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

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Mar 2019 09:19:31 -0800

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 <
[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 4 Mar 2019 12:46:07 +0000

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:

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 <[email-masked]<mailto:[email-masked]>> 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:

3.9.  SSRC

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
[email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 4 Mar 2019 14:03:59 +0100

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:
> There are also some requirements John Mattsson presented from 
> Ericsson's perspective on these issues at the same meeting (IETF 94): 
> Slide 6 of
> 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
>
>
>> 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."
>>
>> 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.
>>
>> 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 
>> <[email-masked] 
>> <mailto:[email-masked]>> 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:
>>
>>     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
>>
>>     [email-masked] <mailto:[email-masked]>
> SE-164 80 Stockholm, Sweden | mailto:[email-masked]