Sécurité : Une faille majeure de la cryptographie courante
Posté par chaica (). Modéré le 20 novembre 2006.
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.
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.
L'article du Monde (1878 hits)
L'abstract de l'article scientifique (720 hits)
L'article scientifique au format pdf (992 hits)
> Lire la dépêche (106 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #776740.




fonctionnement / impact
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
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 ?
J'aime la liberté.
J'aime BSD.
[^]Re: fonctionnement / impact
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
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
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]