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

Une question revient fréquemment : 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 l'utiliser pour déchiffrer la charge utile de données via le Triple-DES (ou AES, selon le cas).

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

La partie délicate réside dans la dérivation de 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 essentiel 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 à chaque transaction (d'où l'acronyme DUKPT : Derived Unique Key Per Transaction, soit « clé unique dérivée par transaction »). Aucune clé n'est jamais utilisée deux fois. Par conséquent, les attaques par rejeu sont pratiquement impossibles.

Pour comprendre le fonctionnement du DUKPT, il convient de maîtriser le concept du 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, ses 21 bits de poids faible constituant un compteur.

Structure du numéro de série de clé.

À retenir : chaque transaction par carte chiffrée est accompagnée d'un KSN. Le KSN fait toujours 10 octets de long. Il 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, il reçoit en injection une clé de 16 octets et un KSN initial de 10 octets. La clé injectée est dérivée d'une clé ultra-secrète (qui n'est jamais injectée) 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 que diverses 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é à partir du hachage (même si le KSN est connu), car il s'agit d'un hachage unidirectionnel cryptographiquement sécurisé.

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

Une fois chiffrées, les données de transaction ne sont déchiffrées qu'à leur destination finale autorisée, qui peut être l'émetteur de la carte. La partie réceptrice (par exemple, l'émetteur) utilisera sa propre copie de votre BDK (ainsi que le KSN de la transaction) pour recalculer la clé de session de la transaction 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 le même secret (le BDK). Il est supposé que vous aurez préalablement communiqué le « secret » nécessaire à la partie réceptrice afin 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 l'on connaît le BDK d'origine et le KSN. (À cette étape, tout KSN provenant de l'appareil concerné convient, puisque le compteur sera remis à zéro.)

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-la à 24 octets en utilisant la méthode dite EDE3. Cela signifie simplement : copiez les 8 premiers octets de la clé et ajoutez-les à la fin, ce qui crée 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 comme suit :

2. Masquez votre KSN initial de 10 octets en appliquant un ET logique (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 un vecteur d'initialisation composé uniquement de zéros. (Notez que le chaînage de blocs de chiffrement n'est pas pertinent ici, car les données ne représentent qu'un seul bloc : 8 octets.) Conservez le chiffré de 8 octets obtenu à cette étape, car il constituera la moitié gauche de l'IPEK de 16 octets.

5. Pour obtenir la moitié droite de l'IPEK, appliquez 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 l'arithmétique des 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 de manière incrémentielle, segment par segment.)

6. Étendez par 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 à présent de l'IPEK finale de 16 octets.

Si vous implémentez cela dans votre propre code, essayez de générer une IPEK à partir d'une valeur de clé de test 0123456789ABCDEFFEDCBA9876543210 et d'un KSN égal à 62994900000000000001. L'IPEK résultante devrait être B5610650EBC24CA3CACDD08DDAFE8CE3.

Gestion des clés et algorithmes de chiffrement

Vous remarquerez, au passage, que le Triple-DES (TDES) est largement utilisé dans le cadre de DUKPT. L'AES n'intervient à aucun moment (même si votre lecteur de carte est configuré pour utiliser l'AES comme algorithme de chiffrement). La norme X9.24 préconise le TDES, et parfois le DES simple. Il est essentiel de bien distinguer le processus de dérivation de clé DUKPT 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 effectuer un encodage TDES ou AES. Aucune routine de chiffrement ne sait ni ne se soucie de l'origine de votre clé, ni des algorithmes ayant servi à la construire ; la seule chose qui compte, c'est que la clé elle-même fonctionne. Ainsi, même si les données à déchiffrer ont été chiffrées avec l'AES, la clé utilisée pour les déchiffrer sera dérivée via DUKPT, qui utilise le TDES en interne.

Où se trouve le code ?

Dans la deuxième partie de cet article, nous expliquerons en détail comment utiliser un IPEK combiné à un KSN pour dériver une clé de session DUKPT. Nous présenterons le code source complet afin que vous puissiez reproduire l'ensemble du processus par vous-même. Si vous ne souhaitez pas attendre la suite pour consulter ce code source, n'hésitez pas à jeter un œil à notre populaire Outil de chiffrement/déchiffrement, qui contient une implémentation JavaScript entièrement fonctionnelle des algorithmes DUKPT que j'aborderai dans la deuxième partie (avec des implémentations open source de TDES et d'AES). Cet outil vous permet de dériver des clés DUKPT (dans les 3 variantes : PIN, Data et MAC), de chiffrer ou déchiffrer des données (avec TDES ou AES), de générer différents types de hachages, et bien plus encore. De plus, comme il s'agit simplement d'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 Data à partir d'un KSN et d'un IPEK ? Passez à la Partie II de cet article.