Poc e2ee

[lebaudantoine]

Purpose

This PR implements end-to-end encryption (E2EE) capabilities for LiveKit rooms using WebRTC's Frame Encryption API. The implementation ensures that media streams are encrypted on the sender's side and can only be decrypted by authorized participants, maintaining confidentiality even from the LiveKit server.

It's a proof of concept, not intended to be merged.

According to LiveKit documentation :

Connections are established using 256-bit TLS encryption and media streams are encrypted with AES-128. All data at rest is encrypted with AES-256

E2EE adds an extra layer of security features, when you cannot trust the LiveKit server.

Proposal

During room access token generation, the first participant triggers the creation of a room passphrase, which is encrypted using Fernet symmetric encryption and stored in Redis. Subsequent participants retrieve this encrypted passphrase from the cache. When the room ends, LiveKit's webhook notifies the backend to invalidate the cached passphrase.

Using Fernet symmetric encryption is fine for short-term storage.

It's a naive approach, but yet simple.

All participants share an encryption key that remains constant throughout the meeting session, without rotation.

Technical Limitations

Current E2EE feature isn't perfect yet, for a few reasons:

Codec Compatibility

Limited to VP8 video and Opus audio
VP9/AV1 incompatible due to lack of encrypted backup codec support
Required for backwards compatibility with non-VP9 clients

→ doesn't support most recent and optimized Media codec.

Audio Processing

RED (Redundant Encoding) unsupported
Server cannot strip RED packets when E2EE enabled

→ Cannot enable this optimization.

Browser Support

Requires Firefox 117+ for compatibility
Chrome/Edge: 86+
Safari: 15.4+

→ Not available for our FF 115 users

Performance Considerations

Increased CPU usage on resource-constrained devices
Web Worker implementation mitigates main thread impact

AI or recording

E2EE disables Egress functionality, preventing AI features that require room audio recording and processing.

→ Disable a differentiating feature

Documentation

I haven't found any documentation on LiveKit website.

Algorithm

Yet supports only AES-GCM 128, no 256.

Source code

FrameCryptor is responsible for en-/decrypting media frames.

KeyProvider is responsible for key lifecycle.

Future Enhancements

Dynamic Encryption

• Investigation needed: Enable/disable encryption mid-session
• Requires careful key distribution and participant synchronization

Passphrase Requirements

• Define secure passphrase format
• verify the passphrase generation is totally secure

Room Configuration

• Make encryption opt-in rather than default
• Provide admin controls for encryption settings

My 2cts

E2EE should be disabled by default for several reasons:

• Not all meetings require the additional security layer and computational overhead
• Enables broader codec support (VP9, AV1) for standard meetings
• Maintains compatibility with features like audio RED and egress
• Not supported on our targeted FF version

End-to-end encryption becomes critical in scenarios where:

• The LiveKit infrastructure might be compromised
• Meeting content is highly sensitive (e.g., "Diffusion Restreinte" discussions, medical data)
• Zero-trust security model is mandated

[lebaudantoine]

I manually added the misssing authority certificate inside livekit alpine pod. I need to find a better solution !

[lebaudantoine]

Zoom offers two options, enhanced encryption and e2e encryption by default, enhanced encryption is selected.
What is enhanced encryption in Zoom?

AES 256-bit GCM encryption, protecting message and room content. Encryption keys are generated and managed by Zoom's server.

[lebaudantoine]

/!\ default expiration of the cache, corner case, when a participant join right before, and right after.