wspes

1. www.wspes.org eGovernance workshop Prato March 5th 2007 A practical solution to the interoperability challenge in PKI related on-line services

2. Part ISPES & W-SPESProject Presentation

3. Call Reference: eTEN 2004-01 (Initial Deployment) Start Date: 01/02/2006 End Date: 30/01/2008 Funding from EU: 1.2 M€ (10% of project costs) N. Partners involved: 15 from 5 EU countries W-SPES stands for “Widening SPES” (eTEN 2002-2004) The scope is to: - “deploy” the adoption of the solutions set-up by SPES in new partner sites - Re-using SPES services and/or interoperability approach. - Re-using SPES PKI / EU-PKI services Setting Processes for Electronic Signature

4. SPES partners • Comune di Prato, (IT), co-ordinating partner • Comune di Bologna, (IT), contractor • Landeshauptstadt Saarbruecken/IKS, (D), contractor • Sheffield City Council, (UK), contractor • Municipality of Naestved, (DK), Member These partners (excluding Naestved and Bologna) formed a new consortium (W-SPES) with some newcomers……

5. W-SPES new partners / 1 • Sunderland City Council (United Kingdom) • City of Bremerhaven (Germany) • Dundee City Council (United Kingdom) • City of Koper (Slovenia) • Province of Piacenza (Italy)

6. New W-SPES partners / 2 • Province of Prato (Italy) • All the Prato Province Towns (Italy) • Prato Province health care utility (Italy) • Axetel Consulting (Romania)

7. SPES Objectives • To accelerate the introduction of the digital signature in publicadministrations. • To develop Applications/Services through a cross-fertilisation process amongst the partners. • To integrate the digital signature into these applications. • To implement a model organisational structure for the registration authority issuing/managing the digital certificates. • To ensure that a certificate released in one country by a Trusted Third Party can be accepted all over Europe

8. W-SPES Objectives • to extend the scope of SPES and pursue for improved and broader results across European countries. • to encourage mutual co-operation and replication of experiences. • to consolidate the use of digital signature and strong authentication. • to identify and classify the knowledge deriving from the SPES project. • to set up a number of interactive and secure electronic services which require strong authentication and/or digital signature. • to consolidate the SPES CA cross-recognition scheme.

9. Advantages • Network allowing trusted exchange of documents. • Uses in the Authorisation & Licensing service category for professionals (e.g.: building permit requests) • Provision of new style of web based applications with the integration of the digital signature. • Creation of paper-less environment. • Benefits for citizens via internet, kiosks or commercial shops • Payment of bills / taxes • Personal information enquiries - Social Security, Tax, Fines, service related data, etc.

10. Advantages of EU Level Work/1 • EU funding contributes to accelerate processes which are often neglected by local authorities. • Improves quality of processes by encouraging the exchange of experiences among partners. • Creation of a useful framework of interoperability, for developing common strategies and practices.

11. Advantages of EU Level Work/2 • A common and entrusted language allowing sharing and exchanging of documents and information. • Overall cost reduction as initial deployments can be tested and different approaches compared before full deployment takes place. • Reduced entry cost and risk for others wanting to join, because where SPES partners have taken the lead, others can analyse their experiences and follow, adding value to the process.

12. Services • The SPES project was based around the development of some 20 applications needing Digital signature and/or strong authentication. • These included recognised Best Practice – Bruxelles 2001 award winning applications and Como award 2003 winning applications. • Full list of SPES applications on the SPES web site www.spesproject.org

13. Services • The W-SPES project identified last June the final list of applications to be implemented and needing Digital signature and/or strong authentication. • Some of them as re-use of SPES ones. • Some other ones are integrating the SPES developed interoperability modules • Full list of W-SPES applications will be reported ion the project web-site (Forecast end of March 2007) www.wspes.org

14. Sunderland City Council (UK) • Single-Sign-On Services for citizens interacting with local government services • Youth Opportunity Card Services to Young People (13-25yrs) • Smartcard-based ID for citizens making cash/cheque payments at automatic kiosks • Strong Authentication to an Identity Management Provider – user provisioning in multiple financial systems

15. Bremerhaven City Council (Germany) • Holiday Request • The electronic document register and document workflow management • Gravestone Permission • Electronic management of building authorization

16. Dundee City Council (UK) • Housing Referrals • Common Housing Register • Reimbursement of Employees’ Expenses • Application for Annual & Other Leave

17. Koper City Council (Slovenia) • Public procurement internal workflow • Information on the status of citizen's applications • Building location information

18. Province of Piacenza (Italy) • Electronic protocol and document flow management • Unified access for enterprises • SIT – Territorial System Information • Form server • Payments in Commercial shops • Internal document flows • Government gateway

19. Province of Prato (Italy) • Electronic document register and document workflow management; • Building local tax account system; • Payments on commercial shops.

20. Health care utility of Prato (Italy) • The electronic document protocol register and document workflow management • Building Document Management • Payments on commercial shops. • Web Portal for Family Physicians

21. Target Users Intermediate Users • Employees of public bodies, utilising the selected processes within their own administrations. End Users: • Citizens wanting to use applications that require authentication, integrity, confidentiality and non-repudiation on data exchange with the city administration • Professionals and Business Intermediaries who are those that normally manage interaction with the public offices on behalf of small firms. • Enterprises who directly interact with administrations

22. Expected local Benefits • Improved service to citizens. • Positive effects on the local economies of the municipalities and a boost for local industry. • Overall improvement in the quality of life for citizens and for the personnel involved.

23. Expected Final Results • The background objective is to foster European integration • SPES stands for: Setting Processes for Electronic Signature..but • “The hope” (in Latin SPES) is that an SME or a citizen in one country will be able to request a service (e.g. authorization) electronically from a Public Administration in another country. That will be possible on the day in which the digital signature will be recognised and accepted by the receiver. The SPES project will contribute to this acceptance.

24. W-SPES - State of the art • Milestone 1 : Best practice internal workshop (Jun 2006) • Milestone 2 : Detailed project plan (Aug 2006) • Milestone 3 : Services ready to start (Jan 2007) • Milestone 4 : Services rolled-out (Jan 2008)

25. W-SPES – some demos • Payments in commercial shops (Prato) DEMO • Building tax On-line (Prato) DEMO • Building permits on-line (Prato) see later

26. Part IISPES & W-SPES: A practical solution to the interoperability challenge in PKI related on-line services

27. The problem • Digital Signature schemes (PKI) are becoming the key to secure advanced citizens services on the Internet & info-kiosks • Interoperability between local solutions thus becomes more and more important • The question is: ”How do we ensure that citizens from one EU country can access services from another EU country ?”

28. SPES objectives/1 • To propose a practical technical approach to facilitate the introduction of European on-line services which will: • Accept digital certificates issued by different European CA’s • To uniquely associate the provided digital certificate with the physical identity of the service user

29. SPES objectives/2 • Identifying the major obstacles to interoperability between CA solutions: • Cooperation between CA’s is difficult due to many factors. The cooperation must be kept as simple as possible • ID information stored on cards differs from country to country. Alternative methods of identification must be found for on-line identification of the user • Development of a set of tools to deal with the interoperability problem in a pragmatic manner

30. SPES Trust & Security issues • General architecture for: • Strong Authentication • Digital signature Usage of PKI technology (this is in concrete the core of SPES technical activity) Digital certificates stored in Smart CARDS

31. Trust & Security issues Key points • General system architecture definition • availability of PKI modules in selected applications • implementing missing modules • Integrating existing ones • replication of experiences • Strong authentication interoperability issues • Digital signatures interoperability issues

32. Trust & Security issues 2 2 Web server 1 Web server 2 Web server N 1 3 1 Strong authentication Scenario 1 Distributed Https 2 Client Client module (provided by the CA) to support https in Internet Explorer (PC/SC) or Netscape (PKCS#11) 2 • Server module to recognize the certificate. Depends on: • OS • web server platform • application RA tools

33. Trust & Security issues 2 2 Web server 1 Web server N 4 1 1 3 Server module interacting with the Authentication server 3 Strong authentication Scenario 2 Centralized Authentication server Https 3 Client Client module (provided by the CA) to support https (Internet Explorer/Netscape) • Server module to recognize the certificate. Depends on: • OS • web server platform • application RA tools

34. Trust & Security issues 2 Discussion (Scenario 1): • The availability of the client module (from the CA) for all the user platforms (normally available for the main browser platforms). • The module is normally integrated in the web server platform (need only to be configured). • The software implementation depends on the API used and the hosting OS . • To technically identify the user it is only necessary to have the CA data and DN structure. • To logically identify the user at a European level a unique identification key is missing (fiscal code, social security code, etc.). • The user identity often depends on the OS user management system used for each web server.

35. Trust & Security issues Discussion (Scenario 2): • The availability of the client module (from the CA) for all the user platforms (normally available for the main browser platforms). • The module (some parts) are normally integrated in the web server platform (only need configuration), additional module have to be realised. • Soft dependence of the software implementation on the hosting OS and web platform (API). • Unavailability of largely adopted standard (open) for interaction • To technically identify the user it is only necessary to have the CA data and DN structure. • To logically identify the user at a European level a unique identification key is missing (fiscal code, social security code, etc.). • The user identity does not depends on the OS user management systems used for each web server. • The user identification problems are centralised in the Authentication server • Security measures between web servers and authentication server. 2 2 3

36. Trust & Security issues Interoperability issues The presence of HTTPS protocol solves almost completely the interoperability problems between user client software and web server software modules. Residual problems: • CA certificate options policies. • Large number of recognised CA is needed. • The DN structure must be recognised. • It is necessary to map user DN on to a user identification key in the applications The scenario 2 simplifies the solution of these problems

37. Trust & Security issues 1 2 3 1 2 Digital Signature scenario 1 End-to-End DS creation/verification Signing tool Signing tool Verification tool Verification tool Server Client Client CA/RA tools

38. Trust & Security issues 2 1 1 2 2 3 1 Digital Signature scenario 2 DS verification via Application server Signing module Verification web tool Signing module Signing web tool Verification module Verification module Client Server ActiveX, Applets, etc. CA/RA tools

39. Trust & Security issues Discussion • Signing tools normally provided by selected CAs. • Verification tool necessary in two different versions (end user / application software API). • Web signing tool, suitable in the scenario 2, very critical for interoperability issues (it depends on the user side selected CA) • The interoperability issues in DS verification concerns: • Digital certificate formats/variants • Digital signature file format • To technically identify the user it is necessary to have the known DN structure. • To logically identify the user at European levels a unique identification key is missing (fiscal code, social security code, etc.). • Two type or RA are suitable depending on national legislation and selected application • strong signature • light signature It is necessary to make a distinction between them

40. Trust & Security issues Interoperability issues • Adopted standard for message envelope. • Large number of recognised CA is needed. • The DN structure must be recognised. • It is necessary to map user DN on to a user identification key in the applications The interoperability problems have been faced developing a verification tool for SPES - RECOGNIZED digital signatures (selecting the scenario 1)

41. Summary of SPES Interoperability approach Digital Signature & Strong Authentication • Digital signature verification tool • Centralised authentication server • Using of EUPKI CA/RA Open source tools (W-SPES) • Cross recognition among CAs • SPES recognised CAs Trusted list • CA / RA standard policies • Memorandum of Agreement among the involved CAs • Registration procedure before accessing the service

42. SPES DS verification tool

43. Web application Service request (1) Redirect to AS (2) Browser Internet (BW) Service Access (5) Redirect to service (4) Authentication server Authentication (3) Centralised Authentication (general scheme)

44. Autentication server Service B Service A Centralised Authentication Diagram : • First service access 1) First request 2) Redirect 3) Login Page 4) Submit Form 5a) Autentication cookie 5b) Redirect to service 6) Service A Cookie 7) Service A usage

45. Autentication server Service B Service A 1) First request Centralised Authentication Diagram: • new service request • session timeout not expired 2) Redirect 3) Authentication cookie renewal 4) Redirect to service 5) Service A Cookie 6) Service A Accession

46. Autentication server Service B Service A 1) newt request Centralised Authentication Diagram: • same service request • service cookie not expired • session timeout not expired 5) Service A Cookie renewal 6) Service A Accession

47. Centralised Authentication Authentication security level structure Authentication 1a … Trust Level 1 Authentication 1b Trust level 2 Authentication 2a … Authentication 2b … Authentication 3a … Authentication 3b Trust level I Authentication na … Authentication nb Trust level N Token translation capability !

49. ACCEPTED SMART CARD (Prato) Italian Electronic ID card All Italian commercial CAs Municipality Employees ID card Other SPES partner CAs

50. SPES CA Trusted List