Earlier today, Lifesize announced the upcoming release of end-to-end encryption (E2EE) for group video conferencing meetings. This will include full, E2EE for all meetings on the Lifesize cloud service, including those where a subset or all participants join using Lifesize’s family of 4K meeting room systems. Once fully implemented, all Lifesize customers – whether on subscription or free plans – will be able to choose whether to encrypt their video meetings end to end.

Jim Lundy, founder and lead analyst at Aragon Research, does an admirable job contextualizing the news for us: “The rapid shift to remote work and the hybrid in-office/distributed teams model brought video conferencing security and encryption to the forefront of business leaders’ and technology decision makers’ minds. Lifesize rolling out end-to-end encryption for group meetings is the right move for its customers, partners and the industry at-large.”

Given recent news coverage and considerable interest in security features supported by video conferencing service providers, our intent is to be fully transparent and open about our approach and address any questions about how we’re implementing E2EE so that we can get feedback from customers, researchers and the broader community while we finalize the implementation.

Building on the Strengths of Lifesize’s Architecture

As we’ve highlighted previously, Lifesize’s video infrastructure is built atop WebRTC, both our software clients (desktop, mobile and web apps) and endpoint meeting room devices. This allows us to ride the wave of the larger WebRTC open source community in releasing features and keeping our platform secure. Let’s take a technical look at how that specifically applies to E2EE.

WebRTC has introduced a concept called Insertable Streams. This allows us to modify the media stream both at egress and ingress using a JavaScript worker, giving us the opportunity to apply encryption and decryption. Fortunately, Insertable Streams makes this step fairly trivial for any technology with WebRTC underpinnings. To demonstrate how this works, I’ve taken a sample bit of code and changed it to add AES encryption in a simple sandbox: https://github.com/bobby-beckmann/samples.

Of course, the E2EE challenge has two other parts that need solving. First, key exchange. How do we securely send keys to new participants in a meeting? Again, fortunately, there are browser technologies that make this an approachable problem with just a little bit of code. Here’s an example piece of code that demonstrates a simple Elliptical-curve Diffie-Hellman key exchange: https://github.com/bobby-beckmann/keyshare. (If you’re interested in more on how that works, further reading is available.)

Authentication: The Overlooked Encryption Element

The final E2EE component to solve for is how to authenticate that the person you’ve exchanged keys with during the meeting is, in fact, who they say they are. When you read about leading approaches to end-to-end encryption in the messaging space, Signal is often referenced. It has an excellent implementation, and it has a method for out-of-band verification of the party on the other end of the message. I’ll admit that I use Signal but have never actually gone through the verification step to ensure that there is no party in the middle watching my messages. At Lifesize, we’ve been considering how we might offer an authentication step that would be accessible to end users but provide a higher level of security.

We’re unofficially calling our method the Lifesize Codeword. The Lifesize Codeword is a pronounceable fake word that is created on the fly using your public key as a seed for a random number generator. (You can see this generated in the GitHub repository above.) We then take this Codeword and use it for authentication. You’ll know your own Codeword and it will be added as a watermark in your video stream by the client. The other meeting participants will also have your public key and can thus generate the same Codeword. This word will be shown underneath your video feed for quick visual confirmation. You’ll also be able to compare it via audio or out-of-band communication.

More Security Mechanisms to Come

We will offer more traditional PKI solutions, but our goal is to not have Lifesize hold the encryption keys or the means of authentication. We’re also working on the right approach to joining a virtual meeting and how the host can determine who gets the encryption key as well as exploring in-meeting key rotation and other improvements to this feature. Those precise implementation details will be communicated later as we engage our customers and invite feedback.

From a feature perspective, there will be some limitations on how E2EE can be used. When E2EE is applied, meeting recordings, PSTN call participants and support for third-party conference room devices will be automatically disabled.

The building blocks laid out above hopefully give you an idea of how we’re implementing E2EE for all our customers around the world. We’re ready and willing to show a demo to anyone who would like to see one, so we invite you to reach out. And as we progress, I commit that we will release final implementation source code for anyone to review. After all, security of our global customers’ data and sensitive communications has always been a core pillar of Lifesize’s approach and engineering culture. We always address security challenges head-on and such transparency is paramount to continuing to prioritize security and privacy without slowing down innovation.