jkow a écrit 4 commentaires

  • [^] # Re: Faire tourner un processus sur la machine ciblée ? Facile !

    Posté par  . En réponse à la dépêche Une faille majeure de la cryptographie courante. É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.
  • [^] # Re: fonctionnement / impact

    Posté par  . En réponse à la dépêche Une faille majeure de la cryptographie courante. É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: c'est vrai on est vendredi

    Posté par  . En réponse au journal LaTEX : un modèle de rapport de stage et écrire en japonais (sous LaTEX). Évalué à 1.

    Il existe un ptit truc hyper agreable pour tapper du latex :
    http://cristal.inria.fr/whizzytex/

    Cela permet de visualiser son document au fur et à mesure de la frappe.
    (Non, je nourris pas le troll sur l'editeur ;) )
  • # fonctionnement / impact

    Posté par  . En réponse à la dépêche Une faille majeure de la cryptographie courante. É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...