EN 419212-4-2018 Application Interface for Secure Elements for Electronic Identification Authentication and Trusted Services - Part 4 Privacy specific Protocols.pdf

1、BSI Standards PublicationWB11885_BSI_StandardCovs_2013_AW.indd 1 15/05/2013 15:06Application Interface for Secure Elements for Electronic Identification, Authentication and Trusted ServicesPart 4: Privacy specific ProtocolsBS EN 419212-4:2018National forewordThis British Standard is the UK implement

2、ation of EN 419212-4:2018. Together with BS EN 419212-1:2017, BS EN 419212-2:2017, BS EN 419212-3:2017 and BS EN 419212-5:2018, it supersedes BS EN 419212-1:2014 and BS EN 419212-2:2014, which will be withdrawn upon publication of all parts.The UK participation in its preparation was entrusted to Te

3、chnical Committee IST/17, Cards and security devices for personal identification.A list of organizations represented on this committee can be obtained on request to its secretary.This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its co

4、rrect application. The British Standards Institution 2018 Published by BSI Standards Limited 2018ISBN 978 0 580 95130 5ICS 35.240.15Compliance with a British Standard cannot confer immunity from legal obligations.This British Standard was published under the authority of the Standards Policy and Str

5、ategy Committee on 30 April 2018.Amendments/corrigenda issued since publicationDate Text affectedBRITISH STANDARDBS EN 419212-4:2018EUROPEAN STANDARDNORME EUROPENNEEUROPISCHE NORMEN 419212-4April 2018ICS 35.240.15 Supersedes EN 419212-1:2014, EN 419212-2:2014EUROPEAN COMMITTEE FOR STANDARDIZATIONCOM

6、IT EUROPEN DE NORMALISATIONEUROPISCHES KOMITEE FR NORMUNGCEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels 2018 CEN Ref. No. EN 419212-4:2018: EAll rights of exploitation in any form and by any means reserved worldwide for CEN national MembersApplication Interface for Secure Elements

7、for Electronic Identification, Authentication and Trusted Services - Part 4: Privacy specific ProtocolsInterface applicative des lments scuriss utiliss comme dispositifs de cration de signature lectronique qualifie (cachet) - Partie 4 : Protocoles spcifiques la protection de la vie priveAnwendungssc

8、hnittstelle fr sichere Elemente zur elektronischen Identifikation, Authentisierung und fr vertrauenswrdige Dienste - Teil 4: Datenschutzspezifische ProtokolleThis European Standard was approved by CEN on 6 February 2017.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which

9、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 Europe

10、an 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 t

11、he 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, Roman

12、ia, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.English VersionEN 419212-4:2018 (E)European foreword 3Introduction .41 Scope .52 Normative references 53 Introduction 53.1 General .53.2 Auxiliary Data Comparison 63.2.1 General63.2.2 Presentation of the auxiliary

13、data .63.2.3 Age Verification . 83.2.4 Document Validation 93.3 Restricted Identification 103.3.1 General.103.3.2 Command APDU for Step RI:1 .123.3.3 Command APDU for Step RI:2 .134 e-Services with trusted third party protocol 144.1 General 144.2 Architecture 144.3 Enhanced Role Authentication (ERA)

14、 protocol .164.4 Authentication flow steps .174.4.1 General.174.4.2 Step 1: Service selection .184.4.3 Step 2: User consent.184.4.4 Step 3 User authentication to the SP .194.4.5 Step 4 Access to the service (or go to next steps) 194.4.6 Step 5 Request for attributes (OPT) .194.4.7 Step 6 Restoration

15、 of security context (OPT) .194.4.8 Step 7 User authentication to the AP (OPT) 194.4.9 Step 8 Reading and providing attribute requested (OPT) 194.4.10 Step 9 Restoration of security context (OPT) .194.4.11 Step 10 Ask access to the service (OPT) .194.4.12 Step 11 Verification of attributes by the SP

16、 (OPT) 194.4.13 Step 12 Grant access to the service (OPT) 19Bibliography .202Contents PageBS EN 419212-4:2018EN 419212-4:2018 (E)European forewordThis document (EN 419212-4:2018) has been prepared by Technical Committee CEN/TC 224 “Personal identification and related personal devices with secure ele

17、ment, systems, operations and privacy in a multi sectorial environment”, 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 October 2018, and conflicting nat

18、ional standards shall be withdrawn at the latest by October 2018.Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN shall not be held responsible for identifying any or all such patent rights.This document supersedes EN 419212-1:

19、2014 and EN 419212-2:2014.This standard supports services in the context of electronic IDentification, Authentication and Trust Services (eIDAS) including signatures.In EN 419212 Part 2, the standard allows support of implementations of the European legal framework for electronic signatures, definin

20、g the functional and security features for a Secure Elements (SE) (e.g. smart cards) intended to be used as a Qualified Signature Creation Device (QSCD) according to the Terms of the “European Regulation on Electronic Identification and Trust Services for electronic transactions in the internal mark

21、et”.A Secure Element (SE) compliant to the standard will be able to produce a “qualified electronic signature” that fulfils the requirements of section 4, in particular Articles 26 (requirements for advanced electronic signatures) and 29 (requirements for qualified electronic signature creation devi

22、ces) of the so-called eIDAS Regulation and therefore can be considered equivalent to a hand-written signature.This standard consists of five parts: Part 1: “Introduction and common definitions” describes the history, application context, market perspective and a tutorial about the basic understandin

23、g of electronic signatures. It also provides common terms and references valid for the entire 419212 series. Part 2: “Signature and Seal Services” describes the specifications for signature generation according to the eIDAS regulation. Part 3: “Device Authentication” describes the device authenticat

24、ion protocols and the related key management services to establish a secure channel. Part 4: “Privacy specific Protocols” describes functions and services to provide privacy to identification services. Part 5: “Trusted eServices” describes services that may be used in conjunction with signature serv

25、ices described in Part 2.According to the CEN-CENELEC Internal Regulations, the national standards organisations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic

26、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 the United Kingdom.3BS EN 419212-4:2018EN 419212-4:2018 (E)IntroductionRec

27、ipients 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.The European Committee for Standardization (CEN) draws attention to the fact that it is claimed that compliance with this docum

28、ent may involve the use of a patent concerning the mapping function given in EN 419212-2:2017 8.2.The patent relates to “Sagem, MorphoMapping Patents FR09-54043 and FR09-54053, 2009”.CEN takes no position concerning the evidence, validity and scope of this patent right.The holder of this patent righ

29、t has ensured CEN that he/she is willing to negotiate licences under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the holder of this patent right is registered with CEN. Information may be obtained from:Morpho11, boule

30、vard Gallini92445 Issy-les-Moulineaux CedexAttention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other than those identified above. CEN shall not be held responsible for identifying any or all such patent rights.4BS EN 419212-4:2018EN 41

31、9212-4:2018 (E)1 ScopeThis part specifies mechanisms for SEs to be used as privacy-enabled devices in the context of IAS, and fulfill the requirements of Article 5 of the so-called eIDAS Regulation about data processing and protection.It covers:- Age verification- Document validation- Restricted ide

32、ntification- eServices with trusted third party based on ERA protocol2 Normative referencesThe 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

33、, 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 interchangeISO/IEC 7816-8:2016, Integrated circuit(s) cards with contacts Part 8: Commands and mechani

34、sms for security operations3 Introduction3.1 GeneralPrivacy Context is an environment to be considered whereas a card holder may be exposed to an environment that might read privacy parameters from the card ahead of any device authentication. Such privacy parameters can be the unique Card ID or othe

35、r personalized parameters that allow a tracking and profiling of the card holder.For instance, if the nationality of a card holder can be identified by the nature of the card description parameters (e.g. algorithm ID), then a card holder of certain nationality could be exposed to observation. Privac

36、y context describes the requirement to allow a card holder to be confident that privacy parameters will not be exposed to unauthorized environment.ICC Cards used for eID functionality may need as well privacy features e.g. to conceal the identity or the specific profile of the ICC owner in open netw

37、orks or for Machine to Machine (M2M) services.One popular functionality represents the well known use of pseudonyms here implemented by the restricted identification or 4.3 “Enhanced Role Authentication (ERA) protocol” with the purpose that these pseudonyms are used for certain services (e.g. paymen

38、t sector) and cannot be linked to a global profile of the owner.Another application lies in the validation of the ICC for authorization to web services, (e.g. voting) where only as much information is to be revealed as necessary for the actual service. Another popular use is the age verification wit

39、h information provided only to the extent that a person is older than a particular age but without revealing the actual age of the card holder.Different privacy oriented protocols are described in the following sections.5BS EN 419212-4:2018EN 419212-4:2018 (E)3.2 Auxiliary Data Comparison3.2.1 Gener

40、alThe COMPARE command specified in ISO/IEC 7816-4:2013, initiates a comparison of “comparison data” with non-volatile “reference data” in the ICC. The comparison data are provided by the IFD either in the COMPARE command or by an operation prior to the comparison e.g. as Auxiliary Data as described

41、in EN 419212-3:2017, 3.6.4.5.As with coding the comparison data in the compare command the command could be sent multiple times, the IFD could evaluate the actual auxiliary data (e.g. age) by additional verification attempts on selected auxiliary data content (e.g. variable age).If the IFD is allowe

42、d to send the compare command only once, then such an attempt may be avoided. Sending the comparison data as auxiliary data within device authentication protocols as specified in this standard, avoid those attacks. The presentation of the auxiliary data are shown in 3.2.3 and shall be implemented ac

43、cording to TR 03110 2.20.The presentation of auxiliary data are mandatorily to be provided by the General Authentication Procedure (GAP) according to TR 03110 2.20.As there are several further options to prevent from exhaustive search and the actual exposure cannot be generalized due to the fact tha

44、t the actual content of auxiliary data are not specified in this standard, the associated countermeasures to the above situation are out of the scope of this standard.For the additional services several use cases e.g. perform age verification, document validity verification or other comparison are p

45、ossible.Each of these use cases requires an appropriate usage of the COMPARE command regarding P1, P2, and the data field. These parameters are described in the following.The successful execution of the COMPARE command has no result on the internal status of the card.3.2.2 Presentation of the auxili

46、ary dataThe auxiliary data are presented as part of the mEAC protocol (EN 419212-3:2017, clause 3.6), in two possible variants. These variants are described above and shown in Table 1.Auxiliary data may have use cases as in the following examples:- For Age Verification the terminal has to send the r

47、equired date of birth threshold.- For Document Validity Verification the terminal has to send the current dateThe following is an example that shows Table 34 in Part 3 but highlights the added steps relevant to the verification of the auxiliary data. The table relates to the mEAC protocol as describ

48、ed in EN 419212-3:2017, 3.6.Table 1 Reference device authentication scheme mEACStage Step IFDTransmis-sionICCA 1READ BINARY of file containing protocol related parameters (e.g. public param-eters etc.) Read parameters Data are in response APDUGET DATA to read public parameters from EF.DH.Protocol re

49、levant data are available to the terminal.6 BS EN 419212-4:2018EN 419212-4:2018 (E)Stage Step IFDTransmis-sionICCB2 condi-tionalIn case of a remote interface: Proof of user presence: User is requested to prove presence by presentation of e.g. PIN Verify user presence Response: OKIn 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 1013 here. For backward compatibility to EACv1.1 protocol va