Au forum Intel (IDF), Louis Burns - le directeur de l'Intel CPU-desktop unit, a dévoilé quelques caractéristiques du fameux Prescott (un Pentium 4 gravé en 90 nm avec 1MB de cache L2). Parmi celles-ci on relève une expression énigmatique : "La Grande support".
La Grande est tout simplement le nom marketing version Intel de TCPA (Trusted Computing Platform Alliance) qui, lorsqu'elle est alliée au Palladium de Microsoft, tente de "sécuriser" l'informatique par la certification cryptographiques de programmes autorisés et par la destruction possible à distance des fichiers non certifiés... Avec toutes les dérives que l'on imagine.
Aller plus loin
- L'article dans The Inquirer (4 clics)
- Un autre article de The Inquirer (4 clics)
- TCPA (5 clics)
- FAQ TCPA/Palladium en Français (5 clics)
# Re: TCPA confirmé pour Prescott
Posté par earxtacy . Évalué à 9.
et le processeur dragon de chine ?
[^] # Re: TCPA confirmé pour Prescott
Posté par Jean-Marc Leroy . Évalué à 8.
Y'a encore du boulot. Sans compter que tout sera en chinois là-dedans, ce qui devrait particulièrement aider ces sales chiens d'impérialistes occidentaux à en comprendre le fonctionnement.
Non, je préférerais encore un Amiga :D
Bon, l'est cher, vu le nombre de machines qu'ils comptent produire.
Rendez-vous au CeBit du mois prochain pour en reparler, paraît que l'AmigaOne sera officiellement présenté avec AmigaOS 4 ...
[^] # Re: TCPA confirmé pour Prescott
Posté par Julien CARTIGNY (site web personnel) . Évalué à 10.
Une enfilade entre Beretta Vexée et moi-même sur fr.comp.securité:
http://groups.google.fr/groups?dq=&hl=fr&lr=&ie=UTF-8&a(...)
Une interviews d'un mec d'AMI bios sur slashdot.org:
http://interviews.slashdot.org/article.pl?sid=03/01/17/1430214&(...)
3 docs PDF chez IBM:
http://www.research.ibm.com/gsal/tcpa/(...)
(une collection de liens concernant DRM / Palladium / TCPA est dispo là: http://www.lifl.fr/~cartigny/palladium.html(...) , si vous connaissez d'autres références sérieuses vous êtes le bienvenue. Attention, toutes les URLs ne sont pas à croire absoluement !)
[^] # Re: TCPA confirmé pour Prescott
Posté par Toufou (site web personnel) . Évalué à 4.
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à 3.
"La Grande is the security feature Intel told us about at the last IDF, and includes protection in the CPU, at the platform level, and with software."
c'est un extrait du 2e article de the Inquirer qui ne mentionne pas TCPA
http://www.theinquirer.net/?article=7881(...)
[^] # OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par free2.org . Évalué à 1.
je viens de prendre connaissance de nouveaux liens sur les clés uniques à la fabrication de chaque PC stockées dans TCPA et accessibles uniquement par un OS crypté qui n'est chargé que si le hardware et le boot sont garantis par les clés uniques TCPA
http://www.cypherpunks.to/TCPA_DEFCON_10.pdf(...)
cet OS peut donc contenir des clés secrètes (puisque cryptées avant le boot sécurisé) qui pourront crypter des documents DRM qui seront donc non décryptables par d'autres OS comme Linux (sans compter les lois EUCD et DMCA )
ces slides PDF (visibles avec xpdf) sont confirmées par un document d'un des créateurs de TCPA, nouveau lien donné en bas de la FAQ de ross andersson:
http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html(...)
lui meme confirmé par les specs officielles TCPA (page 12, section 2.2 "trusted roots"): http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
on peut d'ailleurs noter un discours de stallman dans ces nouveaux liens, qui confirme celui d'Eben Moglen sur le danger pour la survie du Libre
nouveaux liens de la FAQ: http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html#additions(...)
Bref, je vais avoir besoin d'aide pour rédiger un article sur ce qui pourrait être le scandale TCPA/IBM
tellement IBM a tenté de nous rassurer en oubliant de mentionner certaines informations cruciales !
PS: pour les fans de TCPA, une manière de m'aider serait d'analyser les slides PDF de cypherpunk et de me dire si elles contiennent une erreur, et laquelle
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Julien CARTIGNY (site web personnel) . Évalué à 1.
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par free2.org . Évalué à 0.
http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html(...)
n'a pas été nié par IBM qui qualifie ce document de "très raisonable"
et ce mode exetnd peut servir à ne booter que des OS trusted
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par free2.org . Évalué à 1.
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Jerome Herman . É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: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par free2.org . Évalué à 1.
Mais tout est dans cette phrase ! Tu as entendu de parler de WIndows XP ? Il oblige à obtenir une nouvelle clé de MS si on change la configuration du PC.
MS va pouvoir utiliser TCPA pour faire la meme chose !
Les clefs privees ne sont pas protegees contre une attaque physique dans l'implementation IBM.
je te propose de relire le titre de cette news: TCPA est à l'intérieur d'un pentium !
qui va pouvoir aller lire pjysiquement à l'intérieur de son pentium ?
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Jerome Herman . Évalué à 1.
Non, deja dit pourquoi :
1) effet immediat - si le boot change, tous les applis cryptees sont inutilisables immediatement, et pas sous 30 jours.
2) sous TCPA le owner peut deplacer les clefs (systeme de migration)
je te propose de relire le titre de cette news: TCPA est à l'intérieur d'un pentium ! qui va pouvoir aller lire pjysiquement à l'intérieur de son pentium ?
Non plus, deja dit aussi : la news dit que le prochain CPU intel supportera les fonctions TCPA. De plus
Burns said that the Prescott would have 13 additional instructions (lien Inquirer 1)
Manque de pot il y a deja treize fonction obligatoires dans TCPA+4 systemes initialisations obligatoires+ une dizaine de fonction de hashage et de cryptage.
Si tu suis le lien inquirer 2 tu verras que les fonctions implementees dans le CPU sont des fonctions FP->int, Videos, et un synchroniseur de processus. Pas du tout TCPA. La puce sera donc HORS du processeur au moins ce coup la.
Kha
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par free2.org . Évalué à 1.
Mais qui t'a dit que toutes les applis seraient cryptées avec TCPA ? relis les mécanismes que j'ai proposé. Tu verras qu'il suffit de crypter avec une clé TCPA des clés (qui ne sont aps des clés TCPA, elles) pour chaque application ou fichier protégé par DRM (et uniquement ces applications là). Si tu changes de config, TCPA bloque l'accès à ces clés, et tu dois à nouveau télécharger ces clés en justifiant que tes paiements sont à jour.
C'est simple et efficace.
sous TCPA le owner peut deplacer les clefs (systeme de migration
Prouve moi que ce système sera forcément accessible au possesseur d'un PC TCPA, n'oublie pas que le mot "desirable" ne signifie pas obligatoire !
Ensuite prouve-moi que ce système permettra de décrypter les fichiers cryptés protégés par PCR, meme si ton PCR a changé.
Enfin il suffit que les fonctions de PCR et de cryptage soient dans un pentium pour que les applications DRM deviennent impossible à controuner.
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Jerome Herman . Évalué à 1.
Kha
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Julien CARTIGNY (site web personnel) . Évalué à 2.
[^] # Re: TCPA confirmé pour Prescott
Posté par syntaxerror . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à 0.
[^] # Re: TCPA confirmé pour Prescott
Posté par Julien CARTIGNY (site web personnel) . Évalué à 0.
ce qui n'est pas assez précis et peut induire en erreur
En effet, j'aurais dû mettre "TCPA != SCP"
il aurait dû être "TCPA sera un élément essentiel de Palladium pour tuer Linux"
Voir les discussions plus bas...
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à 0.
par contre la fonctionalité de blocage d'accès des clés à un OS alternatif est bel et bien dans les specs de TCPA (voir le PDF whyTCPA d'IBM)
il est tout à fait possible, voir probable, que Palladium s'appuiera en grande partie sur TCPA
[^] # TCPA confirmé comme tueur de Linux
Posté par free2.org . Évalué à 7.
[^] # Re: TCPA confirmé comme tueur de Linux
Posté par let antibarbie = xp <- xp - 1 . Évalué à 2.
Enfin, TCPA n'est rien d'autre qu'une puce crypto qui sera standard sur les PC. point. je suis d'accord avec berretavexee sur ce point.
Le risque ? que M$ impose un processeur incluant la crypto pour nous refiler sans derniere version de Windaube... et apres nous imposer le jeu des DRM et tout ... forcement la transition sera facile pour eux si les crypto-chips sont sur tous les PCs. Cela dit ca tuera pas linux.
[^] # Re: TCPA confirmé comme tueur de Linux
Posté par free2.org . Évalué à 1.
voici un extrait du document officiel d'IBM "why tcpa": (page 4 du PDF)
http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
if an attempt is made to boot an alternative system, the PCR value will not match, and the unseal will fail
traduction: si on boote un OS différent [que celui qui a stocké des clés protégés par signature PCR], la signature PCR sera erronée, et le déblocage des clés ne se fera pas
concrètement cela veut dire qu'il est possible pour MS de crypter des documents et des programmes avec des clés TCPA qui ne seront pas
accessibles à Linux. Et une beta récente d'Office sauvegarde les documents dans un format crypté DRM... Il se peut que dans un futur proche
nous soyons tous obligés d'utiliser Windows pour lire la plupart des documents que l'on reçoit, sans possibilité de les transférer sous Linux,
à cause de TCPA !
sans parler de wine qui ne pourra pas exécuter des programmes cryptés par TCPA
[^] # Re: TCPA confirmé comme tueur de Linux
Posté par Jerome Herman . Évalué à 2.
Kha
(qui commence a trouver qu'il y a de l'echo, doit y avoir un truc creux pas loin)
[^] # Re: TCPA confirmé comme tueur de Linux
Posté par doublehp (site web personnel) . Évalué à 1.
Quoi que ... ok on a deja vu pire ... et comme je disais il y a peu ... il suffit que ca passe a la tele, de faire un peu de pub, et la pillule s avale toute seule ...
( enfin j aimerai quand meme bien voire l etat dans lequel serait l angleterre si il fallait les faire conduire a droite du jour au lendemain ... comme disait un ami, fodrait le faire progressivement : d abord que les camions dans une region donnee, en beta-test, puis les camions dans tous le pays .... puis les trains grande ligne, puis les estafettes, et les voitures a la fin ... )
[^] # Re: TCPA confirmé comme tueur de Linux
Posté par Franck Yvonnet . Évalué à 1.
Comme Microsoft Bob, BeOS, ou le Net Computer d'Oracle ? (entre autres grands echecs de l'informatique)
[^] # Re: TCPA confirmé pour Prescott
Posté par jeandubois . Évalué à 6.
t'as raison, ferme les yeux cela fera moins mal.
(désolé de t'incendier, mais la news m'a un peu énervé)
>ou alors je prend le nouvel amiga ;)
Le nouvel Amiga ? celui avec un processeur IBM ? IBM, c'est pas ceux qui se proposent de fournir TCPA pour Linux ?
Quand à ceux qui vont dire AMD, je leurs rappel qu'AMD a aussi signé pour inclure TCPA direct dans le cpu.
En clair, Intel, AMD et IBM (Amiga et Mac) sont déjà dans le même bateau.
J'ai l'impression qu'il va nous rester plus que le C3 de VIA, bouhou.
Il faut que l'on trouve notre "José Beauvais" de l'informatique et qu'on le suive détruire tous les camions de cpu contaminé qui vont rentrer dans notre beau pays, le tout en chantant la Marseillaise bien sur.
Pu... que je suis gaché.
[^] # Re: TCPA confirmé pour Prescott
Posté par jigso . Évalué à 6.
[^] # Re: TCPA confirmé pour Prescott
Posté par kb . Évalué à 3.
Et Motorola (qui fabrique des PPCs aussi comme IBM), NVidia .... Par contre à ma connaissance ATI n'en fait pas parti (du moins pas encore :\), ni les fabricants de SPARC, dont j'ai oublié le nom ....
Le hardware libre devient de plus en plus pressant ....
[^] # Re: TCPA confirmé pour Prescott
Posté par doublehp (site web personnel) . Évalué à 1.
Moi ji dis ... nos papis ils distilaient la nuit, nous on va souder la nuit ...
# Et moi alors !?
Posté par One . Évalué à 3.
J'avais abordé le sujet dés son annonce, et tout le monde s'en foutait, en disant que c'etait pas possible : http://linuxfr.org/2002/09/18/9639.html.(...) Intitulé "la Grande Technology est lancée". Ya meme un gus qui s'était foutu de moi pour le choix du titre.
Ben, nous y voilà. Et on fait quoi maintenant. Ahhhh.... on rigole moins là !
[^] # Re: Et moi alors !?
Posté par Jean-Marc Leroy . Évalué à 2.
[^] # Re: Et moi alors !?
Posté par Nuks . Évalué à 6.
[^] # Arghhhhhh, un point meurtier !
Posté par One . Évalué à 1.
Je vous donne ci-après la bonne adresse : http://linuxfr.org/2002/09/18/9639.html(...)
Hehehe, pas de point cette fois, non mais !
[^] # Re: Arghhhhhh, un point meurtier !
Posté par patrick_g (site web personnel) . Évalué à 3.
# Re: TCPA confirmé pour Prescott
Posté par notrya2 . Évalué à -1.
[^] # Re: TCPA confirmé pour Prescott
Posté par huhuhu . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par Backbone . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par A-Wai . Évalué à 2.
Même AMD a annoncé qu'ils supporteraient les "specs" TCPA...
> Acheté autre chose même si c'est plus cher
Perso je passerais bien chez la Pomme, mais c'est quand meme _vraiment_ plus cher :-(
[^] # Re: TCPA confirmé pour Prescott
Posté par Backbone . Évalué à -2.
[^] # Re: TCPA confirmé pour Prescott
Posté par huhuhu . Évalué à 0.
[^] # Re: TCPA confirmé pour Prescott
Posté par Backbone . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par patrick_g (site web personnel) . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par notrya2 . Évalué à 9.
Si le message est passé que les gens ne veulent pas du palladium, Intel ou AMD même si temporairement n'ont que du palladium a proposer, vont peut-être proposer des cpu non-palladium pour prendre des parts de marché au concurrent. De plus, Intel ne va pas changer toute sa game de cpu pour du uniquement palladium. Si durant la phase transitoire d'adoption de palladium les cpu palladium se vendent mal, Intel va réfléchir sérieusement avant de ne proposer que du palladium.
[^] # Re: TCPA confirmé pour Prescott
Posté par Jean Roc Morreale . Évalué à 2.
[^] # Re: TCPA confirmé pour Prescott
Posté par jeff110 . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par Alberto . Évalué à 5.
[^] # Re: TCPA confirmé pour Prescott
Posté par Toufou (site web personnel) . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par okhin . Évalué à 4.
# D'autres cpu?
Posté par Dalton joe . Évalué à 2.
[^] # Re: D'autres cpu?
Posté par Dalton joe . Évalué à 1.
http://www.openbrick.org(...)
[^] # Re: D'autres cpu?
Posté par Backbone . Évalué à 1.
[^] # Re: D'autres cpu?
Posté par Alberto . Évalué à 1.
[^] # Re: D'autres cpu?
Posté par matiasf . Évalué à 4.
- "threw out all the good parts of the x86 because people thought those parts were ugly. They aren't ugly, they're the 'charming oddity' that makes it do well."
J'ai bossé sur des stations de travail HP, Alpha et Sun. Ben les x86 que j'avais à la maison (pII, k6-2, athlon) m'ont toujours impressionné par leur performance. Le pire étant HP, l'Alpha avait de belles perfo en calcul.
[^] # Re: D'autres cpu?
Posté par CopainJack (site web personnel, Mastodon) . Évalué à 5.
# Re: TCPA confirmé pour Prescott
Posté par xcoder_nux . Évalué à -1.
# Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee . Évalué à 10.
[^] # Re: TCPA confirmé pour Prescott
Posté par Julien CARTIGNY (site web personnel) . Évalué à -1.
[^] # Re: TCPA confirmé pour Prescott
Posté par TSelek . Évalué à 2.
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . Évalué à 10.
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à 6.
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . Évalué à 7.
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à 4.
c'est deja dur de convertir des gens "normaux" à Linux sans TCPA, avec TCPA cela rique de devenir impossible...
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . Évalué à 7.
Apparemment on a un gros probleme de comunication toi et moi.
TCPA en tant que tel ne changera rien a la compatibilite entre Windows et Linux. Si je choisis de crypter un doccument sous Office en mode exclusif, non seulement mon Linux ne peut pas le lire, mais aussi n'importe quel autre PC sous n'importe quel OS (windows compris) ne peut pas le lire non plus, parceque la clef elle est dans ma puce, et comme c'est une clef de protection (type 1) je ne peux pas la redistribuer.
Par contre si je veux pouvoir utiliser ce doccument sur d'autre PC ou avec d'autre OS il faudra que je crypte mon logiciel avec une clef de type identitaire (type 2) ou d'autehntification (type 3) qui elles sont distribuable et ne dependent ni de l'OS, ni du programme, ni de la config hardware (ce qui est parfaitement logique vu que ces clefs sont faites pour permettre un echange de donnees.)
J'irais meme jusqu'a dire au contraire, a l'heure actuelle l'algo qui est utilise par MS pour le cryptage des donnees est proprietaire et protege (RSA 4 si ma memoire est bonne), et Open Office ne peut pas ouvrir les doccuments cryptes par cette methode(il gere les protections mais pas le cryptage).
A l'inverse si Office utilise le systeme de cryptage TCPA, alors un doccument crypte en type2 ou type3 sera tres facile a decoder vu que l'ensemble des fonctions seront deja implementee en hardware par la puce. Il n'y aura qu'a les invoquer dans OOo (Et on a deja le code GPL pour le faire, merci IBM) et le tour est joue.
TCPA ne change rien a ce niveau la, voir meme facilite la vie.
Kha
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à 3.
De même si certains exécutables windows deviennent par défaut cryptés par une clé TCPA non accessible, alors il sera impossible de les exécuter sous Wine
(on a un problème de compréhension, en effet)
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à 3.
voici un extrait du document officiel d'IBM "why tcpa": (page 4 du PDF)
if an attempt is made to boot an alternative system, the PCR value will not match, and the unseal will fail
traduction: si on boote un OS différent [que celui qui a stocké des clés protégés par signature PCR], la signature PCR sera erronée, et le déblocage des clés ne se fera pas
concrètement cela veut dire qu'il est possible pour MS de crypter des documents et des programmes avec des clés TCPA qui ne seront pas
accessibles à Linux. Et une beta récente d'Office sauvegarde les documents dans un format crypté DRM... Il se peut que dans un futur proche
nous soyons tous obligés d'utiliser Windows pour lire la plupart des documents que l'on reçoit, sans possibilité de les transférer sous Linux,
à cause de TCPA !
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . Évalué à 7.
nous soyons tous obligés d'utiliser Windows pour lire la plupart des documents que l'on reçoit, sans possibilité de les transférer sous Linux,
à cause de TCPA !
C'est justement ca que tu ne comprend pas, si c'etait le cas je serais de tout coeur avec toi contre TCPA, mais l'exemple que tu donne est incoherent.
Il y a trois mode de cryptage dans TCPA qui correspondent a trois besoins differents.
---Le premier mode est un mode securitaire paranoiaque. Si un fichier est crypte avec ce mode seule la machine qui a crypte ce fichier, avec l'os qui a crypte ce fichier et le hardware intouche peut decrypte ce fichier. En d'autre terme pour lire un fichier cryptee en type1 (je ne sais pas si c'est l'appellation officielle mais elle est utilisee sur pas mal de brochures) il faut la machine, l'OS et le Hardware et les references TCPA.
Un fichier crypte par ce mode est completement illisible pour n'importe quel autre systeme sous n'importe quel autre ordi. A la limite si tu te fait un dual boot Windows/Windows sur ta machine (avec deux install windows strictement identiques) ton deuxieme Windows sera incapable de lire un doccument crypte avec le premier(Meme hardware, meme install, mais les attributions TCPA ne sont pas les memes donc le coffre ne s'ouvre pas pour cette clef).
Je ne sais meme pas si ca marcherait en faisant un ghost de ton disque et en remplaceant le disque original par une copie.
Si quelqu'un t'envoit un jour un fichier crypte comme ca, tu peux installer windows, office et rencontrer personellement Balmer, tu ne pourras pas ouvrir ce fichier. Point final.
---Le deuxieme mode est un mode d'identification d'identites. Il permet de m'assurrer que la personne en face de moi est bien qui elle pretend etre, ou que la personne qui consulte tel ou tel doccument est bien habilitee a le faire. C'est un principe de clefs assymetriques tout ce qu'il y a de plus courant,sauf qu'il est gere en hardware. Dans ce cas la on se moque de savoir quel est ton hardware, ton OS, ta religion et la couleur de tes chaussettes. La seule question est "Est-ce que tu connais le code ?" si oui on echange la clef et tu peux lire le doc, si non ca s'arrette la.
---Le troisieme mode est une sorte de mix des deux autres. Le but du jeu est ici d'identifier un ordinateur avec un niveau de paranioa reglable qui va de "oui c'est bien le bon processeur" (ie c'est une machine que je connais meme si on a change son os, son disque dur ou le nom de l'utilisateur). A oui c'est l'exacte configuration que je connais. En mode 3 tu generes ta clef avec le degre de paranoia que tu veux et tu l'envois au certificateur. Celui ci n'a aucun moyen de savoir quel OS tu utilise a partir de la clef que tu lui a envoye. Donc quand il va crypter les donnees en utilisant cette clef, il va le faire de facon independante de l'OS. Et quelque soit l'OS qui ait envoye la clef, il pourra decrypter le message.
Mais si une personne veut t'envoyer un doccument crypte avec l'espoir que tu le lise (et pas seulement pour avoir une copie ailleurs que sur son dur) il est oblige d'utiliser le deuxieme ou le troisieme mode. Or rien dans TCPA ne permet de faire de segregation, Ca marche, ou ca ne marche pas, il n'y a pas de si. Il n'y a pas moyen de dire on peut ouvrir le fichier avec mot de passe SI l'OS est windows(methode 2). Pas plus que l'on peut dire en methode 3 on peut ouvrir le fichier sur ce PC si l'OS est windows. On peut verifier que la config n'a pas changee depuis l'emission des clefs, mais pas bloquer le decodage d'un fichier si ce n'est pas le cas.
En d'autre termes si un copain t'envoit un fichier crypte depuis windows et que tu ne peux pas l'ouvrir, ce n'est pas la faute de TCPA.
Kha
[^] # TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . Évalué à 2.
dès lors les fichiers ainsi cryptés deviennent inaccessibles à un autre OS en dual boot sur le meme machine.
cet OS ne peux donc plus accéder aux fichiers obtenus sous Windows, et wine ne peut pas exécuter des binaires protégés par le mode parano de TCPA
PS: peux tu me donner des liens vers tes sources, moi j'ai donné un lien vers ma source IBM
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Euclide (site web personnel) . Évalué à 5.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . Évalué à 0.
dans un format de fichier spécifique à MS
une fois arrivé chez ce quelqu'un, le soft MS s'empressera de rajouter une couche de crypto TCPA pour que seul Windows puisse maintenant y accéder, meme si ton copain connait le format de fichier spécifique à MS
(format que les lois DMCA et EUCD t'empecheront de violer)
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Beretta_Vexee . Évalué à 5.
Je vois pas ce que TCPA vient changer a l'affire, si ils ne veulent pas que leurs document soit accesible par une application tiers, ils peuvent déjà le faire.
Pour info ca m'etonnerait un peut que microsoft utilise TCPA alors qu'ils veulent imposer leur systéme Palladium qui marche un peut leur platebande depuis qu'ils ont prit pour eux le terme d'informatique de confience.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par let antibarbie = xp <- xp - 1 . Évalué à 2.
je voudrais ajouter cependant que je ne suis pas entierement certain que le mode "parano" tel que décrit plus haut réagisse de la façon décrite plus haut, en effet je vois pas comment le driver TCPA communiquerait a la puce de façon sécurisée l'OS actuellement utilisé. Apres tout le driver Linux pourrait très bien dire a la puce "je suis Windows" et vice-versa... (prouvez moi le contraire ?)
Ce qui réduit la limitation du mode parano à "la même machine, dual boot compris"..
(mais si on boote sur un CD ca marche plus !)
Cela dit je sais pas si ca va pas faire chier tout ca avec les multiples re-installations de Lilo qu'il peut nous arriver de faire si touche de près au kernel.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 1.
En fait 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 certifie ou non. 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 la certification TCPA c'est tout.
kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par let antibarbie = xp <- xp - 1 . Évalué à 1.
Heu attend j'ai tout à coup l'impression d'être passé quelques temps en arrière vis à vis des FUDs concernant l'amalgame TCPA/palladiüm.
C'est koi cette histoire de certification d'OS ??
Pour utiliser TCPA, il faut le driver TCPA, point. La puce s'auto-protège si elle ne reconnait pas les données de boots hachées ... au premier boot par exemple. Ca empeche d'utiliser les clefs existant sur la puce (c'est normal). Ben alors tu fait un reset de la puce avec ton nouveau systeme et hop.. ca marchera désormais.. avec de nouvelles clefs.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 . Évalué à 5.
dès lors les fichiers ainsi cryptés deviennent inaccessibles à un autre OS en dual boot sur le meme machine.
Oui sauf que seul probleme si ils font ca tu ne peux plus acceder a ce fichier autrement que sur ta config actuelle. Tu ne peux plus le diffuser, le lire sur un autre PC, le reouvrir si tu change quoi que ce soit en hard sur ta machine etc..
En d'autres termes ce fichier deveint hyper confidentiel. Plus personne ne peut s'en servir a part toi sur ta machine avec ton hardware. Ca m'etonnerais beaucoup que ce comportement soit active par defaut.
Mes sources sont les memes que les tiennes je pense. Mais bon les voila quand meme :
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?
Ca ca vient de ton doccument favori. Pour ceux qui ne maitrise pas l'anglais il est dit qu'il est theoriquement possible d'utiliser TCPA pour bloquer la diffusion de doccuments DRM, a condition bien sur de connaitre la clef de boot de tous les systemes "Legaux". En d'autres termes d'avoir la collection complete de toutes les configs hardware et software imaginables (bon seulement celle qui respectent le DRM) et de la mettre a jour regulierement. Bonne chance a qui veux essayer, moi je regarde :).
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.
Ca aussi d'ailleurs ca vient du doc que tu site a tour de bras (et qui curieusement dit exactement le contraire de ce que tu entends). Ici il est dit que moyennant des connaissaances electroniques de base il est possible d'aller recuperer en clair l'ensemble des clefs stoquee sur la puce a condition d'avoir un acces physique a la machine.
-"Oh ben ma clef elle est toute bloquee dans mon ancien PCR, et je peux pas la lire.
-"C'est pas grave mon petit on va aller te la chercher ta clef. Tiens la voila. Bon je te la copie dans la zone publique comme ca la prochaine fois que tu change de carte video ca se passera bien
-"Merci monsieur
Aller hop on enchaine sur
http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
La on a toute l'algorithmique que j'ai decrite grossierement plus haut. Et si on s'y connait un peu on se rend compte que savoir si telle ou telle clef a ete generee avec un OS windows ou Linux est impossible. C'est encore moins facile pour le PRC que pour quoi que ce soit d'autre.
10.4.5 Creating a PCR composite hash
The definition specifies the operation necessary to create TCPA_COMPOSITE_HASH.
Action
The hashing MUST be done using the SHA-1 algorithm.
Dans SHA-1 il y a 160bits dont 80 bits de de codage et 80 bits de donnees. C'est clair que sur 10 caractere il va y avoir le nom de mon os, le modele de ma carte graphique, savoir si il y a un autre OS a cote etc..
Ben non une fois le PRC genere pour une selection de composant c'est completement irreversible. On peut recalculer pour la meme selection et voir si rien n'a change, mais pour savoir ce qui est installe en partant du PRC bonne chance !!!
La phrase qui te fait si peur :
The "trusted" boot functions provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence.
Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has backdoored the operating system, the PCR value will not match, and the unseal will fail, thus
Ne veut pas dire que un OS peut aller sans que tu le sache crypter des docs et des executables pour etre sur que tu ne t'en serve pas sous un autre systeme. Pour etre exact c'est meme exactement le genre de chose dont TCPA te protege. Si Windows a l'install te locke des executables avec des clefs basees sur le PCR (ce qui veut deja dire que windows est un executable qui s'autocertifie vis a vis de TCPA ce qui me semble impossible vu la doc).
1) Il se tire une vache de balle dans le pied. Parceque TCPA c'est pas comme le systeme de protection actuelle, c'est pas dans 30 jours, c'est tout de suite. J'ai flashe mon bios ? Tous les outils proteges par clef sont bloques. Qu'est ce que je peux faire ? Rien sauf si je connais l'astuce.
2) Il est possible de facon logicielle et de facon materielle de changer les clefs de place.(Et heureusement d'ailleurs il manquerait qu'un serveur de donnees critiques soit completement out parce qu'un des disques raid a lache). Le vilain windows il a mis des clefs dans un PCR, bon ben on va les copier dans l'autre alors (Voir meme on va les mettre en acces hors PCR).
Le but du PCR n'est pas de surveiller ce que tu fais mais d'empecher des programmes d'avoir acces a tes donnes et applications critiques. A la limite on peut se sevir de TCPA pour empecher Windows de changer le boot record a l'install.
Si ils respectent les normes qu'ils se sont eux-memes fixes il n'y a vraiment aucun danger.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . Évalué à 1.
un des créateurs de TCPA convient que la norme actuelle est inacceptable:
http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html(...)
il suffit de regarder le début des specs officeille TCPA, page 12, section 2.2
"trusted roots" pour voir que voir que le but de TCPA est tres proche de l'activation framework de Windows XP qui permet de s'assurer que seul celui qui a payé la licence d'un fichier a accès à ce fichier
http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 2.
Le premier point sur le trusted root est en effet assez sensible, creer des organismes de certification capable generer un nouveau trusted root risque de ne pas etre evident. De plus ces organismes auront besoin pour creer ce root d'un grand nombre d'information vous concernant (le numero de serie de votre CPU, de votre Bios et le degree de conformite de votre machine a TCPA). Toutes ces informations leur permettront 1- de savoir exactement qui vous etes, 2-de creer a volonte un trusted root capable de tourner sur votre machine (et donc d'acoir un acces total sur toutes vos clefs). Mettre a disposition un outil capable de creer un trusted root risque donc de faire autant de mal que de bien. Mais le probleme avec le trusted root ne vient que si un utilisateur n'a pas le controle sur ses PCR, IE si je ne peut pas determiner quelles serie de composants sont necessaire au boot. Dans l'implementation actuelle on peut au contraire creer autant de PCR que l'on veut et ce base sur les infos que l'on veut. On peut en faire un qui boot a tous les coups, un qui exige la presence de telle ou telle carte PCI ou disque dur, un qui exige que tout soit rigoureusement identique etc... Si on enleve ce droit alors la oui on aura un probleme. Mais ce n'est pas le cas.
Comme le dit l'auteur du texte :
This, coupled with the inability to disable the extend capability, would prevent anyone from running an operating system of their choice.
Pour l'instant non seulement on peut desactiver le mode extend (ie tout doit etre TCPA certified), mais on peut meme choisir ce que l'on veut verifier. Il faut donc faire tres attention a ce point, mais pour l'instant ca va.
Je ne peux pas creer mon propre trusted root, mais j'ai des droits complets dessus (je peux meme aller chercher les clefs physiquement si ca me chante cf plus haut)
Je ne peux pas desactiver TPM mais je peux creer un PCR qui ne verifie rien. Je suis d'accord que ce n'est pas l'ideal, mais le choix contraire poserait au moins autant de probleme et remttrait en cause l'utilite de TCPA.
En ce qui concerne le troisieme point c'est assez vrai. Si je me place en mode trust, je prend pas mal de risque de me faire cibler, c'est a dire qu'un organisme regroupant les clefs identitaires de plusieurs machines serait capable de faire fusionner plusieurs de mes identites (par exemple de savoir que deux pseudos sont en fait une seule et meme personne.) Quand je veux echanger des clefs avec quelqu'un en TCPA je fais appel a une tierce personne (trust third party). Si je fait souvent appel a la meme boite, elle risque de pouvoir suivre mes habitudes sur le net. De plus si cette personne est aussi emettrice de certificat elle risque de pouvoir faire un recoupement complet sur mon identite. Il est clair que ceci pose un probleme d'anonymat sur le net. Bon outre le fait qu'une personne qui decide de vous retrouver a tous les moyens pour le faire aujourd'hui, il est vrai que d'avoir un organisme capable de savoir qui l'on est et ce que l'on fait sur le net est assez deplaisant (meme si on est deja loin du probleme pose par la possibilite ou non de booter son OS favori). Il a ete clairement defini qu'un certificateur ne pouvait pas etre un third party trust. Mais techniquement rien ne l'empeche. Seul petit probleme, a moins de s'echanger les clefs TCPA de la main a la main comme on s'echange aujourd'hui les clefs GnuPG il n'y a pas d'autres solutions. Par contre n'importe qui peut jouer le role de third party trust. Donc on aurait plutot besoin au contraire du support du libre au maximum. En effet il suffit de multiplier le nombre de third party trust pour que le recoupement de donnees devienne improbable. Reste a voir si c'est implementable, j'y jette un oeuil ce soir.
Ceci etant cet article ne fait pas non plus mention de danger immediats, juste de dangers potentiels. De plus sur les 5 suggestions qui sont faites, 2 ont deja ete realisees (4 et 5), une est irrealisable (3) une est dangereuse (1) et une pourrait effectivement etre un plus et a d'ailleurs ete envisagee par Intel (2).
il suffit de regarder le début des specs officeille TCPA, page 12, section 2.2 "trusted roots" pour voir que voir que le but de TCPA est tres proche de l'activation framework de Windows XP
Oui extremement proche, pour ne pas dire quasiment identique. A un detail pres : c'est l'utilisateur qui est aux commandes. Si j'ai envie de controler ce qui tourne sur ma machine, et d'empecher tout ce que je n'ai pas controle de tourner, c'est mon probleme. Parce que c'est moi qui decide. C'est exactement ca le but de TCPA et je ne vois pas le mal. Pour que cela se retourne contre l'utilisateur et l'empeche de faire quelquechose, il faudrait rajouter un grand nombre de limitations a ce qui existe a l'heure actuelle
-il faudrait enlever la possibilite de creer des PCR
-il faudrait enlever la possibilite de deplacer/copier les clefs
-il faudrait que l'ensemble des PCR/TPM crees avec les truted root exigent un systeme certifie jusqu'a la garde...
Pour l'instant on en est pas la, et heureusement.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . Évalué à 1.
d'après les slides http://www.cypherpunks.to/TCPA_DEFCON_10.pdf(...)
des clés uniques à la fabrication de chaque PC sont stockées dans TCPA et accessibles uniquement par un OS crypté qui n'est chargé que si le hardware et le boot sont garantis par les clés uniques TCPA
cet OS peut donc aussi contenir des clés secrètes (puisque cryptées avant le boot sécurisé) qui pourront crypter des documents DRM qui seront donc non décryptables par d'autres OS comme Linux (sans compter les lois EUCD et DMCA )
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 3.
Si tu te bases sur ce doccument pour te faire ton idee de TCPA tu peux effectivement paniquer.
Ces slides pretendent que la puce est "tamper proof" ce qui est completement faux, elle est completement accessible tant au point de vue hardware que software. On y apprend aussi que la puce TCPA va servir a faire respecter le DRM (ce qui est impossible cf mes posts precedents) et meme qu'elle possede un DRM check au boot(on en apprend tous les jours). Il ne faut pas croire tout ce que tu trouves sur internet....
des clés uniques à la fabrication de chaque PC sont stockées dans TCPA et accessibles uniquement par un OS crypté qui n'est chargé que si le hardware et le boot sont garantis par les clés uniques TCPA
Ces clefs ne sont pas accessibles par un OS crypte mais par un OS certifie. C'est le trusted root dont on parlait plus haut. Ces clefs ne sont la que pour s'assurer avant de delivrer un certificat TCPA, que ton ordinateur est bien capable de delivrer ce certificat. Donc
1) - Cette clef ne gene que les echanges de clefs avec une tierce partie , elle n'entrave en rien le fonctionnement de TCPA en mode "coffre fort", meme sans un systeme 100% pur TCPA on peut quand meme creer des clefs et des PCR a volonte, par contre on ne peut pas les distribuer.
2)- Elle n'empeche en rien le boot ou l'utilisation d'un OS ou d'applics non certifies. Elle n'empeche pas non plus d'utilser les fonctions TCPA non certifiantes.
3)- Sans cette clef des systemes possedant juste un chipset TCPA pourraient se pretendre Full TCPA Compliant, et donc de mentir sur le niveau de securite dont il dispose effectivement.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Ce qui est complètement faux CHEZ IBM et pour l'instant ! TCPA n'est qu'une norme papier.
Les truc tamper résistant sont attaqués en "ouvrant" la puce et en manipulant certains signaux. Une url sur une doc était paru sur dlfp.
Si la puce tcpa est noyé dans un cpu type x86, la complexité, le mélange des fonctions, fait que les attaques hardwares vont devenir super hasardeux ! Et qui veut tenter "d'ouvrir" son cpu à 200eur pour avoir une chance d'avoir les clefs ?
"La première sécurité est la liberté"
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 1.
Presenter un fait probable (ie l'integration eventuelle par Intel de la puce dans un CPU rendant son audit difficile), comme une obligation est un raccourci dangereux.
De pus le fait que le nouveau CPU d'intel supporte TCPA veut seulement dire une chose : il possedera un module d'authentification TCPA (ie il sera certifie TCPA). Vu la course a la vitesse en ce moemnt et les problemes qu'ont les fondeurs a faire tenir toutes les fonctions desires dans un cpu, on peut penser qu'Intel ne va pas "gacher" des transistors betement en mettant le systeme TCPA a proprement parler dans le CPU. La solution logique serait de le mettre au contraire avec le chipset south bridge, ce qui est une bien meilleure place au niveau des bus de donnees pour controler les fonctions de pre-boot.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Certe.
La suite par contre.... Une puce type cryto controleur est minuscule à coté de tout le reste ! De plus, le chef d'orchestre du système est le cpu qui a donc acces à tous. L'avantage est d'empécher de snifer les échanges TCPA<-> CPU.
Et puis ouvrire le cpu ou le south bridge doit être aussi complexe, l'un que l'autre.
"La première sécurité est la liberté"
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 1.
Le probleme viendrait si la puce etait integre a un controleur (ie une puce qui fait TCPA+autre chose) . La ca risquerait de compliquer la tache. Mais ca compliquerait aussi la tache des fabriquant de carte mere, vu que chaque upgrade dudit controlleur impliquerait une upgrade TCPA au passage. Ceci etant c'est tout a fait envisageable de mettre le TCPA sur la clock par exemple, voir meme ca simplifierait les fonctions de RNG. Mais pour l'instant on est en speculation pure, donc pas d'arguments concrets pour dire que c'est mal ou que c'est bien.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . Évalué à 0.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 2.
La section 4.13 te donne les etats preconfigures et les flages de TPM, dont on peut deduire son comportement.
La partie 4.13.2 est celle qui t'interressera le plus je pense, il y a tous les iens vers les autres sections si tu veux des approfondissement.
La partie 4.22-4.23 decrit les processus lors de la migration des clefs.
On peut a peu pres tout faire avec un OS non certifie TCPA. Seul probleme ce ne sera pas un certificat complet. La TPM Proof n'est pas obligatoire, mais son absence fait que les clefs ne sont plus certifiees TCPA.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Le fait que le TPm soit sous control de l'OS ne me plait pas trop. Des tas de bidouille peut-être fait par lui.
De plus, l'endorcement key unique par TPM n'est pas vraiment un gage de protection de la vie privé. Et je ne voix pas vraiment à quoi cette foutu clef peut servir !
Elle devrait être traiter comme les clef actuelle pourquoi avoir cette clef unique ?
"La première sécurité est la liberté"
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Beretta_Vexee . Évalué à 1.
Puis c'est tout de méme de la crypto RSA de l'orde de 2048Bit ce qui n'est pas specialement triviale a implementer en soft, et ce avec un niveau de securité superieur a n'importe qu'elle implementation soft.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Les certificats font déjà ce boulot. En quoi, est-ce un problème de pouvoir modifier le contenu de la puce ? Enfin, en quoi est-ce un problème pour toi, l'utilisateur du système ? Parce que je comprends tout à fait que ceux qui veulent te tracer préfaire que tu ais cette clef.
...une puce vierge et de remplacer la puce sur la machine attaqué pour passer les protections.
En quoi, tu passes les protections ? Le TCPA est avant tout là pour planquer une clef privé et la protéger en cas de crack de ta machine (le boulot d'une carte à puce). Le reste n'est que pour aider l'implentation de truc sur ta machine que tu ne controles pas. IMHO.
la crypto RSA de l'orde de 2048Bit ce qui n'est pas specialement triviale a implementer en soft
C'est beaucoup plus trivial à faire en soft que de se le taper sur les qq mips dont disposent les crypto controleurs.
et ce avec un niveau de securité superieur a n'importe qu'elle implementation soft.
???
Quel sécurité ? Celle d'une jolie boite noire ? Quel assurance aurras-tu sur la qualité du random de la clef de session par exemple, a part celle du commerciale ?
"La première sécurité est la liberté"
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 1.
Et bien c'est exactement ca, c'est un certificat hardware, ni plus ni moins. Et il faut que le certificateur soit une tierce personne et que les certificats ne puissnet pas etre delivres par n'importe qui (ce qui interdit malheureusement une mise en place 100% libre). Sinon une machine pourrait s'autocertifer ce qui fait :
- 1) Une personne pourrait creer un trusted root sur lequel il est owner, l'implanter sur ta machine et recuperer toutes tes clefs (pas bon)
- 2) N'importe qui pourrait passer pour n'importe qui au niveau des echanges de clefs (pas top non plus)
Comme pour les certificats il faut des organismes certificateurs, c'est aussi simple que ca. Et comme en TCPA tout le monde est certifie, tout le monde passe par un organisme certificateur.
En quoi, tu passes les protections ? Le TCPA est avant tout là pour planquer une clef privé et la protéger en cas de crack de ta machine (le boulot d'une carte à puce). Le reste n'est que pour aider l'implentation de truc sur ta machine que tu ne controles pas. IMHO.
TCPA sert aussi a generer des clefs publiques vis a vis de ta machine et de l'exterieur. Une puce vierge ou avec un trusted root fausse entrainerais l'efondrement de tout ce mode sans ces protections. TCPA ne servirait plus a rien (autant stoquer les clefs en clair sur ton disque dur, ca reviendrait au meme)
Quel assurance aurras-tu sur la qualité du random de la clef de session par exemple
Vu qu'on peut generer des RN a la volee avec TCPA , il est extremement facile de quantifier la qualite de ces nombres aleatoires. tu en genere 100 000, tu trace une gaussienne, tu regarde et tu connais la qualite de ta generation. Pas besoin de faire confiance aveugle a ton commercial, tu peux aller verifier par toi meme si ca te chante (il n'y a pas besoin de connaitre l'algo pour tester la qualite d'une serie aleatoire)
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
TCPA sert aussi a generer des clefs publiques
Euh... si il génère des clefs publiques ils génèrent aussi des clefs privé, sinon y'a comme un hic...
TCPA ne servirait plus a rien (autant stoquer les clefs en clair sur ton disque dur, ca reviendrait au meme)
N'importe quoi ! Dans ce cas tu te trouves avec l'équivalent d'une carte à puce !! Tu peux lui faire générer une clef RSA. Elle te sort la clef publique et conserve la clef privé. Si tu fais un coup de ssh, la puce te génére la clef de session. La clef privé n'est jamais visible !
"La première sécurité est la liberté"
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 1.
Ben c'est un peu le but de tout certificat non ? Avoir un process qui ne depend pas de toi et qui permet d'assurer que tu es bien qui tu pretend etre non ? Tous les certificats "logiciels" sont bases sur ce principe. Tu va voir un organisme de certification, tu lui demande de te creer un certificat comme quoi tu es ce qui tu dit etre, et tu le deplois sur ton site. Je sais bien que DLFP c'est auto certifie (quand on clique sur autehntification SSL) mais c'est un principe assez rare et peu securise.
Ce n'est que la transcription en hardware d'un principe de certification par tierce partie. Rien de choquant en soit. La seule chose qui pose probleme est que l'on ne peut pas choisir l'organisme certifieur (bien qu'il soit possible de faire changer le trusted root) Il serait bon en effet que certains des organismes de certification soit des tenors du libre (ma certif de base est faite par Intel, je l'enleve et je la fais refaire par GNU). Mais ca demande pas mal de boulot pour pouvoir etre mis en place.
De plus un certificat ne t'identifie que si tu le partage. Ce que rien ne t'oblige a faire, meme pas TCPA. Tu n'a pas envie d'ouvrir de connections vers l'exterieur sous certificat TCPA ? Ben tu ne le fais pas, ca va pas t'empecher de vivre.
La clef privé n'est jamais visible !
Ben si, tu peux la lire l'editer, la copier d'une zone a une autre etc...
Il y a pleins de fonctions qui te permettent de faire cela dans les normes. sinon si ta puce a un probleme et grille, toute tes donnees cryptees seraient perdues. Un peu genant quand meme non ? Et puis bon vu que TCPA fait aussi du cryptage symetrique c'est une veine qu'on puisse voir, lire et echanger les clefs tu ne crois pas ?
Le owner d'un trusted root fait ce qu'il veut avec les clefs...
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par boubou (site web personnel) . Évalué à 1.
Bref, peut être que TCPA peut faire aussi bien que verisign, mais je ne suis pas sûr que cela serve tant que ça...
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 utilisé en synergie avec d'autres cryptages
Posté par free2.org . Évalué à 1.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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: TCPA utilisé en synergie avec d'autres cryptages
Posté par Beretta_Vexee . Évalué à 1.
Tout le principe du systéme repause sur le fait que tu puisse faire confience a la puce en ce qui conserne tes clées, et si possible plus qu'en ton disque dur ou méme ta ram.
Cette valeurs sert en effet a identifier la puce, mais cette identification sera faite au niveau du BIOS ou de l'OS, de plus cela ne sera jamais fait en claire mais via un systéme de defit, donc logiquement les valeurs retournés ne seront jamais les mémes, ce qui rend son utilisation pour un tracage des utilisateur bien plus complexe que par exemple l'utilisation des n° de serie du processeur des disques dur ou je ne sais quoi encore ( systeme addopté pour l'activation de windows XP )
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par boubou (site web personnel) . Évalué à 1.
Ouai, enfin, il faut le dire vite, tout ça. Si tu as besoin de nombres aléatoires pour faire de la simulation, ce que tu racontes est relativemen vrai. En d'autres termes, tu peux, avec des tests statistiques, vérifier (dans une certaine mesure) que le générateur est sympa : bonne uniformité, indépendance (apparante) entre n tirages successifs, etc. Avec 100 000 tu es loin du compte, mais si le générateur est hardware, je suppose qu'on peut engendrer beaucoup de nombres et donc faire des vérifications lourde.
Par contre, en crypto tu as besoin de nombres aléatoires sûrs, ce qui n'est pas du tout une propriété statistique. L'idée est que si tu observes la série pendant un certain temps, tu dois n'obtenir aucune information sur le prochain nombre engendré. Et ça, c'est plutôt velu à tester. Les générateurs congruentiels par exemple ont des propriétés statistiques satisfaisantes mais ne sont pas du tout cryptographiquement sûr...
Je suppose qu'il existe des procédures pour obtenir de l'information sur l'aspect sûr d'un générateur aléatoire, mais j'aimerais bien des pointeurs et une idée de la faisabilité. Parce que ce dont tu parles, ça n'a rien à voir avec de la crypto.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 boubou (site web personnel) . Évalué à 1.
Je te rassure, ça ne marchera pas avec un réseau de neurones. Les réseaux de neurones sont mon thème de recherche depuis maitenant 10 ans et je peux vraiment t'assurer qu'on ne peut pas faire ce genre de test avec un RN.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 free2.org . Évalué à 1.
dans ton message ci-dessus tu devrait remplacer le mot "chaos" par "phénomènes physiques aléatoires" (comme les "bruits" électroniques ou les émissions de particules)
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par doublehp (site web personnel) . Évalué à 1.
Tu sait commen ca marche le Rapido de la Francaise des jeux ?
Tu coche des cases sur une grille, une machine genere des nombres aleatoires, le truc s affiche sur un ecran ( toutes les 5 minutes ), et si ta grille est conne celle de l ecran, tu la donne au barman qui la fait certifier par la machine.
C est tres simple, c est de la physique niveau terminale; tu prends au choix:
- une resistance traversee par un courant, ca la fait chauffer
- un condensateur a temperature ambiante
ces deux composants presentent a temperature ambiante une forte instabilite electrique du au mouvement des electrons sur la couche exterieure de l atome si tu n est pas au zero absolue.
Tu ajoute a cela une petite oscillation pour ajouter des variations de courant, donc de temperature, tu met un filtre passe haut pour virer l effet premier de ton dernier oscillateur, tu ajoute un chti Ampli Op avec un gain maximum en mode sature, et tu te retrouve avec la version binaire du bruit d un electron sur un atome .... ( ou la somme des bruits de 10 000 e- sur 10 000 atomes , ce qui est pas mieux ), ce qui par definition est un phenomene quatique, donc pas previsible !!!
La tu a un parfait generateur de nombres aleatoires .... tu ajoute un petit comparateur, un diviseur de frequence et un echantilonneur et c est fini ...
La realisation parfaite de cela n est pas donnee au premier venu, mais visiblement la technologie actuelle est suffisement avancee pour qu une companie d Etat ait accepte de l utiliser dans un produit qui soit aussi rependu que les machines a Rapido que tu trouve dans tous les bars de France : Si le code obtenu etait pas suffisement aleatoire, il serait facile de prevoire les grilles, et donc de gagner a coup sure ... mais c est base sur un phenomene quatique ajoute aux changement atmospheriques, donc pas previsible !
( je resume )
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par doublehp (site web personnel) . Évalué à 1.
Mais cette faille est aplicable a tous les autres domaines de la cryptographie, y compris au domaine bancaire ( on ne va pas fabriquer un fougon blinde qui coute plus cher que la somme de fonds qu il va transporter en 10 ans ... )
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran . Évalué à 1.
Ne veut pas dire que un OS peut aller sans que tu le sache crypter des docs et des executables pour etre sur que tu ne t'en serve pas sous un autre systeme. Pour etre exact c'est meme exactement le genre de chose dont TCPA te protege. Si Windows a l'install te locke des executables avec des clefs basees sur le PCR (ce qui veut deja dire que windows est un executable qui s'autocertifie vis a vis de TCPA ce qui me semble impossible vu la doc).
1) Il se tire une vache de balle dans le pied. Parceque TCPA c'est pas comme le systeme de protection actuelle, c'est pas dans 30 jours, c'est tout de suite. J'ai flashe mon bios ? Tous les outils proteges par clef sont bloques. Qu'est ce que je peux faire ? Rien sauf si je connais l'astuce.
On imagine le scenario suivant:
Quand j'installe windows ZP, il se connecte chez microsoft (pour l'enregistrement). En plus des trucs qui se passent actuellement avec XP, microsoft envoie une cle de cryptage (symmetrique), qui depends du numero de licence. Cette cle sert a crypter tous ce qu'on ne veut pas que l'utilisateur s'amuse a regarder, car c'est *mal* pour lui:-)
Cette cle est elle meme encryptee avec le PCR.
Donc, impossible de mater depuis linux ce que windows veut cacher, puisqu'on ne peut voir la cle symetrique. Si on fait un upgrade system, windows ZP ne peut plus lire cette fameuse cle. Pas grave, il se reconnecte a Microsoft, qui lui redonne gentiment (et de toute facon, sous XP il faut bien se reenregistrer dans ces cas la, non?)
J'avoue ne pas connaitre TCPA, mais de loin il a l'air tres dangereux. Et vous n'etes pas tres convaincant. Son utilite est tres douteuse. La seule chose positive pour l'utilisateur lambda, c'est la possibilite d'avoir des cles inviolables. C'est tres bien, mais cela existe deja, cela s'appelle les cartes a puces. Et, que je sache, les cartes a puces sont infiniment plus pratiques. Si je vais chez un ami, j'aime pouvoir m'identifier sur mon serveur de messagerie en mettant ma carte dans son lecteur. Je trouve nettement moins pratique l'idee de dessouder le chip DRM et de l'avoir toujours sur moi.
Cela me parait assez clair que ce truc n'est pas invente pour notre bonheur a nous, petites gens. Et meme s'il ne permet pas de fliquer autant que je pourrais le craindre (du genre, mes deux premiers paragraphes, c'est pas possible), c'est un pas dans la mauvaise direction. On franchit une ligne, a mon sens. A partir de quand vous trouvez que la situation pue vraiment? Quand des hommes en impermeable frappent a votre porte pour vous emmener?
Clairement, il faut boycotter des maintenant.
A lire: "Matin brun", de Franck Pavloff
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 1.
Bon je passe outre le fait de se faire dicter par telephone une clef de 2048bits, ce qui pourtant pourrait etre un pur moment de bonheur, et qui a mon avis decredibilise un peu ton scenario.
Je reprend au moment ou mon "windows media DRM et tout" il ne veut plus marcher parceque j'ai upgrade mon systeme. J'apelle windows qui me file une clef, je l'enregistre et la hop : mon "windows media DRM et tout que je m'en sert que pour lire des trucs legaux promis jure" il ne marche toujours pas. Ben non le bougre il a ete crypte avec une clef qui ne sera accessible que depuis mon ancien profil de boot, et la je l'ai change. Zut alors je suis oblige de reinstaller tout mon windows. Et donc de me farcir une troisieme installation de clef super.
Non vraiment j'y crois pas un seul instant...
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran . Évalué à 1.
Bon je passe outre le fait de se faire dicter par telephone une clef de 2048bits, ce qui pourtant pourrait etre un pur moment de bonheur, et qui a mon avis decredibilise un peu ton scenario.
Troll, je reponds pas.
Je reprend au moment ou mon "windows media DRM et tout" il ne veut plus marcher parceque j'ai upgrade mon systeme. J'apelle windows qui me file une clef, je l'enregistre et la hop : mon "windows media DRM et tout que je m'en sert que pour lire des trucs legaux promis jure" il ne marche toujours pas. Ben non le bougre il a ete crypte avec une clef qui ne sera accessible que depuis mon ancien profil de boot, et la je l'ai change. Zut alors je suis oblige de reinstaller tout mon windows. Et donc de me farcir une troisieme installation de clef super.
Non, tu n'as pas compris le schema que je decris. Les trucs DRM (par exemple) sont proteges avec une cle que Microsoft te donne (Il la calcule en fonction du numero de licence, par exemple.) TCPA sert juste a proteger la-dite cle dans les tripes du TPM, de telle sorte qu'on ne puisse pas la lire depuis linux. Apres un upgrade, cette cle devient inaccessible, certes. Mais Microsoft peut la redonner. Et DRM devient a nouveau accessible.
Ma question est: pourquoi ce scenario n'est pas possible sous TCPA?
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 1.
De deux choses l'une soit la clef que MS te donne est toujours la meme, et la effectivement tu peux t'en servir pour relancer des applications et/ou des docs DRM apres une upgrade. Mais bon comme c'est toujours la meme clef, rien ne t'empeche de la remettre en place sans l'accord de MS, voir meme de la copier dans un endroit parfaitement accessible sous Linux. Si la clef ne change pas elle est par definition tres faible, vu qu'elle ne depend pas de ton hardware, meme si elle est stoquee sur TCPA rien ne t'interdit de l'utiliser ailleurs.
En plus pour que cette technique soit possible il faut que la clef soit donnee en mode transmissible, elle ne peut pas se loger en contole PCR (meme avec exactement la meme clef la puce refusera de decrypter un element qui a ete encrypte sous un autre PCR). Donc le cas dont tu parles ne peut pas se produire.
Pour faire clair il y a deux cas :
- Soit la clef est depedante du hardware, logee avec un test de PCR et fait appel a la fonction TPMPROOF auquel cas elle devient inaccessible en cas de changement de hardware ou d'OS (la elle est illisible par linux) . Mais si je change mon Hardware, meme si MS me redonne exactement la meme clef, mon TPMPROOF a change et le decryptage reste impossible. La seule solution que j'ai si je veux decrypter ce qui a ete crypte par cette clef avant le changement de hardware est de deplacer cette clef dans une zone qui ne fait pas appel au TPMPROOF, et qui est donc lisible par Linux.(N.B ce deplacement de clef est tout a fait possible, il suffit d'avoir les droits owner sur le trusted root pour faire tout ce que l'on veut avec les clefs.)
-Soit la clef est independante du Hardware et ne fait pas appel au TPMPROOF du PCR, auquel cas elle est de base lisible par linux, basta.
Troll, je reponds pas.
Je suis desole que tu ais pris mon apparte comme cela, ce n'etait pas mon intention. J'imagine donc que pour toi tous les echanges de clefs se feront par moyen electronique obligatoirement. C'est possible mais ce serait quand meme une sacree limitation. Je pense qu'une mention "necessite une connection internet valide" sur un OS serait du plus mauvais effet. Meme si XP s'installe tres bien via le net, la possibilite de le reinstaller par telephone est quand meme rassurante.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran . Évalué à 1.
De deux choses l'une soit la clef que MS te donne est toujours la meme, et la effectivement tu peux t'en servir pour relancer des applications et/ou des docs DRM apres une upgrade.
C'est effectivement le cas que je considere.
Mais bon comme c'est toujours la meme clef, rien ne t'empeche de la remettre en place sans l'accord de MS, voir meme de la copier dans un endroit parfaitement accessible sous Linux.
Oui, a condition que j'ai une chance de la voir, cette cle. Dans ma comprehension de Palladium, Windows a une zone securisee (que j'ai vu appelee "Le sanctuaire Palladium") dans lequel ne peuvent rentrer que les applications signees. Exemple, les applications DRM compliants. Contre-exemple, un debuger. Meme l'administrateur ne peut pas rentrer dans le sanctuaire Palladium. Si les gars de chez Microsoft sont malins. Cette fameuse cle est rangee dans le sanctuaire quand le systeme est up; et dans le TPM quand le systeme est down. En l'absence de trou de securite, je ne peux jamais intercepter cette cle.
En fait, c'est precisement cette cle qui sert a securiser les ressources du sancturaire Palladium, lorsque le systeme est down (dans mon schema personnel, bien sur. J'ai aucune idee precise du fonctionnement de Palladium.)
Je suis desole que tu ais pris mon apparte comme cela, ce n'etait pas mon intention. J'imagine donc que pour toi tous les echanges de clefs se feront par moyen electronique obligatoirement. C'est possible mais ce serait quand meme une sacree limitation. Je pense qu'une mention "necessite une connection internet valide" sur un OS serait du plus mauvais effet. Meme si XP s'installe tres bien via le net, la possibilite de le reinstaller par telephone est quand meme rassurante.
Bof. Cette securite parano, c'est juste pour le DRM. Le DRM, pour les gens qui n'ont pas internet, n'est pas d'une utilite dementielle. Ces pauvres loosers auront un windows ZP, un peu castre (sans DRM): Ils s'enregistreront par telephone et on ne leur donnera pas de cle Palladium. A mesure que le temps passe, l'hypothese "tout le monde a internet" devient de plus en plus vrai. Donc je crois que Microsoft peut parfaitement commencer a mepriser ces gens la.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . Évalué à 1.
Il n'y a pas de notion de "Sanctuaire" ou de zone inaccessible dans TCPA. La seule zone pour laquelle on est pas libre est le trusted root qui doit etre delivre par un organisme certificateur assermente.
Si tu fiche la clef dans le TPM elle devient lisible par le owner du trusted root, c'est pourquoi Paladium aura sa propre puce tres vraissemblablement. Une puce qui sera peut etre base sur TCPA, qui utilisera peut etre le systeme TPM, mais ce ne sera pas TCPA en l'etat.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran . Évalué à 2.
Cette remarque a ete suggeree dans plusieurs fils. A chaque fois, tu reponds que si tel est le cas, le moindre upgrade rend l'acces a ces donnees impossibles par windows. C'est l'unique argument que tu sors pour dire que Microsoft ne peut pas implementer cela.
Dans le schema que je propose, ce probleme disparait puisqu'on se reenregistre aupres de Microsoft a chaque upgrade, pour recuper la fameuse cle qui est desormais devenu inaccessible.
DONC, TCPA permet d'implementer quelque chose qui, a defaut d'etre Palladium, lui est fonctionnellement identique.
Palladium est mal.
Ce qui est identique a Palladium est mal aussi.
Ce qui permet d'implementer quelque chose d'identique a Palladium est donc mal.
Bref TCPA est mal
TCPA n'aide en rien ni DRM ni Paladium.
J'attends un argument technique solide qui invalide mon schema. Je ne demande qu'a te croire, mais pour le moment je reste tres tres mefiant vis a vis de TCPA.
Il n'y a pas de notion de "Sanctuaire" ou de zone inaccessible dans TCPA
Bien sur. Je vois TCPA comme une couche bas niveau. De meme qu'en assembleur, il n'y a pas de notion d'objet. Mon schema montre qu'on peut utiliser TCPA pour implementer un sanctuaire.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 free2.org . Évalué à 1.
sur quel document tu te base pour affirmer que l'accès lecture/ecriture à toutes les données par l'utilisateur est dans la norme TCPA ?
(moi je cite un document où il est marqué que l'utilisateur n'a pas accès au contenu du random generator, ce qui n'est pas rassurant sur la qualité de celui-ci. un bon générateur doit avant tout se baser sur des phénomènes physiques imprévisibles comme le bruit ou l'émission de particules. pas sur un pseudo générateur mathématique et donc déterministe)
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 ?
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 utilisé en synergie avec d'autres cryptages
Posté par free2.org . Évalué à 1.
il n'est pas dit qu'il a accès à l'algo ou au code du générateur non plus !
Il y a dans la doc une les fonctions qui doivent etre accessible au boot, a partir du bios et logiciellement sous l'OS.
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 ?
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 ?
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)
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 free2.org . Évalué à 1.
it is desirable to provide a method that enables or disables the process
"Désirable" veut dire que ce n'est pas obligatoire dans la norme. Le danger est donc bien là: la norme n'oblige pas les constructeurs à donner un controle yotal à l'utilisateur. C'est juste "désirable". No comment.
PS: merci pour tes références
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 thoran . Évalué à 1.
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.
Elle ne l'est pas. C'est clair? ELLE NE L'EST PAS!
C'est de la bete crypto symmetrique, et la cle est envoyee par Microsoft a l'enregistrement. Elle est envoyee a mon ordinateur. Pas a moi. Mon ordinateur, qui est devenu mon ennemi, se garde bien de me laisser voir cette cle un jour.
Ensuite, je te cite, citant la spec:
The "trusted" boot functions provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence.
Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has backdoored the operating system, the PCR value will not match, and the unseal will fail [...]
Windows ZP applique ce procede et "scelle" la fameuse cle avec le PCR courant.
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.
Question:
Comment je fais pour acceder au "pass" (la fameuse cle). Depuis linux, mauvaise valeur du PCR. Aucune chance de lire la cle. Depuis Windows ZP, a moins d'un trou de securite, il ne me la donnera jamais. Il la gardera dans ces tripes et aucun programme ne pourra jamais y acceder.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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 free2.org . Évalué à 1.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . É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
[^] # Mais quel est l'interret du test PCR !!
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Donc c'est bien un système que tu achètes toi pour toi mais qui peux te baiser ? Un organisme certificateur est externe et bien identifié. En quoi le changement de hardware ou d'OS permet d'augmenter la sécurité de l'utilisateur ? On dis toujours que la sécurité info est avant tout contre les attaques "remote" et non par accès physique à la machine. En quoi, cela aide à la sécurité de mes clefs privés ? C'est moi qui controle le changement de hardware ou d'OS ! Je préfaire encore la carte à puce à pin code qui active la transaction pour quelques minutes.
Tu peux juste t'identifier plus facilement. Cela peut simplifier des démarches. Mais moi, cela me rappelle Passport de MS et le numero unique d'identification que les Japonais voulait donner à chaque citoyen.
De plus, la crypto de fichier protéger par PCR. 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. Tu dois upgrader la machine ? Pas grave, on te donne le "droit" de recharger le fichier à nouveau crypté avec une nouvelle clef.
"La première sécurité est la liberté"
[^] # Re: Mais quel est l'interret du test PCR !!
Posté par Jerome Herman . É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 Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par doublehp (site web personnel) . Évalué à 1.
Dans notre societe de service tout se loue, et c est de plus en plus vrai pour les PC, et en generale le contract de location specifie que tu n a pas le droit d'ouvire ni modifier l appareil loue.
Deja les contracts de garentie actuel sur le sproduits achetes specifient que la garentie saute si tu ouvre le dit element ( telephones portables, durs, frigo, alimentaions de PC, fer a repasser ... je melange volontairement ) ce qui implique que le consommateur moyen est deja habitues a ne pas avoir le droit d ouvrire les produits dont il est pourtant proprietaires ...
[^] # Re: TCPA confirmé pour Prescott
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . Évalué à 1.
Si tu veux pouvoir envoyer des doccuments certifies authentiques par TCPA, alors oui il faut que tout ton systeme soit TCPA (mais c'est normal il me semble).
Si tu cherche juste un cryptage fort sans certifications supplementaires (apres tout 2048bits c'est quand meme deja une vache de securite) la tu t'en moque tu peux avoir juste le chipset TCPA et le cpu qui a les fonctions, le reste tu t'en balance.
Si tu veux envoyer un doccument crypte garanti d'emission (ie la la machine qui l'a envoye est bien celle qui pretend l'avoir envoye). Il faut que tu cree un PCR qui hashe l'integralite de ton processus de boot. Mais il ne controlera pas la compliance TCPA des elements qu'il va hasher.
Le seul but de ce lock de clef et des certifications TCPA de hardware est pour la recertification TCPA.
Par exemple si sur un serveur un de mes disques meurt (disque RAID, donc pas de perte de donnees). Theoriquement mon PCR change, et donc les clefs certifies TCPA ne seront plus accessibles au boot suivant. Mais comme tout mon serveur est TCPA mon nouveau PCR sera aussi full TCPA, quand je vais deplacer les clefs d'un PCR a l'autre je ne vais pas perdre les certifications TCPA.
Kha
[^] # Re: TCPA confirmé pour Prescott
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . É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: TCPA confirmé pour Prescott
Posté par Beretta_Vexee . Évalué à 3.
Si j'arrive a faire comprendre aux masses que TCPA n'est pas l'ennemis la moitié du travail est fait puisqu'ils repporteront toute leurs creinte sur Palladium, et ce avec un minimum de sujection de ma par ce qui en renforcera l'impacte.
1) Je defends une technologie que je trouve interessent, puisqu'elle facilite le recours a un cryptage fort.
2) Je ne passe pas pour un fanatique communiste defenceur du libre.
3) Je fais du mal a SCP/Palladium.
4) Domination du monde rapide en me servant des lideur d'opignion de la masse revolutionnaire que represente les avocats du logiciel libre pour renverser les multinationals et les etats en quelque mois...
[^] # Re: TCPA confirmé pour Prescott
Posté par TSelek . Évalué à 2.
Aujourd'hui je peux changer de banque, changer de Carte Bleue. Imaginons que maintenant, on me greffe cette CB sur le front et que je ne puisse plus en changer, ainsi que de banque, ou alors au prix de terribles souffrances. Tu me réponds que je pourrais toujours payer en liquide. Oui, bien sur. Ah non, juste les petits montants... Et pour les gros montants ?
[^] # Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee . Évalué à 1.
Je crois méme que j'ai fait reculer l'addoption du GSM et de l'UMTS outre atlantique ... Tu en a d'autre ? Parce que visiblement le marché de la carte a puce m'a pas attendut moi ou TCPA pour se casser la gueule.
Quand a ton analogie sogrenue avec la carte bleu, je te rappel qu'il existe un moyen de paiment appelé le cheque, qui est bien plus vieux que la carte banquaire que tu ais libre de refusé lors de ton contrat avec ta banque.
[^] # Re: TCPA confirmé pour Prescott
Posté par huhuhu . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par cornofulgur . Évalué à 1.
On le paye pour ca. ;)
TCPA est effectivement innofensif en ce qui concerne les libertes individuelles.
Il faut le dire vite.
tcpa se répand comme une trainée d'OGM dans nos machines et les gens n'ont pas le choix. Le cartel ne te laisse pas le choix.
tcpa est une porte qui leur permet de controler la machine. 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.
Ils sont en train de te bouffer ton pognon. tcpa est un cookie monstrueux.
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é. Tu n'as pas le moyen de décider : je désactiverai dans tel cas et pas dans tel autre. C'est imprévisible. C'est tout ou rien.
tcpa est une super technologie. mais
a. tu la payes.
b. ca ne t'apporte rien.
c. ca existe depuis 20 ans (cartes à puces).
d. la loi de l'offre et de la demande, c'est un doux rêve aujourd'hui.
Qu'ils vendent des fritz chips à part. si j'en ai besoin j'irai en acheter.
D'ailleurs, j'ai une carte à puce sur ma carte bleue. j'en suis tres content.
A cote de ca, quand j'écoute Paul England qui cause de Palladium, il n'a pas un discours liberticide : il dit que les gens arriveront à trouver une "bonne" utilisation des DRM. Je pense qu'il a raison : c'est un probleme social, pas technique.
Palladium permet de monter un p2p équitable : j'achète. On s'en fout que ce soit pas top secure du moment que c'est équitable. Internet est bati sur du sable, me dit on, et bien ca marche. Chasser des bugs dans un système est une garantie pour l'équité et pour l'innovation. Nous en avons besoin.
Quant aux marketteux de MS, ben, ils devraient revoir leurs copies. Qu'on fasse une confusion entre trust et trust aux Amériques, c'est une chose triste. Maintenant que les francophones confondent abus de monopole et abus de confiance, c'est affligeant. On n'a pas d'excuse.
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . É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 patrick_g (site web personnel) . Évalué à 4.
Je suis d'accord avec toi sur la différence entre TCPA et palladium.
Je te prie de m'excuser si ma news n'est pas assez claire sur ce point.
Il n'empeche que je ne te suis plus quand tu dit que TCPA est un système "neutre éthiquement" (c'est implicite dans ta réponse..)
Considérons la situation imaginaire suivante : je désire crypter mes précieuses lettres d'amour (qui passionnent la CIA et la DGSE :-)) je télécharge donc un logiciel GPL de cryptage et roulez jeunesse !!
soudain je sui pris d'un horrible doute : et si je m'étais fait avoir par un logiciel bidon ?
Je télécharge donc les sources et je les examine : même si je ne suis pas très compétent je peux au moins comparer l'implémentation du code avec le source C de référence de l'algo (présent partout sur le net).
Au besoin je peux payer un type pour qu'il me montre et m'explique le code.
Je peux aussi compter sur les milliers de types qui téléchargent le logiciel....y'en aura bien un pour s'apercevoir de la couille si il y en a une.
C'est une démarche saine et cohérente : c'est dans la nature même de la GPL de vérifier les sources !
Avec TCPA la situation est très différente : je ne peux en aucun cas sortir un microscope electronique de ma poche et m'amuser à suivre les portes logiques des 100 millions de transistors !!
Je suis obligé de faire confiance aveuglément au constructeur (et en cas d'erreur volontaire ou non de sa part je suis baisé).
Un logiciel (libre) c'est souple , c'est adaptable, c'est modifiable.
TCPA c'est l'antithèse de la liberté accordée par la GPL.
Je suis certain que tu connais comme moi la boutade de RMS a propos de TCPA : "cela s'intitule "informatique de confiance" car les constructeurs peuvent faire confiance à votre ordinateur....mais vous vous ne pouvez plus lui faire confiance""
[^] # Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee . Évalué à 1.
Et si c'était déjà le cas ? Apres tout tes lettres d'amour son bien decrypté a un moment quelqu'on que dans la RAM ou autre.
De plus peut étre méme que les standars cryptographique que son RSA, AES, et SHA-1 on étaient choisis pour des leurs faiblesses, car apres tout ce sont des standar Americains, et que la CIA peut les casser en quelques minute sur le PC de monsieur tout le monde ?
De plus pourquoi ton raisonnemant se limiterait il a TCPA, peut étre que toute l'industrie de la securitée informatique n'est qu'une vaste supercherie a la solde des services de renseignement d'un gouvernement mondiale a la solde des cabaliste d'usenet !!!
Plus serieusement, tu crois vraiment que des fabricants de matos de cryptage et de securité peuvent se permetre de foutre des backdoor ?
Ils leurs faudraient une bonne dose de bétise et une sacrée confience dans leurs backdoor, parce qu'on parle pas d'un sombre soft pour une dizaine de serveur la mais d'un produit destiné a étre vendue a des millions d'exemplaires.
[^] # Re: TCPA confirmé pour Prescott
Posté par patrick_g (site web personnel) . Évalué à 1.
néanmoins :
1) les backdoors logicielles peuvent êtres évitées par l'usage de logiciels libres qui permettent l'examen du code.
2) les algos de crypto (DES;3DES;AES;twofish...etc) sont scrutés par les spécialistes du monde entier : je suis pas assez parano pour croire que le monde entier conspire contre moi....et s'il est vrai que ce sont des standards US faut pas oublier que AES est un algo belge à l'origine (Rjindael).
3) les éventuelles backdoors hardwares actuelles ne sont pas évitables et il est vrai que nous nous faisons peut-être tous avoir en ce moment même....mais officiellement il n'en est rien et il n'y a pas de crypto matérielle dans nos CPU grand public ET C'EST CE QUI VA CHANGER AVEC TCPA !!!
c'est l'officialisation de la chose qui m'inquiète au plus haut point!!
Intel ou AMD ou Motorola ne prendraient pas le risque actuellement de bidouiller les CPU de peur du scandale en cas de découverte...mais avec le standard TCPA c'est officiel : il y aura de la crypto matérielle dans mon CPU et je serai dépendant de l'implémentation matérielle dans le silicium !
si c'est mal foutu et pleins de bugs tant pis pour moi c'est comme ça !
si c'est backdooré par la NSA (affreux néologisme) tant pis pour moi c'est comme ça !
Je ne peux plus rien y faire c'est gravé dans le silicium.......malgré tout les efforts de la FreeSoftware je suis prisonnier de mon ordi : triste non ?
[^] # Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee . Évalué à 1.
Apres le coup de la Puce qui envoye tes donnés crypté par le resau a la NSA, en fesant fit de l'OS et du reste, j'ai du mal a y croire, tu m'escusera...
De plus si tu ne fais pas confience a TCPA, tu es libre de ne pas l'utiliser tu boot ton linux sans le module ou le driver et c'est finie on en parle plus.
[^] # Re: TCPA confirmé pour Prescott
Posté par cornofulgur . Évalué à 2.
Jusqu'au jour où une loi débile passera qui obligera les FAI a négocier une connexion tcpa montrant ton ID infalsifiable.
Tu es libre de ne pas te connecter au Net, ceci dit.
[^] # Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee . Évalué à 1.
Reveiez vous un peut, on est en 2003, la realitée depasse largement vos petites fictions, avec la téléperquisition il ne faudra pas plus d'une minute pour faire le lien entre une IP et un nom une addresse a un officié de police.
De plus le probléme que tu souléves est legislatif pas technologique.
C'est pour cela qu'au lieu de pertre son temps a essayer des reculers les avancées techniques, ils faut plustot lutter contre le developpement de ces lois dangereuses .
[^] # Re: TCPA confirmé pour Prescott
Posté par boubou (site web personnel) . Évalué à 1.
Ouai, ta raison, vive les OGM, le clonage humain, le nucléaire, etc.
Sinon, tu ne pourrais pas faire un minimum (je dis bien un minimum) attention à ton orthographe. C'est insupportable, j'ai presque envie de te mettre -1 à chaque commentaire à cause de ça.
[^] # Re: TCPA confirmé pour Prescott
Posté par cornofulgur . Évalué à 1.
Je ne parlais pas de cette mesure législative dans le but d'identifier les internautes, on est déjà servi c'est vrai.
Je parlais de cette mesure dans le but d'imposer un réseau Ternet constitué exclusivement de machines dégradées dont les utilisateurs ne sont plus maitres.
Un Minitel en couleur.
Sur une machine tcpa, quelles seront les limites imposées à Root ?
Qui bénéficie de ces limites ?
perdre son temps a essayer de reculer les avancées techniques
Ce n'est pas une avancée technique. ca existe depuis 20 ans.
Mets moi ta puce ailleurs que dans un Personal Computer, je serai content.
Enfin ca dépends... :)
# Re: TCPA confirmé pour Prescott
Posté par Julien Olivier . Évalué à 1.
[^] # Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee . Évalué à 6.
[^] # Re: TCPA confirmé pour Prescott
Posté par Julien Olivier . Évalué à 3.
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à -1.
[^] # Re: TCPA confirmé pour Prescott
Posté par XHTML/CSS inside (site web personnel) . Évalué à 5.
[^] # Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee . Évalué à 2.
Si on veut vous tracez il existe enormement de moyen, surtout si ca implique un soft resident sur la cible, votre CPU a un n° de serie vos DD aussi, vos barette de ram certainnement, etc etc ... Sans méme parler de votre nom d'utilisateur et autre.
Le nerf de la guerre n'est pas la, le fait est de savoir si l'on veut plus de cryptage et de maniére plus sur ce qu'offre TCPA ou si l'on veut moin de responcabilité mais aussi une perte de controle ce qu'offre Palladium.
TCPA ne permet pas l'identification du PC ou trés difficilement ( en tout cas bien plus difficilement que par les divers moyens cités plus haut ), Palladium pour le moment personne ne le sait, mais aux vue de Passport et autre initiative de la firme de Redmont on peut se pauser des questions.
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à 0.
tu devrais essayer des p2p comme freenetproject , gnunet, etc.
pour le mail je te conseille les softs basés sur "onion routing" ou sur "dining cryptographers"
dans debian tu as mixmaster
[^] # Re: TCPA confirmé pour Prescott
Posté par doublehp (site web personnel) . Évalué à 1.
quel mal y as-t-il a apparaitre tel que l'on est ?
je vois pas commen je peut interdire a un mec dans la rue de me suivre jusque chez moi, relever le nom de ma rue, le numero de ma maison, ou le numero de ma plaque d iimmatriculation ... le botin telephonique ou l anuaire de ma ville lui donneront mon nom, mon telephone, ce qui lui permet d'aller au service des impots pour savoir combien je gagne, ou je bosse ( si il l esait pas encore ), de me denoncer aux services fiscaux pour reclamer a ce que je sois controle ... bref .... il peut aussi m'attendre devant ma porte pour nme tuer ... ou simplement espionner mes moindres faits et jestes le plus legalement du monde ...
Je ne comprends pas pourquoi on ferait tant d'efforts pour rester anonymes sur le net, alors que c'est pas possible IRL ...
( Attention, certains de mes propos sont peut-etre ironiques ... )
# Re: TCPA confirmé pour Prescott
Posté par jx951 . Évalué à 0.
[^] # Re: TCPA confirmé pour Prescott
Posté par huhuhu . Évalué à 2.
[^] # Re: TCPA confirmé pour Prescott
Posté par free2.org . Évalué à 1.
pour ma part les fonctions de sécurité software de LinuxSecurityModule, systrace, fireflier et autres tripwire me suffisent amplement
sans compter que les clés de cryptage (c'est quand meme la base de TCPA) sont deja protégées par des passphrase dans ssh et gpg
# Re: TCPA confirmé pour Prescott - les utilisateurs trancherons
Posté par stef_2000 . Évalué à 3.
Pourquoi les gens ont un PC chez eux?
- la plupart pour taper trois quatre CV et lettre par ans --> office est necessaire et en plus mon pote me le file.
- surfer sur le web: cool je pourai me faire mes Compil de MP3 et me lire des DIVX (sur mon appareil de salon maintenant) --> et hop plus besoin d'acheter des CD et DVD
- Les jeux --> je prends pas la console car je peux copier les jeux PC
- Brancher mon appareil photo numerique --> je paie plus le photographe (bien que l'appareil photo coute chere)
Je crois avoir bien resumé les besoins des particuliers d'un PC --> aucun besoin "vital" d'un PC. Si je veux ecrire mes lettre et CV pour un boulot y a les agences de l'emploi qui me permette cela. Je peux arriver à la conclusion que les particuliers n'ont pas besoins de PC et si ils se rendent compte qu'ils ne peuvent plus faire ce qu'ils veulent de leur PC et que chaque action leur coute de l'argent (en plus du prix d'achat du PC) il se peux bien que ceux-ci n'achete plus de PC et delaisse l'informatique.
On parle de l'internet dans les Frigo, douches,... on essaie de creer un besoins mais les consommateurs n'en veulent pas pour le moment et j'espere jamais.
J'espere qu'a ce moment le monde retrouvera ces vrai valuers et que la communication interpersonnel reprendra ses droits au depend de tout ce qui est virtuel.
Dans ma vision des choses cela ferait tres mal à Krosoft et à l'informatique en general (je suis informaticien) et puis est-ce que les entreprises veule un controle permanant de MacroDollar sur leur business je ne crois pas mais ca c'est un autre debat
J'attends avec impatience vos commentaires...
[^] # Re: TCPA confirmé pour Prescott - les utilisateurs trancherons
Posté par free2.org . Évalué à 1.
Par contre si certains fichiers disponibles sur internet sont protégés par un système fiable de DRM (reposant sur des puces hardware) qui n'est pas violable, et qui pour des raisons de contournement n'est pas disponible sur les OS alternatifs; ALORS ce sont les OS alternatifs qui vont avoir du mal à convertir les utilisateurs "normaux":
"quoi, avec Linux je ne peux pas accéder à telle grande radio, ou à telle bande annonce célèbre, ou à tel morceau de musique célèbre ?".
Alors que aujourd'hui en utilisant Wine ou en utilisant des softs libres compatibles, on peut accéder à tous ces fichiers protégés.
[^] # Re: TCPA confirmé pour Prescott - les utilisateurs trancherons
Posté par Jerome Herman . Évalué à 1.
La menace DRM est une menace reelle, mais elle ne peut en rien etre aidee ou favorisee par TCPA. On ne peut pas a partir d'une clef publique TCPA en deduire que l'utilisateur fait tourner linux ou possede un programme de rip.
kha
[^] # TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . Évalué à 0.
là faut pas exagérer non plus quand meme !
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
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
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
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)
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é
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 . É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
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . Évalué à 1.
voici mon article qui regroupe les 6 faits sur TCPA avec liens vers les documents officiels:
https://linuxfr.org/~igive/1546.html(...)
Je peux creer un fichier qui ne sera lu que par cette machine.
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é) je peux m'assurer de l'identité exacte d'un PC TCPA. C'est bien plus dangereux que l'ID des pentiums (qui a été boycotté avec succès)
Et que je change de sequence de boot, de base je ne peux plus decrypter mes applis
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)
Ca n'empeche pas un OS non signe d'acceder aux fonctions TCPA
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)
MS fait partie de tout
oui mais pourquoi des leaders du software comme Oracle (leader des DBs), Sun (J2EE) ou LInux/Apache (leader des serveurs webs) ne font pas partie de TCPA ?
MS est le seul non fabricant de CPU à faire partie de TCPA
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.
faux: la norme autorise à intégrer TCPA dans n'importe quoi (cf liens dans mon article)
y compris le CPU
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
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.
faux: la norme autorise à intégrer TCPA dans n'importe quoi (cf liens dans mon article)
y compris le CPU
C'est pas vraiment faux. Disons que la puce TCPA dans le cpu regardera ce qui passe sur le bus du cpu. C'est physiquement différent mais identique de façon système.
"La première sécurité est la liberté"
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . Évalué à 1.
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . É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 free2.org . Évalué à 1.
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.
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . É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 confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . Évalué à 1.
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . É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 confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . Évalué à 1.
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
ensuite je ne suis pas d'accord sur les conclusions de:
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.
Au contraire, à l'image de XP activation, les fournisseurs DRM sont contents qeu tu ne puissse plus accéder aux fichiers DRM si ta config change, et t'envoieront à nouveau ces fichiers si tu es à jour du paiement de tes mensualités ou de ton pay per view.
Donc je confirme et je signe: TCPA est une avancée considérable pour le DRM !
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . É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 confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . É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é comme menace bien pire que le numéro du pentium
Posté par free2.org . Évalué à 1.
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.
On peut generer autant de CA que l'on veut.
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.
Où as-tu lu que le mode extend ne sera pas forcé ? (notamment pour pouvoir utiliser certains softs DRM qui exigerait sa présence...)
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . É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 free2.org . Évalué à 1.
Quand aux softs de DRM de MS si ils exigent Windows pour tourner, le mal est deja fait (combiné à l'endording key et au PCR, ça fait mal)
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . É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 free2.org . Évalué à 1.
je ne comprends pas pourquoi tu contredis en permanence le document IBM qui dit le contraire (tu es mieux informé qu'IBM que l'évolution actuelle de la norme TCPA ?):
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
voir ma réponse similaire à un ton commentaire similaire:
https://linuxfr.org/comments/178109.html(...)
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . Évalué à 1.
Kha
(dans une chambre d'echos depuis trois jours)
[^] # Re: TCPA confirmé pour Prescott - les utilisateurs trancherons
Posté par doublehp (site web personnel) . Évalué à 1.
> J'espere qu'a ce moment le monde retrouvera ces vrai valuers et que la communication interpersonnel reprendra ses droits au depend de tout ce qui est virtuel.
Hmmm .....
est ce que tu as "besoin" de ta voiture ? un simple velo pourrait suffire pour aller au boulo ...
Est ce que tu as "besoin" d'une tele chez toi ?
Pourtant certains seraient prets a faire beaucoup pour en avoire une: la payer a credit meme si ils ont pas de salaire, faire 60km pour trouver un darty ouvert le dimanche apres midi par ce que la TV a fume le matin ... Tu trouve meme des assurances qui te promettent de te chager ta TV chez toi a domicile dans les 24h ... je ne pense pas qu un tel service puisse etre propose sans qu il y ait un reel "besoin" des dits consommateurs ...
Dans le meme ordre d idee, ma mere dis que la seule veritable avancee technologique du 20e sciecle est la machine a laver le linge. Presque 100% des autres produits (TV, micro-onde, lave vaisselle - en tant qu etudiant, je n ai rien de tout ca ... juste une gaziniere ) sont remplacables/suprimables sans grand domage pour la liberte ou le bonheur du genre humain ...
Et ce cher PC ... mon ami de tous les jours, mon compagnon de solitude ... ben malgres ce que certains de mes prochent peuvent croire, je peut passer plus de 2 semaines sans le voire ... ni meme penser a lui ... et il ne me manque pas !
Je ne remet pas en cause l'evolution, mais il ne faut pas non plus la deifier ... merci de faire la part des choses ...
# Cet article me fait tripper :)
Posté par doublehp (site web personnel) . Évalué à 1.
Bref ce debat me fait bien rire ...
On avait depasse les 500 commentaires avec IE vs MZ, la ca va un poil moins vite, mais c est sacrement plus volumineux ( en volume de texte a lire ... ), quoi que la page se charge pour l instant plus vite ...
Qui veut une cuisse de troll doree a point ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.