Platform Privacy and Security Technical Brief

The Platform, currently on its second iteration (rolled out in June 2023), uses various cryptographic algorithms and functions to transmit and store information in a secure way, with the ultimate goal of ensuring that the information it holds cannot ever be deciphered by prying eyes. This means that, should the database ever be compromised, the information contained therein would remain safe.

The sections below detail how the Platform secures datasets and the data-points therein.

This section applies to the initial version of the Platform, as well as the subsequent version rolled out in June 2023.

All personal information captured by a user of the Platform when casting a vote in a referendum is encrypted using AES-256, which refers to the Advanced Encryption Standard (AES) with a key size of 256 bits. AES (Rijndael) is an industry-standard symmetric encryption block-cipher algorithm that is widely used for securing sensitive data. It was selected by the United States National Institute of Standards and Technology (NIST) in 2001 as the successor to the Data Encryption Standard (DES), which was broken in 1999. The strength of AES-256 lies in its resistance to various cryptographic attacks, including brute force attacks and known plaintext attacks. It has undergone rigorous evaluation and testing for vulnerabilities and has stood up to a wide range of cryptographic attacks. To date (June 2023), the block cipher – which has been extensively analysed and scrutinised by cryptographic experts worldwide – has not been broken and is currently classified as safe to use in government, financial, and military applications.

Encryption is first done on sensitive data-points, i.e., those that contain personal and contact information, and then the entire dataset is encrypted as a whole before being bundled with a one-way hash of the voter’s identification number (more on this below [1]).

Each cycle of encryption is done using a secret encryption key that is not accessible to anyone, except for the platform administrator, who operates the platform in a secure Virtual Private Cloud (VPC) in South Africa, to which no other first party and no third-party has access.

All encrypted data is signed using a Hashed Message Authentication Code (HMAC) to prevent it from being tampered with after having been encrypted and persisted to the database.

[1] When hashing identification numbers, the Platform uses a highly secure cryptographic hash function that produces a large fixed-size hash that cannot be reversed, is protected against preimage attacks, and is resistant to collisions (meaning that there is an extremely low chance of two non-hashed data points producing the same hash). Usage of this mechanism allows the platform to quickly perform identification number lookups when a user is casting a vote to ensure that they do not vote twice in a particular referendum. It relies on the user’s input to do this lookup, as the input itself is hashed in the exact same manner that all persisted input is hashed. A comparison function is then used to do the lookup, which returns an indication as to the pre-existence of the input.

This section applies to the June 2023 version of the Platform.

The June 2023 rollout introduced User Accounts to the Platform. User Accounts allow voters to further-secure their personal information by only allowing them, and nobody else, to use it when casting votes in a referendum. As part of this, it is required that personal information is stored separately from votes, as a method to prefill the required fields of a vote record.

All User Accounts are protected with a password of the voter’s choosing, and this password is persisted using a highly secure, pseudorandom hash (more on this below [2]). The Platform requires that all passwords meet a minimum set of requirements to ensure strong account security. When choosing a password, users must provide at least eight (8) characters consisting of at least one (1) number, at least one (1) lowercase letter, at least one (1) uppercase letter, and at least one (1) special character (symbol). Users may not choose passwords that have been leaked as part of a data-breach on another website or system. The Platform securely and anonymously makes use of the haveibeenpwned.com/passwords service to determine if a password is not safe for use.

Personal information stored against an account is not encrypted using the same algorithm used for vote data encryption, briefed in the previous section. Due to the nature of user accounts, and how they additionally need to be looked up in order to prevent data collisions between two or more accounts, data points are individually encrypted using the XChaCha20 stream cipher, which is a symmetric encryption algorithm that is known for its simplicity, high performance, and strong resistance to various cryptographic attacks. Unlike AES-256, it operates on 512-bit state, a key, and a 192-bit nonce, producing a stream of pseudorandom data that can be used for encryption and other cryptographic purposes. Encrypted ciphertext authentication is done using BLAKE2b-MAC, which is resilient to key-substitution attacks.

This encryption is performed using a completely separate secret encryption key that, like the key used to encrypt vote data, cannot be accessed by the outside world.

Coupled with this form of encryption, the Platform makes use of blind indexes that help it satisfy the need to perform data the lookups described above. These blind indexes use multiple filter strategies to allow for quick cipher-text search with minimal data leakage (at worst). Each blind index uses its own key, distinct from both the primary encryption key and from every other index encryption key. This allows the Platform to securely encrypt and hash all personal data, while still allowing it to be searchable by the Platform without storing it in plain text.

Unlike vote data encryption, the Platform does not encrypt each data-point individually and then as a bundle, as this would prevent the Platform from functioning as described (searchability). Instead, each data-point is encrypted on its own and stored separately. Blind indexes are not stored alongside the data they index.

When a User Account has an active session (Authenticated User), it is able to decrypt data that belongs to it. For example, an Authenticated User can access their User Account information by navigating to the “My Account” page (the Page) on the Site. When serving the Page, the Platform securely decrypts the information held by the User Account and presents it to the Authenticated User. This information includes all basic User Account information, such as the Authenticated User’s name, email address, contact number, and identification number (which is initially partially masked, but can be revealed by clicking on the “eye” icon on the Page, which initiates a secure, signed request to the Platform). Additionally, event information about previous votes cast by the Authenticated User is decrypted and displayed on the Page, along with the creation timestamp of the sole audit record and the User Agent that was persisted on the same audit record (see the next section pertaining to audit records and how they work).

[2] When hashing User Account passwords, the Platform uses a highly secure cryptographic hash algorithm that produces a large fixed-size hash that cannot be reversed. The size of the hash is determined during the initialization step of the algorithm, which takes the user’s password as input and generates an initial state, including a pseudo-randomly generated salt and other parameters, such as the memory size, number of iterations, and parallelism degree. The hash is computed, finalised, and then persisted in a manner that prevents pre-computed tables, such as rainbow tables, from being effective in an attack (that is, if the database were ever to be compromised).

This section applies to all versions of the Platform.

In order to prevent the unauthorized manipulation of any data-point, the Platform employs the use of an automated audit-trail, which is designed to record the state of every auditable data-point at the time of persisting it to the database and sign it using a one-way cryptographic hash (as described in the previous sections). This auditing system records every data-point as part of every vote cast, as well as every data-point that forms part of a user account.

Each audit record, stored in a central and private ledger, contains information about the field names that were created, updated, or cleared, as well as information about the data-point that was created, updated, or cleared during a persistence transaction (i.e., writing data to the database). The audit records are stored verbatim, after encryption is performed on the applicable data-points and after those data-points are persisted to the database.

Vote data can only be created, but it can never be changed, cleared, or destroyed. User Account data can be created and changed, subject to some limitations, but can never be cleared or destroyed.

In addition to the data itself, each audit record contains a reference to the IP address and User Agent that was associated with the HTTP request that triggered the creation or change to the applicable data-point.

As a whole, this information is signed, and the signature is stored against the audit record in the ledger. At any point in time, the auditing system can run a data-integrity check on all audit records, using their signatures, to ensure that persistence of the related data-points has been done in an authorized way and that the current state of all data-points can be reached using their audit records. If a record is tarnished, or its current state cannot be reached, then the check for it will fail, at which point the underlying data-point is regarded as null-and-void and should, as a result, be soft-deleted so that it does not form part of the current state of the Platform.

This section applies to all versions of the Platform.

All network traffic between devices on the public internet and the Site’s server (the Server) is encrypted using SSL certificates and the TLS protocol, which is designed to provide secure communication over a computer network. It establishes an encrypted connection between a client (such as a web browser) and a server, ensuring that data transmitted between them remains confidential and cannot be intercepted or tampered with by unauthorized parties.

The Site and Platform uses CloudFlare and Let’s Encrypt to perform full TLS handshakes over two network hops.

On the CloudFlare side, it uses their Full, Strict encryption mode, which requires that all connections from devices via their Domain Name System (DNS) (which we use for the Domain, referendums.co.za) are secure, and that Cloudflare’s connection to the Server is encrypted using an SSL/TLS certificate issued by a trusted Certificate Authority. For the latter, the Server uses Let’s Encrypt, which is a free SSL/TLS certificate provider. For more information about Let’s Encrypt certificates and their Chain of Trust, you can read about it at the link below: letsencrypt.org/certificates.

If either certificate expires, then a connection to the Server and, by extension, the Site, cannot be made. When this happens, CloudFlare will display an error message, indicating that it cannot securely connect to the Server (“host”).