Sécurité : le hardware a son importance

Je l'avais déjà mentionné dans un précédent article : la sécurité repose également sur du hardware. Je pense qu'une partie du grand public l'a bien compris ces dernières années avec les failles Spectre et Meltdown qui affectent l'immense majorité des CPU (x86 et même ARM), et plus récemment avec la puce T2 d'Apple. Bien sûr, c'est non-exhaustif.

Le grand problème de la sécurité hardware, c'est qu'elle est fortement limitée dans le temps, car souvent gravée au niveau du silicone. Chaque hardware a forcément des défauts, et s'il est récent, ce n'est après tout qu'une question de temps avant qu'il ne soit compromis. Le software a ses limites même s'il peut apporter des mitigations avec des mises à jour de firmware (ce qui n'est parfois pas permis par certaines enclaves en lecture seule comme chez Apple).

Généralement je tends à considérer qu'un attaquant qui a la motivation et les ressources, qui a un accès physique à votre machine quelle qu'elle soit, ce n'est pas une question de "si" mais de "quand" il réussira à compromettre ladite machine. Peu importe la sécurité employée.

L'approche d'Apple

Pour autant, aujourd'hui je m'intéresse à ce que le hardware peut apporter au software. Depuis l'iPhone 5S, Apple intègre à ses iPhone une enclave sécurisée (Secure Enclave Processor) qui a pour rôle de gérer des informations critiques en son sein : clés privées, données biométriques, etc.

developer.apple.com

Pour faire simple, quand vous utilisez Face ID ou Touch ID, la vérification proprement dite s'effectue au niveau de l'enclave sécurisée grâce à vos données biométriques stockées et chiffrées sur votre appareil, uniquement accessibles par une clé de dérivation gérée par l'enclave dont l'accès est strictement géré par les entrailles d'iOS.

Trusted Execution Environment (TEE)

Pour autant, est-ce que Android était totalement démuni toutes ces années ? Pas vraiment, Android utilise depuis plusieurs versions le TEE présent sur les SoC ARM. C'est l'implémentation standard du hardware-backed keystore qui désigne toutes les implémentations d'enclave sécurisée isolées de l'OS principal.

Le TEE est donc une partie du SoC isolée d'Android et tourne sous son propre système, le protégeant théoriquement d'une compromission d'Android ; la communication avec ce dernier se fait par une interface restreinte.

Pour autant, cette approche est encore perfectible. En effet, il est reproché par les chercheurs en sécurité que le TEE est une partie trop dépendante du reste du SoC, qui partage d'ailleurs la même mémoire physique que ce dernier qui est simplement partionnée.

Secure Elements, vers StrongBox

C'est pour cette raison qu'il a été envisagé d'isoler davantage l'enclave du reste du système et plusieurs tentatives ont consisté en des puces quasiment autonomes avec leur propre stockage, CPU, RAM, OS... c'est quasiment un 2e SoC ! Par exemple, la puce T2 des Macbook s'occupe de faire tourner bridgeOS responsable de la TouchBar, mais bien d'autres choses également relatives à la sécurité du système (comme le démarrage sécurisé).

Ces puces sont appelées secure elements, et Android les gère depuis sa neuvième itération avec l'API StrongBox responsable des générations cryptographiques et de l'interface restreinte entre le système et la puce (il faut bien communiquer).

Les SE proposent donc une sécurité accrue par rapport au TEE, qui était déjà lui-même une grande avancée par rapport à d'autres approches moins avancées, voire pas d'approche du tout avec une sécurité uniquement software-backed qui appartient désormais au passé.

Le nouveau-né de Google

Google a introduit en 2018 une nouvelle "puce de sécurité", autrement dit un SE, sur sa gamme Pixel 3 : Titan M. On la trouve aujourd'hui sur tous les Pixel sortis depuis le Pixel 3, jusqu'au Pixel 5 (3a et 4a inclus).

Titan pour serveur à gauche, Titan M à droite (source : Google)

Titan M a plusieurs rôles (liste non-exhaustive) :

  • Renforcer le verified boot en délestant le SoC de la gestion des clés et du rollback.
  • Contrôler strictement le processus de déverouillage et de déchiffrement des profils.
  • Servir évidemment de keystore : génération et stockage de clés cryptographiques, de données biométriques...

Par rapport à une approche classique type TEE, Titan M protège d'une plus grande variété d'attaques comme les side-channels attack. Également, son firmware est inaccessible en écriture tant que le profil principal n'est pas déverouillé.

Verified Boot + Titan M = ♥️

Titan M est indispensable pour renforcer la sécurité du verified boot qui est une des premières mitigations en cas de modification malveillante du système (OS + bootloader).

Bootflow recommandé : "Android Verified Boot 2.0" (android.googlesource.com)

Un système compromis ne devra donc pas démarrer, et Titan M gère complètement ce processus en limitant les tentatives de bypass.

Lock screen + FBE + Titan M =  ♥️

Ensuite, Titan M renforce la sécurité de l'étape du lock screen. Sur une version d'Android moderne, le chiffrement est passé du full-disk encryption (FDE) au file-based encryption (FBE), ce qui a bien plus de sens pour une gestion granulaire (permise par l'utilisation de user profiles par exemple).

L'étape du déverouillage d'un profil est donc peut-être bénine, mais cruciale. Elle dépend en premier lieu, comme depuis toujours, de la sécurité que vous employez : PIN, mot de passage, et leur longueur...

Titan M stocke les tokens nécessaires pour dériver les clés responsables du chiffrement du disque, et ne les délivre pas jusqu'à ce que l'étape du lock screen soit passée. Quand le bon PIN est rentré, Titan M délivre le token que le smartphone peut utiliser pour dériver la clé nécessaire à déchiffrer le disque.

Titan M propose une mitigation efficace des attaques par bruteforce, et dispose de sa propre horloge interne pour éviter un bypass. Les durées entre plusieurs tentatives erronées s'allongent... Mathématiquement, un code à 4 PIN généré aléatoirement peut prendre jusqu'à environ 650 ans pour être bruteforce grâce à Titan M !

Évidemment, privilégiez des PIN à au moins 6 chiffres...

L'avenir

Nous avons constaté l'évolution du principe d'enclave sécurisée, son rôle, et comment ce concept est aujourd'hui poussé au maximum jusqu'à devenir une puce indépendante du reste du système et qui communique de façon stricte avec le système principal.

À ce jour, Apple et Google proposent ce qu'il se fait de mieux dans la matière, et c'est une des raisons pour lesquelles je conseille largement un iPhone ou un Google Pixel. Samsung me semble-t-il est le seul constructeur qui commence à suivre les pas de Google avec le secure element S3FV9RR.

Titan M, bien qu'étant remarquablement bien pensé, souffre de son manque de transparence. Son firmware est en grande partie closed-source, et c'est un problème inhérent aux SoC ARM. Conscient du problème, Google souhaite capitaliser sur ses avancées et se tourne vers l'avenir avec le projet Open Titan, qui reposera sur le jeu d'instructions RISC-V au lieu d'ARM, et pourra ainsi proposer un modèle open-source, de confiance, et plus facilement auditable.

J'ai seulement effleuré une petite partie de ce vaste domaine et je vous invite à faire vos propres recherches et à suivre activement ce qui se passe dans le domaine. Apple devrait par exemple très bientôt mettre à jour sa puce T2 qui était une variante de son SoC A10, et je pense que ce sera le cas dès le mois prochain avec l'annonce des premiers Macbook ARM.