Zoom strong-armed by US watchdog to beef up security after boasting of end-to-end encryption that didn't exist Zoom has been forced to agree to a range of security improvements in a settlement with America's consumer watchdog, the Federal Trade Commission, as a result of earlier wrongly claiming it offered true 256-bit end-to-end encryption. The pact [PDF], announced Monday, obliges the video-conferencing giant to carry out an annual …
So which video services actually do offer true end-to-end encryption with no man-in-the-middle?
I've been reading through the issues facing Nextcloud Talk and Jitsi. The basic problem seems to be that if the stream is encrypted properly, each client needs a "direct link" with each other client - and this doesn't really scale. NCT claims that you need to budget 1Mbit/s per connected user, which quickly becomes impossible if you're the wrong side of an ADSL connection with a capped uplink speed of 1Mbps.
Google Meet and Zoom seem to work reasonably well down to speeds of 300kbit/s here but this is one stream only outgoing - we were in a Google Meet call with nearly 40 others on Sunday and our upstream bitrate for two connections (don't ask) didn't top 800kbps so obviously Google's doing something in the middle.
Current solutions for scaling seem pretty much all to involve client-server-client connection models, with the server in the middle decoding and routing, pretty much as Zoom does at the moment. Jitsi has plans for some kind of two-layer encryption but I read the notes and still didn't have a clue exactly how that solved the issue.
Any pointers for a good introduction to the subject?
M.
No! If data is decrypted in the middle, it is DEFINITELY NOT end-to-end encryption - even if the middle re-encrypts the data before sending it on.
I don't care how five-eyes may have redifined the term, that's not the way E2E encryption works. I can however see why they want to pretend that it is - because that way they can intercept the data at the server while fooling the plebs that they have secure comms.
With true E2E encryption you do not need to trust the server at all - a MITM attack is simply not possible.
Well, Zoom now says it's doing proper E2EE after earlier trying to claim its use of vanilla TLS was E2E. Here's its statement:
"Zoom’s E2EE offering uses public key cryptography. In short, the keys for each Zoom meeting are generated by participants’ machines, not by Zoom’s servers. Encrypted data relayed through Zoom’s servers is indecipherable by Zoom, since Zoom’s servers do not have the necessary decryption key. This key management strategy is similar to that used by most end-to-end encrypted messaging platforms today."
Take that into account as you will.
C.
"
And what issues verifies that a key can be trusted? Who controls that?
"
All keys are generated ONLY by the computer of the person sending the data. Nobody else is involved at all. So the only person you need to trust is the person you are communicating with. I detailed one possible way of achieving this in an earlier post.
My understanding of public key cryptography is that the "sender" encodes data with the public key of the "receiver" and that this encrypted stream can only be decoded by the private key of the receiver. It relies on that private key staying private.
If that is what Zoom is doing:
...keys...are generated by participants' machines, not by Zoom's serversthen each client must still therefore generate a separate stream for each other client, unless those clients share, and therefore synchronise, both public and private keys. If they do this, then the server which is mediating the call can very easily also be party to the negotiation and gain access to the keys, so you are relying on that server being utterly trustworthy.
As I understand it (and I said I don't really understand it, but I have had a chance to re-read it) the plan by Jitsi is to have the clients agree on a single set of keys with which to encode their video streams but to prevent the server having access to this key (not quite sure how).
In order for the server to be able to route calls, the clients also - individually - set up keys between themselves and the server, and all the server has to do is read, duplicate and route the encrypted streams, without needing, or indeed being able, to decode the streams themselves.
Sounds plausible - it's just the bit about not allowing the server to have access to the shared key that has me scratching my head; how do you do that?
M.
Noting that asymmetric public key cryptography isn't usually used for transmitting data.
It is slow, and vulnerable to analysis if bulk data is transmitted.
Public keys are usually used for the exchange of symmetric keys which are much faster and more secure.
Apologies if this is already stated down thread.
This post has been deleted by its author
Suppose A and B are in a call. Each has published a public key Pa and Pb with private Pa' and Pb'. A each chooses a key Ka and Kb for the streaming cypher. A sends B encrypt(nonce_a1, encrypt( nonce_a2, Ka, Pa), Pb). B sends A encrypt(nonce_b1, encrypt(nonce_b2, Kb, Pb), Pa). When A receives B's message, A sends B encrypt(nonce_a3, nonce_a2 || Ka, Pb). When B receives A's message, B sends a encrypt(nonce_b3, nonce_b2 || Kb, Pb). A then verifies that encrypt(nonce_b2, Kb, Pb) matches what was first sent. Likewise for B.
The agreed key is Ka xor Kb.
If the key generation for one is weak, the other strengthens it.
Whoever controls the public key infrastructure still controls this. Given it's a private company's solution, and they aren't registering people as domain names, how do you think this is actually happening in a way that couldn't easily be broken by the provider?
"Wire" says that separate streams are required for true e2ee in a group chat...
https://medium.com/@wireapp/video-conferencing-end-to-end-encrypted-1270ab1c16fe
However, google says a group can share common keys: https://support.google.com/duo/answer/9280240?hl=en-GB - the main thing is that the shared keys are renegotiated when a user joins or leaves the chat.
Edit: Accidentally posted "anonymous", and trying to fix that using "edit post" doesn't work - "Jamie Jones"
Wire - limited to FOUR participants! Basically too much CPU resource needed to encrypt/decrypt all the streams on all the user gadgets.
If a server can join in, I guess much more can be done to optimize the multiplexed stream, do things like closed captions etc. Without the setup is limited?
IF you could spin up something like Hyper-V Shield VMs or AWS "Nitro Enclaves" in the datacentre per session or at least per org, you'd probably solve the performance issues?
I'd guess your solution would work.. Of course, you'd lose the E2EE then though (how much do you trust your VM hoster etc.?)
An E2EE shared key service would benefit from an external server with bandwidth, because your outgoing data stream will be identical for all recipients and so an external server it can be used to distribute your stream rather than have your home connection feed each client individually itself.
In a true end to end encrypted system, provided the meta data itself isn't considered overly sensitive, you can use third parties to reduce the bandwidth requirements and still be sure that this party can't read your information.
A, B, C and D decide on an encryption key together, this is the really hard part because you need to be certain only those four parties have the key.
Then each of them can connect to server X and send their encrypted video and audio streams there. X will forward those streams to the other parties in the chat, so upload speed requirements are the same no matter how many users there are.
X doesn't have your encryption key, so they're sending this data back and forth blindly, they can't tell what's in it.
If the meta data is important and you don't want anybody to know who is taking to who, things get a lot harder.
The reason most of the open source solutions have those huge bandwidth requirements for multi person conversations is because they don't have a server X to bear that cost for you, you have to send the stream to every person separately.
<I’m not a security expert>
The direct link between E2EE endpoints would be at the session layer not at the network layer. With E2EE, the encryption keys are unique (and secretive) for every send/receive pair. So, the sender has to replicate the outbound stream as many times as there are receivers and each time with the unique key associated with that receiving endpoint. All the replicated streams can be sent to a proxy server at the network layer for forwarding to endpoints but only the sender is capable of creating each receiver’s encrypted stream.
A previous poster mentions an alternate mechanism of choosing a single key amongst N endpoints. That would eliminate the replication problem. I don’t know, but it seems like this requires handshaking between all endpoints to pick an unique secret key. If so, how does it work when a new endpoint wishes to join a session already in progress?
In E2EE communications, the public key crypto is only used to send the actual crypto key to the other end. In a video conference, I imagine that the key is generated on the host's system. Then as each participant joins, they are provided the key using the usual key exchange mechanism. To control bandwidth consumption as each client joins in, the server would probably instruct the clients to use a lower quality video feed because it would be impossible for the server to transcode the video in realtime for each client's camera.
Note that only the encryption must be end-to-end, *not* the path of the communication. The data itself can pass through (and be distributed by) intermediate servers, so long as those servers are only forwarding the data "blind" and cannot themselves decrypt the video.
In other words only the destination end point(s) has the means to decrypt the data that was encrypted by the origin end point.
I've been converting all of my musician and music teacher friends from Zoom and teams to Rock Out Loud Live.
Great audio quality and as low latency as I've seen in any streaming service. They deliberately limit session connections to ensure QOS for small groups as opposed to supporting huge gatherings and live concerts. Very focused in their mission.
They don't advertise and are little known outside of the music teaching community. Won't post their URL here but they are easy enough to find.
So which other video conferencing, collaboration tools are going to receive the same level of third-party security scrutiny?
I would turn this around and sell it as a benefit of the Zoom product and thus encourage the Federal Trade Commission to do similar with the other vendors and establish a full regulatory framework....
"Thanks to the COVID-19 pandemic, Zoom’s user-friendly video conferencing software went from a popular tool to an essential piece of software as people isolated themselves at home – and a household name."
Not really thanks to the pandemic, but thanks to the laziness of the news media. The number of times I've seen the news media refer to a "zoom conference" when the footage shows different software in use is beyond counting. Earlier this year I was working with an organisation which has Microsoft Teams. A departmental manager decided he needed to set up a video conference for a handful of people. Now video wasn't really necessary, but the obsession with video conferencing is something else for which we can blame the news media.* The manager therefore decided he needed to set up a Zoom conference. He was told by his IT department that he and all the rest of the company's staff had Teams installed and Teams would do the job just as well as Zoom. There was a standoff between the manager and the IT department which delayed the conference for a couple of days. This went on until the COO stepped in and told the manager to run the conference on Teams. After the fact though the manager expressed his surprise at how well Teams did the job.
*I know several companies who have had to upgrade infrastructure thanks to the earlier obsession with video conferencing. Of course the shine has now worn off and we are seeing far fewer video conferences than we did a few months ago. Meaning of course that these companies are now left with a recurring bill for infrastructure which is more than they need. Take the organisation I mentioned above, they have a number of offices and a number of remote workers. They have always managed in the past with geographically seperated teams having audio conference calls. Then suddenly thanks to the media's obsession with Zoom many of their staff began to insist on every call from a team meeting to a simple one on one phone call being video. I spoke to somebody at this organisation only last week and was told that the enthusiam for video conferencing had waned by july and things have mostly returned to audio only.
If you are remotely working on your own, there is a huge psychological benefit to interacting with another human face at least occasionally!
All internal calls I do with video, and some (where it has been pre-arranged) with customers (some have security concerns about me seeing their office, and others simply don't have the bandwidth.)
Trouble is that Teams and many other collaboration tools are designed to be used within a single organisation.
Work in an organisation where the norm is to work collaboratively with other organisations (in both ad-hoc and more long-term arrangements) and you can quite quickly find yourself restricted to: phone, email, Zoom, Dropbox...
Mind you, I don't see why the IT department needed to be involved, Zoom like Teams installs in user space... So it would have made more sense for the IT to discover that the reason why Teams isn't being used is because users had voted with their feet and installed Zoom...
Yes the media have played a part in establishing Zoom as the defacto tool, but Zoom took off initially because there wasn't really any other app ready to roll back in March - the media merely picked up the success story and amplified it...
First each participant generates its own public-private key pair, and sends its public key to all the other participants. Next each participant generates its own, random symetrical encryption key (e.g. AES), and sends that key to all the other participants, each encrypted with their respective public keys. Each participant will thus receive the PK-encrypted encryption keys of all other participants which they can decrypt using their respective private keys and store internally. Note all these communications can go via a public server, because the server cannot decrypt any key as it does not have any of the private keys.
After that initial handshaking, the video streaming can take place, with the outgoing video encrypted with the AES key of the participant sending the video. It can be securely sent & distributed via the public server because the server cannot decrypt any of the streams. Each incoming video stream (relayed/distributed via the server) can be decrypted by each participant using the stored key of the participant from which stream originated. Thus Tx bandwidth is just a single video stream which is then distributed by the server - but the Rx bandwidth is that of all streams from the other participants.
To be more secure, AES keys can be changed at regular intervals and all participants updated with the new keys using PK encryption as before.
It's very easy to implement, (easier in fact than SSL), and I don't understand why Zoom did not do this from the start.
Thanks. Sounds good to me and matches the asymmetrical nature of most domestic connections. The only difficulty I'd see is that you need some way of negotiating bandwidth reductions as the number of streams approaches the limit of the slowest downstream connection. Hmmm.
And how does it work with telephone participants? ;-)
M.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
