
Zoom’s encryption has links to China, researchers discover - ddebernardy
https://theintercept.com/2020/04/03/zooms-encryption-is-not-suited-for-secrets-and-has-surprising-links-to-china-researchers-discover/
======
dang
It seems like the root node of this article graph is
[https://citizenlab.ca/2020/04/move-fast-roll-your-own-
crypto...](https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-
quick-look-at-the-confidentiality-of-zoom-meetings/), which is being discussed
here:
[https://news.ycombinator.com/item?id=22768494](https://news.ycombinator.com/item?id=22768494)

Matthew Green's article is being discussed here:
[https://news.ycombinator.com/item?id=22771193](https://news.ycombinator.com/item?id=22771193)

------
meowface
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.

[https://citizenlab.ca/2020/04/move-fast-roll-your-own-
crypto...](https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-
quick-look-at-the-confidentiality-of-zoom-meetings/)

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.

~~~
fulafel
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.

~~~
cvwright
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.

~~~
doomrobo
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?

~~~
cvwright
> 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.

------
t0mas88
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?

~~~
lozenge
"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

~~~
netsharc
"128 bits, each bit can be 0 or 1, there you go, 256 bits!"

------
itcrowd
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).

[https://blog.cryptographyengineering.com/2011/12/01/how-
not-...](https://blog.cryptographyengineering.com/2011/12/01/how-not-to-use-
symmetric-encryption/)

~~~
ComputerGuru
Who the hell still uses ECB?

~~~
floathub
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.

[edited for typo]

~~~
lawnchair_larry
Your first point is correct, second is definitely not.

~~~
floathub
See how precious little I know about encryption? And yet even I know that ECB
is a terrible choice!

(In minor defense of self, I should have said CBC or "later").

------
_-___________-_
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.

~~~
complex1314
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/](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_...](https://www.reddit.com/r/privacy/comments/7syt0s/jitsi_meet_is_not_e2ee/))

~~~
_-___________-_
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.

~~~
notechback
But it only works if everyone has Apple devices, so it absolutely does not
"just work" if even one family member doesn't have it.

Most video chat apps are straightforward once set up on the phone.

~~~
_-___________-_
Are you aware of other video chat apps that support e2e-encrypted multi-party
videoconference?

~~~
zeveb
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.

------
jalk
OT: My kids school uses zoom atm. Been connecting using the web client at
[https://zoom.us/wc/join/<meetingid](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.

~~~
mattmcknight
There is a maintenance issue up:
[https://status.zoom.us/incidents/16ll08mmddk6](https://status.zoom.us/incidents/16ll08mmddk6)

~~~
jalk
I know, but my knee still jerked

------
tonyztan
Original title: Zoom's Encryption is “Not Suited for Secrets” and Has
Surprising Links to China

~~~
ddebernardy
Yeah, I only kept the second part of the title when submitting it because it
was a) too long and b) too clickbait-y.

~~~
SAI_Peregrinus
It's using ECB mode. That doesn't even provide confidentiality. "Not suited
for secrets" is entirely correct, and actually somewhat mild.

------
turowicz
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.

~~~
tiborsaas
It is a US company and the founder is american too.

[https://www.bloomberg.com/profile/company/ZM:US](https://www.bloomberg.com/profile/company/ZM:US)

~~~
jplayer01
Aren’t most of their developers in China?

~~~
lain_
I'm not sure if/how that would even matter in the context.

~~~
jplayer01
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.

------
fock
Well, that large majority of developers not is native-speaking seems highly
likely if you only look at output of `zoom.sh` startup script.

No pun intended.

------
dogman144
"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.

~~~
tpetry
Even Wikipedia is stating ECB is a very bad choice. How can someone really use
it nowadays without fraudulent intentions?

~~~
Diggsey
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.

~~~
hiq
Is there a way to use ECB "correctly"?

Is there any non-repeating data apart from noise (if even)?

~~~
Diggsey
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.

~~~
katzenjam
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.

------
t0mas88
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"

------
kerng
It would be good for the title to contain that the encryption they use is
broken.

------
senderista
It’s hard to take the rest of the article seriously when they criticize Zoom
for using 128-bit AES.

~~~
senderista
Downvoters: please name one scenario in which using AES with >128-bit keys
adds any actual security margin, even in principle.

------
aabbcc1241
Why is it surprising ? I heard Zoom is China based dispute it's domain name
has .us

------
Markoff
founder is Chinese, they have 700 employees in China, does anyone really
consider this non Chinese app?

~~~
Markoff
encryption keys issued in China, calls routed through China etc.

I see denial is strong or HN has already it's army of wumaos.

------
AsyncAwait
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.

~~~
petergatsby
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".

------
upofadown
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.

~~~
xtian
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.

~~~
ec109685
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.

~~~
thebean11
That's a much less scary attack vector though, since they would also need to
somehow impersonate the participants voice or image right?

~~~
upofadown
Think of it as aiming a phone at another phone. Apple would decrypt everything
and then reencrypt it.

