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

(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)

> Lire le journal (15 commentaires, moyenne: 1,5).