One of the core features of X-Road is to protect data in transit, and X-Road includes several mechanisms to protect data when it travels between the data exchange parties. Even if X-Road is not a data storage solution, it doesn’t mean that the Security Server wouldn’t store any sensitive data, at least temporarily. Therefore, X-Road 7.0.0 will introduce new security features to protect data at rest on the Security Server. The new features are:
encrypt backup files (opt-in)
verify the integrity of backup files before running a restore
encrypted message payload in message log database (opt-in)
encrypted message log archives (opt-in)
group message log archives by member or subsystem (opt-in).
This blog post gives an overview of the new security features and their key characteristics.
Common design principles
The new 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. All the encryption-related configuration operations require shell access to the Security Server.
The new data protection features have been implemented using the GNU Privacy Guard (GnuPG) – an open-source implementation of the OpenPGP standard as defined by RFC4880. All operations related to backup files and message log archive files have been implemented in an external GnuPG process. Instead, the message log database encryption has been implemented in Java code.
Image 1. Encryption keys that are used to protect data at rest on the Security Server.
The required keys are stored in GPG keyrings, and Security Server's internal key (1) used by default is generated automatically. The Security Server administrators can manually configure additional and member-specific keys (2, 3, 4). All the new encryption keys are illustrated in image 1.
Configuration backup encryption
Security Server configuration backups contain sensitive information, such as database connection credentials, private keys, etc., and therefore, they should be protected from unauthorized access. Starting from version 7.0.0, the Security Server supports signing and encrypting the backup files.
The backups are always signed, but backup encryption is initially disabled. When encryption is enabled, backup files are encrypted when they are created and stored on disk encrypted. It applies to both automatically created and user-created backups. When it comes to user-created backups, the configuration applies to Security Server UI and REST management API.
When backup encryption is enabled, the backups are signed and encrypted using the Security Server’s automatically generated internal key pair (1). In addition, the Security Server administrator can upload additional keys (2) to the Security Server that are used to encrypt the backups together with the internal key. In practice, the backups are encrypted with the internal key and all additional keys. The backups are always signed with the internal key.
During restore, the Security Server verifies the consistency of backup files automatically. However, if the Security Server’s internal key pair is lost, automatic verification is no longer possible. In that case, the Security Server administrator can restore the decrypted backups from the command line with appropriate options that enable skipping integrity verification.
Configuring additional encryption keys is strongly recommended since the Security Server administrator can use them to decrypt configuration backup files in a situation where the internal key pair is lost. Without additional keys, the encrypted configuration backups are unusable in such a situation.
Message log archive grouping and encryption
Message log archive files may contain sensitive information that different organizations can own if multiple members share a single Security Server. Therefore, in version 7, message log archive files can be encrypted and grouped by member or subsystem.
Message log archive encryption and grouping can be configured separately. For example, the archives can be encrypted but not grouped (or vice versa). By default, both features are disabled. Grouping and encryption are enabled/disabled on a Security Server level - they are either enabled or disabled for all the members and subsystems. It's not possible to enable/disable neither of them for selected members nor subsystems only. When encryption and grouping are combined, each member's messages are stored in separate files encrypted with member-specific keys (4). In addition, when message log archive encryption is enabled, the signed document download service returns log records encrypted.
Message grouping can be configured by a member or subsystem. By default, grouping is disabled, and all archive files go to the same default group. Message log archive files that belong to the same group are chained using cryptographic hashes. The implementation is not based on blockchain. However, there may be holes in the chains if grouping is turned on and off or the grouping level (none/member/subsystem) changes. Every time grouping is turned on/off or the grouping level changes, the chains start from zero.
When message log archive encryption is enabled, the archive files are encrypted and signed using the Security Server’s internal key (1) by default. Instead, when archive encryption and grouping are combined, the Security Server administrator must configure one or more member-specific encryption keys (4) for each member. The member-specific keys are used to encrypt the archive files belonging to the member. If the Security Server administrator configures no member-specific key, the Security Server's internal key is used as a fallback.
Also, the format of the message log archives' filenames depends on the configuration of the Security Server. The format varies between encrypted and plain text archives and between different grouping levels. If the archive files are automatically processed based on the file name, the matching rules may have to be adjusted. More information about the filename format is available in the Security Server user guide.
Message log database encryption
Just like the message log archive files, the message log database may contain sensitive information. Starting from version 7.0.0, the message body stored in the message log database can be optionally encrypted, but the default is no encryption. The database encryption is fully transparent to all the external interfaces, e.g., the signed document download service. The Security Server administrator is responsible for configuring the database encryption key (3) before enabling database encryption.
In the message log database, there are two separate columns for plaintext ("message") and encrypted ("ciphermessage") message body. The message body is always stored in one of the two columns depending on the configuration. Instead, the other column that is not used is left empty. When message log database encryption is enabled/disabled, the change doesn't affect already existing records in the database. For example, when message log database encryption is enabled, all the records created after the configuration change will be encrypted and stored in the "ciphermessage" column. Instead, all the records stored before the change will remain in plaintext in the "message" column.
Thanks to the way how the message body encryption in the message log database has been implemented, the change doesn't affect any external integrations. For example, suppose message logs are exported directly from the message log database to some centralized logging system. In that case, the integration doesn't need to be changed if the message log database encryption continues to be disabled.
During message log archiving, the message body is decrypted and written to the archive file in plaintext. Message log archive encryption is configured separately, and when it's enabled, the whole archive file is signed and encrypted. In practice, the message log database encryption may be enabled while the message log archive encryption is disabled (or vice versa). However, if the message log contains sensitive information, it's recommended to enable both the message log database encryption and the message log archive encryption.
Future enhancements
The new data protection features introduced in version 7.0.0 will be developed further in the upcoming releases. For example, one of the potential enhancements is to provide information on the statutes of different encryption configuration options in the Security Server UI to detect the current state and possible configuration errors. Also, making various encryption-related configuration options available through the Security Server UI and REST management API is part of the future development plans.
We’re glad to receive feedback about the new features and contributions regarding further enhancements.