Title of Invention

A METHOD OF PREVENTING RE-USE OF COMPROMISED KEYS

Abstract

RENEWABLE TRAITOR TRACING" A system, method, and computer program product to renewably prevent traitors in a broadcast encryption system from re-using compromised keys. A lincense agency assigns individual receivers a set of Sequence Keys preferably at manufacture, and assigns Sequence Key Blocks (SKBs) to protected content files to be distributed- The files may be distributed on prerecorded media and typically include several file modifications. The particular modifications in a pirated version of a file can help identify which traitors contributed to its theft, SKBs assigned to new files distributed after traitors have been identified cannot be usefully processes using the compromised keys employed in previous content piracy. Innocent receivers that happen to have compromised key(s) in common with traitors can use a replacement uncompromised Sequence Keyfrom the set to usefuly decrypt content. Traitors will however step through all their Sequence Keys without reaching one that will work.

Full Text

a RENEWABLE TRAITOR TRACING Field of the Invention This invention relates to preventing piracy of digital content in a broadcast encryption system and more specifically to tracing traitors who may be colluding to redistribute such content and/or related decryption keys, and to renewably revoking compromised keys to prevent further use in gaining unauthorized access to content. Background of the Invention The widespread transition of data from analog format to digital format has exacerbated problems relating to unauthorized copying and redistribution of protected content. Flawless copies of content can be easily produced and distributed via the Internet or on physical media. This piracy is a major concern and expense for content providers; to this end, industry consortia such as The 4C Entity () and AACSLA () have been formed. These groups are license agencies that provide content protection tools based on Content Protection for Recordable Media (CPRM) and Advanced Access Content System (AACS), respectively- CPRM is a technology developed and licensed by the 4C group, comprising IBM, Intel, Matsushita, and Toshiba, to allow consumers to make authorized copies of commercial entertainment content where the copyright holder for such content has decided to proLecL it from unauthorized copying, AACS is a follow-on technology for the came purpose, under development by a group comprising IBM, Intel, Matsushxta, Toshiba, Sony, Microsoft, Warner Brothers, and Disney. CPRM and AACS protected files are encrypted with a key that is specific to a Media Identifier on their original storage medium (such as a DVD or CD-ROM etc.), so simply copying the content to another storage medium does not break the protection. CPRM also adds a Media Key Block (MKB) to the medium. The MKB is a rile containing a very large number of keys. Each individual compl^anL device is assigned a set of unique Device Keys that allow it to obtain the Media Key from the MKB, that is then combined with the Media Identifier and other values to derive the keys used to decrypt the protected content. Details of the CPP.M and AACS technology are provided, in PCT Patent Publication numbers WO 02/060116, WO 02/060118 and published US patent application numbers 2002-0106087, 2002-0114471, 2002-0104001 and 2004-011611 and are also available from 4C and AACS, Fundamentally, Lhe AACS protection depends on Lhe Interaction between Device Keys and the tree-based Media Key Block, which allows unlimited, precise cryptographic revocation of compromised devices without danger of collateral damage to innocent devices. Because of the inherent power of the revocation of the AACS system, it is possible that attackers may forgo building clones or non-compliant devices and instead devote themselves to attacks where they try to hide the underlying compromised device(s)* These attacks are both more expensive and more legally risky for the attackers, because the attacks require them to have an active server serving either content keys or the content itself, on an instance-by-instance basis. In addition to conventional CD-ROMs, and DVDs, a new type of home consumer device for digital content management has been enabled by the advent of inexpensive, large-capacity hard disks, A movie rental box receives digital movies from some inexpensive source of data, usually a broadcast source (whether terrestrial or satellite-based). The movies are stored on the hard disk, so LhaL aL any moment Lhe hard disk contains, for example, the hundred hottest movies in the rental market. The consumer selects and plays a particular movie, and the movie rental box periodically calls a clearing center and reports the consumer's content usage for billing purposes; the box may also acquire new decryption keys during this call. The most serious attack against these new devices is likely to be the so-called '"anonymous" attack, wherein a user or a group of users purchase rental movies from legitimate movie rental boxes that have been instrumented so that the protected content and/or the decryption keys can be captured and redistributed, often over the Internet. This attack is the most urgent concern of the movie studios that are investigating content protection technology. One solution to the problem is to differently watermark and differently encrypt each movie for each authorized movie rental box, so that if a movie is pirated, the watermarking and encryption information would uniquely identify the compromised box. Alas, this solution is not feasible because of the excessive computing effort and transmission bandwidth required to prepare and transmit individualized movies . The distribution system is economical only if the movies can be distributed over broadcast channels, i.e. where every receiver gets substantially the same data at the same time. The approach known in the art as "tracing traitors" may be used to solve the problem. In one particular instance of this approach, an original version of each movie file is augmented before being broadcast. Specifically, the file that is actually broadcast has had at least one critical file segment replaced by a set of segment variations. Each file segment variation is differently encrypted and preferably also differently watermarked prior to encryption, although the entire file may be watermarked as well. Ail the variations in one segment are identical for viewing purposes though digitally different. A particular receiver is preferably given the cryptographic key to decrypt only one of the variations in each segment. All legitimate receivers with valid decryption keys can play the content, but probably through different segment combinations, if the receiver is compromised and is used to illegally rebroadcast either Lhe keys or the segments themselves, it is possible to deduce which receiver or receivers have been compromised. The tracing traitors approach has not been widely used in practice to date because previous implementations required unreasonable amounts of bandwidth in the broadcast, due to the number of segments or variations required However, published US patent application US 2004-011611, entitled "Method for Tracing Traitors and Preventing Piracy of Digital Content in a Broadcast Encryption System' teaches a method of distributing protected content that combats piracy and enables identification and revocation of compromised receivers in a broadcast encryption system without excessive transmission bandwidth. To recap, whether dealing with DVDs or set-top boxes or other distribution means, a traitor tracing scheme has two basic steps; assigning the keys to receiver devices to enable tracing, and then identifying the traitors for revocation. Efficient trailer tracing Lechnologies direcLed to boLh these steps enable a license agency to more quickly identify traitors and to prevent piracy even by larger groups of colluding traitors. However, what happens after a traitor has been identified and a particular compromised key or set of keys is revoked? The prior art is silent as to the aftermath of a single tracing and revocation. What if a traitor repeats the attack and additional content is pirated, and/or a new key or set of keys is compromised? A system is needed that allows innocent receiver devices to still calculate a correcL cryptographic answer needed to allow content Lo be used, while at the same time preventing traitor devices from getting to such an answer. Disclosure of the Invention The invention employs Sequence Keys and a Sequence Key Block (SKB) Lo extend the previous work on broadcast encryption and traitor tracing* The Sequence Keys are assigned by a license agency to individual playback devices preferably from a key matrix. The license agency also assigns SKBs to be used on prerecorded media, in a manner similar to that of the MKBs (Media Key Blocks) u used in the CPRM system. Any compliant device can process the SKB and get the right decryption key and access the content correctly. In a preferred embodiment, successful processing of the SKB enables the device to properly use the set of variations assigned to it- When a traitor device is identified and its set of Sequence Keys is to be revoked, a new SKB is formulated and distributed on new media* If a device has no compromised Sequence Keys, it decrypts protected content on the new media in a straightforward manner by calculating the correct decryption key, preferably for its assigned variations- If a device has a compromised Sequence Key, then that key is not used, but instead another Sequence Key from a set (in a preferred embodiment, the next key in a linked list) is selected and used if it too has not been compromised* If it has also been compromised, then another available key in the set is selected, and so forth. Thus, innocent devices are given multiple opportunities to find an unrevoked Sequence Key to usefully decrypt the protected content. This approach provides renewability of the Sequence Keys - The formulation of the new SKB by the license agency assures that all of the Sequence Keys in particular devices that have been identified as traitors will be deemed compromised when those devices try to,play the content on the new media. Thus a traitor device will step through all of its Sequence Keys without finding one that will usefully decrypt the protected content- The invention may be employed with broadcast encryption systems using distribution means that may include computer networks, satellite networks, cable networks, television transmissions, and physical storage media. Files may comprise any kind of digital data sequence, including but not limited to text, audio, images, video, music, movies, multimedia presentations, operating systems, video games, software applications, and cryptographic keys. Brief Description pf tha Dravings FIG. 1 is a prior art diagram of a modified distributed file. FIG. 2 is a flowchart of the basic operation of a preferred embodiment of the present invention» FIG, 3 is a diagram oI a Sequence Key Block (SKB), according Lo a preferred embodiment of the present invention. FIG. 4 is a diagram of a Nonce Record format, according to an embodiment of the present invention. FIG. 5 is a diagram of a Calculate Variant Data Record format, according to an embodiment of the present invention. 1;'1G, 6 is a diagram of a Conditionally Calculate Variant Data Record format, according to an embodiment of the present invention, FIG. 7 is a diagram of an End of Sequence Key Block Record format, according to an embodiment of the present invention. Detailed Description of the Invention Referring now to t'lG, 1, a prior art diagram of a modified or augmented distributed file 100 is shown. This file is described in detail in published US patent application US 2004-011611, entitled "Method for Tracing Traitors and Preventing Piracy of Digital Content in a Broadcast Encryption System". The augmented file 100 is the modified version of an original file that will actually be broadcast. The augmented file 100 includes sets of file variations that replaced critical file segments. For example, a first critical file segment has been replaced with variations 102, 104, 106, and 108, while a second critical file segment has been replaced with variations 110, 112, 114, and 116, and so forth* Each file segment variation is simply a copy of the particular corresponding critical file segment that has been differently watermarked and differently encrypted. Each entire file is also typically watermarked and encrypted in a broadcast encryption system. Each file segment variation is identified by a text designation in this application (e.g. A, B, C. . , etc.) for clarity, but in practice binary numbers are generally employed for this purpose. The number of critical file segments and the number of file segment variations preferably employed depends on the properties of the file and its audience. For movies, one could select a single critical file segment and have several hundred file segment variations; however, attackers might sinply choose to omit that single critical file segment in a pirated copy of the file, in hopes that viewers would not find such a glitch to be overly annoying. A pirated movie with say 15 missing critical 5-second scenes is probably going to be too annoying to any viewer for it to be of any commercial value. Thus, the illegally broadcast movies are either substantially disrupted or the attackers must incorporate some of their file segment variations, which will facilitate traitor tracing. Sets of Sequence Keys are assigned to individual devices by the license agency out of a matrix of keys. The licensing agency will generate Sequence Keys organized in a large matrix. The matrix preferably has 256 columns and not more than 65,536 rows* Each cell in the matrix is a different Sequence Key. A single receiver device has one key in each column. Thus, each device has 256 Sequence Keys in this example. In this respect. Sequence Keys are somewhat analogous to the CPRM technology Media Keys. The licensing agency assigns the Sequence Key Blocks to be used with protected files. Sequence Key Blocks are similar to the CPRM Media Key Blocks, but important differences exist, arising both from the use different ciphers (preferably AES instead of C2) and from unique considerations of specific attacks that could be employed against Sequence Key lists. However, unlike MKBs, the SKBs are preferably not part of the fundamental cryptographic protection of the content. The fundamental protection of AACS is the Media Key. In a preferred embodiment of the present invention, the 3KB merely allows different variants of the Media Key to be calculated by different devices. Referring now to FIG, 3, a diagram of a Sequence Key Block (SKB) according to a preferred embodiment of the present invention is shown. The SKB begins with a first column 300, called the "unconditional" column. This column will have an encryption of the output key 302 (denoted "K" in the figure) in every uncompromised Sequence Key (to be precise, it is encrypted in a key derived from Lhe Sequence Key, noL the Sequence Key itself) . Devices LhaL do noL have compromised keys in that column immediately decrypt the output key, and they are done. Devices, both innocent and otherwise, that do have compromised keys instead preferably decrypt a key called a Link Key 304 that allows them to process a further column in the SKB. To process the further column, such devices need both the Link Key and their Sequence Key in that column* Thus the subsequent columns are called "conditional" columns because they can only be processed by the device if it had been given the necessary Link Key in a previous column. The conditional columns are produced Lhe general same way as the lirsL column, i.e. they will have an encryption of the output key in every uncompromised Sequence Key. Devices with a compromised key will get a further Link Key 304 instead of the output key. However, after some number of columns (depending on the actual number of compromised keys), the license agency will know that only compromised devices are getting the Link Key, because all innocent devices would have found the output key in this column or a previous column. At this point, rather than encrypting a Link Key, the agency simply encrypts a 0 (item 306), and the SKB is complete. How do the devices know they have a Link Key 304 versus the output key 302? The short answer is they do not, at least not at first. Each conditional column preferably has a header 308 of known data (e.g, the hexademical value DEADBEEF is often used) encrypted in the Link Key 304 for that column* The device decrypts the header 308 with the key it currently has. If the header 308 decrypts correctly, the device knows it has a Link Key 304 and processes the column, if it does not decrypt correctly, the device knows it has either the output key 302 or a Link Key 304 for a further column. When it reaches the end of the SKB, it knows it must have an output key 302. Note that this device logic allows the license agency to send different populations of devices to different columns by having more than one Link Key 304 output from a single column. For example, in the figure, column (1) links to both column (2) and column (5). This flexibility can help against certain types of attacks, A unique consideration for Sequence Key lists arises from the following attack scenario. Suppose a coalition of hackers is formed that includes one identified and revoked traitor^ and at least one other receiver that has not been revoked. The known traitor's first Sequence Key is used on a current SKB, and a Link Key 304 results because that Sequence Key is compromised. The invention then moves to the next column in the SKB and tries to determine if it' s dealing with an innocent receiver that merely happens to have a compromised key in common with a traitor. However, instead of using the known traitor's next Sequence Key (which would lead to yet another Link Key 304 and eventually to a 0), the coalition now employs the other, unrevoked, receiver's Sequence Key along with the Link Key 304 from the previous column. In this attack and related variants, the possibility exists that the coalition would fool the system and gain access to the protected content in a way that would confound subsequent tracing of all the traitors. To guard against this scenario, the key matrix from which SKBs are generated is preferably subdivided into sub-populations small enough to allow deterministic identification of all traitors in a coalition comprising an identified revoked traitor and new "turncoats" that have not yet been identified and revoked by a given SKB. All tralLor tracing schemes used in this scenario are within the scope of this invention* Similarly, SKB subdivision and population management is also employed against scenarios in which candidate Sequence Keys are not selected by proceeding through a set of Sequence Keys in any particular order. Although the invention has been described above as producing a single correct cryptographic answer enabling access to protected content, in the broader case, there is not just a single output key, but multiple output keys termed Variant Data, Calculation of the Media Key Variant Data using Sequence Keys is now described. Each AACS-compliant device capable of playing pre-recorded content is given a set of secret Sequence Keys when manufactured. These are in addition to the Device Keys that all AACS devices require. These Sequence Keys are provided by the license agency and are for use in processing the Sequence Key Block* The result of the calculation is Variant Data which is then combined with the Media Key from the Media Key Block to generate the Media Key Variant-Key sets may either be unique per device, or used commonly by multiple devices. In a preferred embodiment, each device receives 256 64-bit Sequence Keys, which are referred to as Ks_i (i=0,1, . . ., 255) . For each Sequence Key there is an associated Column and Row value, referred to as CS_i and Rs_i (i = 0, 1, . . ., n-1) respectively. Column and Row values start at 0* For a given device^ no two Sequence Keys will have the same associated Column value (in other words, a device will have at most one Sequence Key per Column) . It is possible for a device to have some Sequence Keys with the same associated Row values. A device uses a Sequence Key Ks_i together with the Media Key K^ to calculate the Media Sequence Key Kms_i as follows; K,s = AES G(K„, Ks_i II 0000000000000016) AES is the American Encryption Standard, a block cipher adopted as an encryption standard by the U.S. government. AES is described in detail in National Institute of Standards and Technology (NIST), Advanced Encryption Standard {AES), FIPS Publication 197, November 26, 2001, and National Institute of Standards and Technology (NIST), Recommendation for Block Cipher Modes of Operation - Methods and Techniques, NIST Special Publication 800-38A, 2001 Edition* See also the AES common book. Advanced Access Content System; Introduction and Common Cryptographic Elements. AES_G is a one-way function defined using the AES cipher. The AES-based one-way function result is calculated as: AES_G(x:, X2) = AES_128D(x1, X2) XOR X2. where XOR is the bitwise exclusive-OR function. AE3_G is specified in the AES common book, in section 2.1.3. AES_ECBD is the AES decrypt function in electronic codebook mode (AES Electronic CodeBook Decrypt) * In this mode, the cipher treats each 128-bit cipher text block as a word to be deciphered independently of any that came before or any that come after, as if it were looking it up in a codebook* When the cipher is used in this way, a change to one block of the cipher text only affects decryption of that block. Contrast this with AES in cipher block chaining mode, in which each cipher text block is combined with a value computed while deciphering the previous block in order to decipher it. When the cipher is operated in cipher block chaining mode, a change to any block of the cipher text affects decryption of all subsequent blocks in the chain. AES_ECBD (referred to as AES_128D(k, d) ) is specified in the AES common book, in section 2.1.1. The Sequence Keys thus serve a similar role that the Device Keys serve in CPRM, i.e. the device does not use its Sequence Key directly to decrypt, but instead it combines it with the Media Key first as shown above* That means that a given SKB is associated with a given MKB (because the 3KB depends on the Media Key for correct processing) . A device preferably treats its Sequence Keys as highly confidential, and their associated Row values as confidential, as defined in the AACS license agreement. The SKB is generated by the license agency and allows all compliant devices, each using their set of secret Sequence Keys and the Media Key, to calculate the Variant Data, Dv, which in turn allows them to calculate the Media Key Variant. If a set of Sequence Keys is compromised in a way that threatens the integrity of the system, an updated SKB can be released that causes a device with the compromised set of Sequence Keys to calculate invalid Variant Data. In this way, the compromised Sequence Keys are "revoked" by the new SKB. An SKB is formatted as a sequence of contiguous Records. Each Record begins with a one-byte Record Type field, followed by a three-byte Record Length field. The Record Type field value indicates the type of the Record, and the Record Length field value indicates the number of bytes in the Record, including the Record Type and the Record Length fields themselves. Record lengths are always multiples of 4 bytes. The Record Type and Record Length fields are never encrypted. Subsequent fields in a Record may be encrypted, depending on the Record Type. Using its Sequence Keys, a device calculates Dv by processing Records of the SKB one-by-one, in order, from first to last. Except where explicitly noted otherwise, a device must process every Record of the SKB. The device must not make any assumptions about the length of Records, and must instead use the Record Length field value to go from one Record to the next. If a device encounters a Record with a Record Type field value it does not recognize, it ignores that Record and skips to the next, h'or some Records, processing will result in the calculation of a Dv value. Processing of subsequent Records n.= y update the D. value that was calculated previously. After processing of the 3KB is completed, the device uses the most recently calculated Dv value as the final value for Dv, If a device correctly processes an SKB using Sequence Keys that are revoked by that SKB, the resulting final Dv will have the special value 000000000000016. This special value will never be an SKB's correct final Dv value, and can therefore always be taken as an indication that the device's Sequence Keys are revoked. Device behavior in this situation is defined by the particular implementation. As an example, a device could exhibit a special diagnostic code, as helpful information to a service technician. The remaining portion of this application describes in detail a particular implementation of the present invention, including various formats likely to be followed by the AACS license agency. However, the present invention is not limited to this particular implementation. Referring now to Figure 4, a Nonce Record format is shown according to an embodiment of the present invention. The nonce number X is used in the Variant Data calculation as described below. The nonce record will always precede the Calculate Variant Data Record and the Conditionally Calculate Variant Data Records in the SKB, although it may not immediately precede them. Referring now to Figure 5, a Calculate Variant Data Record format is shown according to an embodiment of the present invention, A properly formatted SKB will have exactly one Calculate Variant Data Record. Devices must ignore any Calculate Variant Data Records encountered after the first one in an SKB. The use of the reserved fields is currently undefined, and they are ignored. The Generation field will contain 0001-f. for the first generation. The Column field indicates the associated Column value for the Sequence Key to be used with this Record, as described below. Bytes 20 and higher contain Encrypted Key Data (possibly followed by some padding bytes at the end of the Record, not shown in Figure 5) . The first ten bytes of the Encrypted Key Data correspond to Sequence Key Row 0, the next ten bytes correspond to Sequence Key Row 1, and so forth. Before processing the Record, the device checks that both of the following conditions are true; Generation == 000000016 and the device has a Sequence Key with associated Column value Cd_i == Column,or some i. It is not necessary for a first generation device to verify that Record Length is sufficient to index into the Encrypted Key Data, first generation devices are assured that the Encrypted Key Data contains a value corresponding to their Device Key's associated Row value. Referring now to Figure 6, a Conditionally Calculate Variant Data Record format is shown, according to an embodiment of the present invention. A properly formatted SKB may have zero or more Conditionally Calculate Media Key Records. Bytes 4 through 19 of the Record contain Encrypted Conditional Data (Dcd) • If decrypted successfully, as described below, bytes 4 through 7 contain the value DEADBEEF16, bytes 8-9 contains the associated Column value for the Device Key to be used with this Record, and bytes 10-11 contain a Generation value of 000116 for the first generation. Bytes 20 and higher contain Doubly Encrypted Variant Data (possibly followed by some padding bytes at the end of the Record, not shown in Figure 6) . The first ten bytes of the Doubly Encrypted Key Data correspond to Sequence Key Row 0, the next ten bytes correspond to Sequence Key Row 1, and so forth* Upon encountering a Conditional Calculate Variant Data Record, the device first calculates its current Media Key Variant, as follows: K^^v = AES_G(Km, Dv II OOOOOOOOOOOOOie) Where D,, is its current Variant Data calculated from a previous Calculate Variant Data Record or Conditional Calculate Variant Data Record. Using its current Kmv value, the device calculates Conditional Data (Dc) as: Dc = AES_ECBD(Kmvf Dee)- bits to each as needed. The resulting by becomes the current Variant Data value. This record is always a multiple of 4 bytes; if necessary, pad bytes are added on the end. Referring now to Figure 7, an End of Sequence Key Block Record format is shown, according to an embodiment of the present invention. A properly formatted SKB contains an End of Sequence Key Block Record. When a device encounters this Record it stops processing the SKB, using whatever Dv value it has calculated up to that point as the final Dv for that SKB, The End of Sequence Key Block Record contains the license agency's signature on the data in the Sequence Key Block up to, but not including, this record. Devices may ignore the signature daLa. However, if any device checks the signatures and determines that the signature does not verify or is omitted, it must refuse to use the Variant Data. The length of this record is always a multiple of 4 bytes. Regarding the calculation of the Media Key Variant from the Variant Data, when the device has finished processing the SKB, and if it has not been revoked, it will have an 80-bit valid Variant Data Dv, The device calculates the Media Key Variant from the Variant Data as follows: K^v = AES_G(Kn„ Dv I 000000000000000016) In addition, the low-order 10 bits of the Variant Data identify the Variant Number for the device to use in playing the content, from 0 to 1023. This number usually denotes the particular Title Key file the device should use to decrypt the content, although the meaning and use of the Variant Number is format-specific. A general purpose computer is programmed according to the inventive steps herein. The invention can also be embodied as an article of manufacture -a machine component - that is used by a digital processing apparatus to execute the present logic. This invention is realized in a critical machine component that causes a digital processing apparatus to perform the inventive method steps herein. The invention may be embodied by a computer program that is executed by a processor within a computer as a series of computer-executable instructions. These instructions may reside, for example, in RAM of a computer or on a hard drive or optical drive of the computer, or the instructions may be stored on a UASD array, magnetic tape, electronic read-only memory, or other appropriate data storage device. CLAIMS 1. A method of preventing re-use of compromised keys in a broadcast encryption system, comprising: (a) incorporating a particular set of Sequence Keys assigned by a license agency into individual receivers; (b) assigning a Sequence Key Block (SKB) by the license agency to at least one distributed protected file; (c) incremental cryptographic testing by the individual receivers to determine (200) if a selected Sequence Key is compromised; (dl) if the selected Sequence Key is not compromised then responsively properly decrypting (202) the file and ending the method; (d2) if the selected Sequence Key is compromised then responsively determining (204) if a subsequent Sequence Key from the set is available; (el) if a subsequent Sequence Key is available then selecting (206) that subsequent Sequence Key and retuming to step (c); and (e2) if a subsequent Sequence Key is not available then the method ends (208) without properly decrypting the file. 2. The method of claim 1 wherein the Sequence Keys select a particular set of variations in the file. 3. The method of claim 1 wherein the SKB is formulated to cryptographically revoke particular receivers. 4. The method of claim 1 wherein the set includes a linked list. 5. The method of claim 1 wherein the testing further comprises crytographically applying the selected Sequence Key and a Link Key if then available to the SKB to obtain a predetermined value indicating whether the selected Sequence Key is compromised. 6. The method of claim 5 wherein if the selected Sequence Key is compromised, a Link key leading to said subsequent Sequence Key is generated. 7. A system for preventing re-use of compromised keys configured to the perform the steps as claimed in any of the preceding method claims 1 - 6. 8. Ana Apparatus for for preventing re-use of compromised keys in a broadcast encryption system configured to perform the steps as claimed in any of the preceding claims 1 -6.

Documents:

1894-CHENP-2008 AMENDED PAGES OF SPECIFICATION 27-11-2012.pdf

1894-CHENP-2008 AMENDED CLAIMS 27-11-2012.pdf

1894-CHENP-2008 CORRESPONDENCE OTHERS 17-12-2012.pdf

1894-CHENP-2008 EXAMINATION REPORT REPLY RECEIVED 27-11-2012.pdf

1894-CHENP-2008 FORM-1 27-11-2012.pdf

1894-CHENP-2008 FORM-13 27-11-2012.pdf

1894-CHENP-2008 FORM-3 27-11-2012.pdf

1894-CHENP-2008 OTHER PATENT DOCUMENT 27-11-2012.pdf

1894-CHENP-2008 AMENDED PAGES OF SPECIFICATION 17-12-2012.pdf

1894-CHENP-2008 ASSIGNMENT 17-12-2012.pdf

1894-CHENP-2008 CORRESPONDENCE OTHERS 31-10-2012.pdf

1894-chenp-2008-abstract.pdf

1894-chenp-2008-claims.pdf

1894-chenp-2008-correspondnece-others.pdf

1894-chenp-2008-description(complete).pdf

1894-chenp-2008-drawings.pdf

1894-chenp-2008-form 1.pdf

1894-chenp-2008-form 18.pdf

1894-chenp-2008-form 26.pdf

1894-chenp-2008-form 3.pdf

1894-chenp-2008-form 5.pdf

1894-chenp-2008-pct.pdf