Non.
Pas un seul instant.
Le Hash ne sort pas des puces.
Si il sortait, il ne serait pas exploitable car dépendant de la plateforme au sens strict du terme (ie deux PC du même modèle, de la même année n'ont pas les mêmes hashs (testé avec migration de disque dur dont le numéro de série a été forcé sur des x31, ca marche pas))
Si il sortait et qu'il était exploitable, les clefs déposées dans la zone signée seraient déplaçables et donc exploitable à postériori (on aurait besoin d'un système propre pour obtenir les clefs) et après on fait ce que l'on veut)
Si le hash sortait, qu'il soit exploitable et que l'on ne puisse pas bouger les clefs il faudrait encore que le matériel environant (disque dur, carte son, écran etc) intégre aussi un TPM pour pouvoir dialoguer avec celui de la carte mère et se bloquer le cas échéant en cas de non conformité.
On a carrèment de la marge entre maintenant et la zone rouge.
While it does have the ability to
report signed PCR information
Avant d ecommencer, j'attire juste ton attentio que la puce TCPA ne renvoit pas les hash mais créé des reports signés en dfonction du PCR. On est donc bien dans le cadre challenge/response. Ouf.
L'excuse donnée par ce document de 2002 fait aujourd'hui sourire:
oui mais c'est dur car il faudrait stocker les hashs des BIOS des OS dans une grosse base de donnée.
C'est clair, ca fait sourire, on voit tout à fait uen base de données contenir les quelques huit milliards de config bios d'uen machine, l'infinité des partionnements valides et se mettre à jour au fur et à mesure des mises à jour windows ou du lecteur de contenu. Ca fait quoi 2-3 To par utilisateurs grand maximum. Une paille quoi.
Tout ca pour quoi ? Empécher un utilisateur d'accéder à un contenu distant, tout en sachant que si il y accède une fois après authentification il pourra faire ce qu'il veut de la clef et la déplacer si besoin est dans une zone moins restrictive ? Ca vaut le coup.
Je ne comprend vraiment pas pouquoi l'ensemble des magnats de la vidéos et du son ne se sont pas jetés sur cette magnifique opportunité.
Même google ne donne que 2go par utilisateur, c'est environ le millième de ce qui serait nécessaire.
Sur un doccument de 300 pages, il y a 10 pages sur la remote attestation. Il n'existe pour l'instant aucun tiers de confiance utilisable globalement (ie un équivalent verisign pour les certificats), aucun fournisseurs qui demende la présence de TPM pour l'accès à certains service (et je dis juste demande, pas exige), la fonctionnalité est désactivée par défaut et le vendor ID est laissé à blanc.
On sent bien là qu'il s'agit de LA priorité d'IBM quand il s'agit de la puce TCPA.
Le remote attestation aura des répercusions très graves sur nos libertés
C'est clair, un vendeur pourrait vérifier, via agrément d'un tiers de confiance, que la machine distante est bien celle qu'il connait dans uen config qu'il connait. C'est presque aussi intrusif qu'un cookie et presque aussi dangeureux que l'installation d'un certificat local pour l'accès à un service.
alors que d'autres techniques permettent aussi d'améliorer la sécurité d'un ordi mais sans permettre le remote attestation.
C'ets sur au sein d'un parc de PCs il existe pleins de techniques aussi simple et aussi fiable pour vérifier de façon fiable la non compromission des machines clientes par un serveur. On peut citer par exemple..... je sais plus, mais il y en a plein en tout cas. Trop même.
Seul un refus de toutes les puces qui permettent le remote attestation nous permettra d'éviter d'être obligé d'avoir un OS drm non modifiable et des matériels drm, pour pouvoir se connecter.
C'est clair aussi. On rejette violamment une puce qui ne permet en aucun cas de faire la moindre incursion dans DRM et au final on aura jamais de matos drm dans nos PCs. C'est magique, faut pas chercher à comprendre.
On crache très fort sur TCPA et on fera disparaitre les firmwares lockés sur les lecteur DVD.
Par contre as-tu pensé aux conséquences pour le grand public de la généralisation de puces qui permettent d'identifier "en toute confiance" le hardware et le software qu'il y a sur chaque ordinateur ?
Ca serait une catastrophe.
C'ets pour çà que j'aime beaucoup la puce TCPA, parcequ'elle ne permet en aucun cas de faire ce genre de choses. Elle eprmet totu au plus de vérifier que l'on a bien à faire à une config identique à la config précédente. Et encore, dans la mesure ou l'admin de la puce joue le jeu.
Reprend la doc (la grosse, celel qui fait 300 pages) si tu l'as encore et fait une recherche sur "control points" et "aging materials". On y explique pourquoi un disque dur qui commence à rendre l'âme (tourne moins vite, certains clusters en erreur) ou une barrette mémoire veillisante (ECC qui tourne sur certaines zones, temps de latence en augmentation) vont être repérés par la puce TCPA mais en vont pas pour autant causer le verrouillage de la puce.
le remote attestation de la plateforme est bien la communication des hashs des composants de cette plateforme
Donc pour toi la puce envoie directement les hashs brut de fonderie au tiers de confiance (ou alors directement au tiers client )?
Si tu prend tes propres docs (en version PDF de préférence, les schémas sont illisibles sur la version HTML) Notamment celui ci : http://byte.csc.lsu.edu/~durresi/7502/reading/rc23064.pdf(...) à la page 8 figure 2 section "remote attestation"
on y voit clairement que les mesures métriques effectuées par les agents ne sortent jamais de la puce. Le service d'attestation recoit une demande sous forme de challenge et renvoit une response. C'est un cas très classique de preuve par déchiffrage de message dans le cadre d'une certification.
De toute façon, même si les hashs sortaient ils seraient inutilisables. tout d'abord parceque les hashs sont différents (très) sur chaque plateforme, et ensuite parcequ'ils varient d'un boot à l'autre (et oui une carte graphique à 50°c n'aura pas le même hash que la même carte graphique à 20°c). C'ets pas un jeu complexe d'échange entre le TPM et les agents de mesures que le matériel est certifié. (Un peu comem pour les empreintes digitales, le TPM cherche des "points de correspondance" quand il en a suffisament il valide, si ca ne marche pas il rejette).
Bref l'interet de faire sortir les hashs de la puce TCPA est rigoureusement nul.
P.S : j'ai beau chercher je ne vois nulle part mention de l'idée de faire sortir les hash de la puce.
Ca dépend de ton proof of concept.
Si c'est un truc qui a une chance sur dix milliards de marcher, ou qui nécessite des conditions de réalisation monstrueuses (genre réussir à placer une interruption illégale dans un appel système que je ne controlle pas) je ne mets pas à jour.
Pourquoi ? Parceque j'ai déjà des maillons beaucoup plus faibles dans ma chaine de sécurité. Pas la peine de surblinder uen étape si els étapes environnantes ne sont pas au même niveau.
Ben si tu as la majorite des gens qui laisse les trucs en "defaut" comme c'est le cas pour windows.
Le truc par défaut c'est :
En admin : Créer une signature de boot, créer une identité, créer un profil. Lier l'identité avec la signature de boot et accorder les droits en lecture écriture au profil.
Avec le Profil : Déclarer un tiers de confiance, valider l'identité auprès du tiers et sauvegarder la clef d'authenticité dans le profil.
Ca n'ets pas exactement "trivial". Comme la clef ne peut pas être préchargée (interdit par la norme TCPA) à une exception près : identité puce sans signature de boot (laquelle est désactivée par défaut et non chargé par IBM) ca fait quand même du boulot entre le "par défaut" et le truc hautement intrusif.
Pas convaincu : les carte "pirates" pour les bouquets satellites sont casses en 6 mois a peu pres. pourtant ils donnent pas leurs hdl ni leurs cles.
il y a quelques mois ti avait une puce qui servait a l'authentification des voitures. La aussi securite par obfuscation. Paf casse.
Les deux cas que tu donnes appartienent à un paradigme complètement différent, celui ou l'on cherche à garder un secret vis à vis de l'utilisateur final. Sous TCPA il n'y a pas besoin d'utiliser de la force brute, toutes les clefs sont utilisables par l'utilisateur en 10 secondes via migration de zone. Ici on ne cherche pas à protéger le contenu de l'utilisateur, mais du reste du monde.
Typiquemetn dans le cas de technos DRM on cherche à masquer la clef privée le plus possible, mais on est obligé de la donner quand même (sinon l'utilisateur ne peut pas lire le support). TCPA ne cherche absolument pas à faire celà. Toutes les clefs sont toujours accessibles/migrables et donc utilisables dans toutes les situations. Aucun rapport donc avec ce que tu cites.
Tu dis que tu sais exactement ce qui se passe; donc tu as eu le hdl et tu sais le lire?
J'ai eu entre les mains le doc qui permet à un constructeur de fabriquer sa propre puce TCPA dans les normes. Je peux donc dire que je connais le fonctionnement de l'ensemble de la puce à deux exceptions pret (vu que je n'ai pas voulu signer de NDA).
Il s'agit d'enboyer, signés par la puce TPM, les hashs des composants matériels et logiciels d'un ordinateur.
C'est autrement plus intrusif !
GNNNIIII ?????
Le remote attestation permet en passant par un tiers de vérifier que la clef que tu as fait créer par le tiers et qui a été transmise depuis le TPM du tiers jusque dans ton TPM est bien présent et de certifier cette information auprès d'un autre tiers.
C'est exactement l'équivalent des certicats "classiques" sauf que celà se joue entre TPM.
Pour finir il n'y a que deux choses qui peuvent sortir du TPM : soit un message décodé (par exemple suite à un challenge response, ou dans le cadre normal de l'utilisation du TPM pour déchiffrer un message); soit une clef migrable a condition que ce soit vers un autre TPM et seulement via une connection sécurisé.
Relis bien le document de TCG que j'ai cité ci-dessus où ils reconnaissent que cette remote attestation est un fait.
On va pas reprendre le troll ici. Je t'ai déjà démontré, il y a un an que
a) La config sur laquelle un tiers insiste même si il n'y a pas de raison sécuritaire à un tel choix est une config précédamment rencontrée. En d'autres termes le tiers client peut s'assurer via le tiers de confiance que tu as bien toujours la même config que celle créée précédamment. il ne peut en aucun cas en déduire ton OS, tes disques durs, ta carte graphique ou quoi que ce soit d'autre.
b)Toutes les clefs accessibles de l'extérieur sont migrables. En d'autres termes tu peux parfaitement déplacer la clef de ton tiers client d'une zone à une autre. dans ce cas tu nepourras plus être validée par remote attestation, mais tu pourras toujours lire l'ensemble des doccuments qui ont étés cryptés avec cette clef (ce qui limite vachement l'utilisation dans le cadre du DRM). Si tu veux continuer à faire de la remote attestation, tu peux aussi simplement copier la clef. La copie dans la zone certifiée sera toujours valide aux yeux du tiers client, la copie dans une zone plus laxiste sera utilisable comme bon te semble.
Au final cette technique n'est utile que pour un admin qui veut vérifier que ses machines n'ont pas étés compromises avant de les admettre sur le réseau (par exemple). A part çà...
La seule vraie nouveauté de TCPA est le remote attestation.
Et l'analyse métrique du système
Et l'unlock automatique de clef fontion du boot et des interactions utilisateurs
Et le coffre hardware dont les clefs ne sortent jamais en clair
Et l'idépendance du système d'exploitation
Et la migration automatique clef/droit/zone d'un PC à un atre sans compromission possible sauf altération physique de haute volée.
L'avantage de ne pas utilise de "boite noire" est de na pas favorise le developpement de pareilles boites sur toutes les cm pour etre finalement un jour bloque par elles.
La seule façon de bloquer un système via la puce TCPA serait d'avoir dans la puce des clefs extérieures préchargées qui serviaient à autre chose que d'authentifier la puce auprès d'une autre puce. Ce cas est formellement interdit par la norme TCPA. De plus il faudrait aussi que l'utilisateur principal de la machine ne soit pas admin (ce qui est aberrant, il ne pourrait alors plus se servir de la puce) o que les clefs soient accessibles de l'extérieur mais non déplaçable/migrable, ce qui est également interdit par la norme. Pour finir il faudrait également que le matériel soit capable de tirer partie de ces informations, ce qui implique d'avoir un système TPM non seulement sur la carte mère, mais aussi sur les parties que l'on veut bloquer (doncTPM sur disque dur/carte son/lecteur vidéo etc.) Bref on aura encore une chance de voir venir si c'est l'orientation que prennent les choses.
De plus la sécurite par l'obfuscation est rarement une bonne chose
Houlà, c'est pas uen boite noire au sens "on sait pas trop ce qu se passe dedans", c'est uen boite noire au sens "bonne chance pour récupérer la clef les gars". Suite au troll avec Free2org je sais exactement ce qui se passe dans ma puce TPM - vu que je n'utilise pas et que j'ai désactivé les fonctions non parfaitement doccumentés (ie identification puce à puce et identification ditsitante certifiée par tiers)
Dans cette puce il y a deux choses que l'on ne connait pas :
a) le générateur d'aléas - on ne sai pas comment il marche et IBM n'était pastrès causant à ce sujet.
b) la clefs d'authentification TPM qui permet à un système TPM de prouver à un autre système TPM qu'il est bien un système valide. La raison pour laquelle cette clef n'est pas connue est probablement parcequ'il s'agit d'une clef privée ou équivalent plus ou moins complexe. les clefsprivées ont la sale (ou la bonne) habtde de ne pas être conne de tous.
A part çà le reste est très simple. Il y a une couche crypto interne (pour controller l'intégrité de la puce et sécurisé le contenu des coffres), une couche crypto externe pour générer les clefs et une couche de dialogue utilisateur. Bref c'est à peu de chose pret un serveur PKI on die avec une authentification masquée.
Si tu as ta bd + tes binaires de tripwire sur des supports en lecture seule (comme c'est preconise) j'ai un peu de mal a le croire car le module il doit bien etre quelque part ;
Pour aller plus loin que Beretta je dirais ceci : il est trivial de démontrer que tripwie ne sera jamais secure.
Tripwire n'est pas un OS complet, donc pour se lancer, s'initialiser et effectuer ses différentes opérations il est obligé (comme tout le monde) de lancer des appels systèmes et de "faire confiance" à la réponse. tant que tripwire ne sera pas le coeur du kernel (ie le premier truc chargé) il ne pourra pas s'assurer que le système amont n'a pas été corrompu. Il sera obligé de "croire" le système quand celui-ci lui renverra les infos concernant un repertoire précis ou un démon en train de tourner. Entre autre tripwire est incapable de se certifer lui même indépendamment du système. La puce TCPA le peut.
Mais il existent d'autres fonctions de hashage qui ne presente pas ce problème. pourquoi ne pas changer alors?
Pour faire uen réponse claire : par ce que ca ne sert à rien. On a trouvé un cas hyper particulier dans lequel il ets possible de générer "raisonablement" facilement deux fichiers ayant la même signature.
Ce n'est pas l prmeière fois que celà se produit. il y avait par exemple dans le tout premier aogorithme RSA une faille qui faisait que pour certains nombe premiers "spécifiques" il était possible de retrouver les deux facteurs d'un produit de nombre premiers en un temps raisonablement court (complexité n² au lieu de de coplexité exponentielle).
A-t-on abandonné le système immédiatement pour autant ? Non. On a juste ajouter une fonction pour éviter ces cas particuliers.
Pour en revenir à SHA-1, il eut se passer deux choses : soit le cas décrit est un truc vraiment très particulier innutilisable ailleurs. A ce moment la il existe une "faille" dans SHA-1 qui permet à un utilisatur de générer deux fichiers ayant le même hash. Utilisabilité en usurpation : 0.
Soit il existe une propriété algénrique non connue qui vient d'être mise en exemple par un cas spécifique sur SHA-1, et alors si elle est généralisée et démontrée rien ne dit qu'elle n'impactera que SHA-1. On est même plutôt tenté de penser que c'est l'ensemble des calculs de hash qui va être impacté (Si c'ets une propriété algébrique globale, il y a peu de chance que MD5, par exemple, ne soit pas impacté aussi).
Bref soit c'est inutilisable, soit il y a de bonnes chances que ca impacte tout le monde. Les raisons de rejeter SHA-1 sont donc réduite.
1. Le remote attestation n'est pas possible sans une puce de type TCG.
C'est sur on a jamais vu un système identifier un autre système à distance sur la foi d'une clef ou d'un mot de passe. C'est tout nouveau ca vient de sortir. Par exemple les licences MS ne sont pas du tout validées à distance et locké par PC. Du tout.
2. Toutes les autres fonctions TCG ne sont pas nouvelles et sont possibles autrement (les coprocesseurs de crypto existent depuis longtemps, de meme les supports avec mode read-only pour booter dessus en sécurité).
Bien sur aussi, on a depusi longtemps uen boite noire qui fait coffre à clef que l'on peut remplir à volonté et dont les clefs sont inextractibles en clair. Ca existe depuis super longtemps et TPM n'apporte rien.
La façon efficace de lutter contre cela est de refuser d'avoir ces puces
Je te rassure, c'est déjà fait. TPM est en voie de mort rapide. Les normes v2 n'ont jamais vu le jour et les systèmes parallèles ont appris à se faire discret pour rentrer sur nos systèmes en douce. On ne peut que féliciter les gens qui par leur boycott ont tué dans l'oeuf une techno fiable, utile et ouverte, laissant ainsi la porte grande ouverte aux bios plombés, au matos adaptatif et au options de sécurités imposés par les grands groupes et dont les specs sont bien cachés.
Je ne vais pas reprendre ce troll vec toi. Mais au moins essaye d'éviter le FUD par pitié.
Si je met toutes mes clefs privées sur ma clef USB, j'ai pas interet à la perdre ma clef (ou à me la faire piquer). Si je mets toutes mes clefs dans une puce TCPA sur mon portable, le mec qui m pique mon portable sera bien avancé. Il luis era impossible de sortir les clefs de la zone sans le mot de passe admin de la puce (et même comme çà il pourra juste les transférer sur une autre puce et sera incapable de les lire en clair).
Il n'y a déjà pas d'ouverture possible à Palladium avec les versions actuelles de TPM. C'est inutilisable pour la certification de matériel (toutes les puces et tous les matériels génèrent des hash différents non recoupables - c'est même le but premer de la puce). C'est inutilisable pour l'authentification croisée (chaque "client" TCPA se retrouve dans sa zone personelle avec un identifiant de zone qui change à chaque fois) . C'est Inutilisable pour le DRM (toutes les clefs challengeables sont copiables/migrables/déplaceable - Dieu merci).
Bref pour faire du controle à distance et de la certification globale avec çà bonjour.
"vous acceptez la société comme tiers de confiance"
Comme su le grand ternet. Perso je ne fais pas de paiement sur un site web qui n'a pas un certifica valide. je ne vais pas non plus sur les sites certifiés par Verisign en qui je n'ai aucne confiance (et en plsu généralmeent je me fend d'un email pour dire au vendeur pourquoi je n'ai pas finaliser mon achat.)
couplée avec des fonctions systèmes pour savoir si la machine à la dite puce et ainsi l'identifiée.
La seule fonction accessible depuis système de TCPA/TPM c'est challenge-response. IE on teste a) que l'on a bien à faire à une puce TCPA (éventuellement à distance mais surtut en local) et b) on lui envoit un message et elle renvoit le truc déchiffré. C'est tout ce qu'elle fait.
A noter que les clefs "challengeable" sont copiable d'une zone de la puce vers d'autres zones de la puce mais aussi vers d'autres puces TCPA (la manoeuvre est complexe, mais tout à fait réalisable même sous linux).
Le principal problème est que ces puces permettent l'identification à distance des logiciels et matériels utilisés (remote attestation).
Non, le principal problème C'est que les gens croient celà.
Si tu as activé la fonction et si tu as fait signé ta puce (ou que le constructeur l'a fait pour toi, mais IBM et le seul constructeur et il ne l'a jamais fait) et si tu te connecte à un service particulier et si tu as déclaré un third party de confiance ALORS le service particulier pourra apprendre du third party de ocnfiance si oui ou non tu as une puce TCPA couplée à un système TPM valide.
Rien d'autre.
Il lui sera totalement impossible de savoir si tu es sous windows ou linux ou BSD, si tu as des logiciels pirates ou si tu as du contenu illicite.
Il poura juste vérifie si tu as un système TPM valide.
Rien a voir. Palladiu vise à pouvoir certifié le matériel et le logiciel de façon globale (ie que telle appli et tel matériel sont bien conformes à ce qui est annoncé), TCPA/TPM n'a pas d'autre but que de certifier la cohérence d el'ordi par rapport à lui même. (et maintenant qu'IBM laisse tomber sa division x86 ca ne dervait pas changer).
A titre d'exemple, pour ce que l'on sait de palladium (c'est à dire pas grand chose) il devrait être capable de detecter un disque dur "splitté", c'est à dire un réseau de disque dur en mirroring hardware,d'un disque dur standard. Ceci dans le but d'éviter qu'un fichier DRM copié depuis internet ne se trouve dupliqué n fois suite à un seul paiement.
TPM d'un autre coté ne possède pas d'information de ce type, il signe quand on le lui demande et garde le résultat en interne (il est impossible de faire sortir une signature hardware/software de TPM). Aussi semblable soient-ils, deux disques durs lui apparaitront comme différent, il est donc impossible de certifier "globalement" un ensemble de périphériques.
Personellement je m'en sers déjà et depuis un bon moment, les TPM sont un coffre à clef qui permet de mettre toutes les clef privées dans une boite noire accessible seulement si un certains nombre de conditions sont remplies.
Les condition peuvent être soit un boot particulier (si quelqu'un boote depuis un autre disque dur, depuis une clef USB ou depuis une disquette le coffre ne souvre pas), soit simplement une identification connaissance (par mot de passe saisi par l'uilisateur par exemple).
Ca fait un petit moment que sur mon laptop IBM mes clefs sont dans la boite noire.
Il est bon de rapeler qu'en l'état actuel des choses il est impossible d'utiliser TPM pour empecher de booter un OS ou pour s'assurer qu'un OS certifié "globalement" (c'est à dire que la signature n'a pas été faite sur votre portable) est le seul bootable.
Le problème de l'oeuil est un problème assez complexe, l'oeuil "voit" a une fréquence de l'ordre de 10 images par seconde. En d'autre termes si on fait défiler des images différentes (par exemple une voiture puis un avion puis un jardin puis une montagne etc...) avec une fréquence de plus de 10 images par seconde vous aurez vu un grand flou, et vous ne serez pas capable de dissocier les images.
Par contre au niveau de la perception c'est tout à fait autre chose le cerveau dérière l'oeuil est capable de déduire au niveau de la mémoire à court terme ce qu'à vu l'oeuil, ensuite en fonction du contexte il retiendra l'image comme "pertinente" ou "non pertinente". Néamoins si une même image non pertinente se représente plusieurs fois, ou si vous etes en recherche d'une image précise, votre cerveau pourra alors associer l'information à un contexte ou vous la remonter. Ce sont ce que l'on apelle les images subliminales.
Dans le premier cas (imges hors contexte) le cerveau ne remonte pas l'information au conscient de façon claire, mais il remonte un bloc dans lequel se trouve l'information. Typiquement si vous regardez un doccumentaire sur la montagne et que l'on glisse au millieu une image subliminale sur la mer, votre cerveau associera la montagne en général avec cette image précise de la mer.
Dans le second cas, si par exemple vous chassez des souris dans votre maison de campaqgnes et que votre cerveau et donc réglé sur "recherche de souris", vous pourrez "voir" une souris qui traverse votre champs de vision pendant moins d'un dixième de seconde. Un enfant de quatre ans peut imprimer des images ou suivre le mouvement d'un objet qui a défillé sous ces yeux pendant 1/72eme de seconde, chez l'aldulte de 20 ans le seuil de perception tombe à environ 1/50ème de seconde.
Il y a une grande bataille entre différent groupe scientifique pour savoir si celà est lié au nom au fait que le cerveau tourne à a peu près 100hz et que 1/50s est la durée minimale pour percevoir et confirmer une information et donc se donner la peine (pour le cerveau) de la stoquer.
On peut donc se dire que passer au dessus des 50hz (grand maximum 72hz) ne sert à rien. Toute personne qui a déjà eu un moniteur capable d'afficher en 60hz puis en 75hz-85hz non entrelacé est capable de se rendre compte que ce n'est pas exact. Ce qui joue après c'est le confort de l'oeuil. En d'autre terme le mal que doivent se donner l'oeuil en tent que capteur et le cerveau en tant qu'interpreteur pour "comprendre" l'image. Comme on ne dispose pas à l'heure actuelle de technologie capable de passer instantanément d'une image la suivante en affichage (instantanément étant ici équivalent à un temps de mise en place de l'image cent fois plus court que le temps de présentation ) , et que l'on a au contraire le plus souvent des systèmes ou les deux se recouvrent très largement (ie l'image s'affiche au fur et à mesure qu'elle est déssinée), on a alor sun grand nombre d'informations "parasites" qui sont aux limites de la perception.
Si on fixait toujours le même point à l'écran, pas de problème, les informations défilant à 72hz et plus ne seraient même pas percue. Seulement, le regard parcourt l'écran en permanence la recherche d'informations.
Prenons un exemple, sur un moniteur grand écran (avec un jeu vidéo type FPS) le faisceau se promène sur l'écran à 50hz et tout va bien. D'un coup je décide de baisser la tête pour lire mon score. mon mouvement de haut en bas va "suivre" le canon à electron et mon cerveau aura l'impression que quelquechose cloche. Baisser les yeux va me prendre environ un dixième de seconde, une image "vue" va donc remonter au cerveau, seulement cette image va être cassée en plusieurs morceau, 5 en tout. La partie haute correspondra au premier ballayage, la partie moyen haute au deuxième, la partie moyenne au troisième etc.
Si l'image contenait eu de mouvement ca n'est pas grave, mais si il y en avait beaucoup les 5 morceau peuvent être franchement décalées, l'image ne veut rin dire et le cerveau la met à la poubelle parcequ'elle est ininterpretable. Je viens de perdre un dixième de seconde de vision ce qui est notable. Si une information nouvelle était contenu dans cette image, je mettrais un dixième de seconde de plus que d'habitude à la voir et à réagir.
A 100hz au lieu de 50 je n'aurais pas eu 5 morceau mais 10, par contre ils auraient étés moins décalés et les chances que mon cerveau puisse faire quelque chose de l'image aurait été accrues.
Quand l'image est légèrement floue comme au cinéma, celà adoucit le cassures et permet de la même façon au cerveau de "recoller les morceaux" plus simplement. Les yeux peuvent donc parcourir l'écran de facon plus confortable.
Je dis que ce texte est incompréhensible sans uen aide juridique forte et compétente (chacun son métier, décrypter un résumé de 50 ans d'UE n'est pas le mien).
Je pense que le parlement aurait pu se procurer l'assistance juridique nécessaire sans grosse difficulté, par contre 47 millions de votants à conseiller de façon non partisanne c'est beaucoup plus dur.
Là je t'arrête tout de suite : plus de 69% des électeurs français se sont exprimés. Leur avis est donc largement représentatif de la population française, et il est insultant d'entendre que, sous prétexte que tu n'es pas du même avis, tu leur dénis le droit à s'exprimer politiquement, souverainement et démocratiquement.
Houlà ! C'est a mon tour de t'arréter tout de suite, je ne dénie rien du tout aux francais. L'idée que je voulais faire passer est la suivante : le texte du TCE est complètement cryptique, et il est totalement illisible pour un non initié. C'est aprfaitement compréhensible, ce texte prend en compte 50 ans de lois et de jurisprudences en essayant de les harmoniser et en ajoutant une dimension politique absente jusque là. Une grande majorité des francais ne peut pas comprendre ce texte (et ce n'est pas une question de clivage politique, je doute fort que MM Chirac, Hollande ou Fabius le puisse par eux-même). Si j'ai raison (et je pense sincèrement avoir raison) il est alors absurde de faire voter un texte à des gens qui ne peuvent pas le comprendre. Il fallait soit faire un texte simple, soit le faire adopter directement par le parlement. Personellement je ne vois rien d'autre dans ce référendum qu'une tentative de M Chirac de remonter dans les sondages.
Pour le reste de ton post je suis tout à fait d'accord avec toi, mais je ne peux qu'exprimer du dégout face aux arguments qui ont étés retenus d'un coté comme de l'autre pour mener la campagne. Le combat entre les annonciateurs de l'apocalypse contre les pourfendeurs d'ultralibéralisme m'ont donné la nausée. Je pense que les partisans du non avaient avec eux des réthoriciens plus habiles ou plus culotés que ceux du oui. Pour moi le visage de cette campagne restera celui de M Delors déboussolé et incapable de défendre le TCE devant les caméras tant les arguments qu'on lui soumettait étaient distant de la réalité du texte.
Tu ne pourrais pas imaginer que certains (et sûrement plus de 1%) ont lu (et compris!) le traité et n'en ont pas accepté les modalités ? Ca te semble si inconcevable ?
A mon avis, sur les 47 millions de votans ca m'étonnerais beaucoup qu'il y en ai 470 000 capables de lire le TCE, de le comprendre et d'évaluer ce qui a été harmonisé et ce qui a été modifié par eux même.
J'ignore si je susi d'une inculture crasse en ce qui concerne les lois Européennes, mais uen chose est sure ce traité (que j'ai lu plusieurs fois) n'a délivré son sens véritable qu'après qu'un juriste de haute volée ait décidé de m'assister dans ma lecture. Le nombre de contre-sens que je faisais sur chaque article était proprement impressionnant.
Combien de juriste capable de décrypter le TCE existent en France ? Et parmis eux combien se sont donnés la peine de le décrypter par eux-même ?
Je n'irais pas jusqu'à dire que 470 000 me semble inconcevable, mais je serais quand même très surpris.
La France a certainement provoqué un tumulte au sein des pays Européens, mais je ne pense pas qu'elle soit déjà affaiblie. Voyons les choses en face : On est déjà a peu près sur que les Pays Bas, l'Irlande, le Danemark, et la Grande Bretagne vont voter non. Ca fait 5 pays sur 25 qui ne ratifiront pas le TCE. De fait les chances de survie de ce traité sont minces. (A partir de 6 pays qui rejettent le traité, celui ci est automatiquement rejeté pour l'ensemble de l'Europe). La France va donc peut-être être à la source d'une renégociation du traité. Cette renégociaition n'aura probablement pas la "couleur" souhaité par les pouvoirs qui ont appelés à voter non, mais il est difficile de savoir à l'avance ce qui va se passer dans (au moins) cinq ans.
Les français ont votés non pour un bon nombre de raisons, parmis elle se trouve le fait qu'ils n'auraient du être consultés. Le charabia verbeux du TCE nécessite un juriste hautement qualifié pour être décrypté, quand les francais ont cherchés à comprendre ce qu'était ce texte ils ont eu le choix entre les raccourcis faciles et mensongers des politiques de différents bords (tant en faveur du non que du oui) et dix ans de formation à la legislation européenne. Le choix a été vite fait, et les mensonges du non étaient mieux ficelés que ceux du oui. En plus l'attitude "On sait ce qui est bon pour vous, voter non serait puéril, inconscient dangereux et déplacé" en a ennervé plus d'un. Donc PAF.
Maintenant il est important de savoir ce que la France va faire de son non. On eput déjà dire que l'Europe a enfin pris la place qui lui revient dans la tête des Francais, on est loin du taux de participation des précédentes élections, et le premier ministre s'est abstenu de chaudement féliciter une équipe sportive quelconque aujourd'hui. C'est toujours ça de pris. Ceci étant M Chirac a l'air bien décidé à tout faire pour "excuser" ce non auprès des autres pays, ce qui a mon avis n'est pas la bonne façon de faire. Reste aussi à voir si le sFrancais vont se lever et défendre leur vision de l'Europe ou si ils vont retomber dans un état euro-végétatif.
[^] # Re: et oui les TPM ... le contraire
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
Pas un seul instant.
Le Hash ne sort pas des puces.
Si il sortait, il ne serait pas exploitable car dépendant de la plateforme au sens strict du terme (ie deux PC du même modèle, de la même année n'ont pas les mêmes hashs (testé avec migration de disque dur dont le numéro de série a été forcé sur des x31, ca marche pas))
Si il sortait et qu'il était exploitable, les clefs déposées dans la zone signée seraient déplaçables et donc exploitable à postériori (on aurait besoin d'un système propre pour obtenir les clefs) et après on fait ce que l'on veut)
Si le hash sortait, qu'il soit exploitable et que l'on ne puisse pas bouger les clefs il faudrait encore que le matériel environant (disque dur, carte son, écran etc) intégre aussi un TPM pour pouvoir dialoguer avec celui de la carte mère et se bloquer le cas échéant en cas de non conformité.
On a carrèment de la marge entre maintenant et la zone rouge.
[^] # Re: "remote attestation" avouée clairement par why_tcpa d'IBM
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
report signed PCR information
Avant d ecommencer, j'attire juste ton attentio que la puce TCPA ne renvoit pas les hash mais créé des reports signés en dfonction du PCR. On est donc bien dans le cadre challenge/response. Ouf.
L'excuse donnée par ce document de 2002 fait aujourd'hui sourire:
oui mais c'est dur car il faudrait stocker les hashs des BIOS des OS dans une grosse base de donnée.
C'est clair, ca fait sourire, on voit tout à fait uen base de données contenir les quelques huit milliards de config bios d'uen machine, l'infinité des partionnements valides et se mettre à jour au fur et à mesure des mises à jour windows ou du lecteur de contenu. Ca fait quoi 2-3 To par utilisateurs grand maximum. Une paille quoi.
Tout ca pour quoi ? Empécher un utilisateur d'accéder à un contenu distant, tout en sachant que si il y accède une fois après authentification il pourra faire ce qu'il veut de la clef et la déplacer si besoin est dans une zone moins restrictive ? Ca vaut le coup.
Je ne comprend vraiment pas pouquoi l'ensemble des magnats de la vidéos et du son ne se sont pas jetés sur cette magnifique opportunité.
Même google ne donne que 2go par utilisateur, c'est environ le millième de ce qui serait nécessaire.
[^] # Re: et oui les TPM ... OS fiable avant tout, remote attestion grave
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 3.
Sur un doccument de 300 pages, il y a 10 pages sur la remote attestation. Il n'existe pour l'instant aucun tiers de confiance utilisable globalement (ie un équivalent verisign pour les certificats), aucun fournisseurs qui demende la présence de TPM pour l'accès à certains service (et je dis juste demande, pas exige), la fonctionnalité est désactivée par défaut et le vendor ID est laissé à blanc.
On sent bien là qu'il s'agit de LA priorité d'IBM quand il s'agit de la puce TCPA.
Le remote attestation aura des répercusions très graves sur nos libertés
C'est clair, un vendeur pourrait vérifier, via agrément d'un tiers de confiance, que la machine distante est bien celle qu'il connait dans uen config qu'il connait. C'est presque aussi intrusif qu'un cookie et presque aussi dangeureux que l'installation d'un certificat local pour l'accès à un service.
alors que d'autres techniques permettent aussi d'améliorer la sécurité d'un ordi mais sans permettre le remote attestation.
C'ets sur au sein d'un parc de PCs il existe pleins de techniques aussi simple et aussi fiable pour vérifier de façon fiable la non compromission des machines clientes par un serveur. On peut citer par exemple..... je sais plus, mais il y en a plein en tout cas. Trop même.
Seul un refus de toutes les puces qui permettent le remote attestation nous permettra d'éviter d'être obligé d'avoir un OS drm non modifiable et des matériels drm, pour pouvoir se connecter.
C'est clair aussi. On rejette violamment une puce qui ne permet en aucun cas de faire la moindre incursion dans DRM et au final on aura jamais de matos drm dans nos PCs. C'est magique, faut pas chercher à comprendre.
On crache très fort sur TCPA et on fera disparaitre les firmwares lockés sur les lecteur DVD.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
Ca serait une catastrophe.
C'ets pour çà que j'aime beaucoup la puce TCPA, parcequ'elle ne permet en aucun cas de faire ce genre de choses. Elle eprmet totu au plus de vérifier que l'on a bien à faire à une config identique à la config précédente. Et encore, dans la mesure ou l'admin de la puce joue le jeu.
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 4.
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 3.
Donc pour toi la puce envoie directement les hashs brut de fonderie au tiers de confiance (ou alors directement au tiers client )?
Si tu prend tes propres docs (en version PDF de préférence, les schémas sont illisibles sur la version HTML) Notamment celui ci : http://byte.csc.lsu.edu/~durresi/7502/reading/rc23064.pdf(...) à la page 8 figure 2 section "remote attestation"
on y voit clairement que les mesures métriques effectuées par les agents ne sortent jamais de la puce. Le service d'attestation recoit une demande sous forme de challenge et renvoit une response. C'est un cas très classique de preuve par déchiffrage de message dans le cadre d'une certification.
De toute façon, même si les hashs sortaient ils seraient inutilisables. tout d'abord parceque les hashs sont différents (très) sur chaque plateforme, et ensuite parcequ'ils varient d'un boot à l'autre (et oui une carte graphique à 50°c n'aura pas le même hash que la même carte graphique à 20°c). C'ets pas un jeu complexe d'échange entre le TPM et les agents de mesures que le matériel est certifié. (Un peu comem pour les empreintes digitales, le TPM cherche des "points de correspondance" quand il en a suffisament il valide, si ca ne marche pas il rejette).
Bref l'interet de faire sortir les hashs de la puce TCPA est rigoureusement nul.
P.S : j'ai beau chercher je ne vois nulle part mention de l'idée de faire sortir les hash de la puce.
[^] # Re: et oui les TPM ... taille données / taille des clés, ratio crucial
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 5.
Si c'est un truc qui a une chance sur dix milliards de marcher, ou qui nécessite des conditions de réalisation monstrueuses (genre réussir à placer une interruption illégale dans un appel système que je ne controlle pas) je ne mets pas à jour.
Pourquoi ? Parceque j'ai déjà des maillons beaucoup plus faibles dans ma chaine de sécurité. Pas la peine de surblinder uen étape si els étapes environnantes ne sont pas au même niveau.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
Le truc par défaut c'est :
En admin : Créer une signature de boot, créer une identité, créer un profil. Lier l'identité avec la signature de boot et accorder les droits en lecture écriture au profil.
Avec le Profil : Déclarer un tiers de confiance, valider l'identité auprès du tiers et sauvegarder la clef d'authenticité dans le profil.
Ca n'ets pas exactement "trivial". Comme la clef ne peut pas être préchargée (interdit par la norme TCPA) à une exception près : identité puce sans signature de boot (laquelle est désactivée par défaut et non chargé par IBM) ca fait quand même du boulot entre le "par défaut" et le truc hautement intrusif.
Pas convaincu : les carte "pirates" pour les bouquets satellites sont casses en 6 mois a peu pres. pourtant ils donnent pas leurs hdl ni leurs cles.
il y a quelques mois ti avait une puce qui servait a l'authentification des voitures. La aussi securite par obfuscation. Paf casse.
Les deux cas que tu donnes appartienent à un paradigme complètement différent, celui ou l'on cherche à garder un secret vis à vis de l'utilisateur final. Sous TCPA il n'y a pas besoin d'utiliser de la force brute, toutes les clefs sont utilisables par l'utilisateur en 10 secondes via migration de zone. Ici on ne cherche pas à protéger le contenu de l'utilisateur, mais du reste du monde.
Typiquemetn dans le cas de technos DRM on cherche à masquer la clef privée le plus possible, mais on est obligé de la donner quand même (sinon l'utilisateur ne peut pas lire le support). TCPA ne cherche absolument pas à faire celà. Toutes les clefs sont toujours accessibles/migrables et donc utilisables dans toutes les situations. Aucun rapport donc avec ce que tu cites.
Tu dis que tu sais exactement ce qui se passe; donc tu as eu le hdl et tu sais le lire?
J'ai eu entre les mains le doc qui permet à un constructeur de fabriquer sa propre puce TCPA dans les normes. Je peux donc dire que je connais le fonctionnement de l'ensemble de la puce à deux exceptions pret (vu que je n'ai pas voulu signer de NDA).
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 4.
C'est autrement plus intrusif !
GNNNIIII ?????
Le remote attestation permet en passant par un tiers de vérifier que la clef que tu as fait créer par le tiers et qui a été transmise depuis le TPM du tiers jusque dans ton TPM est bien présent et de certifier cette information auprès d'un autre tiers.
C'est exactement l'équivalent des certicats "classiques" sauf que celà se joue entre TPM.
Pour finir il n'y a que deux choses qui peuvent sortir du TPM : soit un message décodé (par exemple suite à un challenge response, ou dans le cadre normal de l'utilisation du TPM pour déchiffrer un message); soit une clef migrable a condition que ce soit vers un autre TPM et seulement via une connection sécurisé.
Relis bien le document de TCG que j'ai cité ci-dessus où ils reconnaissent que cette remote attestation est un fait.
On va pas reprendre le troll ici. Je t'ai déjà démontré, il y a un an que
a) La config sur laquelle un tiers insiste même si il n'y a pas de raison sécuritaire à un tel choix est une config précédamment rencontrée. En d'autres termes le tiers client peut s'assurer via le tiers de confiance que tu as bien toujours la même config que celle créée précédamment. il ne peut en aucun cas en déduire ton OS, tes disques durs, ta carte graphique ou quoi que ce soit d'autre.
b)Toutes les clefs accessibles de l'extérieur sont migrables. En d'autres termes tu peux parfaitement déplacer la clef de ton tiers client d'une zone à une autre. dans ce cas tu nepourras plus être validée par remote attestation, mais tu pourras toujours lire l'ensemble des doccuments qui ont étés cryptés avec cette clef (ce qui limite vachement l'utilisation dans le cadre du DRM). Si tu veux continuer à faire de la remote attestation, tu peux aussi simplement copier la clef. La copie dans la zone certifiée sera toujours valide aux yeux du tiers client, la copie dans une zone plus laxiste sera utilisable comme bon te semble.
Au final cette technique n'est utile que pour un admin qui veut vérifier que ses machines n'ont pas étés compromises avant de les admettre sur le réseau (par exemple). A part çà...
[^] # Re: et oui les TPM ... OS fiable avant tout
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 1.
Et l'analyse métrique du système
Et l'unlock automatique de clef fontion du boot et des interactions utilisateurs
Et le coffre hardware dont les clefs ne sortent jamais en clair
Et l'idépendance du système d'exploitation
Et la migration automatique clef/droit/zone d'un PC à un atre sans compromission possible sauf altération physique de haute volée.
Mais sinon rien. Une paille en somme.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
La seule façon de bloquer un système via la puce TCPA serait d'avoir dans la puce des clefs extérieures préchargées qui serviaient à autre chose que d'authentifier la puce auprès d'une autre puce. Ce cas est formellement interdit par la norme TCPA. De plus il faudrait aussi que l'utilisateur principal de la machine ne soit pas admin (ce qui est aberrant, il ne pourrait alors plus se servir de la puce) o que les clefs soient accessibles de l'extérieur mais non déplaçable/migrable, ce qui est également interdit par la norme. Pour finir il faudrait également que le matériel soit capable de tirer partie de ces informations, ce qui implique d'avoir un système TPM non seulement sur la carte mère, mais aussi sur les parties que l'on veut bloquer (doncTPM sur disque dur/carte son/lecteur vidéo etc.) Bref on aura encore une chance de voir venir si c'est l'orientation que prennent les choses.
De plus la sécurite par l'obfuscation est rarement une bonne chose
Houlà, c'est pas uen boite noire au sens "on sait pas trop ce qu se passe dedans", c'est uen boite noire au sens "bonne chance pour récupérer la clef les gars". Suite au troll avec Free2org je sais exactement ce qui se passe dans ma puce TPM - vu que je n'utilise pas et que j'ai désactivé les fonctions non parfaitement doccumentés (ie identification puce à puce et identification ditsitante certifiée par tiers)
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
a) le générateur d'aléas - on ne sai pas comment il marche et IBM n'était pastrès causant à ce sujet.
b) la clefs d'authentification TPM qui permet à un système TPM de prouver à un autre système TPM qu'il est bien un système valide. La raison pour laquelle cette clef n'est pas connue est probablement parcequ'il s'agit d'une clef privée ou équivalent plus ou moins complexe. les clefsprivées ont la sale (ou la bonne) habtde de ne pas être conne de tous.
A part çà le reste est très simple. Il y a une couche crypto interne (pour controller l'intégrité de la puce et sécurisé le contenu des coffres), une couche crypto externe pour générer les clefs et une couche de dialogue utilisateur. Bref c'est à peu de chose pret un serveur PKI on die avec une authentification masquée.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 4.
Pour aller plus loin que Beretta je dirais ceci : il est trivial de démontrer que tripwie ne sera jamais secure.
Tripwire n'est pas un OS complet, donc pour se lancer, s'initialiser et effectuer ses différentes opérations il est obligé (comme tout le monde) de lancer des appels systèmes et de "faire confiance" à la réponse. tant que tripwire ne sera pas le coeur du kernel (ie le premier truc chargé) il ne pourra pas s'assurer que le système amont n'a pas été corrompu. Il sera obligé de "croire" le système quand celui-ci lui renverra les infos concernant un repertoire précis ou un démon en train de tourner. Entre autre tripwire est incapable de se certifer lui même indépendamment du système. La puce TCPA le peut.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 4.
Pour faire uen réponse claire : par ce que ca ne sert à rien. On a trouvé un cas hyper particulier dans lequel il ets possible de générer "raisonablement" facilement deux fichiers ayant la même signature.
Ce n'est pas l prmeière fois que celà se produit. il y avait par exemple dans le tout premier aogorithme RSA une faille qui faisait que pour certains nombe premiers "spécifiques" il était possible de retrouver les deux facteurs d'un produit de nombre premiers en un temps raisonablement court (complexité n² au lieu de de coplexité exponentielle).
A-t-on abandonné le système immédiatement pour autant ? Non. On a juste ajouter une fonction pour éviter ces cas particuliers.
Pour en revenir à SHA-1, il eut se passer deux choses : soit le cas décrit est un truc vraiment très particulier innutilisable ailleurs. A ce moment la il existe une "faille" dans SHA-1 qui permet à un utilisatur de générer deux fichiers ayant le même hash. Utilisabilité en usurpation : 0.
Soit il existe une propriété algénrique non connue qui vient d'être mise en exemple par un cas spécifique sur SHA-1, et alors si elle est généralisée et démontrée rien ne dit qu'elle n'impactera que SHA-1. On est même plutôt tenté de penser que c'est l'ensemble des calculs de hash qui va être impacté (Si c'ets une propriété algébrique globale, il y a peu de chance que MD5, par exemple, ne soit pas impacté aussi).
Bref soit c'est inutilisable, soit il y a de bonnes chances que ca impacte tout le monde. Les raisons de rejeter SHA-1 sont donc réduite.
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 3.
C'est sur on a jamais vu un système identifier un autre système à distance sur la foi d'une clef ou d'un mot de passe. C'est tout nouveau ca vient de sortir. Par exemple les licences MS ne sont pas du tout validées à distance et locké par PC. Du tout.
2. Toutes les autres fonctions TCG ne sont pas nouvelles et sont possibles autrement (les coprocesseurs de crypto existent depuis longtemps, de meme les supports avec mode read-only pour booter dessus en sécurité).
Bien sur aussi, on a depusi longtemps uen boite noire qui fait coffre à clef que l'on peut remplir à volonté et dont les clefs sont inextractibles en clair. Ca existe depuis super longtemps et TPM n'apporte rien.
La façon efficace de lutter contre cela est de refuser d'avoir ces puces
Je te rassure, c'est déjà fait. TPM est en voie de mort rapide. Les normes v2 n'ont jamais vu le jour et les systèmes parallèles ont appris à se faire discret pour rentrer sur nos systèmes en douce. On ne peut que féliciter les gens qui par leur boycott ont tué dans l'oeuf une techno fiable, utile et ouverte, laissant ainsi la porte grande ouverte aux bios plombés, au matos adaptatif et au options de sécurités imposés par les grands groupes et dont les specs sont bien cachés.
Je ne vais pas reprendre ce troll vec toi. Mais au moins essaye d'éviter le FUD par pitié.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 4.
Il n'y a déjà pas d'ouverture possible à Palladium avec les versions actuelles de TPM. C'est inutilisable pour la certification de matériel (toutes les puces et tous les matériels génèrent des hash différents non recoupables - c'est même le but premer de la puce). C'est inutilisable pour l'authentification croisée (chaque "client" TCPA se retrouve dans sa zone personelle avec un identifiant de zone qui change à chaque fois) . C'est Inutilisable pour le DRM (toutes les clefs challengeables sont copiables/migrables/déplaceable - Dieu merci).
Bref pour faire du controle à distance et de la certification globale avec çà bonjour.
[^] # Re: TPM, TCPA, TCG, "remote attestation"
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 4.
Comme su le grand ternet. Perso je ne fais pas de paiement sur un site web qui n'a pas un certifica valide. je ne vais pas non plus sur les sites certifiés par Verisign en qui je n'ai aucne confiance (et en plsu généralmeent je me fend d'un email pour dire au vendeur pourquoi je n'ai pas finaliser mon achat.)
couplée avec des fonctions systèmes pour savoir si la machine à la dite puce et ainsi l'identifiée.
La seule fonction accessible depuis système de TCPA/TPM c'est challenge-response. IE on teste a) que l'on a bien à faire à une puce TCPA (éventuellement à distance mais surtut en local) et b) on lui envoit un message et elle renvoit le truc déchiffré. C'est tout ce qu'elle fait.
A noter que les clefs "challengeable" sont copiable d'une zone de la puce vers d'autres zones de la puce mais aussi vers d'autres puces TCPA (la manoeuvre est complexe, mais tout à fait réalisable même sous linux).
[^] # Re: TPM, TCPA, TCG, "remote attestation"
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 10.
Non, le principal problème C'est que les gens croient celà.
Si tu as activé la fonction et si tu as fait signé ta puce (ou que le constructeur l'a fait pour toi, mais IBM et le seul constructeur et il ne l'a jamais fait) et si tu te connecte à un service particulier et si tu as déclaré un third party de confiance ALORS le service particulier pourra apprendre du third party de ocnfiance si oui ou non tu as une puce TCPA couplée à un système TPM valide.
Rien d'autre.
Il lui sera totalement impossible de savoir si tu es sous windows ou linux ou BSD, si tu as des logiciels pirates ou si tu as du contenu illicite.
Il poura juste vérifie si tu as un système TPM valide.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 5.
C'est TCPA
c'est le retour de Palladium/NGSCB ?
Rien a voir. Palladiu vise à pouvoir certifié le matériel et le logiciel de façon globale (ie que telle appli et tel matériel sont bien conformes à ce qui est annoncé), TCPA/TPM n'a pas d'autre but que de certifier la cohérence d el'ordi par rapport à lui même. (et maintenant qu'IBM laisse tomber sa division x86 ca ne dervait pas changer).
A titre d'exemple, pour ce que l'on sait de palladium (c'est à dire pas grand chose) il devrait être capable de detecter un disque dur "splitté", c'est à dire un réseau de disque dur en mirroring hardware,d'un disque dur standard. Ceci dans le but d'éviter qu'un fichier DRM copié depuis internet ne se trouve dupliqué n fois suite à un seul paiement.
TPM d'un autre coté ne possède pas d'information de ce type, il signe quand on le lui demande et garde le résultat en interne (il est impossible de faire sortir une signature hardware/software de TPM). Aussi semblable soient-ils, deux disques durs lui apparaitront comme différent, il est donc impossible de certifier "globalement" un ensemble de périphériques.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 3.
Personellement je m'en sers déjà et depuis un bon moment, les TPM sont un coffre à clef qui permet de mettre toutes les clef privées dans une boite noire accessible seulement si un certains nombre de conditions sont remplies.
Les condition peuvent être soit un boot particulier (si quelqu'un boote depuis un autre disque dur, depuis une clef USB ou depuis une disquette le coffre ne souvre pas), soit simplement une identification connaissance (par mot de passe saisi par l'uilisateur par exemple).
Ca fait un petit moment que sur mon laptop IBM mes clefs sont dans la boite noire.
Il est bon de rapeler qu'en l'état actuel des choses il est impossible d'utiliser TPM pour empecher de booter un OS ou pour s'assurer qu'un OS certifié "globalement" (c'est à dire que la signature n'a pas été faite sur votre portable) est le seul bootable.
[^] # Re: Outch !
Posté par Jerome Herman . En réponse à la dépêche Nexuiz 1.0. Évalué à 10.
Par contre au niveau de la perception c'est tout à fait autre chose le cerveau dérière l'oeuil est capable de déduire au niveau de la mémoire à court terme ce qu'à vu l'oeuil, ensuite en fonction du contexte il retiendra l'image comme "pertinente" ou "non pertinente". Néamoins si une même image non pertinente se représente plusieurs fois, ou si vous etes en recherche d'une image précise, votre cerveau pourra alors associer l'information à un contexte ou vous la remonter. Ce sont ce que l'on apelle les images subliminales.
Dans le premier cas (imges hors contexte) le cerveau ne remonte pas l'information au conscient de façon claire, mais il remonte un bloc dans lequel se trouve l'information. Typiquement si vous regardez un doccumentaire sur la montagne et que l'on glisse au millieu une image subliminale sur la mer, votre cerveau associera la montagne en général avec cette image précise de la mer.
Dans le second cas, si par exemple vous chassez des souris dans votre maison de campaqgnes et que votre cerveau et donc réglé sur "recherche de souris", vous pourrez "voir" une souris qui traverse votre champs de vision pendant moins d'un dixième de seconde. Un enfant de quatre ans peut imprimer des images ou suivre le mouvement d'un objet qui a défillé sous ces yeux pendant 1/72eme de seconde, chez l'aldulte de 20 ans le seuil de perception tombe à environ 1/50ème de seconde.
Il y a une grande bataille entre différent groupe scientifique pour savoir si celà est lié au nom au fait que le cerveau tourne à a peu près 100hz et que 1/50s est la durée minimale pour percevoir et confirmer une information et donc se donner la peine (pour le cerveau) de la stoquer.
On peut donc se dire que passer au dessus des 50hz (grand maximum 72hz) ne sert à rien. Toute personne qui a déjà eu un moniteur capable d'afficher en 60hz puis en 75hz-85hz non entrelacé est capable de se rendre compte que ce n'est pas exact. Ce qui joue après c'est le confort de l'oeuil. En d'autre terme le mal que doivent se donner l'oeuil en tent que capteur et le cerveau en tant qu'interpreteur pour "comprendre" l'image. Comme on ne dispose pas à l'heure actuelle de technologie capable de passer instantanément d'une image la suivante en affichage (instantanément étant ici équivalent à un temps de mise en place de l'image cent fois plus court que le temps de présentation ) , et que l'on a au contraire le plus souvent des systèmes ou les deux se recouvrent très largement (ie l'image s'affiche au fur et à mesure qu'elle est déssinée), on a alor sun grand nombre d'informations "parasites" qui sont aux limites de la perception.
Si on fixait toujours le même point à l'écran, pas de problème, les informations défilant à 72hz et plus ne seraient même pas percue. Seulement, le regard parcourt l'écran en permanence la recherche d'informations.
Prenons un exemple, sur un moniteur grand écran (avec un jeu vidéo type FPS) le faisceau se promène sur l'écran à 50hz et tout va bien. D'un coup je décide de baisser la tête pour lire mon score. mon mouvement de haut en bas va "suivre" le canon à electron et mon cerveau aura l'impression que quelquechose cloche. Baisser les yeux va me prendre environ un dixième de seconde, une image "vue" va donc remonter au cerveau, seulement cette image va être cassée en plusieurs morceau, 5 en tout. La partie haute correspondra au premier ballayage, la partie moyen haute au deuxième, la partie moyenne au troisième etc.
Si l'image contenait eu de mouvement ca n'est pas grave, mais si il y en avait beaucoup les 5 morceau peuvent être franchement décalées, l'image ne veut rin dire et le cerveau la met à la poubelle parcequ'elle est ininterpretable. Je viens de perdre un dixième de seconde de vision ce qui est notable. Si une information nouvelle était contenu dans cette image, je mettrais un dixième de seconde de plus que d'habitude à la voir et à réagir.
A 100hz au lieu de 50 je n'aurais pas eu 5 morceau mais 10, par contre ils auraient étés moins décalés et les chances que mon cerveau puisse faire quelque chose de l'image aurait été accrues.
Quand l'image est légèrement floue comme au cinéma, celà adoucit le cassures et permet de la même façon au cerveau de "recoller les morceaux" plus simplement. Les yeux peuvent donc parcourir l'écran de facon plus confortable.
[^] # Re: Il n'y a pas de honte à avoir
Posté par Jerome Herman . En réponse au journal J'ai honte d'être français !. Évalué à 1.
Je pense que le parlement aurait pu se procurer l'assistance juridique nécessaire sans grosse difficulté, par contre 47 millions de votants à conseiller de façon non partisanne c'est beaucoup plus dur.
[^] # Re: Il n'y a pas de honte à avoir
Posté par Jerome Herman . En réponse au journal J'ai honte d'être français !. Évalué à 2.
Houlà ! C'est a mon tour de t'arréter tout de suite, je ne dénie rien du tout aux francais. L'idée que je voulais faire passer est la suivante : le texte du TCE est complètement cryptique, et il est totalement illisible pour un non initié. C'est aprfaitement compréhensible, ce texte prend en compte 50 ans de lois et de jurisprudences en essayant de les harmoniser et en ajoutant une dimension politique absente jusque là. Une grande majorité des francais ne peut pas comprendre ce texte (et ce n'est pas une question de clivage politique, je doute fort que MM Chirac, Hollande ou Fabius le puisse par eux-même). Si j'ai raison (et je pense sincèrement avoir raison) il est alors absurde de faire voter un texte à des gens qui ne peuvent pas le comprendre. Il fallait soit faire un texte simple, soit le faire adopter directement par le parlement. Personellement je ne vois rien d'autre dans ce référendum qu'une tentative de M Chirac de remonter dans les sondages.
Pour le reste de ton post je suis tout à fait d'accord avec toi, mais je ne peux qu'exprimer du dégout face aux arguments qui ont étés retenus d'un coté comme de l'autre pour mener la campagne. Le combat entre les annonciateurs de l'apocalypse contre les pourfendeurs d'ultralibéralisme m'ont donné la nausée. Je pense que les partisans du non avaient avec eux des réthoriciens plus habiles ou plus culotés que ceux du oui. Pour moi le visage de cette campagne restera celui de M Delors déboussolé et incapable de défendre le TCE devant les caméras tant les arguments qu'on lui soumettait étaient distant de la réalité du texte.
[^] # Re: Journal : J'ai honte d'être français !
Posté par Jerome Herman . En réponse au journal J'ai honte d'être français !. Évalué à 10.
A mon avis, sur les 47 millions de votans ca m'étonnerais beaucoup qu'il y en ai 470 000 capables de lire le TCE, de le comprendre et d'évaluer ce qui a été harmonisé et ce qui a été modifié par eux même.
J'ignore si je susi d'une inculture crasse en ce qui concerne les lois Européennes, mais uen chose est sure ce traité (que j'ai lu plusieurs fois) n'a délivré son sens véritable qu'après qu'un juriste de haute volée ait décidé de m'assister dans ma lecture. Le nombre de contre-sens que je faisais sur chaque article était proprement impressionnant.
Combien de juriste capable de décrypter le TCE existent en France ? Et parmis eux combien se sont donnés la peine de le décrypter par eux-même ?
Je n'irais pas jusqu'à dire que 470 000 me semble inconcevable, mais je serais quand même très surpris.
# Il n'y a pas de honte à avoir
Posté par Jerome Herman . En réponse au journal J'ai honte d'être français !. Évalué à 10.
Les français ont votés non pour un bon nombre de raisons, parmis elle se trouve le fait qu'ils n'auraient du être consultés. Le charabia verbeux du TCE nécessite un juriste hautement qualifié pour être décrypté, quand les francais ont cherchés à comprendre ce qu'était ce texte ils ont eu le choix entre les raccourcis faciles et mensongers des politiques de différents bords (tant en faveur du non que du oui) et dix ans de formation à la legislation européenne. Le choix a été vite fait, et les mensonges du non étaient mieux ficelés que ceux du oui. En plus l'attitude "On sait ce qui est bon pour vous, voter non serait puéril, inconscient dangereux et déplacé" en a ennervé plus d'un. Donc PAF.
Maintenant il est important de savoir ce que la France va faire de son non. On eput déjà dire que l'Europe a enfin pris la place qui lui revient dans la tête des Francais, on est loin du taux de participation des précédentes élections, et le premier ministre s'est abstenu de chaudement féliciter une équipe sportive quelconque aujourd'hui. C'est toujours ça de pris. Ceci étant M Chirac a l'air bien décidé à tout faire pour "excuser" ce non auprès des autres pays, ce qui a mon avis n'est pas la bonne façon de faire. Reste aussi à voir si le sFrancais vont se lever et défendre leur vision de l'Europe ou si ils vont retomber dans un état euro-végétatif.
Bref il est encore un peu tôt pour avoir honte.