Make EC compatible with custom member.id value (Pseudonomous users on the SFU)

[toger5]

This is the companioning PR for: matrix-org/matrix-js-sdk#5105

It allows to use a custom UUID value in the member.id field.

• compatible with matrix2.0 (it expects the livekit identity to be what we have in member.id)
• allows us to hide the identity from he SFU.

It also makes sure EC (from v0.17.0 and onwards) will always send the membershipID or member.id with the expected value.

[robintown]

I would like us to think through the following scenario: What if Alice joins a call, and then Eve joins a call using the very same membership ID as Alice? The app, SDK, and JWT service all seem at risk of getting confused in certain ways.

• impact to Element Call: minimal, sort of.
  • From the perspective of a 3rd party, Bob, we would end up creating two RemoteUserMediaViewModels with the same LiveKit participant. They could get confused about their local volume, since they are both fighting for control over the same participant, though that's not super worrying. We would need to be vigilant in the future to not assume exclusive ownership of a participant in our media code.
  • From the perspective of Alice, she would see Eve as perpetually in a 'waiting for media' state, because there would be no remote participant corresponding to her. It seems not great that Eve's impersonation attempt would remain hidden from Alice in this split-brained way.
• impact to matrix-js-sdk: Right now the SDK still uses the hardcoded ID format in getParticipantId, which is used by the encryption managers. Assuming we were to change this (as I think we would need to for compatibility), Eve could then DoS Alice's media by sending garbage keys to Bob, which would override Alice's real key. Bob would fail to decrypt Alice's media.
• impact to the JWT service: If the JWT service is changed to accept any requested participant ID rather than computing an ID itself, it would no longer be able to block certain DoS or impersonation attempts from others joining a call. If Alice has to do a full LiveKit reconnect for any reason, Eve could jump in and grab the rights to her participant ID.

I know we can't in general guarantee the authenticity of media because SFrame has no authentication mechanism, but now that I'm looking at it more closely I'm not sure custom membership IDs work for the current threat model. If implemented across the stack it gives some undesirable abilities to unprivileged users.

[toger5]

@robintown I get the point. I think you are correct. Still need to think through the exact impact.

We have discussed two ways: fully random (UUID) and hashing the expected user + room+ device+ appliaction .... in a defined way.
This would be possible to validate so users could not send state /sticky events that are invalid.
BUT it would allow the opposite attack where I can publish media for a hash i know someone else will compute if they join. (I can already do this with the device id today. the user id is authenticated via the openId token)

[robintown]

hashing the expected user + room+ device+ appliaction .... in a defined way.

Sure, with a salt that could work. I still wonder what the right choice is, generally, between putting computed values in events (which other users must validate and therefore re-compute) versus just asking others to compute the value themselves (no risk of forgotten validation this way).

BUT it would allow the opposite attack where I can publish media for a hash i know someone else will compute if they join.

Not if the JWT service still verifies the computation (meaning we reveal our identity to the JWT service but not the SFU)

[toger5]

Not if the JWT service still verifies the computation (meaning we reveal our identity to the JWT service but not the SFU)

Yes like it is now. it can do so with our userId but not deviceId application and so on.

[fkwp]

Pseudonymous LiveKit Participant Identity

To protect user privacy, a pseudonymous LiveKit participant identity is used, so the Matrix user ID
is not exposed to the LiveKit SFU backend. This pseudonymous identity is given by the SHA-256 hash
of the concatenation of the Matrix user_id, a pipe character (|) , the claimed_device_id,
a pipe character (|) and the member.id field, e.g, SHA256(user_id|claimed_device_id|member.id).

is the latest update on the MSC matrix-org/matrix-spec-proposals@ad88a5a