SIST EN 419212-2:2018

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Uporabniški vmesnik za varnostne elemente za elektronsko identifikacijo, avtentifikacijo in zanesljivost storitev - 2. del: Podpis in dodatne storitveAnwendungsschnittstelle für sichere Elemente, die als qualifizierte elektronische Signatur-/Siegelerstellungseinheiten verwendet werden - Teil 2: Zusätzliche DiensteApplication Interface for Secure Elements for Electronic Identification, Authentication and Trusted Services - Part 2: Signature and Seal Services35.240.15Identification cards. Chip cards. BiometricsICS:Ta slovenski standard je istoveten z:EN 419212-2:2017SIST EN 419212-2:2018en,fr,de01-april-2018SIST EN 419212-2:2018SLOVENSKI
STANDARDSIST EN 419212-2:2015SIST EN 419212-1:20151DGRPHãþD

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 419212-2
December
t r s y ICS
u wä t v rä s w Supersedes EN
v s { t s tæ sã t r s vá EN
v s { t s tæ tã t r s vEnglish Version
Application Interface for Secure Elements for Electronic Identificationá Authentication and Trusted Services æ Part
tã Signature and Seal Services Interface applicative des éléments sécurisés utilisés comme dispositifs de création de signature signatures et de cachets
Anwendungsschnittstelle für sichere Elementeá die als qualifizierte elektronische SignaturæZusätzliche Dienste This European Standard was approved by CEN on
x February
t r s yä
egulations 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ä
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á Serbiaá Slovakiaá Sloveniaá Spainá Swedená Switzerlandá Turkey and United Kingdomä
EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre:
Avenue Marnix 17,
B-1000 Brussels
t r s y CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Membersä Refä Noä EN
v s { t s tæ tã t r s y ESIST EN 419212-2:2018

Security environments . 100 Annex B (informative)
Seals and Signatures . 108 Annex C (informative)
Remote Signatures . 111 SIST EN 419212-2:2018

Part 3: “Device Authentication” describes the device authentication protocols and the related key management services to establish a secure channel.
Part 4: “Privacy specific Protocols” describes functions and services to provide privacy to identification services.
Part 5: “Trusted eServices” describes services that may be used in conjunction with signature services described in Part 2.
This document has been prepared under a mandate given to CEN by the European Commission and the European Free Trade Association. According to the CEN-CENELEC Internal Regulations, the national standards organisations of the following countries are bound to implement this European Standard: 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, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 419212-2:2018

Signature creation and mobile signature creation
User verification
Password based authentication The specified mechanisms are suitable for other purposes like services in the context of [2]. The particular case of seal is also covered by the specification. The differences between seal and signature is exposed in Annex B. Annex B also explains how the mechanisms for SEs as qualified signature creation devices can be used for SEs as qualified seal creation devices. Mobile signature is an alternative to the classical signature case which is performed by a secure element. Mobile signature is encouraged by the large widespread of mobile devices and the qualification authorized by the eIDAS Regulation [2]. The particular case of remote signature (or server signing) is covered by this specification in Annex C. In the rest of this document, except Annex B, there will be no particular notion of a seal since it technically compares to the signature. 2 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ISO/IEC 7816-4:2013, Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange ISO/IEC 7816-8:2004, Identification cards – Integrated circuit cards – Part 8: Commands for security operations ISO/IEC 7816-11:2004, Identification cards — Integrated circuit cards — Part 11: Personal verification through biometric methods ISO/IEC 7816-15, Identification cards — Integrated circuit cards — Part 15: Cryptographic information application ISO/IEC 9797-1:2011, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher ISO 11568-2:2012, Financial services — Key management (retail) — Part 2: Symmetric ciphers, their key management and life cycle ISO/IEC 14888-2:2008, Information technology — Security techniques — Digital signatures with appendix — Part 2: Integer factorization based mechanisms ISO/IEC 19794-2:2005, Information technology — Biometric data interchange formats — Part 2: Finger minutiae data ISO/IEC 15946-5, Information technology — Security techniques — Cryptographic techniques based on elliptic curves — Part 5: Elliptic curve generation, 2009-12-15 SIST EN 419212-2:2018

3 Terms and definitions For the purposes of this document, terms and definitions in EN 419212-1 apply. 4 Symbols and abbreviations For the purposes of this document, symbols and abbreviations in EN 419212-1 apply. 5 Signature application 5.1 Application Flow Figure 1 shows an execution flow for a signature creation as it is mandated in [1].
1 Available at https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03110/index_htm.html SIST EN 419212-2:2018

Figure 1 — Interaction sequences between SCA and QSCD in compliance with EU regulation The corresponding technical implementation is given in this document and as various mechanisms are specified for device authentication and user verification with a number of resulting combinations, Figure 2 gives some example execution flows for typical signature cards. Each card implements a signature application and they differ in the combination of privacy and security features. A card with a contact interface that is used in a trusted environment may not require any device authentication. In contrast, contactless cards are vulnerable to skimming and eavesdropping attacks and hence require protection. Reading SN.ICC would be a possible start for a non-privacy protecting device authentication (e.g. EN 419212-3, 3.9) whereas the card is addressed through contacts. For privacy protection (e.g. EN 419212-3, 3.6, EN 419212-3, 3.7) reading SN.ICC would not be desirable. Instead a password based mechanism may be involved which prevents the card being addressed unless a password, e.g. secret PIN or Card Access Number printed on the card is entered first. This is suitable for contactless cards which shall not allow communication without either the explicit act-of-will of the card holder or proof of legitimate physical possession of the card. In multi-application environments device authentication may be performed on card (e.g. MF level) prior to application selection. Whether for basic or additional services, a device authentication is always mandatory if the environment where the signature device is being used, is not known to be trustable. This is typical for public environment (e.g. airport, merchandise, POS). Only in trusted environments (e.g. company, campus) can device authentication be skipped. SIST EN 419212-2:2018

Figure 2 — Execute signature services Figure 2 shows the selection of additional services in the context of the ESIGN application. User verification might be required for some of the additional services. The detailed access conditions are described in the appropriate security environments. NOTE
* For contactless case in untrusted environment, two choices are possible. Either the reading of CIA file (refer to 14) and the selection of application are done before device authentication, in conformity with Figure 1, or the device authentication is done first.
PKCS#15 takes into account privacy preserving measures involving EF.DIR so that to meet data minimizing property requirements (new component enhanced CIODDO under EF.DIR ensures that the IFD can access DF.CIA content only once security protocols i.e. PACE are fulfilled). This prevent the leakage of user information from CIA file and preserve privacy. 5.2 Trusted environment versus untrusted environment According to the definitions in “trusted environment” (EN 419212-1, 3.58) and “untrusted environment” (EN 419212-1, 3.63), this specification describes additional mechanisms in order to accomplish the required security as claimed in the protection profile [3]. The additional mechanisms according to this specification are: - Device authentication SIST EN 419212-2:2018

to be secured by organisational means Untrusted Environment (public) to be secured by cryptographical means Contact communication channel has been established As in generic case no authentication protocol necessary (see 5 “Signature application”) Chip and Terminal Authentication, see device authentication protocols according to EN 419212-3, clause 3. Contactless communication channel has been established Password Based authentication (PACEv2) with provision of secure channel by secure Messaging (restricted to specific types of passwords e.g. biometric passwords or passwords stored as keys inside the ICC (see 8 “Password-based authentication protocols”) 1. Password based authentication (PACEv2) with provision of secure channel by Secure Messaging 2. Chip and Terminal authentication e.g. see privacy and /or mEAC device authentication protocol according to EN 419212-3, clause 3. NOTE The RSA transport protocol (EN 419212-3, clause 3.8) is not suitable, unless the SN.ICC is set to a “dummy value” for privacy reasons. 5.3 Selection of ESIGN application 5.3.1 General An ESIGN application is selected by its Application Identifier (AID) [see ISO/IEC 7816-5:2004]. The RID is registered by the ISO registration authority and has the following value: A0 00 00 01 67. The first 10 bytes of the AID have the following value AID = A0 00 00 01 67 || “ESIGN” = A0 00 00 01 67 45 53 49 47 4E with Category = 'A.' (international) PIX = 'ESIGN' = 5 bytes NOTE The maximum possible size of the PIX is 11 bytes (refer to ISO/IEC 7816-4, 12.2.3). The remaining 6 bytes may be used by CEN to distinguish between different implementations in the scope of this standard. SIST EN 419212-2:2018
...