Le format APDU pour communiquer en NFC

APDU est un format qui permet de structurer les commandes échangées entre les périphériques NFC. Il est utilisé pour envoyer des commandes et en recevoir les réponses.

Avant de vous lancer, je vous conseille de lire (voir de relire) les articles précédents : “Les bases de la technologie NFC“, “Le NFC et la norme ISO/IEC 14443” et “La boucle Anti-Collision“.

Tous les périphériques NFC ne communiquent pas forcement avec APDU. Mais pour palier à ce problème, les PCD embarquent presque systématiquement un interpréteur APDU pour communiquer avec les cartes qui auraient un format de message propriétaire.

Donc, au travers du PCD on utilise APDU mais toutes les PICC ne communiquent pas forcement avec ce format de message.

Commande

(de l’émetteur vers le récepteur)

  • Elle est composée d’au minimum 4 octets appelés “HEADER” et codifiés “CLA”, “INS”, “P1” et “P2”.
  • On peux y ajouter un “BODY” de taille variable codifié “Lc“, “DATA”, “Le“.

Définitions

  • CLA : Classe d’instruction, permet de déterminer le type de commande (propriétaire, standard, à destination du PCD…)
  • INS : Le code de l’instruction (lire, écrire, s’authentifier…)
  • P1 : Le premier paramètre de la commande
  • P2 : Le second paramètre de la commande
  • Lc : Le nombre d’octet envoyé dans “DATA” (optionnel)
  • DATA : Les données envoyées (optionnel)
  • Le : Le nombre d’octet attendu en réponse (optionnel)

Il existe donc 4 structures de commandes APDU :

  • CLA INS P1 P2 : Format court
  • CLA INS P1 P2 Lc DATA : Format orienté écriture
  • CLA INS P1 P2 Le : Format orienté lecture
  • CLA INS P1 P2 Lc DATA Le : Format complet

Le format dépendra de la commande à exécuter.

Les commandes à destination du PCD

Le PCD étant chargé de réaliser la boucle anti-collision c’est lui qui a en sa possession l’ID et le SAK du récepteur. Il faut donc être capable de lui demander ces informations.

En jouant sur la classe de la commande “CLA”, il est possible d’envoyer des commandes à destination du PCD et pas du récepteur. De la même manière, pour certaines cartes sans contacts, il faut que l’émetteur transforme le message APDU dans le format de la carte, une classe de commande spécifique sera également utilisée. On peux aussi être amener à modifier une configuration du PCD, ces commandes sont en générales propres à chaque PCD, il faudra donc consulter la documentation de votre lecteur NFC.

Pour toutes ces raisons, il existe une classe de commande réservée à la communication avec le PCD. C’est la classe “FFh“.

Les commandes à destination des PICC

On peux considérer qu’il existe 3 types de “PICC”.

Celles qui sont compatible avec la norme ISO/IEC 7816-4.Comme nous le verrons dans un prochain article cette norme définie un jeu de commande commun pour tous les périphériques.

Celles qui utilisent l’APDU comme format de message mais qui ont un jeu de commandes spécifique (la valeur de CLA dépend de la carte). Par exemple, des cartes comme MIFARE DESFire EV1 sont compatible partiellement avec ISO/IEC 7816-4 et propose un jeu de commandes spécifique (CLA = 90h) .

Et enfin, les cartes qui n’utilisent pas APDU, c’est le cas des MIFARE Classic, Ultralight et des NTAG par exemple. La communication avec ces cartes passe par l’interpréteur APDU du PCD (CLA = FFh).

Exemples de valeurs pour CLA :

CLA

Usage

00h

Communication ISO7816-4 standard (envoyée directement à la PICC).

FFh

Communication directe vers le PCD, soit pour le configurer, soit pour utiliser son interpréteur interne APDU (dans le cas des cartes MIFARE Classic ou Ultralight par exemple).

90h

Communication avec des PICC de type MIFARE DESFire.

APDU - CLA

Réponse

(le retour d’une commande, du récepteur vers l’émetteur)

  • Est composé d’au moins 2 octets appelés “TRAILER” et codifiés “SW1” et “SW2”.
  • On peux également y trouver un “BODY”, de taille variable codifié “DATA”.

Définitions

  • SW1 : La codification du type de retour (Normal, Erreur, Warning…)
  • SW2 : Le détail du retour.
  • DATA : La donnée retournée (optionnel et au maximum = à Le si Le > 0).

Il existe donc 2 structures de réponses APDU :

  • SW1 SW2
  • DATA SW1 SW2

Le format dépendra de la commande exécutée.

Les réponses

Comme pour les commandes, les valeurs SW1 et SW2 des réponses dépendent du respect ou pas de la norme ISO/IEC 7816-4.

Si la classe de commande est “00h“, le retour sera conforme à la norme ISO/IEC 7816-4.

Si la classe de commande vaut “FFh” c’est le PCD qui interprète le résultat de la PICC et fait un retour. Les codes sont, en général, identiques à la norme ISO/IEC 7816-4 mais il peut y avoir des spécificités. Il faut dans ce cas se reporter à la documentation du PCD.

Pour les autres classes, c’est la documentation de la PICC qui permet de connaître les codes de retours.

Exemples de valeurs pour SW1 et SW2 :

SW1

SW 2

Usage

90h

00h

Opération réussie ISO7816 et MIFARE Classic

91h

00h

Opération réussie pour MIFARE DESFire

67h

00h

Mauvaise taille de données (incohérence entre “DATA” et “Lc”) en ISO7816 et MIFARE Classic

91h

7Eh

Mauvaise taille de commande pour MIFARE DESFire

6Ah

81h

Fonction non supportée (mauvais code d’instruction par exemple) en ISO7816 et MIFARE Classic

6Bh

00h

Paramètre P1 ou P2 erroné en ISO7816 et MIFARE Classic

91h

9Eh

Erreur de paramètre pour MIFARE DESFire

On voit bien que MIFARE DESFire se comporte différemment de la norme. La documentation est donc impérative sur cette PICC pour en réaliser la programmation.

Exemples d’échanges APDU

Lire l’ID de la PICC (en héxadécimal) :

Lire les 4 octets du bloc 10 d’une PICC MIFARE Ultralight (en héxadécimal) :

Lire les 6 premiers octets sur le fichier 1 d’une application sur MIFARE DESFire (en héxadécimal) :

Lire un fichier en ISO7816 (en héxadécimal) :

Conclusion

Connaitre le format APDU permet d’établir des échanges entre le PCD et le récepteur. C’est incontournable si vous souhaitez développer une programmation de PICC ou un service HCE par exemple. Nous verrons dans un prochain article comment mettre tout cela en oeuvre pour lire une PICC via le langage Java.