Quelles sont les similitudes et les différences fonctionnelles entre TPM et SGX dans l'informatique de confiance?

Question

Je connais le TPM (Trusted Platform Module). Ces dernières années, de plus en plus de chercheurs ont commencé à développer sur Intel SGX, avec lequel je n'ai aucune expérience.

Ce sont deux puces cryptographiques, mais quelles sont leurs similitudes et différences fonctionnelles?
Qu'est-ce que SGX peut réaliser que le TPM typique ne peut pas?

(Si vous le souhaitez, expliquez-le en version "manuel" ou en version "pratique".)

forest · Accepted Answer

Eh bien tout d'abord, SGX n'est pas une puce cryptographique. C'est une fonctionnalité intégrée aux chipsets Intel eux-mêmes, alors que le TPM est souvent une puce discrète positionnée sur le bus LPC , bien que parfois il puisse être émulé dans le chipset (auquel cas il s'appelle fTPM, pour le firmware) TPM, ou iTPM, pour TPM intégré). Sur les processeurs Intel, un TPM intégré sera présent pour tout système prenant en charge TXT .

Module de plateforme sécurisée (TPM)

Le TPM est conçu pour permettre démarrage mesuré , un processus de démarrage où chaque étape vérifie l'étape suivante dans une chaîne de confiance , réduisant ainsi Trusted Computing Base (TCB) à une quantité de code beaucoup plus petite. La façon dont cela fonctionne consiste à obtenir un hachage de diverses données liées au firmware et à les stocker dans des PCR (registres dans le TPM) et descellage une valeur secrète si cela correspond à une configuration connue. Tout commence par le CRTM de confiance (Core Root-of-Trust for Measurement), qui est généralement un composant en lecture seule du BIOS qui envoie un hachage du BIOS lui-même au TPM. Si le CRTM et le TPM sont approuvés, le reste du système n'a pas besoin d'être approuvé.

Un module de plateforme sécurisée ne peut pas agir sur les violations d'intégrité détectées. Il est entièrement passif, n'existant que sur le bus LPC. Tout ce qu'il peut faire en réponse à une violation, c'est refuser de se desceller. Cette valeur secrète peut être quelque chose comme une clé de chiffrement nécessaire pour démarrer le système, ou une chaîne secrète inconnue des attaquants, vous permettant de vérifier que le TPM a vraiment été descellé même s'il vous le communique sur un support non fiable. Le TPM contient également un Endorsement Key , ou EK, qui le vérifie comme un véritable TPM. Seuls les TPM authentiques et approuvés recevront cette clé. Ceci est similaire à l'infrastructure PKI pour HTTPS où une autorité de certification permet à un navigateur de vérifier la légitimité de la connexion à un serveur.

TPM fournit les garanties suivantes à un administrateur système:

Le TPM résistera aux tentatives de falsification (par exemple, les attaques de décapage et de glitching).
L'administrateur système pourra vérifier que le module de plateforme sécurisée est authentique.
Le module de plateforme sécurisée ne se descellera que lorsque les valeurs de hachage du processus de démarrage sont correctes.
Une clé peut être définie pour que le module de plateforme sécurisée ne descelle pas à moins que les PCR soient valides et la clé est fournie.

Le TPM ne se limite pas à être descellé au démarrage. Il peut être descellé à tout moment. Comme un démarrage vérifié peut également vérifier des applications de l'espace utilisateur, un TPM peut même être utilisé, indirectement, pour attester du fait qu'un système exécute un logiciel donné ou est configuré d'une manière spécifique. Une fois le BIOS, le chargeur de démarrage et le noyau vérifiés, il peut vérifier que le système est dans un état arbitraire, par exemple, dispose d'un logiciel à jour. Ce n'est que lorsque tout cela est dans un état valide que le module de plateforme sécurisée se descellera lui-même, lui permettant de prouver aux clients qu'il est à jour et sécurisé. Ceci est appelé attestation à distance , qui peut lui-même être utilisé comme un bloc de construction pour contrôles d'accès au résea .

Notez que ceci est un peu une simplification de la fonctionnalité d'un TPM, et qu'il n'entre pas dans le différences entre SRTM et DRTM (Racine de confiance statique et dynamique pour la mesure, respectivement), mais il devrait être suffisant pour décrire la fonctionnalité générale du système.

Extensions Software Guard (SGX)

SGX a un objectif de conception différent et est un bon bit plus complexe . SGX peut assurer la confidentialité et l'intégrité des processus et peut vérifier le code exécutable avant de l'exécuter. Il s'agit d'une fonction active qui chiffre les processus en cours d'exécution dans une enclave sécurisée tout en les protégeant. Les processus savent que l'enclave est authentique, l'empêchant d'être usurpé par émulation, et l'enclave sait que le processus est authentique, empêchant l'hôte non fiable de lui donner un processus compromis.

L'enclave sécurisée ne peut même pas être lue par le noyau ou toute autre tâche privilégiée une fois qu'elle est configurée. Pour cette raison, un processus exécuté dans une enclave sécurisée peut, au pire, être tué ou faire planter. Il ne peut pas être altéré (même avec JTAG, car le mode de sonde est désactivé dans le contexte SGX, ou du moins on me dit). Cela peut être utilisé pour des choses comme l'exécution d'un invité de machine virtuelle qui n'a pas besoin de faire confiance à l'hôte.

SGX offre les garanties suivantes à un processus s'exécutant dans une enclave sécurisée:

Le processus pourra vérifier qu'il s'exécute sur un SGX authentique.
L'hôte ne peut pas altérer le processus une fois qu'il s'exécute dans l'enclave.
Le processus arrive à définir une API d'E/S pour communiquer avec les processus sur l'hôte.
L'état du processus n'existera jamais en texte clair en mémoire.
Le processus sera vérifié avant d'être exécuté, garantissant qu'il est légitime.

En règle générale, une application utilisant SGX doit être conçue spécifiquement à cette fin. La demande serait écrite pour avoir deux composants. Le premier composant s'exécuterait non confiné sur l'hôte, tandis que le second s'exécuterait dans une enclave sécurisée. Une API d'E/S est définie pour permettre aux deux composants de communiquer entre eux. Tout calcul sensible peut être déchargé sur le processus dans l'enclave sécurisée.

Bien que SGX protège l'enclave de l'hôte, il ne fait pas grand-chose pour protéger l'hôte de l'enclave. Un processus d'enclave malveillant ou compromis pourrait quitter l'enclave et exécuter du code arbitraire sur l'hôte. Cela est dû au fait que instruction EEXIT (voir page 67) , qui quitte l'enclave, ne restaure qu'un nombre limité de registres. En particulier, il permet au processus d'enclave de définir RIP, le pointeur d'instruction et d'accéder à une adresse arbitraire.

Similitudes

Le TPM vous indique simplement si votre micrologiciel ou votre processus de démarrage a changé, et rien de plus, tandis que SGX est plutôt utilisé pour protéger les processus sensibles ou confidentiels de l'hôte. Une similitude entre TPM et SGX est qu'ils ne peuvent pas tous les deux être usurpés, ce qui permet à un système de savoir qu'il parle à la vraie affaire. Un autre est qu'ils sont tous deux impliqués dans le concept de informatique de confiance, réduisant le TCB d'un système de diverses manières. Les deux systèmes ont leur propre ensemble de défauts. TPM version 1.1 et antérieure est vulnérable à la attaque de réinitialisation de plate-forme , par exemple. SGX est vulnérable aux attaques par canal latéral, comme deux papiers l'ont récemment montré.

En dehors de cela, ils sont très différents et ils résolvent des problèmes entièrement différents .