il y est précisé à maintes reprises que les PCR privés ne devaient jamais être révélés (ni en clair ni en signé)
Des références ? Je vois bien un doc qui dit que PCR[7] est "manufacturer specific" et que "user applications must not use this PCR for sealing or attestation" - pour la simple raison qu'il n'est pas digne de confiance; est-ce à celà que tu fais allusion ?
Je ne vois pas comment on peut faire du Remote Attestation sans révéler des valeurs ou hashes de PCR[0..6] signés.
celà implique quand même de garder au chaud un exemplaire de chaque configuration avec ces N Sha-1 de PCR possibles
J'ai déjà expliqué comment on pourrait implémenter cette base de données de façon distribuée: il suffit que chaque constructeur de PC, en sortie d'usine, lise les PCR, signe un document qui dit "je garantis que la configuration définie par les valeurs de PCR XX,YY,ZZ est une plate-forme TCPA digne de confiance", et enregistre ce document sur le disque dur ou dans le BIOS.
Si les banques continuent à considérer que la sécurité de la machine n'est pas leur problème mais celui du client, elles ne chercheront pas à imposer le TPM
Il y a déjà des banques qui imposent une carte à puce pour certains clients et certaines opérations: http://entreprises.bnpparibas.net/francais/html/lecteur01.ht(...) . Si on leur dit qu'il y a l'équivalent d'une carte à puce dans tous les PC du monde, ou si le gouvernement annonce que TCPA remplit les critères techniques de la LCEN pour faire des signatures numériques non répudiables, elles vont sauter sur l'occasion.
logiciel libre [...] poids suffisant pour que les mauvaises idées ne soient plus appliquables
Le logiciel libre n'exclut pas TCPA. Les constructeurs de cartes vidéo et WiFi pourraient fournir des drivers Linux sous forme de modules binaires chiffrés qui ne tourneront que sur le noyau version X.Y.Z signé par RedHat (avec PTRACE et /dev/kmem désactivés). Tout ça pour satisfaire des obligations légales (DMCA pour les drivers vidéo, certification FCC pour les drivers WiFi).
Quel serait l'intéret pour un fai de certifier l'OS de ses clients?
Exonérer sa responsabilité pour les virus envoyés par ses clients, pour les MP3 qu'ils téléchargent, etc. Historiquement les FAI et opérateurs télécom n'étaient pas juridiquement responsables des actions de leurs clients, mais ce principe est régulièrement remis en question par des lois telles que LCEN et DADVSI.
Et éviter que ses serveurs SMTP soient blacklistés par le reste du monde à cause des botnets qui envoient du spam depuis son réseau.
Et quel serait l'intéret d'un site E-Commerce?
Lutter contre la fraude.
Recevoir des bons de commande signés numériquement qui engagent l'acheteur comme une signature manuscrite (c'est dans la LCEN).
Et surtout, avoir accès aux nouvelles infrastructures de paiement sécurisé. Si le client est TCPA, il clique une fois "acceptez vous de payer 1 centime à chaque fois que vous consultez un article sur linuxfr.org ?" et ensuite il paie sans s'en apercevoir avec son porte-monnaie électronique. Si le client n'est pas TCPA, on lui demande de sortir sa carte bleue à chaque fois, et il n'achète pas, parce que ça le gonfle.
Un keystore hardware, capable de signer des transactions dans des sessions.
Si on voulait juste un keystore hardware, une clé USB suffirait. Le TPM est beaucoup plus que ça, parce qu'il est soudé à la carte mère, de la même façon qu'on met des tags antivol inamovibles sur les vêtements dans les magasins.
Idéalement, du point de vue de la sécurité, on voudrait faire tourner les OS et les média players dans un environnement sécurisé, du genre carte à puce haut de gamme qui s'auto-détruit quand on la chatouille un peu trop. Mais ça couterait trop cher, d'où TCPA qui est un compromis raisonnable entre sécurité et coût. Le TPM sert essentiellement à garantir à Sony, à Microsoft, à ton administrateur réseau, à ton ISP, et accessoirement à toi, que ton PC est digne de leur confiance, à moins qu'il soit passé entre les mains d'un pro du dessoudage de composants BGA sur circuits imprimés multi-couches.
dans le document il est indiqué qu'à l'origine, normalement, il n'y a pas d'EK définie
Dans http://www.microsoft.com/windowsvista/privacy/privacy_ctp.ms(...) je lis seulement "The endorsement key may be created and stored in the TPM by your computer's manufacturer, or you may choose to have Windows create it as part of TPM initialization". D'après ce que j'ai lu ailleurs, il faut comprendre ça comme: Soit EK est déjà installée par le constructeur, soit elle ne l'est pas; dans le second cas, on peut choisir de créer EK soit avec Windows, soit avec un autre outil.
Ce qui n'est pas installé en usine, ce sont les clés AIK (mais elles sont liées à EK lorsqu'elles sont créées).
je trouve ça bizarre que tu dises que l'EK sera d'office initialisée par Sony/Microsoft
Je n'ai pas dit ça. J'ai écrit "initialisée en usine". Donc par le constructeur ou par quelqu'un à qui il fait confiance. Et c'est normal puisque le constructeur engage sa responsabilité vis à vis de toi et de Sony/Microsoft en signant (en gros) "je déclare que la plate-forme qui connait la clé PrivEK associée à la clé PubEK XXXXXXXXX protègera vos données conformément à la norme TCPA".
ça m'arrangerai que tu me dises si j'ai pas trop dit de conneries dans mon article
Je n'ai rien vu de choquant, c'est une bonne introduction pas trop technique. Bravo pour ton initiative de recenser les produits équipés de TPM.
il est pour l'instant exclu que l'on puisse vendre un TPM avec des cases préparamétrées à l'avance et déjà réglées sur "Boot certifé de windows" par exemple.
Ceci nous garantit que Microsoft ne peut pas forcer Dell à vendre des PC qui rechigneraient à booter Linux (comme la Xbox). Mais les restrictions que tu cites n'empêchent pas de faire du DRM et plein d'autres choses excitantes.
Le TPM est comparable à une boite noire posée à l'arrière d'un port série. [...] il ne peut qu'interdire l'accès aux clefs qu'il contient.
Ouais, mais si Windows a chiffré tous mes documents avec des clés stockées dans le TPM, ça me fait une belle jambe de savoir que je peux le débrancher...
la première fois que tu actives le TPM, il t'es demandé une "endorsment key" qui est la clé qui permettera de déterminer si tout le reste est valide ou pas
En effet le document de Microsoft que tu cites suggère que Windows est capable d'initialiser l'EK, mais ça ne se passera pas comme ça en pratique. Les release notes (https://www.trustedcomputinggroup.org/groups/tpm/TPM_1_2_Cha(...) , paragraphe Clear Endorsement Key) précisent que la possibilité de changer EK sera réservée aux customers with special security needs (pour les militaires, quoi).
Les TPM grand publics auront une EK initialisée en usine et indélébile. C'est grace à cet identifiant unique que Microsoft et Sony pourront déterminer que ton PC est digne de leur confiance, et que leurs licences logicielles et leurs contenus DRM pourront être attachés à ce PC et à lui seul. Et si on a de la chance, le constructeur ne conservera pas une copie des EK pour la NSA.
Pourquoi la NSA [...] aurait-elle plus en ligne de mire les TPM que les autres systèmes
Parce que le TPM est conçu comme la clé de voute d'une infrastructure de confiance mondiale. Il est probable qu'un jour on ne pourra plus se connecter à Internet sans s'authentifier avec un TPM (ou que seuls les terroristes refuseront de s'authentifier). Pour faire passer la pilule il suffira d'organiser un bon gros Pearl Harbour informatique avec un virus Windows bien destructeur, puis de décréter qu'Internet est en danger mais qu'heureusement 99.9% des PC sont équipés d'un TPM et qu'il suffit d'activer la fonction Trusted Network Connect pour sauver la démocratie.
Pas seulement la clé de voute d'ailleurs, mais aussi la barrière de péage. A terme les maisons de disque européennes ne pourront plus publier de la musique sous DRM fiable sans verser des royalties à des consortiums américains.
la NSA aurait la mains mise sur TBD, Infineon, Atmel, NSM, Broadcom
Pourquoi la NSA ? Il suffit que la justice demande gentiment à un constructeur de l'aider à extraire les clés d'un TPM.
Le tout, sans la moindre fuite ?
Aucun risque puisque la backdoor est une fonctionnalité normalisée. "Mais monsieur on vous l'avait bien dit qu'on pouvait récupérer vos clés, c'est écrit dans le chapitre 15 de la spécification."
C'est un peu gros
Ce n'est rien par rapport au coup des imprimantes laser américaines qui insèrent leur numéro de série en watermark dans nos documents depuis des années: http://www.eff.org/Privacy/printers/index.php
Maintenant, il est clair qu'un back-door peut toujours exister, mais ça la foutrait très mal pour les supporters du tpm.
La backdoor est prévue dans les specs, en option: voir la section 15 ("Maintenance") du document "TPM Main Part 1 Design Principle". Le constructeur peut extraire le contenu du TPM, y compris les clés marquées "non migrables" par le propriétaire.
En principe il faut le mot de passe du propriétaire, mais ça ne doit pas être trop dur à sniffer avec la collaboration du fournisseur du BIOS ou de l'OS. Au pire le constructeur peut désactiver les protections en injectant un firmware troué (section 15.1 "Field Upgrade").
Pas besoin de passer par des certificats. En entreprise l'EK ne sert à rien, autant le désactiver si on en a pas besoin.
Oui mais là on ne parlait plus du certificat EK, on parlait de l'attestation semi-anonyme avec les AIK. Tu confirmes que la certification des AIK par le "privacy CA" ne sert à rien en entreprise ? Et qu'elle n'est donc utile que pour faire du DRM ?
On ne peut pas sortir PrivEK parceque sinon ca ne certifirait plus rien et donc les gens qui ont besoin de PrivEK ne pourraient plus s'en servir (Par exemple pour faire un TakeOwnership à distance).
Ca n'empêche pas de faire un TakeOwnership sécurisé. Evidemment, il ne faut pas donner PrivEK à l'utilisateur, mais seulement au propriétaire légal (celui qui va faire TakeOwnership à distance), et par un canal sécurisé. Principal inconvénient: en cas de revente du PC, le nouveau propriétaire ne peut pas faire confiance au TPM.
Donc même si un logiciel s'amusait à mettre des clefs dans une zone sealé/bindé, le owner pourrait toujours repasser la zone en plubique
Je crois plutôt que si Windows Media Player protège une clé de DRM avec TPM_SEAL, le TPM n'acceptera de la rendre en clair qu'à Windows Media Player, et si Windows Media Player n'a pas envie de la migrer, même le Owner ne pourra rien faire.
Les PrivAIK sont migrables/copiables commes les autres clefs.
Si PrivEK142 est chiffré avec PubEK, je n'ai qu'à lancer un challenge à mon TPM contenant PrivEK142 chiffrée pour obtenir la clef PrivEK142 en clair.
Le fait que EK soit challengeable ne veut pas dire que le TPM va déchiffrer n'importe quoi et renvoyer le résultat en clair. Par exemple, en réponse à TPM_TakeOwnership, le TPM prouve qu'il a bien déchiffré le secret du Owner (et donc qu'il connait PrivEK), mais sans renvoyer ce secret en clair. Voir le champ resAuth dans la spec TPM Part 3 Commands.
Or tu ne peux pas ne pas demander PCR[0], vu le principe même de l'extend des hash.
Ce n'est pas cohérent. Si ça fonctionnait comme tu le dis, l'argument passé à TPM_Quote n'aurait pas besoin d'être un bitmask. Ce serait simplement le numéro du dernier PCR à intégrer dans le hash.
Il me semble évident que le principe d'agrégation séquentielle (ce que tu appelles "extend") s'applique aux registres PCR indépendamment les uns des autres. A tout moment, PCR[0] donne l'historique du CRTM depuis le reset de la machine. PCR[4], c'est l'historique de tous les bootloaders qui ont été essayés. PCR[5] loggue la géométrie du disque et, en cas de multiboot, la partition qui a été sélectionnée. Et PCR[6] enregistre carrément toutes les mises en hibernation du PC.
PCR[0] - ce que j'appelais M(TPM) précédamment est totalement unique pour chaque TPM et change à chaque reset/TakeOwnership
Ce n'est pas ce que je lis dans TCG_PCSpecificSpecfication_v1_1.pdf:
"Only executable code is logged."
"Configuration data such as ESCD should not be measured as part of this PCR."
"Entities that MUST be measured: the CRTM's version identifier (...)"
Il n'est jamais question de logger EK. Ce serait même choquant, car ça fournirait un identifiant globalement unique même lorsque la lecture de PubEK est désactivée.
si tu essayes de demander PCR[1-3] par exemple (...) tu te fais jeter.
Bon, tu as essayé sur ta machine ? TPM_ReadPCR(1) et TPM_Quote(0x00001110) renvoient un code d'erreur ? Lequel ?
PCR[0-4] servent à valider la cohérence du TPM (ie prouver que le système n'a pas été compromis) donc ils sont prévisibles. Mais ce n'est pas pour autant qu'ils sortent de la puce.
Ah, alors si j'appelle TPM_ReadPCR(0) à TPM_ReadPCR(4), j'obtiens quoi ?
Et si j'appelle TPM_Quote(0x11111000), je n'obtiens pas un hash portant sur PCR[0-4] et eux seuls ?
Par ailleurs PCR[0-4] ne concernent pas seulement l'intégrité du TPM. En particulier, PCR[4] inclut le MBR (en prenant soin d'exclure la géométrie du disque, qui n'est pas assez prévisible).
Si je n'utilsie qu'un seul identifiant, un fournisseur de mêche avec le tiers certifiant pourrait remonter mes habitudes
Dans le scénario en entreprise, je n'ai pas besoin de tiers certifiant, tu l'as dit toi même. Les "fournisseurs" dont tu parles sont précisément les gens qui veulent faire du DRM et contrôler ce qu'il se passe dans le réseau de l'entreprise.
En plus pour contourner le DRM il suffirait de booter dans une autre config, avec un autre logiciel vi que PrivEK est TOUJOURS challengeable
Donc tu confirmes que si le TCG interdit qu'on puisse sortir PrivEK, c'est pour qu'on ne puisse pas contourner le DRM ?
Toutes les clefs challengeables de l'extérieur (ie extérieur du TPM) sont déplaceable et copiable à l'intérieur du TPM et vers d'autres TPM.
Je n'en suis pas convaincu. J'ai l'impression que TPM_Seal et/ou TPM_Bind et/ou TPM_CreateWrapKey permettent de créer des clés non migrables.
Sans parler des AIK qui sont challengeables et évidemment pas migrable.
D'ailleurs c'est une bonne chose qu'on puisse créer des clés qui ne sortiront jamais du TPM (sauf assistance du constructeur). Je serais ravi d'utiliser ça pour stocker la clé privée de mon serveur SSL. Si le chip crame, ce n'est pas pire que quand mon certificat expire.
Le constructeur est obligé de me fournir 10000 blobs uniques
Non, je proposais bien qu'il y ait 10000 clés EK partagées par tous les TPM du monde. En effet ça fait un peu désordre, mais ce n'est pas si dramatique que ça, sauf pour le DRM. Le DAA zero-knowledge est encore mieux, évidemment.
je pourrais par exemple garder le blob 127 pour mon tpm et challenger le blob 142 pour récupérer la clef PrivEK142 en clair et l'utiliser dans un émulateur
Non, le constructeur te fournirait PrivEK142 chiffrée avec ton PubEK certifié, donc seul ton TPM pourrait l'avoir en clair.
C'est l'architecture me de la puce qui empèche de renvoyer hash(OS_LOAD)
Bien sûr, ça ne servirait à rien de savoir que le PC fait tourner Windows, si on ne sait pas ce que le BIOS et tous les inits ont fait avant.
Mais il y a bien plusieurs niveaux de hash qui sont de plus en plus "uniques". Et PCR[0] à PCR[4] semblent conçus pour être identiques sur deux PC d'un même modèle.
L'EK est unique, normalement la signature du secret ownership aussi.
De même que les numéros de série du BIOS ne sont pas incorporés dans tous les PCR, j'imagine qu'il y a des PCR qui caractérisent le modèle et la version du TPM mais pas son EK unique. Le tiers inquisiteur peut demander les PCR appropriés selon qu'il veut faire du DRM ou seulement du boot sécurisé.
Pourquoi créer des certificats supplémentaires si il suffisait de demander le hash du CRTM ?
Ben sans certification de la plate-forme par EK, le tiers inquisiteur n'a aucune raison de faire confiance au CRTM.
Seulement madame Michu n'a pas forcément deux ordinateurs sous TPM à la maison
Il faut obligatoirement deux TPM pour faire un backup ? Qu'est ce qui m'empêcherait de demander un backup vers un TPM émulé ?
(sauf pour les clés non-migrables et CMK, évidemment).
Surtout que cette procédure et inautomatisable.
Pourquoi ? Ce n'est pas télécommandable par le Owner ?
Soyons sérieux, Intel rien que pour les bridges CPU possède plusieurs dizaines de chipsets à l'heure actuelle
Certes, mais les combinaisons effectivement mises sur le marché, c'est à dire les modèles de PC, ne couvrent pas toutes les combinaisons possibles des composants.
Allez, une autre solution pour faire du DRM sans base de donnée centrale, et même si les hashes n'étaient jamais les même d'une machine à l'autre: Il suffit qu'à la sortie de l'usine, le constructeur boote le PC, demande le hash, génère un certificat qui dit "je garantis que le hash 0x12345678 correspond au boot d'un PC TCPA avec tel bootloader", et livre ce certificat avec le PC. Ca revient à implémenter la base de façon distribuée. Mais il est vrai qu'il n'y a rien de tel dans les specs, à ma connaissance.
Dans ton message précédent, au sujet de la certification, tu parlais à la fois de la certification de la signature EK du constructeur, et de l'attestation ("Si tu n'as pas besoin de certifier la véracité de ton identité au reste du monde, créé un clef dans le PCR public.").
Dans le premier cas, c'est le constructeur qui prouve son identité. Le tiers de confiance est une bête autorité de certification, c'est classique.
Dans le second cas, c'est l'utilisateur qui prouve que son PC est "digne de confiance". Les whitepapers du TCG disent explicitement que le tiers de confiance jour un rôle un peu nouveau ("privacy CA").
Si j'ai généré l'AIK moi même (ce qui est le cas en réseau d'entreprise), il me suffit de noter la clef public dans un coin moi même pour avoir un degré de certification égal à celui que j'aurais via EK.
En effet TPM_MakeIdentity a l'air indépendant de TPM_ActivateIdentity. Ca me plait. Mais techniquement, pour que l'administrateur puisse faire tout ça à distance de façon sûre, on a besoin de EK (rien que pour le TPM_TakeOwnership initial).
Le problème étant qu'il faut que je me fasse confiance à moi même
Pour ça il suffit que l'entreprise ait un service "privacy CA" de confiance, et là on lierait les AIK à EK. Et ça ne me choquerait pas: ça a clairement des avantages pour la sécurité. Ce qui me choque, c'est que le TCG ajoute des fonctions et impose des restrictions qui trahissent l'intention de faire du DRM. Par exemple:
- Pourquoi prévoir un mécanisme d'attestation qui permet de rassurer non seulement le Owner, mais aussi un tiers inquisiteur quelconque ?
- Pourquoi se donner la peine d'anonymiser les AIK à l'aide d'une "privacy CA", si ce n'est pour faire du DRM sans violer les lois européennes sur la vie privée ? Pour les applications personnelles et en entreprise, l'anonymisation des AIK ne sert à rien.
- Pourquoi empêcher le Owner de connaitre le PrivEK de son TPM ? (réponse: ça lui permettrait d'émuler le TPM en logiciel et de contourner le DRM). OK, ça complique un peu le changement de Owner (le constructeur fournirait un nouveau EK certifié, ça peut se faire à distance).
- De même, pourquoi empêcher le Owner de connaitre la partie privée de SRK ? (réponse: en gros, ça lui permettrait d'extraire ou de migrer des clés nécessaires pour déchiffrer des contenus DRM).
Si il faut un EK valide pour accéder un nouvel EK alors on peut toujours se servir des méccanismes de tracabilité
Je donne mon PubEK, le constructeur me renvoie 10000 blobs contenant chacun un des PrivEK partagés chiffré avec mon PubEK, j'en choisis un et je l'envoie à mon TPM. Ca règle le problème de traçabilité.
Le vrai inconvénient est qu'il faut faire compromis entre le niveau d'anonymat et les dégâts en cas de compromission physique d'un TPM.
et j'ai essayé de la créer moi même. Ca fait deux ans que je m'acharne
Ah ben voilà, ton boulot chez Vivendi, c'est réussir à implémenter du DRM sur TCPA !!! :-)
ce qui signifie qu il est illegale en france de realiser un module cryptographique hardware vraiment secure ?
Non, seulement de refuser de déchiffrer. Tu peux probablement répondre à la sommation des autorités en déchiffrant à l'aide de ton module, sans révéler la clé elle-même.
Evidemment, si tu as la même coupe de cheveux qu'un certain terroriste londonien, et que tu racontes que ton module vient de tomber en panne, ça va faire louche.
De même que je ne susi pas sur qu'il n'y ait pas un tag sur ma carte réseau ou sur mon CPU.
Ben oui, c'est pour ça que les gens stockent leurs clés ailleurs (sur une carte à puce, par exemple). Ceci dit la conception et la fabrication des PC TCPA sera probablement soumise à des procédures de qualité et d'audit sévères, donc je leur ferai davantage confiance qu'à mon PC actuel.
Non, la certification requiert un tiers de confiance
Tu mélanges deux choses:
- L'autorité de certification (exemple: Verisign) qui me permet de savoir qui a signé le certificat d'endossement EK de mon TPM. J'ai probablement déjà son certificat racine, et je n'ai pas besoin d'interagir avec elle.
- Le tiers de confiance auquel je dois faire appel à chaque fois que je veux créer un AIK. Dans mon scénario de boot sécurisé en entreprise, l'administrateur réseau peut très bien être son propre tiers de confiance.
Achéte une puce TCPA, vérifie la, désactive l'EK, créé tes propres clef dans le PCR public et voilà.
OK, sauf que je ne suis pas certain que mes clés permettent de faire la même chose que EK+AIK dans le scénario du réseau d'entreprise.
(...) Je ne vois pas comment on peut faire du DRM avec çà.
Bon, on tourne en rond. Pour avancer, il suffirait que l'EFF ou la CNIL implémente une démo d'infrastructure DRM bien méchante à base de TCPA,
juste pour montrer à tout le monde que c'est possible et que ça peut faire mal.
La solution offerte de désactiver l'EK me parait nettement plus simple et raisonnable.
Encore une fois, il vaudrait mieux pouvoir désactiver EK (sinon TPM_ForceClear suffit à la réactiver), pour que personne ne soit tenté d'en abuser plus tard.
Autre alternative raisonnable: permettre à l'utilisateur de remplacer l'EK d'origine par une EK prise au hasard dans un pool partagé. Ca aurait les mêmes avantages et inconvénients que le mécanisme d'attestation anonyme (DAA).
Attention. Il est très important de se souvenir que la puce TPM ne renvoit pas les hashes individuels, mais le résultat d'une série de hashes imbriqués.
Pourtant TPM_Quote reçoit en argument la liste des PCR à intégrer dans le hash, sous la forme d'un bitmask. Qu'est ce qui emêche le tiers inquisiteur de demander 8 attestations contenant chacune un seul PCR ?
Même si TPM_Quote n'acceptait de signer que des hashes intègrant plusieurs PCR, un système de DRM pourrait en parallèle lire les PCR individuels avec TPM_Read, les hasher lui-même, et comparer son résultat avec le hash signé. Si la fonction de hachage est bien choisie, ça suffit à certifier chaque PCR.
(ie M(TPM) est différent pour chaque TPM - encore heureux).
Pourquoi M(TPM) serait-il unique ? Où vois-tu ça dans la spec ?
chaque panne matérielle pourrait entrainner la perte de l'ensemble du contenu de la puce TPM.
Ben il suffit d'utiliser régulièrement la procédure de backup/migration du TPM, non ?
Et puis tu connais beaucoup de SAV qui s'amusent à désouder des chips sur les cartes mère ? Et qui de plus prendraient la peine de mettre exactement la même version de firmware en remplacement pour que le TPM ne s'aperçoive de rien ?
Ca fait 6.4x10^33 données possibles.
Toujours sous ton hypothèse douteuse que deux machines n'ont aucune chance de renvoyer le même hash.
De plus, j'imagine que les constructeurs auront beaucoup de paperasse à remplir pour avoir le droit de certifier des composants et des PC complets. Donc il est clair que les utilisateurs n'auront plus le choix entre 36 versions de BIOS comme aujourd'hui. Au mieux il y aura 3 versions certifiées et 33 versions "beta". Idem pour les drivers Windows certifiés par Microsoft.
Qu'est ce que vous voulez que ça me fasse? C'est pas le fait qu'on regarde ce que je fais qui m'empeche de faire ce qui me plait, non?
Cool. On peut venir mettre des caméras de surveillance chez toi, alors ?
Remarque, si tu n'as rien à cacher ni à protéger, pas même un numéro de carte de crédit, ou des infos qui pourraient intéresser ton assureur ou ton employeur, ou le plan stratégique du parti politique que tu es en train de fonder, c'est que tu dois être le type le plus inintéressant du monde, et je plains le vigile à qui on va confier ton dossier :-)
Sur deux portables T42 identiques je n'ai jamais réussi à leur faire cracher deux hashes similaires.Et j'ai vraiment essayé.
Pourtant la spec TCG PC Specific Implementation Specification fait tout ce qu'il faut pour que certains hashes soient prédictibles. Par exemple, elle exige que les numéros de série et autres identifiants uniques ne soient pas hashés, ainsi que les portions du MBR spécifiques à la géométrie du disque. Ces précautions n'auraient aucune utilité si l'objectif était seulement de contrôler que le PC boote "dans la même config que la dernière fois". Etrange, non ?
Et quels registres PCR as-tu comparés entre tes deux machines ? J'ai l'impression que seuls PCR[0]-PCR[4] sont conçus pour être bien déterministes.
Autant te dire que pour vérifier un hash et en déduire ce qu'il y a vraiment dérrière il faut y aller....
Je suis sûr que les constructeurs fourniront la liste de toutes les combinaisons homologuées de composants mis sur le marché, si Microsoft demande gentiment.
IBM n'ayant pas mon EK je ne pourrais jamais être certifié....
Qui te dit qu'IBM ou le fabricant du TPM n'ont pas une copie de PubEK sous la main, pour le cas où tu demanderais un certificat ?
Voire de PrivEK (mais dans ce cas, un flag doit en principe t'indiquer que EK a été injectée et pas générée par le TPM lui-même).
En sachant que l'on ne peut pas se servir de a partie publique de l'EK pour faire de l'encryption ?
On se sert de PubEK pour faire du chiffrement, par exemple pour insérer le secret partagé du Owner à distance.
On peut parfaitement désactiver la clef d'endossement et ne jamais s'en servir.
Oui, mais dans ce cas le TPM n'apporte pas grand chose par rapport à une carte à puce associée à un BIOS non flashable. Moi je préfère qu'il y ait un mécanisme de certification qui me garantit que le TPM que j'ai acheté n'est pas contrefait, que son architecture a bien été évaluée Critères Communs EALx par un labo indépendant du fabricant, etc...
Le problème est qu'on empêche le client final de révoquer ce mécanisme de certification ou d'en prendre le contrôle et la responsabilité, alors que ce serait légitime par exemple pour un usage en entreprise. Par conséquent, un jour, 99,9% des PC auront un TPM avec une EK indélébile et un certificat utilisable pour faire du DRM, et à ce moment le grand public n'aura aucune excuse pour empêcher Microsoft, Intel et Sony de déployer Palladium au dessus, puisque ce sera indolore et gratuit (et que ça permettra de lutter contre le terrorisme, blah blah).
Plus précisément, une partie des mécanismes nécessaires (TPM_RevokeTrust et TPM_GenerateRevocableEK) ont été ajoutés à la spec 1.2, mais les release notes expliquent qu'il ne faut pas compter dessus dans les TPM destinés au grand public. Il est encore temps d'exiger que cette politique change.
L'enjeu n'est pas de pouvoir désactiver EK temporairement, ni le TPM entier.
L'enjeu est que les constructeurs de PC nous vendent exclusivement des TPM avec une EK révocable et remplaçable, même si la décision par l'utilisateur de révoquer l'EK du constructeur implique que le TPM devient inutilisable pour certaines applications.
La certification TCPA simple suffit largement dans l'ensemble des cas, et elle n'implique pas du tout l'EK.
Ce que tu appelles certification simple, c'est le mécanisme à base de protocole zéro-knowledge (DAA) ajouté dans la version 1.2 ?
En tout cas tu as bien un EK unique, lisible par l'OS (avec autorisation de l'Owner si tu as pris la précaution d'appeler TPM_DisablePubekRead), et que tu n'es probablement pas libre de modifier. Il ne manque vraiment pas grand chose pour que tu puisses entrer dans le monde merveilleux du DRM :-)
Si jamais le "niveau" est stocké dans le certificat mais pas dans le TPM lui-même, il suffit que le constructeur décide de te délivrer un nouveau certificat. "C'est gratuit et c'est plus sûr, pourquoi refuser ?"
[^] # Re: Les TPM sont dangeureux, remote attestation
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 2.
Des références ? Je vois bien un doc qui dit que PCR[7] est "manufacturer specific" et que "user applications must not use this PCR for sealing or attestation" - pour la simple raison qu'il n'est pas digne de confiance; est-ce à celà que tu fais allusion ?
Je ne vois pas comment on peut faire du Remote Attestation sans révéler des valeurs ou hashes de PCR[0..6] signés.
celà implique quand même de garder au chaud un exemplaire de chaque configuration avec ces N Sha-1 de PCR possibles
J'ai déjà expliqué comment on pourrait implémenter cette base de données de façon distribuée: il suffit que chaque constructeur de PC, en sortie d'usine, lise les PCR, signe un document qui dit "je garantis que la configuration définie par les valeurs de PCR XX,YY,ZZ est une plate-forme TCPA digne de confiance", et enregistre ce document sur le disque dur ou dans le BIOS.
AC
[^] # Re: Les TPM sont dangeureux, remote attestation
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 1.
Avec une carte à puce, ça me semble difficile.
Avec un TPM - je te renvoie à notre discussion de l'été dernier. Tu semblais avoir entrevu le chemin en question dans ton dernier post: http://linuxfr.org/comments/615018.html#615018
AC
[^] # Re: Les TPM sont dangeureux, remote attestation
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 1.
Il y a déjà des banques qui imposent une carte à puce pour certains clients et certaines opérations: http://entreprises.bnpparibas.net/francais/html/lecteur01.ht(...) . Si on leur dit qu'il y a l'équivalent d'une carte à puce dans tous les PC du monde, ou si le gouvernement annonce que TCPA remplit les critères techniques de la LCEN pour faire des signatures numériques non répudiables, elles vont sauter sur l'occasion.
AC
[^] # Re: Les TPM sont dangeureux, remote attestation
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à -1.
Le logiciel libre n'exclut pas TCPA. Les constructeurs de cartes vidéo et WiFi pourraient fournir des drivers Linux sous forme de modules binaires chiffrés qui ne tourneront que sur le noyau version X.Y.Z signé par RedHat (avec PTRACE et /dev/kmem désactivés). Tout ça pour satisfaire des obligations légales (DMCA pour les drivers vidéo, certification FCC pour les drivers WiFi).
AC
[^] # Re: Les TPM sont dangeureux, remote attestation
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 5.
Exonérer sa responsabilité pour les virus envoyés par ses clients, pour les MP3 qu'ils téléchargent, etc. Historiquement les FAI et opérateurs télécom n'étaient pas juridiquement responsables des actions de leurs clients, mais ce principe est régulièrement remis en question par des lois telles que LCEN et DADVSI.
Et éviter que ses serveurs SMTP soient blacklistés par le reste du monde à cause des botnets qui envoient du spam depuis son réseau.
Lutter contre la fraude.
Recevoir des bons de commande signés numériquement qui engagent l'acheteur comme une signature manuscrite (c'est dans la LCEN).
Et surtout, avoir accès aux nouvelles infrastructures de paiement sécurisé. Si le client est TCPA, il clique une fois "acceptez vous de payer 1 centime à chaque fois que vous consultez un article sur linuxfr.org ?" et ensuite il paie sans s'en apercevoir avec son porte-monnaie électronique. Si le client n'est pas TCPA, on lui demande de sortir sa carte bleue à chaque fois, et il n'achète pas, parce que ça le gonfle.
AC
[^] # Re: Les TPM sont dangeureux mais peuvent être utiles
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 1.
Si on voulait juste un keystore hardware, une clé USB suffirait. Le TPM est beaucoup plus que ça, parce qu'il est soudé à la carte mère, de la même façon qu'on met des tags antivol inamovibles sur les vêtements dans les magasins.
Idéalement, du point de vue de la sécurité, on voudrait faire tourner les OS et les média players dans un environnement sécurisé, du genre carte à puce haut de gamme qui s'auto-détruit quand on la chatouille un peu trop. Mais ça couterait trop cher, d'où TCPA qui est un compromis raisonnable entre sécurité et coût. Le TPM sert essentiellement à garantir à Sony, à Microsoft, à ton administrateur réseau, à ton ISP, et accessoirement à toi, que ton PC est digne de leur confiance, à moins qu'il soit passé entre les mains d'un pro du dessoudage de composants BGA sur circuits imprimés multi-couches.
AC
[^] # Re: Validité du concept ?
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 2.
Dans http://www.microsoft.com/windowsvista/privacy/privacy_ctp.ms(...) je lis seulement "The endorsement key may be created and stored in the TPM by your computer's manufacturer, or you may choose to have Windows create it as part of TPM initialization". D'après ce que j'ai lu ailleurs, il faut comprendre ça comme: Soit EK est déjà installée par le constructeur, soit elle ne l'est pas; dans le second cas, on peut choisir de créer EK soit avec Windows, soit avec un autre outil.
Ce qui n'est pas installé en usine, ce sont les clés AIK (mais elles sont liées à EK lorsqu'elles sont créées).
je trouve ça bizarre que tu dises que l'EK sera d'office initialisée par Sony/Microsoft
Je n'ai pas dit ça. J'ai écrit "initialisée en usine". Donc par le constructeur ou par quelqu'un à qui il fait confiance. Et c'est normal puisque le constructeur engage sa responsabilité vis à vis de toi et de Sony/Microsoft en signant (en gros) "je déclare que la plate-forme qui connait la clé PrivEK associée à la clé PubEK XXXXXXXXX protègera vos données conformément à la norme TCPA".
ça m'arrangerai que tu me dises si j'ai pas trop dit de conneries dans mon article
Je n'ai rien vu de choquant, c'est une bonne introduction pas trop technique. Bravo pour ton initiative de recenser les produits équipés de TPM.
Le déploiement va continuer: "U.S. Army requires trusted computing" http://www.securityfocus.com/brief/265
AC
[^] # Re: Les TPM sont dangeureux mais peuvent être utiles
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 3.
Ceci nous garantit que Microsoft ne peut pas forcer Dell à vendre des PC qui rechigneraient à booter Linux (comme la Xbox). Mais les restrictions que tu cites n'empêchent pas de faire du DRM et plein d'autres choses excitantes.
Le TPM est comparable à une boite noire posée à l'arrière d'un port série. [...] il ne peut qu'interdire l'accès aux clefs qu'il contient.
Ouais, mais si Windows a chiffré tous mes documents avec des clés stockées dans le TPM, ça me fait une belle jambe de savoir que je peux le débrancher...
AC
[^] # Re: Validité du concept ?
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 2.
En effet le document de Microsoft que tu cites suggère que Windows est capable d'initialiser l'EK, mais ça ne se passera pas comme ça en pratique. Les release notes (https://www.trustedcomputinggroup.org/groups/tpm/TPM_1_2_Cha(...) , paragraphe Clear Endorsement Key) précisent que la possibilité de changer EK sera réservée aux customers with special security needs (pour les militaires, quoi).
Les TPM grand publics auront une EK initialisée en usine et indélébile. C'est grace à cet identifiant unique que Microsoft et Sony pourront déterminer que ton PC est digne de leur confiance, et que leurs licences logicielles et leurs contenus DRM pourront être attachés à ce PC et à lui seul. Et si on a de la chance, le constructeur ne conservera pas une copie des EK pour la NSA.
AC
[^] # Re: Les TPM sont dangeureux mais peuvent être utiles
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 5.
Ouais, on se demande encore pourquoi les américains ont racheté Gemplus... http://www.infoguerre.com/article.php?op=Print&sid=721
Pourquoi la NSA [...] aurait-elle plus en ligne de mire les TPM que les autres systèmes
Parce que le TPM est conçu comme la clé de voute d'une infrastructure de confiance mondiale. Il est probable qu'un jour on ne pourra plus se connecter à Internet sans s'authentifier avec un TPM (ou que seuls les terroristes refuseront de s'authentifier). Pour faire passer la pilule il suffira d'organiser un bon gros Pearl Harbour informatique avec un virus Windows bien destructeur, puis de décréter qu'Internet est en danger mais qu'heureusement 99.9% des PC sont équipés d'un TPM et qu'il suffit d'activer la fonction Trusted Network Connect pour sauver la démocratie.
Pas seulement la clé de voute d'ailleurs, mais aussi la barrière de péage. A terme les maisons de disque européennes ne pourront plus publier de la musique sous DRM fiable sans verser des royalties à des consortiums américains.
AC
[^] # Re: Les TPM sont dangeureux mais peuvent être utiles
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 4.
Pourquoi la NSA ? Il suffit que la justice demande gentiment à un constructeur de l'aider à extraire les clés d'un TPM.
Le tout, sans la moindre fuite ?
Aucun risque puisque la backdoor est une fonctionnalité normalisée. "Mais monsieur on vous l'avait bien dit qu'on pouvait récupérer vos clés, c'est écrit dans le chapitre 15 de la spécification."
C'est un peu gros
Ce n'est rien par rapport au coup des imprimantes laser américaines qui insèrent leur numéro de série en watermark dans nos documents depuis des années: http://www.eff.org/Privacy/printers/index.php
AC
[^] # Re: Les TPM sont dangeureux mais peuvent être utiles
Posté par a_caspis . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 3.
La backdoor est prévue dans les specs, en option: voir la section 15 ("Maintenance") du document "TPM Main Part 1 Design Principle". Le constructeur peut extraire le contenu du TPM, y compris les clés marquées "non migrables" par le propriétaire.
En principe il faut le mot de passe du propriétaire, mais ça ne doit pas être trop dur à sniffer avec la collaboration du fournisseur du BIOS ou de l'OS. Au pire le constructeur peut désactiver les protections en injectant un firmware troué (section 15.1 "Field Upgrade").
AC
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Oui mais là on ne parlait plus du certificat EK, on parlait de l'attestation semi-anonyme avec les AIK. Tu confirmes que la certification des AIK par le "privacy CA" ne sert à rien en entreprise ? Et qu'elle n'est donc utile que pour faire du DRM ?
On ne peut pas sortir PrivEK parceque sinon ca ne certifirait plus rien et donc les gens qui ont besoin de PrivEK ne pourraient plus s'en servir (Par exemple pour faire un TakeOwnership à distance).
Ca n'empêche pas de faire un TakeOwnership sécurisé. Evidemment, il ne faut pas donner PrivEK à l'utilisateur, mais seulement au propriétaire légal (celui qui va faire TakeOwnership à distance), et par un canal sécurisé. Principal inconvénient: en cas de revente du PC, le nouveau propriétaire ne peut pas faire confiance au TPM.
Donc même si un logiciel s'amusait à mettre des clefs dans une zone sealé/bindé, le owner pourrait toujours repasser la zone en plubique
Je crois plutôt que si Windows Media Player protège une clé de DRM avec TPM_SEAL, le TPM n'acceptera de la rendre en clair qu'à Windows Media Player, et si Windows Media Player n'a pas envie de la migrer, même le Owner ne pourra rien faire.
Les PrivAIK sont migrables/copiables commes les autres clefs.
Non. La définition dit "AIK: (...) an asymmetric key, the private portion of which is non-migratable and protected by the TPM"
(http://www.trustedcomputinggroup.org/downloads/TCG_Glossary.pdf(...) page 4).
Si PrivEK142 est chiffré avec PubEK, je n'ai qu'à lancer un challenge à mon TPM contenant PrivEK142 chiffrée pour obtenir la clef PrivEK142 en clair.
Le fait que EK soit challengeable ne veut pas dire que le TPM va déchiffrer n'importe quoi et renvoyer le résultat en clair. Par exemple, en réponse à TPM_TakeOwnership, le TPM prouve qu'il a bien déchiffré le secret du Owner (et donc qu'il connait PrivEK), mais sans renvoyer ce secret en clair. Voir le champ resAuth dans la spec TPM Part 3 Commands.
AC
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Ce n'est pas cohérent. Si ça fonctionnait comme tu le dis, l'argument passé à TPM_Quote n'aurait pas besoin d'être un bitmask. Ce serait simplement le numéro du dernier PCR à intégrer dans le hash.
Il me semble évident que le principe d'agrégation séquentielle (ce que tu appelles "extend") s'applique aux registres PCR indépendamment les uns des autres. A tout moment, PCR[0] donne l'historique du CRTM depuis le reset de la machine. PCR[4], c'est l'historique de tous les bootloaders qui ont été essayés. PCR[5] loggue la géométrie du disque et, en cas de multiboot, la partition qui a été sélectionnée. Et PCR[6] enregistre carrément toutes les mises en hibernation du PC.
PCR[0] - ce que j'appelais M(TPM) précédamment est totalement unique pour chaque TPM et change à chaque reset/TakeOwnership
Ce n'est pas ce que je lis dans TCG_PCSpecificSpecfication_v1_1.pdf:
"Only executable code is logged."
"Configuration data such as ESCD should not be measured as part of this PCR."
"Entities that MUST be measured: the CRTM's version identifier (...)"
Il n'est jamais question de logger EK. Ce serait même choquant, car ça fournirait un identifiant globalement unique même lorsque la lecture de PubEK est désactivée.
si tu essayes de demander PCR[1-3] par exemple (...) tu te fais jeter.
Bon, tu as essayé sur ta machine ? TPM_ReadPCR(1) et TPM_Quote(0x00001110) renvoient un code d'erreur ? Lequel ?
AC
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Ah, alors si j'appelle TPM_ReadPCR(0) à TPM_ReadPCR(4), j'obtiens quoi ?
Et si j'appelle TPM_Quote(0x11111000), je n'obtiens pas un hash portant sur PCR[0-4] et eux seuls ?
Par ailleurs PCR[0-4] ne concernent pas seulement l'intégrité du TPM. En particulier, PCR[4] inclut le MBR (en prenant soin d'exclure la géométrie du disque, qui n'est pas assez prévisible).
AC
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Dans le scénario en entreprise, je n'ai pas besoin de tiers certifiant, tu l'as dit toi même. Les "fournisseurs" dont tu parles sont précisément les gens qui veulent faire du DRM et contrôler ce qu'il se passe dans le réseau de l'entreprise.
En plus pour contourner le DRM il suffirait de booter dans une autre config, avec un autre logiciel vi que PrivEK est TOUJOURS challengeable
Donc tu confirmes que si le TCG interdit qu'on puisse sortir PrivEK, c'est pour qu'on ne puisse pas contourner le DRM ?
Toutes les clefs challengeables de l'extérieur (ie extérieur du TPM) sont déplaceable et copiable à l'intérieur du TPM et vers d'autres TPM.
Je n'en suis pas convaincu. J'ai l'impression que TPM_Seal et/ou TPM_Bind et/ou TPM_CreateWrapKey permettent de créer des clés non migrables.
Sans parler des AIK qui sont challengeables et évidemment pas migrable.
D'ailleurs c'est une bonne chose qu'on puisse créer des clés qui ne sortiront jamais du TPM (sauf assistance du constructeur). Je serais ravi d'utiliser ça pour stocker la clé privée de mon serveur SSL. Si le chip crame, ce n'est pas pire que quand mon certificat expire.
Le constructeur est obligé de me fournir 10000 blobs uniques
Non, je proposais bien qu'il y ait 10000 clés EK partagées par tous les TPM du monde. En effet ça fait un peu désordre, mais ce n'est pas si dramatique que ça, sauf pour le DRM. Le DAA zero-knowledge est encore mieux, évidemment.
je pourrais par exemple garder le blob 127 pour mon tpm et challenger le blob 142 pour récupérer la clef PrivEK142 en clair et l'utiliser dans un émulateur
Non, le constructeur te fournirait PrivEK142 chiffrée avec ton PubEK certifié, donc seul ton TPM pourrait l'avoir en clair.
AC
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Bien sûr, ça ne servirait à rien de savoir que le PC fait tourner Windows, si on ne sait pas ce que le BIOS et tous les inits ont fait avant.
Mais il y a bien plusieurs niveaux de hash qui sont de plus en plus "uniques". Et PCR[0] à PCR[4] semblent conçus pour être identiques sur deux PC d'un même modèle.
L'EK est unique, normalement la signature du secret ownership aussi.
De même que les numéros de série du BIOS ne sont pas incorporés dans tous les PCR, j'imagine qu'il y a des PCR qui caractérisent le modèle et la version du TPM mais pas son EK unique. Le tiers inquisiteur peut demander les PCR appropriés selon qu'il veut faire du DRM ou seulement du boot sécurisé.
Pourquoi créer des certificats supplémentaires si il suffisait de demander le hash du CRTM ?
Ben sans certification de la plate-forme par EK, le tiers inquisiteur n'a aucune raison de faire confiance au CRTM.
Seulement madame Michu n'a pas forcément deux ordinateurs sous TPM à la maison
Il faut obligatoirement deux TPM pour faire un backup ? Qu'est ce qui m'empêcherait de demander un backup vers un TPM émulé ?
(sauf pour les clés non-migrables et CMK, évidemment).
Surtout que cette procédure et inautomatisable.
Pourquoi ? Ce n'est pas télécommandable par le Owner ?
Soyons sérieux, Intel rien que pour les bridges CPU possède plusieurs dizaines de chipsets à l'heure actuelle
Certes, mais les combinaisons effectivement mises sur le marché, c'est à dire les modèles de PC, ne couvrent pas toutes les combinaisons possibles des composants.
Allez, une autre solution pour faire du DRM sans base de donnée centrale, et même si les hashes n'étaient jamais les même d'une machine à l'autre: Il suffit qu'à la sortie de l'usine, le constructeur boote le PC, demande le hash, génère un certificat qui dit "je garantis que le hash 0x12345678 correspond au boot d'un PC TCPA avec tel bootloader", et livre ce certificat avec le PC. Ca revient à implémenter la base de façon distribuée. Mais il est vrai qu'il n'y a rien de tel dans les specs, à ma connaissance.
AC
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Dans ton message précédent, au sujet de la certification, tu parlais à la fois de la certification de la signature EK du constructeur, et de l'attestation ("Si tu n'as pas besoin de certifier la véracité de ton identité au reste du monde, créé un clef dans le PCR public.").
Dans le premier cas, c'est le constructeur qui prouve son identité. Le tiers de confiance est une bête autorité de certification, c'est classique.
Dans le second cas, c'est l'utilisateur qui prouve que son PC est "digne de confiance". Les whitepapers du TCG disent explicitement que le tiers de confiance jour un rôle un peu nouveau ("privacy CA").
Si j'ai généré l'AIK moi même (ce qui est le cas en réseau d'entreprise), il me suffit de noter la clef public dans un coin moi même pour avoir un degré de certification égal à celui que j'aurais via EK.
En effet TPM_MakeIdentity a l'air indépendant de TPM_ActivateIdentity. Ca me plait. Mais techniquement, pour que l'administrateur puisse faire tout ça à distance de façon sûre, on a besoin de EK (rien que pour le TPM_TakeOwnership initial).
Le problème étant qu'il faut que je me fasse confiance à moi même
Pour ça il suffit que l'entreprise ait un service "privacy CA" de confiance, et là on lierait les AIK à EK. Et ça ne me choquerait pas: ça a clairement des avantages pour la sécurité. Ce qui me choque, c'est que le TCG ajoute des fonctions et impose des restrictions qui trahissent l'intention de faire du DRM. Par exemple:
- Pourquoi prévoir un mécanisme d'attestation qui permet de rassurer non seulement le Owner, mais aussi un tiers inquisiteur quelconque ?
- Pourquoi se donner la peine d'anonymiser les AIK à l'aide d'une "privacy CA", si ce n'est pour faire du DRM sans violer les lois européennes sur la vie privée ? Pour les applications personnelles et en entreprise, l'anonymisation des AIK ne sert à rien.
- Pourquoi empêcher le Owner de connaitre le PrivEK de son TPM ? (réponse: ça lui permettrait d'émuler le TPM en logiciel et de contourner le DRM). OK, ça complique un peu le changement de Owner (le constructeur fournirait un nouveau EK certifié, ça peut se faire à distance).
- De même, pourquoi empêcher le Owner de connaitre la partie privée de SRK ? (réponse: en gros, ça lui permettrait d'extraire ou de migrer des clés nécessaires pour déchiffrer des contenus DRM).
Si il faut un EK valide pour accéder un nouvel EK alors on peut toujours se servir des méccanismes de tracabilité
Je donne mon PubEK, le constructeur me renvoie 10000 blobs contenant chacun un des PrivEK partagés chiffré avec mon PubEK, j'en choisis un et je l'envoie à mon TPM. Ca règle le problème de traçabilité.
Le vrai inconvénient est qu'il faut faire compromis entre le niveau d'anonymat et les dégâts en cas de compromission physique d'un TPM.
et j'ai essayé de la créer moi même. Ca fait deux ans que je m'acharne
Ah ben voilà, ton boulot chez Vivendi, c'est réussir à implémenter du DRM sur TCPA !!! :-)
AC
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 3.
Non, seulement de refuser de déchiffrer. Tu peux probablement répondre à la sommation des autorités en déchiffrant à l'aide de ton module, sans révéler la clé elle-même.
Evidemment, si tu as la même coupe de cheveux qu'un certain terroriste londonien, et que tu racontes que ton module vient de tomber en panne, ça va faire louche.
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Ben oui, c'est pour ça que les gens stockent leurs clés ailleurs (sur une carte à puce, par exemple). Ceci dit la conception et la fabrication des PC TCPA sera probablement soumise à des procédures de qualité et d'audit sévères, donc je leur ferai davantage confiance qu'à mon PC actuel.
Non, la certification requiert un tiers de confiance
Tu mélanges deux choses:
- L'autorité de certification (exemple: Verisign) qui me permet de savoir qui a signé le certificat d'endossement EK de mon TPM. J'ai probablement déjà son certificat racine, et je n'ai pas besoin d'interagir avec elle.
- Le tiers de confiance auquel je dois faire appel à chaque fois que je veux créer un AIK. Dans mon scénario de boot sécurisé en entreprise, l'administrateur réseau peut très bien être son propre tiers de confiance.
Achéte une puce TCPA, vérifie la, désactive l'EK, créé tes propres clef dans le PCR public et voilà.
OK, sauf que je ne suis pas certain que mes clés permettent de faire la même chose que EK+AIK dans le scénario du réseau d'entreprise.
(...) Je ne vois pas comment on peut faire du DRM avec çà.
Bon, on tourne en rond. Pour avancer, il suffirait que l'EFF ou la CNIL implémente une démo d'infrastructure DRM bien méchante à base de TCPA,
juste pour montrer à tout le monde que c'est possible et que ça peut faire mal.
La solution offerte de désactiver l'EK me parait nettement plus simple et raisonnable.
Encore une fois, il vaudrait mieux pouvoir désactiver EK (sinon TPM_ForceClear suffit à la réactiver), pour que personne ne soit tenté d'en abuser plus tard.
Autre alternative raisonnable: permettre à l'utilisateur de remplacer l'EK d'origine par une EK prise au hasard dans un pool partagé. Ca aurait les mêmes avantages et inconvénients que le mécanisme d'attestation anonyme (DAA).
AC
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Pourtant TPM_Quote reçoit en argument la liste des PCR à intégrer dans le hash, sous la forme d'un bitmask. Qu'est ce qui emêche le tiers inquisiteur de demander 8 attestations contenant chacune un seul PCR ?
Même si TPM_Quote n'acceptait de signer que des hashes intègrant plusieurs PCR, un système de DRM pourrait en parallèle lire les PCR individuels avec TPM_Read, les hasher lui-même, et comparer son résultat avec le hash signé. Si la fonction de hachage est bien choisie, ça suffit à certifier chaque PCR.
(ie M(TPM) est différent pour chaque TPM - encore heureux).
Pourquoi M(TPM) serait-il unique ? Où vois-tu ça dans la spec ?
chaque panne matérielle pourrait entrainner la perte de l'ensemble du contenu de la puce TPM.
Ben il suffit d'utiliser régulièrement la procédure de backup/migration du TPM, non ?
Et puis tu connais beaucoup de SAV qui s'amusent à désouder des chips sur les cartes mère ? Et qui de plus prendraient la peine de mettre exactement la même version de firmware en remplacement pour que le TPM ne s'aperçoive de rien ?
Ca fait 6.4x10^33 données possibles.
Toujours sous ton hypothèse douteuse que deux machines n'ont aucune chance de renvoyer le même hash.
De plus, j'imagine que les constructeurs auront beaucoup de paperasse à remplir pour avoir le droit de certifier des composants et des PC complets. Donc il est clair que les utilisateurs n'auront plus le choix entre 36 versions de BIOS comme aujourd'hui. Au mieux il y aura 3 versions certifiées et 33 versions "beta". Idem pour les drivers Windows certifiés par Microsoft.
AC
[^] # Re: La news de l'année ? On vote ?
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 3.
Cool. On peut venir mettre des caméras de surveillance chez toi, alors ?
Remarque, si tu n'as rien à cacher ni à protéger, pas même un numéro de carte de crédit, ou des infos qui pourraient intéresser ton assureur ou ton employeur, ou le plan stratégique du parti politique que tu es en train de fonder, c'est que tu dois être le type le plus inintéressant du monde, et je plains le vigile à qui on va confier ton dossier :-)
[^] # Re: On va se répéter une dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 3.
Pourtant la spec TCG PC Specific Implementation Specification fait tout ce qu'il faut pour que certains hashes soient prédictibles. Par exemple, elle exige que les numéros de série et autres identifiants uniques ne soient pas hashés, ainsi que les portions du MBR spécifiques à la géométrie du disque. Ces précautions n'auraient aucune utilité si l'objectif était seulement de contrôler que le PC boote "dans la même config que la dernière fois". Etrange, non ?
Et quels registres PCR as-tu comparés entre tes deux machines ? J'ai l'impression que seuls PCR[0]-PCR[4] sont conçus pour être bien déterministes.
Autant te dire que pour vérifier un hash et en déduire ce qu'il y a vraiment dérrière il faut y aller....
Je suis sûr que les constructeurs fourniront la liste de toutes les combinaisons homologuées de composants mis sur le marché, si Microsoft demande gentiment.
AC
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 3.
Qui te dit qu'IBM ou le fabricant du TPM n'ont pas une copie de PubEK sous la main, pour le cas où tu demanderais un certificat ?
Voire de PrivEK (mais dans ce cas, un flag doit en principe t'indiquer que EK a été injectée et pas générée par le TPM lui-même).
En sachant que l'on ne peut pas se servir de a partie publique de l'EK pour faire de l'encryption ?
On se sert de PubEK pour faire du chiffrement, par exemple pour insérer le secret partagé du Owner à distance.
On peut parfaitement désactiver la clef d'endossement et ne jamais s'en servir.
Oui, mais dans ce cas le TPM n'apporte pas grand chose par rapport à une carte à puce associée à un BIOS non flashable. Moi je préfère qu'il y ait un mécanisme de certification qui me garantit que le TPM que j'ai acheté n'est pas contrefait, que son architecture a bien été évaluée Critères Communs EALx par un labo indépendant du fabricant, etc...
Le problème est qu'on empêche le client final de révoquer ce mécanisme de certification ou d'en prendre le contrôle et la responsabilité, alors que ce serait légitime par exemple pour un usage en entreprise. Par conséquent, un jour, 99,9% des PC auront un TPM avec une EK indélébile et un certificat utilisable pour faire du DRM, et à ce moment le grand public n'aura aucune excuse pour empêcher Microsoft, Intel et Sony de déployer Palladium au dessus, puisque ce sera indolore et gratuit (et que ça permettra de lutter contre le terrorisme, blah blah).
Plus précisément, une partie des mécanismes nécessaires (TPM_RevokeTrust et TPM_GenerateRevocableEK) ont été ajoutés à la spec 1.2, mais les release notes expliquent qu'il ne faut pas compter dessus dans les TPM destinés au grand public. Il est encore temps d'exiger que cette politique change.
L'enjeu n'est pas de pouvoir désactiver EK temporairement, ni le TPM entier.
L'enjeu est que les constructeurs de PC nous vendent exclusivement des TPM avec une EK révocable et remplaçable, même si la décision par l'utilisateur de révoquer l'EK du constructeur implique que le TPM devient inutilisable pour certaines applications.
AC
[^] # Re: On va se répéter uen dernière fois
Posté par a_caspis . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 2.
Ce que tu appelles certification simple, c'est le mécanisme à base de protocole zéro-knowledge (DAA) ajouté dans la version 1.2 ?
En tout cas tu as bien un EK unique, lisible par l'OS (avec autorisation de l'Owner si tu as pris la précaution d'appeler TPM_DisablePubekRead), et que tu n'es probablement pas libre de modifier. Il ne manque vraiment pas grand chose pour que tu puisses entrer dans le monde merveilleux du DRM :-)
Si jamais le "niveau" est stocké dans le certificat mais pas dans le TPM lui-même, il suffit que le constructeur décide de te délivrer un nouveau certificat. "C'est gratuit et c'est plus sûr, pourquoi refuser ?"
AC