Articles précédents : Articles
- [5] Nouvelle version majeure de Nessus : 2.0
- [8] Mieux vaut en rire : RMS de Microsoft !!
- [23] Un remplaçant pour nos antiques BIOS
- [31] Etude de fiabilité de GNU/Linux face à des OS propriétaires
- [11] nopatent.org est ouvert
- [25] Bientôt, des portables OGG vorbis
- [103] Les statistiques Google reconnaissent les navigateurs basés sur Gecko
- [10] Nouvelle version de phpMyAdmin : 2.4.0
- [66] BeOS est mort vive Zeta
- [104] Libre et rémunération ?
Liens connexes
- L'article dans The Inquirer (871 clics)
- Un autre article de The Inquirer (563 clics)
- TCPA (549 clics)
- FAQ TCPA/Palladium en Français (1083 clics)
Dépêche modérée par
Articles : TCPA confirmé pour Prescott
Posté par patrick_g (page perso, ). Modéré le 25 février 2003.
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.
![[en]](../../../images/en.png)
L'article dans The Inquirer (871 clics)-
Un autre article de The Inquirer (563 clics)
-
TCPA (549 clics)
![[fr]](../../../images/fr.png)
FAQ TCPA/Palladium en Français (1083 clics)
> Lire les commentaires (179 commentaires, moyenne: 2).
Re: TCPA confirmé pour Prescott
je m'en fous je garde mon 400 mhz (qui commence a devenir lent avec openoffice qd meme), ou alors je prend le nouvel amiga ;)
et le processeur dragon de chine ?
-
[^]Re: TCPA confirmé pour Prescott
Posté par Jean-Marc Leroy (page perso, ) le 25/02/2003 à 15:34. (lien). Évalué à 8.Le processeur Dragon est actuellement à peu près équivalent à un 486, question performances...
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 (page perso, ) le 25/02/2003 à 15:44. (lien). Évalué à 18.Bon, un bon point sur les I ! TCPA != SCP (le chips de Palladium). SCP est plus retords, car il réserve une partie de la mémoire et possède des mécanismes de contrôle. Pour plus d'info, voir les références suivantes:
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 !)--
"Nobody expects the spanish inquisition"-
[^]Re: TCPA confirmé pour Prescott
Posté par Toufou (page perso, ) le 25/02/2003 à 17:02. (lien). Évalué à 4.Une enfilade entre Beretta Vexée et moi-même J'adore cette traduction de thread :)
-
[^]Re: TCPA confirmé pour Prescott
Posté par free2.org (page perso, ) le 25/02/2003 à 22:22. (lien). Évalué à 3.pour corser le tout, il se pourait que La Grande soit plus proche de Palladium que de TCPA (cf protection au niveau des logiciels)
"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 (page perso, ) le 26/02/2003 à 00:39. (lien). Évalué à 1.ah ben non, finalement il s'agit bien de TCPA:
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 (page perso, ) le 26/02/2003 à 12:22. (lien). Évalué à 1.Relis les docs d'IBM, elles contiennent certaines critiques envers les slides de Lucky Green (oui, je sais, il faudrait aussi croire IBM, mais il n'empêche qu'ils apportent un point de vue intéressant).
--
"Nobody expects the spanish inquisition"-
[^]Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par free2.org (page perso, ) le 26/02/2003 à 13:46. (lien). Évalué à 0.reste que l'existence du mode "extend" dénoncé dans le document
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 (page perso, ) le 28/02/2003 à 10:00. (lien). Évalué à 1.d'ailleurs IBM dit clairement dans son PDF: "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" avant de dire que cela obligerait à retélécharger les documents si on change quoique ce soit à la config du PC. Mais c'est justement ce que veulent les éditeurs de DRM ! En +, au lieu d'avoir à retélécharger tous les documents, on pourrait n'avoir à retélécharger que une clé par document, chaque clé étant elle-meme encryptée et protégée par le PCR, et inutilisable si la config change. Ce qui serait le DRM parfait. Bref: TCPA est une avancée majeure pour le DRM !
-
[^]Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Jerome Herman () le 28/02/2003 à 14:57. (lien). Évalué à 1.Relit le doccument en entier (cf traduction faite de ce paragraphe dans un de mes posts).
1)- A moins d'avoir l'ensemble des configurations legales sous la main, DRM ne peut pa sse servir de TCPA pour savoir si la plateforme est valable. TCPA peut enregistrer une config et dire si la config sous laquelle tu es ets bien la meme que celle qu'il a enregistre. Determiner la compliance DRM d'une plateforme devra se faire autement.
2)-Les clefs privees ne sont pas protegees contre une attaque physique dans l'implementation IBM. Stoquer des clefs DRM dans une puce TCPA IBM revient a peu de chose pres a les stoquer en clair sur le disque dur.
Bref TCPA ne sert a rien pour le DRM.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par free2.org (page perso, ) le 28/02/2003 à 15:37. (lien). Évalué à 1.TCPA peut enregistrer une config et dire si la config sous laquelle tu es ets bien la meme que celle qu'il a enregistre.
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 () le 28/02/2003 à 16:23. (lien). É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 !
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par free2.org (page perso, ) le 28/02/2003 à 22:26. (lien). Évalué à 1.) effet immediat - si le boot change, tous les applis cryptees sont inutilisables immediatement, et pas sous 30 jours.
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 () le 01/03/2003 à 00:12. (lien). Évalué à 1.CF autres posts.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
-
-
-
-
[^]Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Julien CARTIGNY (page perso, ) le 26/02/2003 à 12:22. (lien). Évalué à 2.Deuxièmemement, la meilleure solution est d'enfiler complétement la norme TCPA (350 pages au bas mots)
--
"Nobody expects the spanish inquisition"
-
-
-
-
[^]Re: TCPA confirmé pour Prescott
Posté par syntaxerror () le 25/02/2003 à 17:07. (lien). Évalué à 1.A propos, pourquoi ta niouze apparue hier a-t-elle disparu presque aussitôt ?
-
[^]Re: TCPA confirmé pour Prescott
Posté par free2.org (page perso, ) le 25/02/2003 à 17:17. (lien). Évalué à 0.c'était un clone erroné d'une news parue fin janvier: https://linuxfr.org/comments/168110.html en + le titre était "TCPA != Palladium" ce qui n'est pas assez précis et peut induire en erreur il aurait dû être "TCPA sera un élément essentiel de Palladium pour tuer Linux"
-
[^]Re: TCPA confirmé pour Prescott
Posté par Julien CARTIGNY (page perso, ) le 25/02/2003 à 20:42. (lien). Évalué à 0.en + le titre était "TCPA != Palladium"
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...--
"Nobody expects the spanish inquisition"-
[^]Re: TCPA confirmé pour Prescott
Posté par free2.org (page perso, ) le 25/02/2003 à 20:50. (lien). Évalué à 0.on ne sait meme pas si SCP existera
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 (page perso, ) le 25/02/2003 à 17:07. (lien). Évalué à 7.rappelons que TCPA est largement suffisant pour que MS puisse tuer Linux: génération et stockage de clés qui ne seront accessibles que par Windows (les specs d'IBM contiennent des clés inaccessibles si l'OS change) et qui rendront les documents et programmes protégés par le DRM de MS non décryptables par Linux (une beta de MS Office avec des .doc protégés par DRM est deja disponible) l'étape suivante sera des PCs subventionnés par le DRM, qui refusent de booter autre chose qu'un OS signé par MS (déjà le hardawre de la Xbox et des GSM Windows refusent les binaires non signés par MS) dans une interview récente sur Slashdot, l'avocat de la FSF, Eben Moglen, dit clairement que le "Trusted Computing" pourra tuer les logiciels libres. PS: quelqu'un veut écrire à IBM pour leur demander si la norme TCPA rendra obligatoire de mettre dans le BIOS la possibilité de rendre les clés Windows accessibles à Linux ?
-
[^]Re: TCPA confirmé comme tueur de Linux
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 25/02/2003 à 20:35. (lien). Évalué à 2.Desole c'est pas du tout ca, relis les docs de TCPA et aussi quelques manuels de sécurité sur les crypto-chips et tu verras que d'une part certains comportements qui t'affolent sont tout a fait naturels pour une puce "sécurisée".
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 (page perso, ) le 25/02/2003 à 20:45. (lien). Évalué à 1.apparemment tu sais mieux que IBM ce qu'il y a dans TCPA !
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 () le 25/02/2003 à 21:08. (lien). Évalué à 2.CF la reponse que je t'ai faite plus bas a un post exactement identique.
Kha
(qui commence a trouver qu'il y a de l'echo, doit y avoir un truc creux pas loin)--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
[^]Re: TCPA confirmé comme tueur de Linux
Posté par doublehp (page perso, ) le 03/03/2003 à 18:47. (lien). Évalué à 1.Enfin fo etre tres TES tres bete pour generer un document dans un format que personne ne peut lire , ce serait aussi idiot que de mander aux anglais de conduire a droite a compter du 01/01/2004 ....
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 (page perso, ) le 03/03/2003 à 19:24. (lien). Évalué à 1.il suffit que ca passe a la tele, de faire un peu de pub, et la pillule s avale toute seule ...
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 () le 25/02/2003 à 15:41. (lien). Évalué à 6.>je m'en fous...
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
-
[^]Re: TCPA confirmé pour Prescott
Posté par kb () le 25/02/2003 à 21:05. (lien). Évalué à 3.En clair, Intel, AMD et IBM (Amiga et Mac) sont déjà dans le même bateau.
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 (page perso, ) le 03/03/2003 à 19:06. (lien). Évalué à 1.encore faut il que les fondeurs acceptent de fondre, ou ne nous fassent pas PAYER notre liberte ...
Moi ji dis ... nos papis ils distilaient la nuit, nous on va souder la nuit ...
-
-
Et moi alors !?
Salut Patrick_g,
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 (page perso, ) le 25/02/2003 à 15:37. (lien). Évalué à 2.Bin on ne passe pas à Prescott, on fait la liste de tous les processeurs qui n'intégrent pas TCPA, on optimise à mort tous les codes existants, on apprend à nettoyer la mémoire derrière soi (sous-entendu : on laisse tomber Java pour un bout de temps ;) ), bref, on s'organise pour que nos processeurs à 2 GHz, qualifiés d'ici la fin de l'année de "poussifs" par les marketeux Internet (comme tous les six mois) et on se braque sur Linux... ou on passe à l'Amiga, mais je ne te cache pas que j'aurai du mal, perso. Même si je suis curieux.
-
[^]Re: Et moi alors !?
Posté par Nuks () le 25/02/2003 à 16:28. (lien). Évalué à 6.ben avec un peu de chance ou pourra pousser un peu nos proc si on choper ce qui se fait de + puissant sans TCPA, par exemple un P4 3 Ghz, il suffirait de faire des carte mere bi tri quadri proc (voir +) ce qui nous permetra de pouvoir continuer comme ca ou alors un coup marketing d'un des 3 fournisseur de proc : faire une version non TCPA de ces proc (comme intel avec les num de serie des proc qui ont d'abord été desactivé pour etre ensuite carrément enlevé du proc) qu'il vendrait moins cher et tout les adeptes de la liberté se rueraient dessus sinon cette annonce peut etre l'occasion d'essayer de nos mobiliser soit pour faire annuler cette merde (j'y crois pas trop) soit de promouvoir les processeur non TCPA (je pense que bcp de lecteur de linuxfr sont consulté par leurs proches pour l'achat de matos informatique et donc il faut les prevenir du danger de TCPA et si chacun de nous prevines ne serait-ce que 10 personne avec le nombres qu'ont est on sera suffisament nombre pour pouvoir etre entendu) sinon peut-etre que l'on pourra etre aider par une loi d'un pays a la con (facon de parler) imaginez : le pays técépéastant (de tcpa et resistant) fait une loi rendant le TCPA illegale, les fabricant de proc seront obligé de faire des versions non-TCPA de leurs proc et ce pays deviendra 1er fournisseur de proc pour les linuxiens et autres bon OK, je suis parti un peu dans le délire mais il faut dire que je ne vois pas comment empecher le TCPA de venir nous emmerder (a part peut etre un grace a notre cher president, qui en + d'empecher la guerre en Irak pourrait empecher les société du TCPA de monopilser l'informatique et nous sortant une loi anti-TCPA, on sait jamis)
-
-
[^]Arghhhhhh, un point meurtier !
Posté par One () le 25/02/2003 à 15:39. (lien). Évalué à 1.Désolé, dans ma précipitation, un point s'est sournoisement glissé dans l'url. Ah la sale bete, c'est tellement petit que j'ai rien vu.
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 (page perso, ) le 25/02/2003 à 16:17. (lien). Évalué à 3.effectivement ta news porte exactement sur le même truc...j'suis désolé !! je pense quand même que dans ce cas c'est l'annonce officielle de la part d'Intel...autrement dit nos espoirs d'une fin de l'histoire du type "serial number" s'effondrent. perso je vote PowerPC : en particulier le PPC970 d'IBM qui va cracher le feu !
-
[+] Re: TCPA confirmé pour Prescott
Faut passer sous AMD par exemple. Le seul discourt que comprend les boîtes commerciales, c'est le pognon. Si les ventes baissent, ils vont s'affoler. Acheté autre chose même si c'est plus cher. Il faut montrer que les cpu "non-palladium" ont un marché.
-
[^]Re: TCPA confirmé pour Prescott
Posté par huhuhu () le 25/02/2003 à 15:41. (lien). Évalué à 1.Mais si amd veut rester conforme à la norme Intel compatible, ils seront bien obligés de suivre, non?
-
[^]Re: TCPA confirmé pour Prescott
-
-
[^]Re: TCPA confirmé pour Prescott
Posté par A-Wai () le 25/02/2003 à 15:43. (lien). Évalué à 2.> Faut passer sous AMD par exemple
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 () le 25/02/2003 à 15:46. (lien). Évalué à -2.c'est clair que les apeuls sont plutot bien gaulés, interface à tomber et BSD pour le kernel... seulement je me vois mal faire un crédit pour en acheter un ;)
-
[^]Re: TCPA confirmé pour Prescott
Posté par huhuhu () le 25/02/2003 à 15:56. (lien). Évalué à 0.Et pis on bidouille pas comme dans un pc avec un mac.
-
[^]Re: TCPA confirmé pour Prescott
-
-
[^]Re: TCPA confirmé pour Prescott
Posté par patrick_g (page perso, ) le 25/02/2003 à 16:13. (lien). Évalué à 1.ben..... les IBooks sont pas si chers !!! perso c'est ma solution de repli face aux CPU espions.
-
-
[^]Re: TCPA confirmé pour Prescott
Posté par notrya2 () le 25/02/2003 à 15:58. (lien). Évalué à 9.Faut être dans une "vision globale". Si Intel sort un cpu palladium avant AMD. Que les ventes de ce cpu sont faibles, alors AMD va réfléchir même s'ils sortent un cpu palladium.
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 Morreale Jean Roc () le 25/02/2003 à 17:16. (lien). Évalué à 2.eptite correction mais néanmoins utile : amd ne sortira pas un cpu palladium mais un cpu avec lspec TCPA, ce qui est un poual différent. De plus dans une doc officielle AMD pointé sur le fait que l'utilisateur aurait le choix de l'utiliser ou pas
-
-
[^]Re: TCPA confirmé pour Prescott
-
-
[^]Re: TCPA confirmé pour Prescott
Posté par Alberto () le 25/02/2003 à 15:56. (lien). Évalué à 5.Faut pas acheter ces processeurs et acheter les anciennes versions ou ceux qui n'integrent pas ces technologies. Intel a plie avec son serial number, il pliera avec son TCPA.
-
[^]Re: TCPA confirmé pour Prescott
Posté par Toufou (page perso, ) le 25/02/2003 à 17:04. (lien). Évalué à 1.Il n'y a plus de numéro de série sur les P4 ?
-
-
[^]Re: TCPA confirmé pour Prescott
D'autres cpu?
N'y a t'il que deux Fondeurs, ne peu t ' on pas choisir des procs differents: geode, c3, arm ou crusoe. . . d'accord ils sont petit mais en cluster ca devrais faire le boulot non.
-
[^]Re: D'autres cpu?
Posté par Dalton joe (page perso, ) le 25/02/2003 à 15:56. (lien). Évalué à 1.Ah j'oubli, je pensais a openbrick.
http://www.openbrick.org(...)-
[^]Re: D'autres cpu?
Posté par Backbone () le 25/02/2003 à 16:15. (lien). Évalué à 1.je ne pense pas que le monde professionnel représente la totalité des les parts de marché des deux leaders Intel & AMD, et entre nous je me vois mal jouer à DOOM III sur un minable crusoé :)) PS : crusoé vs Itanium II en clustering... -> 1000 crusoés pour faire l'équivalence à 10 Itaniums :))) (même si j'exagère ça me fait bien marrer ;)
-
[^]Re: D'autres cpu?
Posté par Alberto () le 25/02/2003 à 17:28. (lien). Évalué à 1.Regarde ce que pense Linus de l'itanium... http://www.theinquirer.net/?article=7966 Bon theinquirer.net -1.
-
[^]Re: D'autres cpu?
Posté par matiasf () le 26/02/2003 à 03:59. (lien). Évalué à 4.Un petit hommage au réalisme du x86 et une petite "claque" à ceux qui ne croient qu'aux cpu 100 % RISC :
- "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 (Jabber id, page perso, ) le 25/02/2003 à 16:19. (lien). Évalué à 5.Super, un cluster domestique de 15 machines pour pouvoir executer OpenOffice ;-) On l'envoit à qui la facture d'electicité :-)
[+] Re: TCPA confirmé pour Prescott
on va ressortir les fers a souder ... je sens qu'on a pas fini de cramer du proco !
Re: TCPA confirmé pour Prescott
TCPA/TPM et Palladium/SCP sont 2 systéme concurent avec des objectif different, Palladium n'a pas besoin de TCPA et resiproquement. Le terme informatique de confiance reprit par les 2 systéme a des but different. TCPA/TPM c'est en gros standardisé le cryptage via des composent comparable a des cartes USIM et SIM, ou encore des clée USB, voir a plus long terme permetre le cryptage de disque dur ou autre, le tout d'un environement qui verifie lui méme son integrité, d'ou le nom de Platefrome de confience et donc d'informatique de confience. TCPA est un standar, les specifiation sont disponible et tout et tout. Palladium/SCP dont on ne sait rien pour le moment, c'est celon les dire des commerciaux de MS, avent tout un system de certification et de cloisonemant, de tout ce qui touche le PC. En gros un tier de confience via un systéme complexe de certification dira si oui ou non telle composent materiel ou logiciel est certifié, et le systéme cloisonera soignieusement les composent certifiés des composents non certifié, a aucun moment il n'est fait mention de cryptage, si leur systéme est efficasse il n'est méme pas necessaire. Mais ce systéme est beaucoup plus risqué puisque le tier qui sera sans doute Microsoft gagne un pouvoir enorme sur votre machine et sur ce que vous pouvez ou non faire avec votre OS certifié MS. Arretté de casser abusivement du sucre sur TCPA, ce systéme n'est peut étre pas parfait, et je comprends que certains ne voit pas son utilisé et le fait qu'il devienne un standar et qu'il soit livré avec les CPU Intel, mais taper aveuglement n'est pas une solution et decredibilise la lute contre un Palladium/SCP qui c'annonce ouvertement liberticide.
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
-
[+] [^]Re: TCPA confirmé pour Prescott
Posté par Julien CARTIGNY (page perso, ) le 25/02/2003 à 16:43. (lien). Évalué à -1.Merci ma poule *smack*
--
"Nobody expects the spanish inquisition"
-
[^]Re: TCPA confirmé pour Prescott
Posté par TSelek () le 25/02/2003 à 17:16. (lien). Évalué à 2.Euh les clés USB pour le moment c'est encore un peu, comment dire... pas secure, ou pas prêt. Pour les USIM/SIM, on parle plutôt de SAM (Security Access Module) qui sont en fait des cartes à puces. Tout ça c'est des cartes à puces, c'est juste le facteur de forme (et maintenant avec l'USB, le type d'interface aussi) qui change : carte crédit, SIM, BGA, USB... Donc tu as raison, TCPA ça existe déjà en fait, on en trouve sur certains PC IBM depuis plus d'un an.
-
[^]Re: TCPA confirmé pour Prescott
Posté par Jerome Herman () le 25/02/2003 à 17:19. (lien). Évalué à 10.Sincerement Beretta_Vexee, reussir a redire sur 240 forums une verite premiere que personne ne veut entendre sans te lasser ca force le respect. Pour ceux qui n'auraient pas suivi TCPA est effectivement innofensif en ce qui concerne les libertes individuelles. C'est juste un systeme hardware qui permet d'encoder et de decoder a la volee des flux d'informations en utilisant des clefs stockees sur la puce donc theoriquement inaccessible. Il n'y a pas de clefs par defaut, ou de systeme de controle, ou de certifications exterieures par defaut. La pire chose qui puisse se produire c'est qu'un serveur exige une certification TCPA avant de vous laisser vous connecter(exactement de la meme facon qu'aujourd'hui pour acceder a certains sites vous devez avoir un SSL). Vous n'avez pas envie que ce serveur puisse vous reconnaitre quand vous reviendrez ? Ben vous creez une identite (ie clef TCPA capable de generer un certificat pour l'exterieur) vous vous connectez, vous faites ce que vous voulez et vous detruisez votre identite. Rien de grave la dedans. Kha
--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé pour Prescott
Posté par free2.org (page perso, ) le 25/02/2003 à 17:40. (lien). Évalué à 6.dans les specs TCPA d'IBM il y a la possibilté de créer des clés qui ne seront plus accesisbles si l'OS change peux-tu me dire pourquoi MS n'utilisera pas cette fonction pour interdire à Linux d'accéder aux clés qui cryptent des programmes et des documents DRM ? dès lors ces programmes et documents ne seront accesibles que sous windows (cf beta de MS Office avec des .doc cryptés) enfin, tu avoueras que ce sera très peu couteux de modifier TCPA pour qu'il interdise de booter un OS non signé par MS, et sans qu'on puisse désactiver cette fonctionalité dans le BIOS
-
[^]Re: TCPA confirmé pour Prescott
Posté par Jerome Herman () le 25/02/2003 à 18:13. (lien). Évalué à 7.peux-tu me dire pourquoi MS n'utilisera pas cette fonction pour interdire à Linux d'accéder aux clés qui cryptent des programmes et des documents DRM ? Oh ils le feront, c'est sur. La question est de savoir est-ce que ca va me limiter ? Non ! Dans le cas ou j'ai envie d'avoir mon doc crypte, il me suffit de le crypter de n'importe quelle autre facon (TCPA comprise) pour pouvoir y avoir acces tranquilement sous linux. La seule chose que ca m'interdit est le cryptage exclusif de MS(ie cryptage dans le cas ou je n'ai pas envie de transmettre mes donnees sur un autre ordi). Rien ne m'empeche de crypter mon doc en dehors d'Office. Et la je suis peinard. En ce qui concerne les programmes, soit je les ai code mois meme et si je les cryptes c'est mon probleme. Soit ils viennent de l'exterieur auquel cas la clef est generee en software puis stocker sur le hardware. La encore pas plus de limitation que si j'etais en pur software. Si je veux mettre la clef sous linux je vais me casser les pieds avec du reverse engeneering, mais le travail sera la meme quand software pur vu que la clef n'est pas presente d'office dans ma puce TCPA. enfin, tu avoueras que ce sera très peu couteux de modifier TCPA pour qu'il interdise de booter un OS non signé par MS, et sans qu'on puisse désactiver cette fonctionalité dans le BIOS J'avoue, j'avoue, mais avoue a ton tour que 1) Pour l'instant ca n'est pas le cas (il serait de meme tres peu couteux d'empecher un formatage en EXT2 ou 3 dans le controleur IDE et ca ne s'est jamais fait) 2) Ce n'est pas du tout le chemin que prend Intel pour l'instant. Vu la geule des nouveaux Bios il sera possible de "cacher logiciellement" une morceau du disque, le code bios complet, tel ou tel periph etc... En d'autres termes meme si un jour Windows exige d'occuper tout l'espace disque et de booter sur un bios certifie, on pourra lui faire croire que c'est le cas alors qu'en fait on a une partition linux juste a cote mais qu'il ne peut meme pas la voir. 3)Cette modification pour avoir un sens implique une fois de plus que TCPA est livre de base avec des clefs precharges. Sans quoi il faut transferer la clef logiciellement. Le jour ou un prog quel qu'il soit me demandera d'avoir acces a mon bios (qui est toujours protege par pass sur mes machine) et ben le cd ira apprendre a voler. Idem pour un prog qui essayerais d'aller ecrire dans ma puce TCPA. En l'etat TCPA n'est pas un danger. Il est effectiveemnt possible qu'il y est derive, mais TCPA etant une norme il faudrait que la version derivee porte un autre nom (meme si c'est TCPA 2.0). Et la oui on pourra ouvrir le feu. Mais on ne va pas s'acharner sur une norme ouverte, pour laquelle on a deja une implementation cote soft en GPL et qui part vraiment d'un bon sentiment pour ce qu'elle pourrait eventuellement devenir dans le pire des cas. On a pas mal de vrais problemes en tant que defenseur du libre, alors pourquoi se battre contre des moulins a vent ? Kha
--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé pour Prescott
Posté par free2.org (page perso, ) le 25/02/2003 à 18:41. (lien). Évalué à 4.apparemment tu attaches peu d'importance à tout le travail qui a été effectué par koffice/abiword/gnumeric/openoffice/samba/etc pour que linux puisse accéder aux formats utilisés par défaut dans windows.
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 () le 25/02/2003 à 19:11. (lien). Évalué à 7.apparemment tu attaches peu d'importance à tout le travail qui a été effectué par koffice/abiword/gnumeric/openoffice/samba/etc pour que linux puisse accéder aux formats utilisés par défaut dans windows.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé pour Prescott
Posté par free2.org (page perso, ) le 25/02/2003 à 19:34. (lien). Évalué à 3.Si par défaut les documents créés par les logiciels de MS sont cryptés avec une clé TCPA non accessible par LInux, alors cela va rendre bien plus difficile l'utilisation de ces documents par Linux: il faudra demander à la personne qui a créé le document de le sauvegarder sous un autre format.
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 (page perso, ) le 25/02/2003 à 19:37. (lien). Évalué à 3.(je reprend une partie de l'article que je viens d'envoyer à linuxfr)
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 () le 25/02/2003 à 21:04. (lien). Évalué à 7.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 !
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 25/02/2003 à 21:23. (lien). Évalué à 2.ce que tu ne comprends pas c'est que MS peut utiliser le mode "paranoiaque" pour ajouter une couche de cryptage à des fichiers qui sont déjà cryptés par une autre méthode.
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 (page perso, ) le 25/02/2003 à 22:18. (lien). Évalué à 5.Oui mais la le document n'est meme plus lisible par une autre machine, meme sous windows.
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 25/02/2003 à 22:56. (lien). Évalué à 0.les softs MS peuvent le décrypter sous ton Windows et l'envoyer à quelqu'un
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 (Jabber id, ) le 25/02/2003 à 23:52. (lien). Évalué à 5.Genial, peuvent déjà le faire avec une clée unique pour tout les document office et la DMCA, EUCD t'interirait d'essayer de la percer.
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.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 26/02/2003 à 21:45. (lien). Évalué à 2.Entierement d'accord,
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 () le 26/02/2003 à 22:08. (lien). Évalué à 1.En fait tu peux faire certifier ton kernel en TCPA. 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 il n'y a pas de certification TCPA.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 27/02/2003 à 17:13. (lien). Évalué à 1.Cette methode est dependante des process de certification et n'est donc pas publique
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 () le 27/02/2003 à 17:51. (lien). Évalué à 1.Je te l'accorde le terme certification est mal choisit. Le probleme vient du fait qu'en francais j'ai du mal a traduire "trusted" (digne de confiance ie certifie) et "certified" (certifie par un tiers).
Ce que je voulais dire c'est qu'on perd le trust TCPA. Rien a voir ave cun certificat delivre par une tierce partie. C'est vrai que ma phrase est tres mal formulee et laisse entendre quelque chose de completement faux. Merci d'avoir releve.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman () le 27/02/2003 à 17:58. (lien). Évalué à 1.Reformulation d'un de mes posts qui peut preter a confusion.
En fait tu peux creer une trust sur ton kernel. Si dans ton PCR tu demande que le kernel soit compris dans le hashage du boot, tu peux aussi demander a ce que le boot se bloque si ce trust est absent.
Le kernel ne "communique pas" avec TCPA, c'est lors du hashage du kernel que TCPA va se rendre compte tout seul suite a la facon dont le kernel va s'initialiser que c'est un OS digne de confiance ou non(ie si il reconnait une sequence de boot qu'il a deja vu ou pas.). Cette methode est dependante des process de certification et n'est donc pas publique. Par contre on peut parfaitement demander au PCR de laisser l'OS booter, on perd le trust TCPA c'est tout.
kha
vraiment desole pour la confusion que ce post aura pu creer. Mea Culpa.--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman () le 25/02/2003 à 22:27. (lien). Évalué à 5.ce que tu ne comprends pas c'est que MS peut utiliser le mode "paranoiaque" pour ajouter une couche de cryptage à des fichiers qui sont déjà cryptés par une autre méthode.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 25/02/2003 à 22:51. (lien). Évalué à 1.je te conseille de lire les nouveaux liens qui sont en bas de la FAQ TCPA de Ross Anderson:
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 () le 26/02/2003 à 00:50. (lien). Évalué à 2.The potential evil of the specification comes from three distinct points. The first is a non-malleable trusted root for trusted storage. The second is the inability to disable ALL of the functionality of the TPM, and the third is the inability to provide a reasonable degree of privacy.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 26/02/2003 à 00:56. (lien). Évalué à 1.c'est encore plus grave que ça:
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 () le 26/02/2003 à 14:56. (lien). Évalué à 3.Oui sauf que ce slide est bourree d'erreurs, d'approxiamtions voir de mensonges grossiers.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay () le 26/02/2003 à 15:07. (lien). Évalué à 1.Ces slides pretendent que la puce est "tamper proof" ce qui est completement faux,
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 ?--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman () le 26/02/2003 à 15:20. (lien). Évalué à 1.Il n'empeche que la norme ne specifie pas que la puce doit etre tamper resistant ou tamper proof, ce qui est annonce dans le doc.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay () le 26/02/2003 à 15:46. (lien). Évalué à 1.Il n'empeche que la norme ne specifie pas que la puce doit etre tamper resistant ou tamper proof, ce qui est annonce dans le doc.
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.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman () le 26/02/2003 à 16:21. (lien). Évalué à 1.Ben pas vraiment en fait. Si la puce est sur le south bridge et pas l'interrieur du CPU il te suffit de te pluger sur les pattes de la puce pour la lire. Tant que la puce est un element independant tout va bien, il n'y a pas besoin de l'ouvrir pour la lire our pour sniffer les echanges puce-cpu.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 26/02/2003 à 15:24. (lien). Évalué à 0.tiens a propos quelqu'un sait où se trouve dans la doc TCPA le fait que un OS non certifié ne peux pas utiliser les fonctions d'authentification de TCPA ?
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman () le 26/02/2003 à 15:56. (lien). Évalué à 2.Dans la doc c'est la section 4.10 qui donne les differentes relations qui peuvent ou doivent etre etablie lors de la creation de clef.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay () le 26/02/2003 à 15:03. (lien). Évalué à 1.Quel est l'interret de tous ça avec ce qui se fait déjà ? C'est-à-dire crypto type RSA + carte à puce à clavier ?
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 ?--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Beretta_Vexee (Jabber id, ) le 26/02/2003 à 15:21. (lien). Évalué à 1.La Clée unique sert uniquement a s'assurer que c'est bien a la méme puce que tu a affaire et non une autre puce vierge ou un composent remplacé, c'est bien beau d'avoir une super puce si il suffit de genere un jeux de clée sur une puce vierge et de remplacer la puce sur la machine attaqué pour passer les protections.
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.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay () le 26/02/2003 à 15:43. (lien). Évalué à 1.En quoi a-t-on besoin de ça ?
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 ?--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman () le 26/02/2003 à 16:36. (lien). Évalué à 1.Les certificats font déjà ce boulot.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay () le 26/02/2003 à 18:54. (lien). Évalué à 1.Ta première partie tent à faire penser que tu trouves tout à fais normal d'avoir un bout de hard que tu ne controles absoluement pas et qui permet de t'identifier ?
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 !--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman () le 26/02/2003 à 20:50. (lien). Évalué à 1.Ta première partie tent à faire penser que tu trouves tout à fais normal d'avoir un bout de hard que tu ne controles absoluement pas et qui permet de t'identifier ?
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par boubou (page perso, ) le 27/02/2003 à 09:52. (lien). Évalué à 1.Juste une remarque : les organismes de certification ne certifient en fait pas grand chose. Si tu regardes les conditions générales de vente, c'est souvent risible. De façon général, le système des certificats n'a pas de raison de mieux marcher en informatique qu'il ne marche pour d'autres choses, comme par exemple la certification comptable (cf enron) ou celle des bateaux (pas besoin d'exemple, n'est-ce pas). En fait, je n'ai pas particulièrement confiance en verisign, par exemple et le fait que DLFP soit auto certifié ne me gêne pas plus que ça. Bruce Schneier a fait des analyses très intéressantes sur les systèmes de certification qui contiennent des critiques plus intéressantes que les miennes (cf http://www.counterpane.com/publish.html(...)).
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 () le 27/02/2003 à 14:41. (lien). Évalué à 1.Oui certainement le principe de certification actuel n'est pas parfait, n'empeche qu'avoir un organisme independant qui intervient au millieu du processus c'est quand meme plus sur que si chacun peut faire ce qu'il veut.
Si je m'autocertifie cela veut dire que tu dois me faire confiance pour pouvoir me faire confiance. Il y a un hic quelque part.
Maintenant libre a toi de faire confiance (ou pas) a Verisign ou a un autre certificateur. Rien ne t'y oblige, si tu vois un certificat produit par une boite que tu ne juges pas digne de confiance tu le refuse. Point final.
Si tu n'a pas confiance en ta clef TCPA tu la desactive. Pas de differences majeures.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 28/02/2003 à 09:46. (lien). Évalué à 1.le principe du web of trust de gnupg, c'est que tu ne fais confiance qu'à tes propres yeux: seules les clés certifiées par une personne que tu as physiquement rencontrée et en qui tu as confiance sont dignes de confiance. tu ne remets pas ta confiance entre les mains d'un organisme "indépendant" qui en fait dépend toujours soit d'un grande multinationale (une de celles de TCPA) soit d'un gouvernement. enfin, ne pas utiliser les certificats TCPA c'est se priver des documents DRM protégés à l'aide de ces certificats donc oui: 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é.
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman () le 28/02/2003 à 15:08. (lien). Évalué à 1.enfin, ne pas utiliser les certificats TCPA c'est se priver des documents DRM protégés à l'aide de ces certificats
Nurf ? A ben ca ca serait bien si DRM utilisait les privates CA pour faire de la protection. Vu que les privates CA ne sont pas scellable (on ne peut pas les associer avec un PCR). Hop certificat, et je fais ce que je veux de ma musique.
TCPA est un progrès énorme en matière de DRM puiqu'il permettra d'envoyer des documents lisibles uniquement par une personne dont un organisme "dépendant" connait l'identité.
Pour connaitre mon identite, il faudrait que le mec il est construit mon ordinateur (donc il connait ma EK), il m'est vendu mon ordinateur (donc il me connait), il est validee mon certificat (c'est lui qui a cree la preuve que mon certificat etait valide), il soit mon fournisseur de contenu (c'est lui quime vend les doccuments DRM). La c'est meme plus une conspiration, c'est une ligue mondiale. Le taiwanais en bas de chez moi est un agent a la solde de la DRM. Avant de me vendre une cart mere il releve scrupuleusement le numero de serie....
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Beretta_Vexee (Jabber id, ) le 26/02/2003 à 21:01. (lien). Évalué à 1.Bas non l'interet de la carte a puce c'est que la clée privé reste dans la carte, si ta puce n'est pas certifié, alors il suffit de genere un nouveaux jeu de clée publique et privé, sur une puce vierge et de les remplacer pour passer outre le systeme.
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 )--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par boubou (page perso, ) le 27/02/2003 à 10:12. (lien). Évalué à 1.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)
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 () le 27/02/2003 à 15:28. (lien). Évalué à 1.Oui c'est vrai que les deux facteurs rentrent en ligne de compte. Il y a l'aleatorite et la predictibilite.
Generalement pour s'assurer que les nombres sont generes independament les uns des autres on utilise du chaos (heure qu'il est, uptime, evenements claviers/souris). Mais meme comme ca il est extrement difficile de savoir si oui ou non la clef est inpredictible en fonction de ses antecedents(NB : pas au sens ou l'on connait la clef, au sens ou n peut limiter les domaines dans lesquels elle peut se trouver). C'est effectivement extremement complexe a faire. RSA a mis pres de dix ans a trouver une faille de ce type dans un de ses protocoles (en fait probablement moins, en tout cas ils ont mis dix ans a l'annoncer). On peut par exemple en fonction d'un nombre en deduire que le suivant contiendra au moins un 6, qu'en base 12 certains chiffres seront fixes, qu'une suite de chiffre sera presente dans la clef etc..
Ca c'est clair que c'est vachement baleze a tester. Je pense que meme si on avait le code du RNG (qui j'en suis sur inclut du chaos a un moment ou a un autre) il faudrait un moment pour savoir si les suites sont predictibles.
A ma connaissance la seule methode possible pour tester ca c'est de faire un reseau de neurone monstrueux et de voir si il es capable de deviner la suite. Le seul truc est que ca risque un peu de ressembler a SETI@HOME...
Donc c'est possible, c'est faisable, c'est lourd et c'est long...
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par boubou (page perso, ) le 28/02/2003 à 12:25. (lien). Évalué à 1.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
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 () le 28/02/2003 à 15:13. (lien). Évalué à 1.Ah bon, autant pour moi...
Il me semblait qu'avec un reseau de neurones du type de ceux qu'on a utlise pour "predire" la suite du signal lors d'une emission laser, on aurait pu fair eune approche. Mais ce n'est pas mon fort...
Si je devait faire une deuxieme tentative je dirais "hashage stochastique". Mais la c'est encore plus vague pour moi.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 28/02/2003 à 12:31. (lien). Évalué à 1.fait attention à ton usage du mot chaos: le chaos désigne des fonctions mathématiques déterministes qui ont des propriétés précises comme la sensibilité aux conditions initiales: ces fonctions sont utilisées dans les pseudo générateurs aléatoires qui ne suffisent pas à eux seuls à faire une bonne crypto
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 (page perso, ) le 03/03/2003 à 20:11. (lien). Évalué à 1.> 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 ?
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 (page perso, ) le 03/03/2003 à 20:22. (lien). Évalué à 1.Zut y a une faille a mon truc : la FJ a peut etre considere que les moyens a mettre en oeuvre pour casser un tel system sont largement superieurs au gain que l on peut obtenire en cassant ce system ( au rapido il y a pas des millions a gagner, mais dans le meilleur des cas c est 5000F je crois ... ), et si la FJ constate que la probabilite de gain augment trop en un lieu ou a une date precide, ils risquent de tout mettre en oeuvre pour mener une enquette ( policiere et scientifique ) en bon eduforme ( c est comme ca que ca s ecrit ? ) pour en trouver la raison ...
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 () le 26/02/2003 à 15:50. (lien). É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 () le 26/02/2003 à 17:11. (lien). Évalué à 1.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?)
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran () le 26/02/2003 à 18:47. (lien). É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 () le 26/02/2003 à 19:27. (lien). Évalué à 1.Ma question est: pourquoi ce scenario n'est pas possible sous TCPA?
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran () le 26/02/2003 à 20:06. (lien). É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 () le 26/02/2003 à 21:04. (lien). Évalué à 1.Oui mais attention, si on parle Palladium et DRM , on est completement dans un autre debat. Le seul et unique but de mes interventions nombreuses dans ce thread (alors que normalement je pond au max un post par mois) c'est de demontrer que DRM/Paladium et TCPA sont des entites completements distinctes. TCPA n'aide en rien ni DRM ni Paladium. Il ne fait pas obstacle au libre en l'etat, et il peut s'averer reellement utile a l'utilisateur final.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran () le 27/02/2003 à 13:21. (lien). Évalué à 2.Je parle de Palladium et de DRM a titre d'exemple! Ce que je montre (et jusqu'a present, tu n'as pas remis en question mon modele), c'est qu'on peut utiliser TCPA tel qu'il est, pour implementer un systeme (par exemple DRM) qui planquent des donnees de facon que l'utilisateur ne puisse jamais y acceder.
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 () le 27/02/2003 à 15:41. (lien). Évalué à 1.c'est qu'on peut utiliser TCPA tel qu'il est, pour implementer un systeme (par exemple DRM) qui planquent des donnees de facon que l'utilisateur ne puisse jamais y acceder.
Dans TCPA il n'y a pas de donnees auquelles l'utilisateur ne peut pas acceder. Ca n'existe pas, il y a une clef qu'il ne peut pas effacer (mais qu'il peut desactiver), masi il n'y a pas de donnees que tu ne puisse consulter, deplacer, copier ailleurs.
Le schema que tu propose ne tiens pas la route. De deux choses l'une soit la clef est dependante du du schema de boot, soit elle ne l'est pas.
Si elle est dependante du schema de boot la puce TCPA ne va pas utiliser cette clef directement mais utiliser cette clef+un cryptage pour eviter que meme quelqu'un qui connait la clef puisse s'en servir en dehors du "bon" schema de boot. Meme si microsoft te redonne une clef, comme le schema d eboot a changer, le cryptage supplementaire changera : il n'y aura pas moyen d'aller te redonner la clef parceque microsoft ne connait pas le cryptage lie a ton schema de boot.
Pour etre vraiment clair : Ce qui a ete crypte avec un schema de boot ne peut etre decrypte qu'avec exactement le meme schema de boot. Ce qui a ete encrypte sans schema de boot peut etre decrypte par n'importe qui qui possede le pass, independament de l'OS et des changements de hardware.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 27/02/2003 à 16:56. (lien). É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.
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 () le 27/02/2003 à 20:00. (lien). Évalué à 1.moi je cite un document où il est marqué que l'utilisateur n'a pas accès au contenu du random generator
Relit ton doccument il est dit que l'utilisateur n'a pas acces aux etapes intermediaires.
et comme TCPA autorise l'ajout de fonctionnalités par les constructeurs (et par l'auteur du BIOS, je pense), pourquoi une fonctionnalité "protection de toutes les données TCPA" ne serait-elle pas ajoutée ?
TCPA autorise a ce que la puce soit integree a un autre composant. Il y a dans la doc une les fonctions qui doivent etre accessible au boot, a partir du bios et logiciellement sous l'OS. Comme on ne peut pas enlever de fonctions, on est peinard.
Par contre je n'ai pas vu ou il est dit que l'on puisse rajouter des fonctionalites a TCPA. tu peux me filer une reference precise ?
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 27/02/2003 à 20:09. (lien). Évalué à 1.Relit ton doccument il est dit que l'utilisateur n'a pas acces aux etapes intermediaires.
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 () le 27/02/2003 à 21:37. (lien). Évalué à 1.je me rappelle avoir lu cela en effet, mais je n'ai plus la page exacte en mémoire. dans ma page free2.org/tcpa/ je donne les références de la page qui précise qu'on peut intégrer TCPA dans une puce qui a d'autres fonctionalités (et il n'est pas interdit que cette puce ait des fonctionnalités de sécurité, y compris des fonctions liées à TCPA)
Il n'est pas non plus interdit de greffer mon controlleur IDE sur une puce qui va empecher le formatage en EXT3 en utilisant ou en bloquant des fonctions de ce controleur. N'empeche que meme si ca se produit ce n'est pas la norme. IDE est innocent si jamais ca se produit.
si c'est le cas, peux tu me dire à quelle page il est dit que le bios doit obligatoirement permettre à l'utilisateur de copier/modifier les clés contenues dans TCPA ?
Pas de creer/modifier/copier des clefs depuis le bios (encore que rine ne l'interdise), mais de s'assurer que l'on puisse passer en mode de controle total du TPM (ie que l'on recupere les droits, meme si ce n'est pas utilisable de suite)
Pardon oublie de ma part, c'est dans la doc TCPA section 2.6.1, page 19
If a TPM does not have an Owner, it is desirable to provide a method that enables or disables the process by which a prospective Owner takes ownership of a TPM. Ideally this method would work both locally and remotely. Unfortunately authenticated commands cannot be interpreted by the TPM if it does not have an Owner. Hence the method of enabling or disabling the process of taking ownership is a local command, and no remote option is provided. (In a PC, these local controls could be made available during the POST, for example.)
La section 2.6.2 indique aussi un certains nombre de mesures a prendre si il n'y a pas d'owner pour le TPM, et suggere un certains nombre de solutions pratiques avant de donner le diagramme general de resolution des etats.
Physical presence authorizes the changing of the TCPA_PERSISTENT_FLAGS -> ownership flag.
Il faut qu'une intervention physique permette d'autoriser les prises de controle du TPM (section 8.13 page 252). La section 8.13.1 nous indique ensuite que si il n'y a pas de owner, il faut que l'on puisse ne creer un moyennant acces physique. (N.B en section 2.6.1 on a vu que la seule facon de s'assurer d'un acces physique etait de rendre les operations possibles seulement avant le boot de l'OS)
Donc avant le boot de l'os je suis Owner du TPM. Ce qui m'autorise a faire tout ce que je veux avec jusqu'a l'extiction de ma machine.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 28/02/2003 à 02:24. (lien). Évalué à 1.petit rappel: Linux peut fonctionner avec plein de formats de partition. bloquer les formatages ext2/ext3 dans un IDE ne bloquerait pas Linux, mais serait interprétable illico comme un abus de position de dominante.
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 () le 28/02/2003 à 15:21. (lien). Évalué à 1.Ben oui mais si il n'y a pas de owner du TPM, la puce TCPA ne peut pas fonctionner du tout. Donc elle ne sert a rien. Le but de mon post etait juste de faire une liste des fonctions qui doivent, auraient interet a, et pourraient etre integree dans le BIOS.
Si on me vend un TCPA sans Owner et sans moyen d'en creer un de facon secure (ie avant le boot de l'OS ce qui assure une presence physique), ma puce ne fait rien. Pas de TPM initialise, pas de stockage de clef.
Ce point n'est donc pas du tout un trou de securite, ou une opportunite pour une personne de se servir de TCPA contre toi. C'est juste "desirable" parceque dans le cas ou la creation d'un owner a echouee, sans ce systeme il faut renvoyer la puce a l'usine pour pouvoir s'en servir.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran () le 27/02/2003 à 19:20. (lien). Évalué à 1.Il y a un manque de communication. On ne se comprends pas.
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 () le 27/02/2003 à 20:31. (lien). Évalué à 1.Elle ne l'est pas. C'est clair? ELLE NE L'EST PAS!
Windows ZP applique ce procede et "scelle" la fameuse cle avec le PCR courant.
Choisit une de ses deux phrase, celle que tu veux et tu fiches l'autre en l'air.
Si ta clef ne depend pas du harware, et qu'elle est jsute stoquee dans un PCR "brut de fonderie" tu reboote, tu prend les droits owner sur le TPM et tu la copie ou tu veux, tu peux meme la passer en mode migrable et l'envoyer a tes amis.
Si elle est proteger par le PCR (ie encryption supplementaire dependante du boot) on tombe dans les cas que j'ai ennonce plus haut.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org (page perso, ) le 28/02/2003 à 09:55. (lien). Évalué à 1.tout ton rainsonement repose sur le fait qu'il sera obligatoire de donner le controle de TCPA au possesseur du PC. or dans la norme on peut lire qeu cela est "desirable" (je cite). d'ailleurs IBM dit clairement dans son PDF: "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" avant de dire que cela obligerait à retélécharger les documents si on change quoique ce soit à la config du PC. Mais c'est justement ce que veulent les éditeurs de DRM ! En +, au lieu d'avoir à retélécharger les documents, on pourrait n'avoir à recharger que une clé non tcpa, protégée par le PCR, et inutilisable si la config change. Ce qui serait le DRM parfait. Bref: TCPA est une avancée majeure pour le DRM !
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman () le 28/02/2003 à 15:59. (lien). Évalué à 1.tout ton rainsonement repose sur le fait qu'il sera obligatoire de donner le controle de TCPA au possesseur du PC. or dans la norme on peut lire qeu cela est "desirable" (je cite).
Non la norme dit que c'est "desirable" d'avoir une methode qui permet de creer un owner sur une puce qui n'en a pas sanst renvoyer le PC a l'usine.
Si je boote sans les droits Owner je ne peut pas faire grand chose avec ma puce. Regarde lasection 7 du doc TCPA. Pour stocker, lire, ecrire, sceller ou migrer une clef j'ai besoin d'avoir une autorisation declaree soit sur l'entite, soit sur la clef elle meme.
Qui cree les entites ? le owner :
The creation of the authorization data is the responsibility of the entity owner. (section 5.4 de la doc)
Qui accorde les droits ? Le owner(desole pour le barbarisme a repetiton mais "possesseur" ca me fait bizarre, je suis preneur d'une bonne traduction) :
All entities from the Owner to the SRK to individual keys and data blobs have authorization data. This data may need to change at some point in time after the entity creation. The ADCP allows the entity owner to change the authorization data. The entity owner of a wrapped key is the owner of the parent key.(section 5.5 de la doc)
Qui change les droits ?(tous en coeur maintenant)
The TPM_ChangeAuth command allows the owner of an entity to change the authorization data for theentity..(section 5.6)
Qui gere le owner ? (attention il n'y a pas de piege)
The TPM_ChangeAuthOwner command allows the owner of an entity to change the authorization data for the TPM Owner or the SRK.
Et oui c'est le Owner aussi.
Bref si j'ai pas les droits a la fois sur le SRK et sur le TPM, je peux pas bouger(pas plus que les programmes qui tournent avec mes droits d'ailleurs). Ma puce ne me sert a rien.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
-
-
-
-
[^]Mais quel est l'interret du test PCR !!
Posté par Nicolas Boulay () le 27/02/2003 à 09:34. (lien). Évalué à 1.elle devient inaccessible en cas de changement de hardware ou d'OS (la elle est illisible par linux)
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.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: Mais quel est l'interret du test PCR !!
Posté par Jerome Herman () le 27/02/2003 à 15:50. (lien). Évalué à 1.En quoi, cela aide à la sécurité de mes clefs privés ?
Le fait de proteger les clefs privees via un PCR permet d'etre sur qu'un petit malin qui boot sur une disquette ne va pas aller tout recuperer et trente seconde. C'est tout.
Imagine que l'on te vende un fichier de son crypté pour ta machine, Seul un logiciel du bon OS pourra décripter ce fichier.
Pour faire cela, il faudrait soit que le mec qui te vend le fichier son vienne chez toi, soit qu'il possede une copie exacte de ta machine chez lui. La oui il peut t'obliger a booter sous un OS certifie DRM parcequ'il a ete capable de generer une clef PCR compatible avec ta machine. Ca devient techniquement possible. Ca oblige juste le vendeur de son a avoir une copie de toutes les machines "legales" possibles chez lui, ou a envoyer un technicien a domicile a chaque fois que tu veux ecouter une chanson. Un peu lourd non ?
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Nicolas Boulay () le 26/02/2003 à 18:58. (lien). Évalué à 1.La clef peut toujours étre échangé par un système automatique par le net comme le windows update.
--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
-
-
-
[^]Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par doublehp (page perso, ) le 03/03/2003 à 19:25. (lien). Évalué à 1.> le reouvrir si tu change quoi que ce soit en hard sur ta machine etc..
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 (page perso, ) le 26/02/2003 à 09:21. (lien). Évalué à 1.Une question puisque tu sembles bien connaître le problème. J'ai lu quelque part qu'il était prévu dans la norme TCPA de n'autoriser le boot que si tout est certifié, en particulier le BIOS lui-même. Plus précisément, l'accès aux clés stockées dans la puce TCPA n'est possible que si tout va bien, dont le bios. Est-ce vrai ? Dans ce cas, ton point 2 ne tient pas, me semble-t-il, à condition bien sûr qu'on puisse interroger la puce pour savoir si elle a "signé" le boot, ce qui me semble quand même une évidence.
-
[^]Re: TCPA confirmé pour Prescott
Posté par Jerome Herman () le 26/02/2003 à 19:45. (lien). Évalué à 1.C'est un des comportements possibles de TCPA. Mais ce n'est pas celui qui est regle par defaut.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé pour Prescott
Posté par boubou (page perso, ) le 27/02/2003 à 10:04. (lien). Évalué à 1.Qu'est ce qui empêche donc windows de n'accepter de s'installer (puis ensuite de booter) que si le boot est certifié TCPA ? Microsoft pourrait très bien décider d'avoir quelque chose comme une liste de bios autorisés. C'est possible ou pas, au regard de la norme ? L'exemple des DVD montre qu'il parfaitement possible de distribuer des clés à des dizaines de fabriquant pour lever le CSS. On peut donc imaginer l'inverse : un fabriquant de bios doit montrer patte blanche à MS pour que windows puisse être installé. Après tout, c'est sûrement ce qu'ils veulent imposer pour Palladium.
-
[^]Re: TCPA confirmé pour Prescott
Posté par Jerome Herman () le 27/02/2003 à 16:11. (lien). Évalué à 1.Qu'est ce qui empêche donc windows de n'accepter de s'installer (puis ensuite de booter) que si le boot est certifié TCPA
Le fait que l'OS ne puisse pas savoir si le boot a ete certifie ou non.
TCPA regarde ce qui se passe au boot (si on le demande explicitement), et en fonction de ca ouvre ou ferme des boites a clefs.
La seule facon qu'il y a pour un OS de se proteger contre un boot est de creer un PCR. Mais le PCR ne regarde pas si la machine est certifie TCPA ou pas, il "enregistre" ce qui se passe lors d'un boot, et ensuite il compare les sequences de boot suivantes avec ce qu'il a enregistre.
Les PCR sont dependant du hardwawre et de la puce TCPA, de plus ce ne sot pas des clefs exportables.
On peut donc imaginer l'inverse : un fabriquant de bios doit montrer patte blanche à MS pour que windows puisse être installé
C'est effectivement parfaitement possible. Pour l'instant ca n'est pas dans les normes(voir meme carrement contre). Pour que ca se produise la seule solution que je vois est la suivante :
1)- On cree de base sur toutes les puces TCPA un PCR qui hashe le bios et le kernel a la recherche de deux sequences particulieres (ce qui est hors norme, le PCR doit etre vide et desactive par defaut, de plus il ne peut pas reagir a une sequence en l'etat)
2)- On installe dans un coffre fort lie a ce PCR une clef generique (ce qui est hors norme, la puce doit etre vide a la base excepte pour la clef fabriquant, les clefs stoques doivent avoir ete genere par la puce et sont donc par essence unique(dans la limite du raisonable) et non generiques)
3)- On place dans les bios et dans les kernels certifies la sequence qui va debloquer la clef.
4)- des parties importantes de l'install sont cryptes avec clef et ne peuvent donc pas fonctionner si la clef n'est pas debloquee.
Comme tu vois TCPA dans son etat actuel ne permet pas ce genre de manipulation, et de plus necessiterait pas mal de modifications pour les accepter. Il ne favorise donc absolument pas ce comportement.--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
-
-
[^]Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee (Jabber id, ) le 25/02/2003 à 22:42. (lien). Évalué à 3.C'est la phase 1 de mon plan de lutte contre SCP/Palladium.
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...--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: TCPA confirmé pour Prescott
Posté par TSelek () le 26/02/2003 à 10:21. (lien). Évalué à 2.TCPA est est une initiative américaine pour remplacer la carte à puce. La carte à puce étant avant tout une industrie européenne que les américains n'ont jamais adoptée pour cause de syndrome "not invented here", et étant moi même européen, je ne te remercie pas pour ton plan de lutte, pour des raisons qui te dépassent. Si toi même tu es européen, je te fais remarquer que tu es en train de te tirer dans le pied.
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 (Jabber id, ) le 26/02/2003 à 15:31. (lien). Évalué à 1.Oauih, et c'est moi qui fait licensier les employés de GEMPLUS ...
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.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: TCPA confirmé pour Prescott
-
-
-
-
[^]Re: TCPA confirmé pour Prescott
Posté par cornofulgur () le 27/02/2003 à 00:27. (lien). Évalué à 1.Sincerement Beretta_Vexee, reussir a redire sur 240 forums une verite premiere que personne ne veut entendre sans te lasser ca force le respect.
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 () le 27/02/2003 à 16:20. (lien). Évalué à 1.Tu ouvres la porte, ils s'installent. Ils te placent leurs cles. Ils s'approprient de l'espace disque, de la RAM, du temps machine. ils la marquent.
Euh, TCPA c'est juste un periph PCI comme les autres au regard du CPU. C'est une espece de port serie a qui on pose des question et qui sort des reponses dans une zone memoire (fixe). Si un mec arrive a prendre le controle de ma becanne rien qu'avec ca, c'est que de toute facon il serait rentre.
tcpa est un cookie monstrueux.
Il y a un numero d'ID dans TCPA, mais il ne peut pas sortir. Tu peux t'en servir pour creer des identites(autant que tu veux toutes differentes), tu peux le rendre illisible logiciellement etc... L'id il ne sort pas de la puce, il sert a la construction de clefs c'est tout, et il n'est pas du tout obligatoire.
Tu ne peux rien faire car si tu décides de désactiver leur puce, ta bécane ne tourne plus qu'en mode dégradé
Ouais elle est degradee ma becanne, par exemple TCPA ne marche plus.... TCPA est un port au regard de l'ordi, je degrade autant ma becanne a enlever TCPA qu'a descativer le port infrarouge de mon desktop.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
[^]Re: TCPA confirmé pour Prescott
Posté par patrick_g (page perso, ) le 26/02/2003 à 09:20. (lien). Évalué à 4.Cher Beretta_Vexee,
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 (Jabber id, ) le 26/02/2003 à 15:41. (lien). Évalué à 1.He He je peux étre plus fort que toi au jeu de la parano.
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.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: TCPA confirmé pour Prescott
Posté par patrick_g (page perso, ) le 26/02/2003 à 17:09. (lien). Évalué à 1.mouais.....c'est en partie vrai.
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 (Jabber id, ) le 26/02/2003 à 20:50. (lien). Évalué à 1.Ba a la base sa me rassure plus qu'autre chose, le premier usage de la crypto c'est quand méme de proteger des donnés pas de les rendres publiques.
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.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: TCPA confirmé pour Prescott
Posté par cornofulgur () le 27/02/2003 à 02:35. (lien). Évalué à 2.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.
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 (Jabber id, ) le 27/02/2003 à 11:23. (lien). Évalué à 1.Manifique, parce que mon FAI ne sait pas qui je suis, il n'a pas mes coordonnés banquaires et il m'offre ses services dans l'anonyma le plus complet ?
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 .--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: TCPA confirmé pour Prescott
Posté par boubou (page perso, ) le 27/02/2003 à 12:31. (lien). Évalué à 1.les avancées techniques
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 () le 28/02/2003 à 00:11. (lien). Évalué à 1.J'ai du mal m'exprimer.
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
J'aimerais comprendre... Si mon processeur supporte TCPA mais que je n'utilise que Linux, quel risque ai-je d'etre emmerdé ?
-
[^]Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee (Jabber id, ) le 25/02/2003 à 16:31. (lien). Évalué à 6.Ouaih, si tu n'installe pas le driver pour ta puce developper sous GPL par un petit mec d'IBM, tu ne pourra pas utiliser les fonction TCPA de ton processeur trop dur pour toi ... http://www.research.ibm.com/gsal/tcpa/
--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: TCPA confirmé pour Prescott
Posté par Julien Olivier () le 25/02/2003 à 16:47. (lien). Évalué à 3.Alors pourquoi tout ces cris et larmes ? Vous avez tous l'intention d'utiliser Windows à l'avenir ?
-
[+] [^]Re: TCPA confirmé pour Prescott
Posté par free2.org (page perso, ) le 25/02/2003 à 17:29. (lien). Évalué à -1.si Windows est le seul moyen d'accéder aux programmes et documents protégés par le DRM de MS, alors oui (une beta de MS Office avec des .doc protégés par DRM est sortie récemment) rappelons aussi que la Xbox est un PC qui refuse d'exécuter des programmes non sgnés par MS TCPA pourrait bien être la fin des logiciels libres (cf interview de Eben moglen sur slashdot)
-
[^]Re: TCPA confirmé pour Prescott
Posté par XHTML/CSS inside (page perso, ) le 25/02/2003 à 17:31. (lien). Évalué à 5.Ce qui m'inquiète, c'est plutôt pour le grand public (le brave papounet qui va acheter un ordi en grande surface pour ses deux fifilles et qui n'y connait rien en info). (je précise => il n'y a aucune arrière pensée péjorative ou moqueuse dans mon propos) Y en a qui sont persuadés qu'ils sont complètement anonymes sur internet (et sous windoze !). Je pense que c'est pour des gens comme ça que ça vaut le coup de gueuler pour que cette saleté de palladium ne passe pas... Qu'en pensez-vous ?
--
In tartiflette we trust !-
[^]Re: TCPA confirmé pour Prescott
Posté par Beretta_Vexee (Jabber id, ) le 25/02/2003 à 23:00. (lien). Évalué à 2.Il n'y a jamais eux d'anonyma effectif sur Internet a part quelque essais foireux genre le systeme paralléle de mail nyme et punker, qui on été des bide monumentaux.
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.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: TCPA confirmé pour Prescott
Posté par free2.org (page perso, ) le 25/02/2003 à 23:26. (lien). Évalué à 0.Il n'y a jamais eux d'anonyma effectif sur Internet a part quelque essais foireux genre le systeme paralléle de mail nyme et punker, qui on été des bide monumentaux.
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 (page perso, ) le 03/03/2003 à 22:10. (lien). Évalué à 1.Pourquoi tenter de rester a nonyme ?
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
Bon je vais peut-etre dire des conneries mais tant pis : moi ce qui me fait peur avec Palladium, c'est la perspective d'un internet gouverné par palladium. En clair on pourrait peut-etre arriver à une situation ou les machines palladium se repandent de plus en plus jusqu'a etre en majorité dans la population des serveurs. Et là, si t'as pas ton palladium, t'es hors circuit... plus personne veut causer avec toi.... maman, j'ai peur....
-
[^]Re: TCPA confirmé pour Prescott
-
[^]Re: TCPA confirmé pour Prescott
Posté par free2.org (page perso, ) le 25/02/2003 à 21:31. (lien). Évalué à 1.il est clair que TCPA risque de banaliser les puces de "sécurité" et de créer un boulevard pour les puces style palladium
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
je voudrais lancer un debat sur ce forum qui pourra prendre son importance dans le futur si TCPA passe.
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 (page perso, ) le 26/02/2003 à 10:14. (lien). Évalué à 1.Je suis d'accord avec toi pour dire que si MS interdit l'accès à certains fichiers copiés illégalment, alors MS se tire une balle de le pied.
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 () le 26/02/2003 à 17:20. (lien). Évalué à 1.Oui c'est tout a fait vrai, sauf que TCPA ne peut pas aider un site internet a savoir si ton ordi il est DRM compliant ou pas.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org (page perso, ) le 26/02/2003 à 22:23. (lien). Évalué à 0.DRM ne peut en rien etre aidee ou favorisee par TCPA
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 () le 26/02/2003 à 23:17. (lien). Évalué à 2.1. la clé endorsing unique dans chaque proc est bien pire que l'identifiant que Intel voulait mettre dans ses pentiums: cela pourra servir à crypter des fichiers DRM qui ne pourront être lus que par un seul ordinateur
Oui bien sur sauf que :
1) Je peux creer un fichier qui ne sera lu que par cette machine. Je ne sais pas si elle respecte le DRM ou si elle va utiliser la le droit de lecture pour faire douze mille copies, mais je peux faire cette limitation. Content.
2) L'id intel passait en clair partout, la clef endorsing sert a generer des CA. Je peux generer une infinite de CA si je veux, personne ne sera jamais qui est l'emetteru principal.
3) Si ca ne me plait pas je peux desactiver cette fonction, c'est d'ailleurs le cas par defaut.
2. la possibilité pour un OS comme windows de crypter des fichiers qui ne peuvent être lus par un autre OS sur la meme machine, c'est pas mal aussi
Oui c'est tres mal, on a vu trois fois deja que c'etait possible mais que ca ficherait MS dedans dans des proportions astronomiques. Pour la derniere fois si je bloque une clef dans le PCR (ie elle ne se debloque que si la sequence de boot est la bonne). Et que je change de sequence de boot, de base je ne peux plus decrypter mes applis. De plus si ca me plait pas d'avoir des clefs liees au PCR Windows je les deplace et basta.
3. le mode "extend" dont parle le créateur critique, qui empeche un OS non signé d'accéder à TCPA, c'est pas mal non plus
Ca n'empeche pas un OS non signe d'acceder aux fonctions TCPA, ca n'empeche pas un OS non signe de booter, ca empeche un OS non signe TCPA de se pretendre signe TCPA. De plus bien que ce soit prevu par la norme il n'y pa pas pour l'instant d'organisme existant capable de "signer" un OS pour TCPA, et il n'est pas dit qu'il y en aura. IBM n'a jamais active cette fonctionalite sur aucune de ses puces parceque ses clients n'en voyait pas l'interet.
4. MS est le seul spécialiste des logiciels à faire partie des fondateurs de TCPA, cela devrait mettre la puce à l'oreille quand aux futures normes TCPA (celles publiées ne sont en rien définitive)
Ah bon ben va falloir le dire a IBM. Je pense qu'ils vont faire vachement la gueule quand on va leur apprendre que les systemes qu'ils ont deja vendu ne sont pas forcement compatible avec TCPA. MS fait partie de tout (meme des normes XML, on raconte qu'on les a vu venir deux fois il y a 3 ans.) c'est leur truc leur politique. Ce que la prochaine norme TCPA sera je n'en sait rien, mais ca m'etonnerais pas mal que IBM et HP laisse MS transformer leur puce en systeme DRM. Et ca ne change rien au fait que pour l'instant il n'y a pas de dangers.
5. les normes TCPA autorisent aussi l'ajout de fonctionalités qui ne sont pas dans les specs: TCPA est alors un cheval de troie pour des fonctionalités plus néfastes comme empecher de booter un OS non signé
Oui, il suffit de recompiler le CPU et hop on a pleins de nouveaux appels. Et puis c'est assez a la mode les normes qui autorisent les trucs qui sont pas dans les normes. A l'heure actuelle TCPA est une puce qui est assise sur un bus et qui regarde les infos passer. en fonction de ca elle ouvre le offre a clef ou pas. Elle ne peut pas empecher l'execution d'un programme, ell ene peut pas formater un disuqe ou supprimer un fichier, elle peut s'ouvrir ou se fermer. Point final.
les documents officiels TCPA et IBM confirment les 5 affirmations ci-dessus, je peux te donner les numéros de page si tu veux
Oh oui je veux, la vraiment je veux bien.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org (page perso, ) le 27/02/2003 à 08:58. (lien). Évalué à 1.j'ajoute un 6e fait: impossibilité de controler le code qui est dans les puces TCPA
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 () le 27/02/2003 à 10:14. (lien). É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.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org (page perso, ) le 27/02/2003 à 10:22. (lien). Évalué à 1.de + les clés ne sortent pas de la puce TCPA, c'est pour cela que la puce TCPA a des focntions de cryptage intégrées. Tu ne peux donc pas utiliser le bus pour accéder aux clés, juste aux fonctions de cryptage qui utilisent ces clés.
-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman () le 27/02/2003 à 16:59. (lien). Évalué à 1.de + les clés ne sortent pas de la puce TCPA, c'est pour cela que la puce TCPA a des focntions de cryptage intégrées. Tu ne peux donc pas utiliser le bus pour accéder aux clés, juste aux fonctions de cryptage qui utilisent ces clés.
Si si elle sorte les clefs. En crypte, mais elles sortent. tu peux les copier, les editer les detruire etc... Tu peux les transferer a une autre puce TCPA (meme si dans le cas des clefs PCR ca ne sert a rien). Bref tu peux faire ce que tu veux a part les lire en clair(En fait c'est meme exactement le but de TCPA etre sur que l'on ne puisse pas te piquer tes clefs.).
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org (page perso, ) le 27/02/2003 à 17:36. (lien). Évalué à 1.curieux, il me semblait que tout l'intéret de TCPA était dans le fait que la puce TCPA faisait elle-meme les opérations de crypto, et que par conséquent elle ne donnait l'accès à personne aux clés qu'elle protège.
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 () le 27/02/2003 à 18:14. (lien). Évalué à 1.curieux, il me semblait que tout l'intéret de TCPA était dans le fait que la puce TCPA faisait elle-meme les opérations de crypto, et que par conséquent elle ne donnait l'accès à personne aux clés qu'elle protège.
Elle ne donne a personne l'acces de clefs en clair. Elle crypte les clefs avant de te les motrer. Ce qui ne t'empeche en rien de les copier, editer, detruire. Elle ne sont toujours pas accessible, elles sont toujours protegees. Je ne vois pas ou est la contradiction ici.
Pour moi la phrase d'IBM sur le fait qu'on peut écouter le bus d'une puce TCPA qui n'est pas dans le CPU se comrpend comme ceci: la puce TCPA doit décrypter les données protégées par DRM et donc envoyer ensuite ces données en clair au CPU: si j'écoute les donénes en clair qu'elle envoie au CPU alors je peux faire une copie décrypté du fichier DRM.
Les phrases d'IBM se comprenne sans DRM. TCPA ne sait pas ce qu'est DRM il n'en a pas la moidre idee. Il sait crypter, decrypter, analyser une sequence de boot et proteger des clefs.
Au cas ou ca t'interresse la phrase d'IBM veut seulement dire que si tu veux recuperer ta clef publique en clair, tu peux le faire sur leur puce. Tu vois tu es a 100 000 lieux de la verite, je ne vois meme pas par quel raisonement tu as pu passer de l'un a l'autre.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org (page perso, ) le 27/02/2003 à 20:18. (lien). Évalué à 1.question habituelle: numéros de page des docs offcielles TCPA où tu as lu tout ça ?
-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman () le 27/02/2003 à 22:33. (lien). Évalué à 1.question habituelle: numéros de page des docs offcielles TCPA où tu as lu tout ça ?
CF section 4.27 sur le storage et la migration des clefs assymetriques
section 4.30 sur les systemes d'identites
section 6.3 sur l'acces en lecture aux differents repertoires et PCR
section 7.2 sur l'ensemble des fonctions obligatoires pour lire une clef publique, binder une clef, debinder une clef, sealer une clef, liberer une clef, preparer un cryptage de migration d'une clef, crypter une clef avec son blob de migration, autoriser la migration d'une clef etc...
Je ne peux pointer dans la doc TCPA ce qui parle du DRM, vu qu'il n'y a rien.
# less spectcpa | grep -e DRM
#
Rien, que dalle. Si tu penses pouvoir utiliser TCPA pour faciliter la protection DRM, explique moi comment, moi je ne vois pas.
On finit avec le paragraphe IBM
The TCPA chip is not particularly suited to DRM. While it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use, this type of scheme would
be a nightmare for content providers to manage. Any change to the BIOS, the operating
system, or the application would change the reported values. How could content
providers recognize which reported PCR values were good, given the myriad platforms,
operating system versions, and frequent software patches?
Second, the IBM version of the TCPA chip, while evaluated to FIPS and Common
Criteria security standards, has specifically omitted tamper resistance from the evaluation
target. The IBM chip sits on the LPC bus, which is easily monitored. The chip is not
defended against power analysis, RF analysis or timing analysis. The bottom line is that
the physical owner of the machine could easily recover any DRM secrets from the chip.
This apparent lack of security in the chip makes perfect sense when you realize that the
purpose of the chip is to defend the user's data against remote (software) attack. When the
goal is to protect the user's keys and data against external attack, we simply are not
concerned with threats based on the user attacking the chip, as the user already has secure
access to his own data.
Traduction : la puce TCPA n'est pas vraiment adaptee a DRM. Bien qu' elle permette de controller des PCR signes, et que ce type d'information peut etre utilise pour empecher une lecture si l'OS et le lecteur ne sont pas des applications de confiance, ce type de modele serait un cauchemar a gerer pour les fournisseurs de contenu, n'importe quel changement au niveau du BIOS, de l'OS ou de l'applicatif changerait les valeurs. Comment ferait les fournisseurs pour connaitre les bonnes valeurs de PCR parmis la myriade de plateforme, de systemes et les frequentes mise a jour ?
Deuxiemement la puce TCPA d'IBM, pendant l'evaluation vis a vis de FIPS et des Common Criteria security standards, a specifiquement omis la resistance a l'audit de cet evaluation. La puce IBM est place sur le bus LPC qui est facile a surveiller. La puce n'a pas de defenses contre des analyse de puissance, de frequence ou de temporisattion. Au final, un utlisiateur pourrait tres facilement recuperer n'importe quel secret DRM de la puce.
Cette absence aparente de securite dans la puce, devient parfaitement logique quand vous realisez que le but de cette puce est de defendre l'utilisateur contre les attaques (logicielles) a distance. Quand on se concentre sur la protection des clefs et des donnees de l'utilisateur contre des attaques exterieures, on se moque du danger represente par un utilisateur qui attaque sa propre puce, vu que l'utilisateur a deja un acces securise a ses donnees.
Simplement : Si DRM met des clefs privees dans une TCPA IBM, il faudra pas qu'il se plaignent si elle se retrouve expose au grand jour.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org (page perso, ) le 28/02/2003 à 02:31. (lien). Évalué à 1.d'abord je constate la confirmation de mon affirmation que tu avais contredite:
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 () le 28/02/2003 à 16:05. (lien). Évalué à 1.d'abord je constate la confirmation de mon affirmation que tu avais contredite:
ensuite je ne suis pas d'accord sur les conclusions de:
CF plus haut dans mes autres posts.
Kha.
P.S : Bien que je comprend ton soucis d'information vis a vis de tes congeneres, je pense que toute les personnes qui lisent encore ce thread au bout de quatre jours, le lise en entier. Inutile donc de reassener 3 fois le meme argument dans tous les sous thread. Ca ne fait que compliquer la discusion.--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
-
-
-
-
-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman () le 27/02/2003 à 16:55. (lien). Évalué à 1.donc par une technique de challenge/response (envoi d'un nombre aléatoire crypté qui vient juste d'etre généré, et demande de décryptage de ce nombre par la clé privé)
Oui je peux m'assurer qu'un PC connait la clef privee. Exactement comme en software. Si tu as peur qu'une clef soit utilise contre toi a des fins d'identification tu peux la detruire, exactement comme en software. Je ne vois pas ou est le probleme. Le principe d'une identification challenge/reponse est d'identifier. Ca marche. On le sait depuis longtemps. TCPA n'apprte ni n'enleve rien a ca.
je peux m'assurer de l'identité exacte d'un PC TCPA.
Non je peux savoir que le PC connait la clef privee. Je ne peux pas savoir si c'est un original ou une copie, si je suis toujours sur le meme PC etc...
C'est bien plus dangereux que l'ID des pentiums (qui a été boycotté avec succès)
CF plus haut, pas du tout. ID intel etait incopiable et directement consultable. L'ID TCPA n'est pas directement consultable, il est desactivable et ne sort d'une puce que sous forme de CA a partir desquels il est techniquement impossible de retrouver l'ID. On peut generer autant de CA que l'on veut.
Le but de DRM est bel et bien de s'assurer que certains document ne te sont plus accessibles si tu ne respecte pas certaines règles. Il sera toujours possible de te réenvoyer ces documents si tu prouves que tu as bien payé ta licence (pour rappel les techniques d'activation de XP et le DRM de mediaplayer fonctionne deja sur un principe similaire)
Ben oui mais le controle du respect ou non de ces regles n'est pas faisable en TCPA et devra donc etre completement implemente a cote. De plus vu que l'on peut copier une clef d'un endroit a un autre en TCPA il faudra aussi inventer une solution qui m'empeche lorsque je suis sous windows de copier ma clef hors du PCR, pour l'instant en TCPA rien ne l'interdit.
ce n'est pas ce que dit l'un des createurs de TCPA dans son document qualifié de "très raisonable" par IBM (voir mon article ci-dessus)
Il dit dans son doccument que si le mode extend etait force et impossible a revoquer (ce qui n'est pas du tout le cas) alors il serait possible de creer sur TPM un systeme qui bloquerait les OS non certifies. Cela impliquerait la mise en place de clefs generiques (CF TCPA rebutal) ce qui va contre les normes TCPA.
Au fait c'est un des createurs de TPM, pas de TCPA. Il est "tres raisonable" au sens ou les dangers potentielsqu'il souleve existent, et que ce n'est pas un tissus d'annerie comme la plupart des autres doccuments sur TCPA qu'on voit trainer sur le net.
MS est le seul non fabricant de CPU à faire partie de TCPA
Ils vont peut etre tenter quelquechose, ils ont peut etre tente quelque chose, en tout cas jusque la ca n'a pas marche.
faux: la norme autorise à intégrer TCPA dans n'importe quoi (cf liens dans mon article) y compris le CPU
Et alors ?? Je peux mettre une puce ou je veux tant que je ne change pas ces fonctions. Si j'ai envie de la mettre dans le CPU (pour avoir une fonction RNG native dans mon CPU) ou dans l'horloge (pour avoir un generateur chaotique a porte de main) ca ne change en rien ce qu'elle fait. Si je fiche une carte sonore dans mon contorleur IDE ca me regarde.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org (page perso, ) le 27/02/2003 à 17:04. (lien). Évalué à 1.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.
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 () le 27/02/2003 à 19:57. (lien). É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.
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--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org (page perso, ) le 27/02/2003 à 22:03. (lien). Évalué à 1.mouais enfin toutes ces valeurs par défaut ça va dépendre aussi du BIOS que tu utilises. Qu'est-ce qui me garanti que tous les BIOS permettront aux utilisateurs de manipuler ces valeurs ?
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 () le 27/02/2003 à 23:03. (lien). Évalué à 1.Bne vu que la puce est censee pouvoir controle le bios, si le bios peut controler la puce ca fait un gros trou de securite non ? La puce est supposee etre appelable depuis le POST (recommandation, ce n'est pas une obligation) Mais il faut une methode qui autorise une detection d'acces physique a la machine (ie avant le boot os), et qui permette la manipulation d'un certain nombre de paramettre (c'est dans les normes CF un de mes autres posts plus haut).
Si les softs DRM exigent windows pour tourner c'est un autre probleme, ils ne pourront pas s'appuyer sur TCPA pour verifier l'OS. Un certains nombre de test devront etre fait a cote (sur une autre puce ou en logiciel).
Toute clef privee qu'une appli DRM stockerait sur ta puce TCPA (meme si elle est base sur un de tes private CA, meme si elle est scellee sur un PCR) serait en danger. Avec le ddroits owner tu pourrais en effet la migrer du sceau PCR vers une zone non scellee, ou meme cree un blob de migration bidon, et ressortir la clef en clair apres quelques manipulations. A la place de DRM je mettrais mes clefs ailleurs.
Kha--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.-
[^]Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org (page perso, ) le 28/02/2003 à 02:36. (lien). Évalué à 1.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.
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 () le 28/02/2003 à 16:07. (lien). Évalué à 1.J'ai dit rois lors de mon post precedent. je voulais dire 4 fois le meme argument.
Kha
(dans une chambre d'echos depuis trois jours)--
Kha
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: TCPA confirmé pour Prescott - les utilisateurs trancherons
Posté par doublehp (page perso, ) le 03/03/2003 à 22:28. (lien). Évalué à 1.> Je crois avoir bien resumé les besoins des particuliers
> 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 :)
Ce qui me fait le plus tripper dans les commenatires ci dessus, c est que certains debattent techniquement au sujet d'une puce dont meme certains de ses concepteurs sont contre sa gravure, et en prenant comme support des docs unbuvables de plusieurs centaines de pages qu'aucun de nous ici n'a lu en entier, ou si il les a deja lues, en arrivant a la fin il avait deja oublie le debut .... bref ca se debats plus ou moins d'un truc dont personne ne peut se venter qu'il sait comment ca marche, avec des arguments , citations, contre arguments et contre citations issues d'adresses diverses dont personne ne peut verifier l'autenticite, et sur un sujet tellement complique qu'aucun humain ne peut le maitriser totalement, meme pas ses concepteurs ...
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 ?
Cette page a été générée par Templeet en 0.6981s (dont 0.1653 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.