Subject: [FECFRAME-PROTO] Encrypted FEC

From: Marshall Eubanks <[email-masked]>
Date: Wed, 26 Sep 2007 13:35:44 -0400

Do we want to allow for separately encrypted FEC streams ?

I could imagine providing a unprotected stream for free, but only  
paying subscribers get protection, which
is why I asked.

Regards
Marshall

_______________________________________________
FECFRAME-PROTO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe-proto

---

From: "Ali Begen \(abegen\)" <[email-masked]>
Date: Wed, 26 Sep 2007 10:55:18 -0700

This is a valid question and will be used in many networks.

Are you asking whether we need to specify the encrypted FEC streams in
the SDP somehow? 

Otherwise, if a handshake on FEC will take place (3-way in your earlier
email), I believe the handling of encrypted FEC streams can be achieved
thru authentication.

-acbegen

> -----Original Message-----
> From: Marshall Eubanks [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 10:36 AM
> To: [email-masked]
> Subject: [FECFRAME-PROTO] Encrypted FEC
> 
> I could imagine providing a unprotected stream for free, but 
> only paying subscribers get protection, which is why I asked.
> 
> Regards
> Marshall
>

---

From: "Ulas Kozat" <[email-masked]>
Date: Wed, 26 Sep 2007 11:17:17 -0700

I do not see any particular reason for not allowing separately encrypted FEC
streams. But why is this relevant to the framework, e.g., does the
application layer or FEC scheme need to coordinate anything with the
framework when encryption is used?

I do have a question about streaming a scalable video. Do we treat each
layer as being served by a separate instantiation of the framework? Or all
the layers (I mean core+enhancement) are served by the same instance? I
guess it should be separate instantiation.

-Ulas

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 26 Sep 2007 14:37:12 -0400

I think that we need to allow for separate encryptions of FEC streams.
There is a danger that an attacker could use the main stream and the  
FEC stream to attack the encryptions.

Here is what it says now

    It is possible that multiple streams with different confidentiality
    requirements (for example, the streams may be visible to different
    sets of users) can be FEC protected by a single repair stream.  This
    scenario is not recommended, since resources will be used to
    distribute and decode data which cannot then be decrypted by at  
least
    some receivers.  However, in this scenario, confidentiality
    protection MUST be applied before FEC encoding of the streams,
    otherwise repair data may be used by a receiver to decode  
unencrypted
    versions of source streams which they do not have permissionions to
    view.

If the main stream is not encrypted, there is no security issue, but  
otherwise I would say that this is not adequate - the FEC needs to be  
encrypted at _at least_ the level of the original encryption.

Obviously, if the encryption scheme "leaks" information, encrypting  
both FEC and original will leak information faster. But, it is worse  
that that. Encryption of the same data with two different encryption  
schemes is notoriously dangerous, and this is close to that (in that  
you are encrypting plaintext and a known function of the plaintext).  
If a different encryption scheme is used for the FEC, the combination  
of the two ciphertexts  may thus lead to recovery of the plaintext.

Our job is to provide guidance and set limits to scheme creators. I  
would change the above to read

    It is possible that multiple streams with different confidentiality
    requirements (for example, the streams may be visible to different
    sets of users) can be FEC protected by a single repair stream.  This
    scenario is not recommended, since resources will be used to
    distribute and decode data which cannot then be decrypted by at  
least
    some receivers.  Confidentiality protection MAY be applied to
    FEC streams when the original stream is not, say to allow for a  
better
    quality of service to subscribers.

    If confidentiality protection is  applied to the original stream,  
confidentiality
    protection MUST be applied before FEC encoding of the streams,
    otherwise repair data may be used by a receiver to decode  
unencrypted
    versions of source streams which they do not have permissionions to
    view. The confidentiality protection applied to the FEC streams  
ideally SHOULD be
    the same protection as that applied to the original stream and  
MUST in any case be as
    least as cryptographically "hard" as that applied to the original  
stream. Identical encryptions
    (same cipher, same key, same offset of a stream cipher) MUST NOT
    be applied to the original and FEC streams.

Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 26 Sep 2007 14:40:10 -0400

On Sep 26, 2007, at 2:37 PM, Marshall Eubanks wrote:

> There is a danger that an attacker could use the main stream and  
> the FEC stream to attack the encryptions.
>
> Here is what it says now
>
> If the main stream is not encrypted, there is no security issue,  
> but otherwise I would say that this is not adequate - the FEC needs  
> to be encrypted at _at least_ the level of the original encryption.
>
> both FEC and original will leak information faster. But, it is  
> worse that that. Encryption of the same data with two different  
> encryption schemes is notoriously dangerous, and this is close to  
> that (in that you are encrypting plaintext and a known function of  
> the plaintext). If a different encryption scheme is used for the  
> FEC, the combination of the two ciphertexts  may thus lead to  
> recovery of the plaintext.
>

I would also change this to

      This scenario SHOULD NOT be done, since resources ....

(Note that this also leads to multiple cipher texts for the same  
plain text attacks.)

Marshall

>    If confidentiality protection is  applied to the original  
> stream, confidentiality
>    least as cryptographically "hard" as that applied to the  
> original stream. Identical encryptions

---

From: Mark Watson <[email-masked]>
Date: Wed, 26 Sep 2007 15:30:13 -0700

Marshall,

There are a few different scenarios here, and we have to be careful to
distinguish them and explain the considerations separately, because they are
very different.

Firstly, the idea that the original stream and the FEC protection might have
different confidentiality requirements (that some users may be authorised to
receive only the original stream and not the FEC), is a new (and
interesting) idea which has not been introduced into the discussions before.
We need to be careful to describe it and consider it separately, since it
arises from a specific user requirement, rather than being just one of
several ways to meet the usual confidentiality requirement for the original
stream.

Secondly, if the above scenario does not apply (users are authorised to
receive both streams or neither stream), and when confidentiality protection
is applied to the original source, before the FEC is applied, there is no
reason to apply confidentiality protection to the FEC stream: the most an
attacker could use the FEC stream for would be to recover the protected
source stream, which they are assumed to have anyway.

As you say, there are some risks associated with applying confidentiality
protection _after_ FEC has been applied, since the attacker know about
linear relationships within the plaintext. However, I think it is sufficient
to require that independent keys are used for the source and FEC data
streams in order to avoid this.

...Mark

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 26 Sep 2007 23:02:18 -0400

Dear Mark;

> several ways to meet the usual confidentiality requirement for the  

I agree.

> source stream, which they are assumed to have anyway.

I also agree. In this case, I strongly favor the encrypt first, FEC  
later approach. I was
thinking about a modular case where this may not be possible, which  
was probably lost in my text.

> streams in order to avoid this.

Yes.

Marshall