Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

Ces outils nous permettent de passer des commandes via PCSC. 

Pour lancer scriptor (il faut positionner la carte avant sur le lecteur) : scriptor -r “CLOUD 4700 F Smart Card Reader [CLOUD 4700 F Contactless Reader] (53201322200637) 01 00”

FF CA 00 00 00 nous renvoie par exemple 04 53 71 D2 FD 3A 80 90 00

04 53 71 D2 FD 3A 80 est le CSN - 90 00 correspond au code de retour (opération ok).

90 6A 00 00 00 permet de lister les applications - il renvoie par exemple ici C0 85 F5 00 84 F4 40 85 F5 C1 85 F5 91 00.

En enlevant le code retour et sachant que les identifiants des applications sont sur 3 octets, nous retrouvons l'application “C0 85 F5”, “00 84 F4”, “40 85 F5” et “C1 85 F5”.

Grâce à la liste des applications enregistrées sur NXP nous arrivons finalement à retrouver à partir de ces identifiants les noms des applications.

En Desfire, les réponses se lisent de droite à gauche 2 bytes par 2 (cf 'LSB') :

“C0 85 F5” devient “F5 85 C0” - on retrouve alors 585C le code pour “identification for academic services” de “Normandie Universite”

“00 84 F4” devient “F4 84 00” - on retrouve alors 4840 le code pour “access contr,time&attendance,multifunccard” de “Horoquartz”

“40 85 F5” devient “F58540” - on retrouve alors 5854 le code pour “identification of students inench Universities (unique student number among all the country)” du “CNOUS”

“C1 85 F5” est la dernière application en date (“dérivée” de 585C) et est l'application demandée par la comue qui présente l'énorme intérêt que l'"on" dispose des clefs pour lire les fichiers présents. Ces fichiers présentent toutes un identifiant spécifique que l'on connait dans nos bases chiffrées avec 3 clefs différentes (pour des questions de confort).

On sélectionne l'application “C1 85 F5” ainsi : 90 5A 00 00 03 C1 85 F5 00

On liste les fichiers en passant la commande 90 6F 00 00 00 qui nous renvoie 00 01 02 91 00.

Le code retour 91 00 en moins, on obtient 3 octets représentant les identifiants des fichiers : 00, 01 et 02

On peut encore passer différentes commandes, notamment pour connaître les “file settings” de chaque fichier : 90 F5 00 00 01 00 00 nous renvoie 00 00 44 14 1F 00 00 91 00 - le deuxième 00 nous renseigne notamment sur le fait que le mode de communication est en plain text ( en clair), cad non encrypté … [ce qui ne doit usuellement pas être le cas sur les applications sécurisées en fait , sauf pour test].

Il faut ensuite s'authentifier en utilisant la clef spécifique au fichier que l'on souhaite lire.

C'est une authentification AES - pas des plus simples à mettre en oeuvre - et qui nécessite alors un peu d'algorithmique - celui-ci est bien expliqué sur ce document http://www.ti.com/lit/an/sloa213/sloa213.pdf à la page 6 précisément.

En suivant http://stackoverflow.com/questions/21257442/mifare-desfire-ev1-authentication-using-aes (nous permet notamment de savoir quoi mettre en tant que “IV”) on arrive à s'en sortir et il est possible de jouer l'ensemble de la procédure d'authentification en lignes de commandes (en s'aidant d'openssl pour décrypter/encrypter les différents nombres reçus et à envoyer - exemple :

echo bf7e381e6ae0c91abcdecac82abee3b2 |xxd -p -r|openssl enc -aes-128-ecb -d -K AE17129EA5C4D303F025032E2FCA2CC6 -iv 00000000000000000000000000000000 -nopad |xxd -

Nous l'avons fait de notre côté en Java (d'auant que du code est librement disponible pour ce faire, voir le code utilisé dans EsupNcTag par exemple).

Une fois l'authentification réussie, on peut enfin lire le fichier voulu : la commande suivante 90BD0000070000000016000000 permet de lire les 16 22 premiers octets du fichier 00. Fichier qu'il faut ensuite éventuellement déchiffrer.

...