la norme dont tu parles c'est des documents vieux de plusieurs années faute d'avoir les documents actuels sous NDA
par contre Intel a accès à tous les documents actuels et les slides de son pDF sont clairs: le hash d'un composant est signable et envoyable à un challenger !
Deja je ne troube pas cela si clair, ensuite le PDF vise manifestement un plubic de neophyte et ne porte pas la marque d'un serieux technologique irreprochable. Je veux bien conceder qu'il y ait eu des modifications de faite en vue de la preparation de la norme TCPA2 et je n'ai pas acces aux doccuments sous NDA. Mais cela m'etonnerais beaucoup quand meme et s'eloignerais vraiment de l'esorit de la norme TCPA1. Pour finir le doccument d'Intel ne parle jamais d'envoyer une signature du Hash a un challenger, si un element doit posseder une telle information c'est le repositary qui va s'y coller. Un challenger n'a rien a faire d'un hash signe, lequel est inutile pour un challenge. Seul une clef publique certifiee par une tierce authorite l'interresse, et c'est le role du repositary de la lui fournir.
fournir le hash d'un bootloader est largement suffisant pour savoir de quel bootloader il s'agit !
Non le hash du boot loader ne donne aucune information utilisable sur le boot loader lui meme. Cela a revient a deviner le contenu d'un doccument a partir d'un MD5. Pire je me suis livree a une petite experience avec mon X31. J'ai fait un backup du disque via drive image et je l'ai restore. Plus moyen d'acceder aux clefs dont la dispo depend du PCR du bootloader (et uniquement de cela). Je ne sais pas ce qui a change (en theorie rien) mais le TPM s'est rendu compte de la modif. Bref le meme bootloader avec la meme config ne recoit pas le meme checksum lors du hashage apres une reinstall.
J'imagine que pour faire un hashage constant il faudrait que la puce puisse ignorer certains params mineurs. Par contre pour faire un hashage constant de machine a machine d'un autre modele il faudrait que la puce soit capable de mettre de cote tout un tas de parametres pour ne garder que l'essentiel du boot loader, ie elle soit capable de faire abstraction du type de disque, de sa taille, de sa geometrie, du partionnement etc. car se sont des informations variables de config a config et qui sont necessaires pour que le BIOS puisse passer la main a un autre systeme.
en ce qui ocncerne le mbr: pourquoi ne serait--il pas en 2 parties: partie exécutables et partie données qui prend en compte les spécificités du disques
Si il faut malgré tout un 2e type de MBR pour certains cas particuliers , leur hash sera répertoriable aussi
Cela demanderait une modification en profondeur du systeme de boot et donc a la fois du bios, des cartes meres et des disques durs. A l'heure actuelle le bios ne fait que charger le premier bootloader qui lui passe sous la main avant de l'executer. Et la puce TCPA ne fait que prendre une photo du bios avec le bootloader charge.
enfin il ne sera pas forcément interdit de booter sur autre chose que le HDD, mais l'OS bootera dans un mode spécial et alors tu ne pourras plus montrer patte blanche aux fournisseurs de contenus DRM (en l'occurence un hash connu pour le MBR)
Cela n'est valable que si le hash signe est en fait une clef publique challengeable (et donc techniquement pas juste un hash signe). Si c'est juste un hash signe rien ne m'empeche de l'envoyer aussi apres avoir faire un TCP dump sur une transaction legale. Si c'est une clef publique Normalement je dois pouvoir la migrer vers une autre zone (d'apres mon vetuste doccument). Et de totue facon la relation checksum => bootloader est loin d'etre triviale.
encore plus drole: la génération et/ou la signature de certains programmes du boot peut très bien venir de MS lui même lors de la procédure interactive (par internet) d'activation de windows
Pour etre valable cette procedure implique que Microsoft sait deja que le boot que je viens d'effectuer (et par extension le PCR) est valable. Ce qui lui est impossible vu que c'est precisement cette information qu'il essaye de certifier.
je n'ai jamais parlé d'une zonne de donnée mais bien du hash d'un exécutable !
Nous sommes bien d'accord, mais dans les architectures que je connais le seul executable chargeable par le bios est l'init du bootloader, lequel est beaucoup trop versatile pour que l'on puisse pretendre le reconnaitre apres un hashage. A moins de lui appliquer un traitement tres particulier coder en dur dans la puce je ne vois pas comment on peut faire la relation checksum->bootloader.
tu crois que Intel n'a pas envie de faire de la concurence au Secure Computing ? si, et lagrande/TrustedComputing semble tout indiqué pour cela
Je ne dis pas que ca ne sera jamais le cas, Intel a deja prouve qu'ils etaient tres interresse par des systemes d'identification unique et de profiling. Je dis juste que pour l'instant, dans la mesure de mes connaissances TCPA n'est pas utilisable pour faire de l'identification DRM, et ceci ni au niveau materiel, ni au niveau logiciel.
quelle clé ? moi je ne parle pas dans ce cas de clé mais de hashes non modifiables stockés dans le PCR lors du boot d'un OS MS
ces hashes sont amplement suffisants à identifier le MBR et s'assurer que c'est un MBR MS
CF plus haut dans ce posts pour mes arguments. La norme dit que c'est interdit et la relation hashage->bootloader est non triviale.
Je ne comprends pas, penses-tu sincèrement qu'on puisse démontrer que des specs aussi énormes (et non entièrement divulguées) que TCG sont toujours inattaquables du point de vue des défenseurs de la liberté ?
Non mais premierement ce que j'ai vu et lu (une bonne trentaine de fois) m'a clairemet rassure. Deuxiement : il faut toujours laisse le benefice du doute, TCPA se defend farouchement de pouvoir etre utilise en DRM et il apporte un reel confort en securite. Troisiemement si on passe notre temps a crier au lopu on prend le risque de se retrouver sans personnes pour nous ecouter au moment ou on aura vraiment un probleme.
La faille que tu penses avoir trouvee (et non la recherche n'est pas inutile, j'ai moi meme passe des heures avec le graph fonctionnel de TCPA sous les yeux) ne me parait pas credible. Je ne pense pas que celle-ci existe pour les raisons evoques ci dessus.
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 0.
par contre Intel a accès à tous les documents actuels et les slides de son pDF sont clairs: le hash d'un composant est signable et envoyable à un challenger !
Deja je ne troube pas cela si clair, ensuite le PDF vise manifestement un plubic de neophyte et ne porte pas la marque d'un serieux technologique irreprochable. Je veux bien conceder qu'il y ait eu des modifications de faite en vue de la preparation de la norme TCPA2 et je n'ai pas acces aux doccuments sous NDA. Mais cela m'etonnerais beaucoup quand meme et s'eloignerais vraiment de l'esorit de la norme TCPA1. Pour finir le doccument d'Intel ne parle jamais d'envoyer une signature du Hash a un challenger, si un element doit posseder une telle information c'est le repositary qui va s'y coller. Un challenger n'a rien a faire d'un hash signe, lequel est inutile pour un challenge. Seul une clef publique certifiee par une tierce authorite l'interresse, et c'est le role du repositary de la lui fournir.
fournir le hash d'un bootloader est largement suffisant pour savoir de quel bootloader il s'agit !
Non le hash du boot loader ne donne aucune information utilisable sur le boot loader lui meme. Cela a revient a deviner le contenu d'un doccument a partir d'un MD5. Pire je me suis livree a une petite experience avec mon X31. J'ai fait un backup du disque via drive image et je l'ai restore. Plus moyen d'acceder aux clefs dont la dispo depend du PCR du bootloader (et uniquement de cela). Je ne sais pas ce qui a change (en theorie rien) mais le TPM s'est rendu compte de la modif. Bref le meme bootloader avec la meme config ne recoit pas le meme checksum lors du hashage apres une reinstall.
J'imagine que pour faire un hashage constant il faudrait que la puce puisse ignorer certains params mineurs. Par contre pour faire un hashage constant de machine a machine d'un autre modele il faudrait que la puce soit capable de mettre de cote tout un tas de parametres pour ne garder que l'essentiel du boot loader, ie elle soit capable de faire abstraction du type de disque, de sa taille, de sa geometrie, du partionnement etc. car se sont des informations variables de config a config et qui sont necessaires pour que le BIOS puisse passer la main a un autre systeme.
en ce qui ocncerne le mbr: pourquoi ne serait--il pas en 2 parties: partie exécutables et partie données qui prend en compte les spécificités du disques
Si il faut malgré tout un 2e type de MBR pour certains cas particuliers , leur hash sera répertoriable aussi
Cela demanderait une modification en profondeur du systeme de boot et donc a la fois du bios, des cartes meres et des disques durs. A l'heure actuelle le bios ne fait que charger le premier bootloader qui lui passe sous la main avant de l'executer. Et la puce TCPA ne fait que prendre une photo du bios avec le bootloader charge.
enfin il ne sera pas forcément interdit de booter sur autre chose que le HDD, mais l'OS bootera dans un mode spécial et alors tu ne pourras plus montrer patte blanche aux fournisseurs de contenus DRM (en l'occurence un hash connu pour le MBR)
Cela n'est valable que si le hash signe est en fait une clef publique challengeable (et donc techniquement pas juste un hash signe). Si c'est juste un hash signe rien ne m'empeche de l'envoyer aussi apres avoir faire un TCP dump sur une transaction legale. Si c'est une clef publique Normalement je dois pouvoir la migrer vers une autre zone (d'apres mon vetuste doccument). Et de totue facon la relation checksum => bootloader est loin d'etre triviale.
encore plus drole: la génération et/ou la signature de certains programmes du boot peut très bien venir de MS lui même lors de la procédure interactive (par internet) d'activation de windows
Pour etre valable cette procedure implique que Microsoft sait deja que le boot que je viens d'effectuer (et par extension le PCR) est valable. Ce qui lui est impossible vu que c'est precisement cette information qu'il essaye de certifier.
je n'ai jamais parlé d'une zonne de donnée mais bien du hash d'un exécutable !
Nous sommes bien d'accord, mais dans les architectures que je connais le seul executable chargeable par le bios est l'init du bootloader, lequel est beaucoup trop versatile pour que l'on puisse pretendre le reconnaitre apres un hashage. A moins de lui appliquer un traitement tres particulier coder en dur dans la puce je ne vois pas comment on peut faire la relation checksum->bootloader.
tu crois que Intel n'a pas envie de faire de la concurence au Secure Computing ? si, et lagrande/TrustedComputing semble tout indiqué pour cela
Je ne dis pas que ca ne sera jamais le cas, Intel a deja prouve qu'ils etaient tres interresse par des systemes d'identification unique et de profiling. Je dis juste que pour l'instant, dans la mesure de mes connaissances TCPA n'est pas utilisable pour faire de l'identification DRM, et ceci ni au niveau materiel, ni au niveau logiciel.
quelle clé ? moi je ne parle pas dans ce cas de clé mais de hashes non modifiables stockés dans le PCR lors du boot d'un OS MS
ces hashes sont amplement suffisants à identifier le MBR et s'assurer que c'est un MBR MS
CF plus haut dans ce posts pour mes arguments. La norme dit que c'est interdit et la relation hashage->bootloader est non triviale.
Je ne comprends pas, penses-tu sincèrement qu'on puisse démontrer que des specs aussi énormes (et non entièrement divulguées) que TCG sont toujours inattaquables du point de vue des défenseurs de la liberté ?
Non mais premierement ce que j'ai vu et lu (une bonne trentaine de fois) m'a clairemet rassure. Deuxiement : il faut toujours laisse le benefice du doute, TCPA se defend farouchement de pouvoir etre utilise en DRM et il apporte un reel confort en securite. Troisiemement si on passe notre temps a crier au lopu on prend le risque de se retrouver sans personnes pour nous ecouter au moment ou on aura vraiment un probleme.
La faille que tu penses avoir trouvee (et non la recherche n'est pas inutile, j'ai moi meme passe des heures avec le graph fonctionnel de TCPA sous les yeux) ne me parait pas credible. Je ne pense pas que celle-ci existe pour les raisons evoques ci dessus.
Kha