3.7.1 Storing Secret Keys on Device

Clients persist device key pairs indefinitely until a DeviceRevoke or DeviceKeyRotate occurs. Device keys are never transmitted to any other device or the server. They may sometimes be lost after a disk corruption or operating system reinstall. In this case, the user must go through the provisioning process once again as a new device would.

Long-term device keys are stored in the local operating system’s keychain (where available), but with some added protection for two Zoom users using the same OS account. Before storing keys in the local OS-provided keychain, we encrypt them using a key-wrapping key stored by the server and specific to each user and each device. When a user revokes their device, they will delete the keychain entry and the server will delete the corresponding key. This also guarantees that keys cannot be recovered from a backup of a device that has since been revoked. If two users are using the same computer, the key-wrapping key prevents one user from being able to access the other’s keys.

One exception are keys corresponding to devices on the EA sighchain (see Section 3.8.1). These keys are also stored in the OS keychain, but they are encrypted using a key-wrapping key which is unique to each EA sighchain and each device. The server will only provide this key-wrapping key to users with EA permissions (see Section 3.8.3). This allows two EAs in the same account sharing the same device to use the same EA device key, which therefore only needs to be provisioned (and approved) once.

We use the committing AEAD scheme CtE1 [12] to prevent the server from supplying malicious key-wrapping keys. On provisioning, after generating the device encryption and signing key pairs, the client will encrypt each secret key as follows:

1. Generate a 32-byte random string KWK and request the server to store it persistently associated with the user and device.

2. Define Context = "Zoombase-1-ClientOnly-KDF-SecretStore".

3. Compute �=���1−���(����,��������,��)�=���1−���(����​,��������​,��​)�=���1−���(����,��������,��)C=CtE1−Enc(KKWK​,HContext​,Mk​), where ���H is the associated data parameter for the underlying AEAD, and store it in the system keychain.

For CtE1, we use HMACSHA256 as the commitment function and libsodium [9]'s crypto_aead_chacha20poly1305_ietf as the AEAD.

We emphasize that this feature will not protect against an insider who also has access to a user’s device (for example, by colluding with another user using the same device). It will also not prevent different users of the same device from installing malware to steal the other user’s keys.