Introduction aux cartes à puce

HAL Id: inria-00384214

https://hal.inria.fr/inria-00384214

Submitted on 14 May 2009

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

Introduction aux cartes à puce

Nicolas Stouls

To cite this version:

Introdu tion aux artes à pu e

Ni olas Stouls

Septembre 2006

Dans le adre de ma thèse Outils formels pour la spé i ation et le dé-veloppementdesystèmes,nousnoussommesintéressésparti ulièrement aux systèmes embarqués et à leur ontraintes de sé urité. En eet, e domaine est a tuellement en très forte expansion et a des besoins de plus en plus importants en sé urité de part son intégration dans des systèmes ritiques de lavie ourante( arte de paiement, automobile, avionique, et ).Deplus, leslogi iels embarquéssont parti ulièrement intéressants àétudierdu point de vue de la sé urité, ar leurs spé i ations sont de petitetaille, bien que leur omplexitésoitenaugmentation onstante.Dans e hapitre,nousnous intéressonsà untype parti ulierde systèmeembarqué :les artesà pu e.

Ce rapport te hnique a été partiellement inspiré par les thèses de L. Casset [Cas02℄, G. Dufay [Duf03℄ et G. Grimaud [Gri00℄ ainsi que par les arti les[Tré03℄deH.Trézéguet, [Cha05 ℄S.Chaptalet[Ave05 ℄deY.Avenel. Enn, ertainesinformationsontététiréesdu ourssurles artesàpu efait par J-L Lanet (GEMPLUS) et C. Barral (GEMPLUS) à L'ENSIMAG en dé embre 2005 [Lan05 ℄etdessitesweb Wikipedia

1

et omment amar he 2

.

1 Te hnologies des artes à pu e

Inventéeen1974 parlefrançaisRolandMoreno,la arteàpu eestissue de travaux onjoints entre des laboratoires français, japonais et allemands. Son interfa e externe est dénit ave exa titude par la norme ISO 7816 [Hus01℄, quisedé omposeen sixalinéas:

 ISO-7816-1:Cara téristiques physiquesde la arte(taille);  ISO-7816-2:Empla ement des onta ts éle triques;

 ISO-7816-3:Naturedessignaux éle triquesetdesproto oles de om-muni ation entreleterminal etla arte;

1

http://fr.wikipedia.org/wiki/Ca rte_à_pu e 2

 ISO-7816-4 :Organisation desdonnéesetsé urisation;  ISO-7816-5 :Pro édured'ins ription desappli ations;  ISO-7816-6 :Données ommunesetrèglesde odage.

Ilexiste troisvariantesde artesàpu e :les artesà mémoire,les artes àlogiquesinternes âblée etles artesàmi ropro esseurintégré.

Les premières étaient les artes à mémoire. Utilisées notamment pour la téléphonie, es artes intègrent un système de fusibles qui peuvent être grilléspermettant ainsi de dé rémenter le nombre d'unités présentes sur la arte.Ces artessonten ore utiliséesaujourd'hui arellespermettent dene pasavoirdemonnaiedanslesappareilstéléphoniqueetdon dediminuerles a tesde vandalisme.

Un se ond type de arte est apparu en dérivé de e premier : les artes à logique interne âblée. Celles- i sont assimilables aux artes à pistes ma-gnétiquesdanslesensoùlesdonnéessto kéesnepeuventpasêtremodiées. Cependant, elles s'en distinguent par la masse d'informations sto kables et lefait quele onta t peutêtre maintenu indéniment. C'estpourquoil'une desutilisations lesplus onnuesde es artesestlesto kage des lefsde dé- hiragepourlesdé odeursde haînes payantes. Sil'on retirela arte,alors ledé odage s'arrête rendant impossible l'utilisation dedeux dé odeursave unemême arte (un même abonnement).

Enn, letroisième type de artesà pu e est elui des artes ave mi ro-pro esseur intégré. L'utilisation de es artes est très répandue dans la vie detouslesjours, equilesrendprogressivementindispensablesetjustieun développementtrès rapidedans ese teurdel'industrie.Eneet,ontrouve notamment dans ette atégorie les artesde paiement

3

[DCS01 ℄, les artes SIM

4

[DD04℄etles artesd'identi ation 5

[SG02 ,Fla05 ℄.Ces artesse dié-ren ient desautres arelles embarquent un pro esseur,de lamémoire vive, de la mémoire persistante et parfoisdes opro esseurs ( ryptographique la plupartdutemps). Ainsi, es artessont apablesd'exé uterunprogramme et sont don assimilables à un ordinateur. Le tableau 1 résume l'évolution des prin ipales ara téristiques de e type de artes. Pour omparaison, le tableau 2 donne les ara téristiques de ertains ordinateurs et onsoles de jeux. Nous remarquerons que les apa ités des artes à pu e a tuelles sont trèspro hesvoir supérieuresà elles desordinateurs d'ilya15 ans.

An dediéren ier les te hnologies demémoire persistanteutiliserdans les artes,voi iunedes riptiondes ara téristiquesde ha uned'entreelles. LesROM(ReadOnlyMemory) sont despu es gravée dire tement dans desplaques de sili ium et mémorisant des informations de manière

perma-3

CarteBleue,Moneo,et . 4

Carted'identi ationservantpourlestéléphonesportables. 5

Année Taille bus Fréquen e (MHz) RAM Mémoire persistante 1981 8bits 4,77 36o tets 1Kod'EPROM

1985 8bits 4,77 128o tets 2Kod'EEPROM 1990 8à16bits 4,77 256o tets 8Kod'EEPROM 1996 8à32bits 4,77à28,16 512o tets 32KodeFLASH

2000 8à32bits 4,77à28,16 1536o tets 32KodeFLASH+32Kod'EEPROM 2002 8à32bits 4,77à28.16 4Ko 64KodeFLASH+64Kod'EEPROM 2003 8à32bits 4,77à66 16Ko 528KodeFLASH

2005 8à32bits 4,77à100 16Ko 768KodeFLASH+256KoPageFLASH 2006 8à32bits 2pro esseurs 30Ko 1GoFLASHUSB

Tab.1 Evolution des ara téristiques artesà pu e àmi ropro esseur

nante.

LesPROM(ProgrammableReadOnlyMemory)sontdespu espouvant mémoriser des informations de manière permanante. Elles sont onstituées defusiblesquipeuventêtregrilléspourmémoriséun0oulaissésinta tspour mémoriser un1.

Les EPROM (Erasable Programmable Read Only Memory) sont des PROM pouvant être ea ées. Celles- i possèdent une vitre permettant de laisser passer des rayons ultra-violets. Lorsque la pu e est en présen e de rayonsultra-violets d'une ertaine longueur d'onde les fusibles sont régéné-rés equifaitquetouslesbitsde lamémoiresontànouveauà1.C'estpour ette raison quel'on qualie e type dePROMd'eaçable.

De même que les EPROM, les EEPROM (Ele tri ally Erasable Read Only Memory) sont despu es pouvant mémoriser des informations de ma-nièrepermananteetpouvantêtreea ées.Cependant,elles'endistinguepar lefaitque elles- i peuvent être ea éespar unsimple ourant éle trique.

La mémoire FLASH est une variante de l'EEPROM également appelée ROM Flash ou Flash EPROM. Contrairement aux EEPROM lassiques, utilisant 2 à 3 transistors par bit à mémoriser, la Flash EPROM n'utilise qu'un seul transistor. D'autre part l'EEPROM peut-être é rite et lue mot par mot, alors quela Flashne peutêtre ea ée que par pages(la taille des pagesétant en onstante diminution).Enn ladensité de lamémoire Flash est plus importante, e qui permet la réalisation de pu es ayant beau oup plus demémoire. Des EEPROM sont ainsipréférentiellement utilisées pour lamémorisationdedonnéesde ongurationetlamémoire FLASHpourdes programmes.

La mémoire FLASH-USB est en fait de la mémoire FLASH, onne tée au reste du système par un bus USB. Cela permet d'adresser une quantité beau oup plusimportantede zonemémoire.

Appareil Taille bus Fréquen e RAM Mémoire persistante AppleII(1977) 8bits 1MHz 4Koà64Ko 12Ko Atari 2600(1977) 8bits 1.19MHz 128o tets 2Koà64Ko Fami om(Aussiappelée NES-1983) 8bits 1,66MHz 16Ko 4Koà512Ko Gameboy(1988) 8bits 4.19MHz 8Ko 16Koà512Ko GameGear(1990) 8bits 3,58MHz 24Ko 4Koà512Ko Ma intoshClassi ouleur(1993) 16bits 16MHz 4Moà10Mo 40Moà160Mo

Tab.2 Cara téristiques d'ordinateurs etde onsoles dejeux pour ompa-raison ave les artesà pu e

Notons enn, que dans letableau 2 la olonne mémoire persistante fait référen e,suivantles as, àde laROMouà desdisques durs.

Par lasuite,nousallonsnousintéresser plusparti ulièrement aux artes ave pro esseur embarqué.

2 Systèmes d'exploitation pour arte à pu e et JavaCard

2.1 Systèmes d'exploitation pour arte à pu e

Comme tout ordinateur, les artes à mi ropro esseur embarqué né es-sitent laprésen ed'unsystème d'exploitationfaisant o e d'interfa e pour l'a èsauxressour esdela arte.Le omportement de etOS

6

est partielle-ment dénidanslanorme ISO-7816 auxalinéas3à 6.Par exemple,l'alinéa 7816-4 dé rit omment les  hiers peuvent être sto kés sous forme d'arbo-res en e de répertoire et de  hiers. Les premières artes embarquaient un OSpropriétaires etun logi ielspé iqueà l'appli ation voulue. Cependant, il n'était pas possible de désinstaller un logi iel et les OS étaient souvent adaptés pour être dédié à l'appli ation embarquée. L'une des onséquen e de etétat defaits étaitl'impossibilitéde développerune arteà pu e pour une appli ation ne permettant pas de vendre susamment d'unités pour amortir le oût de on eption. C'est notamment le as des artes d'a èsà desbatimentsquiétaient développésen détournant des artes onçues pour desappli ationsban aires.

C'estpourquoi,un ertainnombredesystèmesd'exploitationditsouvert, permettant d'installeretdedésinstallerdesappli ations,ontalors progressi-vementvulejour.LepremieràsedémarquerfutJavaCard[SM03 ,BDJ

+

01 ℄ deSun,basésurlelangage Java,etdontlaspé i ationévolueselon les

be-6

soinsdesindustriels présents dansleJavaCard Forum 7

.

Depuis, d'autres systèmes lui ont emboîté le pas omme Windows for Smart Card [Tal99 ℄ de Mi rosoft, basé sur le langage Visual Basi , Mul-tOS [dL99℄ repris par le onsortium MAOSCO (MasterCard, Mondex, Eu-ropayet Dis over) etbasé sur lelangage MEL (MULTOS Exe utable Lan-guage) ou Camille [Gri00 , GHSR05℄ de l'Université de Lille et basé sur le langage intermédiaire Façade.

Depuis son lan ement en 1997, JavaCard a été largement utilisé dans denombreux domaines,y omprisla arteà pu e.Pour donnerunexemple, dans le domaine des artes SIM, JavaCard représentais 24% du mar hé en 2003, 43% en 2004 (450 millions d'unités) et en 2005 la barre des un milliard de artes SIM embarquant et OS depuis sa sortie a été fran hie. Aujourd'hui 'estle systèmed'exploitation pour arte à pu e le plusutilisé dans le monde [Ave05℄. La popularité de JavaCard vient du fait que sa spé i ation n'est pas dénie par le propriétaire des droits (Sun) mais par un onsortium d'industriels, e qui n'est pas le as de Windows for Smart Cards,quiestunOS lefenmain.Deplus,lesspé i ationssontpubliques, equi laisse haquefondeurde arteà pu edéveloppersapropreversionde JavaCard, e quiapporteune valeurajoutée auproduit.

2.2 Cas du JavaCard

Le système JavaCard onsidère les appli ations(applettes) ommedes objets, e qui permet de gérer plusieurs appli ations sur une même arte etdedésinstallerdesprogrammes. Cesapplettes sont é ritesen JavaCard, sous-ensemble du langage Java, et ompilées en un Byte ode qui est inter-prété par une ma hine virtuelle embarquée dansl'OS. Le tableau 3 résume les prin ipales diéren es entre le langage Java et la version a tuelle de JavaCard(2.2.1).

Fon tionnalités Java supportées Fon tionnalités Javanon supportées Typesde base:booléens,byte,short Typesde base:long, double, oat Tableaux àune dimension Tableauà plusieurs dimensions Pa kages, lasses,interfa es etex eptions Cara tèreset haînes de ara tères Création dynamiqued'objets

Héritage, méthodesvirtuellesetsur harge

Tab. 3  Prin ipales diéren es entre les langages Java et Jav a-Card(V2.2.1)

Deplus,leslimitationsdûesaux artesàpu efontque ertaines fon tion-nalités delama hinevirtuelle Java nesont passupportées par JavaCard.

7

Par exemple, une lasse ne peut pas être hargée dynamiquement puisque l'installationsefaitsurunterminalparti ulier.LeSe urityManagerestalors rempla é par un simple rewall qui garanti qu'une applette n'a ède pasà une zone mémoire qui ne lui appartient pas. De même, le ramasse miettes est inutile puisqu'il sut dé rire en RAM les objets temporaires et en mé-moirepersistantes les objets permanants. Ensuite, la limitation de l'espa e mémoire fait quela réation d'objetsn'est quetrès rare, e quirend le lo-nage inutile. Enn, l'embarquement du véri ateur de Byte ode étant trop outeuseen pla e, elui- iestvérié avant son hargement.An degarantir que le ode n'a pas été altéré depuis la véri ation, elui- i est embarqué ave une signature. Une te hnique de signature onsiste à embarquer une preuve de la orre tion de l'applette [RB00,Ne 97 ℄, ar ilest très peu oû-teuxdevérierqu'une peuve estvraie, ontrairement àunevéri ation sans informations. Le tableau 4 résume les prin ipales diéren es de spé i ités entre lesma hinesvirtuelles deJava etJavaCard.

Spé i itésJavaCard Fon tionnalités Java nonsupportées FireWall Se urityManager

Controle d'a èsdansVM Chargement dynamiquede lasses Maitrise dupartage Multi-tâ hes

Objetstemporairesen RAM Ramassemiettes etnalisation Objetspersistants sérialisation d'objets

Atomi itédestransa tions Clonaged'objets Véri ation du Byte ode au hargement

(Signature, proof arrying ode)

Tab.4 Prin ipalesdiéren es despé i itésentre JavaCardetJava

JavaCard fournit également un ertain nombre d'API 8

permettant de simplier le travail et les onnaissan e te hniques né essaires des dévelop-peurs. Par exemple, lors d'une ommuni ation entre une arte (le serveur) et un terminal (le lient), seul un "l" (un onne teur) est utilisé, né essi-tant don une ommuni ationasyn hronesemi-duplexentrelesdeuxpartis. Cette ommuni ation a lieu par l'é hange de messages, nommés APDU

9 , dont la forme est dé rite par la norme ISO-7816-3. JavaCard fournit une APIpermettant d'a éderaux APDUau travers d'objets,simpliant la ré- upération et l'émission des paramètres. Dans sa version a tuelle (2.2.1), JavaCardfournit également unese ondeAPI,nomméeRMI

10

,permettant d'a èderauxméthodesde la arte par desappels d'opération lassiqueset masquant ainsi l'utilisation des APDU. Enn, une autre API intéressante fournie ave JavaCard est elle nommée Open Platform [BWT02℄,

déve-8

API=Appli ationandProgrammingInterfa e 9

APDU=Appli ationProto olDataUnit 10

loppée parVISA, etmettant à dispositiontoute uneinterfa e de gestiondu hirage,du dé hirage etdelasignature d'unmessageainsiquelagestion des lefs.

Parmi les ontraintes liées aux artes à pu e, se trouve également le risque d'arra hage de la arte [SL00 , SL99℄. Or ertaines transa tions sen-sibles telles que l'authenti ation ou les opérations sur le solde d'un porte monnaie éle tronique né essitent d'avoir lagarantie que soit l'opération est ee tuée omplètement, soit que rien n'a hangé. Cette garantie peut être a quise par l'appelsu essifde deux opérations. La première onsiste à de-mandersiunea tionestfaisableetlase ondepermetd'exé uter ettea tion le as é héant. C'est pourquoi la lasse JCSystem de JavaCard met à dis-position trois opérations (beginTransa tion(), ommitTransa tion() et abortTransa tion()permettantdegérerautomatiquement etypede tran-sa tionsengérant lapersistan edesdonnéestemporairesetla ohéren e du système.

Enn, le langage JavaCard dispose d'un ertain nombre de sé urités permettant d'avoir onan e enles applettesinstallées [Req00,Duf03℄,bien que le Se urity Manager ne soit pas embarqué sur la arte. Par exemple, l'exé ution des applettes se fait dans un ontexte personnel dont elles ne peuvent passortiretoùpersonned'autre nepeutlireoué rire(laSandbox) [Hen01℄. Par ontre, une partie de ettezone peutêtre partagée volontaire-mentave uneautreapplette.Cetteprote tionestee tuéepar unFireWall qui permet de vérier dynamiquement la légalité des a ès. Enn, la levée d'une ex eption permet de renvoyer un APDU d'erreur de manière trans-parente. Parmi les te hniques proposées pour garantir la sé urité du ode hargé on trouve notamment le développement formel d'un véri ateur de Byte ode hargeablesur arte [BCR03℄.

2.3 Cy le de vie d'une applet JavaCard

CommetoutprogrammeJava,la ompilationd'uneappletteJavaCard donne un  hier lass, dé ri dans un langage de Byte ode. Cependant, le Byte ode est un langage ontenant beau oup de haînes de ara tères (les nomsdesméthodespar exemple),alorsquelapla emémoireesttrèslimitée surune arte.Commele hargement dynamiquen'est pasautorisé, on peut résoudre à la ompilation les dépendan es de lasses et il devient possible de rempla er es haines par des valeurs numériques, beau oupplus légères à sto ker, que l'on appelle des tokens

11

. A l'issu de e rempla ement, deux  hiers sont rées : un  hier ap ontennt le Byte ode tokenisé et un - hierexport ontenantl'indexdes orrespondan estoken/nomdeméthode.

11

Token=jeton.Dansle asdurempla ementdesnomsdeméthode(tokenisation),les tokenssontdesvaleursnumériques.

Notonsque seulle hier ap sera hargésurla arte. Lorsde ette onver-sionun ertainnombredevéri ationsdesé uritésupplémentairesvontêtre ee tuées ar, ontrairement à Java, le véri ateur de Byte ode n'est pas embarqué surla arte.

Cap

Class

Sources

Loaded

Selected

Processing

Export

Hors carte

Compilation

Conversion

Chargement

Process

Return

Installation

Sélection

Désélection

Activated

Sur carte

Désinstallation

Désinstallation

Fig.1 Cy le de vie d'uneapplet JavaCard

Unefoisle hier approduitilpeutêtre hargésurla arte,puisinstallé (par appel de la méthode install() du système). Cette phase instan ie les objets orrespondants à l'appli ation et enregistre l'instan e auprès du système,rendant ainsilanouvelleappletteopérationnelle. Pour l'exé uter il fautalors laséle tionnerpuis appeler sesméthodes. Cettedernièrephasese faitpar l'é hange d'APDUs. C'estla méthode pro ess(APDU) de l'applette quireçoitettraitelesmessagesentrants. Enn,ilestpossiblededésinstaller une applette lorsqu'elle n'est pas séle tionnée. Le y le de vie d'une applet JavaCardestdé riten gure1.

3 Sé urité des artes à pu e

Les artesàpu esontprin ipalementutiliséesdesdomainesoùlesbesoins ensé urité eten miniaturisation sont très importants. Lesquatre domaines les plus importants sont [Hen01 ℄ : le paiement, la téléphonie, le ontrle d'a èsetlagestiondesinformations. La sé uritédes artespasse alors par laprote tion ontre lesattaque[BECN

+

04,BG01℄ matériellesetlogi ielles. Voi i quelquesexemples d'attaquesayant existé ouexistantes :

 Faussedevanturede terminal

 Attaques invasives(ave démontagede la arte) [SS99 ℄  Attaques statistiquespour retrouverdesse rets [CKN01 ℄  Analyse duux éle tromagnétique [GMO01,QS01 ℄  Attaques baséessur leretrait dela arte [HP04 ℄

 Attaques basées sur la re her he de anaux a hé temporels [Ko 96 , KK99 , MAC

+

02 ,DKL

+

 Dédu tion des se rets basée sur l'analyse de la onsommation de la arte[KJJ99℄

 Attaques par indu tiondefaute, danslebut demodier le omporte-ment dusystème[GT04 , SA02 ℄

Lasé uritédansles artesàpu esebaseprin ipalementsurlesattaques onnuesetdesprin ipesdebonne onduite.Parexemple,lapremièrerèglede baseestquetoutedonnéese rètedoitresterdansla arteetêtretraitéepar la arte.Cependant, ilexiste, ommepourtouterègle desex eptions. Ainsi, la arte SIMdes téléphonesportables dérogeà elle- ien transmettant une lefse rèteautéléphone, arellen'estpasassezpuissantepouree tuerseule l'opérationde hirement/dé hirement àlavoléedela ommuni ation, qui estdon réalisée par letéléphone.

Enn, notonsquelesprin ipales omposantesdelasé uritéd'unlogi iel pour arte àpu e sont les troissuivantes :

 Condentialité :préservationdesse rêts

 Nonrépudiation :garantie de l'identité de l'utilisateur  Intégrité :prote tion ontre l'altération desdonnées

L'étude de asDEMONEY quenous avonsréalisé (Chapitre ??) illustre unexempledemodélisationd'unportemonnaieéle troniquesousJavaCard etprenden ompte lesdiérentes onsidérations de sé uritéexposées i i.

4 Glossaire

APDU :

Appli ation Proto olData Unit API :

Appli ation and Programming Interfa e Applette :

Nom donnéaux programmesdéveloppésenJavaCard. Byte ode :

EPROM :

ErasableProgrammable ReadOnlyMemory- Cesont desPROM pou-vant être ea ées. Celles- i possèdent une vitre permettant de laisser passerdesrayonsultra-violets.Lorsquelapu eestenprésen ederayons ultra-violets d'une ertaine longueur d'onde les fusibles sont régénérés equifaitquetouslesbitsdelamémoiresontànouveauà1.C'estpour ette raison quel'on qualie e type de PROMd'eaçable. Page 3.

EEPROM :

De même que les EPROM, les EEPROM (Ele tri ally Erasable Read Only Memory) sont des pu es pouvant mémoriser des informations de manière permanante etpouvant être ea ées. Cependant, elle s'en dis-tingueparlefaitque elles- ipeuventêtreea éesparunsimple ourant éle trique.Page 3.

FireWall :

Composant logi iel ou matériel d'un réseau permettant de ltrer etde rediriger les messages.

FLASH :

La mémoire FLASHest une variantede l'EEPROMégalement appelée ROMFlashouFlashEPROM.ContrairementauxEEPROM lassiques, utilisant 2 à 3transistors par bità mémoriser,laFlash EPROM n'uti-lise qu'un seul transistor. D'autre part l'EEPROM peut-être é rite et lue motpar mot, alors quela Flashne peutêtre ea ée quepar pages (la taille despages étant en onstantediminution). Enn la densitéde la mémoire Flash est plus importante, e qui permet la réalisation de pu esayant beau oupplusdemémoire.DesEEPROMsont ainsi préfé-rentiellementutiliséespourlamémorisationdedonnéesde onguration etlamémoire FLASH pour desprogrammes. Page 3.

Flash EPROM :

Cf. mémoireFLASH FLASH-USB :

LamémoireFLASH-USBestenfaitdelamémoireFLASH, onne téeau reste dusystèmepar unbus USB. Celapermetd'adresserune quantité beau oup plusimportantede zonemémoire. Page 3.

Ordinateur:

Moyen onçupour a élérer etautomatiserles erreurs. OS :

OperatingSystème (Systèmed'exploitation). PROM :

Programmable Read Only Memory. Ce sont des pu espouvant mémo-riserdesinformationsde manièrepermanante.Ellessont onstituéesde fusibles qui peuvent être grillés pour mémorisé un 0 ou laissés inta ts pour mémoriser un 1.Page 3.

RMI :

RemoteMethodeInvo ation.NouvelleAPIdeJavaCarddepuissa ver-sion2.2.1.

ROM :

Read Only Memory. Ce sont des pu es gravée dire tement dans des plaques de sili ium etmémorisant des informations de manière perma-nante.Page 2.

ROM Flash :

Cf. mémoire FLASH Sandbox :

Littéralementba àsable.Zonemémoireréservéed'uneappli ation arte àpu e.Au uneautreappli ation nepeutlireoué riredans ette plage d'adresses.

Référen es

[Ave05℄ Y.Avenel. Lesospour artesàpu e entreouvertureet diversi- ation. Ele tronique, 163 :3438, 11 2005.

[BCR03℄ L. Burdy, L. Casset, and A. Requet. Développement formel d'un véri ateur embarqué de byte- ode java. In D. Bert, V.Donzeau-Gouge, andH.Habrias,editors, Développement ri-goureux de logi iel ave la méthode B,volume 22.Te hnique et S ien e Informatiques,2003.

[BDJ

+

01℄ G. Barthe, G. Dufay, L. Jakubie , B. Serpette, and S. Melo de Sousa. A Formal Exe utable Semanti s of the JavaCard Platform. Le ture Notes inComputer S ien e,2028 :302, 2001. [BECN

+

04℄ H.Bar-El,H.Choukri,D.Na a he,M. Tunstall, andC. Whe-lan. The sor erer'sapprenti e guideto fault atta ks. In Work-shop on Fault Dete tion and Toleran e in Cryptography, Italy, 2004.

[BG01℄ C. Bidan and P. Girard. La se urite des artes a mi ropro es-seur. Revuedel'Ele tri itéetdel'Ele tronique(REE),5:6065, 5 2001.

[BWT02℄ D. Brewer, C. Wang, and P. Tsai. Proving prote tion prole omplian e for the l/itri visa open platform smart ard. In 3rd InternationalNCommon CriteriaConferen e,2002.

[Cas02℄ L. Casset. Constru tion Corre te de Logi iels pour Carte à Pu e. Développement formel d'un vérieur em-barqué de byte ode Java Card à l'aide de la méthode B. PhD thesis, Université d'Aix-Marseille II, 2002. http://www.atelierb.so iete. om/liens/theseLudovi .pdf. [Cha05℄ S.Chaptal. Les artes àpu e géantes débarquent dansles

mo-biles. 01net,11 2005.

[CKN01℄ J.J. Coron, P. Ko her, and D. Na a he. Statisti s and se ret leakage. In Finan ial Cryptography, volume 1962 of Le ture Notes in Computer S ien e, pages 157173. Springer-Verlag, 2001.

[DCS01℄ Dire tion entrale de la sé urité des systèmes d'information DCSSI. Carte mixe MONEO/CB, rapport de erti ation 2001/10, O tobre 2001.

[DD04℄ C. DemoulinandM. VanDroogenbroe k. Prin ipesde basedu fon tionnement duréseauGSM. Revue del'AIM,04:page 318, 2004.

[DKL

+

99℄ J.-F. Dhem, F. Koeune, P.-A. Leroux, P. Mestre, J.-J. Quis-quater, and J.-L. Willerns. A pra ti al implementation of the

timing atta k. In Third Smart Card Resear h And Advan ed Appli ation Conferen e CARDIS'98. Springer-Verlag, 1999. [dL99℄ J.deLangavant. Themultossystemandar hite ture. In

Gem-plus Developer Conferen e, Paris, 1999.

[Duf03℄ G. Dufay. Véri ation formelle de la plate-forme JavaCard. thèse, Universitéde Ni e - SophiaAntipolis UFRS ien es, dé- embre 2003.

[Fla05℄ M. Flamenbaum. La arte nationale d'identité éle tronique. Rapportde master 2droit du yberspa e,Université deLille 2 Fa ulté dess ien es juridiquespolitiques etso iales, 2005. [GHSR05℄ G.Grimaud,Y.Hodique,andI.Simplot-Ryl. Se ureextensible

type system for e ient embedded operating system by using metatypes. InPro . 1st InternationalWorkshopon Systemand Networking for Smart Obje ts (SaNSO2005), Fukuoka, Japan, 2005. IEEE Press.

[GMO01℄ K. Gandol,C. Mourtel,and F.Olivier. Ele tromagneti analy-sis :Con reteresults. InWorkshop on Cryptographi Hardware and Embedded Systmes (CHES'2001), volume 2162 of Le ture Notes in Computer S ien e, pages 251261. Springer-Verlag, 2001.

[Gri00℄ G. Grimaud. CAMILLE,unsystèmed'exploitation ouvertpour artes à mi ropro esseur. thèse, Laboratoire d'Informatique Fondamentale de Lille, dé embre 2000.

[GT04℄ C. Giraud and H. Thiebeauld. A survey on fault atta ks. In CARDIS'04, Smart Card Resear h and Advan ed Appli ations VI, Toulouse, Fran e, pages159176. Kluwer a ademi , 2004. [Hen01℄ Mike Hendry. Smart Card Se urity and Appli ations. Arte h

House tele omuni ation library,2001.

[HP04℄ E. Hubbersand E. Poll. Reasoningabout ard tears and tran-sa tions in java ard. In Fundamental Approa hes to Software Engineering (FASE'2004), Bar elona, Spain, volume 2984 of Le ture Notes in Computer S ien e, pages 114128. Springer-Verlag, 2004.

[Hus01℄ D. Husemann. Standards in the smart ard world. Computer Networks, 36(4) :476487,2001.

[KJJ99℄ P. Ko her, J. Jae, and B. Jun. Dierential power analysis. Inthe 19thAnnualInternationalCryptology Conferen e on Ad-van es in Cryptology,pages 388397. Springer-Verlag, 1999. [KK99℄ O. Kömmerling andM.G.Kuhn. Designprin iples for

tamper-resistant smart ard pro essors. In the USENIX Workshop on Smart ard Te hnology (Smart ard '99), Chi ago, Illinois,USA, pages 920,1999.

[Ko 96℄ P.Ko her.Timingatta ksonimplementationsofdie-hellman, rsa, dss, and other systems. In the 16th Annual International Cryptology Conferen e on Advan es in Cryptology, pages 104 113. Springer-Verlag, 1996.

[Lan05℄ J-L. Lanet. (Gemplus) Support de ours : Carte à pu e, 2005. Institut NationalPolyte hnique de Grenoble.

[MAC

+

02℄ S. Moore, R. Anderson, P. Cunningham, R. Mullins, and G. Taylor. Improving smart ard se urity using self-timed ir- uits. In ASYNC'02,pages 211218, 2002.

[Ne 97℄ G.C. Ne ula. Proof- arrying ode. In In 24th Prin iples of Programming Languages (POPL), Paris, Fran e, 1997.

[QS01℄ J.J. Quisquater and D. Samyde. Ele tromagneti analysis (ema) : Measuresand ountermeasures for smart ards. In E-smart'01, volume 2140 of Le ture Notes in Computer S ien e, pages 200210. Springer-Verlag, 2001.

[RB00℄ A. Requet and G. Bossu. Embedding formally proved ode in a smart ard:Converting b to . In Third IEEE International Conferen eonFormalEngineeringMethods(ICFEM'00),pages 1522, 2000.

[Req00℄ ARequet. ABModelforEnsuring SoundnessoftheJavaCard Virtual Ma hine. InFMICS'2000, Berlin,Mar h 2000.

[SA02℄ S. Skorobogatov and R. Anderson. Opti al fault indu tion at-ta ks. In Workshop on Cryptographi Hardware and Embed-ded Systmes(CHES2002),SanFran is o Bay(Redwood City), USA, 2002.

[SG02℄ E.SoulierandC.Grenier.Apoliti almodelforthe o-operative produ tionofknowledgeinthedesignpro ess:theshared medi- alle(smf).InEuropean Conferen eon Arti alIntelligen e : Knowledge Management andOrganizational Memories,2002. [SL99℄ D. SabatierandP.Lartigue. The UseoftheBFormal Method

fortheDesignandtheValidationoftheTransa tionMe hanism for Smart Card Appli ations. In FM'99 - Formal Methods -volume 1, volume 1708 of Le ture Notes in Computer S ien e, pages 348387. Springer-Verlag, september 1999.

[SL00℄ D. Sabatier and P. Lartigue. The use of the b formal method for thedesign andthe validation ofthetransa tion me hanism for smart ardappli ations. FormalMethods inSystemDesign, 17(3) :245272,12 2000.

[SM03℄ In . Sun Mi rosystems. Java Card 2.2.1 Virtual Ma hine Spe- i ation,10 2003. Santa Clara, California.

[SS99℄ B. S hneier and Adam Shosta k. Breaking up is hard to do : Modeling se urity threats for smart ards. In USENIX Work-shoponSmartCardTe hnology,pages175185.USENIXPress, 5 1999.

[Tal99℄ L. Talvard. Smart ard for windows overview. In Gemplus Developer Conferen e, Paris, 1999.

[Tré03℄ H. Trézéguet. Les mi ro ontrleurs pour artes à pu e. Ele -tronique, 141 :7281,11 2003.