Certificats de signature de code¶

Stentor prend en charge la signature de code Authenticode pour les payloads générées. Les certificats de signature de code sont téléchargés sous forme de fichiers PFX (PKCS#12), stockés avec des mots de passe cryptés dans la base de données et utilisés pour signer les payloads via l'outil osslsigncode du relais. Les payloads signées portent une signature Authenticode valide qui satisfait à Windows SmartScreen, aux politiques de liste blanche des applications et aux invites de confiance des utilisateurs.

Architecture¶

sequenceDiagram
    participant Operator as Operator
    participant API as Stentor API
    participant DB as PostgreSQL
    participant Relay as Relay (Kali)

    Note over Operator,DB: Certificate Upload
    Operator->>API: POST /certificates (multipart PFX + password)
    API->>API: Parse PFX, extract metadata
    API->>API: Encrypt password (AES-256-GCM)
    API->>DB: Store PFX + encrypted password + metadata
    API-->>Operator: CertificateResponse (no sensitive fields)

    Note over Operator,Relay: Payload Signing
    Operator->>API: POST /sign {payload_id, certificate_id}
    API->>DB: Load payload binary + certificate PFX
    API->>API: Decrypt certificate password
    API->>Relay: sign_payload command (PFX + password + payload)
    Relay->>Relay: osslsigncode sign
    Relay-->>API: Signed payload bytes
    API-->>Operator: {success, signed_size}

Gestion des certificats¶

Télécharger un certificat¶

POST /api/v1/certificates¶

Téléchargez un fichier PFX (PKCS#12) contenant un certificat de signature de code et une clé privée. L'API analyse le PFX pour extraire les métadonnées du certificat (sujet, émetteur, période de validité), crypte le mot de passe avec AES-256-GCM et stocke le tout dans la base de données.

Champs du formulaire :

Limite de taille : 1 Mo maximum pour le fichier PFX.

curl -s -X POST https://stentor.app/api/v1/certificates \
  -H "Authorization: Bearer $TOKEN" \
  -F "name=Contoso Code Signing" \
  -F "description=EV code signing cert for payload signing" \
  -F "pfx_file=@/path/to/certificate.pfx" \
  -F "password=pfx-password-here"

Réponse (201 créées) :

{
  "id": "b2c3d4e5-...",
  "name": "Contoso Code Signing",
  "description": "EV code signing cert for payload signing",
  "subject": "CN=Contoso Ltd, O=Contoso Ltd, L=Redmond, ST=Washington, C=US",
  "issuer": "CN=DigiCert SHA2 Extended Validation Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US",
  "valid_from": "2025-01-15T00:00:00Z",
  "valid_until": "2027-01-14T23:59:59Z",
  "created_by": "USER_UUID",
  "created_at": "2026-02-21T10:00:00Z"
}

Liste des certificats¶

GET /api/v1/certificates¶

Répertoriez tous les certificats stockés. Les champs sensibles (données binaires PFX, mot de passe chiffré) sont exclus de la réponse. Les certificats sont renvoyés dans l'ordre chronologique inverse.

curl -s https://stentor.app/api/v1/certificates \
  -H "Authorization: Bearer $TOKEN"

Champs de réponse :

Obtenir un certificat¶

GET /api/v1/certificates/:id¶

Récupérez un seul certificat par ID. Même format de réponse que le point de terminaison de la liste (pas de champs sensibles).

curl -s https://stentor.app/api/v1/certificates/CERT_UUID \
  -H "Authorization: Bearer $TOKEN"

Supprimer le certificat¶

DELETE /api/v1/certificates/:id¶

Supprimez un certificat et toutes les données associées (binaire PFX, mot de passe chiffré) de la base de données.

curl -s -X DELETE https://stentor.app/api/v1/certificates/CERT_UUID \
  -H "Authorization: Bearer $TOKEN"

Réponse : 204 No Content en cas de succès.

Signature des payloads¶

POST /api/v1/sign¶

Signez un payload générée avec un certificat de signature de code stocké. L'opération de signature est effectuée sur le relais à l'aide de osslsigncode, qui prend en charge les signatures Authenticode pour les fichiers PE (EXE/DLL).

Corps de la demande :

curl -s -X POST https://stentor.app/api/v1/sign \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "payload_id": "PAYLOAD_UUID",
    "certificate_id": "CERT_UUID",
    "description": "Contoso Updater Service",
    "url": "https://contoso.com",
    "timestamp_url": "http://timestamp.digicert.com"
  }'

Réponse (200 OK) :

{
  "success": true,
  "payload_id": "PAYLOAD_UUID",
  "signed_size": 524288
}

Réponses d'erreur :

Flux de signature¶

1. L'API valide la demande et charge le binaire de payload et le certificat PFX à partir de la base de données.
2. Le mot de passe du certificat est déchiffré du stockage AES-256-GCM.
3. Une commande sign_payload est envoyée au premier relais connecté avec les octets de payload, les données PFX, le mot de passe déchiffré et les options de signature.
4. Le relais exécute osslsigncode pour appliquer la signature Authenticode.
5. Les octets de payload signés sont renvoyés à l'API via un canal requête/réponse basé sur la corrélation.
6. L'API renvoie le résultat à l'opérateur.

Stockage crypté¶

Les mots de passe des certificats sont chiffrés au repos à l'aide d'AES-256-GCM avec une clé côté serveur de 32 octets configurée via la variable d'environnement C2_CERTIFICATE_ENCRYPTION_KEY.

Le schéma de chiffrement utilise un nom occasionnel aléatoire de 12 octets pour chaque opération de chiffrement. Le nom occasionnel est ajouté au texte chiffré, la valeur stockée est donc [12-byte nonce][ciphertext + GCM tag].

La rotation des clés est prise en charge via l'utilitaire MigrateEncryptedPassword, qui déchiffre avec l'ancienne clé et rechiffre avec une nouvelle clé en utilisant un nouveau nom occasionnel.

Considérations OPSEC¶