Contexte et objectifs

Le texte résume une présentation destinée à des conférences et organisations telles que Primavera Hacker 25 ou la Freedom of the Press Foundation. Il explique que les outils commerciaux de déverrouillage de téléphones ne reposent pas sur des vulnérabilités inédites, mais sur la commercialisation d’exploits déjà publiés dans des conférences académiques. Leur valeur réside dans la capacité à assembler ces exploits pour chaque combinaison matériel/logiciel et à les empaqueter dans des flux automatisés nécessitant peu d’expertise de l’opérateur.

Architecture matérielle de sécurité

Les processeurs ARM modernes intègrent TrustZone, qui divise le cœur en Normal World (Android, Linux kernel, applications) et Secure World (Trusted OS et Trusted Applications). La communication se fait via le Secure Monitor Call (SMC) géré par le moniteur au niveau EL3. Différents fournisseurs implémentent des variantes : Google utilise TrustyOS, Qualcomm QSEE, Samsung TEEGRIS, Huawei TrustedCore et Trustonic propose Kinibi. Le Secure World héberge Gatekeeper, qui vérifie les codes PIN/password et délivre un jeton signé, ainsi que Keymaster, responsable de la gestion des clés cryptographiques, dont certaines sont liées à l’authentification.

Vecteurs d’attaque exploités

Les outils forensiques ciblent chaque maillon de la chaîne de démarrage. Le Boot ROM, gravé dans le silicium, constitue la racine de confiance et, à quelques exceptions récentes, reste immuable. Il charge le preloader (ou secondary bootloader BL2) qui initialise le matériel, charge le Trusted OS dans le Secure World et le bootloader normal (BL3). Le bootloader applique Android Verified Boot (AVB), les protections anti‑rollback et les vérifications d’état avant d’exécuter le noyau Linux. Le système d’exploitation utilise dm‑verity pour garantir l’intégrité des partitions à l’exécution. Lorsque le dispositif possède un Secure Element, celui‑ci suit une chaîne de confiance parallèle : le StrongBox API (Android 9) expose le Titan M (Pixel 3‑5) ou le Titan M2 (Pixel 6+). Le SE stocke les clés de chiffrement et applique un taux de limitation matériel, rendant l’extraction de clés impossible tant que le SE n’est pas compromis. Les outils doivent donc contourner ou exploiter des failles à chaque étape : vulnérabilités du Boot ROM, erreurs de vérification du preloader, failles du Trusted OS, défauts d’AVB ou de dm‑verity, et enfin attaques contre le SE lorsqu’il est présent.

Limites et contre‑mesures

La présence d’un Secure Element constitue la principale barrière : les téléphones sans SE (la majorité des modèles milieu de gamme) peuvent être déverrouillés en compromettant uniquement le TEE. Les dispositifs flagship, équipés de Titan M ou Titan M2, exigent une compromission du SE, ce qui augmente la complexité et le coût de l’attaque. Les mécanismes de limitation de taux de Gatekeeper et de Keymaster, ainsi que les protections anti‑rollback d’AVB, ralentissent les tentatives de brute‑force mais restent vulnérables si un exploit du Trusted OS est disponible. Les travaux de Quarkslab, Amnesty International Security Lab et GrapheneOS offrent des analyses détaillées de ces vecteurs et proposent des correctifs, notamment le renforcement du code du Trusted OS et la mise à jour du firmware du SE. En l’absence de correctifs spécifiques, la résistance dépend largement de la robustesse du matériel et de la rapidité des mises à jour logicielles.