Journal les faits sur TCPA: de vraies raisons pour boycotter très fort

Posté par .
Tags : aucun
0
26
fév.
2003
(article linuxfr en cours d'amélioration, envoyez moi vos remarques/suggestions)

Puisqu'il circulent beaucoup d'informations non vérifiables sur TCPA, voici 6 faits sur TCPA (specs officielles TCPA ou documents officiels destinés à rassurer d'IBM cités à chaque fois) et leur conséquences pour nous les utilisateurs:

*fait 1: au moment de la fabrication il est inséré une clé privée asymétrique unique dans chaque puce TCPA
"the endorsement key" "uniquely identifies the platform" au bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf
IBM dit que l'accès à cette clé peut etre fermé dans ses puces actuelles, mais les puces des autres constructeurs et les puces futures d'IBM pourraient très bien ne pas donner cette possibilité
*conséquences: cette clé unique est pire qu'un simple numéro unique (boycotté avec succès en son temps, dans les pentium d'Intel), car elle ne peut pas etre contrefaite (elle est authentifiable car elle seule peut décoder des messages cryptées avec sa clé publique associée). Un jour ou l'autre, l'utilisation de cette clé sera exigée par de nouveaux softs DRM (donc fermer l'accès à cette clé impliquera de ne pas pouvoir utiliser ces softs pour encoder/décoder) pour que seul un ordinateur précis puisse accéder à un fichier protégé par DRM, pour un temps précis en fonction de ce qu'a payé l'utilisateur de l'ordinateur, et des techniques de watermarking pourront être utilisées par ce soft DRM pour savoir si ce PC a fait une copie en utilisant des techniques analogiques et l'a envoyé à d'autres PCs.

*fait 2: il est possible pour un OS d'utiliser TCPA pour crypter certains documents et interdire aux autres OS d'accéder à ces documents
"if an attempt is made to boot an alternative system" "the unseal will fail, thus protecting the data" bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf
*conséquences: tous les utilisateurs de dual-boot (par exemple Linux et Windows sur le meme ordinateur) pourront bientot etre confrontés à des fichiers (documents ou programmes) encryptés sous Windows et inutilisables sous Linux: les documents ne seront donc pas ouvrables par openoffice, et les programmes ne seront donc pas exécutables par wine
notons que sous Linux et Windows il est deja possible de protéger par une passphrase certains documents ou certaines partitions. La différence est qeu cette passphrase est stockée dans le cerveau de l'utilisateur qui peut donc l'utiliser avec l'OS de son choix, pas dans une puce TCPA qui refusera à un OS alternatif de l'utiliser.
notons aussi que des outils libres comme tripwire permettent de s'assurer en bootant à partir d'une disquette ou d'un CD-rom qu'un OS n'a pas été modifié par un virus ou par un carcker (pas besoin de TCPA pour cela donc)
enfin des outils libres de sécurité comme LinuxSecurityModule, systrace, fireflier, permettent de s'assurer que certains fichier du système ne pourront aps être accédés par des programmes qui communiquent avec internet (limitant par là meme les dégats que peuvent causer un virus ou un cracker)

*fait 3: impossibilité de controler le code qui est dans les puces TCPA
contrairement aux softs libres de sécurité comme LSM/tripwire/fireflier/systrace, il est très difficile, voir impossible, d'aller controler le code qui sera stocké dans les puces TCPA .
Il est meme prévu dans la spec officielle de cacher au maximum le fonctionnement d'éléments comme le générateur aléatoire (qui est pourtant la base de la sécurité de tout cryptage)
"Intermediate results from the RNG are not available to any user. When the data is for internal use by the TPM (e.g., asymmetric key generation) the data is held in a shielded location and is not accessible to any user. " en haut de la page 13 de http://www.trustedcomputing.org/docs/TCPA_TPM_PP_1_9_7.pdf
*conséquences: sécurité et obscurité ne font pas bon ménage. Des chevaux de Troie ou des failles pourraient etre introduites dans ces puces sans que les utilisateurs le sachent. Les algorithmes de sécurité et de cryptages évoluent au fur et à mesrure que de nouvelles failles sont trouvées: il n'est pas prévu dans les specs de pouvoir changer ces algorithmes si une nouvelle faille est trouvée. Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique). La taille fixe de leur clé est incompatible avec l'évolution rapide des matériels et des techniques pour casser la crypto.
Bref, mieux vaut utiliser des logiciels libres de crypto évolutifs que des logiciels obscues non évoluttifs cachés dans une puce.

*fait 4: TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra etre booté avec ce mode
"the OS kernel would have to be signed"
paragraphe 4 du document critique d'un des créateurs de TCPA http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html
document commenté par IBM comme étant très raisonable "most reasonnable" et sans nier l'existence du mode "extend" au bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf
*conséquences du mode "extend": tous les OS libres (noyaux + programmes systèmes) que l'on peut recompiler en totalité ou en partie ne seront plus utilisables avec TCPA après recompilation.
Voir plus utilisables du tout meme sous forme de binaires si aucune version récente n'est signée pour TCPA.

*fait 5: les specs n'interdisent pas l'ajout de fonctionalités supplémentaires par chaque constructeur dans leur puces de sécurité:
"it can be integrated into some existing component or components"
page 11 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf
*conséquences: un PC à la norme TCPA ne sera donc pas une garantie que seules les fonctionalités de la norme TCPA sont dans ses puces de sécurité
ce PC pourra notamment interdire l'accès aux fonctions TCPA aux OS non signés (meme si le mode extend est abandonné dans les specs)
voir interdire le boot de tout OS non signé

*fait 6: Microsoft est le seul non fabricant de CPU à être membre fondateur de TCPA
cf "background" de http://www.trustedcomputing.org/tcpaasp4/index.asp
et les specs TCPA commencent par une notion de "roots of trust" très similaire à l'activation framework de Windows XP
page 12 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf
*conséquence: la non présence parmis les fondateurs d'autres producteurs spécialisés dans les logiciels n'est pas rassurante étant donné les condamnations anti-trust dont MS a fait l'objet. TCPA est donc clairement susceptible de faire partie de la stratégie de MS pour écraser ses concurents

Bref, au moins pour toutes les raisons ci-dessus, TCPA doit être boycotté très fort (au moins aussi fort que le numéro unique Intel dans chaque pentium qui a été abandonné suite à un boycott)
  • # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort

    Posté par . Évalué à 3.

    Ton article est super, les faits sont énoncés clairement et bien expliqués. Mon commentaire ? Ben... il y a un boulot d'information monstre qui nous attend. :-)

    Rien à voir : il faudrait penser à un système qui fasse que les longs journaux comme celui-là n'apparaissent pas en entier sur la page des journaux, ça bouffe toute la place !
  • # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort

    Posté par (page perso) . Évalué à 1.

    ...juste un problème : l'appel au boycott n'est-il pas interdit en France ?
  • # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort

    Posté par . Évalué à 1.

    (au moins aussi fort que le numéro unique Intel dans chaque pentium qui a été abandonné suite à un boycott)

    Je sais pas pourquoi tout le monde dis ça...Il a été ajouté la fonction bios qui permet d'annihiler sa lecture mais un programme doit pouvoir déverrouiller ça et lire le numero. A vérifier dans les doc intel mais j'en suis pratiquement sur.

    "La première sécurité est la liberté"

  • # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort

    Posté par (page perso) . Évalué à 4.

    > *fait 1: [....] les puces futures d'IBM pourraient très bien ne pas donner cette possibilité

    Va falloir m'expliquer ce qu'on appelle fait ou pas. Là c'est du FUD (c'est à dire faire peur sans aucune réalité concrete) : techniquement dans les puces ce n'est pas possible (ca c'est un fait)

    Le probleme c'est que dans les "faits" suivant c'est la meme chose, c'est du "pourrait" ou "pourront" mais pas du "il y a", "ils font" ou "ils ont prévu de faire".

    Je ne dis pas que ce que tu dis est faux, ininterressant ou meme que tu n'as pas raison sur le fond.
    Mais là c'est des "attention peut etre que plus tard" , comme "faits" on a vu nettement mieux.

    Ce ne sont que de possible dérives que permettent le systeme, les présenter comme des faits décrédibilise toute la démarche aupres des gens qui vont lire
    • [^] # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort

      Posté par . Évalué à 1.

      je précise dans les *conséquences:
      Un jour ou l'autre, l'utilisation de cette clé sera exigée par de nouveaux softs DRM (donc fermer l'accès à cette clé impliquera de ne pas pouvoir utiliser ces softs pour encoder/décoder)

      ensuite c'est un fait que ce n'est pas la norme TCPA qui oblige à donner l'option de désactiver cette clé, comme l'avoue IBM en disant "en tout cas dans nos puces à nous c'est possible"

      je crois que je vais rectifier l'article en ce sens

      http://free2.org/tcpa/(...)
  • # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort

    Posté par . Évalué à 1.

    Bon article, mais quelques remarques en passant:

    * fait 1: c'est exactement le même principe que pour les cartes bancaires... ni plus, ni moins. Donc c'est forcément une fonctionalité aussi utile que les CB (confiance d'une transaction), mais aussi policière (qd tu payes avec une CB, tu es tout de suite fiché)

    * fait 2: aucun risque de ce côté. Même dans un monde 100% windows, les utilisateurs doivent pouvoir s'échanger des fichiers. Donc pas de cryptage automatique des formats .doc ou autre. Par contre, c'est une possibilité supplémentaire de verrouiller des fichiers très sensibles. Donc à priori usage business ou militaire.

    * fait 3: cf fait 1. Comme pour les CB. Mais tes remarques sont juste: obscurité != sécurité

    * fait 6: ibm fait aussi du soft... mais je n'ai pas vu la liste des fondateurs. Mais ce fait n'en est pas vraiment un, car c'est un procès d'intention. Bon, c'est vrai, M$ sux, mais ça n'en reste pas moins subjectif.
    • [^] # Re: les faits sur TCPA: de vraies raisons pour boycotter très fort

      Posté par . Évalué à 1.

      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

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.