Last Updated on: 17th December 2024
Overview
Here's what we will discuss in this whitepaper
What is Encryption?
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 key secret, no one 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, as well as to decrypt it.
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 ensuring no one, except the intended parties, can understand what is being communicated. When you interact with us and store your data in our servers, encryption helps us ensure your privacy.
What we mean by 'data'
There are two types of data that we deal with-
- Customer data- The data you store with us through Zoho services. Typically, this data is handled by a Zoho service through a customer's account that can be identified in our IAM (Identity and Access Management) database. Sensitive data are those that can cause harm to related individuals or organisations when exposed. Depending on the sensitivity of data and the user's requirements in the respective Zoho service, some customer data are encrypted while some are not.
- Derived data- The data which is not directly given by you, but is derived from your data. For example, auth tokens, unique IDs, URLs and reports etc.. are stored with us. Depending on the sensitivity of data, some derived data are encrypted while others are not.
In the subsequent sections, 'data' refers to the data that is encrypted.
Encryption In Transit
When you use Zoho services, your data travels over the internet from your browser to our data center, or to 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:
- When data travels from your browser to our Servers.
- When data travels from our server to non-Zoho servers (third parties)
Between you and Zoho
Zoho has established strict policies to adapt the Transport Layer Security (TLS) to all its connections. TLS ensures a secure connection between you and Zoho 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 Zoho..
We follow the latest TLS protocol version 1.2/1.3 and use certificates generated using 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 Zoho 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.
Encryption at Rest
There are two major levels of encryption-
- Application layer encryption
- Hardware based full disk encryption
The strategy to encrypt data at the application level depends on where and how the data is stored-
- Database (DB) - stored as tables
- Distributed File System (DFS) - stored as files
- URL encryption
- Backup
- Logs
- Cache
The below image paints a broad picture of our encryption strategy:
Application level encryption
Any Zoho service(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.
Field Level Encryption
The sensitive data you input into the application, or the sensitive service data, is stored in respective Zoho service database. Data in these 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 services.
The encryption happens at application layer and only the authorized application user will be able to view the data. Since data encryption at rest is done at application layer, any normal database or support user will not be able to view the data without the access of encryption keys from KMS. Only encrypted data is visible when viewed directly in normal database tools like SQL.
The type of encryption varies depending on the sensitivity of the data field, and the user's choice and requirement.
There are two types of field level encryption-
- Depending on the sensitivity of data
- Depending on the search functionality
Note: Henceforth, we will be referring to a customer or an organisation that uses a Zoho service, and has a finite number of users as an 'Org'.
Depending on the sensitivity of data
Type 1- This is the default type of encryption that we do for data from all Orgs. In this type, our KMS allots a key to each org. Data corresponding to that org will be encrypted using this key. The key is encrypted using a master key and the encrypted key is stored in a separate server.
Type 2- We do this type of encryption for sensitive and Personally Identifiable Information (PII). This category includes fields like Bank account numbers, Identification numbers and biometric data.
In this type, the KMS generates a unique key to each column in the table. All data in a particular column will be encrypted using the key generated for that column. These keys are again encrypted using a master key and stored in a separate server.
Depending on the search functionality
Search functionality over encrypted data depends on the Initialisation Vector (IV) used during encryption. An IV is a random value that initiates the process of encryption. This random value ensures that each block/unit of data encrypts differently. It also means that encrypting the same data twice yields different ciphertexts.
Why is the IV important?
If you had no IV, and used the Cipher Block Chaining (CBC) mode with just your key, two data sets that begin with identical data will produce identical first blocks. IVs make it unlikely that the encryption of two distinct data will ever create the same input/output pairs (at the block cipher level, and using the same key), even when one bears some relation to the other (including but far from limited to: starting with the same first block).
When each encryption request enables the usage of a random IV, the first block would be different. The attacker cannot deduce anything that may help them decode the encrypted data.
Equality Preserving Encryption: In this type, only one IV corresponds to a key. This means, the whole block of ciphertext can be used in a search query. Since the IV is the same for all data for the Org/Column, a search will fetch you the data.
Standard Encryption: In this type, each data entry has a unique IV. Even if you encrypt the entire data with one key, each encrypted data entry will produce a unique ciphertext. Also, since the IV is random and unique for each data, a search query will not fetch you the data. This is a safer option than the "Equality Preserving" variation.
In what situations will these variations be used?
The decision to go for a particular variation usually depends on the requirement. If data must receive the highest standard of protection, we go for Type-2, with standard encryption.
However, it is not always about protection alone. Sometimes, users might want to search and fetch a field such as 'email ID' to suit their requirements. In that case, the standard option would not make sense, and we go for Type-1, with "Equality Preserving" encryption.
File 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 services. The encryption happens at application layer and only the authorized application user will be able to view the data.
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.
The Galois/Counter Mode (GCM) is a typical block cipher mode of operation, using a block cipher algorithm. While CTR provides only encryption, GCM provides encryption along with authentication.
If the encrypted file is corrupted, a junk value will be returned during decryption of the file in CTR mode. On the other hand, in GCM mode, we have an authentication tag which verifies the authenticity of the encrypted file and only then decrypts the data. The GCM mode provides an added layer of integrity to the file.
Like in field level encryption, file encryption also has two types:
Type 1- In this type, 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 the key is stored in the KMS.
Type 2- In this type, 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 KEK, and the encrypted key is stored in the Zoho service database while the file is stored in the DFS. This KEK is unique for each org, and is stored and managed by the KMS.
URL encryption
The invitation links or any other communication within Zoho services 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 types- One key per Org or One key per feature. Again, this is decided by the sensitivity of data in the URL.
Backup encryption
We backup data frequently, and our backup servers are equipped with the same standard of protection as the main servers. All data we take as backup will be encrypted at rest.
Encryption of Logs
Zoho Logs uses Hadoop Distributed File System (HDFS) to store and manage logs. We use the encryption technology of Hadoop 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.
Key Management
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.
Note: We are working on a new feature to support Bring Your Own Key (BYOK) by which you can provide your own encryption keys from an external key manager of your choice.
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 Zoho service-specific. The KEK is generated in a separate server. 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-
- Encrypted data
- DEKs
- Encrypted DEKs
- KEKs
- Encrypted KEKs
- Master key
The KMS manages these elements in the following manner:
Initiate Requests
User authenticated to zoho service and requests data
Encryption in transit
TLS-based encryption
Application Front End
Directs traffic to application servers
Application Server
Initiates encryption process
Key Management Service
Generates/Retrieves Data Encryption Key (DEK)
Master Server
Generates/Retrieves Key Encryption (KEK)
KMS Database
Stores encrypted DEK
Key Management Service
Returns DEK for encryption
Encrypt Agent
Encrypts data using DEK
Storage
Stores encrypted data
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 the Java Security library and the SecureRandom 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.
For Zoho Workdrive, we provide an added layer of security for the documents stored at rest.
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 misuse and unprecedented access of the keys. An Access Control List (ACL) allows only select services to access select keys. Every time a key is accessed, it is authenticated, and the process is logged. These logs are monitored through regular audits.
Access to KMS 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 have a key rotation system where the Master key is changed, 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.
The key rotation is currently triggered only in case of any compromise of the key in the KMS.
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 keys encrypted, same as the master.
What data we encrypt in our services?
The data that is encrypted at rest varies with the Zoho services you opt for. The type of encryption for a particular data entry is decided by either you or us, or the consensus of both.
The following tabular column describes data encrypted by various Zoho services:
| Service | Encrypted Fields |
|---|---|
| CRM | Custom fields marked as encrypted, all files and all mail content sent and received via CRM. For more details, refer link. |
| Workdrive | All files. For more details, refer link. |
| Creator | Fields which are marked for encryption and files(File uploads, Signatures, Audio, Video, Image fields) uploaded by users. For more details, refer link. |
| Campaigns | Custom fields marked as encrypted, user uploaded files. For more details, refer to link. |
| Cliq | ChatTranscript and personal information. For more details, refer link. |
| People | Custom fields will be encrypted if encryption is enabled by the customer for a particular field. All uploaded files will be encrypted. For more details, refer link. |
| Connect | Title, URL and contents of - feed, forum posts, articles, townhalls, groups, announcements, tasks and their comments, video files and attachments. For more details, refer link. |
| Desk | Ticket thread content, attachments, custom fields marked as encrypted and tokens. For more details, refer link. |
| Finance | Bank account details, custom fields that are marked as encrypted, employee details which contain sensitive personal information, travel documents, bank statements and attachments. |
| Projects | Attachments, fields that contain personal information, tokens. For more details, refer link. | Sprints | Files, attachments, tokens and fields that contain personal information. For more details, refer link. |
| Notebook | Notecard and Attachments. For more details, refer link. |
| Sign | Documents, signature images and tokens. For more details, refer link. |
| Analytics | Fields that are marked as personal data and Import and Export credentials. For more details, refer link. |
| All mail content, attachments and fields that contain personal information | |
| Recruit | Custom fields marked as encrypted and user-imported documents. For more details, refer link. |
| Social | Tokens, fields that contain personal information. For more details, refer link. |
| Service Desk Plus Cloud | Tokens, password fields (present in email account, assets, SNMP, etc) and custom fields that are marked as encrypted. For more details, refer link. |
| SalesIQ | File attachments, tokens, media recordings and chat transcripts. For more details, refer link. |
| Assist | Screenshots and session recordings. For more details, refer link. |
| Survey | Custom fields marked as encrypted, files uploaded by respondents and email addresses provided in share feature. For more details, refer link. |
| Show | Presentations, uploaded files and personal information. For more details, refer link. |
| Directory | Custom fields the user has chosen to encrypt. For more details, refer link. |
| Contracts | Contract Documents, Contract Letters, Negotiation Links' Passwords, Organization & Counterparty Contacts' Phone Number. For more details, refer link. |
| Learn | Contents of articles, lessons, attachments, templates and personal information. For more details, refer link. |
| Site24x7 | Mobile number, Email address, Hostname, IP address, URL, Access token, Domain name, Credentials provided by the user, Service Account configurations, NCM configuration backups and files uploaded by the user. For more details, refer link. |
| Dataprep | All of user's data imported into Zoho DataPrep including PII (Personally Identifiable Information), ePHI (Electronically Protected Health Data), and credentials. For more details, refer link. |
| Zoho Forms | Attachments, fields that are marked as encrypted and tokens. For more details, refer link. |
Full-disk encryption
We employ self-encrypting drives(SEDs) to support hardware-based full disk encryption. An SED is a hard disk drive (HDD) or a solid state drive (SSD) that has an encryption circuit built into it.
Self encryption simply means that all the data written to the storage medium is encrypted by the disk drive before being written, and is decrypted by the disk drive when it is read.
The data written on the drive is encrypted/decrypted using a Data Encryption Key (DEK), which is stored on the disk. The default DEK that is provided by the manufacturer is regenerated by us at the time of set up to maintain our standards of security.
To enhance the security of SEDs even further, we use authentication keys. An authentication key (AK) is used to encrypt the DEK and to lock/unlock the drive. AKs are managed using a local key management system (LKMS).
The AK is transferred to the servers securely when encryption is enabled in the server. In case of theft or unauthorised physical access to the disk, the DEK cannot be decrypted without the AK, and thus the data on the drive cannot be accessed or read. In this way, the AK adds an extra layer of protection.
Currently, hardware-based full-disk encryption is applicable by default for all Zoho services in India (IN), Australia (AU) and Japan(JP) data centers. In other DCs, full-disk encryption is available only for certain Zoho services. For further details, refer to the corresponding service-specific encryption help document.
Conclusion
We encrypt sensitive customer data when it is stored, when it is in transit over the internet and when it is traveling between our DCs. However, encryption is only a part of our Security strategy. We constantly innovate and strive to enhance data protection by implementing the latest protocols and technology. To learn about our complete security strategy, please visit https://www.zoho.com/security.html