SIST EN 419212-1: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, avtentikacijo in zanesljivost storitev - 1. del: Uvod in splošne definicijeAnwendungsschnittstelle für sichere Elemente, die als qualifizierte elektronischer Signatur-/Siegelerstellungseinheiten verwendet werden - Teil 1: Allgemeine DiensteInterface applicative des éléments sécurisés utilisés comme dispositifs de création de signature électronique qualifiée (cachet) - Partie 1 : Introduction et définitions communesApplication Interface for Secure Elements for Electronic Identification, Authentication and Trusted Services - Part 1: Introduction and common definitions35.240.15Identification cards. Chip cards. BiometricsICS:Ta slovenski standard je istoveten z:EN 419212-1:2017SIST EN 419212-1:2018en,fr,de01-februar-2018SIST EN 419212-1:2018SLOVENSKI
STANDARDSIST EN 419212-2:2015SIST EN 419212-1:20151DGRPHãþD

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 419212-1
September
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
sã Introduction and common definitions Interface applicative des éléments sécurisés utilisés comme dispositifs de création de signature et définitions communes
Anwendungsschnittstelle für sichere Elementeá die als qualifizierte elektronischer SignaturæAllgemeine 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æ sã t r s y ESIST EN 419212-1:2018

Contents Page European foreword . 5 Introduction . 6 1 Scope . 7 2 Normative references . 7 3 Terms and definitions . 7 4 Symbols and abbreviations . 15 5 Management Summary . 18 5.1 Motivation . 18 5.2 What is in behind?. 19 5.3 Use Cases . 20 5.4 Privacy and Security. 21 5.5 Overview - EU Directive and Regulation . 21 5.6 Facts and Figures . 22 Annex A (normative)
Algorithm Identifiers — Coding and specification . 23 Table A.1 — AlgIDs . 24 Table A.2 — Coding of byte 3 and 4 (for hash calculation - byte 2 = '01' to '0F) . 24 Table A.3 — Coding of byte 3 (for digital signature computation - byte 2 = '1x') . 25 Table A.4 — Coding of byte 4 (for digital signature computation - byte 2 = '1x') . 25 Table A.5 — Coding of byte 3 (for C/S authentication - byte 2 = '2x') . 25 Table A.6 — Coding of byte 4 (for C/S authentication - byte 2 = '2x') . 25 Table A.7 — Coding of byte 3 (for key decipherment - byte 2 = '3x') . 26 Table A.8 — Coding of byte 4 (for key decipherment - byte 2 = '3x') . 26 Table A.9 — Coding of byte 3 (for authentication protocol - byte 2 = '4x'). 26 Table A.10 — Coding of byte 4 (for authentication protocol – byte 2 = '4x') . 28 Table A.11 — Coding of byte 3 (for digital signature verification – byte 2 = '9x'). 28 Table A.12 — Coding of byte 4 (for digital signature verification – byte 2 = '9x'). 28 Table A.13 — Coding of byte 3 (for role authentication – byte 2 = 'Ax') . 29 Table A.14 — Coding of byte 3 (for privacy features – byte 2 = 'Cx') . 29 Table A.15 — Coding of byte 4 (for role authentication - byte 2 = 'Ax'). 29 Table A.16 — Coding of byte 4 (for privacy feature - byte 2 = 'Cx') . 29 Table A.17 — 1-byte Algorithm-ID coding. 30 Annex B (informative)
OID values . 32 B.1 OIDs for certificate signatures . 32 Table B.1 — Object identifier values related to a public key in a certificate . 32 B.2 OIDs for key transport protocol . 32 SIST EN 419212-1:2018

Table B.2 — Object identifier values for the key transport protocol . 33 B.3 OIDs for device authentication with privacy . 33 Table B.3 — Object identifier values for device authentication with privacy . 33 B.4 OIDs for password based mechanisms . 34 Table B.4 — PACE OIDs . 34 B.5 OIDs for mEAC protocol . 34 B.5.1 OIDs for Chip Device Authentication . 34 Table B.5 — Chip Device Authentication (DES/AES) . 34 B.5.2 OIDs for Terminal Device Authentication. 35 Table B.6 — Terminal Authentication (RSA/ECDSA) . 35 B.6 OIDs for privacy protocols . 36 B.6.1 OIDs for Restricted Identification . 36 Table B.7 — OIDs for Restricted Identification . 36 Table B.8 — OIDs for use in certificate extension . 36 B.6.2 OIDs for Restricted Identification . 36 Table B.9 — OIDs for use in auxiliary data verification . 36 B.7 OIDs for mEAC based eServices - OIDs for Terminal Device Authentication in mEAC-based eServices . 36 Table B.10 — OID values for the mEAC Terminal Authentication. 36 B.8 OIDs for the PCA mechanism . 37 Table B.11 — OID for the PCA mechanism . 37 Annex C (informative)
Build scheme for object identifiers defined by EN 419212 . 38 Figure C.1 — Build scheme for mEAC OIDs . 39 Annex D (informative)
Tutorial on Signature Technology . 40 D.1 General . 40 D.2 Signatures and keys . 41 Table D.1 — Generating RSA keys . 42 D.3 Signing documents . 42 D.4 About certificates . 43 D.5 The “chain of trust” . 44 D.6 Multi step signature generation . 44 D.6.1 General . 44 D.6.2 Device authentication protocols . 44 D.6.3 Secure Messaging . 45 D.6.4 Password based device authentication . 45 D.6.5 PIN entry . 45 D.7 Signing the document . 46 SIST EN 419212-1:2018

Annex E (informative)
Guide to the EN 419212 . 47 E.1 From EN 14890 to EN 419212 . 47 E.2 The EU Regulation 910/2014 and the Directive 1999/93/EU . 48 E.3 Secure Elements (SE) . 48 E.4 Specific protection required for contactless integrated circuits . 49 E.4.1 General . 49 E.4.2 Eavesdropping attacks . 49 E.4.3 Skimming attack . 49 E.4.4 Relay attack . 49 E.4.5 Denial of Service (DoS) attack . 49 E.4.6 Countermeasures . 50 E.5 The Human-Machine Interface . 50 E.6 Communications with the ICC and with the user . 50 E.7 Information that should be initally communicated by the ICC to the IFD . 51 E.8 User agreement using PINs . 51 E.9 PIN unlocking. 52 E.10 PIN change . 52 E.11 User agreement using biometric information . 52 E.12 User control using a local display and a local keyboard . 52 E.13 Card applications . 53 E.13.1 General . 53 E.13.2 eSign card application . 53 E.13.3 Device authentication mechanisms . 53 E.13.4 Document Decryption mechanisms . 53 E.14 Signature-/Seal functions . 53 E.14.1 General . 53 E.14.2 Digital signature/seal creation . 54 E.14.3 Digital signature verification . 54 E.14.4 Identification and authentication service . 54 Bibliography . 56
European foreword This document (EN 419212-1:2017) has been prepared by Technical Committee CEN/TC 224 “Furniture”, the secretariat of which is held by AFNOR. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by
March 2018, and conflicting national standards shall be withdrawn at the latest by March 2018. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN shall not be held responsible for identifying any or all such patent rights. This document supersedes EN 419212-1:2014 and EN 419212-2:2014. This standard supports services in the context of electronic IDentification, Authentication and Trust Services (eIDAS) including signatures. In EN 419212-2, the standard allows support of implementations of the European legal framework for electronic signatures, defining the functional and security features for a Secure Elements (SE) (e.g. smart cards) intended to be used as a Qualified electronic Signature Creation Device (QSCD) according to the Terms of the “European Regulation on Electronic Identification and Trust Services for electronic transactions in the internal market” [2]. A Secure Element (SE) compliant to the standard will be able to produce a “qualified electronic signature” that fulfils the requirements of Article of the Electronic Signature Regulation and therefore can be considered equivalent to a hand-written signature [2]. This standard consists of five parts: Part 1: “Introduction and common definitions” describes the history, application context, market perspective and a tutorial about the basic understanding of electronic signatures. It also provides common terms and references valid for the entire 419212 series. Part 2: “Signature and Seal Services” describes the specifications for signature generation according to the eIDAS regulation. 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-1:2018

Introduction Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. The European Committee for Standardization (CEN) draws attention to the fact that it is claimed that compliance with this document may involve the use of a patent concerning the mapping function given in EN 419212-2, clause 8.3.6 “Step 4.2 - Map nonce and compute generator point for integrated mapping”. The patent relates to “Sagem, MorphoMapping Patents FR09-54043 and FR09-54053, 2009”. CEN takes no position concerning the evidence, validity and scope of this patent right. The holder of this patent right has ensured CEN that he/she is willing to negotiate licences under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the holder of this patent right is registered with CEN. Information may be obtained from: Morpho 11, boulevard Galliéni 92445 Issy-les-Moulineaux Cedex Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other than those identified above. CEN shall not be held responsible for identifying any or all such patent rights. SIST EN 419212-1:2018

1 Scope This part is an informative introduction into the following parts. It gives guidance to the following parts in order to allow an efficient usage of the provided information. Therefore Part 1 provides history, application context, market perspective and a tutorial about the basic understanding of electronic signatures.
Clause 3 provides “Terms and definitions” covering all parts of this standards. The specific parts will contain a similar section which refers to the clause of this Part 1.
Clause 4 provides “Symbols and abbreviations” covering all parts of this standards. The specific parts will contain a similar section which refers to the clause of this Part 1.
Clause 5 provides a Management Summary that describes the market context in which electronic signatures are typically
Annex A provides the algorithm identifies for all parts of the standard.
Annex B provides the algorithm identifies for all parts of the standard.
Annex C provides the build scheme for object identifiers for all parts of the standard.
Annex D “Tutorial on Signature Technology” provides a tutorial which helps the first reader to get familiar with signature technology and its relation to the society that it serves.
Annex E “Guide to the EN 419212” explains the historical and technical evolution of the ESIGN activities which did finally lead to this version of the signature standard. 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-3:2006, Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical interface and transmission protocols ISO/IEC 9796-2:2010, Information technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Integer factorization based mechanisms ISO 7498-2, Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture 3 Terms and definitions For the purposes of Part 1 to 5 of this series of standards, the following terms and definitions apply. NOTE These definitions are in compliance with those given in the revision of ISO/IEC 7816-4. 3.1 advanced electronic seal electronic seal which meets the following requirements: a) it is uniquely linked to the creator of the seal; b) it is capable of identifying the creator of the seal; SIST EN 419212-1:2018

c) it is created using electronic seal creation data that the creator of the seal can, with a high level of confidence under its control, use for electronic seal creation; and d) it is linked to the data to which it relates in such a way that any subsequent change in the data is detectable; 3.2 advanced electronic signature data in electronic form which are attached to or logically associated with other electronic data to ensure the origin and the integrity of the associated data electronic signature which meets the following requirements: a) it is uniquely linked to the signatory; b) it is capable of identifying the signatory c) it is created using means that the signatory can maintain under his sole control; d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable 3.3 anonymity assurance that a user may use a resource or service without disclosing their user identity 3.4 anonymization process that removes the association between an identifying data set and a data subject 3.5 anonymized data data that was once linked to an individual but can now no longer be related to them 3.6 anonymous data data that cannot be linked to a specific individual 3.7 answer-to-Reset file elementary file which indicates operating characteristics of the card 3.8 a priori trusted operating environment which by definition can be trusted without further device authentication Example: An example of this is the use within a company, where any available access point is connected to a trusted network. 3.9 authentication electronic process that allows the confirmation of the electronic identification of a natural or legal person; or of the origin and integrity of an electronic data SIST EN 419212-1:2018

3.10 certificate for electronic signature electronic attestation which links electronic signature validation data to a natural person and confirms at least the name or the pseudonym of that person 3.11 command-response pair set of two messages: a command followed by a response 3.12 confidentiality protection prevention of information disclosure to unauthorized individuals, entities or systems [ISO 7498-2] 3.13 creator of seal legal person who creates an electronic seal 3.14 data unit smallest set of bits which can be unambiguously referenced 3.15 data element item of information seen at the interface for which are defined a name, a description of logical content, a format and a coding 3.16 data object information seen at the interface which consists of a tag, a length and a value (i.e., a data element) Note 1 to entry: In this specification, data objects are referred to as BER-TLV data objects. Refer to ISO/IEC 7816-4. 3.17 dedicated file file containing file control information and, optionally, memory available for allocation. It may be the parent of EFs and/or DFs 3.18 device authentication process of validating the credentials of a device 3.19 DF name string of bytes which uniquely identifies a dedicated file in the card 3.20 digital signature data appended to – or a cryptographic transformation of – a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery, e.g. by the recipient SIST EN 419212-1:2018

3.21 electronic seal data in electronic form which are attached to or logically associated with other electronic data to ensure the origin and the integrity of the associated data 3.22 electronic seal creation device configured software or hardware used to create an electronic seal 3.23 electronic signature data in electronic form which are attached to or logically associated with other electronic data and which are used by the signatory to sign 3.24 electronic signature creation device configured software or hardware used to create an electronic signature 3.25 qualified electronic seal advanced electronic seal which is created by a qualified electronic seal creation device, and which is based on a qualified certificate for an electronic seal. A qualified certificate is specified in [eIdasReg#1] 3.26 qualified electronic seal creation device electronic seal creation device that creates a qualified electronic seal 3.27 qualified electronic signature creation device electronic signature creation device which meets the requirements as follows: 1. It shall ensure, by appropriate technical and procedural means, that at least: a) the confidentiality of the electronic signature creation data used for electronic signature creation is reasonably ensured; b) the electronic signature creation data used for electronic signature creation can practically occur only once; c) the electronic signature creation data used for electronic signature creation cannot, with reasonable assurance, be derived and the electronic signature is reliably protected against forgery using currently available technology; d) the electronic signature creation data used for electronic signature creation can be reliably protected by the legitimate signatory against use by others 2. Qualified electronic signature creation devices shall not alter the data to be signed or prevent such data from being presented to the signatory prior to signing 3. Generating or managing electronic signature creation data on behalf of the signatory may only be done by a qualified trust service provider SIST EN 419212-1:2018

4. Without prejudice to point (d) of point 1, qualified trust service providers managing electronic signature creation data on behalf of the signatory may duplicate the electronic signature creation data only for back-up purposes provided the following requirements are met: a) the security of the duplicated data sets must be at the same level as for the original data sets; b) the number of duplicated data sets shall not exceed the minimum needed to ensure continuity of the service 3.28 elementary file set of data units or records which share the same file identifier. It cannot be the parent of another file 3.29 file control parameters logical, structural and security attributes of a file 3.30 file identifier 2-bytes binary value used to address a file 3.31 forward secrecy security property of a protocol, that guarantees that the disclosure of long-term private key does not enable an opponent to compromise the secrecy property of the executions of the protocol made in the past, for example, by re-computing previously derived keys 3.32 identification unique association of a set of descriptive parameters to an individual within a given context 3.33 integrity protection integrity protection is a mechanism ensuring that data cannot be modified undetectably 3.34 master file mandatory unique dedicated file representing the root of the file structure 3.35 message string of bytes transmitted by the interface device to the card or vice-versa, excluding transmission-oriented characters as defined in ISO/IEC 7816-3 3.36 mutual authentication authentication where both parties (ICC and IFD) are authenticated to each other 3.37 non-traceability refer to traceless authentication SIST EN 419212-1:2018

3.38 parent file dedicated file immediately preceding a given file within the hierarchy 3.39 password data which may be required by the application to be presented to the card by its user. A password in the context of this specification is a string of numbers and/or ASCII characters 3.40 path concatenation of file identifiers without delimitation. If the path starts with the identifier of the master file, it is an absolute path 3.41 privacy privacy is the claim of individuals, groups, or institutions to determine for themselves when, how, and to what extent information about them is communicated to others [ISO 7498-2] 3.42 private key that key of an entity's asymmetric key pair that should only be used by that entity 3.43 pseudonym identifier that contains sufficient information to allow a verifier to establish a unique link to an entity Note 1 to entry: A pseudonym can be used to reduce privacy risks that are associated with the use of identifiers with fixed or known values. Note 2 to entry: A pseudonym can be an identifier with a value chosen by the person, or assigned randomly. 3.44 pseudonymisation particular type of anonymization that both removes the association with a data subject and adds an association between a particular set of characteristics relating to the data subject and one or more pseudonyms 3.45 pseudonymised data data that can only be linked to such a person if one has possession of a decoding “key” 3.46 pseudonymity pseudonymity is the ensurance that a user may use a resource or service without disclosing its user identity but can still be accountable for its use 3.47 public key public part of an asymmetric key pair SIST EN 419212-1:2018

3.48 qualified electronic signature advanced electronic signature which is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures 3.49 record string of bytes which can be handled as a whole by the card and referenced by a record number 3.50 record number sequential number assigned to each record which uniquely identifies the record within its elementary file 3.51 retry counter counter being used to count the number of erroneous usages of a related (security) object. If the object (e.g. password entry) was used correctly (correct password entered) then the retry counter is reset to its initial value. A typical value of a retry counter is 3 3.52 secret key key used in symmetric algorithms 3.53 security environment condition of use of objects in the card including stored data and data processing functions, expressed as a data element containing one or more access rules 3.54 signatory natural person who creates an electronic signature 3.55 signature creation device secure device which is able to create a signature from its stored data and functionality 3.56 traceless authentication traceless authentication is an authentication which does not give any persistent cryptographic proof that the authentication has occurred 3.57 trustable environment operating environment that avoids tampering with data seen at the communication interface by the definition of its physical location, physical security protection or physical access conditions or other measures 3.58 trusted environment environment the user has decided to trust Note 1 to entry:
In very few cases it is possible for a user to decide whether an evironment ist trustable or not. Therefore it is highly recommended that if a user ist not sure that an environment is a-priori trusted, not to enter SIST EN 419212-1:2018

a PIN until a display message indicates the evidence of secure messaging (which implies the trustable environment). 3.59 trusted channel means by which a TSF and a remote trusted IT product can communicate with the necessary confidence to support the TSP 3.60 trusted path means by which a user and a TSF can communicate with the necessary confidence to support the TSP 3.61 unlinkability assurance that a user may make multiple uses of resources or services without others being able to link these uses together [ISO 7498-2] 3.62 untrustable environment operating environment that does not prevent tampering and intrusion of data available at the communication interface. An environment which is not a priori trustable and which cannot prove trustability through a device authentication, must be considered as untrustable. No further operations should be done by the card holder on an untrustable environment 3.63 untrusted environment operating environment which is not known to be trustable. Until a proof of confidence is given (typically through a device authentication) the environment should not be sent any sensitive data from the cardholder, in particular a PIN Note 1 to entry: After a successful device authentication, untrusted environment turns into trusted environment. Therefore the quality 'untrusted' does not imply 'untrustable' but the requirement of trust verification. 3.64 usage counter counter updated each time a related object is used. Unlike retry counters, usage counters are not reset to their initial value after the object was successfully used 3.65 user consent expression of the act-of-will to a card related service 3.66 usage of expressions in this standard key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [4] MUST: This word, or the terms “REQUIRED” or “SHALL”, means that the definition is an absolute requirement of the specification MUST NOT: This phrase, or the phrase “SHALL NOT”, means that the definition is an absolute prohibition of the specification SIST EN 419212-1:2018

SHOULD: This word, or the adjective “RECOMMENDED”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications shall be understood and carefully weighed before choosing a different course SHOULD NOT: This phrase, or the phrase “NOT RECOMMENDED” means that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label. MAY: This word, or the adjective “OPTIONAL”, means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option SHALL be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality [ … ]
Square brackets indicate a freedom of choice. This can be either a
- choice of values in a given range ['00' . '03'] – typical for fixed length fields,
- or a choice whether to present a value or not – … || '80' L80 AlgID || ['83' L83 KeyId] …. whereas the set of data in square brackets is the optional part (= at the discretion of the implementation) or conditional (= depending on a condition given in the standard) CONDITIONAL: The application of a specification depends on one or more conditions and shall only be applied if the condition(s) are met. The associated condition(s) are always described if a conditional attribute is made with a specification. If the conditions are met, the specification may be normative or informative depending on the context in which the specification is made 4 Symbols and abbreviations For the purposes of Part 1 to 5 of this series of standards, the following symbols and abbreviations apply. NOTE These definitions are in compliance with those given in the revision of ISO/IEC 7816-4. AES Advanced Encryption Standard AID Application Identifier APDU Application protocol data unit AKI Authority Key Identifier AT Authentication Template, CRT for Authentication AUT Authentication BCD Binary Coded Decimal BER Basic Encoding Rules C Certificate CA Certification Authority CAR CA Reference CC Cryptographic Checksum CDA Card Device Authentication CG Cryptogram SIST EN 419212-1:2018

CH Cardholder CHA Certificate Holder Authorization CHN Cardholder Name CHR Certificate Holder Reference CIA Cryptographic Information Application CIO Cryptographic Information Object CLA Class byte Comp() The public key compression function Comp(…) is defined in EN 419212-2, clause 11.6 CRT Control Reference Template CPI Certificate Profile Identifier CRT Control Reference Template CS CertSign, certificate containing the public part of a signature key pair CT CRT for confidentiality CV Card Verifiable CVC Card Verifiable Certificate CWA CEN Workshop Agreement C/S Client/Server D[key](msg) Decipherment of < msg > with < key >
DE Data Element DES Data Encryption Standard DF Dedicated File DH Diffie-Hellman DH.P DH parameters, DH.P = g || p || q DIR Directory DO Data Object DS[key](msg) Digital Signature of < msg > with < key >
DSA Digital Signature Algorithm DSI Digital Signature Input DST Digital Signature Template, CRT for DS DTBS Data to be signed DTBS/R Data to be signed remotely E[key](msg) Encipherment of < msg > with < key >
ECC European Citizen Card ECDH DH key agreement based on elliptic curve cryptography (ELC) ECDH.P ECDH parameters based on elliptic curve cryptography. ECDH.P = p || a || b || G || n ECDSA Signature Scheme based on elliptic curve cryptography (ELC) SIST EN 419212-1:2018

ELC Elliptic Curve Cryptography EDFB Encrypted Data Formatted Block eIDAS Electronic Identification and Authentication Services FCI File Control Information FID File Identifier h(msg) hash-code of < msg >
HT CRT for hash code ICC Integrated Circuit(s) Card ICV Initial Chaining Value ID Identifier IFD Interface Device INS Instruction byte KE Key Encipherment KID Key Identifier L.F Length of elliptic curve parameter MAC[key](msg) Message Authentication Code of < msg > built with < key >
MF Master File MSE MANAGE SECURITY ENVIRONMENT OAEP Optimal Asymmetric Encryption Padding OID Object Identifier P1-P2 Parameter bytes PBM Password based mechanism PCA Privacy based Chip Authentication PrK Private Key PuK Public Key PKI Public Key Infrastructure PKCS Public Key Cryptography Standards PI Padding Indicator PIN Personal Identification Number PP Protection Profile PRND Padding Random Number PSO PERFORM SECURITY OPERATION PSS Probabilistic Signature Scheme QES Qualified Electronic Signature QSCD Qualified Signature Creation Device RC Retry Counter SIST EN 419212-1:2018

RCA RootCA RD Reference Data RFU Reserved for Future Use RID Registered application provider indentifier RND Random number RSA Cryptographic algorithm invented by Ronald Rivest, Adi Shamir and Leonard Adleman SCA Signature-Creation Application SHA Secure Hash Algorithm SE Security Environment SIG() Signature of SK Secret Key SN Serial Number SM Secure Messaging SSC Send Sequence Counter SSCD Secure Signature Creation Device SW1-SW2 Status bytes TDA Terminal Device Authentication TDES Triple-DES, this standard only considers the 2-key variant TOE Target Of Evaluation TPDU Transmission Protocol Data Unit TLS Transport Layer Security TLV Tag, Length, Value TSF TOE Security Functions TSP TOE Security Policy xP x-coordinate of elliptic curve point P yP y-coordinate of elliptic curve point P 5 Management Summary 5.1 Motivation Nowadays, the increase in electronic exchanges benefits to the development of transactions in an electronic way. In order to validate the consent of stakeholders involved in a dematerialized transaction, it is necessary to develop a technology such as electronic signature. Let's regards signing a contract between two business partners, possibly in different countries. Whenever they need to countersign documents during their business relationships, it may take them weeks until a deal is done, because of all the paperwork that needs to be physically sent back and forth. If the two business partners use electronic signatures, they can close their deals in a matter minutes, not weeks. They just have to use the digital signature tools available in their IT environment, e.g. SIST EN 419212-1:2018

selecting the document, using a right click with the mouse, sign it digitally applying the personal PIN code and send it via eMail. This is a complete paperless process, and a electronic signature is just as valid as one made with ink on paper. In the meantime, an electronic signature is no more limited to a desktop environment. Nowadays, mobile usage of dig
...