THÈSE DE DOCTORAT DE L`UNIVERSITÉ PARIS 6 Micro

THÈSE DE DOCTORAT
DE L’UNIVERSITÉ PARIS 6
Spécialité :
Micro-électronique
Présentée par
Minh Huu NGUYEN
Pour obtenir le grade de
DOCTEUR en SCIENCES
DE L’UNIVERSITÉ PARIS 6
Sujet de la thèse :
Sécurisation de processeurs vis-à-vis des
attaques par faute
et par analyse de la consommation
Soutenue le 21 septembre 2011 devant le jury composé de :
M
M
M.
Mme.
M.
M.
Mlle.
GOGNIAT
MAURINE
BAJARD
DRACH-TEMAM
PELAGE
ROBISSON
TRIA
Guy
Philippe
Jean-Claude
Nathalie
Perez
Bruno
Assia
Rapporteur
Rapporteur
Examinateur
Directrice
Examinateur
Examinateur
Examinatrice
Table des matières
Liste des Figures
v
Liste des Tableaux
vii
Remerciements
ix
Résumé
xi
Introduction
xv
I
État de l’art
1 Les attaques
1.1 Attaques invasives . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Préparation . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Rétro-conception matérielle . . . . . . . . . . . . .
1.1.3 Micro-sondage . . . . . . . . . . . . . . . . . . . . .
1.1.4 Modification du circuit . . . . . . . . . . . . . . . .
1.2 Attaques par injections de fautes . . . . . . . . . . . . . .
1.2.1 Méthodes d’injections de fautes . . . . . . . . . . .
1.2.1.1 Modification de l’alimentation . . . . . . .
1.2.1.2 Modification de la fréquence d’horloge . .
1.2.1.3 Illumination . . . . . . . . . . . . . . . . .
1.2.1.4 Champ électromagnétique . . . . . . . . .
1.2.2 Caractéristiques des méthodes d’injections de fautes
1.2.2.1 Modèles de fautes . . . . . . . . . . . . . .
1.2.2.2 Location spatiale des fautes . . . . . . . .
1.2.2.3 Type des fautes . . . . . . . . . . . . . . .
1.2.2.4 Comparaison . . . . . . . . . . . . . . . .
1.2.3 Scénarii d’attaques . . . . . . . . . . . . . . . . . .
1.2.3.1 DFA (Differential Fault Analysis) . . . . .
1.2.3.2 Attaques « safe-error » . . . . . . . . . . .
1.3 Attaques par canaux cachés . . . . . . . . . . . . . . . . .
1.3.1 Modèles de consommation et de rayonnement EM .
1.3.1.1 Modèles de consommation . . . . . . . . .
1.3.1.2 Modèles de rayonnement . . . . . . . . . .
1.3.2 Méthodes de mesure des canaux cachés . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
5
5
5
7
7
7
7
8
8
8
9
9
10
10
10
12
12
14
15
15
15
16
16
i
ii
Table des matières
1.4
1.3.2.1 Temps de réponse . . . . . . . . . . . . . .
1.3.2.2 Consommation . . . . . . . . . . . . . . . .
1.3.2.3 Émission électromagnétique . . . . . . . . .
1.3.2.4 Comparaison . . . . . . . . . . . . . . . . .
1.3.3 Scénarii d’attaques . . . . . . . . . . . . . . . . . . .
1.3.3.1 Analyse du temps de réponse . . . . . . . .
1.3.3.2 SPA « Simple Power Analysis » . . . . . . .
1.3.3.3 DPA « Differential Power Analysis » . . . .
1.3.3.4 Attaque par dictionnaire ou en « template »
1.3.3.5 Attaque par collision interne . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Contre-mesures
2.1 Contre-mesures contre les attaques par faute . . . . . . . . . . . .
2.1.1 Principe de détection des intrusions . . . . . . . . . . . . .
2.1.1.1 Capteurs physiques . . . . . . . . . . . . . . . . .
2.1.1.2 Détection d’erreur . . . . . . . . . . . . . . . . .
2.1.2 Redondance sur processeur . . . . . . . . . . . . . . . . . .
2.1.2.1 Dans la sphère de réplication . . . . . . . . . . .
2.1.2.2 Hors de la sphère de réplication . . . . . . . . . .
2.1.3 Contrôle de flot d’exécution . . . . . . . . . . . . . . . . .
2.1.3.1 Contrôle de transitions entre fonctions et entre BBs
2.1.3.2 Syndrome anormaux . . . . . . . . . . . . . . . .
2.1.4 Stratégie de réaction . . . . . . . . . . . . . . . . . . . . .
2.1.4.1 Recouvrement . . . . . . . . . . . . . . . . . . . .
2.1.4.2 Stratégies de sécurité évoluées . . . . . . . . . . .
2.1.5 Réduction de la sensibilité . . . . . . . . . . . . . . . . . .
2.1.5.1 Technologie . . . . . . . . . . . . . . . . . . . . .
2.1.5.2 Micro-architecture . . . . . . . . . . . . . . . . .
2.1.5.3 Triplication . . . . . . . . . . . . . . . . . . . . .
2.2 Contre-mesures contre les attaques par observation . . . . . . . .
2.2.1 Réduction du signal . . . . . . . . . . . . . . . . . . . . . .
2.2.1.1 Équilibrage . . . . . . . . . . . . . . . . . . . . .
2.2.1.2 Filtrage . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Ajout du bruit . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2.1 Parallélisation d’opérations indépendantes . . . .
2.2.2.2 Modification dynamique de la tension . . . . . .
2.2.2.3 Désynchronisation . . . . . . . . . . . . . . . . .
2.2.2.4 Masquage . . . . . . . . . . . . . . . . . . . . . .
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
16
17
18
18
18
19
20
23
26
27
29
30
30
30
30
33
34
35
39
39
41
41
41
43
44
44
45
45
46
46
46
48
48
48
48
49
53
54
Table des matières
II
iii
Conception
3 Environnement
3.1 Modèle de carte à puce utilisé . . . . . . . . . . . . . . . . .
3.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Processeur miniMIPS . . . . . . . . . . . . . . . . . .
3.1.2.1 Gestion des dépendances lors de l’exécution
instructions . . . . . . . . . . . . . . . . . .
3.1.2.2 Unité Arithmétique et Logique . . . . . . .
3.1.3 Mémoires . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 UART 16550 . . . . . . . . . . . . . . . . . . . . . .
3.1.5 PRNG . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.6 Émulateur d’injection de fautes . . . . . . . . . . . .
3.2 Flot de conception . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Logiciel . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Matériel . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.1 Configurations matérielles . . . . . . . . . .
3.2.2.2 Initialisation des modèles mémoires . . . . .
3.2.3 Simulation et test fonctionnel . . . . . . . . . . . . .
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
57
. . . 58
. . . 58
. . . 58
des
. . . 60
. . . 61
. . . 62
. . . 62
. . . 62
. . . 63
. . . 65
. . . 65
. . . 66
. . . 66
. . . 66
. . . 67
. . . 67
4 Protection vis-à-vis des attaques en faute
4.1 Détection des fautes . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Motivations et contribution . . . . . . . . . . . . . . . . .
4.1.2 Insertion des signatures dans le code . . . . . . . . . . . .
4.1.3 Segmentation des BBs . . . . . . . . . . . . . . . . . . . .
4.1.4 Architecture de vérification d’intégrité . . . . . . . . . . .
4.2 Système de recouvrement . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Motivations et contribution . . . . . . . . . . . . . . . . .
4.2.2 Architecture du système de recouvrement . . . . . . . . . .
4.2.3 Fonctionnement du système de recouvrement . . . . . . . .
4.2.3.1 Pseudo-code « sauvegarde » . . . . . . . . . . . .
4.2.3.2 Pseudo-code « recouvrement » . . . . . . . . . . .
4.2.3.3 Exemples de fonctionnement . . . . . . . . . . . .
4.2.4 Évaluation du système de détection de fautes et de recouvrement pour l’intégrité du code . . . . . . . . . . . . . . .
4.2.4.1 Surcoût matériel . . . . . . . . . . . . . . . . . .
4.2.4.2 Impact sur les performances . . . . . . . . . . . .
4.2.4.3 Sécurité . . . . . . . . . . . . . . . . . . . . . . .
4.3 Protection de l’UAL . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Motivations et contribution . . . . . . . . . . . . . . . . .
69
70
70
70
72
72
76
76
77
79
79
79
81
84
84
85
87
88
88
iv
Table des matières
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.4
Principe de détection . . . . . . . . .
Architecture de l’UAL . . . . . . . .
Mécanisme de recouvrement . . . . .
Ordonnancement statique . . . . . .
Évaluation de l’UAL sécurisée . . . .
4.3.6.1 Surcoût matériel . . . . . .
4.3.6.2 Impact sur les performances
4.3.6.3 Sécurité . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
90
91
92
93
96
96
97
99
99
5 Protection vis-à-vis des attaques par effet de bord
101
5.1 Ajout aléatoire d’instructions factices . . . . . . . . . . . . . . . . 101
5.1.1 Motivations et contribution . . . . . . . . . . . . . . . . . 101
5.1.2 Principe d’insertion . . . . . . . . . . . . . . . . . . . . . . 102
5.1.3 Architecture d’insertion d’instructions factices . . . . . . . 102
5.1.4 Évaluation de l’efficacité de l’ajout des instructions factices 107
5.1.5 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.1.5.1 Simulation de la puissance consommée . . . . . . 107
5.1.5.2 Modèle d’attaque . . . . . . . . . . . . . . . . . . 108
5.1.5.3 Choix des paramètres de la DPA . . . . . . . . . 109
5.1.5.4 Résultats DPA . . . . . . . . . . . . . . . . . . . 110
5.1.6 Surcoût matériel . . . . . . . . . . . . . . . . . . . . . . . 111
5.1.7 Impact sur les performances . . . . . . . . . . . . . . . . . 112
5.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6 Conclusion
115
Référence de Jeux d’instructions MIPS
119
Exemples de fonctionnement système de sauvegarde et de recouvrement
121
Bibliographie
125
Bibliographie personnelle
137
Liste des Abréviations
137
Liste des Figures
1
Flot de conception d’un circuit intégré . . . . . . . . . . . . . . . xvii
1.1
1.2
Puce décapsulée et machine de décapsulation . . . . . . . . . . . .
Reconstruction d’un schéma original à partir des images acquises
[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Création des points de tests par FIB [2] . . . . . . . . . . . . . . .
Coupure d’un simple fil par scalpel laser [2] . . . . . . . . . . . . .
Réduction d’un cycle d’horloge [3] . . . . . . . . . . . . . . . . . .
Banc laser pour l’injection de fautes . . . . . . . . . . . . . . . . .
Injection électromagnétique . . . . . . . . . . . . . . . . . . . . .
Classification de types de fautes . . . . . . . . . . . . . . . . . . .
Chiffrement DES simplifié en dernière ronde . . . . . . . . . . . .
Sonde électromagnétique . . . . . . . . . . . . . . . . . . . . . .
Cartographie des rayonnements électromagnétiques émis par des
interconnexions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Consommation de puissance lors d’un déchiffrement ECC . . . . .
Consommation de courant d’un circuit asynchrone (haut) et résultats DPA associés (bas) . . . . . . . . . . . . . . . . . . . . . .
Attaque en template : cas dégradé . . . . . . . . . . . . . . . . . .
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
2.1
2.2
2.3
2.4
2.5
2.6
Schémas de détection d’erreur . . . . . . . . . . . . . . . . . . . .
Implantation possible de redondance temporelle . . . . . . . . . .
Implantation possible de redondance matérielle (par prédiction) .
Implantation possible de redondance matérielle (duplication) . . .
Sphère de réplication [4] . . . . . . . . . . . . . . . . . . . . . . .
Architecture de vérification d’intégrité au niveau BB proposée
dans [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 Architecture de vérification d’intégrité du programme à différents
niveaux de granualité dans [6] . . . . . . . . . . . . . . . . . . . .
2.7 Ajout d’une nouvelle instruction de branchement dans [5] . . . . .
2.9 La logique en double-rail avec deux entrées . . . . . . . . . . . . .
2.10 Insertion d’instructions factices lors d’un calcul . . . . . . . . . .
2.11 Redistribution aléatoire d’instructions indépendantes . . . . . . .
2.12 Matériel de sélection et d’exécution aléatoire des instructions [7] .
3.1
3.2
3.3
5
6
6
7
8
9
9
11
13
17
18
20
22
24
30
31
32
33
34
38
39
39
47
49
52
52
Architecture du processeur expérimenté . . . . . . . . . . . . . . . 60
Architecture du PRNG . . . . . . . . . . . . . . . . . . . . . . . . 63
Émulateur d’injection de fautes sur le code . . . . . . . . . . . . . 64
v
vi
Liste des Figures
3.4
Environnement de simulation . . . . . . . . . . . . . . . . . . . . 68
4.1
4.2
4.3
Ajout de la signature en début de bloc de base . . . . . . . . . . .
Format de l’instruction qui stocke la signature . . . . . . . . . . .
Flot de conception logicielle d’identification des BBs et d’insertion
des signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intégration du matériel de vérification d’intégrité dans le pipeline
Architecture de la duplication du banc de registres pour la sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intégration du système de sauvegarde et de restauration dans le
pipeline du processeur . . . . . . . . . . . . . . . . . . . . . . . .
Nombre maximal des adresses de lecture dans le TMA . . . . . .
Impact de la taille du code dû à l’ajout des signatures . . . . . . .
Impact sur la performance durant l’exécution normale . . . . . . .
Principe de fonctionnement de notre UAL sécurisée . . . . . . . .
Architecture globale de notre UAL sécurisé . . . . . . . . . . . . .
Graph de dépendance d’un BB . . . . . . . . . . . . . . . . . . .
Graphe de dépendances d’un BB après réordonnancement . . . .
Pourcentage des instructions exécutées utilisant l’UF logique et
arithmétique dans l’UAL . . . . . . . . . . . . . . . . . . . . . . .
Évaluation de l’index ∆ des applications expérimentales . . . . . .
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
5.1
5.2
5.3
5.4
5.5
5.6
Type d’instructions MIPS-I . . . . . . . . . . . . . . . . . . . . .
Architecture du matériel d’insertion d’instructions aléatoires . . .
Intégration du matériel des instructions factices dans le pipeline
du processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résultat de l’attaque par analyse de consommation sur le processeur non-protégé . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extraction du pic DPA associé à la bonne clé . . . . . . . . . . .
Résultat de l’attaque par analyse de consommation sur le processeur protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
71
73
75
77
79
85
86
87
90
91
94
96
97
98
104
105
106
110
111
111
Liste des Tableaux
1.1
1.2
Modèles des fautes en fonction des méthodes d’injection des fautes 12
Courant consommé en fonction des transitions . . . . . . . . . . . 16
2.1
2.2
2.3
Type de CDE utilisable avec le circuit de prédiction . . . . . . . . 32
Duplication des variables et des lignes de code . . . . . . . . . . . 35
Séquences possibles d’instructions quand N = 3 et D = 3 . . . . . 51
4.1
4.2
71
Surcoût de la taille du code dû à l’ajout des signatures . . . . . .
Ajout des macros pour partitionner un bloc de base en sous blocs
de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Problématique sur le recouvrement en réexécutant un bloc de base
4.4 Structure du TMA . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Séquence de sauvegarde . . . . . . . . . . . . . . . . . . . . . . .
4.6 Séquence de restauration . . . . . . . . . . . . . . . . . . . . . . .
4.7 Surcoût matériel de recouvrement entre TMA=3 et TMA=4 . . .
4.8 Nombre des opérations de sauvegarde durant l’exécution normale
4.9 Illustration du mécanisme de recouvrement de l’UAL . . . . . . .
4.10 Tableau de dépendance d’un BB . . . . . . . . . . . . . . . . . . .
4.11 Processus d’ordonnancement . . . . . . . . . . . . . . . . . . . . .
4.12 Évaluation du surcoût matériel de l’UAL protégée . . . . . . . . .
5.1
5.2
5.3
2
3
4
5
6
7
8
9
74
74
78
83
83
84
87
92
95
95
97
Modèles « distance », « poids » de Hamming, transitions montantes et descendantes pour une équipotentielle . . . . . . . . . . 107
Évaluation du surcoût matériel de l’AIF . . . . . . . . . . . . . . 112
Impact sur la performance des ajouts aléatoires d’instructions
aléatoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Séquence
Séquence
Séquence
Séquence
Séquence
Séquence
Séquence
Séquence
(r) . . . . . .
(w) . . . . .
(r)(w) . . . .
(w)(r) . . . .
(r)(w)(r) . .
(w)(r)(w) . .
(r)(w)(r)(w)
(w)(r)(w)(r)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
122
122
122
122
123
123
123
124
vii
Remerciements
Ces travaux de thèse ont été réalisés au sein du laboratoire LCCS (Laboratoire
de Conception des Circuits Sécurisés) du service SCME (Service de Conception
pour les Microtechnologies Émergentes) du CEA-Leti à Grenoble. Ce laboratoire
LCCS est intégré au CMP-GC (Centre Microélectronique de Provence - Georges
Charpak) . Que M. Jean-René Lèquepeys, Chef du service SCME, Mme. Assia
Tria, Chef du laboratoire LCCS et M. Philippe Collot, Directeur du CMP-GC,
trouvent ici mes remerciements pour m’avoir accueilli au sein du laboratoire
LCCS.
J’aimerais remercier Mme Nathalie Drach, Professeur à l’Université UPMC,
pour avoir été ma directrice de thèse. Je lui suis très reconnaissant pour de ses
encouragements et pour la confiance qu’elle m’a accordé tout au long de mes
travaux de thèse.
Je voudrais remercier M. Bruno Robisson, mon encadrant de thèse, sans qui
ce travail ne serait jamais arrivé au bout, pour sa disponibilité, ses irremplaçables
conseils et ses commentaires sur mes travaux de recherche, pour la rédaction des
articles et de cette thèse.
J’adresse aussi mes remerciements à M. Michel Agoyan, ingénieur du CEA,
pour son soutien, son expérience qu’il m’a apportée durant tout ce temps.
Ensuite, mes remerciements à ma femme, aux membres de ma famille et
mes meilleurs amis en général, pour l’amour ou l’amitié qu’ils me donnent au
quotidien.
Enfin, je voudrais aussi saluer toutes les personnes du laboratoire LCCS et
du CMP-GC que j’ai côtoyées avec plaisir : Jean-Baptise, Sylvain, Jérôme, Philippe, Laurent, Serge, Jacque, Anne-Lise, Olivia, Anissa, Loïc, Rémy, Benjamin,
Fall, Matthieu, Olivier, Julien, Selma, Amir, Axel, Stéphane Isnard, Florent etc
pour qui j’espère la plus grande réussite possible pour leurs travaux respectifs.
Merci enfin à Jacques, Guillaume, Driss et Claire pour leurs bons conseils en
orthographe.
ix
Résumé
Les composants de sécurité, parce qu’ils contiennent des informations confidentielles, font l’objet d’attaques. Celles-ci tentent généralement de porter atteinte à la confidentialité, à l’intégrité ou à l’authenticité des données protégées
par les algorithmes de cryptographie embarqués sur ces composants. Les attaques
dites matérielles ou physiques exploitent les faiblesses de l’implantation matérielle de ces algorithmes.
Dans le premier chapitre de cette thèse, une revue des différentes attaques sur
les composants qui protègent des informations confidentielles telles que des clefs
de cryptographiques a été réalisée. Parmi ces attaques, celles dites par « canaux
cachés » (« Side Channel Attacks » ou par effet de bord), sont particulièrement
efficaces : elles exploitent la corrélation qui existe entre les données manipulées
(dont celles qui sont sensibles) et la consommation, le rayonnement électromagnétique ou le temps de réponse du composant. Un autre type d’attaques, dites
par « injection de fautes » consiste à modifier volontairement le fonctionnement
du circuit pour contourner les protections logicielles et matérielles destinées aux
informations sensibles. Le fonctionnement du composant peut être altéré, par
exemple, par illumination laser, par modification de la tension d’alimentation ou
de la fréquence d’horloge. Un troisième type d’attaques, plus difficile à mettre en
oeuvre, consiste à analyser la conception de la puce à l’aide de procédés invasifs
(abrasion, gravure chimique, laser, SEM, etc.) puis à sonder les signaux (grâce
notamment à des faisceaux d’ions focalisés) sur lesquels transitent les informations secrètes. Cet état de l’art de la menace nous a conduit à ne considérer par la
suite que les attaques en fautes et par effet de bord qui sont, pour nous, les plus
dangereuses car relativement faciles à mettre en œuvre sur circuit non protégé.
Les protections qui ont été proposées ces dernières années pour contrer les
attaques par faute ont été analysées dans le second chapitre. Deux types de protections sont principalement mis en œuvre. Le premier consiste à détecter les
tentatives d’injection de faute puis à appliquer une stratégie de réaction adéquate en cas d’attaque. A cet effet, des capteurs qui détectent les modifications
anormales de l’environnement du circuit et des mécanismes de détection d’erreurs
(basées sur des calculs redondants ou sur des calculs prédictifs) ont été implémentés. Les réactions communément proposées vont de la simple coupure des
communications à l’effacement complet des informations stockées en mémoire.
Le deuxième type de protection vise à augmenter la robustesse du circuits aux
différentes techniques d’injection de faute. A cet effet, des méthodes de correction
d’erreurs (elles-aussi basées sur de la redondance) et des dispositifs technologiques
tels que capôts métalliques, filtres, etc. ont été proposés. Les contre-mesures proposées pour contrer les attaques par canaux cachés ont également été analysées
xi
xii
Résumé
dans le second chapitre. Il s’agit soit d’ajouter du bruit sur les canaux soit de
réduire le signal informatif. L’ajout de ce bruit a pu être réalisé matériellement
(générateur de signaux aléatoires branché sur l’alimentation, par exemple) mais
des solutions logicielles ont également été développées (basées sur du masquage,
de l’insertion de code « inutile » dans le source ou des modifications aléatoires
de l’ordre d’exécution des opérations). Des contre-mesures ont également visé
à réduire les corrélations entre les données et les signaux émis par le composant (utilisation d’un codage des données adapté et équilibrage des chemins sur
lesquels transitent ces données). Des propositions en terme de filtrage de l’alimentation ont également fait l’objet de publications. Le second chapitre a montré
que ces contre-mesures présentent un coût généralement important en termes
de matériel ou de performances et qu’elles ont été principalement développées
pour des algorithmes de cryptographie. L’originalité du travail de cette thèse est
de proposer des contre-mesures dédiées à un processeur généraliste avec comme
double objectif :
– de réduire au maximum les coûts associés.
– de sécuriser ce processeur conjointement vis-à-vis des attaques en faute et
par effet de bord.
Le troisième chapitre décrit le vecteur de test qui a été choisi pour réaliser
nos expérimentations. Il s’agit d’un système sur puce représentatif d’un système
embarqué sur une carte à puce. Il est constitué d’un processeur 32 bits de type
DLX à 5 étages de pipeline, d’algorithmes de cryptographie à clef privée (AES
et/ou DES), de mémoires (cache d’instruction, RAM et ROM), de blocs d’entrées/sorties (ISO 7816 et RS232), d’un générateur de nombre pseudo-aléatoire,
etc. Le troisième chapitre décrit également l’environnement de conception matériel et logiciel qui a été développé dans le cadre de cette thèse. Un mécanisme
d’émulation de l’effet de fautes sur un composant a en particulier été détaillé.
Le quatrième chapitre a décrit trois contre-mesures aux attaques en faute
et une aux attaques par canaux cachés qui ont été implantées dans le cadre de
la thèse. La première protection vise à vérifier l’intégrité des instructions entre
la mémoire et l’étage de décodage. A cet effet à chaque bloc de base (ie. séquence d’instructions délimitées par un saut ou une destination de saut) a été
ajoutée une signature CRC permettant de détecter une modification d’une ou
plusieurs instructions de ce bloc. La stratégie de détection choisie, dite « à la
volée », a consisté à récupérer les instructions normalement, c’est-à-dire une à
une, à mettre à jour récursivement le CRC à chacune de ces récupérations puis
à exécuter les instructions normalement (c’est-à-dire toujours une à une). La détection de l’erreur a seulement lieu en fin d’exécution du bloc de base. Ce choix
induit un temps de latence de détection de la faute qui est proportionnel à la
taille des blocs mais n’a pas d’impact sur les performances du processeur. Un mécanisme de récupération en cas de détection d’erreur a également été implanté.
Résumé
xiii
Ce mécanisme permet de réexécuter un bloc de base corrompu en restaurant les
données telles qu’elles étaient avant l’exécution du bloc. Pour assurer une réexécution correcte, les données restaurées sont celles stockées soit dans les registres,
soit dans la mémoire principale. Le stockage des données des registres est réalisé
dans un miroir du banc de registre. Le stockage des données dans la mémoire
est réalisé dans une zone tampon. Pour réduire l’impact de cette sauvegarde en
terme de surface, n’y sont stockées que les données nécessaires au recouvrement,
à savoir celles qui sont modifiées après avoir été lues. Nous avons également fait
en sorte que, contrairement à l’état de l’art, la restauration des données se fasse
également à la volée pour ne pas favoriser l’une des classes d’attaques en faute
dite en « safe-error ». La troisième contre-mesure aux attaques en faute consiste
à vérifier, quasiment en temps masqué, les calculs réalisés par l’unité arithmétique et logique (UAL). Ces différentes méthodes ont été évaluées en termes de
performance, de surface et de sécurité. Nous montrons que le mécanisme de détection et de recouvrement a un faible impact sur les performances et un coût
acceptable de 18.8% (pour les LUTs) et de 68.6% (pour les bascules). Quant à
celui de détection d’erreur dans l’UAL : le surcoût matériel est de 2.94% (pour
les LUTS) et de 3.2% (pour les bascules). La réduction du temps additionnel est
de 70%.
Dans le cinquième chapitre a été décrite une contre-mesure aux attaques par
canaux cachés. Il s’agit d’insérer aléatoirement dans le pipeline du processeur des
instructions aléatoires. Ce taux d’insertion peut être modifié par le développeur
suivant le type de données manipulées par le programme. A noter également que
pour que l’attaquant ait le plus de mal possible à distinguer les instructions factices de celles qui sont utiles (car elles auront des profils de courant différents),
les instructions factices ont été choisies dans un ensemble aussi large que possible d’instructions. Les opérandes de ces opérations ont également été choisies
aléatoirement. Afin de ne pas créer de fuite d’information, le banc de registres
a été dupliqué pour assurer le stockage des opérandes et du résultat des opérations factices. La génération d’aléas a été réalisée à l’aide d’un générateur de
nombres pseudo-aléatoires basé sur un Linear Shift Register (LSFR). La sécurité
de cette contre-mesure a été validée sur des données synthétiques. Son coût est
de 18.49% (pour les LUTs) et de 53.16% (pour les bascules). La perte en terme
de performance dépend du taux d’insertion d’instructions factices mais est, dans
nos expérimentations, de l’ordre d’un facteur 4.
Introduction
La sécurité constitue une composante cruciale des technologies de l’information et de la communication et représente un des leviers de leur essor car elle
est à la base de l’instauration de la confiance nécessaire pour les utilisateurs finaux. Ceci explique certainement pourquoi le marché de la carte à puce, laquelle
implémente des fonctions cryptographiques assurant la confidentialité, l’authentification et l’intégrité des données, continue à afficher une dynamique à deux
chiffres depuis sa création, il y a plus de 20 ans. La croissance en volumes prévue
par Eurosmart, l’association des fabricants de cartes à puce, est de +18% pour
2010 (pour atteindre 5,3 milliards d’unités dont 4.0 milliards de cartes SIM et
880 millions de cartes de paiement) et de +13% pour 2011 (pour atteindre 6,0
milliards d’unités dont 5,5 milliards de SIM et 1 milliard de cartes de paiement).
Parmi les marchés traditionnels (que sont les télécommunications, le paiement,
l’identification/santé, le transport, etc.), celui de la sécurisation de la diffusion
de contenus multimédia pour des applications Pay-TV ou VOD (Video On Demand) va certainement croître aussi rapidement que ceux des supports très en
vogue tels que les téléphones intelligents ou les tablettes multimédia. Cette sécurisation est réalisée, par exemple grâce à des systèmes d’accès conditionnels (CAS
pour Conditionnal Access System) dont la sécurité est basée sur un composant
pour carte à puce, lequel stocke les droits du possesseur de la carte sous forme
de clefs. La récupération frauduleuse de ces clefs (et leur diffusion sur internet)
par un « hacker » permet à des fraudeurs l’accès au contenu sans paiement des
droits.
Parmi les manipulations frauduleuses qui peuvent être mises en œuvre sur
les composants de sécurité, trois types d’attaques font l’objet d’une attention
particulière depuis la fin des années 1990, à la fois de la part du marché mais
également du monde universitaire. Elles sont qualifiées de « physique » car elles
nécessitent pour l’attaquant d’avoir le composant « entre les mains » ce qui est
généralement le cas pour les cartes à puce. Certaines de ces attaques sont dites
invasives (ou « intrusives ») au sens où elles endommagent (parfois irrémédiablement) le composant. D’autres méthodes, qui sont également très efficaces mais
qui ne mettent pas à mal l’intégrité du composant (on parle d’attaques « non intrusives »), sont basées soit sur l’analyse du comportement du circuit en présence
de perturbations (on parle dans ce cas d’attaques « en faute ») ou sur l’observation des modifications de l’environnement créées par le circuit lorsqu’il réalise
des calculs cryptographiques (on parle alors d’attaques par « effet de bord », par
« canaux cachés » ou en « side-channel »). A noter que toutes ces attaques, bien
que distinctes dans leur principe, sont généralement combinées en pratique.
xv
xvi
Introduction
Contre ces manipulations frauduleuses, les concepteurs de composants sécurisés ont proposé de nombreux dispositifs (ou contre-mesures) qui, soit donnent
une information sur l’état du circuit (par exemple détectent une tentative de
modification du comportement ou d’intrusion physique) soit agissent pour protéger les données. Dans le premier cas, on parlera de « capteurs » et dans le
second d’« actionneurs ». Parmi les capteurs mentionnés dans la littérature, on
citera les systèmes de détection d’erreur basés généralement sur de la redondance
spatiale (bit de parité, CRC, duplication, etc.) ou temporelle mais également les
capteurs de grandeurs physiques telles que la tension, la fréquence d’horloge, la
température, la lumière, etc. Parmi les « actionneurs », du bruit est ajouté artificiellement sur les signaux émis par la puce. L’ajout de ce bruit a pu être réalisé
matériellement (grâce à un générateur de signaux aléatoires branché sur l’alimentation, une modification rapide de la tension et de la fréquence d’horloge ou
des blocs réalisant les calculs) mais des solutions logicielles ad hoc ont également
été développées. Parmi celles-ci, on peut citer les techniques de masquage, l’insertion de code « inutile » ou la modification aléatoire de l’ordre d’exécution des
opérations. Des contre-mesures ont également visé à réduire les corrélations entre
les données et les signaux émis par le composant via par exemple l’utilisation de
logiques dites « équilibrées ».
Comme la course poursuite engagée entre les concepteurs de circuits de sécurité et les attaquants s’accélère avec la diversité des systèmes, leur ouverture et
leur multiplicité, il apparaît aujourd’hui comme un enjeu majeur de devoir améliorer drastiquement la résistance de ces composants à toutes ces attaques. Ces
composants sont conçus grâce aux techniques et méthodes développées depuis
plus d’un demi siècle pour les circuits intégrés non sécurisés. La conception de tels
circuits est une tâche complexe qui s’effectue de manière séquentielle, c’est-à-dire
en franchissant un certain nombre d’étapes constituant ce qui est couramment
appelé « le flot de conception », représenté en Figure 1. La première de ces étapes
consiste, en coopération avec le client, à spécifier précisément les caractéristiques
du circuit. Généralement, ces spécifications (ou cahier des charges) définissent
la ou les fonctionnalités du circuit, par exemple son coût (lié étroitement à sa
surface) et ses performances en terme de temps de calcul et de consommation.
La seconde phase consiste à déterminer un modèle de circuit susceptible de vérifier ces spécifications. Des outils logiciels spécifiques, dits de synthèse, aident
le concepteur dans cette recherche. Cependant, comme la complexité de la tâche
réalisée par ces outils de synthèse ne permet pas de garantir à 100% que le circuit
obtenu respecte effectivement le cahier des charges, il est nécessaire de vérifier
si c’est le cas ou non dans un troisième temps. Pour cela, le concepteur utilise
des outils logiciels spécifiques dit d’analyse (souvent basés sur des techniques de
simulation du fonctionnement du circuit ou de preuves formelles). Si le circuit
obtenu par synthèse vérifie en simulation le cahier des charges, il peut partir en
Introduction
xvii
fabrication. Sinon, le concepteur doit modifier les paramètres d’entrée des outils
de synthèse jusqu’à ce qu’il obtienne un circuit correct. Il est important de noter
que ce processus itératif de synthèse et d’analyse n’est pas monolithique mais
qu’il se décompose lui même en plusieurs sous processus, chacun étant associé
à un niveau de précision dans la modélisation (ou d’abstraction) du circuit. La
fabrication du circuit constitue la quatrième étape dans la réalisation du circuit. Comme les dispersions de fabrication, même si elles sont actuellement très
faibles et bien maîtrisées, peuvent introduire de très légers écarts entre le circuit
« concret » et son modèle, il est nécessaire de vérifier sur le circuit fabriqué que
le cahier des charges est vérifié. Cette dernière étape, qui consiste à mesurer les
performances réelles du circuit, est généralement appelée « phase de caractérisation ».
Figure 1 – Flot de conception d’un circuit intégré
Même si elle n’est pas encore optimale, l’intégration dans le flot de conception des spécifications (fonction, coût, vitesse et consommation) est validée et
éprouvée à l’heure actuelle sur des centaines de milliers de circuits. Dans le cas
d’un circuit sécurisé, les spécifications doivent également intégrer des contraintes
sécuritaires généralement exprimées en termes de « résistance à telle ou telle attaque ». Or la « résistance » du circuit, si elle peut être quantifiée juste avant sa
commercialisation lors de sa certification selon des normes désignées sous le nom
de « critères communs », est beaucoup plus difficile à évaluer a priori, c’est-àdire lors de sa conception. Toute vulnérabilité non détectée lors de cette phase
entraîne pour l’entreprise non seulement un surcoût significatif (en temps de développement et en certification) mais aussi une baisse importante de son revenu
xviii
Introduction
car 25% à 50% du chiffre d’affaire du marché de la sécurité est lié à l’introduction de nouveaux produits innovants et sécuritaires. Par ailleurs, la probabilité
d’apparition d’une telle vulnérabilité est loin d’être négligeable car la résistance
du circuit est assurée par des protections (ou contre-mesures) qui représentent
plus de 50% du circuit.
C’est dans ce contexte que nous avons orienté nos travaux de recherche vers
le développement et l’évaluation a priori de nouvelles protections vis-à-vis des
attaques par effet de bord et en faute. Les protections proposées dans le cadre
de cette thèse sont principalement destinées aux microprocesseurs tels que ceux
qui sont embarqués dans des cartes à puces. En effet, nous considérons que ces
microprocesseurs, en tant que garant de l’exécution de toutes les protections logicielles, constituent un élément de sécurité incontournable. Ce choix résulte aussi
du constat que, comparativement aux implantations matérielles d’algorithmes
de cryptographie, peu de travaux les concernent. Enfin, les spécifications de ces
composants constituent un réel challenge en termes de conception. Ils doivent présenter un niveau de sécurité très élevé, des performances correctes (notamment
pour les applications Pay-TV), et ce, à un prix extrêmement bas (typiquement
de quelques dizaines de centimes d’euros à quelques euros).
Dans le premier chapitre, les principes des différentes attaques connues seront
détaillées. Un focus particulier sera réalisé sur celles qui ne mettent pas en cause
l’intégrité du composant. Dans le second chapitre, les principales contre-mesures
à ces attaques seront présentées. Nous détaillerons celles spécifiquement destinées
aux microcontrôleurs. Dans le troisième chapitre, le microprocesseur qui a servi
de support d’étude pour cette thèse sera décrit. L’environnement de conception
et notamment celui permettant l’évaluation a priori des contre-mesures seront
également précisés. Dans le quatrième chapitre, une méthode de détection d’erreur dans la mémoire d’instruction, couplée à un mécanisme de récupération en
cas d’erreurs seront présentés. Y sera également proposé une méthode de détection d’erreur de calcul dans l’unité arithmétique et logique. Dans le cinquième
chapitre, une technique rendant le circuit plus robuste aux attaques par effet de
bord est détaillée. Au cours de ces deux derniers chapitres, l’évaluation des protections en termes de surface, de performances et de sécurité sera réalisée. Nous
conclurons enfin ce travail de thèse et présenterons les perspectives actuellement
identifiées.
Première partie
État de l’art
1
Chapitre 1
Les attaques
Sommaire
1.1
Attaques invasives . . . . . . . . . . . . . . . . . . . .
1.1.1 Préparation . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Rétro-conception matérielle . . . . . . . . . . . . . .
1.1.3 Micro-sondage . . . . . . . . . . . . . . . . . . . . .
1.1.4 Modification du circuit . . . . . . . . . . . . . . . . .
1.2 Attaques par injections de fautes . . . . . . . . . . .
1.2.1 Méthodes d’injections de fautes . . . . . . . . . . . .
1.2.1.1 Modification de l’alimentation . . . . . . .
1.2.1.2 Modification de la fréquence d’horloge . . .
1.2.1.3 Illumination . . . . . . . . . . . . . . . . .
1.2.1.4 Champ électromagnétique . . . . . . . . . .
1.2.2 Caractéristiques des méthodes d’injections de fautes
1.2.2.1 Modèles de fautes . . . . . . . . . . . . . .
1.2.2.2 Location spatiale des fautes . . . . . . . . .
1.2.2.3 Type des fautes . . . . . . . . . . . . . . .
1.2.2.4 Comparaison . . . . . . . . . . . . . . . . .
1.2.3 Scénarii d’attaques . . . . . . . . . . . . . . . . . . .
1.2.3.1 DFA (Differential Fault Analysis) . . . . .
1.2.3.2 Attaques « safe-error » . . . . . . . . . . .
1.3 Attaques par canaux cachés . . . . . . . . . . . . . .
1.3.1 Modèles de consommation et de rayonnement EM .
1.3.1.1 Modèles de consommation . . . . . . . . .
1.3.1.2 Modèles de rayonnement . . . . . . . . . .
1.3.2 Méthodes de mesure des canaux cachés . . . . . . .
1.3.2.1 Temps de réponse . . . . . . . . . . . . . .
1.3.2.2 Consommation . . . . . . . . . . . . . . . .
1.3.2.3 Émission électromagnétique . . . . . . . . .
1.3.2.4 Comparaison . . . . . . . . . . . . . . . . .
1.3.3 Scénarii d’attaques . . . . . . . . . . . . . . . . . . .
1.3.3.1 Analyse du temps de réponse . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
.
5
.
5
.
5
.
7
.
7
.
7
.
7
.
8
.
8
.
8
.
9
.
9
. 10
. 10
. 10
. 12
. 12
. 14
. 15
. 15
. 15
. 16
. 16
. 16
. 16
. 17
. 18
. 18
. 18
3
4
Chapitre 1. Les attaques
1.4
1.3.3.2
1.3.3.3
1.3.3.4
1.3.3.5
Conclusion
SPA « Simple Power Analysis » . . . . . . .
DPA « Differential Power Analysis » . . . . .
Attaque par dictionnaire ou en « template »
Attaque par collision interne . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
. 19
. 20
. 23
. 26
. 27
Les composants de sécurité, parce qu’ils contiennent des informations confidentielles, font l’objet d’attaques. Celles-ci tentent généralement de porter atteinte à la confidentialité, à l’intégrité ou à l’authenticité des données protégées
par les algorithmes de cryptographie embarqués sur ces composants. Les attaques
dites matérielles ou physiques exploitent les faiblesses de l’implantation matérielle de ces algorithmes. Contrairement aux attaques cryptanalytiques (lesquelles
sont purement mathématiques), l’attaquant doit avoir le composant « entre les
mains » pour pouvoir mettre en œuvre ces attaques.
Certaines de ces attaques sont dites invasives (ou « intrusives ») au sens où
elles nécessitent des modifications physiques du composant pouvant l’endommager. Il s’agit d’analyser la conception de la puce à l’aide de procédés invasifs
(abrasion, gravure chimique, laser, SEM. . . ) puis à sonder les signaux (grâce notamment à des faisceaux d’ions focalisés) sur lesquels transitent les informations
secrètes [2].
D’autres méthodes, également très efficaces, ne mettent pas à mal l’intégrité du composant (on parle d’attaques « non intrusives »). Parmi celles-ci, les
attaques SCA (pour « Side Channel Analysis »), utilisent le fait que la consommation, le rayonnement électromagnétique ou le temps de réponse d’une puce est
fonction des données manipulées. Le second type d’attaques, appelées attaques
en faute, consiste à modifier l’environnement de la puce (température, exposition
à des rayonnements UV, X ou visibles, modification de la fréquence d’horloge,
laser. . . ) de telle sorte que le fonctionnement de celle-ci s’en trouve altéré. Les
attaques DFA (pour « Differential Fault Analysis ») tirent parti de la comparaison entre un chiffré correct et un chiffré fauté et les attaques en « safe-error »
de la comparaison entre un comportement normal et un comportement fauté.
Dans ce chapitre, toutes ces attaques seront détaillées, avec un focus particulier sur les attaques non intrusives.
1.1
Attaques invasives
Les attaques invasives nécessitent d’accéder physiquement aux éléments constitutifs des circuits intégrés (tels que les pistes, les plots d’entrées/sorties, les bus
d’interconnexion. . . ) en utilisant des équipements de laboratoire très spécifiques.
L’accès aux éléments constitutifs nécessite une phase de préparation du circuit,
1.1. Attaques invasives
5
une phase de compréhension de l’organisation des éléments constitutifs puis une
phase de récupération des informations. Celle-ci est réalisée soit par sondage, soit
par modification du circuit.
1.1.1
Préparation
La première étape de préparation du circuit est la décapsulation du module
qui l’intègre et l’enlèvement des couches de passivation qui protègent le circuit
contre l’environnement et la migration ionique. Cette étape met en œuvre des
procédés physico-chimiques relativement simples telles qu’abrasion mécanique ou
dissolution par un acide. La photo de gauche de la Figure 1.1.1 représente une
puce de carte à puce qui a été préparée en vue d’une attaque en injections de
faute.
Figure 1.1 – Puce décapsulée et machine de décapsulation
1.1.2
Rétro-conception matérielle
Cette phase vise à connaître la structure des éléments constitutifs du circuit
pour en déduire sa fonction. Tous les niveaux de matériaux déposés durant la
fabrication sont enlevés en ordre inverse et sont respectivement photographiés
à l’aide d’un microscope associé avec une caméra CCD. En traitant toutes les
informations ainsi acquises, ce qui peut se révéler extrêmement long et coûteux
pour un circuit récent, l’attaquant peut en déduire le schéma du circuit puis les
algorithmes implantés. Ces connaissances l’aideront à choisir les positions de ses
micro-sondes.
6
Chapitre 1. Les attaques
Figure 1.2 – Reconstruction d’un schéma original à partir des images acquises
[1]
1.1.3
Micro-sondage
Le micro-sondage (ou « micro-probing ») consiste à poser des sondes très fines
sur certaines pistes du circuit et d’accéder ainsi à la valeur des signaux internes
du composant. L’attaquant peut ainsi examiner, grâce à une « sonde passive »,
les échanges qui ont lieu sur le bus de communication entre le processeur et la
mémoire ou entre le processeur et un bloc de cryptographie. Il peut même forcer
un fil de ce bus à une valeur particulière (on parle alors de « sondes actives »). La
pose des micro-sondes nécessite généralement la réalisation de plots de contact
et parfois celles de pistes verticales (appelées « via »). Ces reprises de connexion
sont généralement faites à l’aide d’un FIB (pour Focus Ion Beam). La Figure
1.3 représente des points de test posés sur un bus de communication.
1.1.4
Modification du circuit
Certains circuits sont munis de protections (tels que des capteurs de tension
d’alimentation, de lumière, de fréquence d’horloge . . . ) contre les attaques en
faute [section 1.2]. L’attaquant peut être amené à les désactiver en coupant les
fils de métal d’interconnexion, par exemple, avec un scalpel laser ou un FIB tel
que représenté sur la Figure 1.4.
1.2. Attaques par injections de fautes
7
Figure 1.3 – Création des points de tests par FIB [2]
Figure 1.4 – Coupure d’un simple fil par scalpel laser [2]
1.2
Attaques par injections de fautes
Les attaques « en faute » consistent, dans un premier temps, à modifier
l‘environnement de la puce lorsqu’elle exécute certaines opérations critiques puis
à analyser les réponses du circuit obtenues dans ces conditions. Les fautes peuvent
être injectées par variation de l’alimentation, de la fréquence d’horloge (« overclocking »), par l’utilisation d’un faisceau laser ou par la création d’ondes électromagnétiques intenses à proximité du circuit. Ces différentes techniques sont
brièvement décrites ci-dessous.
1.2.1
Méthodes d’injections de fautes
1.2.1.1
Modification de l’alimentation
Un circuit intégré est composé d’éléments de mémorisations (bascules ou FlipFlops) qui comparent, pendant un court intervalle de temps, leurs entrées à la
8
Chapitre 1. Les attaques
tension d’alimentation. Cet échantillonnage, nécessaire au bon fonctionnement
du circuit, peut donc être altéré par une variation de la tension d’alimentation.
Diverses variations se sont avérées efficaces : de l’impulsion brève mais d’amplitude élevée à des variations de faible amplitude mais quasi-statique.
1.2.1.2
Modification de la fréquence d’horloge
La majorité des circuits actuels fonctionnent au pas cadencé d’une horloge
(on parle dans ce cas de circuits « synchrones »). Ces circuits possèdent une fréquence de fonctionnement maximale, liée à la durée de transfert des données dans
ses blocs combinatoires. Si le circuit est cadencé par une horloge externe, l’attaquant peut imposer une fréquence d’horloge supérieure à la fréquence maximale
du circuit. La période d’horloge est alors inférieure à la durée du transfert des
données dans les blocs combinatoires (on parle d’« overclocking ») et le registre
en aval stocke soit une valeur instable soit la valeur précédente. Dans ces deux
cas, des opérations réalisées par le circuit peuvent s’avérer incorrectes. La Figure
1.5 représente une réduction sur un seul cycle de la période de l’horloge.
Figure 1.5 – Réduction d’un cycle d’horloge [3]
1.2.1.3
Illumination
Il s’agit d’éclairer intensément le silicium du composant à l’aide d’un laser
ou d’un simple flash d’appareil photo dont la lumière est concentrée par un microscope [8]. L’énergie transportée par la source lumineuse est absorbée par les
électrons du silicium qui constitue le circuit. Cette énergie leur permet de passer
de la bande interdite à la bande de conduction. Chaque nouvel électron dans
la bande de conduction crée une paire électron-trou. L’ensemble de ces paires
forme un courant photoélectrique. Les portes logiques ainsi que les bascules du
composant étant sensibles à ce courant peuvent changer d’état. A noter que l’utilisation d’un laser et d’un microscope permet à l’attaquant de cibler précisément
une surface de quelques µm2 d’un circuit. La Figure 1.6 reporte deux photos de
1.2. Attaques par injections de fautes
9
l’un des bancs d’injection de fautes par laser mis à disposition dans la plateforme
MicroPacks de Gardanne.
Figure 1.6 – Banc laser pour l’injection de fautes
1.2.1.4
Champ électromagnétique
Il s’agit de générer un champ électromagnétique intense à proximité du composant. La Figure 1.7 représente une bobine et un générateur d’impulsions qui
peuvent être utilisés pour générer un tel champ. Il a été montré dans [9, 10] qu’un
tel dispositif permet de modifier les valeurs stockées dans des cellules mémoire
ou de modifier la fréquence de fonctionnement d’un oscillateur en anneau.
Figure 1.7 – Injection électromagnétique
10
Chapitre 1. Les attaques
1.2.2
Caractéristiques des méthodes d’injections de fautes
1.2.2.1
Modèles de fautes
Différents modèles sont utilisés pour modéliser l’effet des perturbations décrites ci-dessus. Les différents modèles distinguent généralement la localisation
de la faute dans le temps et l’espace et le type de fautes engendrées.
1.2.2.1.1 Localisation temporelle Les perturbations décrites en 1.2.1 modifient le fonctionnement du circuit de façon transitoire, ou non. Dans le premier
cas, on parlera de « fautes transitoires » et dans le second, de fautes « permanentes ». Généralement, l’attaquant cherche à générer des fautes transitoires car
elles lui permettent de réaliser plusieurs expérimentations sur une même puce.
Cette hypothèse est faite notamment dans le cas des attaques en fautes décrites
dans la section 1.2.3.
Dans le cas des fautes transitoires, la capacité de la perturbation à n’impacter le circuit que durant une durée très courte et avec une gigue (ou « jitter »)
faible est également recherchée. Elle permet ainsi par exemple de n’impacter
qu’une ronde d’un algorithme de cryptographie. On parlera de « résolution temporelle élevée » quand cette durée est courte et la gigue faible et de « résolution
temporelle faible » dans le cas contraire.
1.2.2.2
Location spatiale des fautes
Les perturbations décrites en 1.2.1 modifient le comportement de tout ou
partie du circuit. Bien que ces zones soient très difficiles à déterminer en pratique
(elles dépendent de nombreux paramètres expérimentaux ainsi que du circuit sous
test), on parlera de « résolution spatiale élevée » (resp. faible) quand la zone de
perturbation est petite (resp. grande). Dans le même ordre d’idée, on parlera de
fautes « simple » quand un seul bit du circuit est modifié (comme décrit dans
[11]) et de faute « multiple » quand plusieurs bits le sont.
1.2.2.3
Type des fautes
Il existe plusieurs types de fautes, définies ci-dessous et représentées sur la
Figure 1.8 :
– La valeur du bit est inversé par rapport à la valeur qu’il aurait eu sans
perturbation. On parle alors de bit flip.
– La valeur du bit est forcée à une valeur fixe. On parle de set si la valeur
est fixée à 1 et de reset si la valeur est fixée à 0.
– La valeur du bit est forcée à sa valeur précédente. On parle de collage à 1
si la valeur précédente était égale à 1 et collage à 0 sinon.
1.2. Attaques par injections de fautes
11
– La valeur du bit est forcée à 0 ou 1 avec une probabilité de 50 % random.
t1
t2
original
b=1
b=1
collage 1
b=1
bit Reset
b=0
b=1
b=1
bit Set
collage 0
b=0
b=0
bit Reset
b=0
b=0
b=0
b=1
bit Set
Figure 1.8 – Classification de types de fautes
1.2.2.4
Comparaison
Les variations de la tension d’alimentation ne nécessitent pas d’accès direct au
composant mais seulement à son alimentation. La variation temporelle obtenue
est de faible résolution car les régulateurs de tension embarqués sur le composant
se comportent vis-à-vis des impulsions comme des filtres passe-bande, lesquels
lissent l’effet des impulsions. La localisation spatiale des impulsions de tension
est nulle.
Les modifications de l’horloge ne nécessitent pas d’accès direct au composant,
si celui-ci est cadencé par une horloge externe. Si ce n’est pas le cas, une sonde
active doit être posée par l’attaquant sur l’une des pistes d’horloge. Une telle
pose est très peu probable sur les composants actuels car les pistes sur lesquelles
circulent l’horloge sont généralement enfouies dans le composant (et donc très
difficilement accessibles). Par contre, la localisation temporelle des fautes est
excellente, car il n’y a pas de filtrage « analogique » du signal. Il a été montré
dans [12] que les fronts d’une horloge fautée peuvent être réglés à une dizaine
de picosecondes près, de plus avec une gigue négligeable. Une telle précision
12
Chapitre 1. Les attaques
temporelle permet de générer des fautes simples, malgré une précision spatiale
nulle.
Les attaques par illumination nécessitent une préparation du composant pour
avoir accès à l’une des faces du circuit. Dans le cas de la face arrière, il est
souvent choisi d’amincir le substrat pour faciliter la pénétration de la lumière.
Lorsque celle-ci est générée par un laser, la précision temporelle va de moyenne
à très bonne (suivant la technologie du laser utilisé). La précision spatiale est
généralement très bonne. Il est, en effet, acquis que des fautes simples peuvent
être générées à l’aide d’un laser.
Les travaux actuellement en cours sur les attaques électromagnétiques montrent
qu’elles peuvent être menées avec et sans ouverture du boîtier mais que, dans le
second cas, la précision spatiale est réduite. La précision temporelle est réduite
par la bande passante de la sonde d’injection mais est a priori bonne.
Ces différentes considérations sont reportées dans le Tableau 1.1.
Alimentation
Horloge
Illumination
Électromagnétique
Préparation
non
non (si horloge externe)
oui
oui (non)
Location temporelle
moyenne
excellente
moyenne à bonne
moyenne
Localisation spatiale
nulle
nulle
très bonne
moyenne (faible)
Tableau 1.1 – Modèles des fautes en fonction des méthodes d’injection des fautes
1.2.3
Scénarii d’attaques
L’injection des fautes est utilisée pour affecter l’opération normale d’un processeur. Grâce à des perturbations, l’attaquant peut :
– Modifier un branchement conditionnel pour accéder à des segments de code
de sécurité. Une telle modification de branchement peut notamment permettre de réduire le nombre des rondes d’un algorithme de chiffrement par
bloc (DES, AES [13]). Cette réduction peut aller jusqu’à une seule ronde,
rendant triviale la récupération de la clé secrète.
– Étendre le nombre d’itérations d’une routine d’écriture pour présenter des
données sur le port série. Ces données peuvent alors être du code ou des
clefs stockées dans la mémoire [14].
– Corrompre des données transférées entre la mémoire et le processeur ou
modifier des instructions en cours d’exécution [15].
D’autres attaques en faute sont, par contre, spécifiques aux algorithmes de cryptographie. Les principaux scénarii d’attaques associés sont décrits ci-dessous :
1.2. Attaques par injections de fautes
1.2.3.1
13
DFA (Differential Fault Analysis)
La plupart des algorithmes de cryptographie (tels que DES, AES, RSA . . . )
sont sujets aux attaques DFA qui consistent à extraire la clé secrète à partir des
différences entre les textes issus de chiffrements corrects et fautés d’un même
message.
Par exemple, DES est un algorithme de chiffrement itératif constitué de 16
rondes. La Figure 1.9 décrit la dernière ronde simplifiée du chiffrement DES.
Figure 1.9 – Chiffrement DES simplifié en dernière ronde
Pour attaquer le DES grâce à la DFA, l’attaquant doit injecter des fautes
sur la sortie de la 15e ronde. Il n’est pas nécessaire de préciser la position et le
nombre de bits fautés. La sortie de cette ronde peut être exprimée par l’équation
suivante, la fonction S s’effectuant par 8 tables de substitution en fonction de 8
clés partielles de 6 bits :
R16 = S(R15 ⊕ K16 ) ⊕ L15
= S(L16 ⊕ K16 ) ⊕ L15
f
Pendant la 15e ronde, si une faute se produit de sorte que R15 devienne R15
,
alors :
f
f
R16
= S(R15
⊕ K16 ) ⊕ L15
= S(Lf16 ⊕ K16 ) ⊕ L15
On déduit :
f
R16 ⊕ R16
= S(L16 ⊕ K16 ) ⊕ L15 ⊕ S(Lf16 ⊕ K16 ) ⊕ L15
= S(L16 ⊕ K16 ) ⊕ S(Lf16 ⊕ K16 )
14
Chapitre 1. Les attaques
La dernière équation établit une relation dans laquelle seule la valeur de la
clé K16 est inconnue tandis que les autres valeurs sont retrouvées grâce au chiffré
original et au chiffré erroné. En faisant une recherche exhaustive sur les 64 valeurs
possibles, un faible nombre des clés partielles qui satisfont cette équation est
établi (typiquement, une dizaine sur 64). En répétant la même méthode avec
plusieurs textes chiffrés, l’attaquant va trouver la bonne clé partielle. Enfin, il va
déduire la clé complète en faisant la combinaison de toutes les clés partielles ainsi
obtenues. Eli Biham et Adi Shamir [16], en utilisant cette approche, ont fait des
expérimentations et ont montré que la clé secrète du DES peut être retrouvée
à partir de 200 textes chiffrés. La DFA est également applicable au chiffrement
AES [17] ou RSA [18].
1.2.3.2
Attaques « safe-error »
Pour réaliser une attaque en « safe-error », l’attaquant a seulement besoin de
savoir si le calcul de cryptographie s’est correctement réalisé ou non. Il n’a, en
particulier et contrairement à la DFA, pas besoin de connaître la différence entre
le chiffré correct et fauté. Comme cette différence contient beaucoup d’information sur la clef, les attaques en safe-error nécessitent, en contrepartie, de mieux
maîtriser l’injection de fautes mais également de réaliser plus de chiffrements avec
et sans fautes. Ces attaques sont particulièrement efficaces sur les implantations
sécurisées vis-à-vis des attaques DFA.
Ce type d’attaque a été publié initialement dans [19] pour trouver la clé privée
de l’algorithme de cryptographie asymétrique RSA. Pour réaliser cette attaque,
la valeur d’un bit de la clef doit pouvoir être fixée, par exemple, à ’0’. L’attaquant
fait réaliser un calcul cryptographique au circuit en le perturbant. Si le résultat
obtenu est correct (test qui peut être réalisé simplement par déchiffrement avec la
clef publique), c’est que la valeur du bit de la clef était à ’0’ (la perturbation n’a
pas modifié le résultat). Si le résultat obtenu est incorrect, c’est que la valeur du
bit de la clef privée était à ’1’ (la perturbation a modifié le résultat). L’attaquant
procède ensuite de même pour chacun des autres bits de la clef.
Un autre exemple d’attaque en « safe-error », appelée DBA (pour « Differential
Behavioral Analysis ») [20], exploite à la fois le principe énoncé ci-dessus et celui de la DPA [section 1.3.3.3]. Cette attaque injecte des fautes de type « set ou
reset » sur un ensemble de bits B, fonction du texte clair et de la clé partielle.
L’attaquant n’a pas besoin de connaître la valeur des fautes injectées mais il
doit faire en sorte que ces fautes assignent pour tout texte en clair, aux bits de
B une valeur constante H. Dans un premier temps, l’attaquant va réaliser des
chiffrements non fautés à partir d’un ensemble des textes en clair. Il réalise de
nouveau ces chiffrements en injectant cette fois-ci des fautes, lesquelles modifient
(ou non) le texte chiffré original C ou le comportement du circuit. Pour chacune
1.3. Attaques par canaux cachés
15
de ces réalisations, il va associer la modification (ou non) et le texte chiffré C.
Ensuite, il recalcule théoriquement la valeur des bits B pour tous les textes clairs
et toutes les clés partielles possibles. La bonne clé est celle qui fait en sorte que
pour tous les textes clairs (ou au moins la majorité), C change quand H 6= B
et C ne change pas quand H = B. Si H est inconnu, l’attaquant teste plusieurs
valeurs de H pour retrouver la clé partielle.
1.3
Attaques par canaux cachés
Depuis l’article initial de Kocher [21], plusieurs attaques par canaux cachés
sont proposées sur des implantations de crytographie. Ce sont des attaques qui
reposent sur l’observation durant l’exécution du circuit des phénomènes physiques telles que le temps de réponse, la consommation de puissance consommée
ou l’émission électromagnétique.
1.3.1
Modèles de consommation et de rayonnement EM
1.3.1.1
Modèles de consommation
Lorsqu’un circuit est réalisé sur silicium, les portes logiques qui le constituent
sont physiquement distantes les unes des autres. Les interconnexions entre les
portes, réalisées par des pistes parallèles au substrat, créent des condensateurs,
dits de ligne. La valeur de ces condensateurs est, en première approximation,
proportionnelle à la longueur des interconnexions. De plus, chaque entrée d’une
porte logique présente, au fil qui lui est connecté, un condensateur dit d’entrée.
La valeur de ce dernier est liée à la réalisation niveau « transistor » de la porte et
au placement-routage de celle-ci. Les condensateurs de ligne et d’entrée sont des
composants « parasites » qui contribuent à l’absorption de puissance du circuit.
On distingue classiquement la puissance statique de la puissance dynamique. La
première est due au courant « de fuite » qui traverse les transistors qui constituent la porte quand ils sont dans un état stable (bloqué ou passant) (Istat ).
La seconde se produit quand ces transistors changent d’état. Ces commutations
peuvent provoquer un courant de court-circuit (Icc ) entre la masse et l’alimentation. Suivant le sens de la commutation, les condensateurs parasites qui sont
connectés à la sortie de la porte sont chargés ou déchargés. Si la transition a
lieu de l’état bas vers l’état haut, les condensateurs parasites sont chargés par
le courant (Icl ) en provenance de l’alimentation ; si au contraire la transition a
lieu de l’état haut vers l’état bas, la décharge des condensateurs se fait à travers
la masse (et dans ce cas, aucun courant n’est absorbé). Ces considérations sont
résumées dans le Tableau 1.2. A noter que sur les technologies actuelles, Icl , Icc ,
Istat représentent respectivement 70-90%, 10-30% et moins de 1% du courant
16
Chapitre 1. Les attaques
total. Sur les technologies futures, la part du courant de fuite aura tendance à
augmenter à cause de la diminution de l’épaisseur de l’oxyde de grille des MOS.
Transition état courant → état suivant
0→0
0→1
1→0
1→1
Courant consommé
Istat
Icc + Icl
Icc
Istat
Tableau 1.2 – Courant consommé en fonction des transitions
1.3.1.2
Modèles de rayonnement
En technologie CMOS, la commutation des portes logiques est accompagnée
d’une activité électrique comme nous l’avons demontré dans la section 1.3.1.1.
Ce courant génère une variation dans le champ électromagnétique autour de la
puce, selon la loi de Lentz. Nous avons :
V
dφ
Z dt
Z
= −
φ =
~ · dA
~
B
Où V est la tension de sortie de la sonde, φ est le flux magnétique, t le temps,
~ le champ magnétique et A
~ la surface pénétrée par la sonde.
B
1.3.2
Méthodes de mesure des canaux cachés
1.3.2.1
Temps de réponse
La mesure du temps de réponse d’un circuit peut se faire :
– soit directement à l’aide d’un chronomètre qui se déclenche sur le début de
la requête et qui s’arrête à la fin de celle-ci,
– soit indirectement en mesurant le courant consommé ou le rayonnement
électromagnétique du circuit, comme décrit ci-dessous.
1.3.2.2
Consommation
Pour mesurer la consommation électrique d’un circuit, une petite résistance
R, d’environ 1 Ohm, est insérée en série entre le connecteur de masse du composant et la masse de l’appareil de mesure. Le courant I circulant à travers R crée
une tension proportionnelle à I et qui peut être mesurée à l’aide d’un oscilloscope via une sonde de tension. Il est possible de mesurer directement le courant
d’alimentation grâce à une sonde de courant.
1.3. Attaques par canaux cachés
1.3.2.3
17
Émission électromagnétique
L’émission électromagnétique d’un circuit est captée soit par des sondes de
champ magnétique (généralement des boucles inductives, comme celles représentées en Figure 1.10) soit par des sondes de champ électrique (généralement des
antennes « fouet »), amplifiée puis enregistrée avec un oscilloscope. Ces sondes
sont généralement positionnées aussi près que possible de la surface active du
circuit. Ces sondes peuvent, dans la plupart des cas, être déplacées latéralement
au dessus de cette surface avec une table XY. La précision typique de positionnement est de l’ordre de quelques microns. L’attaquant obtient alors une
cartographie de l’émission électromagnétique telle que celle qui est représentée
en Figure 1.11. A noter également qu’au delà de cette mesure en champ proche,
il a été montré que des mesures peuvent être menées à plusieurs centimètres du
composant.
Figure 1.10 – Sonde électromagnétique
18
Chapitre 1. Les attaques
Figure 1.11 – Cartographie des rayonnements électromagnétiques émis par des
interconnexions
1.3.2.4
Comparaison
Le premier avantage du signal électromagnétique (EM) par rapport au signal de consommation est qu’il est possible de l’acquérir sans intrusion dans le
système. En outre, plusieurs signaux électromagnétiques différents peuvent être
mesurés soit en plaçant simultanément plusieurs capteurs au dessus du circuit
soit en déplaçant un capteur unique à l’aide d’une table XY [9]. C’est pourquoi,
il est communément admis que les signaux électromagnétiques permettent d’obtenir une information « localisée », au sens où les différentes sources de rayonnement peuvent être mesurées . Le problème de séparation de sources d’information
dans un signal EM a d’ailleurs été explicitement abordé dans [22]. Notons cependant que le signal électromagnétique étant généralement plus faible que celui
obtenu en mesurant la consommation, il est plus sensible au bruit. De plus, avec
le signal EM, la quantité de données à traiter par les algorithmes d’extraction
de l’information augmente proportionnellement avec le nombre de positions de
la sonde. Enfin, dans le domaine de la caractérisation sécuritaire, le signal EM,
parce qu’il est très dépendant du positionnement de la sonde, pose des problèmes
de reproductibilité des résultats.
1.3.3
Scénarii d’attaques
1.3.3.1
Analyse du temps de réponse
L’une des attaques par canaux cachés les plus simples a pu être réalisée sur
les premières implantations du test de code personnel (code PIN). Supposons
que l’algorithme qui consiste à tester que deux chaînes de N caractères sont
identiques, est implanté de la façon suivante :
1.3. Attaques par canaux cachés
19
Algorithme 1 Algorithme de test de code PIN
Entrées: N ; /* Nombre de caractères à tester*/
Entrées: char *stored_pin ; /* Code PIN stocké en mémoire*/
Entrées: char *prop_pin ; /* Code PIN à tester*/
Sorties: result ; /* Vrai si les deux chaînes sont identiques, faux sinon*/
result=TRUE ; /* Initialisation*/
index_max=N ;
index=0 ; /* Test de code*/
tantque result==true AND index < index_max faire
si stored_pin[index] == prop_pin[index] alors
index++ ;
sinon
result=FALSE ;
finsi
fin tantque
retourne result ;
L’attaque proposée fonctionne à condition que l’attaquant sache que le test
se fait caractère par caractère et que le programme sort du test dès qu’une
différence apparaît entre le PIN stocké et celui testé. La première propriété lui
permet d’appliquer la méthode « diviser pour régner ». La seconde fait en sorte
que le temps de calcul soit corrélé aux données manipulées. En effet, supposons
que les (p − 1) premiers caractères soient connus (avec p < N ) de l’attaquant
mais que le dernier pième ne l’est pas. Le temps de test du code PIN sera égal à
tp si le pième caractère testé par l’attaquant est incorrect et égal à tp + ∆ avec
∆ > 0 sinon ( ∆ représentant le temps de calcul pour au moins un passage
supplémentaire dans la boucle « While »).
L’attaque consiste à tester de façon exhaustive les valeurs possible du premier
caractère et de mesurer le temps de réponse du composant à ces sollicitations.
L’un de ces tests est sensiblement plus lent que les autres (d’une durée ∆ ) et
correspond au caractère stocké effectivement dans le circuit. Le second caractère
sera déterminé en testant tous les seconds caractères possibles concaténés au
premier caractère retenu et à choisir celui qui conduit à la réponse du composant
la plus lente. Les caractères suivants seront obtenus d’une façon strictement
identique.
1.3.3.2
SPA « Simple Power Analysis »
Cette attaque permet d’identifier des séquences d’un algorithme par une
simple analyse du profil de courant consommé par le circuit et ainsi en déduire
des informations sur la clef de chiffrement.
20
Chapitre 1. Les attaques
La SPA a permis d’attaquer des algorithmes cryptographiques symétriques
comme le RSA [23, 24] ou les courbes elliptiques. En effet, certains algorithmes de
multiplication de points sur les courbes elliptiques mettent en œuvre deux types
d’opérations sur les points : le doublement et l’addition. Ces opérations sont
réalisées successivement ou non en fonction de la valeur d’un des bits de la clef.
La Figure 1.12 représente une estimation de la consommation d’un coprocesseur
pour courbes elliptiques effectuant une multiplication sur une courbe elliptique.
On constate qu’il est possible de détecter deux motifs. Le premier est constitué
d’une succession de 4 phases intensives de calculs, d’une phase moins intensive
puis de 4 phases intensives. Le second est constitué d’une succession de 2 phases
intensives de calculs, d’une phase moins intensive puis de 2 phases intensives.
Pour cette implantation particulière, le premier motif correspond à une addition
de points et le second à un doublement de point. Une fois ces motifs détectés
par l’attaquant, ce dernier peut remonter à la valeur de la clef sachant qu’une
addition suit un doublement si et seulement si la valeur de la clef est égale à ’1’.
Figure 1.12 – Consommation de puissance lors d’un déchiffrement ECC
1.3.3.3
DPA « Differential Power Analysis »
La DPA utilise des fonctions statistiques adaptées à l’algorithme visé pour
faire ressortir des corrélations entre la consommation du circuit et le calcul d’une
1.3. Attaques par canaux cachés
21
valeur intermédiaire a. Pour autoriser une approche de type ‘diviser pour régner’,
cette valeur a est choisie de telle sorte qu’elle ne dépende que du message d’entrée
M et d’un nombre restreint de bits de la clef K (inconnue). Cet ensemble de bits
est appelé ‘fragment de clef’ et est noté Kr . Dans les chiffrements DES et AES,
la sortie de la S-Box r de la première ronde est souvent choisie comme valeur
intermédiaire car elle est respectivement fonction de 6 et de 8 bits de la clef.
On a donc a = f (Kr , M ) avec f une fonction qui peut aisément être déduite du
standard.
Dans un premier temps, l’attaquant choisit un modèle de consommation en
fonction de la connaissance qu’il a de l’implantation de l’algorithme de cryptographie. Le modèle le plus simple (mais le plus général) qui a été initialement
proposé par Kocher consiste à considérer l’un des bits de a comme valeur p(a)
de la puissance consommée par le circuit.
Dans un second temps, l’attaquant mesure les consommations de puissance
P (K, M1 ), P (K, M2 ), . . . , P (K, Mn ) correspondant à l’encryptage de n messages
d’entrée M1 , M2 , . . . , Mn connus avec la clef K.
Dans un troisième temps, l’attaquant va générer la liste de toutes les valeurs
possibles du fragment de clef Kr (appelée également hypothèse de clef). Dans
le cas où a est la sortie d’une des S-Box de l’AES, cette liste est constituée
de 28 = 256 éléments. Pour tout élément Kr∗ de cette liste et pour chacun des
messages M , l’attaquant peut prédire la valeur de a = f (Kr∗ , M ) et la valeur de
puissance associée p(a) = p(f (Kr∗ , M )). Si p(a) est l’un des bits de a, l’attaquant
sépare les courbes collectées en deux groupes : celui des consommations telles
que p(f (Kr∗ , M )) = 0 (on parlera de consommation de type ’0’) et celui des
consommations telles que p(f (Kr∗ , M )) = 1 (de type ’1’). Enfin, les moyennes de
chacun de ces deux groupes seront calculées.
P0 = moy{P (K, Mi )|p(f (Kr∗ , Mi ) = 0)}
P1 = moy{P (K, Mi )|p(f (Kr∗ , Mi ) = 1)}
Si l’hypothèse de clef est incorrecte (c’est-à-dire Kr∗ 6= Kr ), il n’y aura pas
une différence notable entre les P0 et P1 . En effet, la valeur de p(a) dans ce cas
sera différente de sa valeur réelle avec une probabilité de 50%, soit environ la
moitié des messages d’entrées et les traces de puissance ne seront pas corrélées
à a. Par contre, lorsque le fragment de clé est correct, une différence entre les
moyennes apparaîtra [figure 1.13]. Ainsi, le maximum des essais pour trouver la
clé sera 2m avec m le nombre de bits d’un fragment de la clé (typiquement m=6
pour le DES et m=8 pour l’AES). Si la taille de la clé est N bits, l’attaquant a
2m essais au lieu de 2N dans la recherche exhaustive.
besoin seulement de N
m
22
Chapitre 1. Les attaques
Figure 1.13 – Consommation de courant d’un circuit asynchrone (haut) et résultats DPA associés (bas)
1.3.3.3.1 Exemple « théorique » Dans ce paragraphe est expliqué sur un
exemple simple pourquoi la DPA fonctionne. Supposons que la consommation
mesurée P (K, Mi ) se décompose en une partie R(a) liée au calcul du bit de a
considéré et en une autre partie Q(K, Mi ) qui, elle, n’est pas liée à a. Dans ce
cas, les moyennes calculées par l’attaquant s’écrivent de la façon suivante :
P0 = moy{Q(K, Mi ) + R(f (Kr , Mi ))|p(f (Kr∗ , Mi )) = 0}
= moy{Q(K, Mi )|p(f (K∗r , Mi )) = 0} + moy{R(Kr , Mi )|p(f (Kr∗ , Mi )) = 0}
P1 = moy{Q(K, Mi ) + R(K, Mi )|p(f (Kr∗ , Mi )) = 1}
= moy{Q(K, Mi )|p(f (K∗r , Mi )) = 1} + moy{R(Kr , Mi )|p(f (Kr∗ , Mi )) = 1}
Lorsque la différence P0 −P1 est calculée par l’attaquant, les moyennes des en-
1.3. Attaques par canaux cachés
23
sembles {Q(K, Mi )|p(f (K∗r , Mi )) = 1} et {Q(K, Mi )|p(f (K∗r , Mi )) = 0} s’annulent (dès qu’un assez grand nombre de courbes est utilisée).
Lorsque l’hypothèse de clef est bonne, le groupe des consommations de type
’0’ (resp. ’1’) regroupe toutes les consommations qui correspondent à un état
bas (resp. haut) du bit de a considéré. Si les valeurs précédentes de ce bit sont
équiprobables (c’est-à-dire qu’un ’1’ logique a la même probabilité d’être précédée
par un ’1’ que par un ’0’) alors la consommation d’un état haut (resp. bas) est
égale à la moyenne de la consommation des transitions qui mènent à un état haut
(resp. bas), à savoir les transitions 0 → 1 et 1 → 1 (resp. 0 → 0 et 1 → 0). A
partir des consommations associées aux transitions d’un bit (et reportées dans le
Tableau 1.2), les formules précédentes deviennent (avec Vcc la valeur de la tension
d’alimentation du circuit) :
P0 = Vcc ∗ moy{i0→0 , i1→0 }
IstatN + Icc
= V cc ∗
2
P1 = Vcc ∗ moy{i0→1 , i1→1 }
Icc + Icl + IstatP
= V cc ∗
2
(1.1)
(1.2)
(1.3)
(1.4)
Lorsque l’hypothèse de clef n’est pas bonne, le groupe des consommations de
type ’0’ (resp. ’1’) regroupe autant de consommations qui correspondent à un état
bas (resp. haut) du bit de a considéré que de consommations qui correspondent
à un état haut. Les formules ci-dessus deviennent alors :
P0 = P1 = Vcc ∗ {(moy{i0→0 , i1→0 , i0→1 , i1→1 }}
(1.5)
Par conséquent, lorsque la mauvaise hypothèse de clef est choisie, on a P0 −
P1 = V cc ∗ I2cl 6= 0 (d’après les équations 1.3 et 1.4 avec comme hypothèse
supplémentaire que IstatN = IstatP ) mais lorsque la mauvaise hypothèse de clef
est choisie, on a P0 − P1 = 0 (équation 1.5).
1.3.3.4
Attaque par dictionnaire ou en « template »
L’attaque par dictionnaire consiste, dans un premier temps, à bâtir sur un
composant identique à celui que l’on souhaite attaquer, un dictionnaire ayant
comme entrée la valeur de quelques bits secrets de la clef (appelés « clef partielle », notée k) et comme champ, les propriétés statistiques (ou « template »
notée tk ) d’un canal mesuré lorsque ces quelques bits sont manipulés par le circuit. Dans un second temps, l’attaquant détermine les propriétés statistiques t?
du même canal sur le circuit qui manipule la clef inconnue. Il cherchera ensuite
24
Chapitre 1. Les attaques
dans l’ensemble des champs du dictionnaire le champ tk le plus « proche » du t? .
Si tK désigne ce champ, il choisira enfin comme valeur de clef, la valeur K.
Il procédera de façon identique pour les autres bits de la clef grâce à la
méthode « diviser pour régner » ou grâce à une variante appelée « extend and
prune ». L’une des hypothèses supplémentaire pour qu’une telle attaque réussisse est donc que le circuit avec lequel est bâti le dictionnaire consomme « de
la même façon » que le circuit qui est attaqué. En pratique, cette hypothèse
pourra être vérifiée pour les circuits dont la part de consommation dépendant
de la dispersion de fabrication est négligeable par rapport à la consommation
« structurelle » (c’est-à-dire liée au positionnement et au type de portes élémentaires qui le constituent). Il est à noter que cette hypothèse sera donc d’autant
moins vérifiée que la technologie utilisée pour fabriquer le circuit sera fine.
L’une des premières attaques en template proposée a été appelée « simple »
dans la littérature. Elle est rappelée ici à titre didactique. Elle consiste à ne
considérer comme propriété statistique du canal que la valeur moyenne obtenue lors de la construction du dictionnaire sur toutes les réalisations. La Figure
1.3.3.4 représente ce cas dégradé d’attaque en template. A gauche sont représentées les moyennes µk obtenues pour les différentes valeurs de clefs partielles
(ici simplement constitués de 3 bits). A droite est reportée la courbe x? mesurée
avec la clef inconnue. L’attaquant choisira naturellement, dans ces conditions, la
clef partielle k telle que la courbe de µk ressemble le plus à la courbe mesurée,
en l’occurrence k = (100). La notion de ressemblance sera ci-dessous définie en
terme de probabilité.
Figure 1.14 – Attaque en template : cas dégradé
Pour que le dictionnaire soit aussi compact que possible, seuls un nombre réduit de points d’intérêt du canal sont considérés. Ces n points d’intérêt sont
généralement choisis parmi ceux qui présentent une variance maximum. Des
techniques plus élaborées comme l’analyse en composantes principales permet
de calculer les bases qui maximisent ces variances. Pour réduire encore la taille
1.3. Attaques par canaux cachés
25
du dictionnaire, l’attaquant suppose que la consommation vérifie un modèle de
bruit gaussien multivarié. Dans ces conditions, chaque template se résume à un
vecteur de n moyennes et à une matrice de covariance (de taille n ∗ n). L’attaque
pour n = 1 est précisée puis généralisée dans le paragraphe suivant pour n > 1.
1.3.3.4.1 Attaque en template pour n = 1 Dans le cas particulier où le
nombre de points d’intérêt est égal à 1 (n = 1), le modèle statistique employé
est constitué seulement de la moyenne et de l’écart-type. On note xpk la pième
mesure du canal obtenue lors de la phase de construction du dictionnaire pour
la valeur de clef partielle k. Les moyennes et écart-type pour la clef k, notés
respectivement µk et σk sont alors calculés à l’aide des formules suivantes :
Pp p
xk
p
1
µk =
sP
p
1
σk =
(1.6)
(xpk − µ)2
p
(1.7)
Lors de la phase de classification, si l’attaquant n’a qu’une seule mesure x?
du canal à sa disposition, il calculera pour tous les templates du dictionnaire les
probabilités suivantes et choisira k celle qui maximise cette probabilité :
pk (x? ) =
σk ∗
1
√
2∗π
∗e
2
x −µ
−1
∗( ?σ k )
2
k
(1.8)
Dans le cas où l’attaquant a i réalisations {x0? , x1? , . . . , x?i−1 } à sa disposition, il
calculera le produit des probabilités pk (xi? ) pour sa classification. On parle parfois
dans ce cas d’attaque
√ en template « amplifiée » car la probabilité d’erreur est
réduite d’un facteur i.
1.3.3.4.2 Template pour n > 1 Dans ce cas, l’attaquant choisit n points
d’intérêt, généralement parmi ceux où l’écart type est le plus important. Il calcule
alors le vecteur des moyennes Mk = {µ0 , µ1 , . . . , µn−1 } en chacun de ces points à
l’aide de la formule suivante, avec xpk (ti ) désignant la valeur du canal à l’instant
d’intérêt i :
Pp p
x (ti )
(1.9)
µk (ti ) = 1 k
p
Il calcule également la matrice de covariance Ck , dont les éléments sont définis,
si i et j désignent respectivement les indices des lignes et des colonnes, par la
formule suivante :
Pp
Ck (ti , tj ) =
1
(xpk (ti ) − µk (ti ))(xpk (tj ) − µk (tj ))
p−1
(1.10)
26
Chapitre 1. Les attaques
Lors de la phase de classification, si l’attaquant n’a qu’une seule mesure x? du
canal à sa disposition (mais qui est un vecteur de n points), il calculera pour tous
les champs du dictionnaire les probabilités suivantes et choisira k qui maximise
cette probabilité :
pk (x) = q
1
n
∗e
−1
∗(x? −µk )t ∗Ck−1 (x? −µk )
2
(1.11)
det(Ck ) ∗ (2 ∗ π)
Des templates ont été réalisés en pratique sur RC4 par Rechberger [25]. Dans
son cas particulier la valeur de n comprise entre 10 et 20 permet d’obtenir les
meilleurs résultats. Il propose également de modifier l’étape de construction du
dictionnaire en y incluant des tests de classifications pour optimiser les paramètres.
1.3.3.5
Attaque par collision interne
L’idée de cette attaque est de détecter une collision interne en analysant des
informations sur la puissance consommée. Une collision interne apparaît lorsqu’une fonction dans un algorithme de cryptographie traite deux entrées différentes et donne un même résultat. On utilise le terme « interne » car en général,
la collision n’est pas vue à la sortie de l’algorithme. La collision n’est reconnue
que par la corrélation de puissance consommée durant l’exécution de l’algorithme
de cryptographie. Schramm et al. [26] ont exploité la vulnérabilité du DES pour
créer une collision interne. Dans cette fonction, chacune des 8 S-Box définit une
application surjective de 26 (entrée) → 24 (sortie). Comme chacune est équilibrée,
4 entrées différentes d’une S-Box pourront obtenir la même sortie.
Premièrement, l’attaquant va rechercher, grâce à l’analyse de la puissance
consommée, des textes clairs distincts particuliers x et x ⊕ 4 tels que S(x ⊕ k) =
S(x ⊕ k ⊕ 4) avec k la clé secrète. Il va ensuite réaliser une recherche exhaustive
des clefs qui vérifient cette équation. Ce type d’attaque peut également s’appliquer au chiffrement AES. Puisque les S-Box de AES est bijective, il y a deux
variantes d’attaque qui causent la collision. K.Schramm et al. [27] ne produisent
pas la collision sur l’étape de substitution par S-Box mais sur l’un des octets de
sortie dans l’étape « Mix Column » tandis que J. Blömer et al. [28] provoquent
une faute sur 1 bit à la sortie de S-Box pour créer la collision.
En résumé, les attaques non-invasives ne nécessitent pas des matériels puissants et coûteux comme les attaques invasives et sont plus rapides à mettre en
oeuvre. C’est pourquoi, les attaques non-invasives sont considérées comme les
menaces les plus dangereuses et les plus efficaces face à la sécurité des systèmes
embarqués.
1.4. Conclusion
1.4
27
Conclusion
Dans ce chapitre, les principales attaques décrites dans la littérature sont rappelées. Il apparaît que les attaques par « effet de bord » permettent de récupérer
les informations sensibles par simple « écoute » d’un phénomène physique, le syndrome, émis par le circuit en fonctionnement. Ces attaques seront d’autant plus
efficaces que les modèles d’émission (supposés ou mesurés respectivement dans
le cas des attaques par « corrélation » ou par « dictionnaire ») des syndromes
seront précis. Par contre, plus ces modèles seront précis, moins l’attaque pourra
être appliquée à d’autres composants. Il apparaît également dans ce chapitre
que les attaques en faute permettent de récupérer les informations sensibles par
modification du comportement du circuit. Elles sont toutes basées sur l’analyse
d’un modèle de comportement du circuit en présence d’une classe particulière de
fautes. Il s’avère que plus la classe de fautes considérée est restrictive (c’est-àdire qu’elle nécessite une injection temporellement et spatialement bien localisée),
plus la récupération de l’information à partir des résultats expérimentaux est facile (temps de calcul et mémoire de travail réduits). Dans le cadre de notre étude,
nous étudierons des contre-mesures aux attaques que nous considérons comme
les plus critiques, à savoir les attaques par effet de bord et en faute.
Chapitre 2
Contre-mesures
Sommaire
2.1
Contre-mesures contre les attaques par faute . . . . . . . 30
2.1.1
2.1.2
2.1.3
Principe de détection des intrusions . . . . . . . . . . . .
30
2.1.1.1
Capteurs physiques . . . . . . . . . . . . . . . .
30
2.1.1.2
Détection d’erreur . . . . . . . . . . . . . . . . .
30
Redondance sur processeur . . . . . . . . . . . . . . . . .
33
2.1.2.1
Dans la sphère de réplication . . . . . . . . . . .
34
2.1.2.2
Hors de la sphère de réplication . . . . . . . . .
35
Contrôle de flot d’exécution . . . . . . . . . . . . . . . . .
39
2.1.3.1
Contrôle de transitions entre fonctions et entre
BBs . . . . . . . . . . . . . . . . . . . . . . . . .
39
Syndrome anormaux . . . . . . . . . . . . . . . .
41
Stratégie de réaction . . . . . . . . . . . . . . . . . . . . .
41
2.1.4.1
Recouvrement . . . . . . . . . . . . . . . . . . .
41
2.1.4.2
Stratégies de sécurité évoluées . . . . . . . . . .
43
Réduction de la sensibilité . . . . . . . . . . . . . . . . . .
44
2.1.5.1
Technologie . . . . . . . . . . . . . . . . . . . . .
44
2.1.5.2
Micro-architecture . . . . . . . . . . . . . . . . .
45
2.1.5.3
Triplication . . . . . . . . . . . . . . . . . . . . .
45
2.1.3.2
2.1.4
2.1.5
2.2
Contre-mesures contre les attaques par observation . . . 46
2.2.1
2.2.2
2.3
Réduction du signal . . . . . . . . . . . . . . . . . . . . .
46
2.2.1.1
Équilibrage . . . . . . . . . . . . . . . . . . . . .
46
2.2.1.2
Filtrage . . . . . . . . . . . . . . . . . . . . . . .
48
Ajout du bruit . . . . . . . . . . . . . . . . . . . . . . . .
48
2.2.2.1
Parallélisation d’opérations indépendantes
. . .
48
2.2.2.2
Modification dynamique de la tension . . . . . .
48
2.2.2.3
Désynchronisation . . . . . . . . . . . . . . . . .
49
2.2.2.4
Masquage . . . . . . . . . . . . . . . . . . . . . .
53
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . 54
29
30
Chapitre 2. Contre-mesures
Ce chapitre résume les techniques principales dans les différents niveaux
d’abstraction qui pourront être utilisées pour protéger le processeur. En particulier, les techniques au niveau architectural sont détaillées car c’est à ce niveau que
nos travaux ont été menés. Contre les attaques en faute, on peut distinguer deux
grands principes. Le premier consiste à détecter les attaques puis mettre en place
une stratégie de réaction appropriée. Le deuxième vise à réduire la susceptibilité
aux fautes ou augmenter la robustesse. Contre les attaques en consommation, le
principe des contre-mesures se base sur la réduction du rapport signal sur bruit.
Il s’agit donc soit de diminuer l’amplitude du signal (à l’aide de techniques d’
« équilibrage » et « filtrage ») soit d’augmenter le niveau de bruit (avec des techniques dites de « masquage » et d’introduction de calculs « non-déterministes »).
Ci-après sont décrites ces techniques.
2.1
2.1.1
Contre-mesures contre les attaques par faute
Principe de détection des intrusions
Il existe deux classes de détection d’intrusions classiquement implémentées
dans les composants de sécurité.
2.1.1.1
Capteurs physiques
La première classe vise, à l’aide de capteurs de grandeurs physiques, à détecter
les perturbations créées par l’attaquant. Différents capteurs ont été implantés,
à cet effet, pour détecter des variations anormales de la tension d’alimentation,
de la fréquence d’horloge, de la température et de l’éclairement du composant,
ce dernier type de détection étant généralement réalisé en face avant à l’aide de
photo-diodes.
2.1.1.2
Détection d’erreur
La seconde classe vise à détecter les erreurs créées dans le circuit par ces
perturbations. Il existe deux sous-classes de détection. La distinction entre ces
sous-classes est illustrée par le graphe d’un système (qui peut être aussi bien
matériel que logiciel) représenté en Figure 2.1. Chaque sommet du graphe (numéroté sur l’exemple de 1 à 5) est associé à un état interne du système et chaque
arête de ce graphe est associée à un enchaînement possible des états du système.
2.1. Contre-mesures contre les attaques par faute
Système initial
Contrôle du flot
Redondance temporelle
31
Redondance spatiale
Figure 2.1 – Schémas de détection d’erreur
Test d’intégrité de l’enchaînement des états La première sous-classe de
détection consiste à vérifier que l’enchaînement des états est réalisé correctement
(on parle alors « de contrôle de flot d’exécution »). A cet effet, au cours de la
conception du programme ou du circuit, les enchaînements autorisés du système
sont déterminés. Sur l’exemple proposé, les enchaînements autorisés des états
sont {1 → 2; 2 → 3; 3 → 4; ; 3 → 5; 4 → 2; 4 → 5}. Lors de l’exécution, il s’agit
de vérifier que chaque transition effective du système est bien dans l’ensemble
des transitions autorisées.
Test d’intégrité des états La seconde sous-classe de détection consiste, pour
chaque état, à calculer plusieurs fois les variables internes puis à comparer les
résultats obtenus. On parle de « redondance temporelle » quand ces calculs sont
réalisés successivement et de « redondance spatiale » ou « matérielle » quand ils
sont réalisés en parallèle.
La redondance temporelle dont une implantation possible est représentée Figure 2.2, nécessite uniquement des éléments de mémorisation qui stockent l’état
précédent et qui le compare avec l’état courant. En contrepartie, ce type de redondance réduit les performances. Au niveau de la couverture des fautes, cette
technique ne peut détecter que les fautes dont la durée est inférieure à celle qui
sépare les instants de réexécution. En effet, des perturbations de longue durée
peuvent produire des fautes identiques lors de différentes réexécutions. Dans ce
cas, les résultats issus de ces réexécutions sont également identiques mais ils sont
erronés : Le système de détection est mis en défaut. Des variantes de redondance
temporelle ont été proposées pour palier ce problème : le principe repose soit sur
une réexécution différente du calcul original [29].
32
Chapitre 2. Contre-mesures
F
Résultat (recomputation)
COMP
=
Error ?
R
Résultat (première exécution)
Figure 2.2 – Implantation possible de redondance temporelle
La redondance spatiale consiste à utiliser plus de bits que nécessaire (au sens
de la théorie de l’information) pour coder les données que l’on souhaite protéger. On parlera d’« ordre » de la redondance, le rapport entre le nombre de bits
effectivement utilisés pour coder l’information sur le nombre de bits minimal
possible pour coder cette dernière. Pour détecter les erreurs (il ne s’agit pas de
les corriger) : l’ordre de la redondance est alors compris entre 1 et 2. A noter que
plus l’ordre sera élevé, plus les capacités de détection (mais malheureusement
également le coût) seront importantes. Cette redondance spatiale peut être implantée à l’aide de Code Détecteurs d’Erreur (ou CDE). Les fautes détectées par
ces CDEs sont assez limitées comme présenté dans le Tableau 2.1. Par exemple,
l’utilisation de code de parité ne peut détecter qu’un seul bit fauté alors que le
code Berger ne traite que les fautes unidirectionnelles (c’est-à-dire des transitions
de 0 à 1 ou de 1 à 0).
Type de code
Bit de parité
Code de Berger
Code de Bose-Line
Code de Dong
Propriétés de code
Détection d’un seul bit fauté
Détection de toute faute unidirectionnelle
Détection d’un nombre de fautes unidirectionnelles
en fonction du nombre de bits utilisés
Détection d’un nombre de fautes unidirectionnelles
en fonction du nombre de bits utilisés
Tableau 2.1 – Type de CDE utilisable avec le circuit de prédiction
Pour protéger les calculs à l’aide de CDEs, une solution, appelée « code de
prédiction » a été proposée. Son principe est illustré dans la Figure 2.3. Soient
A, B, S respectivement deux entrées d’un circuit combinatoire, S = F (A, B)
sa sortie et CA , CB et CS respectivement les CDEs de A, B, S. Le circuit de
prédiction est couplé avec le circuit original pour générer un autre CDE de la
sortie, appelé CS0 , à partir des entrées A,B et/ou de leur CDE CA , CB . Donc,
on a CS0 = P (A, B) et/ou CS0 = P (A, B, CA , CB ). La comparaison de CS et CS0
2.1. Contre-mesures contre les attaques par faute
33
est ensuite réalisée pour la validité de la sortie S. L’équation de prédiction P est
déduite à partir des propriétés mathématiques du CDE.
A
S
F
B
Générateur
CDE
CS
COMP
=
Erreur ?
Circuit de
CA
CB
Prédiction
C’S
Figure 2.3 – Implantation possible de redondance matérielle (par prédiction)
Un cas particulier de redondance spatiale est la duplication. Il s’agit, comme
indiqué en Figure 2.4, d’implanter deux circuits identiques fonctionnant en parallèle et d’en comparer les sorties pour valider le fonctionnement du système.
Figure 2.4 – Implantation possible de redondance matérielle (duplication)
2.1.2
Redondance sur processeur
Dans ce paragraphe, les travaux de recherche récents qui ont appliqué les
techniques de redondance sur le processeur sont présentés. Ces différentes techniques n’étant généralement pas applicables à l’ensemble du processeur (pour
34
Chapitre 2. Contre-mesures
des raisons de coût essentiellement), la notion de « sphère de réplication » a été
introduite dans [4]. Cette sphère est définie comme étant une zone logique dans
laquelle les composants tels que le processeur, le pipeline, l’Unité Arithmétique
et Logique (UAL), etc sont protégés soit par duplication temporelle ou spatiale
tandis que ceux (comme la mémoire, le cache ou le banc des registres) à l’extérieur de la sphère sont protégées par des techniques moins coûteuses telles que
les CDEs, comme nous le décrirons par la suite. Comme illustré en 2.5, les données doivent être répliquées en entrée de la sphère et les données doivent être
comparées en sortie. Cette notion de sphère aide le concepteur à régler le compromis entre le taux de couverture des fautes (le modèle des fautes et le nombre
des fautes qui sont détectées), les performances attendues ainsi que le coût du
matériel additionnel.
Figure 2.5 – Sphère de réplication [4]
2.1.2.1
Dans la sphère de réplication
Dans le processeur commercial Compaq Himalaya [30], la sphère de réplication contient tout le processeur. Dans ce cas particulier, deux processeurs
identiques sont physiquement implantés et la réplication des entrées ainsi que
la comparaison des sorties s’effectuent à chaque coup d’horloge (on parle de
2.1. Contre-mesures contre les attaques par faute
35
« lockstepping »). Cette technique est également utilisée dans un autre processeur commercial IBM S/390 [31] mais la sphère de réplication n’est composée
que de l’unité Fetch, Décodage et Exécution. Dans le système DIVA [32], deux
processeurs sont également utilisés mais ils ne sont pas identiques. Le processeur
redondant, appelé le vérificateur, est plus simple que le processeur principal : il ne
se charge pas des tâches complexes telles que la prédiction du flot du programme,
la dépendance des registres, etc. . . .
La réplication peut également être implémentée par redondance temporelle.
Cette redondance peut être réalisée au niveau logiciel. Il peut s’agir de dupliquer
des instructions [33], des variables et des lignes de code [34] comme illustré dans le
tableau 2.2, ou de transformer les variables dupliquées en des nouvelles variables
par multiplication d’un facteur prédéfini [35]. Dans ces conditions, la sphère
de réplication peut concerner l’ensemble du système (processeur, mémoire de
données et d’instructions) et consomme beaucoup de ressources mémoires (code
et données). L’impact est notable sur les performances.
Pour diminuer cet impact, certains auteurs ont proposé d’adjoindre du matériel dédié à la comparaison des blocs logiciels redondants [36] ou d’utiliser
les capacités de certains processeurs modernes (« SMT » pour Simultaneaous
MultiThreaded processors) à exécuter en parallèle des fils d’instructions (appelés « threads » en anglais). Cette technique, appelé AR-SMT (pour ActiveStream/Redundant-Stream Simultaneaous MultiThreading), a été premièrement
proposée par Rotenberg et al. [37]. Dans cette méthode, deux threads identiques
sont utilisés : l’un appelé A-Thread (le thread principal) et l’autre appelé Rthread (le thread redondant). Lorsque des instructions du A-Thread sont chargées et exécutées, leurs résultats vont mettre à jour à tous les registres d’états du
processeur (banc de registres, registres de contrôle du pipeline, le compteur du
programme, etc) ainsi que la mémoire. Ces résultats seront également stockées
dans un tampon appelé « Delay Buffer ». Lors de l’exécution du R-Thread, ses
résultats sont comparés à ceux du A-Thread stockés précédemment dans le Delay
Buffer. Une généralisation de cette approche a été proposée dans [4].
Code original
int a,b ;
...
b = a + 5;
Code modifié
int a1 , a2 , b1 , b2
...
b 1 = a1 + 5 ;
b 2 = a2 + 5 ;
if (b1 != b2 )
error () ;
Tableau 2.2 – Duplication des variables et des lignes de code
Des redondances temporelles ont été proposées au niveau des bascules, élé-
36
Chapitre 2. Contre-mesures
ments qui mémorisent l’information au sein du microprocesseur. Par exemple,
dans [38], les bascules sont dupliquées et l’horloge de chacune est déphasée. Ainsi,
les sorties des bascules sont échantillonnées à des moments différents. Si la durée
de faute est inférieure à ce déphasage, une seule bascule sera affectée, ce qui sera
détecté par le comparateur. Des travaux [39, 40] se sont basés sur ce principe
pour la protection du pipeline du processeur.
2.1.2.2
Hors de la sphère de réplication
Hors de la sphère de réplication, la redondance est généralement implantée à
l’aide de CDEs (beaucoup moins coûteux que la duplication). Ces redondance ont
pu cibler des zones très particulières du processeur comme l’UAL ( code de parité
[41], Berger [42], Bose-Line [43]. Ces codes sont également utilisés pour protéger
les données stockées dans les zones mémoires telles que les RAM, les ROM, le
cache, les registres ainsi que leur transfert entre ces zones ou entre ces zones et le
pipeline. Pour la mémoire d’instruction, à la compilation, le CDE original d’une
instruction ou d’un groupe d’instructions est calculé et stocké dans le composant.
Lors de l’exécution de cette instruction (ou de ce groupe d’instructions), le CDE
est recalculé. Ensuite, il est comparé avec le CDE original. Une erreur est détectée
si ces deux CDE sont différents.
Pour renforcer la sécurité en détectant les fautes avec une grande probabilité,
le CDE de long taille, appelé signature, est utilisé. Une telle méthode introduit
un surcoût mémoire important si à chaque instruction est associé un CDEs. Il
est donc difficile de porter ce schéma dans les systèmes embarqués tels que la
carte à puce dont la mémoire est une ressource limitée. De plus, si le temps de
génération de signature est long, la performance du système est considérablement
dégradée. Un compromis intéressant est d’utiliser une signature pour un ensemble
d’instructions. De nombreuses travaux se basant sur cette idée ont été proposés
dans la littérature. Ils peuvent être divisés en 2 catégories suivantes, suivant
l’ensemble d’instructions pris en considération :
A base d’une ligne de cache Ce schéma n’est applicable évidement qu’avec
un processeur doté d’un cache d’instructions. En phase de compilation, les signatures sont générées pour chaque de ligne de cache et stockées en mémoire.
En fonctionnent et lors du défaut de cache, le processeur va chercher dans la mémoire la ligne de cache demandée (ainsi que sa signature), calculer sa signature
puis la comparer avec celle préalablement stockée en mémoire. Les approches
qui sont basées sur ce schéma sont décrites dans [44, 45, 46, 47, 48]. L’objectif
de ces travaux est de sécuriser la mémoire externe en proposant non seulement
l’intégrité des instructions mais aussi la confidentialité pour faire face à l’attaque
qui consiste à capturer l’information du programme sur le bus de la mémoire. La
2.1. Contre-mesures contre les attaques par faute
37
confidentialité est souvent effectuée en chiffrant préalablement la ligne de cache
par un algorithme de cryptographie. Le déchiffrement et la vérification d’intégrité
introduit une latence importante [44, 45] lors du chargement d’une ligne de cache
de la mémoire vers le cache. Afin de réduire cette latence, Elbaz et al proposent
une technique permettant d’effectuer rapidement la vérification d’intégrité après
le déchiffrement de la ligne [46] tandis que Vaslin et al. proposent d’utiliser la
technique OTP (One Time Pad) permettant de déchiffrer rapidement la ligne
et de vérifier à la volée l’intégrité du déchiffrement de la ligne de cache [48]. A
noter que de telles méthodes ne permettent d’assurer l’intégrité des instructions
que sur le bus entre la mémoire et le cache : une modification des instructions,
lors de leur exécution dans le pipeline, ne peut pas être détectée. Il pourrait
être envisagé de porter ce schéma pour la vérification des instructions dans le
pipeline. C’est-à-dire, lorsqu’une ligne de cache est chargée et exécutée dans le
pipeline, la vérification est effectuée. Cependant, au sein d’une ligne de cache, il
peut exister une instruction de saut. Or, la signature est calculée sur une ligne de
cache complète. Cette contrainte obligerait à insérer des « nop » dans le pipeline,
ce qui dégraderait les performances.
A base d’un bloc de base Un Bloc Basique (BB) est un ensemble des instructions consécutives dans lesquelles il n’y a pas de branchement sauf éventuellement la dernière instruction. Pour identifier les BBs, on cherche les instructions
appelées « leader » dont chacun les cas suivants :
– la première instruction du programme
– l’instruction suivant un branchement
– la destination des branchements.
Pour chaque « leader », un BB est formé en groupant des instructions jusqu’au
prochain leader.
Le principe du schéma est de découper le programme d’application en plusieurs BBs et de générer une signature pour chaque BB en phase de compilation.
Pendant l’exécution, les instructions d’un BB sont chargées, décodées puis exécutées les unes après les autres dans le pipeline. Lorsque la dernière instruction
du BB est atteinte, la signature est calculée puis comparée avec celle stockée.
Vu que la fin du BB est détectée lors du décodage de la dernière instruction, ce
schéma peut assurer l’intégrité des instructions sur le chemin entre la mémoire
jusqu’à l’étage de décodage du pipeline. A noter que traiter ce problème n’est
pas aussi évident que celui qui se base sur une ligne de cache. Dans ce dernier, les
signatures sont calculées à partir d’une ligne de cache, ce qui rend la récupération
des signatures facile en s’appuyant sur une partie des bits d’adresse d’une ligne
de cache tandis que dans le schéma de vérification à base du BB, la signature est
calculée sur un ensemble d’instructions dont la taille est variable.
38
Chapitre 2. Contre-mesures
Plusieurs méthodes, qui reposent sur ce schéma, ont été proposées. Elles se
différencient principalement par la manière dont sont stockées puis récupérées
les signatures. Dans [5], l’adresse du début et de fin du BB a été utilisée, comme
illustré décrite dans la Figure 2.6 pour localiser la signature.
Figure 2.6 – Architecture de vérification d’intégrité au niveau BB proposée dans
[5]
Dans leur système, deux tableaux sont utilisés : l’un, appelé FHT (Full Hash
Table), stocke les informations de tous les BB et l’autre, appelé IHT (Internal
Hash Table), joue le rôle de cache stockant des informations des BBs les plus
récents. Lors de l’exécution du BB, l’adresse du début et de la fin est lu par le
processeur en détectant les limites du BBs (des instructions de branchements).
Ces deux valeurs d’adresses sont des clés pour récupérer la valeur originale du
CDE. Plusieurs cas de figure peuvent survenir :
– Si les clefs sont présentes dans le IHT, la valeur originale du CDE est lue
et comparée avec celle calculée pour valider l’intégrité.
– Si ces clefs ne sont pas présentes dans le IHT, elles sont recherchées dans
le FHT.
– Si elles n’existent pas dans ce dernier, les 2 adresses lues ne sont pas
valides et le processeur signale que le flot du programme est affecté.
– Si elles sont présentes dans le FHT, le CDE est lu et comparé avec celui
calculé pour valider l’intégrité.
Le principal inconvénient de telles approches est le fait que la taille nécessaire
de la mémoire « Content Adressable Memory » (CAM) [49] implémentant les
tableaux doit être suffisamment large pour pouvoir stocker le CDE des BBs.
L’approche proposée par Ragel et al. [50] n’utilise pas ces tableaux mais ajoute
une nouvelle instruction au début du BB. Cette instruction stocke le CDE. Il est
à noter que dans cette approche, chaque BB doit impérativement se terminer par
un branchement afin de faciliter la détection de fin d’instruction, quitte à ajouter
une nouvelle instruction de branchement, comme le montre la Figure 2.7.
2.1. Contre-mesures contre les attaques par faute
39
Figure 2.8 – Architecture de vérification d’intégrité du programme à différents
niveaux de granualité dans [6]
Signature bb1
L1 : add ...
BB1
new jump instruction
Signature bb2
L2: xor ...
BB2
jmp ...
Figure 2.7 – Ajout d’une nouvelle instruction de branchement dans [5]
2.1.3
Contrôle de flot d’exécution
2.1.3.1
Contrôle de transitions entre fonctions et entre BBs
Arora et al. [6] proposent une architecture décrite dans la Figure 2.8 qui
permet de vérifier à plusieurs niveaux que le flot du programme s’exécute correctement. Le principe est illustré par la Figure 2.8 et est décrit ci-après.
1. Le niveau « inter-procedural » consiste à assurer la bonne transition des
fonctions au sein du programme. Deux tableaux TABstart et TABstop sont
utilisés pour examiner la transition des fonctions lors d’un appel ou un retour d’une fonction. Le nombre des entrées dans les 2 tableaux est égal à
40
Chapitre 2. Contre-mesures
celui des fonctions dans un programme. Une entrée du TaBstart comprend
une adresse d’appel de fonction, un index de fonction et un pointeur vers
le premier BB dans la nouveau fonction qui vient d’être appelée. Une entrée du TaBstop comprend une adresse de retour de fonction, un index de
fonction et un pointeur vers un BB dans la précédente fonction qui appelle. La différence entre TABstart et TABstop est le fait que les valeurs
des entrées dans ce dernier sont dynamiquement mis à jour. Une machine
d’état est également construite pour représenter les transitions valides des
fonctions en utilisant les mêmes index. Lorsqu’une fonction B est appelée
par la fonction A, l’adresse de la fonction B est cherchée dans le TABstart.
A ce moment, l’adresse de retour (lorsque la fonction B sera terminée) est
stockée dans le TABstop ainsi que son index et le numéro de BB qui se
situe sur l’adresse de retour. Si l’adresse de la fonction B est retrouvée dans
Tabstart, son index est récupéré et comparé avec celui-ci dans la machine
d’état pour valider la transition. Lors du retour de B vers A, l’adresse de retour va être retrouvé dans le TABstop et pour la validation de la transition,
le processus est identique à celui de l’appel de fonction.
2. Le niveau « intra-procedural » consiste à assurer la bonne transition des
BBs au sein d’une fonction. Un tableau TabBB est utilisé pour stocker la
valeur du décalage avec l’adresse de la fonction, les deux autres index qui
pointent sur 2 prochains BBs (suivant que le saut en fin du BB est effectué
ou non), et le CDE du BB. Lorsque le programme passe d’un BB à un
autre BB, l’adresse du nouveau BB, calculé en basant sur le décalage du
BB précédent, est comparé avec l’adresse du compteur du programme (PC)
pour valider la transition.
3. Le niveau BB consiste à assurer l’intégrité des instructions au sein du BB.
Lorsque le BB est exécuté, le CDE est calculé et comparé avec celui stocké
dans le TabBB. Tous les valeurs dans de ces tableaux sauf le TabRet sont
générées en phrase de compilation. Au niveau matériel, de tels tableaux
sont implémentés sur le modèle de la mémoire de type CAM.
Des implantations matérielles d’un mécanisme de détection d’erreur dans le
flot d’exécution ont été proposées dans [51, 52]. Dans les deux cas, les systèmes
sont constitués du système à sécuriser et d’un processeur additionnel (parfois
appelé « Watchdog »). Dans les deux cas également, les binaires du programme
à sécuriser sont, dans la phase de conception, analysés pour en extraire un graphe
d’exécution tel que présenté en introduction de ce chapitre. En cours d’exécution,
le processeur additionnel reçoit ou collecte des informations sur l’exécution du
programme et compare ce graphe d’exécution à celui qui a été précalculé. En cas
de différence entre les deux graphes, un signal d’erreur est levé.
2.1. Contre-mesures contre les attaques par faute
2.1.3.2
41
Syndrome anormaux
Une autre technique, proposée dans [53, 54], est de se baser sur les syndromes
anormaux du processeur pour la détection des fautes. Lorsqu’une faute survient,
les données pourront être corrompues. A un moment donné, le transfert ou le calcul de ces données incorrectes peut conduire à des événements anormaux comme
le changement du flot du programme conduisant à une mauvaise prédiction de
décision de branchement, le dépassement de résultat calculé, l’accès mémoire sur
les zones non autorisées, le blocage d’exécution du processeur, etc . . . . De telles
méthodes sont peu coûteuses en termes de matériel et de performances car des
composants qui servent à capter ces syndromes sont intrinsèquement intégrés
dans le processeur moderne comme le processeur superscalaire. Par contre, la
couverture de fautes apportée par ces méthodes est faible car il est clair que si
les attaques peuvent précisément fauter quelques bits sur une donnée, ces syndromes anormaux ne peuvent pas se produire. En plus, comme la détection de
faute n’est déclenchée que lorsqu’un syndrome anormal survient, la latence de la
détection peut être longue et donc il est possible que la sortie du résultat erroné
soit observable par l’attaquant.
2.1.4
Stratégie de réaction
2.1.4.1
Recouvrement
Nous appelons par la suite « stratégie de réaction » tout mécanisme de décision qui permette au composant d’activer une réaction ou de paramétrer en
autonomie et de façon optimale les contre-mesures en fonction du contexte environnemental (déterminé par exemple par les valeurs des détecteurs d’intrusion
décrits dans les paragraphes précédents) et du contexte applicatif (déterminé
par la sensibilité des informations manipulées). Suivant la stratégie choisie, les
performances du circuit (en termes de vitesse et de consommation) et sa disponibilité sont améliorées sans remettre en cause bien sûr sa sécurité. Dans un
premier temps, nous présenterons les mécanismes simples de réaction et décrirons
ensuite brièvement les mécanismes les plus évolués.
Par exemple, certains travaux ont suggéré de simple stratégies telles que
la terminaison définitive ou le redémarrage du système. De telles mécanismes
peuvent être visibles aux attaquants en utilisant les techniques d’analyse de puissance consommée, rendant le système vulnérable à l’attaque « safe-error » qui
est capable de déduire les données secrètes en se basant sur le comportement
anormal du système comme décrit précédemment dans 1.2.3.2. Le recouvrement
est une stratégie de sécurité permettant de maintenir l’opération du processeur
en état de marche après avoir détecté les fautes. Certaines techniques de recouvrement ont été proposées. La plupart d’entre eux se basent du processus
42
Chapitre 2. Contre-mesures
de « sauvegarde-recouvrement ». La sauvegarde est un point de sauvegarde qui
stocke l’état correct du processeur tandis que le recouvrement est une reprise
du point de sauvegarde lors de la détection des fautes pour revenir à un état
correct.Lors de sauvegarde, le processeur va sauvegarder les données actuelles
des registres architecturaux (compteur du programme, pointeur de pile ou banc
de registres, etc), du cache ou de la mémoire. Ce processus peut être facilement
effectué par la réplication [31, 55]. Cependant, pour le cache ou la mémoire, cette
approche induit un grand surcoût en terme d’espace de stockage. D’autres techniques n’utilisant pas la réplication ont été aussi proposées. Elles peuvent être
classées en trois catégorie suivantes :
2.1.4.1.1 Mise en tampon Introduit par Tamir et al. dans [56], cette technique repose sur le fait que lorsqu’un emplacement (cache/mémoire) est mis à
jour depuis la création d’une sauvegarde, sa valeur reste inchangée tandis que
son adresse ainsi que sa nouvelle valeur sont stockés dans un tampon basé sur
la mémoire de type CAM. À la prochain sauvegarde, la nouvelle valeur dans le
tampon est réécrite vers l’emplacement suivant l’adresse stockée. Pendant l’exécution, lors de la lecture/écriture de la mémoire, l’adresse est comparée à celle
stockée dans le tampon afin de vérifier si l’emplacement de cette adresse a été
mis à jour ou non.
Ce schéma ressemble à celui utilisé dans les processeurs modernes pour traiter les erreurs de prédiction. En effet, ces processeurs sont capable d’exécuter
plusieurs instructions en désordre afin d’accroître la performance du processeur
[57]. Dans ce cas, les instructions dites « spéculatives » qui se placent après une
instruction de branchement peuvent être exécutées en faisant la prédiction du
résultat de branchement. Si cette prédiction est incorrecte, ces instruction spéculatives pourrons modifier le contenu des registres ou de la mémoire. Pour prévenir
ce problème, un tampon appelé « Reorder Buffer » est utilisé pour stocker temporairement les résultats des instructions exécutées. Ces résultats ne sont écrites
vers des registres ou la mémoire que lorsque la prédiction est correcte. Certains
travaux [32, 58, 53] ont exploité ce mécanisme pour offrir le recouvrement couplé
avec la détection des fautes dans des processeurs modernes.
2.1.4.1.2 Mise en tampon dans le cache de données Le cache de données est une petite mémoire permettant au processeur d’accéder rapidement aux
données les plus fréquemment utilisées qui sont copiées depuis la mémoire. Cette
technique de recouvrement repose sur le même principe de la technique précédente en utilisant le cache comme un tampon pour stocker des valeurs mises à
jour pour la mémoire. Comme adressé dans [59], dès qu’une sauvegarde est établie, le processeur peut mettre à jour le cache, mais pas la mémoire. Les lignes
de cache qui sont modifiées, appelées les lignes sales, seront stockées dans la
2.1. Contre-mesures contre les attaques par faute
43
mémoire lors de la prochaine sauvegarde. Lors du recouvrement, le contenu du
cache est vidé puis être rechargé à partir de la mémoire durant l’opération de
recouvrement. Le fait de transférer les lignes « sales » vers la mémoire à chaque
sauvegarde va introduire une dégradation importante de la performance du processeur durant l’exécution normale. Pour limiter cet impact Hunt et al. [60] ont
proposé une solution qui consiste à marquer les lignes « sales » comme « inchangeables » au lieu de les déplacer dans la mémoire et les lignes restantes comme
« propres » au moment de la création d’une sauvegarde. Après cela, seules les
lignes « propres » peuvent être modifiées mais pas les lignes « inchangeables ».
Lorsque le recouvrement est déclenché, toutes les lignes exceptées celles « inchangeables » sont supprimés dans le cache. L’inconvénient principal de la technique
de recouvrement basé sur le cache est que, lorsque le processeur doit modifier
les lignes « inchangeables » ou « sales », une nouveau sauvegarde est forcée afin
d’écrire les lignes « inchangeables » dans la mémoire. Cela n’est pas souhaitable
pour des systèmes qui ont besoin de contrôler le moment de création d’une sauvegarde comme c’est le cas dans les circuits sécurisés. En effet, pour ceux-ci, si
la sauvegarde est créée alors que la vérification est toujours en cours les données
qui pourraient être corrompues par l’attaquant seront sauvegardé (car l’erreur
n’est pas encore détectée) et puis, récupérés lors du recouvrement, entraînant le
recouvrement incorrect.
2.1.4.1.3 « Logging » Cette technique est duale de celle de « mise en tampon ». Le principe est que lorsqu’un emplacement dans la mémoire est modifié,
la mise à jour sera effectué et la valeur originale (avant la mise à jour) ainsi
que l’adresse de l’emplacement modifié sont stockés dans un tampon. Lors du
recouvrement, les valeurs originales sont réécrites à l’emplacement de la mémoire
indiquées par adresses stockées. Ce schéma est initialement introduit dans [61].
Prvulovic et al. [62] ont ensuite proposé le système Revive qui combine la technique « basée sur le cache » et « logging » pour le recouvrement. Lorsque les
lignes « sales » doivent être mises à jour, celles-ci et leurs adresses sont sauvegardées. Sorin et al. [63] ont proposé le système Safety qui applique le « logging »
pour le cache et la mémoire.
L’avantage de cette technique « logging » est qu’elle permet d’éviter les pertes
en performances induites par les deux techniques précédentes. En effet, ces dernières nécessitent durant l’exécution normale (sans fautes), de prendre le temps
de mettre à jour les modifications vers la mémoire lors d’une sauvegarde.
2.1.4.2
Stratégies de sécurité évoluées
Des stratégies de sécurité plus évoluées qu’un simple recouvrement en cas
d’erreur ont été proposées. Elles reposent sur l’adjonction au système initial de
44
Chapitre 2. Contre-mesures
matériel dédié à l’application de ces stratégies. Deux types d’architectures ont
été proposées.
La première, proposée dans [64] pour des cibles FPGA, est basée sur des
moniteurs connectés en réseau. Certains d’entre eux mesurent l’état du circuit,
configurent des contre-mesures, voire modifient l’implantation de primitives de
cryptographie. L’un de ces moniteurs, appelé SEP (pour Security Executive Processor) centralise l’information en provenance des autres moniteurs. Cette architecture prévoie deux types de réactions. L’une, de type réflexe, permet à un
moniteur qui détecte un état anormal de réagir directement. L’autre, plus lente,
passe par le SEP qui appliquera la réaction telle qu’elle a été définie à la conception du circuit. Cette architecture a été validée pour optimiser la gestion de
l’énergie dans le composant.
La seconde, proposée dans [65] pour des cibles de type ASIC, est également
constitué de mécanismes qui mesurent l’état du circuit (appelés « capteurs »)
et qui peuvent configurer des contre-mesures (appelés « actionneurs »). Ces mécanismes peuvent être matériel et/ou logiciels. Contrairement à la première architecture, l’implantation de primitives ne peut pas être modifiée. De même, les
actionneurs et capteurs ne sont pas connectés en réseau mais seulement à un
contrôleur additionnel via des registres et des FIFO pour les capteurs et actionneurs respectivement matériels et logiciels. Le contrôleur additionnel, appelé
système d’audit a son propre espace mémoire et met en œuvre la stratégie de réaction définie à la conception. Celle qui a été proposée est formalisée sous forme
de règles permettant de traduire relativement aisément l’expertise d’un concepteur de systèmes sécurisés. Ces règles sont exprimées grâce à la logique floue en
langage naturel (c’est-à-dire à l’aide d’adjectifs tels que « élevé », « moyens »,
« faible »).
2.1.5
Réduction de la sensibilité
2.1.5.1
Technologie
Seules des solutions technologiques approchées ont été proposées pour rendre
le circuit insensible aux fautes. Il peut s’agir de mettre en place des filtres passebas sur l’alimentation pour absorber les impulsions sur l’alimentation, d’utiliser
une horloge interne pour rendre le circuit insensible à l’« overclocking », de déposer des couches réfléchissant un faisceau laser, des capots métalliques pour
blinder les circuits des agressions électromagnétiques, etc. . . . D’autres méthodes
se concentrent sur la minimisation des charges électriques collectés en cas d’attaque par lumière. Par exemple, dans [66], les auteurs proposent d’implanter une
troisième couche, appelée « deep n-well », entre les zones N+ et le substrat P
dans le composant CMOS pour se débarrasser des électrons créés sous l’effet
2.1. Contre-mesures contre les attaques par faute
45
de la lumière, qui peuvent inverser la valeur des noeuds sensitifs. De même, la
technologie « Silicon-on-insulator » [67] peut être utilisée pour isoler les noeuds
sensibles avec le substrat en silicium.
2.1.5.2
Micro-architecture
Les circuits asynchrones offrent une solution efficace pour résister à des attaques de variation de l’horloge ou de tension d’alimentation car l’horloge ne
cadence pas leur calculs et leur vitesse de fonctionnement s’adapte aux modifications de la tension d’alimentation [68, 69]. Par contre, une étude récente montre
que la sensibilité aux attaques laser n’est que peu diminuée par rapport aux
circuits synchrones [70].
2.1.5.3
Triplication
Étant un type de redondance spatiale, la triplication utilisant 3 circuits identiques est capable de masquer l’effet fautes à l’aide d’ un voteur majoritaire
qui sert à sélectionner la bonne sortie. Lorsqu’un des trois circuits est fauté, le
système va utiliser l’une des deux autres sorties, non fauté et par conséquent
identique pour continuer le fonctionnement. Vu de l’extérieur nous ne pouvons
pas savoir si les fautes sont effectivement survenues ou non.
46
Chapitre 2. Contre-mesures
2.2
Contre-mesures contre les attaques par observation
Le principe des contre-mesures contre les attaques par observation se base
généralement sur la réduction du rapport entre le signal et le bruit. Celle-ci est
parvenue soit en réduisant l’amplitude du signal soit en ajoutant du bruit.
2.2.1
Réduction du signal
On distingue deux techniques permettant de réduire le signal :
2.2.1.1
Équilibrage
Cette technique vise à maintenir une grandeur physique du circuit (consommation, temps de calcul, etc) constante quelles que soient les données manipulées.
Pour équilibrer la consommation des circuits, de nombreuses études [69] ont
suggéré d’employer les circuits logiques en double-rail qui se basent sur codage
1 parmi 2 permettant de garder la symétrie entre le bit ’1’ et ’0’. L’architecture
de tels circuits est généralement composé d’un circuit logique complémentaire de
l’original pour équilibrer la transition des bits qui contribue la consommation du
circuit. La Figure 2.9 illustre un schéma global d’un circuit logique en doublerail avec deux entrées. Le partie logique en double-rail est implémentée de telle
sorte que les deux sorties complémentaires soient générées : l’une provenant de
la logique originale et l’autre provenant de la logique duale.
A noter que cette logique double rail peut également être utilisées pour détecter des erreurs. A cet effet, deux signaux d’erreur peuvent également être générées
par deux comparateurs duaux (deux portes XOR et XOR inversé) générant deux
signaux d’erreur complémentaires. Ces deux signaux sont complémentaires en cas
de perturbation sur la partie logique. Si un des deux comparateurs est perturbé,
ces deux signaux sont identiques, ce qui entraîne systématiquement une alarme
sur le système.
En termes de consommation, lors d’une transition de bit de 0 à 1 sur le circuit
original, le circuit complémentaire subit en même temps une transition de 1 à 0
(1-0). Cependant, cela n’est pas suffisant pour garder la consommation constante
car le nombre des transitions (0-1) et (’1-0’) peuvent être variables en fonction
des données d’entrées, et aussi car il existe un déséquilibre de consommation pour
les différentes transitions (0-1 et 1-0) [71]. Pour rendre le nombre des transitions
indépendant des données, une phase de « précharge » a été ajoutée dans l’opération de ces circuits. De nombreuses portes logiques de type spécifique comme
SABL (Sense Amplifier Based Logic) [71], WDDL (Wave Dynamic Digital Logic)
[72] ont été introduites pour intégrer la phase de précharge dans leur opération.
2.2. Contre-mesures contre les attaques par observation
A
A
B
47
Résultat
Logique originale
Résultat
Logique duale
B
Erreur
Erreur
Figure 2.9 – La logique en double-rail avec deux entrées
La logique SABL est une logique dynamique (précharge) et différentielle (deux
fils par signal) permettant d’avoir toujours un événement de commutation par
cycle quelque soit la valeur en entrée.
Ces deux techniques nécessitent une attention lors de conception en phase de
placement routage car il apporte de nombreux déséquilibres entre les chemins,
notamment source de fuites. Deux méthodes pour y remédier ont été proposées.
La première consiste à placer les portes logiques et router les pistes qui les relient
en mode différentiel afin de rendre les chemins électriques de charge et décharge
les plus symétriques possibles [73]. Supatra et al. [74] appliquent le même principe
afin d’équilibrer la consommation lors du chargement des données sur un bus de
données du processeur. Un bus de 32 bits va être augmenté jusqu’à 64 bits dans
lesquels 32 bits sont complémentaires aux autres. Pendant la phase de précharge,
tous les 64 bits sont préchargées au niveau ’1’. Pendant la phase d’évaluation, 32
bits du bus sont chargés à la valeur actuelle (32 bits) tandis que les 32 autres
bits sont complémentaires aux premiers 32 bits, ce qui fait qu’il y a certainement
32 bits parmi 64 bits vont se décharger de 1 à 0. Ensuite, une autre phase de
précharge est répétée, ce qui fait que 32 de 64 bits vont se charger de 0 à 1. Et
on obtient finalement un équilibre entre le nombre de transitions 0-1 et 1-0. La
seconde méthode, appelée STTL (pour Secure Triple Track Logic) vise à réduire
les différences de temps de calcul qui peuvent apparaître entre deux étages de
mémorisation [75]. Pour cela, un fil supplémentaire a été rajouté à chacun des
canaux double rail. La propagation du signal porté par ce fil est retardé de telle
sorte que ce signal n’est valide que lorsque les données codées en double rail sont
stables. La validité de ce fil conditionne l’échantillonnage de ces données dans
l’étage de mémorisation positionné en aval.
48
2.2.1.2
Chapitre 2. Contre-mesures
Filtrage
Quelques approches de filtrage ont été proposées. Dans [76], les auteurs ont
proposé d’implanter dans une puce un circuit dédié servant à isoler l’alimentation
externe de celle interne du circuit en utilisant deux capacités de découplage. Dans
un premier temps, la capacité 1 est chargée par la source d’alimentation externe
tandis que la capacité 2 est déchargée en alimentant le circuit. Dans un second
temps, les rôles de ces deux capacités sont inversés. Ainsi, le courant observé
à l’extérieur est uniforme, ce qui rend le circuit immunisé contre l’attaque en
consommation.
Une autre approche, proposée dans [77, 78, 79], consiste à réduire la variation
du courant de consommation en introduisant un circuit analogique servant à
réguler le courant total autour d’une valeur prédéfinie quelque soit l’opération
du système [78]. Muresan et al. [80] appliquent le même principe au niveau
processeur en insérant des instructions « NOP » durant l’exécution du processeur
afin d’augmenter le temps de décharge du courant permettant de maintenir le
courant dissipé à une valeur constante.
2.2.2
Ajout du bruit
Dans cette section sont décrites des techniques qui ajoutent du bruit sur
l’amplitude, ou l’ajoutent à l’instant d’exécution d’instructions sensibles (on
parle alors de désynchronisation ou d’exécution non déterministe). D’autres techniques, dites de masquage, rendent impossibles la prédiction des calculs intermédiaires nécessaires aux attaques par corrélation.
2.2.2.1
Parallélisation d’opérations indépendantes
Il est important de noter que les efforts faits sur l’équilibrage des données ne
rentrent pas dans ce cadre. En effet lors de l’équilibrage, les opérations sont faites
en parallèle mais ces opérations ne sont pas indépendantes (l’une est la duale de
l’autre). Dans le cas du parallélisme, c’est bien le niveau de bruit que l’on cherche
à augmenter et non la valeur du signal à réduire. En prenant l’exemple de l’AES,
soit on pipeline soit on augmente la taille des chemins de données. Il serait
bien évidement possible de faire les deux à la fois mais le surcoût deviendrait
certainement prohibitif.
2.2.2.2
Modification dynamique de la tension
Il s’agit de faire varier aléatoirement la tension d’alimentation du circuit.
L’amplitude de la variation doit être cependant relativement faible pour qu’aucune erreur de fonctionnement n’apparaisse. Les circuits asynchrones QDI sont
2.2. Contre-mesures contre les attaques par observation
49
particulièrement bien adaptés pour l’implantation d’une telle contre-mesure car
ils acceptent des variations importantes de la tension d’alimentation (quasiment
jusqu’à VDD
+ 10%).
2
2.2.2.3
Désynchronisation
2.2.2.3.1 Ajout de jigue sur l’horloge Il s’agit de modifier aléatoirement
la fréquence d’horloge du circuit. L’amplitude de la modification (ou jigue) doit
être suffisamment importante pour « étaler » les calculs sensibles mais tout de
même assez faible pour que les calculs soient réalisés correctement (c’est-à-dire
que les temps de setup et de hold des bascules soient garantis).
2.2.2.3.2 Ajout d’instructions factices Il s’agit d’exécuter des opérations
qui n’ont pas de fonction autre que de créer une surconsommation lors ou entre les
étapes d’un calcul sensible (« dummy operations »). L’exécution des opérations
peut être fixe (pour rendre plus difficile les attaques simples) ou aléatoirement
distribuée à chaque calcul sensible (contre SPA et DPA). L’exécution peut être
réalisée en parallèle (par exemple, calcul du processeur pendant un calcul cryptographique sur le coprocesseur) ou insérée temporellement (comme représenté en
Figure 2.10) pour les calculs des S-Boxes dans une ronde AES. Une implémentation possible consiste un générateur de nombre aléatoire dont les sorties sont
fortement chargées lors d’un calcul sensible. Dans tous les cas, cet ajout coûte
en consommation et s’il est réalisé temporellement, également en performance.
Figure 2.10 – Insertion d’instructions factices lors d’un calcul
50
Chapitre 2. Contre-mesures
Pour mettre en œuvre ce principe dans un processeur, Irwin et al. [81] ont
introduit dans le pipeline un étage de Mutation qui est placé devant l’étage
d’exécution. En phrase de compilation, un traitement en logiciel est effectué
sur le code pour connaître l’état (« utilisé » ou « non utilisé ») des registres en
insérant dans le code deux instructions spéciales LIV E and DEAD. Lors de
l’exécution de ces instructions, l’état des registres est déterminé et stocké dans
un tableau implanté dans l’étage « Mutation ». Chaque fois que ce dernier trouve
que l’état d’un registre est changé de « utilisé » vers « non utilisé », il produit
une instruction factice qui va mettre à jour ce registre, ce qui permet d’introduire
un niveau non-déterministe en maintenant la justesse du programme exécuté. A
titre d’exemple, le code ci-dessous illustre l’ajout des instructions factices en se
basant sur l’état des registres.
LIVE
LOADC
LIVE
LOADC
LIVE
ADD
DEAD
SUB
MUL
DEAD
DIV
LIVE
LOADC
..
.
R0
R0,
R1
R1,
R2
R2,
R0
R0,
R2,
R2
R2,
R2
R2,
..
.
; R0 est « utilisé »
#1
; R1 est « utilisé »
#2
; R2 est « utilisé »
R0, R1
R1, R2
R2, R1
R1, R0
; R0 est « non-utilisé »
; Etage de Mutation ajoute une instruction factice
; R2 est « non-utilisé »
; Etage de Mutation ajoute une instruction factice
; R2 est « utilisé »
#3
Cette approche nécessite la modification du code par logiciel qui n’est pas
triviale et la taille du code est considérablement augmentée.
La proposition d’Ambrose et al. [82] se base également sur l’ajout des instructions factices mais diffère de celle énoncée dans [81] en les injectant à un
endroit aléatoire du code. Pour ce faire, les auteurs ont proposé de modifier le
code en phrase de compilation pour introduire deux instructions spéciales, appelées SET _F LAG et RESET _F LAG, qui sont placées respectivement au début
et à la fin d’un bloc d’instructions afin de contrôler l’initialisation et l’arrêt de
l’injection des instructions factices. De plus, l’instruction SET _F LAG sert à
stocker deux paramètres suivantes :
– N : le nombre maximum des instructions factices injectées entre deux instructions normales
– D : le nombre maximum des instructions normales exécutées avant chaque
injection. En d’autres termes, l’injection ne peut être faite qu’après l’exécution de ce nombre d’instructions.
2.2. Contre-mesures contre les attaques par observation
51
Le Tableau 2.2.2.3.2 présente des séquences possibles d’instructions quand
N = 3 et D = 3 (on note ’X’ une instruction factice injectée) ;
Séquence originale
Séquence 1
Séquence 2
Séquence 3
Séquence 4
I1 I2 I3 I4 I5 I6 I7 I8 I9
I1 I2 XXI3 XI4 I5 I6 XXI7 I8 XXXI9
I1 XI2 I3 I4 XXXI5 XXI6 I7 XXXI8 I9
I1 I2 I3 XXI4 XI5 XXXI6 I7 I8 XI9
I1 I2 I3 XXXI4 I5 I6 XXI7 XI8 XXI9
Tableau 2.3 – Séquences possibles d’instructions quand N = 3 et D = 3
Étant donné que l’exécution des instructions factices pourraient modifier les
valeurs des registres utilisés par des instructions normales, les instructions factices
possibles sont restreintes à celles qui ne modifient aucune valeur de ces registres.
Il peut s’agir, par exemple, d’une addition du contenu d’un registre Rn avec la
valeur 0 avec écriture du résultat dans Rn .
2.2.2.3.3 Redistribution aléatoire d’instructions utiles indépendantes
(« suffling ») Il s’agit de redistribuer aléatoirement les opérations indépendantes dans un ensemble donné d’instructions. Ceci va produire des traces de
consommation différentes à chaque lancement du même programme, rendant la
mise en oeuvre des attaques par canaux cachés beaucoup plus délicate. La Figure 2.11 représente une telle redistribution des calculs de S-Boxes dans une
ronde de l’AES. Cette contre-mesure n’a d’impact ni sur les performances ni sur
la consommation mais son efficacité est extrêmement dépendante de la structure
du code exécuté. En effet, moins il y aura d’instructions indépendantes, plus le
bruit ajouté sera faible.
Quand ce principe de redistribution aléatoire des instructions est appliqué à
un processeur, on parle de processeur « non-déterministe » c’est-à-dire qui est
capable d’exécuter les instructions en ordre aléatoire sans pour autant changer le
résultat final du programme exécuté. May et al. [7] ont proposé un tel processeur.
Les auteurs introduisent un matériel dédié comme le montre la Figure 2.12, qui
consiste à choisir de façon aléatoire des instructions indépendantes et puis les
exécuter.
52
Chapitre 2. Contre-mesures
Figure 2.11 – Redistribution aléatoire d’instructions indépendantes
Figure 2.12 – Matériel de sélection et d’exécution aléatoire des instructions [7]
Ce matériel reçoit comme entrée une instruction, puis la divise en trois opérandes : les deux premières sont les adresses du registre de source et la troisième
est l’adresse du registre de destination. Chaque opérande est vérifiée via un tableau appelé « Random Issue Buffer » stockant des bits de masque indiquant si
les registres de source de cette instruction sont le résultat d’une instruction précédente et son registre de destination est un registre de source d’une instruction
précédente. Une instruction est considérée indépendante si les bits de masque ne
2.2. Contre-mesures contre les attaques par observation
53
sont pas activés (mis à ’0’). L’unité « Random Instruction Selection », utilisant
un générateur du nombre aléatoire, va ensuite choisir au hasard une des instructions indépendantes et celle-ci sera ordonnée par l’unité « Instruction Table »
pour l’exécution.
Afin d’augmenter le niveau de « non-déterministe » du processeur, les mêmes
auteurs ont proposé le renommage aléatoire des registres [83] lors de l’exécution
des instructions. Le renommage des registres est réalisé à l’aide d’un ensemble
des registres virtuels, utilisés dans l’ensemble des instructions du processeur,
et un ensemble des registres physiques, utilisés par l’étage d’exécution lors de
l’exécution. A un moment donné, chaque registre virtuel est associé à un registre
physique. Lorsqu’un registre virtuel est réécrit, sa connexion avec un registre
physique correspondant est supprimée et un autre registre physique sera assigné
à ce registre virtuel. A titre d’exemple, considérons un segment du code suivant :
LOAD
STORE
LOAD
STORE
#A, R0
R0, #B
#C, R0
R0, #D
;R0 est réécrit
Il existe deux possibilités de renommage :
Premier Cas
LOAD
#A, Reg0
STORE Reg0, #B
LOAD
#C, Reg1
STORE Reg1, #D
Deuxième Cas
LOAD
#A, Reg1
STORE Reg1, #B
LOAD
#C, Reg0
STORE Reg0, #D
Cette technique améliore le niveau « non-déterministe » pour deux raisons :
– Le renommage des registres augmenté l’indépendance du code, offrant ainsi
plus de possibilités d’ordonnancement des instructions. Par exemple, dans
les deux cas, la première et troisième instruction ne sont plus dépendantes
et celles-ci peuvent être donc ordonnées en ordre aléatoire.
– Chaque fois qu’un registre physique est écrit, la valeur stockée dans ce
registre est modifiée. Cette modification, comme expliqué en 1.3.1.1, génère
une surconsommation qui augmente le niveau de bruit des mesures faites
par l’attaquant.
2.2.2.4
Masquage
Il s’agit de réaliser les opérations de cryptographie non pas directement avec
les textes clairs et les clefs secrètes mais dans un premier temps avec des données
issues de combinaisons entre celles-ci et un nombre aléatoire (le masque) puis
54
Chapitre 2. Contre-mesures
de recombiner le résultat obtenu et ce nombre aléatoire pour obtenir le résultat
original (c’est-à-dire non masqué).
Le principe de cette technique peut être facilement illustré par l’exemple du
masquage dit « booléen ». Soit une fonction f d’une variable u. Le concepteur
souhaite faire en sorte que le résultat de f ne puisse pas être prédit par l’attaquant. Il défini à cet effet une fonction f 0 telle que f 0 (u ⊕ r) = f (u) ⊕ r. f (u) est
dans ce cas calculée en effectuant f 0 (u ⊕ r) ⊕ r.
Cette technique nécessite donc le calcul de la fonction (f 0 ) combinant le
masque et la donnée pour chacun des masques. Cet inconvénient a été surmonté
pour sécuriser des implémentations matérielles et logicielles d’algorithmes de
cryptographie [84, 85, 86, 87] Cependant, le cas des processeurs est plus complexe car deux cas de figure se présentent. Soit les opérations réalisées par le
processeur sont des transferts de données (par exemple stockage dans la mémoire
ou chargement dans le pipeline) soit ces opérations sont de type arithmétique et
logique (réalisées dans l’UAL). Dans le premier cas, comme les valeurs des données ne sont pas modifiées, les fonctions f et f 0 sont les fonctions « identité ».
Masquer revient donc simplement à XORer la donnée avec un nombre aléatoire,
et démasquer à XORer cette donnée masquée avec le même masque. Deux mécanismes de masquage hors de l’UAL ont été proposés dans [88] et dans [89].
Pour les opérations arithmétiques et logiques, le calcul de la fonction f 0 , hors
certaines opérations comme le XOR et dans une certaine mesure l’addition et la
multiplication, est délicate. La sécurisation de ces opérations passe donc généralement par l’implantation de logiques équilibrées comme proposé, par exemple,
dans [90].
2.3
Conclusion
Ce chapitre est dédié à l’étude des contre-mesures proposées dans la littérature contre les attaques par faute et par observation. Même si certaines de
ces protection s’avère efficaces, à notre connaissance, aucune d’entre elles prise
unitairement, ne sécurise totalement un circuit. La sécurité de ce dernier passe
donc nécessairement par une combinaison judicieuse de différentes protections.
Dans le chapitre suivant est décrit l’environnement de conception qui sera utilisé
pour concevoir et valider les différentes contre-mesures que nous proposons dans
le cadre de cette thèse.
Deuxième partie
Conception
55
Chapitre 3
Environnement
Sommaire
3.1
Modèle de carte à puce utilisé . . . . . . . . . . . . . . . . 58
3.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.1.2 Processeur miniMIPS . . . . . . . . . . . . . . . . . . . . 58
3.1.2.1 Gestion des dépendances lors de l’exécution des
instructions . . . . . . . . . . . . . . . . . . . . . 60
3.1.2.2 Unité Arithmétique et Logique . . . . . . . . . . 61
3.1.3 Mémoires . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.4 UART 16550 . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.5 PRNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.6 Émulateur d’injection de fautes . . . . . . . . . . . . . . . 63
3.2 Flot de conception . . . . . . . . . . . . . . . . . . . . . . . 65
3.2.1 Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.2.2 Matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.2.1 Configurations matérielles . . . . . . . . . . . . . 66
3.2.2.2 Initialisation des modèles mémoires . . . . . . . 66
3.2.3 Simulation et test fonctionnel . . . . . . . . . . . . . . . . 67
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Ce chapitre présente l’environnement de travail utilisé dans la conception et
la validation des solutions proposées. Dans un premier temps, nous présenterons
le système cible, représentatif d’une carte à puce, sur lequel les contre-mesures
proposées ont été implémentées. Dans un second temps, nous décrirons les flots
de conception matérielle et logicielle qui servent à modéliser, simuler et valider
nos solutions.
3.1
3.1.1
Modèle de carte à puce utilisé
Architecture
Les contre-mesures proposées dans cette thèse sont implémentées sur une
plateforme de prototypage FPGA appelée PECAP (pour Prototype d’Émulateur
57
58
Chapitre 3. Environnement
de Carte à Puce). L’objectif de cette plateforme, réalisée au sein du département
SAS, est de simuler, tester et valider des contre-mesures aux attaques présentées
dans le chapitre 1. Cette plateforme, intégrée sur un FPGA de type Virtex 5
XC5VLX50, est constituée principalement des blocs suivants :
– Un processeur miniMIPS 32 bits,
– des mémoires RAM et ROM,
– un bus système avec un contrôleur de bus,
– un UART (pour « Universal Asynchronous Receiver Transmitter ») 16550,
– un PRNG (pour « Pseudo Random Number Generator »),
– un module d’injection de fautes.
Dans les sections suivantes, nous décrivons en détail ces différents éléments
constitutifs.
3.1.2
Processeur miniMIPS
Nous avons choisi un modèle de processeur aussi représentatif que ceux intégrés en cartes à puce. Pour pouvoir y intégrer nos contre-mesures, ce modèle
devait être également réutilisable et modifiable (« open source »). Le modèle de
processeur choisi est un RISC 32 bits, compatible avec le jeu d’instructions MIPS1 (qui compte 51 instructions). L’Annexe 6 présente des instructions typiques du
jeu d’instruction MIPS-1 qui sont utilisées dans les exemples d’illustration présentés dans les chapitres suivants. Notre modèle de processeur est basé sur le
projet Opencore miniMIPS ([91]) dans lequel la partie exécutive est constituée
d’un pipeline à 5 étages. Chaque étage réalise un traitement élémentaire. Ces
traitements, cités dans l’ordre de séquencement dans le pipeline, sont les suivant :
– [FETCH] Charger les instructions
– [DECODE] Décoder les instructions, lire des données à partir du banc de
registre
– [EXECUTE(EXE)] Exécute les instructions par l’UAL détaillée en 3.1.2.2
– [MEMOIRE(MEM)] Accéder à la mémoire (Lire/Écrire des données de/vers
la mémoire)
– [WRITE-BACK] Écrire des résultats vers le banc de registre
Les données se propagent dans le pipeline à raison d’un étage par cycle d’horloge ;
autrement dit, une instruction est exécutée, en moyenne, en un cycle horloge,
mais avec une latence de cinq cycles pour chaque instruction. L’intérêt de l’utilisation d’une structure de type pipeline est d’accroître les performances du cœur.
Mais il découle d’une architecture de type pipeline de nouvelles contraintes :
deux étages différents pouvant être amenés à manipuler sur le contenu du même
registre, les dépendances, détaillées en 3.1.2.1, doivent être gérées. Le miniMIPS
en cas de dépendance rompt le pipeline : le principe est d’interrompre le fonc-
3.1. Modèle de carte à puce utilisé
59
tionnement normal d’un étage qui travaille sur un registre partagé, jusqu’à ce
que le contenu de ce dernier ait été mis à jour. Afin d’éviter les ruptures de
pipeline trop fréquentes, le CPU doit posséder un nombre suffisant de registres
internes « (General Purpose Register » (GPR) . Le miniMIPS définit un banc
de 32 GPR, le premier registre, le registre 0 étant physiquement câblé à 0. Des
modifications importantes ont été réalisées sur le modèle miniMIPS pour améliorer la gestion des exceptions. Une vue de la partie exécutive du miniMIPS
est proposée sur la Figure 3.1. Enfin, à noter que le modèle possède un cache
d’instructions de 2 KOctets pour accélérer l’accès à la mémoire d’instructions
mais il ne possède pas de mémoire cache de données.
60
Chapitre 3. Environnement
Mémoire
d’instructions
MUX
Contrôleur du bus
+
MUX
4
+
PC
Cache
Décodeur
Adr.rs Adr.rt Adr.rd
Donnée
MUX
Contrôleur
Dépendances
Étage Mémoire
Adresse
ALU
Immédiate2
MUX
Instruction
Offset
Immédiate1
Banc de
registres
Fetch
Décode
Exécute
Mémoire
WB
Figure 3.1 – Architecture du processeur expérimenté
3.1.2.1
Gestion des dépendances lors de l’exécution des instructions
Dépendances de données Il existe trois types de dépendances de données :
1. Vraie dépendance - Lecture Après Écriture (LAE)
Cette dépendance existe lorsqu’une instruction utilise une donnée produite
par une instruction qui la précède. Elle ne peut être exécutée que si cette
donnée est disponible.
2. Antidépendance - Écriture Après Lecture (EAL)
3.1. Modèle de carte à puce utilisé
61
Cette dépendance existe lorsqu’une instruction veut écrire une donnée
dans un registre tandis qu’une instruction précédente doit lire la valeur
du même registre.
3. Dépendance de sortie - Écriture Après Écriture (EAE)
Cette dépendance est encore appelée « Écriture après Écriture ». Elle
existe lorsqu’une instruction veut écrire une donnée dans un registre tandis
qu’une instruction précédente doit également modifier la valeur du même
registre.
Notre processeur cible étant de type pipeline simple, avec des instructions exécutées dans l’ordre séquentiel du programme, nous ne nous intéressons qu’aux
vraies dépendances de données. Cependant, si on souhaite changer l’ordre d’exécution des instructions, comme dans le cas de notre approche proposée dans le
section 4.3, il faudra également gérer les antidépendances et les dépendances de
sortie.
Dépendances de contrôle Lors de l’exécution d’une instruction de branchement conditionnel, le chargement des instructions qui suivent le branchement ne
peut être effectué que lorsque les calculs de condition et d’adresse de destination
sont achevés.
Stratégie de résolution des dépendances Pour gérer ces dépendances durant l’exécution des instructions, la solution implémentée dans notre processeur
est de bloquer le pipeline en envoyant des « bulles », c’est-à-dire des instructions
N OP , jusqu’à ce que ces dépendances soient résolues.
3.1.2.2
Unité Arithmétique et Logique
Nous présentons dans cette section le modèle de l’UAL utilisé dans nos expérimentations. Ce modèle dispose des unités fonctionnelles suivantes : un additionneur, un multiplieur et une unité logique. Toutes ces unités peuvent réaliser leurs
calculs en un cycle horloge. L’unité logique est composée de circuits combinatoires
réalisant les opérations logiques telles que XOR, ET, OU, décalage, qui partagent
une partie des ressources matérielles. Cela signifie que les instructions réalisant
des opérations logiques différentes utilisent la même unité fonctionnelle. Il faut
également noter que l’additionneur dans notre modèle se charge non seulement
d’effectuer l’addition/soustraction (par exemple les instructions ADD, SU B )
mais aussi d’évaluer le résultat des instructions de branchement (par exemple
BEQ (« Branch On Equal »), BN E (« Branch Not Equal »). En revanche, pour
les instructions d’accès mémoire (par exemple LW (« Load Word »), SW (« Store
Word »)),certain mode d’adressage, nécessite l’ajout d’un « offset » à une adresse
62
Chapitre 3. Environnement
de base. Ce calcul d’adresse est pris en charge par un autre additionneur, implanté à l’extérieur de l’UAL dans l’étage d’exécution du processeur.
3.1.3
Mémoires
Les modèles de mémoires ROM et RAM intégrées dans PECAP sont basés
sur celles fournies par Xilinx sous la forme de blocs paramétrables et synthétisés
grâce à un outil spécifique. Ces blocs mémoires mobilisent des ressources dédiées
sur le FPGA.
3.1.4
UART 16550
L’UART réalise, de façon asynchrone, la sérialisation/désérialisation des données. Le modèle retenu consiste en une traduction VHDL des spécifications de
l’UART 16550 de National Semiconductor. Les sources VHDL sont issues du
projet de la plate-forme Opencores intitulé « a VHDL 16550 UART core » et
sont utilisables librement.
3.1.5
PRNG
Les nombres aléatoires sont des éléments particulièrement importants notamment en cryptographie. Deux types de générateurs de nombres aléatoires sont
utilisés, selon le degré de sécurité exigé par l’application :
– les TRNGs (pour « True Random Number Generator ») : extraient les
séquences de nombres de phénomènes physiques considérés comme aléatoires tels que le bruit thermique ou la métastabilité. Ils sont utilisés, par
exemple, pour la génération de clés sécrètes ou de challenges dans les protocoles d’authentification.
– les PRNGs : qui génèrent des séquences dont les propriétés statistiques
s’approchent de celles des séquences aléatoires mais qui ne le sont par réellement car complètement déterminées par un état initial. Ces générateurs
sont généralement plus faciles à concevoir et à intégrer que des TRNG et
peuvent être utilisés pour masquer des données lors d’un cryptage, ou encore pour brouiller les séquences d’algorithmes qui se déroulent au niveau
du microprocesseur.
C’est précisément pour ce type de fonctions (insertion aléatoire d’instructions
aléatoires décrite en 5.1) que nous avons choisi d’implémenter un générateur de
nombres pseudo-aléatoires. L’architecture retenue, couple un automate cellulaire
et un LFSR (Linear Feedback Shift Register). Un mécanisme de détection de
dysfonctionnement basé sur le calcul dynamique d’un biais statistique a ensuite
3.1. Modèle de carte à puce utilisé
63
été rajouté. Il est capable de reconnaître un état anormal de la séquence (blocage, répétitions . . . ). L’originalité de cet auto-test est qu’il a été conçu à partir
de scénarii d’attaques basés sur l’injection de fautes classiques (collage, inversion, etc..). En cas de détection d’un dysfonctionnement, le PRNG peut envoyer
l’information au processeur (pour qu’il choisisse la stratégie de sécurité à appliquer) mais également se réinitialiser et ainsi parer une attaque non permanente.
L’architecture globale du PRNG est reportée Figure 3.1.5. Des tests statistiques
classiques (Diehard, NIST,. . . ) ont été appliqués aux séquences générées. Des
simulations ont également permis de valider le bon fonctionnement du PRNG en
présence de perturbations.
Figure 3.2 – Architecture du PRNG
3.1.6
Émulateur d’injection de fautes
Pour tester les différentes contre-mesures aux attaques en faute qui seront
décrites au chapitre suivant, nous avons implémenté un mécanisme d’émulation
de fautes. Celles-ci peuvent être injectées soit sur des instructions transitant
entre le cache d’instruction et le pipeline, soit sur des résultats de l’UAL. Dans
le premier cas, la faute injectée est une inversion (de type bit flip) du bit de poids
faible. Dans le second cas, le résultat de l’UAL est complémenté (c’est-à-dire que
tous les bits du résultat sont inversés). Dans les deux cas, le déclenchement des
fautes se fait sur le numéro d’occurrence d’une instruction identifiée par son
adresse en mémoire.
La Figure 3.3 représente le mécanisme d’injection touchant l’instruction entre
le cache d’instructions et la mémoire. L’adresse de l’instruction à perturber
est stockée dans le registre F AU LT _ADRESSE et le numéro d’occurrence
64
Chapitre 3. Environnement
est codé dans 4 des bits du registre F AU LT _CON . Deux des autres bits de
F AU LT _CON servent à activer l’injection de fautes sur l’UAL (actif à l’état
haut) ou sur les instructions.
Cache
0x01
Injecteur
de
fautes
M
U
X
Adresse
enable_fault_instr
Fetch
Decode
UAL
Instruction
Mémoire
Execute
Pipeline 0xFF
M
U
X
MEM
WB
enable_fault_UAL
bit 1
FAULT_CON
FAULT_ADRESSE
bit 0
Comp
bit 2 to 5
Compteur
Comp
Figure 3.3 – Émulateur d’injection de fautes sur le code
Le fonctionnement du mécanisme est décrit dans l’Algorithme 2.
Algorithme 2 Algorithme décrivant le fonctionnement de l’émulateur d’injection de fautes
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
Paramétrer F AU LT _CON et F AU LT _ADRESSE
Obtenir l’adresse de l’instruction ADR_IN ST R
compteur = 0
si compteur == F AU LT _CON [5 : 2]and F AU LT _ADRESSE == ADR_IN ST R
alors
si F AU LT _CON [0] == ’1’ alors
active_f ault_instruction = ’1’
sinon si F AU LT _CON [1] == ’1’ alors
active_f ault_U AL = ’1’
sinon
active_f ault = ’0’
compteur = compteur + 1
finsi
finsi
A noter que les registres F AU LT _ADRESSE et F AU LT _CON sont considérés par le processeur comme des « périphériques » matériels à part entière.
Dans le cas particulier de la mise au point d’une contre-mesure matérielle ou
logicielle en code natif, l’outil utilisé pour les paramétrer est simplement le débogueur (comme GDB). Afin d’automatiser l’injection de fautes sur plusieurs
3.2. Flot de conception
65
adresses de façon aléatoire, nous avons par ailleurs utilisé un outil Expect [92].
Cet outil permet de lancer l’environnement de simulation et d’interagir avec le
prototype PECAP (dont les injecteurs) via le débogueur.
3.2
3.2.1
Flot de conception
Logiciel
Les applications utilisées pour évaluer l’impact des contre-mesures proposées
dans cette thèse, ont été extraites de la suite de benchmark Mibench [93], programmés en langage C. Le développement d’un code dans un tel langage de
programmation, doit se faire nécessairement en rapport avec l’architecture matérielle. Cet aspect dual est relativement transparent quand on développe un
logiciel sur l’ordinateur. Par exemple : les pilotes des couches logicielles les plus
basses ainsi que les « firmware » rattachés à un composant ont été développés
antérieurement et les programmeurs sur l’ordinateur utilisent les fonctions d’une
API (Application Programming Interface) de haut niveau. Dans notre cas, la
situation est très différente : l’assemblage des briques de base a dû être réalisé
en définissant notamment une affectation mémoire particulière. Le langage C
permet de travailler à un niveau relativement bas : on accède aux périphériques
en spécifiant une adresse via le mécanisme de pointeurs, ces derniers étant définis relativement pendant le partitionnement mémoire écrit en « dur » dans le
langage VHDL. Tous ces aspects sont regroupés sous le terme de co-conception.
Tous les outils de développement logiciel qui nous intéressent ici sont regroupés sous la suite SDE MIPS et fournissent par MIPS Technologies, Inc. La
plupart des logiciels utilisés sont issus des outils GNU sont :
– sde-gcc : compilateur C et assembleur
– sde-ld : éditeur de lien
– sde-objdump : désassembleur
– sde-objcopy : outil de conversion des formats exécutables
Ces outils sont conformes aux spécifications des microprocesseurs MIPS. Le
concepteur pourrait par exemple leur demander d’optimiser le programme au
moment de la compilation. En outre, ils supportent les différentes versions de
l’ISA MIPS. Illustrons par deux exemples ce point. Le modèle miniMIPS a été
développé pour être compatible avec l’ISA MIPS-1. Pour être en mesure de l’utiliser avec les outils de SDE MIPS, il faut simplement utiliser l’option -mips1.
De même, les instructions sont interprétées en adoptant le modèle de représentation « little endian », ce qu’on rappellera aux outils en leur passant l’option
-EL. Enfin, un programme spécifique permet de convertir l’exécutable binaire
en un fichier d’initialisation mémoire compréhensible par l’outil de synthèse de
66
Chapitre 3. Environnement
mémoire ROM Xilinx.
3.2.2
Matériel
Les contre-mesures proposées dans cette thèse sont développées en VHDL
et implantées dans les sources disponibles du processeur miniMIPS. La cible
matérielle finale, étant un FPGA Xilinx de type Virtex5 XC5VLX50.
En comparaison à un flot FPGA conventionnel, nous avons à résoudre deux
problèmes :
3.2.2.1
Configurations matérielles
Pour pouvoir tester et caractériser facilement de façon unitaire les contremesures matérielles il est nécessaire de pouvoir générer des configurations matérielles différentes. Cependant, les outils FPGA existants et notamment les outils
de synthèse (XST : Xilinx Synthesis Technology) ne savent pas bien gérer la
description de configuration proposée par le langage VHDL, c’est pourquoi nous
avons dû ajouter au flot VHDL existant l’utilisation de « directives » issues du
langage C , telles que : « ifdef . . . endif » permettant d’avoir un code VHDL
conditionnel. Une fois ce code conditionnel prétraité par un programme du type
préprocesseur C, on obtient un code source VHDL tout à fait classique et parfaitement compréhensible par les outils FPGA (ISE Xilinx).
3.2.2.2
Initialisation des modèles mémoires
Avant de pouvoir caractériser sur FPGA nos contre-mesures, il faut être en
mesure de pouvoir effectuer plusieurs simulations et ceci à différents niveaux
d’abstraction, du plus haut qui est la simulation le code VHDL lui-même au plus
bas qui est la représentions en portes logiques inter-connectées.
Un système basé sur microprocesseur possède presque toujours une mémoire dite
« non volatile » (ROM, flash . . .) capable de stocker les instructions de démarrage
du processeur (« boot ») de façon permanente, même en l’absence d’alimentation
électrique. Dans le cas d’un FPGA cette mémoire non volatile est en fait émulée
par un bloc de mémoire volatile (RAM) dont le contenu est initialisé à la mise
sous tension du FPGA. C’est en fait le « le bitfile » de configuration du FPGA
qui contient les valeurs d’initialisation de tels blocs de RAM.
Les blocs de mémoires volatiles (RAM) utilisés dans le FPGA ne font pas partie
de la description VHDL du design, mais pour pourvoir effectuer des simulations
aux différents niveaux d’abstraction on utilise des modèles VHDL dont le comportement est proche, au niveau fonctionnel et temporel, du bloc physique. Le
contenu de ces modèles mémoires doit être initialisé avant de pouvoir lancer une
3.3. Conclusion
67
simulation. Différents types et formats de fichiers sont utilisés pour cette initialisation car les modèles diffèrent d’un niveau d’abstraction à l’autre. Si les processeurs proposés par les fabricants de FPGA sont généralement bien supportés et
peuvent disposer d’outils spécifiques (EDK Xilinx) ce n’est, malheureusement,
pas le cas pour les autres. Dans notre flot ces différents fichiers d’initialisation
sont en fait générés automatiquement lors de la construction du code embarqué.
L’ensemble de ces ajouts au flot FPGA existant a été automatisé à l’aide de
l’utilitaire « Make ».
3.2.3
Simulation et test fonctionnel
Pour simuler et tester fonctionnellement les contre-mesures, nous avons développé l’environnement présenté dans la Figure 3.4. Cet environnement nous
permet de contrôler l’exécution du processeur modélisé en utilisant le débogueur
GDB dans la suite SDE. Cet environnement dispose d’un port série virtuel de
type UART 16550 connecté à celui de PECAP.
Le logiciel réalisant le test fonctionnel du système complet est constitué des
trois composants distincts :
1. Programme de test
Ce programme peut être choisi à partir de benchmarks afin de simuler,
tester ou évaluer les contre-mesures implémentées dans le processeur.
2. « Stub »
Un logiciel spécifique appelé « stub » sert à communiquer avec le débogueur. Une fois que le stub est lancé, il va d’abord surveiller les commandes
envoyées par l’utilisateur depuis le débogueur après, répondre en exécutant
des tâches demandées.
3. « Startup »
Ce logiciel, écrit en assembleur, sert à initialiser l’état du processeur et
lancer le « stub ». Celui-ci est exécuté au démarrage du processeur.
3.3
Conclusion
Dans ce chapitre, nous avons présenté notre plateforme de prototypage ainsi
que l’environnement de travail permettant de modéliser, simuler et valider les
contre-mesures proposées dans le chapitre suivant.
68
Chapitre 3. Environnement
PECAP
UART
16550
Port série
virtuel
miniMIPS
Mémoire
Contre−mesures
Débugger
Données d’initialisation
Pile
Programme de test
Startup
stub
Figure 3.4 – Environnement de simulation
Chapitre 4
Protection vis-à-vis des attaques
en faute
Sommaire
4.1
Détection des fautes . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Motivations et contribution . . . . . . . . . . . . . . . . .
4.1.2 Insertion des signatures dans le code . . . . . . . . . . . .
4.1.3 Segmentation des BBs . . . . . . . . . . . . . . . . . . . .
4.1.4 Architecture de vérification d’intégrité . . . . . . . . . . .
4.2 Système de recouvrement . . . . . . . . . . . . . . . . . .
4.2.1 Motivations et contribution . . . . . . . . . . . . . . . . .
4.2.2 Architecture du système de recouvrement . . . . . . . . .
4.2.3 Fonctionnement du système de recouvrement . . . . . . .
4.2.3.1 Pseudo-code « sauvegarde » . . . . . . . . . . . .
4.2.3.2 Pseudo-code « recouvrement » . . . . . . . . . .
4.2.3.3 Exemples de fonctionnement . . . . . . . . . . .
4.2.4 Évaluation du système de détection de fautes et de recouvrement pour l’intégrité du code . . . . . . . . . . . . . .
4.2.4.1 Surcoût matériel . . . . . . . . . . . . . . . . . .
4.2.4.2 Impact sur les performances . . . . . . . . . . .
4.2.4.3 Sécurité . . . . . . . . . . . . . . . . . . . . . . .
4.3 Protection de l’UAL . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Motivations et contribution . . . . . . . . . . . . . . . . .
4.3.2 Principe de détection . . . . . . . . . . . . . . . . . . . . .
4.3.3 Architecture de l’UAL . . . . . . . . . . . . . . . . . . . .
4.3.4 Mécanisme de recouvrement . . . . . . . . . . . . . . . . .
4.3.5 Ordonnancement statique . . . . . . . . . . . . . . . . . .
4.3.6 Évaluation de l’UAL sécurisée . . . . . . . . . . . . . . . .
4.3.6.1 Surcoût matériel . . . . . . . . . . . . . . . . . .
4.3.6.2 Impact sur les performances . . . . . . . . . . .
4.3.6.3 Sécurité . . . . . . . . . . . . . . . . . . . . . . .
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
70
70
72
72
76
76
77
79
79
79
81
84
84
85
87
88
88
90
91
92
93
96
96
97
99
99
69
70
Chapitre 4. Protection vis-à-vis des attaques en faute
Dans ce chapitre, trois contre-mesures vis-à-vis des attaques en faute sont proposées pour le processeur simple qui a été décrit dans le chapitre 3. La première
consiste à détecter, par redondance spatiale, des erreurs qui peuvent survenir
dans la mémoire d’instruction ou lors du transfert des instructions entre celle-ci
et le premier étage du pipeline. Cette protection est couplée à la seconde contremesure qui est une réaction du circuit en cas de détection d’erreur. Cette réaction
consiste à recommencer l’exécution du programme à partir d’un état sain. On
parle dans ce cas de « recouvrement ». La troisième contre-mesure consiste, par
redondance temporelle, à détecter des erreurs injectées dans l’UAL. L’évaluation
en termes de sécurité, de surcoût matériel et d’impact en performances est pour
chacune de ces contre-mesures estimée.
4.1
4.1.1
Détection des fautes
Motivations et contribution
Nous considérons que la méthode proposée par Ragel et al dans [50] pour tester l’intégrité de la mémoire d’instruction jusqu’à l’étage de décodage du pipeline
(et décrite dans 2.1.2.2 ) présente un compromis sécurité versus performances
intéressant. Néanmoins, dans le cadre de cette thèse, nous proposons une amélioration à cette méthode. Cette amélioration consiste à séquencer les calculs de
signatures sans avoir à rajouter dans le code des instructions factices de sauts.
Nous proposons également un mécanisme qui réduit artificiellement la taille d’un
BB afin de diminuer le temps de latence de la détection.
4.1.2
Insertion des signatures dans le code
Dans [50], la vérification d’intégrité d’un BB est faite après l’exécution de
sa dernière instruction. Pour séquencer ces vérifications, le processeur doit donc
savoir quand il atteint cette dernière instruction. Or celle-ci peut être une instruction de branchement (cas du BB2 de la Figure 4.1(a)) ou non, si elle est
suivie par une instruction qui est la destination d’un branchement (cas du BB1
de la Figure 4.1(a)). Pour que le processeur puisse distinguer ce cas, Ragel a proposé d’insérer, en plus des signatures, une instruction de branchement factice,
comme représenté en Figure 4.1(c). L’ajout de cette instruction factice augmente
artificiellement la taille du code.
La solution que nous proposons ne nécessite pas cette instruction factice de
branchement. Il s’agit, comme présenté sur la Figure 4.1(b), d’insérer uniquement
une instruction dite « de signature » au début de chaque de BB. Ainsi, le calcul de
4.1. Détection des fautes
71
L1 : add ...
Signature BB1
L1 : add ...
BB1
BB1
sub ...
BB1
sub ...
Ajout des signatures
L2: xor ...
BB2
Signature BB2
L2: xor ...
BB2
jmp ...
(a) BB original
Signature BB1
L1 : add ...
Ajout des signatures
sub ...
jmp (ajout d’un nouvel branchement factice)
Signature BB2
L2: xor...
BB2
jmp ...
(b) Notre méthode
jmp ...
(c) Méthode proposée dans [50]
Figure 4.1 – Ajout de la signature en début de bloc de base
la signature est déclenché sur cette instruction et s’arrête dès que le programme
atteint l’instruction de signature du BB suivant. Le Tableau 4.1 reporte le surcoût
de la taille du code de notre cas par rapport à celui de [50]. On constate que le
gain apporté est de 4 à 5 points.
Tableau 4.1 – Surcoût de la taille du code dû à l’ajout des signatures
Application Notre méthode Méthode utilisée dans [50]
Bitcount
21.71%
25.69%
ADPCM
22.69%
27.73%
Stringsearch
18.77%
22.3%
CRC32
22.35%
26.79%
SHA-1
19.42%
23.62%
Blowfish
12.13%
14.82%
DES
17.6%
21.3%
AES
19.21
23.25%
Il existe de nombreuses techniques utilisées pour la génération d’une signature
allant des CDEs (bit de parité, code de Hamming, CRC, etc. ) décrits dans
la section 2.1.1.2 à des algorithmes plus sophistiqués comme les fonctions de
hachage (MD5, SHA-1,etc. décrits dans [94], ...). Le choix d’une technique repose
sur un compromis entre le temps de génération des signatures, l’espace mémoire
nécessaire au stockage des signatures et la capacité de détection de fautes. Dans
le cadre de notre travail, l’algorithme CRC a été choisi, d’une part en raison de sa
génération rapide en matériel et pour son surcoût raisonnable en taille mémoire,
d’autre part en raison de sa robustesse en terme de détection de fautes. En effet,
la probabilité de détection des erreurs est égale au nombre de séquences ayant
le même CRC sur le nombre total de séquences possibles. Si m est la taille du
CRC et n la taille de la séquence, le nombre total de séquences possibles est
de 2n et le nombre de séquences ayant le même CRC est de 2n /2m = 2n−m . La
72
Chapitre 4. Protection vis-à-vis des attaques en faute
probabilité de détection des erreurs est donc de 2−m , indépendante de la taille
de la séquence d’instructions m. Un CRC sur 16 bits a été choisi pour calculer
la signature, cette taille étant conforme au standard décrit dans [95].
Nous avons défini une instruction spéciale dite « de signature » dont le code
opérationnel est codé sur 6 bits et dont l’opérande, la signature CRC est codée sur
16 bits. La Figure 4.2 présente l’instruction dédiée au stockage de la signature.
0
31 opcode 26 25
15
011111 00.....00
Signature (CRC 16)
Figure 4.2 – Format de l’instruction qui stocke la signature
4.1.3
Segmentation des BBs
Puisque la vérification de l’intégrité est effectuée lors de l’exécution de la
dernière instruction, la latence de détection dépend de la taille du BB. Plus la
taille du BB est grande, plus la latence de détection est importante. Or une
longue latence de détection peut être critique en terme de sécurité. En effet, il
est possible que l’effet d’une faute sur les instructions rende effective une attaque
avant sa détection.
L’identification des BBs et l’insertion des signatures au début des BBs à
partir d’un programme C ont été effectué selon un flot de conception logicielle
représenté en Figure 4.3. Dans ce flot, la source du programme (d’extension .c
est compilée (on parle de compilation « Front-End ») pour obtenir un code en
assembler (d’extension .s). A partir de ce dernier, un logiciel, nommé « parseur »
et développé dans le cadre de notre travail, identifie le début de chaque BB en
se basant sur des étiquettes produites dans le code en assembleur. Après cette
phase d’identification des BBs, leur signature est insérée dans le code assembleur
original, ce qui donne un nouveau code assembleur, noté .sign.s. Celui-ci est
ensuite passé à l’étape « Assemble and Link », puis à l’outil sde-objcopy pour
générer le code binaire.
Pour que le développeur logiciel puisse facilement réduire la taille des BBs,
nous avons défini des macros qui génèrent des étiquettes supplémentaires lors de
la compilation du code en assembleur. Ces macros sont activées via la commande
« asm(__BB_délimiteur :) », comme présenté dans le code 4.2.
4.1.4
Architecture de vérification d’intégrité
Nous avons implanté le matériel dédié à la vérification d’intégrité dans le
pipeline du processeur miniMIPS comme représenté dans la figure 4.4. Lors de
4.1. Détection des fautes
73
Sources .c
Compilateur Front−End
Fichier .s
(en assembleur)
Parseur
Identification
des étiquettes
Identification des BBs
Insertion des signatures
au début des BBs
Fichier .sign.s
(en assembleur)
Assemble et Link
Fichier exécutable elf
Outil sde−objcopy
Code binaire
Figure 4.3 – Flot de conception logicielle d’identification des BBs et d’insertion
des signatures
l’exécution d’un BB, la première instruction (de type « signature ») est chargée.
La signature qu’elle contient est ensuite extraite puis stockée dans le registre
de signature. En parallèle, l’adresse de cette première instruction est retenue
dans un registre permettant au processeur, en cas de recouvrement, de reprendre
74
Chapitre 4. Protection vis-à-vis des attaques en faute
Tableau 4.2 – Ajout des macros pour partitionner un bloc de base en sous blocs
de base
void authentication() { void authentication() {
while (condition) {
while (condition) {
statement1 ;
statement1 ;
..
statement2 ;
.
..
.
statement20 ;
..
asm(__BB_délimiteur :) ;
.
..
statement21 ;
.
..
..
.
.
..
statement40 ;
.
..
.
asm(__BB_délimiteur :) ;
statement60 ;
statement41 ;
..
.
}
}
statement60 ;
}
}
4.1. Détection des fautes
75
Recouvrement
Adresse
MUX
PC
Adresse BB
Vérificateur
Mémoire
d’instructions
EstSignature
EstBranchement
Invalide
Instruction
Cache
Générateur
CRC−16
Contrôleur
Comparateur
Registre de Signature
Instruction
FETCH
DECODE
EXECUTE
MEM
WB
Pipeline
Figure 4.4 – Intégration du matériel de vérification d’intégrité dans le pipeline
76
Chapitre 4. Protection vis-à-vis des attaques en faute
l’exécution au début de ce BB. Ensuite, les instructions suivantes sont chargées
et exécutées une à une dans le pipeline. Ces instructions sont également lues par
le générateur du CRC-16 pour recalculer la signature. A noter que la génération
du CRC va se faire lors de l’exécution des instructions, à la volée, grâce à la
méthode proposée dans [96]. Une fois que la dernière instruction du BB est
chargée, le calcul du CRC-16 est complet et le résultat va être ensuite comparé à
la valeur stockée dans le registre de signature. Si ces valeurs ne sont pas égales,
un signal est activé et le mécanisme de recouvrement est déclenché.
4.2
4.2.1
Système de recouvrement
Motivations et contribution
Dans le cadre de notre étude, le recouvrement consiste à réexécuter les BBs
pour lesquels une différence entre la signature calculée à la conception (c’est-àdire « off-line ») et celle calculée au cours de l’exécution est détectée. Ce schéma
pose le problème de la première exécution corrompue d’un BB qui peut modifier
la valeur des registres ou de la mémoire. A titre d’illustration, le Tableau 4.9
montre que la première exécution d’un BB modifie les registres sp, s8 ainsi que
l’emplacement mémoire à l’adresse s8+24. Il s’agit dont de restaurer les registres
et la mémoire pour effectuer un recouvrement correct.
Tableau 4.3 – Problématique sur le recouvrement en réexécutant un bloc de base
Ordre
1
Instructions
ADDIU sp,sp,-16
2
3
LW v0,28(s8)
SW s8,8(sp)
4
5
6
7
8
MOVE s8,sp
LW v0,24(s8)
NOP
OR v0,v0,v1
SW v0,24(s8)
Note
sp est modifié et sa nouvelle valeur va être lue quand cette
instruction sera réexécutée
s8 est modifié et sa nouvelle valeur va être lue quand l’instruction 2 sera réexécutée
La nouvelle valeur du mem[s8 + 24] va être lue quand l’instruction 5 sera réexécutée
Nous avons considéré que la sauvegarde et la restauration des registres du
processeur peut être réalisée par simple duplication. Une telle duplication est, par
contre, rédhibitoire dans le cadre de notre travail pour la mémoire. Ainsi, notre
travail porte essentiellement sur la réduction du coût induit par le mécanisme de
recouvrement de la mémoire. Pour réduire ce coût, la solution que nous proposons
se base sur la technique « logging » et possède les avantages suivants par rapport
aux méthodes présentées dans la section 2.1.4.1.3 :
4.2. Système de recouvrement
77
– Dans les méthodes existantes basées sur la technique « logging », chaque
fois qu’un emplacement mémoire est modifié, la sauvegarde des valeurs
originales est déclenchée [61]. Cela signifie que lors d’une écriture à un emplacement mémoire, le processeur doit y faire une lecture additionnelle afin
de récupérer la valeur originale et la stocker dans un tampon. Le fait d’exécuter une lecture additionnelle à chaque écriture peut entraîner une dégradation importante de la performance. Nous remarquons que ce processus
n’est pas toujours nécessaire. En effet, avant l’exécution d’une instruction
d’écriture, s’il n’y pas d’instructions de lecture à cette adresse à partir du
début du BB, il n’est pas nécessaire d’effectuer la sauvegarde. En effet, en
cas du recouvrement, la première instruction d’écriture est réexécutée en
effaçant la valeur potentiellement corrompue par la première exécution. De
ce fait, notre proposition est de ne sauvegarder un emplacement mémoire
que lorsqu’il est lu et après écrit. Cela permet de réduire la taille de la zone
mémoire (ou tampon) nécessaire pour le stockage des valeurs originales.
– Dans les méthodes existantes, en cas de recouvrement, toutes les valeurs
originales sauvegardées sont restaurées en une fois à partir du tampon vers
la mémoire. Ce processus peut être long et potentiellement détectable via
une analyse de la consommation de puissance, rendant ainsi le système vulnérable à certaines attaques comme celle proposée dans [20]. Notre méthode
va rendre de telles attaques plus difficiles en effectuant la restauration des
données de façon aussi « furtive » que possible. A cet effet, les valeurs originales des données sont restaurées une-à-unes uniquement lorsque le BB
qui est réexécuté les manipule.
4.2.2
Architecture du système de recouvrement
Le mécanisme de recouvrement choisi pour le banc de registre consiste à
doubler ce dernier : le banc normal et le banc de sauvegarde comme décrit dans
la figure 4.5. Au début de l’exécution d’un BB, le signal sauvegarde est activé
pour transférer des données à partir du banc normal vers le banc de sauvegarde.
Lors du recouvrement, le signal restaure est activé et déclenche la recopie des
valeurs du banc de sauvegarde vers le banc normal.
Quant à la mémoire, nous souhaitons faire en sorte que la sauvegarde des
valeurs originales ne soit réalisée que pour des emplacements mémoire qui sont
lus et ensuite écrits. A cet effet, nous avons introduit dans le processeur un
composant dédié nommé GSR (Gestion de Sauvegarde et Restauration) qui, à
partir des opérations lecture/écritures de la mémoire, décide quand le système
doit faire la sauvegarde durant l’exécution normale et quand le système doit faire
la restauration pendant le recouvrement. Le GSR est constitué principalement
du TMA (pour Tableau de Moniteur d’Adresses) qui est la zone mémoire sup-
78
Chapitre 4. Protection vis-à-vis des attaques en faute
Banc de registres de sauvegarde
D Q
E
Reg1 32bits
Banc de registres normal
Adresse de registre de lecture 1
M
U
X
D Q
E
32bits Reg1
Restaure
D Q
E
32bits
Reg2
M
U
X
M
U
X
Sortie de registre 1
M
U
X
Sortie de registre 2
D Q
E
32bits Reg2
Restaure
D Q
E
32bits
Reg31
M
U
X
D Q
E
32bits Reg31
Restaure
MUX
Adresse de registre de lecture 2
Restaure
Banc de registres normal
Décodeur
Sauvegarde
Banc de registres de sauvegarde
Donnée à écrire
111...111 Adresse de registre d’écriture
Figure 4.5 – Architecture de la duplication du banc de registres pour la sauvegarde
plémentaire destinée à stocker les valeurs modifiées lors de l’exécution d’un BB.
Cette zone, comme illustré dans le Tableau 4.4, stocke des éléments suivants :
– Adresse (A) : Ce champ stocke les adresses qui sont lues en mémoire. A
noter que nous avons fait en sorte que ces adresses ne soient stockées qu’une
seule fois.
– Etat_Sauvegarde (ES), Etat_Restauration (ER) : Ces deux bits servent
à indiquer respectivement si la sauvegarde ou la restauration a déjà été
effectuée sur l’adresse Adresse.
– V aleur_Sauvegarde (V S) : Ce champ stocke la valeur d’un emplacement
mémoire (cette valeur sera utilisé en cas de recouvrement).
La Figure 4.6 présente l’intégration du GSR dans le pipeline du processeur.
On constate que les données peuvent transiter via différents chemins. Ceux-ci
sont sélectionnées grâce aux multiplexeurs nommés MEMR (pour MEM-Read,
contrôlé par le signal rc) et MEMW (pour MEM-Write, contrôlé par le signal
wc) de la façon suivante :
– De la mémoire de données (MEM) vers le banc de registre (WRS) : (MEM_out
4.2. Système de recouvrement
79
Tableau 4.4 – Structure du TMA
Adresse
(A)
s8+28
s8+24
..
.
..
.
Etat_Sauvegarde
(ES)
0
1
..
.
..
.
Etat_Restauration
(ER)
0
0
..
.
..
.
Valeur de sauvegarde
(VS)
0
Mem[s8+24]
..
.
..
.
⇒ WRS_in si rc=0)
– Du tampon (TMA) vers le banc de registre (WRS) : (TMA_out ⇒ WRS_in
si rc=1)
– Du tampon TMA vers la mémoire de données (MEM) : (TMA_out ⇒
MEM_in si wc=0)
– De l’étage d’exécution (EXE) vers la mémoire de données (MEM) : (EXE_out
⇒ MEM_in si wc=1)
A noter également qu’un chemin relie la mémoire de données (MEM) vers
le tampon (TMA). Le fonctionnement du système complet et en particulier le
transfert des informations sur ces différents chemins, est décrit dans le paragraphe
suivant.
4.2.3
Fonctionnement du système de recouvrement
4.2.3.1
Pseudo-code « sauvegarde »
Durant l’exécution normale, le GSR reçoit une opération ainsi que sa ou ses
opérandes. Si cette opération est une lecture, l’opérande, notée AR , est l’adresse
à lire. Dans ce cas, le GSR transfert le contenu de la mémoire à l’adresse AR
vers le banc de registre (noté W RS). Si cette adresse est lue pour la première
fois, il ajoute AR dans le TMA. Si l’ opération reçue par le GSR est une écriture,
ses opérandes sont l’adresse à écrire, notée AW , et la valeur à écrire vk , laquelle
est stockée dans l’étage EXE. Si l’adresse Aw est dans le TMA (elle a donc
été préalablement lue), le GSR sauve dans le TMA la valeur qui était stockée
en mémoire à cette adresse. Cette opération de sauvegarde induit une lecture
additionnelle. Ensuite, le GSR écrit la donnée vk dans la mémoire à l’adresse
Aw . Le pseudo-code 3 décrit ce mécanisme de sauvegarde.
4.2.3.2
Pseudo-code « recouvrement »
En mode « recouvrement », lorsque l’opération est une lecture, trois cas se
produisent. Si la sauvegarde de la donnée à l’adresse AR a été réalisée lors du
fonctionnement normal (elle est alors dans le TMA) et que la donnée à cette
80
Chapitre 4. Protection vis-à-vis des attaques en faute
rc
TMA
AMT_out
FETCH
Adresse
wc
MEMR
WRS_in
Adresse
EXE_out
GSR
DECODE
Mémoire
de
Données
MEMW
MEM_out
EXECUTE
Backup
MEM
WRITE REG
Reg File
Pipeline du Processeur
Figure 4.6 – Intégration du système de sauvegarde et de restauration dans le
pipeline du processeur
4.2. Système de recouvrement
Algorithme 3 Algorithme décrivant le mécanisme de sauvegarde
1: si Opération est Lecture mémoire alors
2:
/* Opération est Lecture Mémoire à l’adresse AR */
3:
rc = 0 /* MEM_out ⇒ WRS_in*/
4:
WRS=MEM[AR ]
5:
Obtenir l’adresse de lecture AR
6:
si AR n’existe pas dans TMA alors
7:
/* Créer et initialiser la ligne associée à l’adresse AR */
8:
Ajouter AR à la ligne LM du TMA
9:
TMA[LM ][ES]=0
10:
TMA[LM ][ER]=0
11:
TMA[LM ][VS]=NULL
12:
finsi
13: sinon
14:
/* Opération est Écriture Mémoire à l’adresse AW avec la valeur vk */
15:
Obtenir l’adresse d’écriture AW
16:
si (AW existe dans TMA) alors
17:
/* Sauvegarder la valeur originale avant de l’effacer*/
18:
Obtenir la ligne LM où AW est trouvée
19:
si TMA[LM ][ES]==0 alors
20:
TMA[LM ][ER]=1
21:
TMA[LM ][VS]=MEM[AW ]
22:
finsi
23:
finsi
24:
MEM[AW ]=vk
25: finsi
81
82
Chapitre 4. Protection vis-à-vis des attaques en faute
adresse n’a pas encore été restaurée, la restauration doit être réalisée. Le GSR
active le signal rc pour que le processeur charge directement la donnée stockée à
partir du TMA et l’écrive dans l’étage d’écriture de registres (WRS). En parallèle, le GSR demande au processeur de faire une écriture à la place d’une lecture
normale en activant le signal wc afin de ramener la valeur originale stockée dans
TMA vers la mémoire de données. Dans ce cas, cette écriture n’impacte pas la
performance du processeur, car celle-ci remplace la lecture normale. Si la sauvegarde de la donnée à l’adresse AR a été réalisée lors du fonctionnement normal
mais que sa restauration déjà eu lieu ou si la donnée n’a pas été sauvegardée lors
du fonctionnement normal, le GSR transfert la donnée de la mémoire de données
vers le banc de registre.
Lorsque l’opération est une écriture, la donnée vk est écrite en mémoire à
l’adresse AW . Par ailleurs, si le contenu de cette adresse avait été préalablement
sauvegardé, le bit RS est levé pour faire en sorte qu’à la prochaine lecture,
la valeur à récupérer soit celle stockée en mémoire et non celle présente dans
le TMA. Un tel cas est décrit plus précisément dans le paragraphe 4.2.3.3. Le
pseudo-code 4 décrit ce mécanisme de restauration.
4.2.3.3
Exemples de fonctionnement
Dans cette section, le fonctionnement du système de sauvegarde/recouvrement
pour une adresse A0 arbitraire est illustré par un exemple. Pour celui-ci :
– Inst désigne les instructions de lecture/écriture suivantes
– (w, vj ) instruction d’écriture de la valeur vj à l’adresse A0
– (r) instruction de lecture à l’adresse A0
– ([ES], [ER], [V S]) désigne le triplet (TMA[L0 ][Etat_Sauvegarde], TMA[L0 ][Etat_Restauration], TMA[L0 ][V aleur_Sauvegarde]), avec L0 la ligne
du TMA où l’adresse A0 est stockée. φ correspond à l’état où la ligne L0
n’a pas été créée pour l’adresse A0 dans le TMA.
– [A0 ] désigne la valeur stockée en mémoire à l’adresse A0 . Cette valeur est
égale initialement à v0 .
Considérons tout d’abord l’exécution normale de la séquence d’écritures, de
lectures puis d’écritures présentée dans le Tableau 7(a). A l’étape 0, la table
TMA ne contient pas l’adresse A0 et [A0 ] = v0 . Les étapes 1 à j constituent une
séquence d’écritures des valeurs v1 à vj en A0 . Comme A0 n’a pas été lue, le TMA
reste inchangé. L’étape j + 1 est la première lecture de la valeur vj stockée en A0 .
Une ligne dans le TMA est créée et cette ligne contient le triplet (0, 0, N U LL)
(activation des lignes de 6 à 12 du pseudo-code de sauvegarde). S’ensuit alors
une séquence de lectures qui ne modifient pas la valeur de ce triplet. L’étape
k + 1 est une écriture. Comme cette fois-ci, l’adresse A0 est dans le TMA, les
lignes de 16 à 22 du pseudo-code de sauvegarde sont activées. La valeur vj est
4.2. Système de recouvrement
83
Algorithme 4 Algorithme décrivant le mécanisme de restauration
1: si Opération est Lecture mémoire alors
2:
/* Opération est Lecture Mémoire à l’adresse AR */
3:
Obtenir l’adresse de lecture AR
4:
si (AR existe dans TMA) alors
5:
Obtenir la ligne LM où AR est trouvée
6:
si (TMA[LM ][ES]==1) et (TMA[LM ][ER]==0) alors
7:
/* Restauration : Donnée lue à partir du TMA et copiée dans MEM
et WRS*/
8:
TMA[LM ][ER]=1
9:
wc=1 /* TMA_out ⇒ MEM_in*/
10:
MEM[AR ]= TMA[LM ][VS]
11:
rc=1 /* TMA_out ⇒ WRS_in*/
12:
WRS=TMA[LM ][VS]
13:
sinon
14:
/* Restauration déjà réalisée : Donnée lue à partir de la mémoire et
copiée dans WRS*/
15:
rc=0 /* MEM_out ⇒ WRS_in*/
16:
WRS=MEM[AR ]
17:
finsi
18:
sinon
19:
/* Adresse non sauvegardée : Donnée lue à partir de la mémoire et copiée
dans WRS*/
20:
rc=0 /* MEM_out ⇒ WRS_in*/
21:
WRS=MEM[AR ]
22:
finsi
23: sinon
24:
/* Opération est Écriture Mémoire à l’adresse AW avec la valeur vk (stockée*/
25:
/* Donnée lue à partir du EXE et copiée dans MEM*/
26:
wc = 0 /* EXE_out ⇒ MEM_in*/
27:
MEM[AW ]=vk
28:
Obtenir l’adresse d’écriture Aw
29:
si (AW existe dans TMA) alors
30:
Obtenir la ligne LM où Aw est trouvée
31:
si (TMA[LM ][ES]=1) and (TMA[LM ][ER]=0) alors
32:
TMA[LM ][ER]=1
33:
finsi
34:
finsi
35: finsi
84
Chapitre 4. Protection vis-à-vis des attaques en faute
alors sauvée dans le TMA. Toute écriture suivante à l’adresse A0 ne modifiera
pas le triplet (1, 0, vj ) associé mais [A0 ] sera modifié.
Étape
0
1
...
j
j+1
...
k
k+1
...
l
Inst
φ
(w, v1 )
...
(w, vj )
(r)
...
(r)
(w, vk+1 )
...
(w, vl )
([ES], [ER], [V S])
φ
φ
...
φ
(0, 0, N U LL)
...
(0, 0, N U LL)
(1, 0, vj )
...
(1, 0, vj )
[A0 ]
v0
v1
...
vj
vj
...
vj
vk+1
...
vl
Tableau 4.5 – Séquence de sauvegarde
La restauration associée à la même séquence d’écritures, de lectures et d’écritures est présentée dans le Tableau 7(b). En début de restauration, la ligne
associée à l’adresse A0 contient le triplet (1, 0, vj ) et AO = vl . Lors de la première écriture dans A0 , les lignes 23 à 35 du pseudo-code de restauration sont
activées. Celles-ci invalident la donnée stockée dans le triplet en initialisant la
valeur ER à 1. Sans cette précaution, à l’étape j + 1, la donnée vj aurait été
restaurée à l’adresse A0 . Ceci aurait été un problème dans la mesure où cette
valeur sauvegardée est issue d’une exécution incorrecte.
Étape
0
1
...
j
j+1
...
k
k+1
...
l
Inst
φ
(w, v1 )
...
(w, vj )
(r)
...
(r)
(w, vk+1 )
...
(w, vl )
([ES], [ER], [V S])
(1, 0, vj )
(1, 1, vj )
...
(1, 1, vj )
(1, 1, vj )
...
(1, 1, vj )
(1, 1, vj )
...
(1, 1, vj )
[A0 ]
vl
v1
...
vj
vj
...
vj
vk+1
...
vl
Tableau 4.6 – Séquence de restauration
Plusieurs exemples de fonctionnement pour différentes séquences de lectures
et d’écritures sont proposés en Annexe 6.
4.2. Système de recouvrement
85
4.2.4
Évaluation du système de détection de fautes et de
recouvrement pour l’intégrité du code
4.2.4.1
Surcoût matériel
Le système de recouvrement présenté dans les sections précédentes est essentiellement constitué du tableau TMA. Cette tableau est une mémoire de type
CAM, c’est-à-dire constituée d’une mémoire accessible en lecture et en écriture
ainsi que d’autant de comparateurs que la table a d’entrées. Comme ces comparateurs sont assez coûteux en matériel, on doit choisir avec soin la « taille » du
TMA. Cette taille est définie par la suite comme étant la taille en nombre de
bits des adresses qui identifient ses entrées. Soit n la taille du TMA, le nombre
d’entrées qui peuvent y être stockées est de 2n .
La première analyse réalisée pour choisir cette taille a consisté à estimer le
surcoût matériel du TMA pour une de taille de ce dernier égale à 3 et à 4. Le
Tableau 4.12 reporte les résultats obtenus. On constate qu’en utilisant une taille
de TMA égale à 3 au lieu de 4, on réduit le surcoût en nombre de LUTs de
23.95% à 18.8% et celui en le nombre de bascules de 91.29% à 68.86%.
Tableau 4.7 – Surcoût matériel de recouvrement entre TMA=3 et TMA=4
Processeur original
Processeur intégrant le matériel de recouvrement
(Taille du TMA = 3)
Processeur intégrant le matériel de recouvrement
(Taille du TMA = 4)
LUTs
4567
5426
(+18.8%)
5661
(+23.95%)
Bascules
2367
3997
(+68.86%)
4528
(+91.29%)
La seconde analyse a consisté à évaluer le nombre maximal d’adresses à sauvegarder lors de l’exécution des applications. Les résultats obtenus sont reportés
en Figure 4.7. On constate que pour le code original auquel des signatures en
début de chacun de ses BBs ont été ajouté, le nombre maximal d’adresses à
sauvegarder varie de 11 à 14. Dans ce cas, la taille du TMA doit être égale à 4
(2n ≥ 14 ⇒ n ≥ 4).
Nous avons ensuite, grâce aux outils décrits en 4.1.3, limité la taille maximale
des BBs à une valeur fixée de 8 (MBB=8). Cette limitation de la taille maximale
des BBs implique une augmentation de leur nombre d’où une augmentation du
nombre de signatures ajoutées pour la vérification de leur intégrité. La figure
4.8 montre l’impact sur la taille du code de la limitation des BB à la valeur 8.
On peut observer que la taille du code pour MBB=8 est légèrement augmentée
de 4% à 6% par rapport au code original. Nous considérons que ce surcoût est
acceptable au regard du gain matériel obtenu par la réduction à 3 de la taille du
TMA. Par conséquent, c’est cette valeur qui est retenue par la suite.
Chapitre 4. Protection vis-à-vis des attaques en faute
Max number of stored read addresses in the AMT
86
15
10
5
0
nt
ou
c
Bit
m
rch
pc
ea
s
Ad
ing
Str
2
C3
CR
sh
A-1
wfi
SH
o
l
B
S
DE
S
AE
Figure 4.7 – Nombre maximal des adresses de lecture dans le TMA
4.2.4.2
Impact sur les performances
En fonctionnement normal, le processeur requiert un temps supplémentaire
pour faire une lecture additionnelle des données qui sont sauvegardées dans le
TMA. Cette sauvegarde impacte donc les performances du processeur. Pour évaluer cet impact comparativement aux autres schémas proposés dans la littérature,
nous avons, dans un premier temps, comparé le nombre de sauvegardes réalisées
avec notre technique (où seules les données qui sont écrites après avoir été lues
sont sauvegardées) et le nombre de sauvegardes réalisées avec les techniques existantes (où toutes les données qui sont écrites sont sauvegardées). Les résultats
obtenus sont reportés dans le Tableau 4.8. Ils montrent que le nombre de sauvegardes requis pour notre solution est beaucoup moins important que celui requis
pour les schémas existants. De plus, en cas de MBB=8, le nombre d’opérations
de sauvegarde peut encore être réduit comme les cas des algorithmes SHA-1,
Blowfish et AES.
Dans un second temps, nous avons calculé l’impact de notre solution en terme
de CPI (pour Cycles par Instruction). La Figure 4.9 présente ce CPI pour l’implantation du schéma de recouvrement sur l’exécution du code original et du
Code size overhead due to added signatures
4.2. Système de recouvrement
25%
87
Original Code
MBB = 8
20%
15%
10%
5%
0%
A-1
SH
h
s
wfi
o
l
B
S
DE
S
AE
Figure 4.8 – Impact de la taille du code dû à l’ajout des signatures
code avec MBB=8. Les résultats montrent que notre solution induit une très
faible réduction de performance.
Il est à noter que dans le cas de MBB=8, le code est modifié en ajoutant plus
de signatures et donc la taille du code est augmentée. Mais le CPI est moins grand
que dans le cas de l’exécution du code original. La raison est que l’exécution des
instructions de signature est rapide, comparée à celle des autres instructions, par
exemple les instructions d’accès mémoire comme LW et SW . Pour l’illustrer,
prenons l’exemple suivant. Supposons que dans le code original nous ayons 10
instructions de signatures (S) et 100 autres instructions (I). Supposons également
que la moyenne cycles/instruction des signatures S soit de 1 (la signature est
rapide) et des instructions I soit de 2. Pour le code original, le CPI est égal à :
200 + 10
= 1, 9
110
Supposons le code soit maintenant modifié en augmentant de 50 à 100 signatures.
Dans ce cas, le CPI est égal à :
200 + 50
= 1, 6
150
88
Chapitre 4. Protection vis-à-vis des attaques en faute
Tableau 4.8 – Nombre des opérations de sauvegarde durant l’exécution normale
Emplacement mémoire
Emplacement mémoire
« lu et après écrit »
est écrit
(Les schémas existants basés sur
(Notre solution)
le « logging »)
MBB = 8 Code original MBB = 8
Code original
SHA-1
258
376
2986
2986
Blowfish
351
380
21354
21354
DES
231
231
2832
2832
AES
1316
1836
13120
13120
No recovery support (Original Code)
With recovery support (Original Code)
No recovery support (MBB=8)
With recovery support (MBB =8)
Cycle per instruction
2.00
1.50
1.00
0.50
0.00
A-1
SH
Blo
h
s
wfi
S
DE
S
AE
Figure 4.9 – Impact sur la performance durant l’exécution normale
4.2.4.3
Sécurité
Notre système de recouvrement a été soumis à des tests intensifs d’injection
de fautes grâce à l’émulateur décrit dans la section 3.1.6. Ces tests ont prouvé
la robustesse de notre système. Cette méthode nous a cependant permis de détecter un cas où notre approche ne fonctionne pas correctement. Il s’agit du cas
où l’attaquant change une instruction de lecture (LW ) en une instruction d’écriture (SW ). Considérons l’ensemble des instructions reportées dans le Tableau 4.9
comme un BB objet d’une attaque en faute. Dans le cas où la deuxième instruction de lecture mémoire LW v0,28(s8) est changée par l’attaquant en l’instruction
d’écriture mémoire SW v0,28(s8), la valeur originale à l’adresse s8 + 28 est alors
accidentellement modifiée. A la fin de l’exécution du BB, le système détecte une
4.3. Protection de l’UAL
89
erreur et le recouvrement est déclenché. Durant cette opération, le processeur reexécute LW v0,28(s8) qui va lire la valeur de l’emplacement mémoire à l’adresse
s8 + 28, laquelle est incorrecte.
4.3
4.3.1
Protection de l’UAL
Motivations et contribution
Intégrée à l’étage d’exécution du processeur, l’UAL est un composant effectuant des opérations arithmétiques et logiques. Ce composant réalise non seulement les opérations centrales des algorithmes de cryptographie mais également
les tests conditionnels. C’est pourquoi il est l’une des cibles privilégiées pour les
attaques en fautes décrites dans la section 1.2. Nous proposons dans le cadre
de cette thèse une contre-mesure qui consiste à protéger l’UAL contre de telles
attaques. Par ailleurs, comme cette contre-mesure est destinée à être implantée
dans un processeur embarqué de carte à puce qui possède des contraintes de surface et de performance, nous nous intéressons à une solution permettant d’offrir
un faible coût en terme de matériel, une faible perte de performance tout en
assurant un niveau de sécurité élevé.
Les techniques de redondance, décrites dans la section 2.1.1.2 sont couramment utilisées afin de protéger les circuits logiques en général et l’UAL en particulier. Parmi ces techniques, la technique de redondance temporelle semble un
bon choix, car elle induit un surcoût matériel beaucoup plus faible que celui des
autres techniques (redondance spatiale et redondance d’information), en offrant
une haute capacité de détection de fautes transitoires. Cependant, la technique
de redondance temporelle présente deux principaux inconvénients. Le premier est
qu’elle n’est pas capable de détecter les fautes permanentes. Ce problème peut
être résolu à l’aide d’une variante de la technique de redondance temporelle basée
sur une réexécution différente du calcul original . Le deuxième inconvénient est
le temps additionnel important dû à la réexécution et qui peut dégrader significativement la performance. Nous pensons que cet impact peut être réduit en
mettant à profit les éléments suivants :
Temps Libre (TL) Ce facteur est défini comme l’intervalle de temps pendant
lequel le processeur est bloqué à cause d’événements tels qu’un défaut du
cache, une dépendance d’instructions (l’exécution de la dernière instruction
ne peut pas avancée tant que les résultats des instructions précédentes ne
sont pas prêts), etc. Si une réexécution est effectuée pendant le TL, il n’y
pas de temps additionnel.
Matériel Libre (ML) L’UAL d’un processeur est généralement composée d’unités fonctionnelles (UF) distinctes correspondant à chaque type d’opération,
90
Chapitre 4. Protection vis-à-vis des attaques en faute
par exemple l’unité additionneur, l’unité multiplieur ou l’unité logique. A
un instant donné, il est possible qu’une de ces unités ne soit pas utilisée lors
de l’exécution d’une instruction. L’état d’une unité non utilisée est appelée
« Matériel Libre ». En l’occurrence, une réexécution peut être réalisée sur
le ML sans nécessiter de temps additionnel.
Ordonnancement des Instructions (OI) L’ordonnancement est un processus qui consiste en fonction de critères de latences, de disponibilité de matériel, à modifier l’ordre des instructions sans modifier la validité du code,
en respectant les dépendances de données. L’ordonnancement des instructions peut être réalisé afin que la réexécution se fasse au moment de TL ou
ML. Le surcoût en temps serait alors nul.
Des travaux précédents ont proposé d’exploiter les facteurs TL et ML avec réordonnancement des instructions afin de réduire les temps d’exécution pour les
processeurs complexes tels que CRAY-1 [97] ou les processeurs superscalaires
[98]. Notre travail consiste à utiliser ce type de techniques dans des processeurs
simples comme ceux utilisés dans la carte à puce. Dans ce contexte, nous avons
apporté les contributions suivantes :
– Les processeurs complexes offrent de multiples unités fonctionnelles identiques, implantées dans l’UAL, permettant d’exécuter plusieurs instructions
en parallèle en vue de maximiser la performance. Le taux de ML est donc
important. Pour un processeur simple, l’UAL possède plusieurs unités fonctionnelles, mais aucune d’entre elles n’est identique. En effet, ce type de
processeur doit être optimisé en surface pour les applications portables.
Dans ce travail, nous introduisons une solution permettant d’exploiter le
facteur ML dans un processeur simple. L’idée repose sur le constat suivant :
lorsque deux instructions consécutives dont les opérations sont distinctes,
c’est-à-dire qu’elles sont réalisées par deux unités fonctionnelles distinctes,
la réexécution de la première instruction peut être effectuée en même temps
que l’exécution de la seconde instruction. Dans ce cas, il n’y aucune perte
de performance.
– Les processeurs complexes intègrent un matériel dédié qui consiste à ordonnancer les instructions de façon dynamique, c’est-à-dire à la volée, lors
de l’exécution. Comme un processeur simple ne dispose pas en général de
tel matériel, notre solution s’est donc orientée vers un ordonnancement
statique. Pour cet ordonnancement statique, nous proposons d’utiliser un
algorithme basé sur l’algorithme « List Scheduling » comme utilisé dans
[99] et dans les principaux compilateurs afin d’ordonner les instructions
de telle sorte que des instructions consécutives nécessitent des opérations
distinctes.
–
4.3. Protection de l’UAL
4.3.2
91
Principe de détection
Fetch
Decode
UAL
Soient A et B deux instructions consécutives (B après A) et A1, A2 et
B1,B2 respectivement leurs opérandes, qui sont lues à partir du banc de registres. Les opérateurs de l’UAL (par exemple ADD, XOR,etc.) utilisés par
A et B sont respectivement notés optypeA et optypeB. Nous dirons que ces
derniers sont distinctes s’ils ne partagent aucune ressource matérielle (notation
optypeA ∩ optypeB = ). En d’autres termes, les opérateurs sont distincts s’ils
sont réalisées à l’aide de blocs logiques différents. A noter que cette notion de distinction entre les opérateurs n’est pas mathématique mais dépend uniquement de
l’architecture de l’UAL. Par exemple, dans notre cas, on peut avoir ⊕ ∩ ⊕ =
6 ;
∩ 6= ; + ∩ − = . Une analyse statistique que nous avons réalisée sur un
ensemble de programmes représentatifs a montré que le cas où deux instructions
consécutives partagent des opérateurs (c’est-à-dire optypeA ∩ optypeB 6= )
n’apparaît que dans environ 15% des cas. Cette analyse nous a incité à exploiter
le matériel libre (facteur ML) pour sécuriser notre UAL.
MEM
WB
Execute
Cycle
1
A
2
B
3
4
A
B
A
B
A
Réexécution de A
Figure 4.10 – Principe de fonctionnement de notre UAL sécurisée
Le Tableau 4.10 illustre le principe de sécurisation proposé. Au 1er cycle,
A est chargée dans le pipeline de l’étage de Fetch. Au 2e cycle, B est chargée
dans le pipeline et A est passée à l’étage de Décode. Au 3e cycle, A est passée
à l’étage d’Exécution où l’UAL réalise l’opération optypeA. Au 4e cycle, B est
passée à l’étage d’Exécution où l’UAL lit l’opération optypeB et vérifie ensuite
si les opérations optypeA et optypeB réalisées par A et B utilisent deux unités
fonctionnelles différentes. Si c’est le cas, l’UAL exécute B en parallèle avec la
réexécution de A. Dans le cas contraire, le processeur est bloqué durant un cycle
(ce qui stoppe l’avancement des instructions dans le pipeline) afin que l’UAL
puisse réexécuter A. Après cela, le processeur est débloqué et l’UAL exécute B.
L’algorithme de détection d’erreurs dans l’UAL est don le suivant :
92
Chapitre 4. Protection vis-à-vis des attaques en faute
Algorithme 5 Algorithme de vérification dans l’UAL
Entrées: optypeA /* Opération précédente*/
Entrées: optypeB /* Opération courante*/
Entrées: RA /* Résultat de l’opération A stocké dans un registre*/
Entrées: VA /* Recalcul de l’opération A*/
Sorties: Erreur /* Résultat de test : 0 si faute, 1 sinon*/
si optypeB ∩ optypeA = alors
Calculer B et parallèlement calculer VA et ERREU R = (VA 6= RA
sinon
Bloquer l’avancement du pipeline, calculer VA et ERREU R = (VA 6= RA )
Débloquer l’avancement du pipeline, calculer B
finsi
4.3.3
Architecture de l’UAL
La Figure 4.11 décrit l’architecture globale de notre UAL sécurisée, laquelle
est constituée de 3 blocs principaux :
B1
Banc
B1
de
Registres
B1
A2
R
A1
B1
A1
optypeA
B1
Additionneur
0
1
A1
=
A1
B1
B1
Bloque le processeur ?
Stocker les opérandes
et le type d’opération
A1
0
1
0
1
0
1
UF
résultat B
=
Erreur ?
Multiplicateur
UF
res_logic
MUX2
R
res_add
0
1
Encodeur
optypeB
UF
MUX1
B2
optypeB
0
1
res_mult
A1
R
résultat réexécuté A
Logique
Sélection des opérandes
pour les différentes UFs
optypeA
Vérification du résultat réexécuté
avec celui stocké précédément
Figure 4.11 – Architecture globale de notre UAL sécurisé
Lorsque l’instruction B est exécutée dans l’UAL, le premier bloc sauvegarde
les optypeA et les opérandes A1 et A2 dans les registres additionnels R.
Le deuxième bloc comprend un encodeur et des multiplexeurs. L’encodeur
calcule les signaux de contrôle des multiplexeurs à partir des valeurs optypeA et
4.3. Protection de l’UAL
93
optypeB. Les multiplexeurs aiguillent en fonction de ces signaux de contrôle les
opérandes A1,A2, B1, B2 vers les différentes unités fonctionnelles. Par exemple,
si optypeA est ADD et optypeB est XOR, l’encodeur va générer à sa sortie la
valeur « 100 ». Cette valeur va positionner A1 et A2 en entrée de l’additionneur
et B1 et B2 en entrée de l’unité logique (réalisant le XOR). Sur cet exemple, le
multiplieur n’est pas utilisé et ses opérandes peuvent donc être choisies arbitrairement.
Le dernier bloc sert à sélectionner les résultats : le premier étant le résultat de
l’instruction B, qui est obtenu à partir du M U X1 et transféré vers l’étage MEM ;
le deuxième étant le résultat de la réexécution de l’instruction A, obtenu à partir
du M U X2, et comparé avec celui de le première exécution stockée précédemment
pour la détection de fautes. Si ces résultats ne sont pas égaux, le signal error est
activé et le processeur va déclencher le mécanisme de recouvrement décrit dans
la section suivante.
4.3.4
Mécanisme de recouvrement
La détection se faisant juste après l’exécution d’une instruction à l’étage EXE
et l’erreur n’affectant ni les données du banc de registres ni ceux de la mémoire,
le recouvrement suite aux fautes induites dans l’UAL est plus simple que dans le
cas des fautes affectant le programme. En effet, notre stratégie de recouvrement
consiste simplement à recharger et réexécuter l’instruction dont l’opération est
corrompue lors de l’exécution dans l’UAL. Le processus du recouvrement est
illustré dans le Tableau 4.9. Prenons par exemple cinq instructions consécutives
{A, B, C, D, E}. et notons Vi la vérification de l’instruction i. Supposons que
l’opération de l’instruction B soit corrompue. Sa vérification VB au 5ème cycle va
donc produire un signal d’erreur.
Tableau 4.9 – Illustration du mécanisme de recouvrement de l’UAL
Cycle
1
2
3
4
FETCH
A
B
C
D
DECODE
5
E
D
6
B (rechargé)
A
B
C
EXE
A
B
VA
C
VB → Erreur
MEM
WRITE-BACK
A
B
A
Le recouvrement est effectué selon les étapes suivantes :
– Toutes les valeurs de registres d’état situées à partir de l’étage FETCH
jusqu’à l’étage MEMORY sont abandonnées et seront effacées lors du rechargement de l’instruction B.
94
Chapitre 4. Protection vis-à-vis des attaques en faute
– Les valeurs de registres d’état à l’étage WRITE-BACK qui résultent de
l’exécution de l’instruction A sont écrites dans le banc de registres.
– L’instruction B est rechargée en remettant le Compteur de Programme à
l’adresse de l’instruction B.
4.3.5
Ordonnancement statique
Dans le cadre de notre travail, nous avons choisi d’adapter les techniques
d’ordonnancement statiques existantes afin de minimiser le nombre d’instructions consécutives utilisant une même unité fonctionnelle et ceci afin d’exploiter
efficacement le facteur ML. Plusieurs algorithmes heuristiques ont été proposés pour faire cet ordonnancement. Ils peuvent être divisés en deux catégories :
ceux qui opèrent dans la limite des BBs (ordonnancement intra BB) et ceux qui
peuvent ordonner les instructions provenant de BBs différents (ordonnancement
inter BBs). Cette seconde catégorie est utilisée pour des processeurs dotés de mécanismes de spéculation permettant d’exécuter des instructions situées après une
instruction de branchement non résolue et de rétablir la validité du programme
si la spéculation sur le branchement s’avère incorrecte.
Comme notre processeur ne possède pas cette capacité, notre choix se porte
sur la première catégorie, en particulier un algorithme appelé « List Scheduling »,
souvent utilisé pour l’ordonnancement des instructions dans les BBs [100]. Cet
algorithme commence par générer pour chaque BB un tableau représentant les
dépendances entre les instructions, dépendances de différents types : « Lecture
après Écriture », « Écriture après Lecture » et « Écriture après Écriture » comme
décrits dans [57] et rappelés dans 3.1.2.1. Par ailleurs, deux instructions d’accès
mémoire sont considérées comme dépendantes si la première instruction est une
écriture, car il est impossible de savoir en phase de compilation si ces deux instructions n’utilisent pas la même l’adresse. Dans ce tableau, nous notons comme
prédécesseurs l’ensemble des instructions précédentes dont dépend l’instruction
courante ; Les successeurs désignent l’ensemble des instructions suivantes qui dépendent de l’instruction courante.
Ce tableau est utilisé comme entrée pour l’algorithme « List Scheduling » qui
implémente ensuite les étapes principales ci-dessous afin de produire un nouvel
ordre des instructions de chaque BB.
1. Initialiser EP = l’ensemble des instructions disponibles (celles qui sont
prêtes à être ordonnées) qui ne possèdent aucun prédécesseur.
2. Tant que EP n’est pas vide
(a) Choisir une instruction j dans EP selon les priorités suivantes :
i. Avoir une opération différente de celle de la dernière instruction
qui vient d’être ordonnée.
4.3. Protection de l’UAL
95
ii. Avoir une opération qui utilise une des UFs de l’UAL
iii. Avoir le plus grand nombre de successeurs
(b) Ordonner l’instruction j (si après sélection selon les priorités listées
ci-dessus, il reste plusieurs instructions possibles, on peut choisir au
hasard une de ces instructions. Dans notre implémentation, on prend
la première (dans l’ordre séquentiel du programme).
(c) Enlever l’instruction j dans EP ainsi que dans la liste des prédécesseurs correspondant à chaque instruction.
(d) Mettre à jour EP en ajoutant des instructions dont la liste des prédécesseurs est vide.
A noter que les priorités mentionnées ci-dessus ne sont dédiées qu’à notre application dont l’objectif est de produire autant que possible des instructions consécutives utilisant des UFs différentes. De plus, étant donné que le problème d’ordonnancement des instructions est en général un problème NP-Complet [101], le
résultat de l’implantation de notre algorithme ne pourrait pas être optimal. A
titre d’illustration, la figure 4.12 présente le graphe de dépendances d’un BB. Les
successeurs et prédécesseurs des instructions sont listés dans le Tableau 4.3.5. Le
0
1
2
3
4
5
6
7
8
9
10
11
12
Figure 4.12 – Graph de dépendance d’un BB
96
Chapitre 4. Protection vis-à-vis des attaques en faute
Index
0
1
2
3
4
5
6
7
8
9
10
11
12
Tableau 4.10 – Tableau de dépendance d’un BB
Instructions
Liste de Successeurs Liste de Prédécesseurs
ADDIU r29, r29, 0
2,3,4,5,6,7,8
LUI r2, 0
10
SW r21, 36(r29)
3,4,5,6,7,8,9
0
SW r20, 32(r29)
4,5,6,7,8,10
0,2
SW r19, 28(r29)
5,6,7,8,11
0,2,3
SW r18, 24(r29)
6,7,8,12
0,2,3,4
SW r31, 40(r29)
7,8
0,2,3,4,5
SW r17, 20(r29)
8
0,2,3,4,5,6
SW r16, 16(r29)
0,2,3,4,5,6,7
ADDU r21, r4, r0
2
ADDIU r20, r2, 0
1,3
ADDU r19, r0, r0
4
ADDU r18, r0, r0
5
processus d’ordonnancement de ce BB est réalisé en plusieurs itérations comme le
montre le Tableau 4.11. Dans cet exemple, le BB original possède quatre dernières
instructions qui utilisent l’UF de l’additionneur. En appliquant notre algorithme
pour réordonner ce BB, nous obtenons un nouveau BB comme montré dans la
Figure 4.13 qui ne contient aucune paire d’instructions consécutives utilisant la
même UF.
Tableau 4.11 – Processus d’ordonnancement
Itération
EP
Ordonnancement
Index
Instruction
0
0,1
0
ADDIU r29, r29, 0
1
1,2
2
SW r21 36(r29)
2
1,3,9
9
ADDU r21, r4, r0
3
1,3
3
SW r20, 32(r29)
4
1,4
4
SW r19, 28(r29)
5
1,5,11
11
ADDU r19, r0, r0
6
1,5
5
SW r18, 24(r29)
7
1,6,12
12
ADDU r18, r0, r0
8
1,6
6
SW r31, 40(r29)
9
1,7
1
LUI r2, 0
8
7,10
10
ADDIU r20, r2, 0
9
7
7
SW r17, 20(r29)
10
8
8
SW r16, 16(r29)
4.3. Protection de l’UAL
97
0
2
9
3
4
11
5
12
6
1
10
7
8
Figure 4.13 – Graphe de dépendances d’un BB après réordonnancement
4.3.6
Évaluation de l’UAL sécurisée
4.3.6.1
Surcoût matériel
La Table 4.12 reporte le surcoût matériel de l’UAL protégée comparé à l’UAL
originale. Le coût matériel de l’UAL protégée comprend les Multiplexeurs ajoutés, l’encodeur, le comparateur ainsi que les registres additionnels comme décrit
dans la section 4.3.2. On peut remarquer que le surcoût de l’UAL protégée est
très faible. Le nombre de LUTs et Flip-Flops utilisés occupent 2.94% et 3.2% de
98
Chapitre 4. Protection vis-à-vis des attaques en faute
Tableau 4.12 – Évaluation du surcoût matériel de l’UAL protégée
LUTs
Bascules La
période
d’horloge (ns)
Processeur avec UAL
6076
2366
25.563
originale
Processeur avec UAL
6255
2442
29.739
protégée
(+2.94%) (+3.2%) (+16.33%)
plus par rapport à l’UAL originale. De plus, l’impact sur le chemin critique de
cette UAL protégée est relativement faible (de 11.6 %) et peut être négligé.
4.3.6.2
Impact sur les performances
La Figure 4.14 présente le pourcentage des instructions exécutées utilisant
l’UF logique et arithmétique dans l’UAL par rapport à celles n’utilisant aucune
UF, par exemple, des instructions d’accès mémoire. Il est à noter que cette analyse est effectuée par le profilage des applications en temps réel et non pas à partir
du code statique. On peut observer que pour les applications expérimentales, plus
de 50% des instructions emploient l’UAL pour le calcul. Par conséquent, une implémentation triviale de duplication temporelle augmenterait de 50% le temps
de calcul.
No_FU_Instr
Adder FU
Logic FU
100%
0%
nt
ou
tc
Bi
ch
ar
cm
p
Ad
St
rin
e
gs
2
C3
CR
1
A-
SH
h
fis
ow
Bl
DE
S
S
AE
Figure 4.14 – Pourcentage des instructions exécutées utilisant l’UF logique et
arithmétique dans l’UAL
Pour évaluer l’efficacité de notre solution qui réduit le temps additionnel en
4.3. Protection de l’UAL
99
exploitant le facteur ML, nous définissons un index ∆ calculé de la manière
suivante :
tM L − tO
textraM L
=
∆=
textraAF
tAF − tO
avec :
– textraM L , tM L représentent respectivement le temps additionnel et le temps
total d’exécution quand le schéma de redondance temporelle est appliqué
avec l’exploitation du facteur ML.
– textraAF , tAF représentent respectivement le temps additionnel et le temps
total d’exécution quand le schéma de redondance temporelle est appliqué
sans exploiter aucun facteur. Cela signifie que lors de la réexécution, le
processeur doit prendre un cycle supplémentaire pour refaire l’opération
de l’UAL.
– t0 représente le temps total en cas d’exécution normale sans le schéma de
protection de l’UAL.
L’index ∆ sert à quantifier la réduction du temps additionnel obtenu en exploitant le facteur ML, comparativement à une solution qui ne l’exploiterait pas.
Plus cette valeur est faible, moins le temps additionnel est important. La Figure
4.15 présente les valeurs de l’index ∆ pour les applications expérimentales avec
et sans l’utilisation de l’ordonnancement statique. On voit que l’exploitation du
facteur ML permet de réduire le temps additionnel jusqu’à 30% en moyenne par
rapport au schéma n’exploitant aucun facteur. On observe aussi que l’application
de l’ordonnancement statique est intéressant en permettant une réduction à 20%
en moyenne.
50%
IH
Scheduling + IH
45%
40%
35%
Delta
30%
25%
20%
15%
10%
5%
0%
Bit
nt
u
co
cm
p
Ad
S
rch
ea
gs
trin
2
C3
CR
A-1
SH
wfi
Blo
sh
S
DE
S
AE
me
an
Figure 4.15 – Évaluation de l’index ∆ des applications expérimentales
100
4.3.6.3
Chapitre 4. Protection vis-à-vis des attaques en faute
Sécurité
Notre solution a été fonctionnellement validée à l’aide de l’émulateur de fautes
décrit dans la section 3.1.6. Le modèle de fautes utilisé couvre tout type de fautes
affectant les UFs de l’UAL, produisant une sortie erronée. Nous avons pu vérifier
que, parce que notre approche se base sur la redondance temporelle, elle n’est
pas capable de détecter les fautes permanentes comme mentionné précédemment
dans la section 4.3.1.
4.4
Conclusion
Dans ce chapitre, nous avons décrit trois protections aux attaques en faute :
un schéma de vérification d’intégrité sur les BBs, un mécanisme de recouvrement
associé à ce test d’intégrité, une l’UAL sécurisée basée sur la réexécution des
instructions utilisant les unités fonctionnelles libres. L’efficacité de ces techniques
a été démontrée et leur impact sur les performances estimé. Nous allons dans le
chapitre suivant présenter des protections aux attaques par effet de bord.
Chapitre 5
Protection vis-à-vis des attaques
par effet de bord
Sommaire
5.1
5.2
Ajout aléatoire d’instructions factices . . . . . . . . . . . 101
5.1.1
Motivations et contribution . . . . . . . . . . . . . . . . . 101
5.1.2
Principe d’insertion . . . . . . . . . . . . . . . . . . . . . 102
5.1.3
Architecture d’insertion d’instructions factices
5.1.4
Évaluation de l’efficacité de l’ajout des instructions factices 107
5.1.5
Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
. . . . . . 102
5.1.5.1
Simulation de la puissance consommée . . . . . . 107
5.1.5.2
Modèle d’attaque . . . . . . . . . . . . . . . . . 108
5.1.5.3
Choix des paramètres de la DPA . . . . . . . . . 109
5.1.5.4
Résultats DPA . . . . . . . . . . . . . . . . . . . 110
5.1.6
Surcoût matériel . . . . . . . . . . . . . . . . . . . . . . . 111
5.1.7
Impact sur les performances . . . . . . . . . . . . . . . . . 112
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Dans ce chapitre, une contre-mesure vis-à-vis des attaques par effet de bord
est proposée pour le processeur simple qui a été décrit dans la section 3.1.2. Cette
protection consiste à rajouter du bruit sur les mesures réalisées par l’attaquant.
Ce bruit est généré en insérant aléatoirement entre des instructions valides des
instructions elles-mêmes choisies aléatoirement. Le principe d’une telle insertion
est tout d’abord précisé. L’architecture matérielle qui met en œuvre ce principe
est ensuite décrite. Dans un troisième temps, une caractérisation de cette contremesure en terme de sécurité vis-à-vis des attaques DPA est détaillée. Enfin,
l’impact en termes de performance et de surcoût est discuté.
101
102
5.1
5.1.1
Chapitre 5. Protection vis-à-vis des attaques par effet de bord
Ajout aléatoire d’instructions factices
Motivations et contribution
Nous considérons que l’injection aléatoire d’instructions aléatoires proposée
par Ambrose et al. dans [82] présente un compromis sécurité versus performances
compatible avec les objectifs de cette thèse. Ces auteurs proposent d’insérer dans
le pipeline des instructions factices. Ces instructions effectuent des opérations
qui prennent comme opérandes le contenu de l’un des 32 registres Rn (avec n ∈
{1, 2, . . . , 31}) du processeur et le registre spécial R0 (qui stocke constamment la
valeur nulle) et qui écrivent le résultat dans Rn . Dans ce cadre, les instructions
factices se mettent donc sous la forme « op_f actice Rn Rn R0 » (avec n ∈
{1, 2, . . . , 31}). Pour que l’instruction ne modifie pas la valeur de Rn , seules les
opération de type ADD ou XOR sont envisagées. Cette méthode présente un
inconvénient majeur. Le registre Rn peut stocker une donnée sensible telle qu’une
clef de chiffrement. Lors de l’exécution de l’opération factice, cette donnée va
être transférée dans divers éléments du processeur (dont l’UAL). Ce transfert
crée potentiellement une fuite d’information par effet de bord.
La technique que nous décrivons dans ce chapitre pâlie cet inconvénient car les
opérations factices n’utilisent aucune donnée du programme principal. De plus,
la forme des instructions factices que nous proposons est plus générique. Elles se
mettent sous la forme « op_f actice Rn Rm Rl » avec m, n, l ∈ {1, 2, . . . , 31}).
Nous augmentons ainsi le niveau de « non déterminisme » du système.
5.1.2
Principe d’insertion
Notre approche consiste à ajouter dans le pipeline des instructions factices.
Comme dans la solution proposée dans [82], le taux d’insertion des instructions
factices sera réglé par deux paramètres notés D et N . D désigne le nombre d’instructions valides consécutives que l’on s’autorise à exécuter sans insertion de
fausses instructions ; N désigne le nombre maximum de fausses instructions insérées entre deux instructions valides. Pour que l’attaquant ait plus de mal à distinguer les instructions factices de celles qui sont utiles (car elles pourraient avoir
des profils de courant différents), les instructions factices seront choisies dans un
ensemble d’instructions aussi large que possible (noté Ensemble_Instructions_Factices). Les opérandes de ces opérations seront également choisies aléatoirement dans un ensemble donné (noté Ensemble_V aleurs_Operandes). La génération d’aléas sera réalisée à l’aide du générateur de nombres pseudo-aléatoires
décrit dans la section 3.1.5. Le pseudo-code 6 décrit le principe d’insertion.
Enfin, comme nous souhaitons que les opérations factices ne modifient en rien
les résultats des opérations valides et que les opérations factices ne créent pas de
5.1. Ajout aléatoire d’instructions factices
103
Algorithme 6 Algorithme aléatoire d’insertion d’instructions factices aléatoires
Entrées: P C /* Compteur de Programme*/
Entrées: N /* Nombre maximum d’opérations consécutives factices à insérer*/
Entrées: D /* Nombre maximum d’opérations utiles consécutives*/
Entrées: Ensemble_Instructions_F actices /* Ensemble des opérations factices insérables*/
Entrées: Ensemble_V aleurs_Operandes /* Ensemble des valeurs d’opérandes
utilisables*/
/* Insertions d’instructions utiles*/
nb_utiles = rand(1, D) /* Choix aléatoire d’un nombre entre 1 et D*/
pour i = 0 to nb_utiles faire
Exécution de l’instruction positionnée sur PC
PC = PC + 1;
fin pour
/* Insertions d’instructions factices*/
nb_f actices = rand(0, N ) /* Choix aléatoire d’un nombre entre 0 et N */
pour i = 0 to nb_f actices faire
Choisir aléatoirement dans Ensemble_Instructions_F actices une instruction Cmd
Choisir aléatoirement dans Ensemble_Opérandes une valeur pour l’opérande Arg
Exécuter Cmd avec l’opérande Arg
fin pour
fuite d’information supplémentaire, un banc de registres complet supplémentaire
leur a été attribué. Il est utilisé pour le stockage des opérandes et du résultat de
ces opérations factices. Ces considérations conduisent à l’architecture suivante.
5.1.3
Architecture d’insertion d’instructions factices
Dans la solution qui a été retenue, les instructions insérées aléatoirement sont
représentées sous forme de « op_f actice Rn Rm Rl » avec :
– op_f actice désignant toute instruction hors instruction de branchement et
de lecture/écriture mémoire.
– Rn désignant le registre de destination
– Rm , Rl désignant les deux registres de source
– m, n, l ∈ {1, 2, . . . , 31}
Pour rappel, il existe trois formats d’instruction dans le jeu d’instruction
MIPS : les instructions de type R, de type I et de type J (représentées sur la
Figure 5.1.3). Celles de type J correspondent à des branchements. Elles ne sont
104
Chapitre 5. Protection vis-à-vis des attaques par effet de bord
donc pas utilisées pour des instruction factices. Par contre, toutes celles de type R
ou I (sauf celles de lecture/écriture mémoire) devront être générées aléatoirement.
31
type−R
26 25
opcode
31
26 25
31
type−J
$rs
opcode
type−I
21 20
16 15
$rd
$rt
21 20
$rs
11 10
6 5
$sa
16 15
$rt
func
0
immédiat
26 25
opcode
0
0
adresse cible
opcode: code de l’opération
rs: adresse de registre de la première source d’opérande
rt: adresse de registre de la seconde source d’opérande
rd: adresse de la destination
sa: nombre de bits de décalage à effectuer
immédiat: valeur immédiate
func: function de l’instruction
Figure 5.1 – Type d’instructions MIPS-I
Pour mettre en œuvre le principe d’insertion d’instructions aléatoires, un
matériel appelé « Ajout des instructions factices » (AIF) a été implémenté comme
présenté dans la Figure 5.2. L’AIF comprend une mémoire ROM où sont stockés
30 triplés de 13 bits qui décrivent partiellement l’instruction qui va être insérée :
6 bits désignent le champ opcode de cette instruction et 6 autres bits son champ
f unc. Un dernier bit désigne le type type de l’instruction qui va être insérée (R
ou I). Ce choix est réalisé via un multiplexeur intégré à l’AIF.
L’entrée de AIF est une valeur aléatoire A de 32 bits, produite à partir du
PRNG. Cette valeur est utilisée pour générer l’instruction factice (de type I ou R)
comme suit : Un ensemble de triplets correspondant à l’ensemble des instructions
MIPS-1 excepté celles de branchement, de lecture/écriture mémoire sont stockés
dans un mémoire ROM. Dans ce cas, nous comptons jusqu’à 30 triplets sur les
possibilités du jeu d’instructions MIPS-1. Nous utilisons donc 5 bits, extrait à
partir des bits 31 à 27 de la valeur A, qui sert à adresser un des triplets stockés
dans la ROM.
– les bits 31 à 27 de A sélectionnent dans la ROM l’un des triplet opcode,
f unc et type
– les bits 25 à 21 de A constituent le champ rs
– les bits 20 à 16 de A constituent le champ rt
– les bits 15 à 11 de A constituent le champ rd
5.1. Ajout aléatoire d’instructions factices
PRNG
bits 25 downto 21
rs
bits 20 downto 16
rt
bits 15 downto 11
rd
bits 10 downto 6
sa
bits 15 downto 0
immediat
32 bits
105
ROM
bits 31 downto 27
opcode1, func1, type1
opcode2, func2, type2
opcode3, func3, type3
opcode
func
type
type−R
type−I
opcode
opcode
rs
rs
rt
rt
rd
rs
func
MUX
opcodeN, funcN, typeN
Instruction factice
immédiat
Figure 5.2 – Architecture du matériel d’insertion d’instructions aléatoires
– les bits 10 à 6 de A constituent le champ sa
– les bits 15 à 0 de A constituent le champ immédiat
La Figure 5.3 présente l’intégration du matériel AIF dans le pipeline du processeur. Deux instructions spécifiques SET _F LAG et RESET _F LAG sont
ajoutées au jeu d’instruction pour contrôler les paramètres N and D. L’étage de
décodage est modifié pour être en mesure d’interpréter ces deux nouvelles instructions. Lors de l’exécution de celles-ci, l’étage de décodage va activer ou désactiver
l’ajout des instructions factices via deux signaux init ou arrêt et transférer les
deux paramètres N et D vers l’AIF. En fonction de la valeur de ces paramètres,
l’AIF injecte des instructions factices et pilote le signal enable_f actice qui va
être transféré au sein du pipeline pour choisir la lecture de données Src_Reg1 et
Src_Reg2 à partir du banc de registres principal ou factice, ainsi que l’écriture
de données vers ces deux bancs. A noter que lors de la circulation dans les étages
106
Chapitre 5. Protection vis-à-vis des attaques par effet de bord
de pipeline, une instruction factice est accompagnée par le signal enable_f actice.
La propagation de ce signal est prise en compte par l’étage de renvoi qui contrôle
la dépendance des données entre les instructions. Ainsi, les dépendances entre
une instruction factice qui se trouve dans un étage et une instruction factice ou
normale qui se trouve dans un autre étage, ne sont pas prises en considération.
Mémoire
PRNG
Banc de
registres registres
principal
AIF
Cache
instruction_factice
Instruction
MUX
MUX
MUX
enable_factice
enable_factice
instruction_normale
factice
Donnée à écrire
Banc de
enable_écriture
init arrêt N D
enable_écriture
d’instructions
MUX
’0’
MUX
’0’
enable_factice
Pipeline
FETCH
DECODE
EXECUTE
MEM
WB
RENVOI
init arrêt N D
Figure 5.3 – Intégration du matériel des instructions factices dans le pipeline du
processeur
5.1. Ajout aléatoire d’instructions factices
5.1.4
107
Évaluation de l’efficacité de l’ajout des instructions
factices
Pour évaluer l’efficacité de l’ajout d’instructions factices, des attaques de type
DPA sont réalisées sur des données synthétiques (c’est-à-dire issues de simulation
et non de mesures réelles). Ces données synthétiques sont générées à partir de
simulations de l’exécution d’un AES et de modèles de consommation classiquement adoptés dans le domaine. Ces modèles sont rappelés ci-après.
5.1.5
Sécurité
5.1.5.1
Simulation de la puissance consommée
Simulation de la puissance consommée par une équipotentielle Des
modèles, appelés « distance » et « poids » de Hamming, sont classiquement utilisés pour estimer la consommation du circuit à partir de simulations logiques. Ces
modèles ne considèrent que la consommation générée par les variations en sortie
des portes logiques. Ces modèles s’affranchissant de la réalisation physique des
portes logiques, on ne parle alors plus de consommation des portes logiques mais
de consommation des équipotentielles (ou nœud) qui relient ces mêmes portes.
Dans le modèle « distance de Hamming », la consommation de courant est
supposée être égale au nombre de transitions des équipotentielles du circuit. Il
s’agit, avec les notations introduites dans la section 1.3.1.1, de considérer que
Icc ' Icl + Icc ' 1 (c’est-à-dire que Icl ' 0 ) et que IstatP = IstatN ' 0.
Dans le modèle « poids de Hamming », la consommation de courant est supposée être égale au nombre d’états hauts des équipotentielles du circuit. Ce modèle, qui ne prend pas en compte l’état précédent, mais seulement l’état courant
du nœud considéré ne se justifie physiquement que dans des cas très particuliers.
Les modèles poids et distance de Hamming ainsi que les modèles dérivés
beaucoup moins utilisés qui décomptent les transitions montantes « HDZO »
(pour « Hamming Distance Zero to One ») ou descendantes « HDOZ » (pour
« Hamming Distance One to Zero »), sont reportés dans le Tableau 5.1.
Transitions
0
0
1
1
→
→
→
→
0
1
0
1
Courant consommé
(discussion 1.3.1.1)
inverseur
IstatN
Icc + Icl
Icc
IstatP
Distance de
Hamming
HD
0
1
1
0
Poids de Hamming
HW
0
1
0
1
Transition
montante
HDZO
0
1
0
0
Transition
descendante
HDOZ
0
0
1
0
Tableau 5.1 – Modèles « distance », « poids » de Hamming, transitions montantes
et descendantes pour une équipotentielle
108
Chapitre 5. Protection vis-à-vis des attaques par effet de bord
Simulation de la puissance consommée par un circuit Par la suite, nous
choisissons le modèle « distance de Hamming » comme modèle de consommation
et considérons que la consommation d’un circuit est la somme de la consommation de chacune de ses équipotentielles. Pour obtenir cette consommation,
la simulation logique du fonctionnement du processeur lorsqu’il réalise le chiffrement AES d’un texte avec une clef (inconnue) est dans un premier temps réalisée.
L’injection d’instructions aléatoires est déclenchée lors de l’exécution de l’AES à
l’aide des deux instructions spécifiques SET _F LAT (qui initialise ici D = 4 et
N = 8) and RESET _F LAT comme suit :
__asm__(".word 0xc8408000"); // SET_FLAT
KeyExpansion(key, w);
N=8 D=4
w_tab(0, w, roundkey);
AddRoundKey(data, roundkey, state);
for ( i=1; i<10; i++)
{
SubBytes(state);
__asm__(".word 0xe8000000"); // RESET_FLAT
ShiftRows(state);
MixColumns(state);
w_tab(i, w, roundkey);
AddRoundKey(state, roundkey, state);
}
SubBytes(state);
Le simulateur logique est paramétré de telle sorte que les variations de toutes les
équipotentielles du circuit à chaque pas de simulation soient enregistrées dans
un fichier d’extension .VCD (pour « Value Changed Dump »). Au terme de la
simulation, un logiciel extrait du .VCD, pour tous les pas de temps, le nombre de
variations des équipotentielles. Une « courbe » constituée de l’ensemble de points
(pas de simulation ; nombre de transitions) représentative de la consommation
est obtenue.
5.1.5.2
Modèle d’attaque
Depuis sa publication, l’attaque DPA qui a été présentée à la section 1.3.3.3
a fait l’objet de nombreuses adaptations. Celles-ci ont essentiellement concerné
les modèles prédisant la consommation du circuit et les opérateurs statistiques
mesurant la corrélation entre les prédictions et les mesures. Le modèle de puissance proposé initialement était basé sur la valeur d’un seul bit. Des modèles
5.1. Ajout aléatoire d’instructions factices
109
de puissance plus complexes (tels que les modèles « HW » et « HD » décrits
au paragraphe 5.1.5.1) ont ensuite pris en considération plusieurs bits (on parle
d’attaque DPA « multi-bits »). L’attaque a alors gagné en efficacité (la clef peut
être extraite avec moins de courbes), mais a perdu en robustesse (le modèle étant
plus précis, il est vrai pour moins de circuits). Parmi les différents opérateurs de
« corrélation » proposés, outre la différence de moyenne initialement décrite par
Kocher (et décrite au 1.3.3.3), on peut citer le coefficient de Pearson [102] (on
parle alors de CPA pour Correlation Power Analysis), mais aussi l’information
mutuelle [103] (on parle de MIA pour Mutual Information Analysis).
5.1.5.3
Choix des paramètres de la DPA
Les différents paramètres choisis pour réaliser la DPA telle qu’elle a été décrite
dans 1.3.3.3 sont les suivants :
– Calcul intermédiaire a : la sortie de la première S-Box (r = 0) de la première
ronde est choisie comme valeur intermédiaire. On a donc a = f (K0 , M ) avec
f une fonction qui peut aisément être déduite du standard (combinaison
de ADDROUNDKEY et de SUBBYTE).
– Messages clairs M : nous considérons que l’attaquant est susceptible de
pouvoir choisir les textes clairs. L’ensemble des textes choisis pour attaquer
la S-Box r est l’ensemble des textes qui parcourent ses entrées, les autres
bits restant constants (choisis tous identiques et arbitrairement nuls). Dans
ces conditions, on a |M | = 256.
– Clef K : nous considérons que les corrélations entre les signaux mesurés par
l’attaquant et les prédictions de ce dernier sont indépendantes de la clef.
En effet, il est communément admis que celles-ci fonctionnent indépendamment de la clef utilisée, même si parfois les résultats obtenus peuvent
légèrement différer. Nous choisissons arbitrairement K égale à 2B 7E 15
16 28 AE D2 A6 AB F7 15 88 09 CF 4F 3C.
– Modèle de consommation S : nous supposons que l’attaquant ne prédit que
les poids de Hamming de la sortie de la S-Box (la prédiction de la distance
nécessitant la connaissance de ces derniers à deux instants distincts) et
qu’il choisit un modèle de consommation très robuste, à savoir, la valeur
d’un des bit en sortie de cette S-Box.
– Opérateur de corrélation : dans le cas particulier où un signal unique est
corrélé à une valeur binaire, les trois opérateurs de corrélation (différence
des moyennes, MIA et Pearson) donnent des résultats très proches [104].
Nous n’en retiendrons donc qu’un : la différence des moyennes, telle qu’elle
a été définie dans le paragraphe 1.3.3.3.
110
Chapitre 5. Protection vis-à-vis des attaques par effet de bord
5.1.5.4
Résultats DPA
Pour valider l’efficacité du matériel d’ajout des instructions factices, nous
avons réalisé l’attaque par analyse de corrélation avec le modèle de distance de
Hamming sur l’algorithme de cryptographie AES exécuté par le processeur, sans
ajout d’instructions factices puis avec ajout d’instructions factices. Les différences
de moyennes obtenues pour les différentes valeurs d’hypothèses de clefs et avec
comme modèle de consommation la valeur du premier bit en sortie de la première
S-Box, sont reportées ci-après. On constate que lorsque la contre-mesure n’est pas
activée (Figure 5.4), l’une des « courbes » (de couleur jaune) ressort nettement
des autres. Cette courbe est associée à l’hypothèse de clef 43D = 2BH qui est
effectivement celle utilisée pour faire le calcul. Par exemple, on peut voir nettement dans la Figure 5.5 la valeur de corrélation maximale apparaît sur la courbe
associée à la bonne clef 2BH (au pas de temps 15264). L’attaque DPA fonctionne
donc correctement. On constate que lorsque la contre-mesure est activée (Figure
5.6), aucune des « courbes » (et en particulier pas celle qui correspond à la bonne
clef partielle) ne ressort. L’attaque ne fonctionne donc pas. A noter que, dans les
deux cas, les attaques qui ont été réalisées avec comme modèle de consommation,
l’un des 7 autres bits de la sortie de la première S-Box, donnent des résultats
similaires.
Figure 5.4 – Résultat de l’attaque par analyse de consommation sur le processeur
non-protégé
5.1. Ajout aléatoire d’instructions factices
111
Figure 5.5 – Extraction du pic DPA associé à la bonne clé
Figure 5.6 – Résultat de l’attaque par analyse de consommation sur le processeur
protégé
5.1.6
Surcoût matériel
Le tableau 5.2 présente le surcoût matériel lors de l’implantation du matériel
AIF dans le processeur. On voit que le nombre de LUTS utilisés dans notre
solution sont raisonnables (18.49%). Il en est de même pour l’impact sur la
période d’horloge (25.36%). Le nombre des bascules sont relativement importants
(53.16%) car notre schéma a utilisé la duplication du banc de registre.
112
Chapitre 5. Protection vis-à-vis des attaques par effet de bord
Tableau 5.2 – Évaluation du surcoût matériel de l’AIF
La période
LUTs
Bascules
d’horloge (ns)
Processeur original
4568
2366
5.601
Processeur + AIF
5413
3624
7.039
(+18.49%)
(+53.16%)
(+25.36%)
5.1.7
Impact sur les performances
L’impact sur les performances dépend des paramètres D et N . Pour estimer
ces performances, nous faisons l’hypothèse que chaque instruction, qu’elle soit
aléatoire ou non, s’exécute en un même nombre de cycles (choisi arbitrairement
à 1). Pour D = 2 et N = 3, 8 cas peuvent se produire :
– 1 instruction valide suivie de 0, 1, 2 ou 3 instructions factices. Pour exécuter
cette instruction valide et cette séquence d’instruction factices, il faudra
N
P
(i+1)
alors en moyenne (N +1) = 10
= 2, 5 cycles.
4
– 2 instructions valides suivies de 0, 1 , 2 ou 3 instructions factices. Pour exécuter ces deux instructions valides et cette séquence d’instruction factices,
i=0
N
P
il faudra alors en moyenne
N
P
(i+2)
i=0
(N +1)
=
14
4
= 3, 5 cycles.
N
(i+1)+
i=0
P
(i+2)
i=0
= 24/8 = 3 cycles sont donc nécessaires pour réaliser 1,5 instructions valides. La perte en performance est donc dans ce cas particulier de
200%.
Plus généralement pour D et N , D∗(N +1) cas peuvent se produire : 1, 2,. . . ,D
instructions valides suivies de 0,1,. . . ,N instructions factices. Il faudra donc en
2∗(N +1)
D P
N
P
(
moyenne
D
P
(i+j))
j=0 i=0
D∗(N +1)
cycles pour réaliser
(j)
j=0
D
instructions valides. L’insertion
D P
N
P
(
d’instructions aléatoires dégrade donc les performances d’un facteur
(i+j))
j=0 i=0
(N +1)∗
D
P
.
(j)
j=0
Le Tableau 5.3 reporte cette perte calculée pour différentes valeurs de D et de
N.
On constate en particulier que pour D = 4 et N = 8 (paramètres choisis
pour nos tests de résistance à la DPA), le nombre de cycles nécessaires pour
réaliser l’ensemble des instructions valides est multiplié par un facteur 2,6. Si
l’on ajoute les 25% dus à la diminution de la fréquence d’horloge, la performance
est diminuée d’un facteur 4,5.
5.2. Conclusion
D
D
D
D
D
D
D
=1
=2
=3
=4
=5
=6
=7
N =0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
N =1
1,5
1,3
1,3
1,2
1,2
1,1
1,1
113
N =2
2,0
1,7
1,5
1,4
1,3
1,3
1,3
N =3
2,5
2,0
1,8
1,6
1,5
1,4
1,4
N =4
3,0
2,3
2,0
1,8
1,7
1,6
1,5
N =5
3,5
2,7
2,3
2,0
1,8
1,7
1,6
N =6
4,0
3,0
2,5
2,2
2,0
1,9
1,8
N =7
3,5
2,6
2,2
1,9
1,8
1,6
1,5
N =8
5,0
3,7
3,0
2,6
2,3
2,1
2,0
Tableau 5.3 – Impact sur la performance des ajouts aléatoires d’instructions
aléatoires
5.2
Conclusion
Dans ce chapitre, nous avons décrit une protection aux attaques par effet de
bord : il s’agit d’insérer aléatoirement des instructions aléatoires. Notre protection, par rapport à l’état de l’art, réduit les fuites d’information et augmente le
niveau de non déterminisme. L’efficacité de cette technique a été démontrée sur
des données synthétiques (c’est-à-dire issues de simulation). Nous avons également montré que le surcoût en matériel est de 18.49% (LUTs) et 53.16% (Bascules). Les performances obtenues dépendent de paramètres de l’injection : plus
le taux d’injection sera élevé (et donc le niveau de non déterminisme), plus les
performances seront dégradées. Typiquement, lorsque l’on insère 8 instructions
factices maximum entre 4 instructions valides maximum, la performance est réduite d’un facteur 4,5.
Chapitre 6
Conclusion
Les composants de sécurité, parce qu’ils contiennent des informations confidentielles, font l’objet d’attaques. Celles-ci tentent généralement de porter atteinte à la confidentialité, à l’intégrité ou à l’authenticité des données protégées
par les algorithmes de cryptographie embarqués sur ces composants. Les attaques
dites matérielles ou physiques exploitent les faiblesses de l’implantation matérielle de ces algorithmes.
Dans le premier chapitre de cette thèse, une revue des différentes attaques sur
les composants qui protègent des informations confidentielles telles que des clefs
de cryptographiques a été réalisée. Parmi ces attaques, celles dites par « canaux
cachés » (« Side Channel Attacks » ou par effet de bord), sont particulièrement
efficaces : elles exploitent la corrélation qui existe entre les données manipulées
(dont celles qui sont sensibles) et la consommation, le rayonnement électromagnétique ou le temps de réponse du composant. Un autre type d’attaques, dites
par « injection de fautes » consiste à modifier volontairement le fonctionnement
du circuit pour contourner les protections logicielles et matérielles destinées aux
informations sensibles. Le fonctionnement du composant peut être altéré, par
exemple, par illumination laser, par modification de la tension d’alimentation ou
de la fréquence d’horloge. Un troisième type d’attaques, plus difficile à mettre en
oeuvre, consiste à analyser la conception de la puce à l’aide de procédés invasifs
(abrasion, gravure chimique, laser, SEM, etc.) puis à sonder les signaux (grâce
notamment à des faisceaux d’ions focalisés) sur lesquels transitent les informations secrètes. Cet état de l’art de la menace nous a conduit à ne considérer par la
suite que les attaques en fautes et par effet de bord qui sont, pour nous, les plus
dangereuses car relativement faciles à mettre en œuvre sur circuit non protégé.
Les protections qui ont été proposées ces dernières années pour contrer les
attaques par faute ont été analysées dans le second chapitre. Deux types de protections sont principalement mis en œuvre. Le premier consiste à détecter les
tentatives d’injection de faute puis à appliquer une stratégie de réaction adéquate en cas d’attaque. A cet effet, des capteurs qui détectent les modifications
anormales de l’environnement du circuit et des mécanismes de détection d’erreurs
(basées sur des calculs redondants ou sur des calculs prédictifs) ont été implémentés. Les réactions communément proposées vont de la simple coupure des
communications à l’effacement complet des informations stockées en mémoire.
Le deuxième type de protection vise à augmenter la robustesse du circuits aux
115
116
Chapitre 6. Conclusion
différentes techniques d’injection de faute. A cet effet, des méthodes de correction
d’erreurs (elles-aussi basées sur de la redondance) et des dispositifs technologiques
tels que capôts métalliques, filtres, etc. ont été proposés. Les contre-mesures proposées pour contrer les attaques par canaux cachés ont également été analysées
dans le second chapitre. Il s’agit soit d’ajouter du bruit sur les canaux soit de
réduire le signal informatif. L’ajout de ce bruit a pu être réalisé matériellement
(générateur de signaux aléatoires branché sur l’alimentation, par exemple) mais
des solutions logicielles ont également été développées (basées sur du masquage,
de l’insertion de code « inutile » dans le source ou des modifications aléatoires
de l’ordre d’exécution des opérations). Des contre-mesures ont également visé
à réduire les corrélations entre les données et les signaux émis par le composant (utilisation d’un codage des données adapté et équilibrage des chemins sur
lesquels transitent ces données). Des propositions en terme de filtrage de l’alimentation ont également fait l’objet de publications. Le second chapitre a montré
que ces contre-mesures présentent un coût généralement important en termes
de matériel ou de performances et qu’elles ont été principalement développées
pour des algorithmes de cryptographie. L’originalité du travail de cette thèse est
de proposer des contre-mesures dédiées à un processeur généraliste avec comme
double objectif :
– de réduire au maximum les coûts associés.
– de sécuriser ce processeur conjointement vis-à-vis des attaques en faute et
par effet de bord.
Le troisième chapitre décrit le vecteur de test qui a été choisi pour réaliser
nos expérimentations. Il s’agit d’un système sur puce représentatif d’un système
embarqué sur une carte à puce. Il est constitué d’un processeur 32 bits de type
DLX à 5 étages de pipeline, d’algorithmes de cryptographie à clef privée (AES
et/ou DES), de mémoires (cache d’instruction, RAM et ROM), de blocs d’entrées/sorties (ISO 7816 et RS232), d’un générateur de nombre pseudo-aléatoire,
etc. Le troisième chapitre décrit également l’environnement de conception matériel et logiciel qui a été développé dans le cadre de cette thèse. Un mécanisme
d’émulation de l’effet de fautes sur un composant a en particulier été détaillé.
Le quatrième chapitre a décrit trois contre-mesures aux attaques en faute
et une aux attaques par canaux cachés qui ont été implantées dans le cadre de
la thèse. La première protection vise à vérifier l’intégrité des instructions entre
la mémoire et l’étage de décodage. A cet effet à chaque bloc de base (ie. séquence d’instructions délimitées par un saut ou une destination de saut) a été
ajoutée une signature CRC permettant de détecter une modification d’une ou
plusieurs instructions de ce bloc. La stratégie de détection choisie, dite « à la
volée », a consisté à récupérer les instructions normalement, c’est-à-dire une à
une, à mettre à jour récursivement le CRC à chacune de ces récupérations puis
à exécuter les instructions normalement (c’est-à-dire toujours une à une). La dé-
117
tection de l’erreur a seulement lieu en fin d’exécution du bloc de base. Ce choix
induit un temps de latence de détection de la faute qui est proportionnel à la
taille des blocs mais n’a pas d’impact sur les performances du processeur. Un mécanisme de récupération en cas de détection d’erreur a également été implanté.
Ce mécanisme permet de réexécuter un bloc de base corrompu en restaurant les
données telles qu’elles étaient avant l’exécution du bloc. Pour assurer une réexécution correcte, les données restaurées sont celles stockées soit dans les registres,
soit dans la mémoire principale. Le stockage des données des registres est réalisé
dans un miroir du banc de registre. Le stockage des données dans la mémoire
est réalisé dans une zone tampon. Pour réduire l’impact de cette sauvegarde en
terme de surface, n’y sont stockées que les données nécessaires au recouvrement,
à savoir celles qui sont modifiées après avoir été lues. Nous avons également fait
en sorte que, contrairement à l’état de l’art, la restauration des données se fasse
également à la volée pour ne pas favoriser l’une des classes d’attaques en faute
dite en « safe-error ». La troisième contre-mesure aux attaques en faute consiste
à vérifier, quasiment en temps masqué, les calculs réalisés par l’unité arithmétique et logique (UAL). Ces différentes méthodes ont été évaluées en termes de
performance, de surface et de sécurité. Nous montrons que le mécanisme de détection et de recouvrement a un faible impact sur les performances et un coût
acceptable de 18.8% (pour les LUTs) et de 68.6% (pour les bascules). Quant à
celui de détection d’erreur dans l’UAL : le surcoût matériel est de 2.94% (pour
les LUTS) et de 3.2% (pour les bascules). La réduction du temps additionnel est
de 70%.
Dans le cinquième chapitre a été décrite une contre-mesure aux attaques par
canaux cachés. Il s’agit d’insérer aléatoirement dans le pipeline du processeur des
instructions aléatoires. Ce taux d’insertion peut être modifié par le développeur
suivant le type de données manipulées par le programme. A noter également que
pour que l’attaquant ait le plus de mal possible à distinguer les instructions factices de celles qui sont utiles (car elles auront des profils de courant différents),
les instructions factices ont été choisies dans un ensemble aussi large que possible d’instructions. Les opérandes de ces opérations ont également été choisies
aléatoirement. Afin de ne pas créer de fuite d’information, le banc de registres
a été dupliqué pour assurer le stockage des opérandes et du résultat des opérations factices. La génération d’aléas a été réalisée à l’aide d’un générateur de
nombres pseudo-aléatoires basé sur un Linear Shift Register (LSFR). La sécurité
de cette contre-mesure a été validée sur des données synthétiques. Son coût est
de 18.49% (pour les LUTs) et de 53.16% (pour les bascules). La perte en terme
de performance dépend du taux d’insertion d’instructions factices mais est, dans
nos expérimentations, de l’ordre d’un facteur 4.
Il est important de noter que les contre-mesures qui insèrent des instructions factices et qui détectent des erreurs dans l’UAL ont été utilisées dans le
118
Chapitre 6. Conclusion
projet ANR « Smart On Smart »(SOS) moyennant quelques modifications mineures. Celles-ci ont seulement consisté à ajouter une interface permettant de
régler dynamiquement le taux d’insertion d’instructions factices et d’activer ou
de désactiver la détection d’erreur. Ces « réglages » sont réalisés dans le cadre de
SOS par un processeur qui est dédié à l’application de stratégies de sécurité évoluées. Nous pensons que cette approche constitue l’une des perspectives de nos
travaux de thèse. En effet nous pensons qu’elle permet au composant de choisir
en autonomie et de façon optimale les paramètres des actionneurs et les réactions
en fonction du contexte environnemental (déterminé par les valeurs des capteurs)
et applicatif (déterminé par la sensibilité des informations manipulées). Grâce à
ce mécanisme complexe de décision, les performances du circuit (en termes de
vitesse et de consommation) et sa disponibilité devraient être améliorées sans
remettre en cause bien sûr sa sécurité.
D’autres perspectives sont également envisagées. Il s’agirait, dans un premier
temps de réaliser des attaques, par exemple avec les différents bancs d’attaque
disponibles dans notre laboratoire, sur le FPGA. Ces attaques devraient valider concrètement les résultats que nous avons obtenus en simulation. En ce qui
concerne les attaques par effet de bord, il pourrait être également intéressant
d’utiliser des métriques de sécurité plus évoluées que celles que nous avons proposées, en prenant par exemple les métriques décrites dans [82, 105, 106, 107].
Dans un second temps, pour être encore plus représentatif d’un circuit commercial, il pourrait être intéressant de réaliser un circuit ASIC puis de tester de
nouveau la résistance de nos contre-mesures sur des bancs d’attaques réels.
Référence de Jeux d’instructions
MIPS
Catégorie
Arithmétique
Instruction
ADD rd, rs, rt
SUB rd, rs,rt
ADDI rt, rs, imm
ADDU rd, rs, rt
SUBU rd, rs, rt
ADDIU rd, rs, imm
AND rd, rs, rt
Logique
OR rd, rs, rt
ANDI rd, rs, imm
ORI rt, rs, imm
SLL rd, rs, shamt
SRL rd, rs, shamt
LW rt, imm(rs)
Transfert des données
SW rt, imm(rs)
Signification
rd = rs+rt
Commentaires
Addition de deux registres et place
la somme dans un registre
rd = rs - rt
Soustraction de deux registres et la
différence est placée dans un registre
rt = rs + imm
Addition de la valeur d’un registre
avec une valeur constante et place
la somme dans un registre
rd = rs + rt
Addition non-signée de deux registres et la somme est placée dans
un registre
rd = rs - rt
Soustraction non-signée de deux registres et la différence est placée
dans un registre
rt = rs + imm
Addition non-signée de la valeur d’un registre et une valeur
constante. La somme est placée dans
un registre
rd = rt & rs
ET logique, bit par bit, entre deux
registres. Le résultat est placé dans
un registre
rd = rs | rt
OU logique, bit par bit, entre deux
registres. Le résultat est placé dans
un registre
rd = rs & imm
ET logique, bit par bit, entre un registre et une constante. Le résultat
est placé dans un registre
rd = rs | imm
OU logique, bit par bit, entre un registre et une constante. Le résultat
est placé dans un registre
rd = rs shamt Décalage des bits vers la gauche. Un
décalage d’un bit vers la gauche correspond à une multiplicateur à 2
rd = rs shamt Décalage des bits vers la droite. Un
décalege d’un bit vers la droite correspond à une division à 2
rt
=
Mé- Charge 4 octets de l’adresse mémoire[rs+imm]
moire rs + imm dans un registre
Mémoire[rs+imm] Sauvegarde quatre octets d’un re= rt
gistre à l’adresse mémoire rs + imm
119
120
Annexe . Référence de Jeux d’instructions MIPS
LUI rt, imm
rt = imm * 216
SLT rd, rs, rt
if (rs<rt) rd =
1 ; else rd = 0
SLTI rt, rs, imm
if (rs<imm) rt =
1 ; else rt = 0
SLTU rd, rs, rt
if (rs<rt) rd =
1, else rd =
0 (nombre nonsigné)
if (rs<imm) rt
= 1 ; else rt =
0 (nombre nonsigné)
if (rs==rt) PC
= PC + imm
Comparaison
STLIU rt, rs, imm
Branch conditionnel
BEQ rs, rt, imm
BNE rs, rt, imm
j adresse
if (rs !=rt) PC =
PC + imm
PC = adresse
Branch inconditionnel
jr rs
jal destination
PC = rs
r31 = PC + 4 ;
PC = destination
Charge une valeur constante dans
les deux octets les plus significatifs
d’un registre
Affecte un registre indiquant le résultat de la comparaison de deux registres
Affecte un registre indiquant le résultat de la comparaison d’un registre et d’une constante
Affecte un registre indiquant le résultat de la comparaison non-signée
de deux registres
Affecte un registre indiquant le résultat de la comparaison non-signée
d’un registre et d’une constante
On effectue un branchement à l’étiquette donné si les deux registres
sont égaux
On effectue un branchement à l’étiquette donné si les deux registres
sont différents
Saute à une adresse dans le programme
Saute à une adresse stockée dans un
registre
Saute à une fonction et Stocke
l’adresse dans le registre numéro 31
pour revenir où l’on était
Exemples de fonctionnement
système de sauvegarde et de
recouvrement
Dans cette partie, nous illustrons les états de la mémoire et le TMA en considérant le code d’un bloc de base structuré selon les séquences d’instructions de
lecture et d’écriture suivantes :
– (R) : une séquence d’instructions de lecture (Tableau 2)
– (W) : une séquence d’instructions d’écriture (Tableau 3)
– (R)(W) : une séquence d’instructions de lecture suivie d’une séquence
d’écriture (Tableau 4)
– (W)(R) : une séquence d’instructions d’écriture suivie d’une séquence de
lecture (Tableau 5)
– (R)(W)(R) : une séquence d’instructions d’écriture suivie d’une séquence
de lecture suivie d’une séquence de lecture (Tableau 6)
– (W)(R)(W) : une séquence d’instructions d’écriture suivie d’une séquence
de lecture suivie d’une séquence d’écriture (Tableau 7)
On rappelle ici les notations qui ont été introduites dans le paragraphe
4.2.3.3 :
– Inst désigne les instructions de lecture/écriture suivantes
– (w, vj ) instruction d’écriture de la valeur vj à l’adresse A0
– (r) instruction de lecture à l’adresse A0
– ([ES], [ER], [V S]) désigne le triplet (TMA[L0 ][Etat_Sauvegarde], TMA[L0 ][Etat_Restauration], TMA[L0 ][V aleur_Sauvegarde]), avec L0 la ligne
du TMA où l’adresse A0 est stockée. φ correspond à l’état où la ligne L0
n’a pas été créée pour l’adresse A0 dans le TMA.
– [A0 ] désigne la valeur stockée en mémoire à l’adresse A0 . Cette valeur est
égale initialement à v0 .
– Rsig désigne le signal indiquant que la donnée doit être restaurée.
121
Annexe . Exemples de fonctionnement système de sauvegarde et de
122
recouvrement
Tableau 2 – Séquence (r)
(b) Restauration (r)
(a) Sauvegarde (r)
Étape
0
1
...
j
Inst
φ
(r)
...
(r)
([ES], [ER], [V S])
φ
(0, 0, N U LL)
...
(0, 0, N U LL)
[A0 ]
v0
v0
...
v0
Étape
0
1
...
j
Inst
φ
(r)
...
(r)
([ES], [ER], [V S])
(0, 0, N U LL)
(0, 0, N U LL)
...
(0, 0, N U LL)
[A0 ]
v0
v0
...
v0
Rsig
0
0
...
0
Tableau 3 – Séquence (w)
(a) Sauvegarde (w)
Étape
0
1
...
j
Inst
φ
(w, v1 )
...
(w, vj )
([ES], [ER], [V S])
φ
φ
...
φ
(b) Restauration (w)
[A0 ]
v0
v1
...
vj
Étape
0
1
...
j
Inst
φ
(w, v1 )
...
(w, vj )
([ES], [ER], [V S])
φ
φ
...
φ
[A0 ]
v0
v1
...
vj
Rsig
0
0
...
0
Tableau 4 – Séquence (r)(w)
(a) Sauvegarde (r)(w)
Étape
0
1
...
j
j+1
...
k
Inst
φ
(r)
...
(r)
(w, vj+1 )
...
(w, vk )
([ES], [ER], [V S])
φ
(0, 0, N U LL)
...
(0, 0, N U LL)
(1, 0, v0 )
...
(1, 0, v0 )
(b) Restauration (r)(w)
[A0 ]
v0
v0
...
v0
vj+1
...
vk
Étape
0
1
...
j
j+1
...
k
Inst
φ
(r)
...
(r)
(w, vj+1 )
...
(w, vk )
([ES], [ER], [V S])
(1, 0, v0 )
(1, 1, v0 )
...
(1, 1, v0 )
(1, 1, v0 )
...
(1, 1, v0 )
[A0 ]
vk
v0
...
vj
vj+1
...
vk
Tableau 5 – Séquence (w)(r)
(a) Sauvegarde (w)(r)
Étape
0
1
...
j
j+1
...
k
Inst
φ
(w, v1 )
...
(w, vj )
(r)
...
(r)
([ES], [ER], [V S])
φ
φ
...
φ
(0, 0, N U LL)
...
(0, 0, N U LL)
(b) Restauration (w)(r)
[A0 ]
v0
v1
...
vj
vj
...
vj
Étape
0
1
...
j
j+1
...
k
Inst
φ
(w, v1 )
...
(w, vj )
(r)
...
(r)
([ES], [ER], [V S])
(0, 0, N U LL)
(0, 0, N U LL)
...
(0, 0, N U LL)
(0, 0, N U LL)
...
(0, 0, N U LL)
[A0 ]
vj
v1
...
vj
vj
...
vj
Rsig
0
0
...
0
0
...
0
Rsig
0
1
...
0
0
...
0
123
Tableau 6 – Séquence (r)(w)(r)
(b) Restauration (r)(w)(r)
(a) Sauvegarde (r)(w)(r)
Étape
0
1
...
j
j+1
...
k
k+1
...
l
Inst
φ
(r)
...
(r)
(w, vj+1 )
...
(w, vk )
(r)
...
(r)
([ES], [ER], [V S])
φ
(0, 0, N U LL)
...
(0, 0, N U LL)
(1, 0, v0 )
...
(1, 0, v0 )
(1, 0, v0 )
...
(1, 0, v0 )
[A0 ]
v0
v0
...
v0
vj+1
...
vk
vk
...
vk
Étape
0
1
...
j
j+1
...
k
k+1
...
l
Inst
φ
(r)
...
(r)
(w, vj+1 )
...
(w, vk )
(r)
...
(r)
([ES], [ER], [V S])
(1, 0, v0 )
(1, 1, v0 )
...
(1, 1, v0 )
(1, 1, v0 )
...
(1, 1, v0 )
(1, 1, v0 )
...
(1, 1, v0 )
[A0 ]
vk
v0
...
v0
vj+1
...
vk
vk
...
vk
Rsig
0
1
...
0
0
...
0
0
...
0
Tableau 7 – Séquence (w)(r)(w)
(a) Sauvegarde (w)(r)(w)
Étape
0
1
...
j
j+1
...
k
k+1
...
l
Inst
φ
(w, v1 )
...
(w, vj )
(r)
...
(r)
(w, vk+1 )
...
(w, vl )
([ES], [ER], [V S])
φ
φ
...
φ
(0, 0, N U LL)
...
(0, 0, N U LL)
(1, 0, vj )
...
(1, 0, vj )
(b) Restauration (w)(r)(w)
[A0 ]
v0
v1
...
vj
vj
...
vj
vk+1
...
vl
Étape
0
1
...
j
j+1
...
k
k+1
...
l
([ES], [ER], [V S])
(1, 0, vj )
(1, 1, vj )
...
(1, 1, vj )
(1, 1, vj )
...
(1, 1, vj )
(1, 1, vj )
...
(1, 1, vj )
Inst
φ
(w, v1 )
...
(w, vj )
(r)
...
(r)
(w, vk+1 )
...
(w, vl )
[A0 ]
vl
v1
...
vj
vj
...
vj
vk+1
...
vl
Rsig
0
0
...
0
0
...
0
0
...
0
Tableau 8 – Séquence (r)(w)(r)(w)
(a) Sauvegarde (r)(w)(r)(w)
Étape
0
1
...
j
j+1
...
k
k+1
...
l
l+1
...
m
Inst
φ
(r)
...
(r)
(w, vj+1 )
...
(w, vk )
(r)
...
(r)
(w, vl+1 )
...
(w, vm )
([ES], [ER], [V S])
φ
(0, 0, N U LL)
...
(0, 0, N U LL)
(1, 0, v0 )
...
(1, 0, v0 )
(1, 0, v0 )
...
(1, 0, v0 )
(1, 0, v0 )
...
(1, 0, v0 )
(b) Restauration (r)(w)(r)
[A0 ]
v0
v0
...
v0
vj+1
...
vk
vk
...
vk
vl+1
...
vm
Étape
0
1
...
j
j+1
...
k
k+1
...
l
l+1
...
m
Inst
φ
(r)
...
(r)
(w, vj+1 )
...
(w, vk )
(r)
...
(r)
(w, vl+1 )
...
(w, vm )
([ES], [ER], [V S])
(1, 0, v0 )
(1, 1, v0 )
...
(1, 1, v0 )
(1, 1, v0 )
...
(1, 1, v0 )
(1, 1, v0 )
...
(1, 1, v0 )
(1, 1, v0 )
...
(1, 1, v0 )
[A0 ]
vm
v0
...
v0
vj+1
...
vk
vk
...
vk
vl+1
...
vm
Rsig
0
1
...
0
0
...
0
0
...
0
0
0
0
Annexe . Exemples de fonctionnement système de sauvegarde et de
124
recouvrement
Tableau 9 – Séquence (w)(r)(w)(r)
(b) Restauration (w)(r)(w)(r)
(a) Sauvegarde (w)(r)(w)(r)
Étape
0
1
...
j
j+1
...
k
k+1
...
l
l+1
...
m
Inst
φ
(w, v1 )
...
(w, vj )
(r)
...
(r)
(w, vk+1 )
...
(w, vl )
r
...
r
([ES], [ER], [V S])
φ
φ
...
φ
(0, 0, N U LL)
...
(0, 0, N U LL)
(1, 0, vj )
...
(1, 0, vj )
(1, 0, vj )
...
(1, 0, vj )
[A0 ]
v0
v1
...
vj
vj
...
vj
vk+1
...
vl
vl
...
vl
Étape
0
1
...
j
j+1
...
k
k+1
...
l
l+1
...
m
Inst
φ
(w, v1 )
...
(w, vj )
(r)
...
(r)
(w, vk+1 )
...
(w, vl )
r
...
r
([ES], [ER], [V S])
(1, 0, vj )
(1, 1, vj )
...
(1, 1, vj )
(1, 1, vj )
...
(1, 1, vj )
(1, 1, vj )
...
(1, 1, vj )
(1, 1, vj )
...
(1, 1, vj )
[A0 ]
vl
v1
...
vj
vj
...
vj
vk+1
...
vl
vl
...
vl
Rsig
0
0
...
0
0
...
0
0
...
0
0
...
0
Bibliographie
[1] Oliver Kömmerling and Markus G. Kuhn. Design Principles for Tamperresistant Smartcard Processors. In Proc. USENIX Workshop on Smartcard
Technology − WOST, USENIX Association, pages 9–20, 1999. (Cité sur
les pages v and 6.)
[2] Sergei P. Skorobogatov. Semi-invasive Attacks – A New Approach to Hardware Security Analysis. Technical report, University of Cambridge, Computer Laboratory, April 2005. (Cité sur les pages v, 4, 6, and 7.)
[3] Michel Agoyan, Jean-Max Dutertre, David Naccache, Bruno Robisson, and
Assia Tria. When clocks fail : On critical paths and clock faults. In CARDIS, pages 182–193, 2010. (Cité sur les pages v and 8.)
[4] Steven K. Reinhardt and Shubhendu S. Mukherjee. Transient Fault Detection via Simultaneous Multithreading. SIGARCH Computer Architecture
News, 28(2) :25–36, 2000. (Cité sur les pages v, 33, 34, and 35.)
[5] Yunsi Fei and Z. Jerry Shi. Microarchitectural Support for Program Code
Integrity Monitoring in Application-Specific Instruction Set Processors. In
Proc. Design, Automation and Test in Europe − DATE, EDA Consortium,
pages 815–820, 2007. (Cité sur les pages v, 37, 38, and 39.)
[6] Divya Arora, Srivaths Ravi, Anand Raghunathan, and Niraj K. Jha. Secure
Embedded Processing through Hardware-Assisted Run-Time Monitoring.
In Proc. Design, Automation and Test in Europe − DATE, IEEE CS,
volume 1, pages 178–183, 2005. (Cité sur les pages v and 39.)
[7] David May, Henk L. Muller, and Nigel P. Smart. Non-deterministic Processors. In Proc. Australasian Conference on Information Security and
Privacy − ACISP, Springer, pages 115–129, 2001. (Cité sur les pages v,
51, and 52.)
[8] S.P. Skorobogatov and R.J. Anderson. Optical Fault Induction Attacks.
Cryptographic Hardware and Embedded Systems-Ches 2002 : 4th International Workshop, Redwood Shores, CA, USA, August 13-15, 2002 : Revised
Papers, 2002. (Cité sur la page 8.)
[9] Jean-Jacques Quisquater and David Samyde. Electromagnetic analysis
(ema) : Measures and counter-measures for smart cards. In E-SMART
’01 : Proceedings of the International Conference on Research in Smart
Cards, pages 200–210, London, UK, 2001. Springer-Verlag. (Cité sur les
pages 9 and 18.)
125
126
Bibliographie
[10] François Poucheret, Karim Tobich, Mathieu Lisart, Bruno Robisson,
Laurent Chusseau, and Philippe Maurine. Local and direct electromagnetic injection of power into cmos integrated circuits. In Proceedings of
Fault Diagnosis and Tolerance in Cryptography (FDTC’11), page To appear, Nara, Japan, 2010. (Cité sur la page 9.)
[11] Amir Pasha Mirbaha, Jean-Max Dutertre, Anne-Lise Ribotta, Michel
Agoyan, Assia Tria, and David Naccache. Single-Bit DFA Using MultipleByte Laser Fault Injection. In 10th IEEE International Conference on
Technologies for Homeland Security, Boston, États-Unis, November 2010.
(Cité sur la page 10.)
[12] Doulcier Marion, Jean-Max Dutertre, Jacques Jean-Alain Fournier, JeanBaptiste Rigaud, Bruno Robisson, and Assia Tria. A Side-Channel and
Fault-Attack Resistant AES Circuit Working on Duplicated Complemented Values. In Solid State Circuits Conference - Digest of technical papers,
2011 (ISSCC 2011) International Solid State Circuits Conference - ISSCC
2011, page 15.6, San Francisco United States, 02 2011. (Cité sur la page 11.)
[13] Hamid Choukri and Michael Tunstall. Round Reduction Using Faults. In
Proc. Fault Diagnosis and Tolerance in Cryptography − FDTC, volume
4236, pages 13–24, 2005. (Cité sur la page 12.)
[14] Ross Anderson and Markus Kuhn. Tamper Resistance : A Cautionary
Note. In Proc. Second Usenix Workshop on Electronic Commerce, USENIX
Association, pages 1–11, 1996. (Cité sur la page 12.)
[15] Eric Vétillard and Anthony Ferrari. Combined attacks and countermeasures. In CARDIS, pages 133–147, 2010. (Cité sur la page 12.)
[16] Eli Biham and Adi Shamir. Differential Cryptanalysis of DES-like Cryptosystems. In Proc. Advances in Cryptology − CRYPTO, Springer, volume
537, pages 2–21, 1990. (Cité sur la page 14.)
[17] Christophe Giraud. DFA on AES. In Proc. Advanced Encryption Standard
− AES, Springer, volume 3373, pages 27–41, 2004. (Cité sur la page 14.)
[18] Christian Aumüller, Peter Bier, Wieland Fischer, Peter Hofreiter, and JeanPierre Seifert. Fault Attacks on RSA with CRT : Concrete Results and
Practical Countermeasures. In Proc. Cryptographic Hardware and Embedded Systems − CHES, Springer, volume 2523, 2003. (Cité sur la page 14.)
[19] S.-M. Yen and M. Joye. Checking before Output May not be Enough
against Fault-Based Cryptanalysis. IEEE Transactions on Computers,
49(9) :967–970, 2000. (Cité sur la page 14.)
[20] Bruno Robisson and Pascal Manet. Differential Behavioral Analysis. In
Proc. Cryptographic Hardware and Embedded Systems − CHES, Springer,
volume 4727, pages 413–426, 2007. (Cité sur les pages 14 and 76.)
Bibliographie
127
[21] P. Kocher, J. Jaffe, and B. Jun. Differential Power Analysis. In Advances
in Cryptology − CRYPTO, Springer, volume 1666, pages 388–397, 1999.
(Cité sur la page 15.)
[22] Thanh-Ha LE. Analyses et mesures avancées du rayonnenment électromagnétique d’un circuit intégré. PhD thesis, Institut National Polytechnique
de Grenoble., 2007. (Cité sur la page 18.)
[23] Roman Novak. SPA-Based Adaptive Chosen-Ciphertext Attack on RSA
Implementation. In PKC ’02 : Proceedings of the 5th International Workshop on Practice and Theory in Public Key Cryptosystems, pages 252–262,
London, UK, 2002. Springer-Verlag. (Cité sur la page 20.)
[24] Pierre-Alain Fouque, Gwenaëlle Martinet, and Guillaume Poupard. Attacking Unbalanced RSA–CRT Using SPA. j-LECT-NOTES-COMP-SCI,
2779 :254–268, 2003. (Cité sur la page 20.)
[25] Christian Rechberger. Side channel analysis of stream ciphers. Master’s
thesis, Institute for Applied Information Processing and Communications
(IAIK), Graz University of Technology, Austria, 2004. (Cité sur la page 26.)
[26] Kai Schramm, Thomas J. Wollinger, and Christof Paar. A New Class
of Collision Attacks and Its Application to DES. In Proc. Fast Software
Encryption − FSE, Springer, volume 2887, pages 206–222, 2003. (Cité sur
la page 26.)
[27] Kai Schramm, Gregor Leander, Patrick Felke, and Christof Paar. A
collision-attack on aes : Combining side channel- and differential-attack.
In CHES, pages 163–175, 2004. (Cité sur la page 26.)
[28] Johannes Blömer and Volker Krummel. Fault Based Collision Attacks on
AES. In Proc. Fault Diagnosis and Tolerance in Cryptography − FDTC,
Springer, volume 4236, pages 106–120, 2006. (Cité sur la page 26.)
[29] J. H. Patel and L. Y. Fung. Concurrent Error Detection in ALU’s by
Recomputing with Shifted Operands. IEEE Transactions on Computers,
31(7) :589–595, 1982. (Cité sur la page 31.)
[30] Alain Wood, Robert Jardine, and Wendy Bartlett. Data Integrity in HP
NonStop Servers. In Proc. Workshop on Silicon Errors in Logic and System
Effects − SELSE, 2006. (Cité sur la page 34.)
[31] Timothy J. Slegel and et al. IBM’s S/390 G5 Microprocessor Design. IEEE
Micro, 19(2) :12–23, 1999. (Cité sur les pages 34 and 42.)
[32] Todd M. Austin. DIVA : A Reliable Substrate for Deep Submicron Microarchitecture Design. In Proc. ACM/IEEE international symposium on
Microarchitecture − MICRO, IEEE CS, pages 196–207, 1999. (Cité sur les
pages 34 and 42.)
128
Bibliographie
[33] Nahmsuk Oh, Philip P. Shirvani, and Edward J. Mccluskey. Error Detection by Duplicated Instructions in Super-scalar Processors. IEEE Transactions on Reliability, 51 :63–75, 2002. (Cité sur la page 34.)
[34] Maurizio Rebaudengo, Matteo Sonza Reorda, Marco Torchiano, and Massimo Violante. Soft-Error Detection through Software Fault-Tolerance
Techniques. In Proc. International Symposium on Defect and FaultTolerance in VLSI Systems − DFT, IEEE CS, pages 210–218. IEEE Computer Society, 1999. (Cité sur la page 34.)
[35] Nahmsuk Oh, Subhasish Mitra, and Edward J. McCluskey. ED4I : Error
Detection by Diverse Data and Duplicated Instructions. IEEE Transactions on Computers, 51(2) :180–199, 2002. (Cité sur la page 34.)
[36] Paolo Bernardi, Leticia Maria Veiras Bolzani, Maurizio Rebaudengo, Matteo Sonza Reorda, Fabian Luis Vargas, and Massimo Violante. A New
Hybrid Fault Detection Technique for Systems-on-a-Chip. IEEE Transactions on Computers, 55(2) :185–198, 2006. (Cité sur la page 35.)
[37] Eric Rotenberg. AR-SMT : A Microarchitectural Approach to Fault Tolerance in Microprocessors. In Proc. International Symposium on FaultTolerant Computing − FTCS, IEEE CS, pages 84–91, 1999. (Cité sur la
page 35.)
[38] Michael Nicolaidis. Time Redundancy Based Soft-Error Tolerance to Rescue Nanometer Technologies. In Proc. VLSI Test Symposium - VTS, IEEE
CS, page 86, 1999. (Cité sur la page 35.)
[39] Viswanathan Subramanian and Arun K. Somani. Conjoined Pipeline :
Enhancing Hardware Reliability and Performance through Organized Pipeline Redundancy. In Proc. Pacific Rim International Symposium on
Dependable Computing − PRDC, IEEE CS, pages 9–16. IEEE Computer
Society, 2008. (Cité sur la page 35.)
[40] Dan Ernst, Nam Sung Kim, Shidhartha Das, Sanjay Pant, Rajeev Rao,
Toan Pham, Conrad Ziesler, David Blaauw, Todd Austin, Krisztian Flautner, and Trevor Mudge. Razor : A Low-Power Pipeline Based on CircuitLevel Timing Speculation. In Proc. IEEE/ACM International Symposium
on Microarchitecture − MICRO, IEEE CS, pages 7–18, 2003. (Cité sur la
page 35.)
[41] Michael Nicolaidis. Carry Checking/Parity Prediction Adders and ALUs.
IEEE Transactions on Very Large Scale Integration Systems, 11(1) :121–
128, 2003. (Cité sur la page 35.)
[42] J.-C. Lo, S. Thanawastien, T.R.N. Rao, and M. Nicolaidis. An SFS Berger
Check Prediction ALU and Its Application to Self-checking Processor Desi-
Bibliographie
129
gns. IEEE Transactions on Computer-Aided Design of Integrated Circuits
and Systems, 11(4) :525–540, 1992. (Cité sur la page 35.)
[43] S. S. Gorshe and B. Bose. A Self-checking ALU Design with Efficient
Codes. In Proc. VLSI Test Symposium − VTS, IEEE CS, pages 157–161,
1996. (Cité sur la page 35.)
[44] David Lie, Chandramohan Thekkath, Mark Mitchell, Patrick Lincoln, Dan
Boneh, John Mitchell, and Mark Horowitz. Architectural Support for Copy
and Tamper Resistant Software. ACM SIGPLAN Notices, 35(11) :168–177,
2000. (Cité sur la page 36.)
[45] G. Edward Suh, Dwaine Clarke, Blaise Gassend, Marten van Dijk, and
Srinivas Devadas. AEGIS : Architecture for Tamper-evident and Tamperresistant Processing. In Proc. International conference on Supercomputing
− ICS, ACM, pages 160–171, 2003. (Cité sur la page 36.)
[46] Reouven Elbaz, Lionel Torres, Gilles Sassatelli, Pierre Guillemin, Michel
Bardouillet, and Albert Martinez. A Parallelized Way to Provide Data
Encryption and Integrity Checking on a Processor-Memory Bus. In Proc.
Design Automation Conference − DAC, ACM, pages 506–509, 2006. (Cité
sur la page 36.)
[47] Romain Vaslin, Guy Gogniat, Jean-Philippe Diguet, Eduardo Wanderley
Netto, Russell Tessier, and Wayne P. Burleson. A security approach for offchip memory in embedded microprocessor systems. Microprocessors and
Microsystems - Embedded Hardware Design, 33(1) :37–45, 2009. (Cité sur
la page 36.)
[48] Romain Vaslin, Guy Gogniat, Eduardo Wanderley Netto, Russell Tessier,
and Wayne P. Burleson. Low Latency Solution for Confidentiality and Integrity Checking in Embedded Systems with Off-Chip Memory. In Proc. Reconfigurable Communication-centric Systems-on-Chip − ReCoSoC, pages
146–153, 2007. (Cité sur la page 36.)
[49] Kostas Pagiamtzis and Ali Sheikholeslami. "Content-Addressable Memory
(CAM) Circuits and Architectures : A Tutorial and Survey". IEEE Journal
of Solid-State Circuits, 41(3) :712–727, March 2006. (Cité sur la page 38.)
[50] Roshan G. Ragel and Sri Parameswaran. IMPRES : Integrated Monitoring for Processor Reliability and Security. In Proc. Design Automation
Conference − DAC, ACM, pages 502–505, 2006. (Cité sur les pages 38, 70,
and 71.)
[51] A. Benso, S. Di Carlo, G. Di Natale, and P. Prinetto. A watchdog processor
to detect data and control flow errors. In On-Line Testing Symposium,
2003. IOLTS 2003. 9th IEEE, pages 144 – 148, july 2003. (Cité sur la
page 40.)
130
Bibliographie
[52] Shufu Mao and T. Wolf. Hardware support for secure processing in embedded systems. Computers, IEEE Transactions on, 59(6) :847 –854, june
2010. (Cité sur la page 40.)
[53] Nicholas J. Wang and Sanjay J. Patel. ReStore : Symptom Based Soft
Error Detection in Microprocessors. In Proc. International Conference on
Dependable Systems and Networks − DSN, IEEE CS, pages 30–39, 2005.
(Cité sur les pages 41 and 42.)
[54] Satish Narayanasamy, Ayse K. Coskun, and Brad Calder. Transient Fault
Prediction Based on Anomalies in Processor Events. In Proc. Design,
automation and test in Europe − DATE, EDA Consortium, pages 1140–
1145, 2007. (Cité sur la page 41.)
[55] Portolan Michele and Leveugle Regis. Effective checkpoint and rollback
using hardware/os collaboration. In Proc. efect and Fault-Tolerance in
VLSI Systems − DFT, IEEE CS, pages 370–378, 2007. (Cité sur la
page 42.)
[56] Y. Tamir and M. Tremblay. High-performance fault-tolerant vlsi systems
using micro rollback. IEEE Transaction on Computers, 39(4) :548–554,
1990. (Cité sur la page 42.)
[57] J. L. Hennessy and D. A. Patterson. Computer Architecture : A Quantitative Approach. Morgan Kauffman, 2006. (Cité sur les pages 42 and 93.)
[58] T. N. Vijaykumar, Irith Pomeranz, and Karl Cheng. Transient-fault Recovery using Simultaneous Multithreading. SIGARCH Computer Architecture News, 30(2) :87–98, 2002. (Cité sur la page 42.)
[59] Philip A. Bernstein. Sequoia : A fault-tolerant tightly coupled multiprocessor for transaction processing. Computer, 21(2) :37–45, 1988. (Cité sur
la page 42.)
[60] D.Hunt and P.Marinos. A general purpose cache-aided rollback error recovery (carer) technique. In Proc. Fault-Tolerant Computing Systems −
FTCS, IEEE CS, pages 170–175, 1987. (Cité sur la page 43.)
[61] P. A. Lee, N. Ghani, and K. Heron. A recovery cache for the pdp-11. IEEE
Transaction on Computers, 29(6) :546–549, 1980. (Cité sur les pages 43
and 76.)
[62] Milos Prvulovic, Zheng Zhang, and Josep Torrellas. Revive : Cost-effective
architectural support for rollback recovery in shared-memory multiprocessors. SIGARCH Comput. Archit. News, 30(2) :111–122, 2002. (Cité sur la
page 43.)
[63] Daniel J. Sorin, Milo M. K. Martin, Mark D. Hill, and David A. Wood.
Safetynet : Improving the availability of shared memory multiprocessors
Bibliographie
131
with global checkpoint/recovery. In Proc. Computer architecture − ISCA,
IEEE CS, pages 123–134, 2002. (Cité sur la page 43.)
[64] Guy Gogniat, Tilman Wolf, Wayne P. Burleson, Jean-Philippe Diguet,
Lilian Bossuet, and Romain Vaslin. Reconfigurable hardware for highsecurity/ high-performance embedded systems : The safes perspective.
IEEE Trans. VLSI Syst., 16(2) :144–155, 2008. (Cité sur la page 44.)
[65] B. Robisson, M. Agoyan, S. Le Henaff, P. Soquet, G. Phan, Wajsburt, F.,
and P. Bazargan-Sabet. Implementation of complex strategies of security
insecure embedded systems. In New Technologies, Mobility and Security
(NTMS), 2011 4th IFIP International Conference on, pages 1 –5, feb. 2011.
(Cité sur la page 44.)
[66] H. Puchner, Y.Z Xu, and D. Radaelli. Advanced SEU Engineering using
a Triple Well Architecture [CMOS SRAM]. In Proc. Solid-State Device
Research Conference − ESSDERC, IEEE CS, pages 369–372, 2004. (Cité
sur la page 44.)
[67] Ethan H. Cannon, Daniel D. Reinhardt, Michael S. Gordon, and Paul S.
Makowenskyj. SRAM SER in 90, 130 and 180 nm Bulk and SOI Technologies. In Proc. International Reliability Physics Symposium − IRPS, IEEE
CS, pages 300–304, 2004. (Cité sur la page 45.)
[68] Yannick Monnet, Marc Renaudin, and Regis Leveugle. Designing Resistant Circuits against Malicious Faults Injection Using Asynchronous Logic.
IEEE Transactions on Computers, 55(9) :1104–1115, 2006. (Cité sur la
page 45.)
[69] Paul Cunningham, Ross Anderson, Robert Mullins, George Taylor, and
Simon Moore. Improving Smart Card Security Using Self-Timed Circuits.
In Proc. International Symposium on Asynchronus Circuits and Systems ASYNC, IEEE CS, page 211, 2002. (Cité sur les pages 45 and 46.)
[70] Rodrigo Possamai Bastos, Yannick Monnet, Gilles Sicard, Fernanda Lima
Kastensmidt, Marc Renaudin, and Ricardo Reis. Comparing transientfault effects on synchronous and on asynchronous circuits. In IOLTS, pages
29–34, 2009. (Cité sur la page 45.)
[71] Kris Tiri, Moonmoon Akmal, and Ingrid Verbauwhede. A Dynamic and
Differential CMOS Logic with Signal Independent Power Consumption to
Withstand Differential Power Analysis on Smart Cards. In Proc. European
Solid-State Circuits Conference − ESSCIRC,, pages 403–406, 2002. (Cité
sur la page 46.)
[72] Kris Tiri and Ingrid Verbauwhede. A Logic Level Design Methodology for
a Secure DPA Resistant ASIC or FPGA Implementation. In Proc. Design,
132
Bibliographie
Automation and Test in Europe − DATE, IEEE CS, pages 246–251, 2004.
(Cité sur la page 46.)
[73] Sylvain Guilley, Philippe Hoogvorst, Yves Mathieu, and Renaud Pacalet.
The “Backend Duplication” Method. In Proc. Cryptographic Hardware and
Embedded Systems − Springer, volume 3659, pages 383–397, 2005. (Cité
sur la page 47.)
[74] H. Saputra, N. Vijaykrishnan, M. Kandemir, M. J. Irwin, R. Brooks,
S. Kim, and W. Zhang. Masking the Energy Behavior of DES Encryption. In Proc. Design, Automation and Test in Europe − DATA, IEEE
CS, pages 84–89, 2003. (Cité sur la page 47.)
[75] Victor Lomné, Philippe Maurine, Lionel Torres, Michel Robert, Rafael
Soares, and Ney Calazans. Evaluation on fpga of triple rail logic robustness against dpa and dema. In DATE, pages 634–639, 2009. (Cité sur la
page 47.)
[76] Adi Shamir. Protecting Smart Cards from Passive Power Analysis with
Detached Power Supplies. In Proc. Cryptographic Hardware and Embedded
Systems − CHES, Springer, pages 71–77, 2000. (Cité sur la page 48.)
[77] Rakers Patrick, Connell Larry, Collins Tim, and Russel Dan. Secure
contactless smartcard ASIC with DPA protection. IEEE Journal of SolidState Circuits, 36(3) :559–565, 2001. (Cité sur la page 48.)
[78] Girish B. Ratanpal, Ronald D. Williams, and Travis N. Blalock. An
On-Chip Signal Suppression Countermeasure to Power Analysis Attacks.
IEEE Transactions on Dependable Security Computing, 1(3) :179–189,
2004. (Cité sur la page 48.)
[79] R. Muresan, H. Vahedi, Y. Zhanrong, and S. Gregori. Power-smart
System-on-chip Architecture for Embedded Cryptosystems. In Proc. Hardware/software codesign and system synthesis − CODES+ISSS, ACM,
pages 184–189, 2005. (Cité sur la page 48.)
[80] Radu Muresan and Catherine Gebotys. Current Flattening in Software and
Hardware for Security Applications. In Proc. Hardware/software codesign
and system synthesis − CODES+ISSS, ACM, pages 218–223, 2004. (Cité
sur la page 48.)
[81] J. Irwin, D. Page, and N. P. Smart. Instruction Stream Mutation for
Non-Deterministic Processors. In Proc. Application-Specific Systems, Architectures, and Processors − ASAP, IEEE CS, pages 286–295, 2002. (Cité
sur la page 50.)
[82] Jude Angelo Ambrose, Roshan G. Ragel, and Sri Parameswaran. RIJID :
Random Code Injection to Mask Power Analysis based Side Channel At-
Bibliographie
133
tacks. In Proc. Design Automation Conference − DAC, ACM, pages 489–
492, 2007. (Cité sur les pages 50, 101, 102, and 118.)
[83] David May, Henk L. Muller, and Nigel P. Smart. Random Register Renaming to Foil DPA. In Proc. Cryptographic Hardware and Embedded Systems
− CHES, Springer, pages 28–38, 2001. (Cité sur la page 53.)
[84] Jean-Sébastien Coron and Louis Goubin. On Boolean and arithmetic masking against differential power analysis. In Cryptographic Hardware and
Embedded Systems, volume 1965 of Lecture Notes in Computer Science,
pages 231–237. Springer, 2001. (Cité sur la page 54.)
[85] Mehdi-Laurent Akkar and Christophe Giraud. An implementation of des
and aes, secure against some attacks. In C.K. Koc, D. Naccache, and
C. Paar, editors, Proceedings of Cryptographic Hardware and Embedded
Systems, volume 2162 of Lecture Notes in Computer Science, pages 309–
318. Springer, 2002. (Cité sur la page 54.)
[86] F.-X. Standaert, G. Rouvroy, and J.-J. Quisquater. Fpga implementations of the des and triple-des masked against power analysis attacks. In
Field Programmable Logic and Applications, 2006. FPL ’06. International
Conference on, pages 1 –4, aug. 2006. (Cité sur la page 54.)
[87] H. Maghrebi, J.-L. Danger, F. Flament, S. Guilley, and L. Sauvage. Evaluation of countermeasure implementations based on boolean masking to
thwart side-channel attacks. In Signals, Circuits and Systems (SCS), 2009
3rd International Conference on, pages 1 –6, nov. 2009. (Cité sur la
page 54.)
[88] L. Barthe, P. Benoit, and L. Torres. Investigation of a masking countermeasure against side-channel attacks for risc-based processor architectures.
In Field Programmable Logic and Applications (FPL), 2010 International
Conference on, pages 139 –144, 31 2010-sept. 2 2010. (Cité sur la page 54.)
[89] Stefan Tillich, Mario Kirschbaum, and Alexander Szekely. Sca-resistant
embedded processors : the next generation. In ACSAC’10, pages 211–220,
2010. (Cité sur la page 54.)
[90] Francesco Regazzoni, Alessandro Cevrero, François-Xavier Standaert, Stephane Badel, Theo Kluter, Philip Brisk, Yusuf Leblebici, and Paolo Ienne.
A design flow and evaluation framework for dpa-resistant instruction set
extensions. In Proceedings of the 11th International Workshop on Cryptographic Hardware and Embedded Systems, CHES ’09, pages 205–219, Berlin, Heidelberg, 2009. Springer-Verlag. (Cité sur la page 54.)
[91] Projet Minimips. http://opencores.org/project,minimips. (Cité sur
la page 58.)
134
Bibliographie
[92] Don Libes. Exploring Expect. O’Reilly & Associates, Inc., 1996. (Cité sur
la page 65.)
[93] M. R. Guthaus, J. S. Ringenberg, D. Ernst, T. M. Austin, T. Mudge, and
R. B. Brown. MiBench : A Free, Commercially Representative Embedded
Benchmark Suite. In Proc. Workshop on Workload Characterization −
WWC, pages 3–14, 2001. (Cité sur la page 65.)
[94] Bruce Schneier. Applied Cryptography : Protocols, Algorithms, and Source
Code in C, Second Edition. Wiley, 1995. (Cité sur la page 71.)
[95] Philip Koopman and Tridib Chakravarty. Cyclic Redundancy Code (CRC)
Polynomial Selection For Embedded Networks. In Proc. Dependable Systems and Networks - DSN, IEEE Computer Society, pages 145–154, 2004.
(Cité sur la page 71.)
[96] Giuseppe Campobello, Giuseppe Patanè, and Marco Russo. Parallel CRC
Realization. IEEE Transactions on Computers, 52(10) :1312–1319, 2003.
(Cité sur la page 72.)
[97] G.S Sohi, M. Franklin, and K.K Saluja. A Study of Time Redundant Fault
Tolerance Techniques for High-Performance Pipelined Computers. In Proc.
Fault-Tolerant Computing Systems − FTCS, pages 436–433, 1989. (Cité
sur la page 89.)
[98] M. Franklin. A Study of Time Redundant Fault Tolerance Techniques
for Superscalar Processors. In Proc. Defect and Fault Tolerance in VLSI
Systems − DFT, pages 207–215, 1995. (Cité sur la page 89.)
[99] G. Sinevriotis and Thanos Stouraitis. A Novel List-Scheduling Algorithm
for the Low-energy Program Execution. In Proc. International Symposium
on Circuits and Systems − ISCAS, IEEE CS, pages 97–100, 2002. (Cité
sur la page 89.)
[100] Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman. Compilers : Principles,
Techniques, and Tools. Addison-Wesley, 1986. (Cité sur la page 93.)
[101] Michael R. Garey and David S. Johnson. Computers and Intractability ; A
Guide to the Theory of NP-Completeness. W. H. Freeman & Co., 1990.
(Cité sur la page 94.)
[102] Eric Brier, Christophe Clavier, and Francis Olivier. Correlation Power
Analysis with a Leakage Model. In Proc. Cryptographic Hardware and
Embedded Systems − CHES, Springer, pages 16–29, 2004. (Cité sur la
page 109.)
[103] Nicolas Veyrat-Charvillon and François-Xavier Standaert. Mutual Information Analysis : How, When and Why ? In Proc. Cryptographic Hardware
and Embedded Systems − CHES, Springer, pages 429–443, 2009. (Cité sur
la page 109.)
Bibliographie
135
[104] Stefan Mangard, Elisabeth Oswald, and Francois-Xavier Standaert. One
for All - All for One : Unifying Standard DPA Attacks. Cryptology ePrint
Archive, Report 2009/449, 2009. (Cité sur la page 109.)
[105] Benedikt Gierlichs, Lejla Batina, and Pim Tuyls. Mutual information analysis – a universal differential side-channel attack. Cryptology ePrint Archive, Report 2007/198, 2007. (Cité sur la page 118.)
[106] P. Leadbitter, D. Page, and N.P. Smart. Nondeterministic multithreading.
Computers, IEEE Transactions on, 56(7) :992 –998, july 2007. (Cité sur
la page 118.)
[107] François-Xavier Standaert and Cédric Archambeau. Using subspace-based
template attacks to compare and combine power and electromagnetic information leakages. In Elisabeth Oswald and Pankaj Rohatgi, editors,
CHES, volume 5154 of Lecture Notes in Computer Science, pages 411–425.
Springer, 2008. (Cité sur la page 118.)
Bibliographie personnelle
Conférences internationales avec actes
1. M.H. Nguyen, B. Robisson, M. Agoyan, N. Drach « Low-cost recovery
for the code integrity protection in secure embedded processors », in Proc.
IEEE International Symposium on Hardware-Oriented Security and Trust
- HOST, San Diego, USA, IEEE CS, pages 99-104, 2011
2. M.H. Nguyen, B. Robisson, M. Agoyan, N. Drach « Low-cost fault tolerance on the ALU in simple pipelined processors », in Proc. Design and
Diagnostics of Electronic Circuits and Systems - DDECS, Autriche, IEEE
CS, pages 28-31, 2010
3. M.H. Nguyen, B. Robisson, N. Drach « Evaluation of the Time Redundant Fault Tolerance on the ALU for Simple Pipelined Processors », in
Proc. Austin Conference on Integrated Systems and Circuits - ACISC, Austin, USA, 2009
Conférences internationales sans actes
1. B. Robisson, M. Agoyan, S. Bouquet, M.H. Nguyen, S. Le Henaff, P.
Soquet, G. Phan, F. Wajsbürt, P. Bazargan-Sabet, N. Drach « Management
of the security in smart secure devices », in Smart Systems Integration
Conference, Zurich, Suisse, 2011
Conférences nationales avec actes
1. M.H Nguyen, M.Agoyan, P.Manet, B.Robisson « Test dintégrité de code
couplée à de la compression », in Journées Nationales du Réseau Doctoral
en Microélectronique JNRDM, Bordeaux, May 2008
137
Résumé : Les circuits intégrés de sécurité comme ceux qui sont utilisés dans
les cartes à puce, parce qu’ils contiennent des informations confidentielles, font
l’objet de manipulations frauduleuses, appelées communément attaques, de la
part de personnes mal intentionnées. Plusieurs attaques ont été répertoriées et
analysées. Les plus efficaces d’entre-elles consistent à mesurer la consommation
du circuit lorsque celui-ci réalise des calculs cryptographiques ou à altérer son
fonctionnement (notamment grâce à un laser) puis à utiliser des outils mathématiques permettant d’extraire les informations sensibles de ces mesures. Le travail
de thèse porte sur la protection d’un microprocesseur embarqué dans les circuits
de sécurité tels que la carte-à-puce contre les attaques répertoriées avec une
attention particulière portée aux attaques en faute. L’approche consistera à intégrer des spécifications sécuritaires dans les modèles architecturaux de processeurs
puis de créer ou d’adapter des outils de génération automatique afin d’obtenir des
modèles matériels vérifiant ces spécifications. Dans un premier temps, il s’agit
de faire l’état de l’art des attaques ainsi que les contre-mesures proposées dans
la littérature (masquage de l’information sensible par des aléas, redondance des
données, équilibrage des chemins de propagation etc...) Dans un second temps,
les contre-mesures, proposées dans le cadre de thèse, seront implantées et validées sur un processeur expérimental. Le résultat obtenu de solutions proposées
doivent offrir un faible surcoût en terme de matériel et de performance
Mots clés : Sécurité, Cartes à puce, Microprocesseur, Attaques par faute,
Attaques par observation, Contre-mesures, Intégrité du code, Détection, Recouvrement, Unité Arithmétique and Logique
138
Bibliographie personnelle
139