L’essentiel
Référence architecture et gouvernance. La conformité d’un composant ne garantit pas l’interopérabilité du système complet.
Trois points à établir avant de conclure :
- profil et version adoptés par le projet
- domaines applicatifs et gouvernance des clés
- échange complet entre carte, terminal et service
CIPURSE définit plusieurs profils et des mécanismes communs ; le profil retenu, les domaines applicatifs, les clés et les terminaux doivent être nommés. L’ouverture du standard ne remplace pas les essais d’interopérabilité. Une recette complète vérifie personnalisation, transaction, traitement d’erreur et administration sur l’infrastructure du projet.
Un standard ouvert, trois profils
Ce standard, publié par une association d’industriels et d’opérateurs, décrit une carte à microcontrôleur pour le transport et les services urbains. L’interface radio suit l’ISO/IEC 14443, les commandes et le système de fichiers l’ISO/IEC 7816-4, et la sécurité repose sur l’AES 128 bits avec messagerie sécurisée. Trois profils, notés S, L et T, se distinguent par l’étendue des fonctions exigées ; le profil T, le plus complet, vise le transport.
Les fichiers se regroupent en applications dotées chacune de leurs clés : plusieurs exploitants partagent ainsi une carte sans accéder aux données des autres. Les opérations de valeur s’appuient sur un mécanisme de transaction protégé contre l’arrachement : si la carte quitte le champ en cours d’écriture, l’état précédent est rétabli.
Ce qui se décide avant la personnalisation
Le standard fixe les mécanismes, pas le contenu. Avant l’encodage, il faut disposer de la structure d’applications propre au réseau : identifiants, fichiers, tailles, droits et versions de clés. Nous chargeons cette structure et les clés diversifiées dans la puce, puis inscrivons dans le rapport de production l’UID et le numéro de série applicatif de chaque carte.
Un même profil peut être implémenté sur des puces de fondeurs différents. C’est l’intérêt d’un standard ouvert, et une raison de tester chaque nouvelle référence de puce sur les valideurs du réseau : durée de transaction, comportement en bord de champ et reprise après arrachement se mesurent, ils ne se déduisent pas d’une déclaration de conformité.
Supports pour la mobilité
Nous produisons ces cartes au format ISO en PVC ou en PET, avec impression recto verso, photo et numéro visible. Les titres occasionnels peuvent aussi prendre la forme de bracelets ou de porte-clés ; dans tous les cas, l’antenne est dimensionnée pour la classe d’antenne ISO/IEC 14443 attendue par les valideurs. Pour une carte nominative, la photo et le nom sont imprimés à partir du même fichier que celui qui personnalise la puce ; un contrôle final peut relire le numéro de série applicatif et le comparer au numéro imprimé au dos. Un titre anonyme est encodé sans données de porteur et ne reçoit qu’un numéro visible.
Sources primaires
À lire ensuite
01 / PUCEEM4100, identifiant 125 kHz en lecture seule
L’identifiant LF en lecture seule, ses formats d’affichage et ses limites usuelles sont expliqués dans leur contexte.
02 / PUCENormes ISO utiles en RFID et NFC
Une carte des principales familles de normes, à lire avec le protocole et l’application.
03 / USAGECartes et badges RFID en marque blanche pour intégrateurs
Des références documentées, des échantillons et une recette de lot pour sécuriser le déploiement client.
Questions fréquentes
Un gestionnaire d’immeuble peut-il ajouter sa propre application sur une carte de mobilité à ce standard ?
Oui, si une seconde application, avec ses propres clés, est prévue dans la structure de la carte et si les lecteurs du bâtiment savent l’exploiter. Sinon, ils ne liront au mieux que l’identifiant de base, ce qui ne constitue pas une authentification. Le partage de la carte se négocie avec l’autorité qui gère la structure d’applications.
Quel profil indiquer dans une demande de cartes de mobilité à ce standard ?
Celui retenu par le réseau dans ses spécifications, en général le profil T pour un titre de transport complet. Ajoutez la capacité mémoire, la structure d’applications, la version des clés et la liste des valideurs de référence. Sans ces éléments, la carte ne peut être personnalisée que pour un essai.
Les valideurs d’un réseau lisent-ils des cartes de ce standard fabriquées par un autre producteur ?
En principe oui, si le profil, la structure d’applications et les clés sont identiques : c’est le but d’un standard ouvert. Une série d’essais sur les valideurs du réseau reste indispensable, car la puce, l’antenne et la construction de la carte influent sur la durée de transaction.