Zoom E2EE

End-to-end encryption (E2EE) means that data is encrypted between the different endpoints. No intermediary party can decrypt it and thus, private communication is achieved.

After a long long list of security failures, bad programming, poor design choices. Zoom made lots of efforts to fix several serious issues and recently brought finally the E2EE feature.

General meeting uses a meeting key to protect communication transit with aes-256-gcm. The key is distributed, by Zoom servers, to each joining participiant. It uses a KDF (HMAC) including cleartext stream id.

MMR, multimedia routers, relay and multiplex streams without any packet decryption. These are part of Zoom cloud infrastructure. However, any feature that does not natively permit the Zoom protocol, use a Zoom connector, to proxy the streams. These proxy act as an endpoint and decrypt/encrypt all their communication with the endpoint application, such as SIP, PSTN, H323.

Recent development provides (from zoom communication) E2EE with zoom native clients. There are mandatory disabled features to be able to use such security level:

• Join before host
• Cloud recording
• Live streaming
• Live transcription
• Breakout Rooms
• Polling

Free user accounts can use this security feature. They are required to have a valid billing option associated. Phone verification is mandatory.

The E2EE feature is defined as an option in the account settings and group management (Settings->Meeting->Security). Participants will have to verify a security code to ensure they match the expected one.

Better identity management and E2EE SSO integration are part of Phase 2, which is tentatively roadmapped for 2021. Thanks to the support of solid cryptographers, Zoom security features are improving over time.

Zoom’s E2EE meetings support a maximum of 200 participants.

Zoom finally provides a correct level of security. However, don’t forget that they first started to lie about their security. And they really changed because of public pressure, not because of proactive security. Anyway, in the end, it worked and results are there. However, as we don’t have access to the source code, many aspects rely on what can be communicated. Hopefully further independant audits will continue and let users have a more appropriate trust with Zoom.

Please, refer to the EFF guide for good security practice with Zoom application usage.

The Paderborn university provides good instructions on when and how to use Zoom. As they advise, self-hosting a Jitsi instance, provides much better control and confidentiality. Jitsi is free/libre software and does not require at all a user account registration. BTW, Jitsi has an ongoing work on E2EE and it currently works, but not tagged yet production ready.