{"id":19160,"date":"2022-07-18T17:07:00","date_gmt":"2022-07-18T15:07:00","guid":{"rendered":"https:\/\/www.kaspersky.fr\/blog\/?p=19160"},"modified":"2022-07-22T16:18:56","modified_gmt":"2022-07-22T14:18:56","slug":"hertzbleed-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/hertzbleed-attack\/19160\/","title":{"rendered":"Qu’est-ce Hertzbleed et qu’est-ce qui le rend si unique ?"},"content":{"rendered":"

En juin, des chercheurs de trois universit\u00e9s am\u00e9ricaines ont publi\u00e9<\/a> un article d\u00e9crivant une attaque r\u00e9elle qui abuse du fait que les changements de fr\u00e9quence du processeur d\u00e9pendent de la charge qu\u2019il supporte (comportement standard pour les processeurs modernes). La fr\u00e9quence du processeur est mesur\u00e9e en hertz, d\u2019o\u00f9 le nom de Hertzbleed, faisant allusion au fait qu\u2019un changement de cette fr\u00e9quence entra\u00eene une fuite de donn\u00e9es.<\/p>\n

Cette m\u00e9thode peut \u00eatre class\u00e9e comme une attaque mat\u00e9rielle, c\u2019est-\u00e0-dire une attaque qui exploite les vuln\u00e9rabilit\u00e9s ou autres faiblesses sp\u00e9cifiques du mat\u00e9riel. Il existe de nombreuses attaques de ce type, mais presque toutes n\u00e9cessitent un acc\u00e8s direct au poste cible ou \u00e0 une puce sp\u00e9cifique. Mais Hertzbleed peut fonctionner \u00e0 distance !<\/p>\n

Cette \u00e9tude est d\u2019un grand int\u00e9r\u00eat et, malgr\u00e9 sa complexit\u00e9, elle peut \u00eatre r\u00e9sum\u00e9e dans des termes simples. Cependant, pour en comprendre au moins les subtilit\u00e9s, il est n\u00e9cessaire d\u2019avoir quelques connaissances de base. Nous avons donc d\u00e9cid\u00e9 de faire les deux : de publier une explication simple au sujet de Hertzbleed, et une autre l\u00e9g\u00e8rement plus compliqu\u00e9e (mais toujours sans graphiques sophistiqu\u00e9s ni calculs obscurs).<\/p>\n

\"\"

Comme il est d\u00e9sormais habituel, Hertzbleed a son propre site et son propre logo. Le logo reprend l\u2019essence m\u00eame de la vuln\u00e9rabilit\u00e9 : la modification de la fr\u00e9quence du processeur entra\u00eene des fuites. Source<\/a><\/p><\/div>\n

\u00a0<\/strong><\/p>\n

L\u2019explication simple<\/h2>\n

Pour \u00e9conomiser de l\u2019\u00e9nergie, les processeurs modernes ne maintiennent pas la m\u00eame fr\u00e9quence en continu. Au lieu de cela, la fr\u00e9quence (ainsi que la tension du processeur) s\u2019ajuste automatiquement en fonction de sa charge. Lorsque les t\u00e2ches sont peu nombreuses, la fr\u00e9quence peut \u00eatre tr\u00e8s basse (par exemple, 900 MHz au lieu de la fr\u00e9quence nominale de 3,2 GHz). Si les t\u00e2ches sont nombreuses, la fr\u00e9quence d\u2019un ou de tous les c\u0153urs du processeur peut \u00eatre augment\u00e9e au-dessus de la valeur de base. En pratique, la charge (le nombre et la complexit\u00e9 des t\u00e2ches) n\u2019est pas le seul crit\u00e8re de modification la fr\u00e9quence. Celle-ci peut par exemple \u00eatre abaiss\u00e9e si le processeur surchauffe.<\/p>\n

Les chercheurs ont r\u00e9ussi \u00e0 exploiter cette fonctionnalit\u00e9 native pour mesurer l\u2019\u00e9tat du processeur lorsqu\u2019il ex\u00e9cutait un programme de cryptage de donn\u00e9es et ainsi voler des informations sensibles. Ils ont trouv\u00e9 une caract\u00e9ristique d\u2019un algorithme de cryptage moderne qui \u00a0\u00bb force \u00a0\u00bb le processeur \u00e0 augmenter la fr\u00e9quence lors du traitement de certaines donn\u00e9es. Lorsque la fr\u00e9quence augmente, les donn\u00e9es sont trait\u00e9es plus rapidement, et l\u2019ordinateur attaqu\u00e9 r\u00e9pond plus vite aux demandes. Les chercheurs ont pu reconstruire la cl\u00e9 secr\u00e8te de cryptage en mesurant le temps de r\u00e9ponse. Arm\u00e9s de cette cl\u00e9, ils peuvent th\u00e9oriquement intercepter et d\u00e9crypter les donn\u00e9es \u00e9chang\u00e9es par le syst\u00e8me cible, par exemple avec d\u2019autres ordinateurs dans un r\u00e9seau priv\u00e9 virtuel. Et tout cela sans avoir qu\u2019il n\u2019y ait la moindre chance d\u2019enregistrer le \u00a0\u00bb vol \u00a0\u00bb de la cl\u00e9.<\/p>\n

Hertzbleed d\u00e9veloppe l\u2019id\u00e9e d\u2019attaques mat\u00e9rielles par le biais de canaux dits secondaires. En m\u00eame temps, il introduit la possibilit\u00e9 th\u00e9orique de voler des donn\u00e9es \u00e0 distance en envoyant des requ\u00eates \u00e0 la victime potentielle via le r\u00e9seau. Pour l\u2019instant, cela reste un exercice purement th\u00e9orique dans la recherche de vuln\u00e9rabilit\u00e9s complexes dans les processeurs modernes. Il est n\u00e9anmoins tout \u00e0 fait possible que de telles attaques soient \u00ab\u00a0simplifi\u00e9es\u00a0\u00bb \u00e0 l\u2019avenir.<\/p>\n

Une l\u00e9g\u00e8rement plus compliqu\u00e9e<\/h2>\n

Les attaques par canal lat\u00e9ral<\/em><\/a> sont r\u00e9alis\u00e9es en observant indirectement le fonctionnement d\u2019une seule puce ou d\u2019un ordinateur entier. La m\u00e9thode classique d\u2019attaque par canal lat\u00e9ral consiste \u00e0 observer les variations du courant \u00e9lectrique consomm\u00e9 par la puce. Si la puce est en train de chiffrer des donn\u00e9es \u00e0 l\u2019aide d\u2019une cl\u00e9 secr\u00e8te, par exemple, les variations de la consommation \u00e9lectrique peuvent dans certains cas \u00eatre utilis\u00e9es pour reconstruire la cl\u00e9.<\/p>\n

Les canaux lat\u00e9raux peuvent \u00eatre logiciels ou mat\u00e9riels. La c\u00e9l\u00e8bre \u00e9tude Spectre<\/a> utilise un canal lat\u00e9ral de ce type directement dans le processeur, en exploitant des fonctions d\u2019ex\u00e9cution sp\u00e9culative pour voler des informations sensibles. De plus, il n\u2019est parfois pas n\u00e9cessaire de brancher un voltm\u00e8tre \u00e0 l\u2019ordinateur pour surveiller la consommation d\u2019\u00e9nergie du processeur car il y en a souvent un int\u00e9gr\u00e9. Une attaque li\u00e9e \u00e0 Hertzbleed a d\u00e9j\u00e0 \u00e9t\u00e9 d\u00e9velopp\u00e9e en utilisant un syst\u00e8me de surveillance de la consommation \u00e9lectrique moyenne des processeurs Intel.<\/p>\n

Penchons-nous maintenant sur r\u00e9glage dynamique de la fr\u00e9quence du processeur<\/em>. Cela est possible gr\u00e2ce \u00e0 la technique DVFS, c\u2019est-\u00e0-dire la mise \u00e0 l\u2019\u00e9chelle dynamique de la tension et de la fr\u00e9quence. En effet, la tension du processeur, tout comme la fr\u00e9quence, varie pour assurer des conditions de fonctionnement optimales (faible consommation d\u2019\u00e9nergie \u00e0 faible charge, fonctionnement stable \u00e0 capacit\u00e9 maximale). Les chercheurs d\u00e9crivent en d\u00e9tail comment ils ont r\u00e9alis\u00e9 de nombreuses exp\u00e9riences DVFS sur des processeurs Intel (Intel lui-m\u00eame appelle cette technologie Turbo Boost). Ils ont charg\u00e9 le processeur avec une charge n\u00e9gligeable (des calculs arithm\u00e9tiques de base) et ont observ\u00e9 les modifications de la fr\u00e9quence. Plusieurs tendances se sont d\u00e9gag\u00e9es : pour simplifier au maximum, avec un ensemble de donn\u00e9es de calcul, la fr\u00e9quence du processeur avait tendance \u00e0 augmenter, mais pas avec un autre. De m\u00eame, une fr\u00e9quence accrue entra\u00eenait des calculs plus rapides et, par cons\u00e9quent, un r\u00e9sultat plus rapide.<\/p>\n

Examinons un troisi\u00e8me terme technique pertinent pour tout cela : la programmation en temps constant. Ce terme est important pour l\u2019impl\u00e9mentation d\u2019un algorithme de cryptage dans un programme. Supposons que nous ayons un programme qui re\u00e7oit une certaine phrase en entr\u00e9e et qui \u00e9met la m\u00eame phrase, mais crypt\u00e9e. Nous pouvons saisir des donn\u00e9es, mais nous ne connaissons pas la cl\u00e9 secr\u00e8te de cryptage, que nous essayons de d\u00e9terminer en observant le temps d\u2019ex\u00e9cution, puisque le temps d\u2019ex\u00e9cution de la fonction d\u00e9pend des donn\u00e9es d\u2019entr\u00e9e. Cela revient \u00e0 tenter de p\u00e9n\u00e9trer dans un coffre-fort verrouill\u00e9 par un code num\u00e9rique secret qui r\u00e9agit de mani\u00e8re l\u00e9g\u00e8rement diff\u00e9rente aux s\u00e9quences de chiffres presque justes, en donnant des indices de type \u00ab\u00a0froid\u00a0\u00bb et \u00ab\u00a0chaud\u00a0\u00bb. La plupart des programmes qui mettent en \u0153uvre des algorithmes de cryptage comportent un m\u00e9canisme de protection destin\u00e9 \u00e0 emp\u00eacher toute tentative de d\u00e9terminer la cl\u00e9 de cette mani\u00e8re : c\u2019est le principe m\u00eame de la programmation en temps constant.<\/p>\n

Le r\u00e9sultat le plus important de l\u2019\u00e9tude de Hertzbleed est que l\u2019ajustement dynamique de la fr\u00e9quence du processeur<\/em> brise le principe de la programmation en temps constant<\/em>, c\u2019est-\u00e0-dire l\u2019invariance temporelle dans le cryptage. Les auteurs ont montr\u00e9 comment en profiter. Pour cela, ils ont pris un syst\u00e8me dot\u00e9 d\u2019un logiciel de cryptage de donn\u00e9es r\u00e9el et ont introduit une s\u00e9quence de caract\u00e8res, que le programme a ensuite essay\u00e9 de d\u00e9crypter. Les entr\u00e9es ont \u00e9t\u00e9 choisies pour cr\u00e9er les conditions permettant \u00e0 un attaquant de reconstruire la cl\u00e9 de cryptage. De plus, la cl\u00e9 est extraite par un canal lat\u00e9ral<\/em>. Cela signifie que la fuite de donn\u00e9es se produit en raison d\u2019un changement de la fr\u00e9quence du processeur et, par cons\u00e9quent, du temps d\u2019ex\u00e9cution du programme et du temps de r\u00e9ponse \u00e0 la demande de l\u2019attaquant.<\/p>\n

Des cons\u00e9quences manquantes<\/h2>\n

Dans notre \u00ab\u00a0explication l\u00e9g\u00e8rement plus compliqu\u00e9e\u00a0\u00bb de la m\u00e9thode Hertzbleed, nous avons couvert environ\u2026 0,05 % des informations r\u00e9elles pr\u00e9sent\u00e9es par les chercheurs. Il existe d\u2019innombrables autres nuances \u00e9galement pertinentes pour comprendre le fonctionnement. Ils ont notamment utilis\u00e9 une caract\u00e9ristique de l\u2019algorithme d\u2019encapsulation des cl\u00e9s SIKE pour cr\u00e9er les conditions permettant de rendre possible la fuite par le biais du temps de r\u00e9ponse ou du changement de fr\u00e9quence. Cette m\u00e9thode est similaire \u00e0 l\u2019attaque Spectre susmentionn\u00e9e, qui n\u00e9cessite la cr\u00e9ation de conditions sp\u00e9ciales dans le logiciel attaqu\u00e9 pour permettre le vol de donn\u00e9es importantes. Sur la base des r\u00e9sultats de l\u2019\u00e9tude, il est impossible de dire sans \u00e9quivoque si la vuln\u00e9rabilit\u00e9 se trouve dans le processeur ou dans le programme.<\/p>\n

Et il faut mentionner un aspect flagrant de la r\u00e9alisation : bien que les chercheurs aient d\u00e9montr\u00e9 une attaque r\u00e9elle et pratique (et non th\u00e9orique), ils l\u2019ont r\u00e9alis\u00e9e dans des conditions contr\u00f4l\u00e9es. La variation du temps de r\u00e9ponse en fonction des entr\u00e9es \u00e9tait toujours constante. Qu\u2019en est-il si le processeur ex\u00e9cute simultan\u00e9ment d\u2019autres t\u00e2ches qui affectent \u00e9galement le temps de r\u00e9ponse et rendent les donn\u00e9es plus bruyantes ? Enfin, m\u00eame dans ces circonstances id\u00e9ales, la reconstruction de la cl\u00e9 de cryptage (dans deux exp\u00e9riences diff\u00e9rentes) a pris 36 heures et 89 heures ! Pendant ce temps, des milliers de requ\u00eates par seconde ont \u00e9t\u00e9 envoy\u00e9es au programme de cryptage, ce qui \u00e9tait le seul moyen de s\u2019assurer que toutes les caract\u00e9ristiques n\u00e9cessaires au fonctionnement du logiciel et du mat\u00e9riel \u00e9taient align\u00e9es pour aboutir \u00e0 la fuite. C\u2019est extr\u00eamement long !<\/p>\n

La r\u00e9action \u00e0 cette \u00e9tude a donc \u00e9t\u00e9 ambigu\u00eb. D\u2019une part, les vuln\u00e9rabilit\u00e9s ont re\u00e7u les identifiants habituels : CVE-2022-23823 pour Intel, et CVE-2022-24436 pour AMD. Il semblerait que le probl\u00e8me se situe, apr\u00e8s tout, dans les processeurs. Intel<\/a> et AMD<\/a> ont cependant indiqu\u00e9 qu\u2019ils ne pr\u00e9voyaient pas de publier de mises \u00e0 jour pour les syst\u00e8mes concern\u00e9s (pour Intel, il s\u2019agit des processeurs de la 8e \u00e0 la 11e g\u00e9n\u00e9ration). En fait, la modification de l\u2019algorithme SIKE a rendu l\u2019attaque d\u00e9montr\u00e9e impossible. Microsoft et Cloudflare, qui utilisent SIKE comme l\u2019un des \u00e9l\u00e9ments de leurs syst\u00e8mes de cryptage, ont mis \u00e0 jour leur propre logiciel.<\/p>\n

N\u00e9anmoins, l\u2019\u00e9tude a une importance consid\u00e9rable. Comme Spectre en 2018, ce ne sera pas la derni\u00e8re attaque de cette classe. Si un exemple de fuite de donn\u00e9es par ajustement dynamique de la fr\u00e9quence du processeur peut \u00eatre d\u00e9montr\u00e9, d\u2019autres suivront certainement. C\u2019est aussi un ensemble de travaux importants pour les sp\u00e9cialistes du cryptage. SIKE est un algorithme plut\u00f4t r\u00e9cent, candidat au titre de \u00ab\u00a0solution de cryptographie post-quantique\u00a0\u00bb. Il a \u00e9t\u00e9 analys\u00e9 pour sa robustesse contre toute attaque par canal lat\u00e9ral, et s\u2019est av\u00e9r\u00e9 assez r\u00e9sistant. Cependant, l\u2019\u00e9tude de Hertzbleed a montr\u00e9 que de nouvelles options sont apparues.<\/p>\n

En somme, comme c\u2019est souvent le cas avec de telles \u00e9tudes, cette attaque a \u00e9t\u00e9 \u00ab\u00a0d\u00e9couverte\u00a0\u00bb mais n\u2019a pas pu \u00eatre mise en \u0153uvre de mani\u00e8re compl\u00e8te et r\u00e9ussi dans des conditions r\u00e9elles. Les d\u00e9veloppeurs de processeurs et de programmes particuli\u00e8rement sensibles au hacking tireront leurs propres conclusions et apporteront des modifications avant qu\u2019il ne soit possible de r\u00e9ellement voler quelque chose. Mais il y a une petite chance que la prochaine fois, ces chercheurs ou d\u2019autres trouvent quelque chose qui permette aux attaquants d\u2019intercepter le trafic r\u00e9seau crypt\u00e9 ou de casser le cryptage tout en restant anonyme, par exemple. Avec un peu d\u2019imagination, il est possible d\u2019amplifier le sch\u00e9ma d\u00e9crit dans cette \u00e9tude \u00e0 de telles proportions. Cela reste \u00e0 prouver, et l\u2019\u00e9tude de Hertzbleed (et la difficult\u00e9 que nous avons eue \u00e0 la d\u00e9crire en termes simples) montre que ce n\u2019est pas une t\u00e2che facile. Pour les vuln\u00e9rabilit\u00e9s de classe Spectre, aucune avanc\u00e9e de ce type n\u2019a \u00e9t\u00e9 d\u00e9montr\u00e9e<\/a> depuis plus de quatre ans. Ici aussi, les choses vont probablement continuer \u00e0 stagner : dans un an environ, un autre rapport sera publi\u00e9, qui fera l\u00e9g\u00e8rement progresser et clarifiera le pr\u00e9c\u00e9dent. C\u2019est un r\u00e9sultat positif. Apr\u00e8s tout, nous avons d\u00e9j\u00e0 assez de probl\u00e8mes avec la cybers\u00e9curit\u00e9 !<\/p>\n","protected":false},"excerpt":{"rendered":"

L’une des \u00e9tudes les plus complexes, mais facile \u00e0 comprendre, sur l’infos\u00e9curit\u00e9 de ces derniers temps.<\/p>\n","protected":false},"author":665,"featured_media":19164,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2112,3150,3151],"tags":[4296,2673,322],"class_list":{"0":"post-19160","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-processeurs","11":"tag-spectre","12":"tag-vulnerabilites"},"hreflang":[{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/hertzbleed-attack\/19160\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/hertzbleed-attack\/24346\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/hertzbleed-attack\/19812\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/hertzbleed-attack\/26719\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/hertzbleed-attack\/25052\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/hertzbleed-attack\/27390\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/hertzbleed-attack\/33493\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/hertzbleed-attack\/10883\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/hertzbleed-attack\/44824\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/hertzbleed-attack\/19724\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/hertzbleed-attack\/29043\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/hertzbleed-attack\/25222\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/hertzbleed-attack\/30710\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/hertzbleed-attack\/30458\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.fr\/blog\/tag\/vulnerabilites\/","name":"Vuln\u00e9rabilit\u00e9s"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/19160","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/comments?post=19160"}],"version-history":[{"count":5,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/19160\/revisions"}],"predecessor-version":[{"id":19172,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/19160\/revisions\/19172"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media\/19164"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media?parent=19160"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/categories?post=19160"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/tags?post=19160"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}