J'avais décidé de ne plus utiliser mon téléphone et surtout pas mon mobile qui peut fournir ma position en continu. J'avais banni les cartes de fidélité des supermarchés qui permettaient de collecter les informations sur mes goûts et de les revendre. J'évitais de même les sondages divers commerciaux. Je me disais qu'en payant en liquide (avec un risque de contrefaçon sur les billets certes) et en n'utilisant pas de pass dans le métro, je préserverais un peu de ma liberté. Poussant le raisonnement au bout, j'avais décidé d'organiser régulièrement des brèves rencontres avec des inconnus pour mettre dans un pot commun mes billets et mes tickets de métro, les mélanger et repartir ainsi avec des numéros de série anonymisés, par peur d'être suivi, et puis cela me permettait d'échanger des empreintes GnuPG.
Bien sûr j'utilisais des logiciels libres, car pourquoi ferais-je confiance à des logiciels propriétaires boîtes noires, contenant potentiellement des portes dérobées ou des espiogiciels. Je ne communiquais qu'en https, mes courriels étaient tous chiffrés, mes partitions aussi, et de toute façon mes remarques sur la météo et le sexe opposé ne circulaient que dans des images de gnous en utilisant de la stéganographie. Et je me croyais tranquille.
C'était sans compter sur le déploiement de nouveaux ordinateurs équipés en standard de TPM (oui l'informatique dite « de confiance », TCPA/Palladium, ayez confiance, tout ça) qui étaient déjà sur le marché. Et les imprimantes qui se mettaient à bavasser aussi. Sans compter aussi que certains aimeraient bien collecter toutes les données de trafic internet et téléphonique (le courrier postal n'intéresse personne...), en évoquant des questions de sécurité, voire créer des e-milices sur les réseaux (de toute façon on me proposait déjà de confier mes clés de chiffrement aux forces de police, sachant qu'ils savaient s'en passer si besoin). Ceci dit les débats sur la nouvelle carte d'identité électronique en France avaient laissé perplexe (identifiant unique, données biométriques, mélange de l'officiel et du commercial, etc.).
De son côté l'industrie de la musique et du cinéma promettait des mesures techniques de protection pour décider si et quand et combien de fois je pourrais lire le DVD que j'avais acheté, et avec quel matériel et quel logiciel, en arguant des cataclysmes apocalyptiques et tentaculaires causés par des lycéens de 12 ans ; on me promettait même des identifiants uniques sur chaque disque et un blocage de la copie privée pourtant légale. Finalement on me proposait de bénéficier des puces d'identification par radio-fréquences RFID aux usages multiples : traçage des étrangers, contrôle des papiers d'identité, implantation sous-cutanée...
Bah il ne me restait plus qu'à aller poser devant les caméras dans la rue (Paris, Londres, etc.), et à reprendre des pilules. Enfin ça ou essayer d'améliorer les choses.
« Nous avons neuf mois de vie privée avant de naître, ça devrait nous suffire. » (Heathcote Williams)
« Même les paranoïaques ont des ennemis. » (Albert Einstein)
Du respect de la vie privée et secrète du geek en milieu urbain
18
août
2005
# On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 8.
La Grande (La surcouche d'Intel) c'est nettement moins sur. Et si La Grande est dangereux, l'implémentation du Trusted Computing complet par Microsoft a de bonnes chances d'être une horreur.
Mais la puce TPM est une belle invention, partique, utile, sure et fiable.
[^] # Re: On va se répéter uen dernière fois
Posté par Gniarf . Évalué à 1.
[^] # Re: On va se répéter uen dernière fois
Posté par briaeros007 . Évalué à 8.
tu dis ; as tu une preuve de securite de ta puce ? non donc ce n'est pas sur. on ne sais pas comment ils sortent leurs numeros aleatoires (vrai aleas ???) , on ne sait pas comment ils protegent leurs contenus. on ne sait pas si il y a pas un mode superutilisateur qui permet de recuperer les cles etc ...
Donc le sure et fiable me semble premature (a moins que tu ais acces au vhdl ?)
Si c'etait effectivement sur oui ca serait bien ; mais bon une puce qui sert de base a des techniques liberticides je ne lui accorde pas le benefice du doute .
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 4.
En ce qui concerne la norme, on a un degré de sécurité difficilement égalable. La clef privée étant inaccessible et ne pouvant être déplacée que par des manoeuvres longues et complexes et seulement à destination d'un autre TPM.
Les contenus "sesnibles" sont protégéspar non accès extérieur. Pour lire uen clef directement, il faut ouvrir la puce et venir ce brancher sur les bus interne. C'est nettement plus compelxe que de percer un coffre fort.
Chaque "coffre" à clef (PCR) fait des mesures de huits points de matériels et du pré-boot pour générer la clef d'authentification. Même si la qualité de l'algo est faible, une suite de MD5 octuple imbriqués reste très difficile à casser. Donc même si la clef elle même est généré par un aléa douteux, la falsification d'une puce rsique d'être très complexe.
mais bon une puce qui sert de base a des techniques liberticides je ne lui accorde pas le benefice du doute .
C'ets justement le truc. La puce TPM ne sert absolument pas de base aux techniques liberticides. Seulement comme il est assez difficile de vendre un produit qui n'a d'autre utilité que de fliquer son utilisateur, on rajoute la puce à coté pour faire un bundle "attractif".
Il n'y a aucun rapport entre la puce TPM et (par exemple) les canaux sécurisés de La Grande. Le fait que La Grande utilise la puce TPM pour stoquer ses clefs est un plus, mais absolument pas une nécessité. Si un site web décide de stoquer ses clefs dans la puce TPM ca ne ferait pas de la puce un tueur d'internet non plus.
[^] # Re: On va se répéter une dernière fois
Posté par briaeros007 . Évalué à 4.
Ca c'est toi qui le dis .
Le but du vhdl c'est d'en etre sur. Voir l'exemple des puces motorola dans mon message plus bas.
Il n'y a aucun rapport entre la puce TPM et (par exemple) les canaux sécurisés de La Grande. Le fait que La Grande utilise la puce TPM pour stoquer ses clefs est un plus, mais absolument pas une nécessité
Tu dis qu'il n'y a pas de rapport ensuite tu dis qu'il y en a un...
C'est pas une necessite mais c'est ce qui va se passer. Et donc je veux etre sur que mes cles soient bien en secu c'est legitime non?
Je n 'ai rien contre le principe de la puce tpm . Mais je m'extasie pas devant une nouvelle techno parceque c'est une nouvelle techno.
Les exemples de puces cryptographiques "rate" sont plutot frequent.
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 1.
C'est dans el sens ou la puce TPM, bien qu'utilisé par Lagrande n'apporte rien du tout à la méccanique des systèmes de canaux cryptés. (A la limite ils apporteraient plutot une faille, vu que les clefs TPM challengeables sont exportables et qu'on pourrait peut-être "écouter le contenu d'un canal avec une autre puce TPM branchée en parallèle").
Tout le méccanisme de protection (ségementation hardware, test actifs, isolation, bloquages etc.) sont fait par du hardware dédié.
Et donc je veux etre sur que mes cles soient bien en secu c'est legitime non?
Pour tes clefs privées tu as le choix entre deux options : En clair sur ton ordinateur (même si c'est pour des temps très bref) ou enfermés dans uen puce coffre fort dans laquelle elle est née et d'ou elle ne peut théoriquement (et c'est pour la certitude qu'il faudrait le VHDL nous sommes d'accord) pas sortir sauf intervention lourde nécessitant une présence physique sur la machine.
L'existence d'une backdoor permettant la récupération de l'ensemble des clefs contenues dans une puce (et à distance de préférence) ets une pure hypothèse (même si on a déjà vu les américains forcer els constructeurs à ce genre de choses). Ceci étant comparé à "en clair sur le disque dur" (ou la clef USB) je ne peux m'empécher de penser qu'il y a un progrès.
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 3.
Pas d'accord. La spec TPM encourage les constructeurs à implémenter une API pour transférer le contenu d'un TPM vers un autre (TPM_CreateMaintenanceArchive, TPM_LoadMaintenanceArchive). Il y a un baratin pas du tout crédible qui dit que le constructeur déchiffre l'archive, mais à moitié seulement, grâce à un XOR miraculeux. D'ailleurs ce pipeau est dans un "informative comment", pas dans la partie normative.
Si ça ne suffit pas, il y a aussi un mécanisme optionnel qui permet au constructeur d'upgrader le firmware du TPM (Field Upgrade). Est-il besoin d'en dire plus ?
Tout ça est dans https://www.trustedcomputinggroup.org/downloads/tpmwg-mainrev62_Part(...) section 13 pour ceux qui ont le temps de se faire une opinion par eux-mêmes.
Ces fonctions sont optionnelles, et leur présence aura évidemment un impact sur les profils Critères Communs auxquels un TPM pourra prétendre. On peut se douter que les militaires n'auront pas les mêmes TPMs que le grand public (si tant est que les militaires choisissent d'utiliser TCPA).
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 4.
Une archive ne peut être créé qu'entre deux puces TCPA, et elle doit être préparé à l'avance par le owner de la puce. Le transfer se fait de la façon suivante :
Les duex TCPA se reconnaissent comme TCPA, le owner du TCPA à migrer certifie le TCPA migrateur dans son TCPA. Les deux TCPA ouvrent un canal sécurisé pour se mettre d'accord sur une clef synchro. Finalement le TCPA à migrer envoit sa base de maintenance au TCPA recepteur en prenant soin de la passer d'abord via une moulinette XOR avec la clef synchor choisit précédamment. C'est on ne peut plus classique. Quand à permettre la manip à distance par un non owner (ie uen vraie backdoor) on en est très loin.
Quand à l'upgrade firmware, ca n'est pas plus inquiétant que le reste. Vu qu'il n'y a pas de méccanisme pour forcer l'upgrade. De plus à moins que la norme ne change, il faudrait que la mise à jour casse sérieusement la compatibilité avec la norme pour devenir dangereux.
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 4.
Et le TPM1 vérifie que le certificat du TPM2 est bien signé par le constructeur ? Et il télécharge tout seul des CRL pour vérifier qu'il n'est pas révoqué ?
En fait je suppose il fait entièrement confiance au Owner, comme tu le suggères. Dès lors il est possible de migrer vers un TPM2 bidon.
Quant à l'autorisation du Owner et à la moulinette XOR, elles sont protégées au mieux par le secret symmétrique de 160 bits, que l'on peut forcément sniffer avec une backdoor dans l'OS ou le BIOS. Donc le tour est joué, y compris à distance. A moins de mettre ce secret et tous les algos qui l'utilisent dans un autre module "de confiance" (une carte à puce, par exemple).
La simple existence de cette fonction de maintenance est en contradiction avec le principe de base d'un token crypto: même le propriétaire ne devrait jamais pouvoir extraire les clés. D'ailleurs il y a une commande TPM_KillMaintenanceFeature pour la désactiver, mais j'imagine déjà le dialogue dans le TPM Wizard: "Attention, en désactivant cette fonction, vous risquez de perdre irrémédiablement vos clés, et d'être en infraction avec l'article 434-15-2 du Code Pénal relatif au recouvrement des conventions de chiffrement. Voulez-vous vraiment continuer ?"
Merci pour tes clarifications techniques, mais je ne suis toujours pas rassuré.
P.S. Quant à l'upgrade firmware, il s'agit peut être seulement d'allonger l'access-list des opérations soumises à autorisation du Owner (protected capbilities).
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 2.
Rien à voir du tout, Les certificats, EK et autres n'interviennent pas du tout dans les migrations de clefs et les transmissions pour maintenance. Tu mets deux puces face à face et c'est le owner qui décide tout seul comme un grand d'authoriser le TCPA emmetteur à faire le transfert.
Quant à l'autorisation du Owner et à la moulinette XOR, elles sont protégées au mieux par le secret symmétrique de 160 bits, que l'on peut forcément sniffer avec une backdoor dans l'OS ou le BIOS. Donc le tour est joué, y compris à distance. A moins de mettre ce secret et tous les algos qui l'utilisent dans un autre module "de confiance" (une carte à puce, par exemple).
Casser une clef symétrique 160 bits en sniffant des emissions "incohérentes" (Les couples clefs publiques/cles privées c'est aps comem un fichier texte, il y a grosso-modo la même proportion de chaque chiffre)
La simple existence de cette fonction de maintenance est en contradiction avec le principe de base d'un token crypto: même le propriétaire ne devrait jamais pouvoir extraire les clés.
Comme tu le dis, si tu veux tu peux désactiver la fonction. Par contre l'idée de pouvoir migrer/copier mes clefs d'un TCPA à l'autre me plait :
a) Parceque des fois j'aurais peut-être envie de changer de puce/machien sans pour autant changer de certificats
b) parceque des fois je veux bien avoir un certificat TCPA load-balancé sur deux machines
c) parceque tant que cette fonction sera présente l'idée même du DRM sera risible
"Attention, en désactivant cette fonction, vous risquez de perdre irrémédiablement vos clés, et d'être en infraction avec l'article 434-15-2 du Code Pénal relatif au recouvrement des conventions de chiffrement. Voulez-vous vraiment continuer ?"
Si je veux détruire mes clefs, je refais une prise de controle du ownership du TCPA. C'est plus rapide et plus efficace
Quant à l'upgrade firmware, il s'agit peut être seulement d'allonger l'access-list des opérations soumises à autorisation du Owner (protected capbilities).
Ca pourrait, mais ca rentre dans le cadre de ce que j'apelle "grave déviation par rapport à la norme"
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 2.
Non, ça c'est la procédure de Backup/Migration, je suppose.
Je parle de la procédure de Maintenance (section 13 de la spec), qui n'est réalisable qu'avec l'assistance du constructeur, et qui permet de transférer même les données marquées comme "non migrables".
Il n'y a rien à casser. On parle de backdoors et d'attaques avec la complicité du constructeur de TPM et du fournisseur de l'OS, dans le but d'extraire des clés que l'utilisateur croyait à l'abri dans ton TPM. Il suffit d'intercepter le secret lorsque l'utilisateur saisit sa passphrase pour autoriser une opération protégée quelconque.
Là tu donnes de faux espoirs à certains.
Avec les procédures de Backup/Migration, l'utilisateur ne peut transférer que les clés marquées comme migrables (donc probablement pas les clés de DRM).
Les clés non migrables ne sont transférables que par le SAV du constructeur (procédure de Maintenance).
Le problème n'est pas de savoir détruire les clés (il y a le marteau pour ça), mais de continuer à les utiliser en sachant si elles sont réellement à l'abri.
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 3.
Je parle de la procédure de Maintenance (section 13 de la spec), qui n'est réalisable qu'avec l'assistance du constructeur, et qui permet de transférer même les données marquées comme "non migrables".
Il n'y a pas grand intéret à faire un backup des clefs non migrables. Ce sont les clefs interne à la puce et elles sont inaccessibles par l'extérieur. La procédure de maintenance complète n'est utile que dans le cas ou l'on veut récupérer aussi l'EK. Mais à part çà l'intéret est à peu près nul.
Il suffit d'intercepter le secret lorsque l'utilisateur saisit sa passphrase pour autoriser une opération protégée quelconque.
Tant bien même on arriverait à attrapper le mot de passe du owner au vol (et là on est très loin des specs TCPA et à fond dans la parano) on ne pourrait toujours pas récupérer les clefs privées de la puce TCPA en clair.
Une fois que la commande qui demande à TPM1 de transférer le package de migration vers TPM2 est lancée, tout se passe en crypté entre TPM1 et TPM2. Le owner n'a en aucun cas la main sur le transfert. La seule façon de récupérer les clefs en clair serait de les migrer (ie secret du owner, préparation d'un package de migration, déclaration du TPM d'acceuil et en option depuis la V2.0 présence physique ) vers un TPM qui permet l'accès aux clefs en clair.
Là tu donnes de faux espoirs à certains.
Avec les procédures de Backup/Migration, l'utilisateur ne peut transférer que les clés marquées comme migrables (donc probablement pas les clés de DRM).
Les clés non migrables ne sont transférables que par le SAV du constructeur (procédure de Maintenance).
Certes mais les clefs non migrables sont à usage interne exclusif. Ce sont les clefs utilisés par la puce TCPA pour se valider elle même et pour crypter les PCR (exception faite de l'EK qui a un status très particulier, et qui ne peut pas être utilisé pour faire du DRM non plus - a moins que le tiers de confiance soit aussi le fournisseur de service) .
Il est très important de comprendre que els clefs non migrables ne sont pas interrogeable par l'extérieur (que ce soit par l'OS, un logiciel quelconque, ou même par le owner de la puce ) et que leur utilisation pour faire du DRM est totalement impossible.
Le problème n'est pas de savoir détruire les clés (il y a le marteau pour ça), mais de continuer à les utiliser en sachant si elles sont réellement à l'abri.
La puce TCPA n'est pas la solution ultime, mais comparée a toutes les autres solutions que j'ai pu voir c'est celle qui offre le plus haut degré de fiabilité. Elle n'est pas nécessairement parfaite, mais comparé à un disque en clair, ou même à une carte à puce qui ne valide pas la plateforme sur laquelle elle est lue, je trouve qu'il y a un vrai gain.
Maintenant il s'agit là de mon opinion, avec laquelle on peut être d'accord ou pas, et je puisse parfaitement comprendre que l'on puisse préférer une solution via carte à puce/signature mémoire/OS sur support non volatile.
Par contre l'amalgame TCPA=DRM=POUBELLE ne passe pas du tout (mais vous l'aviez déjà remarqué)
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 2.
Je doute que la maintenance puisse migrer EK. L'entité qui réalise l'opération est même censée révoquer l'EK de TPM1 et informer les autorités de certification (page 65).
Concernant l'intérêt d'extraire les clés non migrables, ça m'étonnerait beaucoup qu'elles n'aient absolument aucune valeur, mais je ne maitrise pas suffisamment les specs pour argumenter.
La seule façon de récupérer les clefs en clair serait de les migrer (ie secret du owner, préparation d'un package de migration, déclaration du TPM d'acceuil et en option depuis la V2.0 présence physique ) vers un TPM qui permet l'accès aux clefs en clair.
Donc avec la procédure de backup/migration il suffit bien d'intercepter le secret du Owner (même pas besoin de la collaboration du constructeur). Pour ça il suffira d'une backdoor ou d'un bug exploitable dans un OS, même certifié. D'ailleurs c'est comme ça que le boot sécurisé de la Xbox a été contourné.
Pour beaucoup d'applications il vaut mieux perdre la clé en cas de panne matérielle, que de prévoir un mécanisme de backup aussi vulnérable.
Par contre l'amalgame TCPA=DRM=POUBELLE ne passe pas du tout
Je suis d'accord. TCPA pourrait être idéal pour chiffrer son disque, protéger la clé SSL de son serveur web, ou administrer un réseau bureautique d'entreprise.
Le problème est que les exigences du DRM ont une influence très lourde sur la norme TCPA. Pour les trois applications ci-dessus, il n'y a aucune raison d'empêcher le propriétaire du PC de détruire le certificat du constructeur et de gérer EK lui-même (ce qui serait plus satisfaisant du point de vue de la confidentialité et de la vie privée).
Mais si Microsoft et Vivendi se retrouvent face à un parc installé où 10% des clients ont effacé le certificat EK d'origine de leur TPM, ils ne pourront plus faire passer le DRM de façon indolore. C'est pour ça que tu ne peux pas générer EK sur tes chips, et que tu ne pourras pas le changer sur les futurs modèles, à moins de payer ton TPM plus cher (c'est écrit en clair dans les release notes TPM_1_2_Changes_Final.pdf).
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 3.
Oui vu que la clef d'endossement passe alors sur TPM2. ca ne se fait pas d'avoir deux fois le même identifiant unique. Ca serait même plutôt pas bien vu du tout.
ça m'étonnerait beaucoup qu'elles n'aient absolument aucune valeur, mais je ne maitrise pas suffisamment les specs pour argumenter.
Elles ont une ennorme valeur : elles empêchent le forcage des coffres à clefs par tampering. Mais à part çà... Que dalle.
Pour beaucoup d'applications il vaut mieux perdre la clé en cas de panne matérielle, que de prévoir un mécanisme de backup aussi vulnérable.
Certes, mais pour d'autres non. C'est toujours mieux à mon sens d'avori el choix. De plus si on parle de backdoor, et de fonctions non documentés, il ne sert pas à grand chose de gronder contre les fonctions qui sont doncumentés. Rien ne prouve en effet qu'il n'existe pas un moyen caché de sortir la clef, à moins de fondre la puce toi même.
il n'y a aucune raison d'empêcher le propriétaire du PC de détruire le certificat du constructeur et de gérer EK lui-même
Euh... dans une certification trois tiers il faut trois tiers. Si je te certifies être Bill Gates ou RMS ca n'a aucune valeur. Il faut que quelqu'un d'autre te certifie que je suis bien qui je prétend être. C'est exactement le but de l'EK. Donc l'EK ne peut pas être fait par le propriétaire de la puce.
Mais si Microsoft et Vivendi se retrouvent face à un parc installé où 10% des clients ont effacé le certificat EK d'origine de leur TPM, ils ne pourront plus faire passer le DRM de façon indolore
Il est totalement impossible d'utilsier EK pour faire du DRM. EK identifie la puce, quand à savoir si cette puce est sur un PC ou un Mac, si l'OS de la machin est windows, BSD ou Linux, si le lecteur et windowsmédia ou vlc... TPM ne dispose d'aucun moyen de le gérer. Il eput certifier (ou non) que la config est bien identique à la config précédente. C'est tout.
En plus de celà, comme toutes les clefs accessibles de l'extérieur sont copiables et migrables ca n'apporte pas vraiment de garanties de ce coté là non plus.
TCPA et le DRM c'est comme les poissons et les byciclettes, les deux se déplacent, mais ils vont pas vraiment ensemble.
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 1.
Tampering physique ? Ou déchiffrage des blobs externes ? (auquel cas ce serait évidemment très intéressant de savoir extraire ces clés non migrables).
Donc l'EK ne peut pas être fait par le propriétaire de la puce.
C'est pourtant utile lorsque le propriétaire du PC n'est pas l'utilisateur.
Exemple: l'administrateur d'un réseau d'entreprise qui veut contrôler les applis qui tournent sur son réseau.
Il est totalement impossible d'utilsier EK pour faire du DRM
En effet, il faut tout le reste de l'infrastructure, ainsi que des périphériques durcis, et des compétences pour produire des logiciels garantis sans bugs, donc c'est pas demain la veille.
Mais c'est bien EK qui est à la racine de la chaîne de confiance.
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 2.
Tampering physique, les blobs externes sont fabriqués avec des clefs qui agissent avec l'extérieur et qui sont donc migrables (en théorie, parcequ'en pratique elles sont bloquées pendant la migration et détruites après)
C'est pourtant utile lorsque le propriétaire du PC n'est pas l'utilisateur.
Exemple: l'administrateur d'un réseau d'entreprise qui veut contrôler les applis qui tournent sur son réseau.
Dans ce cas c'est très simple, tu créé un profil et tu lui associe divers PCR avec les applications ou groupe d'applications que l'utilisateur a le droit de lancer.
Par exemple, si l'utilisateur appartient au groupe "secretariat" sous linux, tu lui assoice un profil secretariat qui lui ouvre une clef capable de l'authentifier sur le réseau.
Si l'environement de login est modifié, alors l'utilisateur perd sa clef (le PCR se referme) et donc la connection réseau.
Mais c'est bien EK qui est à la racine de la chaîne de confiance.
Manifestement, vu la direction que prend Intel avec La Grande (Elles sont très bien les nouvelles docs de http://www.intel.com/technology/security/(...) ) ca va pas être le cas du tout. C'est l'OS qui va servir de certificat via Lagrande et la double authentification intel qui va faire office de tiers de confiance.
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 3.
tu créé un profil et tu lui associe divers PCR avec les applications ou groupe d'applications que l'utilisateur a le droit de lancer.
Tout le problème est de savoir si cette gestion de profils peut être faite de façon sûre sans EK. A suivre dans l'autre thread
http://linuxfr.org/comments/613763.html#613763(...)
En tout cas merci pour la discussion, j'en profite pour découvrir les specs TCPA, et il n'y a pas grand monde capable de débattre sur les détails techniques.
AC
[^] # Re: On va se répéter une dernière fois
Posté par doublehp (site web personnel) . Évalué à 3.
ce qui signifie qu il est illegale en france de realiser un module cryptographique hardware vraiment secure ?
[^] # Re: On va se répéter une dernière fois
Posté par Gniarf . Évalué à 3.
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 3.
Non, seulement de refuser de déchiffrer. Tu peux probablement répondre à la sommation des autorités en déchiffrant à l'aide de ton module, sans révéler la clé elle-même.
Evidemment, si tu as la même coupe de cheveux qu'un certain terroriste londonien, et que tu racontes que ton module vient de tomber en panne, ça va faire louche.
[^] # Re: On va se répéter une dernière fois
Posté par tao popus . Évalué à 2.
Je ne trouve pas spécialement qu'il y ai progrès, au contraire, sur la clef USB, on peut facilement, utiliser une technologie logicielle libre à laquelle on peut faire relativement confiance pour encrypter les informations, lorsque c'est purement materiel, il n'y a plus aucun moyen de contrôle.
J'aurais l'audace de comparerer ça au vote éléctronique (inverifiable, comme le TPM) par rapport au vote papier (vérifiable par tous comme les logiciels libres), je crois qu'il n'y a pas photo sur le degré de confiance que l'on peut faire à l'un et à l'autre.
Un ex: la distribe live CD Knoppix MiB
http://www.bouissou.net/knoppix-mib/doc-html/Knoppix-Mib.html(...)
[^] # Re: On va se répéter une dernière fois
Posté par Krunch (site web personnel) . Évalué à 2.
Je dois avouer que plus je lis les commentaires de cette dépèche et moins j'ai l'impression de comprendre TCPA et compagnie mais je doute fort que ça soit moins "sécurisé" qu'une clé USB et si le brol est standardisé, c'est tout autant accessible aux logiciels libres qu'aux logiciels propriétaires.
Pour ce qui est de la comparaison au vote électronique, que tu utilises une clé USB, une carte à puce ou TCPA/TPM/machin, tu ne sais que (très) difficilement contrôler ce qui se passe en dessous d'un certains niveau donc la clé USB n'est pas beaucoup mieux du point de vue de la transparence.
Pas besoin que ça soit *purement* matériel, même avec un minimum au niveau hardware (clé USB ?), tu ne peux plus être sûr de tout contrôler.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 3.
Oui mais pour utiliser ses information tu seras obliger de les décrypter, et donc d'être à la merci d'une personne qui aurait pris le controlle de ton ordinateur et qui logguerait.
La puce TPM par contre ne laisse jamais sortir les clefs privées, donc il est impossible d'obtenir une telle clef par des moyens détournées. Pour chopper la clef publique, il faut casser la clef privée... C'est quand même uen grosse faille de sécurité en moins.
[^] # Re: On va se répéter uen dernière fois
Posté par Jean Parpaillon (site web personnel) . Évalué à 3.
Si je peux éviter un ordinateur avec une puce TPM, je le ferais. Mais quant à parler du code source des composants, je ne pense pas que le raisonnement tienne longtemps. Tu as les sources de ta puce réseau, de ton proc, du BIOS de ta carte mère, pour ne parler que de composants sensibles ?
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: On va se répéter uen dernière fois
Posté par briaeros007 . Évalué à 4.
Avoir le hdl du puce crypto et d'un puce autre ont deux but bien differents.
Le but du vhdl sur une puce cryptographique c'est d'eviter les modes "super utilisateur" comme sur certaines puces motorola (ou mode entretien ou mode ...) qui donnait les cles qu'ils etaient cense conserve.
Ca peut sembler con mais de tels puces ont deja ete utilise dans des appareils. La cryptanalyse desdits appareils a ete plutot simple dans ce cas.
De plus c'etait pour repondre au message "la puce est sur et fiable" On en sais rien qu'elle est sur ni qu'elle est fiable parce que par definition on ne peut pas avoir les algos utilise.
Tu dirais qu'un logiciel proprietaire DE CRYPTO est sur et fiable sans aucune preuve alors qu'il est assez peu repandu et utilise depuis assez peu de temps ?
Enfin je suis toujours etonne par la mauvaise foi des pro tpm qui moinsse les messages , non pas qu'ils soient inutile (car a mon avis poser des question n'est pas inutile ) mais simplement qu'ils ne correspondent pas a leurs avis. Ca reflete bien le type de personne que c'est : moi j'ai tout le temps raison.
Heureusement qu'il existe des pro tpm qui ne moinsse pas (enfin j'espere)
[^] # Re: On va se répéter uen dernière fois
Posté par Gniarf . Évalué à 3.
http://fr.wikipedia.org/wiki/Very_High_Speed_Integrated_Circuit_Har(...)
utilisé ici, ca revenait à demander si on avait le code source des composants soi-disant de sécurité (et le fait qu'on ne peut plus raisonnablement les fabriquer soi-même depuis longtemps n'est pas un détail)
[^] # Re: On va se répéter uen dernière fois
Posté par briaeros007 . Évalué à 1.
Le but du vhdl sur une puce cryptographique c'est d'eviter les modes "super utilisateur"
donne:
"Le but du vhdl sur une puce cryptographique c'est d'eviter les modes "super utilisateur" en verifiant dans le hdl de la non presence de backdoor ;)"
[^] # Re: On va se répéter uen dernière fois
Posté par LeMagicien Garcimore . Évalué à 5.
Qu'est-ce qui te prouve que le HDL qu'on te donne est bien celui de ta puce ? Sur du soft tu peux toujours recompiler. Sur du hard je vois mal comment tu pourrais faire.
[^] # Re: On va se répéter uen dernière fois
Posté par briaeros007 . Évalué à 1.
C'etait pour le principe le hdl ; pour montrer qu'on a aucune certitude de ce qu'il y a dans la puce.
Maintenant si tu veux que je te donne un protocole complet de certification j'en suis incapable mais ca fera pas avancer le schimlblick.
[^] # Re: On va se répéter uen dernière fois
Posté par Zanton . Évalué à 3.
Peut-être serait-il judicieux de faire démarrer les notes plus haut de manière à ce que des messages intéressants ne se retrouvent pas "non visibles" dès le départ car moinssé par des opposants au contenu.
Voilà, désolé pour le off topic :(
[^] # Re: On va se répéter uen dernière fois
Posté par Thomas Petazzoni (site web personnel) . Évalué à 10.
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 10.
En ce qui cocnerne les dépèches argumentés, les posts complets, les arguments contrés et les longs threads (notamment contre free2) j'ai très largement fait mon boulot.
Si je regarde juste dans l'historique des commentaires de ma page perso (http://linuxfr.org/~khane/(...) ) on y trouve :
http://linuxfr.org/comments/609635.html#609635(...)
http://linuxfr.org/comments/609658.html#609658(...)
http://linuxfr.org/comments/609667.html#609667(...)
Dans une news récente, j'en ai pas mal soupé
https://linuxfr.org/2005/06/18/19158.html(...)
Seulement je suis d'accord qu'il faut un article clair et simple. Mais c'est très long à faire. je susi dessus depuis deux mois, j'avance bien même si j'ai beaucoup de mal à obtenir les informations (sur La Grande notamment) sans signer de NDA.
Le gros problème est que l'amalgame TCPA/La Grande/Trusted Computing entretien l'illusion que l'on ne eput avoir l'un sans les autres, ce qui est faux. On peut avoir une puce de sécurisation sous le controle total de l'utilisateur sans se frapper toute la clique de matériel espion et limitatif.
[^] # Re: On va se répéter uen dernière fois
Posté par Thomas Petazzoni (site web personnel) . Évalué à 6.
Si besoin, je veux bien être relecteur pour l'article en question : je peux jouer le rôle du relecteur-neuneu-de-base-qui-connait-pas-grand-chose-voire-rien-a-TCPA ;-)
[^] # Re: On va se répéter uen dernière fois
Posté par Gniarf . Évalué à 9.
le vrai utilisateur, le client de ces petits bidules, ce n'est pas moi, mais le marchand de PC et de matériel qui doit les intégrer pour que son matériel soit autorisé (euh, zut, on dit reconnu) par Microsoft qui tient 90 % du marché, moi je vais juste être un gentil consommateur avec un sourire béat à qui on va tendre le produit fini, une grosse boite avec ces petits bidules cachés - ou pas de boite du tout.
être au courant ne change pas grand chose : essayez d'acheter un iPod sans DRM à Apple, ils vous diront qu'ils ne font pas. une imprimante ou un photocopieur couleur qui ne rajoute pas les petits bidules qui contiennent le numéro de série de l'engin ? aucun fabricant ne fait, quelque soit le prix.
pour le reste, le matériel qui va bien sera simplement plus cher au début, ensuite il ne sera plus fabriqué ou tout simplement déclaré illégal à la vente et à l'importation
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 4.
a) Que le TPM sans le liberticide existe, fonctionne est libre sous linux et est complètement doccumenté.
b) Que le liberticide autour se revendique d'être "Opt-in", qu'il n'est pas encore implanté et qu'il n'est même pas fini.
c) Qu'on a encore le choix de prendre du "rien du tout" et qu'en faisant un tapage on peut garder ce qui est bon pour nous et rejeter ce qui ne l'est pas.
En bref : il ne faut pas jeter bébé avec l'eau du bain. Certaines sociétés ont pour des raisons réelles (Jetez un coup d'oeuil à la norme Sarbannes-Oxley pour comprendre) besoin d'un plus en sécurité. Si on leur fait croire que ce plus ne peut être obtenu que par l'acception d'un framework Trusted Computing complet elle prendront le framework plutôt que de dépenser des milliards supplémentaires en audit de sécurité et de prier poru que les procédures soient respectées.
Par contre si on insiste sur le fait que ce dont elles ont besoin est en fait un module disponible séparément qui en nécessite en rien l'acception de l'ensemble du framework, alors elles risquent de faire pencher la balance en notre faveur. Au final on peut récupérer un outil qui protège les libertés individuelles au lieu de les mettre à mal.
[^] # Re: On va se répéter uen dernière fois
Posté par Benoît Sibaud (site web personnel) . Évalué à 9.
- qui a généré la clé maître en dur dans la puce, et comment ? (a-t-elle être créée pour être plombée dès le départ, ou a-t-elle était stockée à la création par le fabricant par exemple)
- puis-je changer cette clé maître ?
- le gain pour l'utilisateur justifie-t-il notamment la traçabilité amenée par un identifiant unique sur chaque processeur, et la perte de contrôle éventuelle sur ce que je peux exécuter sur mon ordinateur ?
- comment je fais si cette puce est boguée ?
- est-ce forcément une super idée de regrouper mes informations les plus secrètes dans une boîte noire étiquetée « boîte à informations les plus secrètes » ?
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 6.
Toi même. C'est une rpocédure qui s'appelle prendre possession du TPM (Taking ownership of a TPM). Sans celà le TPM est inutilisable (vous ne disposez d'aucun moyen pour créer ou lire des zones et des clefs)
puis-je changer cette clé maître ?
Oui, il suffit de refaire la procédure de prise de controle du TPM. Si celle ci a déjà été effectuée une fois, il faut connaitre le "secret" du précédent owner ou faire un reset de la puce (ce qui nécessite uen présence physique sur le poste).
Bien sur toutes les clefs contenues dans le TPM seront détruites.
le gain pour l'utilisateur justifie-t-il notamment la traçabilité amenée par un identifiant unique sur chaque processeur, et la perte de contrôle éventuelle sur ce que je peux exécuter sur mon ordinateur ?
Il y a identification , mais pas tracabilité. Avec TPM je peux générer autant d'identifiant unique que je le souhaite, et je peux donc facilemetn créer un profil PCR par site en ligne. Les différents profils seront inrecoupables.
Il n'y a pas non plus de blocage de l'ordinateur. La puce TPM reste totalement passive. Elle recoit un challenge et renvoit une réponse (ou non). C'est à peu prés tout ce qu'elle sait faire niveau interraction avec l'extérieur. Une erreur ou une absence de réponse ne peuevnt en aucun cas générer un lockdown hardware.
comment je fais si cette puce est boguée ?
Soit les fonctions d'exports fonctionnent encore, et il y a alors moyen d'exporter les clefs vers un autre TPM fonctionnel. Soit l'ensemble des clefs peut être considéré comme perdu.
est-ce forcément une super idée de regrouper mes informations les plus secrètes dans une boîte noire étiquetée « boîte à informations les plus secrètes » ?
C'est le problème du coffre fort. Chacun est libre de sa propre stratégie de sécurité. Les clefs privées contenues dan sun TPM sont supposées quasi inaccessibles et totalement inaccessibles à distance. On peut être sceptique quand à cette afirmation, mais il reste le problème de trouver uen alternative à fiabilité comparable.
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 4.
Pas d'accord. Le TPM contient bien une clé asymétrique codée en dur (EK, Endorsement Key), non modifiable par l'utilisateur, ainsi que le certificat correspondant signé par le constructeur et lisible par l'OS (sauf en cas de désactivation, auquel cas le TPM ne sert plus à grand chose).
Les specs TPM mentionnent explicitement que ça pose des problèmes de traçabilité puisque le certificat identifie de manière unique le TPM.
(https://www.trustedcomputinggroup.org/downloads/tpmwg-mainrev62_Part(...) TPM Main specification version 1.2 Part 1 Design Principles, page 25).
Le secret partagé correspondant à la notion d'"ownership" n'est rien de plus qu'un code PIN amélioré.
En fait les specs sont un peu floues (délibérément ?) quant à savoir qui génère EK. Mais il est clair que le TPM serait inutilisable pour faire du DRM si on laissait les utilisateurs choisir tous la même clé, ou émuler leur TPM en soft. Donc inutile de réver.
AC
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 3.
Mais le document TPM_1_2_Changes_final explique que les chips qui supportent cette fonctionalité seront plus chers que les autres. Autrement dit, aucun constructeur ne les intégrera dans ses PC.
AC
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 4.
Elle peut contenir. Il s'agit d'une demande qui avait été faite par certains constructeurs, lesquels sont finalement revenus sur leur décision. L'endorsement Key est uen clef qui certifie que la puce a bien été construite par "tel constructeur" et qu'elle est bien de version "machin". Il y a deux personnes authorisées à générer cette clef : le constructeur de la puce ou le constructeur du PC. Le vrai problème de cette clef est que si l'on s'en sert via un tiers de confiance pour générer plusieurs certificats uniques pour des sites internet ou des services online et que les tiers de confiance sont de mêche avec les dits sites et fournisseurs de services alors on peut faire la correlation entre les différents certificats.
C'est un vrai problème de sécurité sauf que
a) Aujourd'hui il n'existe aucune puce grand public contenant l'endorsement key
b) Il n'existe aucun tiers de confiance et aucun site exigeant des certificats EK
c) Intel a mis au point une autre technique de certification d'identité TPM qui est beaucoup moins intrusive et nettement plsu simple à mettre en place.
(sauf en cas de désactivation, auquel cas le TPM ne sert plus à grand chose).
C'est dommage çà. Parceque j'ai deux puces TCPA chez moi, qui n'ont pas d'EK, aucun moyen d'en rajouter une et qui fonctionnent très bien. L'EK est puremetn facultative et ne touche qu'une partie marginale des fonctions TCPA
Le secret partagé correspondant à la notion d'"ownership" n'est rien de plus qu'un code PIN amélioré.
Oui, et ? A ce que je sache on a toujorus pas craqué le pin d'une carte à puce. Il y a toujours une bourse de beaucoup d'argent pour le premier qui y arrive.
En fait les specs sont un peu floues (délibérément ?) quant à savoir qui génère EK
Elles sont très claires au contraires. Le fondeur ou le cosntructeur.
Mais il est clair que le TPM serait inutilisable pour faire du DRM si on laissait les utilisateurs choisir tous la même clé
Le truc c'est qui si on leur impose un certificat toujorus différent à chaque fois, TPM est quand même incapable de faire du DRM. L'EK+certifiact ne peuvent servir qu'à répondre à une demande de certification emmanant d'un tiers de confiance. C'est inutilisable pour crypter un fichier sur le disque dur par exemple.
En ce qui concerne les clefs utilisables pour crypter un fichier, elles sont déplaceables et copiable sà volonté. Ca fait un poil tache pour une utilisation DRM
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 4.
Soyons clairs: ça sert avant tout à certifier que le TPM est un vrai TPM (et pas une émulation en soft), que l'OS n'est pas bidouillé ou virtualisé, et que le Media Player respecte le DRM. Tout ça via les AIK et les PCR.
Ben oui: Si tu veux faire des choses compliquées, par exemple du boot sécurisé, tu dois acheter un TPM avec un EK et un certificat codés en dur. Sinon, on te vend un TPM sans EK et tu te contentes de l'utiliser pour stocker des clés. Mais on ne te laisse pas gérer EK toi même. Pourtant ce serait très utile pour des applications en entreprise. Bizarre, non ?
Les premiers DVD commercialisés n'étaient pas chiffrés, même quand CSS était déjà dans la norme.
Ca m'intéresse. Des références ?
Et on va geler le déploiement de TCPA et réécrire toutes les specs pour intégrer le mécanisme d'Intel ?
AC
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 2.
Oui
que l'OS n'est pas bidouillé ou virtualisé,
non
et que le Media Player respecte le DRM.
non
Tout ça via les AIK et les PCR.
L'EK est dans un conteneur différent des AIK. Ils ne peuvent en aucun cas se garantir l'un l'autre.
L'EK permet de garantir que l'on est bien en face d'un TPM authentique. Le système PCR/AIK permet de vérifier que telle ou telle ressource est accessible et dans le même état que la fois précédente. Grosso modo on ouvr eun coffre à clef, on fourre une clef dedans au premier passage (sans avoir aucune identification possible de ce qu'est l'OS, le bios etc.) et au deuxième passage on vérifie que l'on est bein dans la même config que lors du premier passage en lancant un challenge sur tel PCR sur la clef que l'on a mis dans ce PCR.
Et là soit on a une réponse positive, soit pas.
C'est tout.
Ben oui: Si tu veux faire des choses compliquées, par exemple du boot sécurisé, tu dois acheter un TPM avec un EK et un certificat codés en dur.
Mon boot est certifé, mes programmes sont sous surveillance constante (refresh des PCR toutes les minutes) et si quelqu'un fait la moindre modif ou que ce soit, SE Linux ferme immédiatement l'ensemble des droits en lecture/écriture/exécution. Ca marche très trop bien (Trop parceque le serveur X est son utilisation de SHM m'empèche de ls signer/locker proprement)
Certifier le boot ne veux pas dire pouvoir prouver à une tierce partie que l'OS sur lequel je bosse est bien un windows (TCPA est totalement incapable de faire çà) mais prouver à uen tierce partie que le boot est bien le même que cleui de la dernière fois.
Je peux bien sur certifer le boot, l'OS, toute un groupe d'applis ou appli par appli etc. suivant le même principe.
Ca m'intéresse. Des références ?
http://www.intel.com/technology/security/downloads/scms19_direct_pr(...)
Par contre sur les 5 liens existant seul celui ci reste, mais il y a eu un gros upload de docs récamment. Effacement malencontreux ou revirement ?
Et on va geler le déploiement de TCPA et réécrire toutes les specs pour intégrer le mécanisme d'Intel ?
Non on va simplement ocntinuer comme on a commencé : des puces sans EK dans un monde sans personen capable de certifier les EKs. Le reste de la puce TPM est très bien.
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 1.
D'après les specs les AIK sont des alias de EK (pour limiter la traçabilité), donc il ne sont quand même pas complètement indépendants.
Ah, ça c'est cool. On peut avoir des détails sur la config ?
Certifier le boot ne veux pas dire pouvoir prouver à une tierce partie que l'OS sur lequel je bosse est bien un windows (TCPA est totalement incapable de faire çà)
Ben si, quand même. Le TPM répond à un challenge en signant le PCR correspondant à la config Windows avec un AIK reconnu par Microsoft (via le tiers de confiance éventuel).
mais prouver à uen tierce partie que le boot est bien le même que cleui de la dernière fois.
Et ta config permet-elle de faire ça, la tierce personne étant quelqu'un d'autre que toi ?
Par exemple, dans une entreprise, permet-elle à l'administrateur de détecter qu'un utilisateur est en train d'essayer de se connecter au réseau avec un OS non autorisé ?
Il me semblait que pour ça il faut des AIK, et donc un EK (certifié par le constructeur ou au moins par l'administrateur).
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 2.
GNI ? Les AIK sont des descripteurs de contenu PCR (genre ce PCR a été créé avec un hash préboot+mémoire+appli "toto"+utilsateur "marcel" ).
Ah, ça c'est cool. On peut avoir des détails sur la config ?
Déjà publié par IBM, mais ca sera dans l'article, promis.
Ben si, quand même. Le TPM répond à un challenge en signant le PCR correspondant à la config Windows avec un AIK reconnu par Microsoft (via le tiers de confiance éventuel).
Si tu veux que ton AIK soit reconnu par microsoft, i faut obligatoirement passer par un tiers de ocnfiance. Un AIK est une clef qui décrit le contenu du hashage, mais elle n'est pas "lisible" en clair. Pour prouver qu'elle correspond bien à ce qu'elle prétend être il faut nécessairement passer par un certificat.
Ce qui se passe :
Tiers inquisiteur : Il me faut l'AIK boot+windows.exe+utilisateur
TPM utilisateur : OK c'est FH67EF45DE43AC34FF22
Tiers de confiance : Je confirme c'est bien l'AIK boot+windows.exe+utilisateur (et c'est uniquement à çà que l'EK sert)
Mais alors maintenant si un petit malin c'est amusé a lancer un programme "windows.exe" sur son linux (par exemple un process idle, on va pas gacher des ressources non plus) ni le tiers inquisiteur ni le tiers de confiance ne peuvent rien y faire. On a demander à TPM de signer windows.exe, il l'a fait et basta. Ce qu'est windows.exe il n'en sait rien et il s'en moque.
Par exemple, dans une entreprise, permet-elle à l'administrateur de détecter qu'un utilisateur est en train d'essayer de se connecter au réseau avec un OS non autorisé ?
Tout à fait. Il suffit de signer le boot de chaque machine et de noter le résultat. Si il change, c'est qu'il y a entourloupe. Quand on a les PC sous la main, on a pas besoin de l'EK. On signe les PC quand on est sur qu'ils sont "propres". Et on tape sur tout ce qui change.
L'EK ne sert que pour les TPM inconnus perdus dans la nature. Pour les PC de ton réseau...
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 2.
Evidemment, mais le tiers inquisiteur, lui, décidera de faire confiance à la plate-forme ou pas en fonction de la valeur du hash. Bon, on ne va pas épiloguer sur le fait que TCPA peut être utilisé, si on le souhaite, comme un composant essentiel d'une infrastructure de DRM.
Quand on a les PC sous la main, on a pas besoin de l'EK.
Logistiquement, c'est un cauchemar d'avoir les PC sous la main. Le protocole à base d'EK certifiés par le constructeur permet à l'administrateur d'activer les PC à distance.
On signe les PC quand on est sur qu'ils sont "propres".
En pratique l'administrateur veut signer un seul PC "propre" de référence et télécharger le PCR correspondant vers tous les TPM de son réseau, sans se déplacer, à chaque fois que c'est nécessaire. Sans crypto asymétrique (EK), ça va être très très chaud. Surtout quand on voudra mettre à jour les PCR précisément parce qu'on vient de s'apercevoir que la config "propre" n'était pas si propre que ça...
Et quid du petit malin qui ramène un PC en panne au SAV ? Est-ce qu'on lui signe son PC ? Sans EK, comment savoir si c'est un vrai TPM qui est dedans ?
Bref, moi je veux des puces TCPA avec EK, parce que c'est plus sûr et plus flexible. Mais je veux aussi avoir le contrôle de mon EK pour éviter que d'autres en abusent.
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 2.
Il va avoir ennormément de mal. Le tiers de confiance peut très facilement vérifier si c'est lui ou pas qui a mis le certificat dans le TCPA. Mais supposons qu'il veuille valider un hash.
Même si on demande le hash de juste windows.exe; le TPM ne fait pas de mini hashes, il y a en fait 8 hashes successifs avant même le premier hash demandé. Les hashes contiennent : Le CPU, le Chipset, le bios, la puce TCPA elle même et la séquence préboot (les divers init)
Donc hash_tcpa(windows.exe)=hash(puce_TCPA + hash(chipset1 + hash(chipset2 + hash(CPU + hash(.... )+hash(windows.exe) ))))
Bien entendu chaque puce renvoit un hash différent. Et puis le chipset intel rev156b ne renvoit pas le même hash que le chipset intel rev156c.
Sur deux portables T42 identiques je n'ai jamais réussi à leur faire cracher deux hashes similaires.Et j'ai vraiment essayé.
Autant te dire que pour vérifier un hash et en déduire ce qu'il y a vraiment dérrière il faut y aller....
En ce qui concerne EK je pense que mon précédent poste a du t'éclairer sur ce que je voulais vraiment dire.
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 3.
Pourtant la spec TCG PC Specific Implementation Specification fait tout ce qu'il faut pour que certains hashes soient prédictibles. Par exemple, elle exige que les numéros de série et autres identifiants uniques ne soient pas hashés, ainsi que les portions du MBR spécifiques à la géométrie du disque. Ces précautions n'auraient aucune utilité si l'objectif était seulement de contrôler que le PC boote "dans la même config que la dernière fois". Etrange, non ?
Et quels registres PCR as-tu comparés entre tes deux machines ? J'ai l'impression que seuls PCR[0]-PCR[4] sont conçus pour être bien déterministes.
Autant te dire que pour vérifier un hash et en déduire ce qu'il y a vraiment dérrière il faut y aller....
Je suis sûr que les constructeurs fourniront la liste de toutes les combinaisons homologuées de composants mis sur le marché, si Microsoft demande gentiment.
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 2.
Attention. Il est très important de se souvenir que la puce TPM ne renvoit pas les hashes individuels, mais le résultat d'une série de hashes imbriqués.
Par exemple, un chipset southbridge renverra toujours le même hash à l'intérieur du TPM via les systèmes de mesures. Cependant ce hash ne sort pas de la puce. Ce qui sort de la puce c'est hash(M(chipset1) + hash(M(chipset2) + hash(M(TPM)+ hash (M(bios) + hash(M(chipset3) + ...)))))
avec M(X) la mesure du composant X par la puce TCPA.
Il y a au minimum 8 hash imbriqués, et on peut pour créer des PCR non publics en rajouter jusqu'à 8 de plus. Comme les mesures de chaque TPM sont unique (ie M(TPM) est différent pour chaque TPM - encore heureux). Le hash qui va sortir sera également unique.
Ces précautions n'auraient aucune utilité si l'objectif était seulement de contrôler que le PC boote "dans la même config que la dernière fois".
Dans ce cadre là, les précautions ne servent à rien, elles servent par contre beaucoup dans un autre cadre : l'envoi en réparation. Supposons que le chipset1 brule et qu'il contienne un numéro de série. Si les mesures et leur hash ne sont pas prédictibles, le nouveau chipset va changer complètement tous les PCR, même le PCR public ne sera plus accessible si chipset1 fait partie des 8 composants fondamentaux qui servent à chaque PCR. En d'autres termes, chaque panne matérielle pourrait entrainner la perte de l'ensemble du contenu de la puce TPM. Ce qui fait quand même un peu désordre non ?
Je suis sûr que les constructeurs fourniront la liste de toutes les combinaisons homologuées de composants mis sur le marché, si Microsoft demande gentiment.
Même en ne prenant que les 8 hash principaux et en supposant qu'il existe un moyen de récupérer M(TPM) hors de la puce. il faut alors connaitre l'ensemble des combinaison possibles de
hash(M(chipset1) + hash(M(chipset2) + hash(M(TPM)+ hash (M(bios) + hash(M(chipset3) + hash(composant6 + hash(composant7 +hash(composant 8))))))))
Un système de hash bien fait étant ininversible il faudra comparer le hash final à l'ensemble de tous les hashs possibles à chaque fois. En supposant qu'il existe cent types de composants de chaque sorte (et là on est carrément optimiste) hors TPM cela fait 100^9x(nombre de TPM vendus) hash à connaitre en se contant seulement ici d'identifier le matériel préboot (ie le PCR public).
Après bien sur si on veut faire du drm c'est la liste de l'ensemble des
hash(M(chipset1) + hash(M(chipset2) + hash(M(TPM)+ hash (M(bios) + hash(M(chipset3) + hash(composant6 + hash(composant7 +hash(composant 8 + hash(boot + hash(system +hash(user +hash (logiciel + hahs (donneés))))))))))))) qu'il faut connaitre. Et il be faut pas oublier de régénerer l'ensemble de la base à chaque fois qu'il y a mise à jour du système ou du logiciel.
Si on table sur 10% de PC équipés de puce TPM et d'un seul utilisateur non owner par TPM ca fait 10^18x(80 000 000)² (il y a environ 800 000 000 de PC dans le monde). Ca fait 6.4x10^33 données possibles. La bonne nouvelle c'est que c'est en dessous du nombre d'atomes dans l'univers, donc techniquemetn réalisable. La mauvaise nouvelle c'est qu'on est dans une hypothèse hyper favorable et qu'on a même pas pris en compte le bios, le système, le lgoiciel ou les données....
Donc pour DRM, je continue de pas y croire un seul instant.
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 2.
Pourtant TPM_Quote reçoit en argument la liste des PCR à intégrer dans le hash, sous la forme d'un bitmask. Qu'est ce qui emêche le tiers inquisiteur de demander 8 attestations contenant chacune un seul PCR ?
Même si TPM_Quote n'acceptait de signer que des hashes intègrant plusieurs PCR, un système de DRM pourrait en parallèle lire les PCR individuels avec TPM_Read, les hasher lui-même, et comparer son résultat avec le hash signé. Si la fonction de hachage est bien choisie, ça suffit à certifier chaque PCR.
(ie M(TPM) est différent pour chaque TPM - encore heureux).
Pourquoi M(TPM) serait-il unique ? Où vois-tu ça dans la spec ?
chaque panne matérielle pourrait entrainner la perte de l'ensemble du contenu de la puce TPM.
Ben il suffit d'utiliser régulièrement la procédure de backup/migration du TPM, non ?
Et puis tu connais beaucoup de SAV qui s'amusent à désouder des chips sur les cartes mère ? Et qui de plus prendraient la peine de mettre exactement la même version de firmware en remplacement pour que le TPM ne s'aperçoive de rien ?
Ca fait 6.4x10^33 données possibles.
Toujours sous ton hypothèse douteuse que deux machines n'ont aucune chance de renvoyer le même hash.
De plus, j'imagine que les constructeurs auront beaucoup de paperasse à remplir pour avoir le droit de certifier des composants et des PC complets. Donc il est clair que les utilisateurs n'auront plus le choix entre 36 versions de BIOS comme aujourd'hui. Au mieux il y aura 3 versions certifiées et 33 versions "beta". Idem pour les drivers Windows certifiés par Microsoft.
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 2.
Si tu demande un seul PCR tu auras le hash de tous les PCR pré-boot plus le PCR boot/postboot que tu as demandé. C'est l'architecture me de la puce qui empèche de renvoyer hash(OS_LOAD) par exemple. Ca sera toujours un hash imbriqué.
Pour TPM_Quote c'est le même principe, pour qu'un hash soit valide, il faut absolument qu'il prenne en compte le CRTM (ie la base de confiance des mesures). C'est même la seule façon de vérifier que les données renvoyées par le TPM sont valides.
Pourquoi M(TPM) serait-il unique ? Où vois-tu ça dans la spec ?
GNI ? L'EK est unique, normalement la signature du secret ownership aussi. Donc le CRTM sera forcément unique (aux collisions prés). c'est la base même du TPM, et la raison principale pour laquelle les TPM doivent être livrés sans owner. C'est la seule façon de s'assurer que le constructeur n'a pas pu faire une copie de notre CRTM. C'est clair que si les TPM étaient livrés avec un own et un secret prédéfini, les constructeurs pourraient noter les clefs publics et signatures comme ils peuvent le faire avec l'EK.
Autre problème si M(TPM) n'est pas unique, ca veut dire que si une personne reset la puce, elle garde quand même intact les AIK, et puet donc se faire passer pour le possesseur légal de la puce.
Bref si M(TPM) est déterministe, la puce n'apporte strictement rien en matière de sécurité.
En plus tous le meccanisme de certification de la puce par l'EK n'apporterait alors strictement rien, vu que tous les TPM (au moins d'une même marque - même modèle) auraient la même signature. Pourquoi créer des certificats supplémentaires si il suffisait de demander le hash du CRTM ?
Ben il suffit d'utiliser régulièrement la procédure de backup/migration du TPM, non ?
Oui, à l'EK près ca suffirait. Seulement madame Michu n'a pas forcément deux ordinateurs sous TPM à la maison, et monsieur DSI GrosseBoite n'a pas forcément envie de lancer une procédure de backup systématique de tous ses TPM. Surtout que cette procédure et inautomatisable.
Et puis tu connais beaucoup de SAV qui s'amusent à désouder des chips sur les cartes mère ? Et qui de plus prendraient la peine de mettre exactement la même version de firmware en remplacement pour que le TPM ne s'aperçoive de rien ?
C'est bien pour çà qu'il faut qu'un rpemplacement de carte mére à l'identique ne gène pas le TPM. Les TPM infineon par exemple sont sur des cartes filles extractibles, pour permettre une maintenance facilité (la carte mère crame, on peut quand même garder le TPM en état). Quand à la mise à jour des firmwares il est possibles grace à un système de certifications des composants de faire accepter une mise à jour de composants par le TPM sans que les clefs ne se bloquent. Cependant je ne coris pas qu'ile xiste de TPM supportant cette opération au jour d'ajourd'hui.
Toujours sous ton hypothèse douteuse que deux machines n'ont aucune chance de renvoyer le même hash.
Ce n'est pas une hypothèse. EK + signature du secret owner est unique.
Au mieux il y aura 3 versions certifiées
Par constructeur et par mois ? Ou bien il n'y aura qu'un seul constructeur par chipset existant lequel aura seulement trois versions et ne fera pas de nouveaux chipsets pendant des années ?
Honnêtement, si il n'y a que trois chipsets certifiés (mettons Intel, VIA, NVidia) par classe de chipset ca va être un vrai frein au progrès.
Soyons sérieux, Intel rien que pour les bridges CPU possède plusieurs dizaines de chipsets à l'heure actuelle, et c'est normal : il y a plusieurs classe de processeurs, des cartes mères qui vont de un à 8 processeurs, des controlleurs redondants ou non, des support mémoires ECC et/ou regsitred ou rien etc. Lesquels chispet sont intégrés différamment suivant que ce soit Intel, Asus ou Tyan qui fasse le boulot. Pour tomber à trois chipsets certifiés il faudra couper sévèrement.
Et là je ne parlerais même pas du dernier jouet de Intel : le Bios EFI qui s'assure à lui tout seul d'exploser largement les cents variantes par composant
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 2.
Bien sûr, ça ne servirait à rien de savoir que le PC fait tourner Windows, si on ne sait pas ce que le BIOS et tous les inits ont fait avant.
Mais il y a bien plusieurs niveaux de hash qui sont de plus en plus "uniques". Et PCR[0] à PCR[4] semblent conçus pour être identiques sur deux PC d'un même modèle.
L'EK est unique, normalement la signature du secret ownership aussi.
De même que les numéros de série du BIOS ne sont pas incorporés dans tous les PCR, j'imagine qu'il y a des PCR qui caractérisent le modèle et la version du TPM mais pas son EK unique. Le tiers inquisiteur peut demander les PCR appropriés selon qu'il veut faire du DRM ou seulement du boot sécurisé.
Pourquoi créer des certificats supplémentaires si il suffisait de demander le hash du CRTM ?
Ben sans certification de la plate-forme par EK, le tiers inquisiteur n'a aucune raison de faire confiance au CRTM.
Seulement madame Michu n'a pas forcément deux ordinateurs sous TPM à la maison
Il faut obligatoirement deux TPM pour faire un backup ? Qu'est ce qui m'empêcherait de demander un backup vers un TPM émulé ?
(sauf pour les clés non-migrables et CMK, évidemment).
Surtout que cette procédure et inautomatisable.
Pourquoi ? Ce n'est pas télécommandable par le Owner ?
Soyons sérieux, Intel rien que pour les bridges CPU possède plusieurs dizaines de chipsets à l'heure actuelle
Certes, mais les combinaisons effectivement mises sur le marché, c'est à dire les modèles de PC, ne couvrent pas toutes les combinaisons possibles des composants.
Allez, une autre solution pour faire du DRM sans base de donnée centrale, et même si les hashes n'étaient jamais les même d'une machine à l'autre: Il suffit qu'à la sortie de l'usine, le constructeur boote le PC, demande le hash, génère un certificat qui dit "je garantis que le hash 0x12345678 correspond au boot d'un PC TCPA avec tel bootloader", et livre ce certificat avec le PC. Ca revient à implémenter la base de façon distribuée. Mais il est vrai qu'il n'y a rien de tel dans les specs, à ma connaissance.
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 2.
Les PCR sont les noms des "boites" qui contiennent les données sécurisées. La question est de savori si on peut avoir la signature ou l'AIK de juste cette boite. La réponse est non, tous les hash qui sortent de la puce contiennent au minimum un sous hash du CRTM.
PCR[0-4] servent à valider la cohérence du TPM (ie prouver que le système n'a pas été compromis) donc ils sont prévisibles. Mais ce n'est pas pour autant qu'ils sortent de la puce.
j'imagine qu'il y a des PCR qui caractérisent le modèle et la version du TPM mais pas son EK unique
Bien sur, un PCR peut ne caractériser que celà, mais si tu demande un hash ou un AIK qui permet d'accéder à ce PCR une fois d eplsu le hash sortant de la puce contiendra le CRTM (et donc sera imprévisible)
Ben sans certification de la plate-forme par EK, le tiers inquisiteur n'a aucune raison de faire confiance au CRTM.
Si le CRTM était prévisible si. Il pourrait faire les calculs de son coté et vérifier la concordance.
Il faut obligatoirement deux TPM pour faire un backup ? Qu'est ce qui m'empêcherait de demander un backup vers un TPM émulé ?
Le specs. La migration n'est déclenchable que vers un autre TPM. J'imagine que l'on pourrait forcer une migration via un TPM émulé en forcant le TPM hôte à accepter le certificat du TPM émulé. Beaucoup de travail pour madame Michu...
Pourquoi ? Ce n'est pas télécommandable par le Owner ?
Non, la présence physique est requise.
Allez, une autre solution pour faire du DRM sans base de donnée centrale, et même si les hashes n'étaient jamais les même d'une machine à l'autre: Il suffit qu'à la sortie de l'usine, le constructeur boote le PC, demande le hash, génère un certificat qui dit "je garantis que le hash 0x12345678 correspond au boot d'un PC TCPA avec tel bootloader", et livre ce certificat avec le PC.
Ce serait une façon de faire, c'est dommage que la norme TCG interdise strictement qu'un TPM soit livré avec un owner prédéfini et des clefs préchargées. De plus, il faudrait également s'assurer que le propriétaire du PC ne connaisse pas le secret owner, ne puisse pas reseter la puce etc. Bref on a à 100 lieues des specs.
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 2.
Ah, alors si j'appelle TPM_ReadPCR(0) à TPM_ReadPCR(4), j'obtiens quoi ?
Et si j'appelle TPM_Quote(0x11111000), je n'obtiens pas un hash portant sur PCR[0-4] et eux seuls ?
Par ailleurs PCR[0-4] ne concernent pas seulement l'intégrité du TPM. En particulier, PCR[4] inclut le MBR (en prenant soin d'exclure la géométrie du disque, qui n'est pas assez prévisible).
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 2.
Et si j'appelle TPM_Quote(0x11111000), je n'obtiens pas un hash portant sur PCR[0-4] et eux seuls ?
En théorie bien sur, mais tu auras PCR[0] dans le lot, donc comme PCR[0] contient déjà le CRTM tu auras déjà un hash impossible à corréler. A partir du moment ou dans un hash tu demandes le PCR[0], le résultat de ce hash n'est pas intrepretable vu que PCR[0] contient la mesure du CRTM (et donc implicitement la mesure de l'EK) et la mesure du owner. Or tu ne peux pas ne pas demander PCR[0], vu le principe même de l'extend des hash.
PCR[0] - ce que j'appelais M(TPM) précédamment est totalement unique pour chaque TPM et change à chaque reset/TakeOwnership
Par contre si tu essayes de demander PCR[1-3] par exemple (donc CPU, ESCD,CMOS, NVRAM + BIOS, OPTION ROMS + OPTION ROMS CONFIGURATION) tu te fais jeter. La puce TCPA ne sait pas construire de hash autrement qu'à partir de PCR[0] et en remontant (principe de l'extend).
Par ailleurs PCR[0-4] ne concernent pas seulement l'intégrité du TPM.
Non ca concerne l'intégrité du système préboot. Si je t'ai laissé penser le contraire, j'en suis désolé.
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . Évalué à 2.
Ce n'est pas cohérent. Si ça fonctionnait comme tu le dis, l'argument passé à TPM_Quote n'aurait pas besoin d'être un bitmask. Ce serait simplement le numéro du dernier PCR à intégrer dans le hash.
Il me semble évident que le principe d'agrégation séquentielle (ce que tu appelles "extend") s'applique aux registres PCR indépendamment les uns des autres. A tout moment, PCR[0] donne l'historique du CRTM depuis le reset de la machine. PCR[4], c'est l'historique de tous les bootloaders qui ont été essayés. PCR[5] loggue la géométrie du disque et, en cas de multiboot, la partition qui a été sélectionnée. Et PCR[6] enregistre carrément toutes les mises en hibernation du PC.
PCR[0] - ce que j'appelais M(TPM) précédamment est totalement unique pour chaque TPM et change à chaque reset/TakeOwnership
Ce n'est pas ce que je lis dans TCG_PCSpecificSpecfication_v1_1.pdf:
"Only executable code is logged."
"Configuration data such as ESCD should not be measured as part of this PCR."
"Entities that MUST be measured: the CRTM's version identifier (...)"
Il n'est jamais question de logger EK. Ce serait même choquant, car ça fournirait un identifiant globalement unique même lorsque la lecture de PubEK est désactivée.
si tu essayes de demander PCR[1-3] par exemple (...) tu te fais jeter.
Bon, tu as essayé sur ta machine ? TPM_ReadPCR(1) et TPM_Quote(0x00001110) renvoient un code d'erreur ? Lequel ?
AC
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . Évalué à 5.
A force de ne pas avoir de réponse valable dan sun sens ni dans l'autre , j'ai fini par prendre mon tournevis et démonter les 2 T42 sous TCPA. Là je me suis rendu compte avec horreur que les deux modèles de cartes LPC étaient différents - de fait il est un peu normal que j'obtienne jamais deux fois le même PCR. Dans l'ordre :
a) Un IBM T42 c'ets très chiant à démonter, et c'est pire à remonter
b) Ma base de test pour quand je ne suis pas sur de comprendre la doc était fausse.
c) Ca fait potentiellement deux ans que je raconte des conneries (ou pas) sur le TPM.
d) Je dois de plates excuses à f.free2.org
Ce qui est encore sur :
- la clef d'endossement (EK) n'est toujours pas utilisable directement pour faire du DRM, car elle est toujours active et interrogeable quelque soit la config du TPM (à partir du moment ou le TPm est actif bien sur)
- les AIK liés à un PCR particulier ne sont pas facilement utilisable pour DRM non plus, vu qu'ils ne peuvent que signer et non decrypter.
- PCR[0] est immuable, il ne change pas sans intervention du constructeur. Le changement de owner ne l'influe donc pas (honte sur moi).
Ce qui mérite enquète :
- une clef liée à un PCR lui même liée à un AIK pourrait être utilisée pour du DRM. Pour celà il faudrait réussir à faire un TPM_WRAPKey en réussissant à bloquer l'interception des Auh et migrAuth par un logiciel tiers. Celà est peut-être faisable via un méccanisme de session.
- Si les clefs PCR[0-4] sont prédictibles, un challenger avec uen base de données conséquente peut connaitre votre matériel (avec révision et options) même si il n'est pas jugé digne de confiance.
- Un PCR non initialisé peut très vite donner à un challenger une méthode pour scanner les programmes s'executant sur votre machine, pour peu que ceux ci soient rigides (toujours dans l'hypothèse ou les PCR sont disjoints et ou les hashs osnt prédictibles)
En ce moment j'essaye de joindre des gens compétents chez IBM et au TCG pour avoir des réponses.
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 1.
Tiens, une question très simple:
D'après les specs, pour exécuter TPM_TakeOwnership, il faut que EK soit initialisé (car le secret partagé doit être chiffré avec PubEK).
Comment as-tu pu prendre possession de tes chips si ils n'ont pas de EK ?
Est-ce que TPM_ReadPubEK renvoie vraiment TPM_NO_ENDORSEMENT ?
Ou seulement TPM_DISABLED_COMMAND ? (ce qui signifierait que la lecture de PubEK est restreinte, mais il reste TPM_OwnerReadInteralPub).
Tu voulais peut-être dire que le vendeur ne t'a pas fourni le certificat EK en même temps que la machine ?
AC
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 3.
Non, j'ai bien une EK sur mon TPM et elle est bien certifiée au niveau 1 (sinon je me ferais jeter par les autres TPM), ce que je voulais dire est qu'elle n'est pas utilisable/activée/accessible pour les travaux de certifications third party. Je n'ai pas de certificat niveau 2 qui me permettrait d'avori des certificats niveau 3 pour me faire authentifier à l'extérieur de la puce. Grosso modo, j'ai le certificat qui dit "c'est un tcpa" mais pas celui qui dit "c'est ce tcpa là" et je ne peux donc pas créer les certificats qui disent "Mr Machin certifie que c'est bien ce tcpa là"
Mais c'est très complexe à dire. Donc ce que je veux dire c'est que je n'ai pas l'EK qui fait peur par parcequ'il identifie la machine. Et que je ne pourrais jamais l'avoir.
La certification TCPA simple suffit largement dans l'ensemble des cas, et elle n'implique pas du tout l'EK.
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 2.
Ce que tu appelles certification simple, c'est le mécanisme à base de protocole zéro-knowledge (DAA) ajouté dans la version 1.2 ?
En tout cas tu as bien un EK unique, lisible par l'OS (avec autorisation de l'Owner si tu as pris la précaution d'appeler TPM_DisablePubekRead), et que tu n'es probablement pas libre de modifier. Il ne manque vraiment pas grand chose pour que tu puisses entrer dans le monde merveilleux du DRM :-)
Si jamais le "niveau" est stocké dans le certificat mais pas dans le TPM lui-même, il suffit que le constructeur décide de te délivrer un nouveau certificat. "C'est gratuit et c'est plus sûr, pourquoi refuser ?"
AC
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 3.
Non en fait il y a trois niveaux dans la certification. Le premier niveau c'est juste que le fabriquant mette une clef EK valide en lançant la commande qui va bien.
Le deuxième niveau c'est que le constructeur récupère la clef d'endossement dans un coin et la garde précieusement pour fournir des certificats par la suite
Le troisième niveau c'est qu'il valide les certificats via un tiers de confiance.
IBM n'ayant pas mon EK je ne pourrais jamais être certifié....
En tout cas tu as bien un EK unique
oui
lisible par l'OS
oui - mais désactivable, désactivé par défaut (le TPM n'a même pas de owner)
. Il ne manque vraiment pas grand chose pour que tu puisses entrer dans le monde merveilleux du DRM :-)
En sachant que l'on ne peut pas se servir de a partie publique de l'EK pour faire de l'encryption ? Ca va être très dur.
Les fonctionnalités d'endossement impliquent une perte de l'anonymat, fut-elle temporaire. On peut parfaitement désactiver la clef d'endossement et ne jamais s'en servir. Personellement j'ai déployé ma propre clef dans la section publique de mes PCR et ca me va très bien pour créer des certificats entre les deux machines de mon réseau.
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 3.
Qui te dit qu'IBM ou le fabricant du TPM n'ont pas une copie de PubEK sous la main, pour le cas où tu demanderais un certificat ?
Voire de PrivEK (mais dans ce cas, un flag doit en principe t'indiquer que EK a été injectée et pas générée par le TPM lui-même).
En sachant que l'on ne peut pas se servir de a partie publique de l'EK pour faire de l'encryption ?
On se sert de PubEK pour faire du chiffrement, par exemple pour insérer le secret partagé du Owner à distance.
On peut parfaitement désactiver la clef d'endossement et ne jamais s'en servir.
Oui, mais dans ce cas le TPM n'apporte pas grand chose par rapport à une carte à puce associée à un BIOS non flashable. Moi je préfère qu'il y ait un mécanisme de certification qui me garantit que le TPM que j'ai acheté n'est pas contrefait, que son architecture a bien été évaluée Critères Communs EALx par un labo indépendant du fabricant, etc...
Le problème est qu'on empêche le client final de révoquer ce mécanisme de certification ou d'en prendre le contrôle et la responsabilité, alors que ce serait légitime par exemple pour un usage en entreprise. Par conséquent, un jour, 99,9% des PC auront un TPM avec une EK indélébile et un certificat utilisable pour faire du DRM, et à ce moment le grand public n'aura aucune excuse pour empêcher Microsoft, Intel et Sony de déployer Palladium au dessus, puisque ce sera indolore et gratuit (et que ça permettra de lutter contre le terrorisme, blah blah).
Plus précisément, une partie des mécanismes nécessaires (TPM_RevokeTrust et TPM_GenerateRevocableEK) ont été ajoutés à la spec 1.2, mais les release notes expliquent qu'il ne faut pas compter dessus dans les TPM destinés au grand public. Il est encore temps d'exiger que cette politique change.
L'enjeu n'est pas de pouvoir désactiver EK temporairement, ni le TPM entier.
L'enjeu est que les constructeurs de PC nous vendent exclusivement des TPM avec une EK révocable et remplaçable, même si la décision par l'utilisateur de révoquer l'EK du constructeur implique que le TPM devient inutilisable pour certaines applications.
AC
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 2.
Voire de PrivEK (mais dans ce cas, un flag doit en principe t'indiquer que EK a été injectée et pas générée par le TPM lui-même).
Effectivemetn rien. De même que je ne susi pas sur qu'il n'y ait pas un tag sur ma carte réseau ou sur mon CPU. Je ne susi pas sur non plus que quand je désactive les fonctions EK elles ne sont pas réactivables à distance etc. L'EK fait partie d'un système de certification. Tu dois donc faire confiance au constructeur, au certificateur et au tiers inquisiteur. Effectivement dans le monde du logiciel libre on peut éviter tout celà, il suffit d'auditer le code, de compielr soit-même et de détruire les certificats racines par défaut. Dans le monde hardware il faudrait faire une puce TCPA basée sur les specs et la fondre soi-même. C'est un peu plus complexe pour l'instant
Oui, mais dans ce cas le TPM n'apporte pas grand chose par rapport à une carte à puce associée à un BIOS non flashable. Moi je préfère qu'il y ait un mécanisme de certification qui me garantit que le TPM que j'ai acheté n'est pas contrefait, que son architecture a bien été évaluée Critères Communs EALx par un labo indépendant du fabricant, etc...
Achéte une puce TCPA, vérifie la, désactive l'EK, créé tes propres clef dans le PCR public et voilà. Tu as toute les garanties possible sur ta puce et le certificat que tu utilises est le tien à 100%.
Le problème est qu'on empêche le client final de révoquer ce mécanisme de certification ou d'en prendre le contrôle et la responsabilité, alors que ce serait légitime par exemple pour un usage en entreprise.
Non, la certification requiert un tiers de confiance. Si le site Ebay me certifie qu'il est bien le site ebay, je n'ai aucun moyen de savoir si c'est vrai. Si un de mes certificat racine, obtenus via des canaux fiabilisés par une chaine de confiance mer certifie que c'est bien le site ebay, c'est bon je peux y aller.
Si tu n'as pas besoin de certifier la véracité de ton identité au reste du monde, créé un clef dans le PCR public.
un jour, 99,9% des PC auront un TPM avec une EK indélébile et un certificat utilisable pour faire du DRM
Le certificat est utilisable pour faire de l'authentification, pour le DRM c'est impossible. L'EK ne peut pas être utilisé pour crypter du contenu de façon sécurisée. De plsu l'EK n'est lié à aucun PCR et est donc toujours accessible si on connait le secret. Je ne vois pas comment on peut faire du DRM avec çà.
L'enjeu est que les constructeurs de PC nous vendent exclusivement des TPM avec une EK révocable et remplaçable
Si on révoque l'EK
a) On détruit toutes les clefs et
b) On se coupe la possibilité de créer un certificat acceptable de l'extérieur (à moins de reafire appel à une tierce partie pour régénérer l'EK, et là on retombe dans le même schéma)
La solution offerte de désactiver l'EK me parait nettement plus simple et raisonnable.
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 2.
Ben oui, c'est pour ça que les gens stockent leurs clés ailleurs (sur une carte à puce, par exemple). Ceci dit la conception et la fabrication des PC TCPA sera probablement soumise à des procédures de qualité et d'audit sévères, donc je leur ferai davantage confiance qu'à mon PC actuel.
Non, la certification requiert un tiers de confiance
Tu mélanges deux choses:
- L'autorité de certification (exemple: Verisign) qui me permet de savoir qui a signé le certificat d'endossement EK de mon TPM. J'ai probablement déjà son certificat racine, et je n'ai pas besoin d'interagir avec elle.
- Le tiers de confiance auquel je dois faire appel à chaque fois que je veux créer un AIK. Dans mon scénario de boot sécurisé en entreprise, l'administrateur réseau peut très bien être son propre tiers de confiance.
Achéte une puce TCPA, vérifie la, désactive l'EK, créé tes propres clef dans le PCR public et voilà.
OK, sauf que je ne suis pas certain que mes clés permettent de faire la même chose que EK+AIK dans le scénario du réseau d'entreprise.
(...) Je ne vois pas comment on peut faire du DRM avec çà.
Bon, on tourne en rond. Pour avancer, il suffirait que l'EFF ou la CNIL implémente une démo d'infrastructure DRM bien méchante à base de TCPA,
juste pour montrer à tout le monde que c'est possible et que ça peut faire mal.
La solution offerte de désactiver l'EK me parait nettement plus simple et raisonnable.
Encore une fois, il vaudrait mieux pouvoir désactiver EK (sinon TPM_ForceClear suffit à la réactiver), pour que personne ne soit tenté d'en abuser plus tard.
Autre alternative raisonnable: permettre à l'utilisateur de remplacer l'EK d'origine par une EK prise au hasard dans un pool partagé. Ca aurait les mêmes avantages et inconvénients que le mécanisme d'attestation anonyme (DAA).
AC
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 2.
Non je ne mélange rien, l'EK créé par le constructeur est obtenu après la certification du matériel par audit du TCG ou d'un groupe indépendant et la certification du fournisseur que c'ets bien une puce TCPA. C'est rigoureusement l'équivalent des certificats racines que l'on trouve dans les navigateurs, ils sont livrés de base parcequ'il est très complexe d'établir une chaine de confiance vis à vis de l'extérieur soi-même. Pour certifier soi-même verisign par exemple il faut se déplacer chez Verisign en personne, ou dans un organisme de confiance qui certifie verisign. Dans le cadre de TCPA il faudrait faire auditer la puce, la faire certifier, faire auditer son TCPA et le faire certifier soi-même. Un peu long et complexe comme manip non ?
OK, sauf que je ne suis pas certain que mes clés permettent de faire la même chose que EK+AIK dans le scénario du réseau d'entreprise.
Il n'y a absolument pas besoin de EK pour générer des AIK. Un AIK est uen clef associée a un PCR ou à un ensemble de PCR. Si j'ai généré l'AIK moi même (ce qui est le cas en réseau d'entreprise), il me suffit de noter la clef public dans un coin moi même pour avoir un degré de certification égal à celui que j'aurais via EK. Le problème étant qu'il faut que je me fasse confiance à moi même (ce quid an sle cadre d'une grosse entreprise avec plusieurs intervenants n'est pas forcément aussi simple que ça)
Bon, on tourne en rond. Pour avancer, il suffirait que l'EFF ou la CNIL implémente une démo d'infrastructure DRM bien méchante à base de TCPA,
juste pour montrer à tout le monde que c'est possible et que ça peut faire mal.
Honnêtement j'ai demandé à plusieurs intervenants de divers mailing lists de faire cette implémentation, et j'ai essayé de la créer moi même. Ca fait deux ans que je m'acharne et que je provoque des gens plus doués que moi. Sans résultat.
Encore une fois, il vaudrait mieux pouvoir désactiver EK (sinon TPM_ForceClear suffit à la réactiver), pour que personne ne soit tenté d'en abuser plus tard.
TPM_ForceClear est un reset forcé de la puce pour une personne ne connaissant pas le secret owner. Quand on fait une requète TPM_ForceClear, le pc doit être rebooté. Au reboot le bios TPM charge uniquement l'OS TPM, toutes les fonctions réseaux/bus extérieurs sont désactivées pour assurer la présence physique de l'intervenant sur le PC. L'intervenant doit alors confirmer qu'il veut faire un reset de la puce, laquelle puce se retrouve alors dans le mode par défaut : pas de owner, 0 clef stoquée,toutes fonctions désactivées sauf "take ownership". Très difficile de faire celà "en douce"
Autre alternative raisonnable: permettre à l'utilisateur de remplacer l'EK d'origine par une EK prise au hasard dans un pool partagé. Ca aurait les mêmes avantages et inconvénients que le mécanisme d'attestation anonyme (DAA).
Ca aurait un autre gors inconvennient : comment s'assurer que la requète "prendre uen clef au hasard dans le pool" a bien été faite à partir d'une puce TCPA et non par un émulateur.
Si il faut un EK valide pour accéder un nouvel EK alors on peut toujours se servir des méccanismes de tracabilité (vu que j'aurais été obligé de donner pubEK pour changer d'EK). Si il n'y a pas besoin d'EK (et donc même pas besoin de owner sur la puce) n'importe quel émulateur peut faire la requète et se retrouver certifié comme un TPM valide...
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 2.
Dans ton message précédent, au sujet de la certification, tu parlais à la fois de la certification de la signature EK du constructeur, et de l'attestation ("Si tu n'as pas besoin de certifier la véracité de ton identité au reste du monde, créé un clef dans le PCR public.").
Dans le premier cas, c'est le constructeur qui prouve son identité. Le tiers de confiance est une bête autorité de certification, c'est classique.
Dans le second cas, c'est l'utilisateur qui prouve que son PC est "digne de confiance". Les whitepapers du TCG disent explicitement que le tiers de confiance jour un rôle un peu nouveau ("privacy CA").
Si j'ai généré l'AIK moi même (ce qui est le cas en réseau d'entreprise), il me suffit de noter la clef public dans un coin moi même pour avoir un degré de certification égal à celui que j'aurais via EK.
En effet TPM_MakeIdentity a l'air indépendant de TPM_ActivateIdentity. Ca me plait. Mais techniquement, pour que l'administrateur puisse faire tout ça à distance de façon sûre, on a besoin de EK (rien que pour le TPM_TakeOwnership initial).
Le problème étant qu'il faut que je me fasse confiance à moi même
Pour ça il suffit que l'entreprise ait un service "privacy CA" de confiance, et là on lierait les AIK à EK. Et ça ne me choquerait pas: ça a clairement des avantages pour la sécurité. Ce qui me choque, c'est que le TCG ajoute des fonctions et impose des restrictions qui trahissent l'intention de faire du DRM. Par exemple:
- Pourquoi prévoir un mécanisme d'attestation qui permet de rassurer non seulement le Owner, mais aussi un tiers inquisiteur quelconque ?
- Pourquoi se donner la peine d'anonymiser les AIK à l'aide d'une "privacy CA", si ce n'est pour faire du DRM sans violer les lois européennes sur la vie privée ? Pour les applications personnelles et en entreprise, l'anonymisation des AIK ne sert à rien.
- Pourquoi empêcher le Owner de connaitre le PrivEK de son TPM ? (réponse: ça lui permettrait d'émuler le TPM en logiciel et de contourner le DRM). OK, ça complique un peu le changement de Owner (le constructeur fournirait un nouveau EK certifié, ça peut se faire à distance).
- De même, pourquoi empêcher le Owner de connaitre la partie privée de SRK ? (réponse: en gros, ça lui permettrait d'extraire ou de migrer des clés nécessaires pour déchiffrer des contenus DRM).
Si il faut un EK valide pour accéder un nouvel EK alors on peut toujours se servir des méccanismes de tracabilité
Je donne mon PubEK, le constructeur me renvoie 10000 blobs contenant chacun un des PrivEK partagés chiffré avec mon PubEK, j'en choisis un et je l'envoie à mon TPM. Ca règle le problème de traçabilité.
Le vrai inconvénient est qu'il faut faire compromis entre le niveau d'anonymat et les dégâts en cas de compromission physique d'un TPM.
et j'ai essayé de la créer moi même. Ca fait deux ans que je m'acharne
Ah ben voilà, ton boulot chez Vivendi, c'est réussir à implémenter du DRM sur TCPA !!! :-)
AC
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 2.
Oui, mais c'ets normal. Si je ne susi pas présent physiquement sur la machine, qu'est-ce qui m'assure que c'est bien ma puce TCPA que je viens d'acheter et pas un petit malin qui s'est mis au milieu pour gagner des droits sur le réseau ? Si le PubEK m'a été transmis par le constructeur en même temps que le PC a été livré c'est très simple, sinon c'est impossible sauf à se déplacer.
Ensuite uen fois fait le takeOwnership je peux tranquillement désactiver GetPubEK.
Pourquoi prévoir un mécanisme d'attestation qui permet de rassurer non seulement le Owner, mais aussi un tiers inquisiteur quelconque ?
CF exemple précédent. L'acheteur du PC vérifie qu'ile st ebien en train de dialoguer avec le PC qu'il a acheté, même si il ne l'a pas initialisé lui même.
Pourquoi se donner la peine d'anonymiser les AIK à l'aide d'une "privacy CA", si ce n'est pour faire du DRM sans violer les lois européennes sur la vie privée ? Pour les applications personnelles et en entreprise, l'anonymisation des AIK ne sert à rien.
Pour éviter les recoupements. Si je n'utilsie qu'un seul identifiant, un fournisseur de mêche avec le tiers certifiant pourrait remonter mes habitudes. En créant un certificat par profil/service/fournisseur je rend la tache de tracage impossible. En prime, je peux déplacer mon "Privacy CA" d'un AIK à un autre, pour le DRM c'est un poil pataud...
Pourquoi empêcher le Owner de connaitre le PrivEK de son TPM ? (réponse: ça lui permettrait d'émuler le TPM en logiciel et de contourner le DRM).
Le but du PrivEK ets de certifier que l'on a bien affaire au TPM auquel on pense avoir à faire, et à s'assurer que celui ci n'a pas été compromis. Si on pouvait le sortir l'ensemble de la sécurité du TPM s'éffondrerait. En plus pour contourner le DRM il suffirait de booter dans une autre config, avec un autre logiciel vi que PrivEK est TOUJOURS challengeable, quel que soit les PCR et même si il n'y a pas de owner. On retombe donc dans un bête schéma de protection logiciel.
De même, pourquoi empêcher le Owner de connaitre la partie privée de SRK ? (réponse: en gros, ça lui permettrait d'extraire ou de migrer des clés nécessaires pour déchiffrer des contenus DRM).
Toutes les clefs challengeables de l'extérieur (ie extérieur du TPM) sont déplaceable et copiable à l'intérieur du TPM et vers d'autres TPM. Une fois de plsu comme protection DRM ca fait très léger. PrivSRK ne touche que les clefs internes, lesquelles sont utilisés par le TPM (au sens OS) pour sa cuisine interne. Elle ne sont pas challengeables et donc inutilisables pour le DRM.
Je donne mon PubEK, le constructeur me renvoie 10000 blobs contenant chacun un des PrivEK partagés chiffré avec mon PubEK, j'en choisis un et je l'envoie à mon TPM. Ca règle le problème de traçabilité.
sauf que a) Le constructeur est obligé de me fournir 10000 blobs uniques, sous peine que je choisisse une PrivEK qui a déjà été choisie par quelqu'un d'autre, ce qui serait assez désordre, donc la tracbilité reste. De plus rien ne prouve à mon constructeur que je ne vais utiliser qu'une seule des clefs, je pourrais par exemple garder le blob 127 pour mon tpm et challenger le blob 142 pour récupérer la clef PrivEK142 en clair et l'utiliser dans un émulateur...
Mon constructeur se retrouverait alors à avoir certifié un émulateur. Pas top non plus.
Ah ben voilà, ton boulot chez Vivendi, c'est réussir à implémenter du DRM sur TCPA !!! :-)
Deux ans payé plein pot pour ne rien produire \o/ J'aimerais bien, mais c'est pas le cas.
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 2.
Dans le scénario en entreprise, je n'ai pas besoin de tiers certifiant, tu l'as dit toi même. Les "fournisseurs" dont tu parles sont précisément les gens qui veulent faire du DRM et contrôler ce qu'il se passe dans le réseau de l'entreprise.
En plus pour contourner le DRM il suffirait de booter dans une autre config, avec un autre logiciel vi que PrivEK est TOUJOURS challengeable
Donc tu confirmes que si le TCG interdit qu'on puisse sortir PrivEK, c'est pour qu'on ne puisse pas contourner le DRM ?
Toutes les clefs challengeables de l'extérieur (ie extérieur du TPM) sont déplaceable et copiable à l'intérieur du TPM et vers d'autres TPM.
Je n'en suis pas convaincu. J'ai l'impression que TPM_Seal et/ou TPM_Bind et/ou TPM_CreateWrapKey permettent de créer des clés non migrables.
Sans parler des AIK qui sont challengeables et évidemment pas migrable.
D'ailleurs c'est une bonne chose qu'on puisse créer des clés qui ne sortiront jamais du TPM (sauf assistance du constructeur). Je serais ravi d'utiliser ça pour stocker la clé privée de mon serveur SSL. Si le chip crame, ce n'est pas pire que quand mon certificat expire.
Le constructeur est obligé de me fournir 10000 blobs uniques
Non, je proposais bien qu'il y ait 10000 clés EK partagées par tous les TPM du monde. En effet ça fait un peu désordre, mais ce n'est pas si dramatique que ça, sauf pour le DRM. Le DAA zero-knowledge est encore mieux, évidemment.
je pourrais par exemple garder le blob 127 pour mon tpm et challenger le blob 142 pour récupérer la clef PrivEK142 en clair et l'utiliser dans un émulateur
Non, le constructeur te fournirait PrivEK142 chiffrée avec ton PubEK certifié, donc seul ton TPM pourrait l'avoir en clair.
AC
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 2.
Si tu es en réseau entreprise tu fais comme tu veux. Tu peux déjà faire les recoupements toi-même de toute façon. Il est nettement plus simple d'aller mettre une clef dans le PCR qui nous interresse et de challenger cette clef pour s'asurer que tout va bien. Pas besoin de passer par des certificats. En entreprise l'EK ne sert à rien, autant le désactiver si on en a pas besoin. Celà ne limite en rien les utilisations du TPM (sauf si on veut faire un TakeOwnership à distance, ce qui est une opération qui se fait une fois pour toute le plus souvent.)
Donc tu confirmes que si le TCG interdit qu'on puisse sortir PrivEK, c'est pour qu'on ne puisse pas contourner le DRM ?
Non ce que je dis c'est
a) On ne peut pas sortir PrivEK parceque sinon ca ne certifirait plus rien et donc les gens qui ont besoin de PrivEK ne pourraient plus s'en servir (Par exemple pour faire un TakeOwnership à distance). Il est beaucoup plus raisonnable de laisser les gens qui n'en n'ont pas besoin le désactiver.
b) PrivEK n'ets pas utilisable en DRM vu qu'il est toujours accessible. Supposons un fichier DRM encrypté avec le PubEK d'un TPM. Quelque soit le boot de la machine sur lequel le TPM est présent je peux faire un challenge de ce fichier et obtenir la version en clair. l'EK ne sert qu'à prouver que le TPM peut décrypter un challenge envoyé sur PubEK. il n'est lié à aucun PCR, et il ne nécessite même pas que la manoeuvre TakeOwnership ait été faite. Faire une encryption d'un fichier sur PubEK revient à déposer le fichier en clair sur le poste, ce qui est très loin de la philosophie DRM.
En clair : EK a une vraie utilité et ne doit pas être supprimé et il est totalement inutilisable pour le DRM.
Je n'en suis pas convaincu. J'ai l'impression que TPM_Seal et/ou TPM_Bind et/ou TPM_CreateWrapKey permettent de créer des clés non migrables.
TPM_SEAL et TPM_BIND servent à créer des zones dans les PCR et le TPM pour ne donner l'accès à ces zones que si les PCR sont validés (ie identiques à ceux rencontrés lors de la pose du seal/du bind).
Ces clef ne sont pas challengeable de l'extérieur. De plus toutes les zones sealées/bindées peuevnt être libérées par les commandes TPM_unseal et TPM_unbind. Donc même si un logiciel s'amusait à mettre des clefs dans une zone sealé/bindé, le owner pourrait toujours repasser la zone en plubique... (Ou déplacer les clefs vers la zone publique au choix)
TPM_CreateWrapKey créé une clée (au choix signature (x)ou encrytption) et la lie (bind) à un PCR. C'est juste pour éviter d'avoir à faire les deux opérations l'une dérrière l'autre en laissant la clef publique quelques instant. Bien entendu la clef peut être déliée du PCR, copiée, migrée etc.
Sans parler des AIK qui sont challengeables et évidemment pas migrable.
Ah bon ? Les AIK sont non migrables ? Les PrivAIK sont migrables/copiables commes les autres clefs. Biens ur si je veux faire une authentification baséesur une clef AIK qui a été déplacée je vais me faire jeter. Par contre si mon but c'est de décrypter un fichier présent sur mon disque dur je n'aurais aucun problème.
Non, le constructeur te fournirait PrivEK142 chiffrée avec ton PubEK certifié, donc seul ton TPM pourrait l'avoir en clair.
Pas du tout. Si PrivEK142 est chiffré avec PubEK, je n'ai qu'à lancer un challenge à mon TPM contenant PrivEK142 chiffrée pour obtenir la clef PrivEK142 en clair. A partir de là, j'en fait ce que je veux.
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . Évalué à 2.
Oui mais là on ne parlait plus du certificat EK, on parlait de l'attestation semi-anonyme avec les AIK. Tu confirmes que la certification des AIK par le "privacy CA" ne sert à rien en entreprise ? Et qu'elle n'est donc utile que pour faire du DRM ?
On ne peut pas sortir PrivEK parceque sinon ca ne certifirait plus rien et donc les gens qui ont besoin de PrivEK ne pourraient plus s'en servir (Par exemple pour faire un TakeOwnership à distance).
Ca n'empêche pas de faire un TakeOwnership sécurisé. Evidemment, il ne faut pas donner PrivEK à l'utilisateur, mais seulement au propriétaire légal (celui qui va faire TakeOwnership à distance), et par un canal sécurisé. Principal inconvénient: en cas de revente du PC, le nouveau propriétaire ne peut pas faire confiance au TPM.
Donc même si un logiciel s'amusait à mettre des clefs dans une zone sealé/bindé, le owner pourrait toujours repasser la zone en plubique
Je crois plutôt que si Windows Media Player protège une clé de DRM avec TPM_SEAL, le TPM n'acceptera de la rendre en clair qu'à Windows Media Player, et si Windows Media Player n'a pas envie de la migrer, même le Owner ne pourra rien faire.
Les PrivAIK sont migrables/copiables commes les autres clefs.
Non. La définition dit "AIK: (...) an asymmetric key, the private portion of which is non-migratable and protected by the TPM"
(http://www.trustedcomputinggroup.org/downloads/TCG_Glossary.pdf(...) page 4).
Si PrivEK142 est chiffré avec PubEK, je n'ai qu'à lancer un challenge à mon TPM contenant PrivEK142 chiffrée pour obtenir la clef PrivEK142 en clair.
Le fait que EK soit challengeable ne veut pas dire que le TPM va déchiffrer n'importe quoi et renvoyer le résultat en clair. Par exemple, en réponse à TPM_TakeOwnership, le TPM prouve qu'il a bien déchiffré le secret du Owner (et donc qu'il connait PrivEK), mais sans renvoyer ce secret en clair. Voir le champ resAuth dans la spec TPM Part 3 Commands.
AC
[^] # Re: On va se répéter uen dernière fois
Posté par boubou (site web personnel) . Évalué à 5.
Quand on lit tes messages sur TCPA, on a l'impression que tu t'es énormément documenté sur le sujet, voire que c'est plus ou moins lié à ton boulot. Mais quand tes contradicteurs interpretent la norme différamment de toi, je ne sais pas trop quoi penser. Peut être que c'est naïf, mais j'ai l'impression que si j'en savais un minimum sur toi (et sur tes contradicteurs), j'aurais plus d'"arguments" pour décider qui a raison ou tort.
Tu me diras qu'on ne sait pas grand chose sur notre ami pasbill et qu'il a quand même réussi à convaincre certains (dont moi) qu'il bossait effectivement chez MS. Moralité, quand il raconte quelque chose sur le noyau de Windows, j'ai tendance à lire attentivement. Si ça se trouve, c'est un pur imposteur. D'autre part, il est possible que je sois le seul à n'avoir aucune idée de qui tu es et de ce que tu fais...
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 8.
A l'heure actuelle je m'occupe de choses diverses au sein de l'équipe applicative de Vivendi Universal HQ (Dont on peut penser plein de choses, mais qui n'ont pas non plus d'intérets financiers direct dans TPM, même si la branche musique dont je ne susi pas lorgne violamment sur les DRM)
Au cours de ma vie j'ai fait de la crypto à haute dose (Stage avec l'université d'Evry sur l'inversibilité des multiplications via translations de base) et pas mal d'electronique (Mise au point d'une imprimante et d'un terminal braille pour aveugle).
Je suis un touche à tout (bon, OK surtout une grande gueule qui a du mal à rester longtemps dans la même boite) et plutôt pas mal paranoiaque quand ca m'amuse (Mon OpenBSD est une forteresse, même moi je ne rentre dessus qu'une fois sur trois)
Mon intéret pour TPM est celui d'un amateur ave cune bonne base technique, mais pas celui d'un chercheur ou d'un ingénieur de haut niveau sur le sujet. Par contre je peux être très casse pied quand j'ai besoin de connaitre quelque chose, et il y a pas mal de réceptionnistes à qui "Bonjour, c'est Monsieur Jérôme Herman" doit encore donner des sueurs froides.
Pour les specs TCPA je les ai lu (3x300+ pages, merci) et c'est pas très complexe à comprendre (la partie "haut niveau" est laissée à la discretion des fondeurs). Mais quand j'ai un doute je téléphone directement aux gens concernés pour poser des questions.
Voilà. A toi de te faire ton idée.
[^] # Re: On va se répéter uen dernière fois
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 2.
Calomnies ! Je n'ai jamais entouré mon écran de papier alu ! C'est la tête qu'il faut entourer pour se protéger des rayons nocifs des extra-terrestres.
Non il y a une antenne en papier alu à coté de mon écran. Ca suffit et ca génère toujours des conversations sympas quand les gens viennent chez moi.
[^] # Re: On va se répéter uen dernière fois
Posté par boubou (site web personnel) . Évalué à 1.
Et c'est vrai que ça suffit ?
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 4.
Aucun agent du FBI n'est venu chez moi jusqu'à présent.
Plus sérieusement ca génère une reflection assez casse pied à filtrer, c'est faisable mais c'est pas "immédiat". Ca apporte un vrai plus si le but est effectivement de se protéger contre le piratage industriel.
L'idéal pour pas beaucoup plus cher c'est d'avoir une mini soufflerie qui déplace des bouts de papiers alu dans un "aquarium" pas très loin de ton PC. Là la protection contre le rayonnement est quasiment aussi bonne que celle offerte par une cage de faraday complète, non pas que le signal est bloqué, mais qu'il est perturbé par des réflections qu'on peut considérer comme aléatoires (Et le premier qui me dit que le mouvement de particules planes dans un flux d'air est un mouvement chaotique brownien pas du tout aléatoire, il en prend une).
[^] # Re: On va se répéter uen dernière fois
Posté par briaeros007 . Évalué à 2.
aïe pas la tete pas la tete.
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 2.
Vas-y sort moi l'équation complète du mouvement de chaque morceau déchirré à la main, le tout tournant dans un souflerie alimentés apr des turbines 12v mal lissé par un transfo bas de gamme alimenté par du 220v pas filtré.
Allez vas-y ! Je t'attend !
(N.B : Le truc c'est que si tu fais des réseaux de neurones à longueur de journée, tu es peut-être capable de la faire génere l'équation, au moins sur un temps court.)
[^] # Re: On va se répéter uen dernière fois
Posté par boubou (site web personnel) . Évalué à 3.
Sans vouloir faire ma tête de con, le mouvement brownien, au sens mathématique du terme, c'est nécessairement aléatoire. Donc mouvement brownien pas du tout aléatoire, ça n'a pas de sens...
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . Évalué à 2.
Par expemple pendant les migrations les hirondelles ont un mouvement brownien (donc aléatoire, donc imprédictible), mais pourtant elles vont toutes vers le sud, et en plus souvent dans le même régions (donc pas aléatoire du tout et carrément prédictible). Après il y a toute la théorie stochastique qui déboule, les notions de prévisibilité et de prévisibilité encadrée. La notion de risque et d'évènement energétiquement improbable et tout le toutim.
Comme disait mon prof, on va considérer que le mouvement est "suffisament" complètement aléatoire.
[^] # Re: On va se répéter uen dernière fois
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
Si tu veux m'en mettre une, j'habite a Villejuif.
[^] # Re: On va se répéter uen dernière fois
Posté par encre (site web personnel) . Évalué à 1.
http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...)
# Et encore une couche
Posté par Matthieu Weber . Évalué à 10.
En direct de formats-ouverts.org:
Pareil pour l'audio.
Source: http://formats-ouverts.org/blog/2005/08/15/494-vous-devez-utiliser-(...)
[^] # Re: Et encore une couche
Posté par arma . Évalué à 10.
Personne ne trouve ça inquiétant? En poussant encore un peu plus loin, cela menace la liberté d'expression.
Comme le gouvernement chinois a contraint microsoft, google, yahoo, etc d'interdire les recherches ou les créations de blogs contenants des mots jugés 'illicites' comme : 'liberté d'expression', 'démocratie', ...
Qu'est ce qui empêche un tel gouvernement d'obliger microsoft à bloquer ces mots au niveau même de l'ordinateur d'un tier.
Tu es petit chinois et tu désires écrire un texte avec un contenu 'démocratique' ... Tu le sauvegardes, ce fichier t'appartient (c'est toi qui l'a créé) mais tu n'as pas le droit de le lire ou de le diffuser dans ton pays car chaque ordinateur refusera de lire un tel fichier.
à méditer...
[^] # Re: Et encore une couche
Posté par kowalsky . Évalué à 2.
yahoo, etc d'interdire les recherches ou les créations de blogs
contenants des mots jugés 'illicites' comme : 'liberté d'expression',
'démocratie', ...
Heu je ne remets pas es dires en cause, mais ça provient d'ou cette
affirmation, non pas que je ne te crois pas hein, mais je cherche des
sources concernant cette histoires, ça se trouve; c'est un peu comme
pour l'histoire de la censure d'"imagine" de lenon apres le 11 septembre...
[^] # Re: Et encore une couche
Posté par Barnabé . Évalué à 1.
http://yro.slashdot.org/article.pl?sid=05/06/17/1948223&tid=153(...)
http://yro.slashdot.org/article.pl?sid=04/09/22/0039208&tid=153(...)
# fais attention à Londres avec les caméras
Posté par Gniarf . Évalué à 1.
[^] # Re: fais attention à Londres avec les caméras
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: fais attention à Londres avec les caméras
Posté par Krunch (site web personnel) . Évalué à 2.
http://www.schneier.com/blog/archives/2005/08/shoot-to-kill_r.html(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: fais attention à Londres avec les caméras
Posté par doublehp (site web personnel) . Évalué à 2.
Genre j ai une bombe dans un petit carton postal ridicule, et je veux faire sauter la petite salle de cinema de Boulogne un vendredi soir en plein ete ...
Je me rappelle aussi qu on regardais bizarrement mon PC pose sur le quai du metro le dernier mardi de juillet, genre je vais faire 100 000 morts un mardi soir de fin juillet dans une station de metro ...
Ils otn reussi a faire tellement paniquer les gens, que les peuples ont meme oublie l interret des bombes: faire du bruit et des morts.
Bientot les militaires votn faire desactiver et deosser un colis suspect qui rest 24h devant l entree de la mairie de Trifouilli-les-bains en plein mois de mars, a une epoque ou le bled compte 47 habitants, en comptant les chats et les moutons.
[^] # Re: fais attention à Londres avec les caméras
Posté par briaeros007 . Évalué à 5.
[^] # Re: fais attention à Londres avec les caméras
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
[^] # Re: fais attention à Londres avec les caméras
Posté par Sebastien (site web personnel) . Évalué à 1.
[^] # Re: fais attention à Londres avec les caméras
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: fais attention à Londres avec les caméras
Posté par doublehp (site web personnel) . Évalué à 2.
Et encore, pour la TV, tu paye une redevance ...
Et malgres que tu paye, et que sur la TV il y a des chaines publiques, tu n a psa le droit de redistribuer tes enregistrements, ni meme te poser ta TV sur une fenetre pour montrer l image dehors.
Ton billet de cine te donne droit a voire une oeuvre; si tu relis la copie privee, elle ne peut pas s y appliquer.
C est la loi.
[^] # Re: fais attention à Londres avec les caméras
Posté par briaeros007 . Évalué à 1.
Ne pas tout confondre; la redevance est pour payer les chaines publiques ; pas privees.
de plus
Ton billet de cine te donne droit a voire une oeuvre; si tu relis la copie privee, elle ne peut pas s y appliquer.
C est la loi.
je ne vois pas ca dans "la loi" :
si j'en crois l'article l122-5 du code de la propriete intellectelle
Les deux exceptions concernent les copies d'oeuvres d'art utilise a des fins identiques de l'originales; et la copie des logiciels autres que celle de sauvegardes.
reste a voir que si les films sont des "oeuvres d'arts" et que la copie cherche une fin identique a l'originale (quelle est la fin d'un film dans une salle de cine ? faire de l'audience? etre diffuse au plus grand nombre? ...)
# Et les bières-sondes
Posté par jerome (site web personnel) . Évalué à 5.
Enfin, pour le consommateur, le constat est terrifiant : l'âpre surprise d'avaler une goulée d'eau en place de la bière attendue. En même temps, ça change pas beaucoup de la kro'.
À noter que cette pratique a été initiée par Danone, pour les yahourts (il me semble), suivi ensuite par d'autres entreprises de l'agro-alimentaire ...
[^] # Re: Et les bières-sondes
Posté par astennu . Évalué à 5.
"le constat est terrifiant : l'âpre surprise d'avaler une goulée d'eau en place de la bière attendue."
C'est vrai que c'est la pire des tortures pour un buveur de bière ...
[^] # Re: Et les bières-sondes
Posté par Pierre Tramonson . Évalué à 1.
Ils mettaient du sperme dans le yahourt ?
[^] # Re: Et les bières-sondes
Posté par Pelt . Évalué à 8.
[^] # Re: Et les bières-sondes
Posté par Wawet76 . Évalué à 4.
Ils ont la forme et le poids des produits suivis histoire d'être transportés de la même façon, mais en général on les distingue au premier coup d'oeil.
J'avais vu il y a longtemps un reportage sur un tel capteur utilisé pour voir si les cageots de pêches n'étaient pas trop secoués pendant le transport.
La principale utilisation doit être le contrôle de la chaîne du froid.
[^] # Re: Et les bières-sondes
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
[^] # Très bonne idée !
Posté par thom_ra . Évalué à 3.
Attention : je n'ai pas dit que ça empêche d'être "malade" ;-)
[^] # Re: Et les bières-sondes
Posté par Sebastien (site web personnel) . Évalué à 1.
# à déposer
Posté par KaZeKaMi (site web personnel) . Évalué à 6.
il me semblait dans ce cas là qu'on appelait ça du courrier postal plutôt...
------> [] (sur la pointe des pieds)
[^] # Re: à déposer
Posté par Tony Flow . Évalué à 1.
en tout cas c'est sur que si on est un poil parano et qu'on veut etre tranquille, avec tout ça il n'y a plus qu'à aller vivre dans une grotte !
# Paranoïte aigue ... et justifiée ... ?
Posté par Taku . Évalué à 2.
De plus, le GnuPG a beau être *sur*, quand on voit la puissance de calcul des machines dont dispose la N.S.A., je doute que tes protections durent très longtemps.
Enfin bon ce que j'en dis ...
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par briaeros007 . Évalué à 3.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par doublehp (site web personnel) . Évalué à 1.
ben, c est 1024 bits ...
soit 2^1024 ...
donc meme avec une cle 256, on avait deja 256>100 ...
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par briaeros007 . Évalué à 3.
Sachant que la norme de securite actuelle est a 2^80 et que une cle 1024 bits <=> 2^80 operations pour reussir a retrouver les facteurs.
tu peut me le redire le " heu ... tu sais ce qeu veut dire 1024 ?" ?
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par doublehp (site web personnel) . Évalué à 2.
il trouve un nomrbe premier tous les 4 calculs ... et le rythme reste constant jusqu au plus grand nombre supporte, qui si je me souviens bien est un nombre ayant pour taille 10% de la RAM disponible ...
aka si tu as 4Go de ram, il calcule en un temps record tous les nombres premiers jusqu a... 2^2^28 = 2^ 268435456
il te reste a diviser la cle publique par chacun des nombres obtenus.
Son probleme, c est que des qu on depasse 2^256, les processeusr ne savent plus manipuler en direct, meme avec le processeurs vectoriels ... il faut alors decouper le nombre en sous entiers, ce qui ralenti tout.
Sa methode, au lieu de varifier la primalite d un nomrbe, ou de generer des nombres probablement premiers, il a reussi a ecrire un programme qui genere directement la suite des nombres premiers (ce qui n est pas formalisable par une suite mahtematique ordinaire, mais via un progrmme oui).
Ca necessite etude et tests, mais sa theorie me paraissait bonne.
du coup, tu obtiens immediatement un par un tous les nombres premiers ... chose que personne n avais pu avoir avant.
certes pour caser du RSA, il reste a tester CHACUN de ces nombres, mais la on obtiens tous les nombres premiers, et seulement eux. Et comme son programme analyse aussi la quantite de nombres premiers par decade, tu peux en temps reel tracer la courbe du nombre d operations restantes.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par briaeros007 . Évalué à 1.
"il te reste a diviser la cle publique par chacun des nombres obtenus."
plus facile a dire qu'a faire...
tu dis que ton majorant de tes nombres premiers c'est :
2^ 268435456
d'apres le theoreme des nombres premiers on a approximativement
2^ 268435456 / ln (2^ 268435456) nombre premiers inferieur a 2^268435456
Je pense qu'il te faudrais plus que 4Go pour les stocker :-D
"Et comme son programme analyse aussi la quantite de nombres premiers par decade, tu peux en temps reel tracer la courbe du nombre d operations restantes."
Tu en as pas une approximation par le theoreme des nombres premiers? enfin quand tu dis decade c'est bien de
passe de 0 à 10 ; puis de 10 à 20 puis de ... (ou alors de 10 à 100 si on suis une echelle logarithmique)
" il reste a tester CHACUN de ces nombres, mais la on obtiens tous les nombres premiers, et seulement eux. "
donc pour un nombre de n bits ; on doit
1°) creer le crible cad faire 4*n/2 operations (ca ne sert a rien de faire les nombres premiers plus grand que la moitie du nombre a chercher) (ouah il trouvent des nombres premiers en o(1) pas mal) (en realite c'est 4*n^1/2 ; chouette des dl pour simplifer le calcul :-D)
2°)faire une recherche qui prend n/2 *n (tous les nombres premiers divise avec le nombre qu'on cherche) Et ceci en suposant qu'on ait une division en n ce qui me semble fortement improbable (je pencherais plutot pour du n*ln(n) )
ce qui donne du n^2 (ou plutot du n^3/2 si on prend seulement les n^1/2 premiers entiers)
Le crible quadratique fait la factorisation en n ln (n) (a peu pres)
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par Krunch (site web personnel) . Évalué à 3.
Tu peux même t'arrêter à la racine carrée du nombre qu'on cherche à factoriser.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par briaeros007 . Évalué à 1.
ce que j'ai mis ici :
Pas besoin de les stocker. S'ils sont directement générés à la suite l'un de l'autre il suffit de vérifier à chaque fois si c'est un diviseur (ou bien en générer 16, les tester, en générer 16, les tester,...).
Effectivement je n'y avais pas pense
Avec ceci on a donc un compromis temps memoire: si on les stocke pas on arrive a du n^5/2 (si la division peut se faire en n ce dont j'ai de gros doute) ce qu est toujours superieur a du n*ln (n).
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par doublehp (site web personnel) . Évalué à 2.
donc fatalement, des nombres aussi drands, tu en stoque pas plus de 20 ...
mais j ai dit pouvoir gerer ... c est la toute l astuce de son idee: une fois que tu asutilise un petit nombre premier, tu en a plus besoin, donc tu l efface, ce qui fait un peu de place pour aller plus loin: une fois que tu as rempli ta RAM avec les petits nombres premiers, tu les traite, puis t en a plus besoin, alors tu les efface, et tu continues ...
l interret, c est qu il utilise pour generer la suite qu une dizaine de coefficients ... donc ca necessite peu de memoire pour gerer la chose.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par briaeros007 . Évalué à 1.
C'est le meme principe pour casser les mdp crypte de windows.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par boubou (site web personnel) . Évalué à 5.
Un programme est nécessairement un cas particulier d'une "suite mathématique ordinaire", comme tu dis. De plus, il existe des fonctions (extrêmement lentes) qui engendrent la liste des nombres premiers. Je te conseille la lecture de http://mathworld.wolfram.com/PrimeFormulas.html(...)
Ce qui est probable, c'est que ton pote a trouvé quelque chose qui marche pour quelques nombres premiers, car il a été démontré, il y a bien longtemps, qu'il n'était pas possible de construire une fonction qui calcule efficacement tous les nombres premiers (cf http://mathworld.wolfram.com/Prime-GeneratingPolynomial.html(...) ).
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par schyzomarijks . Évalué à 10.
La NSA est en train de se consituter une base d'empreinte et de photo titanesque. En effet, la douane te prend en photo ainsi que tes empreintes lors de ton arrivé au US.
Et c'est sans compter les mormonts qui se font fort de collecter l'ensemble des états civils mondiaux. http://www.unadfi.com/actualite/themes/mormons.htm(...)
Bref, on est pisté, analysé, catégorisé, répertorié dans tout les sens. Que ce soit la police, les marketteux, les religieux, les mafieux... Ils me veulent TOUS du mal.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par Mildred (site web personnel) . Évalué à 1.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par coujou . Évalué à 3.
Ca me rapelle un truc que j'avais lu dans le monde diplo ( http://www.monde-diplomatique.fr/2003/08/RAMONET/10252(...) ). J'imagine qu'ils ont pas fait marche arriere depuis. J'aime surtout (façon de parler) le concept de Total Information Awareness.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par Antoine . Évalué à 1.
Une autre possibilité, c'est les implants.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par Dalton joe . Évalué à 4.
Il ont des noyaux Linux dont les version sont 10 ans supèrieur? c'est fou... ils doivent avoir le Hurd en version de prod alors et pour Windows j'imagine même pas.
Je ne savais pas que Wikipédia avait des informateurs à la NSA.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par Krunch (site web personnel) . Évalué à 5.
Il me semble qu'une observation similaire a été faite avec DES ou 3DES mais la différence était de 15 ans (? je retrouve rien la dessus pour le moment mais en tout cas c'était plus).
http://fr.wikipedia.org/wiki/SHA-0(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par Krunch (site web personnel) . Évalué à 2.
http://en.wikipedia.org/wiki/DES#NSA.27s_involvement_in_the_design(...)
Tout ça pour dire que la NSA a sans doute toujours de l'avance mais que l'écart semble se réduit.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Paranoïte aigue ... et justifiée ... ?
Posté par ArBaDaCarBa . Évalué à 5.
# News de première page
Posté par lloyds . Évalué à 1.
Je la verrais mieux en journal mais bon une deuxième page serait déja amplement suffisant non?
[^] # Re: News de première page
Posté par vrm (site web personnel) . Évalué à 6.
2) c'est posté par un modo, alors ca doit aider pour faire passer les billet d'humeur ;)
[^] # Re: News de première page
Posté par Thomas Petazzoni (site web personnel) . Évalué à 10.
Essaie de faire passer un billet d'humeur aussi bien rédigé, avec autant de liens, sur un sujet aussi pertinent... et tu verras que le fait que l'auteur soit modéro ne change rien.
[^] # Re: News de première page
Posté par djibb (site web personnel) . Évalué à 5.
[^] # Re: News de première page
Posté par tene . Évalué à 7.
:p
ps: vous n'avez pas lu ce message, il n'existe pas...
[^] # Re: News de première page
Posté par TImaniac (site web personnel) . Évalué à 5.
Ensuite il y a une section Humeur dans les depêches de LinuxFR, ce type d'article peut donc tout à fait être pris en compte.
Ensuite dans les journaux on peut parler de tout et n'importe quoi (c'est d'ailleur un de leur but : parler d'autre chose que de Linux et plus généralement de l'informatique). Là en l'occurence on a un parfait article d'humeur qui concerne l'informatique et les logiciels libres.
Quand à savoir pourquoi c'est en première page : c'est bien écrit, agréable à lire, et surtout cela fait une synthèse de nombreuses préocupations avec à chaque fois un lien permettant d'approfondir la lecture. Bref, c'est intéressant et les modos ont estimés que cela méritait d'être mis en avant.
[^] # Re: News de première page
Posté par Zenitram (site web personnel) . Évalué à 5.
Qu'il soit modo ou pas ne doit pas changer grand chose au fait que c'est un article de qualité, et une bonne base pour se renseigner sur le sujet.
# Dependance
Posté par izulium . Évalué à 1.
Je pense que notre dependance des multinationales n'est plus a prouver. Elles dirigent une bonne partie de nos actions et influent sur notre facon de penser, nous incitent a consommer ... j'ai parfois l'impression de vivre et d'evoluer dans le monde de 1984 (G. O.). Nous participons au systeme ... Ou va t'il nous conduire ? La securite est devenue de nos jours, le meilleur pretexe pour developper la surveillance de la population et l'economie.
(Dsl pr les accents - QWERTY)
IzuliuM
[^] # Re: Dependance
Posté par Yves Martin . Évalué à 3.
Tu te vois cultiver tes légumes et pomper ton eau pour éviter de dépendre des multinationales de la distribution agro-alimentaire ?
Et pédaler pour faire tourner ton ordinateur assemblé au fer à souder avec des lampes à vide de conception artisanale ;)
[^] # Re: Dependance
Posté par Zanton . Évalué à 5.
Avec un raisonnement comme le tien, on ne fait que subir ce que les autres décident.
Surtout qu'accessoirement, l'eau de mon robinet n'appartient pas encore à Danone et que tu peux aller sur le marché si tu veux des légumes. Tu es libre de choisir ta dépendance.
[^] # Re: Dependance
Posté par DLFP est mort . Évalué à 0.
Ce qui n'est pas le cas avec les services accaparés par l'Etat.
La securite est devenue de nos jours, le meilleur pretexe pour developper la surveillance de la population et l'economie.
Ca ne serait justement pas l'Etat et non pas les multinationales (et en quoi serait-ce lié à leur caractère multinational ? qu'est-ce que ça change si l'entreprise est nationale ?), qui intervient dans toujours plus de domaines "pour notre bien" ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Et Tor ?
Posté par agmk . Évalué à 5.
[^] # Re: Et Tor ?
Posté par krumtrash . Évalué à 0.
Je teste...
[^] # Re: Et Tor ?
Posté par Olivier Tigro . Évalué à 0.
Ai-je le droit (moral) de brouiller les pistes pour transferer mes règles de firewall, de la musique ou mes photos, en employant pour cela des moyens d'ordinaire réservés aux espions ?
A mon avis, si TOR est immoral, PGP l'est aussi, mais cela ne règle pas la question...
# Mouais...
Posté par drcanard . Évalué à 10.
Les gens dénoncent le tout sécuritaire et pourtant n'hésitent pas à pousser à la limite de la desinformation l'argument de sécurité en tant qu'argument principal quand ils font la promotion de logiciels libres (Linux, Firefox, ...).
Les gens veulent avoir le droit de ne pas être dérangés par des chieurs et pourtant font tout pour être joignables 24/24 7/7 (mobile, IM, ...).
Avant de dénoncer ou d'améliorer quoi que ce soit, il serait peut-être bon de savoir ce qu'on veut...
[^] # Re: Mouais...
Posté par vrm (site web personnel) . Évalué à 4.
[^] # Re: Mouais...
Posté par drcanard . Évalué à 8.
Le battage intensif qu'il y a eu il y a quelques mois sur Firefox/IE, avec la toile présentée comme "la zone" infestée de spywares, virus et autres créatures de Satan, est à mon avis un exemple bien parlant.
PS : J'adore Firefox et je n'utilise que ça, mais bon, y'a des limites.
[^] # Re: Mouais...
Posté par TImaniac (site web personnel) . Évalué à 7.
Les gens contrôlent ce qu'ils disent plutôt que d'être contrôlés à leur insu.
Les gens dénoncent le tout sécuritaire et pourtant n'hésitent pas à pousser à la limite de la desinformation l'argument de sécurité en tant qu'argument principal quand ils font la promotion de logiciels libres (Linux, Firefox, ...).
Sécuriser sa vie privée n'est pas du tout pareil que "sécuriser" un CD du point de vu du consommateur. C'est pas parcque t'as le même mot qu'il faut y voir un paradoxe.
Les gens veulent avoir le droit de ne pas être dérangés par des chieurs et pourtant font tout pour être joignables 24/24 7/7
Là encore, à priori tu as filés ton numéro à des personnes de "confiance". Bref tu es maître de tes communications, et le processus est parfaitement identifié (signal d'appel, affichage de l'appelant, liberté de décroché), bref c'est pas du tout contradictoire avec la volonté de ne pas être dérangés par des spammeurs et autres démarcheages non sollicités.
Avant de dénoncer ou d'améliorer quoi que ce soit, il serait peut-être bon de savoir ce qu'on veut...
On veut "maîtriser" notre vie privée, décider nous même ce qu'on étaler ou pas.
[^] # Re: Mouais...
Posté par drcanard . Évalué à 1.
Tu prétends contrôler ce que tu dis, mais en contrôles-tu vraiment la portée ?
Si n'importe qui peut lire ton blog ou d'ailleurs tout texte de ta main mis en public sur la toile, tu ne peux pas empêcher qu'une personne malveillente en tire des informations sur ton compte, parfois en lisant entre les lignes, et les utilise contre toi. Il ne faut pas sous-estimer tout ce qu'on peut faire inconsciemment.
De plus, avec l'archivage, tu ne contrôles pas la portée dans le temps. On pourrait très bien dans 10 ans te ressortir quelque chose que tu as publié de ton plein gré et que, pour une raison ou pour une autre, tu aurais préféré que ça soit oublié.
[^] # Re: Mouais...
Posté par TImaniac (site web personnel) . Évalué à 3.
Ca c'est un tout autre débat, à chacun d'assumer ses actes.
Il ne faut pas sous-estimer tout ce qu'on peut faire inconsciemment.
Tu peux aussi raconter tout et surtout n'importe quoi sur ton blog. Là encore tu as toujours la liberté de te taire et de ne rien dire si tu es parano et que tu as peur que madame irma lise entre tes lignes. Mais tu es libre de publier sur ton blog ou non, libre d'y mettre des conneries ou non, tu prends des risques mais tu en es conscient.
Bref on parle ici d'assumer ses actes et paroles, pas du tout la même chose que le respect de la vie privée (où là tu n'es pas maître des informations que l'on divulge -vole- sur toi).
[^] # Re: Mouais...
Posté par Nicolas Schoonbroodt . Évalué à 1.
Mais ce que tu as rendu public de ton plein grès, je suis d'accord, il n'y a rien à dire, il faut assumer. Mais ici, ce serait de l'autre qu'on parle, amha.
[^] # Re: Mouais...
Posté par Pierre Tramonson . Évalué à -1.
Si vous ne supportez pas la pression d'une vie fortement soumise à l'influence de notre société, changez de société ou isolez vous loin du bruit et de la fureur des villes, personne n'ira vous scanner le cerveau pour savoir pourquoi vous avez 4 brebis et pas 3.
[^] # Re: Mouais...
Posté par Valdenaire Denis (site web personnel) . Évalué à 4.
l'influence de notre société, changez de société
Tout dépend de combien on est à pas le supporter. Parce qu'au bout d'un certain nombre, c'est pas nous qui dégageons. C'est la société, son bruit et sa fureur.
Le 't'es pas content tu dégages' n'est pas vraiment un argument en faveur de la liberté. Sinon, 'je suis pas content je fais tout sauter' en est un aussi...
[^] # Re: Mouais...
Posté par erik_lallemand . Évalué à 2.
Si vous ne supportez pas la pression d'une vie fortement soumise à l'influence de notre société, changez de société
je propose plutôt:
Si vous ne supportez pas la pression d'une vie fortement soumise à l'influence de notre société, changez la société ;o)
[^] # Re: Mouais...
Posté par Zenitram (site web personnel) . Évalué à 3.
Mais dans ce cas, est-ce que les jeunes "Karens" veulent eviter la modernité? C'est ca qui me fait bizarre dans tes propos, je traduis par le fait que la société veut garder un petit peuple en otarcie pour le plaisir, et ne demande pas aux jeunes ce qu'ils preferent.
Si les jeunes "Karens" preferent la vie moderne, pourquoi les empecher?
Ca me ferai penser a qu'on me dise "non, pas de TV, pas de machine a laver, fait tout a la main, j'aimerai garder un peu d'authenticité avec toi".
[^] # Re: Mouais...
Posté par erik_lallemand . Évalué à 2.
...mais je comprends que mon commentaire n'était pas 100% clair :P
[^] # Re: Mouais...
Posté par SuperDindon . Évalué à -1.
les gens craignent pour leur vie privée mais libres à eux de mettre à nu une partie de leur vie
les gens dénoncent le tout sécuritaire lorsque cette sécurité n'est pas dans leur intérêt, au contraire des logiciels comme Firefox offrent le moyen de garantir une sécurité avantageuse pour l'utilisateur
les gens veulent avoir le droit de ne pas être dérangés par des chieurs mais cela n'implique par forcément couper toute communication, il existe d'autres moyens pour en être épargnés ( justice, blacklists pour les IMs, .. ) sans avoir à abandonner leurs moyens de communications
[^] # Re: Mouais...
Posté par Valdenaire Denis (site web personnel) . Évalué à 3.
Sauf que... c'est peut etre pas leur vraie vie qu'ils mettent sur le blog... Et ça fait toute la différence...
>>Les gens dénoncent le tout sécuritaire
Promu par l'état, les institutions, les dominants de manière général
en opposition à la sécurité personnelle, promue par des individus, des associations de volontaires, des dominés en général...
>>Les gens veulent avoir le droit de ne pas être dérangés par des chieurs
Les chieurs : les publicitaires, les démarcheurs, etc...
>> être joignables 24/24 7/7
Par des amis et des parents. Qui normalement ne sont pas des chieurs (sinon faut leur dire, ils rappelleront plus).
>>il serait peut-être bon de savoir ce qu'on veut
Pouvoir choisir de ne pas avoir de laisse (!= choisir la couleur de la laisse.)
# Remarque sans importance
Posté par pifou . Évalué à 3.
Des lycéens de 12 ans !!! D'un autre coté il doit pas en y avoir beaucoup mais c'est peut être ceux là les mAIchants hackers/pirates (attention un troll c'est glissé insidieusement dans la phrase) qui font tant de mal à nos pauvres maisons de disque.
# Et les échographies ?
Posté par qdm . Évalué à 9.
Ce monsieur doit pas connaître (pourtant il est né en 1941). Et encore, on parle pas des nouvelles échographies 3D couleur. On est plus en sécurité nulle part, je vous le dis.
# les puces RFID dans les billets de 20 euros
Posté par aegirs (site web personnel) . Évalué à 1.
[^] # Re: les puces RFID dans les billets de 20 euros
Posté par Franck Yvonnet . Évalué à 5.
# autant être parano jusqu'au bout
Posté par Franck Yvonnet . Évalué à 3.
...avec des agents du gouvernement qui te présentaient de faux papiers.
# Grand jeu Le monde dans ton appart
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
2) La puissance de calcul nécessaire pour la reconnaissance faciale est maintenant à la portée du grand public.
3) Vous avez envie de faire comme à la télé, de voir des milliers de photos défiler super vite avant d'afficher un « Positive match 100% » sur une photo qui est pile poil celle du type recherché.
Lancez-vous dans le grand jeu « Le monde dans ton appart » : collecter les photos de l'ensemble des gens de la planète en récupérant toutes les vidéos et les images du net, en supprimant les doublons grâce à la reconnaissance faciale. Bien sûr, ça ne sert à rien, mais bon c'est quand même la plus chouette collection du monde, et ça fait super geek (plus besoin de sortir dehors, vous serez blasé).
# Oyster
Posté par Pooly (site web personnel) . Évalué à 7.
C'est personelle (tu donne ton adresse, ton petit nom pour l'avoir et même ta photo si tu veux un abonnement), mais surtout ce truc enregistre _tout_ tes recharges d'argents, et tout tes trajets (avec les heures)). Mr. le Maire veut également en faire un moyen de paiment électronique... pour payer le journal, le potde yaourt etc...
Et au prix du métro londonien (2£ le trajet en zone 1, 18FF ?) l'économie faite avec ce système (1.70£ letrajet en zone creuse, et le bus moins cher, etc), plus le fait que l'on ne peut acheter son billet dans le bus en zone 1 (pas le temps, trop de bouchon, achète à la machine en panne ou il faut de la monnaie sur le trottoir), s'en passer est un vrai luxe.
Bref, on est pas sur la bonne voie avec tout ça.
Le gros problème, c'est d'amener ces trucs petit à petit, pour endormir les craintes et faire passer la pillule. (petit métaphore : Plonge une grenouille dans l'eau bouillante, elle va se barrer _très_ vite, plonge là dans l'eau froide et fait chauffer, elle y reste ! le gradient de température est trop faible)
[^] # Re: Oyster
Posté par MistY . Évalué à 2.
# Dur à avaler
Posté par 桃白白 . Évalué à -1.
La rouge ou la bleue ?
[^] # Neo réveille toi
Posté par Mike_M . Évalué à 0.
Je prends la pillule rouge. Quand je repense à toutes ces machines connectés sur moi qui me manipulait et me prenait toute ma liberté...
# quote
Posté par ouah (site web personnel) . Évalué à 6.
La phrase n'est pas d'Einstein. Elle est attribuée à Golda Meir lors d'une discussion avec Kissinger durant la guerre du Kippour.
# La news de l'année ? On vote ?
Posté par Rafael (site web personnel) . Évalué à 1.
Ca s'impose quand on lit celle çi.
Je propose cette news au rang de news de l'année.
[^] # Re: La news de l'année ? On vote ?
Posté par psychoslave__ (site web personnel) . Évalué à -1.
Enfin vraiment je trouve ça marrant qu'on flipe autant pour des choses parreil, après tout, "ils" peuvent bien décortiquer ma vie de long en large si ça peut leur faire plaisir, et même écrire mon autro-biographie (attention je veux des parts tout de même XD ). Qu'est ce que vous voulez que ça me fasse? C'est pas le fait qu'on regarde ce que je fais qui m'empeche de faire ce qui me plait, non?
Si vraiment ils avaient de tels moyens, de connaitre les faits et gestes de chacun à tout moment, cela empecherais-t-il franchement chacun d'agir selon son bon vouloir?
Soyons honete, les hommes politiques ne laisserait pas passer des lois permetant de les utiliser: ils doivent pouvoir préserver le secret de toutes les saloperies qu'ils peuvent bien commetre, enfin au moins jusqu'a ce qu'ils aient trouvé le moyen de fabriquer un casque cebro-controleur XD
Halala, quand je pense que j'ai été obligé de m'identifier pour poster ce message, c'est clair, DLFP fait partit du "systeme" et cherche juste à reperer les élément dangereux pour la société... Arf, me voila fiché (encore?).
[^] # Re: La news de l'année ? On vote ?
Posté par a_caspis . Évalué à 3.
Cool. On peut venir mettre des caméras de surveillance chez toi, alors ?
Remarque, si tu n'as rien à cacher ni à protéger, pas même un numéro de carte de crédit, ou des infos qui pourraient intéresser ton assureur ou ton employeur, ou le plan stratégique du parti politique que tu es en train de fonder, c'est que tu dois être le type le plus inintéressant du monde, et je plains le vigile à qui on va confier ton dossier :-)
[^] # Re: La news de l'année ? On vote ?
Posté par Sylvain Sauvage . Évalué à 3.
Parce que passer sa vie à espionner un type inintéressant à espionner, c'est chiant, mais passer sa vie à espionner le type qui se fait chier à espionner le type qui est inintéressant à espionner, ça doit être bien plus chiant.
Et je parle pas du type qui espionne le type qui espionne le type qui
stack overflow¹
¹ : à moins d'avoir une récursion terminale, ce qui est possible vu qu'il n'y a rien à espionner...
[^] # Re: La news de l'année ? On vote ?
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
[^] # Re: La news de l'année ? On vote ?
Posté par fusible . Évalué à 2.
[^] # Re: La news de l'année ? On vote ?
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
[^] # Re: La news de l'année ? On vote ?
Posté par Nicolas Bernard (site web personnel) . Évalué à 3.
[^] # Re: La news de l'année ? On vote ?
Posté par fusible . Évalué à 2.
Merci pour le mot clé.
(*) Cryptonomicon de Neal Stephenson, pour ceux(**) qui ne connaissent pas.
(**) Il y en a?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.