Encryption Protocol

GlobaLeaks implements an encryption protocol specifically designed for anonymous whistleblowing applications.

The protocol has been developed and validated in collaboration with the Open Technology Fund and represents a tradeoff between security and usability intended to provide easy use by whistleblowers and reasonable security from attackers seizing the backend and attempting bruteforce decryption.

Encryption is implemented for each submission protecting questionnaire’s answers, comments, attachments and involved metadata. The keys involved in the encryption are per-user and per-report and this guarantees that only whistleblowers and their recipients could access the reports. Such an implementation implies that in case users forget their password, they would lose any possibility of access to the data contained in their accounts.

In order to enable users to be able to recover their own account in case of loss of their password, the system implements an Key Recovery mechanism and make available to every user an Account Recovery Key. This measure ensure that users in possession of their own Account Recovery Key could always restore their own access to their own account and the data contained therein.

In order to protect the system from data loss in case of users’ loss of both the password and the account recovery key, the system could be configured enabling a Key Escrow mechanism and delegating to administrators the role and responsibility to support users recovering access to their own accounts and the data contained therein. Such a capability has the value to add resiliency to the project protecting from any data loss in case of users’ death or in condition of conflict of interest inside the recipient team. The same capability has the drawback that users with access to escrow keys could possibily access others users accounts and the data contained therein. Project owners are invited to wisely choose if enabling this feature depending on the project’s threat model and to document the choice on the project’s privacy policies.

Encryption’s Workflow

Users chooses a personal secure password at first login done using an account activation link;
The system creates a personal user asymmetrical keypair and stores the private key symmetrically encrypted with a secret derived from the personal user password;
The private key of each user is protected with the Key Recovery mechanism and if enabled with the Key Escrow mechanism;
The whistleblower files a report;
The system assigns personal numeric 16-digits receipt for the whistleblower;
The system generates an asymmetrical keypair for the whistleblower and stores the private key symmetrically encrypted with a secret derived from the receipt of the whistleblower;
The system generates an asymmetrical keypair for the encryption of the report, the attached files, the comments and the involved metadata and stores a copy of the private key encrypted for each involved user by using their own public key;
The system encrypts the report, the attached files, the comments and the metadata with the public key generated for the report;
The system grants every involved user access to their reports and enable them to communicate by automatically locking and unlocking involved keys when a report is accessed or new communication is performed.

Encryption’s Details

Algorithms

Type	Implementation
Asymmetric encryption	Libsodium SealedBoxes, an encryption implementation that combines Curve25519, XSalsa20 and Poly1305 alghoritms.
Symmetric encryption	Libsodium SecretBoxes, an encryption implementation that combines XSalsa20 and Poly1305.

Users’ Credentials

The system used two different type of credentials depending on the user role:

Credentials type	User role
Passwords	Passwords are used for authenticating users identified by a username
Receipts	Receipts are 16-digits random secrets used for authenticating anonymous whistleblowers

Assumptions:

The system enforces strong password complexity;
The system enforces expiration of receipts according to a strict data retention policy limiting the concurrent number of active receipts;

Users’ Keys

Type	Generation	Storage
ECC Curve25519 keypair	Generated by the backend at first user login for authenticated users and on submission for whistleblowers	Keys are stored on the backend encrypted using symmetric encryption. The symmetric key used for encrypting users’ keys is derived from the users’ credentials using the KDF function Argon2ID. The parameters for Argon2ID used for KDF are chosen stronger than the parameters one used for authentication of related user which the hash is stored. The parameters are chosen to require 128MB per Login and 1 second of computation.

Data Encryption’s Keys

Type	Generation	Storage
256 bit keys	Generated by the backend for each report	Keys and stored on backend filesystem encrypted using asymmetric encryption by means of Users’ and Whistleblower’s keys respectively

Key Generation

Users’ encryption keys are automatically generated during the first user login and secured by means of the user passphrase used for login. This simple but effective key generation policy requires users to perform their first login before being enabled to receive reports.

Key Recovery

The system implements a key recovery system by means of a recovery key and symmetric encryption.

Upon generation of a user key, the private key is symmetrically encrypted with a randomly generated recovery key.

For usability reasons, this recovery is kept as well encrypted on the backend making it possible for logged users in possession of their password to retrieve and print their own account recovery key.

Key Escrow

The system implements an optional key escrow mechanism in order to limit data loss in case of users’ password loss.

Key escrow can be enabled during the initial application wizard or alternatively could be enabled in the advanced settings of the software.

We advise enabling this option if you would like to protect whistleblowers’ submissions from being lost in the situation where recipients lose their passwords. On the other hand, we would not advise using this feature if you want to setup a system where only recipients are able to access submissions.

When the option is enabled the system will generate and assign an escrow key and assign it to the administrator that has enabled the feature; the key will be furtherly used by the system to encrypt every system key preserving a copy that could be unlocked by any administrator in the availability of the escrow key.

Administrators with access to the escrow key will be able to support any internal user in case of password loss and issue password reset. As well they will be able to grant this same privilege to other administrators or disable the feature completely.