EN 14890-2:2008

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 Smartcards als sichere Signaturerstellungseinheiten - Teil 1: BasisdiensteInterfaces applicatives des cartes à puce utilisées pour le création de signatures électroniques sécurisées - Partie 2: Services additionelsApplication 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 14890-2:2008SIST EN 14890-2:2009en,fr,de01-april-2009SIST EN 14890-2:2009SLOVENSKI
STANDARD
EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 14890-2November 2008ICS 35.240.15Supersedes CWA 14890-2:2004
English VersionApplication Interface for smart cards used as Secure SignatureCreation Devices - Part 2: Additional ServicesInterface d'application des cartes intelligentes utiliséescomme dispositifs sûrs de création de signature - Partie 2 :Services complémentairesAnwendungsschnittstelle für Chipkarten, die zur Erzeugungqualifizierter elektronischer Signaturen verwendet werden -Teil 2: Zusätzliche DiensteThis European Standard was approved by CEN on 5 October 2008.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this EuropeanStandard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such nationalstandards may be obtained on application to the CEN 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 translationunder the responsibility of a CEN member into its own language and notified to the CEN Management Centre has the same status as theofficial versions.CEN members are the national standards bodies of Austria, Belgium, Bulgaria, 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 and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMITÉ EUROPÉEN DE NORMALISATIONEUROPÄISCHES KOMITEE FÜR NORMUNGManagement Centre: rue de Stassart, 36
B-1050 Brussels© 2008 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 14890-2:2008: ESIST EN 14890-2:2009

Security Service Descriptor Templates.48 A.1 Introduction.48 A.2 Security Service Descriptor Concept.48 A.3 SSD Data Objects.49 A.3.1 DO Extended Header List, tag ‘4D’.49 A.3.2 DO Instruction set mapping (ISM), tag ‘80’.49 A.3.3 DO Command to perform (CTP), tag ‘52’ (refer to ISO/IEC 7816-6).49 A.3.4 DO Algorithm object identifier (OID), tag ‘06’ (refer to ISO/IEC 7816-6).49 A.3.5 DO Algorithm reference, tag ‘81’.49 A.3.6 DO Key reference, tag ‘82’.50 A.3.7 DO FID key file, tag ‘83’.50 A.3.8 DO Key group, tag ‘84’.50 A.3.9 DO FID base certificate file, tag ‘85’.50 A.3.10 DO FID adjoined certificate file, tag ‘86’.50 A.3.11 DO Certificate reference, tag ‘87’.50 A.3.12 DO Certificate qualifier, tag ‘88’.50 A.3.13 DO FID for file with public key of the certification authority PK(CA), tag ‘89’.50 A.3.14 DO PIN usage policy, tag ‘5F2F’.50 A.3.15 DO PIN reference, tag ‘8A’.51 A.3.16 DO Application identifier (AID), tag ‘4F’ (refer to ISO/IEC 7816-6).51 A.3.17 DO CLA coding, tag ‘8B’.51 A.3.18 DO Status information (SW1-SW2), tag ‘42’ (refer to ISO/IEC 7816-6).51 A.3.19 DO Discretionary data, tag ‘53’ (refer to ISO/IEC 7816-6).51 A.3.20 DO SE number, tag ‘8C’.52 A.3.21 DO SSD profile identifier, tag ‘8D’.52 A.3.22 DO FID mapping, tag ‘8E’.52 A.4 Location of the SSD templates.52 A.5 Examples for SSD templates.52 Annex B (informative)
Key and signature formats for elliptic curves over prime fields GF(p).54 B.1 General.54 B.2 Elliptic curve parameters.54 B.3 Public key point.55 B.4 ECDSA signature format.55 Annex C (informative)
Security environments.56 C.1 Introduction.56 C.2 Definition of CRTs (examples).57 C.2.1 General.57 C.2.2 CRT for Authentication (AT).58 C.2.3 CRT for Cryptographic Checksum (CCT).59 C.2.4 CRT for Digital Signature (DST).60 C.2.5 CRT for confidentiality (CT).61 C.3 Security Environments (example).62 C.3.1 General.62 C.3.2 Security Environment #10.62 C.3.3 Security Environment #11.62 C.4 Coding of access conditions (example).63 SIST EN 14890-2:2009

Interoperability aspects.69 D.1 General.69 D.2 Choosing device authentication.69 D.2.1 General.69 D.2.2 Signature generation flow with possible processing options.71 D.3 Choosing User verification method.72 Annex E (informative)
Example of DF.CIA.73 Bibliography.78
2, defining the functional and security requirements for a smart card intended to be used as a Secure Signature Creation Device. This is in accordance with the Terms of the European Directive on Electronic Signature 1999/93, whereby a card compliant to the standard shall be able to produce a 'Qualified electronic signature' that fulfils the requirements of Article 5.1 of the Electronic Signature Directive, therefore giving it the equivalent status of a hand-written signature.
This standard additionally provides generic Identification, Authentication and Digital Signature (IAS) services and contains all additional cryptographic services specified in CEN CWA 14890 Part 2. The standard enables the development of interoperable cards issued by any card industry sector. The standard also describes an application interface and behaviour of the SSCD that should be possible to be implemented on native and interpreter based cards. The standard is compliant with other European standards developed in the framework of the European Directive 1999/93. This European Standard Application Interface for smart cards used as Secure Signature Creation Devices consists of two parts:  Part 1: “Basic Services” describes the mandatory specifications for an SSCD as part of generic IAS Services to be used in compliance to requirements of Article 5.1 of the Electronic Signature Directive [5].
 Part 2: “Additional Services” describes remaining services for IAS. 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, 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 and the United Kingdom.
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 KID Key Identifier MD5 Message Digest 5 (hash algorithm)
MF Master File OAEP Optimal Asymmetric Encryption Padding P1-P2 Parameter bytes PI Padding Indicator SIST EN 14890-2:2009

For proving access rights to components such as servers, a PK based authentication procedure has to be performed. Such client/server Authentication (See 3.2) is a process, being independent from the requirement of a 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 (See 3.1). The server’s certificate as well as the server protocol is application specific and therefore out of the scope of this document. 6.2 Client/Server protocols This specification covers only the case, where the card performs a digital signature computation applying the private key for authentication in an INTERNAL AUTHENTICATE (COMPUTE DIGITAL SIGNATURE) command to the authentication input contained in the data field of the command after formatting the input. 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 [7]. Such a certificate is not interpreted by the ICC. Relevant authentication procedures are e.g.  PK Kerberos protocol (for logon authentication)  SSL/TLS protocol  WTLS protocol. All the above protocols base on the same cryptographic algorithms. In particular they are all using PKCS #1 padding format in the case of RSA. Therefore this specification describes only the PKCS #1 padding. 6.3 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 specify user verification as a mandatory step prior to client/server authentication. SIST EN 14890-2:2009

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 40 % 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 EN 14890-1:2008, Clause 13.3.3. SIST EN 14890-2:2009

Figure 5 — Example for the mask generating function MGF1 SIST EN 14890-2:2009

6.5 Client/Server protocol 6.5.1 General
Table 2 shows the execution flow of the RSA client/server authentication. This specification covers only the internal authentication. Table 2 — Client/Server authentication flow Stage Step IFD Trans-mission ICC 1 — . preceding steps(e.g. user verification) that are application specific for client/server authentication application specific protocol flow INTERNAL AUTHENTICATION — server (IFD) authenticates client (ICC) 1 READ BINARY of certificate (typically X.509) certificate 2 MSE:SET PrK.CH.AUT
2 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
For the structure and content of the APDU refer to ISO/IEC 7816-4:2005, Clause 7.2.3. The structure and coding of C.CAICC.CS_AUT may be as described in Clause 14.15, 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. Table 4 — Read EF.C.CH.AUT — response Response Parameter Meaning Data field EF.C.CH.AUT plain data as stored in EF SW1-SW2 Refer to ISO/IEC 7816-4
NOTE 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.5.3 Step 2 — Set signing key for client/server internal authentication The MSE command sets the key ID of the ICC’s client/server private authentication key to be used for the following computation of the digital signature. SIST EN 14890-2:2009

according to ISO/IEC 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:2005, Clause 7.5.11. The structure and coding of the key reference data is specified in Clause 11.2.2. The response data field is empty. Table 6 — Select key reference for internal authentication — response Response Parameter Meaning Data field empty SW1-SW2 Refer to ISO/IEC 7816-4
Alternatively the COMPUTE DIGITAL SIGNATURE command can be used. Alternative Execution Flow Table 7 — Select key reference for internal authentication — command APDU Command Parameter Meaning CLA
according to ISO/IEC 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, Clause 7.5.11. The structure and coding of the key reference data is specified in Clause 11.2.1. SIST EN 14890-2:2009

6.5.4 Step 3 — Internal authentication The IFD sends a challenge in the data field of the INTERNAL AUTHENTICATE command. The ICC computes a signature over the challenge by using its private key that was selected in the preceding step. Execution Flow Table 9 — INTERNAL AUTHENTICATE — command APDU Command Parameter Meaning CLA
according to ISO/IEC 7816-4 INS ‘88’ INTERNAL AUTHENTICATE P1 ‘00’ no algorithm information P2 ‘00’ key reference — none Lc field ‘xx’ Data field data
authentication input T see below Le field ‘00’
For the structure and content of the APDU refer to ISO/IEC 7816-4, Clause 7.5.2. The digital signature input format is described in 6.5.6. The algorithms usable for client server authentication are described in 11.1.1. The response data contains the signature. Table 10 — INTERNAL AUTHENTICATE — response Response Parameter Meaning Data field RSA: SIG = DSa[PrK.IFD.CS.AUT](DSI) where DSI is formed according to 6.4. ECDSA: For the ECDSA algorithm the signature format is described in B.4 SW1-SW2 Refer to ISO/IEC 7816-4 a DS is to be understood as plain RSA exponentiation. It does not imply a layer of input formatting other than already specified here.
For the structure and content of the APDU refer to ISO/IEC 7816-8:2004, Clause 5.8. The digital signature input format is described in 6.5.6. The algorithms usable for client server authentication are described in 11.1.1. The response data contains the signature. Table 12 — COMPUTE DIGITAL SIGNATURE — response Response Parameter Meaning Data field RSA: SIG = DSa[PrK.IFD.CS.AUT](DSI) where DSI is formed according to 6.4. ECDSA: For the ECDSA algorithm the signature format is described in B.4 SW1-SW2
Refer to ISO/IEC 7816-4 a DS is to be understood as plain RSA exponentiation. It does not imply a layer of input formatting other than already specified here.
While the IFD sends only the authentication input T, the ICC performs the padding as described in Figure 3. In the following text it is not necessary to distinguish between these alternatives. 6.5.5 Client/Server authentication execution flow The ICC generates a signature in the size of the modulus over the input data, which shall be presented in padded form such, that it is the size of the modulus. SIST EN 14890-2:2009

Table 14 — Command data field for SSL/TLS T L V Bytes — — T = H_MD5 || H_SHA1 refer to [4] and [5]
Table 15 — Command data field for WTLS T L V Bytes — — T = H_SHA1
refer to [4]
The ICC will have to perform the padding according to Figure 3 or Figure 4. The value T is taken as described by the three tables above. 6.5.6.2 ECDSA For ECDSA the value T is padded with leading zero bits. 6.5.6.3 Other algorithms All other algorithms use the padded (PKCS #1) authentication input in the data field. Table 16 — Input to other algorithms T L V Bytes — — authentication input
...