TPM, certificats et chiffrement (principes et fonctionnement)

Introduction

Cet article a pour but de présenter les principes du TPM ainsi que les liens qui peuvent exister entre le TPM et le stockage des clés de chiffrement.

Qu’est-ce que le TPM et son rôle ?

Description

En premier lieu TPM est l’acronyme de « Trusted Platefom Module ».
La définition telle qu’elle est donnée par le TCG est la suivante : « Un TPM est un composant système indépendant disposant de son propre état par rapport au système hôte. L’unique interaction entre ces deux systèmes se fait par le biais d’un bus de communication défini dans la norme TPM. »

Un TPM peut être un composant physique à part entière ou bien rattaché directement au processeur mais s’exécutant dans un espace bien défini de sorte qu’il ne soit pas accessible par le système d’exploitation hôte et que le seul canal d’accès soit le bus de communication défini plus haut.

Ce composant a plusieurs usages tous liés à la confidentialité des éléments qu’il contient et, en particulier, à la protection de secrets tels que :

  • La génération de clés privées ;
  • Le stockage sécurisé de ces mêmes clés ;
  • La gestion des secrets type certificat machine/utilisateurs.

Une puce TPM est ainsi compartimentée en modules indépendants, interopérables entre eux et tous spécialisés, comme le montre le schéma ci-dessous :

alt

Fonctionnement

Le fonctionnement d’un TPM repose sur le mécanisme de « Root Of Trust » pouvant être comparé à la chaîne de confiance dans les autorités racines générant des certificats publics. Seuls les fabricants de puces TPM disposent des éléments nécessaires à la génération de ces clés « racines » ou « root » gravés de manières physique et unique sur chaque TPM.
En effet chaque TPM dispose lors de sa fabrication d’un couple de clé privée/publique (appelé Endorsement Key ou EK) permettant la réalisation de toutes les opérations cryptographiques futures. Un certificat émis par une autorité de certification que le fabricant de TPM est le seul à posséder peut aussi y être intégré pour valider que l’EK est bien générée par le fabricant lui-même.

alt

Etats du TPM

Par défaut, lors de la fabrication un TPM est livré désactivé par le constructeur. Plusieurs opérations sont nécessaires afin que celui-ci soit pleinement fonctionnel.
Ci-dessous la liste des différents états possibles :

alt

Suivant les fournisseurs d'ordinateurs, un TPM peut être préparé dans l'état enabled/disable ainsi que Activated/Non activated. Ces deux opérations de mise sous tension et d'activation sont aussi configurables au travers du BIOS (ou UEFI selon le modèle et la version).
L'étape du « Ownership » se fait au travers du système d'exploitation.
Les différents états et interactions possibles sont décrits dans les documents suivants :

TPM 1.2 vs 2.0

Deux versions cohabitent actuellement. TPM 1.2 est la version historique alors que la 2.0 est sa version révisée. Cette version révisée apporte notamment les améliorations suivantes :

  • Support de nouvelles suites cryptographiques ;
  • Amélioration de la compatibilité avec les applications ;
  • Simplification du management : Ownership automatique par le système d’exploitation ;
  • Amélioration des politiques d’autorisation : HMAC 1.2, Présence physique, PCR.

Focus : Verrouillage du TPM (lockout)

Des mécanismes anti brute-force sont présents dans les TPM et certaines clés peuvent être protégées par une sécurité additionnelle tel qu’un code PIN ou mot de passe afin d’y accéder. Si les deux versions implémentent ce mécanisme, toutes deux ne l’implémentent pas de la même manière.

  • TPM 1.2 : Implémentation assez libre par les constructeurs (réponses très longues après X essais, augmentation du délai de réponse en fonction du nombre de question,)
  • TPM 2.0 : implémentation plus rigoureuse mais laissée libre aux éditeurs de systèmes d’exploitation avec les prérequis suivants : Blocage au bout de X tentatives et mécanisme d’auto déverrouillage.

Par exemple Microsoft a défini la norme suivante au sein de ses systèmes d’exploitation :

  • Verrouillage du TPM au bout de 32 tentatives
  • Chaque tentative infructueuse est décrémentée toutes les deux heures (soit 64 heures pour revenir à un état normal)

Clés et hiérarchie

Le TCG a défini dans les normes TPM une hiérarchisation bien établie dans l’usage et la création des clés afin de garantir un niveau maximal de sécurité.
Les différents types de clés sont les suivantes :

  • EK : bi-clef physiquement inscrite dans le TPM lors de sa conception par le fabricant. Ne quitte jamais le TPM et ne peut être effacée.
  • SRK : clé dérivée de EK et créée dans la phase « Owned » d’initialisation du TPM. Cette clé ne quitte jamais le TPM et est utilisée pour chiffrer/déchiffrer les autres clés enfants générées.
  • AIK : clé utilisée pour effectuer les opérations de signature permettant de vérifier que la clé tierce générée l’a bien été au sein d’un TPM.
  • Storage Keys : Clés utilisées dans des buts divers : chiffrement, Certificats, …

alt

Focus SRK

La clé SRK est utilisée de manière à sécuriser toutes les clés enfants créées en chiffrant leur partie privée via sa clé publique avant de les laisser être exportées vers l’application ou le programme qui a demandé la clé.

Ci-dessous le schéma décrivant la cinématique de chiffrement :

alt

Cette cinématique induit forcément que la clé K0 ne peut être déchiffrée qu’à l’intérieur du TPM et avec la clé privée SRK priv.

Ci-dessous le schéma décrivant la cinématique de déchiffrement :

alt

Mécanismes d’attestation de clé

L’attestation de clé est un mécanisme visant à prouver que la clé publique/privée générée l’a bien été à partir d’un TPM. La manière cryptographique permettant d’y arriver est liée au processus de création de AIK ainsi qu’à son utilisation en tant que clé de signature.
Les mécanismes d’attestation de clés sont très majoritairement utilisés par les PKI. Cela permet de s’assurer, par exemple, que la demande de signature d’un certificat provient bien d’un TPM. Une fois les vérifications effectuées, la PKI peut apposer sur le certificat des OID spécifiques pouvant servir à un contrôle ultérieur (cela peut être assimilé à un « tampon de validation »).

Types d’attestation de clé possible

Plusieurs types d’attestation de clé sont possibles :

  • Attestation par contrôle de l’identité de l’utilisateur ;
  • Attestation par contrôle du certificat émis par le fabricant du TPM ;
  • Attestation par contrôle de la clé publique du TPM.

Tous ces contrôles offrent des degrés de confiance sur l’attestation qui en est faite par la PKI et sont détaillés ci-dessous.

alt

Processus complet de génération d’un certificat issue d’un TPM

D’un point de vue purement technique plusieurs étapes sont nécessaires à la génération d’un certificat provenant d’un TPM. Prenons l’exemple d’un certificat utilisateur devant être sécurisé par le TPM et devant être attesté comme tel.

La liste de ces étapes est décrite ci-dessous :

alt

  1. Génération des clés : Le TPM génère la paire de clé Privée/publique nommée K0
  2. Signature clés TPM : La clé privée AIK est utilisée pour réaliser la signature de la clé K0
  3. Requête CSR : La demande de signature contient plusieurs clés permettant la vérification de la demande par la CA
  4. Attestation de clé : La CA valide par le mécanisme choisi dans le Template que la clé publique provient bien d’un TPM
  5. Validation de la signature : Mécanisme classique de la vérification de l’intégrité de la clé publique K0
  6. Challenge : La CA envoie un challenge au TPM permettant de vérifier qu’il dispose bien de la clé privée associée à la clé publique émise.
  7. Signature : Le CSR est signé par la CA, devient un certificat et est envoyé au client.

alt

Remarque : Toutes ces opérations ne transitent pas en clair sur le réseau mais utilisent une session de communication sécurisée en TLS.

Processus complet de boot BitLocker avec TPM

Un autre exemple mettant bien souvent en jeu le TPM est le chiffrement des postes Windows via BitLocker. Le chiffrement de poste s’appuyant sur un mécanisme de chiffrement symétrique (Même clé qui est utilisée pour réaliser le chiffrement et le déchiffrement) la clé secrète utilisée pour le chiffrement/déchiffrement peut être stockée dans le TPM.

Le chiffrement des données via BitLocker se base sur deux types de clés :

  • Clé de chiffrement des volumes de données (FVEK) : Cette clé est utilisée pour le chiffrement des données et est stockée de manière sécurisée sur la partition de démarrage.
  • Clé maîtresse du Volume (VMK) : Cette clé est utilisée pour sécuriser l’accès à FVEK.

alt

Ainsi le démarrage du système protégé par les mécanismes BitLocker avec les protecteurs TPM + PIN suit les étapes suivantes :

  1. Démarrage du poste : Mise sous tension du poste, chargement des composants de boot
  2. Validation des PCRs : Activation de la TPM, vérification de l’intégrité des éléments de démarrage (PCR)
  3. Demande du code PIN : une fois la validation des différents PCRs effectuée, demande du code PIN à l’utilisateur
  4. Relâchement VMK : Si le PIN est valide, le TPM utilise la clé SRK pour déchiffrer le clé VMK et la rend au système.
  5. Déchiffrement FVEK : La clé VMK récupérée est utilisée par le système de démarrage pour déchiffrer la clé FVEK
  6. Déchiffrement des données : La clé FVEK est utilisée pour déchiffrer les données nécessaires au démarrage et au chargement du système.
  7. Signature : le système est démarré et déverrouillé. Les données sont disponibles pour les applications et déchiffrées puis à nouveau chiffrées grâce à FVEK.

Ressources

TPM lockout sur le Blog Technet Microsoft

Attestation de clé/PKI Windows sur le Technet Microsoft

BitLocker1 : https://technet.microsoft.com/en-us/library/cc162804.aspx et Bitlocker2 : https://technet.microsoft.com/en-us/library/cc732774(v=ws.10).aspx