Dans ton message précédent, au sujet de la certification, tu parlais à la fois de la certification de la signature EK du constructeur, et de l'attestation ("Si tu n'as pas besoin de certifier la véracité de ton identité au reste du monde, créé un clef dans le PCR public.").
Dans le premier cas, c'est le constructeur qui prouve son identité. Le tiers de confiance est une bête autorité de certification, c'est classique.
Dans le second cas, c'est l'utilisateur qui prouve que son PC est "digne de confiance". Les whitepapers du TCG disent explicitement que le tiers de confiance jour un rôle un peu nouveau ("privacy CA").
Si j'ai généré l'AIK moi même (ce qui est le cas en réseau d'entreprise), il me suffit de noter la clef public dans un coin moi même pour avoir un degré de certification égal à celui que j'aurais via EK.
En effet TPM_MakeIdentity a l'air indépendant de TPM_ActivateIdentity. Ca me plait. 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).
Le problème étant qu'il faut que je me fasse confiance à moi même
Pour ça il suffit que l'entreprise ait un service "privacy CA" de confiance, et là on lierait les AIK à EK. Et ça ne me choquerait pas: ça a clairement des avantages pour la sécurité. Ce qui me choque, c'est que le TCG ajoute des fonctions et impose des restrictions qui trahissent l'intention de faire du DRM. Par exemple:
- Pourquoi prévoir un mécanisme d'attestation qui permet de rassurer non seulement le Owner, mais aussi un tiers inquisiteur quelconque ?
- 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.
- 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). OK, ça complique un peu le changement de Owner (le constructeur fournirait un nouveau EK certifié, ça peut se faire à distance).
- 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).
Si il faut un EK valide pour accéder un nouvel EK alors on peut toujours se servir des méccanismes de tracabilité
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é.
Le vrai inconvénient est qu'il faut faire compromis entre le niveau d'anonymat et les dégâts en cas de compromission physique d'un TPM.
et j'ai essayé de la créer moi même. Ca fait deux ans que je m'acharne
Ah ben voilà, ton boulot chez Vivendi, c'est réussir à implémenter du DRM sur TCPA !!! :-)
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Dans ton message précédent, au sujet de la certification, tu parlais à la fois de la certification de la signature EK du constructeur, et de l'attestation ("Si tu n'as pas besoin de certifier la véracité de ton identité au reste du monde, créé un clef dans le PCR public.").
Dans le premier cas, c'est le constructeur qui prouve son identité. Le tiers de confiance est une bête autorité de certification, c'est classique.
Dans le second cas, c'est l'utilisateur qui prouve que son PC est "digne de confiance". Les whitepapers du TCG disent explicitement que le tiers de confiance jour un rôle un peu nouveau ("privacy CA").
Si j'ai généré l'AIK moi même (ce qui est le cas en réseau d'entreprise), il me suffit de noter la clef public dans un coin moi même pour avoir un degré de certification égal à celui que j'aurais via EK.
En effet TPM_MakeIdentity a l'air indépendant de TPM_ActivateIdentity. Ca me plait. 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).
Le problème étant qu'il faut que je me fasse confiance à moi même
Pour ça il suffit que l'entreprise ait un service "privacy CA" de confiance, et là on lierait les AIK à EK. Et ça ne me choquerait pas: ça a clairement des avantages pour la sécurité. Ce qui me choque, c'est que le TCG ajoute des fonctions et impose des restrictions qui trahissent l'intention de faire du DRM. Par exemple:
- Pourquoi prévoir un mécanisme d'attestation qui permet de rassurer non seulement le Owner, mais aussi un tiers inquisiteur quelconque ?
- 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.
- 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). OK, ça complique un peu le changement de Owner (le constructeur fournirait un nouveau EK certifié, ça peut se faire à distance).
- 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).
Si il faut un EK valide pour accéder un nouvel EK alors on peut toujours se servir des méccanismes de tracabilité
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é.
Le vrai inconvénient est qu'il faut faire compromis entre le niveau d'anonymat et les dégâts en cas de compromission physique d'un TPM.
et j'ai essayé de la créer moi même. Ca fait deux ans que je m'acharne
Ah ben voilà, ton boulot chez Vivendi, c'est réussir à implémenter du DRM sur TCPA !!! :-)
AC