TCPA, fausses idées et clarification

Une traduction d'un article de David Safford, chercheur chez IBM
ayant pour titre original "Clarifying Misinformation on TCPA", octobre 2002
(original au format pdf) : http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf

Dans des papiers récents, Ross Anderson[8], Bill Arbaugh[10] et Lucky Green[12] critiquent TCPA[1] et Palladium[3], arguant qu'ils représentent un désastre pour le consommateur, et qu'ils ne servent qu'à faire appliquer la Gestion de Droits Digitaux (DRM ou Digital Right Management). Ces publications ont suscité une inquiétude à grande échelle chez les consommateurs, ce qui a même mené à la création d'un site anti-TCPA[9], qui a lancé un appel pour écrire aux sociétés membres de la TCPA. Malheureusement, les articles en question donnent des informations inexactes sur la TCPA dans la mesure où ils font un amalgame injustifié entre TCPA, Palladium et DRM présentent des spéculations sur TCPA comme des faits font preuve d'une mauvaise compréhension technique de la Spécification TCPA

Ce papier analyse ces publications anti-TCPA, traite les erreurs en détail, et démontre que leurs conclusions concernant TCPA sont tout simplement fausses. Ce papier défend seulement TCPA. Palladium et DRM devront se défendre eux-mêmes. Note : j'ai un système avec une puce TCPA sur lequel tournent Windows et Linux, et tous les commentaires qui suivent ont été vérifiés sur ce matériel. Tous les points de vue sont les miens, pas nécessairement ceux d'IBM.

Premièrement, les papiers cités font l'amalgame entre TCPA, Palladium et DRM, en les considérant comme la même chose. Aussi, clarifions ce que nous entendons par "TCPA". L'Alliance pour une Plate-forme Informatique de Confiance (Trusted Computing Platform Alliance) a été formée afin d'établir un standard industriel pour un sous-système informatique de confiance, pouvant être ajouté à un ordinateur.

IBM a intégré depuis plus de deux ans un prédécesseur de la puce TCPA dans des ordinateurs NetVista et ThinkPad. Elle s'appelle "sous-système de sécurité intégré" (ESS=Embedded Security Subsystem). L'ESS était principalement une puce à clé publique du style 'carte à puce', placée directement sur le bus SMB de la carte mère. L'idée était de rendre disponible des jetons de clé publique "en dur" à très faible coût, en les intégrant au système, éliminant la nécessité pour des cartes à puce et des lecteurs séparés.

D'autres sociétés étaient en train d'étudier des solutions similaires, et il devenait évident que l'on aurait besoin d'un standard commun. L'organisation TCPA a publié des spécifications libres ('Open Source') de tout le système TCPA[1] ; elles sont téléchargeables librement. La spécification TCPA principale définit une puce qui répond aux demandes de toutes les sociétés membres. Parallèlement, d'autres spécifications TCPA couvrent des interfaces ordinateur spécifiques et des détails logiciels.

Les fonctions de la puce TCPA elle-même peuvent être séparées en trois groupes principaux :

Les fonctions de clé publique sont très similaires à celles de la puce ESS d'IBM d'origine (qui possédait déjà des codes source sous GPL, utilisés activement dans plusieurs projets). Elles permettent une génération de paires de clés sur la puce, en même temps que la signature publique, la vérification, le cryptage et le décryptage.

Les fonctions de démarrage "en confiance" offrent la possibilité de stocker, dans des Registres de Configuration de la Plate-forme (PCR = Platform Configuration Registers), des hachages d'informations sur la configuration durant la séquence de démarrage. Une fois que l'ordinateur est démarré, des données (telles que des clés symétriques pour des fichiers cryptés) peuvent être "scellées" sous un PCR. Les données scellées ne peuvent être descellées que si le PCR possède la même valeur qu'au moment du scellage. Si on essaie de faire démarrer un autre système, ou si un virus a introduit un back-door dans le système d'opération, la valeur PCR ne correspondra pas et le descellement échouera, protégeant ainsi les données.

Les fonctions d'initialisation et de gestion permettent au propriétaire d'utiliser ou non la puce, de la remettre à zéro, et d'en prendre possession. Ce groupe de fonctions est un peu complexe, afin d'assurer une séparation forte entre ce qui peut être fait au niveau du BIOS (démarrage), et ce qui peut l'être lors du fonctionnement normal de l'ordinateur, pour qu'aucun logiciel malicieux puisse effectuer des opérations sensibles (comme la lecture de la clé d'endossement[15]).

Palladium est un projet mené par Microsoft pour ajouter une informatique "de confiance" à Windows, à travers une combinaison d'outils matériels et logiciels. Coté matériel il s'agit d'une puce similaire à la puce TCPA (Microsoft l'appelle SCP), en même temps que des modifications au niveau du processeur pour ajouter une protection de niveau trousseau-1 (ring-1), et des modifications du chipset pour créer un "espace mémoire de confiance" isolé (trusted memory space), et établir des "chemins de confiance" (trusted path) avec le clavier et avec l'écran. Coté logiciel, Palladium utilise des techniques de "hyperviseur" pour ajouter une application de confiance TOR[13], dans un espace protégé, séparé du système d'opération normal. Au jour d'aujourd'hui, il n'est pas encore sûr si Palladium intégrera un support pour la puce TCPA en plus de la puce SCP. Microsoft a déclaré que le matériel Palladium aura une spécification publique, et que Linux pourra être écrit pour fonctionner sur ce matériel. Ceci dit, Microsoft possède un grand nombre de brevets sur l'utilisation de ces modifications matérielles. Jusqu'au jour d'aujourd'hui, Microsoft n'a même pas garanti la mise en place de licences "raisonnables et non-discriminatoires" de ces brevets, donc Microsoft pourrait facilement interdire tout accès aux fonctions en question par Linux.

La conclusion est que TCPA et Palladium sont deux projets différents. La puce TCPA n'offre qu'un sous-ensemble des fonctions fournies par Palladium, qui inclut des éléments additionnels significatifs sur le plan matériel et logiciel. Seul TCPA a déjà une spécification détaillée librement téléchargeable, et un portage testé des pilotes et librairies sur Linux.

La Gestion des Droits Digitaux (Digital Rights Management) est une tentative pour contrôler l'utilisation et la copie de contenu digital, tel que musique et films. Des systèmes DRM existants, comme Windows Media Player avec ses fichiers au format "Windows Media Audio" (.wma), tournent au niveau logiciel. Ross Andersen et d'autres spéculent que TCPA et Palladium seront employés pour renforcer le DRM dans un système d'opération "de confiance". Mon avis personnel (je ne parle pas pour IBM) est que DRM est stupide, parce qu'il ne sera jamais efficace[6,7], et parce qu'il enlève des droits existants au consommateur. Mais c'est un autre débat. Condamner TCPA parce qu'il permet de faire tourner une mauvaise application est absurde. Cet argument ressemble aux arguments des gouvernements quand ils essaient de bannir le cryptage, sous prétexte que le chiffrement peut être utilisé par des terroristes pour dissimuler leurs messages. Dans le cas du cryptage, les gens se sont rendus compte qu'il s'agit tout simplement d'un outil pour protéger des données, et qu'il peut être utilisé pour de bonnes et de mauvaises causes. La même chose est vrai de TCPA. L'informatique de confiance peut rendre n'importe quelle application plus sûre : les bonnes et les mauvaises. Je n'ai aucun problème avec les gens qui s'insurgent contre le DRM : je suis totalement d'accord. Mais l'argument qui veut que l'informatique de confiance est mauvaise parce qu'elle peut supporter DRM est fallacieux : c'est ignorer complètement la sécurité que TCPA peut apporter aux bonnes applications, comme la sécurité de mes clés personnelles d'authentification, ou mes fichiers personnels chiffrés. Voir aussi le papier "Why TCPA" pour plus de détails sur les applications positives de TCPA.

Ross dit que "Palladium ... s'appuyera sur la puce TCPA" et que "l'application évidente est la Gestion de Droits Digitaux (DRM)". Le reste de sa FAQ traite principalement les problèmes concernant le DRM tel que possiblement implémenté dans Palladium.

Primo, ceci ne concerne pas TCPA, mais Palladium. Secundo, l'application évidente de TCPA n'est par le DRM, mais de permettre des individus de sécuriser leurs clés privées, et de sécuriser leurs données chiffrées contre des virus ou d'autres attaques qui peuvent compromettre le système d'opération. Il est incorrect de mettre TCPA dans le même sac que Palladium et DRM, sans distinction. Battez-vous contre le DRM, mais n'accusez pas TCPA de ce que est Palladium sait faire - il s'agit de deux systèmes différents.

"Lorsque vous amorcez votre PC, Fritz prend la main. Il vérifie que la ROM d'amorce est conforme, l'exécute, contrôle l'état de la machine ; puis il vérifie la première partie du système d'exploitation, le charge et l'exécute, vérifie l'état de la machine, et ainsi de suite."

Ceci est complètement faux. La puce TCPA n'exécute rien. Elle accepte des requêtes de données, et répond avec des données. Dans la version IBM, la puce TCPA est située sur le bus LPC et utilise des registres I/O. La puce TCPA ne contrôle pas et ne peut pas contrôler l'exécution !

"Les premières versions seront vulnérables à quiconque disposera des outils et de la patience nécessaires pour casser le matériel (i.e., lire les données en clair sur le bus entre le processeur et la puce Fritz). Cependant, à partir de la phase 2, la puce Fritz disparaîtra à l'intérieur du processeur principal, appelons-le « Hexium », et les choses deviendront beaucoup plus difficiles. Des opposants très motivés, et très riches, seront encore capable de le casser. Néanmoins, il est probable que cela devienne de plus en plus dur et coûteux."

Il y a deux erreurs ici : premièrement, la lecture du bus vers la puce TCPA ne révélera pas et ne pourra pas révéler une clé privée. Les clés privées sont générées sur la puce, et ne quittent jamais la puce sans être chiffrées. Mais surtout, TCPA a été développé pour protéger les données de l'utilisateur contre des attaques externes, et non pas contre une attaque par le propriétaire. Une défense contre une attaque par le propriétaire de l'ordinateur est un problème beaucoup plus compliqué à résoudre en terme de matériel. Les puces TCPA n'ont pas été conçues pour résister à une attaque matérielle locale telle qu'un analyse de puissance, RF ou chronométrique. C'est un exemple parmi d'autres que TCPA n'est pas prévu pour DRM, qui nécessite des niveaux de protection matérielle beaucoup plus élevés, étant donné qu'il n'y a pas de confiance vis à vis du propriétaire. Supposer une résistance matérielle future accrue de TCPA est un autre exemple de pure spéculation.

"Vous préférez peut-être ne plus être inquiété par les virus, mais ni TCPA ni Palladium ne régleront ce problème : les virus profitent de la manière dont les logiciels (comme Office ou Outlook de Microsoft) utilisent les macros."

Bien que TCPA ne puisse pas éviter qu'il y ait des logiciels stupides, il peut très bien maîtriser les dommages causés. En particulier, aucun virus pourra voler une clé privée protégée par TCPA. Comment pourrait-il le faire, puisque la clé est générée sur la puce, stockée sur la puce, et ne quitte jamais la puce ? En plus, des virus qui cherchent à s'introduire par des back-doors ou des chevaux de Troie pour accéder à vos données sensibles, peuvent être détectés et arrêtés par TCPA, en refusant de débloquer des clés dans un environnement compromis. C'est la fonction primaire de TCPA que de placer des informations critiques sur le plan sécuritaire dans le "dur", hors de portée de logiciels malicieux ou fonctionnant mal.

"De ce point de vue, TCPA et Palladium n'offrent pas autant de sécurité à l'utilisateur qu'au vendeur de PC, à l'éditeur de logiciel, et à l'industrie du spectacle. Ils ne sont d'aucune utilité pour l'utilisateur, bien au contraire."

Personnellement, je trouve la possibilité de protéger mes clés privées et mes données chiffrées très important et très utile.

"Fritz vérifie que les composants matériels sont sur la liste « approuvé TCPA », que les composants logiciels ont été signés, et qu'aucun d'entre eux ne possède un numéro de série ayant été résilié. Si la configuration du PC a connu des modifications significatives, la machine doit se reconnecter pour être certifiée en ligne."

Rien de tout ceci existe, ni dans les spécifications TCPA, ni dans les produits TCPA sur le marché. Bien que ces choses pourraient théoriquement être faites sur n'importe quel système d'opération, le fait de les présenter comme une réalité existante, au lieu de la spéculation pure qu'elle représente, est irresponsable.

"Il y a malgré tout un domaine où vous ne pouvez pas désactiver Fritz. Vous ne pouvez pas l'obliger à ignorer les logiciels piratés. Même s'il a été informé que le PC ne démarre pas en mode « de confiance », il vérifie toujours que le système d'exploitation n'est pas sur la liste des numéros de série résiliés."

Voici encore plus de spéculation pure présentée comme une réalité. Il n'existe pas de "liste de numéros de série résiliés". Est-ce quelqu'un pourrait créer une telle liste ? Oui, ça peut être réalisé, avec ou sans TCPA. Le nombre de choses stupides qui pourraient être réalisées est sans fin sur une machine de Turing complète. TCPA ne le fait pas, tout simplement.

"TCPA sapera les bases de la GPL (Licence Publique Générale) ... Pour obtenir un certificat du consortium TCPA, le postulant devra soumettre le code nettoyé à un laboratoire d'évaluation, en même temps qu'une masse de documentation démontrant pourquoi diverses attaques connues contre le code ne fonctionnent pas. (L'évaluation est du niveau E3 : suffisamment coûteuse pour laisser à l'écart la communauté du logiciel libre, mais assez permissive pour que la plupart des éditeurs de logiciels aient une chance de faire valider leurs codes sources vérolés.) Bien que le logiciel modifié sera protégé par la GPL, et que le code source sera libre, il ne pourra pas utiliser toutes les fonctionnalités TCPA à moins d'avoir un certificat spécifique à la puce Fritz de votre machine."

Encore de la spéculation fondée sur rien et présentée comme un fait. Le fait est que nous travaillons sur la publication de code source TCPA pour Linux sous GPL. La certification de code source par TCPA n'existe pas, il s'agit d'une invention pure.

"Les objectifs commerciaux de TCPA sont : 'Prévenir l'utilisation de logiciels sans licence' et 'Gestion des Droits Digitaux (DRM)'".

Les termes 'protection de droits d'auteur' et 'DRM' ne figurent nulle part sur le site www.trustedpc.org. Ils ne représentent pas l'objectif commercial premier, et la puce qui en est le résultat n'est pas particulièrement adaptée au DRM, étant donné qu'elle est mal protégée contre une attaque de la part du propriétaire. Les objectifs principaux sont la sécurisation des clés privées du propriétaire et celle des données chiffrées de l'utilisateur contre une attaque logicielle extérieure.

"La puce [TCPA] : résistante contre une interférence extérieure, montée en surface"

Eh bien, non. La puce TCPA n'est pas particulièrement résistante contre une interférence ou une attaque par le propriétaire. Dans les Critères Communs d'Evaluation pour TCPA, la résistance contre une interférence matérielle a été spécifiquement exclue des objectifs. La version IBM se présente sous forme d'une carte-fille LPC, et elle n'est pas spécialement protégée contre des attaques matérielles locales. Cela n'a jamais fait partie du cahier des charges, étant donné que le but était de protéger des données utilisateur contre une attaque logicielle extérieure.

Le diagramme 'Processus de démarrage du système d'opération TCPA' contient les éléments "Liste d matériel approuvé", "Liste de numéros de série résiliés" et "Décryptage des binaires du système d'opération", le tout présenté comme des fonctions TCPA existantes.

Aucune d'entre elles n'existe. Il s'agit encore une fois de spéculation présentée comme une réalité.

TCPA ne dépend d'aucun système d'opération. TCPA fonctionne déjà dans des environnements Windows et Linux.

La puce TCPA exécute toutes ses fonctions sans utiliser de certificat extérieur. Autant il est possible d'écrire une application DRM qui demande des certificats extérieurs, autant il n'existe aucune autorité de certification pour TCPA, et aucune application de la sorte ; ceci est encore totalement imaginaire.

Les commentaires de Bill Arbaugh sont les plus raisonnables, et ils contiennent en outre des suggestions constructives. Ceci dit, ils présentent aussi quelques idées erronées sur TCPA.

[La protection de l'intégrité et le stockage de confiance] utilisent des certificats racine de confiance en tant que base [pour les garanties de sécurité en question]

Ceci repose sur une mauvaise compréhension de la spécification TCPA. Aucun certificat n'est réquis, pour aucune fonction de la puce TCPA. Une telle autorité racine n'existe même pas, ni pour TCPA en général, ni pour les puces actuellement commercialisées par IBM. On peut générer des clés privées, les utiliser pour signer, chiffrer, sceller et désceller des données sous des PCR, sans aucun certificat.

Un certificat peut être nécessaire à une seule occasion, au cas où on veut prouver à un tiers que l'on possède une puce TCPA approuvée. La majorité des applications n'ont pas besoin de cela, et cette certification n'est pas supportée actuellement par les puces IBM. Si on souhaite développer une application qui nécessite un tel certificat, la spécification TCPA prévoit une clé d'endossement qui peut être utilisée pour obtenir un certificat convenable. Cela ne peut fonctionner que si quelqu'un, le fabricant par exemple, possède une trace de la clé publique d'endossement d'une puce TCPA donnée, et est en mesure d'utiliser cette information pour certifier des clés d'identité de la puce TCPA en question. Ceci n'est pas requis, et l'accès logiciel à la clé d'endossement peut être désactivé.

Il y a certainement un aspect "vie privée" à l'accès à la clé d'endossement, puisqu'elle identifie la plate-forme de manière unique. Aussi, la spécification TCPA fait beaucoup d'efforts pour permettre une certification anonyme. La meilleure défense pour des utilisateurs préoccupés par la protection de leur vie privée est de désactiver tout simplement la clé d'endossement.

1."Permettre aux propriétaires de charger leurs propres certificats racine de confiance"

La puce TCPA n'a pas de certificat, et n'en charge aucun. La seule clé privée que ne peut pas être effacée ni remplacée par le propriétaire est la paire de clés d'endossement, qui peut être créée sur la puce lors de sa fabrication, et enregistrée (la part publique) par le fabricant. Ce n'a d'ailleurs aucun sens pour l'utilisateur d'effacer ou de remplacer la clé d'endossement, étant donné que seule la clé enregistrée par le fabricant peut être utilisée pour l'endossement en question. Si vous voulez un endossement, vous avez besoin de cette clé. Si vous ne voulez pas d'endossement, vous pouvez désactiver tout accès à cette clé. Toutes les autres clés peuvent être chargées et effacées à souhait. Notez qu'IBM n'enregistre pas, et n'a jamais enregistré, de clés d'endossement, parce qu'aucun client ne l'a jamais demandé.

Ceci est tout à fait possible avec la version IBM existante. Il s'agit d'une carte-fille sur le bus LPC, qui peut simplement être ôtée ; ce faisant toutes les clés sont remises à zéro (le BIOS TCPA se plaindra, et il faudra utiliser la version non-TCPA). Il est plus facile de désactiver TCPA dans le BIOS. Certaines commandes inoffensives restent actives, mais toutes les commandes sensibles sont désactivées. Ceci est complètement sous contrôle du propriétaire. Sous Linux, on peut choisir de charger ou pas le pilote TCPA. Si on ne charge pas le pilote, aucune application peut accéder à la puce. C'est totalement sous contrôle de l'utilisateur.

La désactivation de la clé d'endossement permet la protection totale de la vie privée. Assurer cette protection tout en utilisant une forme quelconque de clé d'endossement est bien sûr très difficile. Les opérations autour de la clé d'endossement ont en réalité été développées pour protéger la vie privée de l'utilisateur en permettant la génération de multiples identités abstraites. Beaucoup d'efforts ont été faits dans la spécification pour définir un processus dans lequel la fonctionnalité de la clé d'endossement est limitée à la seule génération de ces identités. Une Autorité de Certification (CA) peut être sélectionnée par l'utilisateur en tant que seule entité pouvant faire le lien entre la clé d'endossement et une identité spécifique. Une CA différente peut être utilisée pour claque identité, si souhaité. L'utilisateur exerce un contrôle total sur le l'utilisation ou non, et si oui comment, utiliser la clé d'endossement.

Tout à fait ! Tout le code TCPA de base fonctionne sur Linux, et nous travaillons activement pour mettre sous GPL le pilote de base et la librairie interface

C'est une excellente idée, en particulier quand (4) aura été mis en place. TCPA est complexe, et la spécification est difficile à comprendre, en particulier les parties concernant l'initialisation et la gestion.

TCPA n'est pas Palladium TCPA n'est pas DRM. DRM est juste une application possible d'un composant "de confiance". Critiquez DRM autant que vous voulez

Ce que TCPA ne fait pas : contrôler l'exécution bloquer une exécution, basé sur des signatures, listes de révocation ou d'approbation

Ce que TCPA fait : fournir une protection des clés privées et des données chiffrées d'un utilisateur protéger des données sensibles de beaucoup d'attaques logicielles, y compris des virus, des vers et des chevaux de Troie

http://www.trustedcomputing.org/docs/main%20v1_1b.pdf

http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v100.pdf

Palladium NB : depuis le 25-1-2003, Microsoft n'utilise plus le nom « Palladium ». Désormais, Microsoft fait référence aux fonctions de feu Palladium sous le nom « the next-generation secure computing base for Windows »

[4] Paul England et Marcus Peinado : "Authenticated Operation of Open Computing Devices" http://cs-people.bu.edu/mpe/acisp.pdf Editeur : Batten et Seberry, ACIPS 2002, LNCS 2384, Springer-Verlag, 2002

Toutes les citations de la FAQ de Ross Anderson proviennent de la traduction française

[15] Clé d'endossement (endorsement key) : pourrait également être traduit par 'clé d'approbation', ou 'clé d'aval'. Terme de cryptographie utilisé exclusivement dans les spécifications TCPA.

Ce papier a été rédigé par David Safford, manager au IBM's Global Security Analysis Laboratory, en octobre 2002.