Je crois que tu es vraiment aveuglé. Il n'a y a rien à ajouter que de répéter l'avoeu d'IBM, cofondateur de TCPA/TCG et fabriquant de puces TCPA: could be used to prevent play unless a trusted operating system and application were in use
C'est clair pour tous ceux qui le lisent, sauf pour ceux qui préfèrent ne pas comprendre.
Quand on s'exprime dans un forum on peut faire des maladresses. Si j'en ai fait, mea culpa.
Mais il faut classer les conséquences de la généralisation de TCPA par ordre d'importance.
Et la conséquence la plus importante est clairement la possibilité d'obliger le grand public à utiliser des OS DRM et du matériel DRM pour pouvoir se connecter. Dans un pays comme la France.
Je ne parle même pas des conséquences dans une dictature comme la Chine.
Ici ou là-bas, les conséquences de TCPA sont tellement graves pour la liberté de faire ce qu'on veut avec son ordinateur, que le reste devient très secondaire.
signed PCR information, and this information could be used to prevent play
unless a trusted operating system and application were in use,
Tu nies l'évidence, c'est pathétique.
C'est ta parole contre celle de TCG et IBM qui admettent clairement dans les documents que j'ai cité que on peut identifier à distance la plateforme en utilisant les metrics (c'est à dire les hash) des matériels et des logiciels.
Encore une fois les nombreux documents que j'ai cité, et que tu n'as pas pu contesté, disent clairement le contraire.
"a provider
will need to know that the remote platform is trustworthy" "The TCPA
system reports the metrics and lets the challenger make the final decision regarding the trustworthiness of the remote platform."
JE corrige c'est dans ce document IBM pro TCPA: http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...) The TCPA chip is not particularly suited to DRM. While it does have the ability to
report signed PCR information, and this information could be used to prevent play unless a trusted operating system and application were in use, this type of scheme
be a nightmare for content providers to manage. Any change to the BIOS, the oper
system, or the application would change the reported values. How could content
providers recognize which reported PCR values were good, given the myriad platfo
operating system versions, and frequent software patches?
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.
Ce dernier argument n'est pas sérieux avec la puissance actuelle des clusters de PC bon marchés. (cf les clusters de Google).
Ces histoires ridicules ont vraiment bien peu d'importance par rapport notamment à aux identifications de l'OS et des processeurs , qui elles ne dépendront surement pas de l'age du HDD ou du capitaine :) Et ce afin de s'assurer que l'OS et le proc ont bien le DRM que le provider requiert.
D'ailleurs puisque on parle des docs d'origine, moi j'avais réupéré ça, sur l'ancien site TCPA (aujourd'hui offline) et toi aussi je le sais puisque je t'en avais communiqué l'URL:
"a provider
will need to know that the remote platform is trustworthy" "The TCPA
system reports the metrics and lets the challenger make the final decision regarding the
trustworthiness of the remote platform." http://www.trustedcomputing.org/docs/Credible_Interoperability_0207(...)
http://66.102.9.104/search?q=cache:https://www.trustedcomputinggrou(...) TCG features could potentially enable a situation in which users are essentially
“forced” to use the TCG mechanism in order to have access to a set of services. This could result from “bundling” — where a single large provider of services could use the combination of its role as a major provider with the TCG remote attestation
capability to ensure that the user is employing a configuration that the provider
insists upon, even when there is no security reason for such a choice. Another
situation that can arise is where a significant portion of the providers of a particular
service could use their market clout (the fact that they constitute a majority of
providers of that particular type of service) to essentially force the use of TPM
Alors je t'explique: another cela veut dire une autre situation.
Par remote attestation ils n'entendent donc simplement pas le fait de forcer quelqu'un à montrer qu'il a TPM mais bien de forcer quelqu'un à montrer les hash de sa configuration.
Dans tous les cas, c'est mieux d'avoir un OS fiable et sécurisé
C'est en effet le véritable fondement de la sécurité et TCPA n'y changera rien.
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 ?
N'importe quoi. Tu es de mauvaise foi car on a déja parlé ensemble de booter sur un medium read-only sur lequel est tripwire qui va vérifier l'intégrité de l'OS avant de le booter. C'est faisable maintenant, facilement et sans puce TCPA.
Chaque années de nouvelles failles sont trouvées dans les algo de crypto ce qui doit nous inciter à la prudence. En utilisant des clés et des hashs ayant la taille maximale que l'on puisse traiter avec un temps raisonable. Inutile d'attendre d'avoir une grosse faille pour augmenter ces tailles.
Il est deja démontré que la crypto la plus fiable (la seule qui est non cassable) est la crypto qui utilise des clés au moins aussi grandes que la taille des données qui seront à traiter (one time pad). Et tout cryptanaliste sait bien à quel point le ratio tailles des données / taille des clés est un ratio important.
Il est clair que ces puces implémentant des algorithmes déjà bien attaqués dans du hardware, en + d'éventuelles backdoors que nous pourront pas y déceler, sont mal adaptées à l'évolution rapide de la crypto.
C'est clair. Le but de TCPA, c'est de repousser au niveau de hardware les possibilités d'attaques.
Non, les données seront accéder par un OS et par des logiciels. Et s'ils contiennent des failles, ces données seront accessible à un tiers, que tu ais TCPA ou non.
Par contre, être protégé des attaques logiciel
Et tu y accedes comment à tes données ? Par tes logiciels non ? C'est un énorme mensonge que de laisser croire que TCPA va protéger des failles de ton OS ou de tes logiciels. Meme les algorithmes de crypto et le générateur aléatoire de TCPA sont sujets à caution.
Comme je l'ai déja mentionné ici, des OS démontrés fiables à base de micronoyaux (comme EROS ou COYOTOS) sont bien plsu importants que d'avoir une puce dans laquelle on croit en croisant les doigts.
J'ajoute que l'article dont on parle concerne uniquement TCPA dans Linux, pour la bonne raison que TCPA a introduit la remote attestation bien avant les autres puces DRM (et des brevets ont certainement été déposés par les membres de TCG, dont Intel et IBM). C'est pour cette raison que certains logiciels libres ( mais certains le refusent comme les logiciels du projet GNU) dont Linux intègrent déjà un support pour TCPA.
Impossible d'avoir une remote attestation sans stocker dans une puce "de confiance" les hashs des composants matériels et logiciels d'un PC, ce qui est la base de TCPA.
J'ai expliqué ici à tous le remote attestation de TCPA et pourquoi il faut le refuser dans les PC du grand public. Suivons l'exemple de l'équipe du GNU bootloader GRUB qui refuse d'intégrer un patch avec le support TCPA pour que leurs utilisateurs prennent conscience quelles seront les conséquences d'une popularisation des puces remote attestation.
Evidemment toutes les puces DRM sont susceptibles de poser une menace similaire et il vaut mieux toutes les refuser. Et tous ceux qui veulent nous parler en détails des dangers de ces autres puces seront, je pense, ici les bienvenus.
Désolé mais les documents TCG et IBM que je viens de citer et qui sont en lignes, ainsi que les documents d'intel que j'ai lu il y a 2 ans et dont j'avais commuiqué l'uRL sur linuxfr et à toi sont très clairs:
le remote attestation de la plateforme est bien la communication des hashs des composants de cette plateforme, ce qui dans les définitions TCPA a toujours correspondu au matériels et aux logiciels de cette plateforme.
Et l'analyse métrique du système
etc.
Impossible de réaliser le remote attestation de la plate-forme complete (matériel et logiciels) sans ces fonctions.
Tout dans TCPA tend vers le remote attestation.
Le remote attestation aura des répercusions très graves sur nos libertés et est bien plus important que toute les bidouilles qu'on pourrait faire par ailleurs avec TCPA alors que d'autres techniques permettent aussi d'améliorer la sécurité d'un ordi mais sans permettre le remote attestation.
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. Voila ce qui est important.
essaye d'éviter le FUD par pitié.
C'est surtout toi qui en fait: 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.
Le remote attestatiàon de TCPA n'a rien à voir avec cela.
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 !
Relis bien le document de TCG que j'ai cité ci-dessus où ils reconnaissent que cette remote attestation est un fait.
Dommage que tu sois en retard sur eux sur ce FUD.
Mais ces systéme dépasse largement le cadre du simple marketing, la pile non exécutable qui permet d'éviter l'exploitation de la plus part des buffer overflow est un gain de sécurité notable, TCPA s'inscrit dans le même domaine
Je ne vois vraiment pas du tout le rapport.
La seule vraie nouveauté de TCPA est le remote attestation.
mais je ne comprend pas pourquoi vous voulez absolument rejeter toutes les avancés de TPM en bloque, cela plusieurs fois que nous avons des échanges sur ce points sans que vous ayez fournit un début de réponse.
Si tu n'a pas compris ma comparaison avec le ID du pentium 3 qui a été abandonné suite à boycott. Tu ne comprendras jamais en effet.
Le truc important en matière de haute sécurité est d'avoir un OS fiable, le reste (y compris TCG/TCPA/TPM) c'est souvent du marketing quand ce n'est pas pire.
On peut y ajouter les OS à base de micronoyau comme Hurd qui sont bien plus facile à auditer que les monolithes et dont certains services sont complètements indépendants les uns des autres (userspace).
1. Le remote attestation n'est pas possible sans une puce de type TCG.
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é).
De 1. et 2. je déduis que, en matière de business, l'avantage concurentiel de TCG est de loin le remote attestation.
Il va y a voir une pression économique très forte de la part des fournisseurs de contenus pour imposer aux utilisateurs TCG.
La façon efficace de lutter contre cela est de refuser d'avoir ces puces. C'est en effet sous la pression des consommateurs qui le refusaient que le numéro d'identification des pentium 3 a été abandonné.
Même TCG admet officiellement la "remote attestation": remote attestation
capability to ensure that the user is employing a configuration that the provider
insists upon, even when there is no security reason for such a choice http://66.102.9.104/search?q=cache:https://www.trustedcomputinggrou(...)
Oui TCPA, TCG, TPM, trusted computing group
C'est bien la meme chose. (toutes ces marques sont déposées par TCG).
Le principal problème est que ces puces permettent l'identification à distance des logiciels et matériels utilisés (remote attestation).
Si leur usage se répand, des fournisseurs d'accès et de contenus exigeront qu'on active notre TPM pour s'assurer que le matériel et les logiciels que nous utilisons contiennent un DRM qui leur convient.
Une petite recherche sur le web avec tcg "remote attestation" vous en dira +
[^] # Re: "remote attestation" avouée clairement par why_tcpa d'IBM
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 3.
could be used to prevent play unless a trusted operating system and application were in use
C'est clair pour tous ceux qui le lisent, sauf pour ceux qui préfèrent ne pas comprendre.
[^] # conséquences graves passent avant le reste
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 3.
Mais il faut classer les conséquences de la généralisation de TCPA par ordre d'importance.
Et la conséquence la plus importante est clairement la possibilité d'obliger le grand public à utiliser des OS DRM et du matériel DRM pour pouvoir se connecter. Dans un pays comme la France.
Je ne parle même pas des conséquences dans une dictature comme la Chine.
Ici ou là-bas, les conséquences de TCPA sont tellement graves pour la liberté de faire ce qu'on veut avec son ordinateur, que le reste devient très secondaire.
[^] # Re: "remote attestation" avouée clairement par why_tcpa d'IBM
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
unless a trusted operating system and application were in use,
Tu nies l'évidence, c'est pathétique.
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
[^] # OS fiable avant tout, remote attestion grave, docs clairs
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
"a provider
will need to know that the remote platform is trustworthy" "The TCPA
system reports the metrics and lets the challenger make the final decision regarding the trustworthiness of the remote platform."
C'est clair et net !
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
[^] # "remote attestation" avouée clairement par why_tcpa d'IBM
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
The TCPA chip is not particularly suited to DRM. While it does have the ability to
report signed PCR information, and this information could be used to prevent play
unless a trusted operating system and application were in use, this type of scheme
be a nightmare for content providers to manage. Any change to the BIOS, the oper
system, or the application would change the reported values. How could content
providers recognize which reported PCR values were good, given the myriad platfo
operating system versions, and frequent software patches?
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.
Ce dernier argument n'est pas sérieux avec la puissance actuelle des clusters de PC bon marchés. (cf les clusters de Google).
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
D'ailleurs puisque on parle des docs d'origine, moi j'avais réupéré ça, sur l'ancien site TCPA (aujourd'hui offline) et toi aussi je le sais puisque je t'en avais communiqué l'URL:
"a provider
will need to know that the remote platform is trustworthy" "The TCPA
system reports the metrics and lets the challenger make the final decision regarding the
trustworthiness of the remote platform." http://www.trustedcomputing.org/docs/Credible_Interoperability_0207(...)
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
TCG features could potentially enable a situation in which users are essentially
“forced” to use the TCG mechanism in order to have access to a set of services. This could result from “bundling” — where a single large provider of services could use the combination of its role as a major provider with the TCG remote attestation
capability to ensure that the user is employing a configuration that the provider
insists upon, even when there is no security reason for such a choice. Another
situation that can arise is where a significant portion of the providers of a particular
service could use their market clout (the fact that they constitute a majority of
providers of that particular type of service) to essentially force the use of TPM
Alors je t'explique: another cela veut dire une autre situation.
Par remote attestation ils n'entendent donc simplement pas le fait de forcer quelqu'un à montrer qu'il a TPM mais bien de forcer quelqu'un à montrer les hash de sa configuration.
Ces hashs sont d'ailleurs aussi évoqués par ce white paper d'IBM, pourtant destiné à faire la promotion de TCPA:
http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...)
[^] # Re: et oui les TPM ...
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
C'est en effet le véritable fondement de la sécurité et TCPA n'y changera rien.
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 ?
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à -1.
Du délire total :)
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
[^] # Re: et oui les TPM ... taille données / taille des clés, ratio crucial
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
Il est deja démontré que la crypto la plus fiable (la seule qui est non cassable) est la crypto qui utilise des clés au moins aussi grandes que la taille des données qui seront à traiter (one time pad). Et tout cryptanaliste sait bien à quel point le ratio tailles des données / taille des clés est un ratio important.
Il est clair que ces puces implémentant des algorithmes déjà bien attaqués dans du hardware, en + d'éventuelles backdoors que nous pourront pas y déceler, sont mal adaptées à l'évolution rapide de la crypto.
[^] # Re: et oui les TPM ...
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
Non, les données seront accéder par un OS et par des logiciels. Et s'ils contiennent des failles, ces données seront accessible à un tiers, que tu ais TCPA ou non.
[^] # TCPA n'est pas une solution magique pour des OS non secure
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 3.
Et tu y accedes comment à tes données ? Par tes logiciels non ? C'est un énorme mensonge que de laisser croire que TCPA va protéger des failles de ton OS ou de tes logiciels. Meme les algorithmes de crypto et le générateur aléatoire de TCPA sont sujets à caution.
Comme je l'ai déja mentionné ici, des OS démontrés fiables à base de micronoyaux (comme EROS ou COYOTOS) sont bien plsu importants que d'avoir une puce dans laquelle on croit en croisant les doigts.
[^] # "remote attestation" TCG et refus de toutes les puces similaires
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 3.
Impossible d'avoir une remote attestation sans stocker dans une puce "de confiance" les hashs des composants matériels et logiciels d'un PC, ce qui est la base de TCPA.
J'ai expliqué ici à tous le remote attestation de TCPA et pourquoi il faut le refuser dans les PC du grand public. Suivons l'exemple de l'équipe du GNU bootloader GRUB qui refuse d'intégrer un patch avec le support TCPA pour que leurs utilisateurs prennent conscience quelles seront les conséquences d'une popularisation des puces remote attestation.
Evidemment toutes les puces DRM sont susceptibles de poser une menace similaire et il vaut mieux toutes les refuser. Et tous ceux qui veulent nous parler en détails des dangers de ces autres puces seront, je pense, ici les bienvenus.
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
le remote attestation de la plateforme est bien la communication des hashs des composants de cette plateforme, ce qui dans les définitions TCPA a toujours correspondu au matériels et aux logiciels de cette plateforme.
[^] # Re: et oui les TPM ... OS fiable avant tout, remote attestion grave
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 4.
etc.
Impossible de réaliser le remote attestation de la plate-forme complete (matériel et logiciels) sans ces fonctions.
Tout dans TCPA tend vers le remote attestation.
Le remote attestation aura des répercusions très graves sur nos libertés et est bien plus important que toute les bidouilles qu'on pourrait faire par ailleurs avec TCPA alors que d'autres techniques permettent aussi d'améliorer la sécurité d'un ordi mais sans permettre le remote attestation.
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. Voila ce qui est important.
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 1.
C'est surtout toi qui en fait:
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.
Le remote attestatiàon de TCPA n'a rien à voir avec cela.
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 !
Relis bien le document de TCG que j'ai cité ci-dessus où ils reconnaissent que cette remote attestation est un fait.
Dommage que tu sois en retard sur eux sur ce FUD.
[^] # Re: et oui les TPM ... OS fiable avant tout
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 1.
Je ne vois vraiment pas du tout le rapport.
La seule vraie nouveauté de TCPA est le remote attestation.
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à -1.
Si tu n'a pas compris ma comparaison avec le ID du pentium 3 qui a été abandonné suite à boycott. Tu ne comprendras jamais en effet.
[^] # Re: et oui les TPM ... OS fiable avant tout
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
C'est pour cela que j'ajoute ces liens vers des OS libres démontrés fiables:
http://www.eros-os.org/(...)
http://coyotos.org/(...)
On peut y ajouter les OS à base de micronoyau comme Hurd qui sont bien plus facile à auditer que les monolithes et dont certains services sont complètements indépendants les uns des autres (userspace).
[^] # "remote attestation" avouée par TCG et aussi par IBM, refuser = gagner
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 3.
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é).
De 1. et 2. je déduis que, en matière de business, l'avantage concurentiel de TCG est de loin le remote attestation.
Il va y a voir une pression économique très forte de la part des fournisseurs de contenus pour imposer aux utilisateurs TCG.
La façon efficace de lutter contre cela est de refuser d'avoir ces puces. C'est en effet sous la pression des consommateurs qui le refusaient que le numéro d'identification des pentium 3 a été abandonné.
[^] # Re: TPM, TCPA, TCG, "remote attestation" avouée par TCG et aussi par IBM
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 6.
remote attestation
capability to ensure that the user is employing a configuration that the provider
insists upon, even when there is no security reason for such a choice
http://66.102.9.104/search?q=cache:https://www.trustedcomputinggrou(...)
Idem pour IBM:
these mechanisms interact to
enable remote attestation
http://66.102.9.104/search?q=cache:hMRNHAVJ3BwJ:byte.csc.lsu.edu/~d(...)
[^] # TPM, TCPA, TCG, "remote attestation"
Posté par free2.org . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 9.
C'est bien la meme chose. (toutes ces marques sont déposées par TCG).
Le principal problème est que ces puces permettent l'identification à distance des logiciels et matériels utilisés (remote attestation).
Si leur usage se répand, des fournisseurs d'accès et de contenus exigeront qu'on active notre TPM pour s'assurer que le matériel et les logiciels que nous utilisons contiennent un DRM qui leur convient.
Une petite recherche sur le web avec tcg "remote attestation" vous en dira +