I'd recommend reading the original Citizen Lab article as well, which discusses the flaws more specifically. This Intercept article is good, but seems to be aimed at more of a general, less-technical audience.
At the very least, they are validating TLS certificates. (Which I know is the true bare minimum requirement of TLS, but "goto fail" and all...)
>We set up mitmproxy to intercept the TLS traffic and configured the Zoom Linux client to route its TLS traffic through mitmproxy. Fortunately, the Zoom client did appear to warn us that the fake TLS certificates generated by mitmproxy were untrusted.
The CL article seems to be underplaying the vulnerability of ECB, with the "not recommended" description. Any cryptographer will tell you it's downright trivially broken, with textbook practical attacks taught to undergrads.
Is ECB any worse than any other deterministic encryption?
Deterministic encryption can be ok if the data that you’re encrypting is already really random (high min-entropy). Compressed audio and video streams have a decent amount of entropy. Probably not enough to satisfy a cryptographer, but it’s probably enough to make it very difficult to learn much from 128-bit AES ECB blocks.
Note that everyone’s favorite ECB example with the picture of Tux the Linux penguin is not very realistic, because the plaintext is not compressed. If you ECB a JPEG or a PNG, you won’t see the same patterns.
I teach the attacks on ECB in my network security class. It’s bad, but AES is not the Caesar cipher. I’m not sure “trivially broken” is quite right.
That said, I am really curious what Zoom is actually doing here. Going to have to take a look today. My guess is that the real fail from using ECB mode is more likely to come from using it on audio/video metadata, or on other more structured parts of the protocol.
All this is technically true. As long as you believe that you will never ever under any circumstance send the same video chunk twice under the same key, you get all the security guarantees of a real CPA-secure (=> non-deterministic) symmetric cipher. But 1. I don't think this is a reasonable belief, and 2. even if it is, why chance it when you can use CTR mode and a random nonce, with practically zero overhead?
> As long as you believe that you will never ever under any circumstance send the same video chunk twice under the same key
Yes, that is the question here, and it's a really fascinating one. How often do you send two identical 128-bit chunks in practice? How much does it depend on the quality of your webcam and your lighting? If the video is grainy and splotchy in the background, you're getting a lot of randomness in your data. How much does that help? Any at all? Or are you still totally screwed?
> even if it is, why chance it when you can use CTR mode and a random nonce, with practically zero overhead?
1000 times this. Crypto code should be like the safety components in a car or an airplane. You wouldn't buy a car with seatbelts or brakes that work 90% or even 95% of the time. In the same way, you shouldn't write network code that probably doesn't let an adversary figure out everything you're sending.
Note that I was asking specifically about deterministic modes. Those include SIV mode [1] but not the more common CBC, CTR, etc.
Any deterministic encryption relies on entropy of the plaintext for security [2]. This is not unique to ECB.
My objection was to the hyperbolic phrase "trivially broken." SIV mode is deterministic, but nobody who understands what it does would call it "trivially broken."
And I'm definitely not saying that anyone should use ECB. Just that in this case, the vulnerability may not live up to the hype.
By all means, go ahead bashing on Zoom. It's the cool thing to do these days, and clearly they've done enough to deserve most of it.
I'm personally more upset that they're advertising 256bit AES yet using 128bit AES. Sure, 128bit is still fine to use today, but it's still false advertising. They're already falsely claiming end-to-end encryption. It doesn't help that they're using the weakest mode of AES on top of all of this.
If Zoom had a security audit, the auditors would quickly suggest using either some sort of ECB-based algorithm that uses an SIV, or just AES-CTR. I'm guessing they went with ECB due to its parallelization of the encryption/decryption process, which totally makes sense, except that there are much more secure algorithms out there.
This is dangerously wrong. ECB is a non-starter no matter the entropy of the plaintext. Trivially broken is accurate. I hope you are not teaching students that it is ever ok.
The exact same explanation + visual are already in The Intercept's article (and CitizenLab's). The rest of it is flaunting Crypteron's searchable encryption.
And another case of lying in marketing: "A security white paper from the company claims that Zoom meetings are protected using 256-bit AES keys, but the Citizen Lab researchers confirmed the keys in use are actually only 128-bit."
How do they keep doing this? Do they just put whatever sells best in the documents and implement something else? First the end2end thing, now 128 instead of 256 bits. How many more are we going to find in the coming days?
"We never meant to mislead people but we realise we don't use the terminology in the way it is normally understood. We added up the keys on both sides of the conversation to reach 256 bits." Is probably what they'll say
> Do they just put whatever sells best in the documents and implement something else?
Yes.
I've always expected businesses to stretch the truth with their marketing e.g. "Leading Brand of Donut in America", "Award Winning Bread", "Cheapest Gas for 50 miles"
However Zoom are just engaging in straight up false advertising regarding security features. It's not cheeky -- it's wrong.
Hard to say. Could be cultural where sales and engineering butt heads. Could be "sell it first, develop it later so we can beat the market" mentality.
Either way, Zoom is going to go down as either a company that did everything right and won the market or did everything wrong and won the market. Depending on who you talk to.
> Do they just put whatever sells best in the documents and implement something else?
I've worked 10+ years in Silicon Valley and the motto "it is better to beg forgiveness than ask for permission" really does ring true. This manifests at all levels from ICs and up the chain of leadership. People do what gets them their bonus/promotion and everything else be damned. "Acquire the customer and fix the security problem later" was the mindset here.
The story here is that Zoom uses key distribution servers located in China (in addition to several servers in the USA) and that Chinese law might be compelling Zoom to disclose the encryption keys. I think it is a valid concern, but for me it also raises the question of whether this may also be required in the US.
In addition to letting the Chinese (and possibly US) government in on the encryption keys, the encryption scheme is also badly broken (ECB mode of AES). Prof. Matthew Green has written many articles about AES and encryption more generally and I recommend his blog if you are interested (even as a lay person).
They are using EBC mode? I don't know of a single crypto library that would pick that as a default, so someone actually made this decision (like actively lowered encryption capability). I thought of some of the previous issues of not being too bad, but this leaves me wondering...
That is truly amazing. I know precious little about encryption, but I assumed everyone knows that ECB is bad and that CBC is the only sensible way to do AES.
Maybe I've been sensitised by all the security flaws, privacy leaks and outright lies on Zoom's part, but I'm starting to really notice how much a lot of public figures are pushing Zoom.
Does anyone else find it really weird? Late-night TV hosts, I can understand - maybe they just get paid for it, or have Zoom shares. But for example UK government leaders repeatedly mentioning it by name, e.g. Matt Hancock saying that despite being unwell, Boris Johnson is still having "Zoom videoconferences", or saying Johnson addressed his "Zoom cabinet", just feels... weird.
Edited to add: thinking about it more, I remember "FaceTime" being used pretty similarly when it was new. So I guess all the bad news is just sensitising me.
Zoom is popular. Enough that it's both the default for many people and the tech that gets brought up in discussions. My dance school uses zoom. My work uses zoom. Online courses use zoom. Maybe it's more noticeable when famous people mention it, but really - it's a default now. Even if there was some shady push for it, it's also organically massively popular.
trying to download the (self-installing) app twice _every_ time, whilst you're (actively) trying to join a meeting in your browser is the kind of organic popularity the yahoo toolbar had...
you don't say. That way (and autostarting and nagging) you easily get a lot of popularity compared to a web-service (with most people being unaware of bookmarking features in their browser). That was the operating principle of a lot of crappy ad/malware companies back then this was still considered an ethical businessmodel. Seems we are seeing time repeat itself.
Maybe they tried Skype first, which works horrible (tried twice, never managed connect all the participants at the same time), and finally relief over something that actually works. I have used Zoom successfully with 70 participants, and then breakout groups. The only alternative I can see that recently came to my attention is Jitsi Meet (https://jitsi.org/), which I will try next time I have the opportunity. But seems like it has at least one of the same weaknesses as zoom, with no end to end encryption (https://www.reddit.com/r/privacy/comments/7syt0s/jitsi_meet_...)
You can also try BigBlueButton (https://bigbluebutton.org). Open source, and a lot of nice things done better than the usual online meeting standards (e.g. included whiteboard and slides are real slides and watchers have a lot of flexibility in watching them).
As far as I can find out, FaceTime is currently the only solution for "just works" (in the sense that your grandma could use it) videoconferencing that is e2e encrypted.
If there are no cross-platform apps which support e2e-encrypted multi-party videoconferences, then there simply is currently no solution at all for 'just works' secure videoconferencing, because part of just working is not requiring users to switch to a platform they otherwise would not.
It is curious, and post revelations in the recent decade nothing is too weird to suspect - but don't underestimate the immense social value of jumping on the technological bandwagon and the free "hip" PR that it produces in media.
And when more people do it, more people do it, i.e the bandwagon effect.
People then look at the articles written in the media and say "hey i use that app too, cool, we are part of the same tribe".
Showing of knowledge of the tech-zeitgeist is an easy way for a politician or anyone for that matter to appear being both with the times", "tech-savvy" and just the same as regular folk.
OT: My kids school uses zoom atm.
Been connecting using the web client at
https://zoom.us/wc/join/<meetingid without dashes>.
Today however those links are returning 403 Forbidden (even tried multi)
My knee-jerk reaction was that they have some way of capitalizing on installed software which they can't on the web-client. But of course it could simply be that the web-client requires more server resources and now have to curb its usage.
I always knew that the "zoom.us" is a dodgy name for an installation file. As if someone was going an extra length to make sure you think its a US company.
You don’t remember the whole Australia debacle when their government passed a law allowing them to secretly compel software developers to compromise whatever they’re working on? This is basically the same thing, where we know the Chinese government is capable and willing to coerce anybody in their grasp to serve in their interests. Guess where software developers in China happen to live? China. Where can the CCP most easily wield their power and influence? Also China.
Is Eric Yuan a US citizen? He wasn't born or educated here so I don't know he considers himself American, and a significant amount of his company's product development is not done in America.
Before this sounds anti-immigrant, I'm the product of immigrants like most Americans and I think the qualifier for being American is considering oneself American and having citizenship or on the path to get it.
"home grown encryption scheme" seems to imply Zoom is rolling its own crypto, which is tremendously foolish.
That isn't exactly the case, per the same article. More Zoom is choosing a poor choice among other choices, of implementing AES:
"Furthermore, Zoom encrypts and decrypts with AES using an algorithm called Electronic Codebook (ECB) mode, “which is well-understood to be a bad idea, because this mode of encryption preserves patterns in the input,” according to the Citizen Lab researchers. In fact, ECB is considered the worst of AES’s available modes."
Bad idea but not "rolling own crypto bad"
edit: agree it's bad. this is pointing out inaccuracies in language from tech journalism reporting on security. This continues to be an issue per the miseducation it creates for the general public in infosec concepts, which is already an uphill battle of misconceptions. Since these articles, or AG Barr, are the discussions that actually hit the mainstream, it's an issue that needs to correct.ed Tech journalism, a profession focused on 'getting the facts,' are the direct conduit of this version of miseducation/failure of facts, and should be corrected. See: NY Times Baltimore Ransomware = NSA Tool (false), Bloomberg Supermicro (false, so far), etc.
Many of the alternative modes are unsuitable for this case, as it is being used to encrypt UDP packets which may be lost. There are two commonly used modes which support the random access needed here:
- ECB
- CTR
Note that CTR is still recommended for use and is often used for things like hard-disk encryption where random access is required. Furthermore, the only difference between ECB and CTR is that CTR includes an incrementing counter in the input to the encryption algorithm to ensure that each encryption is unique. Do you know what else starts with an incrementing counter? UDP packets intended to form an audio or video stream.
So yes: ECB can be bad, but there's no evidence that Zoom are actually using it incorrectly. Using CTR when you already have a non-repeating data stream would only add overhead and potentially negatively impact the amount of useful data that can be streamed.
Yes, as I mentioned, if you include an incrementing counter within each block then the data does not repeat. The data only needs to be non-repeating within a single stream. Different streams will use a different IV and possibly different keys. This is how CTR works.
Including a counter in each UDP packet does not make ECB mode equivalent to CTR mode.
Let's assume the counter is at the start of the packet. An AES block is 16 bytes, so the counter ensures the first 16 bytes of ciphertext are unique across packets. But any patterns in the remainder of the packet are preserved, within and across packets.
Most of Zoom's security problems seem like the kind of things a novice programmer who didn't know any better would do. Which may mean that they hire inexperienced programmers, or may mean that they wanted that as an excuse if they got caught. The former is probably more likely. After all, never attribute to malice what can adequately be explained by incompetence.
It works like that if you're encrypting a bitmap, but a compressed video stream is already fairly randomised. The encryption is broken, but low-res video extraction seems unlikely.
Keyservers in China may be a risk, but this sounds like a terrible idea: "The researchers also found that Zoom protects video and audio content using a home-grown encryption scheme"
I've really grown to dislike the "China == bad" thing, yes, they're domestically authoritarian, without excusing any of it, I like to act on hard evidence, not hear say, I am stunned that after the Bloomberg fiasco these kind of stories didn't take a hit.
P.S. Personally, I don't consider the NSA having my data as being any better, thank you.
EDIT: Just to be clear, I don't think Zoom's encryption claims should be trusted, but it's not because CHINAAA, it's because they're misleading people into thinking TLS means E2E.
If encryption keys are stored in a country where the company is required, by law or by force, to turn them over to authorities upon request then that should be noted. And yes that includes the US to a lesser degree.
When people say 'the server with the encryption keys is physically located in China, and they have many Chinese employees', the subtext that we should all know at this point is that they're required by Chinese law to turn everything over to the authorities. We have hard evidence & beyond hard evidence of this, so it's kind of assumed that educated people are aware of this. And yes the same goes for say US telecom companies having legally mandated backdoors & the US government exploiting this to conduct unauthorized surveillance or even just purely commercial spying, it's well-documented, everyone should know this. So in the future someone can say 'this telecom company is US-based' and we can all understand the subtext.
So it's OK to just say 'the servers are in China' and we should all know what that means, at this point. TLDR- it's OK to have priors
I've really grown to dislike the "people who presumably consider themselves ethical defending a regime that represses free speech and expression, brutally crushes dissenters, disappears ethical doctors, is led by a 'president for life' dictator, and has literally hauled off 1M muslims to internment campus where their organs are being harvested and their culture is being erased, thing".
OK, this makes things clearer. Zoom does in fact encrypt their streams from client to client but they have easy access to the keys.
In their recent post about this question they apologize for what they admit to be an incorrect use of the phrase "end to end encryption". They base this on the existence of things like the gateways used to the regular telephone network.
It seems like an odd way to spin this. Why didn't they just state that the data is encrypted "end to end" and then leave it at that? Apple supposedly has access to the keys used to encrypt FaceTime calls but they happily involve the "end to end encryption" marketing phrase. I don't see why Zoom couldn't do the same. The way Zoom has handled this could of been a lot better.
I think the world needs a consumer standard for cryptography. Something like:
* Level 1 for the case where any eavesdropper can get the plain text.
* Level 2 for when just the provider can get the plain text.
* Level 3 for when just the users can get the plain text.
Most of what is being described as "end to end encrypted" these days is really just level 2 even in the case where the provider does not have the keys due to the fact that the provider can trivially MITM the traffic. The general public should be made aware of the distinction without having to dig into the technical details.
Apple does not have access to FaceTime keys or iMessage keys for that matter. They are truly end-to-end encrypted, and I don’t think there is any need to cheapen or muddy the term for the sake of marketers.
They can still write software to insert themselves into the key exchange flow and eavesdrop on a conversation. E.g. I don’t believe there is anything stopping Apple from pretending a participant bought a new device.
Perhaps as that was based on random internet comments. FaceTime still ends up at level 2 with Zoom and the rest because Apple can MITM the traffic without much trouble. There is no provision for the user to prevent/detect a MITM attack in FaceTime or iMessage.
So you’re saying there should be a three-level consumer standard where the third level excludes any possible consumer product? Please don’t pretend that Apple and Zoom’s approaches are equivalent here. There is a substantial difference that deserves to be acknowledged. Anyone whose threat model includes Apple subverting their own security architecture shouldn’t be using any communication platforms.
Matthew Green's article is being discussed here: https://news.ycombinator.com/item?id=22771193