EN 419251-1:2013

Security requirements for device for authentication - Part 1: Protection profile for core functionality

This European Standard is a Protection Profile that defines the security requirements for an authentication device.

Sicherheitsanforderungen für Geräte zur Authentisierung - Teil 1: Schutzprofil für Kernfunktionalitäten

Diese Europäische Norm ist ein Schutzprofil, das die Sicherheitsanforderungen an ein Gerät zur Authentisierung definiert.

Profils de protection pour dispositif d'authentification - Partie 1: Dispositif avec import de clés

Le présent document est un Profil de Protection qui définit les exigences de sécurité pour un dispositif
d’authentification.

Varnostne zahteve naprav za overjanje - 1. del: Profil za zaščito ključne funkcionalnosti

Ta evropski standard je profil za zaščito, ki določa varnostne zahteve naprav za overjanje.

General Information

• Status: Published
• Publication Date: 05-Mar-2013
• Withdrawal Date: 29-Sep-2013
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: CEN/TC 224 - Machine-readable cards, related device interfaces and operations
• Drafting Committee: CEN/TC 224/WG 17 - Protection Profiles in the context of SSCD
• Current Stage: 9093 - Decision to confirm - Review Enquiry
• Start Date: 27-Jun-2024
• Completion Date: 14-Apr-2025
• Directive: 910/2014 - Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing directive 1999/93/EC
• Mandate: M/460 - Standardisation Mandate to the European Standardisation Organizations CEN, CENELEC and ETSI in the field of Information and Communication Technologies applied to Electronic Signatures
• Ref Project: SIST EN 419251-1:2013 - Security requirements for device for authentication - Part 1: Protection profile for core functionality

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.IXQNFLRQDOQRVWLSicherheitsanforderungen für Geräte zur Authentifizierung - Teil 1: Schutzprofil für KernfunktionalitätenProfils de protection pour dispositif d'authentification - Partie 1: Dispositif avec import de clésSecurity requirements for device for authentication - Part 1: Protection profile for core functionality35.240.15Identifikacijske kartice in sorodne napraveIdentification cards and related devicesICS:Ta slovenski standard je istoveten z:EN 419251-1:2013SIST EN 419251-1:2013en01-maj-2013SIST EN 419251-1:2013SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 419251-1
March 2013 ICS 35.240.15 English Version
Security requirements for device for authentication - Part 1: Protection profile for core functionality
Profils de protection pour dispositif d'authentification - Partie 1: Dispositif avec import de clés
Sicherheitsanforderungen für Geräte zur Authentisierung - Teil 1: Schutzprofil für Kernfunktionalitäten This European Standard was approved by CEN on 7 December 2012.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2013 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 419251-1:2013: ESIST EN 419251-1:2013

...................................................................................... 15 8 Life Cycle ........................................................................................................................................ 16 8.1 Overview ......................................................................................................................................... 16 8.2 Pre-Personalisation phase ............................................................................................................. 17 8.3 Personalisation phase ................................................................................................................... 18 8.3.1 General ........................................................................................................................................... 18 8.3.2 Personalisation application ........................................................................................................... 18 8.4 Usage phase  Authentication application .................................................................................. 18 8.4.1 General ........................................................................................................................................... 18 8.4.2 Verifier ............................................................................................................................................ 19 9 Security problem definition ........................................................................................................... 19 SIST EN 419251-1:2013

Figures Figure 1 — TOE Security Features . 12 Figure 2 — Personalisation application environment . 13 Figure 3 — Authentication application environment . 14 Figure 4 — TOE Life Cycle . 16
Tables Table 1 — Protection of sensitive data . 24 Table 2 — Security objectives vs problem definition rationale . 27 Table 3 — Security attributes . 31 Table 4 — Core security attributes . 35 Table 5 — Core operations . 35 Table 6 — Core security attributes - Operation . 36 SIST EN 419251-1:2013

ISO/IEC 15408-21), Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional components ISO/IEC 15408-31), Information technology — Security techniques — Evaluation criteria for IT security — Part 3: Security assurance components ISO/IEC 18045, Information technology — Security techniques — Methodology for IT security evaluation
3 Conformance 3.1 CC Conformance Claim This Protection Profile (PP) is CC Part 2 extended and CC Part 3 conformant and written according to
ISO/IEC 15408-1, -2, -3 and ISO/IEC 18045. 3.2 PP Claim This PP does not claim conformance to any other Protection Profile. 3.3 Package Claim The evaluation assurance level for this PP is EAL4-augmented with the assurance components AVA_VAN.5 and ALC_DVS.2. 3.4 Conformance Rationale Since this PP is not claiming conformance to any other protection profile, no rationale is necessary here.
3.5 Conformance Statement The conformance required by this PP is the demonstrable-PP conformance. This would facilitate conformance claim to both the PP “Authentication device” and other PPs for Security Target (ST) authors.
1) ISO/IEC 15408-1, -2 and -3 respectively correspond to Common Criteria for Information Technology Security Evaluation, Parts 1, 2 and 3. SIST EN 419251-1:2013

 one or more hash values of a signer's public key certificate together the identifier of the hash function used to compute these hash values, and some information which allows the signer to disambiguate between several signers certificates 4.4 Configuration set of groups Note 1 to entry: Each configuration corresponds to one PP. It has its own rationale. See [2]. 4.5 Group set Assets, threats, objectives, and Requirements, addressing a specific function Note 1 to entry: See [2]. 4.6 Holder legitimate holder of the authentication device
Note 1 to entry: See 9.2 for more details. 4.7 Issuer user of the authentication device during personalisation Note 1 to entry: See 9.2 for more details. 4.8 Protection Profile PP implementation-independent statement of security needs for a TOE [SOURCE: ISO/IEC 15408-1:2009, Clause 4 "Terms and definitions", modified  in ISO/IEC 15408-1, the protection profile refers to a TOE type instead of a TOE in this document] SIST EN 419251-1:2013

6 Overview of the target of evaluation 6.1 TOE Type The aimed objective is to define security requirements that an authentication device shall conform to in the perspective of a security evaluation. The Target of Evaluation (TOE 2)) considered in this PP corresponds to a hardware device (such as, for example, a smart card or USB token) allowing its legitimate holder to authenticate himself when accessing an on-line service or to guarantee the origin authentication of data sent by the User to a distant agent 3). This PP has been constructed such as to make it possible for an ST writer to claim conformance to both this PP and the PP-SSCD [3], [4], [5], [6], [7] and easily merge these PPs into one ST. 6.2 TOE Usage In order to connect to an on-line service with restricted access or send data whose origin should be authenticated, the Holder shall use his personal authentication device. The service provided by the device requires the prior input of authentication data by the Holder on a terminal device (as specified in 6.5). The authentication service included in the TOE relies solely on public-key cryptography mechanisms to allow the Holder to authenticate himself and access to the on-line service with restricted access or to enable the origin authentication of data sent by the Holder. Note that authentication devices implementing shared key (i.e., symmetric-key) mechanisms for authentication purposes are therefore not considered in this PP. 6.3 Security Features of the TOE The primary functionality of the TOE is to enable the Holder to authenticate himself in order to access an on-line service or guarantee the origin authentication of data sent by the Holder to a distant agent.
2) In the document the terms authentication device, device and TOE are equivalent. 3) He is a physical person that receives some authenticated data from the users. SIST EN 419251-1:2013

6.4.2 Multiple applications e-administration for tax payment requiring signature + e-commerce only requiring authentication. The e-administration and the e-commerce center may get the certificate from the PKI. But they may also rely on the authentication protocol to securely provide the public key, for example within a signed certificate. Communication between Authentication application and the TOE may be regarded as secure for:  Holder authentication;  Selection of online server;  Selection of a specific Authentication key pair;  Acceptance of authentication of the TOE. 6.5 Required non-TOE Hardware and Software The authentication device requires the services provided by a terminal device to enable the Holder to input his authentication data. Typically, this terminal device (e.g., a PINPad terminal) ensures the protection of authentication data input in confidentiality and integrity and its secure transfer to the TOE. The general features of this terminal along with the method employed to enable the input of authentication data are considered out of the TOE scope. It should be however noted that the level of security of the whole operational system including the TOE depends on the security level of the TOE operational environment. In particular, an authenticated terminal device for the input and transfer of the Holder authentication data could be required in usage environments considered as untrusted. 6.6 Protection Profile Usage The requirements present in this PP define the minimum security rules an ST of an authentication device shall conform to but are in no way exhaustive. It remains indeed possible to add functionalities or also refer to another PP. However, any modifications to this PP are restricted by the rules defined by the conformance as set forth in Clause 3. In other respects, this PP aims at ensuring compatibility with PP-SSCD [3], [4], [5], [6], [7], in order to define complementary security requirements for products offering both authentication and signature services.
Figure 1 — TOE Security Features Figure 1 shows all the security features of the TOE, in the Personnalisation and Usage environments. The legend explains how different colors identity the security features of the different groups: Core and KeyImp. Further details on groups can be found in [2].
Figure 2 — Personalisation application environment 7.2.2 Functionalities The Personalisation application interfaces the TOE at the Personalisation facility. These operations take place before the issuance of the TOE. This application initialises all data specific to the end user. These data can include:  APrK  User RAD If the TOE generates the APrK, the application retrieves the APuK and sends it to the CA that will generate the certificate. If the TOE imports the APrK, the application retrieves the APuK and sends it to the TOE. The application also ensures that the APuK is securely - protected in integrity - sent from the key pair generator to the CA that generates the certificate. 7.2.3 Communication As the environment is trusted, Transfer of sensitive data is protected by the environment. However, as APrK is of special special sensitivity, a "Trusted channel" is always required to load it. SIST EN 419251-1:2013

Figure 3 — Authentication application environment 7.3.2 Functionalities The Authentication application interfaces the TOE when the holder needs to be authenticated by the Verifier. It can run on several devices:  a PC at home to access online services (e-administration, e-commerce…).  a specific device to identify and authenticate a card holder (police control…). The TOE may contain several Authentication keys. It may also contain Signature keys. Therefore the Authentication application shall ensure a clear and secure human interface to prevent any confusion, when selecting the Verifier and the authentication key. The VAD can also be entered via a separate Human Interface. 7.3.3
Communication The Authentication application is in a trusted environment. The TOE and the Authentication application exchange the following sensitive data:  Import of Holder VAD for authentication;  Import of Holder RAD for update;  Request for authentication from a specific Verifier. SIST EN 419251-1:2013

7.5.2 Communication Communication between the Key generator and the TOE shall be secured. During the personalisation phase, which takes place in a trusted environment, this communication can be split in two phases:  Transfer from the Key Generator to the Personalisation application, then  Transfer from the Personalisation application to the TOE. 7.6
The certification authority generates a Certificate, based on the public key it receives. As the key is generated off TOE, the Environment shall ensure that the public key is securely transferred to the CA. SIST EN 419251-1:2013

Figure 4 — TOE Life Cycle This figure represents two views of the life-cycle:
a) An “end-user” view made of four phases, focusing on the following main logical phases: 1) Development phase: IC design, and embedded software development; SIST EN 419251-1:2013

b) A business view made of seven steps, focusing more on the different trades and actors involved in smartcard business. For example, the company in charge of IC manufacturing may be different from the one in charge of IC packaging, as well as from the one in charge of packaging, initialisation, pre-personalisation, not considering all other actors involved in this phase: antenna supplier, booklet supplier. The definition of the content of each step and the associated supply chain vary from one provider to another and the picture is just indicative. Referring to the life-cycle, the evaluated product is the product that comes out of the IC manufacturing, test and possible pre-personalisation operations (step 3).
At this step, the product shall already be self-protected before delivery to step 4 and all steps after. This means that if a patch is to be loaded on the product to fix a security flaw, this operation has to be performed during the IC manufacturing step, i.e. in an environment that is under control of the evaluation and assessed through assurance class of Common Criteria related to the development environment (ALC). The following options are also important to keep in mind:
 creation of the application;  applet instantiation for a JavaCard;  loading of the pre-personalisation data in the chip. These operations may or may not be performed within the IC manufacturer secure premises covered by the evaluation scope, depending on the business organisation for the TOE production. They may even be performed during the personalisation phase (step 6) under the control of the issuing state.
However, if they are not performed within the IC manufacturer secure premises, the procedures to perform these operations have to be well defined, and successfully evaluated through assurance tasks of Common Criteria related to guidance analysis (class AGD). More generally, all steps that come after step 3 are to be covered by guidance (secure delivery, secure handling, etc.). The ST writer can choose to include step 4 and also step 5 inside the perimeter of the evaluation. In this case the premises where these operations take place will be covered by ALC, not AGD and sensitive operations such as the loading of patches invoving Security Functions can be done in the included steps. 8.2 Pre-Personalisation phase Pre-Personalisation is the final phase under the control of the Smart card manufacturer.
Application initialisation During Pre-personalisation, the Smartcard manufacturer initialises the application. Import of Issuer RAD The manufacturer imports the Issuer RAD that will be used in the next phase to authenticate the Issuer. SIST EN 419251-1:2013

8.3.2 Personalisation application Issuer authentication The Issuer authenticates himself to the TOE using a RAD. Import of Holder RAD This function is mandatory in Personalisation. This function initialises the RAD. When biometrics is used, this operation requires the holder. Import of Authentication Protocol sensitive data This function is optional as these data may be empty. It is only necessary if APrK / APuK key pair is generated on TOE during Personalisation. In this case the TOE shall import the APSD, if not null, after the CA has generated the certificate.
Import of Authentication private key. This function is not necessarily used in Personalisation. The TOE can also be issued without APrK.
8.4 Usage phase  Authentication application 8.4.1 General The Authentication application interfaces the TOE to the holder. During the usage phase, the Holder can perform the following operation on the authentication device: Holder Authentication to the TOE, The Holder authenticates himself to the TOE using a RAD.
When the TOE is used both for Authentication and Signature and when the RAD is a PIN, the TOE shall provide at least one PIN for Signature and one PIN for Authentication.
Import of the private key This function is not necessarily used in Usage phase. APrK can also be imported in Personalisation phase. The TOE can also be issued with APrK. SIST EN 419251-1:2013

Allow Authentication by Verifier This function enables the Holder to accept or deny the authentication by the Verifier.
8.4.2 Verifier Authentication by Verifier This function allows the Verifier to authenticate the TOE and therefore its holder.
Other functions following the Authentication, such as exchange of data with the Verifier, are out of the scope of this PP. 9 Security problem definition 9.1 Assets 9.1.1 General The description of each asset provides the type of protection required for each asset ("Protection" part). RAD, VAD, Authentication Protocol sensitive data are not Assets, they are TSF data. The ST writer shall specify these TSF data. 9.1.2 Assets protected by the TOE D.AUTHENTICATION This asset represents the authentication function itself and all the benefits that can result from the authentication. These benefits can be:  communication data between the authentication device and an access-restricted on-line service  data or goods located in an access-restricted area  rights provided in country by an ID card 9.1.3 Sensitive assets of the TOE D. AUTHENTICATION_PRIVATE_KEY
This asset corresponds to the private key generated outside of the TOE and imported in the TOE or generated inside the TOE. The private key is associated with a public key and a public-key certificate. In addition, the private key shall remain consistent with its corresponding public key. Protection: integrity and confidentiality. Application notes: This asset is used by the authentication service running on the TOE.
...