Cryptography Reference
In-Depth Information
Since the broadcast source only transmits one version of an item of broadcast
content, the content encryption key used to encrypt a specific item of content
must be the same for all consumers. Since consumers have different access rights
to digital content, the CEK for two different items of broadcast content must be
different.
The challenge is thus to make sure that only consumers who are authorised
to access content can obtain the appropriate CEK. In order to facilitate this, the
operational constraints that we outlined impose the following key management
design decisions:
Encrypted CEK is transmitted in the broadcast signal
. The most important
reason for this is the need for instant access. The CEK is transmitted along
with the content itself and is made 'instantly available' by being continuously
repeated, perhaps every 100 milliseconds or so. Clearly the CEK cannot be
transmitted in the clear, otherwise anyone receiving the broadcast signal could
obtain it and hence recover the content. Thus the CEK is transmitted in
encrypted form. We will refer to the key used to encrypt the CEK as the
key
encrypting key
(KEK).
CEK is frequently changed
. Once someone has access to the CEK, they can use it
to recover all broadcast content that is encrypted using it. Thus it is important
to frequently change the CEK, for the reasons discussed in Section 10.6.2. In
most video broadcast systems the CEK typically changes every 30 seconds, but
this can happen as often as every five seconds.
CEK is transmitted in advance
. In order to aid synchronisation and instant
access, the CEK is issued in advance of the transmission of any content
broadcast using it. Clearly this cannot be too far in advance because of the
dynamic nature of the authorised consumer base. The compromise is to
constantly transmit two (encrypted) CEKs, which consist of:
1. the current CEK that
is being used to encrypt
the current broadcast
content;
2. the 'next' CEK that will be used to encrypt the next broadcast content.
Hence the content access device has time to recover the next CEK and have it
instantly available as soon as the CEK is changed.
Use of symmetric key hierarchies
. We have already seen that video broadcast
schemes use KEKs to encrypt the CEKs. This of course just 'transfers' the
access problem to making sure that only authorised consumers have access
to the required KEKs. In order to manage this problem in a scalable way,
video broadcast systems use symmetric key hierarchies (see Section 10.4.1),
the details of which we will discuss shortly.
VIDEO BROADCAST KEY ESTABLISHMENT
We now discuss how a video broadcast scheme establishes the KEKs that are
necessary for authorised consumers to obtain the CEKs that they are entitled to.
