Mais il y a bien plusieurs niveaux de hash qui sont de plus en plus "uniques". Et PCR[0] à PCR[4] semblent conçus pour être identiques sur deux PC d'un même modèle.
Les PCR sont les noms des "boites" qui contiennent les données sécurisées. La question est de savori si on peut avoir la signature ou l'AIK de juste cette boite. La réponse est non, tous les hash qui sortent de la puce contiennent au minimum un sous hash du CRTM.
PCR[0-4] servent à valider la cohérence du TPM (ie prouver que le système n'a pas été compromis) donc ils sont prévisibles. Mais ce n'est pas pour autant qu'ils sortent de la puce.
j'imagine qu'il y a des PCR qui caractérisent le modèle et la version du TPM mais pas son EK unique
Bien sur, un PCR peut ne caractériser que celà, mais si tu demande un hash ou un AIK qui permet d'accéder à ce PCR une fois d eplsu le hash sortant de la puce contiendra le CRTM (et donc sera imprévisible)
Ben sans certification de la plate-forme par EK, le tiers inquisiteur n'a aucune raison de faire confiance au CRTM.
Si le CRTM était prévisible si. Il pourrait faire les calculs de son coté et vérifier la concordance.
Il faut obligatoirement deux TPM pour faire un backup ? Qu'est ce qui m'empêcherait de demander un backup vers un TPM émulé ?
Le specs. La migration n'est déclenchable que vers un autre TPM. J'imagine que l'on pourrait forcer une migration via un TPM émulé en forcant le TPM hôte à accepter le certificat du TPM émulé. Beaucoup de travail pour madame Michu...
Pourquoi ? Ce n'est pas télécommandable par le Owner ?
Non, la présence physique est requise.
Allez, une autre solution pour faire du DRM sans base de donnée centrale, et même si les hashes n'étaient jamais les même d'une machine à l'autre: Il suffit qu'à la sortie de l'usine, le constructeur boote le PC, demande le hash, génère un certificat qui dit "je garantis que le hash 0x12345678 correspond au boot d'un PC TCPA avec tel bootloader", et livre ce certificat avec le PC.
Ce serait une façon de faire, c'est dommage que la norme TCG interdise strictement qu'un TPM soit livré avec un owner prédéfini et des clefs préchargées. De plus, il faudrait également s'assurer que le propriétaire du PC ne connaisse pas le secret owner, ne puisse pas reseter la puce etc. Bref on a à 100 lieues des specs.
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.
Je ne trouve pas spécialement qu'il y ai progrès, au contraire, sur la clef USB, on peut facilement, utiliser une technologie logicielle libre à laquelle on peut faire relativement confiance pour encrypter les informations
Oui mais pour utiliser ses information tu seras obliger de les décrypter, et donc d'être à la merci d'une personne qui aurait pris le controlle de ton ordinateur et qui logguerait.
La puce TPM par contre ne laisse jamais sortir les clefs privées, donc il est impossible d'obtenir une telle clef par des moyens détournées. Pour chopper la clef publique, il faut casser la clef privée... C'est quand même uen grosse faille de sécurité en moins.
Pourtant TPM_Quote reçoit en argument la liste des PCR à intégrer dans le hash, sous la forme d'un bitmask. Qu'est ce qui emêche le tiers inquisiteur de demander 8 attestations contenant chacune un seul PCR ?
Si tu demande un seul PCR tu auras le hash de tous les PCR pré-boot plus le PCR boot/postboot que tu as demandé. C'est l'architecture me de la puce qui empèche de renvoyer hash(OS_LOAD) par exemple. Ca sera toujours un hash imbriqué.
Pour TPM_Quote c'est le même principe, pour qu'un hash soit valide, il faut absolument qu'il prenne en compte le CRTM (ie la base de confiance des mesures). C'est même la seule façon de vérifier que les données renvoyées par le TPM sont valides.
Pourquoi M(TPM) serait-il unique ? Où vois-tu ça dans la spec ?
GNI ? L'EK est unique, normalement la signature du secret ownership aussi. Donc le CRTM sera forcément unique (aux collisions prés). c'est la base même du TPM, et la raison principale pour laquelle les TPM doivent être livrés sans owner. C'est la seule façon de s'assurer que le constructeur n'a pas pu faire une copie de notre CRTM. C'est clair que si les TPM étaient livrés avec un own et un secret prédéfini, les constructeurs pourraient noter les clefs publics et signatures comme ils peuvent le faire avec l'EK.
Autre problème si M(TPM) n'est pas unique, ca veut dire que si une personne reset la puce, elle garde quand même intact les AIK, et puet donc se faire passer pour le possesseur légal de la puce.
Bref si M(TPM) est déterministe, la puce n'apporte strictement rien en matière de sécurité.
En plus tous le meccanisme de certification de la puce par l'EK n'apporterait alors strictement rien, vu que tous les TPM (au moins d'une même marque - même modèle) auraient la même signature. Pourquoi créer des certificats supplémentaires si il suffisait de demander le hash du CRTM ?
Ben il suffit d'utiliser régulièrement la procédure de backup/migration du TPM, non ?
Oui, à l'EK près ca suffirait. Seulement madame Michu n'a pas forcément deux ordinateurs sous TPM à la maison, et monsieur DSI GrosseBoite n'a pas forcément envie de lancer une procédure de backup systématique de tous ses TPM. Surtout que cette procédure et inautomatisable.
Et puis tu connais beaucoup de SAV qui s'amusent à désouder des chips sur les cartes mère ? Et qui de plus prendraient la peine de mettre exactement la même version de firmware en remplacement pour que le TPM ne s'aperçoive de rien ?
C'est bien pour çà qu'il faut qu'un rpemplacement de carte mére à l'identique ne gène pas le TPM. Les TPM infineon par exemple sont sur des cartes filles extractibles, pour permettre une maintenance facilité (la carte mère crame, on peut quand même garder le TPM en état). Quand à la mise à jour des firmwares il est possibles grace à un système de certifications des composants de faire accepter une mise à jour de composants par le TPM sans que les clefs ne se bloquent. Cependant je ne coris pas qu'ile xiste de TPM supportant cette opération au jour d'ajourd'hui.
Toujours sous ton hypothèse douteuse que deux machines n'ont aucune chance de renvoyer le même hash.
Ce n'est pas une hypothèse. EK + signature du secret owner est unique.
Au mieux il y aura 3 versions certifiées
Par constructeur et par mois ? Ou bien il n'y aura qu'un seul constructeur par chipset existant lequel aura seulement trois versions et ne fera pas de nouveaux chipsets pendant des années ?
Honnêtement, si il n'y a que trois chipsets certifiés (mettons Intel, VIA, NVidia) par classe de chipset ca va être un vrai frein au progrès.
Soyons sérieux, Intel rien que pour les bridges CPU possède plusieurs dizaines de chipsets à l'heure actuelle, et c'est normal : il y a plusieurs classe de processeurs, des cartes mères qui vont de un à 8 processeurs, des controlleurs redondants ou non, des support mémoires ECC et/ou regsitred ou rien etc. Lesquels chispet sont intégrés différamment suivant que ce soit Intel, Asus ou Tyan qui fasse le boulot. Pour tomber à trois chipsets certifiés il faudra couper sévèrement.
Et là je ne parlerais même pas du dernier jouet de Intel : le Bios EFI qui s'assure à lui tout seul d'exploser largement les cents variantes par composant
Tu mélanges deux choses:
Non je ne mélange rien, l'EK créé par le constructeur est obtenu après la certification du matériel par audit du TCG ou d'un groupe indépendant et la certification du fournisseur que c'ets bien une puce TCPA. C'est rigoureusement l'équivalent des certificats racines que l'on trouve dans les navigateurs, ils sont livrés de base parcequ'il est très complexe d'établir une chaine de confiance vis à vis de l'extérieur soi-même. Pour certifier soi-même verisign par exemple il faut se déplacer chez Verisign en personne, ou dans un organisme de confiance qui certifie verisign. Dans le cadre de TCPA il faudrait faire auditer la puce, la faire certifier, faire auditer son TCPA et le faire certifier soi-même. Un peu long et complexe comme manip non ?
OK, sauf que je ne suis pas certain que mes clés permettent de faire la même chose que EK+AIK dans le scénario du réseau d'entreprise.
Il n'y a absolument pas besoin de EK pour générer des AIK. Un AIK est uen clef associée a un PCR ou à un ensemble de PCR. 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. Le problème étant qu'il faut que je me fasse confiance à moi même (ce quid an sle cadre d'une grosse entreprise avec plusieurs intervenants n'est pas forcément aussi simple que ça)
Bon, on tourne en rond. Pour avancer, il suffirait que l'EFF ou la CNIL implémente une démo d'infrastructure DRM bien méchante à base de TCPA,
juste pour montrer à tout le monde que c'est possible et que ça peut faire mal.
Honnêtement j'ai demandé à plusieurs intervenants de divers mailing lists de faire cette implémentation, et j'ai essayé de la créer moi même. Ca fait deux ans que je m'acharne et que je provoque des gens plus doués que moi. Sans résultat.
Encore une fois, il vaudrait mieux pouvoir désactiver EK (sinon TPM_ForceClear suffit à la réactiver), pour que personne ne soit tenté d'en abuser plus tard.
TPM_ForceClear est un reset forcé de la puce pour une personne ne connaissant pas le secret owner. Quand on fait une requète TPM_ForceClear, le pc doit être rebooté. Au reboot le bios TPM charge uniquement l'OS TPM, toutes les fonctions réseaux/bus extérieurs sont désactivées pour assurer la présence physique de l'intervenant sur le PC. L'intervenant doit alors confirmer qu'il veut faire un reset de la puce, laquelle puce se retrouve alors dans le mode par défaut : pas de owner, 0 clef stoquée,toutes fonctions désactivées sauf "take ownership". Très difficile de faire celà "en douce"
Autre alternative raisonnable: permettre à l'utilisateur de remplacer l'EK d'origine par une EK prise au hasard dans un pool partagé. Ca aurait les mêmes avantages et inconvénients que le mécanisme d'attestation anonyme (DAA).
Ca aurait un autre gors inconvennient : comment s'assurer que la requète "prendre uen clef au hasard dans le pool" a bien été faite à partir d'une puce TCPA et non par un émulateur.
Si il faut un EK valide pour accéder un nouvel EK alors on peut toujours se servir des méccanismes de tracabilité (vu que j'aurais été obligé de donner pubEK pour changer d'EK). Si il n'y a pas besoin d'EK (et donc même pas besoin de owner sur la puce) n'importe quel émulateur peut faire la requète et se retrouver certifié comme un TPM valide...
Pourtant la spec TCG PC Specific Implementation Specification fait tout ce qu'il faut pour que certains hashes soient prédictibles
Attention. Il est très important de se souvenir que la puce TPM ne renvoit pas les hashes individuels, mais le résultat d'une série de hashes imbriqués.
Par exemple, un chipset southbridge renverra toujours le même hash à l'intérieur du TPM via les systèmes de mesures. Cependant ce hash ne sort pas de la puce. Ce qui sort de la puce c'est hash(M(chipset1) + hash(M(chipset2) + hash(M(TPM)+ hash (M(bios) + hash(M(chipset3) + ...)))))
avec M(X) la mesure du composant X par la puce TCPA.
Il y a au minimum 8 hash imbriqués, et on peut pour créer des PCR non publics en rajouter jusqu'à 8 de plus. Comme les mesures de chaque TPM sont unique (ie M(TPM) est différent pour chaque TPM - encore heureux). Le hash qui va sortir sera également unique.
Ces précautions n'auraient aucune utilité si l'objectif était seulement de contrôler que le PC boote "dans la même config que la dernière fois".
Dans ce cadre là, les précautions ne servent à rien, elles servent par contre beaucoup dans un autre cadre : l'envoi en réparation. Supposons que le chipset1 brule et qu'il contienne un numéro de série. Si les mesures et leur hash ne sont pas prédictibles, le nouveau chipset va changer complètement tous les PCR, même le PCR public ne sera plus accessible si chipset1 fait partie des 8 composants fondamentaux qui servent à chaque PCR. En d'autres termes, chaque panne matérielle pourrait entrainner la perte de l'ensemble du contenu de la puce TPM. Ce qui fait quand même un peu désordre non ?
Je suis sûr que les constructeurs fourniront la liste de toutes les combinaisons homologuées de composants mis sur le marché, si Microsoft demande gentiment.
Même en ne prenant que les 8 hash principaux et en supposant qu'il existe un moyen de récupérer M(TPM) hors de la puce. il faut alors connaitre l'ensemble des combinaison possibles de
hash(M(chipset1) + hash(M(chipset2) + hash(M(TPM)+ hash (M(bios) + hash(M(chipset3) + hash(composant6 + hash(composant7 +hash(composant 8))))))))
Un système de hash bien fait étant ininversible il faudra comparer le hash final à l'ensemble de tous les hashs possibles à chaque fois. En supposant qu'il existe cent types de composants de chaque sorte (et là on est carrément optimiste) hors TPM cela fait 100^9x(nombre de TPM vendus) hash à connaitre en se contant seulement ici d'identifier le matériel préboot (ie le PCR public).
Après bien sur si on veut faire du drm c'est la liste de l'ensemble des
hash(M(chipset1) + hash(M(chipset2) + hash(M(TPM)+ hash (M(bios) + hash(M(chipset3) + hash(composant6 + hash(composant7 +hash(composant 8 + hash(boot + hash(system +hash(user +hash (logiciel + hahs (donneés))))))))))))) qu'il faut connaitre. Et il be faut pas oublier de régénerer l'ensemble de la base à chaque fois qu'il y a mise à jour du système ou du logiciel.
Si on table sur 10% de PC équipés de puce TPM et d'un seul utilisateur non owner par TPM ca fait 10^18x(80 000 000)² (il y a environ 800 000 000 de PC dans le monde). Ca fait 6.4x10^33 données possibles. La bonne nouvelle c'est que c'est en dessous du nombre d'atomes dans l'univers, donc techniquemetn réalisable. La mauvaise nouvelle c'est qu'on est dans une hypothèse hyper favorable et qu'on a même pas pris en compte le bios, le système, le lgoiciel ou les données....
Donc pour DRM, je continue de pas y croire un seul instant.
Qui te dit qu'IBM ou le fabricant du TPM n'ont pas une copie de PubEK sous la main, pour le cas où tu demanderais un certificat ?
Voire de PrivEK (mais dans ce cas, un flag doit en principe t'indiquer que EK a été injectée et pas générée par le TPM lui-même).
Effectivemetn rien. De même que je ne susi pas sur qu'il n'y ait pas un tag sur ma carte réseau ou sur mon CPU. Je ne susi pas sur non plus que quand je désactive les fonctions EK elles ne sont pas réactivables à distance etc. L'EK fait partie d'un système de certification. Tu dois donc faire confiance au constructeur, au certificateur et au tiers inquisiteur. Effectivement dans le monde du logiciel libre on peut éviter tout celà, il suffit d'auditer le code, de compielr soit-même et de détruire les certificats racines par défaut. Dans le monde hardware il faudrait faire une puce TCPA basée sur les specs et la fondre soi-même. C'est un peu plus complexe pour l'instant
Oui, mais dans ce cas le TPM n'apporte pas grand chose par rapport à une carte à puce associée à un BIOS non flashable. Moi je préfère qu'il y ait un mécanisme de certification qui me garantit que le TPM que j'ai acheté n'est pas contrefait, que son architecture a bien été évaluée Critères Communs EALx par un labo indépendant du fabricant, etc...
Achéte une puce TCPA, vérifie la, désactive l'EK, créé tes propres clef dans le PCR public et voilà. Tu as toute les garanties possible sur ta puce et le certificat que tu utilises est le tien à 100%.
Le problème est qu'on empêche le client final de révoquer ce mécanisme de certification ou d'en prendre le contrôle et la responsabilité, alors que ce serait légitime par exemple pour un usage en entreprise.
Non, la certification requiert un tiers de confiance. Si le site Ebay me certifie qu'il est bien le site ebay, je n'ai aucun moyen de savoir si c'est vrai. Si un de mes certificat racine, obtenus via des canaux fiabilisés par une chaine de confiance mer certifie que c'est bien le site ebay, c'est bon je peux y aller.
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.
un jour, 99,9% des PC auront un TPM avec une EK indélébile et un certificat utilisable pour faire du DRM
Le certificat est utilisable pour faire de l'authentification, pour le DRM c'est impossible. L'EK ne peut pas être utilisé pour crypter du contenu de façon sécurisée. De plsu l'EK n'est lié à aucun PCR et est donc toujours accessible si on connait le secret. Je ne vois pas comment on peut faire du DRM avec çà.
L'enjeu est que les constructeurs de PC nous vendent exclusivement des TPM avec une EK révocable et remplaçable
Si on révoque l'EK
a) On détruit toutes les clefs et
b) On se coupe la possibilité de créer un certificat acceptable de l'extérieur (à moins de reafire appel à une tierce partie pour régénérer l'EK, et là on retombe dans le même schéma)
La solution offerte de désactiver l'EK me parait nettement plus simple et raisonnable.
Ce que tu appelles certification simple, c'est le mécanisme à base de protocole zéro-knowledge (DAA) ajouté dans la version 1.2 ?
Non en fait il y a trois niveaux dans la certification. Le premier niveau c'est juste que le fabriquant mette une clef EK valide en lançant la commande qui va bien.
Le deuxième niveau c'est que le constructeur récupère la clef d'endossement dans un coin et la garde précieusement pour fournir des certificats par la suite
Le troisième niveau c'est qu'il valide les certificats via un tiers de confiance.
IBM n'ayant pas mon EK je ne pourrais jamais être certifié....
En tout cas tu as bien un EK unique
oui lisible par l'OS
oui - mais désactivable, désactivé par défaut (le TPM n'a même pas de owner) . Il ne manque vraiment pas grand chose pour que tu puisses entrer dans le monde merveilleux du DRM :-)
En sachant que l'on ne peut pas se servir de a partie publique de l'EK pour faire de l'encryption ? Ca va être très dur.
Les fonctionnalités d'endossement impliquent une perte de l'anonymat, fut-elle temporaire. On peut parfaitement désactiver la clef d'endossement et ne jamais s'en servir. Personellement j'ai déployé ma propre clef dans la section publique de mes PCR et ca me va très bien pour créer des certificats entre les deux machines de mon réseau.
Evidemment, mais le tiers inquisiteur, lui, décidera de faire confiance à la plate-forme ou pas en fonction de la valeur du hash
Il va avoir ennormément de mal. Le tiers de confiance peut très facilement vérifier si c'est lui ou pas qui a mis le certificat dans le TCPA. Mais supposons qu'il veuille valider un hash.
Même si on demande le hash de juste windows.exe; le TPM ne fait pas de mini hashes, il y a en fait 8 hashes successifs avant même le premier hash demandé. Les hashes contiennent : Le CPU, le Chipset, le bios, la puce TCPA elle même et la séquence préboot (les divers init)
Tu voulais peut-être dire que le vendeur ne t'a pas fourni le certificat EK en même temps que la machine ?
Non, j'ai bien une EK sur mon TPM et elle est bien certifiée au niveau 1 (sinon je me ferais jeter par les autres TPM), ce que je voulais dire est qu'elle n'est pas utilisable/activée/accessible pour les travaux de certifications third party. Je n'ai pas de certificat niveau 2 qui me permettrait d'avori des certificats niveau 3 pour me faire authentifier à l'extérieur de la puce. Grosso modo, j'ai le certificat qui dit "c'est un tcpa" mais pas celui qui dit "c'est ce tcpa là" et je ne peux donc pas créer les certificats qui disent "Mr Machin certifie que c'est bien ce tcpa là"
Mais c'est très complexe à dire. Donc ce que je veux dire c'est que je n'ai pas l'EK qui fait peur par parcequ'il identifie la machine. Et que je ne pourrais jamais l'avoir.
La certification TCPA simple suffit largement dans l'ensemble des cas, et elle n'implique pas du tout l'EK.
Tu ne fait pas ta tête de con du tout, c'est pour çà que le mouvement brownien est chiant à traiter.
Par expemple pendant les migrations les hirondelles ont un mouvement brownien (donc aléatoire, donc imprédictible), mais pourtant elles vont toutes vers le sud, et en plus souvent dans le même régions (donc pas aléatoire du tout et carrément prédictible). Après il y a toute la théorie stochastique qui déboule, les notions de prévisibilité et de prévisibilité encadrée. La notion de risque et d'évènement energétiquement improbable et tout le toutim.
Comme disait mon prof, on va considérer que le mouvement est "suffisament" complètement aléatoire.
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.
GNI ? Les AIK sont des descripteurs de contenu PCR (genre ce PCR a été créé avec un hash préboot+mémoire+appli "toto"+utilsateur "marcel" ).
Ah, ça c'est cool. On peut avoir des détails sur la config ?
Déjà publié par IBM, mais ca sera dans l'article, promis.
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).
Si tu veux que ton AIK soit reconnu par microsoft, i faut obligatoirement passer par un tiers de ocnfiance. Un AIK est une clef qui décrit le contenu du hashage, mais elle n'est pas "lisible" en clair. Pour prouver qu'elle correspond bien à ce qu'elle prétend être il faut nécessairement passer par un certificat.
Ce qui se passe :
Tiers inquisiteur : Il me faut l'AIK boot+windows.exe+utilisateur
TPM utilisateur : OK c'est FH67EF45DE43AC34FF22
Tiers de confiance : Je confirme c'est bien l'AIK boot+windows.exe+utilisateur (et c'est uniquement à çà que l'EK sert)
Mais alors maintenant si un petit malin c'est amusé a lancer un programme "windows.exe" sur son linux (par exemple un process idle, on va pas gacher des ressources non plus) ni le tiers inquisiteur ni le tiers de confiance ne peuvent rien y faire. 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.
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é ?
Tout à fait. Il suffit de signer le boot de chaque machine et de noter le résultat. Si il change, c'est qu'il y a entourloupe. Quand on a les PC sous la main, on a pas besoin de l'EK. On signe les PC quand on est sur qu'ils sont "propres". Et on tape sur tout ce qui change.
L'EK ne sert que pour les TPM inconnus perdus dans la nature. Pour les PC de ton réseau...
Tampering physique ? Ou déchiffrage des blobs externes
Tampering physique, les blobs externes sont fabriqués avec des clefs qui agissent avec l'extérieur et qui sont donc migrables (en théorie, parcequ'en pratique elles sont bloquées pendant la migration et détruites après)
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.
Dans ce cas c'est très simple, 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.
Par exemple, si l'utilisateur appartient au groupe "secretariat" sous linux, tu lui assoice un profil secretariat qui lui ouvre une clef capable de l'authentifier sur le réseau.
Si l'environement de login est modifié, alors l'utilisateur perd sa clef (le PCR se referme) et donc la connection réseau.
Mais c'est bien EK qui est à la racine de la chaîne de confiance.
Manifestement, vu la direction que prend Intel avec La Grande (Elles sont très bien les nouvelles docs de http://www.intel.com/technology/security/(...) ) ca va pas être le cas du tout. C'est l'OS qui va servir de certificat via Lagrande et la double authentification intel qui va faire office de tiers de confiance.
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).
Oui vu que la clef d'endossement passe alors sur TPM2. ca ne se fait pas d'avoir deux fois le même identifiant unique. Ca serait même plutôt pas bien vu du tout.
ça m'étonnerait beaucoup qu'elles n'aient absolument aucune valeur, mais je ne maitrise pas suffisamment les specs pour argumenter.
Elles ont une ennorme valeur : elles empêchent le forcage des coffres à clefs par tampering. Mais à part çà... Que dalle.
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.
Certes, mais pour d'autres non. C'est toujours mieux à mon sens d'avori el choix. De plus si on parle de backdoor, et de fonctions non documentés, il ne sert pas à grand chose de gronder contre les fonctions qui sont doncumentés. Rien ne prouve en effet qu'il n'existe pas un moyen caché de sortir la clef, à moins de fondre la puce toi même.
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
Euh... dans une certification trois tiers il faut trois tiers. Si je te certifies être Bill Gates ou RMS ca n'a aucune valeur. Il faut que quelqu'un d'autre te certifie que je suis bien qui je prétend être. C'est exactement le but de l'EK. Donc l'EK ne peut pas être fait par le propriétaire de la puce.
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
Il est totalement impossible d'utilsier EK pour faire du DRM. EK identifie la puce, quand à savoir si cette puce est sur un PC ou un Mac, si l'OS de la machin est windows, BSD ou Linux, si le lecteur et windowsmédia ou vlc... TPM ne dispose d'aucun moyen de le gérer. Il eput certifier (ou non) que la config est bien identique à la config précédente. C'est tout.
En plus de celà, comme toutes les clefs accessibles de l'extérieur sont copiables et migrables ca n'apporte pas vraiment de garanties de ce coté là non plus.
TCPA et le DRM c'est comme les poissons et les byciclettes, les deux se déplacent, mais ils vont pas vraiment ensemble.
c'est un mouvement chaotique brownien pas du tout aléatoire.
Vas-y sort moi l'équation complète du mouvement de chaque morceau déchirré à la main, le tout tournant dans un souflerie alimentés apr des turbines 12v mal lissé par un transfo bas de gamme alimenté par du 220v pas filtré.
Allez vas-y ! Je t'attend !
(N.B : Le truc c'est que si tu fais des réseaux de neurones à longueur de journée, tu es peut-être capable de la faire génere l'équation, au moins sur un temps court.)
Soyons clairs: ça sert avant tout à certifier que le TPM est un vrai TPM (et pas une émulation en soft)
Oui que l'OS n'est pas bidouillé ou virtualisé,
non et que le Media Player respecte le DRM.
non Tout ça via les AIK et les PCR.
L'EK est dans un conteneur différent des AIK. Ils ne peuvent en aucun cas se garantir l'un l'autre.
L'EK permet de garantir que l'on est bien en face d'un TPM authentique. Le système PCR/AIK permet de vérifier que telle ou telle ressource est accessible et dans le même état que la fois précédente. Grosso modo on ouvr eun coffre à clef, on fourre une clef dedans au premier passage (sans avoir aucune identification possible de ce qu'est l'OS, le bios etc.) et au deuxième passage on vérifie que l'on est bein dans la même config que lors du premier passage en lancant un challenge sur tel PCR sur la clef que l'on a mis dans ce PCR.
Et là soit on a une réponse positive, soit pas.
C'est tout.
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.
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. Ca marche très trop bien (Trop parceque le serveur X est son utilisation de SHM m'empèche de ls signer/locker proprement)
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 çà) mais prouver à uen tierce partie que le boot est bien le même que cleui de la dernière fois.
Je peux bien sur certifer le boot, l'OS, toute un groupe d'applis ou appli par appli etc. suivant le même principe.
Par contre sur les 5 liens existant seul celui ci reste, mais il y a eu un gros upload de docs récamment. Effacement malencontreux ou revirement ?
Et on va geler le déploiement de TCPA et réécrire toutes les specs pour intégrer le mécanisme d'Intel ?
Non on va simplement ocntinuer comme on a commencé : des puces sans EK dans un monde sans personen capable de certifier les EKs. Le reste de la puce TPM est très bien.
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 pas grand intéret à faire un backup des clefs non migrables. Ce sont les clefs interne à la puce et elles sont inaccessibles par l'extérieur. La procédure de maintenance complète n'est utile que dans le cas ou l'on veut récupérer aussi l'EK. Mais à part çà l'intéret est à peu près nul.
Il suffit d'intercepter le secret lorsque l'utilisateur saisit sa passphrase pour autoriser une opération protégée quelconque.
Tant bien même on arriverait à attrapper le mot de passe du owner au vol (et là on est très loin des specs TCPA et à fond dans la parano) on ne pourrait toujours pas récupérer les clefs privées de la puce TCPA en clair.
Une fois que la commande qui demande à TPM1 de transférer le package de migration vers TPM2 est lancée, tout se passe en crypté entre TPM1 et TPM2. Le owner n'a en aucun cas la main sur le transfert. 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.
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).
Certes mais les clefs non migrables sont à usage interne exclusif. Ce sont les clefs utilisés par la puce TCPA pour se valider elle même et pour crypter les PCR (exception faite de l'EK qui a un status très particulier, et qui ne peut pas être utilisé pour faire du DRM non plus - a moins que le tiers de confiance soit aussi le fournisseur de service) .
Il est très important de comprendre que els clefs non migrables ne sont pas interrogeable par l'extérieur (que ce soit par l'OS, un logiciel quelconque, ou même par le owner de la puce ) et que leur utilisation pour faire du DRM est totalement impossible.
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.
La puce TCPA n'est pas la solution ultime, mais comparée a toutes les autres solutions que j'ai pu voir c'est celle qui offre le plus haut degré de fiabilité. Elle n'est pas nécessairement parfaite, mais comparé à un disque en clair, ou même à une carte à puce qui ne valide pas la plateforme sur laquelle elle est lue, je trouve qu'il y a un vrai gain.
Maintenant il s'agit là de mon opinion, avec laquelle on peut être d'accord ou pas, et je puisse parfaitement comprendre que l'on puisse préférer une solution via carte à puce/signature mémoire/OS sur support non volatile.
Par contre l'amalgame TCPA=DRM=POUBELLE ne passe pas du tout (mais vous l'aviez déjà remarqué)
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é ?
Rien à voir du tout, Les certificats, EK et autres n'interviennent pas du tout dans les migrations de clefs et les transmissions pour maintenance. 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.
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).
Casser une clef symétrique 160 bits en sniffant des emissions "incohérentes" (Les couples clefs publiques/cles privées c'est aps comem un fichier texte, il y a grosso-modo la même proportion de chaque chiffre)
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.
Comme tu le dis, si tu veux tu peux désactiver la fonction. Par contre l'idée de pouvoir migrer/copier mes clefs d'un TCPA à l'autre me plait :
a) Parceque des fois j'aurais peut-être envie de changer de puce/machien sans pour autant changer de certificats
b) parceque des fois je veux bien avoir un certificat TCPA load-balancé sur deux machines
c) parceque tant que cette fonction sera présente l'idée même du DRM sera risible
"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 ?"
Si je veux détruire mes clefs, je refais une prise de controle du ownership du TCPA. C'est plus rapide et plus efficace
Quant à l'upgrade firmware, il s'agit peut être seulement d'allonger l'access-list des opérations soumises à autorisation du Owner (protected capbilities).
Ca pourrait, mais ca rentre dans le cadre de ce que j'apelle "grave déviation par rapport à la norme"
Aucun agent du FBI n'est venu chez moi jusqu'à présent.
Plus sérieusement ca génère une reflection assez casse pied à filtrer, c'est faisable mais c'est pas "immédiat". Ca apporte un vrai plus si le but est effectivement de se protéger contre le piratage industriel.
L'idéal pour pas beaucoup plus cher c'est d'avoir une mini soufflerie qui déplace des bouts de papiers alu dans un "aquarium" pas très loin de ton PC. Là la protection contre le rayonnement est quasiment aussi bonne que celle offerte par une cage de faraday complète, non pas que le signal est bloqué, mais qu'il est perturbé par des réflections qu'on peut considérer comme aléatoires (Et le premier qui me dit que le mouvement de particules planes dans un flux d'air est un mouvement chaotique brownien pas du tout aléatoire, il en prend une).
Je me rappelle que tu as dit quelque part que ton écran était entouré dans du papier d'alu
Calomnies ! Je n'ai jamais entouré mon écran de papier alu ! C'est la tête qu'il faut entourer pour se protéger des rayons nocifs des extra-terrestres.
Non il y a une antenne en papier alu à coté de mon écran. Ca suffit et ca génère toujours des conversations sympas quand les gens viennent chez moi.
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
Elle peut contenir. Il s'agit d'une demande qui avait été faite par certains constructeurs, lesquels sont finalement revenus sur leur décision. 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". Il y a deux personnes authorisées à générer cette clef : le constructeur de la puce ou le constructeur du PC. Le vrai problème de cette clef est que si l'on s'en sert via un tiers de confiance pour générer plusieurs certificats uniques pour des sites internet ou des services online et que les tiers de confiance sont de mêche avec les dits sites et fournisseurs de services alors on peut faire la correlation entre les différents certificats.
C'est un vrai problème de sécurité sauf que
a) Aujourd'hui il n'existe aucune puce grand public contenant l'endorsement key
b) Il n'existe aucun tiers de confiance et aucun site exigeant des certificats EK
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.
(sauf en cas de désactivation, auquel cas le TPM ne sert plus à grand chose).
C'est dommage çà. Parceque 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
Le secret partagé correspondant à la notion d'"ownership" n'est rien de plus qu'un code PIN amélioré.
Oui, et ? A ce que je sache on a toujorus pas craqué le pin d'une carte à puce. Il y a toujours une bourse de beaucoup d'argent pour le premier qui y arrive.
En fait les specs sont un peu floues (délibérément ?) quant à savoir qui génère EK
Elles sont très claires au contraires. Le fondeur ou le cosntructeur.
Mais il est clair que le TPM serait inutilisable pour faire du DRM si on laissait les utilisateurs choisir tous la même clé
Le truc c'est qui si on leur impose un certificat toujorus différent à chaque fois, TPM est quand même incapable de faire du DRM. L'EK+certifiact ne peuvent servir qu'à répondre à une demande de certification emmanant d'un tiers de confiance. C'est inutilisable pour crypter un fichier sur le disque dur par exemple.
En ce qui concerne les clefs utilisables pour crypter un fichier, elles sont déplaceables et copiable sà volonté. Ca fait un poil tache pour une utilisation DRM
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.
Une archive ne peut être créé qu'entre deux puces TCPA, et elle doit être préparé à l'avance par le owner de la puce. Le transfer se fait de la façon suivante :
Les duex TCPA se reconnaissent comme TCPA, le owner du TCPA à migrer certifie le TCPA migrateur dans son TCPA. Les deux TCPA ouvrent un canal sécurisé pour se mettre d'accord sur une clef synchro. Finalement le TCPA à migrer envoit sa base de maintenance au TCPA recepteur en prenant soin de la passer d'abord via une moulinette XOR avec la clef synchor choisit précédamment. C'est on ne peut plus classique. Quand à permettre la manip à distance par un non owner (ie uen vraie backdoor) on en est très loin.
Quand à l'upgrade firmware, ca n'est pas plus inquiétant que le reste. Vu qu'il n'y a pas de méccanisme pour forcer l'upgrade. De plus à moins que la norme ne change, il faudrait que la mise à jour casse sérieusement la compatibilité avec la norme pour devenir dangereux.
Alors tout d'abord la cryptographie et ses applicatiosn hardwares ne sont pas mon métier. D'un coté ca signifie que je ne suis pas forcément à la pointe et de l'autre que je n'ai rien à gagner financièrement à promouvoir le TPM. A toi de voir si c'est un plus ou un moins.
A l'heure actuelle je m'occupe de choses diverses au sein de l'équipe applicative de Vivendi Universal HQ (Dont on peut penser plein de choses, mais qui n'ont pas non plus d'intérets financiers direct dans TPM, même si la branche musique dont je ne susi pas lorgne violamment sur les DRM)
Au cours de ma vie j'ai fait de la crypto à haute dose (Stage avec l'université d'Evry sur l'inversibilité des multiplications via translations de base) et pas mal d'electronique (Mise au point d'une imprimante et d'un terminal braille pour aveugle).
Je suis un touche à tout (bon, OK surtout une grande gueule qui a du mal à rester longtemps dans la même boite) et plutôt pas mal paranoiaque quand ca m'amuse (Mon OpenBSD est une forteresse, même moi je ne rentre dessus qu'une fois sur trois)
Mon intéret pour TPM est celui d'un amateur ave cune bonne base technique, mais pas celui d'un chercheur ou d'un ingénieur de haut niveau sur le sujet. Par contre je peux être très casse pied quand j'ai besoin de connaitre quelque chose, et il y a pas mal de réceptionnistes à qui "Bonjour, c'est Monsieur Jérôme Herman" doit encore donner des sueurs froides.
Pour les specs TCPA je les ai lu (3x300+ pages, merci) et c'est pas très complexe à comprendre (la partie "haut niveau" est laissée à la discretion des fondeurs). Mais quand j'ai un doute je téléphone directement aux gens concernés pour poser des questions.
qui a généré la clé maître en dur dans la puce, et comment ? (a-t-elle être créée pour être plombée dès le départ, ou a-t-elle était stockée à la création par le fabricant par exemple)
Toi même. C'est une rpocédure qui s'appelle prendre possession du TPM (Taking ownership of a TPM). Sans celà le TPM est inutilisable (vous ne disposez d'aucun moyen pour créer ou lire des zones et des clefs)
puis-je changer cette clé maître ?
Oui, il suffit de refaire la procédure de prise de controle du TPM. Si celle ci a déjà été effectuée une fois, il faut connaitre le "secret" du précédent owner ou faire un reset de la puce (ce qui nécessite uen présence physique sur le poste).
Bien sur toutes les clefs contenues dans le TPM seront détruites.
le gain pour l'utilisateur justifie-t-il notamment la traçabilité amenée par un identifiant unique sur chaque processeur, et la perte de contrôle éventuelle sur ce que je peux exécuter sur mon ordinateur ?
Il y a identification , mais pas tracabilité. Avec TPM je peux générer autant d'identifiant unique que je le souhaite, et je peux donc facilemetn créer un profil PCR par site en ligne. Les différents profils seront inrecoupables.
Il n'y a pas non plus de blocage de l'ordinateur. La puce TPM reste totalement passive. Elle recoit un challenge et renvoit une réponse (ou non). C'est à peu prés tout ce qu'elle sait faire niveau interraction avec l'extérieur. Une erreur ou une absence de réponse ne peuevnt en aucun cas générer un lockdown hardware.
comment je fais si cette puce est boguée ?
Soit les fonctions d'exports fonctionnent encore, et il y a alors moyen d'exporter les clefs vers un autre TPM fonctionnel. Soit l'ensemble des clefs peut être considéré comme perdu.
est-ce forcément une super idée de regrouper mes informations les plus secrètes dans une boîte noire étiquetée « boîte à informations les plus secrètes » ?
C'est le problème du coffre fort. Chacun est libre de sa propre stratégie de sécurité. Les clefs privées contenues dan sun TPM sont supposées quasi inaccessibles et totalement inaccessibles à distance. On peut être sceptique quand à cette afirmation, mais il reste le problème de trouver uen alternative à fiabilité comparable.
Ce que tu dis est tout à fait exact. Sauf qu'à la différence d'Apple et de son Ipod ou des imprimantes et de leur marquage on sait
a) Que le TPM sans le liberticide existe, fonctionne est libre sous linux et est complètement doccumenté.
b) Que le liberticide autour se revendique d'être "Opt-in", qu'il n'est pas encore implanté et qu'il n'est même pas fini.
c) Qu'on a encore le choix de prendre du "rien du tout" et qu'en faisant un tapage on peut garder ce qui est bon pour nous et rejeter ce qui ne l'est pas.
En bref : il ne faut pas jeter bébé avec l'eau du bain. Certaines sociétés ont pour des raisons réelles (Jetez un coup d'oeuil à la norme Sarbannes-Oxley pour comprendre) besoin d'un plus en sécurité. Si on leur fait croire que ce plus ne peut être obtenu que par l'acception d'un framework Trusted Computing complet elle prendront le framework plutôt que de dépenser des milliards supplémentaires en audit de sécurité et de prier poru que les procédures soient respectées.
Par contre si on insiste sur le fait que ce dont elles ont besoin est en fait un module disponible séparément qui en nécessite en rien l'acception de l'ensemble du framework, alors elles risquent de faire pencher la balance en notre faveur. Au final on peut récupérer un outil qui protège les libertés individuelles au lieu de les mettre à mal.
[^] # Re: On va se répéter une 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.
Les PCR sont les noms des "boites" qui contiennent les données sécurisées. La question est de savori si on peut avoir la signature ou l'AIK de juste cette boite. La réponse est non, tous les hash qui sortent de la puce contiennent au minimum un sous hash du CRTM.
PCR[0-4] servent à valider la cohérence du TPM (ie prouver que le système n'a pas été compromis) donc ils sont prévisibles. Mais ce n'est pas pour autant qu'ils sortent de la puce.
j'imagine qu'il y a des PCR qui caractérisent le modèle et la version du TPM mais pas son EK unique
Bien sur, un PCR peut ne caractériser que celà, mais si tu demande un hash ou un AIK qui permet d'accéder à ce PCR une fois d eplsu le hash sortant de la puce contiendra le CRTM (et donc sera imprévisible)
Ben sans certification de la plate-forme par EK, le tiers inquisiteur n'a aucune raison de faire confiance au CRTM.
Si le CRTM était prévisible si. Il pourrait faire les calculs de son coté et vérifier la concordance.
Il faut obligatoirement deux TPM pour faire un backup ? Qu'est ce qui m'empêcherait de demander un backup vers un TPM émulé ?
Le specs. La migration n'est déclenchable que vers un autre TPM. J'imagine que l'on pourrait forcer une migration via un TPM émulé en forcant le TPM hôte à accepter le certificat du TPM émulé. Beaucoup de travail pour madame Michu...
Pourquoi ? Ce n'est pas télécommandable par le Owner ?
Non, la présence physique est requise.
Allez, une autre solution pour faire du DRM sans base de donnée centrale, et même si les hashes n'étaient jamais les même d'une machine à l'autre: Il suffit qu'à la sortie de l'usine, le constructeur boote le PC, demande le hash, génère un certificat qui dit "je garantis que le hash 0x12345678 correspond au boot d'un PC TCPA avec tel bootloader", et livre ce certificat avec le PC.
Ce serait une façon de faire, c'est dommage que la norme TCG interdise strictement qu'un TPM soit livré avec un owner prédéfini et des clefs préchargées. De plus, il faudrait également s'assurer que le propriétaire du PC ne connaisse pas le secret owner, ne puisse pas reseter la puce etc. Bref on a à 100 lieues des specs.
[^] # 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.
[^] # Re: On va se répéter une 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é à 3.
Oui mais pour utiliser ses information tu seras obliger de les décrypter, et donc d'être à la merci d'une personne qui aurait pris le controlle de ton ordinateur et qui logguerait.
La puce TPM par contre ne laisse jamais sortir les clefs privées, donc il est impossible d'obtenir une telle clef par des moyens détournées. Pour chopper la clef publique, il faut casser la clef privée... C'est quand même uen grosse faille de sécurité en moins.
[^] # Re: On va se répéter une 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.
Si tu demande un seul PCR tu auras le hash de tous les PCR pré-boot plus le PCR boot/postboot que tu as demandé. C'est l'architecture me de la puce qui empèche de renvoyer hash(OS_LOAD) par exemple. Ca sera toujours un hash imbriqué.
Pour TPM_Quote c'est le même principe, pour qu'un hash soit valide, il faut absolument qu'il prenne en compte le CRTM (ie la base de confiance des mesures). C'est même la seule façon de vérifier que les données renvoyées par le TPM sont valides.
Pourquoi M(TPM) serait-il unique ? Où vois-tu ça dans la spec ?
GNI ? L'EK est unique, normalement la signature du secret ownership aussi. Donc le CRTM sera forcément unique (aux collisions prés). c'est la base même du TPM, et la raison principale pour laquelle les TPM doivent être livrés sans owner. C'est la seule façon de s'assurer que le constructeur n'a pas pu faire une copie de notre CRTM. C'est clair que si les TPM étaient livrés avec un own et un secret prédéfini, les constructeurs pourraient noter les clefs publics et signatures comme ils peuvent le faire avec l'EK.
Autre problème si M(TPM) n'est pas unique, ca veut dire que si une personne reset la puce, elle garde quand même intact les AIK, et puet donc se faire passer pour le possesseur légal de la puce.
Bref si M(TPM) est déterministe, la puce n'apporte strictement rien en matière de sécurité.
En plus tous le meccanisme de certification de la puce par l'EK n'apporterait alors strictement rien, vu que tous les TPM (au moins d'une même marque - même modèle) auraient la même signature. Pourquoi créer des certificats supplémentaires si il suffisait de demander le hash du CRTM ?
Ben il suffit d'utiliser régulièrement la procédure de backup/migration du TPM, non ?
Oui, à l'EK près ca suffirait. Seulement madame Michu n'a pas forcément deux ordinateurs sous TPM à la maison, et monsieur DSI GrosseBoite n'a pas forcément envie de lancer une procédure de backup systématique de tous ses TPM. Surtout que cette procédure et inautomatisable.
Et puis tu connais beaucoup de SAV qui s'amusent à désouder des chips sur les cartes mère ? Et qui de plus prendraient la peine de mettre exactement la même version de firmware en remplacement pour que le TPM ne s'aperçoive de rien ?
C'est bien pour çà qu'il faut qu'un rpemplacement de carte mére à l'identique ne gène pas le TPM. Les TPM infineon par exemple sont sur des cartes filles extractibles, pour permettre une maintenance facilité (la carte mère crame, on peut quand même garder le TPM en état). Quand à la mise à jour des firmwares il est possibles grace à un système de certifications des composants de faire accepter une mise à jour de composants par le TPM sans que les clefs ne se bloquent. Cependant je ne coris pas qu'ile xiste de TPM supportant cette opération au jour d'ajourd'hui.
Toujours sous ton hypothèse douteuse que deux machines n'ont aucune chance de renvoyer le même hash.
Ce n'est pas une hypothèse. EK + signature du secret owner est unique.
Au mieux il y aura 3 versions certifiées
Par constructeur et par mois ? Ou bien il n'y aura qu'un seul constructeur par chipset existant lequel aura seulement trois versions et ne fera pas de nouveaux chipsets pendant des années ?
Honnêtement, si il n'y a que trois chipsets certifiés (mettons Intel, VIA, NVidia) par classe de chipset ca va être un vrai frein au progrès.
Soyons sérieux, Intel rien que pour les bridges CPU possède plusieurs dizaines de chipsets à l'heure actuelle, et c'est normal : il y a plusieurs classe de processeurs, des cartes mères qui vont de un à 8 processeurs, des controlleurs redondants ou non, des support mémoires ECC et/ou regsitred ou rien etc. Lesquels chispet sont intégrés différamment suivant que ce soit Intel, Asus ou Tyan qui fasse le boulot. Pour tomber à trois chipsets certifiés il faudra couper sévèrement.
Et là je ne parlerais même pas du dernier jouet de Intel : le Bios EFI qui s'assure à lui tout seul d'exploser largement les cents variantes par composant
[^] # 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.
Non je ne mélange rien, l'EK créé par le constructeur est obtenu après la certification du matériel par audit du TCG ou d'un groupe indépendant et la certification du fournisseur que c'ets bien une puce TCPA. C'est rigoureusement l'équivalent des certificats racines que l'on trouve dans les navigateurs, ils sont livrés de base parcequ'il est très complexe d'établir une chaine de confiance vis à vis de l'extérieur soi-même. Pour certifier soi-même verisign par exemple il faut se déplacer chez Verisign en personne, ou dans un organisme de confiance qui certifie verisign. Dans le cadre de TCPA il faudrait faire auditer la puce, la faire certifier, faire auditer son TCPA et le faire certifier soi-même. Un peu long et complexe comme manip non ?
OK, sauf que je ne suis pas certain que mes clés permettent de faire la même chose que EK+AIK dans le scénario du réseau d'entreprise.
Il n'y a absolument pas besoin de EK pour générer des AIK. Un AIK est uen clef associée a un PCR ou à un ensemble de PCR. 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. Le problème étant qu'il faut que je me fasse confiance à moi même (ce quid an sle cadre d'une grosse entreprise avec plusieurs intervenants n'est pas forcément aussi simple que ça)
Bon, on tourne en rond. Pour avancer, il suffirait que l'EFF ou la CNIL implémente une démo d'infrastructure DRM bien méchante à base de TCPA,
juste pour montrer à tout le monde que c'est possible et que ça peut faire mal.
Honnêtement j'ai demandé à plusieurs intervenants de divers mailing lists de faire cette implémentation, et j'ai essayé de la créer moi même. Ca fait deux ans que je m'acharne et que je provoque des gens plus doués que moi. Sans résultat.
Encore une fois, il vaudrait mieux pouvoir désactiver EK (sinon TPM_ForceClear suffit à la réactiver), pour que personne ne soit tenté d'en abuser plus tard.
TPM_ForceClear est un reset forcé de la puce pour une personne ne connaissant pas le secret owner. Quand on fait une requète TPM_ForceClear, le pc doit être rebooté. Au reboot le bios TPM charge uniquement l'OS TPM, toutes les fonctions réseaux/bus extérieurs sont désactivées pour assurer la présence physique de l'intervenant sur le PC. L'intervenant doit alors confirmer qu'il veut faire un reset de la puce, laquelle puce se retrouve alors dans le mode par défaut : pas de owner, 0 clef stoquée,toutes fonctions désactivées sauf "take ownership". Très difficile de faire celà "en douce"
Autre alternative raisonnable: permettre à l'utilisateur de remplacer l'EK d'origine par une EK prise au hasard dans un pool partagé. Ca aurait les mêmes avantages et inconvénients que le mécanisme d'attestation anonyme (DAA).
Ca aurait un autre gors inconvennient : comment s'assurer que la requète "prendre uen clef au hasard dans le pool" a bien été faite à partir d'une puce TCPA et non par un émulateur.
Si il faut un EK valide pour accéder un nouvel EK alors on peut toujours se servir des méccanismes de tracabilité (vu que j'aurais été obligé de donner pubEK pour changer d'EK). Si il n'y a pas besoin d'EK (et donc même pas besoin de owner sur la puce) n'importe quel émulateur peut faire la requète et se retrouver certifié comme un TPM valide...
[^] # Re: On va se répéter une 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.
Attention. Il est très important de se souvenir que la puce TPM ne renvoit pas les hashes individuels, mais le résultat d'une série de hashes imbriqués.
Par exemple, un chipset southbridge renverra toujours le même hash à l'intérieur du TPM via les systèmes de mesures. Cependant ce hash ne sort pas de la puce. Ce qui sort de la puce c'est hash(M(chipset1) + hash(M(chipset2) + hash(M(TPM)+ hash (M(bios) + hash(M(chipset3) + ...)))))
avec M(X) la mesure du composant X par la puce TCPA.
Il y a au minimum 8 hash imbriqués, et on peut pour créer des PCR non publics en rajouter jusqu'à 8 de plus. Comme les mesures de chaque TPM sont unique (ie M(TPM) est différent pour chaque TPM - encore heureux). Le hash qui va sortir sera également unique.
Ces précautions n'auraient aucune utilité si l'objectif était seulement de contrôler que le PC boote "dans la même config que la dernière fois".
Dans ce cadre là, les précautions ne servent à rien, elles servent par contre beaucoup dans un autre cadre : l'envoi en réparation. Supposons que le chipset1 brule et qu'il contienne un numéro de série. Si les mesures et leur hash ne sont pas prédictibles, le nouveau chipset va changer complètement tous les PCR, même le PCR public ne sera plus accessible si chipset1 fait partie des 8 composants fondamentaux qui servent à chaque PCR. En d'autres termes, chaque panne matérielle pourrait entrainner la perte de l'ensemble du contenu de la puce TPM. Ce qui fait quand même un peu désordre non ?
Je suis sûr que les constructeurs fourniront la liste de toutes les combinaisons homologuées de composants mis sur le marché, si Microsoft demande gentiment.
Même en ne prenant que les 8 hash principaux et en supposant qu'il existe un moyen de récupérer M(TPM) hors de la puce. il faut alors connaitre l'ensemble des combinaison possibles de
hash(M(chipset1) + hash(M(chipset2) + hash(M(TPM)+ hash (M(bios) + hash(M(chipset3) + hash(composant6 + hash(composant7 +hash(composant 8))))))))
Un système de hash bien fait étant ininversible il faudra comparer le hash final à l'ensemble de tous les hashs possibles à chaque fois. En supposant qu'il existe cent types de composants de chaque sorte (et là on est carrément optimiste) hors TPM cela fait 100^9x(nombre de TPM vendus) hash à connaitre en se contant seulement ici d'identifier le matériel préboot (ie le PCR public).
Après bien sur si on veut faire du drm c'est la liste de l'ensemble des
hash(M(chipset1) + hash(M(chipset2) + hash(M(TPM)+ hash (M(bios) + hash(M(chipset3) + hash(composant6 + hash(composant7 +hash(composant 8 + hash(boot + hash(system +hash(user +hash (logiciel + hahs (donneés))))))))))))) qu'il faut connaitre. Et il be faut pas oublier de régénerer l'ensemble de la base à chaque fois qu'il y a mise à jour du système ou du logiciel.
Si on table sur 10% de PC équipés de puce TPM et d'un seul utilisateur non owner par TPM ca fait 10^18x(80 000 000)² (il y a environ 800 000 000 de PC dans le monde). Ca fait 6.4x10^33 données possibles. La bonne nouvelle c'est que c'est en dessous du nombre d'atomes dans l'univers, donc techniquemetn réalisable. La mauvaise nouvelle c'est qu'on est dans une hypothèse hyper favorable et qu'on a même pas pris en compte le bios, le système, le lgoiciel ou les données....
Donc pour DRM, je continue de pas y croire un seul instant.
[^] # 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.
Voire de PrivEK (mais dans ce cas, un flag doit en principe t'indiquer que EK a été injectée et pas générée par le TPM lui-même).
Effectivemetn rien. De même que je ne susi pas sur qu'il n'y ait pas un tag sur ma carte réseau ou sur mon CPU. Je ne susi pas sur non plus que quand je désactive les fonctions EK elles ne sont pas réactivables à distance etc. L'EK fait partie d'un système de certification. Tu dois donc faire confiance au constructeur, au certificateur et au tiers inquisiteur. Effectivement dans le monde du logiciel libre on peut éviter tout celà, il suffit d'auditer le code, de compielr soit-même et de détruire les certificats racines par défaut. Dans le monde hardware il faudrait faire une puce TCPA basée sur les specs et la fondre soi-même. C'est un peu plus complexe pour l'instant
Oui, mais dans ce cas le TPM n'apporte pas grand chose par rapport à une carte à puce associée à un BIOS non flashable. Moi je préfère qu'il y ait un mécanisme de certification qui me garantit que le TPM que j'ai acheté n'est pas contrefait, que son architecture a bien été évaluée Critères Communs EALx par un labo indépendant du fabricant, etc...
Achéte une puce TCPA, vérifie la, désactive l'EK, créé tes propres clef dans le PCR public et voilà. Tu as toute les garanties possible sur ta puce et le certificat que tu utilises est le tien à 100%.
Le problème est qu'on empêche le client final de révoquer ce mécanisme de certification ou d'en prendre le contrôle et la responsabilité, alors que ce serait légitime par exemple pour un usage en entreprise.
Non, la certification requiert un tiers de confiance. Si le site Ebay me certifie qu'il est bien le site ebay, je n'ai aucun moyen de savoir si c'est vrai. Si un de mes certificat racine, obtenus via des canaux fiabilisés par une chaine de confiance mer certifie que c'est bien le site ebay, c'est bon je peux y aller.
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.
un jour, 99,9% des PC auront un TPM avec une EK indélébile et un certificat utilisable pour faire du DRM
Le certificat est utilisable pour faire de l'authentification, pour le DRM c'est impossible. L'EK ne peut pas être utilisé pour crypter du contenu de façon sécurisée. De plsu l'EK n'est lié à aucun PCR et est donc toujours accessible si on connait le secret. Je ne vois pas comment on peut faire du DRM avec çà.
L'enjeu est que les constructeurs de PC nous vendent exclusivement des TPM avec une EK révocable et remplaçable
Si on révoque l'EK
a) On détruit toutes les clefs et
b) On se coupe la possibilité de créer un certificat acceptable de l'extérieur (à moins de reafire appel à une tierce partie pour régénérer l'EK, et là on retombe dans le même schéma)
La solution offerte de désactiver l'EK me parait nettement plus simple et raisonnable.
[^] # 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é à 3.
Non en fait il y a trois niveaux dans la certification. Le premier niveau c'est juste que le fabriquant mette une clef EK valide en lançant la commande qui va bien.
Le deuxième niveau c'est que le constructeur récupère la clef d'endossement dans un coin et la garde précieusement pour fournir des certificats par la suite
Le troisième niveau c'est qu'il valide les certificats via un tiers de confiance.
IBM n'ayant pas mon EK je ne pourrais jamais être certifié....
En tout cas tu as bien un EK unique
oui
lisible par l'OS
oui - mais désactivable, désactivé par défaut (le TPM n'a même pas de owner)
. Il ne manque vraiment pas grand chose pour que tu puisses entrer dans le monde merveilleux du DRM :-)
En sachant que l'on ne peut pas se servir de a partie publique de l'EK pour faire de l'encryption ? Ca va être très dur.
Les fonctionnalités d'endossement impliquent une perte de l'anonymat, fut-elle temporaire. On peut parfaitement désactiver la clef d'endossement et ne jamais s'en servir. Personellement j'ai déployé ma propre clef dans la section publique de mes PCR et ca me va très bien pour créer des certificats entre les deux machines de mon réseau.
[^] # Re: On va se répéter une 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.
Il va avoir ennormément de mal. Le tiers de confiance peut très facilement vérifier si c'est lui ou pas qui a mis le certificat dans le TCPA. Mais supposons qu'il veuille valider un hash.
Même si on demande le hash de juste windows.exe; le TPM ne fait pas de mini hashes, il y a en fait 8 hashes successifs avant même le premier hash demandé. Les hashes contiennent : Le CPU, le Chipset, le bios, la puce TCPA elle même et la séquence préboot (les divers init)
Donc hash_tcpa(windows.exe)=hash(puce_TCPA + hash(chipset1 + hash(chipset2 + hash(CPU + hash(.... )+hash(windows.exe) ))))
Bien entendu chaque puce renvoit un hash différent. Et puis le chipset intel rev156b ne renvoit pas le même hash que le chipset intel rev156c.
Sur deux portables T42 identiques je n'ai jamais réussi à leur faire cracher deux hashes similaires.Et j'ai vraiment essayé.
Autant te dire que pour vérifier un hash et en déduire ce qu'il y a vraiment dérrière il faut y aller....
En ce qui concerne EK je pense que mon précédent poste a du t'éclairer sur ce que je voulais vraiment dire.
[^] # 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é à 3.
Non, j'ai bien une EK sur mon TPM et elle est bien certifiée au niveau 1 (sinon je me ferais jeter par les autres TPM), ce que je voulais dire est qu'elle n'est pas utilisable/activée/accessible pour les travaux de certifications third party. Je n'ai pas de certificat niveau 2 qui me permettrait d'avori des certificats niveau 3 pour me faire authentifier à l'extérieur de la puce. Grosso modo, j'ai le certificat qui dit "c'est un tcpa" mais pas celui qui dit "c'est ce tcpa là" et je ne peux donc pas créer les certificats qui disent "Mr Machin certifie que c'est bien ce tcpa là"
Mais c'est très complexe à dire. Donc ce que je veux dire c'est que je n'ai pas l'EK qui fait peur par parcequ'il identifie la machine. Et que je ne pourrais jamais l'avoir.
La certification TCPA simple suffit largement dans l'ensemble des cas, et elle n'implique pas du tout l'EK.
[^] # 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.
Par expemple pendant les migrations les hirondelles ont un mouvement brownien (donc aléatoire, donc imprédictible), mais pourtant elles vont toutes vers le sud, et en plus souvent dans le même régions (donc pas aléatoire du tout et carrément prédictible). Après il y a toute la théorie stochastique qui déboule, les notions de prévisibilité et de prévisibilité encadrée. La notion de risque et d'évènement energétiquement improbable et tout le toutim.
Comme disait mon prof, on va considérer que le mouvement est "suffisament" complètement aléatoire.
[^] # Re: On va se répéter une 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.
GNI ? Les AIK sont des descripteurs de contenu PCR (genre ce PCR a été créé avec un hash préboot+mémoire+appli "toto"+utilsateur "marcel" ).
Ah, ça c'est cool. On peut avoir des détails sur la config ?
Déjà publié par IBM, mais ca sera dans l'article, promis.
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).
Si tu veux que ton AIK soit reconnu par microsoft, i faut obligatoirement passer par un tiers de ocnfiance. Un AIK est une clef qui décrit le contenu du hashage, mais elle n'est pas "lisible" en clair. Pour prouver qu'elle correspond bien à ce qu'elle prétend être il faut nécessairement passer par un certificat.
Ce qui se passe :
Tiers inquisiteur : Il me faut l'AIK boot+windows.exe+utilisateur
TPM utilisateur : OK c'est FH67EF45DE43AC34FF22
Tiers de confiance : Je confirme c'est bien l'AIK boot+windows.exe+utilisateur (et c'est uniquement à çà que l'EK sert)
Mais alors maintenant si un petit malin c'est amusé a lancer un programme "windows.exe" sur son linux (par exemple un process idle, on va pas gacher des ressources non plus) ni le tiers inquisiteur ni le tiers de confiance ne peuvent rien y faire. 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.
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é ?
Tout à fait. Il suffit de signer le boot de chaque machine et de noter le résultat. Si il change, c'est qu'il y a entourloupe. Quand on a les PC sous la main, on a pas besoin de l'EK. On signe les PC quand on est sur qu'ils sont "propres". Et on tape sur tout ce qui change.
L'EK ne sert que pour les TPM inconnus perdus dans la nature. Pour les PC de ton réseau...
[^] # Re: On va se répéter une 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.
Tampering physique, les blobs externes sont fabriqués avec des clefs qui agissent avec l'extérieur et qui sont donc migrables (en théorie, parcequ'en pratique elles sont bloquées pendant la migration et détruites après)
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.
Dans ce cas c'est très simple, 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.
Par exemple, si l'utilisateur appartient au groupe "secretariat" sous linux, tu lui assoice un profil secretariat qui lui ouvre une clef capable de l'authentifier sur le réseau.
Si l'environement de login est modifié, alors l'utilisateur perd sa clef (le PCR se referme) et donc la connection réseau.
Mais c'est bien EK qui est à la racine de la chaîne de confiance.
Manifestement, vu la direction que prend Intel avec La Grande (Elles sont très bien les nouvelles docs de http://www.intel.com/technology/security/(...) ) ca va pas être le cas du tout. C'est l'OS qui va servir de certificat via Lagrande et la double authentification intel qui va faire office de tiers de confiance.
[^] # Re: On va se répéter une 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é à 3.
Oui vu que la clef d'endossement passe alors sur TPM2. ca ne se fait pas d'avoir deux fois le même identifiant unique. Ca serait même plutôt pas bien vu du tout.
ça m'étonnerait beaucoup qu'elles n'aient absolument aucune valeur, mais je ne maitrise pas suffisamment les specs pour argumenter.
Elles ont une ennorme valeur : elles empêchent le forcage des coffres à clefs par tampering. Mais à part çà... Que dalle.
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.
Certes, mais pour d'autres non. C'est toujours mieux à mon sens d'avori el choix. De plus si on parle de backdoor, et de fonctions non documentés, il ne sert pas à grand chose de gronder contre les fonctions qui sont doncumentés. Rien ne prouve en effet qu'il n'existe pas un moyen caché de sortir la clef, à moins de fondre la puce toi même.
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
Euh... dans une certification trois tiers il faut trois tiers. Si je te certifies être Bill Gates ou RMS ca n'a aucune valeur. Il faut que quelqu'un d'autre te certifie que je suis bien qui je prétend être. C'est exactement le but de l'EK. Donc l'EK ne peut pas être fait par le propriétaire de la puce.
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
Il est totalement impossible d'utilsier EK pour faire du DRM. EK identifie la puce, quand à savoir si cette puce est sur un PC ou un Mac, si l'OS de la machin est windows, BSD ou Linux, si le lecteur et windowsmédia ou vlc... TPM ne dispose d'aucun moyen de le gérer. Il eput certifier (ou non) que la config est bien identique à la config précédente. C'est tout.
En plus de celà, comme toutes les clefs accessibles de l'extérieur sont copiables et migrables ca n'apporte pas vraiment de garanties de ce coté là non plus.
TCPA et le DRM c'est comme les poissons et les byciclettes, les deux se déplacent, mais ils vont pas vraiment ensemble.
[^] # 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.
Vas-y sort moi l'équation complète du mouvement de chaque morceau déchirré à la main, le tout tournant dans un souflerie alimentés apr des turbines 12v mal lissé par un transfo bas de gamme alimenté par du 220v pas filtré.
Allez vas-y ! Je t'attend !
(N.B : Le truc c'est que si tu fais des réseaux de neurones à longueur de journée, tu es peut-être capable de la faire génere l'équation, au moins sur un temps court.)
[^] # 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
que l'OS n'est pas bidouillé ou virtualisé,
non
et que le Media Player respecte le DRM.
non
Tout ça via les AIK et les PCR.
L'EK est dans un conteneur différent des AIK. Ils ne peuvent en aucun cas se garantir l'un l'autre.
L'EK permet de garantir que l'on est bien en face d'un TPM authentique. Le système PCR/AIK permet de vérifier que telle ou telle ressource est accessible et dans le même état que la fois précédente. Grosso modo on ouvr eun coffre à clef, on fourre une clef dedans au premier passage (sans avoir aucune identification possible de ce qu'est l'OS, le bios etc.) et au deuxième passage on vérifie que l'on est bein dans la même config que lors du premier passage en lancant un challenge sur tel PCR sur la clef que l'on a mis dans ce PCR.
Et là soit on a une réponse positive, soit pas.
C'est tout.
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.
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. Ca marche très trop bien (Trop parceque le serveur X est son utilisation de SHM m'empèche de ls signer/locker proprement)
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 çà) mais prouver à uen tierce partie que le boot est bien le même que cleui de la dernière fois.
Je peux bien sur certifer le boot, l'OS, toute un groupe d'applis ou appli par appli etc. suivant le même principe.
Ca m'intéresse. Des références ?
http://www.intel.com/technology/security/downloads/scms19_direct_pr(...)
Par contre sur les 5 liens existant seul celui ci reste, mais il y a eu un gros upload de docs récamment. Effacement malencontreux ou revirement ?
Et on va geler le déploiement de TCPA et réécrire toutes les specs pour intégrer le mécanisme d'Intel ?
Non on va simplement ocntinuer comme on a commencé : des puces sans EK dans un monde sans personen capable de certifier les EKs. Le reste de la puce TPM est très bien.
[^] # Re: On va se répéter une 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é à 3.
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 pas grand intéret à faire un backup des clefs non migrables. Ce sont les clefs interne à la puce et elles sont inaccessibles par l'extérieur. La procédure de maintenance complète n'est utile que dans le cas ou l'on veut récupérer aussi l'EK. Mais à part çà l'intéret est à peu près nul.
Il suffit d'intercepter le secret lorsque l'utilisateur saisit sa passphrase pour autoriser une opération protégée quelconque.
Tant bien même on arriverait à attrapper le mot de passe du owner au vol (et là on est très loin des specs TCPA et à fond dans la parano) on ne pourrait toujours pas récupérer les clefs privées de la puce TCPA en clair.
Une fois que la commande qui demande à TPM1 de transférer le package de migration vers TPM2 est lancée, tout se passe en crypté entre TPM1 et TPM2. Le owner n'a en aucun cas la main sur le transfert. 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.
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).
Certes mais les clefs non migrables sont à usage interne exclusif. Ce sont les clefs utilisés par la puce TCPA pour se valider elle même et pour crypter les PCR (exception faite de l'EK qui a un status très particulier, et qui ne peut pas être utilisé pour faire du DRM non plus - a moins que le tiers de confiance soit aussi le fournisseur de service) .
Il est très important de comprendre que els clefs non migrables ne sont pas interrogeable par l'extérieur (que ce soit par l'OS, un logiciel quelconque, ou même par le owner de la puce ) et que leur utilisation pour faire du DRM est totalement impossible.
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.
La puce TCPA n'est pas la solution ultime, mais comparée a toutes les autres solutions que j'ai pu voir c'est celle qui offre le plus haut degré de fiabilité. Elle n'est pas nécessairement parfaite, mais comparé à un disque en clair, ou même à une carte à puce qui ne valide pas la plateforme sur laquelle elle est lue, je trouve qu'il y a un vrai gain.
Maintenant il s'agit là de mon opinion, avec laquelle on peut être d'accord ou pas, et je puisse parfaitement comprendre que l'on puisse préférer une solution via carte à puce/signature mémoire/OS sur support non volatile.
Par contre l'amalgame TCPA=DRM=POUBELLE ne passe pas du tout (mais vous l'aviez déjà remarqué)
[^] # Re: On va se répéter une 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.
Rien à voir du tout, Les certificats, EK et autres n'interviennent pas du tout dans les migrations de clefs et les transmissions pour maintenance. 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.
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).
Casser une clef symétrique 160 bits en sniffant des emissions "incohérentes" (Les couples clefs publiques/cles privées c'est aps comem un fichier texte, il y a grosso-modo la même proportion de chaque chiffre)
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.
Comme tu le dis, si tu veux tu peux désactiver la fonction. Par contre l'idée de pouvoir migrer/copier mes clefs d'un TCPA à l'autre me plait :
a) Parceque des fois j'aurais peut-être envie de changer de puce/machien sans pour autant changer de certificats
b) parceque des fois je veux bien avoir un certificat TCPA load-balancé sur deux machines
c) parceque tant que cette fonction sera présente l'idée même du DRM sera risible
"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 ?"
Si je veux détruire mes clefs, je refais une prise de controle du ownership du TCPA. C'est plus rapide et plus efficace
Quant à l'upgrade firmware, il s'agit peut être seulement d'allonger l'access-list des opérations soumises à autorisation du Owner (protected capbilities).
Ca pourrait, mais ca rentre dans le cadre de ce que j'apelle "grave déviation par rapport à la norme"
[^] # 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é à 4.
Aucun agent du FBI n'est venu chez moi jusqu'à présent.
Plus sérieusement ca génère une reflection assez casse pied à filtrer, c'est faisable mais c'est pas "immédiat". Ca apporte un vrai plus si le but est effectivement de se protéger contre le piratage industriel.
L'idéal pour pas beaucoup plus cher c'est d'avoir une mini soufflerie qui déplace des bouts de papiers alu dans un "aquarium" pas très loin de ton PC. Là la protection contre le rayonnement est quasiment aussi bonne que celle offerte par une cage de faraday complète, non pas que le signal est bloqué, mais qu'il est perturbé par des réflections qu'on peut considérer comme aléatoires (Et le premier qui me dit que le mouvement de particules planes dans un flux d'air est un mouvement chaotique brownien pas du tout aléatoire, il en prend une).
[^] # 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.
Calomnies ! Je n'ai jamais entouré mon écran de papier alu ! C'est la tête qu'il faut entourer pour se protéger des rayons nocifs des extra-terrestres.
Non il y a une antenne en papier alu à coté de mon écran. Ca suffit et ca génère toujours des conversations sympas quand les gens viennent chez moi.
[^] # 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é à 4.
Elle peut contenir. Il s'agit d'une demande qui avait été faite par certains constructeurs, lesquels sont finalement revenus sur leur décision. 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". Il y a deux personnes authorisées à générer cette clef : le constructeur de la puce ou le constructeur du PC. Le vrai problème de cette clef est que si l'on s'en sert via un tiers de confiance pour générer plusieurs certificats uniques pour des sites internet ou des services online et que les tiers de confiance sont de mêche avec les dits sites et fournisseurs de services alors on peut faire la correlation entre les différents certificats.
C'est un vrai problème de sécurité sauf que
a) Aujourd'hui il n'existe aucune puce grand public contenant l'endorsement key
b) Il n'existe aucun tiers de confiance et aucun site exigeant des certificats EK
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.
(sauf en cas de désactivation, auquel cas le TPM ne sert plus à grand chose).
C'est dommage çà. Parceque 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
Le secret partagé correspondant à la notion d'"ownership" n'est rien de plus qu'un code PIN amélioré.
Oui, et ? A ce que je sache on a toujorus pas craqué le pin d'une carte à puce. Il y a toujours une bourse de beaucoup d'argent pour le premier qui y arrive.
En fait les specs sont un peu floues (délibérément ?) quant à savoir qui génère EK
Elles sont très claires au contraires. Le fondeur ou le cosntructeur.
Mais il est clair que le TPM serait inutilisable pour faire du DRM si on laissait les utilisateurs choisir tous la même clé
Le truc c'est qui si on leur impose un certificat toujorus différent à chaque fois, TPM est quand même incapable de faire du DRM. L'EK+certifiact ne peuvent servir qu'à répondre à une demande de certification emmanant d'un tiers de confiance. C'est inutilisable pour crypter un fichier sur le disque dur par exemple.
En ce qui concerne les clefs utilisables pour crypter un fichier, elles sont déplaceables et copiable sà volonté. Ca fait un poil tache pour une utilisation DRM
[^] # Re: On va se répéter une 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é à 4.
Une archive ne peut être créé qu'entre deux puces TCPA, et elle doit être préparé à l'avance par le owner de la puce. Le transfer se fait de la façon suivante :
Les duex TCPA se reconnaissent comme TCPA, le owner du TCPA à migrer certifie le TCPA migrateur dans son TCPA. Les deux TCPA ouvrent un canal sécurisé pour se mettre d'accord sur une clef synchro. Finalement le TCPA à migrer envoit sa base de maintenance au TCPA recepteur en prenant soin de la passer d'abord via une moulinette XOR avec la clef synchor choisit précédamment. C'est on ne peut plus classique. Quand à permettre la manip à distance par un non owner (ie uen vraie backdoor) on en est très loin.
Quand à l'upgrade firmware, ca n'est pas plus inquiétant que le reste. Vu qu'il n'y a pas de méccanisme pour forcer l'upgrade. De plus à moins que la norme ne change, il faudrait que la mise à jour casse sérieusement la compatibilité avec la norme pour devenir dangereux.
[^] # 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é à 8.
A l'heure actuelle je m'occupe de choses diverses au sein de l'équipe applicative de Vivendi Universal HQ (Dont on peut penser plein de choses, mais qui n'ont pas non plus d'intérets financiers direct dans TPM, même si la branche musique dont je ne susi pas lorgne violamment sur les DRM)
Au cours de ma vie j'ai fait de la crypto à haute dose (Stage avec l'université d'Evry sur l'inversibilité des multiplications via translations de base) et pas mal d'electronique (Mise au point d'une imprimante et d'un terminal braille pour aveugle).
Je suis un touche à tout (bon, OK surtout une grande gueule qui a du mal à rester longtemps dans la même boite) et plutôt pas mal paranoiaque quand ca m'amuse (Mon OpenBSD est une forteresse, même moi je ne rentre dessus qu'une fois sur trois)
Mon intéret pour TPM est celui d'un amateur ave cune bonne base technique, mais pas celui d'un chercheur ou d'un ingénieur de haut niveau sur le sujet. Par contre je peux être très casse pied quand j'ai besoin de connaitre quelque chose, et il y a pas mal de réceptionnistes à qui "Bonjour, c'est Monsieur Jérôme Herman" doit encore donner des sueurs froides.
Pour les specs TCPA je les ai lu (3x300+ pages, merci) et c'est pas très complexe à comprendre (la partie "haut niveau" est laissée à la discretion des fondeurs). Mais quand j'ai un doute je téléphone directement aux gens concernés pour poser des questions.
Voilà. A toi de te faire ton idée.
[^] # 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é à 6.
Toi même. C'est une rpocédure qui s'appelle prendre possession du TPM (Taking ownership of a TPM). Sans celà le TPM est inutilisable (vous ne disposez d'aucun moyen pour créer ou lire des zones et des clefs)
puis-je changer cette clé maître ?
Oui, il suffit de refaire la procédure de prise de controle du TPM. Si celle ci a déjà été effectuée une fois, il faut connaitre le "secret" du précédent owner ou faire un reset de la puce (ce qui nécessite uen présence physique sur le poste).
Bien sur toutes les clefs contenues dans le TPM seront détruites.
le gain pour l'utilisateur justifie-t-il notamment la traçabilité amenée par un identifiant unique sur chaque processeur, et la perte de contrôle éventuelle sur ce que je peux exécuter sur mon ordinateur ?
Il y a identification , mais pas tracabilité. Avec TPM je peux générer autant d'identifiant unique que je le souhaite, et je peux donc facilemetn créer un profil PCR par site en ligne. Les différents profils seront inrecoupables.
Il n'y a pas non plus de blocage de l'ordinateur. La puce TPM reste totalement passive. Elle recoit un challenge et renvoit une réponse (ou non). C'est à peu prés tout ce qu'elle sait faire niveau interraction avec l'extérieur. Une erreur ou une absence de réponse ne peuevnt en aucun cas générer un lockdown hardware.
comment je fais si cette puce est boguée ?
Soit les fonctions d'exports fonctionnent encore, et il y a alors moyen d'exporter les clefs vers un autre TPM fonctionnel. Soit l'ensemble des clefs peut être considéré comme perdu.
est-ce forcément une super idée de regrouper mes informations les plus secrètes dans une boîte noire étiquetée « boîte à informations les plus secrètes » ?
C'est le problème du coffre fort. Chacun est libre de sa propre stratégie de sécurité. Les clefs privées contenues dan sun TPM sont supposées quasi inaccessibles et totalement inaccessibles à distance. On peut être sceptique quand à cette afirmation, mais il reste le problème de trouver uen alternative à fiabilité comparable.
[^] # 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é à 4.
a) Que le TPM sans le liberticide existe, fonctionne est libre sous linux et est complètement doccumenté.
b) Que le liberticide autour se revendique d'être "Opt-in", qu'il n'est pas encore implanté et qu'il n'est même pas fini.
c) Qu'on a encore le choix de prendre du "rien du tout" et qu'en faisant un tapage on peut garder ce qui est bon pour nous et rejeter ce qui ne l'est pas.
En bref : il ne faut pas jeter bébé avec l'eau du bain. Certaines sociétés ont pour des raisons réelles (Jetez un coup d'oeuil à la norme Sarbannes-Oxley pour comprendre) besoin d'un plus en sécurité. Si on leur fait croire que ce plus ne peut être obtenu que par l'acception d'un framework Trusted Computing complet elle prendront le framework plutôt que de dépenser des milliards supplémentaires en audit de sécurité et de prier poru que les procédures soient respectées.
Par contre si on insiste sur le fait que ce dont elles ont besoin est en fait un module disponible séparément qui en nécessite en rien l'acception de l'ensemble du framework, alors elles risquent de faire pencher la balance en notre faveur. Au final on peut récupérer un outil qui protège les libertés individuelles au lieu de les mettre à mal.