Bon je me suis un peu calme et jesuis desole pour le post plus haut. Mais j'etais vraiment en rogne.
Je ne remet pas un seul instant en question tes connaissances en informatiques, pas plus que je ne remet en question celles de M Anderson. Mais je pense simplement que sur ce point particulier il y a des chose que vous n'avez pas comprises, ce sont des points techniques surement completement disjoints de ce que vos domaines de connaissances respectifs.
Par exemple pour le hashage du boot. Tu me certifie que l'on peut identifier l'os en fonction du hashage de l'init du boot loader. Ce n'est pas possible pour les raisons suivantes :
1) Le boot loader n'est pas forcement l'OS loader, dans le cas de linux, BSD et Windows bases sur technologie NT ce n'est pas le cas. Le Boot loader et l'OS loader sont disjoint. Mais pire parfois l'init du boot loader et le boot loader lui meme sont differents. Dans le ca sle plus complexe le bios charge et execute l'init du boot loader qui a son tour charge et execute le boot loader qui donne le choix entre plusieurs OS.
2) L'init du boot loader change suivant la taille du disque, la partition sur laquelle se trouve le boot ou l'OS loader, le fait qu'il y ait ou non des secteurs defectueux, et bien sur la taille et la methode de mise en place du boot loader (ou de l'os loader). On peut donc considere a peu de chose pres qu'il y a autant d'init de boot loader qu'il y a d'installation differentes. Il est donc possible a la puce TCPA de reperer quasiment a coup sur une variation dans la sequence de boot initiale du systeme, par contre dans le cas d'un dual boot windows/linux elle sera incapable de savoir quel a ete ton choix car quand lilo s'execute toute la phase hashage et analyse de l'init du boot loader est deja termine : la preuve le boot loader s'est execute. A ce moment la tous les hashages de la puce TCPA sont deja finis et le coffre a clef est deja ouvert ou ferme.
Ce qui vaut pour linux vaut aussi pour windows. TCPA est incapable de voir si tu es en train de booter un windows dont rundll32.exe et kernel32.dll ont ete tweake pour faire apparaitre des informations de debug. Ces deux fichiers rentrent dans le processus de boot beaucoup trop tard pour pouvoir etre anayses. Bien sur a plus forte raison cela est valable pour tous les softs qui ne font pas partie du processus de boot.
Pour pouvoir faire du DRM il faudrait que la puce puisse surveiller trois crans plus loin a savoir le boot loader lui meme (si different de l'init) devrait aussi etre verifie et valide, bien sur l'OS loader devrait egalement subir le meme sort et la memoire devrait etre certifie avant le passage en mode protege. En fait seule la derniere etape est essentielle, on se moque bien de comment on arrive au moment ou on est sur que c'est un OS certifie qui va etre initialise, du moment que c'est bien ce qui se produit. Or TCPA est incapable de faire cela.
La phrase In general, any code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to turning control of the system over to that code. The BIOS MUST not hash any data areas. Le traduit bien. le bios ne DOIT PAS faire un hash des zones datas, donc sur un systeme moderne ce n'est pa sl'OS loader qui va etre hashe mais le boot loader ou l'init du boot loader. La plupart des systemes d'exploitations ne tenant pas sur le MBR on est bien dans la zone DATA, et on peut donc les falsifier a tire larigo apres coup. Ceci est innacceptable pour faire du DRM.
Pour finir parlons de ton doccument Intel. Tu a l'air de penser que le registar et le repositary sont deux entites controllees par un consortium mondial et non pas betement deux serveurs montes par un admin lambda pour sa boite.
Il est evident que pour pouvoir authentifier une machine (via TPM ou non) il faut lui demander une premiere fois de generer une clef publique (la en l'occurence basee sur x composants du PCR) quand on est sur de la machine que l'on a en face de soi, et ensuite pour les authentifications ulterieures necessite un jeu de challenge reponse face a cette clef.
Quoi de plus normal que d'avoir une zone qui garde les clefs et une autre (eventuellement la meme ) qui est capable de faire l'association clef/machine.
Ces bases de donnes de hashage que tu brandis comme la preuve ultime ne sont que les donnees collectes a la main sur un reseau par un admin tout ce qu'il y a de plus standard. Mais il va de soit qu'avant de pouvoir consulter cette base le dit admin a du la creer, et il aura bien du mal a s'en servir pour authentifier une machine exterieure au reseau.
La seule chose qui puisse permettre une authentification a posteriori est le code fabriquant. Et encore il permet de certifier qu'il y a bien une puce TPM dans la machine et point barre.
TCG est le nom du groupe, TCPA etait le nom du systeme mais il n'est plus guere utilise a cause de la mauvaise pub, TPM est le nom de la puce.
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Je ne remet pas un seul instant en question tes connaissances en informatiques, pas plus que je ne remet en question celles de M Anderson. Mais je pense simplement que sur ce point particulier il y a des chose que vous n'avez pas comprises, ce sont des points techniques surement completement disjoints de ce que vos domaines de connaissances respectifs.
Par exemple pour le hashage du boot. Tu me certifie que l'on peut identifier l'os en fonction du hashage de l'init du boot loader. Ce n'est pas possible pour les raisons suivantes :
1) Le boot loader n'est pas forcement l'OS loader, dans le cas de linux, BSD et Windows bases sur technologie NT ce n'est pas le cas. Le Boot loader et l'OS loader sont disjoint. Mais pire parfois l'init du boot loader et le boot loader lui meme sont differents. Dans le ca sle plus complexe le bios charge et execute l'init du boot loader qui a son tour charge et execute le boot loader qui donne le choix entre plusieurs OS.
2) L'init du boot loader change suivant la taille du disque, la partition sur laquelle se trouve le boot ou l'OS loader, le fait qu'il y ait ou non des secteurs defectueux, et bien sur la taille et la methode de mise en place du boot loader (ou de l'os loader). On peut donc considere a peu de chose pres qu'il y a autant d'init de boot loader qu'il y a d'installation differentes. Il est donc possible a la puce TCPA de reperer quasiment a coup sur une variation dans la sequence de boot initiale du systeme, par contre dans le cas d'un dual boot windows/linux elle sera incapable de savoir quel a ete ton choix car quand lilo s'execute toute la phase hashage et analyse de l'init du boot loader est deja termine : la preuve le boot loader s'est execute. A ce moment la tous les hashages de la puce TCPA sont deja finis et le coffre a clef est deja ouvert ou ferme.
Ce qui vaut pour linux vaut aussi pour windows. TCPA est incapable de voir si tu es en train de booter un windows dont rundll32.exe et kernel32.dll ont ete tweake pour faire apparaitre des informations de debug. Ces deux fichiers rentrent dans le processus de boot beaucoup trop tard pour pouvoir etre anayses. Bien sur a plus forte raison cela est valable pour tous les softs qui ne font pas partie du processus de boot.
Pour pouvoir faire du DRM il faudrait que la puce puisse surveiller trois crans plus loin a savoir le boot loader lui meme (si different de l'init) devrait aussi etre verifie et valide, bien sur l'OS loader devrait egalement subir le meme sort et la memoire devrait etre certifie avant le passage en mode protege. En fait seule la derniere etape est essentielle, on se moque bien de comment on arrive au moment ou on est sur que c'est un OS certifie qui va etre initialise, du moment que c'est bien ce qui se produit. Or TCPA est incapable de faire cela.
La phrase In general, any code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to turning control of the system over to that code. The BIOS MUST not hash any data areas. Le traduit bien. le bios ne DOIT PAS faire un hash des zones datas, donc sur un systeme moderne ce n'est pa sl'OS loader qui va etre hashe mais le boot loader ou l'init du boot loader. La plupart des systemes d'exploitations ne tenant pas sur le MBR on est bien dans la zone DATA, et on peut donc les falsifier a tire larigo apres coup. Ceci est innacceptable pour faire du DRM.
Pour finir parlons de ton doccument Intel. Tu a l'air de penser que le registar et le repositary sont deux entites controllees par un consortium mondial et non pas betement deux serveurs montes par un admin lambda pour sa boite.
Il est evident que pour pouvoir authentifier une machine (via TPM ou non) il faut lui demander une premiere fois de generer une clef publique (la en l'occurence basee sur x composants du PCR) quand on est sur de la machine que l'on a en face de soi, et ensuite pour les authentifications ulterieures necessite un jeu de challenge reponse face a cette clef.
Quoi de plus normal que d'avoir une zone qui garde les clefs et une autre (eventuellement la meme ) qui est capable de faire l'association clef/machine.
Ces bases de donnes de hashage que tu brandis comme la preuve ultime ne sont que les donnees collectes a la main sur un reseau par un admin tout ce qu'il y a de plus standard. Mais il va de soit qu'avant de pouvoir consulter cette base le dit admin a du la creer, et il aura bien du mal a s'en servir pour authentifier une machine exterieure au reseau.
La seule chose qui puisse permettre une authentification a posteriori est le code fabriquant. Et encore il permet de certifier qu'il y a bien une puce TPM dans la machine et point barre.
TCG est le nom du groupe, TCPA etait le nom du systeme mais il n'est plus guere utilise a cause de la mauvaise pub, TPM est le nom de la puce.
Kha