Sergio said:
"So the main issue here is that "endpoint can separate
two different originating sources and to map the SSRC to a
human readable name (or alias)". By modifying the MIDs the
MD is able to do exactly that, and have the same effect than
splicing attack without having to rewrite the ssrcs, that
is, the endpoint will not be able to differentiate rtp
packets coming from two different sources as the MID is used
for routing and not the ssrc."
[BA] Let me attempt to unpack this. There are two issues
here, which relate to:
1. Effects of changing the RTP header SSRC
2. Effects of manipulating the original" SSRC associated
with the e2e keys.
Taking each in turn:
1. Changing the RTP header SSRC affects the routing of
audio/video seen by the user but does not affect the
integrity of media, which is protected by the e2e keys.. By
changing the RTP header SSRC it is possible to "splice" the
media or cause the a/v rendered in audio/video tags to
switch between users (e.g. dominant speaker protection). As
we have discussed this is very common and causes few
problems today, so it really can't be thought of as an
"attack".
2. I believe this is the aspect Cullen is referring to,
which provides an attacker with the ability to fool an
endpoint into accepting as authentic a manipulated payload.
This can be used to create a "deep fakes" so it is a genuine
attack.
Addressing this doesn't require outlawing the
modification of the RTP header SSRC. If the original SSRC
is included in the payload in cleartext and integrity
protected along with the rest of the payload, then the
payload crypto-context is unaffected by modifications to the
SSRC included in the RTP header. The endpoint determines
the appropriate keys for integrity protection and payload
decryption from the payload SSRC, not the RTP header SSRC.
Of course, for this to work, conference participants
cannot be allowed to masquerade as each other. That is, if
multiple conference endpoints possess the e2e keys used to
encrypt and integrity protect payload data, then they can
source "deep fake" media that appears to originate from
another party. As you have pointed out, this is a
fundamental problem that the PERC framework does not
address.
However, it can be addressed if trust is rooted in
hardware (e.g. the TPM) and that e2e keys are not accessible
to the endpoints (either _javascript_ or the browser).
AFAICT, PERC key management doesn't meet this requirement,
but some content protection schemes claim to do so..
