If I'm honest and I'm working on a video conferencing platform, a potential customer asks "Do you have End-to-end encryption?". I say honestly "No". The customer goes to Zoom because they lied and said they do. Any outcome where Zoom keeps even _some_ of the resulting customers and money rewards deceit and ensures you'll get worse products in future because a worse product was given a leg up by lying. That's where we are today.
Silence detection (and a bunch of related problems) should be solved by using Constant Bitrate (CBR) encoding. The analysis linked says SILK was used, which was conceived as primarily a Variable (VBR) encoding but it doesn't go into enough depth to be sure whether VBR is in play here, though it's hard to give Zoom benefit of the doubt.
On the video side you can play sensor noise off against video codec optimisations. If you're sure the bottom 1-2 bits on a video conference camera feed is noise, the people writing the optimised live video encoder probably agree and aren't sending those bits anyway (you can synthesise noise perfectly well without sending it), so it's a wash.
And also though I agree it's not where you'd start do not rule out attackers controlling the plaintext - the "virtual pub" I attended a few hours ago with friends had a third party video playing, and sometimes people share their slide decks by video in corporate or government environments. It's definitely more practical to sneak deliberately watermarked video into someone's Zoom conference than to, as we worried about for disk encryption, get them to stash megabytes or gigabytes of carefully watermarked files on a drive.
I will say in passing that it's weird to keep picking VBR AAC in your examples, the document says they used SILK, which would make sense because SILK was designed (by Skype many years ago) for this application. AAC is from a different era (it turns out we were trying to be too clever back then) and targets a different application.
This bothers me because even if ECB was good enough here, which we're both agreed it isn't, encrypted SILK VBR is anyway specifically known to be vulnerable to the same approach they demo'd in "Spot Me if You Can" and similar papers:
https://ieeexplore.ieee.org/document/4531143
Keep in mind that even without any cryptographic work, we know the exact length in bytes (just like in that paper) of every SILK frame on the wire.
As to the cryptography:
I think the first thing I'd do if I was trying to turn this into an attack would be to send gibberish to Zoom's intermediary servers and see if they care (thus function as a potential Oracle).
You know more about the codec situation here than I do. So, you tell me! What should I be looking at?
Where are you getting this recommendation? Who recommended it - to Zoom? And when?
> You know more about the codec situation here than I do. So, you tell me! What should I be looking at?
If you're prepared to be at least slightly interested in problems even if ECB only contributes rather than blowing them wide open, then maybe you should look at H.264 I-frames first.
An I-frame stands on its own. For example the WebP image format is essentially just one I-frame from VP8. If the scene is literally unchanged from one I-frame to the next, all the exact same image data must be re-encoded, and logically (if the codec is at all efficient) that means the same bytes.
[ If you just don't use I-frames then all loss becomes unrecoverable and people will stop saying your product "Just works". In products like a DVD or Netflix I-frames are needed to make it "seekable". This is obviously not a necessity in a video conference, but the ability to handle network glitches and to add/ remove participants seamlessly is a requirement ]
So with ECB for I-frames clearly we can tell if nothing changed. Maybe an artificially lit meeting room with nobody in it, a desk left unmanned. Or a screen share left showing an unchanging desktop. Is that a "useful" thing for eavesdroppers to learn? Do you think Zoom users would be surprised that eavesdroppers can tell their colleagues took a coffee break?
But because codecs like H.264 are oriented around square blocks I suspect we can do better. They're not deliberately trying to have these blocks encode to exactly 16 bytes and so mostly they won't, but of course one chance in 16 isn't nothing and we get to try every I-frame. Probably not to the point of getting a blocky outline of a moving person on a stream (which is sad because I'm pretty sure that, like the Penguin, would make the point viscerally) but enough to have some idea which parts of a scene (or a slide deck) are changing.
Isn't an important part of the argument that the point the penguin 'makes viscerally' is actually an extremely narrow, relatively uninteresting one? It tells you something like 'certain types of synthetic images represented entirely uncompressed in the spatial domain are obviously super leaky when ECB-mode encrypted'. Which, you know, neat but nobody does that.
It seems extra-uninteresting compared to things like 'plaintext can be recovered from encrypted realtime VBR-encoded audio'.
In that context 'I-frames might be both identical and magically align' seems even more contrived than the already more-famous-than-informative penguin.
> In that context 'I-frames might be both identical and magically align' seems even more contrived than the already more-famous-than-informative penguin.
Did you take a look at an actual H.264 video stream of something boring?
I downloaded a random example of an H.264 video of the generic movie lead-in you've seen a million times where giant numerals appear in descending sequence. The sequence repeats itself several times, allowing us to compare I-frames each time.
Let me quote from the first time a giant numeral two is displayed - briefly in hexadecimal:
> fc fe 7f 3f 9f cf e7 f3 f9 fc fe 7f 3f 9f cf e7
That's not encrypted, but on the other hand I also don't understand what it means because I am not an H.264 decoder. So an ECB encoded block would be just as meaningful to me.
Of course, we'd only get the same exact ECB encoded block if the input was the same... a few seconds later another I-frame of the same giant numeral two and:
> fc fe 7f 3f 9f cf e7 f3 f9 fc fe 7f 3f 9f cf e7
Ah. Well, maybe it's just a fluke? A few seconds later the same number is featured in the I-frame again and...
> fc fe 7f 3f 9f cf e7 f3 f9 fc fe 7f 3f 9f cf e7
Maybe I got real stupid in my old age but I think what's going on here is exactly what I already told you to expect. Given the same input the H.264 I-frame encoded is identical or at least so very similar as to be full of the same 16-byte sequences. Actually it's mostly 9-byte sequences, it's just that it needs so very, very many of them to encode an I-frame that statistically producing a recurring 16-byte sequence was almost inevitable.
Let me be clear here: I don't understand H.264 well enough to align this naturally frame aligned, I just took the raw data and pretended it was already 128-bit aligned because that logically cannot be worse than what you'd get if you knew what you were doing. I would be astonished if somebody who actually knows what they're doing can't get much better results from this.
I can H.264 a series of images with solid-colored blocks and not see repeats. But who knows if my codec test harness is representative? I very much doubt it is. I'm certain that there are cases where there are not just collisions, but useful collisions. Let's understand what they are.
This isn't "vulnerability Olympics". It's simply about understanding what we are discussing.
http://demo.nimius.net/video_test/videos/test.mp4
This file contains audio, which in the Zoom pseudo-RTP is separate so you should strip that out with your preferred tool without changing the H.264 video though it won't change the results very much (it only re-assures us that the recurring data is in the video stream as I assumed) so if you don't have such tools don't worry too much.
It has the case we're interested in, because it's the simplest to understand: I-frames with identical content.
If you've put together a "codec test harness" that's what you want to simulate. Don't feed in penguins or "solid-coloured blocks" just feed in a still image, and watch as (unsurprisingly) it outputs the same I-frame each time it needs to do so, regular as clockwork. You're not simulating a Zoom stream of abstract art, but a shared desktop that's showing Pauline's Q3 revenue forecast for two whole minutes while her team discuss Tiger King or the desktop of a guy who left five minutes ago but didn't leave the meeting, or (more speculatively) an empty meeting room on camera.
This is the beginning. If we stop dismissing it as just "more complicated" than just a Penguin pixmap and bring in people who know more about video codecs we can explore how much more can be done. If every slide show has the company logo and the presenter's name on the first slide, does that correlate? Can we make a watermark that would survive being played back through one codec and then encoded by Zoom?
But there's a strong sense in which I don't care to do all that actual work. Some of these things might be possible and some not, but we're not building a cool demo for a convention we're just here to say that Zoom is terribly insecure and if people feel they must use it, treat it like a meeting held in the local coffee shop, assuming your local coffee shop is bugged by both the US and Chinese government.
04608c1c211004608c1c00000007419b: 4 samples
1004608c1c211004608c1c0000000741: 4 samples
0963211004608c1c211004608c1c0000: 5 samples
33c00963211004608c1c211004608c1c: 5 samples
63211004608c1c211004608c1c000000: 5 samples
f7df7df7df7df7df7df7df7df7df7df7: 5 samples
0001000003ff0000000e000004000000: 6 samples
211004608c1c211004608c1c00000007: 7 samples
c00963211004608c1c211004608c1c00: 8 samples
0001000003ff00000014000004000000: 9 samples
0001000003ff0000000d000004000000: 25 samples
75d75d75d75d75d75d75d75d75d75d75: 31 samples
5d75d75d75d75d75d75d75d75d75d75d: 33 samples
00000b0000000b0000000b0000000b00: 34 samples
d75d75d75d75d75d75d75d75d75d75d7: 34 samples
7f3f9fcfe7f3f9fcfe7f3f9fcfe7f3f9: 39 samples
f3f9fcfe7f3f9fcfe7f3f9fcfe7f3f9f: 40 samples
9fcfe7f3f9fcfe7f3f9fcfe7f3f9fcfe: 42 samples
cfe7f3f9fcfe7f3f9fcfe7f3f9fcfe7f: 42 samples
fcfe7f3f9fcfe7f3f9fcfe7f3f9fcfe7: 42 samples
e7f3f9fcfe7f3f9fcfe7f3f9fcfe7f3f: 43 samples
f9fcfe7f3f9fcfe7f3f9fcfe7f3f9fcf: 43 samples
fe7f3f9fcfe7f3f9fcfe7f3f9fcfe7f3: 46 samples
3f9fcfe7f3f9fcfe7f3f9fcfe7f3f9fc: 47 samples
aebaebaebaebaebaebaebaebaebaebae: 60 samples
baebaebaebaebaebaebaebaebaebaeba: 63 samples
00000000000000000000000000000000: 69 samples
ebaebaebaebaebaebaebaebaebaebaeb: 73 samples
00060000000600000006000000060000: 147 samples
I-frame macroblocks in H.264 are DCT'd, like a JPEG; I have no intuition for what the repeats would signify, except that the encoding is deterministic and, I guess, within an I-frame, stateless? So identical samples will show up in the output?
(It might be easy to instrument an H.264 decoder to get an indication of what frame I'm in when I see a collision, which is I guess what I'll do next).
I don't think it would make a huge difference but the numbers might be higher/more representative. Another way might be to just capture zoom traffic of someone's Quarterly Synergies presentation or whatnot.
Edit: also thought of a silly upper-bound test for Team Penguin - you get plaintext of every colliding block in the stream. How much penguin can you get out of that?
I absolutely agree that the real deserved flak is for saying "end-to-end encryption" when that's clearly not what's happening. Honestly, I don't know how they could make their product work as well as it does with actual end-to-end (consumer to consumer) encryption. Self-hosted solutions can do this but their servers are doing a lot more than ferrying raw data streams around. That's why their meetings work so well with 200+ participants.
They also deserve criticism for saying AES-256 when they're using 128-bit keys, but like you said it's not a security issue. I suppose they could be referring to TLS that they use to set up connections and meetings rather than the stream itself but that's a stretch.
For me, the main reason using ECB makes me distrust a service is that it could be a canary for "we don't have anyone who understands security working here", and it increases my prior that they're also doing other dumb things like reusing keys, or not securely distributing them in the first place.
Lack of end-to-end is bad, but in a situation with more than two participants it's not an easy problem and when some of them are dialing in from landlines then one of your endpoints has to have a key anyway, unless I'm missing something? [edit - was addressed in first paragraph]
Is it conceivable that actual Zoom use cases might allow attackers to do some of these things? I don't have an example in mind, but I'm thinking that the Zoom protocol supports many more actions than just audio and video transmission, so perhaps some of the other protocol features could be exploited for plaintext injection.
For example, Zoom supports text chats, and some kind of metadata information about participants and call setup. Perhaps those are all directly encrypted under the same key with the same block cipher mode?
The trick with ECB is that you're relying on 128-bit blocks of plaintext repeating with perfect alignment, and, to do anything useful with it, those repeats leaking useful information. In a bitmap image of a penguin, those repeats are easy: they're blocks of pixels of uniform color, and all ECB is doing is permuting their colors. That's less intuitively true of audio (where I'm not really seeing repeats at all, but, again, you should just play with it).
Um, so, just to make sure I understand you, you're implying that lossy compression is not worth its salt? Because you will surely have more repeats in a lower entropy space.
1) "likely" != "guaranteed to"
2) If there's sensor noise when you're sharing your screen, then you're doing something horribly horribly wrong
Like setting a custom, static background? One of zooms fun features.
People are dunking on Zoom for rolling their own crypto and coming up with AES-128-ECB. This is also bad, but people should be aware that it's a lot more complicated than "you can see penguins through it".
You can see penguins through an ECB-encrypted bitmap because discrete blocks of the bitmap image repeat, and thus have the same ciphertext, and these correspondences carry obvious meaning in a bitmap. The same is not automatically true of video or audio data with normal codecs. Aaron Toponce points out that sensor noise will likely scramble ECB ciphertexts, for instance.
Colm MacCárthaigh makes an even more important point, which is that it's already very trick to reliably encrypt voice tracks, because common encoding and transmission techniques make them susceptible to traffic analysis. So, for instance, you can quickly find papers about exploiting silence suppression to make predictions about speech in an encrypted audio channel. The point here being, cryptanalytic attacks on ECB are unlikely to be anyone's first recourse.
Obviously, the 128 bit AES key thing doesn't really have any practical impact.
Designers should religiously avoid ECB mode, but the real danger of ECB is in interactive settings, where we as attackers get to induce plaintext patterns, and use chosen boundaries to isolate targeted ciphertext. Bulk video and audio transmission isn't that kind of interactive setting. You still don't want to read people saying that ECB is OK; it's bad.
Essentially: it seems like Zoom's cryptography is bad, but not in a way that really matters compared to brochure-level badness of non-end-to-end-encryption.