Pour un marchand en ligne, être conforme à PCI-DSS se traduit par appliquer une série de mesures de sécurité obligatoires à l’ensemble des équipements susceptibles de traiter, de voir passer ou de stocker un numéro de carte bancaire. Cela va du terminal de paiement au serveur chargé de traiter la transaction en passant par la base de données clients si elle conserve les numéros des cartes bancaires. Mais pour autant la conformité n’est pas une fin en soit : si le commerçant peut réduire le nombre d’équipements soumis à PCI-DSS il fera certainement des économies !

Pour cela, une seule solution : retirer les numéros de carte d’un maximum de systèmes. Les bons élèves ont ainsi déjà traqués les dépôts sauvages de numéros de cartes bancaires (copiés localement par un employé dans un classeur Excel, par exemple). D’autres ont quant à eux aussi optimisé les processus métiers afin que l’acte de paiement ne concerne qu’un minimum de machines (ce que conseille d’ailleurs PCI-DSS). C’est déjà ça de moins à traiter, mais ce n’est pas suffisant car une telle mesure ne touchera en définitive que les systèmes qui ne sont pas essentiels. Mais il restera toujours une multitude d’équipements qui, eux, nécessitent pour leurs traitements un numéro de carte bancaire (appelé PAN dans le jargon bancaire).

A ce stade le chiffrement pourrait apparaître comme la solution idéale. Et c’est d’ailleurs une approche très répandue. Hélas, le chiffrement ne fait pas sortir un système du périmètre PCI DSS, il se contente de le rendre conforme. « PCI concerne toutes les machines qui voient le PAN en clair ou chiffré », confirme Frédéric Charpentier, QSA (auditeur PCI) pour le cabinet XMCO. Et encore, le chiffrement rend la machine conforme lorsqu’il est correctement mis en oeuvre : selon une étude menée par Verisign auprès de cinquante grandes entreprises américaines en 2007, la première cause d’échec à l’audit PCI (79%) était l’incapacité à chiffrer correctement les données bancaires. En outre, en chiffrant, déchiffrant et re-chiffrant les données à différents stades du traitement l’entreprise introduit une complexité supplémentaire et donc un risque accru d’erreur ou d’exploitation.

Le chiffrement écarté, il reste la tokenization. La technique, bien que plus récente et beaucoup moins répandue, permettra de réellement faire sortir des pans entiers du Système d’Information hors du périmètre PCI-DSS. La stratégie est simple : le numéro de carte bancaire est remplacé au plus tôt dans le processus de paiement par un jeton – une valeur arbitraire qui n’a aucun lien avec lui – et c’est désormais ce jeton qui sera stocké, transmis et traité à loisir par les applications qui le nécessitent. Un serveur central est alors le seul pouvoir associer un jeton au numéro de carte bancaire véritable qu’il représente. Bien entendu, dans cette base unique les PAN sont stockés de manière chiffrée et ce serveur peut (doit !) faire l’objet d’une surveillance d’autant plus renforcée qu’il est le seul qui compte désormais.

Les avantages de la tokenization sont nombreux : en premier lieu, bien entendu, puisque les systèmes qui traitent le jeton ne travaillent plus avec un véritable numéro de carte bancaire ils ne sont plus soumis à PCI : « toutes les machines qui n’ont pas besoin du PAN pour la transaction, mais par exemple seulement pour identifier l’utilisateur, sortent ainsi du périmètre PCI. Il n’y a presque plus que le serveur de jetons qui doit être PCI », résume Frédéric Charpentier. Et puisque le jeton, lui, peut encore ressembler en tout point à un PAN valide les applications n’ont donc pas besoin d’être ré-écrites afin d’accepter un format différent, contrairement à ce qui peut être le cas avec le chiffrement (bien que ce soit également possible dans certains cas avec le chiffrement, par exemple grâce à l’approche dite « Format-Preserving Encryption« , voire la variante « Format-Controlling Encryption » proposée par la société Protegrity).

La gestion des clés de chiffrement est également simplifiée : les numéros de carte ne sont chiffrés que dans le serveur de jetons, dont la clé peut changer régulièrement. Le jeton, lui, ne change jamais.

Mieux : rien n’oblige en réalité ce fameux jeton à ressembler à un PAN. Tant que le format ne change pas il peut parfaitement inclure certaines données métiers si l’entreprise le souhaite. Enfin, il n’y a aucun risque de déchiffrement à partir du seul jeton : il n’y a aucun lien mathématique réversible entre le jeton et le PAN qu’il représente. Exit donc le risque d’attaque par force brute ou à l’aide de tables arc-en-ciel. Si les jetons sont perdus dans la nature ils seront totalement inexploitables.

C’est évidemment cette facilité à réduire au maximum la voilure PCI qui séduit les adeptes de la tokenization. « Pour moi le principe est clair : la donnée carte bancaire appartient à la banque, pas au commerçant. Et c’est au propriétaire de la donnée d’assurer sa sécurité ! Nous n’avons pas besoin du PAN pour les processus métiers, il n’y a donc aucune raison pour que nous ayons à la conserver sur les systèmes uniquement pour pouvoir répondre au banque si c’est bien telle carte qui a effectué tel achat chez nous », explique Thierry Servais, RSSI de Kingfisher. La société a ainsi banni la donnée carte bancaire en externalisant complètement le traitement chez un prestataire. « Avec la Tokenisation la donnée carte sort totalement de notre système, elle est chiffrée par le lecteur de carte et nous ne pouvons pas la déchiffrer. Le prestataire nous fournis un token qui pourrait être présenté s’il est nécessaire de faire référence à ce numéro de carte à l’avenir », poursuit Thierry Servais.

Le jeton délivré par le serveur peut servir à réaliser tous les traitements susceptibles d’exiger le numéro de carte bancaire, et notamment le remboursement par virement ou l’ajout d’une charge supplémentaire. Il est donc parfaitement transparent pour les métiers. « La seule limitation concernera les systèmes qui font des opérations de monétique pure ou des calculs de validité du numéro à l’aide d’un algorithme, et les application en fin de processus : elles restent, elles, dans le périmètre PCI-DSS. Mais pour tous les systèmes passe-plats en milieu de processus c’est idéal », explique Frédéric Charpentier.

La mise en oeuvre d’une solution de tokenization sera largement facilitée en confiant l’ensemble du traitement à un prestataire tiers, comme l’a décidé Kingfisher. C’est alors à lui d’émettre les jetons et de veiller à la conformité PCI-DSS de son infrastructure. Le client ne s’occupe plus que de conserver les jetons, qui ne présentent aucun risque particulier. « Mais attention, il ne faut pas croire que la conformité PCI-DSS arrivera automatiquement avec une telle approche, mais il ne restera plus grand chose à traiter », modère tout de même Thierry Servais. Il reste à gérer, en effet, notamment les terminaux de paiement (PoS, pour Point of Sale).

Il est également possible de mettre en oeuvre la solution en interne en passant par un développement propriétaire. « Dans toutes les mises à oeuvre que j’ai traitées nous avons fait du sur-mesure. Nous avons simplement ajouté un champs supplémentaire dans l’une des bases qui reçoit les numéros de cartes afin de stocker le jeton. Le plus compliqué est surtout de savoir où effectuer le remplacement du PAN au plus tôt dans le processus sans que cela n’impacte le métier », détaille Frédéric Charpentier.

Il existe, enfin, des solutions commerciales sous la forme de boîtiers qui se chargeront de gérer le remplacement et dont les éditeurs mettent en avant la simplicité de déploiement. « L’idée de remplacer le numéro de carte dès son arrivée en ajoutant simplement un boîtier en passerelle est très vendeuse mais il faut faire attention car ce n’est pas toujours possible. Il faut s’assurer que derrière tout vas continuer à fonctionner, par exemple dans le cadre d’un centre d’appel qui demande un numéro de carte bancaire pour identifier un client », met en garde Frédéric Charpentier.

Quelle que soit la solution choisie, cette technologie n’est cependant pas anodine à mettre en oeuvre et il faudra prendre quelques précautions. « Ce n’est pas comme déployer un boîtier IPS ! Les clients sont frileux lorsqu’il s’agit de toucher à leurs systèmes de paiement », précise à juste titre Frédéric Charpentier, notant que les demandes en la matière ne se bousculent pas encore. L’entreprise devra notamment s’assurer qu’elle est en mesure de distinguer les données « tokenizées » des véritables données en clair tout au long de ses traitements, afin de ne pas propager les premières là où les secondes sont attendues, ce qui pourrait rapidement gripper les plus fiables des processus métiers ! C’est d’ailleurs peut-être parce que toucher aux systèmes de paiement ne se décide pas sur un coup de tête que la tokenization reste encore plutôt confidentielle : « On ne trouve effectivement pas grand chose en France, mais nous avons déjà eu quatre propositions après notre PoC au Royaume Uni », confirme Thierry Servais.

Bien qu’encore peu répandue aujourd’hui parmi les marchands soumis à PCI-DSS, la tokenization devrait toutefois devenir plus populaire dans les mois à venir : Visa vient en effet de publier une série de recommandations pour mettre en oeuvre cette technologie, et encourage les marchands à le faire.

Plus simple, plus légère, plus souple et moins coûteuse que le chiffrement tout en étant globalement plus sûre, la tokenization mérite réellement votre attention si vous êtes concerné par PCI-DSS.