Bonne façon d'utiliser le TPM pour le chiffrement complet du disque
Je configure actuellement un équivalent BitLocker à l'aide d'un TPM et de LUKS. J'ai les bases et je peux mesurer le processus de démarrage et sceller la clé FDE à l'aide du TPM.
Chaque fois que les parties sensibles (firmware, bootloader, noyau) sont mises à jour, la commande suivante est utilisée pour sceller la clé de cryptage au nouvel état du système:
tpm_sealdata -p 0 -p 1 ... -p 11 -p 13 -i <keyfile> -o <sealed keyfile>
Lorsque le système démarre, les éléments suivants sont utilisés pour desceller la clé qui est ensuite transmise à LUKS pour monter le volume chiffré:
tpm_unsealdata -i <sealed keyfile> -o <temporary keyfile stored in RAM>
Cela fonctionne et a le comportement souhaité - si le processus de démarrage a été falsifié (disons en ajoutant init=/bin/sh à la ligne de commande du noyau pour contourner un mot de passe root) le TPM refuse de desceller la clé et le système est donc sûr.
Cependant, j'ai quelques questions:
Tout d'abord, le TPM requiert le mot de passe SRK chaque fois qu'une opération de scellage/descellage est effectuée. Je voudrais éviter cela et le faire se comporter comme BitLocker qui est transparent et ne demande rien. J'ai pensé à utiliser un mot de passe SRK par défaut mais apparemment, ce n'est pas sûr , mais les réponses ne disent pas si un attaquant sachant que le mot de passe peut desceller une clé si les PCR ne correspondent pas à l'état dans lequel ils étaient lorsque la clé a été scellée.
Une autre question est de savoir comment dois-je utiliser pour sceller les clés - ma façon implique tpm_sealdata/tpm_unsealdata mais un autre projet tpm-luks utilise tpm-nvread/tpm-nvwrite au lieu. Je voudrais connaître les différences et savoir si une voie est plus sûre que l'autre.
Tout d'abord: AUCUN système n'est sûr à 100%, mais l'utilisation de TPM est meilleure que pas de TPM du tout. La puce TPM est juste une sorte de stockage crypté, qui réside sur la carte mère des ordinateurs qui prennent en charge Trusted Platform Environment, et dont les BIOS sont préparés pour le gérer.
Les PCR sont des registres avec des fonctions spécifiques qui sont gérées par l'opération TPM_Extend. Ils ne peuvent pas être "définis", seulement étendus (new_hash old_hash || new_measurement]).
Le module de plateforme sécurisée a une racine de confiance statique pour les mesures (SRTM) et une racine de confiance dynamique pour les mesures (DRTM), et la combinaison des deux crée l'environnement sécurisé. Ce gars explique très bien comment cela se fait. Il s'agit d'une chaîne de confiance entre les éléments fixes et dynamiques.
De retour aux PCR, ce sont des registres indépendants de la plateforme, et les plus courants sont:
PCR 0 to 3 for the BIOS, ROMS...
PCR 4 - MBR information and stage1
PCR 8 - bootloader information stage2 part1
PCR 9 - bootloader information stage2 part2
PCR 12 - all commandline arguments from menu.lst and those entered in the Shell
PCR 13 - all files checked via the checkfile-routine
PCR 14 - all files which are actually loaded (e.g., Linux kernel, initramfs, modules...)
PCR 15 to 23 are not used
Les ordinateurs portables basés sur Intel utilisent généralement les 16 premiers registres, mais il pourrait être étendu à d'autres logiciels/utilisations.
Lors de l'écriture d'informations (scellage) dans TPM, vous pouvez ajouter une clé racine de stockage (SRK) qui est en quelque sorte une "clé de gestion" et est utilisée pour ajouter d'autres clés à ce stockage. Selon pages de manuel , l'utilisation de -z Définira TSS_WELL_KNOWN_SECRET (20 zero bytes).
-z, --well-known
Use TSS_WELL_KNOWN_SECRET (20 zero bytes) as the SRK password.
You will not be prompted for the SRK password with this option.
Ainsi, avoir ce SRK défini sur le secret par défaut (TSS_WELL_KNOWN_SECRET) Ne sera pas suffisant pour attaquer quelqu'un puisque le TPM ne peut être descellé que si les PCR actuels correspondent à ceux utilisés pour sceller les données. En outre, une partie de la manipulation de la PCR se produit au moment du démarrage (BIOS) et il est très difficile de les manipuler et donc de créer de "faux" PCR. Le BIOS est le seul endroit où les PCR sont considérés comme des zéros avant la fin du processus.
La seule attaque FEASABLE est celle qui vise à MITM les communications entre le BIOS et la PCR vers des zéros PCR sans redémarrer la machine pour mettre le système en état "de confiance". Cette attaque est connue sous le nom de TPM Reset Attack .
L'attaque
Donc, compte tenu de tout ce que nous avons vu ci-dessus, il devrait être très difficile de simuler un processus de démarrage fiable, tant que le BIOS prend les premières mesures. L'hypothèse critique ici est que les PCR ne peuvent pas être facilement réinitialisés sans redémarrer toute la plate-forme sur laquelle réside le TPM. Si un attaquant est capable de surveiller les mesures envoyées aux PCR par le BIOS (avec, par exemple, un analyseur logique, voir ce document), et capable de mettre à zéro les PCR sans redémarrer la machine, alors il pourrait prendre une plate-forme dans n'importe quel configuration et le mettre dans un état "de confiance". Donc, la partie difficile est de réinitialiser le TPM sans faire tomber toute la machine. Il convient de mentionner que nous avons également examiné la possibilité d'interposer de la mémoire et d'autres choses de ce type pour modifier le système en cours d'exécution une fois qu'il a été mesuré, mais en raison de la vitesse des bus sur lesquels la mémoire et les disques durs sont installés, il s'agit d'une entreprise délicate. Attaquer un bus plus lent est beaucoup plus facile.
Les modules TPM résident généralement sur le bus Low Pin Count (LPC). Le bus LPC prend en charge une ligne de réinitialisation entraînée au sol. Cela signifie que lorsque cette ligne particulière du bus est mise à la terre, chaque appareil sur ce bus est censé se réinitialiser. Les autres périphériques connectés à ce bus incluent le BIOS et les contrôleurs de clavier et de souris hérités. La vidéo ci-dessous montre que conduire cette ligne est en effet possible et assez facile à faire. Veuillez noter que dans la vidéo, nous accédons à l'ordinateur en question via une session ssh à distance. En effet, le contrôleur du clavier et de la souris est réinitialisé lorsque nous conduisons la broche de réinitialisation, mais pas la carte réseau. Plus de détails sur cette attaque (et d'autres!) Peuvent être vus dans ma thèse de spécialisation: une évaluation de la sécurité des modules de plate-forme sécurisée, rapport technique TR2007-597 du Dartmouth College Computer Science.
Notez que == [- ceci est une version simplifiée à outrance de TOUTES LES CHOSES qui impliquent le Trusted Computing. Veuillez consulter le Document d'architecture de TPMv2 pour obtenir plus d'informations sur toutes les opérations qui se produisent entre le bios, le matériel et les logiciels lors de la configuration d'un environnement de confiance.
tl; dr : L'utilisation de la clé racine de stockage par défaut (20 octets zéro) n'est pas suffisante pour créer un système non sécurisé.
Contenu connexe: