Analyses Sécuritaires de Code de Carte À Puce Sous Attaques Physiques Simulées

UNIVERSIT DORLANS
COLE DOCTORALE MATHMATIQUES, INFORMATIQUE,

PHYSIQUE THORIQUE ET INGNIERIE DES SYSTMES
LABORATOIRE DINFORMATIQUE FONDAMENTALE
DORLANS
THSE prsente par :
Xavier KAUFFMANN-TOURKESTANSKY
soutenue le : 28 novembre 2012

pour obtenir le grade de : Docteur de lUniversit dOrlans
Discipline/ Spcialit : INFORMATIQUE
Analyses scuritaires de code de carte puce

sous attaques physiques simules
THSE dirige par :

Pascal BERTHOM Professeur, ENSI de Bourges
RAPPORTEURS :
Samia BOUZEFRANE Matre de confrences, CNAM
Nathalie DRACH-TEMAM Professeur, UPMC Paris 6
JURY :
Mirian HALFELD FERRARI ALVES Professeur, IUT dOrlans,
Prsident du jury
Jean-Franois LALANDE Matre de Confrences, ENSI de Bourges
Jean-Louis LANET Professeur, Universit de Limoges
Francis CHAMBROT Ingnieur, Oberthur Technologies
Remerciements
Je tiens remercier les direntes personnes qui ont contribu cette thse.
Tout d'abord Emmanuel Prou pour m'avoir donn la chance de faire une thse chez
Oberthur Card Systems (maintenant Oberthur Technologies). Ses conseils et remarques m'ont
chaque fois guid et m'ont pouss amliorer la qualit de mon travail.
Je remercie Samia Bouzefrane ainsi que Nathalie Drach-Temam pour m'avoir fait l'honneur
d'accepter d'tre mes rapporteurs de thse. Merci elles et aux relecteurs attentifs qui ont su
dbusquer mes fautes et m'aider les corriger.
Je tiens remercier Francis Chambrot pour m'avoir accueilli dans son quipe de dve-
loppeurs Oberthur Technologies. Nos discussions ont grandement contribu cette thse et
m'ont beaucoup appris sur le monde de l'entreprise.
Merci tous mes collgues et amis qui ont rendu ces trois annes riches en expriences et
bons moments. Pour avoir rpondu toutes mes questions (pas toujours videntes), nag, bu
et voyag avec moi, vous avez fait de ces trois ans beaucoup plus qu'une simple thse. Merci
Tl Agbodjan, Yann-Loc Aubin, Graldine Avou, Emily Baczkowski, David Bennetot, Chris-
tophe Boussion, Philippe Butez, Agns Cougnard, Frank Degueret, Marco De Oliviera, Roger
Do, Mathieu Drouard, Sebastien Dubrunfaut, Olivier Escalona, Annick Fourmann, Cyril Gour-
raud, Sylvain Helaine, Audrey Jacquemart, Olivier Kawak, Osman Kocoglu, Franois Laporte,
Michel Lavenir, Raphael Levenes, Philippe Muresianu, Arezki Rezzeli, Caroline Ruet, Coraline
Strei, Rozenn Trubert, Rami Wehbi. En tant que dveloppeur, collgue et souvent ami, je garde
d'excellents souvenirs de ma thse grce vous.
Une ddicace spciale au bureau 133, avec son ambiance du tonnerre, o pas une journe ne
passe sans une bonne blague. Merci Guillaume Baurand, Yannick Bequer, Pierre Bourgault,
Ludovic Martin-Martinasso, Aissa Waknioun.
Merci galement aux habitants de la zone crypto et autres cryptologues pour leur aide
et pour n'avoir jamais manqu de m'inviter leurs pauses caf et soires arroses. Merci
Philippe Andouard. Guillaume Barbu, Clment Capel, Guillaume Dabosville, Fabien Deboyser,
Paul Dischamp, Julien Doget, Emmanuelle Dottax, Christophe Giraud, Robert Naciri, Gilles
Piret, Matthieu Rivain, Franck Rondepierre, Yannick Sierra, Hugues Thiebeauld pour les maux
de ttes mathmatiques ou non. Je tiens en particulier remercier Laurie Genelle pour nos
nombreuses conversations qui m'ont toujours beaucoup aid.
AT X mes cts et m'ont

Merci aux thsards qui, l'Ensi de Bourges, ont souert avec L E
permis d'attraper (parfois in extremis) mon train. Merci aussi aux membres du corps enseignant
qui ont su, par leur conversation, leur importation de spiritueux ou leur poigne de fer, entretenir
ma motivation pendant la rdaction de ce mmoire.
Je tiens galement remercier Danaelle Buriot dont les randonnes et longues discussions
ont renforc mon physique et mon mental intervalles rguliers.
ii
Pour avoir donn matire cette thse et nos collaborations, je remercie tout particulire-
ment mes co-auteurs Karine Heydemann, Pascal Berthom, Francis Chambrot et Jean-Franois
Lalande.
Mes encadrants Pascal Berthom et Jean Franois Lalande mritent une mention spciale
pour m'avoir si souvent encourag, log et nourri de leur passion pour l'informatique. Votre
sens humain et votre travail ont beaucoup inuenc le mien.
Je tiens aussi remercier toute ma famille et en particulier ma soeur Soline et Anh ma

maman pour m'avoir soutenu et support tout au long de ces trois ans. Cette thse vous est
ddie.
Mon dernier remerciement sera pour Agns pour sa comprhension, son soutien et son amour
qui m'ont beaucoup aid dans l'criture de ce manuscrit.
mon pre,
Table des matires
1 Introduction 1
1.1 Cadre et enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Facteur d'chelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Dportement de la scurit et environnement hostile . . . . . . . . . . . . 3
1.1.3 Carte puce et cryptographie . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Principe de fonctionnement d'une carte . . . . . . . . . . . . . . . . . . . 6
1.1.5 Diversit de l'cosystme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.6 Processus d'valuation de la scurit et de certication . . . . . . . . . . . 10
1.2 Approche fonctionnelle et vision bas niveau . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 Fabrication et utilisation fonctionnelle . . . . . . . . . . . . . . . . . . . . 12
1.2.2 Fonctionnement interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Besoins en scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.1 Historique de la scurit des cartes . . . . . . . . . . . . . . . . . . . . . . 27
1.3.2 Attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.3 Problmatique globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3.4 Proprits de scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.3.5 Spcications fonctionnelles et scurits additionnelles . . . . . . . . . . . 32
1.3.6 Scurisation et angles d'attaque . . . . . . . . . . . . . . . . . . . . . . . . 38
1.3.7 Modlisation et vrication . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.3.8 Angle d'approche et rsum . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.4 Conclusion et annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2 Modlisation et proprits de scurit 49

2.1 Introduction, approche et hypothses . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.1.1 Approches existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.1.2 Dcomposition de fonctionnalit . . . . . . . . . . . . . . . . . . . . . . . 53
2.1.3 Dcomposition en lments du langage . . . . . . . . . . . . . . . . . . . . 53
2.2 Formalisme utilis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2.1 Information et conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2.2 Ensemble d'informations visibles . . . . . . . . . . . . . . . . . . . . . . . 56
2.2.3 Zone de garantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.2.4 Type d'attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.2.5 Formalisation d'une proprit de scurit . . . . . . . . . . . . . . . . . . . 61
2.3 Condentialit d'une information . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.3.1 Condentialit sous attaque . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.3.2 Zone de gnration d'information d'un conteneur . . . . . . . . . . . . . . 64
2.3.3 Zone de garantie de condentialit . . . . . . . . . . . . . . . . . . . . . . 66
2.3.4 Avantage pour l'attaquant et granularit de l'information . . . . . . . . . 67
2.4 Intgrit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.4.1 Accs un conteneur et zone de garantie . . . . . . . . . . . . . . . . . . . 69

vi Table des matires
2.4.2 Intgrit en lecture et criture . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.4.3 Avantage pour l'attaquant . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.4.4 Intgrit d'excution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.1 Aspects smantiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.2 Temporalit des proprits . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.3 Prise en compte du compilateur . . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.4 Thorie de l'information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.6.5 Gnration automatique de proprits . . . . . . . . . . . . . . . . . . . . 78
3 Modle d'attaque 81
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.2 Caractrisation de l'attaquant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.2.1 Capacit d'observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.2.2 Capacit d'action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.3 Modlisation des consquences haut niveau . . . . . . . . . . . . . . . . . . . . 87
3.4 Modle d'attaque physique haut niveau . . . . . . . . . . . . . . . . . . . . . . 88
3.4.1 Eets des attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.4.2 Importance des attaques par nop et par saut . . . . . . . . . . . . . . . . 90
3.4.3 Attaques de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.4.4 Attaques de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.4.5 Dcalage d'interprtation du code . . . . . . . . . . . . . . . . . . . . . . . 97
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.6.1 Prise en compte d'attaques d'un ordre suprieur . . . . . . . . . . . . . . 105
3.6.2 Extension du modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4 Vrication de scurit sous attaques simules 109

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.2 Vrication statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.2.1 Exemple de proprits de scurit . . . . . . . . . . . . . . . . . . . . . . . 111
4.2.2 Vrication d'intervalle de valeurs . . . . . . . . . . . . . . . . . . . . . . 113
4.2.3 Limites de la vrication et solution . . . . . . . . . . . . . . . . . . . . . 115
4.2.4 Instrumentation et gnration d'annotations . . . . . . . . . . . . . . . . . 115
4.2.5 Vrication de scurit et simulation d'attaques physiques . . . . . . . . . 118
4.3 Rduction du nombre d'attaques simules . . . . . . . . . . . . . . . . . . . . . . 118
4.3.1 Attaques considres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.3.2 Typage de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.3.3 Classes d'quivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.3.4 Conditions et boucles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.3.5 Exprimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.5 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Table des matires vii
5 Test de scurit et visualisation 141

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.2 Mthodologie de test propose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.2.2 Mthode de classication des rsultats . . . . . . . . . . . . . . . . . . . . 146
5.3 Exprimentations et analyse scuritaire . . . . . . . . . . . . . . . . . . . . . . . . 148
5.3.1 Plate-forme exprimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.3.2 Exemple sur bzip2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.3.3 Exemple sur gzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.3.4 Couverture assembleur par le modle C . . . . . . . . . . . . . . . . . . . 157
5.4 Analyse des rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
5.4.1 Distribution des attaques par taille du saut . . . . . . . . . . . . . . . . . 160
5.4.2 Analyse visuelle des fonctions vulnrables . . . . . . . . . . . . . . . . . . 161
5.4.3 Implmentation de contre-mesures . . . . . . . . . . . . . . . . . . . . . . 163
5.5 Rsultats exprimentaux sur code de carte puce . . . . . . . . . . . . . . . . . . 164
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.7 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6 Outils industriels 169

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
6.2 Environnent et facteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.2.1 Environnement industriel . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.2.2 Processus de vrication de la scurit . . . . . . . . . . . . . . . . . . . . 170
6.2.3 Facteurs prendre en compte . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.3 Outils et mthodes existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.3.1 Domaines similaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.3.2 Cas particulier de la scurit . . . . . . . . . . . . . . . . . . . . . . . . . 173
6.3.3 Techniques statiques et dynamiques . . . . . . . . . . . . . . . . . . . . . 173
6.3.4 Scurit et absence d'erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . 173
6.4 Ralisations techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.4.1 Amlioration de la relecture de code . . . . . . . . . . . . . . . . . . . . . 175
6.4.2 Amlioration de la tracabilit fonctionnelle . . . . . . . . . . . . . . . . . 175
6.4.3 Vrication de formes de code . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.4.4 Injection simple et exhaustive d'attaques . . . . . . . . . . . . . . . . . . . 177
6.4.5 Analyse et interrogation interactive du code source . . . . . . . . . . . . . 181
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
7 Conclusion 189
7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
7.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Bibliographie 193
Glossaire 207
viii Table des matires
Table des Figures 211

Liste des Tableaux 212
Liste des Listings 213
Liste des Algorithmes 215
Chapitre 1
Introduction
Sommaire
1.1 Cadre et enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Facteur d'chelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Dportement de la scurit et environnement hostile . . . . . . . . . . . 3
1.1.3 Carte puce et cryptographie . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Principe de fonctionnement d'une carte . . . . . . . . . . . . . . . . . . 6
1.1.5 Diversit de l'cosystme . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.6 Processus d'valuation de la scurit et de certication . . . . . . . . . . 10
1.2 Approche fonctionnelle et vision bas niveau . . . . . . . . . . . . . . 11
1.2.1 Fabrication et utilisation fonctionnelle . . . . . . . . . . . . . . . . . . . 12
1.2.2 Fonctionnement interne . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Besoins en scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.1 Historique de la scurit des cartes . . . . . . . . . . . . . . . . . . . . . 27
1.3.2 Attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.3 Problmatique globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3.4 Proprits de scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.3.5 Spcications fonctionnelles et scurits additionnelles . . . . . . . . . . 32
1.3.6 Scurisation et angles d'attaque . . . . . . . . . . . . . . . . . . . . . . . 38
1.3.7 Modlisation et vrication . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.3.8 Angle d'approche et rsum . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.4 Conclusion et annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.1 Cadre et enjeux

Cette thse s'intresse aux attaques physiques contre les systmes embarqus qui permettent
de modier le comportement du code. Provoques par des vecteurs d'inuences physiques ex-
trieurs au systme, ces attaques peuvent remettre en cause la scurit de celui-ci. Cette thse
cible en particulier le code des cartes puce. En eet, la scurit du fonctionnement de ces cartes
et la condentialit des informations contenues dans celles-ci reprsentent un enjeu important.
Le cas des cartes puce n'est cependant pas un cas isol. En eet, on recense au cours des
dernires annes, divers cas de piratage o une vulnrabilit matrielle permet de compromettre
l'ensemble d'un systme en crant une faille logicielle exploitable. Un exemple trs mdiatis est
celui du hacker amricain George Hotz alias geohot et ses hacks successifs de l'Iphone et de la
Ps3 [Wikipedia 2012b]. Les schmas d'attaque utiliss se trouvent dans l'exploitation logicielle
d'une mise en dfaut du matriel par perturbation lectrique [Hotz 2010]. Les consquences -
nancires de ces piratages sont estimes plusieurs millions de dollars [Kushner 2012]. Dans le
2 Chapitre 1. Introduction
milieu bancaire, ces schmas d'attaque sont connus [Rankl & Eng 2003] et pris trs au srieux
parce qu'une remise en cause de la scurit des cartes puce entranerait de graves consquences
nancires ainsi qu'une perte de conance de la part des utilisateurs. Si de telles attaques phy-
siques sont connues, se prmunir contre elles reste un d pour les personnes charges de mettre
en place la scurit. L'auteur de [Leroy 2003] donne un aperu de cette tche de scurisation et
des dicults associes en prsentant quelques eets possibles d'attaques et les contre-mesures
associes. Ce d est non seulement technique, du fait de la frontire existant entre le monde du
matriel et du logiciel qui entraine une dicult les modliser simultanment. Ce d est aussi
industriel, cause de contraintes fortes en termes de dlais prsents dans les projets raliss en
entreprise. Par consquent, dans cette thse, nous proposons d'tudier la scurit logicielle de
projets embarqus, tels que les cartes puce, en incorporant la possibilit d'attaques physiques.
Avant de pouvoir tre produites, ces cartes puce doivent d'abord tre certies. Cette
certication a pour but de garantir leur rsistance face des attaques visant compromettre
la condentialit ou l'intgrit des donnes mmorises. Cette thse s'inscrit galement dans ce
contexte de certication. D'un point de vue technique, nous nous intressons l'analyse de code
source an de :
dcouvrir de nouvelles attaques ;

mettre en place les contre-mesures appropries.
Nous cherchons fournir aux dveloppeurs des techniques et outils pour mieux scuriser leur
code et garantir la scurit des donnes sensibles manipules.
L'enjeu principal de cette thse, d'un point de vue industriel, est de permettre une meilleure
scurit des codes embarqus sur carte puce par une validation rigoureuse de ces codes contre les
attaques physiques. De plus, l'entreprise doit fournir un rapport aux organismes de certication
tels que les Critres Communs mandats par l'Agence Nationale de la Scurit des Systmes
d'Information an de garantir que des standards de scurit sont bien respects. Le respect de
ces garanties permet d'assurer que des systmes sensibles dploys grande chelle, telles que
les cartes puce, sont capables de rsister des attaques malicieuses.
D'un point de vue acadmique, le thme de cette thse se trouve entre deux domaines :
l'lectronique embarque et l'informatique. L'enjeu est de crer des ponts entre ces deux domaines
au travers d'une modlisation des eets d'attaques matrielles sur le code source du programme.
Le but de ces ponts est d'allier ces deux domaines an d'obtenir une meilleure scurit globale.
L'originalit du travail se trouve dans le point de vue adopt qui apporte une approche oriente
logicielle une modlisation physique des attaques. Ces travaux peuvent servir de point de dpart
de nouveaux axes d'approche au problme de la scurit dans le domaine embarqu. Ils peuvent
aussi permettre une intgration de nouvelles analyses des systmes logiciels de vrication
existants qui n'embarquent pas cette dimension de fautes matrielles. Avant de parler en dtail
du travail eectu, nous prsentons quelques aspects lis la scurit des systmes embarqus
et en particulier aux cartes puce.
1.1.1 Facteur d'chelle

Le contexte d'utilisation particulier des cartes puce entraine des consquences sur la scurit
de celles-ci et des considrations lies leur diusion grande chelle. Leur utilisation dans un
environnement non scuris physiquement pose aussi des problmes de scurit.
1.1. Cadre et enjeux 3
March, environnement et perspectives Le rapport [Consultants 2009] donne un bilan de

la situation actuelle sur le march mondial de la carte puce. Des perspectives d'volution et des
scnarii stratgiques sont aussi prsents. Ce rapport montre l'enjeu stratgique et conomique
que reprsente la carte puce au niveau mondial. La migration vers ce support scuris a
sensiblement contribu, au cours des 20 dernires annes, rduire la fraude bancaire lie au
paiement. Les auteurs estiment qu'avec l'mergence des technologies sans contact, les cartes
puce resteront dans les annes venir un des supports scuriss de rfrence port notamment
par les industries de tlcommunication. En eet, les cartes puce sont un moyen simple et
bas cot permettant d'intgrer une composante garantissant un haut niveau de scurit des
schmas qui ncessitent le partage d'une information (par exemple un schma d'authentication).
Nombre de cartes en circulation : eet de masse amplicateur pour la scurit La

carte puce est ainsi un mdium d'authentication largement dploy et utilis. D'aprs l'auteur
de [Avenel 2010], le nombre de cartes puce livres dans le monde a t multipli par 10 entre
2000 et 2010, passant de 540 millions prs de 5 milliards. Selon [Bodescot & Guinot 2011],
l'anne 2011 s'achve avec une hausse de 11% des ventes mondiales de cartes microprocesseur
(carte bancaire, tlphone avec carte SIM), plus de 6 milliards d'units. Les prvisions men-
tionnes dans [Avenel 2010] annoncent que le nombre de cartes livres dans le monde pourrait
tre multipli par 4 au cours des 10 prochaines annes pour atteindre 20 milliards. Ce dploie-
ment de masse amplie les risques associs la scurit et ncessite de la part des fabricants de
garder une longueur d'avance sur les capacits des attaquants. Une grande ractivit en cas de
dcouverte de nouvelles attaques est aussi requise de leur part.
1.1.2 Dportement de la scurit et environnement hostile

Le but d'une carte puce est d'assurer un certain nombre de fonctionnalits. Dans le cas
d'une carte bancaire, ces fonctionnalits consistent permettre un utilisateur d'eectuer des
transactions et de retirer de l'argent. Ces oprations ncessitent plusieurs acteurs, notamment
la banque et l'utilisateur. Le rle d'une carte est d'authentier l'utilisateur auprs de la banque
an que celle-ci valide ou non la transaction bancaire demande.
Dans ce schma d'authentication, certaines informations partages entre les dirents ac-
teurs sont dportes l'intrieur de la carte remise au porteur. Cette carte et les informations
qu'elle contient reprsente un des lments de scurit du schma. Associe une information
connue seulement du porteur et le direnciant d'un autre, une authentication du porteur et
de la carte est ralise permettant un retrait ou une transaction. La carte est donc un lment
du processus d'authentication deux facteurs pour le porteur (une information qu'il connait
et un lment physique qu'il possde).
Cependant, pour remplir son rle dans une transaction, une carte doit disposer d'informa-
tions permettant de l'identier, ainsi que son porteur, auprs de la banque. Les cartes renferment
donc des secrets appartenant la banque et par consquent n'appartiennent pas l'utilisateur
nal. De plus, an de remplir leur rle de jeton d'authentication, ces cartes doivent tre en
libre circulation et par consquent des personnes malveillantes peuvent facilement se les pro-
curer. En fait, une fois la carte sortie de l'environnement contrl d'une usine, elle se trouve
dans un environnement o chacun des acteurs peut tre considr comme hostile. Que ce soit
un utilisateur ou un commerant malveillant ou un attaquant quelconque, tous peuvent avoir
un intrt exposer des secrets contenus dans la carte ou modier son comportement. Par
consquent, chacun d'eux peut mettre en danger la scurit de la carte.
La scurit dans ces systmes d'authentication repose sur des informations sensibles conte-
nues dans un objet physique qu'une tierce personne n'est pas en mesure de compromettre. Le cas
chant, cette tierce personne sera en mesure de se faire passer pour le porteur original auprs de
la banque et aura accs aux ressources de celui-ci. Dirents autres scnarii d'attaques visant des
gains dirents sont envisageables. Certains de ces scnarii sont voqus dans la section 1.1.6.
1.1.3 Carte puce et cryptographie

L'un des principaux avantages des cartes puce est de pouvoir embarquer bas cot et
encombrement rduit des capacits de calcul leves permettant des calculs mathmatiques
sophistiqus. Ces calculs participent la scurit du systme en orant la possibilit d'intgrer
des oprations cryptographiques de chirement et de signature des schmas d'authentication.
La cryptographie tient ainsi un rle important dans le fonctionnement des cartes puce. Elle
assure notamment la condentialit des donnes enregistres dans la carte mais surtout la con-
dentialit des messages transmis entre un metteur (le porteur) et un rcepteur (la banque).
Un schma de chirement utilise une cl an de transformer le message transmettre en un
message chir. Ce message peut seulement tre dchir par un destinataire qui possde la cl
de dchirement adquate. On distingue les chirements :
symtrique ou cl prive (par exemple le des, Triple des et l'aes) qui utilise une cl com-
mune pour le chirement et le dchirement. Cette cl est partage entre l'metteur et le
destinataire et doit tre communique par un des correspondant au second correspondant.
Si un attaquant intercepte cette cl pendant cette communication, il sera en mesure de
dchirer les messages transmis entre les deux correspondants. La scurit de ce type de
chirement repose sur la non divulgation d'un secret commun entre les deux correspon-
dants.
asymtrique ou cl publique (par exemple le rsa ou les ecc voir ECC) qui utilise une
paire de cls dont l'une peut tre rendue publique. Ce type de chirement renforce la
scurit car la cl prive n'a pas besoin d'tre communique entre les correspondants. Un
attaquant, s'il connat la cl publique et est capable d'intercepter les messages chirs
entre les correspondants, n'est pas en mesure de dchirer ces messages. Cette rsistance
est due la dicult factoriser les grands nombres entiers. La scurit de ce type de
chirement repose essentiellement sur la non divulgation de la cl prive.
apport nul de connaissance (zero knowledge) qui repose sur un systme de stimula-
tion/rponse par un des correspondants pour amener l'autre correspondant fournir la
preuve de la connaissance d'une information [Goldwasser et al. 1989]. Cette mthode per-
met d'authentier un des correspondants sans communiquer d'informations sur le secret
utilis un ventuel attaquant [Quisquater et al. 1989].
Pour un change de messages chirs entre une carte et une banque, un algorithme cl
publique ncessite deux paires de cls. La carte abrite sa cl prive qui va servir dchirer les
messages chirs par la banque avec la cl publique correspondante. La carte possde aussi la
cl publique de la banque qu'elle utilisera pour chirer des messages destination de la banque.
Un chirement asymtrique peut aussi tre utilis dans un schma de signature o l'auteur
d'un message veut prouver qu'il est bien l'origine du message transmis. Dans cette congura-
tion, la carte peut gnrer une paire de cls asymtriques. Le message sera sign l'aide de la
cl prive puis transmis avec la cl publique. Un destinataire recevant le message pourra ainsi
vrier que la carte est bien l'origine du message transmis en validant celui-ci l'aide de la cl
publique.
Les algorithmes de chirement requirent, dans certains cas, (par exemple, pour le rsa) des
modules matriels additionnels capables de raliser des multiplications et des exponentiations. La
plupart des cartes puce qui utilisent des algorithmes cls publiques incorporent un cryptopro-
cesseur ddi. Une carte peut aussi embarquer un module ddi la gnration d'ala. En eet,
certains protocoles d'authentication ou des oprations cryptographiques comme la gnration
de cls condentielles ou de vecteurs d'initialisation ncessitent la gnration de nombres ala-
toires. La gnration de nombres rellement alatoires est importante en cryptographie. Parmi
ces modules ddis la gnration d'ala, les Physical Unclonable Functions ou puf sur silicium
sont des primitives cryptographiques rcentes qui utilisent les dirences physiques entre des
circuits d'architecture identique pour gnrer un code spcique chaque circuit (semblable
une empreinte digitale unique du circuit).
Le risque au niveau de la gnration de nombres alatoires apparat quand, par manque de
diversication d'un calcul, une mme valeur est constamment obtenue en sortie ou quand des
collisions apparaissent dans ce calcul (plusieurs entres donnant la mme sortie). Il serait dans
ce cas possible de remonter jusqu' un secret utilis dans le calcul. Si le nombre alatoire est
utilis pour augmenter l'entropie d'une valeur, il sera possible d'obtenir des valeurs constantes.
Si cette constante est utilise en entre d'un calcul, il serait alors encore une fois possible de
remonter jusqu' un secret utilis dans ce calcul.
Le choix d'un algorithme cryptographique dpend surtout du but fonctionnel recherch et du
schma dans lequel la carte puce est utilise. Le choix d'un algorithme particulier conditionnera
ainsi certaines caractristiques matrielles du composant.
Indpendamment du besoin fonctionnel, la cryptographie est gnralement utilise dans les
applications embarques au niveau de :
l'authentication de la carte (exemple carte SIM) ;
l'authentication du porteur (code PIN) ;
la gnration et vrication de signatures lectroniques : pour le transfert de chiers, les
certicats . . .
Ces parties sensibles sont les cibles d'attaques visant compromettre les lments sensibles
manipuls. Des travaux ont t mens, notamment sur les attaques par canaux cachs qui per-
mettent, par simple observation de la consommation lectrique ou du rayonnement lectroma-
gntique de la carte, de dduire des informations sur les donnes et secrets manipuls. Nous
aborderons la capacit d'observation d'un attaquant dans le chapitre 3.2.1.
Les implmentations cryptographiques sont aussi vulnrables aux attaques par fautes qui,
en introduisant une erreur dans l'algorithme cryptographique, peuvent compromettre celui-ci et
permettre l'attaquant de remonter aux cls utilises. La capacit d'action d'un attaquant sera
aborde dans le chapitre 3.2.2.
Le terme d'attaque par canaux cachs ou canaux auxiliaires est utilis pour qualier ces
attaques physiques sur un systme. Ces attaques exploitent des vecteurs physiques permettant
d'observer ou d'inuencer le comportement du composant lors de son fonctionnement.
Dans cette thse, nous n'abordons pas en dtail les attaques par canaux cachs sur les
parties cryptographiques. Les parties cryptographiques ne reprsentent qu'une partie du systme
expose aux attaques physiques. De plus, la scurit de l'ensemble d'un systme repose sur
d'autres lments de scurit qui sont aussi vulnrables ces attaques, en particulier aux attaques
par fautes. Nous cherchons donc, dans la suite de cette thse, caractriser les eets des attaques
par canaux cachs et montrer comment le code d'un projet embarqu peut tre sensible de
telles attaques.
Pour conclure sur l'aspect cryptographique, on peut mentionner des domaines proches comme
l'obfuscation de code ou la cryptographie en bote blanche [Joye 2008] qui sont aussi utiliss an
d'assurer la condentialit de donnes sensibles.
1.1.4 Principe de fonctionnement d'une carte

Prenons comme exemple un schma de paiement par carte bleue. Celui-ci peut se dcomposer
en 3 parties :
Authentication de la carte qui se fait hors-ligne (sans appeler la banque). Des informations
relatives au porteur (nom, numro de carte, date de validit. . . ) ainsi qu'une valeur de
signature V S sont inscrites dans la carte. La signature V S est calcule de manire dnitive
la personnalisation. Y , une valeur numrique dduite des informations crites dans la
carte (par une fonction de hachage), est d'abord calcule. Notons Y = f (inf o). V S est
alors calcule en utilisant la cl secrte S du groupement des cartes bancaires (GIE CB) :
V S = S(Y ). La fabrication et l'criture des V S sur la puce se fait dans des locaux trs
scuriss, car S doit rester secret. Lorsque la carte est introduite dans le terminal, celui-
ci lit les informations portes par la carte et la valeur de signature V S. Il calcule alors
Y 1 = f (inf o) et Y 2 = P (V S) = P (S(Y )), P tant la cl publique du GIE. Puis il compare
Y 1 et Y 2 : pour qu'une carte soit valide, il faut que Y 1 = Y 2. Ces fonctions cl secrte
et cl publique sont bases sur le rsa. Le modulo publique franais est un nombre connu
entre 768 et 1024 bits, produit de 2 premiers inconnus.
Authentication du porteur de la carte avec un secret o un secret est chir et stock

dans la puce de la carte. C'est la puce qui vrie elle-mme si le code prsent par le porteur
est le bon. Elle transmettra ensuite un jeton d'authentication au terminal prouvant que
l'authentication a russi.
Authentication en ligne qui n'est pas ralise pour toutes les transactions, mais seulement
pour celles dpassant un certain montant. Le terminal interroge la banque, qui envoie la
carte une valeur alatoire x. La carte calcule y = f (x, K), o K est une cl secrte inscrite
dans la partie illisible de la carte et f la fonction de chirement du DES (ou du triple DES
depuis 1999). La valeur est transmise la banque, qui calcule elle-mme f (x, K) et donne
ou non l'autorisation. Remarquons que ceci ncessite que la banque connaisse la cl secrte
de toutes les cartes.
VS + Infos
Authentification
Figure 1.1 Schma d'une authentication hors ligne ne ncessitant pas de participation de la
banque dans la transaction [Bayart 2012]
Envoie un nombre alatoire x
Renvoie f(x,K)
Vrifie et donne l'autorisation
Figure 1.2 Schma d'une authentication en ligne authentiant la carte auprs de la banque
au moment de la transaction [Bayart 2012]
La gure 1.1 illustre le mcanisme d'authentication de la carte dans un scnario ne nces-

sitant pas d'authentication auprs de la banque (typiquement pour des faibles montants). La
gure 1.2 illustre le mcanisme d'authentication de la carte dans un scnario ncessitant une
authentication auprs de la banque.
1.1.5 Diversit de l'cosystme

Nous avons mentionn l'intrt principal de la carte puce qui est de pouvoir embarquer
sur une plate-forme lectronique des capacits de calcul leves permettant des oprations cryp-
tographiques qui assurent la scurit de donnes condentielles. Ces plates-formes de taille et
Terminal
Authentifie(Alice)?
pin = 1234
1 2
4 3
Oui
Porteur Banque
Figure 1.3 Schma d'authentication bancaire
consommation rduites et possdant un prix peu lev, sont incorpores dans dirents schmas
d'authentication. Les cartes puce sont ainsi utilises dans de nombreux secteurs dans lequel
l'cosystme ncessite que l'utilisateur nal dispose d'un moyen de prouver sa lgitimit un
autre acteur du systme [Descamps 2000].
Le contrle d'accs dans lequel le porteur de la carte prouve par sa possession physique son
appartenance un groupe habilit accder un environnement restreint ;
Les cartes d'identit qui permettent par leur possession physique et la correspondance des
informations contenues dans celles-ci avec les caractristiques morphologiques du porteur
d'authentier celui-ci ;
La tlphonie mobile dans laquelle la puce identiera l'appareil et implicitement l'utilisateur

auprs de son fournisseur d'accs an que celui-ci l'autorise accder son rseau ;
La tlvision numrique dans laquelle la carte va permettre au consommateur nal quip

d'un dcodeur de dchirer le contenu multimdia envoy par le groupe audiovisuel an
de le visualiser ;
La carte multi-services pouvant regrouper des ores de dlisation et d'autres applications

comme par exemple des compteurs d'utilisation ;
Les cartes de paiement bancaire permettant au porteur de la carte, condition de

connaitre le PIN associ, de s'authentier auprs de la banque et de raliser des tran-
sactions.
Les deux schmas 1.3 et 1.4 illustrent l'utilisation d'une carte puce dans des cas courants o
elle intervient dans le processus d'authentication de l'utilisateur avec un autre correspondant.
Rseau
Accs accord
Terminal
pin = 1234 Authentifie(Alice)?
Oui
Porteur Fournisseur d'accs
Figure 1.4 Schma d'authentication tlphonique
Le rle d'une carte microprocesseur peut aller du simple service d'authentication jusqu'
servir de plate-forme de support pour des applications tierces comme pour les Javacards. Des
services sont connus du grand public comme les cartes Mifare d'authentication, les Passe Navigo
pour le transport, les cartes SIM pour la tlphonie, les cartes Canal+ pour la tlvision, les
cartes VISA / Mastercard et les portefeuilles lectroniques Moneo pour le domaine bancaire.
Ces exemples montrent l'intgration de cette technologie dans la vie courante et la varit de
l'cosystme li la carte puce.
Au cur d'une carte puce, comme pour tout systme embarqu, se trouve le microcon-
trleur. Parmi les direntes familles de microcontrleur utilises en embarqu, on peut citer le
8051 et ses variantes sur lequel est bas un bon nombre de cartes bancaires du march appeles.
Les cartes mobiles et d'identit, qui demandent des fonctionnalits d'interoprabilit et une ver-
satilit post production plus grande, sont plus souvent bases sur des plates-formes Java. Ces
plates-formes respectent les spcications Java Card qui dnissent un standard pour toutes les
cartes de ce type. Parmi ces plates-formes, on retrouve des plates-formes multi-applicatives telles
que OpenCard ou MultOS qui disposent dj d'un systme d'exploitation. Ces cartes orent aux
dveloppeurs des interfaces de haut niveau rendant l'accs aux services de bas niveau transparent.
Cette abstraction facilite l'implmentation rapide d'applications. L'existence de telles cartes nous
montre qu'il est dicile de dvelopper une application un niveau fonctionnel tout en grant les
contraintes de bas niveau. Ces cartes nous montrent aussi que certaines entreprises dveloppent
spciquement des applications. Ces entreprises dvelopperont ainsi une comptence uniquement
fonctionnelle et dlgueront la scurit de bas niveau d'autres spcialistes.
Pour plus de dtails sur les dirents cas d'utilisation d'une carte puce ainsi que de nom-
breuses autres informations relies au sujet, le lecteur pourra se rfrer [Bouzefrane 2009].
Cette diversit et gnralisation (tout comme le facteur d'chelle mentionn dans la sec-
tion 1.1.1) reprsentent souvent des facteurs aggravants du point de vue de la scurit et nces-
site le recours des techniques de scurisation spciques et adaptes. En eet, si compromettre
la scurit d'une carte revenait compromettre l'ensemble des cartes du mme type prsentes
en circulation, le danger pour le systme serait bien trop lev. Pour combler cette vulnrabilit,
on utilise des techniques comme la diversication, permettant, en se basant sur un identiant
unique comme le numro de srie de la carte ou un nombre gnr alatoirement, de direncier
des oprations sensibles d'une carte une autre.
La diversit des cas d'utilisation mentionns prcdemment ncessitent donc de prendre en

compte diremment la scurit dans les dirents scnarii o une carte puce est utilise.
Cependant une procdure d'valuation commune est ncessaire an de certier le respect d'un
niveau de scurit des cartes produites et aussi standardiser les attaques prises en compte dans
cette valuation.
1.1.6 Processus d'valuation de la scurit et de certication

Une fois cres et avant de pouvoir tre vendues, les cartes doivent tre certies par une
autorit de certication (en France, l'ANSSI). Cette autorit va mandater des centres spcialiss,
les CESTI, chargs d'eectuer des tests de vulnrabilit an de conrmer que certains schmas
de scurit sont bien respects sur ces cartes au moment de leur cration et leur dveloppement.
Le document [Criteria 2009] propose des exemples d'attaques (duplication de la carte, d-

couverte des secrets internes, modication de fonctionnement), des exemples d'attaquants. Il
propose aussi une classication et notation des attaques en fonction de critres comme le nombre
de cartes dtruites avant que l'attaque n'aboutisse, le temps ncessaire pour raliser l'attaque
ou les comptences de l'attaquant. Ce document classe les attaques par critres de faisabilit
et standardise une mthode an d'valuer le risque que reprsente une attaque sur un com-
posant matriel. [Eurosmart 2001] est un document similaire qui dcrit aussi bien les attaques
potentielles qu'une mthode d'valuation des cartes contre les attaques dcrites. Ces documents,
raliss par de nombreux spcialistes en scurit dans le domaine embarqu, montrent que les
attaques physiques sont des dangers bien rels et sont envisages trs srieusement surtout dans
le milieu bancaire. Ce document fait partie d'un ensemble de documents dcrivant une mtho-
dologie d'valuation de la scurit regroup sous l'appellation Critres Communs.
La dcision d'intgrer les Critres Communs comme processus d'valuation et de faire appel
des centres d'valuation indpendants ont fait suite diverses fraudes grande chelle. Parmi
celles-ci, l'aaire Humpich et sa Yes Card ont forc le gouvernement franais rvaluer
les processus de certication au niveau national. Serge Humpich avait russi contourner deux
1.2. Approche fonctionnelle et vision bas niveau 11
systmes de scurit existants : premirement il avait russi crer des cartes qui, quel que soit le
code (authentiant le porteur) prsent, renvoyait toujours code bon ; deuximement, il avait
contourn l'authentication hors ligne RSA. Comme mentionn prcdemment en section 1.1.3,
cette scurit repose sur la dicult factoriser les grands nombres entiers. Or, en 1998, l'entier
n utilis par le GIE avait une taille de 320 bits (inchange depuis 1990). Cependant, il tait
possible cette poque de factoriser des entiers jusqu' 512 bits. Humpich en utilisant un logiciel
de factorisation a ainsi russi factoriser cet entier et dcouvrir la cl secrte. Depuis la taille
est passe 768 bits. Similairement, l'authentication en ligne est passe du simple des au Triple
des lui aussi victime de l'augmentation des capacits de calcul.
En parallle des valuations de scurit menes dans le cadre des Critres Communs, des
groupements bancaires, comme le GIE CB, valuent de leur ct la rsistance des produits dli-
vrs face aux attaques physiques. Pour des hauts niveaux de scurit, les processus d'valuation
demandent la preuve formelle de garanties de scurit telles que la condentialit, l'intgrit ou
le cloisonnent de donnes. Ces preuves sont demandes an de pouvoir atteindre des niveaux de
certication de scurit recommands pour l'utilisation de cartes comme les cartes bancaires ou
les cartes passeports lectroniques.
Pour plus d'information sur les Critres Communs, les processus d'valuation associs et
leur mise en application, le lecteur peut se rfrer [CCP 2012]. Le lecteur peut aussi se rfrer
[Flottes et al. 2011] qui liste les principaux acteurs dans le domaine de la scurit embarque
ainsi que les ds existants dans le domaine et les axes de recherche actuels.
Les processus d'valuation et la recherche autour des attaques physiques conrment le danger
qu'elles reprsentent dans des secteurs aussi sensibles que le secteur bancaire. Si on dcompose
une carte puce comme un systme logiciel s'excutant sur une plate-forme matrielle, on peut
admettre que pour russir scuriser convenablement une carte, il convient de comprendre aussi
bien son fonctionnement logiciel que matriel ainsi que les moyens dont dispose un attaquant
chacun de ces niveaux pour compromettre la scurit.
Si par une attaque, il est possible de violer la condentialit d'une information, compromettre
l'intgrit d'une donne ou fausser la logique d'excution, la scurit de l'ensemble du systme
peut tre mise en dfaut. Il est donc important de s'intresser aux besoins en scurit de ce
systme et aussi leur garantie face aux attaques. An de cerner ces besoins en scurit, un
formalisme les dcrivant est ncessaire. Dans le chapitre 2, nous proposerons un formalisme
pour des proprits de scurit telles que la condentialit et l'intgrit de donnes ou l'intgrit
d'excution.
Les outils dvelopps dans le chapitre 6 visent vrier les proprits de scurit formalises.
Ils peuvent aussi tre utiliss dans une phase de validation de la scurit.
1.2 Approche fonctionnelle et vision bas niveau

Dans la section 1.2.1, nous nous intressons la fabrication des cartes puce et plus parti-
culirement au processus de dveloppement logiciel. Nous plaons le processus de certication
de scurit en perspective au sein de celui-ci. Nous parlons ensuite des dirents types de cartes,
leur communication avec un terminal et illustrons dirents cas d'utilisation. Dans un deuxime
temps, nous donnons, dans la section 1.2.2, des dtails techniques sur le fonctionnement interne
d'un microcontrleur an de dtailler l'architecture de celui-ci. Cette tape permet de mieux
comprendre l'impact des attaques physiques et leurs consquences sur le code source.
1.2.1 Fabrication et utilisation fonctionnelle
Processus de cration gnral
Le processus de cration gnral d'une carte suit 6 tapes menant son utilisation par le
porteur nal. Le rle jou par les dirents acteurs responsables de sa cration, leur comptence
propre et la chronologie de la cration sont visibles au travers de ces tapes.
Etape 1 : la conception et fabrication de la puce ;

Etape 2 : le dveloppement du logiciel embarqu ;
Etape 3 : le masquage du logiciel dans la puce ;
Etape 4 : l'assemblage de la carte puce ;
Etape 5 : la personnalisation ;
Etape 6 : l'utilisation.
Les concepteurs de la partie logicielle et la partie matrielle sont souvent deux entreprises
direntes. L'entreprise qui dveloppe l'applicatif achtera une puce un fondeur suivant des
spcications propres au produit nal demand par le client. Le produit nal, la puce embarquant
le logiciel rpondant aux besoins du client (par exemple une banque), sera ensuite livr.
Ainsi, d'un point de vue chronologique, la conception et la fabrication de la puce ont dj

t ralises par le fondeur, qui propose des composants au concepteur logiciel. Celui-ci choisit
le plus appropri par rapport au projet que souhaite le client nal. Une fois la partie logicielle
acheve, un premier masquage du logiciel sur le composant est eectu avant une production en
masse. L'assemblage de la puce avec le support plastique est ralise. Une production de masse
est ensuite lance o une phase de personnalisation congure les cartes avec des informations
propres l'utilisation nale. Les cartes sont nalement distribues aux utilisateurs.
Processus de cration logiciel
Dans cette thse, nous nous intressons la scurit logicielle d'un systme embarqu sou-
mis des attaques physiques. Par consquent, analyser le processus de dveloppement logiciel
est ncessaire. Cette analyse permet notamment d'apprhender les contraintes associes au d-
veloppement en terme de temps et de moyens ainsi que les contraintes d'intgration pour une
mthodologie de vrication de la scurit.
La gure 1.5 illustre le processus de dveloppement du logiciel embarqu dans une carte
puce. Dans ce processus, il existe deux tapes de vrication de la scurit qui interviennent
d'abord au niveau logiciel puis au niveau matriel.
Logiciel
SPCIFICATIONS DVELOPPEMENT TEST

FONCTIONNELLES LOGICIEL LOGICIEL
TEST
MASQUAGE
DE SCURIT CARTE PRTE
DU LOGICIEL
MATRIEL
Matriel
Figure 1.5 Description simplie des direntes tapes dans le processus de dveloppement
du logiciel d'une carte puce
On comprend, en regardant l'ordre des direntes tapes de ce processus, pourquoi il est

intressant d'intgrer la vrication de la scurit tt au cours de celui-ci an d'viter une
nouvelle itration de l'ensemble du processus en cas d'un chec des tests scuritaires physiques.
En eet, si les tests de scurit physique chouent, la carte ne peut pas tre produite. La phase
de test logiciel ainsi que le dploiement sur composant physique doivent nouveau tre eectus.
Cette phase inclut une mise jour du logiciel pour inclure des contre-mesures contre les attaques
dcouvertes pendant la phase de test physique. Le cycle de dveloppement doit donc reprendre
la phase de dveloppement logiciel. Cette phase termine, le composant doit tre une nouvelle
fois valu et certi contre les attaques physiques. L'ensemble de ces oprations est extrmement
coteux en temps et en ressources.
On peut voir dans les gures 1.6 et 1.7 l'avantage que reprsenterait une solution logicielle
permettant d'introduire, pendant la phase de test logiciel, des tests de scurit simulant les tests
matriels eectus plus tard dans le processus. Dplacer une partie de la phase de test mat-
riel en les simulant de manire logicielle permettrait une avance de phase dans la dcouverte
de vulnrabilits. Dans cette thse, nous cherchons en simulant les attaques physiques au ni-
veau logiciel obtenir un tel avantage. [Dutertre et al. 2009] mentionne aussi le cot lev de
la caractrisation matrielle contre les fautes physiques. Les auteurs proposent notamment une
technique de caractrisation base sur la simulation qui permettrait de rduire l'eort four-
nir cette tape. Base sur une simulation bas niveau (sur un fpga) des consquences d'une
attaque modiant la synchronisation temporelle du circuit, ils arrivent provoquer des fautes
sur des implmentations cryptographiques matrielles. Dans cette thse, nous suivons le mme
principe mais souhaitons simuler de manire purement logicielle l'ensemble des attaques par
fautes matrielles modiant la valeur de variable ou le code interprt.
Ce processus prsent ici suit un processus de dveloppement logiciel standard illustr de
manire simpli dans les schmas prcdents. Le processus de scurisation du code intervient
SPCIFICATION DVELOPPEMENT TEST

FONCTIONELLE LOGICIEL LOGICIEL
TEST
MASQUAGE
DU LOGICIEL
MATRIEL
Figure 1.6 Une simulation logicielle des tests de scurit matrielle entraine une conomie de
tests physiques plus longs et plus couteux
SPCIFICATIONS DVELOPPEMENT TEST

FONCTIONNELLES LOGICIEL LOGICIEL
TEST
MASQUAGE
DU LOGICIEL
MATRIEL
Figure 1.7 Itration prliminaire entre la phase de dveloppement et la phase de test logiciel
simpliant la phase de test matriel
souvent aprs ou en parallle des tests logiciels. Ce processus prend la forme d'une revue de
code faisant intervenir un spcialiste de la scurit et le dveloppeur applicatif charg du dve-
loppement fonctionnel. Nous prenons en compte ce double point de vue et cette sparation des
comptences dans notre approche.
Avant de nous intresser au fonctionnement interne d'un microcontrleur qui est la base
de tout systme embarqu, nous allons parler des dirents types de composants existants,
leurs dirences. Ces dirences ont un impact sur la chaine de compilation et le processus de
dveloppement. Nous verrons que certaines de ces dirences conditionnent aussi le processus
de scurisation logiciel.
Familles et types de cartes

Familles de carte puce Il existe direntes familles de cartes puce.
Les cartes mmoire simple servent de simple support de stockage ;

Les cartes mmoire avec logique cble possdent un support de stockage et sont capables
d'eectuer des oprations de logique simple ;
Les cartes microprocesseur sont des cartes possdant une mmoire programmable ainsi
que des fonctionnalits permettant des oprations logiques avances.
On s'intressera aux cartes microprocesseur dites aussi cartes intelligentes. Cette intelli-
gence vient du fait que contrairement aux cartes mmoire les cartes microcontrleur peuvent
tre programmes pour eectuer des dcisions logiques complexes.
Types de cartes On distingue aussi deux grands types de cartes qui se direncient par la
technique utilise pour communiquer avec le lecteur :
La carte sans contact, base sur une technologie RFID, ces cartes permettent de communi-
quer sans contact physique avec le lecteur. L'alimentation en courant provient nanmoins
du terminal ;
La carte contact ncessite un contact physique direct avec le lecteur au niveau du micro-
module an que l'alimentation et les commandes soient transmises.
Parmi les cartes contact, on note les cartes avec bandes magntiques ou les cartes puce
contenant un microcontrleur. Les cartes bande magntique, trs dployes, en particulier aux
tats Unis, sont simples d'utilisation mais d'un niveau de scurit plus faible par rapport aux
cartes microcontrleur. Les cartes puce sans contact voluent dans un environnement moins
scuris que les cartes contact et demandent des considrations de scurit direntes. Dans
cette thse, nous nous intresserons essentiellement aux cartes contact microcontrleur.
Les caractristiques techniques des direntes cartes puce sont regroupes en normes et
spcications. Dans la section suivante, nous prsenterons ces direntes normes et spcications
existantes qui dterminent les caractristiques des cartes puce. Ces normes et spcications
incluent des aspects de scurit intervenant dirents niveaux (protocolaire, cryptographique,
fonctionnel . . . ) ainsi qu' des moments dirents du processus de cration d'une carte (person-
nalisation, utilisation).
Normes et spcications
Normes Deux normes internationales rgissent les caractristiques des cartes puce :
ISO/IEC 14443 pour les cartes sans contact ;

ISO/IEC 7816 pour les cartes contact.
Ces normes dcrivent aussi bien les caractristiques physiques que la syntaxe des com-
mandes envoyer la carte ou les schmas cryptographiques employer. An de pouvoir tre
compatibles avec les dirents terminaux existants, les cartes doivent respecter ces normes.
Pour plus d'informations sur celles-ci, le lecteur peut consulter les rfrences [Wikipedia 2012c]
et [Wikipedia 2012d].
Spcications Au dessus de ces normes, des spcications, tablies par EMVCo pour la migra-
tion et l'interoprabilit des terminaux et cartes puce, formalisent le fonctionnement applicatif
des programmes embarqus dans les microcontrleurs. La spcication emv 4.1 est compos de
4 livres dnissant notamment les rgles respecter au niveau du protocole de communication
an d'adhrer la norme emv. Les terminaux et cartes respectant la norme emv sont compa-
tibles entre eux. La section 1.2.1 apportera plus de prcisions sur la communication entre carte
et terminal.
D'un point de vue de la scurit, [Bond 2006] montre que ces protocoles sont vulnrables
des attaques logiques. [Murdoch et al. 2010] montre qu'il est possible d'attaquer des protocoles
aujourd'hui mis en place dans l'univers bancaire en utilisant des attaques man in the middle.
Ces attaques connues dans le domaine des rseaux repose sur le fait qu'un attaquant malveillant
s'insre entre deux interlocuteurs lgitimes et parvient espionner et / ou modier l'change
entre ces interlocuteurs. Ces attaques montrent qu'il est important de s'intresser toute la
chaine de scurisation et pas seulement un point en particulier. Elles valident aussi la transpo-
sition d'attaques de domaines dirents au monde de l'embarqu. Dans cette thse, nous nous
intressons aux attaques sur le code source embarqu dans les cartes puces. Cependant, nous
ne nous focalisons pas sur les particularits protocolaires ou cryptographiques de ces codes, nous
considrons tout code comme une implmentation d'un objectif fonctionnel qui peut tre mis en
dfaut.
Communication avec une carte

Avant d'aller plus loin, nous introduisons quelques termes utiliss dans la communication
entre une carte et un lecteur. Tout d'abord le terminal permet de communiquer avec la carte et
de lui envoyer des instructions sous forme de commandes. Chacune de ces commandes remplit
un objectif particulier contribuant un objectif nal. L'ensemble de ces commandes constitue
une transaction dbutant au moment o la carte est alimente et s'achevant lorsqu'elle ne l'est
plus. Une transaction permettra l'utilisateur de la carte d'eectuer une plusieurs tches
ncessaires pour remplir l'objectif premier de la carte, par exemple s'authentier auprs d'un
organisme pour prouver son identit et autoriser une demande.
An de communiquer avec une carte, on doit disposer d'un lecteur. Ce lecteur sert d'interface
entre la carte et le terminal ; il va transmettre des commandes la carte en respectant un certain
protocole. Le dialogue se fait par trames de communication appeles APDU. Les standards
ISO/IEC 7816 ou ISO/IEC 14443 et la norme emv dnissent les commandes envoyer pour
tablir la communication entre le terminal et la carte. Deux protocoles existent :
T=0 est le plus utilis et utilise une transmission de donne par caractre ;
T=1 est moins utilis, il utilise une transmission de donne par blocs structurs.
Ces protocoles sont dcrits en dtail l'intrieur de la norme ISO 7816-3.
L'amorce d'une connexion entre la carte et le terminal se fait par une rponse un signal
lectrique mis sur le contact RST du micromodule. La carte renvoie une rponse normalise
ainsi que les informations ncessaires au terminal pour tablir la communication (par exemple :
la vitesse d'change).
Une session de communication correspond un change de trames entre le terminal et la

carte. Le terminal utilisera plusieurs commandes an de dclencher certaines actions. La liste
ci-dessous rsume les principales tapes de la transaction :
1. Application selection
2. Initiate application processing
3. Read application data
4. Processing restrictions
5. Oine data authentication
6. Cardholder verication
7. Terminal risk management
8. Terminal action analysis
9. First card action analysis
10. Online transaction authorisation
11. Second card action analysis
12. Issuer script processing
Ces tapes se traduisent en un certain nombre de commandes qui peuvent tre envoyes la
carte :
Power On le terminal carte fournit du courant la carte et commence le processus d'initiali-

sation. La carte rpond par un Answer To Reset ;
Select Application le terminal slectionne une application ;

Get Processing Options le terminal demande des informations la carte sur son contenu
ainsi que des donnes fonctionnelles pour le reste de la transaction ;
Read Record le terminal va lire aux endroits appropris dans le systme de chier des infor-
mations supplmentaires sur l'application slectionne ;
Get Challenge le terminal demande la carte un nombre alatoire la carte pour diversier
ou chirer une opration future ;
Internal authenticate authentie l'application pour que le terminal puisse accder des don-
nes sensibles de la carte ;
Verify Pin le porteur est authenti auprs de la carte ;

Generate Application Cryptogram un cryptogramme d'autorisation est gnr et la tran-
saction nalise.
Pour plus de prcision sur le fonctionnement et les dtails de chaque tape, le lecteur pourra
se rfrer la norme emv. Une explication simplie peut aussi tre trouve dans le docu-
ment [Bouzefrane 2008]. Pour rsumer, on peut dire que ces commandes dcomposent un change
permettant une authentication de la carte et du porteur dans une transaction dcrite dans la
section 1.1.4.
Depuis son apparition, le protocole emv a t la cible de nombreuses attaques. Dirents

points de vulnrabilit du protocole peuvent tre trouvs la rfrence [Wikipedia 2012a].
Ce protocole sert aussi de point d'entre de nombreuses attaques de type logi-
ciel. [Bond & Anderson 2001] et [Buetler 2008] montrent deux types d'attaques pouvant arriver
au niveau protocolaire compromettre la scurit en utilisant des approches direntes. En
envoyant des squences de commandes dans le dsordre ou en espionnant les trames d'change,
un attaquant peut mettre en vidence des vulnrabilits au niveau logiciel. Une autre approche
est adopte par [Lancia 2011] o une technique de fuzzing est utilise contre les paramtres
des commandes envoyes an de faire ressortir des vulnrabilits dans le code implmentant le
protocole.
Ces approches montrent qu'au niveau protocolaire, l'implmentation est source de vulnra-
bilit et qu'il est ncessaire de disposer de techniques et d'outils an de vrier cette implmen-
tation logicielle contre les dirents types d'attaques existants.
Une des dicults mettre en place une solution et des outils permettant une vrication
gnrique de la scurit provient de la diversit des composants utiliss et donc des chaines de
compilation utilises en embarqu.
Chaine de compilation et gnricit

Les fondeurs peuvent fournir leur propre chaine de compilation et environnement de d-
veloppement ou s'appuyer sur des environnements existants tels que KEIL. Ils peuvent aussi
choisir d'implmenter des instructions spciales pour leur composant, d'adopter un agencement
mmoire particulier ou de supporter des optimisations spciques. A cause de ces dirences, il
est dicile pour le dveloppeur et la personne charge de la scurit de trouver une mthode
gnrique applicable sur l'ensemble des composants pour scuriser leur application. Cependant
l'ensemble de ces fondeurs supportent gnralement l'ensemble du standard C ANSI. Ainsi,
il est plus facile d'incorporer des scurits au niveau du code source avant la compilation par
l'environnent spcique au fondeur. Les scurits logicielles incorporer demandent de la part
des spcialistes en scurit une premire phase d'valuation du composant face aux attaques
physiques. La rsistance du composant cette phase d'valuation dnira le besoin de renfor-
cer la scurit au niveau logiciel. Souvent, pour des raisons de cot, des composants avec peu
de dfenses matrielles sont choisis et une grande partie de la scurit est dlgue au niveau
logiciel.
1.2.2 Fonctionnement interne

Aprs avoir parl des tapes de fabrication d'une carte, nous allons nous intresser son
fonctionnement interne an de mieux comprendre comment une attaque physique peut aecter
le fonctionnement logiciel.
Registres
R R
E E
Vcc ADDR G G RAM
DATA 1 2
Clock CPU CTRL
ROM
IO BUS
EEPROM
Glue logique Memoires
Architecture interne d'une carte puce
Figure 1.8 Schma simpli d'une carte
Composants essentiels d'une carte puce

Une carte puce est physiquement compose de trois lments :
La carte plastique ;
Le micromodule ;
La puce.
La carte plastique est le socle physique de base de la carte. Sur celle-ci se trouve la puce
en elle mme qui contient les donnes et le programme excuter. La puce se trouve sous le
micromodule seule partie visible depuis l'extrieur et dont les contacts servent d'interface avec
le lecteur.
La gure 1.8 montre un schma simpli de la carte en faisant apparaitre les dirents
composants entrant en jeu : les composants mmoires, les bus et le microprocesseur.
Caractristiques techniques d'une carte puce

Dans cette section, nous allons parler des caractristiques d'une carte puce. Nous allons
passer en revue les dirents composants physiques et expliquer leur fonctionnement. Dans un
deuxime temps, nous prendrons l'hypothse d'une attaque physique et observerons les cons-
quences de celle-ci sur le fonctionnement de la carte.
Architecture d'une carte microprocesseur Une carte ressemble schmatiquement la

gure 1.9.
Dans la gure 1.9 on peut voir les dirents composants matriels formant une carte.
On distingue les dirents blocs matriels internes :
Interfaces externes ;
Alimentation et horloge ;
Unit centrale et microprocesseur ;
Les direntes mmoires externes rom/ ram/ eeprom ;
Le bus interne de communication.
Chacun de ces lments peut servir de cible une attaque physique. Ces vecteurs d'attaque
sont des moyens pour l'attaquant d'inuer sur le systme : ils font souvent partie des prrequis
Vcc Vcc
Logique
Mmoire Mmoire
d'horloge Unit
morte vive
et de centrale
ROM RAM
reset
Bus
Interface Mmoire
srie EEPROM
Vss Vss
Figure 1.9 Schma d'une carte [Consultants 2009]
ncessaires au bon fonctionnement de l'architecture du microcontrleur ou d'un des composants

cls responsables d'une tche spcique ncessaire l'ensemble de la carte.
Interfaces externes Les interfaces externes permettent la carte de communiquer avec le

terminal. Elles alimentent aussi celle-ci et fournissent les signaux lectriques responsables des
changements lectriques au sein de la puce. Ces changements lectriques et leur synchronisation
sont la base de tout change d'information et de logique du systme.
On retrouve sur le micromodule les plaques de contact donnant accs aux fonctionnalits
mentionnes ci-dessous.
Figure 1.10 Illustration du micromodule
(1) Vcc le signal de l'alimentation en courant externe

(2) RST le signal de redmarrage de la carte

(3) CLK le signal d'horloge externe (beaucoup de composants disposent maintenant d'une
horloge interne permettant de s'aranchir d'un signal externe pouvant introduire des pro-
blmes de scurit
(4) et (8) RFU congurable suivant l'utilisation

(5) GND la masse
(6) Vpp la tension de programmation
(7) I/O le signal d'entre sortie qui sert encoder les messages en provenance ou en direction
du terminal
L'alimentation est facilement accessible par un attaquant qui peut brancher une alimentation
dont il contrle le voltage. En alimentant la carte avec un voltage excdant le seuil admis pour le
fonctionnement de la carte, un attaquant peut esprer perturber le fonctionnement de celle-ci
son avantage. Il existe aussi un risque permanent que l'alimentation de la carte soit coupe tout
moment eaant ainsi toutes les donnes en mmoire volatile et interrompant les oprations en
cours ou des critures de donnes qui auraient d avoir lieu. Le squencement des commandes
et la manire dont celles-ci sont implmentes est donc trs important si on veut garder une
cohrence des donnes mais aussi une cohrence scuritaire du systme. Des mcanismes sont
donc responsables du respect de l'intgrit des donnes en cas de coupure de courant. Il est
cependant ncessaire de vrier l'intgrit scuritaire du systme. Des capteurs de sous-tension
et de surtension sont maintenant mis en place pour se protger contre de telles attaques.
L'horloge constitue aussi un vecteur d'attaque de choix pour un attaquant. Une lecture ou
criture est gnralement synchronise sur le front montant ou descendant d'une horloge. A ce
moment prcis, la valeur prsente sur un ou plusieurs bus sont lus an d'tre transmise. Ainsi
en ralentissant ou acclrant l'horloge, un attaquant peut esprer fausser la valeur qui sera
transmise. La plupart des composants rcents embarquent une horloge interne pour se protger
contre de telles attaques.
Les donnes de la carte sont transmises et reues par l'entre I/O. Un attaquant externe, du
point de vue de la carte, est capable d'observer, de contrler ou de modier les donnes transitant
sur cette entre. On estime donc qu'il est capable de choisir les commandes envoyes la carte.
Cette position lui permet de monter des attaques dites logiques en exploitant l'interface d'entre
I/O. Ces attaques logiques sont la base des attaques contre le protocole mentionnes dans la
section 1.2.1. Certaines des attaques mentionnes dans [Criteria 2009] sont les attaques logiques
qui exploitent des failles existantes dans l'implmentation faite des spcications. Si ces attaques
ne ncessitent pas d'induire d'erreurs au niveau matriel, une perturbation physique peut tre
considre comme un facteur aggravant qui, combine aux attaques logiques, peuvent mettre
jour de nouvelles vulnrabilits.
On notera aussi les attaques par dcouverte de fonctions de test oublies par le dvelop-
peur. L'attaquant enverra toutes les suites possibles de commandes la carte en esprant que
celle-ci rponde lors d'une commande non spcie. Il aura ainsi dcouvert une nouvelle entre
logicielle pouvant potentiellement lui servir de vecteur d'attaque. On remarque l'intrt des m-
thodes formelles dans ce contexte permettant de prouver, notamment dans les protocoles de
communication, que ceux-ci sont exempts de failles scuritaires.
Dirents types de mmoire Dirents types de mmoire cxistent sur un composant em-
barqu. Le mode de rtention de l'information, caractristique principale de chacune d'elles,
conditionne la mcanique interne (logique et matrielle) de ce type de mmoire. On distingue
les mmoires non volatiles (eeprom), des mmoires volatiles (ram). Leur utilisation permet la
mmorisation d'informations pour une utilisation future. L'intrt pour l'attaquant ainsi que
le procd d'attaque sont dirents suivant le type de mmoire implique dans l'opration ma-
trielle attaque. Les eets des attaques auront une dure plus ou moins longue si la variable
aecte est crite en eeprom ou en ram. On peut aussi noter que certaines informations sont
crites de manire dnitive en rom dans la carte au moment de sa fabrication.
De manire gnrale, les critures fonctionnelles en eeprom qui interviennent au cours de la
transaction sont critiques pour le bon fonctionnement scuritaire de la carte. Ainsi, les interfaces
de lecture et d'criture en mmoire eeprom sont des positions d'attaque privilgies. Dans le
cas d'une mise jour d'un compteur de scurit, par exemple le nombre d'essais du code PIN,
russir empcher la mise jour de ce compteur en empchant son criture reprsente un gain
pour l'attaquant.
Les mmoires volatiles contiennent des donnes dont la dure de vie est conditionne par
l'alimentation en courant du microcontrleur. En cas de coupure, les informations contenues
dans cette mmoire sont perdues. Certaines variables globales peuvent cependant avoir une dure
de vie dpassant la dure d'un change APDU. Celles-ci peuvent tre utilises pour conserver
une information temporaire, ncessaire au long d'une transaction, mais ne demandant pas une
criture en mmoire eeprom en vue d'une utilisation future.
Les interfaces matrielles et logicielles manipulant la mmoire dans un contexte de scurit
sont donc trs sensibles et doivent tre scurises contre les attaques par fautes. Dans un avenir
proche, la gnralisation de la mmoire flash dans les composants embarqus de type carte
bancaire apportera de nouveaux ds de scurit.
Les moyens la disposition des attaquants pour perturber le matriel sont donc nombreux.
Ils reposent essentiellement sur un apport d'nergie supplmentaire et localis une partie du
circuit. Un apport de lumire, une perturbation du courant lectromagntique, une hausse de
la temprature peuvent tre utiliss pour modier le comportement du logiciel interprt sur le
matriel attaqu. Nous traiterons en dtail, dans la section 3.2.2 du chapitre 3, des capacits
d'action des attaquants leur permettant de perturber les composants matriels notamment les
mmoires.
Architecture Harvard vs Von Neumann Dans ce paragraphe, nous discutons de l'archi-

tecture mmoire utilise pour transmettre des informations stockes en mmoire volatile ou non
volatile jusqu'au microprocesseur o elles doivent tre interprtes. Par dfaut, un microcontr-
leur 8051 adopte une architecture Harvard, c'est--dire que le code et les donnes proviennent
de deux espaces mmoires dirents (rom et rameeprom). L'architecture peut cependant tre
modie pour adhrer l'architecture Von Neumann o le code et les donnes proviendront du
mme espace mmoire. Des donnes seront ainsi interprtes comme du code. Un tel changement
permet de charger du code excutable dans une zone mmoire programmable (eeprom) et non
dans une zone en lecture seule comme la rom. Cette fonctionnalit peut tre utilise pour char-
ger du code excutable a posteriori de la cration de la puce. En eet, une fois le code embarqu
en rom celui-ci ne peut plus tre modi.
Un fonctionnement qui respecte l'architecture Von Neumann peut poser des problmes de
scurit au moment du chargement du code excutable. Le fait que du code excutable peut tre
interprt pendant la phase d'utilisation de la carte permettrait un attaquant, s'il arrivait
charger du code malicieux, de crer une faille de scurit. De plus, avec une double attaque, il
pourrait la fois exploiter une faille dans le code original et en mme temps contourner le
code correctif rajout.
Types de plates-formes embarques On distingue deux types de plates-formes sur les-

quelles sont bases les cartes puce :
Les plates-formes natives Dveloppes en C, elles coutent relativement peu cher et leur prin-
cipal avantage est leur rapidit. Elles sont beaucoup utilises dans le systme bancaire et
ont une architecture monolithique qui ne permet pas l'ajout de nouvelles applications une
fois dployes.
Les plates-formes ouvertes Souvent dveloppes en Java leur principal avantage est une
grande interoprabilit / portabilit sur la base d'une machine virtuelle et d'applets Ja-
vacard. Leur dsavantage rside dans le fait qu'elles sont plus onreuses ainsi que plus
lentes.
Par la suite, nous traiterons spciquement des plates-formes natives qui est le sujet principal
de cette thse. Cependant, certains rsultats thoriques obtenus peuvent s'appliquer sur tout
systme embarqu base de microcontrleur.
Systmes d'exploitation Le systme d'exploitation est une partie importante d'un systme
embarqu. Ce systme est construit selon une architecture logicielle donnant accs aux capa-
cits matrielles du composant. Cette architecture structure fournit des services gnriques
ncessaires au bon fonctionnement logiciel de la carte. Parmi celles-ci, on peut citer :
Le systme de chier responsable de l'agencement des informations en mmoire eeprom, ce

systme de chier est construit autour de dossiers contenant les informations d'une mme
application et de chiers, des conteneurs unitaires pour ces informations ;
Les briques cryptographiques qui fournissent des services de chirement, dchirement, si-
gnature mentionns dans la section 1.1.3 ;
Les mcanismes de journalisation responsables de l'intgrit des processus d'criture en ee-

prom en utilisant une criture dire dans une zone mmoire tampon ;
Les mcanismes d'erreurs responsables de la gestion des erreurs logicielles ou matrielles

qui peuvent apparatre dans un contexte fonctionnel normal et fournissant au terminal les
informations sur le contexte et ventuellement l'origine de l'erreur.
Le choix de l'architecture logicielle et l'intgration de la scurit au moment de la conception

du systme d'exploitation sont particulirement importants an de garantir une scurit contre
les attaques physiques travers l'ensemble du systme.
Microcontrleurs
La base lectronique d'une carte puce est le microcontrleur. Dans cette section, nous
dtaillerons son architecture interne an de comprendre comment interagissent les direntes
parties matrielles et comment une attaque peut russir les perturber.
Architecture dtaille Un microcontrleur est compos d'un microprocesseur et de m-

moires. Le microprocesseur peut tre dcompos en une unit de calcul (UC), une unit arithm-
tique et logique (UAL) ainsi que des registres dont l'accumulateur ACC et les registres d'tats
(C,AC,S,O,Z,P). Des registres spciaux SFR sont ddis au contrle des priphriques raccords
au microcontrleur.
Figure 1.11 Architecture interne du microprocesseur [Litwak 1999]
La gure 1.11 illustre les composants internes du microprocesseur. On distingue les dirents
lments responsables de l'interprtation du code.
L'UC, responsable de l'excution du code programm en mmoire rom, suit un fonctionne-
ment en 4 tapes :
Fetch l'instruction excuter est charge depuis un registre spcique, le registre d'instruction
RI ;
Decode l'instruction est dcode par rapport au jeu d'instructions du composant ;

Exec cette instruction est ensuite excute entrainant les modications correspondantes dans
le reste du systme ;
Prep Next nalement, la prochaine instruction est prpare ce qui quivaut dplacer le cur-
seur de lecture du code du programme en rom.
Attaquer une de ces tapes peut avoir un eet sur le code qui sera excut. L'UC fonctionne
aussi avec l'aide de l'UAL responsable des oprations arithmtiques (addition, soustraction,
multiplication ou division) et logiques (et, ou, ngation logiques) dont a besoin le programme
pour eectuer des calculs ou des combinaisons logiques. Attaquer directement l'UAL pourra avoir
des consquences sur le rsultat d'un calcul ou une dcision logique. De mme, les consquences
de l'attaque d'un registre dpendra de son utilisation. En eet, modier un registre contenant la
valeur intermdiaire d'un calcul changera le rsultat de ce calcul. Alternativement, modier un
registre d'tat inuencera une instruction suivante comme, par exemple, un saut conditionnel
qui se base sur cet tat pour prendre une dcision.
Mmoires Les mmoires correspondent des cellules capables de retenir un tat lectrique.
Ces cellules sont regroupes en cases mmoires dont la taille dpend de l'architecture et qui
peuvent contenir une information.
La ROM contient le code du programme ainsi que les donnes permanentes de celui-ci. L'index
permettant de parcourir cette mmoire est le Program Counter (PC). La taille standard
de la rom sur un 8051 est de 4K ;
La RAM contient les donnes du programme l'excution, la pile accessible par le Stack
Pointeur (SP) et 32 registres d'un octet chacun. Les 128 octets de la ram peuvent tre
adresss en utilisant le Data Pointeur (DPTR) d'une longueur de 16 bits ;
L'EEPROM contient les donnes permanentes modiables du systme. On y accde gnrale-

ment l'aide d'un systme de chiers.
Attaquer ces direntes mmoires peut avoir un eet dirent suivant leur type et l'utilisation
qui en est faite par le programme. On peut noter que la ram reste alimente dans un scnario
normal tout au long de la transaction. Ainsi, les informations rsidant en ram, si elles sont
perturbes, auront un eet qui peut perdurer jusqu' la n de la transaction. Modier une
donne crite en eeprom aura un eet qui ne se limite pas une simple transaction mais peut
inuencer les transactions futures. Des informations sensibles concernant l'tat de la carte sont
gnralement gardes en eeprom. Attaquer ces informations au moment de leur criture en
eeprom peut tre avantageux pour un attaquant. C'est pourquoi les interfaces d'criture en
eeprom (ainsi que les interfaces de lecture) doivent tre soigneusement scurises contre les
attaques physiques. Les contre-mesures visant dfendre l'intgrit des informations stockes
en eeprom sont souvent bases sur des mcanismes de hachage tels que des checksums. Ces
checksums sont calculs et sauvegards en eeprom en mme temps que les informations sensibles
s'y trouvant et vris aprs chaque criture.
Bus Les bus sont des points d'attaque privilgis par les attaquants qui utilisent les fautes
physiques. En eet, les bus se trouvent la priphrie des zones mmoires facilement recon-
naissables sur les composants. Ces zones de transfert d'information sont donc cibles par les
attaques physiques car elles sont faciles localiser sur la puce et prsentent un gain lev pour
l'attaquant.
La gure 1.12 montre les dirents composants mmoire d'un microcontrleur. On distingue
nettement les direntes zones mmoires ainsi que le microprocesseur. Les bus se trouvent la
limite des zones mmoires.
On distingue 4 types de bus :
Le bus de donnes de 8 128 bits, ce bus bidirectionnel permet la communication entre l'UC
et la mmoire en passant par le RI, l'ACC ou les registres ;
Figure 1.12 Vue d'une puce et des dirents composants mmoire [Guilley 2007]
1.3. Besoins en scurit 27
Le bus d'adresse sur 16 bits, ce bus unidirectionnel permet l'UC de spcier des adresses
aux registres ;
Le bus de contrle ou de commande bidirectionnel, il met en relation l'UC et les mmoires

au travers de commandes de lecture et d'criture ;
Le bus interne du microprocesseur met en relation l'UC, l'UAL, l'ACC, les registres, les
mmoires tampons du microprocesseur et le bus de donnes.
Attaquer ces bus aura pour eet de perturber les valeurs de variables crites dans les di-
rentes zones mmoires. L'eet peut aussi fausser un calcul ou faire en sorte qu'un code dirent
soit interprt par le composant. Ainsi attaquer le bus de donnes au moment du Fetch aura
une consquence sur l'instruction dcode et excute. Attaquer ce mme bus un autre mo-
ment pourra avoir un eet dirent ou ne pas avoir d'eet. Certaines attaques peuvent aussi
tre quivalentes d'un point de vue matriel. Ainsi perturber un bus lors du Fetch aura pour
consquence qu'une valeur fausse sera charge dans le RI. Cependant perturber directement le
RI pourra avoir le mme eet.
La comprhension des mcanismes de fonctionnement interne d'un microcontrleur sont n-

cessaires pour valuer au niveau logiciel les consquences d'une attaque.
1.3 Besoins en scurit

Aprs avoir expliqu les mcanismes de fonctionnement interne du matriel sur lequel s'ex-
cute le code d'une carte puce, nous proposons d'aborder les besoins en scurit. Nous avons
montr qu'attaquer physiquement un composant peut perturber l'excution du programme,
voyons maintenant comment des attaquants ont su tirer prot de ces attaques pour crer et
exploiter des vulnrabilits logicielles et pourquoi il est ncessaire de s'en protger.
1.3.1 Historique de la scurit des cartes

Les attaques sur carte puce ont fortement volu depuis leur apparition. La puis-
sance de calcul disponible aujourd'hui force l'utilisation de cls de chirement de tailles tou-
jours plus grandes. De nouveaux algorithmes cryptographiques (RSA, AES, courbes ellip-
tiques) ont t dploys sur celles-ci. Des attaques de plus en plus sophistiques ont fait
leur apparition [van Woudenberg et al. 2011] tandis que les constructeurs et les dveloppeurs
cherchent des moyens de plus en plus ingnieux an de scuriser leur code au niveau mat-
riel [Guilley et al. 2008] comme au niveau logiciel [Guilley et al. 2010].
La carte puce, invention de Roland Moreno et Michel Ugon en 1974 a cependant su s'im-
poser comme l'lment cl de la scurit de nombreux systme d'authentication. En tant que
tel, elle a subi de nombreuses attaques depuis sa cration jusqu' aujourd'hui.
1996 A la confrence Usenix, les attaques sur les cartes puce sont abordes an de montrer
que leur scurit peut tre compromise et donc que les systmes bass sur celles-ci peuvent
tre mis en danger [Anderson & Kuhn 1996] ;
1996 Les premires attaques par canaux cachs sont mises en uvre sur des algorithmes
cryptographiques en exploitant des informations acquises en mesurant les temps d'ex-
cution [Kocher 1996] ;
1997 Les premires attaques concrtes sont dcrites ;
2000 L'aaire Serge Humpich en France et la clbre Yes Card permet de faire croire un
terminal que la carte renvoie une rponse correcte une demande d'authentication. Une
explication de l'attaque peut tre trouve la rfrence [Cortier 2005] ;
2000 En parallle, la confrence Usenix, de nombreuses attaques sont envisages o la carte

puce est utilise comme vecteur de vulnrabilit [Gobio et al. 2000] ;
2003 Les premires attaques optiques sont dcrites ainsi que leur application dans le but de
compromettre la scurit des cartes puce [Skorobogatov & Anderson 2002] ;
2010 Christopher Tarnovsky la confrence Black Hat montre un exemple d'attaque inva-
sive ainsi que les possibilits de mettre nu une carte puce et de la retro ingnie-
rer [Tarnovsky 2010] ;
2010 En parallle, Ross Anderson Cambrige dcrit diverses attaques contre le protocole qui
rgit les changes entre les terminaux et les cartes [Murdoch et al. 2010].
La progression de ces attaques montre que les attaquants sont capables d'voluer pour trouver
de nouveaux moyens de perturber les systmes base de carte puce. Ceux-ci empruntent des
chemins de plus en plus indirects et complexes pour provoquer des erreurs et exploiter des
vulnrabilits rsultantes. C'est pourquoi scuriser indpendamment les direntes parties d'un
programme embarqu ne permet pas d'assurer la scurit de l'ensemble de celui-ci. Considrer
le systme dans son intgralit en tablissant et en validant une politique de scurit cohrente
sur la totalit du systme est ncessaire pour djouer ces attaques.
1.3.2 Attaques physiques

Dans cette section, nous prsentons l'architecture d'un microcontrleur dans l'hypothse
d'une attaque physique. Les composants matriels de l'architecture d'un microcontrleur sont
ainsi passs en revue. Ce chapitre se termine par le classement de ces attaques en catgories
pertinentes vis--vis de leur modlisation et plus tard de leur simulation.
Les attaquants ont des comptences direntes. De l'utilisateur nal, sans comptence infor-
matique, aux organisations criminelles, disposant d'une quipe d'ingnieurs l'expertise leve
et de moyens consquents, comme par exemple des FIBs, en passant par l'tudiant en lec-
tronique, disposant des moyens oerts par son universit, des attaquants aux comptences et
moyens varis vont s'attaquer aux dfenses des cartes et chercher les compromettre.
La gure 1.13 montre un environnement matriel permettant de monter des attaques phy-
siques sur une carte puce l'aide d'un laser.
Caractrisation des attaques On peut classier les attaques suivant le procd utilis pour
les mettre en uvre. Ainsi, on distingue des attaques :
Passives qui ne ncessitent pas de modier physiquement la carte ou la puce ;

Semi invasives qui ncessitent une modication physique non destructive de la carte ou de la
puce ;
Invasives qui ncessitent une modication destructive de la carte ou de la puce.

Figure 1.13 Banc d'attaque laser, source : Oberthur Technologies
Dans cette thse, on s'intresse aux attaques semi invasives ou invasives de type attaque par
pulse laser. L'approche adopte permet cependant de modliser toute attaque crant une faute
logicielle.
[Bar-El 2003] mentionne des exemples d'attaques classes suivant des catgories similaires :
invasives et non invasives. L'auteur donne des dtails sur la zone mmoire implique dans une
attaque. Ces dtails montrent que les attaques documentes dans la littrature ciblent l'ensemble
des mmoires existantes mentionnes dans le paragraphe 1.2.2.
On peut regrouper diremment les attaques en deux grandes catgories selon que leurs
consquences logicielles aectent une information ou le code la manipulant. On peut ainsi dis-
tinguer les attaques qui aectent les valeurs des variables des attaques qui aectent la logique
du programme comme les conditions ou les boucles. Dans cette thse, nous adoptons une telle
classication tant donn que cette reprsentation se prte mieux au travail de modlisation que
nous souhaitons mener.
Principe gnral Les attaques visent compromettre la carte en permettant la divulgation

d'informations secrtes (par exemple, des cls de chirement), la remise en cause de l'intgrit de
certaines donnes (par exemple des compteurs d'essais ou mme les cls de chirement), la remise
en cause de l'intgrit du fonctionnement de la carte (par exemple, un dni de service, mais aussi
un changement de comportement) ou le rejeu (une fois certaines informations acquises, il est

possible de crer un clone de la carte). Le but de ces attaques est la gnration d'argent ou le
vol d'identit. Il se rsume par une lvation de privilge pour l'attaquant.
Moyens d'attaque Les vecteurs d'attaque sont nombreux : la temprature, les modications
temporelles, de courant, l'utilisation de radiation ou de lumire. De nombreux facteurs physiques
peuvent ainsi tre exploits pour crer une faute logicielle. On notera aussi qu'un attaquant, s'il
peut contrler l'environnement dans lequel une transaction est eectue, peut facilement arra-
cher la carte du lecteur en coupant brutalement son alimentation. Cette coupure aura pour eet
d'arrter l'excution du code et ventuellement de dclencher certaines scurits. Un attaquant
peut exploiter cette coupure pour ritrer ses tentatives d'attaque. Pour parer cette ventua-
lit, la journalisation des rponses scuritaires doit tre soigneusement prise en compte lors du
dveloppement.
1.3.3 Problmatique globale

Face aux besoins de scurit exprims dans les sections prcdentes, dirents moyens de
scurisation doivent tre mis en place. Ces moyens de scurisation doivent tre capables de
couvrir l'ensemble du systme. En eet, sur un systme impliquant plusieurs briques logicielles,
la scurit est soumise au problme du maillon faible, c'est--dire qu'elle repose sur la rsistance
de l'lment le moins scuris.
L'architecture logicielle d'un systme embarqu est gnralement compose de direntes

couches logiques (bios, systmes d'exploitation, applications, briques cryptographiques). Ces
couches logiques sont assembles de manire accomplir les direntes tches fonctionnelles
demandes par les spcications. Ces tches fonctionnelles dcrites dans les spcications appli-
catives sont traduites en un programme qui doit s'excuter sur une plate-forme matrielle. Or,
tout systme dcompos de cette manire est soumis une problmatique de visibilit. Certaines
de ces couches vont abstraire la complexit des oprations sous-jacentes et proposer d'avoir accs
au service par le biais d'interfaces de programmation. On notera aussi que ces dirents services
sont gnralement dvelopps par des personnes direntes, ce qui augmente le risque de voir
apparatre des erreurs au niveau des interfaces.
Du point de vue de la scurit, cette sparation architecturale entre les dirents blocs de
services entraine une diminution dans la visibilit scuritaire globale du systme. De plus, ces
blocs peuvent avoir des considrations en scurit direntes. Tel bloc ne devra pas laisser fuir
d'informations condentielles tandis qu'un autre bloc devra tre scuris en terme d'intgrit.
Ce manque de visibilit et cette htrognit de la scurit sur l'ensemble du systme rend le
travail de la personne en charge de la scurisation plus dicile.
Il convient par ailleurs de considrer la scurit de l'ensemble du systme et pas seulement

certains services rputs sensibles. Par exemple, si un mcanisme de chirement existe dans
un bloc cryptographique de bas niveau mais qu'une fonction de haut niveau ne l'utilise pas ou
l'utilise incorrectement an de chirer des donnes sensibles, c'est la scurit de l'ensemble du
systme qui peut tre compromise. De plus, dans le cas d'attaques par faute, il faut aussi s'assurer
que le service appel est correctement excut (que les donnes sont bien chires). Les interfaces
de programmation de lecture et d'criture (boucle de lecture dans un tableau) constituent un
autre exemple de point d'attaque. Si celles-ci sont compromises, il serait possible de transfrer
des informations condentielles de la mmoire vers l'extrieur de la carte. Finalement, supposons

qu'il soit possible pour une application de tlphonie mobile d'accder aux ressources ou donnes
d'une application bancaire, les donnes condentielles de celle-ci pourraient tre compromises.
Ces exemples mettent en vidence le besoin d'tablir des proprits de scurit an d'exprimer de
manire formalise les besoins en scurit d'un systme embarqu. La condentialit, l'intgrit,
la bonne excution ou le cloisonnement de certaines donnes pourront alors tre vris. Dans
le chapitre 2, nous proposons une formalisation de certaines de ces proprits de scurit.
Les scnarii de cration d'une vulnrabilit par l'injection d'une faute physique et le procd
permettant d'exploiter celle-ci pour obtenir un gain pour l'attaquant sont ce que nous nommerons
chemins d'attaque. De nombreux chemins d'attaque existent suivant les tches que doit accomplir
le programme et l'implmentation qui en est faite. Dans le chapitre 5, nous utiliserons cette
notion en nous plaant dans un scnario fonctionnel donn et en cherchant exhaustivement par
la simulation de fautes physiques obtenir un gain fonctionnel.
1.3.4 Proprits de scurit

Les proprits de scurit, sur des systmes embarqus, o la scurit joue un rle prdomi-
nant, doivent tre exprimes en fonction d'aspects fonctionnels du systme. En eet, une partie
de la scurit est intgre dans des aspects fonctionnels du code. Une carte puce a avant tout
un but fonctionnel d'authentication. De cette fonctionnalit, on pourra ensuite tirer le gain
haut niveau pour l'attaquant, tel qu'il est dcrit plus tard dans la section 1.3.7.
Une proprit de scurit est une garantie souhaite sur le code d'un point de vue de la
scurit. Elle est intrinsque au systme et peut tre tablie sans supposer d'attaque. l'ex-
trme, on peut envisager un attaquant avec des capacits nulles dans une modlisation qui fait
apparatre un attaquant. Dans ce cas, la proprit de scurit sera toujours garantie moins que
le dveloppeur n'ait introduit une faille. Inversement, si un attaquant a des capacits innies,
on ne pourra jamais assurer la garantie d'une proprit de scurit. La validation ou la mise en
place des contre-mesures an de garantir cette proprit dpend du modle d'attaquant. An
d'exprimer de manire pertinente une proprit de scurit, il convient d'abord d'exprimer avec
prcision les capacits d'un attaquant travers un modle d'attaque. Nous tablissons dans le
chapitre 3 un tel modle d'attaque.
Une autre considration prendre en compte est la priorit de la fonctionnalit et des perfor-
mances qui passe avant les aspects de scurit du code. On pourrait dire que scuriser un code
qui ne ralise pas sa tche principale ou qui n'atteint pas les performances requises est inutile
car le produit, mme s'il est parfaitement scuris, sera invendable.
Une dernire considration est le code en lui-mme et la dynamique logique qu'il implmente.
Le code exprime un besoin fonctionnel dcrit sous forme d'une spcication fonctionnelle. Ainsi,
les proprits de scurit, si elles sont garanties, protgeront ce besoin fonctionnel. Celui-ci
correspond une fonctionnalit implmente dans un langage de programmation (ici le C) se
dcomposant en plusieurs lments de ce langage : des fonctions et des variables.
Nous avons donc plusieurs lments prendre en compte pour exprimer les proprits de
scurit.
Le besoin fonctionnel sous-jacent ;

L'implmentation logicielle ;
Les capacits de l'attaquant.
Les spcicits d'une telle fonctionnalit dpendent totalement de ce que doit accomplir le
programme. Il est donc dicile de dnir des proprits de scurit gnriques dans ce cadre.
Cependant, une fonctionnalit se dcompose en plusieurs lments du langage de programma-
tion comme une ou plusieurs fonctions et certainement une plusieurs variables (locales et/ou
globales). Des dpendances logiques comme des conditions et des boucles articulent dynamique-
ment ces lments et donnent un sens au programme an de raliser le but de la fonctionnalit.
Une proprit de scurit cible une fonctionnalit que doit accomplir le programme. Garantir
une proprit de scurit au niveau du code source revient valider que le code impliqu dans
la scurit d'une fonctionnalit rsiste des attaques. Une garantie de scurit pour une fonc-
tionnalit de haut niveau pourra tre divise en un ensemble de garanties sur des fonctionnalits
d'un niveau infrieur plus proche du code source. Ainsi en vriant un ensemble de proprits de
scurit sur le code source, la scurit d'une fonctionnalit de haut niveau pourra tre garantie.
1.3.5 Spcications fonctionnelles et scurits additionnelles

L'exemple du listing 1.1 montre un extrait de code implment l'aide de spcications fonc-
tionnelles et de recommandations scuritaires contre des attaques physiques. Cet exemple illustre
la dualit de la scurit : l'existence d'une scurit fonctionnelle inclue dans les spcications et
d'une scurit additionnelle rajoute par le dveloppeur contre les attaques physiques.
Soit la fonctionnalit d'authentication basique suivante :
L'utilisateur doit s'authentier l'aide de son code PIN ;

Si celui-ci est correct la carte doit renvoyer un jeton d'authentication au terminal ;
L'utilisateur n'a droit qu' 3 essais ;
Le compteur d'essai doit tre mmoris en eeprom.
Exemple de fonctionnalit sans scurit additionnelle

La fonctionnalit dcrite dans l'exemple prcdent se dcompose en quatre actions accom-
plir dont une implmentation qui peut tre la suivante.
Listing 1.1 Exemple d'une implmentation d'authentication basique avec une tche fonctionnelle s-
curitaire sensible mais sans code contre attaques physiques
void Authentification(void) 1
{ 2
user_pin = get_pin(); 3
card_pin = read_eeprom(&ee_card_pin); 4
pin_cpt = read_eeprom(&ee_pin_cpt); 5
if ((user_pin == card_pin) && (pin_cpt < 3)) 6
{ 7
return jeton_auth; 8
} 9
else 10
{ 11
pin_cpt++; 12
} 13
write_eeprom(&ee_pin_cpt, pin_cpt); 14
} 15
Commentons comment ces actions ont t implmentes et ce que peut retirer l'attaquant
en les perturbant :
Ligne 3 la valeur du PIN prsent par l'utilisateur est crite dans la variable user_pin en
ram Un attaquant peut modier la valeur de la variable ram user_pin mais n'en tire pas
d'avantage car s'il possde la carte il est dj capable de choisir la valeur de user_pin qu'il
prsente la carte via le terminal
Lignes 4 et 5 la valeur du PIN enregistr dans la carte est lue depuis l'eeprom an de la
comparer celle de l'utilisateur ; la valeur du compteur reprsentant le nombre de pr-
sentations successives invalides de la part de l'utilisateur est aussi lue ; ces valeurs sont
respectivement crites dans les variables en ram card_pin et pin_cpt. L'attaquant peut
obtenir un avantage s'il modie la valeur de card_pin an qu'elle corresponde au PIN qu'il
prsentera la carte. Par consquent, cela lui permet de s'authentier la place de l'utili-
sateur lgitime. Un autre gain pour l'attaquant peut tre de forcer la lecture de ee_pin_cpt
une valeur infrieure celle actuellement enregistre en eeprom. Cela lui permet, par
un nombre illimit de prsentations successives du PIN, de dcouvrir la valeur du PIN
enregistr dans la carte.
Lignes 6 13 le PIN prsent est compar au PIN de la carte la condition que le nombre
d'essais incorrects successifs ne soit pas suprieur 3 ; si ces conditions ne sont pas res-
pectes, le compteur d'essai est incrment. Au niveau de cette comparaison, un attaquant
cherche soit obtenir jeton_auth alors que la comparaison ne devait pas le diriger vers
cette branche soit empcher l'incrment de pin_cpt an de pouvoir, par un nombre illi-
mit de prsentations successives du PIN, dcouvrir la valeur du PIN enregistr dans la
carte.
Ligne 14 la valeur du compteur d'essais est mmorise en eeprom. Ici aussi, l'attaquant
cherche perturber l'criture an que la valeur mmorise en eeprom soit infrieure
celle prvue lui permettant par un nombre illimit de prsentations successives du PIN
de dcouvrir la valeur du PIN enregistr dans la carte.
Exemple de fonctionnalit avec scurit additionnelle

Raliser une attaque physique prcise demande du matriel onreux et une expertise. A
cause de ces facteurs, un certain nombre d'hypothses peuvent tre faites sur ce qu'est capable
de provoquer un attaquant. Ces hypothses seront abordes dans le chapitre 3 et sont brivement
rsumes ici an de pouvoir comprendre les scurits additionnelles ajouter au code fonctionnel
du listing 1.1. On suppose donc que l'attaquant :
n'a droit qu' une attaque physique au cours de la transaction ;
peut modier de manire transiente (non permanente) une variable en ram lors de sa
lecture (respectivement criture) depuis (respectivement vers) l'eeprom mais n'est pas
capable de contrler la valeur obtenue autre que 0x00 ou 0xFF ;
peut modier de manire transiente la valeur d'une variable directement en ram mais
n'est pas capable de contrler la valeur obtenue autre que 0x00 ou 0xFF ;
peut, sous certaines conditions, modier de manire permanente une valeur lue depuis
l'eeprom ;
peut, si la conguration matrielle et le contexte logiciel le permettent, eectuer deux fois
la mme attaque avec un certain cart temporel ;
dans de trs rares cas, eectuer des doubles attaques avec une modication spatiale de
l'endroit vis ;
peut sauter une ou plusieurs instructions successives en contrlant l'origine du saut mais
pas la destination dans le cas de plusieurs instructions successives.
Ces hypothses se combinent avec la possibilit que possde l'attaquant d'arrter le fonction-
nement de la carte n'importe quel moment en coupant l'alimentation de celle-ci. Un attaquant
peut utiliser cette capacit pour empcher le dclenchement des rponses scuritaires, conser-
vant ainsi la possibilit de ritrer son attaque. Il peut aussi l'utiliser pour perturber le ot
d'excution fonctionnelle du code en empchant la ralisation de fonctionnalits ou l'criture
d'informations en eeprom.
Ces direntes attaques dont nous avons brivement rappel les consquences prcdemment
seront dcrites en dtail par la suite dans le chapitre 4. Dans le chapitre 4 nous nous intressons
aux consquences des attaques physiques sur l'assembleur traduites au niveau du code C. Nous
nous intressons particulirement aux attaques qui modient la valeur des variables ou celles qui
sautent du code.
Maintenant que nous avons dcrit les possibilits de l'attaquant, nous allons donner une
description des scurits additionnelles permettant de se dfendre contre certaines attaques.
Nous ne couvrirons pas l'intgralit des contre-mesures mais seulement celles qui rpondent aux
attaques les plus plausibles car plus faciles raliser par l'attaquant.
Dans l'extrait de code 1.2, certaines scurits additionnelles ont t rajoutes an de scuriser
les fonctionnalits. Dtaillons le rle de chacune de ces scurits :
Ligne 6 vrication de l'intgrit de card_pin, lue depuis l'eeprom, en doublant sa lecture

l'aide d'une seconde variable card_pin2. En supposant que l'attaquant n'a droit qu' une
attaque perturbant une variable, il n'est pas capable de perturber la fois la lecture ee-
prom de card_pin et de card_pin2. La contre-mesure choisie est kill_card() (dcrite dans
la section 1.3.5). Cette contre-mesure n'opre cependant pas contre une double attaque ;
Ligne 13 vrication de l'intgrit de pin_cpt avec la mme contre-mesure que pour card_pin.
La rponse scuritaire choisie ici est kill_card(). Le contenu de cette fonction est dtaill
dans la section 1.3.5. Cette section contient aussi d'autres exemples de rponses scuri-
taires ;
Lignes 19 et 22 on incrmente pin_cpt a priori pour viter l'arrachement et on le dcrmente

si tout se passe bien, en supposant que l'incrmentation de pin_cpt ligne 18 ne puisse
pas tre saute en mme temps que la condition la ligne 20 ;
Ligne 28 vrication de l'intgrit de pin_cpt crit en eeprom en rechargeant en ram la valeur

crite et en la comparant celle suppose avoir t crite. Cette contre-mesure suppose
que l'attaquant ne peut raliser qu'une seule attaque.
On peut remarquer que ces scurits additionnelles dpendent fortement du contexte fonc-
tionnel ainsi que des objets sensibles protger. Les lectures et critures en eeprom, si la donne
lue ou crite est sensible (ici, card_pin et pin_cpt), sont particulirement vulnrables aux at-
taques physiques et ncessitent une redondance scuritaire. On note aussi que scuriser du code
rajoute de la complexit et augmente aussi sa taille tout en diminuant ses performances. Par
exemple, la vrication de la cohrence de deux variables miroirs (ici, card_pin2 et pin_cpt2)
double au minimum le temps d'excution.
Les organismes qui crivent les spcications des produits peuvent mettre des guides de
recommandations scuritaires condentiels dcrivant les objets sensibles et donnant des descrip-
Listing 1.2 Exemple d'une implmentation d'authentication basique avec une tache fonctionnelle scuritaire
sensible avec quelques dfenses additionnelles contre les attaques physiques
{ 2
card_pin = read_eeprom(&ee_card_pin); 4
card_pin2 = read_eeprom(&ee_card_pin); 5
// vrification de lintgrit de card_pin (def 1) 6
if (card_pin != card_pin2) 7
{ 8
killcard(); 9
} 10
pin_cpt2 = read_eeprom(&ee_pin_cpt); 12
// vrification de lintgrit de pin_cpt (def 2) 13
if (pin_cpt != pin_cpt2) 14
{ 15
killcard(); 16
} 17
pin_cpt++; 18
// incrmentation a priori pour viter larrachement (def 3a) 19
if (user_pin == card_pin) && (pin_cpt < 3) 20
{ 21
// dcrmentation si tout se passe bien (def 3b) 22
pin_cpt--; 23
} 25
re_ee_pin_cpt = read_eeprom(&ee_pin_cpt); 27
// vrification de lintgrit de pin_cpt crit en EEPROM (def 4) 28
if (re_ee_pin_cpt != pin_cpt) 29
{ 30
killcard(); 31
} 32
} 33
tions haut niveau des contre-mesures qu'il serait recommand d'implmenter au niveau fonction-
nel. Les fondeurs peuvent aussi fournir ce genre de guide pour le dveloppement de bas niveau
dcrivant comment implmenter par rapport leur composant des contre-mesures ecaces. Ces
dernires s'apparentent plus des scurits additionnelles.
Une des problmatiques associe cette double implmentation de la scurit est le besoin
de tester le bon fonctionnement de ces implmentations aussi bien dans le cas de la scurit
fonctionnelle que dans le cas de la scurit contre attaque physique. Or, dans le cas de la
scurit fonctionnelle, il existe souvent des tests fonctionnels exigs par le client pour valider
le comportement de la carte du point de vue du terminal. Cependant, dans le cas des contre-
mesures contre attaque physique, le code rajout dans le listing 1.2 ne devant pas modier le
comportement fonctionnel, il peut tre considr comme du code mort ne ncessitant pas de
tests fonctionnels. Il faut alors crer des tests scuritaires spciques pour stimuler et tester ce
code rajout.
Outre les tests spciques ncessaires pour valider le bon fonctionnement des contre-mesures
implmentes, il existe une dicult supplmentaire pour le dveloppeur. Celui-ci doit identier
les lments sensibles de son implmentation fonctionnelle et les scuriser contre des attaques
physiques potentielles. Or, le dveloppeur n'a pas forcment une connaissance prcise de l'impact
d'une attaque physique sur le composant sur lequel son code sera dploy. Il lui est donc dicile
d'estimer la sensibilit de son implmentation face aux attaques physiques.
Il est important de noter que, du point de vue du dfenseur, un programme peut contenir
du code que l'attaquant doit excuter. Par exemple, le code correspondant la mise jour
d'un compteur de scurit ou l'appel d'une rponse scuritaire doit tre excut, mme en
prsence d'une attaque physique. Un programme peut, par ailleurs, contenir des parties de
code que l'attaquant ne doit pas excuter sous certaines conditions. Par exemple, un calcul
cryptographique avec des donnes xes par l'attaquant lors d'une attaque ne doit pas tre
eectu. Seul le dveloppeur est capable de connatre le sens associ au code qu'il crit et donc
de dnir les besoins en scurit associs.
Scuriser le code contre les attaques physiques est donc une tche dicile pour le dveloppeur
qui est cependant le seul disposer des connaissances ncessaires pour y arriver. Dans cette thse,
nous souhaitons cerner les possibilits d'attaque sur le code source et permettre au dveloppeur
de scuriser plus facilement et plus ecacement son code source.
Contre-mesures scuritaires
Plusieurs types de dfenses existent pour se protger contre les attaques physiques. Nous
allons prsenter celles-ci, le niveau auquel elles agissent et leur mode de fonctionnement.
Types de dfenses Les dfenses qui existent dans une carte puce interviennent plusieurs
niveaux. L'empilement de ces dfenses permet de crer plusieurs barrires de dfense pour l'at-
taquant qui devra, par exemple, djouer des dfenses matrielles avant de pouvoir atteindre les
parties du composant lui permettant d'inuencer le comportement du programme. Ces dfenses
sont :
Matrielles o dirents capteurs sont utiliss contre les dirents vecteurs physiques existants
(capteurs de lumire, de surtension, ltres, logique double rail . . . ). Ces dfenses sont
gnralement transparentes pour le dveloppeur. Des dfenses matrielles supplmentaires
propres au composant peuvent exister mais demandent une conguration de la part du

dveloppeur.
Algorithmiques o l'implmentation par l'ajout de compteurs, de machines d'tat et d'autres

fonctionnalits assure un certain niveau de scurit au systme.
Logicielles cette partie est gnralement laisse la discrtion du dveloppeur qui doit dcider
s'il est pertinent d'utiliser une redondance de donnes, doubler une opration, mettre en
place un checksum ou des points de contrle dans son code an d'assurer la scurit de
celui-ci.
Dtection de l'attaque Une dfense peut gnralement tre dcompose en deux tapes.
Premirement, une vrication dans le code permet de dtecter une incohrence par rapport
au comportement attendu. Dans un second temps, une rponse scuritaire est dclenche en
fonction de la sensibilit de l'opration en cours. Cette rponse peut tre immdiate ou dire.
Une dtection dans une dfense logicielle repose toujours sur une comparaison eectue dans le
langage de programmation. L'objet de la comparaison peut tre multiple et dpend du contexte
ainsi que de la sensibilit de l'objet scuriser ou de la fonctionnalit scuriser. Dans cer-
tains cas, les dfenses algorithmiques et logicielles peuvent tre imbriques pour des gains de
performance.
Dans le cas d'une fonctionnalit scuriser, la dtection revient souvent comparer le rsultat
obtenu la n de la fonctionnalit en excutant une seconde fois l'intgralit ou une partie de
la fonctionnalit. Par exemple, la mise jour d'une donne sensible comme un compteur en
mmoire eeprom demande une premire mise jour en ram suivie d'une criture en mmoire
eeprom puis d'une relecture et d'une comparaison par rapport l'quivalent de la donne
prsente en mmoire ram.
Rponses scuritaires Les ractions possibles face une attaque sont souvent les suivantes :
destruction de la carte par eacement de zones mmoires sensibles ;
blocage d'une application qui se met en indisponibilit vis--vis du terminal ;
dans certains cas, si le comportement face l'attaque est spci, une rponse prvue par
les spcications peut tre renvoye au terminal.
Garantir une proprit de scurit peut revenir vrier qu'une dfense contre attaque
physique existe, qu'elle couvre bien l'objet sensible scuriser, qu'elle se dclenche bien et
provoque la rponse scuritaire escompte.
Positionnement d'une dtection / contre-mesure Le positionnement d'un couple (d-

tection et contre-mesure) dans le code doit tre fait de telle manire que l'attaquant ne soit
pas capable en une seule attaque d'obtenir un gain et de sauter la contre-mesure. Une autre
contrainte dont le dveloppeur doit tenir compte lors du positionnement est le fait que la carte
peut tre arrache tout moment. Ainsi, la dfense doit tre place de telle sorte que l'attaquant
ne puisse pas, par exemple, crire une donne sensible fausse en mmoire eeprom, puis arracher
la carte et ne pas eectuer la vrication, la contre-mesure ou les deux.
Porte d'une dfense Sans contraintes de performance temporelles ou de taille mmoire,

on aurait la possibilit de scuriser une implmentation fonctionnelle sans se proccuper des
consquences. Cependant en embarqu, ces contraintes ne peuvent tre ignores. Il convient

donc de les prendre en compte lors de l'implmentation de la scurit en essayant d'optimiser,
dans la mesure du possible, la porte des dfenses. Une dfense peut tre qualie comme :
Eective sur une zone de code correspondant porte de dtection d'une dfense couvrant ou
non la fonctionnalit scuriser ;
Ecace si la fonctionnalit scuriser est couverte ecacement par cette porte ;

Optimale si la fonctionnalit scuriser est couverte ecacement par cette porte et que la
porte minimise l'impact sur les performances.
L'objet scuriser est l'implmentation d'un besoin fonctionnel. La notion d'optimalit est
lie la dure de vie de l'objet scuriser et le type de proprit de scurit qui s'y rapporte. On
ne traite pas du cot mmoire d'une scurit ni son optimisation dans cette thse. Cependant,
on s'intressera la couverture des attaques physiques par une dfense logicielle en utilisant
direntes techniques de simulation d'attaques. Quelle que soit la proprit de scurit (con-
dentialit / intgrit), la dure de vie de l'objet scuriser aura son importance et sera lie la
dnition de cette proprit de scurit.
1.3.6 Scurisation et angles d'attaque

Si on relie les besoins en scurit au code source, on peut rapidement voir qu'il est dicile
d'implmenter du code qui rsiste aux attaques physiques. Prenons l'exemple d'une condition.
Une version non scuris de l'implmentation d'une condition est prsente dans le listing 1.3.
Listing 1.3 Condition non scurise
if (x == y) 1
{ 2
z = 1; 3
} 4
Le listing 1.4 prsente une premire scurisation consistant rajouter une rponse scuritaire
si la condition n'est pas vrie.
Listing 1.4 Condition scurise naivement
if (x == y) 1
{ 2
z = 1; 3
} 4
else 5
{ 6
killcard(); 7
} 8
Cette implmentation ne rsiste pas un attaquant capable de sauter l'excution d'une

instruction. En eet, prenons comme exemple une condition gnrique en C implmente dans
le listing 1.5. Celle-ci se traduit en assembleur par le code du listing 1.6 (exemple avec du code
d'un composant Motorola 68000 dont on pourra trouver une description du jeu d'instructions
la rfrence suivante [EventHelix 2012]) :
Listing 1.5 Implmentation C d'une condition
if (x == y) 1
{ 2
z = 1; 3
} 4
else 5
{ 6
z = 0; 7
} 8
Listing 1.6 Traduction de cette condition en assembleur 68000
* chargement de x dans le registre de donne D7 1

MOVE.L _x, D7 2
* comparaison de x avec y 3
CMP.L _y, D7 4
* si ingalit saut dans la branche else spcifie par le label L1 5
BNE.S L1 6
* chargement de 1 dans z 7
MOVE.L #1, _z 8
* saut aprs linstruction if-then-else 9
BRA L2 10
* partie else de linstruction if-else 11
* mise zro de z 12
L1 CLR.L _z 13
* fin de linstruction if-else. En cas dgalit, la partie else de la 14
* condition est saute pour atteindre directement le label L2 15
L2 ... 16
Or, dans le listing 1.6, si l'attaquant saute l'instruction la ligne 6 ; mme si la condition
n'est pas vrie, le code de la branche then sera excut sans que celle de la branche else ne le
soit jamais. Dans ce cas, un attaquant arrive excuter l'inverse de ce qui est prvu par le code
(scnario 1).
On peut remarquer que si l'attaquant est capable de sauter l'instruction la ligne 10, partir
du moment o il a accs la branche then, il est en mesure d'excuter la fois la branche then
et la branche else. On remarque aussi qu'en sautant les lignes 8 ou 13, l'attaquant peut ne pas
excuter le code eectif d'une des branches (car dans cet exemple, il n'y a qu'une instruction dans
chacune des branches). Dans ce cas prcis, cette attaque est quivalente au comportement initial
ou ne pas excuter la totalit de la condition. Dans ces deux cas, l'attaquant doit tre intress
soit par l'excution de la branche else (par exemple, si cette branche annule les eets de la
premire comme un compteur incrment et dcrment) soit par la non excution de l'ensemble
de la condition (par exemple, le passage d'une machine d'tat un tat dsavantageux pour
l'attaquant). Dans ces cas, l'attaquant arrive excuter plus ou moins que ce qui est prvu par
le code (scnario 2).
Deux derniers cas intressants prendre en compte sont si l'attaquant saute une des ins-
tructions aux lignes 2 ou 4. Dans ces cas, l'attaquant empruntera une des branches non pas en
fonction de la condition originale mais en fonction du contexte prcdent le if. Dans le premier
cas, la branche emprunte dpendra de la valeur se trouvant prcdemment dans le registre D7
et de sa dirence avec la valeur de y. Dans le second cas, la branche emprunte dpendra, avec
cette architecture et jeu d'instruction, de la position du registre d'tat Z qui est mis 1 si le
rsultat de la soustraction entre les deux oprandes donne 0 [Angelis 2012]. Avec des jeux d'ins-
tructions dirents, il pourra s'agir de l'ACC. Ce registre d'tat peut tre dtermin par d'autres
oprations, comme par exemple des oprations arithmtiques. La position de ce registre d'tat
dnira la branche emprunte aprs l'excution de l'instruction de saut la ligne 10. Dans ces
cas, l'attaquant arrive, en fonction du contexte, obtenir un comportement identique au com-
portement original, un comportement inverse ou un de ces comportements avec les eets de bord
induits par la non excution d'une des lignes sautes (scnario 3).
Une scurisation possible contre l'attaque du scnario 1 est l'implmentation scurise du
listing 1.7. En supposant que la fonction killcard() termine l'excution du programme sans
retourner dans le code qui l'appelle, la branche else ne sera jamais excute.
Listing 1.7 Condition scurise avec une premire mthode
if (x != y) 1
{ 2
killcard(); 3
} 4
else 5
{ 6
z = 1; 7
} 8
Cependant, cette forme de code dfensive ne scurise pas contre les scnarii d'attaque 2 et
3. Elle ne fonctionne pas non plus contre des sauts de multiples instructions conscutives. Par
exemple, ne pas excuter l'instruction d'appel la fonction killcard() et le saut la ligne 10
peut avantager l'attaquant si celui-ci cherche excuter le contenu de la branche else alors
que la condition est fausse (x != y). Cette dfense ne protge pas non plus contre les doubles
attaques qui permettent, par exemple, le saut du contenu d'une branche (ligne 8) et le saut
d'une instruction de branchement (ligne 10), ce qui, dans certains cas, peut tre quivalent au
saut de multiples instructions successives. Les doubles sauts sont cependant plus ecaces dans
l'hypothse d'une modication de code qui avantage l'attaquant suivi du saut de la contre-mesure
associe.
La seule dfense possible qui prend en compte les scnarii 1, 2 et 3 (sans pour autant prendre
en compte les doubles sauts et certains sauts d'un grand nombre d'instructions successives) est
de doubler la condition (si possible avec une implmentation dirente de la premire) et de
vrier la cohrence entre ces deux conditions. Cependant, cette mthode double au minimum
le temps d'excution ainsi que la mmoire ncessaire pour implmenter la condition.
Ce travail de dnition du gain pour l'attaquant, d'analyse des eets des fautes sur le com-
portement du code et de lien entre l'eet et le gain devrait tre fait sur l'ensemble des formes de
code du systme et une version dfensive de cette forme de code devrait tre utilise lors d'une
opration sensible. Dans le chapitre 5, nous proposons une mthode exhaustive an de tester
dynamiquement les comportements possibles du code en injectant exhaustivement des attaques
au niveau C mais aussi au niveau assembleur. Cette mthode permet d'valuer la rsistance des
contre-mesures implmentes en rduisant au maximum le travail de dnition et d'analyse.
1.3.7 Modlisation et vrication

Dans un premier temps, an de pouvoir proposer des mthodes cherchant garantir la
scurit de ces systmes embarqus, nous proposons de formaliser des proprits de scurit
exprimant les garanties de scurit souhaites. Dans un second temps, an de pouvoir cerner
l'ensemble des problmatiques lies la scurit embarque, il convient d'tablir un modle des
capacits de l'attaquant, c'est--dire, sa capacit modier le comportement fonctionnel du

code par le biais d'une attaque physique. Grce ces lments, nous proposerons des outils
permettant l'analyse du code et la vrication de la scurit de celui-ci.
Modlisation de la scurit : une approche fonctionnelle

Une approche possible pour modliser la scurit est l'approche fonctionnelle. Les problma-
tiques de scurit sont abordes partir des fonctionnalits que doit accomplir le programme.
L'avantage d'une telle approche est qu'elle reste gnrique par rapport au code et s'adapte un
environnement industriel. Un logiciel a toujours un cahier des charges dcrivant ses fonctionna-
lits. Une fois les tches accomplir par le programme connues, on peut facilement en dduire le
gain pour un attaquant. Par exemple, si une tche est d'authentier un utilisateur s'il prsente
un bon PIN, le gain pour l'attaquant est de s'authentier avec un mauvais PIN. De plus, on
peut aisment, en lisant le cahier des charges, isoler les fonctionnalits sensibles sur lesquelles
se concentrer et liminer celles dont la scurit est moins importante. Par consquent, une re-
prsentation de la scurit ce niveau est adapte un contexte industriel par son caractre
gnrique. En eet, on arrivera toujours exprimer un besoin de scurit partir du cahier des
charges du logiciel.
Finalit fonctionnelle Soit une transaction regroupant plusieurs commandes. Chaque com-
mande peut tre vue comme une fonctionnalit disposant d'une nalit. Cette nalit est gn-
ralement prsente dans la rponse renvoye par la carte mais aussi dans les changements oprs
au sein de la carte par l'excution de la commande. L'ensemble de ces commandes mne la
nalit globale qui est l'aboutissement de la transaction reprsentant la tche fonctionnelle glo-
bale. En faisant l'hypothse que la dernire rponse de la carte rete l'excution d'un ensemble
d'oprations internes relatives la transaction, on peut en vriant cette rponse dduire que
ces oprations internes se sont bien eectues. Cette hypothse est la base des tests en bote
noires. Cette hypothse revient aussi dire que l'attaquant ne peut pas la fois raliser une
attaque et perturber le mcanisme de gestion d'erreur et aussi qu'une gestion d'erreur est im-
plmente pour chaque opration critique au sein de la carte. La rponse nale l'chelle d'une
transaction, rete le droulement d'oprations issues de commandes prcdentes car dans une
transaction (par exemple emv) ces commandes sont lies par des informations partages. Pour
notre modlisation nous prendrons une perspective l'chelle d'une commande. Les proprits
de scurit peuvent tre tablies sur des commandes ou l'chelle d'une transaction.
Perspective et vision allge Si on analyse le ot de contrle du code source, on peut

distinguer :
des oprations ou calculs ;
des appels de fonctions regroupant un ou plusieurs oprations et calculs. Ces fonctions
peuvent tre vues comme des boites avec des entres et sorties ;
des conditions.
Le listing 1.8 illustre ce niveau d'abstraction en ne faisant apparatre que les deux derniers
lments mentionns ci-dessus. Ainsi, une fois que le terminal a envoy une requte la carte,
le code prsent dans celle-ci s'excute de manire autonome sans autre intervention de la part
du terminal. Les seules informations modiant les dcisions lors de l'valuation des conditions
Listing 1.8 Requte schmatique
# Terminal --envoi dune requte--> Carte 1

# -in-> 2
F() 3
{ 4
if (toto == titi) 5
{ 6
f(); 7
} 8
} 9
# <-out- 10
du code se trouvent dans la requte d'origine. En gardant une reprsentation faisant seulement
apparatre les lments du graphe d'appels et les lments du ot de contrle, nous avons abs-
trait le code prsent qui s'excute squentiellement pour ne garder que les points de changement
possibles dans la logique du programme. Ces points de dcision sont cls dans la logique de fonc-
tionnement du programme et reprsentent des points d'attaques particulirement intressants
pour un attaquant.
Ces visions de l'excution fonctionnelle permettent focaliser uniquement sur un sous ensemble
du graphe d'appels total, i.e., les squences d'appels se terminant par une nalit fonctionnelle.
Les transitions l'intrieur de ces squences (conditions, appels) sont des points dans le code
potentiellement vulnrables une attaque physique car ce sont des points cls au niveau fonc-
tionnel.
D'un point de vue de la scurit, on peut considrer qu'une vrication, par exemple doubler
une opration comme dans le listing 1.9, dclenchera en cas de non respect une rponse scuritaire
et n'amnera jamais appeler la fonction permettant de continuer dans le graphe d'appels vers
la nalit. En eet, doubler une opration n'apporte rien dans le ot fonctionnel du code mais
est uniquement prsent pour protger contre des attaques physiques.
Dans l'exemple 1.9, aprs une vrication de l'excution correcte de calcul_crypto(), le

ot du code retournera sur le chemin fonctionnel standard et eectuera une transition normale
hors de la fonction F(). Par contre, si la condition if (res1 == res2) n'est pas vrie, le ot
d'excution standard est interrompu et bascule sur l'excution du code d'une rponse scuritaire.
Cette perspective nous montre qu'il est important de considrer un point de vue particulier
lorsqu'on s'intresse la scurit fonctionnelle et que seule une partie du code sera pertinente
dans la modlisation.
Expression du gain pour l'attaquant

Le gain pour l'attaquant est li l'utilisation faite de la carte puce. Une carte puce
peut, par exemple, tre utilise dans le cadre d'une authentication entre plusieurs partis. Dans
ce scnario, un attaquant dispose de plusieurs moyens pour exploiter les possibilits d'une at-
taque physique. Nous dcrivons dans la suite deux types d'exploitation suivant que l'attaque
compromet des donnes ou modie le comportement de la carte.
Si on considre qu'une attaque permet d'obtenir des informations ou des donnes conden-
tielles permettant d'authentier les partis (typiquement des cls d'authentication), le but de
l'attaquant est de se faire passer pour un des partis an de se placer comme destinataire d'un
Listing 1.9 Exemple simple d'une fonction avec doublement scuritaire qui n'a pas d'impact sur la nalit
fonctionnelle
// on arrive fonctionnellement ici 1

// appel F 2
3
void F(void) 4
{ 5
res1 = calcul_crypto(); 6
7
// de peur dtre attaqu on double le calcul 8
res2 = doublement_calcul_crypto(); 9
10
if (res1 == res2) 11
{ 12
// transition sur le chemin fonctionnel 13
continuer_fonctionnellement_vers_finalite(); 14
} 15
else 16
{ 17
// non transition 18
killcard(); 19
} 20
} 21
transfert nancier et intercepter le montant transfr. Dans la pratique, l'attaquant fabrique des
clones de la carte contenant les donnes condentielles obtenues malicieusement. Dans le cas
d'un vol de carte, l'attaquant cherche en priorit obtenir le code PIN du possesseur de la carte
ce qui lui permettra de retirer de l'argent.
Si on considre qu'une attaque physique est capable de modier le comportement fonctionnel

de la carte, le but de l'attaquant est de gnrer de l'argent (en ciblant les compteurs de montant),
de monter en privilge dans des scnarii qui ne le demandent pas (en ciblant des variables d'tat),
de faire du rejeu de commande (en ciblant des variables de machines d'tat), d'empcher le
verrouillage scuritaire de la carte (en empchant la mise jour de variables d'tat scuritaire).
Dans la pratique, l'attaquant a besoin de l'assistance d'un commerant complice an de russir
son attaque dont le gain montaire n'est pas immdiatement visible.
Cependant modier le comportement du code peut amener une exploitation indirecte

dans un contexte dirent. Par exemple, le rejeu autorise la gnration de traces exploitables
dans des attaques par canaux cachs an de retrouver des cls secrtes. On retombe dans un
des cas mentionns ci-dessus o l'attaquant cherche se faire passer pour l'un des partis. Le
rejeu inconditionnel d'une commande ouvre aussi la possibilit d'puiser exhaustivement les
combinaisons d'entre et ainsi dcouvrir un secret.
On remarque ainsi qu'il existe de nombreux vecteurs d'attaques qui dpendent la fois du
contexte d'utilisation de la carte et de son implmentation fonctionnelle.
An d'assurer une compltude au niveau de la scurit fonctionnelle et se prmunir contre

un maximum de vecteurs d'attaque possibles, il convient de raliser un travail de rexion
prliminaire sur les besoins fonctionnels et l'implmentation de ceux-ci dans une optique de
scurit.
1.3.8 Angle d'approche et rsum
Dans cette thse, nous cherchons amliorer la scurit de la carte en introduisant une
meilleure visibilit des eets des fautes physiques. Nous adoptons une approche fonctionnelle de
haut niveau an de mettre en vidence comment ces fautes peuvent tre utilises pour monter
des attaques sur le code. An de rpondre cette problmatique de scurit, nous allons modier
le comportement d'un programme en faisant varier certains paramtres le caractrisant.
Programmes
Donnes d'entre
Attaques
Figure 1.14 Axes d'approche du problme
La gure 1.14 montre une perspective visuelle du problme et l'angle d'approche que nous
souhaitons adopter. Les dirents axes reprsentent les paramtres du problme qui peuvent
tre modis. Dans notre approche, nous ferons varier les attaques possibles en xant le code
d'un programme et des donnes d'entre spciques. Des approches direntes comme le fuzzing
[Lancia 2011] ne prennent pas en compte d'attaques et font varier les donnes d'entre sur un
mme programme. Une mthode utilisant la mutation de programme [Barbu et al. 2010] essaie
de couvrir l'ensemble des programmes possibles dont ceux contenant une attaque pour un mme
jeu d'entres. Nous avons choisi cette mthode qui semble dans notre contexte tre la plus
approprie. Dans cette thse, nous exploiterons donc cette mthode consistant faire varier les
attaques possibles sur l'ensemble du programme.
En plus du choix de cette mthode, nous adoptons galement un point de vue particulier
dans cette thse.
MATRIEL FONCTIONNALITS
IMPLMENTATION
DU CODE
SECURIT
CHEMINS
COMPTENCES D'ATTAQUE
ATTAQUANT
Figure 1.15 La place de la scurit dans le contexte embarqu
La scurit sur une carte puce se trouve la jonction de plusieurs lments rpartis
dirents niveaux :
Matriel le circuit lectronique responsable de l'excution physique du programme ;

Fonctionnel la logique derrire le fonctionnement du matriel dnissant le ou les rles et
actions accomplir ;
Attaquant la personne malveillante dont le gain va s'exprimer en fonction du fonctionnel.
Ces lments sont eux mmes interdpendants :
Implmentation logicielle entre le matriel et le fonctionnel, reprsente comment le dvelop-

peur va traduire les actions fonctionnelles en un programme s'excutant sur le matriel (la
puce) ;
Les chemins d'attaques chemins logiques reprsentant comment l'attaquant envisage de

troubler l'excution fonctionnelle an d'obtenir un gain ;
Les comptences matrielles de l'attaquant dnissent le matriel auquel l'attaquant a

accs et ses connaissances techniques lui permettant de mener bien une attaque.
A chaque niveau peut tre associ un point de vue particulier qui englobe les considrations
et problmatiques associes au niveau en question. L'approche adopte dans cette thse est de
prendre en compte le point de vue du dveloppeur charg d'implmenter le code fonctionnel et
d'incorporer une notion d'attaquant matriel directement traduite sur le code source.
1.4 Conclusion et annonce

Dans ce chapitre, nous avons prsent l'architecture d'un microcontrleur an de mieux cer-
ner les vulnrabilits en cas d'attaques physiques. Nous avons aussi donn l'intuition ncessaire
pour comprendre ce que cherchait raliser un attaquant grce ces attaques. Les compo-
sants matriels de l'architecture d'un microcontrleur ont t passs en revue et nous avons
prsent l'aspect fonctionnel des considrations en scurit. Nous avons mis en vidence le be-
soin d'exprimer des garanties de scurit sous forme de proprits de scurit gnriques au
niveau du code source du programme. Nous avons galement mis en vidence le besoin d'un mo-
dle d'attaque au niveau du code source permettant de formaliser les capacits de modication
fonctionnelle d'un attaquant l'aide d'une attaque physique. Finalement, nous avons montr
qu'une mthode permettant de tester le code source contre ces attaques physiques tait nces-
saire. Dans les chapitres suivants, nous prsenterons donc nos quatre principales contributions qui
sont regroups dans les publications suivantes : [Chambrot & Kaumann-Tourkestansky 2009],
[Berthom et al. 2010], [Berthom et al. 2011] et [Berthom et al. 2012].
Dans le chapitre 2, une formalisation de proprits de scurit au niveau du code source

est tablie. Des proprits de scurit comme la condentialit, l'intgrit de donnes et l'int-
grit d'excution sont formalises de manire ce qu'un dveloppeur soit capable de les utiliser
directement sur son code source.
Dans le chapitre 3, un modle d'attaque pour la vrication de proprits de scurit est

tabli sur le code C. Ce modle d'attaque permet de dterminer une mthode pour simuler
les capacits d'un attaquant sur le code source. Nous dterminons notamment ses capacits
observer et agir sur les composants matriels d'un microcontrleur et les rpercussions sur
le code source. Dans ce chapitre, nous introduisons galement une modlisation statistique du
phnomne de dcalage du ot d'excution rsultant d'une attaque physique.
Dans le chapitre 4, ce modle d'attaque tabli est utilis pour rduire le nombre d'attaques
raliser. Nous apportons la preuve que cette rduction stimule l'intgralit des attaques possibles
du modle propos ainsi qu'une technique dterminant les points d'attaque de cette rduction.
Nous utilisons galement une approche statique visant montrer qu'il est possible d'utiliser une
mthode d'injection de fautes simules et de la relier une mthode de vrication formelle.
Dans le chapitre 5, nous proposons une valuation des risques de scurit lis aux attaques
physiques sur le contrle de ot. Cette valuation est ralise grce une simulation haut niveau
de ces attaques utilisant le modle prcdemment cr. Ce chapitre tablit un classement de ces
attaques en catgories pertinentes vis--vis de leur consquence fonctionnelle. Nous cherchons
ainsi relier les attaques matrielles et le comportement fonctionnel rsultant par la simulation
d'attaques au niveau logiciel. Cette relation est utilise pour montrer les consquences sur le
contrle de ot du programme en simulant des attaques par saut. La mthode propose permet
de mettre en vidence les consquences fonctionnelles quelle que soit l'attaque par saut. Une
approche dynamique est ensuite utilise visant dterminer le degr de couverture des attaques
possibles au niveau physique par le modle tabli et les simulations eectues haut niveau.
Cette couverture est tablie en utilisant direntes techniques d'injection d'attaque.
Le chapitre 6, dcrit dirents outils existants pour eectuer des tests ou des vrications
de la scurit dans des projets chelle industrielle. Ces outils seront passs en revue et nous
montrons le besoin d'une solution ddie rpondant un contexte prcis. Les dirents outils
industriels raliss dans le cadre de cette thse sont prsents en dtail et nous mettrons en lu-
1.4. Conclusion et annonce 47
mire leurs avantages dans l'adoption d'une mthodologie complte et adapte l'environnement
industriel de cette thse.
Finalement, le chapitre 7 terminera cette thse en prsentant les conclusions tablies et les
perspectives possibles du travail ralis.
Chapitre 2
Modlisation et proprits de scurit
Sommaire
2.1 Introduction, approche et hypothses . . . . . . . . . . . . . . . . . . 49
2.1.1 Approches existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.1.2 Dcomposition de fonctionnalit . . . . . . . . . . . . . . . . . . . . . . 53
2.1.3 Dcomposition en lments du langage . . . . . . . . . . . . . . . . . . . 53
2.2 Formalisme utilis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2.1 Information et conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2.2 Ensemble d'informations visibles . . . . . . . . . . . . . . . . . . . . . . 56
2.2.3 Zone de garantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.2.4 Type d'attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.2.5 Formalisation d'une proprit de scurit . . . . . . . . . . . . . . . . . 61
2.3 Condentialit d'une information . . . . . . . . . . . . . . . . . . . . . 62
2.3.1 Condentialit sous attaque . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.3.2 Zone de gnration d'information d'un conteneur . . . . . . . . . . . . . 64
2.3.3 Zone de garantie de condentialit . . . . . . . . . . . . . . . . . . . . . 66
2.3.4 Avantage pour l'attaquant et granularit de l'information . . . . . . . . 67
2.4 Intgrit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.4.1 Accs un conteneur et zone de garantie . . . . . . . . . . . . . . . . . 69
2.4.2 Intgrit en lecture et criture . . . . . . . . . . . . . . . . . . . . . . . . 70
2.4.3 Avantage pour l'attaquant . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.4.4 Intgrit d'excution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.1 Aspects smantiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.2 Temporalit des proprits . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.3 Prise en compte du compilateur . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.4 Thorie de l'information . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.6.5 Gnration automatique de proprits . . . . . . . . . . . . . . . . . . . 78
2.1 Introduction, approche et hypothses

Aprs avoir montr dans le chapitre prcdent, le besoin de formaliser la scurit an de
cerner les besoins en scurit d'un code embarqu. Nous avons pris le parti la fois d'adopter
une vision fonctionnelle permettant d'apprhender directement le gain pour l'attaquant et un
point de vue proche du dveloppeur an que celui-ci soit capable d'exprimer les besoins en
scurit de son code. Nous exprimons ainsi des proprits de scurit sur le code source utilis
50 Chapitre 2. Modlisation et proprits de scurit
par le dveloppeur, ici le C. Ces proprits doivent aussi tre gnriques an de pouvoir tre
utilises quel que soit le projet.
Dans ce chapitre, nous parlerons donc d'une modlisation de la scurit permettant de for-
maliser des proprits de scurit. Ces proprits de scurit nous servent vrier des compor-
tements de scurit sur notre systme. Dans notre approche, nous allons choisir de les modliser
partir d'un point de vue particulier mi-chemin entre des spcications fonctionnelles de
haut niveau et des lments du langage de programmation. Une caractristique originale dans
cette approche est l'incorporation de rponses scuritaires dans la formalisation. La particularit
propre au contexte de la scurit embarque est que le matriel peut tre attaqu physiquement.
Cette particularit intervient lors de la vrication et du test de ces proprits.
Dans ce chapitre, nous nous intressons donc la dnition de proprits de scurit dans un
environnement embarqu soumis des attaques physiques. Dans un contexte industriel, le choix
des composants utiliss et de la chaine de compilation est laisse l'entreprise dveloppant la
partie logicielle de la carte. Ces caractristiques peuvent varier d'un projet l'autre et excluent
l'utilisation du compilateur lors de la vrication des proprits de scurit. Ces caractristiques
rendent aussi la dnition de proprits gnriques plus diciles. Notre objectif est de formaliser
des proprits de scurit pour les raisons donnes dans la section 1.3 du chapitre 1. Ce chapitre
a permis de donner l'intuition de ce que pouvait faire un attaquant. Nous voulons maintenant
formaliser les garanties de scurit souhaites l'aide d'un modle et des proprits de scurit.
Pour formaliser les garanties de scurit souhaites, nous devons d'abord nous intresser
ce que fait le code puis ce que l'attaquant gagnerait le perturber. Les fonctionnalits du
programme une fois dcomposes en oprations proches du langage de programmation utilis,
peuvent tre projetes sur le code source.
2.1.1 Approches existantes

Direntes approches la dnition de proprits de scurit existent dans la littrature.
Ces approches adoptent des points de vue dirents entranant des niveaux d'abstraction plus
ou moins loigns du code source.
SELinux [McCarty 2004] est un exemple de modle de scurit qui peut tre rajout au
systme standard de Linux an d'augmenter la scurit face aux diverses attaques que subit le
systme. Ce modle centr sur le contrle d'accs adopte une approche de haut niveau et permet,
par l'utilisation de rles et de permissions, de garantir la scurit. Ce modle a t dploy avec
succs sur des systmes embarqus Android an de garantir des proprits de lgitimit d'accs
des ressources [Shabtai et al. 2010].
Des modles crs pour assurer des garanties d'isolation entre direntes parties d'un mme
systme existent galement. Les auteurs de [Schellhorn et al. 2002] proposent une extension des
modles de Bell/Lapaluda [Bell & LaPadula 1975] et Biba [Biba 1977] an de vrier formel-
lement la scurit d'une carte multi-applicatives dans le cas o une nouvelle application est
ajoute. Les deux derniers modles cits dnissent la condentialit et l'intgrit en terme de
contrle d'accs dans un systme avec des acteurs possdant des degrs de privilge dirents.
Le point de vue adopt est port sur le droit d'accs des ressources du systme d'exploitation
se traduisant par des lectures et critures dans des chiers du systme de chier. Ce point de
vue s'intresse au systme et reste relativement loign du code source.
Schwan mentionne dans [Schwan 2008], en plus des modles prcdents, des modles bass sur
2.1. Introduction, approche et hypothses 51
le ot d'information. Originalement introduit par Denning [Denning 1976], ce modle a donn
lieu des prdicats comme la non-interfrence [Goguen & Meseguer 1982]. Ce prdicat dnit
des rgles pour le transfert d'une information sensible entre des sources d'un niveau de scurit
dirent. Schwan mentionne d'autres prdicats comme la restriction, la non-dductibilit et l'iso-
lation. Ces prdicats sont formaliss l'aide de traces. Une trace tant une caractrisation du
systme ralise l'aide d'une squence d'entres et de sorties. Le point de vue adopt confronte
des menaces des objectifs de scurit formaliss et regroups en politiques de scurit. Cette
approche adapte un travail de certication reste relativement loigne du code source. Cepen-
dant, la notion de ot d'information et de trace se rapproche de celui-ci. En eet, les transferts
d'information sont visibles au niveau du code source tandis que les traces d'excution caract-
risent un scnario fonctionnel. Ce scnario peut tre li l'approche fonctionnelle prsente dans
la section 1.3.7 du chapitre 1.
Le concept de trace est utilis par Thorn [Thorn 1999] dans une approche de la scurit
adoptant un point de vue proche du langage de programmation. Celui- ci choisit une reprsen-
tation en terme de graphe du programme. Une trace d'excution du programme projete sur
cette reprsentation gnre une squence de nuds qui peut tre confronte des proprits de
scurit. Ces proprits de scurit sont dnies partir de formules logiques qui font intervenir
des squences de nuds prtablies et labelliss suivant des critres de scurit. Ces critres de
scurit illustrent la validit ou le potentiel de risque d'une squence d'appels du programme.
Cette approche est applique au code d'une Java Card et valide l'utilisation du graphe d'ap-
pel d'un programme pour valider des proprits de scurit portant sur une suite d'appels du
programme. Cette approche a l'avantage de permettre, une fois les squences d'appels connus,
d'tablir des rgles qui pourront tre valides par la machine virtuelle de manire statique ou
dynamique. Elle demande cependant de dnir l'avance ces squences d'appels. Ce modle ne
suppose pas non plus la prsence de fautes l'intrieur du code d'un appel. Si certains aspects
de cette approche peuvent tre adapts au niveau C, la majeure partie reste spcique un
environnement utilisant le langage Java.
Les auteurs de [Sabelfeld & Myers 2003] donnent une description complte des prdicats
associs au ot d'information utilis pour la vrication de la condentialit. Des dtails sur
l'utilisation de l'analyse statique pour la vrication de politiques de condentialit ainsi qu'une
prsentation des ds associs sont donns. On note que l'auteur eectue un lien entre la con-
dentialit et l'intgrit : la condentialit requiert qu'une information ne soit pas transmise dans
des destinations incorrectes tandis que l'intgrit demande que des informations ne soient pas
transmises depuis des sources incorrectes. Si ces deux dnitions ne prennent ni la temporalit
des transferts ni la persistance des informations en compte, elles donnent une ide des pro-
prits de scurit au niveau du langage o les sources et destinations sont des variables. Un
programme, en calculant des valeurs errones, peut corrompre l'intgrit d'informations sans
inuence extrieure. Une vrication complte de l'intgrit est donc plus dicile mettre en
uvre car elle demande une preuve de correction de l'intgralit du programme. Les auteurs
mettent aussi l'accent sur la dicult vrier les ots d'information sur des langages de bas ni-
veau car la structure de celui-ci est perdu la compilation. L'analyse statique et l'interprtation
abstraite [Cousot & Cousot 1977] sont cependant considres prometteuses pour la vrication
de ots d'information dans un contexte de scurit.
Les preuves formelles constituent aussi un moyen de garantir la scurit. Les auteurs
de [Andronick et al. 2005] utilisent un systme base d'annotations, spciant formellement
les fonctionnalits du programme en terme de prconditions et postconditions. Ces fonctionna-

lits couples une reprsentation formelle du programme extraite du code source forment un
modle de haut niveau sur lequel des proprits de scurit peuvent tre vris l'aide d'outils
de preuve. Les auteurs utilisent ces systme et modle an de vrier le mcanisme de journali-
sation du systme d'exploitation. Leur approche produit une garantie forte du fonctionnement
du mcanisme et donc de la scurit des oprations d'criture en eeprom associes. Les auteurs
de [Blazy & Leroy 2005] proposent une approche similaire mais utilisent un modle de la m-
moire mi-chemin entre la reprsentation mmoire C et une reprsentation mmoire matrielle.
Ces derniers donnent en plus des indications sur le temps d'excution ncessaire l'excution
des gnrations et vrications de preuves. Aucune indication sur le cot en temps ncessaire
la dnition de ces preuves n'est donne. Les rsultats de [von Oheimb et al. 2003] laissent
cependant penser que de telles preuves peuvent passer l'chelle dans des contextes industriels.
L'auteur de [Lanet 2000] met quelques rserves sur l'utilisation de mthodes formelles pour tout
un projet dans un cadre industriel car le cot ncessaire leur mise en place dans un processus
existant est important. La dnition des spcications formelles ainsi que la connaissance des
outils de preuve ncessaires rend dicile cette mise en place. Une utilisation limite des parties
d'un systme peut cependant, sous certaines conditions, tre praticable.
Un exemple de proprit de scurit, exprime formellement directement sur le code source,
est le ot d'information scuris. Ce ot d'information scuris est dni dans le modle tabli
par Denning comme une structure en treillis. Cette structure symbolise spatialement les niveaux
de scurit prsents dans un systme. L'auteur de [Zanotti 2002], en utilisant ce modle, donne
la dnition suivante de ce treillis : un ensemble partiellement ordonn (SC, ), avec C un
ensemble ni de niveaux de scurit muni de la relation d'ordre partiel (aussi appel relation
de dominance). Chaque variable x utilise l'intrieur du programme possde un niveau de
scurit x. Il est suppos que ce niveau de scurit est dtermin statiquement et qu'il ne peut
changer l'excution. La dnition suivante est tablie :
Dnition 1 (Flot d'information scuris) Si x1 et x2 sont deux variables du programme

et qu'il existe un ot d'information de x1 vers x2 , le ot peut tre autoris si et seulement si
x1 x2
Avec cette dnition, l'hypothse xant le niveau de scurit l'excution entraine que des
cas particuliers ne peuvent tre pris en considration.
Listing 2.1 Cas particulier
int generique[2] = {1234,0}; // un tableau avec une information 1

// sensible 1234 et une non sensible 0 2
int apdu; // variable qui transmet des informations 3
// lextrieur de la carte 4
apdu = generique[0]; // affectation qui pose un problme 5
// de scurit 6
envoie_terminal( apdu ); // fonction qui divulgue linformation 7
Dans le listing 2.1, on ne peut pas associer de niveau de scurit au tableau generique qui
contient des informations avec des niveaux de scurit antagonistes. La variable apdu, laquelle
on peut aecter un niveau de scurit bas, pose un problme de scurit si elle est la cible
d'une aectation d'une information sensible. Avec la dnition prcdente, il n'est pas possible
de dterminer si cette aectation est autorise ou pas. De plus, supposons que l'aectation est
2.1. Introduction, approche et hypothses 53
apdu = generique[1];. Celle-ci devrait tre autorise. Cependant, en cas d'attaque physique,
l'eet matriel provoqu peut perturber le code interprt de telle manire retrouver apdu =
generique[O];. Les attaques physiques posent donc des problmes de scurit supplmentaires.
Dans ce chapitre, nous donnons des dnitions de proprits de scurit qui prennent en
compte les problmatiques exposes ci-dessus en introduisant des notions supplmentaires. Ces
dnitions s'inspirent de concepts mentionns dans les contributions de cette section. Elles es-
saient de rpondre la problmatique d'exprimer des notions de scurit sur un langage de
programmation alors que celui-ci peut, sous attaque, ne pas avoir le comportement souhait.
2.1.2 Dcomposition de fonctionnalit

La scurit d'une fonctionnalit du programme, telle qu'elle est dcrite dans les spcications
fonctionnelles, est fortement lie l'avantage qu'un attaquant pourrait tirer du fait de russir son
attaque. Nous avons dni dans le chapitre prcdent, dans la section 1.3.7, ce que nous appelons
le gain pour l'attaquant. Le modle de scurit est construit sur l'tude des gains potentiels de
l'attaquant lorsqu'il ralise des attaques contre une fonctionnalit du code.
Sans attaque, les proprits de scurit seraient naturellement garanties puisque le code
fonctionnel est cens, par construction, respecter les proprits de scurit voulues. Dans ce cas,
des contre-mesures additionnelles ne seraient pas ncessaires. En cas d'attaque, une rponse
scuritaire doit tre dclenche si une proprit de scurit n'est pas respecte. Il est possible
qu'une attaque n'ait pas d'eet ou que l'eet ne perturbe pas assez l'excution pour qu'une
proprit de scurit soit viole. Cependant, dans le cas contraire, une contre-mesure de scurit
doit contrecarrer l'attaque. Les contre-mesures sont donc places titre prventif dans le code.
Celles-ci ne doivent pas empiter sur le fonctionnel et changer le comportement attendu. Dans le
chapitre suivant, nous dveloppons la notion d'attaquant, dans cette section nous prsentons
travers un exemple comment exprimer les besoins de scurit sur le code partir des spcications
fonctionnelles.
Listing 2.2 Exemple d'une implmentation basique d'un mcanisme d'authentication
void auth(void) 1
{ 2
pin = get_pin(); 3
if (pin == 1234) 4
} 6
Dans l'exemple du listing 2.2, implmentant une fonction d'authentication basique, un

gain pour l'attaquant serait d'obtenir le jeton d'authentication avec le mauvais PIN (ou sans
vrication du PIN). L'objectif fonctionnel de la fonction auth est dcrite dans les spcications
du programme. Pour exprimer le besoin en scurit de cette fonctionnalit, l'expert en scurit
doit donc s'intresser aux spcications et en dduire le ou les gains pour l'attaquant. Les besoins
en scurit peuvent alors s'exprimer en fonction de l'inverse de ces gains.
2.1.3 Dcomposition en lments du langage

Une fonctionnalit s'implmente l'aide d'informations et de logique. Cela se traduit, au
niveau du code source, par des lments conteneurs comme des variables ou des tableaux et
des lments logiques comme des conditions (if) ou des rptitions (for, while) assembls pour
remplir l'objectif d'une fonctionnalit (l'incrment d'un compteur et sa mise jour en mmoire
eeprom, par exemple).
L'implmentation d'une fonctionnalit peut faire intervenir du code source dirents en-
droits du programme. Les lments conteneurs et logiques sont alors rpartis dans direntes
fonctions. De plus, dans l'ensemble du code implmentant une fonctionnalit, seul un sous-
ensemble de celui-ci peut avoir du sens en terme de scurit. L'expert en scurit et le dvelop-
peur doivent donc s'associer pour dterminer le code qui doit tre protg.
Les points du programme ainsi dnis reprsentent les points d'attaque principaux du pro-
gramme par rapport une fonctionnalit. Suivant l'implmentation du programme, des points
d'attaque indirects peuvent tre trouvs. Si une condition est un point d'attaque, les aectations
des variables impliques dans cette condition sont des points d'attaque indirects. L'ensemble de
ces points d'attaque aussi appels chemin d'attaque doivent tre pris en compte an de com-
pltement scuriser une fonctionnalit. Les oprations associes ces points dans le programme
peuvent alors tre caractrises. Ainsi, une proprit de scurit peut se traduire en contraintes
sur des lments du langage. Soit des besoins de scurit de haut niveau comme par exemple :
cette condition doit tre excute ;

ce calcul doit tre ralis ;
ce point dans l'excution du programme, pour ce scnario, cette variable doit avoir une
telle valeur ;
cette action doit tre eectue avant telle action.
Ces besoins vont engendrer des contraintes sur les lments du langage.
pour excuter le code de la branche then d'un if, la condition impliquant l'galit entre
deux variables doit tre vraie ;
cette variable locale doit tre incrmente ;
cette variable globale de la machine d'tat doit tre mise jour cet endroit du programme ;
l'appel cette fonction doit tre ralis seulement si cette variable a t vrie a priori.
Dans un environnement sans attaque, ces contraintes sont naturellement garanties, ce qui
n'est pas le cas en prsence d'attaque. On a ici l'intuition que, s'il existe une dpendance d'infor-
mation entre deux variables du programme, cette dpendance est relaye en matire de scurit
l'intrieur du programme. Cette dpendance met aussi en vidence le lien de consquence entre
les informations abrites dans des lments conteneurs et les lments logiques du programme.
Une relation de consquence inverse existe aussi. Ces liens sont la base des chemins d'attaque
indirects et sont donc importants pour la scurit. Une dernire notion visible ici est l'quiva-
lence des consquences entre plusieurs points d'attaque. En eet, empcher l'excution d'une
des branches d'une condition revient sauter l'excution du code correspondant la branche
ou fausser l'valuation de la condition pour qu'elle excute l'autre branche ou encore faus-
ser un terme de la condition pour que la branche souhaite soit excute. Il existe donc des
chemins d'attaque plus ou moins directs permettant d'atteindre et d'exploiter une vulnrabilit
fonctionnelle. Ces notions sont exploites dans la suite de cette thse.
Pour plus de prcision, on dnit une proprit de scurit un niveau proche d'une opration
unitaire dans le code source. Ainsi, an de scuriser entirement une fonctionnalit, qui peut
contenir un nombre consquent d'oprations mmoires et logiques, il convient de dcomposer
celle-ci en autant d'oprations unitaires scuriser et donc d'instances de proprits de scurit
garantir an d'assurer la scurit globale de la fonctionnalit.
2.2. Formalisme utilis 55
2.2 Formalisme utilis

2.2.1 Information et conteneur
La notion d'information et celle de conteneur sont importantes pour la comprhension des
proprits de scurit. Un programme embarqu sur une puce est une suite d'instructions qui
modie et transforme des informations en rponse des informations de la part du terminal. Ces
informations transitent travers des conteneurs dnis au niveau du langage de programmation.
Ainsi, on peut dnir la notion de conteneur au niveau du langage de programmation.
Dnition 2 (Conteneur et Information) Un conteneur C contient une information I un

instant t. Un conteneur est un lment physique dans le systme carte puce - terminal.
Soit PIN un objet fonctionnel, on note Ipin l'information associe cet objet et Cpin un
conteneur abritant cette information.
Dirents cas de gure sont envisageables lorsque ces notions sont projetes sur le code source.
Une variable, une ligne donne du code source, permet d'accder un emplacement physique
qui contient une information. Cette information prend la forme d'une valeur numrique. l'ex-
cution du programme, cette information est modie, transmise, duplique, eace. Cependant,
elle reste vhicule de conteneur conteneur.
Listing 2.3 Transfert d'information par conteneur
int apdu; 1
int pin = 1234; 2
apdu = 0000; 3
apdu = pin; 4
Dans le listing 2.3, le conteneur Capdu de l'objet nomm apdu correspond la variable apdu
dans le code. L'information abrite par ce conteneur est Iapdu qui a pour valeur 0000 puis 1234
aprs transfert d'information de la variable pin la ligne 4. On remarque que cette information
est transmise au conteneur apdu sans tre eace du conteneur pin.
Un conteneur abrite, un instant prcis, une valeur. Cette valeur est son information par
dfaut. Cette valeur peut cependant concider, de manire fortuite ou non, avec la valeur d'in-
formations abrites par d'autres conteneurs. Ainsi, la ligne 4, l'information Iapdu du conteneur
apdu est 1234 qui est aussi, cause de la duplication de l'information, l'information Ipin du
conteneur Cpin . Donc aprs l'excution de cette ligne de code, on a Iapdu = Ipin .
Listing 2.4 volution d'une information par aectation directe de valeur
int pin; 1
pin = 0000; 2
pin = 1234; 3
La valeur d'une information peut aussi voluer par aectation directe sans provenir d'un
autre conteneur. Dans le listing ci-dessus, Cpin = pin avec Ipin = 0000. Aprs l'aectation de la
ligne 3, on a Cpin = pin avec Ipin = 1234.
Ainsi, un instant donn, un objet fonctionnel peut se trouver rparti grce son information
dans dirents conteneurs. On peut aussi remarquer qu'au niveau du code source, le nom d'une
variable n'est pas reprsentatif d'un objet fonctionnel qui est seulement caractris par une
information.
2.2.2 Ensemble d'informations visibles
Grce la notion de conteneur et d'information, nous pouvons maintenant dcrire ce qu'est

une information observable par un attaquant et aussi dans quel cas la condentialit de cette
information est respecte ou compromise. Nous cherchons ici caractriser la divulgation d'une
information au travers de conteneur.
Le code du listing 2.5 permet d'illustrer les direntes notions dnies dans cette section. La
gure 2.1 prsente les transferts d'information lors de l'excution de ce code et leur visibilit en
fonction de la puissance d'observation d'une attaquant.
Listing 2.5 Transfert d'information sans attaque
int var1, var2, pin, clef, mem, apdu; 1

mem = 88888; 2
pin = 1234; 3
var1 = pin; 4
var2 = var1; 5
var2 = mem; 6
apdu = var2; 7
print_terminal(apdu); 8
clef = 536237; 9
var1 = clef; 10
La gure 2.2 montre les dirents points de vue que peut avoir un attaquant et les infor-
mations qui lui sont accessibles. Chacun de ces points de vue est caractris par l'ensemble des
conteneurs qu'un attaquant est en mesure d'observer. Ces derniers sont dnis en fonction des
capacits de l'attaquant. La couleur utilise rete la sensibilit de l'information abrite par
un conteneur : rouge et rose pour sensible et vert pour non sensible. La gure permet de vi-
sualiser l'volution des informations l'intrieur du code. Dans cette gure, en se plaant au
niveau du terminal, les informations transitant par les conteneurs Capdu sont visibles. Avec des
moyens d'observation plus avancs, comme l'observation des canaux cachs, un attaquant peut
aussi avoir accs aux informations contenues dans Cvar1 ou Cvar2 . Avec une sonde physique, un
attaquant observe les informations transitant par un conteneur mmoire Cmem . Les conteneurs
Cpin et Cclef (et donc les informations qu'ils peuvent contenir) restent invisibles un quelconque
observateur.
Dans ce scnario, si l'attaquant se place du point de vue du terminal, il peut prendre connais-
sance des informations du conteneur apdu ainsi que celles des variables var2 et mem, par transfert
d'information. L'information 1234, initialement enregistre dans la variable pin, reste conden-
tielle car l'attaquant est incapable d'observer, depuis le terminal, le contenu des variables pin
ou var1.
Un critre important est le moment d'observation de l'attaquant. Ainsi, si un attaquant a

accs, par canaux cachs, aux informations abrites par le conteneur var1 l'instant t1, il a
accs l'information sensible 1234. Cependant, s'il observe ce mme conteneur t2, il a accs
une autre information sensible 536237. Une dfense contre les canaux cachs peut donc tre de
rduire le champ de vision de l'attaquant au moment o des donnes sensibles sont manipules
en mmoire ou rendre une excution sensible non direntiable d'une excution non sensible.
Interne Carte Elements observables
mem pin var1 var2 apdu clef Terminal Canaux_caches Sonde_materielle
88888
1234
1234
Vision attaquant t1
1234
88888
88888
remplace
1234
88888
88888
536237
536237
536237
remplace
1234
Vision attaquant t2
mem pin var1 var2 apdu clef Terminal Canaux_caches Sonde_materielle
Figure 2.1 volution des informations l'intrieur des conteneurs correspondant au code du
listing 2.5
Terminal
Capdu Canaux cachs

Ccl
Cpin
Cvar2
Cvar1
Cmem
Sonde matrielle
Figure 2.2 Avec une mthode d'observation et un point d'observation certains conteneurs,
ainsi que l'information qu'ils abritent, sont visibles
Forte capacit d'observation Il est intressant de remarquer que suivant les comptences
d'observation de l'attaquant, certaines informations peuvent lui tre directement accessibles.
Ainsi, si l'attaquant peut, par observation, avoir constamment accs aux informations abrites
par le conteneur PIN, il est capable de compromettre la condentialit de n'importe quelle in-
formation sensible transfre l'aide de ce conteneur. La gure 2.3 illustre cet exemple, dans le
cas o l'attaquant est capable, par canaux cachs d'avoir constamment accs aux informations
transitant par le conteneur Cpin . Ainsi, si le code du listing 2.5 est excut, l'attaquant a di-
rectement accs l'information 1234, sans mme avoir besoin d'eectuer une attaque physique
modiant le ot d'information.
Un moyen de se protger contre un attaquant de ce niveau est de chirer l'information avant

son passage dans le conteneur ; ce qui n'est pas toujours possible. Se protger contre les attaques
par canaux cachs est donc une tche ardue, o caractriser prcisment l'attaquant est ncessaire
mais dicile. Les dfenses implmentes doivent prendre en compte une surapproximation des
capacits de l'attaquant pour ne pas tre mise en dfaut.
Attaque physique modiant le ot d'information En cas d'attaque, le ot d'information

peut changer et de nouveaux transferts d'information peuvent tre cres. Le listing 2.6 reprend
l'exemple prcdent en simulant la non excution de l'instruction var2 = mem; ligne 6. Ce type
d'attaque correspond, par exemple, une attaque par saut d'instruction.
Une telle attaque peut introduire une vulnrabilit provoquant la perte de condentialit
d'une information sensible. La gure 2.4 montre l'volution des informations l'intrieur du
Terminal
Capdu Canaux cachs

Ccl
Cvar2
Cvar1
Cmem
Sonde matrielle
Cpin
Figure 2.3 La condentialit est directement compromise si une information se trouve dans
un conteneur visible
Listing 2.6 Transfert d'information avec attaque
int var1, var2, pin, cle, mem, apdu; 1

mem = 88888; 2
pin = 1234; 3
var1 = pin; 4
var2 = var1; 5
var2 = mem; 6
apdu = var2; 7
clef = 536237; 9
var1 = clef; 10
mem pin var1 var2 apdu clef Terminal
88888
1234
1234
1234
1234
536237
536237
536237
remplace
1234
1234
mem pin var1 var2 apdu clef Terminal
Figure 2.4 volution des informations l'intrieur des conteneurs correspondant au code du
listing 2.6
code du listing 2.6. On observe que l'information sensible Ipin valant 1234 se trouve maintenant
dans un conteneur visible par l'attaquant Capdu alors que ce n'tait pas le cas. Le saut d'une
instruction a ainsi chang le ot d'information au travers des variables jusqu' communiquer
une information sensible, qui devait rester condentielle, l'extrieur de la carte.
Dans un contexte o le systme peut tre soumis des attaques physiques, nous devons
considrer, en plus des capacits d'observation de l'attaquant, ses capacits agir sur le systme.
Ainsi, nous introduisons TA , le type d'attaque, symbolisant les capacits d'action de l'attaquant,
autrement dit, comment il peut russir perturber l'excution du code. Un exemple de capacit
d'action est la possibilit d'introduire des sauts dans le code mentionn prcdemment. Si TA =
, alors l'attaquant a la capacit d'action d'un utilisateur standard par le biais du terminal.
Dnition 3 (Ensemble d'lments observables sous attaque) L'ensemble des informa-

tions obtenues en observant le conteneur C dans l'hypothse d'une attaque de type TA est not
Obs(C, TA ).
Pour violer la condentialit d'une information secrte, un attaquant cherche dcouvrir

directement l'information par canaux cachs en analysant les fuites d'information gnres lors
de l'excution du programme. Il peut aussi provoquer une faute physique an de faire drailler
le ot d'information et amener des informations sensibles dans des conteneurs visibles depuis
l'extrieur. Ainsi, la combinaison des capacits d'observation et d'action de l'attaquant peut lui
permettre de compromettre la scurit du systme.
2.2.3 Zone de garantie

En plus des notions d'information et de conteneur, une notion de zone doit tre dnie
pour restreindre le champ d'application d'une garantie souhaite. En eet, sachant que plusieurs
informations peuvent tre contenues des instants dirents dans un mme conteneur, il convient
de borner l'application d'une proprit de scurit une zone particulire o elle a du sens.
Dnition 4 (Zone de garantie) Une zone de garantie ZG est une zone de code correspon-
dant un contexte temporel dans lequel le respect d'une proprit de scurit est demande par
la garantie de scurit.
Par exemple, on cherche garantir que le PIN reste condentiel pendant la commande
Verify_PIN() mais pas pendant la commande Update_Record(). Cette zone de garantie se traduit
en une zone de code dans une ou plusieurs fonctions C o on cherche vrier la proprit pour
cette information.
2.2.4 Type d'attaques

Les attaques sont des lments perturbateurs qui vont modier le comportement du systme
l'excution. Dirents types d'attaques sont possibles en fonction des capacits de l'attaquant.
Les dirents types d'attaques sont dvelopps dans le chapitre 3 et regroupe dans un modle
d'attaque. Pour l'instant, nous supposons que les attaques se dcomposent en deux types : celles
sur les informations manipules par le programme et celles contre le programme manipulant ces
informations. Comme mentionn prcdemment, une attaque peut modier le ot d'information
et amener des informations secrtes dans le champ de vision de l'attaquant. Cependant, elle peut
aussi directement compromettre l'intgrit de certaines donnes ou oprations, lui permettant
ainsi d'inuencer les dcisions prises l'excution.
2.2.5 Formalisation d'une proprit de scurit

On peut maintenant exprimer de manire gnrique une proprit de scurit en faisant
apparatre les principales composantes de celle-ci.
Dnition 5 Soit la notation suivante, pour une proprit de scurit P :
P (x, a, ZG , code)
avec
P : la proprit ;
x : des lments sensibles ou actifs protger ;
a : un ensemble d'attaques suivant un modle d'attaque ;
ZG : une zone de garantie pour la proprit de scurit ;
code : le code source sur lequel s'applique la proprit (sous entendu par la suite).
Les lments sensibles x protger sont des lments du programme qui ont un rle fonction-
nel important dans la ralisation de tches sensibles. chacun de ces lments, il est possible
d'associer une garantie de scurit souhaite (condentialit, intgrit). Cette garantie doit tre
respecte un moment de l'excution du programme symbolis ici par la notion de zone de
garantie ZG . On veut, par exemple, assurer que le PIN reste condentiel lors de la commande
Verify_PIN(), que le compteur d'essai du PIN reste intgre lors de la mme commande ou qu'une
cl reste condentielle et intgre lors de son utilisation dans un calcul cryptographique.
Rappelons qu'un attaquant se modlise en deux capacits distinctes : sa capacit observer
le systme et sa capacit agir sur ce systme. La formalisation des proprits de scurit
prend en compte ces deux capacits qui seront dtailles par la suite dans le chapitre 3. La
capacit d'observation rajoute une composante la proprit, pour la condentialit, tandis que
la capacit agir est symbolise ici par a.
Les lments dcrits ci-dessus sont les principales composantes constituant des proprits de
scurit que nous dclinons dans les prochaines sections de ce chapitre. Nous formalisons ainsi
deux besoins de scurit : la condentialit et l'intgrit.
2.3 Condentialit d'une information

Pour cette proprit, un conteneur est dni comme un ou plusieurs lments matriels
(case mmoire ram ou eeprom, registre) d'un systme embarqu pouvant abriter un moment
donn une information. En projetant cette reprsentation sur le C, les variables sont donc des
conteneurs labelliss. On note C un conteneur.
On souhaite dnir la notion de condentialit sur le code source d'un projet. Or, dans un
code source, la notion d'information est dicilement reprsentable directement. Passer par un
conteneur abritant cette information permet de s'aranchir de cette dicult. Cela permet aussi
au dveloppeur de spcier dans le code un conteneur et d'induire partir de ce conteneur les
informations qu'il convient de protger en condentialit.
Une information a une dure de vie dans un conteneur. Cette dure de vie dbute quand
l'information est introduite dans le conteneur et se termine lorsque une nouvelle information
prend sa place. Cette dure de vie d'une information l'intrieur d'un conteneur ne doit pas
tre confondue avec la dure de vie du conteneur, dnie comme la dure pendant laquelle ce
conteneur est accessible. Au sens C, c'est--dire en adoptant le point de vue du programme, une
variable locale est un exemple de conteneur dont la dure de vie est quivalente la fonction o
elle est dnie.
Le listing 2.7 donne un exemple de transfert d'information entre plusieurs conteneurs bas
sur l'exemple du listing 2.5. Nous nous servons de cet exemple pour illustrer les notions de dure
de vie d'un conteneur et de dure d'une information dans un conteneur.
Dans ce code, la dure de vie des conteneurs var1, var2, pin, clef, mem, apdu, des variables
locales, est conne la fonction foo(). Un conteneur global a une dure de vie dbutant au
moment de sa cration en mmoire et terminant quand il n'est plus possible d'accder la
mmoire lui tant ddi. La dure de vie d'une information l'intrieur d'un conteneur est
dirente. Par exemple, la dure de vie de l'information 1234 l'intrieur du conteneur var2
dbute en ligne 7 et se termine en ligne 8. Cet exemple est reprsent dans la gure 2.5.
2.3. Condentialit d'une information 63
Listing 2.7 Exemple de transfert d'information dans des conteneurs
void foo(void) 1
{ 2
int var1, var2, pin, clef, mem, apdu; 3
mem = 88888; 4
pin = 1234; 5
var1 = pin; 6
var2 = var1; 7
var2 = mem; 8
apdu = var2; 9
clef = 536237; 11
var1 = clef; 12
} 13
Mmoire interne Carte Dures de vie
msg pin var1 var2 apdu clef Terminal conteneur var2 information 1234 dans var2
88888
1234
1234
1234
88888
88888
remplace
1234
88888
88888
536237
536237
536237
remplace
1234
msg pin var1 var2 apdu clef Terminal conteneur var2 information 1234 dans var2
Figure 2.5 Exemple de dure de vie d'un conteneur et dure de vie d'une information
l'intrieur d'un conteneur
On note CI l'ensemble des informations I contenues par C pendant cette dure de vie.
Cette notion est lie mais pas strictement quivalente l'existence d'une criture pour cette
variable. Par exemple, dans le listing 2.7,var2 I = ?, 1234, 88888 car, avant d'tre
1234, la variable var2 pointe sur une case mmoire qui contient une information
initialise
inconnue ?. En analysant le reste du programme, il serait possible de dduire la valeur de cette
information comme la dernire criture eectue dans ce conteneur. L'information 1234 est
ensuite remplace par 88888 lors du transfert d'information la ligne 8. C I est donc dni
par les critures dans le conteneur qui sont les moyens de modier les informations contenues
partir du code source.
2.3.1 Condentialit sous attaque

Nous dnissons, au niveau du code source, la proprit de condentialit suivante.
Proprit 1 (Condentialit d'une information en cas d'attaque) Soient C un conte-

neur parmi l'ensemble des variables V du programme, M un modle d'attaque dnissant les
attaques possibles, O un conteneur dans l'ensemble des variables observes VO , on dit que les
informations abrites par C sont condentielles sous attaque si et seulement si
C V, O VO , I information telle que C I, on a I

/ Obs(O, M)
On note cette proprit :

e(C, O, M)
Conf identialit
Autrement dit, quelle que soit l'information abrite dans un conteneur sensible, cette infor-
mation ne doit jamais se trouver dans un conteneur observ par l'attaquant, mme en cas de
perturbation.
Par exemple, il peut tre intressant de garantir la condentialit de pin pour le code d'au-
thentication du listing 2.7. Si l'on considre apdu comme un lment potentiellement observable
par l'attaquant, on peut exprimer la condentialit de pin sous la forme :
e(pin, apdu, M)
Conf identialit
Dans cette notation, Cpin a t simpli pin et Capdu apdu.
Cependant pour pouvoir isoler avec prcision une information partir d'un conteneur, il est
ncessaire de dnir une zone dans le code dans laquelle nous considrons que les informations,
lues partir du conteneur, sont retenues pour la proprit de condentialit. En eet, hors d'une
telle zone, un conteneur peut contenir des informations peu importantes du point de vue de la
condentialit.
2.3.2 Zone de gnration d'information d'un conteneur

Un conteneur peut abriter des informations direntes pendant une dure de temps. Or cette
dure peut tre associe des lignes de code successives crant une zone de code.
Dnition 6 (Zone de gnration) Une zone de gnration Z pour un conteneur C est une
zone de code qui s'exprime en ligne l'aide d'une ligne de dbut ld et une ligne de n lf . On
adopte la notation suivante. Z = ld : lf pour dnir cette zone de code.
sensible mais sans code contre attaques physiques
{ 2
int jeton_auth = 0x0F; 3
int user_pin, card_pin, pin_cpt; 4
card_pin = read_eeprom(&ee_card_pin); // zone de gnration 6
if (user_pin == card_pin) && (pin_cpt < 3) 8
{ 9
} 11
else 12
{ 13
pin_cpt++; 14
} 15
} 17
De cette dnition dcoule la dnition suivante :
Dnition 7 (Ensemble d'information d'un conteneur dans une zone de code)

Z
L'ensemble des informations I contenues dans C dans une zone de code Z est not C I .
Ces zones vont permettre de prciser les informations sensibles considrer pour un conteneur
gnrique qui peut contenir la fois des informations sensibles et non sensibles.
Proprit 2 (Condentialit restreinte en cas d'attaque) Soient C un conteneur parmi

l'ensemble des variables V du programme, M un modle d'attaque, O un conteneur dans l'en-
semble des variables observes VO , Z une zone de code, on dit que les informations abrites par
C dans la zone Z sont condentielles sous attaque si et seulement si
Z
C V, O VO , I information telle que C I , on a I
/ Obs(O, M)

e(C, O, M, Z)
Conf identialit
Autrement dit, quelle que soit l'information contenue dans un conteneur sensible, pendant
une dure correspondant l'excution du code dans une zone, cette information ne doit jamais
se trouver dans un conteneur observ par l'attaquant mme en cas d'attaque.
En appliquant cette proprit sur le listing 2.8, la zone de gnration d'information sensible
pourrait tre la zone entre les lignes 6 et 6. La proprit applique ce code source s'crit :
e(card_pin, jeton_auth, M, L6 : L6)

Conf identialit
Dans ce code, seule la ligne 5 est considre par le dveloppeur comme pertinente du point
de vue de la condentialit de l'information prsente dans la variable card_pin. On suppose que
jeton_auth peut tre communiqu l'extrieur du programme et donc constitue un vecteur de
fuite d'information.
2.3.3 Zone de garantie de condentialit

En plus de la zone de gnration d'information, on peut restreindre la zone d'application o
l'on considre que la proprit de condentialit doit rester valide. Cette restriction est ncessaire
an de permettre au dveloppeur de prciser plus nement une zone d'intrt dans laquelle il
serait ncessaire d'assurer la condentialit d'une information pour la scurit. Cette notion
de zone de garantie a t dnie prcdemment dans la dnition 4 de la section 2.2.3. Cette
zone permet au dveloppeur de limiter temporellement les conteneurs considrs observables par
l'attaquant. On peut rednir la proprit de condentialit sur le code en incorporant cette
notion de zone de garantie.
Proprit 3 (Condentialit restreinte en cas d'attaque garantie sur une zone)

Soient C un conteneur parmi l'ensemble des variables V du programme, M un modle
d'attaque, O un conteneur dans l'ensemble des variables observes VO , soient Z une zone de g-
nration d'information et ZG une zone de garantie, on dit que les informations manipules dans
la zone Z par C sont condentielles dans le champ ZG dans l'hypothse d'une attaque physique
si et seulement si pour toute information I contenue dans C pour un temps correspondant
l'excution du code dans Z :
le conteneur O observable par l'attaquant n'appartient pas la zone de code ZG mme en
cas d'attaque physique ;
ou ce conteneur appartient la zone ZG et l'information I n'est pas observable dans ce
conteneur mme si le code est attaqu par une attaque de type M.
La phrase prcdente peut tre formalise de la manire suivante :
Z
C V, O VO , I information telle que (C I), on a :
O / ZG (O ZG I / Obs(O, M))
Cette dernire expression se simplie en :
(O ZG I
/ Obs(O, M))
e(C, O, M, Z, ZG )
Conf identialit
En appliquant cette proprit sur le listing 2.9, la zone de garantie concerne est la zone entre
les lignes 8 et 15. En eet, le dveloppeur souhaite que l'information contenue dans la variable
card_pin reste condentielle pendant sa comparaison avec user_pin et ne soit pas dvoile hors
de la fonction avec jeton_auth. On peut crire cette proprit :
e(user_pin, jeton_auth, M, L6 : L6, L8 : L15)

Conf identialit
Les zones de gnration et de garantie doivent tre fournies par un dveloppeur. En s'ap-
puyant sur l'implmentation de son code, celui-ci doit dterminer la sensibilit des informations
manipules pour tablir les zones de gnration. Les zones de garanties sont cres partir de
l'emplacement des vecteurs de fuite d'information dans le code. Ces zones peuvent tre disjointes.
En eet, elles reprsentent des notions direntes : Z est une zone de gnration d'informations
sensibles du point de vue de la condentialit tandis que ZG est une zone de garantie souhaite
par le dveloppeur o ces informations condentielles ne doivent pas tre visibles au travers de
conteneurs observables par l'attaquant.
sensible mais sans code contre attaques physiques
{ 2
card_pin = read_eeprom(&ee_card_pin); // zone de gnration 6
if (user_pin == card_pin) && (pin_cpt < 3) // dbut de zone de garantie 8
{ 9
} 11
else 12
{ 13
pin_cpt++; 14
} // fin de zone de garantie 15
} 17
2.3.4 Avantage pour l'attaquant et granularit de l'information

Cette dnition de la condentialit ne prend pas en compte le fait qu'une information
puisse tre chire. En eet, si une information secrte apparat dans un conteneur observable
par l'attaquant la condentialit de cette information n'est pas viole si celle-ci est chire.
part dans des cas de cryptographie en bote blanche [Joye 2008], une information telle qu'une cl
de chirement ou de dchirement est dvoile au moment de son utilisation. An de simplier
notre formalisation, nous n'introduirons pas de granularit supplmentaire sur l'information
d'un conteneur. Nous considrons que lors du choix des zones de gnration, le dveloppeur
slectionne des zones de code pour un conteneur alors que celui-ci contient une information
dchire. Cependant, si on souhaite prendre en compte la granularit de l'information dans la
proprit de condentialit, on peut rednir la fonction d'observation comme suit :
Dnition 8 (Rednition de la fonction d'observation) Soient O un conteneur observ

parmi l'ensemble des variables, M un modle d'attaque, F() une fonction transformant une
information I telle que (C I), on a :
I
/ Obs(O, M) F(I) Obs(O, M) =
Le listing 2.10 donne un exemple de dchirement d'une information enregistre chire en

eeprom pour son utilisation dans une comparaison. Si l'attaquant est capable d'observer le
conteneur pin_carte la ligne 5, il a accs l'information secrte. Cependant, ce moment
de l'excution, cette information est chire donc sa condentialit n'est pas compromise. D'un
autre ct, si l'attaquant est capable d'observer le conteneur pin_carte la ligne 9, il a accs
l'information secrte en clair et donc sa condentialit est compromise.
Listing 2.10 dchirement d'une information condentielle
void verif_pin() 1
{ 2
int pin_carte; 4
pin_carte = lecture_eeprom(&pin_carte_chiffre); 5
int pin_utilisateur; 6
pin_utilisateur = lecture_terminal(); 7
// dchiffrement de pin_carte_chiffre 8
pin_carte = dechiffre(pin_carte_chiffre); 9
if (pin_utilisateur == pin_carte) 10
{ 11
} 13
} 14
A titre d'information, dans le cas spcique d'une comparaison, on peut viter de dchirer
une information sensible en chirant l'lment compar comme dans le listing 2.11. Ainsi, l'in-
formation secrte n'est jamais dchire et un attaquant en observant le conteneur pin_carte
n'importe quel moment de l'excution n'a jamais accs l'information en clair. Cette technique
permet de scuriser l'information secrte et d'assurer sa condentialit.
Listing 2.11 Comparaison chire d'une information condentielle
void verif_pin() 1
{ 2
int pin_carte; 4
pin_carte = lecture_eeprom(&pin_carte_chiffre); 5
int pin_utilisateur; 6
pin_utilisateur = lecture_terminal(); 7
// chiffrement de pin_utilisateur 8
pin_utilisateur = chiffre(pin_utilisateur); 9
if (pin_utilisateur == pin_carte) 10
{ 11
} 13
} 14
En rajoutant une telle granularit l'information, on peut dcrire de manire prcise les
cas qui avantagent l'attaquant. En eet, sans cette granularit, on peut seulement dire que
l'attaquant a pris connaissance d'une information sensible. Or, si celle-ci est chire, l'attaquant
n'en tire aucun avantage.
On peut faire l'hypothse qu'on se place volontairement dans des cas o les informations sont
dchires, la suite ou non d'une attaque, pour l'observation des conteneurs et la vrication
de la proprit de condentialit. On peut aussi prendre en compte le fait qu'une information
peut tre chire ou non lors de la formalisation grce cette granularit de l'information. On
peut ainsi exprimer le gain pour l'attaquant :
Conf identialit
e(C, O, M, Z, ZG ) Iclair Obs(O, M)
avec Iclair , une information secrte en clair c'est--dire non chire.
Ainsi, au niveau du code, on doit spcier des APIs de transformation pouvant tre forma-
lises de la manire suivante :
2.4. Intgrit 69
C 0 < Ichif f re >x f (C 1 < Iclair >)

et
C 2 < Iclair >x f 1 (C 3 < Ichif f re >)
avec C < I > un conteneur C abritant I un instant donn, B x A un transfert d'informa-
tion du conteneur A vers le conteneur B , f () une fonction de transformation, f 1 () son inverse.
Par exemple dans le listing 2.11 la ligne 9, f () = chiffre() et dans le listing 2.10 la ligne 9,
f 1 () = dechiffre().
Ces fonctions de transformations permettent notamment d'isoler dans le code les endroits o
une information secrte est dchire et de se concentrer sur ces portions de code pour l'analyse
et la vrication de la condentialit de cette information.
2.4 Intgrit
Dans cette section, nous nous intressons l'intgrit d'excution d'un programme sous
attaque. Par rapport la proprit prcdente, nous ne poussons pas aussi loin le formalisme,
le but tant de clarier les notions d'intgrit.
2.4.1 Accs un conteneur et zone de garantie

Pour accder l'information abrite dans un conteneur, on a recours une opration de
lecture qui copie l'information du conteneur dans un autre conteneur pour pouvoir l'utiliser.
Pour remplacer l'information abrite dans un conteneur, on a recours une opration d'criture
qui crasera l'information abrite par une nouvelle information.
Dnition 9 (Accs en lecture et criture un conteneur) On note respectivement

r(C) et w(C), les oprations de lecture et d'criture d'un conteneur C ; r(C) et w(C) sont
respectivement les valeurs lues et crites associes chacune d'elles.
A partir de ces dnitions, on peut dire que l'excution d'un code se rsume des squences
d'oprations de lecture et d'criture de multiples conteneurs, d'oprations logiques et arithm-
tiques et des branchements de ot. En cas d'attaque physique, comme prsent en section 2.2.4,
l'attaquant peut modier l'information stocke dans un conteneur, autrement dit eectuer une
opration d'criture sur ce conteneur ou sauter des instructions conscutives du code. Le cha-
pitre 3 dveloppera ces lments. Nous supposons galement que l'attaquant n'a le droit qu'
un unique essai pour son attaque, ce qui est raisonnablement le cas le plus rpandu l'heure
actuelle. En cas d'attaque contre un conteneur, le programme modie la squence des lectures/-
critures concernant celui-ci. Dans cette nouvelle squence, une opration additionnelle d'criture
de ce conteneur a t insre ou une ou plusieurs oprations de lecture / criture auront t
enleves. On note wa (C) cette criture additionnelle et S(C) = [x1 , x2 , xn ] avec xi = r ou
xi = w une squence ordonne de lectures / critures de C.
Si une opration d'criture additionnelle est insre, 4 scnarii sont possibles en fonction de
l'emplacement de l'attaque dans la squence. Ils peuvent tre regroups en deux comportements :
S1a (C) = [r, wa , r] et S1b (C) = [w, wa , r] : l'criture additionnelle modie la valeur lue par
la seconde lecture ;
S2a (C) = [r, wa , w] et S2b (C) = [w, wa , w] : l'criture additionnelle n'a pas d'eet car
l'criture suivante annule son eet.
Seuls les cas S1a (C) et S1b (C), o l'criture additionnelle provoque une modication de
l'intgrit de la valeur lue, nous intressent. En supposant que le code fonctionnel du projet est
correct et donc qu'il n'existe pas de variable lue avant d'tre initialise, on peut dire que dans
une squence S(C), la lecture d'un conteneur est toujours prcde par une criture de celui-ci.
On peut donc dduire que, les seules zones intressantes pour vrier une proprit d'intgrit
d'un conteneur l'excution sous attaque, sont les zones de type (S1a (C) et S1b (C)). On peut
englober ces deux types de zones dans une zone gnrique dbutant par une criture de ce
conteneur suivie d'une ou plusieurs lectures de ce mme conteneur. La dernire lecture x0 doit
correspondre une lecture fonctionnelle dont on souhaite garantir l'intgrit. On note ZG cette
zone de code de garantie. Cette zone est formalise par :
SZG (C) = [w0 , x1 , x2 , xn , x0 ] avec xi = r

Illustrons la dnition de cette zone de garantie partir du code fonctionnel du listing 2.12.
Ce listing ralise la lecture eeprom du conteneur card_pin dans le but de l'utiliser pour une
comparaison. On souhaite, dans cet exemple, garantir l'intgrit de ce conteneur an d'tre sur
que l'information utilise dans la comparaison n'est pas fausse.
Listing 2.12 Zone de garantie souhaite pour l'intgrit du conteneur card_pin sous attaque
{ 2
card_pin = read_eeprom(&ee_card_pin); // dbut de zone de garantie 6
if (user_pin == card_pin) && (pin_cpt < 3) // fin de zone de garantie 8
{ 9
} 11
else 12
{ 13
pin_cpt++; 14
} 15
} 17
Si, dans le listing 2.12, on souhaite garantir l'intgrit du conteneur card_pin partir de sa
premire aectation mmoire jusqu' sa comparaison avec le PIN prsent par l'utilisateur, une
zone de garantie spcique doit tre dnie. Le contexte sensible du point de vue de la scurit
dbute au moment de la premire criture d'une information sensible dans ce conteneur. Ce
contexte dbute donc en ligne 6, o la valeur est lue depuis l'eeprom. Ce contexte se termine la
ligne 8, o sa valeur est compare et permet en cas de succs d'obtenir un jeton d'authentication.
Ainsi, dans ce cas, on a : ZG = L6 : L8.
2.4.2 Intgrit en lecture et criture

Pour tablir la proprit d'intgrit d'un conteneur sous attaque physique, nous devons nous
assurer que les oprations de lecture ou criture d'un conteneur dans la zone considre s'ef-
fectuent correctement. Sans attaque, le programme s'eectue correctement par hypothse sur
2.4. Intgrit 71
le compilateur et sur la plate-forme d'excution. Dans le cas d'une attaque, la perturbation

peut agir sur une lecture ou une criture ou un calcul intermdiaire conduisant une mauvaise
criture. Notre dnition d'intgrit de conteneur cherche exprimer le fait que le programme
s'excute correctement vis vis du code manipulant ce conteneur. La rponse scuritaire peut
aussi tre intgre cette dnition comme nous l'avons fait pour la proprit de condentialit.
Dans un premier temps, on dnit cette notion sans considrer les contre-mesures.
Le but est de dnir l'intgrit sur une squence d'instructions manipulant un conteneur
C. Pour cela, on dcompose une squence en oprations atomiques de lectures/critures sur ce
conteneur. Une attaque ne viole pas l'intgrit d'une opration de lecture si la valeur lue est
identique celle qui serait lue sans attaque. On dnit de mme l'intgrit d'une opration
d'criture.
On note X #a l'intgrit d'une opration X sous attaque a.
Dnition 10 (Intgrit de lecture d'un conteneur) Pour une attaque donne a, on dit
qu'une lecture du conteneur C est intgre vis vis de a si et seulement si la valeur lue sous
attaque est la mme que celle lue sans attaque.
r(C) #a ra (C) = r(C)

o ra (C) reprsente la lecture de C dans le programme attaqu par a.
Dnition 11 (Intgrit d'criture d'un conteneur) De mme pour l'criture, on dnit

l'intgrit de w(C) par :
w(C) #a wa (C) = w(C)

o wa (C) reprsente l'criture dans C dans le programme attaqu par a.
On souhaite maintenant dnir l'intgrit d'un conteneur, sous attaque physique, en prenant
en compte un rponse scuritaire KC du systme pouvant survenir plus tard dans l'excution
du programme. On note l'appel cette rponse suivant la convention LTL de logique temporelle
F (KC) c'est--dire que KC doit survenir plus tard dans l'excution du programme.
On peut maintenant tablir la proprit suivante pour l'intgrit :
Proprit 4 (Intgrit d'un conteneur l'excution sous attaque) Soient a une at-
taque parmi l'ensemble A des attaques considres, C un conteneur parmi l'ensemble V des
variables, ZG une zone de garantie dnie par une criture suivie d'une ou plusieurs lectures de
C : SZG (C) = [w0 , r1 , . . . rk ] et KC la rponse scuritaire, l'intgrit de C est garantie dans ZG
sous attaque si et seulement si

wa
/ SZG (C)

a A, on a : w0 # a F (KC)

a
i [1, . . . , k] ri #


Int
egrit
e(C, ZG , a)
Pour un ensemble d'attaques A, on dnit naturellement l'intgrit d'un conteneur vis vis
de cette famille par :
Int e(C, ZG , A) a A, Int

egrit egrit
e(C, ZG , a)
Cette proprit d'intgrit peut s'interprter de la manire suivante : soit une zone de code
dbutant par l'aectation d'une variable une valeur (criture) dont on souhaite garantir l'in-
tgrit pour une utilisation future (lecture). On souhaite avoir cette garantie en prsence d'une
attaque physique. Si la consquence de cette attaque physique impacte la variable considre,
cette consquence est quivalente : l'insertion d'une opration d'criture sur cette variable un
endroit du code ou le saut d'une plusieurs instructions aectant cette variable. Nous justions
cette armation dans notre modle d'attaque que nous dveloppons dans le chapitre 3. Garantir
l'intgrit de la variable partir de son aectation jusqu' son utilisation revient donc s'assurer
que :
la premire aectation n'a pas t saute sinon lors de l'utilisation la variable a pour valeur
la dernire valeur abrite par le conteneur lu ;
la premire aectation reoit la bonne valeur ;
chaque lecture dans la zone n'est pas saute sinon l'intgrit de lecture, lors de l'utilisation
fonctionnelle, est viole ;
chaque lecture lit la valeur attendue ;
l'attaque n'introduit pas l'quivalent d'une criture de ce conteneur dans la zone considre.
En eet, si cette criture induite par l'attaque apparat avant la zone, elle est crase par
la premire criture (considre comme correcte) de la zone. Si celle-ci apparat aprs la n
de la zone, elle n'aecte pas la dernire lecture du conteneur dans la zone et par consquent
son utilisation, ce qui est ce que nous cherchons garantir.
Si une des conditions prcdentes n'est pas respecte, le systme doit ragir de manire
approprie et dclencher une rponse scuritaire. Si une telle rponse est dclenche, on estime
que l'intgrit du conteneur considr est assure.
Gnralisation une excution L'intgrit telle que dnie par la dnition 4 ne prend en
compte qu'un seul conteneur dans une zone prcise ZG dlimite par un criture et une lecture
de ce conteneur. Or une squence d'excution est compose de plusieurs squences dlimites
par de multiples accs ce conteneur. Garantir l'intgrit d'un mme conteneur tout au long
d'une excution revient garantir l'intgrit de celui-ci sur l'ensemble des zones de garantie ZG .
Gnralisation de multiples conteneurs et dpendance : Application l'intgrit

d'excution Pendant un ot d'excution, un conteneur peut dpendre de plusieurs autres
conteneurs en termes de dpendance d'information. Dans l'instruction x = a + b;, on voit qu'
l'excution de cette ligne de code, l'information contenue dans la variable x la suite de a et
b. Si on considre le code depuis le dbut de l'excution du programme jusqu' l'interprtation
de cette instruction, on peut tablir que l'intgrit de cette instruction dpend de l'intgrit de
l'ensemble des conteneurs qui inuent sur cette instruction par dpendance d'information ainsi
que l'ensemble du code logique (conditions, boucles, sauts, appels) menant cette instruction.
Si on fait l'hypothse que le code logique est valide et n'est pas inuenc par une attaque
physique, on peut dire que l'intgrit de l'excution du code depuis le dbut de l'excution
2.4. Intgrit 73
jusqu' une instruction est garantie si l'ensemble des conteneurs impliqus dans cette excution
sont intgres.
2.4.3 Avantage pour l'attaquant

L'avantage que peut tirer un attaquant d'une modication en intgrit d'un conteneur (et
par consquent de l'information qu'il abrite) dpend des spcications fonctionnelles du produit
et donc du sens associ l'information. En eet, supposons deux variables servant de compteurs
cpt1 et cpt2 : cpt1 comptabilise le nombre d'essais eectus par l'utilisateur pour s'authentier en
prsentant un PIN, cpt2 comptabilise le plafond maximum de retrait de la carte. Un attaquant
a un intrt minimiser cpt1 mais maximiser cpt2. Ainsi compromettre l'intgrit de ces
variables n'est avantageux pour l'attaquant uniquement si cela lui permet d'aller l'encontre
d'un comportement fonctionnel li la scurit.
2.4.4 Intgrit d'excution

Le but de l'intgrit d'excution, pour le dveloppeur, est de garantir qu'au niveau fonctionnel
certaines oprations menant la ralisation d'une tche sont bien eectues. Le premier problme
pour le dveloppeur est l'identication de ces oprations critiques d'un point de vue fonctionnel
et d'un point de vue de la scurit. Prenons pour exemple la vrication du PIN dans laquelle
une partie du code enregistre des rapports pour auditer le code en cas d'erreurs. Ce code n'est
pas critique vis--vis de la vrication, cependant incrmenter le compteur d'essai du PIN l'est.
Le dveloppeur est seulement intress par la garantie des instructions du code contribuant de
manire eective la ralisation d'une fonctionnalit principale. Dans cet exemple, il s'agit de
la vrication ou de sa scurit. Vrier la scurit de mcanismes supplmentaires, qui n'ont
pas directement trait la fonctionnalit ou sa scurit, n'est pas utile pour le dveloppeur.
Dans la section prcdente, nous avons dni l'intgrit d'un conteneur sous attaque physique.
Dans cette section, nous allons largir ce concept d'intgrit une instruction de code. Une
instruction de code est n'importe quelle instruction du langage de programmation, ici le C. Pour
raliser une tche, certaines instructions sont critiques.
Dans la section 2.4.2, on a dni r(C) # et w(C) #, l'intgrit d'une opration de lec-
ture ou d'criture d'un conteneur C. Nous pouvons tendre cette dnition n'importe quelle
instruction du langage de programmation en prenant en compte le ot d'excution et en intro-
duisant le concept de saut. En eet, les oprations de lecture et d'criture telles que nous les
avons dnies jusqu' prsent ne supposent pas l'existence d'un ot d'instructions. Cependant,
on peut dnir un ot d'instructions comme une suite de transformations d'informations et de
conteneurs suivie d'un saut vers une autre instruction Instr0 excuter not y Instr0 . On peut
formaliser cette nouvelle proprit sur l'intgrit d'une instruction Instr de la manire suivante.
Cette formalisation se base sur les dnitions d'un tat mmoire du systme et de la transition
d'tats mmoires.
Dnition 12 (tat mmoire) L'tat mmoire E d'un systme un instant t est dni par
l'ensemble des couples (C, I) avec C un conteneur et I l'information abrite dans ce conteneur
l'instant t
Dnition 13 (Transition d'tat mmoire) L'excution d'une instruction permet de passer
d'un tat mmoire un autre avec pour modication les consquences de l'instruction sur la
mmoire. On note E ( E0 la transition entre un tat E et un tat E0 suite l'excution d'une

Instr
instruction Instr.
On peut alors tablir la proprit suivante :
Proprit 5 (Intgrit d'une instruction) Soient E1

l'tat mmoire du systme avant l'ex-
0
cution de Instr , E2 l'tat mmoire du systme aprs l'excution de Instr . Soit Instr l'instruc-
tion qui suit Instr dans le ot d'excution du code. On a l'intgrit d'excution de l'instruction
Instr si et seulement si les deux conditions du systme suivant sont remplies.

E1 ( E2
Instr # Instr
y Instr0
Listing 2.13 Intgrit d'excution d'une condition en C
instr_avant(); 1
if (x == 0) 2
{ 3
then_exec(); 4
} else 5
{ 6
else_exec(); 7
} 8
instr_apres(); 9
Ainsi pour une condition en C, i.e., un if comme implment dans le listing 2.13, l'intgrit
de cette instruction de condition peut s'appliquer sur le code de la manire suivante :

EL2 ( EL8
If
If #
y Instr : L9
Cette dnition peut tre aussi tre tendue aux boucles. Par exemple, prenons la boucle
implmente en 2.14.
Listing 2.14 Intgrit d'excution d'une boucle en C
int i; 1
int y = 1; 2
instr_avant(); 3
for (i=0; i<10; i++) 4
{ 5
y++; 6
} 7
instr_apres(); 8
On peut appliquer la proprit d'intgrit d'excution cette boucle.

EL4 ( EL8
F or # F or
y Instr : L8
Un appel de fonction, dont on peut trouver une implmentation dans le listing 2.15, est aussi
pris en compte par la proprit.
2.5. Conclusion 75
Listing 2.15 Intgrit d'excution d'un appel de Listing 2.16 Intgrit d'excution d'un appel de
fonction en C fonction en C
int x = 5; 1 void f(int x) 10

int y; 2 { 11
instr_avant(); 3 x++; 12
y = f(x); 4 return x; 13
instr_apres(); 5 } 14
Pour cet appel de fonction, on crirait :

EL4 ( EL5
Call # Call
y Instr : L5
Ces proprits, dclines sur le code source, permettent d'exprimer des problmatiques de
scurit uniquement partir d'une reprsentation mmoire des informations. Il est maintenant
possible en vriant des tats mmoires du systme de vrier des garanties de scurit sur le
code source. Grce de telles proprits, un dveloppeur est capable d'exprimer les besoins de
scurit de son application en terme de condentialit et d'intgrit.
2.5 Conclusion
Nous avons formalis le problme de scurit travers direntes proprits faisant intervenir
des lments de code et dans certains cas la rponse scuritaire du systme. L'adoption de cette
perspective permet au dveloppeur d'exprimer ses besoins en terme de garanties de scurit sur
son code. Disposer de ce formalisme permet aussi de cerner l'ensemble de la scurit fonctionnelle
du systme en restant au niveau du code source de haut niveau. Le fait de garder cette perspective
prsente un rel avantage pour le dveloppeur de faon abstraire la complexit d'un code de
bas niveau. Un avantage sous-jacent de la reprsentation choisie est que la notion de conteneur et
d'information peut tre projet aussi bien au niveau matriel qu'au niveau logiciel. Cette cohsion
permet d'unier une reprsentation assembleur et C. Elle permet galement aux proprits d'tre
appliques de manire transparente par rapport au langage utilis car il est toujours possible pour
une information donne de trouver le conteneur correspondant. Les proprits de scurit ont
aussi t cres de manire regrouper les possibilits d'attaque au sein mme de la proprit.
Cette particularit fait que ces proprits se prtent bien la vrication de la scurit sous
attaques physiques. De plus, ces proprits ont t penses de manire faciliter l'implmentation
des vrications concrtes en testant la correspondance des tats mmoires obtenus avec et sans
attaque. Enn, ces proprits de scurit sont indpendantes de la technique d'analyse et de
vrication utilises ce qui les rend particulirement adaptes pour exprimer gnriquement des
besoins de scurit au niveau du code source. Cette formalisation devrait pouvoir s'appliquer
n'importe quelle architecture embarque voire n'importe quel code soumis des attaques par
fautes physiques.
Des limitations sont cependant associes aux proprits de scurit dnies dans ce chapitre.
En eet, ces proprits traitent sparment la condentialit et l'intgrit des informations.
Cette sparation permet l'utilisation d'un modle proche de la mmoire lors de leur dnition.
Elle empche aussi toute vrication simultane des deux proprits potentiellement lies par
une relation de causalit, ce qui peut tre souhait lors de la rsolution de preuves. Il est aussi
important de noter que ces dnitions imposent plusieurs limitations :
La condentialit de l'excution du code n'est pas considr du point de vue fonctionnel ;
La smantique du code et ses consquences sur la condentialit des informations ne sont
pas prises en compte ;
Le modle d'attaquant est limit de manire raliste dans ses capacits d'observation et
d'action.
Pour des formalisations qui lvent les deux dernires limitations, le lecteur peut se rfrer
[Myers et al. 2004] et [Balliu & Mastroeni 2009]. Les auteurs proposent des notions de d-
classication d'information et de robustesse aux attaques particulirement intressantes dans
un contexte cryptographique. L'approche adopte ici est plus simple mais a priori plus facile
mettre en pratique.
En eet, les limitations sont associes plusieurs avantages qui rendent l'utilisation des pro-
prits plus faciles exploiter. L'intgrit d'une information repose sur l'intgrit du conteneur
qui l'abrite. Cette dnition permet de seulement considrer des squences de lectures et d'cri-
tures de variables dans le code. Cette dnition est associe celle d'intgrit d'excution d'une
instruction ou suite d'instructions. tant donn que cette intgrit d'excution est lie des
tats mmoires du systme, il est toujours possible de crer des images totales ou partielles de la
mmoire des instants de l'excution. Cette particularit simplie l'laboration de vrications
pour cette proprit et autorise le choix des points de vrication si les informations sont lies
entre elles. De plus, en faisant l'hypothse que la condentialit d'une information repose sur
l'intgrit d'excution d'appels des interfaces de programmation (de chirement par exemple),
l'ensemble des vrications peut tre ramen l'intgrit d'excution de code. Des hypothses
similaires permettent de dlguer des vrications ce qui rend chacune d'elle moins complexe. Le
fait de faire de telles hypothses a aussi l'avantage de permettre de cloisonner les vrications.
Ces hypothses doivent cependant tre faites avec soin et parfois tre accompagnes de vrica-
tions de scurit supplmentaires. Par exemple, les interfaces cryptographiques ne doivent pas
utiliser le mme tampon d'entre et de sortie. Le cloisonnement des vrications et la sparation
des proprits de condentialit et d'intgrit du point de vue fonctionnel force la cration des
vrications de scurit unitaires qui lors d'une campagne de vrication permet d'isoler et de
remonter jusqu' l'origine d'une vulnrabilit.
Malgr ce travail de formalisation sur les proprits de scurit qui sont les priorits d'Ober-
thur Technologies, ces proprits ne seront pas rutilises telles quelles dans les chapitres suivants.
En eet, cette thse a men le travail de formalisation en parallle des mthodes proposes ci-
aprs. Les notions de scurit (condentialit, intgrit) sur lesquelles sont bases les proprits
tablies sont aussi prsentes dans les Critres Communs mais ne prennent pas en compte l'impl-
mentation par le dveloppeur. Elles sont exprimes un niveau fonctionnel, ce qui empche une
utilisation directe sur le code source par celles-ci. Cependant, tout comme les Critres Communs
regroupent dans un schma de scurit un ensemble d'exigences de scurit, les proprits de
scurit tablies dans ce chapitre doivent tre regroupes pour former une politique de scu-
rit complte et cohrente sur l'ensemble du code source. De plus, les notations mathmatiques
doivent encore tre adaptes avant une utilisation dans un systme informatique an d'tre
manipules par des programmes.
Par ailleurs, une fois cette politique de scurit crite, les mthodes dveloppes dans les
chapitres qui suivent peuvent se servir de cette politique en entre des vrications ou des
2.6. Perspectives 77
tests. Par exemple, pour le chapitre 4, ces proprits projetes dans un langage de type ACSL
permettent une vrication statique de celles-ci. Comme nous le verrons plus loin, ce problme
est en soi dlicat. Par ailleurs, pour le chapitre 5, le test de la proprit est assure par un oracle
(interne ou externe au programme test) an de savoir si la proprit est viole. Dans ce cas, il
faut explicitement programmer la vrication de la proprit en projetant ses composantes sur
le code source, par exemple une variable tester.
Le chapitre qui suit, s'intresse maintenant aux attaques et leurs consquences bas niveau.
Il dnit clairement le modle d'attaque et permet de cerner la nature des attaques considres
dans cette thse.
2.6 Perspectives
2.6.1 Aspects smantiques
Les proprits de scurit exprimes dans ce chapitre se basent sur une reprsentation simple
proche de la mmoire. Ce point de vue est adopt an de faciliter sa projection sur le code source
tout en mettant les proprits ainsi exprimes la porte du dveloppeur. Ce point de vue ignore
la smantique associe au langage de programmation pour se concentrer sur des lments qui
peuvent tre tests par une analyse de la mmoire. Rajouter des aspects de smantiques, no-
tamment les prdicats dvelopps dans [Balliu & Mastroeni 2009] et [Myers et al. 2004] peuvent
apporter une nouvelle dimension aux proprits et leur vrication. La condentialit se prte
bien cette approche o l'analyse smantique du code peut permettre d'intgrer des carac-
tristiques de fuites lies la smantique du code source. Ces caractristiques permettent de
dduire, partir de ce qu'un attaquant apprend par canaux cachs, s'il est capable ou non de
compromettre la condentialit d'informations sensibles.
2.6.2 Temporalit des proprits

Les proprits de scurit tablies dans ce chapitre peuvent servir exprimer, sur du code C,
des besoins en scurit tels que la condentialit et l'intgrit. Ces proprits prennent en compte
la possibilit d'attaques parvenant modier le code source. Si ces proprits couvrent une partie
des besoins en scurit d'un systme, elles ne traitent pas en dtail du squencement des opra-
tions respecter fonctionnellement. Le squencement des oprations dans le code peut avoir une
importance vis--vis des spcications mais aussi de la scurit. Exprimer de telles proprits de
logique temporelle et les vrier sur du code C sous attaque a dj t trait [Andouard 2009]
l'aide de Model Checking. L'auteur de [Leroy 2004] donne un aperu du fonctionnement du
Model Checking utilis pour vrier des proprits de contrle de ot. Cependant, une repr-
sentation haut niveau de ces proprits temporelles ne couvre pas une ventuelle optimisation
du compilateur sur l'implmentation du code. Intgrer des aspects temporels aux proprits de
scurit peut permettre de les tendre et augmenter le pouvoir d'expression du dveloppeur pour
exprimer ses besoins en scurit.
2.6.3 Prise en compte du compilateur

En embarqu, pour des raisons de tailles et de performances, les codes sont fortement optimi-
ss au moment de la compilation. Alors que des codes compils avec, par exemple, gcc sont par
dfaut optimiss un niveau 0 (-O0), les codes embarqus peuvent tre optimiss des niveaux
bien suprieurs (-O9 ou -O10, par exemple). Si cette compilation apporte des gains, elle peut
parfois tre faite au dtriment de la scurit. En eet, les passes d'optimisation suivent des sch-
mas de rarrangement et regroupement de code. Dirents exemples de ces passes sont dcrites
dans la rfrence [Keil 2012]. Prenons par exemple le schma de regroupement de code commun
en sous blocs pour un gain de taille. Cette optimisation peut, en modiant l'ordre des opra-
tions, aller l'encontre de l'intention du dveloppeur ; celui-ci souhaitant une squence prcise
d'opration sur laquelle repose la scurit de son implmentation. L'agencement des registres est
aussi faite par le compilateur de manire transparente au niveau du code source et pour le d-
veloppeur. Le manque de contrle n au niveau C de ces aspects d'optimisation peut introduire
des failles de scurit dans le systme. Cependant, l'optimisation la plus prjudiciable est sans
doute le schma qui retire le code inutile et notamment les redondances dans le code. En eet,
doubler des oprations est une technique trs utilise en tant que contre-mesure. Le compilateur
incapable de direncier une redondance souhaite pour la scurit d'un code redondant inutile
optimise les deux cas de la mme manire. Cette dernire optimisation peut trs bien retirer une
dfense implmente par le dveloppeur. De plus, les passes d'optimisation sont empiles, ce qui
peut rendre le sens du code gnr trs loign de celui de dpart et dicile relire. Ainsi, pour
vrier si une scurit implmente au niveau C est bien ecace une fois optimise par le com-
pilateur, le dveloppeur doit s'intresser au code assembleur gnr et vrier si celui-ci respecte
bien les garanties de scurit souhaites. Une solution possible ces problmatiques de scurit
est d'optimiser partiellement le code des niveaux d'optimisation infrieur an de prserver la
smantique de dpart. Les compilateurs peuvent fournir des directives (#pragma GCC optimize)
permettant cette optimisation partielle. Une autre mthode consiste modier le code de dpart
en introduisant une forme de code que le compilateur ne sait pas optimiser.
Une perspective possible serait d'introduire un aspect temporel aux proprits de scurit
dj tablies et exprimes sur le code source. En projetant cet aspect sur le code assembleur
gnr par le compilateur, on pourrait s'assurer que des contraintes de squencement sont bien
respectes mme aprs compilation.
2.6.4 Thorie de l'information

Une dernire perspective pourrait tre de raner ces proprits, notamment la proprit de
condentialit, an de prendre en compte des lments de la thorie de l'information. On pour-
rait alors introduire et dnir prcisment des transferts d'information partiels entre conteneurs
ou des transformations d'informations. L'information visible par l'attaquant pourrait ainsi tre
caractrise au travers d'un modle de fuite [Prou & Rivain 2009]. Ces nouveaux lments pour-
raient alors tre utiliss pour rpondre de manire ne des problmatiques de condentialit
plus complexes et tablir des dfenses plus sophistiques [Coron et al. 2007].
2.6.5 Gnration automatique de proprits

Une des dicults l'adoption gnralise dans un contexte industriel de vrications de
la scurit par preuves formelles est le temps associ la cration des preuves. Cette dicult
s'applique aussi aux proprits de scurit. Une perspective intressante serait de russir gn-
rer ces preuves ou proprits directement depuis les spcications fonctionnelles. Certains essais
dans ce sens ont dj t ralis [Moebius et al. 2009]. Une extension de cette perspective est la
cration d'un compilateur capable partir de ces preuves de gnrer le code source associ res-
pectant les contraintes de performance propre l'embarqu. Le respect de proprits de scurit
aprs la compilation peut aussi tre eectu l'aide d'un compilateur certi [Blazy et al. 2006].
Chapitre 3
Modle d'attaque
Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.2 Caractrisation de l'attaquant . . . . . . . . . . . . . . . . . . . . . . . 82
3.2.1 Capacit d'observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.2.2 Capacit d'action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.3 Modlisation des consquences haut niveau . . . . . . . . . . . . . 87
3.4 Modle d'attaque physique haut niveau . . . . . . . . . . . . . . . . 88
3.4.1 Eets des attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . 88
3.4.2 Importance des attaques par nop et par saut . . . . . . . . . . . . . . . 90
3.4.3 Attaques de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.4.4 Attaques de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.4.5 Dcalage d'interprtation du code . . . . . . . . . . . . . . . . . . . . . 97
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.6.1 Prise en compte d'attaques d'un ordre suprieur . . . . . . . . . . . . . 105
3.6.2 Extension du modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.1 Introduction
tablir un modle d'attaque permet de cadrer les capacits de l'attaquant considr dans la
vrication des proprits de scurit. Les proprits de scurit envisages sont dcrites dans le
chapitre 2. Dans ce chapitre, nous caractrisons un attaquant par sa capacit observer et agir
sur un systme. Dans ce chapitre, nous dnissons dans quelle mesure un attaquant peut utiliser
ces capacits. Nous adoptons un point de vue particulier consistant ramener les eets matriels
un niveau d'abstraction suprieur. Nous prsentons d'abord d'autres modles existants et les
comparons au modle propos. Ensuite, nous exposons notre modle, ses caractristiques et ses
implications.
Crer un modle formel, prcis et complet des capacits d'un attaquant est ncessaire an
d'apporter une validation correcte de la scurit. En eet, on peut prendre l'exemple d'une
implmentation cryptographique qui, alors qu'elle tait prouve scurise, n'a pas rsister la
dcouverte de fautes physiques non couvertes par les hypothses de la preuve [Wagner 2004]. La
scurit de l'implmentation a donc t invalide.
Nous introduisons dirents modles existants permettant de caractriser les fautes physiques
sur un composant et montrons qu'ils sont peu adapts la vrication de proprits de scurit
au niveau du code source. Nous introduisons ensuite notre propre modle prenant en compte le
point de vue du dveloppeur et exprim au niveau du code source C d'un projet embarqu. Nous
82 Chapitre 3. Modle d'attaque
montrons comment ce modle peut servir pour transcrire de manire complte les eets possibles
d'une attaque physique sur le code source et en dduire les impacts fonctionnels rsultants.
Ce modle nous sert, dans les sections 4 et 5, crer des mthodes permettant de vrier le
fonctionnement du code C sous attaques physiques. Ces mthodes passent particulirement bien
l'chelle permettant de traiter des codes rels de carte puce. La mthodologie purement
logicielle tablie permet de prdire en avance de phase les vulnrabilits possibles d'un code C
face des attaques physiques par simulation sur le code source. Cette simulation permet, sans
changer les habitudes tablies de dveloppement et de test, de mettre en vidence les failles du
code pouvant tre exploites par un attaquant.
3.2 Caractrisation de l'attaquant

Tel que nous l'avons vu dans l'expression des proprits de scurit, un attaquant est ca-
ractris par sa capacit observer des lments du systme et en tirer une connaissance sur
des informations sensibles utilises lors de son excution. Un attaquant peut aussi utiliser cette
capacit d'observation an d'apprendre comment fonctionne le systme. Arm de cette connais-
sance, il peut agir sur ce systme et en modier le comportement l'excution. Cette capacit
d'action est une seconde comptence qui caractrise un attaquant. Nous dcrivons chacune de
ces deux capacits.
3.2.1 Capacit d'observation

Un attaquant, suivant les moyens et les connaissances dont il dispose, est capable en observant
un systme embarqu lors de son excution de dduire le fonctionnement interne de celui-ci. Il
est ventuellement aussi en mesure d'observer directement les donnes manipules. De telles
capacits d'observation peuvent trs facilement compromettre la condentialit d'informations
secrtes telles que les clefs de chirement utilises lors de calculs cryptographiques par la carte.
Dans un systme embarqu, les garanties en terme de scurit et de connement de l'informa-

tion sont remises en cause par les canaux cachs. Dans la gure 3.1, un utilisateur ou attaquant
du systme a la possibilit d'observer non seulement les entres et sorties du systme mais aussi
les fuites d'informations involontaires de celui-ci. Ainsi des informations sur les secrets contenus
dans le systme peuvent tre transmis l'extrieur par le biais de ces canaux auxiliaires. Ces
canaux remettent en cause le cloisonnement des secrets l'intrieur du systme. Les fuites par
ces canaux reprsentent les lments observables par un attaquant et ont t symboliss par la
notation Obs(C, TA ) dans la dnition 3 du chapitre 2. Cette notion a t dnie comme l'en-
semble des informations obtenues en observant le conteneur C dans l'hypothse d'une attaque
d'un certain type TA .
[De Haas 2007] donne de manire simple les principes physiques exploits dans des observa-
tions par canaux cachs ainsi que des exemples pratiques illustrant comment ils peuvent tre
utiliss pour compromettre un chirement des et rsa. Ces exemples montrent qu'il est possible
d'observer directement un secret lors de son utilisation en connaissant les signatures temporelles
ou les prols de consommation de courant des instructions ralises (si celles-ci sont distinctes).
Ces exemples montrent aussi qu'en comparant des excutions ralises avec des entres di-
rentes (dont l'entre valide) et en observant les fuites d'information obtenues par canaux cachs,
3.2. Caractrisation de l'attaquant 83
il est possible de dduire si l'entre prsente est valide. En plus de ces exemples, les principales
mthodes de scurisation contre ces canaux cachs sont aussi abordes de manire thorique.
FUITE D'INFORMATION
ENTRES SORTIES
SECRETS
Figure 3.1 Fuite d'informations par les canaux d'observation auxiliaires
Dans [Kocher 1996], les premires attaques par canaux cachs sont mises en uvre sur des al-
gorithmes cryptographiques en exploitant des informations acquises en mesurant les temps d'ex-
cution des calculs eectus. Ces canaux cachs sont bass sur l'observation de fuites involontaires
d'informations contenues dans les rayonnements physiques mis par le systme lors de son fonc-
tionnement. Direntes techniques d'observation et d'analyse sont maintenant employes. Outre
la mesure du temps d'excution, la mesure de la consommation de courant [Kocher et al. 2011]
ainsi que la mesure de l'mission lectromagntique [Quisquater & Samyde 2001] sont utilises.
Des techniques d'analyse avances utilisent une approche statistique base sur la rcolte et
l'analyse par corrlation de multiples traces de consommation de courant obtenues au cours de
l'excution du code [Kocher et al. 2011].
Si de telles techniques avances existent, les auteurs de [Kocher et al. 2011] arment que
des techniques d'observation simples sont susantes pour mettre en dfaut des implmenta-
tions cryptographiques non protges. Ces techniques ne sont pas nouvelles et doivent tre
considres lors de la scurisation d'un systme embarqu. Les auteurs de [Akkar et al. 2000],
discutent dj de direntes techniques d'analyse de ce type et donnent une mthodologie pour
russir concrtement de telles attaques. Des rsultats concrets d'attaques russies sont obtenus
dans [Gandol et al. 2001] o les principaux algorithmes cryptographiques comme le des et le
rsa sont mis en dfaut. Ces rsultats concrets ont pouss les auteurs de [Agrawal et al. 2002]
proposer un formalisme complet an de modliser les fuites passives d'information et l'appli-
quer aux fuites d'information par rayonnement lectromagntique. Ce modle appel adversa-
rial model repose sur un modle mathmatique bas sur la thorie de l'information. Il permet
l'aide des signaux de fuite observs combins une approximation statistique (gaussienne) de
prdire si les signaux observs correspondent une excution connue prise sur un composant
de rfrence. Si ce modle prend en compte la prsence d'un attaquant cherchant obtenir la
connaissance d'une information, il s'applique exclusivement aux signaux physiques observables
lors d'une excution et ncessite un apprentissage l'aide d'un composant de rfrence et dans
le cadre de fuites passives. Ce modle peut dicilement se traduire un niveau de perspective
proche du code source d'un programme et donc ne peut tre utilis tel quel par un dveloppeur
pour l'aider scuriser le code de son application.
Outre ces mthodes d'coute passive, il existe des mthodes d'coute active de type semi
invasives ou invasives ncessitant souvent une prparation physique de la carte. Ces mthodes
d'coute active utilisent des techniques qui font intervenir une sonde lectromagntique ou de
rcupration [Samyde et al. 2002]. Les techniques de sondage permettent d'obtenir de l'informa-
tion l'aide des missions lectromagntiques du composant et de dduire prcisment quelle
partie du composant est active au cours d'un calcul. Elles permettent galement de retrouver de
l'information par analyse de l'empreinte lectrique laisse en mmoire par rmanence.
Pour plus d'informations sur le sujet des attaques par canaux cachs, une bibliographie
a t compile la date d'octobre 2002 et a t publie sous la direction de J.-J. Quisquater
dans [Quisquater & Kouene 2002]. On y retrouve les principales mthodes dcrites ci-dessus. Une
liste de publications relative aux fuites d'information par canaux cachs et techniques associes
est maintenue l'adresse [SCL 2012].
Les techniques exposes ci-dessus montrent qu'un attaquant dispose d'une diversit de m-
thodes d'observation sa disposition. Bien que ces mthodes ncessitent parfois du matriel
sophistiqu, des plates-formes compltes sont maintenant disponibles [Riscure 2012] et rduisent
l'investissement et la technique ncessaires pour observer les fuites physiques d'un systme et
en tirer avantage. Cependant l'expertise ncessaire pour exploiter les rsultats fournis par ces
bancs est encore leve.
Les attaques mentionns dans la littrature ciblent souvent les mcanismes cryptographiques
du systme embarqu. Cependant, le reste du code fonctionnel du systme est lui aussi expos
aux mmes attaques. La conclusion de [Giraud 2007] amne aussi envisager les vulnrabili-
ts du reste du systme face aux attaques physiques. Pour soutenir cette armation, l'auteur
de [Aigner & Oswald 2011] montre qu'il est possible par observation de la consommation de
courant, de direncier deux instructions excutes par le processeur. Dans son exemple, les
MOV 0x00 peuvent tre direncis des MOV 0xFF ainsi que les JZ des JNZ qui forment des traces
de consommation bien distinctes si l'architecture matrielle du composant n'a pas t conue
pour ne pas mettre de fuites par rayonnement. On peut donc dduire qu'il est possible, pour
un attaquant sur un systme embarqu peu ou mal protg, non seulement de comprendre
le ot du code mais aussi d'obtenir des informations sur les donnes manipules, et ceci par
simple observation des canaux cachs. Le fait de connatre ces informations peut compromettre
la scurit du systme en soi ou guider l'attaquant lors d'une tentative visant perturber le
systme. Dans [Amiel et al. 2007] et [Clavier et al. 2010], les auteurs montrent la mise en uvre
des capacits d'observation an de guider une perturbation physique du systme.
Dans cette thse, nous nous intressons la visibilit de l'information transmise directement
l'extrieur par les sorties prvues du systme. L'observation par canaux auxiliaires peut ce-
pendant tre incorpore dans le formalisme propos en section 3.4 car celui-ci prend en compte
les ux indirects ou partiels d'information.
Le but de cette thse en rapport avec la fuite d'information se limite proposer un forma-
lisme dcrivant les eets des attaques an de vrier si une attaque physique peut forcer une
fuite d'information vers une sortie standard du systme. A la dirence des travaux cits prc-
demment, un tel modle est formalis au niveau du code source du logiciel considr an d'tre
au plus prs de la terminologie du dveloppeur. Il permet aussi une validation de proprits de
scurit garantissant la condentialit, l'intgrit et le bon fonctionnement de certaines parties
critiques du code. Enn, nous nous basons sur ce formalisme an de proposer des solutions de
vrication performantes.
3.2. Caractrisation de l'attaquant 85
3.2.2 Capacit d'action

S'il est possible d'observer le comportement d'un systme embarqu pendant son
utilisation avec les canaux cachs et d'en dduire des informations secrtes, le risque
est d'autant plus important qu'un attaquant est en plus capable d'agir sur le sys-
tme an d'en modier le comportement [Giraud & Thiebeauld 2004a]. Les techniques as-
socies ces modications de comportement prennent la forme d'apport d'nergie tels
que des surtensions hors des seuils de tolrance de la carte [Aumller et al. 2002], des
pointes de courant ou des modications de la temprature agissant sur l'horloge de la
carte [Anderson & Kuhn 1997], des mission de lumire [Skorobogatov & Anderson 2002] ou
lectromagntiques [Quisquater & Samyde 2002]. Les premiers cas d'applications de ces attaques
utilises pour mettre en dfaut des implmentations cryptographiques apparaissent dans les
annes 2000 [Biham & Shamir 1997] [Kmmerling & Kuhn 1999] [Boneh et al. 2001]. Cette ca-
pacit d'action allie la capacit d'observation utilise comme guide ou comme moyen de
compromission ouvre la porte de nouvelles attaques. Deux tudes recensent les dirents
vecteurs possibles dont dispose un attaquant an de perturber un systme embarqu par une
attaque physique : [Bar-El et al. 2006] et [Giraud & Thiebeauld 2004b]. Les attaques prsentes
ne demandent souvent que peu d'investissement et peuvent pour la plupart tre eectues sans
dtruire la carte ce qui les rend ralisables et particulirement dangereuses.
Les eets de ces attaques peuvent tre catgoriss suivant dirents modles d'eet de fautes
connus. [Gadellaa 2005] et [Nguyen 2011] rpertorient et expliquent ces modles de fautes :
Bit ip La valeur du bit est inverse par rapport la valeur qu'il aurait eu sans perturbation ;
Set et Reset La valeur du bit est force une valeur xe. On parle de set si la valeur est xe
1 et de reset si la valeur est xe 0 ;
Collage La valeur du bit est force sa valeur prcdente. On parle de collage 1 si la valeur
prcdente tait gale 1 et collage 0 sinon ;
Random La valeur du bit est force 0 ou 1 avec une probabilit de 50 %.
Le lecteur peut trouver une liste rcente et complte des attaques par fautes classies d'une
faon explicite la rfrence [Verbauwhede et al. 2011].
Ces fautes physiques utilises comme vecteur d'attaque ont une focalisation, une dure tem-
porelle [Quisquater & Kouene 2002] ainsi qu'une mthode d'analyse qui mne l'exploitation de
la vulnrabilit. Comme mthode d'exploitation, on peut mentionner l'attaque par safe error qui
par comparaison d'excutions du programme faut et non faut et la connaissance de la valeur
xe par la faute ainsi que le fait que la faute doit avoir un impact sur le rsultat, permet, dans
le cas d'une non raction de la carte l'attaque, de dduire la valeur de la case mmoire fausse.
Cette dduction se fait sans connaissance pralable et ne ncessite qu'une observation externe
des ractions du systme. Une autre mthode d'exploitation est la recherche de collisions. Alors
qu'il n'existait qu'un nombre dni d'entres produisant une certaine sortie, l'introduction d'une
faute augmente ce nombre d'entres possibles pour cette sortie. De telles collisions permettent
un attaquant de prsenter une entre incorrecte et d'obtenir une sortie correcte. Les tech-
niques d'exploitation ont constamment volu au cours du temps [Rankl & Eng 2003] et ont
contraint les fabricants de cartes puce adapter leur systme en implmentant de nouvelles
contre-mesures.
[Dutertre et al. 2010] donnent une explication des phnomnes physiques entrant en jeu dans
une attaque physique laser ainsi qu'un rcapitulatif des principaux modles de fautes connus
classs suivant les dirents critres mentionns ci-dessus. Le regroupement de ces modles de
faute permet de dterminer que les fautes considres sont soit des inversions ou collages sur un
bit, soit des random sur un octet. Pour notre modle d'attaque, nous choisissons d'adopter un
modle de faute sur un octet qui nous semble plus raliste dans la pratique.
Pour une explication des eets matriels des attaques par laser sur un composant embarqu,
le lecteur peut se rfrer [Canivet 2009]. L'auteur donne une caractrisation des eets des injec-
tions de fautes sur les lments matriels du composant. Il propose galement une classication
des eets d'une faute physique en 5 catgories suite des campagnes d'attaques par surtensions
et tirs lasers : sans eet, faute silencieuse, faux positif, erreur dtecte, erreur non dtecte. Dans
le chapitre 5, nous utilisons une classication qui se rapproche de celle-ci.
Dans la suite de cette thse, nous nous intressons l'eet de ces attaques sans nous pr-
occuper de la technique pratique mise en uvre pour la raliser. Nous nous concentrons es-
sentiellement sur les attaques optiques dont les eets ont t discutes en [Skorobogatov 2005]
et qui sont toujours d'actualit [Skorobogatov 2010] o l'auteur recommande au niveau logiciel
une vrication constante des accs mmoire. En eet, [Clavier 2007] mentionne dans sa thse
qu'il sut d'une faute d'un bit sur le premier xor du calcul d'un aes pour mettre en dfaut cet
algorithme. L'auteur stipule galement que la matrise d'une faute sur un bit est trs dicile.
Les autres attaques documentes laissent cependant penser qu'il est possible, avec des at-
taques physiques, de compromettre le comportement du code au del des accs mmoire. Ces
dirents types d'eets qui peuvent tre obtenus partir d'une attaque physique se traduisent en
une modication du code. Les auteurs de [Anderson & Kuhn 1997] mentionnent qu'il est possible
d'induire un saut conditionnel non prvu ou d'empcher qu'un saut conditionnel prvu soit eec-
tu. Ces techniques ont t utilises de manire pratique dans le pass notamment pour mettre
en dfaut les systmes de protection des chanes tlvises payantes [McCormac et al. 1995] ex-
pliquant l'importance de les prendre en considration aussi bien au niveau de la conception
matrielle [Guilley 2007] que de l'implmentation logicielle.
[Gadellaa 2005] qui travaille sur la Java Card fait un regroupement de l'ensemble des attaques
classes par moyen de mise en uvre, type d'eet, niveaux de comptence de l'attaquant et
matrise ncessaire pour mener bien les attaques. Il met galement en relation leurs eets sur
les variables au niveau logiciel. Il rane notamment le modle de faute en introduisant les quatre
dclinaisons suivantes pour les erreurs sur un bit :
Erreurs de bit prcis la faute aecte un seul bit du code ;

Erreurs de bit inconnu la faute aecte un seul bit, l'attaquant cible une variable mais ne
contrle pas prcisment o celle-ci est aecte ;
Erreurs de bit inconnu sur des variables inconnues la faute modie une seule variable
mais l'attaquant ne sait pas quelle variable est aecte ;
Erreurs alatoires la faute modie un nombre quelconque de variables.
Pour plus d'informations sur les dirents modles de fautes et contre-mesures associes
appliques un contexte cryptographique, le lecteur peut se rfrer [Otto 2005].
Dans notre modle, nous adoptons le mme point de vue que le modle de bit inconnu. Nous
supposons qu'un attaquant est capable de modier une variable connue une valeur inconnue
3.3. Modlisation des consquences haut niveau 87
en modiant uniquement un bit. Cependant, nous largissons ce modle pour prendre en compte
toute modication du code (incluant les modications d'opcodes) aectant un seul octet.
Les fautes dcrites dans ces modles de fautes sont ensuite utilises an de crer des vul-
nrabilits dans le programme qui est interprt par le matriel. Ces vulnrabilits prsentes
dans le code source sont ensuite exploites un niveau fonctionnel pour monter une attaque
fonctionnelle et tirer un gain de l'erreur introduite. Des attaques fonctionnelles compromettant
la condentialit d'un secret ou l'intgrit d'un objet sensible, en exploitant les consquences
d'attaques physiques, peuvent tre trouvs la rfrence [Lancia 2012]. L'existence de ces at-
taques conrme le besoin de s'intresser aux eets de ces fautes tous les niveaux du systme
et comprendre leur inuence sur le code source an de s'en prmunir.
3.3 Modlisation des consquences haut niveau

Cette section dcrit un modle permettant de simuler au niveau C des attaques par injection
de code. Avant de justier en section 3.4 pourquoi ce modle est pertinent et reprsente conve-
nablement les attaques physiques, nous donnons le principe de ce modle d'attaque au niveau C
et nous l'illustrons sur l'exemple du listing 3.1. Ces attaques assembleur peuvent tre regroupes
en deux catgories : celles qui modient la valeur d'une variable et celles qui induisent un saut
dans le code.
Modication de variable
Une attaque classique peut modier la valeur d'un registre, par exemple en eeprom. Dans ce
cas, une variable du programme est aecte au moment de son chargement depuis l'eeprom. An
de reprsenter l'eet d'une telle attaque, le modle C propos introduit une nouvelle instruction
C qui aecte une valeur arbitraire cette variable entre les lignes 3 et 4 comme dans le listing 3.2.
Listing 3.1 Exemple de code Listing 3.2 Modication de la valeur d'une variable
int func() { 1 int func() { 1

... 2 ... 2
target_val = 0x00; 3 target_val = 0x00; 3
... 4 target_val = 0xF0; 4
... 5 ... 5
if (!security(target_val)) 6 if (!security(target_val)) 6
secret = authorize(); 7 secret = authorize(); 7
return secret; 8 return secret; 8
} 9 } 9
Ce type d'attaque, ayant pour consquence la modication d'une variable, est la plus utili-
se par les attaquants [Derouet 2007]. D'autres types d'attaques permettent d'obtenir un eet
dirent, comme dcrit dans la section suivante.
Les attaques par saut

Perturber une instruction peut amener modier la nature d'une instruction assembleur.
Nous donnons plus de dtails sur l'eet d'une telle perturbation dans la section 3.4.3. Mme si la
matrise d'une telle attaque est vraiment dicile, un attaquant peut russir introduire un saut
dans le code. Dans notre modle d'attaque au niveau C, nous proposons de simuler l'attaque
l'aide d'une instruction goto, comme dans le listing 3.3 o l'attaque est injecte entre les lignes 4
et 5.
La modication d'une instruction assembleur peut aussi introduire une instruction nop, qui
peut tre intressante an d'viter une condition. Nanmoins, viter une ligne C est inclus dans
le modle d'attaque goto. L'exemple du listing 3.4 montre une ligne qui a t supprime par une
attaque ce qui peut tre simule en utilisant un goto jusqu' la ligne 7.
Listing 3.3 Attaque par saut Listing 3.4 Attaque par non excution
int func() { 1 int func() { 1

... 2 ... 2
target_val = 0x00; 3 target_val = 0x00; 3
... 4 ... 4
... goto label; 5 ... 5
if (!security(target_val)) 6 if (!security(target_val)) 6
label: 7 7
secret = authorize(); 8 secret = authorize(); 8
return secret; 9 return secret; 9
} 10 } 10
Maintenant que nous avons introduit le principe du modle propos, permettant de simuler
au niveau du code source C les attaques physiques, nous proposons d'tudier nement et de
manire exhaustive les consquences d'une attaque sur le code assembleur. Nous souhaitons
montrer qu'un nombre important d'attaques induites par faute physique peuvent se reprsenter
l'aide d'un modle d'attaque au niveau C.
3.4 Modle d'attaque physique haut niveau

Dans cette section, nous dcrivons les attaques physiques sur les cartes puce et leurs eets
an de remonter vers l'eet produit au niveau C. Ainsi, nous montrons que le modle propos
en section 3.3 est appropri pour simuler les attaques physiques au niveau du code source C.
Nous introduisons d'abord en section 3.4.1 ce qu'est une attaque par faute, ses caractris-
tiques et ses eets possibles. Nous expliquons aussi dans cette section pourquoi il est important
de prendre en compte deux types d'attaques : les attaques par nop et les attaques par saut 3.4.2.
Dans les sections 3.4.3 et 3.4.4, nous dtaillons les eets de ces attaques par faute sur le code
et sur les donnes. An d'tudier leurs eets et les raccrocher notre modle d'attaque, nous
proposons de direncier les eets sur les valeurs des variables des eets sur le contrle de ot. Fi-
nalement, dans la section 3.4.5, nous abordons un aspect supplmentaire des eets des attaque
physiques en expliquant comment une attaque par faute peut dcaler le ot d'interprtation
du code. Nous proposons galement une modlisation de ce dcalage et discutons des impacts
possibles de celui-ci sur l'excution du programme.
3.4.1 Eets des attaques physiques

Un attaquant peut modier un registre ou la valeur d'une variable lors de son enregistre-
ment dans une case mmoire en ram ou eeprom. Il peut perturber une variable pendant sa
transmission sur le bus de donnes. En fonction du type de mmoire utilis pour enregistrer la
valeur attaque et la potentielle rptition de l'attaque, l'eet de l'attaque est dit transient ou
permanent.
3.4. Modle d'attaque physique haut niveau 89
Transient Une attaque transiente peut par exemple avoir lieu sur un bus lors de la rcupra-
tion de l'instruction pour le processeur. Il n'y a pas de perturbation lors de la prochaine
rcupration de la mme instruction. L'eet est donc ponctuel ;
Transient rptitif Une attaque transiente rptitive est une attaque transiente qui peut tre
eectue plusieurs fois, ce qui a pour eet de provoquer le mme eet chaque fois qu'une
mme portion de code est sollicite ;
Permanent Une attaque permanente a lieu quand un composant mmoire tel que l'eeprom
ou la ram entre en jeu dans l'opration attaque. L'eet perdure dans la case mmoire
correspondante et se rpercute sur les utilisations futures de cette case mmoire.
On appelle attaque de donne une attaque qui modie la valeur d'une donne, i.e., une
information du programme, rsidant en ram, eeprom ou pendant sa transmission sur le bus
de donnes. Ces attaques incluent aussi les donnes permanentes accessibles uniquement en
lecture et donc stockes en rom. On appelle attaque de code, une attaque qui modie le code
du programme manipulant ces informations. Ce code mmoris en rom peut aussi tre attaqu
pendant son transfert sur le bus de donnes. On distingue explicitement la cible d'une attaque
(donne, code) de l'eet de celle-ci (changement de la valeur de variables, changement de ot).
Les attaques de code sont abordes dans la section 3.4.3 tandis que les attaques de donnes
sont abordes en section 3.4.4. Les attaques de donnes et de code peuvent tous deux avoir des
consquences sur le fonctionnement du programme comme le montre la table 3.1. Ainsi, une
attaque de code peut compromettre une opration arithmtique, ce qui a pour eet d'aecter
une valeur errone une variable. Ce type d'attaque peut aussi compromettre une opration
logique comme une condition, ce qui a une inuence sur le contrle de ot du programme. Les
attaques de donnes, quant elles, peuvent compromettre une information manipules par le
programme, c'est--dire, la valeur d'une variable. Cependant, si cette variable est utilise dans
une condition, de telles attaques auront aussi un eet sur le contrle de ot du programme.
Finalement, les deux types d'attaque peuvent tous deux avoir des eets la fois sur les variables
et le contrle de ot du programme. Par la suite, nous dtaillons les attaques de code dont les
eets sont plus complexes compars aux eets des attaques de donnes dont il est plus facile de
comprendre qu'ils modieront directement la valeur d'une variable.
Cible
Code Donne
Eet
Variables
Flot
Table 3.1 Croisement entre la cible et les eets d'une attaque
Nous avons choisi un modle de faute qui nous semble raliste parmi les dirents modles
de fautes physiques possibles. Ce modle de faute traduit les capacits de l'attaquant modier
le systme. Le modle de faute retenu considre qu'il est possible pour l'attaquant de modier K
octets du code interprt mais qu'il est dicile pour lui de matriser la valeur obtenue sauf pour
les valeurs 0x00 et 0xFF. Soit X une instruction quelconque interprte par le processeur un
instant donn de l'excution du programme. Cette instruction X est transforme aprs l'attaque
en une nouvelle instruction que l'on note Y.
attaque
X Y
Or X et Y sont des instructions, donc on a la relation :
attaque
[opcode, oprande1, oprande2] [opcode', oprande1', oprande2']
Dans cette relation, pour le 8051, un opcode ou un oprande est cod sur un octet. Nous
prendrons l'hypothse qu'un attaquant est capable de modier K octets dans une instruction
modiant un opcode, un ou plusieurs oprandes ou les deux. Nous supposerons aussi qu'une
modication d'un octet s'eectue exactement sur un opcode ou un oprande mais pas cheval
1
entre les deux . Si cause d'une attaque, un oprande est interprt comme un opcode, un
phnomne de dcalage apparat. Nous tudions ce phnomne en 3.4.5.
3.4.2 Importance des attaques par nop et par saut

Dans cette section, nous dtaillons les dirents cas de gure possibles aprs une attaque et
discutons de l'importance des attaques par nop et par saut. Ces attaques sont de la forme :
attaque
X Y
Plus prcisment, dans les deux cas suivants :
attaque
[opcode, oprande1, oprande2] [NOP, NOP, NOP]
attaque
[opcode, oprande1, oprande2] [JMP, oprande1', oprande2']
Ces attaques peuvent tre la consquence d'une faute respectant le modle d'attaque raliste
que nous avons retenu (perturbation d'un simple octet). Dans le document [Criteria 2009], de
telles attaques ont une note leve ce qui conrme leur importance. L'auteur de [Teuwen 2010]
mentionne que les attaques les plus importantes sont les attaques o l'eet transforme Y en
une instruction nop ou une squence de nops. Cette armation se justie d'abord par le fait
qu'obtenir une valeur prcise entre 0x00 et 0xFF est trs dicile car elle dpend de la nature de
l'attaque physique et de la disposition des composants matriels et de la raction de ceux-ci.
Ensuite, une telle attaque correspond un pulse laser unique (hypothse raliste) par exemple
sur le bus qui transmet le code devant tre excut. Ces attaques sont en pratique les attaques
les plus courantes car ces bus se trouvent la sparation entre une zone mmoire et la glue
logique du circuit ce qui les rend facilement distinguables. Enn, dans la mesure du possible,
un attaquant cherche garder un contexte proche du contexte original en minimisant l'eet de
l'attaque pour ne pas introduire d'eets de bord supplmentaires dicilement contrlables. Cette
dernire condition carte les attaques sur un grand nombre d'octets conscutifs. Les attaques
ayant des eets multiples seront dcrites en section 3.4.3. Pour ces raisons, nous tudierons en
plus d'une attaque gnrale, les attaques qui injectent une instruction de saut ou une squence
de nops.
1. En fait, une attaque cheval sur une partie de l'opcode et une partie de son premier oprande revient
considrer que l'attaque modie l'opcode et l'oprande.
Nous utiliserons comme exemple le listing de code 3.5 qui montre comment la perturbation
d'un appel de fonction peut permettre la dcouverte du PIN au bout de 9999 essais au maximum.
Listing 3.5 Exemple d'une injection d'un nop qui permet la dcouverte du pin en 9999 essais
unsigned int user_tries = 0; // initialisation 1
unsigned int max_tries = 3; 2
// --vie de la carte-- 3
ASM : CALL incr_tries(user_tries) -> NOP NOP 4
res = check_pin() 5
if (res == ok) 6
{ dec_tries(user_tries); } 7
if (user_tries < max_tries) 8
{ everything_is_fine(); } 9
else 10
{ killcard(); } 11
Dans la suite, nous discuterons de la faon de modliser ces attaques pour les 3 sous cas
suivants :
les attaques par nop qui remplacent une ou plusieurs instructions conscutives par des
instructions nop ;
les attaques par jump qui remplacent une instruction par une opration de saut, ventuel-
lement arrire ;
attaque
les attaques gnrales X Y , i.e., le remplacement d'une instruction par une autre
avec le mme nombre d'oprandes.
3.4.3 Attaques de code

Une attaque de code modie une instruction qui aurait d tre excute. Au niveau as-
sembleur, cette modication est quivalente une perturbation de l'opcode ou des oprandes
d'une instruction ; ventuellement des deux. Quel que soit le jeu d'instructions de l'architecture
cible, une instruction, une fois eectue, mmorise des informations dans un ou plusieurs re-
gistres. Montrons qu'une attaque de code peut modier le contenu d'un registre de destination,
le contenu d'une case mmoire ou le contrle de ot.
Les registres sont utiliss pour mmoriser des informations comme : des rsultats interm-
diaires lors d'un calcul, des adresses mmoire, des valeurs de variables ou des adresses d'instruc-
tions. Ces lments doivent tre utiliss (ce qui sous entend un accs par lecture) plus tard dans
le code par au moins une instruction. Si ce n'est pas le cas, ces registres sont crass avant d'tre
lus (utiliss) soit cause du contrle de ot soit parce que le compilateur a gnr du code
inutile par consquent une attaque sur ces registres avant cet crasement n'a pas d'eet car
l'crasement annule l'eet de l'attaque.
L'utilisation du contenu d'un registre met jour une variable (par une criture en m-
moire), calcule une adresse mmoire (par l'adresse d'une variable au cours d'un accs mmoire
ou l'adresse d'un code excutable lors d'un saut) ou inuence le contrle de ot (par un registre
impliqu dans un saut conditionnel). Par consquent, n'importe quelle attaque qui modie le
contenu d'un registre a soit un eet sur une mise jour mmoire, soit sur le contrle de ot,
soit sur les deux.
Au niveau C, cela veut dire que n'importe quelle attaque qui russit impacte une ou plu-
sieurs variables, le contrle de ot ou les deux. Dans les prochaines sections, nous montrons des
exemples d'attaque au niveau assembleur an d'illustrer ces direntes consquences au niveau
Listing 3.7 quivalent assembleur de la fonction exemple
_example: 1
... 2
Listing 3.6 Exemple d'une fonction C MOV R2,DPL // charge le paramtre en R2 3
MOV A,#0x05 // 5 est mis dans A 4
char example(char u) 1 ADD A,R2 // compute u + 5 in A 5
{ 2 MOV _c,A // crit c en RAM depuis A 6
char res, b; 3 CLR C // baisse la carry 7
c = u + 5; 4 SUBB A,#0x0A // calcule b ,i.e., C-10 8
b = c < 10; 5 JNC 00102$ // saute 102 si la carry 9
if (b) { 6 nest pas leve (else)
res = c + 1; 7
ATTACK_ADDR$: 10
} 8
MOV A,_c // charge C dans A 11
else { 9
INC A // A++ i.e. c + 1 12
res = 0; 10
} 11 MOV R2,A // crit A en R2 (res=c + 1) 13
return res; 12 SJMP 00103$ // saute par-dessus le else 14
} 13 00102$: 15
MOV R2,#0x00 // crit 0 en R2 (res= 0) 16
00103$: 17
MOV DPL,R2 // pousse R2 sur la pile 18
RET // retour 19
Figure 3.2 Exemple d'un code C et son quivalent en assembleur 8051C
C. Nous prsentons galement notre modle d'attaque au niveau C pour chacune de ces cons-
quences. Nous prendrons d'abord comme exemple l'extrait de code C et l'assembleur quivalent
prsents dans les listings 3.6 et 3.7.
Une approche similaire est adopte dans un processus de rtro ingnierie ou en utilisant une
technique comme la dcompilation [Cifuentes & Gough 1995] o on cherche retrouver, partir
d'un binaire destin tre interprt par le matriel, le code source non compil ayant servi
gnrer ce code binaire. Nous adoptons une approche similaire avec des hypothses propres
un contexte embarqu sous attaques physiques an de retrouver les eets au niveau fonctionnel
d'une attaque physique malicieuse.
Dans la section 3.4.3, nous discutons des attaques qui impactent les donnes et proposerons
une modlisation de leurs eets. Pour ces attaques, nous montrons plus tard dans le chapitre 5 que
le modle C quivalent est dicilement utilisable pour implmenter une plate-forme d'attaques
exhaustives cause du nombre total de cas tester. Cependant, ce modle sert de base pour nos
contributions sur la vrication des proprits d'intervalles sur les variables que nous prsenterons
dans le chapitre 4. Dans un deuxime temps, nous tudions dans la section 3.4.3 les attaques qui
perturbent le code et leurs eets sur les valeurs des variables et le contrle de ot. Nous proposons
une modlisation de celles-ci et montrons comment le code source C peut tre instrument pour
les simuler dans le chapitre 5.
Les eets aectant les valeurs

Si une ou plusieurs instructions impliques dans le calcul d'une nouvelle valeur pour la
variable v est attaque, alors la nouvelle valeur de v est fausse. Une telle attaque peut prendre
la forme de la non excution d'une ou plusieurs instructions (quivalente des attaques par
injection de nops ou un saut en avant dans le code), la rptition d'une ou plusieurs instructions
(quivalente un saut en arrire dans le code) ou le remplacement d'une instruction par une
autre. La variable v, aecte par l'attaque, est dite attaque et nous appelons une telle attaque
une attaque de valeur pour exprimer la modication de la valeur d'une variable. Une attaque de
valeur a pour consquence l'criture d'une valeur fausse dans une case mmoire correspondant
une variable.
Au niveau C, une attaque par valeur peut tre modlise prcisment si on sait quelle nouvelle
opration est eectue. Dans l'exemple de code en assembleur du listing 3.7, l'instruction MOV A
, #0x05 la ligne 4 aecte la valeur 0x05 au registre A an de calculer u + 5 avec l'instruction
ADD A, R2, i.e., la nouvelle valeur de la variable c. Si l'opcode ADD la ligne 5 est remplace par un
opcode SUBB alors l'aectation de c au niveau C devient c = u - 5;. Malheureusement, dans le
cas d'une attaque, la valeur prcise obtenue peut tre dicile modliser au niveau C car il faut
calculer la consquence de l'attaque en tenant compte du code assembleur qui prcde et succde
le point d'attaque. Cela revient rtro ingnierer du code assembleur vers son code source, si
cela est possible. [Cifuentes & Gough 1995] adopte une telle approche de rtro ingnierie mais
prcise qu'elle dpend beaucoup des optimisations du compilateur. Or, si le compilateur est
propritaire, comme c'est souvent le cas dans un milieu industriel, une documentation complte
des optimisations faites par celui-ci n'est pas forcement disponible. De plus, notre approche
va plus loin que de la simple rtro ingnierie, puisqu'il s'agit de transformer le code binaire
pour inclure une attaque avant de le rtro ingnierer. De telles transformations sont utilises
dans [Grith & Kaiser 2007] o les auteurs comparent leur propre outil d'instrumentation aux
autres outils d'instrumentation pour la simulation de fautes existantes. Dans [Miller et al. 2001],
les auteurs utilisent de telles techniques dans le but de vrier la scurit mais restent dans une
optique de test en bote noire sans remonter l'origine de l'erreur.
A l'heure actuelle, la rtro ingnierie d'un calcul mettant en jeu des manipulations de re-
gistres peut tre complexe cause des optimisations de code introduites par le compilateur. Par
exemple, le remplacement de MOV A, #0x05 la ligne 4 par une instruction nop induit que l'op-
ration ADD A, R2 eectue l'addition entre les registres A et R2 : le contenu du registre A est alors
inconnu. Au niveau C, ceci est quivalent c = u + ?;. Par consquent, il est possible d'obtenir
des valeurs qui peuvent compromettre la scurit du systme. Les auteurs de [Blmer et al. 2006]
montrent qu'il est possible d'exploiter une telle attaque pour compromettre la scurit d'un cal-
cul cryptographique utilisant des courbes elliptiques. Dans leur mise en pratique, ils expliquent
que n'importe quelle attaque menant un changement de signe peut compromettre le calcul.
Dans leur implmentation, le non branchement d'une condition est responsable du changement
de signe, cependant ils mentionnent qu'une inversion de bit est susante dans d'autres impl-
mentations du mme calcul cryptographique .
2
Il existe ainsi de nombreux moyens de modier le calcul d'une nouvelle valeur et il n'est
pas raliste de toutes les considrer. N'importe quelle attaque par injection de nop sur les
lignes 3, 4 et 5 ou des combinaisons de ces lignes perturbe le calcul de la nouvelle valeur de c. De
mme, n'importe quelle attaque par saut arrire depuis la ligne i5 jusqu' la ligne 5 a pour
consquence un calcul d'une valeur errone pour c et par consquent reprsente une attaque par
valeur sur c. Pour aller encore plus loin, si MOV A, #0x05 est remplac par une autre instruction
avec le mme nombre d'oprandes, par exemple ADD A, #0x05, une valeur inconnue pour la valeur
2. Cette dirence renforce l'ide que la scurit d'un systme repose sur le couple de paramtres que sont la
capacit de l'attaquant modier le systme allie une implmentation spcique.
Listing 3.8 Simulation Listing 3.9 Simulation Listing 3.10 Simulation Listing 3.11 Simulation
1 2 3 4
c = attack(); 1 c = u + 5; 1 c = u + 5; 1 c = u + 5; 3
b = c < 10; 2 b = c < 10; 2 b = c < 10; 2 b = c < 10; 4
67fb0 3 goto label2; 3 goto label4a; 3 goto label4b; 5
if (b) { 4 if (b) { 4 if (b) { 4 if (b) { 6
5 5 label4a: 5 label4a: 7
res = c + 1; 6 res = c + 1; 6 res = c + 1; 6 res = c + 1; 8
} 7 } 7 } 7 } 9
else { 8 else { 8 else { 8 else { 10
c6d30 9 label2: 9 label4b: 9 label4b: 11
res = 0; 10 res = 0; 10 res = 0; 10 res = 0; 12
} 11 } 11 } 11 } 13
c est calcule. C'est pourquoi nous proposons de modliser n'importe quelle attaque modiant
la valeur d'une variable v par le modle d'attaque de valeur suivant : v = attack();. Ainsi, tous
les exemples d'attaque de valeur d'une variable c voqus prcdemment peuvent tre modliss
dans notre modle au niveau C de la mme manire avec l'introduction d'une instruction c =
attack(); comme le montre le listing 3.8.
Arriv ici, la dicult principale est de tester toutes les variables attaques pour toutes les
valeurs possibles retournes par attack(). Au lieu de tester toutes les valeurs possibles pour
une variable attaque en utilisant un outil de simulation, il est plus appropri de prendre en
compte ces attaques avec une approche statique. En eet, les outils statiques et smantiques
peuvent travailler sur des intervalles de valeurs pour les variables attaques contrairement aux
mthodologies de test qui utilisent des valeurs discrtes. Nous montrons comment ce modle
d'attaque peut tre exploit dans le chapitre 4.
Les eets aectant le contrle de ot

Illustrons les consquences sur le contrle de ot de nos 3 sous cas d'attaques : nop, jump
et X Y .
Les attaques de contrle de ot avec des attaques par nop L'instruction assembleur
SUBB calcule la valeur de la variable locale b la ligne 8 du listing 3.7. Le registre de carry
est positionne 1 par cette instruction quand il y a un dpassement, i.e., quand c < 10. Le
registre de carry est utilis plus tard par l'instruction de saut conditionnel JNC la ligne 9.
Par consquent, une attaque par nop ciblant l'instruction SUBB est une attaque de contrle de
ot par nop. Puisque l'instruction CLR C la ligne 7 positionne le registre de carry 0, si une
attaque fait que la carry n'est jamais leve, l'instruction de saut conditionnel JNC la ligne 9
introduit un saut qui est toujours emprunt. Une telle attaque peut tre simule au niveau C en
insrant une instruction goto comme le montre le listing 3.9.
Supposons maintenant qu'une attaque par nop cible la fois les instructions assembleur
CLR C et SUBB A, #0x0A aux lignes 7 et 8. Ce cas est aussi une attaque par contrle de ot par
nop. Dans ce scnario, le saut conditionnel ligne 9 dpend de la dernire instruction qui a utilis
le registre de carry. Si la carry a t leve, le ot d'excution du programme suit la branche
then de la construction if/then/else, sinon le ot saute dans la branche else. Par consquent,
au niveau C, deux simulations sont considrer, une pour chaque branche comme le montre
Listing 3.12 Simulation 5 Listing 3.13 Simulation 6 Listing 3.14 Simulation 7
goto label1; 1 13dca 1 cpt ++; 1

c = u + 5; 2 c = u + 5; 2 c = u + 5; 2
label1: 3 aa856 3 d5b66 3
b = c < 10; 4 b = c < 10; 4 b = c < 10; 4
if (b) { 5 if (b) { 5 if (b) { 5
res = c + 1; 6 label3: res = c + 1; 6 res = c + 1; 6
} 7 } 7 } 7
else { 8 else { 8 else { 8
d752a 9 goto label3; 9 label5: 9
res = 0; 10 res = 0; 10 res = 0; 10
} 11 } 11 } 11
82ddd 12 d534f 12 if (cpt >= first_time && 12
645c4 13 30ed2 13 cpt <= last_time) { 13
2ae13 14 d155f 14 goto label5; } 14
les listings 3.10 et 3.11. Notons que le modle d'attaque couvre le cas o une attaque par nop
cible uniquement la ligne 8. En eet, une attaque modlise au niveau C peut correspondre
plusieurs attaques au niveau assembleur qui peuvent tre factorise comme le montre les
listings 3.9 and 3.11.
Maintenant, supposons qu'une attaque par nop cible l'instruction assembleur MOV _c, A la
ligne 6 qui mmorise la nouvelle valeur de c en mmoire. Aucun registre n'est impact dans ce
cas, la variable c n'est juste pas mise jour comme si la premire instruction du code C n'tait
pas excute. Ce scnario peut tre modlis au niveau C avec le modle d'attaque par goto
en sautant la ligne C o c est aecte comme le montre le listing 3.12.
Par consquent, toutes les attaques par nop qui modient uniquement le contrle de ot
peuvent tre modlises avec le modle d'attaque par goto. Pour considrer l'intgralit des
attaques de contrle de ot par nop au niveau C, il est alors susant de gnrer toutes les
instructions gotos en avant dans le code d'une instruction C une autre.
Les attaques de contrle de ot avec des attaques par saut Nous considrons mainte-
nant les attaques par saut, i.e., le remplacement d'une instruction assembleur par une instruction
de saut. Comme les attaques par nop sont quivalentes des sauts en avant dans le code, nous
ne considrerons que les sauts en arrire dans cette section.
Supposons qu'une attaque par saut remplace l'instruction MOV DPL, R2 la ligne 19 par JMP
00102$, qui est un saut arrire dans le code (deux instructions en arrire) au label 00102$, i.e.,
la partie else de la condition. Cette partie aecte 0 au registre abritant la valeur de retour
R2. Comme l'excution est squentielle, ce saut entraine une nouvelle excution de l'instruction
JMP 00102$. Si l'attaque est permanente, l'excution du programme boucle de manire innie. Si
l'attaque est transiente ou transiente rptitive, la fonction s'achvera et la valeur retourne est 0
(puisque la partie else est excute quelle que soit la valeur de b dans le cas d'une telle attaque).
Ces deux scnarii peuvent tre simuls au niveau C avec un goto. Dans le cas d'une attaque
transiente ou transiente rptitive, le goto doit tre encapsul dans une condition comme le
montre le listing 3.14.
Supposons maintenant que l'instruction MOV R2, #0x00 est remplace par l'instruction JMP
ATTACK_ADDR1$ o @ATTACK_ADDR1$ dsigne l'instruction la ligne 10, la premire de la partie
then. Une telle attaque force le ot du code emprunter la branche then depuis la branche else
(sans eectuer res = 0;). Par consquent, si l'attaque est faite, le rsultat de la fonction est
c + 1 au lieu de 0. Cette attaque peut tre simule au niveau C par une instruction goto qui
force le ot d'excution retourner en arrire dans la partie then comme le montre le listing 3.13.
On peut donc dire que tous les sauts arrires qui impactent seulement le contrle de ot
peuvent tre modliss avec un goto arrire au niveau C. Pour considrer toutes les attaques sur
le contrle de ot par saut arrire dans le code source, il sut, au niveau C, de considrer tous
les goto arrire d'une instruction C une instruction prcdente.
On peut conclure en disant que les attaques par nop et par saut qui impactent seulement
le contrle de ot peuvent tre modlises avec le modle d'attaque par goto au niveau C.
Par consquent, considrer toutes les attaques par goto au niveau C stimule l'ensemble de ces
attaques.
Les attaques multiples eets

Comme expliqu prcdemment, une attaque ciblant un registre va se propager dans la
suite du code jusqu' ce que ce registre soit utilis comme une variable (i.e., une attaque par
valeur), ou pour contrler le ot (i.e., une attaque de contrle de ot). Cependant, suivant les
optimisations ralises par le compilateur, il se peut que ce registre soit utilis plusieurs fois
la suite sans tre rcrit nouveau. Dans ce cas, en attaquant ce registre, l'attaque a plusieurs
consquences combines. Dterminer si une attaque peut avoir plusieurs consquences n'est pas
ais. Par exemple, le compilateur peut ventuellement extraire une sous expression d'un calcul
arithmtique si le rsultat de ce calcul intervient plusieurs fois par la suite, par exemple dans un
autre calcul et dans des conditions. Cette sous expression peut alors tre mise dans un registre
qui est rutilis plusieurs fois. Nous donnons dans le listing 3.15 un exemple simple de code ou
b+c est utilis deux endroits. Si ce calcul est perturb, la valeur de a est incorrecte et le if peut
ventuellement mal se drouler. Nos modles d'attaque peuvent cependant reprsenter une telle
attaque comme montr dans le listing 3.16 mais la dicult pour dtecter de tels cas demeure.
Listing 3.15 Code original Listing 3.16 Code avec attaques
a = b + c + d; // attaque 1 a = attack(); 1
f25bX 2 goto label1; // ou goto label2 2
if (b + c > 6) { 3 if (b + c > 6) { 3
} 4 label1: } 4
else { 5 else { 5
} 6 label2: } 6
Considrons les attaques qui ciblent une des instructions impliques dans le calcul de la
variable locale b entrant en jeu dans la condition if/then/else. Une telle attaque peut modier
le ot du if/then/else et n'est pas une attaque par valeur puisque b reste dans un registre sans
tre stock en mmoire. En fonction de la valeur du registre abritant b, l'attaque est quivalente
un saut inconditionnel dans la branche then ou la branche else du if/then/else.
On peut donc en dduire qu'attaquer une ou plusieurs instructions impliques dans une d-
cision de contrle de ot et qui n'a pas d'impact sur une variable en mmoire est quivalent
l'insertion d'un saut inconditionnel dans le code. Nous appelons une telle attaque une attaque
de contrle de ot. Au niveau C, un saut inconditionnel peut tre eectu avec un couple d'ins-
tructions goto/label o label dsigne une instruction C cible pour le saut. Nous appelons ce
modle le modle d'attaque par goto.
3.4.4 Attaques de donnes

Les attaques de donnes regroupent les attaques sur une information ou donne manipule
par le programme. Un attaquant en modiant les donnes manipules par le programme des
moments cls peut changer la valeur d'une donne sensible et par consquent induire un nouveau
comportement du programme. Les eets de ces attaques de donnes dpend de l'implmentation
du programme et du gain vis par l'attaquant ; c'est pourquoi nous ne les dtaillons pas. Leur
modlisation est simple. Suivant le modle de faute choisi, la modlisation revient remplacer
la valeur d'une variable lors de son utilisation (lecture ou criture) par une autre dpendant des
capacits de l'attaquant. Le modle de faute que nous avons choisi induit que cette valeur est
0x00, 0xFF, ou une valeur alatoire.
3.4.5 Dcalage d'interprtation du code

Dcalage du code
Nous avons vu que l'eet d'une faute physique pouvait introduire une modication de valeur
de variables ou introduire des sauts modiant le contrle de ot du programme. Dans cette
section, nous introduisons un phnomne supplmentaire caus par ces fautes physiques. Ce
phnomne est associ la perturbation du ot d'instructions interprt de manire squentielle
par le processeur. Nous cherchons caractriser ce phnomne au niveau du code assembleur et
d'en dduire qu'elles en sont les consquences plus haut niveau.
Une attaque qui modie le code excut quand il est charg depuis la rom dans le cpu
peut modier la valeur d'un octet. Dans le cas d'un jeu d'instructions de longueur variable, le
processeur dcode une instruction en commenant par dcoder l'octet contenant l'opration code
(opcode) pour ensuite dterminer le nombre d'octets ncessaires pour les oprandes. Ce mode
opratoire est gnralement le cas dans les systmes embarqus de petite taille cause du haut
niveau de compacit du code rsultant. Si une attaque modie l'octet d'un opcode, elle peut
alors aussi modier le nombre d'octets suivants utiliss comme oprandes. Par consquent, un
dcalage dans le ot d'instructions interprtes a lieu et ce ot peut rester dcal jusqu' ce que
le ot original soit ventuellement retrouv.
Considrons l'exemple d'une attaque ciblant une instruction code sur 3 octets . Le premier
3
octet X contient l'opcode tandis que les deux octets suivants sont les oprandes. Supposons
que X est remplac par Y . Les consquences de ce changement dpend du nombre d'octets
ncessaires par l'opcode Y :
1. X arg1 arg2 ; Y ; arg1 arg2 si Y n'a pas d'octet d'oprande alors arg1 est vu comme un
opcode. En fonction du nombre d'octets requis par arg1, arg2 est soit un oprande soit
un opcode. Le ot d'instructions est dcal.
2. X arg1 arg2 ; Y arg1 ; arg2 si Y requiert un octet d'oprande, alors arg2 est vu comme un
opcode et le ot d'instructions est dcal (jusqu' ce qu'il retrouve ventuellement le ot
initial).
3. X arg1 arg2 ; Y arg1 arg2 ; Si Y requiert deux octets oprandes alors l'intgralit de l'ins-
truction est modie et le ot d'instructions n'est pas dcal.
3. D'autres cas avec un ou deux octets suivront le mme schma

Dure de vol
Lorsque le ot d'instruction est dcal, il peut ventuellement retrouver le ot initial, ce que
nous tudions par la suite. Retomber sur le ot original consiste interprter comme opcode
un opcode du ot original aprs un dcalage d'interprtation induit par une attaque. Toute
interprtation de code suite ce dcalage correspond une tape. La premire tape consiste
choisir un octet au hasard qui reprsente la premier octet lu comme un opcode aprs que le ot
soit dcal. Cet octet, dans le ot original, peut tre un opcode ou une oprande. Le fait de le
choisir au hasard sert reprsenter l'interprtation du processeur suite une attaque dcalant le
ot d'interprtation. Toute tape suivante consiste considrer l'octet courant comme un opcode
et d'valuer les octets suivants comme des arguments de cet opcode. Dans cette valuation,
on considre les sauts comme des instructions comme les autres, c'est--dire, que ce sont des
opcodes ayant 0, 1 ou deux arguments suivant le saut considr. On ne considre pas l'endroit
o on va chercher l'instruction suivante mais considrons que le code est interprt de manire
squentielle. Cette partie peut se faire de manire exprimentale en inlinant le code qui doit
tre excut aprs le saut.
Quand le ot est dcal, le code binaire dans son intgralit peut tre interprt comme
un nouveau programme. Cependant, le programme original et le programme dcal peuvent
correspondre nouveau un point donn : c'est ce que nous appelons rcuprer le ot original.
Avant de rcuprer le ot original, un certain nombre d'oprations hors squence peuvent tre
eectues. Nous nommons l'ensemble de ces oprations hors squence un vol. Ce vol se compose
de plusieurs tapes. Une tape tant l'interprtation d'une instruction hors squence par le
processeur. Le but de cette section est de dterminer la dure de vol moyenne, dnie partir
de la dure de vol :
Dnition 14 (Dure de vol) Nombre d'tapes ncessaires pour retrouver le ot original.
Nous noterons v, la dure de vol moyenne dnie suivant un modle probabiliste.
On dnit p(n) comme la probabilit de retomber sur le ot original au bout de n tapes.
Cette dure de vol moyenne se caractrise de la manire suivante :

X
v = (n p(n)) (3.1)
n=1
Cette notion de vol peut tre illustre par la gure 3.3. Les ches suprieures reprsentent
le ot initial tandis que les ches infrieures reprsentent le vol, i.e., le ot dcal. Les cases
vertes reprsentent les opcodes du ot d'origine. La case jaune reprsente la premire tape de
destination d'un vol c'est--dire un octet interprt comme un opcode hors de squence originale.
Dans cet exemple, le ot original est rcupr au bout d'un vol d'une dure de trois tapes. On
considre que la premire tape est cause par une attaque. Celle-ci contraint l'argument A1
tre interprt comme un opcode. Cet opcode ncessite deux arguments : A2 et I2. A1, A2
et I2 sont donc interprts comme une instruction hors squence formant une seconde tape
dans le vol. Cette tape mne l'tape A3, I3 interprt comme une instruction ncessitant un
argument. Dans cet exemple informel, le ot original est nalement rcupr en I4 au bout de
3 tapes. Nous conserverons les conventions dans les schmas accompagnant les preuves.
I1 A1 A2 I2 A3 I3 I4 A4
1 2 3
Figure 3.3 Illustration de la notion de vol et des tapes
Modle probabiliste
An de prciser la dure de vol moyenne dans un code, il faut dnir quelques lments
complmentaires dcrivant les distributions moyennes des instructions dans le code objet. En
particulier, on dnit, pour i le nombre d'arguments d'une instruction avec i {0, 1, 2} :
ci : la probabilit que l'opcode du code interprt corresponde une instruction ncessitant i

arguments ;
ai : la probabilit que l'opcode interprt fasse partie d'une instruction du jeu d'instructions
ncessitant i arguments.
La deuxime srie de probabilit dpend uniquement du jeu d'instructions que l'on consi-
dre, tandis que la premire dpend du binaire considr. On prend comme hypothse que les
arguments sont uniformment rpartis sur l'intervalle [0..255]. Par consquent, la rpartition des
opcodes correspondant aux arguments suit la loi de probabilit i.
Si on considre un octet au hasard dans un code binaire, cet octet O (en jaune dans les
illustrations) est interprt comme un opcode dans la nouvelle squence. On considre aussi
que l'intgralit d'une instruction (opcode et un ou deux arguments) est toujours interprt de
manire squentielle. Les instructions elles-mmes sont interprtes les unes la suite des autres,
ce qui implique qu'un saut dans le code est le rsultat de l'interprtation d'une squence d'octets
reprsentant un saut dans le jeu d'instructions. Il n'est pas possible d'induire un saut autrement.
Cette hypothse exclut le cas o l'argument interprt n'est pas l'octet suivant directement un
opcode ou le cas o un second argument n'est pas l'octet suivant directement le premier argument
de l'instruction. Sachant qu'un opcode ou un argument sont cods sur un octet chacun, on a
donc les probabilits suivantes s'appliquant sur le code original :
p0 = (c0 + c1 + c2 )/(c0 + 2c1 + 3c2 ) de tomber sur un opcode ;
p1 = (c1 + c2 )/(c0 + 2c1 + 3c2 ) de tomber sur un argument juste avant un opcode ;
p2 = c2 /(c0 + 2c1 + 3c2 ) de tomber sur un argument 2 octets avant un opcode.
Ces trois vnements sont disjonctifs.
Dans ce modle, nous prenons comme hypothse qu'une attaque ne peut pas conduire le
processeur interprter la moiti d'une instruction introduisant un dcalage d'un demi octet dans
le ot d'interprtation. Un tel phnomne ncessiterait une recherche en mmoire de l'instruction
interprter d'une taille infrieure un octet ce qui n'est pas le cas.
Lemme et preuve courte de la rcupration du ot initial

Nous prouvons par la suite qu'un ot de code dcal a une forte probabilit de retrouver le ot
initial. Le lemme suivant estime le nombre conscutif d'instructions excutes par le processeur
ncessaires pour rcuprer le ot original. An de simplier le modle, nous considrons dans
un premier temps que le code assembleur est une distribution alatoire du jeu d'instructions,
c'est--dire que ci = ai . Nous supposons aussi que choisir deux instructions conscutives dans le
code binaire est quivalent eectuer deux essais indpendants.
Lemme 1 Quand le ot est dcal d'un octet, le nombre estim d'instructions conscutives du
processeur pour rcuprer le ot original est 1/p0 .
Preuve: Une opration est constitue d'un opcode et de plusieurs oprandes (0, 1 ou 2 en 8051).
Quand une attaque a lieu, le ot est dcal et ce nouveau ot d'instructions est interprt en
utilisant un octet qui est un opcode du ot original avec une probabilit p0 et un oprande avec
une probabilit 1 p0 . Dans le premier cas, le ot original est retrouv la premire tape.
Dans le second cas, l'oprande (du code original) est interprt comme un opcode z. Le ot
original peut tre retrouv l'opration suivante en fonction du nombre d'oprandes de z et de
la structure du ot original. Dterminer la nature de l'opration qui suit z peut tre vu comme
un autre dcalage alatoire indpendant du premier dcalage. Par consquent, la probabilit de
rcuprer le ot original reste p0 cette tape. Cette probabilit suit la loi de Bernoulli et nous
permet de dterminer le nombre d'tapes E(X) ncessaires an de russir rcuprer le ot
1
original. E(X) = p0 + (1 p0 )(1 + E(X)) ce qui nous amne E(X) = p0 .
Rsultats numriques Pour le jeu d'instructions du 8051, en prenant l'hypothse simpli-

catrice qu'un binaire suit une distribution uniforme des opcodes au sein du programme et en
considrant que les oprandes suivent cette distribution, on obtient p = 0.64. Par consquent,
en 1.56 tapes le ot original est rcupr. Quand le ot d'instructions est dcal, la probabilit
de succs de l'attaque responsable diminue car les oprandes qui sont interprtes comme des
opcodes peuvent mener un blocage du programme (si une instruction illgale est rencontre ou
si cette interprtation provoque une erreur fonctionnelle comme une division par 0). Cependant,
de telles attaques ne sont pas impossibles raliser [Shacham 2007] et si le programme ne se
bloque pas, le ot d'excution rcupre rapidement le ot original.
Thorme et preuve longue de la dure de vol

Thorme 1 tant donne le modle probabiliste tabli dans la section 3.4.5, la longueur du
vol est :
1
v = p0 + (1 p0 ) 1 +
1 + 2
avec :
c1 + c2
a0 + a1 c0 + a2 (c20 + c1 )

1 =
c1 + 2c2
c2
2 = (a1 + a2 c0 )
c1 + 2c2
Preuve:
Dtermination des ccients p(n). Dans la suite, on dtermine de manire prcise les
dirents ccients de l'quation 3.1. Rappelons que p(n) est la probabilit de retomber sur
le ot original au bout de n tapes. Une tape est l'interprtation hors squence d'un opcode.
On considre que la premire interprtation hors squence reprsente dj une tape comme on
peut le voir dans la gure 3.3.
p(1) : Cette quation correspond la probabilit de tomber directement sur un opcode original
aprs une premire tape et l'interprtation d'un opcode. Donc :
c0 + c1 + c2
p(1) = p0 = (3.2)
c0 + 2c1 + 3c2
p(2) : Dans cette quation, l'octet considr O est l'argument d'un autre opcode. Cette quation
correspond la probabilit de ne pas retrouver le ot original l'issue de la premire tape
mais qu'une seconde tape permet de le rejoindre. On a :
p(2) = (1 p(1)) (cas(1) + cas(2)) (3.3)
avec cas(i) reprsentant la probabilit conditionnelle de retrouver le ot en deux tapes

sachant que l'on se trouvait i octet(s) gauche de l'opcode suivant. Ainsi cas(1)
regroupe les cas o, l'issue de la premire tape, un argument du ot original interprt
cause du dcalage comme un opcode se trouve une distance d'un octet gauche du
prochain opcode du ot original. L'ensemble des cas peut tre regroup dans un des scnarii
suivants.
cas(-1) : Ce cas arrive avec la probabilit conditionnelle de (c1 + c2 )/(c1 + 2c2 ).
On dtaille la contribution de ce cas de la manire suivante :
Avec probabilit a0 : l'octet O considr correspond un opcode ayant 0 argu-

ment. On retrouve le ot l'tape suivante ;
O R
Avec probabilit a1 : on retrouve le ot si l'instruction suivant O est une instruc-

tion ayant 0 arguments, c'est--dire avec probabilit c0 ;
O R
Avec probabilit a2 : on retrouve le ot l'tape suivante si l'instruction suivant

O est une instruction avec 1 oprande, c'est--dire, avec probabilit c1
O R
ou si il existe deux instructions conscutives O n'ayant aucun argument, cela

correspondant c20 .
O R
La contribution pour le cas(1) est donc globalement de :
c1 + c2
a0 + a1 c0 + a2 (c20 + c1 )

1 =
c1 + 2c2
cas(-2) : la probabilit conditionnelle de ce cas est c2 /(c1 + 2c2 ).
Figure 3.4 Cas 2
On peut retrouver le ot l'tape suivante dans les deux cas suivants :
Avec probabilit a1 : l'octet O considr est une instruction ayant 1 argument.

Dans tous les cas, le ot est rcupr cette tape
O R
Avec probabilit a2 : l'octet O considr correspond une instruction ayant deux

paramtres. Pour rcuprer le ot, il faut que l'instruction immdiatement sui-
vante n'ait aucun argument. Donc, le ot est rcupr cette tape avec la
probabilit c0
O R
La contribution pour le cas(2) est donc :
c2
2 = (a1 + a2 c0 )
c1 + 2c2
Au nal :
p(2) = (1 p0 )(1 + 2 ) (3.4)
p(n) : une tape n donne, il est assez simple de constater que l'on se retrouve dans un cas
identique au prcdent. On obtient donc le rsultat suivant :

i1
X
p(n) = 1 p(j) (1 + 2 ) (3.5)
j=0
En rsum, partir de la deuxime tape, cela correspond un tirage suivant la loi de

Bernoulli de paramtre p = 1 + 2 .
L'esprance de cette partie est 1/(1 p)
Discussion du modle et ranement

Champs d'application Le modle probabiliste employ prend en compte des tapes ind-
pendantes (hypothse du lemme 1) ou des tapes lies et interprtes de manire squentielle
(hypothse du thorme 1). Or des instructions interprtes de manire squentielle sans saut
forment un bloc basique. Si on se place au niveau d'abstraction des blocs basiques, suivant les
hypothses adoptes, le lemme 1 s'applique sur les blocs basiques vus comme des tapes in-
dpendantes tandis que le thorme 1 s'applique sur les instructions l'intrieur d'un mme
bloc basique. La gure 3.5 illustre les champs d'application du lemme et de la preuve au niveau
d'abstraction d'un bloc basique.
Ranement Dans le calcul eectu dans le paragraphe 3.4.5, nous avons pris l'hypothse que
les instructions du jeu d'instructions taient rparties uniformment dans le binaire (ai = ci ).
Dans la pratique, ce n'est pas le cas. On peut par exemple utiliser un jeu d'instructions dont
la moiti des instructions sont des instructions illgales ce qui modie totalement la dynamique
du phnomne de dcalage ainsi que le calcul du vol moyen. Il reste prouver que le calcul du
vol moyen repose uniquement sur la rpartition des oprandes dans le code binaire et pas la
rpartition des opcodes et des oprandes. Le modle peut donc tre ran an de s'adapter
des conditions direntes. Cependant le mode opratoire reste le mme. De plus nous n'avons
pas direnci la rpartition des opcodes de celle des oprandes.
MOV R1, R7 Dbut du dcalage

MOV A, R2 NOP NOP, R2
ADD A, @R1
VOL
JMP
BLOC
Recupration
BASIQUE Lemme
du flot original
Thorme
AVANT ATTAQUE APRES ATTAQUE
Figure 3.5 Champ d'application du lemme et du thorme au niveau des blocs basiques
3.5 Conclusion
Dans ce chapitre, nous avons caractris de manire formelle les possibilits d'observation et
d'action que nous considrons ralisables de la part d'un attaquant. Ces capacits vont condi-
tionner la scurit du systme et les contre-mesures rajouter dans le code. Nous avons dcrit
ces capacits d'une manire cohrente avec les proprits de scurit du chapitre 2, exprimes
au niveau du code source pour tre proche d'une reprsentation haut niveau propre au dvelop-
peur. Nous avons ainsi dni un modle d'attaque haut niveau adapt traduire les besoins
fonctionnels du systme et les garanties en scurit qui en dcoulent. Ce modle nous sert
caractriser les eets des attaques physiques sur le code source en essayant de faire apparatre
les dangers fonctionnels qu'elles reprsentent. Nous pouvons maintenant utiliser cette caractri-
sation de l'attaquant et la confronter aux garanties de scurit souhaites pour notre systme,
exprimes au travers des proprits de scurit.
Ce modle d'attaque permet dans un premier temps de vrier si les proprits de scu-
rit exprimes sont bien garanties. En caractrisant les eets d'une attaque au niveau du code
source, le modle permet de mieux comprendre celle-ci. Ce modle inclut notamment une ca-
ractrisation du dcalage d'interprtation de code rsultat d'une attaque physique. On peut
remarquer que contrairement un modle de faute un modle d'attaque cherche incorporer le
gain potentiel de l'attaquant. Le modle ainsi dni permet aussi de modliser les arrachements
de la carte qui font partie des moyens dont dispose l'attaquant pour compromettre la scu-
rit [Marche & Rousset 2006]. En eet ces arrachements se rsument des sauts de code jusqu'
la n du programme. Ce modle permet donc de simuler des attaques an de tester un systme
face aux attaques physiques. Les tests de scurit raliss nous permettent d'implmenter des
contre-mesures appropries aux endroits adquats du systme. Dans les chapitres suivants, nous
proposons deux mthodes pratiques an de vrier la scurit d'un systme embarqu contre
les attaques physiques. Ces mthodes reposent sur une analyse du code source et la simulation
d'attaques physiques. Ces simulations d'attaques physiques sont tablies en fonction du modle
d'attaque dcrit dans ce chapitre.
3.6 Perspectives
3.6.1 Prise en compte d'attaques d'un ordre suprieur
Dans le modle que nous avons tabli dans ce chapitre, nous avons pris des hypothses sur
les capacits de l'attaquant ainsi que sur les consquences matrielles relles d'une perturbation
physique. On peut facilement raliser que la complexit de l'ensemble des interactions ayant lieu
au niveau matriel ne peut pas tre compltement traduite au niveau du code source et que
seuls certains eets sont modlisables. Parmi ceux-ci, des eets supplmentaires d'une attaque
peuvent tre incorpors dans le modle tabli an de l'tendre. Nous donnons quelques pistes
an de prsenter ces consquences multiples et les illustrer l'aide d'exemples d'implmentations
vulnrables.
Il est possible qu'une seule attaque ait des consquences multiples. En eet, mme une at-
taque simple peut avoir des consquences modlisables par de multiples injections d'criture
et de multiples sauts. Par exemple, dans le listing 3.17, on peut voir qu'un seul saut a pour
consquence une modication de valeur et une modication de la logique du code par le rempla-
cement d'un type de saut par un autre. Or ce remplacement de saut peut tre simul par une
modication de la carry responsable du saut.
Listing 3.17 Exemple d'une attaque simple consquences multiple
MOV R1, 5 1
JNEQ label:12 2
; devient aprs une attaque 3
MOV R1, 2 4
JEQ label:12 5
Prenons comme exemple le code du listing 3.18 an d'illustrer quelques exemples de vuln-
rabilits possibles en exploitant les consquences multiples d'une attaque.
Listing 3.18 Code original
int foo; 1
foo = 1; 2
use_foo(foo); 3
if (foo != 1) 4
{ 5
KC(); 6
} 7
Exemples de vulnrabilits De multiples consquences peuvent tre causes par des at-
taques doubles mais de simples attaques dans certaines conditions dpendant la fois de l'im-
plmentation du code, de l'architecture et du compilateur peuvent aussi provoquer des cons-
quences multiples sur le code. Ci-dessous quelques exemples permettent de se rendre compte de
telles vulnrabilits.
Listing 3.19 Consquence multiples : criture + saut
int foo; 1
foo = 1; 2
foo = 2; // attaque modifiant foo 3
use_foo(foo); 4
if (foo != 1) 5
{ 6
// et provoquant aussi le saut de KC(C) 7
goto label_attaque; 8
KC(); 9
label_attaque: 10
} 11
Dans le listing 3.19, si une attaque simple (ou une attaque double) a pour consquence une
modication de foo juste avant son utilisation en ligne 4 et un saut de la rponse scuritaire
KC() en ligne 9, foo est utilis avec une valeur fausse sans que le code ne s'en aperoive. Il s'agit
ici d'une vulnrabilit.
Listing 3.20 Consquence multiples : criture + criture
int foo; 1
foo = 1; 2
foo = 2; // attaque modifiant foo 3
use_foo(foo); 4
foo = 1; // et modifiant foo une seconde fois 5
if (foo != 1) 6
{ 7
KC(); 8
} 9
Dans le listing 3.20, si une attaque (simple ou double) a pour consquence deux modications
en criture du code, on peut se retrouver dans un cas o la valeur utilise par use_foo() est fausse
et est remise son tat initial juste aprs son utilisation et avant sa vrication entrainant une
rponse scuritaire. Dans ce scnario, le code est une nouvelle fois incapable de dtecter la
prsence d'une attaque. D'o la prsence d'une vulnrabilit.
Ces deux exemples sont ralisables mais demandent une disposition particulire du code.
Dans l'exemple suivant, nous choisissons une forme de code a priori scuritaire et employe de
manire courante dans les codes de cartes puce.
Listing 3.21 Version scurise d'une condition vulnrable une attaque par saut simple
if (x != 0) 1
{ 2
KC(); 3
} else 4
{ 5
code_effectif(); 6
} 7
L'extrait de code du listing 3.21, la condition (x != 0) prend en compte la majeure partie

des valeurs possibles de x et les redirige vers la rponse scuritaire KC(). Seule la valeur correcte
n'est pas ltre et amne a l'excution de code_effectif(). Cependant, cet extrait de code se
traduit en assembleur de la manire suivante :
Listing 3.22 Traduction en assembleur du code C du listing 3.21
MOV R1, _x 1
MOV R2, 0 2
CMP R1, R2 3
JNEQ label_else 4
CALL KC() 5
JMP label_end 6
label_else: 7
CALL code_effectif() 8
label_end: 9
Or si ce code est attaqu par un simple saut de deux instructions, on se retrouve avec le code
assembleur suivant :
Listing 3.23 Traduction en assembleur du code C du listing 3.21 sous attaque
MOV R1, #x 1
MOV R2, 0 2
CMP R1, R2 3
JNEQ label_else 4
GOTO label_else: ; attaque par saut sautant 2 instructions assembleur 5
CALL KC() 6
JMP label_end 7
label_else: 8
CALL code_effectif() 9
label_end: 10
On se retrouve donc excuter le code C du listing suivant, qui est exactement oppos en
terme de logique celui du listing 3.21 de dpart.
Listing 3.24 Equivalent C du code assembleur attaqu
if (x != 0) 1
{ 2
code_effectif(); 3
} 4
On peut ainsi voir que de telles attaques peuvent aussi tre dangereuses pour la scurit du
systme et doivent tre prises en compte.
3.6.2 Extension du modle

L'approche utilise pour crer ce modle repose essentiellement sur un critre de divulgation
d'information ainsi qu'un aspect fonctionnel de la logique du programme. Une perspective pour-
rait tre d'enrichir le modle l'aide d'une approche dirente. [Pistoia et al. 2007] donne une
ide d'une telle association entre le ot d'information et le contrle d'accs.
Le modle d'attaque tabli cherche lier des eets physiques bas niveau des besoins fonc-
tionnels de haut niveau an de permettre au dveloppeur d'associer les deux perspectives. Ces
deux perspectives doivent tre prises en compte an de garantir la scurit du systme. Les
besoins en scurit s'expriment grce des proprits de scurit au mme niveau que le mo-
dle c'est--dire sur le code source du programme. Si cette approche a l'avantage d'tre proche
du point de vue du dveloppeur, elle ne considre pas l'intgralit du systme. Pour prendre
en compte le systme avec un niveau d'abstraction suprieur des modles de menaces tels que
STRIDE peuvent tre utiliss [Microsoft 2002]. Associer ces modles de haut niveau permettrait
de prendre en compte la scurit du systme de manire plus large et de considrer des vecteurs
d'attaques dirents.
Enn, ce modle ne considre que les attaques et ne modlise pas en soi les dfenses. Combiner
attaques et dfenses dans une mme reprsentation orirait une solution intressante permettant
de les confronter. Les auteurs de [Kordy et al. 2010] proposent une telle approche sous la forme
d'arbres d'attaque et de dfense. Une telle reprsentation pourrait donner lieu des formes
de rsolution utilisant, par exemple, la thorie des jeux [Manshaei et al. 2012]. Cette thorie a
galement t applique, au niveau du langage, l'analyse de la scurit du ot d'information
d'un programme par interprtation abstraite [Malacaria & Hankin 1999].
Chapitre 4
Vrication de scurit
sous attaques simules
Sommaire
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.2 Vrication statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.2.1 Exemple de proprits de scurit . . . . . . . . . . . . . . . . . . . . . 111
4.2.2 Vrication d'intervalle de valeurs . . . . . . . . . . . . . . . . . . . . . 113
4.2.3 Limites de la vrication et solution . . . . . . . . . . . . . . . . . . . . 115
4.2.4 Instrumentation et gnration d'annotations . . . . . . . . . . . . . . . . 115
4.2.5 Vrication de scurit et simulation d'attaques physiques . . . . . . . . 118
4.3 Rduction du nombre d'attaques simules . . . . . . . . . . . . . . . 118
4.3.1 Attaques considres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.3.2 Typage de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.3.3 Classes d'quivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.3.4 Conditions et boucles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.3.5 Exprimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.5 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.1 Introduction
Dans ce chapitre, nous nous intressons la vrication automatique de proprits de scurit
en nous appuyant sur une analyse statique du code C. Le langage C est utilis pour le systme
d'exploitation des cartes puce ainsi que pour ses applications. L'utilisation de ce langage
bas niveau permet une meilleure ecacit par rapport des solutions de type Java Card qui
ncessitent une machine virtuelle. Nanmoins, le langage C soure de dirents inconvnients :
Il n'est pas fortement typ : les outils d'analyse statique ont des dicults pour l'infrence
de type, en particulier avec les conversions de type et les pointeurs ;
la mmoire peut tre librement accde : les outils d'analyse statique ne peuvent pas
forcment dduire ce qui est manipul sauf en reprsentant l'intgralit de la mmoire
(avec des dicults supplmentaires avec des structures de type union) ;
le langage n'est pas orient objet : les outils d'analyse statique ne peuvent s'aider de
l'encapsulation ou de l'hritage pour en dduire des proprits.
Ces inconvnients posent des dicults aux analyseurs statiques et rendent plus dicile
l'analyse de proprits qui doivent prendre en compte ces restrictions. De plus, les codes de
carte puce contiennent des instructions assembleur qui manipulent directement des registres
110 Chapitre 4. Vrication de scurit sous attaques simules
et ne sont pas reconnus par les analyseurs statiques de code C se limitant le plus souvent au C
de type ANSI. La justication derrire l'utilisation d'une analyse statique du code est qu'elle
est indpendante de l'environnement ce qui la rend plus gnrique et lui permet d'tre intgre
plus tt dans le processus de dveloppement de la carte. L'auteur de [Leveugle 2007] conrme
l'intrt d'intgrer des tests de scurit de manire anticipe y compris au niveau matriel.
Dans ce chapitre, nous prsentons une premire mthode an de vrier que le code source
respecte bien certaines particularits. Dans les chapitres prcdents, nous avons prsent un
formalisme permettant d'exprimer les besoins en scurit d'un systme et un modle d'attaque
servant caractriser les possibilits d'un attaquant. Pour chacun d'eux, nous avons adopt une
approche de haut niveau permettant de reter les besoins fonctionnels du systme sur le code
source. Comme nous l'avons mentionn dans l'introduction, la carte agit passivement en rponse
aux instructions du terminal. Ainsi, le code excut dpend essentiellement des informations se
trouvant dans la commande envoye la carte et aussi des informations mmorises en eeprom.
Ces informations seront manipules par le programme l'aide de variables au cours de conditions
qui modieront le comportement du programme. An de vrier des besoins fonctionnels et leur
scurit, il convient de s'intresser aux variables du programme et valider que les informations
contenues dans celles-ci sont bien celles attendues mme sous attaque physique. Si ce n'est
pas le cas, un attaquant peut trs bien l'aide d'une attaque modier le comportement du
programme en sa faveur. Dans la section 4.2, nous prsentons comment Frama-C, un outil
d'analyse statique, peut permettre la vrication d'intervalles de valeurs dans des variables et
introduisons par injection de code des simulations d'attaques physique. Dans la section 4.3,
nous amliorons cette mthode en nous aidant des rsultats tablis dans les chapitres 2 et 3.
Cette amlioration introduit des classes d'quivalence pour les consquences des attaques. Ces
classes permettent de considrablement rduire le nombre d'attaques eectuer tout en couvrant
l'intgralit des attaques de notre modle. Nous apportons dans cette section la preuve de cette
couverture ainsi que la mthode permettant de dterminer la position d'un nombre minimum
de points d'attaques permettant de garantir cette couverture. Les contributions couvertes dans
ce chapitre font rfrence la publication [Berthom et al. 2010].
4.2 Vrication statique

Lorsqu'on tente d'utiliser un analyseur statique sur un code relativement complexe, on s'aper-
oit assez rapidement que des proprits simples ne peuvent tre vries directement : l'outil ne
peut conclure du fait des limitations prcdemment voques. Une dicult additionnelle pour
les analyseurs statiques est le manque de contexte d'excution par rapport une analyse dyna-
mique. Par exemple, les informations contenues en eeprom ne sont pas dductibles de manire
statique si elles sont incorpores dans une phase de personnalisation eectue par le terminal.
Dans cette section, nous proposons une mthode permettant d'aider l'outil de vrication
conclure sur le respect ou la violation de la proprit exprime. Pour simplier nos explications,
nous n'avons considr qu'une seule proprit concernant les variables : l'appartenance un
intervalle. Cela permet par exemple d'exprimer le fait que le PIN doit appartenir l'intervalle
de valeurs numriques [0, ..., 9999].
Il existe deux avantages vrier statiquement des intervalles de valeurs. La premire est
d'ordre technique : elle permet en une seule passe de vrier un ensemble discret de valeurs
4.2. Vrication statique 111
qui demanderait dynamiquement autant de tests que de valeurs tester. Sur des intervalles
importants, le gain en terme de temps de test est signicatif. L'autre avantage concerne la
scurit qui demande d'associer un sens ces valeurs en fonction du contexte d'excution. Ainsi,
pour un scnario donn, il existe pour une variable du programme un instant de l'excution,
un ensemble de valeurs qui peuvent tre considres comme bonnes ou mauvaises du point de
vue de la scurit. Cette direntiation dpend du gain que peut tirer l'attaquant obtenir
une valeur pour une variable dirente de celle normalement attendue. Par exemple, russir
rduire le montant d'une transaction un montant infrieur celui attendu peut lui tre
avantageux. Russir empcher le dcompte d'un compteur de scurit, retant le nombre
d'essais de prsentation du PIN restants, constitue un autre exemple. En eet, cela permet
l'attaquant de dcouvrir le PIN l'aide d'une prsentation exhaustive d'un maximum de
9999 PINs. Dans ce dernier exemple, le fait de ne pas dcompter se traduit par le fait que
le compteur garde une valeur identique aprs dcrmentation. Ces exemples peuvent donc se
traduire en intervalles de valeurs ou un ensemble de valeurs discrtes. Ainsi, en vriant qu'une
variable contient bien une valeur spcique ou un ensemble de valeurs spciques un moment
de l'excution du programme, on vrie galement que pour un scnario fonctionnel donn, le
programme respecte bien le comportement attendu. De plus, on peut remarquer que vrier
qu'une valeur discrte appartient un ensemble de valeurs dni revient vrier que cette
valeur n'appartient pas deux intervalles de valeurs (ou suite de valeurs discrtes continues).
Ces intervalles sont dnis comme l'intersection de l'ensemble avec la valeur discrte. On peut
donc toujours crer un ou plusieurs intervalles de valeurs permettant de vrier qu'une variable
un point donn du programme contient une valeur spcique.
En partant d'un code de dmonstration dcrit dans la section 4.2.1, nous montrons que l'outil
de vrication n'arrive pas vrier cette proprit d'intervalle et nous montrons comment injec-
ter des informations complmentaires pour l'aider. Une fois cette tape franchie, nous prsentons
en section 4.2.5 comment prendre en compte les attaques physiques dcrites en chapitre 3.
L'outil d'analyse statique retenu pour eectuer les analyses est Frama-
C [Correnson et al. 2010]. Cet outil utilise des annotations an d'exprimer les garanties
souhaites. Par consquent, les objectifs de vrication doivent tre exprims dans le langage
acsl [Baudin et al. 2010]. Par exemple, l'intervalle de la variable pin s'crit :
/*@ assert 0 <= pin_input <= 9999; */
4.2.1 Exemple de proprits de scurit

Soit l'extrait de code C prsent dans le listing 4.1. Ce code ralise une opration bancaire.
La fonctionnalit principale se trouve dans la fonction banking qui appelle la fonction work.
Ces deux parties de code sont extraites d'un code plus gnral crit en C 8051. Cependant, les
parties spciques au 8051 ont t remplaces par leur quivalent en C car elles sont dicilement
interprtes par un analyseur de code source spcialise dans le C ANSI.
Dans ce code, l'attaquant peut se concentrer en premier lieu sur les mcanismes d'authenti-
cation, en ligne 21. Pour un fonctionnement sans attaque, quand le mauvais code PIN est entr,
la transaction est abandonne. L'attaquant peut alors perturber la condition if pour obtenir
malgr tout l'excution de la fonction work pour tout code PIN entr. Dans le modle d'attaque
du chapitre 3, cette attaque peut tre reprsente l'aide d'un goto inject avant la ligne 22 et
un label juste avant la ligne 23.
Listing 4.1 Exemple de code C pour une transaction bancaire
#include <stdio.h> 1
typedef unsigned int word; 2
word number1; /* 2 variables globales initialises ailleurs */ 3
word number2; 4
extern word scanp(); /* Mthode de saisie du code PIN */ 5
6
word work() { /* Travail une fois authentifi */ 7
word result; 8
word x = 0; 9
if (number1 > 10) 10
x++; 11
result = number1 + number2 + x; 12
return result; 13
} 14
15
void banking() { /* Code principal de lapplication bancaire */ 16
17
word res; 18
word pin_input; 19
20
pin_input = scanp(); 21
if (pin_input == 1234) { 22
res = work(); 23
} 24
} 25
D'autre part, l'attaquant peut aussi se concentrer sur la fonction work qui calcule une valeur
(par exemple le montant de la transaction) avant de retourner cette valeur. L'attaquant peut
alors perturber un des termes de l'addition de la ligne 12. L'attaquant peut perturber par exemple
la variable locale x ou l'une des variables globales number1 ou number2 an d'obtenir le rsultat
souhait. Par exemple, l'attaque x=255; peut tre injecte juste avant la ligne 12. Pour obtenir ce
rsultat, plusieurs attaques sont possibles. Par ailleurs, si la fonction work() possde un nombre
important d'instructions, cela donne plus de temps l'attaquant pour raliser l'attaque.
Les deux exemples d'attaques prcdemment voqus tentent de violer les proprits de
scurit suivantes, comme dcrites dans le chapitre 3 :
l'intgrit d'excution de la ligne 22, an de garantir la bonne authentication de l'uti-

lisateur ;
lintgrit de la variable result, cens garantir le bon calcul du rsultat dans la fonction
work.
Nous ne dcrivons pas plus formellement ces proprits en utilisant le formalisme du cha-
pitre 3 puisqu'il est dicile de traduire de telles proprits directement en acsl. Cette partie
mriterait une tude approfondie part entire. Cependant, le langage acsl permet d'exprimer
des proprits simples de comparaison de variables. Dans la suite, nous supposons donc par sim-
plication que l'objectif de scurit est de vrier l'appartenance d'une variable un intervalle.
Comme voqu prcdemment, cela peut se traduire par la vrication que PIN appartient
l'intervalle [0, ..., 9999].
Listing 4.2 Exemple de code C pour une transaction bancaire avec des annotations acsl
word number2; 4
6
word x = 0; 8
if (number1 > 10) 9
x++; 10
/* Check property 2 */ 11
/*@ assert 0 <= x <= 1; */ 12
return result; 14
} 15
16
word res; 18
word pin_input; 19
20
/*@ assert 0 <= pin_input <= 9999; */ 23
if (pin_input == 1234) { 24
res = work(); 25
} 26
/*@ assert 0 <= res <= 100; */ 28
} 29
4.2.2 Vrication d'intervalle de valeurs

En considrant que x est une variable sensible, le dveloppeur souhaite que cette variable
appartienne un intervalle prdni [xmin , xmax ]. Le but de ce chapitre n'est pas seulement de
vrier qu'une telle proprit est satisfaite mais aussi qu'elle est garantie mme si une attaque
physique est ralise. En eet, si elle est mise en dfaut pour une attaque donne, le dveloppeur
doit mettre en place une contre-mesure adquate et doit ensuite vrier nouveau la robustesse
de sa contre-mesure.
La proprit est exprime en utilisant le langage acsl [Baudin et al. 2010] dont les annota-
tions sont incluses en tant que commentaires C. A partir de l'exemple du listing 4.1, on souhaite
que les trois proprits suivantes soient vries.
1. Le pin doit tre dans l'intervalle [0, 9999] avant le test if (ligne 22) ;
2. La variable x doit tre dans l'intervalle [0, 1] avant de calculer result (ligne 12) ;
3. A la n de la mthode banking(), le rsultat doit tre entre 0 et 100 (ligne 24).
On peut formaliser en acsl ces trois proprits l'intrieur du code source, comme le montre
le listing 4.2. Ces proprits doivent tre spcies par le dveloppeur ou un spcialiste en charge
de la scurit de l'application.
La vrication de code source non attaqu incluant les annotations donne des rsultats
dirents suivant la proprit considre. Un extrait d'analyse Frama-C est prsent dans
le listing 4.3. Frama-C isole d'abord les variables globales number1 et number2 et leur af-
fecte un intervalle de valeurs inconnues. Ensuite, une analyse de valeur par interprtation
Listing 4.3 Analyse Frama-C du listing 4.2
[ v a l u e ] ====== I N I T I A L STATE COMPUTED ====== 1

[ v a l u e ] Values o f g l o b a l s a t i n i t i a l i z a t i o n 2
number1 [ . . ] 3
number2 [ . . ] 4
[ k e r n e l ] No code f o r f u n c t i o n scanp , d e f a u l t a s s i g n s generated 5
banking i n p u t 2 . c : 23 : [ v a l u e ] A s s e r t i o n g o t s t a t u s unknown 6
banking i n p u t 2 . c : 12 : [ v a l u e ] A s s e r t i o n g o t s t a t u s v a l i d 7
banking i n p u t 2 . c : 28 : [ v a l u e ] A s s e r t i o n g o t s t a t u s unknown 8
[ v a l u e ] ====== VALUES COMPUTED ====== 9
[ v a l u e ] Values f o r f u n c t i o n work : 10
r e s u l t [ . . ] 11
x { 0 ; 1; } 12
[ v a l u e ] Values f o r f u n c t i o n banking : 13
r e s [ . . ] o r UNINITIALIZED 14
pin_input [0 ..9999 ] 15
abstraite [Cuoq & Prevosto 2010] est eectue pour les variables et les valeurs obtenues sont
confrontes aux exigences des annotations de type assert .
La proprit 1 est teste la ligne 23. Cette proprit ne peut tre valide (status =
unknown) car elle dpend de la fonction scanp 1 dont le code n'a pas t donn Frama-
C;
La proprit 2, la ligne 12, est valide. Cette proprit est facilement valide par Frama-C
(status = valid) car x est initialis zro dans la fonction work et est incrmente au plus
une fois ;
La proprit 3, la ligne 28 ne peut tre valide (status = unknown). Cela est d au retour
de la fonction work() qui retourne une valeur indtermine car les valeurs des variables
globales number1 et number2 ne sont pas connues.
On remarque qu' la n de l'analyse, Frama-C conclut que la variable pin_input est dans
l'intervalle [0, ..., 9999]. Cela est d au fait que chaque annotation acsl est d'abord vrie
et, si elle obtient le statut unknown, est alors suppose vraie pour la suite du processus de
vrication. Ainsi, les rsultats importants du listing 4.3 sont les validations d'assertion dans la
partie INITIAL STATE COMPUTED.
Une autre remarque importante est qu'un assert est suppos vrai ds qu'il est de type
unknown. Les vrications suivantes utilisent alors la valeur suppose vraie pour cet assert. Ainsi,
le prochain rsultat obtenu dpend des rsultats de type unknown qui le prcdent. Par exemple,
la proprit 2, la ligne 12, pourrait dpendre du rsultat de la proprit 1, la ligne 23, qui
est de type unknown (i.e., suppose vraie pour la validation de la proprit 2). Cependant, dans
cet exemple, il n'y a pas de dpendance entre les deux proprits. Donc, pour que le rsultat de
l'ensemble des vrications soit exploitable, il faut que toutes les proprits soient dtermines
(de statut valid ou invalid, mais pas unknown). Dans la suite, nous montrons une mthode pour
aider l'analyse statique dterminer les cas unknown.
1. scanp reprsente un quivalent de scanf pour la carte puce : il lit le PIN depuis le terminal.
4.2.3 Limites de la vrication et solution

Les rsultats observs dans le listing 4.3, nous ont montr, pour l'exemple de code contenant
nos trois proprits, que certaines proprits ne peuvent tre vries par Frama-C. Plusieurs
raisons expliquent cette limitation.
Premirement, le code analys est partiel. Le code de certaines fonctions, comme scanp,
n'est pas donn Frama-C. Cependant, mme si le code relatif scanp avait t fourni, aucun
analyseur statique ne peut en dduire d'information exploitable d'une fonction qui demande des
informations externes au programme de manire dynamique. Dans notre cas, les informations
sont fournies dynamiquement par le terminal. Frama-C ne peut que supposer un ensemble de
valeur maximal pour ces valeurs entres, ce qui rend l'analyse indcidable. De plus, intgrer
l'intgralit du code source d'un programme de carte puce l'analyseur est une opration
longue et fastidieuse : le code comprend des appels non-ANSI et des portions de code assembleur
qui perturbent l'analyseur. On cherche donc restreindre le champ d'analyse an de contourner
ces dicults.
Deuximement, Frama-C peut tre perturb par des codes C complexes, par exemple si
des pointeurs de fonction C sont concerns par l'analyse. Ce problme, relatif aux analyseurs
statiques, n'est pas un sujet trait dans cette thse et n'est donc pas tudi plus avant.
Nanmoins, il est important de russir valider les proprits de scurit formalises en acsl
pour le code standard, sans attaque. Pour ce faire, nous proposons dans la suite une mthode
qui traite deux limitations prcises dues la structure du code :
les variables globales qui peuvent tre inconnues ou modies par des fonctions appeles
dont l'analyseur n'a pas le code ;
l'appel des fonctions dont l'analyseur n'a pas le code et dont le retour dnit une variable
locale. Dans le code du listing 4.2, la fonction scanp illustre un tel cas.
4.2.4 Instrumentation et gnration d'annotations

Dans cette section, nous proposons une solution pour aider l'analyseur statique lorsqu'il est
en prsence de variables globales et d'appels de fonctions externes. Nous proposons de collecter
des informations l'excution pour ensuite les injecter sous forme d'annotations dans le code
source de dpart. Ainsi, de nouvelles informations seront disponibles lors de l'analyse statique.
La solution est base sur une instrumentation du code source an d'observer l'volution des va-
riables globales et les rsultats retourns par les fonctions durant leur excution dynamique dans
un scnario sans attaque. An d'obtenir des informations signicatives, il est ncessaire d'ex-
cuter un certain nombre de fois le programme dans des scnarii fonctionnellement cohrents.
En eet, obtenir, pour une variable, des valeurs antagonistes du point de vue fonctionnel rend
les valeurs obtenues incohrentes du point de vue d'un comportement de scurit. Les conclu-
sions labores partir de l'analyse seront alors incorrectes. Cette instrumentation permet de
construire des ensembles de donnes reprsentatives des excutions observes. Pour une variable
audite, plusieurs cas sont possibles pour une variable observe :
une mme valeur est collecte chaque excution : on peut alors gnrer une annotation
acsl xant la valeur de cette variable ;
quelques valeurs sont collectes sur un nombre signicatif d'excutions : on peut alors
gnrer une annotation acsl dcrivant un intervalle discret ou un intervalle si cela est
plus appropri ;
Une fois ces annotations gnres, elles sont injectes dans le code original avant une nouvelle
analyse statique des proprits d'intervalles de scurit voulues.
Code instrument pour l'observation

Un programme Java a t dvelopp pour analyser les codes sources C et dterminer les
instructions qui doivent tre audites. Dans notre cas, il s'agit de trouver les variables globales
et les appels de fonction externes dont le rsultat est utilis (ou ayant un paramtre pass par
adresse).
Par exemple, dans le listing 4.2, la valeur de la variable number1 inuence la condition ligne 9
et peut dclencher l'instruction x++. Pour chaque variable globale, le programme Java cherche les
lignes de code utilisant cette variable en lecture. Juste avant chaque ligne de code, le programme
injecte une squence de code an d'extraire la valeur de cette variable au moment de l'excution
dynamique du programme. Un exemple de squence de code pour auditer la variable number1
est prsent en listing 4.4. Il permet de rcuprer la valeur de number1 lors de son utilisation en
ligne 9, ce qui explique la notation @9, qui permet ensuite de retrouver l'emplacement du point
d'audit lors de l'analyse de la trace d'excution.
Listing 4.4 Patch pour l'audit de la variable globale number1
/* DBUT AUDIT */ 1
char * buf_1 = ( char * ) malloc (20 * sizeof ( char ) ) ; 2
sprintf ( buf_1 , "%i" , number1 ) ; 3
char temp2_1 [ 400 ] = "@9 : number1 = " ; 4
strcat ( temp2_1 , buf_1 ) ; 5
fprintf ( dump , "%s\n" , temp2_1 ) ; 6
/* DBUT AUDIT */ 7
if (number1 > 10) 8
De manire similaire, le programme Java audite les fonctions non analyses par Frama-
C. Pour scanp, la variable audite est celle recevant l'aectation du retour de la fonction. La
squence de code d'audit est ajoute juste aprs l'appel scanp.
Aprs excution, un chier d'audit produit, par exemple, l'extraction suivante :
Listing 4.5 Extrait du chier d'audit
@ 21 : pin_input = 1234 1
@ 9 : number1 = 10 2
@ 13 : number1 = 10 3
@ 13 : number2 = 0 4
Injection des informations collectes

Les informations collectes pendant l'excution sont lues dans le chier de log et de nouvelles
annotations acsl sont insres aux lignes fournies par ce chier, comme le montre le listing 4.6,
an de permettre la vrication statique. Pour les variables globales, une annotation de type
assert est ajoute avant l'utilisation de la variable. Pour les fonctions inconnues comme scanp,
une annotation de type assert est ajoute aprs que la variable ait reu l'aectation du retour
de la fonction. Pour les ensembles discrets, l'oprateur logique || permet de reprsenter une
numration, comme par exemple /*@ assert number1 == 10 || number1 == 11; */.
Listing 4.6 Injection des annotations acsl partir des informations collectes
word number2; 4
6
word result; 8
word x = 0; 9
/*@ assert number1 == 10; */ /* INSERTION AUDIT */ 10
11
if (number1 > 10) 11
x++; 12
/*@ assert 0 <= x <= 1; */ 14
return result; 16
} 17
18
word res; 20
word pin_input; 21
22
/*@ assert pin_input == 1234; */ /* INSERTION AUDIT */ 24
/*@ assert 0 <= pin_input <= 9999; */ 25
if (pin_input == 1234) { 26
res = work(); 27
} 28
/*@ assert 0 <= res <= 100; */ 30
} 31
Listing 4.7 Analyse Frama-C avec les nouvelles informations
banking i n p u t 3 . c : 24 : [ v a l u e ] A s s e r t i o n got status unknown 1

banking i n p u t 3 . c : 25 : [ v a l u e ] A s s e r t i o n got status valid 2
r e s u l t {10; } 10
x {0; } 11
r e s {10; } 13
p i n _ i n p u t {1234; } 14
Vrication des proprits avec les informations collectes

Aprs avoir inject de nouvelles assertions partir de l'observation de l'excution, Frama-C
peut vrier les proprits demandes. La sortie de l'analyse est rapporte dans le listing 4.7. Les
annotations de type assert qui correspondent aux informations injectes peuvent avoir un statut
de type unknown car ces informations sont prcisment ce que l'analyseur statique ne pouvait
pas dduire dans la premire analyse. Le fait que ces annotations soient de type unknown n'est
pas gnant : ces assertions deviennent vraies pour l'analyseur statique. On observe que cela se
produit bien pour les assertions des lignes 24, 10 et 15.
Ensuite, on observe dans le listing 4.7 que les proprits vises obtiennent un statut valid.
Cela se produit pour les trois proprits, en ligne 25, 14 et 30. La collecte et l'injection d'infor-
mations a donc permis d'aider Frama-C vrier les proprits voulues.
4.2.5 Vrication de scurit et simulation d'attaques physiques

L'intrt de vrier des proprits souhaites sur le code original rside dans la vrication
de ces mmes proprits en intgrant les attaques issues du modle d'attaque prsent dans le
chapitre 3. Dans la suite, on ne considre que les attaques de donnes, telles que dnies dans
la section 3.4.4 du chapitre 3. Le modle d'attaque de contrle de ot peut aussi tre utilis,
cependant, traiter les attaques de donnes est particulirement intressant car un analyseur
statique travaille justement sur les valeurs possibles des variables manipules.
Soit une attaque physique perturbant une variable x juste avant la ligne 15 du listing 4.6 qui
calcule le rsultat de la fonction work(). L'attaque injecte peut par exemple tre x = 255. Dans
ce cas, la sortie donne par Frama-C indique clairement que le statut de la troisime proprit
est invalid, comme le montre le listing 4.8.
Ainsi, la mthode d'analyse statique propose combine au modle d'attaque permet de
mettre en vidence des violations des proprits d'intervalle formalises en acsl.
4.3 Rduction du nombre d'attaques simules

La section prcdente a prsent une mthode pour vrier une proprit de scurit pour un
code sous attaque physique. La dicult pour exploiter une telle mthode rside dans le nombre
4.3. Rduction du nombre d'attaques simules 119
Listing 4.8 Analyse Frama-C avec une attaque de valeur simule

banking i n p u t 3 . c : 30 : [ v a l u e ] A s s e r t i o n got status invalid 7
( stopping propagation ) . . 8
banking i n p u t 3 . c : 4 3 : [ k e r n e l ] warning : non t e r m i n a t i o n d e t e c t e d i n f u n c t i o n 9
banking 10
r e s u l t {265; } 13
x {255; } 14
NON TERMINATING FUNCTION 16
de codes dirents tester. Ce nombre dpend directement du nombre possible d'attaques

physiques. Ce nombre est encore plus important si l'on souhaite simuler des attaques transientes
ou transientes rptitives.
D'un point de vue spatial, l'attaque peut avoir lieu tous les endroits du code source ce qui
rend le nombre de codes sous attaque considrer proportionnel la taille du code. Ensuite, pour
un point particulier du code, il faut considrer toutes les variables (resp., les contrles de ot)
qu'il est possible de perturber dans ce contexte. En se plaant dans le pire des cas, l'ensemble
des variables (resp., des contrles de ot) du programme pourraient tre attaques. Ainsi, le
nombre de codes considrer est proportionnel la taille du code multipli par le nombre de
variables (resp., le nombre de contrles de ot). An de rduire le nombre de codes attaqus
tester, nous proposons une rduction qui minimise le nombre de codes attaqus considrer. Le
principe de l'approche utilise est semblable celle adopte par [Barbosa et al. 2005] pour viter
la superposition de deux bit ips lors de tests d'injection de fautes. Nous utilisons une approche
similaire au niveau C dans un contexte de scurit pour rduire l'espace d'attaque considrer.
Dans cette section, nous rduisons le nombre de codes en nous appuyant sur la notion d'qui-
valence de codes. Deux codes attaqus sont considrs quivalents quand les eets des deux
injections donnent les mmes consquences lors de l'excution du code. Par exemple, en consi-
drant le code de la fonction work() du listing 4.2, l'injection d'une attaque contre number2 a le
mme eet en ligne 8 ou en ligne 13. Ceci n'est pas vrai pour l'injection d'une attaque contre
number1 qui impacte la condition en ligne 9 si l'injection est en ligne 8. Ainsi, dans ce dernier
exemple, il faut considrer deux classes d'quivalences pour les attaques concernant number1 :
les codes attaqus o l'attaque se produit avant la ligne 9 et les codes attaqus o l'attaque se
produit aprs la ligne 9.
Dans la suite, nous utilisons les notions d'quivalence de codes et de couverture d'une classe
d'quivalence par une autre. Le but est de calculer l'ensemble minimum de codes attaqus
donner l'tape de vrication tout en garantissant la couverture totale de tous les eets d'at-
taques possibles. Les dnitions et les algorithmes prsents dans cette section s'appuient sur
la dtermination des oprations de lecture et d'criture pour des variables dont la modica-
tion peut potentiellement permettre de raliser une attaque dangereuse pour l'application. Ces
oprations de lecture et d'criture correspondent aux dnitions et utilisations des variables/don-
nes (use-def ) et l'analyse de dpendance utilise par les compilateurs pour eectuer certaines
optimisations [Muchnick 1998].
4.3.1 Attaques considres

Dans la suite de ce chapitre, nous supposons qu'une attaque permet de modier une variable
x. Typiquement, nous reprsenterons une telle attaque par le code x = value;.
Dnition 15 Attack(code, i, x) est une copie du code original o l'attaque ciblant x est injecte
entre les lignes i 1 et i.
Nous considrons qu'un code source de taille n contient autant d'instructions C que le nombre
de lignes, c'est--dire n. Ainsi, le code source rsultant d'une injection d'attaque utilisant la
fonction Attack possde n+1 lignes. Ce changement dans la numrotation du code source peut
troubler les explications des sections suivantes. Nous considrons donc qu'une ligne injecte par
1
l'attaque est insre en ligne i 2 et n'a pas d'inuence sur la numrotation du code source
original.
4.3.2 Typage de code

A partir d'un code source code et d'une variable x, nous dnissons les types read et write
d'une ligne de code source en fonction de l'opration eectue sur x. Dans certains cas, une ligne
C peut eectuer les deux oprations simultanment, comme x++ qui est type rw.
Dnition 16 T ype(code, x, i) dni comme suit : la ligne i du code est type par read,
Soit
write, rw ou pour une variable x. Le type read (respectivement, write) signie que la ligne de
code lit (respectivement, crit) la variable x. Le type signie qu'aucune opration n'est ralise
sur x.
Dans la suite, nous raisonnons sur les lignes de code qui dnissent une fonction f, note
codef . L'analyse est locale au bloc de la fonction et le but est de dterminer la prochaine utilisa-
tion ou dnition d'une variable, aprs qu'une attaque soit ralise. Comme nous ne souhaitons
pas analyser l'intgralit du code source, l'analyse s'intresse uniquement au bloc de la fonction
et n'entre pas dans l'analyse des appels de sous-fonctions.
Cependant, comme il est ncessaire de typer un appel de fonction appel avec un paramtre
sensible x, une analyse interprocdurale peut tre eectue an de raner le typage des appels
de fonctions. Par exemple, en fonction du corps de la fonction, un appel comme proc(&x) peut
tre typ read ou write, ou bien . La table 4.1 donne le typage des appels de fonctions que
nous considrons et qui reprsente une sur-approximation de ces types qui est utile lorsqu'on ne
possde pas le code source de ces fonctions ou que l'on ne souhaite pas les analyser.
La notion de typage d'une ligne de code peut maintenant tre tendue une dnition
rcursive qui permet de qualier, partir d'un point particulier i le prochain type de x dans le
code source :
Variable sensible : x Si x est locale Si x est globale
y = f(x) ; read rw
x = f(y) ; write rw
proc(& x) ; rw rw
proc(y) ; rw
Table 4.1 Rgles de typage pour les appels de fonctions
Dnition 17 Soit T ypeAf ter(codef , x, i) la fonction qui retourne le type de la prochaine ligne
type (dirent de ) partir de i utilisant x. Elle est dnie rcursivement par :

T ypeAf ter(codef , x, last) =

T ype(code , x, i) si T ype(code , x, i) 6=
f f
T ypeAf ter(code , x, i) =

f
T ypeAf ter(codef , x, i + 1) sinon
o last est la dernire ligne du bloc de la fonction codef .
T ypeAf ter(codef , x, i) ne retourne pas de type si la fonction n'utilise pas x aprs la ligne i,
lignei incluse. Si une ligne du bloc de code de la fonction utilise x aprs la ligne i (ou aecte
potentiellement x dans l'un des cas de la table 4.1), T ypeAf ter(codef , x, i) retourne ce prochain
type d'utilisation de x. Si ce type existe, nous pouvons extraire le numro de la ligne qui dnit
ce type, comme le prsente la dnition suivante :
Dnition 18 LineT ypeAf ter(codef , x, i) la fonction retournant le numro de

Soit ligne d-
nissant T ypeAf ter(codef , x, i), si ce type existe, - 1 a t choisi pour les autres cas.
Algorithme 1 Calcul de TypeAfter pour un code squentiel

1: function TypeAfter-sequentiel(code, x, i)
2: if i = last(code) then
3: return NULL
4: Type type Type(code, x, i)
5: if type 6= NULL then
6: return type
7: return TypeAfter(code, x, i+1)
Dans le cas d'un code linaire, ces deux fonctions peuvent se calculer par les algorithmes
donns aux algorithmes 1 et 2. Un code d'exemple est donn dans le listing 4.9 qui illustre les
deux dnitions prcdentes.
Algorithme 2 Calcul de LineT ypeAf ter pour un code linaire

1: function LineTypeAfter-linraire(code, x, i)
2: Type type TypeAfter(code, x, i)
3: if type 6= NULL then
4: j i
5: while true do
6: Type type2 Type(code, x, j)
7: if type2 = type then
8: return j
9: j+1
10: return -1
Listing 4.9 Code d'exemple illustrant les fonctions de typage
word f() { // TypeAfter(x,1)=w 1

word result; // Type(x,2)= 2
word y = 0; 3
word x = 0; // Type(x,4)=w 4
result = 0; // TypeAfter(x,5)=rw 5
x = x + 1; 6
result = result + y; // TypeAfter(x,7)=r 7
y--; 8
send(x); 9
y--; // LineTypeAfter(x,10)=12 10
result = 2 * y; 11
result = result + x; 12
y = 0; // TypeAfter(x,13)= 13
return result; // LineTypeAfter(x,14) nest pas dfini 14
} 15
4.3.3 Classes d'quivalence

Dans cette section, nous dnissons la notion de classe d'quivalence sur les codes attaqus
tels que dnis dans la section 4.2.5. Nous restreignons pour l'instant l'tude un code squen-
tiel au niveau du contrle de ot, i.e., avec un code source qui ne contient pas de boucle ou
de conditions : le code est alors vu comme une squence linaire d'instructions C comme des
aectations, des appels de fonctions et des manipulations de variables. Pour un tel code, nous
montrons que les classes d'quivalence correspondent au nombre minimal de codes vrier par
l'analyseur statique pour garantir la proprit de scurit voulue. Le cas gnral, pour un code
contenant des conditions et des boucles, est tudi plus tard en section 4.3.4.
Dnition 19 Attack(codef , i, x) et Attack(codef , j, x) sont quivalentes, not

Deux attaques
Attack(codef , i, x) Attack(codef , j, x), si et seulement si les valeurs de x sont gales entre le
code excut lors de Attack(codef , i, x) et le code excut lors de Attack(codef , j, x) pour chaque
lecture de x pendant cette excution.
Il faut noter que l'on peut inclure le code original dans l'ensemble des codes attaqus. De
cette manire, la classe d'quivalence de celui-ci correspond aux codes attaqus pour lesquels les
attaques n'ont pas d'eet. Le lemme suivant permet d'identier cette classe.
Lemme 2 Si T ypeAf ter(codef , x, i) {write, } alors Attack(codef , i, x) codef .
Preuve: Dans le premier cas,T ypeAf ter(codef , x, i) = write. La prochaine opration sur x
aprs la ligne i est de type write, disons ligne j . Donc, il n'existe aucune opration read entre
les lignes i et j . Toute attaque qui modie x dans cet intervalle est inutile car x est cras la
ligne j .
Dans le second cas, T ypeAf ter(codef , x, i) = signie qu'il n'y a aucune opration read ou
write dans les oprations restantes. Donc, l'attaque n'a aucun eet.
Par exemple, en utilisant le listing 4.9, le lemme 2 implique qu'injecter une attaque contre x
la ligne 1 (avant l'excution de la premire instruction de la fonction) ou la ligne 5 n'a pas
d'eet sur le code : ces attaques sont quivalentes au code original.
Le lemme suivant permet d'identier les autres classes pour un code linaire :
Lemme 3 Si T ypeAf ter(codef , x, i) {read, rw} alors
Attack(codef , i, x) Attack(codef , LineT ypeAf ter(codef , x, i), x).
Preuve: Aprs la ligne i, la prochaine opration concernant x est de type read, la ligne j =
LineT ypeAf ter(codef , x, i). Toute attaque qui modie x dans l'intervalle [i, j] a les mmes
consquences sur x qu'une attaque eectue en ligne j car aucune ligne dans l'intervalle [i, j 1]
n'utilise en lecture ou criture x. Donc, tous ces codes attaqus sont quivalents au code attaqu
en ligne j .
Par exemple, en utilisant le listing 4.9, le lemme 3 implique que l'injection d'une attaque
contre x la ligne 7 est quivalent injecter l'attaque la ligne 9. Ces deux lemmes mettent
en vidence les attaques importantes qui ont des consquences et celles qui n'en ont pas. L'ide
principale est d'tudier les attaques qui ont des consquences et de rduire leur nombre au
minimum.
L'algorithme de la fonction LineT ypeAf ter est relativement simple mettre en uvre
partir de l'algorithme linaire. Le raisonnement est donn par l'algorithme 2.
Avec les deux lemmes prcdents, on obtient un premier rsultat pour les codes linaires.
Thorme 2 S'il y a n oprations de type read ou rw sur x dans codef alors le nombre
minimal de classes d'quivalence est n+1 et ces classes d'quivalence sont :
codef {Attack(codef , i, x), i t.q. T ype(code, x, i) {read, rw}}
Preuve: Chaque ligne i du code est typ par la fonction T ypeAf ter(codef , x, i) par les valeurs
read ou write ou rw ou .
Si le type de cette ligne est write ou , le lemme 2 dit que le code attaqu est quivalent au
code original et donc l'ensemble de ces attaques compte pour une classe d'quivalence : codef .
Si le type de cette ligne est read ou rw, le lemme 3 dit que ce code attaqu est qui-
valent au code attaqu la ligne j = LineT ypeAf ter(codef , x, i). Cette ligne j dnit donc
cette classe d'quivalence. On remarque que cette ligne j est de type read ou rw et que donc
T ype(code, x, j) {read, rw}. Rciproquement, deux lignes de type read ou rw ont ncessai-
rement deux valeurs de LineT ypeAf ter(codef , x, i) direntes et donc dnissent deux classes
direntes. Donc chaque ligne dnie par T ype(code, x, j) {read, rw} dnit une classe unique.

Ainsi, il y a n+1 codes vrier qui sont le code initial codef , plus les codes attaqus o
les attaques sont injectes aux emplacements d'opration read ou write.
Pour dterminer les classes d'quivalence de code qui contiennent des boucles ou des tests, la
prochaine section doit reconsidrer les dnitions des fonctions T ypeAf ter et LineT ypeAf ter
qui devront prendre en compte les ruptures de ot.
4.3.4 Conditions et boucles

Dans la section prcdente, nous avons seulement considr les codes source sans boucles
et sans conditions. An de traiter ces cas, les fonctions T ypeAf ter et LineT ypeAf ter peuvent
tre rednies an de diviser le code d'une fonction contenant des boucles et des conditions en
rgions o les attaques sont quivalentes. Cependant, cela produit un grand nombre de classes
d'quivalence. De plus, certaines classes peuvent tre regroupes comme le montre le listing 4.10
en considrant des attaques contre la variable x. En utilisant la notion de classe prcdente, on
a deux rgions : [1..3] et [4..7]. Si on divise ces classes cause de l'instruction if, on obtient
quatre zones : [1, 2], [3], [4, 5] et [6, 7].
Si on attaque en ligne 4 (attaque 1) ou en ligne 6 (attaque 2), si la condition est vraie, les
consquences de ces deux attaques sont identiques ; si la condition est fausse, l'attaque 1 est
inoprante et l'attaque 2 a des consquences sur la ligne 7. Dans tous les cas de gure, ces deux
attaques ont des consquences la ligne 7 ou sont inoprantes : lors de l'analyse statique, elles
peuvent tre tudies conjointement, en supposant que l'analyse du code original ait t eectue
au pralable.
D'un point de vue de notre modle de classes d'quivalence, cet exemple dnit trois classes :
Le code original ;
Le code attaqu en ligne 3 ;
Le code attaqu en ligne 6.
Cependant, l'analyse statique du dernier cas est dj traite par l'analyse statique des deux
cas prcdents : on dit que cette attaque est couverte par les deux autres. Il est donc inutile de
la simuler. Cette section fait voluer les dnitions des fonctions T ypeAf ter et LineT ypeAf ter
pour tenir compte de cette situation.
Listing 4.10 Exemple de code contenant un if
... 1
if (cond){ 2
z = x; 3
attaque 1 4
} 5
attaque 2 6
y = x; 7
Dnition 20 Une attaqueAttack(codef , i, x) est couverte par une attaque Attack(codef , j, x),
not Attack(codef , i, x) C Attack(codef , j, x), si et seulement si les eets de Attack(codef , i, x)
sur les valeurs de x sont incluses dans les eets de Attack(codef , j, x) sur les valeurs de x ou si
l'attaque Attack(codef , i, x) n'a pas d'eet.
Dans la suite, nous gnralisons les fonctions T ypeAf ter et LineT ypeAf ter pour des sections
de code gnriques. LineT ypeAf ter(code, x, i) retourne un numro de ligne tel que :
Attack(codef , i, x) C Attack(codef , LineT ypeAf ter(code, x, i), x)
Ces deux fonctions sont tendues tout bloc de C, i.e., entre des accolades quilibres. Nous
supposons que la numrotation des lignes est globale tout le code source et que f irst et last
sont deux fonctions sur un bloc C qui donnent respectivement les numros de ligne du dbut et
de n d'un bloc considr.
Conditions
Cette section s'intresse aux conditions, en gnral les structures de type if thenelse. Une
condition peut tre dcompose en trois parties distinctes : la condition cond, le thenblock et
le else block. Ce dernier peut tre vide. On dnit les fonctions suivantes :
block then(block, i ) retourne le bloc then si une instruction if est situe la ligne
numrote i ou si i appartient ce bloc then. Dans le cas inverse, la fonction retourne
NULL ;
block else( block , i ) est dnie de manire similaire vis--vis du bloc else ;
block if( block , i ) est dnie de manire similaire pour tout le bloc if ;
rst ( block ) retourne la premire ligne du bloc block ;
last ( block ) retourne la dernire ligne du bloc block . Si la conditionelle n'a pas de bloc
block else alors last ( block else) retourne la valeur de last ( block then) ;
cond( if block) retourne la condition du bloc if block.
En utilisant ces fonctions, on rednit la fonction T ypeAf ter dans l'algorithme 3. Le principe
gnral de cette fonction est de trouver prcisment l'utilisation suivante de la variable cible. Les
dirents cas sont explors. Un cas particulier est quand on considre une ligne de code avant
une condition et que la variable n'est pas utilise jusqu'au if. Dans ce cas, si la variable est
utilise dans au moins un des blocs de la condition, le type retourn est l'union des deux types
dnis par chacun des blocs. Par exemple, si le bloc then utilise la variable en lecture et le bloc
else en criture, le type rsultant est rw.
Le thorme 2 doit tre modi an de prendre en compte les nouvelles dnitions des
fonctions T ypeAf ter et LineT ypeAf ter. Avant d'arriver la rcriture de ce thorme, nous
devons adapter les lemmes 2 et 3.
Lemme 4 Le lemme 2 reste valide dans le contexte des conditions.
Preuve: On peut restreindre la preuve au cas des blocs if car la dnition de la fonction
T ypeAf ter ne change pas hors de ce contexte.
Si T ypeAf ter retourne , cela signie que l'analyse du code a travers le bloc if sans trouver
d'opration read ou write. L'injection de code concernant cette variable est donc inoprante.
Si la fonction T ypeAf ter retourne write, cela signie que l'opration write a t trouve
l'intrieur ou aprs l'un des blocs du if . Deux cas sont alors considrer.
1. Si l'opration write est trouve aprs le bloc if , alors l'opration annule toute modication
de valeur par une attaque.
Algorithme 3 Fonction TypeAfter pour les conditions

1: function TypeAfter(bloc, x, i)
2: if i = last(block) then . Fin de bloc
3: return
4: if Type(block, x, i) 6= then . La variable est utilise cette ligne
5: return Type(block, x, i)
6: Block bif block-if(block, i)
7: if bif 6= NULL then . La ligne est dans un bloc if
8: Block bthen block-then(block, i)
9: Type TypeThen TypeAfter(bthen, x, rst(bthen))
10: Block belse block-else(block, i)
11: Type TypeElse TypeAfter(belse, x, rst(belse))
12: if i = line(cond(bif )) then . La ligne i est la condition du if
13: if 6= then
Type(block, x, line(cond(bif )))
14: return Type(block, x, line(cond(bif )))
15: if TypeThen = & TypeElse = then . x n'est pas utilis dans then ni else
16: return TypeAfter(block, x, last(belse)+1)
17: return TypeThen TypeElse . renvoi de l'union des types des 2 branches sinon
18: else if i < last(bthen) then . La ligne i est dans le bloc then
19: if ( thenTypeThen = ) . et le bloc then n'utilise pas x
20: return TypeAfter(block, x, last(belse)+1) . recherche du type aprs la condition
21: else
22: return TypeThen
23: else . La ligne i est dans le bloc else
24: if TypeElse = then
25: return TypeAfter(block, x, last(belse)+1)
26: else
27: return TypeElse
28:
29: return TypeAfter(block, x, i+1) . On dlgue le typage la ligne suivante

Algorithme 4 Fonction LineTypeAfter pour les conditions

1: function LineTypeAfter(bloc, x, i)
2: if i= last(block) | TypeAfter(block, x, i) = write then . Fin de bloc ou criture de x
3: return -1
4: Block bif block-if(block, i)
5: . La variable est utilise cette ligne et on n'est pas dans un bloc if
6: if Type(block, x, i) 6= and bif = NULL then
7: return i
8:
9: if bif 6= NULL then . La ligne est dans un bloc if

10: Block bthen block-then(block, i)
11: Type TypeThen TypeAfter(bthen, x, rst(bthen))
12: int lta-then LineTypeAfter(bthen, x, rst(bthen))
13: Block belse block-else(block, i)
14: Type TypeElse TypeAfter(belse, x, rst(belse))
15: int lta-else LineTypeAfter(belse, x, rst(else))
16:
17: if i = line(cond(bif )) then . La ligne i est la condition du if

18: if Type(block, x, line(cond(bif ))) 6= then
19: return i
20: if TypeThen = & TypeElse = then . x n'est pas utilis dans then ni else
21: return LineTypeAfter(block, x, last(belse)+1)
22: . sinon, x est utilis au moins d'un ct en lecture, on "factorise" l'attaque
23: return rst(bif )
24:
25: else if i < last(bthen) then . La ligne i est dans le bloc then
26: if TypeThen = then . et le bloc then n'utilise pas x
27: return LineTypeAfter(block, x, last(belse)+1) . on dlgue la suite
28: else if lta-then i then
29: return line(cond) . On peut factoriser
30: else . x est utilis au dessus : on ne peut pas factoriser
31: return LineTypeAfter(bthen, x, i)
32:
33: else . La ligne i est dans le bloc else

34: if TypeElse = then
35: return LineTypeAfter(block, x, last(belse)+1)
36: else if lta-else i then
37: return line(cond)
38: else
39: return LineTypeAfter(belse, x, i)
40:
41: return LineTypeAfter(block, x, i+1) . On dlgue le typage la ligne suivante

2. Si l'opration write est trouve dans, par exemple, le bloc thenblock, les consquences
d'une attaque peuvent tre annules par ce write ou bien tre propages par le bloc else
block. Dans ce dernier cas, cette attaque est considre tre couverte par des attaques
injectes aprs le bloc if .

Deux oprations read peuvent se produire dans les blocs thenblock et else block. Pour
couvrir toutes les attaques ayant un impact sur ces lectures, au lieu d'injecter une attaque dans
chacun des blocs, nous pouvons injecter une attaque avant le dbut du bloc if si aucune opration
sur x n'est ralise entre la condition du if et ces deux lectures. Dans les autres cas, l'endroit
o l'attaque doit tre injecte est la ligne o la lecture est faite. Avec un tel raisonnement, nous
pouvons rednir la fonction LineT ypeAf ter(code, x, i) lorsqu'un if est mis en jeu.
Dnition 21 La fonction LineT ypeAf ter(code, x, i), note aussi LT A(code, x, i), est dnie
par l'algorithme 4.
An d'illustrer la fonction LineT ypeAf ter, nous montrons dans les listings 4.11 4.18 les
dirents cas de gure tudis. Nous nous intressons au placement des attaques en fonction de
l'instruction if. Il faut examiner principalement deux cas : si l'attaque est place avant ou dans
l'un des blocs then/ else . Pour chacun de ces cas, on considre toutes les utilisations possibles
de la variable cible x.
1. L'attaque a lieu avant la condition. Il faut remarquer que l'eet de cette attaque est
le mme que si l'attaque a lieu sur la condition.
La condition n'utilise pas la variable : elle est alors transparente pour le calcul de
LineT ypeAf ter.
Listing 4.11 i en dehors de la condition x non utilis
i 1
... 2
if ( ... ) 3
{ 4
... 5
} 6
else 7
{ 8
... 9
} 10
LTA = LTA(11) 11
La variable est utilise dans la condition. On peut placer l'attaque juste avant le if ;
cette classe couvre aussi d'autres cas d'attaque dcrits ci-aprs.
Listing 4.12 i en dehors de la condition x dans condition
i 1
... 2
LTA = 3 + 1
2
3
if ( ..x.. ) 4
{ 5
... 6
} 7
else 8
{ 9
... 10
} 11
La variable est utilise dans le bloc then (symtriquement, dans le bloc else ). On peut
remonter cette attaque avant la condition, ce qui revient alors au cas prcdent. Cette
attaque n'a pas d'inuence sur la partie else ; la dplacer est donc lgitime.
Listing 4.13 i en dehors de la condition x dans then
i 1
... 2
LTA = 3 + 1
2
3
if ( ... ) 4
{ 5
..x.. 6
} 7
else 8
{ 9
... 10
} 11
La variable est utilise dans les deux blocs. On la factorise.
Listing 4.14 i en dehors de la condition x dans then et else
i 1
... 2
LTA = 3 + 1
2
3
if ( ... ) 4
{ 5
..x.. 6
} 7
else 8
{ 9
..x.. 10
} 11
2. L'attaque a lieu dans la condition. On place l'attaque dans le bloc then, mais celle-ci
peut tre faite de manire symtrique dans le bloc else . Ce qui se passe dans le bloc else
n'a pas d'importance pour ces attaques.
La variable n'est pas utilise dans le bloc. On peut dlguer le placement de l'attaque
aprs le if.
Listing 4.15 i dans then x non utilis dans then
if ( ... ) 1
{ 2
i 3
... 4
} 5
else 6
{ 7
..x.. 8
} 9
LTA = LTA(10) 10
La variable est utilise avant et aprs l'attaque dans le bloc. On ne pas factoriser l'at-
taque ; cela revient au cas du code linaire.
Listing 4.16 i dans then x utilis dans then avant et aprs i

if ( ... ) 1
{ 2
..x.. 3
i 4
..x.. LTA = 5 + 1
2
5
} 6
else 7
{ 8
..x.. 9
} 10
La variable est utilise dans le bloc, aprs l'attaque, et il n'y a pas d'autre utilisation
avant dans ce bloc. On peut remonter cette attaque avant la condition.
Listing 4.17 i dans then x utilis dans then aprs i
LTA = 1 + 1
2
1
if ( ... ) 2
{ 3
i 4
..x.. 5
} 6
else 7
{ 8
..x.. 9
} 10
La variable n'est pas utilise aprs l'attaque dans le bloc. Ce cas revient au cas o la
variable n'est pas utilise dans le bloc (listing 4.15).
Listing 4.18 i dans then x utilis dans then avant i

if ( ... ) 1
{ 2
..x.. 3
i 4
} 5
else 6
{ 7
..x.. 8
} 9
LTA = LTA(10) 10
Comme les attaques peuvent couvrir d'autres attaques, il faut adapter le lemme 3 qui exprime
la couverture plutt que l'quivalence de deux attaques qui ciblent une ligne dont le T ypeAf ter
est read ou rw :
Lemme 5 Si T ypeAf ter(codef , x, i) {read, rw} alors
Attack(codef , i, x) C Attack(codef , LineT ypeAf ter(codef , x, i), x).
Preuve: Aprs la ligne i, la prochaine opration concernant x est de type read. Si la ligne
dterminant le type n'est pas dans un if, on revient au raisonnement du lemme 3. La o les
lignes dnissant ce type peuvent tre plusieurs endroits : dans la condition, dans le bloc
thenblock, dans le block else block, ou dans les deux. Plusieurs cas sont distinguer :
ce type n'est dni que par une seule ligne j :
de la condition du if : LT A renvoie cette ligne et toute attaque dans l'intervalle [i, j]
a les mmes consquences qu'une attaque eectue juste avant la condition du if (lis-
ting 4.12).
du bloc thenblock ou else block : LT A renvoie :
la ligne dnissant le type (i est encadr par deux utilisations de x, comme montr
dans le listing 4.16) : si la condition du if est vraie, l'attaque est couverte par la classe
o l'injection a lieu juste avant la ligne j, ou sinon l'attaque est inoprante et donc
couverte par la classe codef .
la ligne de la condition : dans ce cas, il n'y a pas d'utilisation de x entre la condition et
j (listing 4.17). Attaquer en ligne i est couvert par l'attaque eectue sur la condition.
En eet, si la condition est vraie, l'attaque est encore active la ligne i et donc la
ligne j; si la condition est fausse l'attaque est inoprante. Dans ce cas, l'attaque sur
la condition couvre bien l'attaque en ligne i.
ce type est dni par deux types read ou rw en lignes j et j0 : dans ce cas, la ligne
i considre est forcment avant le if et la ligne retourne par LT A est la ligne de la
condition. Comme il y a deux lectures dans les blocs du if, on peut factoriser l'attaque
la ligne de la condition et donc couvrir toute attaque de [f irst(block then), j] ou
[f irst(block else), j 0 ] par une attaque en ligne line(cond). Ce cas est illustr par le
listing 4.14.
Ainsi, tous ces codes attaqus sont couverts par un seul et mme code attaqu en positionnant
le point d'attaque la ligne LineT ypeAf ter(codef , x, i).
A des ns d'illustration du cas du if, un code d'exemple avec les valeurs de T ypeAf ter (TA)
et de LineT ypeAf ter (LTA) est donn dans la table 4.2. Cet exemple montre la factorisation
de la premire lecture dex dans les deux branches de la condition. Pour les autres cas, la valeur
de LT A est le numro de la ligne o une lecture est eectue. Pour la variable x, on s'aperoit
que LT A prend les deux valeurs 3 et 6 ce qui permet de dnir deux classes de couverture pour
l'ensemble des attaques contre x.
Boucles
Dans cette partie, nous modlisons la gestion des boucles. Seules les boucles while sont
traites puisque les autres types de boucles peuvent tre rcrites avec un while. Les listings 4.19
4.25 illustrent les cas distinguer quand un code contient une boucle. Ils montrent en particulier
L Code TA(x) LTA(x) TA(y) LTA(y) TA(z) LTA(z)
1 word f() r 3 r 3 rw 3
2 { r 3 r 3 rw 3
3 if (y == 0) { r 3 r 3 rw 3
4 y = 48 ; r 3 w -1 rw 3
5 y = x; r 3 w -1 rw 3
6 z = x + z; r 6 -1 rw 3
7 } else { r 3 w -1 -1
8 y = x + 1; r 3 w -1 -1
9 } -1 -1 -1
10 } -1 -1 -1
Table 4.2 Exemple de valeurs pour la fonction LineT ypeAf ter avec une condition
les lignes o les attaques doivent tre injectes pour couvrir tous les cas d'attaque possibles. Nous
distinguons deux zones d'attaque pouvant avoir une inuence sur les instructions contenues dans
une boucle : avant la boucle ou l'intrieur de la boucle. Nous dtaillons les cas possibles dans
chacune des congurations.
1. Avant la boucle :
Listing 4.19 : la boucle n'utilise pas la variable x considre ; elle est donc transparente
pour les attaques. Les attaques dans ce cas seront couvertes par les attaques eectues
aprs la boucle.
Listing 4.19 i en dehors de la boucle x non utilis
i 1
... 2
while ( ... ) 3
{ 4
... 5
} 6
LTA = LTA(7) 7
Listing 4.20 : la boucle utilise la variable x au niveau de la condition. L'impact de

l'attaque a lieu au moins sur la premire valuation de la condition et ventuellement
sur les autres si x n'est pas modi dans le corps du while. Cette attaque est couverte
par l'attaque sur la ligne de la condition.
Listing 4.20 i en dehors de la boucle x utilis dans la condition
i 1
... 2
LTA = 3 + 1
2
3
while ( ... x ... )// dfinit le type 4
{ 5
... 6
} 7
Listing 4.21 : la boucle utilise la variable au sein de la boucle. Une attaque l'intrieur
de la boucle n'est pas quivalente parce qu'elle est rpte chaque tour de boucle.
On peut donc, comme dans le listing 4.20, placer cette attaque avant la condition de la
boucle.
Listing 4.21 i en dehors de la boucle x utilis dans la boucle
i 1
... 2
LTA = 3 + 21 3
while ( ... ) 4
{ 5
... x ... // dfinit le type 6
} 7
2. A l'intrieur de la boucle :
Listing 4.22 : la boucle utilise la variable et l'attaque a lieu avant l'utilisation de celle-ci.
L'impact de cette attaque a lieu chaque tour de boucle au niveau de l'utilisation de la
variable. Cette attaque est donc quivalente celle eectue sur la ligne d'utilisation de
la variable ; elle est par consquent couverte par cette dernire.
Listing 4.22 i dans la boucle x utilis dans la boucle aprs i

while ( ... ) 1
{ 2
... 3
i 4
... 5
LTA = 6 + 1
2
6
x 7
... 8
} 9
Listing 4.23 : la boucle utilise la variable et l'attaque a lieu aprs la dernire utilisation
de celle-ci. L'impact de cette attaque a lieu chaque tour de boucle, mais seulement
partir de la deuxime. Elle peut ne pas avoir d'impact si la condition s'avre fausse.
Cette attaque est donc quivalente celle eectue en n de la boucle.
Listing 4.23 i dans la boucle x utilis dans la boucle avant i

while ( ... ) 1
{ 2
... 3
x 4
... 5
i 6
... 7
LTA = 8 + 1
2
8
} 9
Listing 4.24 : la boucle utilise la variable dans la condition et l'attaque a lieu dans le
corps de la boucle. Cette attaque est eective partir de la deuxime valuation de la
condition. La aussi, cette attaque est couverte par l'attaque eectue en n de boucle.
Listing 4.24 i dans la boucle x utilis dans la condition
while ( ... x ... ) 1

{ 2
... 3
i 4
... 5
LTA = 6 + 21 6
} 7
Listing 4.25 : la boucle n'utilise pas la variable. Dans ce cas, l'attaque dans le corps de
la boucle n'a pas d'eet tant que l'on est dans la boucle. Elle est donc quivalente une
attaque eectue juste aprs la boucle.
Listing 4.25 i dans la boucle x non utilis
while ( ... ) 1
{ 2
... 3
i 4
... 5
} 6
LTA = LTA(7) 7
A partir de cette tude, les dnitions des fonctions T ypeAf ter et LineT ypeAf ter peuvent
tre adaptes la problmatique des boucles. Pour cela, la ligne 28 de l'algorithme 3 doit
tre remplace par l'algorithme 5. Pour rcrire une nouvelle fois le thorme, les lemmes 2
et 3 doivent rester valides. De manire similaire au cas de la condition, on dnit de nouvelles
fonctions :
block while(block , i ) retourne le bloc while, sans sa condition, si une instruction while
est situe la ligne numrote i ou si i appartient ce bloc. Dans le cas inverse, la fonction
retourne NULL ;
La fonction cond est tendue pour prendre en compte la condition des boucles.
Lemme 6 Avec cette modication de la dnition de T ypeAf ter, le lemme 2 reste valide.
Preuve: Comme la condition est value aprs chaque partie interne d'un bloc while, toute
attaque la ligne i l'intrieur d'un tel while peut toucher deux parties distinctes du code :
premirement, la partie juste aprs la ligne i, et deuximement la partie partir de la condition
Algorithme 5 Code ajouter la dnition de TypeAfter

Partie insrer aprs la ligne 28 de l'algorithme 3
1: Block bwhile block-while(block, i)
2: if bwhile 6= NULL then . La ligne i est dans une boucle Type
3: TypeEndLoop TypeAfter(bwhile, x, i)
4: if TypeEndLoop 6= then .x est utilise dans la boucle aprs i
5: return TypeEndLoop
6: Type TypeCondLoop Type(bwhile, x, line(cond(bwhile)))
7: if TypeCondLoop 6= then .x est utilise dans la condition
8: return TypeCondLoop
9: Type TypeBeginLoop TypeAfter(bwhile, x, rst(bwhile)+1)
10: if TypeBeginLoop 6= then . x est utilise partir du dbut de la boucle
11: return TypeBeginLoop
12: return TypeAfter(block, x, last(bwhile)+1)
du while jusqu' la ligne i.T A retourne , toute attaque n'a pas d'impact sur le
Si la fonction
reste du code. Si la fonction T A retourne write, une attaque est annule par l'opration write
dans la premire partie de la boucle ou aprs le while.
Finalement, la dnition de LineT ypeAf ter doit prendre en compte de la mme manire les
boucles comme montr au listing 6. Il faut alors vrier que le lemme 5 est toujours valide.
Avec cette nouvelle dnition de la fonction LineT ypeAf ter, il faut vrier que le lemme 5
est toujours valide pour prendre en compte la situation particulire des boucles.
Lemme 7 Avec cette modication de la dnition de LineT ypeAf ter, le lemme 5 reste valide.
Preuve: Comme pour le lemme prcdent, il faut s'attarder sur le cas des boucles. Plusieurs
congurations peuvent se produire pour lesquelles le type de la prochaine utilisation est une
lecture.
La prochaine utilisation est dans une condition de boucle. Deux cas peuvent se
produire :
La ligne i que l'on considre est avant la dnition de la boucle. Cela revient au cas des
conditions tudies prcdemment. La fonction LineT ypeAf ter retourne alors la ligne
de la condition de la boucle. Cette ligne est retourne par LineT ypeAf ter dans ce cas
par la ligne 5 de l'algorithme.
La ligne i est situe dans le bloc while. Dans ce cas, la condition est value avant de
faire (ou pas) l'valuation du bloc. Positionner l'attaque la n du bloc while permet
que celle-ci soit eective lors de la prochaine valuation de la condition (ligne 17 de
l'algorithme).
La prochaine utilisation est en lecture et est l'intrieur du bloc while en
dehors de la condition. nouveau deux cas sont considrer :
i est l'extrieur de la boucle, place avant. Dans ce cas, on ne peut pas mettre une
attaque l'intrieur de la boucle, car celle-ci est excute chaque itration. La fonction
LineT ypeAf ter retourne la ligne de la condition de boucle (ligne 9 de l'algorithme) et
cette attaque est couverte par celle o on attaque la ligne de la condition de la boucle.
Algorithme 6 Modications apporter LineTypeAfter prenant en compte les boucles

Partie insrer aprs la ligne 40 de l'algorithme LineTypeAfter
1: Block bwhile block-while(block, i)
2: if bwhile 6= NULL then . i est dans une boucle
3: Type TypeCondLoop Type(bwhile, x, line(cond(bwhile))) . i conditionne le while
4: if TypeCondLoop 6= & i = line(cond(bwhile)) then . et la condition est type
5: return i
6: if TypeCondLoop = & i = line(cond(bwhile)) then . i conditionne le bloc while
7: Type TypeEndLoop TypeAfter(bwhile, x, i) . et la condition est non type
8: if TypeEndLoop 6= then . on regarde si x est utilise dans le corps de la boucle
9: return i
10: else
11: return LineTypeAfter(bwhile, x, last(bwhile)+1)
12: Type TypeEndLoop TypeAfter(bwhile, x, i) . On est l'intrieur d'un bloc while
13: if TypeEndLoop 6= then . La variable est utilise entre la ligne i et la n de la boucle
14: return LineTypeAfter(bwhile, x, i)
15: Type TypeBeginLoop TypeAfter(bwhile, x, rst(bwhile)) .x utilis dans le bloc ?
16: if TypeBeginLoop 6 then
=
17: return last(bwhile)
18: return LineTypeAfter(block, x, last(bwhile)+1)
i est l'intrieur de la boucle avant l'utilisation de x. Dans ce cas, l'attaque a lieu

chaque tour de boucle. L'eet de l'attaque la ligne i est le mme que l'attaque la
ligne de LineT ypeAf ter(bwhile, i, x). Cela revient au cas du code linaire (ligne 14 de
l'algorithme).
i est l'intrieur de la boucle aprs l'utilisation de x. Dans ce cas, l'attaque a lieu
partir du deuxime tour de boucle. On peut placer l'attaque en n de boucle (ligne 17
de l'algorithme).
Il n'y a pas d'utilisation de la variable x jusqu' la n du bloc. Le type est dni
aprs le bloc while (ligne 18 de l'algorithme).
En conclusion, chacune des attaques sur la ligne i est couverte par l'attaque dnie par la
fonction LineT ypeAf ter(bloc, i, x).
Synthse des codes attaqus considrer

La section prcdente a propos les dnitions des deux fonctions T ypeAf ter (T A) et
LineT ypeAf ter (LT A) qui permettent de diviser le code d'une fonction en zones o les at-
taques sont couvertes par une attaque injecte aux numros de lignes dnis par la fonction
LineT ypeAf ter. Ainsi, pour simuler toutes les attaques possibles, il n'y a besoin que ne consi-
drer que les codes attaqus aux lignes dnies par LineT ypeAf ter.
Thorme 3 L'ensemble rduit de codes attaqus qui couvre toutes les attaques possibles contre
la variable x est le code initial codef , plus les codes attaqus o l'attaque est injecte aux numros
de lignes dnis par la fonction LineT ypeAf ter, c'est--dire :
[
codef Attack(codef , LineT ypeAf ter(codef , x, i), x)
i|program|
Preuve: A l'aide de l'ensemble des 6 lemmes prcdents, nous avons dmontr que toute attaque
en ligne j est soit inoprante, soit couverte par l'attaque dnie par la fonction LineT ypeAf ter
en ligne LineT ypeAf ter(codef , x, j).
L'ensemble des codes considrer est donc dni par les valeurs renvoyes par LT A plus le
code original.
4.3.5 Exprimentations
La rduction propose en section 4.3 a t implmente dans un prototype cod en Java. Ce
prototype prend un chier C et dtecte automatiquement toutes les variables utilises. Puis, il
recherche toutes les oprations de lecture de ces variables et calcule les lignes correspondant
la fonction LT A qui doit recevoir l'attaque. Pour chaque ligne d'attaque, le prototype gnre
un nouveau code C. Pour l'exemple du listing 4.1 et la variable x, pin_input et res, il cr les
chiers du listing 4.26.
Listing 4.26 Fichiers crs par le prototyle
/ home / j f / smart_card / p i n _ i n p u t / a t t a c k _ l i n e _ 2 1 . c 1
/ home / j f / smart_card / x / a t t a c k _ l i n e _ 1 1 . c 2
/ home / j f / smart_card / x / a t t a c k _ l i n e _ 1 2 . c 3
. . . ( et a i n s i de s u i t e pour number1 , number2 . . . ) 4
Dans la suite de cette section, nous montrons l'eet de notre rduction par couverture d'at-
taques pour le listing 4.1. Il y a trois variables considrer : pin_input, x et res. Sans la rduction
propose par le thorme 3, le nombre de codes gnrer est grossirement le nombre de va-
riables multipli par le nombre de lignes de la fonction considre, c'est--dire 6 (x peut tre
attaqu dans work() sur 6 lignes) + 2 5 (res et pin_input dans banking()) = 16 codes gnrer.
Rduction pour pin_input

Si l'on applique la rduction la variable pin_input, la ligne 22 est tague avec read par
la fonction T A. Donc, pour l'injection de l'attaque, seule la ligne 22 est considre car T A(i
[17..21]) = write, T A(i 23) = , T A(i [7..14]) = ). Ainsi, appliquer la rduction pour
pin_input n'introduit qu'une attaque en ligne 22.
Rduction pour x
Si l'on applique la rduction pour la variable x, les lignes 10 et 11 sont tagues par rw par la
fonction TA et la ligne 12 est tague avec read. Pour l'injection des attaques, deux lignes sont
concernes car i [10..11], LT A(i) = 11 et pour i = 12, LT A(i) = 12 (de manire similaire
pin_input les autres lignes ont le type ou write). Ainsi, appliquer la rduction pour x introduit
deux attaques en ligne 11 et 12.
Rduction pour res

Dans cet exemple, res n'est jamais lu et aucune attaque ne peut avoir d'eet sur lui. Il
s'agit clairement d'un exemple pdagogique car res n'est jamais utilis. En pratique il est test,
retourn ou envoy en tant que paramtre dans un appel de fonction. Dans ces cas, res est
impliqu dans une lecture et donc une possible attaque.
Rsultat de la rduction
En conclusion, appliquer notre mthodologie pin_input, x et res rduit le nombre d'attaque
3, au lieu de 16 initialement : une attaque contre pin_input en ligne 22 ; deux attaques contre
x en lignes 11 et 12 ; aucune attaque possible contre res.
4.4 Conclusion
Dans ce chapitre, nous avons prsent une mthodologie pour vrier des proprits de s-
curit exprimes en acsl. Bien qu'il manque la projection des proprits du chapitre 3 vers le
langage acsl, ce qui, en soit, n'est pas trivial, nous avons montr que des proprits simples
telles que l'appartenance un intervalle pour une variable donne, peuvent tre vries l'aide
d'un outil d'analyse statique. Dans les cas o la proprit est dicile vrier par manque
d'information, nous avons propos une mthode dynamique permettant d'infrer celles-ci par-
tir de l'excution du programme. Cette mthode permet de combler ecacement ce manque
d'information qui bloquerait l'analyse statique. Les problmes lies aux variables globales et les
appels de fonctions externes sont ainsi rsolues.
Ce chapitre a aussi montr comment le modle d'attaque peut-tre exploit en combinaison

avec l'outil d'analyse statique. Nous avons prcisment montr comment gnrer des codes sous
attaques physiques l'aide du modle d'attaque en provoquant la modication de variables.
Ces codes reprsentent les points d'attaque possibles de l'attaquant. Mme si le nombre de ces
attaques reste polynomial avec la taille du code, le nombre de codes attaqus gnrs est trs
grand et ncessite de s'intresser la rduction de ce nombre an de minimiser les vrications
eectuer. La n de ce chapitre est ainsi all plus loin que l'amlioration du nombre de codes sous
attaque : il a prouv l'optimalit du nombre de codes gnrs, mme pour des codes complexes
comprenant des structures de contrle typiques pour un code C. Un nombre minimum de points
d'attaque a donc t trouv permettant de maximiser l'eet de celles-ci. Les positions ainsi
trouves peuvent tre utilises pour minimiser le nombre d'attaques ncessaires permettant de
couvrir l'ensemble des attaques par valeurs possibles. Ainsi, une stratgie de test de scurit
peut tre tablie.
Enn, les dicults relatives l'utilisation d'un outil d'analyse statique demeurent. Les poin-
teurs, les tableaux, peuvent rendre la vrication de proprits dicile. Ces dicults s'loignent
du cadre de cette thse, mais les contributions prsentes sont indpendantes de ces dicults.
Ainsi, la mthode propose peut tre utilise avec d'autres outils d'analyse statique ou tirer
partie des prochaines avances dans ce domaine.
Un autre point important est de russir travailler sur le code rel de la carte puce avec de
tels outils. Pour russir analyser de tels codes, il faut russir adapter le code pour le rendre
compatible avec l'analyseur statique. Ce processus, compltement manuel, peut prendre plu-
sieurs semaines en fonction de la taille du code initial, de ses spcicits et de la chaine de

compilation utilise. Ce processus doit tre ritr si le code source volue de manire cons-
quente. Cependant, l'investissement devient rentable car une fois la proprit de scurit voulue
vrie, on peut alors exhaustivement tester des attaques et vrier si la proprit reste valide.
Si une grande partie du code est rutilise de projets projets, en portant une base commune
sur les direntes nouvelles architectures de composant, seul l'eort initial est important. Cepen-
dant, le rel investissement se trouve dans la dnition, l'criture et le maintien des annotations
exprimant les garanties souhaites sur le code source. Annoter l'intgralit du code source d'un
projet de 100 000 LOC n'est pas envisageable sans des ressources ddies cette tche. Cepen-
dant, tant donn que l'intgralit du code source ne remplit pas les mmes objectifs en terme
de scurit, ces annotations peuvent tre mises en place uniquement dans les parties de code
sensibles ce qui mitige l'eort fournir.
4.5 Perspectives
Gnration automatique de cas de tests pertinents
La mthode propose ici consiste dlguer la dtermination de ces informations une
mthode dynamique. Les scnarii intressants doivent cependant tre dtermines manuelle-
ment. Des mthodes d'analyse statiques bases sur la smantique et l'interprtation abstraite
permettent cependant d'laborer des cas de test permettant de stimuler une portion spcique
de code dans un projet [Nori et al. 2009]. Intgrer une telle mthode permettrait de rduire la
recherche des vecteurs d'entrs ncessaires. La mthode devrait cependant tre modie an
d'tre applique dans un contexte de scurit. Les scnarii qui avantagent l'attaquant devront
tre distingus de ceux qui ne l'avantagent pas.
Gnration automatique de substituts

Des portions de code en assembleur peuvent aussi freiner un analyseur statique. Crer des
substituts en C pour ces portions de code et les utiliser lors d'une analyse peut augmenter
l'ecacit et la prcision de celles-ci. Russir crer ecacement ces substituts est une perspec-
tive intressante. L'approche utilise par [Cifuentes & Gough 1995] pourrait servir de base la
cration de ces substituts.
Diminution du champ d'valuation

Un facteur d'chelle intervient aussi lors de l'analyse de programme de grande taille. Russir
diminuer le champ considr lors d'une analyse est un facteur cl pour assurer la vrication de
scurit de l'ensemble d'un systme. L'approche adopte par [Monate & Signoles 2008] pourrait
servir de base une telle rduction.
Identication des points vulnrables du systme

Une contrainte consiste aussi isoler les parties du programme qui reprsentent un danger
d'un point de vue fonctionnel si elles sont soumises des attaques physiques. Dans le cha-
pitre 5 propose une mthode permettant d'identier ces points de vulnrabilit l'chelle d'un
programme.
Chapitre 5
Test de scurit et caractrisation

visuelle de programme sous attaques
physiques simules
Sommaire
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.2 Mthodologie de test propose . . . . . . . . . . . . . . . . . . . . . . 143
5.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.2.2 Mthode de classication des rsultats . . . . . . . . . . . . . . . . . . . 146
5.3 Exprimentations et analyse scuritaire . . . . . . . . . . . . . . . . . 148
5.3.1 Plate-forme exprimentale . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.3.2 Exemple sur bzip2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.3.3 Exemple sur gzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.3.4 Couverture assembleur par le modle C . . . . . . . . . . . . . . . . . . 157
5.4 Analyse des rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
5.4.1 Distribution des attaques par taille du saut . . . . . . . . . . . . . . . . 160
5.4.2 Analyse visuelle des fonctions vulnrables . . . . . . . . . . . . . . . . . 161
5.4.3 Implmentation de contre-mesures . . . . . . . . . . . . . . . . . . . . . 163
5.5 Rsultats exprimentaux sur code de carte puce . . . . . . . . . . 164
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.7 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
5.1 Introduction
Dans ce chapitre, nous introduisons une contribution mthodologique permettant de tester
si les scurits mises en place dans un code source sont capables de rsister des attaques
physiques. Nous donnons les rsultats exprimentaux de cette mthode dploye l'chelle d'un
projet de carte puce d'Oberthur Technologies.
Une approche possible pour dterminer si une attaque russit consiste numrer exhausti-
vement toutes les attaques possibles, puis d'analyser l'impact de chacune d'elles sur l'excution
du programme, an de pouvoir discerner celles qui ont russi des autres. tant donn que les
consquences des attaques physiques peuvent tre expliques au niveau assembleur, une telle ap-
proche doit a priori tre eectue ce niveau. Ainsi, en tudiant les consquences des attaques
au niveau assembleur, on peut tablir un modle d'attaque ce niveau (par une modication ou
insertion de code simulant l'eet de l'attaque). On peut ainsi dcouvrir de nouvelles attaques
142 Chapitre 5. Test de scurit et visualisation
C ASM
Code source Assembleur 8051 Binaire Carte puce
Simulation
dattaques physiques
C ASM
Attaques physiques
Comment reproduire Comment expliquer
Simulateur
les attaques dans le code ? les attaques ?
Tests de scurit Tests de scurit

haut niveau bas niveau
Figure 5.1 Schma de la mthodologie adopte pour l'analyse scuritaire
susceptibles de russir : soit en excutant la version attaque du code et en comparant le com-

portement obtenu au comportement attendu dans un scnario sans attaque, soit en analysant
statiquement la version attaque du code et en prouvant des proprits de scurit. Cependant
avec cette mthode, une fois qu'une attaque a t identie comme potentiellement dangereuse,
ses consquences sur le code assembleur doivent encore tre relies au code source original au
niveau C, an d'implmenter une contre-mesure. Cette tche est particulirement dicile. En
eet, il n'est pas vident de dcompiler du code assembleur an de retrouver le code source
original. De plus, la russite de cette dcompilation dpend en grande partie du compilateur et
du niveau d'optimisation utilis au moment de la gnration du binaire.
C'est donc pourquoi, en utilisant le modle d'attaque haut niveau prsent en chapitre 3,
nous proposons d'exploiter le modle de haut niveau an d'tudier l'impact de chaque attaque
sur l'excution du programme. Le fait d'utiliser un modle d'attaque haut niveau est symbolis
dans la gure 5.1 par la che de gauche en pointills. Compar un cycle qui incorpore des
attaques simules ou encore des attaques sur cible matrielle, cette mthode permet d'obtenir
plus rapidement des rsultats en raccourcissant la prise en compte des attaques l'intrieur
du cycle de dveloppement. Le dveloppeur peut ainsi savoir au niveau du code source qu'il
dveloppe si des attaques physiques sont susceptibles de compromettre son implmentation.
Nous utilisons donc le modle d'attaque tabli en chapitre 3 an de raliser la simulation des
attaques dans le code source C. Nous nous intressons particulirement aux attaques aectant
le contrle de ot du programme. Dans la section 5.2, nous prsentons la mthodologie propose
qui utilise des simulations d'attaques sur le contrle de ot au niveau C an d'identier des
attaques dangereuses qui sont susceptibles de compromettre la scurit du programme. Cette
mthodologie permet au dveloppeur de faire une analyse pousse de l'ensemble des impacts
possibles d'attaques physiques son code. Nous prsentons les rsultats exprimentaux d'une telle
analyse en section 5.3. Aucune exprimentation n'est donc ncessaire au niveau assembleur. Nous
nous servons des programmes de compression bzip2 et gzip, dont le comportement symbolise
celui d'une carte puce, pour montrer comment la mthodologie propose permet de caractriser
des programmes soumis des attaques physiques. An de montrer le rendement de la mthode
propose, i.e., la couverture des attaques possibles bas niveau par celles simules haut niveau,
5.2. Mthodologie de test propose 143
C ASM
Code source original Assembleur Dbogage gdb

injection dattaques
(1) Simulation
dattaques physiques
Classification
Attacked Source code Attacked Assembly
Attacked Source code Attacked Assembly
Code source attaqu Assembleur attaqu
Campagne de tests
(3)
(2)
Implmentation
Visualisation
de contre mesure
Figure 5.2 Vue d'ensemble de la plate-forme exprimentale
une sous section 5.3.4 est ddie la comparaison des comportements du systme obtenus suite
injection d'attaques sur le contrle de ot au niveau C avec ceux obtenus au niveau assembleur.
La section 5.4 analyse les rsultats obtenus grce la mthode propose et montre comment ces
rsultats peuvent tre utiliss par le dveloppeur pour amliorer la scurit de son code. Cette
section montre galement comment la mthodologie permet d'valuer l'ecacit d'une contre-
mesure. Finalement, la section 5.5 conclut en proposant des rsultats concrets obtenus sur le
code d'une vrai carte puce. Les contributions couvertes dans ce chapitre font rfrence la
publication [Berthom et al. 2012].
5.2 Mthodologie de test propose

Le chapitre 3 a identi comment il est possible de modliser les attaques sur le contrle
de ot au niveau du code source. Cette section dcrit la mthodologie de test que nous propo-
sons reprsente dans la gure 5.2 par des ches pleines. Les ches en pointill de la gure
reprsentent la validation exprimentale de cette proposition.
5.2.1 Principe
Le principe de la mthodologie propose, consistant attaquer fonctionnellement un pro-
gramme de manire exhaustive, est proche de celle prsente dans [Srivatanakul et al. 2005]. Ce
principe, utilis notamment en scurit dans les tests d'intrusion, vise tester les systmes en
les soumettant des attaques varies. La prsence d'une faille est suppose dans le systme, le
but est de la mettre en vidence par ces attaques. Cette mthodologie cible l'implmentation de
fonctionnalits mais aussi les spcications de celles-ci, permettant de chercher des failles aussi
bien dans l'une que dans les autres. Concrtement, la mthode employe consiste stimuler des
points d'attaques et observer la raction du systme. Cette technique est notamment utilise
dans le domaine de l'injection de faute par l'ajout de saboteurs qui perturbent le systme lors
de son excution [Grinschgl et al. 2011].
Notre mthodologie de test propose d'utiliser les attaques par saut du modle d'attaque par
goto an de tester exhaustivement le code source d'un scnario fonctionnel soumis l'ensemble
des attaques de contrle de ot possibles. Un scnario fonctionnel est une suite de commandes
envoyes la carte an de dclencher des actions au sein de celle-ci. Ces actions ont pour but
de remplir une ou plusieurs tches qui sont les objectifs fonctionnels du scnario. Gnralement,
pour chaque fonctionnalit dcrite dans les spcications fonctionnelles du produit, il existe un
scnario fonctionnel permettant de stimuler cette fonctionnalit implmente au travers d'un
test fonctionnel. Pour un Verify Pin, il existe dj des tests fonctionnels qui, par exemple,
simulent un scnario o l'utilisateur prsente un PIN correct (respectivement, incorrect) et vri-
ent que le jeton d'authentication renvoy est correct (respectivement incorrect). Des variantes
de ces scnarii existent dans les tests unitaires, les campagnes de tests fonctionnels ou les tests
de certication permettant d'valuer la correspondance de l'implmentation aux spcications
fonctionnelles. Les dveloppeurs responsables de l'implmentation auront gnralement cr de
tels tests. La technique d'injection d'attaque dans le code source du programme tant totalement
indpendante de la technique utilise pour eectuer les tests, elle s'applique donc quelle que soit
la mthodologie ou le niveau de test utilis. Tests unitaires, tests d'intgration ou tests de r-
gression retourneront des informations d'un niveau dirent mais incorporant l'eet d'attaques
physiques. Ainsi, un des avantages de cette mthode est qu'elle permet de rutiliser ces tests
fonctionnels en les drivant pour crer des tests de scurit. Pour cela, il sut de modier le test
pour faire apparatre un avantage possible pour l'attaquant vis--vis du test en question. Par
exemple, pour le Verify PIN, modier le PIN prsent par l'utilisateur par un PIN incorrect. Si
le test ainsi modi retourne le mme rsultat que le test non modi, l'attaquant a trouv un
moyen par une attaque physique d'entrer un PIN incorrect mais d'obtenir un jeton d'authenti-
cation correct. On peut remarquer que si les tests taient eectus sans changer les scnarii, on
testerait avec cette mthode la rsilience d'une excution par rapport des attaques.
Une fois la campagne de test d'attaques exhaustives eectue, nous proposons de classi-
er les rsultats obtenus an de direntier les attaques qui ont russi des autres. Les auteurs
de [Madeira et al. 2000] adoptent une classication similaire celle prsente ici mais dans un
contexte sans scurit et applique la dcouverte d'erreurs dans un programme. Les auteurs
catgorisent les comportements de 3 programmes crits en C face des injections de fautes mu-
les et crent un parallle avec l'origine logicielle de la faute. Les rsultats montrent que les outils
d'injection de fautes par mulation russissent simuler certaines erreurs haut niveau comme
les erreurs d'aectation, de logique, d'interface ou de partage de ressources. Cependant, certaines
d'entres elles comme les erreurs qualies d'algorithmiques ou de fonctionnelles se prtent mal
des simulation de bas niveau. Plus complexes, car ncessitant une modication extensive de haut
niveau pour tre apparentes, celles-ci ncessiteraient une intervention manuelle pour dnir et
dclencher prcisment l'erreur souhaite. Les auteurs citent [Christmansson & Chillarege 1996]
qui mentionne que ces erreurs non couvertes reprsentent 44 % des erreurs logicielles trouves lors
de leurs expriences. Ces chires renforcent l'intrt que reprsentent une solution logicielle pour
la dcouverte de nouvelles fautes dans l'implmentation. Les auteurs de [Madeira et al. 2000] pr-
sentent galement que des mtriques peuvent tre utilises comme moyen de guider l'injection
des fautes pour les rendre plus pertinentes et ecaces. Ces mtriques permettent de compenser
le manque de rsultats terrains qui peuvent normalement aider guider ces injections. Nous
prsenterons, dans la section 5.2.2, une utilisation dirente de telles mtriques non pas comme
guide mais comme un moyen de caractriser une attaque en synthtisant les formes de code
prsentes dans le code saut par l'attaque.
Dans la littrature, direntes autres approches ont t adoptes an de vrier la scurit
des codes embarqus contre les attaques physiques. Ces approches par modlisation ou simula-
tion font intervenir des niveaux d'abstraction dirents ainsi que des mthodes de vrication
direntes.
Une modlisation en SystemC d'une partie du systme au niveau matriel et l'introduction
d'attaques dans ces modles [Rothbart et al. 2004] ;
La cration d'une plate-forme d'injection de fautes pour les cartes s'inspirant des plates-
formes d'injection existant en suret de fonctionnement et permettant l'insertion d'at-
taques par dlai en prenant l'aes pour exemple [Faurax 2008] ;
Des simulateurs de composants ddis la modlisation des fuites d'informations sur les
algorithmes cryptographiques [Andouard 2009] [Agostini 2009] ;
Une plate-forme de cration de codes mutants en mmoire pour la vrication de proprits
de scurit sur des applications Java Card [Machemie et al. 2011].
Malheureusement, aucune de ces mthodes ne porte sur un systme C complet dans le cas
d'attaques par fautes. S'il est possible que certaines de ces mthodes passent l'chelle, elles ne
permettent pas d'obtenir un rsultat direct sur le code attaqu mais seulement sur un modle
de celui-ci dirents niveaux d'abstraction. Le dveloppeur qui doit introduire une contre-
mesure dans le code pour corriger une vulnrabilit trouve doit transcrire les rsultats obtenus
ce niveau d'abstraction au niveau du code source, ce qui demande un eort supplmentaire.
Finalement, une modlisation au niveau du composant, si elle a l'avantage d'tre plus dle, de-
mande une adaptation de celui-ci dans le cas d'une utilisation avec un composant aux spcicits
direntes.
La mthodologie propose a pour but de passer l'chelle au niveau d'un projet C complet.
Par rapport [Madeira et al. 2000], elle propose une granularit suprieure sur un jeu d'entre
restreint un scnario particulier intressant du point de vue de la scurit. L'objectif n'est pas
de mettre en vidence des erreurs logicielles par des tests mais de dcouvrir quelles attaques
logicielles entrant dans un modle d'attaque peuvent compromettre la scurit du systme. Les
rsultats prsents font donc apparatre l'chelle d'une fonction, pour toutes les fonctions
d'un programme, les eets d'une campagne exhaustive d'attaques par saut. Les rsultats in-
correct de [Madeira et al. 2000] sont ici dcomposs en error, o le systme se rend compte
d'un problme, et bad, qui peuvent reprsenter un gain pour l'attaquant. Nous proposons de
visualiser dans l'espace ces attaques et les rsultats obtenus an de localiser prcisment les
zones de code sensibles. Cette mthodologie permet au dveloppeur, grce l'identication de
ces zones, d'ajouter des contre-mesures appropries. Ces contre-mesures peuvent tre nouveau
testes en utilisant la mme mthode an de s'assurer que celles-ci empchent la russite de
l'attaque et aussi n'introduisent pas de nouvelle faille exploitable par une autre attaque. Pour
des exemples de contre-mesures ainsi qu'une mthode alternative de vrication, le lecteur peut
se rfrer [Sere et al. 2011]. Les auteurs utilisent un interprteur abstrait, fonctionnant sur
un modle de la mmoire, ainsi qu'un gnrateur de codes mutants, bas sur un modle d'at-
taque, an d'amliorer la rsistance du code contre les attaques par fautes. Leur outil s'utilise
sur du bytecode Java Card. Le dveloppeur peut annoter des fonctions dans le code an que
la machine virtuelle eectue des vrications supplmentaires d'intgrit en utilisant un jeu de

contre-mesures intgr la machine virtuelle. Certaines techniques utilises sont proches de
celles prsentes dans ce chapitre ou le prcdent. Le concept d'interprtation abstraite est aussi
utilis par Frama-C. L'approche par gnration de codes mutants est proche de l'approche qui
consiste crer de multiples versions attaques d'un code original que nous avons adopte ici.
La principale dirence est que la gnration de codes mutants est eectue directement en m-
moire tandis que la solution propose ici travaille par instrumentation du code source en amont
du compilateur. Cette solution ore une meilleure gnricit en C qui ne peut pas s'appuyer sur
une machine virtuelle. Dans ce chapitre, nous proposons galement une classication des eets
des attaques gnres au niveau fonctionnel an de faciliter le travail d'identication du code
vulnrable.
5.2.2 Mthode de classication des rsultats

Quand un programme contenant une attaque simule (par injection au niveau assembleur,
C ou avec gdb) est excut, le comportement du programme doit tre valu an de dterminer
si l'attaque a russi. Nous proposons la classication suivante qui regroupe les dirents cas
d'excutions :
not triggered : l'attaque n'a pas t dclenche lors de l'excution. Ce cas apparat
lorsqu'une attaque est insre dans une portion de code non stimule par le scnario
d'excution choisi. Dans tous les autres cas, l'attaque est dclenche ;
signal : le programme se termine et retourne un signal (sigsegv, sigbus, ...) ;
error : le programme se termine et retourne un message d'erreur ;
good : le programme se termine et la sortie retourne ainsi que le comportement du
programme correspondent ceux attendus ;
bad : le programme se termine mais la sortie retourne ainsi que le comportement du pro-
gramme ne correspondent pas ceux attendus. La dnition de bad doit tre dtermine
pour chaque application tant donn que le comportement ou la sortie attendue dpendent
de l'application considre ;
kill : le programme ne se termine pas et doit tre interrompu.
Les excutions aboutissant des good ou error peuvent tre considres comme tolrantes
vis--vis de l'attaque : le programme est capable de faire face l'attaque en l'ignorant ou en
dtectant un comportement incorrect. Pour une carte puce, dtecter une erreur peut amener
tuer la carte (en eacer le contenu de sa mmoire) ce qui est considr comme un compor-
tement appropri d'un point de vue scuritaire. Un crash, un signal ou un kill est aussi un
comportement appropri pour l'expert en scurit. Cela veut dire que le programme a t mis
dans un tat instable qui amne au blocage ou la non terminaison de celui-ci. Par consquent,
un attaquant n'est pas en mesure d'exploiter une telle attaque tant donn que la transaction
eectue avec le terminal n'aboutit pas. Par rapport [Madeira et al. 2000], les correspondances
sont correct pour good, hang pour killed et crash pour signal.
Le dernier scnario, le plus dangereux d'un point de vue de la scurit, est une excution
bad. Ce scnario peut tre interprt comme une excution qui a abouti mais a t susamment
perturbe pour induire un comportement incorrect. Ces scnarii sont les plus importants pour le
dveloppeur et ncessitent que une investigation plus approfondie de sa part an d'implmenter
la contre-mesure adquate.
Ligne source de destination
Rsultat de loracle
Ligne source dorigine
Figure 5.3 Reprsentation 2D des rsultats donn par un oracle
Nous qualions comme oracle le processus permettant de dterminer si le comportement

du programme est correct ou incorrect par rapport un scnario donn. La notion d'oracle est
dveloppe d'un point de vue pratique dans la section 5.5. La gure 5.3 illustre la reprsentation
en deux dimensions que nous avons choisie pour classier les rsultats des attaques injectes
suivant le modle d'attaque par goto. L'axe des abscisses donne la ligne de code source de
dpart du correspondant un goto inject dans le code une ligne prcise. L'axe des ordonnes
donne la ligne de code source d'arrive du saut correspondant un label inject dans le code.
L'intersection de ceux deux axes est un carr de couleur qui correspond une des classications
prsentes prcdemment qui traduit un comportement particulier du systme. Chacune des
classes possde un code couleur spcique. Cette reprsentation en deux dimensions permet
avec l'aide des codes couleurs de regrouper et d'identier visuellement les zones de code qui, si
elles ne sont pas excutes du fait d'une attaque par saut, ont un comportement similaire.
Synthse pour une attaque

Finalement, quand une attaque est identie, une quantication automatique des caractris-
tiques du code saut est ralise. Cette quantication aide dterminer la nature de l'attaque
ralise. Par exemple, le listing 5.1 montre une synthse des attaques classes en tant que bad
qui saute l'extrait de code suivant, de la ligne 4116 la ligne 4133 de la fonction BZ2_blockSort :
La quantication recense le nombre d'aectations et d'appels de fonction qui n'ont pas t
raliss. Elle prend aussi en compte si l'attaque entre ou sort d'un bloc de code d'une profondeur
suprieure. Dans cet exemple, les variables aectes ne sont pas utilises dans le reste de la
fonction, ce qui veut sans doute dire que ne pas raliser l'appel mainSort entrane une russite
de l'attaque. tant donn que le dveloppeur sait ce que doit raliser son code, il doit tre en
mesure de facilement comprendre les consquences du saut de ces lignes de code C. Ainsi, la
vue d'ensemble des lments de code permet celui-ci d'apprhender rapidement la cause et les
eets prcis de cette attaque et par consquent, l'aide implmenter la contre-mesure la plus
approprie. Celle-ci peut par exemple assurer que la fonction mainSort est bien appele.
Listing 5.1 Exemple d'une zone de code saute
goto label; // dbut de zone dattaque 1

if (wfact > 100) { 2
wfact = 100; 3
} 4
5
budgetInit = nblock * ((wfact - 1) / 3); 6
budget = budgetInit; 7
8
mainSort(ptr, block, quadrant, ftab, nblock, verb, &budget); 9
10
if (verb >= 3) 11
VPrintf3(" %d work, %d block, ratio %5.2f\n", 12
budgetInit - budget, 13
nblock, 14
(float)(budgetInit - budget) / 15
(float)(nblock == 0 ? 1 : nblock)); 16
17
if (budget < 0) { label: // fin de zone dattaque 18
Dlai d'expiration
Lors des exprimentations, en plus d'une synthse des lments sauts lors de l'attaque, nous
avons d prendre en compte un lment supplmentaire qui est le dlai d'expiration maximal
aprs lequel un test doit tre interrompu. Cette interruption est ncessaire dans les cas o une
attaque provoque une boucle innie dans le programme. Un paramtre exprimental, le dlai
avant interruption du test ou dlai d'expiration a donc t tabli. Nous avons vri exprimen-
talement qu'un facteur de deux fois le temps d'excution maximal pour le dlai d'expiration
convenait. La gure 5.4 montre la classication de toutes les attaques possibles contre la fonc-
tion principale de bzip2 en variant le dlai d'expiration pour la mthodologie utilisant gdb. En
utilisant gdb, il est possible de mesurer le temps d'excution de la fonction principale avant
l'interruption du processus si l'excution n'a pas atteint la n de la fonction. En utilisant un
dlai d'expiration de 0.1 s, un grand nombre d'excutions sous attaques sont classes en tant
que killed : la compression n'a pas le temps ncessaire pour tre eectue. La gure 5.4 montre
qu'avec un dlai de 0.14 s, la classication des attaques se stabilise. tant donn que le temps
d'excution original de bzip2 est approximativement de 0.159 s, cela montre qu'un facteur de 2
avant l'interruption du processus est susant pour avoir des rsultats reprsentatifs.
5.3 Exprimentations et analyse scuritaire

Une plate-forme exprimentale a t dveloppe an de remplir trois objectifs.
Premirement, conrmer que le modle d'attaque au niveau C est cohrent avec le modle
d'attaque au niveau assembleur (ce modle d'attaque au niveau assembleur correspond au
modle de faute sur un octet que nous avons choisi dans le chapitre 3) ;
Deuximement, montrer comment le modle d'attaque au niveau C permet au dveloppeur
d'obtenir des informations pertinentes sur les failles de scurit dans son code ;
Troisimement, montrer que l'ecacit d'une contre-mesure peut tre value visuellement.
La premire section 5.3 prsente l'installation de la plate-forme exprimentale dans une
premire sous section 5.3.1. Ensuite, les sections 5.3.2 et 5.3.3 prsentent les taux de couvertures
5.3. Exprimentations et analyse scuritaire 149
80000 Reference execution time
70000
not triggered
good
60000
error
signal
50000 killed
Attack count
bad
40000
30000
20000
10000
0
0.1 0.12 0.14 0.16 0.18 0.2
Execution time before killing the bzip2 process
Figure 5.4 Nombre d'attaques pour chaque catgorie en fonction du dlai d'expiration (en
utilisant la mthode gdb)
entre les direntes mthodes employes pour injecter des fautes dans bzip2 et gzip et montre
comment valuer l'ecacit d'une contre-mesure. Une troisime sous section 5.3.4 prsente une
comparaison entre ces dirents taux de couverture. La seconde section 5.4 propose une mthode
d'analyse des rsultats base sur la direntiation fonctionnelle des attaques ecaces et de
celles qui ne le sont pas. Les critres permettant cette direntiation ont t exposs dans la
section 5.2.2. Cette mthode d'analyse permet la fois l'identication de vulnrabilits dans
le code mais aussi l'valuation d'une contre-mesure implmente. Finalement, la 5.5 montre
comment la mthodologie propose peut aider dans l'analyse de la scurit d'un extrait de code
de carte puce d'Oberthur Technologies.
5.3.1 Plate-forme exprimentale

Comme expliqu prcdemment, nous considrons uniquement les attaques impactant le
contrle de ot caus par des attaques par nop ou des attaques par saut. Nous avons par
consquent bas l'implmentation de notre mthodologie sur le modle d'attaque par goto an
d'injecter exhaustivement ces attaques par goto au niveau du code source C.
Les binaires obtenus sont lancs et le rsultat de chaque excution est classi suivant la
mthodologie dcrite dans la section 5.2.2. L'injection peut tre eectue dans le code source
avant compilation ou dynamiquement pendant l'excution en utilisant un dbogueur. An de
pouvoir analyser les taux de couverture, nous avons aussi implment l'injection de ces attaques
par saut au niveau assembleur. Trois mthodes d'injection ont donc t utilises : au niveau du
code source C, assembleur et en utilisant un dbogueur :
La mthodologie d'injection d'attaque goto assembleur insre des sauts inconditionnels

au niveau assembleur : une instruction de saut inconditionnel jmp label ainsi qu'un label
de destination label sont insrs dans le corps de la fonction tudie. Le code rsultant
est alors compil an d'obtenir une version attaque du programme ;
La mthodologie d'injection d'attaque goto C insre directement une attaque par goto
dans le code source de la fonction cible. Le code instrument est ensuite compil et excut.
Comme montr dans la section 3.4.3 du chapitre 3, les attaques transientes peuvent tre
simules au niveau C en encapsulant les attaques par goto injectes dans une condition
if/then qui contrle lorsqu'elle est dclenche en utilisant un compteur d'excution. Nous
avons aussi implment l'injection d'attaques transientes au niveau C ;
La mthodologie d'injection d'attaque goto utilisant gdb vite d'avoir compiler une
nouvelle fois le programme : le dbogueur gdb est utilis avec le binaire d'origine et
interrompt la vole l'excution du programme an d'injecter dynamiquement au niveau
d'une ligne C une attaque goto permettant de faire sauter l'excution une autre endroit
du programme. En utilisant les interfaces de programmation python de gdb, un script
contrle le programme s'excutant sous gdb. Un point d'arrt est insr au dbut de la
fonction tudie. Quand l'excution atteint ce point d'arrt, une duplication du processus
en cours est ralise. Le script python insre ensuite un point d'arrt la ligne source de
l'attaque par goto. Quand la source du saut est atteinte, un saut est ralis en prcisant
gdb le numro de la ligne cible qui convertit celle-ci en une adresse mmoire. L'excution
du programme est ensuite reprise jusqu' son terme. L'avantage principal de cette mthode
est qu'une fois qu'une attaque a t ralise, l'attaque suivante peut tre teste en utilisant
une nouvelle duplication du processus original (qui a t interrompu au dbut de la fonction
tudie).
Des attaques par saut peuvent modier arbitrairement le contrle de ot permettant de sau-
ter du corps d'une fonction dans le corps d'une autre fonction. Cependant, un tel saut a une
faible probabilit de succs tant donn que la pile et donc le contexte d'excution deviennent ra-
pidement incohrentes une fois que les paramtres sont dpils. Par consquent, nous considrons
uniquement les attaques par saut intra-fontion.
5.3.2 Exemple sur bzip2

Nous considrons le programme de compression bzip2 inclus l'intrieur des tudes com-
paratives de rfrence spec 2006 [Henning 2006] an d'eectuer une analyse de scurit en
profondeur. L'application est constitue de 106 fonctions et 3 069 instructions C. Le code as-
sembleur correspondant est compos de 26 006 instructions. Le principe de fonctionnement de
bzip2 est bas sur l'algorithme de Burrows-Wheeler et un encodage de Human. L'algorithme de
Burrows-Wheeler repose sur une rorganisation des donnes compresser de manire regrou-
per les caractres identiques l'aide d'oprations de dcalage. L'encodage de Human repose
sur un encodage probabiliste des donnes d'entre en un arbre binaire tri l'aide des fr-
quences d'occurrence de chaque caractre. Le tri est eectu l'aide d'oprations de dcalage et
d'additions.
Nous slectionnons comme entre un chier de 489K contenant des informations alatoires.
An d'analyser la sortie d'une compression, nous considrons une excution comme mauvaise
(bad) toute excution qui gnre un chier compress dirent de celui de rfrence obtenu avec
une excution sans attaque du programme.
La gure 5.5 montre la rpartition des rsultats obtenus par l'oracle classis suivant les cat-
gories mentionnes dans la section 5.2.2. Ce graphique montre non seulement la trace d'excution
du scnario de test utilis l'intrieur de bzip2, il montre aussi, pour cette trace, les fonctions
qui, si elles sont attaques, peuvent avantager un attaquant. Ainsi, les parties blanches (not
triggered) du graphique correspondent au code qui n'est pas stimul par le test utilis. Une
grande proportion de vert (good) pour une fonction signie qu'elle est rsistante aux attaques
par fautes. Une grande proportion de jaune (error) signie que le code dispose de mcanismes
de dtection qui sont dclenchs par l'attaque. Une grande proportion de bleu (signal) montre
que le programme communique avec le systme d'exploitation par le biais de signaux pour si-
gnaler un comportement anormal. Ce cas ne concerne pas les systmes embarqus qui n'utilisent
pas de signaux. Une grande proportion d'orange pour une fonction montre qu'en dclenchant
une attaque dans cette fonction une boucle innie a t cre et que le test a t arrt aprs un
dlai calcul dans la section 5.2.2. Gnralement, ce cas survient lorsque l'attaque introduit une
boucle ou empche l'excution de la condition d'arrt d'une boucle existante. Finalement, les
fonctions qui ont une grande proportion de rouge (bad) sont particulirement vulnrables aux
attaques par fautes. Attaquer de telles fonctions augmente la probabilit d'obtenir une sortie
errone sans que le programme ne le dtecte. Grce cette reprsentation, il est possible de
caractriser visuellement la rsistance aux attaques du programme fonction par fonction et ainsi
discriminer parmi ces fonctions, celles qu'il convient de scuriser.
bad
error
good
killed
signal
0
20
40
60
80
100
not triggered
addFlagsFr..
add_pair_t..
applySaved..
applySaved..
bsFinishWr..
bsPutUChar
bsPutUInt3..
bsW
BZ2_blockS..
BZ2_bsInit..
BZ2_bz__As..
BZ2_bzBuff..
BZ2_bzBuff..
BZ2_bzclos..
BZ2_bzComp..
BZ2_bzComp..
BZ2_bzComp..
BZ2_bzDeco..
BZ2_bzDeco..
BZ2_bzDeco..
BZ2_bzdope..
BZ2_bzerro..
BZ2_bzflus..
BZ2_bzlibV..
BZ2_bzopen
BZ2_bzRead..
BZ2_bzRead..
BZ2_bzRead..
BZ2_bzRead
BZ2_bzWrit..
BZ2_bzWrit..
BZ2_bzWrit..
BZ2_bzwrit..
BZ2_compre..
BZ2_decomp..
BZ2_hbAssi..
BZ2_hbCrea..
BZ2_hbMake..
BZ2_indexI..
bz_config_..
bzopen_or_..
cadvise
cleanUpAnd..
compressed..
compress
compressSt..
configErro..
containsDu..
copyFileNa..
copy_input..
copy_outpu..
countHardL..
crcError
default_bz..
default_bz..
fallbackQS..
fallbackSi..
fallbackSo..
fileExists
flush_RL
fopen_outp..
generateMT..
handle_com..
hasSuffix
init_RL
ioError
isempty_RL
license
mainGtU
mainQSort3
main
mainSimple..
mainSort
makeMaps_d
makeMaps_e
mapSuffix
mkCell
mmed3
myfeof
myMalloc
mySignalCa..
mySIGSEGVo..
notAStanda..
outOfMemor..
pad
panic
Figure 5.5 Rsultats d'attaques permanentes ralises en C sur le code de bzip2
prepare_ne..
redundant
saveInputF..
sendMTFVal..
setExit
showFileNa..
snocString
testf
testStream
uInt64_fro..
uInt64_isZ..
uInt64_qrm..
uInt64_toA..
uInt64_to_..
uncompress
uncompress..
unRLE_obuf..
unRLE_obuf..
usage
Chapitre 5. Test de scurit et visualisation 152

5.3.3 Exemple sur gzip

Nous avons galement utilis la mthodologie sur les fonctions du code de gzip an de pou-
voir comparer le comportement de deux programmes sous attaques. Ces deux programmes sont
deux implmentations direntes d'un mme besoin fonctionnel et reposent sur des algorithmes
dirents. Nous considrons maintenant le programme de compression gzip. Cette application
est constitue de 61 fonctions et 2 453 instructions C. Le code assembleur correspondant est
compos de 12 951 instructions.
Le principe de fonctionnement de gzip est bas sur un encodage de Lempel-Ziv et un en-
codage de Human. L'encodage de Lempel-Ziv repose sur la cration d'une table de symbole
cre en parcourant l'entre compresser. Celle-ci est base sur des distances calcules entre un
motif courant et un motif prsent dans une partie prcdente du chier. L'implmentation d'un
tel encodage ncessite de parcourir les donnes et donc des manipulations d'index et des calculs
de distance.
Nous slectionnons comme entre le mme chier de 489K contenant des informations ala-
toires ayant servi aux tests sur bzip2. An d'analyser la sortie d'une compression, nous consi-
drons une excution comme mauvaise (bad) toute excution qui gnre un chier compress
dirent de celui de rfrence obtenu avec une excution sans attaque du programme.
Ainsi, la gure 5.6 montre les rsultats obtenus sur l'ensemble du code de gzip. Comme
pour bzip2, la trace obtenue caractrise une excution particulire du code par l'utilisation
d'une partie du code du programme. Il est possible, partir de la gure, de dterminer les
fonctions sensibles qui auront une plus grande proportion de rouge. Il est aussi possible de
comparer partir de ces gnomes, deux programmes dirents excutant un mme scnario
an de dterminer lequel est plus rsistant aux attaques par fautes.
bad
error
good
killed
signal
0
20
40
60
80
100
not triggered
abort_gzip
add_envopt
basename
bi_init
bi_reverse
bi_windup
build_bl_t..
build_tree..
build_tree
check_ofna..
check_zipf..
clear_bufs
compress_b..
copy_block
copy
copy_stat
create_out..
ct_init
ct_tally
decode_c
decode_p
decode
decode_sta..
deflate_fa..
deflate
display_ra..
do_exit
do_list
do_stat
error
exchange
file_read
fillbuf
fill_inbuf
fill_windo..
flush_bloc..
flush_outb..
flush_wind..
gen_bitlen
gen_codes
getbits
get_istat
get_method
_getopt_in..
getopt_lon..
getopt
get_suffix
help
huf_decode..
huft_build
huft_free
inflate_bl..
inflate_co..
inflate_dy..
inflate_fi..
inflate
inflate_st..
init_block
init_getbi..
license
lm_init
longest_ma..
lzw
main
make_ofnam..
make_simpl..
make_table
my_index
my_strlen
name_too_l..
pqdownheap
read_c_len
read_error
read_pt_le..
read_tree
reset_time..
same_file
scan_tree
send_all_t..
send_bits
Figure 5.6 Rsultats d'attaques permanentes ralises en C sur le code de gzip
send_tree
set_file_t..
shorten_na..
strlwr
treat_file
treat_stdi..
unlzh
unlzw
unpack
unzip
updcrc
usage
version
warn
write_buf
write_erro..
xmalloc
zip
Chapitre 5. Test de scurit et visualisation 154

Comparaison de gnomes
bzip2 produit une sortie plus petite et repose sur la cration de blocs indpendants ce qui
permet une ventuelle rcupration en cas de corruption. gzip est lgrement moins performant
en terme de facteur de compression mais est un peu plus rapide. La consommation mmoire
l'excution est aussi plus faible pour gzip [Collin 2005] ce qui laisse penser que le programme
utilise moins de variables de grande taille simultanment. En eet, le fonctionnement de gzip
repose sur le principe d'une fentre de taille xe parcourant le chier source en analysant une
portion limite du chier compresser tandis que pour bzip2 l'ensemble des permutations de la
chaine d'entre doit tre contenue un moment donn en mmoire.
Nous qualions de gnome une reprsentation de la rpartition des classes de rsultats obte-
nues aprs l'excution d'un scnario de test en prsence d'attaques. En eet, cette reprsentation
caractrise le comportement du programme sous attaques et cre une signature particulire de
celui-ci dans un cas particulier d'excution s'il est soumis des attaques par saut.
Les gures 5.7 et 5.8 illustrent les gnomes des deux programmes de compression. Les
fonctions et le code qui n'ont pas t stimuls ont t retirs an d'obtenir des chantillons re-
prsentatifs du comportement de chaque programme. Les dirences entre les deux programmes
commencent devenir visibles. On remarque un plus grand nombre d'erreurs error et de si-
gnal dans le gnome de bzip2 que dans celui de gzip. Cette observation nous montre que
bzip2 embarque plus de code ddi la gestion des erreurs et utilise plus de signaux dans
l'implmentation de ses fonctionnalits.
An de pouvoir comparer plus ecacement ces deux programmes, la gure 5.9 illustre la
comparaison entre les gnomes, en distribuant les attaques par classes. On peut ainsi conrmer
les observations prcdentes et conrmer que gzip est plus sensible des attaques par fautes
que bzip2. Le plus grand nombre de mcanismes d'erreur de bzip2 visibles dans les catgories
signal et error sont vraisemblablement responsables de cette proportion plus faible de bad.
De manire priphrique, on note aussi que ces deux programmes sur ce scnario particulier
ont une proportion quivalente de killed. Une construction interne proche peut tre la raison
de cette galit mais un nombre plus grand de scnarii doit tre utilis pour conrmer cette
hypothse.
Les attaques transientes

Aprs avoir prsent les eets des attaques permanentes, nous nous intressons aux attaques
transientes. On appelle attaque transiente une attaque qui n'est dclenche qu'une fois pendant
l'excution, contrairement une attaque qui est dclenche chaque fois que le bloc de code
C contenant l'attaque est excut. Ainsi, le nombre d'attaques transientes par goto tester
(et classier) par ligne de code source est gal au nombre d'excutions de l'instruction C cor-
respondante. Nous avons test exhaustivement ces attaques transientes et la gure 5.10 montre
la classication des attaques pour la totalit du code de bzip2. Le nombre de cas good (resp.
kill) augmente (resp. diminue) tant donn que les attaques par saut arrire transientes ont
une plus faible probabilit de provoquer une boucle innie.
La gure 5.11 montre le classement des attaques pour la fonction mainQSort3 de bzip2 en
fonction du moment o l'attaque est dclenche. Les attaques qui sont dclenches la premire
fois que le bloc de code C correspondant est excut donne environ 30% de bad, 30% de kill,
et 30% de good. Les attaques dclenches entre la troisime et la 25e excution du bloc C
156
Distribution of attacks among categories Distribution of attacks among categories
0
20
40
60
80
100
0
20
40
60
80
100
add_envopt addFlagsFr..
basename add_pair_t..
bsFinishWr..
bi_init
bsW
bi_reverse
BZ2_blockS..
bi_windup
bad
bad
BZ2_bzComp..
build_bl_t.. BZ2_bzComp..
build_tree BZ2_bzComp..
clear_bufs BZ2_bzWrit..
killed
killed
copy_block BZ2_bzWrit..
ct_init BZ2_bzWrit..
BZ2_compre..
ct_tally
BZ2_hbAssi..
deflate
BZ2_hbMake..
signal
signal
do_exit
compress
file_read compressSt..
fill_windo.. copyFileNa..
flush_bloc.. copy_input..
error
error
flush_outb.. copy_outpu..
flush_RL
gen_bitlen
generateMT..
gen_codes
handle_com..
Figure 5.8 Gnome de gzip

init_block
good
good
Figure 5.7 Gnome de bzip2

hasSuffix
lm_init isempty_RL
longest_ma.. mainGtU
main mainQSort3
pqdownheap main
scan_tree mainSimple..
mainSort
send_bits
makeMaps_e
treat_stdi..
myfeof
updcrc
myMalloc
write_buf prepare_ne..
zip snocString
Chapitre 5. Test de scurit et visualisation
Distribution des attaques parmi les classes
0.5
0.4
0.3
0.2
0.1
0
signal bad error good killed
Classes
bzip2 gzip
Figure 5.9 Comparaison des gnomes de bzip2 et gzip
rduisent le nombre de cas good. Aprs la 26e excution du bloc C, la gure 5.10 montre que
le classement se stabilise. Cependant, cette stabilit dpend du nombre d'excutions de chaque
instruction C et des donnes d'entre.
5.3.4 Couverture assembleur par le modle C
An de valider le modle d'attaque haut niveau tabli dans le chapitre 3, nous dtaillons dans
cette section les aspects techniques des trois mthodes d'injection prsentes prcdemment. Le
but de la section est de calculer exprimentalement le taux de couverture des attaques simules
au niveau assembleur par celles qui le sont au niveau C.
Le premier avantage qu'il y a utiliser trois mthodes d'injection d'attaques direntes est
que les mthodes assembleur et C peuvent tre compares an de savoir si le modle d'attaque
C par goto donne une couverture satisfaisante des attaques possibles par saut en assembleur.
De plus, l'utilisation d'un modle de haut niveau ncessite de gnrer l'ensemble des binaires
attaqus correspondant, ce qui entraine un grand nombre de gnrations de code source et
de cycles de compilation. La mthode gdb injecte dynamiquement les attaques haut niveau
pendant l'excution. Cette mthode rduit sensiblement le temps ncessaire la ralisation des
tests.
158
Distribution of attacks among categories Distribution of attacks among categories
0
20
40
60
80
100
0
20
40
60
80
100
1 addFlagsFr..
2
3 add_pair_t..
4 bsFinishWr..
5 bsPutUChar
6
bsW
7
8 BZ2_blockS..
bad
9 BZ2_bzComp..
10
BZ2_bzComp..
11
12 BZ2_bzComp..
13 BZ2_bzWrit..
14
killed
BZ2_bzWrit..
15
16 BZ2_bzWrit..
17 BZ2_compre..
18 BZ2_hbAssi..
19
20 BZ2_hbMake..
21 compress
signal
22 compressSt..
fonction du moment o l'attaque est dclenche

23
containsDu..
24
25 copyFileNa..
26 copy_input..
27
error
copy_outpu..
28
29 flush_RL
30 generateMT..
31 handle_com..
32
hasSuffix
Moment when attack is triggered

33
good
34 isempty_RL
35 main
36
37 mainGtU
38 mainQSort3
39 mainSimple..
40
mainSort
41
not triggered
42 makeMaps_e
43 myfeof
bad
error
good
killed
44
signal
myMalloc
45
46
not triggered prepare_ne..
47 saveInputF..
48 sendMTFVal..
Figure 5.10 Les attaques transientes injectes avec gdb dans la totalit de bzip2
49
50 snocString
Figure 5.11 Classement des attaques transientes pour la fonction mainQSort3 de bzip2 en
Chapitre 5. Test de scurit et visualisation
Statistiques ASM C gdb
Taille du code 26 103 8 643 8 643
Nb d'attaques 3 531 954 117 802 131 630
Temps Simu. 2d 18h 8h 2h
Nb BADs 273 129 14 050 5 417
Nb chier vide 103 952 6 514 1 301
Uniq BADs 2 326 1 245 852
ASM couverture 100% 25% 25%
Table 5.2 Couverture

d'attaques
Table 5.1 Statistiques des attaques simules sur bzip2
Distribution of attacks in ASM Distribution of attacks in C

0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%
addFlagsFromEnvVar
add_pair_to_block
BZ2_blockSort
BZ2_bzCompressEnd
BZ2_bzCompressInit
BZ2_bzCompress
BZ2_bzWriteClose64
BZ2_bzWriteOpen
BZ2_bzWrite
BZ2_compressBlock
BZ2_hbMakeCodeLengths
compress
compressStream
copy_input_until_stop
copy_output_until_stop
generateMTFValues
handle_compress
mainGtU
mainQSort3
main
mainSimpleSort
mainSort
bad killed signal error good not triggered
Figure 5.12 Distribution des attaques permanentes injecte au niveau ASM / C pour les
fonctions de bzip2 de plus de 7 instructions
Nous proposons de comparer les consquences des attaques du modle d'attaque au niveau
C aux consquences des attaques au niveau assembleur. Ces dernires sont reprsentes dans la
gure 5.2 en lignes pointilles. Nous comparons aussi nos rsultats avec ceux obtenus grce une
technique complmentaire base sur l'injection d'attaques l'aide d'un dbogueur. Cette partie
de l'tude, dont les rsultats sont donnes en section 5.3.4, est une vrication exprimentale de
la mthodologie globale et n'est pas ncessaire pour utiliser la mthode propose.
La gure 5.12 montre les classications C et ASM (assembleur) des eets d'attaques per-
manentes sur des fonctions possdant plus de 7 instructions dans l'ensemble du code source de
bzip2. Les attaques par saut sont injectes pour chaque couple d'instructions assembleur. Cette
gure montre que les distributions sont semblables ce qui suggre que le modle d'attaque
haut niveau permet de couvrir une portion signicative du modle bas niveau. Les fonctions
sensibles, qui ont une grande proportion de bads, doivent tre analyses de manire approfondie,
comme prsent plus loin dans la section 5.4.2.
An de comparer les taux de dtection des attaques russies de la mthodologie d'injection
d'attaque, nous avons calcul l'identiant md5 de chaque chier compress par une excution du
programme. Si le md5 correspond celui calcul en utilisant une version originale du programme
bzip2, le scnario de test est considr good, sinon il est bad.
Les tableaux 5.1 et 5.2 donnent les rsultats statistiques obtenus avec les trois mthodologies.
D'abord, on remarque qu'il y a 30 fois moins de cas de test pour la mthodologie C par rapport
la mthodologie ASM ce qui se traduit par une excution de l'ensemble des tests ncessitant
8 fois moins de temps. La mthodologie gdb a un comportement similaire et est encore plus
rapide car elle ne ncessite pas de nouvelle compilation de l'ensemble du programme et factorise
une partie de l'excution des tests. Ensuite, nous calculons le nombre de chiers compresss
dirents obtenus avec le programme attaqu. Chaque chier correspond un scnario unique
bad et nous considrons que deux attaques qui retournent le mme chier ont le mme eet.
Un cas particulier du scnario bad apparat quand un chier vide est obtenu ce qui arrive dans
prs de 46% des scnarii pour la mthodologie C. Comparer les cas uniques de bad permet de
dterminer la couverture d'une mthodologie par une autre. L'intersection prcise des groupes
obtenus est donn dans la tableau 5.2. Pour la mthodologie C, nous obtenons 1245 bads uniques
dont 482+21 sont partags avec la mthodologie ASM qui totalise 2326 bads. Ces rsultats nous
amnent une couverture de 21% des rsultats obtenus avec la mthodologie assembleur par les
rsultats obtenus avec la mthodologie C. La mthodologie gdb conrme ces rsultats.
5.4 Analyse des rsultats

5.4.1 Distribution des attaques par taille du saut
La gure 5.13 montre la distribution d'attaques par taille du saut (nombre de lignes de code
successives sautes par ce saut). La courbe good montre que le programme est particulirement
sensible aux attaques par saut de grande taille (suprieur 260 lignes) : le programme bzip2 ainsi
attaqu ne retourne pas de chier compress correct. On remarque de manire plus tonnante
que certains saut arrire mnent des good. Ces attaques ne sont pas classes comme kill car
le programme n'est pas entr dans une boucle innie. La courbe bad montre que la plupart des
attaques russies ont une taille de saut entre 10 et 20 lignes de code. Le nombre de ces attaques
russies dcroit ensuite d'une manire quasiment linaire. D'une manire plus surprenante, le
nombre d'attaques classies comme bad est quasiment constant pour les attaques par saut
arrire jusqu'au sauts arrire de -540 lignes o il tombe 0.
D'un point de vue scuritaire, cette gure aide identier les plages d'attaques qui peuvent
tre dangereuses pour le programme considr. Pour bzip2 les scnarii bad sont des sauts en
5.4. Analyse des rsultats 161
avant entre 0 et 450 lignes de code. Ce rsultat peut tre dirent pour un autre code source.
2000
1540
1180
900
680
520
400
300
220
160
Attack count
120
80
60
40
20
bad
error
good
killed
600 550 500 450 400 350 300 250 200 150 100 50 0 50 100 150 200 250 300 350 400 450 500 550 600
Jump size (in lines)
Figure 5.13 Nombre d'attaques en fonction de la taille du saut exprim en lignes de code C
5.4.2 Analyse visuelle des fonctions vulnrables
5561 kill good bad
5551
Destination line number
5541
5531
5521
5511
5501
5491
5481
5484 5494 5504 5514 5524 5534 5544 5554
Source line number
Figure 5.14 Classication spatiale des attaques good/bad/kill en fonction des lignes source
et destination, simules en C pour la fonction BZ2_compressBlock
4156 kill good bad

4146
4136
4126
4116
4106
4096
4086
4087 4097 4107 4117 4127 4137 4147
Source line number
et destination, simules en C pour la fonction BZ2_blockSort
Les rsultats sont obtenus par l'excution d'un scnario fonctionnel. Par construction, la
classication des rsultats prend en compte le gain que peut obtenir l'attaquant en provoquant
une modication de l'excution avec une faute. Les fonctions ayant des rsultats classes comme
bad sont donc sensibles d'un point de vue de la scurit, par rapport au scnario excut. Elles
reprsentent la possibilit qu'un attaquant obtienne un gain sans que le systme ne s'en rende
compte et ne dclenche de contre-mesure.
Une fois qu'une fonction sensible et vulnrable aux fautes est identie, grce son taux
important de cas bad, le dveloppeur charg de la scurit a besoin d'une reprsentation plus
prcise des attaques dangereuses an de comprendre pourquoi ces attaques russissent. Les
gures 5.14 et 5.15 montrent deux exemples d'une reprsentation spatiale des classes d'attaques
good, kill et bad (les autres classes ne sont pas reprsentes). Nous utilisons les conventions
de la gure 5.3. Comme on pouvait s'y attendre, les sauts arrires gnrent un grand nombre de
cas kill tandis que les sauts en avant amne des cas bad.
Pour la fonction BZ2_compressBlock de la gure 5.14, un grand nombre de cas bad sont
obtenus si la source de l'attaque se trouve entre les lignes de code source 5504 et 5550. Pour la
fonction BZ2_blockSort, le nombre de cas bad est moins important. On remarque aussi qu'une
srie d'attaques russit si la ligne de code source de destination de l'attaque se trouve aprs
la ligne 4126. Ces informations sont trs utiles pour le dveloppeur charg d'implmenter des
contre-mesures adaptes. Nous dveloppons ce dernier point l'aide de l'exemple de la fonction
BZ2_blockSort dans la prochaine section.
5.4. Analyse des rsultats 163
Listing 5.2 Implmentation d'une contre-mesure pour la fonction BZ2_blockSort ne ncessitant pas de d-
calage de la numrotation des lignes du code de dpart
/** Code original **/ /** contre-mesure **/ 4085

/** kc(); = {perror("KILLCARD");exit(-1);} **/ 4086
int security = 48; 4087
... 4088
security++; 4140
s->origPtr = -1; 4141
if (security != 49) kc(); security++; 4142
for (i = 0; i < s->nblock; i++) 4143
{ if (security != 50+2*i) kc(); security++; 4144
if (ptr[i] == 0) { 4145
s->origPtr = i; 4146
break; 4147
} if (security != 51+2*i) kc(); security++; 4148
} 4149
if (security < 50) kc(); 4150
AssertH(s->origPtr != -1, 1003); 4151
5.4.3 Implmentation de contre-mesures

Le listing 5.2 montre un extrait de la fonction BZ2_blockSort dans lequel la partie gauche du
listing est le code original. tant donn que nous avons dcouvert un grand nombre de bad dans
la gure 5.15, nous proposons une implmentation d'une contre-mesure nave pour scuriser la
zone 4140-4151 . Cette contre-mesure, sur la partie droite du listing 5.2, consiste incrmenter
et tester rgulirement un simple compteur.
4156 kill good bad

4146
4136
4126
4116
4106
4096
4086
4087 4097 4107 4117 4127 4137 4147
Source line number
et destination, simules en C pour la version scurise de BZ2_blockSort
La gure 5.16 montre la nouvelle classication des attaques. Plusieurs cas bad ont disparu
pour tre remplac par des cas error (les carrs noirs ont disparu de la partie suprieure de
la gure). Certains cas kill ont aussi disparu de la mme zone (partie droite de la gure). Cet
exemple montre comment un dveloppeur peut implmenter une contre-mesure permettant de
contrer un grand nombre d'attaques par contrle de ot ralises dans la pratique par un saut
dans le code depuis le dbut de la fonction jusque dans la zone 4140-4151.
5.5 Rsultats exprimentaux sur code de carte puce

An d'implmenter un oracle gnrique permettant de classer les rsultats des excutions de
codes de cartes puce, nous avons implment un oracle externe la carte, i.e., dans un terminal
de simulation. A l'aide de ce systme, un statut d'erreur signal par la carte au terminal se traduit
par un cas bad. L'avantage principal rsultant de la cration d'un tel oracle est qu'il peut tre
utilis pour n'importe quelle fonction implique dans une opration qui retourne un statut au
terminal.
Comme mentionn prcdemment, la signication d'un cas bad peut changer suivant l'ap-
plication. Ce cas reprsente un comportement scuritaire incorrect pour le systme. Ce compor-
tement scuritaire incorrect se manifeste par des vnements observables un certain niveau du
systme. Dans notre cas, nous avons choisi, pour des soucis de gnricit, de nous intresser au
statut renvoy par la carte car il correspond une philosophie de test en bote noire proche de
ce que peut raliser un attaquant. Cependant, il est aussi possible, pour plus de prcision, de
se placer dans une situation de test en bote blanche au niveau du code source du programme.
Dans ce cas, on peut, par exemple, crer un oracle capable d'apprcier si une criture mmoire
est correctement eectue, qu'une variable est bien incrmente (respectivement dcrmente)
ou qu'une valeur discrte est bien aecte une variable. Cette notion d'oracle peut facile-
ment tre tendue puisqu'on peut aussi crer un autre niveau un oracle capable d'apprcier si
lors d'une excution le composant laisse fuir de l'information par canaux cachs. En fait, pour
toute garantie de scurit souhaite (une proprit de scurit dans notre cas), s'il est possible
de dterminer un ou plusieurs critres observables retant le respect ou non de la proprit,
on peut crer un oracle qui, partir de ces critres, direncie un comportement correct d'un
comportement qui ne l'est pas. Ainsi, on peut direncier les attaques russies des autres. En
variant et en combinant les oracles il est possible de prendre en compte l'ensemble des capacits
d'observation et d'action des attaquants.
La mthodologie d'injection au niveau du code source a t applique une fonction sensible

d'un projet d'Oberthur Technologies ralisant une authentication basique. Le scnario considr
consiste ce qu'un utilisateur fournisse de mauvais certicats au mcanisme d'authentication,
ce qui doit conduire la carte refuser d'authentier celui-ci. L'attaquant cherche obtenir cette
authentication en attaquant physiquement la carte.
La fonction considre, compose de 180 lignes de code C, est responsable de la partie prin-
cipale du processus d'authentication. D'un point de vue scuritaire, toute attaque dtecte sur
une carte puce doit dclencher une rponse scuritaire consistant tuer la carte. La catgorie
killcard est la rponse scuritaire la plus forte que peut dclencher la carte quand une attaque
est dtecte. Les cas o une erreur ou un signal est retourn par la carte ou lorsque la dcision
nale est de refuser l'accs l'utilisateur (good) ne sont pas des cas dangereux pour la scurit
de la fonction car l'attaque a chou. Par consquent, les attaques qui permettent l'authentica-
tion sous attaque sont celles qui retournent un jeton valide et un statut valide au terminal. Nous
5.5. Rsultats exprimentaux sur code de carte puce 165
avons congur l'oracle pour qu'il classe ces cas dans la catgorie bad incluant donc les attaques
considres comme dangereuses pour la scurit du programme. Notons que pour amliorer les
performances de nos campagnes de test, nous catgorisons d'abord les rsultats suivant le statut
retourn par la carte au terminal et analysons la validit du jeton d'authentication que dans
un second temps.
killed bad good error killcard not_triggered

270
250
230
210
190
170
150
130
110
90
90 110 130 150 170 190 210 230 250 270
Source line number
Figure 5.17 Classication spatiale des attaques kill/bad/error en fonction des lignes source
et destination, simules en C pour une fonction sensible du code source de d'une carte puce
La gure 5.17 prsente une classication spatiale des rsultats des attaques. Dans ce scnario
particulier, les cas bad pour cette fonction apparaissent quand le saut a lieu dans une zone
dtermine par les lignes (212-268,92-209). Les points obtenus dans cette zone reprsentent des
attaques potentiellement dangereuses car elles ont le comportement d'une attaque russie et
ncessitent uniquement un saut dans le code pour provoquer ce comportement.
La distribution de ces attaques considres comme dangereuses est reprsent dans l'espace
dans la gure 5.18. Cette gure montre la relation entre le nombre d'attaques considres comme
dangereuses et le nombre de lignes du code source original qui sont sautes. Pour cette fonction
sensible stimule par ce scnario de test particulier, il apparat que les sauts d'une distance de
40 120 lignes de code successives sont celles qui donnent le plus d'attaques russies.
tant donn que, pour Oberthur Technologies, seuls les sauts d'une distance faible sont
considrs comme des attaques ralistes car elles sont ralisables dans la pratique de manire
contrle et reproductible, nous nous sommes intresss 3 attaques d'une distance de saut
infrieure 10 lignes de code C successives. Nous avons examin les 3 attaques identies et
avons dtermin 2 faux positifs, i.e., o le statut renvoy par la carte est correct mais o le jeton
d'authentication gnr est incorrect. Par consquent, seul un cas sur ces 3 cas bad est vraiment
dangereux. En utilisant les lignes source et destination identiant le saut concern, nous sommes
3
Attack count
0
0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170
Jump size (in lines)
Figure 5.18 Nombre de rsultats BAD en fonction de la distance de l'attaque par saut
remont la cause de la vulnrabilit : un saut direct dans une branche fonctionnelle incorrecte
d'une condition. La consquence fonctionnelle de cette attaque est une authentication russie
par l'utilisateur avec des certicats incorrects.
Cette attaque a t identie comme la plus raliste vis--vis du processus d'authentication.

Les experts scuritaires ont nanmoins rapport que la distance du saut assembleur considr
rendait l'attaque extrmement dicile raliser et qu'une contre-mesure supplmentaire n'tait
pas ncessaire.
La gure 5.18 montre que si des sauts d'une distance plus grande pouvaient tre contrls
prcisment, le taux de russite des attaques serait considrablement amlior et l'implmenta-
tion considre deviendrait vulnrable des attaques exploitant une perturbation du contrle de
ot au niveau fonctionnel. Pour terminer, on peut prciser que le critre discriminant de la cat-
gorie bad peut tre amlior an d'incorporer la vrication du jeton d'authentication. Cette
amlioration permettrait de direncier les attaques vraiment dangereuses et ainsi d'exclure les
faux positifs identis. Cependant, pour ne pas pnaliser les performances des campagnes de
test, cette vrication doit tre faite seulement aprs avoir vri que le statut retourn est
identique au statut d'un scnario correct.
5.6 Conclusion
Dans ce chapitre, nous avons propos une mthodologie de test dynamique ainsi qu'un en-
vironnement de test an de valider le comportement fonctionnel d'une implmentation sous
attaque physique. Cette mthodologie est une alternative la solution statique de vrication
d'intervalles de valeur propose dans le chapitre prcdent. Elle permet d'obtenir une synthse
du comportement sous attaque sur l'ensemble du code stimul par un cas de test. Les attaques
simules correspondent au modle d'attaque tabli dans le chapitre 3. L'ensemble des attaques
par saut du modle d'attaque par goto peuvent ainsi tre simules. partir d'une reprsen-
tation visuelle du comportement obtenu, le dveloppeur peut isoler les fonctions susceptibles
d'engendrer une faille fonctionnelle de scurit. Cette reprsentation permet galement de ltrer
les attaques pouvant tre considres comme ralistes jusqu' obtenir un chantillon rduit de
lignes de code considrer. Le dveloppeur doit conrmer la faisabilit d'une attaque mat-
rielle ces endroits du code source en prenant en compte l'architecture matrielle utilise. Cette
tape consiste vrier si le code assembleur gnr est galement sensible des attaques du
modle d'attaque. Pour ce faire, une des mthodologies assembleur proposes peut tre utilise.
Seule la mthodologie au niveau C a t implmente dans un contexte industriel. Celle-ci pr-
sente l'avantage de pouvoir tre intgre au processus de dveloppement et utilis alors que le
composant cible et donc la plateforme matrielle associe n'est pas encore disponible. Un autre
avantage est que cette mthode contrairement la mthode du chapitre prcdent ne ncessite
pas d'annotation pour fournir de rsultats. L'ensemble du processus est automatis. La gnra-
tion de l'ensemble des codes attaqus permet galement de rejouer une attaque prsente dans une
campagne d'attaque an de recrer le contexte d'excution de l'attaque. Cette mthode couvre
l'ensemble des attaques fonctionnelles par modication du contrle de ot du programme.
L'exprience pratique montre la faisabilit de la mthodologie et valide celle-ci l'chelle
d'un programme. Nous avons ainsi russi implmenter notre technique d'injection d'attaque
sur bzip2 et gzip. En analysant les rsultats exprimentaux obtenus, on peut dire que le modle
d'attaque C simulant les consquences bas niveau d'une attaque physique couvre une partie si-
gnicative de ces attaques. La mthodologie propose permet d'identier l'ensemble des attaques
potentiellement dangereuses au niveau fonctionnel correspondant au modle d'attaque tabli. La
mthodologie permet au dveloppeur de facilement remonter jusqu' l'origine fonctionnelle de
l'attaque et aussi l'aide implmenter et tester une contre-mesure adquate. En utilisant l'outil
dvelopp, un dveloppeur peut aussi tester de manire itrative l'implmentation de ses contre-
mesures jusqu' ce qu'elles deviennent ecaces tout en gardant la garantie qu'aucune attaque
ne compromet son implmentation.
5.7 Perspectives
Cette mthodologie peut servir dans des travaux futurs an d'injecter automatiquement des
contre-mesures au niveau du code source du programme. En eet, la phase d'instrumentation
d'attaque peut tre drive an d'inclure des contrles de scurit ou des contre-mesures. Les
auteurs de [Akkar et al. 2003] prsentent une solution similaire.
La mthodologie propose permet partir d'un test existant de valider son comportement
en cas d'attaque. Il pourrait tre intressant de gnrer automatiquement ces tests en dter-
minant les vecteurs d'entre possibles permettant de simuler la portion de code souhaite. Les
auteurs de [Nori et al. 2009] adoptent une telle approche en associant l'analyse statique, pour la
dcouverte de nouveaux vecteurs de test, associe des tests dynamiques et un algorithme de
ranement successif.
La simulation d'attaques multiples est possible grce la mthodologie propose. Il serait
intressant de caractriser nouveau le code en stimulant des doubles fautes an de caractriser
les formes de code sensibles ce type d'attaques. En eet, ces attaques ont vocation se
gnraliser avec la monte en comptence des attaquants. Disposer d'une caractrisation du
code vis--vis de ces attaques peut aider dans le processus de scurisation du code et la cration
de nouvelles contre-mesures.
Chapitre 6
Outils industriels
Sommaire
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
6.2 Environnent et facteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.2.1 Environnement industriel . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.2.2 Processus de vrication de la scurit . . . . . . . . . . . . . . . . . . . 170
6.2.3 Facteurs prendre en compte . . . . . . . . . . . . . . . . . . . . . . . . 170
6.3 Outils et mthodes existantes . . . . . . . . . . . . . . . . . . . . . . . 171
6.3.1 Domaines similaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.3.2 Cas particulier de la scurit . . . . . . . . . . . . . . . . . . . . . . . . 173
6.3.3 Techniques statiques et dynamiques . . . . . . . . . . . . . . . . . . . . 173
6.3.4 Scurit et absence d'erreurs . . . . . . . . . . . . . . . . . . . . . . . . 173
6.4 Ralisations techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.4.1 Amlioration de la relecture de code . . . . . . . . . . . . . . . . . . . . 175
6.4.2 Amlioration de la tracabilit fonctionnelle . . . . . . . . . . . . . . . . 175
6.4.3 Vrication de formes de code . . . . . . . . . . . . . . . . . . . . . . . 176
6.4.4 Injection simple et exhaustive d'attaques . . . . . . . . . . . . . . . . . 177
6.4.5 Analyse et interrogation interactive du code source . . . . . . . . . . . . 181
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.1 Introduction
Dans ce chapitre, nous prsentons les ralisations complmentaires eectues au cours de
cette thse. Ces ralisations rpondent de manire outille des besoins en termes de scurisa-
tion de code source dans un environnement industriel. Tout d'abord, en section 6.2, nous donnons
quelques lments de contexte an de mieux cerner les raisons qui ont men la ralisation de
tels outils. Puis, en section 6.3, nous prsenterons direntes mthodes et outils existants permet-
tant de rsoudre des problmes de scurit. Finalement, dans la section 6.4, nous prsenterons
les solutions techniques ralises dans le cadre industriel au cours de cette thse qui contri-
buent amliorer le processus de scurisation de code embarqu. Les contributions couvertes
dans ce chapitre font rfrence aux publications [Chambrot & Kaumann-Tourkestansky 2009]
et [Berthom et al. 2011]. Ces deux contributions sont d'ordre industriel en montrant comment
des mthodologies labores dans les contributions prcdentes ont pu tre mises en uvre dans
un environnement industriel.
170 Chapitre 6. Outils industriels
6.2 Environnent et facteurs

Avant de prsenter les ralisations techniques dveloppes dans le cadre industriel au cours
de cette thse, il convient de donner un aperu de l'environnement industriel embarqu dans
lequel cette thse s'est droule.
6.2.1 Environnement industriel

Tout d'abord, prsentons quelques mtriques sur les projets embarqus voqus dans cette
thse. Ces projets reprsentent l'ensemble du code source du systme d'exploitation d'une carte
puce et de ses applications. Ils sont compos d'environ 100 000 200 000 LOC programms
en langage C. Les projets Java Card ne sont pas abords dans cette thse et aucune ralisa-
tion technique n'a t eectue dans ce cadre. Cependant certaines techniques gnriques mises
au point peuvent tre adaptes d'autres langages et des environnements de dveloppement
dirents.
L'environnement de dveloppement dans le cadre de cette thse est Microsoft Visual Stu-
dio 2005. Dans une premire phase de dveloppement, un projet sous forme de DLL est d'abord
cr et interfac avec une solution de simulation de terminal propritaire. Le projet sous cette
forme permet des tests et des corrections sur plusieurs itrations du cycle de dveloppement.
Une fois le projet avanc, dans une deuxime phase de dveloppement, ce projet est port sur
l'environnement propritaire du fondeur (en utilisant KEIL ou un autre environnement de dve-
loppement) et de nouvelles itrations du cycle de dveloppement sont faites en parallle avec ces
deux projets. Finalement, un binaire nal est livr au fondeur qui l'embarque sur le composant
rel.
6.2.2 Processus de vrication de la scurit

Dans ce processus de dveloppement, la vrication de la scurit se prsente sous la forme de
plusieurs relectures de code faisant intervenir le dveloppeur qui a implment la solution logiciel
et l'expert en scurit. Le premier a la connaissance des besoins fonctionnels de l'application sur
laquelle il travaille et donc du code qu'il a dvelopp ; le second est jour vis--vis des dernires
attaques physiques existantes et des chemins d'attaques associs. Des tests scuritaires sont aussi
raliss dans la deuxime phase de dveloppement pour s'assurer que les contre-mesures mises
en place sont bien dclenches lors de la dtection d'une attaque physique. Ces tests demandent
qu'un dveloppeur dbogue son application et modie manuellement au moment de l'excution
une instruction pour simuler une attaque.
Avec les ralisations techniques de cette thse, un des buts est d'amliorer le processus de
scurisation mis en place tout en prenant en compte les facteurs industriels existants.
6.2.3 Facteurs prendre en compte

Plusieurs contraintes industrielles ont t prises en compte lors de la cration ou l'intgration
d'outils visant amliorer le processus de scurisation.
6.3. Outils et mthodes existantes 171
Les facteurs environnementaux

Des facteurs environnementaux ont conditionn des choix sur les outils mettre en uvre
dans le cadre industriel de cette thse. Tout d'abord l'environnement propritaire du fondeur
ne peut pas tre modi. Celui-ci est bas sur un compilateur propritaire et spcique au
composant utilis. Par consquent, toute scurisation base sur une modication du compilateur
n'est pas envisageable ; tout comme la modication du binaire a posteriori de la compilation.
En cas de dcouverte d'une faille scuritaire, il aurait t dicile de distinguer si l'origine du
problme se situait dans le code d'origine ou le code rajout par le compilateur. Une telle solution
est galement dicile maintenir. Ces contraintes ont pouss la cration d'outils intervenant
avant la compilation c'est--dire sur le code source C du programme.
Des contraintes lies au contexte embarqu sont aussi entres en jeu dans la conception des
outils d'aide la scurisation. Parmi celles-ci, le haut niveau d'optimisation d'un code embarqu
(par un compilateur propritaire) rend dicile la rtro ingnierie ou des formes de dcompilation
de code assembleur. De plus, des contraintes lies la rutilisation de code existant ainsi que
la rapidit de dveloppement demand dans un march concurrentiel ont aect le cahier des
charges des outils dvelopps.
Les facteurs techniques

En plus de ces facteurs environnementaux, dirents facteurs techniques sont aussi inter-
venus. Ces facteurs techniques se rsument essentiellement des considrations de passage
l'chelle d'outils existants ou de mthodes de scurisation. Un autre facteur important est l'qui-
libre entre la pertinence des rsultats fournis et l'utilisabilit des outils.
Si un grand nombre de techniques de rsolution existent dans la littrature, toutes n'ont pas
encore t adaptes de manire viable dans un contexte industriel.
Les facteurs humains

L'utilisabilit d'un outil repose sur les utilisateurs de celui-ci. Certains paramtres entrent en
jeu comme la courbe d'apprentissage, la charge de travail ncessaire an d'obtenir des rsultats
pertinents. Ces paramtres se traduisent en une rticence vis--vis de l'adoption de l'outil dans
les habitudes de travail dans un environnement industriel.
L'ensemble de ces facteurs a t pris en compte dans les ralisations techniques eectues
en milieu industriel au cours de cette thse. Dans la majeure partie des cas, un quilibre a t
trouv an de mitiger l'eort et d'amener progressivement vers des rsultats pertinents.
6.3 Outils et mthodes existantes

6.3.1 Domaines similaires
Direntes techniques permettant une validation ou une vrication de la scurit existent.
La validation implique l'utilisation d'un oracle qui juge en fonction de l'observation d'un
rsultat obtenu si une garantie souhaite est obtenue. Il s'agit bien souvent de rsultats pratiques
obtenus lors de tests.
La vrication quant elle implique une modlisation faisant apparaitre la totalit des l-
ments (et uniquement ceux-ci) entrant en jeu dans la rsolution d'une garantie ainsi que la
rsolution eective de cette garantie dans tous les scnarii possibles envisags. On obtient ainsi
une preuve de la garantie souhaite. Il s'agit dans ce cas bien souvent d'une preuve au sens
mathmatique.
Ce travail ralis dans cette thse touche plusieurs secteurs concerns par l'eet que peut
provoquer une faute sur le fonctionnement de leur systme. Le contexte d'utilisation, les priorits
fonctionnelles et les consquences scuritaires ne sont cependant pas les mmes. Les secteurs lec-
trique et lectronique cherchent assurer le bon fonctionnement de leur systme an d'assurer
une continuit de service. En aronautique, les systmes ne sont pas confronts des attaquants
malicieux mais des facteurs environnementaux extrmes ; par contre la panne de fonctionne-
ment d'une partie ou la totalit d'un systme peut avoir des consquences dsastreuses comme la
perte de vies humaines ce qui implique une recherche extrmement pousse des erreurs de fonc-
tionnement voire une preuve de l'absence de ceux-ci. Finalement en embarqu, l'attaquant est
malicieux et cherche modier le comportement du code an de l'avantager dans une situation
o il ne doit pas l'tre.
On retrouve des besoins similaires dans plusieurs autres domaines de recherche :
les codes correcteurs d'erreur ;
le test de programmes ;
la scurit logicielle et contre-mesures associes ;
le Model Checking ;
l'analyse et vrication de programme.
Les codes correcteurs sont utiliss an de garantir une continuit de fonctionnement dans
des conditions o le systme peut tre amen transmettre un signal dont l'intgrit peut tre
compromise. Dans le cas de la scurit embarque le ot d'excution est vis par un attaquant. Le
test des programmes joue ici aussi un rle majeur dans la validation des programmes embarqus.
En eet, tester en situation relle est souvent le seul moyen d'avoir une conrmation sur le terrain
du code. Cependant, les tests de scurit exhaustifs ne sont pas forcment ralisables dans ces
conditions cause de l'explosion combinatoire qui en rsulte.
Il faudrait tester l'ensemble des scnarii possibles sur l'ensemble du code quelle que soit l'at-
taque envisage et ce pour toutes les attaques possibles. Ce travail s'apparente de la vrication
exhaustive d'un programme dans un cadre de suret. Or, pour la scurit, on ne s'intresse qu'aux
cas qui peuvent avantager l'attaquant. Le but nal tant d'implmenter les contre-mesures ap-
propries l'intrieur du code sans sacrier les performances. Un moyen de vrier certains
aspects de fonctionnement d'un systme est d'utiliser le Model Checking ce qui permet de vri-
er certains comportement d'un systme bas sur une modlisation de celui-ci faisant apparaitre
seulement certaines caractristiques pertinentes vis vis de la vrication souhaite.
La problmatique associe cette approche est qu'on est aussi souvent confront l'explosion
combinatoire mentionne prcdemment. La dernire approche et aussi la plus forte en terme de
garanties obtenues est la preuve de programme qui est le dernier domaine de recherche associe
ce travail. La preuve de programme consiste modliser l'aide de formules / d'quations
mathmatiques le fonctionnement et le comportement d'un programme et de ensuite rsoudre ces
quations l'aide d'un solveur an de prouver que le fonctionnement du programme correspond
bien au comportement souhait.
Chacune de ces approches vient avec un cot en terme d'implmentation et de complexit
6.3. Outils et mthodes existantes 173
qu'il convient de prendre en compte et d'valuer avant d'envisager son intgration un processus
de dveloppement et un environnement existant.
6.3.2 Cas particulier de la scurit

Parmi ces domaines, une dirence fondamentale existe qui direntie les techniques d'injec-
tion d'attaques et la recherche de vulnrabilit de la validation ou vrication de la scurit.
La dirence majeure entre la recherche de vulnrabilits et la validation ou vrication

de la scurit par l'absence de ces vulnrabilits se trouve dans le processus de recherche. Un
attaquant se trouve souvent dans la premire conguration tandis qu'un dfenseur se trouve
dans la seconde. Typiquement, un attaquant arrte sa recherche aprs avoir trouv la premire
vulnrabilit tandis que le dfenseur doit en thorie toutes les trouver.
6.3.3 Techniques statiques et dynamiques

Un autre critre de direnciation des techniques existantes est l'approche base sur une
analyse statique du code source ou une excution dynamique de celui-ci. Les approches statiques
sont gnralement plus faciles mettre en uvre mais des rsultats prcis sont diciles obtenir
car le contexte d'excution doit tre suppos. Les approches dynamiques sont plus prcises
en terme de pertinence des rsultats fournis mais en fonction du systme peuvent tre trs
coteuses en temps d'excution. Des solutions hybrides existent mais ncessitent une adaptation
au contexte industriel et la chaine de compilation utilise. Si celle-ci est modie, une nouvelle
adaptation doit tre eectue.
6.3.4 Scurit et absence d'erreurs

Un grand nombre d'attaques exploitent des erreurs prsentes dans le code. C'est le cas des
dbordements de tampon mais ce cas peut tre gnralis la plupart des vrications ncessaires
pour viter un comportement incontrl du programme. Ainsi liminer les erreurs dans le code
peut amener un renforcement de la scurit. Vrier l'absence d'erreurs peut tre fait en
vriant l'absence de certaines fonctions risque, formes de code sensibles ou bien la prsence
de la vrication adquate place au bon endroit. Dans le cadre des attaques physiques, un
raisonnement similaire peut tre fait car certaines formes de code peuvent tre sensibles vis--
vis des attaques physiques o l'absence de vrication peut entrainer dans l'hypothse d'une
faute une vulnrabilit.
Dirents outils existent permettant ces vrications.
Les outils propritaires

Des outils comme Fortify [HP 2012], Klockwork [Klockwork 2012] ou Parasoft [Parasoft 2012]
ou Goanna [Fehnker et al. 2006] permettent des vrications du type de celles mentionnes ci-
dessus. Cependant, si de tels outils ont fait leurs preuves vis--vis de certaines vrications,
leur but reste la dtection d'erreur dans le code par la validation, ils ne sont pas spcialiss
dans la validation ou la vrication de proprits de scurit dans le cadre d'attaques physiques.
De plus, dpendre d'une solution propritaire pour la scurisation de code peut tre rdhibitoire
dans certains cadres industriels. Finalement, la conguration de l'outil pour fournir des rsultats
pertinents rpondant aux questions de scurit embarqu contre des attaques physiques demande
un eort et un maintien coteux. Ainsi ces outils n'ont pas t retenus bien qu'ils puissent
amliorer la qualit du code.
Les outils non propritaires

Certains outils libres, gratuits ou acadmiques existent aussi pour la vrication de la scurit
du code source. Parmi ceux-ci, on peut citer :
Splint [Evans & Larochelle 2002] qui fournit par analyse statique des informations sur des
potentielles erreurs de codage et l'utilisation de fonctions risque. Il peut l'aide d'annotations
fournir des informations sur la propagation et la non interfrence entre deux variables. Son
utilisation s'intgre bien avec des chaines de compilation comme Gcc mais est dicilement
adaptable pour passer l'chelle sur des projets utilisant une autre chaine de compilation.
CppCheck [Marjamki 2012] vrie un certain nombre de rgles de codage en analysant

statiquement le code source. Facile d'utilisation, il n'est cependant pas facilement modiable
pour vrier d'autres rgles.
Sonar [Bellingard et al. 2012] vrie des rgles de codage en analysant statiquement le
code, il peut facilement tre paramtr pour vrier de nouvelles rgles mme si ces rgles sont
limites aux interfaces fournies par l'outil. Il demande cependant tre intgr une chaine de
compilation spcique et s'adapte mal aux chaines de compilation propritaires.
Frama-C [Baudin et al. 2012] dvelopp par le CEA, cet outil d'analyse statique par inter-
prtation abstraite permet de vrier l'absence d'erreurs et aussi de prouver certaines proprits
grce un langage d'annotation acsl. Dlicat prendre en main, il passe cependant trs bien
l'chelle grce la cration abstraite de fonctions de substitution pour le code manquant. Pour
eectuer des vrications sur l'ensemble du code d'un projet embarqu, une adaptation doit
cependant tre faite et une puissance de calcul consquente est ncessaire pour mener bien ces
vrications. Des outils valus, FramaC semble le plus prometteur bien qu'il n'intgre pas de
vrications lies des fautes physiques. Un eort d'adaptation a donc t fait pour permettre
l'analyse de projets grce cet outil qui est utilis dans le chapitre 4. Bien qu'il soit ncessaire,
le cot de la cration et du maintien des annotations sur l'ensemble d'un projet pose cependant
un problme dans un contexte industriel, ce qui conne son utilisation un sous-ensemble d'un
projet.
Pour une liste exhaustive des outils d'analyse statique existant pour le C, le lecteur peut se
rfrer [Spinroot 2012]. D'autres outils notamment acadmiques existent pour la vrication,
par exemple d'implmentations cryptographiques, mais l'accs rduit aux sources, les contraintes
d'utilisation ou un passage l'chelle dlicat font qu'ils ne sont pas mentionns ici. Les plates-
formes d'injection de fautes ne seront pas non plus couvertes ici car elles agissent principalement
sur le binaire rsultant de la compilation ce qui ne rpond pas une contrainte industrielle tablie
prcdemment. De plus, celles-ci sont souvent confrontes des problmatiques de passage
l'chelle dans le chapitre 5. Aprs avoir vri si une solution existante ne pouvait pas tre utilise
ou drive an de permettre de rpondre aux besoins de scurisation industriel, une solution
6.4. Ralisations techniques 175
spcique a t conue et implmente. Cette solution technique se dcompose en l'utilisation

de plusieurs outils intervenants des niveaux dirents dans le processus de scurisation tout
en visant amliorer celui-ci.
6.4 Ralisations techniques

Ces outils se dcomposent en deux types d'outils. Les outils d'analyse permettent de com-
prendre et d'isoler des portions de code critique du point de vue de la scurit. Les outils de
scurisation permettent d'valuer ce code vis--vis d'attaques physiques.
6.4.1 Amlioration de la relecture de code

An d'aider la relecture de code en cernant le cadre de celle-ci l'aide de listes de questions
servant de rappel, un outil a t slectionn et modi an de pouvoir tre utilis dans le contexte
industriel. Agnitio [Rook 2011] permet une liaison entre le code source et des besoins en scurit
exprims sous forme de question. L'utilisation de cet outil permet de cadrer pertinemment le
travail du dveloppeur et de l'expert de scurit en charge de la revue du code source. Les
gures 6.2 et 6.1 illustrent l'interface de cet outil.
Figure 6.2 volution du code au cours des

Figure 6.1 Liste de vrication dans le code
revues
6.4.2 Amlioration de la tracabilit fonctionnelle

Tel que mentionn dans le chapitre 1 section 1.3.7, une approche fonctionnelle est adopte
pour modliser la scurit. Cette approche fonctionnelle se justie par le fait que la scurit
a souvent un sens ce niveau puisque le gain pour l'attaquant mentionn dans le chapitre 1
section 1.3.7 s'exprime aussi ce niveau. De plus, l'implmentation de la tche fonctionnelle est
faite dans les sources par le dveloppeur qui est le plus en mesure de comprendre le raisonnement
derrire le code implment. Russir tablir une tracabilit des objectifs fonctionnels jusque
dans le code source permet non seulement une meilleure matrise du code dans sa rponse aux
exigences fonctionnelles mais aussi une meilleure comprhension du code par les autres personnes.
Par consquent un meilleur maintien de celui-ci notamment du point de vue de la scurit est
assur.
An de permettre une documentation du code source et l'ajout d'informations liant une
partie du code sa demande fonctionnelle ou faisant apparatre l'implmentation d'une contre-
mesure scuritaire, le logiciel Doxygen [van Heesch 2008] a t utilis. Ce programme analyse
le code source et gnre une documentation structure de celui-ci en faisant apparatre des
lments annots. Des programmes annexes ont t dvelopps en python pour minimiser l'eort
ncessaire pour annoter les lments requis. Ces outils annexes sont bass sur l'analyse du code
source et l'injection de cartouches prremplis contenant des informations extraites du code et
requis par Doxygen. L'utilisation de ces outils permet une documentation ecace du code source
et les documentations gnres peuvent tre utilises pour aider l'identication des points
sensibles du code ou la certication de l'implmentation de scurit. Les documentations
gnres ont, de manire pratique, t utilises dans la justication semi-formelle [Lanet 2000]
de telles implmentations. La gure 6.3 illustre l'interface de cet outil.
Figure 6.3 Exemple de documentation gnre avec Doxygen
6.4.3 Vrication de formes de code

Comme les dirents outils mentionns en section 6.3.4, la vrication de l'absence de cer-
taines formes de code ou de la prsence de scurit peut aider la scurisation du code source.
D'autres outils bass, sur l'interprtation abstraite et utilisant la plate-forme modulaire de
Listing 6.1 Exemple de code pour catgorisation par mots cls
static void foo(int k) 1

{ 2
j = pin && pin_cpt || q; 3
write_EEPROM(j); 4
return j; 5
} 6
Frama-C, permettent galement d'eectuer des vrications de formes de code ou de ot d'infor-
mation [Delmas et al. 2010] [Cuoq et al. 2012]. l'aide d'une analyse approfondie, ces derniers
permettent d'obtenir des rsultats sans faux positifs.
Ces outils ont cependant t crs dans une optique de suret de fonctionnement et non de
scurit. Du point de vue de la scurit, la recherche et validation de formes de code a pour
but d'viter l'utilisation de constructions vulnrables aux fautes physiques. An de valider des
rgles de codage de scurit propres Oberthur Technologies, un outil d'analyse bas sur la
reconnaissance de formes de code a t dvelopp. Les formes de code sont dduites de l'arbre
de syntaxe abstrait (AST) du programme. Cet outil utilise Pycparser [Bendersky 2012] pour
la cration des AST. En se basant sur des formes de code connues, l'outil identie ces formes
ou squences de formes l'intrieur de l'intgralit du code source du programme et propose
l'utilisateur une liste de candidats potentiels (extrait de code possdant une vulnrabilit
potentielle) en donnant la raison de la slection du candidat en question.
Des catgories de motifs labelliss sont crs pour guider les analyses. Par exemple, *pin
*::confidentiel ou write_*::api_ecriture pour signier qu'un lment de code (variable ou
fonction) contenant le motif pin appartient la catgorie condentiel respectivement que tout
lment de code commenant par write_ appartient la catgorie des interfaces d'criture. A
partir du code du listing 6.1, l'arbre de syntaxe abstrait du listing 6.2 est cr. Les catgories
cres sont retes sur l'AST et guident ainsi les analyses en dclenchant la recherche d'une
nouvelle catgorie ou une analyse l'endroit de la dcouverte de la catgorie.
La dcouverte d'une de ces catgories ou d'une squence ordonne de catgories dans l'AST
dclenche des vrications supplmentaires comme la recherche de nouvelles catgories ou des
vrications annexes. Cet outil permet de vrier un grand nombre de rgles de scurit comme
par exemple si des constantes risque sont utilises, qu'une forme de code risque manipulant
un objet sensible est utilise, qu'une rponse scuritaire se trouve aprs une criture en eeprom
ou que des conditions identiques sont utilises une distance trop proche (et sont vulnrables
des doubles attaques). La prsentation des rsultats est ralise l'aide de Sphinx [Brandl 2012].
La gure 6.4 illustre un exemple de rsultats gnr par l'outil.
6.4.4 Injection simple et exhaustive d'attaques

Un outil d'injection d'attaque a t dvelopp de manire pouvoir tre intgr au processus
de dveloppement existant ainsi qu' la chaine de compilation. Cet outil devait aussi passer
l'chelle en terme de temps d'excution des tests. Tout d'abord une mthode d'injection simple
paramtrable et pouvant tre stimule depuis le terminal l'aide d'une commande spcique a
t dvelopp. Cet outil utilise une base d'attaques dcompose en motif d'injection et morceau
de code stimulant l'attaque. Le dveloppeur peut alors inclure un ou plusieurs motifs d'injec-
Figure 6.4 Exemple de rsultats obtenus par l'outil

Listing 6.2 Exemple de code pour catgorisation par mots cls
FileAST : 1
FuncDef : 2
Decl : foo , [ ] , [ s t a t i c ] , [ ] 3
FuncDecl : 4
ParamList : 5
Decl : k , [ ] , [ ] , [ ] 6
TypeDecl : k , [ ] 7
IdentifierType : [ int ] 8
TypeDecl : foo , [ ] 9
I d e n t i f i e r T y p e : [ void ] 10
Compound : 11
Assignment : = 12
ID : j 13
BinaryOp : | | 14
BinaryOp : && 15
ID : p i n confidentiel 16
ID : p i n _ c p t confidentiel 17
ID : q 18
FuncCall : 19
ID : write_EEPROM api_ecriture 20
ExprList : 21
ID : j 22
Return : ID : j 23
tion dans les commentaires de son code et l'outil les remplace par le morceau de code associ.
Un mcanisme utilisant une variable globale de dclenchement est gr an de pouvoir inclure
conditionnellement l'ensemble des morceaux de code d'attaque. Une commande avec une syntaxe
spcique peut ensuite tre utilise pour dclencher au moment de l'excution du programme
une ou plusieurs attaques. En combinant cette mthode avec les contributions du chapitre 4,
une campagne de test ecace contre les attaques par modication de valeur peut tre cre.
Cependant avec cette mthode, les attaques injectes simulent non seulement des modications
de variables des valeurs spciques mais aussi des sauts de code intra-fonction. La mthode
ncessite par contre des annotations de la part du dveloppeur. Cette mthode prsuppose donc
de la part du dveloppeur une ide pralable des attaques susceptibles de mettre en danger son
code.
Dans le cas d'un projet inconnu, Frama-C peut tre utilis pour analyser le code et dter-
miner des points d'attaques potentiels. partir de ces points d'attaque, le dveloppeur peut
ensuite positionner dans le code des attaques simules et observer l'eet de celles-ci. Frama-C
peut servir simuler ces attaques en drivant l'utilisation du mcanisme d'annotation. Il peut
cependant aussi servir vrier l'appartenance un ensemble de valeur pour une variable don-
ne un point du programme. La gure 6.5 montre l'interface de Frama-C. On peut voir au
milieu le code original et droite une version prprocesse de celui-ci. En se positionnant
un point du programme, par exemple une fonction, on peut, aprs avoir eectu une analyse
de valeur, connatre l'ensemble des variables modies par cette fonction avec une profondeur
d'appel paramtrable. On peut ainsi savoir si une fonction manipule une variable sensible, ce
qui peut guider une attaque. L'interface permet aussi de dterminer les impacts dans le reste
du programme d'une instruction et donc d'une modication de celle-ci. La gure 6.6 illustre une
telle analyse d'impact. Dans le panneau de gauche, on peut voir l'impact sur les fonctions du
programme tandis que le code impact dans le corps de la fonction est surlign en vert. Les eets
des attaques simules peuvent tre analyses par ces mmes moyens. En utilisant la mthode
dveloppe dans la section 4.3 du chapitre 4, il est possible de dterminer l'ensemble des points
d'attaque possibles pour une variable.
Figure 6.5 Frama-C - Analyse de code
Figure 6.6 Frama-C - Impact d'une instruction
Injecter exhaustivement des attaques permet de s'aranchir de la connaissance pralable

de chemins d'attaque et potentiellement d'en dcouvrir de nouveaux. Dans le cas d'attaques
par sauts, un outil a t dvelopp an de permettre de simuler exhaustivement l'ensemble des
sauts possibles l'intrieur d'une fonction. Cet outil bas sur les contributions du chapitre 5,
permet de tester sans connaissance pralable un code contre des attaques par saut de code.
Cette mthode utilise une instrumentation de chaque instruction d'une fonction avec un couple
de label et goto. Ces couples sont encapsuls dans des directives de compilation conditionnelle ce
qui permet de dclencher un ou plusieurs sauts par excution. Une variable systme est utilise
pour enclencher la compilation d'un goto source et d'un label de destination. Une fonctionnalit
de compilation incrmentale de Visual Studio est utilise pour ne compiler que le chier du
projet qui est modi et acclrer les tests. Des optimisations additionnelles sont ralises
partir d'une excution pralable du scnario de test choisi qui permet l'aide de la couverture
de code de la fonction d'liminer les tests inutiles (car le goto source ne se trouve pas parmi les
lignes de code excutes). L'ensemble du processus est automatis l'aide de scripts. Avec cette
mthode, le dveloppeur a seulement choisir la fonction qu'il veut tester an de dclencher
les campagnes d'attaques. Une campagne de test sur une fonction d'environ 200 LOC prend
avec cette mthode entre 5 et 6 heures sur une machine de bureau standard (Dell Latitude
D630). En fonction de la chaine de compilation utilise et des performances de la machine hte,
ces rsultats peuvent varier. Une reprsentation visuelle des rsultats catgoriss a t ralis
l'aide de Ploticus [Grubb 2012]. Cette mthode permet de couvrir indirectement un grand
nombre d'attaques par valeur modiant le contrle de ot du programme. Ainsi l'intgralit
des attaques sur des variables impliques dans des conditions sont testes avec cette mthode
d'une manire beaucoup plus ecace qu'en injectant toutes les attaques possibles au niveau
assembleur. Des rsultats d'une telle campagne sont donns dans la section 5.5 du chapitre 5.
6.4.5 Analyse et interrogation interactive du code source

tant donn que la mthode prcdente teste exhaustivement toutes les combinaisons de
saut possibles l'intrieur d'une mme fonction, le dveloppeur doit quand mme spcier quelle
fonction doit tre instrumente pour l'injection d'attaques par saut. Pour simplier ce processus,
un outil a t dvelopp an d'instrumenter a priori l'intgralit du code avec des instructions
permettant de consigner dans un chier une trace des fonctions appeles l'excution du scnario
choisi. Le dveloppeur peut ainsi utiliser cette trace an de spcier les fonctions qu'il veut
instrumenter.
Ainsi le dveloppeur peut tester un chemin d'attaque contre l'ensemble des attaques par saut
possibles. Cependant, tant donn une fonction ou une opration dans l'intgralit du code d'un
projet, il ne peut pas encore connatre l'intgralit des chemins d'attaque permettant d'atteindre
ce point. Cet ensemble peut uniquement tre obtenu en analysant de manire discrte la totalit
des chemins d'appels du programme concerns par cette fonction ou cette opration. Des outils
comme PathCrawler [Williams et al. 2005] dispose des fonctionnalits ncessaires pour raliser
de telles analyses mais les sources n'tant pas disponibles et an de garder une cohrence avec le
reste des outils dvelopps, une solution spcique a t dveloppe. L'auteur de [Andouard 2009]
utilise une reprsentation similaire base sur le graphe d'appel du programme sur lequel des
proprits de logique temporelles peuvent tre vries. Ces proprits temporelles permettent
de s'assurer que des squences d'appels sont bien respectes. L'ergonomie de l'outil en question
est plus abouti que celui ralis dans le cadre de cette thse. Cependant, les sources n'tant
galement pas disponibles et an de garder une cohrence avec le reste des outils dvelopps, une
solution alternative accessible par simple ligne de commande a t ralise. Cet outil se base sur
une reprsentation sous forme de graphe d'appels de l'ensemble des AST de chaque fonction du
programme. Il permet un parcours du graphe d'appels tout en disposant d'informations propres
l'AST. Le dveloppeur peut alors l'aide d'une syntaxe simple, visible dans le listing 6.3
dterminer l'ensemble des chemins d'attaques possibles menant la fonction VIS_VerifiyPin

l'aide d'une simple ligne de commande.
Listing 6.3 Explorateur interactif de code source en ligne de commande
cbrowser . py f V I S _ V e r i f y P i n P v 1
# f : fonction 2
# P: parents r e c u r s i v e l y in callgraph 3
# v : c r e a t e v e c t o r s , i . e . , a l l d i s t i n c t i v e paths 4
Un chier de sortie est cr contenant l'ensemble des chemins (un chemin par ligne) sous la
forme visible dans le listing 6.4.
Listing 6.4 Exemple de chemins obtenus dans le graphe d'appel du programme
V IS _ Ve r if yP I N < parent 1 < parent 2a . . . 1

V IS _ Ve r if yP I N < parent 1 < parent 2b . . . 2
... 3
V IS _ Ve r if yP I N < parent 1a < parent 2 . . 4
D'autres options permettent interactivement d'obtenir des informations direntes comme

l'ensemble des ls et les chemins associs, l'ensemble des chemins d'une fonction une autre du
programme, de ltrer les lments de sortie en utilisant des expressions rgulires, de faire appa-
ratre des lments de l'AST et mme de lancer des analyses comme la recherche d'une squence
particulire parmi les chemins d'attaque ou acher l'ensemble des variables impliques dans
des conditions sur un chemin d'attaque prcis. Il est aussi possible d'obtenir une reprsentation
graphique du graphe d'appels demand l'aide de Graphviz [Ellson et al. 2003] qui est visualis
l'aide de ZGRViewer [Pietriga 2005]. La visualisation supporte dirents algorithmes de dis-
position des nuds ce qui permet de contrler la sortie obtenue. Lors de la cration des graphes,
la possibilit de catgoriser et colorier des groupes de nuds est aussi oerte. Ces groupes repr-
sentent des fonctions dont le nom rpond une expression rgulire dtermine. Ainsi, on peut
facilement distinguer les fonctions appartenant un mme module si toutes les fonctions de ce
module commencent par la mme chaine de caractre. Par exemple, VIS_ pour les fonctions
du module VISA. A l'aide de cet outil, un dveloppeur peut amliorer sa connaissance du code
mais surtout guider pertinemment des analyses et des tests de son programme d'un point de vue
scuritaire. Grce ces fonctionnalits, cet outil est capable de rduire la complexit d'un projet
une chelle comprhensible par le dveloppeur l'aide de quelques requtes. Un exemple est
fourni avec les gures 6.7 et 6.8 o le programme entier d'une carte puce est progressivement
rduit pour ne faire gurer qu'une partie restreinte du code. Les requtes permettant d'obtenir
ces graphes sont donns dans le listing 6.5. Par rapport une simple lecture de code, une telle
reprsentation graphique apporte une vision haut niveau du systme scuriser. En ranant
progressivement ses requtes, le dveloppeur est capable de faire apparatre de manire inter-
active les seuls lments intressants dans son raisonnement. Cette solution ore une mthode
d'approche et de recherche alternative aux rapports d'erreurs.
OS
OS_GetRecordBinaryB1
OS_GetRecordBinaryB0
OS_CreateCyclicEFBody
OS_CreateDFOrEF
OS_CreateMF
OS_CreateDFOrEFHeader
OS_CheckP3
OS_SelectMF OS_LoadFileHeader
OS_SelectFileByEFID
OS_GetRemainingByte
OS_RestorePreviousSelectedContext OS_SelectFile
OS_GetBinaryFileError
OS_InitJournalBeforeCommand OS_ClearDataForXDataRam
OS_CommonSelectFileAndApplication
OS_PushKillCard OS_ClearPublicRamVariables
OS_SendData OS_CheckAccessCondition OS_GetLock OS_GetLockandMirror

BC
OS_GetEmvLengthField OS_UpdateBinary OS_WriteSecureLock OS_ClearDesKey

BC_SelectFile
OS_GetRecord OS_InitLock OS_ActivateDesKey OS_ClearAllDesKey

BC_ReadBinaryB1
BC_ReadBinaryB0
BC_CreateFile BC_UpdateBinaryD7Part1
BC_ReadRecord BC_UpdateBinaryD6Part1
BC_UpdateBinaryD7 BC_CommonReadRecord
BC_EraseCard BC_UpdateBinaryD7Part2
BC_UpdateBinaryD6 BC_UpdateBinaryD6Part2
LOC
LOC_DisableEraseCardCommand
LOC_SelectApplicationByAID
LOC_SendSelectFileResponse
LOC_SelectApplicationByPSEOrPPSE
LOC_FindAndSelectEFIDForAnAID
LOC_EraseCard
LOC_SearchDesKeyFile
LOC_LoadEepromDesKey
LOC_EnableEraseCardCommand
ECP
ECP_InitECPDispatcher ECP_CheckPersoMAC ECP_DesactivateGoodKeyOrSessionKey
ECP_SecurityLevelVerification ECP_DecryptWithCBCMethod ECP_ActivateGoodKeyOrSessionKey
Figure 6.7 Rduction progressive de la complexit du programme par interrogation du graphe

d'appels
VIS_VerifyPIN
EMV_VerifyPIN OS_GetObjectXdata OS_BlockApplication OS_SetObjectXdata
EMV_RecoverEncipheredPIN EMV_SetPtcToPtlValue OS_GetObjectGeneric OS_SetObjectGeneric
OS_ActivateRsaKey OS_GetPinReference EMV_VerifyPinFormat OS_SetPtc LOC_PositObject LOC_BlockApplicationByApplicationNumber
OS_ModifySecretRecord LOC_LoadEepromRsaKey OS_GetPtcPtl OS_SelectFile OS_ForceWritingLinkedData
OS_DesactivateRsaKey OS_CheckDesSecureChecksumInEeprom LOC_SearchRsaKeyFile OS_RaiseErrorP1P2Incorrect
OS_GetDesSecureChecksumInEeprom OS_GetDesSecureChecksumInRam LOC_GetRsaRecordData OS_PopKillCard OS_InitJournal
OS_SecureObjectEncryptAndDecryptFromEeprom OS_ReadEepromDesKeyByte OS_DesactivateDesKey OS_ActivateDesKey
OS_RsaCryptographicServices OS_ReadNBytes OS_CheckSecureChecksumForSecretObject LOC_LoadEepromDesKey
LOC_GetDesKeyRecord LOC_SearchDesKeyFile LOC_GoDesKIDNumber OS_LoadFileHeader
LOC_KMCAction OS_GetLock OS_SearchFile OS_GoRecordNumber
OS_CheckNoDanger OS_ClearSpecificDesKey OS_GetLockandMirror OS_SaveData
OS_PositDanger OS_SecureObjectEncryptAndDecryptFromRam LOC_RamToJournal LOC_RamToEeprom
LOC_GoFirstRecordOfSecretRecord LOC_JournalToEeprom LOC_FormatAndWriteToJournal SecurityStartSection
OS_PositNoDanger OS_FlushCache OS_RaiseErrorFileNotFound
OS_CheckRecord OS_MuteCard OS_SendFirstEmvByte
OS_GoToSimMask OS_CheckForSendingSecurityATRBytes OS_WriteNBytes
SecurityKillCardDelayedWithReason OS_SendByte OS_NextRecord
SecurityBeforeSending LOC_FindJournalPriorRecord OS_RaiseErrorWrongFormatObjectInDataField
LOC_NextRsaKPID SecurityKillCardNow OS_LoadFirstRecord
SecurityReset OS_WriteByte OS_RaiseErrorCommandSequenceError
OS_RaiseErrorSW1SW2AlreadySet OS_RaiseErrorRecordNotFound OS_RaiseErrorLcIncorrect
SecurityKillCardNowWithReason OS_RaiseError
SecurityEndSection
SecurityKillCardDelayed
SecurityKillCard
OS
OS_WriteByte
OS_FlushCache
OS_MuteCard OS_SendFirstEmvByte OS_RandomTimeWaiting
OS_GoToSimMask OS_CheckForSendingSecurityATRBytes OS_SimulMuteCardOnDll
OS_RaiseErrorSW1SW2AlreadySet OS_SendByte
OS_RaiseError
MISC
SecurityBeforeSending SecurityEndSection longjmp Send SecurityKillCardDelayedWithReason
SecurityReset SecurityKillCard
OS
OS_RaiseErrorSW1SW2AlreadySet
OS_RaiseErrorCommandSequenceError
VIS
VIS_VerifyPIN OS_RaiseErrorLcIncorrect OS_RaiseError
OS_RaiseErrorP1P2Incorrect
Figure 6.8 Rduction l'chelle d'un module puis d'un ensemble de fonctions
Listing 6.5 Commandes utilises pour crer les graphes
# dtermine l ensemble des i n t e r f a c e s du module du systme d e x p l o i t a t i o n 1

cbrowser . py f OS_ p g 2
3
# dtermine l ensemble des i n t e r f a c e s d une a p p l i c a t i o n de l a c a r t e au 4
# systme d e x p l o i t a t i o n e t cre des groupes par module 5
cbrowser . py f BC_ c d OS_ G 6
7
# dtermine l ensemble des chemins p o s s i b l e s d une f o n c t i o n v e r s une 8
# a u t r e f o n c t i o n e t c o l o r i e l e s d i f f r e n t s modules 9
cbrowser . py f VI S _V e ri f yP I N c v d S e c u r i t y K i l l C a r d g c o l o r 10
11
# dtermine l ensemble des appels d une f o n c t i o n en r e c r a n t l e s chemins 12
# d appel p e r m e t t a n t de l e s a t t e i n d r e e t cre des groupes par module 13
cbrowser . py f OS_WriteByte C v G 14
15
# dtermine l e s chemins p o s s i b l e s d une f o n c t i o n un ensemble d a u t r e s 16
# f o n c t i o n s en l i m i n a n t c e r t a i n s m o t i f s e t cre des groupes 17
cbrowser . py f VI S _V e ri f yP I N c v d OS_Raise s [ Transac , Command ] G 18
Finalement, un outil combinant la recherche de formes de code de la section 6.4.3 et l'inter-

rogation interactive du graphe d'appels permet une recherche de squences complexes de formes
de code en s'appuyant sur le graphe d'appels lors de la recherche. Cet outil permet des recherches
interprocdurales avec des informations de l'AST. Le listing 6.6 montre un extrait de code en
python o un liste dnit une squence de recherche l'intrieur de l'AST. Avec cette liste,
au dpart de la fonction VIS_VerifyPIN, on cherche une squence o une scurit killcard() se
trouve aprs une criture en eeprom d'une valeur. Dans ce scnario, un attaquant peut fausser
la valeur crite avec une attaque et arracher la carte avant que la dfense n'ait eu le temps
de se dclencher. Avec les bons paramtres, cette squence de recherche peut tre gnralise
l'ensemble du code source d'un projet.
Listing 6.6 Exemple de recherche de formes de code interprocdurale
check_seq = ["FuncDef::Start", 1
"+ID(VIS_VerifyPIN)::Down", 2
"If@::Down", 3
"+Compound::Down", 4
"+ID(SecureCounter)::Down", 5
"If::Down", 6
"+Compound::Down", 7
"+ID(killcard)::Up", 8
"ID(SecureCounter)?ifcond::Up", 9
"@::End"] 10
check_secu_too_late(check_seq, "FuncCall", "writeEEprom") 11
Applique au code source du listing 6.7, cette squence permet d'obtenir une trace du code
entre un if, la ligne 4, qui manipule dans son corps SecureCounter, un objet sensible, et un if,
la ligne 11, qui vrie cet objet sensible dans la condition. La fonction check_secu_too_late
isole les fonctions ("FuncCall") prsentes dans la trace et eectue une recherche rcursive pour
vrier si un ls dans le graphe d'appels de f() ou g() n'appelle pas la fonction writeEEprom.
Listing 6.7 Exemple de code source pour recherche de formes de code interprocdurale
void VIS_VerifyPIN(void) 1
{ 2
/* ... */ 3
if ( /* ... */) /* dbut de trace */ 4
{ 5
SecureCounter++; 6
} 7
f(); 8
if ( /* ... */) 9
g(); 10
if ( SecureCounter != 12 ) /* fin de trace */ 11
killcard(); 12
/* ... */ 13
} 14
Disposer la fois d'informations sur le graphe d'appels et sur l'AST des fonctions au moment
de l'analyse permet d'obtenir des informations croises qui peuvent tre utilises an d'aider le
dveloppeur lors de la scurisation du code. On peut ainsi crer une table qui donne pour chaque
fonction du programme les autres fonctions qui, elles-mmes ou par un appel ls, utilisent les
mmes variables globales. Un exemple est donn avec la table 6.1. Le dveloppeur peut ainsi, en
interrogeant la table, isoler au travers de l'ensemble du programme des fonctions qui peuvent
servir de points d'entre un attaquant. De tels points d'entre peuvent servir pour une attaque
au travers de la modication de variables globales qui propagent par construction une erreur
dans le reste du programme. De telles informations sont diciles obtenir sans une analyse
interprocdurale du graphe d'appels couple avec des informations provenant de l'AST.
Fonctions f1 f2 ... fn
f1 glob1 ;glob6 glob4 ... globi ;globj
f2 glob4 glob4 ;glob7 ... globk ;globl
... ... ... ... globm ;globn
fn globi ;globj globk ;globl globm ;globn globx ;globy
Table 6.1 Croisement entre les fonctions et les globales utilises
Ces analyses se basent sur l'AST de chacune des fonctions du programme analys. La cration
des chiers d'AST prend quelques minutes pour l'ensemble d'un projet. Ces chiers sont ensuite
mis en cache pour les analyses. Ainsi, chacune de ces analyses, mme les plus complexes, ne
prend que quelques secondes pour s'excuter, ce qui permet des passes de recherches rapides par
un utilisateur. Ces passes peuvent ensuite tre regroupes pour crer des suites de recherche de
formes de code sensibles sur l'ensemble d'un programme.
6.5 Conclusion
Les mthodologies dveloppes dans les chapitres prcdents ont pour but de donner de
solides garanties de scurit au travers d'une formalisation des besoins en scurit et la modli-
sation des capacits de l'attaquant. L'application dans un domaine industriel se concrtise par
une amlioration du processus de scurisation existant travers l'utilisation d'outils. Ces outils
sont en partie bass sur les mthodologies dveloppes dans un contexte acadmique.
L'utilisation de ces mthodes et outils doit se traduire en un gain en temps et des informa-
tions pertinentes remontes aux dveloppeurs chargs de mettre en place la scurit. Ces outils
remplissent les fonctionnalits suivantes : aide la dcouverte de nouvelles vulnrabilits, test
de rsistance des scurits implmentes contre les attaques connues. Les ralisations dans un
contexte industriel incluent :
Une mthode ddie la carte puce pour tester la scurit implmente contre les
attaques physiques. Avec cette technique, on peut aprs annotation du code source, injecter
des attaques et les lancer depuis le terminal ;
Une plate-forme automatique pour le test dynamique des sauts de code et l'identication
des impacts fonctionnels. Avec cet outil, il est possible de tester toutes les combinaisons de
saut possible dans le code, consquence d'une attaque physique, et de vrier leurs impacts
fonctionnels.
Le contexte industriel de cette thse m'a permis de confronter une perspective acadmique
aux contraintes industrielles dans le cadre d'une vrication de la scurit. Si des outils per-
mettant la preuve de la scurit sont attractifs du point de vue de la garantie apporte, le cot
engendr par leur adoption, leur conguration et leur maintien favorisent l'heure actuelle des
solutions alternatives sur des projets grande chelle. Je pense cependant que de tels outils
dpassent maintenant le cadre acadmique et peuvent tre utiliss avec succs dans un contexte
industriel. Il est cependant important de choisir les lments du systme sur lesquels ces outils
seront dploys de manire maximiser le retour sur investissement. Les lments dont la scu-
rit est critique et qui ont vocation tre rutiliss gurent parmi les lments considrer. Pour
le reste du systme, des approches qui minimisent l'eort fournir de la part du dveloppeur
et favorisent la gnration de rsultats se prtent bien un contexte industriel. Finalement, je
pense que s'il n'existe pas l'heure actuelle d'outils permettant de garantir de manire automa-
tique, gnriquement et sans produire de faux positifs l'ensemble des problmatiques de scurit
qui touchent l'embarqu, l'accent doit tre mis sur des outils qui augmentent la synergie entre
le dveloppeur et l'expert en scurit. Des outils d'aide la dcision lors de revues de code sont
particulirement appropris. Je pense aussi qu'il est dicile de vrier des contraintes de scu-
rit sans un apport d'information additionnel de la part du dveloppeur. Contrairement des
problmatiques de suret, la scurit demande au niveau fonctionnel une intention de compor-
tement que le dveloppeur implmente partir des spcications. L'objectif lors de la cration
d'outils d'aide la dcision doit tre de rduire la complexit induite par de larges programmes
et permettre rapidement et de manire interactive une apprciation de la part de l'utilisateur
d'un problme de scurit.
6.6 Perspectives
Des outils de visualisation de code peuvent tre utiliss an d'aider dans la comprhension du
programme et ainsi une scurisation plus ecace. Les auteurs de [Hurd et al. 2010] prsentent
un outil de visualisation du ot d'information travers l'intgralit d'un programme C. Cet outil
permet notamment de visualiser le passage de l'information de fonctions en fonctions. Les points
d'entre et de sortie de cette information dans une partie du programme est mise en vidence
permettant d'apprhender visuellement la transmission de cette information d'un point un

autre du programme. Des outils similaires ont t dvelopps pour la visualisation l'excu-
tion [Kurtz 2004] ou des donnes dans les direntes parties d'un systme [Mysore et al. 2008].
Les auteurs de [Doernenburg 2006] donnent des exemples d'outils pouvant servir la cration de
ces visualisations. Des travaux sur le code assembleur ont galement t menes [Ly et al. 2008].
Une autre perspective serait d'arriver mettre en place une technique similaire la si-
mulation utilisant un dbogueur du chapitre prcdent. En plus d'orir de meilleures perfor-
mances, une solution dynamique permettrait d'interagir directement avec le programme au mo-
ment de l'attaque. Des pistes pour de telles implmentations peuvent tre trouves aux rf-
rences [Nethercote & Seward 2007] et [Brossard 2011].
Chapitre 7
Conclusion
7.1 Conclusion
Les systmes embarqus sont aujourd'hui utiliss dans de nombreux secteurs d'activits.
Parmi ces systmes, les cartes puce sont utilises dans des domaines o la scurit requiert une
attention particulire. Servant de support de nombreux processus d'authentication, cette carte
contient des donnes sensibles cibles par des attaquants. Comme le tmoigne l'volution des
attaques au cours des 10 dernires annes, des attaques de plus en plus sophistiques sont mises
au point permettant d'extraire ces donnes sensibles mais aussi de perturber le fonctionnement
prvu de la carte. Parmi ces attaques, les attaques par faute physique reprsentent un d de
taille pour les constructeurs de composants et les dveloppeurs logiciels du secteur embarqu.
La scurisation et la certication des plates-formes et du code embarqu reprsente une phase
importante du processus de cration d'une carte. Disposer d'outils ecaces permettant d'aider
les dveloppeurs confronts ce besoin de scurisation est un enjeu pour les entreprises de
dveloppement embarqu. Or, l'heure actuelle, peu de mthodologies et d'outils prennent en
compte cette dimension d'attaque physique. Cette thse s'inscrit dans ce cadre et a pour but de
rpondre ce besoin.
Dans cette thse, nous avons choisi d'adopter une approche de haut niveau en gardant le
point de vue du dveloppeur logiciel. Ainsi, aprs avoir donn un aperu de l'architecture interne
et du fonctionnement d'une carte puce, nous avons dcrit les direntes attaques existantes.
An de garantir la scurit du code contre ces attaques, nous avons exprim des proprits
de scurit telles que la condentialit et l'intgrit au niveau du code source. Exprimer ces
proprits de scurit ce niveau a l'avantage de les rendre comprhensibles et utilisables par
la personne qui implmente aussi les fonctionnalits logicielles du programme.
Nous avons ensuite cherch caractriser les capacits d'un attaquant compromettre le
systme par une attaque physique. A partir d'un modle de faute de la littrature, nous avons
tabli un modle d'attaque, exprimant au niveau du code source, les consquences fonctionnelles
des attaques. Nous avons galement approfondi la caractrisation des eets des fautes physiques,
en modlisant les consquences de celles-ci sur le ot d'interprtation du code par le micropro-
cesseur. Ce modle nous a ensuite permis de crer des simulations logicielles des direntes
attaques possibles. Dans un souci d'optimisation des vrications, nous avons tabli et prouv
une rduction possible du nombre de simulations d'attaque injecter dans le code source an
de couvrir l'ensemble des points d'attaque.
Une fois ces proprits de scurit et un modle d'attaque exprims, nous avons cherch
vrier que les proprits taient bien respectes en tudiant le code source du programme.
Des lments observables au niveau du code source, comme le fait qu'une variable ait une valeur
particulire un instant donn du programme, ont t choisis an de valider le comportement du
programme sous attaque. Travailler avec Frama-C, un outil d'analyse statique capable d'eectuer
190 Chapitre 7. Conclusion
des analyses sur une reprsentation abstraite du code, nous a permis d'tendre ce critre
l'appartenance d'une valeur d'une variable un intervalle de valeur un instant donn de
l'excution. En combinant des lments observables, validant le comportement du code, des
attaques physiques, simules par injection de code source, nous avons propos une mthodologie
permettant de valider statiquement la scurit du comportement du code sous attaque.
Face certaines limitations de l'analyse statique, une mthodologie, base sur le test et la
validation dynamique d'lments observables, t mise au point. Cette mthode utilise un
principe d'injection de code issu du modle d'attaque simulant des attaques par saut. Nous
avons utilis cette mthode exprimentale an de dcouvrir et d'isoler de nouvelles attaques
correspondant au modle d'attaque. Une reprsentation graphique de la rpartition des attaques
potentiellement dangereuses a t propose an de visualiser, sur l'ensemble du programme, les
zones risque l'chelle d'une fonction. Cette mthode nous a galement servi confronter la
couverture de notre modle d'attaque haut niveau avec la totalit des attaques possibles en
assembleur. Nous avons pour cela utilis deux techniques d'injections : avant compilation et
la vole pendant l'excution dynamique du programme l'aide d'un dbogueur. Ces techniques
intervenant au niveau C ou au niveau assembleur. Ces direntes techniques exposent ainsi
dirents moyens de mise en uvre possibles. La mthodologie a nalement t porte et teste
dans un environnement industriel o elle a mise en vidence une vulnrabilit sur le code de
carte puce. L'attaque associe a cependant t juge trs dicile voire impossible raliser
avec les comptences actuelles des attaquants.
Une dernire partie de la thse traite des direntes mthodes et outils dvelopps dans le
contexte industriel, ayant pour but d'amliorer le processus de scurisation du code source. Ces
mthodes incluent le test et le passage l'chelle d'outils d'analyse statique sur des projets
industriels. Une solution ddie, compose d'outils d'analyse de code, de parcours et d'interro-
gation du graphe d'appels, a galement t dveloppe an de faciliter le travail du dveloppeur
charg de scuriser le code source. Cette partie donne un exemple d'informations dont celui-ci
doit disposer an de scuriser ecacement son code source.
Pour conclure, on peut faire appel la gure 1.15 du chapitre 1 qui donne une vue d'en-
semble de la problmatique de scurit dans un contexte embarqu. Cette gure montre que la
scurit fait intervenir des aspects matriel, fonctionnel et d'attaque. Cette thse montre qu'un
aspect de modlisation important entre en jeu. Cette modlisation est ncessaire an d'exprimer
ecacement des besoins en scurit, cerner l'ensemble des possibilits d'attaque et laborer des
solutions appropries. Si cette thse propose une solution purement logicielle au problme de
la scurit embarqu, cette approche ne doit pas faire oublier qu'il est important de considrer
conjointement les perspectives matrielles et logicielles an de cerner ecacement l'ensemble de
la complexit du problme [Wolf 1994].
7.2 Perspectives
Les rsultats obtenus dans cette thse peuvent tre tendus suivant plusieurs axes. Ces axes
ont trait des domaines thoriques et pratiques de l'informatique. Ces axes incluent :
La scurit o des modlisations adoptant des perspectives direntes permettraient de ratio-

naliser des problmatiques complexes ;
L'architecture scurise avec une quantication de la scurit par rapport l'ensemble des
dfenses matrielles permettant de dduire les besoins logiciels ;
La compilation avec la cration de compilateurs certis garantissant des proprits de scu-

rit ou aidant la vrication de celles-ci ;
Le langage o la smantique et l'interprtation abstraite appliqus la scurit ouvrent de

nouvelles perspectives d'analyse ;
L'ingnierie logicielle avec la cration de tests et d'injections de fautes ddies la scurit ;

La thorie de l'information qui permettrait de raner les modles tablis ;
La visualisation qui applique la scurit permettrait de trouver des reprsentations adap-
tes.
Les travaux raliss dans cette thse ouvrent des perspectives d'intgration avec d'autres
domaines mais aussi des perspectives d'amlioration et de ranement du travail existant. Par
exemple, intgrer une perspective d'attaque physique des outils d'analyse statique ou dyna-
mique existants, en se basant sur les modlisations tablies, pourrait permettre d'laborer des
analyses sophistiques exploitant les capacits de ces outils. Ces analyses auraient pour but,
soit d'aider le dveloppeur dans son processus de scurisation, en mettant sa disposition des
informations supplmentaires, soit de tester le code et les scurits implmentes pour valuer
leur rsistance des attaques physiques modlises.
Les proprits de scurit et modles tablis pourraient galement tre tendus an de faire
apparatre des lments de thorie de l'information ou des aspects de squencement propre
la logique temporelle. Ces proprits, une fois tablies sur l'ensemble du systme, constituent
une politique de scurit qui assure un niveau de scurit travers l'ensemble du systme.
Cependant, les politiques gnres peuvent contenir des conits qu'il serait intressant d'tudier
et de rsoudre an d'obtenir une cohrence dans la scurit sur l'ensemble du systme.
Les tests de scurit tablis ici pourraient tre amliors en se rapprochant d'autres domaines
comme le concolic testing ou le fuzzing. Ces domaines proposent des techniques de dcouverte et
gnration automatique de vecteurs d'entre permettant d'atteindre un point particulier du pro-
gramme. tablir automatiquement des tests pertinents pourraient reprsenter un rel avantage
dans un contexte industriel. Des techniques comme la couverture de code pourraient galement
tre utilises pour amliorer la visibilit des tests tablis et permettre des comparaisons de traces
d'excution. Dans une mme optique, des visualisations plus sophistiques pourraient tre ta-
blies pour mettre en vidence des aspects de scurit du code l'chelle d'un projet.
Prendre en compte les optimisations du compilateur du point de vue de la scurit reprsente
galement un d de taille. Russir traduire des proprits de haut niveau se rpercutant sur
le code assembleur ou une modlisation de bas niveau pourrait tre une piste de travaux futurs.
Dans un contexte un peu dirent, o le compilateur peut tre modi, celui-ci pourrait tre
utilis an d'extraire des informations sur le code au moment de la compilation o mme de
scuriser automatiquement des portions de code. Cette solution aurait l'avantage de dlguer la
scurisation et simplier le travail de scurisation du dveloppeur. Sans l'aide du compilateur,
une instrumentation du code pour la scurit peut galement tre eectue. Un exemple d'une
telle instrumentation est donn dans cette thse.
Des perspectives propres chaque chapitre sont aussi prsentes la n de ceux-ci.
Bibliographie
[Agostini 2009] O. Agostini. Simulateur d'Attaques Hardware sur Carte Puce. Master's thesis,
Universit de Bordeaux 1, 2009. (Cit en page 145.)
[Agrawal et al. 2002] D. Agrawal, B. Archambeault, J. Rao et P. Rohatgi. The EM Side-

Channel(s). In B. Kaliski, . K. Ko et C. Paar, editeurs, Cryptographic Hardware
and Embedded Systems - CHES, volume 2523 of Lecture Notes in Computer Science,
pages 2945. Springer Berlin / Heidelberg, 2002. (Cit en page 83.)
[Aigner & Oswald 2011] M. Aigner et E. Oswald. Power Analysis Tutorial. Rapport technique,
University of Technology Graz, 2011. (Cit en page 84.)
[Akkar et al. 2000] M.-L. Akkar, R. Bevan, P. Dischamp et D. Moyart. Power Analysis, What
Is Now Possible... In T. Okamoto, editeur, ASIACRYPT, volume 1976 of Lecture Notes
in Computer Science, pages 489502. Springer, 2000. (Cit en page 83.)
[Akkar et al. 2003] M.-L. Akkar, L. Goubin et O. Ly. Automatic Integration of Counter-
Measures Against Fault Injection Attacks. In e-Smart, Nice, France, 2003. (Cit en
page 167.)
[Amiel et al. 2007] F. Amiel, K. Villegas, B. Feix et L. Marcel. Passive and Active Combined
Attacks : Combining Fault Attacks and Side Channel Analysis. In Workshop on Fault
Diagnosis and Tolerance in Cryptography, pages 92102, Vienna, Austria, 2007. IEEE.
(Cit en page 84.)
[Anderson & Kuhn 1996] R. Anderson et M. Kuhn. Tamper resistance-a cautionary note. In
Second USENIX Workshop on Electronic Commerce, volume 2, pages 1 11, San Diego,
CA, USA, 1996. (Cit en page 27.)
[Anderson & Kuhn 1997] R. Anderson et M. Kuhn. Low Cost Attacks on Tamper Resistant
Devices. In 5th International Workshop Security Protocols, pages 125136, Paris, France,
1997. Springer-Verlag. (Cit en pages 85 et 86.)
[Andouard 2009] P. Andouard. Outils d'aide la recherche de vulnrabilits dans l'implantation

d'applications embarques sur carte puce. PhD thesis, Universit de Bordeaux 1, 2009.
(Cit en pages 77, 145 et 181.)
[Andronick et al. 2005] J. Andronick, B. Chetali et C. Paulin-Mohring. Formal Verication of

Security Properties of Smart Card Embedded Source Code. In J. A. Fitzgerald, I. J.
Hayes et A. Tarlecki, editeurs, Formal Methods - FM, volume 3582 of Lecture Notes in
Computer Science, pages 302317, Newcastle, UK, 2005. Springer. (Cit en page 51.)
[Angelis 2012] D. Angelis. Motorola 68000 Instruction Set, 2012. http://infoindustrielle.free.

fr/68K_pdf/02_68K_36_106.pdf [En ligne ; consult le 05-aot-2012]. (Cit en page 39.)
[Aumller et al. 2002] C. Aumller, P. Bier, W. Fischer, P. Hofreiter et J.-P. Seifert. Fault
Attacks on RSA with CRT : Concrete Results and Practical Countermeasures. In B.
S. Kaliski Jr., . K. Ko et C. Paar, editeurs, Cryptographic Hardware and Embedded
Systems - CHES, volume 2523 of Lecture Notes in Computer Science, pages 260275,
Redwood Shores, CA, USA, 2002. Springer. (Cit en page 85.)
194 Bibliographie
[Avenel 2010] Y. Avenel. Cartes puces : Les nouvelles frontires, 2010. http://www.electroniques.
biz/pdf/ES_2010_010_044.pdf [En ligne ; consult le 05-aot-2012]. (Cit en page 3.)
[Balliu & Mastroeni 2009] M. Balliu et I. Mastroeni. A weakest precondition approach to active
attacks analysis. In S. Chong et D. A. Naumann, editeurs, Workshop on Programming
Languages and Analysis for Security - PLAS, pages 5971. ACM, 2009. (Cit en pages 76
et 77.)
[Bar-El et al. 2006] H. Bar-El, H. Choukri, D. Naccache, M. Tunstall et C. Whelan. The sor-
cerer's apprentice guide to fault attacks. Proceedings of the IEEE, vol. 94, no. 2, pages
370382, 2006. (Cit en page 85.)
[Bar-El 2003] H. Bar-El. Known Attacks Against Smartcards. Rapport technique, Discretix
Technologies, 2003. http://www.hbarel.com/publications/Known_Attacks_Against_Smartcards.pdf
[En ligne ; consult le 05-aot-2012]. (Cit en page 29.)
[Barbosa et al. 2005] R. Barbosa, J. Vinter, P. Folkesson et J. Karlsson. Assembly-Level pre-

injection analysis for improving fault injection eciency. In 5th European conference on
Dependable Computing - EDCC, EDCC'05, pages 246262, Budapest, Hungary, 2005.
Springer-Verlag. (Cit en page 119.)
[Barbu et al. 2010] G. Barbu, H. Thiebeauld et V. Guerin. Attacks on Java Card 3.0 Combi-
ning Fault and Logical Attacks. In J. I.-C. Dieter Gollmann Jean-Louis Lanet, editeur,
Smart Card Research and Advanced Application. 9th IFIP WG 8.8/11.2 International
Conference, volume 6035 of Lecture Notes in Computer Science / Security & Cryptology,
pages 148163, Passau, Allemagne, 2010. Springer. (Cit en page 44.)
[Baudin et al. 2010] P. Baudin, J.-C. Fillitre, C. March, B. Monate, Y. Moy et V. Prevosto.
ACSL : ANSI/ISO C Specication Language. Rapport technique, CEA LIST and INRIA,
2009-2010. Preliminary Design (v 1.4). (Cit en pages 111 et 113.)
[Baudin et al. 2012] P. Baudin, R. Bonichon, L. Correnson, P. Cuoq, Z. Dargaye, J.-C. Fillitre,
P. Herrmann, C. March, B. Monate, Y. Moy, A. Pacalet, V. Prvosto, J. Signoles et
B. Yakobowski. Frama-C : Framework for Modular Analysis of C. CEA-LIST and
INRIA-Futurs, 2012. http://frama-c.com/ [En ligne ; consult le 05-aot-2012]. (Cit en
page 174.)
[Bayart 2012] F. Bayart. La scurit des cartes bancaires, 2012. http://www.bibmath.net/crypto/

moderne/cb.php3 [En ligne ; consult le 05-aot-2012]. (Cit en pages 7 et 211.)
[Bell & LaPadula 1975] D. E. Bell et L. J. LaPadula. Secure Computer Systems : Unied Ex-
position and Multics Interpretation. Rapport technique MTR-2997, The MITRE Corp.,
1975. (Cit en page 50.)
[Bellingard et al. 2012] F. Bellingard, D. Bolkensteyn, S. Brandhof, O. Gaudin, F. Mallet et

E. Mandrikov. Sonar an open platform to manage code quality, 2012. http://www.
sonarsource.org/ [En ligne ; consult le 05-aot-2012]. (Cit en page 174.)
[Bendersky 2012] E. Bendersky. Pycparser tool for parsing C code, 2012. http://code.google.com/
p/pycparser/ [En ligne ; consult le 05-aot-2012]. (Cit en page 177.)
[Berthom et al. 2010] P. Berthom, K. Heydemann, X. Kaumann-Tourkestansky et J.-F. La-

lande. Attack model for verication of interval security properties for smart card C codes.
In 5th ACM SIGPLAN Workshop on Programming Languages and Analysis for Security
PLAS'10, pages 112, Toronto Canada, 2010. ACM. (Cit en pages 46 et 110.)
Bibliographie 195

lande. Simulating physical attacks in smart card C codes : the jump attack case. In
e-Smart, Nice, France, 2011. (Cit en pages 46 et 169.)

lande. High level model of control ow attacks for smart card functional security. In 7th
International Conference on Availability, Reliability and Security AReS 2012, Prague,
Czech Republic, 2012. IEEE Computer Society. (Cit en pages 46 et 143.)
[Biba 1977] K. J. Biba. Integrity Considerations for Secure Computer Systems. Rapport tech-
nique, MITRE Corp., 1977. (Cit en page 50.)
[Biham & Shamir 1997] E. Biham et A. Shamir. Dierential Fault Analysis of Secret Key Cryp-
tosystems. In Advances in Cryptology - CRYPTO, volume 1294 of Lecture Notes in
Computer Science, pages 513525, Santa Barbara, California, USA, 1997. Springer Ber-
lin / Heidelberg. (Cit en page 85.)
[Blazy & Leroy 2005] S. Blazy et X. Leroy. Formal verication of a memory model for C-like
imperative languages. In R. B. Kung-Kiu Lau, editeur, ICFEM'05 : 7th International
Conference on Formal Engineering Methods, volume 3785 of Lecture Notes in Computer
Science, pages 280299, Manchester, UK, 2005. Springer. http ://www.springer.com/.
(Cit en page 52.)
[Blazy et al. 2006] S. Blazy, Z. Dargaye et X. Leroy. Formal Verication of a C Compiler Front-
End. In International Symposium on Formal Methods - FM, volume 4085 of Lecture Notes
in Computer Science, pages 460475, Hamilton, ON, Canada, 2006. Springer. (Cit en
page 79.)
[Blmer et al. 2006] J. Blmer, M. Otto et J.-P. Seifert. Sign Change Fault Attacks on Elliptic
Curve Cryptosystems. In L. Breveglieri, I. Koren, D. Naccache et J.-P. Seifert, editeurs,
Fault Diagnosis and Tolerance in Cryptography, volume 4236 of Lecture Notes in Com-
puter Science, pages 3652. Springer, 2006. (Cit en page 93.)
[Bodescot & Guinot 2011] A. Bodescot et D. Guinot. Les cartes puce sans contact se g-
nralisent. Le Figaro, 2011. http://www.eurosmart.com/images/doc/articles/111114-lefigaro.
fr-itwm.bertin.pdf [En ligne ; consult le 05-aot-2012]. (Cit en page 3.)
[Bond & Anderson 2001] M. Bond et R. J. Anderson. API-Level Attacks on Embedded Systems.
IEEE Computer, vol. 34, no. 10, pages 6775, 2001. (Cit en page 18.)
[Bond 2006] M. Bond. Phish and Chips. In B. Christianson, B. Crispo, J. A. Malcolm et

M. Roe, editeurs, Security Protocols Workshop, volume 5087 of Lecture Notes in Com-
puter Science, pages 4951, Cambridge, UK, 2006. Springer. (Cit en page 16.)
[Boneh et al. 2001] D. Boneh, R. DeMillo et R. Lipton. On the importance of checking crypto-
graphic protocols for faults. Journal of Cryptology, vol. 14, no. 2, pages 101119, 2001.
(Cit en page 85.)
[Bouzefrane 2008] S. Bouzefrane. Cours carte puce EMV, 2008. http://cedric.cnam.fr/

~bouzefra/cours/cours_SEM/Cartes_Bouzefrane_EMV.pdf [En ligne ; consult le 05-aot-2012].
(Cit en page 18.)
[Bouzefrane 2009] S. Bouzefrane. Cours carte puce, 2009. http://cedric.cnam.fr/~bouzefra/

cours/cours_SEM/Cartes_Bouzefrane_partie1.pdf [En ligne ; consult le 05-aot-2012]. (Cit
en page 10.)
196 Bibliographie
[Brandl 2012] G. Brandl. Sphinx Python Documentation Generator, 2012. http://sphinx.pocoo.

org/ [En ligne ; consult le 05-aot-2012]. (Cit en page 177.)
[Brossard 2011] J. Brossard. Post Memory CorruptionMemory Analysis. In Black Hat, Las
Vegas, NV, USA, 2011. http://www.pmcma.org/wp-content/uploads/2011/09/BHUS-2011_Brossard.
pdf [En ligne ; consult le 05-aot-2012]. (Cit en page 188.)
[Buetler 2008] I. Buetler. Smart Card APDU Analysis. In Black Hat, Las Vegas, NV, USA,
2008. http://www.blackhat.com/presentations/bh-usa-08/Buetler/BH_US_08_Buetler_SmartCard_
APDU_Analysis_V1_0_2.pdf [En ligne ; consult le 05-aot-2012]. (Cit en page 18.)
[Canivet 2009] G. Canivet. Analyse des eets d'attaques par fautes et conception scurise sur
plate-forme recongurable. PhD thesis, Institut Polytechnique de Grenoble, 2009. (Cit
en page 86.)
[CCP 2012] Common Criteria Portal, 2012. www.commoncriteriaportal.com [En ligne ; consult le
05-aot-2012]. (Cit en page 11.)
[Chambrot & Kaumann-Tourkestansky 2009] F. Chambrot et X. Kaumann-Tourkestansky.

Dedicated Smart Card Security Checking. In e-Smart, Nice, France, 2009. (Cit en
pages 46 et 169.)
[Christmansson & Chillarege 1996] J. Christmansson et R. Chillarege. Generation of an er-

ror set that emulates software faults based on eld data. In Proceedings of the The
Twenty-Sixth Annual International Symposium on Fault-Tolerant Computing (FTCS
'96), FTCS '96, pages 304, Washington, DC, USA, 1996. IEEE Computer Society. (Cit
en page 144.)
[Cifuentes & Gough 1995] C. Cifuentes et K. J. Gough. Decompilation of Binary Programs.

Software - Practice & Experience, vol. 25, no. 7, pages 811829, 1995. (Cit en pages 92,
93 et 139.)
[Clavier et al. 2010] C. Clavier, B. Feix, G. Gagnerot et M. Roussellet. Passive and Active
Combined Attacks on AES - Combining Fault Attacks and Side Channel Analysis. In
L. Breveglieri, M. Joye, I. Koren, D. Naccache et I. Verbauwhede, editeurs, Fault Diag-
nosis and Tolerance in Cryptography, pages 1019, Santa Barbara, CA, USA, 2010. IEEE
Computer Society. (Cit en page 84.)
[Clavier 2007] C. Clavier. De la scurit physique des crypto-systmes embarqus. PhD thesis,
Universit de Versailles, St Quentin en Yvelines, 2007. (Cit en page 86.)
[Collin 2005] L. Collin. A Quick Benchmark : Gzip vs. Bzip2 vs. LZMA, 2005. http://tukaani.
org/lzma/benchmarks.html [En ligne ; consult le 05-aot-2012]. (Cit en page 155.)
[Consultants 2009] D. N. Consultants. Dimension conomique et industrielle des cartes

puces, 2009. http://www.industrie.gouv.fr/p3e/etudes/cartes_puces/cartes_puces.pdf [En
ligne ; consult le 05-aot-2012]. (Cit en pages 3, 20 et 211.)
[Coron et al. 2007] J.-S. Coron, E. Prou et M. Rivain. Side Channel Cryptanalysis of a Hi-
gher Order Masking Scheme. In P. Paillier et I. Verbauwhede, editeurs, Cryptographic
Hardware and Embedded Systems - CHES, volume 4727 of Lecture Notes in Computer
Science, pages 2844. Springer, 2007. (Cit en page 78.)
[Correnson et al. 2010] L. Correnson, P. Cuoq, A. Puccetti et J. Signoles. Frama-C User Manual.
CEA LIST, 2010. (Cit en page 111.)
Bibliographie 197
[Cortier 2005] V. Cortier. Verication of cryptographic protocols : techniques , tools and link to
cryptanalysis. In Symposium A Quarterly Journal In Modern Foreign Literatures, Nancy,
France, 2005. (Cit en page 28.)
[Cousot & Cousot 1977] P. Cousot et R. Cousot. Abstract Interpretation : A Unied Lattice
Model for Static Analysis of Programs by Construction or Approximation of Fixpoints.
In R. M. Graham, M. A. Harrison et R. Sethi, editeurs, Symposium on Principles of
Programming Languages - POPL, pages 238252, Los Angeles, CA, USA, 1977. ACM.
(Cit en page 51.)
[Criteria 2009] C. Criteria. Application of Attack Potential to Smartcards. Rapport tech-

nique March, BSI, 2009. www.commoncriteriaportal.org/files/supdocs/CCDB-2009-03-001.pdf
[En ligne ; consult le 05-aot-2012]. (Cit en pages 10, 21 et 90.)
[Cuoq & Prevosto 2010] P. Cuoq et V. Prevosto. Frama-C's value analysis plug-in. Rapport
technique, CEA LIST, 2010. http://frama-c.com/download/value-analysis-Boron-20100401.pdf
[Cuoq et al. 2012] P. Cuoq, D. Delmas, S. Duprat et V. M. Lamiel. Fan-C, a Frama-C plug-in
for data ow verication. In Embedded Real Time Software and Systems ERTS, Toulouse
, France, 2012. (Cit en page 177.)
[De Haas 2007] J. De Haas. Side Channel Attacks and Countermeasures for Embedded Systems.
In Black Hat, Las Vegas, NV, USA, 2007. (Cit en page 82.)
[Delmas et al. 2010] D. Delmas, S. Duprat, V. M. Lamiel et J. Signoles. Taster, a Frama-C

plug-in to enforce Coding Standards. In Embedded Real Time Software and Systems
ERTS, Toulouse , France, 2010. (Cit en page 177.)
[Denning 1976] D. E. Denning. A Lattice Model of Secure Information Flow. Papers from Fifth
ACM Symposium on Operating Systems Principles, vol. 19, no. 5, pages 236243, 1976.
(Cit en page 51.)
[Derouet 2007] O. Derouet. Secure Smartcard Design against Laser Fault Injection. In 4th
Workshop on Fault Diagnostic and Tolerance in Cryptography, Vienne, Autriche, 2007.
(Cit en page 87.)
[Descamps 2000] J. B. N. Descamps. La carte puce. Master's thesis, Universit de Lille 1,

2000. http://phonecards.free.fr/these.htm [En ligne ; consult le 05-aot-2012]. (Cit en
page 8.)
[Doernenburg 2006] E. Doernenburg. Software Visualization and Model Generation. Engineer,

pages 112, 2006. (Cit en page 188.)
[Dutertre et al. 2009] J.-M. Dutertre, A. Tria, M. Agoyan, B. Robisson et M. Agoyan. Low cost
fault injection method for security characterization Secure ICs design issues. In e-Smart,
Nice, France, 2009. (Cit en page 13.)
[Dutertre et al. 2010] J.-M. Dutertre, A.-P. Mirbaha, A. Tria, B. Robisson et M. Agoyan. Revue
exprimentale des techniques d'injection de fautes. Journe Scurit GDR SoC-SiP,
2010. (Cit en page 86.)
[Ellson et al. 2003] J. Ellson, E. R. Gansner, E. Koutsoos, S. C. North et G. Woodhull. Graphviz

and dynagraph - static and dynamic graph drawing tools. In Graph Drawing Software,
pages 127148. Springer-Verlag, 2003. (Cit en page 182.)
198 Bibliographie
[Eurosmart 2001] Eurosmart. Common Criteria for IT Security Evaluation Protection Prole
Smartcard Integrated Circuit Protection Prole, 2001. (Cit en page 10.)
[Evans & Larochelle 2002] D. Evans et D. Larochelle. Improving Security Using Extensible
Lightweight Static Analysis. IEEE Software, vol. 19, no. 1, pages 4251, 2002. http:
//www.splint.org [En ligne ; consult le 05-aot-2012]. (Cit en page 174.)
[EventHelix 2012] EventHelix. C to Assembly Translation, 2012. http://www.eventhelix.com/

RealtimeMantra/Basics/CToAssemblyTranslation.htm [En ligne ; consult le 05-aot-2012]. (Cit
en page 38.)
[Faurax 2008] O. Faurax. valuation par simulation de la scurit des circuits face aux at-
taques par faute. These, Universit de la Mditerrane - Aix-Marseille II, 2008. (Cit en
page 145.)
[Fehnker et al. 2006] A. Fehnker, R. Huuck, P. Jayet, M. Lussenburg et F. Rauch. Goanna -

A Static Model Checker. In L. Brim, B. R. Haverkort, M. Leucker et J. van de Pol,
editeurs, Formal Methods : Applications and Technology, volume 4346 of Lecture Notes
in Computer Science, pages 297300. Springer, 2006. http://redlizards.com/products/ [En
ligne ; consult le 05-aot-2012]. (Cit en page 173.)
[Flottes et al. 2011] M. L. Flottes, G. D. Natale et G. Gogniat. Journe scurit : Scurit des
systmes embarqus, 2011. http://www2.lirmm.fr/journees_securite/material/prospectives/
2011.pdf [En ligne ; consult le 05-aot-2012]. (Cit en page 11.)
[Gadellaa 2005] K. O. Gadellaa. Fault Attacks on Java Card. PhD thesis, Technische Universiteit
Eindhoven, 2005. (Cit en pages 85 et 86.)
[Gandol et al. 2001] K. Gandol, C. Mourtel et F. Olivier. Electromagnetic Analysis : Concrete

Results. In . Ko, D. Naccache et C. Paar, editeurs, Cryptographic Hardware and
Embedded Systems - CHES, volume 2162 of Lecture Notes in Computer Science, pages
251261. Springer Berlin / Heidelberg, 2001. (Cit en page 83.)
[Giraud & Thiebeauld 2004a] C. Giraud et H. Thiebeauld. Basics of Fault Attacks. In Fault
Diagnosis and Tolerance in Cryptography, Florence, Italy, 2004. (Cit en page 85.)
[Giraud & Thiebeauld 2004b] C. Giraud et H. Thiebeauld. A Survey on Fault Attacks. In J.-J.
Quisquater, P. Paradinas, Y. Deswarte et A. A. E. Kalam, editeurs, Conference on Smart
Card Research and Advanced Applications - CARDIS, pages 159176, Toulouse, France,
2004. Kluwer. (Cit en page 85.)
[Giraud 2007] C. Giraud. Attaques de cryptosystmes embarqus et contre-mesures associes.

PhD thesis, Universit de Versailles, St Quentin en Yvelines, 2007. (Cit en page 84.)
[Gobio et al. 2000] H. Gobio, S. Smith, J. D. Tygar et B. Yee. Smart Cards in Hostile Environ-
ments. Security, 2000. (Cit en page 28.)
[Goguen & Meseguer 1982] J. A. Goguen et J. Meseguer. Security Policies and Security Models.
In IEEE Symposium on Security and Privacy, pages 1120, Oakland, CA, USA, 1982.
(Cit en page 51.)
[Goldwasser et al. 1989] S. Goldwasser, S. Micali et C. Racko. The knowledge complexity of

interactive proof systems. SIAM Journal on Computing, vol. 18, no. 1, pages 186208,
1989. (Cit en page 4.)
Bibliographie 199
[Grith & Kaiser 2007] R. Grith et A. G. E. Kaiser. Evaluating Software Systems via Fault-
Injection and Reliability, Availability and Serviceability (RAS) Metrics and Models Thesis
proposal. Science, 2007. (Cit en page 93.)
[Grinschgl et al. 2011] J. Grinschgl, A. Krieg, C. Steger, R. Weiss, H. Bock et J. Haid. Automatic
saboteur placement for emulation-based multi-bit fault injection. In 6th International
Workshop on Recongurable Communication-centric Systems-on-Chip - ReCoSoC, pages
18, Montpellier, France, 2011. IEEE. (Cit en page 144.)
[Grubb 2012] S. Grubb. Software package for producing plots, charts and graphics from data,
2012. http://ploticus.sourceforge.net/doc/welcome.html [En ligne ; consult le 05-aot-2012].
(Cit en page 181.)
[Guilley et al. 2008] S. Guilley, L. Sauvage, J.-L. Danger, N. Selmane et R. Pacalet. Silicon-level
Solutions to Counteract Passive and Active Attacks. In IEEE-CS, editeur, 5th workshop
on Fault Tolerance and Detection in Cryptography, pages 317, Washington, DC, USA,
2008. IEEE-CS. (Cit en page 27.)
[Guilley et al. 2010] S. Guilley, L. Sauvage, J.-L. Danger et N. Selmane. Fault Injection Resi-
lience. In Fault Diagnosis and Tolerance in Cryptography, pages 5165, Santa Barbara,
United States, 2010. IEEE Computer Society. 17 pages (extended version). (Cit en
page 27.)
[Guilley 2007] S. Guilley. Architecture et CAO pour crypto-processeurs scuriss. In GDR SoC-
SiP, 2007. (Cit en pages 26, 86 et 211.)
[Henning 2006] J. L. Henning. SPEC CPU2006 benchmark descriptions. ACM SIGARCH Com-
puter Architecture News, vol. 34, no. 4, 2006. (Cit en page 150.)
[Hotz 2010] G. Hotz. PS3 Hack Pastie, 2010. http://pastie.org/795944 [En ligne ; consult le
05-aot-2012]. (Cit en page 1.)
[HP 2012] HP. HP Fortify Static Code Analyzer (SCA), 2012. https://www.fortify.com/products/
hpfssc/source-code-analyzer.html [En ligne ; consult le 05-aot-2012]. (Cit en page 173.)
[Hurd et al. 2010] J. Hurd, A. Tomb et D. Burke. Visualizing Information Flow through C
Programs Automated Security Analysis Project C Information Flow Tool ( Cift ). In
Workshop on Systems Software Verication, Vancouver, BC, Canada, 2010. USENIX
Association. (Cit en page 187.)
[Joye 2008] M. Joye. On White-Box Cryptography. In Proceedings of the 1st International

Conference Security of Information and Networks, pages 712. Traord Publishing, 2008.
(Cit en pages 6 et 67.)
[Keil 2012] Keil. OPTIMIZE Compiler Directive. Rapport technique, ARM Ltd and ARM Ger-
many GmbH., 2012. http://www.keil.com/support/man/docs/c51/c51_optimize.htm [En ligne ;
consult le 05-aot-2012]. (Cit en page 78.)
[Klockwork 2012] Klockwork. On the y source code analysis, 2012. http://www.klocwork.com/

products/insight/?source=feature [En ligne ; consult le 05-aot-2012]. (Cit en page 173.)
[Kocher et al. 2011] P. Kocher, J. Jae, B. Jun et P. Rohatgi. Introduction to dierential power
analysis. Journal of Cryptographic Engineering, vol. 1, pages 527, 2011. (Cit en
page 83.)
200 Bibliographie
[Kocher 1996] P. C. Kocher. Timing Attacks on Implementations of Die-Hellman, RSA, DSS,

and Other Systems. In N. Koblitz, editeur, CRYPTO, volume 1109 of Lecture Notes in
Computer Science, pages 104113. Springer, 1996. (Cit en pages 27 et 83.)
[Kmmerling & Kuhn 1999] O. Kmmerling et M. G. Kuhn. Design principles for tamper-
resistant smartcard processors. In USENIX Workshop on Smartcard Technology, pages
920, Chicago, Illinois, USA, 1999. (Cit en page 85.)
[Kordy et al. 2010] B. Kordy, S. Mauw, M. Melissen et P. Schweitzer. Attack-defense trees and
two-player binary zero-sum extensive form games are equivalent. In Proceedings of the
First international conference on Decision and game theory for security - GameSec, Ga-
meSec'10, pages 245256, Berlin, Heidelberg, 2010. Springer-Verlag. (Cit en page 108.)
[Kurtz 2004] B. Kurtz. SoftViz : A Run-time Software Visualization Environment. PhD thesis,
Worcester Polytechnic Institute, 2004. (Cit en page 188.)
[Kushner 2012] D. Kushner. Machine Politics : NewYorker interview of George Hotz,

2012. http://www.newyorker.com/reporting/2012/05/07/120507fa_fact_kushner?currentPage=all
[Lancia 2011] J. Lancia. Un framework de fuzzing pour cartes puce : application aux pro-
tocoles EMV. In Symposium sur la Scurit des Technologies de l'Information et des
Communications, Rennes, France, 2011. (Cit en pages 18 et 44.)
[Lancia 2012] J. Lancia. Compromission d'une application bancaire JavaCard par attaque logi-
cielle. In Symposium sur la Scurit des Technologies de l'Information et des Communi-
cations, Rennes, France, 2012. (Cit en page 87.)
[Lanet 2000] J.-L. Lanet. Are Smart Cards the Ideal Domain for Applying Formal Methods ? In
J. P. Bowen, S. Dunne, A. Galloway et S. King, editeurs, First International Conference
of B and Z Users - ZB, volume 1878 of Lecture Notes in Computer Science, pages 363373,
York, UK, 2000. Springer. (Cit en pages 52 et 176.)
[Leroy 2003] X. Leroy. Computer Security from a Programming Language and Static Analysis
Perspective. In P. Degano, editeur, European Symposium on Programming, volume 2618
of Lecture Notes in Computer Science, pages 19, Warsaw, Poland, 2003. Springer. (Cit
en page 2.)
[Leroy 2004] X. Leroy. Exploiting type systems and static analyses for smart card security. In
G. Barthe, L. Burdy, M. Huisman, J.-L. Lanet et T. Muntean, editeurs, Construction
and Analysis of Safe, Secure, and Interoperable Smart Devices - CASSIS, volume 3362
of Lecture Notes in Computer Science, pages 172191. Springer, 2004. (Cit en page 77.)
[Leveugle 2007] R. Leveugle. Early Analysis of Fault-based Attack Eects in Secure Circuits.
IEEE Transactions on Computers, vol. 56, no. 10, pages 14311434, 2007. (Cit en
page 110.)
[Litwak 1999] R. Litwak. Fonctionnement interne d'un microprocesseur, 1999. http://rlitwak.

plil.fr/Cours_MuP/rlit321.html [En ligne ; consult le 05-aot-2012]. (Cit en pages 24
et 211.)
[Ly et al. 2008] O. Ly, P. Andouard et D. Rouillard. VisAA : Visual Analyzer for Assembler.
In Logic and Automata, pages 221225, Tozeur, Tunisia, 2008. (Cit en page 188.)
Bibliographie 201
[Machemie et al. 2011] J.-B. Machemie, C. Mazin, J.-L. Lanet et J. Iguchi-Cartigny. SmartCM
A Smart Card Fault Injection Simulator. In IEEE International Workshop on Information
Forensics and Security, pages 16, Foz do Iguau, Portugal, 2011. (Cit en page 145.)
[Madeira et al. 2000] H. Madeira, D. Costa et M. Vieira. On the Emulation of Software Faults
by Software Fault Injection. In International Conference on Dependable Systems and
Networks, pages 417426, New York city, NY, USA, 2000. (Cit en pages 144, 145
et 146.)
[Malacaria & Hankin 1999] P. Malacaria et C. Hankin. Non-Deterministic Games and Program
Analysis : An Application to Security. In IEEE Symposium on Logic in Computer Science
- LICS, pages 443452, Trento, Italy, 1999. IEEE Computer Society Press. (Cit en
page 108.)
[Manshaei et al. 2012] M. Manshaei, Q. Zhu, T. Alpcan, T. Basar et J.-P. Hubaux. Game Theory
Meets Network Security and Privacy. Rapport technique, Ecole Polytechnique Fdrale
de Lausanne, Vol. 45, Issue # 3, September 2013, 2012. (Cit en page 108.)
[Marche & Rousset 2006] C. Marche et N. Rousset. Verication of JAVA CARD Applets Beha-
vior with Respect to Transactions and Card Tears. IEEE, 2006. (Cit en page 105.)
[Marjamki 2012] D. Marjamki. A tool for static C/C++ code analysis, 2012. http://
sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page [En ligne ; consult le 05-
aot-2012]. (Cit en page 174.)
[McCarty 2004] B. McCarty. Selinux : Nsa's open source security enhanced linux. O'Reilly
Media, Inc., 2004. (Cit en page 50.)
[McCormac et al. 1995] J. McCormac, K. Vikor, M. Williams, R. Vreeman, L. Sugoy et B. McIl-

wrath. Decoding Pay TV (European Scrambling Systems), 1995. http://cd.textfiles.com/
hackersencyc/ETC/HARDWARE/FAQ2.HTM [En ligne ; consult le 05-aot-2012]. (Cit en page 86.)
[Microsoft 2002] Microsoft. The STRIDE Threat Model, 2002. http://msdn.microsoft.com/en-us/

library/ee823878(v=cs.20).aspx [En ligne ; consult le 05-aot-2012]. (Cit en page 108.)
[Miller et al. 2001] B. P. Miller, M. Christodorescu, R. Iverson, T. Kosar, A. Mirgorodskii et

F. I. Popovici. Playing Inside the Black Box : Using Dynamic Instrumentation to Create
Security Holes. Parallel Processing Letters, vol. 11, no. 2/3, pages 267280, 2001. (Cit
en page 93.)
[Moebius et al. 2009] N. Moebius, K. Stenzel et W. Reif. Generating formal specications for
security-critical applications - A model-driven approach. In Workshop on Software En-
gineering for Secure Systems - ICSE, IWSESS '09, pages 6874, Washington, DC, USA,
2009. IEEE Computer Society. (Cit en page 79.)
[Monate & Signoles 2008] B. Monate et J. Signoles. Slicing for Security of Code. In P. Lipp, A.-
R. Sadeghi et K.-M. Koch, editeurs, Trusted Computing - Challenges and Applications
- TRUST, volume 4968 of Lecture Notes in Computer Science, pages 133142, Olso,
Norway, 2008. Springer. (Cit en page 139.)
[Muchnick 1998] S. S. Muchnick. Advanced compiler design and implementation. Morgan Kauf-
mann, 1998. (Cit en page 120.)
[Murdoch et al. 2010] S. J. Murdoch, S. Drimer, R. J. Anderson et M. Bond. Chip and PIN is
Broken. In IEEE Symposium on Security and Privacy, pages 433446, Berleley/Oakland,
CA, USA, 2010. IEEE Computer Society. (Cit en pages 16 et 28.)
202 Bibliographie
[Myers et al. 2004] A. C. Myers, A. Sabelfeld et S. Zdancewic. Enforcing Robust Declassication.

In Workshop on Computer Security Foundations - CSFW, pages 172186, Pacic Grove,
CA, USA, 2004. IEEE Computer Society. (Cit en pages 76 et 77.)
[Mysore et al. 2008] S. Mysore, B. Mazloom, B. Agrawal et T. Sherwood. Understanding and

visualizing full systems with data ow tomography. In S. J. Eggers et J. R. Larus, editeurs,
Architectural Support for Programming Languages and Operating Systems - ASPLOS,
pages 211221, Seattle, WA, USA, 2008. ACM. (Cit en page 188.)
[Nethercote & Seward 2007] N. Nethercote et J. Seward. Valgrind : a framework for heavyweight
dynamic binary instrumentation. In Programming Language Design and Implementation
- PLDI, PLDI'07, pages 89100, San Diego, CA, USA, 2007. ACM. (Cit en page 188.)
[Nguyen 2011] M. H. Nguyen. Scurisation de processeurs vis--vis des attaques par faute et
par analyse de la consommation. PhD thesis, Universit Pierre et Marie Curie (UPMC),
2011. Type : Thse de Doctorat Soutenue le : 2011-09-21 Dirige par : Drach-temam,
Nathalie Encadre par : ROBISSON Bruno. (Cit en page 85.)
[Nori et al. 2009] A. V. Nori, S. K. Rajamani, S. Tetali et A. V. Thakur. The YogiProject :

Software Property Checking via Static Analysis and Testing. In S. Kowalewski et A. Phi-
lippou, editeurs, Tools and Algorithms for the Construction and Analysis of Systems -
TACAS, volume 5505 of Lecture Notes in Computer Science, pages 178181, York, UK,
2009. Springer. (Cit en pages 139 et 167.)
[Otto 2005] M. Otto. Fault Attacks and Countermeasures. PhD thesis, University of Paderborn,
2005. (Cit en page 86.)
[Parasoft 2012] Parasoft. Parasoft Application Security Solution, 2012. http://www.parasoft.com

[Pietriga 2005] E. Pietriga. A Toolkit for Addressing HCI Issues in Visual Language Envi-
ronments. In IEEE Symposium on Visual Languages and Human-Centric Computing
(VL/HCC), pages 145152, Dallas, TX, USA, 2005. IEEE Computer Society. (Cit en
page 182.)
[Pistoia et al. 2007] M. Pistoia, A. Banerjee et D. a. Naumann. Beyond Stack Inspection :

A Unied Access-Control and Information-Flow Security Model. IEEE Symposium on
Security and Privacy - SP, pages 149163, 2007. (Cit en page 107.)
[Prou & Rivain 2009] E. Prou et M. Rivain. Combining Information Theory and Side Chan-
nels to Break Secure Implementations. In e-Smart, Nice, France, 2009. (Cit en page 78.)
[Quisquater & Kouene 2002] J.-J. Quisquater et F. Kouene. Side Channel Attacks, 2002. (Cit
en pages 84 et 85.)
[Quisquater & Samyde 2001] J.-J. Quisquater et D. Samyde. ElectroMagnetic Analysis (EMA) :
Measures and Counter-measures for Smart Cards. In I. Attali et T. Jensen, editeurs,
Smart Card Programming and Security, volume 2140 of Lecture Notes in Computer
Science, pages 200210. Springer-Verlag Berlin Heidelberg, Cannes, France, 2001. (Cit
en page 83.)
[Quisquater & Samyde 2002] J.-J. Quisquater et D. Samyde. Eddy current for Magnetic Ana-
lysis with Active Sensor. In e-Smart, Nice, France, 2002. (Cit en page 85.)
Bibliographie 203
[Quisquater et al. 1989] J.-J. Quisquater, M. Quisquater, M. Quisquater, M. Quisquater, L. C.

Guillou, M. A. Guillou, G. Guillou, A. Guillou, G. Guillou, S. Guillou et T. A. Berson.
How to Explain Zero-Knowledge Protocols to Your Children. In G. Brassard, editeur,
CRYPTO, volume 435 of Lecture Notes in Computer Science, pages 628631, London,
UK, 1989. Springer. (Cit en page 4.)
[Rankl & Eng 2003] W. Rankl et W. Eng. Smart card handbook, pages 667734. John
Wiley & Sons, 2003. Overview about Attacks on Smart Cards. (Cit en pages 2 et 85.)
[Riscure 2012] Riscure. Riscure Security Tools, 2012. http://www.riscure.com/tools/inspector [En

[Rook 2011] D. Rook. Agnitio tool for security code review, 2011. http://sourceforge.net/projects/
agnitiotool/ [En ligne ; consult le 05-aot-2012]. (Cit en page 175.)
[Rothbart et al. 2004] K. Rothbart, U. Nee, C. Steger, R. Weiss, E. Rieger et A. Muehlberger.

High Level Fault Injection for Attack Simulation in Smart Cards. In 13th Asian Test
Symposium, ATS '04, pages 118121, Kenting, Taiwan, 2004. IEEE Computer Society.
(Cit en page 145.)
[Sabelfeld & Myers 2003] A. Sabelfeld et A. C. Myers. Language-based information-ow secu-

rity. IEEE Journal on Selected Areas in Communications, vol. 21, no. 1, pages 519,
2003. (Cit en page 51.)
[Samyde et al. 2002] D. Samyde, S. Skorobogatov, R. Anderson et J.-J. Quisquater. On a new

way to read data from memory. In First International IEEE Security in Storage Work-
shop, pages 6569, Greenbelt, MD, USA, 2002. IEEE Comput. Soc. (Cit en page 84.)
[Schellhorn et al. 2002] G. Schellhorn, W. Reif, A. Schairer, P. Karger, V. Austel et D. Toll.

Veried formal security models for multiapplicative smart cards. Journal of Computer
Security, vol. 10, no. 4, 2002. (Cit en page 50.)
[Schwan 2008] M. Schwan. Specication and verication of security policies for smart cards.
PhD thesis, Mathematisch-Naturwissenschaftliche Fakultt II, 2008. (Cit en page 50.)
[SCL 2012] Side Channel Lounge, 2012. http://imperia.rz.rub.de:9085/en_sclounge.html [En ligne ;

consult le 05-aot-2012]. (Cit en page 84.)
[Sere et al. 2011] A. Sere, J.-L. Lanet et J. Iguchi-Cartigny. Evaluation of Countermeasures

Against Fault Attacks on Smart Cards. International Journal of Security and Its Appli-
cations, vol. 5, no. 2, 2011. (Cit en page 145.)
[Shabtai et al. 2010] A. Shabtai, Y. Fledel et Y. Elovici. Securing Android-Powered Mobile

Devices Using SELinux. IEEE Security & Privacy, vol. 8, no. 3, pages 3644, 2010. (Cit
en page 50.)
[Shacham 2007] H. Shacham. The geometry of innocent esh on the bone : return-into-libc
without function calls (on the x86). In Conference on Computer and communications
Security, CCS '07, pages 552561, Alexandria, VA, USA, 2007. ACM. (Cit en page 100.)
[Skorobogatov & Anderson 2002] S. P. Skorobogatov et R. J. Anderson. Optical Fault Induction

Attacks. In B. S. Kaliski Jr., . K. Ko et C. Paar, editeurs, Cryptographic Hardware
and Embedded Systems - CHES, volume 2523 of Lecture Notes in Computer Science,
pages 212, Redwood Shores, CA, USA, 2002. Springer. (Cit en pages 28 et 85.)
204 Bibliographie
[Skorobogatov 2005] S. P. Skorobogatov. Semi-invasive attacks A new approach to hardware

security analysis. Rapport technique UCAM-CL-TR-630, University of Cambridge, Com-
puter Laboratory, 2005. (Cit en page 86.)
[Skorobogatov 2010] S. Skorobogatov. Optical Fault Masking Attacks. In Workshop on Fault

Diagnosis and Tolerance in Cryptography, Fault Diagnosis and Tolerance in Cryptogra-
phy, pages 2329, Santa Barbara, California, USA, 2010. IEEE Computer Society. (Cit
en page 86.)
[Spinroot 2012] Spinroot. Static Source Code Analysis Tools for C, 2012. http://spinroot.com/
static/ [En ligne ; consult le 05-aot-2012]. (Cit en page 174.)
[Srivatanakul et al. 2005] T. Srivatanakul, J. A. Clark et F. Polack. Stressing Security Require-

ments : Exploiting the Flaw Hypothesis Method with Deviational Techniques. In Sympo-
sium on Requirements Engineering for Information Security, Paris, France, 2005. (Cit
en page 143.)
[Tarnovsky 2010] C. Tarnovsky. Deconstructing a Secure Processor. In Black Hat, Wa-

shington, DC, USA, 2010. https://media.blackhat.com/bh-dc-10/video/Tarnovsky_Chris/
BlackHat-DC-2010-Tarnovsky-DeconstructProcessor-video.m4v [En ligne ; consult le 05-aot-
2012]. (Cit en page 28.)
[Teuwen 2010] P. Teuwen. How to Make Smartcards Resistant to Hackers' Lightsabers ? In

J. Guajardo and B. Preneel and A.-R. Sadeghi and P. Tuyls, editeur, Foundations for
Forgery-Resilient Cryptographic Hardware, pages 18, Dagstuhl, Germany, 2010. (Cit
en page 90.)
[Thorn 1999] T. Thorn. Vrcation de politiques de scurit par analyse de programmes. PhD
thesis, Universit de Rennes I, Ifsic, Irisa, 1999. (Cit en page 51.)
[van Heesch 2008] D. van Heesch. Doxygen : Source code documentation generator tool, 2008.
http://www.stack.nl/~dimitri/doxygen/ [En ligne ; consult le 05-aot-2012]. (Cit en
page 176.)
[van Woudenberg et al. 2011] J. G. van Woudenberg, M. F. Witteman et F. Menarini. Practical

Optical Fault Injection on Secure Microcontrollers. In Workshop on Fault Diagnosis and
Tolerance in Cryptography, pages 9199, Los Alamitos, CA, USA, 2011. IEEE Computer
Society. (Cit en page 27.)
[Verbauwhede et al. 2011] I. Verbauwhede, D. Karaklajic et J.-M. Schmidt. The Fault Attack
Jungle - A Classication Model to Guide You. In Workshop on Fault Diagnosis and
Tolerance in Cryptography, pages 38, Nara, Japan, 2011. Ieee. (Cit en page 85.)
[von Oheimb et al. 2003] D. von Oheimb, G. Walter et V. Lotz. A Formal Security Model of
the Inneon SLE 88 Smart Card Memory Managment. In E. Snekkenes et D. Gollmann,
editeurs, 8th European Symposium on Research in Computer Security - ESORICS, vo-
lume 2808 of Lecture Notes in Computer Science, pages 217234, Gjvik, Norway, 2003.
Springer. (Cit en page 52.)
[Wagner 2004] D. Wagner. Cryptanalysis of a Provably Secure CRT-RSA Algorithm. In 11th

ACM conference on Computer and communications security, pages 9297, Washington,
DC, USA, 2004. (Cit en page 81.)
[Wikipedia 2012a] Wikipedia. EMV Vulnerabilities, 2012. http://en.wikipedia.org/wiki/EMV#

Vulnerabilities [En ligne ; consult le 05-aot-2012]. (Cit en page 18.)
Bibliographie 205
[Wikipedia 2012b] Wikipedia. George Hotz, 2012. http://en.wikipedia.org/wiki/George_Hotz [En

[Wikipedia 2012c] Wikipedia. Norme Iso 14443, 2012. http://en.wikipedia.org/wiki/ISO/IEC_14443

[Wikipedia 2012d] Wikipedia. Norme Iso 7816, 2012. http://en.wikipedia.org/wiki/ISO/IEC_7816

[Williams et al. 2005] N. Williams, B. Marre, P. Mouy et M. Roger. PathCrawler : Automatic

Generation of Path Tests by Combining Static and Dynamic Analysis. In M. D. Cin,
M. Kaniche et A. Pataricza, editeurs, Fifth European Dependable Computing Confe-
rence, volume 3463 of Lecture Notes in Computer Science, pages 281292, Budapest,
Hungary, 2005. Springer. (Cit en page 181.)
[Wolf 1994] W. Wolf. Hardware-Software Co-Design of Embedded Systems. Proceedings of the

IEEE, vol. 82, no. 7, pages 967989, 1994. (Cit en page 190.)
[Zanotti 2002] M. Zanotti. Security Typings by Abstract Interpretation. In 9th International

Symposium on Static Analysis - SAS, SAS '02, pages 360375, Madrid, Spain, 2002.
Springer-Verlag. (Cit en page 52.)
Glossaire
8051 Intel 8051 ou 8051 est un microcontrleur (MC) dvelopp par Intel en 1980 pour tre
utilis dans des produits embarqus. C'est encore une architecture populaire ; de nombreux
microcontrleurs plus rcents incorporent un coeur 8051, complt par un certain nombre
de circuits priphriques intgrs sur la mme puce, et dots de mmoires de plus grande
capacit.. 9
Android Android est un systme d'exploitation open source3 utilisant le noyau Linux, pour
smartphones, tablettes tactiles, PDA et terminaux mobiles conu par Android, une star-
tup rachete par Google, et annonc ociellement le 5 novembre 20074. D'autres types
d'appareils possdant ce systme d'exploitation existent, par exemple des tlviseurs et
des tablettes.. 50
ANSSI L'Agence nationale de la scurit des systmes d'information est une agence charge
de la scurit informatique rattache au Secrtariat gnral de la dfense et de la scurit
nationale.. 10
APDU APDU (Application Protocol Data Unit) est une trame unitaire normalise de commu-
nication entre le terminal et la carte.. 16
Canal+ Canal+ (stylise CANAL+) est une chaine de tlvision gnraliste franaise prive
page axe sur le cinma et le sport. Toute premire chaine prive page en France, elle
appartient au groupe Canal+ (liale du groupe Vivendi).. 9
CESTI Centre d'valuation de la scurit des technologies de l'information est un prestataire de

service, indpendant, charg d'valuer la conformit d'un produit aux Critres communs..
10
Checksum Un checksum ou somme de contrle est une forme de contrle par redondance. Cette
empreinte est une valeur utilise pour s'assurer qu'une donne est mmorise ou transmise
sans erreur.. 25
DLL En informatique, une bibliothque ou bibliothque de programmes est un ensemble de

fonctions utilitaires, regroupes et mises disposition an de pouvoir tre utilises sans
avoir les rcrire. Les fonctions sont regroupes de par leur appartenance un mme
domaine conceptuel (mathmatique, graphique, tris, etc). Les bibliothques logicielles se
distinguent des excutables dans la mesure o elles ne reprsentent pas une application.
Elles ne sont pas compltes, elles ne possdent pas l'essentiel d'un programme comme une
fonction principale et par consquent ne peuvent pas tre excutes directement. 170
ECC En cryptographie, les courbes elliptiques, des objets mathmatiques, peuvent tre utilises
pour des oprations asymtriques comme des changes de cls sur un canal non-scuris ou
un chirement asymtrique, on parle alors de cryptographie sur les courbes elliptiques ou
ECC (de l'acronyme anglais Elliptic curve cryptography). L'usage des courbes elliptiques
en cryptographie a t suggr, de manire indpendante, par Neal Koblitz et Victor Miller
en 1985.. 4
208 Glossary
EMVCo Europay Mastercard Visa, abrg par le sigle EMV, est depuis 1995 le standard inter-
national de scurit des cartes de paiement (cartes puce). Il tire son nom des organismes
fondateurs : Europay International (absorb par Mastercard en 2002), MasterCard Inter-
national et Visa International. 16
FIB La Sonde ionique focalise, plus connue sous le nom du sigle anglais FIB (Focused ion
beam), est un instrument scientique qui ressemble au microscope lectronique balayage
(MEB). Mais l o le MEB utilise un faisceau d'lectrons focaliss pour faire l'image
d'un chantillon, la "FIB" utilise un faisceau d'ions focaliss, gnralement du gallium.
Il est en eet facile de construire une source mtal liquide (LMIS, de l'anglais liquid
metal ion source. Contrairement aux MEB, les FIB sont destructives. Par consquent, leur
domaine d'applications est plus la microfabrication que la microscopie. Les principaux
domaines d'applications sont la science des matriaux et en particulier le domaine des
semiconducteurs et des circuits intgrs.. 28
fuzzing Le fuzzing est une technique pour tester des logiciels. L'ide est d'injecter des donnes
alatoires dans les entres d'un programme. Si le programme choue (par exemple en
crashant ou en gnrant une erreur), alors il y a des dfauts corriger.. 18, 44
GIE CB Le Groupement des Cartes Bancaires CB est un groupement d'intrt conomique

priv qui runit la plupart des tablissements nanciers franais dans le but d'assurer
l'interbancarit des cartes de paiement.. 6
Javacard Java Card fait rfrence la technologie dveloppe par Sun maintenant Oracle qui
permet l'excution d'application sous forme d'applet Java sur un support telle qu'une carte
puce Java Card est un environnement d'excution Java destin aux applications pour
Carte puce. Cette technologie fournit un environnement scuris pour les applications
qui fonctionnent sur ce support de capacit mmoire et de traitement limits. De multiples
applications peuvent tre dployes avant et mme aprs que la Carte puce a t four-
nie l'utilisateur nal. Les applications crites dans le langage de programmation Java
peuvent tre excutes en toute scurit sur l'ensemble des types de cartes disponibles sur
le march.. 9, 23
Linux Linux ou GNU/Linux, est un systme d'exploitation libre fonctionnant avec le noyau
Linux. C'est une implmentation libre du systme UNIX respectant les spcications PO-
SIX. Linux est le systme le plus utilis sur les super-ordinateurs et les smartphones. Sur
les serveurs informatiques, le march est partag avec les autres Unix et Windows. Il est
largement utilis comme systme embarqu dans les appareils lectroniques : tlvision,
modem, GPS, etc.. 50
Mastercard MasterCard Worldwide (NYSE : MA) est une entreprise amricaine de systme
de paiement dont le sige est Purchase, New York. Jusqu'en 2006, c'tait une socit
cooprative dtenue par plus de 25 000 institutions nancires. Depuis, elle est une socit
cote en Bourse. MasterCard est aussi la marque de cartes de crdit, un des produits de
cette socit.. 9
Glossary 209
Mifare MIFARE est une des technologies de carte puce sans contact les plus rpandues dans
le monde avec 3,5 milliards de cartes et 40 millions de modules de lecture/encodage. La
marque, lance par Philips, est proprit de la socit NXP.. 9
Moneo Moneo (parfois crit Mono) est le seul systme de porte-monnaie lectronique utilis
en France en 2011. Il peut tre matrialis sur une carte bancaire ou sur une carte ddie
cet usage. Les montants concerns par les transactions sont de l'ordre de la petite monnaie
(distributeur, automate, caf, musique, boulangerie, journal, parcmtre, etc.).. 9
MultOS MULTOS ("Multiple Operating System") est un systme d'exploitation qui permet
l'aide d'une machine virtuelle d'xcuter plusieurs applications direntes de manire
scurise sur la mme carte puce.. 10
Passe Navigo Un passe Navigo est une carte puce sans contact, utilisant la technologie RFID
(Radio Frequency IDentication, radio-identication) ou plus prcisment NFC (Near Field
Communication, communication en champ proche), qui sert de support pour certains for-
faits d'abonnement utilisables dans les transports en le-de-France sur les rseaux RATP,
SNCF et Optile. Sa mise en oeuvre est supervise par le STIF, qui est propritaire de la
marque.. 9
OpenCard La plate-forme OpenCard est un middleware implment en Java.. 10
PIN Personal Identication Number se composant souvent de 4 chires, sa connaissance permet

avec la possession d'une carte puce associe d'authentier le porteur auprs d'une banque
et de raliser des transactions bancaires. 8
SIM La carte SIM (de l'anglais Subscriber Identity Module) est une puce contenant un mi-
crocontrleur et de la mmoire. Elle est utilise en tlphonie mobile pour stocker les
informations spciques l'abonn d'un rseau mobile, en particulier pour les rseaux de
type GSM ou UMTS. Elle permet galement de stocker des applications de l'utilisateur,
de son oprateur ou dans certains cas de tierces parties.. 9
VISA VISA est une marque de carte de paiement de la Visa International Service Association.
VISA est aussi le nom de l'entreprise commune compose de quelque 21 000 socits
nancires (banques, socits de crdit).. 9
Table des Figures
1.1 Schma d'une authentication hors ligne ne ncessitant pas de participation de la
banque dans la transaction [Bayart 2012] . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Schma d'une authentication en ligne authentiant la carte auprs de la banque

au moment de la transaction [Bayart 2012] . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Schma d'authentication bancaire . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Schma d'authentication tlphonique . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Description simplie des direntes tapes dans le processus de dveloppement

du logiciel d'une carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6 Une simulation logicielle des tests de scurit matrielle entraine une conomie de
tests physiques plus longs et plus couteux . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Itration prliminaire entre la phase de dveloppement et la phase de test logiciel

simpliant la phase de test matriel . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.8 Schma simpli d'une carte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.9 Schma d'une carte [Consultants 2009] . . . . . . . . . . . . . . . . . . . . . . . . 20
1.10 Illustration du micromodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.11 Architecture interne du microprocesseur [Litwak 1999] . . . . . . . . . . . . . . . 24
1.12 Vue d'une puce et des dirents composants mmoire [Guilley 2007] . . . . . . . 26
1.13 Banc d'attaque laser, source : Oberthur Technologies . . . . . . . . . . . . . . . . 29
1.14 Axes d'approche du problme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.15 La place de la scurit dans le contexte embarqu . . . . . . . . . . . . . . . . . . 45
2.1 volution des informations l'intrieur des conteneurs correspondant au code du

listing 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.2 Avec une mthode d'observation et un point d'observation certains conteneurs,

ainsi que l'information qu'ils abritent, sont visibles . . . . . . . . . . . . . . . . . 58
2.3 La condentialit est directement compromise si une information se trouve dans

un conteneur visible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.4 volution des informations l'intrieur des conteneurs correspondant au code du

listing 2.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.5 Exemple de dure de vie d'un conteneur et dure de vie d'une information
l'intrieur d'un conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1 Fuite d'informations par les canaux d'observation auxiliaires . . . . . . . . . . . . 83
3.2 Exemple d'un code C et son quivalent en assembleur 8051C . . . . . . . . . . . . 92
3.3 Illustration de la notion de vol et des tapes . . . . . . . . . . . . . . . . . . . . . 99
3.4 Cas 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.5 Champ d'application du lemme et du thorme au niveau des blocs basiques . . . 104
5.1 Schma de la mthodologie adopte pour l'analyse scuritaire . . . . . . . . . . . 142
5.2 Vue d'ensemble de la plate-forme exprimentale . . . . . . . . . . . . . . . . . . . 143
5.3 Reprsentation 2D des rsultats donn par un oracle . . . . . . . . . . . . . . . . 147

5.4 Nombre d'attaques pour chaque catgorie en fonction du dlai d'expiration (en
utilisant la mthode gdb) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.5 Rsultats d'attaques permanentes ralises en C sur le code de bzip2 . . . . . . 152
5.6 Rsultats d'attaques permanentes ralises en C sur le code de gzip . . . . . . . 154
5.7 Gnome de bzip2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.8 Gnome de gzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.9 Comparaison des gnomes de bzip2 et gzip . . . . . . . . . . . . . . . . . . . . 157
5.10 Les attaques transientes injectes avec gdb dans la totalit de bzip2 . . . . . . . 158
5.11 Classement des attaques transientes pour la fonction mainQSort3 de bzip2 en
fonction du moment o l'attaque est dclenche . . . . . . . . . . . . . . . . . . . 158
5.12 Distribution des attaques permanentes injecte au niveau ASM / C pour les fonc-
tions de bzip2 de plus de 7 instructions . . . . . . . . . . . . . . . . . . . . . . . 159
5.13 Nombre d'attaques en fonction de la taille du saut exprim en lignes de code C . 161
5.14 Classication spatiale des attaques good/bad/kill en fonction des lignes source et
destination, simules en C pour la fonction BZ2_compressBlock . . . . . . . . . . 161
destination, simules en C pour la fonction BZ2_blockSort . . . . . . . . . . . . . 162
destination, simules en C pour la version scurise de BZ2_blockSort . . . . . . 163
5.17 Classication spatiale des attaques kill/bad/error en fonction des lignes source
et destination, simules en C pour une fonction sensible du code source de d'une
carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.18 Nombre de rsultats BAD en fonction de la distance de l'attaque par saut . . . . 166
6.1 Liste de vrication dans le code . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

6.2 volution du code au cours des revues . . . . . . . . . . . . . . . . . . . . . . . . 175
6.3 Exemple de documentation gnre avec Doxygen . . . . . . . . . . . . . . . . . . 176
6.4 Exemple de rsultats obtenus par l'outil . . . . . . . . . . . . . . . . . . . . . . . 178
6.5 Frama-C - Analyse de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.6 Frama-C - Impact d'une instruction . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.7 Rduction progressive de la complexit du programme par interrogation du graphe
d'appels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.8 Rduction l'chelle d'un module puis d'un ensemble de fonctions . . . . . . . . 184
Liste des Tableaux
3.1 Croisement entre la cible et les eets d'une attaque . . . . . . . . . . . . . . . . . 89
4.1 Rgles de typage pour les appels de fonctions . . . . . . . . . . . . . . . . . . . . 121
4.2 Exemple de valeurs pour la fonction LineT ypeAf ter avec une condition . . . . . 132
5.1 Statistiques des attaques simules sur bzip2 . . . . . . . . . . . . . . . . . . . . 159
5.2 Couverture d'attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.1 Croisement entre les fonctions et les globales utilises . . . . . . . . . . . . . . . . 186
Liste des Listings

1.1 Exemple d'une implmentation d'authentication basique avec une tche fonc-
tionnelle scuritaire sensible mais sans code contre attaques physiques . . . . . . 32
1.2 Exemple d'une implmentation d'authentication basique avec une tache fonc-
tionnelle scuritaire sensible avec quelques dfenses additionnelles contre les at-
taques physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.3 Condition non scurise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.4 Condition scurise naivement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.5 Implmentation C d'une condition . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.6 Traduction de cette condition en assembleur 68000 . . . . . . . . . . . . . . . . . 39
1.7 Condition scurise avec une premire mthode . . . . . . . . . . . . . . . . . . . 40
1.8 Requte schmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.9 Exemple simple d'une fonction avec doublement scuritaire qui n'a pas d'impact
sur la nalit fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.1 Cas particulier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.2 Exemple d'une implmentation basique d'un mcanisme d'authentication . . . . 53
2.3 Transfert d'information par conteneur . . . . . . . . . . . . . . . . . . . . . . . . 55
2.4 volution d'une information par aectation directe de valeur . . . . . . . . . . . 55
2.5 Transfert d'information sans attaque . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.6 Transfert d'information avec attaque . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.7 Exemple de transfert d'information dans des conteneurs . . . . . . . . . . . . . . 63
2.10 dchirement d'une information condentielle . . . . . . . . . . . . . . . . . . . . 68
2.11 Comparaison chire d'une information condentielle . . . . . . . . . . . . . . . . 68
214 Liste des Listings
2.12 Zone de garantie souhaite pour l'intgrit du conteneur card_pin sous attaque . 70
2.13 Intgrit d'excution d'une condition en C . . . . . . . . . . . . . . . . . . . . . . 74
2.14 Intgrit d'excution d'une boucle en C . . . . . . . . . . . . . . . . . . . . . . . . 74
2.15 Intgrit d'excution d'un appel de fonction en C . . . . . . . . . . . . . . . . . . 75
2.16 Intgrit d'excution d'un appel de fonction en C . . . . . . . . . . . . . . . . . . 75
3.1 Exemple de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.2 Modication de la valeur d'une variable . . . . . . . . . . . . . . . . . . . . . . . 87
3.3 Attaque par saut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.4 Attaque par non excution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.5 Exemple d'une injection d'un nop qui permet la dcouverte du pin en 9999 essais 91
3.6 Exemple d'une fonction C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.7 quivalent assembleur de la fonction exemple . . . . . . . . . . . . . . . . . . . . 92
3.8 Simulation 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.9 Simulation 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.10 Simulation 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.11 Simulation 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.12 Simulation 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.13 Simulation 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.14 Simulation 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.15 Code original . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.16 Code avec attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.17 Exemple d'une attaque simple consquences multiple . . . . . . . . . . . . . . . 105
3.18 Code original . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.19 Consquence multiples : criture + saut . . . . . . . . . . . . . . . . . . . . . . . 106
3.20 Consquence multiples : criture + criture . . . . . . . . . . . . . . . . . . . . . 106
3.21 Version scurise d'une condition vulnrable une attaque par saut simple . . . . 106
3.22 Traduction en assembleur du code C du listing 3.21 . . . . . . . . . . . . . . . . 107
3.23 Traduction en assembleur du code C du listing 3.21 sous attaque . . . . . . . . . 107
3.24 Equivalent C du code assembleur attaqu . . . . . . . . . . . . . . . . . . . . . . 107
4.1 Exemple de code C pour une transaction bancaire . . . . . . . . . . . . . . . . . . 112
4.2 Exemple de code C pour une transaction bancaire avec des annotations acsl . . 113
4.3 Analyse Frama-C du listing 4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.4 Patch pour l'audit de la variable globale number1 . . . . . . . . . . . . . . . . . . 116
4.5 Extrait du chier d'audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.6 Injection des annotations acsl partir des informations collectes . . . . . . . . 117
4.7 Analyse Frama-C avec les nouvelles informations . . . . . . . . . . . . . . . . . . 118
4.8 Analyse Frama-C avec une attaque de valeur simule . . . . . . . . . . . . . . . . 119
4.9 Code d'exemple illustrant les fonctions de typage . . . . . . . . . . . . . . . . . . 122
4.10 Exemple de code contenant un if . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.11 i en dehors de la condition x non utilis . . . . . . . . . . . . . . . . . . . . . . 128
4.12 i en dehors de la condition x dans condition . . . . . . . . . . . . . . . . . . . 129
4.13 i en dehors de la condition x dans then . . . . . . . . . . . . . . . . . . . . . . 129
4.14 i en dehors de la condition x dans then et else . . . . . . . . . . . . . . . . . . 129
4.15 i dans then x non utilis dans then . . . . . . . . . . . . . . . . . . . . . . . . 130
4.16 i dans then x utilis dans then avant et aprs i. . . . . . . . . . . . . . . . . . 130
4.17 i dans then x utilis dans then aprs i . . . . . . . . . . . . . . . . . . . . . . 130
4.18 i dans then x utilis dans then avant i . . . . . . . . . . . . . . . . . . . . . . 130
4.19 i en dehors de la boucle x non utilis . . . . . . . . . . . . . . . . . . . . . . . 132
4.20 i en dehors de la boucle x utilis dans la condition . . . . . . . . . . . . . . . . 133
4.21 i en dehors de la boucle x utilis dans la boucle . . . . . . . . . . . . . . . . . 133
4.22 i dans la boucle x utilis dans la boucle aprs i . . . . . . . . . . . . . . . . . 133
4.23 i dans la boucle x utilis dans la boucle avant i . . . . . . . . . . . . . . . . . 134
4.24 i dans la boucle x utilis dans la condition . . . . . . . . . . . . . . . . . . . . 134
4.25 i dans la boucle x non utilis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.26 Fichiers crs par le prototyle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.1 Exemple d'une zone de code saute . . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.2 Implmentation d'une contre-mesure pour la fonction BZ2_blockSort ne ncessi-
tant pas de dcalage de la numrotation des lignes du code de dpart . . . . . . . 163
6.1 Exemple de code pour catgorisation par mots cls . . . . . . . . . . . . . . . . . 177
6.2 Exemple de code pour catgorisation par mots cls . . . . . . . . . . . . . . . . . 179
6.3 Explorateur interactif de code source en ligne de commande . . . . . . . . . . . . 182
6.4 Exemple de chemins obtenus dans le graphe d'appel du programme . . . . . . . . 182
6.5 Commandes utilises pour crer les graphes . . . . . . . . . . . . . . . . . . . . . 185
6.6 Exemple de recherche de formes de code interprocdurale . . . . . . . . . . . . . 185
6.7 Exemple de code source pour recherche de formes de code interprocdurale . . . . 186
Liste des Algorithmes

1 Calcul de TypeAfter pour un code squentiel . . . . . . . . . . . . . . . . . . . . 121
2 Calcul de LineT ypeAf ter pour un code linaire . . . . . . . . . . . . . . . . . . . 122
3 Fonction TypeAfter pour les conditions . . . . . . . . . . . . . . . . . . . . . . . . 126
4 Fonction LineTypeAfter pour les conditions . . . . . . . . . . . . . . . . . . . . . 127
5 Code ajouter la dnition de TypeAfter . . . . . . . . . . . . . . . . . . . . . 135
6 Modications apporter LineTypeAfter prenant en compte les boucles . . . . . 136
Colophon
AT X et Vim partir d'un template par Olivier Commo-
Cette thse a t ralise avec L E
wick. La fonte utilise pour les listing est DejaVu Sans Mono. Le glossaire a t cr partir de
Wikipdia. Les images proviennent de http://openclipart.org.
Xavier KAUFFMANN-TOURKESTANSKY
Analyses scuritaires de codes de carte puce
sous attaques physiques simules
Cette thse sintresse aux effets des attaques par fautes physiques sur le code dun systme
embarqu en particulier la carte puce. De telles attaques peuvent compromettre la scurit du
systme en donnant accs des informations confidentielles, en compromettant lintgrit de don-
nes sensibles ou en perturbant le fonctionnement pendant lexcution. Dans cette thse, nous
dcrivons des proprits de scurit permettant dexprimer les garanties du systme et tablissons
un modle dattaque de haut niveau dfinissant les capacits dun attaquant modifier le systme.
Ces proprits et ce modle nous servent vrifier la scurit du code par analyse statique ou test
dynamique, combins avec linjection dattaques, simulant les consquences logicielles des fautes
physiques. Deux mthodologies sont ainsi dveloppes afin de vrifier le comportement fonctionnel
du code sous attaques, tester le fonctionnement des scurits implmentes et identifier de nou-
velles attaques. Ces mthodologies ont t mises en uvre dans un cadre industriel afin de faciliter
le travail du dveloppeur charg de scuriser un code de carte puce.
Mots cls : code, scurit, attaques physiques, carte puce, information, proprits, confidentia-
lit, intgrit, analyse statique, test, injection de faute, vrification, preuve, modlisation, simulation
logicielle, optimisation, rduction, outils, certification, embarqu, analyse, comportement
Security Analysis of Smart Card C Code using Simulated Physical Attacks
This thesis focuses on the effects of attacks by physical faults on embedded source code specifically
for smart cards. Such attacks can compromise the security of the system by providing access to
confidential information, compromising the integrity of sensitive data or disrupting the execution flow.
In this thesis, we describe security properties to express security guarantees on the system. We
also offer an attack model defining at high level an attackers ability to disrupt the system. With
these properties and model, we check the source code security against physical attacks. We use
static analysis and dynamic testing, combined with attack injection to simulate the consequences of
physical faults at software level. Two techniques are created to stress the functional behavior of the
code under attack, test the reliability of built-in security countermeasures and identify new threats.
These techniques were implemented in a framework to help developers secure their source code in
an industrial environment.
Keywords : code, security, physical attacks, smart card, information, security properties, confidentia-
lity, integrity, static analysis, testing, fault injection, verification, proof, hardware modeling, software
simulation, optimization, reduction, tools, security model, certification, embedded, analysis, behavior
Laboratoire dInformatique Fondamentale dOrlans

Rue Lonard de Vinci
B.P. 6759 F-45067 ORLEANS Cedex 2

Analyses Sécuritaires de Code de Carte À Puce Sous Attaques Physiques Simulées

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Analyses Sécuritaires de Code de Carte À Puce Sous Attaques Physiques Simulées

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIT DORLANS

COLE DOCTORALE MATHMATIQUES, INFORMATIQUE,

soutenue le : 28 novembre 2012

Analyses scuritaires de code de carte puce

THSE dirige par :

AT X mes cts et m'ont

Je tiens aussi remercier toute ma famille et en particulier ma soeur Soline et Anh ma

1.1.1 Facteur d'chelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 Dportement de la scurit et environnement hostile . . . . . . . . . . . . 3

1.1.3 Carte puce et cryptographie . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.4 Principe de fonctionnement d'une carte . . . . . . . . . . . . . . . . . . . 6

1.1.5 Diversit de l'cosystme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1.6 Processus d'valuation de la scurit et de certication . . . . . . . . . . . 10

1.2 Approche fonctionnelle et vision bas niveau . . . . . . . . . . . . . . . . . . . . . 11

1.2.1 Fabrication et utilisation fonctionnelle . . . . . . . . . . . . . . . . . . . . 12

1.2.2 Fonctionnement interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.3 Besoins en scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.3.1 Historique de la scurit des cartes . . . . . . . . . . . . . . . . . . . . . . 27

1.3.2 Attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.3.3 Problmatique globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.3.4 Proprits de scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1.3.5 Spcications fonctionnelles et scurits additionnelles . . . . . . . . . . . 32

1.3.6 Scurisation et angles d'attaque . . . . . . . . . . . . . . . . . . . . . . . . 38

1.3.7 Modlisation et vrication . . . . . . . . . . . . . . . . . . . . . . . . . . 40

1.3.8 Angle d'approche et rsum . . . . . . . . . . . . . . . . . . . . . . . . . . 44

1.4 Conclusion et annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2 Modlisation et proprits de scurit 49

2.1.1 Approches existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.1.2 Dcomposition de fonctionnalit . . . . . . . . . . . . . . . . . . . . . . . 53

2.1.3 Dcomposition en lments du langage . . . . . . . . . . . . . . . . . . . . 53

2.2 Formalisme utilis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.2.1 Information et conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.2.2 Ensemble d'informations visibles . . . . . . . . . . . . . . . . . . . . . . . 56

2.2.3 Zone de garantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

2.2.4 Type d'attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

2.2.5 Formalisation d'une proprit de scurit . . . . . . . . . . . . . . . . . . . 61

2.3 Condentialit d'une information . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2.3.1 Condentialit sous attaque . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.3.2 Zone de gnration d'information d'un conteneur . . . . . . . . . . . . . . 64

2.3.3 Zone de garantie de condentialit . . . . . . . . . . . . . . . . . . . . . . 66

2.3.4 Avantage pour l'attaquant et granularit de l'information . . . . . . . . . 67

2.4.1 Accs un conteneur et zone de garantie . . . . . . . . . . . . . . . . . . . 69

2.4.2 Intgrit en lecture et criture . . . . . . . . . . . . . . . . . . . . . . . . . 70

2.4.3 Avantage pour l'attaquant . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

2.4.4 Intgrit d'excution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

2.6.1 Aspects smantiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

2.6.2 Temporalit des proprits . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

2.6.3 Prise en compte du compilateur . . . . . . . . . . . . . . . . . . . . . . . . 77

2.6.4 Thorie de l'information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

2.6.5 Gnration automatique de proprits . . . . . . . . . . . . . . . . . . . . 78

3.2 Caractrisation de l'attaquant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.2.1 Capacit d'observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.2.2 Capacit d'action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.3 Modlisation des consquences haut niveau . . . . . . . . . . . . . . . . . . . . 87

3.4 Modle d'attaque physique haut niveau . . . . . . . . . . . . . . . . . . . . . . 88

3.4.1 Eets des attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.4.2 Importance des attaques par nop et par saut . . . . . . . . . . . . . . . . 90

3.4.3 Attaques de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.4.4 Attaques de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3.4.5 Dcalage d'interprtation du code . . . . . . . . . . . . . . . . . . . . . . . 97

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.6.1 Prise en compte d'attaques d'un ordre suprieur . . . . . . . . . . . . . . 105

1.1.6 Processus d'valuation de la scurit et de certication . . . . . . . . . . . 10

1.3.5 Spcications fonctionnelles et scurits additionnelles . . . . . . . . . . . 32

1.3.7 Modlisation et vrication . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.3 Condentialit d'une information . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2.3.1 Condentialit sous attaque . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.3.3 Zone de garantie de condentialit . . . . . . . . . . . . . . . . . . . . . . 66

3.4.1 Eets des attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . 88

4 Vrication de scurit sous attaques simules 109

4.2 Vrication statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.2.2 Vrication d'intervalle de valeurs . . . . . . . . . . . . . . . . . . . . . . 113

4.2.3 Limites de la vrication et solution . . . . . . . . . . . . . . . . . . . . . 115

4.2.5 Vrication de scurit et simulation d'attaques physiques . . . . . . . . . 118

5.2.2 Mthode de classication des rsultats . . . . . . . . . . . . . . . . . . . . 146

6.2.2 Processus de vrication de la scurit . . . . . . . . . . . . . . . . . . . . 170

6.4.3 Vrication de formes de code . . . . . . . . . . . . . . . . . . . . . . . . . 176

dcouvrir de nouvelles attaques ;

Nombre de cartes en circulation : eet de masse amplicateur pour la scurit La

Authentication du porteur de la carte avec un secret o un secret est chir et stock

La gure 1.1 illustre le mcanisme d'authentication de la carte dans un scnario ne nces-

Figure 1.3 Schma d'authentication bancaire

La tlphonie mobile dans laquelle la puce identiera l'appareil et implicitement l'utilisateur

La tlvision numrique dans laquelle la carte va permettre au consommateur nal quip

La carte multi-services pouvant regrouper des ores de dlisation et d'autres applications