Thread by @LeaKissner

It's time to talk about @zoom_us security over @zoom_us at #enigma2021 by Merry Ember Mou with the talk "BUILDING E2EE AND USER IDENTITY"

usenix.org/conference/eni…

Zoom's launched end-to-end encryption 5 months after the white paper was published
* prevents eavesdroppers between users who are speaking to each other
* protection against compromised servers

[ here's the E2EE whitepaper from Zoom]

github.com/zoom/zoom-e2e-…

What's a Zoom meeting like?
* streamed through servers
* people can join and leave (subject to controls)
* meetings are encrypted by a key (server doesn't decrypt generally but needs the key for things like people who join by phone and to let new people join)

But E2EE requires that the server can't get in (or anyone else not in the meeting)
* so a client needs to make the meeting key and distribute it to other meeting participants
* putting it into an existing system, so don't want to degrade performance or introduce complexity/bugs

E2EE design: meeting leader makes the key, distributes it (encrypted under each user's public key) and some meeting-specific context

[ not going to try to type the crypto see the whitepaper 😁 ]

When someone leaves the meeting, the meeting leader rotates the key

Also need to know who's in the meeting -- the leader makes and signs the list

Notice that people can set their display name to whatever they want -- we'll revisit this later

If a leader drops out or changes, everyone's shown a leader change notification and the new leader rotates the key

There's a security code everyone can check to make sure there are no MITMs

Now let's talk about performance realities which shaped design
* video sent over UDP
* security messages sent over TCP and must be performant
* have to work on low-end phones
* joining a meeting must be easy
* participants must get meeting keys

Have to throttle re-keying if a zillion people are joining/leaving -- if you don't then you can DoS everyone with re-keys at the beginning/ends of large meetings
(but will always happen within 15 seconds)

Participants need to see new meeting participants, etc. but if you send a zillion notifications people can get alert fatigue and had to balance for that

Deploying E2EE
* There's a small interface for the client E2EE code
* Clients post public keys to keyservers (later phases may include more identity information)
* Require clients to update versions to use E2EE, but try to avoid backwards incompatibility

How do you know who you're in a meeting with? Are they sus?
* can check code.. but you might not know everyone
* camera and mic may be off

... and people can name themselves whatever they want

How do we prove that a key is associated with an identity and prove it?
* later phases have multi-device identity
* if you're part of an "account" (e.g. company, school), then the account can prove you're part of it
* attestations in a signchain which goes in a transparency tree

Because there's a sigchain/transparency tree, we can audit it and see if the server has engaged in any nefarious behaviour (e.g. erasing devices, adding new devices)

Somewhat similar to keybase.io tree, but not the same. Zoom identities may not be public, etc.

Sharing sigchains
* participants in a meeting can share their sigchains with each other to prove what their identities are
* display identities appropriately

Also can use an identity provider (IdP) to vouch for an identity -- because most people trust their IdP

[for IdP think your login service e.g. @okta ]

Takeaways:
* E2EE security depends on knowing who's at the ends
* Building E2EE into an existing implementation requires a lot of balancing
* "is it secure?" is never a yes/no question -- depends on assumptions, usability, systems, etc. [YES!]

[end of talk -- read the paper]