Video Broadcasting—Key Management, Security, and Design

Key management for video broadcasting

The primary key management task for digital video broadcasting seems simple when we state it: the keys required to recover broadcast content should be available only to those consumers who are authorized to view the broadcast content. However, several complications combine to make this a challenging task:

• The number of potential consumers: A digital video broadcast network is likely to have a large number of consumers (in some cases, this could be several million), and hence the key management system design must be sufficiently scalable so that it works in practice.

• Dynamic groups of authorized consumers: The groups of consumers authorized to view digital broadcast content are extremely dynamic. Pay-per-view services provide the extreme example of this, where the authorized consumers are likely to be different for every content broadcast.

• Constant service provision: In many applications, a broadcast source will constantly be streaming digital video content, which must be protected. There are no break periods in which key management operations could be conducted. Most key management must therefore be conducted on the fly.

• Precision of synchronization: As we know, stream ciphers require the keys at each end of the communication channel to be synchronized. In digital video broadcasting, this synchronization has to happen between the broadcast source and all authorized consumers (which, as we have just pointed out, could number in the‘millions’). This synchronization must be close to being perfect. Otherwise, some consumers may incur a temporary loss of service.

• Instant access: Consumers normally want instant access to broadcast content and will not tolerate delays imposed by key management tasks. A good example of the extreme nature of this problem arises in the case of subscription services, where consumers often choose to select a series of different broadcast channels, each for a very short period of time, to make a selection (often referred to as ‘channel surfing’). Since these different channels need to be encrypted using different encryption keys, the content access device needs instant access to all the relevant decryption keys.

We will now examine how digital video broadcasting systems typically address these challenges.

Video broadcast key management system design

All video broadcast content must be encrypted during transmission. This must be done by using a symmetric key, which we will refer to as the content-encryption key (CEK). Since the broadcast source only transmits one version of an item of broadcast content, the content-encryption key used to encrypt a specific content item must be the same for all consumers. Since consumers have different access rights to digital content, the CEK for two different broadcast content items must be different.

The challenge is thus to make sure that only consumers who are authorized to access content can obtain the appropriate CEK. To facilitate this, the outlined operational constraints 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 ms or so. The CEK cannot be transmitted in the clear. Otherwise, anyone receiving the broadcast signal could obtain it and 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 encrypted using it. Thus, it is important to frequently change the CEK for these reasons. In most video broadcast systems, the CEK typically changes every 30 s, but this can happen as often as every 5 s.

• CEK is transmitted in advance: To aid synchronization and instant access, the CEK is issued in advance of transmitting any content broadcast using it. This cannot be too far in advance because of the dynamic nature of the authorized consumer base. The compromise is to constantly transmit two (encrypted) CEKs, which consist of:

  1. The current CEK 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. That, of course, transfers the access problem to ensure that only authorized consumers have access to the required KEKs. To manage this problem in a scalable way, video broadcast systems use symmetric key hierarchies.

Video broadcast key establishment

We now discuss how a video broadcast scheme establishes the KEKs necessary for authorized consumers to obtain the CEKs they are entitled to.

As previously mentioned, video broadcast schemes use symmetric key hierarchies. At the top of each of these hierarchies are keys shared only by the broadcast provider and a particular consumer, referred to as consumer keys (CKs). In a simple system with relatively few consumers, these CKs could encrypt the KEKs. However, there are two reasons why this is not very practical:

1. Most video broadcast systems have so many consumers that sending an encrypted KEK in this way would require too much bandwidth, since a unique ciphertext would have to be sent for each consumer.

2. Each KEK itself must be frequently changed for similar reasons to the CEKs. This might happen, say, on a daily basis. Thus, the bandwidth problems are further exacerbated by the need to frequently update the KEKs.

The compromise is to deploy zone keys (ZKs), which are keys shared by groups of consumers. Zone keys have longer lifetimes than KEKs but shorter lifetimes than CKs. A relevant ZK is initially sent to a consumer encrypted using their CK. The consumer then uses the ZK to recover KEKs used to recover CEKs. When a ZK needs to be changed, the new ZK needs to be sent to every consumer who requires it, but this event occurs much less frequently than for KEKs (which in turn occurs much less frequently than for CEKs).

The consumer keys, which sit at the top of these key hierarchies, are stored on the smart cards of the content access devices. They are thus established before issuing the smart cards to the consumers. A simple example set of key hierarchies is shown in the illustration below. In this example, there are five consumers, divided into two zones. In practice, multiple layers of zone keys can be deployed to enhance scalability.