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

Filed Under

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.

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


It is unfortunate that schools did not Phil Howard  –  Apr 10, 2020 11:59 PM

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!

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.



IPv4 Markets

Sponsored byIPXO

Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byAppdetex


Sponsored byVerisign

Domain Management

Sponsored byMarkMonitor

Domain Names

Sponsored byVerisign