3.8.1 Escrow Administrators and the EA Sighchain

To enable escrow for their account, an account administrator assigns EA permissions (Section 3.8.3) to one or more users to designate them as EAs. EAs will then be able to provision one or more of their devices with fresh EA device keys, which ultimately will be used to decrypt the encrypted content escrowed from all the account’s users.

EA device keys are independent of the device keys listed on the EA’s own user sighchain (and used to encrypt their own data); instead, the EA enabled devices and their public keys are added to a special user sighchain, which we call the EA sighchain. EA sighchains follow all the rules of regular user sighchains (Section 3.5.3), but they have no single user-email, and devices listed in this chain can belong to different EAs (instead of a single user).

In addition, the server adds an EscrowAdmin link to the account sighchain referring to the EA sighchain’s userID, so that account members can be on the same page on whether escrow is enabled or not. Each EA sighchain is associated with at most one account, and vice versa.

When provisioning an EA’s device to have access to all the account’s data, the device generates fresh EA device keys and adds a new link to the EA sighchain. These users’ devices therefore have two sets of device keys: one on the user’s own sighchain, and one on the EA sighchain. Once it is approved by an existing device on the EA sighchain, the device will receive all the PUKs associated with this EA sighchain, allowing it access to all the escrowed data. Provisioned EA devices will display to their corresponding EA users the list of active EA devices (which EAs can use to monitor which devices have access to the account’s data) and the EA sighchain fingerprint. Monitoring EA devices and comparing fingerprints prevents MitM attacks. The fingerprint can be compared before approving a new EA device, and shared with all the account members so that they can confirm it before enabling escrow. After enabling escrow, account members can continue to monitor the EA fingerprint to ensure that their escrow devices are rotated for every EA PUK rotation.

Given that the Zoom server is responsible for enforcing which users are EAs, and therefore can add devices to the EA sighchain, the first device will enable lockdown mode on the EA sighchain (see Section 3.4.4), and members’ clients will enforce that this is the case. This prevents an attacker compromising the Zoom server from generating new PUKs on the EA sighchain and therefore gaining access to account members’ data. Lockdown mode also has a significant performance impact as it would trigger a PUK rotation in all the account member’s chains as well (Section 3.4.1).

When an account administrator disables escrow, the Zoom server revokes all escrow admin management permissions, adds a new link to the account sighchain with an empty escrow admin userID, and revokes all device keys on the EA’s chain. As soon as clients are aware of this, either through a server notification or from their own monitoring, they revoke the virtual escrow devices from their own chains (and rotate their PUKs). EAs’ devices will also revoke the EA device’s secret keys from durable storage. If the user is moved between different accounts, and the new account has escrow enabled, the user will be notified of the new escrow being setup and given the opportunity to check the new EA sighchain’s fingerprint. If the former account has escrow enabled, those EAs will only have access to the user’s ciphertexts before the account change, while the user’s devices will share all known PUKs with the new EAs. As detailed in the Security Limitations section, we rely on the server to enforce proper access control for ciphertexts when the encryption keys cannot be promptly rotated due to the user’s devices being offline, which can happen in both the above cases.

It is important that the EAs maintain access to at least one device in the oldest non-empty approval class at all times, as otherwise escrowed data could be irreparably lost. For this reason, administrators are required to generate a backup key on the EA sighchain when enabling escrow. If all the devices on the EA’s oldest class are unavailable, the only option to recover is to turn escrow off and back on, which would trigger notifications to all account members to acknowledge escrow again.

When escrow is enabled, or re-enabled when old escrow devices are unavailable, the new EAs will have access to a specific user’s data only after that user comes online to encrypt their keys for the EAs. Therefore, there may be unrecoverable gaps in the content that can be recovered for the escrowed users. To avoid this, we recommend account administrators to enable escrow before encryption