Zoho Whitepaper on Encryption and Security Practices
Overview
Here's what we will discuss in this whitepaper
- What is Encryption?
- Encryption In Transit
- Encryption at Rest
- Application level encryption
- Key Management
- What data we encrypt in our services?
- Full-disk encryption
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 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-
- 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. Depending on the sensitivity of data and the user's requirements, some customer data are encrypted while some are not. Sensitive data are those that can cause harm to related individuals or organisations when exposed.
- 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 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 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 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.
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 services. 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-
- 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
Level 1- This is the default level of encryption that we do for data from all Orgs. In this level, 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.
Level 2- We do this level of encryption for sensitive and Personally Identifiable Information (PII). This category includes fields like Bank account numbers, Identification numbers and biometric data.
In this level, 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
An Initialisation Vector (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: This is the default level of encryption for all tables. In this level, the entire table of data gets one IV. This means, the whole block of ciphertext can be used in a search query inside a table. Since the IV is the same for all data inside the table, a search will fetch you the data.
Standard Encryption: In this level, each data entry has a unique IV. Even if you encrypt the entire table 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 level of protection, we go for Level-2 with the standard encryption. However, if not all the fields need the maximum protection but select ones do, Level-2 protection with the standard version would suffice.
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, a standard option would not make sense, and we go for the "Equality Preserving" variation.
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 services.
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
Zoho 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.
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.
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-
- Encrypted data
- DEKs
- Encrypted DEKs
- KEKs
- Encrypted KEKs
- Master key
The KMS manages these elements in the following manner:
Master Server
Generates/Retrieves Key Encryption (KEK)
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.
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 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.
What data we encrypt in our services?
The data that is encrypted at rest varies with the services you opt for. The options and levels 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, 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. For more details, refer link. |
| Campaigns | Fields that contain personal information, user uploaded files |
| Cliq | ChatTranscript and personal information |
| People | Custom Fields, all files. 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 |
| Desk | Ticket thread content, attachments, custom fields and tokens. For more details, refer link. |
| Finance | Bank account details, custom fields that contain personal information, employee details which contain personal information, travel documents, bank statements, attachments |
| Projects | Attachments, fields that contain personal information, tokens. For more details, refer link. |
| Notebook | Notecard and Attachments |
| Sign | Documents, signature images and tokens. For more details, refer link. |
| Reports | Custom fields, files uploaded by users, custom queries |
| All mail content, attachments and fields that contain personal information | |
| Recruit | Custom fields, user-imported documents |
| Social | Tokens, fields that contain personal information |
| Service Desk Plus Cloud | Tokens, email server passwords and custom fields. For more details, refer link. |
| SalesIQ | Files, attachments, tokens, personal information and chat transcripts. |
Full-disk encryption
We employ self-encrypting drives(SEDs) to support Hardware-based full disk encryption.
SED is a hard disk drive (HDD) or solid state drive (SSD) with an encryption circuit built into the drive. Self encryption simply means that all of the data written to the storage medium is encrypted by the disk drive before being written and decrypted by the disk drive when it is read.
SED drives are FIPS 140-2 compliant or TCG complaint drives. The encryption algorithm configured for the SED’s is AES algorithm. The key used for encrypting and decrypting is of length 256.
There are two types of keys used in SEDs, the data encryption key (DEK) and the authentication key(AK).
Data Encryption Key - This key is used to encrypt / decrypt the data in the drive. This key is generated by a vendor during the manufacturing process. When we get new servers with SED drives, we regenerate the key for security reasons.
Authentication Key - This key will encrypt DEK and used for locking and unlocking the drive. Authentication keys are generated with strong policy and stored in our Key Management System. The same key will be transferred to each server in secure way when we enable encryption in the servers.We are using local key management (LKM ) to manage the authentication key.
Note: Currently, hardware based full-disk encryption is applicable only in India (IN) and Australia (AU) data centers.
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
Related Articles
Zoho Data Security/Encryption/PII
Zoho Applications have a variety of administrative tools for handling sensitive financial, medical or PII data. Per the following Dept. of Homeland Security definitions: PII and Sensitive PII Defined DHS defines personal information as “Personally ...How to work with Data Encryption in ZohoCRM
Zoho CRM now has a powerful data security feature... click below to understand how to work with Data Encryption https://www.zoho.com/crm/help/security/encryption.htmlZoho Privacy, Security Practices, Certifications, Policies, Compliance & Infrastructure
The CRMonCall and Zohelpers organizations always work under terms of non-disclosure, thus we hold any business process information or data you share with our teams as highly proprietary and confidential. In most cases, we will have put a ...Get Ready to Sell on the Go with Zoho Mobile
A mobile CRM is not a downsized version of the desktop CRM. It’s a more specialized and dedicated platform aimed at higher productivity. In the mobile version, you concentrate on what matters most. In this ebook, find out about the useful features ...Security Enhancements in Zoho CRM API Framework
Recent Zoho announcement regarding changes to the ZohoCRM API framework, in the event these changes might impact the work you are completing: https://www.zoho.com/crm/help/api/security-enhancement.html