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

[Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>]

Hi,

Regarding the splicing attack there are at least one aspect I don't think have come up yet in this discussion and which relates to the SSRC and the MD.

Bernard is correct that what is important is that the source SSRC that is pointing to the e2e key context are unique and not collidable to prevent enabling a splicing attack. If the MD translate them that is not an issue as long as the source SSRC is determinable and verifiable through the e2e integrity mechanisms.

What has been less discussed is that non-malicious MD can actually prevent attacks by tracking which original SSRC is coming from where. That way an attacker trying to introduce a splice or an replay of an source SSRC can be blocked before it gets circulated to other MDs or endpoints. Thus help mitigating this attack.

For me it at least this is one of the reasons why it is good to keep the original SSRC easily accessible. This combined with the set of changes anyway needed to support PERC it looked like keeping the SSRC static was the simplest solution from my perspective. 

The discussion of the Splicing attack original was in the context of the field manipulations that could be allowed. I think the basics is in this presentation:

https://www..ietf.org/proceedings/94/slides/slides-94-perc-2.pdf

There are also some requirements John Mattsson presented from Ericsson's perspective on these issues at the same meeting (IETF 94): Slide 6 of

https://www..ietf.org/proceedings/94/slides/slides-94-perc-5.pdf

This is only to provide my perspective from the time I was involved in the WG. I did disengage fairly soon after this meeting so I lack the full perspective on the WG operations and what is documented in the draft now.

Cheers

Magnus

On 2019-03-01 18:20, Bernard Aboba wrote:

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

On Fri, Mar 1, 2019 at 8:18 AM Sergio Garcia Murillo <sergio.garcia.murillo@xxxxxxxxx> wrote:

On 01/03/2019 16:38, Cullen Jennings wrote:

However to get to the heart of why the MID is different than the SSRC in the splicing attack,  the key thing with the splicing attack is the attacker gets the receiver to use a valid, but not really the correct, SRTP crypto context. As outlined in https://tools.ietf.org/html/rfc3711#section-3.2 , the crypto context looked up from dest IP:port and SSRC. So changing the SSRC allows the attacker in the splicing attack to switch to a crypto context of the attackers choosing (and one the attacker has keys for). Changing the other things such as the MID does not allow this. 

You are describing how ssrc splicing works, not what are its effects, or why it is an issue. I think I have found the origin of the ssrc rewriting issue and the splicing attack for perc in here:

https://www.ietf.org/archive/id/draft-westerlund-perc-rtp-field-considerations-00.txt

3.9.  SSRC

   The SSRC identifies the source of the RTP packet.  As each SSRC has
   its own RTP sequence number space as well as timestamp sequence,
   collisions shall be avoided.  For the PERC usage it is also important
   that a receiving endpoint can separate two different originating
   sources and to map the SSRC to a human readable name (or alias).  The
   important security related issue is that unless the originating RTP
   stream can be identified the MDD could create one outgoing stream
   that selects packets from either of them.  This may be challenging
   due to replay protection, but not impossible depending on how the
   sequence number and timestamps align.  To avoid having multiple
   identifers for the RTP packet stream, the design team has proposed
   that the SSRC shall be unique and the original value preserved to the
   receiving endpoint.

   Even if the originating endpoints have unique SSRCs, it is not clear
   if the same requirement will be extended to the MDD, and then
   especially media switching RTP mixers that have their own SSRCs.
   Thus translation of SSRC as a method for dealing with SSRC collisions
   may need to be dealt with.

   The original SSRC needs to be authenticated end-to-end to prevent the
   splicing attack described above.

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.

Best regards

Sergio

_______________________________________________
Perc mailing list
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------