Il y a plus d’un mois, une faille de sécurité pouvait permettre différentes actions néfastes dans Android. Bien qu'ayant été corrigée, la mise à jour n'est pas encore assez diffusée et la brèche peut permettre une cassure dans le chiffrement intégral d'Android. Le chercheur à l'origine de la découverte a même publié les outils nécessaires.
Fin mai, le chercheur indépendant Gal Beniamini publiait le résultat de ses travaux : la sécurité d’Android était mise à mal à cause d’une faille (en fait une série de failles pouvant se suivre) dans les extensions de Qualcomm. Ces vulnérabilités ont été corrigées en deux temps par Google, qui avait été averti. Une première fois en janvier, puis à nouveau en juin. Le problème était alors que seules les versions 5.1.1 et 6.0 d’Android recevraient les correctifs (70 % des utilisateurs n'en sont pas équipés), Samsung ayant d’ailleurs réagi rapidement.
De l'intégration dans le matériel...
Mais l’histoire ne s’arrête pas là. La faille principale n’a en fait pas été complètement bouchée, et il sera complexe d’y remédier complètement, à moins d’intervenir directement sur le matériel, ce qui pose d’évidents problèmes. Pour expliquer le problème, Beniamini est revenu sur l’affaire Apple/FBI, dont selon lui on peut tirer les comparaisons et conséquences qui s’imposent.
On rappellera donc que depuis iOS 8, le chiffrement intégral est devenu automatique et obligatoire (Full Disk Encryption, ou FDE). Pour éviter que ce chiffrement ne soit trop facilement cassé, Apple n’a pas utilisé directement le code PIN de l’utilisateur. À la place, un code 256 bits est généré en usine et intégré au matériel, dont il dépend : l’UID. C’est seulement ensuite que cette longue clé est en plus chiffrée par le code PIN, ajoutant une protection supplémentaire.
... au stockage sous forme de variable logicielle
Du côté d’Android, le chiffrement est assuré par dm-crypt, que le chercheur décrit comme largement éprouvé par de très nombreux tests. L’utiliser pour assurer le chiffrement intégral de l’espace de stockage est donc un bon choix, avec une limite toutefois, inhérente finalement à toute solution de chiffrement : sa force dépend directement de la clé.
Cette dernière est créée de la façon suivante : une clé maitresse de 128 bits générée aléatoirement, accompagnée d’un salage de 128 bits (insertion de bits aléatoires) puis elle-même chiffrée via le mot de passe de l’utilisateur, qui peut être un code PIN ou un « pattern », c’est-à-dire le dessin que l’on trace en reliant les points. La clé maitresse, appelée DEK (pour Device Encryption Key), est alors stockée dans une zone spécifique, le « crypto footer ».
Matériel contre logiciel
Les clés sont globalement générées de la même manière pour les deux environnements, le matériel influençant directement le processus de création. Il existe pourtant une différence conséquente : dans le cas des puces Qualcomm, l’espace sécurisé où sont stockées les clés – appelé TrustZone – est manipulable par voie logicielle, ce qui est impossible chez Apple.
Pour le chercheur, cela pose un certain nombre de problèmes, le plus évident étant que le chiffrement intégral d’Android peut être cassé via une attaque par force brute (en testant toutes les combinaisons). En effet, si la clé maitresse peut être récupérée directement dans la TrustZone, la seule barrière restante est alors le code PIN de l’utilisateur. Et on sait à quel point il peut être parfois faible.
Des correctifs diffusés, mais pas installés partout
Dans son billet de blog expliquant l’ensemble de ses travaux, Gal Beniamini indique qu’il a utilisé les deux failles de la TrustZone pour extraire la fameuse DEK. Tout ce qu’il avait à faire, c’est accéder à cet espace. Des scripts dédiés en Python ont fait le reste du travail en automatisant les opérations d’attaque par force brute sur le chiffrement. Il est sûr de sa découverte, au point d’avoir publié sur GitHub non seulement les fameux scripts, mais également le code permettant d’extraire la clé maitresse. Ce qui rend d’autant plus dangereuse la découverte.
Pourtant, Beniamini n’a-t-il pas utilisé des failles qui ont déjà été corrigées ? Si, mais ce n’est malheureusement pas suffisant, plusieurs paramètres entrant en ligne de compte. D’une part, les correctifs n’ont pas encore été installés partout. Ars Technica, qui a également abordé la situation, indique que d’après les chiffres de la société de sécurité Duo, 37 % des appareils Android utilisant ses produits sont encore vulnérables.
L'implication d'un tiers complique la donne
D’autre part, les correctifs installés peuvent être retirés d’un smartphone ou d’une table. Selon le chercheur, il suffit que le bootloader de l’appareil ait été débloqué. Les outils ne manquent pas, et faire revenir un smartphone à son état non protégé entrainera mathématiquement le reste de l’attaque par un pirate connaissant la méthode.
Enfin – et c’est selon le chercheur l’un des gros points noirs – les pirates ne seront peut-être pas les seuls intéressés par cette découverte. Les agences d’espionnage et de renseignement n’auraient a priori que peu de démarches à effectuer : demander essentiellement auprès d’un OEM l’image chiffrée d’une TrustZone. Le processus de création de clé sur Android réclame en effet le constructeur lui-même du smartphone, ce qui peut paraître logique, mais implique finalement trois entreprises à chaque fois : Google, Qualcomm et l’OEM.
Non, le chiffrement intégral n'est pas inutile
Pour Beniamini, la différence d’approche d’Android sur le chiffrement intégral et l’implication d’une entreprise tierce créent tout le problème. La correction de ce problème ne sera pas simple, car elle ne peut pas être logicielle. Le chercheur indique pourtant que la solution est à portée de main : la SHK. Il s’agit d’une clé particulière, cette fois intégrée dans le matériel, que les puces Qualcomm utilisent pour certaines fonctions cryptographiques. Malheureusement, elle ne sert qu’indirectement pour le chiffrement intégral du stockage : une clé dérivée est créée et stockée dans la TrustZone sous la forme d’une variable logicielle.
La solution est donc « simple » : ne plus faire de dérivations de clés et se servir du matériel directement. Selon le chercheur, l’efficacité de la méthode est manifeste, comme l’a prouvé le choc entre Apple et le FBI. Bien entendu, cela n’empêche pas les failles de sécurité, comme dans n’importe quelle solution. L’agence américaine a d’ailleurs acheté une telle vulnérabilité pour en finir avec un iPhone 5c récalcitrant.
En attendant, Gal Beniamini indique que le chiffrement intégral d’Android rajoute une évidente couche de protection, mais à une condition : que le mot de passe soit fort, quelle que soit sa forme.
