I’m sitting outside during quarantine reading Zoom’s new “E2E Encryption for Zoom Meetings” and it’s pretty interesting.

First things I notice: I recognize some of these names, and it uses a Creative Commons license!

It’s also refreshingly honest about Zoom’s security limitations. A complete 180 compared to before the pandemic when Zoom was basically like “no worries we’re unhackable”

They include themselves in their threat model now! This is important because as a US company, and a company that operates all over the world (including China), governments can force Zoom (and any company) to spy on their users. The only way to mitigate this threat is real E2EE

While I’d love it if it were some day in scope, I’m glad they acknowledge that even with E2EE they’re not attempting to protect metadata: who is meeting with who, when, and from where

They’re planning on incrementally implementing E2EE in four phases. I like this because it means we’ll be able to have E2EE (albeit imperfect) Zoom meetings sooner.

When using a meeting in E2E mode, everyone will have to use the Zoom app: no web app, dial in, etc

In phase 1, meetings will be E2EE but you still have to trust Zoom’a servers: they could do an active attack to spy on a meeting (like FaceTime or iMessage). But by phase 4, Zoom accounts are basically like Keybase accounts- using existing devices to add new devices

Phase 1 will have a “meeting security code”. The host can read it out loud, and all participants can compare it, and if it matches for everyone it means there is no MITM attack.

Already, this is better than Webex, which currently supports E2EE but doesn’t let you verify it

Interesting. “No secret key or unencrypted meeting contents will be provided to Zoom infrastructure servers” except for abuse reporting — seems reasonable

Describing a bunch of cryptographic algorithms they’re planning to use

Every Zoom device generates and stores a long term signing keypair which never leaves that device.

public key crypto

Each device has a keypair, but additionally each time you join a meeting you generate a new ephemeral keypair just for that meeting, signs it with their long term keypair.

This is what’s used to encrypt the meeting’s symmetric session key for each participant

As people leave and join the meeting, the shared meeting key gets rekeyed. So if you join for a second, get the key, then leave/get kicked out, you can’t spy on the rest of the meeting (assuming you can observe the network)

Nice. When you leave a meeting, your client destroys all ephemeral keys used during the meeting to provide “forward secrecy” — an attacker that records an encrypted meeting can’t later decrypt it after stealing keys from a device

Ooh it looks the meeting security code will be encoded as basically a dice ware passphrase.

And “if deep fake technology is a concern” you can verify the meeting is secure out of band, like in a Signal group with all participants

If people join or leave a meeting, and the meeting gets rekeyed, then everyone has to re-compare the security code. That makes sense

Phase 2 is all about identity. Each user makes signed statements when they add new devices and revoke devices, and these statements are part of a signature chain so a malicious server can’t replay or emit any of them

There’s also a signature chain full of contact list updates - you keep track of the device keys you notice for everyone you have meetings with, so you can tell if someone joins from an unrecognized (possibly faked) device

Phase 3 introduces a transparency tree, similar to Certificate Transparency. It ensures that Zoom tells all users the same info about who has what key — meaning if an insider performs a MITM attack against users, there will be a public auditable evidence trail

The Zoom Transparency Tree concept is incredibly similar to how Keybase does a good job at multiple device support. You can see Keybase experience making its way into this doc

Phase 4 introduces “real-time security”, making it so a malicious server simply doesn’t have the ability to add a fake device for a user, and the device needs to be added using an existing device (like by scanning a QR code)

Hah, the conclusion says this white paper proposes bringing E2EE to Zoom “as that term is best understood by security experts” — clearly this is a reference to my and @yaelwrites’a reporting https://theintercept.com/2020/03/31/zoom-meeting-encryption/