Non je demontre jsute que si tu fait de l'embarque, tu peux creer ton propre systeme de verification a peu pres aussi efficace que TCPA pour une fraction du prix. Cela s'eplique facilement car
1) tu connais par avance le systeme et ses tolerances, tu n'as donc pas besoin de systeme de mesure.
2) tu veux juste verifier si une information que tu possedes est vraie sur une plateforme, tu n'as donc pas besoin de systeme de cryptage pour comuniquer.
Les deux fonctions "cheres" de TCPA te sont donc parfaitement inutile. Pourquoi alors investir de l'argent dans un systeme complexe qui ne te sert a rien, alors que tu peux faire un systeme et peu couteux qui a toutes les caracs dont tu as besoin ?
depuis quand valeur siginifie nom quelle mauvaise foi !!!
Oups desole, c'est encore un piege de mes tres vieilles et antiques docs dans lesquels il est fait mention sans arret du PCR value (adresse du segment PCR ou commence la boite a clef) et du PCR content (contenu de la boite).
Mais bon pour que les fans de Niklaus Wirth ne hurlent pas a l'infamie (ben oui tout le monde sait tres bien que l'on accede aux elements par valeur ou par adresse). Seulement tout le monde sait aussi qu'il y a un piege : les zones memoires ! Ben oui la valeur d'une zone memoire c'est justement son adresse, et les pointeurs sont la pour en attester. Hors le PCR (et ses segments) sont des zones memoires...
comment s'assurer que le fonctionnement de cette puce n'est pas contourné par l'utilisateur ?
Alors tu fabrique un module avec une prom (qui contient le numero de serie de l'appareil et eventuellement des codes de verif), une puce de hashage (qui supporte plusieurs systeme c'est mieux) et deux nappes pour le plugger sur ta carte.
Tu prend un polymere quelconque (un gros truc qui tache et qui peut pas s'enlever a l'acetone sans demolir les composants)
Tu prend ton montage et tu le noies dans le polymere (a l'execpetion des nappes bien sur)
Tu mets ce montage en serie sur ton bus (cpu+memoire < -> module< -> interface).
Et voila tu as pour 3 francs par modules (le prix que ca va te couter en volume) un systeme quasi incassable.
Tu peux compliquer ton modules si tu as besoin de plus de fiabilite, mais honettement tu es tranquile pour un moment.
le MBR est un secteur contenant un exécutable et une zone de donées
Je me demande qui fait expres de ne pas comprendre
On peut utiliser une partie du MBR comme une zone de donnees, apres tout c'est un secteur du disque comme les autres. On peut meme utiliser tout le MBR comme une zone de donnees. Mais ca ne change rien au fait que le bios ne considerera jamais un MBR commencant avec une siganture de boot comme une zone de donnees.
Si tu decide de couper ton mbr en deux et de mettre l'executable au debut et les donnees a la fin, tu n'as AUCUN moyen de dire au bios ou se trouve la coupure. Le bios n'a AUCUN moyen de la trouver par lui-meme, et quand au disque dur IL NE SAIT MEME PAS CE QU'EST UN MBR.
Ta zone de donnees sur le MBR est arbitraire, c'est le programmeur du bootloader qui a decide de la mettre la. Mais le MBR n'a pas de facon normee deux zones predefinies. Le bios ne peut donc pas faire le distingo entre ces deux zones PARCEQU'ELLES N'EXISTENT PAS. Il n'y a qu'une seule zone physique, qui n'est pas uen zone de donnees en regard du bios.
Si tu cree avec ton editeur de texte favori un texte dont les dix premeieres lignes sont du code C, et la suite un poeme de Ronsard IL S'EN FOUT. Par ce qu'il ne sait pas ce qu'est le C, il ne sait pas qui est Ronsard ou ce qu'est un poeme. Pour le bios c'est pareil, il ne sait pas ce qu'est un executable, il ne sait
pas comment ca marche ni pourquoi ca marche. Tout ce qu'il sait c'est que si il rencontre un motif sur la premiere tete du premier cylindre du premier secteur il doit charger TOUT le premier secteur en memoire. Et si un programmeur decide d'utiliser tout ou partie du mbr COMME une zone de donnees, ca n'en fait pas une zone une zone de donnees pour le bios.
J'ai oublie ton PS. A l'epoque ou j'etais en stage chez 2a2e on travaillait quasi exclusivement avec des aveugles. Peu de chance qu'ils s'amusent a trifouiller leur machine (d'ailleurs la question ne s'est meme jamais pose).
Depuis je n'ai pas rebosse dans l'embarque, amis sur une plateforme embarque il est TRES facile de savoir a distance si il y a eu des modifs ou non (pour peu que le systeme possede une connection a distance), et ce sans passer par TCPA ou DRM. Tu met une puce de hash, tu lui demande un hash d'une section de programme que tu connais et c'est fini.
Bon le mot extrai ne te plait pas, tu prefere le mot partie qui prete a confusion, est-ce partie au sens "partie de la ville" ou partie au sens "partie d'un tout"
La question est donc de savoir si la puce renvoit la valeur du PCR (le nom de la boite) ou le contenu du PCR (le contenu de la boite)
Et la reponse est Challenger recieves from platform
- SML, AIK cred and PCR value signed by AIK
mais tu a clairement eu tort tout à l'heure de dire qu'on ne peut pas stocker la totalité des données modifiables en fin de mbr
Mais bien sur que l'on peut, je n'ai jamais dit le contraire. Les boot loader windows9x et dos le font d'ailleurs. Je dit juste que le bios n'est pas capable de faire le distingo sur le MBR entre les donnees et l'executable, et qu'il faudrait severement le modifier pourqu'il devienne capable de le faire !
Le bios ne comprend pas ce qu'il lit sur le MBR, seul le CPU le peut. Il peut reconnaitre a certains critere si il s'agit d'un boot loader ou non et c'est tout, de la meme facon qu'acrobat reader te jette pour tout fichier qui ne commence pas par %PDF, le bios ignore les BR qui ne commencent pas par une certaine sequence. Si il recupere cette sequence par contre il charge l'integralite du BR en memoire et il fait faire un jump au CPU sur ce segment. Peut lui importe que ce soit effectivement un BR ou une coincidence malheureuse. On peut parfaitement par exemple faire une disquette de donnees pures qui plantera un PC en boucle, et ce sans le faire expres.
Dans un executable, il y a des variables. la position des variables dans l'executable (au debut, a la fin au millieu) ne change rien au fait que ces variables font parties integrantes de l'executable. Le bios charge le premier secteur en entier (init du boot loader, qui n'est pas forcement le boot loader complet mais qui est un bon debut). Pour pouvoir lire ensuite les donnees situees n'importe ou ailleurs que sur le MBR, cet init de boot loader a besoin d'infos sur le disque.
Donc soit le bios est capable de faire le distingo entre la partie executable et la partie donnee sur le MBR (et la bravo parceque c'est de l'octet brut) pour ne hasher que la zone executable. Soit il hashe aussi les donnees. Aujourd'hui le bios hashe aussi les donnees.
il est bien précisé que la value PCR envoyées est signée et non cryptée !
il est dit : "quote of PCR that contains component1 measurement" ce qui veut dire l'extrait du PCR qui contient la mesure du composant1.
Traduction simpliste "bonjour, c'est quoi le morceau de PCR qui est lie a la mesure du composant1 ?"
Reponse attendue "C'est le 42".
Rien a voir avec la transmission du contenu du PCR et surtout de la mesure du composant1.
Il est dit aussi : "PCR value signed by AIK" ce qui veut dire que la valeur du PCR est signe par le AIK.
La question est de savoir si le challenger recoit juste la signature ou la valeur du PCR + la signature. Pour moi il ne recoit que la signature. Mais meme si il recevait la valeur + la signature ca ne serait pas grave, parcequ'il recoit la valeur du PCR et non son contenu. Il recoit donc le nom de la boite a clef, mais ne sait rien sur les clefs a l'interieur....
Kha
Ah fait pour 2A2E, pourquoi ? Ils ont laisse tomber les vaeugles et se lancent dans le DRM ?
On ne doit pas hasher la zone de donnees, mais les donnees qui font partie de l'executable sont bien entendue prise en compte. Sinon comment identifier un bootloader generique de type NT ?
C'est peut etre evident, mais pour l'instant c'est pas le cas.
Relit ta propre citation, le bios charge TOUT le premier secteur. De toute facon si le bios ne charge pas les donnees, il va avoir du mal a les loger en memoire pour l'execution de l'init du boot loader. Et donc le jump risque d'etre compromis.
par rapport au mbr, sa définition est très simple: tous les octets du premier secteur du disque booté (au moins 512 octets) sont chargés en mémoire par le bios, qui exécute ce mbr à partir du premier octet
On est d'accord
il n'y a absolument rien qui empeche de mettre toutes les données à la fin de ces octets
du tout
et de fait, un recherche sur google avec mbr "first sector" bytes retourne plusieurs documents qui détaillent des mbr dont les données sont stockées à la fin de ces octets !
Tout a fait
une fois de + tu dis ce qui t'arrange, pas la vérité !!!
Ben en l'occurence la ta verite m'arrange vachement (au fait c'etait aussi la mienne, mais je t'en laisse la paternite si tu y tiens)
Regarde :
Si le bios lit tout le premier secteur, et si les donnees sont sur ce premier secteur, et si il est obligatoire de hasher le contenu du bios avant de faire le jump vers l'execution de l'init du boot loader => les donnees vont se faire hasher avec la partie non donnees.
Tant que le bios n'est pas capable de s'arreter en cours de chemin lors de la partie lecture du premier secteur (ie tant qu'il n'est pas capable de lire seulement l'exe et de bloquer les donnees), les donnees se feront hasher.
au fait, contrairement à ce que tu avais plusieurs fois affirmé avec véhémence
Ce que j'ai affirme avec vehemence, et que d'ailleurs je maintiens, et que pour que ta theorie se verifie il faudrait un bios qui se comporte vis a vis du disque dur, ou un disque dur qui se comporte vis a vis du bios de facon differente de ce qui existe aujourd'hui. Je le maintiens.
Bien sur que le bios doit etre capable de recevoir et de transmettre des informations a la puce TPM, mais son fonctionnement du point de vue de la machine hors TPM n'a pas bouge d'un iota. Et rien ne laisse penser que ce sera le cas.
pour le boot loader tu n'expliques toujours pas pourquoi la config du disque ne serait pas située juste après l'exécutable, et y'a pas besoin de hasher une zone de données !!!
J'y revient avec ton deuxieme posts en dessous
je maintiens qu'il est marqué en toutes lettres page 9 que le challenger va obtenir la mesure du component1
Alors a part le dessin il est marque en toute lettre
Le challenger demande un extrait du PCR qui contient les mesures du composant1
Le challenger recoit de la plateforme le SML la certif AIK et la valeur du PCR signee par l'AIK
Juste pour savoir elles ont ou les mesures ?
-Le certificat AIK est une clef publique generee a la demande du registar pour prouver la presence d'une puce TPM sur la plateforme, il est independant du materiel autre que la dite puce. La clef privee est generee par la puce et ne sort pas.
- Le SML est le log des hashages materiel, sa presence certifie que le PCR envoye correspond bien au composant demande en on pas a un autre composant. Il est egalement independant du materiel et notamment de la nature du composant.
-Le PCR signe par l'AIK est non seulement crypte par l'AIK, mais il est egalement independant du materiel. Il correspond au "numero" de la boite qui contient le hashage du materiel ainsi que les clefs eventuelleemnt placee la.
Seul le "contenu" du PCR est dependant du materiel, mais lui il n'apparait nul part.
Je m'interresse a TCPA en tant qu'utilisateur nous n'avons ni moi, ni aucune des boites pour lesquelles j'ai travaille, ni la boite pour laquelle je travaille le moindre interet financier ou contractuel envers les technologies TCPA
Moi je suis dev de jeux sur mon temps libre, je m'interresse tout particulierement aux shaders parceque c'est vraiment plus souple que le T&L que je n'ai jamias pu blairer :
Voici ce que je pense des drivers NVidia sous Windows :
1) Impossible de certifier le triple buffering, si la carte charge elle repasse en double, tant pis pour les effets qui requierent trois buffers
2) Les shadders sont sur 16 ou 32 bits, dommage la norme est a 24 bits en OpenGL et sous Dx9. CX'est en dur sur la carte on ne pourra rien y changer. En 16 bits c'est rapide mais moche et en cas d'accumulation de shaders sur une textures bonjour les erreurs
En 32 bits c'est lent (mais alors beaucoup). De plus la taille du shader permettant surtout de passer a une texture de taille superieure en 16 bits on est en 256x256 (bof) en 24 on est en 2048x2048 ca commence a etre suffisant, en 32 bits on est en plusieurs millionsx plusieurs millions (je vois pas l'interet du tout)
3) Il y a eu des optimisations plus que douteuses sous 3D Mark, notemment le precalcul des surfaces caches pour les parties non interactives de la demo. Comme ca on coupe le Z sorting et on gagne en Bande passante. Ca fait un gros score au 3D mark mais ca ne correspond a rien en terme de perfs dans un environement de jeux standard.
4) Personne n'a encore vu le nouveau driver avec 40 a 50% de gains de perf en plus qui devait sortir cette semaine. Nvidia nous a deja fait ce coup la une fois lors de la guerre de l'anti aliasing, je me mefie beaucoup. Il existe peut-etre mais tant qu'il n'est pas telechargeable et que je n'ai pas pu voir de mes yeux ses perfs et sa qualite je reste sur mes positions
Car concevoir un ou plusieurs exécutables MBR hashables qui se contentent de stocker les paramètres du HDD dans une zone de données n'a rien d'impossible
Actuellement si. Pour pouvoir etre reconnu comme bootable par le bios et pour pouvoir reconnaitre le disque dur (et donc par la suite le lire) l'init du boot loader depend de la config de ce fameux disque. Donc meme si tu stoques des infos sur le disque a cote impossible de les lire si ton init de bootloader n'est pas correct. Impossible de "casser" le boot loader en un init indenpendant du DD et une zone de donnees. Un boot loader qui ne ferait rien d'autre que d'aparaitre comme init de boot loader au yeux du bios avant d'afficher le message "coucou" qu'il lirait sur une zone du mbr apres avoir ete jumpe par le bios serait deja tres dependant du type de disque dur.
page 9 il est expliqué que le challenger va obtenir la mesure du component1 (mesure qui est définie page 8 comme étant le hash du component1)
OOUUUIII je l'attendais celle la, et en plus j'ai volontairement laisse planner la confusion pour voir si tu allais mordre, ca n'a pas loupe. J'imagine que tu fait allusion a la fleche qui part du SML de la plateforme pour aller vers le SML du challenger non ?
Si c'est le cas jette un coup d'oeuil sur ce qu'est le SML et tu comprendras que tu peux dormir sur tes deux oreilles....
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 ....
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.
ce n'est pas du tout ce qu'il ressort du document Intel déjà cité !
Ce n'est pas comme ca que je comprend le doccument Intel, qui parle de certifier un hash mais pas de le stocker, par contre la norme TCPA est tres claire a ce sujet les hashs sont impossibles a faire sortir de la puce.
et qu'est-ce qui empeche un bios spécialement conçu pour TCG (c'est quand meme ce dont parle la news ici) de s'assurer que ce premier exécutable est généré par un programme signé par MS puis de signer (ou mémoriser le hash) de ce premier exécutable après sa génération ? rien
C'est bien pour ca que je suis en rogne figure-toi il y aura un bios phenix qui supportera le Secure Computing (propriete exclusive de MS), aucun rapport avec le Trusted Computing (IBM, INTEL, AMD et MS). Le confusion entre les deux (entretenu par MS il faut bien le dire) m'ennerve.
Le bios peut s'assurer que le loader est conforme a une signature a condition d'avoir une clef. Cette clef devant etre protege contre la copie pour etre efficace. A partir du moment ou il y a une clef protege dans le bios MS n'a plus besoin de la puce TPM, le boulot est deja fait.
mais de toutes façons tout ceci est probablement inutile car il faudra que tu m'expliques où tu as vu que le premier programme ne peut pas ajouter au PCR le hash du 2e programme et ainsi de suite
La norme TCPA indique clairement que la zone de donnee ne doit pas renter en compte dans le hashage, si le bios le fait quand meme il viole la norme. De plus il faut que le bios soit capable de lire le disque. Une fois de plus on en revient a un bios special qui est capable de faire la lecture du contenu du disque pour verification. Il n'a deja plus besoin de la puce TPM a ce moment la.
pas une fois que le bios a donne la main (en stockant son hash) au premier programe: si ce prmeier programme et les suivants ne permettent pas à l'utilisateur de modifier ce hash il sera infalsifiable même par l'utilisateur
Si je me logue en admin TPM et que je boot sur un autre disque rien ne m'empeche de sortir la clef. Une fois de plus il faudrait que le bios (la puce TPM ne peut pas empecher un boot) m'empeche de booter une solution alternative. Si il est capable de faire ca il n'a plus besoin de TPM non plus.
le (I), le (II) et l'existence possible d'une base de hash de chaque élément sont clairement démontrés !
Toujours pas non, et apres il te reste encore a demontrer que c'est possible de le mettre en place ( cf 3 de mon post precedent) et que c'est utilisable (cf 4 ) ....
I) - le seul segment chargeable par le bios et l'init boot situer sur la zone boot du support (pour les disques durs : le MBR).
- La puce TPM ne contient pas de systeme de reconaissance de signatures externes, elle ne peut que reconnaitre son propre travail. MS ne peut donc pas "signer" un programme de boot, la puce peut seulement reconnaitre une sequence qu'elle a deja "vu" avant.
- La puce n'exporte pas les hashs elle peut juste mettre une clef prive dans uen boite associe a un PCR. La seule chose qui sortira de la puce est la clef publique associee.
- Les clefs privees sont migrables d'une zone a l'autre par l'admin puce, une clefs lie a un PCR peut odnc etre deplacee vers une zone ouverte a tous.
- La puce hash le premier executable charge par le bios, or celui-ci varie suivant le support, le format du disque, ses partition etc. Il est donc impossible de creer ce programme a priori et de le signer. Il ne peut etre genere qu'a posteriori.
jusque là on est d'accord ? très bien (I)
Meme pas en reve
de (I) et (II) je déduis:
un tiers qui recoit le hash de L signé par ma puce TCG peut avoir la certitude que j'utilises un OS signé par MS avant d'être booté
Quel dommage qu'un tiers ne puisse pas recevoir le hash et que les programmes ne soient pas certifiables a priori mais doivent certifie a posteriori par l'utilisateur (de toute facon la norme TCPA interdit de precharger des clefs donc le probleme est regle).
PS en ce qui concerne le doc de Intel il faut que tu me dises où il est précisé que les mécanismes évoquées ne sont pas utilsables par internet ! (et où il est précisé que cela concerne seulement un usage interne !)
Ils sont bien entendu utilisable sur internet, ce n'est pas cela que je remet en cause, c'est le cote base de donnees unifiee. La puce TPM permet de faire deux choses au niveau des identifications
1) assurer via un registar (interne ou externe) que tu possede bien un TPM.
2) garantir via un repository (interne ou externe) que tu as toujours acces aux clefs qu'il t'a fait generer.
Identifier le materiel sous jaccent au hashage est tout simplement impossible
1) parceque les informations du hashage ne sortent jamais de la puce (elles ne sont pas migrables non plus)
2) parceque les clefs privees genere par TPM et stoquees dans un PCR sont independantes du PCR, et donc les clefs publiques (seules a sortir du TPM hors methode de migration) aussi.
3) parceque TPM ayant pour but d'identifier precisement une machine par rapport a une autre meme du meme modele possede des systemes de mesures extremenent pointus qui vont probablement faire correspondre des hashages differents a des produits d'apparence rigoureusement identique pour l'homme.
4) Meme si le hashage etait identique pour deux composants configures de la meme facon sur deux machines avec deux TPMs differents et que le hashage etait visible il faudrait une base de donnees monstrueuse pour le gerer. Exemple pour l'init du boot qui te plait tant, il existe
(Modeles disque dur)x(Formatages bas niveau possibles sur le disque dur)x(Geometries physiques possible compte tenu du formatage bas niveau)x(partitionnements possibles)x(position de l'OS loader sur le disque)x(type du boot loader)x(configuration du boot loader)x(type de l'OS loader) possibilites (et je pense que j'en oublie).
j'ai jamais dit le contraire, je dis juste que la chain of trust, si elle est poursuivie par le bootloader et l'OS va permetter de s'assurer à distance de quel OS on utilise:
La chaine of trust ne peut etre poursuivi que logiciellement, vu que la puce ne peut pas stoquer ces informations la. On retombe donc sur une banale securite logicielle. Oui c'est faisable, non c'est pas incassable. De plus toutes les clefs accessibles par l'exterieur de la puce TPM sont migrables. Bonne chance donc pour avoir une assurance quelconque.
si MS fait un bootloader qui n'accepte de booter qu'un windows signé par MS (le bootlaoder vérifie avec une clé publique de MS que les exécutables sont signés par la clé privée de MS)
Bien sur qu'ils peuvent faire ca mais ils seront oblige de le faire en logiciel, la puce TPM n'apportera rien.
la présence du hash de ce bootloader dans les infos PCR signées par TCG sera la preuve infalsifiable (à cause de la signature du TPM) qu'on a un windows signé par MS
La presence (ou l'absence) d'un hash particulier dans une puce TPM est impossibel a dectecter. Tout ce que l'on peut faire c'est de challenger une clef qui se trouve normalement protege dans une zone dependante de ce hash. Mais si l'admin migre la clef tout se barre. Le challenger aura acces a la clef mais il n'aura aucun moyen de savoir si elle depend encore d'un hash PCR ou non.
voir le document Intel spring2003 pour les modalités
Tu gagne 1$ a chaque fois que tu cites ce doc c'est pas possible. Relit le tu verras qu'il parle d'une methode au sein d'une entreprise avec un admin qui remplit le repository lui meme pour l'usage exclusif de sa boite. Pas de plan mondial de recuperation de tous les hash de tous les PCR de la planete (ce qui tombe bien parcequ'ils ne sont pas recuperable de toute facon...)
je crois que tu n'as toujours pas compris la notion de chain of trust lors du boot:
Ta definition est amusante, quel domage qu'elle soit fausse. Pour ton information voici comment marche la chaine of trust :
Les clefs abritee par la puce TPM (TCG etant le nom du groupe une fois de plus) sont enfermes dans des boites gigognes. Pour que TPM accepte de libere une clef il faut qu'un certains nombre de conditions soient verifiees par les hashs PCR.
Ces conditions peuvent etre nulles (clef accessible a tous) ou demander que l'utilisateur soit le bon, ou demander que l'utilisateur, le bios, les periphs PCI, et le MBR soit les bons. Cette liste de conditions a remplir forment la chaine of trust. A savoir que tu peux faire confiance a la puce qui fait confiance au bios qui fait confiance au MBR.
Il n'y a pas d'executables ecrits "specialement" pour le systeme TCPA. Le bios doit bien sur pouvoir repondre aux demandes de la puce (sans quoi toutes les coffres qui contiennent des clefs necessitant un PCR dependant du bios restent fermees) mais ca s'arrette la. Une fois de plus la puce TPM ne peut pas et ne doit pas hasher les zones de donnees. Les seules informations qu'elle aura sur le disque seront sur le MBR. Ensuite uen fois les informations sur le MBR recoltee elle aura fini son hashage des composants. L'ensemble du PCR sera fixe et tout ce qui arrive apres ne la concerne pas. Meme si le boot loader etait certifie par un tiers et pouvait identifier l'OS il ne pourrait pas stocker l'information dans la puce (qui n'a pas d'emplacement PCR pour stoquer cette information), mais en plus ca n'est pas le cas.
tout ceci est amplement confirmé par le document Intel du printemps 2003 que j'ai cité ci-dessus, dicument qui précise que chaque hash qui compose le PCR (ciomponent) est obtensible séparément et avec une signature assurant un tiers qu'il n'a pas été truqué par l'utilisateur (on voit bien que l'unique fonction de TCG par rapport à des softs libres équivalents est de se méfier de l'utilisateur pour faire plaisir à un tiers !)
Oui c'est l'idee meme de la crypto non ? Chercher a verifier que la personne avec qui je dialogue est bien qui elle pretend etre. Pour finir les hashs ne sont pas obtensible separement, par contre tu peux faire une chaine of trust de longueur 1 qui ne hash qu'un seul peripherique. Par exemple tu creer une boite a clef tout utilisateur sur le PCR qui a hashe le periph PCI1 et tu demandes a TPM de te creer une clef privee dans cette boite.Ensuite tu demande la clef publique et tu la stoque dans ton repositary. Derriere si tu veux savoir si le periph PCI1 est bien identique a celui que tu connais et auquel tu fais confiance tu vas chercher la clef publique dans ton repositary et par un challenge reponse tu verifie que la clef privee et bien dans le TPM avec qui tu dialogue et qu'elle est disponible (ie que la chaine of trust de PCI1 est respectee).
Mais comme la clef privee cree par le TPM n'a aucun rapport avec le composants sur PC1 impossible de faire marche arriere et de deduire le composant de la clef privee. A plus forte raison de la clef publique.
Les parties hashages du PCR (checksums ) sont en zone dite interne de la puce. Impossible donc de les faire sortir ou de les migrer.
bref, TCG n'apporte aux utilsiateurs d'OS libres qu'une seule chose: pourvoir se faire identifier à distance par des tiers comme n'étant pas utilisateurs d'un OS DRM non modifiable !
Ben en tant qu'heureux possesseur d'une puce TPM et utilisateur de logiciel libre je te dis bien fort non. Ca apporte pleins de choses. Et comme en plus l'identification d'un OS DRM par TPM est inpossible a moins bien sur qu'il ne tienne integralement sur le MBR (bonne chance) et qu'une clef d'identification ai ete prechargee dans le PCR assiocie a cette sequence de boot (ce qui est interdit par la norme).
(et en + un OS DRM pourra facilement stocker des stockée des données non acessibles aux autres OS, autres OS qui devront par ailleurs booter sur CD car l'utilisation d'un lilo/grub entrainerait une rupture de la chain of trust)
Toutes les donnees accessibles ou challengables par l'exterieur sont migrables (et heureusement d'ailleurs pour des raisons de maintenance). L'admin de la puce peut donc sortir n'importe quelle clef de n'importe quel coffre et la placer dans un autre, par exemple celui daont la chaine of trust passe par lilo/grub ou le boot sur le cd de la knoppix.
REFUSONS TOUS les softs et hards TCG avant qu'il ne soit trop tard !
Oui si vous voyez un soft TCG refusez le ! Il n'existe pas, le vendeur est en train de vous arnaquer, la puce TPM ne peut pas hasher les zones de donnees.
où il est précisé qu'il faut créer un système mondial ("eco-system") de tous les hashs de tous les composants certifiés TCG (soft et hard) d'un ordinateur !
Comme quoi on peut avoir un DEA avec mention tres bien et ne pas savoir ce qu'est un ecco-systeme.
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.
Bon j'arrete la.
Ca ne sert a rien de discuter avec une personne qui ne sait pas de quoi elle parle du tout et qui repette plusieurs fois exactement le meme argument. Tu trouvera la reposne a cette affirmation grotesque un peu plus haut.
Doccument toi sur le processus de boot sans TCPA, notamment les phases d'initialisation du boot loader, la relache des interrupts par le bios et le passage en mode protege.
c'est carrément incompréhensible ce que tu dis là, et la clé privée associée à cette clé publique elle sort d'où ?
Ben non hashage plus+nombre aleatoire + algo -> clef privee (qui ne sort pas de la puce TCPA sauf migration declenchee physiquement a la main par l'admin)
clef privee + aleatoire + algo -> clef publique (la seule qui sort).
C'est tout a fait classique le "dans uen certaine mesure" ne sert qu'a dire qu'il n'y a rien de trivial a repasser de la clef publique au checksum
ah bon ? et pourquoi ?
Parceque si il etait facile de faire un emulateur de puce TCPA sur un PC sans puce, alors la puce TCPA n'aurait strictement aucun interet (et meme s'en servir serait dangereux).
Ca c'est pour la raison logique.
Emuler uen puce via un logiciel est souvent long, la plupart des processeurs et des puces sont emules avec des facteurs de 100 voir de 1000 en ralentissement. De plus le comportement d'un emulateur n'est jamais rigoureusement identique surtout en ce qui concerne par exemple la generation de nombres pseudo-aleatoires, et comme c'est une des capacites primordiales de la puce...
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.
Ouais ! alors voila comment ca marche :
Le bios il s'initialise et au bout d'un moment il se sent seul, alors ils regarde a des endroits bien definis des fois qu'il y aurait pas un petit bout de code qui lui permette de repasser le bebe a quelqu'un d'autre.
Ce bout de code est charge par le bios, il donne le tout debut de l'init de la phase de boot de l'OS. A savoir 1) la position du loader 2) son point d'execution. Tres efficace pour savoir si on a touche au disque dur depuis la derniere fois, totalement inutile si on veut connaitre l'OS qui va etre lance. Je peux parfaitement reprendre exactement l'init boot loader de Windows2003 et le faire pointer sur un autre boot loader. Comme je ne suis pas encore passe en mode protege c'est la fete. Au moment du passage en mode protege le Bios est OUT, le Bios ne peut qu'ouvrir la porte au mode protege, de la il suffit que la premiere instruction quand le bios a tourne le dos soit "fausse alerte, on boot comme ca finalement" pour que la puce TCPA n'y voit que du feu au niveau de l'OS (par contre elle pourra se rendre compte qu'il y a eu des changement sur le disque).
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
1) tu connais par avance le systeme et ses tolerances, tu n'as donc pas besoin de systeme de mesure.
2) tu veux juste verifier si une information que tu possedes est vraie sur une plateforme, tu n'as donc pas besoin de systeme de cryptage pour comuniquer.
Les deux fonctions "cheres" de TCPA te sont donc parfaitement inutile. Pourquoi alors investir de l'argent dans un systeme complexe qui ne te sert a rien, alors que tu peux faire un systeme et peu couteux qui a toutes les caracs dont tu as besoin ?
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 0.
Oups desole, c'est encore un piege de mes tres vieilles et antiques docs dans lesquels il est fait mention sans arret du PCR value (adresse du segment PCR ou commence la boite a clef) et du PCR content (contenu de la boite).
Mais bon pour que les fans de Niklaus Wirth ne hurlent pas a l'infamie (ben oui tout le monde sait tres bien que l'on accede aux elements par valeur ou par adresse). Seulement tout le monde sait aussi qu'il y a un piege : les zones memoires ! Ben oui la valeur d'une zone memoire c'est justement son adresse, et les pointeurs sont la pour en attester. Hors le PCR (et ses segments) sont des zones memoires...
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Alors tu fabrique un module avec une prom (qui contient le numero de serie de l'appareil et eventuellement des codes de verif), une puce de hashage (qui supporte plusieurs systeme c'est mieux) et deux nappes pour le plugger sur ta carte.
Tu prend un polymere quelconque (un gros truc qui tache et qui peut pas s'enlever a l'acetone sans demolir les composants)
Tu prend ton montage et tu le noies dans le polymere (a l'execpetion des nappes bien sur)
Tu mets ce montage en serie sur ton bus (cpu+memoire < -> module< -> interface).
Et voila tu as pour 3 francs par modules (le prix que ca va te couter en volume) un systeme quasi incassable.
Tu peux compliquer ton modules si tu as besoin de plus de fiabilite, mais honettement tu es tranquile pour un moment.
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Je me demande qui fait expres de ne pas comprendre
On peut utiliser une partie du MBR comme une zone de donnees, apres tout c'est un secteur du disque comme les autres. On peut meme utiliser tout le MBR comme une zone de donnees. Mais ca ne change rien au fait que le bios ne considerera jamais un MBR commencant avec une siganture de boot comme une zone de donnees.
Si tu decide de couper ton mbr en deux et de mettre l'executable au debut et les donnees a la fin, tu n'as AUCUN moyen de dire au bios ou se trouve la coupure. Le bios n'a AUCUN moyen de la trouver par lui-meme, et quand au disque dur IL NE SAIT MEME PAS CE QU'EST UN MBR.
Ta zone de donnees sur le MBR est arbitraire, c'est le programmeur du bootloader qui a decide de la mettre la. Mais le MBR n'a pas de facon normee deux zones predefinies. Le bios ne peut donc pas faire le distingo entre ces deux zones PARCEQU'ELLES N'EXISTENT PAS. Il n'y a qu'une seule zone physique, qui n'est pas uen zone de donnees en regard du bios.
Si tu cree avec ton editeur de texte favori un texte dont les dix premeieres lignes sont du code C, et la suite un poeme de Ronsard IL S'EN FOUT. Par ce qu'il ne sait pas ce qu'est le C, il ne sait pas qui est Ronsard ou ce qu'est un poeme. Pour le bios c'est pareil, il ne sait pas ce qu'est un executable, il ne sait
pas comment ca marche ni pourquoi ca marche. Tout ce qu'il sait c'est que si il rencontre un motif sur la premiere tete du premier cylindre du premier secteur il doit charger TOUT le premier secteur en memoire. Et si un programmeur decide d'utiliser tout ou partie du mbr COMME une zone de donnees, ca n'en fait pas une zone une zone de donnees pour le bios.
Voila
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Le MBR d'un disque dur n'est pas une zone de donnees.
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Depuis je n'ai pas rebosse dans l'embarque, amis sur une plateforme embarque il est TRES facile de savoir a distance si il y a eu des modifs ou non (pour peu que le systeme possede une connection a distance), et ce sans passer par TCPA ou DRM. Tu met une puce de hash, tu lui demande un hash d'une section de programme que tu connais et c'est fini.
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 0.
La question est donc de savoir si la puce renvoit la valeur du PCR (le nom de la boite) ou le contenu du PCR (le contenu de la boite)
Et la reponse est
Challenger recieves from platform
- SML, AIK cred and PCR value signed by AIK
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Mais bien sur que l'on peut, je n'ai jamais dit le contraire. Les boot loader windows9x et dos le font d'ailleurs. Je dit juste que le bios n'est pas capable de faire le distingo sur le MBR entre les donnees et l'executable, et qu'il faudrait severement le modifier pourqu'il devienne capable de le faire !
Le bios ne comprend pas ce qu'il lit sur le MBR, seul le CPU le peut. Il peut reconnaitre a certains critere si il s'agit d'un boot loader ou non et c'est tout, de la meme facon qu'acrobat reader te jette pour tout fichier qui ne commence pas par %PDF, le bios ignore les BR qui ne commencent pas par une certaine sequence. Si il recupere cette sequence par contre il charge l'integralite du BR en memoire et il fait faire un jump au CPU sur ce segment. Peut lui importe que ce soit effectivement un BR ou une coincidence malheureuse. On peut parfaitement par exemple faire une disquette de donnees pures qui plantera un PC en boucle, et ce sans le faire expres.
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Donc soit le bios est capable de faire le distingo entre la partie executable et la partie donnee sur le MBR (et la bravo parceque c'est de l'octet brut) pour ne hasher que la zone executable. Soit il hashe aussi les donnees. Aujourd'hui le bios hashe aussi les donnees.
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
il est dit : "quote of PCR that contains component1 measurement" ce qui veut dire l'extrait du PCR qui contient la mesure du composant1.
Traduction simpliste "bonjour, c'est quoi le morceau de PCR qui est lie a la mesure du composant1 ?"
Reponse attendue "C'est le 42".
Rien a voir avec la transmission du contenu du PCR et surtout de la mesure du composant1.
Il est dit aussi : "PCR value signed by AIK" ce qui veut dire que la valeur du PCR est signe par le AIK.
La question est de savoir si le challenger recoit juste la signature ou la valeur du PCR + la signature. Pour moi il ne recoit que la signature. Mais meme si il recevait la valeur + la signature ca ne serait pas grave, parcequ'il recoit la valeur du PCR et non son contenu. Il recoit donc le nom de la boite a clef, mais ne sait rien sur les clefs a l'interieur....
Kha
Ah fait pour 2A2E, pourquoi ? Ils ont laisse tomber les vaeugles et se lancent dans le DRM ?
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Relit ta propre citation, le bios charge TOUT le premier secteur. De toute facon si le bios ne charge pas les donnees, il va avoir du mal a les loger en memoire pour l'execution de l'init du boot loader. Et donc le jump risque d'etre compromis.
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
On est d'accord
il n'y a absolument rien qui empeche de mettre toutes les données à la fin de ces octets
du tout
et de fait, un recherche sur google avec mbr "first sector" bytes retourne plusieurs documents qui détaillent des mbr dont les données sont stockées à la fin de ces octets !
Tout a fait
une fois de + tu dis ce qui t'arrange, pas la vérité !!!
Ben en l'occurence la ta verite m'arrange vachement (au fait c'etait aussi la mienne, mais je t'en laisse la paternite si tu y tiens)
Regarde :
Si le bios lit tout le premier secteur, et si les donnees sont sur ce premier secteur, et si il est obligatoire de hasher le contenu du bios avant de faire le jump vers l'execution de l'init du boot loader => les donnees vont se faire hasher avec la partie non donnees.
Tant que le bios n'est pas capable de s'arreter en cours de chemin lors de la partie lecture du premier secteur (ie tant qu'il n'est pas capable de lire seulement l'exe et de bloquer les donnees), les donnees se feront hasher.
au fait, contrairement à ce que tu avais plusieurs fois affirmé avec véhémence
Ce que j'ai affirme avec vehemence, et que d'ailleurs je maintiens, et que pour que ta theorie se verifie il faudrait un bios qui se comporte vis a vis du disque dur, ou un disque dur qui se comporte vis a vis du bios de facon differente de ce qui existe aujourd'hui. Je le maintiens.
Bien sur que le bios doit etre capable de recevoir et de transmettre des informations a la puce TPM, mais son fonctionnement du point de vue de la machine hors TPM n'a pas bouge d'un iota. Et rien ne laisse penser que ce sera le cas.
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 0.
J'y revient avec ton deuxieme posts en dessous
je maintiens qu'il est marqué en toutes lettres page 9 que le challenger va obtenir la mesure du component1
Alors a part le dessin il est marque en toute lettre
Le challenger demande un extrait du PCR qui contient les mesures du composant1
Le challenger recoit de la plateforme le SML la certif AIK et la valeur du PCR signee par l'AIK
Juste pour savoir elles ont ou les mesures ?
-Le certificat AIK est une clef publique generee a la demande du registar pour prouver la presence d'une puce TPM sur la plateforme, il est independant du materiel autre que la dite puce. La clef privee est generee par la puce et ne sort pas.
- Le SML est le log des hashages materiel, sa presence certifie que le PCR envoye correspond bien au composant demande en on pas a un autre composant. Il est egalement independant du materiel et notamment de la nature du composant.
-Le PCR signe par l'AIK est non seulement crypte par l'AIK, mais il est egalement independant du materiel. Il correspond au "numero" de la boite qui contient le hashage du materiel ainsi que les clefs eventuelleemnt placee la.
Seul le "contenu" du PCR est dependant du materiel, mais lui il n'apparait nul part.
Je m'interresse a TCPA en tant qu'utilisateur nous n'avons ni moi, ni aucune des boites pour lesquelles j'ai travaille, ni la boite pour laquelle je travaille le moindre interet financier ou contractuel envers les technologies TCPA
Kha
# Re: Half life, le jeu à moitié mort-vivant
Posté par Jerome Herman . En réponse au journal Half life, le jeu à moitié mort-vivant. Évalué à 10.
Voici ce que je pense des drivers NVidia sous Windows :
1) Impossible de certifier le triple buffering, si la carte charge elle repasse en double, tant pis pour les effets qui requierent trois buffers
2) Les shadders sont sur 16 ou 32 bits, dommage la norme est a 24 bits en OpenGL et sous Dx9. CX'est en dur sur la carte on ne pourra rien y changer. En 16 bits c'est rapide mais moche et en cas d'accumulation de shaders sur une textures bonjour les erreurs
En 32 bits c'est lent (mais alors beaucoup). De plus la taille du shader permettant surtout de passer a une texture de taille superieure en 16 bits on est en 256x256 (bof) en 24 on est en 2048x2048 ca commence a etre suffisant, en 32 bits on est en plusieurs millionsx plusieurs millions (je vois pas l'interet du tout)
3) Il y a eu des optimisations plus que douteuses sous 3D Mark, notemment le precalcul des surfaces caches pour les parties non interactives de la demo. Comme ca on coupe le Z sorting et on gagne en Bande passante. Ca fait un gros score au 3D mark mais ca ne correspond a rien en terme de perfs dans un environement de jeux standard.
4) Personne n'a encore vu le nouveau driver avec 40 a 50% de gains de perf en plus qui devait sortir cette semaine. Nvidia nous a deja fait ce coup la une fois lors de la guerre de l'anti aliasing, je me mefie beaucoup. Il existe peut-etre mais tant qu'il n'est pas telechargeable et que je n'ai pas pu voir de mes yeux ses perfs et sa qualite je reste sur mes positions
Voila voila
Kha
[^] # 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é à 1.
Actuellement si. Pour pouvoir etre reconnu comme bootable par le bios et pour pouvoir reconnaitre le disque dur (et donc par la suite le lire) l'init du boot loader depend de la config de ce fameux disque. Donc meme si tu stoques des infos sur le disque a cote impossible de les lire si ton init de bootloader n'est pas correct. Impossible de "casser" le boot loader en un init indenpendant du DD et une zone de donnees. Un boot loader qui ne ferait rien d'autre que d'aparaitre comme init de boot loader au yeux du bios avant d'afficher le message "coucou" qu'il lirait sur une zone du mbr apres avoir ete jumpe par le bios serait deja tres dependant du type de disque dur.
page 9 il est expliqué que le challenger va obtenir la mesure du component1 (mesure qui est définie page 8 comme étant le hash du component1)
OOUUUIII je l'attendais celle la, et en plus j'ai volontairement laisse planner la confusion pour voir si tu allais mordre, ca n'a pas loupe. J'imagine que tu fait allusion a la fleche qui part du SML de la plateforme pour aller vers le SML du challenger non ?
Si c'est le cas jette un coup d'oeuil sur ce qu'est le SML et tu comprendras que tu peux dormir sur tes deux oreilles....
Kha
[^] # 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
[^] # 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
[^] # 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é à 1.
Ce n'est pas comme ca que je comprend le doccument Intel, qui parle de certifier un hash mais pas de le stocker, par contre la norme TCPA est tres claire a ce sujet les hashs sont impossibles a faire sortir de la puce.
et qu'est-ce qui empeche un bios spécialement conçu pour TCG (c'est quand meme ce dont parle la news ici) de s'assurer que ce premier exécutable est généré par un programme signé par MS puis de signer (ou mémoriser le hash) de ce premier exécutable après sa génération ? rien
C'est bien pour ca que je suis en rogne figure-toi il y aura un bios phenix qui supportera le Secure Computing (propriete exclusive de MS), aucun rapport avec le Trusted Computing (IBM, INTEL, AMD et MS). Le confusion entre les deux (entretenu par MS il faut bien le dire) m'ennerve.
Le bios peut s'assurer que le loader est conforme a une signature a condition d'avoir une clef. Cette clef devant etre protege contre la copie pour etre efficace. A partir du moment ou il y a une clef protege dans le bios MS n'a plus besoin de la puce TPM, le boulot est deja fait.
mais de toutes façons tout ceci est probablement inutile car il faudra que tu m'expliques où tu as vu que le premier programme ne peut pas ajouter au PCR le hash du 2e programme et ainsi de suite
La norme TCPA indique clairement que la zone de donnee ne doit pas renter en compte dans le hashage, si le bios le fait quand meme il viole la norme. De plus il faut que le bios soit capable de lire le disque. Une fois de plus on en revient a un bios special qui est capable de faire la lecture du contenu du disque pour verification. Il n'a deja plus besoin de la puce TPM a ce moment la.
pas une fois que le bios a donne la main (en stockant son hash) au premier programe: si ce prmeier programme et les suivants ne permettent pas à l'utilisateur de modifier ce hash il sera infalsifiable même par l'utilisateur
Si je me logue en admin TPM et que je boot sur un autre disque rien ne m'empeche de sortir la clef. Une fois de plus il faudrait que le bios (la puce TPM ne peut pas empecher un boot) m'empeche de booter une solution alternative. Si il est capable de faire ca il n'a plus besoin de TPM non plus.
le (I), le (II) et l'existence possible d'une base de hash de chaque élément sont clairement démontrés !
Toujours pas non, et apres il te reste encore a demontrer que c'est possible de le mettre en place ( cf 3 de mon post precedent) et que c'est utilisable (cf 4 ) ....
Bonne chance
Kha
[^] # 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é à 1.
- La puce TPM ne contient pas de systeme de reconaissance de signatures externes, elle ne peut que reconnaitre son propre travail. MS ne peut donc pas "signer" un programme de boot, la puce peut seulement reconnaitre une sequence qu'elle a deja "vu" avant.
- La puce n'exporte pas les hashs elle peut juste mettre une clef prive dans uen boite associe a un PCR. La seule chose qui sortira de la puce est la clef publique associee.
- Les clefs privees sont migrables d'une zone a l'autre par l'admin puce, une clefs lie a un PCR peut odnc etre deplacee vers une zone ouverte a tous.
- La puce hash le premier executable charge par le bios, or celui-ci varie suivant le support, le format du disque, ses partition etc. Il est donc impossible de creer ce programme a priori et de le signer. Il ne peut etre genere qu'a posteriori.
jusque là on est d'accord ? très bien (I)
Meme pas en reve
de (I) et (II) je déduis:
un tiers qui recoit le hash de L signé par ma puce TCG peut avoir la certitude que j'utilises un OS signé par MS avant d'être booté
Quel dommage qu'un tiers ne puisse pas recevoir le hash et que les programmes ne soient pas certifiables a priori mais doivent certifie a posteriori par l'utilisateur (de toute facon la norme TCPA interdit de precharger des clefs donc le probleme est regle).
PS en ce qui concerne le doc de Intel il faut que tu me dises où il est précisé que les mécanismes évoquées ne sont pas utilsables par internet ! (et où il est précisé que cela concerne seulement un usage interne !)
Ils sont bien entendu utilisable sur internet, ce n'est pas cela que je remet en cause, c'est le cote base de donnees unifiee. La puce TPM permet de faire deux choses au niveau des identifications
1) assurer via un registar (interne ou externe) que tu possede bien un TPM.
2) garantir via un repository (interne ou externe) que tu as toujours acces aux clefs qu'il t'a fait generer.
Identifier le materiel sous jaccent au hashage est tout simplement impossible
1) parceque les informations du hashage ne sortent jamais de la puce (elles ne sont pas migrables non plus)
2) parceque les clefs privees genere par TPM et stoquees dans un PCR sont independantes du PCR, et donc les clefs publiques (seules a sortir du TPM hors methode de migration) aussi.
3) parceque TPM ayant pour but d'identifier precisement une machine par rapport a une autre meme du meme modele possede des systemes de mesures extremenent pointus qui vont probablement faire correspondre des hashages differents a des produits d'apparence rigoureusement identique pour l'homme.
4) Meme si le hashage etait identique pour deux composants configures de la meme facon sur deux machines avec deux TPMs differents et que le hashage etait visible il faudrait une base de donnees monstrueuse pour le gerer. Exemple pour l'init du boot qui te plait tant, il existe
(Modeles disque dur)x(Formatages bas niveau possibles sur le disque dur)x(Geometries physiques possible compte tenu du formatage bas niveau)x(partitionnements possibles)x(position de l'OS loader sur le disque)x(type du boot loader)x(configuration du boot loader)x(type de l'OS loader) possibilites (et je pense que j'en oublie).
Kha
[^] # Re: chain of trust !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
La chaine of trust ne peut etre poursuivi que logiciellement, vu que la puce ne peut pas stoquer ces informations la. On retombe donc sur une banale securite logicielle. Oui c'est faisable, non c'est pas incassable. De plus toutes les clefs accessibles par l'exterieur de la puce TPM sont migrables. Bonne chance donc pour avoir une assurance quelconque.
si MS fait un bootloader qui n'accepte de booter qu'un windows signé par MS (le bootlaoder vérifie avec une clé publique de MS que les exécutables sont signés par la clé privée de MS)
Bien sur qu'ils peuvent faire ca mais ils seront oblige de le faire en logiciel, la puce TPM n'apportera rien.
la présence du hash de ce bootloader dans les infos PCR signées par TCG sera la preuve infalsifiable (à cause de la signature du TPM) qu'on a un windows signé par MS
La presence (ou l'absence) d'un hash particulier dans une puce TPM est impossibel a dectecter. Tout ce que l'on peut faire c'est de challenger une clef qui se trouve normalement protege dans une zone dependante de ce hash. Mais si l'admin migre la clef tout se barre. Le challenger aura acces a la clef mais il n'aura aucun moyen de savoir si elle depend encore d'un hash PCR ou non.
voir le document Intel spring2003 pour les modalités
Tu gagne 1$ a chaque fois que tu cites ce doc c'est pas possible. Relit le tu verras qu'il parle d'une methode au sein d'une entreprise avec un admin qui remplit le repository lui meme pour l'usage exclusif de sa boite. Pas de plan mondial de recuperation de tous les hash de tous les PCR de la planete (ce qui tombe bien parcequ'ils ne sont pas recuperable de toute facon...)
Kha
[^] # Re: chain of trust !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Ta definition est amusante, quel domage qu'elle soit fausse. Pour ton information voici comment marche la chaine of trust :
Les clefs abritee par la puce TPM (TCG etant le nom du groupe une fois de plus) sont enfermes dans des boites gigognes. Pour que TPM accepte de libere une clef il faut qu'un certains nombre de conditions soient verifiees par les hashs PCR.
Ces conditions peuvent etre nulles (clef accessible a tous) ou demander que l'utilisateur soit le bon, ou demander que l'utilisateur, le bios, les periphs PCI, et le MBR soit les bons. Cette liste de conditions a remplir forment la chaine of trust. A savoir que tu peux faire confiance a la puce qui fait confiance au bios qui fait confiance au MBR.
Il n'y a pas d'executables ecrits "specialement" pour le systeme TCPA. Le bios doit bien sur pouvoir repondre aux demandes de la puce (sans quoi toutes les coffres qui contiennent des clefs necessitant un PCR dependant du bios restent fermees) mais ca s'arrette la. Une fois de plus la puce TPM ne peut pas et ne doit pas hasher les zones de donnees. Les seules informations qu'elle aura sur le disque seront sur le MBR. Ensuite uen fois les informations sur le MBR recoltee elle aura fini son hashage des composants. L'ensemble du PCR sera fixe et tout ce qui arrive apres ne la concerne pas. Meme si le boot loader etait certifie par un tiers et pouvait identifier l'OS il ne pourrait pas stocker l'information dans la puce (qui n'a pas d'emplacement PCR pour stoquer cette information), mais en plus ca n'est pas le cas.
tout ceci est amplement confirmé par le document Intel du printemps 2003 que j'ai cité ci-dessus, dicument qui précise que chaque hash qui compose le PCR (ciomponent) est obtensible séparément et avec une signature assurant un tiers qu'il n'a pas été truqué par l'utilisateur (on voit bien que l'unique fonction de TCG par rapport à des softs libres équivalents est de se méfier de l'utilisateur pour faire plaisir à un tiers !)
Oui c'est l'idee meme de la crypto non ? Chercher a verifier que la personne avec qui je dialogue est bien qui elle pretend etre. Pour finir les hashs ne sont pas obtensible separement, par contre tu peux faire une chaine of trust de longueur 1 qui ne hash qu'un seul peripherique. Par exemple tu creer une boite a clef tout utilisateur sur le PCR qui a hashe le periph PCI1 et tu demandes a TPM de te creer une clef privee dans cette boite.Ensuite tu demande la clef publique et tu la stoque dans ton repositary. Derriere si tu veux savoir si le periph PCI1 est bien identique a celui que tu connais et auquel tu fais confiance tu vas chercher la clef publique dans ton repositary et par un challenge reponse tu verifie que la clef privee et bien dans le TPM avec qui tu dialogue et qu'elle est disponible (ie que la chaine of trust de PCI1 est respectee).
Mais comme la clef privee cree par le TPM n'a aucun rapport avec le composants sur PC1 impossible de faire marche arriere et de deduire le composant de la clef privee. A plus forte raison de la clef publique.
Les parties hashages du PCR (checksums ) sont en zone dite interne de la puce. Impossible donc de les faire sortir ou de les migrer.
bref, TCG n'apporte aux utilsiateurs d'OS libres qu'une seule chose: pourvoir se faire identifier à distance par des tiers comme n'étant pas utilisateurs d'un OS DRM non modifiable !
Ben en tant qu'heureux possesseur d'une puce TPM et utilisateur de logiciel libre je te dis bien fort non. Ca apporte pleins de choses. Et comme en plus l'identification d'un OS DRM par TPM est inpossible a moins bien sur qu'il ne tienne integralement sur le MBR (bonne chance) et qu'une clef d'identification ai ete prechargee dans le PCR assiocie a cette sequence de boot (ce qui est interdit par la norme).
(et en + un OS DRM pourra facilement stocker des stockée des données non acessibles aux autres OS, autres OS qui devront par ailleurs booter sur CD car l'utilisation d'un lilo/grub entrainerait une rupture de la chain of trust)
Toutes les donnees accessibles ou challengables par l'exterieur sont migrables (et heureusement d'ailleurs pour des raisons de maintenance). L'admin de la puce peut donc sortir n'importe quelle clef de n'importe quel coffre et la placer dans un autre, par exemple celui daont la chaine of trust passe par lilo/grub ou le boot sur le cd de la knoppix.
REFUSONS TOUS les softs et hards TCG avant qu'il ne soit trop tard !
Oui si vous voyez un soft TCG refusez le ! Il n'existe pas, le vendeur est en train de vous arnaquer, la puce TPM ne peut pas hasher les zones de donnees.
où il est précisé qu'il faut créer un système mondial ("eco-system") de tous les hashs de tous les composants certifiés TCG (soft et hard) d'un ordinateur !
Comme quoi on peut avoir un DEA avec mention tres bien et ne pas savoir ce qu'est un ecco-systeme.
Kha
[^] # 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
[^] # 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é à 0.
Ca ne sert a rien de discuter avec une personne qui ne sait pas de quoi elle parle du tout et qui repette plusieurs fois exactement le meme argument. Tu trouvera la reposne a cette affirmation grotesque un peu plus haut.
Doccument toi sur le processus de boot sans TCPA, notamment les phases d'initialisation du boot loader, la relache des interrupts par le bios et le passage en mode protege.
Desole
Kha
[^] # 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.
Ben non hashage plus+nombre aleatoire + algo -> clef privee (qui ne sort pas de la puce TCPA sauf migration declenchee physiquement a la main par l'admin)
clef privee + aleatoire + algo -> clef publique (la seule qui sort).
C'est tout a fait classique le "dans uen certaine mesure" ne sert qu'a dire qu'il n'y a rien de trivial a repasser de la clef publique au checksum
ah bon ? et pourquoi ?
Parceque si il etait facile de faire un emulateur de puce TCPA sur un PC sans puce, alors la puce TCPA n'aurait strictement aucun interet (et meme s'en servir serait dangereux).
Ca c'est pour la raison logique.
Emuler uen puce via un logiciel est souvent long, la plupart des processeurs et des puces sont emules avec des facteurs de 100 voir de 1000 en ralentissement. De plus le comportement d'un emulateur n'est jamais rigoureusement identique surtout en ce qui concerne par exemple la generation de nombres pseudo-aleatoires, et comme c'est une des capacites primordiales de la puce...
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.
Ouais ! alors voila comment ca marche :
Le bios il s'initialise et au bout d'un moment il se sent seul, alors ils regarde a des endroits bien definis des fois qu'il y aurait pas un petit bout de code qui lui permette de repasser le bebe a quelqu'un d'autre.
Ce bout de code est charge par le bios, il donne le tout debut de l'init de la phase de boot de l'OS. A savoir 1) la position du loader 2) son point d'execution. Tres efficace pour savoir si on a touche au disque dur depuis la derniere fois, totalement inutile si on veut connaitre l'OS qui va etre lance. Je peux parfaitement reprendre exactement l'init boot loader de Windows2003 et le faire pointer sur un autre boot loader. Comme je ne suis pas encore passe en mode protege c'est la fete. Au moment du passage en mode protege le Bios est OUT, le Bios ne peut qu'ouvrir la porte au mode protege, de la il suffit que la premiere instruction quand le bios a tourne le dos soit "fausse alerte, on boot comme ca finalement" pour que la puce TCPA n'y voit que du feu au niveau de l'OS (par contre elle pourra se rendre compte qu'il y a eu des changement sur le disque).
Kha