# Semestre SILM: livre blanc

Guillaume Hiet

► To cite this version:

Guillaume Hiet. Semestre SILM: livre blanc. CentraleSupélec; Inria. 2020. hal-04577909

HAL Id: hal-04577909

https://hal.science/hal-04577909

Submitted on 16 May 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Semestre SILM: livre blanc

Guillaume Hiet

► To cite this version:

Guillaume Hiet. Semestre SILM: livre blanc. CentraleSupélec; Inria. 2020. hal-04577909

HAL Id: hal-04577909

https://hal.science/hal-04577909v1

Submitted on 16 May 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

CentraleSupélec

<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /></figure>

# Semestre SILM : livre blanc

Guillaume Hiet

20 décembre 2020
<figure><img src="image_2.png" /></figure>

CentraleSupélec

<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /></figure>

# Semestre SILM : livre blanc

Guillaume Hiet

20 décembre 2020
# Table des matières

Acronymes 1

1 Introduction 5

2 État de l'art 8

2.1 Support matériel pour la sécurité logicielle 8

2.1.1 Trusted Platform Module et late launch 10

2.1.2 System Management Mode 11

2.1.3 Sécurité basée sur la virtualisation 12

2.1.4 Enclaves sécurisées 16

2.1.5 Co-processeur de sécurité 20

2.1.6 Mécanismes de sécurité au niveau du jeu d'instructions 24

2.1.7 Mécanismes de traces et compteurs de performance 30

2.1.8 Spécification et preuve formelles des architectures matérielles 31

2.2 Attaques logicielles contre la microarchitecture 33

2.2.1 Attaques logicielles par canaux auxiliaires 35

2.2.2 Exploitation de l'exécution transitoire 39

2.2.3 Attaques logicielles par injection de fautes 43

2.2.4 Attaques contre les enclaves sécurisées 45

2.2.5 Rétroconception de la microarchitecture 49

2.3 Contre-mesures logicielles face aux attaques contre la microarchitecture 52

2.3.1 Contre-mesures logicielles face aux attaques par canaux auxiliaires 53

2.3.2 Protections contre les attaques exploitant l'exécution transitoire 57

2.3.3 Contre-mesures logicielles face aux attaques par martellement de la mémoire 60

3 Perspectives 62

3.1 Défis et perspectives scientifiques 62

3.1.1 Fossé sémantique et isolation du moniteur de sécurité 62

3.1.2 Support matériel pour la réponse aux intrusions 62

3.1.3 Contrat matériel/logiciel pour lutter contre les canaux auxiliaires 63

3.1.4 Processeur générique résistant aux attaques par observation de la consommation de courant 64

3.1.5 Automatisation de l'analyse des attaques logicielles contre la microarchitecture 64

3.1.6 Modélisation et preuve formelles des mécanismes de sécurité matériels 65

3.1.7 Micro-isolation 65

3.1.8 Identification de nouvelles attaques contre la microarchitecture 66
# Table des matières

Acronymes 1

1 Introduction 5

2 État de l'art 8

2.1 Support matériel pour la sécurité logicielle 8

2.1.1 Trusted Platform Module et late launch 10

2.1.2 System Management Mode 11

2.1.3 Sécurité basée sur la virtualisation 12

2.1.4 Enclaves sécurisées 16

2.1.5 Co-processeur de sécurité 20

2.1.6 Mécanismes de sécurité au niveau du jeu d'instructions 24

2.1.7 Mécanismes de traces et compteurs de performance 30

2.1.8 Spécification et preuve formelles des architectures matérielles 31

2.2 Attaques logicielles contre la microarchitecture 33

2.2.1 Attaques logicielles par canaux auxiliaires 35

2.2.2 Exploitation de l'exécution transitoire 39

2.2.3 Attaques logicielles par injection de fautes 43

2.2.4 Attaques contre les enclaves sécurisées 45

2.2.5 Rétroconception de la microarchitecture 49

2.3 Contre-mesures logicielles face aux attaques contre la microarchitecture 52

2.3.1 Contre-mesures logicielles face aux attaques par canaux auxiliaires 53

2.3.2 Protections contre les attaques exploitant l'exécution transitoire 57

2.3.3 Contre-mesures logicielles face aux attaques par martellement de la mémoire 60

3 Perspectives 62

3.1 Défis et perspectives scientifiques 62

3.1.1 Fossé sémantique et isolation du moniteur de sécurité 62

3.1.2 Support matériel pour la réponse aux intrusions 62

3.1.3 Contrat matériel/logiciel pour lutter contre les canaux auxiliaires 63

3.1.4 Processeur générique résistant aux attaques par observation de la consommation de courant 64

3.1.5 Automatisation de l'analyse des attaques logicielles contre la microarchitecture 64

3.1.6 Modélisation et preuve formelles des mécanismes de sécurité matériels 65

3.1.7 Micro-isolation 65

3.1.8 Identification de nouvelles attaques contre la microarchitecture 66
<table><tr><td>3.1.9</td><td>Environnement d'exécution réellement de confiance</td><td>66</td></tr><tr><td>3.2</td><td>Perspectives d'application et transfert de technologie</td><td>67</td></tr><tr><td>3.2.1</td><td>Architecture CHERI</td><td>67</td></tr><tr><td>3.2.2</td><td>Introspection et vérification d'intégrité à l'exécution</td><td>68</td></tr></table>
<table><tr><td>3.1.9</td><td>Environnement d'exécution réellement de confiance</td><td>66</td></tr><tr><td>3.2</td><td>Perspectives d'application et transfert de technologie</td><td>67</td></tr><tr><td>3.2.1</td><td>Architecture CHERI</td><td>67</td></tr><tr><td>3.2.2</td><td>Introspection et vérification d'intégrité à l'exécution</td><td>68</td></tr></table>
Acronyms

ALU Arithmetic-Logic Unit (unité arithmétique et logique). 34

AMT Active Management Technology. 21

API Application Programming Interface (interface de programmation). 63, 67

ASIC Application-Specific Integrated Circuit (circuit intégré spécialisé). 65

ASLR Address Space Layout Randomization (distribution aléatoire de l'espace d'adressage). 25, 38, 39, 42, 46, 56

BIOS Basic Input Output System. 10

BMC Baseboard Management Controller. 22

BTI Branch Target Indicators. 26

CAT Cache Allocation Technology. 38, 55

CET Control-flow Enforcement Technology. 26

CFI Control Flow Integrity (intégrité du flux de contrôle). 6, 17, 22, 23, 26, 28, 30, 60

CSME Converged Security and Management Engine. 21-23, 52

DCA Direct Cache Access. 50

DCI Direct Connect Interface. 21

DFI Data Flow Integrity. 29

DIFT Dynamic Information Flow Tracking (suivi dynamique des flux d'information). 20, 22-24, 29

DMA Direct Memory Access (accès direct à la mémoire). 14, 60

DRAM Dynamic Random Access Memory (mémoire dynamique à accès aléatoire). 17, 18, 34, 44, 45, 50, 51, 60
# Acronyms

ALU Arithmetic-Logic Unit (unité arithmétique et logique). 34

AMT Active Management Technology. 21

API Application Programming Interface (interface de programmation). 63, 67

ASIC Application-Specific Integrated Circuit (circuit intégré spécialisé). 65

ASLR Address Space Layout Randomization (distribution aléatoire de l'espace d'adressage). 25, 38, 39, 42, 46, 56

BIOS Basic Input Output System. 10

BMC Baseboard Management Controller. 22

BTI Branch Target Indicators. 26

CAT Cache Allocation Technology. 38, 55

CET Control-flow Enforcement Technology. 26

CFI Control Flow Integrity (intégrité du flux de contrôle). 6, 17, 22, 23, 26, 28, 30, 60

CSME Converged Security and Management Engine. 21-23, 52

DCA Direct Cache Access. 50

DCI Direct Connect Interface. 21

DFI Data Flow Integrity. 29

DIFT Dynamic Information Flow Tracking (suivi dynamique des flux d'information). 20, 22-24, 29

DMA Direct Memory Access (accès direct à la mémoire). 14, 60

DRAM Dynamic Random Access Memory (mémoire dynamique à accès aléatoire). 17, 18, 34, 44, 45, 50, 51, 60
DRM Digital Rights Management (gestion des droits numériques). 17, 21

ECC Error-Correcting Code (code correcteur d'erreurs). 50, 51

ETM Embedded Trace Macrocell. 24, 30, 31

FIDO Fast IDentity Online. 17

FPGA Field-Programmable Gate Array (réseau de portes programmables in situ). 8, 16, 32, 65

GPU Graphics Processing Unit. 22

HDL Hardware Description Language (langage de description du matériel). 33, 65

IBPB Indirect Branch Predictor Barrier. 59

IBRS Indirect Branch Restricted Speculation. 59

ISA Instruction Set Architecture (jeu d'instructions). 24–26, 29–32, 52, 63–65, 68

ISR Instruction Set Randomization. 30

LLC Last Level Cache. 36–38, 49, 50, 55

MAC Message Authentication Code. 28

MDS Microarchitectural Data Sampling. 42

MMU Memory Managment Unit. 38, 39

MPK Memory Protection Keys. 25–27, 42

MPX Memory Protection Extensions. 27, 28

MTE Memory Tagging Extension. 28

OS Operating System (système d'exploitation). 6, 10–13, 16–20, 22, 25–28, 30, 31, 39, 42, 43, 45–47, 51, 53, 55, 56, 59, 60, 64–68

PA Pointer Authentication. 28

PAC Pointer Authentication Code. 28, 29

PAN Privilege Access Never. 25

PCH Platform Controller Hub. 21

PCI Peripheral Component Interconnect. 22

PSP Platform Security Processor. 21

PTM Program Trace Macrocell. 24, 30, 31
DRM Digital Rights Management (gestion des droits numériques). 17, 21

ECC Error-Correcting Code (code correcteur d'erreurs). 50, 51

ETM Embedded Trace Macrocell. 24, 30, 31

FIDO Fast IDentity Online. 17

FPGA Field-Programmable Gate Array (réseau de portes programmables in situ). 8, 16, 32, 65

GPU Graphics Processing Unit. 22

HDL Hardware Description Language (langage de description du matériel). 33, 65

IBPB Indirect Branch Predictor Barrier. 59

IBRS Indirect Branch Restricted Speculation. 59

ISA Instruction Set Architecture (jeu d'instructions). 24–26, 29–32, 52, 63–65, 68

ISR Instruction Set Randomization. 30

LLC Last Level Cache. 36–38, 49, 50, 55

MAC Message Authentication Code. 28

MDS Microarchitectural Data Sampling. 42

MMU Memory Managment Unit. 38, 39

MPK Memory Protection Keys. 25–27, 42

MPX Memory Protection Extensions. 27, 28

MTE Memory Tagging Extension. 28

OS Operating System (système d'exploitation). 6, 10–13, 16–20, 22, 25–28, 30, 31, 39, 42, 43, 45–47, 51, 53, 55, 56, 59, 60, 64–68

PA Pointer Authentication. 28

PAC Pointer Authentication Code. 28, 29

PAN Privilege Access Never. 25

PCH Platform Controller Hub. 21

PCI Peripheral Component Interconnect. 22

PSP Platform Security Processor. 21

PTM Program Trace Macrocell. 24, 30, 31
<table>
  <tr>
    <td>PXN</td>
    <td>Privilege Execute Never. 25, 31</td>
  </tr>
  <tr>
    <td>RAPL</td>
    <td>Running Average Power Limit. 39</td>
  </tr>
  <tr>
    <td>REE</td>
    <td>Rich Execution Environment. 17, 18</td>
  </tr>
  <tr>
    <td>ROP</td>
    <td>Return Oriented Programming. 16, 25–27, 29, 30, 41, 46, 56</td>
  </tr>
  <tr>
    <td>SDK</td>
    <td>Software Development Kit (kit de développement logiciel). 19, 46</td>
  </tr>
  <tr>
    <td>SE</td>
    <td>Secure Element (élément sécurisé). 66, 67</td>
  </tr>
  <tr>
    <td>SEP</td>
    <td>Secure Enclave Processor. 20, 21</td>
  </tr>
  <tr>
    <td>SGX</td>
    <td>Software Guard Extensions. 11, 16, 18–20, 39, 42–48, 51, 54–56</td>
  </tr>
  <tr>
    <td>SMAP</td>
    <td>Supervisor Mode Access Prevention. 25</td>
  </tr>
  <tr>
    <td>SMEP</td>
    <td>Supervisor Mode Execution Prevention. 25, 31</td>
  </tr>
  <tr>
    <td>SMI</td>
    <td>System Management Interrupt. 11, 12</td>
  </tr>
  <tr>
    <td>SMM</td>
    <td>System Management Mode. 9, 11, 12, 22, 23, 32, 68</td>
  </tr>
  <tr>
    <td>SMRAM</td>
    <td>System Management RAM. 11</td>
  </tr>
  <tr>
    <td>SMT</td>
    <td>Satisfiability Modulo Theories. 33</td>
  </tr>
  <tr>
    <td>SoC</td>
    <td>System on a Chip (système sur une puce). 17, 18, 28, 30, 49, 50</td>
  </tr>
  <tr>
    <td>STIBP</td>
    <td>Single Thread Indirect Branch Prediction. 59</td>
  </tr>
  <tr>
    <td>TCB</td>
    <td>Trusted Computing Base (base de confiance). 14, 18–20, 45</td>
  </tr>
  <tr>
    <td>TEE</td>
    <td>Trusted Execution Environment (environnement d'exécution de confiance). 12, 16–18, 20, 24, 45–48, 66–68</td>
  </tr>
  <tr>
    <td>TLB</td>
    <td>Translation Lookaside Buffer. 38</td>
  </tr>
  <tr>
    <td>TOCTOU</td>
    <td>Time-Of-Check to Time-Of-Use. 45</td>
  </tr>
  <tr>
    <td>TPM</td>
    <td>Trusted Platform Module. 9–12, 21</td>
  </tr>
  <tr>
    <td>TRR</td>
    <td>Target Row Refresh. 51</td>
  </tr>
  <tr>
    <td>TSX</td>
    <td>Transactional Synchronization Extensions. 19, 37, 38, 56</td>
  </tr>
  <tr>
    <td>TXT</td>
    <td>Trusted Execution Technology. 10, 11, 15, 16, 18</td>
  </tr>
  <tr>
    <td>UEFI</td>
    <td>Unified Extensible Firmware Interface (interface extensible et unifiée du micrologiciel). 10, 21, 25, 44, 68</td>
  </tr>
  <tr>
    <td>USB</td>
    <td>Universal Serial Bus. 21, 52</td>
  </tr>
  <tr>
    <td>VM</td>
    <td>Virtual Machine (machine virtuelle). 12, 14–16</td>
  </tr>
  <tr>
    <td>VMI</td>
    <td>Virtual Machine Introspection (interspection de machines virtuelles). 15, 62</td>
  </tr>
</table>
<table>
  <tr>
    <td>PXN</td>
    <td>Privilege Execute Never. 25, 31</td>
  </tr>
  <tr>
    <td>RAPL</td>
    <td>Running Average Power Limit. 39</td>
  </tr>
  <tr>
    <td>REE</td>
    <td>Rich Execution Environment. 17, 18</td>
  </tr>
  <tr>
    <td>ROP</td>
    <td>Return Oriented Programming. 16, 25–27, 29, 30, 41, 46, 56</td>
  </tr>
  <tr>
    <td>SDK</td>
    <td>Software Development Kit (kit de développement logiciel). 19, 46</td>
  </tr>
  <tr>
    <td>SE</td>
    <td>Secure Element (élément sécurisé). 66, 67</td>
  </tr>
  <tr>
    <td>SEP</td>
    <td>Secure Enclave Processor. 20, 21</td>
  </tr>
  <tr>
    <td>SGX</td>
    <td>Software Guard Extensions. 11, 16, 18–20, 39, 42–48, 51, 54–56</td>
  </tr>
  <tr>
    <td>SMAP</td>
    <td>Supervisor Mode Access Prevention. 25</td>
  </tr>
  <tr>
    <td>SMEP</td>
    <td>Supervisor Mode Execution Prevention. 25, 31</td>
  </tr>
  <tr>
    <td>SMI</td>
    <td>System Management Interrupt. 11, 12</td>
  </tr>
  <tr>
    <td>SMM</td>
    <td>System Management Mode. 9, 11, 12, 22, 23, 32, 68</td>
  </tr>
  <tr>
    <td>SMRAM</td>
    <td>System Management RAM. 11</td>
  </tr>
  <tr>
    <td>SMT</td>
    <td>Satisfiability Modulo Theories. 33</td>
  </tr>
  <tr>
    <td>SoC</td>
    <td>System on a Chip (système sur une puce). 17, 18, 28, 30, 49, 50</td>
  </tr>
  <tr>
    <td>STIBP</td>
    <td>Single Thread Indirect Branch Prediction. 59</td>
  </tr>
  <tr>
    <td>TCB</td>
    <td>Trusted Computing Base (base de confiance). 14, 18–20, 45</td>
  </tr>
  <tr>
    <td>TEE</td>
    <td>Trusted Execution Environment (environnement d’exécution de confiance). 12, 16–18, 20, 24, 45–48, 66–68</td>
  </tr>
  <tr>
    <td>TLB</td>
    <td>Translation Lookaside Buffer. 38</td>
  </tr>
  <tr>
    <td>TOCTOU</td>
    <td>Time-Of-Check to Time-Of-Use. 45</td>
  </tr>
  <tr>
    <td>TPM</td>
    <td>Trusted Platform Module. 9–12, 21</td>
  </tr>
  <tr>
    <td>TRR</td>
    <td>Target Row Refresh. 51</td>
  </tr>
  <tr>
    <td>TSX</td>
    <td>Transactional Synchronization Extensions. 19, 37, 38, 56</td>
  </tr>
  <tr>
    <td>TXT</td>
    <td>Trusted Execution Technology. 10, 11, 15, 16, 18</td>
  </tr>
  <tr>
    <td>UEFI</td>
    <td>Unified Extensible Firmware Interface (interface extensible et unifiée du micrologiciel). 10, 21, 25, 44, 68</td>
  </tr>
  <tr>
    <td>USB</td>
    <td>Universal Serial Bus. 21, 52</td>
  </tr>
  <tr>
    <td>VM</td>
    <td>Virtual Machine (machine virtuelle). 12, 14–16</td>
  </tr>
  <tr>
    <td>VMI</td>
    <td>Virtual Machine Introspection (interspection de machines virtuelles). 15, 62</td>
  </tr>
</table>
# Chapitre 1

## Introduction

La sécurité des composants logiciels et celle des composants matériels ont souvent été considérées comme deux problèmes spécifiques, abordés par des communautés distinctes. Toutefois, il apparaît de plus en plus important de combiner les aspects logiciels et matériels afin de prendre en compte les nouvelles attaques logicielles. Par exemple, des vulnérabilités matérielles comme Spectre ou Meltdown peuvent être exploitées par des attaques purement logicielles. De telles attaques peuvent être exécutées à distance et ne nécessitent pas d'accès physique à la plateforme matérielle ciblée. Il est donc nécessaire d'étudier de manière approfondie la sécurité des interfaces logicielles/matérielles, tant du point de vue des attaques que des moyens de défense. Cette étude soulève un certain nombre de défis.

Tout d'abord, les plateformes matérielles sont de plus en plus complexes et les spécifications de leur différents composants matériels ne sont pas toujours publiquement accessibles. En outre, ces spécifications sont parfois incomplètes, incorrectes ou ambiguës. Des approches ont donc été proposées par différents travaux de recherche afin de déterminer le fonctionnement et l'état de ces composants matériels avant de pouvoir les utiliser ou les analyser.

Évaluer le niveau de sécurité qu'offrent ces plateformes matérielles face aux attaques logicielles constitue également un défi important. L'étude des vulnérabilités existantes ou nouvelles qui peuvent affecter les plateformes matérielles est cruciale. Il convient également d'analyser les attaques logicielles qui peuvent exploiter de telles vulnérabilités afin d'évaluer leur facilité de mise en œuvre et leur criticité.

Face à ces menaces, il convient enfin d'étudier les mécanismes de défense que l'on peut mettre en place. En effet, les plateformes récentes embarquent de plus en plus de mécanismes de sécurité au sein de leurs composants matériels. Cela soulève un certain nombre de questions intéressantes : Quels types de mécanismes de sécurité peuvent être implémentés dans les plateformes matérielles à un coût acceptable ? Quelles sont précisément les propriétés de sécurité qui sont garanties par de tels mécanismes ? En outre, des contremesures purement logicielles peuvent être déployées dans les systèmes d'exploitation et les applications exécutés sur les plateformes matérielles afin de les protéger contre des attaques logicielles qui exploiteraient des vulnérabilités matérielles.

Le semestre thématique SILM fut dédié à la sécurité des interfaces logiciel/matériel et aux différents défis listés précédemment. Nous nous sommes spécifiquement intéress-
# Chapitre 1

## Introduction

La sécurité des composants logiciels et celle des composants matériels ont souvent été considérées comme deux problèmes spécifiques, abordés par des communautés distinctes. Toutefois, il apparaît de plus en plus important de combiner les aspects logiciels et matériels afin de prendre en compte les nouvelles attaques logicielles. Par exemple, des vulnérabilités matérielles comme Spectre ou Meltdown peuvent être exploitées par des attaques purement logicielles. De telles attaques peuvent être exécutées à distance et ne nécessitent pas d'accès physique à la plateforme matérielle ciblée. Il est donc nécessaire d'étudier de manière approfondie la sécurité des interfaces logicielles/matérielles, tant du point de vue des attaques que des moyens de défense. Cette étude soulève un certain nombre de défis.

Tout d'abord, les plateformes matérielles sont de plus en plus complexes et les spécifications de leur différents composants matériels ne sont pas toujours publiquement accessibles. En outre, ces spécifications sont parfois incomplètes, incorrectes ou ambiguës. Des approches ont donc été proposées par différents travaux de recherche afin de déterminer le fonctionnement et l'état de ces composants matériels avant de pouvoir les utiliser ou les analyser.

Évaluer le niveau de sécurité qu'offrent ces plateformes matérielles face aux attaques logicielles constitue également un défi important. L'étude des vulnérabilités existantes ou nouvelles qui peuvent affecter les plateformes matérielles est cruciale. Il convient également d'analyser les attaques logicielles qui peuvent exploiter de telles vulnérabilités afin d'évaluer leur facilité de mise en œuvre et leur criticité.

Face à ces menaces, il convient enfin d'étudier les mécanismes de défense que l'on peut mettre en place. En effet, les plateformes récentes embarquent de plus en plus de mécanismes de sécurité au sein de leurs composants matériels. Cela soulève un certain nombre de questions intéressantes : Quels types de mécanismes de sécurité peuvent être implémentés dans les plateformes matérielles à un coût acceptable ? Quelles sont précisément les propriétés de sécurité qui sont garanties par de tels mécanismes ? En outre, des contremesures purement logicielles peuvent être déployées dans les systèmes d'exploitation et les applications exécutés sur les plateformes matérielles afin de les protéger contre des attaques logicielles qui exploiteraient des vulnérabilités matérielles.

Le semestre thématique SILM fut dédié à la sécurité des interfaces logiciel/matériel et aux différents défis listés précédemment. Nous nous sommes spécifiquement intéress-
sés aux problématiques de sécurité qui combinent des aspects logiciels et matériels, par exemple :

— L'exploitation de vulnérabilités matérielles par des attaques purement logicielles;

— L'utilisation de protections logicielles pour lutter contre l'exploitation de vulnérabilités matérielles;

— L'utilisation de protections matérielles pour lutter contre l'exploitation de vulnérabilités logicielles;

Les travaux qui se focalisent essentiellement sur l'un des deux domaines, matériel ou logiciel, ne relèvent pas, a priori du périmètre de notre étude. Ainsi, les attaques logicielles exploitant uniquement des vulnérabilités logicielles, par exemple un logiciel malveillant exploitant une vulnérabilité de type buffer overflow, ne sont pas considérées. Il en est de même des techniques de protection purement logicielles contre ces attaques, par exemple, l'utilisation de canaris au niveau du compilateur ou le placement aléatoire des zones mémoires par l'OS (Operating System, système d'exploitation). Il en est de même des attaques ou des contre-mesures purement matérielles.

Toutefois, les techniques que peuvent mettre en œuvre les approches purement matérielles ou logicielles peuvent parfois être transposées dans un contexte hybride, combinant des aspects logiciels et matériels, tant du point de vue de l'attaque que de la défense. Des techniques de défense contre les vulnérabilités logicielles, comme le CFI (Control Flow Integrity, intégrité du flux de contrôle), sont classiquement implémentées de manière purement logicielle mais peuvent également être implémentées en partie de manière matérielle. De même, des attaques matérielles, comme l'injection de fautes ou les attaques par canaux auxiliaires, peuvent également être réalisées de manière logicielle. Ces différents cas de figure tombent naturellement dans le périmètre de notre étude.

Nous nous sommes plus particulièrement intéressés aux trois axes de recherche suivants :

1. Analyser le comportement et l'état des composants matériels en utilisant des mécanismes de trace, des techniques de fuzzing, de rétro-conception ou d'analyse des canaux auxiliaires;

2. Étudier les vulnérabilités matérielles et les attaques logicielles qui peuvent les exploiter : par exemple les attaques par canaux auxiliaires, par injection de fautes ou celles exploitant des comportements non spécifiés;

3. Détecter et prévenir les attaques logicielles en utilisant des composants matériels dédiés. Proposer des contre-mesures logicielles permettant de se protéger des vulnérabilités matérielles.

Les principaux événements organisés durant ce semestre thématique sont les suivants :

— L'école d'été SILM s'est déroulée du 8 au 12 juillet 2019 au centre Inria Rennes Bretagne Atlantique et sur le campus de Rennes de CentraleSupélec en coopération avec le GDR Sécurité Informatique du CNRS;

— Le Workshop SILM 2019, a été organisé durant la European Cyber Week du 20 au 21 novembre 2019 au centre de congrès de Rennes;

— Le séminaire SILM, est organisé depuis octobre 2019 au centre Inria Rennes Bretagne Atlantique;
sés aux problématiques de sécurité qui combinent des aspects logiciels et matériels, par exemple :

— L'exploitation de vulnérabilités matérielles par des attaques purement logicielles;

— L'utilisation de protections logicielles pour lutter contre l'exploitation de vulnérabilités matérielles;

— L'utilisation de protections matérielles pour lutter contre l'exploitation de vulnérabilités logicielles;

Les travaux qui se focalisent essentiellement sur l'un des deux domaines, matériel ou logiciel, ne relèvent pas, a priori du périmètre de notre étude. Ainsi, les attaques logicielles exploitant uniquement des vulnérabilités logicielles, par exemple un logiciel malveillant exploitant une vulnérabilité de type *buffer overflow*, ne sont pas considérées. Il en est de même des techniques de protection purement logicielles contre ces attaques, par exemple, l'utilisation de canaris au niveau du compilateur ou le placement aléatoire des zones mémoires par l'OS (*Operating System, système d'exploitation*). Il en est de même des attaques ou des contre-mesures purement matérielles.

Toutefois, les techniques que peuvent mettre en œuvre les approches purement matérielles ou logicielles peuvent parfois être transposées dans un contexte hybride, combinant des aspects logiciels et matériels, tant du point de vue de l'attaque que de la défense. Des techniques de défense contre les vulnérabilités logicielles, comme le CFI (*Control Flow Integrity, intégrité du flux de contrôle*), sont classiquement implémentées de manière purement logicielle mais peuvent également être implémentées en partie de manière matérielle. De même, des attaques matérielles, comme l'injection de fautes ou les attaques par canaux auxiliaires, peuvent également être réalisées de manière logicielle. Ces différents cas de figure tombent naturellement dans le périmètre de notre étude.

Nous nous sommes plus particulièrement intéressés aux trois axes de recherche suivants :

1. Analyser le comportement et l'état des composants matériels en utilisant des mécanismes de trace, des techniques de fuzzing, de rétro-conception ou d'analyse des canaux auxiliaires;

2. Étudier les vulnérabilités matérielles et les attaques logicielles qui peuvent les exploiter : par exemple les attaques par canaux auxiliaires, par injection de fautes ou celles exploitant des comportements non spécifiés;

3. Détecter et prévenir les attaques logicielles en utilisant des composants matériels dédiés. Proposer des contre-mesures logicielles permettant de se protéger des vulnérabilités matérielles.

Les principaux événements organisés durant ce semestre thématique sont les suivants :

— L'école d'été SILM s'est déroulée du 8 au 12 juillet 2019 au centre Inria Rennes Bretagne Atlantique et sur le campus de Rennes de CentraleSupélec en coopération avec le GDR Sécurité Informatique du CNRS;

— Le Workshop SILM 2019, a été organisé durant la European Cyber Week du 20 au 21 novembre 2019 au centre de congrès de Rennes;

— Le séminaire SILM, est organisé depuis octobre 2019 au centre Inria Rennes Bretagne Atlantique;
- Une Master Class, une présentation sur le stand du Ministère des armées et une démonstration sur le stand d'ALLISTENE ont été organisées au Forum International de la Cybercriminalité du 28 au 30 janvier 2020 à Lille;

- Le Workshop SILM 2020, co-localisé avec la conférence IEEE Security and Privacy Europe, devait avoir lieu du 16 au 18 juin 2020 à Gênes. La conférence a été reportée au 7-11 septembre 2020 en raison de la pandémie de Covid-19. Notre workshop a été reporté au 12 septembre 2020 et s'est finalement tenu en visio-conférence, compte tenu de la situation sanitaire.

Les informations concernant les différents événements organisés durant ce semestre thématique sont accessibles à partir du site web du semestre : https://silm.inria.fr/. Le site permet notamment d'accéder aux supports de présentation et aux enregistrements vidéo des présentations, lorsque les auteurs nous ont donné leur accord pour la diffusion de ces documents.

Le présent document dresse un bilan de ce semestre. Le chapitre 2 présente un état de l'art du domaine au travers des trois axes identifiés précédemment. Le chapitre 3 liste les principales perspectives scientifiques et technologiques du domaine. Enfin, le chapitre ?? liste les principaux acteurs travaillant sur cette thématique, dans les domaines académiques et industriels.
- Une Master Class, une présentation sur le stand du Ministère des armées et une démonstration sur le stand d'ALLISTENE ont été organisées au Forum International de la Cybercriminalité du 28 au 30 janvier 2020 à Lille;

- Le Workshop SILM 2020, co-localisé avec la conférence IEEE Security and Privacy Europe, devait avoir lieu du 16 au 18 juin 2020 à Gênes. La conférence a été reportée au 7-11 septembre 2020 en raison de la pandémie de Covid-19. Notre workshop a été reporté au 12 septembre 2020 et s'est finalement tenu en visio-conférence, compte tenu de la situation sanitaire.

Les informations concernant les différents événements organisés durant ce semestre thématique sont accessibles à partir du site web du semestre : https://silm.inria.fr/. Le site permet notamment d'accéder aux supports de présentation et aux enregistrements vidéo des présentations, lorsque les auteurs nous ont donné leur accord pour la diffusion de ces documents.

Le présent document dresse un bilan de ce semestre. Le chapitre 2 présente un état de l'art du domaine au travers des trois axes identifiés précédemment. Le chapitre 3 liste les principales perspectives scientifiques et technologiques du domaine. Enfin, le chapitre ?? liste les principaux acteurs travaillant sur cette thématique, dans les domaines académiques et industriels.
# Chapitre 2

## État de l'art

Nous présentons dans ce chapitre un rapide état de l'art du domaine. Nous présentons dans un premier temps, en section 2.1 les approches qui utilisent des fonctionnalités matérielles pour détecter ou se prémunir de l'exploitation de vulnérabilités logicielles. Puis nous présentons en section 2.2 les différentes attaques logicielles qui exploitent des vulnérabilités matérielles, au niveau de la microarchitecture. Enfin, nous évoquons les contre-mesures logicielles qui peuvent être déployées pour détecter ou se prémunir de ces attaques, en section 2.3.

### 2.1 Support matériel pour la sécurité logicielle

Plusieurs travaux académiques se sont intéressés à utiliser un support matériel pour détecter ou prévenir les attaques logicielles. Certains utilisent des fonctionnalités existantes des processeurs disponibles sur le marché, d'autres proposent de nouvelles fonctionnalités matérielles en validant leurs approches par simulation ou en les implémentant sur FPGA (Field-Programmable Gate Array, réseau de portes programmables in situ). Cette tendance concerne également les produits disponibles sur le marché. Les différents fabricants de microprocesseurs et d'ordinateurs sont en effet de plus en plus enclins à ajouter des fonctionnalités de sécurité matérielles au sein de leurs produits. Les intérêts par rapport aux approches purement logicielles sont multiples [1] :

- les fonctionnalités matérielles ne peuvent être modifiées, ce qui les rend plus robustes face aux attaques logicielles;

- une meilleure efficacité du temps d'exécution et de la consommation énergétique;

- une interface réduite et contrôlée, qui permet de mieux protéger les secrets.

Toutefois, ces fonctionnalités ne sont pas toujours immunisées face aux attaques logicielles, notamment celles exploitant les canaux auxiliaires, présentées en section 2.2. En outre, l'immutabilité des fonctionnalités matérielles est également une faiblesse qui limite les possibilités de mise à jour des mécanismes de sécurité, en cas de découverte de vulnérabilités matérielles. Des travaux se sont récemment intéressés à cette limitation et définissent une architecture matérielle reconfigurable, permettant de s'adapter dynamiquement à la menace [2].

Différentes approches ont été proposées dans la littérature, implémentant différents types de mécanismes de sécurité, au sein même du processeur [3] où à l'aide d'un co-processeur
# Chapitre 2

## État de l'art

Nous présentons dans ce chapitre un rapide état de l'art du domaine. Nous présentons dans un premier temps, en section 2.1 les approches qui utilisent des fonctionnalités matérielles pour détecter ou se prémunir de l'exploitation de vulnérabilités logicielles. Puis nous présentons en section 2.2 les différentes attaques logicielles qui exploitent des vulnérabilités matérielles, au niveau de la microarchitecture. Enfin, nous évoquons les contre-mesures logicielles qui peuvent être déployées pour détecter ou se prémunir de ces attaques, en section 2.3.

### 2.1 Support matériel pour la sécurité logicielle

Plusieurs travaux académiques se sont intéressés à utiliser un support matériel pour détecter ou prévenir les attaques logicielles. Certains utilisent des fonctionnalités existantes des processeurs disponibles sur le marché, d'autres proposent de nouvelles fonctionnalités matérielles en validant leurs approches par simulation ou en les implémentant sur FPGA (Field-Programmable Gate Array, réseau de portes programmables in situ). Cette tendance concerne également les produits disponibles sur le marché. Les différents fabricants de microprocesseurs et d'ordinateurs sont en effet de plus en plus enclins à ajouter des fonctionnalités de sécurité matérielles au sein de leurs produits. Les intérêts par rapport aux approches purement logicielles sont multiples [1] :

- les fonctionnalités matérielles ne peuvent être modifiées, ce qui les rend plus robustes face aux attaques logicielles;

- une meilleure efficacité du temps d'exécution et de la consommation énergétique;

- une interface réduite et contrôlée, qui permet de mieux protéger les secrets.

Toutefois, ces fonctionnalités ne sont pas toujours immunisées face aux attaques logicielles, notamment celles exploitant les canaux auxiliaires, présentées en section 2.2. En outre, l'immutabilité des fonctionnalités matérielles est également une faiblesse qui limite les possibilités de mise à jour des mécanismes de sécurité, en cas de découverte de vulnérabilités matérielles. Des travaux se sont récemment intéressés à cette limitation et définissent une architecture matérielle reconfigurable, permettant de s'adapter dynamiquement à la menace [2].

Différentes approches ont été proposées dans la littérature, implémentant différents types de mécanismes de sécurité, au sein même du processeur [3] où à l'aide d'un co-processeur
externe, isolé du processeur principal. Zhao *et al.* dressent un état de l'art de ces différents mécanismes, des propriétés qu'ils garantissent et des vulnérabilités qui les affectent, en les catégorisant suivant différents niveaux d'abstraction [1].

De nombreux travaux ont proposé des approches permettant de garantir une propriété d'isolation. Ces travaux partent du constat que les logiciels sont de plus en plus complexes et qu'il est difficile de s'assurer qu'ils ne contiennent pas de vulnérabilités exploitables par un attaquant. En cas de compromission, l'attaquant a potentiellement accès à l'ensemble des données de l'application. Pour limiter l'impact des intrusions et faciliter l'analyse des vulnérabilités, il convient d'appliquer le principe de séparation des tâches en découpant le logiciel en modules indépendants qui peuvent communiquer entre eux via une interface limitée et contrôlée.

L'isolation d'un module consiste à contrôler l'exécution des autres composants logiciels afin de s'assurer qu'ils ne pourront lire ou modifier ses données et son code. Zhang *et al.* ont réalisé un état de l'art des différentes approches permettant d'isoler matériellement des environnements d'exécution [4]. Ils identifient les différents cas d'usage légitimes de ces environnements isolés : la surveillance du système à l'exécution, l'analyse post-mortem de la mémoire, l'analyse dynamique des logiciels malveillants et l'exécution de tâches critiques pour la sécurité. Ils mentionnent également les cas d'usage illégitimes qui consistent à implanter des logiciels malveillants dans ces environnements isolés afin de les rendre difficilement détectables et persistants. Ils abordent enfin les vulnérabilités qui affectent ces mécanismes, notamment les mécanismes d'isolation.

En outre, un certain nombre de travaux se sont intéressés à l'informatique de confiance (*trusted computing*). Il s'agit de mettre en place une racine de confiance (*Root of Trust*) permettant de mesurer ou de vérifier l'intégrité des composants logiciels, de prouver cette intégrité à un tiers (attestation à distance) ou de conditionner le déchiffrement de données du système à la vérification d'intégrité. Ces approches sont notamment promues par le Trusted Computing Group, un consortium d'industriels, et ont donné lieu à la spécification et à la réalisation du TPM (*Trusted Platform Module*). Il s'agit originellement d'un composant matériel isolé réalisant des opérations cryptographiques pour implémenter les fonctions listées précédemment. Il permet notamment de vérifier et d'attester l'intégrité d'un système. Depuis la version 2 du standard, ces fonctionnalités peuvent également être réalisées par du logiciel exécuté sur le processeur principal, en s'appuyant sur des mécanismes d'isolation fournis par le processeur. Maene *et al.* ont publié un état de l'art des différentes architectures matérielles qui ont été proposées de manière plus large dans les milieux académiques et industriels pour mettre en place cette informatique de confiance et garantir notamment les propriétés d'isolation et d'attestation [5].

Nous détaillons par la suite les principaux travaux académiques et industriels visant à
utiliser un support matériel pour protéger le logiciel. Nous évoquons dans un premier
temps les travaux s'intéressant à l'informatique de confiance et s'appuyant sur le TPM
GREC (section 2.1.1). Nous abordons ensuite les mécanismes d'isolation implémentés au sein
des microprocesseurs, comme le SMM (System Management Mode) (section 2.1.2), les
mécanismes de virtualisation (section 2.1.3) ou les enclaves (section 2.1.4) ainsi que l'iso-
lation par l'utilisation d'un co-processeur dédié (section 2.1.5). Des mécanismes de sécurité
spécifiques ont également été proposés pour lutter contre l'exploitation de vulnérabilités
logicielles, notamment celles issues de la gestion de la mémoire. La section 2.1.6 liste les
approches qui implémentent ces mécanismes au niveau du jeu d'instructions et la sec-
externe, isolé du processeur principal. Zhao *et al.* dressent un état de l'art de ces différents mécanismes, des propriétés qu'ils garantissent et des vulnérabilités qui les affectent, en les catégorisant suivant différents niveaux d'abstraction [1].

De nombreux travaux ont proposé des approches permettant de garantir une propriété d'isolation. Ces travaux partent du constat que les logiciels sont de plus en plus complexes et qu'il est difficile de s'assurer qu'ils ne contiennent pas de vulnérabilités exploitables par un attaquant. En cas de compromission, l'attaquant a potentiellement accès à l'ensemble des données de l'application. Pour limiter l'impact des intrusions et faciliter l'analyse des vulnérabilités, il convient d'appliquer le principe de séparation des tâches en découpant le logiciel en modules indépendants qui peuvent communiquer entre eux via une interface limitée et contrôlée.

L'isolation d'un module consiste à contrôler l'exécution des autres composants logiciels afin de s'assurer qu'ils ne pourront lire ou modifier ses données et son code. Zhang *et al.* ont réalisé un état de l'art des différentes approches permettant d'isoler matériellement des environnements d'exécution [4]. Ils identifient les différents cas d'usage légitimes de ces environnements isolés : la surveillance du système à l'exécution, l'analyse post-mortem de la mémoire, l'analyse dynamique des logiciels malveillants et l'exécution de tâches critiques pour la sécurité. Ils mentionnent également les cas d'usage illégitimes qui consistent à implanter des logiciels malveillants dans ces environnements isolés afin de les rendre difficilement détectables et persistants. Ils abordent enfin les vulnérabilités qui affectent ces mécanismes, notamment les mécanismes d'isolation.

En outre, un certain nombre de travaux se sont intéressés à l'informatique de confiance (*trusted computing*). Il s'agit de mettre en place une racine de confiance (*Root of Trust*) permettant de mesurer ou de vérifier l'intégrité des composants logiciels, de prouver cette intégrité à un tiers (attestation à distance) ou de conditionner le déchiffrement de données du système à la vérification d'intégrité. Ces approches sont notamment promues par le Trusted Computing Group, un consortium d'industriels, et ont donné lieu à la spécification et à la réalisation du TPM (*Trusted Platform Module*). Il s'agit originellement d'un composant matériel isolé réalisant des opérations cryptographiques pour implémenter les fonctions listées précédemment. Il permet notamment de vérifier et d'attester l'intégrité d'un système. Depuis la version 2 du standard, ces fonctionnalités peuvent également être réalisées par du logiciel exécuté sur le processeur principal, en s'appuyant sur des mécanismes d'isolation fournis par le processeur. Maene *et al.* ont publié un état de l'art des différentes architectures matérielles qui ont été proposées de manière plus large dans les milieux académiques et industriels pour mettre en place cette informatique de confiance et garantir notamment les propriétés d'isolation et d'attestation [5].

Nous détaillons par la suite les principaux travaux académiques et industriels visant à
utiliser un support matériel pour protéger le logiciel. Nous évoquons dans un premier
temps les travaux s'intéressant à l'informatique de confiance et s'appuyant sur le TPM
GREC (section 2.1.1). Nous abordons ensuite les mécanismes d'isolation implémentés au sein
des microprocesseurs, comme le SMM (System Management Mode) (section 2.1.2), les
mécanismes de virtualisation (section 2.1.3) ou les enclaves (section 2.1.4) ainsi que l'iso-
lation par l'utilisation d'un co-processeur dédié (section 2.1.5). Des mécanismes de sécurité
spécifiques ont également été proposés pour lutter contre l'exploitation de vulnérabilités
logicielles, notamment celles issues de la gestion de la mémoire. La section 2.1.6 liste les
approches qui implémentent ces mécanismes au niveau du jeu d'instructions et la sec-
tion 2.1.7 présente les approches utilisant les mécanismes de traces et les compteurs de performances. Enfin, plusieurs travaux s'intéressent à définir formellement les mécanismes de sécurité matériels et les propriétés de sécurité qu'ils sont censés garantir. L'objectif est de prouver in fine que les implémentations sont conformes à la spécification et garantissent effectivement les propriétés souhaitées.

## 2.1.1 Trusted Platform Module et late launch

### 2.1.1.1 Implémentation de services de sécurité à l'aide du TPM

Le TPM [6] est aujourd'hui présent dans la plupart des ordinateurs commercialisés. Il est notamment utilisé par Microsoft [7] pour stocker des clés cryptographiques, réaliser le scellement conditionnel des clés cryptographiques utilisées pour chiffrer le disque dur (BitLocker Drive Encryption), mesurer l'intégrité des composants logiciels (hyperviseur, noyau de l'OS, périphériques, éléments de configuration, etc.) au démarrage (Measured Boot) et fournir un service d'attestation à distance (Health Attestation).

Des chercheurs d'IBM ont également démontré qu'il était possible d'implémenter des services similaires sous Linux [8]. Aujourd'hui, le support du TPM a été intégré au chargeur de démarrage GRUB qui peut ainsi mesurer l'intégrité de la configuration du chargeur de démarrage, du noyau et de ses options [9]. IBM a développé *Integrity Measurement Architecture*, une solution complémentaire qui permet de mesurer, de vérifier et d'attester l'intégrité des fichiers d'un système Linux, après le démarrage du noyau [10].

Des travaux se sont intéressés à l'implémentation du TPM de manière logicielle, ce qui permet de le virtualiser et d'offrir ses services à différentes machines virtuelles [11]. Cette approche, qui est maintenant compatible avec les dernières spécifications du TPM, est notamment utilisée par Google dans son service Shielded VMs [12] au sein de son service Google Cloud.

Les précédentes solutions reposent sur une chaîne statique de vérification de l'intégrité (Static Root of Trust for Measurement). L'initialisation de cette chaîne est réalisée par un module du boot firmware<fnref n="1" /> qui est exécuté en premier lors du démarrage et dont l'adresse est fixe. L'inconvénient de cette approche est qu'elle nécessite de mesurer tous les éléments de la chaîne de confiance depuis le démarrage de la machine (le firmware UEFI, les firmware des différents périphériques, le chargeur de démarrage, le noyau, les éléments de configuration de ces logiciels, etc.). Toute modification de l'un de ces éléments, notamment suite à une mise à jour, nécessite de mettre à jour les mesures de référence.

Pour contourner cette limitation, Intel et AMD ont proposé des mécanismes permettant d'implémenter le concept de late launch [13]. Ce concept consiste à initier la chaîne de confiance après la phase de démarrage de la machine, typiquement avant le chargement du noyau de l'OS. On parle alors de *Dynamic Root of Trust for Measurement*. Intel implémente ce mécanisme via l'extension TXT (Trusted Execution Technology) [14] qui propose de nouvelles instructions (GETSEC[SENTER]) permettant notamment d'initier dynamiquement la séquence de mesures. Cette instruction place le processeur dans un mode spécifique qui permet d'exécuter le code de mesure de manière isolée et exclusive (un seul cœur est actif). AMD propose une solution similaire intégrée à sa technologie de support

<footnote n="1">1. appelé également BIOS (Basic Input Output System) et qui implémente maintenant l'UEFI (*Unified Extensible Firmware Interface*, interface extensible et unifiée du micrologiciel)</footnote>
tion 2.1.7 présente les approches utilisant les mécanismes de traces et les compteurs de performances. Enfin, plusieurs travaux s'intéressent à définir formellement les mécanismes de sécurité matériels et les propriétés de sécurité qu'ils sont censés garantir. L'objectif est de prouver in fine que les implémentations sont conformes à la spécification et garantissent effectivement les propriétés souhaitées.

## 2.1.1 Trusted Platform Module et late launch

### 2.1.1.1 Implémentation de services de sécurité à l'aide du TPM

Le TPM [6] est aujourd'hui présent dans la plupart des ordinateurs commercialisés. Il est notamment utilisé par Microsoft [7] pour stocker des clés cryptographiques, réaliser le scellement conditionnel des clés cryptographiques utilisées pour chiffrer le disque dur (BitLocker Drive Encryption), mesurer l'intégrité des composants logiciels (hyperviseur, noyau de l'OS, périphériques, éléments de configuration, etc.) au démarrage (Measured Boot) et fournir un service d'attestation à distance (Health Attestation).

Des chercheurs d'IBM ont également démontré qu'il était possible d'implémenter des services similaires sous Linux [8]. Aujourd'hui, le support du TPM a été intégré au chargeur de démarrage GRUB qui peut ainsi mesurer l'intégrité de la configuration du chargeur de démarrage, du noyau et de ses options [9]. IBM a développé *Integrity Measurement Architecture*, une solution complémentaire qui permet de mesurer, de vérifier et d'attester l'intégrité des fichiers d'un système Linux, après le démarrage du noyau [10].

Des travaux se sont intéressés à l'implémentation du TPM de manière logicielle, ce qui permet de le virtualiser et d'offrir ses services à différentes machines virtuelles [11]. Cette approche, qui est maintenant compatible avec les dernières spécifications du TPM, est notamment utilisée par Google dans son service Shielded VMs [12] au sein de son service Google Cloud.

Les précédentes solutions reposent sur une chaîne statique de vérification de l'intégrité (Static Root of Trust for Measurement). L'initialisation de cette chaîne est réalisée par un module du boot firmware<fnref n="1" /> qui est exécuté en premier lors du démarrage et dont l'adresse est fixe. L'inconvénient de cette approche est qu'elle nécessite de mesurer tous les éléments de la chaîne de confiance depuis le démarrage de la machine (le firmware UEFI, les firmware des différents périphériques, le chargeur de démarrage, le noyau, les éléments de configuration de ces logiciels, etc.). Toute modification de l'un de ces éléments, notamment suite à une mise à jour, nécessite de mettre à jour les mesures de référence.

Pour contourner cette limitation, Intel et AMD ont proposé des mécanismes permettant d'implémenter le concept de late launch [13]. Ce concept consiste à initier la chaîne de confiance après la phase de démarrage de la machine, typiquement avant le chargement du noyau de l'OS. On parle alors de *Dynamic Root of Trust for Measurement*. Intel implémente ce mécanisme via l'extension TXT (Trusted Execution Technology) [14] qui propose de nouvelles instructions (GETSEC[SENTER]) permettant notamment d'initier dynamiquement la séquence de mesures. Cette instruction place le processeur dans un mode spécifique qui permet d'exécuter le code de mesure de manière isolée et exclusive (un seul cœur est actif). AMD propose une solution similaire intégrée à sa technologie de support

<footnote n="1">1. appelé également BIOS (Basic Input Output System) et qui implémente maintenant l'UEFI (*Unified Extensible Firmware Interface*, interface extensible et unifiée du micrologiciel)</footnote>
à la virtualisation (AMD-V).

Intel fournit un code binaire spécifique permettant de mesurer la partie SMM du firmware (SINIT). L'utilisateur peut fournir un code réalisant la mesure du logiciel qui doit être exécuté par la suite (typiquement, le noyau de l'OS). TXT est supporté, entre autres, par Microsoft. Sous Linux, le projet tBoot [15] permet d'initier une séquence de mesures avant le démarrage du noyau. Cet outil est notamment utilisé par OpenDTeX Secure Boot [16], un projet développé par la société AMOSSYS et financé par la DGA, qui implémente des fonctionnalités de scellement conditionnel et de bannière de vérification d'intégrité sous Linux, en utilisant le TPM et les extensions Intel TXT.

Des travaux ont également proposé d'utiliser le late launch pour implémenter Flicker [17], un service d'enclave. Le mécanisme est alors quelque peu détourné de son but initial. Au lieu de démarrer le noyau d'un OS ou d'un hyperviseur, les chercheurs tirent profit de l'isolation fournie par les mécanismes de late launch pour protéger du code et des données sensibles vis-à-vis de l'application et de l'OS. Les mécanismes d'enclaves comme Intel SGX (Software Guard Extensions) sont aujourd'hui destinés à cet usage. Ces travaux ont été repris récemment pour implémenter un service original de prévention des ransomware disposant de privilèges administrateur. Les fichiers sont directement accessibles en lecture seule. Toute modification doit être effectuée par un composant de confiance. Ce composant implémente des modifications non-destructives qui permettent de restaurer l'état précédent d'un fichier. Les auteurs utilisent Flicker pour isoler le composant en charge de la modification des fichiers [18].

### 2.1.1.2 Attaques contre le TPM et Intel TXT

Intel TXT n'est pas exempt de vulnérabilités [19-24] en raison notamment de la complexité de ce mécanisme. Ces vulnérabilité sont notamment liées à l'interaction de ce mécanisme avec d'autres fonctionnalités des processeurs Intel comme le SMM ou à des défauts dans l'implémentation du code SINIT. D'autres vulnérabilités [25] sont liées à l'interaction avec le mécanisme de gestion de la mise en veille.

Les implémentations du TPM ont également fait l'objet de vulnérabilités. Récemment, des chercheurs ont démontré que certaines implémentations, dont l'implémentation logicielle de Intel (fPTM) mais également des implémentations physiques, qui sont censées être plus robustes que les implémentations logicielles et qui font l'objet d'évaluations selon les Critères Communs, sont vulnérables à des attaques par canaux auxiliaires [26]. Ces vulnérabilités peuvent être exploitées à distance et permettent de réaliser une atteinte à la confidentialité des clés privées stockées dans le TPM.

## 2.1.2 System Management Mode

Le SMM est le mode d'exécution le plus privilégié sur l'architecture x86, introduit par Intel dans le processeur Intel 386SL. Il permet d'exécuter des services privilégiés du logiciel de démarrage et d'initialisation de la plateforme (boot firmware), y compris après la phase de démarrage, lors de l'exécution de l'OS. Ce mode permet d'isoler ces services qui peuvent accéder à une partie dédiée de la mémoire (SMRAM (System Management RAM)), qui est uniquement accessible en SMM. Le processeur bascule dans ce mode lors d'une interruption matérielle spécifique (SMI (System Management Interrupt)) qui peut être déclenchée par le logiciel.
à la virtualisation (AMD-V).

Intel fournit un code binaire spécifique permettant de mesurer la partie SMM du firmware (SINIT). L'utilisateur peut fournir un code réalisant la mesure du logiciel qui doit être exécuté par la suite (typiquement, le noyau de l'OS). TXT est supporté, entre autres, par Microsoft. Sous Linux, le projet tBoot [15] permet d'initier une séquence de mesures avant le démarrage du noyau. Cet outil est notamment utilisé par OpenDTeX Secure Boot [16], un projet développé par la société AMOSSYS et financé par la DGA, qui implémente des fonctionnalités de scellement conditionnel et de bannière de vérification d'intégrité sous Linux, en utilisant le TPM et les extensions Intel TXT.

Des travaux ont également proposé d'utiliser le late launch pour implémenter Flicker [17], un service d'enclave. Le mécanisme est alors quelque peu détourné de son but initial. Au lieu de démarrer le noyau d'un OS ou d'un hyperviseur, les chercheurs tirent profit de l'isolation fournie par les mécanismes de late launch pour protéger du code et des données sensibles vis-à-vis de l'application et de l'OS. Les mécanismes d'enclaves comme Intel SGX (Software Guard Extensions) sont aujourd'hui destinés à cet usage. Ces travaux ont été repris récemment pour implémenter un service original de prévention des ransomware disposant de privilèges administrateur. Les fichiers sont directement accessibles en lecture seule. Toute modification doit être effectuée par un composant de confiance. Ce composant implémente des modifications non-destructives qui permettent de restaurer l'état précédent d'un fichier. Les auteurs utilisent Flicker pour isoler le composant en charge de la modification des fichiers [18].

### 2.1.1.2 Attaques contre le TPM et Intel TXT

Intel TXT n'est pas exempt de vulnérabilités [19-24] en raison notamment de la complexité de ce mécanisme. Ces vulnérabilité sont notamment liées à l'interaction de ce mécanisme avec d'autres fonctionnalités des processeurs Intel comme le SMM ou à des défauts dans l'implémentation du code SINIT. D'autres vulnérabilités [25] sont liées à l'interaction avec le mécanisme de gestion de la mise en veille.

Les implémentations du TPM ont également fait l'objet de vulnérabilités. Récemment, des chercheurs ont démontré que certaines implémentations, dont l'implémentation logicielle de Intel (fPTM) mais également des implémentations physiques, qui sont censées être plus robustes que les implémentations logicielles et qui font l'objet d'évaluations selon les Critères Communs, sont vulnérables à des attaques par canaux auxiliaires [26]. Ces vulnérabilités peuvent être exploitées à distance et permettent de réaliser une atteinte à la confidentialité des clés privées stockées dans le TPM.

## 2.1.2 System Management Mode

Le SMM est le mode d'exécution le plus privilégié sur l'architecture x86, introduit par Intel dans le processeur Intel 386SL. Il permet d'exécuter des services privilégiés du logiciel de démarrage et d'initialisation de la plateforme (boot firmware), y compris après la phase de démarrage, lors de l'exécution de l'OS. Ce mode permet d'isoler ces services qui peuvent accéder à une partie dédiée de la mémoire (SMRAM (System Management RAM)), qui est uniquement accessible en SMM. Le processeur bascule dans ce mode lors d'une interruption matérielle spécifique (SMI (System Management Interrupt)) qui peut être déclenchée par le logiciel.
Ce mode n'a initialement pas été conçu pour la sécurité mais pour permettre à l'OS de dé-
léguer au firmware certaines tâches très dépendantes de la configuration matérielle, comme
la gestion de l'énergie. Le firmware est en effet développé en partie par le constructeur de
la carte mère. Toutefois, ce mode a, au fil du temps, acquis une importance fondamentale
dans la sécurité de la plateforme matérielle. Il permet en effet d'exécuter des services
critiques comme la mise à jour du code du firmware ou la configuration du TPM. Seul
un service exécuté en SMM peut permettre l'écriture dans la mémoire flash contenant le
code du firmware.

Bien que ce mode soit destiné à l'exécution de services du firmware, plusieurs travaux de recherche ont proposé de tirer profit de l'isolation qu'il fournit pour isoler des fonctions de sécurité. Ainsi Reina et al. utilisent ce mode pour implémenter une solution d'analyse post-mortem de la mémoire [27]. Sun et al. proposent un système permettant à l'utilisateur de basculer entre différents systèmes exécutés sur la même machine, par exemple pour traiter des données de sensibilités différentes [28]. Ce mode a également été utilisé pour isoler des services de surveillance à l'exécution des autres composants logiciels de la plateforme (OS, application) [29, 30], des périphériques [31] ou pour réaliser des analyses dynamiques de logiciels malveillants [32].

SMM est une solution intéressante pour protéger des fonctions de sécurité. Toutefois, ce
mode présente plusieurs limitations. Il est relativement complexe et n'a pas été conçu
pour des besoins de sécurité. Il a d'ailleurs fait l'objet de nombreuses vulnérabilités qui
ont été corrigées au fil du temps. En outre, il implique un changement de contexte qui a un
impact non négligeable sur les performances. L'exécution des services en SMM préempte
l'exécution de l'OS et de l'hyperviseur. Par conséquent, les services exécutés en mode SMM
doivent avoir une durée limitée pour ne pas perturber le fonctionnement de l'OS et des
applications. En outre, le code SMM ne peut s'exécuter que lors d'une SMI. Un attaquant
peut donc empêcher l'exécution de ce code en bloquant les SMI. Il paraît aujourd'hui plus
pertinent d'utiliser d'autres mécanismes d'isolation spécifiquement conçus pour l'isolation
de fonctions de sécurité, notamment les fonctions de virtualisation ou les TEE (Trusted
Execution Environment, environnement d'exécution de confiance).

2.1.3 Sécurité basée sur la virtualisation

Les techniques de virtualisation permettent de partager les ressources matérielles (proces-
seur, mémoire, périphériques) entre plusieurs VM (Virtual Machine, machine virtuelle).
Un hyperviseur (ou Virtual Machine Monitor) est un composant logiciel permettant de
créer et d'exécuter plusieurs machines virtuelles (les systèmes invités) sur une plateforme
matérielle (le système hôte). L'hyperviseur s'assure entre autre du partage des ressources
matérielles du système hôte entre les différents systèmes invités. Il présente à chaque sys-
tème invité une abstraction des ressources matérielles de l'hôte. Ces ressources virtuelles
peuvent à leur tour être partagées entre différentes applications par un OS exécuté dans
chaque système invité. On distingue classiquement deux types d'hyperviseurs :

— les hyperviseurs de type 1 (bare-metal) tels que Microsoft Hyper-V<fnref n="2" /> ou VMware vSphere<fnref n="3" />, etc. s'exécutent directement sur le matériel, le système hôte se réduit dans ce cas à l'hyperviseur et ne contient pas d'OS;

<footnote n="2">2. https://docs.microsoft.com/fr-fr/virtualization/hyper-v-on-windows/</footnote>

<footnote n="3">3. https://www.vmware.com/fr/products/vsphere-hypervisor.html</footnote>
Ce mode n'a initialement pas été conçu pour la sécurité mais pour permettre à l'OS de dé-
léguer au firmware certaines tâches très dépendantes de la configuration matérielle, comme
la gestion de l'énergie. Le firmware est en effet développé en partie par le constructeur de
la carte mère. Toutefois, ce mode a, au fil du temps, acquis une importance fondamentale
dans la sécurité de la plateforme matérielle. Il permet en effet d'exécuter des services
critiques comme la mise à jour du code du firmware ou la configuration du TPM. Seul
un service exécuté en SMM peut permettre l'écriture dans la mémoire flash contenant le
code du firmware.

Bien que ce mode soit destiné à l'exécution de services du firmware, plusieurs travaux de recherche ont proposé de tirer profit de l'isolation qu'il fournit pour isoler des fonctions de sécurité. Ainsi Reina et al. utilisent ce mode pour implémenter une solution d'analyse post-mortem de la mémoire [27]. Sun et al. proposent un système permettant à l'utilisateur de basculer entre différents systèmes exécutés sur la même machine, par exemple pour traiter des données de sensibilités différentes [28]. Ce mode a également été utilisé pour isoler des services de surveillance à l'exécution des autres composants logiciels de la plateforme (OS, application) [29, 30], des périphériques [31] ou pour réaliser des analyses dynamiques de logiciels malveillants [32].

SMM est une solution intéressante pour protéger des fonctions de sécurité. Toutefois, ce
mode présente plusieurs limitations. Il est relativement complexe et n'a pas été conçu
pour des besoins de sécurité. Il a d'ailleurs fait l'objet de nombreuses vulnérabilités qui
ont été corrigées au fil du temps. En outre, il implique un changement de contexte qui a un
impact non négligeable sur les performances. L'exécution des services en SMM préempte
l'exécution de l'OS et de l'hyperviseur. Par conséquent, les services exécutés en mode SMM
doivent avoir une durée limitée pour ne pas perturber le fonctionnement de l'OS et des
applications. En outre, le code SMM ne peut s'exécuter que lors d'une SMI. Un attaquant
peut donc empêcher l'exécution de ce code en bloquant les SMI. Il paraît aujourd'hui plus
pertinent d'utiliser d'autres mécanismes d'isolation spécifiquement conçus pour l'isolation
de fonctions de sécurité, notamment les fonctions de virtualisation ou les TEE (Trusted
Execution Environment, environnement d'exécution de confiance).

2.1.3 Sécurité basée sur la virtualisation

Les techniques de virtualisation permettent de partager les ressources matérielles (proces-
seur, mémoire, périphériques) entre plusieurs VM (Virtual Machine, machine virtuelle).
Un hyperviseur (ou Virtual Machine Monitor) est un composant logiciel permettant de
créer et d'exécuter plusieurs machines virtuelles (les systèmes invités) sur une plateforme
matérielle (le système hôte). L'hyperviseur s'assure entre autre du partage des ressources
matérielles du système hôte entre les différents systèmes invités. Il présente à chaque sys-
tème invité une abstraction des ressources matérielles de l'hôte. Ces ressources virtuelles
peuvent à leur tour être partagées entre différentes applications par un OS exécuté dans
chaque système invité. On distingue classiquement deux types d'hyperviseurs :

— les hyperviseurs de type 1 (bare-metal) tels que Microsoft Hyper-V<fnref n="2" /> ou VMware vSphere<fnref n="3" />, etc. s'exécutent directement sur le matériel, le système hôte se réduit dans ce cas à l'hyperviseur et ne contient pas d'OS;

<footnote n="2">2. https://docs.microsoft.com/fr-fr/virtualization/hyper-v-on-windows/</footnote>

<footnote n="3">3. https://www.vmware.com/fr/products/vsphere-hypervisor.html</footnote>
— les hyperviseurs de type 2 tels que VirtualBox 4, QEMU 5 ou VMware Workstation Player 6 sont des applications qui s'exécutent au dessus de l'OS du système hôte.

Dans un système virtualisé, l'abstraction du matériel présentée par l'hyperviseur aux systèmes invités est très similaire à l'interface avec le matériel physique. L'OS des systèmes invités peut donc s'exécuter sans nécessiter de modification de son code. Une alternative et/ou une approche complémentaire, appelée para-virtualisation, consiste à modifier le code des OS invités pour qu'ils réalisent directement des appels à l'hyperviseur (ou hyper-call) plutôt que de tenter d'accéder aux ressources matérielles virtualisées. Cela simplifie la tâche de l'hyperviseur et limite la dégradation des performances liées à la virtualisation. Toutefois, cela nécessite de modifier en partie le code des OS invités. Cette solution, utilisée notamment par Xen, est aujourd'hui utilisée en partie par la plupart des hyperviseurs.

On remarque que la distinction entre hyperviseurs de type 1 et 2 tend à s'estomper. En effet, les hyperviseurs de type 2 comme QEMU s'appuient généralement sur des fonctionnalités qui ont été déportées dans le code du noyau de l'OS du système hôte (par exemple, QEMU utilise KVM 7, un module du noyau Linux implémentant une partie de l'hyperviseur). Toutefois, une distinction importante qui perdure est la quantité de code (et donc la surface d'attaque) du système hôte. Dans le cas d'un hyperviseur de type 2, le système hôte est important puisqu'il contient un OS complet, l'hyperviseur et potentiellement différentes applications utilisateurs alors que dans le cas d'un hyperviseur de type 1, il se réduit au seul hyperviseur.

Les hyperviseurs de type 1 sont plutôt utilisés dans les serveurs hébergeant les environnements de type *cloud* et les hyperviseurs de type 2 sont plutôt utilisés sur des ordinateurs personnels, permettant à l'utilisateur d'exécuter différents environnements virtuels en plus des applications exécutées nativement sur le système hôte. Mais ces domaines d'utilisation ne sont pas exclusifs. Par exemple, Microsoft utilise Hyper-V (son hyperviseur de type 1) pour virtualiser des fonctions de sécurité sur les ordinateurs personnels [33].

Pour pouvoir partager les ressources matérielles, les hyperviseurs doivent pouvoir intercepter et contrôler les accès au matériel réalisés par les OS invités. Afin de faciliter ce contrôle et limiter l'impact sur les performances, les fabricants de processeurs ont proposé des extensions matérielles (Intel VT, AMD-V, etc.) que l'hyperviseur peut utiliser pour contrôler les VM. Cela se traduit par l'ajout d'un niveau de privilège supplémentaire, dans lequel s'exécute le système hôte (et donc l'hyperviseur). Ce mode permet à l'hyperviseur d'exécuter des VM dans un mode moins privilégié et d'intercepter les accès au matériel réalisés par les VM. Le processeur appelle le code de l'hyperviseur lorsqu'un tel accès est réalisé par l'OS d'un système invité. Il peut ainsi partager les ressources matérielles entre les VM.

L'hyperviseur assure également une propriété d'isolation entre les VM : un programme exécuté dans une VM (y compris un OS invité) ne peut interférer avec une autre VM (en particulier il ne peut pas lire ou modifier les zones mémoires allouées à d'autres VM). Cela fait de l'hyperviseur un des composants logiciels les plus privilégiés au sein d'une

<footnote n="4">4. https://www.virtualbox.org/</footnote>

<footnote n="5">5. https://www.qemu.org/</footnote>

<footnote n="6">6. https://www.vmware.com/fr/products/workstation-player/workstation-player-evaluation.html</footnote>

<footnote n="7">7. https://www.linux-kvm.org/page/Main_Page</footnote>
— les hyperviseurs de type 2 tels que VirtualBox 4, QEMU 5 ou VMware Workstation Player 6 sont des applications qui s'exécutent au dessus de l'OS du système hôte.

Dans un système virtualisé, l'abstraction du matériel présentée par l'hyperviseur aux systèmes invités est très similaire à l'interface avec le matériel physique. L'OS des systèmes invités peut donc s'exécuter sans nécessiter de modification de son code. Une alternative et/ou une approche complémentaire, appelée para-virtualisation, consiste à modifier le code des OS invités pour qu'ils réalisent directement des appels à l'hyperviseur (ou hyper-call) plutôt que de tenter d'accéder aux ressources matérielles virtualisées. Cela simplifie la tâche de l'hyperviseur et limite la dégradation des performances liées à la virtualisation. Toutefois, cela nécessite de modifier en partie le code des OS invités. Cette solution, utilisée notamment par Xen, est aujourd'hui utilisée en partie par la plupart des hyperviseurs.

On remarque que la distinction entre hyperviseurs de type 1 et 2 tend à s'estomper. En effet, les hyperviseurs de type 2 comme QEMU s'appuient généralement sur des fonctionnalités qui ont été déportées dans le code du noyau de l'OS du système hôte (par exemple, QEMU utilise KVM 7, un module du noyau Linux implémentant une partie de l'hyperviseur). Toutefois, une distinction importante qui perdure est la quantité de code (et donc la surface d'attaque) du système hôte. Dans le cas d'un hyperviseur de type 2, le système hôte est important puisqu'il contient un OS complet, l'hyperviseur et potentiellement différentes applications utilisateurs alors que dans le cas d'un hyperviseur de type 1, il se réduit au seul hyperviseur.

Les hyperviseurs de type 1 sont plutôt utilisés dans les serveurs hébergeant les environnements de type *cloud* et les hyperviseurs de type 2 sont plutôt utilisés sur des ordinateurs personnels, permettant à l'utilisateur d'exécuter différents environnements virtuels en plus des applications exécutées nativement sur le système hôte. Mais ces domaines d'utilisation ne sont pas exclusifs. Par exemple, Microsoft utilise Hyper-V (son hyperviseur de type 1) pour virtualiser des fonctions de sécurité sur les ordinateurs personnels [33].

Pour pouvoir partager les ressources matérielles, les hyperviseurs doivent pouvoir intercepter et contrôler les accès au matériel réalisés par les OS invités. Afin de faciliter ce contrôle et limiter l'impact sur les performances, les fabricants de processeurs ont proposé des extensions matérielles (Intel VT, AMD-V, etc.) que l'hyperviseur peut utiliser pour contrôler les VM. Cela se traduit par l'ajout d'un niveau de privilège supplémentaire, dans lequel s'exécute le système hôte (et donc l'hyperviseur). Ce mode permet à l'hyperviseur d'exécuter des VM dans un mode moins privilégié et d'intercepter les accès au matériel réalisés par les VM. Le processeur appelle le code de l'hyperviseur lorsqu'un tel accès est réalisé par l'OS d'un système invité. Il peut ainsi partager les ressources matérielles entre les VM.

L'hyperviseur assure également une propriété d'isolation entre les VM : un programme exécuté dans une VM (y compris un OS invité) ne peut interférer avec une autre VM (en particulier il ne peut pas lire ou modifier les zones mémoires allouées à d'autres VM). Cela fait de l'hyperviseur un des composants logiciels les plus privilégiés au sein d'une

<footnote n="4">4. https://www.virtualbox.org/</footnote>

<footnote n="5">5. https://www.qemu.org/</footnote>

<footnote n="6">6. https://www.vmware.com/fr/products/workstation-player/workstation-player-evaluation.html</footnote>

<footnote n="7">7. https://www.linux-kvm.org/page/Main_Page</footnote>
plateforme. Il s'agit donc d'un composant critique pour la sécurité [34]. Une vulnérabilité dans l'hyperviseur permet potentiellement à un attaquant de briser l'isolation et d'accéder aux ressources de toutes les VM.

On remarque par ailleurs que les hyperviseurs sont régulièrement utilisés spécifiquement pour assurer des tâches en lien avec la sécurité. Par exemple, l'analyse dynamique des malware se fait dans des sandbox, des environnements contrôlés et isolés. La plupart de ces environnements reposent sur l'utilisation d'hyperviseurs (par exemple, Cuckoo <fnref n="8" /> supporte la plupart des hyperviseurs du marché, DRAKVUF [35] utilise Xen, etc.). L'utilisation d'un hyperviseur permet dans ce cas d'isoler le système infecté, d'analyser et de contrôler les comportements malveillants du malware analysé (notamment sa propagation) mais également de restaurer facilement et rapidement le système infecté dans un état sain, en tirant parti des fonctions de capture d'instantanés (snapshoting) fournies par la plupart des hyperviseurs.

Nous évoquons par la suite plus en détail les approches qui visent à renforcer la sécurité des systèmes virtualisés en chiffrant la mémoire des VM (section 2.1.3.1) et en réduisant la surface d'attaque de l'hyperviseur (section 2.1.3.2). Nous présentons ensuite en section 2.1.3.3 les travaux de recherche qui utilisent la virtualisation pour isoler un moniteur de sécurité afin de surveiller et protéger les systèmes invités.

### 2.1.3.1 Chiffrement de la mémoire des machines virtuelles

Dans un cas d'usage de type *cloud*, les VM sont déployées sur une infrastructure fournie par un tiers, qui n'est pas nécessairement de confiance. Afin de protéger la mémoire des machines virtuelles face à un hyperviseur potentiellement malveillant ou corrompu, AMD a proposé un mécanisme permettant de chiffrer la mémoire des VM [36]. L'approche s'appuie sur le co-processeur de sécurité intégré aux processeur d'AMD, qui réalise les opérations de chiffrement/déchiffrement à la volée. Il est possible de chiffrer l'intégralité de la mémoire avec une clé unique (ce qui simplifie le support logiciel) ou en associant une clé différente à chaque VM et à l'hyperviseur. Intel dispose d'une technologie similaire mais plus souple [37]. Il est en effet possible d'associer des clés à des pages et d'utiliser différentes clés au sein d'une même VM, par exemple pour isoler différentes applications ou différentes fonctionnalités au sein d'une même application.

Des travaux récents [38] ont montré que les opérations d'entrée/sortie réalisant des DMA (Direct Memory Access, accès direct à la mémoire) ne pouvaient être chiffrées avec une clé de VM, dans la solution d'AMD. Si l'hyperviseur est corrompu ou malveillant, cela signifie que les données échangées avec les périphériques peuvent être lues et modifiées par l'hyperviseur. Pire, cela permet à l'hyperviseur de créer un oracle de chiffrement et de déchiffrement de la mémoire d'une VM en manipulant les données recopiées entre la zone mémoire de la VM et les pages en clair. L'implémentation d'Intel ne semble pas souffrir de cette limitation.

### 2.1.3.2 Réduction de la surface d'attaque de l'hyperviseur

L'hyperviseur a un rôle clé dans la mise en place de l'isolation entre les différentes VM. Il fait de fait partie de la TCB (Trusted Computing Base, base de confiance). Idéalement, sa surface d'attaque devrait être réduite au minimum et un effort important devrait être

<footnote n="8">8. https://cuckoosandbox.org/</footnote>
plateforme. Il s'agit donc d'un composant critique pour la sécurité [34]. Une vulnérabilité dans l'hyperviseur permet potentiellement à un attaquant de briser l'isolation et d'accéder aux ressources de toutes les VM.

On remarque par ailleurs que les hyperviseurs sont régulièrement utilisés spécifiquement pour assurer des tâches en lien avec la sécurité. Par exemple, l'analyse dynamique des malware se fait dans des sandbox, des environnements contrôlés et isolés. La plupart de ces environnements reposent sur l'utilisation d'hyperviseurs (par exemple, Cuckoo <fnref n="8" /> supporte la plupart des hyperviseurs du marché, DRAKVUF [35] utilise Xen, etc.). L'utilisation d'un hyperviseur permet dans ce cas d'isoler le système infecté, d'analyser et de contrôler les comportements malveillants du malware analysé (notamment sa propagation) mais également de restaurer facilement et rapidement le système infecté dans un état sain, en tirant parti des fonctions de capture d'instantanés (snapshoting) fournies par la plupart des hyperviseurs.

Nous évoquons par la suite plus en détail les approches qui visent à renforcer la sécurité des systèmes virtualisés en chiffrant la mémoire des VM (section 2.1.3.1) et en réduisant la surface d'attaque de l'hyperviseur (section 2.1.3.2). Nous présentons ensuite en section 2.1.3.3 les travaux de recherche qui utilisent la virtualisation pour isoler un moniteur de sécurité afin de surveiller et protéger les systèmes invités.

### 2.1.3.1 Chiffrement de la mémoire des machines virtuelles

Dans un cas d'usage de type *cloud*, les VM sont déployées sur une infrastructure fournie par un tiers, qui n'est pas nécessairement de confiance. Afin de protéger la mémoire des machines virtuelles face à un hyperviseur potentiellement malveillant ou corrompu, AMD a proposé un mécanisme permettant de chiffrer la mémoire des VM [36]. L'approche s'appuie sur le co-processeur de sécurité intégré aux processeur d'AMD, qui réalise les opérations de chiffrement/déchiffrement à la volée. Il est possible de chiffrer l'intégralité de la mémoire avec une clé unique (ce qui simplifie le support logiciel) ou en associant une clé différente à chaque VM et à l'hyperviseur. Intel dispose d'une technologie similaire mais plus souple [37]. Il est en effet possible d'associer des clés à des pages et d'utiliser différentes clés au sein d'une même VM, par exemple pour isoler différentes applications ou différentes fonctionnalités au sein d'une même application.

Des travaux récents [38] ont montré que les opérations d'entrée/sortie réalisant des DMA (Direct Memory Access, accès direct à la mémoire) ne pouvaient être chiffrées avec une clé de VM, dans la solution d'AMD. Si l'hyperviseur est corrompu ou malveillant, cela signifie que les données échangées avec les périphériques peuvent être lues et modifiées par l'hyperviseur. Pire, cela permet à l'hyperviseur de créer un oracle de chiffrement et de déchiffrement de la mémoire d'une VM en manipulant les données recopiées entre la zone mémoire de la VM et les pages en clair. L'implémentation d'Intel ne semble pas souffrir de cette limitation.

### 2.1.3.2 Réduction de la surface d'attaque de l'hyperviseur

L'hyperviseur a un rôle clé dans la mise en place de l'isolation entre les différentes VM. Il fait de fait partie de la TCB (Trusted Computing Base, base de confiance). Idéalement, sa surface d'attaque devrait être réduite au minimum et un effort important devrait être

<footnote n="8">8. https://cuckoosandbox.org/</footnote>
déployé pour minimiser les vulnérabilités. Cependant, même les hyperviseurs de type 1, qui offrent une surface d'attaque plus réduite que ceux de type 2, peuvent présenter des vulnérabilités exploitables par un attaquant <fnref n="9" />. Ces vulnérabilités viennent en partie du fait que les hyperviseurs sont développés dans des langages bas niveau offrant peu de garanties de sécurité, comme le C ou C++ et qu'ils comprennent une quantité de code importante, réalisant des fonctionnalités complexes. Par exemple, le code source d'Hyper-V comporte environ 100 000 lignes de code écrit en C [39].

Des travaux de recherche se sont intéressés à réduire cette surface d'attaque. DeHypen [40] propose ainsi de transférer une part importante du code d'un hyperviseur intégré au noyau du système hôte (comme KVM) dans l'espace utilisateur. Ainsi, l'approche permet de réduire les privilèges pour une part importante des fonctionnalités, ce qui limite l'impact en cas de compromission. De manière similaire, CloudVisor-D [41] utilise la virtualisation imbriquée pour protéger les VM face à l'hyperviseur hôte. Afin de réduire le coût de la virtualisation imbriquée, il décompose l'hyperviseur imbriqué en plusieurs VM de filtrage qui s'exécutent en parallèle des VM utilisateurs. L'hyperviseur imbriqué est alors fortement réduit et se concentre sur la protection des VM de filtrage.

### 2.1.3.3 Surveillance et protection des machines virtuelles

Plusieurs travaux de la littérature utilisent la virtualisation pour protéger les systèmes invités face aux attaques. Ainsi TrustVisor [42] propose un hyperviseur minimal dans le but d'implémenter des enclaves. Ces enclaves permettant d'isoler les fonctions sensibles d'une application. L'approche est similaire à celle suivie par Flicker [17] mais les auteurs utilisent ici la virtualisation au lieu de Intel TXT pour isoler les enclaves, ce qui permet de limiter le surcoût à l'exécution lors des changements de contexte. Gateway [43] vise à protéger le code du noyau de logiciel malveillant exploitant des vulnérabilités dans les pilotes de périphériques. Pour cela, il isole les pilotes dans un espace mémoire dédié et il contrôle les interactions entre ces pilotes et le reste du noyau, via une interface spécifique. Les auteurs utilisent la virtualisation pour s'assurer que les pilotes ne puissent interagir que via cette interface.

La surveillance du comportement des systèmes invités via des techniques de VMI (Virtual Machine Introspection, introspection de machines virtuelles) à fait l'objet de nombreux travaux [44]. Ces techniques permettent par exemple d'analyser dynamiquement des logiciels malveillants [35, 45] ou de vérifier l'intégrité du système surveillé [46].

En plaçant le moniteur dans l'hyperviseur ou dans une VM isolée du système surveillé, on le protège des attaques visant le système surveillé. Toutefois, cette isolation crée un fossé sémantique [47] : le moniteur ne dispose pas de toutes les informations de contexte qui lui permettent d'inférer précisément l'état du système surveillé. Par exemple, il ne dispose pas de la valeur du registre pointant sur la table des pages. En outre, il doit inférer les différentes structures de données du noyau invité pour retrouver, par exemple, la liste des processus ou des fichiers ouverts.

Différentes approches ont été proposées pour réduire ce fossé sémantique [44, 47]. Par exemple SYRINGE [48] injecte des appels de fonctions dans le système surveillé pour obtenir les informations souhaitées. L'outil contrôle l'exécution de ces appels de fonctions

<footnote n="9">⁹. Par exemple, Hyper-V fait l'objet de plusieurs CVE : https://www.cybersecurity-help.cz/vdb/SB2019111214</footnote>
déployé pour minimiser les vulnérabilités. Cependant, même les hyperviseurs de type 1, qui offrent une surface d'attaque plus réduite que ceux de type 2, peuvent présenter des vulnérabilités exploitables par un attaquant <fnref n="9" />. Ces vulnérabilités viennent en partie du fait que les hyperviseurs sont développés dans des langages bas niveau offrant peu de garanties de sécurité, comme le C ou C++ et qu'ils comprennent une quantité de code importante, réalisant des fonctionnalités complexes. Par exemple, le code source d'Hyper-V comporte environ 100 000 lignes de code écrit en C [39].

Des travaux de recherche se sont intéressés à réduire cette surface d'attaque. DeHypen [40] propose ainsi de transférer une part importante du code d'un hyperviseur intégré au noyau du système hôte (comme KVM) dans l'espace utilisateur. Ainsi, l'approche permet de réduire les privilèges pour une part importante des fonctionnalités, ce qui limite l'impact en cas de compromission. De manière similaire, CloudVisor-D [41] utilise la virtualisation imbriquée pour protéger les VM face à l'hyperviseur hôte. Afin de réduire le coût de la virtualisation imbriquée, il décompose l'hyperviseur imbriqué en plusieurs VM de filtrage qui s'exécutent en parallèle des VM utilisateurs. L'hyperviseur imbriqué est alors fortement réduit et se concentre sur la protection des VM de filtrage.

### 2.1.3.3 Surveillance et protection des machines virtuelles

Plusieurs travaux de la littérature utilisent la virtualisation pour protéger les systèmes invités face aux attaques. Ainsi TrustVisor [42] propose un hyperviseur minimal dans le but d'implémenter des enclaves. Ces enclaves permettant d'isoler les fonctions sensibles d'une application. L'approche est similaire à celle suivie par Flicker [17] mais les auteurs utilisent ici la virtualisation au lieu de Intel TXT pour isoler les enclaves, ce qui permet de limiter le surcoût à l'exécution lors des changements de contexte. Gateway [43] vise à protéger le code du noyau de logiciel malveillant exploitant des vulnérabilités dans les pilotes de périphériques. Pour cela, il isole les pilotes dans un espace mémoire dédié et il contrôle les interactions entre ces pilotes et le reste du noyau, via une interface spécifique. Les auteurs utilisent la virtualisation pour s'assurer que les pilotes ne puissent interagir que via cette interface.

La surveillance du comportement des systèmes invités via des techniques de VMI (Virtual Machine Introspection, introspection de machines virtuelles) à fait l'objet de nombreux travaux [44]. Ces techniques permettent par exemple d'analyser dynamiquement des logiciels malveillants [35, 45] ou de vérifier l'intégrité du système surveillé [46].

En plaçant le moniteur dans l'hyperviseur ou dans une VM isolée du système surveillé, on le protège des attaques visant le système surveillé. Toutefois, cette isolation crée un fossé sémantique [47] : le moniteur ne dispose pas de toutes les informations de contexte qui lui permettent d'inférer précisément l'état du système surveillé. Par exemple, il ne dispose pas de la valeur du registre pointant sur la table des pages. En outre, il doit inférer les différentes structures de données du noyau invité pour retrouver, par exemple, la liste des processus ou des fichiers ouverts.

Différentes approches ont été proposées pour réduire ce fossé sémantique [44, 47]. Par exemple SYRINGE [48] injecte des appels de fonctions dans le système surveillé pour obtenir les informations souhaitées. L'outil contrôle l'exécution de ces appels de fonctions

<footnote n="9">9. Par exemple, Hyper-V fait l'objet de plusieurs CVE : https://www.cybersecurity-help.cz/vdb/SB2019111214</footnote>
depuis une VM isolée afin de s'assurer qu'un attaquant ne puisse les perturber. Shadow-Monitor [46] utilise une approche similaire. Une partie du moniteur est déportée dans le système surveillé et le moniteur isolé dans la VM de contrôle s'assure que la partie déportée du moniteur n'est pas perturbé par l'attaquant. PrivWatcher [49] s'intéresse plus particulièrement à la détection des non-control-data attacks qui modifient les données d'un programme.

## 2.1.4 Enclaves sécurisées

Historiquement, les processeurs ont implémenté des mécanismes permettant d'isoler les différentes applications utilisateurs ainsi que le noyau de l'OS. Des extensions sont également présentes dans bon nombre de processeurs permettant d'isoler différentes machines virtuelles et l'hyperviseur qui les contrôle. Ces mécanismes reposent sur une hiérarchie de confiance verticale : l'isolation entre composants de niveau *n* est mise en place et contrôlée par un composant de niveau *n* − 1, qui doit être de confiance. Cette approche nécessite de faire confiance aux composants logiciels de bas-niveau (OS, hyperviseur).

Des mécanismes d'enclaves ont également été proposés pour isoler certaines fonctionnalisés d'une application, sans nécessiter de faire confiance à ces composants de bas niveau, notamment dans un cas d'usage de type *cloud computing*. Des travaux ont proposé d'utiliser des mécanismes existants des processeurs de l'époque, comme Intel TXT [17] ou la virtualisation [50].

D'autres projets ont proposé de modifier l'architecture des processeurs afin d'implémenter des mécanismes dédiés [51]. Toutefois ces travaux n'ont pu être évalués qu'en simulation. De même, Noorman et al. ont proposé Sancus, un mécanisme d'enclave dédié aux systèmes embarqués [52] qui ne disposent pas de mécanisme d'isolation telle que la mémoire virtuelle. Sancus vise principalement à isoler différents composants logiciels sur un même processeur en assurant l'intégrité de ces composants (la confidentialité n'est pas un objectif de ce projet). Sancus a donné lieu à la réalisation d'un prototype sur FPGA en modifiant un *softcore* MSP430. Ces approches étendent le jeu d'instruction des processeurs pour permettre la création et la gestion des enclaves. L'exécution du code d'une enclave passe par un saut à des adresses spécifiques, appelées points d'entrée. Cela permet de limiter les attaques de type ROP (Return Oriented Programming). Ces projets assurent l'isolation de la mémoire de l'enclave et fournissent des services de vérification d'intégrité et d'attestation à distance.

Ces différents concepts se retrouvent également dans les mécanismes d'enclaves disponibles maintenant dans les processeurs du marché. Nous évoquons par la suite plus en détail les projets qui reposent sur les mécanismes ARM TrustZone (section 2.1.4.1), Intel SGX (section 2.1.4.2) et les différents mécanismes d'enclaves pour les processeurs RISC-V (section 2.1.4.3).

### 2.1.4.1 ARM TrustZone

TrustZone [53] est un mécanisme d'isolation développé par ARM et disponible sur certains de ses processeurs (Cortex-A, utilisés typiquement dans les *smartphone* et Cortex-M, destinés aux systèmes embarqués). Les processeurs ARM étant omniprésents sur les *smartphone*, ce dispositif est essentiellement utilisé pour implémenter le concept de TEE défini par le consortium GlobalPlatform [54].
depuis une VM isolée afin de s'assurer qu'un attaquant ne puisse les perturber. Shadow-Monitor [46] utilise une approche similaire. Une partie du moniteur est déportée dans le système surveillé et le moniteur isolé dans la VM de contrôle s'assure que la partie déportée du moniteur n'est pas perturbé par l'attaquant. PrivWatcher [49] s'intéresse plus particulièrement à la détection des non-control-data attacks qui modifient les données d'un programme.

## 2.1.4 Enclaves sécurisées

Historiquement, les processeurs ont implémenté des mécanismes permettant d'isoler les différentes applications utilisateurs ainsi que le noyau de l'OS. Des extensions sont également présentes dans bon nombre de processeurs permettant d'isoler différentes machines virtuelles et l'hyperviseur qui les contrôle. Ces mécanismes reposent sur une hiérarchie de confiance verticale : l'isolation entre composants de niveau *n* est mise en place et contrôlée par un composant de niveau *n* − 1, qui doit être de confiance. Cette approche nécessite de faire confiance aux composants logiciels de bas-niveau (OS, hyperviseur).

Des mécanismes d'enclaves ont également été proposés pour isoler certaines fonctionnalisés d'une application, sans nécessiter de faire confiance à ces composants de bas niveau, notamment dans un cas d'usage de type *cloud computing*. Des travaux ont proposé d'utiliser des mécanismes existants des processeurs de l'époque, comme Intel TXT [17] ou la virtualisation [50].

D'autres projets ont proposé de modifier l'architecture des processeurs afin d'implémenter des mécanismes dédiés [51]. Toutefois ces travaux n'ont pu être évalués qu'en simulation. De même, Noorman et al. ont proposé Sancus, un mécanisme d'enclave dédié aux systèmes embarqués [52] qui ne disposent pas de mécanisme d'isolation telle que la mémoire virtuelle. Sancus vise principalement à isoler différents composants logiciels sur un même processeur en assurant l'intégrité de ces composants (la confidentialité n'est pas un objectif de ce projet). Sancus a donné lieu à la réalisation d'un prototype sur FPGA en modifiant un *softcore* MSP430. Ces approches étendent le jeu d'instruction des processeurs pour permettre la création et la gestion des enclaves. L'exécution du code d'une enclave passe par un saut à des adresses spécifiques, appelées points d'entrée. Cela permet de limiter les attaques de type ROP (Return Oriented Programming). Ces projets assurent l'isolation de la mémoire de l'enclave et fournissent des services de vérification d'intégrité et d'attestation à distance.

Ces différents concepts se retrouvent également dans les mécanismes d'enclaves disponibles maintenant dans les processeurs du marché. Nous évoquons par la suite plus en détail les projets qui reposent sur les mécanismes ARM TrustZone (section 2.1.4.1), Intel SGX (section 2.1.4.2) et les différents mécanismes d'enclaves pour les processeurs RISC-V (section 2.1.4.3).

### 2.1.4.1 ARM TrustZone

TrustZone [53] est un mécanisme d'isolation développé par ARM et disponible sur certains de ses processeurs (Cortex-A, utilisés typiquement dans les *smartphone* et Cortex-M, destinés aux systèmes embarqués). Les processeurs ARM étant omniprésents sur les *smartphone*, ce dispositif est essentiellement utilisé pour implémenter le concept de TEE défini par le consortium GlobalPlatform [54].
Le terme de TEE est couramment employé dans différents articles de recherche et publications marketing. Toutefois, suivant les ouvrages, les environnements ainsi nommés ne fournissent pas toujours les mêmes services. Sabt et al. en donnent une définition précise et dressent un état de l'art des différents projets existants [55]. Cependant, TrustZone fournit un mécanisme générique d'isolation qui peut être utilisé à d'autres fins. Par exemple, Nyman et al. l'utilisent pour mettre en œuvre du CFI et protéger une shadow stack [56].

TrustZone définit deux modes de fonctionnement pour un cœur ARM [57] :

— le *non Secure World* correspond au mode d'exécution classique, dans lequel s'exécute l'OS applicatif (par exemple Android) et les applications utilisateurs;

— le *Secure World* correspond à un mode d'exécution isolé.

Le passage d'un mode à l'autre se fait via une instruction spécifique (SMC). L'exécution de cette instruction provoque une transition vers le *Secure World* et l'exécution du *monitor*, un composant logiciel qui gère les changements de contexte entre les deux modes d'exécution. Suivant les implémentations logicielles, une ou plusieurs applications de sécurité peuvent être exécutées dans le *Secure World*. Un OS sécurisé (TEE OS) peut également être utilisé pour faciliter l'accès et le partage des ressources matérielles entre ces différentes applications de sécurité. L'ensemble des applications et l'OS qui s'exécutent dans le *non Secure World* sont parfois désignés sous le terme de REE (Rich Execution Environment).

Le *Secure World* permet d'accéder à l'ensemble des ressources de la plateforme (y compris la mémoire des logiciels exécutés dans le *non Secure World*) mais l'inverse n'est pas vrai. Le mode courant du processeur peut-être exporté vers les périphériques via le bus, ce qui permet de restreindre l'accès à certains périphériques en fonction du mode d'exécution. Cela permet notamment de restreindre l'accès à une plage d'adresses physiques de la DRAM (Dynamic Random Access Memory, mémoire dynamique à accès aléatoire) au *Secure World*. Toutefois, cela doit être implémenté par le fabricant du SoC (System on a Chip, système sur une puce).

Sur le marché des smartphones Android, on retrouve principalement trois implémentations de TEE TrustZone :

— QSEE/QTEE pour les téléphone utilisant un SoC Qualcomm;

— TrustedCore, développé par Huawei;

— Kinibi, développé par Trustonic (et utilisé notamment sur certains téléphones Samsung).

Toutefois, d'autres implémentations existent [58], notamment Linaro OP-TEE [59], qui est distribuée en *open-source*. Samsung utilisait principalement Kinibi mais a maintenant développé sa propre implémentation : TEEGRIS [60].

Les principales applications exécutées dans les TEE fournissent des services aux applications Android : gestion des DRM (Digital Rights Management, gestion des droits numériques), Android KeyMaster (protection des clefs cryptographiques), paiement sécurisé ou l'authentification FIDO (Fast IDentity Online).

Samsung a également développé Knox, une solution qui vérifie et renforce l'intégrité des applications et du système Android [61]. Cette solution implémente différents services dont la vérification de l'intégrité du noyau [62, 63]. Ces solutions sont issues de travaux
Le terme de TEE est couramment employé dans différents articles de recherche et publications marketing. Toutefois, suivant les ouvrages, les environnements ainsi nommés ne fournissent pas toujours les mêmes services. Sabt et al. en donnent une définition précise et dressent un état de l'art des différents projets existants [55]. Cependant, TrustZone fournit un mécanisme générique d'isolation qui peut être utilisé à d'autres fins. Par exemple, Nyman et al. l'utilisent pour mettre en œuvre du CFI et protéger une shadow stack [56].

TrustZone définit deux modes de fonctionnement pour un cœur ARM [57] :

— le *non Secure World* correspond au mode d'exécution classique, dans lequel s'exécute l'OS applicatif (par exemple Android) et les applications utilisateurs;

— le *Secure World* correspond à un mode d'exécution isolé.

Le passage d'un mode à l'autre se fait via une instruction spécifique (SMC). L'exécution de cette instruction provoque une transition vers le *Secure World* et l'exécution du *monitor*, un composant logiciel qui gère les changements de contexte entre les deux modes d'exécution. Suivant les implémentations logicielles, une ou plusieurs applications de sécurité peuvent être exécutées dans le *Secure World*. Un OS sécurisé (TEE OS) peut également être utilisé pour faciliter l'accès et le partage des ressources matérielles entre ces différentes applications de sécurité. L'ensemble des applications et l'OS qui s'exécutent dans le *non Secure World* sont parfois désignés sous le terme de REE (Rich Execution Environment).

Le *Secure World* permet d'accéder à l'ensemble des ressources de la plateforme (y compris la mémoire des logiciels exécutés dans le *non Secure World*) mais l'inverse n'est pas vrai. Le mode courant du processeur peut-être exporté vers les périphériques via le bus, ce qui permet de restreindre l'accès à certains périphériques en fonction du mode d'exécution. Cela permet notamment de restreindre l'accès à une plage d'adresses physiques de la DRAM (Dynamic Random Access Memory, mémoire dynamique à accès aléatoire) au *Secure World*. Toutefois, cela doit être implémenté par le fabricant du SoC (System on a Chip, système sur une puce).

Sur le marché des smartphones Android, on retrouve principalement trois implémentations de TEE TrustZone :

— QSEE/QTEE pour les téléphone utilisant un SoC Qualcomm;

— TrustedCore, développé par Huawei;

— Kinibi, développé par Trustonic (et utilisé notamment sur certains téléphones Samsung).

Toutefois, d'autres implémentations existent [58], notamment Linaro OP-TEE [59], qui est distribuée en *open-source*. Samsung utilisait principalement Kinibi mais a maintenant développé sa propre implémentation : TEEGRIS [60].

Les principales applications exécutées dans les TEE fournissent des services aux applications Android : gestion des DRM (Digital Rights Management, gestion des droits numériques), Android KeyMaster (protection des clefs cryptographiques), paiement sécurisé ou l'authentification FIDO (Fast IDentity Online).

Samsung a également développé Knox, une solution qui vérifie et renforce l'intégrité des applications et du système Android [61]. Cette solution implémente différents services dont la vérification de l'intégrité du noyau [62, 63]. Ces solutions sont issues de travaux
réalisés par des chercheurs de l'université d'État de Caroline du Nord (NC State) [64]. Des chercheurs ont également proposé des mécanismes permettant de sécuriser les échanges entre le REE et le TEE [65].

Une des problématiques des TEE TrustZone est que le déploiement d'applications sécurisées nécessite l'accord du fabricant du périphérique qui a intégré le TEE, ce qui limite en pratique le déploiement de ces applications. En effet, contrairement aux autres mécanismes d'enclaves comme SGX, TrustZone ne fournit qu'un seul environnement sécurisé. Toutes les applications sécurisées s'exécutent dans le même environnement. L'ajout d'une application sécurisée augmente donc la taille de la TCB puisque ces applications sont faiblement cloisonnées entre elles. Le TEE OS peut tout de même les isoler avec les mécanismes classiques de pagination. Des travaux récents ont également proposé d'utiliser le langage Rust pour limiter l'exploitation de vulnérabilités liées à la gestion de la mémoire dans le TEE [66].

Afin de faciliter le déploiement d'applications sécurisées, Sun et al. ont proposé TrustICE [67], un mécanisme qui permet d'isoler des enclaves dans le REE. La partie installée dans le Secure World est minimale et n'a pas besoin d'être modifiée lors du déploiement d'une enclave. L'approche est similaire à Flicker [17] mais utilise TrustZone au lieu de Intel TXT.

Toutefois, ces approches implémentent une isolation temporelle qui n'est pas compatible avec les processeurs multi-cœurs modernes. Des travaux récents ont étendu cette approche en renforçant l'isolation et en permettant l'exécution en parallèle de l'enclave avec un ou plusieurs TEE [68]. SecTEE [69] propose une approche similaire mais vise également à protéger les applications des attaques physiques et des attaques par canaux auxiliaires exploitant les accès à la mémoire. Ce projet est particulièrement intéressant car TrustZone ne fournit pas nativement de protection face aux attaques contre la microarchitecture. En outre, TrustZone ne fournit pas non plus de mécanisme de chiffrement de la mémoire principale. Il est donc recommandé que les TEE utilisent seulement la mémoire interne du SoC, afin d'éviter les attaques physiques d'écoute sur le bus mémoire. Toutefois, cette mémoire est très limitée en quantité, ce qui impose des contraintes sur le TEE. Zhao et al. ont proposé d'utiliser un TEE minimal qui réside dans la mémoire interne du SoC et permet de stocker des applications sécurisées dans la DRAM, en utilisant du chiffrement [70].

TrustZone est une technologie développée initialement pour le domaine des smartphones. Les processeurs ARM sont également de plus en plus utilisés au niveau des serveurs, dans le domaine du cloud computing. Néanmoins, TrustZone n'est pas nativement adapté à la virtualisation. Des chercheurs ont donc proposé une approche pour supporter plusieurs TEE virtualisés [71].

### 2.1.4.2 Intel SGX

Intel a développé la technologie SGX permettant d'exécuter des enclaves sécurisées [72]. L'objectif est de pouvoir isoler des fonctions sensibles sans faire confiance à l'OS ni à l'hyperviseur. Le cas d'usage typique est le cloud computing où des utilisateurs souhaitent déployer des applications sur des infrastructures qu'ils ne maîtrisent pas. On peut donc redouter dans ce cas que l'OS et l'hyperviseur soient malveillants ou compromis. Le code et les données exécutés dans une enclave SGX sont donc également isolés de ces composants.
réalisés par des chercheurs de l'université d'État de Caroline du Nord (NC State) [64]. Des chercheurs ont également proposé des mécanismes permettant de sécuriser les échanges entre le REE et le TEE [65].

Une des problématiques des TEE TrustZone est que le déploiement d'applications sécurisées nécessite l'accord du fabricant du périphérique qui a intégré le TEE, ce qui limite en pratique le déploiement de ces applications. En effet, contrairement aux autres mécanismes d'enclaves comme SGX, TrustZone ne fournit qu'un seul environnement sécurisé. Toutes les applications sécurisées s'exécutent dans le même environnement. L'ajout d'une application sécurisée augmente donc la taille de la TCB puisque ces applications sont faiblement cloisonnées entre elles. Le TEE OS peut tout de même les isoler avec les mécanismes classiques de pagination. Des travaux récents ont également proposé d'utiliser le langage Rust pour limiter l'exploitation de vulnérabilités liées à la gestion de la mémoire dans le TEE [66].

Afin de faciliter le déploiement d'applications sécurisées, Sun et al. ont proposé TrustICE [67], un mécanisme qui permet d'isoler des enclaves dans le REE. La partie installée dans le Secure World est minimale et n'a pas besoin d'être modifiée lors du déploiement d'une enclave. L'approche est similaire à Flicker [17] mais utilise TrustZone au lieu de Intel TXT.

Toutefois, ces approches implémentent une isolation temporelle qui n'est pas compatible avec les processeurs multi-cœurs modernes. Des travaux récents ont étendu cette approche en renforçant l'isolation et en permettant l'exécution en parallèle de l'enclave avec un ou plusieurs TEE [68]. SecTEE [69] propose une approche similaire mais vise également à protéger les applications des attaques physiques et des attaques par canaux auxiliaires exploitant les accès à la mémoire. Ce projet est particulièrement intéressant car TrustZone ne fournit pas nativement de protection face aux attaques contre la microarchitecture. En outre, TrustZone ne fournit pas non plus de mécanisme de chiffrement de la mémoire principale. Il est donc recommandé que les TEE utilisent seulement la mémoire interne du SoC, afin d'éviter les attaques physiques d'écoute sur le bus mémoire. Toutefois, cette mémoire est très limitée en quantité, ce qui impose des contraintes sur le TEE. Zhao et al. ont proposé d'utiliser un TEE minimal qui réside dans la mémoire interne du SoC et permet de stocker des applications sécurisées dans la DRAM, en utilisant du chiffrement [70].

TrustZone est une technologie développée initialement pour le domaine des smartphones. Les processeurs ARM sont également de plus en plus utilisés au niveau des serveurs, dans le domaine du cloud computing. Néanmoins, TrustZone n'est pas nativement adapté à la virtualisation. Des chercheurs ont donc proposé une approche pour supporter plusieurs TEE virtualisés [71].

### 2.1.4.2 Intel SGX

Intel a développé la technologie SGX permettant d'exécuter des enclaves sécurisées [72]. L'objectif est de pouvoir isoler des fonctions sensibles sans faire confiance à l'OS ni à l'hyperviseur. Le cas d'usage typique est le cloud computing où des utilisateurs souhaitent déployer des applications sur des infrastructures qu'ils ne maîtrisent pas. On peut donc redouter dans ce cas que l'OS et l'hyperviseur soient malveillants ou compromis. Le code et les données exécutés dans une enclave SGX sont donc également isolés de ces composants.
Contrairement à TrustZone, l'objectif est de se prémunir également des attaques physiques par observation des communications entre le processeur et la mémoire. Pour cette raison, la mémoire des enclaves est chiffrée par le processeur avec une clé unique. En revanche, les attaques par canaux auxiliaires ne font pas partie du modèle de menace, ce qui est problématique, étant donné les cas d'usage envisagés. Le code des enclaves doit donc utiliser des contre-mesures pour lutter contre ces attaques. Par exemple Weiser et al. proposent d'utiliser une mémoire ORAM implémentée en FPGA pour protéger le code des enclaves contre ce type d'attaques [73].

Contrairement à TrustZone, le code des enclaves s'exécute dans l'espace utilisateur et ne peut réaliser d'appel système. Pour interagir avec le matériel, il doit donc appeler du code situé en dehors de l'enclave. De même, SGX s'appuie sur l'OS pour gérer les pages mémoires de l'enclave. Des mécanismes de protection s'assurent que l'OS ne peut compromettre l'intégrité des enclaves. Toutefois, les enclaves SGX peuvent être vulnérables aux *controlled-channel attacks*. L'OS peut provoquer intentionnellement des erreurs de page afin d'observer la séquence des adresses accédées par l'enclave. Afin de lutter contre ce canal auxiliaire, Shih et al. ont proposé T-SGX [74] qui s'appuie sur le mécanisme de mémoire transactionnelle Intel TSX (Transactional Synchronization Extensions).

Ce mécanisme a été utilisé par de nombreux travaux de recherche [75]. Des chercheurs du MIT ont notamment publié un document qui explique le fonctionnement de ce mécanisme complexe qui a des interactions avec les nombreux mécanismes déployés dans les architecture x86 [76].

Afin de faciliter le développement d'enclaves, Intel fournit un SDK (Software Development Kit, kit de développement logiciel) [77]. Il est également possible d'utiliser des SDK fournis par d'autres éditeurs comme Microsoft [78], Google [79] ou Fortanix [80]. Ce dernier permet de développer des enclaves en Rust, ce qui limite leur surface d'attaques. C'est également l'approche proposée par des chercheurs de Baidu [81].

Ces SDK sont destinés à isoler certaines fonctions d'applications qui doivent être développées spécifiquement pour cette technologie. D'autres outils [82-84] ont été développés pour permettre d'isoler des applications entières au sein d'une enclave, en minimisant l'effort d'adaptation. Comme il n'est pas possible de réaliser directement des appels système depuis les enclaves, ces outils utilisent une approche de *library OS*. Cette approche consiste à ajouter dans l'enclave une bibliothèque qui fournit les fonctions de l'OS au code de l'enclave et réalise des appels externes. Graphene [85] suit la même approche mais ne nécessite pas de recompiler les applications.

Ces approches permettent d'isoler des applications en minimisant l'effort d'adaptation. Toutefois, comme l'intégralité du code de l'application est exécutée dans l'enclave, cela augmente la surface d'attaque et la TCB de l'enclave. Des approches ont donc proposé de réduire cette surface d'attaque [86]. De même, certaines approches renforcent la sécurité en cloisonnant le code exécuté au sein de l'enclave à l'aide de Intel MPK [87], en mettant en place de l'ASLR au niveau de l'enclave [88] ou en utilisant le langage Rust [80, 81].

### 2.1.4.3 Enclaves RISC-V

RISC-V est une architecture de processeur ouverte issue des travaux de l'université de Berkeley et promue par la fondation RISC-V, qui publie notamment les spécifications. Plusieurs projets se sont intéressés à définir un mécanisme d'enclave pour cette architec-
Contrairement à TrustZone, l'objectif est de se prémunir également des attaques physiques par observation des communications entre le processeur et la mémoire. Pour cette raison, la mémoire des enclaves est chiffrée par le processeur avec une clé unique. En revanche, les attaques par canaux auxiliaires ne font pas partie du modèle de menace, ce qui est problématique, étant donné les cas d'usage envisagés. Le code des enclaves doit donc utiliser des contre-mesures pour lutter contre ces attaques. Par exemple Weiser et al. proposent d'utiliser une mémoire ORAM implémentée en FPGA pour protéger le code des enclaves contre ce type d'attaques [73].

Contrairement à TrustZone, le code des enclaves s'exécute dans l'espace utilisateur et ne peut réaliser d'appel système. Pour interagir avec le matériel, il doit donc appeler du code situé en dehors de l'enclave. De même, SGX s'appuie sur l'OS pour gérer les pages mémoires de l'enclave. Des mécanismes de protection s'assurent que l'OS ne peut compromettre l'intégrité des enclaves. Toutefois, les enclaves SGX peuvent être vulnérables aux *controlled-channel attacks*. L'OS peut provoquer intentionnellement des erreurs de page afin d'observer la séquence des adresses accédées par l'enclave. Afin de lutter contre ce canal auxiliaire, Shih et al. ont proposé T-SGX [74] qui s'appuie sur le mécanisme de mémoire transactionnelle Intel TSX (Transactional Synchronization Extensions).

Ce mécanisme a été utilisé par de nombreux travaux de recherche [75]. Des chercheurs du MIT ont notamment publié un document qui explique le fonctionnement de ce mécanisme complexe qui a des interactions avec les nombreux mécanismes déployés dans les architecture x86 [76].

Afin de faciliter le développement d'enclaves, Intel fournit un SDK (Software Development Kit, kit de développement logiciel) [77]. Il est également possible d'utiliser des SDK fournis par d'autres éditeurs comme Microsoft [78], Google [79] ou Fortanix [80]. Ce dernier permet de développer des enclaves en Rust, ce qui limite leur surface d'attaques. C'est également l'approche proposée par des chercheurs de Baidu [81].

Ces SDK sont destinés à isoler certaines fonctions d'applications qui doivent être développées spécifiquement pour cette technologie. D'autres outils [82-84] ont été développés pour permettre d'isoler des applications entières au sein d'une enclave, en minimisant l'effort d'adaptation. Comme il n'est pas possible de réaliser directement des appels système depuis les enclaves, ces outils utilisent une approche de *library OS*. Cette approche consiste à ajouter dans l'enclave une bibliothèque qui fournit les fonctions de l'OS au code de l'enclave et réalise des appels externes. Graphene [85] suit la même approche mais ne nécessite pas de recompiler les applications.

Ces approches permettent d'isoler des applications en minimisant l'effort d'adaptation. Toutefois, comme l'intégralité du code de l'application est exécutée dans l'enclave, cela augmente la surface d'attaque et la TCB de l'enclave. Des approches ont donc proposé de réduire cette surface d'attaque [86]. De même, certaines approches renforcent la sécurité en cloisonnant le code exécuté au sein de l'enclave à l'aide de Intel MPK [87], en mettant en place de l'ASLR au niveau de l'enclave [88] ou en utilisant le langage Rust [80, 81].

### 2.1.4.3 Enclaves RISC-V

RISC-V est une architecture de processeur ouverte issue des travaux de l'université de Berkeley et promue par la fondation RISC-V, qui publie notamment les spécifications. Plusieurs projets se sont intéressés à définir un mécanisme d'enclave pour cette architec-
ture. Dessouky et al. dressent un état de l'art de ces différents projets en comparant leur
architecture, les fonctionnalités apportées, le modèle d'attaquant considéré, la TCB et les
fonctionnalités matérielles utilisées [89].

Sanctum [90], développé par le MIT, est un des premiers projets d'enclaves RISC-V.
Il prend en compte, dans son modèle de menaces, les attaques par canaux auxiliaires
mais pas les attaques physiques. Le mécanisme est similaire à Intel SGX. Les enclaves
s'exécutent en espace utilisateur et s'appuient sur l'OS. Toutefois, les auteurs ont inclus
des mécanismes pour se prémunir contre les attaques par canaux auxiliaires et notamment
les controlled-channel attacks.

Keystone [91], un projet de l'université de Berkeley, réalisé notamment par l'équipe qui a développé l'architecture RISC-V, considère un modèle de menaces similaire mais inclut également les attaques physiques par espionnage du bus mémoire. Toutefois, à l'inverse de Sanctum et de Intel SGX, les enclaves Keystone comportent également du code qui s'exécute en mode noyau.

TIMBER-V [92] propose un mécanisme d'enclave pour les systèmes embarqués en s'ap-
puyant sur une approche d'étiquetage de la mémoire (*tagged memory*) qui permet d'asso-
cier une étiquette à des blocs mémoire. Cette approche a été utilisée dans d'autres travaux
de la littérature pour implémenter du DIFT (Dynamic Information Flow Tracking, suivi
dynamique des flux d'information) [93] ou des systèmes de capacités [94]. Les auteurs
l'utilisent ici pour implémenter un mécanisme d'isolation à grain fin afin d'éviter la frag-
mentation de la mémoire et d'utiliser au mieux la quantité limitée de mémoire disponible
dans les systèmes embarqués.

Ces projets offrent différents modèles d'enclaves qui sont plus ou moins adaptés selon les
besoins. En outre, ils offrent une protection limitée contre les attaques par canaux auxi-
liaires et ne proposent pas de canaux de communications sécurisés vers les périphériques.
Le projet CURE [95] tente de résoudre ces différents problèmes en proposant différents
types de modèles d'enclaves.

Des entreprises ont également développé et commercialisent des mécanismes d'enclaves
RISC-V, notamment HEX-Five [96].

2.1.5 Co-processeur de sécurité

Les enclaves présentées dans les sections précédentes s'exécutent au sein du processeur
principal. Elles utilisent des mécanismes d'isolation fournis par le processeur mais par-
tagent les ressources matérielles (cœur CPU, cache, RAM, périphériques) avec le reste des
applications. Cela les rend, en général, vulnérables aux attaques par canaux auxiliaires.
En outre, elles peuvent être vulnérables à un défaut dans le mécanisme d'isolation.

Afin de renforcer l'isolation, des approches ont proposé d'utiliser un processeur ou un cœur d'exécution, séparé physiquement du processeur principal, pour isoler des fonctions de sécurité. Historiquement, IBM a été un des premiers constructeurs à suivre cette approche en développant le processeur IBM 4758 [97]. L'objectif était de fournir un TEE pour exécuter des applications sécurisées. En outre, des chercheurs d'IBM ont proposé d'utiliser ce coprocesseur pour implémenter un service de surveillance des applications exécutées sur le processeur principal, afin de détecter d'éventuelles intrusions [98].

De nos jours, Apple déploie un coprocesseur de sécurité appelé SEP (Secure Enclave
ture. Dessouky et al. dressent un état de l'art de ces différents projets en comparant leur
architecture, les fonctionnalités apportées, le modèle d'attaquant considéré, la TCB et les
fonctionnalités matérielles utilisées [89].

Sanctum [90], développé par le MIT, est un des premiers projets d'enclaves RISC-V.
Il prend en compte, dans son modèle de menaces, les attaques par canaux auxiliaires
mais pas les attaques physiques. Le mécanisme est similaire à Intel SGX. Les enclaves
s'exécutent en espace utilisateur et s'appuient sur l'OS. Toutefois, les auteurs ont inclus
des mécanismes pour se prémunir contre les attaques par canaux auxiliaires et notamment
les controlled-channel attacks.

Keystone [91], un projet de l'université de Berkeley, réalisé notamment par l'équipe qui a développé l'architecture RISC-V, considère un modèle de menaces similaire mais inclut également les attaques physiques par espionnage du bus mémoire. Toutefois, à l'inverse de Sanctum et de Intel SGX, les enclaves Keystone comportent également du code qui s'exécute en mode noyau.

TIMBER-V [92] propose un mécanisme d'enclave pour les systèmes embarqués en s'ap-
puyant sur une approche d'étiquetage de la mémoire (*tagged memory*) qui permet d'asso-
cier une étiquette à des blocs mémoire. Cette approche a été utilisée dans d'autres travaux
de la littérature pour implémenter du DIFT (Dynamic Information Flow Tracking, suivi
dynamique des flux d'information) [93] ou des systèmes de capacités [94]. Les auteurs
l'utilisent ici pour implémenter un mécanisme d'isolation à grain fin afin d'éviter la frag-
mentation de la mémoire et d'utiliser au mieux la quantité limitée de mémoire disponible
dans les systèmes embarqués.

Ces projets offrent différents modèles d'enclaves qui sont plus ou moins adaptés selon les
besoins. En outre, ils offrent une protection limitée contre les attaques par canaux auxi-
liaires et ne proposent pas de canaux de communications sécurisés vers les périphériques.
Le projet CURE [95] tente de résoudre ces différents problèmes en proposant différents
types de modèles d'enclaves.

Des entreprises ont également développé et commercialisent des mécanismes d'enclaves
RISC-V, notamment HEX-Five [96].

2.1.5 Co-processeur de sécurité

Les enclaves présentées dans les sections précédentes s'exécutent au sein du processeur
principal. Elles utilisent des mécanismes d'isolation fournis par le processeur mais par-
tagent les ressources matérielles (cœur CPU, cache, RAM, périphériques) avec le reste des
applications. Cela les rend, en général, vulnérables aux attaques par canaux auxiliaires.
En outre, elles peuvent être vulnérables à un défaut dans le mécanisme d'isolation.

Afin de renforcer l'isolation, des approches ont proposé d'utiliser un processeur ou un cœur d'exécution, séparé physiquement du processeur principal, pour isoler des fonctions de sécurité. Historiquement, IBM a été un des premiers constructeurs à suivre cette approche en développant le processeur IBM 4758 [97]. L'objectif était de fournir un TEE pour exécuter des applications sécurisées. En outre, des chercheurs d'IBM ont proposé d'utiliser ce coprocesseur pour implémenter un service de surveillance des applications exécutées sur le processeur principal, afin de détecter d'éventuelles intrusions [98].

De nos jours, Apple déploie un coprocesseur de sécurité appelé SEP (Secure Enclave
(Processor) dans ses téléphones iPhone depuis la version 5s [99]. Il s'agit d'un processeur séparé du processeur principal. Il utilise une zone dédiée de la DRAM, qui est chiffrée. Le processeur principal peut uniquement communiquer avec le SEP via un mécanisme de boîte aux lettres. Ce processeur permet entre autres de stocker des clés cryptographiques, de chiffrer les données biométriques et de gérer le démarrage sécurisé du smartphone.

AMD utilise également un coprocesseur appelé Secure Processor ou PSP (Platform Security Processor) [100] qui fournit des services similaires. Il s'agit d'un processeur ARM qui gère notamment le démarrage sécurisé des plateformes AMD car le PSP est démarré avant le processeur x86. Il comprend également un TPM logiciel. Le firmware de ce processeur est stocké de manière sécurisée dans une mémoire flash dédiée. Toutefois, des chercheurs ont pu récemment exploiter une faille leur permettant de récupérer ce firmware en écouant sur le bus SPI reliant le PSP à la mémoire flash [100]. Des employés d'une société israélienne ont également démontré plusieurs failles permettant d'injecter du code dans le firmware du PSP, en raison d'une vulnérabilité dans le code de vérification d'intégrité du firmware [101]. Comme ce processeur a accès, sans restriction, à l'intégralité de la mémoire physique, l'exécution de code malveillant au sein du PSP permet de contourner les autres mécanismes de sécurité de la plateforme. Ces vulnérabilités ont depuis été corrigées.

HP utilise également un microcontrôleur dédié pour implémenter sa solution HP Sure Start [102, 103]. Ce mécanisme permet notamment de vérifier l'intégrité du firmware UEFI des ordinateurs haut de gamme de la marque, et de les restaurer en cas de commission.

Intel utilise aussi un processeur isolé, le CSME (Converged Security and Management Engine), qui est maintenant situé au sein du chipset intégré des processeurs Intel, le PCH (Platform Controller Hub) [104]. Il s'agit, dans les dernières versions des processeurs Intel, d'un processeur Intel 486 isolé, qui est relié au bus PCIe. Ce composant a un accès privilégié à la mémoire et aux différents périphériques de l'ordinateur. Son firmware comprend un OS dérivé de Minix [105] et plusieurs applications. Il est utilisé pour la gestion des DRM et pour implémenter la technologie Intel AMT (Active Management Technology). Cette dernière permet d'administrer l'ordinateur à distance, même lorsqu'il est éteint, dès lors qu'il est alimenté électriquement et relié à un réseau informatique. Le CSME exécute également un TPM logiciel.

Toutefois, de nombreuses vulnérabilités ont été découvertes concernant les logiciels exécutés sur le CSME et en particulier ceux gérant AMT [106]. Comme il s'agit d'un composant très privilégié, l'exploitation d'une vulnérabilité permet à un attaquant d'obtenir des privilèges importants sur la plateforme. En outre, les différents travaux de rétroconception ont démontré que les mécanismes de protection du logiciel (protection contre les corruptions mémoire, isolation interne, etc.) sont assez limités.

Le firmware du CSME est situé dans une mémoire flash. Il est signé et chiffré. Cependant, des employés de la société russe Positive Technology ont pu exploiter une vulnérabilité sur certaines cartes mères permettant d'activer la mise au point via JTAG du processeur x86 et de son chipset [107]. Cette attaque leur a permis d'avoir accès au code du firmware du CSME. En effet, sur ses processeurs récents, Intel a intégré la possibilité de transporter le protocole JTAG via USB (Universal Serial Bus) en utilisant le DCI (Direct Connect Interface) [108].

Ces différentes technologies sont propriétaires et peu d'informations publiques sont dis-
(Processor) dans ses téléphones iPhone depuis la version 5s [99]. Il s'agit d'un processeur séparé du processeur principal. Il utilise une zone dédiée de la DRAM, qui est chiffrée. Le processeur principal peut uniquement communiquer avec le SEP via un mécanisme de boîte aux lettres. Ce processeur permet entre autres de stocker des clés cryptographiques, de chiffrer les données biométriques et de gérer le démarrage sécurisé du smartphone.

AMD utilise également un coprocesseur appelé Secure Processor ou PSP (Platform Security Processor) [100] qui fournit des services similaires. Il s'agit d'un processeur ARM qui gère notamment le démarrage sécurisé des plateformes AMD car le PSP est démarré avant le processeur x86. Il comprend également un TPM logiciel. Le firmware de ce processeur est stocké de manière sécurisée dans une mémoire flash dédiée. Toutefois, des chercheurs ont pu récemment exploiter une faille leur permettant de récupérer ce firmware en écouant sur le bus SPI reliant le PSP à la mémoire flash [100]. Des employés d'une société israélienne ont également démontré plusieurs failles permettant d'injecter du code dans le firmware du PSP, en raison d'une vulnérabilité dans le code de vérification d'intégrité du firmware [101]. Comme ce processeur a accès, sans restriction, à l'intégralité de la mémoire physique, l'exécution de code malveillant au sein du PSP permet de contourner les autres mécanismes de sécurité de la plateforme. Ces vulnérabilités ont depuis été corrigées.

HP utilise également un microcontrôleur dédié pour implémenter sa solution HP Sure Start [102, 103]. Ce mécanisme permet notamment de vérifier l'intégrité du firmware UEFI des ordinateurs haut de gamme de la marque, et de les restaurer en cas de commission.

Intel utilise aussi un processeur isolé, le CSME (Converged Security and Management Engine), qui est maintenant situé au sein du chipset intégré des processeurs Intel, le PCH (Platform Controller Hub) [104]. Il s'agit, dans les dernières versions des processeurs Intel, d'un processeur Intel 486 isolé, qui est relié au bus PCIe. Ce composant a un accès privilégié à la mémoire et aux différents périphériques de l'ordinateur. Son firmware comprend un OS dérivé de Minix [105] et plusieurs applications. Il est utilisé pour la gestion des DRM et pour implémenter la technologie Intel AMT (Active Management Technology). Cette dernière permet d'administrer l'ordinateur à distance, même lorsqu'il est éteint, dès lors qu'il est alimenté électriquement et relié à un réseau informatique. Le CSME exécute également un TPM logiciel.

Toutefois, de nombreuses vulnérabilités ont été découvertes concernant les logiciels exécutés sur le CSME et en particulier ceux gérant AMT [106]. Comme il s'agit d'un composant très privilégié, l'exploitation d'une vulnérabilité permet à un attaquant d'obtenir des privilèges importants sur la plateforme. En outre, les différents travaux de rétroconception ont démontré que les mécanismes de protection du logiciel (protection contre les corruptions mémoire, isolation interne, etc.) sont assez limités.

Le firmware du CSME est situé dans une mémoire flash. Il est signé et chiffré. Cependant, des employés de la société russe Positive Technology ont pu exploiter une vulnérabilité sur certaines cartes mères permettant d'activer la mise au point via JTAG du processeur x86 et de son chipset [107]. Cette attaque leur a permis d'avoir accès au code du firmware du CSME. En effet, sur ses processeurs récents, Intel a intégré la possibilité de transporter le protocole JTAG via USB (Universal Serial Bus) en utilisant le DCI (Direct Connect Interface) [108].

Ces différentes technologies sont propriétaires et peu d'informations publiques sont dis-
ponibles. Les détails d'implémentation ont souvent été révélés suite à l'exploitation de vulnérabilités ayant permis d'effectuer un travail de rétroconception. En outre, elles permettent essentiellement d'implémenter des services de sécurité du concepteur de la plate-forme.

Des travaux de recherche se sont également intéressés à l'utilisation d'un coprocesseur isolé afin de surveiller les applications exécutées sur le processeur principal, notamment l'OS et l'hyperviseur. Au delà de la vérification d'intégrité, des approches ont également été proposées pour vérifier différents types de politique de sécurité, comme le CFI ou le DIFT.

### 2.1.5.1 Vérification de l'intégrité de l'OS et de l'hyperviseur

Plusieurs travaux ont proposé des approches de vérification de l'intégrité du noyau ou de l'hyperviseur en utilisant un coprocesseur isolé. Ainsi, Copilot [109] utilise un coprocesseur connecté au bus PCI (Peripheral Component Interconnect) afin de vérifier l'intégrité du code du noyau ainsi que certaines tables de pointeurs. L'objectif est de détecter des *rootkit* au niveau du noyau. L'approche de détection est simple : le détecteur s'assure que les structures n'ont pas été modifiées en vérifiant leurs résumés cryptographiques. Les auteurs de cette approche l'ont ensuite étendue afin de détecter un plus large spectre d'attaques [110]. En effet, l'approche précédente n'est pas adaptée pour surveiller des structures qui sont censées être modifiées régulièrement durant l'exécution du noyau, comme par exemple la liste des processus. Ils ont donc proposé une approche permettant d'exprimer des invariants qui doivent être respectés sur la manipulation de ces structures par le code du noyau. Des chercheurs d'Intel ont proposé une approche similaire pour détecter des *rootkit* dans un hyperviseur. Ils ont proposé pour cela d'utiliser l'ancêtre du CSME [111].

Wang et al. ont développé une approche hybride pour surveiller l'intégrité de l'OS et de l'hyperviseur [112]. Ils utilisent le SMM pour réaliser l'acquisition de la mémoire et déportent la vérification vers un serveur externe en utilisant une carte réseau spécifique. De même Hypersentry utilise un contrôleur BMC (Baseboard Management Controller) afin de pouvoir déclencher à distance la vérification de l'intégrité de la mémoire, qui est réalisée par un code exécuté en SMM [113]. Bien qu'elles utilisent un composant externe, ces approches reposent en grande partie sur l'isolation fournie par le SMM.

Les travaux présentés jusqu'ici reposent sur l'acquisition régulière de la mémoire. Toutefois, cette approche est vulnérable aux *transient attacks* qui consistent à réaliser une attaque sur le système surveillé entre deux acquisitions puis à nettoyer les traces de l'attaque. Pour lutter contre ce type d'attaques, les auteurs de Vigilare [114] proposent de surveiller l'ensemble des transactions réalisées sur le bus mémoire. Ils utilisent pour cela un composant externe connecté sur le bus en question. Ils ont par la suite étendu leur approche pour surveiller les structures dynamiques du noyau [115]. L'approche de détection est similaire à celle proposée par Petroni et al. [110].

Toutefois, les approches surveillant le bus mémoire peuvent être contournées par un attaquant utilisant une politique de type *write-back* sur les caches. Lee et al. ont proposé une approche complémentaire utilisant l'interface de mise au point du processeur (*Core Debugging Interface*) afin de prendre en compte cette limitation [116]. En outre, ces approches nécessitent des modifications importantes au niveau du matériel. Koromilas et al. ont proposé d'utiliser le GPU (*Graphics Processing Unit*) pour isoler le moniteur et réaliser
ponibles. Les détails d'implémentation ont souvent été révélés suite à l'exploitation de vulnérabilités ayant permis d'effectuer un travail de rétroconception. En outre, elles permettent essentiellement d'implémenter des services de sécurité du concepteur de la plate-forme.

Des travaux de recherche se sont également intéressés à l'utilisation d'un coprocesseur isolé afin de surveiller les applications exécutées sur le processeur principal, notamment l'OS et l'hyperviseur. Au delà de la vérification d'intégrité, des approches ont également été proposées pour vérifier différents types de politique de sécurité, comme le CFI ou le DIFT.

### 2.1.5.1 Vérification de l'intégrité de l'OS et de l'hyperviseur

Plusieurs travaux ont proposé des approches de vérification de l'intégrité du noyau ou de l'hyperviseur en utilisant un coprocesseur isolé. Ainsi, Copilot [109] utilise un coprocesseur connecté au bus PCI (Peripheral Component Interconnect) afin de vérifier l'intégrité du code du noyau ainsi que certaines tables de pointeurs. L'objectif est de détecter des *rootkit* au niveau du noyau. L'approche de détection est simple : le détecteur s'assure que les structures n'ont pas été modifiées en vérifiant leurs résumés cryptographiques. Les auteurs de cette approche l'ont ensuite étendue afin de détecter un plus large spectre d'attaques [110]. En effet, l'approche précédente n'est pas adaptée pour surveiller des structures qui sont censées être modifiées régulièrement durant l'exécution du noyau, comme par exemple la liste des processus. Ils ont donc proposé une approche permettant d'exprimer des invariants qui doivent être respectés sur la manipulation de ces structures par le code du noyau. Des chercheurs d'Intel ont proposé une approche similaire pour détecter des *rootkit* dans un hyperviseur. Ils ont proposé pour cela d'utiliser l'ancêtre du CSME [111].

Wang et al. ont développé une approche hybride pour surveiller l'intégrité de l'OS et de l'hyperviseur [112]. Ils utilisent le SMM pour réaliser l'acquisition de la mémoire et déportent la vérification vers un serveur externe en utilisant une carte réseau spécifique. De même Hypersentry utilise un contrôleur BMC (Baseboard Management Controller) afin de pouvoir déclencher à distance la vérification de l'intégrité de la mémoire, qui est réalisée par un code exécuté en SMM [113]. Bien qu'elles utilisent un composant externe, ces approches reposent en grande partie sur l'isolation fournie par le SMM.

Les travaux présentés jusqu'ici reposent sur l'acquisition régulière de la mémoire. Toutefois, cette approche est vulnérable aux *transient attacks* qui consistent à réaliser une attaque sur le système surveillé entre deux acquisitions puis à nettoyer les traces de l'attaque. Pour lutter contre ce type d'attaques, les auteurs de Vigilare [114] proposent de surveiller l'ensemble des transactions réalisées sur le bus mémoire. Ils utilisent pour cela un composant externe connecté sur le bus en question. Ils ont par la suite étendu leur approche pour surveiller les structures dynamiques du noyau [115]. L'approche de détection est similaire à celle proposée par Petroni et al. [110].

Toutefois, les approches surveillant le bus mémoire peuvent être contournées par un attaquant utilisant une politique de type *write-back* sur les caches. Lee et al. ont proposé une approche complémentaire utilisant l'interface de mise au point du processeur (*Core Debugging Interface*) afin de prendre en compte cette limitation [116]. En outre, ces approches nécessitent des modifications importantes au niveau du matériel. Koromilas et al. ont proposé d'utiliser le GPU (Graphics Processing Unit) pour isoler le moniteur et réaliser
régulièrement des acquisitions de la mémoire à une fréquence importante, ce qui permet d'éviter les transient attacks sans requérir de modification au niveau matériel [117]. De même Nighthawk [118] implémente le moniteur dans le CSME, ce qui permet de surveiller l'ensemble du code s'exécutant sur le processeur principal, y compris en SMM et ce sans nécessiter de modification au niveau matériel.

Ces différentes approches se focalisent sur la vérification d'intégrité. Toutefois d'autres politiques de sécurité peuvent être implémentées via un coprocesseur externe. Ces approches sont une alternative à la vérification logicielle ou intégrée au processeur. L'utilisation d'un support matériel permet de protéger le mécanisme et d'accélérer les traitements. Le déport dans un processeur externe a l'avantage de ne pas impliquer de modification de la microarchitecture du processeur principal. Toutefois, en isolant la fonction de sécurité de la sorte, se pose le problème du fossé sémantique. Le processeur externe possède une visibilité réduite sur l'état du processeur principal.

Pour franchir ce fossé, il est nécessaire d'extraire les informations nécessaires du processeur principal et de les envoyer vers le coprocesseur de sécurité. Ces informations dépendent de la politique de sécurité implémentée. Des travaux ont proposé de réutiliser des mécanismes de traces existants sur les processeurs du marché pour envoyer ces informations au coprocesseur. Ces mécanismes, dont l'objectif premier est la mise au point des programmes, peuvent être détournés pour mettre en place des mécanismes de sécurité, comme présenté en section 2.1.7. Nous évoquons ici leur utilisation dans le cadre des échanges avec un coprocesseur de sécurité.

### 2.1.5.2 Vérification de politiques de sécurité

Des travaux se sont intéressés à implémenter une politique de CFI à l'aide d'un coprocesseur externe. Cette politique permet de lutter contre les attaques de corruption de la mémoire qui visent à détourner le flot d'exécution de l'application. Ainsi, l'entreprise Secure-IC a développé HCODE [119], un projet permettant de surveiller les instructions de branchement depuis un moniteur externe afin de vérifier la politique de CFI. Ils diffient pour cela un cœur de processeur SPARC LEON afin de générer les traces et de s'interfacer avec le moniteur externe.

Lee *et al*. ont également proposé d'utiliser le mécanisme de traces ARM PTM afin de vérifier le CFI sur un moniteur de sécurité externe [120]. Cette approche ne nécessite aucune modification au niveau du matériel.

Des chercheurs de l'équipe projet Inria/CentraleSupélec CIDRE ont proposé, dans le cadre d'une collaboration avec les laboratoires d'HP Inc, une approche permettant de vérifier une politique de CFI au niveau du code du firmware s'exécutant en SMM [121]. Comme indiqué en section 2.1.2, ce type de code s'exécute avec des privilèges élevés. Une vulnérabilité peut alors permettre à l'attaquant de se camoufler et de devenir persistant sur la machine. Ce type de code étant développé en C, il est potentiellement vulnérable aux attaques de corruption mémoire, d'où l'intérêt de le protéger en utilisant le CFI.

Le DIFT est un autre type de politique de sécurité permettant de détecter un large spectre d'attaques. Il s'agit d'associer des métadonnées, appelées *tag* ou *label* dans la littérature, à des conteneurs d'information (typiquement, des pages mémoires et des registres). Il s'agit ensuite de propager ces étiquettes en fonction des instructions exécutées afin de refléter les flux d'information qui résultent de l'exécution de chaque instruction.
régulièrement des acquisitions de la mémoire à une fréquence importante, ce qui permet d'éviter les transient attacks sans requérir de modification au niveau matériel [117]. De même Nighthawk [118] implémente le moniteur dans le CSME, ce qui permet de surveiller l'ensemble du code s'exécutant sur le processeur principal, y compris en SMM et ce sans nécessiter de modification au niveau matériel.

Ces différentes approches se focalisent sur la vérification d'intégrité. Toutefois d'autres politiques de sécurité peuvent être implémentées via un coprocesseur externe. Ces approches sont une alternative à la vérification logicielle ou intégrée au processeur. L'utilisation d'un support matériel permet de protéger le mécanisme et d'accélérer les traitements. Le déport dans un processeur externe a l'avantage de ne pas impliquer de modification de la microarchitecture du processeur principal. Toutefois, en isolant la fonction de sécurité de la sorte, se pose le problème du fossé sémantique. Le processeur externe possède une visibilité réduite sur l'état du processeur principal.

Pour franchir ce fossé, il est nécessaire d'extraire les informations nécessaires du processeur principal et de les envoyer vers le coprocesseur de sécurité. Ces informations dépendent de la politique de sécurité implémentée. Des travaux ont proposé de réutiliser des mécanismes de traces existants sur les processeurs du marché pour envoyer ces informations au coprocesseur. Ces mécanismes, dont l'objectif premier est la mise au point des programmes, peuvent être détournés pour mettre en place des mécanismes de sécurité, comme présenté en section 2.1.7. Nous évoquons ici leur utilisation dans le cadre des échanges avec un coprocesseur de sécurité.

### 2.1.5.2 Vérification de politiques de sécurité

Des travaux se sont intéressés à implémenter une politique de CFI à l'aide d'un coprocesseur externe. Cette politique permet de lutter contre les attaques de corruption de la mémoire qui visent à détourner le flot d'exécution de l'application. Ainsi, l'entreprise Secure-IC a développé HCODE [119], un projet permettant de surveiller les instructions de branchement depuis un moniteur externe afin de vérifier la politique de CFI. Ils diffient pour cela un cœur de processeur SPARC LEON afin de générer les traces et de s'interfacer avec le moniteur externe.

Lee *et al.* ont également proposé d'utiliser le mécanisme de traces ARM PTM afin de vérifier le CFI sur un moniteur de sécurité externe [120]. Cette approche ne nécessite aucune modification au niveau du matériel.

Des chercheurs de l'équipe projet Inria/CentraleSupélec CIDRE ont proposé, dans le cadre d'une collaboration avec les laboratoires d'HP Inc, une approche permettant de vérifier une politique de CFI au niveau du code du firmware s'exécutant en SMM [121]. Comme indiqué en section 2.1.2, ce type de code s'exécute avec des privilèges élevés. Une vulnérabilité peut alors permettre à l'attaquant de se camoufler et de devenir persistant sur la machine. Ce type de code étant développé en C, il est potentiellement vulnérable aux attaques de corruption mémoire, d'où l'intérêt de le protéger en utilisant le CFI.

Le DIFT est un autre type de politique de sécurité permettant de détecter un large spectre d'attaques. Il s'agit d'associer des métadonnées, appelées *tag* ou *label* dans la littérature, à des conteneurs d'information (typiquement, des pages mémoires et des registres). Il s'agit ensuite de propager ces étiquettes en fonction des instructions exécutées afin de refléter les flux d'information qui résultent de l'exécution de chaque instruction.
Afin d'implémenter la propagation et la vérification des étiquettes dans un coprocesseur externe, plusieurs approches ont été proposées. Raksha [122] est un des premiers travaux à proposer de découpler le mécanisme de DIFT de l'implémentation du processeur principal. Pour combler le fossé sémantique lié à l'isolation, il est nécessaire d'envoyer la suite des instructions générant des flux d'information vers le coprocesseur. L'approche repose sur la mise en place d'un mécanisme de traces qui permet d'envoyer ces informations au moniteur DIFT. Rasksha nécessite quelques modifications de la microarchitecture du processeur principal pour mettre en place ce mécanisme de traces, ce qui limite son adoption.

Des travaux ont proposé d'utiliser les mécanismes de traces fournis par les processeurs disponibles sur le marché. Ainsi Lee et al. utilisent le mécanisme ARM ETM (Embedded Trace Macrocell) disponible sur la plupart des processeurs ARM destinés aux systèmes embarqués [123]. Ce mécanisme permet de tracer toutes les instructions exécutées.

Toutefois, sur les processeurs plus puissants, utilisés typiquement sur les smartphone, ce mécanisme n'est pas implémenté car le débit des traces serait trop important pour pouvoir être traité en temps réel sans impacter les performances. ARM implémente à la place le mécanisme PTM (Program Trace Macrocell) qui ne trace que les exceptions et les sauts. Il est donc nécessaire de retrouver les séquences d'instructions exécutées linéairement dans un bloc de base. HardBlare implémente le DIFT en utilisant le mécanisme de traces ARM PTM. Il complète les informations manquantes, nécessaires au DIFT, en utilisant une préanalyse statique et une instrumentation des applications lors de la compilation. Ces informations manquantes sont stockées sous forme d'annotations et envoyées au coprocesseur lors du chargement du programme exécutable [93].

Ces différentes approches se focalisent sur la vérification d'une politique de sécurité. PHMon [124] propose un mécanisme générique qui permet de surveiller différents types de politiques de sécurité et ainsi de rentabiliser les mécanismes matériels ajoutés à l'architecture.

### 2.1.5.3 Limites des moniteurs externes

Les approches qui reposent sur un moniteur externe et déclenchent des vérifications lors de certains événements sont potentiellement vulnérables à des attaques en évasion. L'attaquant peut inférer le type d'événements capturés ainsi que la fréquence des vérifications afin de conduire son attaque entre deux vérifications et effacer ses traces [125].

En outre, les moniteurs ne peuvent observer que la mémoire physique. Des attaques en évasion sont donc possibles en modifiant la correspondance entre mémoire virtuelle et physique, au dépend du moniteur [126]. Enfin, les données qui résident dans le cache peuvent échapper à la vérification, si le moniteur se contente de surveiller la mémoire [127]. Ces limitations peuvent également concerner les moniteurs isolés à l'aide de TrustZone [128].

## 2.1.6 Mécanismes de sécurité au niveau du jeu d'instructions

Outre l'ajout de mécanismes d'isolation permettant d'implémenter des TEE ou des enclaves, différents projets ont proposé d'implémenter des mécanismes de sécurité au niveau de l'ISA (Instruction Set Architecture, jeu d'instructions) des processeurs.
Afin d'implémenter la propagation et la vérification des étiquettes dans un coprocesseur externe, plusieurs approches ont été proposées. Raksha [122] est un des premiers travaux à proposer de découpler le mécanisme de DIFT de l'implémentation du processeur principal. Pour combler le fossé sémantique lié à l'isolation, il est nécessaire d'envoyer la suite des instructions générant des flux d'information vers le coprocesseur. L'approche repose sur la mise en place d'un mécanisme de traces qui permet d'envoyer ces informations au moniteur DIFT. Rasksha nécessite quelques modifications de la microarchitecture du processeur principal pour mettre en place ce mécanisme de traces, ce qui limite son adoption.

Des travaux ont proposé d'utiliser les mécanismes de traces fournis par les processeurs disponibles sur le marché. Ainsi Lee *et al*. utilisent le mécanisme ARM ETM (Embedded Trace Macrocell) disponible sur la plupart des processeurs ARM destinés aux systèmes embarqués [123]. Ce mécanisme permet de tracer toutes les instructions exécutées.

Toutefois, sur les processeurs plus puissants, utilisés typiquement sur les *smartphone*, ce mécanisme n'est pas implémenté car le débit des traces serait trop important pour pouvoir être traité en temps réel sans impacter les performances. ARM implémente à la place le mécanisme PTM (Program Trace Macrocell) qui ne trace que les exceptions et les sauts. Il est donc nécessaire de retrouver les séquences d'instructions exécutées linéairement dans un bloc de base. HardBlare implémente le DIFT en utilisant le mécanisme de traces ARM PTM. Il complète les informations manquantes, nécessaires au DIFT, en utilisant une préanalyse statique et une instrumentation des applications lors de la compilation. Ces informations manquantes sont stockées sous forme d'annotations et envoyées au coprocesseur lors du chargement du programme exécutable [93].

Ces différentes approches se focalisent sur la vérification d'une politique de sécurité. PHMon [124] propose un mécanisme générique qui permet de surveiller différents types de politiques de sécurité et ainsi de rentabiliser les mécanismes matériels ajoutés à l'architecture.

### 2.1.5.3 Limites des moniteurs externes

Les approches qui reposent sur un moniteur externe et déclenchent des vérifications lors de certains événements sont potentiellement vulnérables à des attaques en évasion. L'attaquant peut inférer le type d'événements capturés ainsi que la fréquence des vérifications afin de conduire son attaque entre deux vérifications et effacer ses traces [125].

En outre, les moniteurs ne peuvent observer que la mémoire physique. Des attaques en évasion sont donc possibles en modifiant la correspondance entre mémoire virtuelle et physique, au dépend du moniteur [126]. Enfin, les données qui résident dans le cache peuvent échapper à la vérification, si le moniteur se contente de surveiller la mémoire [127]. Ces limitations peuvent également concerner les moniteurs isolés à l'aide de TrustZone [128].

## 2.1.6 Mécanismes de sécurité au niveau du jeu d'instructions

Outre l'ajout de mécanismes d'isolation permettant d'implémenter des TEE ou des enclaves, différents projets ont proposé d'implémenter des mécanismes de sécurité au niveau de l'ISA (*Instruction Set Architecture*, jeu d'instructions) des processeurs.
### 2.1.6.1 Protection du noyau du système d'exploitation

Le noyau des OS est une cible de choix pour les attaquants puisqu'il s'exécute dans un contexte privilégié. Entre outre, les OS tels que Microsoft Windows, Linux ou Apple Mac OSX sont développés dans des langages peu robustes aux attaques liées à la gestion de la mémoire, tel que le C. Ils comportent en outre de nombreuses fonctionnalités et représentent une quantité de code importante. De fait, ils font l'objet régulièrement de vulnérabilités qui sont exploitées par des attaquants pour élever leurs privilèges et mettre en place des rootkit.

Les fabricants de microprocesseurs ont donc proposé des extensions de leur ISA afin de renforcer la protection du noyau face à ces attaques. Ainsi, Intel a intégré l'extension SMEP (Supervisor Mode Execution Prevention) à ses microprocesseurs qui empêche le noyau d'exécuter du code situé dans une page de l'espace utilisateur. Cette extension est également disponible sur les processeurs AMD. Elle permet d'éviter les attaques qui détournent le flot d'exécution du noyau vers du code situé en espace utilisateur, sous la maîtrise de l'attaquant (attaques appelées return-to-user ou ret2usr). ARM propose un mécanisme similaire : PXN (Privilege Execute Never).

Ces mécanismes peuvent être déployés facilement car, en général, le noyau ne doit pas légitimement exécuter du code utilisateur. SMAP (Supervisor Mode Access Prevention) est un mécanisme complémentaire, disponible sur les processeurs Intel et AMD, qui interdit de manière générale au noyau d'accéder aux pages mémoire de l'espace utilisateur. Toutefois, ce mécanisme ne peut être activé en permanence car le noyau doit parfois accéder légitimement à l'espace des processus utilisateurs, notamment dans le cadre de certains appels système (par exemple, pour un appel système read, le noyau doit recopier les données lues dans le fichier vers un tampon situé dans la mémoire du processus). Le code du noyau doit donc être modifié pour activer et désactiver ce mécanisme suivant les besoins. ARM dispose d'un mécanisme similaire : PAN (Privilege Access Never).

Toutefois, des chercheurs ont montré que ces mécanismes ne sont pas suffisants car le noyau partage implicitement des espaces mémoire avec les processus [129].

Des chercheurs ont également utilisé SMAP pour mettre en œuvre de l'isolation interne aux processus [130], avec de meilleures performances que les mécanismes dédiés à cet usage comme Intel MPK (Memory Protection Keys), qui sont présentés par la suite.

### 2.1.6.2 Vérification de l'intégrité du flot de contrôle

Une part importante des applications et du code privilégié (OS, hyperviseur, firmware UEFI, etc.) est toujours développée à l'aide de langage offrant peu de protection contre les attaques de corruption de la mémoire. Différents mécanismes ont été peu à peu adoptés pour lutter contre ces attaques. Ces mécanismes sont implémentés au niveau du matériel (pages non exécutables pour éviter l'injection de code), de l'OS (ASLR (Address Space Layout Randomization, distribution aléatoire de l'espace d'adressage) pour complexifier l'utilisation du ROP) et du compilateur (utilisation de canaris pour détecter les dépassements de pile).

De nos jours, ces contre-mesures permettent de se prémunir efficacement contre les attaques de corruption de la mémoire utilisant de l'injection de code. Toutefois, l'utilisation du ROP reste possible, notamment lorsque l'ASLR est mise en défaut (suite à des fuites
### 2.1.6.1 Protection du noyau du système d'exploitation

Le noyau des OS est une cible de choix pour les attaquants puisqu'il s'exécute dans un contexte privilégié. Entre outre, les OS tels que Microsoft Windows, Linux ou Apple Mac OSX sont développés dans des langages peu robustes aux attaques liées à la gestion de la mémoire, tel que le C. Ils comportent en outre de nombreuses fonctionnalités et représentent une quantité de code importante. De fait, ils font l'objet régulièrement de vulnérabilités qui sont exploitées par des attaquants pour élever leurs privilèges et mettre en place des rootkit.

Les fabricants de microprocesseurs ont donc proposé des extensions de leur ISA afin de renforcer la protection du noyau face à ces attaques. Ainsi, Intel a intégré l'extension SMEP (Supervisor Mode Execution Prevention) à ses microprocesseurs qui empêche le noyau d'exécuter du code situé dans une page de l'espace utilisateur. Cette extension est également disponible sur les processeurs AMD. Elle permet d'éviter les attaques qui détournent le flot d'exécution du noyau vers du code situé en espace utilisateur, sous la maîtrise de l'attaquant (attaques appelées return-to-user ou ret2usr). ARM propose un mécanisme similaire : PXN (Privilege Execute Never).

Ces mécanismes peuvent être déployés facilement car, en général, le noyau ne doit pas légitimement exécuter du code utilisateur. SMAP (Supervisor Mode Access Prevention) est un mécanisme complémentaire, disponible sur les processeurs Intel et AMD, qui interdit de manière générale au noyau d'accéder aux pages mémoire de l'espace utilisateur. Toutefois, ce mécanisme ne peut être activé en permanence car le noyau doit parfois accéder légitimement à l'espace des processus utilisateurs, notamment dans le cadre de certains appels système (par exemple, pour un appel système read, le noyau doit recopier les données lues dans le fichier vers un tampon situé dans la mémoire du processus). Le code du noyau doit donc être modifié pour activer et désactiver ce mécanisme suivant les besoins. ARM dispose d'un mécanisme similaire : PAN (Privilege Access Never).

Toutefois, des chercheurs ont montré que ces mécanismes ne sont pas suffisants car le noyau partage implicitement des espaces mémoire avec les processus [129].

Des chercheurs ont également utilisé SMAP pour mettre en œuvre de l'isolation interne aux processus [130], avec de meilleures performances que les mécanismes dédiés à cet usage comme Intel MPK (Memory Protection Keys), qui sont présentés par la suite.

### 2.1.6.2 Vérification de l'intégrité du flot de contrôle

Une part importante des applications et du code privilégié (OS, hyperviseur, firmware UEFI, etc.) est toujours développée à l'aide de langage offrant peu de protection contre les attaques de corruption de la mémoire. Différents mécanismes ont été peu à peu adoptés pour lutter contre ces attaques. Ces mécanismes sont implémentés au niveau du matériel (pages non exécutables pour éviter l'injection de code), de l'OS (ASLR (Address Space Layout Randomization, distribution aléatoire de l'espace d'adressage) pour complexifier l'utilisation du ROP) et du compilateur (utilisation de canaris pour détecter les dépassements de pile).

De nos jours, ces contre-mesures permettent de se prémunir efficacement contre les attaques de corruption de la mémoire utilisant de l'injection de code. Toutefois, l'utilisation du ROP reste possible, notamment lorsque l'ASLR est mise en défaut (suite à des fuites
mémoire ou à des attaques par canaux auxiliaires). Dans ce contexte, l'utilisation du CFI paraît prometteuse. Afin de limiter l'impact à l'exécution de cette protection, des travaux se sont intéressés à étendre l'ISA afin d'implémenter matériellement la vérification d'une politique CFI.

Ainsi, Davi et al. ont proposé d'ajouter deux nouvelles instructions permettant d'étiqueter les branchements et les retours de fonction afin d'implémenter une politique CFI [131]. Plus précisément, ils cherchent à se prémunir contre les attaques détournant le flot de contrôle au niveau de l'adresse de retour des fonctions (*backward edge CFI*). Ils ont ensuite étendu ces travaux en proposant et en évaluant l'approche sur des processeurs *softcore* Intel Siskiyou Peak et LEON3 [132]. Des travaux se sont intéressés plus globalement à protéger à la fois l'adresse de retour et les appels indirects de fonction (qui utilise des pointeurs de fonction) [133].

Ces approches nécessitent de modifier la microarchitecture et ne s'appliquent pas aux
processeurs existants. Toutefois, les fabricants de processeurs ont intégré récemment un
support du CFI au sein de leurs produits. Ainsi, Intel a développé CET (Control-flow
Enforcement Technology) [134, 135], une extension permettant de mettre en place du
CFI à gros grain. L'approche permet de protéger les retours de fonction à l'aide d'une
shadow stack et les appels indirects de fonction à l'aide d'une instruction spécifique. Plus
précisément, tout branchement doit sauter au début d'une fonction valide, ce qui limite
le ROP. Une instruction spécifique sert à identifier le début valide d'une fonction (la cible
d'un branchement doit toujours correspondre à cette instruction). Toutefois, l'attaquant
peut toujours contourner le flot de contrôle en sautant à une adresse marquant le début
d'une fonction légitime.

ARM a également proposé une approche similaire avec sa solution BTI (Branch Target Indicators) [136]. Toutefois, cette technologie n'implémente pas de *shadow stack* et ne protège pas les adresses de retour.

2.1.6.3 Isolation interne aux processus

Les processeurs modernes proposent de nombreux mécanismes d'isolation (niveau de privilège d'exécution, extension de virtualisation, mécanismes d'enclaves, etc.). Cependant, ces mécanismes ne permettent pas aisément de cloisonner le code appartenant à un même processus, sans nécessiter des changements de contexte coûteux en termes d'impacts sur les performances. Un tel besoin existe car certaines applications implémentent de nombreuses fonctionnalités et comprennent de nombreuses lignes de code. Une vulnérabilité dans le code de l'application peut donc permettre à un attaquant d'accéder à l'ensemble des données de l'application.

Des chercheurs ont proposé d'utiliser le niveau de privilèges intermédiaire des processeurs x86 (*ring* 2), qui n'est en général pas utilisé dans les OS modernes, afin d'implémenter un mécanisme permettant de séparer les applications en deux espaces isolés [137]. Cette approche a l'avantage d'être compatible avec tous les processeurs de l'architectures x86 et ne nécessite pas de mécanisme additionnel. Toutefois, il ne fournit que deux environnements isolés pour chaque processus.

Intel a également développé MPK, un mécanisme permettant de restreindre l'accès d'un thread à un groupe de pages. Plusieurs travaux de recherche ont proposé d'utiliser ce mécanisme pour isoler le code à l'intérieur d'un même processus. Park et al. ont notamment
mémoire ou à des attaques par canaux auxiliaires). Dans ce contexte, l'utilisation du CFI paraît prometteuse. Afin de limiter l'impact à l'exécution de cette protection, des travaux se sont intéressés à étendre l'ISA afin d'implémenter matériellement la vérification d'une politique CFI.

Ainsi, Davi et al. ont proposé d'ajouter deux nouvelles instructions permettant d'étiqueter les branchements et les retours de fonction afin d'implémenter une politique CFI [131]. Plus précisément, ils cherchent à se prémunir contre les attaques détournant le flot de contrôle au niveau de l'adresse de retour des fonctions (*backward edge CFI*). Ils ont ensuite étendu ces travaux en proposant et en évaluant l'approche sur des processeurs *softcore* Intel Siskiyou Peak et LEON3 [132]. Des travaux se sont intéressés plus globalement à protéger à la fois l'adresse de retour et les appels indirects de fonction (qui utilise des pointeurs de fonction) [133].

Ces approches nécessitent de modifier la microarchitecture et ne s'appliquent pas aux
processeurs existants. Toutefois, les fabricants de processeurs ont intégré récemment un
support du CFI au sein de leurs produits. Ainsi, Intel a développé CET (Control-flow
Enforcement Technology) [134, 135], une extension permettant de mettre en place du
CFI à gros grain. L'approche permet de protéger les retours de fonction à l'aide d'une
shadow stack et les appels indirects de fonction à l'aide d'une instruction spécifique. Plus
précisément, tout branchement doit sauter au début d'une fonction valide, ce qui limite
le ROP. Une instruction spécifique sert à identifier le début valide d'une fonction (la cible
d'un branchement doit toujours correspondre à cette instruction). Toutefois, l'attaquant
peut toujours contourner le flot de contrôle en sautant à une adresse marquant le début
d'une fonction légitime.

ARM a également proposé une approche similaire avec sa solution BTI (Branch Target Indicators) [136]. Toutefois, cette technologie n'implémente pas de *shadow stack* et ne protège pas les adresses de retour.

2.1.6.3 Isolation interne aux processus

Les processeurs modernes proposent de nombreux mécanismes d'isolation (niveau de privilège d'exécution, extension de virtualisation, mécanismes d'enclaves, etc.). Cependant, ces mécanismes ne permettent pas aisément de cloisonner le code appartenant à un même processus, sans nécessiter des changements de contexte coûteux en termes d'impacts sur les performances. Un tel besoin existe car certaines applications implémentent de nombreuses fonctionnalités et comprennent de nombreuses lignes de code. Une vulnérabilité dans le code de l'application peut donc permettre à un attaquant d'accéder à l'ensemble des données de l'application.

Des chercheurs ont proposé d'utiliser le niveau de privilèges intermédiaire des processeurs x86 (*ring* 2), qui n'est en général pas utilisé dans les OS modernes, afin d'implémenter un mécanisme permettant de séparer les applications en deux espaces isolés [137]. Cette approche a l'avantage d'être compatible avec tous les processeurs de l'architectures x86 et ne nécessite pas de mécanisme additionnel. Toutefois, il ne fournit que deux environnements isolés pour chaque processus.

Intel a également développé MPK, un mécanisme permettant de restreindre l'accès d'un *thread* à un groupe de pages. Plusieurs travaux de recherche ont proposé d'utiliser ce mécanisme pour isoler le code à l'intérieur d'un même processus. Park *et al.* ont notamment
proposé libmpk, une bibliothèque qui abstrait le mécanisme matériel, renforce la sécurité et comble certaines lacunes du mécanisme, notamment le nombre limité de clés [138]. Les auteurs ont appliqué leur approche à différents programmes dont OpenSSL et différents compilateurs JavaScript.

ERIM [139] combine l'utilisation de MPK avec une analyse statique du code binaire des applications afin de s'assurer qu'il ne comprend pas de séquence d'instructions, exécutables par une attaque ROP, permettant de contourner l'isolation.

D'autres cas d'usages ont été proposés. Ainsi Wang et al. proposent d'utiliser MPX (Memory Protection Extensions) pour isoler un moniteur de référence au sein des applications [140]. A titre d'exemple, ils ont implémenté une approche de Multi-Va-riant eXecution (MVX), qui consiste à comparer les résultats de l'exécution de différentes implémentations d'une même fonctionnalité (diversité fonctionnelle).

Ces approches sont intéressantes mais ne peuvent être implémentées que sur les processeur x86 disposant de MPK (les processeurs AMD récents supportent maintenant également cette fonctionnalité). En outre, Connor et al. ont évalué le niveau de sécurité apporté par ces mécanismes d'isolation [141]. Ils ont démontré que cette isolation pouvait être contournée par des attaques de type *confused deputy* utilisant l'OS.

Mogosanu et al. ont également présenté un mécanisme d'isolation à grain fin interne au processus, complémentaire de la pagination [142]. Ils ont proposé une implémentation de leur approche sur un *softcore* RISC-V. Leur approche vise notamment à minimiser le surcoût lié à l'utilisation du cloisonnement. Schrammel et al. ont proposé un mécanisme d'isolation intra-processus pour les processeurs RISC-V qui est à la fois robuste en ce qui concerne la sécurité (qui ne nécessite pas, par exemple, d'analyser le code binaire de l'application) et performant [143]. Les auteurs ont implémenté leur approche sur un *softcore* RISC-V et fournissent un mode d'émulation pour x86 utilisant MPK.

### 2.1.6.4 Vérification de la validité des pointeurs

Les langages bas niveau comme le C offrent peu de garanties sur la gestion de la mémoire. En particulier, l'utilisation de pointeurs peut conduire à des vulnérabilités si le développeur n'inclut pas explicitement des vérifications dans le code de son application. L'absence de vérification peut typiquement conduire à des vulnérabilités de type *buffer overflow*. Le pointeur est alors utilisé pour accéder à la mémoire en dehors des zones réservées par le développeur.

Pour lutter contre les attaques exploitant ces vulnérabilités, des travaux ont proposé des extensions matérielles permettant de vérifier la validité des pointeurs avant leur utilisation. L'objectif est de réduire le surcoût à l'exécution lié à la vérification, par rapport à des solutions purement logicielles. Il s'agit typiquement d'associer aux pointeurs des métadonnées permettant de déterminer leur domaine de validité (par exemple, les bornes d'un tableau).

Kwon et al. ont par exemple proposé d'encoder ces métadonnés de manière adjacente aux bits d'adresses pour former un *fat pointer* [144]. Ils ont pour cela conçu un processeur avec une architecture et une microarchitecture spécifique. Leur approche permet en outre d'associer un type (valeur entière, pointeur valide, pointeur invalide, etc.) à chaque mot manipulé par le processeur. Cette approche, développée dans le cadre du projet CRA-SH/SAFE, leur a permis de mettre au point une architecture générique [145] permettant
proposé libmpk, une bibliothèque qui abstrait le mécanisme matériel, renforce la sécurité et comble certaines lacunes du mécanisme, notamment le nombre limité de clés [138]. Les auteurs ont appliqué leur approche à différents programmes dont OpenSSL et différents compilateurs JavaScript.

ERIM [139] combine l'utilisation de MPK avec une analyse statique du code binaire des applications afin de s'assurer qu'il ne comprend pas de séquence d'instructions, exécutables par une attaque ROP, permettant de contourner l'isolation.

D'autres cas d'usages ont été proposés. Ainsi Wang et al. proposent d'utiliser MPX (Memory Protection Extensions) pour isoler un moniteur de référence au sein des applications [140]. A titre d'exemple, ils ont implémenté une approche de Multi-Va-riant eXecution (MVX), qui consiste à comparer les résultats de l'exécution de différentes implémentations d'une même fonctionnalité (diversité fonctionnelle).

Ces approches sont intéressantes mais ne peuvent être implémentées que sur les processeur x86 disposant de MPK (les processeurs AMD récents supportent maintenant également cette fonctionnalité). En outre, Connor et al. ont évalué le niveau de sécurité apporté par ces mécanismes d'isolation [141]. Ils ont démontré que cette isolation pouvait être contournée par des attaques de type *confused deputy* utilisant l'OS.

Mogosanu et al. ont également présenté un mécanisme d'isolation à grain fin interne au processus, complémentaire de la pagination [142]. Ils ont proposé une implémentation de leur approche sur un *softcore* RISC-V. Leur approche vise notamment à minimiser le surcoût lié à l'utilisation du cloisonnement. Schrammel et al. ont proposé un mécanisme d'isolation intra-processus pour les processeurs RISC-V qui est à la fois robuste en ce qui concerne la sécurité (qui ne nécessite pas, par exemple, d'analyser le code binaire de l'application) et performant [143]. Les auteurs ont implémenté leur approche sur un *softcore* RISC-V et fournissent un mode d'émulation pour x86 utilisant MPK.

### 2.1.6.4 Vérification de la validité des pointeurs

Les langages bas niveau comme le C offrent peu de garanties sur la gestion de la mémoire. En particulier, l'utilisation de pointeurs peut conduire à des vulnérabilités si le développeur n'inclut pas explicitement des vérifications dans le code de son application. L'absence de vérification peut typiquement conduire à des vulnérabilités de type *buffer overflow*. Le pointeur est alors utilisé pour accéder à la mémoire en dehors des zones réservées par le développeur.

Pour lutter contre les attaques exploitant ces vulnérabilités, des travaux ont proposé des extensions matérielles permettant de vérifier la validité des pointeurs avant leur utilisation. L'objectif est de réduire le surcoût à l'exécution lié à la vérification, par rapport à des solutions purement logicielles. Il s'agit typiquement d'associer aux pointeurs des métadonnées permettant de déterminer leur domaine de validité (par exemple, les bornes d'un tableau).

Kwon et al. ont par exemple proposé d'encoder ces métadonnés de manière adjacente aux bits d'adresses pour former un *fat pointer* [144]. Ils ont pour cela conçu un processeur avec une architecture et une microarchitecture spécifique. Leur approche permet en outre d'associer un type (valeur entière, pointeur valide, pointeur invalide, etc.) à chaque mot manipulé par le processeur. Cette approche, développée dans le cadre du projet CRA-SH/SAFE, leur a permis de mettre au point une architecture générique [145] permettant
de mettre en œuvre différents types de politiques de sécurité [146]. Cela permet, entre autres, de protéger les données sur la pile [147].

Cette approche est intéressante car elle fournit un support matériel générique, permettant d'implémenter différents mécanismes et donc de contrer un vaste spectre d'attaques. Toutefois, il s'agit d'une architecture très différente des architectures disponibles sur le marché. Tous les composants logiciels (OS, compilateur, applications, etc.) doivent être redéveloppés à cet effet, ce qui limite l'adoption d'une telle approche.

Les constructeurs de microprocesseurs ont également proposé des extensions matérielles permettant de vérifier la validité des pointeurs. Ainsi, Intel a proposé MPX, une extension permettant de spécifier et vérifier les bornes de validité des pointeurs. Cette extension est notamment utilisée dans le projet LMP [148] pour protéger la *shadow stack* pour la vérification du CFI. Les auteurs notent cependant que certaines fonctionnalités de MPX ont un surcoût important à l'exécution. Ce résultat a été confirmé par Oleksenko et al. qui ont réalisé une analyse expérimentale détaillée de MPX et de ses performances [149]. Les auteurs sont arrivés à la conclusion surprenante que cette solution matérielle n'offre pas de meilleurs performances que les solutions purement logicielles. Depuis, le support de MPX dans le compilateur GCC et le noyau Linux a été arrêté et Intel n'intègre plus cette extension dans ses nouveaux processeurs.

ARM propose également les extensions PA (Pointer Authentication) et MTE (Memory Tagging Extension) dans son architecture ARMv8-A. Ces deux fonctionnalités utilisent les bits de poids fort des adresses virtuelles qui ne sont pas utilisés pour encoder l'adresse. En effet, les adresses virtuelles sont, par exemple, encodées au maximum sur 39 bits pour l'architecture ARM 64 bits sous Linux. Ces deux fonctionnalités partagent l'espace restant, quand elles sont utilisées de concert.

MTE, introduite dans l'architecture ARMv8.5-A, permet d'associer une étiquette (*tag*) aux données stockées en mémoire ainsi qu'aux pointeurs permettant de manipuler ces données. Si le programme manipule des données à l'aide d'un pointeur possédant une étiquette différente de celle des données, une exception est levée. La solution stocke les étiquettes de la mémoire en dédiant 4 bits pour chaque mot de 16 octets en mémoire. Les étiquettes des pointeurs sont stockées dans les bits de poids fort de l'adresse. Des instructions ont été ajoutées pour contrôler les étiquettes.

Ce type de mécanisme permet par exemple de s'assurer que les pointeurs ne peuvent être utilisés pour accéder à une zone non allouée ou, de manière générale, à une zone possédant une étiquette différente. Cela réduit la faisabilité des attaques exploitant des corruptions mémoire. Toutefois, le nombre d'étiquettes étant réduit, l'attaquant peut toujours utiliser un pointeur pour manipuler des données en dehors des bornes mais vers une zone disposant de la même étiquette. MTE est maintenant supportée par le noyau Linux et le compilateur LLVM mais aucun processeur commercialisé à la date de rédaction de ce rapport ne dispose de cette fonctionnalité.

PA, introduite dans l'architecture ARMv8.3-A, permet d'authentifier les pointeurs en leur associant un MAC (Message Authentication Code) appelé PAC (Pointer Authentication Code), situé lui aussi dans les bits de poids fort des adresses. Cette fonctionnalité est notamment implémentée sur le SoC Apple A12 utilisé dans les iPhone XS. Des instructions ont été ajoutées afin de créer et d'authentifier des PAC. Un pointeur créé de la sorte doit être authentifié avant de pouvoir être utilisé, sinon la traduction d'adresse génère
de mettre en œuvre différents types de politiques de sécurité [146]. Cela permet, entre autres, de protéger les données sur la pile [147].

Cette approche est intéressante car elle fournit un support matériel générique, permettant d'implémenter différents mécanismes et donc de contrer un vaste spectre d'attaques. Toutefois, il s'agit d'une architecture très différente des architectures disponibles sur le marché. Tous les composants logiciels (OS, compilateur, applications, etc.) doivent être redéveloppés à cet effet, ce qui limite l'adoption d'une telle approche.

Les constructeurs de microprocesseurs ont également proposé des extensions matérielles permettant de vérifier la validité des pointeurs. Ainsi, Intel a proposé MPX, une extension permettant de spécifier et vérifier les bornes de validité des pointeurs. Cette extension est notamment utilisée dans le projet LMP [148] pour protéger la *shadow stack* pour la vérification du CFI. Les auteurs notent cependant que certaines fonctionnalités de MPX ont un surcoût important à l'exécution. Ce résultat a été confirmé par Oleksenko et al. qui ont réalisé une analyse expérimentale détaillée de MPX et de ses performances [149]. Les auteurs sont arrivés à la conclusion surprenante que cette solution matérielle n'offre pas de meilleurs performances que les solutions purement logicielles. Depuis, le support de MPX dans le compilateur GCC et le noyau Linux a été arrêté et Intel n'intègre plus cette extension dans ses nouveaux processeurs.

ARM propose également les extensions PA (Pointer Authentication) et MTE (Memory Tagging Extension) dans son architecture ARMv8-A. Ces deux fonctionnalités utilisent les bits de poids fort des adresses virtuelles qui ne sont pas utilisés pour encoder l'adresse. En effet, les adresses virtuelles sont, par exemple, encodées au maximum sur 39 bits pour l'architecture ARM 64 bits sous Linux. Ces deux fonctionnalités partagent l'espace restant, quand elles sont utilisées de concert.

MTE, introduite dans l'architecture ARMv8.5-A, permet d'associer une étiquette (*tag*) aux données stockées en mémoire ainsi qu'aux pointeurs permettant de manipuler ces données. Si le programme manipule des données à l'aide d'un pointeur possédant une étiquette différente de celle des données, une exception est levée. La solution stocke les étiquettes de la mémoire en dédiant 4 bits pour chaque mot de 16 octets en mémoire. Les étiquettes des pointeurs sont stockées dans les bits de poids fort de l'adresse. Des instructions ont été ajoutées pour contrôler les étiquettes.

Ce type de mécanisme permet par exemple de s'assurer que les pointeurs ne peuvent être utilisés pour accéder à une zone non allouée ou, de manière générale, à une zone possédant une étiquette différente. Cela réduit la faisabilité des attaques exploitant des corruptions mémoire. Toutefois, le nombre d'étiquettes étant réduit, l'attaquant peut toujours utiliser un pointeur pour manipuler des données en dehors des bornes mais vers une zone disposant de la même étiquette. MTE est maintenant supportée par le noyau Linux et le compilateur LLVM mais aucun processeur commercialisé à la date de rédaction de ce rapport ne dispose de cette fonctionnalité.

PA, introduite dans l'architecture ARMv8.3-A, permet d'authentifier les pointeurs en leur associant un MAC (Message Authentication Code) appelé PAC (Pointer Authentication Code), situé lui aussi dans les bits de poids fort des adresses. Cette fonctionnalité est notamment implémentée sur le SoC Apple A12 utilisé dans les iPhone XS. Des instructions ont été ajoutées afin de créer et d'authentifier des PAC. Un pointeur créé de la sorte doit être authentifié avant de pouvoir être utilisé, sinon la traduction d'adresse génère
une faute de page. Cette protection permet d'éviter qu'un attaquant puisse modifier ou forger un pointeur à partir d'un débordement de tampon, par exemple. Cette extension a notamment été utilisée par Liljestrand et al. [150]. Les auteurs proposent une solution permettant de résister aux attaques visant à forger ou réutiliser des PAC.

Le projet CHERI [94], développé principalement par des chercheurs de l'université de Cambridge, étend les principes d'étiquetage de la mémoire et de vérification des bornes des pointeurs présentés précédemment. Il utilise pour cela un mécanisme plus générique de capacités, qui permet également d'associer des permissions aux pointeurs. Cette approche permet de contrer un large spectre d'attaques exploitant des corruptions mémoire [151, 152]. Les chercheurs ont implémenté dans un premier temps cette approche sur un *soft-core* spécifique. Ils ont également établi une collaboration avec ARM dans le cadre du projet Morello [153]. ARM a proposé une modification de son architecture supportant les extensions de CHERI et va développer un processeur expérimental implémentant cette architecture. Toutefois, il s'agit seulement pour l'instant d'un projet de recherche et ARM ne s'engage pas à inclure ce support dans ses futurs produits.

### 2.1.6.5 Autres approches

Des travaux se sont intéressés à implémenter d'autres types de mécanismes de sécurité au niveau de l'ISA.

Ainsi, Zagiebovlo et al. ont proposé une ISA permettant de contrôler les flux d'informations, y compris ceux résultants de canaux auxiliaires temporels [154]. Pour cela, l'architecture associe des labels aux données manipulées par le processeur. Ce dernier doit propager et vérifier les étiquettes lors de l'exécution des instructions. L'objectif est de définir une ISA que doivent respecter des processeurs implémentant du DIFT. Ce type de processeur peut ainsi être utilisé par des logiciels souhaitant contrôler leur flux d'informations. L'approche n'a toutefois pas donné lieu à une implémentation.

Le projet HDFI [155] fournit un support matériel pour implémenter du DFI (Data Flow Integrity). L'approche, proposée initialement par des chercheurs de Microsoft Research, consiste à vérifier que les accès mémoire respectent le graphe de flot de données de l'application. Cette approche nécessite de déterminer un tel graphe et d'annoter le programme en associant, à chaque instruction de lecture, l'ensemble des instructions du programme qui ont pu légitimement écrire cette donnée. La vérification consiste à associer une étiquette à chaque donnée lors de son écriture puis à vérifier lors, de chaque lecture, que l'étiquette provient bien d'une écriture légitime. HDFI permet d'accélérer matériellement cette vérification. Les auteurs proposent d'étendre l'ISA RISC-V avec des instructions permettant d'étiquer les données et de vérifier les étiquettes. Ils ont implémenté leur approche sur un *softcore* RISC-V. Toutefois, l'approche ne permet de stoker des étiquettes que sur un bit, ce qui permet tout de même d'implémenter différents types de protection mais diverge significativement de l'approche originale.

Des approches ont également proposé d'implémenter diverses formes de diversifications au niveau du jeu d'instructions. Il s'agit de diversifier la forme du code ou des données à l'exécution afin que l'attaquant ne puisse prédire cette forme lors d'une attaque de type ROP ou *data-only attacks*, qui vise à modifier ou lire les valeurs des variables de façon illégitime.

HARD [156] implémente une approche similaire au DFI. Il s'agit de chiffrer les variables
une faute de page. Cette protection permet d'éviter qu'un attaquant puisse modifier ou forger un pointeur à partir d'un débordement de tampon, par exemple. Cette extension a notamment été utilisée par Liljestrand et al. [150]. Les auteurs proposent une solution permettant de résister aux attaques visant à forger ou réutiliser des PAC.

Le projet CHERI [94], développé principalement par des chercheurs de l'université de Cambridge, étend les principes d'étiquetage de la mémoire et de vérification des bornes des pointeurs présentés précédemment. Il utilise pour cela un mécanisme plus générique de capacités, qui permet également d'associer des permissions aux pointeurs. Cette approche permet de contrer un large spectre d'attaques exploitant des corruptions mémoire [151, 152]. Les chercheurs ont implémenté dans un premier temps cette approche sur un *soft-core* spécifique. Ils ont également établi une collaboration avec ARM dans le cadre du projet Morello [153]. ARM a proposé une modification de son architecture supportant les extensions de CHERI et va développer un processeur expérimental implémentant cette architecture. Toutefois, il s'agit seulement pour l'instant d'un projet de recherche et ARM ne s'engage pas à inclure ce support dans ses futurs produits.

### 2.1.6.5 Autres approches

Des travaux se sont intéressés à implémenter d'autres types de mécanismes de sécurité au niveau de l'ISA.

Ainsi, Zagieboylo et al. ont proposé une ISA permettant de contrôler les flux d'informations, y compris ceux résultants de canaux auxiliaires temporels [154]. Pour cela, l'architecture associe des labels aux données manipulées par le processeur. Ce dernier doit propager et vérifier les étiquettes lors de l'exécution des instructions. L'objectif est de définir une ISA que doivent respecter des processeurs implémentant du DIFT. Ce type de processeur peut ainsi être utilisé par des logiciels souhaitant contrôler leur flux d'informations. L'approche n'a toutefois pas donné lieu à une implémentation.

Le projet HDFI [155] fournit un support matériel pour implémenter du DFI (Data Flow Integrity). L'approche, proposée initialement par des chercheurs de Microsoft Research, consiste à vérifier que les accès mémoire respectent le graphe de flot de données de l'application. Cette approche nécessite de déterminer un tel graphe et d'annoter le programme en associant, à chaque instruction de lecture, l'ensemble des instructions du programme qui ont pu légitimement écrire cette donnée. La vérification consiste à associer une étiquette à chaque donnée lors de son écriture puis à vérifier lors, de chaque lecture, que l'étiquette provient bien d'une écriture légitime. HDFI permet d'accélérer matériellement cette vérification. Les auteurs proposent d'étendre l'ISA RISC-V avec des instructions permettant d'étiquer les données et de vérifier les étiquettes. Ils ont implémenté leur approche sur un *softcore* RISC-V. Toutefois, l'approche ne permet de stoker des étiquettes que sur un bit, ce qui permet tout de même d'implémenter différents types de protection mais diverge significativement de l'approche originale.

Des approches ont également proposé d'implémenter diverses formes de diversifications au niveau du jeu d'instructions. Il s'agit de diversifier la forme du code ou des données à l'exécution afin que l'attaquant ne puisse prédire cette forme lors d'une attaque de type ROP ou *data-only attacks*, qui vise à modifier ou lire les valeurs des variables de façon illégitime.

HARD [156] implémente une approche similaire au DFI. Il s'agit de chiffrer les variables
avec des clés choisies aléatoirement mais en s'assurant que des variables appartenant à une même classe d'équivalence soient chiffrées avec la même clé. Cette approche permet de protéger le code contre les data-only attacks.

Wang et al. ont proposé une architecture composée de deux ordinateurs, utilisant différentes ISA, reliés par un bus InfiniBand [157]. Cette architecture possède un jeu d'instructions hétérogènes et permet d'exécuter des applications qui peuvent utiliser l'une ou l'autre des ISA. L'application peut ainsi s'exécuter sur les deux ordinateurs et comparer les résultats (diversification) ou alterner aléatoirement entre les deux ISA.

De Clercq et al. proposent une approche d'ISR (Instruction Set Randomization) dont l'objectif est de contrer les attaques par injection de code et de type ROP [158]. Pour cela, le compilateur chiffre les instructions avec des clés dépendant du flot de contrôle. A l'exécution, le processeur déchiffre les instructions à la volée. Cette approche permet de mettre en œuvre un forme de CFI. Les auteurs visent le domaine des systèmes embarqués et ont implémenté leur approche sur un softcore LEON3.

Yu et al. ont proposé une architecture facilitant le développement d'applications constant-time, dont le temps d'exécution ne varie pas en fonction de la valeur des secrets [159]. Cette approche permet de lutter contre les attaques par canaux auxiliaires temporels. Les auteurs évaluent également leur approche en fournissant une microarchitecture implémentant cette ISA.

### 2.1.7 Mécanismes de traces et compteurs de performance

Les approches présentées dans la section précédente nécessitent de modifier l'ISA et la microarchitecture. D'autres approches ont à l'inverse proposé d'utiliser les fonctionnalités existantes des processeurs afin d'implémenter des protections contre les attaques logicielles. Des travaux se sont notamment intéressés à l'utilisation des mécanismes de traces et aux compteurs de performances. Ces mécanismes ont initialement été introduits pour des besoins de mise au point et de profilage des applications. Toutefois, leur usage peut être détourné pour implémenter des mécanismes de sécurité.

Sur l'architecture x86, des travaux utilisent ainsi le mécanisme de trace Intel PT [160] qui permet de tracer les branchements et les changements de contexte du processeur. Le mécanisme peut être configuré par le noyau de l'OS. Le processeur écrit les traces, qui sont fortement compressées, directement dans la mémoire physique. Ce mécanisme a notamment été utilisé pour implémenter une politique de CFI [161, 162] puisqu'il fournit des informations sur les branchements. En outre, Schumilo et al. ont proposé de l'utiliser pour réaliser du fuzzing au niveau du noyau de l'OS [163].

Les processeurs ARM disposent également de la technologie CoreSight [164, 165]. Suivant le type de processeur, le mécanisme de trace diffère. Pour les microcontrôleurs destinés aux systèmes embarqués, ARM intègre généralement un ETM qui permet de tracer toutes les instructions exécutées. En revanche, les processeurs applicatifs de type Cortex-A disposent d'un PTM qui, à l'instar d'Intel PT, ne permet de tracer que les branchements et les exceptions. Suivant le SoC et son implémentation, les traces peuvent être envoyées dans un buffer interne au SoC, ce qui permet d'y accéder depuis un programme exécuté sur le SoC, ou vers une interface de mise au point (interface JTAG). Certains SoC permettent également d'envoyer les traces vers un autre composant, par exemple un FPGA intégré comme dans le SoC ZYNQ de Xilinx.
avec des clés choisies aléatoirement mais en s'assurant que des variables appartenant à une même classe d'équivalence soient chiffrées avec la même clé. Cette approche permet de protéger le code contre les data-only attacks.

Wang et al. ont proposé une architecture composée de deux ordinateurs, utilisant différentes ISA, reliés par un bus InfiniBand [157]. Cette architecture possède un jeu d'instructions hétérogènes et permet d'exécuter des applications qui peuvent utiliser l'une ou l'autre des ISA. L'application peut ainsi s'exécuter sur les deux ordinateurs et comparer les résultats (diversification) ou alterner aléatoirement entre les deux ISA.

De Clercq et al. proposent une approche d'ISR (Instruction Set Randomization) dont l'objectif est de contrer les attaques par injection de code et de type ROP [158]. Pour cela, le compilateur chiffre les instructions avec des clés dépendant du flot de contrôle. A l'exécution, le processeur déchiffre les instructions à la volée. Cette approche permet de mettre en œuvre un forme de CFI. Les auteurs visent le domaine des systèmes embarqués et ont implémenté leur approche sur un softcore LEON3.

Yu et al. ont proposé une architecture facilitant le développement d'applications constant-time, dont le temps d'exécution ne varie pas en fonction de la valeur des secrets [159]. Cette approche permet de lutter contre les attaques par canaux auxiliaires temporels. Les auteurs évaluent également leur approche en fournissant une microarchitecture implémentant cette ISA.

## 2.1.7 Mécanismes de traces et compteurs de performance

Les approches présentées dans la section précédente nécessitent de modifier l'ISA et la microarchitecture. D'autres approches ont à l'inverse proposé d'utiliser les fonctionnalités existantes des processeurs afin d'implémenter des protections contre les attaques logicielles. Des travaux se sont notamment intéressés à l'utilisation des mécanismes de traces et aux compteurs de performances. Ces mécanismes ont initialement été introduits pour des besoins de mise au point et de profilage des applications. Toutefois, leur usage peut être détourné pour implémenter des mécanismes de sécurité.

Sur l'architecture x86, des travaux utilisent ainsi le mécanisme de trace Intel PT [160] qui permet de tracer les branchements et les changements de contexte du processeur. Le mécanisme peut être configuré par le noyau de l'OS. Le processeur écrit les traces, qui sont fortement compressées, directement dans la mémoire physique. Ce mécanisme a notamment été utilisé pour implémenter une politique de CFI [161, 162] puisqu'il fournit des informations sur les branchements. En outre, Schumilo et al. ont proposé de l'utiliser pour réaliser du fuzzing au niveau du noyau de l'OS [163].

Les processeurs ARM disposent également de la technologie CoreSight [164, 165]. Suivant le type de processeur, le mécanisme de trace diffère. Pour les microcontrôleurs destinés aux systèmes embarqués, ARM intègre généralement un ETM qui permet de tracer toutes les instructions exécutées. En revanche, les processeurs applicatifs de type Cortex-A disposent d'un PTM qui, à l'instar d'Intel PT, ne permet de tracer que les branchements et les exceptions. Suivant le SoC et son implémentation, les traces peuvent être envoyées dans un buffer interne au SoC, ce qui permet d'y accéder depuis un programme exécuté sur le SoC, ou vers une interface de mise au point (interface JTAG). Certains SoC permettent également d'envoyer les traces vers un autre composant, par exemple un FPGA intégré comme dans le SoC ZYNQ de Xilinx.
Ninja utilise ainsi l'ETM pour analyser des logiciels malveillants depuis un environnement isolé à l'aide de TrustZone [166]. Kargos utilise le PTM pour détecter les injections de code dans le noyau de l'OS. Cette approche apporte les mêmes garanties que Intel SMEP ou PXN mais elle n'induit pas de pénalité sur les performances [167]. HART utilise l'ETM pour protéger les modules du noyau de l'OS sans nécessiter de les recompiler [168]. Les auteurs utilisent ce mécanisme pour implémenter AddressSanitizer [169], une protection logicielle qui permet de vérifier les accès mémoire pour prévenir les attaques de dépassement de tampon et de use-after-free. Contrairement à l'approche logicielle, l'approche utilisant HART ne nécessite pas d'avoir accès au code source du module et peut donc être appliquée sur les modules propriétaires fournis par un tiers.

Ces mécanismes présentent également une menace potentielle pour la sécurité du code exécuté dans les environnements cloisonnés comme TrustZone. Le mécanisme de trace des processeurs ARM permet en effet de tracer le code exécuté en mode protégé, depuis l'espace non protégé. Cette fonctionnalité peut être verrouillée mais Ning et al. ont montré que ce verrouillage n'était souvent pas mis en place dans les produits du marché [170].

Des approches ont également exploré l'utilisation des compteurs de performances pour implémenter des mécanismes de sécurité, notamment de la détection d'intrusions ou de la détection de codes malveillants [171]. Das et al. dressent un état de l'art de ces approches [172]. Suite à une analyse détaillée de ces mécanismes et des garanties qu'ils peuvent fournir, les auteurs démontrent qu'ils doivent être utilisés avec prudence dans le contexte de la sécurité informatique. En effet, ces mécanismes n'ont pas été conçus pour cet usage et les auteurs démontrent qu'il est possible de réaliser des attaques en évasion sur les mécanismes de détection qui les utilisent.

## 2.1.8 Spécification et preuve formelles des architectures matérielles

Les sections précédentes présentent les différents mécanismes de sécurité qui ont été implémentés à l'aide d'un support matériel. De fait, les microprocesseurs disponibles sur le marché embarquent de plus en plus de mécanismes de sécurité. Toutefois, se pose la question de la confiance que l'on peut avoir dans ces mécanismes. En effet, certains d'entre eux ont déjà fait l'objet de vulnérabilités exploitables par des attaquants.

Afin de renforcer la confiance dans ces mécanismes de sécurité, des travaux se sont intéressés à la spécification formelle de ces mécanismes. En outre, ce travail de spécification permet par la suite de vérifier formellement que ces mécanismes garantissent certaines propriétés de sécurité, définies elles aussi formellement. L'étape ultime consiste à s'assurer que l'implémentation du mécanisme est bien conforme à la spécification et permet donc d'assurer effectivement les propriétés de sécurité attendues.

Les mécanismes de sécurité matériel présentés dans les sections précédentes reposent en grande partie sur l'état de l'architecture matérielle. En outre, certains apportent des modifications à l'ISA. Il est donc nécessaire, dans un premier temps, de spécifier formellement la sémantique de l'ISA.
Ninja utilise ainsi l'ETM pour analyser des logiciels malveillants depuis un environnement isolé à l'aide de TrustZone [166]. Kargos utilise le PTM pour détecter les injections de code dans le noyau de l'OS. Cette approche apporte les mêmes garanties que Intel SMEP ou PXN mais elle n'induit pas de pénalité sur les performances [167]. HART utilise l'ETM pour protéger les modules du noyau de l'OS sans nécessiter de les recompiler [168]. Les auteurs utilisent ce mécanisme pour implémenter AddressSanitizer [169], une protection logicielle qui permet de vérifier les accès mémoire pour prévenir les attaques de dépassement de tampon et de use-after-free. Contrairement à l'approche logicielle, l'approche utilisant HART ne nécessite pas d'avoir accès au code source du module et peut donc être appliquée sur les modules propriétaires fournis par un tiers.

Ces mécanismes présentent également une menace potentielle pour la sécurité du code exécuté dans les environnements cloisonnés comme TrustZone. Le mécanisme de trace des processeurs ARM permet en effet de tracer le code exécuté en mode protégé, depuis l'espace non protégé. Cette fonctionnalité peut être verrouillée mais Ning et al. ont montré que ce verrouillage n'était souvent pas mis en place dans les produits du marché [170].

Des approches ont également exploré l'utilisation des compteurs de performances pour implémenter des mécanismes de sécurité, notamment de la détection d'intrusions ou de la détection de codes malveillants [171]. Das et al. dressent un état de l'art de ces approches [172]. Suite à une analyse détaillée de ces mécanismes et des garanties qu'ils peuvent fournir, les auteurs démontrent qu'ils doivent être utilisés avec prudence dans le contexte de la sécurité informatique. En effet, ces mécanismes n'ont pas été conçus pour cet usage et les auteurs démontrent qu'il est possible de réaliser des attaques en évasion sur les mécanismes de détection qui les utilisent.

## 2.1.8 Spécification et preuve formelles des architectures matérielles

Les sections précédentes présentent les différents mécanismes de sécurité qui ont été implémentés à l'aide d'un support matériel. De fait, les microprocesseurs disponibles sur le marché embarquent de plus en plus de mécanismes de sécurité. Toutefois, se pose la question de la confiance que l'on peut avoir dans ces mécanismes. En effet, certains d'entre eux ont déjà fait l'objet de vulnérabilités exploitables par des attaquants.

Afin de renforcer la confiance dans ces mécanismes de sécurité, des travaux se sont intéressés à la spécification formelle de ces mécanismes. En outre, ce travail de spécification permet par la suite de vérifier formellement que ces mécanismes garantissent certaines propriétés de sécurité, définies elles aussi formellement. L'étape ultime consiste à s'assurer que l'implémentation du mécanisme est bien conforme à la spécification et permet donc d'assurer effectivement les propriétés de sécurité attendues.

Les mécanismes de sécurité matériel présentés dans les sections précédentes reposent en grande partie sur l'état de l'architecture matérielle. En outre, certains apportent des modifications à l'ISA. Il est donc nécessaire, dans un premier temps, de spécifier formellement la sémantique de l'ISA.