Developer setting to show LiveKit participants that do not have MatrixRTC sessions a.k.a. non-member tiles

[hughns]

This is based on top of #2701

I don't know if we still want it or not.

Developer setting looks like this and is disabled by default:

[fkwp]

@fkwp can I get a product decision on whether this should be enabled by default or not?

this should be default disabled. (we only present people with a matrixrtc membership)

[hughns]

@fkwp can I get a product decision on whether this should be enabled by default or not?

this should be default disabled. (we only present people with a matrixrtc membership)

So we classify the risk of eavesdropping at the LiveKit SFU as acceptable until we move to to-device messaging for key distribution: #1281.

n.b. with a malicious SFU there are other attack vectors around the media streams which aren't mitigated by showing all participants.

Just a thought: as an interim measure we could show some warning (like we do for unencrypted calls) in the header bar to indicate that the call isn't secure. Thoughts?

[toger5]

Just a thought: as an interim measure we could show some warning (like we do for unencrypted calls) in the header bar to indicate that the call isn't secure. Thoughts?

I think this is a good idea. In general there should be a way to find out if there are non matrix subscribers.
I am not sure about the warning not secure? Currently it is. With to-device its still secure there is just sth odd going on.

Thought: This can also happen expectedly due to federation lag. where i connect to lk but my homeserver still does not see the state event and the keys. Maybe we can do some rxjs throttling so this only happens when someone is subscribing for more then 20 seconds?

[davidegirardi]

I suggest this is something we should turn into a release blocker: if we simply hide LiveKit participants without MatrixRTC association, then outside participants can eavesdrop on the call as long as they have the keys

And how would they get the keys?

[Half-Shot]

The warning idea is fine but you need a resolution step for it to be useful. I.e. How do you make the call secure again? Kick the participant who's not got a membership?

Otherwise it's just going to leave users confused about how to make the app work.

[toger5]

@davidegirardi

And how would they get the keys?

This is just for the intermediate situation where we do not yet use to device messages. Its not any random person who could listen and decrypt the streams but other Matrix room members that are not in the call. (They could download the keys from the room history and then decrypt)

[davidegirardi]

In that case, can't they just record the traffic coming through the SFU without participating in the call? Get the rooms from the keys, the private key of the SFU from the config, intercept the traffic before the SFU and then decrypt?

[hughns]

In that case, can't they

just record the traffic coming through the SFU without participating in the call?

Yes. They can record the encrypted media streams that are being sent to the SFU. They are encrypted with a symmetric cipher (AES if I recall correctly). Each incoming media stream has its own media key.

Get the rooms from the keys,

I think you mean get the media keys from the Matrix room. If so, then yes.

the private key of the SFU from the config,

Do you mean the TLS/SSL key?

intercept the traffic before the SFU and then decrypt?

No, because each media stream is encrypted with a key that is not known to the SFU.

[hughns]

Thought: This can also happen expectedly due to federation lag. where i connect to lk but my homeserver still does not see the state event and the keys. Maybe we can do some rxjs throttling so this only happens when someone is subscribing for more then 20 seconds?

This is a very good point. I think it makes the idea of a warning useless: An attacker could simply disconnect and reconnect to stay within the throttle period and be undetected.

[davidegirardi]

I'm replying inline so we don't lose context but the important part is after the quote-replies:

the private key of the SFU from the config,

Do you mean the TLS/SSL key?

Exactly so they can get access to the application layer and then decrypt the E2EE traffic with the keys they got from the room.

intercept the traffic before the SFU and then decrypt?

No, because each media stream is encrypted with a key that is not known to the SFU.

But you need that to get access to the E2EE application layer.

What I'm saying is that a room member with privileged access to the SFU can still decrypt the traffic. Displaying extra tiles in the call doesn't help with this attack scenario. The privileged user (member of room and admin on the SFU) can still get access to the traffic without being a LiveKit participant. Key material comes from the room itself.

[hughns]

What I'm saying is that a room member with privileged access to the SFU can still decrypt the traffic. Displaying extra tiles in the call doesn't help with this attack scenario. The privileged user (member of room and admin on the SFU) can still get access to the traffic without being a LiveKit participant. Key material comes from the room itself.

I completely agree. This is why I earlier said:

n.b. with a malicious SFU there are other attack vectors around the media streams which aren't mitigated by showing all [LiveKit] participants [as tiles on the screen].

For the record, the change in behaviour that impacts security (to only show MatrixRTC memberships and not LiveKit participants) was introduced by #2701. This PR is related but does not change the security.

If someone is making the case to rollback #2701 then please go and do so.

Otherwise I would like to get the code of this PR reviewed and, if acceptable, merged.

[davidegirardi]

I think always showing those tiles does help the security of the call and it's just confusing for end users. It's useful for development so Security is not against merging this.

[fkwp]

To be clear (and correct me if I am wrong). The only difference here compared to the to-device message approach is that everybody in a matrix room will have the e2ee media keys rather than only the subset of the actual call participants.

And with the work package of sending keys via to-device messages being on the near horizon I do consider this as secure enough for the time being.

Hence, lets use this as a useful developer / debug tool -- but we default it off (so user needs to explicitly enable it in developer settings to show non-rtc-member-tiles)

[toger5]

I would also like to give a TLDR in my own words (I can tell from the comments that we all know whats happening but this is for reference/simplified mental model)

• Before ToDevice: Everyone in a room can decrypt your stream.
  Secure group = room member list.
  • Without ToDevice, we have the room scope security behavior. We do not need to warn about another livekit member as a security issue since a non RTC member user is not more dangerous than a user from that room reading the SFU streams (SFU does not need to/cannot be trusted)
  • Informing about the secure scope inside the app could be interesting. Right now we do this outside the app (talks, docs, code comments, msc's)
• After ToDevice: Only ppl with call memberships can decrypt the streams
  Secure group = call member list. (An RTCmember event is required to receive the keys)
  • So there is no harm in externals reading encrypted streams and connecting to the lk session so we don't need to warn about another livekit member as a security issue.

[robintown]

Thanks everyone for taking the time to discuss my concern. I'm happy that we have a clear perspective on the current security model out in the open. :)