Humeur : Du respect de la vie privée et secrète du geek en milieu urbain
Posté par Benoît Sibaud (Jabber id, page perso, ). Modéré le 18 août 2005.
Bien sûr j'utilisais des logiciels libres, car pourquoi ferais-je confiance à des logiciels propriétaires boîtes noires, contenant potentiellement des portes dérobées ou des espiogiciels. Je ne communiquais qu'en https, mes courriels étaient tous chiffrés, mes partitions aussi, et de toute façon mes remarques sur la météo et le sexe opposé ne circulaient que dans des images de gnous en utilisant de la stéganographie. Et je me croyais tranquille.
C'était sans compter sur le déploiement de nouveaux ordinateurs équipés en standard de TPM (oui l'informatique dite « de confiance », TCPA/Palladium, ayez confiance, tout ça) qui étaient déjà sur le marché. Et les imprimantes qui se mettaient à bavasser aussi. Sans compter aussi que certains aimeraient bien collecter toutes les données de trafic internet et téléphonique (le courrier postal n'intéresse personne...), en évoquant des questions de sécurité, voire créer des e-milices sur les réseaux (de toute façon on me proposait déjà de confier mes clés de chiffrement aux forces de police, sachant qu'ils savaient s'en passer si besoin). Ceci dit les débats sur la nouvelle carte d'identité électronique en France avaient laissé perplexe (identifiant unique, données biométriques, mélange de l'officiel et du commercial, etc.).
De son côté l'industrie de la musique et du cinéma promettait des mesures techniques de protection pour décider si et quand et combien de fois je pourrais lire le DVD que j'avais acheté, et avec quel matériel et quel logiciel, en arguant des cataclysmes apocalyptiques et tentaculaires causés par des lycéens de 12 ans ; on me promettait même des identifiants uniques sur chaque disque et un blocage de la copie privée pourtant légale. Finalement on me proposait de bénéficier des puces d'identification par radio-fréquences RFID aux usages multiples : traçage des étrangers, contrôle des papiers d'identité, implantation sous-cutanée...
Bah il ne me restait plus qu'à aller poser devant les caméras dans la rue (Paris, Londres, etc.), et à reprendre des pilules. Enfin ça ou essayer d'améliorer les choses.
« Nous avons neuf mois de vie privée avant de naître, ça devrait nous suffire. » (Heathcote Williams)
« Même les paranoïaques ont des ennemis. » (Albert Einstein)
> Lire la dépêche (173 commentaires, moyenne: 3,2).
Vous avez demandé le commentaire #612824.
On va se répéter uen dernière fois
TPM n'est pas dangereux (dans les normes 1.0, 1.1, 1.2 et 2.0). Il est inutilisable pour la tracabilité, les drm ou le blocage machine.
La Grande (La surcouche d'Intel) c'est nettement moins sur. Et si La Grande est dangereux, l'implémentation du Trusted Computing complet par Microsoft a de bonnes chances d'être une horreur.
Mais la puce TPM est une belle invention, partique, utile, sure et fiable.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
tu peux répêter "la Terre est plate" autant qu'il te plaira, ça ne te donnera pas raison.
Windows has no users. It has hostages.
[^]Re: On va se répéter uen dernière fois
on en a deja discuter de ca :-D
; as tu une preuve de securite de ta puce ? non donc ce n'est pas sur. on ne sais pas comment ils sortent leurs numeros aleatoires (vrai aleas ???) , on ne sait pas comment ils protegent leurs contenus. on ne sait pas si il y a pas un mode superutilisateur qui permet de recuperer les cles etc ...tu dis
Donc le sure et fiable me semble premature (a moins que tu ais acces au vhdl ?)
Si c'etait effectivement sur oui ca serait bien ; mais bon une puce qui sert de base a des techniques liberticides je ne lui accorde pas le benefice du doute .
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: On va se répéter une dernière fois
Ne pas confondre la norme TCPA/TPM et els éventuelles implémentations.
En ce qui concerne la norme, on a un degré de sécurité difficilement égalable. La clef privée étant inaccessible et ne pouvant être déplacée que par des manoeuvres longues et complexes et seulement à destination d'un autre TPM.
Les contenus "sesnibles" sont protégéspar non accès extérieur. Pour lire uen clef directement, il faut ouvrir la puce et venir ce brancher sur les bus interne. C'est nettement plus compelxe que de percer un coffre fort.
Chaque "coffre" à clef (PCR) fait des mesures de huits points de matériels et du pré-boot pour générer la clef d'authentification. Même si la qualité de l'algo est faible, une suite de MD5 octuple imbriqués reste très difficile à casser. Donc même si la clef elle même est généré par un aléa douteux, la falsification d'une puce rsique d'être très complexe.
mais bon une puce qui sert de base a des techniques liberticides je ne lui accorde pas le benefice du doute .
C'ets justement le truc. La puce TPM ne sert absolument pas de base aux techniques liberticides. Seulement comme il est assez difficile de vendre un produit qui n'a d'autre utilité que de fliquer son utilisateur, on rajoute la puce à coté pour faire un bundle "attractif".
Il n'y a aucun rapport entre la puce TPM et (par exemple) les canaux sécurisés de La Grande. Le fait que La Grande utilise la puce TPM pour stoquer ses clefs est un plus, mais absolument pas une nécessité. Si un site web décide de stoquer ses clefs dans la puce TPM ca ne ferait pas de la puce un tueur d'internet non plus.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
Pour lire une clef directement, il faut ouvrir la puce et venir ce brancher sur les bus interne. C'est nettement plus compelxe que de percer un coffre fort.
Ca c'est toi qui le dis .
Le but du vhdl c'est d'en etre sur. Voir l'exemple des puces motorola dans mon message plus bas.
Il n'y a aucun rapport entre la puce TPM et (par exemple) les canaux sécurisés de La Grande. Le fait que La Grande utilise la puce TPM pour stoquer ses clefs est un plus, mais absolument pas une nécessité
Tu dis qu'il n'y a pas de rapport ensuite tu dis qu'il y en a un...
C'est pas une necessite mais c'est ce qui va se passer. Et donc je veux etre sur que mes cles soient bien en secu c'est legitime non?
Je n 'ai rien contre le principe de la puce tpm . Mais je m'extasie pas devant une nouvelle techno parceque c'est une nouvelle techno.
Les exemples de puces cryptographiques "rate" sont plutot frequent.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: On va se répéter une dernière fois
Tu dis qu'il n'y a pas de rapport ensuite tu dis qu'il y en a un...
C'est dans el sens ou la puce TPM, bien qu'utilisé par Lagrande n'apporte rien du tout à la méccanique des systèmes de canaux cryptés. (A la limite ils apporteraient plutot une faille, vu que les clefs TPM challengeables sont exportables et qu'on pourrait peut-être "écouter le contenu d'un canal avec une autre puce TPM branchée en parallèle").
Tout le méccanisme de protection (ségementation hardware, test actifs, isolation, bloquages etc.) sont fait par du hardware dédié.
Et donc je veux etre sur que mes cles soient bien en secu c'est legitime non?
Pour tes clefs privées tu as le choix entre deux options : En clair sur ton ordinateur (même si c'est pour des temps très bref) ou enfermés dans uen puce coffre fort dans laquelle elle est née et d'ou elle ne peut théoriquement (et c'est pour la certitude qu'il faudrait le VHDL nous sommes d'accord) pas sortir sauf intervention lourde nécessitant une présence physique sur la machine.
L'existence d'une backdoor permettant la récupération de l'ensemble des clefs contenues dans une puce (et à distance de préférence) ets une pure hypothèse (même si on a déjà vu les américains forcer els constructeurs à ce genre de choses). Ceci étant comparé à "en clair sur le disque dur" (ou la clef USB) je ne peux m'empécher de penser qu'il y a un progrès.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
Pas d'accord. La spec TPM encourage les constructeurs à implémenter une API pour transférer le contenu d'un TPM vers un autre (TPM_CreateMaintenanceArchive, TPM_LoadMaintenanceArchive). Il y a un baratin pas du tout crédible qui dit que le constructeur déchiffre l'archive, mais à moitié seulement, grâce à un XOR miraculeux. D'ailleurs ce pipeau est dans un "informative comment", pas dans la partie normative.
Si ça ne suffit pas, il y a aussi un mécanisme optionnel qui permet au constructeur d'upgrader le firmware du TPM (Field Upgrade). Est-il besoin d'en dire plus ?
Tout ça est dans https://www.trustedcomputinggroup.org/downloads/tpmwg-mainrev62_Part(...) section 13 pour ceux qui ont le temps de se faire une opinion par eux-mêmes.
Ces fonctions sont optionnelles, et leur présence aura évidemment un impact sur les profils Critères Communs auxquels un TPM pourra prétendre. On peut se douter que les militaires n'auront pas les mêmes TPMs que le grand public (si tant est que les militaires choisissent d'utiliser TCPA).
AC
[^]Re: On va se répéter une dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
Et le TPM1 vérifie que le certificat du TPM2 est bien signé par le constructeur ? Et il télécharge tout seul des CRL pour vérifier qu'il n'est pas révoqué ?
En fait je suppose il fait entièrement confiance au Owner, comme tu le suggères. Dès lors il est possible de migrer vers un TPM2 bidon.
Quant à l'autorisation du Owner et à la moulinette XOR, elles sont protégées au mieux par le secret symmétrique de 160 bits, que l'on peut forcément sniffer avec une backdoor dans l'OS ou le BIOS. Donc le tour est joué, y compris à distance. A moins de mettre ce secret et tous les algos qui l'utilisent dans un autre module "de confiance" (une carte à puce, par exemple).
La simple existence de cette fonction de maintenance est en contradiction avec le principe de base d'un token crypto: même le propriétaire ne devrait jamais pouvoir extraire les clés. D'ailleurs il y a une commande TPM_KillMaintenanceFeature pour la désactiver, mais j'imagine déjà le dialogue dans le TPM Wizard: "Attention, en désactivant cette fonction, vous risquez de perdre irrémédiablement vos clés, et d'être en infraction avec l'article 434-15-2 du Code Pénal relatif au recouvrement des conventions de chiffrement. Voulez-vous vraiment continuer ?"
Merci pour tes clarifications techniques, mais je ne suis toujours pas rassuré.
P.S. Quant à l'upgrade firmware, il s'agit peut être seulement d'allonger l'access-list des opérations soumises à autorisation du Owner (protected capbilities).
[^]Re: On va se répéter une dernière fois
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"
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
Non, ça c'est la procédure de Backup/Migration, je suppose.
Je parle de la procédure de Maintenance (section 13 de la spec), qui n'est réalisable qu'avec l'assistance du constructeur, et qui permet de transférer même les données marquées comme "non migrables".
Il n'y a rien à casser. On parle de backdoors et d'attaques avec la complicité du constructeur de TPM et du fournisseur de l'OS, dans le but d'extraire des clés que l'utilisateur croyait à l'abri dans ton TPM. Il suffit d'intercepter le secret lorsque l'utilisateur saisit sa passphrase pour autoriser une opération protégée quelconque.
Là tu donnes de faux espoirs à certains.
Avec les procédures de Backup/Migration, l'utilisateur ne peut transférer que les clés marquées comme migrables (donc probablement pas les clés de DRM).
Les clés non migrables ne sont transférables que par le SAV du constructeur (procédure de Maintenance).
Le problème n'est pas de savoir détruire les clés (il y a le marteau pour ça), mais de continuer à les utiliser en sachant si elles sont réellement à l'abri.
AC
[^]Re: On va se répéter une dernière fois
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é)
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
La procédure de maintenance complète n'est utile que dans le cas ou l'on veut récupérer aussi l'EK.
Je doute que la maintenance puisse migrer EK. L'entité qui réalise l'opération est même censée révoquer l'EK de TPM1 et informer les autorités de certification (page 65).
Concernant l'intérêt d'extraire les clés non migrables, ça m'étonnerait beaucoup qu'elles n'aient absolument aucune valeur, mais je ne maitrise pas suffisamment les specs pour argumenter.
La seule façon de récupérer les clefs en clair serait de les migrer (ie secret du owner, préparation d'un package de migration, déclaration du TPM d'acceuil et en option depuis la V2.0 présence physique ) vers un TPM qui permet l'accès aux clefs en clair.
Donc avec la procédure de backup/migration il suffit bien d'intercepter le secret du Owner (même pas besoin de la collaboration du constructeur). Pour ça il suffira d'une backdoor ou d'un bug exploitable dans un OS, même certifié. D'ailleurs c'est comme ça que le boot sécurisé de la Xbox a été contourné.
Pour beaucoup d'applications il vaut mieux perdre la clé en cas de panne matérielle, que de prévoir un mécanisme de backup aussi vulnérable.
Par contre l'amalgame TCPA=DRM=POUBELLE ne passe pas du tout
Je suis d'accord. TCPA pourrait être idéal pour chiffrer son disque, protéger la clé SSL de son serveur web, ou administrer un réseau bureautique d'entreprise.
Le problème est que les exigences du DRM ont une influence très lourde sur la norme TCPA. Pour les trois applications ci-dessus, il n'y a aucune raison d'empêcher le propriétaire du PC de détruire le certificat du constructeur et de gérer EK lui-même (ce qui serait plus satisfaisant du point de vue de la confidentialité et de la vie privée).
Mais si Microsoft et Vivendi se retrouvent face à un parc installé où 10% des clients ont effacé le certificat EK d'origine de leur TPM, ils ne pourront plus faire passer le DRM de façon indolore. C'est pour ça que tu ne peux pas générer EK sur tes chips, et que tu ne pourras pas le changer sur les futurs modèles, à moins de payer ton TPM plus cher (c'est écrit en clair dans les release notes TPM_1_2_Changes_Final.pdf).
AC
[^]Re: On va se répéter une dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
elles empêchent le forcage des coffres à clefs par tampering.
Tampering physique ? Ou déchiffrage des blobs externes ? (auquel cas ce serait évidemment très intéressant de savoir extraire ces clés non migrables).
Donc l'EK ne peut pas être fait par le propriétaire de la puce.
C'est pourtant utile lorsque le propriétaire du PC n'est pas l'utilisateur.
Exemple: l'administrateur d'un réseau d'entreprise qui veut contrôler les applis qui tournent sur son réseau.
Il est totalement impossible d'utilsier EK pour faire du DRM
En effet, il faut tout le reste de l'infrastructure, ainsi que des périphériques durcis, et des compétences pour produire des logiciels garantis sans bugs, donc c'est pas demain la veille.
Mais c'est bien EK qui est à la racine de la chaîne de confiance.
AC
[^]Re: On va se répéter une dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
Si le pirate a les moyens d'attaquer physiquement le TPM, il peut probablement extraire les clés non migrables en même temps que les données qui sont chiffrées avec. Bon, je veux bien croire qu'il y a des zones qui s'auto-détruisent mieux que les autres quand on démonte le chip.
tu créé un profil et tu lui associe divers PCR avec les applications ou groupe d'applications que l'utilisateur a le droit de lancer.
Tout le problème est de savoir si cette gestion de profils peut être faite de façon sûre sans EK. A suivre dans l'autre thread
http://linuxfr.org/comments/613763.html#613763(...)
En tout cas merci pour la discussion, j'en profite pour découvrir les specs TCPA, et il n'y a pas grand monde capable de débattre sur les détails techniques.
AC
[^]Re: On va se répéter une dernière fois
La simple existence de cette fonction de maintenance est en contradiction avec le principe de base d'un token crypto: même le propriétaire ne devrait jamais pouvoir extraire les clés. D'ailleurs il y a une commande TPM_KillMaintenanceFeature pour la désactiver, mais j'imagine déjà le dialogue dans le TPM Wizard: "Attention, en désactivant cette fonction, vous risquez de perdre irrémédiablement vos clés, et d'être en infraction avec l'article 434-15-2 du Code Pénal relatif au recouvrement des conventions de chiffrement. Voulez-vous vraiment continuer ?"
ce qui signifie qu il est illegale en france de realiser un module cryptographique hardware vraiment secure ?
www.doublehp.org
le site qui sera toujours en construction ...
[^]Re: On va se répéter une dernière fois
ça fait des années que ça dure, tout gouvernement veut que ses petites affaires restent secrètres tout en se réservant le droit d'accéder aux tiennes si besoin est.
Windows has no users. It has hostages.
[^]Re: On va se répéter une dernière fois
ce qui signifie qu il est illegale en france de realiser un module cryptographique hardware vraiment secure ?
Non, seulement de refuser de déchiffrer. Tu peux probablement répondre à la sommation des autorités en déchiffrant à l'aide de ton module, sans révéler la clé elle-même.
Evidemment, si tu as la même coupe de cheveux qu'un certain terroriste londonien, et que tu racontes que ton module vient de tomber en panne, ça va faire louche.
[^]Re: On va se répéter une dernière fois
Ceci étant comparé à "en clair sur le disque dur" (ou la clef USB) je ne peux m'empécher de penser qu'il y a un progrès.
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, lorsque c'est purement materiel, il n'y a plus aucun moyen de contrôle.
J'aurais l'audace de comparerer ça au vote éléctronique (inverifiable, comme le TPM) par rapport au vote papier (vérifiable par tous comme les logiciels libres), je crois qu'il n'y a pas photo sur le degré de confiance que l'on peut faire à l'un et à l'autre.
Un ex: la distribe live CD Knoppix MiB
http://www.bouissou.net/knoppix-mib/doc-html/Knoppix-Mib.html(...)
[^]Re: On va se répéter une dernière fois
Dans du libre aussi tu peux mettre des mouchards, ça n'empèche rien (bon dans certains cas c'est peut-être plus compliqué mais pas là ). Et si c'est fait au niveau matériel, que tu ais une clé USB ou une carte à puce, tu es b*sé. La différence c'est que si ta carte à puce est "sûre", même si tu l'utilise sur un PC "hostile", on ne peut pas récupérer la clé qui est dessus (bon on peut quand même pendant que la carte est connectée) alors qu'avec une clé USB, si. C'est pas avec un liveCD que tu vas être sauvé (d'ailleurs c'est indiqué sur la page de MiB), sauf peut-être avec Tinfoil Hat Linux :op (http://tinfoilhat.shmoo.com/(...) ) .
Pas besoin que ça soit *purement* matériel, même avec un minimum au niveau hardware (clé USB ?), tu ne peux plus être sûr de tout contrôler.Je dois avouer que plus je lis les commentaires de cette dépèche et moins j'ai l'impression de comprendre TCPA et compagnie mais je doute fort que ça soit moins "sécurisé" qu'une clé USB et si le brol est standardisé, c'est tout autant accessible aux logiciels libres qu'aux logiciels propriétaires.
Pour ce qui est de la comparaison au vote électronique, que tu utilises une clé USB, une carte à puce ou TCPA/TPM/machin, tu ne sais que (très) difficilement contrôler ce qui se passe en dessous d'un certains niveau donc la clé USB n'est pas beaucoup mieux du point de vue de la transparence.
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: On va se répéter une dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
(a moins que tu ais acces au vhdl ?)
Si je peux éviter un ordinateur avec une puce TPM, je le ferais. Mais quant à parler du code source des composants, je ne pense pas que le raisonnement tienne longtemps. Tu as les sources de ta puce réseau, de ton proc, du BIOS de ta carte mère, pour ne parler que de composants sensibles ?
[^]Re: On va se répéter uen dernière fois
A ce que je sache le bios ne conserve pas les cles ,Pas plus que la cr ni que le proc...
Avoir le hdl du puce crypto et d'un puce autre ont deux but bien differents.
Le but du vhdl sur une puce cryptographique c'est d'eviter les modes "super utilisateur" comme sur certaines puces motorola (ou mode entretien ou mode ...) qui donnait les cles qu'ils etaient cense conserve.
Ca peut sembler con mais de tels puces ont deja ete utilise dans des appareils. La cryptanalyse desdits appareils a ete plutot simple dans ce cas.
De plus c'etait pour repondre au message "la puce est sur et fiable" On en sais rien qu'elle est sur ni qu'elle est fiable parce que par definition on ne peut pas avoir les algos utilise.
Tu dirais qu'un logiciel proprietaire DE CRYPTO est sur et fiable sans aucune preuve alors qu'il est assez peu repandu et utilise depuis assez peu de temps ?
Enfin je suis toujours etonne par la mauvaise foi des pro tpm qui moinsse les messages , non pas qu'ils soient inutile (car a mon avis poser des question n'est pas inutile ) mais simplement qu'ils ne correspondent pas a leurs avis. Ca reflete bien le type de personne que c'est : moi j'ai tout le temps raison.
Heureusement qu'il existe des pro tpm qui ne moinsse pas (enfin j'espere)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: On va se répéter uen dernière fois
attention, le VHDL est un langage :
http://fr.wikipedia.org/wiki/Very_High_Speed_Integrated_Circuit_Har(...)
utilisé ici, ca revenait à demander si on avait le code source des composants soi-disant de sécurité (et le fait qu'on ne peut plus raisonnablement les fabriquer soi-même depuis longtemps n'est pas un détail)
Windows has no users. It has hostages.
[^]Re: On va se répéter uen dernière fois
je reprend ma phrase alors :
Le but du vhdl sur une puce cryptographique c'est d'eviter les modes "super utilisateur"
donne:
"Le but du vhdl sur une puce cryptographique c'est d'eviter les modes "super utilisateur" en verifiant dans le hdl de la non presence de backdoor ;)"
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: On va se répéter uen dernière fois
arf
Qu'est-ce qui te prouve que le HDL qu'on te donne est bien celui de ta puce ? Sur du soft tu peux toujours recompiler. Sur du hard je vois mal comment tu pourrais faire.
[^]Re: On va se répéter uen dernière fois
si tu prefere auditer le code par une societe tiers et independante qui surveille tous le processus de fabrication.
C'etait pour le principe le hdl ; pour montrer qu'on a aucune certitude de ce qu'il y a dans la puce.
Maintenant si tu veux que je te donne un protocole complet de certification j'en suis incapable mais ca fera pas avancer le schimlblick.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: On va se répéter uen dernière fois
Je fais un peu de off topic mais ta dernière remarque est vraiment pertinente : il y a visiblement beaucoup de gens qui ne doivent pas comprendre ce que pertinent veut dire... Tu fais un post intéressant et tu te retrouves moinssé parceque quelqu'un n'a pas les mêmes idées que toi, ce qui est tout de même fort dommage en plus d'être injuste.
Peut-être serait-il judicieux de faire démarrer les notes plus haut de manière à ce que des messages intéressants ne se retrouvent pas "non visibles" dès le départ car moinssé par des opposants au contenu.
Voilà , désolé pour le off topic :(
[^]Re: On va se répéter uen dernière fois
Alors fait une dépêche complète, argumentée et documentée pour nous expliquer tout ça de manière simple et compréhensible par un geek de base. Ça t'évitera de te répeter dans 149273 commentaires, et ça me (nous ?) permettra d'apprendre quelque chose.
[^]Re: On va se répéter uen dernière fois
Je suis en train d'écrire un article.
En ce qui cocnerne les dépèches argumentés, les posts complets, les arguments contrés et les longs threads (notamment contre free2) j'ai très largement fait mon boulot.
Si je regarde juste dans l'historique des commentaires de ma page perso (http://linuxfr.org/~khane/(...) ) on y trouve :
http://linuxfr.org/comments/609635.html#609635(...)
http://linuxfr.org/comments/609658.html#609658(...)
http://linuxfr.org/comments/609667.html#609667(...)
Dans une news récente, j'en ai pas mal soupé
https://linuxfr.org/2005/06/18/19158.html(...)
Seulement je suis d'accord qu'il faut un article clair et simple. Mais c'est très long à faire. je susi dessus depuis deux mois, j'avance bien même si j'ai beaucoup de mal à obtenir les informations (sur La Grande notamment) sans signer de NDA.
Le gros problème est que l'amalgame TCPA/La Grande/Trusted Computing entretien l'illusion que l'on ne eput avoir l'un sans les autres, ce qui est faux. On peut avoir une puce de sécurisation sous le controle total de l'utilisateur sans se frapper toute la clique de matériel espion et limitatif.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
Oui, je sais, je te vois ramer à chaque news/journal qui aborde le sujet pour essayer de faire passer ton point de vue sur TCPA et les sujets connexes. Le problème, c'est que l'argumentation est disséminée dans plein de commentaires, donc pour _vraiment_ comprendre ton message, c'est pas évident (surtout que le sujet lui-même n'est pas évident du tout). Donc un bon article complet sur le sujet serait très pertinent.
Si besoin, je veux bien être relecteur pour l'article en question : je peux jouer le rôle du relecteur-neuneu-de-base-qui-connait-pas-grand-chose-voire-rien-a-TCPA ;-)
[^]Re: On va se répéter uen dernière fois
discourir que TPM est innocent ou juste un outil comme une machette, dont seul l'utilisateur serait responsable d'un mauvais usage, me fait une belle jambe : en tant que consommateur final avec un budget à taille humaine, je n'aurais jamais accès à juste TPM-pas-dangereux, on me filera le pack complet liberticide, ou rien (similaire à acheter de la musique avec DRM liée à une machine ou un iPod, ou ne pas pouvoir acheter de musique)
le vrai utilisateur, le client de ces petits bidules, ce n'est pas moi, mais le marchand de PC et de matériel qui doit les intégrer pour que son matériel soit autorisé (euh, zut, on dit reconnu) par Microsoft qui tient 90 % du marché, moi je vais juste être un gentil consommateur avec un sourire béat à qui on va tendre le produit fini, une grosse boite avec ces petits bidules cachés - ou pas de boite du tout.
être au courant ne change pas grand chose : essayez d'acheter un iPod sans DRM à Apple, ils vous diront qu'ils ne font pas. une imprimante ou un photocopieur couleur qui ne rajoute pas les petits bidules qui contiennent le numéro de série de l'engin ? aucun fabricant ne fait, quelque soit le prix.
pour le reste, le matériel qui va bien sera simplement plus cher au début, ensuite il ne sera plus fabriqué ou tout simplement déclaré illégal à la vente et à l'importation
Windows has no users. It has hostages.
[^]Re: On va se répéter uen dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
Je ne suis pas expert sur la puce TPM. Prenons par exemple comme description http://www.tomshardware.com/hardnews/20040916_143806.html(...) . À la lecture on peut se poser les questions suivantes :
- 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)
- puis-je changer cette clé maître ?
- 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 ?
- comment je fais si cette puce est boguée ?
- 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 » ?
[^]Re: On va se répéter uen dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
Pas d'accord. Le TPM contient bien une clé asymétrique codée en dur (EK, Endorsement Key), non modifiable par l'utilisateur, ainsi que le certificat correspondant signé par le constructeur et lisible par l'OS (sauf en cas de désactivation, auquel cas le TPM ne sert plus à grand chose).
Les specs TPM mentionnent explicitement que ça pose des problèmes de traçabilité puisque le certificat identifie de manière unique le TPM.
(https://www.trustedcomputinggroup.org/downloads/tpmwg-mainrev62_Part(...) TPM Main specification version 1.2 Part 1 Design Principles, page 25).
Le secret partagé correspondant à la notion d'"ownership" n'est rien de plus qu'un code PIN amélioré.
En fait les specs sont un peu floues (délibérément ?) quant à savoir qui génère EK. Mais il est clair que le TPM serait inutilisable pour faire du DRM si on laissait les utilisateurs choisir tous la même clé, ou émuler leur TPM en soft. Donc inutile de réver.
AC
[^]Re: On va se répéter uen dernière fois
Une correction: la dernière version des specs prévoit la possibilité de changer EK (TPM_RevokeTrust, TPM_CreateRevocableEK).
Mais le document TPM_1_2_Changes_final explique que les chips qui supportent cette fonctionalité seront plus chers que les autres. Autrement dit, aucun constructeur ne les intégrera dans ses PC.
AC
[^]Re: On va se répéter uen dernière fois
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
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
Soyons clairs: ça sert avant tout à certifier que le TPM est un vrai TPM (et pas une émulation en soft), que l'OS n'est pas bidouillé ou virtualisé, et que le Media Player respecte le DRM. Tout ça via les AIK et les PCR.
Ben oui: Si tu veux faire des choses compliquées, par exemple du boot sécurisé, tu dois acheter un TPM avec un EK et un certificat codés en dur. Sinon, on te vend un TPM sans EK et tu te contentes de l'utiliser pour stocker des clés. Mais on ne te laisse pas gérer EK toi même. Pourtant ce serait très utile pour des applications en entreprise. Bizarre, non ?
Les premiers DVD commercialisés n'étaient pas chiffrés, même quand CSS était déjà dans la norme.
Ca m'intéresse. Des références ?
Et on va geler le déploiement de TCPA et réécrire toutes les specs pour intégrer le mécanisme d'Intel ?
AC
[^]Re: On va se répéter uen dernière fois
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.
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
L'EK est dans un conteneur différent des AIK. Ils ne peuvent en aucun cas se garantir l'un l'autre.
D'après les specs les AIK sont des alias de EK (pour limiter la traçabilité), donc il ne sont quand même pas complètement indépendants.
Ah, ça c'est cool. On peut avoir des détails sur la config ?
Certifier le boot ne veux pas dire pouvoir prouver à une tierce partie que l'OS sur lequel je bosse est bien un windows (TCPA est totalement incapable de faire çà )
Ben si, quand même. Le TPM répond à un challenge en signant le PCR correspondant à la config Windows avec un AIK reconnu par Microsoft (via le tiers de confiance éventuel).
mais prouver à uen tierce partie que le boot est bien le même que cleui de la dernière fois.
Et ta config permet-elle de faire ça, la tierce personne étant quelqu'un d'autre que toi ?
Par exemple, dans une entreprise, permet-elle à l'administrateur de détecter qu'un utilisateur est en train d'essayer de se connecter au réseau avec un OS non autorisé ?
Il me semblait que pour ça il faut des AIK, et donc un EK (certifié par le constructeur ou au moins par l'administrateur).
AC
[^]Re: On va se répéter une dernière fois
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...
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
On a demander à TPM de signer windows.exe, il l'a fait et basta. Ce qu'est windows.exe il n'en sait rien et il s'en moque.
Evidemment, mais le tiers inquisiteur, lui, décidera de faire confiance à la plate-forme ou pas en fonction de la valeur du hash. Bon, on ne va pas épiloguer sur le fait que TCPA peut être utilisé, si on le souhaite, comme un composant essentiel d'une infrastructure de DRM.
Quand on a les PC sous la main, on a pas besoin de l'EK.
Logistiquement, c'est un cauchemar d'avoir les PC sous la main. Le protocole à base d'EK certifiés par le constructeur permet à l'administrateur d'activer les PC à distance.
On signe les PC quand on est sur qu'ils sont "propres".
En pratique l'administrateur veut signer un seul PC "propre" de référence et télécharger le PCR correspondant vers tous les TPM de son réseau, sans se déplacer, à chaque fois que c'est nécessaire. Sans crypto asymétrique (EK), ça va être très très chaud. Surtout quand on voudra mettre à jour les PCR précisément parce qu'on vient de s'apercevoir que la config "propre" n'était pas si propre que ça...
Et quid du petit malin qui ramène un PC en panne au SAV ? Est-ce qu'on lui signe son PC ? Sans EK, comment savoir si c'est un vrai TPM qui est dedans ?
Bref, moi je veux des puces TCPA avec EK, parce que c'est plus sûr et plus flexible. Mais je veux aussi avoir le contrôle de mon EK pour éviter que d'autres en abusent.
AC
[^]Re: On va se répéter une dernière fois
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)
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
Sur deux portables T42 identiques je n'ai jamais réussi à leur faire cracher deux hashes similaires.Et j'ai vraiment essayé.
Pourtant la spec TCG PC Specific Implementation Specification fait tout ce qu'il faut pour que certains hashes soient prédictibles. Par exemple, elle exige que les numéros de série et autres identifiants uniques ne soient pas hashés, ainsi que les portions du MBR spécifiques à la géométrie du disque. 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". Etrange, non ?
Et quels registres PCR as-tu comparés entre tes deux machines ? J'ai l'impression que seuls PCR[0]-PCR[4] sont conçus pour être bien déterministes.
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....
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.
AC
[^]Re: On va se répéter une dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
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.
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 ?
Même si TPM_Quote n'acceptait de signer que des hashes intègrant plusieurs PCR, un système de DRM pourrait en parallèle lire les PCR individuels avec TPM_Read, les hasher lui-même, et comparer son résultat avec le hash signé. Si la fonction de hachage est bien choisie, ça suffit à certifier chaque PCR.
(ie M(TPM) est différent pour chaque TPM - encore heureux).
Pourquoi M(TPM) serait-il unique ? Où vois-tu ça dans la spec ?
chaque panne matérielle pourrait entrainner la perte de l'ensemble du contenu de la puce TPM.
Ben il suffit d'utiliser régulièrement la procédure de backup/migration du TPM, non ?
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 ?
Ca fait 6.4x10^33 données possibles.
Toujours sous ton hypothèse douteuse que deux machines n'ont aucune chance de renvoyer le même hash.
De plus, j'imagine que les constructeurs auront beaucoup de paperasse à remplir pour avoir le droit de certifier des composants et des PC complets. Donc il est clair que les utilisateurs n'auront plus le choix entre 36 versions de BIOS comme aujourd'hui. Au mieux il y aura 3 versions certifiées et 33 versions "beta". Idem pour les drivers Windows certifiés par Microsoft.
AC
[^]Re: On va se répéter une dernière fois
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
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
C'est l'architecture me de la puce qui empèche de renvoyer hash(OS_LOAD)
Bien sûr, ça ne servirait à rien de savoir que le PC fait tourner Windows, si on ne sait pas ce que le BIOS et tous les inits ont fait avant.
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.
L'EK est unique, normalement la signature du secret ownership aussi.
De même que les numéros de série du BIOS ne sont pas incorporés dans tous les PCR, j'imagine qu'il y a des PCR qui caractérisent le modèle et la version du TPM mais pas son EK unique. Le tiers inquisiteur peut demander les PCR appropriés selon qu'il veut faire du DRM ou seulement du boot sécurisé.
Pourquoi créer des certificats supplémentaires si il suffisait de demander le hash du CRTM ?
Ben sans certification de la plate-forme par EK, le tiers inquisiteur n'a aucune raison de faire confiance au CRTM.
Seulement madame Michu n'a pas forcément deux ordinateurs sous TPM à la maison
Il faut obligatoirement deux TPM pour faire un backup ? Qu'est ce qui m'empêcherait de demander un backup vers un TPM émulé ?
(sauf pour les clés non-migrables et CMK, évidemment).
Surtout que cette procédure et inautomatisable.
Pourquoi ? Ce n'est pas télécommandable par le Owner ?
Soyons sérieux, Intel rien que pour les bridges CPU possède plusieurs dizaines de chipsets à l'heure actuelle
Certes, mais les combinaisons effectivement mises sur le marché, c'est à dire les modèles de PC, ne couvrent pas toutes les combinaisons possibles des composants.
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. Ca revient à implémenter la base de façon distribuée. Mais il est vrai qu'il n'y a rien de tel dans les specs, à ma connaissance.
AC
[^]Re: On va se répéter une dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
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.
Ah, alors si j'appelle TPM_ReadPCR(0) Ã TPM_ReadPCR(4), j'obtiens quoi ?
Et si j'appelle TPM_Quote(0x11111000), je n'obtiens pas un hash portant sur PCR[0-4] et eux seuls ?
Par ailleurs PCR[0-4] ne concernent pas seulement l'intégrité du TPM. En particulier, PCR[4] inclut le MBR (en prenant soin d'exclure la géométrie du disque, qui n'est pas assez prévisible).
AC
[^]Re: On va se répéter une dernière fois
Ah, alors si j'appelle TPM_ReadPCR(0) Ã TPM_ReadPCR(4), j'obtiens quoi ?
Et si j'appelle TPM_Quote(0x11111000), je n'obtiens pas un hash portant sur PCR[0-4] et eux seuls ?
En théorie bien sur, mais tu auras PCR[0] dans le lot, donc comme PCR[0] contient déjà le CRTM tu auras déjà un hash impossible à corréler. A partir du moment ou dans un hash tu demandes le PCR[0], le résultat de ce hash n'est pas intrepretable vu que PCR[0] contient la mesure du CRTM (et donc implicitement la mesure de l'EK) et la mesure du owner. Or tu ne peux pas ne pas demander PCR[0], vu le principe même de l'extend des hash.
PCR[0] - ce que j'appelais M(TPM) précédamment est totalement unique pour chaque TPM et change à chaque reset/TakeOwnership
Par contre si tu essayes de demander PCR[1-3] par exemple (donc CPU, ESCD,CMOS, NVRAM + BIOS, OPTION ROMS + OPTION ROMS CONFIGURATION) tu te fais jeter. La puce TCPA ne sait pas construire de hash autrement qu'Ã partir de PCR[0] et en remontant (principe de l'extend).
Par ailleurs PCR[0-4] ne concernent pas seulement l'intégrité du TPM.
Non ca concerne l'intégrité du système préboot. Si je t'ai laissé penser le contraire, j'en suis désolé.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter une dernière fois
Or tu ne peux pas ne pas demander PCR[0], vu le principe même de l'extend des hash.
Ce n'est pas cohérent. Si ça fonctionnait comme tu le dis, l'argument passé à TPM_Quote n'aurait pas besoin d'être un bitmask. Ce serait simplement le numéro du dernier PCR à intégrer dans le hash.
Il me semble évident que le principe d'agrégation séquentielle (ce que tu appelles "extend") s'applique aux registres PCR indépendamment les uns des autres. A tout moment, PCR[0] donne l'historique du CRTM depuis le reset de la machine. PCR[4], c'est l'historique de tous les bootloaders qui ont été essayés. PCR[5] loggue la géométrie du disque et, en cas de multiboot, la partition qui a été sélectionnée. Et PCR[6] enregistre carrément toutes les mises en hibernation du PC.
PCR[0] - ce que j'appelais M(TPM) précédamment est totalement unique pour chaque TPM et change à chaque reset/TakeOwnership
Ce n'est pas ce que je lis dans TCG_PCSpecificSpecfication_v1_1.pdf:
"Only executable code is logged."
"Configuration data such as ESCD should not be measured as part of this PCR."
"Entities that MUST be measured: the CRTM's version identifier (...)"
Il n'est jamais question de logger EK. Ce serait même choquant, car ça fournirait un identifiant globalement unique même lorsque la lecture de PubEK est désactivée.
si tu essayes de demander PCR[1-3] par exemple (...) tu te fais jeter.
Bon, tu as essayé sur ta machine ? TPM_ReadPCR(1) et TPM_Quote(0x00001110) renvoient un code d'erreur ? Lequel ?
AC
[^]Re: On va se répéter une dernière fois
Ca fait trois jours que je me rpend la tête sur tes questions qui sont tout à fait valides. Et çà fait trois jours que je tourne en rond sans aucune réponse qui me convienne.
A force de ne pas avoir de réponse valable dan sun sens ni dans l'autre , j'ai fini par prendre mon tournevis et démonter les 2 T42 sous TCPA. Là je me suis rendu compte avec horreur que les deux modèles de cartes LPC étaient différents - de fait il est un peu normal que j'obtienne jamais deux fois le même PCR. Dans l'ordre :
a) Un IBM T42 c'ets très chiant à démonter, et c'est pire à remonter
b) Ma base de test pour quand je ne suis pas sur de comprendre la doc était fausse.
c) Ca fait potentiellement deux ans que je raconte des conneries (ou pas) sur le TPM.
d) Je dois de plates excuses à f.free2.org
Ce qui est encore sur :
- la clef d'endossement (EK) n'est toujours pas utilisable directement pour faire du DRM, car elle est toujours active et interrogeable quelque soit la config du TPM (Ã partir du moment ou le TPm est actif bien sur)
- les AIK liés à un PCR particulier ne sont pas facilement utilisable pour DRM non plus, vu qu'ils ne peuvent que signer et non decrypter.
- PCR[0] est immuable, il ne change pas sans intervention du constructeur. Le changement de owner ne l'influe donc pas (honte sur moi).
Ce qui mérite enquète :
- une clef liée à un PCR lui même liée à un AIK pourrait être utilisée pour du DRM. Pour celà il faudrait réussir à faire un TPM_WRAPKey en réussissant à bloquer l'interception des Auh et migrAuth par un logiciel tiers. Celà est peut-être faisable via un méccanisme de session.
- Si les clefs PCR[0-4] sont prédictibles, un challenger avec uen base de données conséquente peut connaitre votre matériel (avec révision et options) même si il n'est pas jugé digne de confiance.
- Un PCR non initialisé peut très vite donner à un challenger une méthode pour scanner les programmes s'executant sur votre machine, pour peu que ceux ci soient rigides (toujours dans l'hypothèse ou les PCR sont disjoints et ou les hashs osnt prédictibles)
En ce moment j'essaye de joindre des gens compétents chez IBM et au TCG pour avoir des réponses.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
j'ai deux puces TCPA chez moi, qui n'ont pas d'EK, aucun moyen d'en rajouter une et qui fonctionnent très bien. L'EK est puremetn facultative et ne touche qu'une partie marginale des fonctions TCPA
Tiens, une question très simple:
D'après les specs, pour exécuter TPM_TakeOwnership, il faut que EK soit initialisé (car le secret partagé doit être chiffré avec PubEK).
Comment as-tu pu prendre possession de tes chips si ils n'ont pas de EK ?
Est-ce que TPM_ReadPubEK renvoie vraiment TPM_NO_ENDORSEMENT ?
Ou seulement TPM_DISABLED_COMMAND ? (ce qui signifierait que la lecture de PubEK est restreinte, mais il reste TPM_OwnerReadInteralPub).
Tu voulais peut-être dire que le vendeur ne t'a pas fourni le certificat EK en même temps que la machine ?
AC
[^]Re: On va se répéter uen dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
La certification TCPA simple suffit largement dans l'ensemble des cas, et elle n'implique pas du tout l'EK.
Ce que tu appelles certification simple, c'est le mécanisme à base de protocole zéro-knowledge (DAA) ajouté dans la version 1.2 ?
En tout cas tu as bien un EK unique, lisible par l'OS (avec autorisation de l'Owner si tu as pris la précaution d'appeler TPM_DisablePubekRead), et que tu n'es probablement pas libre de modifier. Il ne manque vraiment pas grand chose pour que tu puisses entrer dans le monde merveilleux du DRM :-)
Si jamais le "niveau" est stocké dans le certificat mais pas dans le TPM lui-même, il suffit que le constructeur décide de te délivrer un nouveau certificat. "C'est gratuit et c'est plus sûr, pourquoi refuser ?"
AC
[^]Re: On va se répéter uen dernière fois
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.
Kha
root est un privilège, pas un droit !
[^]Re: On va se répéter uen dernière fois
IBM n'ayant pas mon EK je ne pourrais jamais être certifié....
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).
En sachant que l'on ne peut pas se servir de a partie publique de l'EK pour faire de l'encryption ?
On se sert de PubEK pour faire du chiffrement, par exemple pour insérer le secret partagé du Owner à distance.
On peut parfaitement désactiver la clef d'endossement et ne jamais s'en servir.
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...
Le problème est qu'on empêche le client final de révoquer ce mÃ