Pour ceux aui ont suivi le thread TCPA precedent vous savez deja que l'ensemble des argumets avances ici sont au mieux incomplet, au pire le resultat d'une pure speculation, pour les autres :
- *info 1: au moment de la fabrication il est inséré une clé privée asymétrique unique dans chaque puce TCPA
"the endorsement key" "uniquely identifies the platform" au bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...)
IBM dit que c'est pour des problèmes de vie privée qu'ils ont pris la décision que l'accès à cette clé peut être désactivé dans les puces IBM actuelles. Cette décision interne d'IBM est la confirmation que la norme TCPA n'oblige pas à fournir la possibilité de désactiver cette clé (désactivation qui n'est faisable que si les softs et documents DRM dont on a besoin n'obligent pas à utiliser cette clé)
*conséquences de cette info: cette clé unique est pire qu'un simple numéro unique (retiré par Intel de ses processeurs, après des appels au boycott), car elle ne peut pas etre contrefaite (elle est authentifiable car elle seule peut décoder des messages cryptées avec sa clé publique associée). Un jour ou l'autre, l'utilisation de cette clé sera exigée par les softs DRM (donc fermer l'accès à cette clé impliquera de ne pas pouvoir utiliser ces softs pour encoder/décoder) pour que seul un ordinateur précis puisse accéder à un fichier protégé par DRM, pour un temps précis en fonction de ce qu'a payé l'utilisateur de l'ordinateur, et des techniques de watermarking pourront être utilisées par ce soft DRM pour savoir si ce PC a fait une copie en utilisant des techniques analogiques et l'a envoyé à d'autres PCs.
Outre le fait que la EK ne soit pas du tout obligatoire, je pense qu'il est bon de rapeler comment cette clef est cree et utilisee :
Le constructeur de la puce ou le constructeur de la carte creent une clef de cryptage. Il est bon de noter que cette clef n'est pas utilisable.
Si on le souhaite on peut demander a un organisme tiers de creer un certificat base sur cette clef(NB l'organisme ne recoit pas la clef mais valide le certificat par un principe de challenge, il ne connait jamais la clef d'endossement). Une fois cree c'est le certificat qui est exploitable. On peut sur une meme puce cree autant de certificats differents que l'on veut. Bien entendu cryptographie oblige il est impossible d'associer une certificat avec la clef d'endossement. On peut ensuite se servir du certificat ainsi cree pour s'authentifier aupres de site. Etre identifie a partir du certificat (qui est la seule info qui a le droit de transiter) implique que la personne qui a cree la puce et la personne qui a valide le certificat sont une seule et meme entite. De plus pour pouvoir vous pister il faut aussi que ce soit la personne chez qui vous utilisez le certificat. Bien que ce risque ne soit pas nul, il est de tres loin inferieur a celui des numeros de serie chez Intel. Ce n'est donc pas pire, c'est nettement mieux. Il est bon de rappeler que la norme TCPA interdit aux producteurs de puces d'etre des organismes certificateurs.
*info 2: il est possible pour un OS d'utiliser TCPA pour crypter certains documents et interdire aux autres OS d'accéder à ces documents
"if an attempt is made to boot an alternative system" "the unseal will fail, thus protecting the data" bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
*conséquences: tous les utilisateurs de dual-boot (par exemple Linux et Windows sur le meme ordinateur) pourront bientot etre confrontés à des fichiers (documents ou programmes) encryptés sous Windows et inutilisables sous Linux: les documents ne seront donc pas ouvrables par openoffice, et les programmes ne seront donc pas exécutables par wine.
Notons que sous Linux et Windows il est deja possible de protéger par une passphrase certains documents ou certaines partitions. La différence est que cette passphrase est stockée dans le cerveau de l'utilisateur qui peut donc l'utiliser avec l'OS de son choix, pas dans une puce TCPA qui refusera à un OS alternatif de l'utiliser.
Notons aussi que des outils libres comme tripwire permettent de s'assurer en bootant à partir d'une disquette ou d'un CD-rom qu'un OS n'a pas été modifié par un virus ou par un cracker (pas besoin de TCPA pour cela donc)
enfin des outils libres de sécurité comme LinuxSecurityModule, systrace, fireflier, permettent de s'assurer que certains fichier du système ne pourront aps être accédés par des programmes qui communiquent avec internet (limitant par là meme les dégats que peuvent causer un virus ou un cracker)
Je passe sur la derniere partie (oui il est possible de faire en logiciel tout ce que fait TCPA en hardware) pour me focaliser sur le systeme d'encription de boot.
La puce TCPA possede un systeme qui lui permet de hasher un boot et de stoquer des clefs dans ce hashage. Si le boot n'est pas rigoureusement identique, le hashage change et les clefs sont impossibles a recuperer.
Si j'encrypte mes doccuments sur un hashage de boot et que je boot differement mes doccuments cryptes ne sont plus disponibles. Effectivemnt si je boot sous linux je n'ai plus acces a mes doccuments . C'est aussi le cas si j'upgrade mon bios, si je patch mon os ou si je change ma carte graphique. Ce systeme est extrememnt limitatif. Tout changement dans la phase de boot entrainne un lock de mes fichiers. Je vous laisse imaginer les problemes que cela creerait si jamais la sauvegarde par defaut etait basee sur ce systeme. De plus il faut ajouter que si mon ordi a les droits pour creer une clef (ie si windows peut forcer l'enregistrement en crypte de mes fichiers en fonction du hashage du boot), alors il a aussi les droits de deplacer ces clefs via un systeme de migration. Donc meme si il y a encryptage sans que je le sache de mon fichier, je peut toujours sortir la clef du coffre depuis windows et la mettre a un endroit ou elle sera accessible depuis linux. La migration et le bind d'une clef ne sont pas des operations faciles, mais c'est tout a fait possible.
*info 3: impossibilité de controler le code qui est dans les puces TCPA
contrairement aux softs libres de sécurité comme LSM/tripwire/fireflier/systrace, il est très difficile, voir impossible, d'aller controler le code qui sera stocké dans les puces TCPA .
Il est meme prévu dans la spec officielle de cacher au maximum le fonctionnement d'éléments comme le générateur aléatoire (qui est pourtant la base de la sécurité de tout cryptage)
"Intermediate results from the RNG are not available to any user. When the data is for internal use by the TPM (e.g., asymmetric key generation) the data is held in a shielded location and is not accessible to any user. " en haut de la page 13 de http://www.trustedcomputing.org/docs/TCPA_TPM_PP_1_9_7.pdf(...)
*conséquences: sécurité et obscurité ne font pas bon ménage. Des chevaux de Troie ou des failles pourraient etre introduites dans ces puces sans que les utilisateurs le sachent. Les algorithmes de sécurité et de cryptages évoluent au fur et à mesrure que de nouvelles failles sont trouvées: il n'est pas prévu dans les specs de pouvoir changer ces algorithmes si une nouvelle faille est trouvée. Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique). La taille fixe de leur clé est incompatible avec l'évolution rapide des matériels et des techniques pour casser la crypto.
Bref, mieux vaut utiliser des logiciels libres de crypto évolutifs que des logiciels obscurs non évolutifs cachés dans une puce.
IL est effectivement impossible d'acceder aux etapes intermediaires de la generation de nombre aleatoire. Mais je ne vois pas comment on peut introduir eun cheval de troie dans une puce qui n'est justement pas reprogrammable, a moins bien sur que ce ne soit le constructeur lui meme qui l'y place. Autant je comprend le soucis qu'il peu y a voir a vouloir etre sur de la force de la clef, autant on ne possede a l'heure actuelle le code d'aucun composant de nos PC. Il pourrait deja y avoir des chevaux de Troie dans une foule des puces qui compose nos ordis. Pourquoi les mettre dans la puce TCPA ? De plus les specs ne font pas mention de quoi que ce soit dans ce genre. Pure speculation donc.
En ce qui concerne la force des clefs, il s'agit de clefs 2048 bits. Il est vrai que si le genrateur aleatoire est de mauvaise qualite, on entamme de beaucoup la force de cette clef, mais ca laisse encore pas mal de marge par rapport a des clefs 256bits.
*info 4: TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être booté avec ce mode
"the OS kernel would have to be signed"
paragraphe 4 du document critique d'un des créateurs de TCPA http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html(...)
document commenté par IBM comme étant très raisonable "most reasonnable" et sans nier l'existence du mode "extend" au bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
*conséquences du mode "extend": tous les OS libres (noyaux + programmes systèmes) que l'on peut recompiler en totalité ou en partie ne seront plus utilisables avec TCPA après recompilation.
Voir plus utilisables du tout, même sous forme de binaires, si aucune version récente de l'OS n'est signée pour TCPA.
Alors la n'importe quoi !! Bien que les morceaux cites soient exacts, le sens est completement deforme. Premierement "Most reasonable" ne veut pas dire tres raisonnable mais le plus raisonable dans ce contexte. Le rebutal d'IBM s'attaque a plusieurs doccuments, la plupart ecrits par des web redacteurs mal informes, et un ecrit par un scientifique. Celui ecrit par le scientifique souleve des problemes tres justes qui pourraient se poser dans l'avenir, meme si actuellement la norme TCPA ne pose pas probleme.
En ce qui concerne le mode extend, le principe est le meme que le hashage de boot vu plus haut. Lorsque l'on place la puce en mode extend elle hashe l'integralite du boot(au lieu de juste des morceaux choisis). L'OS est alors "signe"=il est reconnu par le hashage integral du boot (oui ce n'est pas une boite exterieure qui signe l'OS, c'est la puce TCPA elle meme qui le fait lors de la demande de hashage en mode extend). Il est bon de preciser que
-1) TCPA ne peut pas empecher une machine de booter (cf tcpa rebutal) meme si l'OS n'est pas "signe" il bootera quand meme, le coffre a clef lui sera ferme, un point c'est tout.
-2)Il est impossible de signer un OS autrement que sur la machine meme. Le systeme de hashage de TCPA est extrement sensible au changement et a moins de posseder un ordinateur rigoureusement identique on ne peut pas creer de clef de hashage "transmissible" a une autre machine.
-3)En mode extend (ie on hashe tout ce qui nous passe sous la main au boot) le moindre changement entrainne la fermeture du coffre a clef. Donc on se retrouve avec le bon vieux problemes "tout ce qui est crypte est perdu" au moindre changement de bios/periph/OS. Pas top du tout.
*info 5: les specs n'interdisent pas l'ajout de fonctionalités supplémentaires par chaque constructeur dans leur puces de sécurité:
"it can be integrated into some existing component or components"
page 11 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
*conséquences: un PC à la norme TCPA ne sera donc pas une garantie que seules les fonctionalités de la norme TCPA sont dans ses puces de sécurité (ou dans son CPU)
ce PC pourra notamment interdire l'accès aux fonctions TCPA aux OS non signés (meme si le mode extend est abandonné dans les specs)
voir interdire le boot de tout OS non signé
N'importe quoi bis. Le fait de dire que l'on peut integrer la puce TCPA a un autre composant (ie la placer dans le CPU ou dans l'horloge), ne veut absoluemnt pas dire que l'on puisse
1-) devier en quoi que ce soit de la norme TCPA
2-) Ajouter des fonctions de controle dans la puce
3-) Permettre a la puisse d'interagir avec le processus de boot.
La puce TCPA regarde ce qui se passe sur un bus et dialogue via un port serie vec l'utilisateur ou l'OS. Mais elle ne peut pas interagir avec le bus qu'elle surveille. De plus il est toujours impossible a une societe exterieure de signer un OS pour qu'il soit compatible avec l'ensemble des puces. Parceque
1-) Il faut que le coffre a puce soit vide lors de la fabrication
2-) Compte tenu de la versatilite des systemes aujourd'hui, la seule facon de creer une clef de hashage de boot est de la creer sur l'ordinateur meme, ou sur une copie conforme. On ne peut pas creer un logiciel (quel qu'il soit) qui soit de base certifie TCPA, signe pour le boot. C'est techniquement impossible.
*info 6: Microsoft est le seul non fabricant de CPU à être membre fondateur de TCPA
cf "background" de http://www.trustedcomputing.org/tcpaasp4/index.asp(...)
et les specs TCPA commencent par une notion de "roots of trust" très similaire à l'activation framework de Windows XP
page 12 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
*conséquence: cette information est à rapprocher des condamnations anti-trust définitives dont MS vient de faire l'objet. Cela prouve que Palladium n'est pas la seule technologie de contrôle soutenue activement par MS. Palladium peut s'appuyer sur TCPA qui intègre déjà des notions de l'activation framework de XP.
L'argument qui tue : c'est mal parcequ'il y a Microsoft dedans. Deja Microsoft est dans tout c'est sa politique, mettre du windows dans le moindre fer a repasser d'ici 2010.
alors le trusted root (et non pas les roots of trust) est commun a l'ensemble des systemes de stockage de clefs privees, ou d'information confidentielles. C'est simplement le nom donne a une zone memoire, un repertoire, un fichier, un flux etc.. dont on connait tous les processus capables d'interagir. En d'autre termes un pertoire a la racine en chmod 7000 peut etre considere comme un trusted root.
Pour ceux qui ne savent pas ce qu'est l'activation framework de XP il s'agit de recuperer par telephone ou par connection internet une clef qui va debloquer votre windows. Sans cette clef XP refuse de fonctionner passe un delai de 30 jours (je crois). Peut on repliquer ce comportement avec TCPA ? Non !
Le but de l'activation framework d'XP est de verifier que vous vous etes enregistree vis a vis de Microsoft. C'est un principe tout bete de challenge/reponse. TCPA est capable d'etre challengee, mais pas d'initier un challenge. Elle est donc completement inutile dans ce systeme. Elle ne peut pas appeler Microsoft.
sécurité et obscurité ne font pas bon ménage
Information et obscurantisme non plus.
Kha
Lire les specs c'est bien, comprendre les specs c'est mieux.
# Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 2.
- *info 1: au moment de la fabrication il est inséré une clé privée asymétrique unique dans chaque puce TCPA
"the endorsement key" "uniquely identifies the platform" au bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...)
IBM dit que c'est pour des problèmes de vie privée qu'ils ont pris la décision que l'accès à cette clé peut être désactivé dans les puces IBM actuelles. Cette décision interne d'IBM est la confirmation que la norme TCPA n'oblige pas à fournir la possibilité de désactiver cette clé (désactivation qui n'est faisable que si les softs et documents DRM dont on a besoin n'obligent pas à utiliser cette clé)
*conséquences de cette info: cette clé unique est pire qu'un simple numéro unique (retiré par Intel de ses processeurs, après des appels au boycott), car elle ne peut pas etre contrefaite (elle est authentifiable car elle seule peut décoder des messages cryptées avec sa clé publique associée). Un jour ou l'autre, l'utilisation de cette clé sera exigée par les softs DRM (donc fermer l'accès à cette clé impliquera de ne pas pouvoir utiliser ces softs pour encoder/décoder) pour que seul un ordinateur précis puisse accéder à un fichier protégé par DRM, pour un temps précis en fonction de ce qu'a payé l'utilisateur de l'ordinateur, et des techniques de watermarking pourront être utilisées par ce soft DRM pour savoir si ce PC a fait une copie en utilisant des techniques analogiques et l'a envoyé à d'autres PCs.
Outre le fait que la EK ne soit pas du tout obligatoire, je pense qu'il est bon de rapeler comment cette clef est cree et utilisee :
Le constructeur de la puce ou le constructeur de la carte creent une clef de cryptage. Il est bon de noter que cette clef n'est pas utilisable.
Si on le souhaite on peut demander a un organisme tiers de creer un certificat base sur cette clef(NB l'organisme ne recoit pas la clef mais valide le certificat par un principe de challenge, il ne connait jamais la clef d'endossement). Une fois cree c'est le certificat qui est exploitable. On peut sur une meme puce cree autant de certificats differents que l'on veut. Bien entendu cryptographie oblige il est impossible d'associer une certificat avec la clef d'endossement. On peut ensuite se servir du certificat ainsi cree pour s'authentifier aupres de site. Etre identifie a partir du certificat (qui est la seule info qui a le droit de transiter) implique que la personne qui a cree la puce et la personne qui a valide le certificat sont une seule et meme entite. De plus pour pouvoir vous pister il faut aussi que ce soit la personne chez qui vous utilisez le certificat. Bien que ce risque ne soit pas nul, il est de tres loin inferieur a celui des numeros de serie chez Intel. Ce n'est donc pas pire, c'est nettement mieux. Il est bon de rappeler que la norme TCPA interdit aux producteurs de puces d'etre des organismes certificateurs.
*info 2: il est possible pour un OS d'utiliser TCPA pour crypter certains documents et interdire aux autres OS d'accéder à ces documents
"if an attempt is made to boot an alternative system" "the unseal will fail, thus protecting the data" bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
*conséquences: tous les utilisateurs de dual-boot (par exemple Linux et Windows sur le meme ordinateur) pourront bientot etre confrontés à des fichiers (documents ou programmes) encryptés sous Windows et inutilisables sous Linux: les documents ne seront donc pas ouvrables par openoffice, et les programmes ne seront donc pas exécutables par wine.
Notons que sous Linux et Windows il est deja possible de protéger par une passphrase certains documents ou certaines partitions. La différence est que cette passphrase est stockée dans le cerveau de l'utilisateur qui peut donc l'utiliser avec l'OS de son choix, pas dans une puce TCPA qui refusera à un OS alternatif de l'utiliser.
Notons aussi que des outils libres comme tripwire permettent de s'assurer en bootant à partir d'une disquette ou d'un CD-rom qu'un OS n'a pas été modifié par un virus ou par un cracker (pas besoin de TCPA pour cela donc)
enfin des outils libres de sécurité comme LinuxSecurityModule, systrace, fireflier, permettent de s'assurer que certains fichier du système ne pourront aps être accédés par des programmes qui communiquent avec internet (limitant par là meme les dégats que peuvent causer un virus ou un cracker)
Je passe sur la derniere partie (oui il est possible de faire en logiciel tout ce que fait TCPA en hardware) pour me focaliser sur le systeme d'encription de boot.
La puce TCPA possede un systeme qui lui permet de hasher un boot et de stoquer des clefs dans ce hashage. Si le boot n'est pas rigoureusement identique, le hashage change et les clefs sont impossibles a recuperer.
Si j'encrypte mes doccuments sur un hashage de boot et que je boot differement mes doccuments cryptes ne sont plus disponibles. Effectivemnt si je boot sous linux je n'ai plus acces a mes doccuments . C'est aussi le cas si j'upgrade mon bios, si je patch mon os ou si je change ma carte graphique. Ce systeme est extrememnt limitatif. Tout changement dans la phase de boot entrainne un lock de mes fichiers. Je vous laisse imaginer les problemes que cela creerait si jamais la sauvegarde par defaut etait basee sur ce systeme. De plus il faut ajouter que si mon ordi a les droits pour creer une clef (ie si windows peut forcer l'enregistrement en crypte de mes fichiers en fonction du hashage du boot), alors il a aussi les droits de deplacer ces clefs via un systeme de migration. Donc meme si il y a encryptage sans que je le sache de mon fichier, je peut toujours sortir la clef du coffre depuis windows et la mettre a un endroit ou elle sera accessible depuis linux. La migration et le bind d'une clef ne sont pas des operations faciles, mais c'est tout a fait possible.
*info 3: impossibilité de controler le code qui est dans les puces TCPA
contrairement aux softs libres de sécurité comme LSM/tripwire/fireflier/systrace, il est très difficile, voir impossible, d'aller controler le code qui sera stocké dans les puces TCPA .
Il est meme prévu dans la spec officielle de cacher au maximum le fonctionnement d'éléments comme le générateur aléatoire (qui est pourtant la base de la sécurité de tout cryptage)
"Intermediate results from the RNG are not available to any user. When the data is for internal use by the TPM (e.g., asymmetric key generation) the data is held in a shielded location and is not accessible to any user. " en haut de la page 13 de http://www.trustedcomputing.org/docs/TCPA_TPM_PP_1_9_7.pdf(...)
*conséquences: sécurité et obscurité ne font pas bon ménage. Des chevaux de Troie ou des failles pourraient etre introduites dans ces puces sans que les utilisateurs le sachent. Les algorithmes de sécurité et de cryptages évoluent au fur et à mesrure que de nouvelles failles sont trouvées: il n'est pas prévu dans les specs de pouvoir changer ces algorithmes si une nouvelle faille est trouvée. Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique). La taille fixe de leur clé est incompatible avec l'évolution rapide des matériels et des techniques pour casser la crypto.
Bref, mieux vaut utiliser des logiciels libres de crypto évolutifs que des logiciels obscurs non évolutifs cachés dans une puce.
IL est effectivement impossible d'acceder aux etapes intermediaires de la generation de nombre aleatoire. Mais je ne vois pas comment on peut introduir eun cheval de troie dans une puce qui n'est justement pas reprogrammable, a moins bien sur que ce ne soit le constructeur lui meme qui l'y place. Autant je comprend le soucis qu'il peu y a voir a vouloir etre sur de la force de la clef, autant on ne possede a l'heure actuelle le code d'aucun composant de nos PC. Il pourrait deja y avoir des chevaux de Troie dans une foule des puces qui compose nos ordis. Pourquoi les mettre dans la puce TCPA ? De plus les specs ne font pas mention de quoi que ce soit dans ce genre. Pure speculation donc.
En ce qui concerne la force des clefs, il s'agit de clefs 2048 bits. Il est vrai que si le genrateur aleatoire est de mauvaise qualite, on entamme de beaucoup la force de cette clef, mais ca laisse encore pas mal de marge par rapport a des clefs 256bits.
*info 4: TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être booté avec ce mode
"the OS kernel would have to be signed"
paragraphe 4 du document critique d'un des créateurs de TCPA http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html(...)
document commenté par IBM comme étant très raisonable "most reasonnable" et sans nier l'existence du mode "extend" au bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
*conséquences du mode "extend": tous les OS libres (noyaux + programmes systèmes) que l'on peut recompiler en totalité ou en partie ne seront plus utilisables avec TCPA après recompilation.
Voir plus utilisables du tout, même sous forme de binaires, si aucune version récente de l'OS n'est signée pour TCPA.
Alors la n'importe quoi !! Bien que les morceaux cites soient exacts, le sens est completement deforme. Premierement "Most reasonable" ne veut pas dire tres raisonnable mais le plus raisonable dans ce contexte. Le rebutal d'IBM s'attaque a plusieurs doccuments, la plupart ecrits par des web redacteurs mal informes, et un ecrit par un scientifique. Celui ecrit par le scientifique souleve des problemes tres justes qui pourraient se poser dans l'avenir, meme si actuellement la norme TCPA ne pose pas probleme.
En ce qui concerne le mode extend, le principe est le meme que le hashage de boot vu plus haut. Lorsque l'on place la puce en mode extend elle hashe l'integralite du boot(au lieu de juste des morceaux choisis). L'OS est alors "signe"=il est reconnu par le hashage integral du boot (oui ce n'est pas une boite exterieure qui signe l'OS, c'est la puce TCPA elle meme qui le fait lors de la demande de hashage en mode extend). Il est bon de preciser que
-1) TCPA ne peut pas empecher une machine de booter (cf tcpa rebutal) meme si l'OS n'est pas "signe" il bootera quand meme, le coffre a clef lui sera ferme, un point c'est tout.
-2)Il est impossible de signer un OS autrement que sur la machine meme. Le systeme de hashage de TCPA est extrement sensible au changement et a moins de posseder un ordinateur rigoureusement identique on ne peut pas creer de clef de hashage "transmissible" a une autre machine.
-3)En mode extend (ie on hashe tout ce qui nous passe sous la main au boot) le moindre changement entrainne la fermeture du coffre a clef. Donc on se retrouve avec le bon vieux problemes "tout ce qui est crypte est perdu" au moindre changement de bios/periph/OS. Pas top du tout.
*info 5: les specs n'interdisent pas l'ajout de fonctionalités supplémentaires par chaque constructeur dans leur puces de sécurité:
"it can be integrated into some existing component or components"
page 11 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
*conséquences: un PC à la norme TCPA ne sera donc pas une garantie que seules les fonctionalités de la norme TCPA sont dans ses puces de sécurité (ou dans son CPU)
ce PC pourra notamment interdire l'accès aux fonctions TCPA aux OS non signés (meme si le mode extend est abandonné dans les specs)
voir interdire le boot de tout OS non signé
N'importe quoi bis. Le fait de dire que l'on peut integrer la puce TCPA a un autre composant (ie la placer dans le CPU ou dans l'horloge), ne veut absoluemnt pas dire que l'on puisse
1-) devier en quoi que ce soit de la norme TCPA
2-) Ajouter des fonctions de controle dans la puce
3-) Permettre a la puisse d'interagir avec le processus de boot.
La puce TCPA regarde ce qui se passe sur un bus et dialogue via un port serie vec l'utilisateur ou l'OS. Mais elle ne peut pas interagir avec le bus qu'elle surveille. De plus il est toujours impossible a une societe exterieure de signer un OS pour qu'il soit compatible avec l'ensemble des puces. Parceque
1-) Il faut que le coffre a puce soit vide lors de la fabrication
2-) Compte tenu de la versatilite des systemes aujourd'hui, la seule facon de creer une clef de hashage de boot est de la creer sur l'ordinateur meme, ou sur une copie conforme. On ne peut pas creer un logiciel (quel qu'il soit) qui soit de base certifie TCPA, signe pour le boot. C'est techniquement impossible.
*info 6: Microsoft est le seul non fabricant de CPU à être membre fondateur de TCPA
cf "background" de http://www.trustedcomputing.org/tcpaasp4/index.asp(...)
et les specs TCPA commencent par une notion de "roots of trust" très similaire à l'activation framework de Windows XP
page 12 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
*conséquence: cette information est à rapprocher des condamnations anti-trust définitives dont MS vient de faire l'objet. Cela prouve que Palladium n'est pas la seule technologie de contrôle soutenue activement par MS. Palladium peut s'appuyer sur TCPA qui intègre déjà des notions de l'activation framework de XP.
L'argument qui tue : c'est mal parcequ'il y a Microsoft dedans. Deja Microsoft est dans tout c'est sa politique, mettre du windows dans le moindre fer a repasser d'ici 2010.
alors le trusted root (et non pas les roots of trust) est commun a l'ensemble des systemes de stockage de clefs privees, ou d'information confidentielles. C'est simplement le nom donne a une zone memoire, un repertoire, un fichier, un flux etc.. dont on connait tous les processus capables d'interagir. En d'autre termes un pertoire a la racine en chmod 7000 peut etre considere comme un trusted root.
Pour ceux qui ne savent pas ce qu'est l'activation framework de XP il s'agit de recuperer par telephone ou par connection internet une clef qui va debloquer votre windows. Sans cette clef XP refuse de fonctionner passe un delai de 30 jours (je crois). Peut on repliquer ce comportement avec TCPA ? Non !
Le but de l'activation framework d'XP est de verifier que vous vous etes enregistree vis a vis de Microsoft. C'est un principe tout bete de challenge/reponse. TCPA est capable d'etre challengee, mais pas d'initier un challenge. Elle est donc completement inutile dans ce systeme. Elle ne peut pas appeler Microsoft.
sécurité et obscurité ne font pas bon ménage
Information et obscurantisme non plus.
Kha
Lire les specs c'est bien, comprendre les specs c'est mieux.