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 disponibles lorsque la carte sera redémarrée. Le système d'exploitation gère aussi le Microprocesseur, parfois assorti d’un processeur destiné à 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ées en mémoire 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és dans la mémoire des cartes. Malgré ces limites matérielles, ces COS doivent intégrer des fonctionnalités ainsi que des spécificités telles 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é 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 a 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…).

Une carte à puce ou smart card 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 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.

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 être modifiées 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.

La norme de référence est la norme ISO/CEI 7816 (en)^[2] (Identification cards — Integrated circuit cards), le tableau suivant répertorie les différentes parties de cette norme.

D'autres normes qui concernent les cartes contactless (radio et optique).

Le COS est stocké dans la ROM de la carte à puce. On peut trouver un synonyme au terme COS avec le terme de mask. Pour être plus précis on trouve deux types de mask^[3]:

• hard mask

Indique que le COS est stocké dans une mémoire ROM. Il devient alors non modifiable après l'avoir écrit dans ce type de mémoire.

• soft mask

Indique au contraire un COS dont une partie ou la totalité est stockée dans une mémoire EEPROM. Il devient donc possible de modifier une partie ou la totalité du système après sa première écriture dans l'EEPROM.

Il fournit une API complète afin de communiquer vers les zones mémoire mais également et surtout vers l'extérieur.

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 compact possible et que l'utilisation des capacités mémoire soit raisonnée^[5].

Un autre aspect important est l'usage souvent fait pour ce type de carte, comme 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.

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 de la norme ISO/CEI 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 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 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 cryptoprocesseur sécurisé qui accélère les calculs sur les grands nombres^[11].

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

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^[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 ;
• Puis toujours monolithique mais application et outil d'exploitation sont séparés en trois couches^[13].

Dans ces phases les cartes sont mono-application et l'outil d'exploitation gère des zones^[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^[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és 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].

Ci-dessous quelques exemples de cartes à puce et les éditeurs qui leur sont associés.

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^[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.

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

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 jeu d'instructions de la JCVM (JavaCard Virtual Machine) a donc été adapté et réduit à l'essentiel.

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.

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 est une solution de système d'exploitation pour carte à puce ouverte et non propriétaire.

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 commerce en ligne, le secteur public, etc.

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 jeu d'instructions MEL Bytecode est limité à la manipulation de donnée et à de simples opérations arithmétiques. Bien que ce jeu d'instructions 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.

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.

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 matière 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].

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.

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 entre autres par la résolution des problématiques d'économie d'énergie et la retouche du langage Façade.

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 transports. Les secteurs des télécoms et du bancaire restent toutefois majeurs sur le marché des cartes à puce.

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

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.

• 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, PhD thèse, Laboratoire d'Informatique Fondamentale de Lille (LIFL), 2000 (lire en ligne)
• (en) Wolfgang Rankl (trad. de l'allemand par Kenneth Cox), Smart card applications : design models for using and programming smart cards, Chichester, England, J. Wiley & Sons, 2007, 217 p. (ISBN 978-0-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, Springer, 2002, 305 p. (ISBN 978-3-540-43202-9 et 3-540-43202-7, lire en ligne), p. 28-34

• (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 [archive du 8 décembre 2006])
• (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), LNCS, Springer, vol. 1687,‎ 1999, p. 476-493 (ISSN 0302-9743, 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)
• (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.,‎ juin 2004 (lire en ligne)
• G. Grimaud et D. Deville, « Evaluation d'un micro-noyau destiné aux cartes à microprocesseur. », Deuxième Conférence Française sur les Systèmes d'Exploitation.,‎ mai 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) C.L. Liu et J.W. Layland, « Scheduling algorithms for multiprogramming in a hard-real-time environnement. », ACM 20,1 (January 1973), 46-61.., vol. 20,‎ 1973, p. 46-61 (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), vol. 28,‎ 1994, p. 353-384 (lire en ligne)
• Louis Guillou, « Histoire de la carte à puce du point de vue d’un cryptologue », Actes du septième Colloque sur l'histoire de l'informatique et des transmissions,‎ 2004 (ISBN 2-7261-1281-1, lire en ligne)

• (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 » (version du 4 mai 2011 sur Internet Archive)
• (fr) Jérôme Baumgarten - Nicolas Descamps, « La carte à puce », 1999/2000, p. 18

• Portail de l’informatique
• Portail de la sécurité informatique
• Portail de la cryptologie