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
- L'article du Monde (37 clics)
- L'abstract de l'article scientifique (12 clics)
- L'article scientifique au format pdf (18 clics)
# Ouch
Posté par Anonyme . Évalué à 5.
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 iug . Évalué à 1.
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.
[^] # Re: Ouch
Posté par ribwund . Évalué à 1.
http://www.schneier.com/blog/archives/2006/11/new_timing_att(...)
# TCPA
Posté par Mildred (site web personnel) . Évalué à 5.
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 Guinns . Évalué à 2.
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 Pierre Jarillon (site web personnel) . Évalué à 6.
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 drakkar . Évalué à 6.
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 Gohar . Évalué à 4.
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 Gohar . Évalué à 2.
[^] # Re: TCPA
Posté par vieuxshell (site web personnel) . Évalué à 2.
[^] # Re: TCPA
Posté par Gael Tessier . Évalué à 10.
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 iznogoud . Évalué à 3.
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 Gabriel Linder . Évalué à 4.
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 Pol' uX (site web personnel) . Évalué à 8.
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.
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 pfrenard . Évalué à -1.
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 Pol' uX (site web personnel) . Évalué à 1.
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 Antoine Jacquet (site web personnel) . Évalué à 1.
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 Pol' uX (site web personnel) . Évalué à 1.
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 v_atekor . Évalué à 2.
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 Pol' uX (site web personnel) . Évalué à 1.
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 Gael Tessier . Évalué à 6.
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 fmaz fmaz . Évalué à 4.
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 LeMagicien Garcimore . Évalué à 3.
[^] # Re: TCPA
Posté par Pol' uX (site web personnel) . Évalué à 2.
http://en.wikipedia.org/wiki/Branch_prediction
Adhérer à l'April, ça vous tente ?
[^] # Re: TCPA
Posté par pfrenard . Évalué à -3.
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 ragoutoutou . Évalué à 1.
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 lambada . Évalué à 3.
[^] # Re: TCPA
Posté par free2.org . Évalué à 2.
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 ndesmoul . Évalué à 3.
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 ragoutoutou . Évalué à 1.
La puce TPM fait les calculs cryptographiques, mais seulement ceux nécessaires au TCPA.
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 ndesmoul . Évalué à 1.
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 rouby (site web personnel) . Évalué à 3.
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 ragoutoutou . Évalué à 1.
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 Neo_13 . Évalué à 1.
[^] # Re: TCPA
Posté par ragoutoutou . Évalué à 2.
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 nodens . Évalué à 3.
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 ndesmoul . Évalué à 2.
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 ragoutoutou . Évalué à 0.
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.
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 ndesmoul . Évalué à 2.
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 Alex . Évalué à 2.
[^] # Re: TCPA "remote atetstation" et obscurité
Posté par free2.org . Évalué à 2.
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 ragoutoutou . Évalué à 2.
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 David . Évalué à 2.
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 peck (site web personnel) . Évalué à 10.
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 François LEIBER (site web personnel) . Évalué à 7.
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 DocteurCosmos . Évalué à 5.
se faire une petite copie du .gnupg du /home visé...
[^] # Re: Pas si révoluionnaire
Posté par Alexis P. (site web personnel) . Évalué à 7.
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 peck (site web personnel) . Évalué à 7.
[^] # Re: Pas si révoluionnaire
Posté par Alexis P. (site web personnel) . Évalué à 4.
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 iug . Évalué à 3.
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 Frédéric COIFFIER . Évalué à 0.
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 davux (site web personnel) . Évalué à 1.
[^] # Re: Pas si révoluionnaire
Posté par Victor STINNER (site web personnel) . Évalué à 10.
- "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 Sylvain Briole (site web personnel) . Évalué à 2.
- 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 Victor STINNER (site web personnel) . Évalué à 8.
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 philz . Évalué à 9.
> et Eran Tromer (Adi est le A de RSA ;-))
Le S, plutôt, non ?
[^] # Re: Pas si révoluionnaire
Posté par Sam Laibriz . Évalué à 1.
[^] # Re: Pas si révoluionnaire
Posté par ashram4 . Évalué à 1.
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 Sylvain Briole (site web personnel) . Évalué à 2.
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 Victor STINNER (site web personnel) . Évalué à 10.
Haypo
[^] # Re: Pas si révoluionnaire
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
[^] # Re: Pas si révoluionnaire
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Pas si révoluionnaire
Posté par DocteurCosmos . Évalué à 0.
(...) 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 Alexis P. (site web personnel) . Évalué à 4.
[^] # Re: Pas si révoluionnaire
Posté par Alexis P. (site web personnel) . Évalué à 3.
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 Romain Be. . Évalué à 4.
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 Alexis P. (site web personnel) . Évalué à 3.
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 ragoutoutou . Évalué à 3.
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 Neo_13 . Évalué à 1.
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 salvaire . Évalué à 1.
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 Gilles G. . Évalué à 4.
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.
[^] # Re: Et si on change d'architecture?
Posté par FRLinux (site web personnel) . Évalué à 4.
# Faut m'expliquer...
Posté par Zenitram (site web personnel) . Évalué à 2.
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 Romain Be. . Évalué à 2.
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 erik_lallemand . Évalué à 1.
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 Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
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 Wawet76 . Évalué à 10.
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 riba . Évalué à 2.
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 Guillaume Knispel . Évalué à 10.
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 FReEDoM (site web personnel) . Évalué à 3.
Merde grillé, non je regardais pas TF1, non ...zut trop tard
[^] # Re: C'est quoi cette news alarmiste à la con ?
Posté par sanao . Évalué à 4.
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 ashram4 . Évalué à 1.
1) c'était alarmiste
2) j'ai rien compris
3) je ne savais pas que le "curseur" du processeur met plus de temps à lire les 1 plutôt que les zero.
Finalement c'est du bol que l'article soit disponible à défaut de tout comprendre (j'ai lu 3 pages pour l'instant) je comprend l'idée derrière la faille.
[^] # Re: C'est quoi cette news alarmiste à la con ?
Posté par Gniarf . Évalué à -2.
[^] # Re: C'est quoi cette news alarmiste à la con ?
Posté par Gart Algar . Évalué à 10.
[^] # Re: C'est quoi cette news alarmiste à la con ?
Posté par Gniarf . Évalué à -3.
[^] # Re: C'est quoi cette news alarmiste à la con ?
Posté par Guillaume Knispel . Évalué à 3.
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 Newinx . Évalué à 5.
Et puis tiens je vais proposer ca a TF1 !
# Encore une sur-médiatisation ?
Posté par jayp . Évalué à 6.
# Rendre à César ce qui est à César
Posté par gyom gyom . Évalué à 4.
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 vincent mary . Évalué à -1.
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 ecid . Évalué à 2.
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 _alex . Évalué à 1.
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 dilbert . Évalué à 0.
# Pertinence de l'article/dépêche ci-dessus
Posté par Alexis P. (site web personnel) . Évalué à 10.
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 jkow . Évalué à 6.
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 Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
[^] # Re: fonctionnement / impact
Posté par _alex . Évalué à 1.
- 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 jkow . Évalué à 3.
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 _alex . Évalué à 1.
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 François B. . Évalué à 2.
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 jkow . Évalué à 1.
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 helloworld256 . Évalué à 4.
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 _alex . Évalué à 1.
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 helloworld256 . Évalué à 1.
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 helloworld256 . Évalué à 2.
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 helloworld256 . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.