La diversification des clefs symétriques

La diversification (ou dérivation) est un procédé cryptographique permettant, à partir d’une clef symétrique, de générer une seconde clef.

Le procédé ne doit pas permettre, à partir de la seconde clef de retrouver la clef d’origine.

Utilisation en NFC

En NFC, la plupart du temps, les algorithmes utilisés sont symétriques (sauf pour les transactions bancaires). Les PICC ayant la capacité de gérer des algorithmes asymétriques sont plus chères et l’utilisation même de ce type d’algorithme demande plus de temps, ce qui n’est pas compatible avec la majorité des usages NFC. L’illustration la plus courante étant le contrôle d’accès qui nécessite un grand volume de contrôle en un temps très réduit (l’arrivée au boulot le matin des 2500 personnes).

Mais l’utilisation d’algorithmes symétriques pose un problème. En effet, si l’une des PICC est dérobée et que sa clef est cassée, ce sont toutes les PICC qui sont corrompues puisque la clef est la même partout.

Pour pallier à ce problème, on met en place une diversification des clefs.

La diversification est un processus décrit dans les documents “NIST-800-108” et “NIST-SP-800-38B“. En NFC, et en particulier pour les cartes sans contacts il existe deux standards décrit dans les “Application Note” AN0148 et AN10922.

Un projet est également disponible sur GitHub pour aider à la mise en oeuvre.

Comment ça marche ?

C’est très simple 🙂

La clef d’origine est passée dans un algorithme de diversification qui utilise des données du support (la PICC) pour générer une seconde clef. Les données utilisées sont en général, l’ID de la PICC, l’identifiant de l’application qui stocke la clef etc.

Principe de diversification

En sortie, la clef diversifiée ne permet pas, même en connaissant l’algorithme utilisé, de reconstruire la clef d’origine.

Du coup, si la clef d’une carte est corrompue, elle ne met plus en péril les autres cartes car elles ne possèdent pas les mêmes clefs.

Les applications qui doivent accéder à la carte connaissent la clef d’origine et font une diversification identique pour connaître la clef de la carte à utiliser.

Standard AN0148

Le standard AN0148 décrit la diversification à l’aide des algorithmes DES, 3DES et AES.

Les données utilisées pour diversifier les clefs sont l’ID de la PICC et l’index de la clef à diversifier.

DES

Ou:

  • Kd = Clef diversifiée
  • Km = Clef d’origine
  • KeyNo = Index de la clef
  • ID = Identifiant de la PICC
  • Edes = Méthode de chiffrement DES
  • xor = Méthode “Ou Exclusif”
  • || = Méthode de concaténation

Vous pouvez expérimenter cette diversification avec le projet GitHub et les arguments :

3DES

En 3DES, le procédé est similaire, on découpe la clef 3DES de 16 octets en 2 clefs de 8 octets qui sont chacun dérivées. La première partie avec les données de dérivation, la seconde partie avec les 8 premiers octets de la première diversification.

Ou:

  • Kd = Clef diversifiée
  • Km = Clef d’origine
  • Km0-7 = 8 premiers octets de la clef d’origine
  • Km8-15 = 8 derniers octets de la clef d’origine
  • Kd0-7 = 8 premiers octets de la clef diversifiée
  • Kd8-15 = 8 derniers octets de la clef diversifiée
  • KeyNo = Index de la clef
  • ID = Identifiant de la PICC
  • E3des = Méthode de chiffrement 3DES
  • xor = Méthode “Ou Exclusif”
  • || = Méthode de concaténation

Vous pouvez expérimenter cette diversification avec le projet GitHub et les arguments :

AES

En AES, le fonctionnement est là encore similaire.

Ou:

  • Kd = Clef diversifiée
  • Km = Clef d’origine
  • KeyNo = Index de la clef
  • ID = Identifiant de la PICC
  • Eaes = Méthode de chiffrement AES
  • xor = Méthode “Ou Exclusif”
  • || = Méthode de concaténation

Vous pouvez expérimenter cette diversification avec le projet GitHub et les arguments :

Standard AN10922

Le standard AN10922 est plus récent et détaillé dans le document “NIST-SP-800-38B”.

Il est réalisé en AES (128 ou 192) ou en TDEA (avec des clefs de 16 et 24 octets). A la place de la méthode “xor” utilisée en AN0148, c’est la méthode CMAC (réputée plus fiable) qui est utilisée.

Les données utilisées pour diversifier les clefs sont l’ID de la PICC, l’ID de l’application (3 octets), une graine choisie lors de la configuration de l’algorithme.

La méthode “cmac” est détaillée dans le document “NIST-SP-800-38B” et implémentée dans le projet mis à disposition sur GitHub.

AES (128 bits)

Diversification AN10922 AES 128 bits

Ou:

  • Kd = Clef diversifiée
  • K = Clef d’origine
  • ID = Identifiant de la PICC
  • CMACaes128 = Méthode “CMAC” avec l’algorithme AES 128 bits
  • || = Méthode de concaténation
  • SEED = Graine de diversification
  • length = Méthode d’obtention de la taille d’une variable
  • pad32 = Méthode permettant de compléter une variable pour que sa taille soit égale à 32 octets.

Vous pouvez expérimenter cette diversification avec le projet GitHub et les arguments :

AES (192 bits)

Le procédé est identique à la version “AES 128 mais il est répété deux fois avec une constante différente afin de générer deux clefs diversifiées.

Diversification AN10922 AES 192 bits

Ou:

  • Kd = Clef diversifiée
  • K = Clef d’origine
  • ID = Identifiant de la PICC
  • CMACaes192 = Méthode “CMAC” avec l’algorithme AES 192 bits
  • || = Méthode de concaténation
  • SEED = Graine de diversification
  • length = Méthode d’obtention de la taille d’une variable
  • pad32 = Méthode permettant de compléter une variable pour que sa taille soit égale à 32 octets.
  • xor = Méthode “Ou Exclusif”

Vous pouvez expérimenter cette diversification avec le projet GitHub et les arguments :

Pour finir

L’utilisation de la diversification des clefs symétriques devrait être systématisée. Les processus cryptographiques sont standardisés, documentés et simple à implémenter.

Les standards les plus récents datent de 2010, les processeurs actuels sont largement capables de mener une diversification sans perte significative de temps.

 

A ce jour il existe cependant deux limitations :

  • Les lecteurs qui n’implémenteraient pas cette fonctionnalité.
  • L’utilisation d’ID aléatoire. C’est le cas sur tous les Smartphones ou presque.

 

Il faudra donc veiller à ce qu’un identifiant unique et fixe soit fourni par les récepteurs en “Random ID” et maîtriser la population des lecteurs afin de s’assurer qu’ils sont tous en capacité de réaliser la diversification.

A noter que l’on n’est pas obligé de diversifier l’intégralité des clefs utilisées, on peut le faire uniquement sur certaines clefs critiques.

Enfin, privilégier l’utilisation de l’AES au lieu du DES/3DES, beaucoup plus rapide et sécurisé.