Attaques de reniflage de MTP contre des cibles non-bitlocker

L'année dernière, lors d'un regain d'attention médiatique pour la sécurité des Trusted Platform Module (TPM) déclenché par un billet de blog du Dolos Group décrivant une attaque de reniflage sur Windows Bitlocker reposant sur un TPM, un client nous a demandé d'examiner son installation de chiffrement intégral de disque (FDE) basée sur un TPM à la lumière de ce type d'attaque. Les recherches et les commentaires qui ont suivi, comme l'article du Dolos Group, semblent s'être concentrés sur les TPM utilisés par Windows Bitlocker [1], [2], [3], [4]. C'est pourquoi nous avons pensé qu'il serait intéressant de développer ce scénario en l'appliquant à d'autres scénarios d'utilisation des TPM.

Dans cet article de blog, vous découvrirez :

1. L'historique du Trusted Platform Module (TPM)
2. Notre Modélisation des menaces
3. Enquête
4. L'IoT et les TPM
5. Considérations pour les Red Teaming
6. Recommandations défensives

Contexte

Un module de plateforme de confiance (TPM) désigne généralement un cryptoprocesseur sécurisé dédié conforme à la norme ISO/IEC 11889 du Trusted Computing Group (TCG). Les TPM peuvent être utilisés à des fins diverses, allant de l'intégrité de la plateforme et de la prise en charge FDE au stockage de clés et d'identifiants (par exemple pour l'authentification SSH). Les MPT peuvent être utilisées dans diverses plateformes allant des serveurs et ordinateurs portables aux appareils IoT connectés au cloud.

Il existe deux versions principales de la norme, TPM 1.2 et TPM 2.0, la seconde n'étant pas rétrocompatible avec la première. Les TPM peuvent être mis en œuvre de différentes manières (les dTPM et les fTPM étant les plus courants) :

• TPM discrets (dTPM): ils se présentent sous la forme d'une puce dédiée et inviolable.
• TPMintégrés: ils sont mis en œuvre en tant que sous-système matériel au sein d'une autre puce.
• TPMà microprocesseur (fTPM): ils sont basés sur un microprocesseur et s'exécutent généralement dans l'environnement d'exécution de confiance (TEE) d'une unité centrale.
• TPM d'hyperviseur (vTPM): ils sont séparés d'une machine virtuelle en fonctionnant au-dessus d'un hyperviseur.
• Les TPM logiciels: ils sont purement logiciels et constituent l'implémentation la moins sûre.

En ce qui concerne l'intégrité de la plateforme, les TPM fournissent des mécanismes pour prendre en charge le démarrage mesuré. À partir d'une racine de confiance pour la mesure (CRTM ) (par exemple, la ROM de démarrage d'un SoC), des hachages sont calculés pour divers composants de la plateforme (par exemple, BIOS/UEFI, chargeur de démarrage, micrologiciel de contrôleur intégré, etc. Ces informations peuvent être incorporées dans le Processus de démarrage sécurisé (éventuellement dans le cadre du FDE) pour garantir que ces divers composants n'ont pas été altérés.

Les MPT fournissent également des mécanismes pour prendre en charge les solutions de cryptage afin de fournir des garanties de confidentialité et d'authentification de l'intégrité. Ces mécanismes comprennent la génération de clés, la capacité de chiffrer le matériel de clé avec une clé spécifique à la MPT, et des caractéristiques de résistance à la falsification pour que la MPT fonctionne comme un stockage sécurisé des secrets. L'utilisation d'une clé protégée par un TPM en elle-même est généralement appelée " binding", tandis que l'ajout de valeurs PCR de démarrage mesurées dans le mélange cryptographique est généralement appelé " sealing".

Dans les scénarios de chiffrement, les TPM peuvent généralement être configurés dans l'un des modes suivants :

• TPM uniquement: dans ce cas, le TPM fournit automatiquement la clé à la solution de chiffrement sur demande (par exemple, au démarrage).
• TPM + PIN: dans ce cas, le TPM a besoin d'un secret fourni par le système (généralement un PIN saisi par l'utilisateur) avant de desceller la clé.
• MTP + PIN + MFA: dans ce cas, un facteur supplémentaire, tel qu'une clé USB avec un secret ou un TOTP, est nécessaire.

Dans le cas du FDE, des secrets supplémentaires doivent être fournis avant le démarrage. Les caractéristiques de résistance à l'altération du TPM (devraient) empêcher l'attaque par force brute des codes PIN, l'extraction des clés privées et le déverrouillage pour contourner ces caractéristiques.

Bien qu'il y ait eu par le passé des attaques par sondage invasif, par divers canaux latéraux, par interposition, ainsi que des attaques de conception et d'implémentation contre les TPM, nous nous concentrerons uniquement sur les attaques par reniflage contre les dTPM dans les scénarios d'accompagnement à la mise en œuvre, car ces types d'attaques sont inhérents à la conception des dTPM.

Étant donné que les dTPM sont des puces dédiées distinctes du processeur principal et des autres contrôleurs d'un appareil, elles ont besoin d'un moyen de communiquer avec eux. La norme spécifie les bus LPC, I2C et SPI à cette fin, et le dTPM devra être placé sur un bus avec tout dispositif qui pourrait avoir besoin de lui parler (selon qu'il s'agit d'un rôle mono ou multi-maître).

Pour simplifier quelque peu, lors de l'installation du chiffrement, l'unité centrale devient propriétaire du MPT, le configure et lui envoie une clé pour qu'il la lie ou la scelle. Le MTP chiffre cette clé à l'aide de données d'authentification, de sa propre clé secrète et de mesures PCR optionnelles, puis renvoie le blob de clé chiffrée. Ce blob est ensuite stocké quelque part (généralement dans le cadre d'un en-tête de volume crypté). Lors du décryptage, l'unité centrale envoie le blob de clé crypté au MPT, qui obtient les données d'authentification et les mesures optionnelles et les utilise avec sa clé secrète pour décrypter le blob. La clé en clair est renvoyée à l'unité centrale pour être utilisée.

Ainsi, à un moment donné du processus de décryptage, la clé en clair peut être envoyée par le bus à l'unité centrale en clair, de par sa conception. Bien que la norme TPM 2.0 permette ce que l'on appelle le "chiffrement des paramètres", cette fonction est rarement mise en œuvre par les solutions de chiffrement et, comme l'a souligné Trammell Hudson, elle s'accompagne du problème de l'œuf et de la poule en ce qui concerne l'établissement de la confiance sans la possibilité de stocker des secrets sur l'unité centrale de traitement.

Modélisation des menaces

Notre modélisation des menaces repose sur l'hypothèse d'un attaquant disposant d'un accès physique pour une durée limitée à un appareil utilisant une solution FDE prise en charge par le dTPM. Cela suppose que l'approvisionnement et la mise en service ont été effectués et que les données en question sont cryptées. Bien que toute une série d 'autres menaces entrent dans ce cadre, nous nous sommes spécifiquement concentrés sur le reniflage du bus TPM, car les mesures PCR ne sont pas pertinentes dans ce scénario.

Enquête

Au cours de notre enquête, nous avons comparé Windows 10 Bitlocker avec TPM à plusieurs implémentations FDE basées sur Linux, à savoir : systemd-cryptsetup, clevis, luks-tpm2, safeboot et coreboot. Le TPM en question était un module TPM 2.0 Infineon OPTIGA SLB 9670 avec une interface SPI (bien que ce scénario fonctionne évidemment avec I2C et LPC, comme nous l'avons déjà montré).

Comme nous pouvons le constater, le chiffrement des paramètres n'est tout simplement pas utilisé dans la pratique et, à l'exception de safeboot, aucune des solutions n'applique le PIN/MFA par défaut. Bien que nous n'ayons pas examiné en détail pureboot, U-Boot, tboot et TrustedGRUB2, nous soupçonnons que des résultats similaires s'y appliquent.

Pour aider d'autres personnes à évaluer et à démontrer la faisabilité des attaques par reniflage de TPM contre les implémentations FDE basées sur Linux, j'ai développé deux plugins Saleae Logic 2, comme indiqué ci-dessous. Ils sont disponibles sur Github.

Toutes les solutions que nous avons étudiées sont basées sur le Linux Unified Key Setup (LUKS). Les volumes LUKS2 ont un en-tête avec une zone de keyslot contenant différents keyslots pour différents mots de passe ou fichiers de clés qui peuvent être utilisés pour décrypter le volume. Ces entrées d'emplacement de clé spécifient les informations de dérivation de clé telles que la priorité, la fonction de dérivation de clé, les paramètres, le sel et l'algorithme de chiffrement. Une clé principale chiffrée (MK), stockée dans des bandes anti-forensics (AF), est ensuite déchiffrée à l'aide de la clé dérivée.

Pour utiliser LUKS avec un TPM, la plupart des solutions (system-cryptsetup, safeboot, luks_tpm2) utilisent tpm2-tools, une sorte de boîte à outils BusyBox pour interagir avec la pile logicielle TPM2 (TSS) du Trusted Computing Group (TCG).

Dans systemd-cryptsetup, un jeton TPM est enregistré et lié à un keylot LUKS2. Avec la commande `cryptsetup luksDump /dev/sda1 --debug-json`, nous pouvons voir que le jeton contient une entrée tpm2-blob encodée en base64 qui est envoyée au TPM pour être descellée. Le trafic de descellement est assez facile à repérer sur un bus SPI et consiste en une opération TPM_READ sur TPM_DATA_FIFO_0 (d40024) avec une structure de données composée d'un DWORD avec la valeur 00000022 suivi d'un champ de longueur de la taille d'un WORD (typiquement la valeur 0020) et de la clé de 256 bits qui suit.

Mon plugin Saleae Logic formate la clé pour la sortie du fichier clé LUKS :

Le montage d'un volume peut être fait avec `cryptsetup open ./sda1-luks myvolumename --key-slot 1 --key-file ./mykey --keyfile-size 44`.

Bien que luks-tpm2 fonctionne un peu différemment, il peut stocker les clés dans un fichier scellé sur le disque ou dans la NVRAM du TPM et dispose d'une passphrase pour le descellement. Son opération de descellement est la même sur le bus SPI, et le plugin fonctionne ici aussi. Safeboot semble être la solution la plus robuste parmi celles étudiées, forçant les utilisateurs à utiliser un code PIN par défaut, et fonctionne un peu différemment sous le capot, mais le plugin tpm2-tools fonctionne également pour cette solution.

Clevis est un cadre de décryptage automatisé enfichable avec un certain nombre de "broches" (à ne pas confondre avec un code PIN), où chaque broche met en œuvre le support cryptographique en utilisant un backend différent. Pour le chiffrement, Clevis prend certaines données et une configuration JSON pour produire un objet JSON Web Encryption (JWE) contenant des données chiffrées à l'aide d'une clé JSON Web KEY (JWK) et de certaines métadonnées. Lors du déchiffrement, Clevis obtient la clé à partir de la JWK et des métadonnées et déchiffre le texte chiffré à partir de l'objet JWE.

La "broche" tpm2 de Clevis génère un JWK, crée un objet dans le MPT avec le JWK en tant que données secrètes, et le lie ou le scelle au MPT. Le JWE résultant (associé à un emplacement de clé LUKS2) contient à la fois les parties sensibles publiques et scellées de l'objet créé, ainsi que des métadonnées liées au descellement. Lors du déchiffrement, la "broche" tpm2 prend le JWE, le charge dans le MPT, descelle le JWK et déchiffre le texte chiffré dans le JWE.

Grâce à cette approche, le trafic SPI du MTP est un peu différent. Ce que nous recherchons est une opération TPM_READ sur TPM_DATA_FIFO_0 (d40024) avec une structure de données consistant en un DWORD avec la valeur 00000072, suivi d'un champ de longueur variable de la taille d'un WORD, suivi d'un tas de données JSON.

Mon plugin Saleae Logic valide le JSON et extrait la clé et les métadonnées pertinentes :

IoT et MPT

Les appareils IoT relèvent souvent du modèle de menace typique " accès physique par un adversaire ", en particulier pour les appareils déployés dans des lieux publics ou lorsque l'utilisateur est un adversaire potentiel. Divers scénarios d'utilisation connexes nécessitent une sorte de fonctionnalité de sous-système de sécurité de confiance, telle que l'authentification des appareils, l'identification, la maintenance sécurisée, l'attestation à distance et la protection des données au repos et en transit.

Bien que de nombreux appareils IoT utilisent des coprocesseurs sécurisés non conformes à la norme TPM, les plateformes AWS et Azure peuvent toutes deux être utilisées pour le provisionnement sécurisé des appareils et la protection des jetons/accréditations.

Comme illustré ci-dessous, l'approche Azure pour Windows 10 IoT Core est assez typique pour ce cas d'utilisation. Ici, une clé d'accès partagée (SAK) est établie entre l'appareil IoT et le cloud pendant le processus de provisionnement en fournissant au cloud les parties publiques de la clé d'endossement (EK) et de la clé racine de stockage (SRK) du TPM. La SAK est imprimée dans le TPM du côté de l'appareil, tandis que du côté du nuage, l'appareil physique est associé à un ID d'appareil dans le concentrateur d'appareils du nuage. Ensuite, un jeton de signature d'accès partagé (SAS) est généré, spécifiant une demande d'accès associée à certaines politiques. Ce jeton est signé par le TPM à l'aide d'un HMAC dont la clé est le SAK.

La mise en œuvre du TPM de Windows 10 IoT Core n'utilise pas non plus le chiffrement des paramètres. En tant que tel, le SAK pourrait être reniflé pendant le provisionnement (ce qui n'est pas un scénario très inquiétant), et les jetons SAS pourraient être reniflés pendant les opérations. Selon le modèle de menace de l'appareil, ce dernier point pourrait poser problème. En outre, un attaquant ayant un accès physique à l'appareil IoT pourrait simplement demander au TPM de signer des données arbitraires, soit en s'interposant sur le bus, soit en retirant complètement le TPM.

La défense contre ces types de menaces dans les appareils IoT est compliquée par le fait que le contrôle d'accès au TPM, sous la forme d'un PIN, est compliqué par le besoin typique d'une interaction utilisateur nulle pendant les opérations (ou d'utilisateurs non fiables tout court). Et le simple fait de stocker le code PIN pour qu'il soit automatiquement saisi par le processeur principal pose le problème de l'œuf et de la poule. Ainsi, deux lignes de défense complémentaires viennent à l'esprit pour les appareils IoT protégés par TPM où l'accès physique est une préoccupation :

• La diversification et la révocabilité. Pour limiter l'impact des secrets compromis, il convient de les diversifier pour chaque appareil lors de l'approvisionnement, de sorte que la compromission d'un seul appareil ne s'étende pas à l'ensemble de la flotte dans le style "pwn-once, exploit everywhere". En outre, les secrets d'authentification doivent être révocables, de sorte que la télémétrie défensive devienne exploitable.

• Résistance à la falsification. Étant donné que les MPT ne peuvent pas être connectées directement à des interrupteurs d'autoprotection externes, elles doivent être intégrées dans un sous-système protégé où l'activation de l'interrupteur d'autoprotection déclenche immédiatement l'effacement du secret de la MPT. Dans l'idéal, l'activation de l'interrupteur d'autoprotection déclenche également des alertes au niveau du backend afin que les Processus de révocation puissent être lancés.

Considérations pour les Red Teaming

Mener une attaque de reniflage de TPM en pratique n'est pas tout à fait la même chose que de le faire dans des conditions de laboratoire. Les attaques par reniflage de TPM contre des solutions FDE peuvent constituer un outil puissant dans l'arsenal d'une Red Team et s'inscrivent dans un large éventail de modèles de menaces tels que les attaquants physiques ayant un accès sur site, les ordinateurs portables volés ou sans surveillance, les initiés malhonnêtes et l'interdiction de la chaîne d'approvisionnement. Néanmoins, tous ces scénarios ont en commun le fait que la fenêtre dans laquelle les opérateurs du Red Teaming peuvent exécuter leur attaque est limitée. Une certaine mesure de furtivité est nécessaire - à ce titre, entrer complètement à l'aveugle et tâtonner pendant une demi-heure alors que vous aviez prévu de laisser un ordinateur portable réassemblé à la hâte derrière vous peut rendre tout cela plus difficile à réaliser en pratique qu'il ne l'est pour des raisons purement techniques.

Il ne sera pas facile de neutraliser un facteur supplémentaire dans la pratique. Néanmoins, les attaques de type "tamper-and-revert" basées sur les kits de démarrage et le fait de laisser un minuscule implant matériel doté de capacités de reniflage de bus sur la carte mère constituent deux voies possibles. En pénétrant dans le facteur additionnel et en décachetant le secret TPM, l'implant pourrait soit le stocker en vue d'une récupération physique ultérieure, soit l'exfiltrer via une capacité de communication intégrée (RF, 4G, etc.) en fonction de l'espace disponible et des capacités de miniaturisation. Trammell Hudson a présenté un excellent exposé sur ce sujet pour un cas d'utilisation connexe lors de la conférence 35C3.

Recommandations défensives

De nombreux conseils défensifs solides sur ce sujet sont disponibles, notamment auprès de Microsoft[1],[2], mais de manière générale, le renforcement des solutions FDE basées sur le TPM se résume aux principes suivants :

• Déployez un facteur supplémentaire tel qu'un code PIN, un mot de passe ou un TOTP pour réguler le descellement du TPM.
• Utilisez un fTPM au lieu d'un dTPM si possible.
• Configurez le TPM pour l'intégration de l'amorçage mesuré dans la configuration FDE afin de le protéger contre les menaces liées au micrologiciel.
• Déployez des scellés de sécurité inviolables sur les dispositifs sensibles (bien que le degré d'aide varie considérablement).

Et maintenant ?

Vous souhaitez en savoir plus sur nos services de Red Teaming ou d'évaluation de la sécurité après avoir lu ce blog ? N'hésitez pas à nous Contactez-nous.