Comment déchiffrer les données de carte de crédit, Partie I

Une question revient souvent : les données de piste que j'obtiens de mon lecteur de carte de crédit ID TECH sont chiffrées. Comment les déchiffrer ?

La réponse est la suivante : vous devez obtenir la clé de session appropriée pour la transaction, puis utiliser cette clé pour déchiffrer la charge utile de données via le Triple-DES (ou l' AES, selon le cas).

Le processus de déchiffrement en lui-même est agréablement simple. Vous utiliserez probablement l'une des nombreuses implémentations open source existantes du TDES ou de l'AES (il n'est pas nécessaire d'implémenter vous-même les routines cryptographiques de base), en mode CBC (Cipher Block Chaining), avec un vecteur d'initialisation par défaut composé uniquement d'octets nuls. À condition de disposer de la clé de déchiffrement de 16 octets correcte, le processus de déchiffrement est simple.

La partie délicate consiste à dériver la clé. Pour cela, vous devrez maîtriser la norme ANSI X9.24-1, également connue sous le nom de DUKPT.

Bienvenue dans l'univers du DUKPT

Il est important de comprendre que, dans les lecteurs de cartes de crédit, chaque transaction génère des données qui seront chiffrées à l'aide d'une clé différente. Cette clé est propre à une transaction donnée (d'où l'acronyme DUKPT : Derived Unique Key Per Transaction). Aucune clé n'est jamais utilisée deux fois. Par conséquent, les attaques par rejeu sont pratiquement impossibles.

Pour comprendre le fonctionnement de DUKPT, il faut avoir quelques notions sur le concept de numéro de série de clé, ou KSN (Key Serial Number). L'essentiel à retenir est que le KSN est une valeur de 10 octets qui change à chaque transaction, les 21 bits de poids faible constituant un compteur.

Structure du numéro de série de clé (KSN).

À retenir : chaque transaction par carte chiffrée est accompagnée d'un KSN. Ce KSN a toujours une longueur de 10 octets et est toujours transmis en clair, car le KSN seul ne divulgue aucune information sensible (tout en étant indispensable à la dérivation d'une clé de session).

Lorsqu'un lecteur de carte est configuré pour le chiffrement en usine, une clé de 16 octets et un KSN initial de 10 octets lui sont injectés. La clé injectée est dérivée d'une clé ultra-secrète — jamais injectée directement — appelée BDK, ou Base Derivation Key (clé de dérivation de base). (Étant donné que de nombreuses clés peuvent être dérivées d'un seul BDK, il est possible, et même courant, d'injecter des centaines, voire des milliers de lecteurs de cartes avec des clés uniques issues d'un même BDK.) Le processus de dérivation lui-même nécessite l'utilisation d'un KSN. Comme le KSN contient des informations sur le numéro de série de l'appareil (ainsi qu'un grand nombre d'autres informations d'espace de nommage), un hachage (ou clé) produit à partir d'une combinaison BDK+KSN donnée sera essentiellement unique à l'appareil. De plus, le BDK d'origine ne peut jamais être recalculé à rebours à partir du hachage (même en connaissant le KSN), car il s'agit d'un hachage unidirectionnel cryptographiquement sécurisé.

À chaque transaction, le lecteur de carte (s'il prend en charge DUKPT, ce qui est le cas de pratiquement tous les lecteurs de cartes aujourd'hui) génère une clé unique à partir de la valeur KSN courante et d'un élément appelé IPEK (ou Initial PIN Encryption Key). La clé de session à usage unique ainsi obtenue est ensuite utilisée pour chiffrer les parties sensibles des données de la transaction.

Une fois chiffrées, les données de transaction ne sont jamais déchiffrées avant d'avoir atteint leur destination autorisée, qui peut être l'émetteur de la carte. La partie destinataire (par exemple, l'émetteur) utilisera sa propre copie de votre BDK (ainsi que le KSN de la transaction) pour recalculer la clé de session correspondante et récupérer les données de transaction originales (déchiffrées). Il s'agit d'un processus dit symétrique, car la partie chiffrante et la partie déchiffrante doivent toutes deux connaître au préalable le même secret (le BDK). Il est supposé que vous aurez préalablement fourni à la partie destinataire le « secret » nécessaire pour que vous puissiez toutes deux déchiffrer les messages.

L'IPEK

Le point de départ pour obtenir une clé de session DUKPT est toujours de dériver l'IPEK, ou clé initiale, ce qui n'est possible que si vous connaissez le BDK d'origine et le KSN. (Ici, n'importe quel KSN provenant de l'appareil concerné convient, puisque vous allez mettre le compteur à zéro pour cette étape.)

Pour dériver une clé initiale de chiffrement du PIN (IPEK), vous devez effectuer les opérations suivantes :

1. Si votre BDK fait 16 octets, étendez-le à 24 octets en utilisant la méthode dite EDE3. Cela consiste simplement à copier les 8 premiers octets de la clé à la fin de celle-ci, créant ainsi une clé de 24 octets dont les 8 premiers et les 8 derniers octets sont identiques.

Si votre clé d'origine (en hexadécimal) se présente comme suit :

Vous souhaitez qu'elle se présente finalement comme suit :

2. Masquez votre KSN initial de 10 octets en effectuant une opération AND avec la valeur hexadécimale 0xFFFFFFFFFFFFFFE00000. Nous appellerons le résultat le « KSN masqué ».

3. Créez une valeur de 8 octets à partir du KSN masqué en ne conservant que les 8 premiers octets (c'est-à-dire les plus à gauche) du KSN masqué de 10 octets. En d'autres termes, supprimez les deux octets les plus à droite.

4. En utilisant votre BDK étendue de 24 octets comme clé, chiffrez par TDES les 8 octets du KSN masqué obtenus à l'étape 3. Vous utiliserez pour cela un vecteur initial composé uniquement de zéros. (Notez que le chaînage de blocs de chiffrement n'a pas de sens ici, car les données ne constituent qu'un seul bloc de 8 octets.) Conservez le chiffré de 8 octets obtenu à cette étape, car il deviendra la moitié gauche de l'IPEK de 16 octets.

5. Pour obtenir la moitié droite de l'IPEK, effectuez d'abord un XOR entre votre BDK d'origine de 16 octets et la valeur hexadécimale 0xC0C0C0C000000000C0C0C0C000000000. (Si vous utilisez un langage de programmation prenant en charge les grands entiers, cette opération peut être réalisée en une seule ligne de code. Dans le cas contraire, vous devrez effectuer le XOR des deux valeurs de manière incrémentielle, morceau par morceau.)

6. Appliquez l'extension EDE3 à la valeur de 16 octets obtenue à l'étape 5, afin d'obtenir une valeur de clé de 24 octets.

7. En utilisant la valeur de clé de 24 octets de l'étape 6, chiffrez par TDES les 8 octets du KSN masqué obtenus à l'étape 3. Il s'agit désormais de la moitié droite de l'IPEK.

8. Concaténez les moitiés gauche et droite de l'IPEK. Vous disposez maintenant de l'IPEK final de 16 octets.

Si vous implémentez ceci dans du code par vous-même, essayez de générer un IPEK à partir d'une valeur de clé de test 0123456789ABCDEFFEDCBA9876543210 et d'un KSN de 62994900000000000001. L'IPEK résultant devrait être B5610650EBC24CA3CACDD08DDAFE8CE3.

Gestion des clés et algorithmes de chiffrement

Vous remarquerez, au passage, que Triple-DES (TDES) est largement utilisé dans DUKPT. L'AES n'est jamais utilisé (même si votre lecteur de carte est configuré pour utiliser l'AES à des fins de chiffrement). La norme X9.24 prescrit l'utilisation de TDES, et parfois du DES simple. Gardez bien à l'esprit que le processus de dérivation de clé DUKPT est entièrement distinct du processus de chiffrement/déchiffrement des données de transaction. Dans un cas, vous dérivez une clé ; dans l'autre, vous utilisez cette clé pour réaliser un encodage TDES ou AES. Aucune routine de chiffrement ne sait ni ne se soucie de l'origine de votre clé, ni des algorithmes utilisés pour la construire ; la seule chose qui importe est que la clé elle-même fonctionne. Ainsi, même si les données que vous devez déverrouiller ont été chiffrées avec l'AES, la clé utilisée pour les déverrouiller sera dérivée via DUKPT, qui utilise TDES en interne.

Où se trouve le code ?

Dans la partie II de cet article, nous allons expliquer en détail comment utiliser un IPEK ainsi qu'un KSN pour dériver une clé de session DUKPT. Vous y trouverez le code source complet pour réaliser l'ensemble du processus par vous-même. Si vous ne souhaitez pas attendre la prochaine partie pour consulter ce code source, vous pouvez dès à présent jeter un œil à notre populaire Outil de chiffrement/déchiffrement, qui contient une implémentation JavaScript entièrement fonctionnelle des algorithmes DUKPT dont je parlerai dans la partie II (avec des implémentations open source de TDES et AES). Vous pouvez utiliser cet outil de chiffrement/déchiffrement pour dériver des clés DUKPT (dans les 3 variantes : PIN, Data et MAC), chiffrer ou déchiffrer des données (avec TDES ou AES), générer différents types de hachages, et bien plus encore. Autre avantage de taille : cet outil étant simplement une page web, il fonctionnera dans n'importe quel navigateur (sur toute plateforme) prenant en charge JavaScript.

Vous souhaitez dériver une clé de session DUKPT en variante de données à partir d'un KSN et d'un IPEK ? Passer à la partie II de cet article.