IA et contrats Meyer : Détecter les bugs crypto avant la production

Comment les agents IA et la conception par contrat détectent les vulnérabilités crypto avant la production

Les agents IA changent la donne dans le développement de systèmes sécurisés : au lieu d'écrire manuellement le code et les tests, ils génèrent des implémentations basées sur des contrats formels. Cela élimine la principale raison de l'échec de la conception par contrat — le double de travail. Dans un projet avec TRNG matériel et PKI, deux vulnérabilités critiques ont été détectées précisément grâce à des tests de contrat que des tests unitaires ordinaires auraient manqués.

Pourquoi les tests manquent les erreurs logiques en cryptographie

Les tests ne vérifient que ce à quoi le programmeur a pensé. S'il n'a pas su vérifier le padding dans RSA ou la qualité d'entropie avant de l'injecter dans DRBG — le test ne s'écrira pas tout seul. C'est ainsi qu'un bogue de 27 ans dans OpenBSD et une vulnérabilité de 16 ans dans FFmpeg ont échappé à des millions de vérifications automatisées. Les compilateurs et analyseurs statiques sont impuissants face aux erreurs logiques : choisir le mauvais mode de chiffrement, omettre les vérifications de révocation de certificats, utiliser des normes obsolètes — tout cela passe sous leur radar.

Problème clé : les tests réagissent à l'implémentation, pas à l'intention. Les contrats capturent l'intention avant qu'une seule ligne de code ne soit écrite. Ils fixent les limites : ce que le système doit faire (postconditions), ce qui est interdit (invariants), et sous quelles conditions il peut être appelé (preconditions). Ce n'est pas juste de la documentation — c'est une spécification exécutable.

Voici ce qui distingue l'approche par contrat :

• Formalité : PRE/POST/INV sont écrits sous forme lisible par machine, pas en commentaires.
• Détection précoce : Les violations de contrat échouent immédiatement, pas en production.
• Focus sur les garanties : Au lieu de « comment ça marche » — « ce qui est garanti ».
• Source unique de vérité : Le contrat ne change pas pendant le développement ; il n'est mis à jour que si les exigences changent.

Comment l'agent IA gère la seconde moitié du travail

La conception par contrat a échoué dans le grand public à cause du double de charge de travail : d'abord écrire le contrat, puis le code, puis les tests. Sous la pression des délais, les contrats étaient les premières victimes. Aujourd'hui, l'agent IA prend en charge l'implémentation et la génération de tests, ne laissant aux humains que la formulation du contrat. Cela change la donne économique : une ligne de contrat remplace des centaines de lignes de code et de tests.

Le processus ressemble à ceci :

• L'humain écrit l'invariant : padding == RSA-PSS | RSA-OAEP; PKCS#1 v1.5 == FORBIDDEN.
• L'agent génère le module CryptoEngine, qui n'utilise que les paddings autorisés.
• Simultanément, l'agent crée un test de contrat qui essaie d'utiliser PKCS#1 v1.5 et s'attend à une exception.
• Si le test échoue — l'agent corrige l'implémentation sans toucher au contrat.
• L'humain ne révise que 10 lignes de contrat, pas 1000 lignes de code.

Avantages :

• Vitesse : 11 jours de travail actif sur un projet embedded fullstack au lieu de mois.
• Fiabilité : Le contrat est le point central ; les erreurs dedans sont plus faciles à repérer qu'en code.
• Évolutivité : Une personne gère des agents dans différents rôles (coder, tester, architecte).

Cas réel : PKI avec TRNG matériel et tests de contrat

Le projet pki-on-box inclut cinq modules : STM32G431 (TRNG matériel), daemon Python (DRBG selon NIST SP 800-90A), CryptoEngine (génération de clés), KeyStorage (AES-256-GCM), service CA (signature X.509). Chaque module possède un contrat formel aux interfaces. Deux vulnérabilités critiques ont été trouvées avant le déploiement :

• Mauvais padding : L'implémentation a accidentellement utilisé PKCS#1 v1.5 au lieu de RSA-PSS. L'attaque Bleichenbacher permet la récupération du texte clair via padding oracle — le test de contrat a échoué immédiatement.
• Mauvais mode AES : ECB a été sélectionné au lieu de GCM. Le contrat exigeait un chiffrement authentifié — le test a échoué à nouveau.

Métriques du projet :

• 131 commits
• 62 contract-tests + 15 HW-tests
• 3 cartes MCU (STM32G474, G431, H750)
• Plateforme cible : RK3328 ARM64
• Coût IA : 1780₽ pour 30 sessions
• Dépôt ouvert : github.com/vasilievsv/hw.pki-on-box

Contrats aux interfaces : Là où surgissent les erreurs critiques

Les erreurs logiques surgissent aux frontières des modules. DRBG produit des octets — CryptoEngine doit savoir comment les utiliser. Sans contrat — quelqu'un choisit un padding dans un exemple StackOverflow. Voici deux contrats clés du projet :

contract: key_generation
  PRE:
    - DRBG.seeded == true
    - algorithm ∈ {RSA-2048, ECDSA-P384}
  POST:
    - private_key.encrypted(AES-256-GCM)
    - public_key = derive(private_key)
  INV:
    - padding == RSA-PSS | RSA-OAEP
    - PKCS#1 v1.5 == FORBIDDEN

contract: certificate_issuance
  PRE:
    - issuer_ca.valid() && !revoked()
    - csr.signature.verify() == true
  POST:
    - cert.serial.unique()
    - cert.signature.verify(issuer_ca.public_key) == true
  INV:
    - root_ca.offline == true
    - cert_chain.depth <= max_path_length

Test de contrat pour le padding :

def test_rejects_pkcs1v15_padding(self, crypto):
    priv, pub = crypto.generate_rsa_keypair(bits=2048)
    data = b"invariant check"
    sig = crypto.sign_data(priv, data)
    # PSS must rabotat
    pub.verify(sig, data, padding.PSS(...))
    # PKCS1v15 must slomatsya
    with pytest.raises(Exception):
        pub.verify(sig, data, padding.PKCS1v15(), hashes.SHA256())

Le test ne vérifie pas la fonctionnalité — il vérifie le respect de l'invariant. Si le padding change — le test échoue, même si la signature « fonctionne techniquement ».

Enseignements clés

• Contrats > tests : Les tests vérifient l'implémentation ; les contrats vérifient l'intention. Les erreurs logiques ne sont détectées que par des garanties formelles.
• IA élimine le double travail : L'agent génère le code et les tests à partir du contrat ; l'humain se concentre sur la spécification.
• Erreurs critiques aux frontières : Padding, modes de chiffrement, vérifications de révocation — tout contrôlé par des invariants aux interfaces des modules.
• Vérification ouverte : Projet avec TRNG matériel et tests de contrat disponible en dépôt ouvert pour audit.
• Économie de temps : 11 jours pour un système embedded fullstack au lieu de mois — grâce à la division des rôles et à l'autogén.

— Editorial Team