[ER-59] E2EE: Send media keys via to_device message

[dbkr]

Add to-device key distribution

• After E2EE first cut: Generate media key, send an encrypted room event on call join #1278

In addition to sending media keys as events to the room, send them via to_device events encrypted with Olm as a primary way of sending the keys, then keep the room events as backup. Add a posthog event to track when the keys don't arrive via to_device. This will allow us to migrate away from using room events in the long term as they cause the media key to be saved in the room history.

Prerequisits:

• To device widget MSC MSC3819: Allowing widgets to send/receive to-device messages matrix-org/matrix-spec-proposals#3819
• Make all platforms support to-device widget features
  • rust sdk Support sending to_device messages in the rust sdk widget driver. (MSC3819) matrix-org/matrix-rust-sdk#4859
  • js-sdk (matrix-widget-api) Implement MSC3819: Allowing widgets to send/receive to-device messages matrix-org/matrix-widget-api#57
• split the encryption key logic out from MatrixRTC session into an EncryptionManager (Done in: MatrixRTC: refactor MatrixRTCSession media encryption key logic into EncryptionManager matrix-org/matrix-js-sdk#4612)
• Planning meeting what is needed and how it should be architectured (in regards to MatrixRTC: refactor MatrixRTCSession media encryption key logic into EncryptionManager matrix-org/matrix-js-sdk#4612) (results of planning meeting see Production ready requirements and Tasks

Production ready requirements

• Exclude untrusted devices (expected to need widget api MSC changes)
• Error handling on sending to-device events (expected to need widget api MSC changes)
• Performance: Investigate, test the performance and eventually add ratcheting (expected to need matrixRTC MSC changes)

Tasks

Iterations: are based on Temp: see: https://excalidraw.com/#room=b7556403b8947d5ee7ac,duF48bj2SbmRTsa3ivmLFA

Iteration 1: "change transport" and "make it backwards compatible"

• Use hughs work as reference

• MatrixRTC: Introduce key transport abstraction as prep work for to-device encryption matrix-org/matrix-js-sdk#4773

  • move transport in its own class
  • create a new transport for room event key sharing
  • use that transport
  • adjust tests to support the new architecture

• use the to-device messages instead of the room event. #3155

  • MatrixRTC: ToDevice distribution for media stream keys matrix-org/matrix-js-sdk#4785
    • add to device Transport
    • real world test
    • rebase on top of MatrixRTC: Introduce key transport abstraction as prep work for to-device encryption matrix-org/matrix-js-sdk#4773
    • add benchmarking (might be another PR) Not part of Iteration 1, see iteration 2
    • add sendAndEncryptToDevice message for embedded and stand alone
    • test with rust sdk
    • Make logging consistent for matrixRTC matrix-org/matrix-js-sdk#4788

• Add option to enable to-device-encryption #3167

  • Do KISS backwards compatible system (just a bool flag in EC dev tools)
  • use the correct js-sdk version

• Discuss how we do the transition with backwards compatibility

  • Support to-device and room encryption in parallel or
  • With smart switching (Decision: this is the right solution)
    • MatrixRTC: Add combined toDeviceAndRoomKeyTransport matrix-org/matrix-js-sdk#4792
    • Add RoomAndToDeviceKeyTransport #3185

Iteration 2: "to device message format"

• Encrypt and send duration logging to gather some stats on N^2 scaling
• Make to device messages spec conformant: ToDevice specification part of MatrixRTC spec 4143
  • to-device will use the new format
  • room event transport will keep the old format

Iteration 3: "encryption error cases and security"

• Give access to send errors for to-device message sending using the queue (sendQueue) matrix-org/matrix-js-sdk#4793 Allow the js-sdk to return errors if todevice sending failed.
• Introduce error cases for encryption to be able to imply appropritate retry logic
• Solve "not send to insecure devices" UX.

Other Parallelize tasks (optional)

• Expose encryption information (DecryptionInfo) of to device messages. This is needed to let the widget know if a to-device message can be trusted. Is save in terms of: signed, not leaked to the HS in plaintext ... (maybe there is workaround)

• Refactor the EncryptionManager MatrixRTC: Refactor | Introduce a new Encryption manager (used with experimental to device transport) matrix-org/matrix-js-sdk#4799

  • Rethink when we send updated new keys to minimize traffic and "time where post compromising is not fulfilled"
  • Test livekit ratcheting: Change child loggers (getChild) to LogSpans matrix-org/matrix-js-sdk#4807
  • Add option to livekit to expose allow extracting ratcheted keys. (js-client livekit client repo)
  • refactor retrying to be part of the room-transport instead of the encryption manager (update BasicEncryptionManager and EncryptionManager) @BillCarsonFr
  • rename BasicEncryptionManger into NewEncryptionManager (maybe?)

• Playwright key sharing tests

  • performance metrics for key sharing: Do we need ratchiting

• Prototype:

  • (EXPERIMENTAL) Prototyping with to-device sender key distribution #2572
  • MatrixRTC key distribution using to-device messaging matrix-org/matrix-js-sdk#4485