Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use

From: "Dallard, Nigel" <[email-masked]>
Date: Thu, 27 Apr 2006 10:33:17 +0100

> From: Karl Norrman (KI/EAB) [mailto:[email-masked]] 

> The ROC needs to be integrity protected to ensure that it is
> not maliciously modified or subject to transmission bit errors
> en route.  If the receiver starts using a ROC that has been modified
> during transmission, the receiver will be out of synch.
> Since in "normal" SRTP operation, the ROC is never transmitted 
> in-band, an unprotected transmission of ROC would therefore _add_ 
> a vulnerability that is -_not_ present in RFC3711.

Hi there Karl,

I accept what you are saying, however, in the particular application I
am concerned about...

1. Forward error protection is dealt with at a lower level in the
protocol stack. It should be a very rare occurrence that an erroneous
ROC value reaches the descramber in the ROC. The worst-case scenario
would be that the receiver would be out of sync for R packets. The
broadcaster has the ability to trade the impact of such loss of sync
against bit-rate by varying the value of R.

2. Malicious modification is not necessarily a concern in a broadcast
environment. Your TV does not, today, authenticate the source of the TV
signal.

I believe that if the system/network operator, having performed a risk
assessment (along the lines of that described in Section 9 of RFC3711,
for example), would prefer to trade bit-rate against the possibility of
loss of ROC sync or the ability of receivers to authenticate the source
of his signals, he should be able to do so.

> You are correct when you say that it is necessary to include the MAC
> on each R:th packet.  If one is worried about the bandwidth 
> consumption of a MAC of 80 bits per R:th packet, one could put the
> length of the MAC (n_tag parameter in SRTP) to something less, e.g.,
> 32 bits.

Yes, I understand this. I'd like to effectively set n_tag to 0  :-)

Cheers,

Nigel

** Nigel Dallard                 e-mail: [email-masked]  ** 
** Senior Member                    www: http://www.nds.com  ** 
**   of Technical Staff             tel: +44 23 8030 7151    ** 
** NDS Ltd, Southampton, UK.     mobile: +44 7881 913151     ** 

This email message and any attachments thereto are intended only for use by the addressee(s) named above, and may contain legally privileged and/or confidential information. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [email-masked] and destroy the original message
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: David McGrew <[email-masked]>
Date: Thu, 27 Apr 2006 15:06:54 -0700

Hi Nigel,

>> a vulnerability that is -_not_ present in RFC3711.

I second Karl's concern - RCC used without authentication introduces  
a new vulnerability.

> environment. Your TV does not, today, authenticate the source of  

This makes sense - confidentiality is the main goal in a broadcast TV  
scenario, and authentication would be secondary.  One of the concerns  
with security protocols is that sometimes the lack of authentication  
can induce a loss of confidentiality, but if you are transmitting  
audio/video/media only (as opposed to e.g. DTMF), that's probably not  
an issue in your scenario.

I'm curious: are there any higher-level checksums on the application  
data that would catch the decryption error that would result from ROC  
de-synch?  If not, how would the codec respond to seemingly random  
inputs?

> of his signals, he should be able to do so.

I'm not sure that I'd make that tradeoff.  If there are system  
constraints (e.g. on packet size) that would prevent the use of  
authentication, that's one thing.  But IIRC you're securing video  
broadcasts, and video packets are typically fairly large.  What  
fraction of the bandwidth would be consumed by a 32-bit  
authentication tag on every Rth packet?  Also, consider that with RCC  
as currently defined the 32-bit rollover counter is being included in  
every Rth packet - so there is already some bandwidth loss that's  
being incurred just for using RCC.

> Yes, I understand this. I'd like to effectively set n_tag to 0  :-)

If you're interested in seeing a standard that supports the option  
you're describing, I suspect that people in the security area will  
ask you to provide the sort of analysis that you mention above.

Have you considered using the "Encrypted Key Transport for SRTP"  
method, which provides ROC synchronization as well as some other  
features that are attractive in multi-participant RTP sessions?  It  
doesn't increase the bandwidth usage (it eats into RTCP's bandwidth  
allocation, not RTP's bandwidth allocation - it robs Peter instead of  
Paul, so to speak :-).

Best regards,

David

> This email message and any attachments thereto are intended only  
> for use by the addressee(s) named above, and may contain legally  
> privileged and/or confidential information. If the reader of this  
> message is not the intended recipient, or the employee or agent  
> responsible to deliver it to the intended recipient, you are hereby  
> notified that any dissemination, distribution or copying of this  
> communication is strictly prohibited. If you have received this  
> communication in error, please immediately notify the  
> [email-masked] and destroy the original message

---

From: canetti <[email-masked]>
Date: Thu, 27 Apr 2006 22:54:34 -0400 (EDT)

Two points:

1. I don't see a reason why authentication should not be a security
concern for TV transmissions. I guess that when some hacker
redirects a porn movie to the cartoon channel on sunday morning the
problem will get appropriate attention...

2. If we're talking about broadcast where all recipients use the same key
then just using HMAC (or any other MAC) is not good enough, since anyone
who has the key can forge. A more sophisticated solution is needed.

Ran

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 27 Apr 2006 20:44:40 -0700

>problem will get appropriate attention...

Not to disagree, but to understand this problem better: wouldn't the 
two programs be protected with different program (encryption) 
keys?  In that case, terminals that don't have keys can't decrypt the 
redirected program.  The threat is that one of the entities which has 
the encryption keys sends the redirects the wrong program to the 
wrong channel.  The additional assumption, at least in some systems 
is that the adversary can also transmit (which some people think is 
hard to do, but not anywhere close to "hard" in the cryptographic or 
computational sense.  There are legal and monetary considerations, 
but none of those come close to the typical crypto computational 
complexity and the considerations thereof.)

But, in those cases though, Ran's point (2) below applies.  However, 
no (planned commercial) broadcast system today employs source 
authentication schemes.

So the question is, since group authentication doesn't buy anything 
(if an entity can "transmit" it can go to the lengths of obtaining 
the symmetric key, which a relatively cheaper subscription makes 
available to anyone who signs up for the service), does it make sense 
to use group authentication?

The other question that was asked of me recently is that if 
codec-level "error" correction (can people clued in in that area 
clarify what that means) results in better rendering of content, does 
it make sense to turn off integrity protection?  Thoughts?

regards,
Lakshminath

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Apr 2006 10:15:19 +0200

Lakshminath Dondeti wrote:

> The other question that was asked of me recently is that if codec-level 
> "error" correction (can people clued in in that area clarify what that 
> means) results in better rendering of content, does it make sense to 
> turn off integrity protection?  Thoughts?
> 

What I assume they mean is the use of unequal error correction and then 
have an unequal error detection that allows you to discern between 
errors in the critical parts and errors in the non-critical. For IP the 
existing specifications in this regards are UDP-Lite that allows the UDP 
checksum to be applied to only parts of the payload. Then there exist a 
few RTP payload formats that have data structured in such a way that the 
least important data is at the end of the packet. The codec then can use 
data with errors to do error concealment that is better than not having 
any data at all. AMR and AMR-WB do have these features and some of the 
video codecs are also capable of producing packets where this will work.

The big issue with this system is that it doesn't provide any knowledge 
about how badly damaged the unprotected part has suffered. This is very 
relevant because the amount of bit-errors that these can tolerate in the 
unprotected parts varies with the codec. This have created a situation 
where use of UDP-Lite is from a management point of view is 
undeployable. We don't have mechanism in place to provide the end to end 
path with information on how much bit-errors the individual packet flows 
can handle, nor a way of handling the accumulation received from 
multiple links.

It was a nice idea and it is in use for non-generic systems, one example 
is for all the GSM circuit switched voice. In those cases the codec and 
the link correction and detection mechanism is tailored for the codec so 
that the right error behavior is achieved.

So I would not design any special solution for this. It has been 
available to try since 2002 or so. I have not heard about any deployment 
of this.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: canetti <[email-masked]>
Date: Fri, 28 Apr 2006 11:59:20 -0400 (EDT)

Lakshminath,

> complexity and the considerations thereof.)

This is a great example of  "encryption doesnt buy authentication":
First, as you say, if the attacker has the keys for both transmissions then
it can ofcourse re-encrypt. But even if not, it is often quite easy to
change ecrypted stream A to encrypted stream B *without knowing the key*,
say if the encryption is a stream cipher.  (Here A=donald duck and B=your
favorite porn).

> no (planned commercial) broadcast system today employs source

That's exactly the worry. what's justified on a dedicated link such as
cable TV is no longer justified in IPTV...

> to use group authentication?

Group authentication does give some leverage, since an attacker needs to
either hack or bypass its receiver box so as to extract the authentication
key. but cryptographically it indeed buys you next to nothing in
this one-to-many setting.

> it make sense to turn off integrity protection? Thoughts?

I dont think that any keyless error correction scheme can provide
authentication. An attacker can simply use the same encoding scheme as the
real source.

Best,

Ran