Génération de clefs à partir du bruit électrique de la puce

Posté par . Modéré par Benoît Sibaud.
Tags : aucun
0
29
jan.
2003
Matériel
VIA vient d'annoncer un nouveau processeur VIA C3 basé sur une nouvelle architecture appelée 'Nehemiah'.
(...)
Autre nouveauté, le Nehemiah intègre une technologie appelée PadLock Data Encryption Engine. Cette technologie, qui fera plaisir aux défenseurs de sécurité et de copyright, permet en fait de générer des clefs complètement aléatoires à partir du bruit électrique de la puce.

Note du modérateur : les fonctions de sécurité dans les processeurs sont à la mode cette année (cf TCPA)
  • # Re: Génération de clefs à partir du bruit électrique

    Posté par . Évalué à 10.

    Je ne penses pas que ce soit une fonction à la TCPALLADIUM, bien au contraire c'est tres interessant de pouvoir trouver des sources de données aléatoires dans un ordinateur !
    Apres il faut voir ce que l'on en fait !
    • [^] # Re: Génération de clefs à partir du bruit électrique

      Posté par . Évalué à 2.

      En l'occurence, si je me souviens bien d'une réponse d'un mec de VIA aux trolls poilus qu'on a pu lire ici et sur slashdot: TCPA c'est exactement ce genre de choses: des facilités à la cryptographie embarquées dans les cartes mêres.

      Palladium en revanche apporterait une approche beaucoup plus directive et restrictive (en se servant des facilités cryptographiques de TCPA).
      • [^] # Re: Génération de clefs à partir du bruit électrique

        Posté par . Évalué à 1.

        je te conseille de relire l'article sur les specs TCPA publiées par IBM
        https://linuxfr.org/2003/01/28/11173.html(...)
        tu peux y lire qu'il est possible d'interdire à un OS alternatif d'accéder aux clés générées par un OS MainStream, et donc d'interdire à l'OS alternatif d'accéder aux contenus cryptés avec ces clés.
        • [^] # Re: Génération de clefs à partir du bruit électrique

          Posté par . Évalué à 3.

          Tout à fait normal !

          De la même façon que si Pierre et Paul se partagent un poste et que l'OS génère des clés pour chacun, c'est à l'OS de vérifier que Paul ne puisse pas utiliser la clé à Pierre et vice-versa.

          L'important c'est de vérifier qu'un OS en dual-boot puisse générer ses propres clés sans que les autres OS installés ne puissent taper dedans /!\

          On ne demande pas à MS qu'il nous livre ses secrets, mais qu'il laisse vivre en paix ses concurrents.
          • [^] # Re: Génération de clefs à partir du bruit électrique

            Posté par . Évalué à 2.

            Remarque1: il est possible de faire la meme chose en protégeant ses clés par une passphrase (ce que font openSSH et GPG), et aussi, en + sécure, avec une carte à puce (ou clé USB) qui exige un code pin.

            Le probleme est que les fournisseurs de contenus et de softs vont t'envoyer des contenus cryptés avec des clés publiques dont les clés privées associées ne sont accessibles que par Windows.

            Dès lors ces contenus ne seront pas accessibles sous Linux.
            C'est inacceptable.
            • [^] # Re: Génération de clefs à partir du bruit électrique

              Posté par . Évalué à 1.

              Reponce sencé de l'ingenieur IBM, on ne peut étre responcable du nombre inimaginable de conneries que les gesn peuvent faire avec quoi que ce soit, TCPA n'en fait pas exception, de plus on peut trés bien faire ce que tu decrie sans TCPA, ou sans palladium, le seul trucs c'est qu'on ne pourra pas cracker la paire de clée ou trés difficilement comme tu aurais comme quelqu'un aurait pue le faire avec une solution 100% soft.

              Si de distributeur stupide, utilise des systéme retrictif ce n'est pas a nous de cracker leurs contenue, mais a eux de faire en sorte que nous puissions les lire, sans quoi on se doit de ne pas utiliser leurs service !

              Il y avait des site IE only avent TCPA, on peut soit ne pas le visiter et pourrire la boite du webmaster, soit changer son agent ID pour faire de la pub a IE dans les stats du serveur... La deuxiéme solution n'est evidament pas la bonne.
              • [^] # Re: Génération de clefs à partir du bruit électrique

                Posté par . Évalué à 1.

                Reponce sencé de l'ingenieur IBM, on ne peut étre responcable [...]

                Pitié pour l'orthographe, comme d'habitude...

                Juste par curiosité, quel est ton métier ? Je n'ai quasiment jamais vu quelqu'un écrire aussi mal, surtout pour une personne qui a des connaissances techniques non triviales. Ca ne te joue pas des tours ?
  • # C'est aléatoire un bruit ?

    Posté par . Évalué à -2.

    Parceque que ce soit n'importe quoi d'accords, mais j'ai un doute sur le coté réellement aléatoire du truc.
    • [^] # Re: C'est aléatoire un bruit ?

      Posté par . Évalué à 10.

      Si, un bruit dans une jonction est un bruit blanc preque parfait (pas parfait car sa bande de frequence est limitée).

      Par contre en pratique y'a du bruit non aléatoire qui vient se greffer dessus: bruit d'alim, de mesure etc...

      Mais c'est de loin supérieur a ce que peut fournir un générateur software.
      • [^] # Re: C'est aléatoire un bruit ?

        Posté par . Évalué à 2.

        D'ailleurs, je crois que c'est utilisé par la Française des jeux pour le jeu "rapido"
        • [^] # Oui mais la carte coute cher

          Posté par (page perso) . Évalué à 2.

          A la Française des jeux ils utilisent une carte qui genere des nombre aléatoire qui coute dans les 4000F (il y avais un petit reportage la dessus dans science & vie au moment de la sortie du jeux)

          La c'est integré dans un processeur qui tout entier coute 10x moins cher :)

          (ensuite il faut voir la capacité de nombre aléatoire/seconde mais je ne me souviens plus des chiffres pour la carte a 4KF)

          [moua]
      • [^] # Re: C'est aléatoire un bruit ?

        Posté par . Évalué à 5.

        Autant je comprend ce que tu dis à propos de la justification de la limitation, par la bande passante, du bruit thermique d'une diode et des dipôles électriques en règle générale (me semble-t-il) -cf Nyquist-. Autant je ne suis pas convaincu par ce que tu dis sur les générateurs software. Primo parce qu'ils s'appuient sur des considérations hardware, secundo parce qu'ils vérifient la bonne "blancheur" du bruit (la distribution du tirage et ses moments), je pense entre autre aux Numerical Recipes (OpenSource mais payant, dommage...)
        Un autre bon générateur hardware de nombres aléatoires est une carte d'extension incluant un isotope radioactif (il me semble que cela existe déjà).
        • [^] # Re: C'est aléatoire un bruit ?

          Posté par (page perso) . Évalué à 1.

          > "Un autre bon générateur hardware de nombres aléatoires est une carte d'extension incluant un isotope radioactif (il me semble que cela existe déjà). "

          Wo-h-ow ! Tu peux nous en dire plus ? stp...
          • [^] # Re: C'est aléatoire un bruit ?

            Posté par . Évalué à 5.

            Ecoute, si ma mémoire ne me trahit pas trop, cela remonte à 1 ou 2 ans, j'avais regardé Archimède sur Arte, consacré aux nombres aléatoires et ils avaient évoqué l'existence de carte pour ordinateur (sans plus de précision me semble-t-il) équipée d'une capsule contenant un élément radioactif (à longue durée de vie donc faiblement radioactif) et qui permettrait de générer une suite aléatoire puisque les désintégrations ne sont pas prévisibles (un collègue de IN2P3 pour confirmer ?).
            C'est tout ce que je sais. Dans une enquête policière, on appellerait ça un témoignage peu fiable...
    • [^] # Re: C'est aléatoire un bruit ?

      Posté par . Évalué à 3.

      J'avais entendu parler de trucs similaires il y a quelques années. Des chercheurs avaient parlé d'utiliser le bruit thermique du processeur pour générer les nombres aléatoires.

      Le bruit thermique ou électrique est une excellente source de données aléatoires car il est totalement imprévisible et ne dépend d'aucun paramètre reproductible. En cela c'est beaucoup plus efficace que de générer le nombre aléatoire à partir de l'horloge système.
      • [^] # Re: C'est aléatoire un bruit ?

        Posté par . Évalué à 1.

        hum, ça me rappelle des choses tout ça!

        http://tnemeth.free.fr/fmbl/linuxsf/24.html(...)
        ok je [ ]
        • [^] # Re: C'est aléatoire un bruit ?

          Posté par . Évalué à 1.

          Arf, j'avais pas eu le courage de rechercher l'épisode (je suis un grand fan de l'histoire des pingouins).

          En tout cas la réalité rejoint la fiction. Et AMHA, je crois que pour l'instant il n'y a qu'avec ces systèmes qu'on peut être quasi-certain de la fiabilité de la génération de nombres aléatoires.

          Si je me souviens bien de mes cours de DEUG, chaque nombre aléatoire est généré à partir du précédent et d'une opération très simple (suivie d'un modulo), donc il est (en théorie) très facile de prévoir la suite de nombres aléatoires en connaissant le premier nombre et la regle de calcul du suivant.

          Enfin ça c'est pour les générateurs assez basiques, mais même les générateurs softwares les plus sophistiqués ne sont pas beaucoup plus difficiles à casser, pour peu qu'on connaisse les données de départ et l'algo (et même en closed-source un algo ça peut se retrouver).

          Bon évidemment c'est un peu de la paranoïa, mais de nos jours, je me demande si on n'est jamais trop paranoïaque...
    • [^] # Re: C'est aléatoire un bruit ?

      Posté par . Évalué à 10.

      "Aleatoire" doit etre preciser, le besoin de la cryptographie ca n'est pas le hasard (au sens philosophique) mais la non-predictabilite.

      http://www.ietf.org/rfc/rfc1750.txt(...)
      (j'ai la flemme de chercher des articles scientifiques en complement)

      Pour faire un generateur de nombre aleatoire, il faut des sources de bruit non-predictible.
      Sous linux, on utilise par exemple les evenemetns clavier + les evenements reseaux + les i/o etc. pour alimenter le pool de /dev/urandom.
      Ajouter un RNG hard type i810 ou PadLock machin parmi les sources de /dev/urandom ameliore encore sa qualite (i.e. sa non-predictabilite, voire son debit).
  • # Re: Génération de clefs à partir du bruit électrique

    Posté par . Évalué à 7.

    Le PadLock machin c'est un RNG (random number generator) comme, par exemple, ceux intégrés aux chipsets Intel depuis l'i810. Pour etre basique c'est un dé électronique, rien de plus.

    Le lien avec TCPA est loin d'etre evident!

    http://www.via.com.tw/en/viac3/padlock.jsp(...)
    file:///usr/src/linux/Documentation/i810_rng.txt
  • # Plus pécisement

    Posté par . Évalué à 2.

    La description qu'en fait VIA est là :

    http://www.via.com.tw/en/viac3/padlock.jsp(...)

    Et ça serait bien de rajouter le lien dans la news.
    • [^] # Openbsd

      Posté par . Évalué à 3.

      Via a deja transmis un pdf au team d'openBSD c'est plutot sympa.
      Pas comme sun :)
      a noter que transmeta joue le jeu aussi avec OpenBSD.
  • # Re: Génération de clefs à partir du bruit électrique

    Posté par . Évalué à 5.

    Mouarf ! Ils ne disent même pas si ça sera FIPS-140 ou pas...
    Comme si ils étaient les premiers à implémenter un gun...

    Quel tapage pour un random dont on connait même pas encore le niveau de certification !

    Pour infos, ce type de rng est courant mais alors...

    Par contre la news ne parle pas de la dissipation thermique qui est superbement réduite, mais trolle bien comme il faut : fera plaisir aux défenseurs de sécurité et de copyright, euh random c'est basique quand même ! Vous faites une fixation sur TCPA ou quoi ? Vous ne dites même pas qu'il arrive à 1 Ghz ! Que l'archi a été revue ! Que ça donnera une nouvelle carte EPIA qui cette fois jouera les mp4 comme il faut ! Bref, le plus interessant était dans les (...) !
  • # Re: Génération de clefs à partir du bruit électrique

    Posté par (page perso) . Évalué à 1.

    Infineon le fait depuis un certain temps déjà....

    http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=2(...)

Suivre le flux des commentaires

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