Binaires et artefacts compilés
Binaires et artefacts compilés
Inventoriez la cryptographie embarquée dans les exécutables, bibliothèques, assemblies .NET et archives Java, lorsque vous n'avez pas le code source.
S'applique à :
ELF, PE / COFF, Mach-O (y compris binaires universels)Assemblies .NETClasses Java, JAR / WAR / EAR (imbriquées)Keystores embarqués
Vue d'ensemble
L'analyse des binaires trouve la cryptographie à l'intérieur des artefacts compilés. Elle complète l'analyse du code source, qui a besoin des sources, et l'analyse des images de conteneurs, qui à elle seule ne voit que les noms de paquets, les bibliothèques et les fichiers de configuration.
Rien n'est exécuté ni chargé. Les fichiers sont lus comme des octets et analysés avec des parseurs en lecture seule pour ELF, PE / COFF et Mach-O, ainsi qu'un lecteur borné pour les fichiers de classes Java et les métadonnées .NET.
Ce qui est lu
| Artefact | Preuve | Confiance |
|---|---|---|
| ELF, PE / COFF, Mach-O | Bibliothèques crypto liées : entrées ELF DT_NEEDED, tables d'import et d'import différé PE, commandes de chargement dylib Mach-O. OpenSSL, BoringSSL, LibreSSL, libgcrypt, libsodium, Mbed TLS, wolfSSL, GnuTLS, NSS, CommonCrypto, Security.framework, Windows CNG (bcrypt.dll, ncrypt.dll), crypt32.dll et les fonctions Crypt* de advapi32.dll. | import |
Symboles importés, dynamiques et (si le binaire n'est pas strippé) statiques, associés à des algorithmes, par exemple RSA_*, EC_KEY_*, ECDSA_*, DH_*, EVP_md5, mbedtls_*, wc_*, crypto_sign_*, BCryptSecretAgreement, CryptGenKey, CC_MD5, SecKeyCreate*. | symbol | |
OID embarqués : RSA et ses OID de signature, clé publique EC, ECDSA, DSA, DH, MD5, SHA-1, ML-DSA, SLH-DSA et ML-KEM. Noms d'algorithmes PQC comme ML-KEM-768, ML-DSA-65 ou X25519MLKEM768. | constant | |
Identifiants d'algorithmes Windows CNG (RSA, ECDH_P256, ML-KEM...), comptés uniquement lorsque l'image utilise réellement CNG. | constant | |
Chaînes de version de bibliothèques (OpenSSL 1.1.1w, LibreSSL, BoringSSL, Mbed TLS, wolfSSL). Si la bibliothèque n'est pas liée dynamiquement, elle est signalée comme liée statiquement. | constant | |
| Assemblies .NET | Noms de types crypto issus des métadonnées de l'assembly (RSACryptoServiceProvider, RSACng, ECDsa, ECDiffieHellman, DSA, MD5, SHA1, TripleDES, MLDsa, MLKem, SlhDsa...), uniquement si l'assembly référence System.Security.Cryptography. | symbol |
| Classe Java, JAR / WAR / EAR | Les archives sont ouvertes récursivement, y compris les bibliothèques imbriquées (WEB-INF/lib, BOOT-INF/lib...). Références de classes vers javax.crypto, java.security (KeyPairGenerator, Signature, MessageDigest, KeyFactory, KeyStore...) et Bouncy Castle ; l'algorithme est déduit du nom de classe (RSAPublicKey, ECGenParameterSpec, MLDSA*...). | symbol |
Constantes de chaîne passées à l'API crypto Java ("RSA", "RSA/ECB/OAEPWith...", "SHA1withRSA", "EC", "DESede", "MD5", "ML-DSA-65", "ML-KEM-768"...), uniquement dans les classes qui utilisent une API crypto. Blocs de signature JAR (META-INF/*.RSA, *.DSA, *.EC) ; Bouncy Castle identifié via le manifeste. | constant | |
| Keystores | Les keystores embarqués dans les archives (.jks, .jceks, .p12, .pfx, .keystore, .truststore) sont signalés comme constatations de keystore ; les fichiers PKCS#12 sont analysés. | - |
| Bibliothèques natives dans les archives | Les fichiers .so, .dll, .dylib et .jnilib contenus dans une archive sont analysés comme artefacts natifs. | comme ci-dessus |
Les classes d'un fournisseur crypto lui-même (Bouncy Castle) sont signalées une seule fois, comme bibliothèque, plutôt que comme chacun des algorithmes qu'il implémente.
Niveaux de confiance
Chaque constatation porte le niveau de confiance le plus fort observé pour cet artefact et cet algorithme :
| Niveau | Signification | Score de confiance |
|---|---|---|
import | L'artefact lie une bibliothèque crypto ou utilise une famille d'API crypto. L'algorithme utilisé n'est pas établi. | 0.5 |
symbol | L'artefact référence une fonction, une classe ou un type propre à un algorithme. | 0.7 |
constant | L'artefact embarque une constante qui nomme l'algorithme : OID, identifiant d'algorithme, chaîne de transformation Java, bloc de signature ou chaîne de version de bibliothèque. | 0.9 |
Constatations et CBOM
- Une constatation par artefact et algorithme, et par artefact et bibliothèque, avec jusqu'à huit lignes de preuve (par exemple
[symbol] imports RSA_new from libcrypto.so.3, ou[constant] com/acme/Signer passes "SHA1withRSA"). - L'emplacement est le chemin de l'artefact ; les membres d'une archive sont notés avec
!/, par exempleapp.war!/WEB-INF/lib/legacy.jar. - Algorithme, bibliothèque, confiance et preuves alimentent le CBOM CycloneDX exactement comme les constatations du code source.
- Risque : RSA, ECC, DH, DSA, Ed25519 et X25519 sont vulnérables au quantique (High au niveau
symbolouconstant, Medium au niveauimport) ; MD5, SHA-1, DES, 3DES, RC4 et RC2 sont signalés comme faibles au sens classique (Medium) ; ML-KEM, ML-DSA et SLH-DSA comme résistants au quantique (Info) ; AES, SHA-2 et ChaCha20 en Low ; une bibliothèque vue sans algorithme précis en Info.
Comment lancer l'analyse
| Où | Comment |
|---|---|
| Interface du Cockpit | Dans PQC Readiness, créez une nouvelle analyse et choisissez Binaries & Artefacts, puis téléversez un fichier (jusqu'à 24 Mio). |
| Agent de scan | La commande binary analyse un fichier ou un répertoire entier sur la machine qui détient les fichiers. |
| Analyse du système de fichiers | Ajoutez --binaries à la commande filesystem de l'agent pour examiner les artefacts compilés pendant l'inventaire des certificats et keystores. |
| Analyses d'images de conteneurs | Automatique : chaque analyse d'image Docker, de registre OCI ou Harbor exécute aussi l'analyse des binaires sur le système de fichiers de l'image. Les résultats apparaissent par conteneur sous Crypto in compiled artefacts et dans le rapport JSON. |
| API REST | POST /api/pqc/scans avec scan_type: "binary", le fichier dans options.artifact_data (base64) et son nom dans options.artifact_name. Jusqu'à 24 Mio. |
Agent de scanBASH
# Un fichier ou un répertoire entier
dke-scanner-agent binary ./dist --format summary
dke-scanner-agent binary /opt/app/app.war --output app-binary.json
# Inventaire des certificats et keystores, plus les artefacts compilés
dke-scanner-agent filesystem --path /opt/app --binaries| Option de l'agent (binary) | Description | Par défaut |
|---|---|---|
<path> | Fichier ou répertoire à analyser | - |
--max-depth <N> | Profondeur maximale de répertoire (0 = illimitée) | 12 |
--exclude <LIST> | Sous-chaînes de chemin à ignorer, séparées par des virgules | .git,node_modules |
--max-file-mb <MiB> | Taille maximale de fichier lu | 128 |
--timeout <SECS> | Budget de temps pour l'ensemble de l'analyse | 300 |
--format <FMT> | json ou summary | json |
-o, --output <FILE> | Écrire dans un fichier au lieu de la sortie standard | - |
Téléversement uniquement via le Cockpit
Le Cockpit ne lit jamais un chemin de son propre hôte pour cette analyse : via l'interface et l'API, l'artefact est toujours téléversé, comme pour les captures de paquets. Les artefacts plus volumineux et les répertoires entiers passent par l'agent de scan, qui s'exécute sur la machine qui détient les fichiers.
Plafonds de sécurité
Chaque limite est appliquée. Une limite atteinte est consignée comme note sur l'analyse : un résultat partiel apparaît comme partiel.
| Limite | Agent de scan | Téléversement Cockpit |
|---|---|---|
| Fichier lu depuis le disque | 128 Mio (--max-file-mb) | 24 Mio (plafond de téléversement) |
| Taille décompressée d'une entrée d'archive | 32 Mio | 32 Mio |
| Octets décompressés par archive de premier niveau (imbriquées comprises) | 512 Mio | 256 Mio |
| Entrées par archive de premier niveau (imbriquées comprises) | 50 000 | 30 000 |
| Profondeur d'imbrication des archives | 3 | 3 |
| Taux de compression par entrée | 100:1 (au-delà : refusé comme bombe de décompression) | identique |
| Fichiers examinés par parcours de répertoire | 20 000 | n/a |
| Symboles par objet natif | 500 000 | identique |
| Durée totale | 300 s (--timeout) | 120 s |
La taille déclarée d'une entrée d'archive est vérifiée avant lecture et la lecture effective est elle aussi plafonnée : une entrée qui ment sur sa taille ne peut pas dépasser la limite. Les parcours de répertoire ne suivent jamais les liens symboliques.
Limites
Lire les résultats comme des preuves, pas comme un graphe d'appels
L'analyse montre ce qu'un artefact lie, référence ou embarque. Elle ne retrace pas quels chemins de code appellent quel algorithme à l'exécution.
| Limite | Détails |
|---|---|
| Binaires strippés liés statiquement | Sans table de symboles, une bibliothèque liée statiquement n'est trouvée que par sa chaîne de version et sa table d'OID compilée. Les deux montrent que la bibliothèque est présente et ce qu'elle sait faire, pas quels algorithmes le programme appelle. La table d'OID d'une bibliothèque crypto liste tous les algorithmes qu'elle prend en charge : une preuve de niveau constant issue d'une bibliothèque crypto indique une capacité, pas un usage. |
| Code obscurci, compressé ou chiffré | Les exécutables compressés (par exemple UPX), le chiffrement de chaînes Java (ProGuard / R8), les obfuscateurs .NET et les packers natifs masquent symboles et constantes. Le scanner rapporte ce qui est visible et ne décompresse pas. |
| Profondeur .NET | Seuls les noms de types des métadonnées sont lus. Les corps de méthodes (IL), les chaînes utilisateur (comme les noms d'algorithmes passés en chaîne) et les imports natifs déclarés par DllImport ne sont pas analysés. Les images Native AOT et ReadyToRun sont traitées comme du code natif. |
| Profondeur Java | Les constantes de chaîne sont attribuées à la classe qui les contient, pas au site d'appel. Une valeur construite à l'exécution (concaténation, fichier de configuration) n'est pas vue. Kotlin et Scala sont couverts, car ils compilent vers le même format de classe. |
| Chargement dynamique | Les bibliothèques chargées à l'exécution (dlopen, LoadLibrary, fournisseurs crypto Java choisis par configuration) ne laissent aucune entrée d'import. |
| Formats non couverts | WebAssembly, bytecode Python, métadonnées de modules Go et Rust, archives statiques .a / .lib et images de firmware. Les binaires Go et Rust restent analysés comme des ELF / PE / Mach-O ordinaires. |
| OID courts | Les OID Ed25519 et X25519 sont trop courts pour être reconnus de façon fiable ; ces algorithmes sont trouvés via les symboles et les noms. |
| Téléversements Cockpit | Un fichier de 24 Mio au plus par analyse. Utilisez l'agent de scan pour les artefacts plus volumineux et les répertoires. |