Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC)

From: Bernard Aboba <[email-masked]>
Date: Thu, 21 Feb 2019 10:40:22 -0800

"By not allowing the Media Distributor to change the SSRC, PERC mitigates this
attack."

[BA] The security threat is mis-stated, and the "fix" is worse than the
problem.

In most situations modifying the SSRC will not represent an attack, just an
attempt on the part of the SFU to weave received simulcast streams together
to form a single stream so that an endpoint that does not support simulcast
reception can render it.  So the "fix" is inherently incompatible with
endpoints that can not receive simulcast, not a good tradeoff.

The actual threat to worry about is not "splicing" but "deep fakes" where
an attacker with access to cleartext audio and video can modify the media
(such as putting someone else's face on another body), while still
retaining synchronization between audio and video to make the "fake"
believable.  Addressing this kind of attack requires control of endpoint
access to cleartext media and recording APIs.  AFAICT, PERC does not
prevent this kind of attack because of key sharing.

"Given that MID is by definition HBH as it must match the negotiated SDP
O/A, then the MD could arbitrarily change the MID for an RTP packet and
associate it with whatever transceiver it wishes, effectively having the
same effect than the SSRC splicing attack (at least in perc double where
all participants share the same inner e2e key and there)."

[BA] MID modification is quite likely in scenarios such as "dominant
speaker" where the video (and audio) will switch between participants as
they take turns speaking.  Again, in most situations, this does not
constitute an attack, and where it does, PERC will not be of much help.

On Thu, Feb 21, 2019 at 9:57 AM Sergio Garcia Murillo <
[email-masked]> wrote:

> In the media framework it is stated the following regarding SSRC splicing
> attacks:
>
>    The splicing attack is an attack where a Media Distributor receiving
>    multiple media sources splices one media stream into the other.  If
>    the Media Distributor is able to change the SSRC without the receiver
>    having any method for verifying the original source ID, then the
>    Media Distributor could first deliver stream A and then later forward
>    stream B under the same SSRC as stream A was previously using.  By
>    not allowing the Media Distributor to change the SSRC, PERC mitigates
>    this attack.
>
> However, if BUNDLE and MID are used, and there is no ssrc signaling done
> in SDP, the following RTP demuxing rules from BUNDLE spec applies:
>
>    If the packet has a MID, and the packet's extended sequence number
>    is greater than that of the last MID update, as discussed in
>    [RFC7941], Section 4.2.6 <https://tools.ietf.org/html/rfc7941#section-4.2.6>, update the MID associated with the RTP
>    stream to match the MID carried in the RTP packet, then update the
>    mapping tables to include an entry that maps the SSRC of that RTP
>    stream to the "m=" section for that MID.
>
> Given that MID is by definition HBH as it must match the negotiated SDP
> O/A, then the MD could arbitrarily change the MID for an RTP packet and
> associate it with whatever transceiver it wishes, effectively having the
> same effect than the SSRC splicing attack (at least in perc double where
> all participants share the same inner e2e key and there).
>
> Best regards
>
> Sergio
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 21 Feb 2019 21:38:29 +0100

Fully agree:

- The attack is not an attack but normal SFU behavior (the attack would 
be impersonation and/or deep fakes)
- Trying to prevent it, PERC forbids to rewriting ssrc which break most 
known SFUs up to date
- The attack is not prevented

IMHO PERC fails for WebRTC because it is not truly end to end, just 
browser to browser, as it doesn't take into consideration the role of 
the js app.

Only a e2ee solution integrated with IdP and isolated media streams 
which allows the receiver to assert the identity of the received packet 
would prevent impersonation and deep fakes. Without it, the user *MUST* 
trust the js application so that it doesn't send the media to an 
alternative server or create deep fakes as Bernard is stating.

Best regards
Sergio

On 21/02/2019 19:40, Bernard Aboba wrote:
> "By not allowing the Media Distributor to change the SSRC, PERC 
> mitigates this attack."
>
> [BA] The security threat is mis-stated, and the "fix" is worse than 
> the problem.
>
> In most situations modifying the SSRC will not represent an attack, 
> just an attempt on the part of the SFU to weave received simulcast 
> streams together to form a single stream so that an endpoint that does 
> not support simulcast reception can render it.  So the "fix" is 
> inherently incompatible with endpoints that can not receive simulcast, 
> not a good tradeoff.
>
> The actual threat to worry about is not "splicing" but "deep fakes" 
> where an attacker with access to cleartext audio and video can modify 
> the media (such as putting someone else's face on another body), while 
> still retaining synchronization between audio and video to make the 
> "fake" believable. Addressing this kind of attack requires control of 
> endpoint access to cleartext media and recording APIs.  AFAICT, PERC 
> does not prevent this kind of attack because of key sharing.
>
> "Given that MID is by definition HBH as it must match the negotiated 
> SDP O/A, then the MD could arbitrarily change the MID for an RTP 
> packet and associate it with whatever transceiver it wishes, 
> effectively having the same effect than the SSRC splicing attack (at 
> least in perc double where all participants share the same inner e2e 
> key and there)."
>
> speaker" where the video (and audio) will switch between participants 
> as they take turns speaking.  Again, in most situations, this does not 
> On Thu, Feb 21, 2019 at 9:57 AM Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     In the media framework it is stated the following regarding SSRC
>     splicing attacks:
>
>     However, if BUNDLE and MID are used, and there is no ssrc
>     signaling done in SDP, the following RTP demuxing rules from
>     BUNDLE spec applies:
>
>     Given that MID is by definition HBH as it must match the
>     negotiated SDP O/A, then the MD could arbitrarily change the MID
>     for an RTP packet and associate it with whatever transceiver it
>     wishes, effectively having the same effect than the SSRC splicing
>     attack (at least in perc double where all participants share the
>     same inner e2e key and there).
>
>     Best regards
>
>     Sergio
>
>     [email-masked] <mailto:[email-masked]>