See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221135076

Broadcast encryption versus public-key cryptography in content protection

systems

Conference Paper · November 2009

DOI: 10.1145/1655048.1655055 · Source: DBLP

CITATIONS READS
4 354

1 author:

Jeffrey Lotspiech
Lotspiech.com, LLC
69 PUBLICATIONS 2,153 CITATIONS

SEE PROFILE

All content following this page was uploaded by Jeffrey Lotspiech on 04 June 2015.

The user has requested enhancement of the downloaded file.

 Broadcast Encryption versus Public-Key Cryptography
in Content Protection Systems
Jeffrey B. Lotspiech
Lotspiech.com, LLC
2858 Hartwick Pines Drive
Henderson, Nevada
011-702-263-2450
jeff@lotspiech.com
ABSTRACT
Broadcast encryption and public-key cryptography are two
competing key management schemes. Both are in use today,
although public key is much more pervasive (pervasive in the
number of systems, not necessarily in the number of devices). In
certain applications, especially the content protection or “Digital
Rights Management” application, broadcast encryption seems to
offer real advantages. In the last two or three years, advances
have been made which offer new functionality to broadcast-
encryption systems: a “signature-like” function, a device
authentication protocol, “unified media key blocks” enhancing
forensics, and “security classes”. These new advances are
summarized in this paper. The device authentication protocol has
not previously been described in the academic literature, although
it has been proposed in commercial systems.
The author believes the reason that broadcast encryption has not
been used more frequently in content protection is more due to
system designers being unfamiliar with it, and less due to any
advantages of public-key cryptography. The author hopes that this
paper might begin to reverse this trend.
Categories and Subject Descriptors
J.5 [Computer Applications, Arts and Humanities]
General Terms
Security
Keywords
Broadcast encryption, tracing traitors, content protection, DRM.
1. INTRODUCTION
Seven years ago, Stefan Nusser, Florian Pestoni, and I wrote
a magazine article entitled “Broadcast Encryption’s Bright
Future”[1]. Back then, there was no way to use broadcast
encryption key management to do something analogous to a
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
DRM’09, November 9, 2009, Chicago, Illinois, USA.
Copyright 2009 ACM 978-1-60558-779-0/09/11...$10.00.
39
public-key signature. There was no broadcast-encryption-based
authentication protocol. And, while there were forensic tests to
discover the broadcast-encryption keys an attacker had
compromised during an attack, the number of tests was cubic in
the number of identities the attacker had subsumed. Since then, all
these limitations have been overcome: there is “signature-like
primitive” that works with broadcast encryption keys; there is an
authentication protocol; and the number of forensic tests
necessary to discover the attackers’ keys is now linear in the
attackers’ identities. The purpose of this paper is to update the
original magazine article and describe these new advances. Along
the way, it will also contrast the broadcast-encryption approach
versus the public-key approach. Not surprisingly, it will conclude
that broadcast encryption’s future is still bright.
The term “broadcast encryption” gets its name from the title
of a paper Amos Fiat and Moni Naor wrote in 1993[2]. In this
paper they asked the question: can two parties, who have not
communicated before, agree upon a key without having a two-
way conversation? The answer was “yes”, and they used the word
“broadcast” to capture the one-way nature of the protocol. It did
not necessarily imply a one-to-many transmission. In fact, to my
knowledge, broadcast encryption has never been used to actually
protect commercial broadcasts. Broadcast encryption has been
used widely, however, to protect commercial entertainment
content on physical media like DVDs. The reason is obvious;
public key cryptography simply does not work—assuming the
application cannot demand Internet connectivity for all the
players. Replicators produce encrypted discs and players play
them without any opportunity to have a handshake with the
replicator; this is a classic one-way flow that broadcast encryption
was designed to handle. Although the original DVD protection
scheme, the Content Scrambling System (CSS), was invented
prior to the invention of broadcast encryption, subsequent
schemes, such as the ones used on DVD recordable discs and the
new Blu-ray high-definition optical discs, use it. It is also used in
every Secure Digital (SD) flash memory card, so literally billions
of devices have been manufactured with built-in broadcast
encryption key management. The major commercial systems are
Content Protection for Recordable Media (CPRM)[4], which
protects DVD recordable discs and SD cards, and Advanced
Access Content System (AACS)[3], which protects Blu-ray and
HD-DVD discs.
 How does broadcast encryption work? There are many
schemes, but they each begin by some agency subdividing the
participating devices into subsets. Each device is in many subsets.
Each subset is associated with a cryptographic key. A device
knows the key for every subset it belongs to. Then the agency
generates random media keys and produces media key blocks
(MKBs)1. An MKB is simply a selection of subsets of devices
such that the subsets cover all of the non-compromised devices in
the system, and none of the subsets contains single compromised
device. Figure 1 below illustrates how an agency might select
subsets of a universe of devices to exclude the compromised
devices (the X’s in this figure).
X
X recording was made, then that compromised player will be able to
X protecting content on physical media, but there are techniques that
subsets
compromised
devices
DEVICES
Figure 1. A Broadcast Encryption Scheme Excluding
Compromised Devices
In addition, the MKB contains a list of encryptions of a
media key with each of the selected subset keys. Given an MKB,
a device searches it until it finds a subset it belongs to. Then it
knows both how to index into the list of media key encryptions
and which subset key to use to decrypt this entry. Any two
uncompromised devices will calculate the same media key,
although, unless they are in the same subset, they will not
calculate it in the same way. Figure 2 below illustrates an
example media key block identifying subsets i, j, and k, and after
each subset identifier, the encryption of the media key Km in the
2
particular subset key , for example, Ki.
i e(Ki, Km) j e(Kj, Km) k e(Kk, Km)
Figure 2. An Example Media Key Block Syntax
There is a trivial broadcast encryption scheme where every
device is alone in a single-device subset. That means every device
only needs to store a single key, but the size of the MKB is huge;
it is proportional to the number of unrevoked devices in the
system. Some would not even call this degenerate case a
1
The original Fiat and Naor paper called them “session keys” and
“session key blocks”.
2
Actually, the media key is exclusive-or’ed with the subset
identifier before being encrypted, to avoid encrypting multiple
keys with a single value and thus allowing an attack called the
Birthday Paradox Attack.
broadcast encryption scheme. Certainly, all practical broadcast
encryption schemes have found ingenious ways to trade-off the
number of keys the devices knows (the number of subsets it is in)
with the size of the MKB required for a given set of revoked
devices.
With this background, you can imagine how a recorder can
make a recording, and a player can play it back, without having to
have a two-way handshake to agree upon a key: the recorder
stores a MKB on the media3 and then encrypts the content with
either the media key itself, or with a another random key
encrypted by the media key. For playback, the player merely
processes the MKB to get the necessary key to decrypt the
content. The recorder has confidence that no compromised player
will be able to play the content, because it will be unable process
the MKB. Of course, if a player is compromised after the
play the recording—or, more likely, decrypt it so it can be
distributed in the clear. This is an unavoidable fact of life when
can mitigate it in many cases. We will return to this topic in
section 3.
In the first non-trivial broadcast encryption schemes, a given
device was in dozens of subsets, and therefore stored dozens of
keys. MKBs were also relatively large, for example the MKB for
DVD Audio is 3 MB. Then, in 2001, the subset-difference
broadcast encryption scheme was invented[5]. In this scheme, a
device is literally in billions of subsets, but thankfully does not
have to store the keys for all of them. Instead, the subsets are
organized in a tree structure so that any two subsets are either
completely disjoint, or one is a subset of the other. A subset key is
always a one-way function of the key used in the next higher
subset, greatly reducing the number of subset keys a device has to
store. With so many subsets to choose from, the agency can
produce MKBs whose size is linear in the number of devices
being revoked. This is the best one can do, and is exactly
comparable to a public-key certificate revocation list in this
respect.
It is no accident that the examples we have chosen so far are
from content protection (or, if you like, “digital rights
management”) applications. The content protection application is
… an excellent match for broadcast encryption4. As previously
mentioned, it is essential for physical media, but it is useful even
in situations where two-way conversations between devices are
possible. Often, in a public-key content protection system,
devices exchange their public-key credentials not to actually
identify themselves, but instead to prove to each other that neither
is on the revocation list. They want to know that the device they
are connecting to is compliant; it is not a circumvention device. In
3
Alternatively, the blank media can be manufactured with MKBs
already recorded on them. For example, SD card manufacturers
place 16 MKBs on each card at manufacturing time. These
different MKBs are used for different content protection
applications, like video, audio, publishing, etc.
4
In our original magazine article, I wanted to call content
protection the “poster child” application, but my co-authors
talked me out of it. I guess they are not here for this one.
40
both public-key systems and broadcast-encryption systems, there
is an implicit assumption that circumvention devices will be
revoked. However, revocation in a broadcast-encryption system is
inherent in its MKBs and therefore automatically tied to the
content being protected. A public-key revocation list is not
automatically tied to anything; special measures have to be taken
in a public-key content protection system to make sure that new
content is tied to the latest revocation list. So, what happens
indirectly and occasionally even incorrectly in a public-key
system, happens directly and inevitably correctly in a broadcast-
encryption system.
It is not just that broadcast encryption is more
straightforward in applications where compliance is the issue;
there is an even more compelling advantage: the calculations
involved in broadcast encryption can be done completely with
symmetric encryptions and decryptions. This means that the
calculation overhead can be literally 1000x less, compared to the
elliptic curve versions of public-key cryptography that the
consumer electronics companies favor.
To be honest, there is nothing about broadcast that inherently
demands that it use symmetric key cryptography. Each subset
could be associated with a public/private key pair; the devices
knowing the private key for each subset they belong to. In such a
system, anyone can generate an MKB because the public keys of
the subsets can be published. Even the subset-difference scheme,
which requires these private keys are related by one-way
functions, has a public-key version[13]. Nonetheless, these
approaches have languished, unable to find a compelling
application. Content protection is not such an application; in
content protection, it is a positive advantage that only the
licensing agency can produce a valid MKB. In this paper I will
assume that “broadcast encryption” means “symmetric-key
broadcast encryption”.
Why worry about the performance of symmetric-key
cryptography versus public-key cryptography? There is an
argument that says that over time, devices get more powerful, and
even significant differences like 1000x will be overcome by
improved silicon. That might be true, but it also seems like each
new silicon advance leads to a new class of devices that are near
the limit of the technology, where issues like battery life and
delay times are directly affected by calculation overhead.
The remainder of this paper is organized as follows. Sections
2, 3, 4, and 5 describe new advances in broadcast encryption.
Section 6 discusses some disadvantages of broadcast encryption
compared to public-key cryptography. Section 7 is the conclusion.
2. THE “SIGNATURE-LIKE” PRIMITIVE
Broadcast encryption is inherently anonymous. Any
uncompromised device can process an MKB and come up with
the same key. That key does not identify them, but possession of
that key proves they are compliant. A device can authenticate a
message using a message authentication code (MAC) based on
that key. That means that a compliant device authenticated the
message, but it does not prove which device made the attestation.
This might suffice. To return again to our favorite application, if a
recorder attests with a MAC that a recording has “unlimited
41
moves” that is sufficient. The recorder is compliant (or else it
could not have calculated the key), and compliant devices play by
the rules.
However, there are situations where you do not want to trust
“any device in the system”. A classic case is the version number
in the MKB. Devices that store MKBs refer to the version number
to make sure they always have the latest one they have seen. If
any device could attest for the version number, than the first
compromised device might be able to flood the system with
down-level, but purportedly recent, MKBs and avoid getting
revoked. In AACS, the licensing agency signs each MKB using
an elliptic curve digital signature algorithm. Thus, AACS is
actually a hybrid system, using broadcast encryption for the
fundamental protection on the content, but using public-key
calculations for MKB versions, for content certificates, for
download servers, and for device authentication (see section 3).
The mechanism to achieve a signature-like attestation with
broadcast encryption[9] is actually quite simple, especially if it is
the licensing agency (the agency that produces MKBs) which is
attesting to a message. The licensing agency simply exclusive-ors
a hash of the message with each subset key before encrypting
with the media key in each MKB they produce. If the message has
been tampered with, each subset will calculate the wrong key, and
this wrong key will be different from subset to subset5. So, if the
message is the version number in the MKB, and the attackers
change the version number, the MKB is corrupt and unusable.
Of course, the attackers might have compromised some
devices and this is not yet known by the licensing agency. Then,
the attackers will know the keys for one or more of the subsets in
use in the most recent MKBs. They can modify an MKB and it
will be convincing to those devices that are in the same subset(s)
of the device(s) they have compromised. However, the licensing
agency controls the number of subsets in the MKBs, so they can
make sure that this attack does limited economic damage.
A second rule also mitigates against this attack: if a device
encounters two conflicting attestations from different MKBs, then
it should believe the MKB in which it is in the smaller subset. It is
best to explain this with an example. Suppose the “message” the
licensing agency is attested to with a given MKB is the version
number of the MKB, and the system is at version 10. The
attackers compromise some devices and modify version 10 MKBs
so they are now version 1000. Those devices in the system that
are in the same subsets that the attackers have compromised find
these new MKBs valid; however, all the other devices in the
system do not, so this is mainly a denial of service attack. The
licensing agency examines the fake MKB and sees which subsets
have been compromised. It releases new MKBs at version 11,
where those compromised subsets have been subdivided—
perhaps even down to individual devices. Devices that accepted
5
This is a slightly different formulation than the one in the
referenced paper[9], and improves on it. In that original paper,
after a message had been tampered with, each subset of devices
would still calculate the wrong key, but they would all calculate
the same wrong key. In certain situations, attackers might be
able to take advantage of this.
the erroneous version 1000 MKB will discard it when they see the
new version 11 MKB. Even though the version number is less,
they are in a smaller subset so they accept it as the truth. If the
attackers continue with the attack, they increasingly identify their
compromised keys, and the attack affects fewer and fewer
innocent devices.
Binding Table
MKB “signature”
“Public key”
+hash E of course, each side has to tell the other what its device identifier
+hash E is, in order for the other device to figure out what subset it needs.
+ E
hash
k1 k2 k3 . . . kn
…
…
Km
+ E
hash
Figure 3. An Example Third Party Signature
If the broadcast encryption scheme in use has the property
that the device subsets are disjoint, then there is an easy way to
extend the signature-like mechanism to arbitrary third parties.
This is not a difficult restriction; all the commercial systems and
all the new schemes have this property. The idea, illustrated in
Figure 3, is that the subsets, instead of all calculating the same
media key, calculate instead other random keys Ki, each subset
calculating its own Ki. The licensing agency produces a set of
MKBs and gives them, and their associated Ki’s, to a third party.
The licensing agency uses its signature-like mechanism to attest
to both the version number of the MKB and who it gave it to. In
other words, the Ki’s are not correctly calculated if either of those
things is tampered with. The third party then can produce a table
of a media key encrypted with each of the Ki exclusive-or’ed with
the hash of the message the party wants to attest to. These tables
are called binding tables.
3. AN AUTHENTICATION PROTOCOL
Since the beginning of commercial broadcast encryption
starting with SD cards, there has always been a broadcast-
encryption-based “device authentication” protocol[4]. The host
reads the MKB on the SD card and now both the host and the
micro-controller on the SD card know the media key. The host
sends a nonce to the SD card’s controller, and the controller
responds with another nonce. Based on the common media key,
the two nonces, and an identifier on the SD card, both sides
calculate a common session key. Protected data is then encrypted
with the session key across the bus between the host and the card.
Technically, though, this is not an “authentication” protocol; a
better term would be a compliance protocol. Both sides prove
they are compliant and unrevoked, but neither side proves its
identity. An unrevoked circumvention device pretending to be an
42
SD card could pick a random identifier and the host would be
none the wiser.
Recently, however, a true authentication protocol has been
developed. This has been discussed commercially, but, to my
knowledge, this is the first time it has been described in an
academic paper. The idea is that each side has access to a
different MKB, and they parse their MKB for the other side. In
other words, they figure out the subset the other side needs, and
send only the subset identifier together with the single encryption
of the media key that goes with that subset. In order for this work,
Once this initial exchange of parsed MKBs is complete, then both
devices know the two media keys and use them, together with
nonces, to derive a session key. After the protocol completes, if
one device has a down-level MKB, the device with the more
recent MKB sends it, encrypted in the session key.
With this protocol it is impossible for a device to continually
lie about its device identifier, although it might get away with it
one time. When the licensing agency encounters an obvious
circumvention device it observes what device identifier it is
claiming. The agency then produces an MKB where that device is
in a subset all by itself. If the device is telling the truth about what
keys it has (its device identifier), it will be able to process the
authentication protocol. Then the licensing agency produces a
new MKB that revokes that device. On the other hand, if the
circumvention device has been lying about what keys it has, the
authentication protocol will fail and the test MKB itself is
sufficient to take the circumvention device out of the system.
Why? The new MKBs will have a higher version number, so
compliant will replace their current MKB with a new one as the
new MKBs circulate through the system. The circumvention
device will no longer be able to authenticate with the updated
compliant devices.
4. TRACING AND FORENSICS
The NNL paper[5], in addition to introducing the subset-
difference broadcast encryption scheme, contained a theorem that
said that tracing the keys used in attack can always be done in any
broadcast encryption scheme, if the attackers have no memory of
previous test MKBs. As a practical matter, this means that the
attackers’ device must brought into a lab for testing, where it can
be reset between tests. The testing method is simply a divide-and-
conquer iteration on the subsets of devices, and it takes O(T3) test
MKBs, where T is the number of device identities the attackers
have compromised.
At the same time, the cryptographic literature abounds with
discussions of “tracing traitors”[6][7], which is the process of
deducing device keys based not on test MKBs, but on logically-
equivalent-but-detectable variations in the content itself. Most
people believed that tracing traitors is an essentially different
process than MKB forensics; for example, current Blu-ray players
have two sets of keys, one set to process the subset-difference
MKB on movie discs, and one set of “sequence keys” used for
AACS’s tracing traitors scheme.
This idea turns out to be wrong, but it is understandable why
it persisted so long. In the newest broadcast encryption schemes,
the subset keys are organized in a large tree, and the individual
devices are associated with the leaves in the tree. This allows agency is free to pick any four for a given movie. In other words,
unlimited and precise revocation. It also enables the trick used in the sequence key block stored on the movie disc denotes which
the subset-difference scheme, where a subset key is always a one- columns from the key matrix are being used, so that the players
way function of the key used in the next higher subset. However, know which of their 255 keys to use for each column in the key
in a tree scheme, two devices who are siblings on the leaves of the block. The licensing agency can take full advantage of the 255-
tree will have every subset key in common except one. This movie sequence.
seemed very bad for tracing traitors. It seemed much better to
make sure any two devices have as few keys in common as The problem is, in a multi-column key block on a disc,
possible. This suggested that tracing traitor keys should be which movie in the movie sequence does this block correspond
assigned according to a maximal distance separable (MDS) code to? I used to think this problem had a simple solution: the first
like a Reed-Solomon code. In effect, the keys are assigned out of column in the block was the one that defined which movie in the
a matrix as opposed to a tree. That is precisely what AACS did. movie sequence was used. In other words, to carry on with our
example, the 255 uncompromised keys in the first column in the
key block (let us say it column #17 in the key matrix) would
The missing piece, however, was how revocation of keys has
encrypt 255 movie variant keys. The uncompromised keys in the
to work in a matrix-based system. Because of space limitations (in
remaining columns would all encrypt the one remaining movie
both the content variations and in the MKBs themselves), the
variant key. After all, the vast majority (255/256) of players will
number of rows in the matrix is much less than the number of
only need to process the first column, so this seems to maximize
devices. Thus, in a given column, thousands or even millions of
the forensics on this large group. So the multi-column key block
innocent devices might have a compromised key. However, in a
would look like a single column key block; the movie with such a
subsequent column, because of the maximal-separate property,
block would look forensically just like movie #17 in the sequence.
most of those unlucky devices will not have the same key as the
compromised device. For example, in AACS’s MKB-like
Alas, this does not work. What if the attackers respond using
“sequence keys blocks”, many columns of keys are used to
that one remaining movie variant key? The tracing agency can
encrypt the content variation keys. If an innocent device finds its
conclude that the attackers know the compromised key in column
key is compromised in the first column in the sequence key block,
#17—but it knew that already. The attackers had to have used an
it moves on to the second column to find a content variation key.
uncompromised key from one of the other columns, but the
Likewise, if its key is compromised in the second column, it
tracing agency has no idea which. The tracing agency has gained
moves to the third. Eventually an innocent device will find a
precisely zero information from the recovered movie. The
column in which it has an uncompromised key (or else the
attackers can always do this because they know all the
inherent revocation capability of the system has been exceeded).
compromised keys.
To continue with this example, let us say we have one billion
So a licensing agency producing a multi-column key block
players, and the matrix has 256 rows. (In AACS’s terms this
must spread the variant keys across all the columns. In our
means that each movie has 256 variations.) The number of
example, the licensing agency would encrypt only 64 unique
columns in the matrix (let us say that is 255) corresponds to the
movie variant keys in the 255 uncompromised key cells in the
maximum sequence of movies that can be used for tracing. In
first column. In other words, more than one cell would encrypt the
other words, each player stores 255 keys. Now consider the case
same variant key. In effect, this reduces number of variations q;
where there has been an attack and all the keys in one player have
the effective q is q/c, where c is the number of columns. So, the
been compromised. Thus, one key in each column is
very small number of variations that the space allows is reduced
compromised. Assuming that the keys have been assigned with a
even further by revocation. And our example has been the
Reed-Solomon code, any two players have at most three keys in
minimal case; the situation gets much worse as revocation
common. The licensing agency can exclude the compromised
continues over the life of the system and the number of columns
keys with a four-column key block, as follows: the first column in
in the key blocks gets larger and larger.
this block contains 255 encrypted movie variation keys, and one
encrypted intermediate key in the compromised position.
To reduce the effects of the q/c problem, the licensing
255/256th of the players will directly calculate the movie variation
agency can do divide-and-conquer iterations. If the attackers
key; 1/256th (roughly 16 million) of the players will calculate an
respond from a given column, it will not know exactly which key
intermediate key and have to go to a second column. In that
they have, but it knows it is from a limited set. On subsequent
second column, the same fractions apply, and roughly 64,000
movies, the agency can devote more variations to distinguishing
players will have to move on to a third column. In that column, at
keys within that set. But, if the licensing agency is willing to
most 255 innocent players move on to the fourth column. All 255
iterate, what is so wrong with the tree-based scheme, where
players will have uncompromised keys in that column (because of
divide-and-conquer is essential? The answer is nothing is wrong;
the Reed-Solomon code). The one compromised key in that
in fact, it does not take many revocations before a tree-based
column will contain a random encryption, so attackers who only
scheme performs better than a matrix-based one. A tree-based
have compromised keys will not be able to calculate a movie
scheme never has a q/c problem because any two subsets in a tree
variation key.
are either disjoint or one is a proper subset of the other.
To be clear, when I say “first, second, third, and fourth”
columns, I do not necessarily mean the first four columns in the It now seems unnecessary to have two different key
key matrix. Of the 255 columns in the key matrix, the licensing management systems, one matrix one for tracing traitors and one

43
tree-based one for bulk encryption of the content. In fact, there
does not seem to be any significant difference between broadcast
encryption and tracing traitors[11]. The two can be combined in a
single MKB. AACS calls this a “unified MKB” and their Final
Specification[3], released in 2009, allows manufacturers to
produce new type of player (“Class II”) that does not have
sequence keys. Instead, the variant keys they need are in a
subset-difference MKB. This MKB looks very much like the
MKBs used for signatures (see section 2), and the two
mechanisms can be easily combined. The different subsets
calculate Ki’s, which act as variant keys to unlock the different
variations in the content. A table that looks exactly like a binding
table allows devices to use their variant key to calculate the
common media key that protects the bulk of the content.
I started this section talking about the standard in-the-lab
approach to determine an attacker’s keys using test MKBs. Using
these unified MKBs is substantially better than using standard
MKBs with their O(T3) forensic algorithm, at least in a content
protection application where it is possible to use variations in the
content. As shown in [10] and [11], using the variations, the
number of tests required is O(T) to determine all the T devices the
attackers have compromised.
It is worth noting that public-key cryptography has no
equivalent function to tracing traitors. If a content protection
application needs to identify attackers based on variations in the
unauthorized copies of content, it needs to set up a separate key
domain for that purpose, with its own revocation mechanism. The
recent advances suggest that the best type of tracing traitors key
domain is tree-based, which is also ideal for broadcast encryption,
which can take over the role that the public-key infrastructure was
performing. So, why would such a system ever choose public-key
cryptography?
5. SECURITY CLASSES
It turns out that there is at least one other recent broadcast-
encryption advance that has no exact analogue in public-key
cryptography. The idea is called security classes[12]. Basically, in
an MKB supporting security classes, some of the subsets calculate
the media key as before. Other subsets, however, whose devices
are in a higher security class, calculate a media key precursor.
They then apply a one-way function to derive the media key. All
the devices in the systems can interact based on the media key,
but some devices can have additional privilege because they also
know the media key precursor. Any number of security classes
can be defined, with higher classes calculating the keys for all the
classes below with one-way functions. This does not conflict with
the signature mechanism; the precursor keys can be introduced in
the binding table instead of the MKB itself.
Public-key cryptography has a similar feature, but it is not
quite as flexible. A public-key certificate can describe the
permissions of a device. For example, in the Digital Transmission
Content Protection (DTCP) protocol, recorders are marked as
such in their certificates. A source device will not send “do not
copy” content to a device identified as a recorder. What security
classes enable, in addition, is a device which can receive content
over an authenticated channel and pass it on to another device,
without ever having the key that would allow it to decrypt it.
Nonetheless, the device further down the chain can decrypt
44
content because it is a higher security class and can process the
same MKB and get a media key precursor. In a public-key-based
system, to pass the content on in a useful way, the original device
would also have to pass the key to decrypt the content and thus
would have to know it.
Why would a device that possesses content not be allowed to
decrypt it? Actually, this happens quite frequently. Storage
devices are the classic case. Internet lockers, Internet edge
servers, and flash memory card microcontrollers have no need to
decrypt the content that is stored on them, but usually need to be
authenticated to participate in the system. Broadcast encryption
security classes are perfect for this.
6. DISADVANTAGESS OF BROADCAST
ENCRYPTION
In 2007, Kiayias and Pehlivanoglu described an attack[8]
6
they called the Pirate Evolution Attack . Reading between the
lines, it was clear that the authors thought it meant the death knell
to broadcast encryption. In this attack, the attackers, instead of
deploying all the subset keys in all the devices they have
compromised, just deploy a single key that is in use in the current
version MKB. After the licensing agency responds revoking that
key, the attackers deploy another key. The authors claimed that,
especially in the case of AACS’s subset-difference scheme, a
single compromised device would invoke hundreds of generations
of revoke/response actions before the effects of the single attack
were completely eliminated.
The fallacy with their analysis was that they assumed that the
licensing agency must produce minimal-size MKBs. Of course, it
does not. If suffering this attack, the licensing agency simply
creates MKBs where the attacked subset has been significantly
subdivided. This greatly reduces the number of keys the attackers
can use in the next generation. For example, in the case of AACS
with an MKB of 64 KB (which is not very large considering the
Blu-ray discs can store 50 GB), at most two generations are
required to eliminate the attack from a single device. It is clear, in
the sixteen years since broadcast encryption was first described,
no fundamental flaw has yet been found.
However, there is a problem with broadcast encryption
compared with public-key cryptography. In our original magazine
article we called it the “single score problem”. Basically, if the
nature of an application is such that the attackers can gain a
significant advantage by a single transaction with the system,
broadcast encryption is inappropriate. For example, it would not
be appropriate for a banking application. The forensic
mechanisms built in to broadcast encryption schemes, although
they have been greatly improved recently, still require multiple
iterations with the attackers to reveal the keys being used. In the
“attack once and then leave the system” scenario, the attacker in a
broadcast encryption system, although he may be identified down
to a subset, is otherwise anonymous. In a public-key-based
system, the attacker would have had to have presented credentials,
and proven that he had the keys associated with those credentials.
6
Paul Kocher had earlier independently discovered this attack had
described it confidentially to the Hollywood studios. He called
the attack the Key Rationing Attack.
 Of course, even in a public-key-based system, revocation would
be ineffective (the attacker was not planning a second attack).
However, there might be an opportunity to seek legal remedies
against him because his identity is known.
In the content protection application, it is hard to imagine
that a single attack can cause significant damage. Certainly, a
single unauthorized copy has negligible impact on the system as a
whole. What hurts these systems economically are systematic
attacks like ripping programs which convert the content to
cleartext and Internet file sharing sites which distribute the
content freely. In these cases, there is ample opportunity for the
broadcast encryption forensics to work effectively.
7. CONCLUSIONS
I have often wondered what would have happened had
broadcast encryption been invented first, and public-key
cryptography came along later. Would broadcast encryption have
become the first choice of system designers, and public-key
cryptography being the more expensive alternative needed only in
certain applications? During the course of developing AACS, we
had an opportunity to use the “signature-like primitive”.
However, in the end, we decided against it, the major reason
being “it was too hard to explain to the studios”. By any objective
measure, of course, this is nonsense. I hope, in the few paragraphs
I devoted to it, I was able to convey the gist of how the signature-
like primitive works. How many paragraphs would it have taken,
starting from scratch, to have explained the elliptic curve Digital
Signature Algorithm, which AACS eventually used? In another
sense, however, the reason was apt. ECCDSA is accepted as a
given building block by system designers who only have the
fuzziest idea of the math involved. My goal with this paper was to
make a start with broadcast encryption, so that its primitives, too,
might someday achieve the same given status as public-key
cryptography.
8. REFERENCES
[1] Lotspiech, J., Nusser, S., and Pestoni, F. 2002. Broadcast
encryption’s bright future. Computer, 35(8), Aug. 2002, pp.
59-63.
45
View publication stats
[2] Fiat, A., and Naor, M. 1994. Broadcast encryption.
Advances in Cryptology (Crypto 93). Lecture Notes in
Computer Science 773, 1994. Springer-Verlag, pp 480-491.
[3] http://www.aacsla.com/specifications
[4] http://www.4centity.com
[5] Naor, D., Naor, M., and Lotspiech, J. 2001. Revocation and
tracing routines for stateless receivers. Advances in
Cryptology (Crypto 2001). Lecture Notes in Computer
Science 2139. Springer-Verlag, 2001. pp 41-62.
[6] Chor, B., Fiat, A., and Naor, M. 1994. Tracing traitors.
Crypto '94, Lecture Notes in Computer Science, Springer-
Verlag, Berlin, Heidelberg, New York, volume 839, 1994.
[7] Chor, B., Fiat, A., Naor, M., and Pinkas, B. 2000. Tracing
traitors. IEEE Transactions on Information Theory, 46, 2000.
[8] Kiayias, A. and Pehlivanoglu, S. 2007. Pirate evolution: how
to make the most of your traitor keys,” Advances in
Cryptography – CRYPTO 2007, Lecture Notes in Computer
Science, Springer Berlin, 2007. pp 448-465.
[9] Lotspiech, J. 2007. A signature-like primitive for broadcast-
encryption-based systems. Consumer Communications and
Networking Conference, 2007, Jan. 2007. pp 1042 – 1047
[10] Jin, H., Lotspiech, J., and Meggido, N. 2008. “Efficient
coalition detection in traitor tracing. In Proceeding of IFIP
International conference on Information Security 2008, Sept
8-10, 2008, Milan, Italy.
[11] Jin, H., and Lotspiech, J. 2009. Unifying broadcast
encryption and traitor tracing for content protection. IBM
Technical Report RJ10477, June, 2009. Available from
http://domino.research.ibm.com.
[12] Jin, H., and Lotspiech, J. 2009. Broadcast encryption for
differently privileged. IFIP International Conference on
Information Security (SEC'09) , May 18-20, 2009, Cyprus.
[13] Dodis, Y., and Fazio, N. 2002. Public key broadcast
encryption for stateless receivers. ACM Workshop on Digital
Rights Management, November, 2002.