Article technique
Développer pour EMV, Partie I
ID TECH conçoit et commercialise une large gamme de terminaux 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 simplement « EMV ». (EMV est bien entendu 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 de la 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. Cependant, ID TECH s'efforce de faire de la « conformité EMV » un objectif facilement accessible pour les développeurs, en proposant une variété d'outils gratuits, de SDK, de démonstrations et d'autres ressources conçus pour accélérer la mise sur le marché des intégrateurs de points de vente et de tous ceux qui ont besoin d'une mise en œuvre rapide. conformité EMV.
EMV : par où commencer ?
La plupart des nouveaux clients d'ID TECH sont de solides techniciens. Malgré cela, le niveau de connaissance EMV qu'ils apportent à un nouveau projet varie considérablement. La majorité maîtrise très bien 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 sans contact EMV. D'autres sont nouveaux dans EMV lui-même.
À 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 une remise à niveau sur le déroulement des transactions EMV. Les principales étapes de ce processus 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 effet est isolée dans ce que l'on appelle un EMV Level 2 kernel. Autrement dit, il est hors de portée du développeur d'application de paiement, qui n'a à se préoccuper que d'envoyer des commandes au kernel (et non à 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 :
- Établir une connexion (généralement via USB ou RS-232) avec le lecteur et lui envoyer directement des commandes firmware. Ou bien :
- En utilisant un SDK en langage de haut niveau, écrire 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 relativement peu de temps pour maîtriser les API en langage de haut niveau du SDK universel d'ID TECH (de plus, nous mettons à votre disposition de nombreux exemples de code sur lesquels vous appuyer). L'inconvénient de la solution n°2 est qu'elle tend à lier votre application à un seul langage de développement et à un seul système d'exploitation. Avec la solution 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 des octets) propre au périphérique concerné, et gérer vous-même l'ensemble des problèmes 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 essentiel de comprendre qu'une transaction EMV — en parlant ici du EMV à contact traditionnel, et non du sans-contact — se déroule en trois étapes. Dans le vocabulaire du SDK universel, ces étapes sont désignées comme suit : Start Transaction, Authenticate Transaction et Complete Transaction. (Chacune dispose d'une méthode ou d'une fonction correspondante dans le USDK.) Du point de vue du déroulement du programme, cela signifie que le noyau rend le contrôle à l'appelant à deux reprises au cours du flux de 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 différents TLV (triplets tag-longueur-valeur) 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 typique : le Tag 57 (données de 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 à contact génère généralement deux cryptogrammes (9F26 est retourné deux fois) : l'un est produit avant la finalisation de la transaction, l'autre après. L'événement qui invite la carte à produire le cryptogramme est appelé une requête Gen AC (Generate Application Cryptogram).
Ces cryptogrammes revêtent une importance capitale car 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) attestant 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é créé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, eux, 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, les actions que le développeur d'application de paiement doit entreprendre à leur égard, et leur incidence 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 :