Et l'os loader NT si je lui rajoute une ligne pour qu'il charge OpenBSD il change de signature aussi ? De toute facon uen fois de plus deux PC identiques n'auront pas le meme Hashage du boot.
lors du boot de l'OS 1, la puce ou le bios stocke un checksum de l'OS loader
presque le checksum de l'init de l'OS loader. Bien sur si c'est lilo en multiboot il est bien avance.
tout autre OS ne peut donc pas y accéder, ce qui est inquiétant pour les OS alternatifs !
Pas du tout, ces clefs sont de toute facon migrables vers une autre zone par l'admin de la puce. Si tu as besoin de sortir une clef d'une zone de boot tu peux declencher sa migration soit vers une autre zone de boot soit vers une zone non lie a une sequence de boot. C'est un peu fastidieux mais ca se fait tres bien.
Alors que aujourd'hui, avec des softs libres et sans matos TCG, il est tout à fait possible d'utiliser des algos de crypto mieux considérés + fiables que le RSA de TCG (AES ou des algos symmétriques car pour cet usage précis on a pas besoin de crypto assymétrique) et des clés de taille supérieure ( limitation de taille de l'ordre de 1024 bits dans TCG) pour interdire à quelqu'un de booter sur ta machine et d'accéder à tes données s'il n'a pas ta clé (cela lui interdit aussi d'accéder aux données s'il emporte ton disque dur)
Si il est deja possible de faire meiux et plus fiable de facon logicielle je ne vois pas ce que tu reproches a TCPA. Si ca n'apporte vraiment qu'une protection inferieure a ce qu'il est deja possible de faire logiciellement alors pourquoi es-tu aussi remonte ?
Mais je suis d'accord avec toi ! Je veux pouvoir continuer a booter linux et continuer a pouvoir faire de l'interroperabilite entre OS comme les amendements de la loi sur les brevets m'y authorise officiellement. Seulement TCPA ne me gene pas dans ce but. Ex Palladium oui ! Je suis contre DRM et contre toute tentative qui vise a essayer de me faire perdre du controle sur mes propres doccuments sur mon propre reseau. Mais TCPA ne permet pas ca.
si les périphériques USB (aujourd'hui majoritaires) ne sont pas encore pris en compte par TCG, cela ne fait que simplifier la base de données des checksums des OS et matériels qui permettront d'identifier ta plateforme
Certes, peut etre meme que comme ca on arrivera a trouver assez de molecules dans l'univers pour stocker toutes les possibilites. Par contre ca ne servira a rien vu que comme les periphs seront rajouter apres rien ne garantie l'integrite de la protection.
De toutes façons les périphériques USB non encore pris en compte permettront uniquement de copier des fichiers audio/video...
Ah bon ? tu peux m'expliquer ce qui va m'empecher de sortir un doccument different ? Si le systeme est persuades d'etre en mode full DRM alors qu'il ne l'est pas qu'est ce qui m'empeche de copier un fichier dans une zone qu'il considere comme legale ? Dans le pire des cas je epux toujours sortir mon doccument comme un compose audio ou video.
c'est surtout la possibilité d'identifier un OS pour interdire à des OS alternatifs d'accéder à certains contenus ou certains programmes
Soit rassure, TCPA ne permet absolument pas de faire ca (a moins bien sur que la personne qui a installe ton serveur d'identification soit egalement ton fabriquant et ton fournisseur de contenu et ton certificateur). Je te renvois encore une fois a mon post plus haut.
C'est justement parceque les gens qui peuvent se servir de ce type de systeme ne sont pas forcement mes amis que je suis content que celui-ci soit surveille et controlle. J''ai du mal a te suivre la. En plus si il y a bien un truc que TCPA ne peut pas faire c'est bien d'identifier un OS, il peut identifier la sequence d'initialisation du boot loader, ce qui est genial parceque celle ci depend du type de disque (IDE, SCSI, Firewire, disquette, cdrom) du systeme de fichier, de la taille du disque et du modele du lecteur. La base de donnees qu'il faudrait a partir du checksums pour reconnaitre l'OS sur le point de booter est absolument monstrueuse. Quand a ce checksum cf plus bas
1 TCPA ne fourni jamais les checksums ! Il fournit une clef publique basee sur le checksum dans une certaine mesure. Impossible donc a moins d'avoir une connaissance parfaite du contenu de la puce de retrouver le checksum. Sauf dans le cas hyper particulier de l'identifiant on se retrouvera a chaque fois avec un facteur aleatoire qui viendra mettre le bazar. Seul la generation en parallele de clefs privees rigoureusement identiques permet de casser ce facteur aleatoire et d'avoir acces aux donnees decryptes. De plus meme les clefs basees sur un hashage d'authentification seront toutes impactes par l'ensemble ID fabriquant/Nombre Aleatoire dans le cas de demandes de checksums authentifies. Et donc pour obtenir le checksum il faut avant tout posseder les deux autres infos et je dit bien posseder car la puce ne les laissera sortir que si il y a une operation physique effectuee par le fabriquant sur la puce elle-meme. En ce qui concerne laisser sortir une info seule de la puce c'est absurde, tous les hashages sont identiques d'une puce a l'autre mais les clefs publiques et les clefs privees qui en resultent (et qui sont les seules a sortir de la puce "facilement") sont impactes par un facteur aleatoire. Si ce facteur est regenere a chaque fois (ce qui est le cas pour toutes les operation sauf authentification certifie par une tierce personne) il est impossible de casser la clef publique (a moins de pouvoir aller lire le facteur aleatoire sur la puce ou d'avoir beaucoup de temps a perdre).
Deux hashages successifs des memes parametres de la meme sequence de boot donneront deux clefs privees differents.
2. Eh bien premierement le fait que ce soit techniquement une architecture fermee qui ne fonctionne que par challenge-response. Il faudrait donc que l'emulateur logiciel soit capable d'emuler parfaitement le comportement d'une puce TCPA pour pouvoir donner des reponses coherentes aux differents challenges, or la puce TCPA a ete construite pour rendre ce genre de chose tres difficile. Deuxiemement uen fois de plus on obtient pas le checksum mais une clef publique. Impossible donc de juste recuperer un a un tous les checksums possibles et de faire des melanges. On peut eventuellement essayer de s'amuser a generer toutes les clefs privees possibles liees a un checksum donnees et puis les essayer une a une sur la clef publique renvoye par l'utilisateur, apres tout il n'y en a que quelques millions. A mon sens recreer une puce TCPA avec le meme coupe ID Fournisseur/NA est quand meme beaucoup plus rapide.
Pour finir je ne vois pas ce que les softs viennent faire la dedans. TCPA est totalement incapables de faire le checksum d'un ou plusieurs softs.
Je me reand compte que j'ai oublie de preciser deux choses :
1) Avec chaque nouveau hashage il faut un reboot, la puce TCPA ne faisant des hashages que lors du boot.
2) les peripheriques branchees a chaud ne sont donc pas detectables par TCPA, une carte son USB ou PCMCIA, un periph video FireWire ne sont donc pas detectable par la puce si ils sont ajoutes apres le boot, la seule solution possible pour eviter uen copie par ce genre de periphs avec TCPA et de demander a ce que le bus correspondant soit desactive.
Rien tu as tout a fait raison.
L'utilisateur etant le maillon le plus faible de la chaine c'est a lui qu'il faut fournir des outils pour renforcer ce maillon
Il y a un excellent exemple au sujet des mots de passe plus haut je vais le reprendre.
Si un utilisateur a un mot de passe "faible" il se fera casser en quelques minutes (via une attaque par dictionnaire sur le fichier de mot de passe par exemple). Par contre si le mot de passe est crypte dans la puce alors pas moyen de faire une attaque sur le fichier de mot de passe (qui n'existe plus). Et la puce ne reagit que par challenge/response donc le mot de passe ne sort plus (sauf intervention de l'admin de la puce).
Derniere chose imagine un key logger qui tourne, tu recupere le mot de passe d'un mec a distance, tu essayes de te connecter a distance et tu rentres le mot de passe. Et paf ca ne marche pas, la puce refuse de laisser sortir cette identifiant la pour une session ouverte a distance par un ordinateur non connu.
C'est ce genre de choses que TCPA permet de faire, c'est vrai rien de plus et rien de moins que ce que l'on peut faire avec des logiciels libres si ce n'est le cote coffre-fort de donnees auquel aucun acces brut n'est possible (sauf a l'admin de la puce.).
N.B : Par acces brut j'entend un acces au fichier dans sa forme cryptee ou un acces raw au device qui contient les donnees cryptees.
Alors non TCPA ne permet ni l'identification de materiel, ni l'application de droits DRM, et si c'etait possible les editeurs serait surement les derniers a pouvoir le faire.
Il est quand meme bon de se rapeller que dans le trusted computing le moteur c'est IBM, et qu'il a investit des miliards dans Linux.
Bon alors je vais te reexpliquer une derniere fois comment fonctionne l'identification a distance de TCPA et pourquoi ca serait une TRES mauvaise idee de pouvoir le faire soit-meme. Par contre tu verras on peut parfaitement le faire en libre.
La puce TCPA contient un emplacement special qui n'est considere ni comme une zone d'archivage privee ni comme une zone d'archivage publique. C'est une zone ID de laquelle la clef ne peut sortir que dans des circonstances extraordinaires (il faut faire venir le constructeur de la machine).
Cette zone contient optionellement (pour l'instant : jamais) une clef fabriquant OU une clef fournisseur. Cette clef et techniquement irrecuperable et elle est la meme sur toute une gamme de produit. Cette zone contient aussi un nombre genere aleatoirement et sauvegarde.
Pour obtenir un certificat d'identification il te faut d'abord une demande de hashage pour savoir ce que tu vas faire rentrer dans ton identifiant (cela peut-etre seulement la clef+le nombre aleatoire mais tu peux aussi rajouter ta carte video, ton bios, ta carte son etc.. )
Le systeme fonctionne comme suit : tu te connecte a un fournisseur de certificat et tu lui envoit la clee publique de ton hashage. Celui-ci se connecte alors a ton fournisseur de contenu et lui renvoit alors une clef publique certifiant que tu as bien une puce TCPA. Ton fournisseur de contenu fait ensuite une demande une demande de clef symetrique pour lui et toi et le certicateur vous fourni a tous les deux cette clef symetrique. Ton fournisseur de contenu et toi dialoguez ensuite en utilisant cette clef.
Cela est extrememnt securise et tres respectueux de la vie privee. Neamoins etudions le pire cas possible.
Pour que ton fournisseur puisse reellement t'identifie et savoir de quel materiel tu te sert il faut d'abord qu'il te demande un hashage ID pur (ie ta clef ID constructeur+nombre aleatoire). Pour pouvoir casser cette clef et connaitre le contenu du nombre aleatoire il faut qu'il possede ta clef constructeur (et donc qu'il soit le fabriquant de ta machine ou alors severement de meche avec lui). De plus le nombre aleatoire etant par essence aleatoire il ne faut pas qu'il se trompe de clef non plus, sinon il reccuperera un nombre d'apparence correcte mais faux. Il faut donc aussi qu'il soit celui qui t'ai fourni ton appareil et qu'il est pris soin de noter ta clef auparavent.
Finalement pour recevoir ta clef lors de la demande d'identification il faut finalement que ce soit egalement lui qui fasse office de certificateur (sans quoi il ne recevra que la clef symetrique certifie pour le dialogue).
Donc oui si ton constructeur est ton fournisseur et est aussi ton certificateur alors il eput recuperer la partie aleatoir de ton identifiant unique par recoupements.
Bon, comme le pire peut toujours arriver admettons que ce soit le cas. Cette personne peut desormais identifie ta puce (et rien de plus) par demande d'un hashage ID pur.
Mais si elle veut faire jouer DRM ce qui l'interesse c'est de savoir quel tpe d'OS tu utilises, quel type de materiel tu utilise etc.
Pour identifier ta carte son par exemple voici la methode.
1) recuperer le nombre aleatoire de l'ID par la methode ci dessus
2) demander une serie de hashages ID+nombre aleatoire+periph PCIx (avec x entre 0 et 6)
3) Creer une PC a l'identique du tien en mettant en place le meme ID constructeur et le meme nombre aleatoire que dans ta propre puce (il peut le faire vu qu'il est aussi ton constructeur dans ce scenario super catastrophe).
4) Pour toutes les cartes sons compatibles DRM creer un hashage ID+NA+PCIy (avec y = position de la carte son)
5) Pour toutes les cartes son non DRM creer un hashage ID+NA+PCIz (avec z position de la carte son)
6) Verifier que dans la serie de hashage demandes a l'utilisateur en 2) si il y a bien un hashage identique a 4) et aucun hashage identique a 5).
7) Se rejouir en se disant qu'il ne reste plus qu'a verifier les autres periphs
Dans le pire scenario possible, en donnant acces a tout un tas d'autres informations a ton fournisseur de contenu ca reste quand meme vraiment penible de faire du DRM non ? (Bien sur au moindre flashage de bios d'un des periphs le hashage change aussi).
Par contre comme tu peux le constater il y a intervention d'une tierce partie qui sert de certificateur, ce qui a soi seul justifie que les algorithmes de verif ne soient pas disperses dans la nature. Mais rien n'interdit de voir un jour un serveur de certification etre mis en place par un organisme du libre.
Meme si en theorie tu n'as pas tort, en pratique ca risque de s'averer devastateur (pour le cote Palladium).
Je m'explique : dans un monde dans lequel 1) le marche serait dans un etat sain (ie liberte totale de choix entre plusieurs produits et connaissances de l'ensembe des produits) 2) les acheteurs auraient conscience des risques lies a la divulgation d'information personelle ta theorie deviendrait realite.
Malheureusement avec une ennorme partie du marche deja acquise a Microsoft et des gens persuades que l'on ne peut craindre d'etre fiche que si l'on a quelque chose a se repprocher ca ne marche pas du tout. Le consomateur aura le sentiment de "perdre" quelque chose. Par exemple si les technologies DRM ou la lecture de certains types de doccuments deviennent impossibles sous une alternative alors le consomateur sera frustre.
De plus comme on est en situation de monopole les fournisseurs de service payant necessitant l'utilisation de technologie DRM ne verront pas l'interet de faire d'effort. Il suffit de voir a quel point il est dur de faire changer une page web pour qu'elle devienne lisible par tous les navigatuers lorsque l'on est une minorite. Et encore dans ce cas la on a la norme de notre cote, la mise en place d'une nouvelle page est souvent triviale (rendre un site lisible ne requiert que rarement plus de 1semaine/h) et le service propose par le site reste identique.
Dernier point dans le cas du secure computing (a ne pas confondre avec le trusted de TCPA) on se retrouve dans ce qui s'apelle un trust horizontal. Microsoft controllant la norme (et donc le materiel qui respecte ou non la norme) les logiciels permettant de creer les doccuments de confiance, les logiciels pour les distribuer et les logiciels pour les visualiser. Ce type de trust est le plus dangereux (beaucoup plus qu'un monopole fut-il planetaire) et la loi americaine vise plus particulierement ce genre de situation.
Je te soutiens dans ce combat pour eviter l'amalgame. J'ai aussi perdu temps et XPs (que j'ai regagne dans le meme thread donc pas de rpobleme) avec cette confusion.
Par contre
1) tu m'as grille
2) Felicitation pour ta nouvelle orthographe.
On va encore me traiter de raleur et de pinailleurs mais il ne faut pas confondre le systeme de Microsoft (Secure computing) et celui du consortium avec entre autre Intel et IBM dedans (Trusted computing).
TCPA permet exclusivement a un utilisateur de mettre des clefs et des informations dans la puce. C'est l'utilisateur qui possede les droits sur la machine qui choisit ce qui est securise par la puce ou non, et c'est aussi lui qui choisi dans quelles conditions cela ce fait. Une personne qui a les dorits sur la puce peut faire ressortir de la puce n'importequelle clef qui y est rentre (ie qui n'a pas ete generee par la puce elle meme). TCPA est donc tres difficielment utilisable a des fins restrictive telle que le controle de license, l'invalidation de doccument ou de programmes et bien sur le DRM
A l'inverse Ex-Palladium ne laisse aucun choix a l'utilisateur. Il divise l'ordinateur en deux zones completements disjointes (tout du moins c'est le but). D'un cote les programmes certifies tourant sur du materiel certifie de l'autre les programmes inconnus et le materiel douteux. De plus le systemes se reserve le droit d'invalider les programmes ou les doccuments au bout d'un certain temps si la license n'a pas ete renouvelle aupres d'un serveur de confiance (ideal pour le DRM). Ce dernierpoint etant d'ailleurs a rapprocher de la derniere declaration du chef de la securite de MS qui annonce un systeme de mise a jour et d'installation automatqiue des updates de securite.
Pour l'instant meme apres avoir epluche les docs TCPA deux cents fois je ne vois pas ce qu'il y a de mal dans cette puce (et je suis un parano de premiere). Par contre je me mefie comme de la peste de la solution Microsoft.
La DTD par defaut des doccuments word/XML n'est pas connue, et ne le sera peut etre jamais. Et comme l'ensemble des secretaires, analystes et commerciaux du monde vont pas faire leur propres DTD (meme sous office Pro) ....
Le probleme souleve par PBPG est assez complexe et doit etre pris en compte :
1) Quelles vont etre tes quantites d'achat initiales, es-tu sur de pouvoir retrouver exactement les memes produits si la demande suit ? As-tu au moins un developpeur dans ton equipe (absolument necessaire sous Linux pour adapter certains drivers ou mettre ne place certain patch kernel).
2) Quelle est la garantie de base ? Es-tu considere comem revendeur par tes fournisseur ou dois-tu faire appel a une tierce personne en cas de retour de materiel, as-tu teste la compatibilite des produits ?
3) Si une personne ne veut pas de la Mandrake que se passe-t-il ? Peux-tu faire des install personalisees ? Es-tu capable de fournir 10 , 100, 1000 machines rigoureusement identique a une collectivite ou a une entreprise ? Peux-tu gerer un paiement a 30 jours ? 60 jours ? 90 jours ? Mettre en place un serveur de facon exceptionelle chez un client pour gerer tout un parc de tes propres machines ?
4) La carte graphique n'est pas mentionnee, quid ? Est-elle fournie a la demande ? Fournie suivant les stocks ?
5) IIYAMA est devenu issuportable pour le SAV prend du Viewsonic si tu peux, ici on se bat avec eux jours et nuits et on a un peu plus de 4000 ecrans, donc si on ne trouve pas d emoyen de leur mettre la pression, toi tu risques de ne meme pas avoir de reponses.
C'est tout ce a quoi je peux penser pour l'instant.
Bonne chance a toi
Euh c'est suppose presque marche en theorie, mais en pratique il n'y a pas un seul logicile qui le supporte a l'heure actuelle. Donc si tu veux graver il faut rester en stable.
Les gens ne veulent pas passer sous office jamais, et puis un jour ton client t'envoie un doc en XML2003 de chez MS et tu peux pas l'ouvrir. Et la tu cherches la solution et tu prend 1 Office 2003. Au bout d'un moment tout le monde bosse dessus et il y a la queue pour se servir de la machine avec Office 2003, alors tu en prend 10 seulement pour les services qui traitent directement avec les clients qui ont Office 2003.
Et puis apres ben tu es oblige de mettre du 2003 partout parceque maintenir 2 versions d'Office differentes c'est complexe, parceque le service d'a cote est jaloux, parceque Mr Michu il peut pas relire le travail qu'il a fait chez lui a la maison.
C'est ce qui s'est passe entre word 2 et word 3, idem 3->95 et 95->97. 2000 et XP etait compatibles avec 97 (enfin presque) alors l'upgrade etait pas obligatoire. Bon les utilisateurs forcenes d'excel sont passe en 2000 parcequ'il fallait reussir a gerer plus de 255 types de mise en forme differentes mais c'est tout.
Mais la avec le format XML2003 de chez MS j'ai peur.
Quand on va les differences entre un Solaris de base et un GNU/Solaris utilisable facilement on ne peut repondre qu'une chose :
TOI MEME
C'est pueril mais ca fait du bien
La seule raison qui puisse les pousser a faire ca, excepte prouver au monde entier qu'ils peuvent etre plus betes que les editions Albert-Renee et Microsoft reunis c'est parcequ'ils veulent monter dans les moteurs de recherche.
Je propose donc de les y aider un grand coup en mettant une declaration de metas-keywords sur toutes les pages qui ressemble de pres ou de loin a une liste de trucs.
donc allons-y
meta NAME="keywords" CONTENT="annu, annuaire, annus, annuaires"
meta NAME="description" CONTENT="Annuaire de ..."
Pas de probleme, ce texte peut etre considere comme "public" (rendre un texte libre demande un certain nombre d'efforts que ce texte ne justifie pas). Donc vous pouvez en faire a peu pres ce que vous voulez. Basiquement cela veut dire que je m'engage officiellement a ne jamais reclamer de royalties dessus, et que ce texte peut etre considere comme appartenant au domaine public des aujourd'hui.
Et bien detrompe toi largement, il est beaucoup plus facile de lire un DVD sous Linux que sous n'importe qu'elle autre plateforme, en effet les principaux lecteurs DVDs accedent au contenu du DVD en mode raw, ou au moins sans monter le file-system. Ceci fait que l'immense majorite des protections physiques (les zones RPC et consors) se retrouvent a la rue en deux secondes. Bien sur la protection CSS est elle aussi en morceau depuis des annees. Au final il est tout a fait possible de lire un DVD zone 1 sur un lecteur locke en zone 2 par exemple. Bref jamais de mauvaises surprises avec un dvd import. Perso j'utilise Xine pour regarder tous mes DVDs, et comme je passe la moitie de mon temps aux US j'ai autant si ce n'est plus de zone 1 que de zone 2.
Pour les jeux ca vient. On a deja SDL qui permet de faire pas mal de choses. Maintenant pour ce qui est de la flexibilite et de la rapidite il faut tout d'abord se debarrasser de cette salete de XLib (On s'y emploit avec XCB) et ensuite il faut des drivers valables pour les cartes graphiques (Ca commence a arriver.)
Ceci etant le jeu n'etait pas l'objectif principal de Linux, mais les applications pros (Notamment Maya) devrait nous ramener des drivers magnifiques au fur et a mesure que les utilisateurs abandonnent les stations SGI bas de gamme. Bref on devrait rattraper Windows en qualite de jeux video d'ici deux ans (oui tout ca et oui seulement).
Le Gros probleme des E-Book est que c'est un standard ferme. Bien que base exclusivement sur PDF il est interdit de fabrqiuer des decodeurs libres ou d'afficher les E-Book sur du materiel qui n'est pas officiellement authorise par Adobe. De fait comme le standard est un flop total (normal pour un livre exclusivement digital qu'on ne peut ni preter ni lire a haute voix). Cependant avec les PDAs sous Windows il y a des lecteurs capables entre autre de lire ce genre de format.
Entierement d'accord, ma console favorite a moi c'est Xterm, mais si il faut parler que de console physiques je pense que je prefere un bon NCD, quoi que je ne cracherait pas sur un VT520.
Personellemt je suis encore sous le charme de Kate Beckinsale, absolument sublime dans ce film. Par contre effectivement une fois que l'on passe le cap des images (et encore pas toutes et il faut aimer les tons bleus) le film perd ennormement de son interet. L'ambition etait de faire rentrer dans 1h45 une guerre millenaire, un amour impossible, une double trahison, une double chasse a l'homme, des effets speciaux et des complots a rebondissements multiples. Resultat : un fouilli sans grand interet. On ne se passionne vraiment pour rien et la "grandeur" des personnages est eclipsee.
Ben pour etre franc lors de mes incursions dans le monde du kernel beta (2.5.7x puis 2.6testx) j'ai crashe (ma faute je precise, j'essayais de refaire le bridge ide-scsi) plusieurs centainnes de fois. Et sincerement j'ai ete vraiment surpris de la solidite du ReiserFS compare a celle de l'ext3. En ce qui concerne les transfers foireux (genre le transfers commence puis part en vrille parceque le drivers CD plante) et les reboot a chaud le ReiserFS a encaisse vraiment mieux que l'ext3.
Mes bons c'est mon experience perso et ca ne traduit en aucun cas une etude statistique digne de ce nom. Mais moi maintenant c'est Reiser.
[^] # Re: limitations de TCG par rapport aux softs libres
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Kha
[^] # Re: limitations de TCG par rapport aux softs libres
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.
presque le checksum de l'init de l'OS loader. Bien sur si c'est lilo en multiboot il est bien avance.
tout autre OS ne peut donc pas y accéder, ce qui est inquiétant pour les OS alternatifs !
Pas du tout, ces clefs sont de toute facon migrables vers une autre zone par l'admin de la puce. Si tu as besoin de sortir une clef d'une zone de boot tu peux declencher sa migration soit vers une autre zone de boot soit vers une zone non lie a une sequence de boot. C'est un peu fastidieux mais ca se fait tres bien.
Alors que aujourd'hui, avec des softs libres et sans matos TCG, il est tout à fait possible d'utiliser des algos de crypto mieux considérés + fiables que le RSA de TCG (AES ou des algos symmétriques car pour cet usage précis on a pas besoin de crypto assymétrique) et des clés de taille supérieure ( limitation de taille de l'ordre de 1024 bits dans TCG) pour interdire à quelqu'un de booter sur ta machine et d'accéder à tes données s'il n'a pas ta clé (cela lui interdit aussi d'accéder aux données s'il emporte ton disque dur)
Si il est deja possible de faire meiux et plus fiable de facon logicielle je ne vois pas ce que tu reproches a TCPA. Si ca n'apporte vraiment qu'une protection inferieure a ce qu'il est deja possible de faire logiciellement alors pourquoi es-tu aussi remonte ?
Kha
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
si les périphériques USB (aujourd'hui majoritaires) ne sont pas encore pris en compte par TCG, cela ne fait que simplifier la base de données des checksums des OS et matériels qui permettront d'identifier ta plateforme
Certes, peut etre meme que comme ca on arrivera a trouver assez de molecules dans l'univers pour stocker toutes les possibilites. Par contre ca ne servira a rien vu que comme les periphs seront rajouter apres rien ne garantie l'integrite de la protection.
De toutes façons les périphériques USB non encore pris en compte permettront uniquement de copier des fichiers audio/video...
Ah bon ? tu peux m'expliquer ce qui va m'empecher de sortir un doccument different ? Si le systeme est persuades d'etre en mode full DRM alors qu'il ne l'est pas qu'est ce qui m'empeche de copier un fichier dans une zone qu'il considere comme legale ? Dans le pire des cas je epux toujours sortir mon doccument comme un compose audio ou video.
c'est surtout la possibilité d'identifier un OS pour interdire à des OS alternatifs d'accéder à certains contenus ou certains programmes
Soit rassure, TCPA ne permet absolument pas de faire ca (a moins bien sur que la personne qui a installe ton serveur d'identification soit egalement ton fabriquant et ton fournisseur de contenu et ton certificateur). Je te renvois encore une fois a mon post plus haut.
Kha
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.
1 TCPA ne fourni jamais les checksums ! Il fournit une clef publique basee sur le checksum dans une certaine mesure. Impossible donc a moins d'avoir une connaissance parfaite du contenu de la puce de retrouver le checksum. Sauf dans le cas hyper particulier de l'identifiant on se retrouvera a chaque fois avec un facteur aleatoire qui viendra mettre le bazar. Seul la generation en parallele de clefs privees rigoureusement identiques permet de casser ce facteur aleatoire et d'avoir acces aux donnees decryptes. De plus meme les clefs basees sur un hashage d'authentification seront toutes impactes par l'ensemble ID fabriquant/Nombre Aleatoire dans le cas de demandes de checksums authentifies. Et donc pour obtenir le checksum il faut avant tout posseder les deux autres infos et je dit bien posseder car la puce ne les laissera sortir que si il y a une operation physique effectuee par le fabriquant sur la puce elle-meme. En ce qui concerne laisser sortir une info seule de la puce c'est absurde, tous les hashages sont identiques d'une puce a l'autre mais les clefs publiques et les clefs privees qui en resultent (et qui sont les seules a sortir de la puce "facilement") sont impactes par un facteur aleatoire. Si ce facteur est regenere a chaque fois (ce qui est le cas pour toutes les operation sauf authentification certifie par une tierce personne) il est impossible de casser la clef publique (a moins de pouvoir aller lire le facteur aleatoire sur la puce ou d'avoir beaucoup de temps a perdre).
Deux hashages successifs des memes parametres de la meme sequence de boot donneront deux clefs privees differents.
2. Eh bien premierement le fait que ce soit techniquement une architecture fermee qui ne fonctionne que par challenge-response. Il faudrait donc que l'emulateur logiciel soit capable d'emuler parfaitement le comportement d'une puce TCPA pour pouvoir donner des reponses coherentes aux differents challenges, or la puce TCPA a ete construite pour rendre ce genre de chose tres difficile. Deuxiemement uen fois de plus on obtient pas le checksum mais une clef publique. Impossible donc de juste recuperer un a un tous les checksums possibles et de faire des melanges. On peut eventuellement essayer de s'amuser a generer toutes les clefs privees possibles liees a un checksum donnees et puis les essayer une a une sur la clef publique renvoye par l'utilisateur, apres tout il n'y en a que quelques millions. A mon sens recreer une puce TCPA avec le meme coupe ID Fournisseur/NA est quand meme beaucoup plus rapide.
Pour finir je ne vois pas ce que les softs viennent faire la dedans. TCPA est totalement incapables de faire le checksum d'un ou plusieurs softs.
Kha
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
1) Avec chaque nouveau hashage il faut un reboot, la puce TCPA ne faisant des hashages que lors du boot.
2) les peripheriques branchees a chaud ne sont donc pas detectables par TCPA, une carte son USB ou PCMCIA, un periph video FireWire ne sont donc pas detectable par la puce si ils sont ajoutes apres le boot, la seule solution possible pour eviter uen copie par ce genre de periphs avec TCPA et de demander a ce que le bus correspondant soit desactive.
Kha
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.
L'utilisateur etant le maillon le plus faible de la chaine c'est a lui qu'il faut fournir des outils pour renforcer ce maillon
Il y a un excellent exemple au sujet des mots de passe plus haut je vais le reprendre.
Si un utilisateur a un mot de passe "faible" il se fera casser en quelques minutes (via une attaque par dictionnaire sur le fichier de mot de passe par exemple). Par contre si le mot de passe est crypte dans la puce alors pas moyen de faire une attaque sur le fichier de mot de passe (qui n'existe plus). Et la puce ne reagit que par challenge/response donc le mot de passe ne sort plus (sauf intervention de l'admin de la puce).
Derniere chose imagine un key logger qui tourne, tu recupere le mot de passe d'un mec a distance, tu essayes de te connecter a distance et tu rentres le mot de passe. Et paf ca ne marche pas, la puce refuse de laisser sortir cette identifiant la pour une session ouverte a distance par un ordinateur non connu.
C'est ce genre de choses que TCPA permet de faire, c'est vrai rien de plus et rien de moins que ce que l'on peut faire avec des logiciels libres si ce n'est le cote coffre-fort de donnees auquel aucun acces brut n'est possible (sauf a l'admin de la puce.).
N.B : Par acces brut j'entend un acces au fichier dans sa forme cryptee ou un acces raw au device qui contient les donnees cryptees.
Kha
[^] # Re: TCPA/TCG n'empeche pas linux mais peut le marginaliser
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Il est quand meme bon de se rapeller que dans le trusted computing le moteur c'est IBM, et qu'il a investit des miliards dans Linux.
Pour ce qui est de l'identification DRM je te renvoi a ce post
https://linuxfr.org/comments/280544.html(...)
Kha
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 3.
La puce TCPA contient un emplacement special qui n'est considere ni comme une zone d'archivage privee ni comme une zone d'archivage publique. C'est une zone ID de laquelle la clef ne peut sortir que dans des circonstances extraordinaires (il faut faire venir le constructeur de la machine).
Cette zone contient optionellement (pour l'instant : jamais) une clef fabriquant OU une clef fournisseur. Cette clef et techniquement irrecuperable et elle est la meme sur toute une gamme de produit. Cette zone contient aussi un nombre genere aleatoirement et sauvegarde.
Pour obtenir un certificat d'identification il te faut d'abord une demande de hashage pour savoir ce que tu vas faire rentrer dans ton identifiant (cela peut-etre seulement la clef+le nombre aleatoire mais tu peux aussi rajouter ta carte video, ton bios, ta carte son etc.. )
Le systeme fonctionne comme suit : tu te connecte a un fournisseur de certificat et tu lui envoit la clee publique de ton hashage. Celui-ci se connecte alors a ton fournisseur de contenu et lui renvoit alors une clef publique certifiant que tu as bien une puce TCPA. Ton fournisseur de contenu fait ensuite une demande une demande de clef symetrique pour lui et toi et le certicateur vous fourni a tous les deux cette clef symetrique. Ton fournisseur de contenu et toi dialoguez ensuite en utilisant cette clef.
Cela est extrememnt securise et tres respectueux de la vie privee. Neamoins etudions le pire cas possible.
Pour que ton fournisseur puisse reellement t'identifie et savoir de quel materiel tu te sert il faut d'abord qu'il te demande un hashage ID pur (ie ta clef ID constructeur+nombre aleatoire). Pour pouvoir casser cette clef et connaitre le contenu du nombre aleatoire il faut qu'il possede ta clef constructeur (et donc qu'il soit le fabriquant de ta machine ou alors severement de meche avec lui). De plus le nombre aleatoire etant par essence aleatoire il ne faut pas qu'il se trompe de clef non plus, sinon il reccuperera un nombre d'apparence correcte mais faux. Il faut donc aussi qu'il soit celui qui t'ai fourni ton appareil et qu'il est pris soin de noter ta clef auparavent.
Finalement pour recevoir ta clef lors de la demande d'identification il faut finalement que ce soit egalement lui qui fasse office de certificateur (sans quoi il ne recevra que la clef symetrique certifie pour le dialogue).
Donc oui si ton constructeur est ton fournisseur et est aussi ton certificateur alors il eput recuperer la partie aleatoir de ton identifiant unique par recoupements.
Bon, comme le pire peut toujours arriver admettons que ce soit le cas. Cette personne peut desormais identifie ta puce (et rien de plus) par demande d'un hashage ID pur.
Mais si elle veut faire jouer DRM ce qui l'interesse c'est de savoir quel tpe d'OS tu utilises, quel type de materiel tu utilise etc.
Pour identifier ta carte son par exemple voici la methode.
1) recuperer le nombre aleatoire de l'ID par la methode ci dessus
2) demander une serie de hashages ID+nombre aleatoire+periph PCIx (avec x entre 0 et 6)
3) Creer une PC a l'identique du tien en mettant en place le meme ID constructeur et le meme nombre aleatoire que dans ta propre puce (il peut le faire vu qu'il est aussi ton constructeur dans ce scenario super catastrophe).
4) Pour toutes les cartes sons compatibles DRM creer un hashage ID+NA+PCIy (avec y = position de la carte son)
5) Pour toutes les cartes son non DRM creer un hashage ID+NA+PCIz (avec z position de la carte son)
6) Verifier que dans la serie de hashage demandes a l'utilisateur en 2) si il y a bien un hashage identique a 4) et aucun hashage identique a 5).
7) Se rejouir en se disant qu'il ne reste plus qu'a verifier les autres periphs
Dans le pire scenario possible, en donnant acces a tout un tas d'autres informations a ton fournisseur de contenu ca reste quand meme vraiment penible de faire du DRM non ? (Bien sur au moindre flashage de bios d'un des periphs le hashage change aussi).
Par contre comme tu peux le constater il y a intervention d'une tierce partie qui sert de certificateur, ce qui a soi seul justifie que les algorithmes de verif ne soient pas disperses dans la nature. Mais rien n'interdit de voir un jour un serveur de certification etre mis en place par un organisme du libre.
Kha
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 10.
Je m'explique : dans un monde dans lequel 1) le marche serait dans un etat sain (ie liberte totale de choix entre plusieurs produits et connaissances de l'ensembe des produits) 2) les acheteurs auraient conscience des risques lies a la divulgation d'information personelle ta theorie deviendrait realite.
Malheureusement avec une ennorme partie du marche deja acquise a Microsoft et des gens persuades que l'on ne peut craindre d'etre fiche que si l'on a quelque chose a se repprocher ca ne marche pas du tout. Le consomateur aura le sentiment de "perdre" quelque chose. Par exemple si les technologies DRM ou la lecture de certains types de doccuments deviennent impossibles sous une alternative alors le consomateur sera frustre.
De plus comme on est en situation de monopole les fournisseurs de service payant necessitant l'utilisation de technologie DRM ne verront pas l'interet de faire d'effort. Il suffit de voir a quel point il est dur de faire changer une page web pour qu'elle devienne lisible par tous les navigatuers lorsque l'on est une minorite. Et encore dans ce cas la on a la norme de notre cote, la mise en place d'une nouvelle page est souvent triviale (rendre un site lisible ne requiert que rarement plus de 1semaine/h) et le service propose par le site reste identique.
Dernier point dans le cas du secure computing (a ne pas confondre avec le trusted de TCPA) on se retrouve dans ce qui s'apelle un trust horizontal. Microsoft controllant la norme (et donc le materiel qui respecte ou non la norme) les logiciels permettant de creer les doccuments de confiance, les logiciels pour les distribuer et les logiciels pour les visualiser. Ce type de trust est le plus dangereux (beaucoup plus qu'un monopole fut-il planetaire) et la loi americaine vise plus particulierement ce genre de situation.
Bref non c'est pas que du bon.
Kha
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à -1.
Par contre
1) tu m'as grille
2) Felicitation pour ta nouvelle orthographe.
Kha
# Re: TCPA/Palladium continuent d'avancer
Posté par Jerome Herman . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 7.
TCPA permet exclusivement a un utilisateur de mettre des clefs et des informations dans la puce. C'est l'utilisateur qui possede les droits sur la machine qui choisit ce qui est securise par la puce ou non, et c'est aussi lui qui choisi dans quelles conditions cela ce fait. Une personne qui a les dorits sur la puce peut faire ressortir de la puce n'importequelle clef qui y est rentre (ie qui n'a pas ete generee par la puce elle meme). TCPA est donc tres difficielment utilisable a des fins restrictive telle que le controle de license, l'invalidation de doccument ou de programmes et bien sur le DRM
A l'inverse Ex-Palladium ne laisse aucun choix a l'utilisateur. Il divise l'ordinateur en deux zones completements disjointes (tout du moins c'est le but). D'un cote les programmes certifies tourant sur du materiel certifie de l'autre les programmes inconnus et le materiel douteux. De plus le systemes se reserve le droit d'invalider les programmes ou les doccuments au bout d'un certain temps si la license n'a pas ete renouvelle aupres d'un serveur de confiance (ideal pour le DRM). Ce dernierpoint etant d'ailleurs a rapprocher de la derniere declaration du chef de la securite de MS qui annonce un systeme de mise a jour et d'installation automatqiue des updates de securite.
Pour l'instant meme apres avoir epluche les docs TCPA deux cents fois je ne vois pas ce qu'il y a de mal dans cette puce (et je suis un parano de premiere). Par contre je me mefie comme de la peste de la solution Microsoft.
On verra la suite
Kha
[^] # Re: Office 2003 - XML Propriétaire ???
Posté par Jerome Herman . En réponse au journal Office 2003 n'a pas la côte. Évalué à 1.
Kha
[^] # Re: Projet de vente de machines sous Linux
Posté par Jerome Herman . En réponse au journal Projet de vente de machines sous Linux. Évalué à 2.
1) Quelles vont etre tes quantites d'achat initiales, es-tu sur de pouvoir retrouver exactement les memes produits si la demande suit ? As-tu au moins un developpeur dans ton equipe (absolument necessaire sous Linux pour adapter certains drivers ou mettre ne place certain patch kernel).
2) Quelle est la garantie de base ? Es-tu considere comem revendeur par tes fournisseur ou dois-tu faire appel a une tierce personne en cas de retour de materiel, as-tu teste la compatibilite des produits ?
3) Si une personne ne veut pas de la Mandrake que se passe-t-il ? Peux-tu faire des install personalisees ? Es-tu capable de fournir 10 , 100, 1000 machines rigoureusement identique a une collectivite ou a une entreprise ? Peux-tu gerer un paiement a 30 jours ? 60 jours ? 90 jours ? Mettre en place un serveur de facon exceptionelle chez un client pour gerer tout un parc de tes propres machines ?
4) La carte graphique n'est pas mentionnee, quid ? Est-elle fournie a la demande ? Fournie suivant les stocks ?
5) IIYAMA est devenu issuportable pour le SAV prend du Viewsonic si tu peux, ici on se bat avec eux jours et nuits et on a un peu plus de 4000 ecrans, donc si on ne trouve pas d emoyen de leur mettre la pression, toi tu risques de ne meme pas avoir de reponses.
C'est tout ce a quoi je peux penser pour l'instant.
Bonne chance a toi
Kha
[^] # Re: Emulation ide-scsi
Posté par Jerome Herman . En réponse au journal Emulation ide-scsi. Évalué à 2.
Kha
# Re: Office 2003 n'a pas la côte
Posté par Jerome Herman . En réponse au journal Office 2003 n'a pas la côte. Évalué à 8.
Et puis apres ben tu es oblige de mettre du 2003 partout parceque maintenir 2 versions d'Office differentes c'est complexe, parceque le service d'a cote est jaloux, parceque Mr Michu il peut pas relire le travail qu'il a fait chez lui a la maison.
C'est ce qui s'est passe entre word 2 et word 3, idem 3->95 et 95->97. 2000 et XP etait compatibles avec 97 (enfin presque) alors l'upgrade etait pas obligatoire. Bon les utilisateurs forcenes d'excel sont passe en 2000 parcequ'il fallait reussir a gerer plus de 255 types de mise en forme differentes mais c'est tout.
Mais la avec le format XML2003 de chez MS j'ai peur.
Kha
# Re: Linux est un grand environnement pour les bricoleurs
Posté par Jerome Herman . En réponse au journal Linux est un grand environnement pour les bricoleurs. Évalué à 2.
TOI MEME
C'est pueril mais ca fait du bien
Kha
# Re: Iliad, tu pousses le bouchon un peu loin ...
Posté par Jerome Herman . En réponse au journal Iliad, tu pousses le bouchon un peu loin .... Évalué à 2.
Je propose donc de les y aider un grand coup en mettant une declaration de metas-keywords sur toutes les pages qui ressemble de pres ou de loin a une liste de trucs.
donc allons-y
meta NAME="keywords" CONTENT="annu, annuaire, annus, annuaires"
meta NAME="description" CONTENT="Annuaire de ..."
Et bon apetit les gens
Kha
[^] # Re: L'art et la maniere de demander de l'aide
Posté par Jerome Herman . En réponse au journal L'art et la maniere de demander de l'aide. Évalué à 1.
Voila
Kha
# Re: Lire des DVD sur son ordinateur
Posté par Jerome Herman . En réponse au journal Lire des DVD sur son ordinateur. Évalué à 5.
Pour les jeux ca vient. On a deja SDL qui permet de faire pas mal de choses. Maintenant pour ce qui est de la flexibilite et de la rapidite il faut tout d'abord se debarrasser de cette salete de XLib (On s'y emploit avec XCB) et ensuite il faut des drivers valables pour les cartes graphiques (Ca commence a arriver.)
Ceci etant le jeu n'etait pas l'objectif principal de Linux, mais les applications pros (Notamment Maya) devrait nous ramener des drivers magnifiques au fur et a mesure que les utilisateurs abandonnent les stations SGI bas de gamme. Bref on devrait rattraper Windows en qualite de jeux video d'ici deux ans (oui tout ca et oui seulement).
Kha
# Re: E-Bookz
Posté par Jerome Herman . En réponse au journal E-Bookz. Évalué à 2.
Mias c'est du proprio ad-vitam eternam .
Kha
# Re: Du nouveau de Pierre Breese
Posté par Jerome Herman . En réponse au journal Du nouveau de Pierre Breese. Évalué à 2.
Pour la premiere fois de ma vie je viens d eme fendre d'un commentaire sur ZD.
Kha
[^] # Re: Ma console préférée
Posté par Jerome Herman . En réponse au sondage Ma console préférée. Évalué à 2.
Kha
# Re: Underworld
Posté par Jerome Herman . En réponse à la dépêche Underworld. Évalué à 3.
Kha
# Re: Pourquoi c'est vert ?
Posté par Jerome Herman . En réponse au journal Pourquoi c'est vert ?. Évalué à 0.
Kha
[^] # Re: root directory is not a directory. Clean [y]
Posté par Jerome Herman . En réponse au journal root directory is not a directory. Clean [y]. Évalué à 2.
Mes bons c'est mon experience perso et ca ne traduit en aucun cas une etude statistique digne de ce nom. Mais moi maintenant c'est Reiser.
Kha