La sécurité de votre matériel fonctionne. Ce n'est pas le problème.

Nous entendons régulièrement une objection similaire : « Nous utilisons déjà Android StrongBox. Nous avons un échange de clés ECDH. Nos clés ne quittent jamais le matériel. Pourquoi aurions-nous besoin d’une cryptographie en boîte blanche en plus de cela ? » 

C'est une question légitime. StrongBox, Keystore basé sur un environnement d'exécution de confiance (TEE) et ECDH sont des technologies véritablement robustes. Les rejeter serait intellectuellement malhonnête et contre-productif. Au lieu de les écarter, examinons plutôt ce qu'elles protègent réellement et quelles sont leurs failles.

L'analogie du coffre-fort – et pourquoi elle est incomplète 

La sécurité matérielle excelle dans un domaine : la protection des clés. safe Dans un coffre-fort, StrongBox génère, stocke et effectue des opérations cryptographiques sans jamais exposer les données brutes. C'est une véritable protection, et c'est essentiel. 

Mais voici la question que la plupart des architectes de sécurité ne se posent pas : Le coffre-fort fait-il obstacle aux opérations les plus importantes ? 

Pour les applications Android établissant des connexions serveur standard (via HttpsURLConnection, OkHttp ou des API similaires gérées par le système d'exploitation), la réponse est généralement négative. La pile TLS d'Android repose sur BoringSSL et Conscrypt, deux bibliothèques logicielles qui gèrent l'échange de clés ECDH entièrement par logiciel, sans passer par StrongBox ou TEE Keystore. Les clés de session TLS sont stockées sous forme d'octets bruts en mémoire, indépendamment du matériel de votre appareil. 

Il ne s'agit pas d'un défaut de conception d'Android, mais d'une réalité architecturale souvent négligée dans les discussions sur la sécurité des applications. Votre coffre-fort est excellent. Cependant, pour TLS, le coffre-fort n'est pas situé dans le bâtiment. 

Quand le binaire constitue la surface d'attaque 

Laissons de côté TLS un instant. Prenons l'exemple d'une application qui utilise des clés matérielles pour ses opérations cryptographiques : des clés correctement provisionnées, dérivées d'ECDH et stockées en toute sécurité dans StrongBox. Voilà une configuration robuste. 

Voyons maintenant ce qu'un attaquant fait concrètement avec votre application. Il ne tente pas d'extraire la clé de StrongBox, car c'est difficile. Il télécharge votre application, exécute un désassembleur et lit votre code. 

Ce qu'ils découvrent, c'est la logique d'établissement de liaison : le protocole utilisé par votre application pour communiquer avec votre serveur, le flux d'authentification et la structure de l'API. Grâce à ces informations, ils n'ont pas besoin de votre clé. Ils créent une application modifiée qui effectue une authentification complète et parfaitement légitime. StrongBox activé leur Ce périphérique détient désormais une clé à laquelle votre serveur fait confiance. 

L'attaque la plus lucrative ne consiste pas à lire les données déchiffrées d'un seul utilisateur. Elle consiste à comprendre suffisamment bien votre protocole pour falsifier des requêtes API authentifiées, potentiellement à grande échelle et en se faisant passer pour n'importe quel utilisateur. La sécurité matérielle est impuissante face à ce type d'attaque, car celle-ci n'atteint jamais le matériel. 

C’est là que la cryptographie en boîte blanche et le renforcement des applications comblent leurs lacunes : protéger la logique du protocole elle-même, et pas seulement la clé. 

Le problème de la fragmentation (tant qu'il dure) 

Même en faisant abstraction du problème de BoringSSL, la sécurité matérielle présente un défaut de couverture sur Android. Selon l'étude DroidCCT – une analyse évaluée par des pairs sur la sécurité des appareils Android – StrongBox n'est disponible que sur 8.7 % des appareils haut de gamme, 7.2 % des appareils de milieu de gamme et 0.2 % des appareils d'entrée de gamme. La plupart de vos utilisateurs ne l'ont pas. 

iOS, c'est une autre histoire : Secure Enclave est présent sur tous les appareils iOS actuels et offre une protection matérielle robuste. L'argument de la fragmentation concerne principalement Android. 

Il convient de reconnaître que cet argument a ses limites. La disponibilité du matériel s'améliorera avec le temps, et certaines recommandations de sécurité préconisent déjà la cryptographie en boîte blanche comme complément temporaire à l'environnement d'exécution de confiance (TEE), le temps que l'adoption du matériel se généralise. Les arguments relatifs à la rétro-ingénierie binaire, à l'attestation et à l'indépendance vis-à-vis des fournisseurs restent pertinents ; la fragmentation est l'argument le plus convaincant aujourd'hui. Pour certaines organisations, notamment celles soumises à des contraintes réglementaires ou d'approvisionnement, réduire la dépendance à l'égard de la solution de sécurité d'un fournisseur de matériel unique constitue un objectif de conception en soi. 

Que signifie réellement « attestation de couche application » ? 

Voici une autre lacune qu'il convient de mentionner : votre serveur a terminé une négociation, mais il ne sait pas à qui il parle. 

Il est incapable de faire la différence entre votre application légitime exécutée sur un appareil réel, une version reconditionnée de votre application exécutée sur un appareil rooté et un client entièrement synthétique qui a imité votre échange de clés après avoir rétro-ingénierisé votre protocole. 

L'API Google Play Integrity est utile. L'intégration du niveau MEETS_STRONG_INTEGRITY avec une liaison nonce et requestHash appropriée réduit considérablement la surface d'attaque. Cependant, la réutilisation par un proxy propre demeure un risque résiduel, quel que soit le niveau d'intégrité. 

La cryptographie en boîte blanche fournit une attestation au niveau de l'application : une preuve cryptographique que la requête provient d'une application non modifiée exécutant une logique de protocole protégée, indépendamment des signaux de confiance du système d'exploitation ou du matériel. Il s'agit d'un second signal, orthogonal, qui ne remplace pas l'intégrité de Play, mais constitue la couche complémentaire qui prend en charge les limites de cette dernière. 

La version la plus sophistiquée de cette approche – et celle qui, selon nous, représente l'avenir du secteur – consiste en une attestation comportementale continue : ce client a-t-il déclenché des alertes de falsification depuis sa dernière requête ? Un serveur capable de moduler sa réponse en fonction du niveau de sécurité du client en temps réel est nettement plus résilient qu'un serveur prenant une décision binaire (de confiance/non-confiance) lors de l'établissement de la session. 

L'image complète 

La sécurité matérielle, c'est le coffre-fort. Le chiffrement en boîte blanche et le renforcement des applications, c'est le transport blindé : ils protègent tout ce qui doit quitter le coffre-fort et interagir avec le monde réel. 

Pour la plupart des opérations TLS sous Android, le coffre-fort n'est pas inclus dans le chemin d'accès. Lorsqu'il l'est, il ne protège ni le protocole, ni le binaire, ni la couche d'attestation. Ces raisons ne justifient pas d'abandonner la sécurité matérielle ; elles incitent plutôt à la considérer comme une couche de défense parmi d'autres, et non comme la solution miracle. 

Voici quatre des arguments que nous avons testés en interne avec nos équipes d'ingénierie, de sécurité et de réussite client. L'histoire ne s'arrête pas là, notamment en ce qui concerne l'application de ces arguments à des plateformes spécifiques et aux cadres de conformité (Digital.ai Key & Data Protection détient le certificat FIPS 140-3 n° 4910), et les exigences de l'industrie réglementée. 

Si vous évaluez la protection des applications et souhaitez avoir une vue d'ensemble de son application à votre environnement, nous serions ravis d'en discuter. Demandez une démo aujourd'hui