fait attention à ton usage du mot chaos: le chaos désigne des fonctions mathématiques déterministes qui ont des propriétés précises comme la sensibilité aux conditions initiales: ces fonctions sont utilisées dans les pseudo générateurs aléatoires qui ne suffisent pas à eux seuls à faire une bonne crypto
dans ton message ci-dessus tu devrait remplacer le mot "chaos" par "phénomènes physiques aléatoires" (comme les "bruits" électroniques ou les émissions de particules)
je viens de modifier en partie ce "fait numéro 6", je pense que cette nouvelle version est moins sujette à heurter les sensibilités... http://free2.org/tcpa/(...)
c'est même un excellent moyen pour un artiste indépendant de diffuser un grand nombre d' oeuvres de grande taille (videos) sans avoir à payer des frais d'hébergements élevés à cause de la bande passante que cela engendre.
si on sacrifie les possibilités de partage généralisé de l'information d'Internet, sur l'autel de la marchandisation "Intellectuelle" , alors on fait faire un grand bond en arrière à l'humanité
d'ailleurs IBM dit clairement dans son PDF:
"it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use"
avant de dire que cela obligerait à retélécharger les documents si on change quoique ce soit à la config du PC.
Mais c'est justement ce que veulent les éditeurs de DRM !
En +, au lieu d'avoir à retélécharger tous les documents, on pourrait n'avoir à retélécharger que une clé par document, chaque clé étant elle-meme encryptée et protégée par le PCR, et inutilisable si la config change.
Ce qui serait le DRM parfait.
Bref: TCPA est une avancée majeure pour le DRM !
tout ton rainsonement repose sur le fait qu'il sera obligatoire de donner le controle de TCPA au possesseur du PC. or dans la norme on peut lire qeu cela est "desirable" (je cite).
d'ailleurs IBM dit clairement dans son PDF:
"it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use"
avant de dire que cela obligerait à retélécharger les documents si on change quoique ce soit à la config du PC.
Mais c'est justement ce que veulent les éditeurs de DRM !
En +, au lieu d'avoir à retélécharger les documents, on pourrait n'avoir à recharger que une clé non tcpa, protégée par le PCR, et inutilisable si la config change.
Ce qui serait le DRM parfait.
Bref: TCPA est une avancée majeure pour le DRM !
le principe du web of trust de gnupg, c'est que tu ne fais confiance qu'à tes propres yeux: seules les clés certifiées par une personne que tu as physiquement rencontrée et en qui tu as confiance sont dignes de confiance.
tu ne remets pas ta confiance entre les mains d'un organisme "indépendant" qui en fait dépend toujours soit d'un grande multinationale (une de celles de TCPA) soit d'un gouvernement.
enfin, ne pas utiliser les certificats TCPA c'est se priver des documents DRM protégés à l'aide de ces certificats
donc oui: TCPA est un progrès énorme en matière de DRM puiqu'il permettra d'envoyer des documents lisibles uniquement par une personne dont un organisme "dépendant" connait l'identité.
Toute clef privee qu'une appli DRM stockerait sur ta puce TCPA (meme si elle est base sur un de tes private CA, meme si elle est scellee sur un PCR) serait en danger.
je ne comprends pas pourquoi tu contredis en permanence le document IBM qui dit le contraire (tu es mieux informé qu'IBM que l'évolution actuelle de la norme TCPA ?): it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use
d'abord je constate la confirmation de mon affirmation que tu avais contredite: it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use
ensuite je ne suis pas d'accord sur les conclusions de: ce type de modele serait un cauchemar a gerer pour les fournisseurs de contenu, n'importe quel changement au niveau du BIOS, de l'OS ou de l'applicatif changerait les valeurs.
Au contraire, à l'image de XP activation, les fournisseurs DRM sont contents qeu tu ne puissse plus accéder aux fichiers DRM si ta config change, et t'envoieront à nouveau ces fichiers si tu es à jour du paiement de tes mensualités ou de ton pay per view.
Donc je confirme et je signe: TCPA est une avancée considérable pour le DRM !
petit rappel: Linux peut fonctionner avec plein de formats de partition. bloquer les formatages ext2/ext3 dans un IDE ne bloquerait pas Linux, mais serait interprétable illico comme un abus de position de dominante.
it is desirable to provide a method that enables or disables the process
"Désirable" veut dire que ce n'est pas obligatoire dans la norme. Le danger est donc bien là: la norme n'oblige pas les constructeurs à donner un controle yotal à l'utilisateur. C'est juste "désirable". No comment.
mouais enfin toutes ces valeurs par défaut ça va dépendre aussi du BIOS que tu utilises. Qu'est-ce qui me garanti que tous les BIOS permettront aux utilisateurs de manipuler ces valeurs ?
Quand aux softs de DRM de MS si ils exigent Windows pour tourner, le mal est deja fait (combiné à l'endording key et au PCR, ça fait mal)
Relit ton doccument il est dit que l'utilisateur n'a pas acces aux etapes intermediaires.
il n'est pas dit qu'il a accès à l'algo ou au code du générateur non plus !
Il y a dans la doc une les fonctions qui doivent etre accessible au boot, a partir du bios et logiciellement sous l'OS.
si c'est le cas, peux tu me dire à quelle page il est dit que le bios doit obligatoirement permettre à l'utilisateur de copier/modifier les clés contenues dans TCPA ?
Par contre je n'ai pas vu ou il est dit que l'on puisse rajouter des fonctionalites a TCPA. tu peux me filer une reference precise ?
je me rappelle avoir lu cela en effet, mais je n'ai plus la page exacte en mémoire. dans ma page free2.org/tcpa/ je donne les références de la page qui précise qu'on peut intégrer TCPA dans une puce qui a d'autres fonctionalités (et il n'est pas interdit que cette puce ait des fonctionnalités de sécurité, y compris des fonctions liées à TCPA)
curieux, il me semblait que tout l'intéret de TCPA était dans le fait que la puce TCPA faisait elle-meme les opérations de crypto, et que par conséquent elle ne donnait l'accès à personne aux clés qu'elle protège.
Pour moi la phrase d'IBM sur le fait qu'on peut écouter le bus d'une puce TCPA qui n'est pas dans le CPU se comrpend comme ceci: la puce TCPA doit décrypter les données protégées par DRM et donc envoyer ensuite ces données en clair au CPU: si j'écoute les donénes en clair qu'elle envoie au CPU alors je peux faire une copie décrypté du fichier DRM.
Démocratie démagogique: action de controler (médias d'état ou appartenant à de grands groupes) ou manipuler les médias pour que les gens votent pour ceux qui ont déjà une partie du pouvoir politique ou économique.
Le plus souvent cela passe aussi par le controle politique (non indépendance des magistrats dans la constitution francaise) ou économique (corruption) de la justice.
Vraie Démocratie (Démocratie Directe): les médias sont totalement libres, et la justice est avant tout dispensé par des jurys de citoyens indépendants, les cours supremes étant en fait des référendums.
Chaque pétition qui recueille un grand nombre de signatures peut devenir un projet de loi ratifié par référendum.
Non je peux savoir que le PC connait la clef privee. Je ne peux pas savoir si c'est un original ou une copie, si je suis toujours sur le meme PC etc.
et où as-tu lu que la clé endorsing était copiable ou meme modifiable ? moi j'ai lu qu'il y en avait une seule par puce TCPA et qu'il était juste désactivable. Par conséquent mon raisonement tiens toujours.
On peut generer autant de CA que l'on veut.
moi j'ai lu qu'il fallait passer par un organisme agréé par TCPA pour obtenir un CA, et qeu cela nécessite l'identification de la clé endorsing et donc ton identification. L'organisme peut donc savoir qui a quel CA.
Où as-tu lu que le mode extend ne sera pas forcé ? (notamment pour pouvoir utiliser certains softs DRM qui exigerait sa présence...)
Dans TCPA il n'y a pas de donnees auquelles l'utilisateur ne peut pas acceder. Ca n'existe pas, il y a une clef qu'il ne peut pas effacer (mais qu'il peut desactiver), masi il n'y a pas de donnees que tu ne puisse consulter, deplacer, copier ailleurs.
sur quel document tu te base pour affirmer que l'accès lecture/ecriture à toutes les données par l'utilisateur est dans la norme TCPA ?
(moi je cite un document où il est marqué que l'utilisateur n'a pas accès au contenu du random generator, ce qui n'est pas rassurant sur la qualité de celui-ci. un bon générateur doit avant tout se baser sur des phénomènes physiques imprévisibles comme le bruit ou l'émission de particules. pas sur un pseudo générateur mathématique et donc déterministe)
et comme TCPA autorise l'ajout de fonctionnalités par les constructeurs (et par l'auteur du BIOS, je pense), pourquoi une fonctionnalité "protection de toutes les données TCPA" ne serait-elle pas ajoutée ?
- doublement des peines pour "crime informatique" (je crois que le mot crime ne devrait s'appliquer que quand on met en danger l'intégrité du corps de quelqu'un, comme quand un automobiliste ne respecte pas un passage pour piéton), peines allant jusqu'à 30 ans je crois
- criminalisation des outils de sécurité (tous les outils de détection de failles), comment vont faire les gens pour être sûrs qu'ils sont protégés contre toutes ces failles ?
- impossibilité pratique de faire ou d'importer de la crypto open source avec un CVS (il faudrait faire une nouvelle déclaration à cahque modification dans le CVS
fait 1: c'est exactement le même principe que pour les cartes bancaires..
oui mais la loi interdit de rendre obligatoire l'usage de la carte pour vendre un article
Par contre aucune loi n'empeche de rendre onligatoire l'usage de TCPA pour décrypter certains documents ou exécuter certains programmes DRM
Même dans un monde 100% windows, les utilisateurs doivent pouvoir s'échanger des fichiers
quand tu envooie un document, rien n'empeche windows de décrypter les fichiers avec la clé privée qui est dans ta puce TCPA puis de les encrypter avec la clé publique du destinataire de ces documents (c'est même probablement une des principales applications de TCPA)
ni ton LInux, ni celui du destinataire ne pourront accéder à ces documents
Bon, c'est vrai, M$ sux, mais ça n'en reste pas moins subjectif.
C'est un FAIT que MS est le seul non fabricant de CPU parmis les fondateurs de TCPA.
trustedpc.org
ce qui suit dans *conséquences est en effet mon interprétation des conséquences ce fait
http://www.cdt.org/privacy/issues/pentium3/(...)
n late-April, 2000, Intel quietly let it be known that future processors, starting with the Williamette family of processors, would not include the Processor Serial Number
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
dans ton message ci-dessus tu devrait remplacer le mot "chaos" par "phénomènes physiques aléatoires" (comme les "bruits" électroniques ou les émissions de particules)
[^] # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort
Posté par free2.org . En réponse au journal les faits sur TCPA: de vraies raisons pour boycotter très fort. Évalué à 1.
http://free2.org/tcpa/(...)
[^] # Re: MISC 6 : (in)sécurité du wireless
Posté par free2.org . En réponse à la dépêche MISC 6 : (in)sécurité du wireless. Évalué à 2.
les réponses sont donc en grande partie les mêmes: ipsec, ssh, ssl, gpg, etc.
[^] # Re: Le peer-to-peer en ligne de mire
Posté par free2.org . En réponse à la dépêche Le peer-to-peer en ligne de mire. Évalué à 7.
si on sacrifie les possibilités de partage généralisé de l'information d'Internet, sur l'autel de la marchandisation "Intellectuelle" , alors on fait faire un grand bond en arrière à l'humanité
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
je ne comprends pas pourquoi tu contredis en permanence le document IBM qui dit le contraire (tu es mieux informé qu'IBM que l'évolution actuelle de la norme TCPA ?):
it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use
voir ma réponse similaire à un ton commentaire similaire:
https://linuxfr.org/comments/178109.html(...)
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use
ensuite je ne suis pas d'accord sur les conclusions de:
ce type de modele serait un cauchemar a gerer pour les fournisseurs de contenu, n'importe quel changement au niveau du BIOS, de l'OS ou de l'applicatif changerait les valeurs.
Au contraire, à l'image de XP activation, les fournisseurs DRM sont contents qeu tu ne puissse plus accéder aux fichiers DRM si ta config change, et t'envoieront à nouveau ces fichiers si tu es à jour du paiement de tes mensualités ou de ton pay per view.
Donc je confirme et je signe: TCPA est une avancée considérable pour le DRM !
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
it is desirable to provide a method that enables or disables the process
"Désirable" veut dire que ce n'est pas obligatoire dans la norme. Le danger est donc bien là: la norme n'oblige pas les constructeurs à donner un controle yotal à l'utilisateur. C'est juste "désirable". No comment.
PS: merci pour tes références
[^] # Re: sécurité X Window
Posté par free2.org . En réponse à la dépêche RedHat Advanced Server certifié COE. Évalué à 1.
https://linuxfr.org/2003/02/21/11439.html(...)
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Quand aux softs de DRM de MS si ils exigent Windows pour tourner, le mal est deja fait (combiné à l'endording key et au PCR, ça fait mal)
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
il n'est pas dit qu'il a accès à l'algo ou au code du générateur non plus !
Il y a dans la doc une les fonctions qui doivent etre accessible au boot, a partir du bios et logiciellement sous l'OS.
si c'est le cas, peux tu me dire à quelle page il est dit que le bios doit obligatoirement permettre à l'utilisateur de copier/modifier les clés contenues dans TCPA ?
Par contre je n'ai pas vu ou il est dit que l'on puisse rajouter des fonctionalites a TCPA. tu peux me filer une reference precise ?
je me rappelle avoir lu cela en effet, mais je n'ai plus la page exacte en mémoire. dans ma page free2.org/tcpa/ je donne les références de la page qui précise qu'on peut intégrer TCPA dans une puce qui a d'autres fonctionalités (et il n'est pas interdit que cette puce ait des fonctionnalités de sécurité, y compris des fonctions liées à TCPA)
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Pour moi la phrase d'IBM sur le fait qu'on peut écouter le bus d'une puce TCPA qui n'est pas dans le CPU se comrpend comme ceci: la puce TCPA doit décrypter les données protégées par DRM et donc envoyer ensuite ces données en clair au CPU: si j'écoute les donénes en clair qu'elle envoie au CPU alors je peux faire une copie décrypté du fichier DRM.
# Re: New defs
Posté par free2.org . En réponse au journal New defs. Évalué à 1.
Le plus souvent cela passe aussi par le controle politique (non indépendance des magistrats dans la constitution francaise) ou économique (corruption) de la justice.
Vraie Démocratie (Démocratie Directe): les médias sont totalement libres, et la justice est avant tout dispensé par des jurys de citoyens indépendants, les cours supremes étant en fait des référendums.
Chaque pétition qui recueille un grand nombre de signatures peut devenir un projet de loi ratifié par référendum.
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
et où as-tu lu que la clé endorsing était copiable ou meme modifiable ? moi j'ai lu qu'il y en avait une seule par puce TCPA et qu'il était juste désactivable. Par conséquent mon raisonement tiens toujours.
On peut generer autant de CA que l'on veut.
moi j'ai lu qu'il fallait passer par un organisme agréé par TCPA pour obtenir un CA, et qeu cela nécessite l'identification de la clé endorsing et donc ton identification. L'organisme peut donc savoir qui a quel CA.
Où as-tu lu que le mode extend ne sera pas forcé ? (notamment pour pouvoir utiliser certains softs DRM qui exigerait sa présence...)
[^] # Re: TCPA utilisé en synergie avec d'autres cryptages
Posté par free2.org . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
sur quel document tu te base pour affirmer que l'accès lecture/ecriture à toutes les données par l'utilisateur est dans la norme TCPA ?
(moi je cite un document où il est marqué que l'utilisateur n'a pas accès au contenu du random generator, ce qui n'est pas rassurant sur la qualité de celui-ci. un bon générateur doit avant tout se baser sur des phénomènes physiques imprévisibles comme le bruit ou l'émission de particules. pas sur un pseudo générateur mathématique et donc déterministe)
et comme TCPA autorise l'ajout de fonctionnalités par les constructeurs (et par l'auteur du BIOS, je pense), pourquoi une fonctionnalité "protection de toutes les données TCPA" ne serait-elle pas ajoutée ?
# sécurité X Window
Posté par free2.org . En réponse à la dépêche RedHat Advanced Server certifié COE. Évalué à 1.
(je pense notamment au mode untrusted de xauth)
[^] # Re: Article sur le DRM sur uZine
Posté par free2.org . En réponse à la dépêche Devinez qui vient fouiller chez vous ce soir. Évalué à -1.
[^] # softs anonymes et cryptés
Posté par free2.org . En réponse à la dépêche Le peer-to-peer en ligne de mire. Évalué à 7.
# 3 autres problèmes de la loi
Posté par free2.org . En réponse à la dépêche Confiance dans l'économie numérique. Évalué à 1.
- doublement des peines pour "crime informatique" (je crois que le mot crime ne devrait s'appliquer que quand on met en danger l'intégrité du corps de quelqu'un, comme quand un automobiliste ne respecte pas un passage pour piéton), peines allant jusqu'à 30 ans je crois
- criminalisation des outils de sécurité (tous les outils de détection de failles), comment vont faire les gens pour être sûrs qu'ils sont protégés contre toutes ces failles ?
- impossibilité pratique de faire ou d'importer de la crypto open source avec un CVS (il faudrait faire une nouvelle déclaration à cahque modification dans le CVS
[^] # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort
Posté par free2.org . En réponse au journal les faits sur TCPA: de vraies raisons pour boycotter très fort. Évalué à 1.
oui mais la loi interdit de rendre obligatoire l'usage de la carte pour vendre un article
Par contre aucune loi n'empeche de rendre onligatoire l'usage de TCPA pour décrypter certains documents ou exécuter certains programmes DRM
Même dans un monde 100% windows, les utilisateurs doivent pouvoir s'échanger des fichiers
quand tu envooie un document, rien n'empeche windows de décrypter les fichiers avec la clé privée qui est dans ta puce TCPA puis de les encrypter avec la clé publique du destinataire de ces documents (c'est même probablement une des principales applications de TCPA)
ni ton LInux, ni celui du destinataire ne pourront accéder à ces documents
Bon, c'est vrai, M$ sux, mais ça n'en reste pas moins subjectif.
C'est un FAIT que MS est le seul non fabricant de CPU parmis les fondateurs de TCPA.
trustedpc.org
ce qui suit dans *conséquences est en effet mon interprétation des conséquences ce fait
[^] # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort
Posté par free2.org . En réponse au journal les faits sur TCPA: de vraies raisons pour boycotter très fort. Évalué à 1.
http://www.bigbrotherinside.org/(...)
Intel has decided not to include the PSN
http://www.cdt.org/privacy/issues/pentium3/(...)
n late-April, 2000, Intel quietly let it be known that future processors, starting with the Williamette family of processors, would not include the Processor Serial Number
http://www.intel.com/support/processors/pentiumiii/snum.htm(...)
Disabling the processor serial number can be done at any time, but enabling the serial number requires the processor to be reset
[^] # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort
Posté par free2.org . En réponse au journal les faits sur TCPA: de vraies raisons pour boycotter très fort. Évalué à 2.
avec une version corrigée:
http://free2.org/tcpa/(...)