EN 419212-2:2014

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Uporabniški vmesnik za pametne kartice, ki se uporabljajo kot naprave za izdelovanje varnega podpisa - 2. del: Dodatne storitveAnwendungsschnittstelle für Chip-Karten, die zur Erzeugung qualifizierter elektronischer Signaturen verwendet werden - Teil 2: Zusätzliche DiensteInterface applicative des cartes à puces utilisées comme dispositifs de création de signature numérique sécurisés - Partie 2: Services complémentairesApplication Interface for smart cards used as Secure Signature Creation Devices - Part 2: Additional Services35.240.15Identifikacijske kartice in sorodne napraveIdentification cards and related devicesICS:Ta slovenski standard je istoveten z:EN 419212-2:2014SIST EN 419212-2:2015en,fr,de01-april-2015SIST EN 419212-2:2015SLOVENSKI
STANDARDSIST EN 14890-2:20091DGRPHãþD

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 419212-2
December 2014 ICS 35.240.15 Supersedes EN 14890-2:2008English Version
Application Interface for smart cards used as Secure Signature Creation Devices - Part 2: Additional services
Interface applicative des cartes à puces utilisées comme dispositifs de création de signature numérique sécurisés - Partie 2 : Services complémentaires
Anwendungsschnittstelle für Chip-Karten, die zur Erzeugung qualifizierter elektronischer Signaturen verwendet werden - Teil 2: Zusätzliche Dienste This European Standard was approved by CEN on 27 September 2014.
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
CEN-CENELEC Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2014 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 419212-2:2014 ESIST EN 419212-2:2015

Security Service Descriptor Templates . 91 A.1 Security Service Descriptor Concept . 91 A.2 SSD Data Objects . 92 A.2.1 DO Extended Header List, tag ‘4D’ . 92 A.2.2 DO Instruction set mapping (ISM), tag ‘80’ . 92 A.2.3 DO Command to perform (CTP), tag ‘52’ (refer to ISO/IEC 7816-6) . 92 A.2.4 DO Algorithm object identifier (OID), tag ‘06’ (refer to ISO/IEC 7816-6) . 92 A.2.5 DO Algorithm reference, tag ‘81’ . 92 A.2.6 DO Key reference, tag ‘82’ . 93 A.2.7 DO FID key file, tag ‘83’ . 93 A.2.8 DO Key group, tag ‘84’ . 93 A.2.9 DO FID base certificate file, tag ‘85’ . 93 A.2.10 DO FID adjoined certificate file, tag ‘86’ . 93 A.2.11 DO Certificate reference, tag ‘87’ . 93 A.2.12 DO Certificate qualifier, tag ‘88’ . 93 A.2.13 DO FID for file with public key of the certification authority PK(CA), tag ‘89’ . 93 A.2.14 DO PIN usage policy, tag ‘5F2F’ . 93 A.2.15 DO PIN reference, tag ‘8A’ . 94 A.2.16 DO Application identifier (AID), tag ‘4F’ (refer to ISO/IEC 7816-6). 94 A.2.17 DO CLA coding, tag ‘8B’ . 94 A.2.18 DO Status information (SW1-SW2), tag ‘42’ (refer to ISO/IEC 7816-6) . 94 A.2.19 DO Discretionary data, tag ‘53’ (refer to ISO/IEC 7816-6) . 94 A.2.20 DO SE number, tag ‘8C’ . 94 A.2.21 DO SSD profile identifier, tag ‘8D’ . 95 A.2.22 DO FID mapping, tag ‘8E’. 95 A.3 Location of the SSD templates . 95 A.4 Examples for SSD templates . 95 Annex B (informative)
Security environments . 97 B.1 Definition of CRTs (examples) . 98 B.1.1 CRT for Authentication (AT) . 99 B.1.2 CRT for Cryptographic Checksum (CCT) . 100 B.1.3 CRT for Digital Signature (DST) . 101 B.1.4 CRT for confidentiality (CT) . 102 B.2 Security Environments (example) . 103 B.2.1 Security Environment #10 . 103 B.2.2 Security Environment #11 . 104 B.3 Coding of access conditions (example) . 104 SIST EN 419212-2:2015

Algorithm Identifiers — Coding and specification . 110 Annex D (informative)
Example of DF.CIA . 117 Annex E (informative)
Build scheme for object identifiers defined by EN 14890 . 122 Bibliography . 124
It also specifies additional mechanisms like key decipherment, Client Server authentication, identity management
and privacy related services. 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. EN 419212-1:2014, Application Interface for smart cards used as Secure Signature Creation Devices — Part 1: Basic services ISO/IEC 7816-4:2013, Identification cards — Integrated circuit(s) cards with contacts — Part 4: Organization, security and commands for interchange
ISO/IEC 7816-6:2006, Identification cards — Integrated circuit(s) cards with contacts — Part 6: Interindustry data elements for interchange ISO/IEC 7816-8:2004, Integrated circuit(s) cards with contacts — Part 8: Commands for security operations ISO/IEC 9796 (all parts), Information technology — Security techniques — Digital signature schemes giving message recovery ISO/IEC 9797-1, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher 3 Terms and definitions For the purposes of this document, 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 anonymity assurance in which a user may use a resource or service without disclosing the user's identity 3.2 anonymization
process that removes the association between an identifying data set and a data subject 3.3 anonymized data data that was once linked to an individual but can now no longer be related to them 3.4 anonymous data data that cannot be linked to a specific individual 3.5 C/S external authentication authentication of the server by the client SIST EN 419212-2:2015

SHALL NOT: This phrase, or the phrase "SHALL NOT", means that the definition is an absolute prohibition of the specification.
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 will 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 SIST EN 419212-2:2015

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 will 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 Abbreviations and notation For the purposes of this document, the following symbols and abbreviations apply. APDU Application Protocol Data Unit ARR Access Rule Record AT Authentication Template C/S Client-Server CA Certification Authority CC Cryptographic Checksum CCT Cryptographic Checksum Template CIA Cryptographic Information Application CLA Class byte
CMS Card Management System CRT Control Reference Template CT Confidentiality Template CV Card Verifiable D[key](msg) Decipherment of with DF Dedicated File DH Diffie-Hellman DO Data Object DS[key](msg) Digital Signature of with DSI Digital Signature Input DST Digital Signature Template E[key](msg) Encipherment of with ECDSA Signature Scheme based on elliptic curve cryptography (ELC) EF Elementary File
MF Master File OAEP Optimal Asymmetric Encryption Padding P1-P2 Parameter bytes PI Padding Indicator PrK Private Key PuK Public Key PKI Public Key Infrastructure PKCS Public Key Cryptography Standards PBM Password based mechanism PSO PERFORM SECURITY OPERATION PSS Probabilistic Signature Scheme RA Role authentication RCA Root CA RFU Reserved for Future Use RND Random Number RSA Cryptographic algorithm invented by Ronald Rivest, Adi Shamir and Leonard Adleman SE Security Environment SFI Short File Identifier SHA Secure Hash Algorithm SK Secret Key SN Serial Number SM Secure Messaging SSCD Secure Signature Creation Device SSD Security Service Descriptor SW1-SW2 Status bytes TDES Triple-DES, this standard only considers the 2-key variant UQB Usage Qualifier Byte SIST EN 419212-2:2015

Figure 2 — Example of additional service selection 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.
– 1-byte Algorithm-ID coding. The DSI format according to PKCS #1 V 2.1 has the following structure. The message M represents the authentication input T. HashAlgorithmAuthenticationInput(anynumberofbits)RNGHashSalt(Hbytes)'00.(8bytes).'00'M'DBmaskedDBHash(M’)DSIDSIdmodNd(priv.exp)DS(2048bits)N(2048bits)'00.00''01'Salt(Hbytes)Hash(M')MzeroizeleftmostbitsMGF1mgfSeed=Hash(M')'BC'IFD'sactionICC'sactionHashAlgorithmconditional(seetext)conditional(seetext) Figure 5 — Example for 2048 bit DSI according to PKCS #1 V2.1 Figure 5 shows an example for the DSI computation according to PKCS #1 V2.1. Building the first hash in the IFD is an optional step and appropriate, if the message M is large and the transmission of this large message M would required exhaustive data transmission to the ICC. The hashing function used in MGF1 is the same as the one used to hash the authentication input. The [8 x Key.ModulusByteLength — (Key.ModulusBitLength — 1)] leftmost bits of the output of the MGF1 function are set to zero to provide a DSI input being arithmetically smaller than the modulus N. The MGF1 function is described in [2] [PKCS 1 — V.2.1, Chapter B.2.1]. SIST EN 419212-2:2015

The [8 x Key.ModulusByteLength - (Key.ModulusBitLength - 1)] leftmost bits of dbmask are set to zero to provide a DSI input being arithmetically smaller than the modulus N. The hashing function used in MGF1 is the same as the one used to hash the authentication input. The [8 x Key.ModulusByteLength — (Key.ModulusBitLength — 1)] leftmost bits of the output of the MGF1 function are set to zero to provide a DSI input being arithmetically smaller than the modulus N. Table 1 — Digital Signature Input (DSI) — Format acc. to PKCS #1 V 2.x T L V — — masked DB = DB ⊕ MGF1(Hash(M’), Key.ByteLength — H — 1) Hash(M’) ‘BC’ = Padding according to the ISO/IEC 9796 series (option 1)
6.3.3 Building the DSI on ECDSA No hash shall be internally computed by the ICC. The size of the DSI shall not be greater than the size of the order of the base point (this point is relevant in particular for elliptic curves whose prime length is not a multiple of eight bits – e.g. P-521). SIST EN 419212-2:2015

application specific protocol flow INTERNAL AUTHENTICATION — server (IFD) authenticates client (ICC) 2 1 READ BINARY of certificate (typically X.509)
certificate 2 MSE:SET PrK.CH.AUT
3 INTERNAL AUTHENTICATE or COMPUTE DIGITAL SIGNATURE
Client (ICC) is authenticated to server (IFD) 3 — . subsequent steps that are application specific to present client/server authentication
not specified in this document
6.4.1 Step 1 — Read certificate If the IFD does not already have the client's (ICC) authentication certificate, it may read it from a global data file EF.C.CH.AUT. The client’s certificate C.CH.AUT may contain public algorithm quantities which depend on the client/server authentication algorithm. Execution Flow Table 3 — Read EF.C.CH.AUT — command APDU Command Parameter Meaning CLA according to ISO/IEC 7816-4 INS ‘B0’ READ BINARY P1 ‘85’ Example: SFI = 05 P2 ‘00’ offset = 0 Le field ‘00’
For the structure and content of the APDU refer to ISO/IEC 7816-4:2013, 11.2.3. The structure and coding of C.CAICC.CS_AUT may be as described in section 15.13 "C_CV.CA.CS-AUT (non self-descriptive)", but it could also be some other certificate format unknown to the ESIGN application. The actual format is application specific and out of the scope of this standard. SIST EN 419212-2:2015

Unless the READ BINARY selects the file using a Short File Identifier (SFI), an appropriate SELECT(EF) command shall be executed prior to reading the file. 6.4.2 Step 2 — Set signi
...