INTERNATIONAL TELECOMMUNICATION UNION FOCUS GROUP ON IPTV
TELECOMMUNICATION FG IPTV-C-0490
STUDY PERIOD 2005-2008 English only
WG(s): 3 4th FG IPTV meeting:
Bled, May 7th-11th, 2007
Source: Huawei Technologies Co., Ltd.
Title: Alternative Key Management Algorithm and Effective Group Policy Distribution
Key Management System (KMS), as an important component for both DRM and CA system, will
be focused on this contribution document. Several hierarchical key management algorithms will be
introduced to achieve performance efficiency. Algorithm friendly interface and media path rekeying
are also recommended in this document.
A Content Security Requirement, Separation of KMS and License Issuer, has been inserted to IPTV
output document. In the contribution document, entitled with “End-to-End IPTV Security: Assets,
Risks and Threats” [FG.IPTV-C-0217], KMS is regarded as part of cryptographic assets. The
functionality of KMS was further summarized as authentication, key installation, pair-wise key
establishment, group key establishment, end-system revocation and identity replacement. As one of
the most challenge IPTV sub-system, KMS should have strong security, reliability and scalability.
KMS should also remain low operating expense without excessive consumption of communication
resources. In this contribution, we will focus two important issues of KMS, key management
architecture and group key distribution.
A naive scheme for group key management is assigning one symmetric key for each user. In order
to establish traffic encryption key (KTEK), KMS need broadcast KTEK, which is encrypted with each
member’s symmetric key. Bandwidth consumption lineally increases with increase of group
members. When the number of group members becomes very large, the disadvantage of naive
scheme is obvious. A more efficient idea uses auxiliary keys to build key hierarchy. End users store
their auxiliary keys and decrypt traffic encryption key from group key refresh message. This
scheme achieves extensibility by balancing key storage and message transmissions. [RFC2627]
gives a briefly description to this idea and “Hierarchical Tree Approach” is recommended to solve
large group key management.
Logical Key Hierarchy [LKH] is such a protocol and the first practical broadcast encryption
scheme. Bandwidth overhead of LKH is 2R*Log(M), where R is the number of revoked users and
M is the total number of current members. More interesting broadcast encryption algorithms are
Subset Cover and Subset Differentiate. Another key management algorithm, named Stateful Subset
Cover, has been presented on ACNS 2006. According to public material, it outperforms in overhead
Contact: Xu Chen, Ya Liu Tel: +86-10-82836074
Huawei Technologies Co.,Ltd. Fax: +86-10-82836284
China Email firstname.lastname@example.org
Attention: This is a document submitted to the work of ITU-T and is intended for use by the participants to the activities of ITU-T's
Focus Group on IPTV, and their respective staff and collaborators in their ITU-related work. It is made publicly available for
information purposes but shall not be redistributed without the prior written consent of ITU. Copyright on this document is owned by
the author, unless otherwise mentioned. This document is not an ITU-T Recommendation, an ITU publication, or part thereof.
reduction, which practises in network bandwidth limited system. The following figure shows
overhead of each algorithm.
Fig 1. Algorithm Performance Comparison [SSC-ACNS 2006]
Another important issue of KMS is dealing with user’s registration application and distributing
traffic key refresh message to authenticated users. Just as state above, naive scheme for group key
management is not acceptable for large scale user group. A more practical solution for KMS is
deploying hierarchical key management. Then the question degenerates to select and apply the best
hierarchical key management algorithm. However, algorithm selection for IPTV KMS becomes a
challenge job, since it should care many factors, such as total number of IPTV subscribers,
subscriber change frequency and change scale, etc. We cannot make sure one of them works in all
the scenarios that IPTV implementors would face. An elegant solution to support variable key
management algorithms is making group key management protocol(GKMP [RFC2093]
[RFC2094]) provide algorithm friendly interface. Algorithm alternation will cause minor change to
GKMP. The following figure shows this method.
Fig 2. Algorithm Friendly Interface for Group Key Management Protocol
A second problem for KMS is to key traffic encryption protocol. IETF MSEC Working Group has
standardized a number of GKMPs. These protocols (e.g. MIKEY, GDOI) responds to deliver group
policy to traffic encryption protocols. Each algorithm works in some set of circumstances.
Currently, IPSec, SRTP, ISMACrypt are three candidate protocols to process traffic encryption.
When GKMPs is used to distribute IPTV traffic encryption policy, how to key traffic encryption
protocols is still not clear. For an example, SRTP, as a candidate traffic encryption protocol, is
chosen for DVB condition access protocol and OMA BCAST layer 4 protocol. It is possible to
perform content encryption with SRTP for IPTV DRM use. IETF RTPSec BoF already focuses on
RTP Security problem and there has been a few ways for SRTP “master key” delivery, which
involves of utilizing signalling channel, media channel or hybrid signalling and media channel.
Furthermore, in some wireless circumstances, bi-directional channel is scarcity resource. As a
result, Long Term Key (such as KEK) is pulled over interactive bi-directional channel. Short Term
Key (STK), such as “content key”, pushes through the same path as media, e.g. same UDP port.
STK update message can also benefit from sharing same UDP port, when NAT or Firewall
transversal is required. In this case, extension RTCP to carry KEK protected “content key” [EKT]
and broadcast through broadcast channel is a feasible substituted solution. However, hierarchical
key management makes case complex. Group key refresh message includes a sequence of subset
identifiers and correlated cipher text. EKT solution designs specifically for carrying KEK protected
STK and not ready to carry cipher text sequence. Moreover, from bandwidth point of view, RTCP
sent from media sender is around 3.75%. Group key refresh message transmitting over RTCP would
be great constrained by the available bandwidth. A more proper solution, which modelled STUN
solution, group key refresh messages are multiplexed to RTP channel and transmitted over media
In this contribution, many implementation factors to key management system are illustrated. As a
challenge component of IPTV system, we propose WG3 to consider inserting following
requirement to Content Security Requirement section of working group document and do some
further research in this area.
IPTV_SEC_XXX: Key Management System should adopt hierarchical key management scheme to
achieve performance efficiency.
IPTV_SEC_XXX: Key management algorithm should design for scalability, reliability and
IPTV_SEC_XXX: Group Key Management Protocol should support hierarchical key management
and key management algorithm alternative.
IPTV_SEC_XXX: Short Term Key distribution should adopt media path key exchange with
respect to NAT transversal case and bandwidth limited system.
[FG.IPTV-C-0217] M. Baugher, J. Goldberg, "End-to-End IPTV Security: Assets, Risks and
Threats", FG IPTV-C-0217, Cisco System Inc.
[RFC2093] H. Harney, C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification",
RFC2093, July 1997
[RFC2094] H. Harney, C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture",
RFC2094, July 1997
[RFC2627] D. Wallner, E. Harder, R. Agee, "Key Management for Multicast: Issues and
Architectures", National Security Agency, June 1999
[SSC-ACNS 2006] M. Johansson, G. Kreitz and F. Lindholm, "Stateful Subset Cover", School of
Computer Science and Communication, Royal Institute of Technology, ACNS’ 06, June 8
[LKH] C.K. Wong, M. Gouda, and S.S. Lam, "Secure group communications using key graphs, " in
Proceedings of the ACM SIGCOMM ’98 conference on Applications, technologies, architectures
and protocols for computer communication, pp. 68-79, ACM Press, 1998.
[EKT] D. McGrew, F. Andreasen, from Cisco Systems, Inc., L. Dondeti, from QUALCOMM,
"Encrypted Key Transport for Secure RTP", draft-mcgrew-srtp-ekt-02, March 4, 2007.