Through its security architecture and development practices X-Road provides a versatile security solution that consists of multiple layers.

X-Road Security Architecture

The identity of each organization (X-Road Service Provider or Service Consumer) and technical entry point (Security Server) is verified using certificates that are issued by a trusted Certification Authority (CA) when an organization joins an X-Road ecosystem. The identities are maintained centrally, but all the data is exchanged directly between a consumer and provider. Message routing is based on organization and service level identifiers that are mapped to physical network locations of the services by X-Road. All the evidence regarding data exchange is stored locally by the data exchange parties, and no third parties have access to the data. Time-stamping and digital signature together guarantee non-repudiation of the data sent via X-Road.

Central Server

The Central Server contains the registry of X-Road members and their Security Servers. In addition, the Central Server contains the security policy of the X-Road instance that includes list of trusted certification authorities, list of trusted time-stamping authorities and configuration parameters. Both the member registry and the security policy are made available to the Security Servers via HTTP protocol. This distributed set of data forms the global configuration that Security Servers use for mediating the messages sent via X-Road.

Security Server

The Security Server encapsulates the security aspects of the X-Road infrastructure: managing keys for signing and authentication, sending messages over secure channel, creating the proof value for messages with digital signatures, time-stamping and logging.

The Security Server downloads and caches up-to-date global configuration and certificate validity information from the Central Server. Caching allows the Security Server to operate even when the information sources are unavailable.

Protecting data in transit

The Security Server manages two types of keys to protect data in transit between the Security Servers. The authentication keys are assigned to a Security Server and used for establishing cryptographically secure communication channels with the other Security Servers. X-Road messages transmitted over the public Internet are secured using Transport Layer Security (TLS).

The signing keys are assigned to the Security Server's clients and used for signing the exchanged messages. All X-Road messages are signed by the signing key of the organisations that send the messages and all messages are logged. The signature is always verified by the recipient.

Certificates for the authentication and sign keys are issued by a trusted certification authority. Certificates issued by other certification authorities are considered invalid. When processing messages, the Security Server verifies that certificates have been issued by a trusted Certificate Authority, are valid (not expired or revoked) and are issued to the member organisation that is presenting them.

Protecting data at rest

The Security Server manages additional encryption keys to protect data at rest. The data protection features provide the possibility to encrypt and sign specific data stored on the Security Server. By default, encryption is turned off, and the Security Server administrator can manually enable it.

Access Rights to services

The Security Server handles access control on the organisation level during data exchange between registered X-Road members. The key idea of X-Road is that each service provider owns its data and is responsible for managing access rights of its services. In other words, publishing services via X-Road does not automatically provide other members access to the services.

Full version of the X-Road security architecture is available here.

Security in X-Road Development

Here's a high level summary of the security activities in X-Road development:

  • X-Road has a public bug bounty program that’s open for everyone.

  • Regular security assessments are conducted by a third party.

    • An assessment typically includes an architecture review, threat modelling and penetration testing.

  • Changes to source code are peer reviewed.

    • All source code changes are peer reviewed by another development team member before they’re merged into a stable branch.

  • Threat modelling is arranged internally.

    • Threat modelling sessions are arranged for new significant features, bigger changes to existing features and changes directly related to security.

  • Static source code analysis is run using SonarQube.

    • Run automatically as a part of CI pipeline.

  • Dependency checks are run using OWASP Dependency-Check.

    • Run automatically as a part of CI pipeline.