Il a déjà été montré (cf.
http://www.wisdom.weizmann.ac.il/~trome ... /cache.pdf ) que la détermination indirecte des zones mémoire accédées par un programme (par exemple les lookup tables utilisés par un programme de chiffrage AES) est possible.
Une mémoire cache d'un CPU est partagée par tous les process tournant sur ce CPU. Typiquement, seuls une vingtaine de bits les moins significatifs de l'adresse physique de la mémoire accédée sont utilisés pour identifier l'emplacement du cache qui va recevoir une copie de la donnée tenue en mémoire centrale. Seul le contrôle final de la présence en cache d'une donnée se fera sur l'ensemble des bits de l'adresse.
Il est donc possible pour un process espion de balayer rapidement un espace de plusieurs MBytes, qui va éjecter de la cache CPU une grande partie des données utilisées par un process de chiffrage (par exemple AES) qui utiliserait le même CPU.
Au context switch suivant, le process AES va charger dans la cache ses propres données, éjectant ceux du process espion.
Au context switch suivant, le process espion, en balayant son espace mémoire, peut identifier quelles sont les adresses causant un ralentissement, c-à-d celles qui ont été éjectées du cache par le process AES, ce qui permet, si on a une bonne idée de l'organisation du code AES espionné, de déterminer quels lookup tables AES ont été accédés, ce qui donne une bonne idée des bits de la clé de chiffrement.
Au bout de quelques context switches, le process espion peut donc commencer à avoir une bonne idée du comportement d'accès mémoire du process AES, et donc des bits de la clé qui genèrent ces accès mémoire.
La nouvelle méthode d'attaque dont parle l'article dans Le Monde est une variante de la précédente, qui utilise le fait que des branchements dans le code exécutable peuvent aussi produire des ralentissements, car un CPU moderne a tendance a prédigérer les instructions de la branche qu'il considère la plus probable, et sera notablement ralenti si sa prédiction était mauvaise.
Ces types d'attaque nécessitent de pouvoir faire tourner un code espion sur le même CPU que le système qu'on veut attaquer. Installer un programme espion sur un ordinateur distant est en genéral une opération non-triviale (si on exclut les gens insouciants qui installent n'importe quel widget, screen saver ou freeware douteux qu'ils trouvent sur le net, ou double-cliquent sans réfléchir sur les attachments des e-mails qu'ils reçoivent), donc ces types d'attaque ne sont donc aujourd'hui que très théoriques.
Notons que si on parvient à installer et lancer un programme (par exemple un attachment e-mail) sur un ordinateur distant, le plus simple pour capturer une clé de chiffrage serait simplement pour le process espion d'inspecter directement l'espace mémoire utilisé par le process victime pour y localiser la clé, au lieu de commencer à faire des mesures statistiques de variabilité de temps d'accès du cache ou du pipeline d'exécution / branch prediction unit...
