Aller au contenu
← Tous les articles

Le format APDU pour communiquer en NFC

Florent Perinel
APDUCarte sans contactDESFireISO/IEC14443ISO/IEC7816NFC

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 :

CLAUsage
00hCommunication ISO7816-4 standard (envoyée directement à la PICC).
FFhCommunication 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).
90hCommunication 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 :

SW1SW 2Usage
90h00hOpération réussie ISO7816 et MIFARE Classic
91h00hOpération réussie pour MIFARE DESFire
67h00hMauvaise taille de données (incohérence entre “DATA” et “Lc”) en ISO7816 et MIFARE Classic
91h7EhMauvaise taille de commande pour MIFARE DESFire
6Ah81hFonction non supportée (mauvais code d’instruction par exemple) en ISO7816 et MIFARE Classic
6Bh00hParamètre P1 ou P2 erroné en ISO7816 et MIFARE Classic
91h9EhErreur 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) :

>> FF CA 00 00 00
<< 00 11 22 33 44 55 66 90 00

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

>> FF B0 00 0A 04
<< 11 22 33 44 90 00

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

>> 90 BD 00 00 00 01 00 00 00 06 00 00 00
<< 11 22 33 44 55 66 91 00

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

>> 00 B0 00 00 00
<< 11 22 33 44 55 66 90 00

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.

Un projet en tête ?

Discutons de vos enjeux techniques — la première conversation est toujours gratuite.

Faisons connaissance