Une grosse partie de mon argumentation vient du fait qu'un hash de MBR ne peut pas etre connu a l'avance
une grosse partie de ton argumentation est donc fausse
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
En plus pas de trace de hash signe qui circule et qui est verifie ...
c'est limpidement faux et je pense de + en + que tu y mets beaucoup de mauvaise volonté:
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)
je crois que ces pages 8 et 9 du document intel printemps 2003 suffisent à prouver que la seule utilité de TCG est l'identification à distance des composants de ma plate-forme (OS + matériel, car c'est la seule définition de TCG) par un tiers !
sur le plan économique je préfère la solution cryptage + système d'alarme pour détecter les tentatives d'accès à la pièce de l'ordinateur quand tu n'es pas là
cette solution est pas chère et efficace: en cas d'intrusion, même si le voleur s'empare du disque dur ou en copie les données, tu es prévenu et tu peux passer la pièce et l'ordi au peigne fin pour t'assurer que des mouchards n'ont pas été déposés (tu peux même changer d'ordi au besoin)
Pour éviter des fraudes genre "fausses autorisations de prélèvement" (pas très graves car la banque doit te rembourser si y'a pas ta signature), il vaut peut-être mieux ne donner ce RIB que aux personnes qui en font la demande par email
Notamment afin d'éviter que ce RIB ne soit référencé par des moteurs (ce qui faciliterait la tache d'éventuels faussaires spécialisés) il vaut peut-être mieux éviter de le diffuser par http
D'ailleurs avec un moteur, je remarque que de nombreux sites diffusent deja des RIBs pour leur paiements, on pourrait leur demander si ils ont eu des problèmes avec cela
De toutes façons étant donné un numéro de compte et une banque (informations qui figurent sur tous les chèques), il n'est pas très dur de reconstituer le RIB (il n'y a que 100 clés à 2 chiffres possibles, rapidement essayables sur le site d'une banque)
peux-tu garantir qu'un tiers (cambrioleur ou imposteur ou traitre ou...) n'aura jamais accès physiquement aux données de ton disque dur ?
je ne crois pas ...
J'ajoutes que il est très difficile, voir impossible, de prouver qu'une puce ne contient pas de bug (cf les bugs de nombreuses puces déjà sorties dont les Pentiums d'Intel, le noyau Linux essaye d'ailleurs d'identifier lors du boot les bugs connus des puces qu'utilise ton ordinateur pour les contourner)
Il me sera d'ailleurs très dur de vérifier que la puce TCG de mon ordinateur ne contient pas des fonctions spéciales non documentées (backdoors) qui pourraient compromettre les clés privées que j'y stocke !
Par conséquent un micro-noyau comme hurd (ou celui de RTlinux dont chaque ligne de source a été soigneusement étudiées pour s'assurer de l'absence de bug qui pourrait fausser les temsp de réponse) peut s'avérer aussi sûr qu'une puce TCG. Et même + car il pourra facilement être controlé par tous et être mis à jour en cas de nouvelle faille.
On en revient au débat sécurité par obscurité ou sécurité par examen et amélioration du code source
J'ai choisi mon camp: c'est celui de l'open source
surtout que plusieurs sites web de banques proposent de faire des virement gratuitement vers un autre compte en France, donc pas de frais comme avec les CB
(et chaque virement peut être accompagné d'un message le justifiant)
en fait il suffit simplement de publier le RIB du compte qui reçoit les dons pour linuxfr !
fournir le hash d'un bootloader est largement suffisant pour savoir de quel bootloader il s'agit !
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é !)
A l'heure actuelle le bios ne fait que charger le premier bootloader qui lui passe sous la main avant de l'executer non car tous les bios sont paramétrables pour choisir quel périphérique sera utilisé pour booter
et j'ai déjà répindu qu'en cas de mbr non connu, tu pourras toujours booter un OS mais tu ne pourras plus montrer patte blanche (hash du mbr connu) aux fournisseurs de contenus
Cela n'est valable que si le hash signe est en fait une clef publique challengeable
n'importe quoi
je répète la phrase ci-dessus qui est évidente:
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é !)
La norme dit que c'est interdit et la relation hashage->bootloader est non triviale. non pour la norme, cf document intel , et relis ma phrase répétée ci-dessus pour le hash (le document intel est d'ailleurs entrièrement basé autour de bases de données contenant des hashes à reconnaitre, tu refuses de voir ce qui ne t'arrange pas !)
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 !
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.
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 !
Le bios peut s'assurer que le loader est conforme a une signature a condition d'avoir une clef
fournir le hash d'un bootloader est largement suffisant pour savoir de quel bootloader il s'agit !
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
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)
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
La norme TCPA indique clairement que la zone de donnee ne doit pas renter en compte dans le hashage,
je n'ai jamais parlé d'une zonne de donnée mais bien du hash d'un exécutable !
la norme TCPA précise exactement au même endroit que tout exécutable lancé par le bios doit être hashé et ce hash stocké dans PCR, sans hasher les zones de données qui sont suceptibles de contenir des octets variables (et qui feraient varier le hash le rendant difficile à reconnaitre)
Secure Computing
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
Si je me logue en admin TPM et que je boot sur un autre disque rien ne m'empeche de sortir la clef.
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
PS je trouves que tu as nettement + d'idées quand il s'agit de t'attaquer au Secure Computing que à TCG !
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é ?
Dès qu'un système est très complexe il devient impossible de démontrer qu'il n'a pas de failles et il n'est donc pas inutile d'en chercher comme je le fais. Je pense avoir trouvé d'ailleurs , et je pense plutot que cette "faille" d'attestation est voulue vu l'argent qui est en jeu dans ces histoires de DRM !
- La puce TPM ne contient pas de systeme de reconaissance de signatures externes,
je n'ai jamais dit ça et ma démonstration ne repose absolument pas sur cela, relis-là
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.
ce n'est pas du tout ce qu'il ressort du document Intel déjà cité !
- 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.
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
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
- 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.
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
le (I), le (II) et l'existence possible d'une base de hash de chaque élément sont clairement démontrés !
quand je rencontre en personne des gens, rien ne m'empeche de leur donner un petit CD/DVD sur lequel j'ai stocké d'énormes clés OTP
en compressant bien les messages textes que j'échange avec ces personnes, je peux communiquer avec eux pendant des années et plusieurs fois par jour en ajoutant une couche OTP (histoire de compliquer l'analyse de mon générateur aléatoire, et d'éviter les attaques par répétition/délétions/knownCleartext) à une couche de crypto classique
si mon générateur aléatoire n'est pas trop pourri (y'a des cartes PCI sinon), même les ordinateurs quantiques auront beaucoup de mal à décrypter tout ça (démonstration mathématique oblige)
si en + j'échange un HDD de 100 gigas avec un ami que je vois en personne toutes les semaines (ou tous les mois c'est selon), alors l'échange permanent sécurisé et en temps réel de fichiers multimédias avec cet ami n'est pas un problème non plus
(aucun problème pour se téléphoner en toute sécurité par exemple)
tout ceci est bien sûr valable pour du business et DEVRAIT être utilisé par toutes les entreprises pour leur communications passant par des réseaux extérieurs !
je le conseille aussi à ceux qui luttent contre la corruption des puissants (car dans la constitution française, comme dans d'autres, la justice/parquet/CSM dépend fortement des dirigeants politiques et de leurs amis)
il est clairement écrit dans les docs officiels TCPA que les hash du bios et du premier logiciel lancé par le bios (appelons le le logiciel L) doivent être stockés dans le PCR
donc un tiers peut savoir si mon bios est connu et non modifié et si mon logiciel L est connu et non modifié (et si ce logiciel L est connu pour être signé par MS pour garantir qu'il provient bien de MS, alors le tiers peut aussi le savoir)
jusque là on est d'accord ? très bien (I)
maintenant je vais définir la formule F suivante:
"soit A un logiciel dont on sait qu'il est signé par MS avant d'être lancé, si ce logiciel vérifie que le logiciel B auquel il donne la main est signé par MS (sinon il plante ou reboot) alors on sait que le logiciel B est signé par MS avant d'être lancé"
la formule F est évidemment vraie, tu en conviendras.(II)
maintenant je ne fais qu'appliquer la formule F:
si L est un logiciel conçu pour s'assurer que le logiciel L2 auquel il donne ensuite la main est signé par MS (sinon il reboote la machine), même conception pour L2, et ainsi de suite pour L3, L4 jusqu'à ce que le noyau et les processus root du système aient la main
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é
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 !)
Trouve moi un mechanisme qui garentie qu'une clée est inaccessible en soft ?
si tu as un OS très sécurisé (micronoyau à la Hurd ou bien encore les softs SElinux/systrace/LSM/UML/plex86 pour Linux) il sera très difficile d'accéder à une clé protégée (on peut par exemple interdire à tout le monde, y compris root, d'y accéder directement)
si tu es parano tu peux aussi faire que cette clé n'est utilisée qu'une seule fois au début du boot pour décrypter une partition très sensible (qui peut elle meme contenir des clés de cryptage secondaires) puis effacée de la mémoire avant de lancer effectivement le boot du système (dont tu auras aussi controlé l'intégrité des fichiers essentiels grace à tripwire)
tout ceci est très facile avec un CD-R de boot, une disquette read-only, une clé USB que tu retire avant de booter définitivement l'OS, etc.
par contre si ton OS est une passoire, et que on peut facilement accéder ou modifier (temporairement) les composants de base du système après le boot, alors même si un intrus ne peux pas accéder directement à la clé stockée par TCG, l'intrus peux quand même l'utiliser, y compris à l'insu du propriétaire du système et pendant une longue période (plusieurs mois ou années)
de + comme le système de cryptage de TCG est fixé une fois pour toutes (et n'est pas vraiment ce qui se fait de mieux en matière de crypto) l'intrus, s'il est puissant ou bien informé, peux aussi casser les clés de taille fixe que ce système emploie
encore une fois le seul intéret de TCG est bien pour un tiers de s'assurer ("attestation") du matériel et de l'OS que j'utilise
toutes les fonctions de TCG sont faisables en mieux avec des softs libres sauf une:
l'identification infalsifiable de ma plateforme (matériel et OS) à distance vis à vis d'un tiers
sa fonction de base pour ammorcer la chaine de confience c'est de verifier l'ammorcage du systeme, soit le Bios et ses composants tiers, puis le bootloader apres si la chaine doit se poursuivre c'est au bootloader et a l'OS de la continuer pas a TCPA.
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:
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)
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
voir le document Intel spring2003 pour les modalités
je crois que tu n'as pas vu que tout le document consiste à pouvoir "attester" (attestation) des composants d'une plate-forme.
"Platform", dans tous les documents TCG, désigne l'ensemble d'un ordinateur, OS + hardware dont le hard tcg, , tu peux consulter sans NDA d'anciennes versions de ces docs sur le site officiel TCG
on voit notamment page 7 que le registrar est externe à la plateforme
page 9 que le challenger (celui qui veut connaitre les composants de la palteforme) est externe à la plateforme
les protocoles cryptographiques utilisés (notamment par signature) font que toutes ces opérations peuvent être faites de manière fiables par internet
page 12 il est précisé que la base de données des hash est destinée au challenger (le fournisseur de services) et non au possesseur de la plateforme (moi)
page 26 on vient bien que le registrar et le challenger sont bien des entités distinctes entre elles et distinctes de la plateforme
évidemment si je me place dans la peau d'un fournisseur de services DRM, je serais particulièrement content de cet état de fait qui me permet de savoir sans falsification possible quel est l'OS et le matériel du client auquel j'envoie un contenu.
par contre pour un usage interne à une entreprise, je peux tout à fait utiliser des logiciels libres pour obtenir une fiabilité supérieure aux algos de cryptage non extensibles utilisés par TCG !
étant donné qu'aucun OS n'est démontré mathématiquement inviolable, tout utilisateur de p2p peut dire que son ordinateur a été utilisé contre sa volonté par quelqu'un d'autre, en cas de procès
par contre quelqu'un qui avoue avoir installé Freenet tout en sachant que cela peut faciliter l'utilisation anonyme de son ordinateur par des gens qui ne respectent la loi, peut être accusé de complicité... (en France tout hébergeur de contenu doit pouvoir donner l'identité des auteurs des documents qu'il héberge)
donc pour te défendre il vaut mieux que tu précises que c'est un intrus qui a installé Freenet sur ton ordi, et pas toi
qu'est-ce que TCPA permet de faire qu'on ne pourrait pas déjà faire actuellement pour limiter l'interopérabilité ?
dans la situation actuelle, quand un fournisseur de contenus communique avec l'OS d'un particulier, il n'a aucun moyen de savoir avec certitude que cet OS enforce le DRM et n'a pas été modifié par l'utilsiateur pour faciliter un contournement de DRM.
avec du matos TCG et des OS TCG, le fournisseur aura la garantie que l'OS booté est bien un OS DRM non modifié, car la puce TCG stocke au moment du boot un hash du premier programme booté par le bios TCG, premier programme (et progarammes suivants) qui vont eux-meme ajouter dans la puce TCG des hash des différents composants de l'OS.
à la demande du fournisseur ces hash seront ensuite fournis et signés par la puce TCG comme étant authentiques
en effet le "coffre fort" contient essentiellement des clés privées de type RSA 1024 bits qui n'ont rien qui prouve qu'elles sont incassables (AES et d'autres algos similaires sont aujourd'hui considérés comme plus fiables que RSA, et la taille limitée par le hardware des clés est un désavantage majeur de TCG par rapport à la souplesse des logiciels libres !)
C'est avec ces clés RSA que seront crypté sur le disque dur les données "protégées" par RSA
Je préfère de loin utiliser des algos + récents dispos sous forme de softs libres pour crypter des donénes sur mon disque dur !
la démonstration que OTP est incassable est vraiment très simple (il suffit de simuler un cryptage OTP à la main pour comprendre que ajouter modulo 255 un octet aléatoire jetable à un octet "en clair" donne en résultat un octet aléatoire donc complètement inutilisable par un ennemi; il faudrait réutiliser plusieurs fois ce même octet clé pour arriver à le déterminer, mais OTP signifie bien que chaque octet clé est utilisé une seule fois)
Tu trouves cette démo facilement sur le net, tu peux donc la lire !
Tu trouveras aussi sur le net la démo qui garantit que OTP est le seul algo incassable par une puissance dez calcul illimitée. Cette démo est un peu plus longue (mais compréhensible avec des maths de niveau bac science +1)
je crois que tu n'as toujours pas compris la notion de chain of trust lors du boot:
TCG ajoute dans le PCR un hash du bios écrit spécialement pour tcg, qui ajoute ensuite dans le PCR un hash du premier exécutable de boot écrit spécialement pour TCG (l'exécutable uniquement, pas ses données, cela est précisé dans les docs "chain of trust" officiels), qui ajoute un hash du 2e exécutable écrit spécialement pour TCG, qui ajoute... etc. jusqu'à ce que l'OS compatible TCG ait pris les choses en main hashing is employed to extend trust from the BIOS to other areas of the platform
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 !)
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 !
(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)
REFUSONS TOUS les softs et hards TCG avant qu'il ne soit trop tard !
cf http://www.intel.com/idf/us/spr2003/presentations/S03USSFCS69_OS.pd(...)
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 !
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
une grosse partie de ton argumentation est donc fausse
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
En plus pas de trace de hash signe qui circule et qui est verifie ...
c'est limpidement faux et je pense de + en + que tu y mets beaucoup de mauvaise volonté:
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)
je crois que ces pages 8 et 9 du document intel printemps 2003 suffisent à prouver que la seule utilité de TCG est l'identification à distance des composants de ma plate-forme (OS + matériel, car c'est la seule définition de TCG) par un tiers !
[^] # soltion efficace et peu chère
Posté par free2.org . En réponse au sondage La crypto c'est sympa pour chiffrer. Évalué à 1.
cette solution est pas chère et efficace: en cas d'intrusion, même si le voleur s'empare du disque dur ou en copie les données, tu es prévenu et tu peux passer la pièce et l'ordi au peigne fin pour t'assurer que des mouchards n'ont pas été déposés (tu peux même changer d'ordi au besoin)
[^] # Re: RIB du compte pour les dons linuxfr
Posté par free2.org . En réponse à la dépêche Information du dedans. Évalué à 2.
Notamment afin d'éviter que ce RIB ne soit référencé par des moteurs (ce qui faciliterait la tache d'éventuels faussaires spécialisés) il vaut peut-être mieux éviter de le diffuser par http
D'ailleurs avec un moteur, je remarque que de nombreux sites diffusent deja des RIBs pour leur paiements, on pourrait leur demander si ils ont eu des problèmes avec cela
De toutes façons étant donné un numéro de compte et une banque (informations qui figurent sur tous les chèques), il n'est pas très dur de reconstituer le RIB (il n'y a que 100 clés à 2 chiffres possibles, rapidement essayables sur le site d'une banque)
[^] # La crypto c'est sympa pour les FS !
Posté par free2.org . En réponse au sondage La crypto c'est sympa pour chiffrer. Évalué à 1.
je ne crois pas ...
[^] # sécurité par l'obscurité d'une puce illusoire et dangereuse
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Il me sera d'ailleurs très dur de vérifier que la puce TCG de mon ordinateur ne contient pas des fonctions spéciales non documentées (backdoors) qui pourraient compromettre les clés privées que j'y stocke !
Par conséquent un micro-noyau comme hurd (ou celui de RTlinux dont chaque ligne de source a été soigneusement étudiées pour s'assurer de l'absence de bug qui pourrait fausser les temsp de réponse) peut s'avérer aussi sûr qu'une puce TCG. Et même + car il pourra facilement être controlé par tous et être mis à jour en cas de nouvelle faille.
On en revient au débat sécurité par obscurité ou sécurité par examen et amélioration du code source
J'ai choisi mon camp: c'est celui de l'open source
[^] # RIB du compte pour les dons linuxfr
Posté par free2.org . En réponse à la dépêche Information du dedans. Évalué à 4.
(et chaque virement peut être accompagné d'un message le justifiant)
en fait il suffit simplement de publier le RIB du compte qui reçoit les dons pour linuxfr !
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
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é !)
A l'heure actuelle le bios ne fait que charger le premier bootloader qui lui passe sous la main avant de l'executer
non car tous les bios sont paramétrables pour choisir quel périphérique sera utilisé pour booter
et j'ai déjà répindu qu'en cas de mbr non connu, tu pourras toujours booter un OS mais tu ne pourras plus montrer patte blanche (hash du mbr connu) aux fournisseurs de contenus
Cela n'est valable que si le hash signe est en fait une clef publique challengeable
n'importe quoi
je répète la phrase ci-dessus qui est évidente:
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é !)
La norme dit que c'est interdit et la relation hashage->bootloader est non triviale.
non pour la norme, cf document intel , et relis ma phrase répétée ci-dessus pour le hash (le document intel est d'ailleurs entrièrement basé autour de bases de données contenant des hashes à reconnaitre, tu refuses de voir ce qui ne t'arrange pas !)
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 !
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
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 !
Le bios peut s'assurer que le loader est conforme a une signature a condition d'avoir une clef
fournir le hash d'un bootloader est largement suffisant pour savoir de quel bootloader il s'agit !
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
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)
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
La norme TCPA indique clairement que la zone de donnee ne doit pas renter en compte dans le hashage,
je n'ai jamais parlé d'une zonne de donnée mais bien du hash d'un exécutable !
la norme TCPA précise exactement au même endroit que tout exécutable lancé par le bios doit être hashé et ce hash stocké dans PCR, sans hasher les zones de données qui sont suceptibles de contenir des octets variables (et qui feraient varier le hash le rendant difficile à reconnaitre)
Secure Computing
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
Si je me logue en admin TPM et que je boot sur un autre disque rien ne m'empeche de sortir la clef.
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
PS je trouves que tu as nettement + d'idées quand il s'agit de t'attaquer au Secure Computing que à TCG !
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é ?
Dès qu'un système est très complexe il devient impossible de démontrer qu'il n'a pas de failles et il n'est donc pas inutile d'en chercher comme je le fais. Je pense avoir trouvé d'ailleurs , et je pense plutot que cette "faille" d'attestation est voulue vu l'argent qui est en jeu dans ces histoires de DRM !
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
je n'ai jamais dit ça et ma démonstration ne repose absolument pas sur cela, relis-là
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.
ce n'est pas du tout ce qu'il ressort du document Intel déjà cité !
- 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.
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
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
- 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.
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
le (I), le (II) et l'existence possible d'une base de hash de chaque élément sont clairement démontrés !
[^] # OTP est praticable par tous, voici comment
Posté par free2.org . En réponse au sondage La crypto c'est sympa pour chiffrer. Évalué à 1.
en compressant bien les messages textes que j'échange avec ces personnes, je peux communiquer avec eux pendant des années et plusieurs fois par jour en ajoutant une couche OTP (histoire de compliquer l'analyse de mon générateur aléatoire, et d'éviter les attaques par répétition/délétions/knownCleartext) à une couche de crypto classique
si mon générateur aléatoire n'est pas trop pourri (y'a des cartes PCI sinon), même les ordinateurs quantiques auront beaucoup de mal à décrypter tout ça (démonstration mathématique oblige)
si en + j'échange un HDD de 100 gigas avec un ami que je vois en personne toutes les semaines (ou tous les mois c'est selon), alors l'échange permanent sécurisé et en temps réel de fichiers multimédias avec cet ami n'est pas un problème non plus
(aucun problème pour se téléphoner en toute sécurité par exemple)
tout ceci est bien sûr valable pour du business et DEVRAIT être utilisé par toutes les entreprises pour leur communications passant par des réseaux extérieurs !
je le conseille aussi à ceux qui luttent contre la corruption des puissants (car dans la constitution française, comme dans d'autres, la justice/parquet/CSM dépend fortement des dirigeants politiques et de leurs amis)
[^] # démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
donc un tiers peut savoir si mon bios est connu et non modifié et si mon logiciel L est connu et non modifié (et si ce logiciel L est connu pour être signé par MS pour garantir qu'il provient bien de MS, alors le tiers peut aussi le savoir)
jusque là on est d'accord ? très bien (I)
maintenant je vais définir la formule F suivante:
"soit A un logiciel dont on sait qu'il est signé par MS avant d'être lancé, si ce logiciel vérifie que le logiciel B auquel il donne la main est signé par MS (sinon il plante ou reboot) alors on sait que le logiciel B est signé par MS avant d'être lancé"
la formule F est évidemment vraie, tu en conviendras.(II)
maintenant je ne fais qu'appliquer la formule F:
si L est un logiciel conçu pour s'assurer que le logiciel L2 auquel il donne ensuite la main est signé par MS (sinon il reboote la machine), même conception pour L2, et ainsi de suite pour L3, L4 jusqu'à ce que le noyau et les processus root du système aient la main
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é
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 !)
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
si tu as un OS très sécurisé (micronoyau à la Hurd ou bien encore les softs SElinux/systrace/LSM/UML/plex86 pour Linux) il sera très difficile d'accéder à une clé protégée (on peut par exemple interdire à tout le monde, y compris root, d'y accéder directement)
si tu es parano tu peux aussi faire que cette clé n'est utilisée qu'une seule fois au début du boot pour décrypter une partition très sensible (qui peut elle meme contenir des clés de cryptage secondaires) puis effacée de la mémoire avant de lancer effectivement le boot du système (dont tu auras aussi controlé l'intégrité des fichiers essentiels grace à tripwire)
tout ceci est très facile avec un CD-R de boot, une disquette read-only, une clé USB que tu retire avant de booter définitivement l'OS, etc.
par contre si ton OS est une passoire, et que on peut facilement accéder ou modifier (temporairement) les composants de base du système après le boot, alors même si un intrus ne peux pas accéder directement à la clé stockée par TCG, l'intrus peux quand même l'utiliser, y compris à l'insu du propriétaire du système et pendant une longue période (plusieurs mois ou années)
de + comme le système de cryptage de TCG est fixé une fois pour toutes (et n'est pas vraiment ce qui se fait de mieux en matière de crypto) l'intrus, s'il est puissant ou bien informé, peux aussi casser les clés de taille fixe que ce système emploie
encore une fois le seul intéret de TCG est bien pour un tiers de s'assurer ("attestation") du matériel et de l'OS que j'utilise
[^] # Re: chain of trust !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
https://linuxfr.org/comments/281198.html(...)
toutes les fonctions de TCG sont faisables en mieux avec des softs libres sauf une:
l'identification infalsifiable de ma plateforme (matériel et OS) à distance vis à vis d'un tiers
je refuse donc TCG !
[^] # les dangers de la chain of trust expliqués
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
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:
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)
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
voir le document Intel spring2003 pour les modalités
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
un module logiciel est facilement modifiable/falsifiable/émulable lorsque tu communiques à distance avec avec un tiers
pas une puce TCG qui contient une clé privée unique cachée dans ses circuits et dont elle se sert pour signer les informations qu'elle certifie
[^] # Re: TCPA/TCG n'empeche pas linux mais peut le marginaliser
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
pas une puce TCG qui contient une clé privée unique dont elle se sert pour signer les informations qu'elle certifie
[^] # attestation que ma platform = mon PC+monOS est non modifié
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 3.
"Platform", dans tous les documents TCG, désigne l'ensemble d'un ordinateur, OS + hardware dont le hard tcg, , tu peux consulter sans NDA d'anciennes versions de ces docs sur le site officiel TCG
on voit notamment page 7 que le registrar est externe à la plateforme
page 9 que le challenger (celui qui veut connaitre les composants de la palteforme) est externe à la plateforme
les protocoles cryptographiques utilisés (notamment par signature) font que toutes ces opérations peuvent être faites de manière fiables par internet
page 12 il est précisé que la base de données des hash est destinée au challenger (le fournisseur de services) et non au possesseur de la plateforme (moi)
page 26 on vient bien que le registrar et le challenger sont bien des entités distinctes entre elles et distinctes de la plateforme
évidemment si je me place dans la peau d'un fournisseur de services DRM, je serais particulièrement content de cet état de fait qui me permet de savoir sans falsification possible quel est l'OS et le matériel du client auquel j'envoie un contenu.
par contre pour un usage interne à une entreprise, je peux tout à fait utiliser des logiciels libres pour obtenir une fiabilité supérieure aux algos de cryptage non extensibles utilisés par TCG !
[^] # au contraire, Freenet peut favoriser la notion de complicité !
Posté par free2.org . En réponse à la dépêche Faiblesse des protocoles P2P. Évalué à 2.
par contre quelqu'un qui avoue avoir installé Freenet tout en sachant que cela peut faciliter l'utilisation anonyme de son ordinateur par des gens qui ne respectent la loi, peut être accusé de complicité... (en France tout hébergeur de contenu doit pouvoir donner l'identité des auteurs des documents qu'il héberge)
donc pour te défendre il vaut mieux que tu précises que c'est un intrus qui a installé Freenet sur ton ordi, et pas toi
[^] # Re: TCPA/TCG n'empeche pas linux mais peut le marginaliser
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
https://linuxfr.org/comments/280994.html(...)
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
https://linuxfr.org/comments/280994.html(...)
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
dans la situation actuelle, quand un fournisseur de contenus communique avec l'OS d'un particulier, il n'a aucun moyen de savoir avec certitude que cet OS enforce le DRM et n'a pas été modifié par l'utilsiateur pour faciliter un contournement de DRM.
avec du matos TCG et des OS TCG, le fournisseur aura la garantie que l'OS booté est bien un OS DRM non modifié, car la puce TCG stocke au moment du boot un hash du premier programme booté par le bios TCG, premier programme (et progarammes suivants) qui vont eux-meme ajouter dans la puce TCG des hash des différents composants de l'OS.
à la demande du fournisseur ces hash seront ensuite fournis et signés par la puce TCG comme étant authentiques
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.
C'est avec ces clés RSA que seront crypté sur le disque dur les données "protégées" par RSA
Je préfère de loin utiliser des algos + récents dispos sous forme de softs libres pour crypter des donénes sur mon disque dur !
[^] # Re: PREUVE IRREFUTABLE: document Intel entièrement consacré à l'identification à distance via TCG !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
non fait un find sur "eco-system" dans le pdf
identification à distance par un tiers de chacun des composants
fait un find sur "component"
[^] # Re: La crypto c'est sympa pour chiffrer OTP
Posté par free2.org . En réponse au sondage La crypto c'est sympa pour chiffrer. Évalué à 2.
Tu trouves cette démo facilement sur le net, tu peux donc la lire !
Tu trouveras aussi sur le net la démo qui garantit que OTP est le seul algo incassable par une puissance dez calcul illimitée. Cette démo est un peu plus longue (mais compréhensible avec des maths de niveau bac science +1)
[^] # chain of trust !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
TCG ajoute dans le PCR un hash du bios écrit spécialement pour tcg, qui ajoute ensuite dans le PCR un hash du premier exécutable de boot écrit spécialement pour TCG (l'exécutable uniquement, pas ses données, cela est précisé dans les docs "chain of trust" officiels), qui ajoute un hash du 2e exécutable écrit spécialement pour TCG, qui ajoute... etc. jusqu'à ce que l'OS compatible TCG ait pris les choses en main
hashing is employed to extend trust from the BIOS to other areas of the platform
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 !)
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 !
(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)
REFUSONS TOUS les softs et hards TCG avant qu'il ne soit trop tard !
cf http://www.intel.com/idf/us/spr2003/presentations/S03USSFCS69_OS.pd(...)
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 !