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

[Sergio Garcia Murillo <[e-mail]>]

Hi Magnus,

Thanks for the insights which matches what I understood from the 
splicing attack.

While I acknowledge that being able to track the origin of the rtp 
packet media is a good (and even a must have) functionality:

  * There is no mechanism in PERC to coordinate/map ssrc values to
    origins/participants between the endpoints.
  * In WebRTC, for that information to be of any value, the js app must
    be trusted to do something mean full with it.

FWIW, PERC-Lite carried the original ssrc in the inner payload, and as 
said before in a previous email, we have improved it for a customer to 
carry the participant id in the encrypted payload instead of the ssrc 
value (much more useful).

Best regards
Sergio

On 04/03/2019 13:46, Magnus Westerlund wrote:
> 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 
>> <[e-mail] 
>> <mailto:[e-mail]>> 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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/perc
>>
>
> -- 
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto:[e-mail]
> ----------------------------------------------------------------------