X-Road Security Architecture. Source: https://x-road.global/security
The Information System produces or consumes services via X-Road and is owned by an X-Road member. X-Road supports both REST and SOAP as communication methods, however X-Road does not provide automatic conversions between different types of messages and services. The Information System is capable of discovering registered X-Road members and their available services by using the X-Road metadata protocol.
All messages sent via X-Road are time-stamped and logged by the Security Server. The purpose of the time-stamping is to certify the existence of data items at a certain point in time. The Time-Stamping Authority (TSA) provides a time-stamping service that the Security Server uses for time-stamping all the incoming/outgoing requests/responses. Only trusted TSAs that are defined in the Central Server can be used.
The certification authority (CA) issues certificates to Security Servers (authentication certificates) and X-Road member organizations (signing certificates). Authentication certificates are used for securing the connection between two Security Servers. Signing certificates are used for digitally signing messages sent by X-Road members. Only certificates issued by trusted certification authorities defined in the Central Server can be used.
Encryption used
From X-Road’s publicly available documentation we can get a grasp of the encryption algorithms used within the different components of the platform. All the protocols mentioned in the documentation are widely used and well documented. In addition, X-Road has regular third-party security assessments, with a public bug bounty programme.
Estonia’s e-ID system, however, had fundamental implementation failures when in 2011 the government distributed 120,000 faulty ID cards that were found to have programming errors allowing the card to be used by whoever was physically holding it without the need of knowing the respective PIN code.
More worrying, and not limited to 120,000 faulty cards affected, is a core design feature regarding the way private encryption keys were generated and handled. The ID card’s private encryption key used to authenticate digital signatures should be generated inside the card chip to ensure only that card knows it – a good example of privacy by design. Instead, keys were generated in a server operated by the card manufacturer and copied to the card over the internet.
Another software bug was reported in which the same private key was copied to several different ID-cards, allowing cardholders that were assigned non-unique private keys to use one another’s identity.
These above bugs’ origins have been tracked down to Gemalto, the contractor tasked with manufacturing and maintaining functionality within Estonia’s ID cards. This resulted in Gemalto being ordered to pay €2.2 million compensation to the Police and Border Guard Board. Since 2019 another company called Oberthur Technologies has been in charge of manufacturing ID cards and maintaining their functionality.
De-duplication
Very little is publicly available about the deduplication undertaken in e-Estonia, except that the processes of verification and deduplication during identification are overseen by the Police and Border Guard Board (PBGB), according to the Identity Documents Act. Where the applicant for the digital ID has not previously been issued any ID under the Act, it is the PBGB that conducts the process of verification/deduplication. The Identity Documents Act also allows the Authority, who collects the personal data, to transfer it to third parties for the “identification and verification of facts relevant to the issue” and for the “issue and revocation of an identity document.”
The use of biometrics when registering is optional, but there are talks of turning to fingerprints for authentication when using ID cards instead of PIN codes.
Principles of Engagement
Estonia’s e-governance principles were published as follows:
