Système d'exploitation pour carte à puce

Les systèmes d'exploitation pour carte à puce ou encore smart card's Chip Operating System (COS) sont des systèmes d'exploitation spécifiquement destinés aux cartes à puce. Une carte à puce 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é le système d'exploitation, mais qui ne peut plus être réécrite), et d'une EEPROM (qui conserve les données qui y sont inscrites même après que la carte ne soit 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. A l'image de que représente le PC DOS ou communément n'importe quel autre système d'exploitation, 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 PC DOS, ce type d'OS n'est pas conçu pour fournir d'interface graphique.

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.

Deux types de familles de COS peuvent être distinguées :

• Les COS à usage général qui regroupent un ensemble de fonctions génériques communes pour la plupart des applications.
• Les COS dédiés qui possèdent des fonctions spécifiques pour une ou une liste d'applications particulières et qui peuvent même dans certains cas contenir l'application elle-même.

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 . De nombreux travaux ont consisté à sécuriser le code mobile qui pouvait être chargé dans la carte 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.

Schéma générique d'une carte à puce

Schéma générique d'une carte à puce

Ci-dessus une illustration exemple d'un schéma de carte à puce contactless (en). Ce type de carte permet la communication avec le lecteur de carte :

• via un connecteur physique
• mais aussi via ondes radios (partie gauche du schéma).

Il existe plusieurs types de cartes différentes . Mais pour posséder et faire fonctionner un système d'exploitation et des applications, donc pour exécuter du code, elles doivent contenir un CPU (un Network processorNetwork processor ici en plus), de la mémoire (mémoire ROM, EEPROM, mémoire RAM).

Le système d'exploitation est localisé essentiellement au niveau de la mémoire ROM, sous une forme non altérable, et pour éventuellement certaines de ses fonctions modifiables dans une EEPROM. Il offre les fonctions pour contrôler les différents éléments de la carte et la communication avec le lecteur.

Naissance et évolution des systèmes d'exploitation pour carte à puce

En 1977, Michel UGON découvre l'architecture du SPOM (Self Programmable One-Chip Microcomputer). En 1981, la 1^re carte CP8 sort avec le masque PC0 .

Une importante évolution des outils d'exploitation se fit dans les deux décennies qui suivirent:

• Tout d'abord monolithyque, rien ne distingue l'application de l'outil d'exploitation.
• Puis toujours monolithyque mais application et outil d'exploitation sont séparés en trois couches.

Dans ces phases les cartes sont mono-application et l'outil d'exploitation gère des zones.

• Puis l'outil d'exploitation gère un système de fichier mais est toujours monoapplication.
• L'évolution suivante est la gestion de plusieurs applications.

Problématique des systèmes d'exploitation pour carte à puce

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 , il faut que le code écrit soit le plus compacte possible et que l'utilisation des capacités mémoire soit raisonnée.

Capacité Mémoire Cartes à puce

Elément	Taille en 2004	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.

Parfois, certaines de ces fonctionnalités soient directement intégrés au niveau matériel.

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), 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é.

Normes

La norme de référence est la norme ISO/IEC 7816 (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	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

Les fonctions d'un système de carte à puce

Décrire ici les fonctions de base

Les systèmes d'exploitation

Ci-dessous quelques exemples de cartes à puce et les éditeurs qui leurs 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
MULTOS	Maosco
AuthenIC, SIMphonic	Oberthur Technologies
Micardo	Morpho e-Documents
Cyberflex, Multiflex, Payflex	Schlumberger (entreprise)
CardOS	Siemens (entreprise)
TCOS	Telesec (de)

Nous pouvons trier ces systèmes d'exploitation sous 3 grandes familles :

• Les systèmes vus comme des machines virtuelles
• Les systèmes vus comme des hyperviseurs
• Les autres échappant aux deux catégories ci-dessus

Les systèmes d'exploitation vus comme des machines virtuelles

JAVACARD

Java Card est un système d'exploitation pour carte à puce bâti autour de la technologie JAVA.

La technologie

La technologie Java Card est un sous ensemble (Java Micro Edition ou JME) 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, 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 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

MULTOSMULTOS est une solution de système d'exploitation pour carte à puce ouverte et non propriétaire.

Le Consortium MULTOS

Les spécifications de MULTOS sont maintenues par le consortium MULTOS 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 même 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.

Les systèmes d'exploitation vus comme des hyperviseurs

Le système 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. Camille est 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. 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. 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. L'instruction invoke permet d'appeler une des opérations exportées par les composants formant le système Camille. Ainsi, 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é. Les applications et extensions système peuvent être programmées à l'aide de langages de haut niveau comme le C ou le Java. 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 pour des besoins forts en termes de performances d'exécution. La confidentialité et l'intégrité des applications sont garanties à l'aide d'une vérification de typage.

Camille a dû évoluer afin d’y intégrer les propriétés de contrôle mémoire et temps réel dans le contexte du multi-tâches^{[réf. nécessaire]}.

Camille RC : Resource Control ou contrôle mémoire

La mémoire est une ressource rare dans les cartes à microprocesseur : environ 2/4 ko de mémoire volatile (RAM), 64/128 ko de ROM et 32/64 ko de mémoire non volatile (mémoire Flash ou EEPROM) pour les cartes les plus performantes du marché. Aujourd’hui, le contrôle des ressources, notamment la mémoire, est assuré lors de l’exécution. Une zone mémoire est réservée au démarrage. Ceci n'est pas optimal car il n’y a pas de re-négociation de la mémoire réservée pour une application même s’il existe de la mémoire libre en dehors de la zone réservée.

La solution proposée^{[réf. nécessaire]} se compose de deux parties :

• 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

Dans l’architecture Camille, comme dans la culture carte en général, l’activité du microprocesseur n’est pas partagée entre plusieurs applications. Les problèmes temps réel sont bien connus dans le contexte de l’informatique conventionnel.

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. Un autre point critique à prendre en compte est le chargeur de code intermédiaire et plus particulièrement l’analyse du code chargé qui doit maintenant être capable de détecter et de borner en temps d’exécution les sections critiques du code afin d’intégrer l’activité propre à cette tâche dans l’ensemble des applications déjà chargées.

Le contrôle des ressources (mémoire, processeur et communications) dans les systèmes ouverts des cartes à puce restent aujourd’hui un enjeu à maîtriser. Il faut aller plus loin que la vérification d’intégrité et de confidentialité des données. Pallier les attaques en disponibilité (mémoire ou temps) est donc une étape nécessaire à cette réalisation.

Les autres systèmes d'exploitation

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. Les développements peuvent se faire en Visual Basic, Visual C++.

Economie des systèmes d'exploitation pour cartes à puce

Domaine d'application des cartes à puce

Marché des cartes à puce et systèmes d'exploitation associés en 2010 et prévision en 2011.
(en millions d'unités)
Source : eurosmart.com déc 2010

Domaines	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
Banquaire, Fidélité	B0', EMV	MultOS(50) JavaCard	880	+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 plus part 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)
Source : eurosmart.com déc 2010

Domaines	2010	2010 vs 2009 en %	2011	2011 vs 2010 en %
Télécom	0	-	15	-
Banquaire, 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.

Bibliographie

Articles publiés

• (en) Damien Deville, Antoine Galland, Gilles Grimaud et Sébastien Jean, « Smart Card Operating Systems: Past Present and Future », In Proc. 5th NORDU/USENIX Conference,‎ 2003 (lire en ligne)

• (en) J-L Lanet, J-I Vandewalle et Gilles Grimaud, « FACADE: A Typed Intermediate Language Dedicated to Smart Cards. », In Software Engineering–ESEC/FSE’99 (Toulouse, France, October 1999), no. 1687 in LNCS, Springer,pp. 476–493,‎ 1999 (lire en ligne)

• Antoine Galland, Damien Deville, Gilles Grimaud et Bertil Folliot, « Contrôle des ressources dans les cartes à microprocesseur », 1^er congrès « Logiciel Temps Réels Embarqués » (LTRE) – 24 & 25 janvier 2002 – Toulouse France,‎ 2002 (lire en ligne)

• Gilles Grimaud, « CAMILLE système d'exploitation Ouvert pour Carte à microprocesseur », PhD thèse, Laboratoire d'Informatique Fondamentale de Lille (LIFL), 2000,‎ 2000 (lire en ligne)

• (en) DR Engler et MF Kaashoek, « Exterminate All Operating System Abstractions. », In the 5th IEEE Workshop on Hot Topics in Operating Systems, pages 78-94, Orcas Island, USA, May 1995.,‎ 1995 (lire en ligne)

• (en) D Deville, C Rippert et G Grimaud, « Flexible bindings for type-safe embedded operating systems », In ECOOP Workshop on Programming Languages and Operating Systems (ECOOP-PLOS), Oslo, Norway, June 2004.,‎ 2004 (lire en ligne)

• G Grimaud et D Deville, « Evaluation d'un micro-noyau dédié aux cartes à microprocesseur. », Deuxiµeme Conférence Française sur les Systèmes d'Exploitation, mai 2001.,‎ 2001 (lire en ligne)

• (en) E Rose et KH Rose, « Lightweight bytecode verification. », In Workshop "Formal Underpinnings of the Java Paradigm", OOPSLA'98, 1998.,‎ 1998 (lire en ligne)

• (en) CL LIU et JW Layland, « Scheduling algorithms for multiprogramming in a hard-real-time environnement. », ACM 20,1 (January 1973), 46–61..,‎ 1973 (lire en ligne)

• C Cardeira et Z Mammeri, « Ordonnancement de tâches dans les systèmes temps réel et répartis. », Revue RAIRO,Automatique Productique Informatique Industrielle (APII) 28 (1994), 353-384.,‎ 1994 (lire en ligne)

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