[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Flat Multicast Key Exchange (FMKE)"- Internet Draft
Hi Gorry and IP-DVB colleagues,
Dr G Fairhurst wrote:
> Thanks Haitham for your inputs!
>
> I was wondering whether anyone else had given thouughts as to whether there
> was a need for a specific key management protocol for MPEG-2 transmission?
I think the most well known security system is DVB-S CA (Conditional Access). The
system was designed to be simple and fast to cope with DVB MPEG-TS payload
encryption/decryption. As you know, it uses master/session key concept using EMM/ECM
(Entitlement Management Message /Entitlement Checking Message) plus smartcard key.
>
>
> Various people have in the past commented on the current MPEG-2 encryption
> systems being inappropriate for IP data,
Currently MPEG-TS payload encryption is used on TV broadcasts. I think on principle,
MPEG-2 encryption can be used for IP data in the MPE level. Of course the question of
efficiency is another matter.
Also the MPEG-2 encryption is a proprietary system, so there is no way to fully test its
security strengths and weakness. On the other hand, the use of DES or AES in IPSEC is
good because these encryption algorithms had been well tested.
> but I don't see a clear
> consensus yet
> on exactly what needs to be fixed.
I can tell my opinion about what needs to be fixed. The MPEG-2 encryption is OK, but
the key management is the problems, where the whole DVB-CA system relies on the
smartcard in set top boxes being temper proof and relies on a permanent secret key
stored in the smartcard. This must change and a new security management system should
be used with NO NEED FOR PERMANENTLY STORED SECRET KEYS.
Therefore security frameworks such as GDOI, GSAKMP or Alcatel's FMKE can used to
replace the existing system
>
>
> Is this an Internet Protocol issue (e.g. IPSEC)?
The key management can be GDOI, GSAKMP/FMKE
>
>
> Is it a MPEG-2/DVB/ATSC issue?
Data encryption is MPEG-2/DVB/ATSC
>
>
> Please send comments and questions to this list. I'd like to get a feeling
> on how important this is to people, and what exactly people want to be done.
I would like to hear other peoples opinions on this subject, please.
Best wishes.
Haitham
>
>
> Best wishes,
>
> Gorry Fairhurst
>
> > Laurence.Duquerroy@space.alcatel.fr wrote:
> >
> > > Hello,
> > >
> > > In the context of the SatIP6 IST project, Alcatel Space studies a multicast
> > > security scheme optimised to protect large multicast groups. Such a scheme is
> > > designed for IP over Satellite, Wifi or DVB systems; it is a security solution
> > > for the satellite segment. An implementation over DVB-S/RCS is planned in the
> > > SatIP6 demonstrator.
> > > We have presented this security solution (called SatIPSec) during the ESA
> > > workshop at ESTEC, 13-14 May on "IP networking over satellite".
> > >
> > > We have started to write an Internet Draft detailing our key exchange protocol
> > > (called "Flat Multicast Key Exchange (FMKE)"), and we think that it could be
> > > submitted to the "IP over DVB " group, as IP over DVB systems are targeted
> > > systems. We would be ready to present it to the next IETF meeting (in Vienna).
> > > As it is very security-oriented, it will probably also be submitted to an IETF
> > > security group (i.e. MSEC (Multicast Security) WG).
> > >
> > > You will find in attachment a draft of the ID. Your comments, opinion, and
> > > feedback on it are welcome.
> > > (See attached file: draft-duquer-fmke-00.doc)
> > >
> > > This solution is very flexible. It is able to configure any security dataplane
> > > at layer 2 or 3 ( IPv4/6 IPSec, L2 security dataplanes...).
> > > It is based on similar principles to the ones of the protocols currently defined
> > > in the IETF MSEC group. It uses also similar messages (based on the ISAKMP
> > > standard protocol). However it implements additional mechanisms and features in
> > > order to provide a security solution optimized for satellite systems:
> > >
> > > - It is defined to be low ressource consuming in bandwidth
> > > - It provides a reliable key distribution ( unlike the GDOI and GSAKMP
> > > protocols)
> > > - It can be used in one-to-many and many-to-many scenarios, and is
> > > scalable in these scenarios (MIKEY cannot be used in many-to-many scenarios in
> > > large groups)
> > > - It provides a multicast re-keying (mandatory in large groups) (unlike
> > > MIKEY)
> > > - etc
> > >
> > > We hope that you will find interest in it, and thank you in advance for your
> > > comments.
> > >
> > > Best regards,
> > >
> > > Laurence Duquerroy
> > >
> > > ALCATEL SPACE
> > > RT/ST
> > > Research Department / Advanced Telecom Satellite Systems
> > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60
> > > E-Mail : laurence.duquerroy@space.alcatel.fr
> > >
> > > ------------------------------------------------------------------------
> > > Name: draft-duquer-fmke-00.doc
> > > draft-duquer-fmke-00.doc Type: WINWORD File (application/msword)
> > > Encoding: base64
> > > Description: Mac Word 3.0
> >
> > --
> > Dr. Haitham S. Cruickshank
> >
> > Senior Research Fellow in 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/
--
Dr. Haitham S. Cruickshank
Senior Research Fellow in 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/