Guide d`intgration des APIs CPS - esante.gouv.fr, le portail de l`ASIP

Transcription

GUIDE-51.doc
01/09/2004 2:43
GR
ER
ET
PU B
L IC
Fichier Word :
Enregistré le :
OU
T
’IN
PEM EN T D
GUIDE D'INTEGRATION
des Services Logiciels
de la CPS
Version 5.1 du 09 décembre 2003
09 décembre 2003
Documentation GIP "CPS"
© GIP "CPS" : Ce document est la propriété du Groupement d'intérêt Public CPS.
Page 1 / 74
GIP "CPS"
Guide d'Intégration des
Services Logiciels de la CPS
Version 5.1
SOMMAIRE
1
Introduction ................................................................................................................. 6
2
Bibliographie ............................................................................................................... 6
3
Définitions.................................................................................................................... 7
4
Abréviations................................................................................................................. 9
5
Définitions sur la carte "CPS" .................................................................................. 10
5.1
5.2
Cycle de vie de la carte "CPS"........................................................................................................................... 10
5.1.1
La phase administrative d'une "CPS" .......................................................................................................... 10
5.1.2
La phase d'exploitation de la "CPS" ............................................................................................................ 10
5.1.3
La fin de vie de la "CPS" ............................................................................................................................. 10
Données de la carte "CPS"................................................................................................................................. 11
5.2.1
Le visuel de la carte "CPS".......................................................................................................................... 11
5.2.2
Les données internes de la carte "CPS" ....................................................................................................... 12
5.3
Notions sur l'algorithme RSA à clé publique de la CPS .................................................................................. 14
5.4
Certificat X.509 des clés publiques de la CPS................................................................................................... 15
5.5
La CPS et la confidentialité ................................................................................................................................ 17
6
Les services de la carte CPS.................................................................................... 18
6.1
Procédures liées à la CPS.................................................................................................................................... 18
6.2
Les services de lectures des données .................................................................................................................. 19
6.3
Tables de codification des données de la "CPS" .............................................................................................. 24
6.4
Les services cryptographiques ........................................................................................................................... 25
6.4.1
Services liés à l'authentification de la "CPS"............................................................................................... 25
6.4.2
Services liés à la signature électronique ...................................................................................................... 26
6.4.3
Services de gestion des certificats X.509 des clés RSA .............................................................................. 28
6.5
Services de gestion de la carte ............................................................................................................................ 30
6.6
Services de gestion des sessions .......................................................................................................................... 32
6.7
Services de gestion du code porteur................................................................................................................... 33
6.8
Intégration des services....................................................................................................................................... 35
09 décembre 2003
Page 2 / 74
GIP "CPS"
7
Version 5.1
6.8.1
Structure interne des services ...................................................................................................................... 36
6.8.2
Code retour des services .............................................................................................................................. 38
6.8.3
Paramètre d'état de la carte .......................................................................................................................... 41
6.8.4
Paramètres d'état d'exécutiond'un service .................................................................................................... 41
6.8.5
Performances des services ........................................................................................................................... 41
6.8.6
Recherche d'une solution d'intégration ........................................................................................................ 42
Logiques d'enchaînement des services "CPS" ...................................................... 43
7.1
Définition des types des applications ................................................................................................................. 43
7.1.1
Application "autonome"............................................................................................................................... 43
7.1.2
Applications "intégrées" .............................................................................................................................. 43
7.1.3
Applications "réparties" (poste et central) ................................................................................................... 43
7.2
Services de gestion de la carte ............................................................................................................................ 44
7.3
Services de lecture de données de la carte......................................................................................................... 46
7.4
Services d'authentification de la carte............................................................................................................... 48
7.5
Services de signature électronique ..................................................................................................................... 49
7.6
Services de contrôles de certificat X.509 ........................................................................................................... 50
8
Règles d'installation des logiciels des services "CPS" ......................................... 51
9
Annuaire du GIP "CPS" ............................................................................................ 52
10
Relations entre le Promoteur et le GIP "CPS" ........................................................ 53
10.1
KITs d'intégration et licence d'utilisation des services API........................................................................ 53
10.1.1 Environnements informatiques .................................................................................................................... 53
10.1.2 Description du KIT ...................................................................................................................................... 54
10.1.3 Commande du KIT ...................................................................................................................................... 54
10.2
Formation au GIP "CPS".............................................................................................................................. 55
10.3
Support au GIP "CPS".................................................................................................................................. 55
10.4
Suivi et rapports d'anomalies ........................................................................................................................ 55
11
ANNEXES ................................................................................................................... 56
11.1
Synoptique des services "CPS" ..................................................................................................................... 57
11.2
Synoptique des Codes Retours des services "CPS"..................................................................................... 59
11.3
Performances des Services CPS .................................................................................................................... 61
09 décembre 2003
Page 3 / 74
GIP "CPS"
Version 5.1
11.4
Fiche de rapport d'anomalie (RA) ................................................................................................................ 62
11.5
Principales Questions - Réponses .................................................................................................................. 64
11.5.1 Répartition des services sur le poste ou le serveur ?.................................................................................... 64
11.5.2 La carte CPS et la carte VITALE ?.............................................................................................................. 66
11.5.3 Langages de programmation des API's et compilateurs ?............................................................................ 67
11.5.4 Connexion série de lecteurs NF CPS sur le Macintosh ?............................................................................. 69
11.5.5 La CPS et la gestion des dates ? .................................................................................................................. 70
11.5.6 Compatibilités entre les versions de CPS et de KIT ? ................................................................................. 71
11.5.7 Accès à l'annuaire des certificats X.509 ?.................................................................................................... 72
11.5.8 CPS et lecteurs PC / SC ? ............................................................................................................................ 74
09 décembre 2003
Page 4 / 74
GIP "CPS"
Version 5.1
FICHE DE SUIVI DU DOCUMENT
Date
Intervenant
Version
11 / 06 / 97
JLB
0.1
18 / 06 / 97
10 / 10 / 97
27 / 10 / 97
31 / 12 / 97
VC
JFL
WI
JLB
JLB
JLB
0.2
0.2
0.2
0.3
0.4
1.0
24 / 08 / 99
JLB
2.1
31 / 05 / 00
30 / 06 / 00
09 / 01 / 01
05 / 02 / 01
04 / 12 / 01
12 / 06 / 02
.. / 06 / 03
LR, JLB
JLB
JLB
JLB
JLB
JLB
JLB
2.2
2.3
4.3
4.3
4.4
5.0
Chapitre(s)
Objet de l'évolution
Création 1ère version
6.2 7.2
9 10 11 annexes
6
7.3
12.5
6.5 7.4.3 8.6
9
11
Refonte
Refonte
Corrections sur V 0.1
Dictionnaire des données de la CPS
Questions / Réponses
La CPS et le chiffrement
Listes d'opposition | blanche
Services de confidentialité
Certificats X.509
Suppression TPC
et toutes leurs conséquences…
Corrections
Remplacement CPDIC par CPTAB
Mise à niveau du KIT 4.3
Corrections éditoriales
Mises à jour KIT 4.45
Corrections éditoriales
CPS2ter ; KIT V 5
1
09 décembre 2003
Page 5 / 74
GIP "CPS"
Version 5.1
Introduction
Le présent document a pour objectif de décrire les règles de programmation des Services Logiciels de
la CPS.
Ce document est destiné au Promoteur d'Application qui désire intégrer les Services Logiciels
fournis dans le KIT d'intégration du GIP "CPS".
Les recommandations ou règles décrites sont applicables indépendamment de l'environnement
d'exploitation de l'application.
Le chapitre 5 "Définitions sur la carte "CPS" donne les concepts utiles à connaître pour comprendre
la suite du document.
Le chapitre 6 "Les services de la carte CPS" détaille les fonctionnalités des services.
Le chapitre 7 "Logiques d'enchaînement des services "CPS"" explique au promoteur la logique à
suivre pour l'intégration de ces services dans des procédures.
Les textes écrits en italique sont des compléments ou des précisions donnés à titre informatif
pour une meilleure compréhension générale du sujet.
2 Bibliographie
Les données de la CPS - Allocation des tags et tables de codification.
Les données de la CPS - Fichiers internes après personnalisation.
Manuel(s) de programmation des API des Services CPS
3
09 décembre 2003
Page 6 / 74
GIP "CPS"
Version 5.1
Définitions
Carte Patient-Assuré : carte pouvant contenir des données administratives et/ou médicales.
Carte de Professionnel de Santé : carte du professionnel de santé, réservée aux Professionnels de
Santé réglementés par le code de la santé publique.
Carte de Professionnel en Formation : carte du professionnel de santé en formation.
Carte de Personnel d'Etablissement : carte émise vers les personnels des établissements de soins :
∗ un établissement de santé répertorié par son N° FINESS,
∗ une société d'exercice libéral répertoriée par son N° SIREN ou SIRET,
∗ un professionnel de santé (exemple : secrétaire médicale, ...) répertorié par son N°
d'identification cabinet.
Carte de Personnel Autorisé : carte destinée aux personnes employées par des établissements qui
ne rentrent pas dans la catégorie d'établissements pouvant déployer des CPE. L'autorisation des
établissements est sous la responsabilité du Ministère de l'Emploi et de la Solidarité.
KIT d'intégration : livré par le GIP "CPS" ce KIT comprend en standard :
- Les logiciels des services "CPS".
- La documentation associée : manuels de programmation.
- Une démonstration de la programmation de ces services.
- L'application de gestion de la CPS.
- [ Un dispositif de lecture de cartes "CPS". ]
- [ Un jeu de cartes "CPS" de tests. ]
Format TLV : méthode de structuration des champs de données de longueurs variables utilisée dans
la carte "CPS". Le premier octet contient le type de donnée, le deuxième la longueur de la donnée
et le troisième la valeur de la donnée.
Masque "CPS" : désigne le "système d'exploitation" des cartes de la famille CPS.
Personnalisation : partie de la Phase Administrative du cycle de vie de la carte qui consiste à
inscrire dans (et à marquer sur) la carte "vierge" les différents éléments (données titulaire et
applicatives, clés secrètes, etc.) pour rendre la carte "opérationnelle" avant sa remise au titulaire.
09 décembre 2003
Page 7 / 74
GIP "CPS"
Version 5.1
Promoteur d'Application :.le développeur d'applications ou l'intégrateur d'applications qui
exploitent la "CPS" et ses services associés dans ses applications. Il reçoit du GIP "CPS" le KIT
d'intégration.
Service CPS : unité logicielle appelée par l'application pour réaliser des fonctions de la CPS.
Un service est constitué d'une interface API et d'une logique de traitement de la fonction.
4
09 décembre 2003
Page 8 / 74
GIP "CPS"
Version 5.1
Abréviations
ASCII
American Standard Code for Information Interchange
API
Application Programming Interface
APDU
Instruction élémentaire exécutée par la carte "CPS"
ATR
Answer To Reset = réponse d'une carte à sa mise sous tension
CPS
Terme générique de la Carte Professionnel du Secteur Santé qui se décline en :
• CPE
Carte Personnel d'Etablissement (obligatoirement de modèle CPE-C)
• CPF
Carte Professionnel en Formation
• CPF-C
Carte Professionnel en Formation dans une structure (le PF est employé de la structure)
• CPS
Carte Professionnel de Santé
• CPS-R
Carte Professionnel de Santé de remplacement (le PS se fait remplacé)
• CPS-C
Carte Professionnel de Santé dans une structure (le PS est employé de la structure)
• CPE
Carte Personnel d'Etablissement dans une structure
• CPA
Carte Personnel Autorisé dans une structure
CS
Clé de Session de chiffrement
FSE
Feuille de Soins Electronique
Kp-aut
Clé publique d'authentification
Ks-aut
Clé secrète d'authentification
Kp-gip
Clé publique de certification par le GIP
Ks-gip
Clé secrète de certification par le GIP
Kp-sgn
Clé publique de signature
Ks-sgn
Clé secrète de signature
Kp-kek
Clé publique d'échange de clé de session
Ks-kek
Clé secrète d'échange de clé de session
PF
Professionnel de santé en Formation
PS
Professionnel de Santé
RSA
Algorithme cryptographique (du nom de ses inventeurs Rivest, Shamir et Adelman)
TLV
Tag Length Value
5
09 décembre 2003
Page 9 / 74
GIP "CPS"
Version 5.1
Définitions sur la carte "CPS"
5.1 Cycle de vie de la carte "CPS"
5.1.1
La phase administrative d'une "CPS"
La phase administrative de la "CPS" est la phase de création de la carte.
Elle est décomposée en 3 étapes : fabrication du composant, encartage et personnalisation.
Elle aboutit à la mise en exploitation de la carte.
1. Fabrication des composants chez le fondeur, suivi par l'inscription des données du
fondeur.
2. Encartage du composant chez l'encarteur dans un support plastique, suivi par l'inscription
des données de l'encarteur (pré-personnalisation).
3. Personnalisation de la carte chez le personnalisateur : inscription des données porteur et
applicatives. Inscription des secrets (les clés) d'exploitation et de gestion.
5.1.2 La phase d'exploitation de la "CPS"
La phase d'exploitation de la "CPS" correspond à la vie de la carte
Elle est décomposée en 2 étapes : distribution par l'émetteur (le GIP "CPS") et utilisation par le
porteur (le Professionnel de Santé).
Elle se terminera à la fin de vie de la carte.
4. Distribution sous contrôle du centre de gestion de l'émetteur vers le porteur et
gestion de la "liste blanche" des cartes en exploitation et de leurs données publiques.
5. Utilisation par le porteur (vie active de la carte) grâce à des applications développées par
les promoteurs.
Durant son utilisation, la "CPS" peut être mise à jour : des données sont modifiées par le
gestionnaire suivant des procédures sécurisées de télé-actualisation.
5.1.3
La fin de vie de la "CPS"
La fin de vie de la carte "CPS" peut être provoquée accidentellement (panne, perte, vol, opposition)
ou naturellement (renouvellement de carte ou résiliation du contrat du porteur)
6. La fin de vie de la carte "CPS" est un événement qui doit être traité par le centre de gestion
de l'émetteur car il lui permet d'appliquer certaines décisions liées à la sécurité et/ou au
bon fonctionnement du système :
- inscription de la carte en opposition
- gestion de statistiques et suivi du parc distribué, etc...
5.2
09 décembre 2003
Page 10 / 74
GIP "CPS"
Version 5.1
Données de la carte "CPS"
Chaque carte "CPS" est un objet unique avec une identification bien précise et qui est sous la
responsabilité de son porteur, lui même parfaitement identifié.
Ces identifications carte et porteur se retrouvent sur le visuel et dans les données internes de la
carte.
Il existe 5 types de carte "CPS" correspondant à différentes populations de porteurs :
- la CPS : Carte du Professionnel de Santé réglementé,
- la CPF Carte du Professionnel en Formation,
- la CPE Carte du Personnel d'Etablissement.
La CDE (D=Directeur) est une carte CPE destinée aux responsables d'un établissement.
A ce type CPE destiné aux porteurs du Secteur Santé Social, il faut ajouter les types de cartes
de porteurs autorisés bien que n'appartenant pas à un établissement de soin :
- la CPA : Carte du Personnel Autorisé (GIP "CPS", CPAM, gestion réseau RSS, etc...).
5.2.1 Le visuel de la carte "CPS"
Les cartes CPS, CPF et CPE ont des logos (images) de couleurs différentes suivant le type de carte.
•
Les CPS ont 2 bandeaux d'une couleur associée à leur profession.
•
Les CPF ont 1 bandeau d'une couleur associée à leur future profession.
•
Les autres cartes n'ont pas de bandeau.
Les informations lisibles sur les logos de toutes les cartes sont :
[Raison sociale de la structure (CPE)]
[<Raison sociale>]
cp
Identification de l'émetteur (GIP "CPS")
Identification du porteur
Identité du porteur
Identification de la carte
[Identifiant structure], date d'expiration
80 250 00001 7
{A,D,F,S} 99...99
<code civilité> <NOM> <Prénom>
9999999999
[{A,F,S} 99...99]
expire fin MM/AAAA
L'identification {A,D,F,S} 99...99 du porteur est différente suivant le type de carte
- la CPS A 99999999L
ADELI
- la CPF D 9999999999L
DRASS
- la CPE A 99999999L99/99...99
CABINET + N° Registre (16 c max.)
F 99999999L/99...99
FINESS + N° Registre (16 c max.)
S 99999999L/99...99
SIREN + N° Registre (16 c max.)
S 99999999L 9999L/99...99
SIRET + N° Registre (16 c max.)
(99..99 = caractères alphanumériques ; L = clef de contrôle "Luhn")
5.2.2
09 décembre 2003
Page 11 / 74
GIP "CPS"
Version 5.1
Les données internes de la carte "CPS"
5.2.2.1 Structure des données
Les informations inscrites dans la carte "CPS" sont structurées suivant un format "interne" qui
n'apparaît pas au promoteur puisque celui-ci les manipule suivant un format "externe" décrit dans le
manuel de programmation des services "CPS".
La mémoire de la "CPS" est organisée en structure de fichiers, un fichier est référencé par un
identifiant (exemple EF-NOM = 0004).
Chaque fichier se compose d'un en-tête et d'un corps qui contient les données en format TLV.
Il y a plusieurs fichiers dans la "CPS" : chacun est "spécialisé" en fonction des droits d'accès
aux données qu'il contient.
5.2.2.2 Protection d'accès aux données
On peut classer les données de la "CPS" suivant 3 types:
• les données secrètes qui ne ressortent jamais de la carte, comme la valeur du code porteur et les
clés secrètes de calculs de signature, d'authentification…
En plus des clés asymétriques RSA, la "CPS" possède des clés symétriques de gestion qui sont
utilisées (algorithme A3S ou 3DES) pour les opérations de gestion de la "CPS" (mise à jour
sécurisée de données et authentification carte-à-carte).
• les données confidentielles dont la lecture est protégée par la présentation du code porteur.
La lecture de ces données n'est autorisée par la carte que si le code a été présenté avant avec
succès. Dès que la carte est remise sous tension, il faut représenter ce code.
Ces données sont les Situations d'Exercice et de Facturation du porteur.
• les données publiques à lecture libre.
Ce sont toutes les données d'identification de la carte et de son porteur ainsi que les clés
publiques et données de certification de ces clés publiques.
Le promoteur ne dispose d'aucun moyen d'écriture dans la "CPS".
La "CPS" a été conçue pour répondre aux besoins de l'ensemble des promoteurs d'application
qui y trouveront, au travers des services, tous les renseignements nécessaires.
5.2.2.3
09 décembre 2003
Page 12 / 74
GIP "CPS"
Version 5.1
Les données applicatives
La "CPS" est présentée comme le "passeport" du Professionnel de Santé" : elle contient toutes les
informations caractéristiques d'un acteur du Secteur Santé.
Comme le douanier qui consulte le passeport d'un touriste à la recherche de son identité et du
visa d'entrée dans le pays...
L'application recherchera dans la "CPS" - outre les données d'identification du porteur - la
présence des caractéristiques ou qualités requises pour l'exécution du traitement applicatif
(exemple : recherche de la Situation d'Exercice du porteur dans l'établissement).
Les applications peuvent, par appels des services, récupérer les informations contenues dans la carte
"CPS".
Ces informations sont renvoyées vers l'application sous forme explicite (par exemple, le nom
du porteur) ou sous forme codifiée correspondant à des tables de codification.
Le GIP "CPS" met à disposition des promoteurs un dictionnaire logiciel d'interprétation pour
leur permettre d'afficher "en clair" ces informations codifiées vers l'opérateur mais
l'application doit connaître et exploiter directement ces codes.
5.3
09 décembre 2003
Page 13 / 74
GIP "CPS"
Version 5.1
Notions sur l'algorithme RSA à clé publique de la CPS
Toutes les "CPS" sont capables d'effectuer des fonctions cryptographiques.
Certaines de ces fonctions sont réservées à la gestion interne de la carte CPS ou à la communication
entre la CPS et d'autres cartes (modules de sécurité ou cartes de patients) et ne sont pas développées
dans ce document.
Ces fonctions sont utilisées durant la personnalisation des CPS et leur actualisation.
Les fonctions cryptographiques mises en jeu par les applications sont l'authentification de la carte par
le monde extérieur et la signature électronique de messages.
Ces fonctions utilisent l'algorithme asymétrique RSA.
Le RSA est un algorithme public qui utilise deux données particulières appelées bi-clés ou couple de
clés : la clé secrète (dite aussi clé privée) Ks et la clé publique Kp :
- la clé Ks est protégée (elle est dans la "CPS" et est utilisée par celle-ci dans les calculs internes),
- la clé Kp est accessible par le monde extérieur et est utilisée pour les vérifications (par les services).
Principe de l'algorithme RSA : il est possible de trouver 3 nombres S, P et M tels que :
Quelque soit a < M, si b = aS Modulo(M) alors a = bP Modulo(M)
Si S et M sont très grands (nombres sur plusieurs centaines de bits), retrouver b et S en
connaissant a et P demande une puissance de calcul colossale !
Le couple de clés généré est Ks = (S,M) et Kp = (P,M).
Dans une "CPS", il y a des couples de clés Ks et Kp correspondant aux fonctions de signature
électronique et d'authentification de la "CPS".
Il est important de bien comprendre le principe de maniement de ces clés secrètes et publiques :
• Lorsque Monsieur "Seul" calcule avec sa clé secrète Ks, lui seul peut le faire et
Monsieur "Tout-le-monde" peut vérifier en utilisant la clé publique Kp de Monsieur "Seul".
...Cas typique des fonctions de signature et d'authentification...
• Lorsque Monsieur "Tout-le-monde" calcule avec la clé publique Kp de Monsieur "Seul",
Monsieur "Seul" est le seul à pouvoir vérifier avec sa clé secrète Ks.
...Cas typique d'une fonction d'échange de clé de confidentialité...
Les clés publiques Kp sont des données accessibles directement dans la carte, ou par le réseau dans
l'annuaire du GIP "CPS" qui publie les certificats X.509 de ces clés.
5.4
09 décembre 2003
Page 14 / 74
GIP "CPS"
Version 5.1
Certificat X.509 des clés publiques de la CPS
Ce document n'est qu'une introduction à la connaissance des certificats X.509 émis par l'autorité de
certification GIP "CPS" .
En particulier, il ne traite pas de :
•
La Politique de Certification (PC) définissant l’Infrastructure de Gestion de Clés (IGC).
•
La Déclaration des Pratiques de Certification (DPC) énonçant les procédures et pratiques
qu’une autorité de certification utilise dans la gestion des certificats, permettant notamment
de garantir la fiabilité et la sécurité des certificats qu’elle émet.
•
Les règles de vérification de la chaîne de hiérarchie des certificats que doit appliquer
l'application.
La certification de chaque clé publique Kp de chaque carte est une signature RSA calculée par une
autorité (le GIP "CPS") sur un message.
•
Ce message contient les identifications du certificat, de l'autorité, du porteur, de la carte et les
données de la clé publique Kp (règles d'utilisations, dates de validité et valeur de la clé).
•
Le message et sa signature par l'autorité constituent le certificat.
Le calcul de la signature est effectué à l'émission (personnalisation) de la carte par un module
de sécurité qui contient une clé secrète de signature Ks-gip.
La vérification de la signature de ce certificat est effectuée avec la clé publique de signature Kpgip.
La vérification de ce certificat garantit le lien bi-univoque entre Ks, Kp, l'identification de l'autorité,
l'identification du porteur et l'identification de la carte. La vérification d'un certificat consiste en :
1. la vérification de sa signature, suivie de…
2. la vérification que les données signées correspondent à ce que l'on attend.
Cette vérification doit inclure celle de la chaîne de hiérarchie des certificats.
Les certificats des clés Kp de la CPS sont à la norme X.509. Toutes les applications qui intègrent la
sécurité cryptographique et respectent cette norme devraient être capables de s'échanger, vérifier et
exploiter n'importe quel certificat X.509.
09 décembre 2003
Page 15 / 74
GIP "CPS"
Version 5.1
Le certificat X.509, appliqué à la CPS, est structuré ainsi (au format TLV) :
- Les données du certificat signées (certifiées) :
- Version de référence de la norme X.509 (=V3)
- N° de série du certificat
- Identification de l’algorithme utilisé pour la signature de ce certificat
- Identification de l’émetteur du certificat (GIP "CPS")
- Période de validité du certificat
- Identifications du «sujet» (le porteur)
- Valeur de la clé publique du «sujet»
- Extensions standard, dont :
- Identification de la clé publique de vérification du certificat
- Usage de la clé certifiée (signature, authentification, chiffre)
- Période de droit d'usage de la clé certifiée
- Extensions privées :
- Caractéristiques du PS (code et situation professionnelle...)
- Caractéristiques de la carte (numéro et type...)
- Identification de l’algorithme utilisé pour la signature de ce certificat
- Valeur de signature de ce certificat
La vérification de la signature de ce certificat suppose donc de connaître la valeur de la clé publique
de signature Kp-gip clé correspondant à la clé secrète Ks-gip qui a signé ce certificat.
Cette clé est elle-même certifiée, il faut donc vérifier son certificat, et ainsi de suite jusqu'à
remonter au certificat racine auto-signé de l'autorité de certification : c'est la vérification de la
chaîne de hiérarchie des certificats.
5.5
09 décembre 2003
Page 16 / 74
GIP "CPS"
Version 5.1
La CPS et la confidentialité
Les algorithmes cryptographiques permettent d'assurer la confidentialité.
Exemple avec un algorithme asymétrique type RSA :
Monsieur "Tout-le-monde" chiffre un message avec la clé publique Kp de Monsieur "Seul"
Monsieur "Seul" est donc le seul à pouvoir déchiffrer ces messages avec sa clé secrète Ks.
Exemple avec un algorithme symétrique type DES :
Messieurs "Moi" et "Toi" chiffrent et déchiffrent les messages avec une clé secrète C dont ils
se partagent exclusivement la connaissance.
Généralement, des services de confidentialité mettent en œuvre deux types d'algorithmes :
1. L'algorithme asymétrique (ex : RSA) pour s'échanger confidentiellement une clé de session (CS)
grâce à un couple de clés (Kp-kek et Ks-kek) d'échange de clé de session.
2. L'Algorithme symétrique (ex : DES ou 3DES) pour chiffrer et déchiffrer avec cette clé CS les
messages échangés.
Application aux exemples précédents :
Monsieur "Initiateur" génère une valeur de clé CS (une valeur aléatoire) et la chiffre avec la
clé publique Kp de Monsieur "Destinataire" qui est donc le seul à pouvoir déchiffrer cette
information avec sa clé secrète Ks pour retrouver la valeur CS.
Messieurs "Initiateur" et "Destinataire" chiffrent les messages avec la clé secrète CS.
Les chiffrements et déchiffrements sont effectués par des logiciels performants.
Les cartes CPS pouvaient participer à cette confidentialité en étant les gardiennes de ces clés secrètes
Ks-kek. Ce choix n'a pas été fait.
Une des raisons est que seule la carte était alors capable de déchiffrer le message, ceci pouvait
bloquer sa prise en compte pendant toute une absence (ex : congés) de son porteur. Il fallait
alors trouver un moyen de délégation.
Egalement, les produits du marché imposent que les certificats X.509 de confidentialité
possèdent une adresse e-mail. Ceci entraîne des conséquences lourdes à assumer par une carte,
comme la définition d'un couple Clés (Kp, Ks) et certificats pour chaque adresse e-mail…
La solution adoptée est basée sur des clés de confidentialité "partageable" Ks-kek stockées, chiffrées,
sur le poste de travail (ou sur disquette) avec leur certificat. La CPS n'étant nécessaire que pour le
contrôle d'accès à ces clés.
C'est la solution adoptée par les outils de messagerie sécurisée homologués par le GIP "CPS".
6
09 décembre 2003
Page 17 / 74
GIP "CPS"
Version 5.1
Les services de la carte CPS
6.1 Procédures liées à la CPS
Les promoteurs d'applications mettent en œuvre une ou plusieurs des procédures suivantes :
• Identification et Authentification du Professionnel de Santé en local sur le poste du Professionnel
de Santé.
L'identification consiste à lire et contrôler les données d'identifications du porteur contenues
dans la carte.
L'authentification - avoir la preuve que l'opérateur présent est bien le porteur de cette carte est réalisée par le contrôle du code porteur.
• Authentification de la carte "CPS" du Professionnel de Santé par une Carte Santé, pour vérifier
l'habilitation d'accès à ses données.
Non implémentée.
• Identification et Authentification du Professionnel de Santé et de sa carte à distance par un serveur
d'un gestionnaire d'applications.
L'identification consiste à recevoir et contrôler les données d'identifications du porteur et de sa
carte lues en local dans la carte.
L'authentification (avoir la preuve que la carte est bien une CPS émise par le GIP "CPS" et
que l'opérateur présent est bien le porteur de cette carte) est réalisée par une procédure
d'authentification (échange de "défi" et "réponse") qui met en jeu l'algorithme asymétrique
RSA.
• Signature de documents électroniques par un Professionnel de Santé en local sur son poste et
vérification d'une Signature par un Professionnel de Santé en local sur son poste ou par un serveur
d'un gestionnaire d'applications.
L'intégrité du message (avoir l'assurance que le message n'a pas été altéré) et la garantie de
non répudiation (être certain de l'identité du signataire de ce message) sont réalisés par la
procédure de signature qui met en jeu l'algorithme asymétrique RSA.
• Confidentialité entre Professionnels de Santé.
La confidentialité de tout ou partie d'un message échangé entre 2 Professionnels de Santé est
assurée par des fonctions de chiffrement / déchiffrement de messages et fichiers.
Certaines de ces procédures sont réalisées par l'enchaînement de services décrits dans ce chapitre.
Chaque service enchaîne des appels à des mécanismes élémentaires du lecteur (commandes au
lecteur) et de la carte (instructions carte).
6.2
09 décembre 2003
Page 18 / 74
GIP "CPS"
Version 5.1
Les services de lectures des données
• Service CPS_InformationsCarte (informations caractéristiques de la carte)
Identifiant de l’émetteur de la carte
Cet identifiant est unique pour toutes les "CPS" et doit être vérifié par l'application :
" 80 250 00001 7 " = Secteur Santé (80), France (250), GIP "CPS" (0001).
Identification logique de la carte
Cet identifiant est différent et unique pour chaque "CPS" et doit être mémorisé par
l'application.
Catégorie de la carte du Secteur Santé-Social reconnue ("CPS" ou autre, de test ou d'exploitation)
L'application doit contrôler qu'il s'agit bien d'une carte "CPS" et tester s'il s'agit :
- d'une carte d'exploitation ou
- d'une carte de test telle que celles fournies avec le KIT d'intégration.
L'application installée sur une plate-forme d'exploitation doit rejeter les cartes de test.
er
1 jour de validité de la carte
Ce jour correspond à la date de création (personnalisation) de la carte.
Dernier jour de validité de la carte
Une carte est émise pour une certaine durée de validité. La carte n'a aucune notion du temps.
L'application doit tester cette date et rejeter une carte périmée.
La date de fin de validité est actuellement fixée à "3 ans fin de mois" (24 mois à partir de
la date de début, décalée au dernier jour du mois).
• Service CPS_InformationsPorteur (informations caractéristiques du porteur de la carte)
Code civilité
Exemples :
Visuel de la carte
Mme
Mlle
M.
Dr
Valeur dans la carte 22
23
31
13
Libellé (dictionnaire) Madame
Mademoiselle
Monsieur
Docteur
Nom Patronymique
De 2 à 27 caractères.
Nom Marital
De 2 à 27 caractères. Facultatif, non géré actuellement.
Prénoms (1 obligatoirement et 2 autres facultativement)
De 2 à 27 caractères.
Prénom usuel
De 2 à 27 caractères. C'est ce prénom qui figure sur le visuel de la carte
Langues utilisées
De 1 à 4 valeurs maximum et par ordre de préférence, ce code peut être exploité par une
application multilingue.
09 décembre 2003
Page 19 / 74
GIP "CPS"
Version 5.1
• Service CPS_InformationsPS2 (informations et caractéristiques professionnelles du porteur)
Type de Carte "CPS" : CPS, CPF, CPE, ou CPA
L'application, ayant reconnu que la carte est une "CPS" (Catégorie de la carte) émise par le
GIP "CPS", mémorise le type de carte : CPS, CPF, CPE, ou CPA
Modèle de Carte "CPS" : carte de remplacement (CPS-R), carte de structure (CPS-C, CPF-C, CPE)
Une carte de remplacement est une carte demandée par un PS en situation libérale qui désire
se faire remplacer (par exemple, durant ses congés).
L'identification du remplaçant sera inscrite dans une Situation d'Exercice par télé mise à
jour sous contrôle du PS et d'un serveur du GIP "CPS".
Une carte de structure est une carte demandée par un établissement pour être utilisée par son
porteur exclusivement dans cette structure.
Cette carte peut être une CPS, une CPF ou une CPE (cas des employés d'un hôpital d'un
laboratoire, d'une officine, d'un cabinet, etc....)
L'identification de la structure est inscrite dans une Situation d'Exercice unique dés la
création (personnalisation) de la carte
Identification nationale du PS (en fait du porteur de la carte)
Cette identification est codifiée (à l'image du visuel de la carte) :
Un entête (1er caractère) précisant le type d'identifiant utilisé (ADELI, DRASS, SIREN,
SIRET...) et codifiée suivant une table GIP "CPS".
La valeur de cet identifiant est structurée en fonction de cet entête.
Code profession
Cette information pour une CPS et une CPF est codifiée suivant une table GIP "CPS".
Code métier
Cette information pour une CPE n'est pas renseignée à ce jour.
Nom d'exercice
2 à 27 caractères. C'est ce nom qui figure sur le visuel de la carte
Spécialité de qualification
Cette information pour une CPS est codifiée suivant une table GIP "CPS".
Une à deux orientations particulières (ex disciplines particulières)
Cette information pour une CPS (médecin) est codifiée suivant une table GIP "CPS".
Spécialisation (ex discipline de spécialisation)
Cette information pour une CPS (sage-femme et d'auxiliaire médical) est codifiée suivant une
table GIP "CPS".
Situation professionnelle
Cette information pour une CPS d'un PS n'exerçant plus est codifiée suivant une table GIP
"CPS".
Une à trois attribution(s) complémentaire(s)
Cette information pour une CPS (médecin et chirurgien-dentiste) est codifiée suivant une table
GIP "CPS".
Une à deux nature de qualification
Cette information pour une CPS (médecin, pharmacien et chirurgien-dentiste) est codifiée
suivant une table GIP "CPS".
Un à deux doublets : compétence et nature de compétence
Cette information pour une CPS (médecin, pharmacien et chirurgien-dentiste) est codifiée
suivant une table GIP "CPS".
09 décembre 2003
Page 20 / 74
GIP "CPS"
Version 5.1
• Service CPS_LecSituationPS (informations caractéristiques des situations d'exercices)
Lecture (une à une) des situations d'exercices (accès par numéro physique)
L'exécution de ce service nécessite que le code porteur ait été présenté à la carte "CPS".
Les cartes de modèle C (de structure : CPS-C, CPF-C et CPE) ont obligatoirement une
situation d'exercice décrivant la structure associée.
Une carte de remplacement (CPS-R) à une ou plusieurs situations complétées par l'identifiant
du remplaçant.
Une carte CPF d'un PF qui effectue des remplacements d'un PS à obligatoirement une
situation d'exercice complétée par l'identifiant du remplacé.
Une carte CPS d'un PS qui exerce dans des structures publiques possède des situations
d'exercices décrivant son mode d'activité et éventuellement, sa spécialité dans ces structures.
Une carte CPS d'un PS travaillant dans un cabinet possède une situation d'exercice décrivant
ce cabinet.
Il peut donc exister plusieurs situations d'exercices dans une "CPS". Physiquement,
chacune correspond à un fichier dans la carte.
Chaque fichier (au maximum 15, le nombre réel est donné par le service
CPS_DirSituationPS) est référencé par 2 numéros :
- un numéro logique qui sera utilisé dans les situations de facturation,
- un numéro physique d'accès rendu par CPS_DirSituationPS.
Mode d'exercice
Cette information pour une CPS, CPF ou une CPE est codifiée suivant une table GIP "CPS".
CPS : libéral ou salarié ou remplaçant.
CPF : salarié ou remplaçant.
CPE : libéral (exemple : directeur de laboratoire).
Statut
Cette information est codifiée suivant une table GIP "CPS".
Spécialité d'exercice
Nature de qualification
Identification de la structure
Cette identification est codifiée comme celle des porteurs :
Un entête (1er caractère) précise le type d'identifiant utilisé (CABINET, FINESS, SIREN,
SIRET)
Structure : secteur d'activité
Structure : forme juridique
Structure : raison sociale
2 à 27 caractères.
09 décembre 2003
Page 21 / 74
GIP "CPS"
Version 5.1
Tableau des Pharmaciens
Inscription au Tableau du Pharmacien (voir le Code Profession du PS).
Numéro Logique de la Situation
Cette information sera utilisée en liaison avec les situations de facturations.
Identification nationale du PS {remplaçant , remplacé}
Identification du remplaçant pour une CPS-R.
Identification du remplacé pour une CPF d'un PF ou une CPS d'un PS qui effectue un
remplacement.
Cette identification est codifiée :
Un entête (1er caractère) précisant le type d'identifiant utilisé (ADELI, DRASS, etc...) et
codifiée suivant une table GIP "CPS".
DateDebSit
Premier jour de validité de cette situation (à contrôler par l'application).
DateFinSit
Dernier jour de validité de cette situation (à contrôler par l'application).
09 décembre 2003
Page 22 / 74
GIP "CPS"
Version 5.1
• Service CPS_DirSituationPS
Retourne la liste des différentes situations d'exercices existantes dans la carte.
Références (numéros physiques) des situations d'exercices à utiliser pour leur lecture par le
service CPS_LecSituationPS.
• Service CPS_LecSitFacturation (informations des données liées à la facturation des FSE)
Numéro Logique de la Situation
Référence (numéro logique) de la situation d'exercice associée à cette situation de facturation.
Identifiant à utiliser pour la facturation : type d'identifiant - [Identifiant Assurance Maladie]
Suivant le type d'identifiant précisé, prendre pour la facturation :
- soit l'identifiant national du PS lu par CPS_InformationsPS2
- soit l'identifiant de la structure lu par CPS_LecSituationPS
- soit l'identifiant Assurance Maladie qui suit le type.
Informations conventionnelles
Conventionné ou non, avec dépassement ou avec honoraire libre.
Agréments
Pas d'agrément ou code agrément {A,B,C,D,E,F,K,L,M}.
Autorisations de signature des feuilles de soins
Autorisation {oui, non} à signer les FSE et(ou) les lots
• Service CPS_LectureX509
Certificat X.509
La CPS contient 2 certificats X.509 correspondants aux 2 clés RSA
Le certificat est renvoyé sous forme d'une chaîne d'octets binaire pouvant atteindre 2 K octets !
09 décembre 2003
Page 23 / 74
GIP "CPS"
Version 5.1
6.3 Tables de codification des données de la "CPS"
Certaines des données retournées par les services de lectures font références à des tables de
codification.
La référence vers ces tables est donnée dans le manuel de programmation.
Le Promoteur trouvera ces tables dans un service logiciel "CPTAB" fourni dans le KIT avec son
manuel de programmation.
Le principe de CPTAB est de retourner à l'appelant un libellé associé à un code dans une table.
Les tables de codification sont externalisées dans un fichier texte (ISO 8859-1) DICO-FR.GIP.
Ce fichier est directement maintenu par le GIP "CPS". Il est ainsi modifiable et diffusable
indépendamment des portages et livraisons des logiciels.
Ce fichier est disponible sur le site du GIP "CPS".
Il est conjointement utilisé comme référence par toute application, dont le logiciel CPTAB,
l'annuaire du GIP "CPS", etc...
Les libellés retournés par CPTAB sont dans du format de la norme ISO 8859-1. Ils ne sont donc pas
systématiquement affichables car chaque OS peut avoir un jeu de caractères différent.
Pour assurer ce service d'affichage dépendant de l'OS, CPTAB offre une fonction de conversion de
chaîne de caractères d'ISO 8859-1 vers l'OS.
Enfin, CPTAB gère 3 index de recherche (1 code principal et 2 sous-codes) dans ses tables.
Si le fichier DICO-FR.GIP est absent sur le poste de travail, CPTAB fonctionne en mode dégradé : il
retourne des valeurs inscrites dans son codage.
Le fichier DICO-FR.GIP est constitué d'un ensemble séquentiel de tables.
Chaque table contient des enregistrements séquentiels constitués de 6 éléments séquentiels :
1.
2.
3.
4.
5.
6.
Code-Table
Code-1
Code-2
Code-3
Lg-Libelle
Libelle
•
Les nombre de tables, nombres d'enregistrements par table, tailles des éléments d'un
enregistrement sont variables.
Chaque enregistrement est terminé par 0x0D0A.
Chaque élément est constitué d'une chaîne de caractères.
Le caractère 0x09 (tabulation) sert de séparateur entre chaque élément.
•
•
•
Nom de référence de la table
1er index d'accès dans la table
2ième index d'accès dans la table
3ième index d'accès dans la table
Nombre de caractères du libellé
Valeur du libellé correspondant au critère d'accès Code-1 Code-2 Code-3
6.4
09 décembre 2003
Page 24 / 74
GIP "CPS"
Version 5.1
Les services cryptographiques
6.4.1
Services liés à l'authentification de la "CPS"
La procédure d'authentification de la "CPS" est réalisée par l'enchaînement de 3 services dont le
principe est le suivant :
Le poste et la "CPS" qui veulent accéder à
un système d'information
Le système qui veut authentifier la "CPS"
avant d'ouvrir l'accès
CPS_GenereDefiAuthen
Défi
Défi
CPS_CalculAuthen2
Réponse au défi
Réponse au défi
Défi
Kp-aut (certificat X509)
CPS_VerifAuthen2
Succès ou Echec
Figure 1 : Authentification de la CPS
• CPS_GenereDefiAuthen retourne un défi (valeur binaire aléatoire différente à chaque appel)
Cette valeur est transmise à l'application du poste qui gère la "CPS".
• CPS_CalculAuthen2 fait calculer par la carte la réponse à ce défi.
La réponse (calcul cryptographique effectué avec la clé Ks-aut secrète d'authentification) est :
- différente pour chaque valeur du défi,
- différente pour chaque carte.
La réponse est transmise au système qui va la vérifier en temps réel avant d'autoriser l'accès.
• CPS_VerifAuthen2 vérifie la réponse à ce défi.
Le défi, la réponse et la clé Kp-aut (clé publique d'authentification) sont vérifiés par ce service
qui retourne un "diagnostic" VRAI ou FAUX
Cette clé Kp-aut (son certificat X.509) a été lue dans la carte et transmise depuis le poste
ou recherchée par le système dans l'annuaire du GIP "CPS"
6.4.2
09 décembre 2003
Page 25 / 74
GIP "CPS"
Version 5.1
Services liés à la signature électronique
La procédure de signature par la "CPS" est réalisée par l'enchaînement de 3 services dont le principe
est le suivant :
L'émetteur et la "CPS" qui signent
Le destinataire qui veut vérifier la signature
[Algorithme à utiliser]
Message
CPS_CondenseMessage
Condensât de l'émetteur
Algorithme utilisé
Condensât de l'émetteur
CPS_CalculSign2
Signature
Algorithme à utiliser
Message
CPS_CondenseMessage
Condensât du destinataire
Condensât du destinataire
Signature
Kp-sgn (certificat X509)
CPS_VerifSign2
Succès ou Echec
Figure 2 : Signature électronique
• CPS_CondenseMessage effectue en local (pas d'accès carte) une empreinte du message à signer.
Le condensât résultat n'est pas une compression, il y a perte d'information. La performance de
l'algorithme de condensation assure que 2 messages cohérents différents ne donneront pas le
même condensât résultat.
Le service retourne à l'application le type d'algorithme de condensât qu'il a utilisé.
Il existe 1 autre service : CPS_CondenseFichier qui effectue ce même calcul de condensât sur
un fichier.
09 décembre 2003
Page 26 / 74
GIP "CPS"
Version 5.1
• CPS_CalculSign2 fait calculer par la carte la signature sur ce condensât.
La réponse (calcul cryptographique effectué avec la clé Ks-sgn secrète de signature) est :
- différente pour chaque valeur du condensât,
- différente pour chaque carte.
Le message et sa signature ainsi que le type d'algorithme de condensât utilisé sont transmis au
destinataire qui va vérifier (en temps réel ou en temps différé) la signature avant d'accepter et
exploiter le message.
• CPS_CondenseMessage effectue en local (pas d'accès carte) une condensation du message reçu.
Le destinataire effectue le même calcul de condensât supposé que l'émetteur (s'il y a eu
modification du contenu du message le condensât résultat sera différent).
L'application fournit au service le type d'algorithme de condensât a utiliser.
Même chose pour l'algorithme CPS_CondenseFichier.
• CPS_VerifSign2 vérifie la signature sur le condensât calculé.
Le condensât, la signature et la clé Kp-sgn (clé publique de signature) sont vérifiés par ce
service qui retourne un "diagnostic" VRAI ou FAUX
Cette clé Kp-sgn (son certificat X.509) a été lue dans la carte et transmise depuis le poste
ou recherchée par le système dans l'annuaire du GIP "CPS"
6.4.3
09 décembre 2003
Page 27 / 74
GIP "CPS"
Version 5.1
Services de gestion des certificats X.509 des clés RSA
La procédure de contrôle des certificats de chaque clé publique Kp d'une carte "CPS" est réalisée par
l'application avant d'effectuer la vérification de la fonction associée à cette clé Kp.
Ceci suppose que le GIP "CPS" ait initialisé ce contrôle durant la personnalisation des "CPS" :
L'émetteur GIP "CPS" de la "CPS"
Commentaires :
Pour chaque carte "CPS"
Génération des couples de clés Ks, Kp
Générateur RSA
Pour chaque couple :
Construction du Certificat X.509
Signature du Certificat X.509
Le GIP "CPS" est l'autorité de certification
Signature RSA avec la clé Ks-gip
Ecriture dans "CPS" :
- Ks
- Certificat X.509
(contient la clé Kp)
Gardée secrète dans la "CPS"
Voir le service CPS_LectureX509
Couple suivant
Sauvegarde dans Annuaire :
- Identifiant de la "CPS"
- Certificats X.509
Carte suivante
09 décembre 2003
Page 28 / 74
GIP "CPS"
Version 5.1
Le contrôle du certificat X.509 d'une clé Kp par l'application s'effectue en 3 temps :
1.
L'application récupère le certificat X.509 soit par accès à l'annuaire du GIP "CPS" soit par
demande au poste distant qui gère la CPS.
Sur le poste le service CPS_LectureX509 effectue la lecture de ces données.
Le paramètre pValueX509 retourné contient le certificat X.509 sous forme d'une chaîne
d'octets dans laquelle chaque champ (dont la clé Kp publique et la valeur de signature du GIP
"CPS" calculée avec Ks-gip) est présenté sous un format TLV ("Tag", "Length", "Value")
- le "Tag" est l'identifiant du champ,
- la "Value" est la valeur de ce champ sur un nombre d'octets spécifié dans "Length".
2.
L'application effectue le contrôle de la signature de ce certificat par appel du service
CPS_VerificationX509.
Les paramètres pCA_PublicKey_Mod et pCA_PublicKey_Exp contiennent la clé publique de
vérification de la signature. Elle est fournie par l'application (recherchée dans l'annuaire du
GIP "CPS"). Le service retourne un "diagnostic" VRAI ou FAUX. Si FAUX la clé doit être
rejetée.
En fait, il y a 1 autorité "racine" et plusieurs "autorités de certification de classe x" :
Classe 0 = "anonyme" pour les CPE dont les porteurs ne sont pas nominatifs
Classe 1 = les porteurs de CPS et CPF
Classe 2 = les porteurs "mandataires" de CPE et CPA (statut d'exercice = 1)
Classe 3 = les CPE et CPA (statut d'exercice # 1)
Classe 4 = les clés des serveurs applicatifs qui s'enregistrent auprès du GIP "CPS"
Classe 5 = les clés de confidentialité partageable des porteurs de CPS
Ce jeu de classes est aussi dupliqué pour une version de test.
3.
L'application effectue le contrôle des données contenues dans ce certificat.
Le service CPS_InterpretationX509_CPS permet à l'application d'extraire du certificat
pValueX509 chacun des champs de ce certificat pour les contrôler.
Les contrôles dépendent des exigences de l'application. Au minimum, elle doit vérifier si le
certificat est émis par le GIP "CPS" et s'il correspond à une carte réelle ou de test.
6.5
09 décembre 2003
Page 29 / 74
GIP "CPS"
Version 5.1
Services de gestion de la carte
Les services de lecture de données et les services de calculs cryptographiques effectuent des accès
vers la carte "CPS".
Il est donc nécessaire que l'application, avant d'invoquer ces services, sache piloter une carte dans un
lecteur de carte "CPS".
Les lecteurs de carte CPS sont fabriqués et commercialisés par des industriels.
Ces lecteurs doivent être certifiés conformes aux spécifications par l'AFNOR (marque NF
"CPS").
Sous Windows, Mac OS X et Linux, les lecteurs PC / SC peuvent être utilisés. Se renseigner
auprès du GIP "CPS".
Les services de gestion de la carte dans le lecteur sont :
• CPS_TestPresenceCarte permet à l'application de tester la présence d'une carte dans le lecteur et
l'état de cette carte (voir 6.8.3 Paramètre d'état de la carte) et de prendre des décisions en
conséquence.
Ce service est appelé en précisant l'option de savoir si le code porteur est déjà actif ou non : si
le code porteur a déjà été présenté à la carte par une autre application (voir le champ
EtatCarte), il sera inutile de le redemander à l'opérateur et de le représenter à la carte.
Le service renvoie vers l'application
- un code retour pour indiquer si la carte est présente et exploitable par les services CPS.
- la réponse normalisée (ATR) de toute carte à puce à la mise sous tension.
Si la carte n'est pas exploitable directement par les services CPS, l'application pourra
reconnaître dans cette ATR une autre carte (bancaire ?) qu'elle sait traiter...
L'application utilisera ce service dans 3 cas :
1.
Optionnellement avant d'effectuer l'appel du service CPS_IntroductionCarte pour
éventuellement avertir l'opérateur qu'il doit introduire physiquement sa carte dans le lecteur.
2.
Optionnellement avant d'effectuer l'appel du service CPS_RetraitCarte pour éventuellement
avertir l'opérateur qu'il doit retirer physiquement sa carte dans le lecteur.
3.
Régulièrement (à échéance de "timer") ou ponctuellement (avant d'ouvrir un accès) pour
s'assurer que la même carte est toujours présente.
09 décembre 2003
Page 30 / 74
GIP "CPS"
Version 5.1
• CPS_IntroductionCarte permet à l'application de connaître la carte présente et de la mettre sous
tension.
Effectue la mise sous tension de la carte si ce n'est déjà fait (par une autre application) et
renvoie vers l'application les mêmes informations que le service CPS_TestPresenceCarte.
L'application utilisera ce service dans 2 cas :
1.
Une fois avant tout autre appel de services faisant un accès à la carte (sauf l'appel du service
CPS_TestPresenceCarte )
2.
Systématiquement après qu'un service faisant un accès à la carte lui ait indiqué que l'état de la
carte a changé. Dans ce cas, l'application ne sait plus quelle carte est présente et doit appeler
CPS_IntroductionCarte, et relire toutes les données précédemment lues.
• CPS_RetraitCarte est utilisée pour mettre hors tension la carte.
Une application ne doit pas utiliser ce service sauf dans le cas précis où elle veut programmer la
terminaison sur le poste de tout travail avec la carte pour elle-même et pour toute autre
application potentiellement active sur le poste.
Le poste peut être multi applications et ces applications se partager la ressource "CPS". Si une
d'entre elles effectue un retrait de la carte, toutes les autres le détecteront et redemanderont
l'introduction à l'opérateur...
6.6
09 décembre 2003
Page 31 / 74
GIP "CPS"
Version 5.1
Services de gestion des sessions
Une application qui va travailler avec une carte "CPS" dans le lecteur doit d'abord se faire connaître
du système.
• CPS_OuvertureSession est le premier appel programmé par l'application avec :
Le champ NomRessource qui contient le nom du lecteur tel que décrit dans le fichier de
configuration.
Mettre systématiquement "CPS" (3 caractères ASCII) dans le cas des services CPS.
Le champ NomAppli qui contient le nom symbolique de l'application.
Mettre systématiquement un nom représentatif et spécifique de cette application, et y
ajouter éventuellement un index d'occurrence de cette application.
En retour : Le champ NumSession contient une valeur "HANDLE" que l'application doit
systématiquement rappeler pour tous les autres services.
L'ouverture de session permet au système de réserver et initialiser des zones mémoires.
Ces zones (contextes sessions) permettent des échanges d'informations et des contrôles
entre les divers services.
Ce service ne fait pas d'accès vers le lecteur, il vérifie juste que ce lecteur est bien déclaré
dans le fichier de configuration
Une application qui a terminé de travailler avec la carte "CPS" doit le signaler au système.
• CPS_FermetureSession est le dernier appel programmé par l'application.
La fermeture de session libère ou efface des zones mémoires.
Il est inutile et nuisible en performance d'effectuer une fermeture de session si on doit la
rouvrir ensuite.
Une application de type serveur qui n'utilise pas de services à accès à la carte (elle n'utilise que des
services de type vérification) n'utilise pas ces 2 services de gestion de session.
Le champ NumSession, qui est repris systématiquement dans tous les autres services n'est donc
pas significatif pour les services qui ne font pas d'accès vers la carte. Ces services se repèrent
facilement : ils n'ont pas de champ pEtatCarte en paramètre de retour.
6.7
09 décembre 2003
Page 32 / 74
GIP "CPS"
Version 5.1
Services de gestion du code porteur
Le code porteur permet à l'application de s'assurer que l'opérateur est bien le porteur de la carte
présente (authentification du porteur par la carte).
Le code de déblocage est utilisé pour débloquer une carte bloquée par 3 présentations erronées du
code porteur.
Ces valeurs des codes sont demandées par l'application (saisie masquée de caractères
numériques), transmises aux services puis effacées de la mémoire
Les services de gestion du code porteur de la carte sont :
• CPS_PresCodePorteur permet de présenter à la carte le code porteur précédemment demandé à
l'opérateur.
L'application authentifiera le porteur dans 2 cas :
1.
Elle ne veut autoriser un accès (à un fichier, à un service applicatif..) que si elle est certaine de
la présence effective du porteur d'une "CPS".:
Dans ce cas elle effectue ce test si le code n'est pas déjà actif (pour éviter des demandes
répétitives au porteur).
2.
Avant un calcul de signature pour s'assurer de la présence effective du porteur de la "CPS".
Ce contrôle peut n'être effectué qu'une fois avant un calcul non interruptible de signature(s) sur
un lot de documents (non interruptible signifiant que l'on ne peut intervenir sur le processus de
calcul mais que l'on peut l'abandonner).
Le code porteur est constitué de 4 caractères numériques ASCII.
Le code porteur de toutes les cartes de tests est "1234"
L'application peut connaître, avant de demander la saisie du code à l'opérateur, le nombre
d'essais de présentations encore permis en exploitant le champ EtatCarte : 3, 2 ou 1.
Lorsque cette valeur est 0, la carte est bloquée et l'application pourra proposer à l'opérateur
de recycler son code (débloquer la carte).
• CPS_ModifCodePorteur permet de modifier la valeur du code porteur.
Cette modification s'effectue en demandant 3 saisies à l'opérateur :
- l'ancien code porteur (4 caractères numériques ASCII),
- le nouveau code porteur (4 caractères numériques ASCII) à appliquer,
- la confirmation du nouveau code porteur (double saisie)
L'application n'est pas obligée d'intégrer ce service. Les règles de gestion du nombre d'essais
de changements sont les mêmes que celles de la présentation.
Pour la carte, la modification consiste en :
- présentation du code et
- si le code est correct, changement de la valeur.
09 décembre 2003
Page 33 / 74
GIP "CPS"
Version 5.1
• CPS_RecycleCodePorteur permet de recycler une "CPS" bloquée à la suite de la 3ième
présentation erronée du code porteur par CPS_PresCodePorteur ou CPS_ModifCodePorteur.
Pour effectuer ce recyclage, l'opérateur doit connaître son code de recyclage (appelé aussi code de
déblocage ou super code).
Le code de recyclage est constitué de 8 caractères numériques ASCII.
Le code de recyclage de toutes les cartes de tests est "12345678"
L'application peut connaître, en exploitant le champ EtatCarte si la carte est bloquée et si elle
peut être débloquée.
Dans ce cas, elle peut proposer à l'opérateur de la recycler par 3 saisies :
- le code de recyclage (8 caractères numériques ASCII),
- le code porteur (4 caractères numériques ASCII) à appliquer,
- la confirmation du code porteur (double saisie)
l'opérateur n'est pas obligé de se rappeler la valeur du code porteur avant blocage et peut
fournir une nouvelle valeur.
Pour la carte, le recyclage consiste en :
- présentation du code de recyclage et
- si le code est correct, changement de la valeur du code porteur (la valeur présentée
remplace l'ancienne).
L'application n'est pas obligée d'intégrer ce service.
6.8
09 décembre 2003
Page 34 / 74
GIP "CPS"
Version 5.1
Intégration des services
Pour intégrer les services de la "CPS" dans son application le promoteur définit les phases de son
projet :
Analyse des besoins
Cette phase d'analyse des besoins sort du cadre de ce document...
Etude des solutions
• Quelle est l'architecture du système existant ?
Les intervenants (opérateurs, applications, plates-formes et environnements).
Les communications (protocoles de connexion et d'échange, volumétrie).
• Quelles sont les procédures à mettre en oeuvre ?
Identification(s), Authentification(s), Signature…
• Quel sera l'impact sur l'existant (faisabilité) ?
Ergonomie du poste et de l'application :
La vision par l'opérateur,
Les performances.
Intégration des nouvelles données liées à la carte :
Modification(s) de l'architecture de l'application,
Modification(s) des protocoles entre applications.
Spécification
C'est durant cette phase que le promoteur qui aura identifié les procédures à mettre en œuvre et
qui possède la "boîte à outils" des services (KIT d'intégration) aura besoin de connaître :
• La fonctionnalité de chaque service.
• La logique d'enchaînements de ces services.
• La logique d'exploitation des informations retournées par les services.
Développement
Pour la programmation des services dans l'application, le promoteur se reportera au manuel de
programmation correspondant à son environnement.
Pour les tests, le promoteur utilisera le jeu de cartes de tests fourni dans le KIT (ou de cartes
spécifiques commandées au GIP "CPS").
Qualification
Cette phase sort du cadre de ce document...
Exploitation
Remarque : avant d'être mise en exploitation, l'application devra avoir reçu l'accord du Collège
de Déontologie.
Cette phase sort du cadre de ce document...
6.8.1
09 décembre 2003
Page 35 / 74
GIP "CPS"
Version 5.1
Structure interne des services
L'architecture logique d'une station de travail dans le secteur Santé-Social respecte la structure en
couches logicielles suivante :
APPLICATION
APPLICATION
APPLICATION
API des SERVICES CPS
autres :
API des SERVICES A-M
API de Lectures (Hospitaliers)
GESTIONNAIRE D'ACCES AUX LECTEURS (GALSS)
PROTOCOLE(S) de COMMUNICATION (ex : PSS)
Figure 3 : Architecture du poste du PS
• APPLI 1 APPLI 2 APPLI 3 APPLI 4
Applications utilisant les services des cartes Santé-Social (CPS, A-M, etc...)
• API des SERVICES Carte Santé-Social (CPS, A-M, etc...)
Interfaces spécifiques à chaque type de Carte Santé-Social
• GESTIONNAIRE D'ACCES AUX LECTEURS
Système de gestion des SESSIONS applicatives, des CONTEXTES des applications, des
EXCLUSIVITES d'accès à des ressources périphériques, des PROTOCOLES.
• PROTOCOLE(S) DE COMMUNICATION
Gestionnaire(s) de PROTOCOLE(S) de communication entre station et matériels.
Les protocoles supportés sont PSS et une passerelle vers PC / SC.
09 décembre 2003
Page 36 / 74
GIP "CPS"
Version 5.1
Les API des Services CPS sont conformes à l'architecture générale suivante :
Interfaces applicatifs d'accès aux services
SERVICES....
Interfaces d'accès vers le GESTIONNAIRE
• Les Interfaces applicatifs d'accès aux services réalisent :
Contrôles sur l'appel.
Activation du service requis.
Génération du Compte-rendu.
• Les SERVICES réalisent :
Traitement du service requis.
• Les Interfaces d'accès vers le Gestionnaire réalisent :
Gestion des ordres au Gestionnaire et de ses réponses.
Les services CPS sont construits suivant l'architecture modulaire suivante :
LOGIQUE des
SERVICES
(Interfaces applicatifs d'accès aux services)
Sous / Programmes Internes Communs...
Algorithmes...
APDU-CPS
COMMANDES Lecteur CPS
(Interfaces d'accès vers le Gestionnaire)
• Les LOGIQUES des SERVICES sont les organigrammes d'enchaînement des modules et d'appels
des modules interfaces.
• Le module Algorithmes contient, par exemple, les fonctions de vérification RSA.
• Le module APDU-CPS contient la bibliothèque des instructions élémentaires des cartes CPS.
• Le module COMMANDES Lecteur contient la bibliothèque des commandes du lecteur CPS.
6.8.2
09 décembre 2003
Page 37 / 74
GIP "CPS"
Version 5.1
Code retour des services
Les Services CPS renvoient un Compte-Rendu d'exécution (CR) dont la liste des valeurs et libellés
est fournie dans le manuel de programmation.
Cette liste n'est pas limitative : il se peut qu'une nouvelle valeur soit un jour introduite avec
une nouvelle version, la programmation de l'application doit s'en protéger.
Cependant certaines de ces valeurs de CR méritent une explication supplémentaire.
• 'FF' = NOK = L'exécution du service s'est déroulée avec succès mais le résultat est incorrect
Cette valeur est retournée en cas de contrôle négatif par les services de vérification de :
- Valeur de code porteur ou de déblocage,
- Valeur de certification d'une clé publique,
- Valeur de signature,
- Valeur de réponse à un défi d'authentification.
Dans ces cas, l'application doit dénier la conformité (la signature, l'accès, etc...)
Cette valeur est aussi retournée par les services de lectures d'informations dans la carte
lorsqu'ils n'arrivent pas à exploiter les données internes de la carte.
Les données sont stockées dans la carte suivant un format interne (codification TLV) et
sont éclatées et expansées par les services vers les champs de l'application.
Dans ce cas, l'application doit prévenir l'opérateur qu'il y a une anomalie dans sa carte.
• '01' = ETAT_CARTE_CHANGE = L'état de la Carte a été changé depuis le dernier accès, faire
une introduction carte.
Cette valeur est retournée par tous les services qui font un accès vers la carte lorsqu'ils
détectent qu'une autre application a modifié l'état de la carte dans le lecteur.
Ce cas peut se produire sur les plates-formes où plusieurs applications gèrent et utilisent
la carte.
Dans ce cas, l'application doit considérer que la carte n'est peut-être plus celle qu'elle
connaissait. Elle est obligée d'appeler le service d'introduction de la carte.
L'application doit effacer toutes les données de la carte qu'elle connaissait, les relire,
refaire les procédures d'authentification, etc..
• '02' = LECTEUR_INEXISTANT = Le lecteur spécifié n'est pas référencé dans le fichier de
configuration.
Ce cas intervient à l'ouverture de session, l'application doit prévenir l'opérateur que le lecteur
qu'elle utilise n'est pas décrit dans son fichier de configuration (GALSS.INI sous Windows) .
Ce cas ne devrait pas intervenir si l'application respecte le standard suivant :
Le nom du lecteur de carte CPS est "CPS" (3 caractères ASCII).
09 décembre 2003
Page 38 / 74
GIP "CPS"
Version 5.1
• '04' = SESSION_DEJA_OUVERTE = Une session est déjà ouverte pour ce nom d'application.
Ce cas intervient à l'ouverture de session, il signifie qu'une session est déjà établie avec ce nom
de lecteur sous ce nom d'application
Ce cas pourrait se produire sur les plates-formes où plusieurs applications gèrent et
utilisent la carte, mais correspond plus souvent à un bogue de l'application qui a
"oublié" qu'elle a déjà ouvert une session.
• '05' = NON REPONSE DU LECTEUR = Le lecteur est absent, en panne ou hors tension.
Ce cas intervient aussi lorsque le lecteur est paramétré avec une adresse PSS différente de
celle déclarée dans le fichier de configuration.
L'adresse du lecteur CPS mono-fente est 0.
• '07' = CARTE_HORS_TENSION = Pas de réponse de la carte (carte muette): mal introduite, en
panne...
Le microprocesseur de la carte est un composant électronique qui est alimenté électriquement
par le lecteur.
La mise sous tension est effectuée dans le traitement du service d'introduction de la carte.
Lorsque l'application reçoit ce code retour, le traitement est différent suivant le service appelé.
En retour du service CPS_IntroductionCarte, l'application doit avertir l'opérateur avant de
faire une deuxième tentative (peut-être la carte est-elle introduite à l'envers !)
En retour des autres services d'accès à la carte, l'application doit alerter l'opérateur que sa
carte est en panne.
• '09' = CARTE_INCONNUE = Cette carte ou les données transmises pour les services qui ne font
pas d'accès vers la carte, ne peuvent pas être traitées par les services.
Typiquement, cela se produit en retour du service CPS_IntroductionCarte et
CPS_TestPresenceCarte lorsque l'opérateur introduit une carte autre qu'une CPS ou une
carte CPS d'ancienne génération qui ne devrait plus être en exploitation.
Cela se produit également en retour du service CPS_InterpretationX509-CPS lorsque le
certificat présenté ne provient pas d'une CPS.
• '0C' = SERVICE_IMPOSSIBLE = La carte ou les données transmises pour les services qui ne font
pas d'accès vers la carte, ne sont pas prévues pour ce service (clé absente, fonctionnalité interdite
ou non prévue, fichier absent...).
En retour du service CPS_LecSituationsPS, ce code signifie que le fichier recherché n'existe
pas. Ce cas ne devrait pas se produire si l'application a bien récupéré la liste des situations
par le service CPS_DirSituationsPS.
09 décembre 2003
Page 39 / 74
GIP "CPS"
Version 5.1
• '0D' = LECTEUR_OCCUPE = La ressource lecteur est occupée par une autre application, le
service est momentanément impossible.
Ce code retour des services d'accès au lecteur ou à la carte signifie qu'une autre application
utilise le lecteur.
Les services gèrent, en interne, une boucle d'attente et de reprises pendant environ 5
secondes, ce cas ne devrait pas apparaître en fonctionnement normal.
Il est conseillé à l'application d'avertir l'opérateur de la surcharge du lecteur et de le laisser
décider s'il veut réessayer ou abandonner.
Cependant, une application qui fait de la surveillance de présence carte (contrôle d'accès au
poste) dans un contexte d'applications intégrées doit être alertée car ce peut être une attaque
programmée contre le système.
• '10' = ERREUR_LOGICIELLE = Les API ont détecté une erreur interne (bogue).
Hélas, ce code retour indique une erreur de développement des services !
La conduite du promoteur est différente suivant la phase de son projet d'intégration :
En phase de développement, il est invité à utiliser la procédure de traitement des anomalies
définie dans le chapitre "Suivi et rapports d'anomalies".
En phase d'exploitation des services, l'opérateur suivra la procédure de traitement des
anomalies définie par le promoteur !
Il est demandé au promoteur d'intégrer dans cette procédure la remontée vers le GIP
"CPS" des informations contenues dans le champ CPS_StatusService.
• '11 '= CARTE INVALIDEE = La carte CPS est invalidée
Les lectures sont encore possibles, cependant, l'application doit refuser de traiter cette "CPS".
• '12' = FICHIER INVALIDE = Un fichier de la CPS est invalidé
Les lectures sont encore possibles, cependant l'application doit refuser d'exploiter les
informations renvoyées par le service (exemple : lecture d'un fichier de situation d'exercice).
Ce code d'erreur est aussi possible en retour du service CPS_IntroductionCarte et signifie
qu'une actualisation de la carte s'est mal terminée. Dans ce cas, l'application doit refuser de
traiter cette carte "Une actualisation de cette carte s'étant terminée sur un incident, elle risque
d'être incomplète car des données peuvent être absentes"
• '80' = ERREUR CONFIGURATION = l'installation des logiciels est erronée
Une erreur est intervenue dès le chargement des logiciels API, GALSS et Protocoles PSS ou
PC / SC rendant tout travail impossible. Il faut revoir la procédure d'installation et
particulièrement le fichier de configuration GALSS.INI
Dans le cas d'utilisation de PC / SC, ce statue peut indiquer que l'installation de cette
architecture (driver du lecteur) est mal effectuée.
6.8.3
09 décembre 2003
Page 40 / 74
GIP "CPS"
Version 5.1
Paramètre d'état de la carte
Tous les services qui font accès à la carte retournent un champ EtatCarte qui décrit l'état de la carte :
La carte est présente ou absente du lecteur ?
La carte présente est hors ou sous tension ?
La carte présente sous tension est-elle bloquée ?
La carte présente sous tension bloquée est-elle recyclable ?
La carte présente sous tension est-elle invalidée ?
La carte présente sous tension a-t-elle son code porteur actif ?
L'exploitation de ce champ par l'application n'est pas obligatoire dans la mesure ou le traitement du
code retour CR de chaque service lui suffit. Elle permet cependant d'optimiser le traitement :
A combien de tentatives de saisie du code porteur l'opérateur a-t-il le droit ?
A combien de tentatives de saisie du code de recyclage l'opérateur a-t-il le droit ?
6.8.4
Paramètres d'état d'exécutiond'un service
En complément de tous les champs nécessaires aux traitements, les services retournent une structure
d'informations CPS_StatusService. L'application peut ne pas exploiter directement ces données mais
elle doit être capable de les restituer en cas d'anomalies car elles constituent une aide à la
maintenance des services (voir le chapitre "10.4 Suivi et rapports d'anomalies")
Cette structure contient :
• NumVersionAPI
• NumVersionAPI
• NumAPI
• StatusAPI
• StatusGestionnaire
• StatusInterne
• StatusLecteur
• StatusCarteStatus
6.8.5
numéro de version des API
numéro de version du service
numéro du service API
diagnostic précis de l'API
résultat d’exécution des fonctions du Gestionnaire GALSS
étape interne du service (référence dans son code source)
Code retour lecteur d'exécution d'une commande
code retour Carte ME1-ME2 d'une APDU (ISO-7816)
Performances des services
Les accès aux cartes à microprocesseur sont relativement lents.
Les Services CPS enchaînent souvent plusieurs accès vers la "CPS".
Un service = plusieurs instructions cartes traitées par des commandes lecteur et expédiées au
lecteur par le protocole.
En conséquence, les temps d'exécutions des Services CPS sont significatifs et doivent être pris en
compte pendant les analyses et développements de l'application.
Voir les exemples de performances en "11.3 Performances des Services CPS"
6.8.6
09 décembre 2003
Page 41 / 74
GIP "CPS"
Version 5.1
Recherche d'une solution d'intégration
Il existe différentes méthodes d'intégration qui vont dépendre des fonctionnalités à implémenter et
de l'architecture du produit à réaliser. Mais le promoteur doit connaître les concepts suivants :
1. La CPS est mono-applicative et ne sait traiter plusieurs transactions simultanées, mais les
services API résolvent cette contrainte.
Exemple sur une transaction de lecture qui nécessite 3 instructions (ou APDU) :
1) se positionner sur un fichier, 2) donner la taille du fichier, 3) lire les données.
Si plusieurs applications exécutent sans précaution cette transaction sur des fichiers différents,
les résultats seraient erronés.
Les services API savent gérer cette situation par :
• Sérialisation des appels des applications : prise d'exclusivité de l'accès à la carte pour
toute la transaction, accès à la carte et libération de l'exclusivité.
Une application peut récupérer le code retour CR ='0D' = LECTEUR_OCCUPE
lorsque les API ont bouclé 5 fois (sur timer variable de 1 à 2 secondes) sur la prise
d'exclusivité.
• Mémorisation d'un contexte par session qui décrit l'état et l'avancement d'une
transaction pour cette session.
2. Les services API sont réentrants entre tâches (ou process) puisqu'ils travaillent sur des données
locales créées dans la pile de l'appelant et des données contextuelles par session.
Remarques importantes :
•
2 tâches ne doivent pas travailler simultanément sur une même session, par contre, elles peuvent
se partager cette session si elles savent se synchroniser.
•
Il ne faut pas espérer améliorer les performances en multipliant les tâches qui accèdent à la carte.
•
Sur un serveur où N process gèrent N Clients, les 2 logiques suivantes sont possibles :
1. Les N process accèdent à la carte sur N sessions différentes.
2. Les N process se synchronisent sur un unique process d'accès en session avec la carte.
Cette solution 2 est même préférable dans la mesure où elle permet :
- une gestion de file d'attente personnalisée (à charge du promoteur),
- de gérer plusieurs cartes sur le serveur (un process par carte),
- une gestion simple par ce process de l'arrachage de carte.
•
Lorsqu'un service API ne fait pas d'accès vers la carte, il n'a pas besoin de s'appuyer sur une
session, donc l'application n'a pas à faire d'ouverture de session et peut s'appuyer sur la réentrance
naturelle des API (pas de nécessité de synchronisation entre tâches).
7
09 décembre 2003
Page 42 / 74
GIP "CPS"
Version 5.1
Logiques d'enchaînement des services "CPS"
7.1 Définition des types des applications
7.1.1
Application "autonome"
Il s'agit d'une application monolithique, ou autonome, ou indépendante sur le poste du PS. Cette
application s'installe, se charge et exploite des données et la carte "CPS" indépendamment d'autres.
Paradoxalement, cette application doit considérer qu'elle ne sera pas forcément "seule" sur le
poste du PS. Elle doit adapter le traitement de la carte en conséquence pour ne pas perturber
les autres (par exemple, ne pas systématiquement mettre la carte hors tension en fin
d'exploitation).
7.1.2
Applications "intégrées"
Il s'agit :
• Soit d'un ensemble d'applications - à la base du type autonome - mais dont le promoteur réalise
une intégration.
• Soit d'une application composée de plusieurs tâches (ou process) qui se partagent les services de
la CPS.
Dans ces cas, le promoteur aura la possibilité d'optimiser des traitements dans une unité
dédiée à la "CPS" et chargée de :
- lire 1 seule fois les données de la carte et les stocker en interne à disposition des autres tout
en surveillant la présence de cette carte,
- faire effectuer par la CPS les calculs cryptographiques...
7.1.3
Applications "réparties" (poste et central)
Dans les applications "Client-Serveur" ou les applications fonctionnellement réparties entre le(s)
poste(s) et un central, le promoteur sera amené à répartir en conséquence les services.
Exemple de répartition :
Le central ou serveur est accessible par des postes intelligents en réseau, il engage une
procédure d'authentification de la CPS dans le poste.
Les services de lecture de données et de calcul d'authentification seront sur le poste qui
pilote la "CPS".
Les services de vérification d'authentification seront sur le central.
Remarque :
ce simple exemple n'est pas neutre pour le promoteur si les postes et le central sont
sous 2 systèmes d'exploitation différents ; il doit alors disposer des 2 KITs.
7.2
09 décembre 2003
Page 43 / 74
GIP "CPS"
Version 5.1
Services de gestion de la carte
L'application pourra très simplement réaliser ce type de schéma :
L'opérateur
L'application
Commentaires
Lance l'application
CPS_OuvertureSession
- du lecteur "CPS"
- par l'application = XX...XX
Test du CR = ?
CR = '02'
Message vers l'opérateur :
Votre fichier de configuration GALSS.INI est erroné
(pas de lecteur CPS).
Corrigez la configuration et relancez l'application
Abandon
Lecteur inexistant
CR = '04'
L'application XX...XX existe déjà.
Validez pour abandonner le traitement
Abandon
Session déjà ouverte
BOUCLE:
CPS_IntroductionCarte
Délai = 0
Test du CR = ?
09 décembre 2003
CR = '0D'
Une ou des applications monopolisent le lecteur
Fermez ces applications puis validez
Retour en Boucle
Lecteur occupé
(effectuer une deuxième
tentative avant d'alerter
l'opérateur ?)
CR = '05'
Le lecteur CPS ne répond pas :
(hors tension, en panne)
Vérifiez qu'il est bien connecté et sous tension
puis validez
Retour en Boucle
Non réponse du lecteur
CR = '06'
Le lecteur CPS répond mal (erreur de protocole)
Vérifiez qu'il est bien configuré puis validez
Retour en Boucle
Erreur de transmission
CR = '08'
Carte absente
Page 44 / 74
GIP "CPS"
Version 5.1
Introduisez votre CPS puis validez
Retour en Boucle
CR = '09'
La carte n'est pas une CPS
Introduisez votre CPS puis validez
Retour en Boucle
Carte inconnue
CR = '07'
La carte ne peut être mise sous tension :
- en panne ?
- mal introduite ?
Vérifiez que la carte est bien introduite puis validez
Retour en Boucle
Carte hors tension
CR = '11'
Cette carte est invalidée
Introduisez une carte valide puis validez
Retour en Boucle
Invalidée
CR = '0A'
Votre carte est bloquée par 3 erreurs sur code.
Certaines fonctions seront impossibles
Voulez-vous la débloquer avant de continuer ?
Si réponse opérateur = oui, DEBLOCAGE
Si réponse opérateur = non,, continuer
Carte valide et bloquée
CR <> '00'
Erreur dans l'application XX...XX
Contactez votre Promoteur d'Application
Abandon
A introduit une "CPS"
Ceci est optionnel
Erreurs impossibles !
Constituer le "dossier" ou
"fiche" d'anomalie
Carte valide
ENTREE dans le traitement de l'application...
- SORTIE PROVISOIRE sur anomalie CR
(dont CR = '01' = l'état de la carte a changé)
Retour en Boucle
- SORTIE DEFINITIVE sur décision opérateur
CPS_FermetureSession
7.3
09 décembre 2003
Page 45 / 74
GIP "CPS"
Version 5.1
Services de lecture de données de la carte
Tous ces services sont indépendants, il n'y a donc pas d'ordre obligatoire d'enchaînement. Seuls la
logique, le besoin applicatif et le souci de performance guideront le promoteur.
La règle à respecter pour une application "minimum" est de tester le service
CPS_InformationsCarte
La logique d'enchaînement est la suivante :
Service
Informations retournées
Commentaires
- Emetteur de la carte
- Catégorie de la carte
- Numéro d'identification unique
de la carte
L'application contrôle :
- Carte émise par le GIP "CPS"
- CPS de test ou d'exploitation
- Le numéro sert d'index d'accès
dans une recherche dans les listes
noires ou blanches
La lecture et mémorisation de ce numéro d'identification de la carte (champ IdCarteLog) permet
d'optimiser la performance des traitements applicatifs : tous les autres services de lectures qui suivent
n'ont pas a être reconduits systématiquement si l'application a su stocker dans un environnement
protégé les données retournées par ces services.
Cette possibilité ne doit cependant être utilisée que dans un intervalle de temps limité (comme
une suspension temporaire d'une activité ou session applicative de l'opérateur) !
En effet, les vraies données de la "CPS" (actuellement les situations d'exercice) peuvent être
mises à jour par téléchargement. Dans ce cas, les données stockées par l'application sont
devenues caduques.
CPS_InformationsPorteur
Identité civile du porteur
CPS_InformationsPS2
L'application contrôle en fonction
de ses besoins de contrôles
d'accès à des fonctions ou des
fichiers :
- Type de carte ("CPS" "CPE" ou - cette carte est-elle acceptée ?
"CPF")
- Identification unique du porteur - ce porteur est-il autorisé ?
- cette profession est-elle
- Caractéristiques
autorisée ?
professionnelles du PS
- etc...
CPS_DirSituationPS
- liste des fichiers de situations
La carte peut contenir jusqu'à 8
d'exercices présentes dans la carte situations d'exercice.
- L'application peut décider
d'ouvrir un accès que si une
situation bien précise existe
09 décembre 2003
Ce service n'est pas obligatoire
Page 46 / 74
GIP "CPS"
Version 5.1
(exemple :Le PS travaille dans
l'hôpital BEAULIEU, la
pharmacie CAILLOT)
- L'application peut rechercher la
situation correspondante à la
situation de facturation.
Boucle de...
Dans ces cas, elle va lire
séquentiellement les situations
jusqu'à rencontrer celle qui
l'intéresse
CPS_LecSituationPS
- mode(s) d'exercice
- structure(s) d'exercices
- libéral ? salarié ?...
- bonne identification de la
structure ?
- Numéro logique de situation
Rappel : durant cette boucle de lecture, le service CPS_LecSituationPS peut retourner le code
retour CR = '12' = Fichier invalidée pour indiquer que la situation d'exercice lue est invalidée.
L'application doit ignorer cette situation (ne pas l'exploiter).
...fin de boucle
CPS_LecSitFacturation
- Données de facturation AM
- Numéro logique de situation
Réservé aux applications de FSE
CPS_LectureX509
Certificat X.509 contenant la
valeur de clé publique (Kp-xxx)
Ces informations peuvent être
lues et transmises à l'application
du correspondant éloigné durant
les procédures cryptographiques.
Note : une application qui sait
exploiter un certificat X.509 peut
se satisfaire de cet unique API de
lecture puisqu'elle y trouvera
toutes les informations
caractéristiques de cette CPS et
de son porteur et certifiées
(signées) par l'autorité GIP "CPS"
7.4
09 décembre 2003
Page 47 / 74
GIP "CPS"
Version 5.1
Services d'authentification de la carte
Le schéma d'enchaînement des services est décrit au chapitre 6.4.1 Services liés à l'authentification
de la "CPS" et rappelé ici :
Le poste et la "CPS" qui veulent accéder à
un système d'information
Le système qui veut authentifier la "CPS"
avant d'ouvrir l'accès
La procédure de contrôle du certificat X.509 a été effectuée avec succès
défi
CPS_CalculAuthen2
CPS_GenereDefiAuthen
réponse
CPS_VerifAuthen2
Figure 4 : Services d'authentification
Le service CPS_VerifAuthen2 utilise pour effectuer ce contrôle la clé publique Kp-aut de la "CPS".
Le système aura cette information :
• Soit parce qu'il la recevra directement du poste (CPS_LectureX509), ce qui suppose que les 2
correspondants aient prévu cette information dans leur protocole d'authentification.
• Soit parce qu'il dispose d'une liste locale des "CPS".
La procédure d'authentification ne peut être engagée que si la procédure de contrôle du certificat de
la clé publique Kp-aut a précédemment été effectué avec succès.
09 décembre 2003
Page 48 / 74
GIP "CPS"
Version 5.1
7.5 Services de signature électronique
Le schéma d'enchaînement des services est décrit au chapitre "6.4.2 Services liés à la signature
électronique" et rappelé ici :
L'émetteur et la "CPS" qui signent
Le destinataire qui veut vérifier la signature
La procédure de contrôle du certificat X.509 a été effectuée avec succès
CPS_CondenseMessage
CPS_CalculSign2
message +
signature
CPS_CondenseMessage
CPS_VerifSign2
Figure 5 : Services de signature
Le service CPS_VerifSign2 utilise pour effectuer ce contrôle la clé publique Kp-sgn de la "CPS". Le
système aura cette information :
• Soit parce qu'il la recevra directement du poste (CPS_LectureX509), ce qui suppose que les 2
correspondants aient prévu cette information dans leur protocole d'authentification.
• Soit parce qu'il dispose d'une liste locale des "CPS".
La procédure de signature ne peut être engagée que si la procédure de contrôle du certificat de la clé
publique Kp-sgn a précédemment été effectué avec succès.
09 décembre 2003
Page 49 / 74
GIP "CPS"
Version 5.1
7.6 Services de contrôles de certificat X.509
Le contrôle de certification doit être effectué pour chacune des clés publiques d'une "CPS" :
Kp-aut et Kp-sgn.
Le schéma d'enchaînement des services est :
La "CPS"
Le destinataire qui veut contrôler
CPS_LectureX509
CPS_VerificationX509
CPS_InterpretationX509-CPS
Contrôles de conformité des données
certifiées en fonction de l'attente
Figure 6 : Services de contrôle de certification
8
09 décembre 2003
Page 50 / 74
GIP "CPS"
Version 5.1
Règles d'installation des logiciels des services "CPS"
Ici ne sont présentés qu'un exposé de ces règles et de la logique qui a amené à les éditer.
Règle 1 :
Pour chaque composant à installer, il est nécessaire de respecter sa compatibilité avec
les autres composants.
Deux composants existent sous une application "CPS" : le composant CPS et le
composant GALSS-PSS.
Cette règle ne s'applique que pour le composant GALSS-PSS car le composant CPS
est compatible avec tous les autres composants.
Elle devient pour le promoteur qui installe son application "CPS" :
Ne pas réinstaller le composant GALSS-PSS s'il est déjà présent sur le poste de travail
et qu'il subsiste un doute sur l'existence sur ce poste d'autres application de type FSE.
Règle 2 :
Un fichier ne doit pas être remplacé par un fichier de version inférieure.
Cette règle est classique. Chaque composant est constitué de plusieurs fichiers.
Son corollaire est impératif pour le composant CPS :
C'est le composant CPS de dernière version qui doit toujours être installé.
Règle 3 :
Un composant incomplet ou incohérent doit être réinstallé.
Incomplet ou incohérent (versions de fichiers incohérentes), le composant ne
fonctionne pas et il doit donc être réinstallé.
Un composant est incohérent lorsque les fichiers qui le composent ne sont pas de la
même Version. (VV.xx, quelque soit xx)
Règle 4 :
Avant toute installation, il est nécessaire de décharger les applications en mémoire.
Cette règle est classique. Penser en particulier à tuer les process GALSS (exemple
Windows : GALSVW32).
Règle 5 :
Vérifier les autorisations d'accès aux répertoires d'installation (droits d'administration).
Cette règle est classique.
Règle 6 :
Chaque composant doit être unique et installé dans le répertoire spécifié.
Cette règle est fondamentale pour le bon fonctionnement du poste et sa mise à jour
dans un contexte multi-applicatif.
Les répertoires d'installation sont spécifiés, pour chaque environnement, dans le
manuel de programmation correspondant (exemple : "WINDIR" en Windows).
9
09 décembre 2003
Page 51 / 74
GIP "CPS"
Version 5.1
Annuaire du GIP "CPS"
Dans le cadre de la mise en place de l'Infrastructure de Gestion de Clés (IGC), l'Annuaire du GIP a
pour objectifs :
•
la publication des certificats X.509 et des listes de révocation de certificats (CRL),
•
la mise à disposition des utilisateurs du Système CPS, de requêtes d'accès aux informations
disponibles sur les porteurs de cartes (recherches selon les principes de "pages blanches" et de
"pages jaunes"),
•
d'offrir des prestations spécifiques, comme par exemple :
- l'aide à la gestion de parcs de cartes pour les structures,
- des requêtes dans le cadre d'alertes sanitaires,
- l'interconnexion de l'Annuaire du GIP avec d'autres annuaires.
Pour répondre aux souhaits des Professionnels de Santé et des Autorités Compétentes dans le
domaine de la Santé et de la CNIL, certaines requêtes nécessitent des autorisations préalables
et seront réservées aux personnes autorisées nommément identifiées suivant les procédures
validées par la CNIL et le CODEON.
Tous les porteurs d'une carte de la famille CPS peuvent accéder à l'annuaire.
L'interrogation de l'annuaire se fait selon 2 modes :
1. interrogation directe par le porteur d'une carte qui se connecte sur le serveur WEB de l'annuaire
avec son navigateur et formule des requêtes au travers de formulaires électroniques dans des
pages HTTP. Il peut intégrer les réponses dans son annuaire local.
2. interrogation au travers d'une application qui présente ses requêtes LDAP qui consultent
l'annuaire local et, si besoin, l'annuaire du GIP "CPS". L'application peut stocker les réponses
dans l'annuaire local au travers d'API d'accès à l'annuaire local.
L'alimentation de l'Annuaire du GIP est assurée par l'Autorité de Certification (certificats et leurs
révocations) et le Centre de Gestion (autres données).
Normes & Standards utilisés :
• structure annuaire
• format des certificats
• sécurisation des flux
• protocole d'accès à l'annuaire
• protocole inter-annuaire
: X.520 (standard ISO),
: X.509v3 (norme ISO & standard IETF),
: SSL puis TLS (standard IETF),
: LDAP (standard IETF),
: DISP (standard ISO).
10
09 décembre 2003
Page 52 / 74
GIP "CPS"
Version 5.1
Relations entre le Promoteur et le GIP "CPS"
10.1 KITs d'intégration et licence d'utilisation des services API
10.1.1 Environnements informatiques
Il existe plusieurs environnements informatiques dans le Secteur Santé. Le GIP "CPS" a développé
les logiciels des services dans les environnements les plus représentés :
Plates-formes Windows :
• Windows 95, release 4.00.950 B
• Windows 98, seconde édition, release 4.10.2222 A
• Windows NT4.0, service pack 5
• Windows 2000, service pack 1, release 5.00.2195
• Windows XP.
Plates-formes Macintoch :
• MacOS version FU1-7.5.3, révision 2.2
• MacOS version 9.04
• MaxOS X, version 10.1 (10.2 recommandée)
Plates-formes Unix :
• Unix AIX version 4.2
• Unix SCO Openserver version 5
• Unix SCO UnixWare 7, release 5, version 7.1.1
• Unix SUN Solaris version 7
• Unix HP-UX version 11.0
• Unix Linux RedHat 6.2
Des tests de compatibilité ont été réalisés avec succès sous :
• Unix OpenUnix 8 (utilisation des API SCO UnixWare 7)
• Unix OpenLinux (utilisation des API Linux RedHat)
Plate-forme Prologue : Twin Server 2.2b/D2a
Si un Promoteur a un besoin d'environnement non couvert, il est invité à contacter le GIP
"CPS".
10.1.2
09 décembre 2003
Page 53 / 74
GIP "CPS"
Version 5.1
Description du KIT
Le KIT (adapté pour chaque environnement) est constitué en standard des éléments suivants :
• Les logiciels "CPS"
• les services "CPS", le gestionnaire (GALxxx...) et le protocole (PSSxxx...)
• une ou des applications de démonstration de la programmation des services (CPPGxxx...)
• l'application de Gestion "CPS" sur le poste du PS (CPGESxxx...)
• Les documentations "CPS"
• le guide d'intégration des services
• les manuels de programmation des services
• Optionnel : un dispositif de lecture (lecteur) de cartes "CPS",
Le lecteur est un lecteur mono-fente "CPS" du marché certifié "NF-CPS".
• Optionnel : un jeu de cartes "CPS" de tests.
Ce jeu comprend un lot de cartes représentatif des différentes "CPS" : CPS, CPF et CPE.
10.1.3 Commande du KIT
Le KIT est à commander auprès du GIP "CPS". Dans la commande, le Promoteur précise le ou les
environnements souhaités.
Les livraisons s'effectuent en fonction des disponibilités.
Le promoteur dispose de ce KIT pour effectuer ses travaux d'intégration.
Pour mettre en exploitation son application, le Promoteur doit présenter une demande au
Collège de Déontologie du GIP "CPS". Après avoir obtenu l'avis favorable du Collège, il devra
contracter une licence d'usage auprès du GIP "CPS".
10.2
09 décembre 2003
Page 54 / 74
GIP "CPS"
Version 5.1
Formation au GIP "CPS"
Le GIP "CPS" communique régulièrement aux Promoteurs les dates de sessions de formation sur la
"CPS" et ses services.
Cette formation d'une journée est faite au GIP "CPS", mais il est possible de planifier des
formations sur site.
10.3 Support au GIP "CPS"
Le GIP "CPS" assure une aide technique aux Promoteurs ([email protected]).
Une "hot line" est assurée pour les PS.
Il n'y a pas d'intervention sur site sauf cas majeurs.
10.4 Suivi et rapports d'anomalies
Dans l'annexe 11.4, une Fiche de rapport d'anomalie (RA) est à la disposition du Promoteur pour
communiquer avec le GIP "CPS" sur les anomalies de fonctionnement des services (bogues).
Les modifications résultantes de corrections d'anomalies seront intégrées dans la version suivante du
KIT.
Il peut y avoir des diffusions restreintes de ces corrections en cas d'anomalie bloquante...
09 décembre 2003
Page 55 / 74
GIP "CPS"
Version 5.1
11 ANNEXES
09 décembre 2003
Page 56 / 74
GIP "CPS"
Version 5.1
Guide d'Intégration des Services Logiciels de la CPS
11.1 Synoptique des services "CPS"
N°
lig
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
OuvertureSession
FermetureSession
TestSession
Ce service est indispensable à l'application pour une utilisation "minimale" de la CPS °
Accès vers la carte durant l'exécution de ce service
Le code porteur doit être actif pour exécuter ce service
Des calculs RSA sont mis en jeu dans ce service
Ouvre une session entre l'application et le gestionnaire d'accès et réserve les ressources locales à la station (pas d'accès au lecteur).
4
Ferme la session référencée après avoir libéré les ressources locales à la station..
4
Renvoie le nom de l'application bloquée en exclusivité d'accès à une ressource en empêchant tout accès à la session (contexte multi-applications).
IntroductionCarte
RetraitCarte
TestPrésenceCarte
InformationsCarte
Demande au lecteur l'introduction et la mise sous tension de la carte (si ce n'est déjà fait). Avec ou sans attente.
Demande au lecteur la mise hors tension de la carte et son retrait. Avec ou sans attente.
Demande au lecteur si une carte est présente, si elle est sous tension et si le code porteur est actif (réponse immédiate).
Renvoie les informations caractéristiques de la carte : son émetteur, son type (MS, CPS, PA), son numéro et sa date de fin de validité.
InformationsPorteur
ListeApplications
PresCodePorteur
ModifCodePorteur
RecycleCodePorteur
InformationsPS2
LecSituationPS
GénèreDéfiAuthen
CalculAuthen2
VérifAuthen2
CondenseMessage
CondenseFichier
CalculSign2
VérifSign2
Renvoie les informations génériques sur le porteur de la carte (civilité, nom, prénoms et langues du porteur).
Liste les applications disponibles dans la carte (responsable du domaine commun et des domaines applicatifs).
Présente le code porteur à la carte.
Modifie le code porteur par présentation de l'ancien et du nouveau.
Recycle un code porteur par présentation du code de recyclage et du nouveau code.
Renvoie les informations caractéristiques du PS (profession, spécialité, disciplines...) et son type de carte (CPS, CPF, CPE, CPA).
Lit les différents fichiers de situation d'exercice du PS (accès par identifiant de fichier).
Génère un défi (valeur aléatoire).
Calcule la valeur d'authentification sur un défi fourni de l'extérieur.
Vérifie la cohérence entre une valeur d'authentification et un défi.
Condense un message en vue d'un calcul et / ou d'une vérification de signature.
Condense un fichier en vue d'un calcul et / ou d'une vérification de signature.
Calcule la valeur de signature sur un condensât.
Vérifie la cohérence entre une valeur de signature et un condensât.
DirSituationsPS
LecSitFacturation
Renvoie la liste des identifiants des différents fichiers de Situation d'exercice du Professionnel de Santé
Renvoie les informations du Fichier des Facturations du domaine Assurance Maladie
Nom du service
09 décembre 2003
4
4
4
4
4
4
°
°
°
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
N°
lig
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Page 57 / 74
GIP "CPS"
N°
lig
27
28
29
30
31
32
33
34
Guide d'Intégration des Services Logiciels de la CPS
Ce service est indispensable à l'application pour une utilisation "minimale" de la CPS °
Accès vers la carte durant l'exécution de ce service
Le code porteur doit être actif pour exécuter ce service
Des calculs RSA sont mis en jeu dans ce service
Nom du service
LectureX509
VerifX509
InterpreteX509_CPS
GenereAleaCPS
09 décembre 2003
Lit le certificat X.509 d'une Clé publique (dont la valeur de la clé)
Vérifie la signature d'un certificat X.509 d'une Clé publique.
Extrait les champs d'un certificat X.509 d'une Clé publique.
Fait générer une valeur aléatoire par la CPS
Version 5.1
°
°
°
4
4
4
4
N°
lig
27
28
29
30
31
32
33
34
Page 58 / 74
GIP "CPS"
Version 5.1
11.2 Synoptique des Codes Retours des services "CPS"
Hors le code retour 0x80 signifiant une erreur de configuration à l'ouverture de la session, les
services retournent l'un des codes suivants :
Hex
12 FICHIER INVALIDE
11
CARTE INVALIDEE
10
ERREUR_LOGICIELLE
0F
ERREUR_PARAMETRAGE
0E
MANQUE_RESSOURCE_SYSTEME
0D LECTEUR_OCCUPE
0C SERVICE_IMPOSSIBLE
0B CODE_INACTIF
0A CARTE_BLOQUEE
09
CARTE_INCONNUE
08
CARTE_ABSENTE
07
CARTE_HORS_TENSION
06
ERREUR_TRANSMISSION
05
NON_REPONSE_DU LECTEUR
04
SESSION_DEJA_OUVERTE
03
SESSION_NON_OUVERTE
02
LECTEUR_INEXISTANT
01
ETAT_CARTE_CHANGE
FF
NOK
Liste des Services CPS
CPS_Ouverture_Session
CPS_Fermeture_Session
CPS_Test_Session_
CPS_Introduction_Carte
CPS_Retrait_Carte
CPS_Test_Présence_Carte
CPS_Informations sur le Porteur
CPS_Informations sur la Carte
CPS_Liste_Applications
CPS_Pres_Code_Porteur
CPS_Modif_Code_Porteur
CPS_Recycle_Code_Porteur
CPS_Informations_PS
CPS_Lec_Situation_PS2
CPS_Calcul_Authen2
CPS_Condense_Message
CPS_Condense_Fichier
CPS_Calcul_Sign2
CPS_Vérif_Authen2
CPS_Vérif_Sign2
CPS_DirSituationsPS
F
F
X
X
X
X
0
1
0
2
0
3
0
4
X
0
5
0
6
0
7
0
8
0
9
0
A
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
0
B
0
C
0
D
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
0
E
X
X
X
X
X
0
F
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
1
0
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
1
1
1
2
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
…/…
09 décembre 2003
Page 59 / 74
GIP "CPS"
12
FICHIER INVALIDE
11
CARTE INVALIDEE
10
ERREUR_LOGICIELLE
0F
ERREUR_PARAMETRAGE
0E
MANQUE_RESSOURCE_SYSTEME
Version 5.1
0D LECTEUR_OCCUPE
0C SERVICE_IMPOSSIBLE
0B CODE_INACTIF
0A CARTE_BLOQUEE
09
CARTE_INCONNUE
08
CARTE_ABSENTE
07
CARTE_HORS_TENSION
06
ERREUR_TRANSMISSION
05
NON_REPONSE_DU LECTEUR
04
SESSION_DEJA_OUVERTE
03
SESSION_NON_OUVERTE
02
LECTEUR_INEXISTANT
01
ETAT_CARTE_CHANGE
FF
NOK
Liste des Services CPS
CPS_Lecture_X509
CPS_Vérif_X509
CPS_Interpretation_X509_CPS
CPS_GenereAleaCPS
F
F
0
1
X
0
2
0
3
X
0
4
0
5
X
0
6
X
0
7
X
0
8
X
0
9
X
X
X
X
0
A
0
B
X
X
X
X
X
X
X
0
C
X
X
X
X
0
D
X
0
E
X
X
X
0
F
X
X
X
X
1
0
X
X
X
X
1
1
1
2
X
X
11.3
09 décembre 2003
Page 60 / 74
GIP "CPS"
Version 5.1
Performances des Services CPS
Moyennes de mesures de performances de Services :
Station :
Lecteur :
KIT :
PC pentium II
NF CPS, connecté au port série à 9600 bds et PC/SC USB
Version 5.0 Windows 32 bits
Performances de l'API V5 de gestion d'introduction / éjection carte :
API (s)
Ejection
T1 mesuré
Introduction + Ejection
T2 mesuré
Introduction
T3=T2–T1
T4 mesuré
Lecteur
PSS
PC/SC
PSS
PC/SC
PSS
PC/SC
CPS2ter
0,22 s
0,89 s
1,79 s
1,73 s
1,57 s
0,84 s
0,29 s
0,15 s
CPS2bis
0,21 s
0,97 s
2,09 s
2,17 s
1,88 s
1,20 s
0,38 s
0,28 s
CPS2
0,21 s
0,97 s
2,47 s
2,42 s
2,26 s
1,45 s
(actualisée)
0,68 s
0,46 s
CPS2
0,22 s
1,00 s
2,46 s
2,45 s
2,24 s
1,45 s
0,65 s
0,45 s
T1 = éjection (mise en tension) mesurée avec une carte présente et hors tension.
T2 = introduction + éjection mesurée avec une carte présente.
T3 = introduction d'une carte présente mais hors tension (calculé).
T4 = introduction d'une carte présente sous tension.
Performances de l'API V5 de calcul de signature (CPS_CalculSign2) :
Clé
96
128
Lecteur
PSS
PC/SC
PSS
PC/SC
CPS2ter
1,90 s
1,25 s
CPS2bis
1,95 s
1,75 s
(*)
(*)
CPS2
1,45 s
1,45 s
(*) CPS_CalculAuthen2 pour la clé 128 de la CPS2ter,
256
PSS
3,35 s
PC/SC
2,30 s
Performances de l'API V5 de lecture de certificat (CPS_CalculLectureX509) :
Clé
Lecteur
CPS2ter
CPS2bis
CPS2
96
128
PSS
PC/SC
3,55 s
2,60 s
1,70 s
1,30 s
PSS
3,90 s
256
PC/SC
1,80 s
PSS
4,45 s
PC/SC
2,15 s
11.4
09 décembre 2003
Page 61 / 74
GIP "CPS"
Version 5.1
Fiche de rapport d'anomalie (RA)
Cette fiche est à compléter et à retourner au GIP "CPS" (par E-mail par exemple) :
Fiche de rapport d'anomalie
Société :
Interlocuteur :
Tél :
E-mail :
Adresse :
IDENTIFICATION DE L'EMETTEUR (remplir la colonne de gauche)
GIP "CPS"
Service Technique
Fax :
Tél :
01 44 53 36 53 Fax :
01 40 16 90 15
E-mail :
[email protected]
Adresse : 8 bis, rue de Châteaudun - 75009 - PARIS
IDENTIFICATION DU RA (remplir la colonne de gauche)
N° interne chez l'émetteur :
N° interne au GIP :
AAAAMMJJ-NN-XXX
Date d'envoi au GIP :
JJ/MM/AAAA
Date d'envoi de la réponse : JJ/MM/AAAA
Bloquant
Urgent
Information
Date de clôture du RA:
JJ/MM/AAAA
QUALIFICATION DU RA
Titre du RA :
<<Phrase courte mnémotechnique>>
PIECES JOINTES :
Disquettes
Cartes
<<Préciser>>
Anomalie Constatée :
Documents
Autres
DESCRIPTION DU RA :
<<décrire l'anomalie et les valeurs relevées>>
Comment la reproduire : <<décrire s'il est possible de reproduire l'anomalie>>
Proposition de solution : <<décrire les besoins>>
INFORMATIONS TECHNIQUES SUR LE RA :
1) Compte rendu d'exécution de l'API testée :
CR renvoyé par l'API : <<??>> décimal ou Hexa (rayer la mention inutile)
Structure CPS_StatusService renvoyée par l'API :
NumVersionAPI
<<??>>
décimal ou Hexa (rayer la mention inutile)
NumVersionAPI
<<??>>
NumAPI
<<??>>
StatusAPI
<<??>>
StatusGestionnaire <<??>>
StatusInterne
<<??>>
StatusLecteur
<<??>>
StatusCarte
<<??>>
09 décembre 2003
Page 62 / 74
GIP "CPS"
Version 5.1
2) Versions des logiciels (affichées par CPPGCW32.exe, Menu Lectures, Information Poste)
CPSW32
<<??>>
SSCASW32
<<??>>
GALINW32
<<??>>
GALCLW32
<<??>>
GALSVW32
<<??>>
PSSINW32
<<??>>
3) Joindre (si possible) :
N° logique de la carte testée :
N° du certificat X509 testé :
<<??>>
<<??>>
4) Questions (si possible) :
L'API fonctionne-t-elle avec CPPGCW32.exe ?
L'application CPGESW32 fonctionne-t-elle ?
non oui oui, mais <<préciser>>
non oui (joindre CPS-DIAG.TXT et CPS-TRAC.TXT)
5) Autres :
<<Compléter...>>
11.5
09 décembre 2003
Page 63 / 74
GIP "CPS"
Version 5.1
Principales Questions - Réponses
11.5.1 Répartition des services sur le poste ou le serveur ?
Poste :
Serveur :
le matériel et le programme qui gèrent la "CPS" (là ou se situe le porteur)
le système informatique qui se protège grâce aux sécurités liées à la "CPS"
sans nécessité de présence d'une "CPS".
Attention, le poste du PS peut aussi être considéré comme serveur dès qu'il sécurise une
communication avec un autre PS :
• Vérification d'une signature sur un message reçu.
• Authentification de la "CPS" distante avant d'engager un dialogue.
La lecture de ce manuel répond explicitement à la question : l'analyse des procédures et des
services associés permet d'étudier la répartition des services entre les 2 entités.
En première approximation :
• Tous les services qui font accès à la carte sont sur le poste (voir annexe "Synoptique des
services "CPS"") et ont donc un champ EtatCarte !
• Tous les services de lectures dans la "CPS" et de calculs par la "CPS" (RSA) sont sur le poste.
• Tous les services de vérifications RSA (de certification, de signature, d'authentification) sont
sur le serveur. Attention, dans la procédure de signature, les services CPS_CondenseFichier
et CPS_CondenseMessage sont utilisés sur les 2 entités.
Le tableau de la page suivante donne la répartition Poste et Serveur
09 décembre 2003
Page 64 / 74
GIP "CPS"
Services sur le Poste (la CPS)
Services sur le Serveur
Version 5.1
Commentaires
CPS_OuvertureSession
CPS_FermetureSession
Gestion des sessions
CPS_IntroductionCarte
CPS_RetraitCarte
CPS_TestPrésenceCarte
Gestion de la carte
CPS_PresCodePorteur
CPS_ModifCodePorteur
CPS_RecycleCodePorteur
Gestion du code porteur
CPS_InformationsPorteur
CPS_ListeApplications
CPS_InformationsPS2
CPS_LecSituationPS
CPS_DirSituationsPS
Lectures carte
CPS_LectureX509
CPS_VerificationX509
CPS_InterpretationX509-CPS
Contrôles de certification
CPS_GénèreDéfiAuthen
Procédure
d'authentification
CPS_CalculAuthen2
CPS_VérifAuthen2
CPS_CondenseMessage
CPS_CondenseFichier
CPS_CalculSign2
09 décembre 2003
CPS_CondenseMessage
CPS_CondenseFichier
CPS_VérifSign2
Procédure de signature
Page 65 / 74
GIP "CPS"
Version 5.1
11.5.2 La carte CPS et la carte VITALE ?
La carte CPS est la carte du Professionnel de Santé et la carte VITALE est la carte de l'Assuré
Social.
La CPS est utilisée par toutes les applications du Secteur Santé.
Les cartes CPS et VITALE sont utilisées par les applications de gestion de la Feuille de
Soin Electronique (FSE).
Le GIP "CPS" est responsable de l'émission, la gestion et la promotion de la "CPS" auprès des
utilisateurs et de la disponibilité auprès des Promoteurs d'Applications de logiciels d'accès à la
"CPS" (services).
Le GIP "CPS" a publié vers les industriels les spécifications techniques des lecteurs de
cartes CPS. L'industriel fait certifier son matériel auprès de l'AFNOR. Le Promoteur et
l'utilisateur choisissent le lecteur "CPS" dans la liste des lecteurs certifiés.
Le GIP "CPS" fournit aux promoteurs d'applications les logiciels des services CPS et un
jeu de cartes CPS de tests.
L'intégration dans une application de la gestion de la Feuille de Soin Electronique est de la
responsabilité technique du GIE SESAM-VITALE.
Le GIE SESAM-VITALE fournit aux Promoteurs les Modules Logiciels à intégrer dans
l'application et les lecteurs "Intelligents", double fente CPS et VITALE ainsi que les jeux
de cartes de tests.
Les 2 organismes ont défini en commun la structure technique de la plate-forme d'accueil de ces
diverses applications.
Spécifications du Gestionnaire d'accès aux lecteurs (GALSS), du protocole de
communication des lecteurs (PSS) et du Jeu de commande minimum du lecteur de "CPS".
La "fente" CPS du lecteur SESAM-VITALE est accessible directement par une application
comme un simple lecteur CPS.
En conséquence :
• Le cahier des charges du lecteur bi-fente CPS-VITALE et de l'intégration des logiciels FSE
est à rechercher auprès du GIE SESAM-VITALE.
• Les spécifications techniques des lecteurs CPS et des services CPS sont à rechercher auprès
du GIP "CPS"
• La diffusion du KIT "CPS" seul est assurée par le GIP "CPS".
• La diffusion du KIT "FSE+CPS" est assurée par le CNDA.
09 décembre 2003
Page 66 / 74
GIP "CPS"
Version 5.1
11.5.3 Langages de programmation des API's et compilateurs ?
Les API's CPS (et les logiciels GALSS et PSS) sont développées en langage C.
Les compilateurs utilisés sont :
Windows
Prologue
MAC
UNIX SCO
LINUX
HP
Sun Solaris
UnixWare
AIX
Visual C++ Microsoft
Visual C++ Microsoft
Code Warrior de MetroWERKS
SCO UNIX Development System
GCC
HP C Compiler
Forte Developper
CCS
AIX Compiler
Les API's CPS peuvent être activées à partir de tout langage X dès lors que le compilateur ou
interpréteur X utilisé offre la possibilité d'interface avec le C (essentiellement le respect de règles
d'empilage et de dépilage des paramètres) ce qui est le cas - à priori - des compilateurs actuels.
Par exemple, le KIT CPS livré dans l'environnement Microsoft (Visual C++) contient des
programmes de démonstration de la programmation des API CPS en langage C et en
langage Visual-Basic.
Les règles et options de compilation des API CPS sont explicitées dans les manuels de
programmation.
Si certaines imprécisions existent, le Support du GIP "CPS" doit être contacté et les
manuels de programmation seront enrichis.
Exemple extrait du fichier CPSAPI.H de déclaration des types et prototypes des APIS CPS
typedef struct
UINT16
UINT16
UINT16
UINT16
UINT16
UINT16
UINT16
UINT16
UINT16
CPS_StatusService {
NumVersionAPI;
/* numero de version des API */
NumVersionAPI;
/* numero de version du service */
NumAPI;
/* numero du service API */
StatusAPI;
/* code retour de l'API */
StatusGestionnaire; /* resultat d’execution des fonctions du Gestionnaire. */
StatusInterne;
/* etape interne du service */
StatusLecteur;
/* Code retour lecteur */
StatusCarte;
/* Status Carte ME1-ME2 */
StatusCarte;
} CPS_StatusService;
typedef struct
UINT8
UINT8
UINT8
UINT8
UINT8
CPS_InfosCarte {
IdEmetteur
IdCarteLog
CategorieCarte
DateEmis
DateFinVal
} CPS_InfosCarte ;
[11];
[10];
[2];
[8];
[8];
UINT16 API_ENTRY CPS_InformationsCarte( /* Prototype API */
UINT16
NumSession,
09 décembre 2003
Page 67 / 74
GIP "CPS"
struct
CPS_InfosCarte PTR
CPS_StatusService PTR
PUINT16
09 décembre 2003
Version 5.1
pIC,
pStatusService,
pEtatCarte);
Page 68 / 74
GIP "CPS"
Version 5.1
11.5.4 Connexion série de lecteurs NF CPS sur le Macintosh ?
Les lecteurs CPS fournis par les différents constructeurs doivent pouvoir s'interconnecter (chaînage
de lecteurs). Le standard de connexion "DB9" a été choisi. Tous les lecteurs NF CPS ont donc une
prise de raccordement DB9 femelle.
• Pour les PCs et beaucoup d'autres machines, cette prise se raccorde sur la sortie DB9 mâle du
Port Série.
• Pour les Macintosh, le GIP "CPS" livre dans son KIT un câble de raccordement DB9-DIN8.
La solution, pour l'utilisateur final de l'application, appartient au constructeur du lecteur
et au promoteur d'application.
Schéma du câble de raccordement du lecteur CPS sur Macintosh (attention : ce schéma ne
prend pas en compte l’alimentation électrique du lecteur) :
Lecteur CPS
DB9
M
DB9
M
DB9
F
PC
ou
DB9
M
3
5
2
MAC
DIN8
3
4
5
Le lecteur CPS de base (simple lecteur transparent) est livré configuré d'adresse PSS = 0 et de
vitesse = 9600 bauds.
• Avantage : pas de manipulation.
• Inconvénient : une mise à jour se fait par intervention physique sur le lecteur (une mise à jour ne
serait nécessaire qu'en cas de modification de spécifications).
09 décembre 2003
Page 69 / 74
GIP "CPS"
Version 5.1
11.5.5 La CPS et la gestion des dates ?
Les données concernant les dates dans les cartes de la famille CPS, ainsi que dans la base du Centre
de gestion du GIP "CPS", sont représentées sous la forme AAAAMMJJ (AAAA= Année,
MM=Mois, JJ=Jour) où l'année est enregistrée sur quatre chiffres.
Les API CPS ne font que lire dans la carte les dates et les mettre sous la forme précisée, à la
disposition des applications.
Les API CPS ne font aucun traitement sur les dates (ni calcul, ni comparaison, ni tri).
Le GIP "CPS" rappelle qu'il est de la responsabilité de tout Promoteur d'Application et/ou de
l'exploitant de l'application intégrant les Services CPS, de traiter dans ses applications et/ou de
stocker, les dates fournies par les API-CPS sous leur forme intégrale.
Périodes de validité des cartes CPS :
• La date de début de validité d'une carte correspond à sa date de fabrication.
• La date de fin de validité d'une carte correspond à sa date de début de validité + 2 ans, cadrée
au dernier jour du mois.
Périodes de validité des certificats X.509 :
• La durée de validité des clés (droit d'utilisation) est égale à celle de la carte.
• La durée de validité des certificats d'authentification est égale à celle de la carte.
• La durée de validité des certificats de signature est égale à celle de la carte + 1 mois.
Ce décalage d'un mois laisse un délai entre le moment où un porteur signe un message et
le moment ou le destinataire récupère le certificat lui permettant de vérifier cette
signature.
Ce décalage ne se justifie pas pour l'authentification qui s'effectue "à l'instant t".
11.5.6
09 décembre 2003
Page 70 / 74
GIP "CPS"
Version 5.1
Compatibilités entre les versions de CPS et de KIT ?
La CPS contient un ensemble de données. La liste de ces données ainsi que leurs structures internes
(formats et valeurs de codification) sont décrites dans un document référencé par une valeur de PIX
(Propriety application Identifier eXtension).
Ce PIX permet d'établir un lien entre la version de la carte et la version des API CPS.
La valeur de PIX est inscrite dans la carte CPS et les API sont programmées pour des traitements
adaptés aux différentes valeurs de PIX existants. Ainsi, le PIX = 01 est aujourd'hui refusé par les
API CPS et les cartes CPS sur le terrain ont un PIX = 02.
Il ne peut exister au maximum que 2 versions de CPS sur le terrain :
• la plus récente en cours d'émission pour les nouveaux porteurs et pour les renouvellements ;
• la précédente pour un délai de 3 ans de période de validité d'une CPS.
Ceci dans la mesure ou le GIP "CPS" ne change pas de version de CPS avant 3 ans.
Les API de version N+1 sont un sur ensemble des API de version N.
Il en résulte une totale compatibilité illustrée dans le schéma suivant :
Application basée sur API N
Application basée sur API N+1
API N
API N+1
CPS N
CPS N+1
11.5.7
09 décembre 2003
Page 71 / 74
GIP "CPS"
Version 5.1
Accès à l'annuaire des certificats X.509 ?
Tout public a un accès à l'annuaire du GIP "CPS" : http://annuaire.gip-cps.fr/ pour une recherche
limitée. (voir aussi l'accès par le site du GIP "CPS" : http://www.gip-cps.fr)
Au delà de cette limite, l'annuaire déclenche une procédure de contrôle de présence d'une CPS.
Une application peut présenter des requêtes LDAP vers l'annuaire CPS. Ces requêtes sont
présentées au format URL défini dans [RFC 2255]. Voici quelques exemples :
Objectif
Fiche de l'AC racine
Fiche de l'AC CPS2
Fiche de l'AC
Classe1
Liste de révocation
Delta de la liste de
révocation
Certificat(s) AC
Liste des médecins
porteurs d'une CPF
Liste des
établissements dans
un département
Etablissement dans
un département
Fiche PS (structure)
Fiche PS
Fiche PS (structure)
Fiche PS
Fiche PS
Fiche PS
Fiche PS
09 décembre 2003
Requête
ldap://annuaire.gip-cps.fr/o=gip-cps,c=fr
ldap://annuaire.gip-cps.fr/ou=ac-cps2,o=gip-cps,c=fr
ldap://annuaire.gip-cps.fr/ou=ac-classe-1,o=gip-cps,c=fr
ldap://annuaire.gip-cps.fr/ou=ac-classe-1,o=gipcps,c=fr?certificateRevocationList;binary
ldap://annuaire.gip-cps.fr/ou=ac-classe-1,o=gipcps,c=fr?deltaRevocationList;binary
ldap://annuaire.gip-cps.fr/ou=ac-classe-1,o=gipcps,c=fr?caCertificate;binary
ldap://annuaire.gip-cps.fr/ou=médecin,o=gipcps,c=fr?cn,sn,gn,typecarte?sub?(typecarte=CPF)
ldap://annuaire.gip-cps.fr/l=Paris (75),o=gip-cps,c=fr??one?
ldap://annuaire.gip-cps.fr/l=Paris (75),o=gip-cps,c=fr?raisonsociale?one?
ldap://annuaire.gipcps.fr/sn=DUPONT+givenname=Jean+cn=0751012344,ou=075101234400,l
=Paris (75),o=gip-cps,c=fr
ldap://annuaire.gipcps.fr/sn=DUPONT+givenname=Jean+cn=0751012344,ou=médecin,o=gipcps,c=fr
ldap://annuaire.gip-cps.fr/o=gipcps,c=fr??sub?(&(serialnumber=2000123456)(objectclass=cpsStructuralPers
on))
ldap://annuaire.gip-cps.fr/o=gipcps,c=fr??sub?(&(serialnumber=2000123456)(objectclass=cpsPersonne))
ldap://annuaire.gip-cps.fr/ou=médecin,o=gipcps,c=fr??sub?(cn=0751012344)
ldap://annuaire.gip-cps.fr/ou=médecin,o=gip-cps,c=fr??sub?(&(sn=
DUPONT)(cn=0751012344))
ldap://annuaire.gip-cps.fr/ou=médecin,o=gip-cps,c=fr??sub?(&(sn=
DUPONT)(givenname=Jean))
Page 72 / 74
GIP "CPS"
Version 5.1
Page 73 / 74
11.5.8
09 décembre 2003
GIP "CPS"
Version 5.1
CPS et lecteurs PC / SC ?
L'architecture PC / SC existe dans les environnements Windows, Mac OSX et Linux.
Il a été développé une passerelle de communication de l'architecture GALSS vers PC / SC afin de
permettre l'utilisation de ces lecteurs par les API CPS et les API de lecture Vitale.
API des SERVICES CPS
autres :
API de Lectures Vitale (Hospitaliers)
GESTIONNAIRE D'ACCES AUX LECTEURS (GALSS)
Protocole PSS
Protocole PC / SC =
Passerelle de communication vers
L'architecture PC / SC
Attention toutefois :
1. Cette passerelle est incompatible avec les lecteurs bi-fente de gestion des FSE.
Il ne peut donc être question d'installer cette passerelle chez un PS équipé de logiciels de
gestion de FSE…
2. Elle suppose que l'installation de PC / SC (Resource Manager et Driver) est correcte.
Suivant les environnements, l'installation de PC /SC est native ou doit être effectuée,
l'installation et la reconnaissance du lecteur sont automatiques ou non.
Il est impératif de vérifier ces installations avant d'utiliser cette passerelle.
3. Elle nécessite une mise à jour particulière du fichier de configuration GALSS.INI
Limitations : cette passerelle effectue une conversion entre 2 architectures de types différents
(synchrone et asynchrone) ; certains traitements d'erreurs en cas de manipulations "sauvages"
peuvent être non optimum !
09 décembre 2003
Page 74 / 74

Guide d`intgration des APIs CPS - esante.gouv.fr, le portail de l`ASIP

Transcription

Documents pareils

3- Réactivation code Carte CPS ou CPF

L`activité physique au quotidien permet de rester fort et en santé

Programme des Ateliers CEA (mars 2016)

h9045 colle thermofusible pour la construction des serviettes

VOUS SOUHAITEZ VOUS INSCRIRE A LA C

« Permettez-moi de remercier la mairie du 10e arrondissement de

DS101-EMB /V - Acel Genesys

club de plongee sportive - CPS Rixheim

DS 101-IND / DS 101-EMB