Une faille majeure de la cryptographie courante

Posté par (page perso) . Modéré par Florent Zara.
Tags :
0
20
nov.
2006
Sécurité
Le cryptologue allemand Jean-Pierre Seifert (universités d'Haïfa et d'Innsbruck) aurait rendu possible l'exécution d'attaques basées sur la menace de type '"analyse de prédiction de branche" (BPA).

Dans une note confidentielle, le chercheur met en avant qu'il a réussi à récupérer une clé de chiffrement de 512 bits en quelques millisecondes.

Il s'agit d'un véritable bouleversement dans le milieu de la cryptographie. En effet la parade habituelle consiste à allonger la longueur de la clé de chiffrement. La technique découverte par Jean-Pierre Seifert consiste à analyser le comportement du processeur lui-même afin de déduire statistiquement la clé de chiffrement.

La seule parade pour l'instant consisterait à désactiver le processus de prédiction du processeur mais selon le chercheur "Une telle mesure ralentirait par quatre le microprocesseur (...)".

Les résultats des travaux de Jean-Pierre Seifert sont attendus lors de la prochaine conférence RSA, début 2007

NdM : Cette attaque implique la présence d'un logiciel espion sur la machine effectuant les opérations cryptographiques et dans ce cas il existe souvent d'autres moyens pour obtenir la clé.
De plus, cette attaque ne marchera pas si les opérations cryptographiques sont effectuées sur un matériel distinct du processeur, par exemple un token cryptographique. L'impact est donc surtout pour le grand public et en particulier les échanges sur internet sécurisés par SSL. Il semble qu'Intel ait choisi la politique de l'autruche et se borne à déclarer que la prochaine version d'Openssl réglera le problème, en désactivant la fonction de prédiction du processeur, si besoin est.

Si la percée du professeur Seifert est confirmé par ses pairs, les conséquences de cette découverte risquent de modifier les modalités des échanges électroniques tels qu'ils se pratiquent aujourd'hui.

Aller plus loin

  • # Ouch

    Posté par . Évalué à 5.

    Le problème majeur est que la prediction de branchements est une optimisation majeure qui booste énormément les performances (parce que les branchements, c'est le mal, donc si on peut les prévoir, ça permet de limiter la casse).

    Je ne connais pas grand chose en cryptographie, mais existe-t-il des méthodes de cryptages qui échappent à ce problème ? Je suis parano (attention, hein, ce n'est pas parce qu'on est parano que personne ne nous en veut...), et ça me fait un poil peur que mes clés ssh 2048 posent problème...
    • [^] # Re: Ouch

      Posté par . Évalué à 1.

      Etant donné que ça se passe au niveau du processeur, tous les algorithmes de crypto sont sensibles à ça. Plus encore tous les algorithmes peuvent être tracés par un processus malveillant en environnement utilisateur.

      La solution la plus simple, c'est de vider tous ces caches sur un changement de contexte : TLB, mémoire cache, prédiction de branchement.

      Un autre solution serait d'intégrer la gestion des droits au niveau de ces caches, mais là Intel et les autres ne vont pas être contents.
  • # TCPA

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

    n'est pour le moment qu'une puce proposant des promitives pour la cryptographie et encore complètement inoffensive commence a se répandre dans les ordinateurs grand public. Je pense que ce pourrait être une solution même si je sais que certains voient rouge dés qu'on prononce ce mot.
    En effet, je suppose que la puce propose de générer une clef de manière plus sécurisée, sinon, je ne vois pas bien son interêt.
    • [^] # Re: TCPA

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

      Allez, je me joue la parano ...

      Et puis comme j'y pige rien à ce principe de prédiction ... (Bin, oui, si on fait une prédiction, il faut bien vérifier si elle est juste, donc tout de même faire le calcul, donc je ne vois pas en quoi ca accélèrerait les choses ...)

      Bref, est-ce que ca ne serait pas un fake alarmant, Intel, fait le timide au début ... et d'un seul coup, ils nous sortent pas solution miracle : TCPA !
      Les gens qui ont eu peur de cette faille annoncée à grands coup médiatique se rue sur les étiquettes TCPA sans plus réfléchir à leur vie privée ...

      Moi, j'attend un "proof of concept" avant de sonner l'alarme ...
      PS: une explication sur la prédiction serait aussi la bienvenue
      • [^] # Re: TCPA

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

        C'est toujours embêtant de trouver une faille de sécurité mais à mon avis pas dramatique. Ce qui me m'étonne le plus est le bruit que fait cette nouvelle.

        Je ne serais effectivement pas étonné du tout que cette annonce ait été exploitée pour justifier TCPA et le verrouillage des PC.
        C'est justement ce que l'on peut lire dans le document toujours d'actualité "FAQ TCPA/PALLADIUM/TC/TCG/LAGRANDE/NGSCB/LONGHORN" http://www.lebars.org/sec/tcpa-faq.fr.html
        • [^] # Re: TCPA

          Posté par . Évalué à 6.

          Tout à fait d'accord sur le fait que l'on semble assister à une sorte de compagne médiatique savamment dosée en deux temps... à moins que ce ne soit mon côté paranoïaque qui resurgisse ? :-/

          Dans une premier temps, on nous distille quelques annonces sulfureuses. Tiens, en voici une autre du même acabit ici: http://www.securityfocus.com/brief/360 (en anglais), et dont la conclusion est identique: vive TCPA, c'est pour bientôt, rassurez-vous.

          Et justement, dans un second temps (miracle!), nous apprendrons que la solution à tous nos maux d'ordre sécuritaire est déjà prête ! Eh oui, une bonne partie des cartes mères possède une implémentation, un verrouillage matériel fonctionnel.

          Donc, dans la série "Y'a plus qu'à...", on n'attend plus que l'activation.

          Il faut sans doute qu'un terroriste numérique nous fasse sauter une centrale énergétique quelque part pour que...
          ...euh, pardon. Mon esprit s'égare dans la science-fiction, là.

          <mode humour noir>
          Bref, en 2007, votez TCPA. Ch'est ben bon, mangez-en, etc...
          </mode humour noir>

          Après le logiciel libre, le matériel libre arrivera-t-il à temps, lui ?
          • [^] # Re: TCPA

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

            Ça me rappelle ce que m'expliquait mon médecin à propos du "mongering" de l'industrie pharmaceutique: on invente une nouvelle maladie par exagération ou assimilation de symptômes connus, et juste après, miracle, sort la molécule qui peut soigner la nouvelle maladie.

            Quand on parle tant de traçabilité, on serait en droit d'exiger celle de l'information: d'où vient cette info? Le journaliste a-til enquêté tout seul? Ou a-t-il été contacté par une agence de relations presse? Dans ce cas, qui la payait?
          • [^] # Re: TCPA

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

            Le matériel libre existe déjà: il s'agit de l'OpenSparc de Sun. Je suis très étonné qu'aucun fondeur chinois ne l'ait encore produite, ni qu'aucun programme européen n'ait été lancé pour la produire et assurer l'indépendance technologique du continent...
            • [^] # Re: TCPA

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

              Les fondeur/designer européens existent. Il y en a même des (bon d'accord un) français (bon d'accord franco-italien): STMicroelectronics.
      • [^] # Re: TCPA

        Posté par . Évalué à 10.

        Pour faire simple...

        Quand tu exécutes une instruction, il faut d'abord la lire (chargement dans le pipeline d'instructions), décoder l'instruction et les éventuels arguments qui peuvent se trouver dans la mémoire centrale, dans un cache ou dans des registres puis exécuter... Tout ça se fait en plusieurs étapes dont le nombre varie en fonction de l'architecture du processeur. Quand une instruction en est à la phase d'exécution, la prochaine est en cours de décodage, la suivante encore en train d'être chargée dans le pipeline, etc.

        Seulement quand tu as un branchement conditionnel (if), il faut pouvoir déterminer quelle est l'instruction suivante à exécuter : celle du branchement "if true" ou celle du branchement "if false". La prédiction essaie de déterminer quelle sera celle que l'on va effectivement exécuter. Et si la prédiction a bon, tout se passe bien, on continue le flux d'instructions du pipeline. Sinon, il faut vider le pipeline car on y a chargé des instructions du mauvais branchement qui n'a pas à être exécuté. Il faut repartir avec un pipeline vide et on perd plusieurs étapes avant d'avoir à nouveau une instruction décodée prête à être exécutée.

        --
        http://www.tessier-net.org
        • [^] # Re: TCPA

          Posté par . Évalué à 3.

          Et donc la question qui vient apres est :
          en quoi est-ce que cela permet de gagner du temps ?
          Comment est faite cette prédiction ? Si je veux gagner du temps, il faudrait que cette prédiction ait une probabilité assez importante pour ne pas avoir a dépiler le pipeline et recommencer les etapes de l'instruction suivante effectivement lancée.
          • [^] # Re: TCPA

            Posté par . Évalué à 4.

            On va prendre un exemple concret : pendant un temps les processeurs Intel (je sais pas si çà vaut pour AMD ni si çà a pas changé depuis) considéraient que le if { foo } avait 80% de chances de s'exécuter par rapport au else { bar }, et commençaient à charger le code de cette partie avant même d'avoir pu évaluer le test conditionnel.

            Si la prédiction était juste, on gagne du temps : le processeur a chargé le code pendant qu'il calculait la condtion. Par contre si elle était fausse, il faut vidanger le code chargé pour rien, puis charger le bon code : pendant ce temps il ne peut rien faire d'autre, et perd donc du temps.

            A une échelle humaine c'est difficilement quantifiable vu que çà se joue sur des millièmes de secondes (si c'est pas moins), par contre pour le processeur c'est énorme. Depuis les processeurs ont des instructions de prefetch, mais il me semble qu'elles ne concernent que les données, pas les branchements conditionnels (ex: je vais avoir besoin des données à telle adresse, assure toi qu'elles soient dans le cache pendant que tu calcules autre chose stp merci)

            Certains processeurs (chers) ne s'encombraient pas de tant de finesse : pendant le calcul de la condition ils chargeaient les deux blocs possibles, exécutant ensuite celui qui s'était avéré bon (qui a dit brutal ?) ;)
          • [^] # Re: TCPA

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

            en quoi est-ce que cela permet de gagner du temps ?

            Sur un pentium 4, l'architecture pipeline contient plus de trente niveaux. Cela signifie que la sortie effective du processeur à environ 30 instructions de retard par rapport à la lecture du code exécutable. Si tu as besoin des résultats d'une comparaison pour faire un branchement conditionnel, ça signifie que tu vas attendre le résultat pendant 30 cycles d'horloge avant de sauter à la bonne adresse ... je te laisse juge pour la performance d'une boucle for ...
            Une solution peut consister à essayer de prédire les dits branchements, de façon à ce que le cpu précharge les instructions qui correspondent alors au saut prédit.

            Comment est faite cette prédiction ?

            Il existe plein de méthode plus ou moins sophistiquées, mais pour donner un exemple simple, on peut dire par exemple qu'on prédit que le saut pris sera en arrière (c'est simplissime, mais pas idiot !)
            Bien sûr il existe des méthodes bien plus sophistiquées que je n'ai pas le temps de détailler ici.

            Pour info, la qualité prédiction des branchements de cpu est vraiment cruciale pour des cpu comme le pentium 4 (avec beaucoup d'étages pipelines), car à chaque fois que le prédicteur se vautre, il faut vider le pipe et recharger tout avec le bon code exécutable !
            Cela explique en partie pourquoi les cpu d'amd sont bien plus performants que les cpu intel (a fréquence égale) pour des applications difficiles à prédire (ie : jeux, compilation ...), alors que les cpu d'intel vont plutot roxer sur des trucs monotones (compression de données ...)

            tu pourra trouver des éléments de compréhension ici :
            http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=b(...)

            Adhérer à l'April, ça vous tente ?

            • [^] # Re: TCPA

              Posté par . Évalué à -1.

              Dans les premières versions de prédiction Intel avait fait simple,
              c'etait simplement une analyse statistique de ce qu'il se passait sur le CPU.
              L'analyse du code executé implique donc une optimisation du CPU.
              Simple ... mais pas si efficace que ca puisque dans mes souvenirs ( ca commence à dater) seul 15% des branchements predictifs étaient valides.

              Fox
              • [^] # Re: TCPA

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

                Je n'ai pas de source sous la main, mais je suis sûr que le simple exemple que j'ai cité dépasse les 65% de prédictions valides ...

                Cependant, tes souvenirs ne sont peut être pas erronés : intel a toujours été meilleur en marketing qu'en architecture de prédiction de branchement ! (cf prescott et les autres ...)

                Adhérer à l'April, ça vous tente ?

              • [^] # Re: TCPA

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

                15% ça parait vraiment petit.
                Si on prend les branchements classiques (jump if equal, jump if above, etc), on n'a que 2 possibilités : suivre le branchement ou pas.
                Donc une prédiction mauvaise ne devrait pas faire moins de 50%... Me trompe-je ?
                • [^] # Re: TCPA

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

                  Donc une prédiction mauvaise ne devrait pas faire moins de 50%... Me trompe-je ?


                  Pour les 50 %, tu a tout a fait raison ! Ne sous-estime quand même pas les compétences d'intel : ils sont capables de faire 15 % !

                  Adhérer à l'April, ça vous tente ?

                  • [^] # Re: TCPA

                    Posté par . Évalué à 2.

                    Un exemple de code ou les "if" vont aller statistiquement sur "faux".

                    Les codes d'exceptions d'un pilote.
                    Par exemple, à la lecture d'un bloc de disque, "statistiquement" tu n'as aucune erreur (Il faut l'espérer en tout cas).
                    donc tu as une liste de cas d'erreurs du type :

                    if(hardwareFailure1){
                    interrompre et retourner une erreur
                    }
                    faire(xxx)
                    if(hardwareFailure2){
                    interrompre et retourner une erreur
                    }
                    faire(yyy)
                    .....

                    Le processeur peut optimiser en estimant que "statistiquement" l'assertion est fausse.
                    • [^] # Re: TCPA

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

                      De toute façon, les prédicteurs de branchement sont utiles dans le cadres de boucles répétées, pas du tout pour une assertion isolée, car sinon ça ferait graver beaucoup de transistors pour ne pas gagner grand chose ...
                      De plus, vus les techniques utilisées actuellement, les prédicteurs de branchement ont une certaine "inertie" qui les rends peut utiles pour des tests de type assertion, ou plus particulièrement, des exécutions qui ont beaucoup d'entropie (ex : jeux, normalement tu ne passe pas ton temps a appuyer toujours sur la même touche (même à quake !)).
                      Si on prend par exemple une "simple" prédiction à bi-modale, ont peut considérer que les 2-3 premiers passages en boucles seront prédit faux, mais ca n'empêche pas d'avoir des performances de plus de 90% en moyenne.

                      Adhérer à l'April, ça vous tente ?

              • [^] # Re: TCPA

                Posté par . Évalué à 6.

                J'en doute fortement. Sinon, ils auraient carrément retiré le mécanisme de prédiction de branchement et auraient choisi toujours le saut arrière ou toujours le saut du branchement vrai... avec une probabilité plus proche de 50%

                A 15% de branchements bien prédits, ils auraient aussi de très bons résultats en faisant le contraire de leurs prédictions ! :-)

                --
                http://www.tessier-net.org
                • [^] # Re: TCPA

                  Posté par . Évalué à 4.

                  Si on me donne leur mécanisme de branchement qui fonctionne dans 15% des cas, je vous en fais un pas cher qui voit juste dans 85% des cas.

                  Pour cela, appelons oracle1 le prédicteur de branchement et supposons qu'il retourne une valeur booléenne pour dire s'il faut brancher ou pas.

                  oracle2(x)=return(not(oracle1(x)).

                  Le coup du 15%, c'est sans doute de l'amélioration. Au lieu d'avoir du 50/50, on a du 65/35 et c'est tout de suite moins ridicule.
            • [^] # Re: TCPA

              Posté par . Évalué à 3.

              Pour les references, si vraiment le sujet vous interesse, je vous recommande le bouquin d'Hennessy et Patterson : "Computer Architecture: A Quantitative Approach". Excellent bouquin sur l'architecture des ordinateurs modernes.
            • [^] # Re: TCPA

              Posté par . Évalué à -3.

              Dans les premières versions de prédiction Intel avait fait simple,
              c'etait simplement une analyse statistique de ce qu'il se passait sur le CPU.
              L'analyse du code executé implique donc une optimisation du CPU.
              Simple ... mais pas si efficace que ca puisque dans mes souvenirs ( ca commence à dater) seul 15% des branchements predictifs étaient valides.

              Fox
    • [^] # Re: TCPA

      Posté par . Évalué à 1.

      Une fois ta clef générée par le TPM, il faut tout de même qu'elle soit consultable par les logiciels de crypto... et une fois qu'elle est en ram, le risque est exactement pareil que sans TPM...

      Le TPM ne sauve pas pour ce genre de situation. Le problème n'est pas la génération de la clef mais bien sa présence en ram.
      • [^] # Re: TCPA

        Posté par . Évalué à 3.

        Hmmm, c'est sur que la clé censée rester secrète sorte de la TPM ?
        • [^] # Re: TCPA

          Posté par . Évalué à 2.

          Hmmm, c'est sur que la clé censée rester secrète sorte de la TPM ?
          Non. Les failles se situent plutot dans la puce (sécurité par l'obscurité) et dans les logiciels qui utilisent cette puce, y compris l'OS (puisqu'ils ont le droit d'utiliser la puce pour décrypter, un mauvais bug dans ces logiciels peut permettre à un cracker de décrypter ce qu'il veut).
      • [^] # Re: TCPA

        Posté par . Évalué à 3.

        Euh, non. L'intérêt de la puce TPM c'est qu'elle fait elle-même tous les calculs cryptographiques (enfin ceux qui font intervenir les clés stockées dans la puce).

        Les clés ne sortent pas du composant. On peut voir cette puce comme une carte à puce intégrée au PC. Le logiciel crypto s'interface avec la puce TPM en lui disant de chiffrer/déchiffrer/signer, ...

        Avec une puce TPM les clés cryptographiques ne sont jamais en RAM!

        Cela n'en fait pas un système inviolable pour autant. Si tu as un accès physique à la puce, des attaques similaires à celles existantes dans le domaine des cartes à puce sont envisageables. Attaques qui ont parfois des contremesures d'ailleurs... Mais de telles attaques sont tout de même plus complexes à mettre en oeuvre...

        Donc un logiciel espion ou l'attaque présente ne fonctionnent pas ici.

        Par contre si la puce sert à déchiffrer un message, il est évident que le dit message va se retrouver en clair en RAM.
        • [^] # Re: TCPA

          Posté par . Évalué à 1.

          Euh, non. L'intérêt de la puce TPM c'est qu'elle fait elle-même tous les calculs cryptographiques


          La puce TPM fait les calculs cryptographiques, mais seulement ceux nécessaires au TCPA.

          Avec une puce TPM les clés cryptographiques ne sont jamais en RAM!

          Faudrait te renseigner sur la manière de gérer les clefs dans le TPM, les clefs qui sont accessibles et celles qui ne le sont pas.

          Dans le cas ou les clefs ne seraient pas accessibles aux applications, elles n'auraient de toutes façons aucun intéret à moins que la puce n'intègre tous les protocoles de crypto nécessaires aux opérations (et le SSL/TLS est plutôt spécialisé et complexe) et soit capable de faire du traitement de flux avec une vitesse suffisante.

          Par contre, il existe de vrais accélérateurs SST/TLS hardware, qui eux ont une utilité réelle pour les serveurs.
          • [^] # Re: TCPA

            Posté par . Évalué à 1.

            Je ne voit pas pourquoi la puce TPL serait limitée au TCPA. Normalement l'utilisateur peut décider de générer ses propres clés conservées dans la puce TPM qui joue le rôle de coffre fort. Après un logiciel de messagerie peut très bien s'interfacer avec la puce comme il le ferait avec un banal carte à puce.

            D'autre part une clé est dédiée à un algo donné. Par exemple une clé RSA est faite pour l'algo RSA pas pour du DSA. Normalement il faut même spécifier si la clé est prévue pour faire du chiffrement ou de la signature.
            Si tu veux utiliser un algo exotique inconnu de la puce TPM, cela signifie juste que tu ne pourras pas stocker la clé correspondante sur la puce et que se sera au logiciel de faire tout le boulot. En gros si la clé que tu veux utiliser est dans la puce, elle fait le boulot, sinon c'est ton application.

            Pour moi une puce TPM n'a d'intérêt que côté client et n'a pas pour but d'accélerer les calculs cryptos. Pour cela il existe d'autres solutions comme celles que tu cites, dédiées aux serveurs.
          • [^] # Re: TCPA

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

            Les clés asymétriques sont rarement utilisées directement pour le chiffrement/déchiffrement.
            C'est trop consommateur de ressources CPU.
            Elles servent uniquement à chiffrer/déchiffrer une clé 'symétrique' (générée aléatoirement lors du chiffrement).
            C'est le même principe, en gros, pour un fichier ou une connexion ssl.
            Les algorythmes symétrique sont beaucoup plus performants, et on peut facilement ajouters des clés de destinataires sans démultiplier la taille du message.

            J'imagine, c'est une supposition, que la puce connait un certains nombres de fonctions crypto symétriques 'classiques'.
            C'est tout à fait faisable en hard.
            Du temp où on utillisait encore le DES, ça se faisait déjà.

            Les avantages de la crypto asymétrique sans les inconvénients....
            • [^] # Re: TCPA

              Posté par . Évalué à 1.

              Le problème est qu'une puce TPM n'est pas équipée ni conçue pour négocier une session SSL, et que de ce fait, même si elle peut être utilisée pour faire des opérations de cryptage intervenant dans le SSL, elle n'est pas capable de gérer tout le protocole.

              Mettre les clefs de cryptage SSL dans la puce et seulement dans la puce est donc une énormité. Au final, même si on met la clef dans la puce, elle sera aussi présente en ram, ce qui la rendra toujours vulnérable à certaines attaques.


              Au final, de toutes façons, ce bug est plutôt improbable, à part chez les gens qui installent n'importe-quoi sur leurs machines ou les serveurs web partagés où un webmaster peu scrupuleux essayerait d'espionner le voisin.
              • [^] # Re: TCPA

                Posté par . Évalué à 1.

                Concept interessant... Cela pourra-t-il être utilisé sur les serveurs web mutualisés ?
                • [^] # Re: TCPA

                  Posté par . Évalué à 2.

                  Cela pourra-t-il être utilisé sur les serveurs web mutualisés ?


                  vu que cela requiert un logiciel tournant localement pour faire l'attaque sur la prédiction de branche, c'est à peu près le seul cas de figure où je vois un vrai risque. Ce n'est pas une attaque pouvant être lancée à distance.
                  • [^] # Re: TCPA

                    Posté par . Évalué à 3.

                    Avec les informations dont on dispose pour le moment (et sans avoir lu l'article scientifique) c'est difficile d'évaluer réellement le risque.

                    Si il n'est pas nécessaire d'être root, alors non seulement les serveurs mutualisés, mais aussi tout serveur vulnérable à une exécution arbitraire (et c'est le cas de beaucoup de serveurs web, les sites en php vulnérables à ce type de faille sont légion) sont potentiellement vulnérables.

                    L'autre risque, à vue de nez, c'est tout ce qui repose sur l'authentification par certificat client. Ca augure de méthodes de vol de clef de certificat (et puisque la clef est déduite, pas de phrase de passe qui tienne) qui feront froid dans le dos à tous les admins qui gèrent des accès vpn de nomades par cette méthode. Inciter quelqu'un souvent non informaticien à installer tel ou tel logiciel avec un spyware en prime n'est pas très difficile et passera souvent inaperçu...

                    Bon, après, comme le dit NDM, côté serveur il y a souvent d'autres moyens pour obtenir la clef quand on a la main sur une machine... Une fois qu'il y a une exécution arbitraire, le tout est de trouver une faille locale pour avoir le root, et c'est généralement une question de patience avant tout ;)
              • [^] # Re: TCPA

                Posté par . Évalué à 2.

                Le problème est qu'une puce TPM n'est pas équipée ni conçue pour négocier une session SSL, et que de ce fait, même si elle peut être utilisée pour faire des opérations de cryptage intervenant dans le SSL, elle n'est pas capable de gérer tout le protocole.

                Je ne te suis pas là. Quelle importance qu'elle gère tout le protocole si elle s'occupe des calculs crypto?

                Mettre les clefs de cryptage SSL dans la puce et seulement dans la puce est donc une énormité. Au final, même si on met la clef dans la puce, elle sera aussi présente en ram, ce qui la rendra toujours vulnérable à certaines attaques.

                Alors là je ne vois pas du tout pourquoi.

                En SSL, soit le client n'a pas de certificat et seul le serveur en a un, soit les deux parties possèdent un certificat et il faut en plus protéger la clé privée du client associée à son certificat (qui lui est bien évidemment publique). Mais la puce est sensée savoir le faire.

                Dans les deux cas SSL permet de se mettre d'accord sur une clé de session qu'on aimerait bien protéger (puis jeter). J'ignore comment, dans les faits, une puce TPM gère ça, mais je ne vois pas de raison forçant à avoir la clé générée en RAM. Tout ce qu'on a à fournir à la puce c'est le certificat et l'aléa envoyé par le serveur. La puce peut sans doute même se charger de générer l'aléa du client à destination du serveur.

                Pour moi la clé ne se retrouve donc jamais en clair en RAM. Si c'est le cas j'aimerai que tu m'expliques plus précisemment comment.

                Par contre les données à chiffrer le sont forcément à un moment ou un autre: si on a accès à la RAM pourquoi se fatiguer à aller chercher une clé de chiffrement alors qu'il suffit de lire les données en clair?
                • [^] # Re: TCPA

                  Posté par . Évalué à 0.

                  Je ne te suis pas là. Quelle importance qu'elle gère tout le protocole si elle s'occupe des calculs crypto?


                  Soit elle gère la connexion du début à la fin et aucune clef ne passe en clair dans la ram, soit elle ne la gère pas, et il y a forcément un moment où le software prend le relais pour réalimenter les différentes fonctions de la puce tpm afin de l'utiliser dans le processus de cryptage.

                  Si la puce ne gère pas la session complètement, il y aura forcément un moment où il faudra, par exemple, récupérer le résultat d'une fonction de la puce , le traiter en soft, et le réinjecter dans une autre fonction, ce qui implique un passage par la ram.

                  J'ignore comment, dans les faits, une puce TPM gère ça
                  Idem, je ne vois pas comment cette puce pourrait gérer ça, et je ne trouve aucune littérature sur le sujet. Je ne vois donc pas comment prétendre qu'elle le fait.

                  Le point positif, si le tpm supporte l'algorithme symétrique utilisé lors d'une session, c'est qu'effectivement les attaques de timing ne pourront être utilisées pour faire des statistiques sur la prédiction de branche du cpu puisque les opérations se dérouleront sur un autre cpu, c-à-d la puce tpm. Mais les clefs transitant à l'occasion en ram (sauf preuve du contraire), il y aura toujours d'autres attaques possibles si la machine est déjà compromise au point de faire tourner un outil permettant de faire l'attaque sur la prédiction de branche.

                  Enfin, qui dit qu'on ne va pas trouver des exploits sur les puces TPM, et si cela se produit, comment y remédier?
                  • [^] # Re: TCPA

                    Posté par . Évalué à 2.

                    Je ne suis pas vraiment convaincus par tes arguments concernants une session SSL. Autoriser qu'une clé secrète se retrouve en RAM serait tellement stupide que je vois mal les constructeurs commettre une telle bourde.

                    Mais de toute façon je ne suis guère convaincu par les TPM en eux même, sauf éventuellement pour authentifier une machine. Si on se place au niveau de l'utilisateur un objet personnel comme une carte à puce (ou un dongle) est beaucoup plus appropriée. (Et certaines cartes à puce savent faire du SSL de manière adéquate).
                    • [^] # Re: TCPA

                      Posté par . Évalué à 2.

                      hmm je ne sais pas comment marche une puce tpm, mais à prioris ca doit être comme une cryptobox ou nimporte quel autre hsm. Bref le periph ne connait que les operations crytpo de base et les applis (type openssl) une api specifique pour utiliser la clef, sans jamais y accéder. Pkcs11( http://www.rsasecurity.com/rsalabs/node.asp?id=2133 ) sert typiquement à ça, gère les opérations de crypto de base, et pour tout ce qui est plus évolué, openssl et l'engine pkcs11 s'occupe de faire de lien entre la clée et tes opérations (typiquement une session ssl ou autre); celle ci ne se trouve donc jamais en ram
    • [^] # Re: TCPA "remote atetstation" et obscurité

      Posté par . Évalué à 2.

      En effet, je suppose que la puce propose de générer une clef de manière plus sécurisée, sinon, je ne vois pas bien son interêt.
      Le "remote attestation" est sa seule nouveauté en effet. Des fonctions de cryptographie intégrées au proc ou à la carte mère existent depuis longtemps, cf VIA.
      Pour ce qui est de la sécurité , les générateurs de nombres aléatoires hardware sont potentiellemnt meilleurs que /dev/random.

      Le problèmes de tous ces trucs en hardware c'est la sécurité par l'obscurité (faut avoir confiance pour croire qu'il n'y a ni bug ni backdoor dedans) et l'absence de mise à jour pour tenir compte des exploits et des progrès en cryptanalyse.
      • [^] # Re: TCPA "remote atetstation" et obscurité

        Posté par . Évalué à 2.

        Le truc aussi, c'est que ces systèmes n'implémentent pas tous les algorithmes.
        Des outils comme le PadLock de VIA accélèrent certaines fonctionnalités, mais les clefs passent en ram et une partie des traitements doit être effectuée par le cpu.

        Par contre, question accélération, le padlock accompagné d'un "bête" VIA eden à 1ghz écrase par un facteur ~16 un P4 2,4ghz pour l'AES-256.
    • [^] # Re: TCPA

      Posté par . Évalué à 2.

      Ca marche de la même manière pour une puce : suivant les fonctions activées dans la puce de cryptage, la consommation de courant ne sera pas la même.

      Par ailleurs, il faudra toujours entrer le mot de passe (par exemple au clavier), il y a donc des failles de sécurité beaucoup plus accessibles aux pirates que de faire de la cryptanalyse.

      Pour moi, ce n'est pas une menace qui mérite que les citoyens abandonnent leur liberté pour TPA-Palladium.
  • # Pas si révoluionnaire

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

    C'est un autre canal caché comme on en a déja trouvé beaucoup.

    De plus le risque est plutôt faible puisqu'il faut avoir déjà un accès sur la machine qui utilise la clé privée au moment ou elle l'utilise ...
    • [^] # Re: Pas si révoluionnaire

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

      Exactement !

      Je comprends que réussir à partir d'un principe tel que celui-ci à une véritable attaque est une "belle" réussite, mais je ne vois pas dans quel cas ça peut être utilisé... Si un virus aussi bas-niveau arrive à être installé sur un client, on peut tout aussi bien intercepter la clé privé avant qu'elle soit utilisée pour le cryptage, ou bien intercepter les touches, installer une back-door, ou n'importe quoi d'autre de plus simple et tout aussi efficace...
      • [^] # Re: Pas si révoluionnaire

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


        ou n'importe quoi d'autre de plus simple et tout aussi efficace...


        se faire une petite copie du .gnupg du /home visé...
      • [^] # Re: Pas si révoluionnaire

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

        Voilà ce que je me disais aussi, jusqu'à ce que je vois que l'article est en fait disponible (j'avais cru comprendre que rien n'avait été publié encore).

        En fait, tout ce dont nous avons besoin c'est de pouvoir exécuter un processus sur le même processeur qui est utilisé par l'algorithme de chiffrement. C'est tout. Pas besoin d'accès privilégiés quelconques, donc au final c'est beaucoup plus dangereux (car beaucoup plus facile à déployer) qu'un intercepteur de touches par exemple. Enfin non, disons que si le système que nous avons en face n'est pas très sécurisé, c'est plus simple d'essayer directement de lire ce que la victime tappe sur le clavier, mais dans le cas d'une machine protégée, là les attaques possibles sont limitées.

        Je ne pourrai pas résumer l'article ici, je n'en ai pas les moyens. Ceci dit, les 9 premières pages sont à priori abordables, puisque tout y est expliqué, de manière très claire. Seul flou (pour moi du moins), c'est le fonctionnement exact du processus espion. Je vois l'astuce, mais l'histoire de "mapper" les branches d'exécution de ce dernier sur celles du processus de chiffrement, là je vois plus trop.

        Lecture donc fortement recommandée à toute personne intéressée.
        • [^] # Re: Pas si révoluionnaire

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

          Cela reste complexe, il faut effectuer des mesures pendant que le processus de calcul tourne sur le même processeur. Et que fait-on des 50 autres processus qui ont aussi potentiellement un impact ?
          • [^] # Re: Pas si révoluionnaire

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

            Si je ne me trompe pas, ils ont effectués des tests, donc à priori c'est faisable. Et il est à priori impossible qu'ils aient fait le tout dans un scénario du type "un seul processus tourne sur le processeur" non ?

            Par contre je ne vois pas comment, puisqu'en effet, comme ils le disent d'ailleurs eux-même, le temps d'exécution est partagé entre tous les processus.
            • [^] # Re: Pas si révoluionnaire

              Posté par . Évalué à 3.

              Tu pourrais même construire un thread spécialement fait pour pourrir la prédiction de branchement, le faire tourner pendant que tu décryptes.

              Ou bien se débrouiller pour vider les prédicteurs avant et après déchiffrage.

              Cela pose le problème de disposer des spécifications des predicteurs. Autant que je sache, l'architecture Pentium IV avait conduit Intel à pousser assez loin la recherche dans le domaine et à ne rien diffuser, parce que c'était ça qui lui permettait de larguer AMD :)
          • [^] # Re: Pas si révoluionnaire

            Posté par . Évalué à 0.

            J'y connais rien... mais...
            Et si l'algo de cryptage tournait en mode kernel sur un Linux par exemple, est-ce que le problème pourrait-être partiellement résolu ? (Je crois avoir compris avec la virtualisation matériel, il y a des failles, etc...)
      • [^] # Re: Pas si révoluionnaire

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

        Comme c'est dit plus loin, il suffit de pouvoir exécuter un processus sur la machine qui effectue le calcul. Il n'est pas nécessaire d'avoir le moindre privilège, contrairement à l'interception de clé privée, de frappe de touche, etc..
    • [^] # Re: Pas si révoluionnaire

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

      Tout à fait, c'est N'IMPORTE QUOI cet articlue du journal Le Monde. Cette technique n'a rien de révolutionnaire et l'économie mondiale ne va pas s'effondrer lors de la publication de son article. D'autres exemples de canaux cachés (ou "fuite d'information") :
      - "Time attack" : mesurer le temps de réponse
      - Écoute du bruit du CPU avec un micro
      - Mesure de la consommation électrique
      - Pose d'un micro sur un clavier + réseau de neurone pour deviner les touches tapées
      - Écouter les ondes électromagnétique / radio (écran, clavier, souris) (il parait que clavier/souris sans fil c'est le top)
      - etc.

      Le principal défaut de ces techniques étant qu'il faut être proche physiquement du serveur. La meilleure technique apparement est "time attack" car elle peut fonctionner à distance à condition d'avoir un accès très rapide au serveur (réseau local).

      Bon, pour revenir à l'article : « un petit logiciel "taupe" pourrait donc écouter la puce en toute discrétion, et renvoyer la clé à des hackers ». Comprendre, il faut arriver à installer une taupe.... Il faut donc que la sécurité du serveur soit bancale.

      Tiens, tant qu'on y est. Une autre technique impressionante, qui ressemble à celle dont parle l'article du monde : les processeurs à double coeur isolent au mieux les processeurs exécutés en parallèle (ex: un "core duo" exécute deux programmes à la fois). Mais un chercheur a montré qu'il y a des fuites d'information, (je me souviens plus bien, genre) pouvoir compter le nombre de faute de page. Une taupe peut donc exploiter cette faiblesse pour sniffer les bits d'une clé RSA.

      Bref, c'est sûrement une avancée en matière de fuite d'information, mais ce n'est pas une révolution. Comme toujours, ce n'est pas l'algorithme RSA qui est attaqué mais les faiblesses de son implémentation (logiciel et matérielle). Donc avant de boycotter les CPU Intel/AMD, commencez par vous installer un cage de faraday, ne plus utiliser de wifi ou souris sans fil, et d'utiliser des bibliothèques protégées contre les attaques "time attack" (OpenSSL par exemple).

      Je peux vous trouver des articles sur les méthodes présentées plus haut.

      Haypo
      • [^] # Re: Pas si révoluionnaire

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

        - Écoute du bruit du CPU avec un micro
        - Mesure de la consommation électrique


        As-tu des liens sur ces techniques : je suis très sceptiques quant aux possibilités dans le domaine, vu les fréquences et la densité des puces!
        • [^] # Re: Pas si révoluionnaire

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

          Une recherche rapide sur Google :
          http://www.wisdom.weizmann.ac.il/~tromer/acoustic/ par Adi Shamir et Eran Tromer (Adi est le A de RSA ;-))
          http://citeseer.ist.psu.edu/kocher99differential.html de Paul Kocher, Joshua Jaffe, Benjamin Jun

          Dès qu'il y a des clés privées à récupérer, les gens se mettent à inventer des techniques toujours plus tordues. Pour la Xbox, un mec a sniffé les communications sur port PCI...

          Haypo
        • [^] # Re: Pas si révoluionnaire

          Posté par . Évalué à 1.

          As-tu des liens sur ces techniques : je suis très sceptiques quant aux possibilités dans le domaine, vu les fréquences et la densité des puces!

          Je n'ai pas de lien mais j'ai déjà vu une caméra thermique utilisée sur un microcontroleur. Lors du fonctionnement du composant on voit distinctement des zones resortir et varier dans le temps.

          ça ne dit pas quelle opération est réalisée sur le processeur mais j'imagine qu'avec beaucoup d'essais on peut établir des statistiques sur l'activité du proceseur à partir de son profil thermique.
          • [^] # Re: Pas si révoluionnaire

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

            Je te suis tout à fait en ce qui concerne un microcontroleur, mais là on évoquait sûrement un système beaucoup plus complexe : un microprocesseur moderne avec une fréquence d'horloge supérieure au GHz.
            Pour faire des statistiques d'usage, de puissance dilatée dans telle ou telle unité, OK, mais pour aller deviner quel byte vient de passer, j'étais beaucoup plus sceptique. Apparemment les liens donnés plus haut par la suite de mon interrogation apportent déjà une réponse.
      • [^] # Re: Pas si révoluionnaire

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

        (Oups, j'avais pas fini) De plus je trouve ça nul que LinuxFR reprenne le texte du journal Le Monde en utilisant les même phrases chocs "un véritable bouleversement dans le milieu de la cryptographie", "Intel ait choisi la politique de l'autruche", " Dans une note confidentielle (...)". Beaucoup de mystères autour de cette annonce. Moins on en dit, plus ça semble affreux :-)

        Haypo
        • [^] # Re: Pas si révoluionnaire

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

          C'est pour ça que j'ai rajouté la NdM ce matin en voyant que ca allait passer mais bon, il y a un lien vers l'article, espérons que des gens le liront...
          • [^] # Re: Pas si révoluionnaire

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

            C'est aussi pour ça qu'on a rajouté les liens directs vers l'article scientifique qui n'y étaientt pas dans la news soumise. Ainsi les spécialistes peuvent se faire une idée et résumer leur opinion pour les béotiens.
        • [^] # Re: Pas si révoluionnaire

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

          Ce que j'adore dans l'article du monde c'est le passage (que je cite de mémoire) :

          (...) récupérer presque l'intégralité de la clef (...)

          Autrement dit : le déchiffrement reste impossible, non ?
      • [^] # Re: Pas si révoluionnaire

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

        Le Monde n'est pas une référence en ce qui concerne des articles scientifiques. Si tu veux te faire un avis sur la méthode, lis plutôt l'article même. De là être outré de l'exagération qui est faites, je suis d'accord, même si je trouve que cette attaque, si elle fait vraiment ce qu'elle dit, est de loin beaucoup plus dangereuse que les sus-citées.

        La plupart des canaux cachés auxquels tu fais référence ne sont plus valables aujourd'hui. Le temps d'exécution était certes une faille dans OpenSSL, mais ça a été corrigé puis longtemps. Pour ce qui est du bruit et la consommation électrique, le problème est au final le même, la solution aussi (on équilibre la longueur des branches en rajoutant du bruit). Enfin, micro sur clavier, ondes électromagnétiques, tout ceci nécessite une présence physique proche de la victime (au moins le micro par exemple).

        Ce n'est pas le cas de cette attaque là. Ici, tout ce dont nous avons besoin, c'est de pouvoir exécuter un processus. Certes pas n'importe lequel, donc on doit avoir alors au moins accès à un compilateur, et pouvoir l'exécuter.

        L'utilisateur "de base" (en gros, monsieur X qui est tranquillement devant son pc, dans son salon) n'a à priori rien à craindre, sauf si quelqu'un réussit à accéder à son pc. Or, ce monsieur X a 70% (et encore, je suis optimiste) de chances d'utiliser windows. Ce système étant particulièrement connu pour être la cible de multitudes de vers/chevaux de troie, il n'est pas impossible (loin de là même) d'exécuter un processus espion sur sa machine (par processus espion, j'entends le sens qui est donné dans l'article).

        Nombreux sont ceux qui oublient que les serveurs aussi sont ciblés. Prenez l'exemple d'une entreprise/université qui possèdent un certain nombre de serveurs proposant des services aux employés/étudiants, qui peuvent profiter de ces derniers en se connectant à l'aide d'un terminal. N'importe qui peut alors lancé un processus espion.

        Certes, ce n'est pas si facile que ça, mais la difficulté est considérablement réduite et la compléxité également (grande partie de la clé est trouvée en un seul passage, le reste peut être alors retrouvé par attaque exhaustive). Donc en quelque sorte c'est alarmant. Ce n'est pas la fin de SSL, il ne faut pas renoncer à SSH, mais disons qu'il va falloir suivre de près cette affaire.
        • [^] # Re: Pas si révoluionnaire

          Posté par . Évalué à 4.

          L'utilisateur "de base" (en gros, monsieur X qui est tranquillement devant son pc, dans son salon) n'a à priori rien à craindre, sauf si quelqu'un réussit à accéder à son pc. Or, ce monsieur X a 70% (et encore, je suis optimiste) de chances d'utiliser windows. Ce système étant particulièrement connu pour être la cible de multitudes de vers/chevaux de troie, il n'est pas impossible (loin de là même) d'exécuter un processus espion sur sa machine (par processus espion, j'entends le sens qui est donné dans l'article).


          Certes oui.
          Mais ce qui n'est pas precise dans l'article c'est la mise en oeuvre de la faille.

          En effet, l'application pratique suppose un processus crypto et un processus espion tournant sur la machine. Dans une optique reelle, est-il facile de determiner avec precision quand un processus crypto tourne, et lequel? Je ne le pense pas.

          D'autant plus que il me semble que l'article n'aborde pas le probleme d'execution concurente puisque qu'il n'est fait mention a aucun moment d'un troisieme processus, voire d'un ensemble bien plus important de processus. comme dans un OS reel...

          Ainsi, meme si la faille a l'air reelle, il me semble que le ton alarmiste du Monde est completement deplace. Je dirai que ce journal tombe encore dans la tentation du sensationalisme, ce qui en recherche est plus que dangereux avant d'avoir eu des revisions par les pairs etc...


          Romain
          • [^] # Re: Pas si révoluionnaire

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

            D'autant plus que il me semble que l'article n'aborde pas le probleme d'execution concurente

            En effet, c'est l'un des deux points qui me sont flous. Dans la section 2.3 ils disent qu'ils ne pousseront pas l'analyse trop loin et simplifient le problème. Ceci dit, ils font référence à d'autres articles qui pourraient éventuellement répondre à ces questions. J'ai jeté un coup d'oeil rapide à l'un d'entre eux ( [OST06] dans les références de l'article), mais il me semble que ce ne soit pas le bon, puis franchement, j'avais pas le temps :).

            Donc oui ce n'est pas dans une semaine qu'on va apprendre qu'amazon doit changer de certificat parce que quelqu'un a la clé privée, mais ceci dit j'ai tendance à croire que les barrières sont beaucoup plus faibles à présent. Si un système cryptographique ne tient sa force qu'au fait qu'on ne peut pas savoir quand est-ce que le processus de (dé)chiffrement tourne, c'est à priori loin d'être rassurant.

            Quoi qu'il en soit, l'article du Monde est tout à fait déplacé. Ce serait vraiment bien que les gens cessent d'y faire référence et d'extrapoler leurs critiques sur l'article scientifique même.
      • [^] # Re: Pas si révoluionnaire

        Posté par . Évalué à 3.

        Tiens, tant qu'on y est. Une autre technique impressionante, qui ressemble à celle dont parle l'article du monde : les processeurs à double coeur isolent au mieux les processeurs exécutés en parallèle (ex: un "core duo" exécute deux programmes à la fois). Mais un chercheur a montré qu'il y a des fuites d'information, (je me souviens plus bien, genre) pouvoir compter le nombre de faute de page. Une taupe peut donc exploiter cette faiblesse pour sniffer les bits d'une clé RSA.


        Il me semble que ça ne marche que sur les processeurs à cache partagée (core2 duo), ou les systèmes avec hyperthreading. Si tu utilises des processeurs à cache séparée (p-ex, AMD64) , ces timing attacks doivent être beaucoup plus difficiles.

        Au final le problème de ce bug, comme beaucoup d'autres du même genre, c'est le contrôle de ce qui tourne et de ce qui ne tourne pas sur la machine. Si un serveur se fait injecter un programme qui fait des timing attacks, c'est qu'il y a un problème de sécurité déjà ailleurs.
        • [^] # Re: Pas si révoluionnaire

          Posté par . Évalué à 1.

          Pour l'HyperThreading, c'est évident que les caches sont les mêmes, par contre, pour les Core 2 Duo, seul le L2 est partagé... Ca veut dire que chaque core à son L1 et, bien évidemment, ses registres.

          A part les situations de type HyperThreading, et plus généralement, "des CPU logiques", les caches L1 sont toujours distincts... Donc, cela place tous les CPU au même niveau sur ce point (hors P4C, P4E et PXE).

          Et j'ai du mal à voir le lien entre contenu de la mémoire et temps d'exécution ou analyse de prédiction de branchements...
      • [^] # Espionage en interne

        Posté par . Évalué à 1.

        C'est sûre que pour le grand publique c'est plus simple d'installer un spyware en mode administrateur. C'est sûre qu'il faut obtenir le droit par un moyen quelconque d'exécuter le code espion sur l'ordinateur. Mais on peut envisager en entreprise un ordinateur en accès à plusieurs employés. Si il suffit d'avoir un "top" modifié pour récupérer la clef des autres c'est un peu gênant pour Intel/Amd. Surtout s'il faut désactiver le BPA (encore faut il que l'espion ne puisse pas le réactiver) et que la machine fasse un usage intensif de SSL. Évidement il faut déjà avoir confiance en ses administrateurs, ses dirigeants cf. HP il y a peu ...

        Je suis d'accord il faut revoir la formation et code déontologique des journalistes. Une pige, c'est un feuillet de -1500 signes-, payé environ 60 euros. Du moment qu'il y a 1500 signes tu peux manger le soir ...
  • # Et si on change d'architecture?

    Posté par . Évalué à 4.

    Je ne connais pas le principe de l'analyse de branche, mais j'ai cru comprendre que c'est une opération réalisée par le CPU pour "deviner" la suite des opérations.
    Apparement cette attaque est basée sur une surveillance de l'analyse de branche effectuée par le CPU.

    Alors je me demendais si tous les processeurs font de l'analyse de branche (je sais pas, peut-être que les ARM n'en font pas...) ou si le fait d'avoir une architecture matérielle exotique pourrait être une parade acceptable à ce type d'attaque?

    Merci de vos éclaircissements.
  • # Faut m'expliquer...

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

    Si il faut un logiciel taupe pour ca, c'est que la machine est compromise.
    Si elle est compromise, c'est plus simple de voler les touches du clavier, le fichier certificat tout ca...

    Au final, où est le risque supplémentaire une fois la machine compromise?
    (Ou alors j'ai vraiment rien compris...)
    • [^] # Re: Faut m'expliquer...

      Posté par . Évalué à 2.

      Au final, où est le risque supplémentaire une fois la machine compromise?
      (Ou alors j'ai vraiment rien compris...)


      Simplement que l'attaque en theorie n'aurait pas besoin d'elever ses privilieges... Enfin si jamais elle est realisee en pratique...


      Romain
    • [^] # Re: Faut m'expliquer...

      Posté par . Évalué à 1.

      Si il faut un logiciel taupe pour ca, c'est que la machine est compromise.
      Si elle est compromise, c'est plus simple de voler les touches du clavier, le fichier certificat tout ca...

      Je me pose un peu la même question. Dans quel contexte cette faille peut-elle être utilisée? Que craint-on?

      Est-ce que l'exécution d'une pièce jointe peut laisser un programme résident en mémoire décoder la clé lorsqu'on envoie nos emails, et transmettre l'info via internet?

      Ou est-ce qu'on craint carrément l'insertion du code correspondant dans un programme visant un large public (par exemple Skype, qui comme le souligne cette étude : http://www.secdev.org/conf/skype_BHEU06.pdf ne laisse pas l'utilisateur maître des données envoyées), ce qui reviendrait au même que ci-dessus?
  • # Vu de l'autre coté

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

    Apparemment, la parano va bon train hez les uns et les autres...

    Rappellons quand même qu'il y a des gens qui ont besoin de la cryptographie au jour le jour, et pas pour faire cool et geek... Des gens dont le metier impose une sécurité drastique. Et pas besoin d'être James Bond. Un ingénieur peut-être contraint d'utiliser la crypto pour son travail et ses échanges. Et si on veut sniffer sa machine, on le fera, je ne me fais pas de souci pour son concurrent...


    Autre point de vue... Madame Michou n'a à peu près aucune chance qu'on attaque sa machine pendant qu'elle fait ses courses sur ConsoPasCher.com... Mais le site web marchand, lui, a infiniment plus de chances qu'elle de se faire rooter puis voler ses certificats, afin que tous les clients fassent des virements à des pirates et plus au site marchand... Le risque est là selon moi.

    Enfin, il faut savoir quel type de clef a été cassé.. Car c'est bien beau, mais je rappelle à ceux qui n'ont jamais suivi des cours de cryptographie que des supers algos comme le connu RSA et tant d'autres vont faire des analyses plutôt poussées sur les clefs lors de leur génération. Chopper des nombres premiers sans contrainte comme le suggèrent bien des specifications risque bien de rendre votre clef aussi sécure qu'un post-it sous le claver... Et l'article ne dit pas de quel algo provient la clef, ni quelles étaient ses propriétés.
  • # Quel est le but de cet article ?

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

    Il y a plusieurs personnes non-informaticiennes qui m'ont déjà envoyé le lien vers cet article... Franchement il est ultra-alarmiste alors que je pense que le problème est très loin d'être gênant en pratique. Quand on voit le nombre de machines compromises sur le net, je ne vois pas de raison pour les pirates de d'embêter avec des trucs aussi compliqués.

    L'article du monde laisse entendre que hop la sécurité n'existe plus tout d'un coup. Il ne faut surtout pas faire ses courses de Noël en ligne mon bon monsieur ! Vous vous rendez compte ? Les puces sont compromises ! (avec une belle photo de carte à puce à côté... n'importe quoi)
    • [^] # Re: Quel est le but de cet article ?

      Posté par . Évalué à 2.

      > Les puces sont compromises ! (avec une belle photo de carte à puce à côté... n'importe quoi)

      Ils auraient pu mettre une photo d'une vraie puce, en train de sauter du haut d'une falaise, avec des vrais pirates qui la harcèlent, ça aurait fait encore plus sensationnel!
  • # C'est quoi cette news alarmiste à la con ?

    Posté par . Évalué à 10.

    Ça fait longtemps que ca existe la cryptoanalyse temporelle. Et on a déjà pu extraire des clefs RSA grace à des statistiques de cache hit/miss sur de l'hyperthreading, par exemple, mesuré grace à la différence de temps que met un miss d'un hit. Le fait qu'on se mette à utiliser un autre détail technique ne change quasiment rien du point de vue théorique.

    Beaucoup de bruit pour rien du tout de neuf, si ce n'est un détail technique de mise en oeuvre, comme il en existe des dizaines différents...), et une recherche de sensationnalisme extremement déplacée -- "Une telle mesure ralentirait par quatre le microprocesseur (...)"., vague insinuation d'un espece de <<ralentissons par 4 ou soyont insécure>>, alors qu'on verra sans doute dans quelques semaines à quelques mois que des parades "toutes bêtes" (pour quelqu'un qui maitrise bien les techniques des processeurs modernes et des systèmes d'exploitation) sont possible, puis que dans un peu plus de temps encore un autre canal caché avec trop de débit sera découvert, qu'il faudra combler.

    Même le "L'impact est donc surtout pour le grand public et en particulier les échanges sur internet sécurisés par SSL." est bien trop alarmiste a mon goût (quoique modéré par "dans ce cas il existe souvent d'autres moyens pour obtenir la clé"). Il est bien plus facile de se demerde pour qu'un rootkit soit installé par un moyen ou par un autre, et à ce moment là les analyses temporelles s'avèrent dérisoire par rapport à toutes les autres possibilités.
    • [^] # Re: C'est quoi cette news alarmiste à la con ?

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

      Alarmiste ? Noooonnnnnnn.... C'est pour ça que TF1 a dédié un sujet complet sur cette révolution dans le journal de 20H ce dimanche qui, selon leur propos et ce que je m'en rappelle, affecterai l'ensemble des ordinateurs du monde entier, rien que ça :)

      Merde grillé, non je regardais pas TF1, non ...zut trop tard
      • [^] # Re: C'est quoi cette news alarmiste à la con ?

        Posté par . Évalué à 4.

        Je sais TF1 c'est mal, mais des fois, on est pas chez soi et des zigotos allument la télé :

        Lorsque j'ai entendu ça sur TF1, j'ai rien compris au reportage. Le truc qui m'a le plus sidéré, c'était leur petit curseur qui se baladait sous les 0 et 1 et le commentateur en train de dire (attention c'est de mémoire, mais l'idée est là) : "dans les ordinateurs il y a un curseur comme celui-là qui parcours les bits".
    • [^] # Re: C'est quoi cette news alarmiste à la con ?

      Posté par . Évalué à 3.

      Tient en prime joffre une piste éventuellement possible (à faire confirmer par des spécialistes) pour fermer ce canal caché sur un x86 moderne :

      Utiliser un algorithme Balanced Montgomery Powering Ladder et des CMOV pour choisir la destination, ce qui élimine les sauts conditionnels.

      et hop, on peut meme le faire sans cmov sur les proc plus vieux : http://www.intel.com/cd/ids/developer/apac/zho/dc/xeon/knowl(...)

      De plus le simple fait que l'attaque n'ait pas un résultat garanti dans 100% de ses instances (loin de là) montre qu'on peut trouver d'autres pistes, ce qui eventuellement sera necessaires si d'autres algorithmes sensibles ne peuvent utiliser d'instruction de recopie conditionnelle pour remplacer les sauts conditionnels dépendants des clefs ou de données dérivées.
    • [^] # Re: C'est quoi cette news alarmiste à la con ?

      Posté par . Évalué à 5.

      A quand une news qui révéle que les clefs de chiffrements sont stockées sur la machine, et sont parfois en clair dans la memoire. C'est une énorme faille de sécurité ca, alors moi j'utilise jamais de clefs, comme ca je ne les stock jamais et je risque pas de me la faire piquer ! Non mais hé, salops de hackers...
      Et puis tiens je vais proposer ca a TF1 !
  • # Encore une sur-médiatisation ?

    Posté par . Évalué à 6.

    La nouvelle était déjà sur Slashdot : http://it.slashdot.org/article.pl?sid=06/11/18/2030247 (pas intéressant en soit) et, plus intéressant, une personne apparemment d'un groupe de recherche concurrent y a écrit une réponse montrant que, bien qu'intéressante, cette découverte n'était pas si extraordinaire ou catastrophique que cela : http://it.slashdot.org/comments.pl?sid=207304&cid=169000(...) . Sa conclusion traduite à la hâte dit ceci :
    Puisque cette attaque est limitée au localhost et (au contraire de l'attaque de Bernstein et Boneh) ne peut être étendue à distance, elle ne va pas avoir d'impact sur SSL ou SSH (en utilisateur seul). La victime classique des attaques basées sur le temps sont les smart cards. Pour ces attaques, une autre possibilité intéressante est le DRM ; ces attaques disent simplement que vous ne pouvez pas faire confiance à la crypto tournant sur le même Pentium 4+ qu'un attaquant.
    Cà relativise les choses, tout de suite (enfin, faut le croire, lui aussi ; ils sont peut-être tous dans le Grand Complot).
  • # Rendre à César ce qui est à César

    Posté par . Évalué à 4.

    Je sais pas si le Mr/la Mme qui a publié la news est au courant, mais quand il y a trois auteurs à un papier, on n'attribue pas toute la découverte au troisième !

    Ou alors peut-être le Mr/la Mme a quelque chose contre les Israeliens et les Turques ? Ou, au contraire, un ticket pour Mr Steifert ?

    Par ailleurs le Steifert n'est pas Allemand, mais autrichien ;)

    a+

    LIAR
    • [^] # Re: Rendre à César ce qui est à César

      Posté par . Évalué à -1.

      En fait, le 1er auteur est américain, et le deuxième, est effectivement turc (en plus d'être américain ;)).

      Le Mr/la Mme qui a publié la news :
      - n'est donc pas antisémite, ce qui est très politiquement correct (en plus d'être correct tout court)
      - est anti-américain et anti-turc, ce qui est beaucoup plus à la mode :)
  • # interessant quand même !

    Posté par . Évalué à 2.

    Oui pour le Monde c'est la fin du ... monde.
    Rien d'autre à attendre de la part d'un journal non spécialisé, non ?. En jetant un oeil à l'article, et si j'ai compris le quart de la moitié, la solution d'équilibrage n'est pas suffisante. Ne devrait-on pas dans ce cas repartir de l'algorithme initial non équilibré :

    S = M
    for i from 1 to n-1 do
    S = S * S(mod N)
    if di == 1 then
    S = S * M(mod N)

    et tenter de s'en sortir sans une boucle conditionnelle ?

    S = M
    for i from 1 to n-1 do
    S = S * S(mod N)
    S = S * M(mod N) * di + S * not di

    Ai-je au moins compris le problème ?
    • [^] # Re: interessant quand même !

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

      En voyant ce bout de code, je me dis exactement la même chose : ca coute en ressource (en encore c'est a testé ?), mais il n'y plus de condition sur di, et le problème est réglé ?

      Ca peut aussi se faire avec des et/ou logique si le format de stockage des nombres le permet :
      S = S * S (mod N)
      S = (S * M (mod N) & di) | S & not di

      en bref il reste de l'optimisation pour le temps d'exécution soit le même, et sans condition.
    • [^] # Re: interessant quand même !

      Posté par . Évalué à 0.

      quand on commence à trouver des lignes de code dans uine news pour palier une faille dans ssl, c'est qu'il y a réellement un problème. Sur-médiatisation ou pas.
  • # Pertinence de l'article/dépêche ci-dessus

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

    A lire les commentaires qui ont été fait jusque là et à voir les choix des lecteurs (article du Monde: 679 hits, abstract de l'article scientifique 208 et article même 279), je dois avouer que l'article (de linuxfr) a été posté et accepté trop tôt...

    Que dire quand on lit : "La technique découverte par Jean-Pierre Seifert consiste à analyser le comportement du processeur lui-même afin de déduire statistiquement la clé de chiffrement."

    quand le résumé de l'article initial dit très clairement : "a Simple Branch Prediction Analysis (SBPA) attack --- sharply differentiating it from those one relying on statistical methods"

    Du coup on lit des commentaires parlant de timing attack, que c'est pas nouveau, quand le résumé de l'article dit : "The successful extraction of almost all secret key bits by our SBPA attack against an openSSL RSA implementation proves that the often recommended blinding or so called randomization techniques to protect RSA against side-channel attacks are, in the context of SBPA attacks, totally useless."

    En bref, beaucoup trop de commentaires qui s'acharnent sur l'exagération des conséquences de la méthode, etc. quand visiblement ils n'ont pas pris la peine de lire, ne serait-ce que le résumé de l'article SCIENTIFIQUE. Ne me parlez pas du Monde, depuis quand un journal est-il une référence absolue en tèrmes d'avancées/résultats scientifiques si récents (mi-octobre 2006) et si pointus (d'ailleurs, ne prenez-vous jamais le temps de regarder une autre source d'information que la première qui vous tombe sous la main pour des sujets autres que l'informatique ?) ?!

    Ne pas lire entre mes phrases pour essayer de dicerner un avis quelconque sur la compétence de la méthode : je ne suis pas là pour faire son éloge (ou la critiquer d'ailleurs), pour la simple et bonne raison que je sais et je le dis, moi, que je n'ai pas les connaissances nécessaires pour pouvoir en tirer une conclusion. Ceci n'empêche que je ne vais pas cracher non plus dessus, par simple respect des personnes qui ont travaillé dessus et qui ont pris la peine de pointer une (éventuelle) faille.

    Plutôt que de crier au ridicule et à la paranoïa exagérée d'un journaliste (encore que vous oubliez de le mentionner, on pourrait presque croire que vous donnez un avis sur la méthode), concentrez-vous plutôt sur le sujet même. Et cher(s) rédacteur(s)/rédactrices (d'articles sur linuxfr j'entends), un grand merci pour votre contribution (franchement), mais je vous en prie, évitez dans l'avenir de paraphraser un article comme celui proposé par le Monde.

    Pour ceux qui veulent avoir quelques infos supplémentaires, quelques commentaires pertinents peuvent être lus ici : http://it.slashdot.org/article.pl?sid=06/11/18/2030247
  • # fonctionnement / impact

    Posté par . Évalué à 6.

    Pour le fonctionnement, voila ce que j'ai compris de l'article :
    Le processeur possède des statistiques sur les boucles empruntées, qui vont lui permettre de choisir la bonne branche à exécuter. Celles-ci sont mises à jour à chaque execution de la conditionnelle.

    En gros, si on a :
    if(cond)
    a;
    else
    b;
    Si le processeur s'appercoit que dans 80% des cas cond est vérifié, il va commencer à executer a. S'il en fait cond n'est pas vérifié, il revient en arrière. Cette opération est couteuse en temps, et c'est ca qu'on va mesurer.

    Donc l'attaquant va executer le même code, en faisant en sorte que cond soit toujours vérifiée, afin de pourrir les stats.

    Résultat, lors d'un vrai calcul, le processeur va toujours commencer à executer a; Il suffit de savoir quand il revient en arrière pour avoir des informations sur cond ("facile", ca prend plus de temps).
    Sachant que dans le cas d'un RSA, cette condition est directement déterminée par un bit de clef, on obtient ce bit.

    Voila pour le principe, mais bon, je n'ais aucune connaissance sur le fonctionnement des processeurs.. donc j'au pu me planter qq part...


    Impact
    Il faut voir ensuite ce que cela impacte.
    Premièrement, pour les algos symétriques tels qu'ils sont concus actuellement, cette attaque n'a pas d'effet (pas de conditionnelle portant sur les bits de clef). [1]

    Cela n'impacterait que des algos asymétriques. Ensuite, on attaque une clef privée, qui n'est utilisée que dans le cas du déchiffrement ou de la signature.

    Pour une clef de dechiffrement, il est plus facile de lire le clair nouvellement créé. Par contre, cela permet de déchiffrer ensuite tout autre message... (a condition bien sur d'y avoir accès)

    Pour moi, le principal impact se fait sur les clefs de signature.
    Comme la signature electronique a valeur légale, cela peut poser de graves problème. C'est un premier point.
    Ensuite, plus concretement, niveau web. La récupération de la clef de signature met à bas les différents protocoles d'authenfication (ceux de ssl par exemple). La conséquence est simple alors : plus de confidentialité possible (pour faire tres court, ya une grosse ellipse).

    Reste à voir si cela révolutionne le monde, comme semble vouloir le faire passer les médias.
    Honnêtement, je ne crois pas du tout. Tout simplement car il faut pouvoir executer un code en local sur la machine attaquée, et récupérer les données ensuite. Si le serveur est suffisemment protégé, cela ne devrait pas être possible. Et dans le cas contraire, il existe surement d'autres moyens plus simples de récupérer les clefs.

    Par exemple :
    Un serveur doit être opérationnel immédiatement. Donc dans une implémentation triviale, les clef sont deja... en clair.
    Et sinon, le serveur doit bien avoir un moyen d'y avoir accès sans intervention humaine (ya pas toujours un admin a cote...) Et donc les secrets sont récupérables de la même manière.

    En conclusion :
    C'est une attaque intéressante, mais l'impact est très limité :
    - le particulier : vous en connaissez beaucoup qui utilisent une signature electronique ?
    - les serveurs : il suffit de déporter les calculs sur une machine tierce, ou un équipement dédié. Une solution existe donc.

    Désolé pour le pavé ;)

    [1] il existe toutefois d'autres attaques par canaux auxiliaire, la cache timing attack sur l'AES en particulier. Et pas moins efficace...
    • [^] # Re: fonctionnement / impact

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

      Euh, c'est ce qu'on appelle du "blocking" dans le jargon des créateurs de compilateurs ça, le coup du "dans 80% des cas ça fait ça" non ?
    • [^] # Re: fonctionnement / impact

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

      Je m'intérroge sur 2 choses :

      - si le code ne contient pas de condition, et que le temps d'exécution des boucle est le même, est-ce que l'analyse marche tjrs ? cf un commentaire plus haut (je sais que le temps d'exécution n'est pas tjrs exactement le même surtout pour des multiplications mais dans l'idée est-ce qu'il y aurait une solution de ce type ?).

      - si il y a d'autres processus, est-ce que les caches ne sont pas bruités au point que l'analyse ne fonctionne plus ?
      • [^] # Re: fonctionnement / impact

        Posté par . Évalué à 3.

        S'il n'y a pas de condition (donc pas de branchement) cette attaque ne peut pas fonctionner.

        Par contre, même avec des branche dont le temps d'execution est identique, cela foncitonne toujours : ce n'est pas le temps d'execution d'une branche qui est mesuré, mais plutot celui pour retourner en arrière (vider le pipeline, et recommencer les calculs)

        S'il y a d'autre processus, il y a peu de chance qu'ils affectent statistiquement la même boucle (apparemment, dans ce "cache de prédiction", il doit y avoir une entrée pour chaque boucle).

        Pour mener l'attaque, il faut savoir précisément quelle boucle est executée sur le processeur (il faut bien savoir ce qu'on mesure). Comment on fait, j'en ais aucune idée. Mais ils y sont bien arrivés donc ca doit être possible. Faire tourner d'autre processus ne devrait pas faire sortir du cache des informations sur quelque chose en train d'être exécuté.
        Mais bon, la on en vient à un domaine que je ne maitrise pas du tout, celui des archis processeur, et encore moins sur des trucs récents comme leurs predictions ;)
        Donc tout ce que je dis peut très bien être completement faux !
        • [^] # Re: fonctionnement / impact

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

          Si l'attaque ne fonctionne pas s'il n'y a pas de condition, alors le commentaire http://linuxfr.org/comments/776598.html#776598 tue le troll en 3 coup de cuillères à pot...

          Je vois pas de réaction sur les mailing list d'openssl.

          [ma vie]
          Ca me rappel losrque je recodais en assembleur mes fonctions TurbalPascal, justement sans condition pour accélèrer un peu (bon c'était pas de la cryptographie juste des blobs).
          [/ma vie]
  • # Faire tourner un processus sur la machine ciblée ? Facile !

    Posté par . Évalué à 2.

    Par manque de temps et de connaissances sur le sujet, je n'ai pas pris la peine de lire l'article scientifique... Mais je me pose une question.

    La plupart des commentaires ici semblent s'orienter pour dire que les serveurs sont plus vulnérables à cette "attaque" que le PC de Luce et Henri. Mais dans un contexte actuel où le phishing est très répandu, est-ce que ce vecteur ne serait pas utilisable pour de telles attaques sur les machines clientes... par le biais d'une applet ?

    Je ne sais pas quel est le niveau de contrôle nécessaire pour avoir des résultats probants par cette technique, mais est-ce que le "sandbox" dans lequel tournent les applets java, flash ou autre permet d'accéder aux informations de la BPA ?

    Je ne pense pas avoir succombé au sensationalisme des mass-media qui ont relayé la nouvelle, mais je me pose ici une réelle question... En attendant, je continue à suggérer Firefox+NoScript à mes connaissances.
    • [^] # Re: Faire tourner un processus sur la machine ciblée ? Facile !

      Posté par . Évalué à 1.

      Cette attaque sur les machines clientes ?
      Alors comment mettre en oeuvre cette attaque :
      0) l'attaquant a auparavant pourri le fichier hosts de la machine cible (pour faire accepter le certificat du vrai serveur)
      1) l'attaquant se place en man in the middle, entre le vrai serveur et l'utilisateur. (un fishing évolué donc)
      2) l'attaquant a fait tourner son truc sur la machine de l'utilisateur. (une applet, oui, je ne vois pas pourquoi ca ne fonctionnerait pas, vu qu'il suffirait de droits utilisateur)
      3) la session ssl commence
      4) on négocie la clef. La partie secrete de l'utilisateur est alors connue de l'attaquant (on attaque le diffie hellman), donc la clef entière.
      5) L'attaquant peut tout écouter.

      Mouais, en fait c'est beaucoup plus simple a realiser que je ne le pensais au premier abord.

      Après faut qd même voir quel controle réel il faut sur la machine attaquée, pour récupérer les données. Ca, je n'en ais aucune idée.
  • # assez de blabla. voila ce que j'en dis.

    Posté par . Évalué à 4.

    bon.

    j'ai lu l'article, ce qu'a peu pres personne ici n'a fait.

    remarques:
    le process espion ne doit tourner qu'en mode utilisateur. la technique ne chronomètre pas le temps total donc rajouter un temps aleatoire a la fin ne sert a rien. mettre du code qui ne fait rien dans la branche non prise ne sert a rien. mettre presque le meme code qui prend le meme temps dans la branche non vide ne sert a rien. une seule passe sur le chiffrement est nécessaire.

    les gens sont evidemment tres calés sinon ils ne feraient pas de la recherche la dedans.

    j'ai pas tout compris a l'article, certains trucs sont vagues.

    cependant evidemment tout ceci est futile et infondé car la solution est tres simple.

    La personne ici qui a parlé des CMOV a cent fois raison..
    (sauf qu'il devait penser à un JMP indirect avec l'adresse remplie par un CMOV, ce qui ne marche sans doute pas car la prédiction de branchement peut maintenant prevoir ça je crois... mais les CMOV peuvent etre utilisés pour remplacer les jumps conditionnels par des séries d'instructions conditionnelles et ça ça marche. )

    celle qui a écrit ceci aussi:
    "
    Ne devrait-on pas dans ce cas repartir de l'algorithme initial non équilibré :

    S = M
    for i from 1 to n-1 do
    S = S * S(mod N)
    if di == 1 then
    S = S * M(mod N)

    et tenter de s'en sortir sans une boucle conditionnelle ?

    S = M
    for i from 1 to n-1 do
    S = S * S(mod N)
    S = S * M(mod N) * di + S * not di

    Ai-je au moins compris le problème ?
    "

    oui.

    une solution algorithmique comme celle ci marche tres bien et je suis aterré de voir que des tas d'articles hyper sérieux sont publiés depuis des années sur des trucs qui ne marchent absolument pas sans branchements. et on voit "intel fait la sourde oreille etc". je ne peux pas le croire.

    en fait le probleme vient du fait que les gens ne connaissent pas l'assembleur.

    sinon la solution avec les CMOV aurait été immédiate.

    sans connaitre la crypto, quand j'ai vu le DEBUT de l'article sous google avec les termes "prédiction de branchements", j'ai eu l'intuition du probleme et j'ai pensé dans la meme seconde aux CMOV pour le résoudre. je dois avouer que la solution algorithmique est peut etre plus elegante, meme si ça revient globalement au meme. sans CMOV on peut y arriver aussi bien sur, en faisant des contorsions et des masquages sur les bits des registres, bits dont on s'arrange pour que certains proviennent du résultat de la comparaison concernée. ici c'est encore plus simple vu que ces bits sont deja ceux d'un nombre.

    en gros quels que soient les deux cal de calculs ça marche. on a qu'a faire le calcul deux fois et stocker les deux puis faire la comparaison et bouger le bon dans le registre de destination.

    et en gros n'importe quelle code conditionnel doit pouvoir se ramener a ça d'ailleurs.

    c'est assez evident quand on fait de l'assembleur.(enfin moi j'avais deja reflechi par hasard au moyen de virer les Jcc donc ça doit avoir aidé)

    je vais chercher vite fait sur le net parce que comme des gens ont deja donné la solution ici, et que c'est assez idiot, c'est obligé que ça se sache... quoique... d'aut papiers depuis plusieurs années font des trucs super compliqués la dessus... comme le truc sur les caches...

    alors encore une fois, je suis aterré (et fier) qu'un n00b comme moi voie ça direkt parce qu'aparemment c officiel que y a pas de solution (intel dit qu'on desactivera le BTB si besoin!!!!)

    quand on lit ça dans le papier:

    "it especially endangers those cryptographic/algorithmic primitives, whose nature is an intrinsic and input-dependant branch process"

    ...

    on sait qu'on a raison.

    comments?
    • [^] # Re: assez de blabla. voila ce que j'en dis.

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

      J'ai peut être mal chercher, mais la réaction d'Intel, je ne vois pas la source.

      Tout ce bruit me rappel l'article sur les machines virtuelles, ou il était dit que les instructions pour la virtualisations ouvrait des failles de sécurités (*)

      (*) sauf si on installe un superviseur, chose qui n'était pas dite dans l'article, et qui régle le problème.

      (merci pour ce commentaire qui endigue un peu le "ca y est c'est la fin du monde".)
      • [^] # Re: assez de blabla. voila ce que j'en dis.

        Posté par . Évalué à 1.

        d'ailleurs j'ai trouvé d'autres gens qui exposent des techniques similaires.

        ici:
        http://it.slashdot.org/comments.pl?sid=207304&cid=169054(...)

        ici:
        http://it.slashdot.org/comments.pl?sid=207304&cid=169002(...)

        le deuxieme son nom ne m'est pas inconnu mais je retrouve pas pourquoi...
        • [^] # Re: assez de blabla. voila ce que j'en dis.

          Posté par . Évalué à 2.

          voila une partie d'un mail que j'ai posté.

          how to remove conditional jumps:
          my method:

          S = M
          for i from 1 to n-1 do
          {
          S = S * S(mod N)
          if di == 1 then
          { S = S * M(mod N) }
          }

          replaced by:

          S = M
          for i from 1 to n-1 do
          {
          A = S * S(mod N)
          B = A * M(mod N)
          maskA = !di
          maskB = di
          S = (A & maskA) | (B & maskB)
          }

          Basically, it calculates the 2 possible values in to store in S, then selects automatically the right one to put in S, based on the value of di.

          The choice is performed by adding properly masked results. Of course when I write "maskB = di" I mean extending the the bit to all the bits of the integer (or whatever it is). This IS possible, even in C, for example "maskB = 0 - di" if di is 0 or 1.

          In assembly language you even dont need masks (that was my first idea).
          On processors supporting MOVcc, you just have to move the two results conditionally to the returned register.
          • [^] # Re: assez de blabla. voila ce que j'en dis.

            Posté par . Évalué à 1.

            okay. j'ai écrit aux personnes concernées.

            ma méthode serait connue mais elle est plus lente puisqu'elle calcule a chaque fois le plus onéreux des deux cas.

            donc c'est pour ça qu'elle n'est pas utilisée, et le papier sert a montrer qu'il faut faire ce genre de trucs...

            pour moi c'est clair que c'est pas 4 fois plus lent, mais au pire deux et en moyenne 1.5, et encore parce que comme l'a fait remarquer Terje sur slashdot, ça enleve les penalités de flush du pipe.

            en tout cas de ne pas dire que ça existe dans leur papier, de metttre une phrase comme celle que j'ai quotée, et de declencher la rumeur médiatique sur la fin du monde :) ... c'est un peu fort mais bon.

Suivre le flux des commentaires

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