Comment respecter (et dépasser !) la norme IEEE 1735

Le mois dernier, j'ai reçu un courriel de recrutement d'une personne prétendant être recruteur senior chez Workday.

Soigné. Personnalisé. Sans fautes d'orthographe. Mon prénom dans l'objet, contournant tous les filtres anti-spam.

Je n'ai pas répondu. J'ai vérifié le domaine de l'expéditeur : `embauche-journée de travail.co`.

Pas `workday.comLes enregistrements DNS indiquaient que le routage du courrier passait par `emx.mail.ru`. Les en-têtes SMTP bruts ont confirmé l'origine à `send35.i.mail.ru [89.221.237.130], un relais russe, à 1 h 23, heure de Moscou. Sélecteur DKIM : `mailru`. Politique DMARC : `p=NONE`. Proxy Cloudflare, TTL zéro pour chaque enregistrement. Infrastructure dédiée, conçue pour une diffusion et une disparition rapides.

Le texte était très probablement généré par une IA. J'en suis certain, car un recruteur qui aurait réellement lu mon profil y aurait trouvé une référence. Or, quatre données LinkedIn (nom, titre, secteur d'activité et lieu) ont été intégrées à un modèle de texte et diffusées simultanément à des milliers de cibles. La personnalisation représente la surface d'attaque. L'infrastructure, quant à elle, est révélatrice.

Trop souvent, les systèmes ne sont pas conçus en tenant compte du véritable attaquant. Le profil LinkedIn a été créé pour être consulté par un recruteur effectuant des prises de contact manuelles. Or, les attaquants déploient désormais des processus automatisés à grande échelle, utilisant l'IA pour transformer des données publiques en une forme de confiance exploitable. Cet écart entre l'attaquant supposé par le système et celui qui exploite réellement la faille n'est pas propre aux plateformes sociales. Il s'agit du principal mode de défaillance des systèmes de sécurité, tous secteurs confondus.

Cela m'a fait penser au précédent établi par la norme IEEE P1735 – Pratiques recommandées pour le chiffrement et la gestion de la adresse IP de conception électronique – une norme développée pour protéger la adresse IP de conception matérielle comme le code HDL pour Verilog/VHDL dans la chaîne d'approvisionnement des semi-conducteurs.

En 2017, Chotaray, Nahiyan, Shrimpton, Forte et Tehranpoor ont publié « Standardizing Bad Cryptographic Practice », démantelant la norme IEEE 1735-2014. Un article de 2021 de Speith, Schweins, Ender, Fyrbiack, May et Paar a démontré la récupération complète des clés privées à partir d'implémentations de production chez Intel, Cadence, Siemens, Lattice et autres.

La norme utilisait AES-CBC avec transport de clés RSA. Le chiffrement n'était pas le maillon faible, mais plutôt le modèle de menace. La norme P1735 désignait l'outil EDA comme fiable. Elle modélisait l'attaquant comme un utilisateur IP passif tentant de lire un fichier protégé au repos. Elle ne prenait pas en compte un attaquant contrôlant l'environnement d'exécution, capable de fournir à l'outil des entrées chiffrées spécialement conçues et d'analyser systématiquement ses erreurs de sortie.

La norme imposant l'utilisation d'AES-CBC sans authentification sur le bloc de données et encourageant explicitement les outils de CAO à renvoyer des erreurs de syntaxe descriptives lors du traitement, l'outil lui-même est devenu l'oracle du déchiffrement. Le principe d'utilisabilité de la norme, selon lequel « la qualité des messages d'erreur reflète la qualité de la adresse IP protégée », a constitué le vecteur d'attaque. (Il est à noter que les recommandations ne prenaient pas en compte la vulnérabilité CWE 209 – Divulgation d'informations via un message d'erreur). L'étude de 2021 est allée plus loin : elle a mis en évidence la présence de schémas de cryptographie en boîte blanche basés sur RSA déjà déployés dans les implémentations d'outils de CAO, preuve que l'industrie avait indépendamment identifié la menace MATE (Man-At-The-End) et opté pour le chiffrement en boîte blanche comme solution, mais sans la couche d'intégrité d'exécution nécessaire pour protéger l'implémentation contre un attaquant déjà présent dans l'environnement d'exécution.

La conclusion des chercheurs est sans équivoque : les faiblesses de la norme IEEE 1735 ne peuvent être corrigées par de simples solutions cryptographiques, compte tenu des méthodes de conception matérielle actuelles. Toute protection qui part d’une autre hypothèse échoue là où elle n’a pas prévu le problème.

L'e-mail de recrutement en IA et la norme IEEE 1735 partagent une cause commune : la protection a été évaluée face à un attaquant inadapté dans un environnement inapproprié. La norme IEEE 1735 supposait un lecteur passif, alors que l'attaquant manipulait l'environnement d'exécution. 

 Les profils LinkedIn supposent une prise de contact manuelle par un humain, mais l'attaquant utilise en réalité un processus automatisé : extraction, classification, génération et diffusion à grande échelle. Le LLM sert d'outil d'analyse exploratoire des données (EDA), la boîte de réception humaine fait office d'oracle et le texte brut extrait constitue la source de confiance, contrairement au HDL.

Il s'agit aujourd'hui du mode de défaillance dominant dans l'approvisionnement en sécurité des applications.

Ce que cela signifie pour le choix d'une solution de sécurité

Lorsqu'ils évaluent des produits de sécurité pour des logiciels distribués publiquement, les développeurs vérifient la couverture de conformité, la complexité d'intégration et l'impact sur les performances. Les questions qu'ils omettent généralement sont les suivantes :  
(1) Que suppose cette protection que l'attaquant ne puisse pas faire, et  
(2) Les hypothèses sont-elles toujours vraies lorsque l’attaquant dispose d’outils assistés par l’IA, d’un accès complet à l’environnement d’exécution et d’un budget de requêtes illimité ? 
 
Une architecture de protection qui ne prend pas en compte le modèle de menace approprié, à savoir l'attaque de l'homme au bout du fil (Man-At-The-End) ou l'attaque de l'homme dans le client (Man-In-The-Client), où l'attaquant contrôle le système. dispositif le logiciel fonctionne en se mettant dans la même position que IEEE 1735. La cryptographie peut être son. L'hypothèse de limite ne l'est pas. Un attaquant déjà à l'intérieur de l'environnement d'exécution n'interagit pas avec le applicationla manière dont la protection a été conçue laissait présager et menait généralement à des problèmes graves.  
 
La solution sur laquelle l'industrie des semi-conducteurs s'est néanmoins accordée est la cryptographie en boîte blanche pour protéger les clés dans un environnement d'exécution hostile, combinée à une vérification d'intégrité en temps réel pour détecter et contrer toute instrumentation active. Il s'agit de la même architecture que celle qui appartient at la couche application mobile. Non pas comme une simple case à cocher pour se conformer à la réglementation, mais en réponse directe à une menace. modèle La norme n'a pas été respectée. 
 
En 1993, Ross Anderson a argumenté dans « Pourquoi les cryptosystèmes échouent » » que les failles de sécurité sont rarement d'ordre cryptographique. démontré que les calculs mathématiques sont corrects, mais le modèle de menace et Les hypothèses concernant l'attaquant, ses accès et son environnement s'avèrent erronées. L'expérience d'Anderson a démontré que ces hypothèses aboutissent à des systèmes techniquement conformes, mais opérationnellement défaillants. IEEE 1735 et le processus de recrutement par IA ciblant les profils LinkedIn en sont des exemples. 
 
Avant de valider une solution de sécurité pour une application distribuée publiquement, posez-vous une question : existe-t-il des protections logicielles qui prennent en compte tout ce que l’attaquant ne peut pas faire ? 
 
Si la réponse n'est pas consignée par écrit, le modèle de menace n'a pas été réalisé. 
 
Si yovous aimeriez discuter de votre IEEE 1735 ou autres cryptomonnaies White-Boxbesoins en photographie avec untrois, Nous contacter ici: https://digital.ai/why-digital-ai/contact/

Références

Anderson, RJ (1994). Pourquoi les cryptosystèmes échouent  
https://doi.org/10.1145/188280.188291 
 
Chhotaray et al., « Normalisation des mauvaises pratiques cryptographiques » https://doi.org/10.1145/3133956.3134040 
 
Speith et al., « Comment ne pas protéger sa adresse IP »  
https://doi.org/10.1109/SP46214.2022.9833605 
 
https://cwe.mitre.org/data/definitions/209.html