SOMMAIRE DETAILLE

PREAMBULE GENERALITES SUR LES CARTES Vocabulaire Cartes en logique câblée Cartes à micro-processeur ACTEURS DE LA CARTE Les fabricants de composants Les concepteurs de masques Les encarteurs Les personnalisateurs Le marché de la carte SECURITE DE LA CARTE Quelques attaques sur les cartes Point sur les évaluation sécuritaires Sécurité du composant matériel Sécurité du logiciel Sécurité des communications QUELQUES APPLICATIONS DE LA CARTE Choix d'une carte Acteurs d'un projet carte Applications monétiques, généralités Cartes « Ville » et autres cartes privatives Cartes bancaires avant EMV Les premiers pas Cartes bancaires M4B0 et B4B0' Cartes bancaires EMV Généralités Paiement EMV en mode contact Paiement EMV en mode sans contact (NFC) Paiement mobile EMV sans contact Paiement mobile SIM centric Paiement mobile HCE Paiement mobile SE embedded Porte-monnaie électronique Téléphonie mobile, la carte SIM La carte santé Vitale Passeport électronique

NORMALISATION Survol de la normalisation Organismes de normalisation Les normes de la carte LECTEURS DE CARTES Anatomie d'un lecteur de carte Les lecteurs de table Les lecteurs portables Les lecteurs à intégrer Le dialogue lecteur-carte ANNEXE, ANCIENNES CARTES Cartes à mémoire à piste magnétique Cartes à mémoire laser Cartes à mémoire électronique Carte F256/GPM256 Carte MZ9K Carte GPM416 Cartes M4 et B4B0 Carte M9 Carte M64 Carte COS Premières crypto-cartes ANNEXE, HISTOIRES DE PROJETS Télévision à péage, les origines Véridial, préhistoire de la signature électronique Cerdial, préhistoire de la signature électronique TRAVAUX PRATIQUES Cartes M4B0 et B4B0' Cartes EMV Cartes SIM Cartes M9 Cartes IAS Cartes NAVIGO/CALYPSO

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

• Histoire secrète de la carte à puce, Roland Moreno dans son style toujours très libre...
• Histoire de la carte à puce du point de vue d'un cryptologue, Louis Guillou
• Cartes à puce, Michel Ugon dans « Techniques de l'ingénieur ».
• La carte à puce, Pascal Urien (sachant que ce cours est mis à jour régulièrement et que la version en lien n'est peut-être pas la dernière)
• Super Dupont sauvant l'industrie française de la carte (il faut bien se détendre un peu). J'espère que Gotlib me pardonnera ce détournement (sinon, je le vire (le détournement évidemment)).

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 :

• Le grand public n'a aucune raison de faire ce genre de comparaison.
• Beaucoup d'experts en sécurité ne connaissent pas les spécificités de ces objets qu'ils assimilent à un système informatique comme n'importe quel autre.

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 :

• la carte en logique câblée (carte à microcircuit) qui ne comporte généralement qu'une circuiterie logique destinée à réaliser des fonctions basiques
• et la carte à microprocesseur qui comporte un ou plusieurs processeurs réalisant des fonctions complexes.

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

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 a été le plus répandu et le plus connu pendant un temps.

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

  

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 reviendrons plus tard mais on peut tout de même citer :

• La ROM est de plus en plus souvent remplacée par de la mémoire flash
• L'EPROM est remplacée par des E²PROM qui ont l'avantage d'être effaçables électriquement (comme la flash d'ailleurs).
• Dans les cartes haute-sécurité, l'horloge est générée en interne.
• De même, la tension de programmation de l'E²PROM est générée en interne.
• De plus en plus de composants cartes proposent de nouveaux modes de communication non forcément exclusifs : sans contact, USB...

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.

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 :

• D'une part, récupérer l'énergie du champ électromagnétique
• D'autre part, récupérer la modulation de ce champ pour recevoir de l'information ou moduler ce champ pour émettre de l'information.

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" (site inaccessible en 2019).

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.

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.

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.

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ée à 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 :

• les fabricants de composants électroniques,
• les concepteurs des « masques programme »,
• les encarteurs/imprimeurs,
• les personnalisateurs.

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.

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 en 1999 sous le nom d'INFINEON.

SAMSUNG, considéré comme le 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 2017, 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
ST Microelectronics ST33J2M0	~2016		NA	2 048 ko	50 ko	ARM SecureCore, RISC 32 bits, 60MHz, double coeur

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.

 

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.
Pour la petite histoire, Bull a été reprise par la société ATOS en 2014. ATOS était issue de la fusion d'Axime, Sligos et GSI. On se rappellera que Sligos a été une société importante dans l'encartage via sa filiale Solaic, revendue en 1996 à Schlumberger (qui a donné naissance à Axalto devenue Gemalto suite à la fusion avec Gemplus, voir plus loin).
ATOS et Bull ont donc toutes deux eu à faire avec la carte à puce dans leur histoire et toutes les deux, ont finit par abandonner cette activité. Qu'en conclure ? Rien. C'était juste pour l'anecdote.

Sauf qu'en décembre 2017, l'histoire aurait pu bégayer. Suite à une baisse de ses activités, Gemalto s'est trouvée dans la position d'être repris par le marché. C'est ATOS qui a tiré le premier en lançant une OPA sur la société. Mais c'est finalement Thalès qui a remporté le morceau. Avec le rachat de Morpho quelques mois auparavant, l'année 2017 aura été fertile en bouleversements dans le marché de la carte.

Reste à savoir si Thalès saura valoriser cette acquisition. Rien n'est moins sur... Rendez-vous dans quelques années.

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.
Finalement, Oberthur a racheté Morpho pour donner naissance en septembre 2017 à un nouveau groupe nommé Idemia (nom que je trouve particulièrement sans saveur !).

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

• Gemalto, considéré comme le n° 1 mondial
• Oberthur considéré comme le n° 2 ou 3 mondial, cette place se disputant avec l'allemand Giesecke & Devrient.
• Morpho, considéré comme le quatrième fabricant mondial.

En 2017, on pouvait envisager le palmarès suivant :

• Gemalto, considéré comme le n° 1 mondial, racheté par Thalès en décembre 2017
• Idemia (Oberthur-Morpho), créé suite au rachat de Morpho par Oberthur.
• Giesecke & Devrient.

Il semble que ce palmarès soit toujours valable en 2021.

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 10 milliard en 2018) 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

Production en million d'unités

Légende

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 contentés 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 

• lecture par un terminal souhaitant authentifier la carte d'une donnée en lecture libre appelée « valeur d'authentification » ou VA. Cette VA était la signature d'un certain nombre d'informations en lecture libre et stockées dans la carte (en particulier, PAN, n° de série du composant, dates de validité...).
• Calcul de vérification de signature à partir de la VA et de la clé publique correspondant à la clé privée ayant permis de constituer la VA.
• Si le résultat du calcul permettait de retrouver les informations signées et mémorisées dans la carte, alors, on pouvait en conclure que la VA avait bien été générée par une autorité connaissant la clé privée, donc, une banque.

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 :

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, on peut être partagé :

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.

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.

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é ».

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 :

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 constance (répétabilité) : l'évaluation répétée d'une même cible d'évaluation (TOE) vis-à-vis de la même cible de sécurité par le même laboratoire d'évaluation doit conduire au même verdict.
• la reproductibilité : l'évaluation répétée d'une même cible d'évaluation vis-à-vis de la même cible de sécurité par un laboratoire d'évaluation différent doit conduire au même verdict,
• l'impartialité : l'évaluation doit être exempte de biais,
• l'objectivité : l'interprétation du résultat d'un test ou d'une mesure doit être fait avec le minimum de jugement ou d'avis subjectif.

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

En effet, cette analyse fait 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 :

• l'évaluation a été réalisée conformément aux normes en vigueur ;
• l'analyse de vulnérabilité a été faite à l'état de l'art dans le domaine. A noter qu'en France, du fait des spécificités del a sécurité, l'analyse de vulnérabilité n'est donc pas couverte par l'accréditation des laboratoires d'évaluation par le COFRAC mais par l'agrément délivré par l'ANSSI aux laboratoires. Les laboratoires sont donc sous une double tutelle.

Pourquoi pas le secteur privé ? Théoriquement, rien ne s'y oppose. Mais jusqu'en 2021, 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 :

• Les CC définissent une échelle de 7 niveaux de confiance pour une évaluation (EAL1 à EAL7, EAL pour Evaluation Assurance Level). Pour les cartes, le niveau minimum visé est le plus souvent EAL4 avec des augmentations.
• La principale augmentation est le niveau de résistance aux attaques (en fait, le niveau d'analyse de vulnérabilité). Il y a 5 niveaux (AVA_VAN.1 à AVA_VAN.5). Le niveau retenu pour les cartes est généralement AVA_VAN.5 (résistance élevée aux attaques).
• L'évaluation vérifie la conformité du produit par rapport à une cible de sécurité qui peut être assimilé à une expression de besoin en sécurité. Cette cible spécifie ce qui doit être évalué et à quel niveau de confiance. Dans le domaine des cartes, il existe des cible de sécurité génériques (des profils de protection) universellement adoptées qui garantissent que toutes les évaluations se font selon les mêmes exigences.
• Les certificats délivrés par les organismes de certification bénéficient d'une reconnaissance internationale grâce à deux accords :
• L'accord international dit CCRA. Dans cet accord, la reconnaissance est limitée au niveau EAL2 des CC.
• L'accord européen dit SOGIS. Dans cet accord, la reconnaissance se fait au plus haut niveau des CC sous réserve que les organismes de certification et les laboratoires qui en dépendent soient compétents dans le domaine technique. En 2020, Les pays en mesure de certifier les cartes à haut-niveau de confiance étaient la France, Le Royaume-uni, les Pays-bas, l'Allemagne, l'Espagne.

En conséquence, seules les évaluations sécurité de cartes faites en Europe sont reconnues par les Européens et en pratique, la notoriété de l'accord SOGIS est telle que pendant de nombreuses années, des pays en dehors de l'Europe demandaient que leurs cartes soient évaluées et certifiées en Europe au sein de cet accord. Depuis les années 2010, certains de ces pays cherchent également à monter des schémas d'évaluation et de certification similaires.

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 :

• La plus importante est que les cartes sont les seuls produits qui peuvent être évaluées sans faire d’hypothèse sur l’environnement d’utilisation.

Lorsqu’on évalue la sécurité d’un produit informatique habituel (pare-feu, système d’exploitation, produit de signature, HSM, etc.), il y a toujours des hypothèses simplificatrices qui permettent d’éliminer certaines attaques. Exemple :

• Les utilisateurs sont de confiance
• L’environnement d’utilisation est protégé
• Le système support (typiquement, le système d’exploitation) est correctement administré (et parfois, de confiance « a priori »)
• Le matériel est de confiance (processeur, circuits auxiliaires (chipsets)…)
• Etc.

Pour une carte dans le mode « émis » (le mode dans lequel la carte est fournie à son utilisateur), il n’y a le plus souvent aucune hypothèse simplificatrice. L’évaluateur a donc la possibilité de faire toutes les attaques qui lui viennent en tête dès lors qu’elles sont susceptibles de compromettre un bien sensible identifié dans la cible de sécurité.

• Le mécanisme de composition est spécifique (voir Composite product evaluation for Smart Cards and similar devices) Comme le terme de « composition » n’est pas forcément clair pour tout le monde, voici une illustration :

Considérons un pare-feu personnel s’exécutant sur un poste de travail dont l’éditeur demande l’évaluation. La cible de sécurité du produit décrira les fonctionnalités techniques du pare-feu à prendre en compte durant l’évaluation et décrira sous forme d’hypothèses ce qui est attendu de la part du système d’exploitation.

Dans un monde idéal, on peut supposer qu’il existe un système d’exploitation évalué et certifié sur lequel peut s’exécuter le pare-feu. L’évaluateur vérifiera alors que les hypothèses de la cible de sécurité du pare-feu sont cohérentes avec celles du système d’exploitation et que les fonctionnalités du système d’exploitation sur lesquelles s’appuie le pare-feu sont utilisées correctement. S’étant assuré de ces points, l’évaluateur éliminera toutes les attaques qui sont susceptibles d’être couvertes par des fonctions évaluées du système d’exploitation ou par les hypothèses et concentrera son effort sur les seules fonctionnalités du pare-feu (en pratique, c’est un peu plus compliqué mais c’est l’idée).

Cette approche permet de construire des systèmes complexes dont chaque couche apporte à l’autre certaines fonctionnalités évaluées une fois pour toute et que l’on ne remet pus en question, sauf évolution de l’état de l’art dans le domaine des attaques (en pratique, en 2021, on est loin de cette situation).

Dans le domaine des cartes, il est apparu assez rapidement que cette approche ne fonctionnait pas. Et pour ne pas l’avoir compris, certains industriels ont pu faire des cartes très facilement attaquables alors même que le composant était évalué et certifié au plus niveau et le logiciel qui s’exécutait dessus également.

Il y a des raisons techniques à cela, à commencer par le fait qu’aucun composant ne peut résister à toutes les attaques sans que le logiciel (système d’exploitation ou application) implémentent des contre-mesures spécifiques. Ces contre-mesures ne peuvent pas toutes être spécifiées par le fabricant du composant sauf en des termes généraux. La certification d’une carte (partie applicative) est donc toujours associée à un composant particulier (évalué et certifié) et à un système d’exploitation particulier lorsqu’il y en a un (évalué et certifié sur le composant en question).

Lors de l’évaluation de l’application, l’évaluateur doit être en mesure de réaliser certains tests sur les éléments sous-jacents. Pour ce faire, il dispose d’un rapport spécifique (ETR for composite evaluation) lui permettant de disposer d’informations issues des évaluations des éléments sous-jacents.

• Pour couronner le tout, les évaluations cartes utilisent une cotation des attaques propre au domaine. Ce n’est pas sans entrainer une certaine confusion qui profite à certains... Ce qu’il faut savoir, c’est qu’un ELA4+AVA_VAN.5 pour une carte est d’un niveau de résistance aux attaques sans commune mesure avec une cotation identique pour les autres types de produits.

Conclusions

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 :

• Des cartes bancaires.
• Des cartes pour télévision à péage.
• Des cartes pour l'administration électronique (identité, passeport...)
• Quelques rares cartes SIM en France
• Quelques cartes de contrôle d'accès logique.

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.

La recherche d'un haut niveau de sécurité aura permis pendant un temps à l'Europe de briller dans un des domaines de la sécurité (probablement le seul) et de développer des industries devenue des références internationales (fabricants, laboratoires...). Il est probable que cette position ne durera plus très longtemps (2021), en particulier grâce aux efforts constants de la commission européenne depuis 2014 pour tuer l'écosystème qui s'appuyait sur le SOGIS. C'est chose faite depuis 2019 (voir le réglement 2019/881) [archive] qui, s'il présente bien (comme la plupart des textes officiels), signe en pratique la fin des évaluations commerciales ayant un minimum de sérieux.

La fluidification des échanges s'accommode mal des contraintes liées à la recherche d'un certain niveau de sécurité, d'autant plus que beaucoup d'industriels en Europe ne sont pas à niveau. Plutôt que d'augmenter le niveau de performance des produits, on modifie la façon de mesurer. En clair, on tire vers le bas (voir le « niveau élémentaire » dans le réglement, en pratique, celui qui s'appliquera pour la majorité des produits).

Ce n'est pas la première fois que la commission européenne procède de cette façon et ce n'est sans doute pas la dernière. Mais dans le cas présent, je pense que ni les USA, ni la Chine n'en demandaient tant !

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 2021. 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
Etuves	Standard	Pour éprouver le composant en température et humidité
Alimentation	Standard	Comportement du composant en fonction de l'alimentation
Oscilloscope analogique	Standard	Observation, mesure
Lecteur de carte ou de composant	Standard	Pour utiliser le composant
Logiciel d'analyse de signal	Standard	Pour exploiter des mesures
Logiciel de génération de signaux	Standard	Pour modifier le comportement du composant
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é
Station de micro-probing	Spécialisé	Mesure/capture de signaux
Equipement laser	Spécialisé	Perturber le composant
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
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
Outils de ponçage	Spécialisé	Pour attaquer les matériaux du composant
Microscope électronique à balayage	Sur mesure	Pour analyser le composant en fonctionnement ou à l'arrêt
Faisceau électronique testeur	Sur mesure
Microscope à force atomique	Sur mesure
Faisceau d'ions focalisé (FIB)	Sur mesure
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.

• Au début de l'histoire de la carte, choix de l'EPROM (ensuite, d'EEPROM et de flash), plus complexes à relire que la PROM.
• A une certaine époque, utilisation de mémoires dynamiques plutôt que statiques afin d'empêcher l'analyse du comportement des circuits en basse fréquence.
• Brouillage des informations en mémoire permanente.
• Capteurs divers avec réaction en cas de déclenchement de ces capteurs.
• Bouclier actif.
• Régénération de la fréquence d'horloge en interne et variations aléatoires de la fréquence pour compliquer les synchronisations.
• Génération interne des tensions de programmation des mémoires EEPROM.
• Contrôle des tensions d'alimentation.
• Mesures anti-SPA/DPA
• etc.

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.

Sécurité du logiciel

En pratique, même si les 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

• Gestion des phases de vie : certaines actions sont possibles à certains moment de la vie de la carte et ne doivent plus l'être à d'autres moment. Ainsi, l'accès à la mémoire de la carte est généralement possible pour une grande partie en phase dite « de personnalisation », ceci afin de faciliter l'écriture des données qui serviront à l'application : les données associées au porteur, les codes secrets, les clés secrètes, les autres données confidentielles. L'enjeu sécuritaire est qu'il ne doit pas être possible de revenir dans une phase de vie antérieure.
• Fonctions sécuritaires : par exemple, authentification du porteur via son PIN (code porteur), calculs cryptographiques permettant à l'environnement d'authentifier la carte ou de protéger des communications via des opérations cryptographiques, contrôle d'accès aux données, etc.
• Autres fonctionnalités : par exemple, la possibilité de charger de nouvelles applications lorsque la carte est « émise » sans dégrader sa sécurité, la possibilité d'invalider une carte, etc.

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

• Jusqu'à 10cm, on se trouve dans l'utilisation normale de la carte. Un simple lecteur de carte standard fait l'affaire.
• Jusqu'à 40cm, on dispose d'une alimentation en mesure de fournir un courant important passant dans une antenne adaptée. Cette distance est considérée comme une limite pratique.
• Jusqu'à 50cm, idem que précédemment plus un logiciel de traitement des communications adaptées.
• Jusqu'à 55cm, idem que précédemment plus un matériel en mesure de réaliser un traitement du signal.

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 :

• Votre émulateur de carte peut être remplacé par un smartphone NFC
• le relai peut être un logiciel malveillant situé dans le téléphone de la victime. Plus besoin de matériel d'activation. Ce point est un peu plus détaillé dans le cas du paiement HCE.

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 :

• un émetteur qui émet la carte et qui en est souvent (mais pas toujours) le propriétaire,
• le plus souvent, une carte est associée à un porteur qui est la personne qui utilise la carte émise.

Par ailleurs, une carte peut-être :

• « mono service » (elle donne accès à un seul service) ou « multi-services » (elle donne accès à plusieurs services).
• « mono prestataire » (le ou les services auquels la carte donne accès sont fournis par un seul prestataire) ou « multi-prestataires » (les services proposés sont répartis entre plusieurs prestataires).

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

• La Télécarte a été une carte mono service (elle ne servait qu'à téléphoner), mono prestataire (France-Télécom à l'époque). On ne peut pas dire qu'elle était associée à un porteur particulier puisque celui-ci n'était pas identifié. On peut admettre que l'utilisateur de la carte (son porteur à un instant donné) en était le propriétaire. Enfin, la carte était émise par France-Télécom.
• La carte bancaire M4B0 (émise au milieu des années 1980) était multi-services (elle permettait de payer au comptant, à crédit (théoriquement), de retirer de l'argent liquide...) et de téléphoner), multi-prestataires (il y avait un prestataire bancaire (une banque) et France-Télécom comme second prestataire). Elle était associée à un porteur identifié (au moins pour le service bancaire). Elle était émise par une banque qui en était le propriétaire
• La carte bancaire EMV des années 2010 est multi-services (elle offre potentiellement les mêmes services que la carte bancaire émise en 1986) mais mono prestataire (le prestataire est la banque émettrice de la carte).
• Dans les années 1980, Louis Guillou du CCETT imaginait qu'une carte puisse ne pas être émise au sens propre du terme. L'idée était qu'une carte puisse être achetée vierge par son porteur et qu'elle soit authentifiable par des prestataires potentiels qui pourraient alors charger des applications et des secrets donnant accès à des services. L'authentification de la carte se ferait via un secret initial mis, par exemple, par un tiers de confiance, garantissant que le support répond bien à un certain cahier des charges fonctionnel et sécuritaire. Je cite ce cas car s'il n'a jamais été mis en oeuvre tel qu'imaginé initialement, il est néanmoins très proche de ce qui se met en place (2013) dans le domaine de l'automobile : les véhicules communicants sont équipés d'un module de type SIM à demeure (non remplaçable) mais qui n'est pas affecté à un opérateur particulier. C'est l'utilisateur du véhicule qui décide de l'opérateur qui pourra s'installer dans sa carte et qui pourra en changer s'il le souhaite. Cette absence de véritable émetteur pose des problèmes nouveaux en terme de responsabilité mais ouvre aussi de nouvelles perspectives intéressantes pour le développement de cette technologie.

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 :

• Comment la banque peut-elle connaître à coup sûr le nombre de jetons à rembourser ?
• En faisant cette opération de remboursement, la banque offrait un service et les banques n'ont pas l'habitude de rendre des services gratuitement. Comment expliquer aux porteurs qu'il devait payer pour se faire rembourser ? Commercialement, ce n'est pas très évident.

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 :

• Qui est l'émetteur de la carte ?
• Qui est le porteur de la carte ?
• Quels sont les services proposés ?
• Quels sont les prestataires de services ?
• Quels sont les politiques de sécurité de chaque prestataire ?
• Quels sont les contraintes d'image de chaque prestataire ?
• Quels sont les responsabilités de chaque prestataire ?
• Quels sont les contraintes qui concernent le porteur (considérer en particulier, les contraintes induites via les réglementations sur la signature électronique ou les contraintes induites via la protection de la vie privée) ?

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 :

• utilisation en débit/crédit : les cartes contiennent une information permettant d'identifier indirectement le compte bancaire d'un porteur qui sera débité à partir d'un acte de paiement sur une machine autonome ou sur le terminal de paiement d'un commerçant. Le compte bancaire du commerçant sera crédité de la somme débitée. Les acteurs concernés par ces opérations sont le porteur de la carte, sa banque émettrice, le commerçant et sa banque acquéreur. On parle d'un schéma de paiement à quatre coins.
  

  Les utilisations en crédit sont proches à la différence près que le paiement se fait sur une ligne de crédit préétablie et qu'il déclenche une opération de remboursement selon des modalités prédéfinies.

  A noter qu'en France, dans le domaine des cartes bancaires, il existe une ambiguïté entre certaines cartes de débit et les cartes de crédit. Certaines cartes de débit proposent en effet un débit différé (quelques semaines parfois) ce qui est en pratique assimilable à un paiement à crédit gratuit(le compte n'est pas débité immédiatement).

• utilisation en prépaiement : dans ce mode, le client fait la démarche de convertir par avance une certaine somme d'argent monétaire en une « monnaie » dédiée à un usage ou pas lui donnant l'accès à un certain nombre de services identifiés. Dans le cas présent, la CAM peut servir de simple système d'identification ou peut contenir la preuve qu'un prépaiement d'un certain montant a effectivement eu lieu.

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 :

• La carte bancaire (CB) offre (entre autres parfois) un service de paiement. Le système a été conçu pour être majoritairement utilisé hors ligne ce qui justifie l'existence d'une intelligence locale au niveau de la carte afin d'améliorer la sécurisation des transactions. L'architecture est répartie.
• La Télécarte a été une carte en prépaiement, utilisée en mode hors ligne, mémorisant des droits d'accès à usage dédié (la téléphonie) et s'inscrivant dans une architecture répartie (les droits d'accès sont contenus dans les cartes).
• Le porte monnaie électronique Monéo a été une carte en prépaiement, utilisée hors ligne, mémorisant une « reconnaissance de dette » à usage non dédié de la part de l'émetteur de la carte (la valeur prépayée par le porteur) et s'inscrivant dans une architecture répartie (la valeur du porte monnaie est contenue dans la carte) en mode hors ligne.
• Les cartes d'accès aux restaurants d'entreprise sont le plus souvent des cartes en prépaiement, mémorisant une « reconnaissance de dette » à usage dédié de la part du prestataire de service et s'inscrivant dans une architecture centralisée (la valeur du « porte monnaie » est sur un serveur, la carte ne sert que de moyen d'identification du compte) en mode en ligne.
• Les cartes d'accès conditionnels aux émissions de télévision par satellites sont des cartes en prépaiement mémorisant des droits d'accès à usage dédié (des émissions de télévision) et s'inscrivant dans une architecture répartie en mode hors ligne.

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 :

• Un client souhaitant une carte PASTEL devait désigner un compte téléphonique sur lequel étaient imputées ses communications (il pouvait s'agir de son propre compte ou de celui de son entreprise par exemple).
• lorsqu'il téléphonait à partir d'un publiphone, le centre de gestion enregistrait les coordonnées de son compte ainsi que le nombre de taxes consommées. A noter qu'il existait la possibilité d'utiliser sa carte PASTEL sur un téléphone quelconque en fournissant le numéro de la carte à un opérateur.
• périodiquement (tous les deux mois), il recevait sa facture téléphonique sur laquelle étaient listées les taxes consommées à partir de son installation et celles consommées avec la carte PASTEL.
• Lorsqu'elle était utilisée sur un publiphone, elle mémorisait les appels passés.

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 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 :

• le nombre de bits peut être supérieur au nombre de droits achetés. On inscrit ailleurs dans la carte le nombre de droits effectivement achetés ailleurs dans la carte. Ceci permet de conserver des bits en « réserve » au cas ou il se produirait des erreurs d'écriture dans la carte.
• la carte peut être rechargeable, soit par ré-initialisation de la zone porte-jetons lorsqu'il s'agit d'une carte effaçable, soit par inscription d'une nouvelle zone porte-jetons, etc. Il est alors nécessaire d'introduire des procédures de sécurité spécifiques à cette fonction.

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.

• Le support utilisé était une carte M4 de Bull-CP8.
• La zone de transaction était protégée en écriture et libre en lecture.
• La zone libre contenait l'identité du porteur.
• Le porte monnaie était organisé comme suit :
• Le montant de rechargement de la carte était stocké sur un mot complet de la zone de transaction validé sous contrôle de la clé 1A (émetteur). Les débits étaient inscrits dans les mots qui suivaient à raison de 3 débits par mots. La valeur maximum d'un débit était donc de 1023 x unité de base. Les débits étaient écrits en logique inverse.
• Lors d'un nouveau rechargement, le solde restant était calculé en faisant la différence entre le dernier crédit inscrit et la somme des débits. Le nouveau crédit était alors égal au montant de rechargement plus le solde.
• Afin de diminuer la durée d'une opération de débit, la carte était divisée artificiellement en blocs de 10 mots. Chaque bloc était repéré par un bit dans une map. Au fur et à mesure que les blocs se remplissaient, un bit était grillé dans la map afin d'en faciliter l'adressage (le dernier bloc en utilisation correspond au dernier bit grillé dans la map).
• Des mécanismes d'authentification et de sécurité étaient mis en oeuvre afin d'éviter la création de fausses cartes et de fausse monnaie.
• La durée moyenne d'une opération de débit ou de rechargement était d'environ 2 secondes. Dans le cadre de cette application, une carte permettait d'effectuer environ 400 paiements (sachant que la carte n'était pas effaçable).

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é :

• Les cartes d'accès aux restaurants d'entreprises ou à la cantine
• Les cartes villes permettant l'accès à toute la panoplie des services proposés par certaines villes

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

  
Maquette de la carte pour une exposition

Si le projet ne fut au final pas lancé, les résultats de l'étude furent utilisés 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 :

• Le coût : il y a bien sûr les cartes mais aussi, la réalisation d'un système monétique complexe avec sa gestion associée,
• L'absence d'universalité et d'interopérabilité : en pratique, la ville doit conserver son système d'accès classique pour les personnes qui ne disposent pas de cartes. La carte « ville » apparaît donc comme un système de plus à gérer.

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

  

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 en logique câblées étaient limitées dans leur évolution sauf à les rendre aussi complexes qu'une carte à micro-processeur
• La carte bi-chip de Philips posait un problème de sécurité puisqu'il était possible d'analyser ce qui passait entre les deux composants

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.

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.

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.

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 :

• la faiblesse (en terme de sécurité) de la carte à piste magnétique qui est trop facilement reproductible,
• beaucoup de terminaux de paiement n'étaient pas reliés d'où une certaine difficulté dans le contrôle et la mise à jour des listes d'opposition,
• l'utilisation du « fer à repasser » (système manuel permettant de porter l'empreinte de la carte sur une facturette). Ces équipements se trouvaient essentiellement chez les commerçants ne pouvant justifier d'un chiffre d'affaires suffisant pour être équipés d'un terminal de paiement électronique.
• une certaine insouciance des usagers vis à vis de leur code confidentiel.

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.

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.

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

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

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:

• numéro ISO,
• code pays (cf norme ISO...),
• code devise (cf norme ISO...),
• code exposant dans la devise indiquée (exemple : si le code devise est le franc, le code exposant indique si les montants sont exprimés en centimes, décimes, unité, etc.).
• dates de début et de fin de validité (la date de validité d'une carte à piste magnétique est en général d'un an. Celle d'une carte à puce est en général de deux ans, d'une part parce-que la puce est plus résistante que la piste, d'autre part parce qu'elle est plus coûteuse).
• etc.

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.

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.

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.

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 en lecture libre » contient des informations qui sont inscrites durant la phase de personnalisation. Dans le cas de la carte bancaire, elle contenaient essentiellement les informations d'identité et la valeur d'authentification.
• La « zone de transaction » bénéficie d'un contrôle d'accès configurable. Pour la carte bancaire, elle était protégée (par code) en lecture et en écriture. Elle contenat toutes les informations applicatives qui étaient susceptibles de varier durant la vie de la carte.
• La « zone confidentielle » n'était pas utilisée par l'application bancaire.
• La zone d'état permet de contrôler les présentations de codes. Pour les cartes en technologie EPROM, Elle était généralement dimensionnée pour permettre la présentation d'environ 300 à 500 codes porteurs (à condition qu'il n'y ait pas de présentation de codes faux). Ce dimensionnement impliquait un nombre limité d'utilisations de la carte. La carte B4B0' utilisant une E²PROM, cette limitation n'existait plus.
• La zone secrète contient les codes secrets et le « jeu secret » (clés) de l'algorithme de calcul de la carte. Pour la carte bancaire, on y trouvait donc :
  • le code porteur (PIN). Celui-ci pouvait être « modifié » une fois durant la vie de la carte.
  • la clé de la banque (clé 1A ou clé émetteur ou clé prestataire principal). Cette clé permettait à la carte d'identifier son maître (la banque) pour certaines opérations.
  • la clé France-Télécom (clé 1B ou clé prestataire secondaire). La carte bancaire à puce offrait en effet un autre service que celui proposé par la banque : Il était possible de l'utiliser pour téléphoner. Ce service nécessitait que France-Télécom ait les moyens d'identifier la carte lorsque ce service était mis en oeuvre.
  • le jeu secret permet de mettre en oeuvre des fonctions de sécurité pour certaines opérations. Un exemple d'usage de cet algorithme est donné dans le paragraphe concernant les certificateurs. Un autre exemple d'utilisation est donné dans le chapitre concernant la défunte application VERIDIAL.

    Le jeu secret de la carte bancaire était diversifié à partir du numéro ISO (PAN) de la carte.

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 :

• la date (jour, mois, année),
• le type de l'opération,
• le montant,
• le fait que la transaction ait été faite sous ou hors du plafond de paiement définit pour le type de l'opération,
• éventuellement, un code budget.

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

• Le mois et l'année étaient inscrits lors d'une opération dite de « changement de date ». Pratiquement, lorsque l'équipement de paiement devait inscrire une transaction, il recherchait dans la carte la dernière opération de changement de date réalisée. Si le mois et l'année pour la transaction en cours étaient identiques à celui du dernier changement de date, la transaction était inscrite à la suite de l'historique. Sinon, l'équipement inscrivait une opération de changement de date contenant le mois et l'année en cours puis la transaction elle-même. Cette façon de procéder permettait d'économiser la mémoire de la carte.
• Le type de l'opération pouvait être un virement, un achat comptant, un retrait ou un achat à crédit. Chacune de ces opérations était contrôlée par un plafond dont le montant est contenu dans la carte. Si le montant de l'opération dépassait celui du plafond dans un intervalle de date donné, le terminal de paiement devait appeler un centre d'autorisation. L'indication que la transaction s'était faite sous ou hors plafond était également mémorisée.
• Le montant pouvait être inscrit sur un ou deux mots selon sa valeur. Lorsqu'il était inscrit sur deux mots, on pouvait également définir un code budget dont la valeur ne fut en pratique jamais définie.

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

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

• A permettre de vérifier si l'on était sous ou hors plafond de paiement
• A permettre au porteur d'avoir une trace de ses transactions dans un format homogène pour répondre au besoin de suivre ses dépenses comme on pouvait le faire avec les talons de chèques.

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 :

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 :

• permettre au client de saisir son code porteur de façon à ce qu'il puisse être vérifié par la carte,
• établir une preuve irréfutable que la transaction s'était déroulée dans les règles.

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 :

• Le certificateur devait être préalablement initialisé par la carte du commerçant en début de journée.
• La carte du client ayant été introduite dans le certificateur, il y avait présentation du code porteur et validation. Si le code était correct, la zone de transaction, donc la zone des certificats devenait accessible.
• Le commerçant entrait le montant et la date de la transaction sur le certificateur.
• Le certificateur recherchait le premier bit non grillé (à 1) dans la zone des certificats en commençant par la fin de cette zone.
• Ce bit étant trouvé, il était grillé (mis à zéro). Le certificateur demandait alors à la carte d'effectuer un calcul cryptographique (TELEPASS à l'époque) dont les paramètres étaient un condensé des informations précédemment saisies (date, N( de carte commerçant, montant de la transaction) et du mot contenant le bit grillé (son adresse et sa valeur qui change à chaque transaction).
• le résultat rendu par la carte était condensé puis affiché avec le rang du bit grillé dans la carte. Ce numéro devait être reporté par le commerçant sur la facturette. Il certifiait la transaction venant d'avoir lieu. En cas de contestation (généralement de la part du client), la banque du client avait les moyens de recalculer ce certificat. Si le résultat n'était pas conforme à celui inscrit sur la facturette, il y avait lieu de soupçonner une fraude de la part du commerçant et la transaction ne bénéficiait pas de la garantie de paiement de la banque.

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 :

• Politique de sécurité : elles sont différentes entre la carte bancaire et la« Télécarte ». La carte bancaire avait une durée de vie de 2 ans alors que la Télécarte n'avait pas de durée de vie annoncée. Au bout de 2 ans, il fallait donc trouver un moyen pour rembourser le porteur de la carte bancaire des jetons de téléphone non utilisés. Autant dire que devant la complexité de l'opération, les banques renoncèrent à mettre en place la procédure ét laissèrent la carte au porteur pour qu'il puisse continuer à consommer ses taxes, ceci, au mépris le plus complet des règles de gestions de la carte bancaire qui voulait qu'elle fut invalidée
• Consommation de la mémoire de la carte : les premières cartes étaient non effaçables. Donc, toute inscription d'une zone porte-jetons pour le téléphone se faisait au détriment de la place utilisable pour l'application bancaire avec un risque de voir la zone se saturer et l'obligation pour la banque de redonner une carte

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

• le porteur de la carte introduisait cette dernière dans le publiphone. Après composition de son code porteur, il pouvait téléphoner avec une limite de montant de 150F (1994) par semaine. Le coût total des communications était cumulé sur un « compte ». Tous les 30 jours, France-Télécom envoyait un ordre de virement à la banque du porteur correspondant au montant cumulé sur le compte. Le montant minimum de facturation était de 20F (1994). Si ce montant dans la période considérée était inférieur à ce plancher, l'utilisateur se voyait facturé de 20F. La différence fondamentale entre ce mode de fonctionnement et le précédent est que France-Télécom n'apparaissait ici que comme un « commerçant » parmi d'autres : il n'était plus prestataire secondaire.

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 :

• utilisation de composants E²PROM (effaçable) plutôt qu'EPROM permettant d'éviter certains phénomènes de saturation de la zone d'état.
• remplacement de l'algorithme TELEPASS par un DES
• introduction de nouveaux ordres permettant d'accélérer certains traitements (recherche de données dans la mémoire)
• vers 2005, introduction de l'authentification dynamique par un calcul RSA permettant d'éliminer le phénomène des Yescard.

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 :

• le point le plus important est que la carte EMV s'appuie sur la norme ISO7816-4 et non pas sur une spécification propriétaire. De plus, la spécification EMV ayant fait son marché dans les possibilités de cette norme, ce qu'elle a retenue est également devenu un standard, une sorte de sous-ensemble de ce qu'il faudrait retenir de l'ISO7816-4 (et 3 et 2 également), ce qui n'est pas un mal. L'organisation des données se trouve donc simplifiée et mieux gérée.
• EMV est dit « multi-applications » ce qui est un abus de langage. Disons simplement qu'il est possible d'inscrire plusieurs zones de paramètres permettant aux parties impliquées dans la carte de s'y retrouver. Supposons que vous disposiez d'une carte de la Caisse d'Epargne. Cette banque est affiliée au GIE-CB. La carte sera donc émise avec le logo CB. Mais la Caisse d'Epargne propose également que sa carte soit utilisable dans le réseau VISA. Elle aura donc aussi le logo VISA. La banque peut aussi vous proposer un crédit revolving qui ne se gère pas de la même façon qu'un achat comptant. Tous ces services bénéficieront d'une zone de données différentes (zone CB, zone VISA comptant...) pouvant néanmoins partager quelques données communes (par exemple, le PIN et souvent, les enregistrements des transactions).
• la principale fonctionnalité nouvelle est le module de gestion de risques qui permet à la carte et au terminal de paiement de décider la façon dont doit se dérouler le paiement (par exemple, en ou hors ligne, avec ou sans présentation du PIN, etc.).
• Enfin, dans le système CB et dans de plus en plus de pays en Europe (2012), le système bénéficie des possibilités cryptographiques de la carte (authentification dynamique, présentation chiffrée du PIN, génération de mot de passe à usage unique, etc.).

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 1 (Book 1, Application Independent ICC to Terminal Interface Requirements) : il décrit les fonctionnalités minimales imposées entre la carte et le terminal pour assurer un enchaînement correct des opérations et l'interopérabilité de l'application à utiliser. On y trouve en particulier les spécifications électromécaniques de la carte, * la spécification du protocole de communication entre carte et terminal (blocs ou caractères), le comportement à la réinitialisation (reset) de la carte, la structure des fichiers, la spécification de certaines commandes et la sélection d'une application de paiement.

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 :

• disponibilité de l'authentification statique (SDA). Pour ceux qui ont lu la partie du cours consacré à la carte M4, il s'agit d'un mécanisme similaire à celui de la VA (Valeur d'Authentification) contenant la signature RSA de données de la carte vérifiable par le terminal. Pour rappel, ce mécanisme ne protège par contre le clonage.

Architecture de clé pour SDA

• disponibilité de l'authentification dynamique (DDA). Si cette authentification est disponible, elle permet de faire une authentification dynamique RSA (avec un challenge) de la carte ce qui protège la carte contre le clonage).

Architecture de clé pour DDA

• disponibilité du CDA, obligatoire en France pour les cartes émises après 2012, qui combine le DDA et le GENERATE AC. Ce mode permet à la fois d'authentifier dynamiquement la carte (DDA) et de valider par une signature la façon dont la transaction s'est déroulée via le GENERATE AC (par exemple, si un PIN a été présenté et vérifié, la carte l'indiquera par un statut qui sera signé).
• des informations sur la façon de gérer le risque qui est une des particularités importante d'EMV par rapport aux premières cartes bancaires françaises. Nous y reviendrons. A ce stade, il suffit de savoir que ces informations permettent de définir le comportement de la carte et du terminal en fonction des états interne de chacun. Par exemple, la carte peut accepter les transactions hors ligne mais demander d'aller en ligne (considéré comme plus sûr) dans certaines circonstances. Cette gestion de risque revient à choisir les contraintes maximum entre celles proposées par la carte et celles proposées par le terminal.

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 :

• le nom du porteur,
• les dates de validité de la carte,
• le PAN,
• l'image équivalente de la piste,
• le code devise de la transaction,
• les services associés à la carte (débit, crédit, retrait, national, international…),
• des règles sur la façon d'authentifier le porteur,
• les objets devant être pris en compte pour la gestion du risque (aléa, montant, type de transaction, etc.),
• des clés publiques, des références de clés à utiliser, des certificats de clés.

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 :

• le nombre d'essais restant pour la présentation du PIN,
• le compteur de transaction en ligne,
• La devise connue de la carte (Euro, Franc...),
• Des plafonds,
• Divers compteurs...

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 terminal authentifie la carte. Il peut le faire en SDA (vérification d'une signature statique) ou en DDA qui est le cas qui nous intéresse :
  • Le terminal lit des données dans la carte. A ce stade, il ne peut pas affirmer que ces données sont authentiques.
  • Parmi ces données, il y a la clé publique de l'émetteur. Celle-ci doit être certifiée par la clé publique du schéma de paiement utilisé (MASTERCARD, CB...). Le terminal connait la clé publique de certification de ce schéma de paiement. Il peut donc vérifier le certificat de la clé publique de l'émetteur. On suppose que cette vérification réussi.
  • Le terminal envoie un challenge à la carte.
  • La carte calcule une signature des données précisées dans son DDOL (Dynamic Authentication Object Data). A minima, un nombre aléatoire (UN, Unpredictable Number) et si possible, d'autres données et renvoie le résultat au terminal.
  • Le terminal vérifie la signature. Si elle est correcte, la carte est authentique.
• On suppose que la transaction autorise l'authentification hors ligne du porteur. Le code porteur est saisi sur le clavier du terminal et envoyé à la carte. L'envoi peut être chiffré (si la carte le supporte) ou en clair. La carte effectue la vérification si elle le peut. En effet, elle peut être bloquée suite à trois essais consécutifs faux précédemment réalisés et dans ce cas, la vérification n'a pas lieu. Dans le cas contraire, la vérification est faite. Si le code porteur est correct, la carte l'indique au terminal, modifie une variable d'état volatile (en mémoire non permanente) pour se souvenir qu'une présentation correcte a eu lieu et met à zéro un compteur de présentation de codes faux en mémoire non volatile. Si le code porteur est incorrect, elle incrémente le compteur de présentation. Si ce compteur atteint un maximum (3 en général), la carte se bloque. On suppose ici que le code est correct.
• Le terminal effectue la gestion de risques de la transaction et propose un mode opératoire pour la suite via un GENERATE_AC. La carte réalise sa propre gestion de risques. Les réponses peuvent être :
  • AAC (Application Authentication Cryptogram) : refus de la transaction.
  • ARQC (Authorization Response Cryptogram) : demande d'autorisation en ligne à l'émetteur.
  • TC (Transaction Certificate) : acceptation de la transaction hors ligne.

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

GENERATE_AC et réponses

Quelques commentaires :

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

Du fait de l'absence constatée de fraude et aussi, de la pandémie du Covid19, ce montant est passé à 50€ en 2020.

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 :

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 :

• L'écoute passive : la conséquence est la possibilité de récupérer des PAN et date de validité. Sur les cartes françaises, le nom du porteur et le log des transactions n'est plus accessible depuis environ 2012 (demande de la CNIL, date de mise en place de la mesure).
  La récupération du PAN et date de validité ne devrait pas engendrer de problème de sécurité. Malheureusement, en 2015, certains sites de e-commerce acceptent des paiements avec ces seules informations. Une contre-mesure pourrait être de disposer d'un PAN dédié au sans contact (PAN tokenisé) non utilisable dans d'autres usages. Sinon, l'OSCP a proposé d'étudier le chiffrement des communications. En pratique, cette contre-mesure dépend d'une modification des standards internationaux ce qui est long et complexe. En 2015, il n'était toujours pas envisagé d'introduire une telle évolution d'autat plus qu'il existe des solutions plus simples (cf. PAN tokenisé) et que le risque de voir cette attaque générer de la fraude reste faible.
• L'activation : la conséquence est la possibilité de récupérer un PAN plus une date de validité (voir attaque précédente) et de faire des transactions (limitées à 20€) à l'insu du porteur. Il faut néanmoins que l'attaquant soit enregistré comme commerçant pour pouvoir bénéficier de ces transactions ce qui limite l'intérêt de l'attaque. Par ailleurs, la portée très faible d'une activation en sans contact rend cette attaque difficile à exploiter en condition réelle et peu rentable (la fraude est un business !). Par contre, dans les années 2010-2015, elle a générée un buzz médiatique significatif. Il faut bien que tout le monde vive.
  Il existe plusieurs contremesures si l'on veut se protéger : pour les cartes, la plus évidente est l'utilisation d'un étui métallique. Pour les équipements de type smartphone, on peut utiliser la capacité de valider une transaction par un acte volontaire préalable du porteur.
• Le brouillage : il n'y a pas de moyen simple de se protéger du brouillage. Par contre, celui-ci est facilement repérable (par principe). En pratique, tous les systèmes utilisant des communications sans fil sont plus ou moins sensibles au brouillage. Dans la pratique, les cas de brouillage (en vue de rendre les systèmes indisponibles) sont exceptionnels.
• Attaques en relais : cette attaque est proche de l'activation mais présente l'avantage pour le fraudeur de ne pas avoir besoin d'être un commerçant. Elle est donc théoriquementfaisable sur les cartes mais en pratique, compliquée à mettre en oeuvre. Elle pourrait être plus simple à réaliser sur des smartphones ou équipements similaires. Voir à ce sujet les aspects sécurité spécifiques dans les chapitres qui suivent pour des paiements réalises par ces types d'équipements.

Bilan (2021)

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 dans les années 2010, il aurait été considéré comme quelqu'un d'un peu dérangé ou un adepte forcené de la théorie du complot.

Mais finalement, la pandémie de Covid19 de 2020 a entrainé une utilisation massive du paiement sans contact. Couplé au développement du paiement sans contact par smartphone, on peut penser qu'il est désormais passé dans les moeurs.

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 :

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

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 » :

• La carte USIM étant dans un smartphone, elle est en permanence sous le contrôle des opérateurs. Cela permet en théorie de l'invalider à distance en cas de déclaration de perte ou vol. De plus, ces cartes peuvent être mises à jour ce qui peut permettre de corriger d'éventuels bogues, y compris, pourquoi pas, de sécurité. En 2009, c'était un des arguments des opérateurs pour expliquer que l'on n'avait pas besoin d'une sécurité intrinsèque aussi élevée sur les cartes USIM que sur les cartes classiques. En 2015,cet argument était toujours cité mais moins mis en avant. Une raison évidente est que le smartphone peut être déconnecté du réseau or il n'a pas besoin d'être connecté pour effectuer un paiement. Qui plus est, comme dit précédemment, cette carte USIM peut être insérée dans autre chose qu'un smartphone qui n'est pas forcément communicant. On se retrouve alors dans les conditions de fonctionnement d'une carte classique ce qui justifie pleinement que le niveau de sécurité soit équivalent.
• Le smartphone peut être utilisé pour valider les paiements. Cela permet de se prémunir contre les attaques par activation.
• Le smartphone est un système informatique comme un autre, potentiellement attaquable par des logiciels malveillants. On peut donc imaginer des attaques prenant le contrôle de la fonction de paiement et/ou de la carte USIM et réalisant des transactions via des attaques en relai. Certes, l'architecture des téléphones Androïd est censée ne pas autoriser cette prise de contrôle. Mais personne ne peut garantir que cette spécification est suivie ou sera suivie par tous les smartphones ou tous les équipements susceptibles d'utiliser les cartes USIM. Et il n'y a pas qu'Androïd. On ne peut donc se baser sur cette propriété pour garantir sérieusement une protection vis-à-vis de ce type d'attaque. C'est à l'utilisateur, dans la mesure de ses moyens, de protéger son système, comme il est censé le faire pour son ordinateur personnel, sa tablette, son réfrigérateur, etc.

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 :

• Une grande partie du marché des smartphones n'étaient pas équipés de la fonction NFC et les fabricants, à part Samsung, semblaient hésiter à la généraliser. En particulier, Apple laissait planer un doute sur l'intégration de cette fonctionnalité. En 2014, l'Apple 6 a proposé le NFC et une fonctionnalité de paiement propre Apple (Apple Pay), entrainant un renouveau de l'intérêt du paiement par smartphone.
• Le parc des terminaux de paiements sans contact ne s'est pas développé aussi vite que prévu (voir précédemment).
• Il semble qu'il y ait eu de grandes difficultés pour les porteurs de smartphones éligibles à mettre en œuvre la fonctionnalité (on parle de « parcours client »). Fin 2014, les banques et les opérateurs, conscients du problème, se sont mis d'accords pour simplifier la procédure.

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.

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 ::

• un smartphone, muni d'un moyen de communication NFC, permettant d'interagir avec un lecteur NFC (un terminal de paiement NFC par exemple).
• un système d'aiguillage associant un AID (Application Identifier) à une applications mobile du smartphone qui interagit avec l'utilisateur.
• un serveur sécurisé comportant des secrets permettant de fournir les secrets particuliers à une application carte qui interagit avec un terminal de paiement.
• un serveur (le même que précédemment) qui émule l'application carte.
• Un moyen de communication sécurisé entre le smartphone et le serveur (le serveur doit être en mesure d'accéder au bon smartphone).

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 :

• L'utilisateur sélectionne sur son smartphone l'application mobile qu'il souhaite utiliser et si nécessaire, s'authentifie en saisissant un PIN.
• l'utilisateur approche son smartphone du TPE.
• Le TPE sélectionne l'application de paiement comme il le ferait avec une carte sans contact habituelle.
• A réception de cette commande, l'application de paiement joue alors les passe-plats entre le smartphone et le serveur qui émule la carte EMV. Vu du TPE, tout se passe comme s'il dialoguait avec une carte locale.

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 ::

• Sélection automatique de l'application de paiement du smartphone lors de l'interaction avec le TPE.
• Interaction de l'application de paiement durant la transaction pour afficher le montant et demander l'accord, voire, l'authentification (PIN, biométrie) du porteur.

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

• On ne dispose pas forcément d'un moyen de communication fiable entre le smartphone et le serveur lors du paiement. On parle alors de transactions « sans connexion au réseau mobile » (ou off band) par opposition à un mode « avec connexion au réseau mobile » (ou on band) supposant une connexion avec un serveur dans le cloud.
• Même si l'on envisage d'être connecté au réseau mobile, il peut être ambitieux de réaliser la transaction dans le temps imposé par certaines applications de paiement du fait des délais de latence.

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 :

• Il faut être en mesure de stocker les credentials de façon sécurisée dans le smartphone afin que les clés cryptographiques ne puissent être compromises. On parle dans ce cas de secure element logiciel qui doit assurer la protection de ces clés dont la sécurité devra être comparée à la sécurité des éléments sécurisés matériels.
• Il faut en stocker suffisamment pour ne pas gêner le porteur dans ses achats alors qu'il ne dispose pas d'un accès au serveur et pas trop pour limiter les risques en cas de compromission de ces credentials.
• Il faut émuler localement (dans le smartphone) le comportement de la carte EMV (ce qui est en pratique n'est pas compliqué, je cite ce point juste pour mémoire).

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 :

• Il faut être en mesure de réaliser une saisie sécurisée du PIN afin que ce dernier ne puisse être compromis (idem pour la biométrie).
• Il faut être en mesure de faire savoir au système de paiement que l'authentification a effectivement eu lieu sans qu'il soit possible de l'émuler.

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 :

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
	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 ».
	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 ».
	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 ».
	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 :

• que le serveur HCE dans le cloud soit en mesure de s'adresser au bon smartphone pour approvisionner des credentials lorsque ce dernier retrouve le réseau mobile. On notera que quelque soit l'architecture, le fait de pouvoir s'adresser au bon smartphone est un invariant.
• Que le smartphone protège les credentials et plus particulièrement, les secrets qu'ils contiennent, jusqu'à leur utilisation.
• Que l'authentification du porteur, lorsqu'elle est nécessaire, ne puisse être outrepassée et que l'authentifiant du porteur ne puisse être compromis. Cette fonctionnalité est aussi un invariant quelque soit l'architecture.

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 :

• la détection de mode debug. Le logiciel tente de se protéger contre des tentatives d'exécution en mode debug (matérielle et/ou logicielle).
• la (tentative de) détection de fonctionnement en mode virtualisé.
• la détection d'intégrité du logiciel en cours d'exécution.

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 :

• Comparaison avec la valeur attendue stockée dans l'application de paiement (obfusquée).
• Une variante est de comparer le hash de la valeur saisie au hash de la valeur attendue ce qui évite d'avoir la valeur du PIN dans l'application de paiement.
• Une variante est de comparer le MAC (hash avec une clé) de la valeur saisie au MAC de la valeur attendue. Le calcul du MAC peut se faire à l'aide d'une clé contenu dans le crédential devant être utilisé pour un paiement. Cette façon de faire évite que la valeur du PIN soit dans l'application de paiement.

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

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.

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 :

• Le TEE :: le Trusted Environment Execution est un environnement d'exécution sécurisé proposé par certains processeurs dont les processeurs ARM via la TrustedZone qui équipent le plus grand nombre des smartphones Androïd en 2015. Le TEE peut améliorer la confiance dans l'intégrité des programmes et dans une certaine mesure, la confidentialité dans les données qu'ils manipulent. Reste à déterminer qui décide quel programme peut s'exécuter dans la TEE, sur quels appareils et que ce passe-t-il pour ceux qui n'ont pas de TEE (ou qui ne la gère pas).

• L'utilisation d'un élément sécurisé matériel : la plupart des smartphones disposent d'un élément sécurisé via la carte (U)SIM. Il serait tout fait possible de l'utiliser comme ressource cryptographique pour sécuriser une implémentation HCE logicielle. La spécification Mobile Connect proposée par la GSMA en 2014 pourrait être un bon candidat pour ce type d'implémentation. Mais il y a quelques inconvénients qui ne sont pas forcément techniques. Le plus évident en 2015 est, pour ceux qui voulaient fermer la porte aux opérateurs téléphoniques proposant le SIM centric, de les voir réapparaitre par la fenêtre.

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

Paiement mobile Secure Element embedded

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 :

• Il peut s’agir d’un élément sécurisé du même type que celui utilisé pour les cartes à puce. Sous réserve que cet élément soit mis en oeuvre avec les mêmes règles de l’art que pour les cartes, le niveau de sécurité est équivalent, en particulier si on le compare à celle des cartes USIM émises en France. La seule différence est que si une vulnérabilité est découverte sur cet élément sécurisé, il n’est pas possible de le changer. Dans certains cas, on peut la corriger (correctif logiciel transmis over the air (OTA)). Mais il existe des cas où la vulnérabilité n’est pas corrigeable et il faut vivre avec ou changer de smartphone.
• Il peut s’agir d’un élément sécurisé intégré dans un chipset. En 2015, il est difficile de déterminer le niveau de sécurité d’une telle solution. On peut simplement faire remarquer que les fabricants de chipset ne sont pas forcément des spécialistes dans la conception des composants sécurisés et il convient donc d’être réservé sur cette approche.

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 :

• l'émetteur et le gestionnaire du PME,
• une banque de dépôt,
• les banques des utilisateurs,
• les banques des commerçants,
• les prestataires de services (commerces, téléphone, stationnement...),
• les porteurs (utilisateurs du PME).

Les moyens techniques utilisés étaient :

• des CAM destinés aux porteurs. Ces CAM sont les PME du système.
• des systèmes de paiement (des terminaux de paiements électroniques (TPE) par exemple),
• des distributeurs automatiques de monnaie électronique (DAME),
• un système monétique.

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 :

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 :

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'ont rêvée, les allemands l'ont faite ».

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'aurais 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)  :

• 1986, première expérimentation de la carte SESAM par la CNAM-TS (Caisse Nationale d'Assurance Maladie des Travailleurs Salariés) sur 6 sites : Blois, Lens, Evreux, Rennes, Charleville-Mézière, Bayonne) et utilisation de la MPS-DT (Machine pour Professionnels de Santé – Dispositif de Transmission.
• 1991, naissance du schéma directeur « carte  » soutenu par les trois principaux régimes d'assurance maladie obligatoire. Il décrit la mise en œuvre de Sesam-Vitale jusqu'au système cible.
• 1993, création du GIE SESAM VITALE
• 1994, 550000 cartes distribuées sur 4 sites expérimentaux de masse (Boulogne-sur-mer, Bayonne, Charlevilles-Mézière, Rennes).
• 1995, premiers échanges de feuilles de soin électroniques (FSE) sur les sites expérimentaux. D'août à décembre 1995, le nombre de FSE mensuelles passe de 99000 à 166000.
• 1996, diffusion de nouvelles cartes à Blois pour permettre la qualification de la carte CPS (Carte Professionnelle de Santé). En avril, publication de l'ordonnance relative à la maitrise médicalisée des dépenses de soins. Juin 1996, lancement des appels d'offre pour la fourniture des équipements (cartes, bornes, lecteurs…).

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

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

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 pouviez aller sur le www.telemedecine.org qui a disparu depuis que j'ai écrit ce paragraphe mais 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.

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

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.

Pour en savoir plus sur l'histoire

Si vous voulez en savoir plus sur l'histoire de la carte santé, voici quelques articles dont certains assez croustillants, parus dans la presse entre 1992 et 2001 et qui montre que ce projet n'a pas été un long fleuve tranquille (si on pouvait encore en douter). Les articles sont classés par dates lorsque je les ai conservées (sinon, date environ). Ensuite, il y a le nom de la revue lorsque je l'ai (sinon, revue inconnue). Enfin, il y a tout ou partie du titre de l'article ou du dossier.

• 1992-02-24, revue inconnue (probable, les Echos), Carte santé, le gouvernement lance un groupement d'intérêt public (GIP-CPS)
• 1992-06-01, Gestion hospitalière, Dossier sur la carte à mémoire
  • Les professionnels de la santé et la carte à mémoire
  • Développements et perspectives de la carte à microprocesseur
  • La carte à mémoire: aspects industriels
  • La carte santé: état de l'art en 1992
  • VITALE-SESAM (sic)
  • La carte professionnelle de santé
  • SANTAL, une carte de santé à mémoire au service d'un système de communication plus ouvert
  • DIALYBRE, une application de la carte à mémoire au service des dyalisés
• 1994-03-07, Le Quotidien du Médecin, La carte santé pourrait aussi inclure le dossier médical du patient
• 1994-08-30, Le Quotidien du Médecin, Carte santé, la grande bataille: pour quelques milliards d'enjeux
• 1994-08-31, Le Quotidien du Médecin, Carte santé, la grande bataille: les ratés de l'expérience de Chateaubourg (Ille et Vilaine)
• 1994-10-17, Le Quotidien du Médecin, Sésame-vitale: l'expérience de Vitré différée
• 1995, Le Monde, L'an I du projet Sésam-Vitale a débuté dans les Ardennes
• 1995-01-20, Espace Social Européen, Carte santé: l'avenir en question
• 1995-01-31, La Tribune Desfossés, 1995, les français découvrent la carte santé
• 1995-02-11, Ouest France, La carte à puce santé arrive à petits sauts
• 1995-05-01, Stratégie Santé, Santé, le grand chantier informatique
• 1995-06-12, Le Quotidien du Médecin, Un rapport officiel critique l'imprécision de coût de la carte SESAM-VITALE
• 1996-01-01, World Card Technology, SANTAL, the French smart health card application
• 1996-03-15, Le Monde Informatique, La carte santé bientôt débloquée?
• 1996-03-21, Electronique International, Carte Santé: le plan Juppé pourrait enterrer la carte à microprocesseur
• 1996-05-06, Les Echos, Carte professionnelle de santé: le feu passe au vert
• 1996-06-12, Le Monde Informatique, Carte santé: Sesam, ouvre-toi!
• 1996-07-12, Le Monde Informatique, Le poste de travail du médecin en question
• 1996-10-23, Libération, 45 millions de carnets de santé
• 1996-11-21, Electronique International, Un grand pas franco-allemand vers la carte santé européenne
• 1996-12-13, Le Monde Informatique, Intranet tout de suite!
• 1997-02, l'Ordinateur Individuel, Une puce pour veiller sur votre santé
• 1997 environ, revue inconnue, Carte à puce pour 12 millions d'assurés en 1998
• 1997 environ, revue inconnue, Bull va fournir le logiciel de la carte Vitale
• 1997 environ, revue inconnue, La carte électronique d'assuré social sera généralisée à la fin 1998
• 1997 environ, Le Canard enchainé, La sécu lance ses puces savantes pour mettre en carte médecins et assurés sociaux
• 1997 environ, revue inconnue, Sesam-Vitale: tous derrière la CNAM
• 1997 environ, revue inconnue, Soins: la révolution informatique
• 1997 environ, revue inconnue, Un appel d'offres singulier
• 1997-01-17, Le Monde Informatique, Sésam-Vitale: la CNAM campe sur son réseau
• 1997-01-31, Le Monde Informatique, L'assurance maladie s'ouvre à l'intranet
• 1997-02, revue inconnue, Le système de santé doit être reconfiguré en vol
• 1997-03, Logiciels et systèmes, Dossier: les enjeux de l'informatique de santé
• 1997-05-28, La Tribune, La carte santé entre gestion et organisation
• 1997-06-01, L'Atelier, Le réseau santé alimente les médecines en informations personnalisées
• 1997-12-19, 01 Informatique, Sésam-Vitale: la méthode est-elle bonne ?
• 1998, revue inconnue, Carte santé: la Bretagne en première ligne
• 1998, revue inconnue, Cégétel s'occupe officiellement de notre santé
• 1998, Sesam-Vitale, Cartographie de la diffusion de la carte santé
• 1998-01-02, Les Echos Cégétel sera maitre d'oeuvre du réseau intranet santé-social
• 1998-02-23, Décision Micro et Réseaux 400000 professionnels de santé s'informatisent sous la contrainte
• 1998-03-06, 01 Informatique, Sésam-Vitale: Les députés tirent le signal d'alarme
• 1998-04-03, 01 Informatique, Sésam-Vitale démarre en Bretagne
• 1998-04-10, Le Revenu français, Sésam-Vitale... Dévitalisée ?
• 1998-04-14, Libération, Un réseau informatique pour mieux soigner
• 1998-05, Réseaux et Télécoms, Le CHU de Strasbourg sécurise avec la carte santé
• 1998-05-04, Décision Micro et Réseaux, Une carte à puce pour sécuriser les données des patients
• 1998-05-06, Libération, La carte Vitale n'a pas le ticket
• 1998-05-07, Le Monde, La carte Vitale amorce l'informatisation du système de santé
• 1998-12-11, Le Monde, Un rapport révèle de graves erreurs dans l'informatisation de l'assurance maladie
• 2000 environ, revue inconnue, Un terminal portable pour la carte Vitale (société Sephira)
• 2000-06, Programmez!, Sésam-Vitale: de quoi se rendre malade ?
  • Sésam: grillé ?
  • Des gentlemen hackers montrent les failles grotesques du RSS chez Cégétel-Vivendi
  • Un enfantement dans la douleur
  • Docteur patch, le pionnier
  • Panique en sésamologie
  • Vitale 2, le retour
  • LEs médecins contre-attaquent
• 2000-10-13, 01 Informatique, Pas encore entrée dans les moeurs, la carte vitale prépare sa version 2
• 2001-02-02, Le Monde Informatique, La carte Vitale amorce l'informatisation du système de santé
• 1998-05-07, Le Monde, Un bon réseau, c'est Vitale

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

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

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.

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

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 :

• lorsque la puce du passeport est lue, il est possible, dans certains limites et dans certains contextes, de récupérer à l'insu du porteur l'échange entre le lecteur légitime (le terminal de vérification) et la carte.
• Dans certaines conditions (faible distance), il est possible d'activer la puce du passeport à l'insu du porteur afin d'en lire le contenu.

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 :

• Une fonction de contrôle d'accès aux données ;
• Une fonction de chiffrement des échanges entre le terminal légitime et la puce.

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

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

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 https://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.

• Basic Access Control (BAC). In 2005 Marc Witteman showed that the document numbers of Dutch passports were predictable, allowing an attacker to guess/crack the key required for reading the chip. In 2006 Adam Laurie wrote software that tries all known passport keys within a given range, thus implementing one of Witteman's attacks. Using online flight booking sites, flight coupons and other public information it's possible to significantly reduce the number of possible keys. Laurie demonstrated the attack by reading the passport chip of a Daily Mail's reporter in its envelope without opening it. Note that in some early biometric passports BAC wasn't used at all, allowing attacker to read the chip's content without providing a key.
   
  Cette attaque est en partie acceptable. En partie car les premières spécifications du passeport ne prenaient pas en compte les problèmes potentiels de vie privée. Il aurait plutôt fallu s'en désoler mais annoncer comme un exploit que l'on arrive à lire les données d'un passeport sans BAC qui par constructions sont lisibles n'est pas une bonne façon de présenter les choses (cf. dernière phrase de l'article). Par contre, à partir du moment où il a été décidé de mettre un contrôle d'accès (en l'occurence, le BAC), il était beaucoup plus intéressant d'en montrer la faiblesse de conception, ce que décrit effectivement bien le début de l'article.
   
  
• Passive Authentication (PA). In 2006 Lukas Grunwald demonstrated that it is trivial to copy passport data from a passport chip into a standard ISO/IEC 14443 smartcard using a standard contactless card interface and a simple file transfer tool. Grunwald used a passport that did not use Active Authentication (anti-cloning) and did not change the data held on the copied chip, thus keeping its cryptographic signature valid.[…]
   
  Cette « démonstration » n'a aucun intérêt puisque rien dans les spécifications du passeport n'interdit sa copie et sa reproduction. Au mieux, l'auteur a démontré que le passeport était conforme à ses spécifications dont sa conformité aux normes ISO7816 établies depuis les années 1980 et celles qui ont suivi pour le sans contact…
   
  
• Active Authentication (AA). In 2005 Marc Witteman showed that the secret Active Authentication key can be retrieved using power analysis.[…]
   
  Ce n'est pas une attaque associée à la spécification du passeport mais à son implémentation. Ce type d'attaque est réalisable pour tous les produits pour lesquels il n'a pas été mis en œuvre de contre mesures vis-à-vis des attaques DPA (ou SPA ou EMA, etc.). D'où l'intérêt de procéder à des évaluations sécuritaires pour limiter ce risque. Mais ce n'est pas dans la philosophie des pays anglo-saxons (du moins, jusqu'à 2012). Il aurait fallu écrire : « certaines implémentations du passeport électronique sont sensibles aux attaques DPA… ».
   
  
• […] In 2008 Jeroen van Beek demonstrated that optional security mechanisms can be disabled by removing their presence from the passport index file[…].
   
  Encore une attaque liée à l'implémentation et non aux spécifications. Voir le commentaire précédent. Il aurait fallu écrire : « certaines implémentations du passeport électronique ne garantissent pas l'intégrité des données qu'elles mémorisent » (une implémentation correcte du passeport n'autorise pas la modification des données mémorisées sans contrôle (voire, n'autorisent pas du tout).

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