Re: Demontage en regle

l'énorme différence est dans le fait que on ne peut pas falsifier cette clé même si on a le controle total des softs d'un ordinateur et des paquets internet qu'il envoit. Pour pouvoir décrypter rapidement un challenge encrypté avec la clé publique, IL FAUT posséder la clé privé et être donc le proprétaire de l'ordinateur TCPA en question. C'est vrai que dans l'architecture intel on puvait changer le numero de serie du processeur. Elle est donc la la difference. Et puis un systeme d'authentification qui permet de m'authentifier c'est vraiment degeulasse. Au risque de me repeter la EK ne sert qu'a creer des certificats. Si quelqu'un m'envoit un paquet crypte selon ma EK (et je vois pas bien comment il ferait ca, mais bon), ma puce ne pourra pas le dechiffrer. La seule facon de se servir de la EK est la suivante. - 1) je cree un certificat - 2) j'envoit mon certificat a un organisme de validation - 3) Cet organisme s'assure par un principe de challenge/reponse que je suis bien le createur de ce certificat. - 4) Mon certificat est valide, l'organisme le charge pour confirmation. - 5) J'utilise mon certificat sur le net, si une personne veut verifier son authenticite elle est redirige vers l'organisme qui refait un challenge/reponse pour verifier que c'est bien la machine declaree qui s'en sert. J'en ai ras le bol de ce certificat, je peux le detruire. Ou en refaire un autre et me servir de celui la, ou ne jamais demander de certificat pour commencer, ou meme dans l'implementation IBM demander a ce que ce la EK ne soit pas activee. (soit parcequ'elle n'est pas presente, soit parceque je la desactive dans le bios.) j'aimerais bien que tu me dises comment tu fais cette migration, controlée par Windows et donc non disponible si Windows la refuse. Le philosophie et l'intéret de TCPA est que les clés sont générés dans la puce et n'en sortent jamais ! Les opérations de cryptage se ofnt à l'intérieur de la puce. Où as-tu vu dans les specs que on peut les faire sortir de la puce? Tu veux dire si windows bloque LOGICIELLEMENT l'acces a certaines fonctions TCPA. Ben comme tout le monde, j'attend le crack ou je le develloppe moi meme. Si windows a des droits, c'est que la puce a des droits. Si windows m'interdit d'ecrire sur le port de la puce parceque je ne suis pas une appli securisee, parce que ca ne lui plait pas, ou parcequ'il veut proteger des donnees, il est oblige de faire ca logiciellement. Donc il est oblige de proteger TCPA avec autre chose. Et la de deux choses l'une 1) soit sa protection logicielle est sans faille, je ne peut pas acceder a la puce. Mais a ce moment la pourquoi ne pas utiliser cette protection directement et se passer de la puce TCPA ? 2) soit sa protection est nulle, elle se fait casser et TCPA ne sert a rien. Une fois que je peux ecrire sur la puce j'ai exactement les memes droits que l'OS et les programmes. En ce qui concerne la migration des clefs, lors du precedent thread je t'avais deja renvoye vers le lien dans les specs TCPA, mais c'est pas grave on y retourne : Section 7.2.11,7.2.12,7.2.13 pages 171 a 177 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf la doc officielle TCPA. Tu remarqueras que ces fonctions sont "mandatory" ie obligatoire a toute implementation TCPA. Concernant le mode "extend" qui n'est pas nié par IBM, tu as oublié cette phrase: "could also prevent the use of “free” operating systems because the OS kernel would have to be signed by a entity which is a descendant of the trusted root" Non je n'ai pas oublie cette phrase. Revoyons la ensemble. Tout d'abord "could" en francais pourrait, a la difference de "can" en francais peut. Si TCPA avait le controle sur le boot (ce qui n'est pas le cas) et si TCPA etait fourni avec des clefs prechargees (ce qui est contraire au specs) et si le hashage du kernel etait previsible (ce qui est faux, meme un PCR qui hashe juste le kernel(la transition entre le mode reel et le mode protege) est dependant de la machine sur lequel il est execute), alors on pourrait vendre des puces TCPA qui empechent le boot si l'OS ne repond pas au critere de hashage du PCR. Bien entendu il faudrait aussi s'assurer que l'utilisateur ne puisse pas acceder du tout a ce PCR pour le modifier/ou en dupliquer les proprietes. Ce qui implique de retirer a l'utilisateur les droits sur le trusted root (il ne serait owner que d'une sous entite) et de lui enlever aussi les droits owner sur le SRK (il ne peut plus modifier/alterer/autoriser l'insertion,la suppression ou la migration de clef). Il faudrait de plus que toutes ces fonction soient codes dans la puce, pour eviter un hack logiciel. Bref si TCPA etait quelque chose de completement different reposant sur la technologie TPM ca pourrait etre vachement dangereux. Ben oui. Mais c'est pas le cas. dont tu fais partie sinon tu saurais que des modifications matérielles ou logicielles peuvent entrainer la désactivation de XP ! D'où le lien avec le roots of trust de TCPA et son controle de la configuration matérielle et logicielle. Au risque de me repeter encore le TRUSTED ROOT est un repertoire. Une zone memoire, un endroit pour mettre des donnees dedans, un file system. Bref un truc completement passif. La seule chose qui le differencie des autres zones memoires de ta machine est la certitude que seul le owner du trusted root peut lire/ecrire/effacer des donnees. C'est exactement comme le /root de ta becanne. Si t'es pas root et si le root ne t'a pas donnes de droits tu peux pas ecrire dedans. ET C'EST TOUT.Il ne controle rien, il ne regarde rien, il ne voit rien, il ne fait rien. C'est une zone memoire. Je supposerais donc que tu voulais parler du hashage du boot stoque dans un PCR. Et je te dirais une fois de plus que si MS fiche ces clefs la dedans, il suffit de les migrer ailleurs pour que tout baigne. Je n'est meme pas besoin que MS me redonne les clefs, je peux le faire tout seul... Kha