Comment le code s'authentifie-t-il sur un tag protégé par mot de passe ?
En envoyant la commande d'authentification de la puce avec le mot de passe, en vérifiant la réponse, et seulement ensuite en lisant ou écrivant les pages protégées, le tout sur la même connexion. L'authentification dure au plus tant que le tag reste alimenté. La commande appartient à la puce, pas au type de tag.
La séquence
Un tag protégé par mot de passe refuse les opérations protégées tant qu'il ne reçoit pas le bon mot de passe, sur les puces qui en offrent un ; le réglage et sa portée sont couverts sur la page du mot de passe. Le côté du code est une courte séquence sur une seule connexion.
Il se connecte, avec NfcA sur Android ou par une session de tag sur iOS, et envoie la commande d'authentification de la puce avec le mot de passe, par transceive() ou sendMiFareCommand. Il vérifie la réponse : sur la famille NTAG21x, le mot de passe de 32 bits vient avec un acquittement de 16 bits, PACK, selon la fiche du NTAG213 sur wakdev.com, et le code compare l'acquittement qu'il reçoit à celui qu'il a configuré. Seulement ensuite il lit ou écrit les pages protégées, avant de fermer.
La commande ne fait partie d'aucun type de tag. Son code et son format appartiennent à la puce, et NTAG21x, MIFARE Ultralight C, ICODE SLIX et NTAG 424 DNA ont chacun le leur ; les fiches de puces de wakdev.com renvoient aux fiches techniques qui les définissent. Sur les puces ISO/IEC 15693 qui ont des mots de passe, les commandes qui les gèrent sont dans la plage des commandes propriétaires, comme l'explique la page ISO/IEC 15693.
Ce qui met fin à l'authentification
Un tag passif tire son énergie du champ du lecteur, comme l'explique la page de l'alimentation, et une authentification est un état retenu dans la puce. Elle tombe au plus tard quand le tag quitte le champ ; la fiche technique de la puce dit quels autres événements y mettent fin.
Une nouvelle tentative repart donc du début. Après un TagLostException sur Android ou un readerTransceiveErrorTagConnectionLost sur iOS, le tag qui revient n'est plus authentifié, et un code qui reprend par l'écriture protégée récolte un refus. Il en va de même pour une nouvelle session de tag sur iOS, et pour le nouvel objet Tag qu'Android crée chaque fois que le tag revient à portée.
Gardez l'authentification et les opérations qu'elle déverrouille sur une seule connexion et une seule classe de technologie. Ouvrir une autre classe peut faire resélectionner le tag par Android : dans la pile libre, le code de connexion peut le faire sur les tags ISO-DEP et MIFARE Classic, quand la nouvelle classe demande une autre interface du contrôleur, et ne fait rien sur un tag de type 2. Qu'une resélection mette fin à l'authentification est fixé par la fiche technique de la puce, et la pile d'un fabricant de téléphones peut en décider autrement : rester sur une seule classe est donc le choix qui tient sur tous les téléphones.
Où vit le mot de passe
Le code envoie le mot de passe, donc il doit le détenir. Un mot de passe unique compilé dans une application est dans chaque copie de l'application, et qui l'en extrait peut réécrire tous les tags qu'il protège. Un mot de passe par tag déplace le problème vers une table que l'application va chercher, le relevé que la page du mot de passe appelle une base de données à ne pas perdre.
Un mot de passe est aussi court. Celui des NTAG21x fait 32 bits, et certaines familles de puces limitent les tentatives ratées, un réglage que la page du mot de passe recommande d'activer là où il existe.
Rien de tout cela n'authentifie le tag auprès de l'application. Une copie du contenu ne porte aucun mot de passe, comme l'explique la page du mot de passe contre l'authentification, donc une application qui a besoin de savoir si un tag est authentique a besoin d'une puce qui répond à un défi cryptographique.
Ce que les API de plateforme ne font pas
Aucune API NDEF des deux plateformes ne prend de mot de passe. Ndef.writeNdefMessage() sur Android et writeNDEF sur iOS écrivent sur un tag qui accepte l'écriture, et sur un tag protégé elles échouent comme toute écriture refusée, l'échec que décrit du côté de l'utilisateur la page de l'erreur de protection.
La voie sûre est de s'authentifier par une commande brute et d'écrire les pages protégées par des commandes brutes elles aussi, ce qui veut dire construire les octets NDEF et les écrire dans un ordre sûr, comme le décrit la page des écritures interrompues. Web NFC n'offre ni l'une ni l'autre étape.
Questions fréquentes
Ndef.writeNdefMessage peut-elle écrire sur un tag protégé par mot de passe ?
Pas à elle seule. Les API NDEF ne prennent aucun mot de passe : authentifiez-vous d'abord par une commande brute et écrivez sur la même connexion, par des commandes brutes pour être sûr.
Pourquoi mon écriture échoue-t-elle après une nouvelle tentative ?
Le tag a quitté le champ et est revenu sans authentification. Renvoyez la commande d'authentification avant les opérations protégées.
Le mot de passe empêche-t-il de lire le contenu ?
Seulement sur les puces et les réglages qui protègent la lecture. La plupart des configurations ne protègent que l'écriture, comme l'explique la page du mot de passe.
Une application peut-elle garder le mot de passe secret ?
Pas de quelqu'un qui l'extrait de l'application. Toute application qui s'authentifie détient le mot de passe qu'elle envoie : traitez-le comme un verrou contre la réécriture d'occasion.