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. |
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) :
1 2 |
>> 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) :
1 2 |
>> 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) :
1 2 |
>> 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) :
1 2 |
>> 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.
Bonjour Florent,
Un grand merci pour cette présentation claire, précise, et sans fioritures. J’essaye de mettre en oeuvre l’API PC/SC en .Net (C#) pour lire écrire des TAG NFC, et ton article va me permettre de mieux comprendre le format APDU !
Encore merci !
Thomas
Bonjour,
Sur une Desfire EV1,j’essaie de lire le fichier 1 d’une application (6 1ers octets):
90 BD 00 00 00 01 00 00 00 06 00 00 00
Mais réponse:91 7E (Length of command string invalid)
D’avance merci
Alain
Bonjour,
En utilisant .Net (C#) et la librairie PC/SC, je fois lire et écrire sur une Carte Desfire Ev1 ou Ev2, votre article est intéressant. Mais vu que la documentation sur la Desfire est manquante, j’aimerai bien savoir si vous avez un exemple de lecture / écriture sur la Desfire Ev1 ou Ev2, ou des liens de documentations ?
Je vous remercie par Avance.
Cordialement,
Joseph
Bonjour, dans la cadre de la lecture de l’espace mémoire précédé par l’obtention de la valeur de la “capacity container”, comment procédez-vous ? Merci