je me suis mal exprimé, il était tard (il faut dire que quand il s'agit de TCG tu ne cherches absolument pas à comprendre ce que je cherche à dire, tu préfère jouer sur mes mots)
je voulais dire: fournir le hash d'un bootloader est largement suffisant pour qu'un tiers sache si il connait deja ce bootloader (ie le tiers en a deja fait un hash ou on le lui a donné !)
Non tu t'es tres bien exprime. Prenons un autre exemple. Suposons que je connaisse parfaitement un format de facture numerique (c'est a dire un formulaire vierge). Ce format contient le nom de la societe emmetrice de la facture, son adresse, son numero de telephone et son kbis.
Ce format est connu de moi, je l'ai sous la main, je peux en faire tous les hashs que je veux.
Maintenant si la societe qui utilise ce format remplit une facture, en y mettant le nom du destinataire, le detail des prestations qu'elle a fournis, le montant hors taxe, les taxes, eventuellement un rabais et la somme due avec le delai de paiement. Serais-je capabale avec un MD5 du formulaire remplit dans une main et mon formulaire vierge dans l'autre de savoir si ce MD5 correspond bien a une facture faite avec le formulaire que je connais ?
Surement pas, a moins qu'avant le hashage un masque est cache les infos variables pour ne laisser que les informations statiques. Je ne crois pas a l'existence de ce masque qui laisserait trop de place pour les bidouilleurs dans le cas de TPM, c'est tout.
non car tous les bios sont paramétrables pour choisir quel périphérique sera utilisé pour booter
Oui tu peux changer l'ordre des bootloader qui vont lui passer sous la main, mais des qu'il en trouvera un il s'arretera la et n'ira pas regarder si les periphs suivants en contienne un autre (tu parlais de jouer sur les mots tout a l'heure ?)
hash du mbr connu
Une grosse partie de mon argumentation vient du fait qu'un hash de MBR ne peut pas etre connu a l'avance (ce qui est d'ailleurs plutot rassurant).
fournir le hash d'un bootloader est largement suffisant pour qu'un tiers sache si il connait deja ce bootloader (ie le tiers en a deja fait un hash ou on le lui a donné !)
Et je maintiens que le nombre de parties variables dans un mbr ou dans un bootloader rendent cela impossible
bref ta "défense" de TCG est clairement démolie par le document intel spring2003 qui parle du début à la fin d'identifier de manière non falsifiable une plateforme à distance grace à TCG qui fournit un hash pour chaque composant !
Bon ca va etre long et sur les deux colonnes qui restent suite aux reponses en chaine ca va pas etre drole, mais allons-y
page 1-4 sans interet pour la discusion c'est l'intro
page 5 accent mis sur le fait que le hard ne doit pas mentir
cela requiert :
-des mesures fiables
-un stockage protege de ces mesures
-la capacite a prouver que l'on peut faire ces mesures
Deja la ca coince, il est marque en toute lettre que pour que la puce soit fiable il faut que les mesures (et donc le hash) soit protegees.
page 6
-Clef d'attestation
2048 bit, cree par le TPM en interne , partie privee de la clef non migrable
-Certification
Obtenue aupres d'un registar, le credential n'a pas besoin de contenir la moindre information identificatrice.
Ouch reprobleme dans ton optique, les certificats emis par les registars ne contiennent pas d'infos identificatrices, on commence a etre loin du hashage unique qui circule sur l'internet
page 7
Explication de la creation d'une certif au pres d'un registar, on remarquera l'absence de toute tarce de hashage
page 8
Explication du fonctionnement du systeme de mesure (le hashage), la mesure est stoquee dans le SML, le PCR associe est cree et signe
page 9
Un challenger veut verifier si le PCR associe a un composant est accessible, il effectue donc une demande aupres de l'autre puce pour reccuperer le certificat, le PCR signe et le SML
page 10
le challenger authetifie les composant en chaine, le registar -> AIK -> PCR -> SML.
On remarquera que rien ne permet au challenger de verifier (et donc potentiellement de decoder) le SML, ce qui est normal vu que l'AIK lui certifie deja que les infos SML sont fiables, mais ce qui pose un leger probleme dans le cadre de ta theorie d'identification des hashages....
page 11
on sait maintenant que le composant 1 est present et certifie, reste a savoir si il est fiable
page 12
Comment faire ? soit par une base de donees completement definie, soit par l'intervention d'un admin qui connait ce composant. Cette connaissance s'apelle le repository.
page 13
Le systeme necessite que la tramission de la fiabilite, ou non, du composant soit egalement fiable.
page 14
Tout ce que l'on met dans le repository : le hardware, les politiques internes, les alertes, les softs etc.
page 15
Necessite d'ajouter dans repository des composants venant de plusieurs horizon. On notera aussi qu'il est necessaire de traiter les doccuments pour les rendre comprehensible une fois qu'ils sont dans le repository, et non pas avant ce qui traduit bien l'impossibilite d'anticipation.
page16
plan global de ce qui a ete vu plus haut
page 17
Rappel de ce que l'on possede comme systeme en tenant compte de ce qu'il y a plus haut.
Un systeme de mesure
un rapport sur le PCR
Une validation des certificats
Une validations des mesures (et non pas un rapport sur les mesures...)
Et une duree de vie de certifs.
page 18
Rappel de ce dont on a besoin
-Une com entre le repository et le registar
-Une com entre le challenger et le repository appuye par une police de validite de la plateforme
-Une com du challenger vers le repositary (?? pour l'envoi d'input cette fois ?)
-Un format pour le repositary (unifie etant sous entendu)
-Un outil pour traduire les inputs et les mettre au format repositary.
page 19
On a tout ca marche regardez ! (c'est vraiment pas une pres pour les techos)
page 20
Ben en fait non ca marche pas, il nous manque le format du repositary et des coms entre le repositary et le registar d'un cote et les coms entre le repositary et les challenger de l'autre. Bref pour l'instant tout ce qu'on vient de vous montrer n'existe pas, mais vous pouvez nous aider a le creer ! (ca ajoute encore un peu de credit a la pres...)
page 21
Bilan,
On peut certifie la fiabilite d'un composant
On peut attester de la presence d'un composant sur une plateforme via le challenger
L'ecco-systeme peut fournir des informations sur la fiabilite d'une plateforme
Bon en fait tout ca c'est au futur parcequ'on vient de commencer et que les normes sont pas fixees. D'ailleurs vous pouvez nous aider ?
page 22
C'est une bonne opportunite, viendez nombreux (on vous aime)
page 23
Merci d'etre viendu (remplissez le papier qu'on vous a donner en entrant merci)
page 24
Sauvegarde (si c'est un jet de sauvegarde comme dans AD&D ils l'ont foire)
page 25 & 26
On s'en fout.
Je veux eventuellement admettre que certains de mes arguments soient un peu leger mais de la a se faire demolir par CA !
En plus pas de trace de hash signe qui circule et qui est verifie ....
[^] # 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.
je voulais dire: fournir le hash d'un bootloader est largement suffisant pour qu'un tiers sache si il connait deja ce bootloader (ie le tiers en a deja fait un hash ou on le lui a donné !)
Non tu t'es tres bien exprime. Prenons un autre exemple. Suposons que je connaisse parfaitement un format de facture numerique (c'est a dire un formulaire vierge). Ce format contient le nom de la societe emmetrice de la facture, son adresse, son numero de telephone et son kbis.
Ce format est connu de moi, je l'ai sous la main, je peux en faire tous les hashs que je veux.
Maintenant si la societe qui utilise ce format remplit une facture, en y mettant le nom du destinataire, le detail des prestations qu'elle a fournis, le montant hors taxe, les taxes, eventuellement un rabais et la somme due avec le delai de paiement. Serais-je capabale avec un MD5 du formulaire remplit dans une main et mon formulaire vierge dans l'autre de savoir si ce MD5 correspond bien a une facture faite avec le formulaire que je connais ?
Surement pas, a moins qu'avant le hashage un masque est cache les infos variables pour ne laisser que les informations statiques. Je ne crois pas a l'existence de ce masque qui laisserait trop de place pour les bidouilleurs dans le cas de TPM, c'est tout.
non car tous les bios sont paramétrables pour choisir quel périphérique sera utilisé pour booter
Oui tu peux changer l'ordre des bootloader qui vont lui passer sous la main, mais des qu'il en trouvera un il s'arretera la et n'ira pas regarder si les periphs suivants en contienne un autre (tu parlais de jouer sur les mots tout a l'heure ?)
hash du mbr connu
Une grosse partie de mon argumentation vient du fait qu'un hash de MBR ne peut pas etre connu a l'avance (ce qui est d'ailleurs plutot rassurant).
fournir le hash d'un bootloader est largement suffisant pour qu'un tiers sache si il connait deja ce bootloader (ie le tiers en a deja fait un hash ou on le lui a donné !)
Et je maintiens que le nombre de parties variables dans un mbr ou dans un bootloader rendent cela impossible
bref ta "défense" de TCG est clairement démolie par le document intel spring2003 qui parle du début à la fin d'identifier de manière non falsifiable une plateforme à distance grace à TCG qui fournit un hash pour chaque composant !
Bon ca va etre long et sur les deux colonnes qui restent suite aux reponses en chaine ca va pas etre drole, mais allons-y
page 1-4 sans interet pour la discusion c'est l'intro
page 5 accent mis sur le fait que le hard ne doit pas mentir
cela requiert :
-des mesures fiables
-un stockage protege de ces mesures
-la capacite a prouver que l'on peut faire ces mesures
Deja la ca coince, il est marque en toute lettre que pour que la puce soit fiable il faut que les mesures (et donc le hash) soit protegees.
page 6
-Clef d'attestation
2048 bit, cree par le TPM en interne , partie privee de la clef non migrable
-Certification
Obtenue aupres d'un registar, le credential n'a pas besoin de contenir la moindre information identificatrice.
Ouch reprobleme dans ton optique, les certificats emis par les registars ne contiennent pas d'infos identificatrices, on commence a etre loin du hashage unique qui circule sur l'internet
page 7
Explication de la creation d'une certif au pres d'un registar, on remarquera l'absence de toute tarce de hashage
page 8
Explication du fonctionnement du systeme de mesure (le hashage), la mesure est stoquee dans le SML, le PCR associe est cree et signe
page 9
Un challenger veut verifier si le PCR associe a un composant est accessible, il effectue donc une demande aupres de l'autre puce pour reccuperer le certificat, le PCR signe et le SML
page 10
le challenger authetifie les composant en chaine, le registar -> AIK -> PCR -> SML.
On remarquera que rien ne permet au challenger de verifier (et donc potentiellement de decoder) le SML, ce qui est normal vu que l'AIK lui certifie deja que les infos SML sont fiables, mais ce qui pose un leger probleme dans le cadre de ta theorie d'identification des hashages....
page 11
on sait maintenant que le composant 1 est present et certifie, reste a savoir si il est fiable
page 12
Comment faire ? soit par une base de donees completement definie, soit par l'intervention d'un admin qui connait ce composant. Cette connaissance s'apelle le repository.
page 13
Le systeme necessite que la tramission de la fiabilite, ou non, du composant soit egalement fiable.
page 14
Tout ce que l'on met dans le repository : le hardware, les politiques internes, les alertes, les softs etc.
page 15
Necessite d'ajouter dans repository des composants venant de plusieurs horizon. On notera aussi qu'il est necessaire de traiter les doccuments pour les rendre comprehensible une fois qu'ils sont dans le repository, et non pas avant ce qui traduit bien l'impossibilite d'anticipation.
page16
plan global de ce qui a ete vu plus haut
page 17
Rappel de ce que l'on possede comme systeme en tenant compte de ce qu'il y a plus haut.
Un systeme de mesure
un rapport sur le PCR
Une validation des certificats
Une validations des mesures (et non pas un rapport sur les mesures...)
Et une duree de vie de certifs.
page 18
Rappel de ce dont on a besoin
-Une com entre le repository et le registar
-Une com entre le challenger et le repository appuye par une police de validite de la plateforme
-Une com du challenger vers le repositary (?? pour l'envoi d'input cette fois ?)
-Un format pour le repositary (unifie etant sous entendu)
-Un outil pour traduire les inputs et les mettre au format repositary.
page 19
On a tout ca marche regardez ! (c'est vraiment pas une pres pour les techos)
page 20
Ben en fait non ca marche pas, il nous manque le format du repositary et des coms entre le repositary et le registar d'un cote et les coms entre le repositary et les challenger de l'autre. Bref pour l'instant tout ce qu'on vient de vous montrer n'existe pas, mais vous pouvez nous aider a le creer ! (ca ajoute encore un peu de credit a la pres...)
page 21
Bilan,
On peut certifie la fiabilite d'un composant
On peut attester de la presence d'un composant sur une plateforme via le challenger
L'ecco-systeme peut fournir des informations sur la fiabilite d'une plateforme
Bon en fait tout ca c'est au futur parcequ'on vient de commencer et que les normes sont pas fixees. D'ailleurs vous pouvez nous aider ?
page 22
C'est une bonne opportunite, viendez nombreux (on vous aime)
page 23
Merci d'etre viendu (remplissez le papier qu'on vous a donner en entrant merci)
page 24
Sauvegarde (si c'est un jet de sauvegarde comme dans AD&D ils l'ont foire)
page 25 & 26
On s'en fout.
Je veux eventuellement admettre que certains de mes arguments soient un peu leger mais de la a se faire demolir par CA !
En plus pas de trace de hash signe qui circule et qui est verifie ....
pouf pouf
Kha