d'abord je constate la confirmation de mon affirmation que tu avais contredite: ensuite je ne suis pas d'accord sur les conclusions de:
CF plus haut dans mes autres posts.
Kha.
P.S : Bien que je comprend ton soucis d'information vis a vis de tes congeneres, je pense que toute les personnes qui lisent encore ce thread au bout de quatre jours, le lise en entier. Inutile donc de reassener 3 fois le meme argument dans tous les sous thread. Ca ne fait que compliquer la discusion.
tout ton rainsonement repose sur le fait qu'il sera obligatoire de donner le controle de TCPA au possesseur du PC. or dans la norme on peut lire qeu cela est "desirable" (je cite).
Non la norme dit que c'est "desirable" d'avoir une methode qui permet de creer un owner sur une puce qui n'en a pas sanst renvoyer le PC a l'usine.
Si je boote sans les droits Owner je ne peut pas faire grand chose avec ma puce. Regarde lasection 7 du doc TCPA. Pour stocker, lire, ecrire, sceller ou migrer une clef j'ai besoin d'avoir une autorisation declaree soit sur l'entite, soit sur la clef elle meme.
Qui cree les entites ? le owner : The creation of the authorization data is the responsibility of the entity owner. (section 5.4 de la doc)
Qui accorde les droits ? Le owner(desole pour le barbarisme a repetiton mais "possesseur" ca me fait bizarre, je suis preneur d'une bonne traduction) : All entities from the Owner to the SRK to individual keys and data blobs have authorization data. This data may need to change at some point in time after the entity creation. The ADCP allows the entity owner to change the authorization data. The entity owner of a wrapped key is the owner of the parent key.(section 5.5 de la doc)
Qui change les droits ?(tous en coeur maintenant) The TPM_ChangeAuth command allows the owner of an entity to change the authorization data for theentity..(section 5.6)
Qui gere le owner ? (attention il n'y a pas de piege) The TPM_ChangeAuthOwner command allows the owner of an entity to change the authorization data for the TPM Owner or the SRK.
Et oui c'est le Owner aussi.
Bref si j'ai pas les droits a la fois sur le SRK et sur le TPM, je peux pas bouger(pas plus que les programmes qui tournent avec mes droits d'ailleurs). Ma puce ne me sert a rien.
Ben oui mais si il n'y a pas de owner du TPM, la puce TCPA ne peut pas fonctionner du tout. Donc elle ne sert a rien. Le but de mon post etait juste de faire une liste des fonctions qui doivent, auraient interet a, et pourraient etre integree dans le BIOS.
Si on me vend un TCPA sans Owner et sans moyen d'en creer un de facon secure (ie avant le boot de l'OS ce qui assure une presence physique), ma puce ne fait rien. Pas de TPM initialise, pas de stockage de clef.
Ce point n'est donc pas du tout un trou de securite, ou une opportunite pour une personne de se servir de TCPA contre toi. C'est juste "desirable" parceque dans le cas ou la creation d'un owner a echouee, sans ce systeme il faut renvoyer la puce a l'usine pour pouvoir s'en servir.
Ah bon, autant pour moi...
Il me semblait qu'avec un reseau de neurones du type de ceux qu'on a utlise pour "predire" la suite du signal lors d'une emission laser, on aurait pu fair eune approche. Mais ce n'est pas mon fort...
Si je devait faire une deuxieme tentative je dirais "hashage stochastique". Mais la c'est encore plus vague pour moi.
enfin, ne pas utiliser les certificats TCPA c'est se priver des documents DRM protégés à l'aide de ces certificats
Nurf ? A ben ca ca serait bien si DRM utilisait les privates CA pour faire de la protection. Vu que les privates CA ne sont pas scellable (on ne peut pas les associer avec un PCR). Hop certificat, et je fais ce que je veux de ma musique.
TCPA est un progrès énorme en matière de DRM puiqu'il permettra d'envoyer des documents lisibles uniquement par une personne dont un organisme "dépendant" connait l'identité.
Pour connaitre mon identite, il faudrait que le mec il est construit mon ordinateur (donc il connait ma EK), il m'est vendu mon ordinateur (donc il me connait), il est validee mon certificat (c'est lui qui a cree la preuve que mon certificat etait valide), il soit mon fournisseur de contenu (c'est lui quime vend les doccuments DRM). La c'est meme plus une conspiration, c'est une ligue mondiale. Le taiwanais en bas de chez moi est un agent a la solde de la DRM. Avant de me vendre une cart mere il releve scrupuleusement le numero de serie....
Relit le doccument en entier (cf traduction faite de ce paragraphe dans un de mes posts).
1)- A moins d'avoir l'ensemble des configurations legales sous la main, DRM ne peut pa sse servir de TCPA pour savoir si la plateforme est valable. TCPA peut enregistrer une config et dire si la config sous laquelle tu es ets bien la meme que celle qu'il a enregistre. Determiner la compliance DRM d'une plateforme devra se faire autement.
2)-Les clefs privees ne sont pas protegees contre une attaque physique dans l'implementation IBM. Stoquer des clefs DRM dans une puce TCPA IBM revient a peu de chose pres a les stoquer en clair sur le disque dur.
Bne vu que la puce est censee pouvoir controle le bios, si le bios peut controler la puce ca fait un gros trou de securite non ? La puce est supposee etre appelable depuis le POST (recommandation, ce n'est pas une obligation) Mais il faut une methode qui autorise une detection d'acces physique a la machine (ie avant le boot os), et qui permette la manipulation d'un certain nombre de paramettre (c'est dans les normes CF un de mes autres posts plus haut).
Si les softs DRM exigent windows pour tourner c'est un autre probleme, ils ne pourront pas s'appuyer sur TCPA pour verifier l'OS. Un certains nombre de test devront etre fait a cote (sur une autre puce ou en logiciel).
Toute clef privee qu'une appli DRM stockerait sur ta puce TCPA (meme si elle est base sur un de tes private CA, meme si elle est scellee sur un PCR) serait en danger. Avec le ddroits owner tu pourrais en effet la migrer du sceau PCR vers une zone non scellee, ou meme cree un blob de migration bidon, et ressortir la clef en clair apres quelques manipulations. A la place de DRM je mettrais mes clefs ailleurs.
question habituelle: numéros de page des docs offcielles TCPA où tu as lu tout ça ?
CF section 4.27 sur le storage et la migration des clefs assymetriques
section 4.30 sur les systemes d'identites
section 6.3 sur l'acces en lecture aux differents repertoires et PCR
section 7.2 sur l'ensemble des fonctions obligatoires pour lire une clef publique, binder une clef, debinder une clef, sealer une clef, liberer une clef, preparer un cryptage de migration d'une clef, crypter une clef avec son blob de migration, autoriser la migration d'une clef etc...
Je ne peux pointer dans la doc TCPA ce qui parle du DRM, vu qu'il n'y a rien.
# less spectcpa | grep -e DRM
#
Rien, que dalle. Si tu penses pouvoir utiliser TCPA pour faciliter la protection DRM, explique moi comment, moi je ne vois pas.
On finit avec le paragraphe IBM
The TCPA chip is not particularly suited to DRM. While it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use, this type of scheme would
be a nightmare for content providers to manage. Any change to the BIOS, the operating
system, or the application would change the reported values. How could content
providers recognize which reported PCR values were good, given the myriad platforms,
operating system versions, and frequent software patches?
Second, the IBM version of the TCPA chip, while evaluated to FIPS and Common
Criteria security standards, has specifically omitted tamper resistance from the evaluation
target. The IBM chip sits on the LPC bus, which is easily monitored. The chip is not
defended against power analysis, RF analysis or timing analysis. The bottom line is that
the physical owner of the machine could easily recover any DRM secrets from the chip.
This apparent lack of security in the chip makes perfect sense when you realize that the
purpose of the chip is to defend the user's data against remote (software) attack. When the
goal is to protect the user's keys and data against external attack, we simply are not
concerned with threats based on the user attacking the chip, as the user already has secure
access to his own data.
Traduction : la puce TCPA n'est pas vraiment adaptee a DRM. Bien qu' elle permette de controller des PCR signes, et que ce type d'information peut etre utilise pour empecher une lecture si l'OS et le lecteur ne sont pas des applications de confiance, ce type de modele serait un cauchemar a gerer pour les fournisseurs de contenu, n'importe quel changement au niveau du BIOS, de l'OS ou de l'applicatif changerait les valeurs. Comment ferait les fournisseurs pour connaitre les bonnes valeurs de PCR parmis la myriade de plateforme, de systemes et les frequentes mise a jour ?
Deuxiemement la puce TCPA d'IBM, pendant l'evaluation vis a vis de FIPS et des Common Criteria security standards, a specifiquement omis la resistance a l'audit de cet evaluation. La puce IBM est place sur le bus LPC qui est facile a surveiller. La puce n'a pas de defenses contre des analyse de puissance, de frequence ou de temporisattion. Au final, un utlisiateur pourrait tres facilement recuperer n'importe quel secret DRM de la puce.
Cette absence aparente de securite dans la puce, devient parfaitement logique quand vous realisez que le but de cette puce est de defendre l'utilisateur contre les attaques (logicielles) a distance. Quand on se concentre sur la protection des clefs et des donnees de l'utilisateur contre des attaques exterieures, on se moque du danger represente par un utilisateur qui attaque sa propre puce, vu que l'utilisateur a deja un acces securise a ses donnees.
Simplement : Si DRM met des clefs privees dans une TCPA IBM, il faudra pas qu'il se plaignent si elle se retrouve expose au grand jour.
je me rappelle avoir lu cela en effet, mais je n'ai plus la page exacte en mémoire. dans ma page free2.org/tcpa/ je donne les références de la page qui précise qu'on peut intégrer TCPA dans une puce qui a d'autres fonctionalités (et il n'est pas interdit que cette puce ait des fonctionnalités de sécurité, y compris des fonctions liées à TCPA)
Il n'est pas non plus interdit de greffer mon controlleur IDE sur une puce qui va empecher le formatage en EXT3 en utilisant ou en bloquant des fonctions de ce controleur. N'empeche que meme si ca se produit ce n'est pas la norme. IDE est innocent si jamais ca se produit.
si c'est le cas, peux tu me dire à quelle page il est dit que le bios doit obligatoirement permettre à l'utilisateur de copier/modifier les clés contenues dans TCPA ?
Pas de creer/modifier/copier des clefs depuis le bios (encore que rine ne l'interdise), mais de s'assurer que l'on puisse passer en mode de controle total du TPM (ie que l'on recupere les droits, meme si ce n'est pas utilisable de suite)
Pardon oublie de ma part, c'est dans la doc TCPA section 2.6.1, page 19 If a TPM does not have an Owner, it is desirable to provide a method that enables or disables the process by which a prospective Owner takes ownership of a TPM. Ideally this method would work both locally and remotely. Unfortunately authenticated commands cannot be interpreted by the TPM if it does not have an Owner. Hence the method of enabling or disabling the process of taking ownership is a local command, and no remote option is provided. (In a PC, these local controls could be made available during the POST, for example.)
La section 2.6.2 indique aussi un certains nombre de mesures a prendre si il n'y a pas d'owner pour le TPM, et suggere un certains nombre de solutions pratiques avant de donner le diagramme general de resolution des etats.
Physical presence authorizes the changing of the TCPA_PERSISTENT_FLAGS -> ownership flag.
Il faut qu'une intervention physique permette d'autoriser les prises de controle du TPM (section 8.13 page 252). La section 8.13.1 nous indique ensuite que si il n'y a pas de owner, il faut que l'on puisse ne creer un moyennant acces physique. (N.B en section 2.6.1 on a vu que la seule facon de s'assurer d'un acces physique etait de rendre les operations possibles seulement avant le boot de l'OS)
Donc avant le boot de l'os je suis Owner du TPM. Ce qui m'autorise a faire tout ce que je veux avec jusqu'a l'extiction de ma machine.
Elle ne l'est pas. C'est clair? ELLE NE L'EST PAS! Windows ZP applique ce procede et "scelle" la fameuse cle avec le PCR courant.
Choisit une de ses deux phrase, celle que tu veux et tu fiches l'autre en l'air.
Si ta clef ne depend pas du harware, et qu'elle est jsute stoquee dans un PCR "brut de fonderie" tu reboote, tu prend les droits owner sur le TPM et tu la copie ou tu veux, tu peux meme la passer en mode migrable et l'envoyer a tes amis.
Si elle est proteger par le PCR (ie encryption supplementaire dependante du boot) on tombe dans les cas que j'ai ennonce plus haut.
moi je cite un document où il est marqué que l'utilisateur n'a pas accès au contenu du random generator
Relit ton doccument il est dit que l'utilisateur n'a pas acces aux etapes intermediaires.
et comme TCPA autorise l'ajout de fonctionnalités par les constructeurs (et par l'auteur du BIOS, je pense), pourquoi une fonctionnalité "protection de toutes les données TCPA" ne serait-elle pas ajoutée ?
TCPA autorise a ce que la puce soit integree a un autre composant. Il y a dans la doc une les fonctions qui doivent etre accessible au boot, a partir du bios et logiciellement sous l'OS. Comme on ne peut pas enlever de fonctions, on est peinard.
Par contre je n'ai pas vu ou il est dit que l'on puisse rajouter des fonctionalites a TCPA. tu peux me filer une reference precise ?
et où as-tu lu que la clé endorsing était copiable ou meme modifiable ? moi j'ai lu qu'il y en avait une seule par puce TCPA et qu'il était juste désactivable. Par conséquent mon raisonement tiens toujours.
La clef endorsment ne peut pas sortir de la puce, elle sert a generer des CA. Je peux generer autant de CA que je veux et cette technique n'est pas inversible.(ie on ne peut pas deduire ma clef de mon CA).
moi j'ai lu qu'il fallait passer par un organisme agréé par TCPA pour obtenir un CA, et qeu cela nécessite l'identification de la clé endorsing et donc ton identification. L'organisme peut donc savoir qui a quel CA.
Presque, il faut passer par le constructeur pour faire changer (ou creer vu que cette clef n'est pas forcement presente) la cle d'endorsment. IBM n'a jamais cree une seule de ces clefs dans son implementation. En ce qui concerne les CA, tu peux en creer a l'infini avec ta clef.Tu ne fais que les faire valider par un organisme, qui ensuite certifie ton ta clef.(cf page 278/section 9.3 du doc TCPA) Le seul et unique vrai probleme vient du fait que tu peux te retrouver a envoyer un CA a une personne qui connais ta clef d'endorsing (ie le constructeur de ton PC ou de ta puce). Celui ci peut alors 'amuser (si il a du temps a perdre) a comparer toutes les clefs d'endorsment qu'il connait avec ton privacy CA. La on est plus dans un complexite exponentielle et il peut donc faire le match entre ton CA et ton PC. Mais c'est le seul cas "dangereux".
Lit la section 9.2 page 271 sur les relations PRIVEK/PUBEK et les securites qui tournent autour. (PRIVEK = private endorsment key, PUBEK=public endorsment key)
Où as-tu lu que le mode extend ne sera pas forcé ? (notamment pour pouvoir utiliser certains softs DRM qui exigerait sa présence...)
1)- Un soft DRM ne peut pas exiger la presence du mode extend. Il peut tester une clef par challenge et voir si elle est disponible ou pas. C'est tout.
2)- Meme si il pouvait forcer le mode extend, rien ne lui indiquerait qu'il s'agit d'un OS DRM, a moins de rentrer des informations supplementaires dans la puce avant de la vendre.
3)- extraits de la doc (divers endroits)
BOOL TPMpost TRUE: the TPM MUST successfully complete
TPM_SelfTestFull before permitting execution of any
command
The default state is FALSE
BOOL TPMpostLock FALSE: The state of TPMpost MAY be changed.
(DEFAULT)
TRUE: The state of TPMpost MUST NOT be changed.
Hop la, meme si mon TPM n'arrive pas a s'autotester (ie verifier qu'il fonctionne correcteemnt, je peux quand meme booter)(cf P48)
Un petit coup d'oeuil sur la section 4.25 te permettrait de comprendre comment le PCR marche.
et pour finir le plus beau
: BOOL disable The state of the disable flag. See 8.14. The default state is
TRUE
Voila de base il n'y a pas de TPM d'active sur la puce. Alors pour le mode extend....
curieux, il me semblait que tout l'intéret de TCPA était dans le fait que la puce TCPA faisait elle-meme les opérations de crypto, et que par conséquent elle ne donnait l'accès à personne aux clés qu'elle protège.
Elle ne donne a personne l'acces de clefs en clair. Elle crypte les clefs avant de te les motrer. Ce qui ne t'empeche en rien de les copier, editer, detruire. Elle ne sont toujours pas accessible, elles sont toujours protegees. Je ne vois pas ou est la contradiction ici.
Pour moi la phrase d'IBM sur le fait qu'on peut écouter le bus d'une puce TCPA qui n'est pas dans le CPU se comrpend comme ceci: la puce TCPA doit décrypter les données protégées par DRM et donc envoyer ensuite ces données en clair au CPU: si j'écoute les donénes en clair qu'elle envoie au CPU alors je peux faire une copie décrypté du fichier DRM.
Les phrases d'IBM se comprenne sans DRM. TCPA ne sait pas ce qu'est DRM il n'en a pas la moidre idee. Il sait crypter, decrypter, analyser une sequence de boot et proteger des clefs.
Au cas ou ca t'interresse la phrase d'IBM veut seulement dire que si tu veux recuperer ta clef publique en clair, tu peux le faire sur leur puce. Tu vois tu es a 100 000 lieux de la verite, je ne vois meme pas par quel raisonement tu as pu passer de l'un a l'autre.
Reformulation d'un de mes posts qui peut preter a confusion.
En fait tu peux creer une trust sur ton kernel. Si dans ton PCR tu demande que le kernel soit compris dans le hashage du boot, tu peux aussi demander a ce que le boot se bloque si ce trust est absent.
Le kernel ne "communique pas" avec TCPA, c'est lors du hashage du kernel que TCPA va se rendre compte tout seul suite a la facon dont le kernel va s'initialiser que c'est un OS digne de confiance ou non(ie si il reconnait une sequence de boot qu'il a deja vu ou pas.). Cette methode est dependante des process de certification et n'est donc pas publique. Par contre on peut parfaitement demander au PCR de laisser l'OS booter, on perd le trust TCPA c'est tout.
kha
vraiment desole pour la confusion que ce post aura pu creer. Mea Culpa.
Je te l'accorde le terme certification est mal choisit. Le probleme vient du fait qu'en francais j'ai du mal a traduire "trusted" (digne de confiance ie certifie) et "certified" (certifie par un tiers).
Ce que je voulais dire c'est qu'on perd le trust TCPA. Rien a voir ave cun certificat delivre par une tierce partie. C'est vrai que ma phrase est tres mal formulee et laisse entendre quelque chose de completement faux. Merci d'avoir releve.
de + les clés ne sortent pas de la puce TCPA, c'est pour cela que la puce TCPA a des focntions de cryptage intégrées. Tu ne peux donc pas utiliser le bus pour accéder aux clés, juste aux fonctions de cryptage qui utilisent ces clés.
Si si elle sorte les clefs. En crypte, mais elles sortent. tu peux les copier, les editer les detruire etc... Tu peux les transferer a une autre puce TCPA (meme si dans le cas des clefs PCR ca ne sert a rien). Bref tu peux faire ce que tu veux a part les lire en clair(En fait c'est meme exactement le but de TCPA etre sur que l'on ne puisse pas te piquer tes clefs.).
donc par une technique de challenge/response (envoi d'un nombre aléatoire crypté qui vient juste d'etre généré, et demande de décryptage de ce nombre par la clé privé)
Oui je peux m'assurer qu'un PC connait la clef privee. Exactement comme en software. Si tu as peur qu'une clef soit utilise contre toi a des fins d'identification tu peux la detruire, exactement comme en software. Je ne vois pas ou est le probleme. Le principe d'une identification challenge/reponse est d'identifier. Ca marche. On le sait depuis longtemps. TCPA n'apprte ni n'enleve rien a ca.
je peux m'assurer de l'identité exacte d'un PC TCPA.
Non je peux savoir que le PC connait la clef privee. Je ne peux pas savoir si c'est un original ou une copie, si je suis toujours sur le meme PC etc...
C'est bien plus dangereux que l'ID des pentiums (qui a été boycotté avec succès)
CF plus haut, pas du tout. ID intel etait incopiable et directement consultable. L'ID TCPA n'est pas directement consultable, il est desactivable et ne sort d'une puce que sous forme de CA a partir desquels il est techniquement impossible de retrouver l'ID. On peut generer autant de CA que l'on veut.
Le but de DRM est bel et bien de s'assurer que certains document ne te sont plus accessibles si tu ne respecte pas certaines règles. Il sera toujours possible de te réenvoyer ces documents si tu prouves que tu as bien payé ta licence (pour rappel les techniques d'activation de XP et le DRM de mediaplayer fonctionne deja sur un principe similaire)
Ben oui mais le controle du respect ou non de ces regles n'est pas faisable en TCPA et devra donc etre completement implemente a cote. De plus vu que l'on peut copier une clef d'un endroit a un autre en TCPA il faudra aussi inventer une solution qui m'empeche lorsque je suis sous windows de copier ma clef hors du PCR, pour l'instant en TCPA rien ne l'interdit.
ce n'est pas ce que dit l'un des createurs de TCPA dans son document qualifié de "très raisonable" par IBM (voir mon article ci-dessus)
Il dit dans son doccument que si le mode extend etait force et impossible a revoquer (ce qui n'est pas du tout le cas) alors il serait possible de creer sur TPM un systeme qui bloquerait les OS non certifies. Cela impliquerait la mise en place de clefs generiques (CF TCPA rebutal) ce qui va contre les normes TCPA.
Au fait c'est un des createurs de TPM, pas de TCPA. Il est "tres raisonable" au sens ou les dangers potentielsqu'il souleve existent, et que ce n'est pas un tissus d'annerie comme la plupart des autres doccuments sur TCPA qu'on voit trainer sur le net.
MS est le seul non fabricant de CPU à faire partie de TCPA
Ils vont peut etre tenter quelquechose, ils ont peut etre tente quelque chose, en tout cas jusque la ca n'a pas marche.
faux: la norme autorise à intégrer TCPA dans n'importe quoi (cf liens dans mon article) y compris le CPU
Et alors ?? Je peux mettre une puce ou je veux tant que je ne change pas ces fonctions. Si j'ai envie de la mettre dans le CPU (pour avoir une fonction RNG native dans mon CPU) ou dans l'horloge (pour avoir un generateur chaotique a porte de main) ca ne change en rien ce qu'elle fait. Si je fiche une carte sonore dans mon contorleur IDE ca me regarde.
Tu ouvres la porte, ils s'installent. Ils te placent leurs cles. Ils s'approprient de l'espace disque, de la RAM, du temps machine. ils la marquent.
Euh, TCPA c'est juste un periph PCI comme les autres au regard du CPU. C'est une espece de port serie a qui on pose des question et qui sort des reponses dans une zone memoire (fixe). Si un mec arrive a prendre le controle de ma becanne rien qu'avec ca, c'est que de toute facon il serait rentre.
tcpa est un cookie monstrueux.
Il y a un numero d'ID dans TCPA, mais il ne peut pas sortir. Tu peux t'en servir pour creer des identites(autant que tu veux toutes differentes), tu peux le rendre illisible logiciellement etc... L'id il ne sort pas de la puce, il sert a la construction de clefs c'est tout, et il n'est pas du tout obligatoire.
Tu ne peux rien faire car si tu décides de désactiver leur puce, ta bécane ne tourne plus qu'en mode dégradé
Ouais elle est degradee ma becanne, par exemple TCPA ne marche plus.... TCPA est un port au regard de l'ordi, je degrade autant ma becanne a enlever TCPA qu'a descativer le port infrarouge de mon desktop.
Qu'est ce qui empêche donc windows de n'accepter de s'installer (puis ensuite de booter) que si le boot est certifié TCPA
Le fait que l'OS ne puisse pas savoir si le boot a ete certifie ou non.
TCPA regarde ce qui se passe au boot (si on le demande explicitement), et en fonction de ca ouvre ou ferme des boites a clefs.
La seule facon qu'il y a pour un OS de se proteger contre un boot est de creer un PCR. Mais le PCR ne regarde pas si la machine est certifie TCPA ou pas, il "enregistre" ce qui se passe lors d'un boot, et ensuite il compare les sequences de boot suivantes avec ce qu'il a enregistre.
Les PCR sont dependant du hardwawre et de la puce TCPA, de plus ce ne sot pas des clefs exportables.
On peut donc imaginer l'inverse : un fabriquant de bios doit montrer patte blanche à MS pour que windows puisse être installé
C'est effectivement parfaitement possible. Pour l'instant ca n'est pas dans les normes(voir meme carrement contre). Pour que ca se produise la seule solution que je vois est la suivante :
1)- On cree de base sur toutes les puces TCPA un PCR qui hashe le bios et le kernel a la recherche de deux sequences particulieres (ce qui est hors norme, le PCR doit etre vide et desactive par defaut, de plus il ne peut pas reagir a une sequence en l'etat)
2)- On installe dans un coffre fort lie a ce PCR une clef generique (ce qui est hors norme, la puce doit etre vide a la base excepte pour la clef fabriquant, les clefs stoques doivent avoir ete genere par la puce et sont donc par essence unique(dans la limite du raisonable) et non generiques)
3)- On place dans les bios et dans les kernels certifies la sequence qui va debloquer la clef.
4)- des parties importantes de l'install sont cryptes avec clef et ne peuvent donc pas fonctionner si la clef n'est pas debloquee.
Comme tu vois TCPA dans son etat actuel ne permet pas ce genre de manipulation, et de plus necessiterait pas mal de modifications pour les accepter. Il ne favorise donc absolument pas ce comportement.
En quoi, cela aide à la sécurité de mes clefs privés ?
Le fait de proteger les clefs privees via un PCR permet d'etre sur qu'un petit malin qui boot sur une disquette ne va pas aller tout recuperer et trente seconde. C'est tout.
Imagine que l'on te vende un fichier de son crypté pour ta machine, Seul un logiciel du bon OS pourra décripter ce fichier.
Pour faire cela, il faudrait soit que le mec qui te vend le fichier son vienne chez toi, soit qu'il possede une copie exacte de ta machine chez lui. La oui il peut t'obliger a booter sous un OS certifie DRM parcequ'il a ete capable de generer une clef PCR compatible avec ta machine. Ca devient techniquement possible. Ca oblige juste le vendeur de son a avoir une copie de toutes les machines "legales" possibles chez lui, ou a envoyer un technicien a domicile a chaque fois que tu veux ecouter une chanson. Un peu lourd non ?
c'est qu'on peut utiliser TCPA tel qu'il est, pour implementer un systeme (par exemple DRM) qui planquent des donnees de facon que l'utilisateur ne puisse jamais y acceder.
Dans TCPA il n'y a pas de donnees auquelles l'utilisateur ne peut pas acceder. Ca n'existe pas, il y a une clef qu'il ne peut pas effacer (mais qu'il peut desactiver), masi il n'y a pas de donnees que tu ne puisse consulter, deplacer, copier ailleurs.
Le schema que tu propose ne tiens pas la route. De deux choses l'une soit la clef est dependante du du schema de boot, soit elle ne l'est pas.
Si elle est dependante du schema de boot la puce TCPA ne va pas utiliser cette clef directement mais utiliser cette clef+un cryptage pour eviter que meme quelqu'un qui connait la clef puisse s'en servir en dehors du "bon" schema de boot. Meme si microsoft te redonne une clef, comme le schema d eboot a changer, le cryptage supplementaire changera : il n'y aura pas moyen d'aller te redonner la clef parceque microsoft ne connait pas le cryptage lie a ton schema de boot.
Pour etre vraiment clair : Ce qui a ete crypte avec un schema de boot ne peut etre decrypte qu'avec exactement le meme schema de boot. Ce qui a ete encrypte sans schema de boot peut etre decrypte par n'importe qui qui possede le pass, independament de l'OS et des changements de hardware.
Oui c'est vrai que les deux facteurs rentrent en ligne de compte. Il y a l'aleatorite et la predictibilite.
Generalement pour s'assurer que les nombres sont generes independament les uns des autres on utilise du chaos (heure qu'il est, uptime, evenements claviers/souris). Mais meme comme ca il est extrement difficile de savoir si oui ou non la clef est inpredictible en fonction de ses antecedents(NB : pas au sens ou l'on connait la clef, au sens ou n peut limiter les domaines dans lesquels elle peut se trouver). C'est effectivement extremement complexe a faire. RSA a mis pres de dix ans a trouver une faille de ce type dans un de ses protocoles (en fait probablement moins, en tout cas ils ont mis dix ans a l'annoncer). On peut par exemple en fonction d'un nombre en deduire que le suivant contiendra au moins un 6, qu'en base 12 certains chiffres seront fixes, qu'une suite de chiffre sera presente dans la clef etc..
Ca c'est clair que c'est vachement baleze a tester. Je pense que meme si on avait le code du RNG (qui j'en suis sur inclut du chaos a un moment ou a un autre) il faudrait un moment pour savoir si les suites sont predictibles.
A ma connaissance la seule methode possible pour tester ca c'est de faire un reseau de neurone monstrueux et de voir si il es capable de deviner la suite. Le seul truc est que ca risque un peu de ressembler a SETI@HOME...
Donc c'est possible, c'est faisable, c'est lourd et c'est long...
Oui certainement le principe de certification actuel n'est pas parfait, n'empeche qu'avoir un organisme independant qui intervient au millieu du processus c'est quand meme plus sur que si chacun peut faire ce qu'il veut.
Si je m'autocertifie cela veut dire que tu dois me faire confiance pour pouvoir me faire confiance. Il y a un hic quelque part.
Maintenant libre a toi de faire confiance (ou pas) a Verisign ou a un autre certificateur. Rien ne t'y oblige, si tu vois un certificat produit par une boite que tu ne juges pas digne de confiance tu le refuse. Point final.
Si tu n'a pas confiance en ta clef TCPA tu la desactive. Pas de differences majeures.
1. la clé endorsing unique dans chaque proc est bien pire que l'identifiant que Intel voulait mettre dans ses pentiums: cela pourra servir à crypter des fichiers DRM qui ne pourront être lus que par un seul ordinateur
Oui bien sur sauf que :
1) Je peux creer un fichier qui ne sera lu que par cette machine. Je ne sais pas si elle respecte le DRM ou si elle va utiliser la le droit de lecture pour faire douze mille copies, mais je peux faire cette limitation. Content.
2) L'id intel passait en clair partout, la clef endorsing sert a generer des CA. Je peux generer une infinite de CA si je veux, personne ne sera jamais qui est l'emetteru principal.
3) Si ca ne me plait pas je peux desactiver cette fonction, c'est d'ailleurs le cas par defaut.
2. la possibilité pour un OS comme windows de crypter des fichiers qui ne peuvent être lus par un autre OS sur la meme machine, c'est pas mal aussi
Oui c'est tres mal, on a vu trois fois deja que c'etait possible mais que ca ficherait MS dedans dans des proportions astronomiques. Pour la derniere fois si je bloque une clef dans le PCR (ie elle ne se debloque que si la sequence de boot est la bonne). Et que je change de sequence de boot, de base je ne peux plus decrypter mes applis. De plus si ca me plait pas d'avoir des clefs liees au PCR Windows je les deplace et basta.
3. le mode "extend" dont parle le créateur critique, qui empeche un OS non signé d'accéder à TCPA, c'est pas mal non plus
Ca n'empeche pas un OS non signe d'acceder aux fonctions TCPA, ca n'empeche pas un OS non signe de booter, ca empeche un OS non signe TCPA de se pretendre signe TCPA. De plus bien que ce soit prevu par la norme il n'y pa pas pour l'instant d'organisme existant capable de "signer" un OS pour TCPA, et il n'est pas dit qu'il y en aura. IBM n'a jamais active cette fonctionalite sur aucune de ses puces parceque ses clients n'en voyait pas l'interet.
4. MS est le seul spécialiste des logiciels à faire partie des fondateurs de TCPA, cela devrait mettre la puce à l'oreille quand aux futures normes TCPA (celles publiées ne sont en rien définitive)
Ah bon ben va falloir le dire a IBM. Je pense qu'ils vont faire vachement la gueule quand on va leur apprendre que les systemes qu'ils ont deja vendu ne sont pas forcement compatible avec TCPA. MS fait partie de tout (meme des normes XML, on raconte qu'on les a vu venir deux fois il y a 3 ans.) c'est leur truc leur politique. Ce que la prochaine norme TCPA sera je n'en sait rien, mais ca m'etonnerais pas mal que IBM et HP laisse MS transformer leur puce en systeme DRM. Et ca ne change rien au fait que pour l'instant il n'y a pas de dangers.
5. les normes TCPA autorisent aussi l'ajout de fonctionalités qui ne sont pas dans les specs: TCPA est alors un cheval de troie pour des fonctionalités plus néfastes comme empecher de booter un OS non signé
Oui, il suffit de recompiler le CPU et hop on a pleins de nouveaux appels. Et puis c'est assez a la mode les normes qui autorisent les trucs qui sont pas dans les normes. A l'heure actuelle TCPA est une puce qui est assise sur un bus et qui regarde les infos passer. en fonction de ca elle ouvre le offre a clef ou pas. Elle ne peut pas empecher l'execution d'un programme, ell ene peut pas formater un disuqe ou supprimer un fichier, elle peut s'ouvrir ou se fermer. Point final.
les documents officiels TCPA et IBM confirment les 5 affirmations ci-dessus, je peux te donner les numéros de page si tu veux
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Kha
(dans une chambre d'echos depuis trois jours)
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
ensuite je ne suis pas d'accord sur les conclusions de:
CF plus haut dans mes autres posts.
Kha.
P.S : Bien que je comprend ton soucis d'information vis a vis de tes congeneres, je pense que toute les personnes qui lisent encore ce thread au bout de quatre jours, le lise en entier. Inutile donc de reassener 3 fois le meme argument dans tous les sous thread. Ca ne fait que compliquer la discusion.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Non la norme dit que c'est "desirable" d'avoir une methode qui permet de creer un owner sur une puce qui n'en a pas sanst renvoyer le PC a l'usine.
Si je boote sans les droits Owner je ne peut pas faire grand chose avec ma puce. Regarde lasection 7 du doc TCPA. Pour stocker, lire, ecrire, sceller ou migrer une clef j'ai besoin d'avoir une autorisation declaree soit sur l'entite, soit sur la clef elle meme.
Qui cree les entites ? le owner :
The creation of the authorization data is the responsibility of the entity owner. (section 5.4 de la doc)
Qui accorde les droits ? Le owner(desole pour le barbarisme a repetiton mais "possesseur" ca me fait bizarre, je suis preneur d'une bonne traduction) :
All entities from the Owner to the SRK to individual keys and data blobs have authorization data. This data may need to change at some point in time after the entity creation. The ADCP allows the entity owner to change the authorization data. The entity owner of a wrapped key is the owner of the parent key.(section 5.5 de la doc)
Qui change les droits ?(tous en coeur maintenant)
The TPM_ChangeAuth command allows the owner of an entity to change the authorization data for theentity..(section 5.6)
Qui gere le owner ? (attention il n'y a pas de piege)
The TPM_ChangeAuthOwner command allows the owner of an entity to change the authorization data for the TPM Owner or the SRK.
Et oui c'est le Owner aussi.
Bref si j'ai pas les droits a la fois sur le SRK et sur le TPM, je peux pas bouger(pas plus que les programmes qui tournent avec mes droits d'ailleurs). Ma puce ne me sert a rien.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Si on me vend un TCPA sans Owner et sans moyen d'en creer un de facon secure (ie avant le boot de l'OS ce qui assure une presence physique), ma puce ne fait rien. Pas de TPM initialise, pas de stockage de clef.
Ce point n'est donc pas du tout un trou de securite, ou une opportunite pour une personne de se servir de TCPA contre toi. C'est juste "desirable" parceque dans le cas ou la creation d'un owner a echouee, sans ce systeme il faut renvoyer la puce a l'usine pour pouvoir s'en servir.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Il me semblait qu'avec un reseau de neurones du type de ceux qu'on a utlise pour "predire" la suite du signal lors d'une emission laser, on aurait pu fair eune approche. Mais ce n'est pas mon fort...
Si je devait faire une deuxieme tentative je dirais "hashage stochastique". Mais la c'est encore plus vague pour moi.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Nurf ? A ben ca ca serait bien si DRM utilisait les privates CA pour faire de la protection. Vu que les privates CA ne sont pas scellable (on ne peut pas les associer avec un PCR). Hop certificat, et je fais ce que je veux de ma musique.
TCPA est un progrès énorme en matière de DRM puiqu'il permettra d'envoyer des documents lisibles uniquement par une personne dont un organisme "dépendant" connait l'identité.
Pour connaitre mon identite, il faudrait que le mec il est construit mon ordinateur (donc il connait ma EK), il m'est vendu mon ordinateur (donc il me connait), il est validee mon certificat (c'est lui qui a cree la preuve que mon certificat etait valide), il soit mon fournisseur de contenu (c'est lui quime vend les doccuments DRM). La c'est meme plus une conspiration, c'est une ligue mondiale. Le taiwanais en bas de chez moi est un agent a la solde de la DRM. Avant de me vendre une cart mere il releve scrupuleusement le numero de serie....
Kha
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
1)- A moins d'avoir l'ensemble des configurations legales sous la main, DRM ne peut pa sse servir de TCPA pour savoir si la plateforme est valable. TCPA peut enregistrer une config et dire si la config sous laquelle tu es ets bien la meme que celle qu'il a enregistre. Determiner la compliance DRM d'une plateforme devra se faire autement.
2)-Les clefs privees ne sont pas protegees contre une attaque physique dans l'implementation IBM. Stoquer des clefs DRM dans une puce TCPA IBM revient a peu de chose pres a les stoquer en clair sur le disque dur.
Bref TCPA ne sert a rien pour le DRM.
Kha
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Si les softs DRM exigent windows pour tourner c'est un autre probleme, ils ne pourront pas s'appuyer sur TCPA pour verifier l'OS. Un certains nombre de test devront etre fait a cote (sur une autre puce ou en logiciel).
Toute clef privee qu'une appli DRM stockerait sur ta puce TCPA (meme si elle est base sur un de tes private CA, meme si elle est scellee sur un PCR) serait en danger. Avec le ddroits owner tu pourrais en effet la migrer du sceau PCR vers une zone non scellee, ou meme cree un blob de migration bidon, et ressortir la clef en clair apres quelques manipulations. A la place de DRM je mettrais mes clefs ailleurs.
Kha
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
CF section 4.27 sur le storage et la migration des clefs assymetriques
section 4.30 sur les systemes d'identites
section 6.3 sur l'acces en lecture aux differents repertoires et PCR
section 7.2 sur l'ensemble des fonctions obligatoires pour lire une clef publique, binder une clef, debinder une clef, sealer une clef, liberer une clef, preparer un cryptage de migration d'une clef, crypter une clef avec son blob de migration, autoriser la migration d'une clef etc...
Je ne peux pointer dans la doc TCPA ce qui parle du DRM, vu qu'il n'y a rien.
# less spectcpa | grep -e DRM
#
Rien, que dalle. Si tu penses pouvoir utiliser TCPA pour faciliter la protection DRM, explique moi comment, moi je ne vois pas.
On finit avec le paragraphe IBM
The TCPA chip is not particularly suited to DRM. While it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use, this type of scheme would
be a nightmare for content providers to manage. Any change to the BIOS, the operating
system, or the application would change the reported values. How could content
providers recognize which reported PCR values were good, given the myriad platforms,
operating system versions, and frequent software patches?
Second, the IBM version of the TCPA chip, while evaluated to FIPS and Common
Criteria security standards, has specifically omitted tamper resistance from the evaluation
target. The IBM chip sits on the LPC bus, which is easily monitored. The chip is not
defended against power analysis, RF analysis or timing analysis. The bottom line is that
the physical owner of the machine could easily recover any DRM secrets from the chip.
This apparent lack of security in the chip makes perfect sense when you realize that the
purpose of the chip is to defend the user's data against remote (software) attack. When the
goal is to protect the user's keys and data against external attack, we simply are not
concerned with threats based on the user attacking the chip, as the user already has secure
access to his own data.
Traduction : la puce TCPA n'est pas vraiment adaptee a DRM. Bien qu' elle permette de controller des PCR signes, et que ce type d'information peut etre utilise pour empecher une lecture si l'OS et le lecteur ne sont pas des applications de confiance, ce type de modele serait un cauchemar a gerer pour les fournisseurs de contenu, n'importe quel changement au niveau du BIOS, de l'OS ou de l'applicatif changerait les valeurs. Comment ferait les fournisseurs pour connaitre les bonnes valeurs de PCR parmis la myriade de plateforme, de systemes et les frequentes mise a jour ?
Deuxiemement la puce TCPA d'IBM, pendant l'evaluation vis a vis de FIPS et des Common Criteria security standards, a specifiquement omis la resistance a l'audit de cet evaluation. La puce IBM est place sur le bus LPC qui est facile a surveiller. La puce n'a pas de defenses contre des analyse de puissance, de frequence ou de temporisattion. Au final, un utlisiateur pourrait tres facilement recuperer n'importe quel secret DRM de la puce.
Cette absence aparente de securite dans la puce, devient parfaitement logique quand vous realisez que le but de cette puce est de defendre l'utilisateur contre les attaques (logicielles) a distance. Quand on se concentre sur la protection des clefs et des donnees de l'utilisateur contre des attaques exterieures, on se moque du danger represente par un utilisateur qui attaque sa propre puce, vu que l'utilisateur a deja un acces securise a ses donnees.
Simplement : Si DRM met des clefs privees dans une TCPA IBM, il faudra pas qu'il se plaignent si elle se retrouve expose au grand jour.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Il n'est pas non plus interdit de greffer mon controlleur IDE sur une puce qui va empecher le formatage en EXT3 en utilisant ou en bloquant des fonctions de ce controleur. N'empeche que meme si ca se produit ce n'est pas la norme. IDE est innocent si jamais ca se produit.
si c'est le cas, peux tu me dire à quelle page il est dit que le bios doit obligatoirement permettre à l'utilisateur de copier/modifier les clés contenues dans TCPA ?
Pas de creer/modifier/copier des clefs depuis le bios (encore que rine ne l'interdise), mais de s'assurer que l'on puisse passer en mode de controle total du TPM (ie que l'on recupere les droits, meme si ce n'est pas utilisable de suite)
Pardon oublie de ma part, c'est dans la doc TCPA section 2.6.1, page 19
If a TPM does not have an Owner, it is desirable to provide a method that enables or disables the process by which a prospective Owner takes ownership of a TPM. Ideally this method would work both locally and remotely. Unfortunately authenticated commands cannot be interpreted by the TPM if it does not have an Owner. Hence the method of enabling or disabling the process of taking ownership is a local command, and no remote option is provided. (In a PC, these local controls could be made available during the POST, for example.)
La section 2.6.2 indique aussi un certains nombre de mesures a prendre si il n'y a pas d'owner pour le TPM, et suggere un certains nombre de solutions pratiques avant de donner le diagramme general de resolution des etats.
Physical presence authorizes the changing of the TCPA_PERSISTENT_FLAGS -> ownership flag.
Il faut qu'une intervention physique permette d'autoriser les prises de controle du TPM (section 8.13 page 252). La section 8.13.1 nous indique ensuite que si il n'y a pas de owner, il faut que l'on puisse ne creer un moyennant acces physique. (N.B en section 2.6.1 on a vu que la seule facon de s'assurer d'un acces physique etait de rendre les operations possibles seulement avant le boot de l'OS)
Donc avant le boot de l'os je suis Owner du TPM. Ce qui m'autorise a faire tout ce que je veux avec jusqu'a l'extiction de ma machine.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Windows ZP applique ce procede et "scelle" la fameuse cle avec le PCR courant.
Choisit une de ses deux phrase, celle que tu veux et tu fiches l'autre en l'air.
Si ta clef ne depend pas du harware, et qu'elle est jsute stoquee dans un PCR "brut de fonderie" tu reboote, tu prend les droits owner sur le TPM et tu la copie ou tu veux, tu peux meme la passer en mode migrable et l'envoyer a tes amis.
Si elle est proteger par le PCR (ie encryption supplementaire dependante du boot) on tombe dans les cas que j'ai ennonce plus haut.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Relit ton doccument il est dit que l'utilisateur n'a pas acces aux etapes intermediaires.
et comme TCPA autorise l'ajout de fonctionnalités par les constructeurs (et par l'auteur du BIOS, je pense), pourquoi une fonctionnalité "protection de toutes les données TCPA" ne serait-elle pas ajoutée ?
TCPA autorise a ce que la puce soit integree a un autre composant. Il y a dans la doc une les fonctions qui doivent etre accessible au boot, a partir du bios et logiciellement sous l'OS. Comme on ne peut pas enlever de fonctions, on est peinard.
Par contre je n'ai pas vu ou il est dit que l'on puisse rajouter des fonctionalites a TCPA. tu peux me filer une reference precise ?
Kha
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
La clef endorsment ne peut pas sortir de la puce, elle sert a generer des CA. Je peux generer autant de CA que je veux et cette technique n'est pas inversible.(ie on ne peut pas deduire ma clef de mon CA).
moi j'ai lu qu'il fallait passer par un organisme agréé par TCPA pour obtenir un CA, et qeu cela nécessite l'identification de la clé endorsing et donc ton identification. L'organisme peut donc savoir qui a quel CA.
Presque, il faut passer par le constructeur pour faire changer (ou creer vu que cette clef n'est pas forcement presente) la cle d'endorsment. IBM n'a jamais cree une seule de ces clefs dans son implementation. En ce qui concerne les CA, tu peux en creer a l'infini avec ta clef.Tu ne fais que les faire valider par un organisme, qui ensuite certifie ton ta clef.(cf page 278/section 9.3 du doc TCPA) Le seul et unique vrai probleme vient du fait que tu peux te retrouver a envoyer un CA a une personne qui connais ta clef d'endorsing (ie le constructeur de ton PC ou de ta puce). Celui ci peut alors 'amuser (si il a du temps a perdre) a comparer toutes les clefs d'endorsment qu'il connait avec ton privacy CA. La on est plus dans un complexite exponentielle et il peut donc faire le match entre ton CA et ton PC. Mais c'est le seul cas "dangereux".
Lit la section 9.2 page 271 sur les relations PRIVEK/PUBEK et les securites qui tournent autour. (PRIVEK = private endorsment key, PUBEK=public endorsment key)
Où as-tu lu que le mode extend ne sera pas forcé ? (notamment pour pouvoir utiliser certains softs DRM qui exigerait sa présence...)
1)- Un soft DRM ne peut pas exiger la presence du mode extend. Il peut tester une clef par challenge et voir si elle est disponible ou pas. C'est tout.
2)- Meme si il pouvait forcer le mode extend, rien ne lui indiquerait qu'il s'agit d'un OS DRM, a moins de rentrer des informations supplementaires dans la puce avant de la vendre.
3)- extraits de la doc (divers endroits)
BOOL TPMpost TRUE: the TPM MUST successfully complete
TPM_SelfTestFull before permitting execution of any
command
The default state is FALSE
BOOL TPMpostLock FALSE: The state of TPMpost MAY be changed.
(DEFAULT)
TRUE: The state of TPMpost MUST NOT be changed.
Hop la, meme si mon TPM n'arrive pas a s'autotester (ie verifier qu'il fonctionne correcteemnt, je peux quand meme booter)(cf P48)
Un petit coup d'oeuil sur la section 4.25 te permettrait de comprendre comment le PCR marche.
et pour finir le plus beau
:
BOOL disable The state of the disable flag. See 8.14. The default state is
TRUE
Voila de base il n'y a pas de TPM d'active sur la puce. Alors pour le mode extend....
Kha
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Elle ne donne a personne l'acces de clefs en clair. Elle crypte les clefs avant de te les motrer. Ce qui ne t'empeche en rien de les copier, editer, detruire. Elle ne sont toujours pas accessible, elles sont toujours protegees. Je ne vois pas ou est la contradiction ici.
Pour moi la phrase d'IBM sur le fait qu'on peut écouter le bus d'une puce TCPA qui n'est pas dans le CPU se comrpend comme ceci: la puce TCPA doit décrypter les données protégées par DRM et donc envoyer ensuite ces données en clair au CPU: si j'écoute les donénes en clair qu'elle envoie au CPU alors je peux faire une copie décrypté du fichier DRM.
Les phrases d'IBM se comprenne sans DRM. TCPA ne sait pas ce qu'est DRM il n'en a pas la moidre idee. Il sait crypter, decrypter, analyser une sequence de boot et proteger des clefs.
Au cas ou ca t'interresse la phrase d'IBM veut seulement dire que si tu veux recuperer ta clef publique en clair, tu peux le faire sur leur puce. Tu vois tu es a 100 000 lieux de la verite, je ne vois meme pas par quel raisonement tu as pu passer de l'un a l'autre.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
En fait tu peux creer une trust sur ton kernel. Si dans ton PCR tu demande que le kernel soit compris dans le hashage du boot, tu peux aussi demander a ce que le boot se bloque si ce trust est absent.
Le kernel ne "communique pas" avec TCPA, c'est lors du hashage du kernel que TCPA va se rendre compte tout seul suite a la facon dont le kernel va s'initialiser que c'est un OS digne de confiance ou non(ie si il reconnait une sequence de boot qu'il a deja vu ou pas.). Cette methode est dependante des process de certification et n'est donc pas publique. Par contre on peut parfaitement demander au PCR de laisser l'OS booter, on perd le trust TCPA c'est tout.
kha
vraiment desole pour la confusion que ce post aura pu creer. Mea Culpa.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Ce que je voulais dire c'est qu'on perd le trust TCPA. Rien a voir ave cun certificat delivre par une tierce partie. C'est vrai que ma phrase est tres mal formulee et laisse entendre quelque chose de completement faux. Merci d'avoir releve.
Kha
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Si si elle sorte les clefs. En crypte, mais elles sortent. tu peux les copier, les editer les detruire etc... Tu peux les transferer a une autre puce TCPA (meme si dans le cas des clefs PCR ca ne sert a rien). Bref tu peux faire ce que tu veux a part les lire en clair(En fait c'est meme exactement le but de TCPA etre sur que l'on ne puisse pas te piquer tes clefs.).
Kha
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Oui je peux m'assurer qu'un PC connait la clef privee. Exactement comme en software. Si tu as peur qu'une clef soit utilise contre toi a des fins d'identification tu peux la detruire, exactement comme en software. Je ne vois pas ou est le probleme. Le principe d'une identification challenge/reponse est d'identifier. Ca marche. On le sait depuis longtemps. TCPA n'apprte ni n'enleve rien a ca.
je peux m'assurer de l'identité exacte d'un PC TCPA.
Non je peux savoir que le PC connait la clef privee. Je ne peux pas savoir si c'est un original ou une copie, si je suis toujours sur le meme PC etc...
C'est bien plus dangereux que l'ID des pentiums (qui a été boycotté avec succès)
CF plus haut, pas du tout. ID intel etait incopiable et directement consultable. L'ID TCPA n'est pas directement consultable, il est desactivable et ne sort d'une puce que sous forme de CA a partir desquels il est techniquement impossible de retrouver l'ID. On peut generer autant de CA que l'on veut.
Le but de DRM est bel et bien de s'assurer que certains document ne te sont plus accessibles si tu ne respecte pas certaines règles. Il sera toujours possible de te réenvoyer ces documents si tu prouves que tu as bien payé ta licence (pour rappel les techniques d'activation de XP et le DRM de mediaplayer fonctionne deja sur un principe similaire)
Ben oui mais le controle du respect ou non de ces regles n'est pas faisable en TCPA et devra donc etre completement implemente a cote. De plus vu que l'on peut copier une clef d'un endroit a un autre en TCPA il faudra aussi inventer une solution qui m'empeche lorsque je suis sous windows de copier ma clef hors du PCR, pour l'instant en TCPA rien ne l'interdit.
ce n'est pas ce que dit l'un des createurs de TCPA dans son document qualifié de "très raisonable" par IBM (voir mon article ci-dessus)
Il dit dans son doccument que si le mode extend etait force et impossible a revoquer (ce qui n'est pas du tout le cas) alors il serait possible de creer sur TPM un systeme qui bloquerait les OS non certifies. Cela impliquerait la mise en place de clefs generiques (CF TCPA rebutal) ce qui va contre les normes TCPA.
Au fait c'est un des createurs de TPM, pas de TCPA. Il est "tres raisonable" au sens ou les dangers potentielsqu'il souleve existent, et que ce n'est pas un tissus d'annerie comme la plupart des autres doccuments sur TCPA qu'on voit trainer sur le net.
MS est le seul non fabricant de CPU à faire partie de TCPA
Ils vont peut etre tenter quelquechose, ils ont peut etre tente quelque chose, en tout cas jusque la ca n'a pas marche.
faux: la norme autorise à intégrer TCPA dans n'importe quoi (cf liens dans mon article) y compris le CPU
Et alors ?? Je peux mettre une puce ou je veux tant que je ne change pas ces fonctions. Si j'ai envie de la mettre dans le CPU (pour avoir une fonction RNG native dans mon CPU) ou dans l'horloge (pour avoir un generateur chaotique a porte de main) ca ne change en rien ce qu'elle fait. Si je fiche une carte sonore dans mon contorleur IDE ca me regarde.
Kha
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Euh, TCPA c'est juste un periph PCI comme les autres au regard du CPU. C'est une espece de port serie a qui on pose des question et qui sort des reponses dans une zone memoire (fixe). Si un mec arrive a prendre le controle de ma becanne rien qu'avec ca, c'est que de toute facon il serait rentre.
tcpa est un cookie monstrueux.
Il y a un numero d'ID dans TCPA, mais il ne peut pas sortir. Tu peux t'en servir pour creer des identites(autant que tu veux toutes differentes), tu peux le rendre illisible logiciellement etc... L'id il ne sort pas de la puce, il sert a la construction de clefs c'est tout, et il n'est pas du tout obligatoire.
Tu ne peux rien faire car si tu décides de désactiver leur puce, ta bécane ne tourne plus qu'en mode dégradé
Ouais elle est degradee ma becanne, par exemple TCPA ne marche plus.... TCPA est un port au regard de l'ordi, je degrade autant ma becanne a enlever TCPA qu'a descativer le port infrarouge de mon desktop.
Kha
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Le fait que l'OS ne puisse pas savoir si le boot a ete certifie ou non.
TCPA regarde ce qui se passe au boot (si on le demande explicitement), et en fonction de ca ouvre ou ferme des boites a clefs.
La seule facon qu'il y a pour un OS de se proteger contre un boot est de creer un PCR. Mais le PCR ne regarde pas si la machine est certifie TCPA ou pas, il "enregistre" ce qui se passe lors d'un boot, et ensuite il compare les sequences de boot suivantes avec ce qu'il a enregistre.
Les PCR sont dependant du hardwawre et de la puce TCPA, de plus ce ne sot pas des clefs exportables.
On peut donc imaginer l'inverse : un fabriquant de bios doit montrer patte blanche à MS pour que windows puisse être installé
C'est effectivement parfaitement possible. Pour l'instant ca n'est pas dans les normes(voir meme carrement contre). Pour que ca se produise la seule solution que je vois est la suivante :
1)- On cree de base sur toutes les puces TCPA un PCR qui hashe le bios et le kernel a la recherche de deux sequences particulieres (ce qui est hors norme, le PCR doit etre vide et desactive par defaut, de plus il ne peut pas reagir a une sequence en l'etat)
2)- On installe dans un coffre fort lie a ce PCR une clef generique (ce qui est hors norme, la puce doit etre vide a la base excepte pour la clef fabriquant, les clefs stoques doivent avoir ete genere par la puce et sont donc par essence unique(dans la limite du raisonable) et non generiques)
3)- On place dans les bios et dans les kernels certifies la sequence qui va debloquer la clef.
4)- des parties importantes de l'install sont cryptes avec clef et ne peuvent donc pas fonctionner si la clef n'est pas debloquee.
Comme tu vois TCPA dans son etat actuel ne permet pas ce genre de manipulation, et de plus necessiterait pas mal de modifications pour les accepter. Il ne favorise donc absolument pas ce comportement.
[^] # Re: Mais quel est l'interret du test PCR !!
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Le fait de proteger les clefs privees via un PCR permet d'etre sur qu'un petit malin qui boot sur une disquette ne va pas aller tout recuperer et trente seconde. C'est tout.
Imagine que l'on te vende un fichier de son crypté pour ta machine, Seul un logiciel du bon OS pourra décripter ce fichier.
Pour faire cela, il faudrait soit que le mec qui te vend le fichier son vienne chez toi, soit qu'il possede une copie exacte de ta machine chez lui. La oui il peut t'obliger a booter sous un OS certifie DRM parcequ'il a ete capable de generer une clef PCR compatible avec ta machine. Ca devient techniquement possible. Ca oblige juste le vendeur de son a avoir une copie de toutes les machines "legales" possibles chez lui, ou a envoyer un technicien a domicile a chaque fois que tu veux ecouter une chanson. Un peu lourd non ?
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Dans TCPA il n'y a pas de donnees auquelles l'utilisateur ne peut pas acceder. Ca n'existe pas, il y a une clef qu'il ne peut pas effacer (mais qu'il peut desactiver), masi il n'y a pas de donnees que tu ne puisse consulter, deplacer, copier ailleurs.
Le schema que tu propose ne tiens pas la route. De deux choses l'une soit la clef est dependante du du schema de boot, soit elle ne l'est pas.
Si elle est dependante du schema de boot la puce TCPA ne va pas utiliser cette clef directement mais utiliser cette clef+un cryptage pour eviter que meme quelqu'un qui connait la clef puisse s'en servir en dehors du "bon" schema de boot. Meme si microsoft te redonne une clef, comme le schema d eboot a changer, le cryptage supplementaire changera : il n'y aura pas moyen d'aller te redonner la clef parceque microsoft ne connait pas le cryptage lie a ton schema de boot.
Pour etre vraiment clair : Ce qui a ete crypte avec un schema de boot ne peut etre decrypte qu'avec exactement le meme schema de boot. Ce qui a ete encrypte sans schema de boot peut etre decrypte par n'importe qui qui possede le pass, independament de l'OS et des changements de hardware.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Generalement pour s'assurer que les nombres sont generes independament les uns des autres on utilise du chaos (heure qu'il est, uptime, evenements claviers/souris). Mais meme comme ca il est extrement difficile de savoir si oui ou non la clef est inpredictible en fonction de ses antecedents(NB : pas au sens ou l'on connait la clef, au sens ou n peut limiter les domaines dans lesquels elle peut se trouver). C'est effectivement extremement complexe a faire. RSA a mis pres de dix ans a trouver une faille de ce type dans un de ses protocoles (en fait probablement moins, en tout cas ils ont mis dix ans a l'annoncer). On peut par exemple en fonction d'un nombre en deduire que le suivant contiendra au moins un 6, qu'en base 12 certains chiffres seront fixes, qu'une suite de chiffre sera presente dans la clef etc..
Ca c'est clair que c'est vachement baleze a tester. Je pense que meme si on avait le code du RNG (qui j'en suis sur inclut du chaos a un moment ou a un autre) il faudrait un moment pour savoir si les suites sont predictibles.
A ma connaissance la seule methode possible pour tester ca c'est de faire un reseau de neurone monstrueux et de voir si il es capable de deviner la suite. Le seul truc est que ca risque un peu de ressembler a SETI@HOME...
Donc c'est possible, c'est faisable, c'est lourd et c'est long...
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Si je m'autocertifie cela veut dire que tu dois me faire confiance pour pouvoir me faire confiance. Il y a un hic quelque part.
Maintenant libre a toi de faire confiance (ou pas) a Verisign ou a un autre certificateur. Rien ne t'y oblige, si tu vois un certificat produit par une boite que tu ne juges pas digne de confiance tu le refuse. Point final.
Si tu n'a pas confiance en ta clef TCPA tu la desactive. Pas de differences majeures.
Kha
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 2.
Oui bien sur sauf que :
1) Je peux creer un fichier qui ne sera lu que par cette machine. Je ne sais pas si elle respecte le DRM ou si elle va utiliser la le droit de lecture pour faire douze mille copies, mais je peux faire cette limitation. Content.
2) L'id intel passait en clair partout, la clef endorsing sert a generer des CA. Je peux generer une infinite de CA si je veux, personne ne sera jamais qui est l'emetteru principal.
3) Si ca ne me plait pas je peux desactiver cette fonction, c'est d'ailleurs le cas par defaut.
2. la possibilité pour un OS comme windows de crypter des fichiers qui ne peuvent être lus par un autre OS sur la meme machine, c'est pas mal aussi
Oui c'est tres mal, on a vu trois fois deja que c'etait possible mais que ca ficherait MS dedans dans des proportions astronomiques. Pour la derniere fois si je bloque une clef dans le PCR (ie elle ne se debloque que si la sequence de boot est la bonne). Et que je change de sequence de boot, de base je ne peux plus decrypter mes applis. De plus si ca me plait pas d'avoir des clefs liees au PCR Windows je les deplace et basta.
3. le mode "extend" dont parle le créateur critique, qui empeche un OS non signé d'accéder à TCPA, c'est pas mal non plus
Ca n'empeche pas un OS non signe d'acceder aux fonctions TCPA, ca n'empeche pas un OS non signe de booter, ca empeche un OS non signe TCPA de se pretendre signe TCPA. De plus bien que ce soit prevu par la norme il n'y pa pas pour l'instant d'organisme existant capable de "signer" un OS pour TCPA, et il n'est pas dit qu'il y en aura. IBM n'a jamais active cette fonctionalite sur aucune de ses puces parceque ses clients n'en voyait pas l'interet.
4. MS est le seul spécialiste des logiciels à faire partie des fondateurs de TCPA, cela devrait mettre la puce à l'oreille quand aux futures normes TCPA (celles publiées ne sont en rien définitive)
Ah bon ben va falloir le dire a IBM. Je pense qu'ils vont faire vachement la gueule quand on va leur apprendre que les systemes qu'ils ont deja vendu ne sont pas forcement compatible avec TCPA. MS fait partie de tout (meme des normes XML, on raconte qu'on les a vu venir deux fois il y a 3 ans.) c'est leur truc leur politique. Ce que la prochaine norme TCPA sera je n'en sait rien, mais ca m'etonnerais pas mal que IBM et HP laisse MS transformer leur puce en systeme DRM. Et ca ne change rien au fait que pour l'instant il n'y a pas de dangers.
5. les normes TCPA autorisent aussi l'ajout de fonctionalités qui ne sont pas dans les specs: TCPA est alors un cheval de troie pour des fonctionalités plus néfastes comme empecher de booter un OS non signé
Oui, il suffit de recompiler le CPU et hop on a pleins de nouveaux appels. Et puis c'est assez a la mode les normes qui autorisent les trucs qui sont pas dans les normes. A l'heure actuelle TCPA est une puce qui est assise sur un bus et qui regarde les infos passer. en fonction de ca elle ouvre le offre a clef ou pas. Elle ne peut pas empecher l'execution d'un programme, ell ene peut pas formater un disuqe ou supprimer un fichier, elle peut s'ouvrir ou se fermer. Point final.
les documents officiels TCPA et IBM confirment les 5 affirmations ci-dessus, je peux te donner les numéros de page si tu veux
Oh oui je veux, la vraiment je veux bien.
Kha