J'utilise un lecteur HID Omnikey 5321 pour communiquer avec une étiquette Mifare DESFire EV1. Je veux écrire 16 octets dans un fichier de données standard. J'utilise la DLL WinSCard (C++) pour encapsuler la commande native DESFire dans la structure de message APDU ISO 7816. La sélection de l'application et l'authentification sont réussies mais j'ai un problème avec la commande Write Data. Les paramètres de communication du fichier sont définis sur AES, entièrement chiffrés.Communication NFC - Mifare DESFire EV1 - AES
File Nb : 00
Offset : 00 00 00
Length : 10 00 00 (LSB first)
Data (16 bytes) : 23 00 00 00 00 00 00 08 12 34 56 78 00 00 00 00
Je calcule le CRC de la Native Command:
Native command : 3D (File Nb) (Offset) (Length) (Data)
CRC = 7B 8A 60 0F
Je Chiffrer avec la clé de session et un ensemble IV 00:
32 bytes data to encipher : (Data) (CRC) 80 00 00 00 00 00 00 00 00 00 00 00
APDU sended:
90 3D 00 00 27 00 00 00 00 10 00 00 (32 bytes enciphered data) 00
En réponse, je reçois un "1 E "code d'état qui signifie CRC ou erreur de remplissage. Je ne sais pas où est le problème, l'algorithme de cryptage AES semble être bon parce que je parviens à lire les données.
Il peut s'agir du CRC ou de l'IV. Dois-je des données XOR avec le CMAC?
Juste une pensée, pourrait-il être que le CRC a un ordre des octets différent? –
Le calcul du CRC libfreefare m'a donné '30 D2 07 00' pour cette commande + en-tête + données. Au moins la feuille de données indique, que les commandes avec la longueur de données connues devraient utiliser seulement 0x00 pour le remplissage (bien que je dois admettre que les différentes sections de la feuille de données sont ambiguës, mais c'est explicitement l'état pour la commande d'écriture). –
Merci pour votre aide, je parviens à écrire des données: je change la façon dont je calcule CRC et il m'a donné '30 D2 07 00 ', je touche aussi avec' 0x00 '. – VTerrien