Une faille de sécurité dans les processeurs

Quand la nouvelle est tombée, en novembre 2006, l’industrie informatique s’est arrêtée de respirer pendant quelques secondes. D’après les manchettes, c’en était fini des transactions sécurisées sur Internet. En cause : une faille de sécurité dans la technologie des processeurs superscalaires. Un défaut rien moins que… fondamental.

Une équipe scientifique constituée des cryptologues Onur Acıiçmez , Çetin Kaya Koç et Jean-Pierre Seifert, a montré que, dans certaines conditions, certains processeurs pouvaient laisser transpirer de l’information utilisable ensuite par d’éventuels hackers. Et cela en raison de mécanismes hardware introduits au départ dans les processeurs pour atteindre une plus grande rapidité d’exécution.

Ces mécanismes pourraient permettre aux pirates informatiques qui se seraient introduits sur la machine de déchiffrer indirectement les clés asymétriques utilisées habituellement pour protéger toutes sortes de transactions en ligne. Acıiçmez et ses collègues sont parvenus à acquérir 508 bits sur 512 d’une clé cryptée par RSA. Le tout… du premier coup et en quelques millièmes de secondes. À titre de comparaison, il a fallu trois bons mois et une batterie de quelque 80 ordinateurs à 2.2 GHz pour que le bureau fédéral allemand de la sécurité informatique (BSI) parvienne à craquer une clé SSL à 640 bits.

La nouvelle attaque expérimentale, cependant, se différencie nettement de l’approche « force brute », méthode en vigueur depuis la seconde guerre mondiale. Ici, plus besoin d’effectuer des milliards d’opérations pour craquer une clé. En fait, il n’y a même aucune tentative de décodage frontal.

Dans leur attaque expérimentale, Acıiçmez, Koç et Seifert analysent les états de prédiction de branchements du processeur. Comment ? Grâce à un processus espion qui s’exécute en parallèle du processus de cryptage. Les chercheurs ont baptisé cette technique Simple Branch Prediction Analysis Attack (SBPA). D’après les scientifiques, ces SBPA présentent un « risque de sécurité critique ». Dans le cadre d’une attaque par canaux cachés, il était généralement admis que l’équilibrage égal des opérations dans les deux chemins d’un branchement conditionnel constituait une parade. »

Inexact, à en croire la nouvelle étude. « Même cet équilibrage des branchements conditionnels peut être complètement pris en défaut par une attaque SBPA. » De plus, « malgré des méthodes hardware sophistiquées de partitionnement », comme la protection de mémoire, le sandboxing, qui consiste à isoler des processus spécifiques en leur attribuant des droits limités, ou encore la virtualisation, les SBPA « permettent à un processus sans privilège d’attaquer avec succès d’autres processus qui s’exécutent en parallèle sur le même processeur. » Conclusion ? Ces SBPA s’avèrent « beaucoup plus dangereux qu’on ne le pensait auparavant ».

Spécialiste de la prédiction de branchement, André Seznec s’est attelé à reproduire l’expérience pour se faire sa propre opinion sur le problème. « J’ai essayé, pour valider le principe : ça marche. Très joli cas d’école d’ailleurs ! »

Prérequis essentiel : on considère que le hacker s’est déjà frayé un chemin sur la machine elle-même. Il a passé les firewalls et autres barrages pour installer un logiciel espion, un spyware, sur l’ordinateur. Mais il peut très bien s’agir, au départ, d’un accès légal, dans le cadre d’un partage de ressource. « On peut imaginer que ce soit un collègue du bureau qui fasse tourner un processus sur votre PC par exemple ! »

À partir de là, le but est de « piquer la clé de cryptage privée à son propriétaire légitime. » Le défi semble hors de portée par les techniques classiques d’observation de résultats d’encryptage, car « le cryptage RSA est considéré comme extrêmement robuste. L’état actuel de nos connaissances ne nous permet tout simplement pas d’envisager de craquer un code RSA à très longue clé d’une façon algorithmique ou par la force brute, dans un avenir prévisible. C’est un algorithme en qui tout le monde a confiance. »

Incapable de craquer un algorithme RSA de façon frontale, la SBPA a donc plutôt opté pour une attaque par canaux cachés. Comme l’explique André Seznec, « sur un dispositif matériel, il est possible de mesurer différentes informations relatives à cet équipement. Tout simplement le courant électrique qui circule par exemple. Et à partir de cela, on obtient indirectement des infos. Donc, même si quelqu’un n’arrive pas à lire la donnée directement, il acquiert de l’information indirecte qui le renseigne sur cette donnée. » Jusqu’à il y a peu, ces attaques par canaux cachés s’effectuaient par des moyens hardware. « Cependant, l’introduction des processeurs SMT (Simultaneous Multi Threaded), a permis d’implémenter des attaques par canaux cachés de type purement logiciel. »

Il n’y a pas si longtemps encore, les processeurs géraient les processus dans un mode « temps partagé » : T0 s’exécutait dans une unité de temps (un time slice), puis venait T1 durant le temps suivant, puis à nouveau T0… “ Chacun de ces time slice dure bien plus longtemps que le cycle d’horloge du processeur. Disons qu’un processus prend environ 10 millisecondes. Ce qui représente environ 20 à 30 millions de cycles horloge. Tant qu’un processus cryptographique et un processus espion ne sont pas exécutés simultanément, il n’y aucun risque que ce dernier puisse récupérer des informations sur son voisin. » L’architecture imperméable met chaque processus à l’abri des regards.

Mais la donne a changé avec l’arrivée en 2002 du Pentium 4 HT, un processeur nouvelle génération SMT utilisé pour les PC et les serveurs.

Ces processeurs exécutent deux processus à la fois. Durant un même cycle, T0 et T1 se déroulent simultanément. Pourquoi ? « Principalement pour obtenir plus de performance du processeur, répond André Seznec. Il peut exécuter plusieurs instructions par cycle, mais en général, une partie importante de la ressource est perdue, si un seul processus s’exécute. Quand plusieurs processus s’exécutent en même temps, le hardware est nettement mieux utilisé. » Le hic : deux processus qui tournent en parallèle sur le même processeur peuvent entraîner des fuites d’information. « Quelqu’un peut se débrouiller pour acquérir une vue indirecte sur une exécution de processus, et cela, à partir d’un processus espion qui se déroule simultanément. Cette information indirecte sur l’exécution peut permettre de récupérer des informations sensibles comme une clé de cryptage. »

La boucle mise en cause.

Oui, mais comment espionner un codage ? « En essayant d’obtenir des indications à une échelle microscopique sur ses temps d’exécution, indique André Seznec. Au cœur de certaines versions des algorithmes RSA, se trouve une boucle qui traite deux longues séquences d’opérations. Appelons-les X et Y. » En l’occurrence, « X est toujours exécuté, alors que Y n’est exécuté que si le bit de la clé est 1. Chacun d’eux nécessite plusieurs milliers de cycles horloge. » Une durée assez longue donc. « Maintenant, si quelqu’un est capable, disons, pour chacune des itérations de la boucle, de mesurer combien de temps elles durent, alors il est capable de déterminer si celle-ci est plutôt du type X ou du type XY : il a alors la clé, tout simplement… » CQFD.

Pour arriver à de meilleures performances, les processeurs superscalaires reposent sur une structure hardware de prédiction de branchements. Le branchement est stocké dans une table hardware qu’on appelle un tampon de branchements. En anglais : Branch Target Buffer, ou BTB. Dans la boucle, tant que i n’est pas égal à n, le BTB est interrogé pour l’instruction de branchement de rebouclage à chaque itération. Si cette instruction de branchement n’est pas au rendez-vous dans le BTB, le hardware la restocke dans le BTB.

Dans l’attaque SBPA comme elle est décrite, le spyware est conçu pour utiliser les entrées du BTB dans lesquelles l’instruction de rebouclage peut être rangée. « Tant que l’instruction de rebouclage est absente du BTB, l’espion conserve un comportement régulier, explique André Seznec. Mais une fois que l’instruction de rebouclage est exécutée, un branchement du processus espion perd une vingtaine de cycles. Partant de là, ce que le pirate cherche à faire, c’est détecter la date d’exécution de ce retour de la boucle. Etant donné que X et Y durent quelques milliers de cycles, cette détection n’a pas besoin de se faire au cycle près. Une marge de quelques centaines de cycles fait l’affaire. »

L’estimation du temps est rendue possible par le compteur de cycles implémenté dans le processeur : ce véritable chronomètre est directement accessible par tout processus. « Comme le processus espion a piqué l’entrée de branche, il y a une irrégularité dans le compteur de cycles. Irrégularité que l’on peut lire. À partir du comptage, on peut percevoir si l’opération au sein de la boucle est plutôt du type X ou XY. C’est assez précis pour discriminer. À ce niveau, la longueur de clé ne fait guère de différence. Le code va tomber de toute façon. Des implémentations plus intelligentes de RSA seront cependant plus difficiles à craquer, mais elles pourraient cependant être attaquées. »

Alors, gros temps en vue pour les fabricants de processeurs ? « Non, répond André Seznec. La nouvelle attaque n’implique pas une remise en cause de la façon dont les processeurs sont conçus. Mais elle montre que les développeurs d’applications cryptographiques doivent prendre en compte les aspects système et hardware de leur métier. Pour commencer, ce serait peut-être une bonne idée de désactiver le mode multithread sur les machines qui exécutent des programmes de cryptographie. »