Since the world went virtual, often by using Zoom, several people have asked me if I use it, and if so, do I use their app or their web interface. If I do use it, isn’t this odd, given that I’ve been doing security and privacy work for more than 30 years, and “everyone” knows that Zoom is a security disaster?

To give too short an answer to a very complicated question: I do use it, via both Mac and iOS apps. Some of my reasons are specific to me and may not apply to you; that said, my overall analysis is that Zoom’s security, though not perfect, is quite likely adequate for most people. Security questions always have situation-specific answers; my students will tell you that my favorite response is: “It depends!” This is no different. Let me explain my reasoning.

I’ll start by quoting from Thinking Security, which I wrote about four years ago.

All too often, insecurity is treated as the equivalent of being in a state of sin. Being hacked is not perceived as the result of a misjudgment or of being outsmarted by an adversary; rather, it’s seen as divine punishment for a grievous moral failing. The people responsible didn’t just err; they’re fallen souls to be pitied and/or ostracized. And of course, that sort of thing can’t happen to us, because we’re fine, upstanding folk who have the blessing of the computer deity—$DEITY, in the old Unix-style joke—of our choice.

and

There’s one more point to consider, and it goes to the heart of this book’s theme: is living disconnected worth it? Employees have laptops and network connections because there’s a business need for such things, and not just to provide them with recreation in lonely hotel rooms or a cheap way to make a video call home. As always, the proper question is not “is Wi-Fi access safe?”; rather, it’s “is the benefit to the business from having connectivity greater than or less than the incremental risk?”

Let me put this another way.

1. Are the benefits from me using Zoom (or any other conferencing system; much of this blog post is, as you will see, independent of the particular one involved) greater than the risks?
2. What can Zoom itself do to improve security?
3. If there are risks, what can I or my university do to minimize those risks?

The first part of the question is relatively easy. Part of my job is to teach; part of my employer’s mission is to provide instruction. Given the pandemic, in-person teaching is unduly risky; some form of “distance learning” is the only choice we have right now, and one-way video just isn’t the same. In other words, the benefit of using Zoom is considerable, and I have an ethical obligation to do it unless the risks to me, to my students, or to the university are greater.

Are there risks? Sure, as I discuss below, but at least for teaching, those risks are much less than providing no instruction at all. At most, I—really, the university—should switch to a different platform, but of course, that platform would require its own security analysis.

The platform question is a bit harder, but the analysis is the same. My personal perception, given what I’m now teaching (Computer Security II, a lecture course) and how I teach (I generally use PDF slides), is that I can do a better job on my Mac, where I can use one screen for my slides and another to see my students via their own cameras. In other words, if my ethical obligation is to teach and to teach as well as I can, and if I feel that I teach better when using Mac app, then that’s what I should do unless I feel that the risks are too great.

In other words: I generally don’t use Zoom on iOS for teaching because I don’t think it works as well. I have done so occasionally, where I wanted to use a stylus to highlight parts of diagrams—but I also had it running on my Mac to get the second view of the class.

My reasoning for not using the browser option is a bit different: I don’t trust browsers enough to want one to have the ability to get at my camera or microphone. I (of course) use my browser constantly, and the best way to make sure that my browser doesn’t give the wrong sites access to my camera or mic is to make sure that the browser itself has no access. Can a browser properly ensure that only the right sites have such access, despite all the complexities of IFRAMEs, JavaScript, cross-site scripting problems, and more? I’m not convinced. I think that browsers can be built that way, but I’m not convinced that any actually are.

Some will argue that the Chrome browser is more secure than more or less any other piece of code out there, including especially the Zoom app. That may very well be—Google is good at security. But apart from my serious privacy reservations, flaws in the Zoom app put me at risk while using Zoom, while flaws in a browser put me at risk more or less continuously.

Note carefully that my decision to use the Zoom app on a Mac is based on my classroom teaching responsibilities—and I regard everything I say in class as public and on the record. (Essentially, all of my class slides are posted on my public web site.) There are other things I do for my job where the balance is a bit different: one-on-one meetings with research and project students, private meetings in my roles as both a teacher and as an advisor, faculty meetings, promotion and hiring meetings, and more. The benefits of video may be much less, and the subjects being discussed are often more sensitive, whether because the research is cutting edge and hence potentially more valuable, or because I’m discussing exceedingly sensitive matters. (Anyone who has taught for any length of time has heard these sorts of things from students. For those who haven’t—imagine the most heart-wrenching personal stories you can think of, and then realize that a student has to relate them to a near-stranger who is in a position of authority. And I’ve heard tragic things that my imagination isn’t good enough to have come up with.) Is Zoom (or some other system) secure enough for this type of work?

In order to answer these questions more precisely, though, I have to delve into the specifics of Zoom. Are Zoom’s weaknesses sufficiently serious that my university—and I—should avoid it? Again, though, this is a question that can’t be answered purely abstractly. Let me draw on some definitions from a National Academies report that I worked on:

A “vulnerability” is an error or weakness in the design, implementation, or operation of a system. An “attack” is a means of exploiting some vulnerability in a system. A “threat” is an adversary that is motivated and capable of exploiting a vulnerability.

There are certainly vulnerabilities in Zoom, as I and others have discussed. But is there a threat? That is, is there an adversary who is both capable and motivated?

In Thinking Security, I addressed that question by means of this diagram:

Are you being targeted? And how good is the attacker?

Let’s first consider what I called an egregious flaw in Zoom’s cryptography. In my judgment (and as I remarked in that blog post), “I doubt if anyone but a major SIGINT agency could exploit it.” That’s already a substantial part of the answer: I’m not worried about the Andromedan cryptanalysts trying to learn about my students’ personal tragedies. Yes, I suppose in theory I could have as a student someone who is a person of interest to some foreign intelligence agency and this person has a problem that they would tell to me and that agency would be interested enough in blackmailing this student that they’d go to the trouble of cryptanalyzing just the right Zoom conversation—but I don’t believe it’s at all likely and I doubt that you do. In other words, this would require a highly targeted attack by a highly skilled attacker. If it were actually a risk, I suspect that I’d know about it in advance and have that conversation via some other mechanism.

The lack of end-to-end encryption is a more serious flaw. To recap, the encryption keys are centrally generated by Zoom, sometimes in China; these keys are used to encrypt conversations. (Zoom has replied that the key generation in China was an accident and shouldn’t have been possible.) Anyone who has access to those keys and to the ciphertext can listen in. Is this a threat? That is, is there an adversary who is both motivated to and capable of exploiting the vulnerability? That isn’t clear.

It’s likely that any major intelligence agency is capable of getting the generated keys. They could probably do it by a legal process if the keys are generated in their own country; alternatively, they could hack into either the key generation machine or any one of the end-points of the call—very few systems are hardened well enough to resist that sort of attack. Of course, the latter strategy would work just as well for any conceivable competitor to Zoom—a weak end-point is a weak end-point. There may, under certain circumstances, be an incremental risk if the hosting government can compel production of a key, but this is still a targeted attack by a major enemy. This is only a general technical threat if some hacker group had continuous access to all of the keys generated by Zoom’s servers. That’s certainly possible—companies as large as Marriott and Nortel have been victimized for years—but again, this is the product of a powerful enemy.

There’s another part of the puzzle for a would-be attacker who wants to exploit this flaw: they need access to the target’s traffic. There are a variety of ways that that can be done, ranging from the trivial—the attacker is on-LAN with the target—to the complicated, e.g., via BGP routing attacks. Routing attacks don’t require a government-grade attacker, but they’re also well up there on the scale of abilities.

What it boils down to is this: exploiting the lack of true end-to-end encryption in Zoom is quite difficult, since you need access to both the per-meeting encryption key and the traffic. Zoom itself could probably do it, but if they were that malicious, you shouldn’t trust their software at all, no matter how they handled the crypto.

There’s one more point. Per the Citizen Lab report, “the mainline Zoom app appears to be developed by three companies in China” and “this arrangement could also open up Zoom to pressure from Chinese authorities.” Conversations often go through Zoom’s own servers; this means that, at least if you accept that premise, the Chinese government often has access to both the encryption key and the traffic. Realistically, though, this is probably a niche threat—virtually all of the new Zoom traffic is uninteresting to any intelligence agency. (Forcing military personnel to sit through faculty meetings probably violates some provisions of the Geneva Conventions. In fact, I’m surprised that public universities can even hold faculty meetings since, as state actors, they’re bound by the U.S. constitutional prohibition against cruel and unusual punishment.) In other words: if what you’re discussing on Zoom is likely to be of interest to the Chinese government, and if the assertions about their power to compel cooperation from Zoom are correct, there is a real threat. Nothing that I personally do would seem to meet that first criterion—I try to make all of my academic work public as soon as I can—but there are some plausible university activities, e.g., development of advanced biotechnology, where there could be such governmental interest.

There’s one more important point, though: given Zoom’s architecture, there’s an easy way around the cryptography for an attacker: be an end-point. As I noted in my previous blog post about Zoom,

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.

That is, simply join the call. Yes, everyone on the call is supposed to be listed, but for many Zoom calls, that’s simply not effective. Only a limited number of participants’ names are shown by default; if the group is large enough or if folks don’t scroll far enough, the addition will go unnoticed. If per the above, Zoom is malicious or has been pressured to be malicious, the extra participant won’t even be listed. (Or extra participants—who’s to say that there aren’t multiple developers in thrall to multiple intelligence agencies? Maybe there’s even a standard way to list all of the intercepting parties?

struct do_not_list {<br />     char *username;<br />     char *agency;<br /> } secret_users[] = {<br />     {"Aldrich Ames", "CIA"},<br />     {"Sir Francis Walsingham", "GCHQ"},<br />     {"Clouseau", "DGSE"},<br />     {"Yael", "Mossad"},<br />     {"Achmed", "IRGC"},<br />     {"Vladimir", "KGB"},<br />     {"Bao", "PLA"},<br />     {"Natasha", "Pottsylvania"},<br />     ...<br />     {NULL, NULL}<br /> };

The possibilities are endless…

Let me stress that properly authenticating users is very important even if the cryptography was perfect. Let’s take a look at a competing product, Cisco’s Webex. They appear to handle the encryption properly:

Cisco Webex also provides End-to-End encryption. With this option, the Cisco Webex cloud does not decrypt the media streams, as it does for normal communications. Instead, it establishes a Transport Layer Security (TLS) channel for client-server communication. Additionally, all Cisco Webex clients generate key pairs and send the public key to the host’s client.

The host generates a symmetric key using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG), encrypts it using the public key that the client sends, and sends the encrypted symmetric key back to the client. The traffic generated by clients is encrypted using the symmetric key. In this model, traffic cannot be decoded by the Cisco Webex server. This End-to-End encryption option is available for Cisco Webex Meetings and Webex Support.

The end-points generate key pairs; the host sends the session key to those end-points and only those end-points.

Note what this excerpt does not say: that the host has any strong assurance of the identity of these end-points. Do they authenticate to Cisco or to the host? The difference is crucial. Webex supports single sign-on, where users authenticate using their corporate credentials and no password is ever sent to Cisco—but it isn’t clear to me if this authentication is reliably sent to the host, as opposed to Cisco. I hope that the host knows, but the text I quoted says “all Cisco Webex clients generate key pairs”, and doesn’t say “all clients send the host their corporate-issued certificate”. I simply do not know, and I would welcome clarification by those who do know.

Though it’s not obvious, the authentication problem is related to what is arguably the biggest real-world problem Zoom has: Zoombombing. People can zoombomb because it’s just too easy to find or guess a Zoom conference ID. Zoom doesn’t help things; if you use their standard password option, an encoded form of the password is included in the generated meeting URL. If you’re in the habit of posting your meeting URLs publicly—my course webpage software generates a subscribable calendar for each lecture; I’d love to include the Zoom URL in it—having the password in the URL vitiates any security from that measure. Put another way, Zoom’s default password authentication increases the size of the namespace of Zoom meetings, from 10⁹ to 10¹⁴. This isn’t a trivial change, but it’s also not the same as strong authentication. Zoom lets you require that all attendees be registered, but if there’s an option by which I can specify the attendee list, I haven’t seen it. To me, this is the single biggest practical weakness in Zoom, and it’s probably fixable without much pain.

To sum up: apart from Zoombombing, the architectural problems with Zoom are not serious for most people. Most conversations at most universities are quite safe if carried by Zoom. A small subset might not be safe, though, and if you’re a defense contractor or a government agency, you might want to think twice, but that doesn’t apply to most of us.

That the threat is minimal, absent malign activity by one or more governments does not mean that Zoom and its clients can’t do things better. First and foremost, Zoom needs to clean up its act when it comes to its code. The serious security and privacy bugs we’ve seen, per my blog post the other day and a Rapid7 blog post, boil down to carelessness and/or a desire to make life easier for users, even at a significant cost in security. This is unacceptable, Zoom should have known better, and they have to fix it. Fortunately, I suspect that most of those changes will be all but invisible to users.

Second, the authentication and authorization model has to be fixed. Zoom has to support lists of authorized users, including shortcuts like “*@columbia.edu”. (If it’s already there, they have to make the option findable. I didn’t see it—and I’m not exactly a technically naive user…) Ideally, there will also be some provision for strong end-to-end authentication.

Third, the cryptography has to be fixed. I said enough about that the other day; I won’t belabor the point.

Finally, Webex has the proper model for scalable end-to-end encryption. It won’t work properly without proper, end-to-end authentication, but even the naive model will eliminate a lot of the fear surrounding centralized key distribution.

In truth, I’d prefer multi-party PAKE, at least as an option, but it’s not clear to me that suitably vetted algorithms exist. PAKE would permit secure cryptography even without strong authentication, as long as all of the participants shared a simple password. In the original PAKE paper, Mike Merritt and I showed how to build a public phone where people could have strong protection against wiretappers, even when they used something as simple as a shared 4-digit PIN.

There are things that Zoom’s customers can do today. Zoom has stated that

an on-premise solution exists today for the entire meeting infrastructure, and a solution will be available later this year to allow organizations to leverage Zoom’s cloud infrastructure but host the key management system within their environment. Additionally, enterprise customers have the option to run certain versions of our connectors within their own data centers if they would like to manage the decryption and translation process themselves.

If you can, do this. If you host your own infrastructure, attackers will have a much harder time—you can monitor your own site for nasty traffic, and perhaps (depending on the precise requirements from Zoom), you can harden the system more. Besides, at least for Zoom meetings where everyone is on-site, routing attacks will be much harder.

Finally, enable the security options that are there, notably meeting passwords. They’re not perfect, especially if your users post URLs with embedded passwords, but they’re better than nothing.

One last word: what about Zoom’s competitors? Should folks be using them instead? One reason Zoom has succeeded so well is user-friendliness. In the last few weeks, I’ve had meetings over Zoom, Skype, FaceTime, and Webex. From a usability perspective, Zoom was by far the best—and again, I’m not technically naive, and my notion of an easy-to-use system has been warped by more than 40 years of using ed and vi for text editing. To give just two examples, recently, a student and I spent several minutes trying to connect using Skype; we did not succeed. I’ve had multiple failures using FaceTime; besides, it’s Apple-only and (per Apple) only supports 32 users on a call. There’s also the support issue, especially for universities where the central IT department can’t dictate what platforms are in use. Zoom supports more or less any platform and does a decent job on all of them. Perhaps one of its competitors can offer better security and better usability—but that’s the bar they have to clear. (I mean, it’s 2020, and someone I know had to install Flash(!) for some online sessions. Flash? In 2020?)

I’d really like Zoom to do better. To its credit, the company is not reacting defensively or with hostility to these reports. Instead, it seems to be treating these reports as constructive criticism and is trying to fix the real problems with its codebase while pointing out where the critics have not gotten everything right. I wish that more companies behaved that way.