Article technique
Développer pour EMV, Partie I
ID TECH fabrique et commercialise une large gamme d'appareils de paiement, dont la quasi-totalité est aujourd'hui compatible avec les « cartes à puce » (ou « cartes intelligentes »). Les paiements effectués avec une carte à puce sont communément désignés sous le terme « EMV contact », ou parfois simplement « EMV ». (EMV est bien sûr l'acronyme d'Europay, Mastercard et Visa, le consortium des réseaux de cartes.)
Dans le jargon du secteur, une transaction EMV est une transaction conforme aux exigences des quatre volumes des EMV Integrated Circuit Card Specifications for Payment Systems (disponibles sur https://www.emvco.com/). S'approprier cette spécification demande du temps. Avec ses quatre volumes, il s'agit d'un référentiel particulièrement dense. ID TECH s'efforce toutefois de faire de la « compatibilité EMV » un objectif accessible aux développeurs, en proposant une gamme variée d'outils gratuits, de SDK, de démos et d'autres ressources conçues pour accélérer la mise sur le marché des intégrateurs de points de vente et de tous ceux qui ont besoin de EMV.
EMV : par où commencer ?
La plupart des nouveaux clients d'ID TECH sont des profils très avertis sur le plan technique. Malgré cela, le niveau de connaissance EMV qu'ils apportent à un nouveau projet varie considérablement. La majorité maîtrise parfaitement les systèmes de paiement dans le contexte des lecteurs MSR (lecteurs de piste magnétique). Certains ont déjà travaillé avec EMV, mais ne connaissent pas l'EMV sans contact . D'autres découvrent EMV pour la première fois.
À titre de référence, nous recommandons généralement aux intégrateurs de consulter le livre blanc gratuit d'ID TECH intitulé EMV Transactions with the Universal SDK. La première moitié de ce livre blanc de 25 pages propose un rappel sur le déroulement des transactions EMV. Les principales étapes de ce flux peuvent être résumées ainsi :
À chaque étape de ce processus, le lecteur de carte communique avec la puce de la carte à puce en utilisant des protocoles de très bas niveau définis dans la norme ISO-7816. La quasi-totalité de la logique du lecteur de carte à cet égard est encapsulée dans ce que l'on appelle un EMV Level 2 kernel. En d'autres termes, cette logique est hors de portée du développeur d'application de paiement, qui n'a à se préoccuper que d'émettre des commandes vers le kernel (et non vers la carte elle-même). Même cela est quelque peu inexact. Le développeur d'application de paiement enverra en réalité des commandes au lecteur; et le lecteur se chargera des interactions sous-jacentes nécessaires avec le kernel, qui (à son tour) interagira avec la carte.
Communication avec le lecteur
Comment envoyer des commandes au lecteur ? Deux options s'offrent à vous :
- Établissez une connexion (généralement via USB ou RS-232) avec le lecteur et envoyez-lui directement des commandes firmware. Ou bien :
- À l'aide d'un SDK en langage de haut niveau, écrivez du code (en C/C++, C#, Objective-C, Java ou Swift) qui exploite la bibliothèque SDK appropriée d'ID TECH pour émettre les commandes firmware sous-jacentes.
La deuxième méthode est généralement plus simple, car il faut comparativement peu de temps pour maîtriser les API en langage de haut niveau du SDK universel d'ID TECH (de plus, nous vous fournissons de nombreux exemples de code sur lesquels vous appuyer). L' inconvénient de la méthode n° 2 est qu'elle tend à lier votre application à un seul langage de développement et à un seul système d'exploitation. Avec la méthode n° 1, le choix du langage (et du système d'exploitation) vous appartient, mais vous devez apprendre l'API de commandes firmware (au niveau octet) propre à l'appareil concerné et gérer vous-même toutes les problématiques de connectivité.
Que vous choisissiez de communiquer directement avec le lecteur de carte (via une connexion série, à l'aide de commandes firmware brutes) ou d'utiliser la connectivité intégrée et les commandes de haut niveau du SDK universel, il est important de comprendre qu'une transaction EMV — et j'entends ici le contact EMV traditionnel, avec contact , et non le sans-contact — se déroule en trois étapes. Dans la terminologie du SDK universel, nous désignons ces étapes comme suit : Démarrer la transaction (Start Transaction), Authentifier la transaction (Authenticate Transaction) et Finaliser la transaction (Complete Transaction). (Chacune correspond à une méthode ou une fonction dans le USDK.) Du point de vue du flux d'exécution, cela signifie que le kernel rend le contrôle à l'appelant à deux reprises au cours du déroulement de la transaction : une première fois après le retour de Start Transaction, et une seconde fois après Authenticate Transaction (mais avant Complete Transaction). Ces points d'arrêt ont des implications importantes pour le flux de données, notamment parce que des TLV (triplets tag-longueur-valeur) différents sont retournés à l'issue de chaque phase de transaction. Il est donc essentiel de récupérer les TLV dont vous avez besoin au moment où ils sont disponibles, car ils pourraient ne plus l'être lors d'une phase ultérieure. Exemple classique : le Tag 57 (données de la piste 2) est disponible à la fin de Start Transaction, mais pas à la fin de Complete Transaction.
Les cryptogrammes dans EMV
L'une des données les plus importantes dans toute transaction EMV est le cryptogramme d'application retourné dans le tag 9F26. Une session EMV avec contact produit généralement deux cryptogrammes (9F26 est retourné deux fois) : l'un intervient avant Complete Transaction, l'autre après. L'événement qui amène la carte à générer le cryptogramme est appelé une requête Gen AC (Generate Application Cryptogram).
Si ces cryptogrammes revêtent une telle importance, c'est qu'ils constituent la preuve irréfutable qu'une carte à puce authentique et légitime était physiquement présente lors d'une transaction donnée. (Ils certifient également les valeurs de données spécifiques générées au cours de cette transaction.) Au moment du Gen AC, le noyau L2 soumet à la carte à puce une liste d'objets de données (contenant des données propres à la transaction en cours), et la carte à puce répond en utilisant sa clé privée (connue d'elle seule) pour signer ces données et produire un artefact numérique infalsifiable (un cryptogramme de 8 octets) qui atteste de la légitimité de la carte et des données. La validité du cryptogramme peut être vérifiée par l'autorité en ligne qui sera chargée d'autoriser la transaction (ou de la refuser, selon le cas). C'est précisément pour cela que les cartes à puce ont été inventées, et que EMV existe. Les données de piste magnétique sont faciles à contrefaire. Les cryptogrammes générés à la demande par une puce, en revanche, ne le sont pas.
Dans mon prochain article, nous poursuivrons cette discussion en examinant les types de cryptogrammes que la carte peut produire, leur signification, ce que le développeur d'application de paiement doit en faire, et leur impact sur le succès ou l'échec d'une transaction. Ne manquez pas la Partie II !
Vous avez des questions sur les transactions EMV ? Les lecteurs de cartes ? La technologie sans contact ? Les portefeuilles numériques ? Contactez nos experts :