Si le pirate a les moyens d'attaquer physiquement le TPM, il peut probablement extraire les clés non migrables en même temps que les données qui sont chiffrées avec. Bon, je veux bien croire qu'il y a des zones qui s'auto-détruisent mieux que les autres quand on démonte le chip.
tu créé un profil et tu lui associe divers PCR avec les applications ou groupe d'applications que l'utilisateur a le droit de lancer.
En tout cas merci pour la discussion, j'en profite pour découvrir les specs TCPA, et il n'y a pas grand monde capable de débattre sur les détails techniques.
On a demander à TPM de signer windows.exe, il l'a fait et basta. Ce qu'est windows.exe il n'en sait rien et il s'en moque.
Evidemment, mais le tiers inquisiteur, lui, décidera de faire confiance à la plate-forme ou pas en fonction de la valeur du hash. Bon, on ne va pas épiloguer sur le fait que TCPA peut être utilisé, si on le souhaite, comme un composant essentiel d'une infrastructure de DRM.
Quand on a les PC sous la main, on a pas besoin de l'EK.
Logistiquement, c'est un cauchemar d'avoir les PC sous la main. Le protocole à base d'EK certifiés par le constructeur permet à l'administrateur d'activer les PC à distance.
On signe les PC quand on est sur qu'ils sont "propres".
En pratique l'administrateur veut signer un seul PC "propre" de référence et télécharger le PCR correspondant vers tous les TPM de son réseau, sans se déplacer, à chaque fois que c'est nécessaire. Sans crypto asymétrique (EK), ça va être très très chaud. Surtout quand on voudra mettre à jour les PCR précisément parce qu'on vient de s'apercevoir que la config "propre" n'était pas si propre que ça...
Et quid du petit malin qui ramène un PC en panne au SAV ? Est-ce qu'on lui signe son PC ? Sans EK, comment savoir si c'est un vrai TPM qui est dedans ?
Bref, moi je veux des puces TCPA avec EK, parce que c'est plus sûr et plus flexible. Mais je veux aussi avoir le contrôle de mon EK pour éviter que d'autres en abusent.
j'ai deux puces TCPA chez moi, qui n'ont pas d'EK, aucun moyen d'en rajouter une et qui fonctionnent très bien. L'EK est puremetn facultative et ne touche qu'une partie marginale des fonctions TCPA
Tiens, une question très simple:
D'après les specs, pour exécuter TPM_TakeOwnership, il faut que EK soit initialisé (car le secret partagé doit être chiffré avec PubEK).
Comment as-tu pu prendre possession de tes chips si ils n'ont pas de EK ?
Est-ce que TPM_ReadPubEK renvoie vraiment TPM_NO_ENDORSEMENT ?
Ou seulement TPM_DISABLED_COMMAND ? (ce qui signifierait que la lecture de PubEK est restreinte, mais il reste TPM_OwnerReadInteralPub).
Tu voulais peut-être dire que le vendeur ne t'a pas fourni le certificat EK en même temps que la machine ?
elles empêchent le forcage des coffres à clefs par tampering.
Tampering physique ? Ou déchiffrage des blobs externes ? (auquel cas ce serait évidemment très intéressant de savoir extraire ces clés non migrables).
Donc l'EK ne peut pas être fait par le propriétaire de la puce.
C'est pourtant utile lorsque le propriétaire du PC n'est pas l'utilisateur.
Exemple: l'administrateur d'un réseau d'entreprise qui veut contrôler les applis qui tournent sur son réseau.
Il est totalement impossible d'utilsier EK pour faire du DRM
En effet, il faut tout le reste de l'infrastructure, ainsi que des périphériques durcis, et des compétences pour produire des logiciels garantis sans bugs, donc c'est pas demain la veille.
Mais c'est bien EK qui est à la racine de la chaîne de confiance.
L'EK est dans un conteneur différent des AIK. Ils ne peuvent en aucun cas se garantir l'un l'autre.
D'après les specs les AIK sont des alias de EK (pour limiter la traçabilité), donc il ne sont quand même pas complètement indépendants.
Mon boot est certifé, mes programmes sont sous surveillance constante (refresh des PCR toutes les minutes) et si quelqu'un fait la moindre modif ou que ce soit, SE Linux ferme immédiatement l'ensemble des droits en lecture/écriture/exécution.
Ah, ça c'est cool. On peut avoir des détails sur la config ?
Certifier le boot ne veux pas dire pouvoir prouver à une tierce partie que l'OS sur lequel je bosse est bien un windows (TCPA est totalement incapable de faire çà)
Ben si, quand même. Le TPM répond à un challenge en signant le PCR correspondant à la config Windows avec un AIK reconnu par Microsoft (via le tiers de confiance éventuel).
mais prouver à uen tierce partie que le boot est bien le même que cleui de la dernière fois.
Et ta config permet-elle de faire ça, la tierce personne étant quelqu'un d'autre que toi ?
Par exemple, dans une entreprise, permet-elle à l'administrateur de détecter qu'un utilisateur est en train d'essayer de se connecter au réseau avec un OS non autorisé ?
Il me semblait que pour ça il faut des AIK, et donc un EK (certifié par le constructeur ou au moins par l'administrateur).
La procédure de maintenance complète n'est utile que dans le cas ou l'on veut récupérer aussi l'EK.
Je doute que la maintenance puisse migrer EK. L'entité qui réalise l'opération est même censée révoquer l'EK de TPM1 et informer les autorités de certification (page 65).
Concernant l'intérêt d'extraire les clés non migrables, ça m'étonnerait beaucoup qu'elles n'aient absolument aucune valeur, mais je ne maitrise pas suffisamment les specs pour argumenter.
La seule façon de récupérer les clefs en clair serait de les migrer (ie secret du owner, préparation d'un package de migration, déclaration du TPM d'acceuil et en option depuis la V2.0 présence physique ) vers un TPM qui permet l'accès aux clefs en clair.
Donc avec la procédure de backup/migration il suffit bien d'intercepter le secret du Owner (même pas besoin de la collaboration du constructeur). Pour ça il suffira d'une backdoor ou d'un bug exploitable dans un OS, même certifié. D'ailleurs c'est comme ça que le boot sécurisé de la Xbox a été contourné.
Pour beaucoup d'applications il vaut mieux perdre la clé en cas de panne matérielle, que de prévoir un mécanisme de backup aussi vulnérable.
Par contre l'amalgame TCPA=DRM=POUBELLE ne passe pas du tout
Je suis d'accord. TCPA pourrait être idéal pour chiffrer son disque, protéger la clé SSL de son serveur web, ou administrer un réseau bureautique d'entreprise.
Le problème est que les exigences du DRM ont une influence très lourde sur la norme TCPA. Pour les trois applications ci-dessus, il n'y a aucune raison d'empêcher le propriétaire du PC de détruire le certificat du constructeur et de gérer EK lui-même (ce qui serait plus satisfaisant du point de vue de la confidentialité et de la vie privée).
Mais si Microsoft et Vivendi se retrouvent face à un parc installé où 10% des clients ont effacé le certificat EK d'origine de leur TPM, ils ne pourront plus faire passer le DRM de façon indolore. C'est pour ça que tu ne peux pas générer EK sur tes chips, et que tu ne pourras pas le changer sur les futurs modèles, à moins de payer ton TPM plus cher (c'est écrit en clair dans les release notes TPM_1_2_Changes_Final.pdf).
Tu mets deux puces face à face et c'est le owner qui décide tout seul comme un grand d'authoriser le TCPA emmetteur à faire le transfert.
Non, ça c'est la procédure de Backup/Migration, je suppose.
Je parle de la procédure de Maintenance (section 13 de la spec), qui n'est réalisable qu'avec l'assistance du constructeur, et qui permet de transférer même les données marquées comme "non migrables".
Casser une clef symétrique 160 bits en sniffant des emissions "incohérentes"
Il n'y a rien à casser. On parle de backdoors et d'attaques avec la complicité du constructeur de TPM et du fournisseur de l'OS, dans le but d'extraire des clés que l'utilisateur croyait à l'abri dans ton TPM. Il suffit d'intercepter le secret lorsque l'utilisateur saisit sa passphrase pour autoriser une opération protégée quelconque.
l'idée de pouvoir migrer/copier mes clefs d'un TCPA à l'autre me plait : (...) c) parceque tant que cette fonction sera présente l'idée même du DRM sera risible
Là tu donnes de faux espoirs à certains.
Avec les procédures de Backup/Migration, l'utilisateur ne peut transférer que les clés marquées comme migrables (donc probablement pas les clés de DRM).
Les clés non migrables ne sont transférables que par le SAV du constructeur (procédure de Maintenance).
Si je veux détruire mes clefs, je refais une prise de controle du ownership du TCPA.
Le problème n'est pas de savoir détruire les clés (il y a le marteau pour ça), mais de continuer à les utiliser en sachant si elles sont réellement à l'abri.
L'endorsement Key est uen clef qui certifie que la puce a bien été construite par "tel constructeur" et qu'elle est bien de version "machin".
Soyons clairs: ça sert avant tout à certifier que le TPM est un vrai TPM (et pas une émulation en soft), que l'OS n'est pas bidouillé ou virtualisé, et que le Media Player respecte le DRM. Tout ça via les AIK et les PCR.
j'ai deux puces TCPA chez moi, qui n'ont pas d'EK, aucun moyen d'en rajouter une et qui fonctionnent très bien.
Ben oui: Si tu veux faire des choses compliquées, par exemple du boot sécurisé, tu dois acheter un TPM avec un EK et un certificat codés en dur. Sinon, on te vend un TPM sans EK et tu te contentes de l'utiliser pour stocker des clés. Mais on ne te laisse pas gérer EK toi même. Pourtant ce serait très utile pour des applications en entreprise. Bizarre, non ?
Les premiers DVD commercialisés n'étaient pas chiffrés, même quand CSS était déjà dans la norme.
c) Intel a mis au point une autre technique de certification d'identité TPM qui est beaucoup moins intrusive et nettement plsu simple à mettre en place.
Ca m'intéresse. Des références ?
Et on va geler le déploiement de TCPA et réécrire toutes les specs pour intégrer le mécanisme d'Intel ?
Les duex TCPA se reconnaissent comme TCPA, le owner du TCPA à migrer certifie le TCPA migrateur dans son TCPA.
Et le TPM1 vérifie que le certificat du TPM2 est bien signé par le constructeur ? Et il télécharge tout seul des CRL pour vérifier qu'il n'est pas révoqué ?
En fait je suppose il fait entièrement confiance au Owner, comme tu le suggères. Dès lors il est possible de migrer vers un TPM2 bidon.
Quant à l'autorisation du Owner et à la moulinette XOR, elles sont protégées au mieux par le secret symmétrique de 160 bits, que l'on peut forcément sniffer avec une backdoor dans l'OS ou le BIOS. Donc le tour est joué, y compris à distance. A moins de mettre ce secret et tous les algos qui l'utilisent dans un autre module "de confiance" (une carte à puce, par exemple).
La simple existence de cette fonction de maintenance est en contradiction avec le principe de base d'un token crypto: même le propriétaire ne devrait jamais pouvoir extraire les clés. D'ailleurs il y a une commande TPM_KillMaintenanceFeature pour la désactiver, mais j'imagine déjà le dialogue dans le TPM Wizard: "Attention, en désactivant cette fonction, vous risquez de perdre irrémédiablement vos clés, et d'être en infraction avec l'article 434-15-2 du Code Pénal relatif au recouvrement des conventions de chiffrement. Voulez-vous vraiment continuer ?"
Merci pour tes clarifications techniques, mais je ne suis toujours pas rassuré.
P.S. Quant à l'upgrade firmware, il s'agit peut être seulement d'allonger l'access-list des opérations soumises à autorisation du Owner (protected capbilities).
Une correction: la dernière version des specs prévoit la possibilité de changer EK (TPM_RevokeTrust, TPM_CreateRevocableEK).
Mais le document TPM_1_2_Changes_final explique que les chips qui supportent cette fonctionalité seront plus chers que les autres. Autrement dit, aucun constructeur ne les intégrera dans ses PC.
L'existence d'une backdoor permettant la récupération de l'ensemble des clefs contenues dans une puce (et à distance de préférence) ets une pure hypothèse
Pas d'accord. La spec TPM encourage les constructeurs à implémenter une API pour transférer le contenu d'un TPM vers un autre (TPM_CreateMaintenanceArchive, TPM_LoadMaintenanceArchive). Il y a un baratin pas du tout crédible qui dit que le constructeur déchiffre l'archive, mais à moitié seulement, grâce à un XOR miraculeux. D'ailleurs ce pipeau est dans un "informative comment", pas dans la partie normative.
Si ça ne suffit pas, il y a aussi un mécanisme optionnel qui permet au constructeur d'upgrader le firmware du TPM (Field Upgrade). Est-il besoin d'en dire plus ?
Ces fonctions sont optionnelles, et leur présence aura évidemment un impact sur les profils Critères Communs auxquels un TPM pourra prétendre. On peut se douter que les militaires n'auront pas les mêmes TPMs que le grand public (si tant est que les militaires choisissent d'utiliser TCPA).
qui a généré la clé maître en dur dans la puce, et comment => Toi même. C'est une rpocédure qui s'appelle prendre possession du TPM
Pas d'accord. Le TPM contient bien une clé asymétrique codée en dur (EK, Endorsement Key), non modifiable par l'utilisateur, ainsi que le certificat correspondant signé par le constructeur et lisible par l'OS (sauf en cas de désactivation, auquel cas le TPM ne sert plus à grand chose).
Le secret partagé correspondant à la notion d'"ownership" n'est rien de plus qu'un code PIN amélioré.
En fait les specs sont un peu floues (délibérément ?) quant à savoir qui génère EK. Mais il est clair que le TPM serait inutilisable pour faire du DRM si on laissait les utilisateurs choisir tous la même clé, ou émuler leur TPM en soft. Donc inutile de réver.
[^] # Re: On va se répéter une 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é à 3.
tu créé un profil et tu lui associe divers PCR avec les applications ou groupe d'applications que l'utilisateur a le droit de lancer.
Tout le problème est de savoir si cette gestion de profils peut être faite de façon sûre sans EK. A suivre dans l'autre thread
http://linuxfr.org/comments/613763.html#613763(...)
En tout cas merci pour la discussion, j'en profite pour découvrir les specs TCPA, et il n'y a pas grand monde capable de débattre sur les détails techniques.
AC
[^] # Re: On va se répéter une 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.
Evidemment, mais le tiers inquisiteur, lui, décidera de faire confiance à la plate-forme ou pas en fonction de la valeur du hash. Bon, on ne va pas épiloguer sur le fait que TCPA peut être utilisé, si on le souhaite, comme un composant essentiel d'une infrastructure de DRM.
Quand on a les PC sous la main, on a pas besoin de l'EK.
Logistiquement, c'est un cauchemar d'avoir les PC sous la main. Le protocole à base d'EK certifiés par le constructeur permet à l'administrateur d'activer les PC à distance.
On signe les PC quand on est sur qu'ils sont "propres".
En pratique l'administrateur veut signer un seul PC "propre" de référence et télécharger le PCR correspondant vers tous les TPM de son réseau, sans se déplacer, à chaque fois que c'est nécessaire. Sans crypto asymétrique (EK), ça va être très très chaud. Surtout quand on voudra mettre à jour les PCR précisément parce qu'on vient de s'apercevoir que la config "propre" n'était pas si propre que ça...
Et quid du petit malin qui ramène un PC en panne au SAV ? Est-ce qu'on lui signe son PC ? Sans EK, comment savoir si c'est un vrai TPM qui est dedans ?
Bref, moi je veux des puces TCPA avec EK, parce que c'est plus sûr et plus flexible. Mais je veux aussi avoir le contrôle de mon EK pour éviter que d'autres en abusent.
AC
[^] # 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é à 1.
Tiens, une question très simple:
D'après les specs, pour exécuter TPM_TakeOwnership, il faut que EK soit initialisé (car le secret partagé doit être chiffré avec PubEK).
Comment as-tu pu prendre possession de tes chips si ils n'ont pas de EK ?
Est-ce que TPM_ReadPubEK renvoie vraiment TPM_NO_ENDORSEMENT ?
Ou seulement TPM_DISABLED_COMMAND ? (ce qui signifierait que la lecture de PubEK est restreinte, mais il reste TPM_OwnerReadInteralPub).
Tu voulais peut-être dire que le vendeur ne t'a pas fourni le certificat EK en même temps que la machine ?
AC
[^] # Re: On va se répéter une 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é à 1.
Tampering physique ? Ou déchiffrage des blobs externes ? (auquel cas ce serait évidemment très intéressant de savoir extraire ces clés non migrables).
Donc l'EK ne peut pas être fait par le propriétaire de la puce.
C'est pourtant utile lorsque le propriétaire du PC n'est pas l'utilisateur.
Exemple: l'administrateur d'un réseau d'entreprise qui veut contrôler les applis qui tournent sur son réseau.
Il est totalement impossible d'utilsier EK pour faire du DRM
En effet, il faut tout le reste de l'infrastructure, ainsi que des périphériques durcis, et des compétences pour produire des logiciels garantis sans bugs, donc c'est pas demain la veille.
Mais c'est bien EK qui est à la racine de la chaîne de confiance.
AC
[^] # 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é à 1.
D'après les specs les AIK sont des alias de EK (pour limiter la traçabilité), donc il ne sont quand même pas complètement indépendants.
Ah, ça c'est cool. On peut avoir des détails sur la config ?
Certifier le boot ne veux pas dire pouvoir prouver à une tierce partie que l'OS sur lequel je bosse est bien un windows (TCPA est totalement incapable de faire çà)
Ben si, quand même. Le TPM répond à un challenge en signant le PCR correspondant à la config Windows avec un AIK reconnu par Microsoft (via le tiers de confiance éventuel).
mais prouver à uen tierce partie que le boot est bien le même que cleui de la dernière fois.
Et ta config permet-elle de faire ça, la tierce personne étant quelqu'un d'autre que toi ?
Par exemple, dans une entreprise, permet-elle à l'administrateur de détecter qu'un utilisateur est en train d'essayer de se connecter au réseau avec un OS non autorisé ?
Il me semblait que pour ça il faut des AIK, et donc un EK (certifié par le constructeur ou au moins par l'administrateur).
AC
[^] # Re: On va se répéter une 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.
Je doute que la maintenance puisse migrer EK. L'entité qui réalise l'opération est même censée révoquer l'EK de TPM1 et informer les autorités de certification (page 65).
Concernant l'intérêt d'extraire les clés non migrables, ça m'étonnerait beaucoup qu'elles n'aient absolument aucune valeur, mais je ne maitrise pas suffisamment les specs pour argumenter.
La seule façon de récupérer les clefs en clair serait de les migrer (ie secret du owner, préparation d'un package de migration, déclaration du TPM d'acceuil et en option depuis la V2.0 présence physique ) vers un TPM qui permet l'accès aux clefs en clair.
Donc avec la procédure de backup/migration il suffit bien d'intercepter le secret du Owner (même pas besoin de la collaboration du constructeur). Pour ça il suffira d'une backdoor ou d'un bug exploitable dans un OS, même certifié. D'ailleurs c'est comme ça que le boot sécurisé de la Xbox a été contourné.
Pour beaucoup d'applications il vaut mieux perdre la clé en cas de panne matérielle, que de prévoir un mécanisme de backup aussi vulnérable.
Par contre l'amalgame TCPA=DRM=POUBELLE ne passe pas du tout
Je suis d'accord. TCPA pourrait être idéal pour chiffrer son disque, protéger la clé SSL de son serveur web, ou administrer un réseau bureautique d'entreprise.
Le problème est que les exigences du DRM ont une influence très lourde sur la norme TCPA. Pour les trois applications ci-dessus, il n'y a aucune raison d'empêcher le propriétaire du PC de détruire le certificat du constructeur et de gérer EK lui-même (ce qui serait plus satisfaisant du point de vue de la confidentialité et de la vie privée).
Mais si Microsoft et Vivendi se retrouvent face à un parc installé où 10% des clients ont effacé le certificat EK d'origine de leur TPM, ils ne pourront plus faire passer le DRM de façon indolore. C'est pour ça que tu ne peux pas générer EK sur tes chips, et que tu ne pourras pas le changer sur les futurs modèles, à moins de payer ton TPM plus cher (c'est écrit en clair dans les release notes TPM_1_2_Changes_Final.pdf).
AC
[^] # Re: On va se répéter une 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.
Non, ça c'est la procédure de Backup/Migration, je suppose.
Je parle de la procédure de Maintenance (section 13 de la spec), qui n'est réalisable qu'avec l'assistance du constructeur, et qui permet de transférer même les données marquées comme "non migrables".
Il n'y a rien à casser. On parle de backdoors et d'attaques avec la complicité du constructeur de TPM et du fournisseur de l'OS, dans le but d'extraire des clés que l'utilisateur croyait à l'abri dans ton TPM. Il suffit d'intercepter le secret lorsque l'utilisateur saisit sa passphrase pour autoriser une opération protégée quelconque.
Là tu donnes de faux espoirs à certains.
Avec les procédures de Backup/Migration, l'utilisateur ne peut transférer que les clés marquées comme migrables (donc probablement pas les clés de DRM).
Les clés non migrables ne sont transférables que par le SAV du constructeur (procédure de Maintenance).
Le problème n'est pas de savoir détruire les clés (il y a le marteau pour ça), mais de continuer à les utiliser en sachant si elles sont réellement à l'abri.
AC
[^] # 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é à 4.
Soyons clairs: ça sert avant tout à certifier que le TPM est un vrai TPM (et pas une émulation en soft), que l'OS n'est pas bidouillé ou virtualisé, et que le Media Player respecte le DRM. Tout ça via les AIK et les PCR.
Ben oui: Si tu veux faire des choses compliquées, par exemple du boot sécurisé, tu dois acheter un TPM avec un EK et un certificat codés en dur. Sinon, on te vend un TPM sans EK et tu te contentes de l'utiliser pour stocker des clés. Mais on ne te laisse pas gérer EK toi même. Pourtant ce serait très utile pour des applications en entreprise. Bizarre, non ?
Les premiers DVD commercialisés n'étaient pas chiffrés, même quand CSS était déjà dans la norme.
Ca m'intéresse. Des références ?
Et on va geler le déploiement de TCPA et réécrire toutes les specs pour intégrer le mécanisme d'Intel ?
AC
[^] # Re: On va se répéter une 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é à 4.
Et le TPM1 vérifie que le certificat du TPM2 est bien signé par le constructeur ? Et il télécharge tout seul des CRL pour vérifier qu'il n'est pas révoqué ?
En fait je suppose il fait entièrement confiance au Owner, comme tu le suggères. Dès lors il est possible de migrer vers un TPM2 bidon.
Quant à l'autorisation du Owner et à la moulinette XOR, elles sont protégées au mieux par le secret symmétrique de 160 bits, que l'on peut forcément sniffer avec une backdoor dans l'OS ou le BIOS. Donc le tour est joué, y compris à distance. A moins de mettre ce secret et tous les algos qui l'utilisent dans un autre module "de confiance" (une carte à puce, par exemple).
La simple existence de cette fonction de maintenance est en contradiction avec le principe de base d'un token crypto: même le propriétaire ne devrait jamais pouvoir extraire les clés. D'ailleurs il y a une commande TPM_KillMaintenanceFeature pour la désactiver, mais j'imagine déjà le dialogue dans le TPM Wizard: "Attention, en désactivant cette fonction, vous risquez de perdre irrémédiablement vos clés, et d'être en infraction avec l'article 434-15-2 du Code Pénal relatif au recouvrement des conventions de chiffrement. Voulez-vous vraiment continuer ?"
Merci pour tes clarifications techniques, mais je ne suis toujours pas rassuré.
P.S. Quant à l'upgrade firmware, il s'agit peut être seulement d'allonger l'access-list des opérations soumises à autorisation du Owner (protected capbilities).
[^] # 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é à 3.
Mais le document TPM_1_2_Changes_final explique que les chips qui supportent cette fonctionalité seront plus chers que les autres. Autrement dit, aucun constructeur ne les intégrera dans ses PC.
AC
[^] # Re: On va se répéter une 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é à 3.
Pas d'accord. La spec TPM encourage les constructeurs à implémenter une API pour transférer le contenu d'un TPM vers un autre (TPM_CreateMaintenanceArchive, TPM_LoadMaintenanceArchive). Il y a un baratin pas du tout crédible qui dit que le constructeur déchiffre l'archive, mais à moitié seulement, grâce à un XOR miraculeux. D'ailleurs ce pipeau est dans un "informative comment", pas dans la partie normative.
Si ça ne suffit pas, il y a aussi un mécanisme optionnel qui permet au constructeur d'upgrader le firmware du TPM (Field Upgrade). Est-il besoin d'en dire plus ?
Tout ça est dans https://www.trustedcomputinggroup.org/downloads/tpmwg-mainrev62_Part(...) section 13 pour ceux qui ont le temps de se faire une opinion par eux-mêmes.
Ces fonctions sont optionnelles, et leur présence aura évidemment un impact sur les profils Critères Communs auxquels un TPM pourra prétendre. On peut se douter que les militaires n'auront pas les mêmes TPMs que le grand public (si tant est que les militaires choisissent d'utiliser TCPA).
AC
[^] # 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é à 4.
Pas d'accord. Le TPM contient bien une clé asymétrique codée en dur (EK, Endorsement Key), non modifiable par l'utilisateur, ainsi que le certificat correspondant signé par le constructeur et lisible par l'OS (sauf en cas de désactivation, auquel cas le TPM ne sert plus à grand chose).
Les specs TPM mentionnent explicitement que ça pose des problèmes de traçabilité puisque le certificat identifie de manière unique le TPM.
(https://www.trustedcomputinggroup.org/downloads/tpmwg-mainrev62_Part(...) TPM Main specification version 1.2 Part 1 Design Principles, page 25).
Le secret partagé correspondant à la notion d'"ownership" n'est rien de plus qu'un code PIN amélioré.
En fait les specs sont un peu floues (délibérément ?) quant à savoir qui génère EK. Mais il est clair que le TPM serait inutilisable pour faire du DRM si on laissait les utilisateurs choisir tous la même clé, ou émuler leur TPM en soft. Donc inutile de réver.
AC