Security Analysis of End-to-End Encryption for Zoom Meetings

Abstract

In the wake of the global COVID-19 pandemic, video conference systems have become essential for not only business purposes, but also private, academic, and educational uses. Among the various systems, Zoom is the most widely deployed video conference system. In October 2020, Zoom Video Communications rolled out their end-to-end encryption (E2EE) to protect conversations in a meeting from even insiders, namely, the service provider Zoom. In this study, we conduct thorough security evaluations of the E2EE of Zoom (version 2.3.1) by analyzing their cryptographic protocols. We discover several attacks more powerful than those expected by Zoom according to their whitepaper. Specifically, if insiders collude with meeting participants, they can impersonate any Zoom user in target meetings, whereas Zoom indicates that they can impersonate only the current meeting participants. Besides, even without relying on malicious participants, insiders can impersonate any Zoom user in target meetings though they cannot decrypt meeting streams. In addition, we demonstrate several impersonation attacks by meeting participants or insiders colluding with meeting participants. Although these attacks may be beyond the scope of the security claims made by Zoom or may be already mentioned in the whitepaper, we reveal the details of the attack procedures and their feasibility in the real-world setting and propose effective countermeasures in this paper. Our findings are not an immediate threat to the E2EE of Zoom; however, we believe that these security evaluations are of value for deeply understanding the security of E2EE of Zoom.

Appendices

A Cryptographic Algorithms

1.1 A.1 Signing

Signing scheme consists of Sign.KeyGen, Sign.Sign, and Sign.Verify as follows:

• Sign.KeyGen generates a keypair (vk, sk), where vk and sk denote a verification key and a signing key, respectively.

• Sign.Sign takes a context string Context and a message M as the inputs and outputs a signature Sig over SHA256(Context)$\parallel$ SHA256(M).

• Sign.Verify takes a signature Sig a context string Context and a message M as the inputs, and outputs True upon verification success and False upon failure.

1.2 A.2 Authenticated Public-Key Encryption

Authenticated public-key encryption scheme consists of Box.KeyGen, Box.Enc, and Box.Dex.

Box.KeyGen generates a keypair $(pk_\mathsf{Box}, sk_\mathsf{Box})$, where $pk_\mathsf{Box}$ and $sk_\mathsf{Box}$ denote a public key and a secret key, respectively.

Box.Enc takes the sender’s secret key $sk_\mathsf{Box}^\mathsf{S}$, receiver’s public key $pk_\mathsf{Box}^\mathsf{R}$, a context string $\mathsf{Context_{KDF}}$ and $\mathsf{Context_{cipher}}$, metadata Meta, and a message M as the inputs, and outputs a ciphertext C as follows:

• 1. Generate a 192-bit random string RandomNonce.

• 2. Compute $K' \leftarrow \mathsf{DHKE}(pk_\mathsf{Box}^\mathsf{R}, sk_\mathsf{Box}^\mathsf{S})$, which is the DH key exchange.

• 3. Compute $K \leftarrow \mathsf{HKDF}(K', \mathsf{Context_{KDF}})$, using an empty HKDF salt.

• 4. Compute $D \leftarrow \mathsf{SHA256}(\mathsf{Context_{cipher}})\parallel \mathsf{SHA256}(\mathsf{Meta})$.

• 5. Encrypt the plaintext M with XChaCha20/Poly-1305 taken the symmetric key K, the associated data D, and the nonce RandomNonce as the inputs, and return the ciphertext $C'$.

• 6. Output $C \leftarrow (C', \mathsf{RandomNonce})$.

Box.Dec . takes the receiver’s secret key $sk_\mathsf{Box}^\mathsf{R}$, sender’s public key $pk_\mathsf{Box}^\mathsf{S}$, a context string $\mathsf{Context_{KDF}}$ and $\mathsf{Context_{cipher}}$, metadata Meta, and a ciphertext C as inputs, and outputs a message M or error as follows:

• 1. Parse C as $(C', \mathsf{RandomNonce})$.

• 2. Compute $K' \leftarrow \mathsf{DHKE}(pk_\mathsf{Box}^\mathsf{R}, sk_\mathsf{Box}^\mathsf{S})$, which is the DH key exchange.

• 3. Compute $K \leftarrow \mathsf{HKDF}(K', \mathsf{Context_{KDF}})$, using an empty HKDF salt.

• 4. Compute $D \leftarrow \mathsf{SHA256}(\mathsf{Context_{cipher}})\parallel \mathsf{SHA256}(\mathsf{Meta})$.

• 5. Encrypt the ciphertext $C'$ with XChaCha20/Poly-1305 taken the symmetric key K, the associated data D, and the nonce RandomNonce as the inputs, and return the plaintext M.

• 6. If decryption fails, then output error. Otherwise, output M.

B Further Discussion in Sect. 5

This section further expounds on the discussion in Sect. 5.2.

1.1 B.1 Impersonation Based on Vulnerabilities 1–4 without Colluding with a Malicious Insider

We explain how a malicious outsider can impersonate even any legitimate Zoom User B uninvited to the target meeting without colluding with a malicious insider in the following scenario:

• 1. A malicious outsider stores $\mathsf{Sig}_\mathsf{B}$ and $pk_\mathsf{B}$ posted on the bulletin board in the previous meeting.

• 2. A malicious meeting leader uses meetingID as the personal meeting ID.

• 3. The malicious outsider collects the meetingUUID generated by a malicious insider with the meetingUUID used in the previous meeting.

• 4. The malicious meeting leader reuses the MK used in the previous meeting.

• 5. The malicious outsider posts $\mathsf{Sig}_\mathsf{B}$ and $pk_\mathsf{B}$ to the bulletin board in the new meeting.

To realize the above scenario, the malicious outsider only needs to collude with the malicious meeting leader. To generate meetingID, a meeting leader can choose to automatically generate it with the help of the insiders or use a fixed value as the personal meeting ID. If a malicious meeting leader generates meetingID as a personal meeting ID, then the meeting participants use the same meetingID as the previous meeting. In addition, if meetingUUID is generated according to RFC 4122 [18] (although we do not know if this is actually correct because the generation process of a MeetingUUID is not disclosed in the whitepaper), the meetingUUID is identical to the previous meetingUUID in $2^{61}$ trials by executing a birthday attack. Based on these procedures, the malicious outsider can probabilistically use the same meetingID and meetingUUID as in the previous meeting without colluding with a malicious insider.

1.2 B.2 Discussion

This subsection discusses the feasibilities against the impersonation described in the previous subsection.

Zoom Video Communications announced on its blog that more than 300 million daily meeting participants join Zoom meetings as of April 2020 [25]. Assuming that all meetings have only two participants, only $2^{35.67}$ meetings will be held worldwide in a year. Therefore, there is not much feasibility of executing a birthday attack with $2^{61}$ trials to make meetingUUID coincide with the previous meetingUUID.

Even if the meetingUUID coincides with the previous meetingUUID, how a malicious outsider posts $\mathsf{Sig}_\mathsf{B}$ and $pk_\mathsf{B}$ to the bulletin board implemented on the signaling channel is an open problem. We suggest that a malicious meeting leader posts $\mathsf{Sig}_\mathsf{B}$ and $pk_\mathsf{B}$ on behalf of a malicious outsider as one solution, but we cannot confirm the feasibility of this attack.

In summary, although there is not much feasibility of impersonating even any legitimate Zoom User B uninvited to the target meeting without colluding with a malicious insider, the protocol must include countermeasures, as described in Sect. 5.3, in the event of such an impersonation.