Article technique
Anatomie d'une commande MAC
Nombre de clients d'ID TECH s'intéressent au chiffrement point à point (P2PE)et, dans leur démarche de conformité aux exigences strictes de PCI en matière de P2PE, ils envisagent souvent des terminaux de paiement SRED (Secure Reading and Exchange of Data). Ces terminaux non seulement chiffrent les données au point de capture (comme tous les appareils d'ID TECH sont capables de le faire), mais intègrent également une détection des tentatives d'intrusion, une mise à zéro automatique des données en cas de violation, ainsi que d'autres fonctionnalités de sécurité spécialisées.
Parmi ces « autres fonctionnalités de sécurité spécialisées », l'authentification MAC des commandes occupe une place centrale.
En cryptographie, un code d'authentification de message (MAC) est un code court permettant au destinataire d'un message d'en authentifier l'origine — autrement dit, de confirmer que le message provient d'un expéditeur de confiance. La valeur MAC garantit à la fois l'intégrité des données du message et son authenticité, en associant le message à un secret partagé entre l'expéditeur et le destinataire. Le message est transmis en clair, mais est également accompagné du couple message-MAC (qui contient le secret sous forme chiffrée). Toute personne disposant du secret peut ainsi vérifier que le message (et son contenu MAC associé) provient bien d'une autre partie ayant accès au même secret.
Dans les lecteurs de cartes SRED d'ID TECH, certaines commandes sensibles sont protégées par MAC, ce qui signifie que le terminal n'exécutera la commande que si celle-ci est accompagnée d'un hachage MAC pouvant être vérifié à l'aide d'une clé déjà stockée dans l'appareil. L'expéditeur de la commande doit construire le hachage MAC en utilisant la même clé que celle employée par le terminal pour le valider.
Un exemple permettra peut-être de mieux illustrer ce mécanisme.
Supposons que vous souhaitiez régler la date et l'heure sur un lecteur de carte ID TECH Augusta S, qui est un dispositif SRED. La commande « Régler la date et l'heure » est considérée comme sensible, car une partie non autorisée ne doit pas être en mesure d'antidater (ou de modifier de toute autre façon) les transactions. (Les autres commandes « sensibles » incluent, par exemple, les commandes permettant d'ajouter ou de supprimer des cartes d'une liste blanche, ou de modifier la liste de révocation de certificats de l'appareil.)
Dans le cas courant, vous régleriez la date et l'heure d'un Augusta non-SRED à l'aide de la commande firmware 78 53 01 50, suivie de la longueur de la charge utile (0x08), puis de la longueur de la date/heure (0x06), puis des six octets de date et d'heure au format AA MM JJ HH MM SS, suivis de la « longueur du MAC », qui (pour un appareil non-SRED) est égale à zéro. Dans le cas de Augusta S, la formule est identique, à ceci près que la longueur de la charge utile est 0x26 et que la « longueur du MAC » est 0x1E, car 30 octets supplémentaires de « charge utile MAC » sont ajoutés à la fin de l'ensemble.
Bien entendu, avec Augusta, la commande entière doit être mise en forme selon le protocole NGA d'ID TECH, ce qui consiste à placer STX (0x02) et deux octets de longueur en little-endian au début de la structure de commande, et LRC, checksum et ETX (0x03) à la fin de celle-ci. La version MAC finale de la commande complète se présente comme suit (les octets de commande sont mis en évidence en jaune) :
02 2B 00 78 53 01 50 26 06 17 11 10 09 15 00 1E 10 00 4E C7 DF CF 04 D3 3C C6 EC 6F 50 92 00 86 A1 DD 0A 00 62 99 49 00 00 00 00 00 00 02 EB F9 03
Analysons-la section par section :
02 est le STX.
2B 00 est la longueur (en little-endian) de l'ensemble de la structure, hors le trailer LRC/checksum/ETX.
78 53 01 50 est la commande firmware Régler la date et l'heure.
26 (hexadécimal) indique que 38 octets de charge utile suivent.
06 signifie que la date/heure est composée de 6 octets, à savoir :
17 11 10 09 15 00 — 10 novembre 2017, 09h15:00.
1E signifie que 30 octets de charge utile MAC suivent.
10 00 est une valeur de longueur en little-endian de 16 (car tous les hachages MAC de ID TECH font 16 octets).
4E C7 DF CF 04 D3 3C C6 EC 6F 50 92 00 86 A1 DD est le hachage MAC de 16 octets, ou « HMAC ».
0A 00 est une longueur en little-endian de 10, correspondant au KSN qui suit.
62 99 49 00 00 00 00 00 00 02 est le KSN MAC.
EB est la valeur de contrôle de redondance longitudinale (LRC).
F9 est la somme de contrôle sur 8 bits de tout ce qui va de 78 jusqu'au dernier octet du KSN (02).
03 est ETX (fin de transmission).
La construction de cette commande ne présente pas de difficulté particulière. Les éléments qui méritent une explication sont le KSN et le HMAC (le hachage lui-même).
MAC KSN
Le MAC KSN (numéro de série de clé) est une valeur que vous devez interroger directement auprès du terminal au moment où vous en avez besoin. Si vous connaissez la norme ANSI X9.24-1 (la norme de clé unique dérivée par transaction), vous savez que le KSN est une valeur de 10 octets dont les 21 bits de poids faible constituent un compteur qui s'incrémente après chaque utilisation. Ce que vous n'avez peut-être pas réalisé, c'est que si un terminal contient plusieurs clés DUKPT (pour les données, le MAC et le PIN, par exemple), chacune disposera de son propre KSN dédié, qui s'incrémente de manière indépendante. Le KSN est toutefois une valeur publique, et vous pouvez interroger le MAC KSN dans Augusta de ID TECH à tout moment, à l'aide de la commande (complète et formatée) suivante : 02090078463e040005010000000603.
Le KSN est important, car il entre dans le calcul de la clé MAC, laquelle est unique à chaque utilisation (et donc non exposée aux attaques par rejeu). Pour en savoir plus sur les KSN et la dérivation des clés DUKPT, consultez mon article précédent en deux parties sur ce sujet.
DÉRIVATION HMAC
Passons maintenant à la partie technique.
Le HMAC (voir RFC 2104) est une méthode reconnue par l'industrie pour créer des hachages MAC à l'aide des éléments suivants :
- — une clé à usage unique de 128 bits
- — une charge utile de message arbitraire
- — le hachage SHA-256
La clé en question est dérivée dynamiquement à partir du MAC KSN et de l'IPEK du dispositif (elle-même dérivée d'une BDK), conformément aux règles DUKPT standard. Ces règles définissent une méthode spécifique pour dériver une clé MAC (par opposition à une clé de données ou une clé PIN). Tout cela est décrit dans mon précédent article en deux parties
Le redoutable hachage HMAC est calculé selon la formule suivante, à l'aspect particulièrement intimidant :
H( (K' ⊕ opad) ‖ H( (K' ⊕ ipad) ‖ m) )
Ne vous laissez pas décourager par cette formule. Elle est en réalité tout à fait compréhensible. La valeur K est la clé de 128 bits. K' (k-prime) désigne cette même clé, complétée par des zéros jusqu'à une longueur totale de 64 octets.
La ipad (bourrage interne) correspond simplement à la constante 36363636… répétée jusqu'à une longueur de 64 octets.
K' ⊕ ipad signifie combiner la clé complétée par des zéros avec la valeur ipad, à l'aide d'un OU exclusif (également appelé XOR), une opération arithmétique bit à bit très prisée des passionnés d'informatique.
K' ⊕ ipad) ‖ m signifie ajouter le message (m) à la valeur obtenue précédemment. Il suffit d'ajouter les octets à la fin. (La longueur dépassera désormais 64 octets. Ne vous en inquiétez pas.)
H( (K' ⊕ ipad) ‖ m) signifie appliquer votre fonction de hachage (dans ce cas, SHA-256) à l'intégralité de la valeur entre parenthèses.
Une fois cette étape terminée, vous ajouterez le résultat à K' ⊕ opad, où opad (le bourrage externe) est une constante composée de 5C5C5C5C… répétée jusqu'à une longueur de 64 octets. Vous procéderez ensuite à un nouveau hachage de l'ensemble.
Si vous vous posez la question, les valeurs ipad et opad ont été choisies arbitrairement par les auteurs originaux de cet algorithme, mais de manière à maximiser la distance de Hamming (ou les différences bit à bit) entre les deux moitiés avant et arrière du hachage. Le hachage est effectué en deux moitiés imbriquées afin de prévenir diverses formes d'usurpation.
Pour vous aider à générer des valeurs HMAC, ID TECH a mis en ligne un formulaire HTML icidans lequel vous pouvez saisir des valeurs KSN et BDK (clé racine), dériver votre clé MAC et utiliser HMAC pour créer un hachage MAC de 32 octets (via SHA-256). N'hésitez pas à essayer l'option « Generate HMAC (with verbose output) » disponible dans le menu déroulant en haut du formulaire. Vous obtiendrez une trace détaillée particulièrement utile, qui explique clairement à quoi ressemble chaque élément du puzzle HMAC.
Si vous utilisez notre outil en ligne pour générer une clé MAC à partir d'un KSN de 62 99 49 00 00 00 00 00 00 02 et d'une clé racine (BDK) de 0123456789ABCDEFFEDCBA9876543210 — qui est la clé de test standard ANSI —, votre clé MAC devrait avoir la valeur 3E4A480ACE8B239B9539E6053EAB03D9. Si vous appliquez l'algorithme HMAC à un payload de 78 53 01 50 26 06 17 11 10 09 15 00 1E 10 00 en utilisant cette clé, vous devriez obtenir un hachage HMAC de 32 octets, dont les 16 premiers octets sont 4EC7DFCF04D33CC6EC6F50920086A1DD. (ID TECH n'utilise que les 16 premiers octets.) Il s'agit de l'« empreinte » unique qui sera ajoutée à la commande Set Date and Time. Le lecteur de carte examinera les octets du payload en clair et utilisera son propre KSN ainsi que son code interne de dérivation de clé pour obtenir la même valeur HMAC que celle incluse dans votre commande, vérifiant ainsi que la commande provient nécessairement d'une source qui connaît la BDK secrète (0123456789ABCDEFFEDCBA9876543210), et donc d'une source de confiance.
Des questions sur DUKPT ? HMAC ? SRED ? P2PE ? Contactez nos experts. Nous sommes là pour vous aider :