3.11.1 MitM Between a User’s Devices

These properties allow us to obtain strong guarantees about the confidentiality of the data that is encrypted for a user’s device keys and PUKs. For example, consider any ciphertext (such as an email draft) encrypted for a given per-user key whose secret key is only known to a set of uncompromised devices controlled by the corresponding user (and the users who have permissions to manage the escrow admin virtual user, if escrow is enabled). In order to obtain the plaintext, an adversary (even an insider) would have to either break the encryption scheme, compromise one of the user’s (or escrow admin’s) current devices or backup keys, or trick the user into using one of their devices to approve a maliciouslycontrolled device (so that the existing device encrypts the PUK secrets for the malicious one). If escrow is enabled, an adversary could also compromise one of the escrow admin’s device keys, or a malicious insider could trick the escrow admin user into approving a maliciously-controlled device. A cautious user would only approve an additional device on their sigchain in a situation where they expect such a request: for example, after they sign in on Zoom for the first time on a new device, or in the case of enabling escrow, after they receive a trustworthy notice from their account administrator that escrow is being enabled. An insider could take this as an opportunity to attempt a MitM attack, by lying about the new device’s public key to the old device. However, outsiders cannot perform this attack: even if the attacker had access to the user’s credentials, the attacker would have to add an extra additional device and cannot prevent the legitimate one from appearing in the approval modal. Comparing the sigchain fingerprints as known to the approving device and the new device before confirming approval (and comparing the EA’s fingerprint before adding or approving the virtual escrow device) also prevents insiders from performing this attack. Because the sigchain is an append-only data structure, comparing fingerprints after approval would still allow the user to detect the attack, providing evidence of server compromise/misbehavior and allowing the user to mitigate its effects. In the future, the Zoom Transparency Tree will offer (assuming trusted auditors) an automated and transparent way to ensure that devices have a consistent view of all sigchains and public keys such that checking fingerprints before device approvals will no longer be critical.