. Repères) CARTES À PUCE La carte à puce et les circuits

. Repères)
CARTES À PUCE
La carte à puce
et les circuits asynchrones
Par Jacques FOURNIER, Simon W. MOORE
Security Technologies Department, Gemplus Computer Lab, University of Cambridge
Mots clés
Carte à puce,
Circuits asynchrones,
Technologies Dual Rail,
Analyses en courant
(DPA, CPA),
Analyses en rayonnements
électromagnétiques (EMA),
Attaques par injections
defautesDFA
Introduction
Durant ces dix dernières années, la carte à puce a
connu une évolution étonnante, allant de la simple carte à
mémoire de nos légendaires cartes téléphoniques aux cartes
à micro-contrôleur comme celles utilisées dans les SIM
(Subscriber Identification Module) de nos téléphones
portables. La grande majorité de celles déployées aujourd'hui
est dotée de processeurs CISC de la famille des 8051. Les
dernières cartes à micro-contrôleur ont des cceurs RISC
32 bits. Elles sont aussi dotées de co-processeurs dédiés
à la cryptographie à clef privée (DES, AES) ou à clef
publique (RSA, courbes elliptiques). La carte à puce
d'aujourd'hui est un véritable ordinateur optimisé pour les
calculs de cryptographie avancée. Néanmoins, l'intégra-
tion de processeurs 32 bits au sein d'une carte à puce n'est
pas une fin en soi : cette technologie a devant elle d'autres
défis à relever, tant au niveau des performances qu'au
niveau de la sécurité. Car même si un processeur RISC
32 bits peut offrir des performances plus qu'acceptables,
les besoins en matière de consommation et de sécurité consti-
tuent un sérieux frein à la pleine exploitation de ce potentiel.
Dans cet article, nous nous intéresserons d'abord aux
défis auxquels la carte à puce doit faire face aujourd'hui
au niveau matériel. Ensuite nous passerons en revue les
caractéristiques des circuits asynchrones, où nous verrons
en quoi ces dernières présentent une alternative si
attrayante pour la carte à puce, en particulier en matière
de sécurité. Nous illustrerons ensuite nos propos en décrivant
l'architecture XAP asynchrone développée par l'Université
de Cambridge, et l'analyse sécuritaire effectuée à Gemplus
sur ce coeur [1]. Nous conclurons en portant un bref
regard sur le rôle de la technologie asynchrone dans le
marché de la carte à puce.
2. Défis pour les processeurs
Même si l'évolution des technologies a permis l'inté-
gration d'un calculateur aussi puissant qu'un RISC 32 bits
dans les 25 mm2 normés d'une carte à puce, nous sommes
encore loin d'utiliser tout le potentiel de telles architec-
tures. Ces dernières apportent de la puissance de calcul.
Mais à cette notion de puissance (et de performance) est
liée celle de la consommation en courant. Même si ces
architectures sont capables d'être cadencées à plusieurs
centaines de MHz, la carte à puce, elle, est très limitée en
consommation (7 mA pour le GSM et 10 mA pour le 3G
si nous nous référons aux cartes SIM utilisées dans la
téléphonie mobile). Par conséquent les vitesses de tels
processeurs, une fois intégrés dans un système carte à
puce, sont limitées à quelques dizaines de MHz, et ce
pour les plus performantes d'entre elles. Ainsi, réduire la
consommation des cartes à micro-contrôleur est l'un des
défis que doit relever l'industrie.
De plus, la complexité de tels systèmes ne fait
qu'augmenter la difficulté d'y distribuer une horloge de
e
s s
Les circuits asynchrones reviennent sur le devant de la scène,
notamment dans le domaine de la carte à puce, grâce à leurs
propriétés de basse consommation et leur potentiel en matière
de sécurité. Dans cet article nous étudions comment les circuits
asynchrones peuvent accroître la sécurité des cartes à puce. Pour
cela nous nous intéresserons aux résultats obtenus lors de
l'étude sécuritaire d'un circuit de test dont le processeur a été
implémenté en technologie asynchrone.
SYNOPSIS
Asynchronous devices are back in the limelight, with low
consumption and security capabilities appearing especially attrac-
tive for smart card applications. This article discusses how asyn-
chronous devices can improve smartcard security. Specifically, we
outline the results of a security study on a test circuit with asyn-
chronous-technoiogy processor.
REE
W 6/7
Juin/Juillet 2004

La carte à puce et les circuits asynchrones
façon synchrone et non-biaisée. La logique requise pour
obtenir une distribution correcte de l'horloge est d'une
complexité croissante et, bien évidemment, devient très
vite gourmande en consommation d'énergie.
Finalement, les besoins en sécurité sont plus présents
que jamais. L'une des principales difficultés liée à ce
besoin est de trouver un compromis entre ces besoins en
sécurité, les contraintes de consommation, celles de per-
formance et les coûts de développement.
2.1. Besoins en matière de sécurité
Au sein d'une architecture de sécurité, la carte à puce
est vue comme le module de confiance. C'est la gardienne
des clefs d'identité de son propriétaire, le coffre-fort dans
lequel sont exécutés les algorithmes de chiffrement et
d'authentification. Ainsi, les contraintes de sécurité sur la
carte à puce sont d'une grande importance, d'autant que
récemment nous avons eu droit à une " épidémie " d'at-
taques potentielles sur ces supports :
. Attaques invasives : cette famille d'attaques com-
prend l'ouverture du module de la carte à puce afin
de mettre la puce à nu. Ensuite l'utilisation d'outils
tels qu'un FIE (Focussed Ion Beam) permet à un
attaquant de modifier l'architecture du processeur
et de ses périphériques, ou de faire du " reverse-
engineering " afin de découvrir l'architecture
implémentée [2].
. Attaques se mi-invasives : ces techniques incluent
les attaques par injection de fautes. En variant
brusquement la tension d'alimentation, l'horloge du
processeur ou en illuminant ce dernier à l'aide d'un
faisceau laser, le comportement du processeur est
modifié de sorte que la faute injectée peut servir à
cryptanalyser les algorithmes cryptographiques
exécutés.
. Attaques non-invasives : ces attaques sont
menées en analysant les canaux cachés de la carte
à puce : en mesurant le courant consommé par la
puce [3] ou en récoltant son rayonnement électro-
magnétique EM [4], un attaquant est capable de
déterminer (en appliquant des techniques d'ana-
lyses dites différentielles) la valeur de la clef secrète
manipulée pendant ces mesures. Lorsqu'on attaque
via la mesure de courant on parle de DPA (Differetctial
Power Anal'ysis) ou de CPA (Correlation Power
Analysis), et quand on s'intéresse au champ EM, on
se réfère alors à la DEMA (Differential Electro-
Magnetic Anal,sis) [5].
Durant ces six dernières années, ces failles de sécurité
ont longuement occupé des équipes de recherche aussi
bien académiques qu'industrielles : une pléiade de contre-
mesures a été développée, la grande majorité intervenant
principalement au niveau logiciel. Ces contre-mesures
logicielles, aussi efficaces soient-elles, dégradent énor-
mément les performances des cartes à puces, et occupent
une espace mémoire non négligeable. Elles ne touchent
cependant pas au fond du problème qui rend de telles
attaques possibles : les architectures et technologies
matérielles utilisées pour la fabrication de ces processeurs.
Ainsi naît le besoin de développer une architecture maté-
rielle qui permettrait de faire face à de telles attaques.
Dans les paragraphes suivants, nous nous intéresserons
principalement à l'architecture du processeur, ce qui res-
treint notre espace d'attaques à celles qui sont semi-inva-
sives et non-invasives.
3. Motivations en faveur de l'utilisation des
circuits asynchrones
Cette quête d'une architecture matérielle résistante aux
attaques semi et non-invasives a mené plusieurs groupes
de chercheurs à s'intéresser aux circuits asynchrones. Alors
que la grande majorité des ordinateurs d'aujourd'hui sont
cadencés à l'aide d'une horloge qui régit l'exécution de
chaque opération, les processeurs asynchrones ont la
caractéristique première de fonctionner sans horloge.
Ainsi chaque unité du processeur asynchrone n'attend pas
de coup d'horloge pour lancer une exécution ou acquisi-
tion/transmission de données. Elle est libre de fonctionner
à son rythme, et ce dès qu'elle reçoit une nouvelle donnée
ou qu'elle est prête à en transmettre une. Dans un circuit
synchrone, la communication entre deux entités est régie
par les fronts d'horloge qui servent aussi de garantie pour
déterminer la stabilité et la validité des données tranférées.
Par contre, dans un circuit sans horloge, la communication
entre des unités se fait via un protocole de " dialogue "
(handshake) [6,7]. On distingue alors deux grandes
familles de réalisation de ce protocole de " handshake " :
a Encodage en Il Bundled Data " (BD) : soit un
émetteur E qui veut transmettre une donnée de n bits à R.
L'encodage BD préconise le rajout de deux signaux de
communication : une requête Req de E vers R et une quit-
tance Qui de R vers E. Un délai est rajouté sur le signal
Req pour garantir que les n bits de la donnée sont tous
valides lorsque Req arrive à R.
Req >
<Qui
EMETTEUR RECEPTEUR
BRHM
Figure I. Encodage en Bundled Data.
. Encodage insensible aux délais (DI) : dans ce cas
un encodage redondant m-sur-p est utilisé pour la donnée.
L'encodage redondant permet de déterminer quand une
nouvelle donnée valide est transmise vers R. Ainsi, le
REE
W 6/7
JLiin/Juillet 2004

m Repères
CARTES À PUCE
1
signal Req disparaît, d'où le nom " insensible atix délais'.
L'encodage redondant le plus communément utilisé est la
Dual Rail (DR) où chaque bit de la donnée est représenté
par deux bits comme illustré par le tableau ci-après.
/. ? S ! gn ! f ! j : ation
AO A 1 Signitication
a a Neutre
a 1 0 logique
Il - 1 - -- - - 0 - 1 logique
1 1 Alarme
<i- Qui
data [Oi
EMETTEUR data [O] 1 .,. RECEPTEUR
2n bits
ci ata [ii- 11
datafn-1 1 1
1
Figure 2. Et2codage ert " Dual Rail ".
La nature des circuits asynchrones permet alors de
construire l'argumentaire suivant. L'absence d'horloge
permet non seulement de s'affranchir des complexités de
la distribution de l'horloge, mais aussi de réduire la
consommation du processeur. Cette réduction en courant
se traduit par un lissage de la consommation, ce qui est de
bon augure pour parer aux attaques de type DPA ou CPA.
Par ailleurs les attaques par biais d'horloge ne sont plus
d'actualité. La nature auto-cadencée des circuits asyn-
chrones leur confère aussi une forte tolérance aux fluc-
tuations environnementales : ces circuits présentent une
grande tolérance aux variations en tension ou en tempé-
rature tout en préservant leur fonctionnalité. Finalement
les circuits asynchrones DI garantissent que :
. Quelle que soit la valeur de la donnée manipulée,
sa représentation machine aura toujours le même
poids de Hamming, c'est-à-dire toujours le même
nombre de " 1 ". L'énergie consommée par une donnée
est ainsi toujours la même quelle que soit sa valeur.
. La représentation redondante d'une donnée garantit
aussi que certains états ne sont pas valides (comme
l'état " 11 " de l'exemple de la Dual Rail). Ces états
peuvent alors servir de détecteurs d'erreurs et ainsi
de contre-mesure contre les attaques par injections
de fautes.
3.1. Le projet G3Card
C'est dans le but de vérifier ces attributs sécuritaires
des circuits asynchrones que la Commission européenne,
via le programme IST (Information Society Technologies),
a financé sur trois ans le projet G3Card. Ce dernier
regroupait universitaires et professionnels de la carte à
puce d'une part, et ceux de la conception asynchrone
d'autre part, afin de fabriquer et tester le concept de la
carte à puce à microprocesseur asynchrone.
L'un des processeurs issus de ce projet est le proces-
seur XAP de l'Université de Cambridge. Dans les cha-
pitres suivants nous allons illustrer comment l'analyse en
sécurité du XAP asynchrone nous permet d'apprécier
l'apport qu'auraient les circuits asynchrones en matière de
sécurité.
4. La puce de test Springbank
.
&MN om
lem
M\W mm
Ulm
N'MI mm-
.6Lv n 5 P
i 4 !
an' " sl $ I , m
. -_.'
49 !
.
..
sfr9'iP'
Figlire 3. La piice de test Springbatik.
La puce de test Springbank est détaillée par ses
concepteurs de l'Université de Cambridge dans [8].
Elle a été fabriquée en technologie UMC 0,18pm
CMOS avec six niveaux de métal. L'architecture
utilisée est très proche de celles utilisées dans les
cartes à puce, c'est-à-dire un microprocesseur (coeur
16-bit XAP), 8KB de SRAM, un multiplieur de
Montgomery, une unité de protection mémoire (UPM)
et un bloc d'entrées/sorties, à la différence près que
cette puce comprend cinq versions différentes du
même coeur XAP :
. S-XAP : une version synchrone du XAP
. BD-XAP : une version du XAP en technologie
asynchrone BD
OF-XAP : un XAP en technologie asynchrone DI
avec un encodage 1-sur-4
. DR-XAP : un XAP asynchrone en technologie
Dual Rail (DR)
. SC-XAP : un XAP asynchrone en technologie DR
où la génération de l'état d'alarme " 11 " sert à détecter
une faute : le processeur est alors mis dans un état
bloqué.
Avoir ces 5 processeurs sur une même puce permet de
faire abstraction de considérations " technologiques "' lors
des études comparatives. Dans l'analyse qui suit, nous
nous intéresserons plus particulièrement à la sécurité du
SC-XAP.
REE
W 6/7
Juiii/Juillet 2t) 04

La carte à puce et les circuits asynchrones
4.1. Programme de test
L'analyse en sécurité du SC-XAP a été effectuée à
l'aide d'un programme très simple qui permet d'appécier
les forces et les faiblesses d'un processeur en matière de
sécurité. Le programme est chargé en SRAM. Au début
de ce programme nous activons le SC-XAP, ce qui en
même temps désactive les quatre autres déclinaisons de
l'architecture XAP. La partie du programme qui est testée
comprend les opérations suivantes :
. chargement de l'adresse mémoire du tableau de
données (LD@)
. chargement en registre de la première donnée Opi
(LDOpl)
. exécution d'un XOR entre Opi et Op2 dont le char-
gement est " inclus " dans le XOR (XOR)
'écriture du résultat Res en mémoire (STRes)
Pour chaque boucle du programme, les opérandes
Op 1 et Op2 sont transmis depuis un ordinateur via l'UART,
et en réponse nous lisons Opl, Op2 et Res qui sont écrits
dans un fichier. Les tests ont été effectués dans une confi-
guration où tout mécanisme de protection (notamment au
niveau de l'UPM) a été désactivé.
5. Analyse en sécurité du XAP asynchrone
Les deux grandes approches utilisées pour l'analyse
de sécurité du SC-XAP sont les mêmes que celles utilisées
sur une carte à puce. La première est l'étude de fuites
d'informations par canaux cachés, où l'on compare le
niveau de fuites entre le SC-XAP et le S-XAP. La deuxième
famille de tests traite de la résistance aux fautes (notamment
par faisceau laser et par variation en tension d'alimentation)
du SC-XAP.
5.1. Fuites par canaux cachés
L'étude de fuites par canaux cachés a été menée dans
un premier temps en mesurant le courant consommé à
chaque exécution de notre programme de test, et dans un
deuxième temps en mesurant le rayonnement électroma-
gnétique (EM) du SC-XAP lors de chaque exécution.
Pour chaque exécution, nous transmettons donc, à partir
d'un PC, les opérandes Opl et Op2. Le programme de test
est alors exécuté, et en même temps la mesure en courant
ou en champ EM est faite : la courbe obtenue est alors
sauvegardée. Nous lisons le triplet de données Op 1 -Op2-
Res. Cette manipulation est exécutée plusieurs centaines
de fois. Ainsi pour différentes valeurs de Op l et de Op2,
nous avons les Res correspondants et les courbes en courant
ou en EM correspondantes.
Nous appliquons alors la technique de la CPA
(Correlation Power Analysis) telle que décrite dans [9].
Supposons que l'on veuille faire une CPA sur Opl par
exemple. Pour rappel, les mesures faites pendant nos
manipulations nous ont permis d'avoir un fichier de
différentes valeurs d'Opl, et pour chacune d'elles une
courbe de courant ou EM en fonction du temps d'exécu-
tion. A chaque instant t, nous calculons la corrélation
entre le poids de Hamming de Opi et la variation de la
mesure faite en courant/EM à cet instant. Nous obte-
nons ainsi une courbe de corrélation qui permet de voir
comment, si fuite il y a, la manipulation de Opl évolue
en fonction du temps : car si la donnée Opi fuit en poids
de Hamming (c'est-à-dire que nous avons un modèle
valide) nous aurons une corrélation quasi nulle lors-
qu'elle n'est pas manipulée. Par contre, à l'instant où
Opi est utilisé, la corrélation est non-nulle. L'intensité
de cette corrélation instantanée révèle le niveau de
fuite à cet instant, permettant ainsi de quantifier cette
dernière.
5.1.1. Fuites en courant
La première observation faite sur le SC-XAP est que
l'exécution d'un même programme est déterministe, ce
qui donne des courbes en consommation de courant
(appelées " courbes en courant " par abus de langage) syn-
chrones, et ce malgré l'absence d'horloge. L'analyse en
CPA faite sur Op l, Op2 et Res respectivement démontre
la présence d'une fuite en poids de Hamming de ces don-
nées sur le S-XAP et sur le SC-XAP. Cependant :
. Le niveau de fuite est moindre dans le cas du
SC-XAP que dans celui du S-XAP.
. La différence se fait principalement pendant l'opé-
ration XOR, où une nette diminution d'environ 21 dB
de la fuite est obtenue dans le cas du SC-XAP.
Ainsi, le SC-XAP en technologie asynchrone DR per-
met de réduire la fuite en consommation en courant.
Cependant la fuite existe et est exploitable, et ce même si
la théorie de la Dual Rail ne doit pas permettre la fuite
d'information en poids en Hamming. Nous reviendrons
sur le sujet dans le chapitre sur l'analyse des résultats.
5.1.2. Fuites en rayonnements électromagnétiques fFA
La manipulation précédente est répétée mais cette fois
c'est le rayonnement électromagnétique qui est mesuré à
l'aide d'une bobine telle que décrite dans [4]. Cette fois,
avec le SC-XAP, les courbes mesurées sont très désyn-
chronisées d'une mesure à l'autre. Cependant, à l'aide de
méthodes de traitement du signal, les courbes en EM
peuvent être parfaitement synchronisées entre elles.
L'analyse CPA sur les mesures EM du SC-XAP nous
a réservé la surprise suivante : d'une part la fuite en poids
de Hamming des données est plus évidente que sur les
courbes en courant. D'autre part elle est plus importante
sur les courbes EM du SC-XAP que sur les courbes EM
du S-XAP. Des pics de CPA se voient clairement au niveau
du LDOpl, XOR et STRes. Les maxima de corrélation ne
sont pas très élevés (entre 20 % et 70 %), mais ils le sont
suffisamment pour être exploitables lors d'une attaque.
REE
No 6/7
luin/Juillet 2004

m Repères
CARTES À PUCE
mc,.,.,., : " rm
Il Il i,,II 1. 1 : 1 Il i
1 l'1 ;', 1 1
, !,''
i I I li i
I I I I i `. i
l ",1,,1 : ",'l'[..1'l'
Î III', 1 l, 1,.I,i 1 il'1 1
,1,'l'l' " 1 l'
1 1 l'1 1 ,,
Figure 4. Faitte eii teiisioii stii- le SC-XAP.
5.2. Attaques par injections de fautes
Nous utilisons le même programme de test que dans
le cas des attaques par canaux cachés mais cette fois-ci,
à chaque exécution nous injectons une faute pour tenter
de modifier le comportement du processeur. Le but de
cette famille d'attaques est de tenter de corrompre l'exé-
cution d'une instruction (d'où le besoin de synchronisa-
tion entre l'injecteur de faute et le programme exécuté)
afin de modifier la valeur de la donnée manipulée.
Ces fautes permettent, par cryptanalyse, de retrouver
des clefs secrètes par exemple [10]. Lors de nos mani-
pulations, nous gérons l'exécution du programme en
observant les valeurs de Opl, Op2 et Res et en obser-
vant l'effet de la faute sur la courbe en consommation
en courant (qui, rappelons-le, est déterministe même
pour le SC-XAP).
52. 1. Injections de fautes par faisceau laser
Au moment de l'exécution du XOR ou de l'une des
opérations de chargement de données, nous appliquons
un faisceau laser sur la surface du SC-XAP. D'une exécu-
tion à l'autre du même programme, nous modifions le
" lieu " d'injection de la faute jusqu'à ce qu'une faute soit
détectée sur le résultat du XOR. Pour la grande majorité
de la surface du SC-XAP, le faisceau met le processeur
dans un état bloqué, ce qui prouve que le mécanisme anti-
faute implémenté fonctionne.
Cependant à des endroits bien précis, comme au dessus
de l'UAL (unité arithmétique et logique) ou du banc de
registres, nous évitons le blocage du processeur et géné-
rons des valeurs erronées. Par exemple, une faute injectée
au niveau de l'UAL pendant le XOR produit toujours
comme résultat du XOR la valeur hexadécimale OXOOO 1 et
ce, quelles que soient les données Opl et Op2. Une post-
étude avec l'équipe de conception a permis de révéler que
ces fautes sont restées indétectées, car les cellules registres uti-
lisées n'étaient pas en technologie Dual Rail pour des ques-
tions de réduction de taille et de temps de conception.
5.2.2. Attaques par variations de tension
Cette fois, au lieu d'injecter un faisceau laser sur la
puce, nous réduisons subitement la tension d'alimentation
(quelques millivolts) à l'instant où le XOR est exécuté, ou
bien lors d'une des opérations de chargement de don-
nées dans un registre. La première observation faite est
qu'après de courtes interruptions de l'alimentation (de
l'ordre de la dizaine de ns), le processeur SC-XAP
reprend le cours normal de son programme, sans faute
apparente. Cependant, lorsque la durée d'interruption
est de l'ordre de la centaine de ns, nous observons des
résultats erronés. Dans un des cas, l'injection d'un
" glitch " de tension lors de l'opération LDOpl avait
comme effet de générer un Res qui était systématique-
ment l'inverse logique de l'Op2. Une étude plus
poussée a révélé que cette " longue " coupure de la ten-
sion d'alimentation avait pour effet de toujours charger
la valeur OxFFFF dans le registre contenant Opl. La
figure 4 est la superposition d'une courbe en courant
pour une exécution normale et d'une courbe en courant
pour une exécution avec variation de la tension d'ali-
mentation. Une resynchronisation des deux courbes
(figure 5) permet de voir que l'effet de l'injection de
faute se manifeste précisément au moment de l'opération
LDOPI.
6. Analyse et interprétation des résultats
L'évaluation du processeur SC-XAP démontre des
propriétés très intéressantes en faveur des circuits asyn-
chrones, notamment pour des applications de sécurité. La
technologie asynchrone en Dual Rail réduit la fuite d'in-
formation en consommation en courant. Cependant la
fuite n'est pas totalement éliminée. Même si l'encodage
REE
No 6/7
Jiiin/Juillet 2004