# Chapitre 7

## Extension masquée pour les implémentations «bit slicing»

Le masquage d'ordre élevé est nécessaire pour sécuriser les implémentations exécutées sur des processeurs à faible niveau de bruit. [BS21] ont par exemple réalisé une attaque sur des implémentations purement logicielles (sans ISE) de AES masquées jusqu'à l'ordre 5. Les implémentations «share slicing» (voir sous-section 4.2.5) ont été utilisées pour masquer efficacement à des ordres élevés, allant de l'ordre 3 et 7 dans [Gré+18] jusqu'à l'ordre 31 dans [JS17]. Cependant, [Gao+19] ont montré que les implémentations purement logicielles du «share slicing» pouvaient conduire à une recombinaison des parts liée à la micro-architecture des processeurs. Pour limiter les fuites liées à la micro-architecture des processeurs, un support matériel dédié peut être mis en place, comme par exemple une ISE dédiée au masquage. Plusieurs ISE dédiées au masquage ont été proposées dans la littérature (voir sous-section 5.4.2), mais elles ont été implémentées seulement pour de petits ordres de masquage ($d \le 4$). Dans ce chapitre, 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 nombreux cryptosystèmes. L'ISE1 supporte des ordres de masquage élevés, allant jusqu'à l'ordre 31. Une implémentation masquée à l'ordre $d$ utilisant les instructions de l'ISE1 est sécurisée contre un attaquant pouvant sonder $d$ bits dans le circuit pendant l'exécution de l'implémentation masquée. 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.

Dans la section 7.1, nous décrivons les nouvelles instructions de l'ISE1. La section 7.2 présente la mise en œuvre de l'ISE1 ainsi que son implantation dans le cœur CV32E40P. Dans la section 7.3, nous évaluons les performances et la surface de l'ISE1 sur FPGA.

### 7.1 Spécification de l'ISE1

Dans cette section, nous décrivons tout d'abord les nouvelles instructions masquées que nous proposons. Puis, nous définissons des propriétés de composition permettant d'assurer la sécurité de séquences d'instructions masquées.
7.1.1 Description des instructions

Une implémentation BS (voir sous-section 4.1.3) permet de chiffrer 32 blocs en clair en
parallèle. Le «share slicing» (voir sous-section 4.2.5) est une méthode de masquage des implé-
mentations BS consistant à placer toutes les parts d'un bit masqué dans un même mot mémoire.
Une implémentation «share slicing» masquée à l'ordre d permet alors de chiffrer 32/(d + 1)
blocs en clair en parallèle. Ce type d'implémentation permet de masquer efficacement à des
ordres élevés [Gré+18; JS17]. Cependant, comme toutes les parts sont dans un même mot
mémoire, [Gao+19] ont montré que la micro-architecture des processeurs pouvait produire une
recombinaison des parts. Nous proposons une ISE dédiée au masquage, nommée ISE1, pour
accélérer et sécuriser les implémentsations «share slicing». L'ISE1 est composée de 4 instruc-
tions masquées ise1.and, ise1.or, ise1.not et ise1.xor réalisant respectivement les portes
booléennes AND, OR, XOR et NOT masquées en respectant la représentation «share slicing».
Le code de la figure 7.1 décrit les 4 nouvelles instructions en langage Python. En représentation
«share slicing» d'ordre d, les registres sources reg[rs1] et reg[rs2] (du fichier de registres)
contiennent les masquages d'ordre d de 32/(d + 1) bits, chaque bit étant associé à un bloc
chiffré différent. Par exemple, en représentation «share slicing» d'ordre 3, un mot mémoire de
32 bits contient 8 masquages de 4 parts. Nos instructions masquées appliquent une porte boo-
léenne masquée à chaque masquage. mand, mxor et mnot désignent respectivement des circuits
masqués des portes booléennes AND, XOR, NOT sécurisés dans le modèle de sondage robuste
aux glitchs et/ou transitions. Pour terminer, le résultat de l'instruction masquée est écrit dans
le fichier de registres. La figure 7.2 illustre l'instruction masquée ise1.and.

def ise1.and(rs1, rs2, rd):
n=d+1
for i in range(32//n):
    reg[rd][i*n:(i+1)*n]=mand(reg[rs1][i*n:(i+1)*n],reg[rs2][i*n:(i+1)*n])

def ise1.xor(rs1, rs2, rd):
n=d+1
for i in range(32//n):
    reg[rd][i*n:(i+1)*n]=mxor(reg[rs1][i*n:(i+1)*n],reg[rs2][i*n:(i+1)*n])

def ise1.not(rs1, rs2, rd):
n=d+1
for i in range(32//n):
    reg[rd][i*n:(i+1)*n]=mnot(reg[rs1][i*n:(i+1)*n])

def ise1.or(rs1, rs2, rd):
n=d+1
for i in range(32//n):
    tmp1 = mnot(reg[rs1][i*n:(i+1)*n])
    tmp2 = mnot(reg[rs2][i*n:(i+1)*n])
    tmp3 = mand(tmp1, tmp2)
    reg[rd][i*n:(i+1)*n]=mnot(tmp3)

FIGURE 7.1 – Code Python décrivant les nouvelles instructions de l'ISE1 masquée à un ordre $d \in \{1, \dots, 31\}$. mand, mxor et mnot désignent respectivement des circuits masqués des portes booléennes AND, XOR, NOT. reg[x] désigne la valeur du registre d'indice x dans le banc de registres.
<figure><img src="image_61.png" /><figcaption>FIGURE 7.2 – Illustration de l'instruction `ise1.and` masquée à un ordre $d \in \{1, \dots, 31\}$. `mand` désigne un circuit masqué à l'ordre $d$ de la porte booléenne `AND`. `reg[x]` désigne la valeur du registre d'indice $x$ dans le banc de registres.</figcaption></figure>

### 7.1.2 Composition sécurisée d'instructions masquées

Pour assurer la sécurité de la composition de nos instructions masquées dans le modèle de sondage robuste aux glitchs et/ou transitions, leur implémentation doit être contrainte par des propriétés de sécurité plus fortes. Pour maintenir la sécurité de séquences d'instructions, la méthode utilisée dans les précédentes ISE de l'état de l'art consiste à contraindre les instructions linéaires à être $d$-NI et les instructions non-linéaires à être $d$-SNI dans le modèle de sondage robuste aux glitchs. Nous nommons cette méthode NI-SNI. Cependant, le programmeur doit alors appliquer des instructions de rafraîchissement à certains endroits bien choisis pour maintenir la sécurité de la composition (comme décrit à la sous-section 3.4.4). Pour composer simplement et de façon sécurisée les instructions de l'ISE1, nous proposons deux autres méthodes basées sur les propriétés de composition SNI et PINI.

**Instructions SNI** Pour assurer la sécurité d'une séquence d'instructions de l'ISE1, nous proposons de contraindre toutes les instructions masquées à être $d$-SNI dans le modèle de sondage robuste aux glitchs. Un programme utilisant uniquement les instructions de l'ISE1 est alors $d$-SNI, et donc sécurisé dans le modèle de sondage robuste aux glitchs. En effet, comme expliqué dans la sous-section 3.4.4, la composition d'implémentations masquées $d$-SNI est $d$-SNI. Cette méthode permet une composition simple et sécurisée des instructions de l'ISE1, mais impose un surcoût en temps d'exécution car les instructions linéaires doivent être $d$-SNI.

**Instructions PINI** Pour assurer la sécurité d'une séquence d'instructions de l'ISE1 tout en maintenant un masquage simple des instructions linéaires, nous proposons d'implémenter uniquement des instructions masquées $d$-PINI (resp. $d$-O-PINI). Un programme utilisant les instructions de l'ISE1 est alors $d$-PINI (resp. $d$-O-PINI) comme expliqué dans la sous-section 3.4.5, et donc sécurisé dans le modèle de sondage robuste aux glitchs (resp. aux glitchs et transitions). Les instructions PINI sont plus efficaces que les instructions SNI, car le masquage des instructions linéaires est simple. Les instructions PINI présentent également l'avantage de sécuriser contre les transitions de mémoire survenant durant des instructions *load/store* grâce à l'isolation des parts. En effet, les transitions survenant durant le remplacement de la valeur d'un registre n'apportent pas d'informations supplémentaires car les parts de même indice sont disposées à une même position dans un mot mémoire.
## 7.2 Implémentation de l'ISE1 sur le CV32E40P

Dans cette section, nous décrivons l'implémentation de l'ISE1 sur le cœur CV32E40P.

### 7.2.1 ALU masquée proposée

<figure><img src="image_62.png" /><figcaption>FIGURE 7.3 – Architecture de notre ALU masquée de l'ISE1.</figcaption></figure>

L'ALU masquée décrite dans la figure 7.3 a été développée pour implémenter nos nouvelles instructions. Différentes versions de l'ALU masquée ont été réalisées pour chaque propriété de composition présentée à la section 7.1. Le tableau 7.1 décrit les caractéristiques des instructions masquées pour chaque version de l'ISE1. Dans la version NI-SNI, la porte masquée mand est implémentée avec le AND masqué *d*-SNI de [Fau+18] alors que les portes masquées *mxor* et *mnot* sont implémentées de façon directe. La version SNI est similaire à la précédente, à la différence qu'un circuit de rafraîchissement *d*-SNI est ajouté pour rendre les instructions *ise1.xor* et *ise1.not d*-SNI. La latence de ces instructions est alors de 3 cycles au lieu de 1 pour la version NI-SNI. Pour les instructions PINI, nous implémentons 3 versions différentes utilisant les portes masquées HPC1, HPC2, et HPC3 pour mand. Ces 3 versions permettent d'obtenir différents compromis entre la latence de l'instruction, le nombre d'aléas nécessaires, et la surface de l'implémentation. Par rapport à la version HPC1, les instructions *ise1.and* et *ise1.or* nécessitent deux fois moins d'aléas dans la version HPC2 et un cycle de moins dans la version HPC3. Dans ces 3 versions, les portes masquées *mxor* et *mnot* sont implémentées de façon directe, permettant d'exécuter les instructions *ise1.not* et *ise1.xor* en seulement 1 cycle. Pour les instructions O-PINI, nous implémentons 2 versions différentes utilisant les portes masquées O-PINI2 et HPC3+ pour mand. La version HPC3+ met un cycle de moins pour exécuter les instructions *ise1.and* et *ise1.or*, mais utilise deux fois plus d'aléas par instruction. Dans toutes ces versions, la porte masquée *mor* est implémentée en utilisant la porte masquée *mand* où ses opérandes et son résultat passent par des portes masquées *mnot* conformément aux lois
de de Morgan. Un générateur de nombres pseudo-aléatoires, abrégé en PRNG pour «pseudo-random number generator» en anglais, fournit des valeurs aléatoires pour les portes masquées. Il utilise une seule ronde de la permutation Keccak comme spécifié dans [Ber+10]. Les paramètres de la permutation ont été minimisés de façon à fournir suffisamment de bits aléatoires à chaque cycle d'horloge. Le PRNG est régulièrement réinitialisé à l'aide d'un générateur de nombres aléatoires vrai, abrégé en TRNG pour «true random number generator» en anglais, qui se trouve en dehors du cœur. [Yan+18] donne un exemple de TRNG qui peut être implémenté en pratique. Une FSM contrôle les multiplexeurs internes de l'ALU masquée en fonction de l'opération décodée. La FSM contrôle également le pipeline pour les instructions multi-cycles.

<table><caption>TABLE 7.1 – Caractéristiques des instructions masquées pour chaque version de l'ISE1. m est égal à rnd(d/2). La latence est exprimée en nombre de cycles et les aléas en nombre de bits par instruction.</caption><thead><tr><th>Version ISE1</th><th>Paramètre</th><th>ise1.and/ise1.or</th><th>ise1.not/ise1.xor</th></tr></thead><tbody><tr><td rowspan="3">NI-SNI</td><td>Composition</td><td>SNI</td><td>NI</td></tr><tr><td>Latence</td><td>3</td><td>1</td></tr><tr><td>Aléas</td><td>m × <sup>d(d+1)</sup>⁄2</td><td>0</td></tr><tr><td rowspan="3">SNI</td><td>Composition</td><td>SNI</td><td>SNI</td></tr><tr><td>Latence</td><td>3</td><td>3</td></tr><tr><td>Aléas</td><td>m × <sup>d(d+1)</sup>⁄2</td><td>m × <sup>d(d+1)</sup>⁄2</td></tr><tr><td rowspan="3">HPC1</td><td>Composition</td><td>PINI</td><td>PINI</td></tr><tr><td>Latence</td><td>3</td><td>1</td></tr><tr><td>Aléas</td><td>m × d(d + 1)</td><td>0</td></tr><tr><td rowspan="3">HPC2</td><td>Composition</td><td>PINI</td><td>PINI</td></tr><tr><td>Latence</td><td>3</td><td>1</td></tr><tr><td>Aléas</td><td>m × <sup>d(d+1)</sup>⁄2</td><td>0</td></tr><tr><td rowspan="3">HPC3</td><td>Composition</td><td>PINI</td><td>PINI</td></tr><tr><td>Latence</td><td>2</td><td>1</td></tr><tr><td>Aléas</td><td>m × d(d + 1)</td><td>0</td></tr><tr><td rowspan="3">O-PINI2</td><td>Composition</td><td>O-PINI</td><td>O-PINI</td></tr><tr><td>Latence</td><td>4</td><td>1</td></tr><tr><td>Aléas</td><td>m × (<sup>d(d+1)</sup>⁄2 + d)</td><td>0</td></tr><tr><td rowspan="3">HPC3+</td><td>Composition</td><td>O-PINI</td><td>O-PINI</td></tr><tr><td>Latence</td><td>3</td><td>1</td></tr><tr><td>Aléas</td><td>m × (d(d + 1) + d)</td><td>0</td></tr></tbody></table>
### 7.2.2 Intégration dans le cœur CV32E40P

Le cœur CV32E40P ayant été conçu pour être modifié et étendu, l'intégration de l'ISE1 a été simple. Le cœur a été modifié comme illustré sur la figure 7.4. Le décodeur d'instructions modifié traite les nouvelles instructions et génère des signaux de contrôle pour les instructions multi-cycles. Pour éviter les problèmes de recombinaison des parts, nous avons conçu un chemin de données totalement séparé pour l'ALU masquée. En effet, [Gao+19] a montré que les calculs réalisés dans l'ALU de base peuvent engendrer une recombinaison des parts. La mise en place du chemin de données séparé nécessite d'étendre le registre de *pipeline* ID/EX avec 2 nouveaux registres 32 bits accessibles uniquement depuis l'ALU masquée. Selon l'instruction décodée, soit le chemin de données de masquage, soit le chemin de données normal est activé.

<figure><img src="image_63.png" /><figcaption>FIGURE 7.4 – Schéma simplifié du cœur modifié avec l'ISE1. Les parties rouges ont été ajoutées ou modifiées pour notre ISE.</figcaption></figure>

### 7.2.3 Utilisation logicielle de l'ISE

Notre ISE peut être utilisée pour masquer divers cryptosystèmes. Nous utilisons Usuba [MD19] pour générer une implémentation BS en langage C. Pour la version NI-SNI de l'ISE, nous utilisons Tornado pour maintenir la sécurité en rafraîchissant le masquage à certains endroits. Les opérations élémentaires dans le langage C sont remplacées par les intrinsèques assembleurs de nos instructions masquées. Les blocs d'entrées sont préalablement masqués puis convertis en représentation BS à l'aide de décalages, d'opérations logiques et de valeurs aléatoires. À la toute fin, les blocs de sortie sont reconvertis en représentation standard puis démasqués à l'aide de décalages et d'opérations logiques.

## 7.3 Évaluation des performances et coûts

La figure 7.5 présente le temps d'exécution du chiffrement AES masqué en utilisant la version HPC3 de l'ISE1 (labellisée par HW-M-ISE1), ainsi que différentes solutions de la littérature que nous avons réimplémenté sur le cœur CV32E40P (voir section 6.3). Bien que nous nous sommes
focalisé sur le chiffrement AES, notre solution est applicable à toutes sortes de cryptosystèmes. On constate que HW-M-ISE1 surpasse l'implémentation BS masquée en logiciel SW-M-BS. Par exemple, la version HPC3 de l'ISE1 accélère SW-M-BS de 4,7 à l'ordre 1, de 9,0 à l'ordre 3, de 13,6 à l'ordre 7, de 23,8 à l'ordre 15, de 25,0 à l'ordre 23 et de 42,5 à l'ordre 31. Plus l'ordre de masquage est élevé, plus les gains sont importants. Concernant les solutions matérielles, l'ISE1 est légèrement plus rapide que Skiva mais plus lente que SME. Cela s'explique car SME est optimisé pour le chiffrement AES, mais est moins efficace pour implémenter d'autres cryptosystèmes.

<figure><img src="image_64.png" /><figcaption>FIGURE 7.5 – Temps de chiffrement (en échelle log) de un bloc de AES avec la version HPC3 de l'ISE1 et diverses solutions de masquage logiciel et matériel.</figcaption></figure>

<figure><img src="image_65.png" /><figcaption>FIGURE 7.6 – Surface et fréquence maximale du cœur CV32E40P (CORE) sans ISE, avec Skiva (CORE+SKIVA), avec SME (CORE+SME) et avec la version HPC3 de l'ISE1 (CORE+ISE1).</figcaption></figure>
La figure 7.6 présente la surface et la fréquence maximale du cœur CV32E40P (CORE) sans ISE, avec Skiva (CORE+SKIVA), avec SME (CORE+SME) et avec la version HPC3 de l'ISE1 (CORE+ISE1), pour des ordres de masquage *d* dans {1, 2, 3, ... 31}. Notre solution a un impact limité en surface, même pour des ordres de masquage élevés. Par exemple, le nombre de FF est augmenté par 1,13 à l'ordre 1, par 1,21 à l'ordre 3, par 1,47 à l'ordre 7, par 1,90 à l'ordre 15 et par 2,75 à l'ordre 31. L'ISE1 a une surface légèrement plus grande que Skiva à l'ordre 1 et 3, mais elle est plus rapide en temps de chiffrement. L'ISE1 masquée aux ordres 1, 2 et 3 est bien plus petite que SME. Bien que SME soit plus rapide en termes de temps d'exécution, cette ISE impose un coût important en termes de surface et il semble que SME ne puisse pas être implantée dans des petits FPGA pour des ordres de masquage élevés. De plus, l'ISE1 n'impacte pas la fréquence maximale du cœur CV32E40P (le chemin critique n'est pas dans l'ISE), contrairement à SME.

**Comparaison des différentes versions de l'ISE** Le tableau 7.2 présente les résultats d'implantation des différentes versions de l'ISE1 masquée aux ordres $d \in \{1, 3, 7, 15, 31\}$. La version NI-SNI est la plus petite et est assez efficace en termes de temps de chiffrement. Par contre, cette version est plus complexe à utiliser car l'utilisateur doit insérer des instructions de rafraîchissement dans le code pour maintenir la sécurité de la composition. La version SNI permet de composer directement les instructions masquées de façon sécurisée. Bien que le coût matériel reste faible, cette version est la moins efficace en termes de temps de chiffrement. Cette moindre efficacité s'explique par le fait que l'instruction `ise1.xor` s'exécute en 3 cycles d'horloge. Une autre solution pour composer directement les instructions masquées de façon sécurisée est d'utiliser des instructions PINI. On constate que la version HPC2 consomme plus de surface que HPC1 même si HPC1 utilise plus d'aléas par instruction. HPC3 est la version la plus efficace en temps de chiffrement, mais induit un léger surcoût en surface par rapport à HPC1. Concernant les versions O-PINI de l'ISE1, la version HPC3$^+$ est plus performante en temps de chiffrement et a une surface plus faible que la version O-PINI2. En résumé, la version NI-SNI induit le plus faible coût en matériel, mais est plus complexe à utiliser. La version HPC3 est la plus rapide en temps de chiffrement et est simple d'utilisation. La version HPC3$^+$ est la plus efficace pour protéger contre les glitches et les transitions simultanément.
<table><caption>TABLE 7.2 – Résultats d'implantation de l'ISE1 masquée au ordres $d \in \{1, 2, 3, 7, 15, 31\}$. 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. Les nombres de FF et LUT sont donnés en surcoût par rapport à ceux du cœur CV32E40P de base.</caption><thead><tr><th rowspan="2">d</th><th rowspan="2">Implém.</th><th rowspan="2">Version ISE1</th><th colspan="3">Temps</th><th colspan="3">Surface & période</th></tr><tr><th>Cycles</th><th>cmp1</th><th>cmp2</th><th>FF</th><th>LUT</th><th>P(ns)</th></tr></thead><tbody><tr><td>0</td><td>SW-TTABLE</td><td>Sans ISE</td><td>1266</td><td>base</td><td>n.a.</td><td>base</td><td>base</td><td>14.6</td></tr><tr><td rowspan="7">1</td><td rowspan="7">SW-M-BS<br>HW-M-ISE1</td><td>Sans ISE</td><td>26001</td><td>×21</td><td>base</td><td>×1,00</td><td>×1,00</td><td>14.6</td></tr><tr><td>NI-SNI</td><td>5803</td><td>×4,6</td><td>/4,5</td><td>×1,10</td><td>×1,02</td><td>14.9</td></tr><tr><td>SNI</td><td>8309</td><td>×6,6</td><td>/3,1</td><td>×1,14</td><td>×1,00</td><td>14.4</td></tr><tr><td>HPC1</td><td>5803</td><td>×4,6</td><td>/4,5</td><td>×1,14</td><td>×1,02</td><td>14.9</td></tr><tr><td>HPC2</td><td>5803</td><td>×4,6</td><td>/4,5</td><td>×1,16</td><td>×1,00</td><td>14.4</td></tr><tr><td>HPC3</td><td>5483</td><td>×4,3</td><td>/4,7</td><td>×1,13</td><td>×1,00</td><td>14.4</td></tr><tr><td>O-PINI2</td><td>6123</td><td>×4,8</td><td>/4,2</td><td>×1,19</td><td>×1,01</td><td>14.9</td></tr><tr><td></td><td></td><td>HPC3<sup>+</sup></td><td>5803</td><td>×4,6</td><td>/4,5</td><td>×1,17</td><td>×1,02</td><td>14.9</td></tr><tr><td rowspan="7">3</td><td rowspan="7">SW-M-BS<br>HW-M-ISE1</td><td>Sans ISE</td><td>98575</td><td>×78</td><td>base</td><td>×1,00</td><td>×1,00</td><td>14.6</td></tr><tr><td>NI-SNI</td><td>11567</td><td>×9,1</td><td>/8,5</td><td>×1,14</td><td>×1,03</td><td>14.9</td></tr><tr><td>SNI</td><td>16579</td><td>×13,1</td><td>/5,9</td><td>×1,19</td><td>×1,01</td><td>14.4</td></tr><tr><td>HPC1</td><td>11567</td><td>×9,1</td><td>/8,5</td><td>×1,22</td><td>×1,03</td><td>14.9</td></tr><tr><td>HPC2</td><td>11567</td><td>×9,1</td><td>/8,5</td><td>×1,29</td><td>×1,05</td><td>14.9</td></tr><tr><td>HPC3</td><td>10927</td><td>×8,6</td><td>/9,0</td><td>×1,21</td><td>×1,04</td><td>14.9</td></tr><tr><td>O-PINI2</td><td>12207</td><td>×9,6</td><td>/8,1</td><td>×1,34</td><td>×1,06</td><td>14.9</td></tr><tr><td></td><td></td><td>HPC3<sup>+</sup></td><td>11567</td><td>×9,1</td><td>/8,5</td><td>×1,29</td><td>×1,07</td><td>14.9</td></tr><tr><td rowspan="7">7</td><td rowspan="7">SW-M-BS<br>HW-M-ISE1</td><td>Sans ISE</td><td>300414</td><td>×237</td><td>base</td><td>×1,00</td><td>×1,00</td><td>14.6</td></tr><tr><td>NI-SNI</td><td>23313</td><td>×18,4</td><td>/12,9</td><td>×1,27</td><td>×1,07</td><td>14.9</td></tr><tr><td>SNI</td><td>33337</td><td>×26,3</td><td>/9,0</td><td>×1,35</td><td>×1,08</td><td>14.4</td></tr><tr><td>HPC1</td><td>23313</td><td>×18,4</td><td>/12,9</td><td>×1,45</td><td>×1,15</td><td>14.9</td></tr><tr><td>HPC2</td><td>23313</td><td>×18,4</td><td>/12,9</td><td>×1,60</td><td>×1,15</td><td>14.9</td></tr><tr><td>HPC3</td><td>22033</td><td>×17,4</td><td>/13,6</td><td>×1,47</td><td>×1,17</td><td>14.9</td></tr><tr><td>O-PINI2</td><td>24593</td><td>×19,4</td><td>/12,2</td><td>×1,63</td><td>×1,15</td><td>14.9</td></tr><tr><td></td><td></td><td>HPC3<sup>+</sup></td><td>23313</td><td>×18,4</td><td>/12,9</td><td>×1,50</td><td>×1,18</td><td>14.9</td></tr><tr><td rowspan="7">15</td><td rowspan="7">SW-M-BS<br>HW-M-ISE1</td><td>Sans ISE</td><td>1041285</td><td>×822</td><td>base</td><td>×1,00</td><td>×1,00</td><td>14.6</td></tr><tr><td>NI-SNI</td><td>46237</td><td>×36,5</td><td>/22,5</td><td>×1,48</td><td>×1,17</td><td>14.9</td></tr><tr><td>SNI</td><td>66285</td><td>×52,4</td><td>/15,7</td><td>×1,63</td><td>×1,18</td><td>14.4</td></tr><tr><td>HPC1</td><td>46237</td><td>×36,5</td><td>/22,5</td><td>×1,81</td><td>×1,31</td><td>14.7</td></tr><tr><td>HPC2</td><td>46237</td><td>×36,5</td><td>/22,5</td><td>×2,17</td><td>×1,34</td><td>14.9</td></tr><tr><td>HPC3</td><td>43677</td><td>×34,5</td><td>/23,8</td><td>×1,90</td><td>×1,40</td><td>14.7</td></tr><tr><td>O-PINI2</td><td>48797</td><td>×38,5</td><td>/21,3</td><td>×2,20</td><td>×1,34</td><td>14.9</td></tr><tr><td></td><td></td><td>HPC3<sup>+</sup></td><td>46237</td><td>×36,5</td><td>/22,5</td><td>×1,93</td><td>×1,38</td><td>14.9</td></tr><tr><td rowspan="7">31</td><td rowspan="7">SW-M-BS<br>HW-M-ISE1</td><td>Sans ISE</td><td>3716920</td><td>×2936</td><td>base</td><td>×1,00</td><td>×1,00</td><td>14.6</td></tr><tr><td>NI-SNI</td><td>92609</td><td>×73,2</td><td>/40,1</td><td>×1,91</td><td>×1,36</td><td>14.9</td></tr><tr><td>SNI</td><td>132705</td><td>×104,8</td><td>/28,0</td><td>×2,17</td><td>×1,41</td><td>14.4</td></tr><tr><td>HPC1</td><td>92609</td><td>×73,2</td><td>/40,1</td><td>×2,55</td><td>×1,67</td><td>14.6</td></tr><tr><td>HPC2</td><td>92609</td><td>×73,2</td><td>/40,1</td><td>×3,32</td><td>×1,74</td><td>14.6</td></tr><tr><td>HPC3</td><td>87489</td><td>×69,1</td><td>/42,5</td><td>×2,75</td><td>×1,81</td><td>14.3</td></tr><tr><td>O-PINI2</td><td>97729</td><td>×77,2</td><td>/38,0</td><td>×3,35</td><td>×1,74</td><td>14.6</td></tr><tr><td></td><td></td><td>HPC3<sup>+</sup></td><td>92609</td><td>×73,2</td><td>/40,1</td><td>×2,78</td><td>×1,83</td><td>14.3</td></tr></tbody></table>
<figure><img src="image_66.png" /></figure>
# Chapitre 8

## Extension masquée pour les implémentations *m*-slicing

L'ISE1 que nous avons présenté au chapitre 7 permet d'accélérer les implémentations masquées à des ordres élevés de divers cryptosystèmes en ayant un impact limité en surface. Néanmoins, lorsqu'on implémente un cryptosystème avec l'ISE1, $32/(d+1)$ blocs indépendants doivent être chiffrés en parallèle pour obtenir les meilleures performances. Par exemple, 16 blocs indépendants sont chiffrés en parallèle avec l'ISE1 masquée à l'ordre 1. Seule l'ISE1 masquée à un ordre supérieur à 16 permet de chiffrer un seul bloc à la fois. Le chiffrement de nombreux blocs en parallèle induit un coût lié à la gestion des différents blocs et augmente la pression sur les registres généraux du processeur. Cela limite également les modes de chiffrement utilisables à ceux permettant le chiffrement parallèle de différents blocs, tel que le mode CTR (voir sous-section 1.1.3). Les modes CBC, CFB et OFB peuvent être utilisés seulement pour chiffrer des flux de données complètement indépendants. Mais cette situation se produit rarement dans des systèmes embarquées où les flux de données sont plus faibles. Dans ce chapitre, nous proposons une nouvelle ISE dédiée au masquage, que nous nommons ISE2, qui étend l'ISE1 avec d'autres instructions pour masquer des implémentations *m*-slicing aux ordres $d \in \{1, 3, 7, 15\}$. L'ordre de masquage de l'ISE est fixé au moment de la synthèse. En masquant les implémentations 16-slicing, 8-slicing, 4-slicing et 2-slicing avec l'ISE2 masquée respectivement aux ordres 1, 3, 7, 15, nous obtenons des implémentations permettant de masquer efficacement un bloc à la fois. L'utilisation de tous les modes de chiffrement devient alors possible.

Dans la section 8.1, nous décrivons les nouvelles instructions de l'ISE2. La section 8.2 décrit 4 implémentations *m*-slicing de AES qui sont masquées avec l'ISE2. Deux de ces implémentations sont nouvelles. Dans la section 8.3, nous évaluons les performances et la surface de l'ISE2.

### 8.1 Spécification de l'ISE2

Une implémentation *m*-slicing (voir sous-section 4.1.4) permet de chiffrer $32/m$ blocs en clair en parallèle. En masquant une implémentation *m*-slicing à l'ordre *d* en utilisant la méthode du «*share slicing*» (voir sous-section 4.2.5), on réduit à $32/(m \times (d+1))$ le nombre de blocs en clair chiffrés en parallèle. Ainsi, une implémentation 16-slicing masquée à l'ordre 1 chiffre un seul bloc en utilisant le «*share slicing*». De même, en masquant respectivement les implémentations 8-slicing, 4-slicing et 2-slicing aux ordres 3, 7, et 15 avec le «*share slicing*», nous obtenons des implémentations permettant de chiffrer un bloc à la fois. Une implémentation *m*-slicing
utilise des instructions booléennes, mais également des instructions de décalage pour calculer sur les *m* bits d'un bloc présent dans un mot machine. Pour accélérer les implémentations *m-slicing* masquées aux ordres $d \in \{1, 3, 7, 15\}$ avec le «share slicing», nous avons donc ajouté des instructions masquées à l'ISE1. Les nouvelles instructions sont présentées dans la figure 8.1 et implémentent le décalage à droite et à gauche adapté à la représentation «share slicing».

def ise2.sll(rs1, rs2, rd):
    shift = int("".join(str(x) for x in reg[rs2][0:4]), 2)
    reg[rd][0:32-(d+1)*shift]=reg[rs1][(d+1)*shift:32]
    reg[rd][32-(d+1)*shift:32]=(d+1)*shift*[0]

def ise2.srl(rs1, rs2, rd):
    shift = int("".join(str(x) for x in reg[rs2][0:4]), 2)
    reg[rd][0:(d+1)*shift]=(d+1)*shift*[0]
    reg[rd][(d+1)*shift:32]=reg[rs1][0:32-(d+1)*shift]

def ise2.slli(rs1, imm, rd):
    shift = int("".join(str(x) for x in imm[0:4]), 2)
    reg[rd][0:32-(d+1)*shift]=reg[rs1][(d+1)*shift:32]
    reg[rd][32-(d+1)*shift:32]=(d+1)*shift*[0]

def ise2.srli(rs1, imm, rd):
    shift = int("".join(str(x) for x in imm[0:4]), 2)
    reg[rd][0:(d+1)*shift]=(d+1)*shift*[0]
    reg[rd][(d+1)*shift:32]=reg[rs1][0:32-(d+1)*shift]

FIGURE 8.1 – Code Python décrivant les nouvelles instructions de l'ISE2. reg[x] désigne la valeur du registre d'indice x dans le banc de registres.

## 8.2 Nouvelles implémentations *m*-slicing de AES

Nous avons développé des implémentations 16-slicing, 8-slicing, 4-slicing et 2-slicing de AES en utilisant Usuba (voir sous-section 4.1.3). Deux de ces implémentations sont nouvelles. En utilisant la méthode du «share slicing», ces implémentations de AES permettent de masquer un bloc à la fois avec l'ISE2 respectivement aux ordres 1, 3, 7, 15.

### 8.2.1 Implémentation 16-slicing de AES

<table><thead><tr><th rowspan="3"></th><th colspan="8">ligne 3</th><th colspan="8">ligne 0</th></tr><tr><th colspan="2">colonne 0</th><th colspan="2">colonne 1</th><th colspan="2">colonne 2</th><th colspan="2">colonne 3</th><th colspan="2">colonne 0</th><th colspan="2">colonne 1</th><th colspan="2">colonne 2</th><th colspan="2">colonne 3</th></tr><tr><th>0</th><th>1</th><th>0</th><th>1</th><th>0</th><th>1</th><th>0</th><th>1</th><th>0</th><th>1</th><th>0</th><th>1</th><th>0</th><th>1</th><th>0</th><th>1</th></tr></thead><tbody><tr><th>M<sub>0</sub></th><td>b<sup>0</sup><sub>24</sub></td><td>b<sup>1</sup><sub>24</sub></td><td>b<sup>0</sup><sub>56</sub></td><td>b<sup>1</sup><sub>56</sub></td><td>b<sup>0</sup><sub>88</sub></td><td>b<sup>1</sup><sub>88</sub></td><td>b<sup>0</sup><sub>120</sub></td><td>b<sup>1</sup><sub>120</sub></td><td>...</td><td>b<sup>0</sup><sub>0</sub></td><td>b<sup>1</sup><sub>0</sub></td><td>b<sup>0</sup><sub>32</sub></td><td>b<sup>1</sup><sub>32</sub></td><td>b<sup>0</sup><sub>64</sub></td><td>b<sup>1</sup><sub>64</sub></td><td>b<sup>0</sup><sub>96</sub></td><td>b<sup>1</sup><sub>96</sub></td></tr><tr><th>...</th><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><th>M<sub>7</sub></th><td>b<sup>0</sup><sub>31</sub></td><td>b<sup>1</sup><sub>31</sub></td><td>b<sup>0</sup><sub>63</sub></td><td>b<sup>1</sup><sub>63</sub></td><td>b<sup>0</sup><sub>95</sub></td><td>b<sup>1</sup><sub>95</sub></td><td>b<sup>0</sup><sub>127</sub></td><td>b<sup>1</sup><sub>127</sub></td><td>...</td><td>b<sup>0</sup><sub>7</sub></td><td>b<sup>1</sup><sub>7</sub></td><td>b<sup>0</sup><sub>39</sub></td><td>b<sup>1</sup><sub>39</sub></td><td>b<sup>0</sup><sub>71</sub></td><td>b<sup>1</sup><sub>71</sub></td><td>b<sup>0</sup><sub>103</sub></td><td>b<sup>1</sup><sub>103</sub></td></tr></tbody></table>

FIGURE 8.2 – Notre représentation 16-slicing de 2 blocs dans 8 mots machines ($M_i, 0 \le i \le 7$) d'une architecture 32 bits. $b_i^j$ désigne le $i$-ième bit du $j$-ième bloc.
Nous avons réimplémenté en utilisant Usuba l'implémentation 16-slicing de AES proposée dans [SS16] pour un processeur ARM Cortex-M3, puis portée sur une architecture RISC-V 32 bits dans [Sto19]. Cette implémentation permet de chiffrer en parallèle 2 blocs en clair en les disposant dans 8 mots machines comme illustré dans la figure 8.2. En masquant cette implémentation à l'ordre 1 avec le « share slicing », on peut alors chiffrer un seul bloc. Le code Usuba de cette implémentation se trouve dans la figure B.1 de l'annexe B. La sous-fonction MixColumns peut être calculée efficacement avec des instructions booléennes et de décalage. En effet, la multiplication par 2 est réalisée par un décalage vers la gauche et un masquage conditionnel avec $(00011011)_2$ chaque fois que le bit de poids fort (MSB) vaut 1. Puisque $M_0$ contient le MSB de chaque octet, il suffit de l'ajouter aux quatre registres correspondants. De plus, comme les bits d'un bloc sont rangés par ligne puis colonne, l'ajout d'une ligne de l'état de AES à une autre se réalise simplement par une rotation et un XOR. MixColumns peut ainsi être réalisé de la manière suivante :

$$M'_{0} = (M_{1} \oplus M_{1}^{\gg 8}) \oplus M_{0}^{\gg 8} \oplus (M_{0} \oplus M_{0}^{\gg 8})^{\gg 16}$$

$$M'_{1} = (M_{2} \oplus M_{2}^{\gg 8}) \oplus M_{1}^{\gg 8} \oplus (M_{1} \oplus M_{1}^{\gg 8})^{\gg 16}$$

$$M'_{2} = (M_{3} \oplus M_{3}^{\gg 8}) \oplus M_{2}^{\gg 8} \oplus (M_{2} \oplus M_{2}^{\gg 8})^{\gg 16}$$

$$M'_{3} = (M_{4} \oplus M_{4}^{\gg 8}) \oplus M_{3}^{\gg 8} \oplus (M_{3} \oplus M_{3}^{\gg 8})^{\gg 16} \oplus (M_{0} \oplus M_{0}^{\gg 8})$$

$$M'_{4} = (M_{5} \oplus M_{5}^{\gg 8}) \oplus M_{4}^{\gg 8} \oplus (M_{4} \oplus M_{4}^{\gg 8})^{\gg 16} \oplus (M_{0} \oplus M_{0}^{\gg 8})$$

$$M'_{5} = (M_{6} \oplus M_{6}^{\gg 8}) \oplus M_{5}^{\gg 8} \oplus (M_{5} \oplus M_{5}^{\gg 8})^{\gg 16}$$

$$M'_{6} = (M_{7} \oplus M_{7}^{\gg 8}) \oplus M_{6}^{\gg 8} \oplus (M_{6} \oplus M_{6}^{\gg 8})^{\gg 16} \oplus (M_{0} \oplus M_{0}^{\gg 8})$$

$$M'_{7} = (M_{0} \oplus M_{0}^{\gg 8}) \oplus M_{7}^{\gg 8} \oplus (M_{7} \oplus M_{7}^{\gg 8})^{\gg 16}$$

### 8.2.2 Implémentation 8-slicing de AES

<figure><img src="image_67.png" /><figcaption>FIGURE 8.3 – Notre représentation 8-slicing de 4 blocs dans 16 mots machines ($M_i, 0 \le i \le 15$) d'une architecture 32 bits. $b_i^j$ désigne le $i$-ième bit du $j$-ième bloc.</figcaption></figure>
Nous avons développé une nouvelle implémentation 8-slicing de AES en utilisant Usuba. Cette implémentation permet de chiffrer en parallèle 4 blocs en clair en les disposant dans 16 mots machines comme illustré dans la figure 8.3. Cette implémentation masquée à l'ordre 1 ou 3 avec le « share slicing » permet de chiffrer respectivement 2 ou 1 blocs en parallèle. Le code Usuba de cette implémentation se trouve dans la figure B.2 de l'annexe B. La sous-fonction MixColumns peut être calculée efficacement avec des instructions booléennes et de décalage de la manière suivante :

$$
\begin{align*}
M'_0 &= M_1 \oplus M_9 \oplus M_8 \oplus (M_0 \oplus M_8) \gg^{16} \\
M'_1 &= M_2 \oplus M_{10} \oplus M_9 \oplus (M_1 \oplus M_9) \gg^{16} \\
M'_2 &= M_3 \oplus M_{11} \oplus M_{10} \oplus (M_2 \oplus M_{10}) \gg^{16} \\
M'_3 &= M_4 \oplus M_{12} \oplus M_{11} \oplus (M_3 \oplus M_{11}) \gg^{16} \oplus (M_0 \oplus M_8) \\
M'_4 &= M_5 \oplus M_{13} \oplus M_{12} \oplus (M_4 \oplus M_{12}) \gg^{16} \oplus (M_0 \oplus M_8) \\
M'_5 &= M_6 \oplus M_{14} \oplus M_{13} \oplus (M_5 \oplus M_{13}) \gg^{16} \\
M'_6 &= M_7 \oplus M_{15} \oplus M_{14} \oplus (M_6 \oplus M_{14}) \gg^{16} \oplus (M_0 \oplus M_8) \\
M'_7 &= M_0 \oplus M_8 \oplus M_{15} \oplus (M_7 \oplus M_{15}) \gg^{16} \\
M'_8 &= M_9 \oplus (M_1 \oplus M_0 \oplus M_8) \gg^{16} \oplus M_0 \\
M'_9 &= M_{10} \oplus (M_2 \oplus M_1 \oplus M_9) \gg^{16} \oplus M_1 \\
M'_{10} &= M_{11} \oplus (M_3 \oplus M_2 \oplus M_{10}) \gg^{16} \oplus M_2 \\
M'_{11} &= M_{12} \oplus (M_4 \oplus M_3 \oplus M_{11}) \gg^{16} \oplus M_3 \oplus (M_8 \oplus M_0 \gg^{16}) \\
M'_{12} &= M_{13} \oplus (M_5 \oplus M_4 \oplus M_{12}) \gg^{16} \oplus M_4 \oplus (M_8 \oplus M_0 \gg^{16}) \\
M'_{13} &= M_{14} \oplus (M_6 \oplus M_5 \oplus M_{13}) \gg^{16} \oplus M_5 \\
M'_{14} &= M_{15} \oplus (M_7 \oplus M_6 \oplus M_{14}) \gg^{16} \oplus M_6 \oplus (M_8 \oplus M_0 \gg^{16}) \\
M'_{15} &= M_8 \oplus (M_0 \oplus M_7 \oplus M_{15}) \gg^{16} \oplus M_7
\end{align*}
$$

### 8.2.3 Implémentation 4-slicing de AES

Nous avons réimplémenté en utilisant Usuba l'implémentation 4-slicing de AES proposée dans [AP20]. Cette implémentation permet de chiffrer en parallèle 8 blocs en clair en les disposant dans 32 mots machines comme illustré dans la figure 8.4. Cette implémentation masquée à l'ordre 1, 3 ou 7 avec le « share slicing » permet de chiffrer respectivement 4, 2 ou 1 blocs en parallèle. Le code Usuba de cette implémentation se trouve dans la figure B.3 de l'annexe B. Cette représentation permet de calculer efficacement ShiftRows car les lignes de l'état sont isolées dans des registres distincts. MixColumns ne nécessite plus de rotation mais uniquement des XOR puisque les différents octets au sein d'une colonne sont désormais stockés dans des registres distincts. MixColumns peut être calculée de la manière suivante :
$$M'_{i} = M_{i+1} \oplus M_{i+9} \oplus M_{i+8} \oplus M_{i+16} \oplus M_{i+24}$$

$$M'_{i+1} = M_{i+2} \oplus M_{i+10} \oplus M_{i+9} \oplus M_{i+17} \oplus M_{i+25}$$

$$M'_{i+2} = M_{i+3} \oplus M_{i+11} \oplus M_{i+10} \oplus M_{i+18} \oplus M_{i+26}$$

$$M'_{i+3} = M_{i+4} \oplus M_{i+12} \oplus M_{i+11} \oplus M_{i+19} \oplus M_{i+27} \oplus (M_{i} \oplus M_{i+8})$$

$$M'_{i+4} = M_{i+5} \oplus M_{i+13} \oplus M_{i+12} \oplus M_{i+20} \oplus M_{i+28} \oplus (M_{i} \oplus M_{i+8})$$

$$M'_{i+5} = M_{i+6} \oplus M_{i+14} \oplus M_{i+13} \oplus M_{i+21} \oplus M_{i+29}$$

$$M'_{i+6} = M_{i+7} \oplus M_{i+15} \oplus M_{i+14} \oplus M_{i+22} \oplus M_{i+30} \oplus (M_{i} \oplus M_{i+8})$$

$$M'_{i+7} = M_{i} \oplus M_{i+8} \oplus M_{i+15} \oplus M_{i+23} \oplus M_{i+31}$$

pour $i \in \{0, 8, 16, 24\}$ et où tous les indices doivent être considérés modulo 32.

<figure><img src="image_68.png" /><figcaption>FIGURE 8.4 – Notre représentation 4-slicing de 8 blocs dans 32 mots machines ($M_i, 0 \le i \le 31$) d'une architecture 32 bits. $b_i^j$ désigne le $i$-ième bit du $j$-ième bloc.</figcaption></figure>

### 8.2.4 Implémentation 2-slicing de AES

Nous avons développé une nouvelle implémentation 2-slicing de AES en utilisant Usuba. Cette implémentation permet de chiffrer en parallèle 16 blocs en clair en les disposant dans 64 mots machines comme illustré dans la figure 8.5. Cette implémentation masquée à l'ordre 1, 3, 7 ou 15 avec le « share slicing » permet de chiffrer respectivement 8, 4, 2 ou 1 blocs en parallèle. Le code Usuba de cette implémentation se trouve dans la figure B.4 de l'annexe B. La sous-fonction MixColumns peut être calculée efficacement avec des instructions booléennes et de décalage de la manière suivante :
$$M'_{i} = M_{i+1} \oplus M_{i+17} \oplus M_{i+16} \oplus M_{i+32} \oplus M_{i+48}$$

$$M'_{i+1} = M_{i+2} \oplus M_{i+18} \oplus M_{i+17} \oplus M_{i+33} \oplus M_{i+49}$$

$$M'_{i+2} = M_{i+3} \oplus M_{i+19} \oplus M_{i+18} \oplus M_{i+34} \oplus M_{i+50}$$

$$M'_{i+3} = M_{i+4} \oplus M_{i+20} \oplus M_{i+19} \oplus M_{i+35} \oplus M_{i+51} \oplus (M_{i} \oplus M_{i+16})$$

$$M'_{i+4} = M_{i+5} \oplus M_{i+21} \oplus M_{i+20} \oplus M_{i+36} \oplus M_{i+52} \oplus (M_{i} \oplus M_{i+16})$$

$$M'_{i+5} = M_{i+6} \oplus M_{i+22} \oplus M_{i+21} \oplus M_{i+37} \oplus M_{i+53}$$

$$M'_{i+6} = M_{i+7} \oplus M_{i+23} \oplus M_{i+22} \oplus M_{i+38} \oplus M_{i+54} \oplus (M_{i} \oplus M_{i+16})$$

$$M'_{i+7} = M_{i} \oplus M_{i+16} \oplus M_{i+23} \oplus M_{i+39} \oplus M_{i+55}$$

pour $i \in \{0, 8, 16, 24, 32, 40, 48, 56\}$ et où tous les indices doivent être considérés modulo 64.

<table><thead><tr><th></th><th colspan="6">ligne 0</th></tr><tr><th></th><th colspan="3">colonne 0</th><th colspan="3">colonne 2</th></tr><tr><th></th><th>bloc 0</th><th>...</th><th>bloc 15</th><th>bloc 0</th><th>...</th><th>bloc 15</th></tr></thead><tbody><tr><th>M<sub>0</sub></th><td>b<sup>0</sup><sub>0</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>64</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr><tr><th>...</th><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><th>M<sub>7</sub></th><td>b<sup>0</sup><sub>7</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>71</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr></tbody></table>

<table><thead><tr><th></th><th colspan="6">ligne 0</th></tr><tr><th></th><th colspan="3">colonne 1</th><th colspan="3">colonne 3</th></tr><tr><th></th><th>bloc 0</th><th>...</th><th>bloc 15</th><th>bloc 0</th><th>...</th><th>bloc 15</th></tr></thead><tbody><tr><th>M<sub>8</sub></th><td>b<sup>0</sup><sub>32</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>96</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr><tr><th>...</th><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><th>M<sub>15</sub></th><td>b<sup>0</sup><sub>39</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>103</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr></tbody></table>

<table><thead><tr><th></th><th colspan="6">ligne 1</th></tr><tr><th></th><th colspan="3">colonne 0</th><th colspan="3">colonne 2</th></tr><tr><th></th><th>bloc 0</th><th>...</th><th>bloc 15</th><th>bloc 0</th><th>...</th><th>bloc 15</th></tr></thead><tbody><tr><th>M<sub>16</sub></th><td>b<sup>0</sup><sub>8</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>72</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr><tr><th>...</th><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><th>M<sub>23</sub></th><td>b<sup>0</sup><sub>15</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>79</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr></tbody></table>

<table><thead><tr><th></th><th colspan="6">ligne 1</th></tr><tr><th></th><th colspan="3">colonne 1</th><th colspan="3">colonne 3</th></tr><tr><th></th><th>bloc 0</th><th>...</th><th>bloc 15</th><th>bloc 0</th><th>...</th><th>bloc 15</th></tr></thead><tbody><tr><th>M<sub>24</sub></th><td>b<sup>0</sup><sub>40</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>104</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr><tr><th>...</th><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><th>M<sub>31</sub></th><td>b<sup>0</sup><sub>47</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>111</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr></tbody></table>

<table><thead><tr><th></th><th colspan="6">ligne 2</th></tr><tr><th></th><th colspan="3">colonne 0</th><th colspan="3">colonne 2</th></tr><tr><th></th><th>bloc 0</th><th>...</th><th>bloc 15</th><th>bloc 0</th><th>...</th><th>bloc 15</th></tr></thead><tbody><tr><th>M<sub>32</sub></th><td>b<sup>0</sup><sub>16</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>80</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr><tr><th>...</th><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><th>M<sub>39</sub></th><td>b<sup>0</sup><sub>23</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>87</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr></tbody></table>

<table><thead><tr><th></th><th colspan="6">ligne 2</th></tr><tr><th></th><th colspan="3">colonne 1</th><th colspan="3">colonne 3</th></tr><tr><th></th><th>bloc 0</th><th>...</th><th>bloc 15</th><th>bloc 0</th><th>...</th><th>bloc 15</th></tr></thead><tbody><tr><th>M<sub>40</sub></th><td>b<sup>0</sup><sub>48</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>112</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr><tr><th>...</th><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><th>M<sub>47</sub></th><td>b<sup>0</sup><sub>55</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>119</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr></tbody></table>

<table><thead><tr><th></th><th colspan="6">ligne 3</th></tr><tr><th></th><th colspan="3">colonne 0</th><th colspan="3">colonne 2</th></tr><tr><th></th><th>bloc 0</th><th>...</th><th>bloc 15</th><th>bloc 0</th><th>...</th><th>bloc 15</th></tr></thead><tbody><tr><th>M<sub>48</sub></th><td>b<sup>0</sup><sub>24</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>88</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr><tr><th>...</th><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><th>M<sub>55</sub></th><td>b<sup>0</sup><sub>31</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>95</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr></tbody></table>

<table><caption>FIGURE 8.5 – Notre représentation 2-slicing de 16 blocs dans 64 mots machines ($M_i, 0 \le i \le 63$) d’une architecture 32 bits. $b_i^j$ désigne le $i$-ième bit du $j$-ième bloc.</caption><thead><tr><th></th><th colspan="6">ligne 3</th></tr><tr><th></th><th colspan="3">colonne 1</th><th colspan="3">colonne 3</th></tr><tr><th></th><th>bloc 0</th><th>...</th><th>bloc 15</th><th>bloc 0</th><th>...</th><th>bloc 15</th></tr></thead><tbody><tr><th>M<sub>56</sub></th><td>b<sup>0</sup><sub>56</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>120</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr><tr><th>...</th><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td><td>...</td></tr><tr><th>M<sub>63</sub></th><td>b<sup>0</sup><sub>63</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td><td>b<sup>0</sup><sub>127</sub></td><td>...</td><td>b<sup>15</sup><sub>0</sub></td></tr></tbody></table>
# 8.3 Évaluation des performances et coûts

## 8.3.1 Performance logiciel

Le tableau 8.1 présente les résultats d'implémentations de AES masquées aux ordres $d \in \{1, 3, 7, 15, 31\}$ sans ISE, avec l'ISE1 et avec l'ISE2. Les implémentations masquées avec l'ISE2 permettent de réduire le nombre de blocs chiffrés en parallèle par rapport à l'ISE1. Pour chaque ordre $d \in \{1, 3, 7, 15, 31\}$, nous avons une solution pour chiffrer un seul bloc à la fois, permettant l'utilisation de tous les modes de chiffrement. En termes de temps d'exécution, l'ISE2 impose un petit surcoût par rapport à l'ISE1. Par exemple à l'ordre 1, l'ISE2 induit une augmentation du temps d'exécution de 1,84 par rapport à l'ISE1. Néanmoins, le gain de temps reste important comparé à la solution SW-M-BS masquée sans ISE.

<table><caption>TABLE 8.1 – Résultats d'implantations de l'ISE2 masquée aux ordres $d \in \{1, 2, 3, 7, 15, 31\}$. 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ém.</th><th rowspan="2">Nb blocs chiffrés en parallèle</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>1</td><td>1266</td><td>base</td><td>n.a.</td></tr><tr><td rowspan="5">1</td><td>SW-M-BS</td><td>32</td><td>26001</td><td>×21</td><td>base</td></tr><tr><td>HW-M-ISE1</td><td>16</td><td>5483</td><td>×4,3</td><td>/4,7</td></tr><tr><td rowspan="4">HW-M-ISE2</td><td>8</td><td>8622</td><td>×6,8</td><td>/3,0</td></tr><tr><td>4</td><td>8720</td><td>×6,9</td><td>/3,0</td></tr><tr><td>2</td><td>7992</td><td>×6,3</td><td>/3,3</td></tr><tr><td>1</td><td>10099</td><td>×8,0</td><td>/2,6</td></tr><tr><td rowspan="5">3</td><td>SW-M-BS</td><td>32</td><td>98575</td><td>×78</td><td>base</td></tr><tr><td>HW-M-ISE1</td><td>8</td><td>10927</td><td>×8,6</td><td>/9,0</td></tr><tr><td rowspan="3">HW-M-ISE2</td><td>4</td><td>17308</td><td>×13,7</td><td>/5,7</td></tr><tr><td>2</td><td>17411</td><td>×13,8</td><td>/5,7</td></tr><tr><td>1</td><td>15842</td><td>×12,5</td><td>/6,2</td></tr><tr><td rowspan="4">7</td><td>SW-M-BS</td><td>32</td><td>300414</td><td>×237</td><td>base</td></tr><tr><td>HW-M-ISE1</td><td>4</td><td>22033</td><td>×17,4</td><td>/13,6</td></tr><tr><td rowspan="2">HW-M-ISE2</td><td>2</td><td>34573</td><td>×27,3</td><td>/8,7</td></tr><tr><td>1</td><td>34735</td><td>×27,4</td><td>/8,6</td></tr><tr><td rowspan="3">15</td><td>SW-M-BS</td><td>32</td><td>1041285</td><td>×822</td><td>base</td></tr><tr><td>HW-M-ISE1</td><td>2</td><td>43677</td><td>×34,5</td><td>/23,8</td></tr><tr><td>HW-M-ISE2</td><td>1</td><td>69001</td><td>×54,5</td><td>/15,1</td></tr><tr><td rowspan="2">31</td><td>SW-M-BS</td><td>32</td><td>3716920</td><td>×2936</td><td>base</td></tr><tr><td>HW-M-ISE1</td><td>1</td><td>87489</td><td>×69,1</td><td>/42,5</td></tr></tbody></table>

## 8.3.2 Implémentation sur FPGA

Le tableau 8.2 présente les résultats de l'implémentation FPGA du cœur CV32E40P modifié pour prendre en charge l'ISE2. En termes de surface, l'ISE2 impose une très faible augmen-
tation comparée à l'ISE1. Par exemple, le nombre de LUT du cœur CV32E40P avec l'ISE2 augmente seulement d'un facteur 1,02 par rapport à l'ISE1. De plus, la période minimale de fonctionnement n'est pas impactée car le chemin critique n'est pas dans l'ISE.

<table><caption>TABLE 8.2 – Résultats d'implantation FPGA du cœur CV32E40P avec l'ISE2.</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>ISE1</td><td>2412</td><td>×1,13</td><td>4794</td><td>×1,00</td><td>14,4</td></tr><tr><td>ISE2</td><td>2417</td><td>×1,13</td><td>4912</td><td>×1,03</td><td>15,3</td></tr><tr><td rowspan="2">3</td><td>ISE1</td><td>2590</td><td>×1,21</td><td>4977</td><td>×1,04</td><td>14,9</td></tr><tr><td>ISE2</td><td>2595</td><td>×1,21</td><td>5118</td><td>×1,07</td><td>14,9</td></tr><tr><td rowspan="2">7</td><td>ISE1</td><td>3146</td><td>×1,47</td><td>5596</td><td>×1,17</td><td>14,9</td></tr><tr><td>ISE2</td><td>3151</td><td>×1,47</td><td>5721</td><td>×1,20</td><td>14,9</td></tr><tr><td rowspan="2">15</td><td>ISE1</td><td>4058</td><td>×1,90</td><td>6707</td><td>×1,40</td><td>14,7</td></tr><tr><td>ISE2</td><td>4063</td><td>×1,90</td><td>6657</td><td>×1,39</td><td>14,3</td></tr></tbody></table>
# Chapitre 9

## Extension masquée et sécurisée dans le modèle de sondage par régions

Une implémentation masquée utilisant les ISE précédentes est sécurisée contre un attaquant pouvant sonder *d* bits dans le circuit pendant l'exécution complète. Pour des implémentations de grande taille, le nombre de bits sondés est cependant faible par rapport au nombre de bits manipulés dans toute l'implémentation. Ce faible taux de fuite peut réduire la sécurité obtenue dans le modèle de fuite bruitée (voir sous-section 3.3.4). Pour améliorer le taux de fuite admis, nous proposons une nouvelle ISE, que nous nommons ISE3, qui modifie l'ISE1 pour obtenir une sécurité dans le modèle de sondage 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.

Dans la section 9.1, nous décrivons les instructions de l'ISE3. La section 9.2 présente la mise en œuvre de l'ISE3 ainsi que son implantation dans le cœur CV32E40P. Dans la section 9.3, nous évaluons les performances et la surface de l'ISE3 sur FPGA.

### 9.1 Spécification de l'ISE3

Pour sécuriser contre un attaquant pouvant sonder *d*/2 bits par instruction, nous proposons d'implémenter des instructions masquées à l'ordre *d* comme décrit dans la figure 9.1. Le résultat de l'instruction masquée est obtenue par une opération *d*-NI dans le modèle de sondage robuste aux glitchs. Pour obtenir une isolation entre les différentes instructions, un circuit de rafraîchissement *d*-SNI est appliqué aux entrées de l'opération *d*-NI. Pour maintenir la sécurité dans notre modèle de sondage par régions, les registres d'indice *rs1* et *rs2* sont également rafraîchis avec des circuits de rafraîchissement *d*-SNI dans le modèle de sondage robuste aux glitchs. Sans rafraîchissement des registres d'indices *rs1* et *rs2*, un attaquant pourrait sonder *d*/2 bits à chaque utilisation d'un registre, réduisant ainsi le niveau de sécurité. Ces instructions masquées à l'ordre *d* permettent alors d'obtenir la sécurité contre un attaquant sondant *d*/2 bits par instruction :

**Proposition 1.** Si un programme utilise uniquement des instructions masquées à l'ordre *d* implémentées comme dans la figure 9.1, alors le programme est sécurisé contre un attaquant sondant *d*/2 bits par instruction dans le modèle de sondage robuste aux glitchs.
<figure><img src="image_69.png" /><figcaption>FIGURE 9.1 – Schéma d’une instruction masquée à l’ordre *d* et sécurisée dans le modèle de sondage par régions avec *d/2* sonde par instruction. **reg[x]** désigne le registre d’indice *x* dans le banc de registres.</figcaption></figure>

*Démonstration.* Considérons l'instruction masquée de la figure 9.2 dans laquelle les ensembles $\mathcal{O}_i$ désignent les sondes de sortie et $\mathcal{I}_i$ les sondes internes.

<figure><img src="image_70.png" /><figcaption>FIGURE 9.2 – Illustration d'une preuve de sécurité dans le modèle de sondage par régions.</figcaption></figure>

Montrons dans un premier temps que si les sondes de sortie $\mathcal{O}_i$, $1 \le i \le 3$ vérifient $|\mathcal{O}_i| \le d/2$ pour tout $i$, et les sondes internes $\mathcal{I}_i$, $1 \le i \le 5$ vérifient $\sum_i |\mathcal{I}_i| \le d/2$, alors, les sondes de sortie et internes peuvent être simulées par un ensemble de sondes $\mathcal{A}$ de $\text{reg}[\text{rs1}]$ vérifiant $|\mathcal{A}| \le d/2$ et un ensemble de sondes $\mathcal{B}$ de $\text{reg}[\text{rs2}]$ vérifiant $|\mathcal{B}| \le d/2$. Pour cela, traitons chaque porte une par une :

- Comme $|\mathcal{O}_1| + |\mathcal{I}_1| \le d/2 + d/2 \le d$ et $\text{rafr}_1$ est d-SNI, alors les ensembles $\mathcal{O}_1$ et $\mathcal{I}_1$ peuvent être simulés avec l'ensemble $\mathcal{S}_1$ vérifiant $|\mathcal{S}_1| \le |\mathcal{I}_1|$.

- De même, comme $|\mathcal{O}_3| + |\mathcal{I}_3| \le d$ et $\text{rafr}_4$ est d-SNI, alors les ensembles $\mathcal{O}_3$ et $\mathcal{I}_3$ peuvent être simulés avec l'ensemble $\mathcal{S}_3$ vérifiant $|\mathcal{S}_3| \le |\mathcal{I}_3|$.

- Comme $|\mathcal{O}_2| + |\mathcal{I}_2| \le d/2 + d/2 \le d$ et l'opération est d-NI, alors les ensembles $\mathcal{O}_2$ et $\mathcal{I}_2$ peuvent être simulés avec les ensembles $\mathcal{S}_2^1$ et $\mathcal{S}_2^2$ vérifiant $|\mathcal{S}_2^1| \le |\mathcal{O}_2| + |\mathcal{I}_2|$ et $|\mathcal{S}_2^2| \le |\mathcal{O}_2| + |\mathcal{I}_2|$.

- Comme $|\mathcal{S}_2^1| + |\mathcal{I}_4| \le |\mathcal{O}_2| + |\mathcal{I}_2| + |\mathcal{I}_4| \le d$ et $\text{rafr}_2$ est d-SNI, alors les ensembles $\mathcal{S}_2^1$ et $\mathcal{I}_4$ peuvent être simulés avec l'ensemble $\mathcal{S}_4$ vérifiant $|\mathcal{S}_4| \le |\mathcal{I}_4|$.

- De même, comme $|\mathcal{S}_2^2| + |\mathcal{I}_5| \le |\mathcal{O}_2| + |\mathcal{I}_2| + |\mathcal{I}_5| < d$ et $\text{rafr}_3$ est d-SNI, alors les ensembles $\mathcal{S}_2^2$ et $\mathcal{I}_5$ peuvent être simulés avec l'ensemble $\mathcal{S}_5$ vérifiant $|\mathcal{S}_5| \le |\mathcal{I}_5|$.

L'ensemble des sondes peut donc être simulé avec un ensemble de parts $\mathcal{A} = \mathcal{S}_1 \cup \mathcal{S}_4$ de $\text{reg}[\text{rs1}]$ et un ensemble de parts $\mathcal{B} = \mathcal{S}_3 \cup \mathcal{S}_5$ de $\text{reg}[\text{rs2}]$, vérifiant $|\mathcal{A}| \le |\mathcal{S}_1| + |\mathcal{S}_4| \le |\mathcal{I}_1| + |\mathcal{I}_4| \le d/2$
et $|\mathcal{B}| \le |\mathcal{S}_3| + |\mathcal{S}_5| \le |\mathcal{I}_3| + |\mathcal{I}_5| \le d/2$.

En considérant maintenant le programme comme un graphe dans lequel les différentes instructions sont des sous-graphes, nous pouvons simuler $d/2$ sondes par instruction à partir de $d/2$ parts de chaque masquage d'entrée en appliquant récursivement la propriété démontrée ci-dessus. □

Nous proposons une ISE dédiée au masquage, nommée ISE3, implémentant les instructions de l'ISE1 comme dans la figure 9.1 de façon à être sécurisées contre un attaquant pouvant sonder $d/2$ bits par instruction. Les instructions de l'ISE3 sont décrites dans la figure 9.3. mand, mxor et mnot désignent respectivement des circuits masqués $d$-NI dans le modèle de sondage robuste aux glitchs des portes booléennes AND, XOR, NOT. rafr désigne un circuit de rafraîchissement $d$-SNI dans le modèle de sondage robuste aux glitchs.

def ise_and(rs1, rs2, rd):
    n=d+1
    for i in range(32//n):
        a=rafr(reg[rs1][i*n:(i+1)*n])
        b=rafr(reg[rs2][i*n:(i+1)*n])
        reg[rd][i*n:(i+1)*n]=mand(a,b)
        reg[rs1][i*n:(i+1)*n]=rafr(reg[rs1][i*n:(i+1)*n])
        reg[rs2][i*n:(i+1)*n]=rafr(reg[rs2][i*n:(i+1)*n])

def iseamo(xor(rs1, rs2, rd):
    n=d+1
    for i in range(32//n):
        a=rafr(reg[rs1][i*n:(i+1)*n])
        b=rafr(reg[rs2][i*n:(i+1)*n])
        reg[rd][i*n:(i+1)*n]=mxor(a,b)
        reg[rs1][i*n:(i+1)*n]=rafr(reg[rs1][i*n:(i+1)*n])
        reg[rs2][i*n:(i+1)*n]=rafr(reg[rs2][i*n:(i+1)*n])

def ise_not(rs1, rs2, rd):
    n=d+1
    for i in range(32//n):
        a=rafr(reg[rs1][i*n:(i+1)*n])
        b=rafr(reg[rs2][i*n:(i+1)*n])
        reg[rd][i*n:(i+1)*n]=mnot(a,b)
        reg[rs1][i*n:(i+1)*n]=rafr(reg[rs1][i*n:(i+1)*n])
        reg[rs2][i*n:(i+1)*n]=rafr(reg[rs2][i*n:(i+1)*n])

def ise_or(rs1, rs2, rd):
    n=d+1
    for i in range(32//n):
        a=rafr(reg[rs1][i*n:(i+1)*n])
        b=rafr(reg[rs2][i*n:(i+1)*n])
        tmp1 = mnot(a)
        tmp2 = mnot(b)
        tmp3 = mand(tmp1, tmp2)
        reg[rd][i*n:(i+1)*n]=mnot(tmp3)
        reg[rs1][i*n:(i+1)*n]=rafr(reg[rs1][i*n:(i+1)*n])
        reg[rs2][i*n:(i+1)*n]=rafr(reg[rs2][i*n:(i+1)*n])

FIGURE 9.3 – Code Python décrivant les nouvelles instructions de l'ISE3 masquée à l'ordre $d \in \{1, \dots, 31\}$. mand, mxor et mnot désignent respectivement des circuits masqués $d$-NI des portes booléennes AND, XOR, NOT. rafr désigne un circuit de rafraîchissement $d$-SNI. reg[x] désigne le registre d'indice x dans le banc de registres.
## 9.2 Implémentation de l'ISE3 sur le CV32E40P

Dans cette section, nous décrivons l'implémentation de l'ISE3 sur le cœur CV32E40P.

### 9.2.1 ALU masquée proposée

<figure><img src="image_71.png" /><figcaption>FIGURE 9.4 – Architecture de l’ALU masquée de l’ISE3.</figcaption></figure>

L'ALU masquée décrite dans la figure 9.4 a été développée pour implémenter nos nouvelles instructions. Les portes masquées mand sont implémentées avec le AND masqué d-NI de [Fau+18] alors que les portes masquées mxor et mnot sont implémentées de façon directe. Les registres d'entrée sont préalablement rafraîchis avec un circuit de rafraîchissement d-SNI basé sur la porte AND masquée de [Fau+18]. L'ALU masquée génère également en sortie deux valeurs de 32 bits contenant les valeurs des registres reg[rs1] et reg[rs2] rafraîchies avec d'autres circuits de rafraîchissement d-SNI. Le tableau 9.1 décrit les caractéristiques des instructions masquées de l'ISE3.

<table><caption>TABLE 9.1 – Caractéristiques des instructions masquées de l'ISE3. m est égal à rnd (<sup>32</sup>⁄<sub>d+1</sub>). La latence est exprimée en nombre de cycles et les aléas en nombre de bits par instruction.</caption><thead><tr><td>Instructions</td><td>Latence</td><td>Aléas</td></tr></thead><tbody><tr><td>ise3.xor</td><td>2</td><td>m × 4 × <sup>d(d+1)</sup>⁄2</td></tr><tr><td>ise3.not</td><td>2</td><td>m × 4 × <sup>d(d+1)</sup>⁄2</td></tr><tr><td>ise3.and</td><td>3</td><td>m × 4 × <sup>d(d+1)</sup>⁄2</td></tr><tr><td>ise3.or</td><td>3</td><td>m × 4 × <sup>d(d+1)</sup>⁄2</td></tr></tbody></table>
### 9.2.2 Intégration dans le cœur CV32E40P

L'ALU masquée a ensuite été intégrée au cœur CV32E40P, comme illustré sur la figure 9.5. Le décodeur d'instructions modifié traite les nouvelles instructions et génère des signaux de contrôle pour les instructions multi-cycles. Comme pour l'ISE1, nous avons conçu un chemin de données séparé pour l'ALU masquée afin d'éviter les problèmes de recombinaison des parts. La mise en place du chemin de données totalement séparé nécessite d'étendre le registre de pipeline ID/EX avec 2 nouveaux registres 32 bits accessibles uniquement depuis l'ALU masquée. À la différence de l'ISE1, nous avons ajouté deux nouveaux ports d'écriture au fichier de registres pour actualiser à chaque instruction les registres d'indices rs1 et rs2 avec leurs valeurs rafraîchies.

<figure><img src="image_72.png" /><figcaption>FIGURE 9.5 – Schéma simplifié du cœur modifié avec l'ISE3. Les parties rouges ont été ajoutées ou modifiées pour notre ISE.</figcaption></figure>

## 9.3 Évaluation des performances et coûts

<figure><img src="image_73.png" /><figcaption>FIGURE 9.6 – Temps de chiffrement (en échelle log) pour un bloc de AES en utilisant l'ISE3 et diverses solutions de masquage logiciel et matériel.</figcaption></figure>
La figure 9.6 présente le temps d'exécution du chiffrement AES masqué en utilisant l'ISE3 (labellisé par HW-M-ISE3), ainsi que différentes solutions de la littérature que nous avons réimplémenté sur le cœur CV32E40P (voir section 6.3). HW-M-ISE3 surpasse l'implémentation BS masquée en logiciel SW-M-BS. L'ISE3 induit un petit surcoût en termes de performance par rapport à l'ISE1, mais augmente la sécurité en permettant à un attaquant de sonder $d/2$ bits par instruction.

<figure><img src="image_74.png" /><figcaption>FIGURE 9.7 – Surface et fréquence maximale du cœur CV32E40P (CORE) sans ISE, avec Skiva (CORE+SKIVA), avec SME (CORE+SME), avec la version HPC3 de ISE1 (CORE+ISE1) et avec l'ISE3 (CORE+ISE3).</figcaption></figure>

La figure 9.7 présente la surface et la fréquence maximale du cœur CV32E40P sans ISE (CORE), avec Skiva (CORE+SKIVA), avec SME (CORE+SME), avec la version HPC3 de l'ISE1 (CORE+ISE1) et avec l'ISE3 (CORE+ISE3), pour des ordres de masquage $d$ dans $\{1, 2, 3, \dots, 31\}$. L'ISE3 masquée aux ordres 1, 2 et 3 est bien plus petite que SME. On constate cependant que l'ISE3 a un impact plus important en surface que l'ISE1. Cela s'explique par l'ajout de deux nouveaux ports d'écriture au fichier de registres.
# Chapitre 10

## Solution matérielle/logicielle flexible pour masquer à des ordres élevés

Pour maintenir la sécurité à long terme, il peut être essentiel de pouvoir adapter le niveau de sécurité de la protection de masquage. Contrairement à la mise en œuvre logicielle du masquage, les ISE masquées de l'état de l'art sont limitées aux petits ordres de masquage et ne sont pas assez flexibles pour adapter le niveau de sécurité sans changer le matériel (voir tableau 10.1). Nous proposons une solution de masquage *matériel et logiciel flexible*, que nous nommons HW-SW-ISE1, qui permet de masquer des implémentations BS à divers ordres élevés sans changer le matériel. Un premier niveau de masquage est implémenté en matériel en utilisant l'ISE1 (voir chapitre. 7) dont l'ordre de masquage $d_H$ est fixé *au moment de la synthèse*. Un masquage logiciel, dont l'ordre $d_S$ est fixé au *moment de la compilation logicielle*, utilise ensuite les instructions masquées de l'ISE1 pour atteindre divers ordres supérieurs. Notre solution matérielle/logicielle permet divers compromis entre le coût matériel, le temps d'exécution et la sécurité.

<table><caption>TABLE 10.1 – Caractéristiques des ISE masquées de l'état de l'art et de notre solution HW-SW-ISE1.</caption><thead><tr><th>Référence</th><th>RISC-V</th><th>Ordre de masquage</th><th>Flexibilité au moment de la synthèse</th><th>Flexibilité au moment de la compilation</th></tr></thead><tbody><tr><td>[Gro+16]</td><td>✓</td><td>{1, 2, 3, 4}</td><td>✓</td><td>✗</td></tr><tr><td>[DGH19]</td><td>✓</td><td>1</td><td>✗</td><td>✗</td></tr><tr><td>[Gao+21]</td><td>✓</td><td>1</td><td>✗</td><td>✗</td></tr><tr><td>SKIVA [Kia+21]</td><td>✗</td><td>{1, 3}</td><td>✗</td><td>✓</td></tr><tr><td>SME [MP21]</td><td>✓</td><td>{1, 2, 3}</td><td>✓</td><td>✗</td></tr><tr><td>HW-SW-ISE1</td><td>✓</td><td>(d<sub>S</sub> + 1)(d<sub>H</sub> + 1) - 1, d<sub>H</sub> ∈ N, d<sub>S</sub> ∈ N</td><td>✓</td><td>✓</td></tr></tbody></table>

Dans la section 10.1, nous décrivons notre solution de masquage matériel/logiciel. Dans la section 10.2, nous évaluons les performances et la surface de notre solution sur FPGA.
# 10.1 Solution de masquage matériel/logiciel

## 10.1.1 Présentation de notre solution matériel/logicielle

**Notre solution de masquage** Nous proposons une solution de masquage matériel et logiciel, que nous nommons HW-SW-ISE1, permettant de masquer des implémentations BS à des ordres de masquage beaucoup plus é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 (voir chapitre 7) dont l'ordre de masquage matériel $d_H$ est fixé au moment de la synthèse. Un masquage logiciel, dont l'ordre $d_S$ est fixé au moment de la compilation logicielle, utilise ensuite de façon sécurisée les instructions masquées de l'ISE1 pour obtenir un ordre de masquage total plus élevé. L'ordre de masquage total obtenu est $d = (d_S + 1)(d_H + 1) - 1$.

**Notre représentation masquée** Notre solution de masquage matériel/logiciel utilise une nouvelle représentation masquée qui est un compromis entre le BS masqué et le « share slicing ». Les bits sensibles sont d'abord masqués à l'ordre $d_S$ en disposant les parts dans différents registres comme pour le BS masqué, puis chaque part est à nouveau masquée à l'ordre $d_H$ en disposant les parts dans un même registre comme pour le « share slicing ». Chaque bit est alors masqué en $(d_S + 1)(d_H + 1)$ parts et l'ordre de masquage obtenu est $d = (d_S + 1)(d_H + 1) - 1$. La figure 10.1 illustre notre représentation masquée avec $d_H = 1$ et $d_S = 2$.

<figure><img src="image_75.png" /><figcaption>FIGURE 10.1 – Notre représentation masquée avec $d_H = 1$ et $d_S = 2$ sur une architecture 32 bits. $\hat{b}_i^j$ désigne un masquage du $i$-ième bit du $j$-ième bloc. $\hat{b}_i^j[k][l]$ désigne la $l$-ième part matérielle de la $k$-ième part logicielle du masquage $\hat{b}_i^j$.</figcaption></figure>

**Flexibilité de notre solution** Le niveau de sécurité de notre solution de masquage peut être adapté au moment de la compilation logicielle en modifiant l'ordre de masquage logiciel $d_S$. La flexibilité de notre solution permet également divers compromis coût/performance. Par exemple, pour des applications à surface limitée, une ISE masquée à l'ordre 1 peut être implémentée en matériel et utilisée en logiciel pour différentes valeurs de $d_S$, conduisant à un ordre de masquage total $d \in \{1, 3, 5, 7, 9, 11, \dots\}$. Pour des applications de haute sécurité, une ISE masquée à un ordre plus élevé, comme par exemple 5, peut être implémentée en matériel puis utilisée en logiciel pour différentes valeurs de $d_S$, conduisant à un ordre de masquage total $d \in \{5, 11, 17, 23, 29, \dots\}$.
## 10.1.2 Masquage logiciel/matériel avec la version NI-SNI de l'ISE1

Nous décrivons une première solution de masquage logiciel/matériel utilisant de façon sé-
curisée les instructions de la version NI-SNI de l'ISE1 masquée à l'ordre $d_H$. Pour manipuler
des variables masquées avec notre représentation, nous avons développé des implémentations
masquées à l'ordre $d = (d_S + 1)(d_H + 1) - 1$ des portes booléennes XOR, NOT, AND, OR. Notre
méthode consiste à prendre une implémentation masquée en logiciel à l'ordre $d_S$ de la porte
booléenne, puis de masquer à nouveau l'implémentation en matériel à l'ordre $d_H$ en utilisant
les instructions masquées de l'ISE1. Nous obtenons ainsi des implémentations d-NI des portes
XOR, NOT et des implémentations d-SNI des portes AND, OR. Les implémentations BS peuvent
alors être masquées à l'ordre $d$ en utilisant nos portes booléennes masquées dans le code généré
par Tornado. Nous allons à présent décrire chaque porte booléenne masquée et prouver leur
sécurité dans le modèle de sondage robuste aux glitchs.

**Algorithmme 10** Porte XOR masquée à l'ordre $d_S$ utilisant les instructions de l'ISE1 masquée à l'ordre $d_H$.

Entrée: $\hat{\mathbf{x}} \in \text{GF}(2)^{d_S+1}$ et $\hat{\mathbf{y}} \in \text{GF}(2)^{d_S+1}$

Sortie: $\hat{\mathbf{z}} \in \text{GF}(2)^{d_S+1}$

pour $i = 0$ à $d_S$ faire

$$ \hat{z}[i] \leftarrow \text{ise1.xor}(\hat{\mathbf{x}}[i], \hat{\mathbf{y}}[i]) $$

fin pour

L'algorithme 10 est une implémentation logicielle masquée à l'ordre $d_S$ de la porte XOR dans laquelle l'instruction **xor** est remplacée par l'instruction **ise1.xor** de l'ISE1 masquée à l'ordre $d_H$. Cette implémentation masquée est alors d-NI dans le modèle de sondage robuste aux glitchs :

**Proposition 2.** Si l'instruction isel.xor est $d_H$-NI dans le modèle de sondage robuste aux glitchs, alors la porte XOR masquée en logiciel à l'ordre $d_S$ de l'algorithme 10 est d-NI dans le modèle de sondage robuste aux glitchs, avec $d = (d_S + 1)(d_H + 1) - 1$.

*Démonstration.* Voir la section C.1 de l'annexe C.

**Algorithmme 11** Porte NOT masquée à l'ordre $d_S$ utilisant les instructions de l'ISE1 masquée à l'ordre $d_H$.

Entrée: $\hat{\mathbf{x}} \in \text{GF}(2)^{d_S+1}$

Sortie: $\hat{\mathbf{y}} \in \text{GF}(2)^{d_S+1}$

$$ \hat{\mathbf{y}}[0] \leftarrow \text{ise1.not}(\hat{\mathbf{x}}[0]) $$

pour $i = 0$ à $d_S$ faire

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

fin pour

L'algorithme 11 est une implémentation logicielle masquée à l'ordre $d_S$ de la porte NOT dans laquelle l'instruction **not** est remplacée par l'instruction **ise1.not** de l'ISE1 masquée à l'ordre $d_H$. On peut montrer, de façon similaire à l'algorithme 10, que cette implémentation masquée est alors d-NI dans le modèle de sondage robuste aux glitchs, avec $d = (d_S + 1)(d_H + 1) - 1$.
**Algorithmme 12** Porte AND masquée à l'ordre $d_S$ et $d_S$-SNI utilisant les instructions de l'ISE1 masquée à l'ordre $d_H$ et $d_H$-SNI.

Entrée: $\hat{\mathbf{x}} \in \text{GF}(2)^{d_S+1}$ et $\hat{\mathbf{y}} \in \text{GF}(2)^{d_S+1}$

Sortie: $\hat{\mathbf{z}} \in \text{GF}(2)^{d_S+1}$

pour $i = 0$ à $d_S$ faire

$a_{i,i} \leftarrow \text{ise1.and}(\hat{\mathbf{x}}[i], \hat{\mathbf{y}}[i])$

$u_{i,i} \leftarrow a_{i,i}$

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

$r_{i,j} \stackrel{\$}{\leftarrow} \text{GF}(32)$

$a_{i,j} \leftarrow \text{ise1.and}(\hat{\mathbf{x}}[i], \hat{\mathbf{y}}[j])$

$u_{i,j} \leftarrow \text{ise1.xor}(a_{i,j}, r_{i,j})$

$a_{j,i} \leftarrow \text{ise1.and}(\hat{\mathbf{x}}[j], \hat{\mathbf{y}}[i])$

$u_{j,i} \leftarrow \text{ise1.xor}(a_{j,i}, r_{i,j})$

fin pour

fin pour

pour $i = 0$ à $d_S$ faire

$v_{i,0} \leftarrow u_{i,0}$

pour $j = 1$ à $d_S$ faire

$v_{i,j} \leftarrow \text{ise1.xor}(v_{i,j-1}, u_{i,j})$

fin pour

$\hat{\mathbf{z}}[i] \leftarrow v_{i,d_S}$

fin pour

L'algorithme 12 est une implémentation logicielle masquée à l'ordre $d_S$ et $d_S$-SNI de la porte AND dans laquelle les instructions **xor** et **and** sont remplacées respectivement par les instructions **ise1.xor** et **ise1.and** de l'ISE1 masquée à l'ordre $d_H$. Cette implémentation masquée est alors $d$-SNI dans le modèle de sondage robuste aux glitchs.

**Proposition 3.** Si l'instruction `ise1.xor` est $d_H$-NI et `ise1.and` est $d_H$-SNI dans le modèle de sondage robuste aux glitchs, alors la porte AND masquée à l'ordre $d_S$ de l'algorithme 12 est $d$-SNI dans le modèle de sondage robuste aux glitchs, avec $d = (d_S + 1)(d_H + 1) - 1$.

*Démonstration.* Voir la section C.2 de l'annexe C. □

Pour implémenter la porte OR masquée à l'ordre $d$, nous utilisons les portes masquées NOT et AND conformément aux lois de de Morgan.

### 10.1.3 Masquage logiciel/matériel avec une version PINI de l'ISE1

La solution de masquage logiciel/matériel de la sous-section précédente permet d'obtenir des implémentations NI et SNI de portes booléennes. Cette solution nécessite cependant d'insérer des codes de rafraîchissement à certains endroits bien choisis pour maintenir la sécurité de séquences d'instructions. Bien qu'il existe des outils pour le faire tel que Tornado, cela peut s'avérer compliqué et les codes de rafraîchissement insérés peuvent impacter les performances. Nous proposons une seconde solution de masquage logiciel/matériel utilisant de façon sécurisée les instructions des versions PINI de l'ISE1 masquée à l'ordre $d_H$. Nous avons développé des implémentations masquées à l'ordre $d = (d_S + 1)(d_H + 1) - 1$ des portes XOR, NOT, AND, OR
qui vérifient également la propriété de composition $d$-PINI. Grâce à la propriété de composition $d$-PINI, l'insertion de codes de rafraîchissement n'est plus nécessaire. Nous allons à présent décrire chaque porte booléenne masquée et prouver leur sécurité dans le modèle de sondage robuste aux glitchs.

Tout d'abord, l'algorithme 10 est $d$-PINI dans le modèle de sondage robuste aux glitchs si les instructions `ise1.xor` sont $d_H$-PINI dans le modèle de sondage robuste aux glitchs :

**Proposition 4.** Si l'instruction `ise1.xor` est $d_H$-PINI dans le modèle de sondage robuste aux glitchs, alors la porte XOR masquée en logiciel à l'ordre $d_S$ de l'algorithme 10 est $d$-PINI dans le modèle de sondage robuste aux glitchs, avec $d = (d_S + 1)(d_H + 1) - 1$.

*Démonstration.* Voir la section C.3 de l'annexe C. □

De façon similaire, on peut monter que l'algorithme 11 est $d$-PINI dans le modèle de sondage robuste aux glitchs si l'instruction `ise1.not` est $d_H$-PINI dans le modèle de sondage robuste aux glitchs.

**Algorithme 13** Porte AND masquée à l'ordre $d_S$ utilisant les instructions de l'ISE1 masquée à l'ordre $d_H$ et $d_H$-PINI.

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

**Sortie:** $\hat{\mathbf{z}} \in \text{GF}(2)^{d_S+1}$

pour $i = 0$ à $d_S$ faire

$u_{i,i} \leftarrow \text{ise1.and}(\hat{\mathbf{x}}[i], \hat{\mathbf{y}}[i])$

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

$r_{i,j} \stackrel{\$}{\leftarrow} \text{GF}(32)$

$a_{i,j} \leftarrow \text{ise1.xor}(\hat{\mathbf{y}}[j], r_{i,j})$

$b_{i,j} \leftarrow \text{ise1.and}(\hat{\mathbf{x}}[i], a_{i,j})$

$c_{i,j} \leftarrow \text{ise1.not}(\hat{\mathbf{x}}[i])$

$d_{i,j} \leftarrow \text{ise1.and}(c_{i,j}, r_{i,j})$

$u_{j,i} \leftarrow \text{ise1.xor}(b_{i,j}, d_{i,j})$

$a_{j,i} \leftarrow \text{ise1.xor}(\hat{\mathbf{y}}[i], r_{i,j})$

$b_{j,i} \leftarrow \text{ise1.and}(\hat{\mathbf{x}}[j], a_{j,i})$

$c_{j,i} \leftarrow \text{ise1.not}(\hat{\mathbf{x}}[j])$

$d_{j,i} \leftarrow \text{ise1.and}(c_{j,i}, r_{i,j})$

$u_{j,i} \leftarrow \text{ise1.xor}(b_{j,i}, d_{j,i})$

fin pour

fin pour

pour $i = 0$ à $d_S$ faire

$v_{i,0} \leftarrow u_{i,j}$

pour $j = 1$ à $d_S$ faire

$v_{i,j} \leftarrow \text{ise1.xor}(v_{i,j-1}, u_{i,j})$

fin pour

$\hat{\mathbf{z}}[i] \leftarrow v_{i,d_S}$

fin pour

L'algorithme 13 est une implémentation logicielle masquée à l'ordre $d_S$ et $d_S$-PINI de la porte AND dans laquelle les instructions `xor` et `and` sont remplacées respectivement par les ins-
tructions `ise1.xor` et `ise1.and` de l'ISE1 masquée à l'ordre $d_H$. Cette implémentation masquée est alors $d$-PINI dans le modèle de sondage robuste aux glitchs :

**Proposition 5.** Si les instructions `ise1.xor` et `ise1.and` sont $d_H$-PINI dans le modèle de sondage robuste aux glitchs, alors la porte AND masquée à l'ordre $d_S$ de l'algorithme 13 est $d$-PINI dans le modèle de sondage robuste aux glitchs, avec $d = (d_S + 1)(d_H + 1) - 1$.

*Démonstration.* Voir la section C.4 de l'annexe C. □

Pour implémenter la porte OR masqué à l'ordre $d$, nous utilisons les portes masquées NOT et AND conformément aux lois de de Morgan.

## 10.2 Évaluation des performances et coûts

<figure><img src="image_76.png" /><figcaption>FIGURE 10.2 – Résultats d'implémentations du chiffrement AES avec notre solution de masquage matériel/logiciel utilisant la version HPC3 de l'ISE1 masquée aux ordres matériels $d_H \in \{1, 2, 3, 5, 7\}$ et pour différents ordres logiciels.</figcaption></figure>

La figure 10.2 présente les résultats d'implémentations du chiffrement AES avec notre solution de masquage matériel/logiciel utilisant la version HPC3 de l'ISE1 masquée aux ordres matériels $d_H \in \{1, 2, 3, 5, 7\}$ et pour différents ordres logiciels. Notre solution de masquage matériel/logiciel permet divers compromis entre le coût matériel et le temps d'exécution. On constate en effet qu'augmenter l'ordre matériel de l'ISE1 permet de réduire le temps de chiffrement, mais augmente la surface du cœur. Les résultats d'implémentations présentés dans le tableau 10.2 illustrent les différents compromis possibles. Par exemple, notre solution matérielle/logicielle masquée aux ordres ($d_H = 1, d_S = 15$), ($d_H = 3, d_S = 7$), ($d_H = 7, d_S = 3$), ($d_H = 15, d_S = 1$) permet d'obtenir un ordre total $d = 31$. L'accélération obtenue par rapport à SW-M-BS est respectivement de 1,3 ; de 2,3 ; de 5,0 ; de 7,1 ; alors que le nombre de FF augmente respectivement de 1,13 ; de 1,21 ; de 1,47 ; de 1,90. Un autre bénéfice de notre solution de masquage matériel/logiciel est qu'elle permet de modifier l'ordre total via plusieurs codes compilés en continuant à utiliser l'ISE1 masquée à un ordre matériel fixé au moment de la synthèse. Par exemple, lorsque l'ISE1 est masquée à l'ordre $d_H = 3$, on peut obtenir un ordre total $d \in \{3, 7, 11, 15, 19, 23, 27, 31, ...\}$. On constate également que la solution utilisant la version NI-SNI de l'ISE1 est plus performante que la solution utilisant la version HPC3 de l'ISE1. Cela peut s'expliquer car l'algorithme 13 nécessite davantage d'opérations que l'algorithme 12.
<table><caption>TABLE 10.2 – Résultats d'implémentations du chiffrement AES avec notre solution matérielle/logicielle masquée aux ordres matériels $d_H \in \{1, 2, 3, 5, 7\}$ et pour différents ordres logiciels. cmp1 et cmp2 comparent respectivement le temps d'exécution par rapport à SW-TTABLE et SW-M-BS. Les nombres de FF et LUT sont donnés en surcoût par rapport à ceux du cœur CV32E40P de base.</caption><thead><tr><th rowspan="2">Implémentation</th><th rowspan="2">Version ISE1</th><th rowspan="2">d</th><th rowspan="2">d<sub>H</sub></th><th rowspan="2">d<sub>S</sub></th><th colspan="3">Temps</th><th colspan="2">Surface</th></tr><tr><th>Cycles</th><th>cmp1</th><th>cmp2</th><th>FF</th><th>LUT</th></tr></thead><tbody><tr><td>SW-TTABLE</td><td>Sans ISE</td><td>0</td><td>0</td><td>0</td><td>1266</td><td>base</td><td>n.a.</td><td>base</td><td>base</td></tr><tr><td rowspan="5">SW-M-BS<br>HW-SW-ISE1</td><td>Sans ISE</td><td></td><td>0</td><td>3</td><td>98575</td><td>×78</td><td>base</td><td>×1,00</td><td>×1,00</td></tr><tr><td>HPC3</td><td rowspan="3">3</td><td>1</td><td>1</td><td>66347</td><td>×52</td><td>/1,5</td><td>×1,13</td><td>×1,00</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>43307</td><td>×34</td><td>/2,3</td><td>×1,10</td><td>×1,02</td></tr><tr><td>HPC3</td><td>3</td><td>0</td><td>10927</td><td>×8,6</td><td>/9,0</td><td>×1,21</td><td>×1,04</td></tr><tr><td>NI-SNI</td><td></td><td></td><td></td><td>11567</td><td>×9,1</td><td>/8,5</td><td>×1,14</td><td>×1,03</td></tr><tr><td rowspan="6">SW-M-BS<br>HW-SW-ISE1</td><td>Sans ISE</td><td></td><td>0</td><td>7</td><td>300414</td><td>×237</td><td>base</td><td>×1,00</td><td>×1,00</td></tr><tr><td>HPC3</td><td rowspan="5">7</td><td>1</td><td>3</td><td>238560</td><td>×188</td><td>/1,3</td><td>×1,13</td><td>×1,00</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>224480</td><td>×177</td><td>/1,3</td><td>×1,10</td><td>×1,02</td></tr><tr><td>HPC3</td><td>3</td><td>1</td><td>129688</td><td>×102</td><td>/2,3</td><td>×1,21</td><td>×1,04</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>85528</td><td>×67</td><td>/3,5</td><td>×1,14</td><td>×1,03</td></tr><tr><td>HPC3</td><td>7</td><td>0</td><td>22033</td><td>×17,4</td><td>/13,6</td><td>×1,47</td><td>×1,17</td></tr><tr><td>NI-SNI</td><td></td><td></td><td></td><td>23313</td><td>×18,4</td><td>/12,9</td><td>×1,27</td><td>×1,07</td></tr><tr><td rowspan="9">SW-M-BS<br>HW-SW-ISE1</td><td>Sans ISE</td><td></td><td>0</td><td>15</td><td>1041285</td><td>×822</td><td>base</td><td>×1,00</td><td>×1,00</td></tr><tr><td>HPC3</td><td rowspan="8">15</td><td>1</td><td>7</td><td>793304</td><td>×626</td><td>/1,3</td><td>×1,13</td><td>×1,00</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>724184</td><td>×572</td><td>/1,4</td><td>×1,10</td><td>×1,02</td></tr><tr><td>HPC3</td><td>3</td><td>3</td><td>477371</td><td>×377</td><td>/2,2</td><td>×1,21</td><td>×1,04</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>449211</td><td>×354</td><td>/2,3</td><td>×1,14</td><td>×1,03</td></tr><tr><td>HPC3</td><td>7</td><td>1</td><td>265732</td><td>×209</td><td>/3,9</td><td>×1,47</td><td>×1,17</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>173572</td><td>×137</td><td>/6,0</td><td>×1,27</td><td>×1,07</td></tr><tr><td>HPC3</td><td>15</td><td>0</td><td>43677</td><td>×34,5</td><td>/23,8</td><td>×1,90</td><td>×1,40</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>46237</td><td>×36,5</td><td>/22,5</td><td>×1,48</td><td>×1,17</td></tr><tr><td rowspan="10">SW-M-BS<br>HW-SW-ISE1</td><td>Sans ISE</td><td></td><td>0</td><td>31</td><td>3716920</td><td>×2936</td><td>base</td><td>×1,00</td><td>×1,00</td></tr><tr><td>HPC3</td><td rowspan="9">31</td><td>1</td><td>15</td><td>2772567</td><td>×2190</td><td>/1,3</td><td>×1,13</td><td>×1,00</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>2470487</td><td>×1951</td><td>/1,5</td><td>×1,10</td><td>×1,02</td></tr><tr><td>HPC3</td><td>3</td><td>7</td><td>1586573</td><td>×1253</td><td>/2,3</td><td>×1,21</td><td>×1,04</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>1448333</td><td>×1144</td><td>/2,6</td><td>×1,14</td><td>×1,03</td></tr><tr><td>HPC3</td><td>7</td><td>3</td><td>742167</td><td>×586</td><td>/5,0</td><td>×1,47</td><td>×1,17</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>456468</td><td>×360</td><td>/8,1</td><td>×1,27</td><td>×1,07</td></tr><tr><td>HPC3</td><td>15</td><td>1</td><td>526524</td><td>×415</td><td>/7,1</td><td>×1,90</td><td>×1,40</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>342204</td><td>×270</td><td>/10,7</td><td>×1,48</td><td>×1,17</td></tr><tr><td>HPC3</td><td>31</td><td>0</td><td>87489</td><td>×69,1</td><td>/42,5</td><td>×2,75</td><td>×1,81</td></tr><tr><td>NI-SNI</td><td></td><td></td><td>92609</td><td>×73,2</td><td>/40,1</td><td>×1,91</td><td>×1,36</td></tr></tbody></table>
<figure><img src="image_77.png" /></figure>
Conclusion

Durant cette thèse, différentes extensions de jeux d'instructions (ISE) ont été développées pour masquer des implémentations «bit slicing» (BS) à des ordres élevés. Une première solution est donnée par l'ISE1 qui permet d'implémenter de façon sécurisée et efficace des implémentations BS masquées en utilisant la représentation «share slicing». 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. Pour réduire le nombre de blocs indépendants chiffrés en parallèle, nous avons ensuite proposé l'ISE2 qui étend l'ISE1 pour masquer des implémentations m-slicing à des ordres $d \in \{1, 3, 7, 15\}$. De nouvelles implémentations m-slicing de AES ont été décrites permettant de chiffrer un bloc à la fois. Pour augmenter la sécurité apportée par le masquage, nous avons proposé l'ISE3 qui modifie l'ISE1 pour obtenir une sécurité dans le modèle de sondage 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. Pour terminer, nous avons proposé une solution de masquage matériel et logiciel flexible qui permet de masquer des implémentations BS à divers ordres élevés et variés sans changer le matériel. 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'ISE pour atteindre divers ordres supérieurs. Notre solution offre ainsi une flexibilité au moment de la synthèse, pour répondre à diverses contraintes de performance et de budget, et au moment de la compilation logicielle pour augmenter la sécurité au fil du temps. Notre solution de masquage matériel/logiciel a été l'objet de notre publication [LT23] dans la conférence MWSCAS.

Comme futurs travaux, d'autres cryptosystèmes symétriques peuvent être implémentés avec nos solutions. Nous envisageons également d'implémenter les chiffrements post-quantiques Kyber<fnref n="1" /> et Saber<fnref n="2" /> avec des adaptations de nos ISE dédiées au masquage en utilisant par exemple les implémentations BS développées dans [BC22]. Un autre axe d'étude est d'ajouter de nouvelles instructions masquées à nos ISE pour accélérer des cryptosystèmes spécifiques tel que AES.

<footnote n="1">1. https://pq-crystals.org/kyber/</footnote>

<footnote n="2">2. https://www.esat.kuleuven.be/cosic/pqcrypto/saber/</footnote>
<figure><img src="image_78.png" /></figure>
# Annexe A

## Conversion en représentation BS

L'algorithme de transposition de la figure 4.3 peut être amélioré [Knu98] en observant que la transposée d'une matrice peut s'écrire récursivement comme :

$$ \begin{bmatrix} A & B \\ C & D \end{bmatrix}^T = \begin{bmatrix} A^T & C^T \\ B^T & D^T \end{bmatrix} $$

jusqu'à obtenir des matrices de taille $2 \times 2$ (sur une matrice $32 \times 32$, cela prend 5 itérations). Cet algorithme effectue les opérations en même temps sur $A$ et $B$, et sur $C$ et $D$, réduisant le nombre d'opérations par rapport à l'algorithme de transposition simple. Cet algorithme est illustré par le code de la figure A.1.
```c
unsigned int mask_l[5] = { 0xaaaaaaaaa,
                          0xcccccccc,
                          0xf0f0f0f0,
                          0xff00ff00,
                          0xfafa0000
};

unsigned int mask_r[5] = { 0x55555555,
                          0x33333333,
                          0x0f0f0f0f,
                          0x00ff00ff,
                          0x0000ffff
};

void to_bitslice32x32(uint32_t data[]) {
    for (int i = 0; i < 5; i++) {
        int n = (1UL << i);
        for (int j = 0; j < 32; j += (2 * n)) {
            for (int k = 0; k < n; k++) {
                unsigned int u = data[j + k] & mask_r[i];
                unsigned int v = data[j + k] & mask_l[i];
                unsigned int x = data[j + n + k] & mask_r[i];
                unsigned int y = data[j + n + k] & mask_l[i];
                data[j + k] = u | (x << n);
                data[j + n + k] = (v >> n) | y;
            }
        }
    }
}
```

FIGURE A.1 – Code C de la transposition récursive de 32 blocs de 32 bits en représentation BS.
# Annexe B

## Codes d'implémentations *m*-slicing de
AES
```h
node SBOX (input:v8) returns (output: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}
```

```h
node SubBytes (inputSR:u16x8) returns (out:u16x8) let
    out[0..7]=SBOX(inputSR[0..7]); tel
```

```h
node ShiftRows (inputSR:u16x8) returns (out:u16x8) let
   forall i in [0,7] {
        out[i] = Shuffle(inputSR[i], [ 0,  1,  2,  3,
                                          5,  6,  7,  4,
                                          10, 11,  8,  9,
                                          15, 12, 13, 14])
    }
    tel
```

```h
node RL4 (input:u16) returns (out:u16) let
    out = input <<< 4; tel
```

```h
node RL8 (input:u16) returns (out:u16) let
    out = input <<< 8; tel
```

```h
node MixColumn (a:u16x8) returns (b:u16x8) let
    b[0]=a[1]^RL4(a[1])^RL4(a[0])^RL8(a[0]^RL4(a[0]));
    b[1]=a[2]^RL4(a[2])^RL4(a[1])^RL8(a[1]^RL4(a[1]));
    b[2]=a[3]^RL4(a[3])^RL4(a[2])^RL8(a[2]^RL4(a[2]));
    b[3]=a[4]^RL4(a[4])^a[0]^RL4(a[0])^RL4(a[3])^RL8(a[3]^RL4(a[3]));
    b[4]=a[5]^RL4(a[5])^a[0]^RL4(a[0])^RL4(a[4])^RL8(a[4]^RL4(a[4]));
    b[5]=a[6]^RL4(a[6])^RL4(a[5])^RL8(a[5]^RL4(a[5]));
    b[6]=a[7]^RL4(a[7])^a[0]^RL4(a[0])^RL4(a[6])^RL8(a[6]^RL4(a[6]));
    b[7]=a[0]^RL4(a[0])^RL4(a[7])^RL8(a[7]^RL4(a[7])); tel
```

```h
node AddRoundKey (i:u16x8, key:u16x8) returns (r:u16x8) let
    r = i ^ key; tel
```

```h
node AES128(plain:u16x8, key:u16x8[11]) returns (cipher:u16x8)
    vars tmp : u16x8[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 B.1 – Code Usuba de notre implémentation 16-slicing de AES.</caption>
```javascript
table SBOX (input:v8) returns (output: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 (inputSR:u8x16) returns (out:u8x16) let
out[0..7]=SBOX(inputSR[0..7]);
out[8..15]=SBOX(inputSR[8..15]); tel

node ShiftRows (inputSR:u8x16) returns (out:u8x16) let
forall i in [0,7] {
    out[i] = Shuffle(inputSR[i], [ 0, 1, 2, 3,
                                     6, 7, 4, 5 ] )}
forall i in [8,15] {
    out[i] = Shuffle(inputSR[i], [ 1, 2, 3, 0,
                                     7, 4, 5, 6 ] )
}
tel

node RL4 (input:u8) returns (out:u8) let
out = input <<< 4; tel

node MixColumn (a:u8x16) returns (b:u8x16) let
b[0]=a[1]^a[9]^a[8]^RL4(a[0])^RL4(a[8]);
b[1]=a[2]^a[10]^a[9]^RL4(a[1])^RL4(a[9]);
b[2]=a[3]^a[11]^a[10]^RL4(a[2])^RL4(a[10]);
b[3]=a[4]^a[12]^a[11]^RL4(a[3])^RL4(a[11])^a[0]^a[8];
b[4]=a[5]^a[13]^a[12]^RL4(a[4])^RL4(a[12])^a[0]^a[8];
b[5]=a[6]^a[14]^a[13]^RL4(a[5])^RL4(a[13]);
b[6]=a[7]^a[15]^a[14]^RL4(a[6])^RL4(a[14])^a[0]^a[8];
b[7]=a[0]^a[8]^a[15]^RL4(a[7])^RL4(a[15]);
b[8]=a[9]^RL4(a[1])^RL4(a[0])^RL4(a[8])^a[0];
b[9]=a[10]^RL4(a[2])^RL4(a[1])^RL4(a[9])^a[1];
b[10]=a[11]^RL4(a[3])^RL4(a[2])^RL4(a[10])^a[2];
b[11]=a[12]^RL4(a[4])^RL4(a[3])^RL4(a[11])^a[3]^a[8]^RL4(a[0]);
b[12]=a[13]^RL4(a[5])^RL4(a[4])^RL4(a[12])^a[4]^a[8]^RL4(a[0]);
b[13]=a[14]^RL4(a[6])^RL4(a[5])^RL4(a[13])^a[5];
b[14]=a[15]^RL4(a[7])^RL4(a[6])^RL4(a[14])^a[6]^a[8]^RL4(a[0]);
b[15]=a[8]^RL4(a[0])^RL4(a[7])^RL4(a[15])^a[7]; tel

node AddRoundKey (i:u8x16,key:u8x16) returns (r:u8x16) let
r = i ^ key; tel

node AES128(plain:u8x16,key:u8x16[11]) returns (cipher:u8x16)
vars tmp : u8x16[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 B.2 – Code Usuba de notre implémentation 8-slicing de AES.</caption>
```h
table SBOX (input:v8) returns (output: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}
```

```h
node SubBytes (inputSR:u4x32) returns (out:u4x32) let
    out[0..7]=SBOX(inputSR[0..7]);
    out[8..15]=SBOX(inputSR[8..15]);
    out[16..23]=SBOX(inputSR[16..23]);
    out[24..31]=SBOX(inputSR[24..31]); tel
```

```h
node ShiftRows (inputSR:u4x32) returns (out:u4x32) let
   forall i in [0,7] {
        out[i]=inputSR[i];
        out[i+8]=inputSR[i+8] << 1;
        out[i+16]=inputSR[i+16] << 2;
        out[i+24]=inputSR[i+24] << 3;
    } tel
```

```h
node MixColumn (a:u4x32) returns (b:u4x32) let
   forall i in [0,3] {
        b[i*8]=a[(i*8+1)%32]^a[(i*8+9)%32]^a[(i*8+8)%32]^a[(i*8+16)%32]^a[(i*8+24)%32];
        b[i*8+1]=a[(i*8+2)%32]^a[(i*8+10)%32]^a[(i*8+9)%32]^a[(i*8+17)%32]^a[(i*8+25)%32];
        b[i*8+2]=a[(i*8+3)%32]^a[(i*8+11)%32]^a[(i*8+10)%32]^a[(i*8+18)%32]^a[(i*8+26)%32];
        b[i*8+3]=a[(i*8+4)%32]^a[(i*8+12)%32]^a[(i*8+11)%32]^a[(i*8+19)%32]^a[(i*8+27)%32]^a[(i*8)%32]^a[(i*8+8)%32];
        b[i*8+4]=a[(i*8+5)%32]^a[(i*8+13)%32]^a[(i*8+12)%32]^a[(i*8+20)%32]^a[(i*8+28)%32]^a[(i*8)%32]^a[(i*8+8)%32];
        b[i*8+5]=a[(i*8+6)%32]^a[(i*8+14)%32]^a[(i*8+13)%32]^a[(i*8+21)%32]^a[(i*8+29)%32];
        b[i*8+6]=a[(i*8+7)%32]^a[(i*8+15)%32]^a[(i*8+14)%32]^a[(i*8+22)%32]^a[(i*8+30)%32]^a[(i*8)%32]^a[(i*8+8)%32];
        b[i*8+7]=a[(i*8)%32]^a[(i*8+8)%32]^a[(i*8+15)%32]^a[(i*8+23)%32]^a[(i*8+31)%32];
    } tel
```

```h
node AddRoundKey (i:u4x32, key:u4x32) returns (r:u4x32) let
    r = i ^ key; tel
```

```h
node AES128 (plain:u4x32, key:u4x32[11]) returns (cipher:u4x32)
```

```h
vars tmp : u4x32[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 B.3 – Code Usuba de notre implémentation 4-slicing de AES.</caption>
```h
node SBOX (input:v8) returns (output: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}
```

```h
node SubBytes (inputSR:u2x64) returns (out:u2x64) let
    out[0..7]=SBOX(inputSR[0..7]);
    out[8..15]=SBOX(inputSR[8..15]);
    out[16..23]=SBOX(inputSR[16..23]);
    out[24..31]=SBOX(inputSR[24..31]);
    out[32..39]=SBOX(inputSR[32..39]);
    out[40..47]=SBOX(inputSR[40..47]);
    out[48..55]=SBOX(inputSR[48..55]);
    out[56..63]=SBOX(inputSR[56..63]); tel
```

```h
node ShiftRows (inputSR:u2x64) returns (out:u2x64) let
   forall i in [0,7] {
        out[i]=inputSR[i];
        out[i+8]=inputSR[i+8];
        out[i+16]=inputSR[i+24];
        out[i+24]=inputSR[i+16]<<<1;
        out[i+32]=inputSR[i+32]<<<1;
        out[i+40]=inputSR[i+40]<<<1;
        out[i+48]=inputSR[i+56]<<<1;
        out[i+56]=inputSR[i+48];
    }
    tel
```

```h
node MixColumn (a:u2x64) returns (b:u2x64) let
   forall i in [0,7] {
        b[i*8]=a[(i*8+1)%64]^a[(i*8+17)%64]^a[(i*8+16)%64]^a[(i*8+32)%64]^a[(i*8+48)%64];
        b[i*8+1]=a[(i*8+2)%64]^a[(i*8+18)%64]^a[(i*8+17)%64]^a[(i*8+33)%64]^a[(i*8+49)%64];
        b[i*8+2]=a[(i*8+3)%64]^a[(i*8+19)%64]^a[(i*8+18)%64]^a[(i*8+34)%64]^a[(i*8+50)%64];
        b[i*8+3]=a[(i*8+4)%64]^a[(i*8+20)%64]^a[(i*8+19)%64]^a[(i*8+35)%64]^a[(i*8+51)%64]^a[(i*8)%64]^a[(i*8+16)%64];
        b[i*8+4]=a[(i*8+5)%64]^a[(i*8+21)%64]^a[(i*8+20)%64]^a[(i*8+36)%64]^a[(i*8+52)%64]^a[(i*8)%64]^a[(i*8+16)%64];
        b[i*8+5]=a[(i*8+6)%64]^a[(i*8+22)%64]^a[(i*8+21)%64]^a[(i*8+37)%64]^a[(i*8+53)%64];
        b[i*8+6]=a[(i*8+7)%64]^a[(i*8+23)%64]^a[(i*8+22)%64]^a[(i*8+38)%64]^a[(i*8+54)%64]^a[(i*8)%64]^a[(i*8+16)%64];
        b[i*8+7)=(a[(i*8)%64]^a[(i*8+16)%64])^a[(i*8+23)%64]^a[(i*8+39)%64]^a[(i*8+55)%64];
    }
    tel
```

```h
node AddRoundKey (i:u2x64, key:u2x64) returns (r:u2x64) let
    r = i ^ key; tel
```

```h
node AES128 (plain:u2x64, key:u2x64[11]) returns (cipher:u2x64)
    vars tmp : u2x64[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 B.4 – Code Usuba de notre implémentation 2-slicing de AES.</caption>
# Annexe C

## Preuves de sécurité du chapitre 10

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

*Démonstration.* Soit $\Omega = \mathcal{I} \cup \mathcal{O}$ un ensemble de bits sondés vérifiant $|\Omega| \le d$, ou $\mathcal{I}$ désigne les sondes internes et $\mathcal{O}$ les sondes de sortie.

Désignons par $\mathcal{I}_i$ les sondes internes dans l'instruction $\hat{z}[i] \leftarrow \text{ise1.xor}(\hat{\mathbf{x}}[i], \hat{\mathbf{y}}[i])$ et par $\mathcal{O}_i$ les sondes de sortie sur $\hat{z}[i]$. Si $|\mathcal{I}_i \cup \mathcal{O}_i| \le d_H$, alors comme $\text{ise1.xor}$ est $d_H$-NI dans le modèle de sondage robuste aux glitchs, les sondes $\mathcal{I}_i \cup \mathcal{O}_i$ peuvent être simulées par un ensemble de bits $\mathcal{X}_i$ de $\hat{\mathbf{x}}[i]$ vérifiant $|\mathcal{X}_i| \le |\mathcal{I}_i \cup \mathcal{O}_i|$ et un ensemble de bits $\mathcal{Y}_i$ de $\hat{\mathbf{y}}[i]$ vérifiant $|\mathcal{Y}_i| \le |\mathcal{I}_i \cup \mathcal{O}_i|$. Sinon, on a $|\mathcal{I}_i \cup \mathcal{O}_i| > d_H$ et les sondes $\mathcal{I}_i \cup \mathcal{O}_i$ peuvent être simulées par l'ensemble de bits $\mathcal{X}_i$ contenant les $d_H$ parts de $\hat{\mathbf{x}}[i]$ et l'ensemble de bits $\mathcal{Y}_i$ contenant les $d_H$ parts de $\hat{\mathbf{y}}[i]$. $\mathcal{X}_i$ et $\mathcal{Y}_i$ vérifie alors $|\mathcal{X}_i| \le d_H \le |\mathcal{I}_i \cup \mathcal{O}_i|$ et $|\mathcal{Y}_i| \le d_H \le |\mathcal{I}_i \cup \mathcal{O}_i|$.

On en déduit que l'ensemble des bits sondés $\Omega = \mathcal{I} \cup \mathcal{O}$ peut être simulé par l'ensemble de bits $\mathcal{X} = \cup_i \mathcal{X}_i$ de $\hat{\mathbf{x}}$ vérifiant $|\mathcal{X}| \le \sum_i |\mathcal{X}_i| \le \sum_i |\mathcal{I}_i \cup \mathcal{O}_i| \le |\Omega|$ et par l'ensemble de bits $\mathcal{Y} = \cup_i \mathcal{Y}_i$ de $\hat{\mathbf{y}}$ vérifiant $|\mathcal{Y}| \le \sum_i |\mathcal{X}_i| \le \sum_i |\mathcal{I}_i \cup \mathcal{O}_i| \le |\Omega|$. L'algorithme 10 est donc $d$-NI dans le modèle de sondage robuste aux glitchs. $\square$

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

*Démonstration.* Pour prouver la $d$-SNI de l'algorithme 12, nous construisons un simulateur. Soit $\Omega = \mathcal{I} \cup \mathcal{O}$ un ensemble d'au plus $d$ bits sondés dans l'implémentation, ou $\mathcal{I}$ désigne l'ensemble des sondes internes et $\mathcal{O}$ désigne l'ensemble des sondes de sortie. On note $t_i = |\mathcal{I}|$ et $t_o = |\mathcal{O}|$. Désignons par $\mathcal{I}_x$ les sondes internes dans l'instruction générant la variable $x$. Notre objectif est de déterminer un ensemble de bits $\mathcal{X}$ de $\hat{\mathbf{x}}$ vérifiant $|\mathcal{X}| \le t_i$ et un ensemble de bits $\mathcal{Y}$ de $\hat{\mathbf{y}}$ vérifiant $|\mathcal{Y}| \le t_i$, tel que l'ensemble des bits sondés $\Omega = \mathcal{I} \cup \mathcal{O}$ puisse être simulé par $\mathcal{X}$ et $\mathcal{Y}$.

Nous définissons dans un premier temps un ensemble $\mathcal{K}$ tel que les bits sondés $\mathcal{I}_{r_{i,j}}$, $\mathcal{I}_{u_{i,j}}$ et $\mathcal{I}_{v_{i,j}}$ puissent être simulés avec les ensembles de bits $\mathcal{A}_{i,j} = \{a_{i,j}[k], 0 \le k \le d_H\}$. Comme l'instruction $\text{ise1.xor}$ est $d_H$-NI et donc implémentée de façon directe, les seuls bits qui peuvent être sondés dans l'instruction $\text{ise1.xor}$ sont les bits d'entrées. Si $a_{i,j}[k]$, $u_{i,j}[k]$ ou $r_{i,j}[k]$ est sondé, on ajoute $(i, j, k)$ à $\mathcal{K}$. Si $v_{i,j}[k]$ avec $j < d_S$ est sondé, on ajoute $(i, i, k)$ à $\mathcal{K}$. L'ensemble $\mathcal{K}$ vérifie alors $|\mathcal{K}| \le \sum_{i,j} |\mathcal{I}_{r_{i,j}}| + |\mathcal{I}_{u_{i,j}}| + |\mathcal{I}_{v_{i,j}}|$.

Nous allons maintenant construire un ensemble de bits $\mathcal{X}$ de $\hat{\mathbf{x}}$ vérifiant $|\mathcal{X}| \le t_i$ et un ensemble de bits $\mathcal{Y}$ de $\hat{\mathbf{y}}$ vérifiant $|\mathcal{Y}| \le t_i$ tel que les bits $\mathcal{A}_{i,j}$ et $\mathcal{I}_{a_{i,j}}$ puissent être simulés
avec $\mathcal{X}$ et $\mathcal{Y}$. Comme l'instruction `ise1.and` est $d_{\text{H}}$-SNI, alors pour tout $0 \le i, j \le d_{\text{S}}$, les ensembles de bits $\mathcal{A}_{i,j}$ et $\mathcal{I}_{a_{i,j}}$ peuvent être simulés avec un ensemble de bits $\mathcal{X}_{i,j}$ de $\hat{\mathbf{x}}$ vérifiant $|\mathcal{X}_{i,j}| \le |\mathcal{I}_{a_{i,j}}| + |\mathcal{A}_{i,j}|$ et un ensemble de bits $\mathcal{Y}_{i,j}$ de $\hat{\mathbf{y}}$ vérifiant $|\mathcal{Y}_{i,j}| \le |\mathcal{I}_{a_{i,j}}| + |\mathcal{A}_{i,j}|$. L'ensemble $\mathcal{X} = \cup_{i,j} \mathcal{X}_{i,j}$ vérifie alors $|\mathcal{X}| \le \sum_{i,j} |\mathcal{X}_{i,j}| \le |\mathcal{I}_{a_{i,j}}| + |\mathcal{A}_{i,j}| \le \sum_{i,j} |\mathcal{I}_{a_{i,j}}| + |\mathcal{I}_{r_{i,j}}| + \mathcal{I}_{u_{i,j}} + \mathcal{I}_{v_{i,j}} \le t_i$. De même, l'ensemble $\mathcal{Y} = \cup_{i,j} \mathcal{Y}_{i,j}$ vérifie $|\mathcal{Y}| \le t_i$.

Nous vérifions à présent que les ensembles de bits $\mathcal{X}$ et $\mathcal{Y}$ permettent de simuler l'ensemble des bits sondés $\Omega = \mathcal{I} \cup \mathcal{O}$. Par construction, les ensembles de bits $\mathcal{A}_{i,j}$ et $\mathcal{I}_{a_{i,j}}$ peuvent être simulés avec les ensembles de bits $\mathcal{X}$ et $\mathcal{Y}$. Nous attribuons une valeur aléatoire à chaque $r_{i,j}[k]$ entrant dans le calcul de n'importe quel bit sondé. Le bit sondé $u_{i,j}[k]$ peut être simulé avec $a_{i,j}[k] \in \mathcal{K}$. Supposons maintenant que $v_{i,j}[k]$ soit sondé. $v_{i,j}[k]$ est la somme de $u_{i,J}[k]$ pour $0 \le J \le j$. Si $(i, J, k) \in \mathcal{K}$, alors $u_{i,J}[k]$ peut être simulé en utilisant $a_{i,J}[k]$. Autrement, le calcul de $u_{i,J}[k]$ utilise le bit aléatoire $r_{i,J}[k]$ si $i < J$ ou $r_{J,i}[k]$ si $i > J$ qui n'entre dans le calcul d'aucun autre bit sondé. Une valeur aléatoire peut donc être attribuée à $u_{i,J}[k]$. $\square$

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

*Démonstration.* Soit $\mathcal{I}$ un ensemble de $t_{\text{int}}$ sondes internes et $\mathcal{O}$ un ensemble de $t_{\text{out}}$ sondes de sortie, tel que $t_{\text{int}} + t_{\text{out}} \le d$. Déterminons un ensemble $\mathcal{A}$ d'au plus $t_{\text{int}}$ indices de parts tels que l'ensemble de sondes $\mathcal{I} \cup \mathcal{O}$ puisse être simulé avec les parts d'entrée dont les indices sont $\mathcal{A} \cup \text{Ind}(\mathcal{O})$, où $\text{Ind}(\cdot)$ désigne les indices des parts d'un ensemble de sonde. Désignons par $\mathcal{I}_i$ les sondes internes dans l'instruction $\hat{z}[i] \leftarrow \text{ise1.xor}(\hat{\mathbf{x}}[i], \hat{\mathbf{y}}[i])$ et par $\mathcal{O}_i$ les sondes de sortie sur $\hat{z}[i]$. Comme `ise1.xor` est $d_{\text{H}}$-PINI dans le modèle de sondage robuste aux glitches, il existe un ensemble d'indices de parts $\mathcal{A}_i$ vérifiant $|\mathcal{A}_i| \le |\mathcal{I}_i|$ tel que l'ensemble de sondes $\mathcal{I}_i \cup \mathcal{O}_i$ puisse être simulé avec les parts d'entrée dont les indices sont $\mathcal{A}_i \cup \text{Ind}(\mathcal{O})$. On en déduit que l'ensemble des bits sondés $\Omega = \mathcal{I} \cup \mathcal{O}$ peut être simulé par l'ensemble des parts d'entrée dont les indices sont $\mathcal{A} \cup \text{Ind}(\mathcal{O})$ avec $\mathcal{A} = \cup_i \mathcal{A}$ et vérifie $|\mathcal{A}| \le \sum_i |\mathcal{A}_i| \le \sum_i |\mathcal{I}_i| \le t_{\text{int}}$. L'algorithme 10 est donc d-PINI dans le modèle de sondage robuste aux glitches. $\square$

## C.4 Preuve de la propriété 5

*Démonstration.* Soit $\mathcal{I}$ un ensemble de $t_i$ sondes internes et $\mathcal{O}$ un ensemble de $t_o$ indices de parts de sortie, tels que $t_i + t_o \le d$.

Désignons par $\mathcal{I}_i$ l'ensemble des sondes internes dans la i-ième instruction masquée de l'algorithme 13. Comme l'instruction est $d_{\text{H}}$-PINI, alors l'ensemble de sonde $\mathcal{I}_i$ peut être simulé par l'ensemble des parts matérielles d'indices $\mathcal{X}_i$ dans les entrées de l'instruction, avec $|\mathcal{X}_i| \le |\mathcal{I}_i|$. D'après la propriété PINI, il est équivalent de sonder $\mathcal{I}_i$ ou les parts matérielles d'indices $\mathcal{X}_i$ dans la sortie de l'instruction.

Simulons maintenant l'ensemble des parts de sortie d'indices $\mathcal{O}$, et les ensembles de parts d'indices $\mathcal{X}_i$ dans la variable de sortie de la i-ième instruction masquée. Soit $0 \le k \le d_{\text{H}}$. Désignons par $\mathcal{Y}_k$ l'ensemble des parts matérielles sondées d'indices $k$. Si $|\mathcal{Y}_k| \le d_{\text{S}}$, alors il existe un ensemble $\mathcal{A}_k$ vérifiant $|\mathcal{A}_k| \le |\mathcal{Y}_k|$ tel que $\mathcal{Y}_k$ puisse être simulé par les parts d'entrée d'indices dans $\mathcal{A}_k$. On en déduit que l'ensemble des parts sondées peuvent être simulé par les parts d'entrée d'indices $\cup_{0 \le k \le d_{\text{H}}} \mathcal{A}_k$ vérifiant $|\cup_{0 \le k \le d_{\text{H}}} \mathcal{A}_k| \le \sum_{0 \le k \le d_{\text{H}}} |\mathcal{Y}_k| \le t_i + t_o \le d$. $\square$
<figure><img src="image_79.png" /></figure>
Bibliographie

[ADF16] Marcin ANDRYCHOWICZ, Stefan DZIEMBOWSKI et Sebastian FAUST. "Circuit Com-
pilers with $O(1/\log(n))$ Leakage Rate". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, mai 2016, p. 586-615. DOI: 10.1007/978-3-662-49896-5_21.

[AKS07] Onur ACHİÇMEZ, Çetin Kaya KOÇ et Jean-Pierre SEIFERT. "Predicting Secret Keys Via Branch Prediction". In: *Proc. Cryptographers' Track RSA Conference (CT-RSA)*. Springer, fév. 2007, p. 236-249. DOI: 10.1007/11967668_15.

[AP20] Alexandre ADOMNICAI et Thomas PEYRIN. "Fixslicing AES-like Ciphers : New bitsliced AES speed records on ARM-Cortex M and RISC-V". In : *Transactions on CHES* (déc. 2020), p. 402-425. DOI: 10.46586/tches.v2021.i1.402-425.

[Bal+14] Josep BALASCH et al. "On the Cost of Lazy Engineering for Masked Software Implementations". In: *Proc. International Conference on Smart Card Research and Advanced Applications (CARDIS)*. Springer, nov. 2014, p. 64-81. DOI: 10.1007/978-3-319-16763-3_5.

[Bal+15] Josep BALASCH et al. "DPA, Bitslicing and Masking at 1 GHz". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2015, p. 599-619. DOI: 10.1007/978-3-662-48324-4_30.

[Bar+15] Gilles BARTHE et al. "Verified Proofs of Higher-Order Masking". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, avr. 2015, p. 457-485. DOI: 10.1007/978-3-662-46800-5_18.

[Bar+16] Gilles BARTHE et al. "Strong Non-Interference and Type-Directed Higher-Order Masking". In: *Proc. Conference on Computer and Communications Security (CCS)*. ACM, oct. 2016, p. 116-129. DOI: 10.1145/2976749.2978427.

[Bar+17] Gilles BARTHE et al. "Parallel Implementations of Masking Schemes and the Bounded Moment Leakage Model". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, avr. 2017, p. 535-566. DOI: 10.1007/978-3-319-56620-7_19.

[Bar+19a] Gilles BARTHE et al. "Improved parallel mask refreshing algorithms : generic solutions with parametrized non-interference and automated optimizations". In: *Journal of Cryptographic Engineering (JCEN)* (jan. 2019), p. 17-26. DOI: 10.1007/s13389-018-00202-2.
[Bar+19b] Gilles BARTHE et al. "maskVerif: Automated Verification of Higher-Order Masking in Presence of Physical Defaults". In: *Proc. European Symposium on Research in Computer Security (ESORICS)*. Springer, sept. 2019, p. 300-318. DOI: 10.1007/978-3-030-29959-0_15.

[Bat+16] Alberto BATTISTELLO et al. "Horizontal Side-Channel Attacks and Countermeasures on the ISW Masking Scheme". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2016, p. 23-39. DOI: 10.1007/978-3-662-53140-2_2.

[BBT10] Lyonel BARTHE, Pascal BENOIT et Lionel TORRES. "Investigation of a Masking Countermeasure against Side-Channel Attacks for RISC-based Processor Architectures". In: *Proc. International Conference on Field Programmable Logic and Applications (FPL)*. IEEE, août 2010, p. 139-144. DOI: 10.1109/FPL.2010.35.

[BC22] Olivier BRONCHAIN et Gaëtan CASSIERS. "Bitslicing Arithmetic/Boolean Masking Conversions for Fun and Profit with Application to Lattice-Based KEMs". In: *Transactions on CHES* (août 2022), p. 553-588. DOI: 10.46586/tches.v2022.i4.553-588.

[BCO04] Eric BRIER, Christophe CLAVIER et Francis OLIVIER. "Correlation Power Analysis with a Leakage Model". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2004, p. 16-29. DOI: 10.1007/978-3-540-28632-5_2.

[Bel+16] Sonia BELAÏD et al. "Randomness Complexity of Private Circuits for Multiplication". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, mai 2016, p. 616-648. DOI: 10.1007/978-3-662-49896-5_22.

[Bel+17] Sonia BELAÏD et al. "Private Multiplication over Finite Fields". In: *Proc. Annual Cryptology Conference (CRYPTO)*. Springer, août 2017, p. 397-426. DOI: 10.1007/978-3-319-63697-9_14.

[Bel+20] Sonia BELAÏD et al. "Tornado: Automatic Generation of Probing-Secure Masked Bitsliced Implementations". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, mai 2020, p. 311-341. DOI: 10.1007/978-3-030-45727-3_11.

[Ber+02] Guido BERTONI et al. "Efficient Software Implementation of AES on 32-Bit Platforms". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2002, p. 159-171. DOI: 10.1007/3-540-36400-5_13.

[Ber+10] Guido BERTONI et al. "Sponge-Based Pseudo-Random Number Generators". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2010, p. 33-47. DOI: 10.1007/978-3-642-15031-9_3.

[Ber05] Daniel J. BERNSTEIN. *Cache-timing attacks on AES*. 2005. URL: https://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
[BGR18] Sonia BELAÏD, Dahmun GOUDARZI et Matthieu RIVAIN. "Tight Private Circuits : Achieving Probing Security with the Least Refreshing". In : *Proc. International Conference on the Theory and Application of Cryptology and Information Security (ASIACRYPT)*. Springer, déc. 2018, p. 343-372. DOI : 10.1007/978-3-030-03329-3_12.

[BGW88] Michael BEN-OR, Shafi GOLDWASSER et Avi WIGDERSON. "Completeness Theorems for Non-Cryptographic Fault-Tolerant Distributed Computation". In : *Proc. Symposium on Theory of computing (STOC)*. ACM, jan. 1988, p. 1-10. DOI : 10.1145/62212.62213.

[Bih97] Eli BIHAM. "A fast new DES implementation in software". In : *Proc. Fast Software Encryption (FSE)*. Springer, jan. 1997, p. 260-272. DOI : 10.1007/BFb0052352.

[Bil+14a] Begül BILGIN et al. "A More Efficient AES Threshold Implementation". In : *Proc. International Conference on Cryptology in Africa (AFRICACRYPT)*. Springer, mai 2014, p. 267-284. DOI : 10.1007/978-3-319-06734-6_17.

[Bil+14b] Begül BILGIN et al. "Higher-Order Threshold Implementations". In : *Proc. International Conference on the Theory and Application of Cryptology and Information Security (ASIACRYPT)*. Springer, déc. 2014, p. 326-343. DOI : 10.1007/978-3-662-45608-8_18.

[BM06] Joseph BONNEAU et Ilya MIRONOV. "Cache-Collision Timing Attacks Against AES". In : *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, oct. 2006, p. 201-215. DOI : 10.1007/11894063_16.

[BP12] Joan BOYAR et René PERALTA. "A Small Depth-16 Circuit for the AES S-Box". In : *Proc. International Information Security Conference (SEC)*. Springer, juin 2012, p. 287-298. DOI : 10.1007/978-3-642-30436-1_24.

[BS12] Daniel J. BERNSTEIN et Peter SCHWABE. "NEON Crypto". In : *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2012, p. 320-339. DOI : 10.1007/978-3-642-33027-8_19.

[BS21] Olivier BRONCHAIN et François-Xavier STANDAERT. "Breaking Masked Implementations with Many Shares on 32-bit Software Platforms". In : *Transactions on CHES* (juill. 2021), p. 202-234. DOI : 10.46586/tches.v2021.i3.202-234.

[BS91] Eli BIHAM et Adi SHAMIR. "Differential cryptanalysis of DES-like cryptosystems". In : *Journal of Cryptology (JoC)* (jan. 1991), p. 3-72. DOI : 10.1007/BF00630563.

[BS97] Eli BIHAM et Adi SHAMIR. "Differential fault analysis of secret key cryptosystems". In : *Proc. Annual Cryptology Conference (CRYPTO)*. Springer, août 1997, p. 513-525. DOI : 10.1007/BFb0052259.

[Buc+06] Marco BUCCI et al. "Three-Phase Dual-Rail Pre-charge Logic". In : *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2006, p. 232-241. DOI : 10.1007/11894063_19.

[Can05] David CANRIGHT. "A Very Compact S-Box for AES". In : *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2005, p. 441-455. DOI : 10.1007/11545262_32.
[Cas+20] Gaëtan CASSIERS et al. "Hardware Private Circuits: From Trivial Composition to Full Verification". In: *IEEE Transactions on Computers* (sept. 2020), p. 1677-1690.
DOI: 10.1109/TC.2020.3022979.

[Cha+99] Suresh CHARI et al. "Towards Sound Approaches to Counteract Power-Analysis Attacks". In: *Proc. Annual Cryptology Conference (CRYPTO)*. Springer, août 1999, p. 398-412. DOI: 10.1007/3-540-48405-1_26.

[CK09] Jean-Sébastien CORON et Ilya KIZHVATOV. "An Efficient Method for Random Delay Generation in Embedded Software". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2009, p. 156-170. DOI: 10.1007/978-3-642-04138-9_12.

[Cla+11] Christophe CLAVIER et al. "Square Always Exponentiation". In: *Proc. International Conference on Cryptology in India (INDOCRYPT)*. Springer, déc. 2011, p. 40-57. DOI: 10.1007/978-3-642-25578-6_5.

[Cnu+16] Thomas de CNUDDE et al. "Masking AES with $d + 1$ Shares in Hardware". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2016, p. 194-212. DOI: 10.1007/978-3-662-53140-2_10.

[Coo+13] Jeremy COOPER et al. *Test vector leakage assessment (TVLA) methodology in practice*. 2013. URL: http://icmc-2013.org/wp/wp-content/uploads/2013/09/RohatgiTest-Vector-Leakage-Assessment.pdf.

[Cor+12] Jean-Sébastien CORON et al. "Conversion of Security Proofs from One Leakage Model to Another: A New Issue". In: *Proc. International Workshop on Constructive Side-Channel Analysis and Secure Design (COSADE)*. Springer, mai 2012, p. 69-81. DOI: 10.1007/978-3-642-29912-4_6.

[Cor+14] Jean-Sébastien CORON et al. "Higher-Order Side Channel Security and Mask Refreshing". In: *Proc. Fast Software Encryption (FSE)*. Springer, mars 2014, p. 410-424. DOI: 10.1007/978-3-662-43933-3_21.

[Cor+16] Jean-Sébastien CORON et al. "Faster Evaluation of SBoxes via Common Shares". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2016, p. 498-514. DOI: 10.1007/978-3-662-53140-2_24.

[Cor14] Jean-Sébastien CORON. "Higher Order Masking of Look-Up Tables". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, mai 2014, p. 441-458. DOI: 10.1007/978-3-642-55220-5_25.

[CRZ18] Jean-Sébastien CORON, Franck RONDEPIERRE et Rina ZEITOUN. "High Order Masking of Look-up Tables with Common Shares". In: *Transactions on CHES* (fév. 2018), p. 40-72. DOI: 10.13154/tches.v2018.i1.40-72.

[CS20] Gaëtan CASSIERS et François-Xavier STANDAERT. "Trivially and Efficiently Composing Masked Gadgets With Probe Isolating Non-Interference". In: *Transactions on Information Forensics and Security (TIFS)* (fév. 2020), p. 2542-2555. DOI: 10.1109/TIFS.2020.2971153.
[CS21] Gaëtan CASSIERS et François-Xavier STANDAERT. "Provably Secure Hardware Masking in the Transition- and Glitch-Robust Probing Model : Better Safe than Sorry". In : *Transactions on CHES* (fév. 2021), p. 136-158. DOI : 10.46586/tches.v2021.i2.136-158.

[DDF14] Alexandre DUC, Stefan DZIEMBOWSKI et Sebastian FAUST. "Unifying Leakage Models : From Probing Attacks to Noisy Leakage". In : *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, mai 2014, p. 423-440. DOI : 10.1007/978-3-642-55220-5_24.

[De +15] Thomas DE CNUDDE et al. "Higher-Order Threshold Implementation of the AES S-Box". In : *Proc. International Conference on Smart Card Research and Advanced Applications (CARDIS)*. Springer, nov. 2015, p. 259-272. DOI : 10.1007/978-3-319-31271-2_16.

[De +17] Thomas DE CNUDDE et al. "Does Coupling Affect the Security of Masked Implementations?". In : *Proc. International Workshop on Constructive Side-Channel Analysis and Secure Design (COSADE)*. Springer, avr. 2017, p. 1-18. DOI : 10.1007/978-3-319-64647-3_1.

[DGH19] Elke DE MULDER, Samatha GUMMALLA et Michael HUTTER. "Protecting RISC-V against Side-Channel Attacks". In : *Proc. Design Automation Conference (DAC)*. ACM, juin 2019, p. 1-4. DOI : 10.1145/3316781.3323485.

[DH76] Whitfield DIFFIE et Martin HELLMAN. "New directions in cryptography". In : *Transactions on Information Theory* (nov. 1976), p. 644-654. DOI : 10.1109/TIT.1976.1055638.

[Dhe+98] Jean-François DHEM et al. "A Practical Implementation of the Timing Attack". In : *Proc. International Conference on Smart Card Research and Advanced Applications (CARDIS)*. Springer, sept. 1998, p. 167-182. DOI : 10.1007/10721064_15.

[DR02] Joan DAEMEN et Vincent RIJMEN. *The Design of Rijndael*. 1re éd. Springer, 2002. ISBN : 978-3-540-42580-9. DOI : 10.1007/978-3-662-04722-4.

[Fau+18] Sebastian FAUST et al. "Composable Masking Schemes in the Presence of Physical Defaults & the Robust Probing Model". In : *Transactions on CHES* (août 2018), p. 89-120. DOI : 10.13154/tches.v2018.i3.89-120.

[Fri72] Jeffrey FRIEDMAN. *TEMPEST : A Signal Problem*. National Security Agency. 1972. URL : https://www.nsa.gov/portals/75/documents/news-features/declassified-documents/cryptologic-spectrum/tempest.pdf.

[Gao+19] Si GAO et al. "Share-slicing : Friend or Foe?". In : *Transactions on CHES* (nov. 2019), p. 152-174. DOI : 10.13154/tches.v2020.i1.152-174.

[Gao+21] Si GAO et al. "An Instruction Set Extension to Support Software-Based Masking". In : *Transactions on CHES* (août 2021), p. 283-325. DOI : 10.46586/tches.v2021.i4.283-325.

[GBT07] Benedikt GIERLICHS, Lejla BATINA et Pim TUYLS. *Mutual Information Analysis – A Universal Differential Side-Channel Attack*. IACR Cryptology ePrint Archive. Jan. 2007. URL : https://eprint.iacr.org/2007/198.
[GIB18] Hannes GROSS, Rinat IUSUPOV et Roderick BLOEM. "Generic Low-Latency Masking in Hardware". In: *Transactions on CHES* (mai 2018), p. 1-21. DOI: 10.13154/tches.v2018.i2.1-21.

[GM17] Hannes GROSS et Stefan MANGARD. "Reconciling $d + 1$ Masking in Hardware and Software". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2017, p. 115-136. DOI: 10.1007/978-3-319-66787-4_6.

[GM18] Hannes GROSS et Stefan MANGARD. "A unified masking approach". In: *Journal of Cryptographic Engineering (JCEN)* (mars 2018), p. 109-124. DOI: 10.1007/s13389-018-0184-y.

[GMK16] Hannes GROSS, Stefan MANGARD et Thomas KORAK. *Domain-Oriented Masking: Compact Masked Hardware Implementations with Arbitrary Protection Order*. IACR Cryptology ePrint Archive. Nov. 2016. URL: https://eprint.iacr.org/2016/486.

[GMK17] Hannes GROSS, Stefan MANGARD et Thomas KORAK. "An Efficient Side-Channel Protected AES Implementation with Arbitrary Protection Order". In: *Proc. Cryptographers' Track RSA Conference (CT-RSA)*. Springer, fév. 2017, p. 95-112. DOI: 10.1007/978-3-319-52153-4_6.

[GMO01] Karine GANDOLFI, Christophe MOURTEL et Francis OLIVIER. "Electromagnetic Analysis: Concrete Results". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, mai 2001, p. 251-261. DOI: 10.1007/3-540-44709-1_21.

[Gou+18] Dahmun GOUDARZI et al. "Secure Multiplication for Bitslice Higher-Order Masking: Optimisation and Comparison". In: *Proc. International Workshop on Constructive Side-Channel Analysis and Secure Design (COSADE)*. Springer, avr. 2018, p. 3-22. DOI: 10.1007/978-3-319-89641-0_1.

[GP99] Louis GOUBIN et Jacques PATARIN. "DES and Differential Power Analysis The Duplication Method". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 1999, p. 158-172. DOI: 10.1007/3-540-48059-5_15.

[GR17] Dahmun GOUDARZI et Matthieu RIVAIN. "How Fast Can Higher-Order Masking Be in Software?". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, avr. 2017, p. 567-597. DOI: 10.1007/978-3-319-56620-7_20.

[Gré+18] Benjamin GRÉGOIRE et al. "Vectorizing Higher-Order Masking". In: *Proc. International Workshop on Constructive Side-Channel Analysis and Secure Design (COSADE)*. Springer, avr. 2018, p. 23-43. DOI: 10.1007/978-3-319-89641-0_2.

[Gro+15] Vincent GROSSO et al. "LS-Designs: Bitslice Encryption for Efficient Masked Software Implementations". In: *Proc. Fast Software Encryption (FSE)*. Springer, mars 2015, p. 18-37. DOI: 10.1007/978-3-662-46706-0_2.
[Gro+16] Hannes GROSS et al. "Concealing Secrets in Embedded Processors Designs". In : *Proc. International Conference on Smart Card Research and Advanced Applications (CARDIS)*. Springer, nov. 2016, p. 89-104. DOI : 10.1007/978-3-319-54669-8_6.

[GST14] Daniel GENKIN, Adi SHAMIR et Eran TROMER. "RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis". In : *Proc. Annual Cryptology Conference (CRYPTO)*. Springer, août 2014, p. 444-461. DOI : 10.1007/978-3-662-44371-2_25.

[Guo+20] Qian GUO et al. "Modeling Soft Analytical Side-Channel Attacks from a Coding Theory Viewpoint". In : *Transactions on CHES* (août 2020), p. 209-238. DOI : 10.13154/tches.v2020.i4.209-238.

[GYH18] Qian GE, Yuval YAROM et Gernot HEISER. "No Security Without Time Protection : We Need a New Hardware-Software Contract". In : *Proc. Asia-Pacific Workshop on Systems (APSys)*. ACM, août 2018, p. 1-9. DOI : 10.1145/3265723.3265724.

[HH98] Helena HANDSCHUH et Howard M. HEYS. "A Timing Attack on RC5". In : *Proc. Selected Areas in Cryptography (SAC)*. Springer, août 1998, p. 306-318. URL : https://dl.acm.org/doi/10.5555/646554.694436.

[HS13] Michael HUTTER et Jörn-Marc SCHMIDT. "The Temperature Side Channel and Heating Fault Attacks". In : *Proc. International Conference on Smart Card Research and Advanced Applications (CARDIS)*. Springer, nov. 2013, p. 219-235. DOI : 10.1007/978-3-319-08302-5_15.

[ISW03] Yuval ISHAI, Amit SAHAI et David WAGNER. "Private Circuits : Securing Hardware against Probing Attacks". In : *Proc. Annual Cryptology Conference (CRYPTO)*. Springer, août 2003, p. 463-481. DOI : 10.1007/978-3-540-45146-4_27.

[JS17] Anthony JOURNAULT et François-Xavier STANDAERT. "Very High Order Masking : Efficient Implementation and Security Evaluation". In : *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2017, p. 623-643. DOI : 10.1007/978-3-319-66787-4_30.

[Ker83] Auguste KERCKHOFFS. "La cryptographie militaire". In : *Journal des Sciences Militaires* (jan. 1883), p. 161-191. URL : https://www.petitcolas.net/kerckhoffs/crypto_militaire_1.pdf.

[Kia+21] Pantea KIAEI et al. "Custom Instruction Support for Modular Defense Against Side-Channel and Fault Attacks". In : *Proc. International Workshop on Constructive Side-Channel Analysis and Secure Design (COSADE)*. Springer, avr. 2021, p. 221-253. DOI : 10.1007/978-3-030-68773-1_11.

[KJJ99] Paul KOCHER, Joshua JAFFE et Benjamin JUN. "Differential Power Analysis". In : *Proc. Annual Cryptology Conference (CRYPTO)*. Springer, août 1999, p. 388-397. DOI : 10.1007/3-540-48405-1_25.

[KM22] David KNICHEL et Amir MORADI. "Low-Latency Hardware Private Circuits". In : *Proc. Conference on Computer and Communications Security (CCS)*. ACM, nov. 2022, p. 1799-1812. DOI : 10.1145/3548606.3559362.
[Knu98] Donald E. KNUTH. *The Art of Computer Programming, Volume 3 : Sorting and Searching*. 2ᵉ éd. Addison Wesley Longman Publishing Co., 1998. ISBN : 978-0-201-89685-5. DOI : 10.1007/978-0-387-38162-6.

[Koc+11] Paul KOCHER et al. "Introduction to differential power analysis". In: *Journal of Cryptographic Engineering (JCEN)* (mars 2011), p. 5-27. DOI: 10.1007/s13389-011-0006-y.

[Koc96] Paul C. KOCHER. "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems". In: *Proc. Annual Cryptology Conference (CRYPTO)*. Springer, août 1996, p. 104-113. DOI: 10.1007/3-540-68697-5_9.

[Kön08] Robert KÖNIGHOFER. "A Fast and Cache-Timing Resistant Implementation of the AES". In: *Proc. Cryptographers' Track RSA Conference (CT-RSA)*. Springer, avr. 2008, p. 187-202. DOI: 10.1007/978-3-540-79263-5_12.

[Krä+13] Juliane KRÄMER et al. "Differential Photonic Emission Analysis". In: *Proc. International Workshop on Constructive Side-Channel Analysis and Secure Design (COSADE)*. Springer, mars 2013, p. 1-16. DOI: 10.1007/978-3-642-40026-1_1.

[KS09] Emilia KÄSPER et Peter SCHWABE. "Faster and Timing-Attack Resistant AES-GCM". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2009, p. 1-17. DOI: 10.1007/978-3-642-04138-9_1.

[KSM20] David KNICHEL, Pascal SASDRICH et Amir MORADI. "SILVER – Statistical In-dependence and Leakage Verification". In: *Proc. International Conference on the Theory and Application of Cryptology and Information Security (ASIACRYPT)*. Springer, déc. 2020, p. 787-816. DOI: 10.1007/978-3-030-64837-4_26.

[KSM21] David KNICHEL, Pascal SASDRICH et Amir MORADI. "Generic Hardware Private Circuits : Towards Automated Generation of Composable Secure Gadgets". In: *Transactions on CHES* (nov. 2021), p. 323-344. DOI: 10.46586/tches.v2022.i1.323-344.

[LT23] Fabrice LOZACHMEUR et Arnaud TISSERAND. "A RISC-V Instruction Set Exten-sion for Flexible Hardware/Software Protection of Cryptosystems Masked at High Orders". In: *Proc. International Midwest Symposium on Circuits and Systems (MWSCAS)*. Phoenix, Arizona, USA : IEEE, août 2023. URL: https://www.mwscas2023.org/.

[Mar+20] Ben MARSHALL et al. "The design of scalar AES Instruction Set Extensions for RISC-V". In: *Transactions on CHES* (déc. 2020), p. 109-136. DOI: 10.46586/tches.v2021.i1.109-136.

[Mat93] Mitsuru MATSUI. "Linear Cryptanalysis Method for DES Cipher". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, mai 1993, p. 386-397. DOI: 10.1007/3-540-48285-7_33.

[MD19] Darius MERCADIER et Pierre-Evariste DAGAND. "Usuba : High-Throughput and Constant-Time Ciphers, by Construction". In: *Proc. Conference on Programming Language Design and Implementation (PLDI)*. ACM, juin 2019, p. 157-173. DOI: 10.1145/3314221.3314636.
[MDP19] Loïc MASURE, Cécile DUMAS et Emmanuel PROUFF. "A Comprehensive Study of Deep Learning for Side-Channel Analysis". In: *Transactions on CHES* (nov. 2019), p. 348-375. DOI: 10.13154/tches.v2020.i1.348-375.

[MDS99] Thomas S. MESSERGES, Ezzy A. DABBISH et Robert H. SLOAN. "Investigations of Power Analysis Attacks on Smartcards". In: *Proc. Workshop on Smartcard Technology (WOST)*. Usenix, mai 1999, p. 17. URL: https://dl.acm.org/doi/10.5555/1267115.1267132.

[Mes00a] Thomas S. MESSERGES. "Securing the AES Finalists Against Power Analysis Attacks". In: *Proc. Fast Software Encryption (FSE)*. Springer, avr. 2000, p. 150-164. DOI: 10.1007/3-540-44706-7_11.

[Mes00b] Thomas S. MESSERGES. "Using Second-Order Power Analysis to Attack DPA Resistant Software". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2000, p. 238-251. DOI: 10.1007/3-540-44499-8_19.

[Moo+19] Thorben MOOS et al. "Glitch-Resistant Masking Revisited: or Why Proofs in the Robust Probing Model are Needed". In: *Transactions on CHES* (fév. 2019), p. 256-292. DOI: 10.13154/tches.v2019.i2.256-292.

[MOP07] Stefan MANGARD, Elisabeth OSWALD et Thomas POPP. *Power Analysis Attacks: Revealing the Secrets of Smart Cards*. 1re éd. Springer, 2007. ISBN: 978-0-387-38162-6. DOI: 10.1007/978-0-387-38162-6.

[Mor+11] Amir MORADI et al. "Pushing the Limits: A Very Compact and a Threshold Implementation of AES". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, mai 2011, p. 69-88. DOI: 10.1007/978-3-642-20465-4_6.

[MP21] Ben MARSHALL et Dan PAGE. *SME: Scalable Masking Extensions*. IACR Cryptology ePrint Archive. Oct. 2021. URL: https://eprint.iacr.org/2021/1416.

[MPG05] Stefan MANGARD, Thomas POPP et Berndt M. GAMMEL. "Side-Channel Leakage of Masked CMOS Gates". In: *Proc. Cryptographers' Track RSA Conference (CT-RSA)*. Springer, fév. 2005, p. 351-365. DOI: 10.1007/978-3-540-30574-3_24.

[MPO05] Stefan MANGARD, Norbert PRAMSTALLER et Elisabeth OSWALD. "Successfully Attacking Masked AES Hardware Implementations". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2005, p. 157-171. DOI: 10.1007/11545262_12.

[MPZ21] Maria Chiara MOLTENI, Jürgen PULKUS et Vittorio ZACCARIA. "On robust strong-non-interferent low-latency multiplications". In: *IET Information Security* (nov. 2021), p. 127-132. DOI: 10.1049/ise2.12048.

[MS06] Stefan MANGARD et Kai SCHRAMM. "Pinpointing the Side-Channel Leakage of Masked AES Hardware Implementations". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, oct. 2006, p. 76-90. DOI: 10.1007/11894063_7.
[Nak+11] Daisuke NAKATSU et al. "Combination of SW Countermeasure and CPU Modification on FPGA against Power Analysis". In: *Proc. World Conference on Information Security Applications (WISA)*. Springer, août 2011, p. 258-272. DOI: 10.1007/978-3-642-17955-6_19.

[NIS01] NIST. "Advanced Encryption Standard (AES)". In: *Federal Information Processing Standards Publications (FIPS PUBS)*. Nov. 2001. URL: https://csrc.nist.gov/publications/detail/fips/197/final.

[NRR06] Svetla NIKOVA, Christian RECHBERGER et Vincent RIJMEN. "Threshold Implementations Against Side-Channel Attacks and Glitches". In: *Proc. International Conference on Information and Communications Security (ICICS)*. Springer, déc. 2006, p. 529-545. DOI: 10.1007/11935308_38.

[NRS11] Svetla NIKOVA, Vincent RIJMEN et Martin SCHLÄFFER. "Secure Hardware Implementation of Nonlinear Functions in the Presence of Glitches". In: *Journal of Cryptology (JoC)* (avr. 2011), p. 292-321. DOI: 10.1007/s00145-010-9085-7.

[OST05] Dag Arne OSVIK, Adi SHAMIR et Eran TROMER. "Cache Attacks and Countermeasures: The Case of AES". In: *Proc. Cryptographers' Track RSA Conference (CT-RSA)*. Springer, fév. 2005, p. 1-20. DOI: 10.1007/11605805_1.

[Osw+05] Elisabeth OSWALD et al. "Practical Second-Order DPA Attacks for Masked Smart Card Implementations of Block Ciphers". In: *Proc. Cryptographers' Track RSA Conference (CT-RSA)*. Springer, fév. 2005, p. 192-207. DOI: 10.1007/11605805_13.

[PM05] Thomas POPP et Stefan MANGARD. "Masked Dual-Rail Pre-charge Logic: DPA-Resistance Without Routing Constraints". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2005, p. 172-186. DOI: 10.1007/11545262_13.

[PP10] Christof PAAR et Jan PELZL. *Understanding Cryptography: A Textbook for Students and Practitioners*. Springer, 2010. DOI: 10.1007/978-3-642-04101-3.

[PR13] Emmanuel PROUFF et Matthieu RIVAIN. "Masking against Side-Channel Attacks: A Formal Security Proof". In: *Proc. Annual International Conference on Theory and Applications of Cryptographic Techniques (EUROCRYPT)*. Springer, mai 2013, p. 142-159. DOI: 10.1007/978-3-642-38348-9_9.

[PRB09] Emmanuel PROUFF, Matthieu RIVAIN et Regis BEVAN. "Statistical Analysis of Second Order Differential Power Analysis". In: *IEEE Transactions on Computers* (jan. 2009), p. 799-811. DOI: 10.1109/TC.2009.15.

[QS01] Jean-Jacques QUISQUATER et David SAMYDE. "ElectroMagnetic Analysis (EMA): Measures and Counter-measures for Smart Cards". In: *Proc. International Conference on Research in Smart Cards (E-smart)*. Springer, sept. 2001, p. 200-210. DOI: 10.1007/3-540-45418-7_17.

[Rep+15] Oscar REPARAZ et al. "Consolidating Masking Schemes". In: *Proc. Annual Cryptology Conference (CRYPTO)*. Springer, août 2015, p. 764-783. DOI: 10.1007/978-3-662-47989-6_37.
[Rep15] Oscar REPARAZ. *A note on the security of Higher-Order Threshold Implementations*. IACR Cryptology ePrint Archive. Jan. 2015. URL: https://eprint.iacr.org/2015/001.

[RP10] Matthieu RIVAIN et Emmanuel PROUFF. "Provably Secure Higher-Order Masking of AES". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2010, p. 413-427. DOI: 10.1007/978-3-642-15031-9_28.

[RPD09] Matthieu RIVAIN, Emmanuel PROUFF et Julien DOGET. "Higher-Order Masking and Shuffling for Software Implementations of Block Ciphers". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2009, p. 171-188. DOI: 10.1007/978-3-642-04138-9_13.

[Sha49] Claude SHANNON. "Communication theory of secrecy systems". In: *The Bell System Technical Journal* (oct. 1949), p. 656-715. DOI: 10.1002/j.1538-7305.1949.tb00928.x.

[Sha79] Adi SHAMIR. "How to Share a Secret". In: *Communications of the ACM* (nov. 1979), p. 612-613. DOI: 10.1145/359168.359176.

[SM15] Tobias SCHNEIDER et Amir MORADI. "Leakage Assessment Methodology - A Clear Roadmap for Side-Channel Evaluations". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2015, p. 495-513. DOI: 10.1007/978-3-662-48324-4_25.

[Sok+04] Danil SOKOLOV et al. "Improving the Security of Dual-Rail Circuits". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, août 2004, p. 282-297. DOI: 10.1007/978-3-540-28632-5_21.

[SS16] Peter SCHWABE et Ko STOFFELEN. "All the AES You Need on Cortex-M3 and M4". In: *Proc. Selected Areas in Cryptography (SAC)*. Springer, août 2016, p. 180-194. DOI: 10.1007/978-3-319-69453-5_10.

[Sto19] Ko STOFFELEN. "Efficient Cryptography on the RISC-V Architecture". In: *Proc. International Conference on Cryptology and Information Security in Latin America (LATINCRYPT)*. Springer, oct. 2019, p. 323-340. DOI: 10.1007/978-3-030-30530-7_16.

[TB07] Michael TUNSTALL et Olivier BENOIT. "Efficient Use of Random Delays in Embedded Software". In: *Proc. International Workshop on Information Security Theory and Practices (WISTP)*. Springer, mai 2007, p. 27-38. DOI: 10.1007/978-3-540-72354-7_3.

[TG07] Stefan TILLICH et Johann GROSSSCHÄDL. "Power Analysis Resistant AES Implementation with Instruction Set Extensions". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2007, p. 303-319. DOI: 10.1007/978-3-540-74735-2_21.

[TKS10] Stefan TILLICH, Mario KIRSCHBAUM et Alexander SZEKELY. "SCA-Resistant Embedded Processors: The next Generation". In: *Proc. Advances in Computer Systems Architecture (ACSAC)*. ACM, déc. 2010, p. 211-220. DOI: 10.1145/1920261.1920293.
[TKS11] Stefan TILLICH, Mario KIRSCHBAUM et Alexander SZEKELY. "Implementation and Evaluation of an SCA-Resistant Embedded Processor". In: *Proc. International Conference on Smart Card Research and Advanced Applications (CARDIS)*. Springer, sept. 2011, p. 151-165. DOI: 10.1007/978-3-642-27257-8_10.

[Tsu+03] Yukiyasu TSUNOO et al. "Cryptanalysis of DES Implemented on Computers with Cache". In: *Proc. International Workshop on Cryptographic Hardware and Embedded Systems (CHES)*. Springer, sept. 2003, p. 62-76. DOI: 10.1007/978-3-540-45238-6_6.

[UHA17] Rei UENO, Naofumi HOMMA et Takafumi AOKI. "Toward More Efficient DPA-Resistant AES Hardware Architecture Based on Threshold Implementation". In: *Proc. International Workshop on Constructive Side-Channel Analysis and Secure Design (COSADE)*. Springer, avr. 2017, p. 50-64. DOI: 10.1007/978-3-319-64647-3_4.

[Vey+12] Nicolas VEYRAT-CHARVILLON et al. "Shuffling against Side-Channel Attacks: A Comprehensive Study with Cautionary Note". In: *Proc. International Conference on the Theory and Application of Cryptology and Information Security (ASIA-CRYPT)*. Springer, déc. 2012, p. 740-757. DOI: 10.1007/978-3-642-34961-4_44.

[WA19] Andrew WATERMAN et Krste ASANOVIĆ. *The RISC-V Instruction Set Manual Volume I: Unprivileged ISA*. RISC-V Foundation. Déc. 2019. URL: https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf.

[Yan+18] Bohan YANG et al. "ES-TRNG: A High-throughput, Low-area True Random Number Generator based on Edge Sampling". In: *Transactions on CHES* (août 2018), p. 267-292. DOI: 10.13154/tches.v2018.i3.267-292.
Table des figures

<table>
  <tbody>
    <tr>
      <td>1.1</td>
      <td>Schéma d'une communication entre Alice et Bob.</td>
      <td>19</td>
    </tr>
    <tr>
      <td>1.2</td>
      <td>Système de chiffrement.</td>
      <td>20</td>
    </tr>
    <tr>
      <td>1.3</td>
      <td>Chiffrement par bloc itératif.</td>
      <td>21</td>
    </tr>
    <tr>
      <td>1.4</td>
      <td>Mode de chiffrement.</td>
      <td>22</td>
    </tr>
    <tr>
      <td>1.5</td>
      <td>Le chiffrement AES.</td>
      <td>23</td>
    </tr>
    <tr>
      <td>1.6</td>
      <td>L'état de AES.</td>
      <td>24</td>
    </tr>
    <tr>
      <td>1.7</td>
      <td>Fonction de chiffrement de AES.</td>
      <td>25</td>
    </tr>
    <tr>
      <td>1.8</td>
      <td>Sous-fonction SubBytes.</td>
      <td>25</td>
    </tr>
    <tr>
      <td>1.9</td>
      <td>Sous-fonction ShiftRows.</td>
      <td>26</td>
    </tr>
    <tr>
      <td>1.10</td>
      <td>Sous-fonction MixColumns.</td>
      <td>26</td>
    </tr>
    <tr>
      <td>1.11</td>
      <td>Sous-fonction AddRoundKey.</td>
      <td>27</td>
    </tr>
    <tr>
      <td>2.1</td>
      <td>Classification des attaques.</td>
      <td>29</td>
    </tr>
    <tr>
      <td>2.2</td>
      <td>Attaque par observation.</td>
      <td>30</td>
    </tr>
    <tr>
      <td>2.3</td>
      <td>Consommation d'un microprocesseur 8 bits.</td>
      <td>33</td>
    </tr>
    <tr>
      <td>2.4</td>
      <td>Illustration simplifiée d'un glitch.</td>
      <td>34</td>
    </tr>
    <tr>
      <td>2.5</td>
      <td>SPA sur l'exponentiation modulaire.</td>
      <td>35</td>
    </tr>
    <tr>
      <td>2.6</td>
      <td>Analyse différentielle de la consommation.</td>
      <td>36</td>
    </tr>
    <tr>
      <td>2.7</td>
      <td>Modèles de consommation.</td>
      <td>37</td>
    </tr>
    <tr>
      <td>2.8</td>
      <td>Stratégie d'attaque diviser pour régner.</td>
      <td>38</td>
    </tr>
    <tr>
      <td>2.9</td>
      <td>Contre-mesure de désynchronisation en temps.</td>
      <td>39</td>
    </tr>
    <tr>
      <td>2.10</td>
      <td>Porte logique implémentée en double rail.</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.1</td>
      <td>Procédure d'encodage et de décodage.</td>
      <td>42</td>
    </tr>
    <tr>
      <td>3.2</td>
      <td>Procédure de masquage et de démasquage du masquage booléen.</td>
      <td>42</td>
    </tr>
    <tr>
      <td>3.3</td>
      <td>Schéma de masquage.</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.4</td>
      <td>Modèle de sondage.</td>
      <td>45</td>
    </tr>
    <tr>
      <td>3.5</td>
      <td>Masquage d'une application linéaire.</td>
      <td>46</td>
    </tr>
    <tr>
      <td>3.6</td>
      <td>Porte AND masquée non sécurisée et sécurisée dans le modèle de sondage.</td>
      <td>46</td>
    </tr>
    <tr>
      <td>3.7</td>
      <td>Exemples de sondes étendues pour les glitchs et/ou les transitions.</td>
      <td>47</td>
    </tr>
    <tr>
      <td>3.8</td>
      <td>Modèle de sondage par régions.</td>
      <td>48</td>
    </tr>
    <tr>
      <td>3.9</td>
      <td>Composition d'implémentations masquées.</td>
      <td>49</td>
    </tr>
    <tr>
      <td>3.10</td>
      <td>3-NI illustré sur une implémentation masquée à l'ordre 3.</td>
      <td>52</td>
    </tr>
    <tr>
      <td>3.11</td>
      <td>3-SNI illustré sur une implémentation masquée à l'ordre 3.</td>
      <td>53</td>
    </tr>
    <tr>
      <td>3.12</td>
      <td>3-PINI illustré sur une implémentation masquée à l'ordre 3.</td>
      <td>54</td>
    </tr>
    <tr>
      <td>4.1</td>
      <td>Inversion dans GF(2<sup>8</sup>).</td>
      <td>60</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>4.2</td>
      <td>Représentation «bit slicing».</td>
      <td>60</td>
    </tr>
    <tr>
      <td>4.3</td>
      <td>Code C de la transposition simple de 32 blocs en représentation «*bit slicing*».</td>
      <td>61</td>
    </tr>
    <tr>
      <td>4.4</td>
      <td>Code Usuba d'une implémentation BS de AES.</td>
      <td>62</td>
    </tr>
    <tr>
      <td>4.5</td>
      <td>Représentation 16-slicing</td>
      <td>63</td>
    </tr>
    <tr>
      <td>4.6</td>
      <td>Exponentiation modulaire masquée à l'ordre 1.</td>
      <td>65</td>
    </tr>
    <tr>
      <td>4.7</td>
      <td>Représentation «share slicing» d'ordre 1 sur une architecture 32 bits.</td>
      <td>67</td>
    </tr>
    <tr>
      <td>5.1</td>
      <td>Architecture de jeu d'instructions.</td>
      <td>70</td>
    </tr>
    <tr>
      <td>5.2</td>
      <td>Extension de jeu d'instructions.</td>
      <td>72</td>
    </tr>
    <tr>
      <td>5.3</td>
      <td>Structure de la zone sécurisée de l'ISE de [TG07].</td>
      <td>74</td>
    </tr>
    <tr>
      <td>5.4</td>
      <td>Schéma de l'ISE de [Gro+16].</td>
      <td>75</td>
    </tr>
    <tr>
      <td>5.5</td>
      <td>Schéma de l'ISE de [Gao+21].</td>
      <td>76</td>
    </tr>
    <tr>
      <td>5.6</td>
      <td>Schéma de l'ISE de [MP21].</td>
      <td>76</td>
    </tr>
    <tr>
      <td>6.1</td>
      <td>Notre environnement expérimental.</td>
      <td>81</td>
    </tr>
    <tr>
      <td>6.2</td>
      <td>Utilisation logicielle d'une nouvelle instruction.</td>
      <td>84</td>
    </tr>
    <tr>
      <td>6.3</td>
      <td>Résultats de réimplantations logicielles de plusieurs solutions de l'état de l'art sur le cœur CV32E40P.</td>
      <td>87</td>
    </tr>
    <tr>
      <td>6.4</td>
      <td>Trace de consommation simulée avec Spike pendant le chiffrement AES.</td>
      <td>88</td>
    </tr>
    <tr>
      <td>6.5</td>
      <td>Trace de consommation simulée avec Verilator pendant le chiffrement AES.</td>
      <td>89</td>
    </tr>
    <tr>
      <td>6.6</td>
      <td>Évaluation de la fuite durant la première ronde de AES.</td>
      <td>90</td>
    </tr>
    <tr>
      <td>6.7</td>
      <td>Résultats de l'attaque CPA ciblant la première ronde de AES.</td>
      <td>90</td>
    </tr>
    <tr>
      <td>6.8</td>
      <td>Résultats de l'attaque par modèle ciblant la première ronde de AES.</td>
      <td>91</td>
    </tr>
    <tr>
      <td>7.1</td>
      <td>Code Python décrivant les nouvelles instructions de l'ISE1.</td>
      <td>94</td>
    </tr>
    <tr>
      <td>7.2</td>
      <td>Illustration de l'instruction ise1.and</td>
      <td>95</td>
    </tr>
    <tr>
      <td>7.3</td>
      <td>Architecture de notre ALU masquée de l'ISE1.</td>
      <td>96</td>
    </tr>
    <tr>
      <td>7.4</td>
      <td>Schéma simplifié du cœur modifié avec l'ISE1.</td>
      <td>98</td>
    </tr>
    <tr>
      <td>7.5</td>
      <td>Temps de chiffrement de AES masqué avec l'ISE1.</td>
      <td>99</td>
    </tr>
    <tr>
      <td>7.6</td>
      <td>Surface et fréquence maximale du cœur CV32E40P avec l'ISE1</td>
      <td>99</td>
    </tr>
    <tr>
      <td>8.1</td>
      <td>Code Python décrivant les nouvelles instructions de l'ISE2.</td>
      <td>104</td>
    </tr>
    <tr>
      <td>8.2</td>
      <td>Notre représentation 16-slicing.</td>
      <td>104</td>
    </tr>
    <tr>
      <td>8.3</td>
      <td>Notre représentation 8-slicing.</td>
      <td>105</td>
    </tr>
    <tr>
      <td>8.4</td>
      <td>Notre représentation 4-slicing.</td>
      <td>107</td>
    </tr>
    <tr>
      <td>8.5</td>
      <td>Notre représentation 2-slicing.</td>
      <td>108</td>
    </tr>
    <tr>
      <td>9.1</td>
      <td>Schéma d'une instruction masquée à l'ordre d et sécurisée dans le modèle de sondage par régions avec d/2 sondes par instruction.</td>
      <td>112</td>
    </tr>
    <tr>
      <td>9.2</td>
      <td>Illustration d'une preuve de sécurité dans le modèle de sondage par régions.</td>
      <td>112</td>
    </tr>
    <tr>
      <td>9.3</td>
      <td>Code Python décrivant les nouvelles instructions de l'ISE3.</td>
      <td>113</td>
    </tr>
    <tr>
      <td>9.4</td>
      <td>Architecture de l'ALU masquée de l'ISE3.</td>
      <td>114</td>
    </tr>
    <tr>
      <td>9.5</td>
      <td>Schéma simplifié du cœur modifié avec l'ISE3.</td>
      <td>115</td>
    </tr>
    <tr>
      <td>9.6</td>
      <td>Temps de chiffrement de AES masqué avec l'ISE3.</td>
      <td>115</td>
    </tr>
    <tr>
      <td>9.7</td>
      <td>Surface et fréquence maximale du cœur CV32E40P avec l'ISE3</td>
      <td>116</td>
    </tr>
    <tr>
      <td>10.1</td>
      <td>Notre représentation masquée avec d<sub>H</sub> = 1 et d<sub>S</sub> = 2 sur une architecture 32 bits.</td>
      <td>118</td>
    </tr>
  </tbody>
</table>
<table><tr><td>10.2 Résultats d'implémentations du chiffrement AES avec notre solution de masquage matériel/logiciel</td><td>122</td></tr><tr><td>A.1 Code C de la transposition récursive de 32 blocs en représentation «bit slicing».</td><td>128</td></tr><tr><td>B.1 Code Usuba de notre implémentation 16-slicing de AES.</td><td>130</td></tr><tr><td>B.2 Code Usuba de notre implémentation 8-slicing de AES.</td><td>131</td></tr><tr><td>B.3 Code Usuba de notre implémentation 4-slicing de AES.</td><td>132</td></tr><tr><td>B.4 Code Usuba de notre implémentation 2-slicing de AES.</td><td>133</td></tr></table>
<figure><img src="image_80.png" /></figure>
Liste des tableaux

<table>
  <tbody>
    <tr>
      <td>1.1</td>
      <td>Caractéristiques des différents modes de chiffrement.</td>
      <td>23</td>
    </tr>
    <tr>
      <td>3.1</td>
      <td>Résumé des différentes multiplications masquées en matériel.</td>
      <td>57</td>
    </tr>
    <tr>
      <td>4.1</td>
      <td>Performance de différentes implémentations logicielles du chiffrement AES.</td>
      <td>64</td>
    </tr>
    <tr>
      <td>4.2</td>
      <td>Performances de différentes implémentations logicielles masquées du chiffrement AES.</td>
      <td>68</td>
    </tr>
    <tr>
      <td>5.1</td>
      <td>Formats d'instruction de RV32I.</td>
      <td>71</td>
    </tr>
    <tr>
      <td>5.2</td>
      <td>Coût/Performance du masquage d'ordre 1 de AES extrait de [Gao+21].</td>
      <td>73</td>
    </tr>
    <tr>
      <td>5.3</td>
      <td>Performance de différentes ISE dédiées au masquage de l'état de l'art.</td>
      <td>77</td>
    </tr>
    <tr>
      <td>5.4</td>
      <td>Surface et période de différentes ISE dédiées au masquage de l'état de l'art.</td>
      <td>77</td>
    </tr>
    <tr>
      <td>6.1</td>
      <td>Description des différents opcodes de la spécification RISC-V.</td>
      <td>84</td>
    </tr>
    <tr>
      <td>6.2</td>
      <td>Résultats de réimplantations logicielles de plusieurs solutions de l'état de l'art sur le cœur CV32E40P.</td>
      <td>86</td>
    </tr>
    <tr>
      <td>6.3</td>
      <td>Performance de différentes ISE dédiées au masquage de l'état de l'art réimplan-tées sur le cœur CV32E40P.</td>
      <td>87</td>
    </tr>
    <tr>
      <td>6.4</td>
      <td>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.</td>
      <td>88</td>
    </tr>
    <tr>
      <td>7.1</td>
      <td>Caractéristiques des instructions masquées pour chaque version de l'ISE1.</td>
      <td>97</td>
    </tr>
    <tr>
      <td>7.2</td>
      <td>Résultats d'implantation de l'ISE1 masquée au ordres d &isin; {1, 2, 3, 7, 15, 31}.</td>
      <td>101</td>
    </tr>
    <tr>
      <td>8.1</td>
      <td>Résultats d'implantations de l'ISE2 masquée aux ordres d &isin; {1, 2, 3, 7, 15, 31}.</td>
      <td>109</td>
    </tr>
    <tr>
      <td>8.2</td>
      <td>Résultats d'implantation FPGA du cœur CV32E40P avec l'ISE2.</td>
      <td>110</td>
    </tr>
    <tr>
      <td>9.1</td>
      <td>Caractéristiques des instructions masquées de l'ISE3.</td>
      <td>114</td>
    </tr>
    <tr>
      <td>10.1</td>
      <td>Caractéristiques des ISE masquées de l'état de l'art et de notre solution.</td>
      <td>117</td>
    </tr>
    <tr>
      <td>10.2</td>
      <td>Résultats d'implémentations du chiffrement AES avec notre solution matérielle/logicielle masquée aux ordres matériels d<sub>H</sub> &isin; {1, 2, 3, 5, 7} et pour différents ordres logiciels.</td>
      <td>123</td>
    </tr>
  </tbody>
</table>
<figure><img src="image_81.png" /></figure>
Liste des algorithmes

<table>
  <tbody>
    <tr>
      <td>1</td>
      <td>Vérification de code PIN</td>
      <td>32</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Exponentiation modulaire utilisant la méthode «Square and Multiply»</td>
      <td>32</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Porte AND masquée de [ISW03]</td>
      <td>50</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Méthode de rafraîchissement de [RP10]</td>
      <td>50</td>
    </tr>
    <tr>
      <td>5</td>
      <td>Méthode de rafraîchissement basée sur la multiplication masquée ISW [Bar+16]</td>
      <td>51</td>
    </tr>
    <tr>
      <td>6</td>
      <td>Multiplication masquée PINI<sub>1</sub> de [CS20].</td>
      <td>56</td>
    </tr>
    <tr>
      <td>7</td>
      <td>Multiplication masquée DOM de [GMK16].</td>
      <td>57</td>
    </tr>
    <tr>
      <td>8</td>
      <td>Évaluation sécurisée de h : x ↦ x ⊗ L(x) [Cor+14]</td>
      <td>65</td>
    </tr>
    <tr>
      <td>9</td>
      <td>Multiplication masquée à l'ordre 1 de [Bar+17].</td>
      <td>67</td>
    </tr>
    <tr>
      <td>10</td>
      <td>Porte XOR masquée à l'ordre d<sub>S</sub> utilisant les instructions de l'ISE1 masquée à l'ordre d<sub>H</sub>.</td>
      <td>119</td>
    </tr>
    <tr>
      <td>11</td>
      <td>Porte NOT masquée à l'ordre d<sub>S</sub> utilisant les instructions de l'ISE1 masquée à l'ordre d<sub>H</sub>.</td>
      <td>119</td>
    </tr>
    <tr>
      <td>12</td>
      <td>Porte AND masquée à l'ordre d<sub>S</sub> et d<sub>S</sub>-SNI utilisant les instructions de l'ISE1 masquée à l'ordre d<sub>H</sub> et d<sub>H</sub>-SNI.</td>
      <td>120</td>
    </tr>
    <tr>
      <td>13</td>
      <td>Porte AND masquée à l'ordre d<sub>S</sub> utilisant les instructions de l'ISE1 masquée à l'ordre d<sub>H</sub> et d<sub>H</sub>-PINI.</td>
      <td>121</td>
    </tr>
  </tbody>
</table>
<figure><img src="image_82.png" /></figure>
<figure><img src="image_83.png" /></figure>
**Titre :** Extensions cryptographiques pour processeurs embarqués

**Mot clés :** processeur sécurisé, masquage logiciel/matériel, cryptographie symétrique

**Résumé :** Les implémentations de cryptosystèmes, même robustes mathématiquement, sont susceptibles de divulguer des informations via l'observation de canaux auxiliaires (par exemple la consommation d'énergie). Les attaques par analyse des canaux auxiliaires (SCA) exploitent de potentielles corrélations entre des valeurs physiques mesurées et des opérations et opérandes traitées dans le circuit pour récupérer des données sensibles. Le masquage est une contre-mesure couramment utilisée pour protéger des systèmes logiciels et/ou matériels contre certaines attaques SCA. Cependant, la mise en œuvre purement logiciel du masquage impose un coût important en termes de tailles de code

et temps de calcul, et n'atteint pas toujours le niveau de sécurité attendu en raison de fuites liées à la micro-architecture des processeurs. Dans cette thèse, nous avons développé différentes extensions du jeu d'instructions RISC-V afin de protéger les cryptosystèmes contre des attaques SCA en utilisant un masquage d'ordre élevé. Nous proposons également une solution de masquage matériel/logiciel pour masquer à des ordres élevés avec une grande flexibilité au moment de la synthèse et de la compilation logicielle pour divers compromis coût/performance. Nos solutions ont été implémentées sur le processeur RISC-V CV32E40P, puis validées et évaluées sur FPGA.

**Title:** Cryptographic extensions for embedded processors

**Keywords:** secure processor, software/hardware masking, symmetric cryptography

**Abstract:** Implementations of cryptosystems, even mathematically robust ones, are likely to leak information through the observation of side channels (e.g., energy consumption). Side channel analysis (SCA) attacks exploit potential correlations between measured physical values and operations or operands processed in the circuit to recover sensitive data. Masking is a common countermeasure to protect software or hardware systems against SCA attacks. However, pure software masking leads to important overheads in terms of code size and execution time while it

does not always achieve the expected security level due to leaks in the processor microarchitecture. In this thesis, we developed several extensions of the RISC-V instruction set to protect cryptosystems against SCA attacks using high-order masking. We also proposed a hardware/software masking solution at high orders with flexibility at both hardware synthesis time and software compilation time for various cost/performance tradeoffs. Our solutions have been implemented on the RISC-V CV32E40P processor, then validated and evaluated on FPGA.