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
[email protected] 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.
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 broadcastencryption 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 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 twoway 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.
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
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.
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).
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 recording was made, then that compromised player will be able to play the recording—or, more likely, decrypt it so it can be distributed in the clear. This is an unavoidable fact of life when protecting content on physical media, but there are techniques that can mitigate it in many cases. We will return to this topic in section 3.
X X
X subsets compromised devices
DEVICES
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.
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)
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
…
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.
40
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.
moves” that is sufficient. The recorder is compliant (or else it could not have calculated the key), and compliant devices play by the rules.
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 broadcastencryption system.
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).
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.
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.
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”.
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.
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.
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
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
5
41
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 “signature”
MKB “Public key”
+hash +hash +
E E E
hash
k1
k2
k3
. . .
kn
…
…
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.
Km
+
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, of course, each side has to tell the other what its device identifier is, in order for the other device to figure out what subset it needs. 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.
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.
4. TRACING AND FORENSICS The NNL paper[5], in addition to introducing the subsetdifference 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-andconquer 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.
3. AN AUTHENTICATION PROTOCOL Since the beginning of commercial broadcast encryption starting with SD cards, there has always been a broadcastencryption-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
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 logicallyequivalent-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
42
agency is free to pick any four for a given movie. In other words, the sequence key block stored on the movie disc denotes which columns from the key matrix are being used, so that the players know which of their 255 keys to use for each column in the key block. The licensing agency can take full advantage of the 255movie sequence.
devices are associated with the leaves in the tree. This allows unlimited and precise revocation. It also enables the trick used in the subset-difference scheme, where a subset key is always a oneway function of the key used in the next higher subset. However, in a tree scheme, two devices who are siblings on the leaves of the tree will have every subset key in common except one. This seemed very bad for tracing traitors. It seemed much better to make sure any two devices have as few keys in common as possible. This suggested that tracing traitor keys should be assigned according to a maximal distance separable (MDS) code like a Reed-Solomon code. In effect, the keys are assigned out of a matrix as opposed to a tree. That is precisely what AACS did.
The problem is, in a multi-column key block on a disc, which movie in the movie sequence does this block correspond to? I used to think this problem had a simple solution: the first column in the block was the one that defined which movie in the 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 encrypt 255 movie variant keys. The uncompromised keys in the remaining columns would all encrypt the one remaining movie variant key. After all, the vast majority (255/256) of players will only need to process the first column, so this seems to maximize the forensics on this large group. So the multi-column key block would look like a single column key block; the movie with such a block would look forensically just like movie #17 in the sequence.
The missing piece, however, was how revocation of keys has to work in a matrix-based system. Because of space limitations (in both the content variations and in the MKBs themselves), the number of rows in the matrix is much less than the number of devices. Thus, in a given column, thousands or even millions of innocent devices might have a compromised key. However, in a subsequent column, because of the maximal-separate property, most of those unlucky devices will not have the same key as the compromised device. For example, in AACS’s MKB-like “sequence keys blocks”, many columns of keys are used to encrypt the content variation keys. If an innocent device finds its key is compromised in the first column in the sequence key block, it moves on to the second column to find a content variation key. Likewise, if its key is compromised in the second column, it moves to the third. Eventually an innocent device will find a column in which it has an uncompromised key (or else the inherent revocation capability of the system has been exceeded).
Alas, this does not work. What if the attackers respond using that one remaining movie variant key? The tracing agency can conclude that the attackers know the compromised key in column #17—but it knew that already. The attackers had to have used an uncompromised key from one of the other columns, but the tracing agency has no idea which. The tracing agency has gained precisely zero information from the recovered movie. The attackers can always do this because they know all the compromised keys.
To continue with this example, let us say we have one billion players, and the matrix has 256 rows. (In AACS’s terms this means that each movie has 256 variations.) The number of columns in the matrix (let us say that is 255) corresponds to the maximum sequence of movies that can be used for tracing. In other words, each player stores 255 keys. Now consider the case where there has been an attack and all the keys in one player have been compromised. Thus, one key in each column is compromised. Assuming that the keys have been assigned with a Reed-Solomon code, any two players have at most three keys in common. The licensing agency can exclude the compromised keys with a four-column key block, as follows: the first column in this block contains 255 encrypted movie variation keys, and one encrypted intermediate key in the compromised position. 255/256th of the players will directly calculate the movie variation key; 1/256th (roughly 16 million) of the players will calculate an intermediate key and have to go to a second column. In that second column, the same fractions apply, and roughly 64,000 players will have to move on to a third column. In that column, at most 255 innocent players move on to the fourth column. All 255 players will have uncompromised keys in that column (because of the Reed-Solomon code). The one compromised key in that column will contain a random encryption, so attackers who only have compromised keys will not be able to calculate a movie variation key.
So a licensing agency producing a multi-column key block must spread the variant keys across all the columns. In our example, the licensing agency would encrypt only 64 unique movie variant keys in the 255 uncompromised key cells in the first column. In other words, more than one cell would encrypt the same variant key. In effect, this reduces number of variations q; the effective q is q/c, where c is the number of columns. So, the very small number of variations that the space allows is reduced even further by revocation. And our example has been the minimal case; the situation gets much worse as revocation continues over the life of the system and the number of columns in the key blocks gets larger and larger. To reduce the effects of the q/c problem, the licensing agency can do divide-and-conquer iterations. If the attackers respond from a given column, it will not know exactly which key they have, but it knows it is from a limited set. On subsequent movies, the agency can devote more variations to distinguishing keys within that set. But, if the licensing agency is willing to iterate, what is so wrong with the tree-based scheme, where divide-and-conquer is essential? The answer is nothing is wrong; in fact, it does not take many revocations before a tree-based scheme performs better than a matrix-based one. A tree-based scheme never has a q/c problem because any two subsets in a tree 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 key matrix. Of the 255 columns in the key matrix, the licensing
It now seems unnecessary to have two different key management systems, one matrix one for tracing traitors and one
43
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.
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.
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
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.
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.
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?
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.
5. SECURITY CLASSES It turns out that there is at least one other recent broadcastencryption 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.
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.
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
6
44
Paul Kocher had earlier independently discovered this attack had described it confidentially to the Hollywood studios. He called the attack the Key Rationing Attack.
[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.
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.
[3] http://www.aacsla.com/specifications [4] http://www.4centity.com
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.
[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, SpringerVerlag, 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.
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 signaturelike 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] 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 broadcastencryption-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.
8. REFERENCES
[13] Dodis, Y., and Fazio, N. 2002. Public key broadcast encryption for stateless receivers. ACM Workshop on Digital Rights Management, November, 2002.
[1] Lotspiech, J., Nusser, S., and Pestoni, F. 2002. Broadcast encryption’s bright future. Computer, 35(8), Aug. 2002, pp. 59-63.
45
