Reste le probleme de l'accès indirect via des fonctions de déplacement des clés: dans nos discussions KHA a soutenu très fort, contre moi, que il était possible de déplacer toutes les clés (et donc toutes les clés protégées par un PCR sous un autre OS). Voulez-vous bien me confirmer que c'était une erreur et que les clés protégées par un PCR ne sont pas déplacables sous un autre OS (à moins d'utiliser la manipe BACKUP de Kha, dont je ne comprends pas pourquoi le 2e TPM me donnerait à l'accès au données protégées par PCR sous un autre OS).
En fait c'est lie au fonctionnement des fonctions TPM_SEAL et TPM_UNSEAL. Lorsque tu veut faire rentrer des donnees ou des clefs dans un PCR il n'y a pas de cryptage de ces donnees vis a vis du PCR. C'est juste que si tu essaye de sortir les donnees d'un PCR qui ne correspond pas a ton DIR(PCR=sauvegarde, DIR=etat actuel) via un TPM_UNSEAL le TPM refusera. Par contre si ta clef est migrable, tu peux en demander la migration depuis n'importe quel environement.
Il y a deux facon de migrer une clef : par un rewrap (ie deplacer la clef dans une entite parente), ou par un backup(un blob de donnees contenant la clef sort du TPM).
Le prob du rewrap c'ets que c'est un move.On peut s'en servir pour sortir la clef du PCR et la mettre dans une zone publique, avant de refaire une copie dans le PCR(on peut mettre des clef dans n'importe quel PCR, meme si il ne correspond pas a la sequence de boot actuelle).
Seul ennui si on fait ca c'est que windows peut se rendre compte en lisant le "secret" du sceau que l'OS qui a mis la clef dans le PCR n'est pas un OS connu, et donc peut de fait invalider la clef.
C'est pour ca qu'on ets oblige de se frapper une migration complete qui elle fait une copie de la clef ou des donnees, et laisse les donnees actuelles en place. Ce genre de migration ne devant d'apres les specs n'etre possible qu'entre deux TPM, il faut donc un autre TPM....
Voila pour les explications de pourquoi il faut un deuxieme TPM au cas ou windows bloque les fonctions d'acces TCPA.
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 1.
En fait c'est lie au fonctionnement des fonctions TPM_SEAL et TPM_UNSEAL. Lorsque tu veut faire rentrer des donnees ou des clefs dans un PCR il n'y a pas de cryptage de ces donnees vis a vis du PCR. C'est juste que si tu essaye de sortir les donnees d'un PCR qui ne correspond pas a ton DIR(PCR=sauvegarde, DIR=etat actuel) via un TPM_UNSEAL le TPM refusera. Par contre si ta clef est migrable, tu peux en demander la migration depuis n'importe quel environement.
Il y a deux facon de migrer une clef : par un rewrap (ie deplacer la clef dans une entite parente), ou par un backup(un blob de donnees contenant la clef sort du TPM).
Le prob du rewrap c'ets que c'est un move.On peut s'en servir pour sortir la clef du PCR et la mettre dans une zone publique, avant de refaire une copie dans le PCR(on peut mettre des clef dans n'importe quel PCR, meme si il ne correspond pas a la sequence de boot actuelle).
Seul ennui si on fait ca c'est que windows peut se rendre compte en lisant le "secret" du sceau que l'OS qui a mis la clef dans le PCR n'est pas un OS connu, et donc peut de fait invalider la clef.
C'est pour ca qu'on ets oblige de se frapper une migration complete qui elle fait une copie de la clef ou des donnees, et laisse les donnees actuelles en place. Ce genre de migration ne devant d'apres les specs n'etre possible qu'entre deux TPM, il faut donc un autre TPM....
Voila pour les explications de pourquoi il faut un deuxieme TPM au cas ou windows bloque les fonctions d'acces TCPA.
Kha