Encryption Whitepaper

Encryption is primarily used to safeguard the contents of a message so that only the intended recipient could read it. This was done by replacing the contents with unrecognizable data, which could be understood only by the intended recipient. This is how encryption became a method to protect data from those who might want to steal it.

Encryption is when you change data with a special encoding process so that the data becomes unrecognizable (encrypted). You can then apply a special decoding process and you will get the original data back (decrypted). By keeping the decoding process a secret, nobody else can recover the original data from the encrypted data.

The encoding process follows an encryption algorithm like AES 256 which is public. However, the process itself depends on the key, which is used to encrypt the data and decryption it to retrieve the original data.

The key is kept secret. Without the key, anyone who might succeed in accessing the data will only see a "Ciphertext", which will have no real meaning. Hence, the data is protected.

Why we encrypt your data

The final layer of protection- Though a comprehensive security strategy helps a company protect data from hackers, encryption takes the final stand against attempts to steal your data. It brings data protection to completion as it ensures your data can neither be damaged nor be stolen in the unfortunate event of a security breach.

Privacy- Encryption is a reassurance to privacy concerns surrounding the internet. Encryption helps protect privacy by turning personal information into “for your eyes only” data intended only for the parties that need them. When you interact with us and store your data in our servers, encryption helps us ensure you have absolute privacy.

What we mean by 'data'

There are two types of data that we deal with-

In the subsequent sections, 'data' refers to the data that is encrypted.

When you use Vani, your data travels over the internet from your browser to our data center or other third parties (while using third-party integrations). Encrypting data in transit protects your data from man-in-the-middle-attacks.

There are two scenarios when data in transit is encrypted:

Between you and Vani

Vani has established strict policies to adapt the Transport Layer Security (TLS) to all its connections. TLS ensures a secure connection between you and Vani Servers by allowing the authentication of both parties involved in the connection, and by encryption of data to be transferred. TLS protocol makes sure that no third parties may eavesdrop or tamper with communication between you and Vani..

We follow the latest TLS protocol version 1.2/1.3 and use certificates issued by SHA 256 and ciphers (AES_CBC/AES_GCM 256 bit/128 bit keys for encryption, SHA2 for message authentication and ECDHE_RSA as the key exchange mechanism). We also implement perfect forward secrecy and enforce HTTPS Strict Transport Security (HSTS) across all sites.

Between Vani and third parties

We follow the https protocol during our communication with third parties. For transactions that involve sensitive data and use cases, we use asymmetric encryption, which utilizes a system of public and private keys to encrypt and decrypt data.

For this method, we generate a pair of public and private keys in our KMS (Key Management Service), which creates, stores and manages keys across all services. We encrypt these pairs using a master key and the encrypted key pairs are stored in the KMS itself. The master key is stored in a separate server.

We make public keys available to third parties through the certificates while we store the private key in KMS, and after authentication, the encrypted data is decrypted in the KMS.

Any Vani(or application) that you use involves data: the data you provide and the data we store on your behalf as part of the service. The data may be received as a file or as data fields. Each of these categories is treated differently with respect to how it is encrypted.

This section deals with encryption at rest at the application-level.

DB Encryption

The sensitive data you input into the application, or the service data, is stored in our database as tables. Data in these tables are encrypted according to AES 256 standard with AES/CBC/PKCS5Padding mode. The data that is encrypted at rest varies with the services you opt for. Learn more about the data we encrypt in our service. However, depending on the sensitivity of the data field and the user's choice and requirement, the level of encryption varies.

There are two levels of DB encryption-

Note: Henceforth, we will be referring to a customer or an organisation that uses a Vani, and has a finite number of users as an 'Org'.

File or DFS encryption

The files you create or attach are saved into our Distributed File System (DFS). The files that are encrypted at rest varies with the services you opt for. Learn more about the data we encrypt in our service.

The encryption is based on the standard AES 256 algorithm, and the mode of encryption is either CTR or GCM. In AES 256, the plaintext that needs to be encrypted is divided into packets of data or blocks. Since we are encrypting the contents of files here, the algorithm should ensure that each block's encryption is independent of another, so that the attacker does not get any information about the file even if the block ciphers are compromised. For this requirement, the CTR mode is ideal.

Like in DB encryption, file encryption also has two levels:

Level 1- In this level, each Org is provided with a key. Each file from that Org is encrypted using this key, but with a unique random IV which is stored along with the file itself. This key is again encrypted using a master key and stored in the KMS.

Level 2- In this level, each file is provided with a unique key and is encrypted using that key. Each key used to encrypt a file is encrypted again using a master key, and the encrypted key is stored along with the file in the DFS. This master key is unique for the service or application, and is stored and managed in the KMS.

URL encryption

The invitation links or any other communication between us may involve sensitive data being passed in the URLs. To secure this communication, parts of a URL is encrypted. If there's anything that is identifiable in the URL, say the ID of a document, that part is encrypted.

This encryption has two levels- One key per Org or One key per URL. Again, this is decided by the sensitivity of data in the URL.

Backup encryption

We create backups based on two schedules: daily and weekly. The backup servers are equipped with the same level of protection as the main servers. All data we take as backup will be encrypted at rest. We use AES 256 algorithm for encryption and we store the keys in a separate server. We also have redundant Data Centers (DC) that ensure high availability. These DCs also have a copy of your encrypted data, and they are also backed up like the main DC.

Encryption of Logs

Vani Logs uses Hadoop Distributed File System (HDFS) to store and manage logs. We use the encryption technology of Hadoop Inc to encrypt the data while key management is handled by our KMS.

Encryption of cache

We use Redis open source software for storing and managing cache data. Cache contains data that is repeatedly used in the operation of the service, and need to be stored for a certain amount of time. Sometimes, your data may be cached to improve the service or for troubleshooting. If any data contains sensitive personal information, we choose to encrypt it.

Our in-house Key Management Service (KMS) creates, stores and manages keys across all services. We own and maintain the keys using KMS. Currently, we do not have the provision to encrypt data with keys owned by the customer.

There are different types of keys used at different stages of encryption:

Data Encryption Key(DEK): The key used to convert the data from plain text to cipher text, or the key used to encrypt the data.

Key Encryption Key (KEK): The key used to encrypt the DEK, and is service-specific. It provides an extra layer of security.

Master Key: The key used to encrypt the KEK. This key is stored in an isolated server for safety.

How does the KMS work ?

All types of encryption are according to the AES 256 algorithm. According to this algorithm, the data is treated as 'blocks' which are to be encrypted. Irrespective of whether it is a field in the database or a file in the DFS, encryption begins when a block of data is encrypted using a DEK.

This DEK is further encrypted with a KEK. The KEK is again encrypted using a master key that is stored in a separate server. So, here are the elements that need to be managed-

The KMS manages these elements in the following manner:

How are the keys generated?

KMS generates 256-bit keys that conform to the AES 256 protocol, along with an Initialisation Vector (IV). IV, as we have already discussed, ensures that the first block of encrypted data is random. This is why the same plaintext is encrypted into different ciphertexts with the help of the IVs.

KMS generates these keys and IV using a Java secure library and a secure random number generator.

Where are the keys stored?

The DEKs generated in the KMS are encrypted using a KEK. This provides an additional layer of security. The encrypted DEKs are stored in the KMS database.

We separate the keys physically (store them in different locations) so that an attacker who gets hold of one key cannot get hold of other related keys as well. We encrypt the KEK using a master key and store it in a separate server.

An attacker will not be able to compromise the data by merely targeting the KMS alone.

How secure are the keys?

Physical separation- As discussed earlier, the master key remains in a physically separate and secure server. This makes it difficult for an attacker to compromise both DEKs and KEKs.

Access control- Access control helps us prevent the misuse and unprecedented access of keys. An Access Control List (ACL) allows only selected services to access selected keys. Every time a key is accessed, it is through authentication and the process is logged. Regular audits of these logs help monitor the process.

Access to Key Management Servers is restricted, by default, and allowed only to specific personnel of Zohocorp. Any other access is raised as a ticket and allowed only after the approval of management.

Key Rotation- We use a key rotation system where we change the Root Master key periodically, which ensures additional security. When a new master key and IV are generated, it means that the keys in the database must also be revised. Hence, all the keys in the database are first fetched and decrypted using the old master key and re-encrypted using the new master key and updated in the database.

Provision to manually trigger the rotation of keys is available, to handle critical situations that may arise.

Availability of Keys- If the primary storage of disks in one Data Center (DC) should fail, there is a slave and a secondary slave for backup, that hold the same data as the master DC. Both the slave and the secondary slave have the DEKs encrypted, same as the master.

The following describes data encrypted by Vani

We encrypt all the project data stored in Vani, as well as personally identifiable information like email addresses and IP addresses. We also encrypt all files uploaded to Vani. This includes images, audio files, video files.