Learning Center
Plans & pricing Sign in
Sign Out

X road overview (DOC)


									                                  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

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
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
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
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

                                                              X-Road server             XMLRPC

                                                               X-Road –
                                                              secure and
                                            X-Road protocol
  Client (SOAP)          X-Road server         (secure)       transparent


                                                              X-Road server            SOAP service


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
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

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:
        Protocol: Data exchange protocol between database and information system.
         Requirements on information systems and adapter servers. Version 7.1
        Ahto Kalja. Estonian example of integration e-government services. 2nd Conference on
         eServices in European Civil Registration. Tallinn, Estonia, September 7th – 8th 2006.

     bdf3f68d-b39d-4c82-8b3b-3e7ff7953b04.doc                                           7/7

To top