[+] "Encrypter"

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

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

  Posté par Guillaume Leclanche (page perso, ) le 10/03/2003 à 11:30. (lien). Évalué à 14.

  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 TSelek () le 10/03/2003 à 13:08. (lien). É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 imr () le 10/03/2003 à 11:34. (lien). É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 shbrol () le 10/03/2003 à 11:54. (lien). É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 tuiu pol (Jabber id, ) le 10/03/2003 à 14:21. (lien). É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 TSelek () le 10/03/2003 à 13:15. (lien). É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 Beretta_Vexee (Jabber id, ) le 10/03/2003 à 16:55. (lien). É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.

  --
  Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.

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

    Posté par TSelek () le 11/03/2003 à 08:55. (lien). É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 Morreale Jean Roc () le 11/03/2003 à 09:09. (lien). É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

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

        Posté par TSelek () le 11/03/2003 à 09:57. (lien). Évalué à 1.

        Gemplus est loin d'être le plus gros portefeuille de brevets en la matière, et tu regardes trop la télé, le reportage de Capital, hum hum...
        Pour le reste de ton post, je t'y renvoie.

[+] Liens du site

• [+] [^]Re: Liens du site

  Posté par fleny68 () le 10/03/2003 à 09:09. (lien). Évalué à -3.

  Je suis en Mozilla 121 sous Win98 et ça marche bien.

  --
  Non, rien

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

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

  Posté par Vanhu () le 10/03/2003 à 09:16. (lien). Évalué à 25.

  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 Jak () le 10/03/2003 à 09:22. (lien). É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.

    --
    « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
    - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)

    • [^]Controle du système d'information

      Posté par Vanhu () le 10/03/2003 à 09:33. (lien). É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 TSelek () le 10/03/2003 à 10:29. (lien). Évalué à 11.

        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 tene (page perso, ) le 10/03/2003 à 11:25. (lien). É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 TSelek () le 10/03/2003 à 13:23. (lien). É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 Яник () le 10/03/2003 à 09:52. (lien). Évalué à 11.

    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 Vanhu () le 10/03/2003 à 13:16. (lien). É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 TSelek () le 10/03/2003 à 13:34. (lien). É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 Vanhu () le 10/03/2003 à 15:37. (lien). É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 TSelek () le 10/03/2003 à 16:49. (lien). Évalué à 2.

            c'est une bonne idée, sauf que la parano, c'est comme la sécurité, c'est plus une pratique qu'une technique, alors faire un site la dessus... bon courage à toi ! :)

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

  Posté par Jak () le 10/03/2003 à 09:17. (lien). Évalué à 11.

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

  --
  « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
  - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)

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

  Posté par XHTML/CSS inside (page perso, ) le 10/03/2003 à 10:24. (lien). É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.

  --
  In tartiflette we trust !

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

    Posté par tene (page perso, ) le 10/03/2003 à 11:56. (lien). Évalué à 0.

    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 ?
    
    Tu nous fais de la parano là? ;-)
    
    C'est impossible, et ce pour tous, par exemple, ton IP est sauvegardée quand tu postes un commentaire ici, prouve moi de façon irréfutable qu'elle ne va pas être utilisée d'une façon ou d'une autre pour atteindre le but ultime du complot mondial contre ma personne?...
    
    Tout peut-être utilisé contre ta "vie privée" (faudrait encore définir la limite entre vie privée et le reste, mais bon)...
    
    Pour l'instant, je n'ai pas l'impression que cette technologie est complètement innocente => d'où mon refus.
    
    En suivant le même raisonnement, ne postes plus ici, déconnecte toi du net, etc... ;-)

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

      Posté par gege (page perso, ) le 10/03/2003 à 12:13. (lien). Évalué à 3.

      ton IP est sauvegardée quand tu postes un commentaire ici,
      
      ??? C'est vrai ?
      Si oui, l'adresse IP est considérée comme information personnelle, et est donc régie par la loi informatique, fichiers et liberté. Donc déclaration obligatoire à la CNIL, et surtout information de l'utilisateur (je la vois nulle part cette information) ! Donc si c'est effectivement le cas, linuxfr est dans l'illégalité !

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

        Posté par cmotsch () le 10/03/2003 à 12:38. (lien). Évalué à 3.

        S'il faut déclarer les logs de tous les serveurs web à la CNIL, il vont avoir du boulot les pauvres :)

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

        Posté par scylla (page perso, ) le 10/03/2003 à 12:47. (lien). Évalué à 4.

        je la vois nulle part cette information
        
        Si si au moment où tu as posté, sous le bouton "Envoyer" :
        
        Votre adresse IP sera sauvegardée, elle ne sera pas affichée sur le site, mais elle nous permet de pouvoir prévenir tout abus.

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

        Posté par Thierry Boudet (page perso, ) le 10/03/2003 à 18:38. (lien). Évalué à 1.

        ton IP est sauvegardée quand tu postes un commentaire ici,
        
        ??? C'est vrai ? Si oui, l'adresse IP est considérée comme information personnelle,
        
        Ben ça fait longtemps qu'on sait que les IP sont logguées sur dalfp, et personnellement, ça ne me gene pas. Je n'ai rien à cacher

        --
        ( blog )

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

        Posté par Benoît Sibaud (Jabber id, page perso, ) le 11/03/2003 à 08:46. (lien). Évalué à 1.

        Voir aussi https://linuxfr.org/user_sessions.html(...) qui indique les sessions de l'utilisateur, avec l'IP ayant servi à l'accès au site.

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

      Posté par TSelek () le 10/03/2003 à 13:38. (lien). Évalué à 2.

      Un vrai parano poste depuis un cyber-café où il paiera en liquide et où il ne retournera jamais. En plus il existait déjà un trafic de téléphones portables anonymes, c'est pas avec l'iMode que ça va ralentir...

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

      Posté par XHTML/CSS inside (page perso, ) le 10/03/2003 à 16:05. (lien). Évalué à 1.

      Tu nous fais de la parano là? ;-)
      
      C'est impossible, et ce pour tous, par exemple, ton IP est sauvegardée quand tu postes un commentaire ici, prouve moi de façon irréfutable qu'elle ne va pas être utilisée d'une façon ou d'une autre pour atteindre le but ultime du complot mondial contre ma personne?...
      
      Entre sauvegarder mon ip juste pour éviter qq abus (bien que la déclaration à la cnil soit obligatoire), et réellement s'immiscer dans ma vie privée, il y a quand même de la marge non ?
      
      J'ai l'impression qu'avec cette tech, il n'y aura plus de diférence entre la personne honnête et celui qui pirate à tout va.
      En gros c'est "on scanne votre hd pour vérifier qu'il n'y a pas de logiciels illicites mais on n'a pas dit que l'on n'allait pas chercher autre chose tant qu'on y est..."
      (c'est une impression personnelle)

      --
      In tartiflette we trust !

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

        Posté par Morreale Jean Roc () le 10/03/2003 à 21:30. (lien). Évalué à 2.

        ouais c'est clairement indiqué dans la norme tcpa ça, pile poual entre "TCPA est le fils du cousin germain de palladium alias le nouveausystemsecurisédesgensbiens" et le "en utilisant tcpa vous vous portez volontaire pour une fouille rectale approfondie hebdomadaire" ;p 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 et dans ce cas là ça ne s'ouvrira également pas sous un autre windows non plus.... et quand au mode "extend" signalé dans la depêche ça fait un peu fud et débordant un peu sur pallamachin, si l'os n'est pas estimé comme sûr il ne bénéficiera pas de tcpa et de son tampon, et non pas que linux deviendrait persona non grata complète sur ce sytème :p en attendant quelqu'un aurait il acheté le portable tcpa d'ibm pour pouvoir vérifier deux-trois trucs en situation réelle ?

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

    Posté par modr12 () le 10/03/2003 à 12:34. (lien). Évalué à 2.

    >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.
    tssss Einstein savait la preuve est la lettre adréssé a Roosevelt
    http://occawlonline.pearsoned.com/bookbind/pubbooks/nash5e_awl/medi(...)
    il a regrétté cette lettre plus tard

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

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

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

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

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

  Posté par Christophe Morvan (page perso, ) le 10/03/2003 à 10:27. (lien). É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.

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

    Posté par Quzqo () le 10/03/2003 à 11:51. (lien). Évalué à 1.

    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
    Tout à fait d'accord... lorsque je parlais de débrancher sa carte réseau, il s'agissait de s'isoler du reste du monde : cela aurait tout aussi bien pu être un modem ou une antenne wifi...

    --
    BXN - La vie est un (men)songe.

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

  Posté par alenvers () le 10/03/2003 à 10:43. (lien). Évalué à 7.

  >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é ?
  
  1) les MAC ne vont pas plus loin que le réseau local (sauf peut-être si tu utilise IPv6 mais encore tu n'es pas obligé de de construire ton ip avec ta mac)?
  2) On peut la changer (sinon le fail-over ne pourrait pas fonctionner) !
  3) Anonymat et immunité sont des concepts orthogonaux. On a le droit de ne pas être fiché partout par des firmes privées. Si c'est la justice uniquement en cas de suspicions, ça peut encore passer, mais pas des firmes privees !
  
  
  >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).
  
  Niveau logiciel, on a le choix... Ici, on risque de ne plus l'avoir au vu que la plupart des constructeurs adhèrent à tcpa. Rien à voir entre libre et propriétaire : avoir les specs ne veut pas dire que c'est 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 ?)
  
  La mise à jour ? MOUAAAAH
  
  
  Bon je vais pas passer mon temps à répondre au reste c trop GROS

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

    Posté par Quzqo () le 10/03/2003 à 11:20. (lien). É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 ?

    --
    BXN - La vie est un (men)songe.

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

      Posté par Nicolas Boulay () le 10/03/2003 à 12:27. (lien). É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"

      --
      "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

      • [^](haussement d'épaules)

        Posté par Quzqo () le 10/03/2003 à 13:15. (lien). Évalué à 1.

        Loi Informatique et Libertés ?

        --
        BXN - La vie est un (men)songe.

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

      Posté par alenvers () le 10/03/2003 à 13:12. (lien). Évalué à 0.

      >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...
      
      Rien à voir cfr. premier commentaire te répondant...
      
      
      > 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.
      
      La liberté reste là. Avec TCPA, il n'y a plus de liberté c très différent !
      
      
      >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.
      
      Alors tu confonds ouverture du source et libre... Il logiciel propriétaire peut avoir des sources ouvertes (shared machin, etc.)
      
      >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 ?
      
      Non, le tien ne tient pas du tout la route, il n'entretient que des FUD's.

      • [^]Point...

        Posté par Quzqo () le 10/03/2003 à 13:21. (lien). É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.

        --
        BXN - La vie est un (men)songe.

        • [^]Re: Point...

          Posté par alenvers () le 10/03/2003 à 13:27. (lien). É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.
          
          Il semblerait que je ne sois pas le seul Nico, a fait un post similaire au mien, a peu près en même temps...

        • [+] [^]Re: Point...

          Posté par alenvers () le 10/03/2003 à 14:54. (lien). Évalué à -1.

          >Si avoir un minimum d'ouverture d'esprit
          
          Ouvre ton esprit comme ça et TCPA te le fermera !

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

  Posté par Nim () le 10/03/2003 à 11:02. (lien). É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 alenvers () le 10/03/2003 à 13:22. (lien). Évalué à 3.

    Tout dépend aussi par "incassable". Si on est puriste, il s'agit d'une clé égale à la taille des données et utilisée une seule fois.
    
    Sinon ça peut être défini par "cassable en un temps exponentionnel dépendant de la taille de la clé" (le cas de la plupart des algos)... Dans ce cas, le tout est de choisir des clés suffisament grandes cad pour que le temps de peremption des données soit inférieur au temps de cassage (c francais ça ?).

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

      Posté par free2.org (page perso, ) le 10/03/2003 à 22:06. (lien). Évalué à 1.

      petite remarque sur l'algo OTP dont vous parlez: si je donne un CD-ROM ou un disque dur à un de mes amis, on pourra s'échanger un très grand nombre de messages textes (voir multimedias dans le cas d'un dur) pendant plusieurs mois. Considérant qu'il s'agit d'une crypto démontrée mathématiquement, je ne trouve pas OTP si dur à mettre en oeuvre.

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

        Posté par Moby-Dik () le 11/03/2003 à 00:35. (lien). Évalué à 1.

        Ton CD-ROM, il a intérêt à être bien bien secret et bien bien aléatoire... Pas simple.

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

          Posté par free2.org (page perso, ) le 11/03/2003 à 14:10. (lien). Évalué à 1.

          il y a des générateurs aléatoires hardware basés sur de sphénomènes physiques impérvisibles, achetables sous formes de cartes PCI
          
          quand à garder secrète la clé privée, c'est le problème de TOUS les algorithmes de cryptage. Une passphrase peut aider. Un coffre-fort dans lequel tu mets le Cd quand tu ne t'en sert pas aussi.

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

            Posté par Moby-Dik () le 11/03/2003 à 18:21. (lien). Évalué à 1.

            quand à garder secrète la clé privée, c'est le problème de TOUS les algorithmes de cryptage. Une passphrase peut aider. Un coffre-fort dans lequel tu mets le Cd quand tu ne t'en sert pas aussi.
            
            Si tu utilises une passphrase pour chiffrer ton masque jetable parce que tu ne sais pas stocker celui-ci de façon sûre, c'est l'algo de chiffrement utilisé en conjonction avec la passphrase qui deviendra le maillon faible (sauf si la passphrase est trop courte bien sûr). Donc autant abandonner directement le masque jetable et partager plutôt la passphrase avec ton correspondant.

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

              Posté par free2.org (page perso, ) le 11/03/2003 à 22:39. (lien). Évalué à 1.

              tu oublies qu'il faut la passphrase ET le CD !
              c'est mieux que une passphrase seule

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

                Posté par Moby-Dik () le 11/03/2003 à 22:52. (lien). Évalué à 1.

                Ca revient simplement à empiler les chiffrements successifs, mais tu pourrais faire la même chose sans masque jetable. La caractéristique mathématique du masque jetable n'est pas utile s'il n'est pas conservé en lieu sûr, passphrase ou pas.

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

• [^]TCPA n'est pas Palladium ...

  Posté par b0z0 () le 10/03/2003 à 11:46. (lien). É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 free2.org (page perso, ) le 11/03/2003 à 14:13. (lien). É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 tene (page perso, ) le 10/03/2003 à 11:50. (lien). É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 b0z0 () le 10/03/2003 à 12:16. (lien). É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 Nicolas Boulay () le 10/03/2003 à 12:34. (lien). Évalué à 1.

      Disons que le TPM vérifie ce qui se passe dans le système à l'aide de "mesure" si elles ne lui plaisent, il se désactive. Donc il n'est plus possible d'accèder à ses clefs.
      
      Je comprends l'utiliter de vérifier une partition de boot (en mettant sois même le hash du boot dans le TCPA) mais je comprends beaucoup moins l'interret de vérifier les périphériques PCI par exemple.

      --
      "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

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

    Posté par Matthieu Moy (page perso, ) le 10/03/2003 à 13:07. (lien). É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 TSelek () le 10/03/2003 à 13:42. (lien). É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 Nicolas Boulay () le 10/03/2003 à 15:08. (lien). É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.

        --
        "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

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

          Posté par b0z0 () le 10/03/2003 à 15:19. (lien). É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 TSelek () le 10/03/2003 à 15:44. (lien). É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 Nicolas Boulay () le 10/03/2003 à 16:47. (lien). Évalué à 1.

            arf.
            
            Disons que ce n'est pas parceque c'est du soft bas niveau que c'est de l'OS.
            
            TCPA est une puce à "coté" du système, une puce de carte à puce qui peut aussi espionner ce bus et décider de se désactiver si cela ne va pas.
            
            Palladium rajoute une couche logicielle et notament pour la MMU qui rajoute un niveau de gestion inaccescible pour les OS. Mais ce code sera intégré au bios des cartes, je pense. Ce code controle le système en entier, et surtout permet de le partitionner de manière forte. (j'imagine un virus à l'interrieur ! Aucun antivirus n'y pourra rien... même pas un debuggeur...)

            --
            "Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."

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

              Posté par b0z0 () le 11/03/2003 à 08:14. (lien). Évalué à 1.

              Palladium inclut aussi une partie hardware, le SSC, similaire à celle de TCPA.

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

        Posté par b0z0 () le 10/03/2003 à 15:16. (lien). É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 TSelek () le 10/03/2003 à 16:32. (lien). É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 b0z0 () le 11/03/2003 à 08:20. (lien). É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 TSelek () le 11/03/2003 à 09:01. (lien). É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 b0z0 () le 11/03/2003 à 09:27. (lien). É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 TSelek () le 10/03/2003 à 14:02. (lien). É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

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

  Posté par gourgou () le 10/03/2003 à 11:19. (lien). É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...

• [^]Re: Ma carte mère vient de griller...

  Posté par gourgou () le 10/03/2003 à 11:37. (lien). É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 cornofulgur () le 10/03/2003 à 11:38. (lien). É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 tene (page perso, ) le 10/03/2003 à 11:55. (lien). É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 iug () le 10/03/2003 à 12:38. (lien). É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 cornofulgur () le 10/03/2003 à 13:20. (lien). É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

• [^]Re: PPC970

  Posté par Morreale Jean Roc () le 10/03/2003 à 21:40. (lien). É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

Demontage en regle

• [^]Re: Demontage en regle

  Posté par free2.org (page perso, ) le 10/03/2003 à 20:05. (lien). É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 Jerome Herman () le 10/03/2003 à 21:26. (lien). É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

    --
    Kha
    Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

    • [^]Re: Demontage en regle

      Posté par free2.org (page perso, ) le 10/03/2003 à 22:59. (lien). É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 Jerome Herman () le 11/03/2003 à 01:13. (lien). É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

        --
        Kha
        Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

        • [^]Re: Demontage en regle

          Posté par free2.org (page perso, ) le 11/03/2003 à 09:50. (lien). É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 Jerome Herman () le 11/03/2003 à 15:53. (lien). É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

            --
            Kha
            Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

            • [^]Re: Demontage en regle

              Posté par free2.org (page perso, ) le 11/03/2003 à 16:25. (lien). É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 Jerome Herman () le 11/03/2003 à 17:39. (lien). É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

                --
                Kha
                Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                • [^]Re: Demontage en regle

                  Posté par free2.org (page perso, ) le 11/03/2003 à 17:58. (lien). É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 Jerome Herman () le 11/03/2003 à 18:50. (lien). É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

                    --
                    Kha
                    Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                    • [^]Re: Demontage en regle

                      Posté par free2.org (page perso, ) le 12/03/2003 à 01:15. (lien). É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 thoran () le 11/03/2003 à 17:52. (lien). É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 Jerome Herman () le 11/03/2003 à 19:53. (lien). É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

        --
        Kha
        Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

        • [^]Re: Demontage en regle

          Posté par free2.org (page perso, ) le 12/03/2003 à 01:09. (lien). É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 Jerome Herman () le 12/03/2003 à 15:19. (lien). É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

            --
            Kha
            Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

            • [^]Re: Demontage en regle

              Posté par free2.org (page perso, ) le 12/03/2003 à 23:50. (lien). É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 Jerome Herman () le 13/03/2003 à 02:17. (lien). É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

                --
                Kha
                Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                • [^]Re: Demontage en regle

                  Posté par free2.org (page perso, ) le 13/03/2003 à 10:42. (lien). É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 Jerome Herman () le 13/03/2003 à 16:11. (lien). É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

                    --
                    Kha
                    Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                    • [^]Re: Demontage en regle

                      Posté par free2.org (page perso, ) le 13/03/2003 à 20:18. (lien). É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 free2.org (page perso, ) le 12/03/2003 à 01:35. (lien). É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 free2.org (page perso, ) le 12/03/2003 à 09:51. (lien). É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 thoran () le 12/03/2003 à 14:04. (lien). É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 free2.org (page perso, ) le 12/03/2003 à 14:56. (lien). É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 Jerome Herman () le 12/03/2003 à 16:10. (lien). É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

                --
                Kha
                Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                • [^]Re: Demontage en regle

                  Posté par free2.org (page perso, ) le 12/03/2003 à 21:59. (lien). É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 Moby-Dik () le 12/03/2003 à 22:52. (lien). Évalué à -1.

                    Je crois que tu ne lis pas les messages auxquels tu réponds.

                    • [^]Re: Demontage en regle

                      Posté par free2.org (page perso, ) le 13/03/2003 à 00:02. (lien). É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 Jerome Herman () le 13/03/2003 à 01:45. (lien). É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

                        --
                        Kha
                        Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                        • [^]Re: Demontage en regle

                          Posté par free2.org (page perso, ) le 13/03/2003 à 10:30. (lien). É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 Jerome Herman () le 13/03/2003 à 15:44. (lien). É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

                            --
                            Kha
                            Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                            • [^]Re: Demontage en regle

                              Posté par free2.org (page perso, ) le 13/03/2003 à 16:04. (lien). É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 Jerome Herman () le 13/03/2003 à 16:20. (lien). É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

                                --
                                Kha
                                Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                                • [^]Re: Demontage en regle

                                  Posté par free2.org (page perso, ) le 13/03/2003 à 19:06. (lien). É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 Jerome Herman () le 12/03/2003 à 15:55. (lien). É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

            --
            Kha
            Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

            • [^]Re: Demontage en regle

              Posté par free2.org (page perso, ) le 12/03/2003 à 17:54. (lien). É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 Jerome Herman () le 12/03/2003 à 19:24. (lien). É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

                --
                Kha
                Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                • [^]Re: Demontage en regle

                  Posté par free2.org (page perso, ) le 12/03/2003 à 23:55. (lien). É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 Jerome Herman () le 13/03/2003 à 02:00. (lien). É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

                    --
                    Kha
                    Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                    • [^]Re: Demontage en regle

                      Posté par free2.org (page perso, ) le 13/03/2003 à 10:25. (lien). É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 Jerome Herman () le 13/03/2003 à 15:39. (lien). É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

                        --
                        Kha
                        Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                        • [^]Re: Demontage en regle

                          Posté par free2.org (page perso, ) le 13/03/2003 à 15:57. (lien). É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 Jerome Herman () le 13/03/2003 à 16:14. (lien). É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

                            --
                            Kha
                            Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

                            • [^]Re: Demontage en regle

                              Posté par free2.org (page perso, ) le 13/03/2003 à 19:06. (lien). É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 free2.org (page perso, ) le 13/03/2003 à 16:24. (lien). É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 Moby-Dik () le 11/03/2003 à 01:32. (lien). É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 TSelek () le 11/03/2003 à 09:09. (lien). É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 Jerome Herman () le 11/03/2003 à 14:46. (lien). É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

    --
    Kha
    Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

    • [^]Re: Demontage en regle

      Posté par free2.org (page perso, ) le 11/03/2003 à 16:01. (lien). Évalué à 0.

      et t'as deja vu des clés asymétriques de 256 bits ? en 1970 ?

      • [^]Re: Demontage en regle

        Posté par Jerome Herman () le 11/03/2003 à 16:40. (lien). É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

        --
        Kha
        Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

        • [^]Re: Demontage en regle

          Posté par free2.org (page perso, ) le 11/03/2003 à 17:06. (lien). É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 free2.org (page perso, ) le 11/03/2003 à 17:11. (lien). É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 Jerome Herman () le 11/03/2003 à 17:47. (lien). É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

            --
            Kha
            Administrateur système : Personne ne comprend ce que l'on fait, tout le monde sait quand on oublie de le faire.

            • [^]Re: Demontage en regle

              Posté par free2.org (page perso, ) le 11/03/2003 à 18:06. (lien). Évalué à 0.

              lis mon correctif et tu comprendras ton erreur

        • [^]crypto faible et espionnage

          Posté par Moby-Dik () le 11/03/2003 à 19:04. (lien). É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 TSelek () le 12/03/2003 à 09:43. (lien). É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 free2.org (page perso, ) le 12/03/2003 à 10:34. (lien). É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 free2.org (page perso, ) le 13/03/2003 à 12:51. (lien). É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