SIST EN 419212-2:2015
(Supplement)Application Interface for smart cards used as Secure Signature Creation Devices - Part 2: Additional Services
Application Interface for smart cards used as Secure Signature Creation Devices - Part 2: Additional Services
Maintenance of EN14890-2 according
- consistency
- technical / editorial mistakes
- current technical state of the art (e.g. new decipherment services for elliptic curves and privacy services as restricted identification and age verification)
- clarification on necessary features for the respective contexts e.g. application profiles
New formally proved privacy protocols e.g. for Id management
Physical, electrical and transport protocol characteristics are out of the scope of this standard
Anwendungsschnittstelle für Chip-Karten, die zur Erzeugung qualifizierter elektronischer Signaturen verwendet werden - Teil 2: Zusätzliche Dienste
Interface applicative des cartes à puces utilisées comme dispositifs de création de signature numérique sécurisés - Partie 2: Services complémentaires
La Partie 2 de cette série comprend les services IAS (Identification, Authentification et Signature numérique) en plus des mécanismes SSCD déjà décrits dans la Partie 1 pour permettre l’interopérabilité et l’utilisation des services IAS au niveau national ou européen.
Elle spécifie également des mécanismes supplémentaires tels que le déchiffrement de clé, l'authentification client/serveur, la gestion des identités et les services liés à la protection de la vie privée.
Uporabniški vmesnik za pametne kartice, ki se uporabljajo kot naprave za izdelovanje varnega podpisa - 2. del: Dodatne storitve
Vzdrževanje standarda EN14890-2 v povezavi z naslednjim
– skladnost
– tehnične/uredniške napake
– trenutno stanje tehničnega razvoja (npr. nove storitve dešifriranja za eliptične krivulje in storitve zasebnosti, kot sta omejena identifikacija in preverjanje starosti)
– pojasnitev potrebnih funkcij za zadevna okolja, npr. profili aplikacije
Novi uradno dokazani protokoli za zagotavljanje zasebnosti, npr. upravljanje ID-jev
Fizične, električne in transportne značilnosti protokola ne spadajo na področje uporabe tega standarda.
General Information
Relations
Standards Content (Sample)
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
SIST EN 419212-2:2015
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
EN 419212-2:2014 (E) 2 Contents Foreword .5 1 Scope .7 2 Normative references .7 3 Terms and definitions .7 4 Abbreviations and notation .9 5 Additional Service Selection . 11 6 Client/Server Authentication . 14 6.1 Client/Server protocols . 14 6.2 Steps preceding the client/server authentication . 15 6.3 Padding format . 15 6.3.1 PKCS #1 v 1-5 Padding . 15 6.3.2 PKCS #1 V 2.x (PSS) Padding . 16 6.3.3 Building the DSI on ECDSA . 17 6.4 Client/Server protocol . 18 6.4.1 Step 1 — Read certificate . 18 6.4.2 Step 2 — Set signing key for client/server internal authentication . 19 6.4.3 Step 3 — Internal authentication . 20 6.4.4 Client/Server authentication execution flow . 22 6.4.5 Command data field for the client server authentication . 24 7 Role Authentication . 25 7.1 Role Authentication of the card . 25 7.2 Role Authentication of the server . 25 7.3 Symmetrical external authentication . 25 7.3.1 Protocol . 25 7.3.2 Description of the cryptographic mechanisms . 30 7.3.3 Role description . 30 7.4 Asymmetric external authentication . 31 7.4.1 Protocol based on RSA . 31 7.4.2 Protocol based on modular Enhanced Role Authentication (mERA) . 34 8 Symmetric key transmission between a remote server and the ICC . 49 8.1 Steps preceding the key transport. 49 8.2 Key encryption with RSA . 49 8.2.1 PKCS#1 v1.5 padding . 50 8.2.2 OAEP padding . 50 8.2.3 Execution flow . 51 8.3 Diffie-Hellman key exchange for key encipherment . 54 8.3.1 Execution flow . 56 9 Signature verification . 58 9.1 Signature verification execution flow . 58 9.1.1 Step 1: Receive Hash . 59 9.1.2 Step 2: Select verification key . 60 9.1.3 Step 3: Verify digital signature . 61 10 Certificates for additional services . 62 10.1 File structure . 63 10.2 EF.C_X509.CH.DS . 63 10.3 EF.C.CH.AUT . 63 10.4 EF.C.CH.KE . 63 10.5 Reading Certificates and the public key of CAs . 64 11 Privacy Context functions . 65 SIST EN 419212-2:2015
EN 419212-2:2014 (E) 3 11.1 Introduction . 65 11.2 Auxiliary Data Comparison. 65 11.2.1 Presentation of the auxiliary data . 66 11.2.2 Age Verification . 68 11.2.3 Document Validation . 69 11.3 Restricted Identification . 70 11.3.1 Command APDU for Step RI:1 . 73 11.3.2 Command APDU for Step RI:2 . 74 11.4 eServices with trusted third party protocol . 77 11.4.1 mERA-based eServices with trusted third party protocol . 78 11.4.2 mEAC-based eServices with trusted third party . 83 11.5 eServices with two party protocols . 86 11.5.1 mEAC-based eServices with on-line two party protocol . 86 11.5.2 mEAC-based eServices with off-line two party protocol . 87 12 APDU data structures . 89 12.1 Algorithm Identifiers . 89 12.2 CRTs . 89 12.2.1 CRT DST for selection of ICC’s private client/server auth. key . 89 12.2.2 CRT AT for selection of ICC’s private client/server auth. key . 89 12.2.3 CRT CT for selection of ICC’s private key . 90 12.2.4 CRT DST for selection of IFD’s public key (signature verification) . 90 Annex A (normative)
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
EN 419212-2:2014 (E) 4 B.3.1 Access Conditions. 105 B.3.2 Access rule references . 106 B.3.3 Access conditions for EF.ARR . 107 B.3.4 EF.ARR records . 107 Annex C (normative)
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
SIST EN 419212-2:2015
EN 419212-2:2014 (E) 5 Foreword This document (EN 419212-2:2014) has been prepared by Technical Committee CEN/TC 224 "Personal identification, electronic signature and cards and their related systems and operations", 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 June 2015 and conflicting national standards shall be withdrawn at the latest by June 2015. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights. This document supersedes EN 14890-2:2008. This document has been prepared under a mandate given to CEN by the European Commission and the European Free Trade Association. EN 419212, Application Interface for smart cards used as Secure Signature Creation Devices, consists of two parts: • Part 1: Basic services which describes the specifications for IAS based services on smart cards to be used in compliance to the requirements of Article 5.1 of the Electronic Signature Directive; and • Part 2: Additional services [the present document] which describes other services that may be used in conjunction with all, some or none of the services described in Part 1. This standard supports services in the context of IAS Identification, Authentication and Electronic Signature (IAS) services, as well as other services. In EN 419212-1, the standard allows to support the implementation of the European legal framework for electronic signatures, defining the functional and security features for a smart card intended to be used as a Secure Signature Creation Device according to the Terms of the European Directive on Electronic Signature 1999/93/EC. A card compliant to the standard will be able to produce a "Qualified Electronic Signature (QES)" that fulfils the requirements of Article 5.1 of the Electronic Signature Directive and therefore can be considered equivalent to hand-written signatures. In EN 419212-2, the standard specifies mechanisms to support other services like generic Identification, Authentication, confidentiality, signature verification services and privacy features. EN 419212 defines a set of services that will enable the development of interoperable cards issued by any card industry sector. The standard will describe an application interface and behavior of the SSCD, i.e. it should be possible to implement it on native and interpreter based cards. Compared with the 2008 versions of EN 14890, the following broad change has been made: The scope of the standard was enhanced through new mechanisms in the field of password based mechanisms and privacy. Regarding EN 419212-1, the most significant technical changes that have been made are the following ones: – new algorithms added to device authentication protocols (e.g. AES, ELC); – added AES to secure messaging; SIST EN 419212-2:2015
EN 419212-2:2014 (E) 6 – introduced password based mechanisms (PACEv2); – updating references to their latest releases; – algorithm Identifier coding; – recommendation for making best use of device authentication protocols. Regarding EN 419212-2, the most significant technical changes that have been made are the following ones: a) Added privacy services including: 1) anonymity and pseudonymity services; 2) auxiliary data transmission e.g. for Age verification; 3) e-Services with trusted third party; 4) e-Services with 2-parties. According to the CEN-CENELEC Internal Regulations, the national standards organizations 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, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 419212-2:2015
EN 419212-2:2014 (E) 7 1 Scope This European Standard contains Identification, Authentication and Digital Signature (IAS) services in addition to the SSCD mechanisms already described in EN 419212-1 to enable interoperability and usage for IAS services on a national or European level.
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
EN 419212-2:2014 (E) 8 Note 1 to entry: The client is regarded as the combination of the PC and the ICC. This external authentication is out of the scope of this specification. 3.6 C/S internal authentication authentication of the client by the server Note 1 to entry: The client is regarded as the combination of the PC and the ICC. 3.7 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.8 identification unique association of a set of descriptive parameters to an individual within a given context 3.9 IFD device or entity that belongs to the external world (outside the ICC) 3.10 privacy claim of individuals, groups, or institutions to determine for themselves when, how, and to what extent information about them is communicated to others 3.11 pseudonymity ensurance that a user may use a resource or service without disclosing its user identity 3.12 secured channel communication link between the ICC and a security module (possibly also an ICC) that provides authenticity and/or integrity and/or confidentiality 3.13 unlinkability assurance that a user may make multiple uses of resources or services without others being able to link these uses together [14] 3.14 usage of expressions in this standard use of the key words "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document as to be interpreted as described in [21] Note 1 to entry: See the following list of key-words: SHALL: This word, or the terms "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the specification.
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
EN 419212-2:2014 (E) 9 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 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 A
...
SLOVENSKI STANDARD
oSIST prEN 14890-2:2012
01-maj-2012
Uporabniški vmesnik za pametne kartice, ki se uporabljajo kot naprave za
izdelovanje varnega podpisa - 2. del: Dodatne storitve
Application Interface for smart cards used as Secure Signature Creation Devices - Part
2: Additional Services
Anwendungsschnittstelle für Chip-Karten, die zur Erzeugung qualifizierter elektronischer
Signaturen verwendet werden - Teil 2: Zusätzliche Dienste
Interface applicative des cartes à puces utilisées comme dispositifs de création de
signature numérique sécurisés - Partie 2: Services complémentaires
Ta slovenski standard je istoveten z: prEN 14890-2
ICS:
35.240.15 Identifikacijske kartice in Identification cards and
sorodne naprave related devices
oSIST prEN 14890-2:2012 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 14890-2:2012
---------------------- Page: 2 ----------------------
oSIST prEN 14890-2:2012
EUROPEAN STANDARD
DRAFT
prEN 14890-2
NORME EUROPÉENNE
EUROPÄISCHE NORM
March 2012
ICS 35.240.15 Will supersede EN 14890-2:2008
English Version
Application Interface for smart cards used as Secure Signature
Creation Devices - Part 2: Additional Services
Interface applicative des cartes à puces utilisées comme Anwendungsschnittstelle für Chip-Karten, die zur
dispositifs de création de signature numérique sécurisés - Erzeugung qualifizierter elektronischer Signaturen
Partie 2: Services complémentaires verwendet werden - Teil 2: Zusätzliche Dienste
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee CEN/TC 224.
If this draft becomes a European Standard, 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.
This draft European Standard was established by CEN 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, 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.
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.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2012 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 14890-2:2012: E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
Contents
Foreword .3
1 Scope .4
2 Normative references .4
3 Terms and definitions .5
4 Abbreviations and notation .6
4.1 Abbreviations .6
5 Additional Service Selection .8
6 Client/Server Authentication . 10
6.1 Client/Server protocols . 10
6.2 Steps preceding the client/server authentication . 10
6.3 Padding format . 11
6.4 Client/Server protocol . 13
7 Role Authentication . 20
7.1 Role Authentication of the card . 20
7.2 Role Authentication of the server . 20
7.3 Symmetrical external authentication . 20
7.4 Asymmetric external authentication . 25
8 Symmetric key transmission between a remote server and the ICC . 45
8.1 Steps preceding the key transport. 45
8.2 Key encryption with RSA . 45
8.3 Diffie-Hellman key exchange for key encipherment . 49
9 Signature verification . 53
9.1 Signature verification execution flow . 53
10 Certificates for additional services . 57
10.1 File structure . 57
10.2 EF.C.CH.AUT . 57
10.3 EF.C.CH.KE . 58
10.4 Reading Certificates and the public key of CAs . 58
11 Privacy Context functions . 59
11.1 Introduction . 59
11.2 Auxiliary Data Verification . 59
11.3 Restricted Identification . 64
11.4 mERA-based eServices with trusted third party protocol . 69
12 APDU data structures . 75
12.1 Algorithm Identifiers . 75
12.2 CRTs . 75
Annex A (normative) Security Service Descriptor Templates . 78
Annex B (informative) Key and signature formats for elliptic curves over prime fields GF(p) . 84
Annex C (informative) Security environments . 86
Annex D (normative) Algorithm Identifiers — Coding and specification . 99
Annex E (informative) Example of DF.CIA . 105
Bibliography . 109
2
---------------------- Page: 4 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
Foreword
This document (prEN 14890-2:2012) has been prepared by Technical Committee CEN/TC 224 ―Personal
identification, electronic signature and cards and their related systems and operations‖, the secretariat of
which is held by AFNOR.
This document is currently submitted to the CEN Enquiry.
This document will supersede EN 14890-2:2008.
This standard supports services in the context of IAS Identification, Authentication and Electronic Signature
(IAS) services, as well as other services.
In EN 14890 Part 1, the standard allows to support the implementation of the European legal framework for
electronic signatures, defining the functional and security features for a smart card intended to be used as a
Secure Signature Creation Device according to the Terms of the European Directive on Electronic Signature
1999/93. A card compliant to the standard will be able to produce a "Qualified Electronic Signature (QES)"
that fulfils the requirements of Article 5.1 of the Electronic Signature Directive and therefore can be considered
equivalent to hand-written signatures.
In EN 14890 Part 2, the standard specifies mechanisms to support other services like generic Identification,
Authentication, confidentiality, signature verification services and privacy features.
The standard defines a set of services that will enable the development of interoperable cards issued by any
card industry sector. The standard will describe an application interface and behavior of the SSCD, i.e. it
should be possible to implement it on native and interpreter based cards.
This standard consists of two parts:
Part 1: ―Basic Services for Electronic Signatures‖ describes the specifications for IAS based services on smart
cards to be used in compliance to requirements of Article 5.1 of the Electronic Signature Directive,
Part 2: ―Other Services‖ describes other services that may be used in conjunction with all, some or none of the
services described in Part 1.
st
Changes from the 1 published 2008-Version.
The scope of the standard was enhanced through new mechanisms in the field of password based
mechanisms and privacy.
Part 1:
- New algorithms added to device authentication protocols (e.g. AES, ELC)
- Added AES to secure messaging
- Introduced password based mechanisms (PACEv2)
- Updating references to their latest releases.
- Algorithm Identifier coding
- Recommendation for making best use of device authentication protocol
3
---------------------- Page: 5 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
Part 2:
- Added anonymity and pseudonymity services
- Added Auxiliary data transmission e.g. for Age verification
1 Scope
Part 2 of this series contains Identification, Authentication and Digital Signature (IAS) services in addition to
the SSCD mechanisms already described in Part 1 to enable interoperability and usage for IAS services on a
national or European level.
It also specifies additional mechanisms like key decipherment, Client Server authentication, identity
management and privacy related services.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
[1] ISO/IEC 7816-4:2005, Identification cards — Integrated circuit cards — Part 4: Organization, security
and commands for interchange
< UNDER REVISION>
[2] ISO/IEC 7816-8:2004, Identification cards — Integrated circuit cards — Part 8: Commands for security
operations
[3] ISO/IEC 7816-9:2004, Identification cards — Integrated circuit cards — Part 9: Commands for card
management
[4] ISO/IEC 9796-2:2010, Information technology — Security techniques — Digital signature schemes
giving message recovery — Part 2: Integer factorization based mechanisms
[5] ISO/IEC 15946-5:2009, Information technology — Security techniques — Cryptographic techniques
based on elliptic curves — Part 5: Elliptic curve generation
4
---------------------- Page: 6 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply. These definitions are in
compliance with those given in the revision of ISO/IEC 7816-4.
3.1
Anonymization
The process that removes the association between an identifying data set and a data subject.
3.2
Anonymized data
Data that once were linked to such an individual but can now no longer be related to that person
3.3
Anonymous data
Data that cannot be linked to a specific individual
3.4
C/S external authentication
The authentication of the server by the client. The client is regarded as the combination of the PC and the
ICC. This external authentication is out of the scope of this specification
3.5
C/S internal authentication
The authentication of the client by the server. The client is regarded as the combination of the PC and the ICC
3.6
Forward secrecy
Forward secrecy is a quality of a security protocol, that guarantees the confidentiality of a transaction even if
all longterm keys are compromised in the future.
3.7
identification
Identification is the unique association of a set of descriptive parameters to an individuum within a given
context.
3.8
IFD
Device or entity that belongs to the external world (outside the ICC)
3.9
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.
3.10
pseudonymity
Pseudonymity is the ensurance that a user may use a resource or service without disclosing its user identity.
In contrast to anonymity the user creates and uses an ambiguous parameter – the pseudonym – (e.g. a
phantasy name) which is not sufficient for user identification but is useful to partially recognize and address
the user for dedicated communication purpose (e.g. chat room, forum).
3.11
secured channel
A communication link between the ICC and a security module (possibly also an ICC) that provides authenticity
and/or integrity and/or secrecy
5
---------------------- Page: 7 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
3.12
unlinkability
Unlinkability is the ensurance that a user may make multiple uses of resources or services without others
being able to link these uses together [15].
4 Abbreviations and notation
The abbreviations and notation is in accordance with those given in [5].
4.1 Abbreviations
APDU Application Protocol Data Unit
ARR Access Rule Record
AT CRT for Authentication
C/S Client-Server
CA Certification Authority
CC Cryptographic Checksum
CCT Cryptographic Checksum Template
CIA Cryptographic Information Application
CMS Card Management System
CRT Control Reference Template
CT Confidentiality Template
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 CRT for Digital Signature
E[key](msg) Encipherment of with
EF Elementary File
FCI File Control Information
FCP File Control Parameters
H_ Hash function using algorithm
ICC Integrated Circuit(s) Card
ID Identifier
IFD Interface Device
INS Instruction byte
KE Key Encipherment
KEI Key Encipherment Input Format
6
---------------------- Page: 8 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
KID Key Identifier
MD5 Message Digest 5 (hash algorithm)
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 SEC. OPERATION
PSS Probabilistic Signature Scheme
RCA RootCA
RFU Reserved for Future Use
RND Random Number
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 Secure Service Descriptor
TDES Triple-DES
UQB Usage Qualifier
7
---------------------- Page: 9 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
5 Additional Service Selection
Additional services are typically used in the context of applications that use digital signatures.
A well known additional service is the client/server authentication. In this case, the ICC is used as a crypto
toolbox, e.g. in order to encrypt a challenge with a private key, being stored in the ICC. This is particularly
helpful in applications, where a tamper resistant device is required for client/server authentication. A secure
ICC has the necessary tamper resistant quality and may therefore be used efficiently to support the
application in this context.
Document decryption is another known service which may be performed by the IFD. A terminal application
receives a document, typically encrypted with a symmetric key. The symmetric key is also provided encrypted
with a public key. The ICC contains the appropriate private key, deciphers the symmetric key and returns it to
the terminal application.
While the typical usage of a signature card is the generation of a digital signature, an application might want to
verify a signature with a public key, being stored in the ICC. In this case an additional service is invoked for
signature verification.
Additional services provided in the ICC mandate the existence of an appropriate security environment.
Associated security environments are described in the Annex C ―(informative) Security environments‖ on page
86.
In addition to the descriptive information found in DF.CIA (refer to 16 ―Cryptographic Information Application‖
in Part 1) information might be required that can be presented in Security Service Descriptors. The concept of
Security Service Descriptors is described in the Annex A on page 78.
A user verification may be required prior to the usage of additional services. The password for this user
verification shall be different from the password used for the signature generation. This is to maintain the
purpose of the signature generation password for the sole purpose of a ‗declaration of will‘ in the case of a
signature generation.
8
---------------------- Page: 10 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
Figure 1 — Example of additional service selection
Figure 1 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.
9
---------------------- Page: 11 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
6 Client/Server Authentication
For proving access rights to components such as servers, a PK based authentication procedure has to be
performed. Such client/server Authentication (refer to ―C/S internal authentication‖ on page 5) is a process,
independent from the requirement of device authentication.
Figure 2 — Example of client/server authentication
In the above example client/server authentication establishes a secured channel between a remote server and
a PC. The ICC will be used as a cryptographic toolbox in order to provide the cryptographic functionality to the
PC.
This specification does not support the authentication of the server (―C/S external authentication‖ on page 5).
The server‘s certificate as well as the server protocol is application specific and therefore out of the scope of
this document.
6.1 Client/Server protocols
This specification only covers the case, where the ICC performs a digital signature computation on the
authentication input contained in the data field of an INTERNAL AUTHENTICATE (COMPUTE DIGITAL
SIGNATURE) command. The input is formatted before the private key for authentication is used to form the
signature.
The key pair used for client/server authentication shall be different from the device authentication keys and
signature generation keys respectively. The public part of this key pair, stored with the distinguished name of
the cardholder, is certified by a certificate (typically X.509 [11]. Such a certificate is not interpreted by the ICC.
Relevant authentication procedures are e.g.
the PK Kerberos protocol (for logon authentication)
the SSL/TLS protocol
the WTLS protocol.
All the above protocols are based on the same cryptographic algorithms. In particular they all use PKCS #1
padding format in the case of RSA. This specification describes the PKCS #1 padding and C/S authentication
based on ECDSA.
6.2 Steps preceding the client/server authentication
The steps preceding a client/server authentication are application specific. Hence this specification does not
mandate the existence of those steps.
The access conditions proposed in Annex C ―(informative) Security environments‖ on page 86 specify a user
verification as a mandatory step prior to client/server authentication.
10
---------------------- Page: 12 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
The reference to the password to be used for user verification in the context of client/server authentication is
described in the information of DF.CIA.
6.3 Padding format
6.3.1 PKCS #1 v 1-5
In case of RSA, the authentication input T is formatted according to [7] PKCS #1, Version 2.1, Chapter 9.2
―EMSA-PKCS1-v1-5‖. For particular algorithms refer to 6.4.5 "Command data field for the client server
authentication" on page 19.
Figure 3 — Example for 2048 bit DSI according to PKCS #1 V1.5
The padding is realized through an octet string consisting of octets with value ‗FF‘ (length 8). Due to security
reasons the authentication input shall be smaller or equal to 33 % of the length of the modulus. The formatted
octet string shall consist of k octets where k is the length in octets of the modulus of the private key for
authentication.
The digest info is described in 13.3.3 ―Digest Info for SHA-X‖ in Part 1.
11
---------------------- Page: 13 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
6.3.2 DSI according to PKCS #1 V 2.x (PSS)
The DSI format according to PKCS #1 V 2.1 has the following structure. The message M represents the
authentication input T.
Figure 4 — Example for 2048 bit DSI according to PKCS #1 V2.1”
The hashing function used in MGF-1 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 [7] [PKCS 1 — V.2.1, Chapter B.2.1].
12
---------------------- Page: 14 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
Figure 5 — Example for the mask generating function MGF1
The length of the salt is identical to the Digest Length H of the hash algorithm. The length of DB computes
from
Length(DB) = N – H – 1 = maskLen.
where N is the byte length of the modulus and H is the digest length of the hash algorithm.
The length of the mfgSeed is identical to H, the length of C is 4 bytes as specified [7] . The initial value of C is
zero. The concatenation of [mfgSeed || C] pairs is right truncated at the length of maskLen.
Finally the digital signature input.
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 ISO 9796 (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).
6.4 Client/Server protocol
Table 2 shows the execution flow of the RSA client/server authentication. This specification covers only the
internal authentication.
13
---------------------- Page: 15 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
Table 2 — Client/Server authentication flow
Trans-
Stage Step IFD ICC
mission
... preceding steps(e.g. user
verification) that are application
1 — application specific protocol flow
specific for client/server
authentication
INTERNAL AUTHENTICATION — server (IFD) authenticates client (ICC)
READ BINARY
1 certificate
of certificate (typically X.509)
2 MSE:SET PrK.CH.AUT
2
INTERNAL AUTHENTICATE
3 or
COMPUTE DIGITAL SIGNATURE
Client (ICC) is authenticated to server (IFD)
... subsequent steps that are
3 — application specific to present not specified in this document
client/server authentication
6.4.1 Step 1 — Read certificate
If the IFD does not already have the clients (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
Meaning
Parameter
CLA according to ISO 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, chapter 11.2.3.
The structure and coding of C.CA .CS_AUT may be as described in section 14.13 "C_CV.CA.CS-AUT (non
ICC
self-descriptive)", but it could also be some other format unknown to the ESIGN application. The actual format
is application specific and out of the scope of this standard.
14
---------------------- Page: 16 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
Table 4 — Read EF.C.CH.AUT — response
Response
Meaning
Parameter
Data field EF.C.CH.AUT plain data as stored in EF
SW1-SW2 Refer to ISO/IEC 7816-4
NOTE 1 Unless the READ BINARY selects the file using a Short File Identifier (SFI), an appropriate SELECT(EF)
command must be executed prior to reading the file.
6.4.2 Step 2 — Set signing key for client/server internal authentication
The MSE command sets the keyID of the ICC‘s client/server private authentication key to be used for the
following computation of the digital signature.
Execution Flow
Table 5 — Select key reference for internal authentication - command APDU
Command
Meaning
Parameter
CLA according to ISO 7816-4
INS ‗22‘ MANAGE SECURITY ENVIRONMENT
P1 ‗41‘ SET for internal authentication
P2 ‗A4‘
Lc field ‗xx‘
Data field CRT data field with AlgID (PrK.CH.AUT) and KeyRef(PrK.CH.AUT)
For the structure and content of the APDU refer to ISO/IEC 7816-4, chapter 11.5.11.
The structure and coding of the key reference data is specified in section 12.2.2 "CRT AT for selection of
ICC‘s private client/server auth. key" on page 75.
In order to avoid ambiguity the hashing function MGF-1 shall be indicated in the AlgID.
The response data field is empty.
Table 6 — Select key reference for internal authentication — response
Response
Meaning
Parameter
Data field empty
SW1-SW2 Refer to ISO/IEC 7816-4
Alternatively the COMPUTE DIGITAL SIGNATURE command can be used.
15
---------------------- Page: 17 ----------------------
oSIST prEN 14890-2:2012
prEN 14890-2:2012 (E)
Alternative Execution Flow
Table 7 — Select key reference for internal authentication — command APDU
Command
Meaning
Parameter
CLA according to ISO 7816-4
INS ‗22‘ MANAGE SECURITY ENVIRONMENT
P1 ‗41‘ SET for internal authentication
P2 ‗B6‘ digital signature DST
Lc field ‗xx‘
Data field CRT data field with AlgID (PrK.CH.AUT) and KeyRef(PrK.CH.AUT)
For the structure and content of the APDU refer to ISO/IEC 7816-4, chapter 11.5.11.
The structure and coding of the key reference data is specified in section 11.2.1 ―CRT DST for selection of
ICC‘s private client/s
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.