Re: Security Considerations section for

[Haitham Cruickshank <H.Cruickshank@eim.surrey.ac.uk>]

Hi Gorry and Rod,

Here are some extra comments and I really hope they are helpful:

Gorry Fairhurst wrote:

> OK here is my take on the coping:
>
> Rod.Walsh@nokia.com wrote:
>
> >I think it is a wonderful idea to properly consider IPDVB security requirements. I would just like a sanity check that I still understand the field of what the group would consider. Are these statements about right?
> >
> >* IP-layer/level security (IPsec, MSEC, etc) provides a handful of solutions. Use of these and further specification of IP-layer security is beyond the IPDVB solution scope.
> >
> - These are IP-level solutions, it would be reasonable to advocate their
> use, both with MPE, ULE and any associated network protocols. I would
> suggets it *is* reaonable to discuss these in the context of this list -
> If there is (which I have no indication of) any further development work
> required to update the specs specifically for DVB/MPEG-2, the actual
> work would probably be done within a security area working group.

Yes that sound very good statement.

>
>
> >* security above IP-layer (DRM, SRTP, etc) are well beyond IPDVB solution scope.
> >
> - Agreed.
>
> >* security on MPEG-2 TS (CA, etc) is beyond IPDVB (and IETF) solution scope.
> >
> - The set of currently defined mechanisms will not be re-specified or
> developed within this WG under the Charter specified. It was my
> understanding that Conditional Access (CA) systems are generally
> proprietary, and few target IP services.

The exact status of Conditional Access in DVB standards is: The DVB specification defines the algorithm to use to scramble a DVB stream: it is called the DVB Common Scrambling Algorithm (DVB-CSA).  This algorithm is standardized but is not public.  Technical details of the scrambling algorithm are only made
available to bona-fide users upon signature of a Non-Disclosure Agreement (NDA) administered by the Custodian (ETSI).

In plain english, you have to pay a large amount of money to see the DVB-CSA details.

>
>
> >* If necessary, ULE security mechanisms would be IPDVB solution scope.
> >
> >
> - Yes, the transport of encrypted IP data is within scope.
> - Security also need to be considered in respect of the control
> protocols used to provide the IP service....

Yes control protocols is a good point.

>
>
> >Am I roughly on target with these?
> >
> >
> Yes, that's a useful summary.
>
> >If so, then the use of the IPDVB Security Requirements is clear to me: 1. assess whether any IPDVB security requirements should be met by the ULE-layer and the IPDVB deliverables that would be needed for this; 2. for other IPDVB security requirements determine whether additional work in other WGs is necessary.
> >
> >BTW, it may also help to describe any security problems MPE deployments currently leave open. (Currently I am ignorant of any in MPE-layer scope).
> >
> >
> - Any inputs from the list?

Here is some limited input on the security problems with MPE deployments:

DVB-CA is mainly implemented in the MPEG-TS layer.  The MPE security procedures are defined in the current DVB-RCS standard (ETSI EN 301 790). The MPE security major problem is that security features are optional. Therefore (I think) many people do not implement them.  Another problem is that there is not efficient
support for secure multicast (secure group communication).



>
>
> >Cheers, Rod.
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: owner-ip-dvb@erg.abdn.ac.uk
> >>[mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> >>Behalf Of ext Allison, Art
> >>Sent: Thursday, March 25, 2004 6:01 PM
> >>To: 'ip-dvb@erg.abdn.ac.uk'
> >>Subject: RE: Security Considerations section for
> >>
> >>
> >>
> >>Sniped part and replied..
> >>
> >>Art
> >>::{)>
> >>Art Allison
> >>Director Advanced Engineering
> >>NAB
> >>1771 N St NW
> >>Washington DC 20036
> >>202 429 5418
> >>
> >>
> >>-----Original Message-----
> >>From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> >>Sent: Thursday, March 25, 2004 4:48 AM
> >>To: ip-dvb@erg.abdn.ac.uk
> >>Subject: Re: Security Considerations section for
> >>
> >>I'm quite happy to try to summarise the security thread - or
> >>get someone
> >>else to - I'll leave it a few days to see if there are any
> >>comments/issues
> >>from other people to add.
> >>
> >>I have a small number of questions for clarifications...
> >>...
> >><snip>
> >>
> >>Art Allison wrote:
> >>
> >>
> >>>Second, it seems out of scope to put elements in the RF
> >>>
> >>>
> >>emissions that
> >>
> >>
> >>>belong in the contribution process. It seems that you are
> >>>
> >>>
> >>concerned about
> >>
> >>
> >>>attacks on the data flow up to the RF emission. This is a valid and
> >>>important concern; but seemingly not relevant to a light
> >>>
> >>>
> >>weight emission
> >>
> >>
> >>>Protocol.
> >>>
> >>>
> >>Gorry Fairhurst asked:
> >>Would such contribution feeds normally use MPEG-2 transmission?
> >>AA responds> They generally do although not necessarily in
> >>strict compliance
> >>with the MPEG-2 transport standard. Often 45Mpbs per RF
> >>channel with higher
> >>profile and level is used so that the content can survive decoding and
> >>recoding. Some are distributing at payload rates. ATM is used
> >>by some (with
> >>MPEG-2 packet mapping onto the ATM cells).
> >>
> >>Gorry Fairhurst asked:
> >>To what extent do you envisage these TV contribution feeds to carry IP
> >>packet data?
> >>
> >>Art responds>
> >>Perhaps lots, perhaps little, but MUCH more importantly the
> >>contribution
> >>contains very valuable content to the broadcaster, that
> >>normally they are
> >>contractually bound to protect anyway. It contains the A/V
> >>programming and
> >>lots of folks would like to rip that off. So, I would specify that
> >>everything in the contribution link be protected with
> >>encryption and that
> >>further I would not want it to be standard as that increases
> >>the size of the
> >>target for attackers. The two ends of a contribution link
> >>have always worked
> >>best when they come from the same vendor anyway.  There are several
> >>approaches to protect an entire link, but protection of this
> >>feed is not the
> >>job of the particular type of content embedded therein.  If
> >>you assert that
> >>you should put protection on ULE content type, to be
> >>logically consistent
> >>you would have to assert that each content type have a
> >>protection scheme at
> >>this layer.
> >>If the threat is significant enough, (and for the
> >>contribution link I agree
> >>it is) protect it ALL.
> >>But that protection-for-it-all is out of scope here and is
> >>already being
> >>used today (I am not aware of any in-the-clear contribution
> >>links in the
> >>US.)
> >>
> >>
> >>
> >>
> >
> >
> >
> >

--
Dr. Haitham S. Cruickshank

Senior Research Fellow
Communications Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/