7.12 Security Properties for E2EE Meetings

The Identity Management System, Bulletin Board and Signaling Channel as enumerated in Section 7.4 are deployed by Zoom, and protect against outsiders using TLS. Attackers classified as insiders by our threat model could monitor or meddle with these components. An insider monitoring such components (a passive attack) would expose meeting metadata, which is stated as a limitation of our designs in Section 2.1, but would not otherwise compromise the confidentiality of the meeting. We prevent outsiders from joining meetings through passwords, waiting rooms, and the other non-cryptographic server-enforced access control features described in Section 7.1. TLS and encryption of the meeting streams protect the confidentiality and integrity of the meeting against outsiders who might control the participants’ network. Within the same meeting, the encrypted streams sent by each participant are protected against replay attacks by using encryption nonces as counters. Even across different meetings, the streams cannot be replayed thanks to the fact that participants delete all the ephemeral keys once a meeting is over (which also guarantees forward secrecy). We aim to minimize the damage that an active insider can perform without being detected. First, an insider can force participants to drop out of a meeting, as well as partition them into separate meetings, each with its own leader, and add extra participants circumventing all the above server-enforced features. Our protocol ensures that the meeting leader will be able to detect any participant obtaining access to meeting encryption keys by monitoring the participant list for unexpected entries (for example, by recognizing the participants’ faces in their video streams). If the host observes the same user leaving the meeting four or more times, the participant list will reflect the number of observed leaves. Liveness properties ensure that actions like rekeying the meeting or adding/removing participants cannot be arbitrarily delayed, and furthermore, that audio/video streams displayed are relatively recent. Detecting unauthorized participants can be challenging in large meetings or in certain views, such as when the leader is sharing their screen. In the future, a stronger notion of identity will be leveraged to highlight potential eavesdroppers in the UI, such as those outside of the host’s organization or guest users.

We stress that, even when using IDP attestations, seeing a specific user identity in the participant list of a meeting does not imply that the corresponding user has chosen to participate in the meeting or is still actively participating, but only that that user could potentially have access to the encrypted meeting contents. A malicious insider could either trick the leader into including a user in the participant list (when the user is not actually present in the meeting), or hide the fact that a participant has left a meeting (so that other users are convinced they are still participating). All such participants would still trigger Contact Sync warnings as detailed in Section 3.9 (once that feature is deployed), and clients will remember their identities for future meetings. We believe that preventing these issues would add too much complexity and overhead to the protocol. An active attacker can also try to perform a MitM attack against the meeting. This class of attacks is mitigated by the meeting leader security code, which should be re-checked every time a participant joins or rejoins the meeting (including when moving in and out of breakout rooms), or whenever the meeting leader security code changes as indicated by a UI notification. When leveraged in E2EE meetings (under the assumptions in Section 5.6) an IDP attestation confirms that a meeting participant’s long-term device key belongs to a member of a specific account (identified by its ADN), which has vouched for that participant’s identity (e.g. email address) through a third party identity provider. IDP attestations are a mitigation against MitM attacks and serve as an alternative to checking security codes. We also stress that, as discussed in Section 7.8, when in an E2EE meeting using Breakout Rooms, participants should be skeptical of broadcast messages from the meeting host and should carefully monitor the participant list of the main meeting. We have published [10] a formal security analysis of our core E2EE meetings protocol, which precisely characterizes the liveness, confidentiality, and security properties it achieves.