à ce propos je rappelle l'existence d'un document officiel de Intel (fondateur de TCPA/TCG) du printemps 2003 qui explique les mécanismes d'attestation de la plateforme (identification à distance par un tiers des matériels et de l'OS) avec TCPA/TCG http://www.intel.com/idf/us/spr2003/presentations/S03USSFCS69_OS.pd(...)
La discrimination des matériels non TCPA/TCG et des noyaux modifiables (comme celui de Linux) arrive à grand pas !
et il n'est fait nulle part mention de hasher exclusivement l'executable.
une fois de + tu fais exprès d'oublier que la norme TCG oblige à faire un BIOS qui répond à un cahier des charges précis dans lequel il est clairement que dit qu'on doit hasher la partie exécutable du mbr et pas sa partie données: 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.
il est impossible de continuer à discuter avec quelqu'un qui refuse de lire la phrase ci-dessus issue des specs officielles TCPA !
pas d'accord car j'ai bien précisé y'a des cartes PCI
cartes aléatoires spécialisées PCI qui sont en effet basées sur des phénomènes physiques aléatoires (il y a ausi des cartes mères VIA avec de tels générateurs)
mais en + il y a des phénomènes aléatoires courants comme le temps (en millisecondes ou mieux) écoulé entre 2 frappes de touche du clavier, manipulations souris, voir entre la réception de paquets provenants d'une carte réseau
c'est sur l'accumulation de ces phénomènes que se base /dev/random dans Linux (il y a un pool de ces phénomènes qui est sauvegardé lors d'un shutdown et qui bloque /dev/random quand il est épuisé)
j'ai oublié de préciser que il y a aussi de nombreux paquets debian qui peuvent configurer automatiquement les matériels après l'installation initiale (même si celle ci a été faite avec l'installeur de base fourni avec woody):
discover, auto-install , kudzu , hwdata, read-edid etc.
on peut aussi booter un CD knoppix après une install normale et recopier certains fichiers de config automatiquement générés par knoppix
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
faux et d'ailleurs j'en ai deja parlé tout à l'heure. tu as de nombreuses possibilités dont:
1. avoir un BIOS (car TCPA onlige à modifier les BIOS !) qui reconnait une convention de type une séquence d'octet de meme valeurs
2. stocker dans le mbr toujours au meme endroit la taille de l'exécutable
3. c'est même possible sans convention: il suffit de commencer systématiquement la zone de données des mbr par la table des partitions, et je te mets au défi de prouver qu'on ne peut pas faire un algorithme pour trouver (dans la très grande majorité des cas) où commence la table des partitions dans les mbr actuels (dont la zone de donnée commence effectivement par la table)
enfin je te rappelles que tu n'as pas le choix: si tu veux respecter la norme TCG, tu dois hasher l'exécutable et ne hasher que l'exécutable
oui, c'est le nouvel installeur déjà évoqué ci-dessus: debian-installer http://www.debian.org/devel/debian-installer/(...)
il est dores et deja testable et sera fourni avec sarge
sinon il y a aussi l'installeur graphique de progeny (avec reconaissance matériel aussi): pgi
et bien-sûr il faut savoir que knoppix et ses dérivés sont installables sur le disque dur ultra rapidement (reconaissance auto du matériel et quasiment aucune question posée pour installer 2,5 gigas de programmes configurés et décompressés en 15 minutes environ)
Je suis évidemment entièrement d'accord avec toi sur le fond (cf mon site d'annonces bénévoles libres http://free2.org(...))
Pour joindre l'utile à l'agréable il vaut mieux d'abord rendre service dans des domaines qui nous plaisent et à des gens avec qui on est suceptible d'avoir des affinités (c'est mieux que de vivre ça comme un calvaire et d'en être dégouté)
Je te félicite pour tes bonnes intentions mais c'est plutot ta manière de t'exprimer en déformant les choses qui me gène:
le lien que tu donnes parle d'héberger des congressistes d'ONG, et toi tu parles d'héberger des gens en difficulté
ce n'est pas pareil, même s'il y a des recoupements entre les 2 populations, et même si beaucoup d'ONG s'occupent en effet de personnes en difficulté et ont des membres qu'il doit être agréable (et instructif) d'héberger.
mais c'est ridicule ce que tu dis
"une puce de hash"
comment s'assurer que le fonctionnement de cette puce n'est pas contourné par l'utilisateur ?
comme montré ci-dessus par les specs et le domcument Intel, TCG a trouvé une solution incontournable par l'utilisateur !
à moins de casser la crypto employée ou qu'il y ait des failles dans les specs ou dans l'implantation (car comme j'ai expliqué à Beretta, il n'y a aucune raison pour qu'une puce contienne moins de failles que un micro-noyau opensource, je refuse de faire confiance à une puce opaque dont je ne peux controler qu'elle n'a pas de backdoor)
le MBR est un secteur contenant un exécutable et une zone de donées
mais je suis sûr maintenant que tu fais exprès de ne pas comprendre ce qui suit et qu'on a discuté des milliers de fois:
page 24 PC
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.
donc le BIOS doit hasher la zone exécutable du MBR et pas la zone de données !
tu n'a toujours pas compris la norme TCG qui oblige le BIOS (MUST écrit en capitale) à ne hasher que les données,
j'ai deja répondu à cela ci-dessous: https://linuxfr.org/comments/281799.html(...)
désolé la norme TCPA oblige fortement à ne hasher que les données
et tu le sais très bien car on en a parlé de nombreuses fois ! page 24 PC
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 début des données à ne pas hasher peut être indiqué de plusieurs façons (suite d'octet ayant des valeurs précises, longueur du code ou des données stocké à une position précise, etc.,)
incroyable, to quote en anglais veut dire citer (donner une partie de quelque chose) et non "donner le numéro de"
la partie du PCR contenant le hash sera donc signée et donnée au challenger
tu dis des trucs faux quand ça t'arranges, c'est désespérant et fatiguant !
PS d'une manière générale travailles-tu avec des sociétés qui font de l'embarqué ? (et qui en général aiment les puces permettent de s'assurer à distance que l'utilisateur n'a pas modifié sans autorisation un matériel embarqué)
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, et de ne laisser dans la partie exécutable que des données constantes qui ne feront donc pas varier le hash !
non mais tu te relis parfois ?
en quoi le fait de charger TOUT le premier secteur obligerait à hasher aussi la zone de données située après l'exécutable ? (alors que le bon sens et la norme consistent à ne hasher que la partie exécutable !)
et d'ailleurs il est plusieurs fois précisé par TCG (et ça va de soi d'ailleurs) que on ne doit pas hasher les données mais juste la partie exécutable du code que l'on va exécuter ensuite !
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.
n'importe quoi, c'est évidemment le bios qui va choisir la zone du mbr qu'il va hasher, rien ne l'oblige à hasher les données !
tu es d'un aveuglement incroyable sur les pages 8 et 9 !
page 9 il est clairement dit que la PCR value obtenue contient la mesure (définie page 8, à savoir le hash shA1)
il est bien précisé que la value PCR envoyées est signée et non cryptée !
PS au fait as-tu travaillé avec la boite aaee (2a2e) ou un de ses partenaires ?
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
il n'y a absolument rien qui empeche de mettre toutes les données à la fin de ces octets
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 !
une fois de + tu dis ce qui t'arrange, pas la vérité !!!
au fait, contrairement à ce que tu avais plusieurs fois affirmé avec véhémence, un autre document de Intel (membre fondateur de TCG)explique bien que la norme TCPA exige des BIOS spéciaux (évidemment puisque le BIOS va effectuer des opérations de hash destinées à être stockées dans le PCR) http://www.intel.com/update/departments/initech/it11001.pdf(...)
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'imagine que tu fait allusion a la fleche
je n'ais fait aucune allusion
je maintiens qu'il est marqué en toutes lettres page 9 que le challenger va obtenir la mesure du component1
et page 8 il est marqué en toutes lettres que la mesure du component1 est un hash sha1
ces 2 pages suffisent amplement à montrer ce qu'est vraiment TCG/TCPA
PS: vu ta mauvaise volonté à lire ce qui est marqué en toutes lettres dans le document Intel, j'aimerais que tu sois franc maintenant sur l'indépendance de ton opinion: peux tu nous dire si tu as eu l'occasion de travailler sur TCPA dans le cadre de ton travail ?
[^] # identification à distance de la plateforme (hard et OS) par TCPA/TCG
Posté par free2.org . En réponse à la dépêche L'EUCD appliqué en Allemagne. Évalué à 1.
http://www.intel.com/idf/us/spr2003/presentations/S03USSFCS69_OS.pd(...)
La discrimination des matériels non TCPA/TCG et des noyaux modifiables (comme celui de Linux) arrive à grand pas !
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
une fois de + tu fais exprès d'oublier que la norme TCG oblige à faire un BIOS qui répond à un cahier des charges précis dans lequel il est clairement que dit qu'on doit hasher la partie exécutable du mbr et pas sa partie données:
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.
il est impossible de continuer à discuter avec quelqu'un qui refuse de lire la phrase ci-dessus issue des specs officielles TCPA !
[^] # carte pci et /dev/random
Posté par free2.org . En réponse au sondage La crypto c'est sympa pour chiffrer. Évalué à 1.
cartes aléatoires spécialisées PCI qui sont en effet basées sur des phénomènes physiques aléatoires (il y a ausi des cartes mères VIA avec de tels générateurs)
mais en + il y a des phénomènes aléatoires courants comme le temps (en millisecondes ou mieux) écoulé entre 2 frappes de touche du clavier, manipulations souris, voir entre la réception de paquets provenants d'une carte réseau
c'est sur l'accumulation de ces phénomènes que se base /dev/random dans Linux (il y a un pool de ces phénomènes qui est sauvegardé lors d'un shutdown et qui bloque /dev/random quand il est épuisé)
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
[^] # cache google !
Posté par free2.org . En réponse au journal La page des vulnérabilités de IE supprimée !. Évalué à 1.
http://www.google.fr/search?q=unpatched+IE(...)
[^] # Re: installation facile de Debian avec reconaissance auto du matériel
Posté par free2.org . En réponse à la dépêche Synaptic, une interface graphique conviviale pour apt-get. Évalué à 2.
discover, auto-install , kudzu , hwdata, read-edid etc.
on peut aussi booter un CD knoppix après une install normale et recopier certains fichiers de config automatiquement générés par knoppix
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
faux et d'ailleurs j'en ai deja parlé tout à l'heure. tu as de nombreuses possibilités dont:
1. avoir un BIOS (car TCPA onlige à modifier les BIOS !) qui reconnait une convention de type une séquence d'octet de meme valeurs
2. stocker dans le mbr toujours au meme endroit la taille de l'exécutable
3. c'est même possible sans convention: il suffit de commencer systématiquement la zone de données des mbr par la table des partitions, et je te mets au défi de prouver qu'on ne peut pas faire un algorithme pour trouver (dans la très grande majorité des cas) où commence la table des partitions dans les mbr actuels (dont la zone de donnée commence effectivement par la table)
enfin je te rappelles que tu n'as pas le choix: si tu veux respecter la norme TCG, tu dois hasher l'exécutable et ne hasher que l'exécutable
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
[^] # installation facile de Debian avec reconaissance auto du matériel
Posté par free2.org . En réponse à la dépêche Synaptic, une interface graphique conviviale pour apt-get. Évalué à 3.
http://www.debian.org/devel/debian-installer/(...)
il est dores et deja testable et sera fourni avec sarge
sinon il y a aussi l'installeur graphique de progeny (avec reconaissance matériel aussi): pgi
et bien-sûr il faut savoir que knoppix et ses dérivés sont installables sur le disque dur ultra rapidement (reconaissance auto du matériel et quasiment aucune question posée pour installer 2,5 gigas de programmes configurés et décompressés en 15 minutes environ)
[^] # Re: Pour construire un monde meilleurs, on a besoin de Toi !
Posté par free2.org . En réponse au journal Pour construire un monde meilleurs, on a besoin de Toi !. Évalué à 3.
Pour joindre l'utile à l'agréable il vaut mieux d'abord rendre service dans des domaines qui nous plaisent et à des gens avec qui on est suceptible d'avoir des affinités (c'est mieux que de vivre ça comme un calvaire et d'en être dégouté)
Je te félicite pour tes bonnes intentions mais c'est plutot ta manière de t'exprimer en déformant les choses qui me gène:
le lien que tu donnes parle d'héberger des congressistes d'ONG, et toi tu parles d'héberger des gens en difficulté
ce n'est pas pareil, même s'il y a des recoupements entre les 2 populations, et même si beaucoup d'ONG s'occupent en effet de personnes en difficulté et ont des membres qu'il doit être agréable (et instructif) d'héberger.
[^] # Re: Faiblesse des protocoles P2P
Posté par free2.org . En réponse à la dépêche Faiblesse des protocoles P2P. Évalué à 1.
d'où l'intéret de ne pas avoir de port par défaut (freenet, etc.)
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
"une puce de hash"
comment s'assurer que le fonctionnement de cette puce n'est pas contourné par l'utilisateur ?
comme montré ci-dessus par les specs et le domcument Intel, TCG a trouvé une solution incontournable par l'utilisateur !
à moins de casser la crypto employée ou qu'il y ait des failles dans les specs ou dans l'implantation (car comme j'ai expliqué à Beretta, il n'y a aucune raison pour qu'une puce contienne moins de failles que un micro-noyau opensource, je refuse de faire confiance à une puce opaque dont je ne peux controler qu'elle n'a pas de backdoor)
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
quelle mauvaise foi !!!
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
mais je suis sûr maintenant que tu fais exprès de ne pas comprendre ce qui suit et qu'on a discuté des milliers de fois:
page 24 PC
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.
donc le BIOS doit hasher la zone exécutable du MBR et pas la zone de données !
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
j'ai deja répondu à cela ci-dessous:
https://linuxfr.org/comments/281799.html(...)
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
et tu le sais très bien car on en a parlé de nombreuses fois !
page 24 PC
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 début des données à ne pas hasher peut être indiqué de plusieurs façons (suite d'octet ayant des valeurs précises, longueur du code ou des données stocké à une position précise, etc.,)
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
la partie du PCR contenant le hash sera donc signée et donnée au challenger
tu dis des trucs faux quand ça t'arranges, c'est désespérant et fatiguant !
PS d'une manière générale travailles-tu avec des sociétés qui font de l'embarqué ? (et qui en général aiment les puces permettent de s'assurer à distance que l'utilisateur n'a pas modifié sans autorisation un matériel embarqué)
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
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, et de ne laisser dans la partie exécutable que des données constantes qui ne feront donc pas varier le hash !
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
en quoi le fait de charger TOUT le premier secteur obligerait à hasher aussi la zone de données située après l'exécutable ? (alors que le bon sens et la norme consistent à ne hasher que la partie exécutable !)
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . 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 free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
n'importe quoi, c'est évidemment le bios qui va choisir la zone du mbr qu'il va hasher, rien ne l'oblige à hasher les données !
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
page 9 il est clairement dit que la PCR value obtenue contient la mesure (définie page 8, à savoir le hash shA1)
il est bien précisé que la value PCR envoyées est signée et non cryptée !
PS au fait as-tu travaillé avec la boite aaee (2a2e) ou un de ses partenaires ?
[^] # mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
il n'y a absolument rien qui empeche de mettre toutes les données à la fin de ces octets
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 !
une fois de + tu dis ce qui t'arrange, pas la vérité !!!
au fait, contrairement à ce que tu avais plusieurs fois affirmé avec véhémence, un autre document de Intel (membre fondateur de TCG)explique bien que la norme TCPA exige des BIOS spéciaux (évidemment puisque le BIOS va effectuer des opérations de hash destinées à être stockées dans le PCR)
http://www.intel.com/update/departments/initech/it11001.pdf(...)
[^] # soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
J'imagine que tu fait allusion a la fleche
je n'ais fait aucune allusion
je maintiens qu'il est marqué en toutes lettres page 9 que le challenger va obtenir la mesure du component1
et page 8 il est marqué en toutes lettres que la mesure du component1 est un hash sha1
ces 2 pages suffisent amplement à montrer ce qu'est vraiment TCG/TCPA
PS: vu ta mauvaise volonté à lire ce qui est marqué en toutes lettres dans le document Intel, j'aimerais que tu sois franc maintenant sur l'indépendance de ton opinion: peux tu nous dire si tu as eu l'occasion de travailler sur TCPA dans le cadre de ton travail ?