7.4 System Components

Our end-to-end encryption protocol assumes the following components: Identity management system. The system depends on the existence of a Zoom ID management system that will be responsible for distributing cryptographic public keys generated by individual clients. This server will bind keys to Zoom user accounts where possible, and will also support clients who do not have explicit Zoom identities.

Signaling channel. The system will make use of a signaling channel to distribute cryptographic messages between participants in a meeting. Currently, meeting participants route control messages on TLS-tunnels over TCP, through the MMRs. TLS is terminated at Zoom’s servers. This channel is suitable for our needs. Bulletin board. Participants in the channel can post cryptographic messages to a meeting-specific “bulletin board,” where all other participants can see them. This abstraction can be implemented over the signaling channel. The server controls the bulletin board, as it controls the signaling channel itself, and therefore can tamper with it. Meeting leader. The protocol requires that, at all times, one of the participants plays the role of the meeting “leader.” This client will have the responsibility of generating and updating the shared meeting key, and to distribute this key and other meeting metadata to the other participants. Zoom servers will select the leader, and replace them with a new one if the current one leaves. Note that the meeting leader role is different from the meeting host, who can authorize and kick out participants and has administrative control over meeting functionality. Before version 5.11.3, clients enforce that the leader is always the host, and this will still be the case in most meetings; however, newer clients allow the server to assign these roles independently to support functionality like E2EE Breakout Rooms, which do not have a dedicated host.