Présentation du circuit étudié

Le premier circuit qui sera étudié est un cœur de coprocesseur réalisant des multiplications modulaires de Montgomery. Ce cœur peut être utilisé comme accélérateur matériel pour le chiffrement et déchiffrement de messages en utilisant l’algorithme RSA. La multiplication de Montgomery est définie par l’équation suivante : M(A,B,N) A*B*R−1modN

= où A, B et N sont des entiers codés sur n bits. A, B et N sont respectivement les multiplieur, multiplicande et modulo ; R est défini par R=2n. De plus, le multiplieur et le multiplicande sont tous deux inférieurs au modulo, qui doit être impair. Pour notre étude, le circuit considéré permet de réaliser des opérations sur 512 bits.

Le multiplieur est décrit au niveau transfert de registre (RTL) en VHDL. Le cœur de calcul est une matrice systolique de 512 cellules constituées chacune d’additionneurs et de quelques portes logiques. Ce cœur est contrôlé par de la logique séquentielle et est alimenté en entrée par un registre à décalage, permettant la rotation de l’opérande A un cycle sur deux. Les données en entrée et sortie sont stockées dans des registres 512 bits connectés au reste du système par une simple interface AMBA AHB Lite. Le multiplieur de Montgomery peut être utilisé comme un périphérique esclave connecté à un bus AMBA [AMBA]. Les données sont transférées par sous-mots de 32 bits. La Figure 20 résume les différentes phases du calcul. 3*n cycles sont nécessaires au cœur combinatoire pour réaliser l’opération, soit 1536 cycles d’horloge. En incluant les transferts avec le reste du système, l’opération dure 1739 cycles.

Le prototype qui a été conçu et fabriqué pour ces expériences inclue trois versions du multiplieur. La version de référence (Référence) est une version non protégée du circuit, capable uniquement de réaliser des opérations simples. Les deux autres versions possèdent les mêmes protections contre les fautes. La version Protégée1 est le résultat de l’ajout de la protection choisie à la version de référence. La version Protégée2, quant à elle, est le résultat de la sécurisation d’une version

optimisée de la référence. Ces optimisations ont pour but d’accroître ses performances en pipelinant les transferts au niveau système, elle embarque donc des registres supplémentaires.

0 146 1685 1739 Clock Reset Chargement des données Calcul Lecture du résultat et réinitialisation 0 146 1685 1739 Clock Reset Chargement des données Calcul Lecture du résultat et réinitialisation

Figure 20 : Chronogramme d’une multiplication de Montgomery

L’ajout de toutes les protections a été réalisé sur la description RTL du circuit. Tous les registres du circuit ont été protégés en utilisant un code de parité et des blocs de vérification en double rail. Pour obtenir un bon compromis entre le coût et les capacités de détection de fautes multiples, un bit de parité est ajouté pour chaque sous-mot de 32 bits. Ainsi, un registre de données de 512 bits est protégé par 16 bits ; les registres de taille inférieure ou les bascules isolées ont été regroupés en mots de 32 bits pour être protégés. Le registre d’état de l’interface AMBA AHB a, quant à elle, été protégée en utilisant un codage en un parmi n. Le cœur de calcul combinatoire à lui aussi été protégé en utilisant un code de parité avec une vérification en double rail. La Figure 21 présente comment cette protection a été implantée.

Figure 21 : Principe de prédiction avec vérification en double rail [Port 06]

On retrouve ici le concept présenté précédemment ; cependant, il a été modifié pour ajouter une vérification en double rail. La sortie du bloc de prédiction est comparée au codage de la sortie du bloc protégé par deux vérificateurs duaux générant deux signaux d’erreurs. Ces deux signaux sont complémentaires en l’absence de fautes ou si les fautes ont eu lieu dans le bloc de prédiction ou de calcul original ; si les fautes sont apparues dans un des vérificateurs, on obtient alors une alarme dissymétrique.

Une paire de signaux d’erreur est ainsi générée pour chaque sous-mot protégé. Ces signaux sont ensuite regroupés en fonction du bloc fonctionnel d’où ils proviennent. On crée ainsi 18 alarmes pour la version Protégée1, respectivement 24 pour la version Protégée2. Ces alarmes sont stockées dans deux registres complémentaires Detect0 et Detect1, contenant respectivement uniquement des 0 et des 1 en l’absence de fautes. Du fait de la taille des données transmises par l’interface AMBA AHB, le code d’alarme en sortie est sur 32 bits dont seuls les bits de poids faibles sont significatifs. Les registres de détection conservent leur valeur en cas de détection jusqu’à une réinitialisation du circuit. Un signal d’alarme est généré dès qu’un des bits de ces registres signale la présence de fautes. Tous les blocs de vérification, les codeurs, les registres de détection ainsi que les registres et blocs combinatoires protégés sont implantés dans des entités distinctes du modèle VHDL, permettant ainsi à une synthèse hiérarchique de ne pas éliminer les blocs redondants. La Figure 22 présente l’architecture globale de la version Protégée1.

Figure 22 : Architecture globale de la version Protégée1

Les trois versions du multiplieur ont été implantées sur un circuit en utilisant la technologie ST HCMOS 130nm possédant six niveaux de métal. La Figure 23 montre le layout du circuit contenant les trois versions du multiplieur. La seule contrainte donnée lors des étapes de placement et routage est la séparation des registres de détection Detect0 et Detect1, dans le but d’éviter qu’un tir laser ne touche les deux registres simultanément. Le Tableau 1 présente la comparaison en termes de complexité des différentes versions. Le fort surcoût de la version Protégée1 peut s’expliquer par la complexité des blocs de prédiction de parité dans le cœur de calcul, pour lesquelles l’optimisation n’a pas été totale. Le Tableau 2 résume la correspondance entre les différentes alarmes et les blocs fonctionnels auxquels elles sont rattachées.

Tableau 1 : Complexité des différentes versions du multiplieur

Circuit Surface (mm²) # cellules # portes équivalentes Référence 0,434 26 589 55 751 Protégée1 0,827 46 084 116 796 Protégée2 1,282 59 600 160 849 Protégée2 Protégée1 Référence Protégée2 Protégée1 Référence

Figure 23 : Layout du circuit

Tableau 2 : Affectation des différentes alarmes aux principaux blocs fonctionnels

Fonction Vers. Protégée1 Vers. Protégée2 hard_comb Alarmes 8 à 10 Alarmes 13 à 15 montg_systo Alarmes 11 à 15 Alarmes 16 à 20 control Alarme 16 Alarmes 21 et 22 shift_a Alarme 17 Alarme 23 AHB_interface Alarmes 0 à 7 Alarmes 0 à 12

En termes de niveau de protection, le but n’était pas de protéger totalement le co-processeur contre un type donné de fautes, mais d’avoir un bon compromis entre le coût et le détection de fautes quelconques. Pour des fautes affectant directement les registres, le taux de détection est de 100% pour les fautes de multiplicité impaire. Pour les fautes de multiplicité paire, le taux de détection dépend de leur répartition au sein des différents sous-mots ; il suffit qu’un seul des sous-mots soit touché par un nombre impair de bits faux pour qu’une alarme soit levée. La probabilité d’erreur dans le cœur combinatoire dépend du nombre de sorties erronées et donc de sa structure logique. Dans cette étude, la synthèse a été réalisée en utilisant un flot standard sans limitation du partage de ressources lors de l’optimisation structurelle. De ce fait, une faute simple sur un nœud interne peut tout aussi bien être détectée ou non en sortie, selon le nombre de bits de sortie que cette faute altère. Contrôler la structure générée ne serait pas plus efficace étant donné qu’un tir laser peut illuminer une large zone touchant ainsi plusieurs cône logiques indépendants. Nous n’avons pas contraint le placement et le routage,

facilitant ainsi l’induction de fautes dans plusieurs éléments simultanément, accroissant ainsi la probabilité que l’un d’eux détecte une erreur.

Dans le cas de notre étude, le circuit ciblé ne présente a priori aucune zone plus sensible que les autres, du point de vue de l’application réalisée. En effet, tout résultat erroné peut être utilisé pour compromettre la sécurité globale de l’application. En conséquence, il a été décidé que la campagne d’injection serait basée sur des balayages complets du circuit tout au long de son calcul. Ceci est en quelque sorte une attaque en boite noire.

Toutes les campagnes de tirs laser sur ce circuit ont été réalisées sur la plate-forme d’injection de Gemalto. Pour conserver des temps d’expérimentation raisonnables, il a fallu réduire le nombre de valeurs possibles ; ainsi, le balayage du circuit sera fait dix fois à des instants uniformément répartis sur la durée d’exécution -entre le cycle 0 et le cycle 1350, donc tous les 150 cycles. De la même manière, les mêmes vecteurs d’entrée A, B et N ont été conservés tout au long de la campagne et la surface de chaque version du circuit a été découpée en plusieurs zones. Le circuit de référence a été divisé en 27 zones (9 positions en X et 3 positions en Y) ; les versions protégées ont, quant à elles, été séparées en 45 zones (5 positions en X et 9 positions en Y) et 63 zones (7 positions en X et 9 positions en Y) pour respectivement les versions Protégée1 et Protégée2. Chaque zone ainsi créée a pour forme un carré de 145 microns de côté, dont le centre correspond à la position du tir.

Pour pouvoir étudier le déterminisme des effets des tirs laser sur le circuit, il a été décidé de réaliser 5 tirs sur chaque position spatio-temporelle précédemment définie. Ceci représente 1350, 2250 et 3150 tirs sur respectivement les versions non protégée, Protégée1 et Protégée2.