Avant propos : je rapelle à toutes fins utiles que la réponse que j'ai postée était suite à l'afirmation suivante : Tu vas m'expliquet comment TPM, quand l'OS lui envoie un hash pour le stocker, peut savoir qu'il s'agit du hash d'un matériel ou d'un logiciel !
afirmation dans le sens ou elle certifie que l'OS peut envoyer un hash à la puce TPM, et que celui-ci peut être matériel.
Ma réponse a cette affirmation était a) l'OS ne peut pas envoyer de hash au TPM (pour être plus précis il ne peut qu'étendre un PCR) b) La puce ne stoque pas les hashs (à l'exception des 15 premiers en norme 1.2) c) La puce n'a de toute façon pas les moyens d'accéder au matériel (excepté le bios, et encore parcequ'il est étudié pour et qu'il se charge en mémoire)
Ensuite :
Si tu stockes l'identifiant de chaque élément de la config matérielle dans un des files cité ci-dessus, alors ces identifiants seront hashés par le TPM.
Si tu as déjà un identifiant fiable de ton matériel, pourquoi ne pas l'utiliser directement ? Si il n'est pas fiable qu'est-ce qui te prouve que ce que tu envoies à la puce TPM est valable ? Si tu as déjà signé le driver (par exemple) et que celui ci te renvoit un identifiant matériel alors cette identifiant est forcément bon sans repasser par la case TPM. Et si le driver n'est pas signé/validé qu'est ce qui te prouve que l'identifiant qu'il remonte est valable ? Comme indiqué dans ta citation le TPM ne peut hasher qu'un fichier qui contient des données ou des executables chargés pendant l'execution. Une carte graphique en tant que matériel n'est pas un fichier (même sous unix - elle peut éventuellement avoir une interface qui se comporte comme un fichier mais c'est très différent) , ne contient pas d'executable (éventuellement des données - mais pas seulement) et surtout n'est pas chargée à l'execution.
Ensuite tu n'obtiendras pas la signature de l'identifiant, mais la signature de PCR, donc l'intraréévaluation de toutes les signatures précédente dans ce PCR.
Contrairement à ce que tu prétends dans de nombreux messages, ce n'est pas un hash de tous les hash qui est envoyé. Mais bien chacun des hash, donc il est possible d'identifier chaque élément séparément.
Il y a dans le papier que tu cites une introduction assez longue dans laquelle ils expliquent (rapidement) ce qui se passe. Ils décrivent notament comment ils partent du PCR[10] et comment ils le remplissent. On voit d'un coté la "measurement list" - la liste des mesures et de l'autre les hash : (page 3)
Comme tu peux le constater, avant même que l'on mesure quoi que ce soit (PCR vide, compteur à 000) on a déjà un hash de type agregate. Ce hash correspond au hash "de base" soit celui de 7 premiers PCR (on est ici en norme 1.1).
L'explication du fonctionnement est toute simple et elle est donnée à coté :
The TPM computes the new register content by building a SHA1 over the current content concatenated with the new 160bit number written into the PCR.
En plus dans ta vision des choses, le fait que les éléments soient hashés et signés en concaténation et non en stand alone est plutôt une mauvaise chose, car c'est la seule chose qui garantie que le TPM est impossible à émuler. Sinon il suffirait de prendre les mesures directement sous un OS de confiance et de les reporter à l'identique sous un OS non fiable.
Tu es plus royaliste que le roi: meme TCG avoue officiellement que la remote attestation à des fins de bloquer les utilisateurs de certaines configurations est rendue possible !
Non pas à certaines configurations, mais à tous les ordinateurs qui n'ont pas une endorsement key activée. C'est à dire à peu près tous pour l'instant je crois.
As a consequence, users who do not choose to employ TCG technology would be essentially unable to access that service.
Mais rien n'est dit au sujet de la configuration du poste, on a une EK et un TPM ou pas. Si on les a on rentre, sinon on reste à la porte.
Hors sans puce de type TPM, cette horreur est impossible !
Ah bon ? Tu connais les sites qui exigent le HTTPS ? Ceux qui te boudent si tu n'a pas flash ou le windows media player 10 (je ne parle pas ici des DRM mais bien des technos) ? Et bien c'est pareil. Tu ne veux pas suivre les prérequis, tu ne rentres pas.
[^] # Re: Trusted computing = remote attestation= windows drm obligatoire
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 6.
Tu vas m'expliquet comment TPM, quand l'OS lui envoie un hash pour le stocker, peut savoir qu'il s'agit du hash d'un matériel ou d'un logiciel !
afirmation dans le sens ou elle certifie que l'OS peut envoyer un hash à la puce TPM, et que celui-ci peut être matériel.
Ma réponse a cette affirmation était a) l'OS ne peut pas envoyer de hash au TPM (pour être plus précis il ne peut qu'étendre un PCR) b) La puce ne stoque pas les hashs (à l'exception des 15 premiers en norme 1.2) c) La puce n'a de toute façon pas les moyens d'accéder au matériel (excepté le bios, et encore parcequ'il est étudié pour et qu'il se charge en mémoire)
Ensuite :
Si tu stockes l'identifiant de chaque élément de la config matérielle dans un des files cité ci-dessus, alors ces identifiants seront hashés par le TPM.
Si tu as déjà un identifiant fiable de ton matériel, pourquoi ne pas l'utiliser directement ? Si il n'est pas fiable qu'est-ce qui te prouve que ce que tu envoies à la puce TPM est valable ? Si tu as déjà signé le driver (par exemple) et que celui ci te renvoit un identifiant matériel alors cette identifiant est forcément bon sans repasser par la case TPM. Et si le driver n'est pas signé/validé qu'est ce qui te prouve que l'identifiant qu'il remonte est valable ? Comme indiqué dans ta citation le TPM ne peut hasher qu'un fichier qui contient des données ou des executables chargés pendant l'execution. Une carte graphique en tant que matériel n'est pas un fichier (même sous unix - elle peut éventuellement avoir une interface qui se comporte comme un fichier mais c'est très différent) , ne contient pas d'executable (éventuellement des données - mais pas seulement) et surtout n'est pas chargée à l'execution.
Ensuite tu n'obtiendras pas la signature de l'identifiant, mais la signature de PCR, donc l'intraréévaluation de toutes les signatures précédente dans ce PCR.
Contrairement à ce que tu prétends dans de nombreux messages, ce n'est pas un hash de tous les hash qui est envoyé. Mais bien chacun des hash, donc il est possible d'identifier chaque élément séparément.
Il y a dans le papier que tu cites une introduction assez longue dans laquelle ils expliquent (rapidement) ce qui se passe. Ils décrivent notament comment ils partent du PCR[10] et comment ils le remplissent. On voit d'un coté la "measurement list" - la liste des mesures et de l'autre les hash : (page 3)
000:D6DC…D3DB n/a [boot aggregate]
001:84AB…DA4F [exec]
init
002:9ECF…BE3D [library]
ld-2.3.2.so
003:3365…2342 [library]
libc-2.3.2.so
004:A4DC…C12B [exec]
bash
…
027:2AC8…980D [bash-src]
clock
028:C0F7…9A3D [exec]
hwclock
…
070:01B3…9A1E [bash-cmd]
rc
071:CEBA…1AA4 [exec]
runlevel
072:2998…8ED4 [bash-cmd]
egrep
073:6846…B72D [bash-cmd]
kudzu
…
080:147D…8168 [module]
parport
081:F940…0115 [module]
parport_pc
…
244:D312…DA7C [bash-cmd]
rc.local
245:BB2C…AAB3 [exec]
mingetty
Comme tu peux le constater, avant même que l'on mesure quoi que ce soit (PCR vide, compteur à 000) on a déjà un hash de type agregate. Ce hash correspond au hash "de base" soit celui de 7 premiers PCR (on est ici en norme 1.1).
L'explication du fonctionnement est toute simple et elle est donnée à coté :
En plus dans ta vision des choses, le fait que les éléments soient hashés et signés en concaténation et non en stand alone est plutôt une mauvaise chose, car c'est la seule chose qui garantie que le TPM est impossible à émuler. Sinon il suffirait de prendre les mesures directement sous un OS de confiance et de les reporter à l'identique sous un OS non fiable.
Tu es plus royaliste que le roi: meme TCG avoue officiellement que la remote attestation à des fins de bloquer les utilisateurs de certaines configurations est rendue possible !
Non pas à certaines configurations, mais à tous les ordinateurs qui n'ont pas une endorsement key activée. C'est à dire à peu près tous pour l'instant je crois.
Mais rien n'est dit au sujet de la configuration du poste, on a une EK et un TPM ou pas. Si on les a on rentre, sinon on reste à la porte.
Hors sans puce de type TPM, cette horreur est impossible !
Ah bon ? Tu connais les sites qui exigent le HTTPS ? Ceux qui te boudent si tu n'a pas flash ou le windows media player 10 (je ne parle pas ici des DRM mais bien des technos) ? Et bien c'est pareil. Tu ne veux pas suivre les prérequis, tu ne rentres pas.