Home / Blogs

Zoom Cryptography and Authentication Problems

In my last blog post about Zoom, I noted that the company says "that critics have misunderstood how they do encryption." New research from Citizen Lab show that not only were the critics correct, Zoom's design shows that they're completely ignorant about encryption. When companies roll their own crypto, I expect it to have flaws. I don't expect those flaws to be errors I'd find unacceptable in an introductory undergraduate class, but that's what happened here.

Let's start with the egregious flaw. In this particular context, it's probably not a real threat — I doubt if anyone but a major SIGINT agency could exploit it — but it's just one of these things that you should absolutely never do: use the Electronic Code Book (ECB) mode of encryption for messages. Here's what I've told my students about ECB:

  • Direct use of a block cipher is inadvisable
  • Enemy can build up "code book" of plaintext/ciphertext equivalents
  • Direct use of the block cipher [is]
  • Used primarily to transmit encrypted keys
  • Very weak if used for general-purpose encryption; never use it for a file or a message.
  • Attacker can build up codebook; no semantic security

Again, it would be hard to exploit here, but it suggests that the encryption code was written by someone who knew nothing whatsoever about the subject — and lays open the suspicion that there are deeper, more subtle problems. I mean, subtle problems are hard to avoid in cryptography even when you know what you're doing.

The more important error isn't that egregious, but it does show a fundamental misunderstanding of what "end-to-end encryption" means. The definition from a recent Internet Society brief is a good one:

End-to-end (E2E) encryption is any form of encryption in which only the sender and intended recipient hold the keys to decrypt the message. The most important aspect of E2E encryption is that no third party, even the party providing the communication service, has knowledge of the encryption keys.

As shown by Citizen Lab, Zoom's code does not meet that definition:

By default, all participants' audio and video in a Zoom meeting appear to be encrypted and decrypted with a single AES-128 key shared amongst the participants. The AES key appears to be generated and distributed to the meeting's participants by Zoom servers.

Zoom has the key, and could, in principle, retain it and use it to decrypt conversations. They say they do not do so, which is good, but this clearly does not meet the definition [emphasis added]: no third party, even the party providing the communication service, has knowledge of the encryption keys."

Doing key management — that is, ensuring that the proper parties and only the proper parties know the key — is a hard problem, especially in a multiparty conversation. At a minimum, you need assurance that someone you're talking to is indeed the proper party, and not some interloper or eavesdropper. That, in turn, requires that anyone who is concerned about the security of the conversation has to have some reason to believe in the other parties' identities, whether via direct authentication or because some trusted party has vouched for them. On today's Internet, when consumers log on to a remote site, they typically supply a password or the like to authenticate themselves, but the site's own identity is established via a trusted third party known as a certificate authority.

Zoom can't quite do identification correctly. You can have a login with Zoom, and meeting hosts generally do, but often, participants do not. Again, this is less of an issue in an enterprise setting, where most users could be registered, but that won't always be true for, say, university or school classes. Without participant identification and authentication, it isn't possible for Zoom to set up a strongly protected session, no matter how good their cryptography; you could end up talking to Boris or Natasha when you really wanted to talk confidentially to moose or squirrel.

You can associate a password or PIN with a meeting invitation, but Zoom knows this value and uses it for access control, meaning that it's not a good enough secret to use to set up a secure, private conference.

Suppose, though, that all participants are strongly authenticated and have some cryptographic credentials they can use to authenticate themselves. Can Zoom software then set up true end-to-end encryption? Yes, it can, but it requires sophisticated cryptographic mechanisms. Zoom manifestly does not have the right expertise to set up something like that, or they wouldn't use ECB mode or misunderstand what end-to-end encryption really is.

Suppose that Zoom wants to do everything right. Could they retrofit true end-to-end encryption, done properly? The sticking point is likely to be authenticating users. Zoom likes to outsource authentication to its enterprise clients, which is great for their intended market but says nothing about the existence of cryptographic credentials.

All that said, it might be possible to use a so-called Password-authenticated key exchange (PAKE) protocol to let participants themselves agree on a secure, shared key. (Disclaimer: many years ago, a colleague and I co-invented EKE, the first such scheme.) But multiparty PAKEs are rather rare. I don't know if there are any that are secure enough and would scale to enough users.

So: Zoom is doing its cryptography very badly, and while some of the errors can be fixed pretty easily, others are difficult and will take time and expertise to solve.

By Steven Bellovin, Professor of Computer Science at Columbia University – Bellovin is the co-author of Firewalls and Internet Security: Repelling the Wily Hacker, and holds several patents on cryptographic and network protocols. He has served on many National Research Council study committees, including those on information systems trustworthiness, the privacy implications of authentication technologies, and cybersecurity research needs. Visit Page

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Comments

It is unfortunate that schools did not By Phil Howard  –  Apr 10, 2020 4:59 pm PDT

It is unfortunate that schools did not have sufficient time in advance to set up proper unique authentication identities for each of their students for use through facilities and services like Zoom.  Even with the servers constructing the classroom context, where we must trust the server, securely authenticated communication with each student is essential to trust that server.  Zoom was even shortcutting security of a business meeting setting for convenience.

I can understand Zoom wanting to make use of their service easier to use than the service of their competitors.  That's what the users demand.  I must blame the (business) users for this.  They are demanding wrong security in the form of convenience. Security is an attitude.  Security is not convenient!

Add Your Comments

 To post your comments, please login or create an account.

Related

Topics

DNS Security

Sponsored byAfilias

New TLDs

Sponsored byAfilias

Domain Names

Sponsored byVerisign

Whois

Sponsored byWhoisXML API

Cybercrime

Sponsored byThreat Intelligence Platform

Brand Protection

Sponsored byAppdetex

Cybersecurity

Sponsored byVerisign

IP Addressing

Sponsored byIPv4.Global