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.
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.
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...
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.
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.
Pourquoi mettre un -1 a une chose qui est completement vraie. Il y a deja eu une vague de protectionisme en informatique, vague qui s'est tres mal finie. Il y avait des disquettes micro perforees (trou percer au laser dans la disquette) des dongles (element qui se branche sur une sortie de l'ordi pour certifier la license) et autres systemes anticopie (disquettes lisibles mais non inscriptibles, pour empeche rune copie physique par exemple ).
Et puis tout a disparu. Les utilisateurs legaux se plaignaient en permanence, les services techniques etaient satures et il a ete calcule que ca coutait plus cher de proteger que de laisser pirater. Fin de la premiere vague. On est en pleine deuxieme vague, mais les utilisateurs ont deja gagne une fois, donc l'espoir est clairement permis.
Perso je suis completement contre le piratage, mais j'ai deja fait deux copies de CD audio "proteges" parceque l'original ne passait pas sur la chaine d'une copine. Et je ne compte plus le nombre de "No-CD Patch" qui ont ete appliques a gauche et a droite (Unreal 2 de 5fps a 40fps avec un patch par exemple).
Pour ne pas être d'une totale mauvaise fois, je dois avouer que ces système on limité la plupart du temps le piratage par simple copie d'un original quelconque par n'importe qui.... mais bon...
Oui maintenant il faut au moins 20 secondes de recherche sous google pour faire la meme chose. Des milliers d'utilisateurs perdent l'usufruit d'un produit qu'ils ont legalement achete, les majors gagnent 20 secondes contre les petits pirates, encore une bien belle vitoire.
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.
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.
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)
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.
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.
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.
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.
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...
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
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.
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.
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.
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
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
C'est du reste de ce que fait Gecko non ?
Euh pas du tout, pour completer ce que dit Erwan voici quelques exemples :
prend un editeur de texte et tape (en remplacant les [] ):
hello world
[table border="2"]
[tr]
[td]ceci n'est pas[/td][td]un tableau[/td]
[/tr]
[/table]
sauvegarde sous le nom test1.html et ouvre le avec moz. Surprise le code est interprete. En tehorie il ne devrait pas, je n'ai jamais dit que c'etait du HTML, je n'ai pas ouvert le body, ce truc devrait au mieux s'afficher en tant que texte brut.
un autre ? :
[!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 2.0 strict//EN"]
[html]
[body]
[div align="center"]hello world[/div]
[/body]
[/html]
La je suis en strict 2.0, le tag div devrait passer a la trappe, ben non il est interprete sans probleme et mon hello world se place au centre.
Moz est moins porcin qu'IE (notemment sur le DHTML) mais de la a dire qu'il respecte strictement la norme....
Tes "zigouigoui rigolos derriere", sont dans la norme ou pas ? Su oui, tous les moteurs doivent les supporter, car un moteur doit supporte la norme, toute la norme
pas la norme, LES normes. Il y a une dizaine de normes differentes rien que pour le HTML, sans compter les XHTML, XSL et autres ECMA.Et vu ce qui nous arrive avec le XML ca va aps aller en s'arrangeant. Supporter toute les normes au sens strict ? C'est quasiment impossible. 1) - Il n'y a pas un site sur 1000 qui est W3C compliant. 2)- On peut imaginer un navigateur qui supporte les normes jusqu'a la 4.0 par exemple, mais il risque d'avoir une telle masse de code que derriere pour rattraper ca risque d'etre beau.
A mon sens ce sera deja beau quand les navigateurs seront en mode respect partiel (ie tout ce qui marche est dans la norme) on en est meme pas la pour l'instant. Dans ce cas les zigouigouis deviennent des fonctions dans la norme, mais qui ne sont pas forcement supporter par tous les navigateurs.
J'ai, cela dit, du mal à imaginer une fonction qui ne serait pas implémentable dans un moteur de rendu HTML pour des raisons d'architecture graves,
Un exemple : la gestion des characteres. En theorie pour faire propre il faudrait que chaque signe(caractere) soit un objet a part entiere. En pratique ce n'est pas le cas. Les developpeurs utilise des techniques de groupage(ie les chaines de charactere sont traites comme des objets) et de poid mouche(ie on a un objet caractere et un seul par chaine que l'on decline suivant les besoins). Ca fait gagner du temps et de la place memoireen pagaille car il y a generallement plus d'un caractere dans une chaine.
Mais si demain le DHTML inclu dans la norme la possibilite de bouger les elements d'une meme chaine independament les un des autres, ou de creer des effets de distortion/rotation/zoom par caractere, tout tombe a l'eau. Il faut recommencer une bonne partie du code.
Il me semblait avoir lu (faut vraiment que je note mes sources moi) que les devs de mozz avaient d'abord optimisé le support de lanorme et la compatibilité et que maintenant ils cherchaient À optimiser.
C'est exactement ce que je dis, Gecko se focalise d'abord sur le respect de la norme, la vitesse d'execution et l'occupation meoire passe en deuxieme.
Kha
Bien sur un tel moteur unique ou quasi-unique se doit d'être respectueux de la norme et intransigeant sur celle-ci. Rigoureux pour ne pas introduire d'incompatibilités (c'est le minimum) et intansigeant pour ne pas laisser se prendre de mauvaises habitudes et contraindre à respecter la norme.
Ce n'est pas aussi simple que cela. Si il n'y a qu'un seul moteur, on est loin de l'esprit du libre, on a a faire a une situation de monopole et la norme devient indissociable du produit. De plus qui irait tester son site contre les standards de la W3C si il passe correctement sous le seul et unique moteur qui existe. Le comportement le plus vraissemblable serait plutot : "je teste mon site avec xbrowse et les standards je m'en balance". A partir de se moment la lorsque le boite bidule va passer de xbrowse a ybrowse meme si ils suivent les standards a fond ils risquent de se retrouver avec un certains nombre de sites qui ne respectent pas les standards, qui passaient tres bien sous xbrowse et qui crashent sous ybrowse.
De plus il y a trois facon de respecter une norme :
- Respect strict : tout ce qui n'est pas la norme ne marche pas, tout ce qui est la norme marche
- Respect permissif : tout ce qui est la norme marche, tout ce qui n'est pas la norme on sait pas. (les bons vieux warnings du C...)
- Respect Partiel : Tout ce qui marche est dans la norme, mais on a encore un paquet de fonction non implementees.
Le HTML est une norme qui supporte tres bien le fallback (ie si une fonction n'est pas supportee, on fait autre chose), et il est assez facile a mon sens d'ecrire un site simple et fonctionnel qui passe avec n'importe quel navigateur et de rajouter les zigouigoui rigolos derriere. Seulement tres peu de gens procedent de cette facon. Par contre si il y avait 200 moteurs, tout le monde ferait comme cela. Et je pense perso que ce serait un vrai plus.
Gecko pour moi c'est plus la libjpeg, je vois pas l'intérêt de faire 15 versions différente d'un truc utilitaire.
A mon sens Gecko est plus un outil oriente utilisateur final, qu'une bibliotheque. Mais tant bien meme ce ne serait qu'une bibliotheque ce que tu dis n'es vrai que dans le cas ou le HTML est une norme
- 1) totalement implementee (ie toutes les fonctions HTML sont supportees)
- 2) figee (ie pas d'ajout de fonctions a venir).
Je ne sais pas, mais je pense que ca representerait pas mal de boulot d'ajouter la prise en charge d'une dimension supplementaire dans libjpeg (ie si demain on demande a libjpeg de faire de la compression d'hologrammes). Ben le HTML c'est un peu ca tous les jours. Ca oblige a pas mal de souplesse et d'ouverture d'esprit au moment du dev. Et il peut oujours arriver le moment ou un des deux groupes se dit "mince on avait pas prevu ca du tout", et la l'autre groupe est une veritable bouee de sauvetage. Il y a de part le monde des dizaines de librairies sur les matrices, la gestion des images, les acces disques etc. D'un point de vue exterieur on pourrait penser que toutes ces bibliotheques font la meme chose. Mais elles ne le font pas de la meme facon. Et quand ca coice avec une, il est hautement appreciable de pouvoir se rabattre sur une autre.
Mais pour moi Gecko n'est pas juste une bibliotheque. Il n'existe pas une seule facon d'interpreter du HTML et de l'afficher, et les choix fait par Mozilla peuvent ne pas plaire a tout le monde, le mode de gestion de la page (meme si au final le rendu est le meme) peut varier du tout au tout . Tout depend du but vise. Les objectifs a court terme de KHTML et Mozilla sont assez differents je pense. KHTML a l'air de vouloir faire un support optimise quite a ce qu'il soit restreind, alors que Mozilla cherche plutot un support complet au detriement de l'optimisation. Il s'agit bien de deux philosophies differentes a la base et de deux ergonomies differentes pour l'utilisateur au final. Donc c'est exactement la meme chose que Gnome et KDE.
Sans vouloir m'avancer je pense que ce a quoi faisait reference l'ami d'Oliv c'est a la gestion de l'explorer, qui a en effet enfin evolue sou XP.
Jusqu'a XP l'Explorer etait un des plus grand bouffeur de ressources qui soient. Faire une copie de plusieurs doccuments de taille importantes de disque a disque (meme d'un disque sur lui meme d'ailleurs.) surtout si le reseau rentrait en ligne de compte, avait tendance a fiche par terre une machine. Si quoi que ce soit ne se passait pas idealement (disque fragmente, lag reseau, prob de lecture CD-ROM etc.) on se retrouvait a 100% de ressources prises et ce independamment du nombre de processeurs, de la ram, de la vitesse du systeme...
Ca en etait a un tel point que j'avais pris le reflexe de lancer une commande dos a chaque fois que je voulais faire une copie, et j'avais des gains de perfs de l'ordre de 50%. Le plus beau cas que j'ai vu etait sur une copie de donnees depuis un DVD (distrib linux, pas de rip)
Copie sur le disque via Explorer : 8Mo/s
Copie sur le disque via DOS : 16Mo/s
J'ai refait le test je ne sais pas combien de fois pour etre sur, mais simplement en invoquant une ligne de commande je gagnais 100% de vitesse. En plus la ou mon PC etait quasiment unitilisable avec Explorer, je pouvas sans aucun probleme m'en servir quand la copie se faisait en DOS.
Sous XP manifestement ce comportement a ete en grande partie corrige, et il semble qu'explorer soit desormais traite comme un process comme les autres et non plus comme un dieu tout puissant dont on apaise la colere en lui sacrifiant des ressources. Mais je n'ai pas eu le temps de faire de tests intensifs, je n'ai pas XP et je n'aime pas XP (pour des raisons purement politiques ceci dit: la license m'arrete net).
Flash est présent sur un nombre bien faible d'architectures différentes (Win32 x86, MacOS PPC, Linux x86, Solaris Sparc, si je me souviens bien, mais ensuite ?)
BeOS et FreeBSD/NetBSD(avec support des binaires linux) manquent a ta liste , mais bon le principal chiffre a retenir est 95 a 97% des surfers supportent la techno Flash. Ce qui signifie un seul dev pour toucher 95% du marche (sans tests dans tous les sens, sans cadrages x ou y, sans ce demander ce qui se passe si le mec navigue en bi/tri ecran etc...)
Mais ce qu je voulais dire c'etait surtout que meme a une epoque il y avait tres peu de moteurs de rendu HTML, pas mal de gens pensaient que Flash etait une alternative facile et peu couteuse a mettre en place. Ce qui va contre l'idee que moins il y a de moteurs plus le travail d'un webmaster est simple. Ce qu'il faut retenir c'est que si il y a plus d'un moteur HTML alors il est plus simple pour un webmaster d'en avoir 200 qui vont chercher a suivre les normes le mieux possible et se consulter frequement pour savoir comment interpreter telle ou telle balise, que d'en avoir deux ou trois qui vont passer leur temps a se tirer dans les pattes pour devenir le seul et unique(Cf guerre [layer] vs [Div]).
Pas mal de gens semblent paniques par le top de penetration d'IE 6.0. A mon sesn une explication valable a prendre en compte est l'arret du support de NT4 par Microsoft en juillet. Bien que ce ne soit pas vraiment le bon moment pour cela au niveau budget, il y a un certains nombre de boites qui se disent qu'il vaut mieux pas etre en NT4 si MS ne le supporte plus. Donc il y a eu de grandes vagues de migration vers des systemes Win2K serveur/XP workstation un peu partout. Je pense qu'une partie non negligeable des IE6 qui semblent fleurir en ce moment viennent de la.
C'est pas vraiment rassurant non plus, ca aurait tedance a montrer qu'apres 10 ans de NT les gens ont encore tendance a se tourner vers Microsoft pour leur solutions professionelles.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
En fait 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 Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Il n'y a pas de notion de "Sanctuaire" ou de zone inaccessible dans TCPA. La seule zone pour laquelle on est pas libre est le trusted root qui doit etre delivre par un organisme certificateur assermente.
Si tu fiche la clef dans le TPM elle devient lisible par le owner du trusted root, c'est pourquoi Paladium aura sa propre puce tres vraissemblablement. Une puce qui sera peut etre base sur TCPA, qui utilisera peut etre le systeme TPM, mais ce ne sera pas TCPA en l'etat.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Ben c'est un peu le but de tout certificat non ? Avoir un process qui ne depend pas de toi et qui permet d'assurer que tu es bien qui tu pretend etre non ? Tous les certificats "logiciels" sont bases sur ce principe. Tu va voir un organisme de certification, tu lui demande de te creer un certificat comme quoi tu es ce qui tu dit etre, et tu le deplois sur ton site. Je sais bien que DLFP c'est auto certifie (quand on clique sur autehntification SSL) mais c'est un principe assez rare et peu securise.
Ce n'est que la transcription en hardware d'un principe de certification par tierce partie. Rien de choquant en soit. La seule chose qui pose probleme est que l'on ne peut pas choisir l'organisme certifieur (bien qu'il soit possible de faire changer le trusted root) Il serait bon en effet que certains des organismes de certification soit des tenors du libre (ma certif de base est faite par Intel, je l'enleve et je la fais refaire par GNU). Mais ca demande pas mal de boulot pour pouvoir etre mis en place.
De plus un certificat ne t'identifie que si tu le partage. Ce que rien ne t'oblige a faire, meme pas TCPA. Tu n'a pas envie d'ouvrir de connections vers l'exterieur sous certificat TCPA ? Ben tu ne le fais pas, ca va pas t'empecher de vivre.
La clef privé n'est jamais visible !
Ben si, tu peux la lire l'editer, la copier d'une zone a une autre etc...
Il y a pleins de fonctions qui te permettent de faire cela dans les normes. sinon si ta puce a un probleme et grille, toute tes donnees cryptees seraient perdues. Un peu genant quand meme non ? Et puis bon vu que TCPA fait aussi du cryptage symetrique c'est une veine qu'on puisse voir, lire et echanger les clefs tu ne crois pas ?
Le owner d'un trusted root fait ce qu'il veut avec les clefs...
Kha
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Si tu veux pouvoir envoyer des doccuments certifies authentiques par TCPA, alors oui il faut que tout ton systeme soit TCPA (mais c'est normal il me semble).
Si tu cherche juste un cryptage fort sans certifications supplementaires (apres tout 2048bits c'est quand meme deja une vache de securite) la tu t'en moque tu peux avoir juste le chipset TCPA et le cpu qui a les fonctions, le reste tu t'en balance.
Si tu veux envoyer un doccument crypte garanti d'emission (ie la la machine qui l'a envoye est bien celle qui pretend l'avoir envoye). Il faut que tu cree un PCR qui hashe l'integralite de ton processus de boot. Mais il ne controlera pas la compliance TCPA des elements qu'il va hasher.
Le seul but de ce lock de clef et des certifications TCPA de hardware est pour la recertification TCPA.
Par exemple si sur un serveur un de mes disques meurt (disque RAID, donc pas de perte de donnees). Theoriquement mon PCR change, et donc les clefs certifies TCPA ne seront plus accessibles au boot suivant. Mais comme tout mon serveur est TCPA mon nouveau PCR sera aussi full TCPA, quand je vais deplacer les clefs d'un PCR a l'autre je ne vais pas perdre les certifications TCPA.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
De deux choses l'une soit la clef que MS te donne est toujours la meme, et la effectivement tu peux t'en servir pour relancer des applications et/ou des docs DRM apres une upgrade. Mais bon comme c'est toujours la meme clef, rien ne t'empeche de la remettre en place sans l'accord de MS, voir meme de la copier dans un endroit parfaitement accessible sous Linux. Si la clef ne change pas elle est par definition tres faible, vu qu'elle ne depend pas de ton hardware, meme si elle est stoquee sur TCPA rien ne t'interdit de l'utiliser ailleurs.
En plus pour que cette technique soit possible il faut que la clef soit donnee en mode transmissible, elle ne peut pas se loger en contole PCR (meme avec exactement la meme clef la puce refusera de decrypter un element qui a ete encrypte sous un autre PCR). Donc le cas dont tu parles ne peut pas se produire.
Pour faire clair il y a deux cas :
- Soit la clef est depedante du hardware, logee avec un test de PCR et fait appel a la fonction TPMPROOF auquel cas elle devient inaccessible en cas de changement de hardware ou d'OS (la elle est illisible par linux) . Mais si je change mon Hardware, meme si MS me redonne exactement la meme clef, mon TPMPROOF a change et le decryptage reste impossible. La seule solution que j'ai si je veux decrypter ce qui a ete crypte par cette clef avant le changement de hardware est de deplacer cette clef dans une zone qui ne fait pas appel au TPMPROOF, et qui est donc lisible par Linux.(N.B ce deplacement de clef est tout a fait possible, il suffit d'avoir les droits owner sur le trusted root pour faire tout ce que l'on veut avec les clefs.)
-Soit la clef est independante du Hardware et ne fait pas appel au TPMPROOF du PCR, auquel cas elle est de base lisible par linux, basta.
Troll, je reponds pas.
Je suis desole que tu ais pris mon apparte comme cela, ce n'etait pas mon intention. J'imagine donc que pour toi tous les echanges de clefs se feront par moyen electronique obligatoirement. C'est possible mais ce serait quand meme une sacree limitation. Je pense qu'une mention "necessite une connection internet valide" sur un OS serait du plus mauvais effet. Meme si XP s'installe tres bien via le net, la possibilite de le reinstaller par telephone est quand meme rassurante.
Kha
[^] # Re: L'interret des protections
Posté par Jerome Herman . En réponse à la dépêche Devinez qui vient fouiller chez vous ce soir. Évalué à 10.
Et puis tout a disparu. Les utilisateurs legaux se plaignaient en permanence, les services techniques etaient satures et il a ete calcule que ca coutait plus cher de proteger que de laisser pirater. Fin de la premiere vague. On est en pleine deuxieme vague, mais les utilisateurs ont deja gagne une fois, donc l'espoir est clairement permis.
Perso je suis completement contre le piratage, mais j'ai deja fait deux copies de CD audio "proteges" parceque l'original ne passait pas sur la chaine d'une copine. Et je ne compte plus le nombre de "No-CD Patch" qui ont ete appliques a gauche et a droite (Unreal 2 de 5fps a 40fps avec un patch par exemple).
Pour ne pas être d'une totale mauvaise fois, je dois avouer que ces système on limité la plupart du temps le piratage par simple copie d'un original quelconque par n'importe qui.... mais bon...
Oui maintenant il faut au moins 20 secondes de recherche sous google pour faire la meme chose. Des milliers d'utilisateurs perdent l'usufruit d'un produit qu'ils ont legalement achete, les majors gagnent 20 secondes contre les petits pirates, encore une bien belle vitoire.
Kha
[^] # Re: TCPA confirmé pour Prescott - les utilisateurs trancherons
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
La menace DRM est une menace reelle, mais elle ne peut en rien etre aidee ou favorisee par TCPA. On ne peut pas a partir d'une clef publique TCPA en deduire que l'utilisateur fait tourner linux ou possede un programme de rip.
kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Bon je passe outre le fait de se faire dicter par telephone une clef de 2048bits, ce qui pourtant pourrait etre un pur moment de bonheur, et qui a mon avis decredibilise un peu ton scenario.
Je reprend au moment ou mon "windows media DRM et tout" il ne veut plus marcher parceque j'ai upgrade mon systeme. J'apelle windows qui me file une clef, je l'enregistre et la hop : mon "windows media DRM et tout que je m'en sert que pour lire des trucs legaux promis jure" il ne marche toujours pas. Ben non le bougre il a ete crypte avec une clef qui ne sera accessible que depuis mon ancien profil de boot, et la je l'ai change. Zut alors je suis oblige de reinstaller tout mon windows. Et donc de me farcir une troisieme installation de clef super.
Non vraiment j'y crois pas un seul instant...
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Et bien c'est exactement ca, c'est un certificat hardware, ni plus ni moins. Et il faut que le certificateur soit une tierce personne et que les certificats ne puissnet pas etre delivres par n'importe qui (ce qui interdit malheureusement une mise en place 100% libre). Sinon une machine pourrait s'autocertifer ce qui fait :
- 1) Une personne pourrait creer un trusted root sur lequel il est owner, l'implanter sur ta machine et recuperer toutes tes clefs (pas bon)
- 2) N'importe qui pourrait passer pour n'importe qui au niveau des echanges de clefs (pas top non plus)
Comme pour les certificats il faut des organismes certificateurs, c'est aussi simple que ca. Et comme en TCPA tout le monde est certifie, tout le monde passe par un organisme certificateur.
En quoi, tu passes les protections ? Le TCPA est avant tout là pour planquer une clef privé et la protéger en cas de crack de ta machine (le boulot d'une carte à puce). Le reste n'est que pour aider l'implentation de truc sur ta machine que tu ne controles pas. IMHO.
TCPA sert aussi a generer des clefs publiques vis a vis de ta machine et de l'exterieur. Une puce vierge ou avec un trusted root fausse entrainerais l'efondrement de tout ce mode sans ces protections. TCPA ne servirait plus a rien (autant stoquer les clefs en clair sur ton disque dur, ca reviendrait au meme)
Quel assurance aurras-tu sur la qualité du random de la clef de session par exemple
Vu qu'on peut generer des RN a la volee avec TCPA , il est extremement facile de quantifier la qualite de ces nombres aleatoires. tu en genere 100 000, tu trace une gaussienne, tu regarde et tu connais la qualite de ta generation. Pas besoin de faire confiance aveugle a ton commercial, tu peux aller verifier par toi meme si ca te chante (il n'y a pas besoin de connaitre l'algo pour tester la qualite d'une serie aleatoire)
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Le probleme viendrait si la puce etait integre a un controleur (ie une puce qui fait TCPA+autre chose) . La ca risquerait de compliquer la tache. Mais ca compliquerait aussi la tache des fabriquant de carte mere, vu que chaque upgrade dudit controlleur impliquerait une upgrade TCPA au passage. Ceci etant c'est tout a fait envisageable de mettre le TCPA sur la clock par exemple, voir meme ca simplifierait les fonctions de RNG. Mais pour l'instant on est en speculation pure, donc pas d'arguments concrets pour dire que c'est mal ou que c'est bien.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 2.
La section 4.13 te donne les etats preconfigures et les flages de TPM, dont on peut deduire son comportement.
La partie 4.13.2 est celle qui t'interressera le plus je pense, il y a tous les iens vers les autres sections si tu veux des approfondissement.
La partie 4.22-4.23 decrit les processus lors de la migration des clefs.
On peut a peu pres tout faire avec un OS non certifie TCPA. Seul probleme ce ne sera pas un certificat complet. La TPM Proof n'est pas obligatoire, mais son absence fait que les clefs ne sont plus certifiees TCPA.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Presenter un fait probable (ie l'integration eventuelle par Intel de la puce dans un CPU rendant son audit difficile), comme une obligation est un raccourci dangereux.
De pus le fait que le nouveau CPU d'intel supporte TCPA veut seulement dire une chose : il possedera un module d'authentification TCPA (ie il sera certifie TCPA). Vu la course a la vitesse en ce moemnt et les problemes qu'ont les fondeurs a faire tenir toutes les fonctions desires dans un cpu, on peut penser qu'Intel ne va pas "gacher" des transistors betement en mettant le systeme TCPA a proprement parler dans le CPU. La solution logique serait de le mettre au contraire avec le chipset south bridge, ce qui est une bien meilleure place au niveau des bus de donnees pour controler les fonctions de pre-boot.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 3.
Si tu te bases sur ce doccument pour te faire ton idee de TCPA tu peux effectivement paniquer.
Ces slides pretendent que la puce est "tamper proof" ce qui est completement faux, elle est completement accessible tant au point de vue hardware que software. On y apprend aussi que la puce TCPA va servir a faire respecter le DRM (ce qui est impossible cf mes posts precedents) et meme qu'elle possede un DRM check au boot(on en apprend tous les jours). Il ne faut pas croire tout ce que tu trouves sur internet....
des clés uniques à la fabrication de chaque PC sont stockées dans TCPA et accessibles uniquement par un OS crypté qui n'est chargé que si le hardware et le boot sont garantis par les clés uniques TCPA
Ces clefs ne sont pas accessibles par un OS crypte mais par un OS certifie. C'est le trusted root dont on parlait plus haut. Ces clefs ne sont la que pour s'assurer avant de delivrer un certificat TCPA, que ton ordinateur est bien capable de delivrer ce certificat. Donc
1) - Cette clef ne gene que les echanges de clefs avec une tierce partie , elle n'entrave en rien le fonctionnement de TCPA en mode "coffre fort", meme sans un systeme 100% pur TCPA on peut quand meme creer des clefs et des PCR a volonte, par contre on ne peut pas les distribuer.
2)- Elle n'empeche en rien le boot ou l'utilisation d'un OS ou d'applics non certifies. Elle n'empeche pas non plus d'utilser les fonctions TCPA non certifiantes.
3)- Sans cette clef des systemes possedant juste un chipset TCPA pourraient se pretendre Full TCPA Compliant, et donc de mentir sur le niveau de securite dont il dispose effectivement.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 2.
Le premier point sur le trusted root est en effet assez sensible, creer des organismes de certification capable generer un nouveau trusted root risque de ne pas etre evident. De plus ces organismes auront besoin pour creer ce root d'un grand nombre d'information vous concernant (le numero de serie de votre CPU, de votre Bios et le degree de conformite de votre machine a TCPA). Toutes ces informations leur permettront 1- de savoir exactement qui vous etes, 2-de creer a volonte un trusted root capable de tourner sur votre machine (et donc d'acoir un acces total sur toutes vos clefs). Mettre a disposition un outil capable de creer un trusted root risque donc de faire autant de mal que de bien. Mais le probleme avec le trusted root ne vient que si un utilisateur n'a pas le controle sur ses PCR, IE si je ne peut pas determiner quelles serie de composants sont necessaire au boot. Dans l'implementation actuelle on peut au contraire creer autant de PCR que l'on veut et ce base sur les infos que l'on veut. On peut en faire un qui boot a tous les coups, un qui exige la presence de telle ou telle carte PCI ou disque dur, un qui exige que tout soit rigoureusement identique etc... Si on enleve ce droit alors la oui on aura un probleme. Mais ce n'est pas le cas.
Comme le dit l'auteur du texte :
This, coupled with the inability to disable the extend capability, would prevent anyone from running an operating system of their choice.
Pour l'instant non seulement on peut desactiver le mode extend (ie tout doit etre TCPA certified), mais on peut meme choisir ce que l'on veut verifier. Il faut donc faire tres attention a ce point, mais pour l'instant ca va.
Je ne peux pas creer mon propre trusted root, mais j'ai des droits complets dessus (je peux meme aller chercher les clefs physiquement si ca me chante cf plus haut)
Je ne peux pas desactiver TPM mais je peux creer un PCR qui ne verifie rien. Je suis d'accord que ce n'est pas l'ideal, mais le choix contraire poserait au moins autant de probleme et remttrait en cause l'utilite de TCPA.
En ce qui concerne le troisieme point c'est assez vrai. Si je me place en mode trust, je prend pas mal de risque de me faire cibler, c'est a dire qu'un organisme regroupant les clefs identitaires de plusieurs machines serait capable de faire fusionner plusieurs de mes identites (par exemple de savoir que deux pseudos sont en fait une seule et meme personne.) Quand je veux echanger des clefs avec quelqu'un en TCPA je fais appel a une tierce personne (trust third party). Si je fait souvent appel a la meme boite, elle risque de pouvoir suivre mes habitudes sur le net. De plus si cette personne est aussi emettrice de certificat elle risque de pouvoir faire un recoupement complet sur mon identite. Il est clair que ceci pose un probleme d'anonymat sur le net. Bon outre le fait qu'une personne qui decide de vous retrouver a tous les moyens pour le faire aujourd'hui, il est vrai que d'avoir un organisme capable de savoir qui l'on est et ce que l'on fait sur le net est assez deplaisant (meme si on est deja loin du probleme pose par la possibilite ou non de booter son OS favori). Il a ete clairement defini qu'un certificateur ne pouvait pas etre un third party trust. Mais techniquement rien ne l'empeche. Seul petit probleme, a moins de s'echanger les clefs TCPA de la main a la main comme on s'echange aujourd'hui les clefs GnuPG il n'y a pas d'autres solutions. Par contre n'importe qui peut jouer le role de third party trust. Donc on aurait plutot besoin au contraire du support du libre au maximum. En effet il suffit de multiplier le nombre de third party trust pour que le recoupement de donnees devienne improbable. Reste a voir si c'est implementable, j'y jette un oeuil ce soir.
Ceci etant cet article ne fait pas non plus mention de danger immediats, juste de dangers potentiels. De plus sur les 5 suggestions qui sont faites, 2 ont deja ete realisees (4 et 5), une est irrealisable (3) une est dangereuse (1) et une pourrait effectivement etre un plus et a d'ailleurs ete envisagee par Intel (2).
il suffit de regarder le début des specs officeille TCPA, page 12, section 2.2 "trusted roots" pour voir que voir que le but de TCPA est tres proche de l'activation framework de Windows XP
Oui extremement proche, pour ne pas dire quasiment identique. A un detail pres : c'est l'utilisateur qui est aux commandes. Si j'ai envie de controler ce qui tourne sur ma machine, et d'empecher tout ce que je n'ai pas controle de tourner, c'est mon probleme. Parce que c'est moi qui decide. C'est exactement ca le but de TCPA et je ne vois pas le mal. Pour que cela se retourne contre l'utilisateur et l'empeche de faire quelquechose, il faudrait rajouter un grand nombre de limitations a ce qui existe a l'heure actuelle
-il faudrait enlever la possibilite de creer des PCR
-il faudrait enlever la possibilite de deplacer/copier les clefs
-il faudrait que l'ensemble des PCR/TPM crees avec les truted root exigent un systeme certifie jusqu'a la garde...
Pour l'instant on en est pas la, et heureusement.
Kha
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 5.
dès lors les fichiers ainsi cryptés deviennent inaccessibles à un autre OS en dual boot sur le meme machine.
Oui sauf que seul probleme si ils font ca tu ne peux plus acceder a ce fichier autrement que sur ta config actuelle. Tu ne peux plus le diffuser, le lire sur un autre PC, le reouvrir si tu change quoi que ce soit en hard sur ta machine etc..
En d'autres termes ce fichier deveint hyper confidentiel. Plus personne ne peut s'en servir a part toi sur ta machine avec ton hardware. Ca m'etonnerais beaucoup que ce comportement soit active par defaut.
Mes sources sont les memes que les tiennes je pense. Mais bon les voila quand meme :
The TCPA chip is not particularly suited to DRM. While it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use, this type of scheme would be a nightmare for content providers to manage. Any change to the BIOS, the operating system, or the application would change the reported values. How could content providers recognize which reported PCR values were good, given the myriad platforms,
operating system versions, and frequent software patches?
Ca ca vient de ton doccument favori. Pour ceux qui ne maitrise pas l'anglais il est dit qu'il est theoriquement possible d'utiliser TCPA pour bloquer la diffusion de doccuments DRM, a condition bien sur de connaitre la clef de boot de tous les systemes "Legaux". En d'autres termes d'avoir la collection complete de toutes les configs hardware et software imaginables (bon seulement celle qui respectent le DRM) et de la mettre a jour regulierement. Bonne chance a qui veux essayer, moi je regarde :).
Second, the IBM version of the TCPA chip, while evaluated to FIPS and Common Criteria security standards, has specifically omitted tamper resistance from the evaluation target. The IBM chip sits on the LPC bus, which is easily monitored. The chip is not defended against power analysis, RF analysis or timing analysis. The bottom line is that the physical owner of the machine could easily recover any DRM secrets from the chip. This apparent lack of security in the chip makes perfect sense when you realize that the purpose of the chip is to defend the user's data against remote (software) attack. When the goal is to protect the user's keys and data against external attack, we simply are not concerned with threats based on the user attacking the chip, as the user already has secure
access to his own data.
Ca aussi d'ailleurs ca vient du doc que tu site a tour de bras (et qui curieusement dit exactement le contraire de ce que tu entends). Ici il est dit que moyennant des connaissaances electroniques de base il est possible d'aller recuperer en clair l'ensemble des clefs stoquee sur la puce a condition d'avoir un acces physique a la machine.
-"Oh ben ma clef elle est toute bloquee dans mon ancien PCR, et je peux pas la lire.
-"C'est pas grave mon petit on va aller te la chercher ta clef. Tiens la voila. Bon je te la copie dans la zone publique comme ca la prochaine fois que tu change de carte video ca se passera bien
-"Merci monsieur
Aller hop on enchaine sur
http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
La on a toute l'algorithmique que j'ai decrite grossierement plus haut. Et si on s'y connait un peu on se rend compte que savoir si telle ou telle clef a ete generee avec un OS windows ou Linux est impossible. C'est encore moins facile pour le PRC que pour quoi que ce soit d'autre.
10.4.5 Creating a PCR composite hash
The definition specifies the operation necessary to create TCPA_COMPOSITE_HASH.
Action
The hashing MUST be done using the SHA-1 algorithm.
Dans SHA-1 il y a 160bits dont 80 bits de de codage et 80 bits de donnees. C'est clair que sur 10 caractere il va y avoir le nom de mon os, le modele de ma carte graphique, savoir si il y a un autre OS a cote etc..
Ben non une fois le PRC genere pour une selection de composant c'est completement irreversible. On peut recalculer pour la meme selection et voir si rien n'a change, mais pour savoir ce qui est installe en partant du PRC bonne chance !!!
La phrase qui te fait si peur :
The "trusted" boot functions provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence.
Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has backdoored the operating system, the PCR value will not match, and the unseal will fail, thus
Ne veut pas dire que un OS peut aller sans que tu le sache crypter des docs et des executables pour etre sur que tu ne t'en serve pas sous un autre systeme. Pour etre exact c'est meme exactement le genre de chose dont TCPA te protege. Si Windows a l'install te locke des executables avec des clefs basees sur le PCR (ce qui veut deja dire que windows est un executable qui s'autocertifie vis a vis de TCPA ce qui me semble impossible vu la doc).
1) Il se tire une vache de balle dans le pied. Parceque TCPA c'est pas comme le systeme de protection actuelle, c'est pas dans 30 jours, c'est tout de suite. J'ai flashe mon bios ? Tous les outils proteges par clef sont bloques. Qu'est ce que je peux faire ? Rien sauf si je connais l'astuce.
2) Il est possible de facon logicielle et de facon materielle de changer les clefs de place.(Et heureusement d'ailleurs il manquerait qu'un serveur de donnees critiques soit completement out parce qu'un des disques raid a lache). Le vilain windows il a mis des clefs dans un PCR, bon ben on va les copier dans l'autre alors (Voir meme on va les mettre en acces hors PCR).
Le but du PCR n'est pas de surveiller ce que tu fais mais d'empecher des programmes d'avoir acces a tes donnes et applications critiques. A la limite on peut se sevir de TCPA pour empecher Windows de changer le boot record a l'install.
Si ils respectent les normes qu'ils se sont eux-memes fixes il n'y a vraiment aucun danger.
Kha
[^] # Re: TCPA confirmé comme tueur de Linux
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 2.
Kha
(qui commence a trouver qu'il y a de l'echo, doit y avoir un truc creux pas loin)
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 7.
nous soyons tous obligés d'utiliser Windows pour lire la plupart des documents que l'on reçoit, sans possibilité de les transférer sous Linux,
à cause de TCPA !
C'est justement ca que tu ne comprend pas, si c'etait le cas je serais de tout coeur avec toi contre TCPA, mais l'exemple que tu donne est incoherent.
Il y a trois mode de cryptage dans TCPA qui correspondent a trois besoins differents.
---Le premier mode est un mode securitaire paranoiaque. Si un fichier est crypte avec ce mode seule la machine qui a crypte ce fichier, avec l'os qui a crypte ce fichier et le hardware intouche peut decrypte ce fichier. En d'autre terme pour lire un fichier cryptee en type1 (je ne sais pas si c'est l'appellation officielle mais elle est utilisee sur pas mal de brochures) il faut la machine, l'OS et le Hardware et les references TCPA.
Un fichier crypte par ce mode est completement illisible pour n'importe quel autre systeme sous n'importe quel autre ordi. A la limite si tu te fait un dual boot Windows/Windows sur ta machine (avec deux install windows strictement identiques) ton deuxieme Windows sera incapable de lire un doccument crypte avec le premier(Meme hardware, meme install, mais les attributions TCPA ne sont pas les memes donc le coffre ne s'ouvre pas pour cette clef).
Je ne sais meme pas si ca marcherait en faisant un ghost de ton disque et en remplaceant le disque original par une copie.
Si quelqu'un t'envoit un jour un fichier crypte comme ca, tu peux installer windows, office et rencontrer personellement Balmer, tu ne pourras pas ouvrir ce fichier. Point final.
---Le deuxieme mode est un mode d'identification d'identites. Il permet de m'assurrer que la personne en face de moi est bien qui elle pretend etre, ou que la personne qui consulte tel ou tel doccument est bien habilitee a le faire. C'est un principe de clefs assymetriques tout ce qu'il y a de plus courant,sauf qu'il est gere en hardware. Dans ce cas la on se moque de savoir quel est ton hardware, ton OS, ta religion et la couleur de tes chaussettes. La seule question est "Est-ce que tu connais le code ?" si oui on echange la clef et tu peux lire le doc, si non ca s'arrette la.
---Le troisieme mode est une sorte de mix des deux autres. Le but du jeu est ici d'identifier un ordinateur avec un niveau de paranioa reglable qui va de "oui c'est bien le bon processeur" (ie c'est une machine que je connais meme si on a change son os, son disque dur ou le nom de l'utilisateur). A oui c'est l'exacte configuration que je connais. En mode 3 tu generes ta clef avec le degre de paranoia que tu veux et tu l'envois au certificateur. Celui ci n'a aucun moyen de savoir quel OS tu utilise a partir de la clef que tu lui a envoye. Donc quand il va crypter les donnees en utilisant cette clef, il va le faire de facon independante de l'OS. Et quelque soit l'OS qui ait envoye la clef, il pourra decrypter le message.
Mais si une personne veut t'envoyer un doccument crypte avec l'espoir que tu le lise (et pas seulement pour avoir une copie ailleurs que sur son dur) il est oblige d'utiliser le deuxieme ou le troisieme mode. Or rien dans TCPA ne permet de faire de segregation, Ca marche, ou ca ne marche pas, il n'y a pas de si. Il n'y a pas moyen de dire on peut ouvrir le fichier avec mot de passe SI l'OS est windows(methode 2). Pas plus que l'on peut dire en methode 3 on peut ouvrir le fichier sur ce PC si l'OS est windows. On peut verifier que la config n'a pas changee depuis l'emission des clefs, mais pas bloquer le decodage d'un fichier si ce n'est pas le cas.
En d'autre termes si un copain t'envoit un fichier crypte depuis windows et que tu ne peux pas l'ouvrir, ce n'est pas la faute de TCPA.
Kha
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 7.
Apparemment on a un gros probleme de comunication toi et moi.
TCPA en tant que tel ne changera rien a la compatibilite entre Windows et Linux. Si je choisis de crypter un doccument sous Office en mode exclusif, non seulement mon Linux ne peut pas le lire, mais aussi n'importe quel autre PC sous n'importe quel OS (windows compris) ne peut pas le lire non plus, parceque la clef elle est dans ma puce, et comme c'est une clef de protection (type 1) je ne peux pas la redistribuer.
Par contre si je veux pouvoir utiliser ce doccument sur d'autre PC ou avec d'autre OS il faudra que je crypte mon logiciel avec une clef de type identitaire (type 2) ou d'autehntification (type 3) qui elles sont distribuable et ne dependent ni de l'OS, ni du programme, ni de la config hardware (ce qui est parfaitement logique vu que ces clefs sont faites pour permettre un echange de donnees.)
J'irais meme jusqu'a dire au contraire, a l'heure actuelle l'algo qui est utilise par MS pour le cryptage des donnees est proprietaire et protege (RSA 4 si ma memoire est bonne), et Open Office ne peut pas ouvrir les doccuments cryptes par cette methode(il gere les protections mais pas le cryptage).
A l'inverse si Office utilise le systeme de cryptage TCPA, alors un doccument crypte en type2 ou type3 sera tres facile a decoder vu que l'ensemble des fonctions seront deja implementee en hardware par la puce. Il n'y aura qu'a les invoquer dans OOo (Et on a deja le code GPL pour le faire, merci IBM) et le tour est joue.
TCPA ne change rien a ce niveau la, voir meme facilite la vie.
Kha
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 7.
[^] # Re: TCPA confirmé pour Prescott
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 10.
[^] # Re: Les statistique Google reconnaissent les navigateurs basés sur Gecko
Posté par Jerome Herman . En réponse à la dépêche Les statistiques Google reconnaissent les navigateurs basés sur Gecko. Évalué à 2.
[^] # Re: Les statistique Google reconnaissent les navigateurs basés sur Gecko
Posté par Jerome Herman . En réponse à la dépêche Les statistiques Google reconnaissent les navigateurs basés sur Gecko. Évalué à 3.
Ce n'est pas aussi simple que cela. Si il n'y a qu'un seul moteur, on est loin de l'esprit du libre, on a a faire a une situation de monopole et la norme devient indissociable du produit. De plus qui irait tester son site contre les standards de la W3C si il passe correctement sous le seul et unique moteur qui existe. Le comportement le plus vraissemblable serait plutot : "je teste mon site avec xbrowse et les standards je m'en balance". A partir de se moment la lorsque le boite bidule va passer de xbrowse a ybrowse meme si ils suivent les standards a fond ils risquent de se retrouver avec un certains nombre de sites qui ne respectent pas les standards, qui passaient tres bien sous xbrowse et qui crashent sous ybrowse.
De plus il y a trois facon de respecter une norme :
- Respect strict : tout ce qui n'est pas la norme ne marche pas, tout ce qui est la norme marche
- Respect permissif : tout ce qui est la norme marche, tout ce qui n'est pas la norme on sait pas. (les bons vieux warnings du C...)
- Respect Partiel : Tout ce qui marche est dans la norme, mais on a encore un paquet de fonction non implementees.
Le HTML est une norme qui supporte tres bien le fallback (ie si une fonction n'est pas supportee, on fait autre chose), et il est assez facile a mon sens d'ecrire un site simple et fonctionnel qui passe avec n'importe quel navigateur et de rajouter les zigouigoui rigolos derriere. Seulement tres peu de gens procedent de cette facon. Par contre si il y avait 200 moteurs, tout le monde ferait comme cela. Et je pense perso que ce serait un vrai plus.
Gecko pour moi c'est plus la libjpeg, je vois pas l'intérêt de faire 15 versions différente d'un truc utilitaire.
A mon sens Gecko est plus un outil oriente utilisateur final, qu'une bibliotheque. Mais tant bien meme ce ne serait qu'une bibliotheque ce que tu dis n'es vrai que dans le cas ou le HTML est une norme
- 1) totalement implementee (ie toutes les fonctions HTML sont supportees)
- 2) figee (ie pas d'ajout de fonctions a venir).
Je ne sais pas, mais je pense que ca representerait pas mal de boulot d'ajouter la prise en charge d'une dimension supplementaire dans libjpeg (ie si demain on demande a libjpeg de faire de la compression d'hologrammes). Ben le HTML c'est un peu ca tous les jours. Ca oblige a pas mal de souplesse et d'ouverture d'esprit au moment du dev. Et il peut oujours arriver le moment ou un des deux groupes se dit "mince on avait pas prevu ca du tout", et la l'autre groupe est une veritable bouee de sauvetage. Il y a de part le monde des dizaines de librairies sur les matrices, la gestion des images, les acces disques etc. D'un point de vue exterieur on pourrait penser que toutes ces bibliotheques font la meme chose. Mais elles ne le font pas de la meme facon. Et quand ca coice avec une, il est hautement appreciable de pouvoir se rabattre sur une autre.
Mais pour moi Gecko n'est pas juste une bibliotheque. Il n'existe pas une seule facon d'interpreter du HTML et de l'afficher, et les choix fait par Mozilla peuvent ne pas plaire a tout le monde, le mode de gestion de la page (meme si au final le rendu est le meme) peut varier du tout au tout . Tout depend du but vise. Les objectifs a court terme de KHTML et Mozilla sont assez differents je pense. KHTML a l'air de vouloir faire un support optimise quite a ce qu'il soit restreind, alors que Mozilla cherche plutot un support complet au detriement de l'optimisation. Il s'agit bien de deux philosophies differentes a la base et de deux ergonomies differentes pour l'utilisateur au final. Donc c'est exactement la meme chose que Gnome et KDE.
[^] # Re: Un portable Lindows
Posté par Jerome Herman . En réponse à la dépêche Un portable Lindows. Évalué à 1.
Jusqu'a XP l'Explorer etait un des plus grand bouffeur de ressources qui soient. Faire une copie de plusieurs doccuments de taille importantes de disque a disque (meme d'un disque sur lui meme d'ailleurs.) surtout si le reseau rentrait en ligne de compte, avait tendance a fiche par terre une machine. Si quoi que ce soit ne se passait pas idealement (disque fragmente, lag reseau, prob de lecture CD-ROM etc.) on se retrouvait a 100% de ressources prises et ce independamment du nombre de processeurs, de la ram, de la vitesse du systeme...
Ca en etait a un tel point que j'avais pris le reflexe de lancer une commande dos a chaque fois que je voulais faire une copie, et j'avais des gains de perfs de l'ordre de 50%. Le plus beau cas que j'ai vu etait sur une copie de donnees depuis un DVD (distrib linux, pas de rip)
Copie sur le disque via Explorer : 8Mo/s
Copie sur le disque via DOS : 16Mo/s
J'ai refait le test je ne sais pas combien de fois pour etre sur, mais simplement en invoquant une ligne de commande je gagnais 100% de vitesse. En plus la ou mon PC etait quasiment unitilisable avec Explorer, je pouvas sans aucun probleme m'en servir quand la copie se faisait en DOS.
Sous XP manifestement ce comportement a ete en grande partie corrige, et il semble qu'explorer soit desormais traite comme un process comme les autres et non plus comme un dieu tout puissant dont on apaise la colere en lui sacrifiant des ressources. Mais je n'ai pas eu le temps de faire de tests intensifs, je n'ai pas XP et je n'aime pas XP (pour des raisons purement politiques ceci dit: la license m'arrete net).
Kha
[^] # Re: Les statistique Google reconnaissent les navigateurs basés sur Gecko
Posté par Jerome Herman . En réponse à la dépêche Les statistiques Google reconnaissent les navigateurs basés sur Gecko. Évalué à 3.
BeOS et FreeBSD/NetBSD(avec support des binaires linux) manquent a ta liste , mais bon le principal chiffre a retenir est 95 a 97% des surfers supportent la techno Flash. Ce qui signifie un seul dev pour toucher 95% du marche (sans tests dans tous les sens, sans cadrages x ou y, sans ce demander ce qui se passe si le mec navigue en bi/tri ecran etc...)
Mais ce qu je voulais dire c'etait surtout que meme a une epoque il y avait tres peu de moteurs de rendu HTML, pas mal de gens pensaient que Flash etait une alternative facile et peu couteuse a mettre en place. Ce qui va contre l'idee que moins il y a de moteurs plus le travail d'un webmaster est simple. Ce qu'il faut retenir c'est que si il y a plus d'un moteur HTML alors il est plus simple pour un webmaster d'en avoir 200 qui vont chercher a suivre les normes le mieux possible et se consulter frequement pour savoir comment interpreter telle ou telle balise, que d'en avoir deux ou trois qui vont passer leur temps a se tirer dans les pattes pour devenir le seul et unique(Cf guerre [layer] vs [Div]).
Kha
# Les statistiques IE6.0 une explication
Posté par Jerome Herman . En réponse à la dépêche Les statistiques Google reconnaissent les navigateurs basés sur Gecko. Évalué à 8.
C'est pas vraiment rassurant non plus, ca aurait tedance a montrer qu'apres 10 ans de NT les gens ont encore tendance a se tourner vers Microsoft pour leur solutions professionelles.
Kha