Cours carte à puce

Historique, concepts, sécurité des cartes, TP
© Pascal Chour, 1989 - 2017
Mise à jour, avril 2017, 10ème édition indice 4
Le logiciel PCCAM permet de réaliser les TP décrits dans ce cours

AVERTISSEMENT

Le présent cours est destiné à des fins pédagogiques. Ses lecteurs s'engagent à ne pas utiliser les informations qu'il contient à des fins illicites.

Ce cours relève de la seule responsabilité personnelle de son auteur et ne peut engager son employeur ou toute institution de formation, qu'elle soit privée ou publique, qui l'emploie.


SOMMAIRE DETAILLE

PREAMBULE
GENERALITES SUR LES CARTES
ACTEURS DE LA CARTE SECURITE DE LA CARTE QUELQUES APPLICATIONS DE LA CARTE
NORMALISATION LECTEURS DE CARTES ANNEXE, ANCIENNES CARTES ANNEXE, HISTOIRES DE PROJETS TRAVAUX PRATIQUES

PREAMBULE

Ce document est la mise à jour d'un cours que je donnais dans les années 1980 sur les cartes à puce et vient compléter la (déjà) abondante documentation sur le sujet.

Il vise à faire le point sur la technologie des cartes à puce, leurs applications, leur sécurité, et tente de montrer comment le marché à évolué depuis, non pas sa création (et oui, il y a une histoire avant celle que je raconte. Voir la partie bibliographie juste après), mais au moins, depuis une période suffisamment lointaine pour que l'on puisse parler de « vieillerie » ce qui après tout, est le thème de ce site.

Toutefois, les plus jeunes lecteurs qui ne sont pas forcément (encore) intéressés par l'histoire trouveront également de quoi se former aux cartes actuelles avec en prime, un petit logiciel qui leur permettra de faire quelques expérimentations.

Dernier point : certains chapitres traitent d'anciens projets qui reposent en paix aujourd'hui (c'est tout ce qu'on peut leur souhaiter). Pour les plus concernés, je les ai mis en annexe. Néanmoins, j'ai tenu à conserver les exemples parlant de projets tels que les cartes PASTEL ou la Télécarte ou les premières cartes bancaires françaises car ils permettent de se rappeler que de nombreuses expérimentations avaient été faites dès les années 80, donnant lieu à des projets d'envergure, et aussi parfois, à des échecs retentissants. La lecture de ces chapitres devrait permettre d'éviter à certains de réinventer la roue (et de perdre du temps et surtout, d'en faire perdre aux autres, mais là, c'est juste un rêve).

Quelques liens sur des documents à lire pour compléter ce cours

GENERALITES SUR LES CARTES

Depuis les années 1980, la carte à puce s'est imposée dans notre quotidien, qu'il s'agisse de cartes bancaires, dans le passé de Télécartes, des cartes SIM de nos téléphones portables, etc.

Elle a donné naissance à une importante activité économique qui touche la fabrication de composants électroniques, le développement de logiciels, les processus de personnalisation et de distribution, les machines outils, les périphériques, le développement d'applications, les tests de conformité, les tests de sécurité, etc.

Mais surtout, cette invention a créé un objet de sécurité dans le domaine des technologies de l'information dont la sécurité intrinsèque est sans commune mesure avec tout ce que l'on peut faire par ailleurs. Le fait est paradoxalement peu connu :

Un des objectifs de ce cours est de montrer en quoi cet objet est particulier du point de vue de la sécurité.

Vocabulaire

Dans les années 1980, on parlait en France de « cartes à mémoire » pour désigner l'objet composé d'une carte plastique au format « carte bancaire » et d'un composant électronique inséré dans l'épaisseur de la carte.

Assez rapidement, il est apparu que le terme était impropre. Il a même été à l'origine d'une confusion lorsque le groupement INTAMIC (dont Eurosmart doit être un lointain successeur) a fait réaliser une étude de marché internationale au milieu des années 1980.

En particulier, les japonais contestaient l'intérêt de ce dispositif au prétexte que les cartes à mémoire étaient déjà largement répandues, par exemple, pour permettre le chargement des polices de caractères dans les imprimantes... Si le débat devait avoir lieu aujourd'hui, on parlerait probablement de clés USB.

Dans ces deux exemples, on a bien un dispositif électronique communicant mais pas de sécurité. Sans compter qu'il existe des tas d'autres exemples où l'on a bien des cartes, de la mémoire (une bande magnétique par exemple) mais pas de composant électronique du tout.

Le terme « carte à puce » s'est ensuite susbtitué à la « carte à mémoire » afin de mieux faire ressortir le caractère électronique de l'objet. Il était encore utilisé en France dans les années 2010. S'il est plus juste que le précédent, il fait quand même oublier l'essentiel.

La carte, dans ses différents facteurs de forme, n'est qu'un accident de parcours dans l'utilisation de cette technologie. Certes, elle l'a popularisée. Mais ce qui compte, ce n'est pas le support de la puce, c'est la puce elle-même dont on pourrait résumer les particularités de la façon suivante :

Il s'agit d'un composant électronique communicant,
réalisant des fonctions logiques
et destiné à mettre en œuvre de façon active (par lui-même)
des fonctionnalités de sécurité.

Par rapport à cette définition, le terme « carte à puce » pose deux problèmes : il passe sous silence l'aspect sécurité et laisse à penser que cette technologie est associée à un facteur de forme.

C'est ainsi que certains ont pu entretenir la confusion entre les les puces RFID (Radio-Frequency Identification) et les cartes à puce sans contact. Les puces RFID existent depuis les années 1980. A l'époque, elles utilisaient une pile. Avec le temps, elles ont tiré leur alimentation du champ électromagnétique utilisé pour communiquer avec elles. On les trouve dans certains systèmes de contrôle d'accès physiques (non sécurisés !), dans des systèmes d'identification d'animaux, de containers, de produits de grande consommation, etc. La différence entre les puces des RFID qui se retrouvent parfois dans des cartes et les « cartes à puce » porte encore une fois sur la sécurité : la plupart des RFID n'ont aucune vocation sécuritaire. Cela pourrait changer (il existe de nombreux projets pour réaliser des RFID sécurisés) mais dans ce cas, on retombera probablement sur les technologies de la cartes à puce.

Le terme « carte à microcircuit » ou plus restrictif, « carte à microprocesseur » est également utilisé, en particulier, dans la normalisation. Il est à peine plus précis que le terme « carte à puce » mais a permis un temps de distinguer plus ou moins deux technologies :

Mais là encore, rien sur la sécurité.

Le terme le plus approprié serait probablement « carte à microcontrôleur sécurisé » ou « carte à microcircuit sécurisé » mais c'est un peu long.

Le terme qui a tendance à s'imposer depuis les années 2000 est celui d'« élément sécurisé » (ou en anglais, secure element). Il s'agit presque d'un retour aux origines lorsque l'on considère l'intitulé du brevet de la carte Bull-CP8. Il décrit enfin ce qui fait une particularité importante du dispositif (la sécurité) et ce, sans l'associer à un facteur de forme (carte) ni à une technologie particulière. On peut donc intellectuellement envisager son utilisation dans d'autres choses que des cartes. Je devrais dire « de nouveau envisager » puisqu'à l'origine, les premières idées d'applications n'étaient pas forcément associées aux cartes et l'on trouvait des équipements intégrant des composants de « cartes à puce » en boitier DIL comme par exemple, une carte d'extension de Bull-CP8 utilisée en coprocesseur sécurisé pour les ordinateurs compatibles IBM-PC.

A la fin des années 1980, mon cours commençait par faire la différence entre « carte à mémoire » et « carte à microprocesseur » (CAM dans la suite du document). Je ne l'ai pas conservé dans le corps de ce document mais pour ceux que cela intéresse, vous trouverez en annexe quelques informations sur certaines technologies mise en oeuvre à l'époque dans les « cartes à mémoire » (en particulier, les cartes à piste et les cartes laser).

Par contre, j'ai tenu à conserver une brève description des cartes en logiques câblées qui ont été les précurseurs de la carte à microprocesseur

Les cartes en logique câblée

En 1973, la société Nord Américaine Intel conçoit et réalise les premières mémoires permanentes électroniques inscriptibles électriquement (EPROM 1702) ainsi que le premier micro-processeur (8008. Ok, pour les pinailleurs, il y avait eu le 4004 un peu avant mais on ne jouait pas tout à fait dans la même cour).

img
EPROM 1702 de mon stock personnel. Cliquez pour agrandir.

En 1974, le Français Roland Moréno (décédé le 29 avril 2012 à 66 ans) dépose une série de brevets dont un concernant un « système pour transférer des données de manière personnelle et confidentielle au moyen d'objets portatifs électroniques indépendants » et crée la société Innovatron (les autres brevets porteront sur des mécanismes de protection de ces données et des moyens de communication du dispositif avec l'environnement). A l'origine, on peut remarquer que rien ne liait particulièrement ce système électronique avec la carte plastique au format bancaire. Il en est toujours de même aujourd'hui mais c'est sous cette forme qu'il est le plus répandu et le plus connu

Schématiquement, la carte en logique câblée peut se décomposer en deux sous-ensembles. D'une part, une mémoire inscriptible électriquement, d'autre part, un automate en logique câblée chargé de gérer les communications avec l'environnement et de contrôler l'accès à la mémoire. Les cartes F256 ayant servi à la Télécarte française ou la MZ9K, toutes les deux des années 1980 et distribuées à l'époque par la société Schlumberger (ou plus tard, par Gemplus sous les références GPM256, GPM416, GPM896) en sont des exemples. Cette technologie apporte une certaine « intelligence » à la carte.

Carte à micro-processeur

Avec les cartes à microprocesseurs, on assiste à un véritable saut technologique et fonctionnel. Ce sont ces types de cartes qui permettent de réaliser des systèmes d'identification et d'authentification offrant un très grand niveau de sécurité. Celles-ci ont été inventées par la société Bull et le brevet a été déposé en 1978 (Michel Hugon). Comme on le remarque, la carte la plus courante n'est pas réellement l'invention de Roland Moréno.

La CAM de l'époque se composait d'un micro-processeur, d'une mémoire ROM (Read Only Memory) contenant le programme d'application de la carte, d'une mémoire vive (RAM Random Access Memory), et des systèmes logiques permettant de réaliser un micro-ordinateur complet. A tout cela, on ajoutait une mémoire de type EPROM dont le rôle était de mémoriser de façon permanente des informations durant la vie de la carte.

Le petit nom de l'époque désignant ce microcontrôleur spécifique était MAM pour Micro-calculateur Autoprogrammable Monolythique (ou SPOM en anglais pour Self Programmable One-chip Microcomputer).

A priori, rien ne la distinguait beaucoup d'un microcontrôleur traditionnel (comme le Intel 8085 par exemple). C'est pour cette raison que le brevet sera longtemps contesté (par exemple, par Schlumberger qui était alors le leader mondial dans la fabrication des cartes... en logique câblée). Toutefois, le brevet de Bull-CP8 (CP8 pour Circuit portatif des années 1980 d'après Roland Moreno) finira par s'imposer car ce qui distingue cette carte (et en pratique, ce concept) d'un banal microcontrôleur est la sécurité. C'est en fait un véritable coup de génie qu'à réalisé Bull-CP8 en positionnant son invention dans ce domaine, ce qui à l'époque, était loin d'être évident. Entracte : voici la photo d'une carte Bull-CP8 masque M4, recto... et verso.

img   img

Cette carte, émise au nom de Supelec Rennes, offrait une application de porte-monnaie privatif sécurisé et a été mise en service en 1986. Sa capacité mémoire de l'époque, couplée au fait qu'elle n'était pas effaçable, permettait de l'utiliser environ 2 ans dans une application de restauration collective (400 transactions). Mais ce qui est intéressant, c'est ce qui est au dos de la carte et qui justifie le véritable intérêt de l'invention de Bull-CP8.

La carte d'aujourd'hui semble peu différer de la carte d'alors. En fait, quelques modifications importantes lui ont été apportées. Nous y reviendront plus tard mais on peut tout de même citer :

Cartes avec contacts

Pour pouvoir utiliser ce micro-ordinateur, il était nécessaire de lui fournir de l'énergie et de lui donner la possibilité de communiquer avec l'extérieur. La normalisation internationale, après bien des péripéties (cf chapitre « Normalisation ») a défini une position à donner aux contacts de la carte et la signification de chacun d'eux. On y trouve, les contacts d'alimentation (Vcc et masse), un contact d'horloge (le micro-processeur est un système synchrone utilisant une horloge qui a l'époque était fournie par l'environnement), un contact pour les entrées/sorties bidirectionnelles à l'alternat, un contact de remise à zéro (ré-initialisation, Reset) et un contact permettant d'appliquer la tension et le courant de programmation pour la mémoire EPROM. Ces 6 contacts étaient complétés par deux autres réservés à un usage futur.

img

Cartes sans contacts

Assez rapidement, il est apparu souhaitable de disposer de cartes permettant de réaliser des transactions sans qu'il y ait nécessité de les insérer dans un lecteur.

Dans ce mode, le principal problème à résoudre est l'alimentation électrique de la carte. En mode contact, cette alimentation se fait via les contacts. En mode sans contact, il faut trouver autre chose.

Dès les années 1980-1990, il a existé des dispositifs de type « RFID », sans sécurité particulière, utilisant une pile pour transmette des informations. Ces dispositifs étaient par exemple utilisés pour marquer des animaux afin de les identifier (par exemple, pour actionner un dispositif d'entrée-sortie ou pour déverser de la nourriture dans une mangeoire).

C'est également dans ces années que l'on a imaginé utiliser des dispositifs permettant de valider un titre de transport dans un bus ou un métro. Le dispositif pouvait être constitué d'un boitier comportant des piles et un lecteur interne permettant de lire et d'écrire dans une carte à contact que l'on insérait à demeure dans le boitier (un peu comme les cartes SIM) et d'un dispositif de communication RF (radiofréquence) ou infrarouge pour communiquer avec le valideur.

Toutes ces approches sont dites « actives » dans le sens ou la carte, ou ce qui en tient lieu, dispose d'une source d'énergie permettant d'émettre des informations sans dépendre d'un apport d'énergie extérieur et/ou d'alimenter le dispositif électronique.

Les composants électroniques consommant de moins en moins, on a pu imaginer des cartes directement alimentées grâce à l'énergie générée par un champ électromagnétique. Les cartes sont alors munies d'une antenne dont le rôle est double :

Ces cartes existent depuis la fin des années 1990 et sont dites « passives ». Ce sont elles qui méritent vraiment l'appellation de Cartes sans contacts. On parle aussi de cartes NFC (pour Near Field Contactless). Cet acronyme signifie que la carte est alimentée et communique en champ proche (quelques centimètres) avec un lecteur. La suite de ce cours ne traitera que de ce type de cartes. Pour rendre les choses plus concrètes, un petit rappel de physique élémentaire.

Principes physique du NFC

(Les schémas qui suivent viennent de RFID handbook sur http://rfid-handbook.de/about-rfid.html).

Considérez un bobinage caractérisé par sa forme, le nombre de tour de fil de la bobine et sa taille. Si vous faites passer un certain courant alternatif à une certaine fréquence (13,56MHz pour les cartes dont il est question ici), ce bobinage va produire un champ électromagnétique dans son environnement.

Si vous placez un second bobinage à proximité, sous réserve d'une bonne adaptation et d'une charge adaptée, ce bobinage va récupérer une partie de ce champ électromagnétique qui va générer un certain courant sous une certaine différence de potentiel en fonction de la charge.

img

Ce courant peut alors être utilisé pour alimenter un montage électronique, dans notre cas, une carte à puce.

Reste à voir comment il est possible de faire passer une information entre ces deux bobinages.

Communications de données

Puisque les deux bobinages sont couplés, si l'on change les caractéristiques de l'un, il y aura une influence sur l'autre. En particulier, si l'on modifie la charge associée à une bobine, on modifie l'impédance de charge vue par l'autre bobine ce qui créé une différence de potentiel qui peut servir à transmettre une information.

img

Pour des raisons de performances et de complexité de réalisation, on n'utilise pas directement cette technique. Autour de la fréquence porteuse de 13,56MHz, on va moduler deux sous-porteuses (à 14.0475 MHz et à 12.7125, donc une largeur de bande = 847,5kHz)). Ce sont ces sous-porteuses qui serviront à transporter l'information après un filtrage adéquat visant à supprimer la porteuse. Le débit retenu pour ces fréquences est de 106kbps.

img

Les modulations utilisées peuvent être l'ASK (une modulation d'amplitude de la sous-porteuse), PSK (une modulation de phase) et FSK (une modulation de fréquence).

Si vous ne savez pas ce qu'est une porteuse ou une modulation, je vous conseille la lecture du livre de Lucien Chrétien, « la TSF sans mathématique », de 1935. Comme vous pouvez le constater, ces techniques ne sont plus très jeunes…

Carte et sécurité, un aperçu

En quoi les cartes à microprocesseur présentent-t-elles une sécurité quelconque ?

Concept de composant monolithique

Par composant monolithique, il faut comprendre que tous les éléments du micro-ordinateur décrits ci-dessus se trouvent implantés sur une seule pastille de silicium (monocomposant). Ce concept très important permet de garantir qu'il est très difficile, de déterminer un chemin de données entre les différents éléments. De cette façon, il est très difficile d'espionner les informations circulant entre le micro-processeur et la mémoire EPROM ni d'intervenir au niveau de cette mémoire pour y mettre des informations non désirées.

Mémoires EPROM et E²PROM

L'utilisation de ce type de mémoire plutôt qu'une simple PROM rend quasi impossible sa relecture par attaque directe (loupe binoculaire ou microscope électronique). En simplifiant, la mémorisation au niveau d'une cellule consiste à piéger des électrons dans la porte d'un transistor à effet de champ. Cette base est isolée du drain et de la source par une barrière isolante d'oxyde de silicium (SIO2). La cellule est programmée en injectant des charges sous haute énergie à travers la couche d'oxyde. Les électrons se trouvent alors piégés dans la porte. Il peut se produire un léger courant de fuite qui fait que la cellule se déchargera spontanément au bout d'un certain temps. Les EPROM sont garanties pour avoir une durée de rétention d'information d'environ 10 ans. En pratique, je dispose de cartes ayant 25 ans et qui conservent toute leur mémoire.

L'inconvénient de l'EPROM est qu'elle n'est pas effaçable de manière simple (on peut l'effacer aux UV, mais en général, d'un bloc). Depuis le début des années 1990, les E²PROM (effaçables électriquement) ont pour cette raison remplacé les EPROM, non sans quelques problèmes au départ. Les premières cartes à E²PROM ont été japonaises. Elles avaient tendance à perdre la mémoire au démarrage du fait d'une mauvaise gestion de la remise à zéro qui entraînait des écritures non contrôlées. Les fabricants ont amélioré le mécanisme de « Reset » et ce problème ne semble plus ce produire aujourd'hui.

Accès à la mémoire

Par construction, il est impossible d'accéder directement aux mémoires de la carte. Toutes les opérations de lecture et d'écriture sont contrôlées par le micro-processeur et son programme associé.

Ces sécurités physiques justifient les moyens logiques mis en oeuvre dans les programmes de la CAM afin d'en faire un moyen sûr pour réaliser les fonctions d'identification, authentification, certification, etc.

Il est délicat de décrire les fonctions offertes par une CAM dans l'absolu. Il est en effet possible de créer autant de programmes d'application de carte que l'imagination le permet. Toutefois, certaines d'entres elles font partie du lot habituel que l'on rencontre sur ce type de carte :

Fonctionnalités externes

Les CAM peuvent exécuter des ordres permettant d'effectuer des opérations de lecture et d'écriture, des calculs cryptographiques, etc. L'exécution de ces ordres peut être soumis à certaines contraintes comme des présentations de codes secrets. Certaines cartes sont conçues pour des usages très généraux (les cartes M4, TB100, DX des années 1980 par exemple ou IAS dans les années 2000). D'autres sont conçues au départ pour un usage plus spécifique comme par exemple, les cartes dites « porte-clés » PC0, PC1, PC2 du CCETT ou les cartes « passeport ».

Identification et authentification du porteur

Dans de nombreuses applications, une carte est affectés à un porteur (utilisateur) donné et identifié (exemple, la carte bancaire, la carte santé). L'accès à certains services nécessite que l'on ait l'assurance que l'utilisateur de la carte en est bien le porteur légitime. De nombreuses cartes offrent un mécanisme d'authentification du porteur. Généralement, cette authentification se fait par l'intermédiaire d'un code secret (ou code porteur ou PIN) que seul le propriétaire de la carte est censé connaître. Ce code est inscrit dans la mémoire E²PROM et le programme interdit sa divulgation à l'extérieur de la carte. C'est la carte elle-même (et non un équipement externe) qui vérifie le code qu'on lui présente et autorise ou non l'exécution des autres ordres que l'on est susceptible de lui présenter. Généralement, il est prévu un mécanisme qui bloque la carte lorsque le nombre de codes faux présentés dépasse une certaine valeur. Certaines cartes offrent la possibilité d'enregistrer une caractéristique biologique de son porteur (ou au moins la signature de cette caractéristique). Il peut s'agir d'une empreinte digitale ou d'un fond d'oeil. Les progrès réalisés dans la reconnaissance de l'écriture manuscrite permettent également de faire une reconnaissance de signature. Si ces moyens d'identification peuvent paraître plus sûr que le code secret, il faut toutefois être conscient que les équipements périphériques permettant la « saisie » du code d'identification sont actuellement relativement coûteux et parfois complexes à mettre en oeuvre.

Authentification de la carte

Dans les télétransactions (transactions à distance via un réseau téléinformatique par exemple), il n'est pas possible de s'assurer visuellement que la carte utilisée n'est pas une carte simulée. On va alors lui faire exécuter un calcul cryptographique dont le résultat dépend d'une information secrète contenue dans sa mémoire. Il est souvent possible de conditionner l'exécution de ce calcul par une authentification préalable du porteur. De cette façon, on a l'assurance, d'une part de dialoguer avec une carte émise par un organisme autorisé et d'autre part, que l'utilisateur de la carte en est bien le propriétaire.

Certification d'information

Comment s'assurer à distance qu'une information censée être lue dans la mémoire d'une carte est effectivement inscrite dans cette mémoire ? Un cas typique est la lecture à distance d'une date de fin de validité ou d'un solde de porte-monnaie. La lecture certifiée d'information est un moyen de s'assurer qu'une information est effectivement inscrite dans la mémoire de la carte. Le mécanisme utilisé est similaire à celui de l'authentification de la carte sachant que le résultat du calcul cryptographique dépendra également de l'information que l'on désire certifier.

Cryptographie

Certaines applications nécessitent de chiffrer les informations à transmettre. Jusqu'à l'apparition des méthodes de chiffrement à clé publique, un des problèmes consistait à faire parvenir de façon sûre, la clé de déchiffrement au destinataire. Grâce à ses fonctions de calcul et les informations secrètes pouvant être contenues dans la mémoire de transaction, la carte peut être utilisée comme générateur de clé pour une machine à chiffrer et même se substituer à cette dernière.

La plupart de ces fonctions sont rendues possibles grâce aux fonctions de calcul offertes par la carte. Ces fonctions peuvent être secrètes (cf fonction TELEPASS de Bull-CP8 dans la carte M4) ou publiques (le DES, l'AES par exemple), à clé secrète ou à clé publique (RSA, courbes elliptiques).

Tout cela ne s'est pas fait sans mal. Dans les années 1980, la cryptographie était contrôlée et nécessitait des autorisations de la part du service du chiffre puis du SCSSI (Service Central de la Sécurité des Systèmes d'Information, créé par Laurent Fabius en 1986). Généraliser l'utilisation d'une carte à puce bancaire revenait donc à généraliser le port d'arme pour tous les citoyens puisque la cryptographie était considéré comme une arme de guerre pour les opérations de chiffrement (décret loi de 1939). Finalement, les cartes furent décontrôlées moyennant le fait qu'à l'époque, elles ne pouvaient pas mettre en oeuvre des algorithmes trop sophistiqués (ce qui de toute façon était rendu difficile par le peu de capacité mémoire et puissance de calcul des composants de l'époque) et moyennant le fait qu'elles ne faisaient pas de chiffrement (TELEPASS était une fonction non réversible à clé secrète). Depuis la fin des années 1990, la tendance est plutôt inverse et les cartes sont devenues de véritables ressources cryptographiques.

ACTEURS DE LA CARTE

Si l'on exclue les émetteurs de cartes et les sociétés de services et d'ingénierie, les principaux intervenants dans la fourniture des moyens CAM sont :

Comme on le verra, certaines de ces fonctions sont souvent regroupées au sein d'une même société.

La figure ci-dessous décrit les différentes phases de vie d'une carte à puce et permet de mieux comprendre l'intervention des différents acteurs décrits ci-après.

img

Les fabricants de composants

Les fabricants de composants pour CAM dîtes « haute sécurité » sont peu nombreux. On trouve essentiellement quelques Européens, quelques Japonais et un Coréen. MOTOROLA a été la première entreprise capable de fournir industriellement des composants pour CAM avec une offre basée sur le 6805. Ce composant utilisé entre autres pour la carte M4 disposait de 1,6 ko de mémoire programme, 1 ko de mémoire de transaction et 36 octets de mémoire vive. MOTOROLA n'est néanmoins pas resté sur ce marché, suite peut-être aux problèmes connus par les premières cartes PC2 pour la télévision à péage.

Le consortium THOMSON-SGS, devenu ST Microelectronics est un des autres acteurs majeur dans le domaine de la fourniture de composants. La première offre était basée sur le 8048. Il disposait d'une mémoire programme de 2 ko, d'une mémoire de transaction de 1 ko et de 48 octets de mémoire vive. Depuis, la gamme s'est étoffée et après un passage à vide au milieu des années 2000, le groupe refait partie des fournisseurs importants de ce type de composants.

PHILIPS-TRT a été la première société à produire en 1992 un composant permettant l'exécution d'algorithmes à clé publique (RSA, GQ...) dans un temps raisonnable (pour plus de précisions voir le chapitre « Premières crypto-cartes »).

Ce composant a été utilisé dans la carte DX avec l'algorithme RSA et dans la carte Mimosa de Gemplus avec l'algorithme GQ. Petit à petit, on a oublié TRT, puis cette activité de PHILIPS a été vendue à un fond de pension. En 2012, la société s'appelait NXP.

SIEMENS a également été un fournisseur important de composants pour cartes à puce. Cette partie de l'activité a pris son indépendance et la société était, en 2012, connue sous le nom d'INFINEON.

SAMSUNG, deuxième fabricant de composants dans le monde en 2012 est devenu un des fournisseurs important de composants sécurisés.

ATMEL (partie européenne) fut également une société réputée dans ce domaine. ATMEL corporate a revendu cette activité en 2010 à la société française INSIDE CONTACTLESS, devenue pour la circonstance, INSIDE SECURE. A noter qu'INSIDE SECURE est ce qu'on appelle un fabless : la société ne dispose pas de sa propre fonderie (là où les composants sont fabriqués). Il sous-traite donc cette activité.

En mai 2016, Inside secure a définitivement abandonné l'activité « composants » en la revendant à la société Suisse WISeKey. WiseKey n'étant pas particulièrement reconnu dans ce domaine, cet événement marque probablement la fin de la filière issue d'ATMEL.

Les Japonais ont eu également plusieurs sociétés fabriquant des composants pour cartes à puce. Citons en particulier HITACHI, TOSHIBA, NEC, SHARP, OKI.

Enfin, à partir des années 2000, l'industrie chinoise était de plus en plus présente sur ce marché mais en 2012, les composants fabriqués n'étaient pas considérés comme de « haute sécurité ».

Puisque l'on parle de composants, il est temps de donner une petite idée des performances de ceux que l'on a pu trouver sur le marché jusqu'aux modèles actuels.

Fab. & Ref.

Année

ROM

E²PROM

Flash

RAM

Processeur

Motorola
SC01/MAM01

~1983

1,6ko

1ko
(EPROM)

NA

36o

6805, 8bits, 4MHz

TRT-Philips (NXP)
P83C852

~1995

16ko

4ko

NA

256o

80C51, 8 bits, 10MHz

Inside Secure/Atmel
AT90SDC100
Master core
Secure Core

~2010



128ko
64ko



36ko
18ko

NA



6 ko
6 ko

RISC SecureAVR 8/16 bits,
bi-processeur, 30 Mhz

Infineon
SLE78CX1440P

~2010

288ko

144ko

NA

8 ko

Dual 16 bits, 33MHz

ST Microelectronics
ST33F1M

~2011

256o d'OTP + ROM sys.

NA

1 280 ko

30 ko

ARM SecureCore, RISC 32 bits, 30MHz

Et voici deux photographies de deux composants ayant environ 10 ans d'écart. On note une plus grande accessibilité aux bus sur le premier composant que sur le second ou tout semble noyé (glue logique). Sachant que le second composant avait probablement un bouclier actif qui a été retiré pour la photo. Voila pourquoi, les technologies évoluant, il est important de ne pas laisser trop longtemps des cartes sur le terrain. Des composants qui étaient résistants à des attaques de haut niveau il y a dix ans ne le sont plus forcément aujourd'hui.

img img

Les concepteurs de masques

Il n'est question dans ce chapitre que des sociétés qui proposent des cartes dites de « haute sécurité ».

Le concepteur de masque le plus connu dans le domaine des CAM « haute sécurité » a longtemps été le créateur du concept lui-même à savoir Bull CP8 créée en 1985 avec son MAM (Micro calculateur Auto-programmable Monolithique). Cette société a en particulier réalisé la carte M4 utilisée en France pour les applications bancaires et téléphonique (carte PASTEL). En 1993, L'offre Bull-CP8 portait sur une dizaine de masques dont certains ont été initialement conçus par des organismes de recherche (CCETT par exemple). En 1990, Bull-CP8 et François-Charles Oberthur ont conclut un accord de partenariat qui a eu pour conséquence de transférer l'activité d'encartage de Bull-CP8 depuis ses locaux de Trappes dans de nouvelles unités de production en Bretagne (CP8-Oberthur et CP8 Micro-électronique). L'activité de production de masque sera finalement reprise par la société Axalto elle-même issue de la société Schlumberger (voir ci-après). Bull n'a donc plus d'activité dans ce domaine.

Philips-TRT que l'on a déjà cité parmi les fabricants de composants est également un concepteur de masques. Les cartes D1 et D2 produites à la fin des années 1980 étaient particulièrement bien adaptées aux applications de sécurité (contrôle d'accès et d'habilitation à des systèmes d'informations, signature électronique...). En 1989, un accord a été signé avec Bull-CP8 afin de mettre en commun les ressources nécessaires en matière de recherche et développement de nouveaux masques. Le premier résultat de ce travail commun a été la carte TB100 (TB pour TRT/BULL) reprenant une partie des fonctionnalités de la carte MP de Bull-CP8. Cette entité a été vendue à l'anglais Delarue.

Schlumberger a longtemps revendiqué le titre de premier producteur de CAM au monde. En fait, tout dépend de la définition que l'on donne au terme « carte à mémoire » (cf chapitre précédent). Si l'on ne prend en compte que les cartes à micro-processeur, Schlumberger n'était dans les années 1980 qu'un tout petit producteur (ce qui n'exclut pas d'avoir de l'ambition). Jusqu'en 1990, le plus gros de la production de cette société était encore la carte F256 (carte en logique câblée) avec comme plus gros client France-Télécom (Télécarte). A partir de 1997, Schlumberger pouvait revendiquer une place de leader aux cotés de la société Gemplus. Finalement, l'activité carte de Schlumberger donnera naissance à la société Axalto qui reprendra les activités de conception de masque et de lecteurs de Bull-CP8..

Gemplus, créé en 1988 a eu un démarrage fulgurant grâce à un produit particulièrement souple : le COS (Chip Operating System, voir le chapitre consacré aux cartes COS). L'offre de cette société était basée sur un masque programme offrant des fonctionnalités de base, quelque soit le composant utilisé et laisse à l'utilisateur final le soin de rajouter les fonctions spécifiques qui lui étaient nécessaires. On avait donc une offre réduite en terme de masque programme mais une adaptabilité très grande. Au delà de la carte COS, Gemplus a également conçu beaucoup d'autres masques programmes dont certains, très spécifiques comme la carte MIMOSA pour le CCETT (France Télécom) implémentant l'algorithme GQ pour Guillou-Quisquater.

Finalement, en 2005, Axalto et Gemplus annonceront la fusion de leurs activités pour créer le leader mondial dans la réalisation de cartes. La société issue de cette fusion sera baptisée Gemalto.

Après avoir repris les activités de production de Bull-CP8, Oberthur SC a racheté les activités cartes de Delarue et a commencé la conception de masques. En 2012, Oberthur était considéré comme un des trois premiers mondiaux dans le domaine de la carte. Cette activité a été revendue par son fondateur à un fond de pension américain en 2011, le fondateur ne conservant que l'activité fiduciaire (fabrication de billets de banque entre-autres).

Sagem a également longtemps été un concepteur de cartes et ce, dès les années 1980. En 2005, Sagem rachètera le fabricant allemand Orga pour devenir Sagem-Orga puis ensuite, Morpho.

En 2012, les principaux fabricants de cartes étaient donc :

A coté de ces poids lourds, il existe une multitude de petites ou moyennes sociétés oeuvrant dans le domaine des cartes de haute sécurité. On pourrait citer EDSI, société basée à Rennes (France) et fondée par Michel Hazard, un des créateurs des premiers masques de Bull-CP8. Michel Hazard ayant souhaité prendre sa retraite, il a vendu sa société à Nagra en 2008. On pourrait également citer Innovatron créée par Roland Moreno qui a produit (elle-même ou une de ses filiales) des masques de cartes.

Les encarteurs

Les encarteurs partent d'un composant déjà masqué (programmé) et l'insèrent dans une carte plastique au format ISO. En pratique, beaucoup des concepteurs de masques cités précédemment (Gemalto, Oberthur, G&D, Morpho) réalisent cette opération. Dans les années 1980, de nombreux encarteurs venaient du monde de l'impression (par exemple, SG2, filiale de la banque Société Générale, mais aussi Oberthur, Delarue, Ruwa Plast (ex Ruwa Bell), etc.) sachant qu'une activité importante dans le monde des cartes consistait déjà à traiter le support (découpage, impression, embossage). Toutefois, au moins au début de la carte, un des principaux problème consistait à se doter de machines capables d'insérer le composant dans le support plastique, en plus, parfois de créer ce que l'on appelle le micro-module, c'est à dire, le composant monté sur ses contacts.

Tous les grands encarteurs que j'ai connus ont créé leurs machines, jusqu'à ce que le marché soit suffisamment développé pour qu'une offre industrielle soit enfin disponible. C'est peut-être ce qui a fait la différence entre ceux étaient en mesure de spécifier et de faire fabriquer (ou fabriquer eux-mêmes) ce genre de machine et les autres qui n'étaient concentrés que sur le processus industriel (typiquement, les imprimeurs).

Les personnalisateurs

La personnalisation électrique d'une CAM (par opposition à la personnalisation graphique) consiste à inscrire les informations indispensables à l'application pour laquelle elle est émise. Ces informations peuvent être l'identité du client, le code porteur, les clés secrètes, etc. En pratique, les encarteurs / imprimeurs cités précédemment et parfois, des SSII (Sligos avec Solaic, Segin...) ont du apprendre à réaliser cette opération de façon industrielle. En 2012, cette activité avait déjà subie une forte concentration et se trouvait regroupée chez les concepteurs de masques.

Toutefois, le métier de l'impression continue à s'intéresser au monde de la carte puisqu'en France, la société « Imprimerie Nationale » est également devenue un personnalisateur.

Au final, depuis les années 2000, c'est la fonction de « personnalisateur » qui désigne les grands industriels de la carte ce qui est assez logique car le personnalisateur est le dernier maillon de la chaîne avant d'arriver chez l'émetteur de la carte (issuer en anglais), c'est à dire, celui qui achète et diffuse le produit à l'utilisateur final..

Le marché de la carte

Les chiffres parlent d'eux-mêmes (source Eurosmart). En 1995, le marché des cartes à microprocesseur représentait environ 60 millions d'unités (environ 9 milliard en 2015) et le marché des cartes en logique câblées représentait environ 300 millions d'unités. le marché français représentait alors la moitié du marché mondial en terme d'émission. C'est en 2000 que le nombre de cartes émis dans le monde est devenu supérieur à celui émis en France.

Nombres en millions d'unités

img

img

img

Légende

Télécom : Cartes SIM cards (éléments sécurisés avec une application SIM).

Paiement et banque : cartes émises par les banques et les enseignes pour des services de paiement (débit, crédit, prépaiement...). Cartes émises par d'autres fournisseurs de service ou enseignes pour la fidélité. Cartes à usage social avec application de paiement.

Gouvernment et santé : cartes émises par des organisations gouvernementales pour l'identification des citoyens (documents de voyage, d'identité, de santé) et les services en ligne opérés par des compagnies d'assurances privées dans le domaine de la santé.

Fabricants d'équipements : Téléphones mobiles, tablettes, outils de navigation et autres objets connectés comportant un élément sécurisé sans application SIM.

Autres : Cartes émises par des opérateurs pour le transport, le stationnement (i.e. transport). Cartes émises par les opérateurs de télévision à péage (i.e. pay-tv). Cartes d'accès physique ou logique.

LA SÉCURITÉ DE LA CARTE

La sécurité de la carte telle qu'elle a été conçue par Bull repose sur son caractère « non-reproductible », ou « non-clonable ». En quelques mots, ayant une carte entre les mains dans un état « émis » (carte dans l'état où elle doit être fournie à son utilisateur légitime), vous (ni personne d'autre) ne pouvez la dupliquer pour faire une carte ayant les mêmes caractéristiques. Eventuellement, l'émetteur de la carte sera en mesure de créer d'autres cartes ayant les mêmes caractéristiques à condition qu'il ait conservé les données qui ont été inscrites dans la carte avant qu'elle passe dans l'état « émis » (c'est vrai pour les cartes bancaires par exemple). Dans certaines applications (signature électronique par exemple), même l'émetteur n'est pas en mesure de créer une nouvelle carte ayant les mêmes caractéristiques que celle qu'il vous a fournie précédemment.

Cet objectif de sécurité ne peut être atteint que si certaines conditions sont réunies :

  1. le dispositif matériel (micro-contrôleur) sur lequel repose la carte est « inviolable » pour reprendre le terme de Bull CP8, ce qui évidemment est une caractéristique non atteignable dans le monde réel. On se contentera plus modestement de demander à ce que le viol d'un composant soit d'une complexité telle qu'en pratique, cela ne vaudra pas la peine d'essayer, sauf s'il y a de très forts enjeux à la clé.
  2. le logiciel de la carte a été conçu pour atteindre cet objectif et fonctionne tel qu'il a été spécifié
  3. la sécurité finale ne dépend que de l'émetteur de la carte et dans certains cas, également de son porteur (cas où le porteur ne peut pas faire entièrement confiance à l'émetteur).

Avant d'aborder chacune de ces conditions et de voir comment on les vérifie, on dispose à la date de rédaction de ce document de suffisamment de recul pour déterminer si les cartes répondent à cet objectif.

Quelques attaques sur les cartes

Beaucoup d'attaques sur les cartes citées par la presse généraliste n'en sont pas. Cette affirmation peut sembler bizarre à certains et mérite une petite illustration en guise d'explication

Attaque sur les Télécartes

La première attaque sur les cartes dont je me souviens a fait la une des magazines dans les années 1980. A cette époque, des étudiants grenoblois s'étaient fait pincer par la police parce qu'ils vendaient de fausses Télécartes qui étaient fonctionnellement acceptées par les publiphone.

La presse française de l'époque avait alors titré sur le fait que les cartes qu'on voulait nous faire croire comme étant sûres ne l'étaient pas (« vous pensez, des étudiants... ») en faisant l'amalgame avec les cartes bancaires que l'on commençait à émettre à titre expérimental en Bretagne.

Pour ceux qui ne savent pas comment fonctionnaient les Télécartes de l'époque, il y a un petit chapitre à ce sujet dans ce cours. Mais en résumé, les Télécartes ne répondaient absolument pas au critère de non-reproductibilité. Il s'agissait d'une simple mémoire de 256 bits en lecture libre, comportant dans une partie non réinscriptible, une information identifiant France-Télécom et pour le reste, un nombre de bits pouvant être écrits, chaque bit correspondant à une taxe téléphonique.

Les étudiants se sont contenter d'émuler ce fonctionnement dans un microcontrôleur avec quelques centaines de lignes d'assembleur (pour l'essentiel, gestion du dialogue carte qui est particulièrement simple dans le cas présent et émulation du fonctionnement de la mémoire qui est encore plus trivial).

Parler d'attaque sur les cartes à ce propos était donc un non-sens puisque la carte ne prétendait à aucune sécurité (à par la protection en écriture de certains bits). Il s'agissait en fait d'une attaque sur le système.

L'affaire Humpich

L'affaire Humpich commence par le « cassage » d'une clé RSA de 320 bits par Humpich. Cette clé était utilisée pour mettre en oeuvre une authentification statique des cartes bancaires. Une fois la clé cassée, il était alors possible de réaliser de vraies-fausses cartes pouvant être utilisées en yes-card (une carte qui répond toujours ok à une présentation d'un code porteur ou PIN). Cette authentification statique était mise en oeuvre de la façon suivante 

Cette mise en oeuvre ne fait nullement intervenir un mécanisme de sécurité de la carte qui se comporte ici comme un simple support de mémorisation. On aurait pu faire de même avec une carte à piste magnétique si celle-ci avait eu la possibilité de mémoriser une quantité de données suffisante.

Une partie de la sécurité du système reposait donc sur le fait que la clé RSA devait être l'état de l'art. Mais déjà, en 1988, Louis Guillou écrivait un article dans « Pour la Science » dans lequel il expliquait que les clés de 320 bits n'assuraient plus la sécurité de la valeur d'authentification des cartes.

En pratique, l'authentification statique des cartes, qui pouvaient convenir pour assurer la sécurité du système à son lancement, n'était plus adaptée dans les années 1990. Il fallait passer à l'authentification dynamique (vérification de la possession par la carte de la clé privée via un challenge) ce qui fut fait quelques années plus tard.

Ce cas est emblématique des confusions qui ont été faites à l'époque sur la sécurité des cartes. La sécurité des cartes bancaires, s'inscrivant dans un système particulier (le système CB) avait bien été compromise, mais sans qu'il y ait une attaque sur les cartes.

Cette affaire a été très médiatisée à l'époque. Il est intéressant de savoir comment elle s'est conclue, ne serait-ce que pour éviter de se retrouver dans une mauvaise situation lorsque l'on est amené à expérimenter dans le domaine des cartes.

Humpich a été condamné pour avoir accédé sans autorisation à un STAD (système de traitement automatisé de données). Cette condamnation a été confirmée par la cour d'appel de Paris en 2000. On trouve un résumé de ce point sur le site Légalis  [archive]

Les publications sous l'égide de Ross Anderson

Ross Anderson de l'université de Cambridge au Royaume Uni s'est fait une spécialité de publier des attaques sur les cartes à puce. Si certaines sont de vraies attaques, dans le sens où elles visent à mettre en défaut des mécanismes de sécurité des cartes en général (par exemple, via des attaques semi-invasives utilisant des lasers ou des impulsions électromagnétiques), beaucoup d'autres, sont liées aux systèmes qui les mettent en oeuvre comme par exemple, celle publiée en 2010. Cette attaque utilise la technique de « l'homme dans le milieu » afin de faire croire à un terminal qu'un PIN a été présenté lors d'une transaction EMV. Cette attaque est rendue possible parce que l'information provenant de la carte et indiquant qu'un PIN correct a été présenté n'était généralement pas utilisé à la date de parution de l'attaque.

A noter au passage que la carte bancaire M4B0 du milieu des années 1980 disposait déjà d'un mécanisme qui permettait de « signer » le fait qu'une transaction s'était déroulée selon un processus normal (avec présentation du PIN en particulier). Inconvénient, seule la banque était en mesure de vérifier le cryptogramme car à l'époque, l'algorithme était un hash-MAC. Mais le point avait été bien vu dès cette époque.

Une attaque sur les cartes bancaires NFC

En avril 2012, un consultant français (Renaud Lifchitz) publie une présentation (Hacking the NFC credit cards for fun and debit) montrant qu'il est possible de récupérer les informations circulant en clair entre une carte bancaire sans contact et un terminal. la presse parle « d'une incroyable faille dans les cartes bancaires » en précisant qu'il s'agit d'une découverte.

Là encore, la sécurité de la carte elle même n'est pas en cause puisqu'à aucun moment, il n'a été prévu une quelconque protection en confidentialité des informations transmises. Il s'agit donc bien d'une caractéristique du système qui par conception transmet les données en clair. Quel impact ? Deux points de vue sont à considérér : celui de la protection de la vie privée et celui de la fraude :

Pour la CNIL (vie privée), certaines informations sont considérées comme personnelles (nom, log des transactions).
Ce problème a été en partie réglé puisqu'en 2012, un rapport de l'OSCP (Observatoire de la Sécurité des Cartes de Paiement) précisait que "le nom du porteur n'est en effet plus accessible lors des échanges en mode sans contact pour la très grande majorité des cartes émises en France. En ce qui concerne l'accès à l'historique des transactions sur les supports sans contact, le système « CB » a pris la décision d'interdire, pour tous les produits désormais présentés à l'agrément, la lecture de ces données par l'interface sans contact".

Pour les banques (fraude), le président du groupement des Cartes Bancaires signalait en avril 2015 l'absence de fraude constatée. Il est vrai que si l'on peut imaginer des scénarios de fraudes, ceux-ci sont quelques peu alambiqués et n'intéressent probablement pas ceux dont l'objectif est « de faire du chiffre ». Par contre, ils continuent visiblement d'intéresser ceux « qui veulent faire du buzz ».

Mais ce qui nous intéresse dans ce paragraphe, c'est la façon dont le sujet a été traité par les médias. De ce point de vue, ont peut être partagé :

Par rapport aux années 2000, on peut se féliciter que la presse a cette fois su faire la distinction entre la sécurité des cartes en général et la sécurité des systèmes qui les mettent en oeuvre.

Par contre, le fait que cette information ait suscité tant de bruits est plus problématique et montre une fois de plus combien la recherche d'un certain « sensationnalisme » se fait au détriment de l'information. Il faut rappeler qu'en 2007 (5 ans avant « la découverte »), l'OSCP (Observatoire de la Sécurité des Cartes de Paiement) publiait dans son rapport annuel « Compte tenu des spécifications actuelles des réseaux internationaux Visa et Mastercard, les nom et prénom du porteur peuvent être transmis en mode sans contact de façon non protégée, ce qui pose un problème de protection de ces données ».

En bref, la présentation du consultant n'avait pas lieu d'être, si ce n'est à titre d'illustration de quelque chose de bien connu.

En guise de première conclusion

Sur la trentaine d'années durant lesquelles des cartes « haute-sécurité » ont été émises, le nombre de cas de cassages avérés de cartes est finalement très faible durant leur période normale d'emploi.

Les plus connues et les plus spectaculaires concernent la télévision à péage : dans ce domaine, le principe même du système fait qu'il est possible d'imaginer un modèle économique rentable qui justifie des moyens lourds pour violer quelques cartes. Cela a donc été fait et la bagarre est permanente entre ceux qui attaquent et ceux qui conçoivent les nouvelles cartes.

Les attaques proviennent parfois d'une erreur de construction (un bug logiciel) découvert plus ou moins par hasard par quelqu'un. Ces cas ont été assez rares en pratique puisque jusqu'à une époque récente, le développement des cartes était assez bien maitrisé par les masqueurs.

Ne demandez pas des fonctionnalités trop complexes à une carte.
La complexité est l'ennemie de la sécurité

La complexité des nouvelles cartes augmentant considérablement, il est possible (probable) que le nombre de bugs va lui aussi augmenter, rendant intéressante la recherche des erreurs de construction qui peut souvent être faite à moindre coût avec simple PC et un lecteur. Si ces cas venaient effectivement à se généraliser, ils mettraient en péril tout un pan de l'industrie.

Il existe aussi des erreurs de construction sur le matériel qui favorisent plus ou moins les possibilités d'attaques. Je connais au moins un cas où une carte a été émise avec un composant comportant un problème de fabrication connu. Il a fallu attendre très peu de temps pour qu'il soit exploité. La leçon que l'on doit en tirer est que si on connait une faiblesse, il ne faut pas trop compter sur le fait de ne pas la divulguer pour empêcher son exploitation. Si les enjeux en valent la peine, elle sera exploitée.

Certains cas d'attaques réussies concernent des cartes qui ont été émises il y a fort longtemps. Les techniques de microélectroniques évoluent, les équipements de conception et de test également, donc les équipements d'attaque aussi... puisque ce sont souvent les mêmes. La sécurité d'une carte ne fait donc que se dégrader dans le temps. Ce qui était très difficile à une époque devient simplement difficile un peu plus tard jusqu'à devenir parfois trivial. Il est certain que les cartes émises dans les années 1980 ne résisteraient pas à des attaques de niveau élementaires en 2015 (voir le chapitre sur l'évaluation des cartes), alors que lorsqu'elles sont émises, toutes les cartes « haute sécurité » visent un niveau de résistance élevé aux attaques. Dit autrement, il ne faut pas compter que les cartes émises à un instant t puissent conserver leur dénomination « haute sécurité » au delà de quelques années.

Le niveau de résistance d'une carte donnée se dégrade avec le temps

La conséquence est que les émetteurs de cartes doivents déterminer une période de validité des cartes en fonction des risques assumés et surveiller le niveau de résistance réelle des cartes sur le terrain.

Une autre règle à connaitre est que les cartes ne sont pas « intrinsèquement » sûres. Certains émetteurs ayant des exigences de sécurité élevées demandent à ce que cette sécurité soit vérifiée à travers des évaluations. Les chapitres qui suivent donnent un aperçu de leur contenu.

Mais là comme ailleurs, il n'y a pas de mystère :si l'émetteur ne formule pas d'exigences particulières en matière de vérification de la sécurité, la résistance des cartes qu'il émettra sera très aléatoire. D'où le nombre régulier de publications portant sur des attaques de cartes réussies et parfois triviales : beaucoup de cartes émises ne peuvent pas être considérées comme visant une « haute-sécurité ».

Une carte n'est pas intrinsèquement sûre. Seule, une évaluation de la sécurité permet d'avoir une idée de sa résistance aux attaques

Enfin et pas que dans ce domaine, il faut conserver un oeil et un esprit critique vis-à-vis des publications, y compris, des publications universitaires : la recherche est devenue depuis longtemps un business comme un autre. Le travail de beaucoup de chercheurs, parfois renommés, est de chercher... des financements pour leurs laboratoires. Et une façon d'en faciliter l'obtention est de publier.

C'est ainsi que dans certains milieux de la sécurité, on parle de « livraison annuelle » de tel ou tel chercheur car là comme ailleurs, il faut bien vivre... Parfois, ces publications révèlent des pépites. Mais souvent, on a à faire à du réchauffé (combien d'articles sont republiés après quelques modifications pour faire du « chiffre » : le nombre de publications est un critère de notation pour les chercheurs). Si on y ajoute les « annonces » de certains en mal de notoriété destinées à créer du buz médiatique, on comprendra que le travail d'explication est nécessaire, même s'il est souvent perdu dans le bruit.

L'évaluation de la sécurité des cartes

La question de l'évaluation de la sécurité des cartes ne s'est pas posée immédiatement ; Le marché s'est d'abord contenté de l'affirmation de Bull concernant « l'inviolabilité » de ses cartes.

Lorsqu’en 1990, certains établissements financiers (Caisse d'Épargne, Caisse des Dépôts et La Poste) ont souhaité lancer leur premier porte-monnaie électronique, l’affirmation des fournisseurs sur la sécurité des cartes est apparue insuffisante face aux risques de création de fausse monnaie.

Ce questionnement était justifié. Jusqu'en 1994, les industriels concernés étaient peu nombreux, et honorablement connus. A partir de 1995 le marché s'est développé à grande vitesse. De multiples projets apparaissaient, la technologie se banalisait, de nouveaux acteurs plus ou moins connus voyaient le jour, le marché devenait mondial.

A partir de ce moment, il n’était plus possible de se baser sur les seules déclarations des fournisseurs pour la sécurité.

C’est en France, que se sont développées les premières évaluations de cartes et de composants en se basant sur des normes d’évaluation internationales reconnues (les critères européens ITSEC dans un premier temps, puis les Critères Communs). La toute première a été réalisée entre 1992 et 1993 par le Centre d’Électronique de l’Armement (CELAR, en 2016, DGA/MI, Ministère de la défense) et le laboratoire d’évaluation sécurité de la société Alliance Qualité Logiciel (AQL). Le CELAR se chargeait d’évaluer le composant électronique, AQL réalisait l’évaluation ITSEC du logiciel de la carte. Les résultats ont été présentés alors au salon Cartes 93.

Mais le véritable booster est arrivé lorsque la Banque de France a demandé au GIE-CB des preuves concernant la sécurité des cartes bancaires.

Le GIE-CB s'est alors tourné vers le SCSSI (devenu depuis l'ANSSI) pour faire évaluer la sécurité des cartes et a inscrit dans son règlement que l'agrément des cartes bancaires (c'est à dire, en pratique, le sésame permettant aux fournisseurs de cartes de vendre aux banques) ne serait donné que si les cartes avaient subi une évaluation selon les Critères Communs certifiée par le SCSSI.

Cette décision a eu plusieurs conséquences :

Elle a permis le développement d'une expertise dans le domaine de la sécurité des composants et des cartes, en France tout d'abord, puis en Allemagne (gros fournisseur de composants pour les applications bancaires) et en Hollande. La reconnaissance de cette expertise a largement dépassé le cadre européen.

Elle a poussée vers le haut le niveau de sécurité des aux autres applications (signature électronique, identité, passeport, etc.) à l’exception notable (du fait du volume de cartes émises) des cartes SIM pour lesquels les enjeux ne nécessitait pas de tels niveau de sécurité. A noter cependant qu'à partir de 2009, en France, cette situation a évolué puisque certaines cartes SIM ont été certifiées au même niveau que les cartes bancaires lorsqu’elles ont commencé à intégrer une application bancaire.

La certification sécuritaire est devenue un sésame pour l'export en dehors de l'Europe, certains pays non européen demandant explicitement des cartes certifiées en Europe.

EMVco, l’organisation qui maintien les standards pour les cartes de paiement, a imposé une évaluation inspirée de celle qui a été proposée en France pour les cartes bancaires. Le résultat paradoxal est qu’en 2015, les cartes françaises continuaient à être évaluées selon la norme internationale des Critères Communs et certifiées par l’ANSSI « par exception » tandis que le reste du monde utilisait des cartes évaluées selon les standards EMVco (il faut le reconnaitre, avec un niveau de confiance moindre cependant).

Quelques mots sur les évaluations et les certifications sécurité de produits

L'évaluation de la sécurité d'un produit consiste à vérifier que ce produit est conforme à un référentiel d'exigences. Cette évaluation est réalisée par un laboratoire d'évaluation. Celui-ci peut lui-même être conforme à une norme internationales (typiquement, ISO17025) qui garantie en particulier 

La conformité à cette norme fait l'objet d'une accréditation par un organisme autorisé, en France le COFRAC.

A noter que ces principes sont applicables à quasiment tous les domaines sauf... à la sécurité, ou du moins, la partie intéressante d'une évaluation sécuritaire, à savoir, l'analyse de la vulnérabilité des produits (recherche des failles de sécruité).

En effet, cette analyse fait en effet intervenir une part d'expertise qu'il n'est pas possible de cadrer entièrement du fait de sa subjectivité, sauf à faire perdre tout intérêt à l'évaluation.

C'est pourquoi, afin d'offrir un certain niveau de garantie concernant ce point, il est nécessaire qu'un acteur soit présent dans le processus pour s'assurer que les analyses faites par les laboratoires d'évaluation sont bien au niveau de l'état de l'art.

Dans la plupart des pays, ce sont des agences gouvernementales qui assument généralement cette fonction. En France, il s'agit de l'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI). Ces agences sont également les centres de certifications et les certificats délivrés permettent d'avoir l'assurance que :

Pourquoi pas le secteur privé ? Théoriquement, rien ne s'y oppose. Mais jusqu'en 2016, il n'était généralement pas possible pour le secteur privé de rentabiliser ce type de certification. Les centres de certifications auraient du maintenir un pool d'experts dont le coût se serait forcément répercuté sur le coût de la certification rendant celle-ci insupportable pour les industriels.

Même un organisme comme EMVco qui « approuve » (notez le terme retenu, on ne parle pas de certification) les composants pour le domaine bancaire sous l'angle de la sécurité s'appuie en pratique sur des laboratoires d'évaluation dont les compétences sont vérifiées par d'autres qu'eux (du moins en Europe où les exigences sécurité sont plus élevées que sur d'autres continents).

Mais cette approche n'est pas partagée par tous. Ainsi, aux États-Unis, l'aspect subjectif de l'analyse de vulnérabilité est contesté. Et c’est ainsi que dans le domaine de l’évaluation logiciel, l’approche proposée (imposée) par les États-Unis est une analyse de vulnérabilité complètement objective basée sur une liste de vulnérabilités connues. Cette approche, si elle est parfaitement compatible avec les règles régissant les laboratoires d’évaluation, ne convainc pas les experts en sécurité.

Critères d'évaluation utilisés

Dans le domaine des cartes, les Critères Communs (CC) sont utilisés depuis les années 2000 en remplacement des critères européens ITSEC. L'évaluation des cartes et des composants est d'ailleurs un des rares domaines où ces critères ont eu un réel succès.

Il serait fastidieux d'entrer dans les détails des CC dans ce cours. Je me contenterai de décrire les quelques éléments que le lecteur doit avoir en tête :

Une des raisons de ce succès vient sans doute du fait que dès les années 2000, le monde de la sécurité des cartes (industriels, laboratoires, agences gouvernementales, grands utilisateurs) a accepté de travailler en commun sur les attaques au sein d'un groupe de travail, le JHAS (Joint Interpretation Library - Hardware Attack Subgroup). Les résultats de ce groupe de travail ont servi de référence pour tous les laboratoires européens réalisant des évaluations CC et par la suite, EMVco.

Les document produits par le JHAS ne sont pas publics. Par contre, le document public Application of Attack Potential to Smartcards donne quelques idées sur les moyens employés par les laboratoires pour évaluer les composants et les cartes. Pour plus de précisions, voir le chapitre Sécurité du composant matériel.

Particularités de la sécurité des cartes

Les travaux sur l'évaluation de la sécurité des produits selon des critères normalisés et ouverts ont démarré en France dans les années 1990. Assez rapidement, il est apparu que les cartes présentaient des particularités qui ont été théorisées et explicitées dans des documents parus sous l’égide du SOGIS et qui ont ensuite été repris au niveau international via le CCRA.

Pour les lecteurs pressés, voici un résumé de ces particularités :

img

En guise de première conclusion

Même si depuis que les cartes bancaires existent et ont popularisé le concept, peu de personnes, y compris chez les experts en sécurité, connaissent et comprennent les particularités de cet objet du point de vue de la sécurité.

Les rares attaques publiées concernent des cartes pour lesquelles il n'y a pas eu d'effort particulier du point de vue de la sécurité.

Par ailleurs, il y a souvent confusion entre les attaques portant sur les cartes et celles portant sur le système : ce n'est pas parce qu'une carte résiste à des hauts niveaux d'attaque qu'elle est correctement utilisée ou pire, paramétrée par les émetteurs. Les exemples d'attaques qui n'en sont pas au début de ce chapitre illustrent ce point.

Enfin, pour les quelques experts qui s'intéressent au sujet, la carte représente un défi intéressant et des techniques d'attaques de très haut niveau font donc l'objet de publications dans différente conférences. Mais souvent, celles-ci portent sur des cartes anciennes ou qui ne sont pas réellement de « haute-sécurité ».

Et de fait, les cartes « haute-sécurité » représentent une partie assez faible du marché. Pour faire simple, ce sont généralement :

L'immense majorité des cartes (cartes SIM, cartes pour le transport par exemple) ne méritent pas le qualificatif de « haute-sécurité ». Parfois pour de bonnes raisons : l'environnement d'utilisation ou les enjeux ne nécessitent pas de faire des efforts particuliers vis-a-vis de la sécurité ; parfois pour de mauvaises raisons, l'ignorance n'étant pas la moindre.

Sécurité du composant matériel

Pour les cartes « haute-sécurité », l'objectif des fondeurs (ou plus justement des concepteurs de composant puisqu'il faut également considérer les fabless, c'est à dire, des concepteurs de composants ne disposant pas de fonderies) est de proposer un composant qui offre un maximum de contre-mesures par rapport aux attaques connues et si possible, qui permettent au développeur de masque de s'affranchir des préoccupations liées aux attaques sur le matériel pour ne se consacrer qu'aux fonctionnalités. Même si l'on « tend vers », cet objectif n'est toujours pas atteint en 2016. Néanmoins, les fondeurs améliorent leur produits en permanence et les avancées faites depuis les années 2000 ont été considérables, il faut bien le dire, en grande partie grâce aux exigences sécurité du marché bancaire français (ce qui est encore une fois paradoxalement peu connu en France).

De nombreuses publications font une liste des attaques habituelles sur les composants. Cette liste est également présente à un niveau de généricité assez élevé dans le document Application of Attack Potential to Smartcards. Il présente l'intérêt de servir de base pour la cotation des attaques dans les évaluations sécuritaires de cartes, évaluations pratiquées dans plusieurs pays européens et quelques pays d'Asie.

L'objectif d'une évaluation sécuritaire d'un composant est donc de vérifier s'il est possible de récupérer des secrets que ledit composant est censé protéger ou de modifier l'intégrité d'une donnée sensible (par exemple, un compteur). La difficulté de cette évaluation est que le composant est générique et qu'il ne sait pas encore pour quelle application il sera utilisé. Il est donc soumis à toutes sortes de tests en espérant qu'ils couvrent bien tous les cas d'usages potentiels.

Ces tests couvrent les attaques non invasives telles que récupération d'informations par analyse de la consommation ou du rayonnement électromagnétique ou par perturbation électrique ou lumineuse ainsi que les attaques invasives pouvant aller jusqu'à la modification du composant via un FIB.

A titre d'exemple, voici la liste non exhaustive des équipements prévus dans le document Application of Attack Potential to Smartcards. Ces équipements entrent dans la cotation des attaques aux cotés d'autres critères.

Type d'équipement

Cotation

Usage

Exemple (photos internet)

Emission de lumière ultra-violette

Standard

Effacer des mémoires

 

Lumière flash

Standard

Perturber le fonctionnement

 

Microscope classique en lumière visible

Standard

Observer le circuit

img

Etuves

Standard

Pour éprouver le composant en température et humidité

img

Alimentation

Standard

Comportement du composant en fonction de l'alimentation

img

Oscilloscope analogique

Standard

Observation, mesure

img

Lecteur de carte ou de composant

Standard

Pour utiliser le composant

img

Logiciel d'analyse de signal

Standard

Pour exploiter des mesures

 

Logiciel de génération de signaux

Standard

Pour modifier le comportement du composant

img

Microsope et caméra classiques haut de gamme en lumière visible

Spécialisé

Pour faire mieux qu'avec le microscope classique

 

Microsope et caméra classiques haut de gamme en lumière UV

Spécialisé

 

img

Station de micro-probing

Spécialisé

Mesure/capture de signaux

img

Equipement laser

Spécialisé

Perturber le composant

img

Processeur de traitement du signal

Spécialisé

Pour exploiter les mesures

 

Oscillsocope numérique haut de gamme

Spécialisé

Pour faire mieux qu'avec un simple oscilloscope numérique ou analogique

img

Analyseur de signaux

Spécialisé

 

 

Chimie et outillage

Spécialisé

Pour attaquer les matériaux du composant

 

Plasma

Spécialisé

Pour attaquer les matériaux du composant

img

Outils de ponçage

Spécialisé

Pour attaquer les matériaux du composant

img

Microscope électronique à balayage

Sur mesure

Pour analyser le composant en fonctionnement ou à l'arrêt

img

Faisceau électronique testeur

Sur mesure

 

 

Microscope à force atomique

Sur mesure

 

img

Faisceau d'ions focalisé (FIB)

Sur mesure

 

img

Outils récents de conception et d'analyse de défaillance

Sur mesure

 

 

On l'aura compris, un équipement standard est celui que l'on peut se procurer pour un coût raisonnable un peu partout (magasin, e-bay...), un équipement spécialisé est en général un équipement assez coûteux (quelques dizaine de millier d'euros) que l'on va trouver dans des laboratoires bien équipés. Quant aux équipements dits « sur mesure » (bespoke), il s'agit d'appareils d'accès difficile qui nécessiteront parfois une adaptation pour être utilisés dans le domaine de l'attaque ou des appareils qui auront été spécialement conçus par les laboratoires d'évaluation et que l'on ne trouve pas dans le commerce.

Face à cela, les fabricants rivalisent d'ingéniosité pour tenter de déjouer les attaques réalisables à l'aide des équipements cités ou au moins, les rendre d'un coût prohibitif par rapport au gain escompté. Chaque fabricant a ses secrets de fabrication et il n'est pas question ici de les dévoiler. On peut néanmoins citer quelques exemples connus de contre-mesures dont certaines étaient d'ailleurs parues dans un petit périodique, « le masque et la puce » concocté à l'époque par Louis Guillou du CCETT.

Certaines contre-mesures sont « actives », c'est à dire, ne peuvent fonctionner que lorsque le composant est alimenté. D'autres sont « passives » et permettent de contrer certaines attaques invasives alors que le composant est éteint. A noter également que l'évolution des technologies rend plus délicates certaines attaques : circuits multi-couches qui va créé le phénomène de « glue logique » rendant le circuit plus complexe à analyser, les technologies de plus en plus fine (80nm ou moins) rendant certaines intrusions plus complexes, les consommations de plus en plus faibles rendant les mesures plus complexes, etc. Néanmoins, jusqu'à présent, les laboratoires d'analyses et les attaquants ont toujours su s'adapter à ces évolutions. L'image ci-après donne une idée du contenu d'un micro-contrôleur pour carte à puce.

img

Sécurité du logiciel

En pratique, même si le composants sécurisés reçoivent les plus haut niveaux de certification sécuritaires (EAL4+AVA.VAN.5, le point important est AVA.VAN.5), ils ne peuvent pas se protéger contre toutes les attaques sans que le logiciel qu'ils embarquent n'aient été conçu pour. Là aussi, les techniques de sécurisation font parties du savoir faire de quelques sociétés et sont conservées confidentielles.

La conséquence de ce qui vient d'être exposé est qu'il est illusoire de prendre un composant même certifié, de le programmer n'importe comment et d'espérer qu'il résistera aux attaques. C'est la raison pour laquelle les composants masqués subissent également une évaluation sécuritaire et qu'en pratique, une carte à puce (ou d'ailleurs, n'importe quel composant masqué) subit une évaluation sécuritaire pour obtenir à son tour le niveau AVA.VAN.5. Ce mécanisme d'évaluation dit, « en composition » a été théorisé et mis en pratique dans les évaluations ITSEC ou Critères Communs réalisées en Europe et est décrit dans le document « Composite product evaluation for Smart Cards and similar devices » disponible sur le site de l'accord européen SOGIS concernant les reconnaissances des évaluations sécuritaires (ou sur celui du CCRA mais en général, avec une version de retard).

En résumé, les fonctionnalités de la carte ne peuvent être sûres que si le concepteur du logiciel a pris soin de programmer sa carte pour qu'avec l'aide du composant, elles puissent globalement résister aux attaques précédemment décrites

La suite est plus classique. Les fonctionnalités de la plupart des cartes se déclinent de la façon suivante

Le risque spécifique associé à la sécurité du logiciel et qui commence à être bien connu y compris du grand public provient de la difficulté que l'on a à développer des logiciels complexes sans bugs. Or, certains bugs peuvent avoir un impact sur la sécurité.

Les premières cartes étaient suffisamment simples pour que l'on puisse analyser le logiciel en profondeur et limiter ce risque. Avec le temps, les logiciels sont devenus de plus en plus complexes et ce type d'analyse a atteint ses limites. Une façon de le circonscrire serait d'utiliser plus massivement des méthodes de développement sûres, comme les méthodes formelles. Une société comme Gemalto (et avant, Schlumberger) a réalisé des cartes en partie développées suivant de telles méthodes mais sans aller jusqu'au bout de la démarche.

Ce qui est certain et cela a déjà été évoqué au début de ce document, c'est que le futur enjeu de la sécurité des cartes concernera la maîtrise du développement logiciel ce qui n'est pas gagné. Vouloir mettre un serveur Web dans les cartes à puces comme le proposent certains serait sûrement le meilleur moyen à terme de porter atteinte à la confiance que l'on peut avoir dans ce produit et dans l'industrie associée.

Sécurité des communications

Les différents modes de communication (contact, sans contact) peuvent être utilisés pour tenter de compromettre les biens de la carte. Si un risque de ce type existe, il est indispensable de sécuriser les communications, en les chiffrant si on veut préserver leur confidentialité et/ou en les signant si l'on veut compromettre l'intégrité. Dans certains cas, il peut également être nécessaire d'assurer la disponibilité du canal de communication.

Pendant longtemps, on a considéré comme faible le risque d'attaques sur les communications via les contacts. Ainsi, les PIN des cartes étaient présentés en clair entre le lecteur et la carte. C'est encore souvent le cas mais de plus en plus, certaines applications considèrent que ce risque doit être pris en compte et qu'il faut mettre en place des contre-mesures. C'est le cas, par exemple, pour les cartes bancaires où il est prévu que le PIN puisse être présenté chiffré ou encore, que l'intégrité des informations retournées par la carte vers le lecteur doit être assuré (mode CDA en EMV par exemple).

Toutefois, en mode contact, la plupart des attaques nécessitent une intervention sur les lecteurs ou des aménagements sur les cartes elles-mêmes ce qui limite souvent leurs rentabilités ou leurs généralisations.

Les attaques applicables au mode contact sont généralement applicables au mode sans contact mais avec parfois un mode opératoire simplifié ou une plus grande discrétion. De plus, il existe des attaques que l'on peut considérer comme spécifiques au mode sans contact et qu'il est bon de rappeler, ainsi que leurs limites.

L'écoute passive (eavesdropping)

A partir du moment où l'on communique en « sans fil » ou sans contact, il est possible, par nature, d'écouter cette communication à distance si l'on est capable de récupérer suffisamment d'énergie. L'écoute passive consiste à utiliser une antenne adaptée et à tenter de récupérer un signal qui une fois amplifié et démodulé permet de récupérer les données communiquées entre un lecteur et une carte. La base de ces techniques sont issues de la TSF, c'est-à-dire, de la fin du 19ème siècle ce qui ne nous rajeunit pas…

Jusqu'à quelle distance peut-on écouter ces communications ?

Selon une publication de Giesecke & Devrient de 2009, les communications (ISO14443) entre une carte et un lecteur peuvent être écoutées jusqu'à 3m dans un environnement bruité et 9m dans un environnement non bruité. Les communications entre un lecteur et une carte pourrait être théoriquement écoutées jusqu'à une distance de 100m.

L'activation (skimming)

L'activation consiste à activer une carte sans contact à l'insu du porteur afin de récupérer des informations (skimming), voire, pour les cartes bancaires, réaliser des transactions de paiement.

Une publication de Ziv Kfir and Avishai Wool de 2005 donne quelques indications sur la facilité (ou la difficulté) pour réaliser une telle activation en laboratoire (la carte est correctement positionnée en champ libre, on est en mesure d'avoir des antennes de taille adaptée avec l'alimentation qui convient).

Ces valeurs étaient considérées comme toujours valides en 2015. On trouve une publication très complète de Ilan Kirschenbaum et Avishai Wool (université de Tel Aviv) « How to build a low cost, extended-range RFID skimmer, février 2006 » montrant comment réaliser un montage permettant de se mettre dans le deuxième cas (jusqu'à 40cm, en l'occurrence, 25cm).

Les contremesures possibles sont le blindage de la carte et/ou un mécanisme d'activation. Cette dernière contre-mesure n'était pas disponible sur les cartes en 2015. Par contre, elle est généralement mise en œuvre dans le cas des paiements par smartphones (exemple, Apple Pay).

Le brouillage (jamming)

L'objectif est ici de rendre indisponible la carte en brouillant l'environnement électromagnétique afin de perturber les communications.

Ces attaques sont théoriquement possibles mais nécessitent des équipements peu discrets, en particulier, si l'équipement ne peut être placé à proximité (moins d'un mètre) de l'endroit à brouiller. Par ailleurs, cette attaque est assez rapidement identifiable.

Les attaques en relai (relay attacks)

Considérons la situation suivante : vous utilisez un émulateur de carte sans contact pour réaliser des paiements. Cet émulateur est relié à un dispositif de communication en liaison avec celui d'un complice. Ce complice dispose quant à lui d'un matériel d'activation (voir paragraphes précédents). Ce matériel d'activation est utilisé pour activer la carte sans contact d'une victime situé a proximité. Ainsi, lorsque vous payez, c'est en fait la carte de la victime qui réalise la transaction.

Les mêmes remarques et contre-mesures que celle faites pour l'attaque en activation s'appliquent ici à part que l'attaquant n'a pas besoin d'être un commerçant.

On notera au passage que cette technique d'attaque est encore plus facile à réaliser si vous considérez les paiements par smartphones :

QUELQUES APPLICATIONS DE LA CARTE

Choix d'une carte

Quelle carte choisir pour quelle application ? Faut-il développer une carte spécifique ou tenter d'utiliser une carte généraliste déjà largement émise ?

Les cartes généralistes

Les cartes généralistes visent un large marché et disposent pour ce faire de possibilités variées, que ce soit en terme de gestion mémoire, de cryptographie et de fonctionnalités. Ces cartes ont été les premières à être proposées lorsque le marché était naissant.

On a pu leur reprocher d'être mal adaptées à des besoins spécifiques (par définition) et d'être liées à un industriel donné (au début, Bull-CP8, puis Philips-TRT, Schlumberger et Gemplus) ce qui n'est pas sécurisant pour les émetteurs.

Parmi les « masques » les plus connus de l'époque, on peut citer les D1, et D2 (Philips-TRT), les M4, M9, MP, (Bull-CP8), la TB100 du consortium TRT et Bull (qui présentait donc l'avantage d'avoir deux sources), la M64 de Schlumberger, la famille COS de Gemplus...

La carte M4 reste la plus emblématique de cette catégorie. Elle a été utilisée comme carte bancaire, carte de téléphone « France Télécom » (carte Pastel), carte porte-monnaie électronique, carte de contrôle d'accès, etc. Certaines applications déployées en 2012 utilisaient toujours les descendantes de la carte M4. C'est le cas de la carte d'assurance maladie française « Vitale 1 » qui s'appuyait toujours en 2012 sur les spécifications de la carte M9, elles mêmes très proches de la M4.

Après un passage à vide, cette catégorie de carte est revenue sur le devant de la scène avec la spécification IAS proposée par le GIXEL (devenu ACSIEL en 2013) au début des années 2000.

L'intérêt de cette spécification est qu'elle est proposée par les principaux masqueurs du marché ce qui évite aux émetteurs d'être liés à un seul fournisseur.

Les cartes « applicatives »

Les cartes applicatives sont maîtrisées par les émetteurs ou leurs représentants. Parfois, il s'agit de cartes proposées par des fournisseurs (masqueurs) mais sur la base de spécifications ouvertes et libres de droits.

Certains émetteurs ont ressenti le besoin de disposer de leurs propres cartes plutôt que d'utiliser les modèles généralistes proposés par les fabricants. On peut y voir plusieurs raisons :

Les raisons fonctionnelles : certaines fonctionnalités sont trop complexes à implémenter avec des cartes généralistes ou trop spécifiques. On peut citer l'exemple du porte-monnaie électronique pour lequel la gestion du solde peut se faire simplement avec quelques fonctions dédiées alors qu'elle nécessite des acrobaties du coté applicatif lorsque l'on utilise des cartes généralistes.

Il y a parfois des raisons de performances. Ainsi, la carte de transport Navigo (Transports parisiens) nécessite des temps de réponse très courts tout en visant une sécurité « suffisante » ce qui nécessite un développement très spécifique (à moins de prendre du Mifare de Philips mais on a vu les résultats coté sécurité...).

Une raison de sécurité d'approvisionnement : les banques françaises ont été les premières confrontées au problème. En 1986, elles dépendaient à la fois d'un seul fournisseur pour le masque (Bull-CP8) et d'un seul fournisseur pour le composant (Motorola). L'accord trouvé entre Bull-CP8 et TRT a permis dans un premier temps de proposer une seconde source. Ainsi, la carte M4 a été également émise par TRT-Bull sous deux références, une reposant sur un composant Motorola à base de 6805, l'autre sur un composant ST à base de 8048. Mais les banques restaient tributaires d'un accord qu'elles ne maitrisaient qu'incomplètement. C'est une des raisons qui ont vue l'apparition du masque bancaire M4B0 devenu B4B0', très proche du M4 mais propriété des banques. Ce masque a évolué et a été produit jusqu'en 2007 par tous les fabricants importants de l'époque.

Une raison de sécurité applicative : certaines cartes doivent résister à des niveaux d'attaquant très élevés. C'est particulièrement le cas des cartes de télévision à péage. C'est d'ailleurs dans ce domaine que sont apparues les premières cartes « applicatives » que je connaisse, avec les PC0, PC1 et les différentes versions de la PC2 (encore utilisée en 2012). Ce besoin particulier peu nécessiter des développements très spécifiques que les émetteurs ne sont pas prêts à partager avec d'autres.

Les cartes applicatives se sont fortement développées dans les années 1990-2010 pour donner les « masques » EMV (carte bancaire Europay, Mastercard, VISA), SIM, B4B0 (carte bancaire française ayant remplacée la carte M4), Monéo (porte-monnaie électronique), OACI/ICAO pour le passeport, VITALE2 pour la santé, CPS pour les professionnels de santé, etc.

Ces cartes applicatives ne peuvent être conçues que dans un contexte où l'on est certain de disposer d'un marché suffisant pour amortir leur coût de réalisation.

Le juste milieu entre carte applicative et carte généraliste consiste probablement à créer des cartes généralistes intégrant certaines fonctions applicatives parmi les plus utilisées et de permettre l'ajout de certaines fonctionnalités lorsque le besoin s'en fait sentir. De ce point de vue, des masques basés sur des couches d'interprétation « ouvertes » de type JavaCard ou Multos sur des plateformes matérielles disposant de mémoire flash apporte la souplesse nécessaire pour répondre à ce besoin au prix néanmoins, d'une complexité croissante ce qui peut poser des problèmes de sécurité.

Les acteurs d'un projet carte

Encore du vocabulaire diront certains. Mais derrière le vocabulaire se cachent des concepts et c'est en ignorant ces concepts que beaucoup de projets « cartes » ont échoué au cours du temps. Ce phénomène n'est d'ailleurs pas propre à ce domaine.

En général, dans un projet « carte », on distingue :

Par ailleurs, une carte peut-être :

Les quelques exemples qui suivent permettent d'illustrer ces concepts :

Pour ceux qui trouveraient vain cette catégorisation, disons tout de suite qu'un grand nombre de projets initiés dans les années 1990 ont échoué par ignorance des conséquences qu'entraîne chacun de ces concepts. Pour illustrer le propos, revenons sur la carte bancaire des années 1986

Dans ces années, il était possible d'acheter des jetons de téléphones qui étaient stockés dans la carte bancaire. C'est la raison pour laquelle était identifié le prestataire « France-Télécom ». En effet, ce dernier voulait disposer d'un certain contrôle sur l'inscription de ces jetons dans la carte et disposait donc d'un secret (la clé 1B, voir le chapitre sur la carte M4 pour plus de précisions) pour valider l'inscription de ces jetons et (théoriquement), authentifier la « zone porte-jetons » d'une carte lorsque celle-ci était utilisée dans un publiphone. Or, les cartes bancaires étaient émises par les banques qui en gardaient la propriété. Pour autant, il ne fallait pas que les banques puissent être accusées de frauder France-Télécom en ayant la possibilité d'inscrire elles-mêmes des zones « porte-jetons ». Une première difficulté organisationnelle consistait donc à cloisonner les secrets de France-Télécom vis-à-vis des banques et ceci, depuis la fabrication jusqu'à la fin de vie de la carte. Ce n'est déjà pas simple mais ce n'est pas le pire.

Les cartes bancaires avaient une durée de validité. En fin de vie, la politique de sécurité de l'époque précisait qu'elles devaient (théoriquement) être remise à la banque émettrice pour destruction. Les zones « porte-jetons » de France-Télécom n'avaient pas de fin de validité. Comment gérer cette contradiction ? Facile, il suffisait que la banque rembourse les jetons non consommés au porteur et se fasse ensuite rembourser par France-Télécom. Ceci pose deux problèmes :

Enfin, il restait un dernier problème propre à la technologie de l'époque : les mémoires des cartes d'alors étaient des EPROM non effaçables électriquement. A chaque fois qu'un porteur achetait jetons de téléphones destinés à être inscrits dans sa carte bancaire, il consommait de la mémoire qui n'était plus disponible pour les services bancaires. Le risque était alors de saturer la carte à cause du service de téléphonie. Or, en cas de saturation d'une carte (peu importe la raison), les banques devaient fournir une nouvelle carte au porteur sans que celui-ci ait à payer pour cela (le porteur n'achète pas une carte bancaire mais l'accès à un service de paiement par carte : la carte n'est que le moyen d'accès à ce service).

Bref, on l'aura compris, la vie commune dans une même carte n'était pas qu'une partie de bonheur. Les problèmes de propriété du support, de gestion de la vie de la carte entre plusieurs prestataires, de politiques de sécurité incompatibles, etc, ont fait que cette tentative d'émission d'une carte multi-prestataires n'a pas survécu très longtemps.

Malheureusement, cette leçon n'a pas été bien comprise ni même bien identifiée à l'époque (et même parfois, jusque dans les années 2010). Plusieur projets de cartes multi-services qui ont été imaginés et pour lesquels il y a eu parfois des investissements (ne serait-ce qu'en étude) ont finis par échouer parce que l'on n'avait pas identifié que derrières certains services se cachaient des prestataires différents ayant des objectifs différents. Le cas le plus comique que j'ai connu au milieu des années 1980 est un projet qui avait bien identifié que la carte devrait être multi-prestataires (c'est normal, j'étais alors payé pour spécifier ce projet) mais au final, les prestataires ne purent se mettre d'accord sur la position de leurs logos sur le support plastique (chartes graphiques incompatibles) !.

On mesurera encore la difficulté associée au lancement de cartes multi-prestataires en observant le projet d'offre de service lancé par les opérateurs de téléphonie mobile au milieu des années 2000 pour valoriser les cartes USIM des téléphones. L'offre de service est d'héberger toutes sortes de services comme le paiement, la signature électronique, la gestion d'identité sur le support de la carte SIM tout en garantissant le cloisonnement entre tous les prestataires, y compris l'émetteur (l'opérateur de téléphonie).

Plusieurs années de discussions et spécifications ont été nécessaires pour arriver à un accord entre les différentes parties (en particulier, entre les opérateurs de téléphonie mobile et les banques) avant que les premiers projets aboutissent (2013).

Au moins, dans ce cas, le problème des logos n'est plus le point bloquant

En conclusion, si vous devez lancer (ou analyser) un projet mettant en oeuvre des cartes ou plus généralement, des éléments sécurisés, identifiez bien l'ensemble des points évoqués précédemment et récapitulés ci-après :

Et j'en ai probablement oublié.

Les applications monétiques de la CAM

Généralités, concepts

C'est la monétique qui a initialement permis au marché de la CAM de se développer. Ce développement a démarré en France avec la Télécarte et la carte bancaire.

Les utilisations classiques de la CAM dans ce domaine sont les suivantes :

Les architectures monétiques mettant en oeuvre ces différentes utilisations peuvent être centralisées ou réparties, en ligne ou hors ligne.

Les quelques exemples qui suivent illustrent ces concepts :

Que penser de la carte PASTEL de France-Télécom qui a fonctionné dans les années 1980 jusqu'aux années 2000 ? Pour rappel :

Ce cas curieux mais pas unique était donc une carte de paiement a usage dédié en postpaiement utilisée en mode en ligne dans une architecture centralisée.

Cette catégorisation permet d'intuiter une règle sur ce que l'on doit attendre d'une CAM dans ces applications : les cas les plus défavorables à la sécurité (ceux qui peuvent générer le plus de fraudes) sont les paiements utilisant une « monnaie électronique » non dédiée, en mode hors ligne dans des architectures décentralisées. C'est dans ce ou ces cas que l'apport de la CAM devient décisif pour limiter la fraude.

Est-ce à dire qu'avec la connectivité croissante à faible coût qui se développe depuis le milieu des années 1990, l'intérêt de la CAM pourrait diminuer ?

Si nous considérons le cas des portefeuilles électroniques proposés par certaines plateformes de vente sur Internet (Amazon, FNAC...) sont des « porte-monnaie » électroniques (ce qui n'est pas le cas car ces plateformes n'ont pas le statut requis pour émettre et gérer de la monnaie électronique), on serait ici face à une architecture centralisée en mode en ligne mémorisant une « reconnaissance de dette » (prépaiement) à usage non dédié. Pour déclencher une opération de paiement, on peut envisager l'utilisation d'un authentifiant (mot de passe) avec blocage du compte après quelques tentatives de présentations erronées. Le niveau de sécurité pour l'authentification est proche de celui que l'on peut avoir avec une CAM surtout si l'on prend soin de chiffrer la communication entre le terminal d'entrée de l'authentifiant (ordinateur personnel, ordiphone) et le serveur ce qui est normalement le cas. Toutefois, la situation n'est pas aussi rose : tout d'abord, il faut s'assurer que le terminal d'entrée est sain ce qui est loin d'être trivial. Sinon, on prend le risque de se faire voler son authentifiant.

Mais surtout, les serveurs mémorisant les portes-monnaie deviennent des cibles très attrayantes pour les attaquants de tout poil. Et les attaques sur des systèmes centralisés ont généralement des effets systémiques (voir les conséquences des attaques concernant les services Play Station Network et Qriocity. chez Sony en 2011 ou les attaques ayant visé des chaines de télévision et des banques en 2013 en Corée du sud).

Au début des années 2010, certains prévoyaient la fin des cartes bancaires physiques au profit des portes-feuilles électroniques stockés dans l'Internet. Gageons (2013) que dans quelques temps, on redécouvrira les vertus d'une certaines décentralisation de la sécurité à travers des éléments sécurisés. Il ne s'agira peut-être plus de cartes au sens habituel du terme mais ils devraient continuer à être présent sous une forme ou une autre dans nos équipements informatiques.

Zoom sur les applications monétiques en prépaiement

Ce chapitre est un résidu de ce que j'avais écris en 1989 sur les applications monétiques de la CAM. Il me semble être toujours d'actualité même si certains exemples ont peut-être vieilli.

Architecture centralisée

Il existe un organisme financier (qui peut être le commerçant lui-même) drainant le montant des prépaiements. Lors de l'achat d'une prestation chez un commerçant, la carte est utilisée comme moyen d'identification et d'accès à l'organisme financier pour vérifier qu'il existe un compte chargé d'un montant suffisant pour le paiement de la prestation. S'il existe, il est alors débité du montant correspondant.

Cette technique est généralement utilisée dans des environnements limités mono-prestataire. Citons par exemple le paiement dans un restaurant d'entreprise ou dans un organisme de vente par correspondance... Sa principale caractéristique est de nécessiter l'utilisation de terminaux de paiements en lignes directement raccordés au serveur monétique qui mémorise les comptes des clients.

La montée en puissance du paiement sur Internet et l'interconnexion globale entre acheteurs et commerçants a (re)donné une jeunesse à cette approche qui n'était pas très utilisée lorsque les communications longue distance étaient coûteuses. On peut considérer par exemple que Paypal et ses concurrents entrent dans cette catégorie.

Architecture répartie

Dans ce cas, la carte contient la preuve qu'un prépaiement a effectivement eu lieu et c'est elle qui est débitée du montant de la prestation achetée. Alors que dans les autres techniques, la carte se comportait obligatoirement comme un système d'identification, elle peut ici être complètement anonyme. La Télécarte de France Télécom en est un bon exemple.

Cette technique peut s'avérer extrêmement simple à gérer dans un environnement mono-service. En effet, dans ce cas, une fois l'argent du prépaiement encaissé, il n'est plus nécessaire de suivre les opérations effectuées avec le support de paiement. En multi-services, il peut être nécessaire de réintroduire un système monétique capable de faire la compensation entre les différents services utilisateurs de la carte si ceux-ci sont financièrement indépendants. C'est le cas en particulier pour des portes-monnaie électronique comme Monéo

Différentes techniques en prépaiement

Ce paragraphe traite des différentes façons d'enregistrer la preuve d'un prépaiement dans une CAM et la façon de la débiter. On aura compris qu'il s'agit donc de techniques utilisées dans le cas du prépaiement non centralisé.

Les portes-jetons

Lorsque l'on achète un carnet de tickets de métro (ou un carnet de timbres), on a échangé une certaine somme d'argent monétaire en une somme d'argent correspondant au coût d'une prestation unitaire pour un service donné (les transports urbains ou la poste par exemple). Au fur et à mesure que l'on utilise ces services, on utilise un ou plusieurs de ces tickets qui vont être marqués comme consommés (un trou ou une impression sur les tickets, un coup de tampon encreur sur les timbres). Il n'est en théorie pas possible d'utiliser un même ticket pour payer deux fois la même prestation.

Le principe du porte-jeton dans la CAM suit le même principe :

La carte dispose d'une zone de mémoire EPROM ou EEPROM comportant un certain nombre de bits dans la valeur est fixée arbitrairement à 1 dans l'état initial. A chaque bit est associé un droit d'accès à un service (ou une fraction de ce droit). Lorsque l'on achète une prestation de service, un ou plusieurs bits sont mis à 0 selon le montant de l'achat. Lorsque tous les bits sont à 0, la zone porte-jetons est entièrement dépensée.

La Télécarte de France Télécom fonctionnait selon ce principe. Le coût d'achat de la carte correspondait au coût d'un certain nombre de taxes téléphoniques, les taxes non encore consommées étant représentées par un 1 dans la carte.

Ce principe peut être amélioré en introduisant des sécurités diverses :

Pour être pleinement efficace, la technique du porte-jeton doit être utilisée lorsque le coût des prestations est un multiple entier de la valeur du jeton et que la plage de variation de ce coût est limitée.

En multi-services avec des coûts de prestation très différents, il est préférable de disposer de plusieurs porte-jetons mais l'avance de trésorerie à consentir par le porteur de la carte est plus importante et l'utilisation de la carte est souvent moins souple.

Cette technique n'est pas adaptée au paiement de prestations d'un coût continûment variable dans la mesure où il est nécessaire que tous les montants soient un multiple de la valeur du jeton. Si le jeton a une valeur trop faible par rapport au coût moyen de la prestation, la consommation de la carte devient excessive.

Le porte-monnaie électronique (PME)

Dans le cas du porte-monnaie électronique, la preuve du prépaiement est « matérialisée » par une valeur exprimée en multiple d'une unité de base, par exemple, le centime. Alors qu'en porte-jetons, la valeur totale du prépaiement contenue dans la carte se fait en additionnant tous les jetons et en multipliant le résultat par la valeur du jeton, on utilise dans le PME un codage plus efficace (le binaire par exemple). Ainsi, pour coder 255 centimes avec comme unité de base le centime, il sera nécessaire de disposer de 255 jetons dans le cas du porte-jetons (soit 255 bits) alors que 8 bits seront nécessaires en binaire. L'inconvénient de cet avantage concerne le paiement de prestation d'un coût fixe pour lequel le porte-jetons peut devenir plus efficace.

Plusieurs techniques d'utilisation de la mémoire de la carte peuvent être envisagées. Celle qui est décrite ci-dessous a été mise en oeuvre dans le cadre d'une application réalisée par SUPELEC en 1987 concernant un système d'accès et de paiement pour un restaurant d'entreprise.

Cette application est à ma connaissance une des première ayant proposé un porte-monnaie sécurisé

D'autres méthodes plus ou moins efficaces ont été imaginées avec différents types de cartes. Pour des applications de grande envergure, il est plus intéressant de créer ou d'utiliser une carte gérant par elle même les fonctions de porte-monnaie. C'est ce qui a été fait pour Monéo (et d'autres avant).

Cartes « Ville » et autres cartes privatives

Très tôt, dans les années 1980, des utilisateurs ont envisagé d'utiliser la carte à puce pour permettre le paiement et/ou l'accès à certains services. Les applications les plus typiques ont été :

La justification de l'utilisation de cartes à puces, par rapport à d'autres technologies (piste par exemple) venait de la capacité à pouvoir réaliser des opérations localement (hors ligne) avec un niveau de sécurité acceptable à une époque ou les systèmes étaient faiblement interconnectés.

Pour les restaurants d'entreprise ou les cantines scolaires, cette caractéristique s'est au final avérée peu déterminante. Après le lancement de quelques expérimentations, on s'est aperçu qu'en pratique, les systèmes fonctionnaient en ligne et qu'il n'était pas utile d'investir dans une carte à puce coûteuse là ou une carte à piste permettant d'identifier les utilisateurs (souvent dans un environnement fermé) s'avérait suffisante.

Les seuls cas où une carte à puce pouvaient se justifier était celui des restaurants répartis pour lesquels un consommateur inscrit dans un de ces restaurants pouvaient de temps en temps aller dans un autre.

La carte implémentait alors un porte-monnaie électronique sécurisé utilisable dans les divers restaurants, ceux-ci réalisant après coup une compensation.

Pour les cartes « Ville », l'intérêt était potentiellement plus justifié. Une des premières études complète sur l'utilisation de telles cartes fut faite par la société Avant-Garde Informatique pour le compte de la ville de Rennes en 1987. Cette étude prenait en compte la quasi totalité des services proposés (Crèches, cantines scolaires, accès aux différentes activités sportives avec leur particularités, parking et parcmètres, bibliothèque, services sociaux, transports (avec possibilité de sans contact), etc) avec leurs particularités en terme de paiement et de flux financiers (forfait, jetons, porte-monnaie, autres...).

img  img
Maquette de la carte pour une exposition

Si le projet ne fut au final pas lancé, les résultats de l'étude furent utilisée dans le cadre d'autres projets.

Mais avec le recul, force est de constater que les projets de carte « ville » sont restés rares et souvent peu ambitieux.

Les principales raisons d'après moi :

Ci-dessous, quelques cartes (souvent en logique câblée) provenant de projets bretons...

img  img

img

Cartes bancaires avant EMV

Les premiers pas

En France, les premières expériences mettant en oeuvre une carte à puce ont été faites à Blois, Caen et Lyon. L'objectif était de tester trois sortes de puces car on ne savait pas exactement qu'elle était celle qui conviendrait et se comporterait le mieux. Ces expériences furent menées par les banquiers en 1983.

Ville

Population

Cartes émises

Matériels

Constructeurs impliqués

BLOIS

50 000

23 500

200

Carte à microprocesseur de Bull

LYON

1 200 000

50 000

200

Carte en logique câblée de Schlumberger (à l'époque, Flonic-Schlumberger puis Paymatec)

CAEN

120 000

50 000

250

Carte bi-chips de Philips

Les questions souvent posées telles que, « quel a été le succès commercial des cartes ? » « Quel a été l'accueil du public ?, « Combien et quel a été le montant des transactions effectuées ? » n'ont guère de sens dans le cadre des expérimentations. Les réactions de la clientèle varient nécessairement selon les services offerts par les cartes.

Une des contraintes était d'offrir une interbancarité sans concurrence de sorte que la carte (baptisée IPSO) n'offrait qu'un service minimum.

En fait, ces expérimentations avaient pour objet de démontrer, non seulement la faisabilité, mais surtout la bonne fiabilité des cartes.

Sur ce point, il fut possible d'affirmer que la fiabilité du système carte à mémoire était au moins aussi bonne que celle des systèmes utilisant des cartes à piste magnétique dans les mêmes conditions d'usage.

Ceci fut attesté par plusieurs centaines de milliers de transactions effectuées avec un pourcentage d'incidents dus au micro-circuit très faible. Ce pourcentage était comparable pour les trois constructeurs ce qui renforce encore le caractère de fiabilité puisque les composants font appel à des techniques différentes et que le procédé d'encartage diffère d'un constructeur à l'autre. L'expérience permit également de démontrer la coexistence pacifique entre la puce et la piste. C'est pourquoi la mixité fut retenue pour la suite des opérations.

Au final, c'est la carte Bull qui fut retenue pour la généralisation dans le domaine bancaire. Rétrospectivement, cela paraît logique même si la logique n'a sans doute pas été la seule responsable de ce choix :

Les cartes bancaires M4B0 et B4B0'

La carte bancaire à puce est le premier exemple d'utilisation d'une CAM dans le cadre d'une application de grande envergure.

D'après le GIE-CB, les premières cartes à puce bancaires auraient été émises à partir de 1992. Pour être précis, ces cartes ont commencé à être émises à partir de 1986 en Bretagne. 1992, est la date de généralisation de l'émission des cartes à puce. Ci-dessous, un vestige des cartes de test qui m'ont servi en 1986 à réaliser une « machine de banque » dont une partie des fonctionnalités se retrouvent dans PCCAM.

img
Le N° de PAN de l'image n'est pas celui de la carte réelle.

Une autre preuve ? Cliquez sur l'image ci-dessous pour voir les articles de presse de l'époque.

img
La machine de banque et sa petite soeur grand public avec restitution vocale,
développées entre 1985 et 1986.

Cette carte utilisa le masque M4 de Bull. B0 (B0 pour Banque génération zéro d'après Roland Moréno) est la façon dont le GIE-CB a spécifié la syntaxe et la sémantique des informations (clés, données, codes) contenues dans la carte M4. Voici en guise d'interlude ce que j'en disais en 1986 dans une revue interne de Supélec (A noter une erreur dans cet article. La mémoire utilisée par la carte M4 n'était pas une E2PROM mais bien une EPROM comme indiqué dans ce cours).

Plus tard, la carte M4 fut remplacée par le masque propriétaire B4, offrant une compatibilité ascendante avec le masque M4 mais bénéficiant de fonctionnalités nouvelles (gestion des clés, effacement...).

Objectifs

Plusieurs objectifs ont déterminé le choix et l'utilisation d'une CAM. On verra qu'ils ont été atteints avec plus ou moins de bonheur.

Lutte contre la fraude

La CAM, en raison de sa conception et de ses fonctionnalités, permet de mettre en oeuvre des mécanismes très sûrs dans le domaine de la sécurité. Or dans les années 1980, la généralisation de l'utilisation des cartes de crédits avait été accompagnée par une montée spectaculaire de la fraude. Certaines études (voir un numéro de la revue « La Recherche » de cette époque) prévoyaient un taux de fraude de 5% sur le montant total des transactions pour l'année 1987, chiffre que l'ensemble de la communauté bancaire jugeait insoutenable.

Cette montée de la fraude pouvait s'expliquer par plusieurs raisons :

Certaines raisons sont purement techniques et relèvent de la CAM. D'autres sont plutôt procédurières mais la CAM, là aussi, permet de par son intelligence locale de les améliorer. Enfin, certaines sont comportementales. Ce sont les plus difficiles à modifier ou à faire évoluer : le système peut être parfaitement fiable et sécurisé, tant que le porteur continuera à inscrire son code secret au dos de sa carte, la sécurité en aval ne sera pas mieux assurée.

Simplification des équipements de paiement

La carte à piste n'ayant pas de possibilité de traitement de l'information, toute la sécurité doit être reportée au niveau du terminal ce qui impose l'utilisation de modules de sécurité devant eux-mêmes être sécurisés (il ne faut pas que la sécurité bancaire s'effondre à cause du vol d'un de ces composants) ou d'un fonctionnement systématiquement « en ligne ». La CAM gérant sa propre sécurité, elle permet d'alléger d'autant la réalisation des équipements de paiement. Le choix de la France ayant été d'opter pour des transactions « hors ligne », l'utilisation d'une puce permettait de sécuriser les transactions localement.

Nouveaux services

L'utilisation d'un support disposant d'une capacité de mémorisation plus importante que la piste magnétique et dont les accès peuvent être sécurisés permet d'imaginer la mise en place de nouveaux services de paiement ou autres. D'autre part, l'utilisation de l'algorithme cryptographique de la carte et la disponibilité de lecteurs bon marché permet la mise en place de téléservices professionnels, voire, grand-public (Minitel plus LECAM).

Savez vous que les premières cartes bancaires CB (milieu des années 1980) avaient la possibilité de réaliser des transactions sécurisées à distance (à l'époque, via le Minitel ou des réseaux dédiés). Sauf dans des cas expérimentaux (1986, maquette réalisée pour le Crédit Agricole, tentatives de proposer un service de transactions sécurisées à la fin des années 1980 avec le LECAM ou le MAGIS (Minitel avec lecteur de carte)), ces fonctionnalités n'on jamais été mises en oeuvre à grande échelle. En 2013, c'était encore le cas.

On remarque toutefois que ce dernier objectif n'est pas du même ordre que les précédents et suscite une interrogation : veut-on offrir de nouveaux services ou veut-on justifier l'utilisation d'un moyen (la CAM) ? Le lecteur pourra peut être se faire une opinion après avoir consulté le paragraphe présentant le bilan de cette opération.

Tous ces points plus une volonté politique de promouvoir ce support dans le cadre d'une application de grande envergure furent suffisamment forts pour amener les banquiers à créer et définir la Carte Bancaire à Puce, et ce, malgré un rapport 7 entre le coût d'une CAM et celui d'une carte à piste magnétique (Les banques s'étaient engagées sur de grandes quantités afin d'obtenir un coût de carte relativement faible.

Fonctions offertes par les premières carte à puce bancaire

Fonctions élémentaires

Au minimum, elle devait continuer à offrir les mêmes services que la carte bancaire à piste magnétique. On devait donc trouver dans la puce, toutes les informations disponibles sur la piste. C'est ce que contient la zone « identité » de la carte:

Les informations contenues sur la piste magnétique sont chiffrées. Si ce chiffrement n'empêche pas que l'on puisse reproduire la carte, elle permet d'éviter la fabrication de fausses cartes (hors les reproductions) ou de connaître le code secret d'une carte perdue ou volée (code porteur ou PIN : Personnal Identification Number).

Dans la carte à puce, la zone identité était accompagnée d'une valeur d'authentification Va, résultat d'un calcul RSA (avec une clé de 320 bits) portant sur les informations de la zone identité de la carte plus une partie de son numéro de série (inscrit par le fabricant de la carte). Le degré d'authentification de la carte en local était donc équivalent à celui proposé par la carte à piste magnétique. On disposait même  d'une sécurité supérieure concernant la non reproductibilité : les cartes étaient émises avec un numéro de série dont les constructeurs garantissaient qu'ils étaient tous différents. Une partie de ce numéro entrant dans le calcul de la Valeur d'authentification, on pouvait avoir une certaine assurance qu'un particulier ne pourrait pas recopier une vraie valeur d'authentification provenant d'une vraie carte bancaire dans une autre carte (qui aurait forcément un autre numéro de série).

On disposait également d'une autre garantie des constructeurs de cartes concernant un paramètre que l'on appelait « numéro d'application » (cf Carte M4). Pour les banques, ce numéro valait #3FE5. Toute carte émise pour une application non bancaire contenait un numéro avec des bits prépositionnés dont la valeur était telle qu'il était impossible d'y inscrire le numéro de l'application bancaire (3FE5H).

On peut donc considérer que pour une authentification ne faisant pas intervenir l'algorithme de calcul de la carte, la sécurité statique était grandement améliorée par rapport à une carte à piste magnétique.

Evidemment, ces sécurité ne valaient que tant qu'il était difficile de se procurer des supports permettant d'émuler des cartes au format ISO. Dès la fin des années 1990, ce point n'était plus vrai.

Code porteur

La carte à piste magnétique bancaire contient un code secret (encore appelé code porteur ou PIN). Lorsque ce code doit être vérifié, le PIN saisi par le porteur est transmis en ligne à un serveur avec le contenu de la piste pour vérification. Dans le passé, il pouvait être vérifié localement sur les DAB/GAB (qui n'étaient pas systématiquement en ligne grâce à un module de sécurité. A chaque tentative de présentation de code faux, une information est inscrite sur la piste précisant combien d'essais restent encore à faire. Au bout de trois tentatives malheureuses sur un DAB/GAB, la carte est avalée par l'équipement ou doit être confisquée.

Cette procédure offre une sécurité très moyenne étant donné les caractéristiques même de la carte à piste.

De ce point de vue, la carte à puce apporte un plus car c'est elle-même qui mémorise le nombre de présentations de codes faux et c'est elle-même qui se bloque au bout d'un certain nombre de présentations fausses consécutives (trois pour le code secret).

On trouvera une description du fonctionnement de ce mécanisme de blocage dans le chapitre consacré à la carte M4B0. Le fait que ce soit la carte qui gère sa propre sécurité permet (en théorie) de simplifier les équipements de paiements.

Enfin, la carte M4B0 ou B4B0' offrait la possibilité à son porteur de changer son code. A noter que cette possibilité a existé dès le lancement des cartes bancaires à puce mais n'a quasiment jamais été mise en oeuvre. Et ce que ne savaient pas la plupart des porteurs ni des banquiers, c'est que cette opération pouvait être faite par le porteur lui même, la seule contrainte étant de présenté le code porteur courant.

Plafond de paiement

Dans les opérations de retraits d'argent (DAB/GAB), le matériel est chargé de vérifier qu'il n'y a pas dépassement d'un certain plafond de retrait à l'intérieur d'une période de temps donnée.

Exemple

Si le plafond est de 1800 F sur sept jours glissants, on pourra retirer au maximum 1800F en une seule opération et il faudra attendre sept jours avant de pouvoir effectuer un nouveau retrait. Le montant et la date du retrait sont inscrits sur la piste de façon à pouvoir être vérifié à la prochaine opération.

Encore une fois, étant donné les caractéristiques propres de la carte à piste, la sécurité offerte par ce système est assez mauvaise.

La carte à puce offre les mêmes fonctionnalités avec une sécurité bien supérieure. La description du mécanisme utilisé demande d'approfondir le fonctionnement de la carte bancaire à puce ce qui est l'objet du paragraphe suivant. On peut simplement retenir, à ce niveau, qu'il est possible de rendre au moins les mêmes services qu'une carte à piste magnétique (ce qui est le minimum à atteindre) avec une sécurité améliorée.

Description détaillée de la carte à puce bancaire M4B0 et B4B0'

Choix de la carte

La description détaillée de la carte à puce bancaire était fournie par un document émis par le GIE-CB. Lors de sa conception, il n'existait sur le marché qu'une carte à micro-processeur fabriquée par la société Bull-CP8 : la carte M4. Le GIE-CB s'appuya donc sur les fonctionnalités proposée par cette carte pour définir son utilisation pour le domaine bancaire. C'est ainsi que fut spécifiée la carte M4B0 : M4 pour le masque, B0 pour la façon dont les informations étaient codées dans la carte. Il y eu ensuite une nouvelle spécification dite B1 mais qui ne fut pas déployée. Au début des années 1990, le GIE-CB spécifia une carte s'appuyant sur le masque M4 mais qui devait être propriété du monde bancaire. Il s'agissait de la carte B4B0' qui reprenait certaines évolutions introduites dans la carte B1. Finalement, ce masque évolua jusqu'au milieu des années 2000 avant d'être abandonnée au profit du masque EMV plus moderne.

Découpage de la carte

La carte M4 est divisée en zones (de mémoire), chaque zone bénéficiant d'un contrôle d'accès particulier et parfois configurable :

La zone de transaction

La zone de transaction contenait les informations susceptibles de varier durant la vie de la carte. On y trouvait entre-autres l'historique des transactions monétaires réalisées avec la carte. Cet historique était inscrit à partir du « haut » vers le « bas » de la mémoire de transaction, les autres informations étaient inscrites du « bas » vers le « haut », ceci pour reprendre la présentation traditionnelle du découpage mémoire de la carte.

ADRESSES BASSES

Historique des transactions

 

Autres informations

ADRESSES HAUTES

Transactions

Chaque transaction monétaire réalisée par un équipement de paiement (TPE, DAB/GAB) entraînait l'inscription d'informations caractérisant la transaction :

Ces informations étaient inscrites et validées (cf Description de la carte M4) sous le contrôle du code porteur.

Changement de date 05/89

Le 28, ACHAT COMPTANT, SOUS PLAFOND de 589,50 Francs

Le 31, RETRAIT, SOUS PLAFOND de 400,00 Francs

Changement de date 06/89

Le 01, ACHAT COMPTANT, SOUS PLAFOND de 300,00 Francs

Dans l'exemple ci-dessus, chaque opération prend un mot de la carte (32 bits). Une première opération de changement de date permet d'indiquer que toutes les transactions qui suivent ont été faites durant le mois de Mai 1989, et ceci, jusqu'à la prochaine opération de changement de date (Juin 1989). Le porteur de la carte a effectué un achat comptant sous plafond de paiement le 28/05/89 pour un montant de 589.50F. Il a ensuite effectué un retrait le 31/05/89, sous plafond de paiement pour un montant de 400.00F. L'opération suivante s'est déroulée au mois de Juin. L'équipement de paiement a donc inscrit une opération de changement de date puis a inscrit les caractéristiques de l'opération effectuée, à savoir, un achat comptant sous plafond de paiement pour un montant de 300.00F le 01/06/89.

Ces multiples informations sont essentiellement destinées au porteur de la carte. En effet, un des reproches souvent formulé à l'encontre de l'utilisation des cartes bancaires est la difficulté qu'il y a à suivre ses dépenses et son budget : chaque opération donne lieu à l'émission d'un ticket ou d'une facturette dont les formats diffèrent d'un équipement à l'autre à la différence du chèque où toutes ces informations peuvent être inscrites sur la souche du carnet. Grâce à la CAM, le porteur de la carte conserve sur un support unique l'historique de ses transactions qu'il peut consulter à tout moment pour peu qu'il dispose ou que l'on mette à sa disposition un équipement lui permettant de lire la carte.

A quoi servait cet historique :? Théoriquement, à deux choses :

En pratique, aucune de ces fonctionnalités ne fonctionnait. Pour la deuxième, il aurait fallu que les porteurs disposent de lecteurs ce qui n'était pas le cas.

Pour la première, le principal problème était que la taille de la mémoire étant limitée, et non effaçable (pour les premières cartes), il arrivait un moment ou celle-ci se saturait et il fallait alors changer la carte... ce que ne souhaitait pas faire les banques pour des raisons d'économie.

Autres informations

Elles pouvaient être fort nombreuses. On ne décrira ici que les principales :

Les plafonds

Pour chaque type d'opération possible (retrait, virement, achat comptant, achat à crédit), la banque pouvait inscrire le plafond correspondant comportant les informations suivantes :

  • Type de l'opération,
  • périodicité (nombre de jours glissants, sans périodicité particulière, etc.),
  • montant du plafond.

Si pour un type d'opération, le plafond était absent, l'opération n'était pas permise. Il était possible de « modifier » la valeur des plafonds à la demande de l'usager (ou de la banque). Cette modification était réalisée en inscrivant le nouveau plafond pour l'opération en question avec les nouvelles caractéristiques (rappel : on ne sait pas effacer ou modifier une information validée dans la carte). Lorsqu'un équipement de paiement recherchait un plafond, il devait explorer la mémoire de la carte jusqu'à ce qu'il trouve le dernier plafond inscrit pour l'opération en cours. Les plafonds étaient validés sous le contrôle de la clé de la banque (clé « émetteur principal » ou clé 1A).

Zone des certificats

dans les années 1980, les commerçants ne pouvant pas justifier d'un  chiffre d'affaires suffisant ne pouvaient pas équipés de Terminaux de Paiement Electronique (TPE) mais de ce que l'on appelait familièrement un « fer à repasser ». Cet appareil permettait de reporter l'empreinte de la carte du client sur une facturette. Cette procédure donnait lieu à une fraude relativement importante (faux par duplication, non respect des plafonds maximum par émission d'une double facturette, etc.). Pour éviter cela, il fut décidé de munir les commerçants d'un appareil peu coûteux appelé « certificateur bancaire ». Le rôle de cet appareil était double :

img
Certificateur bancaire DBU26001, Bull

La première fonction est relativement triviale puisque  c'est la carte qui effectue la vérification. Il suffit que l'appareil soit muni d'un clavier permettant la saisie pour pouvoir ensuite réaliser la fonction demandée.

La deuxième fonction mettait en oeuvre une zone de certificats (assimilable à une zone porte-jetons), l'algorithme et le jeu secret contenu dans la carte du porteur.

La zone de certificats était matérialisée dans la carte par une en-tête prestataire (permettant de la différencier des autres zones) validée sous le contrôle de la clé de la banque. A la suite de cette zone se trouvait un certain nombre de mots non validés contenant des bits non grillés.

Entête zone de certificats+ taille de la zone

 

Zone porte-jetons sur un ou plusieurs mots

 

Le certificateur utilise cette zone pour demander à la carte de calculer un certificat non reproductible. Le principe en est le suivant :

La zone des certificats avait une longueur variable suivant les banques (une centaine à quelques centaines de bits en général). Comme aucune autre information que le bit grillé n'était inscrite dans la carte (en particulier, il n'y a pas inscription de la transaction dans l'historique), un client pouvait effectuer un grand nombre d'achat en très peu de temps sans qu'il y ait vérification de sa solvabilité ou du dépassement de plafond pour peu qu'il ne choisisse que des commerçants équipés de certificateurs. Pour éviter ce phénomène, une variante fut introduite au système par l'introduction de la zone des certificats à contrôle de flux. Le principe consiste à limiter logiquement le nombre de certificats possibles alloués à chaque mois d'utilisation de la carte. Mis à part cela, le fonctionnement suit le même principe que ce qui vient d'être exposé.

Zone publiphone

Un service intéressant offert par la carte bancaire à puce consistait à l'utiliser pour téléphoner dans les cabines téléphoniques à carte. En ce sens, on peut dire que la carte bancaire fut multi-services puisqu'elle permettait l'accès à deux services de nature différente dépendants de deux prestataires indépendants.

Principe

Lorsque le client insérait sa carte dans le lecteur du publiphone, celui-ci commençait par lui demander de composer son code secret. Si le code était correct, le publiphone recherchait une « zone publiphone » dans la zone de transaction de la carte. S'il n'en trouvait pas, il proposait d'en créer une. Une zone publiphone est dans le principe équivalent à une zone contenant des certificats (il s'agit d'une zone porte-jetons). Elle est matérialisée par  un en-tête prestataire suivi d'un certain nombre de mots non validés contenant les « jetons » de téléphone et d'une valeur d'authentification.

En-tête zone publiphone taille de la zone

 

Zone de bits (jetons de téléphone)

 

Valeur d'authentification

La valeur d'authentification permettait au publiphone d'authentifier la zone comme ayant bien été inscrite sous le contrôle du prestataire (France-Télécom). Sa présence était due au fait que pour diverses raisons, France-Télécom ne validait pas l'en-tête sous le contrôle de sa clé (clé 1B) mais sous le contrôle de la clé porteur (problème lié à la sécurisation du transport de la clé 1B jusqu'au publiphone, problème également lié au fait que la carte M4 ne permettait pas de faire des présentations de clés chiffrées).

Si le client acceptait la transaction, n taxes (140 en pratique) étaient réservées dans la carte et une opération d'achat comptant était générée par le publiphone. Ensuite, tout se passait comme avec la Télécarte. Chaque taxe de base entraînait le grillage d'un bit. Lorsqu'il ne restait plus que 20 bits (jetons) dans la carte, le publiphone proposait au client l'inscription d'une nouvelle zone, et ceci, sans couper la communication en cours.

La première carte bancaire a été très ambitieuse en proposant d'emblée une carte multi-prestataires. Toutefois, le système fut abandonné en 1994 car la gestion du deuxième prestataire (France-Télécom) était trop problématique. Les raisons étaient les suivantes :

A partir de 1994, la zone publiphone fut donc abandonnée pour être remplacé par le fonctionnement suivant, nettement moins intéressant :

Bilan

Survol

L'histoire de la mise en place de la carte bancaire à puce a été riche en rebondissement et a même failli être abandonnée en cours de route.

Au départ, il y a eu les inévitables problèmes techniques liés à la mise en place d'une nouvelle technologie : puces sauteuses, ruptures de connexions, démagnétisation des pistes, terminaux et particulièrement, publiphones tueurs de puces, etc. Les autres problèmes sont venus des banques elles-mêmes.

Passé l'effet d'image (la campagne de publicité faite à Rennes au démarrage de l'opération fut particulièrement soutenue), les agences bancaires se trouvèrent fort embarrassées lorsque les premiers problèmes arrivèrent : saturation de la carte, remboursement des jetons non consommés dans les zones publiphones, puces hors-services, etc.

La logistique ne suivant pas, ces problèmes donnèrent lieu a une mini-réaction de rejet, tant de la part des commerçants et des porteurs que de certaines banques elles-mêmes. La carte à puce apparaissait alors comme un jouet technologique inutile, coûteux et quasiment pas utilisés, la plupart des TPE et tous les DAB/GAB ne sachant lire que la piste.

Afin d'avoir moins de problème, les commerçant (et les banques) conseillaient aux utilisateurs de scotcher la puce afin que les TPE ne la détecte pas et que seule la piste soit prise en compte. On en arriva donc à la situation cocasse où les banques émettaient des cartes qui leur coûtaient 7 fois plus cher que celles qui n'avaient qu'une simple piste tout en faisant le nécessaire pour que l'on ne puisse l'utiliser.

La situation finit par atteindre un niveau critique lorsque certaines banques menacèrent de ne plus émettre de cartes à puce. Il fallait prendre une initiative, ce fut fait en 1991 avec, d'une part, la signature par les grandes banques de la généralisation du système (avec 2 ans de retard) et surtout, l'institution du droit au rejet. Car on avait fini par oublier l'essentiel : à quoi pouvait bien servir un système de haute sécurité s'il était toujours possible de ne pas l'utiliser tout en bénéficiant du même service ? En France, le coût de la fraude dû au système carte-bancaire était mutualisé au niveau du système CB. Certaines banques peu fraudées payaient donc pour les autres. L'institution du droit au rejet au sein du système CB signifiait qu'à partir d'une certaine date, toutes les opérations de paiement CB qui n'auraient pas été réalisées avec la puce et qui donneraient lieu à un litige ne bénéficieraient plus de la garantie de paiement.

A partir de 1993, la carte à puce s'imposa. Le coût de la fraude a considérablement baissé depuis cette généralisation et certains n'hésitent pas à l'imputer totalement à la puce. Il est toutefois difficile de faire la part des choses car entre-temps, d'autres systèmes améliorant la sécurité du système ont également été mis en place avec en particulier la généralisation des TPE au détriment des « fer à repasser » et la mise en place du Réseau Carte Bancaire (RCB devenu depuis eRSB) permettant l'interrogation du serveur de l'émetteur de la carte en temps réel lors d'un retrait d'argent.

Reprenons maintenant quelques-uns des objectifs initiaux du projet et regardons ce qu'il en est advenu :

Sécurité

Meilleure sécurité statique due à la non reproductibilité de la carte (sécurité dépendant en partie du constructeur) : ce point a permis d'améliorer la sécurité au niveau des TPE et des publiphones. En 1994, les DAB/GAB ne savaient toujours pas lire la puce. Quant aux certificateurs, il ne furent quasiment jamais utilisés. Peut-être, quelques vieux commerçants Rennais ont-ils encore dans leur tiroirs ces étranges appareils munis d'un clavier et d'un afficheur qui leur fut distribué dans les années 1986. Peut-être même se rappellent-ils encore à quoi ils étaient censés servir. La technique a rattrapé la technique. Le problème de la certification des transactions dites manuelles se pose sans doute moins qu'avant du fait de la généralisation des TPE, laissons dormir les certificateurs...

Meilleure sécurité dynamique par l'utilisation de ses possibilités de calcul (sécurité ne dépendant que de l'émetteur) : rares sont encore les applications utilisant les possibilités de calcul de la carte dans le domaine des télétransactions. VERIDIAL qui fait plus loin l'objet d'un chapitre aurait été un des grands projets mettant en oeuvre les possibilités de calcul de la carte dans ce domaine. « Aurait » car il s'agit d'un beau ratage comme l'informatique sait nous en offrir.

Toutefois, un pas décisif fut franchi après l'affaire Humpich et la création de YesCard. Rappelons le, la carte n'était authentifiée que sur la base d'une signature statique inscrite dans la zone en lecture libre. En 1986, il était difficile de reproduire une carte ayant l'apparence d'une vraie carte simplement parce qu'il était difficile de se procurer de telles cartes. Ce n'était plus le cas 10 ans après. Il devenait donc relativement simple de clôner, voire de créer de toute pièce de vraies-fausses cartes tant qu'un calcul mettant en oeuvre un secret de la carte n'était pas mise en oeuvre. Le GIE-CB décida donc de franchir le pas et des cartes avec authentification dynamiques via un calcul RSA furent émises. En 2012, toutes les cartes bancaires émises avec le logo CB étaient normalement avec authentification dynamique. Il aura juste fallu attendre 20 ans après le lancement de la carte bancaire.

Dans le même ordre d'idée, il était possible de sécuriser les télétransactions dès le lancement des premières cartes bancaires. Des tentatives furent faite avec le Minitel et le LECAM dans ce domaine mais sans grande volonté politique et ce système fut abandonné. Avec l'explosion des achats sur Internet dans les années 2000, il était temps de faire quelque chose. L'adoption (timide en France) de 3D Secure a été une première réponse à ce besoin. En 2012, environ 10% des transactions faites avec 3D Secure utilisaient les moyens de calcul de la carte (procédé CAP sur la carte EMV).

Services

carte multi-prestataires : le timide essai de carte multi-prestataires réalisé avec France-Télécom n'a pas été transformé. Les raisons tiennent en partie à des problèmes d'organisation au niveau des banques (remboursement des jetons non consommés). La carte est redevenue mono-prestataire depuis 1994.

Toutefois, à partir de la deuxième moitié des années 2000, la pression des opérateurs de téléphonie mobile pour élargir l'offre de service sur téléphone a donné lieu à des spécifications et des exigences sécuritaires permettant d'envisager de proposer une véritable offre de services multi-prestataires s'appuyant sur la carte SIM. Celle-ci deviendra donc peut-être la première carte multi-prestataire dans le cadre d'une application de grande envergure.

modification des plafonds : quasiment jamais mis en oeuvre car nécessite des investissements au niveau du guichet de l'agence qui n'ont pas été réalisés.

autres modes de paiement que « achat comptant » : bien que prévu à l'origine (par exemple, crédit revolving ou virements), cette possibilité ne fut quasiment pas mise en oeuvre (certaines expérimentations ont été réalisées (Crédit-Agricole du Morbihan en 1986) avec les cartes M4B0 et B4B0'.

Principales différences entre la carte M4B0 et la carte B4B0'

Les principales différences étaient les suivantes :

Principales différences entre les cartes B4B0' et EMV

Le standard EMV décrit dans le chapitre suivant a été promu par le consortium Europay (racheté par Mastercard), VISA et Mastercard. Il est très inspiré de la carte bancaire française (et pour cause...) mais étant arrivé environ 15 ans après les spécifications des cartes bancaires françaises, il bénéficie des avancées techniques qui ont eu lieu durant cette période :

Cartes bancaires EMV

Généralités

le standard EMV a été spécifiée à partir de 1993 par un groupe d'expert appartenant aux réseaux Europay, Mastercard et Visa d'où le nom de spécification EMV. L'objectif était de définir un ensemble de spécifications permettant le dialogue entre une carte et un terminal.

En 1999 a été créé EMVco dont l'objet était de gérer les spécifications EMV, mettre en place une procédure d'agrément des terminaux de paiement et des DAG/GAB.

Plusieurs versions des spécifications se sont succédées. Les plus emblématiques sont la première version qui date de 1994, la version 3.1.1 dite EMV96 qui date de 1996, la version 4.0 dite EMV2000 qui date de 2000. Le logiciel PCCAM ainsi que cette présentation s'appuient pour l'essentiel sur les spécifications 4.2 qui datent de 2008.

La spécification EMV comporte plusieurs livres (book).

Livre 2 (Book 2, Security and Key management) : il décrit les fonctionnalités minimales de sécurité imposées entre la carte et le terminal pour assurer un enchaînement correct des opérations et l'interopérabilité. Les principales fonctionnalités sécuritaires pour l'authentification sont :
  • L'authentification statique : elle permet, par la lecture d'un cryptogramme, de s'assurer que la carte a été émise par une autorité autorisée. Ce mécanisme qui a été utilisé en France au lancement de la carte bancaire (1986) a vite montré ses limites puisqu'il ne permet pas de garantir la non duplicabilité de la carte.
  • L'authentification dynamique en mode hors-ligne : ce mécanisme repose sur un challenge-réponse en RSA utilisant des clés publiques certifiées.
  • L'authentification dynamique combinée qui est proche de l'authentification dynamique mais comportant mais qui inclut un cryptogramme d'application (AC). Une façon de construire ce cryptogramme d'application est également exposée dans la spécification. En pratique, ce cryptogramme est un message d'authentification (MAC) portant sur diverses informations comme par exemple, les montants autorisés, le code devise, le compteur de transaction de l'application (ATC), etc.

Dans le système CB, le mécanisme d'authentification dynamique est à minima celui qui est mis en œuvre depuis plusieurs années, d'abord sur la carte B0' vers le milieu des années 2000, puis sur EMV lorsque B0' a été abandonné. EMV spécifie également les différents usages proposés par des messages sécurisés (secure messaging).

Un mode permet d'assurer l'intégrité et l'authentification des données, un autre permet d'assurer la confidentialité.

Un mécanisme important de la carte est le compteur de transactions de l'application (ATC). Ce compteur doit être incrémenté de 1 à chaque transaction, la notion de transaction étant définie dans la spécification (par exemple, un paiement). Sa valeur limite est de FFFF en hexadécimal. Le nombre maximal de transaction est donc défini par cette valeur moins la valeur initiale du compteur. Ce mécanisme a deux usages : il assure l'unicité des transactions et limite les attaques par force brute sur la carte.

L'inconvénient est qu'il limite également la durée de vie de la carte et possiblement, il peut rendre la carte indisponible si un attaquant a la possibilité de jouer des transactions à l'insu du porteur.

Une des fonctions de base d'une carte à puce est la vérification d'un code, en particulier, dans le domaine bancaire, d'un code porteur ou PIN (Personnal Identification Number). Afin de lutter contre le piégeage des terminaux (interception du dialogue entre la carte et le terminal), il est proposé une présentation chiffrée du code PIN en mode hors ligne. Le mécanisme est le suivant :

  • Le terminal demande un nombre aléatoire R à la carte (commande GET CHALLENGE)
  • Le terminal calcule le cryptogramme d'une donnée comportant :
    • 7F (hexa)
    • PIN (codé sur 8 octets)
    • R (codé sur 8 octet)
    • Padding de N-17 octets, N étant la longueur de la clé publique utilisée pour le chiffrement du PIN (à lire dans la carte).
  • Ce mécanisme implique que les terminaux disposent d'un générateur d'aléea pour constituer le padding.

Lors d'une commande de vérification du PIN (VERIFY PIN), la carte doit effectuer les contrôles sur les données reçues (7F, R, vérification du PIN) et rend le résultat de ce contrôle au terminal.

Les algorithmes approuvés par EMV dans la version 2008 de la spécification sont :

  • Symétriques : le DES, le triple DES avec des modes opératoires dépendant de la fonction à réaliser.
  • Le RSA avec une longueur maximum de clé de 1984 bits (248 octets) et un exposant public devant être 3 ou 2^16+1. En pratique, certaines considérations sur la longueur et le codage des données échangées peuvent limiter encore plus la longueur des clés RSA utilisables (par exemple, en CDA, deux exemples fournis dans la spécification montrent une limitation à 1920 bits, voire, 1605 bits). Pour information, à partir de 2010, l'Agence Nationale de la Sécurité des Systèmes d'Information recommandait 2048 bits.
  • Hachage : SHA1

Comme on peut le constater, en 2008, la cryptographie utilisée n'était pas forcément la plus à jour (en particulier, l'usage du SHA1 n'est pas recommandé pour certaines fonctions et le DES n'est plus considéré comme ayant une résistance élevée).

Livre 3 (Book 3, Application Specification) : le document spécifie les procédures permettant de réaliser une transaction de paiement entre un terminal et une carte. on y trouve :
  • La spécification des commandes de la carte (classe d'instruction, code de l'instruction, nom symbolique) qui s'appuient elles-mêmes sur la norme 7816-4.

    img
    Commandes EMV

  • La description des enchainements d'actions à réaliser pour mener à bien uen transaction dans les différents cas de figure possible
  • Le codage et la sémantique des éléments de protocole
Livre 4 (Book 4, Cardholder, Attendant, and Acquirer Interface Requirements) : le document s'intéresse donc aux caractéristiques générales des terminaux de paiement, leur architecture logicielle, leur spécification d'interface, etc. ne s'agissant pas de l'objet principal de ce cours, je me contenterai de lister un extrait des têtes de chapitre de la table des matières de la version 2008.

Part II - General Requirements
Terminal Types and Capabilities
Functional Requirements
Physical Characteristics

Part III - Software Architecture
Terminal Software Architecture
Software Management
Data Management

Part IV - Cardholder, Attendant, and Acquirer Interface
Cardholder and Attendant Interface
Acquirer Interface

Part V - Annexes
Annex A Coding of Terminal Data Elements
Annex B Common Character Set
Annex C Example Data Element Conversion
Annex D Informative Terminal Guidelines
Annex E Examples of Terminals

Paiement EMV en mode contact

La carte EMV en mode contact est censée être conforme aux normes EMV évoquées dans le chapitre précédent. Pour autant, la norme EMV n'est qu'une boite à outil dont l'implémentation dépend des schémas de paiement (VISA, MASTERCARD…) ce qui peut entraîner des différences dans les modes opératoires entre carte et terminal. La description qui suit du fonctionnement d'une carte EMV n'est donc qu'un cas particulier de ce que l'on peut réellement trouver sur le terrain.

Lorsqu'un terminal souhaite dialoguer avec une carte EMV, il peut chercher à déterminer l'environnement du système de paiement carte (PSE, Payment System Environment) afin de connaitre la liste des applications présentes et référencées par des AID (Application Identifier). Ce PSE se fait en utilisant l'ordre SELECT de la norme 7816-4 avec comme paramètre, la valeur « 1PAY.SYS.DDF01  » qui est la valeur enregistrée par l'ISO pour les paiements de type contact (2PAY.SYS.DDF01 pour le sans contact. On parle de PPSE pour Proximity PSE).

La carte n'est pas forcée d'implémenter ce mécanisme. Dans ce cas, le terminal devra alors tenter de sélectionner les applications cartes qu'il connaît grâce à leur AID. Sinon, ces AID sont présent dans la réponse avec d'autres informations de contexte (priorité de l'application, langue préférée, etc.).

Le terminal doit alors sélectionner l'application qu'il souhaite utiliser. En supposant qu'il ait la liste des AID présents, il doit sélectionner celle qui a le niveau de priorité maximal parmi celles qu'il connaît lui-même. Ceci fait, il peut récupérer des informations telles que le nom de la carte (carte VISA, CB), la langue préférée (FR), la priorité de l'application, le nom préféré de l'application (par exemple, TRANSACTION CB), les références du fichier de log des transactions, etc.

La commande GET_PROCESSING_OPTION spécifique à EMV permet d'initier une transaction. En réponse, la carte va renvoyer une série d'informations dans un PDOL (processing Data Object List) contenant un AIP (Application Interchange Profile) et un AFL (Application File Locator). Contenu d'un PDOL :

img
Architecture de clé pour SDA

img
Architecture de clé pour DDA

L'Application File Locator (AFL) permet de connaître la structure de fichier associée à l'application sélectionnée.

Il serait fastidieux d'entrer dans le détail de ces fichiers. Pour ceux qui ça intéresse, le TP sur les cartes EMV donne un exemple de trace que l'on peut obtenir. La figure ci-dessous donne une représentation graphique d'un extrait de la structure des fichiers d'une telle carte. Mais pour ceux qui veulent se faire une idée générale sur le contenu, on peut citer :

img
exemple d'arborescence de données sur une carte EMV avec PCCAM

Pour terminer sur les données, il faut en signaler une particulièrement importante accessible via une commande 7816-4 GET_DATA. Il s'agit de l'ATC (Application transaction counter, compteur de transaction de l'application). Ce compteur s'incrémente lors de chaque transaction. Sa valeur entre dans les calculs cryptographiques, permettant d'assurer l'unicité de ces calculs, toutes autres données égales par ailleurs. De plus, ce compteur permet de limiter le nombre de transactions pouvant être réalisé par la carte et surtout, le nombre de calculs cryptographiques associés. Ce mécanisme rend beaucoup plus difficile les attaques par canaux auxiliaires lors de ces calculs.

Selon la personnalisation, d'autres données sont potentiellement accessibles via une commande GET_DATA, comme par exemple :

La sécurité des transactions est assurée par une série de calculs cryptographiques utilisant des algorithmes à clé publique (RSA, courbes elliptiques annoncées à partir de 2020) et à clé secrète (triple DES, AES annoncé à partir de 2020).

La carte dispose d'un biclé comportant une clé privé d'ICC (Integrated cicuit Card Private Key) et un certificat de clé public associé (ICC certificate) délivré par l'émetteur de la carte. Ce biclé permet à la carte de réaliser des cryptogrammes permettant d'authentification de données (et donc d'elle-même puisqu'elle prouve ainsi qu'elle connaît la clé privée associée au certificat de clé publique associé).

Elle peut également disposer d'un biclé comportant une clé privée de chiffrement ICC (Integrated Circuit Card private Key) et le certificat correspondant autosigné. Ce certificat permet au terminal de présenter le PIN de la carte chiffré par la clé publique contenue dans le certificat. La carte peut vérifier grâce à sa clé privée.

Enfin, la carte dispose d'une clé secrète «  maître » ICC (Integrated Crcuit Card Master Key) pour l'algorithme triple-DES. Cette clé, reliée au PAN, permet de dériver des clés de session (ISS session Key) lors de chaque transaction. Cette dérivation se fait selon la valeur de l'ATC qui rappelons le, est incrémenté à chaque transaction. Cette clé de session est utilisée pour calculer des messages d'authentification (MAC) de données transmises par la carte. Petit inconvénient, ces MAC ne peuvent pas être vérifiés par le terminal (il ne dispose pas de la clé correspondante pour des raisons de sécurité). Ces MAC sont destinés à être vérifiées en ligne ou a postériori par l'émetteur en cas de problème.

La protection en confidentialité de toutes ces clés et en intégrité des clés et de certaines données critiques justifient les évaluations sécuritaires particulièrement poussées auxquelles sont soumises les cartes.

On dispose désormais de suffisament d'éléments pour comprendre le déroulement typique d'une transaction EMV. Pour mémoire, le terminal a la possibilité d'avoir accès à toutes les informations publiques décrites précédemment, il connait l'application et son mode opératoire.

Le book 3 d'EMV donne les différentes situations possibles à ce stade d'une transaction. La première chose que l'on peut constater, c'est qu'EMV n'est pas l'inventeur de la programmation structurée. Je vois plutôt l'institution jouer dans la catégorie « plat de nouilles ».

img
GENERATE_AC et réponses

Quelques commentaires :

1) Le pavé« terminal decision » correspond à l'analyse de risque du terminal. Suite à cela, il peut rejeter la transaction, la proposer en ligne ou la proposer hors ligne. En cas de rejet de la transaction, il le signifie à la carte via sa demande GENERATE_AC. La carte calcule et« signe » un AAC (en 3DES) et l'envoie au terminal.

2) Si la transaction est proposée en ligne, la carte, qui réalise sa propre analyse de risque peut, refuser la transaction (elle envoie un AAC) ou accepter la proposition d'aller en ligne. Elle le fait savoir en calculant un MAC qu'elle envoie dans l'ARQC. Cet ARQC est envoyé au système d'autorisation, seul en mesure de le vérifier (le terminal ne dispose pas de la clé secrète utilisée pour le MAC). EMV recommande que ces informations contiennent le montant de la transaction, le pays du terminal, le résultat de la vérification du terminal, la devise, la date, le type de la transaction, l'aléa du terminal, l'AIP (les fonctionnalités supportées par la carte) et l'ATC (le compteur de transaction).

3) Si la transaction est proposée hors ligne, la carte, qui réalise sa propre analyse de risque peut, refuser la transaction (elle envoie un AAC), demander à aller en ligne (elle envoie un ARQC) ou générer un TC. Une différence entre un ARQC et un TC est que le TC peut être vérifié localement par le terminal s'il dispose de la clé publique correspondante.

Paiement EMV en mode sans contact (NFC)

Note : la plupart des figures de ce chapitre sont reprises du white paper de la Smart Card Alliance sur le HCE

Il n'est pas difficile de convaincre les utilisateurs des cartes de transports sans contact (premières applications « sécurisées » déployées à grande échelle) de la rapidité et de la facilité d'usage de ce type de support. Qui plus est, ces cartes sont moins sensibles à l'usure que les cartes avec des contacts.

Le commerce, qui cherche à accélérer le passage en caisse, ne pouvait être qu'intéressé par cette évolution. Il y avait toutefois quelques problèmes dont celui de la saisie du PIN. Si l'on veut bénéficier à plein de la rapidité du sans contact, cette saisie doit être abandonnée, d'autant plus qu'en sans contact, elle n'est pas très pratique à faire. Or, le PIN est considéré comme valant signature de la part du porteur et permet la garantie de paiement pour le commerçant (transfert de responsabilité dans le jargon bancaire).

Après quelques tentatives (assez molles il faut bien le dire) pour convaincre que « ce serait bien d'avoir la garantie de paiement malgré l'absence de la présentation du PIN », il a été admis que le paiement sans contact ne bénéficierait pas de cette garantie (comme c'est prévu lorsqu'il n'y a pas de signature ou de présentation de PIN). Cette mesure était cohérente avec le fait que pour protéger le porteur, il était nécessaire de limiter les montants pouvant être débités sans présentation de code en cas d'utilisation frauduleuse suite à perte ou vol.

Cela signifie également que tout porteur s'estimant lésé peut se retourner vers sa banque pour se faire rembourser les sommes payées en sans contact et que la banque doit obtempérer. Si maintenant, un porteur joue à ce jeu pour ne pas payer ses paquets de cigarettes, on tombe dans « l'abusif » et c'est une autre histoire.

En France, en 2015, le montant maximum pouvant être débité lors d'un paiement était de 20€ et le paiement cumulé maximum était de 140€ (source Cartes Bancaires). Une fois ce montant cumulé atteint, la carte impose que le paiement qui suit se fasse en mode contact avec présentation du PIN).

Le paiement sans contact consiste donc à remplacer les communications se faisant via des contacts sur la carte par un moyen des communications sans contact se faisant en RF, Infrarouge… En terme réseau, on substitut donc la couche physique (couche 1 du modèle OSI) par une autre. Pour le développeur d'application, cette modification est (presque) transparente. Par exemple, PCCAM fonctionne aussi bien avec des cartes contact qu'avec des cartes sans contact sans modification du logiciel. C'est le lecteur qui se charge de masquer cette différence au logiciel. Par contre, les temps de réponse sont beaucoup plus court en sans contact qu'en contact du fait des débits plus élevés autorisé par le mode sans contact. Pour plus de précisions, voir le chapitre sur le sans contact NFC

On se rappelera que la fonctionnalité sans contact des cartes EMV vient en supplément du mode contact qui reste présent. On utilise pour ce faire des cartes dites « duales ».

Cinématique d'un paiement sans contact

Dans ses grands principes, la cinématique d'un paiement sans contact diffère peu d'un paiement en mode contact. Quelques différences doivent néanmoins être signalées :

En mode contact, le lecteur est averti de la présence physique d'une carte (via un contacteur ou la détection d'une conduction sur les contacts).

En mode sans contact, le lecteur émet une porteuse et transmet périodiquement une commande de réveil (WUPA ou WUPB pour Wake Up type A ou B, cf. norme ISO14443). La carte sans contact placée dans un champ électromagnétique est d'abord réveillée par le fait qu'elle est alimentée. Cela correspond à la mise sous tension (Reset) d'une carte en mode contact. Elle doit alors attendre la réception d'un WUPA ou WUPB selon son type. Lorsqu'elle le reçoit, elle doit répondre au lecteur. Cette réponse (ATQA ou ATQB pour Answer To reQuest, Type A ou B) est similaire aux octets de mise sous tension (ATR) renvoyés par une carte en mode contact.

Un autre point a signaler est qu'en mode contact, une seule carte peut être introduite dans un lecteur. En mode sans contact, plusieurs cartes peuvent être présentes dans le champ et être réveillées simultanément. Il faut donc que le protocole sache gérer les éventuelles collisions qui en découlent.

Le reste, vu de loin, est proche de ce qui se passe dans le cadre d'un paiement en mode contact. Lorsque la carte est détectée, le lecteur doit réaliser un SELECT PPSE (2PAY.SYS.DDF01) pour connaitre la liste des applications de paiement présentes dans la carte puis sélectionner l'application de paiement à utiliser. Il est également possible de sélectionner directement des applications parmi une liste connue.

Evidemment, l'autre grande différence entre un paiement en mode contact et un paiement en mode sans contact est que l'authentification du porteur n'est plus obligatoire, du moins, jusqu'à un certain montant définit par les schémas de paiement.

La sécurité du paiement sans contact

Le chapitre sur la sécurité des cartes donne des informations sur les attaques spécifiques au sans contact. Leur faisabilité peut varier selon que l'on utilise une carte ou un autre équipement (exemple, smartphone, voir chapitre suivant sur les différents types de paiement sans contact). Les conséquences de ces attaques sont expliquées ci-dessous dans le contexte du paiement :

Bilan (2015)

Du point de vue commercial, le paiement sans contact a fait l'objet de nombreuses critiques basées sur les attaques potentielles décrites précédemment. Le lecteur jugera si ces critiques sont suffisamment justifiées pour demander ou non la désactivation de cette fonctionnalité sur sa carte. Pour les plus anciens dans le domaine, elles peuvent rappeler les critiques qui avaient été faites à propos des cartes à puce lors de leur lancement en 1986 (pas si sûres que ça, contiennent des informations auxquelles le porteur n'a pas accès, permettent de fliquer les porteurs…). Je pense que si quelqu'un avait formulé ces critiques en 2015, il aurait été considéré comme quelqu'un d'un peu dérangé ou un adepte forcené de la théorie du complot.

En 2014, des chercheurs de l'université de Newcastle au Royaume uni (Martin Emms, Budi Arief, Leo Freitas, Joseph Hannon, Aad van Moorsel) ont mis en évidence une faille dans le système [archive] qui n'est pas lié à la technique du sans contact a proprement parlé mais plutôt, des applications de paiement.

En quelques mots, il est possible d'outrepasser les plafonds lors de paiements en devises étrangères en mode hors-ligne sans contrôle du montant (« For example, we have found that Visa credit cards will approve foreign currency transactions for any amount up to €999,999.99 without the cardholder's PINnbsp;») sachant qu'il s'agit d'une carte anglaise avec un montant maximum par transaction unitaire de 20£). La mise en évidence de cette vulnérabilité est très intéressante. Les chercheurs ont réalisé un model formel d'un paiement sans contact et ont constaté qu'il n'était pas possible de modéliser des pré-conditions correctes lorsque le montant était en devise étrangère (problème de spécification). Cela montre une fois de plus tout l'intérêt de telles modélisations pour mettre en évidence des propriétés (fonctionnelles et/ou de sécurité) non satisfaites.

A propos de spécifications, on doit regretter le fait que les principaux schémas de paiements internationaux (Visa, Mastercard, Amex…) n'aient pas réussi à se mettre d'accord pour la spécification de la cinématique d'un paiement sans contact et pour les caractéristiques des applications. Du coup, chaque fournisseur de carte doit développer plusieurs applications et l'on doit retrouver ces applications sur les terminaux de paiements.

Il existe néanmoins une spécification publique et conforme aux spécifications EMV de base (CPA) qui est proposé par certains fournisseurs. Cette spécification est utilisée par certains schémas de paiement domestique.

Paiement mobile EMV sans contact, généralités

Préambule

En préambule, il faut rappeler que la généralisation des smartphones a donné l'idée à certains d'utiliser ces équipements pour réaliser des paiements de proximité. Ca devait être vers 2008. En 2014, certains acteurs prédisaient la fin de la carte à puce dans les deux ans à venir au profit du smartphone (je ne citerai pas de nom par bonté d'âme). En 2015, les paiements par smartphones restaient marginaux. Pour autant, l'agitation sur le sujet a été intense et a relancé les luttes de pouvoir entre les différents acteurs de l'écosystème pour la prise de contrôle du smartphone.

Historiquement, ce sont les opérateurs téléphoniques qui maîtrisent le téléphone via la carte SIM. Il n'était pas surprenant que ces opérateur proposent un jour cette ressource pour permettre de réaliser des paiements par smartphone (voire, même, tente de se substituer aux banques). Dans le jargon, ces solutions sont appelées SIM-centric et utilisent une carte USIM (Universal SIM).

Nokia, au temps de sa splendeur avait tenté de les évincer en proposant de remplacer la carte SIM par un élément sécurisé (MTM (Mobile Trusted Module) par analogie avec le TPM (Trusted Platform Module) qu'il contrôlait. Le projet n'a pas abouti à l'époque mais le lancement d'ApplePay par Apple en 2014 a redonné de la crédibilité à cette idée. Ce mode est dit « secure element embedded ». Le SEE, comparable à une carte à puce, stocke et exécute l'application de paiement. Mais faisant partie du téléphone, il est sous contrôle du fabricant de ce téléphone.

La généralisation des smartphones et la montée en puissance de l'informatique en nuage (cloud) ont également amené de nouveaux acteurs à vouloir s'approprier le contrôle, si ce n'est de l'appareil, du moins de certaines de ses fonctionnalités. Le mode dit « HCE> » (Host Card Emulation que l'on pourrait traduire par émulation de carte sur serveur) est un premier aboutissement de cette évolution. Ici, ce sont les fournisseurs de systèmes d'exploitation et donc, en particulier Google en 2015, qui entrent dans la danse.

Dans ce mode, la carte est plus ou moins « hébergée » dans le cloud. Plus ou moins car comme on le verra, en général, cette émulation est plutôt réalisée dans le smartphone lui-même pour des raisons de performances. Du point de vue de la sécurité, cela change beaucoup de chose. Ce mode a originellement été créé pour contrer les difficultés relationnelles qui pouvaient exister entre les opérateurs téléphoniques propriétaires de la carte SIM et les offreurs de solution. Avec le HCE, exit l'opérateur (dans une certaine mesure).

Une conséquence de cette évolution est la disparition d'un certain facteur de forme (la carte ISO) au profit, en pratique, de n'importe quel objet ayant un facteur de forme imprédictible (une bague, une montre, un montage électronique personnel, un bouton de manchette, etc.) ce qui n'est sans doute pas sans conséquences sur la sécurité. Toutefois, pour simplifier les explications à venir, je ne considèrerai par la suite que la cas du smartphone avec ses particularités.

Une autre conséquence est l'obligation de disposer d'une source d'énergie (la batterie du smartphone) pour payer. Ce retour à des solutions des années 1980 (les cartes actives) que l'on croyait obsolète a de quoi surprendre. Tant que cette source d'énergie restera indipensable, je ne saurai que trop vous conseiller de disposer d'une carte traditionnelle en secours !

On notera cependant que les opérateurs de transports français avaient imposé (dans le cadre du projet Pegasus) que la validation du titre puisse se faire même en cas de batterie déchargée (mais il n'y a généralement pas d'interaction avec une application).

Pour finir, ce chapitre ne traite que de paiement répondant au standard EMV. D'autres solutions ppropriétaires n'utilisent pas ce standard. Leur principal inconvénient est qu'elles ne sont donc pas compatibles avec le parc des terminaux de paiements ou des automates acceptant la carte bancaire. La généralisation de ces solutions est donc sujette à caution (en 2014), surtout lorsque l'on connait le temps nécessaire pour faire migrer un parc de carte et de terminaux.

A ce propos, en 2015, lors d'une conférence gouvernementale sur la promotion du sans contact, les banques ont annoncé que tous les porteurs (qui le souhaitent) seraient équipés d'une carte sans contact en 2016 et que le parc des terminaux aurait intégralement migré pour accepter le sans contact en 2020 (25% du parc en 2014).

Le paiement mobile SIM centric

Avec des fabricants comme Gemalto, Oberthur et Morpho, il était normal que l‘industrie française soit très présente dans le développement de cette approche. Celle-ci peut se définir ainsi :

Le smartphone, est muni d'un moyen de communication NFC. Il dispose d'une carte dite « USIM » (Universal SIM) s'appuyant sur les spécifications de global-platform embarquant, entre-autres, une application bancaire. Cet ensemble fonctionne comme une carte bancaire sans contact avec néanmoins, une particularité : le smartphone permettant de faire des saisies, il est possible d'introduire un acte de validation du porteur préalablement au paiement. C'est un avantage par rapport à la CAM habituelle (on aurait néanmoins pu le faire sur des CAM, certaines ont été présentées dans différents salons) ce qui supprime les risques d'attaques en activation à l'insu du porteur. D'autre part, il est également possible de saisir un PIN ce qui peut potentiellement autoriser des transactions pour des montants supérieurs aux 20€ en France.

Concernant Global Platform, on peut retenir que cette spécification permet à chaque acteur (fournisseurs de service) de disposer d'un domaine de sécurité (security domain) lui permettant de gérer son application (et ses secrets) avec une garantie de confidentialité et de cloisonnement vis-à-vis des autres acteurs, y compris, l'émetteur initial de la carte. Global Platform permet de personnaliser des applications après l'émission initiale de la carte (personnalisation post issuance).

img
Paiement SIM centric

Dans le contexte des paiements, l'émetteur initial est normalement un opérateur de téléphonie mobile (Orange, SFR…). Moyennant la relation contractuelle qui va bien, il est possible pour un émetteur bancaire (BNPP, Société Générale…) de créer et gérer un domaine de sécurité destiné à son ou ses applications de paiement (VISA, Mastercard, CB…). Il peut y avoir autant d'émetteur qu'on le souhaite, tant qu'il reste de la place sur la carte USIM pour créer des domaines de sécurité et charger des applications.

Du point de vue de la sécurité, en France, les cartes USIM sont évaluées comme les cartes bancaires classiques. Le niveau de sécurité intrinsèque est donc le même que pour ces dernières en mode sans contact avec cependant quelques différences significatives si l'on considère l'ensemble « carte plus smartphone » :

Alors que les promoteurs du paiement mobile par carte USIM prévoyaient sa généralisation pour 2012, force a été de constaté en 2014 que le succès n'était pas au rendez vous. Les raisons invoquées étaient les suivantes :

Le paiement mobile HCE (Host Card Emulation)

Vers 2000, la société française Cryptolog International lançait son projet de carte virtuelle s'exécutant sur un serveur sécurisé dans le but pouvoir se passer de cartes à puce dans certaines applications. D'autres sociétés avaient lancé des projets du même type dans la mouvance de la directive européenne 1999/93/CE sur la signature électronique (on peut penser à la société Magic Access : « vous avez un téléphone, vous pouvez signer », les secrets pour la signature se trouvant dans un HSM accessible via un serveur de signature).

Mais en Europe et particulièrement, en France et en Allemagne, pays leaders dans le domaine des CAM, imaginer se passer d'un élément sécurisé sous contrôle exclusif de l'utilisateur pour faire de la signature électronique sécurisée n'était pas précisément une idée bienvenue, en particulier pour des raisons de sécurité.

Près de quinze ans plus tard, le concept revenait sur le devant de la scène, via les US, qui, il est vrai, n'étaient pas les plus matures dans le domaine des éléments sécurisés, ceci expliquant peut-être cela.

Wikipédia nous indique que le terme « HCE » a été inventé en 2012 par les fondateurs de la société SimplyTap. L'adoption du concept par Google en 2013 lui a donnée une crédibilité certaine. La fonctionnalité HCE a été introduite dans la version 4.4 (KitKat) du système d'exploitation Androïd.

Ceci dit, l'implémentation Androïd d'HCE autorise que les interactions puissent être réalisées aussi bien par un élément sécurisé (SIM ou autre) que par une application logicielle dont la sécurité est plus ou moins répartie dans le Cloud. Afin de répondre à ces différents cas de figure, un aiguillage est réalisé en fonction des préférences de l'utilisateur et/ou de l'application sélectionnée par le terminal.

img
Routage de la sélection des applications en HCE

Le paiement en SIM-centric ou via un élément sécurisé embarqué est traité par ailleurs. Dans la suite de ce chapitre, on n'abordera donc que le paiement HCE de type « logiciel » et l'on cherchera à comparer la sécurité entre cette approche et celles qui utilisent un élément sécurisé..

Principes du HCE (hors élément sécurisé)

HCE, dans son acceptation la plus rigoriste, repose sur les principes suivants ::

img
Paiement HCE « logiciel »

En 2015, on considère que le paiement HCE doit être conforme aux spécifications EMV. Cette limitation est justifiée par le souhait de s'appuyer sur un large parc d'acceptation sans contact existant sans qu'il y ait besoin de le modifier et en 2015, ce parc d'acceptation était majoritairement conçu pour réaliser des transactions EMV.

En fait, il faut être plus précis car EMV seul ne veut rien dire. Il faudrait préciser EMV VISA ou EMV MASTERCARD pour ne citer que les deux schémas de paiements les plus importants car en pratique, les TPE sont majoritairement personnalisés pour accepter les cinématiques spécifiques associées aux applications de ces deux schémas. On verra plus loin que cette limitation a un impact sur la sécurité.

Vu de l'utilisateur, une cinématique simplifiée et théorique d'un paiement HCE peut être la suivante :

Du fait des possibilités de traitement et d'interaction qu'offre le smartphone, le nombre de variantes imaginables est important. La seule limite est de rester dans le cadre d'une transaction EMV acceptable par un terminal de paiement électronique. En plus de celle précédemment exposée, d'autres cinématiques peuvent être les suivantes ::

Cette cinématique théorique se heurte en 2015 à quelques difficultés de mise en œuvre :

Pour ces raisons, la solution la plus en vogue en 2015 est, lorsque la communication le permet, de pré-approvisionner le smartphone avec des justificatifs de paiement (credentials) qui seront mémorisés localement et d'utiliser ces credentials lors du paiement, sans passer par une communication avec le serveur. Ces credentials contiennent alors des clés permettant de réaliser les calculs cryptographiques attendus lors d'une transaction de paiement. Les conséquences sont les suivantes :

On a indiqué précédemment qu'il pouvait être nécessaire d'authentifier le porteur, par exemple, en l'invitant à saisir un PIN ou une donnée biométrique. Les conséquences sont les suivantes :

Nous avons exposé le lien existant entre le smartphone et le cloud pour la gestion des credential, il nous faut aussi évoquer le lien entre le terminal de paiement et le système bancaire car il n'est pas neutre en terme de sécurité.

Tous ceux qui ont été confrontés aux communications via le RTC (réseau Téléphonique Commuté) avant le déferlement de l'Internet se rappellent qu'en France, les coûts des communications étaient loin d'être négligeables dans l'équation économique de la mise en place d'un nouveau service. J'ai retrouvé quelques tarifs dans le document RTC de M. Yves Lescop :

Dans ces années là, les communications étaient facturées en unités téléphoniques (UT) de valeur 0,615FFHT. Le coût des communications variait en fonction de la distance et de l'heure, En 1986, le coût d'une communication locale était de 1UT pour 0 à 6mn de communication.

Imaginons qu'un TPE doive demander une autorisation à chaque paiement. Outre la durée de la transaction, il en aurait couté 1UT au commerçant par paiement ce qui est insupportable pour bon nombres de commerces.

C'est pourquoi, en France (et dans d'autres pays), les paiements se font majoritairement sans connexion du TPE à un serveur d'autorisation, même en 2014 (d'après Comprendre les paiements « En France, on estime que seulement 20% des paiements par carte font l'objet d'une autorisation en ligne. Les accords hors ligne sont donnés pour près de 80% des transactions »). On parle de paiement « hors ligne » (par opposition aux paiements « en ligne » lorsque le TPE se connecte systématiquement au système bancaire pour demander une autorisation).

Cette pratique nécessite de renforcer la sécurité au point de paiement. En France, ce renforcement s'est fait par l'adoption de la carte à puce et de la recherche d'un niveau élevé de résistance aux attaques de cette carte. Cela a même permis de proposer la garantie de paiement aux commerçants, même si la transaction est réalisée hors ligne.

Avec HCE, on doit se poser la question de la faisabilité sécuritaire d'un paiement hors ligne, en prenant en compte le fait que le smartphone soit connecté au réseau mobile ou pas lors de la transaction. Dans les schémas ci-dessous, le lien rouge est représente cette connexion entre le smartphone et le cloud, le lien vert représente la communication entre le terminal de paiement et le système de vérification bancaire (typiquement, le serveur d'autorisation).

 

Communications

Commentaires

img
img
Connecté au réseau mobile, en ligne

C'est le cas le plus favorable pour la sécurité. Aucun secret de paiement n'a besoin d'être mémorisé dans l'application de paiement du smartphone. Le TPE peut vérifier la validité de la transaction à travers sa demande d'autorisation.

On est dans un mode « double contrôle ».

img
img
Non connecté au réseau mobile, hors ligne

C'est le cas le plus défavorable. Des secrets doivent être mémorisés et protégés par logiciel dans l'application de paiement du smartphone. Le terminal de paiement ne peut vérifier la validité de la transaction.

On est dans un mode « sans contrôle ».

img
img
Non connecté au réseau mobile, en ligne

Des secrets doivent être mémorisés et protégés par logiciel dans l'application de paiement du smartphone. Le terminal peut vérifier la validité de la transaction à travers sa demande d'autorisation.

On est dans un mode « simple contrôle ».

img
img
Connecté au réseau mobile, hors ligne

Le point positif de cette architecture est qu'aucun secret de paiement n'a besoin d'être mémorisé dans l'application de paiement du smartphone.

Selon l'architectures, on peut être dans un mode « double contrôle » ou « simple contrôle ».

Je ne suis pas certain que le mode « double contrôle » soit réalisable avec les applications de paiement (VISA, MASTERCARD...) utilisées en 2015. L'idée est de faire calculer un TC (Transaction certificate) dans le cloud, suite à des contrôles réalisés par le serveur HCE en collaboration avec le système de vérification bancaire. Le TC qui est le résultat d'un calcul RSA peut être vérifié par le TPE.

Le décor est désormais planté et les différentes hypothèses d'environnement sont énoncées. On a vu qu'elles n'étaient pas toutes égales vis a vis de la sécurité.

Le cas où ni le smartphone, ni le terminal de paiement sont connectés lors de la transaction n'est en pratique jamais évoqué. Tout le monde admet que cette architecture est trop risquée. Je n'entrerai pas dans l'analyse qui justifie cet a priori : la lecture des paragraphes qui suivent et qui portent sur la sécurité des autres architectures donne en creux suffisamment d'informations pour disqualifier celle-ci.

Le cas ou le smartphone n'est pas connecté mais le terminal l'est était en 2014 la solution qui était la plus souvent évoquée, pour les raisons indiquées précédemment. Dans cette architecture, il est nécessaire :

Tout ça, en logiciel, dans un système d'exploitation plus ou moins maitrisé et dans des smartphones aux caractéristiques variables pouvant provenir des quelques dizaines de fournisseurs de la planète.

Le cas ou le smartphone est connecté durant la transaction n'était pas la solution privilégiée en 2015. Toutefois, l'amélioration de la couverture du réseau mobile pourrait rendre cette solution plus attrayante avec le temps. Elle simplifie considérablement la sécurisation du logiciel dans le smartphone et limite la surface d'attaque

Je n'ai jusqu'à présent pas évoqué la protection du serveur HCE ni du système de vérification bancaire. Les enjeux sont éventuellement énormes en matière de sécurité et l'actualité depuis de nombreuses années nous montre régulièrement combien ces systèmes complexes et centralisés sont vulnérables. Mais ce cours est avant tout consacré aux éléments sécurisés. Rentrer dans le détail de la sécurisation des systèmes d'information en général nécessiterait un autre cours à part entière. Je ferai donc l'hypothèse que ces systèmes participant à la mise en oeuvre du HCE sont sécurisés !

Protection des credential

La première idée pour cacher des secrets (qu'il s'agisse de clés, ou d'un traitement ou les deux ensembles) dans un code consiste à le rendre tellement compliqué que sa rétro-analyse rebutera celui qui s'y risquerait. Ces techniques sont utilisées depuis longtemps. Pour ce qui me concerne, mes premières expériences dans ce domaine remontent à la fin des années 1970. Elles se sont considérablement développées et professionnalisées depuis, avec comme premières applications civiles, la protection contre la copie de logiciels (on cache dans le code le mécanisme de protection pour qu'il ne soit pas contournable) et la protection des droits d'auteurs sur les contenus (DRM pour Digital Right management). Du coté sombre, ces techniques sont également utilisées pour compliquer l'analyse des logiciels malveillants (malware) ou leur détection par des antivirus.

Si l'on compare ces techniques avec la protection matérielle, on peut faire une analogie car finalement, une partie de la protection d'un composant électronique sécurisé vient de sa difficulté à le reverser. Mais la comparaison s'arrête vite. Les moyens à mettre en œuvre pour rétroingénierer un composant n'ont rien à voir avec ceux utilisés pour le logiciel. Un FIB coûte plusieurs millions d'euros et il faut parfois des mois pour trouver quelque chose d'exploitable pour un attaquant (Pour ceux que ça intéresse, voir l'attaque de Tarnovsky sur le SLE66 sur Youtube). Les outils disponibles pour le retro ingénierie logicielle sont peu couteux, nombreux et la compétence disponible est beaucoup plus partagée.

Lorsqu'une protection élevée contre la rétroingénierie est recherchée, invariablement, on associe obfuscation logicielle et protection matérielle. Dans le cas d'un smartphone et selon l'hypothèse retenue ici, on ne dispose pas de protection matérielle. La conséquence est qu'il sera nécessaire de changer régulièrement de technique d'obfuscation et que les secrets protégés devront avoir une durée de vie limitée. Cela n'est pas sans conséquence sur la complexification de la gestion du système.

La cryptographie en boite blanche est une autre contremesure permettant de noyer un secret dans un code logiciel en rendant très difficile sa récupération. Le document « cryptographie en boite blanche » paru dans la revue MISC et dont je recommande la lecture, attribue la première publication sur ce thème à Stanley Chow, Philip A. Eisen, Harold Johnson, and Paul C. van Oorschot en 2002. Cette technique est controversée du fait de faiblesse de ses fondements théoriques mais il apparaît que dans la pratique, il existe des implémentations de cryptographie en boite blanche qui sont difficile à attaquer et que l'approche n'est pas sans intérêt. Ceci-dit, le problème d'une approche purement basée sur la pratique est que souvent, son effondrement, quand il se produit, est brutal et spectaculaire.

La cryptographie en boite blanche est généralement associée à l'obfuscation pour compliquer encore plus le travail de l'attaquant.

Mais est-il nécessaire de retrouver les secrets cachés par l'obfuscation pour réussir une attaque ? En pratique, pas toujours. Quelqu'un souhaitant utiliser frauduleusement des credentials pourra se contenter de récupérer l'intégralité du logiciel d'une victime et le faire exécuter dans son propre environnement, sans chercher à comprendre comment il fonctionne ni quels sont les valeurs des secrets.

Ce problème est également bien connu. Les solutions imaginées pour le résoudre consistent à intégrer dans le logiciel des mécanismes caractérisant l'environnement (par exemple, n° de series de sous-ensembles, identifiants fixes mais liés à un environnement donné…). Depuis les années 2000, on appelle cela, fingerprinting d'équipement par analogie avec la biométrie. Mais là encore, les techniques de virtualisation permettent de contourner plus ou moins facilement ces contre-mesures. On mets alors en place d'autres « trucs » imaginés au cours du temps pour compliquer un peu plus la vie de l'attaquant :

Tous ces « trucs » sont plus ou moins facilement contournables. Il ne s'agit que de mesures de défense en profondeur visant à freiner l'attaquant entre le changement de deux versions de logiciels. Il est difficile d'en mesurer la résistance, à part tenter de les contourner lors d'évaluations. Or, les évaluations sont coûteuses et il n'est probablement économiquement pas envisageable d'en faire au rythme du changement de versions. Cette contrainte n'est pas applicable à l'attaquant. Pour ce dernier, il lui suffit de trouver une seule attaque efficace parmi celles qu'il peut tenter pour gagner.

Je finirai sur ce point (sachant que le sujet est loin d'être épuisé) par les techniques dites « antirootkit » ou « antijailbreak » ou plus généralement, les techniques permettant de détecter qu'un système d'exploitation n'est pas compromis. Leur efficacité est sujette à caution et ne doivent pas être considérées comme des mesures de lutte contre des logiciels malveillants (ou alors, ils sont très naïfs) mais plutôt comme des mesures permettant à un utilisateur « standard » de s'apercevoir qu'il a mis lui-même son système (smartphone, ordinateur) dans un état dangereux. C'est seulement à ce titre qu'elles doivent être considérées comme utiles.

En effet, ces techniques, pour fonctionner, ne peuvent que s'appuyer sur les informations retournées par l'environnement dans lesquelles elles s'exécutent. Un logiciel malveillant fera en sorte que ces informations correspondent à ce qu'attendent ces contre-mesures pour ne pas être détecté.

Comme on le voit, la notion d'élément sécurisé en logiciel est problématique et suppose la mise en place d'un processus technico-organisationnel assez complexe (et probablement coûteux) si l'on veut viser un niveau de sécurité équivalent à celui d'un élément sécurisé matériel.

Authentification de l'utilisateur

En France, dans le cas des paiements EMV par cartes à puce en mode contact, l'authentification du porteur est obligatoire et se fait par présentation d'un code porteur sur un clavier protégé d'un terminal de paiement.

En sans contact par carte, le système de paiement impose l'authentification du porteur au delà d'un certain montant (unitaire ou cumulé) ce qui oblige à repasser en mode contact.

Il doit être possible de faire mieux avec un smartphone, du fait des interfaces qu'il propose.

Pour commencer, on peut vouloir imposer un acte volontaire pour autoriser le paiement sans contact, ce qui est un plus par rapport aux cartes émises dans les années 2010. Cet acte volontaire peut être un simple accord (appuie sur un« ok »présenté à l'écran ou s'apparenter à une authentification (vérification d'un caractère biométrique), voire, être similaire à l'authentification habituelle, via la saisie d'un code porteur sur le smartphone lui-même.

Selon le type d'authentifiant et l'architecture (connecté au cloud lors du paiement ou pas), la vérification de l'authentifiant peut se faire de différentes façon.

Authentification par PIN, mobile non connecté au cloud lors du paiement

La saisie est faite sur un clavier virtuel du smartphone ce qui créé le risque de sa capture par un logiciel malveillant ou par hameçonnage (phishing) lors de la saisie.

La vérification peut se faire de plusieurs façon :

La question est de savoir ce que l'on fait si le PIN entré est faux. On peut gérer un compteur interne bloquant l'application après plusieurs codes faux mais s'agissant de logiciel, il est possible à un attaquant de recharger l'application avant contrôle du PIN, voire, de trouver le compteur (par comparaison entre l'image de l'application avant et après la saisie) ce qui facilite les attaques ultérieures.

Le mieux serait sans doute que l'application se comporte comme si le code était correct mais de faire le calcul du TC avec une clé erronée. Ainsi au moment du paiement, le système de vérification bancaire constatera que le TC est faux et rejettera la transaction.

Si l'on adopte cette stratégie, le plus simple est alors de chiffrer la clé servant au calcul de l'ARQC par le PIN. Supposons que la clé courante Ki de l'ARQC (et connue du système bancaire de vérification) soit stockée dans un credential sous la forme Kic = AES(Hash(PIN), Ki). Lorsque le smartphone réalise le paiement, il retrouve Ki = AES-1(Hash(PIN saisi), Kic). Si le PINsaisi est égal au PIN, alors, Ki sera égal à Kic et le calcul de l'ARQC sera correct.

De cette façon, les tentatives de trouver le PIN par force brute sont nécessairement limitées puisqu'à chaque fois, il faut faire une tentative de paiement pour savoir si le PINsaisi était correct ou pas. On peut même imaginer qu'au bout d'un certain nombre de tentatives en échec, le système de vérification considère qu'il s'agit d'une tentative d'attaque et désactive le paiement par mobile pour le compte considéré.

Authentification par PIN, mobile connecté au cloud lors du paiement

Les problèmes liés à la saisie du PIN sont les mêmes que précédemment. La différence essentielle est que le PIN peut être transmis au serveur HCE dans le cloud qui effectue la vérification. Si le PIN est correct, il acceptera de réaliser la transaction EMV (et à tout le moins, de calculer un TC). Sinon, il refusera et pourra bloquer le paiement par mobile au bout d'un certain nombre d'essais en échec.

Authentification par biométrie

L'hypothèse faites ici est que la biométrie ne peut être vérifiée que localement par le smartphone (dans certains pays, on peut envisager des vérifications centralisées mais en France, en 2015, ce mode de fonctionnement n'était pas en vogue, CNIL oblige…).

La biométrie pose plein de problème dont la non révocabilité et la résistance des capteurs aux leurrage. Toutefois, l'objet de ce paragraphe n'est pas de s'étendre sur ces sujets mais de voir comment on peut utiliser le résultat d'une comparaison biométrique pour déclencher le paiement HCE de façon sécurisée.

La méthode naïve est la suivante :: l'application de paiement utilise un résultat (OK, KO) de l'authentification biométrique proposée par le smartphone. Avec cette méthode, un attaquant ayant accès à l'application de paiement du smartphone (et/ou à l'OS…) pourra forcer le résultat à OK et payer.

Une méthode plus subtile consiste à disposer d'un élément sécurisé qui fait la comparaison biométrique et qui renvoie, non pas OK ou KO mais une valeur secète (PIN, clé) qui est soit choisie par l'uilisateur, soit déterminée par le système. On peut alors se trouver dans un cas très proche de celui du paragraphe précédent. En cas de compromission, de cette valeur, il suffit de la changer (et prévenir le serveur HCE de ce changement). C'est l'approche que propose la FIDO alliance et qui en 2015, semble avoir été implémentée sur Androïd (au moins, pour le Samsung Galaxy S5 et l'authentification sur Paypal).

img
FIDO UAF, architecture générale

La FIDO alliance propose un cadre universel pour l'authentification ( Universal Authentication Framework (UAF), [archive]) qui permet de réaliser une authentification cryptographique uniforme entre un client et un serveur quelque soit le moyen d'authentification utilisé coté client. Cette authentification cryptographique nécessite un échange de clés lors de l'enrôlement. Dans le cas de la biométrie, cette clé sera générée par le client une fois l'utilisateur enrôlé localement. Le schéma ci-dessus montre l'architecture technique coté client et serveur. Le schéma ci-dessous montre le principe de l'enrôlement.

img
FIDO UAF, enrôlement

Pour une transaction EMV, cette approche pourrait être utilisé telle quelle dans une architecture connectée au cloud mais devra probablement être aménagée pour une architecture non connectée au cloud

Authentification du smartphone

[Rédaction en cours]

Pistes pour améliorer la sécurité des solutions HCE logicielles

En 2014, quelques pistes étaient évoquées pour renforcer la confiance dans la sécurité logicielle d'une impplémentation HCE :

On notera que ces deux pistes s'appuient sur des éléments matériels...

Paiement mobile Secure Element embedded

img
Paiement avec élément sécurisé embarqué

Entre la carte USIM et le HCE logiciel existe une voie intermédiaire consistant à mettre l’application de paiement dans un élément sécurisé matériel embarqué (soudé) dans le smartphone. Du point de vue de la sécurité intrinsèque, tout est possible :

Un exemple de solution avec élément sécurisé est proposé par Apple Pay. On lira avec intérêt le document Sécurité d'iOS. Même si certaines questions restent en suspend, l’architecture décrite est particulièrement aboutie pour un appareil grand public. En 2015, aucun autre fabricant ne proposait une solution aussi cohérente du point de vue de la sécurité.

Pour finir, l’avis (assumé) de l’auteur est qu’il y a un monde entre la sécurité d'une solution purement logicielle et celle d'une solution avec élément sécurisé. On peut ensuite se demander s’il vaut mieux une carte USIM ou un élément sécurisé embarqué à la « Apple Pay ».

La technique et la sécurité ne sont que des éléments de réponse marginaux. La vraie question est de savoir si l’on préfère dépendre d’un opérateur de téléphonie mobile ou d’un fabricant de téléphone.

LE PORTE-MONNAIE ÉLECTRONIQUE

L'idée du porte-monnaie électronique (PME) est assez ancienne mais les réalisations concrètes ont eu du mal à voir le jour. Avant d'entrer dans le vif du sujet, il est nécessaire de bien définir ce que l'on entend par PME.

Porte-monnaie, porte-jetons

Une confusion courante consiste à assimiler les techniques de porte-jetons aux techniques de porte-monnaie. Un porte-jeton est un dispositif rechargeable ou non contenant des unités généralement prépayées et de valeur constante destinée à payer l'accès à un service généralement unique et identifié. Dans certains cas, plusieurs services sont accessibles mais cela pose des problèmes de tarification : Il est nécessaire que tous les tarifs pratiqués soient des multiples de l'unité de base qui est égale au jeton. Le meilleur exemple de porte-jetons est la carte téléphonique (Télécarte en France).

Le porte-monnaie est un dispositif généralement rechargeable contenant une certaine valeur correspondant à un montant prépayé. La principale différence avec le porte-jetons vient du fait qu'il est possible de payer un montant quelconque inférieur ou égal à la valeur courante du porte-monnaie, chaque paiement venant décrémenter son solde. L'utilisation du porte-monnaie peut s'envisager aussi bien dans des environnements privatifs que publics et c'est là qu'il prend tout son intérêt.

Principe du porte-monnaie électronique

Bien que plusieurs schémas d'utilisation soient envisageables, les principaux projets de PME ont été conçus pour permettre le paiement de petits montants (inférieurs à quelques centaines de francs) dans les commerces, pour le téléphone, les parcs de stationnements... Le porte-monnaie se présente donc comme un substitut de la monnaie fiduciaire ce qui ne va pas sans poser quelques problèmes, seul l'Etat ayant le droit de « battre monnaie ».

Le premier projet de PME est né en France à l'initiative de la Poste, des Caisses d'Epargne et de la Caisse des dépôts.

Les acteurs en présences étaient :

Les moyens techniques utilisés étaient :

Point de vue du porteur

Le porteur disposait d'un PME dont le solde (montant courant du porte-monnaie) était nul au départ. La première opération qu'il devait réaliser pour pouvoir utiliser son porte-monnaie était de le (re)charger.  Le (re)chargement du porte-monnaie consistait à transférer une certaine somme d'argent (le montant du chargement) de la banque du porteur vers une banque de dépôt et d'ajouter au solde du PME le montant de ce chargement. Typiquement, cette opération était réalisée à partir d'un DAME (Distributeur Automatique de Monnaie Electronique) à l'aide d'une carte de paiement traditionnelle (carte bancaire par exemple) et correspondait à un retrait d'argent. On note au passage que le PME ne contenait pas d'argent au sens propre du terme mais la preuve qu'il y avait eu un transfert d'argent entre la banque du porteur et la banque de dépôt : le PME ne manipulait donc pas de monnaie mais plutôt une reconnaissance de dette (vis-à-vis de la banque de dépôt).

Le paiement d'une prestation consistait à débiter le solde du PME de l'acheteur (le porteur) et à créditer le PME du vendeur (le commerçant). Cette opération était réalisée à l'aide de TPE (Terminal de Paiment Electronique), chaque TPE contenant l'équivalent d'un PME (celui du commerçant).

Point de vue du commerçant

Le commerçant était équipé d'un TPE contenant l'équivalent d'un PME. A chaque paiement, le solde du PME du commerçant était crédité du montant débité dans le PME du porteur. En fin de journée, le TPE du commerçant se mettait en liaison avec le centre gestionnaire du système PME. Le PME du commerçant était débité au profit du super PME du centre gestionnaire. On notait au passage les références du commerçant. La dernière opération consistait à demander un ordre de mouvement entre la banque de dépôt du système PME et la banque du commerçant correspondant au solde transféré entre le PME du commerçant et celui du centre gestionnaire.

Point de vue du centre gestionnaire

En plus de la gestion des PME, des porteurs et des commerçant, le rôle du centre gestionnaire consistait à gérer des ordres de mouvements entre les banques des porteurs et la banque de dépôt et entre la banque de dépôt et les banques des commerçants. En simplifiant, le centre gestionnaire se rémunérait pour partie par des commissions sur les opérations réalisées à l'aide du PME (rechargement, achats...) et par les intérêts que rapportait le total des dépôts effectués dans la banque de dépôt.

Complémentarité carte-bancaire/PME

A première vue et pour un néophyte, le système paraît complexe et redondant avec le paiement classique par carte bancaire. Toutefois, dans les années 1990, il présentait plusieurs avantages notables sur ce dernier dès lors qu'il s'agissait de payer de petits montants :

une transaction par carte-bancaire a un coût relativement élevé qui rend problématique le paiement de petites sommes (en France, de l'ordre de 100 à 150F en 1994). Ce coût s'explique entre-autre par la nécessité de traiter chaque opération unitairement alors que dans le cas du PME, les opérations sur les petits montants sont cumulées (dans le TPE du commerçant) et seules les ordres de mouvements (banque porteur vers banque de dépôts, banque de dépôt vers banque commerçant) correspondant à des montants élevés sont traitées unitairement.

Cette complémentarité avait été envisagé dans le projet de la Poste, Caisses d'Epargne et Caisse des Dépôts et avait donné lieu à une étude menée par SE3P (Société d'Etude pour la Promotion du Paiement de Proximité) pour l'utilisation de la carte B4B0' à la fois en PME et en carte bancaire.

Intérêts pour les porteurs et commerçants

L'intérêt évident pour les porteurs et les commerçants (ou plus généralement, les prestataires de service) est l'absence de manipulation de la monnaie (en particulier partout où il faut faire l'appoint et où il faut la transporter) et la rapidité de la transaction.

Principales difficultés de mise en oeuvre

Il existe (au moins) deux difficultés majeures pour la mise en oeuvre d'un tel système. La première est liée à la sécurité : il ne doit pas être possible de créer de la fausse monnaie. Toute la sécurité du système repose sur les procédures de sécurité (utilisant des mécanismes cryptographiques) entre les PME et sur le fait que la carte est réputé physiquement inviolable. Il s'agit là d'un problème de confiance dans le principe même de la CAM et c'est la raison officielle qui a fait échouer ce premier projet en France.

La deuxième difficulté est plus de nature commerciale : une partie des banques (celles qui n'étaient pas à l'origine du projet) voyaient s'échapper une partie des transactions en circulation au profit de la banque de dépôt qui, horreur absolue, était alors gérée par des banques à l'époque liées à l'Etat. Comme les banques qui n'étaient pas dans le projet étaient également celles qui avaient le plus de commerçants qui leur étaient affiliés, leur soutien était indispensable au lancement du projet. Elles ne le donnèrent pas.

Pemière Conclusions

Il semble néanmoins que les travaux faits à l'époque ne furent pas perdus pour tout le monde. Des projets de porte-monnaie se développèrent à l'étranger dont celui de la « GeldKarte » en Allemagne, qui nous revint en France quelques années plus tard sous la forme du porte-monnaie Monéo. VISA eut également un temps le projet d'un tel porte-monnaie.

A noter également en France l'existence du projet Modeus, une autre tentative de PME (dans lequel on retrouvait la Poste et la RATP) démarré à la fin des années 1990 et qui fut finalement abandonné au début des années 2000 au profit de Monéo. Il en fut de même pour Mondex, projet de carte lancé au Royaume-uni qui fut adopté par le Crédit-Mutuel à une époque.

Monéo

A la fin des années 1990, le consortium BMS (Billetique Monétique Service), composé des principaux acteurs bancaires (cette fois-ci) plus quelques autres lance le projet Monéo. A cette occasion est également créée la société SFPMEI (Société Financière du Porte Monnaie Electronique Interbancaire), elle même composée des principaux acteurs bancaires étant la société financière chargée de garantir la valeur des dépots fait sur le PME (BMS étant l'opérateur qui développe et commercialise le système).

Très vite, les performances de Monéo déçoivent et ne répondent pas aux espoirs des initiateurs du projet, du moins, si l'on en croit la presse et d'autres sources : en 2010, on citait le nombre de 2 millions de porteurs et 200000 commerçants. Revenons au début de l'histoire pour tenter de donner quelques clés permettant de comprendre ce demi-succès (soyons optimiste).

En 1990, les conditions du succès d'un tel projet avaient été formulées dans le cadre d'une étude réalisée par la société SE3P (je cite de mémoire) :

  1. Coût de la transaction : celle-ci devait être compétitive par rapport au paiement par carte bancaire qui a l'époque était élevé (plusieurs francs). l'automatisation du mécanisme de paiement était une des conditions pour faire baisser le coût de la transaction du PME :
    • La sécurité des échanges est assurée par des moyens cryptographiques à toutes les étapes du paiement par échange d'argent électronique entre des PME afin de simplifier la gestion technique du système. Ce point a été pour l'essentiel repris dans Monéo.
    • Seul, le solde global du porte monnaie est remonté au tiers de dépôt et non pas les transactions unitaires (ce qui implique l'anonymat du PME, sujet qui a fait l'objet d'un long débat).
    • La transaction doit être rapide par rapport à un paiement par carte bancaire classique. Ce point est en particulier obtenu du fait qu'il n'y a pas de présentation de code porteur et que s'agissant d'un prépaiement, les opérations de contrôle de la solvabilité du porteur peuvent être réduites. Cet avantage pourrait être remis en cause avec la montée en puissance des cartes de paiement sans contact pour lesquelles la présentation du PIN n'est plus systématique (que la transaction soit faite par carte ou via un téléphone portable).
    • Le principe de compensation est de nature à réduire les coûts de compensation entre établissements bancaires
  2. Sécurité du système : il ne doit pas être possible de créer de la fausse monnaie (c'est le risque majeur du système)
  3. la charge supportée par le commerçant doit être faible, voire, nulle pour favoriser l'acceptation du système
  4. Le système doit être rentable. c'était le point dur de l'étude. Celle-ci montrait que la simple rémunération du compte de dépôt était insuffisante pour financer les coûts de fonctionnement et comme il était nécessaire de limiter les frais pour le commerçant, les marges de manoeuvres étaient réduites. Il fallait donc trouver d'autres sources. Une de celles imaginées était de proposer au porteur une assurance perte-vol sur le contenu de son porte-monnaie. Les simulations faites à l'époque montraient qu'il s'agissait de la piste la plus prometteuse pour assurer les financements nécessaires... Ce qui n'est « intellectuellement » pas très satisfaisant.

D'autres éléments sont venus perturber la donne depuis 1990. En particulier, le coût des télécommunications a drastiquement baissé rendant possible la mise en oeuvre d'autres approches : le PME initial fonctionnait pour l'essentiel « hors ligne », la sécurité étant gérée localement par les cartes (ou les SAM (Security/Suscriber Application Module) des commerçants). A l'époque, le simple fait de se connecter quelques part via le RTC (seul moyen pour les petites structures) coûtait quelques dizaines de centimes. Avec le modèle économique de l'Internet, ce coût est généralement globalisé dans un forfait qui pré-existe pour d'autres raisons chez un petit commerçant).

Le coût des transactions par carte bancaires classiques a également baissé et le paiement de petits montants devient envisageables. Ce point avait d'ailleurs été noté comme une évolution probable et problématique pour le PME : dès 1990, il était possible de payer des petits montants par carte bancaire en Espagne (paiement de parking) alors que ce n'était pas le cas (ou rarement le cas) en France. Néanmoins, ce constat laissait prévoir que cela deviendrait possible à brève échéance...

Le paiement par carte bancaire s'est très vite développé en France à partir de la fin des années 1980. Les utilisateurs sont de plus en plus habitués à ce mode de paiement et ne comprennent pas bien pourquoi ils devraient utiliser un autre moyens pour certains paiements. C'est peut-être une des raisons qui a fait que rapidement, Monéo a chercher à s'imposer sur des marchés de niche (paiement des parcmètres, CROUS...) pour lesquels il est plus facile de faire admettre un prépaiement et/ou un système de paiement particulier, proche du paiement privatif.

L'histoire n'est pas terminée. On doit noter que BMS a été repris par le fond d'investissement BlackFin Capital Partners en 2010. Le chiffre d'affaire annoncé de BMS était alors de 10M€. BlackFin Capital Partners visait un chiffre d'affaire de 30M€ en 2015... A suivre disais-je à cette époque.

Et bien, la suite, c'est cette capture d'écran qui clôt le point définitivement. Il provennait de la page http://www.moneo.com/particuliers et voici ce qu'on y trouvait :

img

La carte de santé VITALE

Introduction

En France, l'histoire de la carte santé est presque aussi ancienne que celle de la CAM. Les années 80 à 90 virent l'émergence de plusieurs projets concurrents plus ou moins bien définis. C'est pourtant en Allemagne qu'apparue la première application de carte santé de grande envergure. Après avoir observé les études, expérimentations et errements des projets français, les allemands définirent leur propre projet. Quatre ans après, la carte santé (en logique câblée) était diffusée auprès de 74 millions d'habitants (sur 80 millions d'habitants) et l'Allemagne faisait alors figure de précurseur dans le domaine. Comme l'a dit quelqu'un à l'époque, « la carte santé, les français l'on rêvé, les allemands l'on fait ».

Il faut toutefois relativiser ce succès en rappelant que la carte santé allemande n'avait pas les mêmes ambitions que les cartes santé françaises. Simple identifiant de l'assuré social et de l'état de ses droits, elle ne servait qu'à remplir des formulaires qui étaient ensuite traités par un système informatique classique. Cette relative modestie dans les fonctionnalité s'expliquait par un système législatif très strict quant à la protection des données et des personnes, aucune information médicale ne pouvait être inscrite dans la mémoire de la carte.

Le coût du projet de la carte santé allemande a été estimé à 1,4 milliard de francs et aurait réduit les frais administratifs de 35%.

Le projet Sesam-Vitale

En 1996, le rapport Rosemaryn définissait le projet Sesam-Vitale ainsi :

« le projet consiste, dans ses principes, à faire saisir à la source par les professionnel de santé (médecins, pharmaciens, infirmières, etc.) sur un poste de travail informatique (un micro-ordinateur) les informations figurant sur les feuilles de soins papier et à transmettre directement ces informations via un réseau de télécommunication vers les caisses. C'est la partie « Sesam » (Système Expérimental (ou Electronique selon les sources) de Saisie de l'Assurance Maladie).

L'assuré est identifié administrativement par une carte à mémoire dénommée « carte Vitale » sur laquelle sont enregistrés ses droits à remboursements. Le professionnel de santé est lui identifié par une autre carte à mémoire dite CPS (Carte Professionnelle de Santé) ».

Le rapport indique ensuite qu'il s'agit à la base d'un projet technique visant à améliorer la productivité des caisses d'assurance maladie.

Je cite ce rapport mais j'aurai pu en citer bien d'autres comme par exemple, celui produit l'année suivante, en 1997 par le Conseil Supérieur des Systèmes d'Information de Santé. Le projet Sesam-Vitale a en effet fait l'objet de nombreuses critiques et doutes qui ont suscité rapports et débats et son abandon pur et simple a été évoqué à plusieurs reprises.

Toujours en 1996, certains proposent l'abandon de la carte à microprocesseur et envisagent d'adopter une solution « à l'allemande » avec une carte en logique câblée. Un comble lorsqu'à cette même époque, les allemands envisageaient l'évolution de leur système vers une carte à microprocesseur.

Pourquoi tant de critiques ? L'histoire semblait pourtant avoir bien commencé.

Au début des années 1980, dans la foulée des télécartes et du lancement des cartes bancaires, plusieurs projets voient le jour pour proposer la mise en place d'une carte à puce de l'assurée social. En général, l'objectif est de permettre à chacun de porter sur lui son dossier médical afin que les personnels médicaux à qui il peut avoir à faire aient rapidement et facilement accès au profil du porteur. Cela part plutôt d'une bonne intention.

Evidemment, la confidentialité des informations contenues dans la carte nécessitait la mise en place d'un mécanisme de contrôle d'accès solide. Une solution proposée était que la carte de l'assurée ne puisse être lue et mise à jour qu'après avoir authentifié la carte d'un professionnel de santé.

Mais la mise en œuvre d'un tel mécanisme semble complexe à l'époque et pose des questions sur la confidentialité, la disponibilité des informations, etc.

Petit à petit, le projet qui émergera (Sesam-Vitale), concentrera donc ses efforts sur la gestion administrative du système d'assurance maladie. Cette posture génèrera des critiques de plus en plus acerbes de la part de la profession médicale qui ne verra qu'un système lui apportant des contraintes sans les gains espérés d'un point de vu médical. Sans compter une certaine hypocrisie dans la communication : on communique sur l'amélioration de la prise en charge des assurés sociaux et de l'amélioration du parcours médical (ce qui est vrai dans une certaine mesure) alors que l'objectif est clairement d'améliorer la productivité dans le traitement des feuilles de soin en passant par une baisse des effectifs. Mais les politiques ne peuvent tenir ce type de discours et on en entendra qui tout en soutenant le projet, contesteront ouvertement qu'il vise cet objectif.

Sur le plan technique, le projet va également être la cible de nombreuses critiques, en particulier, sur le choix de technologies dépassées et le nombre de défis à relever simultanément. Résultat, en 1998, le projet qui a démarré depuis une décennie est à peine abouti et a déjà coûté 470MF (environ 75M€). On estime à cette date qu'il faudra encore 3 à 4 milliards de francs (450 à 600M€) pour le mener à bien. Les parlementaires chargés d'une mission sur ce projet diront « nous sommes passés d'un optimisme béat à un pessimisme béant ».

Pour être plus positif, je vous propose ci-après un résumé de quelques informations vu du coté du GIE SESAM-VITALE, créé en 1993 pour gérer le projet. Les principales étapes du projet jusqu'en 1998 (plaquette du GIE de 1997)  :

C'est finalement à partir de 1998 que démarrera le déploiement à grande échelle du système Sesam-Vitale qui se poursuivra jusqu'au début des années 2000.

Contenu de la carte Vitale 1

Nom et prénom de l'assuré
Numéro de sécurité sociale
Identité des ayants droit
Régime de protection sociale
Caisse de sécurité sociale
Couverture de base et éventuellement complémentaires
Taux de prise en charge

On pourra aussi consulter l'article très complet de Wikipedia sur le sujet ainsi que les liens suivants qui donnent beaucoup plus d'informations sur le projet que cette courte introduction :

www.ma-mutuelle-sante.fr/article-carte-vitale-1-17.html
http://sesam-vitale.chez-alice.fr/csvrss.htm

L'affaire Crêteaux

Le monde bancaire avait eu son affaire Humpich, le monde de la santé eu son affaire Crêteaux. Si vous voulez en savoir plus, vous pouvez aller sur ce site dont je donne un extrait :

« L'affaire a fait grand bruit cet été : un informaticien (Jérôme Crêteaux) a démontré l'existence d'une faille de sécurité sur la carte Vitale, permettant notamment d'utiliser de fausses cartes. Le Groupement d'Intérêt Economique Sésam-Vitale déclare aujourd'hui que cette faille sera définitivement corrigée à partir du 2e trimestre 2006.

Date : 13 décembre 2005
Source : APM
 »

Zoom sur les cartes Vitales

Parmi les choix techniques sujets à contestation cités dans certains rapport, je ne citerai que le cas de la carte étant donné l'objet de ce cours.

Pour des raisons de timing (après 10 ans…), la carte retenue sera finalement une ancêtre : il s'agit d'une carte Bull utilisant le masque M9. Elle est commercialement connue sous le nom de carte SCOT. Qu'a-t-elle de particulier ? Il s'agit en fait d'une famille de cartes dérivée de la carte M4. Elle en reprend l'architecture générale mais est proposée avec plus de mémoire, en E²PROM pour certaines, et avec deux algorithmes cryptographiques possibles : le TELEPASS et le DES.

Comme elle a plus de mémoire, les concepteurs ont introduit un ordre de recherche dans la mémoire qui permet d'éviter de lire toute la carte (ou presque) pour trouver une information. Il s'agit en fait d'un succédané d'une carte qui avait été conçue pour le domaine bancaire (a l'époque où il était basé sur la carte M4) et qui s'appelait M4-B1 ou B4-B1 (je dois faire partie des rares à m'en souvenir). Cette carte ne sera jamais émise.

img

La carte M9, connue dans le cas présent sous le nom de carte Vitale 1, ne devait faire qu'assurer la transition avant de passer à la carte Vitale 2 permettant théoriquement d'accueillir un dossier médical et d'autres fonctionnalités sécuritaires.

Pour ce qu'on lui fait faire, elle est déjà sur-dimensionnée. Une simple carte en logique câblée à l'allemande aurait pu suffire.

La carte Vitale 2 aurait du voir le jour avant 2000. En pratique, le masque développé par Schlumberger sera abandonné. Finalement, c'est la société Sagem (devenue Morpho) qui remportera le marché de la Vitale 2. Mais pour éviter de créer une rupture, elle comportera une zone de compatibilité permettant de fonctionner selon les spécifications de la carte M9.

L'article sur le lien qui suit s'en étonne : http://www.crashdebug.fr/index.php/securite-topmenu/3838-cloner-la-carte-vitale-2-enfantin

On aura donc une carte haut de gamme, implémentant les spécifications IAS (Identification, Authentification, Signature) dans sa version « premium », développé sous l'égide du GIXEL (association qui regroupe les principaux acteurs français de la carte) ainsi que la spécification M9 et l'application Vitale 2. Voici un aperçu du contenu de la carte tel qu'on peut le trouver dans un rapport de certification de l'ANSSI (www.ssi.gouv.fr, certificat 2006-17).

img

L'application ADELE correspond à la spécification IAS.

Bel objet, n'est-il pas ? Sauf que pendant longtemps, (peut-être encore à la date de rédaction de ce paragraphe en 2013), l'application utilisée restera le masque M9 d'origine. C'est dommage car en pratique, chaque français (enfin, pas moi, ma carte date de 1998), dispose théoriquement d'une carte qui non seulement permet de mettre en œuvre le système Sesam mais aussi, de la signature, de l'authentification, etc. pour tous les e-services.

Alors que certains se plaignaient que la carte d'identité avec sa fonction IAS n'avait toujours pas été émise en 2013, limitant théoriquement le développement sécurisé des e-services, cette même fonctionnalité était proposée dans la carte Vitale 2 largement diffusée.

Si vous voulez en savoir plus sur la carte M9, rendez-vous dans la section travaux pratiques de ce cours.

LA CARTE SIM

Représentant plus de 70% et plus de 4 milliards des cartes émises en 2011, la carte SIM (Subscriber Identity Module) représente un indéniable succès pour cette industrie et pour cette invention.

Le format le plus connu pour cette carte n'est pas celui de la carte bancaire (trop grand) mais celui nommé ID-000 dans la norme ISO7816-1 (voir chapitre Normalisation).

img

Elle a été conçue pour stocker des informations propres à un abonné d'un réseau GSM et dérivés (UMTS) et assurer l'identification et l'authentification de cet abonné sur le réseau. Il s'agit donc d'un élément de sécurité dans le téléphone ou l'équipement de communication qui l'utilise.

L'identifiant de l'abonné est nommé IMSI pour International Mobile Subscriber Identity dont la spécification est donnée par la recommandation E.212 de l'UIT (Union Internationale des Télécommunications).

img

L'authentification est réalisée à l'aide d'un algorithme cryptographique (A3), la confidentialité des échanges étant réalisées par d'autres algorithmes (A5/1, A5/2, A5/3), un algorithme de génération de clés (A8) permet de générer une clé de session. Ces algorithmes sont de type à « clé secrète » et sont plus ou moins confidentiels (ils sont censés être secrets). Chaque carte SIM comporte une clé Ki unique associée à un IMSI à partir de laquelle l'authentification de la carte est réalisé (SRES = A3(Ki,RAND) où RAND est une valeur aléatoire et SRES, le résultat du calcul) et une clé de session Kc est générée (Kc = A8(Ki, RAND).

Pour le reste, la carte SIM s'appuie sur les normes ISO7816 dont la 7816-4 pour les structures de données et certains ordres. La norme ETSI TS 102 221 V8.2.0 - Technical specification, smart-cards UICC-Terminal interface, physical and logical characteristicsfournit la description physique et logique de l'Universal Integrated Circuit Card utilisé pour accueillir les fonctionnalités de l'application SIM dont les spécifications sont données par 3GPP (3rd Generation Partnership Project; Technical Specification Group Terminals; Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface).

La carte SIM comporte plusieurs répertoires (DF) et fichiers (EF) qui contiennent les informations propres à l'applications comme ledéjà nommé IMSI mais également, toutes sortes d'informations de gestion ainsi que les des fichiers pour les répertoires téléphoniques et les SMS. Le tableau ci-dessous donne un aperçu des fichiers que l'on peut y trouver ainsi qu'une brève description de leur contenu.

identification du fichier Description
'2F05' Extended Language preference
'2FE2' ICC identification
'4F20' Image data
'4Fxx' Image Instance data Files
'6F05' Language preference
'6F07' IMSI
'6F20' Ciphering key Kc
'6F2C' De-personalization Control Keys
'6F30' PLMN selector
'6F31' Higher Priority PLMN search period
'6F32' Co-operative network
'6F37' ACM maximum value
'6F38' SIM service table
'6F39' Accumulated call meter
'6F3A' Abbreviated dialling numbers
'6F3B' Fixed dialling numbers
'6F3C' Short messages
'6F3D' Capability configuration parameters
'6F3E' Group identifier level 1
'6F3F' Group identifier level 2
'6F40' MSISDN storage
'6F41' PUCT
'6F42' SMS parameters
'6F43' SMS status
'6F44' Last number dialled
'6F45' CBMI
'6F46' Service provider name
'6F47' Short message status reports
'6F48' CBMID
'6F49' Service Dialling Numbers
'6F4A' Extension 1
'6F4B' Extension 2
'6F4C' Extension 3
'6F4D' Barred dialling numbers
'6F4E' Extension 4
'6F50' CBMIR
'6F51' Network's indication of alerting
'6F52' GPRS Ciphering key KcGPRS
'6F53' GPRS Location Information
'6F58' Comparison method information
'6F60' User controlled PLMN Selector with Access Technology
'6F61' Operator controlled PLMN Selector with Access Technology
'6F62' HPLMN Selector with Access Technology
'6F63' CPBCCH information
'6F64' Investigation scan
'6F74' BCCH information
'6F78' Access control class
'6F7B' Forbidden PLMNs
'6F7E' Location information
'6FAD' Administrative data
'6FAE' Phase identification
'6FB1' Voice Group Call Service
'6FB2' Voice Group Call Service Status
'6FB3' Voice Broadcast Service
'6FB4' Voice Broadcast Service Status
'6FB5' Enhanced Multi Level Pre-emption and Priority
'6FB6' Automatic Answer for eMLPP Service
'6FB7' Emergency Call Codes

Une autre représentation de l'arborescence de la carte tirée de l'ETSI TS 100 977 est donnée ci-dessous

img

Le chapitre « travaux pratiques » donne quelques exemples d'utilisation de PCCAM pour explorer et décoder le contenu d'une carte SIM.

Le passeport électronique

Le passeport électronique est constitué du passeport papier habituel auquel on adjoint un microcontrôleur sécurisé contenant une application « passeport » conforme aux normes de l'OACI (Organisation de l'Aviation Civile Internationale, en particulier, voir OACI 9303). La particularité de ce microcontrôleur (cette puce) est de dialoguer avec son environnement en mode « sans contact ». Cette puce contient les données d'identification du porteur ainsi que diverses informations biométriques, le tout étant signé par une autorité à l'aide d'un algorithme à clé publique.

En terme de vocabulaire, on parle de « dvLM » (document de voyage lisible à la machine ou « MRTD » pour Machine Readable Travel Document) pour désigner un document officiel (un passeport, un visa, un document d'identité par exemple) émis par un Etat ou une organisation et qui est utilisé par un porteur (vous, moi) pour des déplacements internationaux et qui contient des informations visuelles destinées à être lues par une machine.

On désigne par « application dvLM » les données définissant les fonctionnalités utilisées par la puce du dvLM.

Le passeport de base

Le déploiement du passeport électronique a été accéléré par les USA après les attentats du 11 septembre 2001. L'objectif était de faciliter la lecture des informations contenues dans le passeport et d'en vérifier l'authenticité grâce à une signature électronique. Avec un tel cahier des charges, un simple composant RFID mémorisant les informations d'identification signées est suffisant. On notera que dans cette spécification, les informations contenues dans le passeport ne sont pas considérées comme confidentielles. Le seul objectif de sécurité énoncé consiste à empêcher la fabrication de « faux » passeports, comprendre, la création d'informations d'identification pouvant être considérées comme authentiques. En effet, pour ce faire, il faudrait disposer de la clé privée de signature de l'Etat émetteur qui assure l'authenticité des données.

Par contre, il n'y a pas d'objectif de sécurité visant empêcher la duplication de passeport. Je cite spécifiquement ce point car il a fait l'objet de polémiques initiées par certaines personnes en manque de notoriété pour dénoncer des failles dans la sécurité du passeport électronique.

On notera que ce mécanisme aurait pu ne pas utiliser de puce électronique. Il est possible d'inscrire sur papier le résultat d'une signature électronique et de faire les contrôles de vérification de signature sur un terminal équipé d'une lecture optique avec reconnaissance de caractères. Cela peut sembler un procédé archaïque mais en pratique, la lecture optique est déjà mise en œuvre dans les contrôles aux frontières pour lire la bande dite « MRZ », (Machine Readable Zone) imprimée dans le passeport.

Ce type de mécanisme de sécurité reposant sur la vérification de la signature d'une donnée connue et fixe est appelée « authentification statique ». Elle est utilisée dans toutes sortes d'applications, à commencer par les cartes bancaires françaises émises au milieu des années 1980. C'est d'ailleurs le nom que l'on a retenu pour désigner le premier mécanisme de sécurité du passeport électronique : PA pour Passive Authentication.

Rapidement, il est apparu aux yeux de certains que cette spécification pouvait porter atteinte à des principes de respect de la vie privée, et ce, pour plusieurs raisons :

Introduction d'un contrôle d'accès basique : le BAC (Basic Access Control)

Pour éviter les inconvénients précédents, il a été décidé d'introduire :

Pour implémenter ces deux fonctions qui réalisent le BAC, il a été décidé d'utiliser un algorithme cryptographique symétrique à clé secrète : le triple-DES.

L'utilisation d'un algorithme à clé secrète suppose l'existence d'un secret partagé entre la carte et le système d'inspection (l'équipement de lecture) ce qui représente une certaine difficulté. Les règles de l'art en cryptographie militent pour l'utilisation de clés diversifiées (ici, dans les passeports). Pour que les systèmes d'inspection soient en mesure de retrouver la clé d'un passeport, il aurait été nécessaire de les munir de composants sécurisés mémorisant au moins une clé mère (et en pratique, plusieurs) avec tous les risques de compromission de ces clés qu'impliquerait la perte ou le vol d'un système d'inspection. Quant à disposer d'un système centralisé pour éviter les ce dernier risque, il aurait été difficile à généraliser, tous les pays ne disposant pas d'infrastructures de communication fiables.

La solution retenue a été d'utiliser un secret qui n'en est pas un : le contenu de la MRZ. Le contenu de cette zone est lu optiquement dans le passeport papier et sert à générer une clé qui elle-même est utilisée pour générer les clés de chiffrement et d'authentification permettant la mise en œuvre le BAC (voir ICAO 9303).

img

Normalement, une personne n'ayant pas accès au passeport physique pour y lire le contenu de la MRZ n'est donc pas en mesure de s'authentifier vis-à-vis du passeport ni de déchiffrer les communications entre un système d'inspection légitime et la carte. On dispose donc d'un mécanisme qui semble empêcher les écoutes passives et les attaques actives.

Malheureusement, ce mécanisme souffre d'un défaut provenant du codage de la MRZ. On pourra lire à ce propos la Note n° 9 « Utilisation du profil de protection EAC, 2008 ANSSI ». En résumé, l'entropie de la clé générée par ce mécanisme est très limitée et ne résiste pas à une attaque en force brute. La Note 9 indique que l'entropie théorique ne dépasse pas 73 bits et que pour la plupart des pays de l'Union Européenne et pour les USA, elle est en pratique de l'ordre de 52 bits.

Empêcher le clonage, l'authentification active (AA)

Comme on l'a vu précédemment, la spécification initiale du dvLM ne prévoyait pas de contre-mesure spécifique contre le clonage. Toutefois, à partir du moment où l'on introduit des mécanismes cryptographiques permettant de mettre en œuvre le BAC, il est tentant, moyennant un certain surcoût néanmoins, de spécifier une fonction de sécurité permettant de s'assurer que la puce est authentique et supprimer ainsi les risques de clonage. C'est ce que permet l'authentification active ainsi résumée dans le document TR03110 du BSI (Bundesamt für Sicherheit in der Informationstechnik) (traduction non littérale) :

L'authentification active est une fonctionnalité de sécurité qui prévient le clonage en introduisant un biclé dans chaque puce. La clé publique est mémorisée dans le groupe de donnée DG15 et est protégée (i.e. en intégrité/authenticité) par le mécanisme d'authentification passive et l'utilisation du mécanisme de secure messaging utilisant le BAC. La clé privée correspondante est stockée en mémoire sécurisée (i.e. inaccessible en lecture/écriture) et ne peut être utilisée qu'en interne dans la puce.

La puce peut démontrer sa connaissance de la clé via un protocole de challenge-réponse appelé « authentification active » (active authentication). Le terminal reconnaît que la puce est authentique si le résultat du calcul par la clé privée sur le challenge envoyé est correct.

Procédure d'inspection standard

Arrivée à ce stade des spécifications, il est utile de résumer ce qu'est la procédure dite « d'inspection standard » d'un passeport qui supporte l'authentification active :

  1. Le système d'inspection doit sélectionner l'application ePasseport.
  2. Le système d'inspection doit mettre en œuvre le protocole BAC si celui-ci est proposé par la puce.
  3. Le système d'inspection doit lire les conditions d'accès aux données contenues dans le groupe de données 14 (DG14). L'intégrité et l'authenticité de ces données se fait en utilisant l'authentification passive.
  4. Si disponible, le système d'inspection doit mettre en œuvre l'authentification active.
  5. A ce stade, le système d'inspection peut accéder aux données de faible sensibilité, le MRTD devant refuser l'accès aux éventuelles données biométriques sensibles.

Authentification de la puce (Chip Authentication), contrôle d'accès étendu (EAC)

Les mécanismes BAC et AA ne permettent pas de répondre aux critiques concernant les atteintes à la vie privée. De plus, les pays européens, Allemagne en tête, souhaitaient que les données biométriques type « empreintes digitales » ou « iris » ne soient accessibles qu'à des systèmes d'inspections autorisés (donc authentiques du point de vue du dvLM) et par des protocoles plus robustes que celui proposé par le BAC. C'est ainsi qu'est apparue la spécification « EAC » dont l'implémentation est obligatoire dans les passeports européen.

La spécification EAC introduit deux étapes supplémentaires appelée « authentification de la puce » et « authentification du terminal ».

Le mécanisme d'authentification de la puce est un protocole qui permet une négociation de clés Diffie-Hellman de type ephemeral-static. Il s'agit d'une alternative au protocole optionnel d'authentification active. Comme ce dernier, il permet de vérifier que la puce est authentique mais en plus, il permet de disposer de clés de sessions fortes pour assurer la confidentialité des échanges à travers l'établissement d'un secure messaging qui se subsititue à celui négocié en BAC. Le document TR-03110 donne deux autres propriétés du protocole citées ici pour mémoire : authentification implicite des données lues dans la puce de la carte et non transférabilité des résultats du challenge lors de l'authentification.

L'authentification du terminal permet à la puce du dvLM d'authentifier le terminal par un challenge-réponse en vérifiant la validité du certificat de la clé publique du terminal à partir d'une chaîne de certificat qu'il mémorise (ce qui pose le problème de la mise à jour de cette chaîne). Si le terminal est authentifié, il peut alors avoir accès à l'intégralité des données lisibles de la puce (en particulier, les données biométriques).

Pour terminer, cette spécification introduit un nouveau mécanisme noté PACE (Password Authenticated Connection Establishment) destiné à remplacer le BAC et permettant de disposer d'une clé de session forte dès les premières étapes du contrôle d'accès.

Cette succession de protocoles cryptographiques complique la réalisation des dvLM (et accessoirement des terminaux). Outre le fait que les puces des dvLM doivent être en mesure de réaliser des calculs cryptographiques à clés publiques ce qui impose un coprocesseur adapté, elles doivent faire ces calculs avec les contre-mesures contre les attaques classiques (DPA, SPA, EMA, etc.) ce qui ralentit les échanges. Le fait d'être en mode sans-contact n'améliore pas la situation à cause des limitations d'énergies associées à ce mode de fonctionnement. Malgré ces difficultés, il est à noté que les fabricants européens de puces de dvLM (Gemalto, Oberthur, Sagem…) ont été en mesure de produire de telles puces dès 2008.

Au final, la procédure d'inspection étendue peut se résumer ainsi :

  1. Le système d'inspection doit sélectionner l'application ePasseport.
  2. Le terminal doit lire le groupe de données 14 (DG14) et doit mettre en œuvre le protocole d'authentification de la puce. A l'issue, il doit redémarrer le mécanisme de secure messaging.
  3. Le système d'inspection doit lire et vérifier le DSO (Data Security Object) et doit vérifier la validité des conditions d'accès aux données contenues dans le groupe de données 14 (DG14). L'intégrité et l'authenticité de ces données se fait en utilisant l'authentification passive.
  4. L'authentification active peut être réalisée.
  5. L'authentification du terminal doit être réalisée si il y a nécessité d'accéder aux données sensibles (biométriques) contenues dans la puce du dvLM.

Passeport et désinformation

L'histoire de la carte à puce et de ses applications est jalonnée d'annonces plus ou moins fantaisistes concernant la sécurité, annonces dont on se demande la finalité réelle. En rédigeant ce chapitre, je suis tombé sur une page de Wikipédia en anglais parlant des attaques contre le passeport. J'ai trouvé intéressant de l'utiliser comme exemple de désinformation mais ce qui est dit à propos du passeport a également été dit à propos d'autres applications.

Le lien sur la page est http://en.wikipedia.org/wiki/Biometric_passport mais comme le contenu peut changer, j'ai mis sur ce site quelques extraits du chapitre sur les attaques qui étaient décrites en 2012.

Malheureusement, ces exemples d'attaques qui n'en sont pas ou qui se trompent de cibles sont nombreux et contribuent à la désinformation générale sur ces sujets pas forcément simples à traiter. Ceci est d'autant plus dommage que ce type de publication noient dans la masse d'autres articles qui présentent des attaques ayant un réel intérêt pour améliorer la sécurité.

BIBLIOGRAPHIE

OACI 9303

BSI Technical Guideline TR-03110

BSI-ANSSI Common Criteria Protection Profile, Machine Readable Travel Document using Standard Inspection Procedure with PACE, BSI-PP-0068

img