EN 419212-3:2017
(Main)Application Interface for Secure Elements for Electronic Identification, Authentication and Trusted Services - Part 3: Device authentication protocols
Application Interface for Secure Elements for Electronic Identification, Authentication and Trusted Services - Part 3: Device authentication protocols
This part specifies device authentication to be used for QSCDs in various context including
Device authentication protocols
Establishment of a secure channel Data structures
CV-certificates Key management
The device authentication protocols shall apply to sole-control signature mandated by the EU-regulation eIDAS.
Anwendungsschnittstelle für sichere Elemente zur elektronischen Identifikation, Authentisierung und für vertrauenswürdige Dienste - Teil 3: Geräteauthentisierungsprotokolle
Interface applicative des éléments sécurisés utilisés comme dispositifs de création de signature électronique qualifiée (cachet) Partie 3: Protocoles d'authentification des dispositifs
La présente partie spécifie l’authentification de dispositif à utiliser pour les QSCD dans divers contextes, incluant//y compris :
les protocoles d’authentification de dispositif ;
la mise en place d'un canal sécurisé ;
les structures de données ;
les certificats CV ;
la gestion de clés.
Il convient que les protocoles d’authentification de dispositifs s’appliquent à la signature sous contrôle exclusif imposée par le règlement eIDAS de l’UE [1].
Uporabniški vmesnik za varnostne elemente za elektronsko identifikacijo, avtentikacijo in zanesljivost storitev - 3. del: Protokoli avtentikacije naprav
Ta del opredeljuje overitev naprav, ki se uporablja za naprave za ustvarjanje kvalificiranih elektronskih podpisov (QSCD) v različnih kontekstih, vključno s/z:
• protokoli za overitev naprav,
• vzpostavljanjem varnega kanala,
• podatkovnimi strukturami,
• certifikati CV,
• upravljanjem ključev.
Protokoli za overitev naprav se morajo uporabljati za podpise pod izključnim nadzorom uporabnika, kar ureja uredba EU eIDAS [1].
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 varnostne elemente za elektronsko identifikacijo, avtentikacijo in zanesljivost storitev - 3. del: Protokoli avtentikacije napravAnwendungsschnittstelle für Smartcards als sichere Signaturerstellungseinheiten - Teil 3: GeräteauthentisierungsprotokolleInterface applicative des éléments sécurisés utilisés comme dispositifs de création de signature électronique qualifiée (cachet)
Partie 3: Protocoles d'authentification des dispositifsApplication Interface for Secure Elements for Electronic Identification, Authentication and Trusted Services - Part 3: Device authentication protocols35.240.15Identification cards. Chip cards. BiometricsICS:Ta slovenski standard je istoveten z:EN 419212-3:2017SIST EN 419212-3:2018en,fr,de01-februar-2018SIST EN 419212-3:2018SLOVENSKI
STANDARDSIST EN 419212-2:2015SIST EN 419212-1:20151DGRPHãþD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 419212-3
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
uã Device authentication protocols Interface applicative des éléments sécurisés utilisés comme dispositifs de création de signature d 5authentification des dispositifs
Anwendungsschnittstelle für Smartcards als sichere Signaturerstellungseinheiten æ Teil
uã Geräteauthentisierungsprotokolle This European Standard was approved by CEN on
s y March
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æ uã t r s y ESIST EN 419212-3:2018
Device authentication Protocol Properties . 113 Bibliography . 115 SIST EN 419212-3:2018
Device authentication protocols;
Establishment of a secure channel;
Data structures;
CV-certificates;
Key management. The device authentication protocols should apply to sole-control signature mandated by the EU-regulation eIDAS [1]. 2 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ISO/IEC 7816-4:2013, Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange ISO/IEC 7816-6, Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for interchange ISO/IEC 7816-8:2004, Identification cards — Integrated circuit cards — Part 8: Commands for security operations ISO/IEC 9796-2:2010, Information technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Integer factorization based mechanisms ISO/IEC 14888-3:2016, Information technology — Security techniques — Digital signatures with appendix — Part 3: Discrete logarithm based mechanisms 3 Device authentication 3.1 General This clause assumes that device authentication has to be performed as required in 3.3. Device authentication requires mandatory steps in order to provide a secure authentication. A device authentication is mutual and combines two mechanisms: - an ICC verifies the external world (TDA) and itself verified by the external world (CDA); - the two devices negotiate or exchange information to establish common symmetric session keys for subsequent operations. SIST EN 419212-3:2018
Authentication in general requires a defined order of steps to be processed. Violation of this order may result in the ICC aborting the process. The mechanism to control the proper order of execution steps are out of the scope of this standard. In order to distinguish which device authentication is the most appropriate for a given situation refer to Annex A. For the use of certificates the following table indicates the correct certificate type for each device authentication protocol. Table 1 — Certificate type for use with device authentication protocols Certificate Device Auth. CV Certificate self-descriptive CV Certificate non self-descriptive Attribute certificates self-descriptive 3.8 Key transport protocol - x - 3.5 Privacy protocol RSA - x - 3.5 Privacy protocol ELC x - x 3.6 mEAC x - x SIST EN 419212-3:2018
certificates for the subordinate CAs
link certificates in order to convey the public key(s). In order to use an ESIGN application a mutual authentication between ICC and customer terminal is required by the security policy. As PK algorithms are to be employed ICC and IFD authentication certificates are required. The ICC is the carrier of the ICC authentication certificate; carrier of the IFD authentication certificate could be a plug-in ICC as an example for the realization of an authentication module inside the Signature Creation Application (SCA). The handling of the DOs 5.7.9 and 5.7.10 are out of the scope of this standard. SIST EN 419212-3:2018
Figure 1 — Usage of link certificates for different key versions The example above shows PuK.CA.AUT(2002) available at the ICC. This key was brought to the ICC in 2002, however in 2003 the root key was changed and another key chain
was used when generating the IFD's certificate C.IFD.AUT(2003). In order to allow authentication of the IFD, in the above example the ICC might have to receive a link certificate LC.RCA.AUT(2003) first. This certificate is signed with the PrK.RCA.AUT(2002) and it transports the PuK.RCA.AUT(2003). After having verified the link certificate LC.RCA.AUT(2003) the ICC may now receive the certificates of the 2003-chain up to the C.IFD.AUT which carries the final public key required for authentication. If it can verify the incoming certificate with an existing public key, the ICC accepts the transported public key and may use it for the next instance of the chain. The 'start of trust' is always established with the first certificate, being verified with a public key that is available in the ICC. The example in Figure 1 considers a static Root CA key stored in the ICC. Hence, an IFD shall present a proper link certificate in every device authentication session. Alternatively, an ICC may provide the possibility to permanently store the new Root CA key, which would require the import of a link certificate only once. If the trust anchor has been permanently updated within the ICC, the 'start of trust' for subsequent device authentications is the new Root CA key. The certificate chain to be presented by the IFD is shortened. When verifying a certificate, the verifier shall verify the correct role of the signer. Only those roles being allowed to sign certificates may be accepted for the presentation of a certificate chain. The role of a certificate holder is specified in 5.7.4. 3.4 Authentication environments NOTE In [22] two environments are distinguished with respect to signature creation applications. SIST EN 419212-3:2018
Figure 2 — Trust of the environment 3.4.2 SCA in untrusted environment A device authentication shall be used if the operating environment of the ICC cannot be entirely trusted. This can be the case in public signature terminals or other devices, that cannot provide an a-priori secure channel.
Figure 3 — Communication in untrusted environment Device authentication is mutual. The ICC shall authenticate the IFD and vice versa. The order of authentication, however, may differ, depending on the implemented scheme. After successful device authentication, session keys are available on both sides to be used in subsequent transmissions. The appropriate secure messaging is in compliance with ISO/IEC 7816-4 and described in “9 Secure Messaging” [25]. Examples for an untrusted environment are: - SCA and QSCD are not at the same location, i.e. the card is remote; - usage of biometrics if the sensor is off-card; - usage of contactless cards. 3.4.3 Specification of the environment In general the IFD cannot evaluate a priori whether an environment is trustable or not. Therefore it shall be left to the card holder to decide, whether he may trust the application environment or not. The initiation of a device authentication in the application environment is out of the scope of this specification. 3.4.4 Display message mechanism Given, the card holder has initiated a device authentication this specification proposes a 'display message' mechanism in order to verify that the device authentication has been performed successfully. If used, after successful device authentication, a display message shall indicate the successful device authentication in order to inform the user about the existence of a trusted channel. The application of the display message is described in 3.13. SIST EN 419212-3:2018
GENERAL AUTHENTICATE(KID)1 (compliant to ISO/IEC 7816-4) DH: KID = DH.P || KIFD EC: KID = ECDH.P || KIFD Response = KICC
B\ BZ DH: compute KICC = grICC mod p EC: compute KICC = Comp(rICC G) DH:
compute KIFD/ICC = KIFDrICC mod p EC: compute KIFD/ICC = Comp(rICC KIFD) KICC DH: compute KIFD/ICC = KICCrIFD mod p EC:
compute KIFD/ICC = rIFD KICC
Secure messaging keys are derived on both sides according to 3.9 and [15]. Secure messaging (encryption) is activated. All following commands are protected by secure messaging with encryption as described in “Final command APDU construction” [24] Chapter 9.6.3. The SSC is initialized to a start value of '1'. 2 4 If PuK.CA.AUT is available in the ICC continue with step 7 5 Select PuK.RCA.AUT B\ BZ Select key. Response OK 6 PSO:Verify Certificate C_CV.CAIFD.CS_AUT B\ BZ Verify certificate. Response OK 7 Select the CA public key PuK.CAIFD.CS_AUT. B\ BZ Select key. Response OK 8 PSO:Verify Certificate C_CV.IFD.AUT B\ BZ Verify certificate. Response OK
1 For compliance to CWA 14890, the existence of the A6 template will indicate usage of the CWA 14890 method. This mechanism is restricted to the algorithms already supported in CWA 14890 in which case AES and elliptic curves are not supported. Step 2' DH: compute KIFD = grIFD mod p
MSE:SET:KAT (A6)
DH: DH.P || KIFD Step 3' GET DATA (KICC)
DH: compute KIFD/ICC = KICCrIFD mod p SIST EN 419212-3:2018
...|| h(...|| KIFD || S) ) with
S = SN.IFD || RND.ICC || KICC ||
DH.P EC: SN.IFD || DS[PrK.IFD.AUT] (
Comp(KIFD) || S ) with
S = SN.IFD || RND.ICC || Comp(KICC) || ECDH.P B\
ICC verifies signature. The IFD's identity is implicitly verified as known by the certificate C_CV.IFD.AUT.
BZ OK ICC has now authenticated the reader — SM (encryption) active The full information of DF.CIA may now be revealed to the IFD 4 12 READ BINARY of file EF.C.CAICC.CS_AUT b B\ BZ Read data from specified file. C.CAICC.CS_AUT as response 13 READ BINARY of file EF.C.ICC.AUT B\ BZ Read data from specified file. C.ICC.AUT is in response APDU The Public Key of ICC is now known by the reader, and can be trusted 5 14 MSE:SET PrK.ICC.AUT B\ BZ Select PrK of ESIGN application. Response OK SIST EN 419212-3:2018
...|| h(...|| KICC || S)
) with
S = SN.ICC || RND.IFD || KIFD ||
DH.P EC: SN.ICC || DS[PrK.ICC.AUT] (
Comp(KICC) || S ) with
S = SN.ICC || RND.IFD ||
Comp(KIFD) || ECDH.P Two-way authentication is now complete c a If the data are not organized in a file, it may be read from data objects instead. b This step is required only if the reader does not have the public key of the CA. c The SSC will be updated on both sides according to 8.10 3.6.2.2 Step 1 — Read key exchange parameters If the IFD does not have the required key exchange information available, it may read them from a global data file DH:EF.DH / EC:EF.ELC or data objects respectively. EF.DH/EF.ELC may contain public algorithm quantities which depend on the authentication algorithm. For instance: - in a Diffie-Hellman Key exchange scheme, the public key quantities would be the public parameters g, p and q (refer to “Diffie-Hellman key exchange parameters” [24] Chapter 11.3). - In an Elliptic Curve Diffie-Hellman Key exchange scheme, the public key quantities would be the public parameters p,a,b,G,n and the optional cofactor h (refer to “ELC key exchange public parameters” [24] Chapter 11.7). SIST EN 419212-3:2018
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...