1 / 26

Update on WS eAuthentication status

Update on WS eAuthentication status. Jan van Arkel Co-Chairman eEurope Smart Card Charter Ambassador CEN/ISSS WS eAuthentication. Objectives of the Workshop eAuthentication/eID. consolidate OSCIE eAuthentication GIF content and search for maintenance

lev
Download Presentation

Update on WS eAuthentication status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Update on WS eAuthentication status Jan van Arkel Co-Chairman eEurope Smart Card Charter Ambassador CEN/ISSS WS eAuthentication

  2. Objectives of the Workshop eAuthentication/eID • consolidate OSCIE eAuthentication GIF content and search for maintenance • offer a European Forum on eAuthentication • seek wider involvement and consensus • harmonise eAut with Japan and US • harmonise eAut with WS e-sign i.e. Area K • harmonise with eEpoch development • relate with Porvoo group eGov/eID requirements • prepare a harmonised Glossary of Terms

  3. Deliverables of WSeAut • CWA eAut Part 1: Architecture for a European interoperable eID system within a smart card infrastructure  • CWA eAut Part 2: Best Practice Manual for card scheme operators exploiting a multi-application card scheme incorporating interoperable IAS services • CWA eAut Part 3: User Requirements for a European interoperable eID system within a smart card infrastructure • WP 4: eID Strategic Vision Report

  4. Status WS eAut • The WS started September 16, 2003 • Draft CWA documents were approved (with some comments) on September 20, 2004 • Revised drafts distributed for 60 days public comment period on October 18, 2004 • Disposition of comments ready by December 31 • Final documents distributed by January 15, 2005 • Workshop closing meeting on February 11, 2005 • Official publication of CWA eAuthentication by CEN

  5. Deliverables of WSeAut • CWA eAut Part 1: Architecture for a European interoperable eID system within a smart card infrastructure Table of Content • Introduction • Contextual Model for IAS interoperability • Conceptual model for IAS interoperability • The IAS functional model • IAS system architecture • The functional model in the IAS system architecture • High level description of the primary processes - formal description • IAS interoperability • Securing interoperability • Common requirements for IAS interoperability • Annex A Mandatory fields in certificates

  6. Closed eID scheme certificate cardapplication IAS/ eID cardaccess e-Serviceaccess content on us not on us cardapplication IAS/ eID cardaccess e-Serviceaccess content certificate

  7. eService interoperability certificate cardapplication IAS/ eID cardaccess e-Serviceaccess content on us IOP #2 IOP #3 not on us cardapplication IAS/ eID cardaccess e-Serviceaccess content certificate

  8. IAS Smart card information system architecture

  9. Deliverables of WSeAut • CWA eAut Part 2: Best Practice Manual for card scheme operators exploiting a multi-application card scheme incorporating interoperable IAS services Table of Content • Multi-application smart card schemes(including Government issued eID driven MASchemes) • Risk analysis and Policy management • Service implementation and legal /adminstrative guidelines • Business case analysis • Peer support mechanisms and recommendations

  10. Deliverables of WSeAut • CWA eAut Part 3: User Requirements for a European interoperable eID system within a smart card infrastructure Table of Content • General User requirements for smart card based systems - common elements in support of user req - doing things with a smart card - doing things to a smart card • User requirements for Authenticatioin within an eID system - identification - authentication - signature services - eID processes

  11. Deliverables of WSeAut • Strategic eID Vision reportTable of Content • The Vision - Rationale for a common eID approach - Drivers and inhibirtors for a common apporach • How can the vision be realised • Conditions for mass deployment - minimum requirements - Architectural model - The legal issue - Standardisation • Deployment of eID in Europe and beyond • Recommendations

  12. Deployment of eID • Group 1: the no-not for us- group • Group 2: Early adopters • Group 3: Middle of the road group

  13. Deployment of eID • Group 1: the no-not for us- group Anglo-saxon countries - US - Canada - Australia - New Zealand - UK ???

  14. Deployment of eID • Group 2: Early adopters Malaysia South East Asia Middle East Japan

  15. Deployment of eID • Group 3: Middle of the road group Europe China, India South America Africa

  16. Europe’s leading examples • Estonia 650K • Italy 400K • Belgium 85K • Finland 55K • Spain • Austria

  17. eID deployment worldwide • Overall conclusions: - strong regional differences - a number of European countries is on the move - smart cards prevail - PIN is omnipresent, biometrics are emerging as preferred CHV - PKI is taking off - patchy solutions

  18. Recommendations • Approach eID as an infrastructure which needs to come into place at least in the European domain • Provide a legal basis for a common European eID • Organise a stronger participation in Standardisation • Organise a pan-European demonstrator • European Coordination on eID development is needed

  19. Common Requirements (WS-eAut, CEN 224-WG 15, Porvoo group)

  20. Basic Functionalities • electronic identification & authentication of the cardholder to public and private services • electronic signature for legal proof of non repudiation Optional functions: • confidentiality services, enabling encryption of data transmitted over a network (email, documents transfer) • official travel document

  21. Overall system requirements • The system shall support different security profiles/classes • The system shall be trustworthy for the cardholder, the system as such shall be reliable and it shall protect the cardholders data present in the card • The IAS functionality shall be executed in a secure and controllable way • The execution of the eID and eAuthentication function shall be convenient and fast • The system shall be future proof: - based on international standards (ISO/IEC 7810, 7816 , ISO/IEC 14443, JavaCard/GP, ISO/IEC 7501-3 (ICAO) - post issuance secure updating of data as well as application downloading supported as an option - Multi-vendor support

  22. Cardholderidentification requirements • The system shall support a secure and reliable cardholder identification function: • Personal data of the cardholder shall be held in an electronic form • The Personal data set shall contain as a minimum for interoperability: - (optional) national identification number - family name(s), given name - sex - date of birth - (optional) place of birth - (optional) nationality This file is (optionally) PIN/Biometric protected • The Card related data set shall contain as a minimum for interoperability: - card issuer name/reference - card number - country name, - date of issuance - expiration date

  23. Cardholder authentication requirements • The system shall support a secure and reliable cardholder authentication function • A PIN is mandatory and shall be compliant with ISO/IEC 7816-4 • Biometrics are optional If biometrics are included the following applies: - 1:1 verification compliant to ISO/IEC 7816-11 - a Biometric OID in support of multiple biometric technologies must be present compliant to ISO/IEC 19785-1 (under development) - Fingerprint minutia data is recommended. Implementation shall be compliant to ISO/IEC 19785-2 (under development) - Biometric template storage shall be on the card - Biometric matching on the card is recommended • A Signature key for authentication purposes - shall be present - shall occur only once and shall be protected so it cannot be derived - shall be protected against unauthorized usage by PIN and optionally by biometrics

  24. Electronic signature requirements • The system shall support a secure and reliable cardholder electronic signature funtion for the purpose of legal validaty of the signature • For Europe the PKI system elements of the system shall be in complicance with the qualified digital signature as per article 5.1 of the EU directive 1999/93/EC on a Community framework for electronic signatures • The PKI system elements shall be in compliance with ETSI QCP 101456 (under revision) • The PKI system elements shall be in compliance with CWA 14890 parts 1 –2

  25. Electronic signature requirements (2) • The PKI system elements shall be in compliance with ETSI QCP 101456 The main issues being: - registration procedures - information content of a certificate - liability of the certificate authority - responsibility for protecting the eID card and its content - loading of other applications on the card - renewal of an eID card - prevention of use of eID card and its certificates - cancellation of an eID card - requirements for the supporting PKI (i.e. CWA 14171) - obtaining and protecting the CA certificate - obtaining certificate status information

  26. Electronic signature requirements (3) • Compliance with CWA 14890 (area K) part 1 and 2: - key pair generation on board card - storage of keys on board card - compliance with 7816/15 (PKCS 15) and Crypto Objects - signing function will be PIN and/or Bio protected - data to be signed cannot be altered - the format for electronic signatures and their certificates shall be interoperable - secure messaging shall be supported (symmetric crypto) - algorithms as in EU WS eSign algo document shall be supported - public available certificate status verifying function for relying parties • PKI shall be implemented in the following way:- minimum of 2 certificates (1 for signing; 1 for other functions) - compliant with X509 V3 minimum profile: name of CA, name of Cert holder, unique identifier of Card Holder /Certholder, period of validity of certificate, serial number of certificate, pointer to info on CA certificate policy

More Related