Zoom Finally Moves To End-to-End Encryption: And Takes Security Seriously

I have spent a good deal of my time on Zoom over the past few weeks, and when I use WebEx or Teams, it just does feel the same. But…

Zoom Finally Moves To End-to-End Encryption: And Takes Security Seriously

And the security gasped and laughed out loud, when they found that Zoom setup a server on your computer, and allowed anyone to connect to it. Zoom fixed it, quickly, as it was as bad as it gets for security.

And the security community laughed when it was found that Zoom was using AES ECB (Electronic Code Book). Not even a first year computer security student would ever go near that!

And then they laughed again, when Zoom produced a little icon that said “End-to-end encryption”, where all it was, was a standard TLS tunnel. What if someone setup a proxy on your machine, or an untrusted Zoom client? They just didn’t get it!

The development team at Zoom just couldn’t be trusted for proper security. But when the UK Government and Cabinet starts to use Zoom for their video conferences, you really need to up your game in terms of proper security. Zoom were obviously great with their back-end services and with their user interface, but they were “perhaps” novices when it came to core security?

Go get great crypto people, who are trusted

So I have spent a good deal of my time on Zoom over the past few weeks, and when I use WebEx or Teams, it just does feel the same. But, Zoom’s success have made them a target, and over the weeks there has been a continual upgrading of security. So, what should Zoom do to make sure that things are done correctly? Well, one solution is to bring in trusted heavy weight academics, as they will be trusted to make sure that Zoom does not slip-up in their implementation.

Two of the best crypto academics around are Matthew Green (John Hopkins University) and Alex Stamos (Stanford University). They are two of the most trusted cryptography researchers, and have a long track record within academic research.

And, so, from Zoom saying they were using end-to-end encrytion, when they were not, they finally seems to be taking security seriously [here]:

The great thing about this paper — and typical for one which involves academics — is that possible weaknesses on the methods are identified, in order to highlight possible flaws. This is a refreshing approach from a company with such a poor track record of saying … “everything is fixed”.

At the current time, the identity of users is fairly lose, and where they identify themselves to Zoom using login IDs. The paper outlines a number of phases for the upgrading of the platform towards end-to-end encryption:

  • Phase 1 — Public key management. With this each client will have a long term key pair, and where the private key is kept secret. Then clients will be able to generate their own session key without a server getting involved. In this way identities will be mapped to public keys. A fake key could still be used, but Zoom says that it will be possible to register a public key using “meeting security code”, and which would allow the verification of the public key of another client. This overcomes the meddler-in-the-middle problem, and where Eve is a proxy for Bob’s host.
  • Phase 2 — Identity. This will support a Single-Sign-On (SSO) with an identity provider, and in order to assign the public key to a user. Again there would be no need to authenticate through the Zoom servers.
  • Phase 3 — Key signing. This will support Zoom (and other SSO providers) to sign all the keys used by users. In this phase it will also be possible for a meeting lead to upgrade a whole meeting to end-to-end encryption.
  • Phase 4 — Strong enforcement. In this phase a strong enforcement of key signing will be introduced, and where Bob will not be able to connect to Alice, until he has proven his identify and his associated keys.

The Zoom package will be upgraded to have an “end-to-end security” option. At present, the encryption key is generated by a meeting key. In the new design it will be up to the Zoom clients to negetiate the shared key, and for it not be distributed by the Zoom servers. In this case, there will be no encryption key content held on Zoom’s servers.

In most cases Zoom will use Curve 25519, such as with Diffie-Hellman over Curve25519, and EdDSA over Ed25519. But these are not FIPS certification approved, so there’s a fall-back to ECDSA and ECDH over curve P-384. So signatures we generate a public key (vk_EdDSA) and a private key (sk_EdDSA):

  • EdDSA.KeyGen() → (vk_EdDSA, sk_EdDSA). Generates an EdDSA keypair.
  • EdDSA.Sign(sk_EdDSA, M ) → SigEdDSA. Computes an EdDSA signature.
  • EdDSA.Verify(vk_EdDSA, M, SigEdDSA) → (true, false). Verifies an EdDSA signature [here].

For key exchange, Zoom will typically use DH over Curve 25519, and where Bob and Alice generate a key pair:

  • GenCurve25519Keypair() → (pk_25519, sk_25519). Generates a Curve25519 Diffie-Hellman keypair.
  • DH(sk_A_25519, pk_B_25519) → SS_25519.
  • DH(sk_B_25519, pk_A_25519) → SS_25519 [here].

Once the session key is created, Zoom then uses AES GCM encryption using:

  • AES-GCM-ENC(K, IV, M ) → C. With a message to send, encrypt with GCM using the salt value (IV) and key (K)
  • AES-GCM-DEC(K, IV, C) → M . Decrypt cipher with the IV and key (K) [here].

The GCM mode is used, as it is a stream cipher which allows for parallel processing of the encryption and decryption processing. The key is generated using HKDF (HMAC-based Extract-and-Expand Key Derivation Function) [here]. There is also a dual signing process that integrates ECDSA and EdDSA. To generate the required keys:

  • (vk EdDSA, sk EdDSA) ← EdDSA.KeyGen().
  • (vk ECDSA, sk ECDSA) ← ECDSA.KeyGen().
  • (vk DualSign, sk DualSign) ← ((vk EdDSA, vk ECDSA), (sk EdDSA, sk ECDSA)).

And then to create the dual signature:

  • SigEdDSA ← EdDSA.Sign(sk_EdDSA, M ).
  • SigECDSA ← ECDSA.Sign(sk_ECDSA, M ).
  • SigDualSign ← (M, SigEdDSA, SigECDSA).

The dual signature is then checked with:

  • Parse vk DualSign as ((vk_EdDSA, vk_ECDSA), (sk_EdDSA, sk_ECDSA)).
  • Parse SigDualSign as (M, SigEdDSA, SigECDSA)).
  • r1 ← EdDSA.Verify(vk EdDSA, M, SigEdDSA).
  • r2 ← ECDSA.Verify(vk ECDSA, M, SigECDSA).
  • If r1 and r2 are true, the signature is correct.

The following outlines the setup, and where Bob and Alice generate their identities, and make these to a key pair. Alice proves herself with her public key, and Bob proves his identity with his public key. Once the keys are trusted, they can then negitiate the session keys, without the need for the Zoom server:

Conclusion

Zoom have done the right thing, and employed two leading academics, and which will increase the levels of trust involved. I find WebEx almost unusable … doesn’t Cisco have a UX team?