- Système d'exploitation pour carte à puce
-
Les systèmes d'exploitation pour carte à puce aussi appelés COS[note 1] assurent fondamentalement les mêmes fonctions que les autres systèmes d'exploitation, mais dans un contexte matériel où les limitations matérielles et les problématiques de sécurité sont exacerbées.
Ainsi, à l'instar des autres systèmes d'exploitation, ceux des cartes à puce gèrent le matériel qui leur est assigné. Une carte à puce comporte notamment une mémoire de travail volatile (sous la forme de SRAM), une mémoire non ré-inscriptible (ROM) qui contient le code du système d'exploitation et éventuellement celui d'application pré-déployé ainsi qu'une mémoire morte ré-inscriptible (typiquement de l'EPROM), permettant de stocker des données qui resteront disponible lorsque la carte sera redémarrer). . Le système d'exploitation gère aussi le Microprocesseur, parfois assorti d’un processeur dédié à la cryptographie et le protocole de communication (généralement celui spécifié par la norme ISO 7816).
Les possibilités matérielles des cartes étant limité en mémoires et en puissance de calcul, les systèmes d’exploitation de ces équipements se doivent d'être les plus légers possibles afin d'être embarqué dans la mémoire des cartes. Malgré ces limites matériels, ces COS doivent intégrés des fonctionnalités ainsi que des spécificités tel que :
- L’allocation de mémoire (RAM, EEPROM) ;
- Le système de fichiers ;
- Le contrôle d'exécution de code ;
- Le chargement, le lancement et la gestion des applications ;
- La transmission de données ;
- L'exécution et la gestion des algorithmes cryptographiques.
D'un système mono-applicatif où le système d'exploitation et l'applicatif ne font qu'un (1981), aux cartes à puces les plus récentes pouvant gérer plusieurs applications sur une même carte, les architectures ont évolués et se classifient selon trois modèles. Les systèmes fermés, généralement propriétaires et étroitement liés au matériel sont réalisés pour supporter une application, ou un ensemble d'application prédéfinit. Les systèmes post-issuance repose sur la mise en œuvre d'une machine virtuelle applicative tel que « Java Card Virtual Machine » et « MultOS » ou l'environnement d'exécution est sécurisé et authentifié. L'utilisation d'hyperviseurs à plus récemment été envisagé, avec le système d'exploitation CAMILLE.
D'un point de vue économique, le marché des cartes à puce, en perpétuelle évolution, est présent dans divers domaines (télécommunication, bancaire, télévision, ...).
Sommaire
Description technologique
Une carte à puce ou Smart card (en) est constituée d'un CPU, de mémoire RAM (ses données seront perdues quand celle-ci sera retirée du lecteur), d'une mémoire ROM (où est pré-enregistré en usine le système d'exploitation), et d'une EEPROM (qui conserve les données qui y sont inscrites même après que la carte n'est plus électriquement alimentée). En cela, il s'agit d'un ordinateur classique, réduit à la taille d'une puce.
Elle permet la communication, le stockage et l'exécution de code avec un haut degré de sécurité. Les circuits logiques qui composent la puce supervisent la transmission des données via interface série pour faire communiquer la carte vers l'extérieur et notamment un lecteur. Comme pour n'importe quel autre système d'exploitation, comme par exemple le DOS, les fonctions et les instructions d'un COS ne sont pas dépendantes d'une application en particulier mais se veulent être génériques pour un ensemble de besoins communs à toute application désirant fonctionner dans un environnement de carte à puce. Et tout comme le DOS, ce type d'OS n'est pas conçu pour fournir d'interface graphique.
Environnement matériel
Schéma générique d'une carte à puce
Ci-dessus une illustration simpliste d'une carte à puce. Le schéma montre qu'elle est composée :
- D'une partie logique avec un CPU et un NPU (spécialisé pour la partie réseau) mais plus généralement on pourrait employer le terme de MPU ou (en) Multi-core processor. Cette partie logique est le siège de l'exécution du code applicatif que ce soit l'OS comme les applicatifs installés dans la carte.
- D'une partie mémoire qui permet de stocker l'information volatile (mémoire RAM) durant l'exécution du code. De la EEPROM qui stocke soit des applicatifs ou des données qui peuvent modifiables pendant le fonctionnement de la carte mais qui ne doivent pas être perdus après la perte d'alimentation. Et la mémoire ROM qui stockera le code, notamment l'OS, ou les données figés en usine durant la conception de la puce.
- Une partie communication qui permet la communication avec l'extérieur et notamment le lecteur de carte à puce. Le schéma présenté ci-dessus montre un seul type de communication extérieur avec un contacteur physique, mais d'autres types de communication[1] sont possibles comme les ondes radios mais aussi les ondes lumineuses.
Le système d'exploitation est ainsi localisé essentiellement au niveau de la mémoire ROM, sous une forme non altérable, et pour éventuellement certaines de ses fonctions modifiables dans l'EEPROM. Il offre les fonctions pour contrôler les différents éléments de la carte et la communication avec le lecteur.
Normes
La norme de référence est la norme ISO/IEC 7816 (en)[2] (Identification cards — Integrated circuit cards), le tableau suivant répertorie les différentes parties de cette norme.
Référence Titre ISO/IEC 7816-1 (en) Cards with contacts: Physical characteristics ISO/IEC 7816-2 Cards with contacts: Dimensions and location of the contacts ISO/IEC 7816-3 Cards with contacts: Electrical interface and transmission protocols ISO/IEC 7816-4 Organization, security and commands for interchange ISO/IEC 7816-5 Registration of application providers ISO/IEC 7816-6 Interindustry data elements for interchange ISO/IEC 7816-7 Interindustry commands for Structured Card Query Language (SCQL) ISO/IEC 7816-8 Commands for security operations ISO/IEC 7816-9 Commands for card management ISO/IEC 7816-10 Cards with contacts: Electronic signals and answer to reset for synchronous cards ISO/IEC 7816-11 Personal verification through biometric methods ISO/IEC 7816-12 Cards with contacts: USB electrical interface and operating procedures ISO/IEC 7816-13 Commandes pour la gestion d'application dans un environnement de plusieurs applications ISO/IEC 7816-15 Cryptographic information application D'autres normes qui concernent les cartes contactless (radio et optique).
Référence Titre ISO/IEC 14443 (en) Identification cards -- Contactless integrated circuit cards ISO/IEC 15693 (en) vicinity cards, i.e. cards which can be read from a greater distance ISO/IEC 11693 Identification Cards - Optical Memory Cards - General Characteristics ISO/IEC 11694 Identification Cards - Optical Memory Cards - Linear recording method Fonctionnalités
Composant système d'un COSLe COS est contenu dans la ROM de la carte à puce, on peut aussi trouver le terme de mask[3]. Il fournit une API complète afin de communiquer vers les zones mémoire mais également et surtout vers l'extérieur.
Spécificités
Une des grosses problématiques des outils d'exploitation pour carte à puce est qu'ils doivent être implémentés dans la ROM. De même la quantité de RAM disponible étant relativement faible[4], il faut que le code écrit soit le plus compacte possible et que l'utilisation des capacités mémoire soit raisonnée[5].
Capacité Mémoire Cartes à puce Élément Taille en 2004[6] Taille en 2001 Taille en 1996 ROM 368 kbytes 128 kbytes 16 kbytes EEPROM 256 kbytes 8 kbytes 4 kbytes RAM 16 kbytes 4 kbytes 256 bytes Un autre aspect important est l'usage souvent fait pour ce type de carte, comme par exemple l'acte du paiement ou l'identification d'une personne. Il est donc essentiel que ces systèmes d'exploitation embarquent des fonctionnalités de cryptographie et d'authentification forte[7].
Parfois, certaines de ces fonctionnalités sont directement intégrées au niveau matériel[8][9].
Il est également important que ces systèmes d'exploitation se conforment à des standards en ce qui concerne leur mode de communication. Notamment la norme ISO 7816-4 (specifics organization, security and command for interchange)[10], a été rédigée pour cet usage en définissant la structure des commandes-réponses. Elle définit également une structure pour les données et les applications ainsi qu'une architecture pour la sécurité.
Ainsi ces systèmes d'exploitation sont responsables de :
- La gestion de la mémoire (ROM, RAM, EEPROM) ;
- La gestion de fichiers ;
- Le contrôle d'exécution de code ;
- Le chargement, le lancement et la gestion des applications ;
- La transmission de données ;
- L'exécution et la gestion des algorithmes de cryptographie.
Gestion des fichiers
Une des premières fonction c'est la gestion de fichiers avec les opérations de lecture, écriture, création, suppression sur les fichiers. Pour cela un COS doit suivre les préconisations du standard ISO/IEC 7816-4.
Le stockage des fichiers en mémoire s'organise selon une méthode classique d'arborescence avec une racine et des feuilles. On peut trouver plusieurs types de Système de fichiers :
- (en)Pointer-based file management, p. 272
- (en)Fat-based file management, p. 273
- (en)SCSF (SmartCard Filesystem)
- (en)SC-CFS : Smartcard Secured Cryptographic File System
- ...
La cryptographie
La majorité des applications des cartes à puce étant utilisées pour authentifier de manière forte des individus, un COS pour carte à puce implémente généralement une API de cryptographie. La norme IEC 7816-15 (en) a été conçue pour standardiser ce besoin [réf. nécessaire].
L'utilisation des algorithmes de cryptographie (PKCS) avec la manipulation de grands nombres comme par exemple les algorithmes à clefs symétriques (RSA ou DSA) sont une source de consommation de puissance de calcul. C'est pourquoi on trouve, de plus en plus, adjoint au microprocesseur traditionnel de la carte à puce un Secure cryptoprocessor (en) qui accélère les calculs sur les grands nombres[11].
Communication avec le lecteur
Un COS doit également inter-agir avec un lecteur, pour cela plusieurs mode de transmission possible :
- par contact physique sur la carte elle-même (Contact Smarcard) / ISO/IEC 7816-3
- par onde radio (Contactless SmartCard) / ISO/IEC 14443, ISO 15693
- par onde lumineuse ( Contactless Optical SmartCard) / ISO/IEC 11693 and 11694
Rapide historique
En 1977, Michel UGON découvre l'architecture du SPOM (Self Programmable One-Chip Microcomputer). En 1981, la 1re carte CP8 sort avec le masque PC0[12].
Une importante évolution des outils d'exploitation se fit dans les deux décennies qui suivirent:
- Tout d'abord monolithique, rien ne distingue l'application de l'outil d'exploitation[Pourquoi ?] ;
- Puis toujours monolithique mais application et outil d'exploitation sont séparés en trois couches[Lesquelles ?][13].
Dans ces phases les cartes sont mono-application et l'outil d'exploitation gère des zones[pas clair][14].
- Puis l'outil d'exploitation gère un système de fichier mais est toujours monoapplication[15].
- L'évolution suivante est la gestion de plusieurs applications[Comment ?][16].
Si les logiciels embarqués dans les cartes programmaient directement le matériel, au début des années 1980, la gestion du matériel a progressivement été isolée du code applicatif. Dans les années 1990 les machines virtuelles ont été utilisées pour présenter une abstraction simplifiant l'utilisation des cartes à puces, notamment avec les technologies Java Card. Enfin, dans les années 2000 les premiers mécanismes d'hypervision basés sur des exo-noyaux ont été expérimenté sur les cartes à puces[17]. De nombreux travaux ont consisté à sécuriser le code mobile qui pouvait être chargé dans la carte[18] afin d’assurer l’intégrité et la confidentialité des données. Cependant, établir des garanties plus larges comme le contrôle des ressources ou le temps réel reste une question ouverte[19].
Différentes approches existantes
Les systèmes fermés
Ci-dessous quelques exemples de cartes à puce et les éditeurs qui leur sont associés.
Système de carte à puce et leurs éditeurs Systèmes d'exploitation Éditeur GemXplore, GPK, MPCOS Gemalto STARCOS, STARSIM, STARDC Giesecke & Devrient AuthenIC, SIMphonic Oberthur Technologies Micardo Morpho e-Documents Cyberflex, Multiflex, Payflex Schlumberger (entreprise) CardOS Siemens (entreprise) TCOS Telesec (de) s-Choice Smart (en)SCI Windows for SmartCards
Windows for SmartCard est une extension de l'environnement Windows pour l'authentification des utilisateurs vers les systèmes Microsoft. Elle étend le système de fichier dans la carte[20]. Les développements peuvent se faire en Visual Basic, Visual C++[21].
SOSSE - Simple Operating System for Smartcard Education
SOSSE[22] est un système d'exploitation conçu pour se familiariser avec le monde des applications pour carte à puce. Son originalité vient du fait qu'il est totalement gratuit et ouvert. Les spécifications matérielles des cartes supportées sont également ouvertes, il permet tout type d'expérimentation.
Les machines virtuelles
JAVACARD
Article détaillé : Java Card.Java Card[23] est un système d'exploitation pour carte à puce bâti autour de la technologie JAVA.
La technologie
La technologie Java Card[24] est un sous ensemble (Java Micro Edition ou JME[25]) du langage de programmation JAVA avec un environnement d'exécution optimisé pour le monde des cartes à puce ou tout type de matériel de type embarqué. Cette technologie permet l'utilisation de la programmation JAVA avec les périphériques embarqués comme celui des cartes à puce.
Bien que le système d'exploitation Java Card suit la majorité des préconisations du standard JAVA, toutes les fonctionnalités de JAVA ne sont pas supportées.
En effet, les besoins pour ce type d'applications sont plus modestes au regard de la technologie matérielle utilisée. Ainsi, l'implémentation d'un JRE complet aurait beaucoup de mal à s'accommoder des quelques Ko disponibles dans une carte à puce. Par exemple, le support des threads n'est pas une fonctionnalité essentielle pour ce type d'application. Le jeux d'instruction de la JCVM (JavaCard Virtual Machine) a donc été adapté et réduit à l'essentiel.
Les spécifications
Actuellement JAVA fournit deux spécifications phares pour décrire cette technologie :
- Java Card Platform Specification 2.X[26], décrivant les spécifications :
- Java Card Virtual Machine (JCVM) ;
- Java Card Runtime Environment (JCRE) ;
- les APIs pour la Java Card Platform.
- Java Card Platform Specification 3.X[27] est déclinée sous deux versions :
- Classic Edition, est une évolution de la version 2.X et assure une compatibilité ascendante avec la version 2.X ;
- Connected Edition, améliore le JCRE et la machine virtuelle en ajoutant des nouvelles fonctionnalités réseaux comme le support des applications web.
JCVM ( JAVA Card Virtual Machine )
La JCVM est découpée en deux parties :
- La première partie contient l'interpréteur de bytecode qui est située sur la carte ;
- La deuxième partie contient les autres fonctionnalités classiques d'une machine virtuelle (convertisseur, chargement de classes, vérification du bytecode) qui est située hors de la carte.
Les applications sont chargées et vues comme des applets JAVA classiques.
MULTOS
Article détaillé : Multos.Multos est une solution de système d'exploitation pour carte à puce ouverte et non propriétaire.
Le Consortium MULTOS
Les spécifications de MULTOS[28] sont maintenues par le consortium MULTOS[29] aussi connu sous le nom MAOSCO Limited. Ce consortium regroupe de nombreux industriels comme les constructeurs de cartes à Puce, le secteur des télécommunications, la télévision payante, le E-Commerce, le secteur public, etc.
La technologie
MULTOS est une véritable plateforme multi-applications qui supporte le chargement d'applications sur des cartes qui sont déjà en circulation. De plus, le processus de chargement MULTOS spécifique permet de s’assurer que l’application est authentifiée et que son intégrité est vérifiée au moyen de certificats dédiés.
Cette technologie est réalisée de la manière suivante :
- Une machine virtuelle pour carte qui exécute de manière sécurisée les applications. Les applications MULTOS peuvent être développées sur tout type de langage comme le C, le C++, le JAVA voire en langage machine et compilées en bytecodes MEL qui sera exécuté par cette machine virtuelle. Elle vérifie tous les aspects de l'exécution d'une application, la validité du bytecode, la sécurité des accès mémoire, etc. Ainsi le partage de données entre deux applications n'est pas permis. Le jeux d'instruction MEL Bytecode est limité à la manipulation de donnée et à de simples opérations arithmétiques. Bien que ce jeux d'instruction soit rudimentaire, MULTOS fournit des primitives permettant des opérations plus complexes comme la cryptographie, ou l'accès à la mémoire de MULTOS, mais là aussi ces accès mémoires sont strictement encadrés.
- Une grande interopérabilité, avec la notion de machine virtuelle et la définition d'un grand nombre de primitives standardisées en rapport avec des standards de l'industrie comme les interfaces sans contacts. Cela permet à des applications d'être compatibles entre les différentes implémentations constructeurs de MULTOS.
Un hyperviseur : Camille
Pour supporter la capacité de modifier le fonctionnement du système d'exploitation après son déploiement, des architectures à base de noyaux ont été mises en place. Ces noyaux supportent une extensibilité au niveau système en autorisant le chargement dynamique de services système.
Camille est un système d'exploitation ouvert pour carte à microprocesseur[30]. Camille est un Hyperviseur basé sur les principes architecturaux des exo-noyaux.
Architecture logicielle du système d'exploitation Camille.Le noyau, en particulier, a pour unique vocation de démultiplexer et sécuriser son exploitation[31]. Camille fournit un accès sécurisé aux ressources matérielles et logicielles (microprocesseur, pages de mémoire, interface de communication série, etc.) et permet aux applications de gérer leurs ressources de manière directe.
Camille fournit quatre caractéristiques de base pour les applications: la sécurité, l'extensibilité, l'interopérabilité et la portabilité.
La portabilité est assurée par l'utilisation du langage intermédiaire orienté objet nommé Façade[32]. Façade est un langage intermédiaire simple et compact composé de seulement cinq instructions : trois instructions de branchement (jump, jumpif et jumplist), un return et une instruction invoke. cf. §2.3 Principle of Type-Checking: Type Inference[32]. Un programme Façade peut être vu comme une suite de liens et d'interactions entre les différents composants qui forment le système embarqué[33]. Les applications et extensions système peuvent être programmées à l'aide de langages de haut niveau comme le C, le Java ou Visual Basic. Par la suite, elles sont converties en Façade en utilisant des convertisseurs de code ou un compilateur dédié. Le code Façade, une fois chargé sur l'équipement, est traduit en code natif par un générateur de code à la volée[34] pour des besoins forts en termes de performances d'exécution ou produire un code natif optimisé, pour être inclus dans la ROM d'une carte à puce. cf. §2.2 The Façade System[32]. La confidentialité et l'intégrité des applications sont garanties à l'aide d'une vérification de typage[35].
Pour répondre à la qualité de service dans un contexte multi-tâches (plusieurs applications s'exécutant en même temps), c'est-à-dire répondre aux contraintes comme la disponibilité de ressources, déni de service ou temps réel, Camille a évolué afin d’y intégrer les propriétés de contrôle mémoire et temps réel. §3 Perspective : Camille RC & RT[36].
Camille RC : Resource Control ou contrôle mémoire
Les deux axes pour contrôler les ressources mémoire sont : §3.1 3.1 Camille RC: Resource Control[36].
- une analyse statique de la consommation mémoire (durée de vie des objets, taille consommée dans les différentes mémoires) ;
- un pilotage dynamique de l’ordonnanceur grâce aux informations extraites de l’analyse statique.
Cette analyse va permettre également d’obtenir des informations intéressantes sur la consommation CPU pour mieux maîtriser le temps d'exécution des programmes encartés.
Camille RT : Real Time ou temps réel
L'objectif à atteindre ici est la maîtrise du temps d'exécution des programmes encartés. §3.2 Camille RT : Real Time[36].
Dans un système ouvert où de nouvelles tâches peuvent être ajoutées dynamiquement dans le système, Camille RT devra s’assurer d’une part que les contraintes des tâches déjà supportées ne sont pas affectées, et d’autre part d’assurer à la nouvelle tâche chargée qu’elle aura toujours à sa disposition suffisamment de capacité CPU.
L'axe d'amélioration est la gestion dynamique de l'ordonnanceur qui passera entres autres par la résolution des problématiques d'économie d'énergie et la retouche du langage Façade.
Le Marché
Aujourd'hui le marché des cartes à puce s'ouvre aux nouveaux secteurs comme les transports, l'identité grâce aux nouveaux systèmes d'exploitation ouverts comme JavaCard et Multos . Les cartes à puce sans contact s'emparent également du secteur des transport. Les secteurs des Télécom et du bancaire restent toutefois majeurs sur le marché des cartes à puce.
Domaine d'application des cartes à puceMarché des cartes à puce et systèmes d'exploitation associés en 2010 et prévision en 2011.
(en millions d'unités)
Source : http://www.eurosmart.com/images/doc/Eurosmart-in-the-press/2010/courrier_monetique_dec2010.pdfDomaines Systèmes d'exploitation 2010 2010 vs 2009
en %2011 2011 vs 2010
en %dédiés ouverts Télécom SIM, Télécartes JavaCArd(450) 4000 +18 4500 +13 Bancaire, Fidélité B0', EMV MultOS(50)
JavaCard880 +17 1010 +15 Identité, Santé Vitale
(Scot 400, IGEA)MultOS 190 +19 225 +18 Transport JavaCard 65 +63 80 +23 TV à péage JavaCard 110 +10 125 +14 Sécurité, Contrôle d'accès JavaCard 75 +7 80 +7 Total 5320 +18 6020 +13 En 2010, le marché des cartes à puces a progressé de 18% globalement, fortement dans le secteur des transports et de l’identité/santé mais aussi dans le secteur des Télécom avec une forte demande de carte SIM en Chine, en Inde et au Brésil. On peut remarquer que le système d’exploitation JavaCard prend de plus en plus de part de marché dans la plupart des secteurs. Le système MultOS s’ouvre au marché dans le secteur de l’identité à Hong-Kong (7 millions de cartes à terme) et de l’identité saoudien (17 millions de cartes à terme).
Marché des cartes sans contact en 2010 et prévision en 2011.
(en millions d'unités)Domaines 2010 2010 vs 2009
en %2011 2011 vs 2010
en %Télécom 0 - 15 - Bancaire, Fidélité 175 +46 225 +29 Identité, Santé 100 +33 125 +25 Transport 65 +63 80 +23 Sécurité, Contrôle d'accès 30 - 30 - Total 370 +40 475 +28 Le marché du sans contact a connu également en 2010 une forte hausse + 40% en raison des cartes bancaires à la fois contact et sans contact. Le secteur du transport affiche également une forte hausse de +63% pour les puces sans contact.
Si les cartes sans contact sont en train de se déployer de façon importante, une nouvelle technologie sans contact adaptée au téléphone mobile pourrait émerger prochainement : la communication en champ proche ou NFC (Near Field Communication).
Cette technologie permet à la fois d’émuler une carte sans contact (même sans batterie), de transformer le mobile en lecteur de cartes passives ou de faire communiquer deux mobiles (mode « peer to peer »). Ainsi on peut imaginer des services de paiement sans contact et d’accès aux transports publics associés à l’offre de l’opérateur télécom.
Notes et références
Notes
- qui sont nommés dans la littérature scientifique anglo-saxonne COS pour Chip Operating System
Références
- Smart Card Types
- Organisation internationale de normalisation
- (en)Smart Card Tutorial, 1992, p. 4
- (en) Jean-François Dhem et Nathalie Feyt, « Hardware and Software Symbiosis Helps Smart Card Evolution », dans IEEE Micro, no 21, 2001, p. 14-25
- (en) OpenGroup Steve Petri, « Operating System »
- (en) STMicroelectronics, ST22N256 : Smartcard 32-Bit RISC MCU with 256 Kbytes EEPROM JavacardTM HW Execution & Cryptographic Library, 2004
- (en) Selinis, Sklavos et Koufopavlou, « Crypto Processor for Contactless Smart Cards », dans IEEE MELECON, 2004 [texte intégral]
- Processor for Contactless Smart Cards
- , Area-Efficient Universal Cryptography Processor for SmartCards
- (en) ISO/IEC 7816-4 : Identification cards — Integrated circuit cards — Organization, security and commands for interchange, 7 p.
- Smartcard MCU with enhanced security, crypto-processor and 80 Kbytes EEPROM
- L. Guillou 2004, page 5
- G.Grimaud et Al, 2001, p. ???
- #GIE carte bancaire 1984 p. ???
- W. Rankl et Al. 2007, page 16
- #U. Hansmann et Al. 2002, page 28-34
- D.Deville and Al. 2003, p. 1
- JL.Lanet and Al. 1999, p. 1
- A.Galland and Al. 2002, p. 1
- Smart card security and applications de Mike Hendry page 122
- "technet.microsoft.com"
- (en) SOSSE - Simple Operating System for Smartcard Education
- (en)Java Card
- Site officiel Java Card
- Site officiel de JAVA Micro Edition JME
- Java Card Platform Specification 2.X
- Java Card Platform Specification 3.X
- MULTOS Developer's Reference Manual
- site web du consortium MULTOS
- G.Grimaud,2000, p. 1
- D.Engler and Al,1995, p. 1
- JL.Lanet and Al, 1999, p. 1
- D. Deville and Al. 2004, p. 1
- G.Grimaud et Al, 2001, p. 1
- E.Rose and Al,1998, p. 1
- A.Galland and Al,2002, p. 1
Bibliographie
Ouvrages de référence
- GIE Carte Bancaire, LES SPECIFICATIONS ET LES NORMES DE LA CARTE A MEMOIRE BANCAIRE, 1984
- Gilles Grimaud, CAMILLE système d'exploitation Ouvert pour Carte à microprocesseur, 2000 [lire en ligne]
- (en) Wolfgang Rankl (trad. Kenneth Cox), Smart card applications: design models for using and programming smart cards, 2007 (ISBN 978-470-05882-4)
- (en) Uwe Hansmann, Martin S. Nicklous, Thomas Schäck, Achim Schneider et Frank Seliger, Smart card application development using Java : Second Edition, 2002 (ISBN 978-3-540-43202-9), p. 28-34
Articles publiés
- (en) Damien Deville, Antoine Galland, Gilles Grimaud et Sébastien Jean, « Smart Card Operating Systems: Past Present and Future », dans In Proc. 5th NORDU/USENIX Conference, 2003 [texte intégral]
- (en) J.-L. Lanet, J-I Vandewalle et Gilles Grimaud, « FACADE: A Typed Intermediate Language Dedicated to Smart Cards. », dans In Software Engineering–ESEC/FSE’99 (Toulouse, France, October 1999), vol. 1687, 1999, p. 476-493 (ISSN 0302-9743) [texte intégral]
- Antoine Galland, Damien Deville, Gilles Grimaud et Bertil Folliot, « Contrôle des ressources dans les cartes à microprocesseur », dans 1er congrès « Logiciel Temps Réels Embarqués » (LTRE) – 24 & 25 janvier 2002 – Toulouse France, 2002 [texte intégral]
- (en) DR Engler et MF Kaashoek, « Exterminate All Operating System Abstractions. », dans In the 5th IEEE Workshop on Hot Topics in Operating Systems, pages 78-94, Orcas Island, USA, May 1995., 1995 [texte intégral]
- (en) D. Deville, C. Rippert et G. Grimaud, « Flexible bindings for type-safe embedded operating systems », dans In ECOOP Workshop on Programming Languages and Operating Systems (ECOOP-PLOS), Oslo, Norway., juin 2004 [texte intégral]
- G. Grimaud et D. Deville, « Evaluation d'un micro-noyau dédié aux cartes à microprocesseur. », dans Deuxième Conférence Française sur les Systèmes d'Exploitation., mai 2001 [texte intégral]
- (en) E Rose et KH Rose, « Lightweight bytecode verification. », dans In Workshop "Formal Underpinnings of the Java Paradigm", OOPSLA'98, 1998., 1998 [texte intégral]
- (en) C.L. Liu et J.W. Layland, « Scheduling algorithms for multiprogramming in a hard-real-time environnement. », dans ACM 20,1 (January 1973), 46-61.., vol. 20, 1973, p. 46-61 [texte intégral]
- C. Cardeira et Z. Mammeri, « Ordonnancement de tâches dans les systèmes temps réel et répartis. », dans Revue RAIRO, Automatique Productique Informatique Industrielle (APII), vol. 28, 1994, p. 353-384 [texte intégral]
- Louis Guillou, « Histoire de la carte à puce du point de vue d’un cryptologue », dans Actes du septième Colloque sur l'histoire de l'informatique et des transmissions, 2004 (ISBN 2-7261-1281-1) [texte intégral]
Liens externes
- (en)Microsoft, « Introduction to Windows for Smart Cards »
- (fr) Christian Tavernier, « Les cartes à microcontrôleur ou cartes asynchrones »
- (en) CardLogix Corporation, « Integrated Circuits and Card Operating Systems »
- (en) Société Cardwerk, « What is the COS ? »
- (en) Société OCC : OnCardConnect, « Smart Card Operating System »
- (fr) Jérôme Baumgarten - Nicolas Descamps, « La carte à puce », 1999/2000, p. 18
Wikimedia Foundation. 2010.
