Revoke’s Security Policy

V0.3 Last Updated: 12/03/2020

1 Security Policy

This security policy relates to the Revoke service (the “Service”) operated by Revoke Limited (“Revoke”, “us”, “we”, or “our”). Revoke Limited is a company registered with the Jersey Financial Services Commission, Registration Number 124314.

At Revoke, we care deeply about privacy and security.

This policy outlines the steps we have taken to ensure that any data we store or transmit is secure and protected appropriately.

We use advanced levels of encryption of data at rest and in transit at the message and transport layer including use of the following;

• Elliptic Curve cryptography using Ed25519 and Curve25519 Keys
• Authenticated encryption with associated data (AEAD)
• Diffie-Hellman key agreement
• Sealed Boxes
• DNSSEC
• HTTPS
• IPSec
• AES256 Encryption
• X509 Certificates
• BlakeB Hashing

2 Personal Data

We treat personal data very carefully.

We ensure that all data is encrypted, when it is on your device, when it is being transmitted, and when it is stored with Revoke.

2.1 Mobile Application

Each user has a unique Private Key on their phone for decryption. This Private Key is derived by a random number generation process. A corresponding Public Key is used for encryption. These keys are known as a Key Pair.

To ensure the Key Pair is completely random and impossible to re-generate, the user is required to perform non-predictable, non-reproducible actions.

The actions are device and application permission dependant but include one or more of:

• Microphone sound input
• Video camera input
• Random screen interaction (drag, swipe, tap)
• Accelerometer readings.

2.1.1     Data Encryption at Rest

All data on a user’s device is encrypted using AES256 encryption with a randomly generated password. The password for each item of data is encrypted using a suitable Public Key.

Data is decrypted using a Private Key, accessed with a user-defined PIN.

2.1.2     Data Encryption in Transit

Information sent to and from third parties containing restricted or sensitive personal data is protected and secured by cryptographic certificates.

Certificates are based on the X509 standard but utilising a json format to allow extended attributes not supported in the native x509 certificate format.

In addition to encryption at the message layer, HTTPS is used to encrypt the transport layer between all services.

3 Company API and Customer Matching

Revoke provides an API for companies to query and match customer records, in order to automate responding to requests.

It is essential that no personal data is divulged as part of this process, and that company customer data is protected.

3.1 Customer Matching

All the data sent by the company to Revoke is masked and anonymised using cryptographic operations to provide a secure data store without compromising the personal data of the customer or the commercially sensitive data company.

A customer record from a client company consist of two primary elements:

Unique customer reference

Each company record requires a unique reference that has relevance in the client company customer database. This is to provide a mechanism to link a Revoke record or data protection request with an actual customer.

In order to protect the customer reference field, the company encrypts the data incorporating its Private Key_Curve25519 using secret box encryption.

3.1.1     Matching criteria fields.

The customer record contains one or more matching fields. A criteria field is a unique piece of information connected with the end customer. This can be for items such as “email address”, “first name”, “last name”, “postcode” etc. The company can supply any number of matching fields based on the size and type of customer data contained within their systems.

Prior to transmission, matching field data is protected by two rounds of BlakeB hashing. This ensures that any sensitive commercial or personal information is completely protected against any misuse by a third party. The Revoke data protected mechanism offers three fundamental levels of security:

• There is no practical method to reverse the hashing process and retrieve any customer data sent via the Revoke API.
• As the encoding process happens prior to data transmission, Revoke have no visibility of the data sent and is only concerned with the matching of specific requests by users to a relevant company.
• As the hashed data is mixed with the company public key the resulting output is unique between a given customer and company relationship. The same user information (such as email address, telephone number) will have wildly different resulting match values for different source companies. This prevents leaking the privacy of a given user’s interaction between multiple different company entities.

Matching Field Algorithm

In order to suitably protect the sensitive data sent by the company to Revoke, the following algorithm is implemented:

• A BlakeB hash engine is created and seeded with the 32-byte Revoke public key _Ed25519 obtained via one of the key distribution methods.
• An individual piece of match data is processed by the BlakeB hash engine resulting in a 32-byte output.
  Note: For consistency and match accuracy, all match data should be translated into upper case prior to processing.
• The company’s private Key_Curve25519 and the Revoke public Key_Curve25519 are combined using a Diffie-Hellman key agreement function to generate a 32-byte shared secret.

Note: For added security, the raw secret key agreement value should be protected by utilising a key derivation function (KDF) such as a HMAC or hash.

• The computed shared secret is used to seed a second BlakeB hash engine.
• The output of the first hash process in step 2 is processed by the second BlakeB hash engine resulting in a final 32-byte output value. This value is the data that the company will send through to Revoke in order to process any match requests.

Notes:

• The shared secret output calculated as part of the Diffe-Hellman Key Agreement process (step 3) is a constant and can be safely reused in a batch process if the company and Revoke keys remain unchanged.

The above process has the following advantages:

• The process can be recreated on the Revoke server allowing pre-computation of results for a given company to improve response performance.
• As the hash uses elements of the company’s private key, a dishonest company can-not send investigative requests to see if an email address has been registered to a third-party company.

Users send the same matching information to Revoke utilising a similar approach. The notable difference is that the process is split into two parts with the user’s device performing the initial hash with the Revoke public key.

The Revoke services then use the data sent from the user’s device to pre-compute a hash table containing the relevant data for the onboarded companies. This process uses the Revoke private key and the specific company public key to generate the same shared secret used by the company.

The Revoke system will take all new masked data submitted by users and construct a suitable reference system to enable searching in a timely manner. The system will in effect pre-calculate all the potential match results for the customer and company userbase held in an efficient and secure data storage.

3.2 Company API Transport

Request is made via a HTTPS/SSL communication using a simple REST/SOAP call.

Each request sent to the Company API contains:

• Headers
  • Company Public key
    The public key of the sending company is added as a request header.
  • The sending company uses their secret key to sign the contents of the request payload.
• Payload
  All request payloads include a UTC date time stamp to millisecond precision as part of the signed content. Any request received outside a server defined time window will be ignored.

Payload requests are encrypted using secret box encryption as this removes the need for the company to track and maintain a unique number used once value.