Je m'entete parceque tu lis les specs de travers. Que ce que tu decris est completement irrealisable en l'etat avec TCPA, que je te l'ai deja demontre 10 fois et que tu continue a poster ton doc dans tous les sens alors qu'il est a peu pres aussi faux que possible.
The creator of the key can prevent migration by the User by wrapping it with a non-migratable storage key and loading random data for the MigrationAuthorizationData.
Je ne vois pas ce que ca a faire avec le fait que
1) seules les clefs generes par le TPM peuvent etre passees en non migrables
2) Une fois qu'une clef est non migrable elle ne peut plus etre utilisee que par la puce.
Le mecansime que tu decris est ce qui se passe quand le createur de la clef donne des droits a un utilisateur sur une clef sans pour autant lui donner la clef en elle meme.
Grosso modo je cree un repertoire, je pose ma clef dedans, je donne les droits sur ma clef a un utilisateur et je crypte mon repertoire avec une clef non migrable.
Cependant toutes les entites parentes de ce repertoire ont les droits sur ce repertoire et peuvent migrer ma clef si ca les amuse et si le possesseur du TPM donne son feu vert.
Dans tous tes commentaires tu sembles supposer que le "owner" du TPM est forcément le possesseur de la mcahine, alors que les specs n'interdisent pas à un OS comme Windows d'être ce owner. D'ailleurs si les applications DRM de Win exigent que Win soit owner, on devra laisser owner à Win pour pouvoir utiliser ces applications.
N'importe quoi en folie ! Bien que la puce TCPA soit relativement evoluee, si windows a les droits en owner sur le TPM ou sur le SRK alors je les ai aussi. On dialogue avec le TPM via un port serie pour se loguer en tant que owner TPM ou SRK il faut connaitre le mot de passe. Alors de deux choses l'une : soit tous les TPM et tous les SRK de toutes les puces TCPA ont le meme mot de passe (et la bravo pour la securite) soit les puces sont initialises avec des mots de passe different et windows ne peut pas le deviner (2048 bits a casser ca prend du temps). Et donc le brave windows pour pouvoir utiliser les fonctions TCPA il est oblige de me demander le mot de passe. Et la le plus beau c'est qu'il n'a aucun moyen de savoir si je lui donne les bons. Il n'y a pas de verification possible. Il est assez facile de savoir si on est vraiment le TPM owner ou pas, mais il est impossible de savoir si on a acces au SRK ou a un sous repertoire, donc ton programme qui exige le ownership il va avoir du mal. A noter en plus que toutes ces protections (dans le cas ou on ne met pas exactement le meme mot de passe sur toutes les puces) doivent se faire en logiciel, comme la securite d'un systeme est egale a la securite du plus faible de ses maillons, on a une securite de niveau logiciel et donc TCPA n'aide pas.
Pourquoi t'entêtes-tu alors que le site officiel TCPA possede des documents affirmant haut et fort que le but est bien de permettre à un fournisseur de contenu distant d'identifier les logiciels de ta machine afin de choisir s'il décide de faire confiance ou non à ton OS (grace aux checksums de l'OS par TCPA créés lors du boot):
C'est bien mon petit, maintenant apprend l'anglais et relit ta citation . C'est bon tu vois le probleme ? Non ? Bon je t'aide :
These digests are statistically unique indications of the platform environment, yet they will occur in all platforms with the same software environment. Based upon the reported integrity metrics, the challenger can determine if the platform is configured in a trusted state.
Ca ne permet pas d'identifier le software, ca permet juste de verifier que le systeme est bien celui que l'on connait et a qui on fait confiance. Mais il est impossible de savoir ce que c'est. C'est le principe du MD5, avec tu peux savoir que le fichier que tu as telecharge a cote contient bien les bonnes donnees. Mais tu ne peut pas telecharger juste le MD5 et en deduire le fichier original. De la meme facon impossible d'utiliser un DIR ou un PCR pour identtifier un logiciel.
[^] # 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é à 0.
The creator of the key can prevent migration by the User by wrapping it with a non-migratable storage key and loading random data for the MigrationAuthorizationData.
Je ne vois pas ce que ca a faire avec le fait que
1) seules les clefs generes par le TPM peuvent etre passees en non migrables
2) Une fois qu'une clef est non migrable elle ne peut plus etre utilisee que par la puce.
Le mecansime que tu decris est ce qui se passe quand le createur de la clef donne des droits a un utilisateur sur une clef sans pour autant lui donner la clef en elle meme.
Grosso modo je cree un repertoire, je pose ma clef dedans, je donne les droits sur ma clef a un utilisateur et je crypte mon repertoire avec une clef non migrable.
Cependant toutes les entites parentes de ce repertoire ont les droits sur ce repertoire et peuvent migrer ma clef si ca les amuse et si le possesseur du TPM donne son feu vert.
Dans tous tes commentaires tu sembles supposer que le "owner" du TPM est forcément le possesseur de la mcahine, alors que les specs n'interdisent pas à un OS comme Windows d'être ce owner. D'ailleurs si les applications DRM de Win exigent que Win soit owner, on devra laisser owner à Win pour pouvoir utiliser ces applications.
N'importe quoi en folie ! Bien que la puce TCPA soit relativement evoluee, si windows a les droits en owner sur le TPM ou sur le SRK alors je les ai aussi. On dialogue avec le TPM via un port serie pour se loguer en tant que owner TPM ou SRK il faut connaitre le mot de passe. Alors de deux choses l'une : soit tous les TPM et tous les SRK de toutes les puces TCPA ont le meme mot de passe (et la bravo pour la securite) soit les puces sont initialises avec des mots de passe different et windows ne peut pas le deviner (2048 bits a casser ca prend du temps). Et donc le brave windows pour pouvoir utiliser les fonctions TCPA il est oblige de me demander le mot de passe. Et la le plus beau c'est qu'il n'a aucun moyen de savoir si je lui donne les bons. Il n'y a pas de verification possible. Il est assez facile de savoir si on est vraiment le TPM owner ou pas, mais il est impossible de savoir si on a acces au SRK ou a un sous repertoire, donc ton programme qui exige le ownership il va avoir du mal. A noter en plus que toutes ces protections (dans le cas ou on ne met pas exactement le meme mot de passe sur toutes les puces) doivent se faire en logiciel, comme la securite d'un systeme est egale a la securite du plus faible de ses maillons, on a une securite de niveau logiciel et donc TCPA n'aide pas.
Pourquoi t'entêtes-tu alors que le site officiel TCPA possede des documents affirmant haut et fort que le but est bien de permettre à un fournisseur de contenu distant d'identifier les logiciels de ta machine afin de choisir s'il décide de faire confiance ou non à ton OS (grace aux checksums de l'OS par TCPA créés lors du boot):
C'est bien mon petit, maintenant apprend l'anglais et relit ta citation . C'est bon tu vois le probleme ? Non ? Bon je t'aide :
These digests are statistically unique indications of the platform environment, yet they will occur in all platforms with the same software environment.
Based upon the reported integrity metrics, the challenger can determine if the platform is configured in a trusted state.
Ca ne permet pas d'identifier le software, ca permet juste de verifier que le systeme est bien celui que l'on connait et a qui on fait confiance. Mais il est impossible de savoir ce que c'est. C'est le principe du MD5, avec tu peux savoir que le fichier que tu as telecharge a cote contient bien les bonnes donnees. Mais tu ne peut pas telecharger juste le MD5 et en deduire le fichier original. De la meme facon impossible d'utiliser un DIR ou un PCR pour identtifier un logiciel.
Kha