Articles précédents : Humeur
- [7] [Café Philo] Le travail et le logiciel libre
- [55] La liberté, la face méconnue de l'informatique
- [54] De l'Open Source à l'Open Shore...
- [150] ESR : «Nous n'avons plus besoin de la GPL.»
- [59] Daniel Robbins rejoint Microsoft
- [107] Quelques réflexions autour des brevets logiciels
- [28] Une société choisit l'ERP Open Source Compiere.
- [16] Un ministre de l'Union Européenne à la radio ce soir
- [64] Télédéclaration française des revenus et logiciels libres
- [217] Ubuntu, un cauchemar pour la Debian ?
Humeur : Du respect de la vie privée et secrète du geek en milieu urbain
Posté par Benoît Sibaud (Jabber id, page perso, ). Modéré le 18 août 2005.
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)
> Lire les commentaires (173 commentaires, moyenne: 3,2).
On va se répéter uen dernière fois
TPM n'est pas dangereux (dans les normes 1.0, 1.1, 1.2 et 2.0). Il est inutilisable pour la tracabilité, les drm ou le blocage machine.
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.
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.
-
[^]Re: On va se répéter uen dernière fois
-
[^]Re: On va se répéter uen dernière fois
Posté par briaeros007 () le 18/08/2005 à 10:50. (lien). Évalué à 8.on en a deja discuter de ca :-D
tu dissure
; 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 .--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: On va se répéter une dernière fois
Posté par Jerome Herman () le 18/08/2005 à 12:08. (lien). Évalué à 4.Ne pas confondre la norme TCPA/TPM et els éventuelles implémentations.
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par briaeros007 () le 18/08/2005 à 12:59. (lien). Évalué à 4.Pour lire une 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.
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: On va se répéter une dernière fois
Posté par Jerome Herman () le 18/08/2005 à 13:20. (lien). Évalué à 1.Tu dis qu'il n'y a pas de rapport ensuite tu dis qu'il y en a un...
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 18/08/2005 à 23:00. (lien). Évalué à 3.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
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 () le 19/08/2005 à 08:15. (lien). Évalué à 4.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.
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 19/08/2005 à 10:14. (lien). Évalué à 4.Les duex TCPA se reconnaissent comme TCPA, le owner du TCPA à migrer certifie le TCPA migrateur dans son TCPA.
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 () le 19/08/2005 à 10:28. (lien). Évalué à 2.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é ?
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"--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 19/08/2005 à 11:07. (lien). Évalué à 2.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.
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".
Casser une clef symétrique 160 bits en sniffant des emissions "incohérentes"
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'idée de pouvoir migrer/copier mes clefs d'un TCPA à l'autre me plait : (...) c) parceque tant que cette fonction sera présente l'idée même du DRM sera risible
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).
Si je veux détruire mes clefs, je refais une prise de controle du ownership du TCPA.
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 () le 19/08/2005 à 11:43. (lien). Évalué à 3.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 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é)--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 19/08/2005 à 13:56. (lien). Évalué à 2.La procédure de maintenance complète n'est utile que dans le cas ou l'on veut récupérer aussi l'EK.
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 () le 19/08/2005 à 14:19. (lien). Évalué à 3.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).
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 19/08/2005 à 14:43. (lien). Évalué à 1.elles empêchent le forcage des coffres à clefs par tampering.
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 () le 19/08/2005 à 15:22. (lien). Évalué à 2.Tampering physique ? Ou déchiffrage des blobs externes
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 19/08/2005 à 16:39. (lien). Évalué à 3.Si le pirate a les moyens d'attaquer physiquement le TPM, il peut probablement extraire les clés non migrables en même temps que les données qui sont chiffrées avec. Bon, je veux bien croire qu'il y a des zones qui s'auto-détruisent mieux que les autres quand on démonte le chip.
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 (page perso, ) le 20/08/2005 à 12:36. (lien). Évalué à 3.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 ?"
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 () le 20/08/2005 à 22:08. (lien). Évalué à 3.ça fait des années que ça dure, tout gouvernement veut que ses petites affaires restent secrètres tout en se réservant le droit d'accéder aux tiennes si besoin est.
--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008
-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 20/08/2005 à 23:35. (lien). Évalué à 3.ce qui signifie qu il est illegale en france de realiser un module cryptographique hardware vraiment secure ?
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 () le 21/08/2005 à 11:08. (lien). Évalué à 2.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.
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 (Jabber id, page perso, ) le 21/08/2005 à 12:37. (lien). Évalué à 2.Dans du libre aussi tu peux mettre des mouchards, ça n'empèche rien (bon dans certains cas c'est peut-être plus compliqué mais pas là). Et si c'est fait au niveau matériel, que tu ais une clé USB ou une carte à puce, tu es b*sé. La différence c'est que si ta carte à puce est "sûre", même si tu l'utilise sur un PC "hostile", on ne peut pas récupérer la clé qui est dessus (bon on peut quand même pendant que la carte est connectée) alors qu'avec une clé USB, si. C'est pas avec un liveCD que tu vas être sauvé (d'ailleurs c'est indiqué sur la page de MiB), sauf peut-être avec Tinfoil Hat Linux :op (http://tinfoilhat.shmoo.com/(...) ) .
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.
lorsque c'est purement materiel, il n'y a plus aucun moyen de contrôle
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.--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e 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 () le 21/08/2005 à 14:09. (lien). Évalué à 3.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
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.
-
-
-
-
-
[^]Re: On va se répéter uen dernière fois
Posté par Jean Parpaillon (Jabber id, page perso, ) le 18/08/2005 à 12:14. (lien). Évalué à 3.(a moins que tu ais acces au vhdl ?)
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 ?-
[^]Re: On va se répéter uen dernière fois
Posté par briaeros007 () le 18/08/2005 à 12:52. (lien). Évalué à 4.A ce que je sache le bios ne conserve pas les cles ,Pas plus que la cr ni que le proc...
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)--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: On va se répéter uen dernière fois
Posté par Gniarf () le 18/08/2005 à 13:44. (lien). Évalué à 3.attention, le VHDL est un langage :
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)--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: On va se répéter uen dernière fois
Posté par briaeros007 () le 18/08/2005 à 13:52. (lien). Évalué à 1.je reprend ma phrase alors :
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 ;)"--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: On va se répéter uen dernière fois
Posté par LeMagicien Garcimore () le 18/08/2005 à 16:47. (lien). Évalué à 5.arf
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 () le 18/08/2005 à 19:13. (lien). Évalué à 1.si tu prefere auditer le code par une societe tiers et independante qui surveille tous le processus de fabrication.
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
[^]Re: On va se répéter uen dernière fois
Posté par Zanton (page perso, ) le 18/08/2005 à 16:16. (lien). Évalué à 3.Je fais un peu de off topic mais ta dernière remarque est vraiment pertinente : il y a visiblement beaucoup de gens qui ne doivent pas comprendre ce que pertinent veut dire... Tu fais un post intéressant et tu te retrouves moinssé parceque quelqu'un n'a pas les mêmes idées que toi, ce qui est tout de même fort dommage en plus d'être injuste.
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 (page perso, ) le 18/08/2005 à 11:29. (lien). Évalué à 10.Alors fait une dépêche complète, argumentée et documentée pour nous expliquer tout ça de manière simple et compréhensible par un geek de base. Ça t'évitera de te répeter dans 149273 commentaires, et ça me (nous ?) permettra d'apprendre quelque chose.
-
[^]Re: On va se répéter uen dernière fois
Posté par Jerome Herman () le 18/08/2005 à 11:56. (lien). Évalué à 10.Je suis en train d'écrire un article.
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par Thomas Petazzoni (page perso, ) le 18/08/2005 à 12:38. (lien). Évalué à 6.Oui, je sais, je te vois ramer à chaque news/journal qui aborde le sujet pour essayer de faire passer ton point de vue sur TCPA et les sujets connexes. Le problème, c'est que l'argumentation est disséminée dans plein de commentaires, donc pour _vraiment_ comprendre ton message, c'est pas évident (surtout que le sujet lui-même n'est pas évident du tout). Donc un bon article complet sur le sujet serait très pertinent.
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 () le 18/08/2005 à 13:14. (lien). Évalué à 9.discourir que TPM est innocent ou juste un outil comme une machette, dont seul l'utilisateur serait responsable d'un mauvais usage, me fait une belle jambe : en tant que consommateur final avec un budget à taille humaine, je n'aurais jamais accès à juste TPM-pas-dangereux, on me filera le pack complet liberticide, ou rien (similaire à acheter de la musique avec DRM liée à une machine ou un iPod, ou ne pas pouvoir acheter de musique)
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--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: On va se répéter uen dernière fois
Posté par Jerome Herman () le 18/08/2005 à 13:41. (lien). Évalué à 4.Ce que tu dis est tout à fait exact. Sauf qu'à la différence d'Apple et de son Ipod ou des imprimantes et de leur marquage on sait
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.
-
-
-
[^]Re: On va se répéter uen dernière fois
Posté par Benoît Sibaud (Jabber id, page perso, ) le 18/08/2005 à 13:46. (lien). Évalué à 9.Je ne suis pas expert sur la puce TPM. Prenons par exemple comme description http://www.tomshardware.com/hardnews/20040916_143806.html(...) . À la lecture on peut se poser les questions suivantes :
- 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 () le 18/08/2005 à 14:08. (lien). Évalué à 6.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)
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 18/08/2005 à 22:04. (lien). Évalué à 4.qui a généré la clé maître en dur dans la puce, et comment => Toi même. C'est une rpocédure qui s'appelle prendre possession du TPM
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 () le 18/08/2005 à 23:57. (lien). Évalué à 3.Une correction: la dernière version des specs prévoit la possibilité de changer EK (TPM_RevokeTrust, TPM_CreateRevocableEK).
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 () le 19/08/2005 à 08:40. (lien). É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
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--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 19/08/2005 à 10:46. (lien). Évalué à 4.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".
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.
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.
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.
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.
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 () le 19/08/2005 à 13:41. (lien). Évalué à 2.Soyons clairs: ça sert avant tout à certifier que le TPM est un vrai TPM (et pas une émulation en soft)
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 19/08/2005 à 14:18. (lien). Évalué à 1.L'EK est dans un conteneur différent des AIK. Ils ne peuvent en aucun cas se garantir l'un l'autre.
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.
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.
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 () le 19/08/2005 à 15:42. (lien). Évalué à 2.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.
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...--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 19/08/2005 à 16:29. (lien). Évalué à 2.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.
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 () le 19/08/2005 à 16:57. (lien). É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
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 19/08/2005 à 23:39. (lien). Évalué à 3.Sur deux portables T42 identiques je n'ai jamais réussi à leur faire cracher deux hashes similaires.Et j'ai vraiment essayé.
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 () le 20/08/2005 à 20:47. (lien). Évalué à 2.Pourtant la spec TCG PC Specific Implementation Specification fait tout ce qu'il faut pour que certains hashes soient prédictibles
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 20/08/2005 à 22:30. (lien). É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.
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 () le 21/08/2005 à 14:06. (lien). É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 ?
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--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 21/08/2005 à 15:18. (lien). Évalué à 2.C'est l'architecture me de la puce qui empèche de renvoyer hash(OS_LOAD)
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 () le 21/08/2005 à 15:58. (lien). Évalué à 2.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.
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 21/08/2005 à 18:08. (lien). Évalué à 2.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.
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 () le 21/08/2005 à 22:06. (lien). É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 ?
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é.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter une dernière fois
Posté par a_caspis () le 21/08/2005 à 22:57. (lien). Évalué à 2.Or tu ne peux pas ne pas demander PCR[0], vu le principe même de l'extend des hash.
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 () le 23/08/2005 à 12:43. (lien). Évalué à 5.Ca fait trois jours que je me rpend la tête sur tes questions qui sont tout à fait valides. Et çà fait trois jours que je tourne en rond sans aucune réponse qui me convienne.
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 19/08/2005 à 15:42. (lien). Évalué à 1.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
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 () le 19/08/2005 à 16:38. (lien). Évalué à 3.Tu voulais peut-être dire que le vendeur ne t'a pas fourni le certificat EK en même temps que la machine ?
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 19/08/2005 à 17:04. (lien). Évalué à 2.La certification TCPA simple suffit largement dans l'ensemble des cas, et elle n'implique pas du tout l'EK.
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 () le 19/08/2005 à 17:33. (lien). Évalué à 3.Ce que tu appelles certification simple, c'est le mécanisme à base de protocole zéro-knowledge (DAA) ajouté dans la version 1.2 ?
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 19/08/2005 à 22:34. (lien). Évalué à 3.IBM n'ayant pas mon EK je ne pourrais jamais être certifié....
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 () le 20/08/2005 à 20:11. (lien). Évalué à 2.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).
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 20/08/2005 à 23:22. (lien). Évalué à 2.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.
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 () le 21/08/2005 à 13:35. (lien). Évalué à 2.Tu mélanges deux choses:
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...--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 21/08/2005 à 14:41. (lien). Évalué à 2.Non je ne mélange rien
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 () le 21/08/2005 à 15:31. (lien). Évalué à 2.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).
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 21/08/2005 à 18:00. (lien). Évalué à 2.Si je n'utilsie qu'un seul identifiant, un fournisseur de mêche avec le tiers certifiant pourrait remonter mes habitudes
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 () le 21/08/2005 à 22:48. (lien). É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.
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par a_caspis () le 22/08/2005 à 00:12. (lien). Évalué à 2.Pas besoin de passer par des certificats. En entreprise l'EK ne sert à rien, autant le désactiver si on en a pas besoin.
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 (page perso, ) le 18/08/2005 à 15:38. (lien). Évalué à 5.Juste une petite remarque : personnellement, j'aimerais bien savoir qui tu es. Par exemple, quand je parle réseaux de neurones et que je vais un peu vite pour ne pas ramer pendant 50 messages, on peut bien sûr ne pas me croire sur parole. Mais on peut aussi aller sur ma page web et voir que c'est mon métier. Ca ne veut pas dire que je ne raconte pas de connerie, mais ça veut dire que j'ai produit du savoir nouveau dans le domaine et que cette production a été validée par mes pairs avant d'être publiée dans des journaux et conférences. Bref, sur un domaine précis, ça renforce ma crédibilité.
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 () le 18/08/2005 à 16:35. (lien). Évalué à 8.Alors tout d'abord la cryptographie et ses applicatiosn hardwares ne sont pas mon métier. D'un coté ca signifie que je ne suis pas forcément à la pointe et de l'autre que je n'ai rien à gagner financièrement à promouvoir le TPM. A toi de voir si c'est un plus ou un moins.
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par boubou (page perso, ) le 18/08/2005 à 17:38. (lien). Évalué à 2.Merci, merci, ça éclaire. Je me rappelle que tu as dit quelque part que ton écran était entouré dans du papier d'alu (ou un truc du genre). J'avais cru à une blague, d'un seul coup ça me semble plausible.
-
[^]Re: On va se répéter uen dernière fois
Posté par Jerome Herman () le 19/08/2005 à 08:44. (lien). Évalué à 2.Je me rappelle que tu as dit quelque part que ton écran était entouré dans du papier d'alu
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par boubou (page perso, ) le 19/08/2005 à 09:26. (lien). Évalué à 1.Désolé, effectivement tu parlais d'une antenne alu (cf https://linuxfr.org/comments/591547.html#591547(...) par exemple).
Et c'est vrai que ça suffit ?-
[^]Re: On va se répéter uen dernière fois
Posté par Jerome Herman () le 19/08/2005 à 10:03. (lien). Évalué à 4.Et c'est vrai que ça suffit ?
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).--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.-
[^]Re: On va se répéter uen dernière fois
Posté par briaeros007 () le 19/08/2005 à 12:55. (lien). Évalué à 2.c'est un mouvement chaotique brownien pas du tout aléatoire.
aïe pas la tete pas la tete.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: On va se répéter uen dernière fois
Posté par Jerome Herman () le 19/08/2005 à 13:45. (lien). Évalué à 2.c'est un mouvement chaotique brownien pas du tout aléatoire.
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.)--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.
-
-
[^]Re: On va se répéter uen dernière fois
Posté par boubou (page perso, ) le 19/08/2005 à 15:32. (lien). Évalué à 3.mouvement chaotique brownien pas du tout aléatoire
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 () le 19/08/2005 à 15:59. (lien). Évalué à 2.Tu ne fait pas ta tête de con du tout, c'est pour çà que le mouvement brownien est chiant à traiter.
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.--
Kha
Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.
-
-
[^]Re: On va se répéter uen dernière fois
Posté par Jean-Philippe Garcia Ballester (Jabber id, page perso, ) le 19/08/2005 à 16:00. (lien). Évalué à 1.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).
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 (page perso, ) le 18/08/2005 à 13:53. (lien). Évalué à 1.Je pense que c'est une référence à ceci:
http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...)
-
Et encore une couche
En plus de savoir qui tu es et ce que tu fais, on va aussi te dire quoi faire...
En direct de formats-ouverts.org:
pour afficher les informations de l'ordinateur vers un écran ou vers un video-projecteur, Windows Vista vérifiera s'il est agréé en fonction du contenu à montrer : si ce n'est pas le cas, pas d'affichage.
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 () le 18/08/2005 à 11:22. (lien). Évalué à 10.pour afficher les informations de l'ordinateur vers un écran ou vers un video-projecteur, Windows Vista vérifiera s'il est agréé en fonction du contenu à montrer : si ce n'est pas le cas, pas d'affichage.
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 () le 21/08/2005 à 12:36. (lien). Évalué à 2.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', ...
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...--
You got the money, I got the soul.-
[^]Re: Et encore une couche
Posté par Barnabé () le 21/08/2005 à 13:32. (lien). Évalué à 1.http://www.rsf.org/article.php3?id_article=14069(...)
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
surtout si tu es brun et barbu
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008
-
[^]Re: fais attention à Londres avec les caméras
Posté par Nicolas Boulay () le 18/08/2005 à 12:47. (lien). Évalué à 1.et électricien.
--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."
-
[^]Re: fais attention à Londres avec les caméras
Posté par Krunch (Jabber id, page perso, ) le 18/08/2005 à 17:06. (lien). Évalué à 2.Et si tu es un geek associal avec des fils qui dépassent de ton sac à dos, évite les grandes villes en général.
http://www.schneier.com/blog/archives/2005/08/shoot-to-kill_r.html(...)--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: fais attention à Londres avec les caméras
Posté par doublehp (page perso, ) le 20/08/2005 à 14:33. (lien). Évalué à 2.hier je suis alle a cine direct apres le taf, donc avec mon portable en sac a dos, et un petit colis a la main: un carton de 12x20x20 ... j ai du comencer a l ouvrire pour avoir le doit de rentrer dans la salle.
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 () le 20/08/2005 à 18:11. (lien). Évalué à 5.pour le cine c'est possible que c'est pour verifier que tu n'ais pas de ... camera !
--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: fais attention à Londres avec les caméras
Posté par Nicolas Bernard (page perso, ) le 21/08/2005 à 21:30. (lien). Évalué à 2.A propos... Si je prend ma caméra et que je filme le film... c'est une copie privée, donc légal (contrairement à ce qui est affiché au début de chaque film), non?
-
[^]Re: fais attention à Londres avec les caméras
Posté par Sebastien Tanguy (page perso, ) le 22/08/2005 à 09:33. (lien). Évalué à 1.J'aurais tendance à penser que le droit à la copie privée n'est valide que pour l'achat d'un média (cassette, cd, dvd...), pas pour le fait d'assister à une représentation quelconque (que ce soit ciné, concert, théatre...).
-
[^]Re: fais attention à Londres avec les caméras
Posté par Krunch (Jabber id, page perso, ) le 22/08/2005 à 11:55. (lien). Évalué à 2.IANAL mais il me semble que le droit à la copie privé s'applique bien aux émission TV et radio (et on ne reçoit pas de média physique) donc pourquoi pas aux autres types de "représentations" ?
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: fais attention à Londres avec les caméras
Posté par doublehp (page perso, ) le 22/08/2005 à 13:29. (lien). Évalué à 2.le cinema est un lieu publique: te paye une entree. La TV est un bien prive, qui est dispose dans une zone privee: ton salon.
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 () le 22/08/2005 à 13:48. (lien). Évalué à 1.Et encore, pour la TV, tu paye une redevance ...
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
Lorsque l'oeuvre a été divulguée, l'auteur ne peut interdire [...]
2° Les copies ou reproductions strictement réservées à l'usage privé du copiste et non destinées à une utilisation collective,
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? ...)--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
-
Et les bières-sondes
Tout ça sans compter les bières sondes de chez Kronenbourg (la brasserie) ... Il y a quelques canettes sondes qui sont distribuées assez aléatoirement dans les palettes au départ de la brasserie et qui contiennent un liquide (genre de l'eau, mais pas de la bière) et une sonde chargée d'enregistrer tout un tas de paramètre environnementaux de la canette une fois quittée la maison. Tout ça pour faire des tests de traçabilité, vérifier que le conditionnement est efficace, etc.
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 () le 18/08/2005 à 11:38. (lien). Évalué à 5.Heu, tu peux donner les sources de ton info? Ca me parait peu crédible.
"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 () le 18/08/2005 à 11:51. (lien). Évalué à 1.À noter que cette pratique a été initiée par Danone, pour les yahourts (il me semble)
Ils mettaient du sperme dans le yahourt ?
-
[^]Re: Et les bières-sondes
Posté par Pelt (page perso, ) le 18/08/2005 à 11:56. (lien). Évalué à 8.Il ne doit vraiment pas en avoir beaucoup après tellement d'année à boire de la bière avec mes potes on est encore jamais tombé sur une. A moins qu'on est plus été en état de faire la différence.
-
[^]Re: Et les bières-sondes
Posté par Wawet76 (page perso, ) le 18/08/2005 à 14:08. (lien). Évalué à 4.Ces trucs là n'arrivent pas dans les rayons voyons ! :)
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 (Jabber id, page perso, ) le 18/08/2005 à 14:11. (lien). Évalué à 10.La seconde utilisation doit être le contrôle de la chaîne du foie.
-
-
-
[^]Très bonne idée !
Posté par thom_ra () le 18/08/2005 à 13:54. (lien). Évalué à 3.En effet, vous devez tous savoir que pour éviter la gueule de bois, il faut boire de l'eau pendant la soirée. Et ben là, Kro à trouvé le moyen pour que l'on puisse recommencer à boire de la bière plus vite.
Attention : je n'ai pas dit que ça empêche d'être "malade" ;-)
-
[^]Re: Et les bières-sondes
Posté par Sebastien Tanguy (page perso, ) le 22/08/2005 à 09:35. (lien). Évalué à 1.C'est le genre de choses qui se font aussi pour certains types de serveurs qui coûtent très-très cher (oh, la jolie sonde sur la caisse en bois!).
à déposer
le concept du courriel postal
il me semblait dans ce cas là qu'on appelait ça du courrier postal plutôt...
------> [] (sur la pointe des pieds)
-
[^]Re: à déposer
Paranoïte aigue ... et justifiée ... ?
Bon partant du postulat que la N.S.A. - http://fr.wikipedia.org/wiki/NSA(...) - possède des technologies ayant à peu près dix ans d'avance sur celles que nous avons la possibilité d'utiliser, et vu le niveau des applications grand public actuelles ( http://maps.google.com/(...) par exemple ), j'espère pour que le posteur prend bien soin de ne pas sortir sans son bonnet, sous peine de se faire visionner la calvitie par les satellite de l'agence américaine.
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 () le 18/08/2005 à 11:08. (lien). Évalué à 3.un parano utilise toujours des cles plus grande que prevu : exemple 4096 plutot que 1024 ; avec ca tu devrais etre au dessus des 2^100 non ?
--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par doublehp (page perso, ) le 20/08/2005 à 14:37. (lien). Évalué à 1.heu ... tu sais ce qeu veut dire 1024 ?
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 () le 20/08/2005 à 18:14. (lien). Évalué à 3.2^100 pour 2^100 operations a traiter pour casser la cle (par exemple par un crible algebrique)
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 ?" ?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par doublehp (page perso, ) le 20/08/2005 à 22:00. (lien). Évalué à 2.un ami vient d ecrire un noveau generateur de nombres premiers ... et cherche des gens meilleurs que moi en math pour faire valider son programme.
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 () le 21/08/2005 à 00:50. (lien). Évalué à 1.J'ai pas tres bien compris et je suis pas tres bon en maths non plus mais j'essaie un peu de repondre ; il se peut que je me goure dans ce cas corrigez moi ;)
"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)--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par Krunch (Jabber id, page perso, ) le 21/08/2005 à 02:34. (lien). Évalué à 3.Je pense qu'il te faudrais plus que 4Go pour les stocker :-D
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,...). Tu n'as besoin d'avoir qu'un nombre qui va servir de diviseur en mémoire à la fois.
ca ne sert a rien de faire les nombres premiers plus grand que la moitie du nombre a chercher
Tu peux même t'arrêter à la racine carrée du nombre qu'on cherche à factoriser.--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par briaeros007 () le 21/08/2005 à 10:12. (lien). Évalué à 1.Tu peux même t'arrêter à la racine carrée du nombre qu'on cherche à factoriser
ce que j'ai mis ici :
(en realite c'est 4*n^1/2 ; chouette des dl pour simplifer le calcul :-D)
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).--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par doublehp (page perso, ) le 21/08/2005 à 14:44. (lien). Évalué à 2.j ai dit qu il pense pouvoir gerer des nombres pouvant aller jusqu a 10% de la memoire disponible ...
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 () le 21/08/2005 à 17:18. (lien). Évalué à 1.oui c'est un compromis temps/memoire.
C'est le meme principe pour casser les mdp crypte de windows.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par boubou (page perso, ) le 21/08/2005 à 13:23. (lien). Évalué à 5.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).
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 () le 18/08/2005 à 11:32. (lien). Évalué à 10.La paranoïa est parfaitement justifié.
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 (Jabber id, page perso, ) le 18/08/2005 à 23:09. (lien). Évalué à 1.http://www.onnouscachetout.com/themes/societe/unadfi.php(...)
-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par coujou () le 19/08/2005 à 20:42. (lien). Évalué à 3.La NSA est en train de se consituter une base d'empreinte et de photo titanesque.
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 () le 18/08/2005 à 12:16. (lien). Évalué à 1.j'espère pour que le posteur prend bien soin de ne pas sortir sans son bonnet, sous peine de se faire visionner la calvitie par les satellite de l'agence américaine
Une autre possibilité, c'est les implants.-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par Dalton joe (page perso, ) le 18/08/2005 à 12:50. (lien). Évalué à 4....la N.S.A. possède des technologies ayant à peu près dix ans d'avance sur celles que nous avons la possibilité d'utiliser...
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 (Jabber id, page perso, ) le 18/08/2005 à 17:23. (lien). Évalué à 5.Il me semble que ces 10 ans d'avances viennent en fait d'une observation assez simple. Lorsque le standard SHA-0 a été mis au point (1993), la NSA l'a "patché" sans donner d'explication (ce qui a donné SHA-1 en 1995) et ~10 ans plus tard (2004) des chercheurs en dehors de la NSA on découvert une faille qui s'applique à SHA-0 mais pas à SHA-1. Ce qui a fait dire à certains que la NSA avait 10 ans d'avance à l'époque.
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(...)--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par boubou (page perso, ) le 18/08/2005 à 17:36. (lien). Évalué à 2.DES. La NSA avait inventé une type d'attaque (l'analyse cryptographie différentielle) des années (beaucoup plus que 10, sauf erreur) avant la crypto universitaire. La NSA a donc fait modifié DES par IBM pour le rendre plus robuste contre ce type d'attaque.
-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par Krunch (Jabber id, page perso, ) le 18/08/2005 à 18:35. (lien). Évalué à 2.Apparement c'est bien ~15 ans. DES a été publié pour la première fois en 1975 et le papier sur la cryptanalyse différentielle qui montre que les modifications apportées par la NSA ont amélioré la résistance de DES a été publiée en 1990 (enfin plus loin c'est marqué 1992 et dans les références c'est 1993).
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.--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
-
-
-
-
-
[^]Re: Paranoïte aigue ... et justifiée ... ?
Posté par ArBaDaCarBa () le 18/08/2005 à 15:50. (lien). Évalué à 5.Comme disait Pierre Desproges, "Ce n'est pas parceque je suis parano qu'ils ne sont pas tous après moi".
News de première page
Je trouve cette news est très marrante et aussi intéressante mais je ne comprends pas ce qu'elle fait en première page.
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 (page perso, ) le 18/08/2005 à 11:38. (lien). Évalué à 6.1) y a pas grand chose comme news, c'est les vacances
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 (page perso, ) le 18/08/2005 à 12:35. (lien). Évalué à 10.2) c'est posté par un modo, alors ca doit aider pour faire passer les billet d'humeur ;)
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 (Jabber id, page perso, ) le 18/08/2005 à 11:45. (lien). Évalué à 5.Je ne l'ai pas trouvée marrant du tout... plutot horrifiante.
-
[^]Re: News de première page
Posté par tene (page perso, ) le 18/08/2005 à 13:11. (lien). Évalué à 7.Moi j'ose même pas vous dire ce que j'en pense, il me regarde, surtout lui là bas!
:p
ps: vous n'avez pas lu ce message, il n'existe pas...
-
-
[^]Re: News de première page
Posté par TImaniac (Jabber id, page perso, ) le 18/08/2005 à 11:48. (lien). Évalué à 5.Comme dis au dessus, c'est l'été, y'a pas beaucoup de "news".
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 (page perso, ) le 18/08/2005 à 13:10. (lien). Évalué à 5.Je vote pour la garder en premiere page : très bien écrit, plein de liens interessants, c'est bien précisé "Humeur".
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
Bjr,
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 () le 18/08/2005 à 12:44. (lien). Évalué à 3.... finalement on ne fait qu'accepter une certaine dépendance avec différents organismes et sociétés.
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 (page perso, ) le 18/08/2005 à 16:24. (lien). Évalué à 5.Ca n'est pas parceque c'est un état de fait qu'il faut l'accepter.
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 pankkake (Jabber id, page perso, ) le 23/08/2005 à 02:34. (lien). Évalué à 0.Tu es libre de choisir ta dépendance.
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" ?
-
-
Et Tor ?
Il manque à cet arsenal de paranoïaque (ou prudent ?) Tor, un logiciel d'anonymisation (c'est comme ça qu'on dit ?) des connexions TCP, sponsorisé par l'EFF, que j'ai trouvé assez impressionant : http://tor.eff.org/(...)
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
-
[^]Re: Et Tor ?
-
[^]Re: Et Tor ?
Posté par Olivier Tigro () le 19/08/2005 à 14:56. (lien). Évalué à 0.A l'évocation de TOR, ressurgit le débat sur la prévalence de la lutte contre les pédophiles, le banditisme, le terrorisme, (et tout un tas de trucs en "isme") sur le respect de la vie privée.
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...
Les gens craignent pour leur vie privée et en même temps étalent leur vie sur des blogs.
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 (page perso, ) le 18/08/2005 à 12:06. (lien). Évalué à 4.je vois mal le rapport entre sécurité et sécuritaire
-
[^]Re: Mouais...
Posté par drcanard () le 18/08/2005 à 12:22. (lien). Évalué à 8.Je voulais dire par là qu'il s'agit de faire peur au quidam en exagérant une menace (soit sur sa probabilité d'arriver, soit sur ses conséquences réelles) pour parvenir à ses fins.
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 (Jabber id, page perso, ) le 18/08/2005 à 12:16. (lien). Évalué à 7.Les gens craignent pour leur vie privée et en même temps étalent leur vie sur des blogs.
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 () le 18/08/2005 à 12:37. (lien). Évalué à 1.Les gens contrôlent ce qu'ils disent plutôt que d'être contrôlés à leur insu.
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 (Jabber id, page perso, ) le 18/08/2005 à 13:35. (lien). Évalué à 3.Tu prétends contrôler ce que tu dis, mais en contrôles-tu vraiment la portée ?
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 (Jabber id, page perso, ) le 18/08/2005 à 13:38. (lien). Évalué à 1.Mais dans ce cas, il s'agit d'assumer ses paroles et ses actes, que l'ont a volontairement rendu public, car dans le cas ou tu l'a envoyé a quelqu'un en lui faisant signer une clause de confidentialité qu'il na pas respecté se débat au tribunal, pas ici... Si maintenant le même mail (celui confidentiel) est intercepté par X ou Y et transmis a Z qui s'en sert contre toi, c'est cela qu'il faut combattre.
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.--
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
-
-
-
[+] [^]Re: Mouais...
Posté par Pierre Tramonson () le 18/08/2005 à 13:01. (lien). Évalué à -1.Et il faudrait tout simplement arrêter d'être parano à mon avis. Heureusement qu'il y a la touche d'humour avec le lien Wikipédia sur la fin de l'article :)
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 (page perso, ) le 19/08/2005 à 12:00. (lien). Évalué à 4.>>Si vous ne supportez pas la pression d'une vie fortement soumise à
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 (page perso, ) le 19/08/2005 à 12:45. (lien). Évalué à 2.Si l'on fuit la société, c'est elle qui reviendra nous chercher... on peut citer comme exemple le peuple des "Karens" dans le nord de la Thailande, qui malgré les efforts du gouvernement thai pour protéger ce peuple de la modernité, perd peu à peu son authenticité et adopte les comportements de "la société".
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 (page perso, ) le 19/08/2005 à 13:19. (lien). Évalué à 3.on peut citer comme exemple le peuple des "Karens" dans le nord de la Thailande, qui malgré les efforts du gouvernement thai pour protéger ce peuple de la modernité, perd peu à peu son authenticité et adopte les comportements de "la société".
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 (page perso, ) le 19/08/2005 à 14:20. (lien). Évalué à 2.Les Karens sont libres et on ne leur interdit rien de tel... En général ils préfèrent leur mode de vie et restent dans leur coin. Seulement il y a des gens venant de la majorité de la société, et qui vont là-bas pour donner un coup de main. On demande à ces gens de ne pas apporter avec eux (par exemple) des choses telles que les appareils photo numeriques pour ne pas bouleverser le mode de vie des Karens.
...mais je comprends que mon commentaire n'était pas 100% clair :P
-
-
-
-
[+] [^]Re: Mouais...
Posté par SuperDindon () le 18/08/2005 à 18:39. (lien). Évalué à -1.tes paradoxes sont faciles et ne sont pas vérifiés pratiquement
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 (page perso, ) le 19/08/2005 à 11:52. (lien). Évalué à 3.>>Les gens craignent pour leur vie privée et en même temps étalent leur vie sur des blogs.
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
> en arguant des cataclysmes apocalyptiques et tentaculaires causés par des lycéens de 12 ans.
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 ?
« Nous avons neuf mois de vie privée avant de naître, ça devrait nous suffire. » (Heathcote Williams)
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
Tu as oublié les puces qu'il y aurais dans les billets de 20 Euros ...
-
[^]Re: les puces RFID dans les billets de 20 euros
Posté par Franck Yvonnet (page perso, ) le 18/08/2005 à 17:11. (lien). Évalué à 5.Et des émetteurs satellites planqués dans les alims ATX pour que les gens qui travaillent sur le réseau puissent te connecter à internet de force. Tu peux le vérifier toi même en lançant un ifconfig sur une machine complètement deconnectée: tu trouvera certainement un code de la forme xx:xx:xx:xx:xx:xx qui est le numéro de téléphone par lequel on te connecte.
autant être parano jusqu'au bout
et puis cela me permettait d'échanger des empreintes GnuPG.
...avec des agents du gouvernement qui te présentaient de faux papiers.
Grand jeu Le monde dans ton appart
1) On trouve des caméras partout dans les villes (à tel point que parfois on n'arrive même pas à savoir combien il y en a http://rewriting.net/2005/08/17/ou-sont-passees-les-cameras/#commen(...) ). Il faut ajouter à celles-ci les webcams qui fleurissent un peu partout et dont nombre sont accessibles sur internet. Les moteurs de recherche vous offre un accès à de multiples caméras de surveillance non protégées en ligne (cf http://www.lexpansion.com/compteur/compteur.asp?compteurid=689&(...) ). Certains parcourent les rues pour capter les émissions radio des caméras de vidéosurveillance privées des entreprises, qui émettent jusque dans la rue, et permettent d'espionner à leur insu les salariés et les clients sans même rentrer dans le magasin/l'entreprise.
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
Juste un petit mot sur la carte de métro londonien, qui ressemble à Navigo.
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 (page perso, ) le 19/08/2005 à 12:48. (lien). Évalué à 2.oui enfin si tu prends un formulaire en station, tu met un nom/prénom bidon le gars du guichet s'en fout, il te file ton oyster direct modulo les 3£ de caution, tu la charge en top up directement en liquide aux guichets, ça marche. Après l'interet de mettre un vrai nom/prénom/adresse et tout c'est uniquement pour pouvoir utiliser le service internet (recharger ta carte online) il me semble... et encore je suis même pas sûr que ce soit nécessaire.
[+] Dur à avaler
Bah il ne me restait plus qu'à aller poser devant les caméras dans la rue (Paris, Londres, etc.), et à reprendre des pilules.
La rouge ou la bleue ?
-
[^]Neo réveille toi
quote
« Même les paranoïaques ont des ennemis. »
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 ?
On devrait élire la news de l'année.
Ca s'impose quand on lit celle çi.
Je propose cette news au rang de news de l'année.
linux addict since 1992
-
[+] [^]Re: La news de l'année ? On vote ?
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 20/08/2005 à 17:00. (lien). Évalué à -1.MDR, oui pourquoi pas.
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 () le 20/08/2005 à 19:05. (lien). Évalué à 3.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?
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 () le 20/08/2005 à 20:07. (lien). Évalué à 3.Et le vigile du vigile à qui l'on confie son dossier, hein ?
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 (page perso, ) le 21/08/2005 à 21:41. (lien). Évalué à 2.Bien que je ne pense pas que les gens du Miniamour ©® soient assez malins pour penser à la récusion terminale, ils peuvent éviter le stack overflow simplement en faisant de la surveillance modulaire: le matricule no i surveille le matricule i+1 mod N. Avec des pointeurs c'est facile à implémenter!
-
-
-
-
[^]Re: La news de l'année ? On vote ?
Posté par arno (Jabber id, ) le 21/08/2005 à 00:47. (lien). Évalué à 2.Je vote pour. Ne serait-ce que parcequ'en lisant le débat sur le TPM (auquel je ne comprends rien :p) j'ai l'impression d'être sur le forum des "Admirateurs secrets"© :D.
-
[^]Re: La news de l'année ? On vote ?
Posté par Nicolas Bernard (page perso, ) le 21/08/2005 à 21:35. (lien). Évalué à 2.Sais-tu que dans le monde réel, les "Admirateurs secrets" s'appellent les Cypherpunks? Une petite recherche sur ce mot et...
-
[^]Re: La news de l'année ? On vote ?
Posté par Nicolas Bernard (page perso, ) le 21/08/2005 à 21:44. (lien). Évalué à 3.À propos, si des gens sont intéressés par la création d'une liste cypherpunks-french, ca doit pouvoir se faire, qu'ils me contactent par mail ou message privé.
-
[^]Re: La news de l'année ? On vote ?
Posté par arno (Jabber id, ) le 21/08/2005 à 22:56. (lien). Évalué à 2.Non, je ne le savais pas. J'ai lu les bouquins(*) bien avant d'avoir l'ADSL et depuis je n'avais pas fait de recherche pour trouver le vrai nom.
Merci pour le mot clé.
(*) Cryptonomicon de Neal Stephenson, pour ceux(**) qui ne connaissent pas.
(**) Il y en a?
-
-
Cette page a été générée par Templeet en 0.5442s (dont 0.0402 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.