This is what end-to-end encryption should look like!
BEFORE YOU BEGIN!
Please make sure you check out our post on how end-to-end encryption in general does NOT offer a meaningful level of trust and protection when it comes to modern meetings services.
Also note that e2ee in Jitsi Meet is currently limited to audio, video and screen-sharing. It’s not applied to chat, polls, etc.
Work in Progress!
Some of the people watching our repos have been asking us what the deal was with this little new HIPS project (which by the way stands for Hidden In Plain Sight). Well, now you know! HIPS is about using a new Chrome WebRTC API called “Insertable Streams” to add a second layer of end-to-end encryption to media streams in a way that would make them inaccessible to the video router.
While there is a ton of work left on getting authentication and key distribution to work, the project is already advanced enough for us to engage in two very important steps:
1. Request for Comments
We are calling out to all crypto enthusiasts to have a look tell us if they see anything wrong with what we are doing. The code is here:
https://github.com/jitsi/lib-jitsi-meet/blob/master/modules/e2ee/E2EEContext.js
And here’s an explanation of what we meant to achieve with it:
https://github.com/jitsi/lib-jitsi-meet/blob/master/doc/e2ee.md
2. Demo: end-to-end encrypted calls in Jitsi Meet
In order to try the feature, you can use the End-to-End Encryption option in the overflow menu (bottom right corner of your Jitsi Meeting):
This is already enabled on meet.jit.si and people can try it out if they are using a browser based on Chromium 83 and above (such as the corresponding versions of Edge, Chrome, Opera and Brave).
Now, let’s see exactly how the demo works. In this case, Yana, Fippo and Saúl are having an end-to-end encrypted conversation using the new e2eekey param. At a glance, other than the amazing people on the call, nothing about it seems noteworthy:
Things get interesting when Emil decides to join the call. What he sees in there is just … an endless stream of rubbish:
If Emil was a rogue service provider running the bridge for the meeting, he would no longer be able to eavesdrop on it and an attempt to do so would only yield, well we already said that: an endless stream of rubbish.
The only way for Emil to actually participate in the meeting would be if he was made privy to the e2ee key. In this case he was and once he enters it, everything goes back to normal:
And that’s it! Now everyone sees everyone else and the conversation can continue in full trust and privacy.
So how does all of this work?
Let’s take a step back. We would very likely all agree that we need our meetings to be protected and secure.
Deciding how to protect them, who to protect them from and how exactly to do this is a significantly more complex topic, that we believe everyone in our community should be informed about. We have already discussed how Jitsi Meet gives you protection by using ephemeral rooms and passwords, so no one undesirable can join your meetings, and how all information sent on the network is strongly encrypted using DTLS-SRTP, so that no one who happens to intercept it can actually understand it.
The final piece missing in this puzzle comes from the fact that DTLS-SRTP in WebRTC is strictly tied to a PeerConnection which means that, when using a video router (like Jitsi Videobridge) is involved, WebRTC and DTLS-SRTP can only provide hop-by-hop encryption. In such scenarios Jitsi Videobridge (JVB) ends up establishing as many encrypted channels as there are participants. This is what protects all data on the network. In order for media from one participant to reach another however, it needs to be extracted from the sender’s crypto context and re-encrypted with the receiver’s.
The need to decrypt information while it traverses Jitsi Videobridge, technically provides whoever controls the JVB machine with an opportunity to access the data. They are hence in a position to hear and see everyone on the meeting.
So far, our only answer to this has been that people who feel they cannot trust existing service providers not to eavesdrop on their meetings, can run their own bridges. We spend considerable effort to make sure this is very easy to do, but however much work we throw at streamlining the deployment process it will never be as simple or as hassle-free as a single click on a link.
Insertable Streams in WebRTC
Around three years ago, IETF’s PERC working group (Privacy Enhanced RTP Conferencing) settled on a transport design that could allow a reasonable path to end-to-end encryption (e2ee) in WebRTC conferences. The idea is that rather than try and tweak the existing DTLS-SRTP implementation, conferences can simply add the additional layer of e2e protection on top of the existing one.
The great news is that the approach just became implementable! The Google WebRTC team is currently in the process of adding a brand new feature to the Chromium ecosystem known as Insertable Streams. The feature provides WebRTC apps with access to audio and video frames after they have been encoded but before they have been sent on the network.
Fippo has just published a brilliant description of how insertable streams work in a webrtcHacks post. Do give it a read!
And this, friends, is all we were waiting for! So, we rolled our sleeves and got started.
What’s next: authentication and key management
As we already pointed out, passing keys as URL parameters is a demo thing only. Aside from being impractical it also carries risks given that URL params are stored in browser history.
Our next step is therefore to work out exactly how key management and exchange would work. We expect we will be using The Double Ratchet Algorithm through libolm but the details are still to be ironed out.
The important part is: end-to-end encryption is on its way to protect your Jitsi Meetings. So, stay tuned!
Love,
Your Personal Jitsi Team