This security policy relates to the Rvoke service (the “Service”) operated by Atam ID Technologies Limited (“Rvoke”, “us”, “we”, or “our”). Rvoke is a trading name of Atam ID Technologies Ltd. (“Atam”), a company registered with the Jersey Financial Services Commission, Registration Number 124314.
At Rvoke, 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
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 Rvoke.
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)
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
Rvoke 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 Rvoke 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 Rvoke 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 KeyCurve25519 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 Rvoke 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 Rvoke API.
As the encoding process happens prior to data transmission, Rvoke 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 Rvoke, the following algorithm is implemented:
A BlakeB hash engine is created and seeded with the 32-byte Rvoke 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 KeyCurve25519 and the Rvoke public KeyCurve25519 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 Rvoke in order to process any match requests.
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 Rvoke keys remain unchanged.
The above process has the following advantages:
The process can be recreated on the Rvoke 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 Rvoke 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 Rvoke public key.
The Rvoke 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 Rvoke private key and the specific company public key to generate the same shared secret used by the company.
The Rvoke 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:
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.
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.
Download Rvoke Today
Start protecting yourself with Rvoke, and take back control of your personal data.