VIEWS: 23 PAGES: 7 POSTED ON: 2/23/2012
Dokumendi turvaklass Dokumendi identifikaator X-Road for International Information Exchange 1. Description of the X-Road System 1.1 Goal The goal of the X-Road project was to build an infrastructure that would allow effortless access to the data in state registries without compromising the security of the data and with minimal impact to the existing systems. 1.2 Background and Requirements There were many registries, all very different, managed and developed by different organizations and financed separately. There were even more users, most of them are very small organizations without security knowledge and with a very small IT budget. The security requirements were high. Registries contained mostly personal data that is in some cases used to make high value decisions and in some cases needed in real time. The initial analysis showed that the priority of the security properties is following: 1. Evidentiary value, authenticity, integrity 2. Availability 3. Confidentiality (restricted data, sensitive personal data) All applications required authenticity, integrity and assurance that it is possible to proof to the third party the origin of some data, received over X-Road. In addition, it was envisioned that X-Road would be used by time-critical applications, like for performing the checks on the border. So, availability was next in the list of priorities. And finally, the confidentiality was required in most, but not all cases. 1.3 Security Mechanisms 1.3.1 Evidentiary Value In order to preserve the evidentiary value and integrity of the data, all outgoing messages are signed. Signing keys are registered with third party (X-Road central agency) that acts as a certification authority. All incoming messages are logged. The message log is cryptographically protected (all log entries are linked together using cryptographic hash function). The intermediate hash values are periodically time-stamped by the X-Road central agency. This allows detecting the message log tampering attempts. Message receiver can later prove with the help of the X-Road central agency when and by whom was the message sent. bdf3f68d-b39d-4c82-8b3b-3e7ff7953b04.doc 1/7 Dokumendi turvaklass Dokumendi identifikaator 1.3.2 Availability In order to ensure the high availability of the system, X-Road is built as a distributed system, with minimal number of central services. Besides certification (that is off line process), X-Road central agency provides time-stamping service and directory service. Time-stamping is used in a way that makes it non-time critical. The directory service is built on top of Secure DNS (DNS-SEC). The usage of well-proven DNS protocol and implementation provides very robust, scalable directory service with built-in caching and redundancy. Security extensions of the DNS (signed zones) ensure that the data cannot be tampered. All X-Road servers have their own local caching DNS server that ensures the availability of directory information even in case of (partial) network outage. X-Road protocol supports redundant servers and load sharing. When there is more than one server that offers some service they will be used in random order by clients. When one server does not answer the system will try next. The negative answer is returned only in case all servers are inaccessible. Servers have also some mechanisms to protect against DoS attacks. Critical resources (i.e. CPU time, file handles) are shared between different clients in a fair manner. When one client (attacker) sends large number of messages it will consume its resource slots quickly. The server keeps fulfilling the requests until there are no other clients. But as soon as some other clients sends message it will get priority over the client who has sent large number of messages. 1.3.3 Confidentiality Most of the data that is exchanged via X-Road is not public or has some special access rules that must be followed. SSL protocol is used as a defence mechanism against external attackers. All exchanged data is encrypted. Two level access rights control mechanism is used as a defence mechanism against internal attackers. The two access control levels are inter-organisational level and intra-organizational level. X-Road core deals only with inter-organizational access control, where one organization grants access right to use some service to other organization as whole. It is the responsibility of the other organization to ensure that only right people can use this service, by using whatever technical means it sees appropriate. The obligation of the other organization to enforce rightful usage of the service is enforced by service provisioning contract between the organizations. This two level access control mechanisms that isolates the details of the authentication and access control mechanisms used internally by the organizations was biggest success factor of the X-Road because the impact to the existing systems was minimized. 1.4 Technical Solution Web services were chosen as a vendor and platform neutral message exchange protocol that is well supported and easy to use for application developers. bdf3f68d-b39d-4c82-8b3b-3e7ff7953b04.doc 2/7 Dokumendi turvaklass Dokumendi identifikaator XMLRPC was used for the first version. SOAP support with two-way transliteration to XMLRPC was added in second version. Third version added support for asynchronous operation, where X-Road servers queue the messages destined to other organization and support for SOAP attachments. X-Road servers can process messages with unlimited size. In addition to the real services that are provided by other organizations, X-Road also provides some meta-services that can be used to find out the structure and properties of the system. It is possible to obtain the list of other organizations providing and consuming the services, for each service provider it is possible to find out the list of services provided for requestor (only those services that are granted to requestor are shown). It is also possible to obtain the formal description of the service (in WSDL or proprietary XML format) for automatic generation of the user interfaces. For client, X-Road server functions as a proxy to all services provided by other organizations, so all services appear to be behind the same URL. The parameters of the requested service are specified in the SOAP header. They are also protected by digital signature and time-stamping mechanisms. XMLRPC X-Road server XMLRPC service X-Road – secure and X-Road protocol Client (SOAP) X-Road server (secure) transparent SOAP X-Road server SOAP service SOAP Figure 1. X-Road Overview The transparent usage of web-services minimizes the impact to existing systems and makes the integration of the X-Road services simple for developers. 1.5 Central Agency X-Road has central agency that ensures its operation. The most important task of the X-Road central agency is to ensure the legal status of the X-Road system and the information exchanged via it by enforcing the stated policies. Central agency is also responsible for steering the further development of the X-Road and ensuring its consistency and integrity. Central agency also runs some technical services, like: bdf3f68d-b39d-4c82-8b3b-3e7ff7953b04.doc 3/7 Dokumendi turvaklass Dokumendi identifikaator 1. certification authority that issues certificates to the X-Road servers operated by the organizations. HSM is used to manage the certification keys. 2. directory service that distributes the information about the structure of the X-Road. 3. time-stamping service that time-stamps the intermediary log values sent by X-Road servers. 4. monitoring service, that monitors all the servers in the system. Monitoring is used for resolving the operational problems in the system, for detecting security breaches by analysing the message statistics and for collecting the statistics about system usage. 5. web-based portal for accessing the X-Road services in a simple and centralized way. The portal is intended to be used for citizens and smaller organizations without sufficient IT capability. 1.6 Implementation X-Road servers are built on a base of GNU/Debian Linux. All the additional software is packaged as Debian packages that can be installed and maintained using standard Debian tools. Debian is one of the most secure and free Linux distributions. In addition self-contained installation CD is provided that installs and configures minimal GNU/Debian Linux and X-Road software with minimal user intervention. X-Road servers have minimal user-interface for maintenance and configuration tasks. There is also built-in patching system that allows to distribute X-Road software in a secure way. All keys, including the top-level certification keys can be changed on the fly, without interruptions to the system operations and with minimal user intervention 2 X-Road Implementation This chapter gives roadmap for X-Road implementation. 2.1 Government First and foremost, an organization is needed that acts as X-Road Central Agency. The organization must have both legal and IT capability. Second, set of policies and rules for operating the X-Road is needed. It would be good idea to align the security measures with existing security frameworks (e.g. BSI in Germany) and define the required security levels via existing terms. X-Road Central Agency is responsible for ensuring that only those organizations meeting the stated security requirements can connect to X-Road. Third, X-Road Central Agency must develop its security policy and operation procedures. Finally X-Road central services must be installed and configured. Due to their importance, the servers must be located in the secure premises. So, some extra effort might be needed for securing the server room. It would be good idea to have several, physically separated locations for central services. bdf3f68d-b39d-4c82-8b3b-3e7ff7953b04.doc 4/7 Dokumendi turvaklass Dokumendi identifikaator 2.2 Service Provider First, service provider must ensure that it has sufficient security measures in place, in order to join X-Road. Security policies and operational procedures may be revised. Second, X-Road server(s) must be installed and configured. Third, existing or new SOAP or XMLRPC services must be developed according to X-Road specifications. It is very easy to make the web services usable in the X-Road. Services will be connected to the X-Road server. Finally, after making the contract with service consumers, access rights to use the service are granted to client organizations. 2.3 Service Consumer First, service consumer must ensure that it has sufficient security measures in place, in order to join X-Road. Security policies and operational procedures may be revised. One of the most important steps is to ensure that the sufficient user authentication and access control mechanisms and policies are in place. Service Consumer has two options for using the X-Road services: 1. X-Road services are integrated into its information system. 2. X-Road portal is used. 2.3.1 Integration of the services This is the preferred way to use X-Road services. Separated X-Road server is installed in the organizations premises and configured. The information system of the organisation is modified, to use the X-Road services proxied by the X-Road server. Finally, after making the contract with service provider, the user access rights are set up according to the contract. 2.3.2 Portal X-Road Central Agency may choose to run X-Road portal. In this case the client organization does not need to have X-Road security server or information system. This is very convenient for smaller organizations without IT capability. The organization must satisfy the security requirements. There must be organizational and physical security measures in place that ensure that the information obtained via X-Road is handled in a safe manner. Organization must appoint the User Manager who is responsible for setting up the user access rights in the X-Road portal in accordance with the contracts made with service providers. Finally, after making the contract with service provider, the user access rights are set up according to the contract. bdf3f68d-b39d-4c82-8b3b-3e7ff7953b04.doc 5/7 Dokumendi turvaklass Dokumendi identifikaator 3 Current State X-Road is currently used by the Government of Estonia and private companies. X-Road is the preferred way for connecting governmental agencies and is also used by private companies to exchange data with government and with the other organizations. Currently (August 2006) there are 69 service providers and 366 service consumers connected to the X-Road. The number services from all the X-road service providers is about 700. The statistics of usage: During the year 2003, the total number of X-road queries was: 590 000. Number of queries made via the X-road in 2004: over 7.75 million Daily record of queries in 2004: 118 000 queries per day Number of queries made via the X-road in 2005: over 13.45 million Some of the services currently available via X-Road: Parent benefit in Intenet. Five information systems interact data: Citizens portal, Register of Social Insurance Board, Population register, IS of Health Insurance Fund, IS of TAX Customs Office. Citizen benefit: Citizen can give applications over the Internet; Citizen does not give data, which the IS knows anyway about the citizen; Citizen does not fill long application documents and run from door to door; A good example how the state has simplified the payment system. Benefit for civil servant: Civil servant is free from revising mountains of paper documents (7); Civil servant is free from inputting the data from paper documents; Civil servant is free from checking data in different databases; Civil servant can start the process by inputting only the personal code of client; There does not exist any paper applications at all. Document repository. Document management systems of public sector have an interface with the central document exchange point. They periodically send for other systems documents and receive them. No need for traditional post. No need for scanners. Documents with metadata are exchanged in XML format. 4 Future Developments Future developments are needed when X-Road will be implemented internationally. Both legal and technical systems need amendments. Right now it seems most logical that X-Road Central Agencies will start from bilateral agreements to acknowledge each other and the stipulated security measures and levels. This is probably the hardest task and can be done only in the cooperation. So, the work can start when there is at least one other country wishing to implement X-Road system. On the technical level the solution must be chosen for the directory and certification infrastructure. Once again, there is multitude of solutions for those problems and the solutions must be analysed together with all the participating countries. It is possible to design the system and rules such, it is already is for third and subsequent countries to join the system. bdf3f68d-b39d-4c82-8b3b-3e7ff7953b04.doc 6/7 Dokumendi turvaklass Dokumendi identifikaator 5 Additional information eTrust instead of eLink?. Estonia’s view. eLink expert group meeting – workshop July 4, 2006, Brussels. Available for eLink experts in CIRCA: http://forum.europa.eu.int/irc/DownLoad/y4quSSJAjj28epqthO1SJ9- EROI0Ipa3pLk0tDm9fqU-O-GC-dvqn- Ev_VvAKd0qYMgqgEhMYp/eLink%20Estonian%20vision%20- %20eLink%20wokshop%204-07-2006.pdf Protocol: Data exchange protocol between database and information system. Requirements on information systems and adapter servers. Version 7.1 ftp://ftp.ria.ee/pub/x-tee/juhendid/nouded_infosysteemidele_en.pdf Ahto Kalja. Estonian example of integration e-government services. 2nd Conference on eServices in European Civil Registration. Tallinn, Estonia, September 7th – 8th 2006. http://22.214.171.124/events/conference_2006/Present/xtkalja.pdf 1. bdf3f68d-b39d-4c82-8b3b-3e7ff7953b04.doc 7/7
"X road overview (DOC)"