RE: Réf. : Re: Encryption control of SNDU

["Bernhard Collini-Nocker" <bnocker@cosy.sbg.ac.at>]

Dear Tarif,

since I am not an expert on scrambling could you please elaborate a
little bit on how the receivers do obtain the two keys. Is there a
key distribution mechanism or are those keys permanently set in the
receiver hardware?
Still my personal opinion is that scrambling control should be in a
separate standard track. Where to put the 2 necessary bits is a good
question, adding another header byte seems too much overhead to me.
An potential alternative, provided the MTU of the SNDUs is small
enough, which might be the case for DVB-RCS anyhow, could be to limit
the Length field and insert those 2 bits after the D bit. That would
lead to a 8 K maximum size of SNDUs.

Any other ideas and arguments?

Regards,
Bernhard

> Thanks bernhard for your answer,
>
> In fact, even if we use a secure ULE session mechanism, rekeying is
> required during a session.
> PSI/SI is not real time and could not allow synchronized rekeying on the
> fly without SNDU (or MPE section) loss.
> The receiver still needs a flag indicating from which SNDU the new key
> applies.
>
> The requirement for such a control field is specified in the dvb-rcs
> standard (EN 301790) and in EN 301192.
> In EN 301790 section 6.4.6.3, the exact wording for this is as follows :
>
> DVB Multiprotocol Encapsulation sections, according to EN 301 192
> [5], the 2-bit
> payload_scrambling_control field in the section header is used:
> - 00: not encrypted;
> - 01: reserved;
> - 10: encrypted using session key 0;
> - 11: encrypted using session key 1.
>
> Regards
>
>
>
>
>
>
>
> Bernhard Nocker <bnocker@cosy.sbg.ac.at>@erg.abdn.ac.uk on 24/02/2004
> 21:25:15
>
> Veuillez répondre à ip-dvb@erg.abdn.ac.uk
>
> Envoyé par :      owner-ip-dvb@erg.abdn.ac.uk
>
>
> Pour : <ip-dvb@erg.abdn.ac.uk>
> cc :
> Objet :     Re: Encryption control of SNDU
>
>
> Hi,
>
> if it is really required to notify a receiver about scrambled SNDUs I
> would prefer to use another type field value for that purpose instead of
> adding new header fields. But it might be as appropriate to start a S-ULE
> (secure ULE) draft just for that purpose?! Another alternative would be to
> announce the scrambled ULE in the PSI/SI instead of the encapsulation
> header fields.
>
> Kind regards,
> Bernhard
>
> On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote:
>
> >
> >
> > Hi every body
> >
> > The current ULE draft does not address the issue of SNDU
> encryption which
> > we think is important.
> > In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> > necessary, data encryption at MPE level. Some IP/MPE/MPEG products
> already
> > implement this capability (e.g. Alcatel 9780)
> > Encryption is controlled using the 'payload scrambling control' field (2
> > bits) in the MPE header.
> >
> > Consequently, it would be necessary to provision an "encryption-control"
> > field (2 bits) in the SNDU header.
> > This could also facilitate the transition from MPE to ULE
> > Here is a proposal for its definition :
> >    bit 1 : indicates if the SNDU is encrypted or not
> >    bit 2 : indicating the type of encryption (when active) odd/even (to
> >    allow key shift on the fly)
> >
> > Adding 2 bits would require to add a complete byte to the SNDU header in
> > order that the header still an integer number of bytes. If this is not
> > acceptable from a performance point of view, we can envisage to shorten
> the
> > 'length' field from 15 bits down to 13 bits (note that in MPE,
> the length
> > field is 12 bits).
> >
> > waiting for your feedback
> > regards
> >
> > T. Zein
> >
> > ALCATEL SPACE
> > DRT/RST  --  Ingénieur Systèmes
> > Tel : 0534356918  /  Fax : 0534355560
> > Porte : W.220
> >
> >
> >
>
>
>
>
>
>
> T. Zein
>
> ALCATEL SPACE
> DRT/RST  --  Ingénieur Systèmes
> Tel : 0534356918  /  Fax : 0534355560
> Porte : W.220
>
>
>
>