PGSSI-S - esante.gouv.fr, le portail de l`ASIP Santé

Transcription

ASIP Santé
PGSSI-S – Authentication of healthcare actors
06/06/16
PGSSI-S : Politique générale de sécurité des systèmes
d’information de santé
Authentication of healthcare actors
V 2.0
December 2014
Classification : Public
1 / 26
ASIP Santé
06/06/16
Table of Contents
1
Purpose .......................................................................................................................... 3
2
Scope of Application ....................................................................................................... 4
3
Goals for the authentication of health actors ................................................................... 4
4
Definition of authentication actors ................................................................................... 6
4.1
Authentication .......................................................................................................... 6
4.2
Healthcare Actor ...................................................................................................... 6
4.3
Scope of an identifier ............................................................................................... 6
4.4
Authentication Factors ............................................................................................. 6
4.5
Authentication Type ................................................................................................. 7
4.6
Direct Authentication ................................................................................................ 7
4.7
Authentication Architectures (indirect or by proxy) ................................................... 7
5
Levels of authentication for health actors ........................................................................ 9
5.1
Public authentication levels ...................................................................................... 9
5.1.1
Public Authentication Level 2 ............................................................................ 9
5.1.2
Level 3 Public Authentication .......................................................................... 10
5.2
Private authentication levels .................................................................................. 15
5.2.1
Level 1 private authentication ......................................................................... 15
5.2.2
5.2.3
5.2.4
Baseline rules for the implementation of private authentication ....................... 16
6
Summary of authentication mechanisms ....................................................................... 17
7
Industry relevance......................................................................................................... 18
8
Impact on professional practices ................................................................................... 18
9
APPENDIX 1 – Specification and terms of use for authentication mechanisms ............. 19
9.1
CPS smartcard authentication ............................................................................... 19
9.2
Legal entity software certificate authentication ....................................................... 20
9.3
Individual software certificate authentication .......................................................... 22
9.4
OTP Authentication mechanisms ........................................................................... 24
10 Appendix 2 - Glossary ................................................................................................... 25
11 Appendix 3 – Referenced Documents ........................................................................... 26
2 / 26
ASIP Santé
06/06/16
1 Purpose
This document contains the reference specification for the authentication of healthcare actors,
as defined in the Politique générale de sécurité des systèmes d’information de santé (PGSSI).
It is part of the PGSSI-S technical reference documentation as illustrated in the document
architecture below.
Figure 1 PGSSI-S Reference Architecture
This reference specification defines the mechanisms used to authenticate a healthcare actor,
individual or legal entity to a Health Information System (SIS).
The goals of authentication are described in references #2 and 4 (as listed in Appendix 3 –
Referenced documents).
This security function is intended for health actors, individuals or legal entities, as identified in
the Identification of health and community health actors specification (reference 1).
There are two types of authentication of a healthcare actor:
public authentication: Authentication is called public when the authentication mechanisms
used are linked to national identifiers (or public IDs)1 and that their use is not limited to
specifically identified information systems. Public authentication mechanisms are further defined
in this document.
private authentication: Authentication is called private when it is limited as per the following
criteria:
1
as defined in the Identification of health and community health actors specification (reference 1).
3 / 26
ASIP Santé
06/06/16
1. The authentication mechanism requires a local registration step to associate the
health actor’s identifier with the specified system and provide the actor with the
authentication credentials for the system. The identifier used can be either a
national or local identifier. Verification of the health actor’s identity is the
responsibility of the person in charge of allocating the authentication credentials
(such as, but not limited to, the director of operations or their delegate).
2. The authentication mechanism (e.g. certificate) is specified by director of
operations for that system, based on risk analysis
This document is intended for directors of operation who need to define or select the acceptable
authentication mechanisms and how they will be used, as well as those acting under their
responsibility and involved in the implementation of health information systems security policies.
It is also intended for providers of products or services used in the context of health systems.
Providers must offer solutions that implement the features and implementation constraints
identified in this specification.
2 Scope of Application
The table below summarizes the scope of application of the specification for the authentication
of health actors.
Health
Clinical Care
Care provider
support
functions
Care
Coordination



Public
Health
Research
Screening and
Prevention
Community
Health
Notes
This version of the specification is applicable in the healthcare context noted above. The scope of
application will be expanded in a later version of the repository.
The employment status of the healthcare actors or the lifecycle of the data have no bearing on the
applicability of defined mechanisms.
3 Goals for the authentication of health actors
The development of e-health services and reduction of paper-based medical and community
health services will not be effective until the requirements for creating and maintaining the trust
of stakeholders are met.
The quality of the authentication of healthcare professionals is one of the pillars of this trust.
The authentication of an actor is part of the foundation for securing health information systems
and enabling:



granting access to authorized persons;
differentiating the possible types of access to services and health data according to the
rights associated with the identity of these users;
attribution of actions to their author.
4 / 26
ASIP Santé
06/06/16
The quality of authentication of a healthcare actor is therefore the key enabler for successful
access control.
5 / 26
ASIP Santé
06/06/16
4 Definition of authentication actors
4.1 Authentication
The Référentiel Général de Sécurité (RGS) defines authentication as follows: "The goal of
Authentication is to verify the identity claims of a person or a machine (where identification is the
provision of a previously recorded identity, and authentication is the provision of proof of
identity. Authentication is usually preceded by identification)"2
The security level of an authentication function is linked to:


the level of the identifier used and its assigning process (assurance that the previously
recorded identity is associated with the registered entity and it alone);
the level of the authentication mechanism, the allocation constraints as well as the
implementation constraints (assurance that the authentication mechanism is used by the
registered entity).
In the context of this specification, authentication relates to either individuals or legal entities.
The term person is used to designate an entity that is the subject of an authentication operation,
be it an individual or a legal entity.
4.2 Healthcare Actor
As part of the PGSSI-S, a healthcare actor is an individual or legal entity directly or indirectly
involved in the provision of care to a patient.
4.3 Scope of an identifier
The identifier used for authentication can be local or national in scope.
As noted in the associated reference document Identification of health and community health
actors, identifiers that are national in scope (or public identifiers) are assigned upon registration
in a national identity repository (RPPS, ADELI, FINESS, SIRET / SIREN, etc.).
4.4 Authentication Factors
In practice, the proof of identity submitted during an authentication operation may be based on
one or more of the following authentication factors:




Something that the person knows (e.g. password.)
Something that the person possesses (e.g. smartcard, digital certificate, One Time
Password (OTP) token, OTP card, telephone, tablet, mailbox, etc.);
Something that the person is (e.g. physical characteristic such as biometrics);
Something that the person does (e.g., Behavioral biometrics such as a handwritten
signature or the manner and rhythm in which an individual types on a computer
keyboard, also known as "keystroke biometrics").3
The more factors used during an authentication operation, the greater the reliability of the
authentication.
2
For more information please see section 3.2.a.1 of the “Référentiel Général de Sécurité” version 2.0
available here : http://www.ssi.gouv.fr/uploads/2014/11/RGS_v-2-0_Corps_du_texte.pdf
3
This factor is largely experimental and there are currently few strong authentication solutions that rely
heavily on behavioral biometrics.
6 / 26
ASIP Santé
06/06/16
4.5 Authentication Type
There are two types of authentication:


simple authentication that is based on only one factor (e.g. the user enters his
password);
strong authentication that is based on multiple combined factors (for example, what I
know and what I have: password entered on a terminal that is itself authenticated and
registered as belonging to the authenticated person).
Authentication factors are associated with an individual or a legal entity. In the case of strong
authentication, the various factors used must be associated with the same person (individual or
legal entity).
4.6 Direct Authentication
Authentication of an individual is called direct when the individual is accessing the information
system on their own, under their own responsibility, using their authentication mechanism to
authenticate directly with the information system (e.g. Using a login/password to access a
summary of orders on a website).
4.7 Authentication Architectures (indirect or by proxy)
When direct authentication is not an option, it is possible to implement alternative authentication
architectures in which the function of authenticating the individual is entrusted to a legal entity
third party.
Two alternate authentication architectures are defined:
indirect authentication: when an individual accesses the target health information
system4 via another health information system operated by a legal entity that itself
defines the authentication mechanisms for the individual.
For example, this could be used by a healthcare institution which locally authenticates its
users and takes responsibility for this authentication and then authenticates itself to the
target information system, via its legal entity certificate.
The legal entity is then responsible for ensuring the identity of the individual requesting
access and propagates the identification and authentication for this individual to the
target system after having first authenticated itself to the target system.
Indirect authentication therefore corresponds to the combination of the legal entity’s
public authentication (legal entity software certificate5 assigned following the
implementation constraints described in the appendix of this document) and a private
authentication of an individual healthcare actor (e.g. by username/password, biometric
or national authentication mechanism such as CPS smartcards).
Individual
Private
Authentication
Legal Entity
Public
Authentication
Information System
4
Information system in which the individual wants to get access after authentication.
Electronic certificate stored in a software system (browser, application, operating system, etc.) as
opposed to an electronic certificate securely stored on a hardware device (smartcard or USB key, etc.).
5
7 / 26
ASIP Santé
06/06/16
The legal entity is also responsible for managing the identification of this locally
authenticated actor, and any potential changes to the identifier. The lifecycle of the
locally defined identifiers is determined by the director of operations, depending on the
purpose of use and associated risk analysis.
Indirect authentication cannot be used to assign authentication of a legal entity to
another legal entity.

authentication by proxy: when an individual accesses the target health information
system6 via another information system operated by a legal entity. The legal entity uses
public authentication mechanisms to authenticate the individual to itself. The
authentication mechanisms used by the legal entity are the same mechanisms that the
target information system would use in the context of direct authentication. In other
words, unlike indirect authentication where the legal entity can choose any sufficiently
secure authentication mechanism it prefers, with authentication by proxy the legal entity
must choose an authentication mechanism that has been approved by the target
information system as a public authentication mechanism. I.e. This would be the same
mechanism that would be used if a health actor were to connect directly to the target
information system.
For example, if a supplier offers a value-add service that decentralizes all healthcare
applications to the cloud which includes a direct authentication component, the supplier
would allow the actor to authenticate directly to itself using a smartcard and then take
the responsibility of authenticating the supplier’s system to the target system, thereby
allowing the primary user to avoid having to install additional authentication components
on their local workstation. The user would use a smartcard to authenticate to the cloud
service, and the cloud service would authenticate itself to the target information system
and then convey the identity information of the individual as well as an assurance that
the individual was appropriately authenticated with a smartcard.
Authentication by proxy corresponds to the combination of a public authentication of the
legal entity (legal entity certificate software following the conditions of employment
provided in the Annex) and public authentication of an individual.
Individual
Public
Authentication
Legal Entity
Public
Authentication
Information System
Authenticating by proxy must be done by direct authentication to the legal entity. It is not
possible to use an indirect authentication to a legal entity for authentication by proxy.
6
Information system in which the individual wants to get access after authentication
8 / 26
ASIP Santé
06/06/16
5 Levels of authentication for health actors
The different levels defined for implementing the authentication of health actors are documented
below in order of increasing levels of assurance.
The defined levels combine the strength of the authentication mechanism and scope of
identification on which authentication (local Identifier, national Identifier) is based.
The authentication levels are numbered in ascending order. The authentication level
corresponding to the highest level of assurance has the strongest authentication mechanisms
and uses national scope identifiers rather than local.
The selection of which level of authentication should be used is based on the risk analysis of the
information system as well as regulatory constraints. In some cases, the achievement of a
higher assurance level can be implemented incrementally, starting with lower levels and
incrementing the authentication and identification mechanisms over time until the appropriate
level of authentication is achieved.
A summary view of all the levels for the private and public authentication is presented in section
6.
5.1 Public authentication levels
While level 1 authentication exists for private health actors, this level of assurance is insufficient
for public authentication and therefore this section begins with public authentication level 2.
5.1.1 Public Authentication Level 2
5.1.1.1 Authentication of an individual
5.1.1.1.1 Direct Authentication
In level 2 public authentication, the direct authentication of an individual is performed using an
"Individual software certificate7". This certificate is associated with a key pair that is stored
locally and used to authenticate the individual. The key pair is issued by a PKI identified in the
Référentiel des autorités de certification éligibles pour l’authentification publique dans le secteur
de la santé.
This type of software certificate may be useful for the implementation of SaaS (Software as a
Service - Subscription to an Internet service that offers the functions of a health information
system).8
The conditions of use of software certificates for authentication are specified in section 9.3 of
Appendix 1.
5.1.1.1.2 Authentication Architecture - Indirect Authentication
For level 2 public authentication, indirect authentication is accepted. This is based on a
combination of the public authentication of the legal entity and a private authentication of the
healthcare actor.
7
A software certificate is an electronic certificate stored in a software system (browser, application,
operating system, etc.) as opposed to a certificate enclosed in a hardware device (smart card chip or
USB key, etc.).
8
In this case, the individual being authenticated entrusts the software certificate and associated key-pair
to the SaaS operator to use on their behalf.
9 / 26
ASIP Santé
06/06/16
With indirect authentication, only the legal entity is authenticated to the target health information
system. The legal entity is in turn responsible for authentication of individuals acting under its
authority. Therefore, it must:



define which public or private authentication mechanisms will be used to authenticate
the individual;
identify the security requirements for the authentication of individuals and implement the
appropriate security provisions;
ensure the ability to identify the individual in case of dispute (i.e. management of local
identifiers and their possible evolution over time).
The health actor identifier used can be national or local in scope.9
5.1.1.2 Authentication of legal entities
Level 2 authentication of a legal entity to a target health information system should be carried
out using the following mechanism:
Type of Health Actor
Any type of legal entity
Authorized Mechanisms
Server Certificate
Using an authentication key pair whose public key is signed
by one of Certification Authorities identified in the
Référentiel des autorités de certification éligibles pour
l’authentification publique dans le secteur de la santé (A
specification listing eligible certification authorities for
authentication in the public health sector)
For operational reasons, use of a server certificate is accepted for the authentication of the legal
entity that is responsible for that server. The legal entity is identified in the server’s certificate.
5.1.2 Level 3 Public Authentication
5.1.2.1 Authentication of an individual
5.1.2.1.1 Direct Authentication
In level 3 public authentication, authentication of an individual health actor is performed with one
of the mechanisms described in the following two sub-sections.
9
It should be noted that the use of a local rather than national identifier weakens the overall
authentication.
10 / 26
ASIP Santé
06/06/16
5.1.2.1.1.1 CPx smartcards for Direct Authentication
The primary level 3 authentication mechanisms for individuals are presented in the table below:
Individuals who are healthcare
professionals registered in:


The Répertoire Partagé des
Professionnels de Santé
(RPPS)
or
Other national repositories
such as the ADELI
Individuals who are not healthcare
professionals:
 Non-professional health staff
employed by a health
professional or a legal entity in
the healthcare domain11
(see conditions of use in the appendices)
Healthcare Professional Smartcard (CPS)
Containing an authentication certificate10 issued by
a PKI approved by the group identified in Article R
161-54 of the Code of Social Security and stored
on a smartcard referred to as the CPS smartcard
Healthcare Organization Employee Smartcard
(CPE)
Containing an authentication certificate issued by a
PKI approved by the group identified in Article R
161-54 of the Code of Social Security and stored
on a smartcard referred to as the CPE smartcard
5.1.2.1.1.2 Alternative authentication mechanisms
The term alternative mechanisms refers to a set of mechanisms that depend on the use of a
CPS smartcard for the initial enrolment. The initial enrolment consists of an initial authentication
using the smartcard immediately followed by the linking of the certificate holder to the alternative
authentication mechanism that will be used for subsequent authentications. Any combination of
alternative mechanisms is also considered an alternative mechanism.
Alternative authentication mechanisms respond to a need for public authentication in situations
where CPS smartcards cannot be used, such as on mobile devices that are not smartcard
enabled. The choice of alternative mechanism depends on what can be realistically
implemented. If multiple mechanisms are available, the choice of mechanism should be
prioritized as follows:
In general:
 Use a CPS smartcard
 If a smartcard is not possible, use an SMS based One-Time Password (OTP)
 If neither are possible, use an email-based OTP
In a mobile device environment:
 Use a mobile device with a CPS smartcard
 If that is not possible, use an SMS based OTP
 If neither smartcards nor SMS are possible, use push OTP
10
Certificate: acts as an electronic identity card attesting to the link between the cryptographic keys
provided to an actor for authentication or signature functions. A certificate attests to the link between the
cryptographic keys and the actor’s real identity, and is therefore proof of an actor’s true identity.
11
See the Identification of Health and Community Health Actors specification of the PGSSI-S (Reference
1), for the definition of legal entities in the healthcare domain who are empowered to manage CPE
smartcards.
11 / 26
ASIP Santé

06/06/16
If none of the above are possible, use email-based OTP.
These mechanisms are described below.
A. One-Time Password (OTP) – SMS OTP and email OTP
Authentication by a single use password, also known as One Time Password or OTP involves
the email or SMS transmission of a password to the user at the moment that the user requests
access to an on-line service.
This password is automatically generated by the online service after authentication of the
individual. Once received, the OTP must be used within a maximum defined interval12 and is
valid for only one session.
Operating Principles for authentication by One-Time Password
13
Obtaining an OTP requires an initial user input of an identifier (login) and a password.
The login to request an OTP is called "ID INIT OTP" in the rest of this document.
The password for requesting an OTP is called "PWD INIT OTP" in the rest of this document.
OTP Connection Steps
1. Connection and initial authentication
ID INIT OTP and PWD INIT OTP
2. OTP Transmission
OTP
3. OTP Entry
OTP
4. Application Access
Target Service
Workstation
The prerequisite for OTP authentication requires that each user be enrolled into OTP authentication
through the use of a CPS smartcard, as described at the beginning of this section.
This enrollment phase is used to associate the access parameters (ID INIT OTP and PWD INIT OTP) to a
known user of the system and register the email address and/or mobile phone number that will be used to
transmit the OTP in the future.
B. One-Time Password for mobile devices - OTP Push
In a mobile environment, the OTP can be transmitted by "Push", i.e. after authentication of the
individual and their mobile device, the OTP is sent from the authentication system over a
dedicated channel and intercepted by a mobile application, which returns this password to
complete the authentication.
This system relies on the use of Push platforms available from the leading mobile operating
systems, such as Google, Apple, and Microsoft. The mobile device may be linked to the user by
scanning a QR code with the device’s camera.
12
Usually within 10 minutes or less
This is known as strong two-factor authentication where first something the user “knows” such as the
login and password is provided and then the OTP is sent to something the user “has” such as the device
to which the OTP is sent. This is the opposite of smartcard two-factor authentication, where something
the user “has”, i.e. the smartcard, is provided first.
13
12 / 26
ASIP Santé
06/06/16
Operating principles of the single-use authentication password using PUSH
Authentication Server
Prerequisite: Initial enrollment to associate
the User ID with the Mobile Device
2. Random OTP
Generation
1. ID INIT and PWD INIT
3. OTP
5. OTP
Push Server
4. OTP
5.1.2.1.2 Authentication Architecture - Authentication by proxy
The authentication by proxy architecture is accepted for level 3 public authentication.
Authentication by proxy is made via public authentication of the legal entity as well as public
authentication of the health actor.
In the authentication by proxy mechanism, only the legal entity is authenticated to the target
information system; the health actor is only identified to the target information system and not
authenticated. For proxy authentication, the legal entity is responsible for implementing the
intermediary authentication of health actors to itself. To do this, the legal entity must:



base the authentication of health actors on one of the public authentication mechanisms
accepted by the target information system for direct authentication;
implement level 3 non-repudiation at minimum for the authentication function14;
implement security provisions corresponding to security requirements of the target
information system for the authentication of individuals.
An authentication by proxy architecture requires a contract or agreement between the Director
of operations of the target information system and the legal entity implementing the
authentication by proxy. The contract must at minimum identify the public authentication
mechanisms that are accepted, as well as the security requirements that must be included as
part of the authentication by proxy architecture and the validation process that ensures that the
security requirements have been adequately implemented.
14
See the association “Non-Repudiation” reference document for more information on level 3 nonrepudiation.
13 / 26
ASIP Santé
06/06/16
5.1.2.2 Authentication of the legal entity
Authentication of the legal entity to a health information system must use the following
mechanism:
Any type of legal entity
Legal entity software certificate
Using an authentication key pair whose public key
is signed by one of the Certification Authorities
identified in the Référentiel des autorités de
certification éligibles pour l’authentification
publique dans le secteur de la santé document.
The delivery of the legal entity’s certificate will rely on a specific authorization to ensure the
proper accreditation of the individual representing the legal entity to whom the certificate will be
delivered.
The identifier of the legal entity used is a national identifier (FINESS, SIRET/SIREN, etc.).
14 / 26
ASIP Santé
06/06/16
5.2 Private authentication levels
Private authentication of health actors may only be used for individuals. Legal entities must
always be authenticated using public authentication.
5.2.1 Level 1 private authentication
Login and password based authentication is permitted for level 1 private authentication.
Password policies must include rules for password length and formation, password renewal
periods, and password storage.
Please refer to the ANSSI note on passwords as specified in reference #3 in the references
appendix.
The identifier of health actor used for level 1 private authentication may be either national or
local.15
In level 2 private authentication, a health actor can be authenticated by any strong
authentication mechanism as defined in section 4. The Director of operations is responsible for
selecting the authentication mechanism and managing any risks related to that mechanism.
Examples of level 2 private authentication mechanisms include:


Combination of a login/password with:
o a hardware or virtual token; or
o the use of the contactless capacity of a CPS3 smartcard;
Healthcare organization smartcard (containing an authentication key pair from the
healthcare organization’s PKI) or other device that serves as a secured container for a
non-exportable healthcare organization certificate, such as a USB key. The container
must protect access to the key-pair by some mechanism such as a PIN code,
biometrics, etc.
The Director of operations of the legal entity selects the authentication mechanism based on a
targeted risk analysis.
The identification rules for Level 2 private authentication are the same as those presented for
Level 1.
The Director of operations is responsible for all access to the Health Information System and
must be able to identify all users that have connected to the Health Information System. In order
to do this, the director must manage identification of users as they evolve over time. This is best
accomplished using national identifiers, or potentially using local identifiers where the local
identification can be reasonably expected to guarantee the identification of the user.
Therefore, the Director must:
-
15
Associate an identity to an identifier, and integrate this identifier into an
authentication mechanism (such as including it in the certificate).
The use of a local identifier rather than a national identifier weakens the authentication level.
15 / 26
ASIP Santé
-
06/06/16
Establish a means of distribution of the authentication mechanism to ensure it is
issued to the correct individual and to them alone, for example through face to face
enrolment requiring an identity card.
In level 3 private authentication, a health actor must be authenticated using the same
mechanisms as for level 3 public authentication as described in section 5.1.2 above.
Therefore, a national identifier16 is used and linked to the authentication mechanism.
5.2.4 Baseline rules for the implementation of private authentication
The implementation of authentication mechanisms for access to the Health Information System
should be based on individual user accounts. Any exception to this rule must be duly
authorized. Technical or physical justification for exceptions is required, and each exception
must be subject to a targeted risk analysis.
Alternative access to the Health Information System must be provided for in case of exceptions,
such as:



Temporary access;
Access workarounds with comparably robust authentication, such as a locally managed
generic smartcard that is issued to users on a temporary basis; or
Temporarily degraded authentication mechanism such as username and password.
Alternative access modes must also enable “break glass” functionality that grants temporary
extended access rights to a user during a crisis situation. Examples of situations when break
glass may be used include provision of emergency care to an unconscious patient outside of
typical emergency department services, or crisis response situations.
All alternative accesses must be logged, as defined in the non-repudiation reference document.
Information systems must, at minimum:





Manage the authentication for all users17, by relying on a user registry that contains
national or local identifiers;’
Enable swift or easy changes of user authentication depending on context, such as
emergency department software or multidisciplinary care teams;
Allow configuration of different lengths of session timeout;
Allow configuration of session time limits depending on business rules;
Allow for multiple simultaneous logins to different workstations, if approved by the
Director of the institution. For example, in order to permit a healthcare provider to
provide continuous care to a patient using a few simultaneous systems.
16
For more information on national scope identifiers, please see the Identification of Health and
Community Health Actors reference document listed as Reference 1.
17
These users may be employees of a legal entity, or authorized third parties.
16 / 26
ASIP Santé
06/06/16
6 Summary of authentication mechanisms
Level 1
Level 2
Individual software certificate
Direct
Public authentication
of individuals
Authentication
Architecture
(indirect or by
proxy)
Private authentication
of individuals
Direct
National or local identification of the health
actor.


CPx smartcards
Alternative authentication mechanisms,
including One-Time Passwords such as:
o
push OTP
o
SMS based OTP
o
email based OTP
Indirect Authentication:
Authentication by Proxy:







Authentication based on username and
password.
Level 3
public authentication of the legal entity
local or national identification of the
individual
private authentication of the individual
Any strong authentication mechanism, as selected
and assured by the Director of healthcare
organization.
public authentication of the legal entity
national identification of the legal entity
public authentication of the individual
security requirements imposed by the target
information system
Uses the same mechanisms as level 3 direct public
authentication, using a national identifier.
Local or national identification of the individual.
Password policies required, see security
recommendations in reference #3.
Public authentication of legal entities
Server Certificate
The legal entity is identified in the server’s
certificate. A national identifier is used to identify
the legal entity (FINESS, SIRET / SIREN).
A national identifier is used to identify the legal entity
(FINESS, SIRET / SIREN).
Note: Authentication of legal entities must always be via public authentication.
17 / 26
ASIP Santé
06/06/16
7 Industry relevance
This document provides a path forward for the authentication of health actors which impacts
health IT solutions (commercial products, products developed by the actors themselves, etc.)
that implement them.
As such, it enables vendors to build their own roadmap for product development and formally
claim product conformance to the authentication levels expressed in this document. Depending
on the level of authentication for which conformance is claimed, a certification process may be
required by the Référentiel général de sécurité (RGS).
As a result, Directors of operations will have sufficient clarity to select products and solutions
that are compatible with the level of authentication that they are seeking to implement in their
Health Information System.
8 Impact on professional practices
With this document, healthcare actors will be more able to integrate authentication into the
evolution of their professional practices if they are aware of the possible authentication levels.
This integration is a key step towards full adoption of electronic healthcare data.
At the same time, vendors will be able to consider how users and healthcare professionals will
be impacted by their products and service and will be able to take those into account when
developing their product roadmaps.
18 / 26
ASIP Santé
06/06/16
9 APPENDIX 1 – Specification and terms of
use for authentication mechanisms
9.1 CPS smartcard authentication
With CPS smartcard authentication, an individual seeking to access the system uses a
smartcard that contains a dedicated authentication key pair (private key, public key), issued by
an approved PKI identified in Art. R 161-54 of the code de la sécurité sociale.
The smartcard is accessible via a smartcard reader integrated into the system. The smartcard
readers must be visible by users when they are at their workstation.
The principle of authentication is based on a dialogue between the system and the smartcard,
via the reader. This dialogue allows the system to verify that the user attempting to access the
system possesses the private key.
The cryptographic authentication mechanism is implemented in the smartcard. It can only be
activated when the smartcard has verified the PIN code of the cardholder.
This authentication of the individual is deemed strong as it is a two-factor authentication, in that
it is based on what the person knows (a PIN code) and what the person has (the card).
CPS Smartcard
The smartcard and the authentication certificate are registered to the
individual and carry the identity of the healthcare professional.
Unique
Characteristics The CPS smartcard contains other security and administrative data, such
as the health insurance information that healthcare professionals add to
electronic medical claim forms.
Management
procedures
The following management procedures are defined by the agency
identified in Art. R 161-54 of the code de la sécurité sociale:
 Application requests and issuing of smartcards to healthcare
professionals
 Application requests and issuing of authentication key pairs
 Theft, damage, loss or withdrawal of smartcard services.
Terms of Use
Once issued to its holder, the CPS smartcard is not transferable. The CPS
cardholder is thereafter accountable for use of the smartcard and any
consequences resulting from its use.
19 / 26
ASIP Santé
06/06/16
9.2 Legal entity software certificate authentication
For this authentication mechanism, the individual seeking to access the system on behalf of the
legal entity uses an authentication key pair consisting of a private key and a public key that are
dedicated for the purpose of authentication. The public key for this key-pair is signed by a
Certification Authority identified in the Référentiel des autorités de certification éligibles pour
l’authentification publique dans le secteur de la santé document.
The storage and use of this key pair and the implementation of the cryptographic authentication
mechanism in the health information system are the responsibility of the Director of operations.
The keys must not be duplicated - there must be a one-to-one correspondence between the key
and the system that hosts it. In other words, each key must only be used for one system, and
each system must have only one key.
The principle of authentication is based on a dialogue between the system and the module
performing the cryptographic operation. This dialogue allows the system to verify that the user
attempting to access the system has the private key.
The legal entity certificate is used under the responsibility of the legal entity which ensures that
the certificate is used for indirect authentication or authentication by proxy by authorized
individuals only.
Unique
Characteristics
The key pair is issued to the representative of the legal entity, who is
responsible for placing it in the desired operating environment.
The authentication certificate is registered to the legal entity and carries
the identity of the legal entity.
Management
procedures
responsible for the PKI that issues the key pair:
 Application requests and issuing of the authentication key pair
 Theft, damage, loss or withdrawal of authentication key pairs.
20 / 26
ASIP Santé
06/06/16
Terms of Use
Once issued to the representative of the legal entity, the representative is
thereafter accountable for the use of the key pair and any consequences
resulting from its use.
The representative must ensure that users that store the key-pairs and
use the private keys, or whether or not they generate their key-pair
themselves, meet the following security requirements:
 if the legal entity’s authentication key-pair is generated by the
legal entity’s own mechanisms, the legal entity must ensure that
the key-pair is generated exclusively by authorized individuals
and that the key-pair is cryptographically robust;
 the private key must not be duplicated;
 defects must be detected during the initialization, customization
and operation of the certificate, and secure mechanisms must be
used for the destruction of private keys in the event that they are
re-generated;
 confidentiality and integrity of the private key must be ensured, for
example by requiring a password to be provided prior to making
the private key available for use;
 the public key and private key must consistently match;
 authentication must be initiated in a way that cannot be falsified
without knowledge of the private key;
 authentication must only be permitted for authorized users, and
the private key must be protected against any use by
unauthorized users;
 authenticity and integrity of the public key must be ensured when
exported from storage.
The identifier of the legal entity to which the key-pair is assigned will be
identified in the audit logs of any actions performed on the health
information system. As a result, the representative of the legal entity
must be able to identify which users were using the key-pair at any given
time.
21 / 26
ASIP Santé
06/06/16
9.3 Individual software certificate authentication
For this authentication mechanism, the individual seeking to authenticate uses an authentication
key pair (private key, public key) dedicated to this use, issued by a PKI identified in the
“Référentiel des autorités de certification éligibles pour l’authentification publique dans le
secteur de la santé” document.
The storage and use of this key pair and the implementation of the cryptographic authentication
mechanism in the health information system are the responsibility of the certificate holder.
These responsibilities can be assigned to a third party if the third party can ensure that only the
holder can use the key pair to authenticate.
The keys must not be duplicated - there must be a one-to-one correspondence between the key
and the system that hosts it. In other words, each key must only be used for one system, and
each system must have only one key.
The principle of authentication is based on a dialogue between the system and the module
performing the cryptographic operation. This dialogue allows the system to verify that the user
attempting to access the system has the private key.
Individual Software Certificate
Unique
Characteristics
The key pair is issued to the certificate holder who is responsible for
placing it in the desired operating environment, or who entrusts this task
to a third party.
The authentication certificate is registered to the individual and carries
the identity of the individual.
Management
procedures
responsible for the PKI that issues the key pair:
 Application requests and issuing of the authentication key pair
 Theft, damage, loss or withdrawal of authentication key pairs.
22 / 26
ASIP Santé
06/06/16
Individual Software Certificate
Terms of Use
Once issued to the certificate holder, the use of the key pair and the
consequences thereof for access to health information system are placed
under the responsibility of the certificate holder or a responsible third
party.
This responsible entity must ensure that users that store the key-pairs
and use the private keys, or whether or not they generate their key-pair
themselves, meet the following security requirements:
 if the individual’s authentication key-pair is generated by the
individual’s own mechanisms, the individual must ensure that the
key-pair is generated exclusively by authorized individuals and
that the key-pair is cryptographically robust;
 ensure no duplication of the key;
 the private key must not be duplicated;
 defects must be detected during the initialization, customization
and operation of the certificate, and secure mechanisms must be
used for the destruction of private keys in the event that they are
re-generated;
 confidentiality and integrity of the private key must be ensured;
o For example when using individual software certificates
for level 2 authentication, access to the location in which it
is stored must be restricted. A password must be provided
prior to making the private key available for use. This
password must follow the password policies defined in the
ANSSI reference in reference document #3.
 the public key and private key must consistently match;
 authentication must be initiated in a way that cannot be falsified
without knowledge of the private key;
 authentication must only be permitted for authorized users, and
the private key must be protected against any use by
unauthorized users;
 authenticity and integrity of the public key must be ensured when
exported from storage.
23 / 26
ASIP Santé
06/06/16
9.4 OTP Authentication mechanisms
Structure of the identifier "ID INIT OTP"
The identifier "ID OTP INIT" can be:


a National identifier of the actor (Id RPPS ADELI id, ...);
or
an ad hoc identifier which may be calculated by the system based on the national
identifier of the actor.
In this latter case, the identifier must be unique.
The identifier may be composed of alphanumeric characters [AZ] + [0-9] without accented
characters or special characters. Letters may be upper or lower case. In order to avoid data
entry errors, the letters used must not include the letters o, i or l.
Structure of the initial password "PWD INIT OTP"
The initial password generated by the OTP Service must be at least 8 characters whose
composition are as follows:
-
at least one uppercase letter, a lowercase letter, one number and one special character;
no accented characters;
the following special characters may be used: _-+=<>@&'!?$*,;:
A check on the absence of consecutive identical characters should be performed.
Creation and password structure for subsequent passwords "PWD INIT OTP"
The initial password must be changed by the user upon their first connection; the new password
must be encoded in at least 8 characters with at least one uppercase letter, a lowercase letter,
and a number.
Structure of the One-Time Password "OTP PWD"
The One-Time Password will consist of a set of at least 6 randomly selected numeric characters
from 1-9.
24 / 26
ASIP Santé
06/06/16
10 Appendix 2 - Glossary
Sigle / Acronyme
Signification
ADELI
Automatisation DEs LIstes Système d'information national sur les
professionnels de santé du social et les psychologues
ANSSI
Agence Nationale de la Sécurité des Systèmes d’Information
ASIP Santé
Agence des Systèmes d’Information Partagés de Santé
COPIL
Comité de Pilotage
CPE
Carte de Personnel d’Etablissement
CPM
Carte de Personnel Mandaté
CPS
Carte de Professionnel de Santé
DMP
Dossier Médical Personnel
FINESS
Fichier National des Etablissements Sanitaires et Sociaux
GT
Groupe de Travail
IGC
Infrastructure de Gestion de Clé
OS
Operating System
OTP
One Time Password
PGSSI-S
Politique Générale de Sécurité des Systèmes d’Information de Santé
PIN
Personal Identification Number
PS
Professionnel de Santé
PTS
Pôle Technique et Sécurité
QR Code
Quick Response Code
RGS
Référentiel Général de Sécurité
RPPS
Répertoire Partagé des Professionnels de Santé
SAAS
Software As A Service
SIM
Subscriber Identity Module (carte SIM)
SIREN
Système d’Identification du Répertoire des ENtreprises
SIRET
Système d’Identification du Répertoire des ETablissements
SIS
Système d’Information de Santé
SMS
Short Message Service
USB
Universal Serial Bus
25 / 26
ASIP Santé
06/06/16
11 Appendix 3 – Referenced Documents
Reference n°1 : PGSSI-S – Référentiel d’identification des acteurs sanitaires et médicosociaux
Reference n°2 : Référentiel général de sécurité (RGS) et ses annexes
Reference n°3 : Note ANSSI - Recommandations de sécurité relatives aux mots de passe
Reference n°4 : PGSSI-S – Principes fondateurs
Reference n°5 : PGSSI-S – Référentiel d’imputabilité
Reference n°6 : PGSSI-S – Référentiel des autorités de certification éligibles pour
l’authentification publique dans le secteur de la santé
26 / 26

PGSSI-S - esante.gouv.fr, le portail de l`ASIP Santé

Transcription

Documents pareils

High-performance fingerprint identification terminal for physical

Silverback by Matrix42

More Than You Ever Wanted to Know about NT

Some facts about Geant Casino La Chapelle Sur Erdre 44

White Paper - Citect (Schneider Electric)

Concept de beaute

Approved "Personal healthcare data host", «le Réseau santé social