Setting Processes for Electronic Signature 1 eGovernance workshop Prato March 5th 2007 A practical solution to the interoperability challenge in PKI related on-line services

Setting Processes for Electronic Signature 2 Part I SPES & W-SPES Project Presentation

Setting Processes for Electronic Signature 3 Call Reference:eTEN (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 ) 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 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 SPES partners These partners (excluding Naestved and Bologna) formed a new consortium (W-SPES) with some newcomers……

Setting Processes for Electronic Signature 5 Sunderland City Council(United Kingdom) City of Bremerhaven(Germany) Dundee City Council(United Kingdom) City of Koper(Slovenia) Province of Piacenza(Italy) W-SPES new partners / 1

Setting Processes for Electronic Signature 6 Province of Prato(Italy) All the Prato Province Towns(Italy) Prato Province health care utility(Italy) Axetel Consulting(Romania) New W-SPES partners / 2

Setting Processes for Electronic Signature 7 To accelerate the introduction of the digital signature in public administrations. 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 SPES Objectives

Setting Processes for Electronic Signature 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.

Setting Processes for Electronic Signature 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.

Setting Processes for Electronic Signature 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.

Setting Processes for Electronic Signature 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.

Setting Processes for Electronic Signature 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

Setting Processes for Electronic Signature 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)

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

Setting Processes for Electronic Signature 15 1.Holiday Request 2.The electronic document register and document workflow management 3.Gravestone Permission 4.Electronic management of building authorization Bremerhaven City Council (Germany)

Setting Processes for Electronic Signature 16 1.Housing Referrals 2.Common Housing Register 3.Reimbursement of Employees’ Expenses 4.Application for Annual & Other Leave Dundee City Council (UK)

Setting Processes for Electronic Signature 17 1.Public procurement internal workflow 2.Information on the status of citizen's applications 3.Building location information Koper City Council (Slovenia)

Setting Processes for Electronic Signature 18 1.Electronic protocol and document flow management 2.Unified access for enterprises 3.SIT – Territorial System Information 4.Form server 5.Payments in Commercial shops 6.Internal document flows 7.Government gateway Province of Piacenza (Italy)

Setting Processes for Electronic Signature 19 1.Electronic document register and document workflow management; 2.Building local tax account system; 3.Payments on commercial shops. Province of Prato (Italy)

Setting Processes for Electronic Signature 20 1.The electronic document protocol register and document workflow management 2.Building Document Management 3.Payments on commercial shops. 4.Web Portal for Family Physicians Health care utility of Prato (Italy)

Setting Processes for Electronic Signature 21 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 Target Users

Setting Processes for Electronic Signature 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.

Setting Processes for Electronic Signature 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.

Setting Processes for Electronic Signature 24 W-SPES - State of the art Milestone 1 : Best practice internal workshop(Jun2006) Milestone 2 : Detailed project plan(Aug2006) Milestone 3 : Services ready to start(Jan2007) Milestone 4 : Services rolled-out(Jan2008)

Setting Processes for Electronic Signature 25 W-SPES – some demos Payments in commercial shops (Prato)DEMODEMO Building tax On-line (Prato)DEMODEMO Building permits on-line (Prato)see later

Setting Processes for Electronic Signature 26 A practical solution to the interoperability challenge in PKI related on-line services Part II SPES & W-SPES:

Setting Processes for Electronic Signature 27 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 ?” The problem

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

Setting Processes for Electronic Signature 29 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 SPES objectives/2

Setting Processes for Electronic Signature 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

Setting Processes for Electronic Signature 31 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 Key points Trust & Security issues

Setting Processes for Electronic Signature 32 Trust & Security issues Strong authentication Scenario 1 Client Web server 1Web server 2Web server N Https 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 3 RA tools Distributed

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

Setting Processes for Electronic Signature 34 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. Trust & Security issues 2

Setting Processes for Electronic Signature 35 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 Trust & Security issues

Setting Processes for Electronic Signature 36 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 Trust & Security issues

Setting Processes for Electronic Signature 37 Digital Signature scenario 1 End-to-End DS creation/verification Client 1 Signing tool 2 Verification tool 3 CA/RA tools Client 1 Signing tool 2 Verificati on tool Server Trust & Security issues

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

Setting Processes for Electronic Signature 39 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 Trust & Security issues

Setting Processes for Electronic Signature 40 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) Trust & Security issues

Setting Processes for Electronic Signature 41 Summary of SPES Interoperability approach Digital Signature & Strong Authentication 1. Digital signature verification tool 2. Centralised authentication server 3. Using of EUPKI CA/RA Open source tools (W-SPES) 4. Cross recognition among CAs 5. SPES recognised CAs Trusted list 6. CA / RA standard policies 7. Memorandum of Agreement among the involved CAs 8. Registration procedure before accessing the service

Setting Processes for Electronic Signature 42 SPES DS verification tool

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

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

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

Setting Processes for Electronic Signature 46 Centralised Authentication Diagram: same service request service cookie not expired session timeout not expired 6) Service A Accession 5) Service A Cookie renewal Service A Autentication server 1) newt request Service B

Setting Processes for Electronic Signature 47 Centralised Authentication Authentication security level structure Trust Level 1 Trust level 2 … Trust level I Trust level N Authentication 1a Authentication 1b … Authentication 2a Authentication 2b … Authentication 3a Authentication 3b … Authentication na Authentication nb … Token translation capability !

Setting Processes for Electronic Signature 48

Setting Processes for Electronic Signature 49 ACCEPTED SMART CARD (Prato) Italian Electronic ID card Municipality Employees ID card All Italian commercial CAs Other SPES partner CAs

Setting Processes for Electronic Signature 50 SPES CA Trusted List

Setting Processes for Electronic Signature 51 Memorandum of Agreement (3) Memorandum of Agreement –Template of agreement –Sets out the processes by which the certification authority can be accepted on list Key principle –No added liability –The relying party remains in exactly the same position with or without the intervention of SPES in the process

Setting Processes for Electronic Signature 52 Memorandum of Agreement (4) SPES recognition request New CA Relying party MoA Signature UE directive compliance analysis Policies Analysis Interoperability analysis Acceptance Inclusion in SPES Interoperability instruments Maintenance

Setting Processes for Electronic Signature 53 eID CodePersonal Data On-line Registration Back-Office (associates the application specific key) CitizenOn-line services On-line registration

Setting Processes for Electronic Signature 54 The main achievement of the SPES project has been addressing the interoperability problem and reaching a pragmatic solution to this problem. The proposed solution is: –Relatively easy to set up, –Scalable and open to new CA acceptance in the project, –Easily integrated in the partner process. The solution differs from other interoperability solutions by being much more flexible and easy to set up. The findings of the project have been communicated in a ”Lessons Learned” document produced at the end of the project. Why the SPES solution ?

Setting Processes for Electronic Signature 55 W-SPES – some demos Payments in commercial shops (Prato)DEMODEMO Building tax On-line (Prato)DEMODEMO Building permits on-line (Prato)Registration First accessRegistration First access DEMO

Setting Processes for Electronic Signature 56 eGovernance workshop Prato March 5th 2007 A practical solution to the interoperability challenge in PKI related on-line services Thanks for attention !