Application Interface for Secure Elements for Electronic Identification, Authentication and Trusted Services - Part 4: Privacy specific Protocols

This part specifies mechanisms for SEs to be used as privacy-enabled devices in the context of IAS, and fulfil the requirements of Article 5 of the so-called eIDAS Regulation about data processing and protection.
It covers:
- Age verification
- Document validation
- Restricted identification
- eServices with trusted third party based on ERA protocol

Anwendungsschnittstelle für sichere Elemente, die als qualifizierte elektronische Signatur-/Siegelerstellungseinheiten verwendet werden - Teil 4: Datenschutzspezifische Protokolle

Interface applicative des éléments sécurisés pour les services électroniques d'identification, d'authentification et de confiance - Partie 4 : Protocoles spécifiques à la protection de la vie privée

La présente partie spécifie les mécanismes relatifs aux SE utilisés en tant que dispositifs de protection de la vie privée dans le cadre des IAS et remplit les exigences de l’Article 5 de ce qu’il est convenu d’appeler le Règlement eIDAS relatif au traitement et à la protection des données.
Il traite des aspects suivants :
   vérification de l'âge ;
   validation de document ;
   identification restreinte ;
   services électroniques avec tierce partie de confiance basés sur le protocole ERA.

Uporabniški vmesnik za varnostne elemente za elektronsko identifikacijo, avtentikacijo in zanesljivost storitev - 4. del: Posebni protokoli zasebnosti

Ta del določa mehanizme za varnostne elemente, ki se uporabljajo kot naprave z omogočeno zasebnostjo v okviru IAS in izpolnjujejo zahteve člena 5 tako imenovane uredbe eIDAS o obdelavi in
varstvu podatkov.
Zajema:
– preverjanje starosti
– potrjevanje dokumentov
– omejeno identifikacijo
– elektronske storitve z zaupanja vredno tretjo stranjo na podlagi protokola ERA

General Information

Status
Published
Publication Date
16-Jul-2018
Technical Committee
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
16-Apr-2018
Due Date
21-Jun-2018
Completion Date
17-Jul-2018

Relations

Standard
SIST EN 419212-4:2018 - BARVE
English language
22 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

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 - 4. del: Posebni protokoli zasebnostiAnwendungsschnittstelle für sichere Elemente, die als qualifizierte elektronische Signatur-/Siegelerstellungseinheiten verwendet werden - Teil 4: Datenschutzspezifische ProtokolleInterface applicative des éléments sécurisés pour les services électroniques d'identification, d'authentification et de confiance - Partie 4 : Protocoles spécifiques à la protection de la vie privéeApplication Interface for Secure Elements for Electronic Identification, Authentication and Trusted Services - Part 4: Privacy specific Protocols35.240.15Identification cards. Chip cards. BiometricsICS:Ta slovenski standard je istoveten z:EN 419212-4:2018SIST EN 419212-4:2018en,fr,de01-september-2018SIST EN 419212-4:2018SLOVENSKI
STANDARDSIST EN 419212-2:2015SIST EN 419212-1:20151DGRPHãþD

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 419212-4
April
t r s z 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
vã Privacy specific Protocols Interface applicative des éléments sécurisés pour les services électroniques d 5identificationá d 5authentification et de confiance æ Partie
v ã Protocoles spécifiques à la protection de la vie privée
Anwendungsschnittstelle für sichere Elemente zur elektronischen Identifikationá Authentisierung und für vertrauenswürdige Dienste æ Teil
vã Datenschutzspezifische Protokolle 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:
Rue de la Science 23,
B-1040 Brussels
t r s z 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æ vã t r s z ESIST EN 419212-4:2018

Read parameters Data are in response APDU GET DATA to read public parameters from EF.DH. Protocol relevant data are available to the terminal. B 2 condi-tional In case of a remote interface: Proof of user presence: User is requested to prove presence by presentation of e.g. PIN \ Z
Verify user presence Response: OK In case of a remote interface or a contactless local interface, proof of user presence shall be given by mechanisms defined in 6 "User verification" in order to avoid skimming attacks.
10 For mEACv1 perform the steps 10–13 here. For backward compatibility to EACv1.1 protocol variant, step 11 and step 12 may alternatively be replaced by step 11p applying MSE SET KAT command
(see EN 419212-3:2017, 3.6.3.11)
3 Select and/or verify PuK.RCA.AUT. \ Z Select and/or verify key. Response: OK
4 PSO:Verify Certificate C_CV.CAIFD.CS_AUT \ Z Verify certificate.
The verification of certificates along a certificate chain may continue until the CA's key is available in the ICC that signed the IFD's certificate and delivers PuK.IFD.AUT.
5 Select and/or verify PuK.CAIFD.CS_AUT. \ Z Select and/or verify key. Response: OK
6 PSO:Verify Certificate C_CV.IFD.AUT \ Z Verify certificate. Response: OK The Public Key of the IFD is now known to the ICC, and can be trusted. D 7 MSE:SET AT (PuK.IFD.AUT) Select IFDs public key and select the key parameters for the consecutive operation, send compressed ephemeral public key Comp(PuK.IFD.KA) and optionally auxiliary data For the use of AUX.Data refer to 3.2. \ Z Select PuK of IFD, Store Comp(PuK.IFD.KA) Store auxiliary data (optional) Response: OK 8 GET CHALLENGE \ Z RND.ICC SIST EN 419212-4:2018

S = [SN.ICC II RND.ICC ||
Comp(PuK.IFD.KA) ||
AUX.Data ] \
ICC verifies signature. The IFD's identity is implicitly verified as known by the certificate C_CV.IFD.AUT.
Z Response: OK ICC has now authenticated the IFD E 10 Conditional – only if C.ICC.AUT is available: READ BINARY to obtain C.ICC.AUT or PuK.ICC.KA
\ Z Read C.ICC.AUT or PuK.ICC.KA Data are in response APDU 11 MSE SET AT Set PrK.ICC.KA for authentication \ Z Set PrK.ICC.KA Response: OK 12 GENERAL AUTHENTICATE (compliant to ISO/IEC 7816-4:2013, 11.5.5) send PuK.IFD.KA Compute MAC[KMAC](PuK.IFD.KA) and compare with received value Generate new session keys KENC and KMAC \ Z Compute Comp(PuK.IFD.KA) and compare with hash value obtained in step 7. Generate new session keys KENC and KMAC. Response: OK and MAC[KMAC](PuK.IFD.KA) and RND2.ICC 13 Establish secure session The secure messaging session is restarted with session keys generated in step 11' or 12. Secure channel (ICC- server) is now established and two-way authentication is complete; If Step 10 is not performed, then Step 10 shall be performed in secure messaging mode as Step 14 (not shown in this example).
14 COMPARE BINARY send reference (i.e. OID) of AUX.Data given in step 7 and send mode of comparison
15 Repeat step 14 until all auxiliary data verifications are processed IFD has now verified auxiliary data SIST EN 419212-4:2018

The OID describes the use and associated service for the DO '53' < comparison data > . 3.2.3 Age Verification Age verification is one possible application of AUX.Data on the ICC. The IFD may send an age threshold value as part of the AUX data in the device authentication protocol or in the appropriate C.IFD.AUT certificate. The ICC can return acceptance or refusal without having to reveal the actual age of the card holder. NOTE Cryptologically the age can be evaluated by the IFD using an exhaustive binary search, seven attemps would cover the range from 1 … 128 years. Storing the threshold value as part of the IFD's certificate makes the process less flexible, however, this would avoid leakage of the age through a binary search. Table 2 — COMPARE operation — command APDU Command Parameter Meaning CLA according to ISO/IEC 7816-4 INS ‘33’ COMPARE P1 ‘00’ = COMPARE BINARY P2 ‘00’
Lc field Lc =
< length of command data field >
Data field ‘06’ L06 < OID associating the comparison data >
The result is indicated by the status word in the command response. The COMPARE function is described in 11.6.1 of ISO/IEC 7816-4:2013. The response data field is empty. Table 3 — COMPARE operation —
...

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...