Bizarre Design Choices in Zoom’s End-to-End Encryption

Zoom recently announced that they were going to make end-to-end encryption available to all of their users–not just customers.

This is a good move, especially for people living in countries with inept leadership that failed to address the COVID-19 pandemic and therefore need to conduct their work and schooling remotely through software like Zoom. I enthusiastically applaud them for making this change.

End-to-end encryption, on by default, is a huge win for everyone who uses Zoom. (Art by Khia.)

The end-to-end encryption capability arrives on the heels of their acquisition of Keybase in earlier this year. Hiring a team of security experts and cryptography engineers seems like a good move overall.

Upon hearing this news, I decided to be a good neighbor and take a look at their source code, with the reasoning, “If so many people’s privacy is going to be dependent on Zoom’s security, I might as well make sure they’re not doing something ridiculously bad.”

Except I couldn’t find their source code anywhere online. But they did publish a white paper on Github…

Disclaimers

What follows is the opinion of some guy on the Internet with a fursona–so whether or not you choose to take it seriously should be informed by this context. It is not the opinion of anyone’s employer, nor is it endorsed by Zoom, etc. Tell your lawyers to calm their nips.

More importantly, I’m not here to hate on Zoom for doing a good thing, nor on the security experts that worked hard on making Zoom better for their users. The responsibility of security professionals is to the users, after all.

Also, these aren’t zero-days, so don’t try to lecture me about “responsible” disclosure. (That term is also problematic, by the way.)

Got it? Good. Let’s move on.

Bizarre Design Choices in Version 2.3 of Zoom’s E2E White Paper

Note: I’ve altered the screenshots to be white text on a black background, since my blog’s color scheme is darker than a typical academic PDF. You can find the source here.

Cryptographic Algorithms

It’s a little weird that they’re calculating a signature over SHA256(Context) || SHA256(M), considering Ed25519 uses SHA512 internally.

It would make just as much sense to sign Context || M directly–or, if pre-hashing large streams is needed, SHA512(Context || M).

At the top of this section, it says it uses libsodium’s crypto_box interface. But then they go onto… not actually use it.

Instead, they wrote their own protocol using HKDF, two SHA256 hashes, and XChaCha20-Poly1305.

While secure, this isn’t really using the crypto_box interface.

The only part of the libsodium interface that’s being used is crypto_box_beforenm(), which could easily have been a call to crypto_scalarmult()instead (since they’re passing the output of the scalar multiplication to HKDF anyway).

Also, the SHA256(a) || SHA256(b) pattern returns. Zoom’s engineers must love SHA256 for some reason.

This time, it’s in the additional associated data for the XChaCha20-Poly1305.

Binding the ciphertext and the signature to the same context string is a sensible thing to do, it’s just the concatenation of SHA256 hashes is a bit weird when SHA512 exists.

Meeting Leader Security Code

Here we see Zoom using the a SHA256 of a constant string (“Zoombase-1-ClientOnly-MAC-SecurityCode“) in a construction that tries but fails to be HMAC.

And then they concatenate it with the SHA256 hash of the public key (which is already a 256-bit value), and then they hash the whole thing again.

It’s redundant SHA256 all the way down. The redundancy of “MAC” and “SecurityCode” in their constant string is, at least, consistent with the rest of their design philosophy.

It would be a real shame if double-hashing carried the risk of invalidating security proofs, or if the security proof for HMAC required a high Hamming distance of padding constants and this design decision also later saved HMAC from related-key attacks.

Hiding Personal Details

Wait, you’re telling me Zoom was aware of HMAC’s existence this whole time?

I give up!

Enough Pointless Dunking, What’s the Takeaway?

None of the design decisions Zoom made that I’ve criticized here are security vulnerabilities, but they do demonstrate an early lack of cryptography expertise in their product design.

After all, the weirdness is almost entirely contained in section 3 of their white paper, which describes the “Phase I” of their rollout. So what I’ve pointed out here appears to be mostly legacy cruft that wasn’t risky enough to bother changing in their final design.

The rest of their paper is pretty straightforward and pleasant to read. Their design makes sense in general, and each phase includes an “Areas to Improve” section.

All in all, if you’re worried about the security of Zoom’s E2EE feature, the only thing they can really do better is to publish the source code (and link to it from the whitepaper repository for ease-of-discovery) for this feature so independent experts can publicly review it.

However, they seem to be getting a lot of mileage out of the experts on their payroll, so I wouldn’t count on that happening.

Like this:

Like Loading...

Related

from Hacker News https://ift.tt/3jzAApO