Les trois arguments les plus convaincants contre la cryptographie en boîte blanche – et pourquoi ils sont à côté de la plaque.

In première partie de la série Nous avons examiné les limites de la sécurité matérielle : pourquoi la pile TLS d’Android contourne entièrement StrongBox, pourquoi la fragmentation matérielle laisse la plupart des utilisateurs sans protection et pourquoi la sécurité matérielle ne peut pas protéger la couche protocolaire contre la rétro-ingénierie binaire. Si vous ne l’avez pas encore lu, ce contexte est important pour la suite. 

Cet article s'adresse à un autre type de sceptique : non pas à ceux qui pensent que la sécurité matérielle est suffisante, mais à ceux qui ont déjà rejeté en bloc la cryptographie en boîte blanche. Voici les trois arguments que nous entendons le plus souvent, et ils méritent une réponse directe. 

Argument 1 : « La WBC viole le principe de Kerckhoffs. C'est de l'escroquerie. » 

La critique académique est la suivante : le principe de Kerckhoffs stipule qu'un système cryptographique doit être sûr même si tout ce qui le concerne, à l'exception de la clé, est public. La cryptographie en boîte blanche masque l'implémentation pour protéger la clé, ce qui signifie que sa sécurité repose sur l'obscurité. Ce n'est pas une véritable sécurité. Toutes les implémentations publiques de la cryptographie en boîte blanche utilisées dans les compétitions de type Capture du Drapeau, comme WhibOx, sont cassées en quelques jours. C'est un artifice non scientifique. 

Cette critique témoigne d'une mauvaise compréhension du rôle réel de la WBC et, ce faisant, applique mal le principe même qu'elle invoque. 

WBC ne masque pas l'algorithme. L'AES en boîte blanche reste l'AES : mêmes entrées, mêmes sorties, mêmes opérations mathématiques. L'algorithme est entièrement public et inchangé. WBC modifie la façon dont la clé est stockée et utilisée, en l'intégrant à l'implémentation transformée de manière à rendre son extraction beaucoup plus difficile. L'algorithme demeure public. La clé demeure secrète. C'est précisément ce qu'exige le principe de Kerckhoffs. 

Les critiques confondent « le renforcement de l'implémentation » et « la confidentialité de l'algorithme ». Ce sont deux choses différentes. Renforcer une implémentation pour protéger la clé est un mécanisme de protection essentiel ; il ne s'agit pas d'une violation du principe, mais de son respect. 

Imaginez maintenant ce qui se passe sans cette protection. L'attaquant a accès à votre application et à l'appareil. Extraire une clé n'est pas une attaque sophistiquée, c'est un exercice élémentaire. Trouvez l'instruction ARM AES dans le binaire. Placez un point d'arrêt. Exécutez l'application pendant l'opération. Lisez la clé dans le registre. C'est fait en quelques minutes, avec des outils gratuits. À ce stade, le principe de Kerckhoffs ne vous sauve plus : la clé est perdue. 

Le WBC est ce qui rend le principe de Kerckhoffs viable en environnement hostile. C'est le mécanisme qui protège la clé secrète même lorsque l'attaquant a accès à votre binaire et à votre appareil. 

Il est important de noter que la même attaque par point d'arrêt fonctionne contre OpenSSL : trouver l'instruction AES, placer un point d'arrêt, puis lire le registre. Personne n'organise de concours CTF pour tenter de casser l'extraction de clés d'OpenSSL ou d'autres bibliothèques cryptographiques open source, car elles n'ont jamais été conçues pour protéger les clés dans un environnement d'exécution hostile. WBC est soumis à une norme qu'aucune bibliothèque cryptographique de référence ne respecte. La différence réside dans le fait que WBC s'efforce activement de résoudre le problème. 

Il convient de répondre directement aux critiques formulées à l'encontre de WhibOx : oui, les implémentations CTF peuvent être compromises. Les implémentations commerciales constituent une catégorie différente. Les vulnérabilités DFA connues dans nos implémentations RSA/AES ont été corrigées lors du TFIT en 2019. Aucune attaque DFA connue n'a été démontrée contre nos implémentations à courbes elliptiques. Notre produit est certifié FIPS 140-3 (certificat n° 4910), une validation indépendante non disponible pour les participations aux CTF académiques. 

Plus important encore, WBC n'agit pas seul. Les solutions de renforcement de la sécurité des applications (obfuscation, détection d'instrumentation dynamique, détection de débogueurs, détection d'interception) neutralisent activement les outils nécessaires à un attaquant pour mener des attaques par canaux auxiliaires capables de compromettre les implémentations les plus simples. Un attaquant qui tente d'exécuter Frida sur une application renforcée n'est pas confronté à un algorithme obscurci, mais à un système qui détecte ses outils et y réagit. Il ne s'agit pas de sécurité par l'obscurité, mais de défense en profondeur. 

Argument 2 : « Le décodage rend les globules blancs inutiles. » 

Cette solution nous vient d'architectes de sécurité experts en la matière. Leur argument : même s'il est impossible d'extraire la clé brute d'une implémentation en boîte blanche, ce n'est pas nécessaire. Il suffit de copier l'intégralité du fichier binaire en boîte blanche depuis l'application et de l'exécuter sur votre propre serveur. Vous disposez ainsi d'un outil de déchiffrement prêt à l'emploi. Aucune extraction de clé n'est requise. 

C'est une véritable attaque. Contre une implémentation naïve sans validation côté serveur, elle fonctionne. 

Face à un déploiement correctement mis en œuvre, cela échoue au niveau du serveur – et voici pourquoi. 

Un fichier binaire copié n'est pas votre application. Il ne bénéficie pas du même niveau de sécurité d'exécution que votre application exécutée sur un appareil légitime et non modifié. Les systèmes de sécurité d'applications génèrent des données télémétriques comportementales : ce client a-t-il déclenché des détections de falsification ? L'environnement d'exécution est-il propre ? S'agit-il d'un environnement d'exécution vérifié ? 

Un module « white-box » copié et exécuté sur le serveur d'un attaquant échoue à ces vérifications. Il ne possède aucun historique de télémétrie App Aware et ne peut pas satisfaire à l'attestation comportementale. Le serveur peut – et doit – moduler sa réponse en fonction du niveau de sécurité du client lors de son exécution. Un client ressemblant à un binaire copié est traité en conséquence. 

Au-delà de l'attestation comportementale, les échanges de clés uniques par appareil impliquent qu'une implémentation « boîte blanche » issue du provisionnement d'un appareil ne fonctionnera pas sur une autre cible. Le blob extrait est utile uniquement pour l'interaction spécifique avec le serveur dont il provient ; il ne peut servir d'outil de déchiffrement générique. 

Le vol de code est une véritable faille de sécurité qui exige une réponse architecturale concrète. Cette réponse passe par l'attestation comportementale et l'unicité des clés pour chaque appareil, et non par l'ignorance de l'attaque. 

Argument 3 : « La sécurité matérielle rend la protection logicielle obsolète. » 

Cet argument provient des responsables de plateformes et des fournisseurs de matériel : avec StrongBox, le Keystore basé sur un environnement d’exécution de confiance (TEE) et les enclaves sécurisées désormais bien établis, la protection cryptographique logicielle est une approche dépassée. Les applications devraient s’appuyer sur les primitives d’isolation matérielles. L’obfuscation logicielle est superflue. 

Nous avons abordé les fondements techniques de cet argument dans la première partie, mais il convient d'être direct ici : la prémisse est fausse, et cela peut être démontré. 

La pile TLS d'Android (utilisée par toutes les applications établissant des connexions HTTPS standard via HttpsURLConnection ou OkHttp) gère l'échange de clés ECDH entièrement par logiciel, grâce à BoringSSL et Conscrypt. Elle ne passe pas par StrongBox et n'utilise pas de magasin de clés TEE. Les clés de session TLS sont stockées sous forme d'octets bruts en mémoire sur tous les appareils Android, quelles que soient les capacités de sécurité matérielles présentes. 

Il ne s'agit pas d'une lacune théorique. Elle est documentée dans le code source de BoringSSL, dans les discussions des mainteneurs de Conscrypt et dans des recherches évaluées par des pairs. La sécurité matérielle est excellente pour protéger les clés au repos lors d'opérations spécifiques s'appuyant sur le matériel. Elle n'est tout simplement pas impliquée dans la plupart des opérations cryptographiques courantes des applications Android. 

Au-delà de la faille TLS, la sécurité matérielle ne protège pas votre binaire contre la rétro-ingénierie. Elle n'empêche pas un attaquant de comprendre votre protocole et de falsifier des requêtes authentifiées. Elle ne fournit pas d'attestation au niveau de l'application. Elle ne protège pas contre la compromission comportementale de l'environnement d'exécution. 

La sécurité matérielle représente le coffre-fort. Le chiffrement en boîte blanche et le renforcement des applications constituent le transport blindé, protégeant ainsi tout ce qui doit quitter le coffre-fort et interagir avec le monde réel. Le coffre-fort et le transport blindé sont complémentaires. Affirmer qu'un bon coffre-fort rend le transport blindé obsolète témoigne d'une méconnaissance de la fonction respective de chacun. 

Résumé honnête 

La cryptographie en boîte blanche n'est pas inviolable. Aucun fournisseur sérieux ne prétend le contraire. Son principal atout réside dans l'asymétrie des coûts : elle rend le coût et la sophistication nécessaires à une attaque réussie suffisamment élevés pour dissuader la plupart des attaquants de s'attaquer à des cibles plus faciles, et garantit que les attaques qui réussissent requièrent des ressources comparables à celles d'opérations étatiques ou hautement ciblées, et non celles d'apprentis pirates informatiques utilisant Frida. 

Les critiques académiques formulées à l'encontre du WBC sont valables pour les implémentations autonomes simplistes. Elles ne s'appliquent pas à un déploiement correctement architecturé qui combine le WBC avec le renforcement de la sécurité des applications, l'attestation comportementale et l'unicité des clés par appareil. 

Voici trois arguments que nous avons mis à l'épreuve avec nos équipes d'ingénierie, de sécurité et de réussite client. Si vous évaluez la protection des applications et souhaitez examiner comment cela s'applique à votre environnement et à votre modèle de menaces spécifiques, nous serions ravis d'en discuter. Demandez une démo aujourd'hui