Comment un serveur lit-il l'identifiant qu'un tag recopie dans son adresse ?
Comme une partie de l'adresse demandée. Une puce à miroir écrit son identifiant, et sur certaines puces son compteur de lectures, dans l'adresse en caractères hexadécimaux, à une position choisie quand le tag a été configuré. Le serveur les extrait, vérifie leur longueur et leurs caractères, et les traite comme une affirmation, pas comme une preuve.
Ce qui arrive au serveur
La puce insère les caractères au moment où le tag est lu, si bien que le téléphone reçoit une adresse qui les contient déjà, et la page de l'adresse unique explique pourquoi cela rend distinguables des tags écrits identiquement. Le serveur reçoit une requête ordinaire pour cette adresse.
Il ne la reçoit que si le téléphone ouvre le lien. Un iPhone qui lit un tag en arrière-plan affiche un avis qu'il faut toucher, et depuis Android 17 un téléphone Android en affiche un aussi, selon la page du comportement d'Android. Un utilisateur qui l'ignore a lu le tag sans que le serveur en entende parler.
Le compteur tient son propre compte. Sur un NTAG213 il s'incrémente à la première lecture après l'entrée du tag dans le champ, selon sa fiche sur wakdev.com, qu'une requête suive ou non, donc les trous entre les valeurs que reçoit un serveur sont normaux : la page des codes tournants appelle cela une dérive.
Extraire les valeurs
Où atterrissent les caractères se décide à la configuration du tag, par les réglages de miroir que décrit la fiche de la puce. Placez-les dans un paramètre de requête nommé ou dans un segment de chemin fixe de l'adresse écrite sur le tag, et analysez la requête par ce nom, pas en comptant les caractères depuis le début de l'adresse.
L'identifiant d'un NTAG213 fait sept octets, selon la même fiche, donc il arrive en quatorze caractères hexadécimaux ; son compteur fait 24 bits, six caractères. Une puce d'une autre famille a d'autres longueurs, et le code les prend sur la fiche de cette puce plutôt que sur le premier tag rencontré.
Valider avant de s'en servir
N'importe qui peut taper l'adresse, donc les valeurs sont une entrée comme une autre. Vérifiez la longueur et que chaque caractère est hexadécimal, comparez sans tenir compte de la casse, et rejetez tout le reste avant que cela n'atteigne une requête de base de données ou un journal que quelqu'un lira.
Un format valide ne dit rien de l'existence. Cherchez l'identifiant dans le registre des tags déployés, le relevé de quel tag porte quoi, et traitez un identifiant inconnu comme inconnu, pas comme un nouveau tag à créer.
Quand l'identifiant appartient à un objet qu'une personne porte, un badge par exemple, le relevé devient une donnée sur cette personne, et la page de la protection des données couvre ce qui s'ensuit.
Pourquoi cela ne prouve rien
L'identifiant recopié est lisible par quiconque touche le tag, et l'adresse qui le porte peut être copiée et rejouée sans le tag. La page de l'adresse unique le dit sans détour : il identifie plutôt qu'il n'authentifie.
Un simple compteur ajoute peu. Un serveur qui retient la plus haute valeur vue pour chaque identifiant peut rejeter une ancienne adresse rejouée telle quelle, mais n'importe qui peut taper un nombre plus grand, et celui qui tient le tag en lit un tout frais, la limite que décrit la page des codes tournants.
Une preuve demande une valeur que le serveur puisse vérifier cryptographiquement. Le NTAG 424 DNA insère un CMAC AES dérivé de son identifiant et d'un compteur de 24 bits, vérifiable côté serveur, selon sa fiche sur wakdev.com. Comment le vérifier appartient à la documentation de cette puce, et ce que le vérificateur doit détenir à la page de la vérification.
Questions fréquentes
Pourquoi deux requêtes portent-elles la même valeur de compteur ?
La même adresse a été ouverte deux fois sans nouvelle lecture, par un rechargement ou une copie du lien. Une nouvelle lecture du tag aurait produit une nouvelle valeur.
Pourquoi le compteur fait-il des bonds entre deux requêtes ?
Le tag a été lu sans que le lien soit ouvert, et le compteur s'incrémente à chaque lecture. La page des codes tournants appelle cela une dérive.
L'identifiant recopié est-il unique ?
C'est l'identifiant d'usine, censé être unique dans l'allocation d'un fabricant, et lisible par n'importe qui. Il identifie un tag, il n'en authentifie pas un.
Un serveur peut-il distinguer un tag authentique d'une adresse copiée ?
Pas avec un simple miroir. Il y faut une puce qui insère une valeur cryptographique, comme le CMAC du NTAG 424 DNA, et un serveur qui détient la clé.