Réponse fournie par Stéphane Didier de Spirtech

Les niveaux de sécurité possibles sont les suivants :

1. Aucune authentification : pas de vérification de la signature publique, ni d'authentification du support.
2. Authentification statique seulement : vérification de la signature publique (PIDSignature), mais pas d'authentification du support.
3. Authentification complète: vérification de la signature publique (PIDSignature), et authentification dynamique du support par session sécurisée Calypso.

C'est à chaque opérateur/fournisseur de service de choisir le niveau qui lui convient, en fonction des coûts et des risques.

• Pour le niveau 1, il suffit de savoir lire une carte ISO 7816-4 (commandes Select Application et Read Record), en sans contact ou au contact.
  L'opérateur/fournisseur de service est exposé à tous les risques de falsification : création de faux identifiants, duplication d'identifiants authentiques, création de faux supports, duplication de supports authentiques.
• Pour le niveau 2, il faut en plus implémenter l'algorithme de vérification ECDSA et utiliser la clé publique AMG (aucune utilisation de donnée secrète).
  L'opérateur/fournisseur de service est protégé contre la création de faux identifiants, mais reste exposé aux risques de duplication d'identifiants authentiques, de création de faux supports et de duplication de supports authentiques.
• Pour le niveau 3, il faut en plus implémenter le mécanisme de session sécurisée Calypso, qui nécessite l'accès à un SAM (qui peut se trouver dans le terminal ou dans un serveur) car il met en œuvre des clés secrètes.
  L'opérateur/fournisseur de service est alors protégé contre tous les risques de falsification des identifiants ou des supports (l'authenticité des identifiants et des supports est garantie).

Un fournisseur de terminaux ou un intégrateur pourrait donc se contenter de tester le niveau le plus faible exigé par l'opérateur/fournisseur de service.

Sur une suggestion de Claude Camilli du STIF et avec le concours de SPIRTECH

Il est possible de décorréler, par un système de tokenisation/détokenisation indépendant de la carte :

A) ce qui est dans la carte et destiné en principe à un partenaire, mais physiquement accessible à tous,

B) l'identifiant des informations personnelles du titulaire de la carte dans le système d'Information de ce partenaire.

De la sorte, même si un indélicat lit et conserve A, il ne peut remonter à B ni donc aux informations personnelles du titulaire de la carte par le biais du SI de ce partenaire, sans aussi accéder au système de détokenisation.

Sa mise en œuvre avec l'AMG actuelle ne nécessite aucune modification de la spécification, et dépend de la durée de vie du token.

Pour un token inscrit une fois pour toute :

• changement sémantique : l'identifiant dans la carte réservé au secteur d'activité du partenaire devient le token ;
• la tokénisation est l'association par le système de (dé)tokénisation de ce token à l'identifiant qui permet d'accéder aux informations personnelles du titulaire de la carte dans le SI ;
• le mécanisme de (dé)tokénisation peut être réalisé de diverses façons : calcul cryptographique avec une clé sécrète, table de correspondance, etc.

Le risque de vol de données personnelles reposant sur la robustesse du processus de tokenisation et de detokenisation ce dernier devra faire l'objet de mesures de protections renforcées. Si ces mesures ne sont pas suffisantes il sera possible de modifier régulièrement ou en réaction à la détection d'un vol du processus de tokenisation/dékonisation.Pour un token régulièrement modifié, il faudrait prévoir un système de mise à jour, stocker ce token en tant qu'identifiant personnalisé (ou éventuellement en tant que contrat, mais il n'y en a que 4 dans les structures de fichiers de l'AMG commune), et il faudra éventuellement prévoir un système de CAAD.

CAAD: "Card Access Authorization Decriptor", le mécanisme du SAM qui permet d'imposer l'utilisation d'un identifiant dans les données inscrites dans les cartes, afin de contrôler avec le SAM qui écrit quoi, et éventuellement de limiter la modification d'une donnée à l'opérateur qui l'a inscrite.

À ce jour seul Spirtech le fait, néanmoins Spirtech fournit tous les éléments, et potentiellement d'autres sociétés comme ASK pourraient le faire.

Le HSM doit répondre au standard Calypso. Aujourd'hui il n'existe qu'une seule offre (les HSM Calypso de Spirtech), donc il n'y a pas de contrainte technique. Le SAM n'est nécessaire que pour la mise en œuvre du niveau de sécurité #2 (session sécurisé). En fonction du nombre de transactions simultanées envisagées, il n'est pas forcément nécessaire de s'équiper d'un HSM PCIs (actuellement utilisé uniquement pour des applications billettiques), un HSM SAM‑S20 peut être suffisant (jusqu'à 20 sessions sécurisées simultanées)