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.

Pour autant, aujourd'hui je m'intéresse à ce que le hardware peut apporter au software. Le software seul ne suffit pas, il doit être soutenu par le hardware et vice versa. Les approches de sécurité purement software (chiffrement de disque, vérification d'intégrité du système) appartiennent désormais au passé et sont délestées à une gestion main dans la main avec le hardware dans le cadre du modèle du Trusted Computing.

L'approche d'Apple (SEP)

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.

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.

Pour l'époque (2013), c'était un excellent début ! Et bien sûr, cette implémentation s'est largement améliorée au fil des années.

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 (TrustZone). 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 faisant 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. Les implémentations de TEE sont également réputées pour disposer d'une surface d'attaque massive et de reposer sur des hacks pour implémenter des fonctionnalités de sécurité que nous verrons juste ci-dessous.

Secure Elements (Android + 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 (ici abrégés SE), 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 de sécurité (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 : Titan M

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 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 (avec protection)
• Contrôler strictement le processus de déverrouillage et de déchiffrement des profils (API Weaver)
• Servir évidemment de keystore : génération et stockage de clés cryptographiques, de données biométriques (API StrongBox)

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éverrouillé (permettant des mises à jour).

Le Pixel 2 disposait d'un SE (NXP) également mais pas au même niveau que Titan M. Néanmoins, les premières fondations furent établies.

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).

Un système compromis sera donc détecté, et Titan M soutient complètement ce processus en limitant les tentatives de bypass.

Pour rappel, verified boot (vérification d'intégrité au démarrage) est la pierre angulaire du modèle de sécurité mobile : elle protège non seulement des attaquants locaux mais aussi distants, notamment la persistence de malwares (rootkits). En savoir plus ici.

FBE + Titan M =  ♥️ (Weaver)

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).

Sous le capot, ce mécanisme sur Android emploie l'API Weaver.

L'étape du déverrouillage 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 passe, et leur longueur...

Titan M stocke les tokens nécessaires (de très haute entropie) pour dériver les clés responsables du chiffrement du profil, 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 finalement dériver la clé nécessaire à déchiffrer le profil.

En conséquence, ce mécanisme permet de rendre vos données complètement inutilisables simplement en indiquant au secure element d'effacer son slot Weaver : ce qui se fait lors de la suppression d'un profil sur un Google Pixel par exemple. Bien plus simple et propre que de réécrire sur tout 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 plusieurs décennies pour être bruteforce grâce à Titan M !

Plus précisément, il y a 1 jour de délai entre chaque tentative dès que la barre des 140 tentatives a été dépassée. Un code PIN à 4 chiffres possède 10 000 possibilités. Ce délai s'étend.

É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.

Et peut-être qu'avec ce standard ouvert, nous verrons plus de constructeurs adopter une sécurité hardware équivalente !

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.