1 / 44

European Electronic Signature Standardization

European Electronic Signature Standardization. Hans Nilsson, iD2 Technologies, S Patrick van Eecke, ICRI, University of Leuven, B Nick Pope, Security & Standards, UK Denis Pinkas, Bull, F For more information: www.ict.etsi.org. EESSI: European Electronic Signature Standardization.

kapila
Download Presentation

European Electronic Signature Standardization

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. European Electronic Signature Standardization Hans Nilsson, iD2 Technologies, S Patrick van Eecke, ICRI, University of Leuven, B Nick Pope, Security & Standards, UK Denis Pinkas, Bull, F For more information: www.ict.etsi.org

  2. EESSI:European Electronic Signature Standardization Industry Initiative led by ICT Standards Board (CEN, ETSI, ...) Based on a mandate from European Commission Support the requirements of the EU Directive AND The requirements for standards from users and industry First phase: Inventory and work programme Supported by an expert team, reported on July 1 Next phase: Implementation of work programme

  3. Agenda for today The EU Directive and its implications for standardization A standardization framework for electronic signature Standards for CSPs Standards for signature creation and verification products Interoperability standards Proposed work programme and how to participate

  4. The EU Directive and its implications for Standardization Presented by Patrick Van Eecke, ICRI K.U.Leuven This presentation is not a formal interpretation of the Directive on Electronic Signatures and thus does not represent the position of the European Commission

  5. Status of the directive • 13 May 1998: Proposal of draft directive by the Commission • 23 October 1998: Publication of draft directive in O.J. • 13 January 1999: European Parliament opinion in First Reading • 22 April 1999: Political agreement on the Common Position by Telecommunications Council • 24 June 1999: Common position of the Council • Autumn 1999: Second reading by the Parliament and Council • End 1999: Final adoption • Implementation: within 18 months after adoption (2001)

  6. Definitions • Electronic signature • Certification service provider (CSP) • Advanced electronic signature • Signature creation/verification data • Signature creation/verification device • Qualified certificate • “Qualified Signature”

  7. Scope of the Directive

  8. forbidden allowed 1. Authorisation (obligatory) 2. Accreditation (voluntary) Obligation for Member States to control via supervision E.g. self-declaration scheme with subsequent control by governmental body or private institution CSP issuing qualified certificates to the public Internal market 3. Supervision

  9. Qualified signatures Qualified signature: advanced electronic signature + qualified certificate + secure signature creation device Legal Recognition • General principle (art. 5.2): Legal effect for all electronic signatures • Second principle (art.5.1): certain electronic signatures get the same legal effect as hand-written signature Electronic signatures Advanced electronic signatures

  10. Requirements Annex I: Qualified certificate Annex II: Certification Service Providers issuing qualified certificates Annex III: Secure Signature Creation Device Recommendations Annex IV: Signature Verification The Annexes

  11. Liability causes Incorrect contents of the certificate Person identified in certificate does not hold corresponding signature creation data Incorrect matching of signature creation and verification data (if CSP provides these data) Malfunctioning of the CRL Exemptions CSP can prove he has not acted negligently Certificate is used contrary to the limits on the use of the certificate Liability Only for CSP fulfilling Annex II and issuing/guaranteeing qualified certificates to the public

  12. International aspects if: • Foreign CA fulfils same requirements + accreditation by Member State or • A European CA guarantees for the foreign CA or • Recognition by treaty with EU Foreign certificates = Qualified certificates

  13. Electronic signature committee • Representatives of the Member States and chaired by a representative of the Commission • Clarifying the requirements of the annexes; • Establishing the criteria for the designation of national bodies which determine the conformity of secure signature creation devices with Annex III (see Article 3.2b); • Determining the generally recognised standards for electronic signature products which would comply with the requirements laid down in point (e) of Annex II and Annex III (see Article 3.3). • EESSI recommendation: • Adding an advisory group to the Committee • consisting of industry experts

  14. A Standardization Framework for Electronic Signature Presented by Hans Nilsson iD2 Technologies

  15. Types of Electronic Signatures

  16. Levels of standardization and regulation National implementation EU Directive National Legislation Signature Law Directive Level 1 Ordinance Annexes National Decree(high-level reqs) Level 2 Supervision Technical Rules International functional andquality standards Level 3 Conformityassessment Standards Internationalinteroperability standards Level 4

  17. International Conformity Assessment Accreditation body for Certification bodies EN 45010 Assessment of Certification bodies Certification body Certification body for products for management systems EN 45011 EN 45012 Certification of Certification of Products Management Systems Manufacturer/ Manufacturer/ Supplier Supplier

  18. Formal certification vs Manufacturer’s Declarations • New Approach directives • only “essential requirements” • Detailed standards published in Official Journal • Conformity assessment “modules”: • Formal evaluation by Notified Body, or • Manufacturer’s Declaration • The ES Directive is not strictly a New Approach directive ! • Formal evaluation required for • Secure signature creation devices (Annex III) • Trustworthy systems used by CSPs (Annex Iie) • Industry would like to see the use of both Formal evaluations and Manufacturer’s Declarations!

  19. Technical Framework for Qualified Electronic Signatures • Although “technology neutral”, the Directive implicitly defines a technical framework • We need to define a “first sets of components” that can be used • A proposed first set that can be used: • Asymmetric cryptography (digital signatures) • Certificate based verification using X.509 • Public Key Infrastructure with CAs and Directories • Smart cards and other hardware tokens for private key protection • Reasons for this selection: • Generally accepted, existing standards • Urgent need for standardized use of these technologies! • Other sets of components can be introduced as soon as there is a need and basis for standardization

  20. Quality & Functional Standards forCertification Service Providers Presented by Nick Pope Security & Standards Consultancy Ltd

  21. Certification Service Provider (CSP) Services • Certification Authority • Registration Authority • Directory • Time-stamping • Attribute Authority • Trusted Archive • Notarisation

  22. General Requirements Security Management of CSPs • Technology / service independent requirements • Reliability • Personnel, management administration • Policy documentation e.g BS 7799, ISO TR 13335 (GMITS)

  23. CSP Issuing Qualified Certificates Annex II - Requirements • Reliability • Revocation & timing of revocations • Verify subject identity / attributes • Personnel and management • Trustworthy systems, cryptographic modules • Financial / liability • Protect against forgery, confidentiality • Record relevant information • Keep keys secret

  24. CSP Issuing Qualified Certificates Minimum Policy Requirements • Security Management • Technical Requirements “Qualified” Certificate Policy Internet RFC 2527 Framework for Certificate Policies

  25. CSP Issuing Qualified Certificates Trustworthy systems & cryptographic modules • Standard for Trusted Systems e.g. Common Criteria Protection Profile CS-2 • Standard for Cryptographic Security e.g. Equivalent to FIPS 140-1

  26. Certification Service Provider (CSP) Services CSP Service Relating to Qualified Certificates • Certification Authority • Registration Authority • Directory Other CSP Services • Time-stamping • Attribute Authority • Trusted Archive • Notarisation

  27. CSP Issuing Time Stamps • Security Management Requirements • Technical Requirements • Use of Trusted Systems

  28. Other CSP Services • Attribute Authorities • Trusted Archive • Notarisation Needs better understanding of requirements

  29. Requirement for CSP Quality & Functional Standards • CSP Security Management • Security Management & Certificate Policy for CSPs Issuing Qualified Certificates • Use of Trusted Systems for CSPs Issuing Qualified Certificates • Security Management & Policy for CSPs Issuing Time Stamps

  30. Functional and Quality Standards forSignature Creation and Verification Products Presented by Hans Nilsson iD2 Technologies

  31. Secure Signature Creation Devices (Annex III) • “Practically occur once, secrecy reasonably assured” • high quality key generation and key protection • strong algorithms, sufficient key length • PIN/password, resistant to dictionary attacks and exhaustive search • Signature created inside device, key never leaves device? • no backup copy, or copy of device? • => smart card or other hardware device! • Security requirement standard needed • Germany, Italy: ITSEC security target • US, Canada: FIPS 140-1 cryptographic module • Eurosmart Common Criteria Protection Profiles: • Smartcard Integrated Circuit • Smartcard IC with embedded software

  32. Secure signature creation process and environment Not required in the Directive, but guidelines are still needed for: • User interface • User urged to verify the information before signing • Willful act: PIN every time? Mouse-click enough? • Handling of signing device and PIN (in contract with CSP) • …… • Operating environment and management • Secure or unsecure card reader • Protection against malicious software

  33. Signature verification (Annex IV) Only recommendations in the Directive, but guidelines needed for: • Human and computer-based verification • Short-term authentication: • All information used for verification shall be “displayed” • Certificate chain shall be verified • Revocation checks shall be performed • Long-term validation of electronic signatures: • evidence for independent adjudicator • requires time-stamping

  34. Interoperability standardization requirements for Electronic Signatures Presented by Denis Pinkas Bull

  35. Syntax and encoding • Specification of the syntax and encoding format of an Electronic Signature, including support for multiple signatures and roles • Enhance CMS – S/MIME and add “ time-stamping ” to support long term validation (*). • ETSI TC Security is working in this area. • Standard for the use of X.509 public key certificates as qualified certificates • Support of the on-going work in IETF PKIX and after its completion, consider if any item is missing (*) For long term Electronic Signature validation see: • http://www.id2tech.com/news/pdf/ES_validation.pdf • http://www.openmaster.com/whitepapers/es_validation.pdf

  36. Syntax and encoding (continued) • Profile for Certificates Revocation Lists (CRLs), Authority Revocation Lists (ARLs), OSCP responses and Time Stamps. • ETSI TC Security should address this requirement. • Standard for storing private keys and other PKI objects on smart cards • The PKCS#15 standard may provide the starting point, but this might be continued by ISO/ JTC1/ SC17. • Standard for description of the constituents of a signature policy understandable both by a human being and a computer. • ETSI TC Security should address this requirement • Standard to reference signature policies.

  37. Additional needs • Establish a repository for certificate policies, signature policies or contract types. • The ICC repository being set up under the E-terms initiative could be used. • Define generic roles relevant to current transactions or contracts • An appropriate international organization should define them (ICC or UNICITRAL)

  38. Studies are needed for ... • Solving name forms and name collisions both from a technical and legal point of view. • topic partly addressed by the PKIX WG that may have to be complemented. • The handling of name and certificate policy constraints in the verification of a certification path. • RFC 2459 does not fully address this concern and an extension to that document should be studied and then proposed to the PKIX working group. • A better understanding of the signature policies.

  39. Studies are also needed for (continued) ... • The way to handle large numbers of revoked certificates. • The way to handle suspended certificates in the context of their use in Electronic Signatures. • The roles of notaries in an electronic world both from a technical perspective and a business perspective.

  40. Protocols • For access to a Time Stamping service. • For access to a repository holding time-stamped certificates and scalable revocation information. • To allow registration without the need to exchange a secret by out-of-bands means. • To allow registration involving smart cards and in particular smart cards being able to generated key pairs. • A profiling of the On Line Certificate Status protocol issued by the IETF may be needed. • A profiling of the Time Stamping protocol under study by the PKIX working group may be needed, once this protocol is published by the IETF.

  41. Application Program Interfaces (API) • Define APIs to allow access to various PKI infrastructures on top of the operational and management PKIX protocols. • Experiment the IDUP non repudiation APIs in conjunction with a standard format for electronic signatures in order to test both portability and interoperability.

  42. Work programme and participation

  43. High-priority work areas

  44. How can YOU participate?? • CEN/ISSS Workshop for Electronic Signatures • Initial planning meeting: October 11, Brussels • Workshop kickoff: December 16-17, Brussels • Result: CEN Workshop Agreements • Contact: luc.vandenberghe@cenorm.be or hans.nilsson@id2tech.com • ETSI SEC: Electronic Signatures Infrastructure WG • Information on October 11 • ESI WG meeting: November 23 • Result: ETSI Standards • Contact: gyorgy.g.endersz@telia.se

More Related