La Tokenisation

De nombreux dangers sont présents lors d’un paiement sur la toile ou en sans-contact. Contrairement au paiement de proximité où le porteur insère sa carte dans un terminal créant ainsi un sentiment de sécurité, les données sont plus accessibles lors de transactions sur Internet ou NFC. En effet, d’un côté, l’installation d’un malware au sein de la machine permettra la récupération du triplet numéro de carte / date d’expiration / cryptogramme visuel, de l’autre un sniffer décodera le trafic NFC afin de récupérer le couple numéro de carte / date d’expiration. Face à cette problématique, une réponse a été apportée : la tokenisation. Cette dernière permet l’utilisation de données bancaires jetables. Ainsi  nous mettons-nous à l’abri des conséquences financières faisant suite à un vol de données. Mais qu’est-ce que la tokenisation ? Comment cela fonctionne ? Autant de questions auxquelles répondra cet article.

Le concept informatique de tokenisation n’est pas tout nouveau. La clé artificielle apparue dans les années 70 dans le domaine des bases de données est en effet précurseur. En revanche, la spécification récente (mars 2014) rédigée par EMVCo (organisme regroupant plusieurs réseaux bancaires comme MasterCard et Visa) risque d’accélérer l’adoption de la tokenisation par les banques.

Définition

En monétique, la tokenisation est le processus de substitution de données bancaires (numéro de cartes, …) par des données jetables appelées « jeton » (token en anglais). Cette solution permet de rassurer le porteur, notamment en paiement sur Internet ou en NFC. Pour le commerçant, c’est un moyen de réduire le périmètre de PCI-DSS puisque aucun élément sensible ne sera stocké dans son système d’information. Pour la banque du porteur (émetteur), il s’agit simplement d’un moyen de réduire la fraude. Tous les acteurs de la chaîne monétique (à l’exception… des fraudeurs) y trouve donc leur intérêt, ce qui explique l’enthousiasme de chacun vis-à-vis de la tokenisation.

Tokeniser
Tokeniser

Note : pour qu’un système monétique, par lequel transite un token, soit en dehors du périmètre « PCI DSS », il faut que le numéro du token ne puisse pas être réversible, c’est-à-dire qu’il n’existe pas d’algorithme permettant de déduire le PAN à partir du numéro du token.

La détokenisation désigne tout simplement le processus inverse, à savoir la possibilité de retrouver le vrai numéro de carte à partir du token.

Détokeniser
Détokeniser

Le fonctionnement

Afin de bien appréhender son fonctionnement global, il convient de dissocier plusieurs étapes dans le processus de tokenisation :

  1. Prérequis
  2. Création d’un token
  3. Paramétrage du token
  4. Utilisation du token
  5. Compensation

Prérequis

Une entité désirant devenir fournisseur de service de token (Token Service Provider) doit faire au préalable une demande d’un ou plusieurs codes d’identification de banque (BIN) auprès du réseau bancaire de son choix. A l’instar d’une banque souhaitant émettre une carte, le BIN permettra au fournisseur d’émettre un token avec la garantie qu’il ne corresponde à aucun numéro de carte déjà existant.

Rappel : le BIN (Bank Identification Number) est les 6 premiers chiffres du numéro de carte bancaire et est attribué à un émetteur.

Une entité désirant implémenter le service de tokenisation (Token Requestor) doit s’enregistrer auprès d’un fournisseur de service de tokens. En retour, le fournisseur envoie un identifiant unique (Token Requestor ID).

Création d’un token

Lorsqu’il souhaite obtenir un token, le portefeuille électronique ou le portable NFC HCE demande au Token Requestor de réaliser une demande d’émission de tokens au fournisseur en lui communiquant au minimum :

  • le numéro de carte réel du porteur ;
  • la date d’expiration de la carte ;
  • son identifiant (Token Requestor ID).

Note : d’autres données peuvent être envoyées comme un score de risque de fraude, le niveau de vérification souhaitée ou l’emplacement du token (puce, Secure Element local, …). Ces champs ont été écartés de l’article par soucis de simplicité mais n’hésitez pas à poser des questions si besoin.

En cas de réponse positive, le fournisseur génère un token commençant par son BIN (celui acquis par le fournisseur) et stocke dans son coffre-fort la correspondance entre le token et les données de la vraie carte. Il envoie en retour :

  • le numéro du token ;
  • la date d’expiration du token ;
  • le cryptogramme du token.

Ces informations seront stockées précieusement dans le portefeuille ou dans le mobile NFC (paiement HCE en mode déconnecté).

Création de token
Création de token

Paramétrage du token

La banque du porteur (émetteur), le réseau bancaire et le Token Requestor peuvent intervenir sur le cycle de vie (activation, désactivation, suspension, …) des tokens. Pour ce faire, il leur suffit d’effectuer une demande de maintenance au Token Requestor qui se charge de modifier le statut dudit token.

Utilisation du token

En cas d’utilisation du service de tokenisation lors d’un paiement (paiement mobile, paiement sur Internet, …), les données bancaires propres à la carte du porteur sont remplacées par un token, comme suit :

  • le champ « numéro de carte » contient celui du token ;
  • le champ « date d’expiration » contient celle du token.

Par ailleurs, deux nouveaux champs font leur apparition :

  • le cryptogramme du token ;
  • l’identifiant unique du Token Requestor.

Une fois les données acquises par l’accepteur, une demande d’autorisation est envoyée  au Serveur d’Autorisation de la banque Acquéreur (SAA). L’acquéreur envoie l’autorisation sur le réseau qui l’achemine ensuite au Token Requestor. Ce dernier consulte son coffre-fort, afin de la « détokeniser ». Ce processus inverse consiste à remplacer les données du token par celles de la véritable carte. Ainsi, les champs de la demande d’autorisation sont modifiés comme suit :

  • le champ « numéro de carte » récupère celui de la carte réelle du porteur ;
  • le champ « date d’expiration » récupère celle de la carte réelle du porteur ;
  • le informations relatives aux tokens (numéro du token et date d’expiration) sont recopiés dans deux champs spécifiques.

Dès lors ce traitement effectué, l’autorisation est envoyée au serveur d’autorisation de la banque émetteur (SAE). L’émetteur effectue ses contrôles de manière classique et fournit une réponse.

Suite à réception, le réseau maquille l’autorisation en recopiant le numéro du token et sa date d’expiration dans les champs « numéro de carte » et « date d’expiration » et supprime les champs spécifiques relatifs au token (numéro et  date d’expiration du token). Puis, la réponse à la demande d’autorisation continue son chemin en sens inverse jusqu’au point accepteur.

Utilisation du tokenn
Utilisation du token

Compensation

Lorsque l’accepteur réalise sa télécollecte, il envoie à l’acquéreur les données du token. Ses données sont ensuite envoyées au réseau concerné pour faire l’objet d’une compensation avec l’émetteur. Comme dans le cas de l’autorisation, le réseau appellera le Token Provider afin qu’il détokenise les données. Le reste est classique.

Ce service risque d’être incontournable dans les mois à venir.En effet, comme évoqué dans les paragraphes ci-dessus, ce service nécessite relativement peu d’évolution de la part des acteurs monétiques. D’autant que l’utilisation d’un numéro de carte unique apporte un vrai plus en matière de sécurité et cela permettra aux différents acteurs concernés de réduire leur périmètre PCI-DSS. Comme dans la vraie vie, les coffres-forts ont intérêt à être bien sécurisés puisque à ne pas douter, ils risquent d’attirer fortement les convoitises.

0 commentaires à propos de “La Tokenisation

  1. dans le schéma 1 : à quoi sert le token requestor, pourquoi ne pas intérroger directement le fournisseur de token ?
    dans le schema 2 : quelle est la différence entre l’acquéreur et l’émetteur

    • Bonjour,
      Le Token Requestor est un acteur qui respecte les spécifications EMV relatives à la tokenisation afin de dialoguer avec le Token Service Provider. Techniquement, rien n’empêche les points d’acceptation (smartphone NFC, site web, etc.) de devenir Token Requestor. Mais, peu de chance que ces derniers se lancent dans de tels développements. Généralement, cela est sous-traité à des acteurs spécialisés.

      Acquéreur = banque du commerçant.
      Emetteur = banque du porteur (du moyen de paiement).

      Kévin

    • Bonjour,

      La sécurité entre les deux ne relève pas de EMV. Néanmoins, on peut penser qu’une authentification sera réalisée ainsi qu’un chiffrement des données (https).
      Par ailleurs, un token cryptogram est généré par le token service provider lors de la génération d’un token. Ce token cryptogram doit par la suite être envoyé par le portefeuille électronique au token requestor qui l’enverra au token service provider afin de le valider. Cela permettra la détection de l’altération des données de l’autorisation.

      Kévin

  2. salut, en premier lieu je tiens a vous remercier pour l’article qui est bien clair, Sinon j’aimeari bien savoir c’est quoi la différence entre Token BIN et Token Bin Range?

    • Bonjour Soufiane,

      Merci pour votre commentaire. Pour répondre à votre question, le Token BIN désigne le BIN d’un token tandis que le Token BIN Range désigne la plage des BIN accordée à l’émetteur pour l’émission d’un token.

      Kévin

        • Soufiane,

          Sauf erreur, rien n’oblige à ce que le BIN et le Token BIN soient différents. La longueur du PAN et du Token Payment peuvent même être différents.
          La seule contrainte est que le Token Payment soit différent de tous les PAN existants pour des raisons évidentes.

          L’association entre le Token BIN et le BIN se fait dans les tables de routage gérées par les réseaux.

          Cdlt,
          Kévin

          • Merci encore fois pour votre réponses. mais d’après ce qui j’ai compris que le BIN est Unique donc pour la genération du Token et pour qu’il soit différent il faut que 6 premiers chiffres commençant par le BIN.

            je me demande si sera Possible de vous contacter par Mail , car en faite j’ai un projet pareil a réaliser c’est l’implémentation de la norme EMV Paiement tokenisation, et j’ai besoin d’aide

            Bien amicalement,

  3. Bonjour,
    Dans le schéma de création de token et dans le cas d’un wallet NFC, un point me semble étrange : pourquoi doit-on donner en input du Token requestor le PAN puisque l’objectif justement est de ne pas stocker le PAN sur le mobile et d’éviter de le faire circuler dans des flux ?
    Dans le cas d’un wallet HCE, ne peut-il pas y avoir le cas de figure : Wallet > id mobile banque> Banque Emetteur > TSP, pour obtenir un token ? Auquel cas le PAN reste au niveau de la banque émetteur, et n’est pas supposé provenir du wallet HCE ?
    Merci de votre réponse.

    • Bonjour Simon,

      l’objectif justement est de ne pas stocker le PAN sur le mobile
      Ce n’est pas l’objectif. En SIM-Centric, le PAN est bel est bien stocké sur le téléphone.
      Le PAN est envoyé au Token Requestor pour la génération d’un token. Sans cela, le Token Service Provider ne serait pas capable de faire le lien entre le PAN et le token.
      Pour le wallet HCE, le cas que vous proposez n’existe pas. En tous les cas, ce n’est pas prévu pour le moment.

      Cdlt,

      Kévin

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*