# Extensions cryptographiques pour processeurs embarqués

Fabrice Lozachmeur

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

## To cite this version:

Fabrice Lozachmeur. Extensions cryptographiques pour processeurs embarqués. Informatique [cs]. Université Bretagne Sud, 2024. Français. NNT: tel-04427373

HAL Id: tel-04427373

https://theses.hal.science/tel-04427373

Submitted on 30 Jan 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_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
THÈSE DE DOCTORAT DE

L'UNIVERSITÉ BRETAGNE SUD

ÉCOLE DOCTORALE N° 644

Mathématiques et Sciences et Technologies
de l'Information et de la Communication en Bretagne Océane

Spécialité : Informatique et Architectures numériques

Par

Fabrice LOZACHMEUR

Extensions cryptographiques pour processeurs embarqués

Thèse présentée et soutenue à Lorient, le 23 janvier 2024

Unité de recherche : Lab-STICC UMR 6285, Thales LAS France SAS

Thèse N° : 687

## Rapporteurs avant soutenance :

Régis LEVEUGLE Professeur des Universités, INP - Université Grenoble Alpes

Sébastien PILLEMENT Professeur des Universités, Polytech - Nantes Université

## Composition du Jury :

Président : Sébastien PILLEMENT Professeur des Universités, Polytech - Nantes Université

Examinateurs : Sonia BELAÏD Ingénieure en cryptographie, CryptoExperts

Régis LEVEUGLE Professeur des Universités, INP - Université Grenoble Alpes

Dir. de thèse : Arnaud TISSERAND Directeur de Recherche, CNRS

## Invité(s) :

Nicolas TRANCHANT Expert Cybersécurité, Thales LAS France
<figure><img src="image_3.png" /></figure>
Remerciement

Je présente en premier lieu mes sincères remerciements à mon directeur de thèse, Arnaud Tisserand, qui m'a encadré tout au long de cette thèse et qui m'a fait partager ses observations avisées et ses précieux conseils. Je le remercie notamment pour la confiance qu'il m'a témoignée durant ces 3 années de thèse. Sa capacité d'analyse, son expérience et sa connaissance approfondie du domaine ont été d'une aide précieuse et ont contribué à l'aboutissement de cette thèse.

Je remercie à présent mes encadrants de Thalès. Mes premiers remercients sont à l'égard d'Arnaud Phelipot qui encadra mes travaux en 2021. Je tiens également à remercier Nicolas Tranchant, mon encadrant de 2022 jusqu'à la fin de ma thèse, pour ses remarques constructives et son travail de relecture. Je leur exprime toute ma gratitude pour tout ce qu'ils ont apporté à cette thèse.

Je tiens à remercier mon employeur, l'entreprise Thalès LAS France, de m'avoir donné l'opportunité de réaliser cette thèse. Je remercie également le laboratoire commun LATERAL (entre Thalès et le laboratoire Lab-STICC).

J'aimerais aussi adresser des remerciements à toute l'équipe d'ARCAD. Je remercie plus particulièrement tous les thésards qui ont partagé mon bureau.

Pour terminer, j'adresse des remerciements à ma famille pour m'avoir accompagné et soutenu tout au long de la thèse. Je tiens à remercier particulièrement mon frère, Gaëtan Lozachmeur, pour son soutien et ses précieux conseils.
<figure><img src="image_4.png" /></figure>
# Table des matières

Introduction 13

I État de l'art 17

1 Rappels de cryptographie 19

1.1 Introduction à la cryptographie 19

1.1.1 Le rôle de la cryptographie dans la sécurité de l'information 19

1.1.2 Assurer la confidentialité 20

1.1.3 Chiffrement par bloc 21

1.2 AES 23

1.2.1 Histoire de AES 23

1.2.2 Fonction de chiffrement et de déchiffrement 24

1.2.3 Sous-fonctions de AES 25

2 Attaques par analyse de canaux auxiliaires 29

2.1 Introduction aux attaques SCA 30

2.2 Attaques par observation du temps d'exécution 31

2.3 Attaques par observation de la consommation 32

2.3.1 Origine de la fuite 33

2.3.2 L'analyse simple de la consommation 34

2.3.3 Analyses statistiques de la consommation 35

2.3.4 Contre-mesures 39

2.3.5 Attaques SCA d'ordre supérieur 40

3 Masquage 41

3.1 Représentation masquée 41

3.2 Schéma de masquage 43

3.3 Modèle théorique d'attaquant 44

3.3.1 Modélisation des implémentations à protéger 44

3.3.2 Modèle de sondage 44

3.3.3 Modèle de sondage robuste 47

3.3.4 Modèle de sondage par régions 48

3.4 Composition d'implémentations masquées 49

3.4.1 Schéma de masquage ISW 49

3.4.2 Schéma de masquage RP 50

3.4.3 Implémentations de seuil 51

3.4.4 Propriété de composition NI et SNI 52
<table><tbody><tr><td>3.4.5</td><td>Propriété de composition PINI</td><td>54</td></tr><tr><td>3.5</td><td>Multiplication masquée</td><td>55</td></tr><tr><td>3.5.1</td><td>Multiplication masquée en logiciel</td><td>55</td></tr><tr><td>3.5.2</td><td>Multiplication masquée en matériel</td><td>56</td></tr><tr><td><b>4</b></td><td><b>Techniques d'implémentations</b></td><td><b>59</b></td></tr><tr><td>4.1</td><td>Implémentations logicielles de AES</td><td>59</td></tr><tr><td>4.1.1</td><td>Calcul direct</td><td>59</td></tr><tr><td>4.1.2</td><td>Tables pré-calculées</td><td>60</td></tr><tr><td>4.1.3</td><td>Implémentation «bit slicing»</td><td>60</td></tr><tr><td>4.1.4</td><td>Implémentation m-slicing</td><td>63</td></tr><tr><td>4.1.5</td><td>Comparaison des différentes solutions</td><td>64</td></tr><tr><td>4.2</td><td>Implémentations masquées de AES</td><td>64</td></tr><tr><td>4.2.1</td><td>Schéma de masquage RP</td><td>64</td></tr><tr><td>4.2.2</td><td>Schéma de masquage CPRR</td><td>65</td></tr><tr><td>4.2.3</td><td>Tables masquées</td><td>66</td></tr><tr><td>4.2.4</td><td>Implémentation «bit slicing» masquée</td><td>66</td></tr><tr><td>4.2.5</td><td>Implémentation «share slicing»</td><td>67</td></tr><tr><td>4.2.6</td><td>Comparaison des différentes solutions</td><td>68</td></tr><tr><td><b>5</b></td><td><b>Extensions de jeu d'instructions</b></td><td><b>69</b></td></tr><tr><td>5.1</td><td>Architecture de jeu d'instructions</td><td>69</td></tr><tr><td>5.2</td><td>Jeu d'instructions RISC-V</td><td>70</td></tr><tr><td>5.2.1</td><td>ISA de base RV32I</td><td>71</td></tr><tr><td>5.2.2</td><td>Extensions standards</td><td>71</td></tr><tr><td>5.2.3</td><td>Implementations RISC-V</td><td>71</td></tr><tr><td>5.3</td><td>Extension de jeu d'instructions</td><td>72</td></tr><tr><td>5.4</td><td>ISE pour la contre-mesure de masquage</td><td>73</td></tr><tr><td>5.4.1</td><td>Pourquoi une ISE dédiée au masquage?</td><td>73</td></tr><tr><td>5.4.2</td><td>ISE dédiées au masquage de l'état de l'art</td><td>74</td></tr><tr><td>5.4.3</td><td>Comparaison des ISE dédiées au masquage de l'état de l'art</td><td>77</td></tr><tr><td><b>II</b></td><td><b>Contributions</b></td><td><b>79</b></td></tr><tr><td><b>6</b></td><td><b>Environnement expérimental et reproduction de résultats de solutions de l'état de l'art</b></td><td><b>81</b></td></tr><tr><td>6.1</td><td>Environnement expérimental</td><td>81</td></tr><tr><td>6.1.1</td><td>Génération d'un exécutable</td><td>82</td></tr><tr><td>6.1.2</td><td>Simulation d'un code</td><td>82</td></tr><tr><td>6.1.3</td><td>Synthèse FPGA</td><td>83</td></tr><tr><td>6.2</td><td>Conception et mise en œuvre d'une ISE</td><td>83</td></tr><tr><td>6.2.1</td><td>Conception d'une ISE</td><td>83</td></tr><tr><td>6.2.2</td><td>Ajout des nouvelles instructions à l'assembler</td><td>83</td></tr><tr><td>6.2.3</td><td>Ajout des nouvelles instructions à Spike</td><td>84</td></tr><tr><td>6.2.4</td><td>Ajout des nouvelles instructions au processeur</td><td>84</td></tr><tr><td>6.3</td><td>Réimplantation de l'état de l'art</td><td>85</td></tr></tbody></table>
<table><tbody><tr><td>6.3.1</td><td>Évaluation des performances</td><td>85</td></tr><tr><td>6.3.2</td><td>Solutions logicielles</td><td>85</td></tr><tr><td>6.3.3</td><td>ISE dédiées au masquage de l'état de l'art</td><td>87</td></tr><tr><td>6.4</td><td>Analyse de la résistance contre les attaques SCA</td><td>88</td></tr><tr><td>6.4.1</td><td>Génération de traces simulées de consommation</td><td>88</td></tr><tr><td>6.4.2</td><td>Analyse des traces simulées</td><td>89</td></tr><tr><td><b>7</b></td><td><b>Extension masquée pour les implémentations «bit slicing»</b></td><td><b>93</b></td></tr><tr><td>7.1</td><td>Spécification de l'ISE1</td><td>93</td></tr><tr><td>7.1.1</td><td>Description des instructions</td><td>94</td></tr><tr><td>7.1.2</td><td>Composition sécurisée d'instructions masquées</td><td>95</td></tr><tr><td>7.2</td><td>Implémentation de l'ISE1 sur le CV32E40P</td><td>96</td></tr><tr><td>7.2.1</td><td>ALU masquée proposée</td><td>96</td></tr><tr><td>7.2.2</td><td>Intégration dans le cœur CV32E40P</td><td>98</td></tr><tr><td>7.2.3</td><td>Utilisation logicielle de l'ISE</td><td>98</td></tr><tr><td>7.3</td><td>Évaluation des performances et coûts</td><td>98</td></tr><tr><td><b>8</b></td><td><b>Extension masquée pour les implémentations m-slicing</b></td><td><b>103</b></td></tr><tr><td>8.1</td><td>Spécification de l'ISE2</td><td>103</td></tr><tr><td>8.2</td><td>Nouvelles implémentations m-slicing de AES</td><td>104</td></tr><tr><td>8.2.1</td><td>Implémentation 16-slicing de AES</td><td>104</td></tr><tr><td>8.2.2</td><td>Implémentation 8-slicing de AES</td><td>105</td></tr><tr><td>8.2.3</td><td>Implémentation 4-slicing de AES</td><td>106</td></tr><tr><td>8.2.4</td><td>Implémentation 2-slicing de AES</td><td>107</td></tr><tr><td>8.3</td><td>Évaluation des performances et coûts</td><td>109</td></tr><tr><td>8.3.1</td><td>Performance logiciel</td><td>109</td></tr><tr><td>8.3.2</td><td>Implémentation sur FPGA</td><td>109</td></tr><tr><td><b>9</b></td><td><b>Extension masquée et sécurisée dans le modèle de sondage par régions</b></td><td><b>111</b></td></tr><tr><td>9.1</td><td>Spécification de l'ISE3</td><td>111</td></tr><tr><td>9.2</td><td>Implémentation de l'ISE3 sur le CV32E40P</td><td>114</td></tr><tr><td>9.2.1</td><td>ALU masquée proposée</td><td>114</td></tr><tr><td>9.2.2</td><td>Intégration dans le cœur CV32E40P</td><td>115</td></tr><tr><td>9.3</td><td>Évaluation des performances et coûts</td><td>115</td></tr><tr><td><b>10</b></td><td><b>Solution matérielle/logicielle flexible pour masquer à des ordres élevés</b></td><td><b>117</b></td></tr><tr><td>10.1</td><td>Solution de masquage matériel/logiciel</td><td>118</td></tr><tr><td>10.1.1</td><td>Présentation de notre solution matérielle/logicielle</td><td>118</td></tr><tr><td>10.1.2</td><td>Masquage logiciel/matériel avec la version NI-SNI de l'ISE1</td><td>119</td></tr><tr><td>10.1.3</td><td>Masquage logiciel/matériel avec une version PINI de l'ISE1</td><td>120</td></tr><tr><td>10.2</td><td>Évaluation des performances et coûts</td><td>122</td></tr><tr><td><b>Conclusion</b></td><td></td><td><b>125</b></td></tr><tr><td><b>A Conversion en représentation BS</b></td><td></td><td><b>127</b></td></tr></tbody></table>
B Codes d'implémentations *m*-slicing de AES 129

C Preuves de sécurité du chapitre 10 134

C.1 Preuve de la propriété 2 134

C.2 Preuve de la propriété 3 134

C.3 Preuve de la propriété 4 135

C.4 Preuve de la propriété 5 135
Acronyme

<table><thead><tr><td>Terme</td><td>Description</td><td>Pages</td></tr></thead><tbody><tr><td>SPN</td><td>Substitution-permutation network</td><td>21</td></tr><tr><td>ECB</td><td>Electronic codebook block</td><td>22</td></tr><tr><td>CBC</td><td>Cipher block chaining</td><td>22</td></tr><tr><td>IV</td><td>Initialization vector</td><td>22</td></tr><tr><td>OFB</td><td>Output feedback</td><td>22</td></tr><tr><td>CTR</td><td>Counter mode</td><td>22</td></tr><tr><td>NIST</td><td>National institute of standards and technology</td><td>23</td></tr><tr><td>AES</td><td>Advanced Encryption Standard</td><td>23</td></tr><tr><td>SCA</td><td>Side-channel analysis</td><td>29</td></tr><tr><td>CMOS</td><td>Complementary metal-oxide-semiconductor</td><td>33</td></tr><tr><td>SPA</td><td>Simple power analysis</td><td>34</td></tr><tr><td>DPA</td><td>Differential power analysis</td><td>35</td></tr><tr><td>CPA</td><td>Correlation power analysis</td><td>38</td></tr><tr><td>MIA</td><td>Mutual information analysis</td><td>39</td></tr><tr><td>HO-SCA</td><td>Higher-order side-channel analysis</td><td>40</td></tr><tr><td>BM</td><td>Boolean masking</td><td>43</td></tr><tr><td>MPC</td><td>Multi party computation</td><td>43</td></tr><tr><td>DAG</td><td>Directed acyclic graph</td><td>44</td></tr><tr><td>TI</td><td>Threshold implementation</td><td>51</td></tr><tr><td>NI</td><td>Non-interference</td><td>52</td></tr><tr><td>SNI</td><td>Strong non-interference</td><td>52</td></tr><tr><td>PINI</td><td>Probe isolating non-interference</td><td>54</td></tr><tr><td>O-PINI</td><td>Output probe isolating non-interference</td><td>55</td></tr><tr><td>CMS</td><td>Consolidating masking schemes</td><td>56</td></tr><tr><td>DOM</td><td>Domain oriented masking</td><td>56</td></tr><tr><td>UMA</td><td>Unified masking approach</td><td>56</td></tr><tr><td>GLM</td><td>Generic low-latency masking</td><td>56</td></tr><tr><td>HPC</td><td>Hardware private circuits</td><td>56</td></tr><tr><td>BS</td><td>Bit slicing</td><td>60</td></tr><tr><td>ISE</td><td>Instruction set extension</td><td>69, 72</td></tr><tr><td>ISA</td><td>Instruction set architecture</td><td>69</td></tr><tr><td>CISC</td><td>Complex instruction set computer</td><td>69</td></tr><tr><td>RISC</td><td>Reduced instruction set computer</td><td>69</td></tr><tr><td>RF</td><td>Register file</td><td>75</td></tr><tr><td>PK</td><td>Proxy kernel</td><td>82</td></tr></tbody></table>
<table><thead><tr><td>Terme</td><td>Description</td><td>Pages</td></tr></thead><tbody><tr><td>HTIF</td><td>Host target interface</td><td>82</td></tr><tr><td>ISS</td><td>Instruction set simulator</td><td>82</td></tr><tr><td>CSR</td><td>Control and status registers</td><td>85</td></tr><tr><td>TVLA</td><td>Test vector leakage assessment</td><td>89</td></tr><tr><td>SNR</td><td>Signal-to-noise ratio</td><td>89</td></tr><tr><td>PRNG</td><td>Pseudorandom number generator</td><td>97</td></tr><tr><td>TRNG</td><td>True random number generator</td><td>97</td></tr><tr><td>FSM</td><td>Finite state machine</td><td>97</td></tr><tr><td>MSB</td><td>Most significant bit</td><td>105</td></tr></tbody></table>
Notation

<table><thead><tr><th>Terme</th><th>Description</th><th>Pages</th></tr></thead><tbody><tr><td>Enc</td><td>Fonction de chiffrement</td><td>20</td></tr><tr><td>Dec</td><td>Fonction de déchiffrement</td><td>20</td></tr><tr><td>p</td><td>Message en clair</td><td>20</td></tr><tr><td>c</td><td>Message chiffré</td><td>20</td></tr><tr><td>k</td><td>Clé de chiffrement</td><td>20</td></tr><tr><td>GF(2<sup>s</sup>)</td><td>Corps fini de caractéristique 2, à 256 éléments, défini par le polynôme de réduction P[X] = X<sup>s</sup> + X<sup>s-4</sup> + X<sup>s-3</sup> + X + 1</td><td>24</td></tr><tr><td>R</td><td>Nombre de rondes</td><td>24</td></tr><tr><td>GF(2)</td><td>L'unique corps fini à deux éléments</td><td>25</td></tr><tr><td>N</td><td>Nombre de traces</td><td>30</td></tr><tr><td>r</td><td>Une valeur aléatoire</td><td>41</td></tr><tr><td>n</td><td>Nombre de parts d'une variable masquée</td><td>42</td></tr><tr><td>x̂</td><td>Vecteur représentant un masquage de la variable x</td><td>42</td></tr><tr><td>x̂[i]</td><td>i<sup>ème</sup> part du masquage x̂</td><td>42</td></tr><tr><td>Masque</td><td>Procédure de masquage</td><td>42</td></tr><tr><td>Démasque</td><td>Procédure de démasquage</td><td>42</td></tr><tr><td>d</td><td>Ordre de masquage</td><td>42</td></tr><tr><td>F</td><td>Les termes en police sans empattement désignent une implémentation, une fonction ou un graphe</td><td>43</td></tr><tr><td>F̂</td><td>Une implémentation masquée</td><td>43</td></tr><tr><td>K</td><td>Un corps fini de caractéristique 2</td><td>44</td></tr><tr><td>P</td><td>Les termes en police calligraphique désignent un ensemble</td><td>45</td></tr><tr><td>[·]<sub>reg</sub></td><td>L'opérande est stocké dans un registre</td><td>57</td></tr><tr><td>rs1</td><td>Indice du premier registre source dans le fichier de registres</td><td>71</td></tr><tr><td>rs2</td><td>Indice du deuxième registre source dans le fichier de registres</td><td>71</td></tr><tr><td>rd</td><td>Indice du registre destination dans le fichier de registres</td><td>71</td></tr><tr><td>imm</td><td>Valeur immédiate</td><td>71</td></tr></tbody></table>
<table><thead><tr><th>Terme</th><th>Description</th><th>Pages</th></tr></thead><tbody><tr><td>reg[x]</td><td>Valeur du registre d'indice x dans le fichier de registres.</td><td>75</td></tr><tr><td>d<sub>H</sub></td><td>Ordre de masquage en matériel</td><td>118</td></tr><tr><td>d<sub>S</sub></td><td>Ordre de masquage en logiciel</td><td>118</td></tr><tr><td>⊕</td><td>Porte booléenne XOR</td><td></td></tr><tr><td>⊗</td><td>Porte booléenne AND</td><td></td></tr><tr><td>¬</td><td>Porte booléenne NOT</td><td></td></tr><tr><td>O(·)</td><td>Notation grand O de Landau</td><td></td></tr><tr><td>rnd(·)</td><td>Arrondi de l'opérande</td><td></td></tr><tr><td>n.a.</td><td>Valeur non disponible</td><td></td></tr></tbody></table>
# Introduction

La cryptographie est, en particulier, la science de la protection des informations sensibles. La cryptographie permet notamment d'assurer la confidentialité en utilisant des cryptosystèmes. La cryptographie se divise en deux grandes catégories, la cryptographie asymétrique et la cryptographie symétrique. Un des cryptosystèmes symétriques les plus utilisés actuellement est le chiffrement AES.

Les implémentations de cryptosystèmes, même robustes mathématiquement, sont susceptibles de divulguer des informations via l'observation de canaux auxiliaires du circuit sur lequel s'exécute le cryptosystème (par exemple le temps de calcul, la consommation d'énergie, le rayonnement électromagnétique). Les attaques par analyse des canaux auxiliaires [KJJ99], abrégées en SCA pour «side-channel analysis» en anglais, exploitent de potentielles corrélations entre les valeurs physiques mesurées et les opérations et opérandes traités dans le circuit pour récupérer des données sensibles.

Le masquage est une contre-mesure couramment utilisée pour protéger les systèmes logiciels et/ou matériels contre certaines attaques SCA [Cha+99; GP99]. Le masquage booléen d'ordre $d$ représente chaque variable sensible intervenant lors du calcul en $d + 1$ parts. La sécurité d'un schéma de masquage peut être prouvée dans certains modèles théoriques d'attaquant. Un schéma de masquage est par exemple sécurisé dans le modèle de sondage [ISW03] si un attaquant peut sonder $d$ variables dans l'implémentation sans obtenir des informations sensibles. [Cha+99; PR13] ont montré que le nombre de traces nécessaires pour attaquer une implémentation masquée et sécurisée dans le modèle de sondage augmente avec l'ordre de masquage. Cependant, les implémentations purement logicielles du masquage imposent un surcoût important en termes de tailles de code et temps de calcul [GR17]. De plus, les implémentations masquées en logiciel n'atteignent pas toujours le niveau de sécurité attendu en raison de fuites liées à la micro-architecture des processeurs [Gao+19] ou d'un niveau de bruit trop faible. [BS21] ont ainsi réalisé une attaque sur des implémentations purement logicielles de AES masquées jusqu'à l'ordre 5.

Différentes techniques ont été proposées dans la littérature pour implémenter le chiffrement AES en logiciel. Une des techniques les plus efficaces est appelée le «bit slicing» [Bih97], abrégé en BS, et permet de produire des implémentations de chiffrement à haut débit grâce au parallélisme de données dans un même mot machine. Les implémentations BS peuvent être masquées en répartissant les parts dans différents registres du processeur. Une autre solution, appelée «share slicing», consiste à placer toutes les parts d'un bit masqué dans un même mot mémoire.

Des extensions de jeux d'instructions, abrégées en ISE pour «instruction set extension» en anglais, ont été proposées pour implémenter le masquage de façon efficace et sécurisée. Une ISE dédiée au masquage permet d'accélérer les protections en maintenant de la flexibilité, d'augmenter la sécurité en prenant en compte la micro-architecture des processeurs et de rendre l'utilisation du masquage plus simple. Contrairement aux implémentations logicielles du mas-
quage, les ISE dédiées au masquage de l'état de l'art sont cependant limitées aux petits ordres de masquage.

**Nos contributions** Dans cette thèse, nous avons développé différentes ISE dédiées au masquage pour le processeur RISC-V CV32E40P afin de protéger certains cryptosystèmes contre des attaques SCA en utilisant un masquage d'ordre élevé :

1. Nous avons dans un premier temps mis en place un environnement expérimental permettant de compiler un code source, simuler son exécution sur une architecture RISC-V et de synthétiser le cœur CV32E40P. Plusieurs solutions matérielles et logicielles de l'état de l'art ont ensuite été réimplantées sur le cœur CV32E40P pour analyser leurs performances. Un simulateur a été étendu pour générer des traces simulées de consommation. Les traces simulées sont utilisées pour évaluer la résistance d'une implémentation contre des attaques SCA.

2. Nous proposons une ISE dédiée au masquage, que nous nommons ISE1, permettant d'implémenter de façon sécurisée et efficace des implémentations «*share slicing*» de différents cryptosystèmes. L'ISE1 a été implémentée pour des ordres de masquage élevés, allant jusqu'à l'ordre 31. L'ordre de masquage de l'ISE1 est fixé au moment de la synthèse. Une grande flexibilité est ainsi possible au moment de la conception pour divers compromis coût/performance. L'ISE1 a été implantée sur le processeur RISC-V CV32E40P pour réaliser des évaluations de performance et de surface.

3. Nous proposons une nouvelle ISE dédiée au masquage supportant des ordres de masquage $d \in \{1, 3, 7, 15\}$, que nous nommons ISE2, qui étend l'ISE1 pour réduire le nombre de blocs indépendants chiffrés en parallèle. Nous présentons de nouvelles implémentations «*share slicing*» de AES permettant de chiffrer un bloc à la fois. L'utilisation de tous les modes de chiffrement devient alors possible. L'ordre de masquage de l'ISE est fixé au moment de la synthèse. L'ISE2 a été implantée sur le processeur RISC-V CV32E40P pour réaliser des évaluations de performance et de surface.

4. Une implémentation masquée utilisant les ISE précédentes est sécurisée contre un ataquant pouvant sonder $d$ bits dans l'exécution complète. Pour augmenter la sécurité apportée par le masquage, nous proposons une nouvelle ISE dédiée au masquage, que nous nommons ISE3, qui modifie l'ISE1 pour obtenir une sécurité dans le modèle de son-dage par régions, où chaque région comprend une instruction de l'ISE3. L'ISE3 masquée à l'ordre $d$ permet alors à l'attaquant de sonder $d/2$ bits par instruction sans compromettre la sécurité du schéma de masquage.

5. Nous proposons une solution de masquage matériel/logiciel pour masquer à des ordres élevés avec une grande flexibilité au moment de la synthèse et au moment de la compilation logicielle pour divers compromis coût/performance. Un premier niveau de masquage est implémenté en matériel en utilisant l'ISE1 dont l'ordre de masquage est fixé au moment de la synthèse. Un masquage logiciel utilise ensuite les instructions masquées de l'ISE1 pour atteindre divers ordres supérieurs.

Notre solution de masquage matériel/logiciel a été l'objet de notre publication [LT23] dans la conférence MWSCAS.

**Organisation de la thèse** Le manuscrit de thèse se divise en deux parties consacrées à l'état de l'art et la description de nos contributions. Le chapitre 1 aborde quelques principes
de base de cryptographie symétrique. Le chapitre 2 introduit les attaques SCA. Le chapitre 3 décrit la contre-mesure de masquage. Les différentes techniques d'implémentations logicielles du chiffrement AES sont présentées dans le chapitre 4. Le chapitre 5 établit un état de l'art des ISE dédiées au masquage. Nos contributions sont détaillées dans les chapitres 6, 7, 8, 9 et 10. Le chapitre 6 présente notre environnement expérimental ainsi que la réimplantation sur le cœur CV32E40P de certaines solutions de l'état de l'art. Le chapitre 7 décrit l'ISE1 permettant d'implémenter de façon sécurisée et efficace des implémentations « share slicing » de cryptosystèmes. Le chapitre 8 présente l'ISE2 qui étend l'ISE1 pour réduire le nombre de blocs indépendants chiffrés en parallèle. Le chapitre 9 décrit l'ISE3 qui modifie l'ISE1 pour obtenir une sécurité dans le modèle de sondage par régions. Le chapitre 10 présente notre solution flexible de masquage matériel/logiciel.
<figure><img src="image_5.png" /></figure>
Première partie

État de l'art
<figure><img src="image_6.png" /></figure>
# Chapitre 1

## Rappels de cryptographie

Dans ce chapitre, nous abordons quelques principes de base de cryptographie symétrique. Pour une description plus complète de la cryptographie, le lecteur peut se rapporter au livre [PP10].

Une introduction à la cryptographie est réalisée dans la section 1.1. La section 1.2 introduit le chiffrement symétrique AES.

### 1.1 Introduction à la cryptographie

#### 1.1.1 Le rôle de la cryptographie dans la sécurité de l'information

<figure><img src="image_7.png" /><figcaption>FIGURE 1.1 – Schéma d'une communication entre Alice et Bob.</figcaption></figure>

La cryptographie est, en particulier, la science de la protection des informations sensibles. L'objectif de la cryptographie moderne est de fournir certaines fonctionnalités de sécurité pour échanger des informations sur un canal de communication non sécurisé. Comme illustré sur la figure 1.1, on suppose que deux interlocuteurs, communément appelés Alice et Bob, souhaitent échanger de façon sécurisée des données sensibles à travers un canal de communication. Mais ils ne peuvent pas directement s'échanger les données sensibles, car un attaquant espionne le canal de communication. Dans la communauté cryptographique, l'attaquant qui ne fait qu'observer s'appelle Eve. La cryptographie moderne utilise les mathématiques et la théorie de l'information pour créer des protocoles qui garantissent certaines propriétés de sécurité telles que :

— la *confidentialité* : un message est inintelligible pour quiconque sauf pour Alice et Bob,

— l'intégrité : Bob peut vérifier que le message n'a pas été modifié lors de son transfert,

— l'authenticité : Bob peut vérifier l'identité de l'expéditeur d'un message,

— la non-répudiation : Alice ne peut nier avoir écrit et envoyé un message.
### 1.1.2 Assurer la confidentialité

Pour assurer la confidentialité des données échangées et empêcher Eve de récupérer de l'information, Alice et Bob utilisent un système de chiffrement, aussi appelé cryptosystème, comme par exemple AES qu'on va étudier à la section 1.2. Alice va chiffrer le message à transmettre de telle façon que Bob puisse le déchiffrer, mais pas Eve (voir figure 1.2). Tout d'abord, ils se mettent d'accord sur une fonction de chiffrement Enc et une fonction de déchiffrement Dec. Puis, Alice va chiffrer le message en clair à transmettre, noté *p* pour « plaintext » en anglais, en un chiffré *c* en utilisant une clé de chiffrement $k_A$. Ensuite, Alice transmet le chiffré *c* à Bob à travers le canal de communication. Lorsque Bob reçoit le chiffré *c*, il utilise une clé de déchiffrement $k_B$ pour le déchiffrer et retrouver le clair *p*. Alice et Bob réalisent le chiffrement et le déchiffrement dans leur zone de confiance dans laquelle tout ce qui est manipulé n'est pas visible par Eve. Eve peut obtenir le chiffré en espionnant le canal de communication. Mais si le système de chiffrement est robuste, alors il est calculatoirement impossible de déterminer le clair à partir du chiffré sans la clé de déchiffrement. Selon un des principes de Kerckhoffs [Ker83], la sécurité d'un système de chiffrement ne doit pas reposer sur la dissimulation de son fonctionnement, mais uniquement sur les valeurs des clés et une complexité calculatoire suffisamment grande pour éviter qu'une attaque puisse réussir. En effet, si un certain nombre de personnes souhaitent communiquer en toute sécurité, elles ne peuvent espérer cacher le système qu'elles utilisent.

<figure><img src="image_8.png" /><figcaption>FIGURE 1.2 – Système de chiffrement.</figcaption></figure>

**Cryptographie symétrique et asymétrique** Il existe deux grandes catégories de cryptographie, la *cryptographie asymétrique* (ou à clé publique) et la *cryptographie symétrique* (ou à clé secrète). Les cryptosystèmes symétriques utilisent la même clé secrète *k* pour le chiffrement et le déchiffrement. Ce type de cryptosystèmes est généralement assez performant, mais nécessite que Alice et Bob se soient préalablement échangés de façon sécurisée la clé secrète. Le concept de cryptographie asymétrique a été proposé par [DH76] dans le but de résoudre le problème de distribution des clés posé par la cryptographie symétrique. Dans les cryptosystèmes asymétriques, les clés de chiffrement et de déchiffrement sont distinctes et l'une des clés ne peut pas se déduire de l'autre. On peut donc rendre l'une des deux publique tandis que l'autre reste privée. Tout le monde peut chiffrer en utilisant la clé publique, mais seul le propriétaire de la clé privée peut déchiffrer. En pratique, on utilise d'abord un cryptosystème asymétrique pour échanger la clé secrète et ensuite un cryptosystème symétrique pour l'échange des données. Dans cette thèse, on ne s'intéressera qu'à la cryptographie symétrique dont fait partie le cryptosystème AES.
**Attaques calculatoires** La cryptographie symétrique est la cible d'attaques dont l'objectif est de deviner la clé secrète utilisée ou des informations sur le clair. Les *attaques calculatoires* essayent de déterminer des données sensibles en utilisant uniquement la connaissance de l'algorithme, ainsi que certaines paires de clairs-chiffrés. Un cryptosystème symétrique est alors sécurisé s'il est calculatoirement impossible de déterminer des données sensibles, même en utilisant des implémentations informatiques extrêmement performantes. Un exemple d'attaque est la *recherche exhaustive de clé*, appelée également *attaque force brute*, qui permet de récupérer la clé secrète en utilisant une seule paire de clair-chiffré. Le clair est chiffré avec toutes les clés possibles jusqu'à obtenir le chiffré attendu. Pour rendre la recherche exhaustive de clé informatiquement impossible, un chiffrement doit utiliser un espace de clé suffisamment grand. Par exemple, pour attaquer une clé de 128 bits, une recherche exhaustive nécessite d'effectuer $2^{128}$ chiffrements qui est considérée comme calculatoirement infaisable à ce jour. D'autres attaques plus évoluées ont été proposées comme par exemple la *cryptanalyse différentielle* [BS91] et la *cryptanalyse linéaire* [Mat93].

**Propriétés pour concevoir un cryptosystème symétrique sécurisé** [Sha49] a défini deux propriétés mathématiques importantes pour concevoir des cryptosystèmes symétriques sécurisés, il s'agit de la *confusion* et de la *diffusion*. La confusion reflète la complexité de la relation entre le clair et le chiffré. Dans un cryptosystème raisonnable, la confusion doit être forte pour qu'on ne puisse pas facilement retrouver le clair ou la clé secrète à partir du chiffré. Certaines fonctions non-linéaires sont suffisamment complexes pour garantir un peu de confusion. La diffusion reflète la capacité du cryptosystème à mélanger les bits en cours de chiffrement. Pour qu'un cryptosystème soit robuste, une petite modification sur le clair doit engendrer une modification importante sur le chiffré. La diffusion peut être apportée par certaines fonctions linéaires.

1.1.3 Chiffrement par bloc

<figure><img src="image_9.png" /><figcaption>FIGURE 1.3 – Chiffrement par bloc itératif.</figcaption></figure>

Un *chiffrement par bloc* est un cryptosystème permettant de chiffrer des données de taille fixe (comme par exemple 128 bits) appelées *blocs*. Un *chiffrement par bloc itératif* est un type de chiffrement par bloc dans lequel le chiffré d'un bloc est obtenu en itérant une transformation qui apporte de la confusion et de la diffusion à chaque itération. Les itérations sont aussi appelées des *rondes* ou *tours*. Chaque ronde $Ronde_i$ prend en entrée la sortie de la ronde précédente et une clé de ronde $k_i$. Les clés de ronde sont dérivées de la clé principale $k$ par un algorithme de planification des clés. Une représentation d'une telle construction est donnée dans la figure 1.3. Le schéma de permutation substitution, abrégé en SPN pour «substitution-permutation network» en anglais, est une architecture de chiffrement par bloc itératif couramment utilisée.
Une ronde se compose de trois étapes successives. Premièrement, l'étape de *mélange des clés* consiste à additionner la clé de ronde et l'entrée de la fonction de ronde. Deuxièmement, l'étape de *substitution* apporte de la confusion en appliquant une fonction non linéaire. Troisièmement, l'étape de *permutation* apporte de la diffusion en mélangeant les bits.

**Mode de chiffrement** Pour chiffrer des textes en clair de taille arbitraire, le texte en clair est divisé en blocs puis chaque bloc est chiffré selon un *mode de chiffrement*. La communauté cryptographique utilise différents modes de chiffrement pour appliquer de manière sécurisée un chiffrement par bloc sur plusieurs blocs consécutifs. Certains de ces modes de chiffrement sont décrits dans la figure 1.4. Le *mode ECB*, abrégé de «electronic codebook block» en anglais, consiste à chiffrer chaque bloc indépendamment des autres. ECB est généralement considéré comme non sécurisé, car des blocs en clair identiques produisent des blocs chiffrés identiques. Cela peut être exploité par un attaquant pour obtenir des informations sur les blocs en clair. Le *mode CBC*, abrégé de «cipher block chaining» en anglais, rend le bloc chiffré en cours de chiffrement dépendant des blocs en clair précédemment chiffrés. Le bloc chiffré est obtenu en chiffrant le résultat du *XOR* entre le bloc en clair et le bloc chiffré précédent. Initialement, le *XOR* est effectué avec un vecteur d'initialisation, abrégé en IV. Le *mode OFB*, abrégé de «output feedback» en anglais, transforme un chiffrement par bloc en un chiffrement par flux. Pour générer le bloc chiffré, le *XOR* est réalisé entre le bloc en clair et la sortie du chiffrement par flux. Étant donné que le bloc en clair n'est utilisé que pour le *XOR* final, les opérations du chiffrement par bloc peuvent être effectuées à l'avance. Le *mode compteur*, abrégé en CTR, transforme un chiffrement par bloc en un chiffrement par flux en chiffrant les valeurs successives d'un compteur. Le compteur peut être n'importe quelle fonction produisant une séquence ne se répétant pas sur une longue période. Le mode CTR a des caractéristiques similaires à OFB, mais permet également le chiffrement des blocs en clair en parallèle. Le tableau 1.1 résume les caractéristiques des différents modes de chiffrement.

<figure><img src="image_10.png" /><figcaption>FIGURE 1.4 – (a) Mode ECB; (b) Mode CBC; (c) Mode OFB; (d) Mode CTR.</figcaption></figure>
<table><caption>TABLE 1.1 – Caractéristiques des différents modes de chiffrement.</caption><thead><tr><th>Mode</th><th>Sécurisé</th><th>Précalcul</th><th>Parallèle</th></tr></thead><tbody><tr><td>ECB</td><td>✗</td><td>✗</td><td>✓</td></tr><tr><td>CBC</td><td>✓</td><td>✗</td><td>✗</td></tr><tr><td>OFB</td><td>✓</td><td>✓</td><td>✗</td></tr><tr><td>CTR</td><td>✓</td><td>✓</td><td>✓</td></tr></tbody></table>

## 1.2 AES

### 1.2.1 Histoire de AES

Dans les années 90, on utilisait un algorithme de chiffrement symétrique, appelé DES, dont on voyait apparaître des limites de sécurité vis-à-vis de certaines attaques mathématiques. L'organisme de normalisation américain, le NIST, a alors organisé en 1997 un concours ouvert internationalement pour sélectionner un nouvel algorithme de chiffrement symétrique qui sera appelé *Advanced Encryption Standard* [NIS01], abrégé en AES. Le but était de le standardiser pour le diffuser à l'échelle mondiale. L'algorithme de chiffrement Rijndael [DR02], créé par des chercheurs européens, remporta le concours en 2000 et devint le chiffrement AES<fnref n="1" />. AES est un chiffrement par bloc itératif avec des blocs de 128 bits. Les tailles de clé possibles sont 128, 192 et 256 bits et permettent d'atteindre différents niveaux de sécurité. L'algorithme AES est très flexible et peut être implémenté très efficacement en logiciel et en matériel. Le chiffrement AES peut être implémenté en logiciel de façon efficace, à la fois sur de petits processeurs 8 bits et sur des processeurs 32 bits plus performants. Les implémentations matérielles dédiées à AES peuvent être adaptées en taille et en latence pour répondre à des contraintes spécifiques.

<figure><img src="image_11.png" /><figcaption>FIGURE 1.5 – Le chiffrement AES.</figcaption></figure>

<footnote n="1">1. À https://competitions.cr.yp.to/aes.html, il y a toutes les explications sur le déroulement du concours.</footnote>
## 1.2.2 Fonction de chiffrement et de déchiffrement

Toutes les opérations de l'algorithmme AES transforment un bloc de données appelé **état**. L'état de AES, illustré à la figure 1.6, est une matrice de taille 4 × 4 dont les éléments sont des octets, représentant des valeurs dans le corps fini GF(2⁸) défini par le polynôme de réduction $P[X] = X⁸ + X⁴ + X³ + X + 1$. Au tout début, l'état est le bloc en clair à chiffrer, découpé en octets et rangé par colonne dans la matrice. Pendant le chiffrement, AES va itérer des transformations de l'état avec des fonctions qu'on va définir dans la suite. À la toute fin, l'état contient les octets du bloc chiffré rangés par colonne dans la matrice. Le déchiffrement est similaire au chiffrement, l'état est initialisé avec le texte chiffré et les transformations inverses sont appliquées dans l'ordre inverse.

<figure><img src="image_12.png" /><figcaption>FIGURE 1.6 – L'état de AES.</figcaption></figure>

**Fonction de chiffrement de AES** La fonction de chiffrement de AES est illustrée par la figure 1.7. AES est un chiffrement par bloc itératif de type SPN. Le nombre de rondes *R* dépend de la taille des clés : 10 rondes pour une clé de 128 bits, 12 rondes pour une clé de 192 bits et 14 rondes pour une clé de 256 bits. Dans une ronde, il y a 4 sous-fonctions. Il y a tout d'abord **SubBytes** qui est non linéaire et apporte de la confusion. Puis **ShiftRows** et **MixColumns** qui sont linéaires et apportent de la diffusion. Et enfin **AddRoundKey** qui mélange l'état courant avec la clé de ronde de la ronde en cours. Toutes les clés de rondes sont dérivées de la clé de chiffrement par un algorithme de planification de clé. Pour des raisons de performance et de sécurité, on applique **AddRoundKey** avant la toute première ronde, et dans la dernière ronde, **MixColumns** est omise.

**Fonction de déchiffrement de AES** La fonction de déchiffrement de AES peut être effectuée en utilisant l'inverse des quatre sous-fonctions **SubBytes**, **ShiftRows**, **MixColumns**, et **AddRoundKey**, appliquées dans l'ordre inverse de la fonction de chiffrement. Les clés de ronde sont également prises dans l'ordre inverse. Étant donné que les opérations **SubBytes** et **ShiftRows** commutent, et que **MixColumns** est omise de la ronde finale, il existe une description du déchiffrement de AES qui imite la séquence des opérations pendant le chiffrement.
<figure><img src="image_13.png" /><figcaption>FIGURE 1.7 – Fonction de chiffrement de AES.</figcaption></figure>

1.2.3 Sous-fonctions de AES

**SubBytes** La première sous-fonction de la ronde est SubBytes (voir figure 1.8). SubBytes applique une table de substitution, appelée généralement SBOX, sur chaque octet de l'état. La fonction SBOX est une inversion dans GF(2⁸) suivie d'une application affine sur GF(2). SBOX est non-linéaire et apporte de la confusion. La fonction SBOX peut être implémentée en logiciel sous la forme d'une table précalculée contenant 256 valeurs, ou calculée au moment de l'exécution en utilisant certaines instructions de base du processeur. Pour les implémentations matérielles, de nombreuses conceptions optimisées exploitant les structures mathématiques de la fonction SBOX ont été proposées [Can05; BP12].

<figure><img src="image_14.png" /><figcaption>FIGURE 1.8 – Sous-fonction SubBytes.</figcaption></figure>
**ShiftRows** La deuxième sous-fonction de la ronde est **ShiftRows** (voir figure 1.9). **ShiftRows** décale cycliquement les lignes de l'état. La première ligne n'est pas décalée, la deuxième est décalée de 1 vers la gauche, la troisième de 2 et la quatrième de 3. Elle apporte de la diffusion. L'implémentation en logiciel de **ShiftRows** consiste en un réadressage des octets de l'état et peut être effectuée en combinaison de la SBOX. En matériel, **ShiftRows** peut être implémentée comme un simple câblage.

<figure><img src="image_15.png" /><figcaption>FIGURE 1.9 – Sous-fonction ShiftRows.</figcaption></figure>

**MixColumns** La troisième sous-fonction est **MixColumns** (voir figure 1.10). **MixColumns** multiplie chaque colonne de l'état par la matrice M définie par :

$$M = \begin{pmatrix} 02 & 03 & 01 & 01 \\ 01 & 02 & 03 & 01 \\ 01 & 01 & 02 & 03 \\ 03 & 01 & 01 & 02 \end{pmatrix}$$

Les bits dans une colonne sont mélangés par du calcul pour former la nouvelle colonne. C'est une fonction linéaire sur GF(2⁸) qui apporte de la diffusion. **MixColumns** peut être implémentée en logiciel en calculant des multiplications par $X \in GF(2^8)$, réalisées avec un certain nombre d'instructions de décalage et de XOR, ou par une table pré-calculée. Les implémentations matérielles de **MixColumns** ont tendance à être très efficaces car elles sont constituées principalement d'un nombre relativement faible de portes XOR.

<figure><img src="image_16.png" /><figcaption>FIGURE 1.10 – Sous-fonction MixColumns.</figcaption></figure>
**AddRoundKey** La dernière sous-fonction est AddRoundKey qui est illustrée par la figure 1.11. AddRoundKey réalise l'addition dans GF(2⁸) de chaque octet de l'état avec l'octet correspondant de la clé de ronde de la ronde courante. Elle consiste simplement en XOR bit à bit entre l'état et la clé de ronde.

<figure><img src="image_17.png" /><figcaption>FIGURE 1.11 – Sous-fonction AddRoundKey.</figcaption></figure>
<figure><img src="image_18.png" /></figure>
# Chapitre 2

## Attaques par analyse de canaux auxiliaires

Les cryptosystèmes modernes sont mathématiquement sécurisés contre les attaques calculatoires. Cependant, l’implémentation d’un cryptosystème sur un dispositif physique est susceptible de laisser fuir de l’information. Les *attaques physiques* exploitent l’implémentation physique des cryptosystèmes afin d’extraire des données sensibles. Depuis leur introduction, cette famille d’attaques suscite un grand intérêt à la fois dans la communauté académique et dans la communauté industrielle. En particulier, ce type d’attaques a un impact très important sur la sécurité des systèmes embarqués. Les attaques physiques sont divisées en deux catégories principales : les attaques par *analyse de canaux auxiliaires* [Koc96], abrégées en SCA pour «*side-channel analysis*» en anglais, et les *attaques par faute* [BS97]. Les attaques SCA observent et analysent les fuites physiques pour déterminer des données sensibles. Les *attaques par faute* perturbent le calcul cryptographique en générant des fautes dans le circuit afin de déduire des informations sensibles ou passer outre des protections. Les perturbations peuvent être des variations de tension ou d’horloge, des impulsions électromagnétiques ou encore des impulsions lasers. Dans la suite de cette thèse, nous nous intéresserons uniquement aux attaques SCA.

<figure><img src="image_19.png" /><figcaption>FIGURE 2.1 – Classification des attaques.</figcaption></figure>

La section 2.1 introduit les attaques SCA. La section 2.2 décrit les attaques par observation du temps d'exécution. La section 2.3 présente les attaques par observation de la consommation d'énergie, ainsi que les principales contre-mesures.
## 2.1 Introduction aux attaques SCA

L'implémentation d'un cryptosystème sur un dispositif physique est susceptible de laisser fuir de l'information à travers des mesures physiques appelées *canaux auxiliaires*. Ces mesures physiques peuvent dépendre des opérations effectuées et des données manipulées. Une attaque SCA exploite alors certaines corrélations entre des valeurs physiques mesurées et des valeurs manipulées pour retrouver des variables sensibles. La SCA est une attaque utilisée depuis longtemps, comme par exemple pour ouvrir les coffres-forts en écoutant le son émis par les mouvements internes de la serrure. L'application de la SCA aux implémentations électroniques est plus récente. La première référence d'une attaque SCA ciblant une implémentation électronique date de 1943, lorsqu'un chercheur des laboratoires Bell remarqua que les émissions électromagnétiques d'un dispositif cryptographique dépendait des valeurs manipulées. Il essaya alors de récupérer, plus ou moins directement, le message en clair en exploitant les émissions électromagnétiques. Cette découverte a conduit le gouvernement américain à lancer dans les années 50 le programme TEMPEST [Fri72] pour exploiter les émissions électromagnétiques de différents appareils électroniques. Plusieurs attaques SCA ont ensuite été proposées, mais il faudra attendre 1996 pour qu'une attaque SCA contre une implémentation cryptographique soit publiée [Koc96]. [Koc96] ont montré comment les implémentations classiques de RSA et d'autres cryptosystèmes à clé publique pouvaient être efficacement attaquées en exploitant les variations du temps de calcul. Depuis, les attaques SCA se sont avérées très efficaces dans la pratique pour attaquer une large gamme de cryptosystèmes, notamment DES, AES, RSA, ECC ainsi que les chiffrements post-quantiques. La SCA est devenue aujourd'hui une branche à part entière de la recherche en cryptographie et en sécurité des systèmes embarqués.

<figure><img src="image_20.png" /><figcaption>FIGURE 2.2 – Attaque par observation. N désigne le nombre de traces.</figcaption></figure>
**Description de l'attaque** Pendant une attaque SCA, l'attaquant peut chiffrer plusieurs messages en clair avec une même clé secrète *k*. Pendant le chiffrement de chaque clair, l'attaquant mesure un ou plusieurs canaux auxiliaires, pour obtenir une *trace de mesures physiques* (voir figure 2.2). L'attaquant a alors accès aux messages en clair et/ou aux messages chiffrés associés, ainsi qu'aux traces de mesures physiques correspondantes. L'attaquant analyse ensuite certaines *corrélations* entre les traces de mesures physiques et les valeurs manipulées. Une analyse directe des traces de mesures physiques est parfois suffisante pour déterminer des variables sensibles. Lorsque le bruit est trop important pour mener une analyse directe, des méthodes statistiques [KJJ99] sont utilisées ou des techniques plus sophistiquées à base d'intelligence artificielle [MDP19]. Les attaques SCA nécessitent le plus souvent un accès physique au circuit électronique exécutant le cryptosystème. Cela se produit en pratique pour les implémentations cryptographiques embarquées. Par exemple, lorsqu'une carte bancaire intervient dans l'exécution d'un paiement, le client insère la carte dans le terminal du commerçant et saisit son code PIN. Le terminal dispose alors d'un accès physique à la carte et est en mesure d'interroger la carte pour différents calculs cryptographiques.

**Les différents canaux auxiliaires** Il existe différents canaux auxiliaires permettant d'attaquer un cryptosystème. Un des premiers canaux auxiliaires utilisé dans la littérature est le temps d'exécution du cryptosystème [Koc96]. [KJJ99] ont ensuite exploité l'évolution de la consommation d'énergie d'un circuit électronique pendant l'exécution d'un cryptosystème. La consommation d'énergie est mesurée en utilisant une sonde de courant qui agit un peu comme une résistance en série. Par la suite, [GMO01 ; QS01] ont montré que le rayonnement électromagnétique pouvait être exploité pour attaquer un cryptosystème. L'attaquant capte les émissions électromagnétiques en plaçant une sonde électromagnétique au dessus du circuit électronique. La principale différence avec la consommation d'énergie est la localité de la mesure. Alors que la consommation du circuit électronique est produite par l'ensemble de ses composants, une sonde électromagnétique peut être placée sur un composant spécifique et fournir des informations uniquement par l'élément situé en dessous de la sonde. Plus récemment, d'autres canaux auxiliaires ont été exploités, tels que les émissions de photons [Krä+13], l'acoustique [GST14] ou la température [HS13].

## 2.2 Attaques par observation du temps d'exécution

[Koc96] a réalisé en 1996 une attaque SCA exploitant les différences de temps d'exécution de certains calculs cryptographiques. Afin d'illustrer le fonctionnement de cette attaque, rappelons l'exemple classique de vérification d'un code PIN. On considère l'algorithme 1 qui vérifie le code PIN chiffre par chiffre. Si un chiffre est incorrect, l'algorithme s'arrête. En mesurant le temps mis par l'algorithme pour répondre à un code PIN donné, l'attaquant peut déduire le code PIN correct. En effet, l'attaquant peut essayer toutes les valeurs différentes pour le premier chiffre du code PIN. Une valeur erronée arrête l'algorithme alors que la valeur correcte engendre la comparaison du chiffre suivant. En comparant le temps d'exécution nécessaire pour répondre à chaque requête, l'attaquant peut déduire la valeur du premier chiffre du code PIN. L'attaquant peut ensuite attaquer le chiffre suivant de la même manière. En itérant cette technique, l'attaquant obtient le code PIN complet avec une complexité linéaire au lieu d'exponentielle.
**Algorithmme 1** Vérification de code PIN

**Entrée:** $S[\cdot]$ un vecteur de taille $k$ contenant le code PIN saisi; $C[\cdot]$ un vecteur de taille $k$ contenant le code PIN correct.

**Sortie:** PIN valide ou invalide

pour $i = 1$ à $k$ faire
si $S[i] \neq C[i]$ alors
retourne PIN invalide
fin si
fin pour
retourne PIN valide

Un autre exemple classique d'analyse du temps d'exécution est l'attaque de [Koc96] contre RSA basée sur l'exponentiation modulaire décrite dans l'algorithme 2. L'exponentiation modulaire réalise une boucle qui requiert plus ou moins d'opérations en fonction de l'exposant secret manipulé. En effet, si le bit de l'exposant manipulé vaut 0, seule l'élévation au carré sera effectuée, alors que si le bit vaut 1, une multiplication supplémentaire est réalisée. Ainsi, le temps global du calcul de RSA dépend du nombre de bits à 1 de l'exposant, ce qui permet de récupérer l'exposant secret.

**Algorithmme 2** Exponentiation modulaire utilisant la méthode «*Square and Multiply*»

**Entrée:** $a, m \in \mathbb{N}, e = (e_{k-1}, \dots, e_0)$

**Sortie:** $x = a^e \bmod m$
$x \leftarrow 1$

pour $i = k - 1$ à 0 faire
$x \leftarrow x^2 \bmod m$
si $e[i] = 1$ alors
$x \leftarrow x \times a \bmod m$
fin si
fin pour
retourne $x$

Depuis les travaux de [Koc96], de nombreuses autres attaques exploitant le temps d'exécution ont été développées, telles que [HH98; Dhe+98]. Les attaques par analyse du temps d'exécution sont également rendues possibles par certains mécanismes d'optimisation des processeurs modernes tels que le *cache* [Tsu+03; Ber05; BM06] ou l'unité de prédiction de branchement [AKS07]. Pour protéger un cryptosystème de l'analyse du temps d'exécution, une contre-mesure consiste à implémenter des cryptosystèmes s'exécutant en temps constant [OST05; Kön08], c'est-à-dire tel que le temps d'exécution ne varie pas, ou tout au moins que sa variation ne dépende pas de valeurs sensibles.

## 2.3 Attaques par observation de la consommation

Dans cette section, nous décrivons les attaques SCA exploitant la consommation d'énergie des circuits numériques.
### 2.3.1 Origine de la fuite

**Consommation d'énergie dans les circuits numériques** La plupart des circuits intégrés actuels sont basés sur la technologie CMOS. La consommation et le rayonnement électromagnétique émis par un circuit CMOS dépendent des valeurs manipulées et des calculs effectués [MDS99]. Par exemple, la figure 2.3 montre la consommation d'un microprocesseur 8 bits pendant le transfert d'un octet de données de la mémoire vers un registre. On constate que la consommation est directement liée au nombre de bits qui commutent (appelés transitions). Outre les transferts mémoires, les unités de calcul laissent fuir également de l'information. Par exemple, l'inverseur CMOS consomme davantage lorsque sa sortie commute.

<figure><img src="image_21.png" /><figcaption>FIGURE 2.3 – Consommation d'un microprocesseur 8 bits pendant le transfert d'un octet de données de la mémoire vers un registre. Extrait de [MDS99].</figcaption></figure>

**Glitch** Les circuits ne sont pas idéaux et possèdent des délais de propagation. Les délais de propagation peuvent causer des modifications transitoires du signal de sortie qui n'ont pas de sens fonctionnel [MOP07], qu'on appelle des *glitchs*. Illustrons le concept de glitch avec l'exemple de la figure 2.4. Au temps $T_0$, les deux entrées sont stabilisées à 0, donc C et OUT sont à 1. Au temps $T_1$, on suppose que les deux entrées passent simultanément à 1. À cause du délai de propagation dans l'inverseur et la porte NAND, C et OUT changent respectivement de valeur à $T_2$ et $T_3$. Quand tous les délais de propagation sont passés, la sortie va se stabiliser sur la valeur correcte. Mais entre $T_3$ et $T_4$ s'est produit une modification temporaire et incorrecte du signal de sortie, qu'on appelle un glitch. Les glitchs consomment de l'énergie et la consommation liée aux glitchs dépend des valeurs des opérandes et de leurs commutations. De nouveau, l'énergie consommée par les glitchs peut révéler de l'information sur la clé secrète [MPG05].
<figure><img src="image_22.png" /><figcaption>FIGURE 2.4 – Illustration simplifiée d'un glitch (en pratique les fronts montant et descendant ne sont pas verticaux).</figcaption></figure>

## 2.3.2 L'analyse simple de la consommation

L'analyse simple de la consommation, abrégée en SPA pour «simple power analysis» en anglais, vise à récupérer des informations sensibles en observant seulement quelques traces de consommation [KJJ99]. Deux stratégies principales existent pour récupérer des informations sensibles par analyse simple de la consommation. La première stratégie tente d'identifier les dépendances entre les instructions effectuées et les traces, tandis que la seconde tente directement d'exploiter les dépendances entre les données manipulées et les traces.

**Dépendance aux instructions** Lorsque les calculs dépendent des valeurs des bits de la clé secrète, une trace de consommation peut a priori révéler directement la valeur de la clé. Un exemple typique est l'implémentation RSA basée sur l'exponentiation modulaire de l'algorithme 2 [KJJ99]. L'exponentiation modulaire réalise une boucle et effectue à chaque itération une élévation au carré et une multiplication si le bit d'exposant est 1, ou seulement une élévation au carré si bit d'exposant est 0. Si la consommation de la multiplication est différente de la consommation de l'élévation au carré, alors il est possible de distinguer chaque opération sur la trace de consommation. Par exemple, la figure 2.5 représente une trace de consommation de RSA sur laquelle on peut distinguer les consommations liées à la multiplication et à l'élévation au carré. Un attaquant est alors capable de retrouver chacun des bits de l'exposant secret en déterminant si la multiplication a été effectuée ou non. Une bonne manière de se protéger contre ce type d'attaque est de produire des implémentations à code constant [Cla+11]. Il faut en effet veiller à ce que la suite des instructions exécutées soit la plus régulière possible, ou au moins qu'elle ne dépende pas de valeurs sensibles (directement ou indirectement).
<figure><img src="image_23.png" /><figcaption>FIGURE 2.5 – Trace de consommation de RSA extraite de [Koc+11]. Une SPA sur l'exposition modulaire permet de déterminer la clé.</figcaption></figure>

**Dépendance des données** La consommation d'énergie d'un dispositif exécutant un cryptosystème dépend des valeurs intermédiaires manipulées. Pour récupérer des valeurs sensibles, l'attaquant réalise dans un premier temps un modèle en mesurant la consommation pour chaque valeur de la variable intermédiaire. En comparant la trace mesurée avec le modèle, l'attaquant peut déduire la valeur sensible.

**Limites de la SPA** Une implémentation à code constant permet de protéger efficacement contre la SPA exploitant les dépendances liées aux instructions. De plus, les dépendances liées aux données peuvent être difficiles à exploiter en pratique car les différences de consommation entre les différentes valeurs manipulées sont faibles et l'information utile est noyée dans du bruit lié à la mesure et à l'activité du reste du circuit. Pour atténuer le bruit et pour renforcer les différences de consommation aussi petites soient elles, des méthodes statistiques [KJJ99] ou des techniques plus sophistiquées à base d'intelligence artificielle [MDP19] sont utilisées.

### 2.3.3 Analyses statistiques de la consommation

L'analyse différentielle de la consommation [KJJ99], abrégée en DPA pour «differential power analysis» en anglais, utilise des méthodes statistiques pour déterminer des données sensibles à partir de plusieurs traces de consommation mesurées lors du chiffrement de différents messages en clair avec la même clé secrète. L'attaque DPA consiste dans un premier temps à identifier une variable sensible $X_{k'}$ manipulée dans l'implémentation du chiffrement et qui dépend d'une partie $k'$ de la clé secrète $k$, appelée sous-clé, ainsi que d'une donnée connue de l'attaquant (telle que le message en clair ou le message chiffré). Une fois la variable $X_{k'}$ ciblée, l'attaquant chiffre $N$ clairs $p_1, p_2, ..., p_N$ avec la même clé secrète $k$ pour obtenir les chiffrés $c_i$ correspondants. Pour estimer la valeur de $k'$, l'attaque DPA se décompose en deux phases illustrées par la figure 2.6. D'un côté, on va mesurer la consommation, de l'autre, on va prédire la consommation. Puis on fait une comparaison statistique des deux pour trouver la valeur de $k'$ pour laquelle la mesure et la prédiction sont les plus corrélées.

**Description de l'attaque** La première phase est l'acquisition d'une trace de consommation pendant le chiffrement de chaque clair $p_i$ pour obtenir les différentes lignes de la matrice de consommation mesurée. Les traces de consommation mesurées ne sont pas toujours parfaitement alignées en raison de légers décalages de temps lors de leurs acquisitions. L'attaque DPA étant basée sur une analyse statistique entre les différentes traces, ces décalages peuvent augmenter significativement le nombre de traces nécessaire pour réussir l'attaque. Plusieurs méthodes d'alignement des traces ont été proposées dans la littérature (voir [MOP07] pour un
<figure><img src="image_24.png" /><figcaption>FIGURE 2.6 – Analyse différentielle de la consommation.</figcaption></figure>

aperçu des différentes méthodes). Dans une seconde phase, l'attaquant réalise des hypothèses sur la valeur de la sous clé $k'$ et prédit la consommation pour chaque hypothèse de sous-clé. Pour prédire la consommation, la valeur de $X_{k'}$ est calculée pour chaque hypothèse de sous-clé et pour chaque clair. Puis, la consommation du chiffrement est prédite en utilisant un modèle de consommation théorique. On obtient alors la matrice des consommations prédites dans laquelle chaque colonne correspond à la prédiction de la consommation des N chiffrements pour une hypothèse de sous-clé. Pour déterminer la valeur de la sous clé $k'$, l'attaquant détermine un instant $t$ dans les traces mesurées durant lequel la variable $X_{k'}$ est manipulée dans l'implémentation. Puis une comparaison statistique est réalisée entre la consommation mesurée à l'instant $t$ et la consommation prédite. La colonne de la matrice des consommations mesurées correspondant à l'instant $t$ est comparée avec chacune des colonnes de la matrice des consommations prédites. L'hypothèse de sous-clé pour laquelle la corrélation est la plus forte est probablement la sous-clé correcte. En pratique, l'instant $t$ durant lequel la variable $X_{k'}$ est manipulée ne peut pas être déterminé précisément. La comparaison statistique est alors appliquée en chacun des points d'un intervalle de temps. La taille de cet intervalle dépend de la possibilité d'encadrer plus
ou moins précisément l'instant *t*. Le nombre de courbes nécessaires pour réussir une attaque dépend de plusieurs paramètres tels que le niveau de bruit des mesures, la précision du modèle de consommation ou l'efficacité de la méthode statistique utilisée.

### Modèles de fuite
Nous mentionnons maintenant deux modèles classiques de consommation utilisés dans les attaques DPA. La consommation liée à une variable peut être modélisée par le *poids de Hamming* de la variable, c'est à dire le nombre de bits à 1. Ce modèle exploite le fait que la consommation d'un bit à 0 peut être différente de la consommation d'un bit à 1. Une autre possibilité pour modéliser la consommation d'une variable est de calculer la *distance de Hamming* par rapport à sa valeur précédente, c'est à dire le nombre de bits ayant commuté. Ce modèle exploite le fait que la consommation est plus élevée lorsque les bits commutent. On a illustré ces deux modèles dans la figure 2.7 avec un registre 2 bits. On constate que les deux modèles donnent des traces prédites un peu différentes et ne modélisent pas tout à fait la même chose. Ces deux modèles de consommation sont les plus couramment adoptés car ils sont simples à utiliser et ils correspondent souvent assez bien aux consommations effectivement mesurées.

<figure><img src="image_25.png" /><figcaption>FIGURE 2.7 – Modèles de consommation.</figcaption></figure>

### Stratégie d'attaque
Déterminer directement la clé secrète complète par une attaque DPA est impossible lorsque la clé secrète est de grande taille. Par exemple, pour déterminer la clé de 128 bits de AES, $2^{128}$ hypothèses de clé doivent être modélisées, ce qui est calculatoirement infaisable. La méthode *diviser pour régner* cible des variables dépendant de petits morceaux
de la clé secrète puis les attaque séparément pour déterminer la clé complète. Dès qu'on a un morceau de clé connu, on peut l'utiliser pour déterminer un autre morceau de clé et ainsi de suite. La figure 2.8 illustre la méthode diviser pour régner par une attaque DPA de AES ciblant la sortie de chaque SBOX de la première ronde. L'attaque DPA peut alors révéler chaque octet de la clé secrète avec seulement $2^8$ hypothèses de sous-clé. Le nombre d'hypothèses de sous-clé à tester est donc réduit de $2^{128}$ à $16 \times 2^8 = 2^{12}$, qui est facilement réalisable avec les processeurs actuels et les dispositifs de mesure existants.

<figure><img src="image_26.png" /><figcaption>FIGURE 2.8 – AddRoundKey et SubBytes de la première ronde de AES.</figcaption></figure>

**Différentes méthodes statistiques** Les deux méthodes statistiques les plus utilisées en pratique pour effectuer une attaque DPA sont la différence des moyennes et le coefficient de corrélation de Pearson. La différence des moyennes fut initialement introduite par [KJJ99] et cible un bit d'une valeur intermédiaire de l'implémentation. Pour chaque hypothèse de sous-clé, les traces sont partitionnées en deux ensembles en fonction de la valeur du bit ciblé, puis la différence des moyennes de chaque ensemble est calculée. Il en résulte une courbe de différence des moyennes associée à chaque hypothèse de sous-clé. Lorsque l'hypothèse de sous-clé est incorrecte, la différence des moyennes est proche de 0 car le choix qui a guidé l'affectation de chaque trace à un ensemble est décorrélé de la mesure. Lorsque l'hypothèse de sous-clé est correcte, la différence des moyennes a une valeur élevée à chaque instant où le bit ciblé a été manipulé. L'hypothèse de sous-clé ayant la plus grande différence des moyennes correspond avec une certaine probabilité à la sous-clé correcte. Un des inconvénients de cette méthode statistique est la présence de «pics fantômes» (voir [BCO04] pour une description de ce phénomène). En effet, des hypothèses de sous-clé incorrectes peuvent générer des pics dans la courbe de différence des moyennes. De plus, la différence des moyennes est très sensible à la présence de bruit dans les traces de consommation. Ces contraintes peuvent augmenter de manière significative le nombre de traces nécessaire pour réussir l'attaque. Pour une meilleure tolérance au bruit et aux «pics fantômes», [BCO04] ont proposé l'analyse de la consommation par corrélation, abrégée en CPA pour «correlation power analysis» en anglais, qui utilise le coefficient de corrélation de Pearson comme méthode statistique. Le coefficient de corrélation de Pearson de deux séries statistiques est le quotient de la covariance par le produit des écarts-types de chaque série. Il renseigne sur le degré de dépendance linéaire entre les séries statistiques. Il est compris entre -1 et 1 et plus le coefficient est proche de -1 ou 1, plus la corrélation linéaire est forte. La CPA semble être plus tolérante au bruit et aux «pics fantômes» que la différence des moyennes et fournit généralement de meilleurs résultats expérimentaux en révélant des corrélations avec un nombre de traces inférieur. Ceci est probablement dû au fait que sa formule tient compte à la fois de la
moyenne et de la variance des mesures. Il existe d'autres méthodes statistiques plus évoluées. On peut notamment citer l'analyse de l'information mutuelle [GBT07], abrégée en MIA pour «mutual information analysis» en anglais. À la différence des méthodes statistiques précédentes, elle prend en compte certaines relations non-linéaires entre les traces de consommation et les valeurs manipulées.

### 2.3.4 Contre-mesures

On vient d'étudier les principes de la SPA et de la DPA. On va voir maintenant comment on se protège de ces attaques. Il existe différents types de protection.

**Désynchronisation en temps** Dans les attaques DPA, les traces doivent être alignées pour qu'une variable sensible soit manipulée à un même instant dans chaque trace. Une contre-mesure consiste à désynchroniser les traces afin qu'une variable sensible soit manipulée à des moments différents. Une première méthode est l'insertion aléatoire d'opérations factices [TB07; CK09]. Le temps d'exécution global doit rester constant pour que l'attaquant n'obtienne pas d'information sur le nombre d'opérations factices et les opérations factices ne doivent pas être détectables par SPA. Augmenter le nombre d'opérations factices insérées améliore la sécurité apportée par la contre-mesure, mais en contrepartie dégrade les performances. La deuxième méthode de désynchronisation des traces est le mélange aléatoire des opérations [RPD09; Vey+12]. Cette contre-mesure consiste à réordonner aléatoirement l'ordre d'exécution des opérations lorsque c'est possible. Par exemple, les SBOX de AES peuvent être calculées dans un ordre quelconque. Cependant, le nombre d'opérations qui peut être réordonné est généralement assez limité et dépend de l'algorithmme. La désynchronisation des traces n'est généralement pas suffisante pour se prémunir complètement des attaques DPA. Associée avec d'autres contre-mesures, elle améliore la protection en augmentant le nombre de traces nécessaires pour réussir une attaque DPA.

<figure><img src="image_27.png" /><figcaption>FIGURE 2.9 – Insertion aléatoire d'opérations factices à gauche et mélange aléatoire des opérations à droite.</figcaption></figure>

**Consommation équilibrée** Une autre contre-mesure consiste à rendre la consommation de l'implémentation constante, supprimant ainsi la corrélation entre les mesures et les variables manipulées [Sok+04; PM05; Buc+06]. Par exemple, le double rail rend le poids de Hamming constant en manipulant toujours un bit et son complémentaire. Cependant, en pratique, la consommation n'est jamais parfaitement constante en raison de petits déséquilibres de charge entre les deux circuits complémentaires, de variations de processus, de routage, etc. De plus, cette protection impose un surcoût important en terme de surface, puisqu'elle multiplie la surface par 3 ou 4 environ.
<figure><img src="image_28.png" /><figcaption>FIGURE 2.10 – Porte logique implémentée en double rail.</figcaption></figure>

**Randomisation des données** La contre-mesure la plus étudiée et la plus utilisée en pratique est le *masquage* [Cha+99; GP99]. Le masquage consiste à rendre aléatoires à chaque exécution les variables sensibles manipulées dans une implémentation. Le masquage d'ordre $d$ représente chaque variable sensible par $n$ parts (avec $n > d$) telles que chaque sous-ensemble de $d$ parts soit indépendant de la variable sensible. Un attaquant doit alors connaître plus de $d$ parts pour déterminer une variable sensible. Lorsque le masquage est bien mis en œuvre, la réalisation d'une attaque DPA est d'autant plus compliquée que l'ordre de masquage est élevé. La contre-mesure de masquage est décrite dans le chapitre 3.

## 2.3.5 Attaques SCA d'ordre supérieur

L'attaque *SCA d'ordre supérieur*, abrégée en HO-SCA pour «*higher-order side-channel analysis*» en anglais, est une attaque SCA qui exploite les consommations résultant de la manipulation dans l'implémentation de plusieurs variables. Les *attaques multivariées* d'ordre $d$ combinent $d$ points de la trace pour déterminer des variables sensibles. Le masquage d'ordre $d$ est ainsi vulnérable aux attaques multivariées d'ordre $d + 1$ qui combinent les consommations liées à $d + 1$ parts. Plusieurs *fonctions de combinaison* ont été proposées dans la littérature [PRB09]. [Cha+99] propose d'effectuer le produit des parts alors que [Mes00b] combine les parts en utilisant la différence absolue. La complexité pour réaliser une attaque multivariée augmente avec l'ordre de masquage. Les *attaques univariées* exploitent la consommation en un seul point de la trace résultant de la manipulation de plusieurs variables en parallèle. C'est notamment ce qui se passe lorsque le masquage est appliqué en matériel, puisque toutes les parts sont manipulées en parallèle. Une attaque univariée d'ordre $d$ utilise le moment statistique d'ordre $d$ pour attaquer le cryptosystème. Le masquage d'ordre $d$ en matériel est vulnérable aux attaques univariées d'ordre $d + 1$ qui impliquent conjointement $d + 1$ parts.
# Chapitre 3

## Masquage

Le masquage est une contre-mesure les plus largement utilisées pour protéger les implé- mentations cryptographiques contre la SCA [MOP07]. Le masquage est apparu dans la littéra- ture peu après la publication de l'attaque DPA et fut publié indépendamment dans [Cha+99] et [GP99]. Un schéma de masquage mélange chaque variable sensible intervenant lors du calcul avec une ou plusieurs valeurs aléatoires. La sécurité d'un schéma de masquage est prouvable dans des modèles théoriques d'attaquant. De nombreux schémas de masquage ont été proposés dans la littérature pour réduire les coûts induits ou augmenter le niveau de protection. Un schéma de masquage peut s'avérer compliqué à mettre en œuvre pour des applications com- plexes telles que le chiffrement AES. Pour faciliter la mise en œuvre d'un schéma de masquage, une méthode consiste à composer de façon sécurisée des implémentations masquées.

Dans ce chapitre, nous décrivons en détail la contre-mesure de masquage. Dans la section 3.1, nous introduisons la représentation masquée. Dans la section 3.2, nous décrivons ce qu'est un schéma de masquage. Dans la section 3.3, nous analysons la sécurité apportée par un schéma de masquage dans différents modèles d'attaquant. Dans la section 3.4, nous décrivons différentes méthodes pour composer des implémentations masquées de façon sécurisée. Dans la section 3.5, nous décrivons quelques implémentations masquées de la multiplication.

### 3.1 Représentation masquée

Le masquage est une contre-mesure contre l'attaque SCA. Les premières propositions de masquage ont été réalisées indépendamment par [Cha+99] et [GP99]. Le principe du masquage est d'appliquer un schéma de partage de secret [Sha79] pour randomiser les variables intermé- diaires traitées par un algorithme cryptographique et casser les dépendances statistiques entre les données sensibles et la fuite mesurée.

**Masquage de premier ordre** Le masquage de premier ordre représente une variable sensible $x$ en deux parts telles que chaque part soit statistiquement indépendante de $x$. Par exemple, le masquage booléen représente une variable sensible $x$ par les parts $x \oplus r$ et $r$, où $r$ est une valeur aléatoire uniformément tirée appelée masque. Un attaquant doit donc cibler les deux parts ensembles pour obtenir des informations sur $x$. Par conséquent, les attaques SCA classiques exploitant la fuite liée à une seule variable intermédiaire ne sont plus possibles. Cependant, le masquage de premier ordre est vulnérable aux attaques de second ordre qui exploitent en même temps la fuite liée à $x \oplus r$ et la fuite liée à $r$ (voir par exemple [Mes00b; Osw+05; PRB09]). Pour
atteindre une sécurité contre les attaques d'ordre supérieur, la méthode consiste à augmenter
le nombre de parts.

<figure><img src="image_29.png" /><figcaption>FIGURE 3.1 – Procédure d'encodage et de décodage.</figcaption></figure>

**Masquage d'ordre supérieur** Pour protéger contre les attaques d'ordre supérieur, une variable sensible $x$ est représentée par un vecteur $\hat{x} \in \mathbb{K}^n$ de $n$ parts [Cha+99], appelé un masquage de $x$. On utilise des minuscules en gras avec chapeau $\hat{x}$ pour désigner un masquage d'une variable $x$, et $\hat{x}[i]$ pour désigner la $i^{ème}$ part du masquage $\hat{x}$. Une procédure de masquage Masque : $\mathbb{K} \to \mathbb{K}^n$ est un algorithme probabiliste qui permet de passer en représentation masquée. À partir d'un masquage de $x$, on peut toujours retrouver $x$ en utilisant une procédure de démasquage. Une procédure de démasquage Démasque : $\mathbb{K}^n \to \mathbb{K}$ est un algorithme déterministe vérifiant pour tout $x \in \mathbb{K}$, Démasque(Masque($x$)) = $x$ avec une probabilité égale à 1. Le masquage est dit d'ordre $d$ si tout sous-ensemble de $d$ parts est statistiquement indépendant de $x$. Lorsque $d > 1$, le masquage est dit d'ordre supérieur. Dans la meilleure situation souvent étudiée dans la littérature, l'ordre de masquage est égal à $d = n - 1$, mais l'ordre de masquage peut aussi être inférieur à $n - 1$. Le masquage d'ordre $d$ rend les attaques plus difficiles, car l'attaquant doit au moins connaître plus de $d$ parts pour récupérer la valeur d'une variable sensible. Néanmoins, un masquage d'ordre $d$ est toujours théoriquement vulnérable aux attaques d'ordre $d+1$. Mais en pratique, le bruit implique que la difficulté à réaliser une attaque d'ordre supérieur augmente avec son ordre, ce qui fait de l'ordre de masquage un bon paramètre de sécurité contre les attaques SCA [Cha+99].

<figure><img src="image_30.png" /><figcaption>FIGURE 3.2 – Procédure de masquage (à gauche) et de démasquage (à droite) du masquage booléen.</figcaption></figure>
Masquage booléen d'ordre supérieur Dans ce manuscrit, nous nous intéressons uniquement au masquage booléen d'ordre $d$ [Cha+99; ISW03], abrégé en BM pour « boolean masking » en anglais, dans lequel une variable $x$ est représentée par $d+1$ parts satisfaisant la relation $\hat{x}[0] \oplus \dots \oplus \hat{x}[d] = x$. En pratique, les parts $\hat{x}[1], \dots, \hat{x}[d]$ (appelées les masques) sont des valeurs aléatoires et la part $\hat{x}[0]$ est le XOR de $x$ avec toutes les autres parts (voir figure 3.2 gauche), rendant ainsi tout sous-ensemble de $d$ parts statistiquement indépendant de $x$. Pour démasquer $\hat{x}$, il suffit de calculer le XOR de toutes les parts (voir figure 3.2 droite).

## 3.2 Schéma de masquage

<figure><img src="image_31.png" /><figcaption>FIGURE 3.3 – Schéma de masquage.</figcaption></figure>

Un schéma de masquage est un algorithme permettant de réaliser des calculs en manipulant uniquement des variables masquées tout en préservant certaines propriétés de sécurité. Cette notion est étroitement liée au calcul multi-parties (MPC) [BGW88] qui permet à un ensemble de parties de calculer conjointement une fonction tout en gardant leurs entrées respectives secrètes. L'application d'un schéma de masquage à une implémentation à protéger $\mathbf{F}$ (qui peut être un circuit matériel ou un programme informatique) se divise en trois phases illustrées par la figure 3.3.

1. Premièrement, une phase d'encodage masque les variables d'entrées $x$ à l'ordre de masquage choisi pour donner $\hat{x}$.

2. Deuxièmement, une implémentation masquée de $\mathbf{F}$, notée $\hat{\mathbf{F}}$, est appliquée aux entrées masquées. $\hat{\mathbf{F}}$ a la même fonctionnalité que $\mathbf{F}$ dans le domaine masqué et permet de calculer en utilisant uniquement les variables masquées. De façon plus formelle, $\hat{\mathbf{F}}$ est une implémentation vérifiant pour tout $x$ :

$$ \Pr(\text{Démasque}(\hat{\mathbf{F}}(\text{Masque}(x))) = \mathbf{F}(x)) = 1 $$

3. Troisièmement, une phase de décodage permet de récupérer le résultat du calcul à partir de sa représentation masquée. Ce résultat doit toujours être égal au résultat qu'on aurait obtenu en utilisant l'implémentation non masquée $\mathbf{F}$.
Par exemple, lorsqu'on applique un schéma de masquage à AES, les calculs ne sont pas directement effectués sur la clé de chiffrement $k$ et le message en clair $p$, mais $k$ et $p$ sont préalablement masqués en $\hat{k}$ et $\hat{p}$. Ensuite, une implémentation masquée de AES est appliquée à $\hat{k}$ et $\hat{p}$ pour obtenir un message chiffré masqué $\hat{c}$. Pour terminer, le message chiffré masqué $\hat{c}$ est démasqué pour obtenir le message chiffré attendu.

## Évaluation de la sécurité

L'évaluation de la sécurité d'un schéma de masquage a été lar-
gement étudiée dans la littérature et se divise en deux méthodologies complémentaires. La première méthode consiste à implémenter le schéma de masquage sur un dispositif physique et à réaliser des évaluations pratiques. L'évaluation pratique permet une analyse précise des fuites de l'implémentation réelle. La mise en œuvre pratique de ce type d'évaluation est cependant complexe, car elle nécessite du matériel et une forte expertise des attaques. Et surtout la non réussite d'une attaque ne signifie pas que la solution est sûre ! La deuxième méthode consiste à se placer dans un modèle théorique d'attaquant et de prouver la sécurité d'un schéma de masquage dans ce modèle. Afin de modéliser les capacités d'un attaquant à extraire des informations, plusieurs modèles ont été introduits visant à atteindre différents compromis entre simplicité et précision. Dans la section suivante, nous introduisons différents modèles d'attaquant utilisés dans la littérature.

## 3.3 Modèle théorique d'attaquant

3.3.1 Modélisation des implémentations à protéger

Les implémentations à protéger (circuits matériels ou programmes informatiques) sont préa-
lablement modélisées par un *graphe orienté acyclique* sur un corps $K$ [ISW03; CS21], abrégé en
DAG pour «*directed acyclic graph*» en anglais, dont les arêtes sont des variables intermédiaires
et les sommets sont soit des *fonctions*, des *variables d'entrée*, des *variables de sortie* ou des
*variables aléatoires*. Par exemple, tout circuit combinatoire peut être modélisé par un DAG sur
GF(2) ayant pour sommet les portes booléennes AND, XOR et NOT. Un attaquant est capable
de sonder uniquement les arêtes du DAG. Le modèle d'attaquant dépend donc de la précision
de la modélisation.

3.3.2 Modèle de sondage

Le *modèle de sondage* a initialement été introduit dans [ISW03] pour caractériser un adver-
saire qui serait théoriquement capable de positionner un nombre limité d'aiguilles métalliques
de mesure sur un circuit intégré mettant en œuvre un algorithme cryptographique. Le modèle
de sondage donne à un attaquant la possibilité de sonder jusqu'à *t* arêtes dans le DAG d'une
implémentation masquée comme le montre la figure 3.4. Les arêtes sondées par l'attaquant sont
appelées des *sondes*. Il est supposé que l'attaquant ne peut pas sonder la procédure de masquage
et de démasquage. Une implémentation masquée $\hat{F}$ est sécurisée dans le modèle de sondage avec
*t* sondes si tout ensemble de *t* sondes dans $\hat{F}$ est indépendant des variables sensibles.
<figure><img src="image_32.png" /><figcaption>FIGURE 3.4 – Modèle de sondage.</figcaption></figure>

**Pertinence du modèle** Ce modèle est pratique pour prouver la sécurité d'une implémentation masquée. Cependant, ce modèle n'est pas très réaliste car en pratique un attaquant obtient des fuites bruitées sur le calcul complet et n'a aucune raison d'être limité à t sondes. Pour modéliser plus fidèlement la fuite, le modèle de fuite bruitée a été décrit dans [Cha+99] puis formalisé dans [PR13]. Dans ce modèle, l'adversaire a accès à une fonction bruitée de chaque variable intermédiaire de l'implémentation masquée. Bien que réaliste, ce modèle n'est pas pratique pour les preuves de sécurité. Les implémentations masquées ont donc continué à être vérifiées dans le modèle de sondage en se reposant sur la réduction de sécurité qui a été formellement établie dans [DDF14]. [DDF14] a en effet montré que la sécurité d'une implémentation masquée dans le modèle de fuite bruitée pouvait être obtenue par la sécurité dans le modèle de sondage.

**Preuve de sécurité** Pour prouver en pratique la sécurité dans le modèle de sondage, on utilise le concept de simulation d'une sonde [ISW03] qui permet de décrire les dépendances entre les sondes et les parts d'entrée d'une implémentation masquée. Un ensemble de sondes $\mathcal{P}$ peut être simulé par un ensemble de parts d'entrée $\mathcal{S}$ si et seulement s'il existe un simulateur $\text{Sim}$ tel que les distributions de $\mathcal{P}$ et $\text{Sim}(\mathcal{S})$ soient identiques. Une implémentation masquée est alors sécurisée dans le modèle de sondage à t sondes si tout ensemble de t sondes peut être simulé avec au plus d parts de chaque masquage d'entrée, où d est l'ordre de masquage. En effet, les t sondes peuvent alors être simulées indépendamment des variables sensibles, car le masquage est d'ordre d.

**Implémentation masquée d'une application linéaire** Une application linéaire $\mathcal{L}$ peut être masquée en appliquant $\mathcal{L}$ indépendamment sur chaque part du masquage booléen de l'entrée $x$, noté $\hat{x}$ (voir figure 3.5). Il s'agit d'une implémentation masquée de $\mathcal{L}$ car en démasquant le résultat, on retrouve bien $\mathcal{L}(x)$ :

$$ \mathcal{L}(\hat{\mathbf{x}}[0]) \oplus \cdots \oplus \mathcal{L}(\hat{\mathbf{x}}[d]) = \mathcal{L}(\hat{\mathbf{x}}[0] \oplus \cdots \oplus \hat{\mathbf{x}}[d]) = \mathcal{L}(x) $$

La fonction linéaire ainsi masquée est sécurisée dans le modèle de sondage avec d sondes. En effet, quelle que soit la variable intermédiaire sondée, elle dépend uniquement d'une seule part
de $\hat{x}$. Ainsi, tout ensemble de $d$ sondes est simulable avec $d$ parts de $\hat{x}$, qui sont indépendantes de $x$. Les sondes ne révèlent donc aucune information sur $x$.

<figure><img src="image_33.png" /><figcaption>FIGURE 3.5 – Masquage d'une application linéaire.</figcaption></figure>

**Implémentation masquée d'une application non linéaire** Les fonctions non linéaires sont plus compliquées à masquer que les fonctions linéaires, car elles mélangent plusieurs parts lors des calculs, ce qui peut conduire à une recombinaison des parts. Par exemple, la figure 3.6 de gauche représente une implémentation masquée à l'ordre 1 de la porte AND. En effet, en démasquant le résultat, on retrouve $x \otimes y$ :

$$ 
\begin{aligned}
\hat{z}[0] \oplus \hat{z}[1] &= (\hat{x}[0] \otimes \hat{y}[0]) \oplus (\hat{x}[1] \otimes \hat{y}[0]) \oplus (\hat{x}[0] \otimes \hat{y}[1]) \oplus (\hat{x}[1] \otimes \hat{y}[1]) \\
&= (\hat{x}[0] \oplus \hat{x}[1]) \otimes (\hat{y}[0] \oplus \hat{y}[1]) \\
&= x \otimes y
\end{aligned}
$$

Mais cette implémentation masquée n'est pas sécurisée dans le modèle de sondage même en supposant que les masquages de $x$ et de $y$ sont indépendants. En effet, $\hat{z}[0]$ est égal à $x \otimes \hat{y}[0]$ qui n'est plus indépendant de $x$. On a fait l'erreur de recombiner $\hat{x}[0]$ et $\hat{x}[1]$ dans $\hat{z}[0]$ ce qui a démasqué $x$. Pour éviter de recombiner les parts, des valeurs aléatoires doivent être ajoutées à certains endroits bien choisis comme dans la figure 3.6 de droite. Pour sécuriser la porte AND masquée, une valeur aléatoire $r$ est ajoutée avant de recombiner les deux produits. En démasquant $\hat{z}$, la valeur $r$ disparaît (car $r \oplus r = 0$ dans GF(2)) et on retrouve bien le produit $x \otimes y$. Grâce à la valeur aléatoire $r$, chaque variable intermédiaire est indépendante de $x$ et de $y$ et la porte AND masquée est sécurisée dans le modèle de sondage.

<figure><img src="image_34.png" /><figcaption>FIGURE 3.6 – Porte AND masquée, non sécurisée à gauche et sécurisée à droite dans le modèle de sondage.</figcaption></figure>
#### 3.3.3 Modèle de sondage robuste

La sécurité d'un schéma de masquage repose en grande partie sur l'hypothèse dite de *fuite indépendante* [Cha+99; PR13]. Autrement dit, on suppose généralement que les fuites de différentes valeurs intermédiaires se produisant dans des calculs distincts sont indépendantes les unes des autres. Cependant, cette hypothèse n'est pas toujours vérifiée en pratique dans les implémentations matérielles en raison de défauts physiques. Des défauts physiques tels que les *transitions* de mémoire [MPG05; MPO05; MS06], les *glitchs* [Cor+12; Bal+14], ou les *couplages* [De +17] peuvent engendrer une recombinaison des parts et ainsi dégrader la sécurité des implémentations théoriquement sécurisées dans le modèle de sondage. Le modèle de sondage robuste, introduit dans [Fau+18], étend le modèle de sondage pour capturer les fuites d'information provenant de certains défauts physiques. Ce modèle vise à modéliser avec précision des défauts physiques tout en étant suffisamment simple pour permettre une vérification efficace des implémentations masquées. Pour chaque défaut physique considéré, des sondes étendues ont été introduites pour augmenter le nombre de valeurs observées dans l'implémentation. Une implémentation masquée est sécurisée dans le modèle de sondage robuste à un défaut physique donné si elle est sécurisée dans le modèle de sondage où chaque sonde est étendue pour le défaut physique considéré.

<figure><img src="image_35.png" /><figcaption>FIGURE 3.7 – Exemples de sondes étendues pour les glitchs à gauche, les transitions au centre, les glitchs et transitions à droite. En vert sont réprésentées les sondes de l'attaquant et en rouge les sondes étendues pour le défaut physique considéré.</figcaption></figure>

**Sonde étendue pour les glitchs** Les glitchs sont des transitions de signaux involontaires et indésirables causées par les délais de propagation dans les circuits (voir sous-section 2.3.1). En raison des glitchs, la consommation liée à un fil dépend non seulement de la valeur du fil, mais aussi des données contribuant à sa valeur combinatoire. Afin de modéliser les fuites liées aux glitchs, chaque sonde est étendue en un ensemble de sondes placées sur les sorties des registres et les entrées primaires qui entrent dans le calcul combinatoire de la valeur sondée (voir figure 3.7 gauche).

**Sonde étendue pour les transitions** Les transitions sont des recombinaisons de mémoire causées par l'invocation consécutive d'un circuit. Afin de modéliser les fuites liées aux transitions, chaque sonde placée sur la sortie d'un élément mémoire est étendue en deux sondes, une sur l'entrée et une sur la sortie de l'élément mémoire, doublant ainsi le nombre de sondes (voir figure 3.7 centre).
**Sonde étendue pour les glitches et les transitions** Les transitions et les glitches peuvent également être modélisés simultanément. Les sondes sont d'abord étendues pour les glitches, puis chaque sonde résultante est étendue pour les transitions (voir figure 3.7 droite). Cela correspond à la propriété physique selon laquelle la propagation d'un glitch peut dépendre à la fois de la nouvelle valeur et de la valeur précédente.

### 3.3.4 Modèle de sondage par régions

Pour augmenter la sécurité, le modèle de sondage par régions a été proposé par [ISW03] et formalisé par [ADF16]. Le modèle de sondage par régions est illustré par la figure 3.8. Dans ce modèle, une implémentation masquée $\hat{F}$ est partitionnée en régions $(\hat{F}_1, \hat{F}_2, \dots, \hat{F}_m)$ où chaque $\hat{F}_i$ est un sous-graphe de $\hat{F}$ tel que les portes des sous-graphes $\hat{F}_i$ forment une partition des portes de $\hat{F}$. Une implémentation masquée est alors sécurisée dans le modèle de sondage par régions avec $t$ sondes par région si l'attaquant peut sonder $t$ variables dans chaque région sans compromettre des variables sensibles.

<figure><img src="image_36.png" /><figcaption>FIGURE 3.8 – Modèle de sondage par régions.</figcaption></figure>

**Pertinence du modèle** La réduction de sécurité de [DDF14] permet de montrer la sécurité d'une implémentation masquée dans le modèle de fuite bruitée à partir de la sécurité dans le modèle de sondage. Elle fait intervenir un modèle d'attaquant intermédiaire, appelé *modèle de sondage aléatoire*, dans lequel la valeur de chaque fil est transmise à l'attaquant avec une probabilité donnée $p$, appelée *taux de fuite*. Les implémentations masquées et sécurisées dans le modèle de sondage sont sécurisées dans le modèle de sondage aléatoire, mais le taux de fuite toléré n'est pas constant par rapport à l'ordre de masquage, ce qui n'est pas satisfaisant d'un point de vue pratique. Le *modèle de sondage par régions* permet d'améliorer le taux de fuite toléré, et ainsi d'augmenter la sécurité dans le modèle de fuite bruitée.
3.4 Composition d'implémentations masquées

La sécurité d'une implémentation masquée dans le modèle de sondage peut être vérifiée en
utilisant des outils formels (par exemple [Bar+19b; KSM20]). Si de tels outils sont très utiles
pour évaluer la sécurité d'implémentations concrètes et développer des implémentations sécuri-
sées, ils sont limités par leur complexité exponentielle par rapport à la taille de l'implémentation
et l'ordre de masquage. Par exemple, ces outils ne permettent pas de prouver la sécurité dans
le modèle de sondage d'une implémentation masquée de AES. Pour masquer une application
complexe telle que AES, une méthode illustrée à la figure 3.9 consiste à diviser l'application en
sous-fonctions G₁, ..., Gm suffisamment petites pour être facilement masquées en Ĝ₁, ..., Ĝm.
En composant les différentes sous-fonctions masquées, on obtient alors une implémentation
masquée de l'application complexe. Cependant, la composition d'implémentation masquées sé-
curisées dans le modèle de sondage n'est pas nécessairement sécurisée dans le modèle de sondage
[Cor+14]. Différentes méthodes ont alors été proposées pour composer de façon sécurisée des
implémentations masquées.

<figure><img src="image_37.png" /><figcaption>FIGURE 3.9 – Composition d'implémentations masquées.</figcaption></figure>

3.4.1 Schéma de masquage ISW

[ISW03] ont proposé un schéma de masquage, que nous nommons ISW, pour masquer des
circuits booléens composés de portes AND et NOT. Leur approche consiste à remplacer chaque
porte par un circuit masqué de la porte basé sur un masquage booléen d'ordre d. Chaque
porte NOT est remplacée par un circuit masqué qui consiste simplement à appliquer une porte
NOT sur l'une des parts. L'exactitude s'ensuit simplement puisque NOT(x) = NOT(\hat{x}[0]) ⊕
\hat{x}[1] ⊕ ... ⊕ \hat{x}[d] pour tout masquage booléen \hat{x} de x. Chaque porte AND est remplacée par le
circuit masqué décrit dans l'algorithme 3 qui permet de masquer la porte AND à des ordres
supérieurs. La porte AND masquée à l'ordre d a une complexité en O(d²) et utilise d(d + 1)/2
aléas. Chaque fil du circuit est également remplacé par n = d + 1 fils transportant un masquage
du fil. Tout circuit composé de M portes est alors transformé en un circuit masqué de taille
O(Md²). Le circuit masqué à l'ordre d résultant du schéma de masquage est en outre sécurisé
dans le modèle de sondage à d/2 sondes. Cette solution nécessite ainsi de doubler le nombre de
parts par rapport au nombre de sondes.
**Algorithmme 3** Porte AND masquée de [ISW03]

**Entrée:** Masquage $\hat{\mathbf{x}} \in \text{GF}(2)^{d+1}$ de $x$ et masquage $\hat{\mathbf{y}} \in \text{GF}(2)^{d+1}$ de $y$

**Sortie:** Masquage $\hat{\mathbf{z}} \in \text{GF}(2)^{d+1}$ de $z$ tel que $\bigoplus_i \hat{\mathbf{z}}[i] = x \otimes y$

pour $i = 0$ à $d$ faire

pour $j = i + 1$ à $d$ faire

$$r_{i,j} \leftarrow \mathbb{K}_2$$

$$u_{i,j} \leftarrow r_{i,j}$$

$$u_{j,i} \leftarrow r_{i,j} \oplus (\hat{\mathbf{x}}[i] \otimes \hat{\mathbf{y}}[j]) \oplus (\hat{\mathbf{x}}[j] \otimes \hat{\mathbf{y}}[i])$$

fin pour

fin pour

pour $i = 0$ à $d$ faire

$$\hat{\mathbf{z}}[i] \leftarrow (\hat{\mathbf{x}}[i] \otimes \hat{\mathbf{y}}[i]) \oplus \bigoplus_{j=0, j \neq i}^{d} u_{i,j}$$

fin pour

### 3.4.2 Schéma de masquage RP

[RP10] ont proposé un schéma de masquage d'ordre $d$, que nous nommons RP, atteignant la sécurité contre un attaquant pouvant sonder $d$ sondes. Ils montrent notamment que la porte AND masquée de ISW atteint cette sécurité de sondage minimale en supposant que les deux masquages d'entrée sont mutuellement indépendants. [RP10] ont également observé que la preuve de sécurité de [ISW03] était valable pour tout corps fini et pas seulement GF(2). Le schéma de masquage ISW a ainsi été adapté à AES en travaillant sur GF(2$^8$) au lieu de GF(2). Cependant, la composition directe d'implémentations masquées n'est pas nécessairement sécurisée lorsque les masquages d'entrée de certaines multiplications ne sont plus mutuellement indépendants. Pour maintenir l'indépendance des masquages d'entrée des multiplications, [RP10] ont suggéré de rafraîchir le masquage d'une des entrées en ajoutant des valeurs aléatoires. L'algorithme 4 présente une méthode de rafraîchissement proposée dans [RP10]. Elle consiste simplement à ajouter aux $n - 1$ premières parts un nouveau masque aléatoire et à accumuler la somme des masques dans la dernière part.

**Algorithmme 4** Méthode de rafraîchissement de [RP10]

**Entrée:** Masquage $\hat{\mathbf{x}} \in \mathbb{K}^{d+1}$ de $x$

**Sortie:** Masquage $\hat{\mathbf{y}} \in \mathbb{K}^{d+1}$ de $y$ tel que $\bigoplus_i \hat{\mathbf{y}}[i] = x$

$$\hat{\mathbf{y}}[d] \leftarrow \hat{\mathbf{x}}[d]$$

pour $i = 0$ à $d - 1$ faire

$$r_i \leftarrow \mathbb{K}$$

$$\hat{\mathbf{y}}[d] \leftarrow \hat{\mathbf{y}}[d] \oplus r_i$$

$$\hat{\mathbf{y}}[i] \leftarrow \hat{\mathbf{x}}[i] \oplus r_i$$

fin pour

[Cor+14] ont cependant montré que l'utilisation de la méthode de rafraîchissement de l'algorithme 4 ne permettait pas d'atteindre la sécurité de sondage minimale. Pour obtenir la sécurité de sondage minimale, une nouvelle méthode de rafraîchissement a été proposée dans [DDF14;
Bar+16] consistant à appliquer une multiplication masquée ISW entre le masquage d'entrée et le tuple (1, 0, ..., 0). Notez que cette méthode de rafraîchissement ne nécessite pas l'évaluation complète de la multiplication masquée ISW, mais peut être calculée comme décrit dans l'algorithme 5. Rafraîchir le masquage d'entrée d'une multiplication masquée implique une perte en performance, mais c'est mieux que de doubler le nombre de parts.

<caption>**Algorithmme 5** Méthode de rafraîchissement basée sur la multiplication masquée ISW [Bar+16]</caption>

**Entrée:** Masquage $\hat{\mathbf{x}} \in \mathbb{K}^{d+1}$ de $x$

**Sortie:** Masquage $\hat{\mathbf{y}} \in \mathbb{K}^{d+1}$ de $y$ tel que $\bigoplus_{i} \hat{\mathbf{y}}[i] = x$

**pour** $i = 0$ à $d$ **faire**
$$ \hat{\mathbf{y}}[i] \leftarrow \hat{\mathbf{x}}[i] $$

**fin pour**

**pour** $i = 0$ à $d$ **faire**

**pour** $j = i + 1$ à $d$ **faire**
$$ r_{i,j} \leftarrow \mathbb{K} $$
$$ \hat{\mathbf{y}}[i] \leftarrow \hat{\mathbf{y}}[i] \oplus r_{i,j} $$
$$ \hat{\mathbf{y}}[j] \leftarrow \hat{\mathbf{y}}[j] \oplus r_{i,j} $$

**fin pour**

**fin pour**

### 3.4.3 Implémentations de seuil

Les *implémentations de seuil*, abrégées en TI pour «*threshold implementation*» en anglais, ont été introduites dans [NRR06; NRS11] pour protéger les implémentations matérielles contre un attaquant pouvant sonder une variable. L'idée centrale de TI est le concept d'incomplétude. Un circuit combinatoire est incomplet si chaque sous-circuit contribuant au calcul d'une part de sortie n'utilise pas toutes les parts d'entrée. TI a ensuite été étendue par [Bil+14b] pour se protéger d'un attaquant ayant plusieurs sondes. [Bil+14b] ont introduit la notion d'incomplétude d'ordre $d$. Un circuit combinatoire est incomplet d'ordre $d$ si tout ensemble de $d$ sous-circuits contribuant au calcul d'une part de sortie n'utilise pas toutes les parts d'entrée. La sécurité dans le modèle de sondage découle immédiatement de l'incomplétude. TI est également sécurisée en présence de glitchs [NRR06; NRS11]. En effet, l'incomplétude assure que chaque sous-circuit combinatoire calculant une part de sortie n'utilise pas toutes les parts d'entrée et ne fournit donc aucune information sur l'entrée non masquée même en présence de glitchs. TI a été appliquée à de nombreuses implémentations matérielles masquées [Mor+11; Bil+14a; De +15; UHA17]. Cependant, le niveau de sécurité apporté par TI n'est pas optimal, car une implémentation masquée à l'ordre $d$ est seulement sécurisée par sondage de $d/2$ sondes. Comme pour le schéma ISW, le nombre de parts est doublé par rapport au nombre de sondes.

**Exemple** Nous illustrons ce concept en développant une implémentation de seuil masquée à l'ordre 2 de la porte AND réalisant $c = a \otimes b$. On cherche à définir trois circuits $f_0$, $f_1$ et $f_2$ qui calculent respectivement $\hat{c}[0]$, $\hat{c}[1]$ et $\hat{c}[2]$ de sorte que l'incomplétude soit vérifiée. La méthode consiste à exprimer la forme normale algébrique du circuit à masquer en fonction des parts
d'entrée et de distribuer en conséquence chaque terme dans les parts de sortie. Une solution est donnée par :

$$
\begin{align*}
\hat{c}[0] &= (\hat{a}[1] \otimes \hat{b}[1]) \oplus (\hat{a}[1] \otimes \hat{b}[2]) \oplus (\hat{a}[2] \otimes \hat{b}[1]) \\
\hat{c}[1] &= (\hat{a}[0] \otimes \hat{b}[2]) \oplus (\hat{a}[2] \otimes \hat{b}[0]) \oplus (\hat{a}[2] \otimes \hat{b}[2]) \\
\hat{c}[2] &= (\hat{a}[0] \otimes \hat{b}[0]) \oplus (\hat{a}[0] \otimes \hat{b}[1]) \oplus (\hat{a}[1] \otimes \hat{b}[0])
\end{align*}
$$

On note que $\hat{c}[i]$ ne dépend ni de $\hat{a}[i]$ ni de $\hat{b}[i]$ garantissant ainsi l'incomplétude. Cette porte AND masquée est donc sécurisée par sondage d'une sonde. Cette méthode peut être appliquée à d'autres fonctions avec différents nombres de parts d'entrée ou de sortie.

**Composition** Les circuits combinatoires incomplets peuvent être composés en intercalant des registres de synchronisation pour arrêter la propagation des glitches. Cependant, une condition préalable importante est que chaque circuit combinatoire incomplet a un masquage uniforme en entrée. La composition proposée par [Bil+14b] s'est ainsi avérée vulnérable dans [Rep15] par manque d'uniformité des masquages d'entrée. Pour assurer l'uniformité des masquages d'entrée, [Rep15] ont proposé d'ajouter des aléas supplémentaires avant les registres de synchronisation (par exemple en rafraîchissant les masquages, voir 3.4.2).

3.4.4 Propriété de composition NI et SNI

Dans une première tentative de proposer une propriété de composition générique, [Bar+15]
ont introduit la notion de *non-interférence*, abrégée en NI, pour assurer la sécurité de la com-
position d'implémentations masquées en utilisant le concept de *simulation d'une sonde* (voir
sous-section 3.3.2). Cette propriété assure que les sondes internes et les sondes de sortie sont
simulables par un sous-ensemble limité des parts d'entrée de l'implémentation masquée, comme
illustré sur la figure 3.10.

<figure><img src="image_38.png" /><figcaption>FIGURE 3.10 – 3-NI illustré sur une implémentation masquée à l'ordre 3.</figcaption></figure>

La non-interférence s'est cependant avérée insuffisante pour assurer la sécurité de la compo-
sition d'implémentations masquées [Bar+15]. La non-interférence forte [Bar+16], abrégée en
SNI pour « strong non-interference » en anglais, a alors été proposée pour limiter encore davan-
tage le nombre de parts nécessaires pour simuler les sondes, comme le montre la figure 3.11. Les
propriétés de composition NI/SNI étaient initialement limitées aux implémentations masquées
à une seule sortie, puis ont été étendues dans [CS20] pour couvrir également les implémenta-
tions masquées à sorties multiples. La définition suivante décrit la propriété NI/SNI de façon
plus formelle.

**Definition 1** (*t*-non-interférence (forte) [Bar+16]). *Une implémentation masquée avec* *k* *entrées et une sortie est t-NI (resp., t-SNI)*, *si pour chaque ensemble *I* de *t*<sub>*i*</sub> *sondes internes et pour chaque ensemble O de t*<sub>*s*</sub> *sondes de sortie telles que t*<sub>*i*</sub> + *t*<sub>*s*</sub> ≤ *t*, l'ensemble de sondes I ∪ O peut être simulé avec t*<sub>*i*</sub> + t*<sub>*s*</sub>* (resp., t*<sub>*i*</sub>* parts de chaque entrée).*

<figure><img src="image_39.png" /><figcaption>FIGURE 3.11 – 3-SNI illustré sur une implémentation masquée à l'ordre 3.</figcaption></figure>

[Bar+16] ont montré que *t*-NI implique la sécurité dans le modèle de sondage à *t* sondes. En effet, l'ensemble des sondes pouvant être simulé par au plus *t* parts de chaque masquage d'entrée, elles sont indépendantes de toutes variables sensibles tant que *t* est inférieur ou égal à l'ordre de masquage. De plus, *t*-SNI implique *t*-NI et donc la sécurité dans le modèle de sondage à *t* sondes.

**Composition** La différence entre SNI et NI réside uniquement dans le nombre de parts d'en-
trée pouvant être utilisé pour la simulation. En rendant ce nombre indépendant du nombre
de sondes de sortie, SNI assure une séparation entre les parts de sortie et d'entrée, ce qui
permet une composition générique. En effet, toute composition d'implémentations masquées
*t*-SNI (dans laquelle deux masquages d'entrée d'une implémentation masquée ne sont jamais
identiques) est également *t*-SNI [Bar+16], et donc sécurisée dans le modèle de sondage avec
*t* sondes. Utiliser uniquement des implémentations masquées SNI dans la composition peut
induire des coûts importants. Pour réduire les coûts, [Bar+16] ont présenté une méthode de
composition sécurisée utilisant à la fois des implémentations masquées NI et SNI. Ils ont montré
qu'une composition d'implémentations masquées est *d*-NI si toutes les implémentations mas-
quées sont *d*-NI ou *d*-SNI, selon la règle de composition suivante : chaque masquage est utilisé
au plus une fois comme entrée d'une implémentation masquée autre qu'un rafraîchissement
*d*-SNI. [Bar+16] ont développé un compilateur pour masquer une implémentation et rafraîchir
les masquages nécessaires pour assurer une composition sécurisée. Ce compilateur génère une
implémentation masquée en langage C. Ce compilateur a ensuite été amélioré par [BGR18]
pour rafraîchir le nombre minimum de variables masquées dans une implémentation masquée.
**Exemples d'implémentations masquées (S)NI** La fonction linéaire masquée à l'ordre $d$ présentée à la section 3.3.2 est $d$-NI car toutes les sondes sur $L(\hat{\mathbf{x}}[i])$ sont simulables par la part d'entrée $\hat{\mathbf{x}}[i]$. Cependant, cette implémentation masquée n'est pas $d$-SNI, car pour simuler $d$ parts de sortie différentes, un simulateur doit avoir accès aux $d$ parts d'entrée correspondantes. On peut rendre $d$-SNI l'implémentation masquée d'une fonction linéaire en appliquant au masquage de sortie un rafraîchissement $d$-SNI. La multiplication masquée ISW à l'ordre $d$ de l'algorithme 3 a été démontrée $d$-SNI par [Bar+16]. Ils ont également montré que la méthode de rafraîchissement basée sur la multiplication masquée ISW de l'algorithme 5 est $d$-SNI alors que la méthode de rafraîchissement de l'algorithme 4 est seulement $d$-NI. La vulnérabilité de composition du schéma de [RP10] démontrée par [Cor+14] provient du fait que la méthode de rafraîchissement de l'algorithme 4 n'est pas $d$-SNI.

### 3.4.5 Propriété de composition PINI

NI et SNI offrent une méthode simple de composer en toute sécurité des implémentations masquées. Cependant, cette méthode nécessite l'utilisation de nombreux rafraîchissements de masquage coûteux. Les rafraîchissements de masquage sont nécessaires car la fonction linéaire masquée n'est pas SNI. Cela suggère naturellement la recherche d'une propriété assurant la sécurité de la composition d'implémentations masquées, tout en tirant parti de l'efficacité du masquage des fonctions linéaires.

<figure><img src="image_40.png" /><figcaption>FIGURE 3.12 – 3-PINI illustré sur une implémentation masquée à l'ordre 3.</figcaption></figure>

**Non-interférence isolant la sonde** [CS20] ont proposé une propriété de composition appelée *non-interférence isolant la sonde*, abrégée en PINI pour «*probe isolating non-interference*» en anglais. Pour qu'une implémentation masquée soit PINI, chaque sonde de sortie doit être simulable avec les parts d'entrée de même indice que la sonde de sortie, tandis que chaque sonde interne doit être simulable avec les parts d'entrée d'un indice unique (mais arbitraire). La figure 3.12 illustre la propriété PINI avec une implémentation masquée à l'ordre 3. La définition suivante décrit la propriété PINI de façon plus formelle.
**Definition 2** (*t*-non-interférence isolant la sonde (PINI) [CS20]). Une implémentation masquée est *t*-PINI, si pour chaque ensemble *I* de $t_i$ sondes internes, pour chaque ensemble *A* de $t_o$ indices de parts, tels que $t_i + t_o \le t$, il existe un ensemble *B* d'au plus $t_i$ indices de parts tels que l'ensemble de sondes $I \cup \hat{y}[A]$ peut être simulé avec les parts d'entrée d'indices $A \cup B$.

[CS20] ont montré que toute implémentation masquée d-PINI est sécurisée dans le modèle de sondage avec *d* sondes. De plus, le masquage d'une application linéaire est d-PINI. La propriété PINI permet également une composition directe car la composition d'implémentations masquées d-PINI est d-PINI. [Cas+20] ont montré que la composition directe d'implémentations masquées d-PINI restait sécurisée dans le modèle de sondage robuste aux glitchs. Pour faire face aux transitions de données entre différents cycles d'horloge, [CS21] ont défini la notion plus forte de non-interférence d'isolation de sonde de sortie, abrégée en O-PINI pour « output probe isolating non-interference » en anglais. O-PINI permet de composer de façon sécurisée dans le modèle de sondage robuste aux transitions et glitchs. Une grande variété d'implémentations masquées PINI ont été récemment introduites [CS20; Cas+20; KSM21; CS21; KM22]. Ils diffèrent par le nombre d'aléas nécessaires, leur latence et leur robustesse contre les glitchs et les transitions.

## 3.5 Multiplication masquée

Dans cette section, nous établissons un état de l'art des différentes multiplications masquées proposées dans la littérature. Nous nous intéresserons d'abord aux multiplications masquées en logiciel, puis à celles masquées en matériel.

### 3.5.1 Multiplication masquée en logiciel

**Multiplication masquée (S)NI** [Bar+16] ont montré que la multiplication masquée ISW de l'algorithme 3 ainsi que la méthode de rafraîchissement de l'algorithme 5 sont *d*-SNI. [Bel+16] ont ensuite proposé une multiplication masquée *d*-NI avec un coût en aléas réduit à $d^2/4 + d$, et qui peut être facilement instanciée sur n'importe quel corps fini de caractéristique 2. Bien que la propriété de composition vérifiée soit plus faible que celle obtenue par la multiplication masquée ISW, elle peut être utilisée en pratique pour réduire la complexité des implémentations masquées. Par exemple, on peut remplacer la moitié des multiplications dans l'implémentation masquée de la SBOX de AES (voir figure 4.6) par celles de [Bel+16] tout en maintenant la sécurité globale *d*-SNI. Dans [Bel+17], les mêmes auteurs proposent deux nouvelles multiplications masquées *d*-SNI applicables sur tout corps fini autre que GF(2), l'une avec un nombre linéaire de multiplications et l'autre avec un coût linéaire d'aléas. [Bar+17] ont introduit des multiplications masquées et méthodes de rafraîchissement NI et SNI efficaces en logiciel qui ont ensuite été améliorées dans [Gré+18; Gou+18; Bar+19a]. [Bat+16] ont proposé une multiplication masquée et une méthode de rafraîchissement SNI renforçant la sécurité contre les attaques horizontales et ayant une complexité en nombres aléatoires en $O(d \log d)$.

**Multiplication masquée PINI** [CS20] ont montré que la multiplication masquée «double SNI» proposée dans [GR17], qui consiste à appliquer un rafraîchissement SNI à un des masquages d'entrée de chaque multiplication masquée SNI, est *d*-PINI. Cette méthode est cependant assez conservative et induit des coûts importants en temps d'exécution et en nombre
d'aléas. Pour réduire les coûts, [CS20] ont introduit la multiplication masquée à l'ordre $d$ décrite dans l'algorithme 6, nommée PINI$_1$, qui est $d$-PINI et nécessite $d(d+1)/2$ aléas. PINI$_1$ est inspirée de la multiplication masquée ISW, en remplaçant le calcul de $\hat{\mathbf{x}}[i] \otimes \hat{\mathbf{y}}[j] \oplus r_{i,j}$ par $\hat{\mathbf{x}}[i] \otimes (\hat{\mathbf{y}}[j] \oplus r_{i,j}) \oplus (\hat{\mathbf{x}}[i] \oplus 1) \otimes r_{i,j}$. Aucune des valeurs intermédiaires de ce calcul ne nécessite la connaissance à la fois de $\hat{\mathbf{x}}[i]$ et de $\hat{\mathbf{y}}[j]$ pour être simulée.

**Algorithmme 6** Multiplication masquée PINI$_1$ de [CS20].

**Entrée:** Masquage $\hat{\mathbf{x}} \in \mathbb{K}^{d+1}$ de $x$ et masquage $\hat{\mathbf{y}} \in \mathbb{K}^{d+1}$ de $y$

**Sortie:** Masquage $\hat{\mathbf{z}} \in \mathbb{K}^{d+1}$ de $z$ tel que $\bigoplus_i \hat{z}[i] = xy$

pour $i = 0$ à $d$ faire

pour $j = i + 1$ à $d$ faire

$$r_{i,j} \leftarrow \mathbb{K}$$

$$u_{i,j} \leftarrow \hat{\mathbf{x}}[i] \otimes (\hat{\mathbf{y}}[j] \oplus r_{i,j}) \oplus (\hat{\mathbf{x}}[i] \oplus 1) \otimes r_{i,j}$$

$$u_{j,i} \leftarrow \hat{\mathbf{x}}[j] \otimes (\hat{\mathbf{y}}[i] \oplus r_{i,j}) \oplus (\hat{\mathbf{x}}[j] \oplus 1) \otimes r_{i,j}$$

fin pour

fin pour

pour $i = 0$ à $d$ faire

$$\hat{z}[i] \leftarrow \hat{\mathbf{x}}[i] \otimes \hat{\mathbf{y}}[i] \oplus \bigoplus_{j=0, j \neq i}^{d} u_{i,j}$$

fin pour

### 3.5.2 Multiplication masquée en matériel

**Multiplication masquée (S)NI** Plusieurs multiplications masquées en matériel ont été proposées sans preuve de sécurité à un ordre arbitraire. Nous pouvons notamment citer le *schéma de masquage consolidé* (CMS) [Rep+15; Cnu+16], le *masquage orienté domaine* (DOM) [GMK16; GMK17], l'approche de masquage unifiée (UMA) [GM17; GM18] et le *masquage générique à faible latence* (GLM) [GIB18]. [Moo+19] a montré que CMS, CMS et GLM avaient des failles de sécurité (locales ou de composabilité) dans le modèle de sondage robuste. Seule la multiplication masquée DOM proposée par [GMK16] et décrite dans l'algorithme 7 s'est avérée sécurisée dans le modèle de sondage robuste aux glitchs. [Fau+18] ont en effet montré que la multiplication DOM masquée à l'ordre $d$ est $d$-NI et qu'elle peut être rendue $d$-SNI en stockant les parts de sortie dans des registres. Pour réduire la latence de la multiplication masquée $d$-SNI DOM à un cycle d'horloge, [MPZ21] ont adapté la solution basée sur le *schéma de masquage consolidé* proposée dans [Rep+15] en ajoutant des sommes pré-calculées de bits aléatoires.

**Multiplication masquée PINI** [Cas+20] ont proposé plusieurs multiplications masquées en matériel. Ils ont tout d'abord montré que la multiplication «double SNI» utilisant la multiplication DOM était PINI en présence de glitchs. «Double SNI» a une latence de 4 cycles d'horloge et nécessite $d(d+1)$ aléas. Plusieurs multiplications masquées PINI, nommées HPC pour «hard-ware private circuits» en anglais, ont également été proposées dans [Cas+20] pour améliorer les performances. HPC1 est une multiplication DOM dont on a ajouté à une des entrées un masquage de 0 généré par un rafraîchissement SNI. HPC1 nécessite le même nombre d'aléas que «double SNI», mais a une latence divisée par deux. [Cas+20] ont proposé la multiplication
**Algorithmme 7** Multiplication masquée DOM de [GMK16]. Le crochet $[\cdot]_{\text{reg}}$ indiquent que l'argument est stocké dans un registre.

**Entrée:** Masquage $\hat{\mathbf{x}} \in \mathbb{K}^{d+1}$ de $x$ et masquage $\hat{\mathbf{y}} \in \mathbb{K}^{d+1}$ de $y$

**Sortie:** Masquage $\hat{\mathbf{z}} \in \mathbb{K}^{d+1}$ de $z$ tel que $\bigoplus_i \hat{\mathbf{z}}[i] = x \otimes y$

pour $i = 0$ à $d$ faire

pour $j = i + 1$ à $d$ faire

$$r_{i,j} \leftarrow \mathbb{K}$$

$$u_{i,j} \leftarrow [\hat{\mathbf{x}}[i] \otimes \hat{\mathbf{y}}[j] \oplus r_{i,j}]_{\text{reg}}$$

$$u_{j,i} \leftarrow [\hat{\mathbf{x}}[j] \otimes \hat{\mathbf{y}}[i] \oplus r_{i,j}]_{\text{reg}}$$

fin pour

fin pour

pour $i = 0$ à $d$ faire

$$\hat{\mathbf{z}}[i] \leftarrow \hat{\mathbf{x}}[i] \otimes \hat{\mathbf{y}}[i] \oplus \bigoplus_{j=0, j \neq i}^{d} u_{i,j}$$

fin pour

masquée HPC2, adaptée de PINI₁, qui réduit le nombre d'aléas à $d(d+1)/2$ avec une latence de deux cycles d'horloge. [KSM21] ont présenté GHPC qui permet la construction d'implémentations masquées PINI réalisant n'importe quelle fonction booléenne mais limitée à la sécurité de premier ordre dans le modèle de sondage robuste aux glitchs. GHPC ne nécessite qu'un aléa par bit de sortie et 2 cycles d'horloge, mais induit une surface relativement importante. Dans [KSM21], les auteurs ont en outre introduit GHPCLL, une variante à faible latence de GHPC, qui ne nécessite qu'un seul étage de registre pour calculer toute fonction booléenne, mais nécessite $2n$ nouveaux bits aléatoires par bit de sortie pour une fonction booléenne à $n$ entrées. Pour réduire la latence à un cycle d'horloge, [KM22] propose la multiplication masquée PINI nommée HPC3. En contrepartie, le nombre d'aléas nécessaire est doublé par rapport à HPC2. Pour sécuriser dans le modèle de sondage robuste aux glitchs et transitions, [CS21] réalise une multiplication masquée nommée O-PINI1 qui est O-PINI. Leur construction est directement basée sur HPC2, ajoutant seulement un rafraîchissement supplémentaire en sortie. Cependant, cette multiplication masquée est soit résistante aux glitchs, soit résistante aux transitions, mais

<table><caption>TABLE 3.1 – Résumé des différentes multiplications masquées en matériel.</caption><thead><tr><th>Nom</th><th>Réf.</th><th>Fonction</th><th>Ordre</th><th>Composition</th><th>Latence</th><th>Nb. bits d'aléas</th></tr></thead><tbody><tr><td>DOM</td><td>[GMK16]</td><td>AND</td><td>d ≥ 1</td><td>SNI</td><td>2</td><td>d(d + 1)/2</td></tr><tr><td>CML<sub>LL</sub></td><td>[MPZ21]</td><td>AND</td><td>d ≥ 1</td><td>SNI</td><td>1</td><td>2(d + 1)<sup>2</sup></td></tr><tr><td>Double SNI</td><td>[Cas+20]</td><td>AND</td><td>d ≥ 1</td><td>PINI</td><td>4</td><td>d(d + 1)</td></tr><tr><td>HPC1</td><td>[Cas+20]</td><td>AND</td><td>d ≥ 1</td><td>PINI</td><td>2</td><td>d(d + 1)</td></tr><tr><td>HPC2</td><td>[Cas+20]</td><td>AND</td><td>d ≥ 1</td><td>PINI</td><td>2</td><td>d(d + 1)/2</td></tr><tr><td>GHPC</td><td>[KSM21]</td><td>F : F<sub>2</sub><sup>n</sup> ↦→ F<sub>2</sub><sup>m</sup></td><td>1</td><td>PINI</td><td>2</td><td>m</td></tr><tr><td>GHPC<sub>LL</sub></td><td>[KSM21]</td><td>F : F<sub>2</sub><sup>n</sup> ↦→ F<sub>2</sub><sup>m</sup></td><td>1</td><td>PINI</td><td>1</td><td>2<sup>n</sup> × m</td></tr><tr><td>HPC3</td><td>[KM22]</td><td>AND</td><td>d ≥ 1</td><td>PINI</td><td>1</td><td>d(d + 1)</td></tr><tr><td>O-PINI2</td><td>[CS21]</td><td>AND</td><td>d ≥ 1</td><td>O-PINI</td><td>3</td><td>d(d + 1)/2 + d</td></tr><tr><td>HPC3<sup>+</sup></td><td>[KM22]</td><td>AND</td><td>d ≥ 1</td><td>O-PINI</td><td>2</td><td>d(d + 1) + d</td></tr></tbody></table>
pas les deux en même temps. [CS21] introduit O-PINI2 dans le but d'obtenir une composabilité directe en présence de transitions et de glitchs en même temps. Par rapport à O-PINI1, des registres supplémentaires sont introduits après le rafraîchissement engendrant une latence globale de 3 cycles d'horloge. [KM22] ont ensuite adapté HPC3 pour sécuriser contre les transitions et les glitchs en seulement 2 cycles d'horloge. Le tableau 3.1 résume les différentes méthodes de l'état de l'art pour masquer la multiplication en matériel.
# Chapitre 4

## Techniques d'implémentations

Dans ce chapitre, nous décrivons les différentes techniques d'implémentations logicielles du chiffrement AES. Ces implémentations sont basées sur du calcul direct, sur des tables précalculées, ou sur une technique appelée « bit slicing ». Dans la littérature, différentes implémentations logicielles masquées de AES ont également été proposées. Elles utilisent les différentes techniques décrites au chapitre 3, ainsi que d'autres méthodes telles que les tables masquées, le « bit slicing » masqué ou le « share slicing » qui seront présentées dans la suite.

Dans la section 4.1, nous décrivons les implémentations logicielles du chiffrement AES ne comportant pas de protection contre l'attaque SCA. Dans la section 4.2, nous introduisons différentes techniques de masquage du chiffrement AES de l'état de l'art.

### 4.1 Implémentations logicielles de AES

#### 4.1.1 Calcul direct

Certaines implémentations de AES favorisent le calcul direct, réduisant ainsi l'empreinte mémoire au prix d'une latence accrue. Dans [DR02] est proposée une implémentation, que nous nommons SW-BW, consistant à placer chaque octet de l'état et de la clé de ronde dans des registres différents et à calculer chaque fonction de ronde de manière directe. Sur des plateformes 32 bits, [Ber+02] ont proposé une implémentation, que nous nommons SW-RW, qui améliore la latence d'exécution en plaçant chaque ligne de l'état et de la clé de ronde dans des registres différents. De cette façon, ShiftRows peut être implémentée à l'aide d'instructions de rotation.

**Implémentation de la SBOX** Il existe différentes possibilités pour implémenter en logiciel la fonction SBOX. Une possibilité est de calculer la fonction SBOX au moment de l'exécution en utilisant les instructions de base du processeur. La SBOX de AES réalise le calcul de l'inverse dans $GF(2^8)$ suivi d'une application linéaire sur $GF(2)$. En utilisant le petit théorème de Fermat, on obtient $x^{-1} = x^{254}$ et on peut réduire le calcul de $x^{254}$ en une séquence de multiplications et de carrés décrite à la figure 4.1. Ce type d'implémentation induit cependant une latence d'exécution élevée car les jeux d'instructions de base sont rarement efficaces pour calculer sur des corps finis. Alternativement, la fonction SBOX peut être implémentée sous la forme d'une table contenant les 256 valeurs possibles. Cela nécessite le calcul préalable et le stockage d'une table de 256 octets, mais réduit considérablement la latence d'exécution.
<figure><img src="image_41.png" /><figcaption>FIGURE 4.1 – Inversion dans GF(2$^8$).</figcaption></figure>

4.1.2 Tables pré-calculées

Les implémentations de AES utilisant des tables pré-calculées favorisent le pré-calcul, ré-
duisant la latence mais augmentant l'empreinte mémoire. Le principal exemple de cette tech-
nique est la méthode dite des T-tables [DR02], que nous nommons SW-TTABLE. Cette tech-
nique place chaque colonne de l'état et de la clé de ronde dans des registres différents. Puis,
MixColumn ◦ SubBytes est pré-calculée à l'aide de 4 tables. Chaque ronde devient une séquence
de recherches de table et de XOR pour combiner leurs résultats. Cela nécessite le pré-calcul
et le stockage de 1 ko par table. De plus, dans les systèmes avec des caches de données, les
implémentations basées sur des tables sont sensibles aux attaques temporelles [Tsu+03; Ber05;
BM06].

4.1.3 Implémentation «bit slicing»

Le «bit slicing», abrégé en BS, est une technique d'implémentation introduite par [Bih97],
pour favoriser le parallélisme dans les calculs booléens. Sans BS, chaque registre de 32 ou 64
bits ne contient que 1 bit d'information, ce qui n'est pas optimal. En regroupant plusieurs bits
de données indépendantes dans un même registre, on obtient des calculs booléens sur 32 ou 64
bits en même temps à chaque cycle.

<figure><img src="image_42.png" /><figcaption>FIGURE 4.2 – Représentation «bit slicing» de 32 blocs de 128 bits dans 128 mots machines ($M_i, 0 \le i \le 127$) d'une architecture 32 bits. $b_i^j$ désigne le $i$-ième bit du $j$-ième bloc.</figcaption></figure>

**Implémentation BS de cryptosystèmes** Dans une implémentation BS d'un cryptosystème, les blocs en clair sont d'abord convertis en représentation BS en réalisant une transposition. Sur une architecture avec des registres de $k$ bits, $k$ blocs en clair de $l$ bits sont transposés dans $l$ mots machines de $k$ bits, où le mot machine $j$ contient le $j$-ième bit de chaque bloc en clair. Par exemple, une implémentation BS de AES sur un processeur 32 bits transpose 32 blocs
en clair de 128 bits dans 128 mots machines de 32 bits. Cette représentation BS est illustrée sur la figure 4.2. Transposer les blocs en clair en représentation BS peut être une opération assez coûteuse. Une méthode simple est de transposer les blocs bit par bit comme illustrée dans le code de la figure 4.3. Cet algorithme de transposition peut être amélioré en transposant les blocs en clair de façon récursive [Knu98] (voir annexe A). Le cryptosystème est ensuite exprimé sous la forme d'un circuit F composé de portes booléennes élémentaires (par exemple AND, XOR, OR, NOT). Le circuit F chiffre alors en parallèle les *k* blocs en clair, et retourne les *k* blocs chiffrés en représentation BS. On obtient finalement les *k* blocs chiffrés en réalisant la transposition inverse de la conversion en représentation BS. Le BS produit ainsi des implémentations de chiffrement à haut débit en chiffrant plusieurs blocs en parallèle. Dans la suite, nous désignons par SW-BS une implémentation BS de AES.

```c
void transposition(uint32_t data[32], uint32_t transposed_data[32])
    for (int i = 0; i < 32; i++) {
        transposed_data[i] = 0;
    }

    for (int i = 0; i < 32; i++) {
        for (int j = 0; j < 32; j++) {
            transposed_data[j] |= ((data[i] >> j) & 1) << i;
        }
    }
}
```

<caption>FIGURE 4.3 – Code C de la transposition simple de 32 blocs de 32 bits en représentation BS.</caption>

### Avantages et inconvénients
Le BS permet de produire des implémentations de chiffrement à haut débit grâce au parallélisme des données dans un même mot machine. De plus, les implémentations BS de cryptosystèmes s'exécutent en temps constant. En effet, les conditions en BS sont réalisés en exécutant chaque branchement possible, puis en conservant le résultat correct. Cette méthode peut devenir coûteuse pour les grandes conditions, car elle nécessite le calcul de toutes les branches possibles. Ce n'est cependant pas un problème car les cryptosystèmes symétriques ont peu de conditions à protéger. Les implémentations BS empêchent également les attaques ciblant les caches [Ber05] car les tables pré-calculées sont remplacées par des circuits s'exécutant en temps constant. Cependant, le BS possède quelques limitations. Tout d'abord, de nombreux blocs en clair doivent être chiffrés en parallèle pour obtenir les meilleures performances. Par exemple, dans une architecture 32 bits, 32 blocs en clair doivent être chiffrés en parallèle pour être efficaces. Ces différents blocs en clair peuvent être chiffrés en utilisant le mode de chiffrement CTR qui permet le chiffrement parallèle de blocs consécutifs. Cependant, BS empêche l'utilisation des modes de chiffrement CBC et OFB, ainsi que tout autre mode dans lequel le chiffrement d'un bloc en clair utilise le chiffré précédent. Pour utiliser le BS avec ces modes de chiffrement, une solution est de chiffrer des blocs indépendants en parallèle. Cette méthode induit néanmoins un coût lié à la gestion des différents blocs. Une autre limitation est que le BS utilise beaucoup de variables, ce qui engendre une pression sur les registres généraux du processeur. De nombreux déplacements de données entre les registres et la mémoire sont nécessaires, réduisant les performances. Par exemple, 32 blocs en clair d'AES sont représentés en BS sous la forme de 128 registres de 32 bits, ce qui est nettement supérieur au nombre de registres généraux dans la plupart des processeurs.
**Usuba** Usuba [MD19] est un langage pour décrire des implémentations BS. Un compilateur permet de synthétiser un code Usuba en une implémentation logicielle BS en langage C. De nombreuses optimisations sont réalisées par le compilateur. Le compilateur utilise par exemple un algorithme d'ordonnancement des instructions visant à minimiser la pression sur les registres du processeur. Il a été utilisé avec succès pour déployer des primitives cryptographiques sur des architectures Intel, PowerPC, Arm et Sparc.

```sql
table SBOX (a:v8) returns (b:v8) {
    99,124,119,123,242,107,111,197,48,1,103,43,254,215,171,118,
    ...
    140,161,137,13,191,230,66,104,65,153,45,15,176,84,187,22}

node SubBytes (a:b8[16]) returns (b:b8[16]) let
   forall i in [0,15] {
        b[i] = SBOX(a[i])
    } tel

node ShiftRows (a:b8[16]) returns (b:b1[128]) let
    b = a[
        0, 5, 10, 15,
        4, 9, 14, 3,
        8, 13, 2, 7,
        12, 1, 6, 11]
    tel

node times2 (a:b1[8]) returns (b:b1[8]) let
    b=(a<<1)^(0,0,0,a[0],a[0],0,a[0],a[0]); tel

node times3 (a:b1[8]) returns (b:b1[8]) let
    b=times2(a)^a; tel

node MixColumn_single (a:b8[4]) returns (b:b8[4]) let
    b[0]=times2(a[0])^times3(a[1])^a[2]^a[3];
    b[1]=a[0]^times2(a[1])^times3(a[2])^a[3];
    b[2]=a[0]^a[1]^times2(a[2])^times3(a[3]);
    b[3]=times3(a[0])^a[1]^a[2]^times2(a[3]); tel

node MixColumn (a:b32[4]) returns (b:b32[4]) let
   forall i in [0,3] {
        b[i] = MixColumn_single(a[i])
    } tel

node AddRoundKey(a:b128,key:b128) returns (b:b128) let
    b = a ^ key

node AES128 (plain:b128,key:b128[11]) returns (cipher:b1[128])
vars tmp : b128[10] let
    tmp[0]=AddRoundKey(plain, key[0]);
   forall i in [1,9] {
        tmp[i]=AddRoundKey(MixColumn(ShiftRows(SubBytes(tmp[i-1]))),key[i]);
    }
    cipher=AddRoundKey(ShiftRows(SubBytes(tmp[9]),key[10]), tel
```

<caption>FIGURE 4.4 – Code Usuba d’une implémentation BS de AES, extrait du code source de Usuba¹.</caption>

Le code Usuba d'une implémentation BS de AES est montré à la figure 4.4. Des types spécifiques permettent de manipuler des données en représentation BS. Par exemple, le type `b128` représente un bloc de 128 bits en représentation BS. Pour structurer les programmes,
Usuba utilise des nodes, équivalent aux fonctions dans d'autres langages. Un node spécifie un ensemble de valeurs d'entrée, de valeurs de sortie ainsi qu'un système d'équations reliant ces variables. Pour implémenter SubBytes, la table SBOX est appliquée à chaque octet. La table SBOX est définie par une table de vérité. Un circuit optimisé de la SBOX est intégré au compilauteur, permettant de réaliser la SBOX en 113 opérations booléennes. ShiftRows est calculée en mélangeant les registres, puisque chaque registre contient un bit de chaque élément de l'état. Une implémentation spécifique de MixColumns est réalisée pour calculer sur des variables en représentation BS.

### 4.1.4 Implémentation *m*-slicing

Le *m*-slicing est une technique d'implémentation, introduite dans [KS09], qui généralise le BS. Comme le BS, le *m*-slicing permet de chiffrer plusieurs blocs en parallèle. Dans une implémentation *m*-slicing, un bloc en clair est divisé en morceaux de *m* bits et chaque morceau est placé dans un mot machine différent. Le cas *m* = 1 correspond au BS. Si chaque mot machine contient *k* bits, *k*/*m* blocs en clair indépendants peuvent être chiffrés en parallèle au lieu de *k* pour une implémentation BS. Cette représentation nécessite donc moins de blocs en clair pour remplir les registres et ainsi maximiser le débit. Par exemple, sur une architecture 32 bits, seulement 2 blocs en clair indépendants sont nécessaires pour le 16-slicing contre 32 blocs en clair pour le BS. Il en résulte une pression sur les registres généraux réduite. Dans la suite, une implémentation *m*-slicing de AES est nommée SW-*m*S, avec *m* un entier positif.

<table><caption>FIGURE 4.5 – Représentation 16-slicing de 8 blocs dans 8 mots machines ($M_i, 0 \le i \le 127$) d'une architecture 128 bits. $b_i^j$ désigne le *i*-ième bit du *j*-ième bloc.</caption><thead><tr><th rowspan="3"></th><th colspan="8">ligne 3</th><th colspan="8">ligne 0</th></tr><tr><th colspan="4">colonne 0</th><th colspan="4">colonne 3</th><th colspan="4">colonne 0</th><th colspan="4">colonne 3</th></tr><tr><th>bloc 0</th><th>...</th><th>bloc 7</th><th>...</th><th>bloc 0</th><th>...</th><th>bloc 7</th><th>...</th><th>bloc 0</th><th>...</th><th>bloc 7</th><th>...</th><th>bloc 0</th><th>...</th><th>bloc 7</th><th>...</th></tr></thead><tbody><tr><td>M<sub>0</sub></td><td>b<sup>0</sup><sub>24</sub></td><td>...</td><td>b<sup>7</sup><sub>24</sub></td><td>...</td><td>b<sup>0</sup><sub>120</sub></td><td>...</td><td>b<sup>7</sup><sub>120</sub></td><td>...</td><td>b<sup>0</sup><sub>0</sub></td><td>...</td><td>b<sup>7</sup><sub>0</sub></td><td>...</td><td>b<sup>0</sup><sub>96</sub></td><td>...</td><td>b<sup>7</sup><sub>96</sub></td><td>...</td></tr><tr><td>M<sub>1</sub></td><td>b<sup>0</sup><sub>25</sub></td><td>...</td><td>b<sup>7</sup><sub>25</sub></td><td>...</td><td>b<sup>0</sup><sub>121</sub></td><td>...</td><td>b<sup>7</sup><sub>121</sub></td><td>...</td><td>b<sup>0</sup><sub>1</sub></td><td>...</td><td>b<sup>7</sup><sub>2</sub></td><td>...</td><td>b<sup>0</sup><sub>97</sub></td><td>...</td><td>b<sup>7</sup><sub>97</sub></td><td>...</td></tr><tr><td>M<sub>2</sub></td><td>b<sup>0</sup><sub>26</sub></td><td>...</td><td>b<sup>7</sup><sub>26</sub></td><td>...</td><td>b<sup>0</sup><sub>122</sub></td><td>...</td><td>b<sup>7</sup><sub>122</sub></td><td>...</td><td>b<sup>0</sup><sub>2</sub></td><td>...</td><td>b<sup>7</sup><sub>2</sub></td><td>...</td><td>b<sup>0</sup><sub>98</sub></td><td>...</td><td>b<sup>7</sup><sub>98</sub></td><td>...</td></tr><tr><td>M<sub>3</sub></td><td>b<sup>0</sup><sub>27</sub></td><td>...</td><td>b<sup>7</sup><sub>27</sub></td><td>...</td><td>b<sup>0</sup><sub>123</sub></td><td>...</td><td>b<sup>7</sup><sub>123</sub></td><td>...</td><td>b<sup>0</sup><sub>3</sub></td><td>...</td><td>b<sup>7</sup><sub>3</sub></td><td>...</td><td>b<sup>0</sup><sub>99</sub></td><td>...</td><td>b<sup>7</sup><sub>99</sub></td><td>...</td></tr><tr><td>M<sub>4</sub></td><td>b<sup>0</sup><sub>28</sub></td><td>...</td><td>b<sup>7</sup><sub>28</sub></td><td>...</td><td>b<sup>0</sup><sub>124</sub></td><td>...</td><td>b<sup>7</sup><sub>124</sub></td><td>...</td><td>b<sup>0</sup><sub>4</sub></td><td>...</td><td>b<sup>7</sup><sub>4</sub></td><td>...</td><td>b<sup>0</sup><sub>100</sub></td><td>...</td><td>b<sup>7</sup><sub>100</sub></td><td>...</td></tr><tr><td>M<sub>5</sub></td><td>b<sup>0</sup><sub>29</sub></td><td>...</td><td>b<sup>7</sup><sub>29</sub></td><td>...</td><td>b<sup>0</sup><sub>125</sub></td><td>...</td><td>b<sup>7</sup><sub>125</sub></td><td>...</td><td>b<sup>0</sup><sub>5</sub></td><td>...</td><td>b<sup>7</sup><sub>5</sub></td><td>...</td><td>b<sup>0</sup><sub>101</sub></td><td>...</td><td>b<sup>7</sup><sub>101</sub></td><td>...</td></tr><tr><td>M<sub>6</sub></td><td>b<sup>0</sup><sub>30</sub></td><td>...</td><td>b<sup>7</sup><sub>30</sub></td><td>...</td><td>b<sup>0</sup><sub>126</sub></td><td>...</td><td>b<sup>7</sup><sub>126</sub></td><td>...</td><td>b<sup>0</sup><sub>6</sub></td><td>...</td><td>b<sup>7</sup><sub>6</sub></td><td>...</td><td>b<sup>0</sup><sub>102</sub></td><td>...</td><td>b<sup>7</sup><sub>102</sub></td><td>...</td></tr><tr><td>M<sub>7</sub></td><td>b<sup>0</sup><sub>31</sub></td><td>...</td><td>b<sup>7</sup><sub>31</sub></td><td>...</td><td>b<sup>0</sup><sub>127</sub></td><td>...</td><td>b<sup>7</sup><sub>127</sub></td><td>...</td><td>b<sup>0</sup><sub>7</sub></td><td>...</td><td>b<sup>7</sup><sub>7</sub></td><td>...</td><td>b<sup>0</sup><sub>103</sub></td><td>...</td><td>b<sup>7</sup><sub>103</sub></td><td>...</td></tr></tbody></table>

**Implémentation *m*-slicing** [KS09] ont réalisé une implémentation 16-slicing de AES sur une architecture 128 bits en représentant 8 blocs de 128 bits dans 8 mots mémoires contenant

<footnote n="1">1. https://github.com/usubalang/usuba</footnote>
chacun 16 bits de chaque bloc, comme illustré dans la figure 4.5. [SS16] ont proposé une implémentation 16-slicing de AES sur un processeur ARM Cortex-M3, qui a ensuite été porté sur une architecture RISC-V 32 bits dans [Sto19]. Les performances ont encore été améliorées dans [AP20] en utilisant une méthode appelée «fix slicing». [AP20] proposent également une implémentation 4-slicing de AES appelée «barrel-shiftrows», permettant de chiffrer 8 blocs en parallèle sur une architecture 32 bits.

### 4.1.5 Comparaison des différentes solutions

Le tableau 4.1 présente les performances de différentes implémentations logicielles du chiffrement AES sur des processeurs 32 bits. On constate que l'implémentation SW-TTABLE utilisant des tables est la plus performante, mais est vulnérable aux attaques ciblant les caches. L'implémentation SW-RW est beaucoup moins efficace que SW-TTABLE. Les implémentations m-slicing permettent d'obtenir des performances proches de l'implémentation SW-TTABLE. L'implémentation SW-16S de [SS16] permet de chiffrer 2 blocs en parallèle en atteignant 1990 cycles par bloc sur un processeur ARM Cortex-M3. [Sto19] ont ensuite portée cette implémentation sur une architecture RISC-V 32 bits, permettant d'atteindre 1990 cycles par bloc. L'implémentation SW-16S de [AP20] utilisant la méthode «fix slicing» améliore encore les performances en atteignant 1468 cycles par bloc. Une comparaison plus précise est réalisée au chapitre 6 en réimplémentant ces différentes implémentations sur un même cœur.

<table><caption>TABLE 4.1 – Performance de différentes implémentations logicielles du chiffrement AES. Le temps d'exécution est donné en nombre de cycles par bloc.</caption><thead><tr><th rowspan="2">Implém.</th><th rowspan="2">Source</th><th rowspan="2">Cœur</th><th colspan="2">Temps</th></tr><tr><th>Cycles</th><th>Cmp</th></tr></thead><tbody><tr><td>SW-TTABLE</td><td>[Gao+21]</td><td>SCARV</td><td>1016</td><td>base</td></tr><tr><td>SW-RW</td><td>[Gao+21]</td><td>SCARV</td><td>2427</td><td>×2,4</td></tr><tr><td>SW-16S</td><td>[SS16]</td><td>Cortex-M3</td><td>1617</td><td>×1,6</td></tr><tr><td>SW-16S</td><td>[Sto19]</td><td>E31</td><td>1990</td><td>×2,0</td></tr><tr><td>SW-16S</td><td>[AP20]</td><td>E31</td><td>1468</td><td>×1,4</td></tr><tr><td>SW-4S</td><td>[AP20]</td><td>E31</td><td>1263</td><td>×1,2</td></tr></tbody></table>

## 4.2 Implémentations masquées de AES

### 4.2.1 Schéma de masquage RP

[RP10] ont proposé une implémentation masquée de AES que nous nommons SW-M-RP. Pour masquer l'inversion dans GF(2<sup>8</sup>), ils utilisent la décomposition de la figure 4.1. Chaque multiplication dans GF(2<sup>8</sup>) est remplacée par la multiplication masquée ISW. Les expositions à des puissances de deux étant linéaires dans GF(2<sup>8</sup>), elles sont masquées de façon directe. Cependant, on risque de recombiner les parts en composant ainsi les implémentations masquées, car l'indépendance des masquages d'entrée des multiplications n'est plus satisfaite. En effet, lorsqu'on masque la multiplication d'une variable *x* et d'une variable *y* = L(*x*), où L est une application linéaire, les entrées de la multiplication masquée ISW sont dépendantes
car pour tout $0 \le i \le d$, $\hat{y}[i] = L(\hat{x}[i])$. Pour contourner ce problème, [RP10] ont suggéré d'ajouter des valeurs aléatoires en rafraîchissant le masquage à certains endroits bien choisis, comme illustré à la figure 4.6. [RP10] ont d'abord proposé d'utiliser le code de rafraîchissement de l'algorithme 4, qui s'est avéré non sécurisé dans [Cor+14]. Le code de rafraîchissement de l'algorithme 5 fut finalement utilisé pour maintenir la sécurité de la composition.

<figure><img src="image_43.png" /><figcaption>FIGURE 4.6 – Exponentiation modulaire masquée à l'ordre 1 et sécurisée dans le modèle de sondage. rafr désigne un code de rafraîchissement.</figcaption></figure>

## 4.2.2 Schéma de masquage CPRR

[Cor+14] ont proposé une implémentation masquée de AES que nous nommons SW-M-CPRR. Le schéma de masquage SW-M-CPRR a été initialement proposé pour calculer en toute sécurité des multiplications de la forme $h : x \mapsto x \otimes L(x)$ où L est linéaire, sans avoir besoin de rafraîchir le masquage de x. L'algorithme 8 présente l'évaluation masquée de h proposée dans [Cor+14]. Cette évaluation masquée peut être plus efficace que la solution proposée par [RP10] en remplaçant les multiplications de corps coûteuses par de simples recherches de table. En effet, tabuler la multiplication de corps n'est généralement pas réalisable sur des systèmes contraints (la table contient $2^{2n}$ éléments) alors que tabuler la table de h est facilement réalisable (la table contient $2^n$ éléments). Le seul inconvénient de cette évaluation masquée est qu'elle double le nombre d'aléas par rapport à la multiplication masquée ISW.

**Algorithmme 8** Évaluation sécurisée de $h : x \mapsto x \otimes L(x)$ [Cor+14]

**Entrée:** Masquage $\hat{x} \in K^{d+1}$ de $x$

**Sortie:** Masquage $\hat{z} \in K^{d+1}$ de $z$ tel que $\bigoplus_i \hat{z}[i] = h(x)$

pour $i = 0$ à $d$ faire

pour $j = i + 1$ à $d$ faire

$$r_{i,j} \leftarrow \mathbb{K}$$

$$r'_{i,j} \leftarrow \mathbb{K}$$

$$r_{j,i} \leftarrow r_{i,j} \oplus h(\hat{x}[i] \oplus r'_{i,j}) \oplus h(\hat{x}[j] \oplus r'_{i,j}) \oplus h((\hat{x}[i] \oplus r'_{i,j}) \oplus \hat{x}[j]) \oplus h(r'_{i,j})$$

fin pour

fin pour

pour $i = 0$ à $d$ faire

$$\hat{z}[i] \leftarrow h(\hat{x}[i]) \oplus \bigoplus_{j=0, j \neq i}^{d} r_{i,j}$$

fin pour
### 4.2.3 Tables masquées

[Cha+99; Cor14; CRZ18] ont proposé des implémentations masquées de AES, que nous nommons SW-M-HTABLE, consistant à pré-calculer une table masquée.

**Table masquée à l'ordre 1** Pour évaluer une SBOX dans le domaine masqué, [Cha+99; Mes00a] ont proposé de masquer directement la table. Plus précisément, pour appliquer une table S à une variable x, on précalcule d'abord une table masquée T :

$$T(x) = S(x \oplus m_{in}) \oplus m_{out}$$

pour tout x, avec $m_{in}$ le masque d'entrée et $m_{out}$ le masque de sortie. En appliquant T à une variable masquée avec le masque $m_{in}$, on obtient le résultat de la table S masquée avec le masque $m_{out}$. Le table T doit être recalculée pour toute nouvelle valeur des masques d'entrée et de sortie. Le calcul de la table T entraîne une perte de performance. De plus, la table T doit être stockée en RAM, rendant cette méthode vulnérable aux attaques ciblant les caches [Tsu+03; Ber05; BM06].

**Table masquée à un ordre supérieur** Le masquage des tables proposées dans [Cha+99; Mes00a] au premier ordre a été étendu aux ordres supérieurs dans [Cor14]. Leur solution consiste à décaler progressivement la table T en rafraîchissant le masquage entre chaque décalage. [CRZ18] ont amélioré [Cor14] en augmentant progressivement le nombre de parts de sortie dans la table T et en adaptant la méthode dite des parts communes introduite dans [Cor+16]. La méthode des tables masquées engendre cependant un surcoût important en termes de temps d'exécution, de mémoire et de complexité en aléas.

### 4.2.4 Implémentation «bit slicing» masquée

Pour masquer une application BS ou *m-slicing*, une solution est de répartir les parts dans différents registres du processeur et remplacer les instructions par des implémentations masquées en utilisant les méthodes de masquage présentées au chapitre 3. Dans la suite, nous nommons cette solution SW-M-BS. Une telle approche a été appliquée dans [Gro+15] pour concevoir des chiffrements par blocs en utilisant le schéma ISW. Une implémentation BS masquée de AES a également été proposée dans [Bal+15] et utilisée comme étude de cas pour des attaques SCA sur un processeur ARM Cortex-A8 fonctionnant à 1 GHz. Plus récemment, [GR17] ont décrit des implémentations BS masquées de chiffrements par blocs classiques tels que AES ou PRESENT. Les parts d'un bit étant réparties sur de nombreux mots mémoires, la pression sur les registres généraux du processeur augmente avec l'ordre de masquage [JS17].

**Tornado** Tornado [Bel+20] synthétise une implémentation BS masquée à partir d'une description Usuba d'une primitive cryptographique en utilisant le schéma ISW. Une macro permet d'instancier à la compilation l'ordre de masquage souhaité. Tornado utilise Usuba pour générer automatiquement un code BS qui est ensuite analysé par une extension de tightPROVE [BGR18] pour rafraîchir le masquage lorsque c'est nécessaire.
4.2.5 Implémentation «share slicing»

Une autre technique pour masquer une implémentation BS ou *m-slicing*, appelée «share slicing», consiste à placer toutes les parts d'un bit masqué dans un même mot mémoire. Par exemple, la figure 4.7 illustre la représentation «share slicing» d'ordre 1 sur une architecture 32 bits. Chaque mot mémoire contient un bit de 16 blocs indépendants, ainsi que le masque de chaque bit. Dans la suite, une implémentation «share slicing» de AES est nommé SW-M-SS.

<figure><img src="image_44.png" /><figcaption>FIGURE 4.7 – Représentation «share slicing» d'ordre 1 sur une architecture 32 bits. $\hat{\mathbf{b}}_i^j$ désigne un masquage du $i$-ième bit du $j$-ième bloc.</figcaption></figure>

**Implémentations «share slicing» de AES** [Bar+17] ont proposé une multiplication masquée réalisable efficacement en représentation «share slicing». L'algorithme 9 décrit cette multiplication masquée à l'ordre 1. [Bar+17] ont montré que cette multiplication masquée pouvait être rendue SNI en rafraîchissant le masquage de sortie. Cette multiplication masquée fut en-suite améliorée dans [Gré+18; Gou+18; Bar+19a]. [Gré+18] ont proposé une implémentation «share slicing» de AES masquée aux ordres 3 et 7. Une implémentation «share slicing» masquée à l'ordre 31 a également été proposée dans [JS17].

**Algorithm 9** Multiplication masquée à l'ordre 1 de [Bar+17].

**Entrée:** Masquage $\hat{\mathbf{x}} \in \text{GF}(2)^2$ de $x$ et masquage $\hat{\mathbf{y}} \in \text{GF}(2)^2$ de $y$

**Sortie:** Masquage $\hat{\mathbf{z}} \in \text{GF}(2)^2$ de $z$ tel que $\hat{\mathbf{z}}[0] \oplus \hat{\mathbf{z}}[1] = x \otimes y$

$$a_1 \leftarrow \hat{\mathbf{x}} \otimes \hat{\mathbf{y}}$$

$$r \leftarrow \mathbb{K}_2^2$$

$$b_1 \leftarrow \mathbb{K}_2^2$$

$$a_2 \leftarrow \hat{\mathbf{x}} \otimes \text{ROT}(\hat{\mathbf{y}}, 1)$$

$$b_2 \leftarrow b_1 \oplus a_2$$

$$\hat{\mathbf{z}} \leftarrow b_2 \oplus \text{ROT}(r, 1)$$

**Avantages et inconvénients** Les implémentations de [Gré+18; JS17] ont montré que la multiplication masquée de [Bar+17] est relativement efficace, tant en termes d'aléas que de cycles d'exécution. De plus, le «share slicing» nécessite moins de mots mémoire que le BS masqué, réduisant ainsi le coût lié à la gestion des différents blocs. En effet, le nombre de
blocs chiffrés en parallèle est divisé par $d + 1$. Une propriété intéressante du « share slicing » est qu'il évite les fuites liées aux transitions [Gao+19], puisque la position de chaque part dans un mot mémoire est toujours la même. Le « share slicing » évite ainsi les recombinaisons des parts lors des opérations load/store. Par contre, le placement de toutes les parts dans un même mot mémoire peut conduire à des recombinaisons liées à la micro-architecture des processeurs [Gao+19].

### 4.2.6 Comparaison des différentes solutions

Le tableau 4.2 présente les performances de différentes implémentations logicielles masquées du chiffrement AES. On constate que le masquage induit un coût important en terme de temps d'exécution. Le coût du masquage augmente de façon exponentielle avec l'ordre de masquage. Par exemple, les implémentations SW-M-RP masquées aux ordres 1, 2 et 3 engendrent respectivement un surcoût de 43, 90 et 157. L'implémentation masquée SW-M-HTABLE est beaucoup moins efficace que SW-M-RP. Par exemple, l'implémentation SW-M-HTABLE masquée à l'ordre 2 augmente le temps d'exécution d'un facteur 289 par rapport à l'implémentation non masquée SW-BW. Le « share slicing » semble être une solution efficace pour réduire le temps d'exécution et masquer à des ordres élevés. Une comparaison plus précise est réalisée au chapitre 6 en réimplémentant ces différentes implémentations sur un même cœur.

<table><caption>TABLE 4.2 – Performances de différentes implémentations logicielles masquées du chiffrement AES. Le temps d'exécution est donné en nombre de cycles par bloc.</caption><thead><tr><th rowspan="2">Implém.</th><th rowspan="2">Source</th><th rowspan="2">d</th><th rowspan="2">Cœur</th><th colspan="2">Temps</th></tr><tr><th>Cycles</th><th>cmp</th></tr></thead><tbody><tr><td>SW-BW</td><td rowspan="4">[RP10]</td><td>0</td><td>8051</td><td>3000</td><td>base</td></tr><tr><td>SW-M-RP</td><td>1</td><td>8051</td><td>129000</td><td>×43</td></tr><tr><td>SW-M-RP</td><td>2</td><td>8051</td><td>271000</td><td>×90</td></tr><tr><td>SW-M-RP</td><td>3</td><td>8051</td><td>470000</td><td>×157</td></tr><tr><td>SW-BW</td><td rowspan="3">[CRZ18]</td><td>0</td><td>Intel</td><td>1600</td><td>base</td></tr><tr><td>SW-M-HTABLE</td><td>2</td><td>Intel</td><td>463000</td><td>×289</td></tr><tr><td>SW-M-HTABLE</td><td>3</td><td>Intel</td><td>771000</td><td>×482</td></tr><tr><td>SW-TTABLE</td><td>[SS16]</td><td>0</td><td>Cortex-M4</td><td>662</td><td>base</td></tr><tr><td>SW-M-SS</td><td>[JS17]</td><td>31</td><td>Cortex-M4</td><td>2783510</td><td>×4207</td></tr><tr><td>SW-M-16S</td><td>[BS12]</td><td>0</td><td>NEON</td><td>306</td><td>base</td></tr><tr><td>SW-M-SS</td><td rowspan="2">[Gré+18]</td><td>3</td><td>NEON</td><td>8793</td><td>×29</td></tr><tr><td>SW-M-SS</td><td>7</td><td>NEON</td><td>26601</td><td>×87</td></tr></tbody></table>
# Chapitre 5

## Extensions de jeu d'instructions

Différentes approches existent pour implémenter un cryptosystème. Une *extension de jeu d'instructions*, abrégée en ISE pour «*instruction set extension*» en anglais, ajoute de nouvelles instructions au jeu d'instructions de base pour faire certains calculs de façon plus efficace, augmenter la sécurité, ou réduire l'empreinte mémoire. Pour implémenter le masquage de façon efficace et sécurisée, des ISE dédiées au masquage ont récemment été proposées.

Dans ce chapitre, la section 5.1 introduit le concept d'architecture de jeu d'instructions. La section 5.2 décrit le jeu d'instructions RISC-V. La section 5.3 introduit le concept d'extension de jeu d'instructions. La section 5.4 établit un état de l'art des ISE dédiées au masquage.

### 5.1 Architecture de jeu d'instructions

Une *architecture de jeu d'instructions*, abrégée en ISA pour «*instruction set architecture*» en anglais, fait partie du modèle abstrait d'un processeur. L'ISA agit comme une interface entre le matériel et le logiciel, spécifiant ce que le processeur est capable de faire (voir figure 5.1). En général, une ISA définit les instructions prises en charge, les types de données, les registres, les modes d'adressage, la mémoire virtuelle et le modèle d'entrée/sortie.

**Implémentation d'une ISA** Une ISA peut être implémentée par des processeurs avec des micro-architectures très différentes. Toutes les implémentation d'une ISA sont capables d'exécuter n'importe quel exécutable respectant les contraires de l'ISA. Ainsi, un processeur moins performant et moins coûteux peut être remplacé par un processeur plus coûteux et plus performant implémentant la même ISA sans avoir à modifier le logiciel.

**Classification des ISA** La conception d'ISA est un problème complexe. Les ISA peuvent être classées en deux catégories en fonction de leur complexité architecturale. Les *jeux d'instructions complexes*, abrégés en CISC pour «*complex instruction set computer*» en anglais, comportent de nombreuses instructions spécialisées. Ce type de jeu d'instructions permet d'optimiser l'exécution de certaines opérations, d'améliorer l'utilisation de la mémoire et du cache et de simplifier la programmation. Cependant, le nombre important d'instructions spécialisées augmente la taille du processeur et impacte sa fréquence. De plus, de nombreuses instructions sont rarement utilisées en pratique conduisant à un faible taux d'utilisation des unités de calcul. Les *jeux d'instructions réduits*, abrégés en RISC pour «*reduced instruction set computer*» en anglais, réduisent le nombre d'instructions au minimum en implémentant uniquement les
<figure><img src="image_45.png" /><figcaption>FIGURE 5.1 – Architecture de jeu d'instructions.</figcaption></figure>

instructions les plus fréquemment utilisées dans les programmes. La surface et la consommation énergétique des processeurs RISC est généralement réduite par rapport aux processeurs CISC car le décodage des instructions est plus simple. En contrepartie, le nombre d'instructions exécutées est plus élevé et le code moins compact qu'avec des jeux d'instructions CISC. L'augmentation du nombre d'instructions exécutées peut être compensée par l'utilisation de la technique du *pipeline* qui permet d'augmenter la fréquence d'horloge.

## 5.2 Jeu d'instructions RISC-V

RISC-V est une ISA open source de type RISC qui peut être implémentée, modifiée ou étendue par toute personne sans exigence de licence ni de redevance (à la différence de MIPS, ARM et x86). RISC-V fut développé initialement en 2010 à l'université Berkeley en Californie pour soutenir la recherche et l'éducation en architecture des ordinateurs. Depuis 2010, l'ISA RISC-V a gagné en popularité dans le milieu académique et industriel. En 2015, la fondation RISC-V est créée pour maintenir la conception de RISC-V. La fondation RISC-V se compose d'universitaires et de grandes entreprises telles que Google, Intel, Nvidia, AMD, Qualcomm, et IBM. Cette importante communauté a permis le développement rapide d'une large gamme d'implémentations de processeurs RISC-V. RISC-V est également pris en charge par des systèmes d'exploitation et de nombreuses chaînes d'outils logiciels. Le jeu d'instructions RISC-V a une conception modulaire qui offre une grande flexibilité. Il se compose d'une ISA de base qui est réduite à un ensemble minimal d'instructions. L'ISA de base peut être complétée par un ensemble d'extensions, standards ou non-standards. Cette approche permet d'ajouter uniquement les extensions nécessaires pour répondre aux contraintes du concepteur. Nous allons à présent décrire plus précisément l'ISA de base RV32I. Une description plus complète du jeu d'instructions RISC-V est disponible dans [WA19].
## 5.2.1 ISA de base RV32I

L'ISA de base RV32I possède 32 registres qui ont tous une largeur de 32 bits. En tant qu'ISA de type RISC, RISC-V a une architecture *load-store*, c'est-à-dire que les opérandes et la destination d'une opération doivent être des registres. L'ISA de base RV32I implémente 47 instructions permettant d'obtenir les fonctionnalités de base avec des entiers 32 bits. Cette ISA comprend des instructions pour l'addition et la soustraction entières, les opérations binaires, les *load-store*, les sauts et les branchements. Les formats des instructions de RV32I sont de 6 types différents (voir table 5.1). Les instructions de type R lisent deux registres sources d'indices rs1 et rs2 dans le fichier de registres, et écrivent le résultat dans le registre destination d'indice rd dans le fichier de registres. Les autres types d'instructions utilisent des valeurs immédiates codées dans l'instruction (imm). Les types I et S sont utilisés respectivement pour les load et les store. Les branchements conditionnels ont un format de type B alors que les sauts inconditionnels ont un format de type J. Le type U permet un immédiat de plus grande taille. La position des champs de bits dans les différents types d'instructions a été choisie pour simplifier le décodage. Par exemple, les indices dans le fichier de registres des registres sources et destination sont maintenus à la même position dans tous les formats.

<table><caption>TABLE 5.1 – Formats d'instruction de RV32I, reproduit de [WA19].</caption><thead><tr><th>Type</th><th>31</th><th>30</th><th>25</th><th>24</th><th>21</th><th>20</th><th>19</th><th>15</th><th>14</th><th>12</th><th>11</th><th>8</th><th>7</th><th>6</th><th>0</th></tr></thead><tbody><tr><td>R</td><td colspan="2">funct7</td><td colspan="2">rs2</td><td colspan="2">rs1</td><td colspan="2">funct3</td><td colspan="2">rd</td><td colspan="2"></td><td colspan="2">opcode</td></tr><tr><td>I</td><td colspan="2"></td><td colspan="2">imm[11:0]</td><td colspan="2"></td><td colspan="2">rs1</td><td colspan="2">funct3</td><td colspan="2"></td><td colspan="2">opcode</td></tr><tr><td>U</td><td colspan="2"></td><td colspan="2"></td><td colspan="2">imm[31:12]</td><td colspan="2"></td><td colspan="2"></td><td colspan="2">rd</td><td colspan="2">opcode</td></tr><tr><td>S</td><td colspan="2">imm[11:5]</td><td colspan="2"></td><td colspan="2">rs2</td><td colspan="2">rs1</td><td colspan="2">funct3</td><td colspan="2">imm[4:0]</td><td colspan="2">opcode</td></tr><tr><td>B</td><td>imm[12]</td><td>imm[10:5]</td><td colspan="2"></td><td colspan="2">rs2</td><td colspan="2">rs1</td><td colspan="2">funct3</td><td>imm[4:1]</td><td>imm[11]</td><td colspan="2">opcode</td></tr><tr><td>J</td><td>imm[20]</td><td></td><td>imm[10:1]</td><td>imm[11]</td><td colspan="2"></td><td colspan="2">imm[19:12]</td><td colspan="2"></td><td colspan="2">rd</td><td colspan="2">opcode</td></tr></tbody></table>

## 5.2.2 Extensions standards

L'ISA de base RISC-V peut être étendue avec des extensions de sorte que les processeurs personnalisés soient adaptés aux besoins de l'application. La spécification RISC-V définit un certain nombre d'extensions standards. Parmi ces extensions standards, on peut citer l'extension M (multiplication), A (instructions atomiques), F (virgule flottante simple précision), C (instructions compressées), ou encore l'extension K (cryptographie scalaire). D'autres extensions ne sont pas encore validées par la fondation RISC-V et sont appelées non-standards. Le nom donné à l'ISA obtenue en ajoutant les extensions est le nom de l'ISA de base concaténé avec les lettres de chaque extension ajoutée, comme par exemple RV32IMAFD.

## 5.2.3 Implementations RISC-V

De nombreuses implémentations de cœurs RISC-V ont été proposées avec diverses caractéristiques et objectifs. On peut notamment citer VexRiscv, Rocket, PicoRV32 ou encore les cœurs développés par l'OpenHW Group<fnref n="1" />.

<footnote n="1">1. Une liste complète des cœurs RISC-V est disponible à https://riscv.org/risc-v-cores-and-soc-overview/</footnote>
**OpenHW Group** OpenHW Group<fnref n="2" /> est une organisation mondiale à but non-lucratif dont font partie des acteurs majeurs de l'industrie. L'openHW Group a développé CORE-V, une série de cœurs open source basée sur RISC-V. La famille CORE-V<fnref n="3" /> fournit des cœurs ayant des implémentations optimisées en silicium et FPGA et une conception conforme aux pratiques de l'industrie. La famille CORE-V se compose du CVA6⁴, un cœur adapté aux applications hautes performances, du CV32E40P<fnref n="5" /> pour les plates-formes embarquées, et du CVE2⁶ pour les systèmes embarqués à fortes contraintes énergétiques. Un projet de vérification fonctionnelle a été développé pour vérifier le fonctionnement de la famille de cœurs CORE-V<fnref n="7" />.

**CV32E40P** Nous avons choisi d'implémenter nos extensions sur le cœur CV32E40P. Le cœur CV32E40P est un processeur RISC-V 32 bits à 4 étages. Il implémente le jeu d'instructions RV32IMFC, ou l'extension F est optionnelle. L'ISA du CV32E40P a été étendue pour prendre en charge plusieurs instructions supplémentaires, notamment les boucles matérielles, les instructions de load et de store avec post-incrémentation, les instructions de manipulation de bits et les instructions SIMD qui ne font pas partie de l'ISA RISC-V standard.

## 5.3 Extension de jeu d'instructions

Une extension de jeu d'instructions (ISE) étend une ISA avec de nouvelles instructions ou d'autres fonctionnalités. Une implémentation de l'ISA étendue pourra toujours exécuter du code machine pour les versions de l'ISA sans ces extensions. Par contre, le code machine utilisant des extensions ne fonctionnera que sur les implémentations qui prennent en charge ces extensions. Les ISE permettent d'améliorer différents paramètres tels que le nombre de cycles, l'utilisation de la mémoire (mémoire de données et mémoire de programme), la flexibilité ou encore la consommation d'énergie. Par contre, l'implémentation des nouvelles instructions augmente la surface du processeur et peut impacter sa fréquence de fonctionnement. Le jeu d'instructions x86 fournit de nombreux exemples d'ISE développées notamment par Intel et AMD.

<figure><img src="image_46.png" /><figcaption>FIGURE 5.2 – Extension de jeu d'instructions.</figcaption></figure>

<footnote n="2">2. https://www.openhwgroup.org/</footnote>

<footnote n="3">3. Une liste complète des cœurs CORE-V est disponible à https://github.com/openhwgroup/core-v-cores</footnote>

<footnote n="4">4. https://github.com/openhwgroup/cva6</footnote>

<footnote n="5">5. https://github.com/openhwgroup/cv32e40p</footnote>

<footnote n="6">6. https://github.com/openhwgroup/cve2</footnote>

<footnote n="7">7. https://github.com/openhwgroup/core-v-cores</footnote>
**Comparaison avec un coprocesseur** Une autre solution pour améliorer les performances d'une implémentation spécifique est d'ajouter un coprocesseur au processeur. Un modèle type d'utilisation d'un coprocesseur se compose de quelques étapes simples : configurer le coprocesseur, charger les données d'entrée, lancer le coprocesseur et récupérer les résultats. Le transfert des données entre le processeur et le coprocesseur engendre un coût important en termes de nombre de cycles. Une ISE est un compromis entre une implantation logicielle et un coprocesseur. Elle fournit un couplage plus étroit du matériel personnalisé au *pipeline* du processeur. Les nouvelles instructions permettent de réduire le temps d'exécution par rapport à une implantation logicielle, et de réduire la surface par rapport à un coprocesseur.

## 5.4 ISE pour la contre-mesure de masquage

### 5.4.1 Pourquoi une ISE dédiée au masquage ?

Une ISE est une solution pertinente pour améliorer les performances du masquage et augmenter sa sécurité, tout en maintenant une utilisation simple et flexible.

**Performance** Les implémentations de masquage uniquement logiciel imposent un surcoût important en termes de temps d'exécution, de taille de code exécutable et de valeurs aléatoires de haute qualité. Par exemple, le schéma de masquage de [RP10] dont les performances sont décrites dans le tableau 5.2 induit un surcoût relativement important par rapport à la solution non masquée de [Ber+02]. Le nombre d'instructions est multiplié par 30, le nombre de cycles d'horloge est multiplié par 26, la taille du code est multipliée par 6, et l'usage de la mémoire est presque multiplié par 3. Le masquage est donc très coûteux en ressource, et cela, d'autant plus que l'ordre de masquage est élevé. Une ISE peut aider à réduire le surcoût du masquage en remplaçant un ensemble d'instructions par des instructions dédiées. Pour illustrer les gains apportés par les ISE, le tableau 5.2 présente les résultats d'implémentation de AES avec l'ISE non masquée de [Mar+20] et l'ISE masquée de [Gao+21]. L'ISE non masquée de [Mar+20] accélère le chiffrement AES d'un facteur 8, et réduit la taille du code par 3. L'ISE masquée de [Gao+21] accélère le chiffrement AES d'un facteur 60 par rapport à la version masquée sans ISE de [RP10].

<table><caption>TABLE 5.2 – Coût/Performance du masquage d'ordre 1 de AES extrait de [Gao+21].</caption><thead><tr><th rowspan="2">Référence</th><th rowspan="2">Masqué</th><th rowspan="2">ISE</th><th colspan="2">Temps</th><th colspan="2">Taille de code (octet)</th></tr><tr><th>Instr.</th><th>Cycles</th><th>Instr.</th><th>Données</th></tr></thead><tbody><tr><td>[Ber+02]</td><td>✗</td><td>✗</td><td>1932</td><td>2427</td><td>2148</td><td>524</td></tr><tr><td>[RP10]</td><td>✓</td><td>✗</td><td>59823</td><td>64200</td><td>14416</td><td>1356</td></tr><tr><td>[Mar+20]</td><td>✗</td><td>✓</td><td>238</td><td>291</td><td>730</td><td>10</td></tr><tr><td>[Gao+21]</td><td>✓</td><td>✓</td><td>1012</td><td>1113</td><td>968</td><td>84</td></tr></tbody></table>

**Fuite micro-architecturale** Les protections purement logicielles sont très limitées en raison de fuites dans la micro-architecture du processeur. Par exemple, [Gao+19] montre que les interactions de bits dans les instructions ARM des cœurs M0/M3 sont dévastatrices pour le masquage d'ordre supérieur. Cela oblige tout logiciel qui tente d'être sécurisé à être extrêmement
conservateur dans ses hypothèses, dégradant les performances en termes de temps d'exécution et de taille de code. Une ISE permet d'atténuer les fuites micro-architecturales en adoptant une approche similaire à l'ISA augmentée (ou aISA) de [GYH18] et en contraignant la micro-architecture pour répondre à des propriétés de sécurité plus fortes.

**Flexibilité et simplicité d'utilisation** La conception de schémas de masquage est une tâche relativement difficile. Une ISE dédiée au masquage peut fournir un moyen simple de masquer une implémentation. De plus, une ISE dédiée au masquage est une solution efficace pour augmenter la sécurité et les performances en gardant de la flexibilité.

### 5.4.2 ISE dédiées au masquage de l'état de l'art

Les ISE cryptographiques dédiées au masquage sont assez récentes. Les instructions masquées ajoutées aident à réduire le surcoût du masquage en remplaçant certaines séquences d'instructions (éventuellement longues) par un très petit nombre de séquences dédiées, et augmentent la sécurité en atténuant les fuites micro-architecturales.

Une première ISE pour le masquage d'ordre 1 a été proposée par [TG07]. Le processeur est divisé en une zone non sécurisée et une zone sécurisée. Les données critiques dans la zone non sécurisée sont toujours protégées par un masque booléen. Les opérations les plus critiques en matière de sécurité sont implémentées dans la zone sécurisée en utilisant un style logique résistant à la DPA. La structure de la zone sécurisée est illustrée à la figure 5.3. Les opérandes op1_m et op2_m sont d'abord démasquées et traitées par l'unité fonctionnelle FU, donnant le résultat res. Un générateur de nombres aléatoires produit un nouveau masque et l'applique au résultat avant qu'il ne quitte la zone sécurisée. Cette extension masquée conduit à un surcoût d'un facteur 3,5 en surface, 1,2 pour le chemin critique et 3,5 pour la consommation électrique. Par la suite, des ISE similaires à [TG07] ont été proposées telles que [Nak+11; BBT10; TKS10; TKS11].

<figure><img src="image_47.png" /><figcaption>FIGURE 5.3 – Structure de la zone sécurisée de l'ISE de [TG07].</figcaption></figure>
[Gro+16] présente une ISE dédiée au masquage, que nous nommons GJM, pour le cœur RISC-V V-scale et des ordres de masquage $d \in \{1, 2, 3, 4\}$ fixés au moment de la synthèse. La figure 5.4 est un schéma simplifié du cœur avec l'ISE dédiée au masquage de [Gro+16], dans lequel les flèches rouges représentent des variables masquées et $reg[x]$ désigne la valeur du registre d'indice x dans le fichier de registres. Le fichier de registres est abrégé en RF pour «register file» en anglais. Le fichier de registres est dupliqué pour stocker les $d+1$ parts d'une variable masquée. Cette solution est donc limitée à de petits ordres de masquage puisque la taille du fichier de registres est multipliée par $d+1$. Le chemin de données du processeur est séparé en une partie protégée et une partie non protégée. La partie non protégée applique les opérations de l'ALU de base sur les opérandes préalablement démasquées. La partie protégée contient une ALU masquée qui implémente les instructions masquées en utilisant la représentation DOM [GMK16]. Les instructions étant masquées avec DOM, les utilisateurs doivent rafraîchir les masquages à certains endroits bien choisis pour maintenir la sécurité.

<figure><img src="image_48.png" /><figcaption>FIGURE 5.4 – Schéma de l'ISE de [Gro+16]. Les flèches rouges représentent des variables masquées. $reg[x]$ désigne la valeur du registre d'indice x dans le fichier de registres.</figcaption></figure>

[DGH19] présente une ISE dédiée au masquage d'ordre 1 pour un cœur RISC-V avec une protection SCA lors des accès mémoires. Un processeur RISC-V est complètement masqué avec le schéma de masquage TI [NRR06]. Pour protéger les accès mémoires, un masque supplémentaire est généré à partir d'un aléa et de l'adresse mémoire pour remasquer une variable avant de la stocker en mémoire. Le masque étant généré à la volée, il n'est pas nécessaire de le stocker en mémoire. Cela supprime le surcoût de mémoire associé au masquage et protège la variable masquée en mémoire. Il n'existe pas d'évaluation de la surface, mais on peut penser que le coût de cette ISE est important car les implémentations TI nécessitent un nombre de parts élevé (voir section 3.4).

[Kia+21] présente SKIVA, une ISE pour le cœur LEON3 (jeu d'instructions SPARC V8). Les instructions de Skiva accélèrent les implémentations BS masquées aux ordres 1 ou 3. Les nouvelles instructions permettent d'accélérer l'algorithme de multiplication masquée défini dans [Bar+17]. Il combine également des protections de masquage et de détection de fautes.

[Gao+21] présente une ISE dédiée au masquage d'ordre 1 pour le cœur SCARV RISC-V, que nous nommons GGM. Cette ISE utilise la représentation DOM [GMK16]. La figure 5.5 est un schéma simplifié du cœur avec l'ISE dédiée au masquage de [Gao+21]. Le fichier de registres est divisé en 2 parties (une partie pour chaque part). Cette solution est limitée aux petites ordres de masquage car une ISE dédiée au masquage d'ordre $d$ diviserait le fichier de registres en $d+1$ parties.
<figure><img src="image_49.png" /><figcaption>FIGURE 5.5 – Schéma de l’ISE de [Gao+21]. $reg[x]$ désigne la valeur du registre d’indice $x$ dans le fichier de registres.</figcaption></figure>

[MP21] présente SME, une ISE dédiée au masquage pour le cœur RISC-V SCARV et pour des ordres de masquage $d \in \{1, 2, 3\}$ fixés au moment de la synthèse. Leur approche repose sur des similitudes entre les implémentations de schémas de masquage d'ordre supérieur et la programmation vectorielle. La figure 5.6 est un schéma simplifié du cœur avec l'ISE dédiée au masquage de [MP21]. La première part d'une variable masquée est stockée dans le fichier de registres. Les autres parts sont stockées dans des fichiers de registres dédiés, placées dans l'étage d'exécution du *pipeline*. Une ALU masquée implémente les instructions masquées en utilisant la représentation DOM [GMK16]. L'ISE intègre une version masquée de l'extension cryptographique scalaire officielle RISC-V pour AES [Mar+20].

<figure><img src="image_50.png" /><figcaption>FIGURE 5.6 – Schéma de l’ISE de [MP21]. $reg[x]$ désigne la valeur du registre d’indice $x$ dans le fichier de registres.</figcaption></figure>
### 5.4.3 Comparaison des ISE dédiées au masquage de l'état de l'art

Les tableaux 5.3 et 5.4 présentent les performances et surfaces de différentes ISE dédiées au masquage de l'état de l'art. HW-M-SKIVA, HW-M-GGM et HW-M-SME désignent respectivement des implémentations de AES masquées en utilisant les ISE SKIVA, GGM et SME. On constate que HW-M-SME et HW-M-GGM réduisent fortement le coût du masquage. Même à l'ordre 3, HW-M-SME induit seulement un surcoût de 1,5 par rapport à SW-TTABLE, ce qui est cohérent car HW-M-SME est optimisée pour le chiffrement AES. En revanche, HW-M-SKIVA engendre un surcoût de 4,0 à l'ordre 1 et de 13,2 à l'ordre 3 par rapport à SW-BS. HW-M-SKIVA est moins efficace que HW-M-SME, mais est applicable à toutes sortes de cryptosystèmes contrairement à HW-M-SME. En termes de surface, GGM est la plus petite extension à l'ordre 1 avec une augmentation de 1.25 en FFs et 1.82 en LUTs. GJM et SME induisent des coûts plus important en surface, puisque le fichier de registres est dupliqué.

<table><caption>TABLE 5.3 – Performance de différentes ISE dédiées au masquage de l'état de l'art. Le temps d'exécution est donné en nombre cycles par bloc.</caption><thead><tr><th rowspan="2">Source</th><th rowspan="2">Implém.</th><th rowspan="2">Cœur</th><th rowspan="2">d</th><th colspan="2">Temps</th></tr><tr><th>Cycles</th><th>cmp</th></tr></thead><tbody><tr><td rowspan="3">[Kia+21]</td><td>SW-BS</td><td rowspan="3">Leon3</td><td>0</td><td>704</td><td>base</td></tr><tr><td rowspan="2">HW-M-SKIVA</td><td>1</td><td>2816</td><td>×4,0</td></tr><tr><td>3</td><td>9264</td><td>×13,2</td></tr><tr><td rowspan="2">[Gao+21]</td><td>SW-TTABLE</td><td rowspan="2">SCARV</td><td>0</td><td>1016</td><td>base</td></tr><tr><td>HW-M-GGM</td><td>1</td><td>1113</td><td>×1,1</td></tr><tr><td rowspan="4">[MP21]</td><td>SW-TTABLE</td><td rowspan="4">SCARV</td><td>0</td><td>1016</td><td>base</td></tr><tr><td rowspan="3">HW-M-SME</td><td>1</td><td>1142</td><td>×1,1</td></tr><tr><td>2</td><td>1333</td><td>×1,3</td></tr><tr><td>3</td><td>1524</td><td>×1,5</td></tr></tbody></table>

<table><caption>TABLE 5.4 – Surface et période de différentes ISE dédiées au masquage de l'état de l'art. FF, LUT et P sont données en surcoût.</caption><thead><tr><th rowspan="2">Source</th><th rowspan="2">ISE</th><th rowspan="2">Cœur</th><th rowspan="2">d</th><th colspan="3">Surface & période</th></tr><tr><th>FF</th><th>LUT</th><th>P</th></tr></thead><tbody><tr><td rowspan="5">[Gro+16]</td><td rowspan="5">Sans ISE<br>GJM</td><td rowspan="5">V-scale</td><td>0</td><td>base</td><td>base</td><td>base</td></tr><tr><td>1</td><td>×1,9</td><td>×1,6</td><td>×0,8</td></tr><tr><td>2</td><td>×2,6</td><td>×2,2</td><td>×0,8</td></tr><tr><td>3</td><td>×3,6</td><td>×2,8</td><td>×0,8</td></tr><tr><td>4</td><td>×4,6</td><td>×3,6</td><td>×1,1</td></tr><tr><td rowspan="2">[Gao+21]</td><td rowspan="2">Sans ISE<br>GGM</td><td rowspan="2">SCARV</td><td>0</td><td>base</td><td>base</td><td>base</td></tr><tr><td>1</td><td>×1,3</td><td>×1,8</td><td>×1,1</td></tr><tr><td rowspan="4">[MP21]</td><td rowspan="4">Sans ISE<br>SME</td><td rowspan="4">SCARV</td><td>0</td><td>base</td><td>base</td><td>base</td></tr><tr><td>1</td><td>×1,5</td><td>×1,6</td><td>×1,6</td></tr><tr><td>2</td><td>×1,9</td><td>×1,9</td><td>×1,7</td></tr><tr><td>3</td><td>×2,6</td><td>×2,2</td><td>×1,7</td></tr></tbody></table>
<figure><img src="image_51.png" /></figure>
Deuxième partie

Contributions
<figure><img src="image_52.png" /></figure>
# Chapitre 6

## Environnement expérimental et
reproduction de résultats de solutions de
l'état de l'art

Une chaîne d'outils RISC-V a été mise en place pour compiler et simuler des codes sur le cœur CV32E40P. Des solutions de l'état de l'art ont ensuite été réimplémentées sur le cœur CV32E40P pour étudier leurs performances et les comparer à nos résultats d'implémentation dans la suite. Pour implémenter nos ISE, les nouvelles instructions sont ajoutées à la chaîne d'outils et implantées dans le cœur. Un générateur de traces simulées de consommation a été développé pour analyser la sécurité de nos implémentations contre certaines attaques SCA.

Dans ce chapitre, la section 6.1 donne un aperçu de la chaîne d'outils utilisée pour compiler et simuler un code sur une architecture RISC-V. La section 6.2 décrit les modifications nécessaires pour ajouter une ISE à un cœur RISC-V. La section 6.3 présente les résultats de la réimplantation de solutions de l'état de l'art sur le cœur CV32E40P. La section 6.4 décrit l'évaluation pratique de la résistance contre certaines attaques SCA.

### 6.1 Environnement expérimental

Pour réaliser nos ISE, un *environnement expérimental* a été mis en place (voir figure 6.1) en utilisant des outils libres de la communauté RISC-V pour compiler un code source, simuler son exécution sur une architecture RISC-V et synthétiser le cœur CV32E40P.

<figure><img src="image_53.png" /><figcaption>FIGURE 6.1 – Notre environnement expérimental.</figcaption></figure>
### 6.1.1 Génération d'un exécutable

La chaîne d'outils GNU<fnref n="1" /> pour RISC-V est utilisée pour générer des exécutables RISC-V. Elle dispose notamment d'un *compilateur croisé* GCC capable de créer un code assembleur pour une architecture RISC-V, ainsi qu'une collection d'outils binaires tels que l'*assembleur* et l'*éditeur de liens*. Un programme peut être compilé pour s'exécuter avec le système d'exploitation Linux. Les programmes exécutés sous Linux bénéficient d'une prise en charge complète du système. Cependant, la durée d'exécution est longue en raison de la nécessité de démarrer Linux dans l'environnement de simulation. Alternativement, un programme peut être compilé pour s'exécuter avec un «*proxy kernel*», abrégé en PK, sans prise en charge complète du système d'exploitation. Le PK RISC-V<fnref n="2" /> fournit un environnement de démarrage Linux et transmet simplement les *appels systèmes* à l'hôte via l'*interface hôte-cible*, abrégée en HTIF pour «*host target interface*» en anglais. Le PK prend en charge uniquement les appels systèmes les plus couramment utilisés tels que *printf*. Une autre solution est de compiler un programme pour qu'il s'exécute en «*bare metal*». Les programmes exécutés en «*bare metal*» ne prennent pas en charge de bibliothèques C. Les appels systèmes doivent être gérés directement par le programme.

### 6.1.2 Simulation d'un code

Deux méthodologies ont été mises en place pour simuler l'exécution d'un programme sur une architecture RISC-V. La première consiste à exécuter un programme sur Spike, un simulateur du jeu d'instructions RISC-V. La seconde réalise une simulation précise au niveau du cycle du cœur CV32E40P en utilisant Verilator.

**Simulation du jeu d'instructions RISC-V avec Spike**

Spike<fnref n="3" /> est un *simulateur de jeu d'instructions*, abrégé en ISS pour «*instruction set simulator*» en anglais, permettant de simuler l'ISA RISC-V. En utilisant Spike, les binaires compilés pour une architecture RISC-V peuvent être exécutés sans processeur RISC-V. Les instructions RISC-V sont décodées et exécutées en utilisant le modèle fonctionnel d'un processeur RISC-V. L'utilisation d'un ISS présente l'avantage de s'abstraire de l'implémentation matérielle d'une ISA. En contrepartie, la simulation n'est pas précise au niveau du cycle (par exemple, le *pipeline* d'un processeur n'est pas simulé).

**Simulation cycle précis avec Verilator**

Pour simuler un programme sur le cœur CV32E40P, nous avons utilisé le *simulateur précis au niveau du cycle* Verilator<fnref n="4" />. Un banc de test a été développé dans lequel le cœur CV32E40P est relié à une mémoire. La mémoire est initialisée avec le code à tester. Le simulateur Verilator évalue alors le circuit RTL à chaque cycle d'horloge. Contrairement à la simulation avec un ISS, la simulation avec Verilator prend en compte l'architecture du CV32E40P. Ce type de simulation est cependant moins rapide que la simulation avec un ISS.

<footnote n="1">1. https://github.com/riscv-collab/riscv-gnu-toolchain</footnote>

<footnote n="2">2. https://github.com/riscv-software-src/riscv-pk</footnote>

<footnote n="3">3. https://github.com/riscv-software-src/riscv-isa-sim</footnote>

<footnote n="4">4. https://www.veripool.org/verilator/</footnote>
### 6.1.3 Synthèse FPGA

Pour évaluer la surface et la fréquence de fonctionnement du CV32E40P, le cœur est synthétisé sur un FPGA. La synthèse est réalisée en utilisant le logiciel Vivado 2019.2⁵ de AMD-Xilinx. Le cœur CV32E40P est synthétisé sur le FPGA Digilent Arty A7⁶.

## 6.2 Conception et mise en œuvre d'une ISE

### 6.2.1 Conception d'une ISE

Pour concevoir une ISE, une exploration de l'espace de conception a été réalisée. Nous avons étudié les implémentations logicielles masquées du chiffrement AES sur le processeur cible afin d'identifier les principaux goulots d'étranglement. De nouvelles instructions ont alors été identifiées pour réduire le nombre d'instructions exécutées et augmenter la sécurité. Une exploration de différents types d'ISE dédiées au masquage a également été réalisée pour analyser les compromis entre performance et surface. La micro-architecture du processeur a été étudiée pour détecter l'origine de fuites qui peuvent conduire à une recombinaison des parts. Cette analyse nous a conduit à identifier de nouvelles instructions masquées. Chaque ISE proposée et les instructions correspondantes ajoutées seront détaillées dans les chapitres suivants. Nous présentons dans cette section uniquement la méthodologie commune aux différentes contributions.

### 6.2.2 Ajout des nouvelles instructions à l'assembléeur

Lorsque de nouvelles instructions sont identifiées, il est nécessaire de les ajouter à la chaîne d'outils afin que des programmes informatiques puissent les utiliser. L'option la plus simple consiste à ajouter les nouvelles instructions dans l'assembléeur, car celui-ci offre généralement une structure moins complexe que le compilateur. Les opcodes et d'autres informations sur les nouvelles instructions sont ajoutés à l'assembléeur. Les nouvelles instructions peuvent ensuite être utilisées dans des programmes assembleurs ainsi que dans des langages de haut niveau tel que le langage C (en intégrant directement le code assembleur). L'assembléeur modifié permet alors de traduire un programme informatique utilisant les nouvelles instructions en un exécutable.

**Choix des opcodes** Les opcodes utilisables pour de nouvelles instructions sont décrits par la spécification RISC-V [WA19]. Les deux premiers bits de l'opcode ont toujours pour valeur 1. Les opcodes se divisent en 5 catégories en fonction de la valeur de `opcode[6:2]` comme le montre le tableau 6.1. Les extensions standards utilisent uniquement des opcodes standards et ne doivent pas entrer en conflit les uns avec les autres dans leurs utilisations de ces opcodes. Les opcodes réservés ne sont actuellement pas définis, mais sont réservés pour les futures extensions standards. Les opcodes personnalisés sont réservés à un usage expérimental. Pour nos ISE, nous avons choisi d'utiliser l'opcode 1101011.

<footnote n="5">5. https://www.xilinx.com/products/design-tools/vivado.html</footnote>

<footnote n="6">6. https://digilent.com/reference/programmable-logic/arty-a7/start</footnote>
<table><caption>TABLE 6.1 – Description des différents opcodes de la spécification RISC-V [WA19]. Opcodes standards en bleu, opcodes réservés aux extensions futures en rouge, opcodes personalisés en vert, opcodes réservés à RV128I en gris, opcodes réservés aux instructions de taille supérieure à 32 bits en jaune.</caption><thead><tr><th>opcode[4 : 2]<br>opcode[6 : 5]</th><th>000</th><th>001</th><th>010</th><th>011</th><th>100</th><th>101</th><th>110</th><th>111</th></tr></thead><tbody><tr><th>00</th><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><th>01</th><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><th>10</th><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><th>11</th><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

**Utilisation logicielle d'une nouvelle instruction**

Avec les modifications apportées à l'as-sembleur, les nouvelles instructions peuvent être utilisées dans un langage C à l'aide d'un bloc asm. L'utilisation d'une nouvelle instruction ise.instr est décrite à la figure 6.2. On peut alors vérifier que l'instruction ise.instr est générée en observant le code assembleur de l'exécutable.

```c
int main(void) {
    uint32_t a = 1;
    uint32_t b = 2;
    uint32_t c;

    asm volatile (
        "ise.instr %[rd], %[rs1], %[rs2]\n\t"
        : [rd] "=r" (c)
        : [rs1] "r" (a), [rs2] "r" (b)
    );
}
```

<caption>FIGURE 6.2 – Utilisation logicielle d'une nouvelle instruction.</caption>

### 6.2.3 Ajout des nouvelles instructions à Spike

Pour pouvoir simuler les nouvelles instructions personnalisées ajoutées à l'assembleur, Spike doit être modifié. Les opcodes des nouvelles instructions sont d'abord ajoutés pour que Spike puisse les reconnaître. Ensuite, une description du comportement fonctionnel des nouvelles instructions est ajoutée. La simulation avec Spike permet déja de fournir des résultats en termes de performances et de besoins en mémoire, permettant une première sélection entre différentes solutions.

### 6.2.4 Ajout des nouvelles instructions au processeur

Les instructions personnalisées doivent ensuite être intégrées dans le processeur CV32E40P. Les modifications à apporter dépendent dans une large mesure de la nature des nouvelles instructions. Les modifications courantes englobent la logique de décodage et l'ALU. La logique de décodage doit reconnaître les nouveaux opcodes des instructions ajoutées et définir les signaux de contrôle en conséquence. Les nouvelles instructions sont implémentées dans l'ALU existante ou une nouvelle ALU. D'autres changements pourraient être l'ajout de registres personnalisés ou la modification du nombre de ports de lecture et d'écriture du fichier de registres. Un
programme qui utilise l'ISE peut être exécuté sur le processeur modifié afin de recueillir des données de performances précises. L'implantation matérielle du processeur modifié sur FPGA permet d'évaluer la surface et la période minimale du processeur.

## 6.3 Réimplantation de l'état de l'art

Une comparaison directe des solutions de protection par masquage de l'état de l'art n'est pas pertinente car les cœurs et les FPGA utilisés sont différents dans les papiers. Pour réaliser une comparaison cohérente, nous avons réimplantées plusieurs solutions de l'état de l'art, toutes pour AES, dans le cœur CV32E40P.

### 6.3.1 Évaluation des performances

Pour évaluer les performances des codes implémentés, nous utilisons les registres de contrôle et d'état, abrégés en CSR pour «control and status registers» en anglais. L'ISA RISC-V possède des CSR fournissant des informations sur l'état et les performances du processeur. Le registre time compte le temps écoulé. Le registre cycle contient le décompte du nombre de cycles d'historoge exécutés par le processeur. Le registre instret compte le nombre d'instructions exécutées par le processeur. Les CSR sont accessibles par des instructions spécifiques. Les valeurs des registres time, cycle et instret sont lues avant et après le code à évaluer, puis une soustraction permet d'obtenir le temps d'exécution ainsi que le nombre de cycles et d'instructions.

### 6.3.2 Solutions logicielles

Des solutions logicielles sans ISE de AES ont été réimplantées et sont étiquetées SW-... Les performances sur le cœur RISC-V CV32E40P sont décrites dans le tableau 6.2 et la figure 6.3. SW-BW, SW-RW sont des implémentations de AES basées sur le calcul (voir sous-section 4.1.1) reproduites respectivement de [DR02] et de [Ber+02]. SW-TTABLE est une implémentation T-tables de AES [DR02] (voir sous-section 4.1.2). SW-BS et SW-16S sont respectivement des implémentations BS (voir sous-section 4.1.3) et 16-slicing (voir sous-section 4.1.4) générées en utilisant Usuba [MD19]. SW-M-RP et SW-M-CPRR sont des implémentations masquées basées respectivement sur le schéma de masquage RP [RP10] (voir sous-section 4.2.1) et CPRR [Cor+14] (voir sous-section 4.2.2). SW-M-HTABLE est une implémentation masquée de AES utilisant la méthode des tables masquées de [CRZ18] (voir sous-section 4.2.3). SW-M-BS est une implémentation BS masquée générée par Tornado [Bel+20] (voir sous-section 4.2.4). SW-M-SS est une implémentation «share slicing» (voir sous-section 4.2.5) adaptée de [JS17; Gré+18] et étendue pour masquer aux ordres $d \in \{1, 3, 7, 15, 31\}$. Nos résultats de réimplantation de la figure 6.2 sont cohérents avec ceux de l'état de l'art des tableaux 4.1 et 4.2. SW-TTABLE et SW-BS sont les implémentations non masquées les plus performantes. Les implémentations masquées les plus performances sont SW-M-BS et SW-M-SS. L'implémentation masquée SW-M-CPRR est légèrement plus performante que SW-M-RP. Comme constaté au chapitre 4, SW-M-HTABLE engendre des coûts beaucoup plus élevés que toutes les autres solutions masquées.
<table><caption>TABLE 6.2 – Résultats de réimplantations logicielles de plusieurs solutions de l'état de l'art sur le cœur CV32E40P pour différents ordres de masquage. Le temps d'exécution est donné en nombre de cycles pour chiffrer un bloc avec AES. cmp1 et cmp2 comparent respectivement le temps d'exécution par rapport à SW-TTABLE et SW-M-BS.</caption><thead><tr><th rowspan="2">d</th><th rowspan="2">Implémentation</th><th colspan="3">Temps</th></tr><tr><th>Cycles</th><th>cmp1</th><th>cmp2</th></tr></thead><tbody><tr><td rowspan="5">0</td><td>SW-TTABLE</td><td>1266</td><td>base</td><td rowspan="5">n.a.</td></tr><tr><td>SW-BW</td><td>5521</td><td>×4,4</td></tr><tr><td>SW-RW</td><td>4130</td><td>×3,3</td></tr><tr><td>SW-BS</td><td>2040</td><td>×1,6</td></tr><tr><td>SW-16S</td><td>3770</td><td>×2,9</td></tr><tr><td rowspan="5">1</td><td>SW-M-BS</td><td>26001</td><td>×21</td><td>base</td></tr><tr><td>SW-M-SS</td><td>43377</td><td>×34</td><td>×1,7</td></tr><tr><td>SW-M-CPRR</td><td>168090</td><td>×133</td><td>×6,5</td></tr><tr><td>SW-M-RP</td><td>264186</td><td>×209</td><td>×10,2</td></tr><tr><td>SW-M-HTABLE</td><td>1039485</td><td>×821</td><td>×40,0</td></tr><tr><td rowspan="4">2</td><td>SW-M-BS</td><td>50830</td><td>×40</td><td>base</td></tr><tr><td>SW-M-CPRR</td><td>298785</td><td>×236</td><td>×5,9</td></tr><tr><td>SW-M-RP</td><td>455078</td><td>×360</td><td>×9,0</td></tr><tr><td>SW-M-HTABLE</td><td>1810352</td><td>×1430</td><td>×35,6</td></tr><tr><td rowspan="5">3</td><td>SW-M-BS</td><td>98575</td><td>×78</td><td>base</td></tr><tr><td>SW-M-SS</td><td>94351</td><td>×75</td><td>×1,0</td></tr><tr><td>SW-M-CPRR</td><td>487092</td><td>×385</td><td>×4,9</td></tr><tr><td>SW-M-RP</td><td>702266</td><td>×555</td><td>×7,1</td></tr><tr><td>SW-M-HTABLE</td><td>2947581</td><td>×2328</td><td>×29,9</td></tr><tr><td rowspan="5">7</td><td>SW-M-BS</td><td>300414</td><td>×237</td><td>base</td></tr><tr><td>SW-M-SS</td><td>410365</td><td>×324</td><td>×1,4</td></tr><tr><td>SW-M-CPRR</td><td>1712402</td><td>×1353</td><td>×5,7</td></tr><tr><td>SW-M-RP</td><td>2339654</td><td>×1848</td><td>×7,8</td></tr><tr><td>SW-M-HTABLE</td><td>11120610</td><td>×8784</td><td>×37,0</td></tr><tr><td rowspan="5">15</td><td>SW-M-BS</td><td>1041285</td><td>×822</td><td>base</td></tr><tr><td>SW-M-SS</td><td>1498669</td><td>×1184</td><td>×1,4</td></tr><tr><td>SW-M-CPRR</td><td>6328095</td><td>×4998</td><td>×6,1</td></tr><tr><td>SW-M-RP</td><td>8349458</td><td>×6595</td><td>×8,0</td></tr><tr><td>SW-M-HTABLE</td><td>44908227</td><td>×35473</td><td>×43,1</td></tr><tr><td rowspan="5">31</td><td>SW-M-BS</td><td>3716920</td><td>×2936</td><td>base</td></tr><tr><td>SW-M-SS</td><td>5566866</td><td>×4397</td><td>×1,5</td></tr><tr><td>SW-M-CPRR</td><td>24740662</td><td>×19542</td><td>×6,7</td></tr><tr><td>SW-M-RP</td><td>32177701</td><td>×25417</td><td>×8,7</td></tr><tr><td>SW-M-HTABLE</td><td>182251172</td><td>×143958</td><td>×49,0</td></tr></tbody></table>
<figure><img src="image_54.png" /><figcaption>FIGURE 6.3 – Résultats de réimplantations logicielles de plusieurs solutions de l'état de l'art sur le cœur CV32E40P pour différents ordres de masquage. Le temps d'exécution est donné en nombre de cycles pour chiffrer un bloc avec AES.</figcaption></figure>

6.3.3 ISE dédiées au masquage de l'état de l'art

Plusieurs ISE dédiées au masquage de l'état de l'art ont été réimplantées sur le cœur CV32E40P pour réaliser une comparaison plus objective des différentes solutions existantes. Comme nous nous intéressons aux ISE dédiées au masquage à des ordres élevés, nous avons réimplémenté uniquement SKIVA et SME. GJM n'a pas été réimplémentée car il n'y a pas d'implémentation logicielle disponible pour cette ISE. Les tableaux 6.3 et 6.4 présentent nos résultats d'implantations. Nos résultats d'implantations de SKIVA et SME sont cohérents avec ceux de l'état de l'art présentés dans les tableaux 5.3 et 5.4. Comme indiqué dans 5.4.3, HW-M-SME est très performant puisqu'il est optimisé pour le chiffrement AES, mais engendre une augmentation importante de la surface. À l'inverse, les gains de performance avec HW-M-SKIVA sont moins importants, mais le coût matériel est extrêmement faible.

<table><caption>TABLE 6.3 – Performance de différentes ISE dédiées au masquage de l'état de l'art réimplantées sur le cœur CV32E40P. Le temps d'exécution est donné en nombre de cycles pour chiffrer un bloc avec AES. cmp1 et cmp2 comparent respectivement le temps d'exécution par rapport à SW-TTABLE et SW-M-BS.</caption><thead><tr><th rowspan="2">d</th><th rowspan="2">Implémentation</th><th colspan="3">Temps</th></tr><tr><th>Cycles</th><th>cmp1</th><th>cmp2</th></tr></thead><tbody><tr><td>0</td><td>SW-TTABLE</td><td>1266</td><td>base</td><td>n.a.</td></tr><tr><td rowspan="3">1</td><td>SW-M-BS</td><td>26001</td><td>×21</td><td>base</td></tr><tr><td>HW-M-SKIVA</td><td>14355</td><td>×11,3</td><td>/1,8</td></tr><tr><td>HW-M-SME</td><td>1152</td><td>×0,9</td><td>/22,6</td></tr><tr><td rowspan="2">2</td><td>SW-M-BS</td><td>50830</td><td>×40</td><td>base</td></tr><tr><td>HW-M-SME</td><td>1271</td><td>×1,0</td><td>/40.0</td></tr><tr><td rowspan="3">3</td><td>SW-M-BS</td><td>98575</td><td>×78</td><td>base</td></tr><tr><td>HW-M-SKIVA</td><td>47062</td><td>×37,2</td><td>/2,1</td></tr><tr><td>HW-M-SME</td><td>1417</td><td>×1,1</td><td>/69,6</td></tr></tbody></table>
<table><caption>TABLE 6.4 – Surface et période de différentes ISE dédiées au masquage de l'état de l'art réimplantées sur le cœur CV32E40P.</caption><thead><tr><th rowspan="2">d</th><th rowspan="2">ISE</th><th colspan="5">Surface & période</th></tr><tr><th>FF</th><th>cmp</th><th>LUT</th><th>cmp</th><th>P(ns)</th></tr></thead><tbody><tr><td>0</td><td>Sans ISE</td><td>2141</td><td>base</td><td>4782</td><td>base</td><td>14,6</td></tr><tr><td rowspan="2">1</td><td>SKIVA</td><td>2167</td><td>×1,0</td><td>5040</td><td>×1,1</td><td>14,5</td></tr><tr><td>SME</td><td>2974</td><td>×1,4</td><td>7015</td><td>×1,5</td><td>14,5</td></tr><tr><td>2</td><td>SME</td><td>3839</td><td>×1,8</td><td>8583</td><td>×1,8</td><td>16,5</td></tr><tr><td rowspan="2">3</td><td>SKIVA</td><td>2167</td><td>×1,0</td><td>5040</td><td>×1,1</td><td>14,5</td></tr><tr><td>SME</td><td>5077</td><td>×2,4</td><td>10567</td><td>×2,2</td><td>16,2</td></tr></tbody></table>

## 6.4 Analyse de la résistance contre les attaques SCA

### 6.4.1 Génération de traces simulées de consommation

Pour évaluer la résistance contre les attaques SCA, nous avons développé un générateur de traces simulées de consommation. Les traces simulées peuvent être réalisées en utilisant l'ISS Spike, ou la simulation cycle précis avec Verilator.

**Génération de traces simulées avec Spike**
Pour générer des traces simulées de consommation avec Spike, nous utilisons le mode de débogage interactif qui permet de voir le contenu d'un registre ou d'un emplacement mémoire et d'exécuter des instructions une par une. L'état interne du banc de registres est récupéré à chaque instruction. La suite des états récupérés permet de calculer une trace d'activité théorique du processeur en utilisant la distance de Hamming comme modèle de consommation. Une fonction indique dans le code C à quel moment commencer et terminer l'acquisition de la trace. La figure 6.4 montre une trace simulée avec Spike pendant le chiffrement AES, dans laquelle on peut distinguer les différentes rondes. La trace simulée obtenue avec Spike ne correspond pas à l'activité réelle du processeur, mais permet une première estimation assez rapide des fuites.

<figure><img src="image_55.png" /><figcaption>FIGURE 6.4 – Trace de consommation simulée avec Spike pendant le chiffrement AES.</figcaption></figure>
**Génération de traces simulées avec Verilator** Pour générer des traces simulées avec Verilator, l'état interne du processeur est d'abord récupéré à chaque instruction en utilisant la «netlist» du CV32E40P. La consommation est ensuite estimée en calculant la distance de Hamming pour obtenir le nombre de transitions. Une trace d'activité théorique du processeur est alors obtenue. La figure 6.5 montre par exemple une trace simulée avec Verilator pendant le chiffrement AES. La trace simulée obtenue avec Verilator est plus précise qu'avec Spike car la micro-architecture du processeur est prise en compte, mais cette simulation est beaucoup plus lente.

<figure><img src="image_56.png" /><figcaption>FIGURE 6.5 – Trace de consommation simulée avec Verilator pendant le chiffrement AES.</figcaption></figure>

## 6.4.2 Analyse des traces simulées

Pour analyser la résistance de nos implémentations contre l'attaque SCA, nous avons réalisé des évaluations pratiques en utilisant des traces simulées.

**Évaluation de la fuite** Nous réalisons dans un premier temps une évaluation de la fuite d'information en utilisant la bibliothèque python SCALib<fnref n="7" />. Une évaluation pratique de la fuite peut être réalisée par un *t-test fixe contre aléatoire*, communément appelé TVLA [Coo+13; SM15]. Il s'agit d'une technique d'évaluation des fuites bien connue qui consiste à détecter si les fuites associées à deux groupes peuvent être distinguées. Un groupe contient les traces avec un message clair fixe et l'autre avec des messages clairs choisis au hasard, tandis qu'une clé constante et identique est utilisée dans les deux groupes. La figure 6.6 de gauche montre la valeur du t-test sur la première ronde de AES. On constate que des fuites sont détectées car le t-test dépasse une valeur seuil. Une autre solution pour détecter des fuites d'information est de calculer le *rapport signal sur bruit*, abrégé en SNR pour «*signal-to-noise ratio*» en anglais, entre les traces simulées et les valeurs intermédiaires. De manière informelle, le SNR permet de quantifier la quantité d'informations sur une variable aléatoire contenue dans la moyenne de la fuite. Un SNR élevé signifie que de l'information est détectée dans la moyenne de la fuite. La figure 6.6 de droite montre la valeur du SNR associée à chaque octet de la sortie de **SubBytes** de la première ronde de AES. Chaque pic de SNR indique qu'un octet a été détecté. L'évaluation de la fuite est une première étape pour analyser la sécurité d'une implémentation, mais n'est généralement pas suffisante pour affirmer sa résistance contre l'attaque SCA.

<footnote n="7">7. https://scalib.readthedocs.io/en/stable/</footnote>
<figure><img src="image_57.png" /><figcaption>FIGURE 6.6 – Évaluation de la fuite durant la première ronde de l’implémentation SW-BW de AES. La figure de gauche est le t-test, celle de droite le SNR.</figcaption></figure>

**Réalisation d'attaques SCA** Pour compléter l'évaluation de la sécurité d'une implémentation, nous réalisons des attaques SCA réputées de la littérature. Une première évaluation est effectuée en réalisant des attaques DPA, CPA et MIA avec la librairie python scared<fnref n="8" />. Par exemple, la figure 6.7 montre les résultats de la CPA ciblant le premier octet de la sortie de SubBytes de la première ronde de AES. La figure de gauche est le score du coefficient de Pearson pour chaque hypothèse sur le premier octet de la clé, et la figure de droite est la convergence du coefficient de Pearson en fonction du nombre de traces. On constate que la courbe correspondant à la valeur de clé correcte se détache dès 150 traces simulées.

<figure><img src="image_58.png" /><figcaption>FIGURE 6.7 – Résultats de l'attaque CPA ciblant le premier octet de la sortie de SubBytes de la première ronde de l'implémentation SW-BW de AES. La figure de gauche est le score du coefficient de Pearson, celle de droite la convergence du coefficient de Pearson.</figcaption></figure>

<footnote n="8">8. https://eshard.gitlab.io/scared/index.html</footnote>
Nous réalisons également des *attaques par modèle* [Guo+20] en utilisant à nouveau la librairie python SCALib. Un ensemble de traces simulées est généré pour réaliser un modèle de la consommation. Ensuite, l'attaque utilise ce modèle pour déterminer la clé secrète. La figure 6.8 montre les résultats de l'attaque par modèle appliquée à la sortie de **SubBytes** de la première ronde de l'implémentation AES SW-BW. La figure de gauche est le rang de la clé correcte, et la figure de droite est le taux de succès. L'attaque par modèle détermine la clé en seulement quelques traces.

<figure><img src="image_59.png" /><figcaption>FIGURE 6.8 – Résultats de l’attaque par modèle ciblant la sortie de **SubBytes** de la première ronde de l’implémentation SW-BW de AES. La figure de gauche est le rang de la clé correcte, celle de droite le taux de succès.</figcaption></figure>
<figure><img src="image_60.png" /></figure>