free2.org a écrit 2367 commentaires

tu peux être un peu plus clair STP ?
paske là j'ai envie de te dire: je crois que tu ne comprends pas ce que je dis !

je dis que dans TCPA, après le boot, il y a la possibilité d'obtenir plusieurs signatures (digest) dont celle du programme auquel le BIOS a donné la main en premier au moment du boot. Cette signature , dans le cas d'un petit OS loader dont je parle, ne changera pas et ne dépendera pas de la config matérielle. D'où la possibilité d'identifier facilement un OS loader agréé par MS.

Tu avais compris ça ?

le contenu du blob de migration n'est pas crypté ?

en tout cas faire un backup des clés protégées par PCR suppose des droits complets sur la puce, ce qui pourrait ne pas être si évident si le BIOS en empêche le possesseur de la machine (seul le BIOS possede les tokens d'authentification et ne les donne pas à l'utilisateur)

Mon papier est en constante amélioration. Cependant les messages postés ici sur linuxfr ont bien montré qu'il était possible d'utiliser le PCR pour faire du controle de type DRM, ce qui est quand même la base du problème posé par TCPA !

PS: tu peux nous faire part de ton idée, on peut t'aider avec plaisir !

rien n'empeche de faire booter par le BIOS un petit programme que nous appellerons OS loader, petit programme dont le digest sera toujours le meme et donc facilement identifaiable. Une particularité cependant, ce programme refusera de lancer autre chose qu'un OS dument signé par MS.

et voila, DRM !

si le backup est complet et à l'identique, pourquoi le 2e TPM me laissera-t-il l'accès aux données protégées par PCR si je n'utilise pas exactement la meme config ?

Que Microsoft puisse etre sur que windows est integre et ne s'execute pas dans un emulateur genre "bloch" (au moment de la phase d'activation).
je crois que les digests enregistrés dans la puce TCPA au moment du boot sont fait pour ça: à tout moment on peut avoir la signature de l'OS qui a été booté directement par le BIOS: c'est donc forcément lui l'OS master de la machine. Si sa signature correspond à une signature connue de Win, alors c'est Win l'OS master de la machine, et il ne s'exécute pas d'un virtualiseur.

D'un autre cote, Kha dit que le "peer" ne peut pas voir la config, mais seulement un hash de la config. Il faut trancher cette question.
D'après ce que j'ai compris le hash de la config est détaillé:
il y a un hash pour le matériel, un hash pour le BIOS, et un hash pour l'OS
en comparant le hash de l'OS avec les hash des versions officielles de Win, on peut savoir si l'OS booté par le BIOS est bien Win.

et l'équivalent de fireflier pour PF il est où ? :)
http://fireflier.sourceforge.net/(...)
http://www.sourceforge.net/projects/fireflier(...)

Cela nous rappelle que Ross est un chercheur qui n'est pas le premier venu en matière de crypto. Et la raison pour laquelle sa FAQ continue de présenter TCPA et Palladium sur un pied d'égalité (alors que cette faq a été mise à jour récemment) est qu'il est convaincu que TCPA est bel et bien la partie hardware sur laquelle s'appuiera Palladium.
Ce que j'explique maintenant sur la nouvelle version de ma page http://free2.org/tcpa/(...)

Je réponds moi-meme en partie à la premiere question: Windows utilise un PCR pour sceller les clés qu'il veut cacher, et le driver TCPA de Windows n'autorise pas l'accès à ces clés.
Sous un autre OS je ne peux pas accéder directement à ces clés car le PCR est différent.

Reste le probleme de l'accès indirect via des fonctions de déplacement des clés: dans nos discussions KHA a soutenu très fort, contre moi, que il était possible de déplacer toutes les clés (et donc toutes les clés protégées par un PCR sous un autre OS). Voulez-vous bien me confirmer que c'était une erreur et que les clés protégées par un PCR ne sont pas déplacables sous un autre OS (à moins d'utiliser la manipe BACKUP de Kha, dont je ne comprends pas pourquoi le 2e TPM me donnerait à l'accès au données protégées par PCR sous un autre OS).

Pour la 2e question, je viens de lire Thoran dire que le noyau Win ne doit pas contenir de bug: en utilisant des techniques de micro-noyau (Hurd/Mach) ou de virtualiseur (virtualPC, plex86, UserModeLinux) il est possible de booter un OS très simple (et donc moins sujet à des bugs critiques) qui ne sert qu'à exécuter d'autres OS compartimentés et donc protégés les uns des autres (sandboxs)

Une première question pour toi et KHA: en quoi le fait que Windows bloque l'accès à TCPA quand je suis sous Win m'empeche-t-il d'utiliser le BIOS ou un autre OS pour manipuler les clés que Win a stocké dans TCPA ?

2e question pour Thoran: peux-tu me rappeler quelle est ta vision de l'utilisation de TCPA par un Palladium soft ? Je propose justement une solution soft simple sur ma page web remise à jour: http://free2.org/tcpa/(...)
(merci de me signaler d'autres erreurs sur cette nouvelle version de ma page)

"Ces rapports sont des indications statistiquement uniques du systeme de la plateforme, mais ils se produiront sur toutes les plateformes qui feront tourner le meme environement logiciel".
Mais quel est l'intéret de cette phrase pour un fournisseur de contenu distant avec qui je communique ? (c'est le contexte du document que j'ai cité)
Aucun, sauf si cela lui permet de s'assurer que mon OS est bien compatible DRM !

Dans tous tes commentaires précédents tu supposes aussi que le BIOS est du coté de l'utilisateur, pas du coté de Windows. Le bios pourrait notamment intercepter le token Owner et le refiler à Windows, si l'OS est bien signé avec une clé privée correspondant à celle publique qui est stockée dans le bios.

Enfin tu as suggéré qu'il y a des "bonnes" applications de TCPA: lesquelles ne sont pas faisables avec des solutions software pures comme les softs libres dont je parle dans mon article ?

" Ca pose plus la question de savoir si il faut boycotter Windows ou TCPA. "

La réponse à ta question est simple: aujourdh'ui il est bien plus facile de boycotter TCPA (toutes les "bonnes" fonctions de TCPA ont leur équivalent en software pur) que de boycotter Windows (ce qui implique de nombreux logiciels et documents utilisables que sous Windows.

Maintenant que tu sais, toi aussi, qu'il faut décourager l'adoption de TCPA:
BIENVENUE AU CLUB :)

tu oublies qu'il faut la passphrase ET le CD !
c'est mieux que une passphrase seule

lis mon correctif et tu comprendras ton erreur

Apparemment tu sais tout mieux que les documents du site officiel TCPA:
je maintiens fermement que la phrase:
"yet they will occur in all platforms with the same software environment."
signifie que les palteformes ayant le meme OS auront le meme digest

Sinon peux-tu me dire pourquoi les gens de TCPA se sont donnés la peine de rédiger cette phrase dans ce document ?

Moi je peux te le dire: pour les rédacteurs de ce document, l'identification sans faille de l'OS est un argument de vente de TCPA à toutes les sociétés avides de DRM, et elles sont nombreuses !

Comme tu le suggère fort justement, il est quasiment impossible d'imaginer toutes les utilisations possible de TCPA, d'autant plus que la spec 1.2 n'est toujours pas accessible au public, meme si les ajouts qui ont filtrés sont très liés au DRM (vérification de la date/heure par la puce, compteurs infasilfiables, ...).
Pour ma part j'explique sur ma page qu'il est facile d'utiliser une puce permettant d'identifier un OS, pour s'assurer qu'un OS contient bien la notion de trusted sandbox chère à palladium.

PS: tu oublies systématiquement de traduire le mot "same", il te pose un problème ?

correctif :)
ensuite ce couple de clé sert à encoder une clé privée symétrique dont la taille varie dans les logiciels libres de 128 à 256 bits

j'emploie le terme clé asymétrique pour distinguer une clé privé d'un algo asymétrique d'une clé privée d'un algo symétrique (ce osnt toutes 2 des clés privées et il faut bien pouvoir éviter els ambiguités)

tu n'as pas bien compris comment est habituellement implémenté la crypto à clé (dite crypto asymétrique):
un couple de clé publique /clé privé est généré (et ces clés ont depuis des années dans les logiciels libres des tailles en bit d'au moins 1024)
ensuite ce couple de clé sert à encoder une clé privée asymétrique dont la taille varie dans les logiciels libres de 128 à 256 bits

donc ton argument qui consisterait à comparer les tailles des clés symetriques des logiciels libres avec les tailles des clés asymétriques de TCPA est très faux.

à chaque procédure de prise d'ownership (suite à un reset), il est créeé
un nouveau token qui à lui seul suffit à s'identifier comme owner !
Si Win contient un soft de prise d'ownership, il peut s'emparer une fois la prise terminée de ce token ,et il pourra comme tu le dis si bien s'assurer qu'il est le owner.
page 3 de
http://www.trustedcomputing.org/docs/TCPA_security_policy_v0_45.pdf(...)
The TPM ownership token provides proof of TPM ownership. The creation of the token
occurs when the owner completes the ownership protocol. The value is stored in a shielded
location inside of the TPM. The administrator provides this token to access administrator
functionality, including system configuration.

page 6
applications authorized to perform the Administrator role have knowledge of the TPM
authentication token.

Maintenant relis ta citation de ma citation. Tu vois le problème ?
Bon je t'aide:
yet they [the same digests] will occur in all platforms with the same software environment.

Cela veut dire que le digest de l'OS booté qui est stocké dans TCPA sera toujours les meme chez toutes les personnes qui utilisent le meme OS. Cela suffit largement à identifier ton OS à l'aide d'un challenge encrypté par ta puce TCPA !


sinon, KHA c'est un pseudonyme pour IBM ? :)

et t'as deja vu des clés asymétriques de 256 bits ? en 1970 ?

j'ai mis à jour mes infos sur TCPA, avec notamment comment il est simple d'utiliser TCPA pour faire des trusted sandboxs à la Palladium (ce qui,en l'état actuel de ce qu'on peut savoir sur Palladium, est sa caractéristique majeure)

il y a des générateurs aléatoires hardware basés sur de sphénomènes physiques impérvisibles, achetables sous formes de cartes PCI

quand à garder secrète la clé privée, c'est le problème de TOUS les algorithmes de cryptage. Une passphrase peut aider. Un coffre-fort dans lequel tu mets le Cd quand tu ne t'en sert pas aussi.

The creator of the key can prevent migration by the User by wrapping it with a non-migratable storage key
and loading random data for the MigrationAuthorizationData.
page 164

Dans tous tes commentaires tu sembles supposer que le "owner" du TPM est forcément le possesseur de la mcahine, alors que les specs n'interdisent pas à un OS comme Windows d'être ce owner. D'ailleurs si les applications DRM de Win exigent que Win soit owner, on devra laisser owner à Win pour pouvoir utiliser ces applications.

Pour roots of trust je te conseille de relire le début du PDF des specs...

Pourquoi t'entêtes-tu alors que le site officiel TCPA possede des documents affirmant haut et fort que le but est bien de permettre à un fournisseur de contenu distant d'identifier les logiciels de ta machine afin de choisir s'il décide de faire confiance ou non à ton OS (grace aux checksums de l'OS par TCPA créés lors du boot):

For example, before making content available to a remote user, it is likely that a provider
will need to know that the remote platform is trustworthy. The provider's platform (the
"challenger") queries the remote platform. During system boot, the challenged platform
creates a series of cryptographic digests (integrity metrics) that represent the method
used to build the software environment in the challenged platform. These digests are
statistically unique indications of the platform environment, yet they will occur in all
platforms with the same software environment.
When it receives the query from the challenger, the remote platform responds by digitally
signing and then sending the integrity metrics. The digital signature prevents tampering
Page 2
and allows the challenger to verify the signature. If the signature is verified, the
challenger can then determine whether the identity metrics are trustworthy. If so, the
challenger, in this case the service provider, can then deliver the content. The TCPA
system reports the metrics and lets the challenger make the final decision regarding the
trustworthiness of the remote platform. Based upon the reported integrity metrics, the
challenger can determine if the platform is configured in a trusted state.
http://www.google.fr/search?q=cache:YDeLgyHUXDoC:www.trustedcomputi(...)

j'ai bien lu les pages 171 a 177 , et page 171 on peut lire qu'il est impossible de migrer les clés de type non-migratory (ce qui est logique !) je crois que tu confonds "roots of trust" et TRUSTED ROOT ... à propos de "extend" j'aime bien la notion de software certifié par son fournisseur (shipper): The TPM_Extend event is in response to loading a firmware or software component for which a VE certificate was available. *Event points to the VE certificate that shipped with the platform firmware or software (or discovered by other means). Size indicates the length of this structure. ExtendValue is the digest of the firmware, software or page 58 extend qui n'est pas désactivable: Note, however, that a disabled TPM never disables the "extend" capability. page 244

petite remarque sur l'algo OTP dont vous parlez: si je donne un CD-ROM ou un disque dur à un de mes amis, on pourra s'échanger un très grand nombre de messages textes (voir multimedias dans le cas d'un dur) pendant plusieurs mois. Considérant qu'il s'agit d'une crypto démontrée mathématiquement, je ne trouve pas OTP si dur à mettre en oeuvre.

Outre le fait que la EK ne soit pas du tout obligatoire cette clé unique est dans les specs, et IBM l'a intégré à ses puces actuelles ! que veux-tu de + ? Bien que ce risque ne soit pas nul, il est de tres loin inferieur a celui des numeros de serie chez Intel l'énorme différence est dans le fait que on ne peut pas falsifier cette clé même si on a le controle total des softs d'un ordinateur et des paquets internet qu'il envoit. Pour pouvoir décrypter rapidement un challenge encrypté avec la clé publique, IL FAUT posséder la clé privé et être donc le proprétaire de l'ordinateur TCPA en question. , je peut toujours sortir la clef du coffre depuis windows et la mettre a un endroit ou elle sera accessible depuis linux. j'aimerais bien que tu me dises comment tu fais cette migration, controlée par Windows et donc non disponible si Windows la refuse. Le philosophie et l'intéret de TCPA est que les clés sont générés dans la puce et n'en sortent jamais ! Les opérations de cryptage se ofnt à l'intérieur de la puce. Où as-tu vu dans les specs que on peut les faire sortir de la puce? Concernant le mode "extend" qui n'est pas nié par IBM, tu as oublié cette phrase: "could also prevent the use of “free” operating systems because the OS kernel would have to be signed by a entity which is a descendant of the trusted root" qui ne savent pas ce qu'est l'activation framework de XP dont tu fais partie sinon tu saurais que des modifications matérielles ou logicielles peuvent entrainer la désactivation de XP ! D'où le lien avec le roots of trust de TCPA et son controle de la configuration matérielle et logicielle.