L’essentiel
Pour projets HF qui dépassent la simple lecture d’un identifiant. Plus de mémoire ne signifie pas automatiquement plus de sécurité.
Trois points à établir avant de conclure :
- données réellement sensibles
- authentification et gestion des clés
- test des droits en lecture, écriture et révocation
Ne confondez pas secret, identifiant et donnée personnelle. Un UID peut être public tout en permettant une corrélation indésirable ; une clé peut être courte ou mal partagée malgré un composant moderne. Le dossier de sécurité décrit où les clés sont créées, qui peut les utiliser, comment elles sont renouvelées et comment un support compromis est révoqué.
Trois niveaux de protection à ne pas confondre
Les puces 13,56 MHz se répartissent en trois niveaux de protection. Le premier offre une mémoire ouverte, lisible par tout lecteur compatible, avec au mieux un verrouillage définitif en écriture. Le deuxième ajoute un mot de passe court qui bloque l’écriture ou une partie de la lecture ; ce mot de passe circule en clair et peut être capté par un matériel d’écoute. Le troisième réalise une authentification mutuelle : carte et lecteur prouvent chacun connaître une clé, en général AES-128, sans jamais la transmettre, et les échanges peuvent ensuite être chiffrés.
La capacité mémoire est indépendante de ce classement : une puce de quelques centaines d’octets peut offrir une authentification forte, et une mémoire de plusieurs kilo-octets rester entièrement ouverte.
Diversification des clés et identifiant aléatoire
Avec une clé unique pour tout le parc, l’extraction de cette clé sur une seule carte compromet l’ensemble. La diversification calcule une clé propre à chaque carte à partir d’une clé maître et de l’identifiant : le lecteur la recalcule à la volée, la carte n’en contient que le dérivé. Une carte volée ne livre alors que sa propre clé.
Certaines puces peuvent aussi répondre avec un identifiant aléatoire, renouvelé à chaque mise sous tension, au lieu de leur identifiant d’usine. Cela empêche de suivre un porteur par simple lecture, mais le système ne peut plus s’appuyer sur l’UID : l’identifiant du porteur doit être lu dans un fichier protégé, après authentification. Vérifiez ce point avec l’intégrateur avant de l’activer.
Remise des clés en production
Les cartes sortent d’usine avec des clés de transport connues. Deux schémas existent : nous livrons les cartes avec ces clés et votre intégrateur les personnalise sur site, ou nous injectons vos clés en production. Dans le second cas, les clés transitent par un canal séparé des fichiers graphiques et sont traitées selon une procédure convenue avec vous avant production. Un contrôle du remplacement des clés de transport, carte par carte, peut être prévu dans cette procédure. Lorsque plusieurs applications partagent la même carte, par exemple l’accès et la restauration, chacune reçoit ses propres clés : sans la clé de l’application d’accès, le prestataire de restauration ne peut pas modifier les droits d’accès.



Sources primaires
Questions fréquentes
Chiffrer les données sur la carte suffit-il si la puce n’offre pas d’authentification ?
Le chiffrement applicatif empêche de lire le contenu en clair, mais n’empêche pas de copier les octets chiffrés sur une autre carte, qui sera acceptée si le système ne vérifie que ces données. Pour contrer le clonage, la carte elle-même doit prouver qu’elle détient un secret, ce que seule une puce authentifiante réalise.
Une carte à clés AES peut-elle aussi ouvrir une page sur smartphone ?
Oui, si la puce prévoit une application NDEF lisible sans clé à côté des fichiers protégés. Le téléphone ouvre alors l’URL publique, tandis que le lecteur d’accès s’authentifie sur la partie sécurisée. Les deux espaces se définissent dès l’encodage, car la structure de fichiers se modifie difficilement une fois les cartes remises aux porteurs.
Faut-il changer la clé maître après la perte d’une carte sécurisée ?
Non, si les clés sont diversifiées. On révoque la carte perdue en inscrivant son identifiant en liste noire ou en retirant les droits du porteur. Seule une compromission de la clé maître elle-même, par exemple via un lecteur volé mal protégé ou un poste d’encodage exposé, justifie le renouvellement des clés de tout le parc.
