Mais techniquement, pour que l'administrateur puisse faire tout ça à distance de façon sûre, on a besoin de EK (rien que pour le TPM_TakeOwnership initial).
Oui, mais c'ets normal. Si je ne susi pas présent physiquement sur la machine, qu'est-ce qui m'assure que c'est bien ma puce TCPA que je viens d'acheter et pas un petit malin qui s'est mis au milieu pour gagner des droits sur le réseau ? Si le PubEK m'a été transmis par le constructeur en même temps que le PC a été livré c'est très simple, sinon c'est impossible sauf à se déplacer.
Ensuite uen fois fait le takeOwnership je peux tranquillement désactiver GetPubEK.
Pourquoi prévoir un mécanisme d'attestation qui permet de rassurer non seulement le Owner, mais aussi un tiers inquisiteur quelconque ?
CF exemple précédent. L'acheteur du PC vérifie qu'ile st ebien en train de dialoguer avec le PC qu'il a acheté, même si il ne l'a pas initialisé lui même.
Pourquoi se donner la peine d'anonymiser les AIK à l'aide d'une "privacy CA", si ce n'est pour faire du DRM sans violer les lois européennes sur la vie privée ? Pour les applications personnelles et en entreprise, l'anonymisation des AIK ne sert à rien.
Pour éviter les recoupements. Si je n'utilsie qu'un seul identifiant, un fournisseur de mêche avec le tiers certifiant pourrait remonter mes habitudes. En créant un certificat par profil/service/fournisseur je rend la tache de tracage impossible. En prime, je peux déplacer mon "Privacy CA" d'un AIK à un autre, pour le DRM c'est un poil pataud...
Pourquoi empêcher le Owner de connaitre le PrivEK de son TPM ? (réponse: ça lui permettrait d'émuler le TPM en logiciel et de contourner le DRM).
Le but du PrivEK ets de certifier que l'on a bien affaire au TPM auquel on pense avoir à faire, et à s'assurer que celui ci n'a pas été compromis. Si on pouvait le sortir l'ensemble de la sécurité du TPM s'éffondrerait. En plus pour contourner le DRM il suffirait de booter dans une autre config, avec un autre logiciel vi que PrivEK est TOUJOURS challengeable, quel que soit les PCR et même si il n'y a pas de owner. On retombe donc dans un bête schéma de protection logiciel.
De même, pourquoi empêcher le Owner de connaitre la partie privée de SRK ? (réponse: en gros, ça lui permettrait d'extraire ou de migrer des clés nécessaires pour déchiffrer des contenus DRM).
Toutes les clefs challengeables de l'extérieur (ie extérieur du TPM) sont déplaceable et copiable à l'intérieur du TPM et vers d'autres TPM. Une fois de plsu comme protection DRM ca fait très léger. PrivSRK ne touche que les clefs internes, lesquelles sont utilisés par le TPM (au sens OS) pour sa cuisine interne. Elle ne sont pas challengeables et donc inutilisables pour le DRM.
Je donne mon PubEK, le constructeur me renvoie 10000 blobs contenant chacun un des PrivEK partagés chiffré avec mon PubEK, j'en choisis un et je l'envoie à mon TPM. Ca règle le problème de traçabilité.
sauf que a) Le constructeur est obligé de me fournir 10000 blobs uniques, sous peine que je choisisse une PrivEK qui a déjà été choisie par quelqu'un d'autre, ce qui serait assez désordre, donc la tracbilité reste. De plus rien ne prouve à mon constructeur que je ne vais utiliser qu'une seule des clefs, je pourrais par exemple garder le blob 127 pour mon tpm et challenger le blob 142 pour récupérer la clef PrivEK142 en clair et l'utiliser dans un émulateur...
Mon constructeur se retrouverait alors à avoir certifié un émulateur. Pas top non plus.
Ah ben voilà, ton boulot chez Vivendi, c'est réussir à implémenter du DRM sur TCPA !!! :-)
Deux ans payé plein pot pour ne rien produire \o/ J'aimerais bien, mais c'est pas le cas.
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Oui, mais c'ets normal. Si je ne susi pas présent physiquement sur la machine, qu'est-ce qui m'assure que c'est bien ma puce TCPA que je viens d'acheter et pas un petit malin qui s'est mis au milieu pour gagner des droits sur le réseau ? Si le PubEK m'a été transmis par le constructeur en même temps que le PC a été livré c'est très simple, sinon c'est impossible sauf à se déplacer.
Ensuite uen fois fait le takeOwnership je peux tranquillement désactiver GetPubEK.
Pourquoi prévoir un mécanisme d'attestation qui permet de rassurer non seulement le Owner, mais aussi un tiers inquisiteur quelconque ?
CF exemple précédent. L'acheteur du PC vérifie qu'ile st ebien en train de dialoguer avec le PC qu'il a acheté, même si il ne l'a pas initialisé lui même.
Pourquoi se donner la peine d'anonymiser les AIK à l'aide d'une "privacy CA", si ce n'est pour faire du DRM sans violer les lois européennes sur la vie privée ? Pour les applications personnelles et en entreprise, l'anonymisation des AIK ne sert à rien.
Pour éviter les recoupements. Si je n'utilsie qu'un seul identifiant, un fournisseur de mêche avec le tiers certifiant pourrait remonter mes habitudes. En créant un certificat par profil/service/fournisseur je rend la tache de tracage impossible. En prime, je peux déplacer mon "Privacy CA" d'un AIK à un autre, pour le DRM c'est un poil pataud...
Pourquoi empêcher le Owner de connaitre le PrivEK de son TPM ? (réponse: ça lui permettrait d'émuler le TPM en logiciel et de contourner le DRM).
Le but du PrivEK ets de certifier que l'on a bien affaire au TPM auquel on pense avoir à faire, et à s'assurer que celui ci n'a pas été compromis. Si on pouvait le sortir l'ensemble de la sécurité du TPM s'éffondrerait. En plus pour contourner le DRM il suffirait de booter dans une autre config, avec un autre logiciel vi que PrivEK est TOUJOURS challengeable, quel que soit les PCR et même si il n'y a pas de owner. On retombe donc dans un bête schéma de protection logiciel.
De même, pourquoi empêcher le Owner de connaitre la partie privée de SRK ? (réponse: en gros, ça lui permettrait d'extraire ou de migrer des clés nécessaires pour déchiffrer des contenus DRM).
Toutes les clefs challengeables de l'extérieur (ie extérieur du TPM) sont déplaceable et copiable à l'intérieur du TPM et vers d'autres TPM. Une fois de plsu comme protection DRM ca fait très léger. PrivSRK ne touche que les clefs internes, lesquelles sont utilisés par le TPM (au sens OS) pour sa cuisine interne. Elle ne sont pas challengeables et donc inutilisables pour le DRM.
Je donne mon PubEK, le constructeur me renvoie 10000 blobs contenant chacun un des PrivEK partagés chiffré avec mon PubEK, j'en choisis un et je l'envoie à mon TPM. Ca règle le problème de traçabilité.
sauf que a) Le constructeur est obligé de me fournir 10000 blobs uniques, sous peine que je choisisse une PrivEK qui a déjà été choisie par quelqu'un d'autre, ce qui serait assez désordre, donc la tracbilité reste. De plus rien ne prouve à mon constructeur que je ne vais utiliser qu'une seule des clefs, je pourrais par exemple garder le blob 127 pour mon tpm et challenger le blob 142 pour récupérer la clef PrivEK142 en clair et l'utiliser dans un émulateur...
Mon constructeur se retrouverait alors à avoir certifié un émulateur. Pas top non plus.
Ah ben voilà, ton boulot chez Vivendi, c'est réussir à implémenter du DRM sur TCPA !!! :-)
Deux ans payé plein pot pour ne rien produire \o/ J'aimerais bien, mais c'est pas le cas.