Migration des IGC-CPSintegrateurs-cps.asipsante.fr/sites/default/files/ASIPSanté... · la mise en œuvre du produit F5 BIG-IP Global Traffic Manager de la société F5, la migration

Classification : Non sensible - public 1 / 62

Migration des IGC-CPS

vers l’IGC-Santé

Analyse des impacts sur les applications terrain et consignes de migration

v1.0.4 du 24/03/2017

Destinataires : éditeurs et gestionnaires d’application

Thématique : produits de certification

ASIPSanté - Migration IGC-Santé - Impacts et Consignes - v1.0.4.docx 24/03/2017

Classification : Non sensible – public 2 / 62

Migration des IGC-CPS vers l’IGC-Santé

Analyse des impacts sur les applications terrain et consignes de migration

« ASIP Santé »

Version 1.0.4 du 24/03/2017

Historique du document

Version Date Auteur Commentaires

V 1.0.0 28/10/2015 PUSC / PSCE Première version pour publication

V 1.0.1 07/01/2015 PUSC / PSCE Modifications de forme

V 1.0.2 21/10/2016 PUSC / PSCE Mises à jour éditoriales

V 1.0.3 06/12/2016 PUSC / PSCE

Avertissements concernant :

la gestion de certains RDN par les applications Microsoft,

le contenu de l’extension « key-usage » pour les certificats de signature,

la mise en œuvre du produit F5 BIG-IP Global Traffic Manager de la société F5,

la migration des serveurs SSL mettant en œuvre le mécanisme SNI,

les tailles des certificats et CRLs.

V 1.0.4 24/03/2017 PUSC / PSCE

Précisions sur la hiérarchie d’AC de l’IGC-Santé.

Précisions concernant l’étape 2 :

Modifications mineures de présentation.

Ajout de la correspondance entre les IGC actuelles et l’IGC-Santé pour ce qui concerne les certificats embarqués sur carte.

Détermination du type de certificat et du type de carte.

Versions de Cryptolib à utiliser

Ajout d’une annexe indiquant les éléments distinctifs d’une carte embarquant des certificats IGC-Santé.



Documents de référence

Guides et Documents de bonnes pratiques disponibles sur le site « intégrateurs CPS »

[1] IGC-Santé – Etapes 1 et 2 - Les gabarits des certificats X.509 et des CRLs Version V 1.0.0 du 21/10/2015

[2] ASIP_IGC-Sante_Guide-WebService Manuel d’utilisation pour la demande de certificats en mode Webservice Version V1.0.0 du 28/01/2016

[3] ASIP_IGC-Sante_Guide-IHM Manuel d’utilisation pour la demande de certificats en mode HTTP Version V1.0.0 du 28/01/2016

[4] Guide de bonnes pratiques d’utilisation des listes de révocation des certificats

Novembre 2016

[5] ASIP_Annuaire-CPS_Schema DIT Version 9.0.4 du 30/07/2014

[6] IGC-CPS2bis (IGC prorogée jusqu’à fin 2020) Les gabarits des certificats X.509 et des CRLs Applicable aux certificats logiciels des Classes 4, 5 et 6 Version 3.0 du 21/03/2012

[7] IGC-CPS2ter-2020 (IGC prorogée jusqu’à fin 2020) Les gabarits des certificats X.509 et des CRLs Applicable aux cartes CPS3 Version 1.0 du 20/03/2012

[8] Utilisation de OpenSSL et de mod_ssl avec les cartes CPx et les produits de certification de l’ASIP Santé

Version 3.0.0 du 05/10/2015

[9] Guide de mise en œuvre de la partie sans-contact des cartes CPx Version 2.3.8 du 30/09/2015

[10] Sécurité bureautique avec les produits de certification ASIP-Santé (carte CPS et certificats logiciels)

Version 2.0.1 du 30/09/2015

[11] Composants v4 obsolètes de la Cryptolib CPS v5.0 – 23/02/2017

http://integrateurs-cps.asipsante.fr/sites/default/files/ASIP_IGC-Sante_Guide-WebService_160128_v1.0.0.pdf

http://integrateurs-cps.asipsante.fr/sites/default/files/ASIP_IGC-Sante_Guide-IHM_160128_v1.0.0.pdf



Standards applicables

[12] RFC 4514 - LDAP - String presentation of Distinguished Names Remplace les RFC 1779 et RFC 2253

[13] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile

[14] RFC 6818 - Updates to the Internet X.509 Public Key Infrastructure (RFC 5280) Updates of Certificate and CRL Profile

[15] RFC 6960 - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP

Liens web consacrés au système CPS et à la migration vers l’IGC-Santé

[16] Site web de l’ASIP Santé http://esante.gouv.fr/

[17] Page web contenant toutes les informations formelles et techniques de l’IGC-Santé http://igc-sante.esante.gouv.fr/PC

[18] Espace intégrateurs CPS http://integrateurs-cps.asipsante.fr/

[19] Espace migration IGC-Santé http://integrateurs-cps.asipsante.fr/IGC-Sante-migration

http://esante.gouv.fr/

http://igc-sante.esante.gouv.fr/PC

http://integrateurs-cps.asipsante.fr/

http://integrateurs-cps.asipsante.fr/



Sommaire

1 Objet du document................................................................................................................... 7

2 L’architecture de l’IGC-Santé comparée à celle des IGC-CPS ................................................. 9

2.1 L’architecture de l’IGC-Santé ............................................................................................................. 9

2.2 Rappel : l’architecture de l’IGC-CPS2bis .......................................................................................... 10

2.2.1 Les usages des certificats émis par l’IGC-CPS2bis ................................................................................ 11

2.3 Rappel : l’architecture de l’IGC-CPS2ter .......................................................................................... 12

2.3.1 Les usages des certificats émis par l’IGC-CPS2ter ................................................................................ 12

2.4 Rappel : l’architecture de l’IGC-Technique ....................................................................................... 13

2.5 Le cycle de vie des IGC-CPS ........................................................................................................... 14

3 Les schémas de nommage de l’IGC-Santé ............................................................................ 15

3.1 Schéma de nommage des Autorités de Certification ....................................................................... 15

3.2 Schéma de nommage des porteurs dans les certificats ................................................................... 16

3.2.1 Les DN des certificats de personnes physiques ..................................................................................... 17

3.2.2 Les DN des certificats des structures ...................................................................................................... 19

4 Impacts des DN IGC-Santé sur les recherches des porteurs dans l’Annuaire-CPS ................ 20

4.1 Le DIT de l’Annuaire-CPS ................................................................................................................ 20

4.2 Consignes de recherche dans l’Annuaire-CPS ................................................................................ 21

4.3 Détermination du type de porteur d’un certificat IGC-Santé ............................................................. 22

4.4 Détermination du type de certificat et/ou du type de carte CPx en IGC-Santé ................................ 23

5 Les produits de l’IGC-Santé ................................................................................................... 24

5.1 Les certificats de l’IGC-Santé – Etape 1 ........................................................................................... 24

5.2 Les certificats de l’IGC-Santé – Etape 2 ........................................................................................... 25

5.3 La taille des certificats de l’IGC-Santé .............................................................................................. 25

5.4 L’offre de services de la plateforme IGC-Santé................................................................................ 26

5.4.1 Services de demande et de révocation de certificats .............................................................................. 26

5.4.2 Services d’information sur l’état des certificats ....................................................................................... 27

6 Correspondance entre les certificats des IGC actuelles et les produits de l’IGC-Santé .......... 28

6.1 Certificats logiciels ............................................................................................................................ 28

6.1.1 Correspondances des certificats IGC-CPS2bis détenus par des personnes physiques ......................... 28

6.1.2 Correspondances des certificats IGC-CPS2bis détenus par des structures ........................................... 29

6.2 Certificats embarqués sur carte CPx ................................................................................................ 30

7 Cryptographie mise en œuvre par les différentes IGC ........................................................... 31

8 Les différents cas d'usages cryptographiques ........................................................................ 32

8.1 Authentification d'un serveur par un client ........................................................................................ 32

8.2 Signature de données et vérification de la signature ....................................................................... 34

8.3 Chiffrement et déchiffrement de données ........................................................................................ 35

9 Impacts de la migration sur les applications terrain ................................................................ 36

9.1 Les risques fonctionnels liés au déploiement des certificats émis par l’IGC-Santé ......................... 37

9.2 Contraintes liées aux algorithmes des IGC-CPS.............................................................................. 38

10 Les consignes de migration ................................................................................................... 39

10.1 Serveur avec un certificat SSL IGC-CPS2bis – Classe-4 – Cas d’authentification simple .............. 39

10.1.1 Authentification simple - Consignes de migration – Scénario 1 .............................................................. 39



10.1.2 Authentification simple - Consignes de migration – Scénario 2 .............................................................. 41

10.2 Serveur avec un certificat SSL IGC-CPS2bis – Classe-4 – Cas d’authentification réciproque ....... 44

10.2.1 Authentification réciproque - Consignes de migration – Scénario 1 ........................................................ 44

10.2.2 Authentification réciproque - Consignes de migration – Scénario 2 ........................................................ 46

10.3 Serveurs et clients détenant des certificats SSL émis par l’IGC-CPS2bis – Classe-4..................... 48

10.4 Porteurs détenant des certificats S/MIME émis par l’IGC-CPS2bis – Classe-4 ............................... 49

10.4.1 Consignes de migration vers un « certificat cachet » .............................................................................. 49

10.4.2 Consignes de migration vers un « certificat de confidentialité » .............................................................. 50

10.4.3 Consignes de migration vers un « certificat S/MIME » ............................................................................ 51

10.5 Porteurs détenant des certificats de confidentialité (S/MIME) émis par l’IGC-CPS2bis – Classe-5 52

10.6 Postes de travail acceptant des cartes CPx ..................................................................................... 53

10.6.1 Consignes de migration pour les navigateurs ......................................................................................... 53

10.6.2 Consignes de migration pour les progiciels ............................................................................................. 53

10.6.3 Consignes relatives à la Cryptolib ........................................................................................................... 54

10.7 Consigne commune à tous les cas d’usage ..................................................................................... 55

11 L’IGC-Santé de Test .............................................................................................................. 56

11.1 Schéma de nommage des AC de Test ............................................................................................. 56

11.2 Différences entre les certificats de Production et les certificats de Test .......................................... 56

11.3 Comment distinguer un certificat de production d’un certificat de test ............................................. 57

12 Les cartes embarquant des certificats IGC-Santé .................................................................. 58

12.1 Comment distinguer une carte embarquant des certificats IGC-Santé ............................................ 58

12.2 Autres nouveautés ............................................................................................................................ 58

12.3 Le code d’assistance ........................................................................................................................ 59

13 Glossaire et Définitions .......................................................................................................... 60

13.1 Glossaire ........................................................................................................................................... 60

13.2 Définitions ......................................................................................................................................... 61



1 Objet du document

L’ASIP-Santé va mettre en œuvre une nouvelle infrastructure de gestion de clés – nommée « IGC-Santé » – pour remplacer les 2 IGC-CPS 1 actuelles qui expirent fin 2020.

Le présent document technique est destiné aux éditeurs, développeurs et intégrateurs d’applications santé, mettant en œuvre des certificats des IGC-CPS. Il analyse les impacts sur les applications et leurs infrastructures, puis décrit les consignes pour gérer la migration des certificats des IGC-CPS vers l’IGC-Santé et pour assurer la continuité des services. L’IGC-Santé sera mise en place en 2 étapes :

Etape 1 : Migration de l’IGC-CPS2bis vers l’IGC-Santé

o mise en production de l’IGC-Santé et de la nouvelle plateforme de services associée,

o continuité de l’offre de service actuelle pour les certificats logiciels (reprise des services de l’IGC-CPS2bis),

o extension de l’offre actuelle avec des certificats logiciels pour des personnes physiques et des structures,

o l’IGC-CPS2bis entre en phase « fin de vie » ; elle refusera toute demande pour des nouveaux certificats mais elle acceptera encore de révocation des certificats valides. Cf. § 2.5« Le cycle de vie des IGC-CPS ».

Etape 2 : Migration de l’IGC-CPS2ter et de l’IGC-Technique vers l’IGC-Santé

o arrêt de la production des nouvelles cartes CPx avec des certificats émis par l’IGC-CPS2ter,

o démarrage de la production des cartes CPx avec des certificats de l’IGC-Santé,

o arrêt de l’IGC-Technique qui émet actuellement les certificats d’authentification sans contact. Ces certificats sont dorénavant émis par l’IGC-Santé,

o l’IGC-CPS2ter entre en phase « fin de vie » ; arrêt d’émission de CPx avec des certificats de l’IGC-CPS2ter, la révocation des certificats de l’IGC-CPS2ter valides reste possible. Cf. § 2.5« Le cycle de vie des IGC-CPS »,

o les cartes CPx avec des certificats émis par l’IGC-CPS2ter déjà sur le terrain seront renouvelées un mois avant leur date d’expiration, sauf en cas de renouvellement anticipé suite à un changement des données porteur.

1 Les 2 IGC-CPS : - l’IGC-CPS2ter pour les certificats embarqués dans les cartes,

- l’IGC-CPS2bis pour les certificats logiciels.



Dates clef de l’Etape 1 :

Avril 2016 : Mise en production de la nouvelle plateforme de commande de certificats logiciels émis par la nouvelle IGC-Santé et début de la migration terrain. Les services IGC-Santé sont disponibles en ligne, pour délivrer des certificats de test et de production.

Mars 2017 : L’IGC-CPS2bis entre en phase « fin de vie ».

Fin 2020 : Arrêt effectif de l’IGC-CPS2bis ; les certificats racine et tous les certificats finaux ayant expirés, l’IGC-CPS2bis n’est donc plus opérationnelle.

Dates clef de l’Etape 2 :

Février 2017 Disponibilité des cartes de test.

Octobre 2017 Début d’émission des cartes CPx avec des certificats émis par l’IGC-Santé.

Fin 2020 : Arrêt effectif de l’IGC-CPS2ter – date fin de migration Etape 2 Les certificats racine et tous les certificats finaux ayant expirés, l’IGC-CPS2ter n’est donc plus opérationnelle. Toutes les cartes CPx valides ont des certificats émis par l’IGC-Santé.

Un planning détaillé sera fourni dans un document dédié.

Le présent document traite l’analyse des impacts sur les applications terrain

et donne des consignes de migration liées aux étapes 1 et 2.

Ce document traite notamment les sujets suivants :

l’architecture de l’IGC-Santé,

les schémas de nommage,

l’offre produits de l’IGC-Santé en l’Etape 1,

l’offre produits de l’IGC-Santé en l’Etape 2,

la migration vers l’IGC-Santé,

les principes et consignes de migration selon les différents cas d’usage,

le dispositif d’accompagnement.



2 L’architecture de l’IGC-Santé comparée à celle des IGC-CPS

2.1 L’architecture de l’IGC-Santé

L’architecture de l’IGC-Santé offre 3 gammes, correspondant à autant de niveaux de confiance :

Gamme « Elémentaire »,

Gamme « Standard »,

Gamme « Fort ».

Ces trois gammes sont conformes aux exigences techniques du RGS (algorithmes utilisés, tailles de clés, …). La différence de niveau de confiance entre gamme provient d’une part de la qualité de l’enregistrement des porteurs de certificat et d’autre part de la manière dont est protégée la clé privée associée au certificat (certificats dits « logiciels » ou certificats embarqués dans des cartes de la famille CPS et pour lesquels la protection est optimale).

Chaque gamme dispose de 2 domaines :

Domaine « Personnes » pour les personnes physiques, les certificats peuvent être embarqués dans des cartes CPx ou être « logiciels ».

Domaine « Organisations » pour les structures, les certificats sont « logiciels ».

Le schéma ci-dessous montre l’arborescence de l’IGC-Santé et les potentiels porteurs de certificats après mise en œuvre de toutes les étapes.

L’arborescence de l’IGC-Santé

Métier

AC Racine

« FORT »AC Racine

« STANDARD »

infrastructurePERSONNES

AC Racine

« ELEMENTAIRE »

Professionnels réglementés

Personnel de structures Santé/Social

Personnel de structures autorisées

Personnes morales

Entités organisationnelles

Entités fonctionnelles

Équipements matériels

Services techniques

Composants techniques

ACIPERSONNES

ACIORGANISATIONS



En pratique, dans l’IGC-Santé :

Les certificats logiciels ne sont émis que dans la gamme « Elémentaire » : o Par l’ACI « Gamme Elémentaire – Domaine Personnes » pour les certificats

destinés à des personnes physiques. o Par l’ACI « Gamme Elémentaire – Domaine Organisations » pour les certificats

destinés à des structures.

Les certificats embarqués sur carte CPx sont émis selon les cas dans la gamme « Elémentaire », « Standard » ou « Fort » :

o Les certificats d’authentification et de signature – qui identifient le porteur – sont émis :

Par l’ACI « Gamme Elémentaire – Domaine Personnes » pour les cartes CPE/CPA non nominatives (appelées cartes de service en IGC-Santé).

Par l’ACI « Gamme Standard – Domaine Personnes » pour les cartes CPE/CPA nominatives.

Par l’ACI « Gamme Fort – Domaine Personnes » pour les cartes CPS/CPF. o Le certificat d’authentification sans contact – qui identifie la carte – est toujours

émis par l’ACI « Gamme Elémentaire – Domaine Organisations ».

Les ACI « Gamme Standard – Domaine Organisations » et « Gamme Fort – Domaine Organisations » ne sont pas exploitées (elles n’émettent pas de certificats).

Le type de certificat ou le type de carte ne peut pas être déduit de manière fiable par la seule analyse de l’AC émettrice. (cf. §0 «

Détermination du type de certificat et/ou du type de carte CPx en IGC-Santé »).

2.2 Rappel : l’architecture de l’IGC-CPS2bis

L’IGC-CPS2bis n’émet que des certificats « logiciels ».

L’arborescence de l’IGC-CPS2bis

Frontaux AMO-AMCPersonnesStructures

AC Racine

IGC-CPS2bis

Certificats Applicatifs SSL

Certificats Applicatifs S/Mime

Certificats S/Mime Certificats S/Mime

ACIClasse-4

ACIClasse-5

ACIClasse-6



Notes :

L’architecture de l’IGC-CPS2bis n’a qu’un seul certificat racine (ACR) avec 3 autorités de certification intermédiaires (ACI), chacune pour une classe de certificats distincte.

La Classe-6 est déjà arrêtée ; il n’y a plus de certificats de Classe-6 valides. Le GIE SESAM-VITALE a déployé une IGC (dite IGC-OSI) dédiée aux besoins des projets des organismes d’assurance maladie.

La notion de « classes de certificats » des IGC-CPS est abandonnée dans l’IGC-Santé qui est axée sur des gammes et des domaines.

2.2.1 Les usages des certificats émis par l’IGC-CPS2bis

Les usages de chaque certificat dépendent de sa classe et du typage du certificat :

Classe-4 : certificats SSL :

o identification et authentification serveur pour les structures,

o identification et authentification client pour les postes de professionnels de santé et les structures.

Classe-4 : certificats S/MIME :

o (dé)chiffrement de données et signature d’objets pour les structures. (exemple : Messagerie sécurisé S/MIME ou tout autre échange sécurisé)

Classe-5 : certificats S/MIME (certificats de confidentialité) :

o (dé)chiffrement de données pour les personnes physiques.

Classe-6 (arrêtée) : certificats S/MIME :

o (dé)chiffrement de données et signature d’objets pour les Frontaux SESAM-Vitale exploités par des organismes d’assurance maladie.

Note relative aux certificats de la Classe-5 :

Un certificat S/MIME de la Classe-5 est rattaché à une carte CPx ; seul un porteur d’une CPx (ou un gestionnaire désigné) peut faire une demande d’un tel certificat. La période de validité du certificat S/MIME démarre à la date de sa génération et finit à la même date que celle de la carte du porteur.



2.3 Rappel : l’architecture de l’IGC-CPS2ter

L’IGC-CPS2ter n’émet que des certificats qui sont embarqués dans des cartes CPx.

L’arborescence de l’IGC-CPS2ter

La notion de « classes de certificats » des IGC-CPS est abandonnée dans l’IGC-Santé qui est axée sur des gammes et des domaines.

2.3.1 Les usages des certificats émis par l’IGC-CPS2ter

Chaque CPx contient 2 certificats émis par l’IGC-CPS2ter dont les usages sont :

Certificat de signature : signature des objets par son porteur,

Certificat d’authentification (mode client) : authentification du porteur auprès de tiers :

o serveurs distants,

o gestionnaires SSO (Single SIGN-ON),

o LPS (Logiciels de Professionnels de Santé) sur poste de travail,

o …

Porteurs deCartes CPS

AC RacineSTRUCTURE

ACIClasse-1

ACIClasse-2

ACIClasse-3

ACIClasse-0

AC RacineANONYME

AC RacinePROFESSIONNEL

CPE de Service CPS / CPF CDE / CDA CPE / CPA

Sign

Auth

Sign

Auth

Sign

Auth

Sign

Auth

Directeur



2.4 Rappel : l’architecture de l’IGC-Technique

L’ASIP-Santé a créé en 2011 une IGC-Technique afin d’étoffer l’offre avec des certificats pour un usage d’ « authentification sans contact ».

Ces certificats permettent aux structures d’authentifier le « support CPS » afin de gérer des applications de type « carte d’entreprise » : contrôle d’accès physique, pointage horaire, …

L’arborescence de l’IGC-Technique

Notes concernant l’IGC-Technique :

Il n’y a qu’une seule autorité racine qui signe tous les certificats finaux.

Chaque CPx contient un certificat permettant des « authentifications sans contact ».

Les certificats ne contiennent aucune information concernant le porteur de la carte et les structures où il a une activité.

C’est à la charge de chaque structure d’organiser un enrôlement dans son système et de lier localement les différents supports avec les habilitations des porteurs de CPx.

L’IGC-Technique ne publie pas des CRL (il n’y a pas de possibilité de révocation).

Ses certificats ne sont pas publiés dans l’Annuaire-CPS.



2.5 Le cycle de vie des IGC-CPS

Le cycle de vie d’une IGC est constitué de 3 phases :

phase opérationnelle,

phase fin de vie,

phase de mise en arrêt.

Les 3 phases du cycle de vie d’une IGC

Les dates clefs de la vie des IGC-CPS et leurs impacts sur l’état de ses services sont :

Mise en Production de l’IGC – entrée en « phase opérationnelle »

2001 pour l’IGC-CPS2bis et 2004 pour l’IGC-CPS2ter :

o Publication des certificats ACR et ACI,

o Acceptation des demandes de certificats,

o Acceptation des demandes de révocation de certificats,

o Publication quotidienne des CRLs.

Fin de la « phase opérationnelle » – Engagement de la « phase fin de vie de l’IGC »

o Refus de toute nouvelle demande de certificat,

o Acceptation des demandes de révocation de certificats,

o Publication quotidienne des CRLs.

Expiration du dernier certificat actif – Début de la « phase mise en arrêt »

(entre 3 et 5 ans après la date et avant )

o Refus de toute nouvelle demande de certificat,

o Refus des demandes de révocation de certificats,

o Publication de CRL vides jusqu’à la date de fin de vie de l’IGC (date ).

Fin 2020 : Arrêt effectif des IGC-CPS 2

o Dé-publication des certificats ACR et ACI,

o Dé-publication de la dernière CRL.

Note : Les dates clefs et peuvent tomber sur la même date calendaire.

2 Les 2 IGC-CPS ont été prorogées jusqu’à fin 2020 : en 2008 pour l’IGC-CPS2bis et en 2012 pour l’IGC-CPS2ter.

Phase Opérationnelle

1

Phase fin de vie

2

Phase mise en arrêt

3 4



3 Les schémas de nommage de l’IGC-Santé Les émetteurs de certificats (issuers) et leurs porteurs (subjects) sont identifiés par des Distinguished Names (DN) qui sont uniques dans l’IGC-Santé.

3.1 Schéma de nommage des Autorités de Certification

Ce paragraphe traite du nommage des Autorités de Certification Racine (ACR) des gammes de l’IGC-Santé et de celui des Autorités de Certification Intermédiaires (ACI) pour chacun des Domaines.

Nom gabarit DN d’un certificat racine

<GG>-ACR

c= FR

o= ASIP-SANTE

ou= 0002 187512751

ou= IGC-SANTE

cn= AC RACINE IGC-SANTE < Gamme >

Nom gabarit DN d’un certificat racine intermédiaire

<GG>-<DD>-ACI

c= FR

o= ASIP-SANTE

ou= 0002 187512751

ou= IGC-SANTE

cn= AC IGC-SANTE < Gamme > < Domaine >

Les noms des gabarits et les cn des autorités de certification sont composés :

en fonction de la gamme, <GG> et < Gamme > prend les valeurs suivantes : gamme Elémentaire : <GG> = « EL » < Gamme > = « ELEMENTAIRE »

gamme Standard : <GG> = « ST » < Gamme > = « STANDARD »

gamme Fort : <GG> = « FO » < Gamme > = « FORT »

en fonction du domaine, <DD> et < Domaine > prend les valeurs suivantes : domaine Personnes : <DD> = « PP » < Domaine > = « PERSONNES »

domaine Organisations : <DD> = « ORG » < Domaine > = « ORGANISATIONS »

Dans l’IGC-Santé, le domaine ORGANISATIONS n’est pas exploité (pas d’émission de certificat) en gamme STANDARD et en gamme FORT.

Pour distinguer l’autorité (ACI) qui a émis un certificat final, que ce soit dans le contexte des IGC-CPS ou de l’IGC-Santé, il faut uniquement se baser sur le DN de l’émetteur.

Cette règle s’applique également sur les IGC-CPS actuelles et doit, si ce n’est pas encore le cas, être prise en compte dans tout logiciel existant.

Note : Pour le schéma de nommage des Autorités de Certification de l’IGC-Santé de Test cf. § 11 « L’IGC-Santé de Test ».



3.2 Schéma de nommage des porteurs dans les certificats

Ce paragraphe traite du nommage des porteurs de certificats finaux (certificats « end-user »).

L’IGC-Santé distingue les porteurs de certificats finaux suivants :

Personnes physiques (Domaines Personnes) :

o Professionnel de Santé réglementé et Professionnel de Santé en Formation Un PS peut obtenir des certificats à titre personnel, indépendamment de toute activité professionnelle. Le DN contient uniquement l’identité nationale du porteur ;

o Professionnel de Santé réglementé et Professionnel de Santé en Formation rattaché à une structure Le DN contient l’identité nationale du porteur ainsi que celle de la structure à laquelle le porteur est rattaché (où il exerce une activité professionnelle) ;

o Personnel de structure Le DN contient l’identité nationale du porteur attribuée par la structure, ainsi que celle de la structure de l’employeur ;

o Carte de service attachée à une structure Etape 2 Le DN contient l’identité nationale du porteur, composé de l’identifiant de la structure et d’un identifiant interne au registre, et un pseudonyme. L’identifiant interne au registre et le pseudonyme sont attribués par la structure (la carte n’est pas détenue par une personne nominative). 3

Structures (Domaines Organisations) :

o Structure Le DN contient l’identité nationale de la structure ;

Dans la suite du présent document on distingue 2 catégories de structures :

o Les « structures santé ou social ». Exemples : Hôpitaux, cabinets libéraux, pharmacies, ….

o Les « structures autorisées » : ces structures ne prennent pas en charge des patients. Néanmoins, sur dossier, certaines structures peuvent être autorisées à demander des cartes de type CDA et CPA, ainsi que des certificats logiciels émis par l’IGC-Santé. Exemples : les hébergeurs de données de santé agréés et les organisations d’Assurance Maladie.

o Carte CPx – certificat CPx pour l’authentification sans contact Etape 2 Le DN est celui d’un certificat d’authentification sans contact, il est lié à l’objet carte et ne contient aucune information concernant son porteur, ni sa structure de rattachement.

Note :

L’authentification CPx en mode sans contact est basée sur des certificats techniques associés aux supports carte. Ils sont émis dans le Domaine Organisations de la Gamme Elémentaire et contiennent l’identité du support et non celle du porteur de la carte ni celle de la structure. L’identité du support ne peut être exploitée qu’au niveau d’une structure pour ses contrôles d’accès (logique et/ou physique). Chaque structure doit mettre en place son propre système pour enrôler ces supports et les lier à leur porteur légitime. 4

3 Pour les cartes de service rattachées à des structures libérales (cabinet, pharmacie, …), c’est l’ASIP-Santé qui

attribue des pseudonymes de type « Employé 01 ». 4 La CNIL interdit une base nationale qui permet de relier les identités des supports avec les identités nationales de

leurs porteurs.



3.2.1 Les DN des certificats de personnes physiques

Les tableaux ci-dessous montrent les différences de structure entre les DN de l’IGC-Santé et ceux des IGC-CPS, ces différences sont marquées en texte rouge.

1. PS ou PF non attaché à une structure

- Etape 1 : uniquement certificats logiciels

- Etape 2 : certificats embarqués dans les CPS et des CPF

DN IGC-CPS DN IGC-Santé

c= FR c= FR

o= GIP-CPS

ou= < Profession ou Future Profession > 5 title= < Profession ou Future Profession >

cn= < IdNat_PS > cn= < IdNat_PS >

sn= < nom d'exercice > sn= < nom d'exercice >

gn= < prénom usuel > gn= < prénom usuel >

2. PS ou PF attaché à une structure


- Etape 2 : non applicable aux certificats embarqués dans les cartes


c= FR c= FR

o= GIP-CPS

l= < Nom département (N°)> st= < Nom département (N°)>

o= < Raison sociale Structure >

ou= < IdNat_Struct > ou= < IdNat_Struct >

ou= < Profession ou Future Profession > title= < Profession ou Future Profession >




5 Il s’agit ici du libellé de la Profession ou de la Future Profession tels qu’ils sont définis dans la nomenclature

(Tables G15 et G16). Valable pour tous les DN des PS et PF.



3. Employé nominatif d’une structure


- Etape 2 : certificats embarqués dans les CDE, CPE, CDA et CPA nominatives


c= FR c= FR

o= GIP-CPS




title= < title > 6




4. Certificat de Carte de service ( = ex – « carte anonyme » )

- Etape 1 : non applicable

- Etape 2 : certificats embarqués dans les CPE et CPA non nominatives


c= FR c= FR

o= GIP-CPS




title = < title > 7


sn= < dénomination porteur > 8 pseudo= < dénomination porteur >

gn= < prénom usuel >

Notes :

Les attributs cn, sn et gn des personnes nominatives sont groupés dans un RDN composé ;

Les attributs cn et pseudo des cartes de service sont groupés dans un RDN composé ;

Les RDN composés dans l’IGC-Santé sont tous encodés selon le format DER de la norme ASN.1. Par conséquent, les attributs qu’ils contiennent sont triés selon les règles DER et peuvent apparaître dans un ordre différent de celui des tableaux ; Pour les certificats émis par les IGC-CPS2ter, l’ordre des RDN composés ne respectait pas toujours le format DER. Par conséquent, l’ordre dans le RDN composé pour un porteur donné peut changer lors du passage des IGC-CPS2ter vers l’IGC-Santé.

Le RDN « o=GIP-CPS » est dorénavant supprimé ;

Dans l’IGC-CPS2bis, les certificats de test contiennent « o=TEST » à la place de « o=GIP-CPS. Dans l’IGC-Santé, le DN du sujet ne permet plus de savoir s’il s’agit d’un certificat de production ou de test cf. § 11.3 « Comment distinguer un certificat de production d’un certificat de test ».

6 Renseigné selon le type de carte - CDE/CPE : « Personnel santé ou social », CDA/CPA : « Personnel autorisé ».

7 Renseigné selon le type de carte - CPE : « Carte de service santé ou social », CPA : « Carte de service autorisée ».

8 Dénomination porteur, exemples « Employé 01 », « Administrateur 02 », …



3.2.2 Les DN des certificats des structures

Les tableaux ci-dessous montrent les différences de structure entre les DN de l’IGC-ASIP-Santé et ceux des IGC-CPS, elles sont marquées en texte rouge.

1. Certificat applicatif d’une structure

- Etape 1 : certificats logiciels



c= FR c= FR

o= GIP-CPS




cn= < Nom applicatif > cn= < Nom applicatif >

Note concernant les certificats de structure :

Pour les certificats applicatifs de type « Serveur SSL », le cn (Nom applicatif) doit contenir un FQDN. Pour les autres certificats, ce nom peut être librement défini par son demandeur.

2. Certificat CPx pour l’authentification sans contact


- Etape 2 : certificats embarqués dans les CPx

DN IGC-Technique DN IGC-Santé

c= FR c= FR

o= ASIP-SANTE o= ASIP-SANTE

cn= < IAS Serial Number > cn= < IAS Serial Number >

Notes :

Les certificats CPx pour l’authentification sans contact dans les CPx déjà sur le terrain ne sont pas émis par une IGC-CPS mais par une IGC-Technique. Dans l’IGC-Santé, ces certificats sont signés par l’ACI Organisations de la gamme Elémentaire.

Gestion de certains attributs du DN par les applications Microsoft

Le RDN « pseudo » (pseudonym)

Microsoft ne reconnaît pas le RDN « pseudo ». Lors de l’affichage d’un certificat et

lors de la transformation d’un certificat en un chaîne de caractères, Microsoft

affiche/renseigne son OID : « 2.5.4.65 ».

Le RDN « st » (stateOrProvinceName) et « gn » (givenName)

Lors de l’affichage d’un certificat et lors de la transformation d’un certificat en un

chaîne de caractères, Microsoft affiche/renseigne « s » à la place de « st »

et « g » à la place de « gn ».



4 Impacts des DN IGC-Santé sur les recherches des porteurs dans l’Annuaire-CPS

Les certificats sont publiés quotidiennement dans l’Annuaire-CPS.

L’arborescence de l’Annuaire-CPS (cf. document [5] « ASIP_Annuaire-CPS_Schema DIT » 9), qui correspond à la structure des DN des certificats émis par les IGC-CPS, reste inchangée.

Par conséquent, les DN des certificats émis par l’IGC-Santé ne correspondent plus à l’arborescence de l’Annuaire-CPS.

4.1 Le DIT de l’Annuaire-CPS

Le schéma ci-dessous montre le DIT de l’Annuaire-CPS avec des exemples de certificats finaux émis par l’IGC-Santé.

Les textes en rouge mettent en évidence les différences entre le DIT de l’Annuaire-CPS et les DN des nouveaux certificats finaux :

Les certificats ne contiennent plus le RDN « o=GIP-CPS » ;

Pour les certificats PS et PF, la < (future) Profession > est dorénavant renseignée dans le RDN « title » ;

Pour les certificats des personnes dans les structures et les certificats de structure :

o Le < Département (N°) > est dorénavant renseigné dans le RDN « state » ;

o Ils contiennent un nouveau RDN « organisation » renseigné avec la < Raison sociale >.

« o=ASIP-SANTE » est déclaré comme un alias pour le nœud « o=GIP-CPS ». Même si les deux noms d’attribut peuvent être utilisés indifféremment il faut utiliser dorénavant « o=ASIP-SANTE ».

9 DIT = Directory Information Tree = Schéma d’Arborescence de l’annuaire

c=FR

ou=Médecin

o=GIP-CPS

(o=ASIP-SANTE)

locality=AIN (01) locality=Paris (75)

ou=<idNat_Struct 1> ou=<idNat_Struct 2>

ou=Pharmacien

cn=<idNat_PS>

gn=<prénom>

sn=<nom>

cn=<idNat_PS>

gn=<prénom>

sn=<nom>

Professions

Structures dans le département AIN

cn=<idNat_PS>

gn=Jean

sn=DUPONT

Personnel

de Structure

Départements

c=fr

title=Médecin

cn=<idNat_PS>

gn=Jean

sn=DUPONT

c=fr

state=AIN (01)

o=<Raison sociale>

ou=<idNat_Struct 1>

title=Personnel Santé Social

cn=<idNat_PS>

gn=Alain

sn=DECROIX

c=fr

state=AIN (01)

o=<Raison sociale>

ou=<idNat_Struct 1>

title=Médecin

cn=<idNat_PS>

gn=Jean

sn=DUPONT

Certificat de

Dr. Jean DUPONT

Certificat de

Dr. Jean DUPONT

Rattaché à une structure

Certificat de

Alain DECROIX

Personnel de structure

c=fr

state=AIN (01)

o=ASIPSANTE

ou=<idNat_Struct 2>

cn=serv1.asipsante.fr

Certificat SSL serveur

Nom = serv1.asipsante.fr

cn=serv1.asipsante.fr

c=fr

state=AIN (01)

o=<Raison sociale>

ou=<idNat_Struct 1>

title=Carte de Service

Pseudo=Employé 01

cn=<idNat_PS>

Certificat d’une

carte de service

Ces certificats ne sont paspubliés dans l’Annuaire-CPS

cn=<idNat_PS>

Pseudo=<pseudo>



Les certificats embarqués dans les CPS et les CPF sont publiés dans la Branche PS « (futurs) professionnels de santé » et également dans la Branche PE « personnel de structure » pour chaque activité déclarée du porteur dans une structure (pas de changement par rapport au fonctionnement actuel).

Comme pour les certificats des anciennes IGC, les certificats embarqués dans des Cartes de service et les certificats pour l’authentification du support carte sans contact ne sont pas publiés dans l’Annuaire-CPS. Les identifiants dans les Cartes de service n’étant pas nominatifs, il n’est pas possible de demander des certificats logiciels pour leurs porteurs.

4.2 Consignes de recherche dans l’Annuaire-CPS

Conseils pour des recherches dans l’Annuaire-CPS à partir des DN de l’IGC-Santé :

Une recherche LDAP avec un DN tel qu’il figure dans un certificat émis par l’IGC-Santé ne donnera plus de résultats. Il faut désormais faire les recherches LDAP en utilisant les RDN individuellement.

Les recherches utilisant uniquement les RDN « cn », « gn », « sn » pour les personnes et les RDN « cn » et « ou » pour les structures n’ont pas besoin d’être adaptées.

Pour les recherches sur un département, l’attribut « l » de la requête de recherche doit être valorisé par la valeur du RDN « st » du DN sujet du certificat.

Pour les recherches sur une profession, l’attribut « ou » de la requête de recherche doit être valorisé par la valeur du RDN « title » du DN sujet du certificat.

Il ne faut pas utiliser la Raison sociale comme critère de recherche LDAP car elle peut être modifiée ; seul l’identifiant national de la structure (IdNat_Struct) est garanti unique et stable dans le temps.

L’usage de la classe d’objet « cpsPersonne » ou « cpsStructuralPerson » permet de cibler respectivement la « Branche PS » contenant les PS en tant que professionnels hors structure ou la « Branche PE » 10 contenant toutes les personnes rattachées à une structure (PS et employés).

Les DN des certificats finaux émis par l’IGC-Santé ne correspondent plus au DIT (Directory Information Tree) de l’Annuaire-CPS actuel.

Il est donc nécessaire de vérifier toutes les requêtes LDAP et, si besoin, de les adapter pour garantir le bon fonctionnement des applications. Cette adaptation peut être faite dès maintenant car elle n’impacte pas les applications existantes.

Les clés uniques d’accès aux personnes physiques et aux structures sont leurs identifiants nationaux, respectivement IdNat_PS et IdNat_Struct.

10

« Branche PE » = « Branche Personnel d’Etablissement »



4.3 Détermination du type de porteur d’un certificat IGC-Santé

Types de certificats dont le porteur est une personne physique 1. PS et PF non rattachés à une structure

Le DN du porteur ne permet pas de déterminer s’il s’agit d’un (futur) professionnel car la nomenclature des professions peut évoluer. Pour cela il faut analyser les certificats des PS et PF qui contiennent respectivement une extension « Profession » et « Future Profession ». Leurs certificats ne contiennent pas une identification de structure (absence d’un RDN « ou » dans le DN du porteur). Ces certificats sont publiés dans la branche PS sous le nœud identifié par « ou=<(future) profession> » selon la (future) profession qui figure dans le « title » du certificat et dans une feuille correspondant au triplet « sn+gn+cn ».

2. PS et PF rattachés à une structure

Le DN du porteur ne permet pas de déterminer s’il s’agit d’un (futur) professionnel car la nomenclature des professions peut évoluer. Pour cela il faut analyser les certificats des PS et PF qui contiennent respectivement une extension « Profession » et « Future Profession ». Leurs certificats contiennent une identification de structure (présence d’un RDN « ou » dans le DN du porteur). Ces certificats sont publiés dans les structure où le PS ou le PF a une activité : dans la « Branche PE » sous le nœud identifié par l’IdNat_Struct de l’activité et dans une feuille correspondant au triplet « sn+gn+cn ».

3. Employés nominatifs d’une structure

Leurs certificats ne contiennent ni une extension « Profession », ni une extension « Future Profession ». Leurs certificats contiennent un RDN « title » dans le DN du porteur. Ces certificats sont publiés dans la branche PE sous le nœud identifié par l’IdNat_Struct de la structure et dans une feuille correspondant au triplet « sn+gn+cn ».

4. Cartes de service (étape 2)

Leurs certificats se distinguent par la présence d’un RDN « pseudo » dans le DN du porteur. Les certificats des Cartes de services sont les seuls certificats à ne pas être publiés dans l’Annuaire-CPS.

5. Cartes de directeurs de structure (étape 2)

Visuellement, les cartes des directeurs de structure portent toujours la mention « Directeur » au recto. Dans les certificats IGC-Santé, la qualité de directeur n’apparait pas. L’AC émettrice des certificats de directeurs de structure est la même que celle des certificats d’employés de structure.

Types de certificats dont le porteur est une personne morale

Ces certificats ne contiennent ni un RDN « title », ni un RDN « pseudo » dans le DN du porteur.



Les certificats finaux ne sont pas publiés dans l’Annuaire-CPS dans les cas suivants :

Demande du porteur du certificat (ou par un gestionnaire autorisé) de figurer sur la liste rouge,

Demande d’un gestionnaire d’une structure, que certains des certificats logiciels de sa structure ne soient pas publiés.

4.4 Détermination du type de certificat et/ou du type de carte CPx en IGC-Santé

En IGC-Santé, le type de certificat (logiciel ou embarqué sur carte CPx) et le type de carte ne peuvent pas être déduits de manière fiable par la seule analyse de l’AC émettrice. En effet :

L’AC « Gamme Elémentaire – Domaine Personnes » émet aussi des certificats logiciels.

L’ASIP Santé se réserve la possibilité d’émettre un jour certains types de cartes avec des certificats de gamme inférieure (des CPS/CPF en Elémentaire ou Standard, des CPE/CPA en Elémentaire).

Le type de certificat (logiciel ou carte CPx) est indiqué par l’extension productCategory11.

Le type de carte (CPE, CPA, CPS ou CPF) est indiqué par l’extension productType12.

Pour préciser le type de CPE/CPA :

Les CPE/CPA de service (anciennement appelées CPE/CPA anonymes) peuvent être identifiées par la présence d’un RDN « pseudo » dans le DN du porteur.

Les CPE/CPA nominatives peuvent être identifiée par la présence des RDN « givenName » et « surname » dans le DN du porteur.

Les CDE/CDA ne peuvent pas être distinguées des CPE/CPA nominatives par l’analyse du certificat.

11

Appelée CardCategory dans les IGC-CPS, mais il s’agit de la même extension (OID inchangé). 12

Appelée gipCardType dans les IGC-CPS, mais il s’agit de la même extension (OID inchangé).



5 Les produits de l’IGC-Santé

5.1 Les certificats de l’IGC-Santé – Etape 1

Les tableaux ci-dessous listent les certificats délivrés par l’IGC-Santé et, s’il existe, l’équivalent dans l’offre actuel de l’IGC-CPS2bis.

Certificats logiciels pour des personnes physiques :

Produits IGC-Santé - Etape 1

Description de l’usage

Produits correspondants dans

l’IGC-CPS2bis

Certificat de signature Il permet à son porteur de signer des

objets. N/A

Certificat d’authentification Il permet à son porteur de s’authentifier vis-à-vis d’un tiers, serveur distant ou

une autre personne physique. N/A

Certificat de confidentialité

Il permet à un utilisateur de chiffrer des données à destination du porteur de

certificat qui est le seul à pouvoir déchiffrer les données qui lui sont

destinées.

Certificat S/MIME de la Classe-5

de l’IGC-CPS2bis

Certificats logiciels de structure :


Description de l’usage

Produits correspondants dans

l’IGC-CPS2bis

Certificat cachet (signature)

Il permet à une personne morale de signer des objets.

N/A

Certificat d’authentification client

Il permet à une structure (personne morale) de s’authentifier vis-à-vis d’un tiers, un serveur ou une application.

N/A

Certificat de confidentialité Il permet à un utilisateur de chiffrer des données à destination d’une structure (personne morale), qui est la seule à pouvoir déchiffrer les données qui lui

sont destinées.

N/A

Certificat SSL (authentification serveur et

client)

Il permet à un serveur de s’authentifier vis-à-vis d’un tiers, un module client ou une personne physique, voire en tant que client à un autre serveur distant

Certificat SSL de la Classe-4

de l’IGC-CPS2bis.

certificat S/MIME (signature + chiffrement)

Il permet à un serveur de signer des objets et de déchiffrer les données qui

lui sont destinées.

Certificat S/MIME de la Classe-4

de l’IGC-CPS2bis.

Notes :

Les fonctions de séquestre et de recouvrement des clés privées de chiffrement ne sont pas assurées par l’IGC-Santé.

Grace aux nouveaux produits, l’IGC-Santé permet de répondre plus finement aux usages cryptographiques des applications actuelles et aux bonnes pratiques en limitant l’usage au strict nécessaire.



5.2 Les certificats de l’IGC-Santé – Etape 2

Le tableau ci-dessous liste les certificats CPx offerts par l’IGC-Santé et leur équivalent dans l’offre actuel de l’IGC-CPS2ter et l’IGC-Technique.

Certificats embarqués dans des cartes CPx :


Description de l’usage Produits correspondants

dans les IGC actuelles

Certificat de signature Il permet à son porteur de signer

des objets. Certificat de signature

IGC-CPS2ter

Certificat d’authentification

Il permet à son porteur de s’authentifier vis-à-vis d’un tiers,

serveur distant ou une autre personne physique.

Certificat d’authentification IGC-CPS2ter

Certificat d’authentification sans contact

Il permet l’authentification du support carte par des applications

locales dans des structures.

Certificat d’authentification sans contact

IGC-Technique

5.3 La taille des certificats de l’IGC-Santé

Attention

Les certificats de l’IGC-Santé sont plus volumineux

que ceux des anciennes IGCs (augmentation de 50 à 100%).

Ceci est notamment la conséquence l’augmentation de la taille des numéros de série

(passage de 4 à 16 caractères), de la taille des nouvelles structures des DN, la

présence de l’URL du répondeur OCSP ainsi que de l’augmentation des clés de

signature des autorités de certification.

Il est fortement recommandé aux éditeurs de ne pas programmer

la taille des certificats « en dur » dans leurs applications.



5.4 L’offre de services de la plateforme IGC-Santé

Les offres de services décrites dans ce paragraphe sont disponibles dès le début de la migration.

5.4.1 Services de demande et de révocation de certificats

Les demandes de certificats ainsi que leur révocation peuvent se faire :

via un portail internet ; le demandeur se connecte avec sa carte sur le service et, après authentification réciproque, est guidé dans le choix du type de certificat et le renseignement des données nécessaires. Après réception d’un mail indiquant la disponibilité du certificat, le demandeur peut se reconnecter sur le serveur pour le récupérer.

via une interface de type Webservice ; les fonctions de demande, retrait et révocation peuvent être intégrées dans une application métier via l’invocation d’un jeu de webservices.

via une interface mail, mails chiffrés et signés, au même format que les échanges actuelles pour demander/révoquer les certificats logiciels de l’IGC-CPS2bis. Cette interface est offerte pour faciliter la migration des applications l’exploitant à ce jour. Elle est limitée aux demandes et révocations de certificats dont les usages sont identiques à l’offre produits de l’IGC-CPS2bis :

o personnes physiques : certificats de confidentialité

o structures : certificats SSL et certificats S/MIME

Il est opportun de mettre en œuvre directement l’interface Webservice pour les demandes et révocation de certificats de l’IGC-Santé pour les raisons suivantes :

l’interface est pérenne dans le temps ;

l’interface est plus simple à mettre en œuvre ;

l’interface permet d’accéder à tous les services et produits offerts par la plateforme IGC-Santé.

Notes :

1. Les demandes des certificats de l’IGC-CPS2bis par l’interface mail actuelle (mails chiffrés et signés) resteront disponibles jusqu’à la date T1 (date à partir de laquelle l’IGC-CPS2bis ne délivrera plus de nouveaux certificats).

2. Les révocations des certificats de l’IGC-CPS2bis se feront par l’interface mail actuelle (mails chiffrés et signés) et ceci jusqu’à l’expiration du dernier certificat émis par l’IGC-CPS2bis.

Le tableau ci-dessous indique quelle adresse mail doit être utilisée selon l’IGC ciblée.

Type demande Adresses mail pour les

certificats CPS2bis Adresses mail pour les certificats IGC-Santé

demande d’un certificat

[email protected] [email protected]

révocation d’un certificat

[email protected] [email protected]

mailto:[email protected]






5.4.2 Services d’information sur l’état des certificats

Pour connaître l’état des certificats, l’IGC-Santé offre les services suivants :

Publication des listes de révocation (CRLs)

L’ASIP publie quotidiennement les CRLs de l’IGC-Santé à l’adresse indiquée dans les certificats (extension CRLDistributionPoints) ; une pour chaque ACR et une pour chaque ACI. Elles contiennent l’ensemble des certificats révoqués qui sont encore en période de validité (les certificats révoqués sont purgés des CRL dès que leur date d’expiration est atteinte). Les CRLs peuvent être téléchargées en mode HTTP ou LDAP.

Publication des listes delta de révocation (delta-CRLs)

Pour chaque ACI, l’ASIP publie simultanément avec une CRL et la delta-CRL correspondante à l’adresse indiquée dans les certificats (extension freshestCRL). Les delta-CRLs contiennent les certificats révoqués depuis la publication précédente permettant ainsi aux applications de consolider localement une CRL complète sans devoir charger les (volumineuses) CRLs quotidiennement. Les delta-CRLs sont stockées dans un attribut multivalué et peuvent uniquement être téléchargées en mode LDAP.

Répondeur OCSP (Online Certificate Status Protocol)

Les applications peuvent interroger le répondeur OCSP pour connaître le statut « validé/révoqué/inconnu » d’un certificat. Cf. : [15] RFC 6960 - X.509 Internet Public Key Infrastructure

Online Certificate Status Protocol – OCSP

Attention Etape 2

Les certificats d’authentification sans contact ne sont jamais révoqués.

Par conséquent, il ne faut jamais s’appuyer sur les services d’information sur l’état

des certificats (ni sur les CRL, ni sur le webservice OCSP) pour éviter d’accepter

à tort un tel certificat.

Les structures qui utilisent ces certificats doivent, lors de leur enrôlement, lier la validité

de ces certificats aux certificats d’authentification embarqués dans les cartes

correspondantes.

Si le certificat d’authentification embarqué dans une carte est révoqué, il faut

systématiquement bloquer le certificat d’authentification sans contact du même

support.

Attention Etapes 1 et 2

Les CRLs sont plus volumineuses

que celles des anciennes IGCs.

Ceci est la conséquence de la taille des numéros de série des certificats embarqués

dans les cartes CPx (passage de 4 à 16 caractères).

Il est fortement recommandé aux éditeurs de ne pas programmer

la taille des CRLs « en dur » dans leurs applications.



6 Correspondance entre les certificats des IGC actuelles et les produits de l’IGC-Santé

6.1 Certificats logiciels

Certains certificats émis par l’IGC-CPS2bis cumulent plusieurs usages cryptographiques ce qui n’est pas conforme aux bonnes pratiques qui préconisent de réserver un certificat à un usage unique.

Par conséquent, il n’est pas toujours souhaitable de reconduire les certificats actuels avec les mêmes usages dans l’IGC-Santé.

Les tableaux ci-dessous montrent pour chaque certificat de l’IGC-CPS2bis les options pour migrer vers un certificat de l’IGC-Santé qui correspond au mieux à l’usage effectif.

Rappel : Les certificats de la Classe-6 de l’IGC-CPS2bis sont repris dans une IGC gérée par le GIE SESAM-VITALE. Ils ne sont donc pas concernés par la migration décrite dans ce document.

6.1.1 Correspondances des certificats IGC-CPS2bis détenus par des personnes physiques

Certificats IGC-CPS2bis

Classe-5 - Personnes

Correspondance avec le certificat proposé par l’IGC-Santé

Gamme Elémentaire Domaine Personnes

Exemples usages terrain

Certificat S/MIME

(chiffrement) Certificat de confidentialité

Porteurs de carte utilisant une messagerie au standard S/MIME.

Attention :

La période de validité des certificats S/MIME émis par l’IGC-CPS2bis – Classe-5 est liée à la période de vie de la carte à laquelle elle est rattachée :

o début de validité = date/heure de la demande,

o fin de validité = date d’expiration de la carte du porteur.

La période de validité de tous les certificats logiciels émis IGC-Santé est fixée par l’IGC. Elle est donc indépendante de la période de validité de toute carte que le porteur détient.



6.1.2 Correspondances des certificats IGC-CPS2bis détenus par des structures

Pour chaque certificat IGC-CPS2bis de structure il existe plusieurs options pour le remplacer par un certificat de l’IGC-Santé.

Pour respecter les bonnes pratiques, il est conseillé de retenir le certificat dont l’usage correspond strictement aux besoins du terrain afin de limiter le risque d’un détournement d’usage.

Certificats IGC-CPS2bis

Classe-4 - Structures

Options pour migrer vers des certificats proposés par

l’IGC-Santé Exemples d’applications terrain

Certificat SSL

(authentification serveur + client)

Certificat authentification Client 13

(personne morale)

Proxies DMP des établissements

(Pour les clients SSL, l’usage « authentification serveur » n’est pas requis.)

Certificat authentification Serveur + Client

(serveur)

Serveurs spécifiques Secteur santé : - DMP-WS, Dossier Pharmaceutique, - Serveurs de messageries, …

Certificat S/MIME

(signature + chiffrement)

Certificat cachet (signature par personne morale)

Proxies DMP des établissements

(L’usage « chiffrement » n’est pas requis pour ces applications.)

Certificat de confidentialité (serveur)

Chiffrement de documents échangés entre des sites d'e-commerce en pharmacie et un service de gestion de données de santé

(L’usage « signature » n’est pas requis pour ces applications.)

Certificat S/MIME (Signature + chiffrement de mails)

(proxy ou application)

Structures avec un proxy pour la sécurisation de messages (au standard S/MIME).

Note : Les serveurs HTTP « grand public secteur santé » n’utilisent pas des certificats des IGC de l’ASIP. Ils utilisent des certificats d’Autorités de Certification « commerciales » car leurs certificats racines sont nativement présents dans les navigateurs (Verisign, Thawte, IGC/A, …).

13

La particularité de ces certificats clients et que le CN contient un « nom applicatif » choisi par le demandeur et qu’il n’est donc pas nécessaire de renseigner un FQDN et de faire valider par l’ASIP-Santé son droit d’usage.



6.2 Certificats embarqués sur carte CPx

Une carte CPx contient toujours les trois mêmes types de certificats dédiés aux mêmes usages :

Un certificat d’authentification associé au porteur.

Un certificat de signature associé au porteur.

Un certificat d’authentification associé à la carte, pour l’authentification sans contact.

Ils seront dorénavant tous émis par l’IGC-Santé. Les tableaux ci-dessous montrent la correspondance avec les IGC actuelles :

Certificats IGC-CPS2ter


Classe-0 (CPE et CPA anonyme)


Certificat de signature

Gamme Elémentaire – Domaine Personnes



Classe-2 (CDE et CDA)


Certificat de signature Gamme Standard – Domaine Personnes


Certificat de signature Classe-3 (CPE et CPA)



Classe-1 (CPS et CPF)



Gamme Fort – Domaine Personnes



Certificats IGC-technique


Certificat d’authentification (utilisable en sans contact)

Gamme Elémentaire – Domaine Organisations

Certificat d’authentification (utilisable en sans contact)



7 Cryptographie mise en œuvre par les différentes IGC

Dans le tableau ci-dessous sont listées les fonctions cryptographiques – algorithmes avec longueurs de clés et algorithmes de hachage – en fonction de chaque type de certificat.

IGC

(certificats émis)

Type de certificat

IGC-CPS2bis

(certificats logiciels) (Classe-4 à 6)

IGC-CPS2ter

(certificats CPS3) (Classe-0 à 3)

IGC-Technique

(certificats CPS3)

IGC-Santé

(certificats logiciels)

(certificats CPS3 dès l’Etape 2)

Certificat Racine (ACR)

RSA 2.048 bits

SHA-1

RSA 2.048 bits

SHA-1

RSA 2.048 bits

SHA-1

RSA 4.096 bits

SHA-2

Certificat d’Autorité

Intermédiaire (ACI)

RSA 2.048 bits

SHA-1

RSA 2.048 bits

SHA-1 NA

RSA 4.096 bits

SHA-2

Certificat utilisateur

RSA 1.024 bits

SHA-1

Signature RSA 2.048 bits

SHA-1

Authentification RSA 1.024 bits

SHA-1

NA RSA 2.048 bits

SHA-2

Certificat support authentification

sans contact NA NA

RSA 2.048 bits

SHA-1

RSA 2.048 bits

SHA-2

Avertissement concernant l’extension « key-usage » dans les certificats de

signature de l’IGC-Santé

Le key-usage des certificats de signature contient uniquement le bit « nonRepudation »

(le bit « digitalSignature » est supprimé pour ces certificats).

Toutefois, le key-usage des certificats « cachet » 14 contient les 2 bits

« nonRepudation » et « digitalSignature ».

Avertissement pour la mise en œuvre du produit F5 BIG-IP Global Traffic

Manager de la société F5 15

Si l’infrastructure cible utilise des équipements F5, la version de l’OS BIG-IP doit être

strictement supérieure à 12.x notamment pour tenir compte des spécificités des

IGC-CPS et pour être prête à exploiter les certificats émis par l’IGC-Santé (usage de

l’algorithme SHA-2).

cf. https://support.f5.com/kb/en-us/solutions/public/16000/500/sol16510.html

14

Les certificats « cachet » sont des certificats de signature destinés aux personnes morales. 15

Cet équipement permet notamment le HTTPS SSL Load Balancing.

https://support.f5.com/kb/en-us/solutions/public/16000/500/sol16510.html



8 Les différents cas d'usages cryptographiques Nous pouvons distinguer 3 cas d'usages cryptographiques :

authentification d'un serveur par un client (et authentification réciproque),

signature de données et vérification de la signature,

chiffrement et déchiffrement de données.

Dans les paragraphes suivants, le principe de fonctionnement de chaque cas d'usage est décrit sommairement ainsi que les risques de mauvais fonctionnement.

Pour une application donnée plusieurs cas d'usages peuvent coexister. L’éditeur doit alors respecter les principes de migration pour chaque cas d’usage mis en œuvre dans son application, afin d'éviter des interruptions de service.

8.1 Authentification d'un serveur par un client

Principe de fonctionnement d'une authentification simple - le client authentifie le serveur :

Le client se connecte sur le serveur qui présente son certificat d'authentification (certificat SSL) avec le certificat d’autorité intermédiaire qui a émis ce certificat et éventuellement le certificat racine correspondant;

Le client impose un défi au serveur qui doit le chiffrer avec sa clé privée ;

Le client vérifie la validité du certificat serveur et l'authenticité du serveur :

o il vérifie la période de validité et l'usage autorisé (extensions keyUsage et extendedKeyUsage 16

) du certificat d’authentification,

o s’il s’agit de la sécurisation d’une session SSL, il vérifie la correspondance entre le nom du domaine dans le certificat et le domaine dans l’URL du serveur ;

o il construit le chemin de confiance du certificat en exploitant :

le DN et l’identifiant de la clé émetteur dans le certificat de l’utilisateur pour trouver le certificat de l’autorité intermédiaire émettrice,

le DN et l’identifiant de la clé émetteur dans le certificat de l’autorité intermédiaire pour trouver le certificat de l’autorité racine qui doit être présent dans la base de confiance ;

o il vérifie si le certificat de l'autorité intermédiaire et si celui de la racine du chemin de confiance sont valides au moment de la vérification ;

o il vérifie la signature du certificat de l’autorité intermédiaire par l’autorité racine et sa non-révocation en s’appuyant sur les services d’information sur l’état des certificats ;

16

Cf. document [1] IGC-Santé – Etapes 1 et 2 - Les gabarits des certificats X.509 et des CRLs

Ensemble des

AC de confiance

Base de confiance

Certificat

URL + Défi

Réponse

Au défi

Vérification

certificat +

authenticité serveurKeystore

ClientServeur

Listes

de révocation

des certificats

Annuaire-CPS

Analyse certificat

Info certificat

(URL)Clé pub.

serveur



o il vérifie la signature du certificat d’authentification par l'autorité intermédiaire et sa non-révocation en s’appuyant sur les services d’information sur l’état des certificats.

Le client vérifie la réponse du serveur au défi après l’avoir préalablement déchiffrée à l’aide de la clé publique récupérée dans le certificat serveur.

Si toutes ces vérifications sont positives, le client peut faire confiance au serveur et autoriser les échanges.

Principe de fonctionnement d'une authentification réciproque :

Quand il y a authentification réciproque, le serveur authentifie également le client.

Le schéma ci-dessus est donc joué 2 fois « en miroir ».



8.2 Signature de données et vérification de la signature

Principe de fonctionnement :

Le signataire génère un hash des données à signer et chiffre ce hash avec sa clé privée afin d'obtenir la signature ;

Il adresse ensuite les données signées avec son certificat de signature au vérificateur avec le certificat de l'autorité intermédiaire et éventuellement celui de l’autorité racine ;

Le vérificateur recalcule le hash des données signées et récupère la clé publique dans le certificat reçu ;

Le vérificateur contrôle le certificat du signataire des données dès leur réception :

o il vérifie la période de validité et l'usage autorisé (extensions keyUsage et extendedKeyUsage) du certificat de signature ;




o il vérifie si le certificat de l'autorité intermédiaire et celui de la racine du chemin de confiance sont valides au moment de la vérification (leur signature, période de validité, usage autorisé, …) ;


o il vérifie la signature du certificat de signature par l'autorité intermédiaire et sa non-révocation en s’appuyant sur les services d’information sur l’état des certificats.

Il vérifie la signature en la déchiffrant avec la clé publique récupérée dans le certificat et en comparant ensuite ce résultat avec le hash recalculé.

Si toutes les vérifications sont positives, le client peut faire confiance à l'authenticité des données (intégrité et origine) et les prendre en compte dans son application.

Signataire Vérificateur

Données

validées

Vérification

Certificat +

signature

Données

signées

Données

à signer

Traitement

Signature

Ensemble des

AC de confiance

Hash +

Signature

Listes

de révocation

des certificats

Annuaire-CPS

Base de confiance

Keystore

Clé publique

signataire



8.3 Chiffrement et déchiffrement de données

Principe de fonctionnement :

Au préalable de toute émission chiffrée, l'émetteur doit récupérer le certificat de confidentialité du destinataire dans l'Annuaire-CPS (et éventuellement le stocker dans sa base de confiance locale). Les critères de recherche sont : l’identifiant du destinataire (IdNat_PS) avec éventuellement l’identifiant de son lieu d’exercice (IdNat_Struct) et son adresse mail s’il s’agit du chiffrement d’un mail S/MIME. Si la recherche retourne plusieurs certificats, l’application doit sélectionner le certificat le plus récent émis par une IGC dont le certificat racine se trouve dans le base de confiance de l’application.

Avant chaque utilisation d’un certificat de confidentialité du destinataire, l'émetteur doit vérifier sa validité (le certificat a pu expirer ou être révoqué depuis sa dernière utilisation) :

o il vérifie la période de validité, l'usage autorisé (extensions keyUsage et extendedKeyUsage) du certificat de confidentialité ;




o il vérifie si le certificat de l'autorité intermédiaire et celui de la racine du chemin de confiance sont valides au moment de la vérification ;


o il vérifie la signature du certificat de confidentialité par l'autorité intermédiaire et sa non-révocation en s’appuyant sur les services d’information sur l’état des certificats.

Il génère ensuite une clé de session symétrique avec laquelle il chiffre les données ;

Puis il chiffre la clé de session avec la clé publique récupérée dans le certificat de confidentialité du destinataire ;

Il expédie ensuite les données chiffrées, la clé de session chiffrée ainsi que le certificat de confidentialité contenant la clé publique du destinataire ;

Le destinataire récupère dans le certificat de confidentialité le DN et l’identifiant de la clé publique (extension subjectKeyId) pour déterminer quelle clé privée de confidentialité il doit utiliser (il peut en disposer de plusieurs) pour déchiffrer la clé de session et ensuite déchiffrer les données reçues.

Données

chiffrées

Destinataire Emetteur

Certificats Conf

+

Listes

de révocation

des certificats

Annuaire-CPS

@

mail

Données

en clair

Vérification

certificat

Données

en clair

Chiffrement

Déchiffrement

Ensemble des

AC de confiance

+ Certificats Conf

Base de confiance

Keystore

Clé publique

destinataire



9 Impacts de la migration sur les applications terrain

La migration vers l’IGC-Santé nécessite les évolutions suivantes sur les serveurs, les applications centrales et les logiciels sur les postes client :

ajout des chaînes de confiance de l’IGC-Santé dans les bases de confiance des applications (serveurs et poste de travail),

prise en compte de la nouvelle cryptographie de l’IGC-Santé :

Cf. § 7« Cryptographie mise en œuvre par les différentes IGC ».

o vérification et, si besoin, adaptation des traitements cryptographiques des clés privées (signature, authentification et/ou déchiffrement) et des fonctions de hachage,

o vérification et, si besoin, adaptation des procédures de vérification des certificats des interlocuteurs,

o mise en œuvre des services d’information sur l’état des certificats de l’IGC-Santé.

certificats de l’IGC-CPS2bis – Classe-4 :

Etape 1, jusqu’à la date T1 :

o renouvellement des certificats émis par l’IGC-CPS2bis par des certificats équivalents de l’IGC-Santé.

o renouvellement possible des certificats émis par l’IGC-CPS2bis dans la même IGC pour allonger le délai de migration,

Etape 1, après la date T1 :

o renouvellement de ces certificats émis par l’IGC-CPS2bis par des certificats équivalents de l’IGC-Santé.

certificats de confidentialité de l’IGC-CPS2bis – Classe-5 :

Etape 1, jusqu’à la date T1 :

o renouvellement possible des certificats émis par l’IGC-CPS2bis liés à des cartes CPx (voir conditions au § 10.5 « Porteurs détenant des certificats de confidentialité (S/MIME) émis par l’IGC-CPS2bis – Classe-5 »),

Etape 1, après la date T1 :

o renouvellement de ces certificats émis par l’IGC-CPS2bis par des certificats équivalents de l’IGC-Santé.

certificats d’authentification sans contact :

Dès l’Etape 1 et avant le début de l’Etape 2 : ajout des chaînes de confiance de l’IGC-Santé – Gamme Elémentaire / Domaine Organisations – dans les équipements acceptant la carte CPx et dans la procédure d’enrôlement.



9.1 Les risques fonctionnels liés au déploiement des certificats émis par l’IGC-Santé

1. Les bases de confiance des vérificateurs ne sont pas à jour avec les chaînes de confiance de l’IGC-Santé.

2. Incapacité de traiter des clés RSA de 2.048 et 4.096 bits, notamment pour la vérification des certificats émis par l’IGC-Santé.

3. Incapacité de traiter la fonction de hachage SHA-2, notamment pour la vérification des certificats émis par l’IGC-Santé.

4. Une application métier santé qui n’a pas encore été adaptée pour prendre en compte les fonctionnalités de l’IGC-Santé risque d’être incapable de communiquer avec des interlocuteurs qui ont déjà migré :

impossibilité de vérifier les certificats émis par l’IGC-Santé,

impossibilité d’authentifier des interlocuteurs utilisant des certificats IGC-Santé,

impossibilité de signer un objet avec un certificat par l’IGC-Santé,

impossibilité de vérifier les signatures faites en utilisant des certificats IGC-Santé,

impossibilité de chiffrer vers des interlocuteurs disposant de certificats IGC-Santé.

5. Incapacité pour certaines applications, en particulier les serveurs applicatifs, d’être capables de gérer une cohabitation terrain durant laquelle certains interlocuteurs ont déjà migré et d’autres fonctionnent encore avec des certificats émis par les IGC-CPS.

6. Incapacité technique pour gérer plusieurs chaines de confiance simultanées.

7. Incapacité de charger les (delta-)CRLs pour les applications qui utilisent des URL « programmées en dur ». Les URL peuvent changer dans le temps ce qui impose une exploitation dynamique des extensions dans les certificats finaux qui contiennent les URL pour charger les CRL (crlDistributionPoint) et celles pour charger les delta-CRL (freshestCRL).

8. Incapacité de retrouver des certificats émis par l’IGC-Santé dans l’annuaire-CPS si les consignes présentées dans le § 4.2 « Consignes de recherche dans l’Annuaire-CPS » n’ont pas été respectées.

Attention

Dans les cas des applications dans le domaine Santé-social, il faut privilégier

l’utilisation d’un certificat Serveur SSL de l’IGC-Santé.

Il y a une seule exception : lorsqu’un serveur sécurise uniquement ses liens avec des

clients équipés de navigateurs du marché, il est recommandé d’utiliser un certificat SSL

d’une IGC commerciale (Verisign, Thawte, …) car les chaînes de confiance des

IGC-CPS et IGC-Santé ne sont pas nativement présentes dans les bases de confiance

des navigateurs

Attention

Avec l’augmentation de la taille de clés RSA et l’ajout de nouvelles extensions, la taille

de certificats augmente considérablement : jusqu’à plus d’1 Koctets supplémentaire.



9.2 Contraintes liées aux algorithmes des IGC-CPS

L’utilisation de la fonction de hachage SHA-1 étant déconseillée depuis plusieurs années par l’ANSSI et ses homologues à l’étranger, le support de cette fonction est progressivement abandonné par les produits du marché.

Le navigateur Chrome affiche déjà un message d’alerte lorsqu’un certificat serveur signé avec fonction de hachage SHA-1 est valable au-delà du 1er janvier 2017. Ce message n’empêche toutefois pas d’aller sur le site en mode SSL en acceptant le message d’alerte.

Attention

Pendant la période de migration (Etapes 1 et 2) et jusqu’à l’expiration des 2 IGC-CPS

(fin 2020), les nouvelles configurations doivent être capables de gérer les certificats

des IGC-CPS signés avec une clé RSA (1.024 et 2.048 bits) et la fonction de hachage

SHA-1, faute de quoi il y a un risque de refus des certificats émis par ces IGC.

Attention

Il est recommandé aux éditeurs de migrer au plus vite car plusieurs produits risqueront

de ne plus supporter le SHA-1 à court terme.



10 Les consignes de migration

10.1 Serveur avec un certificat SSL IGC-CPS2bis – Classe-4 – Cas d’authentification simple

L’authentification des serveurs est réalisée par l’application client (navigateur ou client lourd).

Les implémentations sur les serveurs ont en commun qu’elles utilisent toujours la même clé d’authentification de leur Keystore et présentent donc toujours le certificat correspondant aux clients. Il est effectivement impossible de présenter un certificat en fonction de la configuration de chaque client.

Selon le contexte applicatif il y a 2 scénarios de migration pour le certificat serveur :

Scénario 1 : Le gestionnaire d’application maîtrise les évolutions de son serveur et de l’ensemble des postes client (exemple : une application interne à un hôpital). Il doit d’abord (faire) migrer l’ensemble des postes client puis son serveur pour assurer une interruption de service minimale.

Scénario 2 : Le gestionnaire d’application maîtrise les évolutions de son serveur mais ne peut pas faire évoluer les postes client sur le terrain de façon simultanée (exemple : serveur offrant des services à tous les médecins libéraux).

Les consignes de migration pour ces 2 scénarios sont décrites dans les 2 paragraphes suivants.

10.1.1 Authentification simple - Consignes de migration – Scénario 1

Migration des postes client

Les postes client doivent pouvoir fonctionner avec des serveurs qui ont ou n’ont pas encore migrés.

1. mise à jour de tous les postes client pour qu’ils acceptent indifféremment des certificats serveur de l’IGC-CPS2bis et de l’IGC-Santé :

o Dans le cas le plus simple, le progiciel exploite la base de confiance de l’OS. L’installation d’une CryptoLib-CPS récente y ajoute les chaînes confiance de l’IGC-Santé (et les ajoute également dans celle de Firefox si cette application est présente). Pour les progiciels qui gèrent leur propre base de confiance, il faudra ajouter les chaînes de confiance de l’IGC-Santé selon les modalités prévues par ces progiciels ;

o Mise en place des services d’information sur l’état des certificats de l’IGC-Santé pour la vérification de la « non-révocation » des certificats serveur ;

2. adaptation, si besoin, pour que les postes clients fonctionnent correctement avec des clés RSA de 4.096 et de 2.048 bits ainsi qu’avec la fonction de hachage SHA-2 ; Si ces mêmes postes sont amenés à se connecter sur d’autres serveurs SSL qui utilisent encore des certificats serveur émis par l’IGC-CPS2bis, ils doivent toujours pouvoir fonctionner correctement avec des clés RSA de 1.024 bits ainsi qu’avec la fonction de hachage SHA-1.



Migration du serveur (après la mise à jour de tous les postes client) :

ajouter dans la configuration les paramètres permettant de gérer les clés RSA de 4.096 bits et la fonction de hachage SHA-2 ;

demander un certificat Serveur SSL, gamme Elémentaire, à l’IGC-Santé pour l’installer avec son chemin de confiance et la clé privée correspondante dans le Keystore du serveur (à la place de la clé privée et son certificat serveur SSL de l’IGC-CPS2bis).

Attention

En cas d’échec – si certains postes s’avèrent ne pas être compatibles avec le nouveau

certificat serveur – le gestionnaire d’application doit être capable de revenir à

l’ancienne configuration du serveur (réinstallation de l’ancienne clé serveur SSL) le

temps de mettre ces derniers postes à jour.

Il est donc indispensable de sauvegarder l’ancienne clé privée du serveur SSL avant

l’installation de la nouvelle clé privée avec son certificat sur le serveur.



10.1.2 Authentification simple - Consignes de migration – Scénario 2

Dans beaucoup d’applications, le gestionnaire d’application ne maîtrise pas le rythme d’évolution des postes client sur le terrain.

Il est alors impératif que le serveur soit capable pendant la période de migration de gérer simultanément ses clients actuels (dont les postes n’ont pas encore été mis à jour pour fonctionner avec les certificats IGC-Santé) et ceux dont les postes ont été mis à jour.

Cette situation impose que le serveur gère 2 points d’entrée différents (2 (sous)domaines) soit l’URL existante dédiée à l’authentification avec un certificat serveur SSL IGC-CPS2bis et une nouvelle URL dédiée à l’authentification avec un certificat serveur SSL émis par l’IGC-Santé :

les clients non mis à jour continuent à utiliser l’URL existante,

les clients dont les postes ont été mis à jour doivent utiliser la nouvelle URL.

Migration d’un serveur SSL

Pour migrer un serveur SSL, le gestionnaire d’application doit respecter la séquence des actions suivantes :

1. Sur le point d’entrée existant :

renouvellement éventuel du certificat serveur SSL émis par l’IGC-CPS2bis pour se donner plus de temps pour la migration. Si le certificat expire avant T2, il est possible de le renouveler. Cela doit alors être réalisé au plus tard à T1, soit avant que l’IGC-CPS2bis entre en fin de vie. Le nouveau certificat aura une durée de vie de 3 ans. Ce renouvellement est transparent pour les clients du serveur.

2. Création d’un nouveau point d’entrée avec une URL dédiée :

créer un nouveau point d’entrée avec la même configuration que le point d’entrée existant, notamment avec la base de confiance contenant les chaînes de confiance des IGC-CPS, mais en supprimant la clé serveur SSL émis par l’IGC-CPS2bis du Keystore ;


demander un certificat Serveur SSL, gamme Elémentaire, à l’IGC-Santé pour l’installer avec son chemin de confiance et la clé privée correspondante dans le Keystore du serveur.

3. Après la mise en place du nouveau point d’entrée :

Le gestionnaire du serveur doit informer ses clients qu’ils peuvent migrer et accéder au nouveau point d’accès.

Il est opportun suivre l’avancement de la migration en comparant le trafic sur chaque point d’entrée.

A l’approche de la date d’expiration de son certificat SSL IGC-CPS2bis, le gestionnaire devra s’organiser pour prévenir ses clients qui n’ont pas encore migré afin de leur éviter un blocage applicatif.

4. Après expiration du certificat serveur de l’ancien point d’entrée :

Il est conseillé de maintenir l’ancien point d’entrée du serveur au moins jusqu’à l’expiration de son certificat émis par l’IGC-CPS2bis. A la fin de la migration (plus d’appels de clients) ou à la date d’expiration de son certificat serveur émis par l’IGC-CPS2bis, l’ancien point d’entrée devra être fermé.



Pour éviter un blocage applicatif lors de l’expiration des 2 IGC-CPS (notamment Apache pour sa gestion des CRLs), il faut planifier pour fin décembre 2020 au plus tard :

o la suppression des chaînes de confiance des 2 IGC-CPS de la base de confiance du serveur,

o l’arrêt du chargement quotidien des (delta-)CRLs.

Avertissement pour la migration des serveurs SSL mettant en œuvre le

mécanisme « SNI » 17

Le point 2 ci-dessus traite de la création d’un nouveau point d’entrée avec une URL

dédiée. Cette création d’un nouveau point d’entrée peut être réalisée de plusieurs

façons :

les 2 URLs du téléservice sont déployées sur 2 adresses IP différentes (dans

ce cas la mise en œuvre du mécanisme SNI n’est pas requis) ;

les 2 URLs du téléservice sont déployées sur 2 hôtes virtuels différents sur

une seule adresse IP, les clients devront être compatibles avec le mécanisme

« SNI ».

La mise en œuvre du mécanisme « SNI » sur un serveur SSL implique donc que tous

ses clients (navigateurs, clients webservices, …) soient compatibles.

A titre d’exemple est listé ci-dessous, quelques applications avec leurs versions

minimum requises pour être compatibles avec SNI :

Internet Explorer 7 (ceci exclut IE sur Windows XP),

Mozilla Firefox 2,

Google Chrome :

o Windows XP avec Chrome 6,

o Windows Vista avec Chrome 6,

o OS X 10.5.7 avec Chrome 5.0.342.0,

Safari 2.1 (pré-requis : OS X 10.5.6 ou Windows Vista),

Openssl 0.9.8,

Java avec JDK Oracle 1.7.0_80,

Tomcat 8.5,

Apache http 2.2.12,

PHP 5.3.

Il est de la responsabilité du gestionnaire d’application de vérifier si tous ses

clients sont compatibles SNI avant de mettre ce mécanisme en œuvre.

17

Server Name Indication (SNI), qui peut se traduire par « indication du nom du serveur ». C’est une extension du protocole TLS1. Avec l'extension SNI, le client indique le nom d'hôte (hostname) avec lequel il tente de démarrer une négociation TLS. Cela permet au serveur de présenter plusieurs certificats pour la même adresse IP (mais avec des noms d'hôte différents), et donc de mutualiser des hébergements pour des sites sécurisés en https. (source Wikipédia).



Migration des postes client sur le terrain

Les clients sur le terrain migreront progressivement, cela implique :

que les clients qui n’ont pas encore migré continuent à utiliser l’URL du point d’entrée existant (ils ne peuvent vérifier que les certificats serveur émis par l’IGC-CPS2bis).

que les clients dont les postes ont été mis à jour se connectent sur le 2ème point d’entrée du serveur dès qu’ils sont autorisés par le gestionnaire d’application.

La mise à jour d’un client consiste à réaliser les actions suivantes :

1. Mise à jour du poste client pour qu’il accepte indifféremment des certificats serveur de l’IGC-CPS2bis et de l’IGC-Santé :


o Mise en place des services d’information sur l’état des certificats de l’IGC-Santé pour la vérification de la « non-révocation » des certificats serveur,

2. Adaptation, si besoin, pour que les postes clients fonctionnent correctement avec des clés RSA de 4.096 et de 2.048 bits ainsi qu’avec la fonction de hachage SHA-2 ; Si ces mêmes postes sont amenés à se connecter sur d’autres serveurs SSL qui utilisent encore des certificats serveur émis par l’IGC-CPS2bis, ils doivent toujours pouvoir fonctionner correctement avec des clés RSA de 1.024 bits ainsi qu’avec la fonction de hachage SHA-1.



10.2 Serveur avec un certificat SSL IGC-CPS2bis – Classe-4 – Cas d’authentification réciproque

L’authentification des clients par ces serveurs est réalisée :

soit par un proxy du marché (basé sur OpenSSL ou produit équivalent) installé en frontal par rapport aux applications à sécuriser,

soit directement par l’application (exploitant des modules OpenSSL ou autres).

Ces implémentations ont en commun qu’elles utilisent toujours la même clé d’authentification de leur Keystore et présentent donc toujours le certificat correspondant à celle-ci aux clients. Il est effectivement impossible de présenter un certificat en fonction de la configuration de chaque client.

Lors de la période de migration, l’application sur le serveur doit pouvoir authentifier des clients équipés avec :

des certificats logiciels émis par l’IGC-CPS2bis,

des certificats logiciels émis par l’IGC-Santé – clients migrés en Etape 1,

des certificats embarqués dans les CPx émis par l’IGC-CPS2ter,

des certificats embarqués dans les CPx émis par l’IGC-Santé – clients migrés en Etape 2 .

Selon le contexte applicatif il y a 2 scénarios de migration pour le certificat serveur :

Scénario 1 : Le gestionnaire d’application maîtrise les évolutions de son serveur et de l’ensemble des postes client (exemple : une application interne à un hôpital). Il doit d’abord (faire) migrer l’ensemble des postes client puis son serveur pour assurer une interruption de service minimale.

Scénario 2 : Le gestionnaire d’application maîtrise les évolutions de son serveur mais ne peut pas faire évoluer les postes client sur le terrain de façon simultanée (exemple : serveur offrant des services à tous les médecins libéraux).

Les consignes de migration pour ces 2 scénarios sont décrites dans les 2 paragraphes suivants.

10.2.1 Authentification réciproque - Consignes de migration – Scénario 1

Migration des postes client :

Les postes client doivent pouvoir fonctionner avec le serveur avant et après sa migration.

1. Mise à jour de tous les postes client pour qu’ils acceptent indifféremment des certificats serveur de l’IGC-CPS2bis et de l’IGC-Santé :






3. Après la migration du serveur, les clés privées et les certificats logiciels sur les clients peuvent être renouvelées dans l’IGC-Santé au fur et à mesure qu’ils arrivent à expiration. Toutes les CPx (nouvelles et renouvelées) émises à partir du début de l’Etape 2 contiendront des certificats embarqués émis par l’IGC-Santé.

Migration du serveur (après mise à jour de tous les postes client) :

1. ajouter les chaînes de confiance de l’IGC-Santé dans la base de confiance du serveur ;

2. si besoin, adaptation pour que le serveur fonctionne correctement avec des clés RSA de 4.096 et de 2.048 bits et avec la fonction de hachage SHA-2 pour la vérification des certificats de ses clients.

Si ce serveur est amené à authentifier des clients qui utilisent encore des certificats logiciels émis par l’IGC-CPS2bis ou des clients porteurs de cartes CPx, il doit toujours pouvoir fonctionner correctement avec des clés RSA de 1.024 bits et avec la fonction de hachage SHA-1.

3. demander un certificat Serveur SSL, gamme Elémentaire, à l’IGC-Santé pour l’installer avec son chemin de confiance et la clé privée correspondante dans le Keystore du serveur (à la place de la clé privée et son certificat serveur SSL IGC-CPS2bis).

Attention

En cas d’échec – si certains postes s’avèrent ne pas être compatibles avec le nouveau

certificat serveur – le gestionnaire d’application doit être capable de revenir à

l’ancienne configuration du serveur (réinstallation de l’ancienne clé serveur SSL) le

temps de mettre ces derniers postes à jour.

Il est donc indispensable de sauvegarder l’ancienne clé privée du serveur SSL avant

l’installation de la nouvelle clé privée avec son certificat sur le serveur.



10.2.2 Authentification réciproque - Consignes de migration – Scénario 2

Dans beaucoup d’applications le gestionnaire d’application ne maîtrise pas le rythme d’évolution des postes client sur le terrain.

Il est alors impératif que le serveur soit capable pendant la période de migration de gérer simultanément ses clients actuels (dont les postes n’ont pas encore été mis à jour pour fonctionner avec les certificats IGC-Santé) et ceux dont les postes ont été mis à jour.

Cette situation impose que le serveur gère 2 points d’entrée différents (2 (sous)domaines) soit l’URL existante dédiée à l’authentification avec un certificat serveur SSL IGC-CPS2bis et une nouvelle URL dédiée à l’authentification avec un certificat serveur SSL émis par l’IGC-Santé :

les clients non mis à jour continuent à utiliser l’URL existante,

les clients dont les postes été mis à jour devront utiliser la nouvelle URL.

Migration du serveur SSL

Pour migrer le serveur SSL, le gestionnaire d’application doit respecter la séquence des actions suivantes :

1. Sur le point d’entrée existant :

renouvellement éventuel du certificat serveur SSL émis par l’IGC-CPS2bis pour se donner plus de temps pour la migration. Si le certificat expire avant T2, il est possible de le renouveler. Cela doit alors être réalisé au plus tard à T1, soit avant que l’IGC-CPS2bis entre en fin de vie. Le nouveau certificat aura une durée de vie de 3 ans. Ce renouvellement est transparent pour les clients du serveur ;

pour que le serveur puisse authentifier tous ses clients :

o maintenir les chaînes de confiance des IGC-CPS dans la base de confiance ;

o maintenir le chargement quotidien des (delta-)CRLs ACI et ACR des IGC-CPS pour la vérification de la « non-révocation » des certificats client ;

o ajouter les chaînes de confiance de l’IGC-Santé dans la base de confiance ;

o mettre en place les services d’information sur l’état des certificats de l’IGC-Santé. o s’assurer que le serveur fonctionne correctement avec des clés RSA de 4.096, 2.048

bits et de 1.024, bits ainsi qu’avec les fonctions de hachage SHA-1 et SHA-2 pour la vérification des certificats des clients ;

2. Création d’un nouveau point d’entrée avec une URL dédiée :

créer un nouveau point d’entrée avec la même configuration que le point d’entrée existant, notamment avec la base de confiance contenant chaînes de confiance des IGC-CPS, mais en supprimant la clé serveur SSL émis par l’IGC-CPS2bis du Keystore ;


demander un certificat Serveur SSL, gamme Elémentaire, à l’IGC-Santé pour l’installer avec son chemin de confiance et la clé privée correspondante dans le Keystore du serveur ;

installer les chaînes de confiance de l’IGC-Santé dans la base de confiance ;

mettre en place les services d’information sur l’état des certificats client de l’IGC-Santé.

maintenir le chargement quotidien des (delta-)CRLs ACI et ACR des IGC-CPS pour la vérification de la « non-révocation » des certificats client.



3. Après la mise en place du nouveau point d’entrée :

autoriser les postes client à migrer et accéder au nouveau point d’accès.

Il est opportun suivre l’avancement de la migration en comparant le trafic sur chaque point d’entrée.

A l’approche de la date d’expiration de son certificat SSL IGC-CPS2bis, le gestionnaire devra s’organiser pour prévenir les clients qui n’ont pas encore migré afin de leur éviter un blocage applicatif.

4. Après expiration du certificat serveur de l’ancien point d’entrée :

Il est conseillé de maintenir l’ancien point d’entrée du serveur au moins jusqu’à l’expiration de son certificat émis par l’IGC-CPS2bis. A la fin de la migration (plus d’appels de clients) ou à la date d’expiration de son certificat serveur émis par l’IGC-CPS2bis, l’ancien point d’entrée devra être fermé.

Pour éviter un blocage applicatif lors de l’expiration des 2 IGC-CPS (notamment Apache pour sa gestion des CRLs), il faut planifier pour fin décembre 2020 :

o la suppression des chaînes de confiance des IGC-CPS de la base de confiance du serveur,

o l’arrêt du chargement quotidien des (delta-)CRLs.

Migration des postes client sur le terrain

Il faut distinguer les migrations clients suivantes :

Etape 1 : migration des clients avec des certificats serveur logiciels émis par l’IGC-CPS2bis,

Etape 2 : migration des clients, porteurs de cartes avec des certificats d’authentification embarqués dans leurs CPx.

Les clients sur le terrain migreront progressivement, cela implique :

que les clients qui n’ont pas encore migré continuent à utiliser l’URL du point d’entrée existant (ils ne peuvent vérifier que les certificats serveur émis par l’IGC-CPS2bis).

que les clients dont les postes ont été mis à jour sont à jour se connectent sur le 2ème point d’entrée du serveur dès qu’ils sont autorisés par le gestionnaire d’application.

Les mises à jour des clients sont décrites pas les paragraphes suivants :

dans le § 10.3 pour les clients détenant des certificats SSL émis par l’IGC-CPS2bis – Classe-4 ;

dans le § 10.6 pour les clients acceptant des cartes CPS avec des certificats embarqués émis par l’IGC-CPS2ter



10.3 Serveurs et clients détenant des certificats SSL émis par l’IGC-CPS2bis – Classe-4

Les certificats « Serveur SSL » émis par l’IGC-CPS2bis ont aujourd’hui un double usage :

usage classique d’un serveur applicatif qui sécurise avec SSL/TLS les échanges avec ses clients,

usage par un client applicatif pour se connecter sur un serveur SSL/TLS. Actuellement, les clients applicatifs développés dans le contexte du secteur de la santé disposent des certificats « Serveur SSL » émis par l’IGC-CPS2bis pour lesquels l’usage « serveur » n’est pas utilisé (ex. les proxies hospitaliers pour l’application DMP).

Pour le premier cas, le renouvellement du certificat avec l’IGC-Santé se fait en conservant le même usage.

Pour le deuxième cas, les clients applicatifs ont intérêt à demander des « certificats d’authentification client » de l’IGC-Santé dont la commande est plus simple. En effet, pour ces certificats il n’est plus nécessaire de renseigner un FQDN dans le DN sujet avec toutes les vérifications que cela induit ; un simple nom d’application choisi par le gestionnaire local suffit (exemple « Proxy DMP Hôpital du Parc »).

Consignes de migration pour les clients

Comme on peut le lire dans le § 10.1, les gestionnaires des serveurs SSL peuvent prendre des mesures pour donner plus de temps aux éditeurs des logiciels « métier santé » pour faire évoluer leur logiciel et (faire) installer la mise à jour sur les postes client sur le terrain (renouvellement des certificats serveur et mise en place d’un 2ème point d’entrée).

La mise à jour d’un client consiste à réaliser les actions suivantes :

1. mise à jour du poste client pour qu’il accepte indifféremment des certificats serveur de l’IGC-CPS2bis et de l’IGC-Santé :




3. Après la migration de tous les serveurs sur lesquels les clients se connectent, les clés privées et les certificats logiciels sur les clients peuvent être renouvelées dans l’IGC-Santé au fur et à mesure qu’ils arrivent à expiration. Toutes les CPx (nouvelles et renouvelées) produites à partir du début de l’Etape 2 contiendront des certificats émis par l’IGC-Santé.

Lors de l’installation d’un logiciel « métier santé » sur le poste il est nécessaire de demander un certificat authentification client à l’IGC-Santé gamme Elémentaire pour l’installer avec la clé privée et la chaîne de confiance correspondante dans le Keystore du client,

Attention Les clients ne doivent pas activer cette nouvelle version du logiciel avant que le(s) serveur(s) ai(en)t ouvert leur 2ème point d’entrée sécurisé par un certificat serveur émis par l’IGC-Santé.



10.4 Porteurs détenant des certificats S/MIME émis par l’IGC-CPS2bis – Classe-4

Les certificats S/MIME émis par l’IGC-CPS2bis – Classe-4 permettent de signer et de chiffrer.

Selon l’usage de ce certificat, le gestionnaire de l’application peut demander un des 3 certificats suivants :

Certificat cachet Si le certificat ne sert qu’à signer des objets par une personne morale.

(L’usage « chiffrement » n’est donc pas requis.)

Certificat de confidentialité Si le certificat ne sert qu’à déchiffrer des données qui lui sont adressées.

(L’usage « signature » n’est donc pas requis.)

Certificat S/MIME Si le certificat sert aux 2 usages cités ci-dessus comme par exemple pour la messagerie sécurisée S/MIME.

10.4.1 Consignes de migration vers un « certificat cachet »

Consignes de migration pour les signataires :

Les éditeurs des logiciels « métier santé » doivent faire évoluer leurs logiciels et les distribuer sur les postes et les serveurs sur le terrain.

Cette évolution pour la fonction de signature consiste à :

o ajouter les chaînes de confiance de l’IGC-Santé dans la base de confiance,

o adapter leur processus de signature et vérifier la compatibilité cryptographique avec des clés RSA de 4.096 bits et la fonction de hachage SHA-2.

Lors de l’installation du logiciel sur le poste client ou le serveur il est nécessaire :

o de demander un certificat cachet à l’IGC-Santé gamme Elémentaire pour l’installer avec la clé privée et la chaîne de confiance correspondante dans le Keystore du client,

Afin que de donner plus de temps pour la migration aux destinataires des objets signés, il est conseillé de renouveler le certificat S/MIME émis par l’IGC-CPS2bis. Le renouvellement doit se faire avant T1, date à laquelle l’IGC-CPS2bis entre en fin de vie. Le nouveau certificat aura une durée de vie de 3 ans. Tant que le(s) gestionnaire(s) d’application n’a(ont) pas informé les signataires que tous les destinataires sont capables de traiter de signatures IGC-Santé, il faut continuer d’utiliser les certificats S/MIME émis par l’IGC-CPS2bis.



Consignes de migration pour les vérificateurs de signatures :

Les éditeurs des logiciels « métier santé » doivent faire évoluer leurs logiciels et les distribuer sur les postes sur le terrain.

Cette évolution pour la fonction de vérification de signature consiste à :


o adapter leur processus de vérification de signature et vérifier la compatibilité cryptographique avec des clés de RSA de 1.024, 2.048 et 4.096 bits et les fonctions de hachage SHA-1 et SHA-2. Le processus de vérification doit être capable de vérifier aussi bien les signatures faites par des certificats émis par l’IGC-CPS2bis que celles faites par des certificats émis par l’IGC-Santé.

o mettre en place les services d’information sur l’état des certificats de l’IGC-Santé pour la vérification de la « non-révocation » des certificats.

Attention

Les signataires ne doivent pas utiliser des clés de signatures IGC-Santé avant d’y être

autorisé par le gestionnaire de l’application ; un vérificateur dont le poste n’a pas été

mis à jour ne sera pas capable de vérifier une signature IGC-Santé.

10.4.2 Consignes de migration vers un « certificat de confidentialité »

L’entité qui chiffre les données, l’« émetteur », doit utiliser la clé publique contenue dans le certificat du « destinataire », qui utilise sa clé privée pour le déchiffrement.

Avant tout émission de données chiffrées, l’émetteur doit vérifier le certificat du destinataire afin de vérifier s’il n’est pas expiré ou révoqué.

Attention

Dans le cadre d’échanges entre entités distinctes, il est fortement conseillé de limiter

l’usage du certificat de confidentialité à la sécurisation des échanges (mails,

webservices, …). Si l’utilisateur souhaite chiffrer localement les données reçues, il est

recommandé que les mécanismes de chiffrement soient décorrelés de ceux utilisés

pour sécuriser le transfert.

Pour garantir la confidentialité des données stockées en local, dans un SI, une base de

données ou dans un système d’archivage, il existe des produits dédiés qui, outre le

chiffrement et la gestion des droits d’accès, proposent des procédures de

recouvrement éprouvées en cas de perte de clés de chiffrement.

Consignes de migration pour les destinataires (qui déchiffrent) :

Les éditeurs des logiciels « métier santé » doivent faire évoluer leurs logiciels et les distribuer sur les postes clients et les serveurs sur le terrain.

Cette évolution pour la fonction de chiffrement consiste à :


o adapter leur processus de chiffrement et vérifier la compatibilité cryptographique avec des clés RSA de 4.096, 2048 et 1.024 bits et les fonctions de hachage SHA-1 et SHA-2.



Lors de l’installation du logiciel sur le poste ou le serveur il est nécessaire :

o de demander un certificat de confidentialité à l’IGC-Santé gamme Elémentaire pour chaque certificat IGC-CPS2bis détenu et installer ces certificats avec leurs clés privées et leurs chaînes de confiance dans le Keystore du client destinataire,

o si c’est une nouvelle installation ou si le certificat S/MIME IGC-CPS2bis actuel expire avant T2, de demander un (nouveau) certificat de confidentialité à l’IGC-CPS2bis pour donner plus de temps aux émetteurs pour migrer. Cette demande doit être faite avant T1.

o le destinataire doit conserver toutes ses clés de confidentialité et les certificats correspondants au moins jusqu’à leur expiration (valable pour l’IGC-CPS2bis et l’IGC-Santé).

Attention 1

Chaque destinataire doit garder ses anciennes clés privées et les certificats

correspondants pour pouvoir déchiffrer des données qui lui ont déjà été transmises et

qui avaient été chiffrées avec ses anciennes clés IGC-CPS2bis.

Attention 2

Un émetteur qui n’a pas migré ne pourra pas chiffrer des données vers un destinataire

qui n’a qu’un certificat émis par l’IGC-Santé.

Consignes de migration pour les émetteurs (qui chiffrent vers des destinataires) :

Les éditeurs des logiciels « métier santé » doivent faire évoluer leurs logiciels et les distribuer sur les postes sur le terrain.

Cette évolution pour la fonction de chiffrement consiste à :

o ajouter les chaînes de confiance de l’IGC-Santé dans la base de confiance ;

o adapter leur processus de chiffrement et vérifier la compatibilité cryptographique avec des clés RSA de 2.048 et 4.096 bits et la fonction de hachage SHA-2. Le processus de chiffrement doit être capable de vérifier aussi bien les certificats émis par l’IGC-CPS2bis que ceux émis par l’IGC-Santé ;

o lors d’une recherche d’un certificat de confidentialité dans l’Annuaire-CPS (critère = l’identité nationale du destinataire ou une adresse mail), la réponse peut contenir plusieurs certificats. L’émetteur doit retenir le certificat le plus récent émis par l’IGC-Santé s’il la supporte, sinon le certificat le plus récent émis par l’IGC-CPS2bis ;

o mettre en place les services d’information sur l’état des certificats de l’IGC-Santé pour la vérification de la « non-révocation » des certificats.

Attention

Un poste qui n’a pas encore migré sera incapable de chiffrer des données vers un

destinataire qui n’a plus un certificat S/MIME valide émis par l’IGC-CPS2bis.

10.4.3 Consignes de migration vers un « certificat S/MIME »

Puisque les certificats S/MIME émis par l’IGC-CPS2bis – Classe-4 permettent de signer et de chiffrer les impacts de migration cumulent les consignes et contraintes décrites dans § 10.4.1 « Consignes de migration vers un « certificat cachet » » et § 10.4.2 « Consignes de migration vers un « certificat de confidentialité » ».



10.5 Porteurs détenant des certificats de confidentialité (S/MIME) émis par l’IGC-CPS2bis – Classe-5

Les certificats de confidentialité S/MIME émis par l’IGC-CPS2bis – Classe-5 sont détenus par des porteurs de CPx, ils permettent de déchiffrer les données reçues avec leur clé privée. Plusieurs certificats de confidentialité peuvent être rattachés à une CPx (un certificat par adresse mail à sécuriser).

Par conséquent, les consignes et contraintes décrites dans § 10.4.2 « Consignes de migration vers un « certificat de confidentialité » s’appliquent.

Toutefois, les émetteurs qui n’ont pas encore migrés vers l’IGC-Santé – donc incapables de traiter les certificats émis par l’IGC-Santé – ne pourront plus chiffrer des données vers un destinataire si ce dernier n’a pas/plus de certificats de confidentialité IGC-CPS2bis valides.

Pour donner plus de temps aux émetteurs pour migrer vers l’IGC-Santé 18 il peut être nécessaire que les destinataires demandent de nouveaux certificats de confidentialité IGC-CPS2bis avec une durée de vie supérieure à leurs certificats de confidentialité actuels.

Comme indiqué dans le § 6.1.1, la fin de vie d’un certificat S/MIME émis par l’IGC-CPS2bis – Classe-5 est identique à celle de la CPx à laquelle il est rattaché, par conséquent, il est inutile de demander un nouveau certificat de confidentialité à l’IGC-CPS2bis avec la même carte car ce nouveau certificat aurait la même date d’expiration que celui qu’il remplacerait.

Il est donc conseillé au porteur d’un certificat IGC-CPS2bis – Classe-5 de demander un renouvellement anticipé de sa CPx si elle expire avant T2. Cette demande de renouvellement de sa CPx doit se faire au moins 1 mois avant T1, date limite pour demander des certificats IGC-CPS2bis.

Après réception de sa nouvelle carte, le porteur devra renouveler tous ses certificats de confidentialité avant T1. Les dates d’expiration de ces nouveaux certificats seront donc identiques à celles de la nouvelle carte, soit, selon le type de carte, 3 à 5 ans après le début de validité de la carte.

Attention

La période de validité des certificats S/MIME émis par l’IGC-CPS2bis – Classe-5 est

liée à la période de vie de la carte à laquelle elle est rattachée (cf. § 6.1.1).

La période de validité de tous les certificats de confidentialité émis par l’IGC-Santé est

fixe (3 ans).

Cela implique que pour gérer le renouvellement des certificats de confidentialité émis

par l’IGC-Santé l’application doit dorénavant se baser sur la date de l’expiration de ces

certificats.

18

Les émetteurs utilisent le certificat de confidentialité du destinataire pour chiffrer les données.



10.6 Postes de travail acceptant des cartes CPx

A partir du début de l’Etape 2, toutes les nouvelles cartes contiendront des certificats embarqués émis par l’IGC-Santé.

Pour anticiper l’arrivée de ces cartes, il est nécessaire de mettre à jour les différents logiciels qui les exploitent :

les navigateurs utilisés pour les authentifications réciproques,

les logiciels « métier santé » pour les usages d’authentification et signature.

10.6.1 Consignes de migration pour les navigateurs

1. mettre à jour tous les navigateurs pour qu’ils acceptent indifféremment des certificats serveur de l’IGC-CPS2bis et de l’IGC-Santé :

o Cette mise à jour peut se faire par l’installation d’une CryptoLib-CPS récente qui ajoute les chaînes de confiance de l’IGC-Santé dans la base de confiance du système et également dans celle de Firefox si cette application est présente ;

o Pour vérifier la « non-révocation » des certificats serveur, il est conseillé de mettre en place les services d’information sur l’état des certificats de la gamme Elémentaire de l’IGC-Santé sur les postes client.

2. s’assurer que les navigateurs fonctionnent correctement avec des clés RSA de 2.048 et de 4.096 bits ainsi qu’avec la fonction de hachage SHA-2 pour la vérification des certificats serveur. Si ces mêmes postes sont amenés à se connecter sur des serveurs qui utilisent encore des certificats SSL émis par l’IGC-CPS2bis, ils doivent toujours pouvoir fonctionner correctement avec des clés RSA de 1.024 bits ainsi qu’avec la fonction de hachage SHA-1.

10.6.2 Consignes de migration pour les progiciels

1. mettre à jour tous les progiciels pour qu’ils acceptent indifféremment des certificats embarqués émis par l’IGC-CPS2ter et par l’IGC-Santé :


o Le progiciels doit vérifier la validité temporelle et les usages autorisées des certificats d’authentification et de signature mais n’a pas besoin de vérifier la « non-révocation » des certificats car cela est du ressort des accepteurs (serveurs et applications recevant des objets signés).

2. s’assurer que les postes clients fonctionnent correctement avec des clés RSA de 4.096, 2.048 et de 1.024 bits ainsi qu’avec les fonctions de hachage SHA-1 et SHA-2 pour la vérification des certificats serveur. Tant que ces mêmes postes sont amenés à fonctionner avec des CPx contenant des certificats émis par l’IGC-CPS2ter, ils doivent pouvoir fonctionner correctement avec des clés RSA de 1.024 bits ainsi qu’avec la fonction de hachage SHA-1.



Attention

A partir de l’Etape 2, les clés RSA et les certificats IGC-Santé correspondants seront

uniquement chargés dans le « Volet IAS » de la CPx.

Le « Volet CPS2ter » de la carte n’offrira donc plus de fonctions cryptographiques.

Ceci implique la mise en œuvre d’une version minimale de la Cryptolib, le détail est

fourni dans le paragraphe qui suit.

10.6.3 Consignes relatives à la Cryptolib

Pour assurer le bon fonctionnement des cartes CPx contenant des certificats IGC-Santé, la version 5 de la CryptoLib doit être mise en œuvre pour l’usage sur le poste de travail de l’utilisateur final et les librairies déclarées comme obsolètes ne doivent plus être invoquées par les logiciels.

L’ASIP Santé effectuant des publications régulières de nouvelles versions de la Cryptolib, la préconisation est d’utiliser la version la plus à jour possible. A la date de publication de ce document, les versions de Cryptolib à prendre en compte sont listées dans le tableau suivant :

Système d’exploitation Version de Cryptolib

Windows 5.0.33

MacOs 5.0.30

Linux 5.0.9

Les publications de nouvelles versions sont accessibles en utilisant le lien suivant :

http://integrateurs-cps.asipsante.fr/logiciels_cps (*)

Pour les progiciels, il faut aussi s’assurer que les librairies obsolètes ne sont plus utilisées. La liste de ces librairies est fournie dans le document référencé [11] disponible en utilisant le lien suivant :

http://integrateurs-cps.asipsante.fr/documents/Composants-v4-obsoletes-Cryptolib-CPS-v5.0 (*)

(*) Accès restreint, un compte utilisateur est nécessaire pour accéder à ces informations

http://integrateurs-cps.asipsante.fr/logiciels_cps

http://integrateurs-cps.asipsante.fr/documents/Composants-v4-obsoletes-Cryptolib-CPS-v5.0



10.7 Consigne commune à tous les cas d’usage

La fin de vie effective des IGC-CPS est le 31 décembre 2020. A cette date, tous les certificats émis auront expirés. Il ne sera alors plus utile de charger leurs (delta-)CRLs car elles ne contiendront plus de certificats révoquées.

Attention

Toutes les applications émettrices devront supprimer les chaînes de confiance des

IGC-CPS de leurs bases de confiance et arrêter le chargement des (delta-)CRLs

correspondantes au plus tard le 31 décembre 2020 au risque de bloquer les serveurs19

et/ou les postes de travail.

19

Certains proxies, dont OpenSSL, consolident toutes les CRL chargées et risquent de bloquer le processus si une CRL n’est plus disponible ou expirée.



11 L’IGC-Santé de Test

Pour des besoins de tests et de recette de l'IGC-Santé, ainsi que pour les tests d'intégration dans les applications terrain, une IGC-Santé de Test est créée avec exactement la même architecture que l’IGC-Santé de Production.

11.1 Schéma de nommage des AC de Test

Les DN des ACR et ACI de Test se distinguent par les RDN « cn » et « ou » qui contiennent le mot « TEST ».

Nom gabarit DN des Autorités de Certification de Test

<GG>-ACR DN du certificat racine <Gamme>

c= FR

o= ASIP-SANTE

ou= 0002 187512751

ou= IGC-SANTE TEST

cn= TEST AC RACINE IGC-SANTE <Gamme>

<GG>-<DD>-ACI DN du certificat racine intermédiaire

c= FR

o= ASIP-SANTE

ou= 0002 187512751

ou= IGC-SANTE TEST

cn= TEST AC IGC-SANTE < Gamme > < Domaine >

Une application doit détecter les certificats et CRLs de Test en vérifiant si le « cn » de l’autorité émettrice commence par « TEST ».

11.2 Différences entre les certificats de Production et les certificats de Test

Les certificats de test se distinguent sur les points suivants :

1. Les DN des autorités émettrices (DN Issuer des ACR et ACI) de Test :

Leur 2ème RDN « ou » finit par le mot « TEST » (IGC-SANTE TEST).

Leur RDN « cn » commence par le mot « TEST ».

Cf. § 11.1 « Schéma de nommage des AC de Test ».

2. L'extension « certificatePolicies » :

Chaque certificat de Production contient un OID spécifique, faisant référence à la PC du gabarit.

Tous les certificats de Test contiennent un OID unique. Cet OID fait référence à une PC couvrant l'ensemble des certificats de test de l'IGC-Santé.



3. L’extension « productCategory » :

Cette extension, sur 1 octet hexadécimal, indique la catégorie de produit : CPx, module de sécurité, certificat logiciel, ...

Dans les certificats de Production, le bit de poids fort de sa valeur est égal à '0' (valeurs '00', '02', '03', …).

Dans les certificats de Test, le bit de poids fort de sa valeur est égal à '1' (valeurs '80', '82', '83', …).

4. Les URL dans les certificats :

Tous les URL sont spécifiques par extension, par gabarit et pour les certificats de Production et de Test, sauf pour l'URL du serveur OCSP qui est identique pour tous les certificats finaux.

Cf. [1] « IGC-Santé – Etapes 1 et 2 - Les gabarits des certificats X.509 et des CRLs » pour les points 2 à 4.

11.3 Comment distinguer un certificat de production d’un certificat de test

Contrairement aux IGC-CPS actuelles, le DN sujet ne permet plus de savoir s’il s’agit d’un certificat de production ou de test.

La méthode préconisée pour distinguer les certificats end-user de Production des certificats de Test est la suivante :

1. Récupération du DN de l’ACI émetteur,

2. Analyse du DN de l’ACI émetteur, si le RDN « cn » commence par les 4 caractères « TEST » il s’agit d’un certificat de test (cf. § 3.1 et § 11.1).

Les certificats de test sont publiés dans l’Annuaire-CPS selon les mêmes règles annoncées dans le paragraphe précédent à la différence qu’ils sont accrochés au nœud « O=TEST ».

Attention 1

Il n'y a rien dans le DN sujet qui permet de distinguer les certificats de Production de

ceux de Test !

Attention 2

Les applications de Production (serveurs et postes de travail) ne doivent jamais

charger des certificats AC de Test dans leurs bases de confiance.



12 Les cartes embarquant des certificats IGC-Santé

12.1 Comment distinguer une carte embarquant des certificats IGC-Santé

Extérieurement, les cartes embarquant des certificats IGC-Santé sont semblables aux précédentes.

Visuellement, les deux seuls signes distinctifs pour identifier une carte embarquant des certificats IGC-Santé sont les suivants :

1/ Au recto, une date d’émission plutôt qu’une date de fin de validité.

2/ Au verso, la lettre B au milieu de la référence de fabrication de la carte.

12.2 Autres nouveautés

Les cartes embarquant des certificats IGC-Santé présentent d’autres nouveautés :

quelques changements graphiques au verso,

l’identifiant national du porteur en code barre21 à la place du pavé de signature au verso,

le support de Mifare Classic 1K.

Attention, ces nouveautés ne sont pas des signes distinctifs. Les dernières cartes émises contenant des certificats des IGC actuelles pourront en bénéficier.

21

L’identifiant national du porteur correspond à la valeur affichée au-dessus du nom, au verso de la carte, sans les espaces. Exemple avec la carte présentée en exemple : la valeur encodée est « 500000000038836/CPAT001 ».



12.3 Le code d’assistance

Les codes envoyés aux porteurs des cartes IGC-Santé sont :

Comme pour les cartes IGC-CPS2ter actuelles : o Un code confidentiel (PIN). o Un code de déblocage (PUK).

Un code d’assistance à utiliser pour l’identification auprès du support client de l’ASIP Santé (utilisé en remplacement de la communication des trois premiers chiffres du code de déblocage pour les porteurs de cartes IGC-CPS2ter).



13 Glossaire et Définitions

13.1 Glossaire

AC Autorité de Certification

ACI Autorité de Certification Intermédiaire

ACR Autorité de Certification Racine

CRL Certificate Revocation List, liste des certificats révoqués

deltaCRL Les CRLs et delta-CRLs sont publiées simultanément. Une delta-CRL ne contient que les certificats qui ont été révoqués depuis la publication de la dernière CRL.

CPx Ce sigle désigne toute carte de la famille CPS

DIT Directory Information Tree (X.500)

DN Distinguished Name = Identifiant d’un acteur dans le certificat Dans un certificat il y un « DN émetteur » et un « DN porteur ».

ETSI European Telecommunications Standards Institute

ETSI TS 101 456 Norme, élaboré dans le cadre de la directive européenne 1999/93/CE du 13 décembre 1999 pour un cadre commun pour les signatures électroniques, fixe les règles relatives à l'utilisation des signatures électroniques et à leur reconnaissance au sein de l'Union Européenne.

IETF The Internet Engineering Task Force

IGC Infrastructure de Gestion de Clés

LCR Liste des Certificats Révoqués = CRL Terme non utilisé dans ce document

LPS Logiciel de Professionnel de Santé

RDN Relative Distinguished Name

RFC Request For Comments – standard internet publié par l’IETF

RGS Référentiel Général de Sécurité

cf. http://www.ssi.gouv.fr/entreprise/reglementation/administration-electronique/le-referentiel-general-de-securite-rgs/

http://www.ssi.gouv.fr/entreprise/reglementation/administration-electronique/le-referentiel-general-de-securite-rgs/

http://www.ssi.gouv.fr/entreprise/reglementation/administration-electronique/le-referentiel-general-de-securite-rgs/



13.2 Définitions

Application : ensemble de logiciels distribués sur des équipements (serveurs et/ou postes)

offrant un service.

Exemples : Dossier Pharmaceutique, Historique de remboursements, Outils de

Sécurisation de Messagerie (S/MIME), …

IGC : une Infrastructure de Gestion de Clefs est un ensemble de composants physiques (des

ordinateurs, des équipements cryptographiques ou HSM, des cartes à puces), de

procédures humaines (vérifications, validations) et de logiciels (système et application)

ayant pour but de gérer le cycle de vie des certificats électroniques.

IGC-CPS : ce terme désigne les 2 IGC actuelles : IGC-CPS2bis et l’IGC-CPS2ter.

IGC ASIP : ce terme désigne, selon le contexte une des ou toutes les IGC gérées par

l’ASIP-Santé : IGC-CPS2bis, l’IGC-CPS2ter et l’IGC-Santé.

Certificat : c'est une pièce d'identité électronique dont l'objet est de lier une entité physique

(personne ou serveur) à une entité numérique (virtuel). Il est émis par une autorité de

certification qui fait fonction de tiers de confiance et qui atteste du lien entre l'identité

physique et l'entité numérique.

Un certificat contient, outre l'identité du porteur, sa clé publique et les usages autorisés

(signature, chiffrement, …)

certificat racine (ACR) : c'est le certificat qui atteste l'identité de l'autorité de

certification. Il est auto-signé ce qui explique que l'introduction d'un tel certificat

dans une base de confiance nécessite une validation explicite par l'administrateur

d'un système.

certificat intermédiaire (ACI) : c'est le certificat qui atteste l'identité d'une « sous-

autorité de certification » responsable de la signature des certificats finaux pour une

classe donnée. Il est signé par le certificat racine de l'autorité de certification.

Certificat final : c'est une identité numérique dont le porteur est une personne ou

une structure. Dans l'IGC-Santé, un tel certificat est signé par l'autorité intermédiaire

responsable du domaine de certificats à laquelle il appartient.

Certification ETSI : vérification de la conformité à ETSI TS 101 456 « Policy requirements

for certification Authorities issuing qualified certificates »

Chaîne de confiance : une chaîne de confiance d’un certificat final est constituée du

certificat d’autorité intermédiaire (qui a signé le certificat final) et du certificat racine

correspondant.

Chemin de confiance : le chemin de confiance d'un certificat contient : le certificat

lui-même, le certificat de l'autorité intermédiaire ainsi que le certificat racine.

Il est construit dynamiquement à partir du certificat à vérifier jusqu'au certificat racine en

exploitant les noms des émetteurs des certificats et leurs identifiants des clés.



Base de confiance : c'est un « coffre-fort », sous le contrôle de l'administrateur de

l'équipement, qui contient tous les certificats (racine, intermédiaire et serveur) auxquels

l'administrateur a donné sa confiance. Une base de confiance peut être gérée directement

par un OS (exemples : les navigateurs natifs de Windows et de MacOS) ou par un logiciel

donné (exemples : Firefox, messagerie sécurisée S/MIME, Apache/OpenSSL, …).

Keystore : c'est un « coffre-fort », sous le contrôle de l'administrateur de l'équipement, qui

contient tous les clés privées ainsi que les certificats associés.

Identification : déclinaison de l’identité d'une personne, chaque identité devant être sans

équivoque.

Authentification : vérification de l’identité annoncée par une personne sur la base

d’éléments de preuve.

Signature : objet, joint à un document, garantissant l'identité et l’engagement du signataire

vis-à-vis de son contenu. La signature électronique garantit également l'intégrité du

document.

Intégrité : propriété assurant que des données n'ont pas été altérées dans le temps ou lors

d’un transfert (modification, ajout ou suppression).

Chiffrement : transformation réversible d’un document, d’un message ou d’un flux de

données afin de le rendre inintelligible par des tiers non autorisés.