3.4 Multi-Device Support
Zoom users often have several devices that they use Zoom on: their work computer, personal computer, mobile phone, and so on. Each of these devices stores long-term signing and encryption keys (called device keys), which it uses to secure communications and data across a variety of Zoom products. To obtain a rigorous concept of identity, we formalize the set of a user's device keys as well as the ways this set can change over time, a crucial step towards achieving the goal of linking a user's identifiers with their device keys.
Users have three main operations to change their set of valid devices:
DeviceAdd, which adds a new device to the set. The new device generates a new long-term signing key, which is used directly in some Zoom products (such as E2EE meetings) and also to sign statements about the set, and an encryption key, which can be used to communicate with other devices.
DeviceRevoke, which revokes the validity of a previously-added device. Revoked devices are still recorded as part of the set for auditing purposes, but new signatures from their keys are no longer considered valid, and the encryption keys they have access to are rotated as soon as possible.
BatchApprove, which indicates that an existing device considers all devices added to the set until this BatchApprove event legitimate and trustworthy. This operation is signed by the approving device’s key.
Ensuring that each user has a single set of devices that is consistent over time serves several purposes. For the user themselves, it ensures that all of their devices know about each other, so they can be notified when a new device gets added and quickly react if their user account has been compromised.
A user’s set of devices is also of interest to other users they interact with, because not all devices associated with a user may be trusted equally. If Bob is in a meeting with Alice's work computer today, he can trust the connection (i.e., that there is no MitM) by either checking the security code or by noting that Alice’s public key is the same as was used in all past interactions Bob had with Alice. This way, Bob only has to trust that there was no MitM the first time they communicated (established and from that assumption, deduce that all communications where Alice has the same public key are also secure. This assumption is commonly referred to as Trust-On-First-Use (TOFU). If, for tomorrow, Bob meets with Alice’s new mobile phone, Bob might not trust its key as much as her work computer's: a malicious service could have added it, or a hacker could have stolen Alice’s Zoom password. It’d be unfortunate if Alice and Bob had to recheck their security code. By performing a BatchApprove operation from her work computer, Alice can indicate that all of her other devices are trusted, so Bob (who trusts the public key on Alice’s work laptop) can use the signed BatchApprove statement to extend his trust to Alice’s new mobile phone's key.
BatchApprove operations induce a trust graph over a user's set of devices, where each device represents a node and each BatchApprove adds an edge from the device performing the approval to all non-revoked devices introduced after that device. We call each connected component in this graph an approval class, and we assume devices in the same approval class trust each other. When a Zoom user provisions a new device, they’ll have access to their complete device list and so will be able to revoke any that are unrecognized, lost, or stolen. Because of this, we assume that later devices implicitly trust the validity of earlier ones.
Consider the following scenario:
Bob provisions Device a
Bob provisions Device b
Bob provisions Device c
Bob's graph is disconnected: he has 3 separate devices and 3 different approval classes. c does implicitly trust b, but we don't consider them part of the same approval class as the trust is not mutual.
Bob logs onto b and performs a BatchApprove
This operation partially connects Bob's trust graph. b trusts c (the device provisioned after b). Now, there are only two approval classes: one with a and one with b and c.
Bob provisions Device d
Bob logs onto c and performs a BatchApprove
Now, c trusts d. Because b already trusted c, we know that b trusts d as well, even though it never made this claim explicitly.
A malicious server provisions Device e in order to impersonate Bob
Bob logs onto a, recognizes it's unrecognized, and performs a BatchApprove
Having all of Bob’s devices know about each other allows Bob to take action if his account is compromised. After he revokes e, all of Bob’s devices, as well as the users he communicates with on Zoom, know not to trust statements signed by e's device key. Figure 1 summarizes Bob’s trust graph after these steps.