IBM présente TCPA "tel qu'il aurait dû être"

Posté par  (site web personnel) . Modéré par kalahann.
Étiquettes :
0
28
jan.
2003
Matériel
Essayant de se jusitifier vis à vis de la communauté du logiciel Libre de son soutien à TCPA, IBM le présente d'une manière diffèrente.
Selon lui, ce système n'est qu'un moyen de garder des clefs de chiffrement en sécurité. Ce seraient des extensions créées par microsoft (scp/palladium) qui seraient à l'origine de la plupart des problèmes.
Il proposent également des pilotes TCPA sous GPL. Probablement soucieux de conserver l'appui "des geek-libristes", IBM tient à nous présenter TCPA sous un autre jour: selon lui, ce système ne vise qu'à stocker des clefs de cryptage de manière sécurisée.
Il n'aurait donc pas la capacité de contrôler l'éxecution de tels ou tels binaires, ou de restreindre l'accès à certaines zones de la RAM, et aucune certification n'est nécessaire pour l'employer "Sous Linux, il suffit de charger/décharger le module" (qu'ils viennent de sortir).
Il n'intégrerait également aucune fonction de contrôle externe, blacklist des OS (ce qui, selon IBM, serait également possible sans TCPA) et autres joyeusetés telles que la nécessité d'un matériel certifié.
Ils n'auraient également aucun rapport avec le DRM, et affirment ne pas savoir si microsoft voudra intégrer le support du vrai TCPA à Palladium (on garde ce nom ok?).

Ils admettent par contre l'existence d'une clef privée inchangeable, mais jurent ne jamais avoir ne serait-ce que pensé à l'enregistrer (gageons que microsoft sera plus imaginatif). Il reconnaissent également que TCPA peut vérifier si l'OS est fiable, et ne mentionnent pas (en tout cas je l'ai pas vu), ce qui permettra de dire qu'un OS l'est (ils disent juste que c'est le propriétaire déclaré par le système de gestion qui peut le faire, ce qui laisse envisager que microsoft soit ce "propriètaire").

Pour prouver leur bonne volontée, il fournissent un module pour Linux, et sous GPL.

Les questions qui se posent maintenant sont:
- Le "vrai TCPA" sera-t-il distribué au grand public?
- Permettra-t-il d'implémenter un "compatible palladium" libre?

Aller plus loin

  • # Re: IBM présente TCPA

    Posté par  . Évalué à 10.

    moi je suis resté sur ma faim... toujours pas de détails techniques finalement... c'est plus une opération de communication qu'autre chose :(

    • [^] # c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

      Posté par  . Évalué à 10.

      j'ai comparé le "why TCPA" d'IBM avec le FAQ de notcpa http://www.notcpa.org/faq.html D'abord j'ai été étonné par les différences entre les 2 document. Alors j'ai commencé à écrire la preuve que TCPA est seulement utile pour Palladium/DRM (et devrait être boycotté très fort) : Dans le pdf d'IBM, on écrit que TCPA peut être employé pour produire une clef asymetric privée qui ne peut plus être employée si il y a des changements dans le système (matériel ou logiciel), et que personne ne peut lire, même le propriétaire de l'ordinateur. Cela veut dire, entre autres, que cette clé n'est plus accessible si vous installez ou si vous recompilez un nouveau noyau Linux. La clef publique associée peut alors être employée par un fournisseur de contenu ou de soft pour chiffrer le contenu qu'il vous envoie, de sorte que seulement la puce TCPA de votre PC puisse employer ce contenu, et seulement l'OS qui a enregistré la clé privée associée. C'est exactement le parfait Palladium/DRM dont la RIAA, la mpaa et Microsoft rêvent ! D'autre part, sans TCPA, les systèmes Linux et BSD ont déjà des dispositifs de sécurité (pour LInux les capabilities de posix, et maintenant le LinuxSecurityModule) pour s'assurer qu'aucun programme, même root, ne peut modifier ou accéder à certains fichiers (comme le noyau et d'autres fichiers du système principal). Les dispositifs de Jail de LSM peuvent s'assurer qu'un programme utilisant Internet n'accédera jamais sans votre accord à des dossiers privés importants sur votre harddisk. Depuis longtemps, sans TCPA, vous pouvez utiliser un CD-rom amorçable ou un floppy protégé en écriture amorçable pour vérifier l'intégrité de fichiers système du hard-disk chaque fois que vous rebootez. (avec des outils libres comme tripwire) Conclusion : TCPA n'offre rien d'important pour des utilisateurs de Linux, mais offre beaucoup pour les sociétés intéressées par DRM ! P.S.: VIA propose des procs et des cartes mères bon marché sans TCPA, avec des chips facilitant la crypto, comme un générateur aléatoire à haut débit (jusqu'à 6 Mb/sec), ce qui est le manque principal des systèmes actuels (pour regénérer fréquemment de grosses clés ou pour faire du OTP, la seule crypto démontrée fiable mathématiquement) http://fr.news.yahoo.com/030125/35/2z6s2.html

      • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

        Posté par  . Évalué à 2.

        OTP ? T'as des liens, ça m'intéresse.

        • [^] # OTP

          Posté par  . Évalué à 3.

          OneTimePad c'est le plus simple des ciphers, et le plus fiable si le générateur aléatoire est de bonne qualité cependant c'est un algorithme symétrique et il nécessite donc en principe la remise en main propre d'un CDrom (ou HDD, ou connexion locale) de la clé privée qui doit être de taille supérieure ou égale à l'ensemble des données qui seront ensuite échangées dans le futur par les 2 personnes. https://everything2.com/index.pl?node_id=800605

      • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

        Posté par  . Évalué à 6.

        C'est inacceptable du point de vue de l'utilisateur si la clef privée ne peut être re-générée. Car d'une part c'est très mauvais du point de vue de la sécurité (si la clef est compromise), et d'autre part cela permet d'identifier les machines a partir de leur clefs publiques. Cela dit, il faut surement comprendre ca autrement, on ne peut utiliser notre clef privée s'il y a eu un changement dans le système qui a pu compromettre celle-ci. On est alors obligé d'en changer. C'est à notre avantage. En gros dans TCPA, il reste encore des zones d'ombre ! et cela n'a rien du truc parfait dont on nous avait parlé juste là (dans les deux camps). et par conséquent on peut le réaliser en software, et openssl propose des fonctionnalites adéquates pour réaliser tout ca.

        • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

          Posté par  . Évalué à 1.

          on ne peut utiliser notre clef privée s'il y a eu un changement dans le système qui a pu compromettre celle-ci. Non, relis le PDF et tu verras que la clé privée est générée à l'intérieur de la puce TCPA, et qu'elle n'en sort jamais. Les opérations de cryptage utilisant cette clé se font à l'intérieur de la puce. Donc un cracker ne peut pas accéder à cette clé (protection qu'il est déjà possible de faire sous linux avec LSM ou d'autres patches, et meme sans patch avec un simple chroot et un iptables -m owner pour tous les programmes internet). Si tu relis mon raisonnement tu verras que la seule motivation valable pour ce mécanisme est DRM (car tripwire te permet deja de savoir si ton système a été compromis, et LSM te permet deja d'empêcher ton système d'être compromis en exécutant les programmes internet dans une sandbox)

          • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

            Posté par  . Évalué à 5.

            Non, l'objectif premier c'est de remplacer une carte à puce : jamais aucune carte à puce ne devrait laisser sortir ses clés privées ! C'est même le principe de base... Une carte à puce, c'est un coffre avec une ouverture trop petite pour laisser passer les clés générées en interne...

            La suite logique est que la crypto doit alors être au même niveau que les clés, ce ne serait plus au CPU de faire quelque calcul que ce soit mais à la partie TCPA ! Or quid des algos, de l'implémentation ? On n'a rien entendu encore sur le sujet alors que c'est primordial, comme le random !

            Le seul point d'objection valide est la répudiation : peut-on oui ou non regnérer une nouvelle clé sur demande ? Comment ces clés sont-elles taguées ?

            Après, DRM et tout ça, c'est __APPLICATIF__ donc c'est une autre problématique !

            • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

              Posté par  . Évalué à 1.

              objectif premier c'est de remplacer une carte à puce : jamais aucune carte à puce ne devrait laisser sortir ses clés privée
              Encore une fois sous Linux, il est possible de s'assurer au moment du boot (par tripwaire) que certains fichiers systèmes n'ont pas été modifiés, et notamment l'intégrité d'un fichier système qui utilise LSM et interdit l'accès à une clé privée par tous les programmes sauf celui réalisant l'encryption.

              De + le mécanisme de carte à puce que tu décris pourrait être avantageusement remplacé par une puce se branchant sur le port USB et capable elle aussi de générer des clés privées et de crypter avec. Sans pour autant être capable d'interdire l'accès aux services de cryptages avec cette clé à un OS libre. (ce que fait pourtant TCPA, relis le PDF !)

              Le fait d'interdire l'accès au cryptage par une clé privée précise à tous les OS libres est la preuve que TCPA est avant tout fait pour MS.

              • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

                Posté par  . Évalué à 4.

                Moi je suis pour la soluce clé USB :) Mais c'est pas la meilleure, la meilleure c'est avec pinpad.

                Ca existe déjà, comme eGate chez Schlumberger.

                Le pb des soluces softs que tu décris, c'est l'impossibilité de faire des evals sérieuses style Critères Communs sur un PC/OS complet. Pas un seul parano ne se reposera sur tripwire, même si c'est un outil indispensable.

                Par contre ce que tu précises est plus qu'inquiétant....

                Attention aussi au distinguo accès à la clé / accès à un serveur crypto...

              • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

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

                Le fait d'interdire l'accès au cryptage par une clé privée précise à tous les OS libres est la preuve que TCPA est avant tout fait pour MS.

                A ce que j'ai cru comprendre, on peut charger ses propres clefs sous Linux: "There is no requirement for certificates at all, to use any TCPA chip function." et "You can generate private keys use them to sign and decrypt[...]".
                D'ailleurs y zont fait un driver Nux sous GPL.

                • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

                  Posté par  . Évalué à 2.

                  En effet n'importe quel OS, y compris Linux, peut demander la création de clés privées puis les utiliser.

                  Ce qui est inacceptable est le fait qu'il peut aussi demander à TCPA de bloquer l'accès aux clés si le système change (soft ou matériel) ! C'est cette propriété qu'utilisera probablement Palladium.


                  Sans compter les évolutions futures de TCPA (car un standard évolue) qui pourraient être encore plus liberticides: seuls les OS signés par une master key pourraient alors s'exécuter: rappelons que la Xbox et les téléphones Win d'Orange refusent de booter ou d'exécuter des programmes non signé par MS.

            • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

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

              A prioris, la norme TCPA parle d'une clef RSA unique par TPM signé elle-même par une clef unique pour s'assurer de "l'authenticité" du TPM (le "truc" hardware sur la carte mère). Ensuite, le TPM peut générer d'autres clefs qui peuvent être signé par la clef TPM.

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

      • [^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM

        Posté par  . Évalué à 1.

        >TCPA peut être employé pour produire une clef asymetric privée qui ne peut plus être employée si il y a des changements dans le système (matériel ou logiciel)

        Et bin ça va être coton, pour assurer la maintenance des postes de travail équipés de ce Grand Truc.

        C'était pas IBM, qui avait alerté le monde sur les problèmes liés à la maintenance ?

  • # Re: IBM présente TCPA

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

    http://www.research.ibm.com/gsal/tcpa/ http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf et http://www.research.ibm.com/gsal/tcpa/tpm.tar.gz part en time out. http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf part en "(101) Network is unreachable"

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

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

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

    • [^] # Re: IBM présente TCPA

      Posté par  . Évalué à 4.

      Ca s'appelle plus palladium ... y avait déjà un Copyright dessus :p

    • [^] # Re: IBM présente TCPA

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

      C'est toute la force de TCPA/Palladium. On réparti les responsabilités sur chacun des composants de la chaine de vérification : materiel/logiciel/contenu. Ainsi, au final, quand les utilisateurs commencent a gueuler, chacun peut envoyer la patate (ici, l'utilisateur), se retourner vers l'aimable personne qui lui a fourni le logicile/le hardware et le reste :/ Enfin ....

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 10.

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

      • [^] # Re: IBM présente TCPA

        Posté par  . Évalué à 2.

        bah, encore mieux, "on" ne te vendra plus des machines mais "on" te proposera un abonnement à une machine toujours au niveau techniquement, pour une somme presque raisonnable et avec un abonnement Internet (bridé^H^H^H^H^Hprotégé contre les méchants virus) et un abonnement Multimedia (Vivendi Universal, etc...), peut être un abonnement Télé, Jeux, etc...

        si la machine en question est sous Palladium mais est louée et ne t'appartient donc pas, plus de raison de gueuler, non ?

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 1.

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

          • [^] # Re: IBM présente TCPA

            Posté par  . Évalué à 1.

            c'est vrai que je ne vois pas passer Hewlett-Packard, IBM, Sony, Compaq (ah non, plus Compaq), Dell, Gateway, Packard-Bell à ce genre de formule du jour au lendemain.

            Par contre, les portables sont déjà plutôt difficiles à faire évoluer, les PDA et futurs Tablet PC le seront aussi, les machines d'Apple sont relativement peu bidouillables sorti du changement de disque dur...

            ... et les PCs de marque ont en général une clause annulant la garantie en cas de tels bidouillages, voire même simplement de l'ouverture du capot.

            Bizarement, je sens que les machines vendues pour faire tourner le désormais proche "Windows Multimedia Center Edition" seront difficilement upgradables de façon non "autorisée".

  • # Re: IBM présente TCPA

    Posté par  . Évalué à 7.

    Après MS qui laisse tomber le nom palladium voilà IBM qui veut nous faire avaler TCPA .. On commence par nous dire "TCPA c'est pas bien seulement à cause de MS", "on ne va pas utiliser les possibilité de l'identifiant unique" .. IBM est pro-linux mais sur pro-IBM-linux, à part les 250 ingénieurs (tous sur TCPA ?) et les pubs ou on compare Linux à un couillon qui bossent pour des cachoutère, l'action d'IBM envers Linux me semble discutable ..

    • [^] # Re: IBM présente TCPA

      Posté par  . Évalué à 2.

      et MS va dire : TCPA existe, si je ne l'utilise pas, d'autres vont le faire et je vais perdre des sous. Donc voici Palladium. C'est pas ma faute , hein !"

    • [^] # Re: IBM présente TCPA

      Posté par  . Évalué à 4.

      Perso je considèrerai un fabricant de matèriel sérieux à propos de son soutiens à Linux _quand_ il vendra des portables avec Linux pré-installé par défault... car les portables sont ciblés pour les cadres "dynamiques" (donc parmis ceux qui signent les chèques) principalement. mode boule_de_crystal on zoooom... Peut-être en 2003 ? ... Quand il n'y aura plus de possibilité pour les U$ de garder leurs monopoles vivants ? ... ... (pas de réponse) ... mode boule_de_crystal off

  • # Re: IBM présente TCPA

    Posté par  . Évalué à 10.

    TCPA à la base a pour cible la carte à puce ou les SAM. Personne encore n'a réussi à déployer en grandeur réelle les lecteurs de carte à puce, pour un tas de raisons (dont not invented here). Or il faut un endroit assez secure pour stocker les clés cryptos. Normalement c'est la carte à puce qui remplit ce job (enfin chez les clients sensés, qui sont plutôt rares). Bon, pas de carte à puce, donc TCPA. Stocker les clés en lieu sur, ok. Le problème vient ensuite : des clés, appartenant à qui et pour quoi faire ? GPG pourrait bien reposer sur TCPA par exemple. Mais je ne crois pas que les gens qui ont sorti ce bousin l'ont fait pour GPG.

    • [^] # Re: IBM présente TCPA

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

      L'inconvénient des cartes à puce c'est quand même leur débit : on ne peut pas se permettre de chiffrer des gros volumes avec une carte à puce, à moins de ne pas être pressé. Stocker les clés en lieu sur, ok. Le problème vient ensuite : des clés, appartenant à qui et pour quoi faire ? GPG pourrait bien reposer sur TCPA par exemple. Mais je ne crois pas que les gens qui ont sorti ce bousin l'ont fait pour GPG. Je vois aussi un gros avantage pour apache : combien de serveurs HTTPS ont aujorud'hui une clef privée en clair dans un fichier pour éviter que les admins aient à saisir leur passphrase à chaque redémarrage du serveur. Sans compter que même avec une protection par passphrase, la clef privée en clair réside quelque part dans l'espace mémoire du process, donc a priori visible pour quelques pirates acharnés...

      • [^] # Re: IBM présente TCPA

        Posté par  . Évalué à 10.

        non, non, il a raison, l'inconvénient des cartes à puces, c'est qu'elles ont été inventées en France et pas aux US, et que donc là bas ils ne veulent pas en entendre parler. j'ai déjà entendu dire plusieurs fois par des personnes que je considère comme très bien informées, que TCPA (au départ du moins) est venu de l'idée de tuer la carte à puce de "la vieille Europe". c'est le syndrome "not invented here" évoqué par Tselek, et il a raison. en Europe, et surtout en France, c'est beaucoup beaucoup plus déployé qu'on ne le croit (banques, grande distribution, plus tout ce que nous connaissons tous, de la télécarte à la Vitale), mais ces solutions ont souffert pendant très très longtemps du manque complet de support de la part des logiciels américains (ce qui provient à la fois en grande partie du syndrome évoqué ci-dessus, et de la relative incompétence de Gemplus à vendre le truc). Mais bon, quand on essaye d'expliquer en France que le logiciel libre c'est notre chance de sortir de ce système de merde, y'en a plein qui font semblant de ne pas comprendre.... maintenant quand à savoir ce que TCPA est devenu au fur et à mesure de son développement et les gesticulations des uns et des autres, le poids de Microsoft ou du gouvernement américain, j'ai tendance à vouloir écouter RMS pour le coup....

        • [^] # Re: IBM présente TCPA

          Posté par  . Évalué à 5.

          A lire : "De Gemplus à MandrakeSoft ... Impasses d'une non-politique industielle" http://www.temps-reels.net/article.php3?id_article=1202

          • [^] # Re: IBM présente TCPA

            Posté par  . Évalué à 2.

            Eh oui, quel dommage qu'ils n'aient rien fait pendant qu'ils étaient au gouvernement...

            (temps-reels, c'est en gros la section "nouvelles technologies" du PS...)

            [-1] parce que ça ne change pas grand chose hélas...

            • [^] # Re: IBM présente TCPA

              Posté par  . Évalué à 1.

              Il est pas mal du tout cet article en fait !

              Sinon, c'est Bull qui a laisser filer CP8 vers Schlumberger, et à cette époque c'était De Panafieu aux commandes, donc un chiracien pur jus :/

              D'ailleur Bull est un fortin RPR^WUMP de toutes façons.

        • [^] # Re: IBM présente TCPA

          Posté par  . Évalué à 3.

          Ca fait 10 ans que les industriels français se disent "cette année c'est l'explosion du marché américain".... Ils seront tous morts avant d'être entré :( CP8 -> Schlumberger OCS -> Thales (qui est sur la liste des rétortions US aux cotés d'Airbus, EADS...) Gemplus -> CIA (vu à la télé ;) Au fait, MS avait lancé PC/SC, -> dead, PC/SC 2 -> avorté... Windows for SmartCard -> dead bref....

          • [^] # Re: IBM présente TCPA

            Posté par  . Évalué à 1.

            "Ils seront tous morts avant d'être entré :( " C'est le but, et le moyen c'est "faire payer pendant qu'ils croient à nos rêves".

      • [^] # Re: IBM présente TCPA

        Posté par  . Évalué à 2.

        L'inconvénient des cartes à puce c'est quand même leur débit : on ne peut pas se permettre de chiffrer des gros volumes avec une carte à puce, à moins de ne pas être pressé. Ben, tu (dé)chiffres une clé de session avec la clé privée, puis le CPU fait du chiffrement symétrique avec la clé de session.

      • [^] # Re: IBM présente TCPA

        Posté par  . Évalué à 4.

        A propos du débit, cette limite n'existe que pour les cartes ISO7816. De nos jours, on travaille sur des cartes USB 1.1 voir USB 2.0.... Et si il faut plus on fera plus, le problème n'est pas là. Le problème c'est que personne ne veut payer la sécurité, point barre. Oubliez la carte bancaire que vous avez comme modèle, elle a déjà 20 ans.... Pour le reste, je crois qu'on est d'accord...

      • [^] # Re: IBM présente TCPA

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

        > L'inconvénient des cartes à puce c'est quand même leur débit Non non, personne ne s'amuse à crypter des gros volumes avec une carte à puce ! La clef privée de la carte à puce sert à créer/échanger une clef de session (donc symétrique). Ensuite, on crypte les gros volumes avec la clef symétrique, parce que les algos symétriques sont beaucoup plus rapides.

        • [^] # Re: IBM présente TCPA

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

          En fait j'ai fait une bourde en parlant de "gros volume". Ce que je voulais évoquer, c'est surtout (par exemple) les sites https qui ont beaucoup de connexions et impliquent beaucoup de créations de clefs de session. Par contre, comme le fait justement remarquer Tselek, j'en étais resté à la norme iso7816 qui me semble-t-il limite les comms à 9600 bauds ... peut-être que maintenant on n'a plus besoin d'avoir des racks de cartes à puce pour augmenter les perfs.

        • [^] # Re: IBM présente TCPA

          Posté par  . Évalué à 2.

          personne ne s'amuse... j'adore :) bon pour les mecs qui bossent sur le sujet ça doit les faire rire jaune :)

          Pour ta gouverne sache que les prochaines générations de set-top-box risquent fort d'être basées sur des cartes à puce ayant un port haut-débit. L'ISO7816 est en fin de vie, ses remplacants sont déjà prêts.... Reste à éduquer les clients...

  • # Virus ?

    Posté par  . Évalué à 2.

    Je ne comprend pas tout pour être honnète. En gros TCPA permet de stocker des clées. Par rapport à GPG je vois pas bien l'intérêt (sauf si quelqu'un a un accès direct au PC). Sinon il y a une autre partie à laquelle je n'ai rien compris c'est (page 5) : * TCPA does - protect sensitive data from many software attacks, including viruses, worms and trojans. Quelqu'un peut m'expliquer.

    • [^] # Re: Virus ?

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

      Mouarf! Je te conseille l'excellente lecture que voici, tu y trouveras une réponse.. F.A.Q. TCPA/Palladium - VO http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html F.A.Q. TCPA/Palladium - VF - Cristophe Le Bars http://www.lebars.org/sec/tcpa-faq.fr.html

      • [^] # Re: Virus ?

        Posté par  . Évalué à 3.

        Déjà lu. Le papier d'IBM contredit ce qui est écrit dans cette faq qui semble mélanger tcpa et DRM.

    • [^] # Re: Virus ?

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

      Un virus quelconque doit pouvoir recuperer ta clef privée au moment ou tu la decode avec ta passphrase. Un avantage de TCPA, c'est que la clef privée est stockée en hard, et qu'on ne peut pas la récupérer. On peut juste demander de faire des signatures ou des decryptions, etc. Mais ceci peut déjà être fait par une carte à puce. Et l'avantage d'une carte à puce, c'est qu'on peut créer soi-meme une ou plusieurs clefs privée. On n'est pas obligé d'utiliser une clef privée qui a été générée par on ne sait qui, on ne sait où. Le TCPA risque de prendre un marché que ni Oberthur, ni GemPlus, ni Schlumberger n'ont réussi à prendre : la crypto perso en hard sur PC. Mais ça pourra être au détriment du choix de l'utilisateur, si jamais la clef privée est livrée d'origine. (ce qui me parait être une aberration...)

      • [^] # Re: Virus ?

        Posté par  . Évalué à 1.

        Tout à fait !

        D'ailleurs, on sait déjà que les clients n'achetent ça que si ils ne payent pas ! Autrement dit ça doit être intégré, et pour le même cout que la génération précédente. Les taiwanais avaient un port SmartCard sur certaines M/B il n'y a pas si longtemps, ça réduisait les couts mais pas assez, plouf.

      • [^] # Re: Virus ?

        Posté par  . Évalué à 1.

        Bof.

        Un virus peut aussi:
        - se substituer a l'interface logicielle (driver, etc.) entre toi et le hard qui remplace gpg et crypter avec une autre clef;
        - se substituer a l'interface logicielle (driver, etc.) entre toi et le hard qui remplace gpg et te faire croire qu'un message est authentique alors qu'il ne l'est pas;
        - utiliser le hard pour signer des documents a ta place (au besoin apres avoir recuperer ta passphrase aussi facilement (ou aussi difficilement) qu'avec gpg);
        - etc.

        Toute solution hard est de plus sensible a une attaque physique (quelqu'un qui a acces a la machine peut substituer un disque, une carte, une puce, voire la machine dans son entier si c'est le seul moyen), avec les memes resultats: te leurrer sur la clef que tu utilise, mentir sur l'authenticite, signer a ta place, etc.

        Ce qu'on enfoui en hard est un peu plus sercurise mais ca ne devient pas une panacee. C'est un fantasme!
        Ou alors il faut "signer" toute la machine y compris le soft, c'est l'optique TCPA, pour en faire un truc sur lequel on ne peut rien changer, et dans ce cas autant prendre une machine de cryptage hard dediee, c'est pas nouveau, ca existe depuis longtemps, meme avant l'ordinateur.

    • [^] # Re: Virus ?

      Posté par  . Évalué à 1.

      Justement si, GPG te fait la remarque que ta RAM n'est pas secure...

  • # Re: IBM présente TCPA

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

    Microsoft, le passé nous l'a amplement prouvé, ne s'est jamais déranger pour effectuer des opérations (contrôle logiciel, rappatriement de la liste des logiciels d'un PC vers un serveur microsoft ...) sans en informer l'utilisateur. Alors comment sauront nous quelles sont vraiment les intentions de TCPA/Paladium ? La technologie Paladium est une technologie à double tranchant et mise dans de mauvaises mains peut rapidement se révéler néfaste pour l'utilisateur. Si IBM se lance dans cette technologie c'est peut être une chance pour nous d'obtenir les informations que l'on souhaites concerant ce projet. A savoir les caractéristiques complètes pour connaître de quoi il retourne vraiment. Cela dit le problème de Paladium n'est toujours pas réglé et je pense que ce sera essentiellement de lui que viendra le problème !!!! A suive.

    • [^] # Re: IBM présente TCPA

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

      Si IBM se lance dans cette technologie c'est peut être une chance pour nous d'obtenir les informations que l'on souhaites concerant ce projet. A savoir les caractéristiques complètes pour connaître de quoi il retourne vraiment.
      IBM ne se lance pas dans TCPA/paladium pour mieux savoir de quoi il en retourne puisqu'il ne participe pas à paladium et sais déjà tout ce qu'il y a à savoir à propos de TCPA (ils ont participé à sa création et en plus les specifications sont publiques).

  • # Si je veux utiliser une carte à puce, de quoi est-je besoin ?

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

    Bon, il semblerait que IBM tendent à nous expliquer que TCPA n'est finalement qu'un moyen de se débarrasser de la carte à puce (non américaine). Au fait, si je veux un lecteur de carte à puce pour mon PC, j'en trouve où et à quel prix ? Je trouve des cartes à puces style gold ou silver mais ce ne sont que des cartes avec pics intégré. Ou trouver des cartes avec crypto intégré ? Si je veux y stoquer ma clef privée SSH et faire fonctionner le tout, de quoi ai-je besoin pour lui faire générer la clef de session ? Si je veux utiliser GPG même question (sachant que la carte peut crypter en interne un email).

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

    • [^] # Re: Si je veux utiliser une carte à puce, de quoi est-je besoin ?

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

      La dernière fois que j'ai cherché, c'était directement chez les "fondeurs", à savoir Schlumberger ou Oberthur, et il fallait compter 50-60 euros pour le lecteur et environ 80$ pour 5 cartes à puce avec cryptoprocesseur intégré. Maintenant ya le choix de la techno (souvent propriétaire) à l'intérieur, soit du java (cf. les javacard), soit du multos, soit du microsoft, soit... Coté soft, il me semble qu'il est prévu dans openssl de gérer des systèmes de crypto externes/hardware, mais je ne suis pas sûr que tout soit disponible, du moins sous linux...

      • [^] # Re: Si je veux utiliser une carte à puce, de quoi est-je besoin ?

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

        mouais.

        Y'a pas de puce "usb" avec des lecteurs à 10eur ? (en + de la norme à 9600, pour lire les autres type de cartes.).

        Quoique les lecteurs de smart card/ compact flash coute entre 30 et 60 eur.

        80$/5=16eur par carte cela ne me parrait pas hors de prix. (pour faire du gpg complet, des clefs ssh de sessions, décryptage de fichier perso (?)...) Avec des trucs comme ça, je me pointe sur une machine que je ne connais pas, je me loggue où je veux et même le root de la machine ne peut pas me piquer mes passwd.

        Y'a pas de boites de libre qui veut se lancer la dedans :)

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

        • [^] # Re: Si je veux utiliser une carte à puce, de quoi est-je besoin ?

          Posté par  . Évalué à 2.

          Les lecteurs de carte USB sont des connecteurs, pas des lecteurs en tant que tels, donc devraient couter que dalle.

          Mais on trouve maintenant des cartes à puce USB au format dongle USB donc là plus de lecteur du tout (mais tu tapes ton pin sur le PC avec une carte en permanence sous tension, moi perso je toucherais pas à ça).

          • [^] # Re: Si je veux utiliser une carte à puce, de quoi est-je besoin ?

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

            Qu'est-ce que cela peut foutre que la puce sois sous tension ? (y'a pas grand monde d'expert en sécurité des carte à puce ici)

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

            • [^] # Re: Si je veux utiliser une carte à puce, de quoi est-je besoin ?

              Posté par  . Évalué à 3.

              Quel est l'avantage pour un black-hat de taper sur un poste ADSL plutôt qu'un en RTC ? Le poste ADSL a de grande chance d'être plus souvent dispo voire en permanence. Là c'est pareil, tu tapes ton pin et ta carte reste dans un état plutôt interessant. Imaginons un poste Windows équipé PC/SC avec un BO ou plus légalement un soft de télémaintenance :

              1/ je peux voir le pin saisi au clavier :)
              2/ je peux taper dans la carte :)

              Finalement faut être le dernier des abrutis pour penser être sécurisé avec PC/SC, enfin bon...

          • [^] # Re: Si je veux utiliser une carte à puce, de quoi est-je besoin ?

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

            Les dongles usb, c'est bien à prioris. Mais le jour ou tu te balades avec 3 dans la poche et que tu dois aller chercher les prises de l'ordi sous le bureau, tu aurais préférer avoir des cartes à puces.

            Acheter un hub usb pour l'avoir sous l'écran coùte aussi chère qu'un lecteur de cartes et tes 3 cartes peuvent élire domicile dans ton portefeuille sans alourdir et/ou déformer tes poches.

            Le pin sur le lecteur de carte rajoute de la sécurité.

            Il faudrait voir pour faire de l'open hardware sur un lecteur de carte à puce USB+iso machin (pour être compatible avec plein de truc) à code pin. On file ça au chinois qui seront tout heureux d'innonder le marché avec.

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

    • [^] # Re: Si je veux utiliser une carte à puce, de quoi est-je besoin ?

      Posté par  . Évalué à 6.

      Pour info,

      Les industriels, qui font du hard et s'en foutent du LL qui est à l'opposée de leur philosophie, ont accepté que MS uniformise leurs drivers lecteurs/cartes incompatibles grace à PC/SC.

      Le problème de PC/SC est qu'il ne supporte que les lecteurs "stupides" (sans afficheurs et claviers, trop chers !). Donc le code est tapé sur le PC... Bravo la sécurité ! En plus PC/SC laisse la carte à puce sous tension.... ReBravo ! Du vrai sabotage...

      Les industriels de la carte ont donc attendu PC/SC 2 qui devait supporter les pinpads (donc avec saisie du pin sur le lecteur lui même). PC/SC 2 n'est jamais arrivé, MS a jeté l'éponge.

      Merci MS de les avoir planté ! Fallait-il qu'ils soient naïfs quand même...

      Donc deux catégories de lecteurs, avec (avec drivers proprios) ou sans clavier (PC/SC, cf Muscle sous Linux). Soit une soluce pourrie mais standard soit proprio mais secure. MS a déjà neutralisé la carte à puce sur les PC.... Merci qui ?

  • # Jy arrive pas

    Posté par  . Évalué à 5.

    J'arrive pas à me convaincre que TCPA est un réel plus s'il ne fait que du cryptage/authentification de donnée. Par exemple : - pourquoi contrôler le noyau lors du chargement ? - pourquoi vouloir que certaines données du disque dur soit crypté ? Si un serveur est sensible, on le met dans un coffre fort. Pourquoi pas faire du papier crypté aussi. - TCPA a certain effet de bord que ne semble pas présenter un carte à puce ? - TCPA n'apporte rien par rapport à ssl par exemple pour des services distants. - Pourquoi vouloir laisser une seule puce crypter mes données alors qu'il y a plein d'autres solutions de cryptage. Pourquoi cette puce est forcément plus sure que ssl etc... Je suis pas un spécialiste de ces trucs et je suis pas un passionné de cryptage/sécurité etc... Je me limite au minimum mais de façon stricte. J'ai peut-être encore les oreilles qui bourdonne de FUD mais l'explication d'IBM n'arrive à me convaincre. Je ne pense pas qu'il y ait un grosse gain dans çà. J'ai l'impression que c'est du détail. Çà me fait passé à cette info que j'ai entendu ce matin. Une dame est resté plusieurs heures dans un ascenseur en panne et a eu un malaise. Une psychose s'installe, on arrête plusieurs assenceurs par précaution, et on renforce les dispositions sur la sécurité des ascenseurs. Malheureusement, on oublie de dire qu'il y a beaucoup, beaucoup, beaucoup plus d'accident dans les escaliers que dans les ascenseurs (d'ailleur j'ai lu que l'ascenseur était le monde de transport le plus sure du monde). Qu'importe, on fait peur aux gens et on les obliges à prendre les escalier. Mais on ne parle jamais des "risques" pris lorsque l'on prend les escaliers... Bref, c'est comme d'hab. On met les projecteurs sur un détail et on oublie l'essentiel : - bécane à jour. - service bien configuré. - mot de passe pas trivial. - utilisation de service sure. - pas de mot de passe en claire. - se délogguer quand on se casse. - ne pas se trimbaler pas avec des papier confidentiel. - etc. - etc.

  • # Une citation

    Posté par  . Évalué à 5.

    Quels que soient les buts réels derrière la mise en place d'un système tel que TCPA, j'aime beaucoup cette citation : ) : « There is no "serial number revocation list". Could someone create such a list? Yes, this could be done, with or without TCPA. There is no end to the infinite number of stupid things that could be done on a Turing complete system. TCPA simply does not do this. »

  • # Re: IBM présente TCPA

    Posté par  . Évalué à 2.

    1) Cela fait quelque jours, qu'on parle de cette
    article dans a la fin des commentaire de l'artcile
    sur TCPA/Palladium.

    2) L'auteur aurait put lire, et se renseignier un
    minimum avent d'ajouter a l'amalgame TCPA / Palladium.

    TCPA, c'est un puce de cryptage pas forecement dans
    le processeur, par exemple les grands parents de TCPA
    sont present dans la plus part des PC portable, ce sont
    eux qui permettent l'utilisation de disque dur cryptés
    et autre. En gros TCPA est une puce a tous faire du
    cryptage dont l'interet principal est la gestion complete
    des jeux de clées, privées qui n'on plus a étre stockés
    sur un media et son beaucoup moin vulnerable que via
    software car generés dans la puce, et n'en sorte pas.
    TCPA ne s'occupe pas de l'execution ou de quoi que ce soit
    en rapport avec les certifications.
    Le principale confusion vient du fait que le premier
    chapitre des spec de TCPA sont assez difficile a comprendre et
    traite de la gestion interne et de la verfication de la puce,
    via une signature interne només root of trust, cette v
    erification n'est qu'interne a la puce et ne touche que
    ses fonctions, cela est expliqué assez bien par l'ingenieur
    d'AMI BIOS ( l'un des premiére firm a fournir un BIOS qui
    supporte les puces et les processeur TCPA ), cela ne
    servirait pas a grand chose de s'equiper de telle precotions
    si il suffisait d'un flashage de Bios ou d'un modification
    du secteur d'amorcage pour detourner la puce, dans tous les
    cas ces verification ne sont necessaire que si vous avez
    imposer un niveau de confience minimum a un jeu de clée pour
    qu'il pusse étre utilisé par la puce, c'est donc configurable.

    http://interviews.slashdot.org/article.pl?sid=03/01/17/1430214&(...)

    Un article qui complete bien celui du technicien d'IBM

    3) Palladium, si ce n'est le nom et que ca utilisera un mysterie systéme SCP
    miracle, avec un systéme d'Hypersystem ( ring -1 dans le processeur, en
    gros il y a un systéme au dessus de l'OS, surment pour gerer la "confience" )
    que ce sera avent tous pour le DRM, et que c'est completement opaque puisque
    méme les constructeur majeur comme AMI n'on pas méme été approchés par MS
    sur le sujet.

    4) don je le repéte TCPA, il y a un driver libre, cela fonctione sous linux,
    les spec sont dispo et ouverte, donc c'est plustot bien. Palladium, c'est
    du DRM, c'est Microsoft et c'est complétement obscure, donc c'est forcement
    mal.

    P.S. ca demande verification mais de nombreux portable equipés des derniers pentium serait déjà equipés de processeur equipés TCPA, qui serait pour le moment bridé dans leurs par l'absence de BIOS compatible.

    • [^] # Re: IBM présente TCPA

      Posté par  . Évalué à 1.

      Des puces qui génèrent et stockent des clés privées, et cryptent avec sans jamais donner accès la clé: c'est bien TM (des cartes à puces et des puces USB fournissent deja ce type de service, avec + de sécurité d'ailleurs car l'utilisateur peut controler chaque accès au cryptage par sa clé par un code pin)

      Par contre s'il est possible pour un OS de type MS de demander à ce que la clé qu'il vient de générer ne soit pas accessible aux autres OS ou si le hardware change, alors je crie DANGER, DRM !

  • # Re: IBM présente TCPA

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

    The "trusted" boot functions provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence. Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has back-doored the operating system, the PCR value will not match, and the unseal will fail, thus protecting the data. The initialization and management functions allow the owner to turn functionality on and off, reset the chip, and take ownership. This group of functions is somewhat complex, to provide strong separation of what can be done at BIOS (boot) time, and what can be done at normal run-time,

    Il faut encore qu'il explique comment les mesures ont lieu ! Comment faire la différence entre un noyau corrompu et un noyau fraichement recompiler ? Parce que l'on a mis le hash dans le TPM ? Et donc la puce refuse de fonctioner ?

    But to argue thart trusted computing is bad because it can support DRM is fallacious - it completely ignores the security TCPA can add to good applications, such as the security of my personal authentication keys, or my personal encrypted files. See the companion paper, which goes into more detail on the good things that can be done with TCPA.

    Mais qui conserve la master key !!

    Secondly, the obvious application of TCPA is to enable individuals to secure their private keys, and to secure their encrypted data against viruses or other attacks that compromise the operating system, not DRM.

    Il ne dit toujours pas comment.

    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.

    La fameuse clef à bannir. Ils ne sont pas contre la virer finalement. Il faudrait bien faire gaffe à ce que cela ne soit pas implémenté (et donc rendu obligatoire par windows et ensuite, il y aura le rien "ne marche sans mais vous pouvez toujours le déactivé")

    "Allow for complete privacy." Disabling the endorsement key provides complete privacy. Ensuring complete privacy while using any form of endorsement key is clearly very difficult. The operations around the Endorsement Key are actually meant to protect user privacy by enabling the generation of multiple abstracted identities. The specification went to great lengths to define a process whereby the Endorsement Key functionality is limited to the generation of these identities only. A privacy CA can be selected by the user as the only entity that can link the Endorsement key with a specific identity. A different privacy CA can be used for each identity if desired. The user has complete control over the choice of if and how to use the endorsement key.

    Mieux. :)

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

    • [^] # Re: IBM présente TCPA

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

      En résumer, le TCPA c'est une carte à puce qui doit en plus faire des mesures au boot pour se désactiver (hash du noyau stoqué en interne comme pour la Xbox mais modifiable par l'utilisateur ?). Est-ce vraiement utile en conparaison d'une carte à puce ?

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

Suivre le flux des commentaires

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