2.1 Limitations

Abuse Prevention:

When authorized participants engage in abusive behavior, there is an effective mechanism to report them to Zoom’s safety team, to help prevent further abuse.

Broadly speaking, end-to-end encrypted products aim to achieve confidentiality and integrity goals even against insiders: we aim to detect, and if possible, prevent any violations of these properties. While prevention is preferable, we stress that even detection can be a powerful deterrent: it allows users to monitor their communications and quickly move to limit any damage, while demonstrating our commitment to be transparent about breaches.

All Zoom products also have many server-driven security and access control mechanisms, including transport-layer encryption, meeting passwords, and granular user and account level permissions. While these are not meant to protect against insiders with privileged access to our infrastructure (and are not the focus of this document), they are highly effective against outsiders.

2.1 Limitations

Our encryption protocols offer strong guarantees for our customers. However, as with any security system, there are limitations to our approach. There are certain classes of attacks and threats that we deem out of scope, including:

Metadata and traffic analysis: Insiders and outsiders may learn information about the timing, duration, and bandwidth usage patterns of end-to-end encrypted communications, as well as the list of participants and IP addresses.

Software flaws: Zoom’s client code or the third-party libraries it links against can have bugs, or worse, intentional backdoors. Zoom’s binary build procedures might become compromised. In these cases, there are no good cryptographic guarantees we can make. Zoom relies on extensive analyses by independent third party auditors to reassure customers in this domain.

Third party compromise: We leverage third-party Single Sign-Ons (SSOs) and Identity Providers (IDPs) to independently vouch for the identity of Zoom’s users. Doing so moves the trust away from Zoom and to identity providers that many of Zoom’s enterprise users already trust for sensitive identity operations. While we do rely on SSOs and IDPs, the additional security guarantees they offer might be lost due to attacks on their infrastructure.

Denial of service: The encryption architecture does not offer any guarantees regarding availability of the service. Insiders can always refuse service to a specific user, including when they try to perform security critical operations such as enabling or disabling encryption. Insiders could also engineer conditions that would be compromised to try to prevent further data from being encrypted and thus exposed. Email services that do not support end-to-end encryption (see Section 6.3) or, dial-in phones can be used to join Zoom Meetings, but do not support end-to-end encryption. F2F security of the type described in this document is not possible in settings where Zoom products interface with these existing standards. Moreover, users can access some Zoom products through their web browser, and without installing Zoom’s client. Supporting E2E2F for web users poses certain challenges: secure, long-term storage for cryptographic private keys might be unavailable; and worse, malicious web servers could serve backdoored source code to web clients with little chance of detection. We intend to participate in the web standards development process to facilitate the creation of browsers upon which we could offer dependable E2F security.

We will further comment on the specific properties and limitations for each of the products and features described in this whitepaper in their respective sections.