Expériences

Deux expériences ont été conduites, afin de valider le modèle d’attaque. La première attaque était une attaque simulée, ayant pour but de valider l’ap-proche. Pour cette attaque, le leakage simulé de l’appareil était le poids de Hamming du byte attaqué. La seconde attaque a été réalisée sur un microcon-trolleur réalisant des opérations cryptographiques, le AddRoundKey initial et le premier tour d’AES, et servait dés lors à confirmer les résultats de l’attaque simulée. Les résultats de SSTA ont été comparés aux attaques par templates, ainsi qu’à deux techniques d’apprentissage automatisé : les forêts aléatoires et les machines à vecteurs de support. La technique de validation par retenue (section 2.4.1) a été utilisée pour mesurer la qualité du modèle SSTA.

Expériences simulées

Pour cette expérience, nous avons simulé la consommation d’énergie d’un mi-crocontrolleur 8 bits. Chaque trace est représentée par un point, correspon-dant au poids de Hamming d’une clé de 8 bits, ce qui nous met face à un problème univarié. La figure 5.2 nous montre le taux de succès estimé de l’at-taque en fonction du bruit (que nous avons simulé, de moyenne nulle et dont l’écart type est indiqué à la figure 5.2) présent dans les traces. Notons que ce taux de succès est la moyenne des taux de succès de 10 expériences réalisées dans les mêmes conditions⁶. On remarque que la variance du taux de succès de l’attaque est faible, ce qui conforte le résultat apporté par la moyenne des taux de succès. Nous avons utilisé une implantation R7 de la technique de clustering « Partitioning Around Medoids » [64]. Cette technique a été rete-nue, car nous disposions d’une implantation prête à l’emploi et qu’elle a, de suite, montré de bons résultats. Il ne nous a donc pas paru nécessaire de com-parer d’autres techniques de clustering. Suivant le modèle de validation par retenue (section 2.4.1), 3500 traces furent utilisées lors de l’apprentissage et 1500 pour la validation. Comme on pouvait s’y attendre, au plus le bruit est important, au plus le taux de succès diminue.

Expériences mesurées

L’expérience simulée a permis de valider le modèle SSTA, mais tous les para-mètres étaient contrôlés lors de cette phase⁸. Nous avons donc réalisé deux expériences à l’aide de données mesurées : une première, moins complexe, où seule la valeur du byte attaqué variait d’une acquisition à l’autre et une seconde, plus complexe, où les paramètres (clés et textes) étaient pris aléatoi-rement.

Pour la réalisation de ces expériences, nous avons utilisé un microcontrolleur 8 bits ATmega328P, que nous avons programmé en utilisant un Arduino Uno Board. Le microcontrolleur a été placé sur une protoboard externe, afin de ré-duire les bruits générés par les autres composants du Arduino Uno Board. Le microcontrolleur était alimenté en 5.3 V. Une horloge externe de 16 MHz a été utilisée. La consommation d’énergie a été mesurée aux bornes d’une résistance de 47 Ω, placée en série de la pin Vcc de l’ATmega328P. Les acquisitions ont été réalisées à l’aide d’un oscilloscope Agilent Infiniium 80000B Series 2GHz

6. C’est-à-dire la même valeur d’écart-type pour le bruit. 7. Package cluster [43] disponible sur CRAN

8. La fuite d’information correspondait au poids de Hamming exact du byte attaqué. Le bruit ajouté était connu, ainsi que les entrées fournies (textes et clés).

FIGURE5.2 – Taux de succès moyen en fonction du bruit. Généré en réalisant la moyenne de 10 mesures et la technique de clustering « Partitioning Around Medoids ». ●● ● ● ● ● ● ● ● ● ● ● ● ●_● ●●_● ●_●● ●●●_●● ●_●● ●●●●●_●● ●●●●● 0 1 2 3 4 0.0 0.2 0.4 0.6 0.8 1.0 noise success r ate

● average success rate

standard deviation of success rate

40 GSa/s (valeur maximales possibles9).

Lors de la première expérience, nous avons décidé d’utiliser toujours le même texte clair, où tous les bytes ont été mis à zéro. Tous les bytes de la clé ont également été mis à zéro, sauf le byte attaqué. Cette décision de mettre tous les bytes à zéro, sauf celui attaqué, est de faciliter la réalisation de l’attaque, car moins de points dans la trace seront candidats à être l’instant t utilisé pour réaliser l’attaque. En effet, les autres valeurs ne variant pas, elles devraient engendrer des consommations d’énergie similaires. Les points où la consom-mation d’énergie varie le plus, d’une exécution à l’autre, en plus d’être moins nombreux, auront de forte chance d’être des points liés à l’utilisation, par l’ap-pareil, du byte attaqué. Nous avons choisi d’attaquer le treizième byte¹⁰ de clé en faisant varier sa valeur de 0 à 255.

9. En pratique, les paramètres d’acquisition étaient de 2Ghz et 250MSa/s.

10. Le numéro du byte ne devrait avoir aucune influence sur l’attaque, de part l’architecture 8 bits que nous attaquons.

Pour chaque valeur du byte de la clé attaqué, nous avons récolté 10 traces. Chacune de ces 10 traces correspond à la moyenne de 128 exécutions de la partie, de l’algorithme, mesurée. Ces moyennes ont directement été calculées sur l’oscilloscope lors de l’acquisition. Le choix des valeurs des paramètres 10 et 128 est essentiellement dû à des contraintes logistiques (temps d’acquisition des données). Le résultat d’une acquisition (la moyenne de 128 exécutions) est visible à la figure 5.3. Les traces ont été alignées à l’aide d’un trigger placé sur le signal de chiffrement envoyé à l’appareil depuis l’ordinateur de contrôle. Deux signaux différents ont été utilisés au cours de l’expérience : un premier signal donnant l’ordre à l’appareil de commencer le chiffrement à l’aide du texte clair et de la clé connus et un second signal indiquant à l’appareil d’in-crémenter, modulo 256, d’une unité la valeur du byte de la clé attaqué. FIGURE5.3 – Moyenne de 128 exécutions. Mapping des opérations d’AES sur la trace : KEY _EXP – KeyExpansion, ARK – AddRoundKey, SB – SubBytes, SR– ShiftRows, M C – MixColumns.

L’expérience a été conduite en utilisant 8 traces, par valeur de byte, dans l’ensemble d’apprentissage et 2 traces dans l’ensemble de validation11. Le meilleur point (le point le plus corrélé à la valeur attaquée), déterminé en utilisant l’information mutuelle entre la consommation d’énergie et le poids de Hamming du byte attaqué de la clé, pour la réalisation de l’attaque, identi-fié par le feature selection, est localisé à la fin de l’AddRoundKey initial, soit le moment où le treizième byte de la clé est manipulé. L’attaque a été conduite en utilisant la technique de clustering « Partitioning Around Medoids », pour laquelle nous disposions d’une implantation R et parce qu’elle a donné de bons résultats dès nos premières expériences. Le résultat de l’attaque est résumé à

la table 5.1.

TABLE 5.1 – Taux de succès des expériences de SSTA, TA (attaques par tem-plates), RF (forêts aléatoires) et SVM (machines à vecteurs de support). LS/VS est le nombre de traces dans l’ensemble d’apprentissage et dans l’ensemble de validation - Première expérience.

Modèle LS/VS ^{#Traces pour} #Clés ^{Taux de succès (%)}

la moyenne |h − ˆh| = 0 |h − ˆh| ≤ 1 |h − ˆh| ≤ 2

SSTA 8/2 128 256 61.5 89.77 100

TA 8/2 128 256 84.18 99.80 100

RF 8/2 128 256 77.54 99.61 100

SVM 8/2 128 256 83.98 100 100

TABLE5.2 – Taux de succès du modèle naïf.

Modèle Naïf Taux de succès (%)

|h − ˆh| = 0 |h − ˆh| ≤ 1 |h − ˆh| ≤ 2 |h − ˆh| ≤ 3 |h − ˆh| ≤ 4 27.34 71.09 92.97 99.22 100

Le taux de succès de l’expérience est de 61,5 %, ce qui est considérablement plus que le modèle naïf qui se base sur la distribution des poids de Hamming. Le modèle naïf renvoie le poids de Hamming le plus probable : le poids de Hamming 4, qui est le poids le plus souvent rencontré (70 fois sur 256, soit 27,34 %). En considérant une erreur absolue d’une unité dans le poids de Hamming estimé (i.e. |h − ˆh| ≤ 1, où h est le poids de Hamming d’un byte et ˆh est le poids de Hamming estimé par notre modèle), SSTA a un taux de succès de 89,77 %. En autorisant une erreur absolue de deux unités, SSTA atteint un taux de succès de 100 %. Ces pourcentages pour le modèle naïf sont cepen-dant peu relevant, étant donné le nombre considérable de clés à tester¹²... La deuxième expérience vise à généraliser la première expérience. En effet, il est très rare, en pratique, que seul le byte attaqué varie et que tous les autres bytes soient à zéro. Le scénario de cette deuxième expérience va donc être plus 12. En considérant une erreur absolue d’une unité, il faudra tester les clés de poids de Ham-ming 3, 4 et 5 soit 182 clés sur 256.

complexe, pour l’attaquant, que celui de la première, sous différents points : – le texte clair a été aléatoirement choisi, mais reste identique tout au long de

l’expérience, pour se placer dans un cas où le même message est manipulé par divers utilisateurs,

– la clé est modifiée aléatoirement à chaque exécution, pour symboliser le fait que chaque utilisateur a sa propre clé,

– seules 210 clés différentes ont été générées ; toutes les clés ne sont donc pas présentes lors de l’expérience, ce qui fait que les fréquences observées des poids de Hamming ne correspondent pas à la distribution des poids de Hamming ; ce nombre a été choisi de manière arbitraire, mais volontaire-ment inférieur à 256,

– les traces étaient plus bruitées, car elles résultaient de la moyenne de 100 exécutions et non plus de 128 exécutions, pour avoir volontairement plus de bruits dans les mesures.

L’attaque a porté sur le quinzième byte de la clé en lieu et place du treizième byte, car tous les poids de Hamming se retrouvaient dans les valeurs de ce byte. Mis à part les différences mentionnées ci-dessus, tous les autres para-mètres de l’expérience sont restés identiques. En se basant sur la figure 5.1, 31,33 % des bytes de la clé, soit 5 bytes, devraient être attaquables, car tous les poids de Hamming seraient représentés. En pratique, nous sommes arrivés à attaquer 6 bytes de la clé.

La table 5.3 nous montre les résultats de cette deuxième expérience. Le taux de succès de l’attaque est de 53 %, quand aucune erreur n’est tolérée. Le taux de succès de l’attaque atteint les 85,31 %, quand une erreur absolue d’une unité est autorisée et reste de 100% quand l’erreur absolue autorisée est de deux unités.

Une question que l’on peut se poser, est de savoir s’il est difficile pour l’atta-quant de retrouver le meilleur point dans la trace. Nous avons estimé la pro-babilité, pour l’attaquant, d’identifier le bon point à l’aide des traces récoltées pour chacune des expériences mesurées en fonction du nombre de traces dans T^K. Pour chaque expérience, répétée 100 fois, l’ensemble T^K était constitué aléatoirement. La figure 5.4 nous montre la probabilité empirique, pour l’atta-quant, de trouver le meilleur point en fonction du nombre de traces dans T^K, respectivement pour la première (partie gauche de la figure) et la seconde (partie droite de la figure) expérience. À partir d’un peu moins de 20 traces, l’attaquant a, dans les deux cas, plus de 90% de chance de trouver le meilleur point.

TABLE 5.3 – Taux de succès des expériences de SSTA, TA (attaques par tem-plates), RF (forêts aléatoires) et SVM (machines à vecteurs de support). LS/VS est le nombre de traces dans l’ensemble d’apprentissage et dans l’ensemble de validation - Seconde expérience.

Modèle LS/VS ^{#Traces pour} #Clés ^{Taux de succès (%)}

la moyenne |h − ˆh| = 0 |h − ˆh| ≤ 1 |h − ˆh| ≤ 2 SSTA 8/2 100 210 53.0 85.31 100 TA 8/2 100 210 71.56 98.58 100 RF 8/2 100 210 73.46 99.53 100 SVM 8/2 100 210 78.91 100 100