des vérifications sur TCPA: les raisons pour lesquelles je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

IMPORTANT: Le professeur et directeur de l'unité Sécurité de l'Université de Cambridge, Ross Anderson, propose un document en anglais plus à jour que celui-ci: The TC FAQ
Une ancienne version française de ce document est disponible ici.

Puisqu'il circule beaucoup d'informations non vérifiables sur TCPA, voici 8 informations vérifiables sur TCPA (documents du site officiel TCPA ou documents officiels destinés à rassurer d'IBM cités à chaque fois) et leur conséquences pour nous les utilisateurs:

*info 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 c'est pour des problèmes de vie privée qu'ils ont pris la décision que l'accès à cette clé peut être désactivé dans les puces IBM actuelles. Cette décision interne d'IBM est la confirmation que la norme TCPA n'oblige pas à fournir la possibilité de désactiver cette clé (désactivation qui n'est faisable que si les softs et documents DRM dont on a besoin n'obligent pas à utiliser cette clé)
*conséquences de cette info: cette clé unique est pire qu'un simple numéro unique (retiré par Intel de ses processeurs, après des appels au boycott), 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 les 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.

*info 2.1: TCPA a pour but l'identification à distance de l'OS que j'ai booté: "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_020702.pdf
*conséquences: les fournisseurs de contenu auront donc la possibilité de discriminer l'OS que j'utilise. Ils pourront refuser de m'envoyer un contenu si je n'utilise pas Windows pour le recevoir.
Comme évoqué dans l'info suivante, Windows pourra alors faire en sorte qu'aucun autre OS de mon ordinateur puisse accéder à ces documents.

*info 2.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 que 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 cracker (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)

*info 2.3: un OS a la possibilité de prendre le controle total de la puce TCPA (appelée TPM) et de toutes ses fonctionnalités en devenant "owner" du TPM). La seule façon de reprendre le controle de la puce est de faire un reset, et de perdre les informations qu'elle contenait.
"A TPM is necessarily activated by a reset. This, however, causes the TPM to discard any existing secrets, and puts the TPM into its virgin state, waiting for an Owner." bas de la page 18 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf
*conséquences: Si les applications DRM de Win exigent que Win soit owner, on devra laisser owner à Win pour pouvoir utiliser ces applications.

*info 2.4: 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: cette information est à rapprocher des condamnations anti-trust définitives dont MS vient de faire l'objet. Cela prouve que Palladium n'est pas la seule technologie de contrôle soutenue activement par MS. Palladium peut s'appuyer sur TCPA qui intègre déjà des notions de l'activation framework de XP.

Conséquence de l'ensemble des informations 2.x ci-dessus: il est facile d'utiliser TCPA pour fournir l'équivalent des trusted sandboxs de Palladium.
Si le premier OS au moment du boot ne contient en fait qu'une trusted sandbox et un virtualiseur (comme le libre plex86, ou virtualPC, vmware, ...), alors il pourra faire tourner dans le virtualiseur un système complet, tout en controlant la manière dont ce système peut accéder aux informations contenues dans la trusted sandbox, ainsi qu'aux programmes qui s'exécutent dans cette sandbox.
On peut faire de meme en utilisant un micro-noyau: en faisant tourner de manière concurente et indépendante une sandbox et un OS au-dessus de ce micro-noyau. Depuis NT, Windows peut s'exécuter au-dessus d'un micro-noyau (le système libre Hurd s'exécute aussi au dessus d'un micro-noyau)
Quand un fournisseur de contenu voudra s'assurer que mon système contient une trusted sandbox de type Palladium, il pourra exiger que ma puce TCPA lui fournisse un checksum signé du premier OS du boot. Dès lors il pourra refuser de m'envoyer des documents ou des programmes si il constate que mon OS ne possède pas cette trusted sandbox.
On peut noter d'ailleurs que MS vient de racheter le virtualiseur VirtualPC: http://www.connectix.com/about/acquisition_win.html


*info 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 à mesure 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 obscurs non évolutifs cachés dans une puce.

*info 4: TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être 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, même sous forme de binaires, si aucune version récente de l'OS n'est signée pour TCPA.

*info 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é (ou dans son CPU)
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é

Bref, au moins pour toutes les raisons ci-dessus, je refuse fortement d'avoir des puces ou des softs TCPA dans mon ordinateur (au moins aussi fort que le numéro unique Intel dans chaque processeur qui a été abandonné après des appels au boycott)

URL permanente de cet article: http://free2.org/tcpa/

cette page est diffusable sous licence GNU GPL de la FSF (merci de garder un lien vers l'URL permanente)