Les eurodéputés ont ajouté un paragraphe précisant qu'une "invention mise en oeuvre par ordinateur (un logiciel) n'est pas considérée comme apportant une contribution technique uniquement parce qu'elle implique l'utilisation d'un ordinateur".
En clair, pour qu'un programme informatique soit brevetable, il ne suffit pas qu'il soit nouveau, il faut encore qu'il permette une innovation technique indépendamment de sa propre exécution.
Mais avec beaucoup de mauvaise foi, on peut mettre beaucoup de chose dedans. Par exemple, la technique d'affichage du pointeur souris a l'aide de Xor (brevet reel) peut-etre vu comme ayant un effet physique (ecran, affichage, ...)
Les algos de micro-typographie (brevets Adobe, je pense) ont un effet technique sur le papier imprime.
Utiliser un clavier Dvorak n'a d'interet que si on tape en aveugle.
Pour apprendre a taper en aveugle, la regle numero 1 est de ne jamais regarder ses doigts. Quoi qu'il arrive. La premiere touche a apprendre est donc 'backspace'.
Au debut, c'est tres dur, on tape 3 mots par minute. Puis on s'y fait. Ca vient tres vite.
Acheter un nouveau clavier serait donc une erreur.
SURTOUT, ne pas croire qu'on va apprendre plus vite a taper parcequ'on a un clavier avec le dessin des lettres au bon endroit. Le but final est de toute facon la frappe en aveugle. Et on l'atteint beaucoup plus vite en apprenant en aveugle.
Il faut savoir que la plupart des protocoles fonctionnent de la facon suivante, pour calculer la signature d'un fichier:
On decoupe le fichier en "chunks" (9.5 Mo pour mldonkey, ~256 Ko pour bittorrent). On calcule le hash (MD4, SHA1...) de chaque chunk. La signature du fichier est le hash de la concatenation des hashs de tous les chunks.
Grace a cette methode, on peut verifier l'integrite de bouts de fichier qu'on possede deja, avant d'avoir l'integralite du fichier. Cela permet de commencer a uploader alors qu'on n'a pas tout downloader, ainsi que de detecter qu'un "peer" nous uploade n'importe quoi (Et grace au "mods" emule, y'en a plein).
A partir de la, c'est facile de downloader sur plusieurs reseaux:
On recherche sur tous les reseaux, les fichiers contenant la chaine "redhat" et de taille 762 154 782 Octets. Il est hautement probable que tous ces fichiers sont les memes, a quelques mutations pres.
On commence a downloader tous ces fichiers. Pour donner un exemple, je vais les nommer:
* Je suppose que deux fichiers repondaient aux criteres precedants sur le reseau edonkey. Je les appelle E1 et E2.
* Sur Faststrack, il y en avait 3: F1, F2 et F3.
* Sur Bittorrent, un seul: B1
* ...
Parmi tous ces fichiers, j'en choisis un qui est la reference. On va dire que c'est E1.
Je detecte que j'ai telecharge sur F1, l'equivalent d'un chunk de E2. Je calcule alors la signature edonkey de ce chunk (que j'ai telecharge sur Fasttrack) et je me rends compte que c'est la signature attendue. Je marque alors ce chunk comme telecharge pour E2.
Et ainsi de suite...
Quand mon fichier de reference (E1) est termine, ben je suis content. C'est celui que je voulais a la base. J'interromps alors tous les autres car j'ai fini.
Ce systeme marche, meme si les fichiers ne sont pas exactement les memes. En general, ce sont toujours des mutations d'une meme source. Par exemple E1 et E2 auront exactement les memes chunks, sauf 1. Cela sera donc tres rentable de downloader des bouts de E1 sur E2. Comme E1 est la reference, on peut meme decider de ne jamais downloader le chunk qui differe entre E1 et E2 (petite optimisation facile a faire). Si E1 et F1 sont differents, on ne peut pas s'en rendre compte (a cause du schema de signature qui n'est pas le meme, vu qu'ils vivent sur des reseaux differents). L'optimisation n'est donc pas faisable. En pratique, c'est pas genant car ils vont differer sur un petit bout.
Notons que depuis la version 2.4 (et peut-etre avant, voir le Changelog), mldonkey est deja capable de se rendre compte que certains fichiers edonkey partagent les memes chunks. Quand il a downloader un chunk commun sur l'un, il le recopie sur l'autre (fichier).
Dans les préférences du gui, il y a des onglets spécifiques par réseaux où ce genre d'option figure.
Mais il y a de toute façon la méthode universelle suivante:
netstat -apn | grep mlnet | grep LISTEN
pour les ports tcp en écoute.
Nous parlons tous les deux de la meme chose. Ce que j'avais ajoute, lors de la news precedente, c'est une robustesse du schema vis a vis des upgrades systemes: Tous les trucs Palladium critiques sont encryptes avec de la crypto symetrique dont la cle est calculee par Microsoft en fonction du numero de licence (lors de la phase d'activation). Cette cle est scelle grace au PCR. En cas d'upgrade, on perd cette cle. Mais comme de toute facon il faut se reenregistrer, microsoft la redonne a ce moment la.
Ce schema suppose deux choses, en fait:
1) Que Microsoft puisse etre sur que windows est integre et ne s'execute pas dans un emulateur genre "bloch" (au moment de la phase d'activation). J'avoue que je ne comprends pas encore bien si cela est possible. Mais a defaut de comprendre la spec TCPA a la lettre, l'esprit dit (section 2.2 page 2) qu'une entite peut decider si une plateforme est dans un etat acceptable, ou pas. D'un autre cote, Kha dit que le "peer" ne peut pas voir la config, mais seulement un hash de la config. Il faut trancher cette question.
2) Que le noyau (ou micro-noyeau) n'aie pas de failles. Je ne regarde pas bugtraq mais juste la debian-security mailing list. Jusqu'a present, je n'ai jamais vu passer de mise a jour noyau pour cause de trou de securite, meme si je pense qu'il doit y en avoir. 99% des mises a jour concernent des programmes userland. J'en deduis qu'il n'est pas si difficile que ca d'avoir un noyau a peu pres sur. Tout ce qu'il faut, c'est empecher aux programmes userland de passer en ring 0 (il y a un appel systeme pour ca). A part XFree86 (et encore), je crois que personne n'a besoin de ce truc. Donc, ce deuxieme point me parait assez facile a garantir.
Tu veux dire si windows bloque LOGICIELLEMENT l'acces a certaines fonctions TCPA. Ben comme tout le monde, j'attend le crack ou je le develloppe moi meme. Si windows a des droits, c'est que la puce a des droits. Si windows m'interdit d'ecrire sur le port de la puce parceque je ne suis pas une appli securisee, parce que ca ne lui plait pas, ou parcequ'il veut proteger des donnees, il est oblige de faire ca logiciellement. Donc il est oblige de proteger TCPA avec autre chose. Et la de deux choses l'une
1) soit sa protection logicielle est sans faille, je ne peut pas acceder a la puce. Mais a ce moment la pourquoi ne pas utiliser cette protection directement et se passer de la puce TCPA ?
2) soit sa protection est nulle, elle se fait casser et TCPA ne sert a rien. Une fois que je peux ecrire sur la puce j'ai exactement les memes droits que l'OS et les programmes.
Cette alternative est bancale. Cela rejoint un autre echange qu'on a eu dans une autre news, lorsque je voulais prouver qu'on peut implementer la partie soft de palladium, a l'aide de la spec TCPA actuelle.
Je detaille. Tu consideres inutile que windows bloque de facon logicielle des fonctions TCPA. Si le noyau windows a des trous de securites, c'est effectivement domage pour eux car on peut les utiliser pour acceder aux fonctions TCPA que windows veut nous cacher (Et c'est pour ca que palladium ne peut pas se satisfaire de la spec TCPA, en l'etat)
Mais si le noyau windows n'a pas de trou de securite, il garantit que certaines fonctions TCPA (et donc certaines cles) sont inaccessibles de l'exterieur.
Alors que si windows n'utilise pas TCPA --- et meme s'il est parfait ---, je peux toujours l'executer dans un emulateur (genre bloch) et sniffer tout ce qu'il fait. Il n'a aucun moyen de me cacher des cles (meme si l'effort pour executer windows pas a pas est monstrueux)
Il y a un manque de communication. On ne se comprends pas.
Le schema que tu propose ne tiens pas la route. De deux choses l'une soit la clef est dependante du du schema de boot, soit elle ne l'est pas.
Elle ne l'est pas. C'est clair? ELLE NE L'EST PAS!
C'est de la bete crypto symmetrique, et la cle est envoyee par Microsoft a l'enregistrement. Elle est envoyee a mon ordinateur. Pas a moi. Mon ordinateur, qui est devenu mon ennemi, se garde bien de me laisser voir cette cle un jour.
Ensuite, je te cite, citant la spec:
The "trusted" boot functions provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence.
Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has backdoored the operating system, the PCR value will not match, and the unseal will fail [...]
Windows ZP applique ce procede et "scelle" la fameuse cle avec le PCR courant.
Ce qui a ete encrypte sans schema de boot peut etre decrypte par n'importe qui qui possede le pass, independament de l'OS et des changements de hardware.
Question:
Comment je fais pour acceder au "pass" (la fameuse cle). Depuis linux, mauvaise valeur du PCR. Aucune chance de lire la cle. Depuis Windows ZP, a moins d'un trou de securite, il ne me la donnera jamais. Il la gardera dans ces tripes et aucun programme ne pourra jamais y acceder.
Je parle de Palladium et de DRM a titre d'exemple! Ce que je montre (et jusqu'a present, tu n'as pas remis en question mon modele), c'est qu'on peut utiliser TCPA tel qu'il est, pour implementer un systeme (par exemple DRM) qui planquent des donnees de facon que l'utilisateur ne puisse jamais y acceder.
Cette remarque a ete suggeree dans plusieurs fils. A chaque fois, tu reponds que si tel est le cas, le moindre upgrade rend l'acces a ces donnees impossibles par windows. C'est l'unique argument que tu sors pour dire que Microsoft ne peut pas implementer cela.
Dans le schema que je propose, ce probleme disparait puisqu'on se reenregistre aupres de Microsoft a chaque upgrade, pour recuper la fameuse cle qui est desormais devenu inaccessible.
DONC, TCPA permet d'implementer quelque chose qui, a defaut d'etre Palladium, lui est fonctionnellement identique.
Palladium est mal.
Ce qui est identique a Palladium est mal aussi.
Ce qui permet d'implementer quelque chose d'identique a Palladium est donc mal.
Bref TCPA est mal
TCPA n'aide en rien ni DRM ni Paladium.
J'attends un argument technique solide qui invalide mon schema. Je ne demande qu'a te croire, mais pour le moment je reste tres tres mefiant vis a vis de TCPA.
Il n'y a pas de notion de "Sanctuaire" ou de zone inaccessible dans TCPA
Bien sur. Je vois TCPA comme une couche bas niveau. De meme qu'en assembleur, il n'y a pas de notion d'objet. Mon schema montre qu'on peut utiliser TCPA pour implementer un sanctuaire.
De deux choses l'une soit la clef que MS te donne est toujours la meme, et la effectivement tu peux t'en servir pour relancer des applications et/ou des docs DRM apres une upgrade.
C'est effectivement le cas que je considere.
Mais bon comme c'est toujours la meme clef, rien ne t'empeche de la remettre en place sans l'accord de MS, voir meme de la copier dans un endroit parfaitement accessible sous Linux.
Oui, a condition que j'ai une chance de la voir, cette cle. Dans ma comprehension de Palladium, Windows a une zone securisee (que j'ai vu appelee "Le sanctuaire Palladium") dans lequel ne peuvent rentrer que les applications signees. Exemple, les applications DRM compliants. Contre-exemple, un debuger. Meme l'administrateur ne peut pas rentrer dans le sanctuaire Palladium. Si les gars de chez Microsoft sont malins. Cette fameuse cle est rangee dans le sanctuaire quand le systeme est up; et dans le TPM quand le systeme est down. En l'absence de trou de securite, je ne peux jamais intercepter cette cle.
En fait, c'est precisement cette cle qui sert a securiser les ressources du sancturaire Palladium, lorsque le systeme est down (dans mon schema personnel, bien sur. J'ai aucune idee precise du fonctionnement de Palladium.)
Je suis desole que tu ais pris mon apparte comme cela, ce n'etait pas mon intention. J'imagine donc que pour toi tous les echanges de clefs se feront par moyen electronique obligatoirement. C'est possible mais ce serait quand meme une sacree limitation. Je pense qu'une mention "necessite une connection internet valide" sur un OS serait du plus mauvais effet. Meme si XP s'installe tres bien via le net, la possibilite de le reinstaller par telephone est quand meme rassurante.
Bof. Cette securite parano, c'est juste pour le DRM. Le DRM, pour les gens qui n'ont pas internet, n'est pas d'une utilite dementielle. Ces pauvres loosers auront un windows ZP, un peu castre (sans DRM): Ils s'enregistreront par telephone et on ne leur donnera pas de cle Palladium. A mesure que le temps passe, l'hypothese "tout le monde a internet" devient de plus en plus vrai. Donc je crois que Microsoft peut parfaitement commencer a mepriser ces gens la.
Bon je passe outre le fait de se faire dicter par telephone une clef de 2048bits, ce qui pourtant pourrait etre un pur moment de bonheur, et qui a mon avis decredibilise un peu ton scenario.
Troll, je reponds pas.
Je reprend au moment ou mon "windows media DRM et tout" il ne veut plus marcher parceque j'ai upgrade mon systeme. J'apelle windows qui me file une clef, je l'enregistre et la hop : mon "windows media DRM et tout que je m'en sert que pour lire des trucs legaux promis jure" il ne marche toujours pas. Ben non le bougre il a ete crypte avec une clef qui ne sera accessible que depuis mon ancien profil de boot, et la je l'ai change. Zut alors je suis oblige de reinstaller tout mon windows. Et donc de me farcir une troisieme installation de clef super.
Non, tu n'as pas compris le schema que je decris. Les trucs DRM (par exemple) sont proteges avec une cle que Microsoft te donne (Il la calcule en fonction du numero de licence, par exemple.) TCPA sert juste a proteger la-dite cle dans les tripes du TPM, de telle sorte qu'on ne puisse pas la lire depuis linux. Apres un upgrade, cette cle devient inaccessible, certes. Mais Microsoft peut la redonner. Et DRM devient a nouveau accessible.
Ma question est: pourquoi ce scenario n'est pas possible sous TCPA?
Ne veut pas dire que un OS peut aller sans que tu le sache crypter des docs et des executables pour etre sur que tu ne t'en serve pas sous un autre systeme. Pour etre exact c'est meme exactement le genre de chose dont TCPA te protege. Si Windows a l'install te locke des executables avec des clefs basees sur le PCR (ce qui veut deja dire que windows est un executable qui s'autocertifie vis a vis de TCPA ce qui me semble impossible vu la doc).
1) Il se tire une vache de balle dans le pied. Parceque TCPA c'est pas comme le systeme de protection actuelle, c'est pas dans 30 jours, c'est tout de suite. J'ai flashe mon bios ? Tous les outils proteges par clef sont bloques. Qu'est ce que je peux faire ? Rien sauf si je connais l'astuce.
On imagine le scenario suivant:
Quand j'installe windows ZP, il se connecte chez microsoft (pour l'enregistrement). En plus des trucs qui se passent actuellement avec XP, microsoft envoie une cle de cryptage (symmetrique), qui depends du numero de licence. Cette cle sert a crypter tous ce qu'on ne veut pas que l'utilisateur s'amuse a regarder, car c'est *mal* pour lui:-)
Cette cle est elle meme encryptee avec le PCR.
Donc, impossible de mater depuis linux ce que windows veut cacher, puisqu'on ne peut voir la cle symetrique. Si on fait un upgrade system, windows ZP ne peut plus lire cette fameuse cle. Pas grave, il se reconnecte a Microsoft, qui lui redonne gentiment (et de toute facon, sous XP il faut bien se reenregistrer dans ces cas la, non?)
J'avoue ne pas connaitre TCPA, mais de loin il a l'air tres dangereux. Et vous n'etes pas tres convaincant. Son utilite est tres douteuse. La seule chose positive pour l'utilisateur lambda, c'est la possibilite d'avoir des cles inviolables. C'est tres bien, mais cela existe deja, cela s'appelle les cartes a puces. Et, que je sache, les cartes a puces sont infiniment plus pratiques. Si je vais chez un ami, j'aime pouvoir m'identifier sur mon serveur de messagerie en mettant ma carte dans son lecteur. Je trouve nettement moins pratique l'idee de dessouder le chip DRM et de l'avoir toujours sur moi.
Cela me parait assez clair que ce truc n'est pas invente pour notre bonheur a nous, petites gens. Et meme s'il ne permet pas de fliquer autant que je pourrais le craindre (du genre, mes deux premiers paragraphes, c'est pas possible), c'est un pas dans la mauvaise direction. On franchit une ligne, a mon sens. A partir de quand vous trouvez que la situation pue vraiment? Quand des hommes en impermeable frappent a votre porte pour vous emmener?
Je ne sais pas si le noyeau optimise/compile les regles de façon à les comprimer à mort. Mais si il ne le fait pas, pour chaque packet que tu NATes, il va parcourir 2000 règles, au lieu d'une seule...
[^] # Re: Avant de (trop) hurler...
Posté par thoran . En réponse à la dépêche Directive sur les brevets logiciels adoptée. Évalué à 1.
Les eurodéputés ont ajouté un paragraphe précisant qu'une "invention mise en oeuvre par ordinateur (un logiciel) n'est pas considérée comme apportant une contribution technique uniquement parce qu'elle implique l'utilisation d'un ordinateur".
En clair, pour qu'un programme informatique soit brevetable, il ne suffit pas qu'il soit nouveau, il faut encore qu'il permette une innovation technique indépendamment de sa propre exécution.
Mais avec beaucoup de mauvaise foi, on peut mettre beaucoup de chose dedans. Par exemple, la technique d'affichage du pointeur souris a l'aide de Xor (brevet reel) peut-etre vu comme ayant un effet physique (ecran, affichage, ...)
Les algos de micro-typographie (brevets Adobe, je pense) ont un effet technique sur le papier imprime.
Et plein d'autres joyeusetes du meme tonneau.
[^] # Re: enregistré
Posté par thoran . En réponse à la dépêche Brevets logiciels : conférence, manifestation, soutiens et positions. Évalué à 1.
[^] # Re: P2P : Débat public avec le Ministre de la Culture
Posté par thoran . En réponse à la dépêche P2P : Débat public avec le Ministre de la Culture. Évalué à 1.
[^] # Re: PS: dvorak
Posté par thoran . En réponse à la dépêche Red Hat préparerait une version Open Source de Java. Évalué à 2.
Pour apprendre a taper en aveugle, la regle numero 1 est de ne jamais regarder ses doigts. Quoi qu'il arrive. La premiere touche a apprendre est donc 'backspace'.
Au debut, c'est tres dur, on tape 3 mots par minute. Puis on s'y fait. Ca vient tres vite.
Acheter un nouveau clavier serait donc une erreur.
SURTOUT, ne pas croire qu'on va apprendre plus vite a taper parcequ'on a un clavier avec le dessin des lettres au bon endroit. Le but final est de toute facon la frappe en aveugle. Et on l'atteint beaucoup plus vite en apprenant en aveugle.
http://www.gnu.org/software/gtypist/gtypist(...)
[^] # Re: Logiciel de pirates
Posté par thoran . En réponse à la dépêche Mldonkey 2.5.3 est sorti. Évalué à 5.
On decoupe le fichier en "chunks" (9.5 Mo pour mldonkey, ~256 Ko pour bittorrent). On calcule le hash (MD4, SHA1...) de chaque chunk. La signature du fichier est le hash de la concatenation des hashs de tous les chunks.
Grace a cette methode, on peut verifier l'integrite de bouts de fichier qu'on possede deja, avant d'avoir l'integralite du fichier. Cela permet de commencer a uploader alors qu'on n'a pas tout downloader, ainsi que de detecter qu'un "peer" nous uploade n'importe quoi (Et grace au "mods" emule, y'en a plein).
A partir de la, c'est facile de downloader sur plusieurs reseaux:
* Je suppose que deux fichiers repondaient aux criteres precedants sur le reseau edonkey. Je les appelle E1 et E2.
* Sur Faststrack, il y en avait 3: F1, F2 et F3.
* Sur Bittorrent, un seul: B1
* ...
Parmi tous ces fichiers, j'en choisis un qui est la reference. On va dire que c'est E1.
Ce systeme marche, meme si les fichiers ne sont pas exactement les memes. En general, ce sont toujours des mutations d'une meme source. Par exemple E1 et E2 auront exactement les memes chunks, sauf 1. Cela sera donc tres rentable de downloader des bouts de E1 sur E2. Comme E1 est la reference, on peut meme decider de ne jamais downloader le chunk qui differe entre E1 et E2 (petite optimisation facile a faire). Si E1 et F1 sont differents, on ne peut pas s'en rendre compte (a cause du schema de signature qui n'est pas le meme, vu qu'ils vivent sur des reseaux differents). L'optimisation n'est donc pas faisable. En pratique, c'est pas genant car ils vont differer sur un petit bout.
Notons que depuis la version 2.4 (et peut-etre avant, voir le Changelog), mldonkey est deja capable de se rendre compte que certains fichiers edonkey partagent les memes chunks. Quand il a downloader un chunk commun sur l'un, il le recopie sur l'autre (fichier).
[^] # Re: > NdM: et vous, qu'utilisez-vous pour échangez vos fichiers ?
Posté par thoran . En réponse à la dépêche Lmule est mort, vive Xmule !. Évalué à 2.
Je ne vois pas bien ton problème. Il reste que certains protocoles utilisent aussi l'udp, mais netstat indique egalement les ports udp ecoutés.
Ceci règle le cas des connections TCP entrantes. Maintenant, je fais l'hypothèse que tu ne cherches pas à filtrer les connexions TCP sortantes.
[^] # Re: > NdM: et vous, qu'utilisez-vous pour échangez vos fichiers ?
Posté par thoran . En réponse à la dépêche Lmule est mort, vive Xmule !. Évalué à 2.
[^] # Re: et aussi...
Posté par thoran . En réponse au message [Terminal] Comment choisir le gcc qu'il vous faut!. Évalué à 1.
[^] # Re: Demontage en regle
Posté par thoran . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 2.
Ce schema suppose deux choses, en fait:
1) Que Microsoft puisse etre sur que windows est integre et ne s'execute pas dans un emulateur genre "bloch" (au moment de la phase d'activation). J'avoue que je ne comprends pas encore bien si cela est possible. Mais a defaut de comprendre la spec TCPA a la lettre, l'esprit dit (section 2.2 page 2) qu'une entite peut decider si une plateforme est dans un etat acceptable, ou pas. D'un autre cote, Kha dit que le "peer" ne peut pas voir la config, mais seulement un hash de la config. Il faut trancher cette question.
2) Que le noyau (ou micro-noyeau) n'aie pas de failles. Je ne regarde pas bugtraq mais juste la debian-security mailing list. Jusqu'a present, je n'ai jamais vu passer de mise a jour noyau pour cause de trou de securite, meme si je pense qu'il doit y en avoir. 99% des mises a jour concernent des programmes userland. J'en deduis qu'il n'est pas si difficile que ca d'avoir un noyau a peu pres sur. Tout ce qu'il faut, c'est empecher aux programmes userland de passer en ring 0 (il y a un appel systeme pour ca). A part XFree86 (et encore), je crois que personne n'a besoin de ce truc. Donc, ce deuxieme point me parait assez facile a garantir.
[^] # Re: Demontage en regle
Posté par thoran . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 2.
Tu veux dire si windows bloque LOGICIELLEMENT l'acces a certaines fonctions TCPA. Ben comme tout le monde, j'attend le crack ou je le develloppe moi meme. Si windows a des droits, c'est que la puce a des droits. Si windows m'interdit d'ecrire sur le port de la puce parceque je ne suis pas une appli securisee, parce que ca ne lui plait pas, ou parcequ'il veut proteger des donnees, il est oblige de faire ca logiciellement. Donc il est oblige de proteger TCPA avec autre chose. Et la de deux choses l'une
1) soit sa protection logicielle est sans faille, je ne peut pas acceder a la puce. Mais a ce moment la pourquoi ne pas utiliser cette protection directement et se passer de la puce TCPA ?
2) soit sa protection est nulle, elle se fait casser et TCPA ne sert a rien. Une fois que je peux ecrire sur la puce j'ai exactement les memes droits que l'OS et les programmes.
Cette alternative est bancale. Cela rejoint un autre echange qu'on a eu dans une autre news, lorsque je voulais prouver qu'on peut implementer la partie soft de palladium, a l'aide de la spec TCPA actuelle.
Je detaille. Tu consideres inutile que windows bloque de facon logicielle des fonctions TCPA. Si le noyau windows a des trous de securites, c'est effectivement domage pour eux car on peut les utiliser pour acceder aux fonctions TCPA que windows veut nous cacher (Et c'est pour ca que palladium ne peut pas se satisfaire de la spec TCPA, en l'etat)
Mais si le noyau windows n'a pas de trou de securite, il garantit que certaines fonctions TCPA (et donc certaines cles) sont inaccessibles de l'exterieur.
Alors que si windows n'utilise pas TCPA --- et meme s'il est parfait ---, je peux toujours l'executer dans un emulateur (genre bloch) et sniffer tout ce qu'il fait. Il n'a aucun moyen de me cacher des cles (meme si l'effort pour executer windows pas a pas est monstrueux)
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Le schema que tu propose ne tiens pas la route. De deux choses l'une soit la clef est dependante du du schema de boot, soit elle ne l'est pas.
Elle ne l'est pas. C'est clair? ELLE NE L'EST PAS!
C'est de la bete crypto symmetrique, et la cle est envoyee par Microsoft a l'enregistrement. Elle est envoyee a mon ordinateur. Pas a moi. Mon ordinateur, qui est devenu mon ennemi, se garde bien de me laisser voir cette cle un jour.
Ensuite, je te cite, citant la spec:
The "trusted" boot functions provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence.
Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has backdoored the operating system, the PCR value will not match, and the unseal will fail [...]
Windows ZP applique ce procede et "scelle" la fameuse cle avec le PCR courant.
Ce qui a ete encrypte sans schema de boot peut etre decrypte par n'importe qui qui possede le pass, independament de l'OS et des changements de hardware.
Question:
Comment je fais pour acceder au "pass" (la fameuse cle). Depuis linux, mauvaise valeur du PCR. Aucune chance de lire la cle. Depuis Windows ZP, a moins d'un trou de securite, il ne me la donnera jamais. Il la gardera dans ces tripes et aucun programme ne pourra jamais y acceder.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 2.
Cette remarque a ete suggeree dans plusieurs fils. A chaque fois, tu reponds que si tel est le cas, le moindre upgrade rend l'acces a ces donnees impossibles par windows. C'est l'unique argument que tu sors pour dire que Microsoft ne peut pas implementer cela.
Dans le schema que je propose, ce probleme disparait puisqu'on se reenregistre aupres de Microsoft a chaque upgrade, pour recuper la fameuse cle qui est desormais devenu inaccessible.
DONC, TCPA permet d'implementer quelque chose qui, a defaut d'etre Palladium, lui est fonctionnellement identique.
Palladium est mal.
Ce qui est identique a Palladium est mal aussi.
Ce qui permet d'implementer quelque chose d'identique a Palladium est donc mal.
Bref TCPA est mal
TCPA n'aide en rien ni DRM ni Paladium.
J'attends un argument technique solide qui invalide mon schema. Je ne demande qu'a te croire, mais pour le moment je reste tres tres mefiant vis a vis de TCPA.
Il n'y a pas de notion de "Sanctuaire" ou de zone inaccessible dans TCPA
Bien sur. Je vois TCPA comme une couche bas niveau. De meme qu'en assembleur, il n'y a pas de notion d'objet. Mon schema montre qu'on peut utiliser TCPA pour implementer un sanctuaire.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
De deux choses l'une soit la clef que MS te donne est toujours la meme, et la effectivement tu peux t'en servir pour relancer des applications et/ou des docs DRM apres une upgrade.
C'est effectivement le cas que je considere.
Mais bon comme c'est toujours la meme clef, rien ne t'empeche de la remettre en place sans l'accord de MS, voir meme de la copier dans un endroit parfaitement accessible sous Linux.
Oui, a condition que j'ai une chance de la voir, cette cle. Dans ma comprehension de Palladium, Windows a une zone securisee (que j'ai vu appelee "Le sanctuaire Palladium") dans lequel ne peuvent rentrer que les applications signees. Exemple, les applications DRM compliants. Contre-exemple, un debuger. Meme l'administrateur ne peut pas rentrer dans le sanctuaire Palladium. Si les gars de chez Microsoft sont malins. Cette fameuse cle est rangee dans le sanctuaire quand le systeme est up; et dans le TPM quand le systeme est down. En l'absence de trou de securite, je ne peux jamais intercepter cette cle.
En fait, c'est precisement cette cle qui sert a securiser les ressources du sancturaire Palladium, lorsque le systeme est down (dans mon schema personnel, bien sur. J'ai aucune idee precise du fonctionnement de Palladium.)
Je suis desole que tu ais pris mon apparte comme cela, ce n'etait pas mon intention. J'imagine donc que pour toi tous les echanges de clefs se feront par moyen electronique obligatoirement. C'est possible mais ce serait quand meme une sacree limitation. Je pense qu'une mention "necessite une connection internet valide" sur un OS serait du plus mauvais effet. Meme si XP s'installe tres bien via le net, la possibilite de le reinstaller par telephone est quand meme rassurante.
Bof. Cette securite parano, c'est juste pour le DRM. Le DRM, pour les gens qui n'ont pas internet, n'est pas d'une utilite dementielle. Ces pauvres loosers auront un windows ZP, un peu castre (sans DRM): Ils s'enregistreront par telephone et on ne leur donnera pas de cle Palladium. A mesure que le temps passe, l'hypothese "tout le monde a internet" devient de plus en plus vrai. Donc je crois que Microsoft peut parfaitement commencer a mepriser ces gens la.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Bon je passe outre le fait de se faire dicter par telephone une clef de 2048bits, ce qui pourtant pourrait etre un pur moment de bonheur, et qui a mon avis decredibilise un peu ton scenario.
Troll, je reponds pas.
Je reprend au moment ou mon "windows media DRM et tout" il ne veut plus marcher parceque j'ai upgrade mon systeme. J'apelle windows qui me file une clef, je l'enregistre et la hop : mon "windows media DRM et tout que je m'en sert que pour lire des trucs legaux promis jure" il ne marche toujours pas. Ben non le bougre il a ete crypte avec une clef qui ne sera accessible que depuis mon ancien profil de boot, et la je l'ai change. Zut alors je suis oblige de reinstaller tout mon windows. Et donc de me farcir une troisieme installation de clef super.
Non, tu n'as pas compris le schema que je decris. Les trucs DRM (par exemple) sont proteges avec une cle que Microsoft te donne (Il la calcule en fonction du numero de licence, par exemple.) TCPA sert juste a proteger la-dite cle dans les tripes du TPM, de telle sorte qu'on ne puisse pas la lire depuis linux. Apres un upgrade, cette cle devient inaccessible, certes. Mais Microsoft peut la redonner. Et DRM devient a nouveau accessible.
Ma question est: pourquoi ce scenario n'est pas possible sous TCPA?
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par thoran . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Ne veut pas dire que un OS peut aller sans que tu le sache crypter des docs et des executables pour etre sur que tu ne t'en serve pas sous un autre systeme. Pour etre exact c'est meme exactement le genre de chose dont TCPA te protege. Si Windows a l'install te locke des executables avec des clefs basees sur le PCR (ce qui veut deja dire que windows est un executable qui s'autocertifie vis a vis de TCPA ce qui me semble impossible vu la doc).
1) Il se tire une vache de balle dans le pied. Parceque TCPA c'est pas comme le systeme de protection actuelle, c'est pas dans 30 jours, c'est tout de suite. J'ai flashe mon bios ? Tous les outils proteges par clef sont bloques. Qu'est ce que je peux faire ? Rien sauf si je connais l'astuce.
On imagine le scenario suivant:
Quand j'installe windows ZP, il se connecte chez microsoft (pour l'enregistrement). En plus des trucs qui se passent actuellement avec XP, microsoft envoie une cle de cryptage (symmetrique), qui depends du numero de licence. Cette cle sert a crypter tous ce qu'on ne veut pas que l'utilisateur s'amuse a regarder, car c'est *mal* pour lui:-)
Cette cle est elle meme encryptee avec le PCR.
Donc, impossible de mater depuis linux ce que windows veut cacher, puisqu'on ne peut voir la cle symetrique. Si on fait un upgrade system, windows ZP ne peut plus lire cette fameuse cle. Pas grave, il se reconnecte a Microsoft, qui lui redonne gentiment (et de toute facon, sous XP il faut bien se reenregistrer dans ces cas la, non?)
J'avoue ne pas connaitre TCPA, mais de loin il a l'air tres dangereux. Et vous n'etes pas tres convaincant. Son utilite est tres douteuse. La seule chose positive pour l'utilisateur lambda, c'est la possibilite d'avoir des cles inviolables. C'est tres bien, mais cela existe deja, cela s'appelle les cartes a puces. Et, que je sache, les cartes a puces sont infiniment plus pratiques. Si je vais chez un ami, j'aime pouvoir m'identifier sur mon serveur de messagerie en mettant ma carte dans son lecteur. Je trouve nettement moins pratique l'idee de dessouder le chip DRM et de l'avoir toujours sur moi.
Cela me parait assez clair que ce truc n'est pas invente pour notre bonheur a nous, petites gens. Et meme s'il ne permet pas de fliquer autant que je pourrais le craindre (du genre, mes deux premiers paragraphes, c'est pas possible), c'est un pas dans la mauvaise direction. On franchit une ligne, a mon sens. A partir de quand vous trouvez que la situation pue vraiment? Quand des hommes en impermeable frappent a votre porte pour vous emmener?
Clairement, il faut boycotter des maintenant.
A lire: "Matin brun", de Franck Pavloff
[^] # Re: Comprendre XSLT, critique du livre
Posté par thoran . En réponse à la dépêche Comprendre XSLT, critique du livre. Évalué à 1.
http://www.cduce.org/(...)
[^] # Re: Comprendre XSLT, critique du livre
Posté par thoran . En réponse à la dépêche Comprendre XSLT, critique du livre. Évalué à 1.
http://www.cduce.org/(...)
[^] # Re: Voila mon script...
Posté par thoran . En réponse à la dépêche mldonkey 2 est sorti !. Évalué à 1.
iptables -t mangle -A POSTROUTING -s $ip -o $dev -p tcp --destination-port 1863:5190 -j ACCEPT
Je ne sais pas si le noyeau optimise/compile les regles de façon à les comprimer à mort. Mais si il ne le fait pas, pour chaque packet que tu NATes, il va parcourir 2000 règles, au lieu d'une seule...