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 (632 hits)
- Un autre article de The Inquirer (377 hits)
- TCPA (345 hits)
- FAQ TCPA/Palladium en Français (896 hits)
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.
L'article dans The Inquirer (632 hits)
Un autre article de The Inquirer (377 hits)
TCPA (345 hits)
FAQ TCPA/Palladium en Français (896 hits)
> 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-
[^]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-
[^]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
-
-
-
-
-
-
-
-
[^]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)
-
[^]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
-
[^]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
-
[^]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-
[^]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-
[^]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 () 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-
[^]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
-
-
[^]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.
-
-
-
-
-
-
[^]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-
[^]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-
[^]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-
[^]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 ?-
[^]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-
[^]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.-
[^]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
-
-
-
[^]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
-
-
-
-
-
[^]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
-
-
-
-
-
-
-
-
-
-
-
-


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.