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

Posté par  . Édité par Benoît Sibaud. Modéré par Fabien Penso.
Étiquettes :
0
10
mar.
2003
Linux
Puisqu'il circule beaucoup d'informations non vérifiables sur TCPA, voici 6 informations vérifiables (specs officielles TCPA ou documents officiels destinés à rassurer d'IBM cités à chaque fois) et leur conséquences pour nous les utilisateurs. Voir l'article suivant. *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 ce lien.
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é puisse être désactivée 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 : 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 être contrefaite (elle est identifiable 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: 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 ce PDF.

* conséquences: tous les utilisateurs de dual-boot (par exemple Linux et Windows sur le même ordinateur) pourront bientot être 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 déjà 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 pas ê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 3: impossibilité de contrôler 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 même 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 ce PDF.

* conséquences: sécurité et obscurité ne font pas bon ménage. Des chevaux de Troie ou des failles pourraient être 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 (voir ici)
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 ce PDF
*conséquences du mode "extend": tous les OS libres (noyaux + programmes systèmes) que l'on peut recompiler en totalité ou en parti 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» voir la page 11 de URL permanente)

Aller plus loin

  • # "Encrypter"

    Posté par  . Évalué à -7.

    C'est lourd de lire dans des documents comme ca "encrypter" (et ses variantes) partout....

    Le terme francais est "chiffrer", et ca me paraitrait plus "pro" (ou au moins plus propre, plus sérieux) de remplacer ca .......
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  . Évalué à 10.

    Pour le gun c'est normal qu'on aie accès uniquement aux randoms valides, un bon module de sécurité jette les premiers tirés puis passe quelques algos comme MonteCarlo histoire de vérifier que l'analogique marche toujours nickel, inutile d'être parano là (pour plus d'info sur ces guns cf spec FIPS 140).

    Pour la clé racine, ça ressemble pas à une clé de fab permettant une personnalisation mais à une clé qui vous dépossede : ce n'est pas votre clé ! vous n'avez plus de contrôle sur votre PC ! vous payez un truc que vous croyez être votre PC et qu'on détourne en fait comme plateforme DRM, vous payez vos chaines !

    Bref, si vous avez besoin de crypto, achetez un lecteur PINPad et des cartes à puces !

    En plus si c'est sécuritaire comme du EAL4, le code doit être dispo à l'évaluateur dans le sens où à partir d'EAL4 le code est sensé résister à des divulgations, donc que des hackers puissent le lire ne doit plus être un danger, donc selon les CC à partir de 4 on devrait pouvoir faire le forcing sur l'accès au code sans que ça casse les CC... or là on cache tout... vous en concluez...
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  . Évalué à 10.

      que c'est pas très clair. Tu sembles être un spécialiste de cryptographie, ce que malheureusement, peu de lecteurs de linuxfr.org sont.
      Pourrais tu expliquer plus en détail ce dont tu parles ?
      ex: "EAL4", les "CC", le "gun", "clé de fab", "lecteur PINPad", etc.

      Ou à défaut, peux-tu nous indiquer un site qui documenterait tout cela ?

      Merci ;-)
      • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

        Posté par  . Évalué à 9.

        euh... les CC j'ai déjà expliqué ça sur http://linuxfr.org/comments/175211.html(...)

        un gun c'est un générateur de nombres aléatoires, basé sur une source analogique de bruit blanc.

        une clé de fabriquation c'est une clé insérée lors de la fabriquation d'un chip lors des permiers tests usine et que seul le fabriquant connait, mais elle sera desactivée plus tard par la pose d'un verrou lors de la personnalisation du chip et remplacée par une clé générée en interne ou descendue par un canal sécurisé. le principe de base c'est une clé par phase de vie, avec un proprio par phase de vie. dans le cas du TCPA on dirait que ça marche pas comme ça du tout, autrement dit la clé reste propriété du fournisseur ce qui est inacceptable.

        un PINPad c'est un lecteur de cartes à puce avec écran clavier histoire de ne pas taper le PIN sur un PC (imaginez un B.O....)

        un site ? nan, dommage, c'est tout éparpillé...
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  . Évalué à 8.

      vous en concluez...
      que le code inclus n'est pas censé résister à la divulgation, donc qu'il n'est pas aussi bon que ça, donc que des problémes de sécurité vont survenir, donc qu'on ne pourra pas intervenir sur le code défaillant pour y remédier, donc qu'on va régresser sur le plan de la sécurité, donc que c'est de la bouse ????
      J'ai bon, m'sieur?
      • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

        Posté par  . Évalué à 9.

        Oui, tu as bon.

        Il va y avoir regression du point de vue securité, mais par contre du point de vue business, c'est un gros progrès. En langage commercial, cela donnera:

        "Voici TCPA-2.0, encore plus performant et sécurisé que la version précédente! TCPA-2.0 est optimisé pour l'architecture Zogtel Brolium-6".

        Et il te faudra traduire: la version 1.0 était vérolée a mort, voici un truc qui fonctionne a peu pres. Mais vous êtes obligés de changer toute votre machine Brolium-5.

        La société qui a inventé le procédé pour le software s'étant fait un pognon monstre, y a pas de raison qu'on applique pas la recette au hardware...
        • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

          Posté par  . Évalué à 2.

          Ohh ce sera mieux que ca, ca donnera des conférence a la mode Microsoft :
          "ok, avant on etait pas totalement secure, notre but était de sortir le produit pour le public. Mais maintenant on est complétement orienté sécurité cette version 2.0 est vraiment une petite merveille, nous avons beaucoup appris des erreurs du passé ..etc". A incrémenter de version en version comme pour le discours depuis win 95 ..
      • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

        Posté par  . Évalué à 5.

        Oui.

        Le paradoxe c'est qu'il y a un gros push marketing sur les EAL4, qui sont un niveau où la menace que le code soit connu par n'importe qui est considérée comme possible et donc devant être absolument contrée, surtout par la crypto dans les faits. Donc une logique plus proche du logiciel libre que proprio...

        Si c'est EAL4 ils devraient pouvoir mettre le code au grand jour sans avoir à trembler, en plus coté proprio ils sont sensés être protégés par leurs brevets. Or ils ne le font pas. Ca protège pas les brevets ? C'est pas du vrai EAL4 ? :)
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  . Évalué à 1.

      Bon je passe sur l'enormité du troll qu'est cette news, je suis trop fatigué par mon boulot actuel pour me lancer dans un autre longue argumentation.

      Pour la solution du PINPad, ou des lecteurs de smartcard, je veux bien ce serait une solution qui consillerit tout le monde, mais le probleme est que les lecteur standar ne sont pas securisé car il ne gere pas le padding, et ceux qui sont fiable sont proprio.
      De plus la plus part de ces systeme coutes aussi chers qu'un processeur actuel ( 400E ), alors que tout l'interet de TCPA c'est que ce soit un standar sur le papier et dans les faits ( on a pas besoin d'un autre Betamax, qui bien que superieur n'a pas trouver son filon du fait de produit trop chers et peut courant ).

      Bref, si vous avez besoin de crypto, achetez un lecteur PINPad et des cartes à puces !

      Si on s'interesse qu'a ce qui font déjà usage du cryptage alors ca n'a plus d'interet.

      En plus si c'est sécuritaire comme du EAL4, le code doit être dispo à l'évaluateur dans le sens où à partir d'EAL4 le code est sensé résister à des divulgations, donc que des hackers puissent le lire ne doit plus être un danger, donc selon les CC à partir de 4 on devrait pouvoir faire le forcing sur l'accès au code sans que ça casse les CC... or là on cache tout... vous en concluez...

      Troll ... ta smartcard et ton pinpad c'est pour sa puissance des calcul que tu l'utilise ? non, c'est pour proteger tes clées de plus les algo son standar connue et publique RSA SHA AES on etait bien plus etudiés et attaqué que EAL4.
      • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

        Posté par  . Évalué à 1.

        Bon ok, je vais de ce pas donner ma dem à ma DRH, pasque là je suis plus dans le coup...

        Plus sérieusement :

        tu peux m'expliquer ton histoire de padding ? j'ai pourtant bossé sur des tas de lecteurs et pourtant je ne comprend pas...
        400 Euros ? tu achetes des modeles plaqués or ou quoi ? même aux banques on les vendait 3 fois moins chers...
        l'interêt de TCPA ? courcircuiter les cartes à puce de conception française.
        ensuite je crois que sur les clés tu te trompes, elles ne sortent __JAMAIS__ de la carte donc c'est bien sur la puissance de calcul de la carte qui est utilisée, et des cartes on en trouve en 8/16/32 bits avec ou sans accelerateurs cryptos. Quand aux algos, euh une carte c'est un CPU avec ROM/EEPROM donc on code l'algo qu'on veut...

        plus etudiés et attaqué que EAL4 euh, ça veut rien dire ça, à part que tu n'ais rien compris aux CC (/o\ pas taper). EAL/CC c'est pas un algo, c'est une méthodologie et une librairie de critères sécuritaires...

        YOU are a troll !
        • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

          Posté par  . Évalué à 0.

          "t'es un troll!" "vi mais toi t'es rien qu'un fud" "m'en fout moi j'utilise pas kde ispèce de noob" "tu veux la voir la longueur de ma clé ? tu risque de plus marcher après..."

          et après on voit des critiques de /. et de ses échanges mais non j'insiste que sur ce point la france ne joue pas de son particularisme culturel et présente une similitude certaine ^^

          'fin bon c'est avec ce type de super thread que j'en arrive à voir mes jeankevin-like m'expliquer que tcpa est le nouveau système anti piratage qui sera intégré à longhorn.... :/

          "courcircuiter les cartes à puce de conception française"
          malheureusement ce secteur se court-circuite déjà tout seul (gemplus) alors c'est peut-être pas l'argument contre tcpa le plus aboutit :p
  • # Liens du site

    Posté par  . Évalué à -9.

    JE n'arrive pas à aller sur les differents liens offerts par ce site dans le menu à gauche.

    JE suis sous Mozilla et NS 7, serait ce une erreur de ma part ou le site n'est pas compatible Mozilla ?
    • [^] # Re: Liens du site

      Posté par  . Évalué à -3.

      Je suis en Mozilla 121 sous Win98 et ça marche bien.
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  . Évalué à 8.

    J'ai l'impression que ce que l'on craint avec le TPCA, c'est ce que certains pourrait en faire ; de la même manière, certains personnes ont peur de ce que pourraient faire des méchants pirates avec des logiciels d'analyse de sécurité.

    Mais _en-soi_ cette technologie ne peut-elle pas être utile ?

    En parcourrant l'article de LinuxMag sur les réseau sans fils, je me demandais s'il était possible d'utiliser TCPA pour améliorer la sécurité de ces réseaux en autorisant la connexion qu'aux machine identifiées par leur "numéro" TCPA. Est-ce que cette méthode serait infalsifiable ?

    Ces réflexion m'ont amené à me poser la question : Est-ce qu'une machine virtuelle de type Boch pourrait "emuler" le TCPA ?


    Maintenant, il est vrai que dans de mauvaises main, le TCPA peut engendrer de gros problèmes. Je pense aux DRM mais surtout aux truc du genre "votre patron vous envoie un courriel pour vous demander de faire quelque chose d'illégal, courriel qui s'autodétruira dans 15 seconde."

    Néanmoins, ces problèmes dépendent de la onfiance que l'on a dans les concepteurs des logiciels que l'on utilise. Personnellement, je n'ai pas de problèmes de ce côté là. ;-)

    Par contre, tu soulèves un problème important à mes yeux et auquel je n'avais pas pensé. Quid de la protection par une clef à longeur fixée au regard de l'évolution des techniques de décryptage ?

    Yannick
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  . Évalué à 10.

      je me demandais s'il était possible d'utiliser TCPA pour améliorer la sécurité de ces réseaux en autorisant la connexion qu'aux machine identifiées par leur "numéro" TCPA

      Oui, mais on a pas besoin de TCPA pour ca: il "suffirait" de mettre en place sa propre PKi, et de stocker les certificats / cles privées (protégées par mots de passes, bien sur) sur les machines clientes. Après tout, de ce point de vue, TCPA n'est qu'une "variante", qui propose un avantage (stockage de la cle privee en Hard) et un inconvénient (on a aucun controle sur la cle privee (il en existe peut etre une copie ailleurs) ni sur l'autorité de certification (elle pourrait nous révoquer !) ....).

      Après ca, tu concevrais un mechanisme d'authentification forte a partir de ces certificats (que tu confrontes à ton autorité de certification, plus eventuellement d'autres validations sur les champs du certificat) pour authentifier tes postes.

      En extrapolant encore, on peut imaginer que ton méchanisme d'authentification permette aussi de négocier des paramètres (une clé de session, voire pourquoi pas carrément un algo de chiffrement, d'authentification, etc....), dont tu te servirais pour chiffrer/authentifier tous les paquets que tu emmets/recois avec ton correspondant....

      Hein ? quoi ? ca existe déjà ????

      Ah ouais, c'est IPSec.......
      • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

        Posté par  . Évalué à 7.

        [+]

        Et ainsi, tu contrôles entièrement ton système d'information, ce qu'a priori on ne peut pas faire aussi bien avec TCPA. Et, finalement, c'est le plus important.
        • [^] # Controle du système d'information

          Posté par  . Évalué à 6.

          En fait, c'est effectivement bien la le problème: on a d'abord essayé de nous présenter TCPA comme un "containeur de clés", associé à un cablage hard de fonctions de chiffrement/generation d'alea/etc....

          Et présenté comme ca, ca peut paraitre potentiellement intéressant.

          Le problème est justement que, en fait, on subit l'implémentation, et pire encore, on subit le certificat "principal" (on me fournit MA clé privée..... mais comment puis-je etre sur qu'il n'en a pas été fait une copie avant ??????).
          • [^] # Re: Controle du système d'information

            Posté par  . Évalué à 10.

            Ha bon ? Ils te fournissent ta clé "privée" ? Ben dans ce cas elle n'est plus tellement privée... et même si pas de copie un hash suffit pour la fliquer...

            De nos jours ces clés doivent être générées sur commande de leur propriétaire ! Le matos sait le faire ! On a cablé tout les trucs sur les nombres premiers et cribles associés. Ne vous faites jamais refiler des clés, générez les vous même !

            Le matos sait le faire, exigez d'avoir accès à cette fonction de base qu'est la génération de clés ! C'est la __RACINE__ du problème...
            • [^] # Re: Controle du système d'information

              Posté par  . Évalué à 4.

              Hmm, que croire? ;-) [provient du premier lien de la news]

              "Both [integrity protection and trusted storage] use trusted root certificates as this basis [of their
              security guarantees.]" This is a misunderstanding of the TCPA specification. There is no
              requirement for certificates at all, to use any TCPA chip function
              . There doesn’t even exist such a
              root authority for TCPA in general
              , or for IBM’s currently shipping chips. You can generate
              private keys, use them to sign, and decrypt, and seal/unseal data under PCR’s, all without any
              certificates
              . The only time a certificate is needed is if you want to be able to prove to a third party
              that you have an approved TCPA chip. Most applications do not have this need, and this
              certification is not currently supported with IBM’s chips. If you want to do an application that
              needs such a certificate, the TCPA has an endorsement key that can be used to get a suitable
              certificate. The only way this can work is if someone, like the manufacturer, has recorded a given
              TCPA chip’s public endorsement key, and can use this knowledge to certify identity keys from
              the given TCPA chip. This is not required, and software access to the endorsement key can be
              disabled. There is certainly a privacy aspect of access to the endorsement key, as it uniquely
              identifies the platform, and the TCPA specification goes to great lengths to allow for anonymous
              certification. The best defense for privacy conscious users is simply to turn off the endorsement
              key."
              • [^] # Re: Controle du système d'information

                Posté par  . Évalué à 3.

                Tu remarqueras que j'ai été général dans ma remarque...

                Bon, sur ta remarque :
                1/ certificats <> clés privées, donc ta citation m'avance guère (certifs -> clés publiques)
                2/ TCPA c'est une norme, donc les implémentations ont encore de la marge en termes de fonctionnalités...
                3/ root authority <> fab authority (à la rigueur vaudrait peut-être mieux une root authority...)
                4/ The only time a certificate is needed is if you want to be able to prove to a third party that you have an approved TCPA chip. Most applications do not have this need oui mais pour combien de temps ? Parce qu'aujourd'hui, de telles applicattions ne courrent pas les rues, mais demain avec Palladium ?

                ça peut-être un bon système en soi, qu'il ne soit pas perverti j'ai du mal à le concevoir...
      • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

        Posté par  . Évalué à 10.

        Ce que tu écris là est très intéressant et je n'y avais pas pensé.

        Dans TCPA, je voyais l'avantage d'avoir une clef "en dur" que l'on ne pouvait pas dérober (à moins de piquer mon ordinateur !).

        Je trouve que dire que la clef a peut-être été copié avant qu'on me vende l'ordinateur frise le mode parano ; par contre, le problème de la révocation me semble très important :

        - le concepteur de la puce pourrait révoquer ma clef : c'est encore un peu proche du mode parano mais beaucoup moins (surtout par les temps qui courrent :-( )

        - on me vole mon ordinateur : je vais comment pour révoquer ma clef privée (pas parano du tout !).

        Je présume que le système prévu est que l'on pourra faire opposition sur un ordinateur comme on fait opposition sur une carte bleue.

        Finalement, ce qui serait pas mal, ce serait un TCPA où on peut mettre sa propre clef GnuPG !

        Yannick

        PS :
        - Allô, comment faut-il faire pour faire opposition sur un ordinateur TCPA ?
        - Il faut nous envoyer le formulaire d'opposition, signé avec votre identifiant TCPA pour que l'on soit sûr qu'il vient de vous.
        • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

          Posté par  . Évalué à 2.

          Je trouve que dire que la clef a peut-être été copié avant qu'on me vende l'ordinateur frise le mode parano

          Euh... on me paye pour etre parano :-)

          Et une clé PRIVEE, bah ca doit etre privé !!!

          Mais apparemment, d'apres un autre post la au dessus, c'est encore moins simple qu'il n'y parait.....


          Finalement, ce qui serait pas mal, ce serait un TCPA où on peut mettre sa propre clef GnuPG

          Euh, ouais, enfin le concept de PGP/GPG est encore un peu différent, y'a pas de notion de "root of trust", seulement de confiance mutuelle......
          • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

            Posté par  . Évalué à 3.

            tient, un collègue \o/
            et oui la parano c'est un métier, d'ailleurs moi je ne code même plus... que de la parano. mais bon quand on sait ce que les autres ne savent pas ou croient impossible, ça change les perspectives.
            • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

              Posté par  . Évalué à 4.

              tient, un collègue \o/

              Mhhh .... tu dis ca pour essayer de gagner ma confiance ? :-)

              la parano c'est un métier

              Entièrement d'accord: les "paranos amateurs" se laissent guider par leur parano.
              Les "paranos pros" sont paranos, certes, mais sont aussi des pros....

              La différence ?
              Le second ne se laisse pas dominer par sa parano......

              mais bon quand on sait ce que les autres ne savent pas ou croient impossible, ça change les perspectives.

              Oui.

              Et c'est d'ailleurs pour ca que j'essaie de faire de "l'éducation" quand je peux, par des explications parfois, mais le plus souvent par des démos simples (le sniff des mails entrant/sortant, c'est tout bete, mais comment c'est efficace :-).


              A quand un site de "vulgarisation" de la parano, qui montre clairement, avec explications à l'appui, sans sombrer dans la "mauvaise parano", pourquoi il faut quand meme etre un peu parano ?????

              Je suis volontaire pour co-animer ce paranofr.org :-)
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  . Évalué à 10.

      > Mais _en-soi_ cette technologie ne peut-elle pas être utile ?

      Ben, comme le fait remarquer Tselek, ce que nous vantent les défenseurs du TCPA, du point de vue technique, ce sont des choses que l'on peut déjà faire en se dotant du matériel adéquat, cette technologie n'apporte donc rien, à part le fait que ce n'est plus toi qui maîtrise totalement ton système de sécurité (tu ne peux pas choisir ton OS, ni même forcément ton matériel : tu dois faire confiance à quelqu'un d'autre).
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  (site web personnel) . Évalué à 2.

      J'ai l'impression que ce que l'on craint avec le TPCA, c'est ce que certains pourrait en faire ; de la même manière, certains personnes ont peur de ce que pourraient faire des méchants pirates avec des logiciels d'analyse de sécurité.

      C'est toujours pareil, Einstein ne pensait pas forcément à ce qui se passerait quand il a imaginé la puissance du nucléaire, le gars qui a inventé le couteau ne pensait pas forcément à toutes les utilisations de cet outil...

      Maintenant, je me pose une question : qu'est-ce qui me prouve irréfutablement qu'ils ne vont pas utiliser ça contre ma vie privée ?

      Pour l'instant, je n'ai pas l'impression que cette technologie est complètement innocente => d'où mon refus.
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  (site web personnel) . Évalué à 3.

    Merci

    Continue comme ça à surveiller la bête.
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  . Évalué à 7.

    A ce propos : un autre site interessant...

    http://www.notcpa.org/(...)
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  (site web personnel) . Évalué à 3.

    J'ai mis très rapidement en forme le fichier texte dans un fichier LaTeX. J'ai mis des versions ps et pdf (et tex) sur ma page :

    http://morvan.nerim.net/tcpa(...)

    Naturellement je suis à la disposition de l'auteur toute modification.
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  . Évalué à 3.

    INFO 1 :
    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 être contrefaite
    Un peu à l'image des adresses MAC, identifiant de manière unique un hôte sur le réseau : je ne trouve pas cela plus choquant que ça... Est-ce pour se réserver l'anonymat <=> immunité ?
    Un jour ou l'autre, l'utilisation de cette clé sera exigée par les softs DRM ...
    Il ne s'agit ici que de l'emploi, via l'OS, qui peut/pourrait en être fait pas d'une capacité intrinsèque de la puce... En outre, la possibilité offerte de restreindre l'accès au seul "propriétaire" (i.e ordinateur) peut être souhaité par ce dernier : à voir donc comme une fonctionnalité offerte (?)

    INFO 2 :
    être confrontés à des fichiers (documents ou programmes) encryptés sous Windows et inutilisables sous Linux...
    Là encore il s'agit de l'utilisation qui pourrait en être faite, rien de plus... En outre, il arrive un moment où il faut choisir : si on passe son temps à "taper" sur Windows, il est difficillement défendable de dual-boot"er" sur cet OS...
    Enfin, à supposer que ce cauchemard se réalise, ne pouvoir relire/modifier un document qu'exclusivement sur l'ordinateur et l'OS d'origine, c'est tout simplement la mort de la communication au moyen de l'outil informatique : soyons réalistes...
    NDLR : personnellement, je suis un des utilisateurs de dual-boot

    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 ...
    Je doute que l'utilisation de tels logiciels soit effective pour des données personnelles.

    INFO 3 :
    impossibilité de contrôler le code qui est dans les puces TCPA
    D'accord sur le fond, mais :
    Des chevaux de Troie ou des failles pourraient être introduites dans ces puces sans que les utilisateurs le sachent.
    ...pas plus qu'avec des exploits potentiellement non connues et/ou non publiées par l'éditeur d'un logiciel (surtout propriétaires car, ici, le problème est de cet ordre propriétaire/libre).

    Quant à il n'est pas prévu dans les specs de pouvoir changer ces algorithmes si une nouvelle faille est trouvée
    Je ne pense pas que cela soit dans l'intérêt du constructeur. Si l'un ne l'autorise pas, d'autres proposeront la mise à jour de la puce. (ou peut-être suis-je naïf ?)

    Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique)...
    Existe-t-il un algorithme incassable ? j'en doute...

    INFO 4 :
    TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être booté
    Sur ce point, il est vrai que l'aveu implicite est pathétique et constitue une négation de nos droits élémentaires. De plus, cette fonctionnalité est déjà remplie par le BIOS / Firmware / Hardware sur les solutions actuelles.

    INFO 5 :
    Pas compris les * conséquences : OS non signés / extend abandonné / ...

    INFO 6 :
    roots of trust ce qui est somme toute la pierre angulaire de cette technologie : est-ce surprenant ?
    Quant à l'activation framework de Windows XP, même si ce procédé est gênant pour une majorité de non-détenteurs de licences Windows mais utilisateurs tout de même, ce n'est jamais qu'un moyen pour l'éditeur de faire respecter son droits. Que l'on soit d'accord ou pas ne change rien sur le fond : l'éditeur (en l'occurence Windows) est dans son droit, l'utilisateur sans license non.

    Bref, au moins pour toutes les raisons ci-dessus, je refuse fortement d'avoir des puces ou des softs TCPA ...
    Au moins il existe des plate-formes alternatives et pour le numéro unique, un conseil, débranche ta carte réseau.
    En résumé, je trouve cet article intéressant sur bien des points mais l'aspect critique est trop souvent ignoré au profit de certains amalgames qui ne servent aucunement le sujet.
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  (site web personnel) . Évalué à 3.

      et pour le numéro unique, un conseil, débranche ta carte réseau

      En ce qui concerne ce point, ça n'a rien à voir, dans la mesure où le numéro de la carte réseau peut être altéré de façon logiciel. Ce qui ne doit pas être le cas pour TCPA.
    • [^] # Commentaire supprimé

      Posté par  . Évalué à 7.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

        Posté par  . Évalué à 0.

        On a le droit de ne pas être fiché partout par des firmes privées
        1. Ce droit n'est pas implicitement nié ici, pas plus que ton droit à accéder / rectifier les informations collectées.
        2. Accessoirement, ce fichage existe déjà. Le fait que ce soit "limité" à ton banquier, ton médecin ou ton revendeur de voitures est-il plus sécurisant ?
        Je ne vois de ta part, ici, qu'un procès d'intention à l'égard des éditeurs de logiciels...

        la plupart des constructeurs adhèrent à tcpa
        Dans l'absolu, la plupart des utilisateurs (informatique personnelle) préfèrent/se voient imposer Windows... Est-ce pour cela qu'il n'existe pas d'alternative ? Sur cet argument donc... nous avons aussi le choix.

        Rien à voir entre libre et propriétaire
        Tu détournes mon propos : il s'agissait juste d'associer opacité de la puce avec celle du code des logiciels propriétaires et de l'opposer au libre.

        Bon je vais pas passer mon temps à répondre au reste c trop GROS
        C'est tout à fait selon ce shéma que l'on favorise l'échange de point de vues... Ton avis est-il tellement clairvoyant et implicite qu'il te dispense d'argumentaire ?
        • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

          Posté par  (site web personnel) . Évalué à 5.

          Adresse MAC : elles sont changeables facilement, et surtout une adresse MAC ne franchit pas ton réseau local...

          2. Accessoirement, ce fichage existe déjà. Le fait que ce soit "limité" à ton banquier, ton médecin ou ton revendeur de voitures est-il plus sécurisant ?
          Je ne vois de ta part, ici, qu'un procès d'intention à l'égard des éditeurs de logiciels...


          Tu te fou de qui ? Les medecins ont un code qui leur interdit de divulgué une quelconques informations sous peine d'être interdit d'exercer. Ton banquier a une interdiction formelle de vendre leur fichiers de données perso. Ton vendeur de voiture essait d'avoir un maximum d'info mais il n'a pas le droit de faire n'importe quoi.

          Les gens ont le droit de se protéger, mais avec un identifiant généralisé comme une endorsement key tu ne pourras plus seulement effacer le cookie.

          Ton propos ressemble a du gros FUD : "regarder on vous nique par ailleurs pourquoi pas par ce coté là aussi"

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

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 0.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Point...

            Posté par  . Évalué à 0.

            Non, le tien ne tient pas du tout la route, il n'entretient que des FUD's
            Si avoir un minimum d'ouverture d'esprit (quitte à se faire parfois l'avocat du diable) ne revient à tes yeux qu'à entretenir des UF's alors oui, définitivement, nous ne parlons pas la même langue... ce que reflète en substance ton argumentaire.
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  . Évalué à 2.

      >> Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique)...
      > Existe-t-il un algorithme incassable ? j'en doute...

      A l'heure actuelle, ca existe avec une longueur de clé égale à celle des données.
      (super pratique :))

      -1 HS / au sujet
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  . Évalué à 6.

    Je ne pense pas que le système TCPA/paladium puisse être adopté sous la forme qu'il présente aujourd'hui.
    Il faut savoir qu'une part très importante du CA de Micro$oft et dans une moindre mesure des fabricants de matériel concerne les PME. Comment imaginez-vous qu'une PME puisse se passer de pouvoir compiler un programme et de l'exécuter ?
    Un exemple : je peux très bien réaliser un encodeur MP3 en VisualBasic sous excel (ça me ferait mal mais c'est possible). Va-t-il falloir une licence pour lancer des scripts VisualBasic sous excel ? Quelle PME pourra se passer de lancer des scripts sous excel (ou tout autre type de programme "maison") ?
    Vu le coût de la licence permettant de lancer ses propres programmes, je ne pense pas que l'on puisse trouver ne serait-ce qu'une seule PME qui pourrait se le permettre. Ils auront beau faire toute la pub qu'ils voudront, quant une boite aura acheté un ordinateur à base de TCPA et qu'elle verra qu'elle ne peut pas travailler dessus, elle le fera savoir et elle n'en achètera pas d'autres.
    • [^] # TCPA n'est pas Palladium ...

      Posté par  . Évalué à 1.

      ... et réciproquement. Contrairement à ce que beaucoup de gens semblent penser. Accessoirement, Palladium vient d'être renommé en Next Generation Secure Computing Base. Oui, je sais, c'est beaucoup plus long à écrire...

      En tout cas, ça fait plaisir de voir que quelqu'un a réellement lu les spés TCPA avant d'en parler, ça nous change un peu :-) Pour ce qui est de Palladium, sans rentrer dans le détail, il y a pas mal de différences de fond avec TCPA et le système est entièrement distinct. Il semblerait d'ailleurs que Microsoft prépare un whitepaper à ce sujet, affaire à suivre. D'autre part, il se pourrait bien qu'il y ait un article à ce sujet dans un prochain numéro de MISC ...
      • [^] # Re: TCPA n'est pas Palladium ...

        Posté par  . Évalué à 1.

        j'ai mis à jour mes infos sur TCPA, avec notamment comment il est simple d'utiliser TCPA pour faire des trusted sandboxs à la Palladium (ce qui,en l'état actuel de ce qu'on peut savoir sur Palladium, est sa caractéristique majeure)
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  . Évalué à 2.

      Je ne pense pas que le système TCPA/paladium puisse être adopté sous la forme qu'il présente aujourd'hui.

      En fait euh... si qq avait un truc un tout petit peu officiel, expliquant clairement que TCPA vise à controller tous ce qui s'exécute sur la machine? parce que dans beaucoup de thread, certains partent de ce point de vue, et je n'ai jamais rien lu à ce sujet...

      Tous ce que je vois pour l'instant, page 4 de http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...) , c'est des trucs du genre: "There is no such thing as TCPA certification of code; this is pure invention." et page 7:

      "TCPA does not:
      - control execution
      - block execution based on signatures, or revocation lists, or approved lists"

      Et enfin, je me demande pratiquement comment, si c'était quand même le cas, controller l'exécution et même maintenir une liste d'approbation et de réfutation, quelle taille ça prendrait?
      • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

        Posté par  . Évalué à 1.

        TCPA ne vise pas à contrôler tout ce qui s'exécute sur la machine. Cette croyance populaire n'est que le résultat de la propagande de journalistes qui ont lu en diagonale la FAQ de Ross Anderson (qui n'est plus à jour depuis longtemps) et n'ont pas compris la moitié de ce qu'ils ont lu, mais y ont trouvé matière à faire un article "choc" (sic).

        Pour ce qui est de maintenir la liste d'approbation/réfutation, d'après les spés, tout n'est pas stocké dans le TPM (le Trusted Platform Module, plus ou moins la racine de confiance du système) : une partie peut être stockée à l'extérieur, bien entendu chiffrée, et accessible uniquement par le TPM. Cela résoud les problèmes de place.
      • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

        Posté par  (site web personnel) . Évalué à 1.

        Il y a un gros amalgamme entre TCPA et next generation of machin-bidule Palladium.

        En ce qui concerne les architectures de DRM actuelles de Microsoft, un dispositif de control de l'execution des programmes existe deja.

        Voir la news "Devinez qui viens fouiller chez vous ce soir" en premiere page de linuxfr.

        Palladium sera visiblement une generalisation de ce concept.

        Maintenant, sur les differences entre TCPA et Palladium, j'aimerais y voir plus clair.
        • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

          Posté par  . Évalué à 2.

          La différence fondamentale c'est que TCPA est une couche basse de chez basse voir meta-basse comme on a jamais fait sur les PC (plus bas que le BIOS, que le micro-code, pire que les "domaines" du 386), alors que Palladium c'est la couche OS, windows quoi. Bien sur l'un s'appuye sur l'autre
          • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

            Posté par  (site web personnel) . Évalué à 2.

            nononon, Palladium est plus bas encore que TCPA.

            TCPA est une périphérique de plus qui a accès au bus du processeurs pour faire ses mesures.

            Palladium inclue un ring -1 controlé par un soft de MS, le nucleus (?), une sorte de micronoyau qui peut caché des pages de mémoires mêmes à l'OS qui est en dessous. C'est encore plus bas niveau et intrusif que TCPA. Cela pourrait aussi tourné sous linux.

            Le but est de faire une protection mémoire même contre les OS. Et pas seulement pour les programmes entre eux.

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

            • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

              Posté par  . Évalué à 2.

              Pas tout à fait. C'est un nouveau mode du CPU indépendant de la notion de ring, le mode trusted. Dans ce mode tourneront le noyau (nexus), en ring 0, et les agents, en ring 3, tout comme un OS normal. Par contre, effectivement, en mode normal il est impossible de voir ce qui tourne en mode trusted, qu'il s'agisse des applis, du noyau, ou simplement de pages mémoires marquées trusted.

              Donc non, ce n'est pas plus bas que TCPA, mais ça inclut une couche hard de même niveau que celle de TCPA - et, à terme, compatible.
            • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

              Posté par  . Évalué à 1.

              ben c'est quoi un micro-noyau ? ça a beau être une sorte de micro-noyau, ça reste du ressort de l'OS... ou alors les noyaux ne sont plus considérés comme faisant partie de l'OS ? Et le ring ? Les termes que tu utilises appartiennent au monde des OS...

              J'ai du raté une étape... :)
          • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

            Posté par  . Évalué à 1.

            FAUX!

            Certes, à la base, TCPA fournit essentiellement des spécifications matérielles, ainsi que des lignes directrices pour l'implémentation sur diverses architectures (ils ont au moins sorties celles pour les PC). A partir de là, en effet, libre aux développeurs d'OS d'utiliser ces fonctions à leur guise. Pour l'instant, ça se présente surtout sous forme d'une puce que les fabricants de cartes mères peuvent inclure sur leurs produits.

            Palladium, quant à lui, inclut une définition des couches logicielles comme des couches matérielles, même si l'accent est plus sur le logiciel. La couche matérielle de Palladium, elle, se présentera de la même façon que celle de TCPA, mais en diffère pour l'instant, essentiellement parce que la version 1.1 de TCPA ne satisfaisait pas Microsoft au niveau des fonctionnalités apportées. D'après ce qu'ils disent, en revanche, la version 1.2 de TCPA (non encore disponible) devrait pouvoir être utilisée comme couche matérielle avec Palladium. En d'autres termes, les deux projets, qui avaient pas mal divergé, sont en train de converger plus ou moins à nouveau.
            • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

              Posté par  . Évalué à 1.

              :)

              mdr, pourquoi tu cries Faux! si c'est pour te tirer sur le pied juste après ?

              je te relis :

              1/ TCPA -> puce, hardware
              2/ Palladium -> couches, dont la PHY converge vers TCPA (ou l'inverse)

              j'en déduis que si MS a spécifié une couche matérielle dans Palladium c'est pour faire le forcing envers TCPA, et que de toutes façons les gens du hard feront le hard, donc du TCPA, et les gens du soft feront le soft, donc Palladium...
              Pour moi, en terme de couches, le hard reste en dessous du soft... CQFD.

              Autrement dit, je ne crois pas comme toi qu'Intel, ni même personne d'autre dans ce milieu, est prêt à obéir les yeux fermés à MS.

              De plus, si on a bien TCPA = couche basse de Palladium, donc MS, je vois mal IBM dans le coup...
              • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

                Posté par  . Évalué à 0.

                Je ne me tire pas dans le pied. Il n'y a pas comme tu le disais de projet commun TCPA/Microsoft dans lequel le TCPA créerait une couche matérielle et Microsoft une couche logicielle. C'est ce genre de déclaration qui fait que les gens font l'amalgame depuis le début. Palladium et TCPA sont deux projets bien séparés, même s'ils vont (très vraisemblablement) converger à nouveau. Palladium spécifie et le hard, et le soft, tout comme TCPA spécifie le hard et donne des lignes directrices (vagues) pour le soft.

                Ensuite, je n'ai jamais dit qu'Intel, ou AMD (ou Transmeta :-) obéirait les yeux fermés à MS. Par contre, si MS veut faire insérer des SSC (la partie matérielle de Palladium) sur les cartes mères dans des PC, je pense qu'ils ont facilement les moyens d'inonder le marché de cartes mères modifées.

                Ah, un dernier truc ... tu vois mal IBM dans le coup? Tu sais que Microsoft et IBM sont deux des membres fondateurs du TCPA?
                • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

                  Posté par  . Évalué à 1.

                  j'ai pas dit qu'il s'agissait d'un projet commun. de projets complémentaires plutôt.
                  j'ai toujours du mal à croire qu'IBM est prêt à aider MS à conforter son monopole.
                  de plus TCPA ou SSC ne peuvent qu'être dans le chipset ou le CPU, pas le choix, donc là c'est Intel/Via/SiS/etc. Pas MS.

                  question de bon sens.
                  • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

                    Posté par  . Évalué à 1.

                    Sans rentrer dans le troll, tu as dit, je cite : Bien sur l'un s'appuye sur l'autre. C'est à ça que je répondais : faux. A terme, cela devrait être le cas (dixit MS, mais ils parlent d'une spé TCPA non encore sortie), mais en attendant, ça ne l'est pas.

                    Pour les parties matérielles, pour TCPA, ça se présente (pour l'instant) sous forme de puces séparées que les fabricants de cartes mères peuvent intégrer, comme Atmel avec son TPM AT97SC3201 (http://www.atmel.com/atmel/acrobat/2015s.pdf(...) ).

                    Sinon, quand je dis que je pense que Microsoft peut imposer ça, c'est aussi une question de bon sens. S'ils ont réussi à forcer l'achat de Windows avec tous les PC neufs, je pense qu'ils ont les moyens de pousser les fabricants de cartes mères à intégrer un SSC pour Palladium. D'autant plus qu'il semble (indépendamment des problèmes de respect de la vie privée) qu'il y ait des gains de sécurité potentiels intéressants. Combien de fabricants refuseront d'ajouter des fonctionnalités nouvelles, d'après toi? Ceux qui refuseront prendront le risque de se retrouver largués par la concurrence ...
        • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

          Posté par  . Évalué à 1.

          et j'ajoute qu'à propos de En ce qui concerne les architectures de DRM actuelles de Microsoft, un dispositif de control de l'execution des programmes existe deja. ben ça, ça se casse tout seul avec un Bochs, un SoftIce ou des outils du genre... Tu connais un méchanisme de protection venant de chez MS qui n'ait été cassé ? Moi 0.
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  . Évalué à 2.

    Y a un truc plus que l'utilisation du TCPA dans une carte mere qui me dérange...
    est-ce qu'une machine non TCPA aura accès a des données destinés à des machines TCPA voir accéder à un réseaux TCPA ?

    Car si on doit tous se racheter des machines TCPA parce que Windows version TCPA sort et investi 80% du marché avec les consommateurs lambda (bah oui comme d'hab, le mec qui va au carrefour du quoi acheter un PC il se moque totalement de la technologie....) pour pouvoir communiquer (j'entends par la tous simplement echanger des fichiers entre nous...)


    Reste à avoir des machines non TCPA, peut etre que la solution viendra de VIA qui dans sa derniere puce C3 n'a pas intégré cette technologie avec un petit linux non TCPA dessus.... Ainsi ici le libre est la seule alternative à un OS TCPA (qui de MacOS d'ailleurs ?)
    • [^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

      Posté par  . Évalué à 3.

      est-ce qu'une machine non TCPA aura accès a des données destinés à des machines TCPA voir accéder à un réseaux TCPA ?

      Car si on doit tous se racheter des machines TCPA parce que Windows version TCPA sort et investi 80% du marché avec les consommateurs lambda

      Effectivement, là, on aurait un souci. Cela dit, pour que le réseau tombe sous la coupe de TCPA, pour qu'on n'y ait plus accès avec nos chers OS libres, il ne suffirait pas que les autres extrémités (les lambda) se fassent avoir. Il faudrait aussi que la majeure partie des intermédiaires fasse la migration. Et là, je demande : est-il vraisemblable d'imaginer que tous les FAI acceptent, sans plus y réfléchir, de mettre leurs routeurs sous le contrôle plein et entier d'un petit regroupement de déjà-très grosses boîtes ? (Parce que c'est gentil de tapper tout le temps sur les mêmes, mais MS n'est forcément pas tout seul dans l'affaire...)

      (Allez, pour se marrer, en vitesse : j'ai eu sous les yeux un argumentaire assez récents pour ".NET" (comprendre windows 2003, basiquement, à ce qu'il paraît), et je suis MdR à chaque fois (parce qu'ils insistent) que je tombe sur : "possibilité de faire un cluster, jusqu'à huit machines !"...)
  • # Ma carte mère vient de griller...

    Posté par  (site web personnel, Mastodon) . Évalué à 9.

    ...hop, je file chez le chinois du coin, j'en achète une neuve, je la remonte dans le boitier et je rallume la machine. wrong key: all your douments are unreeadable. Mon dieu, mais c'est pas possible un truc comme ça, ça ne marchera jamais. !
    • [^] # Re: Ma carte mère vient de griller...

      Posté par  . Évalué à 2.

      Ah, mais c'est qu'il faut lire ses modes d'emploi :
      "Please, feel free to buy online our brand new "WinWhatever to Win_Next-Generation_Secure_Computing_Base SP1.exe" !
      <veryverysmall>Et en l'appliquant, on récupère aussi tout le contenu de votre disque... pour analyses ultérieures, quoi. C'est même pour ça qu'on vous le met pas sur un CD...</veryverysmall>"
    • [^] # Re: Ma carte mère vient de griller...

      Posté par  . Évalué à 8.

      *info 7: un matériel soumis à un courant électrique n'est pas éternel.

      * conséquences : il faut envisager des sauvegardes et des procédures de remplacement.

      * méthodes :

      - Indiquez le Coût et le Temps Moyen Entre Pannes pour
      . une clef usb externe :
      . une pupuce tcpa onboard :
      . une pupuce tcpa inside the processeur :

      - Quelle est la procédure préventive à suivre permettant de faire face à une éventuelle panne
      . d'une clef usb externe :
      . d'une pupuce tcpa onboard :
      . d'une pupuce tcpa inside the processeur :

      - J'ai une panne matérielle. Quelle est la procédure à suivre dans le cas
      . d'une clef usb externe :
      . d'une pupuce tcpa onboard :
      . d'une pupuce tcpa inside the processeur :

      - Je crains une panne imminente et je souhaite changer de materiel. Quelle est la procédure à suivre dans le cas
      . d'une clef usb externe :
      . d'une pupuce tcpa onboard :
      . d'une pupuce tcpa inside the processeur :
    • [^] # Re: Ma carte mère vient de griller...

      Posté par  . Évalué à 1.

      Autre option: tu génèrés ta clé, tu encodes avec, forcément si tu changes de hard, tu dois copier ta clé sur ton nouveau hard, ça a toujours fonctionner comme ça... (combien de débutant n'ont pas coché la jolie case "Crypter le contenu de ce dossier" sur un dossier d'une partoche NTFS pour s'apercevoir qu'après une nouvelle install il ne pouvait plus ouvrir leur doc... ils auraient du exporter leur clé *avant*). J'ai bon? ;-)
    • [^] # Re: Ma carte mère vient de griller...

      Posté par  . Évalué à 4.

      C'est un très bon argument contre TCPA.

      <Pas content>

      Je me permet une critique de l'article. Dans la guerre de l'information que nous menons contre MS et autres, il me semble qu'on devrait bien faire attention aux arguments qu'on utilise. Si, dans une argumentation on donne n arguments et que parmis eux il y en a des foireux, même si les autres démontrent qu'on a raison, l'adversaire va se focaliser sur les arguments foireux pour gagner la bataille. Je pense que l'argument du cheval de troie... est foireux. Les deux arguments de l'impossibilité de choisir ses softs, et de perte de ses données en cas de panne sont bien meilleurs. Le dernier est en plus valable pour les utilisateurs de Windows. L'argument de la non utilisation est lui-même peu intéressant : la plupart des gens s'en foutent car ça ne change rien à leur vie (je parle là de beaucoup d'utilisateurs de Windows).

      On devrait se focaliser sur l'argument de perte des données en cas de Panne.
      • [^] # Re: Ma carte mère vient de griller...

        Posté par  . Évalué à 1.

        L'argumentation de info 3 est bancale, TSelek l'a fait remarquer fort justement. Il ne faut pas se mettre en colère : l'erreur est humaine.

        L'argument du cheval de Troie par contre n'est pas foireux.

        You can generate private keys, use them to sign, and decrypt, and seal/unseal data under PCR’s, all without any certificates.

        On aurait tendance à penser que "You" désigne l'utilisateur. Mais en fait c'est n'importe quel programme local et éventuellement distant qui va pouvoir demander à accéder à ces fonctions tcpa. Le programme est obligé de demander l'autorisation à root, certes. Mais cette demande n'est pas fair play. On entends ca: s'il te plait root, donne moi les droits d'avoir mon identité, de crypter, de te cacher des choses.

        Le processus n'explique pas pourquoi il demande ca. Quand un soft demande d'acceder à une carte son ou au réseau, root peut se douter de quelque chose, prendre ces précautions. Dans le cas de tcpa, c'est impossible.

        Ca ressemble bougrement à "je suis un DOCument, clique moi".
  • # PPC970

    Posté par  . Évalué à 0.

    Merci pour l'article...
    Une raison de plus d'attendre le nouveau processeur PPC970 d'IBM.
    A moins bien entendu que ces braves merdes n'en fassent également partie...
    • [^] # Re: PPC970

      Posté par  . Évalué à 2.

      sachant qu'IBM participe à la rédaction de cette norme je vois mal comment ils pourraient ne pas l'inclure dans leurs ppc :p un peu comme si MS et win ne suppoterait pas palladium ^^
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  (site web personnel) . Évalué à 2.

    *info 4: TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être booté avec ce mode

    Ben moi, ce que je voudrais bien savoir, c'est :
    - Comment, dans l'OS, se concretise la signature
    - et surtout : QUI signe les OS ?
  • # Demontage en regle

    Posté par  . Évalué à 2.

    Pour ceux aui ont suivi le thread TCPA precedent vous savez deja que l'ensemble des argumets avances ici sont au mieux incomplet, au pire le resultat d'une pure speculation, pour les autres :

    - *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.


    Outre le fait que la EK ne soit pas du tout obligatoire, je pense qu'il est bon de rapeler comment cette clef est cree et utilisee :

    Le constructeur de la puce ou le constructeur de la carte creent une clef de cryptage. Il est bon de noter que cette clef n'est pas utilisable.
    Si on le souhaite on peut demander a un organisme tiers de creer un certificat base sur cette clef(NB l'organisme ne recoit pas la clef mais valide le certificat par un principe de challenge, il ne connait jamais la clef d'endossement). Une fois cree c'est le certificat qui est exploitable. On peut sur une meme puce cree autant de certificats differents que l'on veut. Bien entendu cryptographie oblige il est impossible d'associer une certificat avec la clef d'endossement. On peut ensuite se servir du certificat ainsi cree pour s'authentifier aupres de site. Etre identifie a partir du certificat (qui est la seule info qui a le droit de transiter) implique que la personne qui a cree la puce et la personne qui a valide le certificat sont une seule et meme entite. De plus pour pouvoir vous pister il faut aussi que ce soit la personne chez qui vous utilisez le certificat. Bien que ce risque ne soit pas nul, il est de tres loin inferieur a celui des numeros de serie chez Intel. Ce n'est donc pas pire, c'est nettement mieux. Il est bon de rappeler que la norme TCPA interdit aux producteurs de puces d'etre des organismes certificateurs.


    *info 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)

    Je passe sur la derniere partie (oui il est possible de faire en logiciel tout ce que fait TCPA en hardware) pour me focaliser sur le systeme d'encription de boot.
    La puce TCPA possede un systeme qui lui permet de hasher un boot et de stoquer des clefs dans ce hashage. Si le boot n'est pas rigoureusement identique, le hashage change et les clefs sont impossibles a recuperer.
    Si j'encrypte mes doccuments sur un hashage de boot et que je boot differement mes doccuments cryptes ne sont plus disponibles. Effectivemnt si je boot sous linux je n'ai plus acces a mes doccuments . C'est aussi le cas si j'upgrade mon bios, si je patch mon os ou si je change ma carte graphique. Ce systeme est extrememnt limitatif. Tout changement dans la phase de boot entrainne un lock de mes fichiers. Je vous laisse imaginer les problemes que cela creerait si jamais la sauvegarde par defaut etait basee sur ce systeme. De plus il faut ajouter que si mon ordi a les droits pour creer une clef (ie si windows peut forcer l'enregistrement en crypte de mes fichiers en fonction du hashage du boot), alors il a aussi les droits de deplacer ces clefs via un systeme de migration. Donc meme si il y a encryptage sans que je le sache de mon fichier, je peut toujours sortir la clef du coffre depuis windows et la mettre a un endroit ou elle sera accessible depuis linux. La migration et le bind d'une clef ne sont pas des operations faciles, mais c'est tout a fait possible.

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


    IL est effectivement impossible d'acceder aux etapes intermediaires de la generation de nombre aleatoire. Mais je ne vois pas comment on peut introduir eun cheval de troie dans une puce qui n'est justement pas reprogrammable, a moins bien sur que ce ne soit le constructeur lui meme qui l'y place. Autant je comprend le soucis qu'il peu y a voir a vouloir etre sur de la force de la clef, autant on ne possede a l'heure actuelle le code d'aucun composant de nos PC. Il pourrait deja y avoir des chevaux de Troie dans une foule des puces qui compose nos ordis. Pourquoi les mettre dans la puce TCPA ? De plus les specs ne font pas mention de quoi que ce soit dans ce genre. Pure speculation donc.

    En ce qui concerne la force des clefs, il s'agit de clefs 2048 bits. Il est vrai que si le genrateur aleatoire est de mauvaise qualite, on entamme de beaucoup la force de cette clef, mais ca laisse encore pas mal de marge par rapport a des clefs 256bits.

    *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.


    Alors la n'importe quoi !! Bien que les morceaux cites soient exacts, le sens est completement deforme. Premierement "Most reasonable" ne veut pas dire tres raisonnable mais le plus raisonable dans ce contexte. Le rebutal d'IBM s'attaque a plusieurs doccuments, la plupart ecrits par des web redacteurs mal informes, et un ecrit par un scientifique. Celui ecrit par le scientifique souleve des problemes tres justes qui pourraient se poser dans l'avenir, meme si actuellement la norme TCPA ne pose pas probleme.
    En ce qui concerne le mode extend, le principe est le meme que le hashage de boot vu plus haut. Lorsque l'on place la puce en mode extend elle hashe l'integralite du boot(au lieu de juste des morceaux choisis). L'OS est alors "signe"=il est reconnu par le hashage integral du boot (oui ce n'est pas une boite exterieure qui signe l'OS, c'est la puce TCPA elle meme qui le fait lors de la demande de hashage en mode extend). Il est bon de preciser que
    -1) TCPA ne peut pas empecher une machine de booter (cf tcpa rebutal) meme si l'OS n'est pas "signe" il bootera quand meme, le coffre a clef lui sera ferme, un point c'est tout.
    -2)Il est impossible de signer un OS autrement que sur la machine meme. Le systeme de hashage de TCPA est extrement sensible au changement et a moins de posseder un ordinateur rigoureusement identique on ne peut pas creer de clef de hashage "transmissible" a une autre machine.
    -3)En mode extend (ie on hashe tout ce qui nous passe sous la main au boot) le moindre changement entrainne la fermeture du coffre a clef. Donc on se retrouve avec le bon vieux problemes "tout ce qui est crypte est perdu" au moindre changement de bios/periph/OS. Pas top du tout.

    *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é


    N'importe quoi bis. Le fait de dire que l'on peut integrer la puce TCPA a un autre composant (ie la placer dans le CPU ou dans l'horloge), ne veut absoluemnt pas dire que l'on puisse
    1-) devier en quoi que ce soit de la norme TCPA
    2-) Ajouter des fonctions de controle dans la puce
    3-) Permettre a la puisse d'interagir avec le processus de boot.

    La puce TCPA regarde ce qui se passe sur un bus et dialogue via un port serie vec l'utilisateur ou l'OS. Mais elle ne peut pas interagir avec le bus qu'elle surveille. De plus il est toujours impossible a une societe exterieure de signer un OS pour qu'il soit compatible avec l'ensemble des puces. Parceque
    1-) Il faut que le coffre a puce soit vide lors de la fabrication
    2-) Compte tenu de la versatilite des systemes aujourd'hui, la seule facon de creer une clef de hashage de boot est de la creer sur l'ordinateur meme, ou sur une copie conforme. On ne peut pas creer un logiciel (quel qu'il soit) qui soit de base certifie TCPA, signe pour le boot. C'est techniquement impossible.

    *info 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: 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.


    L'argument qui tue : c'est mal parcequ'il y a Microsoft dedans. Deja Microsoft est dans tout c'est sa politique, mettre du windows dans le moindre fer a repasser d'ici 2010.
    alors le trusted root (et non pas les roots of trust) est commun a l'ensemble des systemes de stockage de clefs privees, ou d'information confidentielles. C'est simplement le nom donne a une zone memoire, un repertoire, un fichier, un flux etc.. dont on connait tous les processus capables d'interagir. En d'autre termes un pertoire a la racine en chmod 7000 peut etre considere comme un trusted root.

    Pour ceux qui ne savent pas ce qu'est l'activation framework de XP il s'agit de recuperer par telephone ou par connection internet une clef qui va debloquer votre windows. Sans cette clef XP refuse de fonctionner passe un delai de 30 jours (je crois). Peut on repliquer ce comportement avec TCPA ? Non !
    Le but de l'activation framework d'XP est de verifier que vous vous etes enregistree vis a vis de Microsoft. C'est un principe tout bete de challenge/reponse. TCPA est capable d'etre challengee, mais pas d'initier un challenge. Elle est donc completement inutile dans ce systeme. Elle ne peut pas appeler Microsoft.

    sécurité et obscurité ne font pas bon ménage

    Information et obscurantisme non plus.

    Kha
    Lire les specs c'est bien, comprendre les specs c'est mieux.
    • [^] # Re: Demontage en regle

      Posté par  . Évalué à 2.

      Outre le fait que la EK ne soit pas du tout obligatoire cette clé unique est dans les specs, et IBM l'a intégré à ses puces actuelles ! que veux-tu de + ? Bien que ce risque ne soit pas nul, il est de tres loin inferieur a celui des numeros de serie chez Intel l'énorme différence est dans le fait que on ne peut pas falsifier cette clé même si on a le controle total des softs d'un ordinateur et des paquets internet qu'il envoit. Pour pouvoir décrypter rapidement un challenge encrypté avec la clé publique, IL FAUT posséder la clé privé et être donc le proprétaire de l'ordinateur TCPA en question. , je peut toujours sortir la clef du coffre depuis windows et la mettre a un endroit ou elle sera accessible depuis linux. j'aimerais bien que tu me dises comment tu fais cette migration, controlée par Windows et donc non disponible si Windows la refuse. Le philosophie et l'intéret de TCPA est que les clés sont générés dans la puce et n'en sortent jamais ! Les opérations de cryptage se ofnt à l'intérieur de la puce. Où as-tu vu dans les specs que on peut les faire sortir de la puce? Concernant le mode "extend" qui n'est pas nié par IBM, tu as oublié cette phrase: "could also prevent the use of “free” operating systems because the OS kernel would have to be signed by a entity which is a descendant of the trusted root" qui ne savent pas ce qu'est l'activation framework de XP dont tu fais partie sinon tu saurais que des modifications matérielles ou logicielles peuvent entrainer la désactivation de XP ! D'où le lien avec le roots of trust de TCPA et son controle de la configuration matérielle et logicielle.
      • [^] # Re: Demontage en regle

        Posté par  . Évalué à 1.

        l'énorme différence est dans le fait que on ne peut pas falsifier cette clé même si on a le controle total des softs d'un ordinateur et des paquets internet qu'il envoit. Pour pouvoir décrypter rapidement un challenge encrypté avec la clé publique, IL FAUT posséder la clé privé et être donc le proprétaire de l'ordinateur TCPA en question. C'est vrai que dans l'architecture intel on puvait changer le numero de serie du processeur. Elle est donc la la difference. Et puis un systeme d'authentification qui permet de m'authentifier c'est vraiment degeulasse. Au risque de me repeter la EK ne sert qu'a creer des certificats. Si quelqu'un m'envoit un paquet crypte selon ma EK (et je vois pas bien comment il ferait ca, mais bon), ma puce ne pourra pas le dechiffrer. La seule facon de se servir de la EK est la suivante. - 1) je cree un certificat - 2) j'envoit mon certificat a un organisme de validation - 3) Cet organisme s'assure par un principe de challenge/reponse que je suis bien le createur de ce certificat. - 4) Mon certificat est valide, l'organisme le charge pour confirmation. - 5) J'utilise mon certificat sur le net, si une personne veut verifier son authenticite elle est redirige vers l'organisme qui refait un challenge/reponse pour verifier que c'est bien la machine declaree qui s'en sert. J'en ai ras le bol de ce certificat, je peux le detruire. Ou en refaire un autre et me servir de celui la, ou ne jamais demander de certificat pour commencer, ou meme dans l'implementation IBM demander a ce que ce la EK ne soit pas activee. (soit parcequ'elle n'est pas presente, soit parceque je la desactive dans le bios.) j'aimerais bien que tu me dises comment tu fais cette migration, controlée par Windows et donc non disponible si Windows la refuse. Le philosophie et l'intéret de TCPA est que les clés sont générés dans la puce et n'en sortent jamais ! Les opérations de cryptage se ofnt à l'intérieur de la puce. Où as-tu vu dans les specs que on peut les faire sortir de la puce? Tu veux dire si windows bloque LOGICIELLEMENT l'acces a certaines fonctions TCPA. Ben comme tout le monde, j'attend le crack ou je le develloppe moi meme. Si windows a des droits, c'est que la puce a des droits. Si windows m'interdit d'ecrire sur le port de la puce parceque je ne suis pas une appli securisee, parce que ca ne lui plait pas, ou parcequ'il veut proteger des donnees, il est oblige de faire ca logiciellement. Donc il est oblige de proteger TCPA avec autre chose. Et la de deux choses l'une 1) soit sa protection logicielle est sans faille, je ne peut pas acceder a la puce. Mais a ce moment la pourquoi ne pas utiliser cette protection directement et se passer de la puce TCPA ? 2) soit sa protection est nulle, elle se fait casser et TCPA ne sert a rien. Une fois que je peux ecrire sur la puce j'ai exactement les memes droits que l'OS et les programmes. En ce qui concerne la migration des clefs, lors du precedent thread je t'avais deja renvoye vers le lien dans les specs TCPA, mais c'est pas grave on y retourne : Section 7.2.11,7.2.12,7.2.13 pages 171 a 177 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf la doc officielle TCPA. Tu remarqueras que ces fonctions sont "mandatory" ie obligatoire a toute implementation TCPA. Concernant le mode "extend" qui n'est pas nié par IBM, tu as oublié cette phrase: "could also prevent the use of “free” operating systems because the OS kernel would have to be signed by a entity which is a descendant of the trusted root" Non je n'ai pas oublie cette phrase. Revoyons la ensemble. Tout d'abord "could" en francais pourrait, a la difference de "can" en francais peut. Si TCPA avait le controle sur le boot (ce qui n'est pas le cas) et si TCPA etait fourni avec des clefs prechargees (ce qui est contraire au specs) et si le hashage du kernel etait previsible (ce qui est faux, meme un PCR qui hashe juste le kernel(la transition entre le mode reel et le mode protege) est dependant de la machine sur lequel il est execute), alors on pourrait vendre des puces TCPA qui empechent le boot si l'OS ne repond pas au critere de hashage du PCR. Bien entendu il faudrait aussi s'assurer que l'utilisateur ne puisse pas acceder du tout a ce PCR pour le modifier/ou en dupliquer les proprietes. Ce qui implique de retirer a l'utilisateur les droits sur le trusted root (il ne serait owner que d'une sous entite) et de lui enlever aussi les droits owner sur le SRK (il ne peut plus modifier/alterer/autoriser l'insertion,la suppression ou la migration de clef). Il faudrait de plus que toutes ces fonction soient codes dans la puce, pour eviter un hack logiciel. Bref si TCPA etait quelque chose de completement different reposant sur la technologie TPM ca pourrait etre vachement dangereux. Ben oui. Mais c'est pas le cas. dont tu fais partie sinon tu saurais que des modifications matérielles ou logicielles peuvent entrainer la désactivation de XP ! D'où le lien avec le roots of trust de TCPA et son controle de la configuration matérielle et logicielle. Au risque de me repeter encore le TRUSTED ROOT est un repertoire. Une zone memoire, un endroit pour mettre des donnees dedans, un file system. Bref un truc completement passif. La seule chose qui le differencie des autres zones memoires de ta machine est la certitude que seul le owner du trusted root peut lire/ecrire/effacer des donnees. C'est exactement comme le /root de ta becanne. Si t'es pas root et si le root ne t'a pas donnes de droits tu peux pas ecrire dedans. ET C'EST TOUT.Il ne controle rien, il ne regarde rien, il ne voit rien, il ne fait rien. C'est une zone memoire. Je supposerais donc que tu voulais parler du hashage du boot stoque dans un PCR. Et je te dirais une fois de plus que si MS fiche ces clefs la dedans, il suffit de les migrer ailleurs pour que tout baigne. Je n'est meme pas besoin que MS me redonne les clefs, je peux le faire tout seul... Kha
        • [^] # Re: Demontage en regle

          Posté par  . Évalué à 1.

          j'ai bien lu les pages 171 a 177 , et page 171 on peut lire qu'il est impossible de migrer les clés de type non-migratory (ce qui est logique !) je crois que tu confonds "roots of trust" et TRUSTED ROOT ... à propos de "extend" j'aime bien la notion de software certifié par son fournisseur (shipper): The TPM_Extend event is in response to loading a firmware or software component for which a VE certificate was available. *Event points to the VE certificate that shipped with the platform firmware or software (or discovered by other means). Size indicates the length of this structure. ExtendValue is the digest of the firmware, software or page 58 extend qui n'est pas désactivable: Note, however, that a disabled TPM never disables the "extend" capability. page 244
          • [^] # Re: Demontage en regle

            Posté par  . Évalué à 1.

            j'ai bien lu les pages 171 a 177 , et page 171 on peut lire qu'il est impossible de migrer les clés de type non-migratory (ce qui est logique !)

            Pas vraiment impossible (N.B tout l'argumentaire est base sur la section 7 du doc d'IBM):
            Migratory data may be copied to an arbitrary number of platforms, using the “migration” commands
            provided. Non-migratory data may be moved to another platform only with the cooperation of a third party
            (the manufacturer of the platform, or his representative), using the “maintenance” commands provided.

            Mais ce n'est pas obligatoire. L'option de maintenance n'est pas forcement implementee et de plus elle peut etre detruite sur une puce qui la possede (TPM_KillMaintenanceFeature). cependant ne jubile pas trop vite voici la suite :
            It must not be possible for the Owner of a key, even with the cooperation of the Owner of the TPM to migrate a non-migratable key from one platform to another. Since a key may be wrapped outside the TPM, it is necessary that non-migratable keys always be generated inside the TPM. It must not be possible for the Owner of a non-migratable asymmetric key, even with cooperation of the Owner of the TPM, to decrypt the contents of an encrypted bundle encrypted with that non-migratable asymmetric key.

            Donc voila le possesseur de la clef ne peut pas migrer la clef meme avec l'aide du possesseur du TPM, les seules clefs non migrables doivent etre des clefs generes en interne, et il ne doit pas etre possible de decrypter des infos encryptes avec ce type de clef assymetrique. En d'autres termes ces clefs ne sont utilisables que par le TPM lui meme. Impossible de faire un mode challenge/reponse pour tester leur presence. Pour ceux qui se demandent a quoi peut bien servir une clef qui est prisonniere a l'interieur d'une puce, qui ne peut pas en sortir et qui ne peut meme pas interagir avec l'exterieur ? Et bien elle sert a la puce pour chiffrer les donnees qui se trouvent a l'interieur de la puce. En d'autres termes je peux crypter avec une clef non migrable une zone memoire de ma puce. Par contre toutes les clefs qui doivent interagir avec l'exterieur (ie tout ce qui n'est pas strictement a l'interieur de la puce) doivent etre migrables.


            je crois que tu confonds "roots of trust" et TRUSTED ROOT ...
            Non pas vrament, disons juste que l'un des deux designe une fonctionalite de TCPA alors que l'autre n'est qu'une facon de parler. C'est a dire literallement des bases de confiances. C'est du pur conceptuel ca recouvre les fonctions que TCPA se doit d'apporter. A savoir une fiabilite au niveau des mesures et une fiabilite au niveau du stockage.


            à propos de "extend" j'aime bien la notion de software certifié par son fournisseur (shipper):
            Je supose que tu parle de ca :
            The TPM_Extend event is in response to loading a firmware or
            software component for which a VE certificate was available. *Event
            points to the VE certificate that shipped with the platform firmware or software (or discovered by other means). Size indicates the length of this structure. ExtendValue is the digest of the firmware, software or other code loaded. Certificates are much too large to put into the log in the Pre-OS environment. Validation of Certificates is unlikely in the Pre-OS environment. The event MUST point to a TCPA_EVENT_CERT structure.


            Il s'agit donc de certificats qui ont ete envoyes (shipped) avec le fimware et le software de la plateforme (ou qui ont ete decouvert par d'autres moyen). Cela veut-il dire que MS va bientot sortir avec son nouvel OS le pack VE certificate-sinon-ca-marche-pas ? Non ca veut juste dire que le mec qui a monte mon PC (et eventuellement installe mon PC) peu eventuellement creer au passage des certificats. Ce ne sont pas des certificats generiques, mais des certificats crees au cas par cas sur les machines. Ces certificats, comme tout certificats PCR servent juste a s'assure que la sequence de boot n'a pas changee.



            apprend a citer en entier, ca me ferait gagner pas mal de temps.
            Note, however, that a disabled TPM never disables the “extend” capability. This is necessary in order to ensure that the PCR values in a TPM are always up-to-date.
            Faisons un raisonement par l'absurde en supposant que l'on puisse eteindre le "extend" : si cette capacite est mise a off alors que je suis dans un PCR x, que je reboote et que une fois l'OS charge je reactive le TPM, vu qu'il n'y a pas eu de nouveau hashage au boot (vu que la capacite etait desactivee) je me retrouve donc avec mon derneir PCR enregistre dans ma puce meme si entre la desactivation et la reactivation du TPM j'ai completement change ma machine. Le PCR ne servirait donc plus a rien vu qu'il suffirait de deux manips pour faire croire a la puce qu'elle est dans un PCR alors que c'est faux. Par contre j'ai un peu de mal a voir en quoi ca te pose un probleme ?

            Kha
            • [^] # Re: Demontage en regle

              Posté par  . Évalué à 1.

              The creator of the key can prevent migration by the User by wrapping it with a non-migratable storage key
              and loading random data for the MigrationAuthorizationData.
              page 164

              Dans tous tes commentaires tu sembles supposer que le "owner" du TPM est forcément le possesseur de la mcahine, alors que les specs n'interdisent pas à un OS comme Windows d'être ce owner. D'ailleurs si les applications DRM de Win exigent que Win soit owner, on devra laisser owner à Win pour pouvoir utiliser ces applications.

              Pour roots of trust je te conseille de relire le début du PDF des specs...

              Pourquoi t'entêtes-tu alors que le site officiel TCPA possede des documents affirmant haut et fort que le but est bien de permettre à un fournisseur de contenu distant d'identifier les logiciels de ta machine afin de choisir s'il décide de faire confiance ou non à ton OS (grace aux checksums de l'OS par TCPA créés lors du boot):

              For example, before making content available to a remote user, it is likely that a provider
              will need to know that the remote platform is trustworthy. The provider's platform (the
              "challenger") queries the remote platform. During system boot, the challenged platform
              creates a series of cryptographic digests (integrity metrics) that represent the method
              used to build the software environment in the challenged platform. These digests are
              statistically unique indications of the platform environment, yet they will occur in all
              platforms with the same software environment.
              When it receives the query from the challenger, the remote platform responds by digitally
              signing and then sending the integrity metrics. The digital signature prevents tampering
              Page 2
              and allows the challenger to verify the signature. If the signature is verified, the
              challenger can then determine whether the identity metrics are trustworthy. If so, the
              challenger, in this case the service provider, can then deliver the content. The TCPA
              system reports the metrics and lets the challenger make the final decision regarding the
              trustworthiness of the remote platform. Based upon the reported integrity metrics, the
              challenger can determine if the platform is configured in a trusted state.
              http://www.google.fr/search?q=cache:YDeLgyHUXDoC:www.trustedcomputi(...)
              • [^] # Re: Demontage en regle

                Posté par  . Évalué à 0.

                Je m'entete parceque tu lis les specs de travers. Que ce que tu decris est completement irrealisable en l'etat avec TCPA, que je te l'ai deja demontre 10 fois et que tu continue a poster ton doc dans tous les sens alors qu'il est a peu pres aussi faux que possible.

                The creator of the key can prevent migration by the User by wrapping it with a non-migratable storage key and loading random data for the MigrationAuthorizationData.

                Je ne vois pas ce que ca a faire avec le fait que
                1) seules les clefs generes par le TPM peuvent etre passees en non migrables
                2) Une fois qu'une clef est non migrable elle ne peut plus etre utilisee que par la puce.

                Le mecansime que tu decris est ce qui se passe quand le createur de la clef donne des droits a un utilisateur sur une clef sans pour autant lui donner la clef en elle meme.
                Grosso modo je cree un repertoire, je pose ma clef dedans, je donne les droits sur ma clef a un utilisateur et je crypte mon repertoire avec une clef non migrable.
                Cependant toutes les entites parentes de ce repertoire ont les droits sur ce repertoire et peuvent migrer ma clef si ca les amuse et si le possesseur du TPM donne son feu vert.

                Dans tous tes commentaires tu sembles supposer que le "owner" du TPM est forcément le possesseur de la mcahine, alors que les specs n'interdisent pas à un OS comme Windows d'être ce owner. D'ailleurs si les applications DRM de Win exigent que Win soit owner, on devra laisser owner à Win pour pouvoir utiliser ces applications.


                N'importe quoi en folie ! Bien que la puce TCPA soit relativement evoluee, si windows a les droits en owner sur le TPM ou sur le SRK alors je les ai aussi. On dialogue avec le TPM via un port serie pour se loguer en tant que owner TPM ou SRK il faut connaitre le mot de passe. Alors de deux choses l'une : soit tous les TPM et tous les SRK de toutes les puces TCPA ont le meme mot de passe (et la bravo pour la securite) soit les puces sont initialises avec des mots de passe different et windows ne peut pas le deviner (2048 bits a casser ca prend du temps). Et donc le brave windows pour pouvoir utiliser les fonctions TCPA il est oblige de me demander le mot de passe. Et la le plus beau c'est qu'il n'a aucun moyen de savoir si je lui donne les bons. Il n'y a pas de verification possible. Il est assez facile de savoir si on est vraiment le TPM owner ou pas, mais il est impossible de savoir si on a acces au SRK ou a un sous repertoire, donc ton programme qui exige le ownership il va avoir du mal. A noter en plus que toutes ces protections (dans le cas ou on ne met pas exactement le meme mot de passe sur toutes les puces) doivent se faire en logiciel, comme la securite d'un systeme est egale a la securite du plus faible de ses maillons, on a une securite de niveau logiciel et donc TCPA n'aide pas.

                Pourquoi t'entêtes-tu alors que le site officiel TCPA possede des documents affirmant haut et fort que le but est bien de permettre à un fournisseur de contenu distant d'identifier les logiciels de ta machine afin de choisir s'il décide de faire confiance ou non à ton OS (grace aux checksums de l'OS par TCPA créés lors du boot):

                C'est bien mon petit, maintenant apprend l'anglais et relit ta citation . C'est bon tu vois le probleme ? Non ? Bon je t'aide :

                These digests are statistically unique indications of the platform environment, yet they will occur in all platforms with the same software environment.
                Based upon the reported integrity metrics, the challenger can determine if the platform is configured in a trusted state.

                Ca ne permet pas d'identifier le software, ca permet juste de verifier que le systeme est bien celui que l'on connait et a qui on fait confiance. Mais il est impossible de savoir ce que c'est. C'est le principe du MD5, avec tu peux savoir que le fichier que tu as telecharge a cote contient bien les bonnes donnees. Mais tu ne peut pas telecharger juste le MD5 et en deduire le fichier original. De la meme facon impossible d'utiliser un DIR ou un PCR pour identtifier un logiciel.

                Kha
                • [^] # Re: Demontage en regle

                  Posté par  . Évalué à 1.

                  à chaque procédure de prise d'ownership (suite à un reset), il est créeé
                  un nouveau token qui à lui seul suffit à s'identifier comme owner !
                  Si Win contient un soft de prise d'ownership, il peut s'emparer une fois la prise terminée de ce token ,et il pourra comme tu le dis si bien s'assurer qu'il est le owner.
                  page 3 de
                  http://www.trustedcomputing.org/docs/TCPA_security_policy_v0_45.pdf(...)
                  The TPM ownership token provides proof of TPM ownership. The creation of the token
                  occurs when the owner completes the ownership protocol. The value is stored in a shielded
                  location inside of the TPM. The administrator provides this token to access administrator
                  functionality, including system configuration.

                  page 6
                  applications authorized to perform the Administrator role have knowledge of the TPM
                  authentication token.

                  Maintenant relis ta citation de ma citation. Tu vois le problème ?
                  Bon je t'aide:
                  yet they [the same digests] will occur in all platforms with the same software environment.

                  Cela veut dire que le digest de l'OS booté qui est stocké dans TCPA sera toujours les meme chez toutes les personnes qui utilisent le meme OS. Cela suffit largement à identifier ton OS à l'aide d'un challenge encrypté par ta puce TCPA !


                  sinon, KHA c'est un pseudonyme pour IBM ? :)
                  • [^] # Re: Demontage en regle

                    Posté par  . Évalué à 1.

                    à chaque procédure de prise d'ownership (suite à un reset), il est créeé un nouveau token qui à lui seul suffit à s'identifier comme owner!
                    Si Win contient un soft de prise d'ownership, il peut s'emparer une fois la prise terminée de ce token ,et il pourra comme tu le dis si bien s'assurer qu'il est le owner.


                    Seul tout petit probleme dans ton raisonement : On ne peut faire un reset que si il y a preuve de presence physique. Cette preuve ne peut etre assuree qu'avant le chargement de l'OS. Pas evident pour Windows de prendre le ownership avant meme de s'etre lance non ?

                    Hence the method of enabling or disabling the process of taking ownership is a local command, and no remote option is provided. (In a PC, these local controls could be made available during the POST, for example.) (section 2.6.1)

                    De plus si il existait un moyen logiciel de prendre le controle d'une puce TCPA (ie TPM+SRK), ca serait assez mauvais non ?
                    Pour finir le owner du TPM n'a aucun pouvoir, il peut authoriser ou interdire des operations, mais il ne peut pas les executer. Pour pouvoir faire quoi que ce soit avec une puce TPM il faut etre owner d'une entite (ie d'un sous repertoire) ou du SRK (ie la racine). Et c'est a ce niveau la que tu n'as pas de moyen de verif. Tu ne peux pas savoir si tu es a la racine ou dans un reprtoire en dessous.

                    La section 10.17.1 explique aussi comment recuperer le ownership complet en prouvant qu'il y a presence physique. Donc basiquement comment recuperer l'acces a l'ensemble des infos contenues dans le TPM. (toujours avant le boot de l'OS).
                    applications authorized to perform the Administrator role have knowledge of the TPM authentication token.
                    Tout a fait logique, vu que le owner du TPM est le seul a pouvoir autoriser pas mal d'operations. Mais ce n'est pas pour autant que cet appli va pouvoir me voler le ownership de TPM...

                    yet they [the same digests] will occur in all platforms with the same software environment.

                    Ourch flagrant delit de traffic d'informations et de falsification de preuves :
                    La citation exacte est :

                    These digests are statistically unique indications of the platform environment, yet they will occur in all platforms with the same software environment.

                    donc "they" ne designe pas "the ??same?? digests" mais "the digests [that] are statistically unique indications of the platform environment" . Sans commentaire hein ?

                    sinon, KHA c'est un pseudonyme pour IBM ? :)
                    Ca serait plus facile dans ce cas la c'est ca. C'est clair que si je bossais chez IBM tous les arguments que j'avance seraient faux...C'est sur qu'un mec qui defend TCPA ca ne peut pas etre un mec qui croit en ce produit, ca doit juste etre un commercial quelconque pret a vendre son ame pour que TCPA se repande ...

                    Ben non, je bosse pas chez IBM, je ne bosse meme pas avec IBM, et a dire la verite je ne suis meme pas fan de TCPA. Seulement le truc qui m'ennui dans ce que tu dis c'est que c'est bourre de fautes d'anneries et d'imprecisions. Je comprend ton desir de defendre le libre, mais ca ne veut pas dire que j'approuve ta methode. Le papier que tu brandis sur ton site est faux, et n'importe qui peut le demolir en 30 secondes. C'est un vrai probleme, meme un papier parfaitement intelligent qui contient une ou deux anneries est discredite. Alors un papier qui ne contient que ca (anneries=erreurs imprecisions et speculations) sert plus la cause adverse qu'autre chose.

                    Ca fait un petit moment que je suis sur TCPA et que je pese le pour et le contre. Pour l'instant je ne suis toujours pas vraiment convaincu. Le nombre de choses que ca peut apporter est ennorme, mais le nombre de facon qu'il y a d'interagir avec la puce est trop grand. Pour l'instant je n'ai pas vu de failles dans le systeme, ni de facon de retourner un TPM contre son possesseur, mais faire un graph de tous les etats possibles prendrait un temps monstrueux donc je ne suis pas sur qu'il n'y est pas un moyen. Et je continue de chercher. Mais pour l'instant TCPA me parait innoffensif pour l'utilisateur.


                    Kha
                    • [^] # Re: Demontage en regle

                      Posté par  . Évalué à 1.

                      Apparemment tu sais tout mieux que les documents du site officiel TCPA:
                      je maintiens fermement que la phrase:
                      "yet they will occur in all platforms with the same software environment."
                      signifie que les palteformes ayant le meme OS auront le meme digest

                      Sinon peux-tu me dire pourquoi les gens de TCPA se sont donnés la peine de rédiger cette phrase dans ce document ?

                      Moi je peux te le dire: pour les rédacteurs de ce document, l'identification sans faille de l'OS est un argument de vente de TCPA à toutes les sociétés avides de DRM, et elles sont nombreuses !

                      Comme tu le suggère fort justement, il est quasiment impossible d'imaginer toutes les utilisations possible de TCPA, d'autant plus que la spec 1.2 n'est toujours pas accessible au public, meme si les ajouts qui ont filtrés sont très liés au DRM (vérification de la date/heure par la puce, compteurs infasilfiables, ...).
                      Pour ma part j'explique sur ma page qu'il est facile d'utiliser une puce permettant d'identifier un OS, pour s'assurer qu'un OS contient bien la notion de trusted sandbox chère à palladium.

                      PS: tu oublies systématiquement de traduire le mot "same", il te pose un problème ?
                      • [^] # Re: Demontage en regle

                        Posté par  . Évalué à 0.

                        "yet they will occur in all platforms with the same software environment."
                        signifie que les palteformes ayant le meme OS auront le meme digest


                        Et non signifie que toutes les plateformes qui font tourner ce logiciel auront un digest pour ce logiciel. Et c'est tout. On peut lire sur le morceau de phrase que tu refuse de citer que ce diggest est dependant de la plateforme.

                        Sinon peux-tu me dire pourquoi les gens de TCPA se sont donnés la peine de rédiger cette phrase dans ce document ?

                        pour leur demontrer que l'on peut non seulement authentifier le hardware mais aussi le software qui tourne dessus (donc que l'on est dans une configuration connue et consideree comme fiable)

                        PS: tu oublies systématiquement de traduire le mot "same", il te pose un problème ?

                        Ben vu que je n'ai pas du tout traduit ce paragraphe dans aucun de mes posts precedents on ne peut pas vraiment parler d'omission. mais bon puisque que tu le demande voici la traduction de ton extrait de phrase

                        "mais ils se produiront sur toutes les plateformes qui feront tourner le meme environement logiciel".

                        Alors bien entendu on se demande ce qui peut bien se produire vu qu'on a qu'un morceau de phrase denue de sens. Donc on fait une citation complete :

                        "Ces rapports sont des indications statistiquement uniques du systeme de la plateforme, mais ils se produiront sur toutes les plateformes qui feront tourner le meme environement logiciel".


                        Kha
                        • [^] # Re: Demontage en regle

                          Posté par  . Évalué à 1.

                          "Ces rapports sont des indications statistiquement uniques du systeme de la plateforme, mais ils se produiront sur toutes les plateformes qui feront tourner le meme environement logiciel".
                          Mais quel est l'intéret de cette phrase pour un fournisseur de contenu distant avec qui je communique ? (c'est le contexte du document que j'ai cité)
                          Aucun, sauf si cela lui permet de s'assurer que mon OS est bien compatible DRM !

                          Dans tous tes commentaires précédents tu supposes aussi que le BIOS est du coté de l'utilisateur, pas du coté de Windows. Le bios pourrait notamment intercepter le token Owner et le refiler à Windows, si l'OS est bien signé avec une clé privée correspondant à celle publique qui est stockée dans le bios.

                          Enfin tu as suggéré qu'il y a des "bonnes" applications de TCPA: lesquelles ne sont pas faisables avec des solutions software pures comme les softs libres dont je parle dans mon article ?
        • [^] # Re: Demontage en regle

          Posté par  . Évalué à 2.


          Tu veux dire si windows bloque LOGICIELLEMENT l'acces a certaines fonctions TCPA. Ben comme tout le monde, j'attend le crack ou je le develloppe moi meme. Si windows a des droits, c'est que la puce a des droits. Si windows m'interdit d'ecrire sur le port de la puce parceque je ne suis pas une appli securisee, parce que ca ne lui plait pas, ou parcequ'il veut proteger des donnees, il est oblige de faire ca logiciellement. Donc il est oblige de proteger TCPA avec autre chose. Et la de deux choses l'une
          1) soit sa protection logicielle est sans faille, je ne peut pas acceder a la puce. Mais a ce moment la pourquoi ne pas utiliser cette protection directement et se passer de la puce TCPA ?
          2) soit sa protection est nulle, elle se fait casser et TCPA ne sert a rien. Une fois que je peux ecrire sur la puce j'ai exactement les memes droits que l'OS et les programmes.


          Cette alternative est bancale. Cela rejoint un autre echange qu'on a eu dans une autre news, lorsque je voulais prouver qu'on peut implementer la partie soft de palladium, a l'aide de la spec TCPA actuelle.

          Je detaille. Tu consideres inutile que windows bloque de facon logicielle des fonctions TCPA. Si le noyau windows a des trous de securites, c'est effectivement domage pour eux car on peut les utiliser pour acceder aux fonctions TCPA que windows veut nous cacher (Et c'est pour ca que palladium ne peut pas se satisfaire de la spec TCPA, en l'etat)

          Mais si le noyau windows n'a pas de trou de securite, il garantit que certaines fonctions TCPA (et donc certaines cles) sont inaccessibles de l'exterieur.

          Alors que si windows n'utilise pas TCPA --- et meme s'il est parfait ---, je peux toujours l'executer dans un emulateur (genre bloch) et sniffer tout ce qu'il fait. Il n'a aucun moyen de me cacher des cles (meme si l'effort pour executer windows pas a pas est monstrueux)
          • [^] # Re: Demontage en regle

            Posté par  . Évalué à 1.

            Ok je viens de comprendre ce que tu voulais dire la derniere fois.
            Donc si je reprend Microsoft me file une clef via une appli proprietaire(ie je ne vois jamais la clef) et la place dans un PCR (pour eviter que j'ai acces a cette clef depuis une autre sequence de boot). De plus il me bloque les fonctions TPM qui me permettrait de deplacer ou de copier cette clef ailleurs. Et pour finir l'OS est construit de telle facon que je ne puisse pas ecrire un driver TPM qui contourne ce probleme.

            Je pense que j'ai du resumer ce que tu voulais dire non ?

            En theorie il est quand meme possible de recuperer cette clef avec la fonction TPM_Backup depuis un autre OS. Je possederais donc une copie utilisable par un autre TPM, par contre je ne pourrais pas faire un UNSEAL des donnees depuis mon propre TPM, je serais oblige de passer par un autre TPM (ie dans ce cas il me faut deux machines avec TCPA, une avec les infos en scelle dans le PCR depuis laquelle je fait mon BACKUP et l'autre qui va recevoir les infos mais qui va pouvoir les decrypter hors du PCR).

            De plus la mise en place de ce systeme implique de couper l'ensemble des droits de l'utilisateur sur sa propre puce, ca se voit. Ca pose plus la question de savoir si il faut boycotter Windows ou TCPA. C'est plus une question du driver et de l'usage qui est fait de ce driver. Il est clair que windows ne peut pas initialiser une puce TCPA et a donc besoin de l'accord de l'utilisateur pour le faire, ce qui aurait tendance a donner plus de pouvoir a l'utilisateur qu'a l'applicatif(ie windows a beson de l'utilisateur pour se servir de TCPA). Peut-on imaginer un systeme ou windows m'enleve les droits Owner ? non difficilement, mais il peut c'est vrai m'empecher logiciellement de m'en servir a ma guise.

            On a effectivement a faire ici a un vrai probleme, bien que ce ne soit que de la speculation on peut imaginer un driver TCPA aux ordres de l'OS et non de l'utilisateur, et ca ce serait extremement dangereux. Il est donc important de s'assurer que l'OS ne retire pas de droits ou ne bloque pas de droits a l'utilisateur.(Et ca c'es hors des specs de la puce, donc techniquement pas moyen de verifier si c'est autorise ou non)

            Kha
            • [^] # Re: Demontage en regle

              Posté par  . Évalué à 1.

              " Ca pose plus la question de savoir si il faut boycotter Windows ou TCPA. "

              La réponse à ta question est simple: aujourdh'ui il est bien plus facile de boycotter TCPA (toutes les "bonnes" fonctions de TCPA ont leur équivalent en software pur) que de boycotter Windows (ce qui implique de nombreux logiciels et documents utilisables que sous Windows.

              Maintenant que tu sais, toi aussi, qu'il faut décourager l'adoption de TCPA:
              BIENVENUE AU CLUB :)
              • [^] # Re: Demontage en regle

                Posté par  . Évalué à 1.

                Maintenant que tu sais, toi aussi, qu'il faut décourager l'adoption de TCPA:
                BIENVENUE AU CLUB :)


                Je suis pas encore vraiment convaincu. Mais je susi en train de faire des simulations avec une idee que je n'avais pas encore exploree et je dois reconnaitre que ca me fait un peu peur.

                La suite au prochain episode.

                Par contre independamment de ma position vis a vis de TCPA je maintien que tes arguments (et le papier qui les ennonce) ne sont pas valables et assez facilements demontables.


                Kha
                • [^] # Re: Demontage en regle

                  Posté par  . Évalué à 1.

                  Mon papier est en constante amélioration. Cependant les messages postés ici sur linuxfr ont bien montré qu'il était possible d'utiliser le PCR pour faire du controle de type DRM, ce qui est quand même la base du problème posé par TCPA !

                  PS: tu peux nous faire part de ton idée, on peut t'aider avec plaisir !
                  • [^] # Re: Demontage en regle

                    Posté par  . Évalué à 1.

                    Cependant les messages postés ici sur linuxfr ont bien montré qu'il était possible d'utiliser le PCR pour faire du controle de type DRM

                    C'est justement ca qui m'ennuit, je ne sais pas si c'est possible, mais je ne pense pas que tu connaisses de methodes qui permette d'utiliser TCPA pour faire du DRM. N'oublie pas que
                    -Toute clef qui est migrable peut etre recupere independament du fait qu'elle appartienne a un TPM ou pas
                    -Toute clef qui interagit avec l'exterieur est miggrable.

                    Pas evident du faire du DRM avec ca, le risque que des petits malins sortent les clefs et les duplique sur d'autres TPM (voir meme les revellent en clair) est trop grand.

                    Kha
                    • [^] # Re: Demontage en regle

                      Posté par  . Évalué à 1.

                      reste à prendre en compte que:
                      - les clés de cryptage seront différentes sur chaque machine: les rendre publique ne servira à rien
                      - tout le monde n'aura pas 2 TPM pour faire des manipes
                      - les connexions permanentes à Internet couplées avec le mécansime d'idnetification d'OS à distance suffisent à ce que les clés de crypto ne soient pas stockées du tout dans ton ordinateur: elles sont envoyées à chaque fois par internet par le fournisseur de contenu (elles-meme cryptées par des clés jetables)

                      - un BIOS vicieux pourrait faire ceci: détection d' un OS loader encrypté de MS. Décryptage à la volé de cet OS loader qui contient de clés de cryptage seules connues de MS. Utilistion de ces clés en conjonction avec les informations de boot TCPA garantissant que le premier OS booté est bien un OS MS, pour crypter des fichiers en ayant la certitude qu'ils ne seront pas lisibles par un autre OS.
                      • [^] # Re: Demontage en regle

                        Posté par  . Évalué à 1.

                        les clés de cryptage seront différentes sur chaque machine: les rendre publique ne servira à rien
                        Par rendre publique je voulais dire deplacer dans une entite independante du PCR.

                        tout le monde n'aura pas 2 TPM pour faire des manipes
                        Ben en fait si a peu de chose pres. Pour que ce genre d'operation serve a quelque chose il faut que tout les ordis soient equipes. Donc on risque de voir fleurir des PC avec TCPA partout.

                        les connexions permanentes à Internet couplées avec le mécansime d'identification d'OS à distance suffisent à ce que les clés de crypto ne soient pas stockées du tout dans ton ordinateur:
                        Et vu que TCPA est un coffre a clef et qu'il ne permet pas d'identifier un OS, en quoi est il mele a tout ca ?

                        un BIOS vicieux pourrait faire ceci: détection d' un OS loader encrypté de MS. Décryptage à la volé de cet OS loader qui contient de clés de cryptage seules connues de MS. Utilistion de ces clés en conjonction avec les informations de boot TCPA garantissant que le premier OS booté est bien un OS MS, pour crypter des fichiers en ayant la certitude qu'ils ne seront pas lisibles par un autre OS. Il est deja capable d'identifier un OS Loader, de le decrypter tout seul. Je suppose que ton OS Loader n'est pas sur le MBR mais sur la partition ammorcee (Donc techniquement on est deja apres loin du POST), le decrypter a ce moment la assure au bios que l'OS qui va etre boote est bien Windows. Dans le cas ou ton OS loader est sur le MBR alors on ne peut booter que Windows (le fait de faire du multiboot changerait surement la signature de l'OS Loader).
                        Donc un bios qui sait faire tout ca, il n'a pas besoin de TCPA pour bloquer des infos aux autres OS eventuellement installes sur la machine.


                        Kha
                        • [^] # Re: Demontage en regle

                          Posté par  . Évalué à 1.

                          voir mes autres réponses sur l'identification de l'OS loader par le BIOS qui est obligatoire dans TCPA, et un hash doit etre stocké dans le PCR.

                          tiens au fait il y a une faille (une de +) dans ton histoire de BACKUP:
                          pourquoi utiliser 2 TPM si il est vrai que le blob de backup est crypté par une clé que l'on fournit ? Pas besoin de 2e TPM pour décrypter des algos standards comme RSA.

                          Je crois plutot que la clé DOIT etre authentifiable comme provenant d'un autre TPM.
                          Seul cet autre TPM pourra utiliser le blob de backup. Et il aura tout loisir de bloquer l'accès aux clés en utilisant le meme PCR. Tou ça n'étant possible que si le BIOS coopère avec luitilsiateur, alors que les spesc TCPA prévoient plutot que le BIOS coopère avec les applications DRM !
          • [^] # Re: Demontage en regle

            Posté par  . Évalué à 1.

            Une première question pour toi et KHA: en quoi le fait que Windows bloque l'accès à TCPA quand je suis sous Win m'empeche-t-il d'utiliser le BIOS ou un autre OS pour manipuler les clés que Win a stocké dans TCPA ?

            2e question pour Thoran: peux-tu me rappeler quelle est ta vision de l'utilisation de TCPA par un Palladium soft ? Je propose justement une solution soft simple sur ma page web remise à jour: http://free2.org/tcpa/(...)
            (merci de me signaler d'autres erreurs sur cette nouvelle version de ma page)
            • [^] # Re: Demontage en regle

              Posté par  . Évalué à 1.

              Je réponds moi-meme en partie à la premiere question: Windows utilise un PCR pour sceller les clés qu'il veut cacher, et le driver TCPA de Windows n'autorise pas l'accès à ces clés.
              Sous un autre OS je ne peux pas accéder directement à ces clés car le PCR est différent.

              Reste le probleme de l'accès indirect via des fonctions de déplacement des clés: dans nos discussions KHA a soutenu très fort, contre moi, que il était possible de déplacer toutes les clés (et donc toutes les clés protégées par un PCR sous un autre OS). Voulez-vous bien me confirmer que c'était une erreur et que les clés protégées par un PCR ne sont pas déplacables sous un autre OS (à moins d'utiliser la manipe BACKUP de Kha, dont je ne comprends pas pourquoi le 2e TPM me donnerait à l'accès au données protégées par PCR sous un autre OS).

              Pour la 2e question, je viens de lire Thoran dire que le noyau Win ne doit pas contenir de bug: en utilisant des techniques de micro-noyau (Hurd/Mach) ou de virtualiseur (virtualPC, plex86, UserModeLinux) il est possible de booter un OS très simple (et donc moins sujet à des bugs critiques) qui ne sert qu'à exécuter d'autres OS compartimentés et donc protégés les uns des autres (sandboxs)
              • [^] # Re: Demontage en regle

                Posté par  . Évalué à 2.

                Nous parlons tous les deux de la meme chose. Ce que j'avais ajoute, lors de la news precedente, c'est une robustesse du schema vis a vis des upgrades systemes: Tous les trucs Palladium critiques sont encryptes avec de la crypto symetrique dont la cle est calculee par Microsoft en fonction du numero de licence (lors de la phase d'activation). Cette cle est scelle grace au PCR. En cas d'upgrade, on perd cette cle. Mais comme de toute facon il faut se reenregistrer, microsoft la redonne a ce moment la.

                Ce schema suppose deux choses, en fait:
                1) Que Microsoft puisse etre sur que windows est integre et ne s'execute pas dans un emulateur genre "bloch" (au moment de la phase d'activation). J'avoue que je ne comprends pas encore bien si cela est possible. Mais a defaut de comprendre la spec TCPA a la lettre, l'esprit dit (section 2.2 page 2) qu'une entite peut decider si une plateforme est dans un etat acceptable, ou pas. D'un autre cote, Kha dit que le "peer" ne peut pas voir la config, mais seulement un hash de la config. Il faut trancher cette question.
                2) Que le noyau (ou micro-noyeau) n'aie pas de failles. Je ne regarde pas bugtraq mais juste la debian-security mailing list. Jusqu'a present, je n'ai jamais vu passer de mise a jour noyau pour cause de trou de securite, meme si je pense qu'il doit y en avoir. 99% des mises a jour concernent des programmes userland. J'en deduis qu'il n'est pas si difficile que ca d'avoir un noyau a peu pres sur. Tout ce qu'il faut, c'est empecher aux programmes userland de passer en ring 0 (il y a un appel systeme pour ca). A part XFree86 (et encore), je crois que personne n'a besoin de ce truc. Donc, ce deuxieme point me parait assez facile a garantir.
                • [^] # Re: Demontage en regle

                  Posté par  . Évalué à 1.

                  Que Microsoft puisse etre sur que windows est integre et ne s'execute pas dans un emulateur genre "bloch" (au moment de la phase d'activation).
                  je crois que les digests enregistrés dans la puce TCPA au moment du boot sont fait pour ça: à tout moment on peut avoir la signature de l'OS qui a été booté directement par le BIOS: c'est donc forcément lui l'OS master de la machine. Si sa signature correspond à une signature connue de Win, alors c'est Win l'OS master de la machine, et il ne s'exécute pas d'un virtualiseur.

                  D'un autre cote, Kha dit que le "peer" ne peut pas voir la config, mais seulement un hash de la config. Il faut trancher cette question.
                  D'après ce que j'ai compris le hash de la config est détaillé:
                  il y a un hash pour le matériel, un hash pour le BIOS, et un hash pour l'OS
                  en comparant le hash de l'OS avec les hash des versions officielles de Win, on peut savoir si l'OS booté par le BIOS est bien Win.
                  • [^] # Re: Demontage en regle

                    Posté par  . Évalué à 2.

                    en comparant le hash de l'OS avec les hash des versions officielles de Win, on peut savoir si l'OS booté par le BIOS est bien Win.

                    Seul petit probleme, ca sous entend que ton windows va booter de la meme facon sur toutes les plateformes. Ce qui est faux (heureusement).
                    Meme si chaque OS a une facon caracteristique de booter, il est oblige de s'adapter a la plateforme sur laquelle il se trouve. Le boot du meme OS sur une plateforme VIA/ATHLON va etre tres different du boot sur une plateforme INTEL/PIV. Bien qu'au final les fonctionnalites soient les memes, les puces ne vont pas reagir pareil et les informations sur les bus vont varier. D'apres les specs TCPA, on considere que tout ce qui se passe apres le POST du bios est du fait de l'OS, ca laisse ennormement de chose a mesurer. C'est pour ca aussi que les mesures sont statistiquements dependante de la plateforme.

                    Kha
                    • [^] # Re: Demontage en regle

                      Posté par  . Évalué à 0.

                      rien n'empeche de faire booter par le BIOS un petit programme que nous appellerons OS loader, petit programme dont le digest sera toujours le meme et donc facilement identifaiable. Une particularité cependant, ce programme refusera de lancer autre chose qu'un OS dument signé par MS.

                      et voila, DRM !
                      • [^] # Re: Demontage en regle

                        Posté par  . Évalué à -1.

                        Je crois que tu ne lis pas les messages auxquels tu réponds.
                        • [^] # Re: Demontage en regle

                          Posté par  . Évalué à 1.

                          tu peux être un peu plus clair STP ?
                          paske là j'ai envie de te dire: je crois que tu ne comprends pas ce que je dis !

                          je dis que dans TCPA, après le boot, il y a la possibilité d'obtenir plusieurs signatures (digest) dont celle du programme auquel le BIOS a donné la main en premier au moment du boot. Cette signature , dans le cas d'un petit OS loader dont je parle, ne changera pas et ne dépendera pas de la config matérielle. D'où la possibilité d'identifier facilement un OS loader agréé par MS.

                          Tu avais compris ça ?
                          • [^] # Re: Demontage en regle

                            Posté par  . Évalué à 1.

                            Techniquement impossible,

                            1) ton OS Loader aussi basique soit-il devra quand meme initialiser le disque, recuperer les interrupts du bios, initialiser la memoire et eventuellement passer en mode reel. Toutes ces operations sont des operations dependante du hardware.

                            2) Si comme il est suggere par la doc, on considere que l'OS prend la main apres le POST, alors les evenements de type amorcage du MBR sont des evenements attribues a l'OS.

                            3) Windows va quand meme devoir rerecuperer les interrupts du bios glannees par l'OS loader et initialiser les periph en fonction de ses drivers, et en ce qui concerne les periphs systemes (la clock, le gestionnaire d'interrupts, les bridges (Ok ponts ) etc...) cela ne sera pas considere comme des evenements PCI ou ISA, donc non attribuables a autre chose dans le hashage qu'a l'OS

                            kha
                            • [^] # Re: Demontage en regle

                              Posté par  . Évalué à 1.

                              On ne se compred pas bien.
                              Le BIOS a la possibilité de stocker dans le TPM des informations concernant l'OS loader à qui il donnera la main. Mais le contenu de ces informations est laissé à la discrétion du BIOS ! Donc le BIOS peut tout a fait faire un digest RSA du petit excutable que constutue l'OS loader. Si l'OS loader de MS est bien fait, il aura toujours la meme signature quelque soit la version de l'OS MS qu'il boote ensuite.
                              D'où la possibilité ensuite pour un fournisseur de contenu distant de savoir si on utiliser Windows ou non.
                              • [^] # Re: Demontage en regle

                                Posté par  . Évalué à 1.

                                Une fois de plus dans ce cas la c'est le bios qui fait le boulot. C'est le bios qui fait le digest de l'os loader (si c'est la puce TCPA qui le fait on est sur qu'il sera different suivant les plateformes). Et c'est ensuite le bios qui decide en fonction de la sequnce de boot si il doit reveler ses informations ou non. En d'autres termes le bios devient capable d'implementer DRM sans TCPA. Donc oui dans ce cas on a un PC DRM, non ce n'est pas grace ou a cause de TCPA.


                                Kha
                                • [^] # Re: Demontage en regle

                                  Posté par  . Évalué à 1.

                                  désolé, mais c'est la norm TCPA qui prévoit que les BIOS devront réaliser un digest de l'OS loader

                                  par conséquent c'est al norme TCPA qui va obliger les BIOS à devenir des outils de DRM !
                                  • [^] # Re: Demontage en regle

                                    Posté par  . Évalué à 1.

                                    désolé, mais c'est la norm TCPA qui prévoit que les BIOS devront réaliser un digest de l'OS loader

                                    Ca ca m'interresse comme info, tu as les sources STP ? Je vois assez mal comment le bios pourrait faire un digest de l'OS loader (ni meme savoir quand il a a faire a un OS Loader) et la norme EFI des nouveau bios INTEL risque de ne carrement pas aider.

                                    Kha
                                    • [^] # Re: Demontage en regle

                                      Posté par  . Évalué à 1.

                                      Proverbe: "Il n'est pire aveugle que celui qui ne veut pas voir..."

                                      http://www.google.fr/search?q=cache:www.trustedcomputing.org/docs/1(...)
                                      Cryptographic
                                      hashing is employed to extend trust
                                      from the BIOS to other areas of the
                                      platform, in the following simplified
                                      sequence:
                                      1. The PC is turned-on.
                                      2. The TCPA-compliant "BIOS Boot
                                      Block" and TPM have a "conversa-
                                      tion."This attests that the BIOS can
                                      be trusted.
                                      3. BIOS queries to ensure that user is
                                      authorized to use the platform.
                                      4. The BIOS then has a "conversa-
                                      tion" with the operating system
                                      (OS) loader and the TPM. This
                                      attests that the OS loader can be
                                      trusted.
                                      ---------------------------------------------
                                      1.2.5 Initial Program Loader (IPL)
                                      Start of informative comment:
                                      This is the code that executes during the Post-Boot state. The purpose of this code is to load the
                                      Post-Boot environment.
                                      End of informative comment
                                      page 9 du pdf PC
                                      -------------------------
                                      http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v(...)
                                      Entities to be Measured:
                                      · Each IPL that is attempted and executed.
                                      page 20 du pdf
                                      ---------------------------
                                      2.1.2 Transferring Control
                                      Prior to transferring control an executing entity MUST measure the entity to which it will transfer
                                      control.
                                      pdf PC
                                      ------------
                                      page 24 PC
                                      In general, any
                                      code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
                                      turning control of the system over to that code. The BIOS MUST not hash any data areas.

                                      ---------------------------------------------------
              • [^] # Re: Demontage en regle

                Posté par  . Évalué à 1.

                Reste le probleme de l'accès indirect via des fonctions de déplacement des clés: dans nos discussions KHA a soutenu très fort, contre moi, que il était possible de déplacer toutes les clés (et donc toutes les clés protégées par un PCR sous un autre OS). Voulez-vous bien me confirmer que c'était une erreur et que les clés protégées par un PCR ne sont pas déplacables sous un autre OS (à moins d'utiliser la manipe BACKUP de Kha, dont je ne comprends pas pourquoi le 2e TPM me donnerait à l'accès au données protégées par PCR sous un autre OS).


                En fait c'est lie au fonctionnement des fonctions TPM_SEAL et TPM_UNSEAL. Lorsque tu veut faire rentrer des donnees ou des clefs dans un PCR il n'y a pas de cryptage de ces donnees vis a vis du PCR. C'est juste que si tu essaye de sortir les donnees d'un PCR qui ne correspond pas a ton DIR(PCR=sauvegarde, DIR=etat actuel) via un TPM_UNSEAL le TPM refusera. Par contre si ta clef est migrable, tu peux en demander la migration depuis n'importe quel environement.
                Il y a deux facon de migrer une clef : par un rewrap (ie deplacer la clef dans une entite parente), ou par un backup(un blob de donnees contenant la clef sort du TPM).
                Le prob du rewrap c'ets que c'est un move.On peut s'en servir pour sortir la clef du PCR et la mettre dans une zone publique, avant de refaire une copie dans le PCR(on peut mettre des clef dans n'importe quel PCR, meme si il ne correspond pas a la sequence de boot actuelle).
                Seul ennui si on fait ca c'est que windows peut se rendre compte en lisant le "secret" du sceau que l'OS qui a mis la clef dans le PCR n'est pas un OS connu, et donc peut de fait invalider la clef.
                C'est pour ca qu'on ets oblige de se frapper une migration complete qui elle fait une copie de la clef ou des donnees, et laisse les donnees actuelles en place. Ce genre de migration ne devant d'apres les specs n'etre possible qu'entre deux TPM, il faut donc un autre TPM....

                Voila pour les explications de pourquoi il faut un deuxieme TPM au cas ou windows bloque les fonctions d'acces TCPA.

                Kha
                • [^] # Re: Demontage en regle

                  Posté par  . Évalué à 1.

                  si le backup est complet et à l'identique, pourquoi le 2e TPM me laissera-t-il l'accès aux données protégées par PCR si je n'utilise pas exactement la meme config ?
                  • [^] # Re: Demontage en regle

                    Posté par  . Évalué à 1.

                    si le backup est complet et à l'identique, pourquoi le 2e TPM me laissera-t-il l'accès aux données protégées par PCR si je n'utilise pas exactement la meme config ?

                    Ce n'est ni un backup complet, ni un backup a l'identique, c'est un backup des donnees et/ou des clefs. Une fois que j'ai le blob de migration je peux le mettre en faire ce que je veux. Le systeme de backup fait sortir la clef du TPM (et donc du PCR). Mais rien ne m'oblige a reintegrer cette clef dans un PCR. Je peux la remttre en public si ca me chante.

                    Kha
                    • [^] # Re: Demontage en regle

                      Posté par  . Évalué à 1.

                      le contenu du blob de migration n'est pas crypté ?

                      en tout cas faire un backup des clés protégées par PCR suppose des droits complets sur la puce, ce qui pourrait ne pas être si évident si le BIOS en empêche le possesseur de la machine (seul le BIOS possede les tokens d'authentification et ne les donne pas à l'utilisateur)
                      • [^] # Re: Demontage en regle

                        Posté par  . Évalué à 1.

                        le contenu du blob de migration n'est pas crypté ?
                        Si bien sur le contenu du blob est crypte, mais avec une clef publique fournie par l'exterieur. Si il etait crypte avec une clef du TPM ca serait pas evident de migrer la clef...

                        en tout cas faire un backup des clés protégées par PCR suppose des droits complets sur la puce

                        Droit owner sur le TPM et droit sur une entite parente de la clef, cela ne correspond pas du tout a des droits complets, mais effectivement il faut pas mal de droits.

                        seul le BIOS possede les tokens d'authentification et ne les donne pas à l'utilisateur

                        La ca suppose quand meme que le bios possede un systeme d'identification de l'OS qu'il est en train de booter, donc techniquement il implemente deja sans TCPA un systeme equivalent a la certification d'OS. En d'autres termes le probleme existe deja sans TCPA. Un bios capable de refuser de relacher certaines ressources a la vue d'un OS est evidemment un des cauchemars du libre. Mais une fois d eplus dans cet environement la on ne peut pas accuser TCPA, c'est le bios qu'il faut flinguer.


                        Kha
                        • [^] # Re: Demontage en regle

                          Posté par  . Évalué à 1.

                          dans cet environement la on ne peut pas accuser TCPA
                          la différence est que une fois booté, l'OS certifié pourra utiliser TCPA pour s'assurer de la signature du BIOS, pour s'assurer de la signature de l'OS loder, etc...
                          Les fournisseurs de contenu distants pourront faire de meme !
                          • [^] # Re: Demontage en regle

                            Posté par  . Évalué à 1.

                            a différence est que une fois booté, l'OS certifié pourra utiliser TCPA pour s'assurer de la signature du BIOS, pour s'assurer de la signature de l'OS loder, etc...

                            Oui mais si le bios est deja capable de planquer des clefs ou des tokens a un OS, il n'a plus besoin de TCPA pour fiare du DRM, il peut le faire tout seul. C'est clair que si on un systeme qui est deja pret pour le DRM, on peut en plus mettre du TCPA dedans, mais de la a dire que TCPA aide le DRM il y a un gouffre.

                            Kha
                            • [^] # Re: Demontage en regle

                              Posté par  . Évalué à 1.

                              tu conviendras qu'il n'y a quasiment rien à ajouter dans un BIOS pour que TCPA sopit un puissant outil de DRM: le danger est donc bien réel !
                              • [^] # Re: Demontage en regle

                                Posté par  . Évalué à 0.

                                Je conviens qu'il n'y a quasiment rien a ajouter au bios pour qu'il serve d'outil de DRM, avec ou sans TCPA.
                                Par contre le fait qu'il y ait du TCPA ou non sur un ordi ne change rien a ce qu'il faut ajouter au bios pour le transformer en outil DRM.

                                Kha
                                • [^] # Re: Demontage en regle

                                  Posté par  . Évalué à 1.

                                  http://www.google.fr/search?q=cache:www.trustedcomputing.org/docs/1(...)
                                  Cryptographic
                                  hashing is employed to extend trust
                                  from the BIOS to other areas of the
                                  platform, in the following simplified
                                  sequence:
                                  1. The PC is turned-on.
                                  2. The TCPA-compliant "BIOS Boot
                                  Block" and TPM have a "conversa-
                                  tion."This attests that the BIOS can
                                  be trusted.
                                  3. BIOS queries to ensure that user is
                                  authorized to use the platform.
                                  4. The BIOS then has a "conversa-
                                  tion" with the operating system
                                  (OS) loader and the TPM. This
                                  attests that the OS loader can be
                                  trusted.
                                  ---------------------------------------------
                                  1.2.5 Initial Program Loader (IPL)
                                  Start of informative comment:
                                  This is the code that executes during the Post-Boot state. The purpose of this code is to load the
                                  Post-Boot environment.
                                  End of informative comment
                                  page 9 du pdf PC
                                  -------------------------
                                  http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v(...)
                                  Entities to be Measured:
                                  · Each IPL that is attempted and executed.
                                  page 20 du pdf
                                  ---------------------------
                                  2.1.2 Transferring Control
                                  Prior to transferring control an executing entity MUST measure the entity to which it will transfer
                                  control.
                                  pdf PC
                                  ------------
                                  page 24 PC
                                  In general, any
                                  code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
                                  turning control of the system over to that code. The BIOS MUST not hash any data areas.

                                  ---------------------------------------------------
                              • [^] # Re: Demontage en regle

                                Posté par  . Évalué à 1.

                                correctif: TCPA prévoit que le BIOS fasse un digest de l'OS. il n'y a donc rien à ajouter à TCPA pour faire du DRM !
    • [^] # Re: Demontage en regle

      Posté par  . Évalué à 2.

      En ce qui concerne la force des clefs, il s'agit de clefs 2048 bits. Il est vrai que si le genrateur aleatoire est de mauvaise qualite, on entamme de beaucoup la force de cette clef, mais ca laisse encore pas mal de marge par rapport a des clefs 256bits.

      J'ai un doute... Tes clés sur 2048 bits, c'est des clés de crypto symétrique ou asymétrique ?
      • [^] # Re: Demontage en regle

        Posté par  . Évalué à 2.

        ça fait drôle heing ? un si long commentaire qui semblait réfléchi...
        comparer 256 à 2048, oui je pense comme toi : on compare pas du DES avec du RSA !
        mais stocker des clés dans du hash... encore un truc de contrebande !
      • [^] # Re: Demontage en regle

        Posté par  . Évalué à 1.

        assymetrique, la plupart des clefs internes sont necessairement en 2048 bits RSA. En ce qui concerne les clefs que tu importe, elles peuvent bien entendu avoir la taille que tu veux.

        Kha
        • [^] # Re: Demontage en regle

          Posté par  . Évalué à 0.

          et t'as deja vu des clés asymétriques de 256 bits ? en 1970 ?
          • [^] # Re: Demontage en regle

            Posté par  . Évalué à 0.

            J'ai jamais vu de clef assymetrique, c'est le mode de crypto qui est assymetrique.
            Pour ce qui est de l'algo RSA par exemple, oui je vois souvent du RSA 256bits (tous les jours meme). C'est vrai que c'est faible comme cryptage, on est en train de changer ca.

            Mais ne confond pas la force d'un cryptage(en bits) avec la longueurs des clefs(en bits aussi, je sais c'est traitre).

            Kha
            • [^] # Re: Demontage en regle

              Posté par  . Évalué à 0.

              j'emploie le terme clé asymétrique pour distinguer une clé privé d'un algo asymétrique d'une clé privée d'un algo symétrique (ce osnt toutes 2 des clés privées et il faut bien pouvoir éviter els ambiguités)

              tu n'as pas bien compris comment est habituellement implémenté la crypto à clé (dite crypto asymétrique):
              un couple de clé publique /clé privé est généré (et ces clés ont depuis des années dans les logiciels libres des tailles en bit d'au moins 1024)
              ensuite ce couple de clé sert à encoder une clé privée asymétrique dont la taille varie dans les logiciels libres de 128 à 256 bits

              donc ton argument qui consisterait à comparer les tailles des clés symetriques des logiciels libres avec les tailles des clés asymétriques de TCPA est très faux.
              • [^] # Re: Demontage en regle

                Posté par  . Évalué à 0.

                correctif :)
                ensuite ce couple de clé sert à encoder une clé privée symétrique dont la taille varie dans les logiciels libres de 128 à 256 bits
              • [^] # Re: Demontage en regle

                Posté par  . Évalué à 0.

                donc ton argument qui consisterait à comparer les tailles des clés symetriques des logiciels libres avec les tailles des clés asymétriques de TCPA est très faux.

                TCPA est en RSA 2048 bits ie la clef privee a une longueur de 2048 bits.

                Comme ca ca devient clair ? C'est bien ce que j'ai dit, j'ai compare du 256 bits avec 2048 bits et c'est bien ca.

                Kha
            • [^] # crypto faible et espionnage

              Posté par  . Évalué à 1.

              RSA 256 bits. Une recherche Google me balance cette anecdote historique (1997) très intéressante :

              I revealed that the UK patent office has been ordered by GCHQ to
              use only 256 bit RSA in securing its communications with the European
              patent office im Munich and with other national offices in Europe, and
              pointed out that this would enable the NSA to get details of British
              patents for its economic intelligence clients at the time they were filed
              rather than three years later when they were published.


              http://www.chiark.greenend.org.uk/pipermail/ukcrypto/1997-September(...)

              (coîncidence amusante : l'auteur du post était Ross Anderson, créateur de la FAQ TCPA)

              Donc, déposez des brevets logiciels en Grande-Bretagne, cela protègera l'innovation vis-à-vis de vos concurrents européens, mais pas des USA ;-) Décidément, on se demande ce que les Anglais font dans l'Union Européenne...
              • [^] # Re: crypto faible et espionnage

                Posté par  . Évalué à 1.

                à mettre à coté de l'affaire Humpich, ou en fait qu'en 1988 les cryptologues disaient déjà que la VA de la carte bancaire BO' était trop faible. C'était du 320 bits...

                1988 : 320 bits, déjà trop faible selon les matheux...
                1997 : 256 bits, mwawawawa la NSA !

                bravo les naïfs...
                • [^] # Re: crypto faible et espionnage

                  Posté par  . Évalué à 0.

                  Cela nous rappelle que Ross est un chercheur qui n'est pas le premier venu en matière de crypto. Et la raison pour laquelle sa FAQ continue de présenter TCPA et Palladium sur un pied d'égalité (alors que cette faq a été mise à jour récemment) est qu'il est convaincu que TCPA est bel et bien la partie hardware sur laquelle s'appuiera Palladium.
                  Ce que j'explique maintenant sur la nouvelle version de ma page http://free2.org/tcpa/(...)
                  • [^] # Re: Ross Anderson: un grand chercheur aus service du Libre

                    Posté par  . Évalué à 1.

                    j'ajoute un lien vers la page de Ross sur le site de son Université: elle montre bien l'étendue de ses recherches en matière de sacurité ainsi que son engagement pour le Libre: qui d'entre nous peut en dire autant ? http://www.cl.cam.ac.uk/~rja14/
  • # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur

    Posté par  (site web personnel) . Évalué à 2.

    Excellant article. Merci pour tes éclaircissements! Maintenant, reste à savoir de quelle manière nous allons pouvoir nous mobiliser pour faire barrage à TCPA... (un sursaut républicain peut etre ;) )

Suivre le flux des commentaires

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