The need for encrypting OTP secret keys
In OneAuth, you can back up your OTP secret keys with Zoho Cloud to have them synced across all your devices and to restore them whenever needed.
More about backup and syncInfo: "Secret key" refers to the alphanumeric key that is used to generate OTPs for your 2FA accounts. These keys are provided by your online account (such as Facebook, Twitter) in the form of a QR code or as plaintext.
During this backup process, we won't store your secret keys in the plaintext form. We will encrypt your secret keys using a passphrase you set and then store them in Cloud. This encryption is to make sure your secret keys are confidential and known only to you, which means neither Zoho nor any attacker can see them.
There is another reason to encrypt your secret keys, which is to maintain the integrity and authenticity. It makes sure the secret keys stored in Cloud are modified only by you and not by an attacker.
The encryption/sync logic used in version 2.0 and the concerns
Following are the practices in version 2.0 that we wanted to improve in version 3.0:
1. Usage of AES-ECB method
In v2.0, we used the AES-ECB method for converting your plaintext secret keys into ciphertext (i.e., the encrypted form of secret keys). The ECB method is a rudimentary encryption method, which creates identical ciphertext blocks for identical plaintext blocks. This makes the data susceptible to
replay attack, since an attacker could predict a pattern of how we're encrypting the secret keys. Although this doesn't allow an attacker to read the encrypted data, there's a chance that the attacker can modify the data. That is, confidentiality is maintained, but integrity and authenticity cannot be guaranteed.
2. Encrypted passphrase in Cloud
We encrypt your passphrase and store it in Zoho Cloud in v2.0. When a user is unable to sign in with multi-factor authentication (MFA), they can use their passphrase to recover access to their account. During this account recovery, we check if the user is entering the correct passphrase by comparing it with the encrypted passphrase in Cloud. Although, the stored passphrase is not readable by Zoho or an attacker (since it is encrypted), it is susceptible to
man-in-the-middle attack.
3. Control of data loss
Once the backup and sync is enabled, whenever you make changes to your OTP accounts, we will make the same changes in Cloud. The changes includes adding a new account and editing or deleting an added account. In v2.0, whenever a change happen on your device, we will remove the secrets on Cloud and replace them with the secrets on your device, i.e, complete replacement. In some scenarios, this practice led to loss of data from devices. Ideally, CRUD (Create, Read, Update, Delete) operations should be followed. For example, if you add a new account, only this addition should be reflected in Cloud and other existing secrets should not be completely replaced. The same goes for every kind of change.
To address these drawbacks, in version 3.0, we've made changes and improved our encryption and sync process.
The enhancements made in version 3.0
To address the concerns mentioned previously, we've made the following changes in OneAuth 3.0 to improve the encryption and sync logic.
1. Moved to AES-GCM method
To encrypt the plaintext OTP secret keys into ciphertext, we've used the AES-GCM method in OneAuth 3.0. The AES-GCM mode introduces a randomness in the encryption process, and makes sure that no two ciphertexts are identical to one another (as opposed to AES-ECB). In addition to confidentiality, this method also guarantees integrity and authenticity of the data in Cloud. This form of encryption is referred to as
authenticated encryption.
2. Zero-knowledge architecture
In v3.0, we've implemented a Zero-knowledge architecture, which lets us provide passphrase-based account recovery without having to store the passphrase in Cloud. Instead of encrypting and storing the passphrase in Cloud, we will generate a PBKDF2 key from the passphrase and store it locally on the device temporarily. This PBKDF2 key is then used for encrypting your secret keys. Hence, only you will have access to your passphrase and not even Zoho can decipher it.
3. CRUD implementation
As stated before, when you make changes on your device, CRUD operations should be followed instead of complete replacement. We've implemented this in v3.0. This negates any possibility of data loss.
Overview of the whole encryption & decryption process
When users initiate backup
When users initiate the backup for the first time, they will need to set up a passphrase. Using this passphrase, all their OTP secret keys will be encrypted and stored in Cloud.
The encryption logic we follow during that process is detailed below:
- Generate two random 128 bit salts–encryption salt and recovery salt.
- Store the two generated salts in Cloud.
- Using the passphrase and the recovery salt, generate a key with the PBKDF2 function. This is called the recovery key.
- Using the passphrase and the encryption salt, generate another key with the PBKDF2 function. This is called the encryption key.
- Encrypt the unique ID of the user with the recovery key. AES-GCM mode is used for encryption. (The unique ID is an identifier specific to each Zoho user and used for identification.)
- Store the encrypted unique ID in Cloud. This will be used later when user wants to restore their secret keys or recover their account.
- Encrypt the OTP secret keys of the user with the encryption key. AES-GCM mode is used for encryption.
- Store the encrypted secret keys in Cloud.
When users restore secrets
When a user wants to restore their OTP secret keys on a new device, they will need to enter their passphrase. Using this passphrase, their encrypted secret keys will be retrieved from Cloud and decrypted.
The decryption logic we follow during that process is detailed below:
- Retrieve the recovery salt from Cloud.
- Using the passphrase and the recovery salt, generate a key with the PBKDF2 function. This is called the recovery key.
- Retrieve the encrypted unique ID of the user from Cloud.
- Decrypt the unique ID using the recovery key. If decryption is successful, the process will continue. If not, “Incorrect passphrase” error will be shown for the user and they will be prompted to enter the correct passphrase.
- Using the passphrase and the encryption salt, generate another key with the PBKDF2 function. This is called the encryption key.
- Retrieve the encrypted OTP secret keys from Cloud.
- Decrypt the secret keys using the encryption key.
- Restore the secret keys on user’s device.