CEN WORKSHOP CWA 15264-1 April 2005 AGREEMENT ICS 35.240.15 English version Architecture for a European interoperable eid system within a smart card infrastructure This CEN Workshop Agreement has been drafted and approved by a Workshop of representatives of interested parties, the constitution of which is indicated in the foreword of this Workshop Agreement. The formal process followed by the Workshop in the development of this Workshop Agreement has been endorsed by the National Members of CEN but neither the National Members of CEN nor the CEN Management Centre can be held accountable for the technical content of this CEN Workshop Agreement or possible conflicts with standards or legislation. This CEN Workshop Agreement can in no way be held as being an official standard developed by CEN and its Members. This CEN Workshop Agreement is publicly available as a reference document from the CEN Members National Standard Bodies. CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG Management Centre: rue de Stassart, 36 B-1050 Brussels 2005 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No.:CWA 15264-1:2005 E
Table of Content Foreword...4 1 Introduction...5 1.1 Scope and objectives...5 1.2 Informative References...5 1.3 Concepts and definitions...6 1.4 Abbreviation...12 2 Contextual Model for IAS interoperability...17 2.1 Trust models...17 2.2 Interoperability of IAS between schemes...18 3 Conceptual model for IAS interoperability...18 3.1 Roles...19 3.2 Processes...21 3.3 SCMF and generic trust model...24 3.4 Smart card communities and communities...24 4 The IAS functional model...25 4.1 The IAS platform function...25 4.2 The platform function...26 4.3 The crypto function...26 4.4 The application function...26 4.5 The connectivity function...26 4.6 The Human Interface function...26 5 IAS system architecture...27 5.1 The Smart layer...27 5.2 The layer...27 5.2 The layer...28 5.4 The layer interfaces...28 6 The functional model in the IAS system architecture...29 6.1 The functional model in the Smart Layer...30 6.2 The functional model in the User Access Point sub-layer...31 6.3 The functional model in the Access Point sub-layer...31 6.4 The functional model in the Layer...31 6.5 The functional model in the PKI service sub-layer...32 7 High level description of the primary processes - formal description...32 7.1 UC 1.0.: activation...32 7.2 UC.1.1.: Securing of the terminal-card link...33 7.3 UC.1.2.: Component Authentication...33 7.4 UC.N.3.: Certificate validation...34 7.5 UC.2.0.: Connection to...35 2
7.6 UC.2.1.: Securing of the link...35 7.7 UC.2.2.: holder authentication by PKI...36 7.8 UC.3.2.: holder authentication by PIN/BioCode...36 7.9 UC.3.0.: Interaction with the...37 7.10 UC.3.1.: Signing of a data object...37 7.11 UC.4.0.: Closing of the Connection...38 7.12 UC.5.0.: deactivation...38 8 IAS interoperability...39 8.1 IAS interoperability scenarios...39 8.2 IAS Interoperability architecture...39 8.3 IAS interoperability processes...45 9 Securing interoperability...45 9.1 Introduction...45 9.2 Securing the -Terminal interface (IOP#1)...45 9.3 Securing the User Access Point - Access Point link (IOP#2)...46 9.4 Securing the access to PKI services (IOP#3)...46 9.5 Securing the Access Point - link (IOP#4)...46 9.6 Securing the on-card applications IAS function interface (IOP#5)...46 10 Common requirements for IAS interoperability...48 10.1 Requirements related to the execution of the primary processes...48 10.2 Requirements on secondary processes...55 Annex A Mandatory field in certificates...59 Table of Figures Figure 1: Towards a smart card infrastructure based on a common eid... 5 Figure 2: Simple 3-entity Trust model... 17 Figure 3: 4-entity Trust model... 17 Figure 4: Role modelling... 20 Figure 5: eauthentication primary process high-level use cases... 22 Figure 6: Generic trust model... 24 Figure 7: The trust model in the SCMF... 24 Figure 8: Interoperability of IAS services... 24 Figure 9: The functional box model... 25 Figure 10: Smart card information system architecture... 27 Figure 11: eauthentication system architecture... 28 Figure 12: The functional model in the IAS system architecture... 30 Figure 13: Primary processes model... 32 Figure 14: The Activation use case (UC 1.0.)... 32 Figure 15: The Connection to use case... 35 Figure 16: The interaction with the use case... 37 Figure 17: Summary of interoperability scenarios and levels... 39 Figure 18: IOP... 40 Figure 19: IOP - case 1... 41 Figure 20: IOP - case 2... 42 Figure 21: IOP - case 3... 42 Figure 22: On-card IOP - case 1... 43 Figure 23: On-card IOP - case 2... 43 Figure 24: On-card IOP - case 3... 44 3
Foreword The production of this CWA (CEN Workshop Agreement) was formally accepted at the e-authentication Workshop's kick-off meeting on 2003-09-16. The document has been developed through the collaboration of a number of contributing partners in WS-eauthentication, representing smart card interests. This CWA has received the support of representatives of each of these sectors. A list of company experts who have supported the document's contents may be obtained from the CEN/ISSS Secretariat. This CWA consists of the following parts, under the general title CWA 15264: Part 1: Architecture for a European interoperable eid system within a smart card infrastructure Part 2: Best Practice Manual for card scheme operators exploiting a multi-application card scheme incorporating interoperable IAS services Part 3: User Requirements for a European interoperable eid system within a smart card infrastructure 4
1 Introduction 1.1 Scope and objectives This part of the CWA defines the interoperability architecture for the implementation of a smart-card based interoperable public eauthentication/eid infrastructure across Europe to be primarily used in the egovernment domain. The workshop considers smart cards as being Integrated Circuits contact cards, Integrated Circuits contactless cards and combined cards with either 2 or more chips on board or 1 chip with both contact and contactless communication capabilities. Although the use of SIM cards is not considered explicitly in this document, this does not exclude the use of SIM card based eid, especially when used for authentication and digital signature purposes. This document models the Interoperability (IOP) problematic from different perspectives in the following order: Context, concluding requirements Concepts o functional view o technical architecture for a smart card based eid system using on-line egovernment applications o dataflows view (description independent from technical solutions) o interoperability issues Specifications / common requirements for interoperability The CWA eauthentication intends to support migration from situation 1 (see below) where each eid-card has its own infrastructure and trust services into a situation 2 where card body, microprocessor, smart card infrastructure as well as trust services may be shared between different providers. epassport edriving license elogical access ehealth esocial security 1 2 egov. / ebus. on-card / on-line services Figure 1: Towards a smart card infrastructure based on a common eid The CWA considers the Identification, Authentication and electronic Signature function (IAS) as a generic one to be used for accessing online egovernment services with smart cards. Issues regarding the content and internal way of function of an application are out of scope. The CWA does however describe the relevant interface between the generic function and the application. 1.2 Informative References Open Smart for Europe v2, (March 2003) eesc Common Specifications for interoperable multi-application secure smart cards v2.0 5
ITU-T Recommendation X.811 (1995) Information Technology -Open Systems Interconnection - Security Frameworks For Open Systems: Authentication Framework ITU-T Recommendation X.813 (1996) Information_Technology- Open Systems Interconnection - Security Frameworks In Open Systems: Non-Repudiation Framework ISO/IEC 7816 4 (FCD 2003) Identification cards Integrated circuit(s) cards with contacts Part 4: Organization, security and commands for interchange ISO/IEC 7816-15 (2002) Identification cards Integrated circuit(s) cards with contacts Part 15: Cryptograpic information application CEN/ISSS WS/E-Sign CWA 14890 1,2 Group K eepoch project, Deliverable D4.2IOP Demonstrator "Safelayer Secure Communications" NICSS-Framework Scheme, NICSS Prerequisites, First Edition, Version 1.20, April 24, 2001 NIST Special Publication 800-63 (2004) Draft Recommendation for Electronic Authentication ISO/IEC JTC 1/SC 37 Standing Document 2, Vocabulary on Biometrics 1.3 Concepts and definitions Abort Acceptor Access (AP) Provider To abnormally terminate a process An entity whose primary role is to provide business services/goods to a person using the smart card for accessing e-services or receiving goods. Also known as Service Provider. An entity in charge of managing the infrastructure (i.e. the card readers, terminals and necessary drivers, communication network and servers) used by card holders accessing the offered services. Accessibility Usability of a product, service, environment or facility by people with the widest range of capabilities In the context of this CWA, "accessibility" typically addresses users who have a disability, but the concept is not limited to disability issues. Advanced electronic signature An electronic signature which meets the following requirements Chapter 1 It is uniquely linked to the signatory; Chapter 2 It is capable of identifying the signatory; Chapter 3 It is created using means that the signatory can maintain under his/her sole control; and Chapter 4 It is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable. Under certain conditions, an advanced electronic signature may be considered as a qualified digital signature (q.v.) 1 according to Directive 1999/93/EC 1 q.v. stands for Quo vide - Which see 6