Fonctionnement de Vitale SESAME

Informations de base disponible sur Wikipedia

https://fr.wikipedia.org/wiki/Carte_Vitale

https://fr.wikipedia.org/wiki/SESAM-Vitale

Cartes VItale

Il existe deux types de carte vitale. Les cartes vitale patient et les CPS (Carte professionnel santé). Lors d'une transmission à la sécurité sociale, il est nécéssaire de disposer d'une CPS.

Il semblerait que la CPS contienne un certificat qui permettrait de :

Signer les données transmises a l'assurance maladie
Déchiffer en partie les cartes vitale patient

Ces deux hypothèses sont à vérifier.

La carte Vitale patient dispose de deux types de données :

Les données autorisées en lecture libre. Ces données encodées contiennent entre autre le nom, prénon etc. du posesseur de la carte. Son numéro de sécu, un identifiant de sa mutuelle, son médecin traitant, ...
Les données protégées, il faut probablement disposer d'une clé présente dans une CPS pour pouvoir les déchiffer. La nature des ces données est pour l'instant inconnu. On peut cepandant supposer qu'il s'agit d'une partie du dossier patient du posesseur de la carte.

Veuillez visiter cette page: Types de cartes compatibles SESAM VITALE pour connaître l'inégralité des type de carte existantes.

Carte Vitale CPS

Chaque carte CPS est concidéré comme un périphérique cryptographique (via la librairie Cryptolib) dont le rôle est de signer des transactions grâce à un certificat

Carte Vitale patient

La carte Vitale patient contient au moins des données en libre lecture. Il existe probablement des données protégées, seulement lisible si on dispose d'une clé correcte.

Les données peuvent être lues par l'API de lecture Sesame/Vitale. Il S'agit d'une API propriétaire compilée en .so ou .dll. La distribution de cette API est très contrôlée par l'assurance maladie.

Fonctionnement de l'API de lecture propriétaire (Windows)

Les fonctions de désencodage se trouvent dans la DLL api_lec.dll. Le démon Galsvw32.exe (Serveur du Gestionnaire d'Acces au Lecteur WIN 32) transmet les trames ADPU et renvoie le résultat aux fonctions de api_lect.dll. Cf. schéma ci dessous:

L'API propriétaire utilise le mode de rétrocompatibilité Vitale 1 de la Vitale 2.

Les données sont désencodés par des opérations OR SHR SHL (ou logique et décaages de bits) qui dépendent de la position de l'octet dans la donnée à désencoder.

Les données sont encodés sur un certain nombre de bits, variable suivant leur nature : Character, Nomber, Boolean, etc.

Ces données suivent toujours le même format, définies par des chaines codées en dur dans api_lec.dll. Par exemple:

“1B1B4B1N1N1N6N1N1N6N6N6N6N#16A#26A”

Signifie que l'on va d'abord décoder 26 lettres (le A désigne les lettres), suivi de 16 lettres, (le # signalant les dizaines), suivi de 6 chiffres, etc. (b étant un booléen codé sur 1 bit). Ces chaines
sont insensibles à la casse.

Par convention, on parlera désormais de "clés de format" pour définir ces chaînes.

Les données encodées peuvent être obtenues en utilisant les paquets suivant (ADPU):

 BC B0 02 B0 00 
 BC B0 04 A0 00
...

L'ordre dans lequel les chaînes sont à processer varie d'une carte à l'autre. L'ordre des mots est encodé par un algorithe différent de celui de désencodage des données. Les données de position des clés de format peuvent être obtenues en utilisant les paquets suvants:

BC B0 02 B0 04 
BC B0 05 40 0C 
BC B0 21 40 18
BC B0 20 F0 28
BC B0 20 A0 28

Recuperation des informations de la carte Vitale

Ci dessous le diagramme d'activité de récupération des données de la carte Vitale, les algorithmes de constructuin des messages sont définis dans les chapitres qui suivent.

Cet algorithme de génération des messages ADPU est celui de la librairie propriétaire, et des premières versions Alpha d'Alibaba. Cet algorithme a été revu et simplifié dans la première version stable. Je vous conseille donc de vous référer à l'implémentation d'Alibaba 1.0. L'algorithme propriétaire est inutilement complexe. Veuillez vous référer à la page suivant pour plus d'informations : Génération des messages ADPU par Alibaba .

Récupération des métadonnées

Pour déchiffrer la carte, il est nécéssaire de connaître l'emplacement mémoire des métadonnées afin de pouvoir générer le message de récupération des addresses.

Par convention, la lecture d'une carte Vitale commence toujours par le message ADPU:

BC C0 00 00 08

Une trame du type suivant est alors renvoyé:

00 00 21 98 00 00 0C 07

En prenant les octets 3 et 4, nous obtenons le nombre 21 98. C'est ce nombre qui sera utilisé pour générer le message de récupération des addresses.

Pour ce faire, on soustrait 0x8 (taille de la réponse précédente) puis 0x50.

0x2198 - 0x8 = 0x2190

0x2190 - 0x50 = 0x2140

Le messagee de récupération des addresses a par convention une longueur de 8. Le message sera donc le suivant:

 BC B0 21 40 08

Récupération du numéro de série de la carte

A partir des données précédentes, il est possible de générer le message ADPU qui nous premettra de déterminer le numéro de série de la carte.

Cette récupération nécéssite la génération d'un message intermédiaire. On reprends notre valeur 21 98 à laquelle on y soustrais 0x08.

0x2198 - 0x08 = 0x2190

On vérifie ensuite si le numéro de série est récupérable. Pour ceci, il nous faut forger un autre message ADPU. On reprends la valeur précédente à laquelle on retranche 0x20.

0x2190 - 0x20 = 0x2170.

La longueur est par convention de 0x04. Le message sera donc:

BC B0 21 70 04

Voici ci dessous un exemple de réponse:

3F 5F EE A1

On regarde alors les le premier octet: 0x3F.

Si un des deux premiers bits sont différents de zéro, alors le numéro de série ne peut pas être récupéré de cette facon.

Par exemple, ici :

0x3F = 00111111 Ce qui nous autorise à récupérer le serial. A l'inverse, un nombre tel que 0xFF = 11111111 ne nous l'aurait pas permis.

Pour vérifier ceci facilement, il suffit de faire un ET logique du nombre récupéré et de 0xC0.

Si le numéro de série peut être calculé, nous allons maintenant générer le message ADPU qui permet de le récupérer. Pour ce faire, on reprends le nombre précédent: 0x2190 auquel on soustrait de nouveau 0x08.

0x2190 - 0x08 = 0x2188

Le message ADPU de récupération du numéro de série (d'une longueur de 0x04 par définition) sera donc:

BC B0 21 88 04

Pour le désencodage des données renvoyées, je vous renvoie à la page suivante : Algorithme de décodage du serial

Message de récuperation des addresses : Récupération des données

Il est donc nécéssaire de disposer de deux types de données différentes pour pouvoir lire une carte Vitale: Le dictionnaire des positions des clés de format et les données elle mêmes.

Les plages d'adressages où ces données peuvent être trouvées sur la carte sont données par les données renvoyées par le message ADPU

 BC B0 21 40 08

Les données renvoyées sont de la forme:

3F 21 40 E1 3F 02 B0 E1 ?!@.?..

0xE1 seraient des séparateurs marquant la fin des données (0x3F correspondraient à des donnés vides). A partir des nombres situées entre ces séparateurs, il est possible de calculer les plages mémoire à récupérer utiles pour déchiffrer la carte.

ATTENTION ! Une partie des données ne peut pas etre récupéré de cette facon, mais via des addresses contenues dans le dictionnaire des positions. Je vous renvoie au chapitre "Anatomie du dictionnaire" pour plus de détails.

Récupération des données d'ordre des clés de format:

Le premier nombre (0x2140) permet de claculer l'emplacement du dictionnaire des positions des clés de format. Il suffit d'y soustraire 0x50.

0x2140 - 0x50 = 0x20F0

Par définition, chaque trame de dictionnaire a forcément une longueur de 0x28.

La première trame pour récupérer le dictionnaire sera donc:

 BC B0 20 F0 28

Pour calculer les trames suivantes, il suffit continuer à soustraire 0x50. La trame suivante sera donc:

0x20F0 - 0x50 = 0x20A0

BC B0 20 A0 28

Conditions d'arret

On continue à générer des messages ADPU jusqu'à ce qu'une des conditions définies dans ce paragraphes soient remplies.

On atteint un paquet vide. Pour ceci, on découpe la réponse de la carte au message tous les 4 octets en partant de la fin. Si on rencontre quatre fois l'octet 0xFF, alors on arrete de générer les paquets.
On atteint un signal d'arret: on découpe la réponse de la carte au message tous les 4 octets en partant de la fin. Si la jonction entre des 4 derniers bits de l'octet 0 suivi des deux premiers bits des l'octet 1 sont égaux à 0x3F, on arrete de générer des paquets.

Les exemples suivants illustrent les cas d'arrets.

Cas Numéro 1 : Soit la trame de réponse suivante:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF                         ........

On découpe la trame tous les 4 octets.

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF

On commence par les 4 derniers octets:

FF FF FF FF

So on ne trouve que des 0xFF (ce qui est le cas ici), alors on arrete de générer des paquets.

Cas numéro 2: Soit la trame de réponse suivante:

On découpe la trame tous les 4 octets.

FF FF FF FF 3F FF 56 B7 4A 36 9F FF C6 D5 55 34 ................
25 60 C0 AA 5C 99 05 CA 5D E9 10 36 BA 32 41 CA ................
60 CC 87 CC 2C FF C2 B1

On prends les 4 derniers octets.

2C FF C2 B1

Puis, on prends les 2 premiers octets:

 2C FF

Ce qui nous donne en binaire:

00101100 11111111

On compare a:

Ce qui ne convient pas. On passe alors à la suite de 4 octets suivants:

60 CC 87 CC

etc. jusqu'à les 4 octets suivant:

3F FF C6 88

Puis, on prends les 2 premiers octets:

3F FF

Ce qui donne en binaire:

00111111 11111111

On compare à :

Les deux valeurs sont égales, alors on arrete de générer des paquets.

Anatomie du dictionnaire

Je vous renvoie a la page dédiée si vous souhaitez obtenir des informations sur l'algorithme de désencodage des données utilisateur des mots ou l'algorithme de désencodage du dictionnaire.

Le dictionnaire des positions semble constitué par des suites de 5 nombres:

 0x01 0x33 0xff 0xb0 0x02
 0x01 0x80 0xff 0xb8 0x02
 0x01 ...
 0x01 0x34 0xff 0x40 0x05
 0x01 ...

Chaque suite de 10 nombre semble ordonnnée de la facon suivante:

[0x01] [Un identifiant du mot clé de désencodage] [0x00 ou 0xFF] [Addresse memoire de debut (octet léger)] [Addresse memoire de debut (octet lourd)]

Par exemple, pour la premiere ligne:

0x01 0x33 0xff 0xb0 0x02

Le mot clé est celui ayant l'identifiant 0x33 et l'addresse mémoire correspondante est 0x02 0xB0. Le role du 0x00 ou 0xFF, qui semble etre un booléen n'a pas encore été découverte.

L'ordre dans lequel se suivent les lignes nous donnent l'ordre dans lequel il faudra enchainer le décodage des mots.

Dans notre exemple, on commencera à décoder le mot correspondant a 0x33, suivi de celui correspondant à 0x80.

ATTENTION ! Il y a chaque fois deux identifiants qui correspondent a un unique mot clé. On peut donc avoir deux lignes différentes qui ont la même signification. Pour obtenir les correspondances entre mots clés et identifiants, veuillez consulter la page suivante:

Identifiants clés de format.

Génération des messages ADPU depuis le dictionnaire.

Il existe des exceptions à l'algorithme de récupération des données décris dans les chapitres qui suivent. En effet, il est nécéssaire de générer un certain nombre de messages ADPU directement depuis le dictionnaire. Pour ce faire, on commence par récupérer la premiere addresse rencontrée. Dans notre exemple, il s'agit de

0xb0 0x02

On construit donc le message suivant (taille 0x04 définie par convention):

BC B0 02 B0 04

Puis, on continue à parser ligne par ligne jusqu'à ce que l'on rencontre l'identifiant du mot 0x34. On génère alors un autre message à partir des addresses mémoire correspondantes. Dans notre exemple, ce paquet serait:

BC B0 05 40 0C

La taille 0x0C est définie par convention.

Récupération des données à déchiffrer:

Remarque: Il existe deux facons différentes de récupérer les données à désencoder:

Soit on récupère toutes les données d'un coup, puis on découpe ces données en fragments a partir du dictionnaire pour savoir quel où se situe le premier octet d'un mot encodé. (On génère donc très peu de messages ADPU. Le gros du travail de découpage se fait après la récupération des données).
Soit on récupère mot à mot les données à désencoder en se servant des addresses du dictionnaire. (Et donc on génère autant de messages ADPU)

Le premier choix est plus performant plus plus compliqué à implémenter, le second choix est moins performant, mais plus simple à implémenter. La librairie propriétaire utiliser le premier choix. Pour des questions de coût de maintenabilité, Alibaba utilise actuellement le second.

La seconde valeur, 0x02B0 permet de construire le message ADPU qui récupère les données à décoder. Pas d'opérations particulières. Le premier message ADPU pour récupérer les données sera donc:

BC B0 02 B0 XX

Calcul de la taille des données à récupérer.

On reprends le dernier quatuor d'octets que l'on a précédement récupéré. Dans notre exemple, il s'agissait de :

3F FF C6 88

On prends les 12 derniers bits de ce quatuor

3F FF C6 88

Ce qui nous donne le nombre 0688. Cette valeur correspond à la taille totale de notre plage mémoire.

On calcule ensuite la longueur de la plage mémoire à récupérer en y soustrayant l'addresse de début des données brutes: 02B0 dans notre exemple.

Pour terminer, on divise le résultat par deux.

0688 - 02B0 = 3D8
3D8 / 2 = 1EC

Ensuite, on découpe cette plage en blocs de 248 octets (0xF8 en hexadécimal).

1EC = F8 + F4

On aura donc deux messages ADPU à générer. L'un d'une taille de 0xF8 et l'autre d'une taille de 0xF4.

Calcul des plages mémoire

Le premier paquet utilisera directement les plages mémoires calculées. Dans notre exemple, ce paquet sera:

BC B0 02 B0 F8

Puis, pour les paquets suivants, on ajoute deux fois la taille mémoire cumulée déjà récupérée.

Par exemple, pour le paquet suivant de notre exemple, on doit effectuer le calcul suivant:

02B0 + 2 * F8 = 02B0 + 01F0 = 04A0

Le paquet suivant sera donc:

BC B0 04 A0 F4

On continue à générer des paquets jusqu'à arriver à une taille à récupérer nférieure à 0xF8. Dans notre cas, F4 < F8. Donc, on s'arrete au second paquet généré.

Traitement des données désencodées

Suite au désencodage des données, il est nécéssaire d'effectuer plusieurs manipulations sur nos données pour que celle-ci soient exploitables.

Calcul de la cle de controle

Il est nécéssaire de calculer la clé de controle du numéro de sécurité sociale. Cel algorithme est public:

La clé de contrôle du NIR est un nombre à deux chiffres dont la valeur est le complément à 97 du reste de la division du nombre formé par le NIR par 97. Cette formule a été adaptée aux numéros de départements alphabétiques (2A et 2B) de la manière suivante

Les caractères alphabétiques sont remplacés par des "0".
On soustrait du nombre à 13 chiffres ainsi obtenu la valeur 1000000 si le caractère alphabétique remplacé par un zéro était la lettre A, ou la valeur 2000000 si c'était la lettre B.

Format des données

Voici le formattage des données correspondant aux différentes clés de format:

Clé de format	Données correspondantes
[14N] [2N] [1N] [3N] [4N] [6N] [60B] [1B] [1A] [1A]	[NIR] [Code regime] [?] [Caisse] [Centre carte] [Date de début de la période de droits] [Durée de la période de droits en mois *] [?] [Identifiant du mode de calcul du code gestion] [?]
[1B] [1B] [4B] [1N] [1N] [1N] [6N] [1N] [1N] [6N] [6N] [6N] [6N] [#16A] [#26A]	[?] [?] [?] [?] [?] [?] [Date de naissance] [?Rang de naissance?] [?Qualité benéficiaire?] [?] [?] [?] [?] [Prénom] [NOM]
[1B] [8B] [50B] [8N] [4N] [2N] [1A]	[?] [?] [Durée de la période mutuelle en mois *] [Numero identite mutuelle] [Date de debut de la mutuelle au format YYmm] [?] [?]
[13X] [8N]	[NIR certifie] [Date de certification]
[27A]	[Nom de jeune fille]
[#33X] [#33X] [#33X] [#33X] [#33X]	[Addresse ligne 1] [Addresse ligne 2] [Addresse ligne 3] [Addresse ligne 4] [Addresse ligne 5]
[2N] [8N] [8N] [2N] [8N] [8N]	[?] [? Date inconnue ?] [? Date inconnue ?] [?] [?] [?]
[2N] [8N] [8N]	[?] [? Date inconnue ?] [? Date inconnue ?]
[1X] [29X]	[?] [? Medecin traitant ?]
[8N] [1N] [24X]	[Date de fin de validite de la carte] [?] [?]

Remarque: On peut parfois trouver plusieurs fois dans les données de la carte la même clé de format. Il s'agit en fait de l'historique de l'utilisateur de la carte. Dans ce cas, il faut prendre la dernière occurence pour avoir la situation actuelle de l'utilisateur.

Par exemple, on pourrait avoir (dans l'ordre de désencodage):

1530155103042099072106010710000000000010000000000000001111111111111111111111111111111111__
153015510304200102748341110000001000000001000000000000001111111111111111111111111111111__

L'ancienne situation est donc : 15301551030420 99 072106010710000000000010000000000000001111111111111111111111111111111111__ (ex. avec le code régime 99 qui est celui des étudiants)

La situation actuelle est donc: 15301551030420 01 0 2518341110000 001000000001000000000000001111111111111111111111111111111__ (ex. avec le code régime 01 qui est le régime général)

Dans notre exemple, le posesseur de la carte est donc passé d'un régime étudiant vers le régime général.

* La période est constituée d'une suite de booléens. Chaque booléen représente un mois. Pour obtenir la durée de la période, on compte le nombre de zéros qui se suivent a partir de la gauche. Par exemple:

0000000000000000000000011111111111111111111111111111111111111

Contient 23 zeros qui se suivent (ici en vert), la période concernée est donc de 23 mois.

Il se peut que la période soit coupée en plusieurs fois. Par exemple:

0000000001000000000000011111111111111111111111111111111111111

Dans ce cas, on ne tiens compte que de la dernière série de zeros (ici 13 mois en vert) pour connaitre la durée de la période actuelle.

Calcul du code de gestion

Voir la page suivante: Algorithme de calcul du code de gestion

Calcul du centre de gestion

Voir la page suivante: Algorithme de calcul du centre de gestion

Tables annexes

Les tables officielles utilisées pour l'exploitation des données peuvent être consultées à la page suivante : Tables annexes

Les règles de remboursement se trouvent dans le fichier tablebin.lec. Le format de ce fichier est propriétaire. Néanmois, par ingénierie inverse, nosu sommes en mesure de comprendre le formattage assez simple du fichier pour l'exploiter. Veuillez vous référer à la page suivante pour plus d'informations: Table des remboursements tablebin.lec

Mise à jour

Les cartes vitales peuvent être mises à jour en les branchant sur une borne de la CPAM. Une authentification par Challenge / Response permettrait l'authentification de la borne par la carte et sa mise à jour.

Il est envsageable de réaliser un MINTM entre la borne et la carte en utilisant un microcontrolleur pour découvrir les trames utilisées et éventuellement modifier à la volée les données de la carte. Cette hypothèse reste à tester.

Transmission à la sécurité sociale

Pas encore d'informations.