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

[Sergio Garcia Murillo <sergio.garcia.murillo@xxxxxxxxx>]

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)."

[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 <sergio.garcia.murillo@xxxxxxxxx> 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, 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
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc