et où as-tu lu que la clé endorsing était copiable ou meme modifiable ? moi j'ai lu qu'il y en avait une seule par puce TCPA et qu'il était juste désactivable. Par conséquent mon raisonement tiens toujours.
La clef endorsment ne peut pas sortir de la puce, elle sert a generer des CA. Je peux generer autant de CA que je veux et cette technique n'est pas inversible.(ie on ne peut pas deduire ma clef de mon CA).
moi j'ai lu qu'il fallait passer par un organisme agréé par TCPA pour obtenir un CA, et qeu cela nécessite l'identification de la clé endorsing et donc ton identification. L'organisme peut donc savoir qui a quel CA.
Presque, il faut passer par le constructeur pour faire changer (ou creer vu que cette clef n'est pas forcement presente) la cle d'endorsment. IBM n'a jamais cree une seule de ces clefs dans son implementation. En ce qui concerne les CA, tu peux en creer a l'infini avec ta clef.Tu ne fais que les faire valider par un organisme, qui ensuite certifie ton ta clef.(cf page 278/section 9.3 du doc TCPA) Le seul et unique vrai probleme vient du fait que tu peux te retrouver a envoyer un CA a une personne qui connais ta clef d'endorsing (ie le constructeur de ton PC ou de ta puce). Celui ci peut alors 'amuser (si il a du temps a perdre) a comparer toutes les clefs d'endorsment qu'il connait avec ton privacy CA. La on est plus dans un complexite exponentielle et il peut donc faire le match entre ton CA et ton PC. Mais c'est le seul cas "dangereux".
Lit la section 9.2 page 271 sur les relations PRIVEK/PUBEK et les securites qui tournent autour. (PRIVEK = private endorsment key, PUBEK=public endorsment key)
Où as-tu lu que le mode extend ne sera pas forcé ? (notamment pour pouvoir utiliser certains softs DRM qui exigerait sa présence...)
1)- Un soft DRM ne peut pas exiger la presence du mode extend. Il peut tester une clef par challenge et voir si elle est disponible ou pas. C'est tout.
2)- Meme si il pouvait forcer le mode extend, rien ne lui indiquerait qu'il s'agit d'un OS DRM, a moins de rentrer des informations supplementaires dans la puce avant de la vendre.
3)- extraits de la doc (divers endroits)
BOOL TPMpost TRUE: the TPM MUST successfully complete
TPM_SelfTestFull before permitting execution of any
command
The default state is FALSE
BOOL TPMpostLock FALSE: The state of TPMpost MAY be changed.
(DEFAULT)
TRUE: The state of TPMpost MUST NOT be changed.
Hop la, meme si mon TPM n'arrive pas a s'autotester (ie verifier qu'il fonctionne correcteemnt, je peux quand meme booter)(cf P48)
Un petit coup d'oeuil sur la section 4.25 te permettrait de comprendre comment le PCR marche.
et pour finir le plus beau
: BOOL disable The state of the disable flag. See 8.14. The default state is
TRUE
Voila de base il n'y a pas de TPM d'active sur la puce. Alors pour le mode extend....
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
La clef endorsment ne peut pas sortir de la puce, elle sert a generer des CA. Je peux generer autant de CA que je veux et cette technique n'est pas inversible.(ie on ne peut pas deduire ma clef de mon CA).
moi j'ai lu qu'il fallait passer par un organisme agréé par TCPA pour obtenir un CA, et qeu cela nécessite l'identification de la clé endorsing et donc ton identification. L'organisme peut donc savoir qui a quel CA.
Presque, il faut passer par le constructeur pour faire changer (ou creer vu que cette clef n'est pas forcement presente) la cle d'endorsment. IBM n'a jamais cree une seule de ces clefs dans son implementation. En ce qui concerne les CA, tu peux en creer a l'infini avec ta clef.Tu ne fais que les faire valider par un organisme, qui ensuite certifie ton ta clef.(cf page 278/section 9.3 du doc TCPA) Le seul et unique vrai probleme vient du fait que tu peux te retrouver a envoyer un CA a une personne qui connais ta clef d'endorsing (ie le constructeur de ton PC ou de ta puce). Celui ci peut alors 'amuser (si il a du temps a perdre) a comparer toutes les clefs d'endorsment qu'il connait avec ton privacy CA. La on est plus dans un complexite exponentielle et il peut donc faire le match entre ton CA et ton PC. Mais c'est le seul cas "dangereux".
Lit la section 9.2 page 271 sur les relations PRIVEK/PUBEK et les securites qui tournent autour. (PRIVEK = private endorsment key, PUBEK=public endorsment key)
Où as-tu lu que le mode extend ne sera pas forcé ? (notamment pour pouvoir utiliser certains softs DRM qui exigerait sa présence...)
1)- Un soft DRM ne peut pas exiger la presence du mode extend. Il peut tester une clef par challenge et voir si elle est disponible ou pas. C'est tout.
2)- Meme si il pouvait forcer le mode extend, rien ne lui indiquerait qu'il s'agit d'un OS DRM, a moins de rentrer des informations supplementaires dans la puce avant de la vendre.
3)- extraits de la doc (divers endroits)
BOOL TPMpost TRUE: the TPM MUST successfully complete
TPM_SelfTestFull before permitting execution of any
command
The default state is FALSE
BOOL TPMpostLock FALSE: The state of TPMpost MAY be changed.
(DEFAULT)
TRUE: The state of TPMpost MUST NOT be changed.
Hop la, meme si mon TPM n'arrive pas a s'autotester (ie verifier qu'il fonctionne correcteemnt, je peux quand meme booter)(cf P48)
Un petit coup d'oeuil sur la section 4.25 te permettrait de comprendre comment le PCR marche.
et pour finir le plus beau
:
BOOL disable The state of the disable flag. See 8.14. The default state is
TRUE
Voila de base il n'y a pas de TPM d'active sur la puce. Alors pour le mode extend....
Kha