EP2119091A2

EP2119091A2 - Content encryption schema for integrating digital rights management with encrypted multicast

Info

Publication number: EP2119091A2
Application number: EP08825886A
Authority: EP
Inventors: Bin Zhu; Min Feng
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2007-01-09
Filing date: 2008-01-09
Publication date: 2009-11-18
Also published as: WO2008150553A3; US7978848B2; EP2119091A4; US20080165956A1; WO2008150553A2

Abstract

Systems and methods provide a content encryption schema for integrating digital rights management (DRM) in a multicast/broadcast encryption system. In one implementation, an exemplary integrated key schema provides content encryption keys that can be employed by a multicast or broadcast process, while providing DRM protection of recorded multicast content via a single DRM decryption secret. The integrated key schema provides high security and allows encrypted multicast content to be saved directly to local files. A license server can efficiently manage and generate DRM keys to be delivered to clients because only a single key needs to be delivered per license to a client. The integrated key schema can be applied together with conventional broadcast or multicast encryption techniques.

Description

CONTENT ENCRYPTION SCHEMA FOR INTEGRATING DIGITAL RIGHTS MANAGEMENT WITH ENCRYPTED MULTICAST

BACKGROUND

[0001] In many applications it is desirable to save the content received from restricted broadcast or encrypted multicast to local files for subsequent replays. The locally saved files should ideally be protected by a Digital Rights Management (DRM) system to prevent unauthorized usage. It is a great challenge to combine conventional DRM with conventional restricted multicast/broadcast since they use different mechanisms to accomplish different goals, and the conventional mechanisms tend to be mutually exclusive. The access control characteristic of restricted multicast/broadcast is designed to ensure that users not belonging to a premium group are unable to access the privileged content. Thus, a new content encryption key is generated each time there is a change in the group membership. These key changes can even occur in the middle of playing the live content. Access control in restricted multicast/broadcast can be achieved by a key distribution mechanism such that only the parties currently belonging to the premium group can receive the content decryption keys, which are then used to decrypt the encrypted multicast/broadcast content.. Thus, key distribution mechanisms that support access control in restricted multicast/broadcast are needed. [0002] In a conventional DRM system, on the other hand, a content object is usually encrypted with a single encryption key to avoid the complexity of key generation and management.

[0003] There are at least two conventional straightforward ways to use multicast and DRM together, but both have serious drawbacks. The first straightforward solution, referred to as the direct recording method, saves encryption blocks received via multicast/broadcast directly to local storage. A user needs to acquire a license from a license server to play the saved content. A license according to this conventional technique has to contain all the content encryption keys associated with all the possible combinations of the saved encryption blocks. This means that a license may contain multiple, even a substantial number of content encryption keys. The license server has to store and track all the content encryption keys used in multicast/ broadcast in order to deliver necessary keys required for DRM protection across all the users.

[0004] The second straightforward solution, referred to as the transcryption technique, works in a similar manner as a transcoder to compression: a recipient transcrypts the encrypted multicast/broadcast content into DRM encrypted content. In this conventional technique, the recipient first decrypts the encrypted multicast content, using multiple content decryption keys, and then re-encrypts the content using DRM encryption, in which a single content encryption key is used for each saved file. In addition to the disadvantage of computational overhead during the transcryption, the security of the system is also compromised. The recipient is required to perform the content packaging that a content publisher normally does in a conventional DRM system. Since users are not trusted in the threat model of DRM applications, more client modules have to be protected against hacking and reverse engineering. In this conventional technique, a conventional DRM content encryption key also needs to be acquired from the license server by the recipient before re-encryption.

[0005] Thus, conventional techniques to provide DRM for restricted multicast/broadcast result in some serious drawbacks. DRM as applied to the conventional "direct recording" technique of storing encrypted multicast content introduces the drawback of requiring complex key management and the drawback of sending a cumbersome number of keys per license to a client. DRM as applied to the conventional "transcryption" technique of storing encrypted multicast content into a DRM format necessitates the drawbacks of requiring prior possession of the DRM key, intensive computational overhead, and introducing the user's machine as an essential middleman in what is supposed to be a secure DRM process for managing the digital rights of the same user. SUMMARY

[0006] Systems and methods provide a content encryption schema for integrating digital rights management (DRM) in a multicast/broadcast encryption system. In one implementation, an exemplary integrated key schema provides content encryption keys that can be employed by a multicast process, while providing DRM protection of recorded multicast content via a single DRM decryption secret. The integrated key schema provides high security and allows encrypted multicast content to be saved directly to local files. A license server can efficiently manage and generate DRM keys to be delivered to clients because only a single key needs to be delivered per license to a client. The integrated key schema can be applied together with conventional broadcast or multicast encryption techniques. [0007] This summary is provided to introduce an exemplary content encryption schema for integrating DRM with multicast/broadcast, which is further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Fig. 1 is a diagram of an exemplary system integrating DRM with encrypted multicast. [0009] Fig. 2 is a block diagram of an exemplary multicast/DRM engine.

[00010] Fig. 3 is a diagram of exemplary multicast content production.

[00011] Fig. 4 is a diagram of an exemplary client-side content player.

[00012] Fig. 5 is a flow diagram of an exemplary method of integrating

DRM with encrypted multicast.

DETAILED DESCRIPTION

Overview

[00013] Described herein is a content encryption schema for integrating digital rights management (DRM) with a multicast/broadcast encryption system. The exemplary encryption schema provides content encryption keys to be used by a multicast/broadcast system and facilitates subsequent DRM protection of multicast content that has been saved. In one implementation, the exemplary encryption schema generates a secret and then a prime number for each block of data content. The schema derives a content encryption key for each block from the secret and each corresponding prime number. Then the exemplary schema subsequently derives a single decryption secret to grant access to a user's particular saved recording of the multicasted/broadcasted content. The single decryption secret is derived from the corresponding prime numbers of the collection of stored blocks that constitute the user's recording. Thus, the prime numbers generated for each individual block enable production of content encryption keys usable by a multicast/broadcast system and also enable a single decryption key to be created for subsequent DRM of saved content.

[00014] The content encryption keys can be used by a multicast/broadcast system when rekeying occurs, but should not be confused with the multicast system's own key distribution techniques for controlling access. The exemplary integrated key schema described herein can be applied together with conventional restricted broadcast or multicast encryption techniques. [00015] The exemplary integrated encryption key schema described herein facilitates the two conventionally diverse multicast/broadcast and DRM schemata that have different purposes and goals. Thus, the exemplary integrated key schema works well for supplying content encryption keys to a multicast/broadcast process while simultaneously facilitating subsequent DRM protection of the saved content via a single DRM key that can be sent in a license.

[00016] The exemplary key schema is secure to collusion attacks in which clients with knowledge of different content encryption keys work together attempting to derive new keys. The exemplary key schema has the additional advantage that multiple recorded files can be merged together directly into a single file by the client, and only a single secret needs to be delivered in a license to decrypt the merged file, regardless of whether the merged file contains consecutive encryption blocks or not. [00017] The term "encryption block" or simply "block" means a segment of data encrypted under the same content encryption key in broadcast or multicast. Auxiliary data assisting decryption of the encrypted data such as the encryption block ID may also be included in the encryption block. In restricted multicast or broadcast, distributed content consists of a sequence of encryption blocks.

[00018] The following description uses the term "key" to mean a piece of information used to encrypt or decrypt data, and uses the term "secret" to mean a piece of nonpublic information used to generate or derive a "key." Nonetheless, it should be noted that "key" and "secret" are often considered interchangeable terms in cryptography.

[00019] In the following description, the terms "restricted multicast/broadcast" and "encrypted multicast/broadcast" denote examples of information transfer in which the transferred information is encrypted to allow only selected recipients, who possess a secret or an access right, to decrypt the information. Restricted broadcast/multicast will be referred to herein by the representative term "restricted multicast" or just "multicast."

Exemplary System

[00020] Fig. 1 shows an exemplary system 100 that integrates DRM with encrypted multicast. A content delivery server 102 hosts one or more components of an exemplary multicast/DRM engine 104. The multicast/DRM engine 104 sends content, such as multimedia content, to a select recipient 106 over a network, for example, the Internet 108. The content is divided into blocks (e.g., corresponding to multicast rekeying intervals) and encrypted by numerous content encryption keys, one for each block, in order to limit access to the content to current subscribers and other intended recipients. A license and payment server 110 may also host one or more components of the exemplary multicast/DRM engine 104'. The recipient 106 has a client-side content player 112 that can play live multicast or can use a DRM secret granted by the license and payment server 110 to play saved content. [00021] For each block of content, the exemplary multicast/DRM engine

104 of the content delivery server 102 generates a content encryption key for that block from a prime number generated to be unique to that block. This content encryption key is adapted by the multicast process being used. For facilitating subsequent DRM, the content delivery server 102 also transmits the corresponding prime numbers of the transmitted blocks to the client-side content player 112 to be stored when the content itself is stored. The corresponding prime numbers may be transmitted and stored separately from the content to be stored. Alternatively, the corresponding prime numbers may be embedded, e.g., in an auxiliary field of each content block, and sent as a part of the content blocks (shown in Fig. 3). The corresponding prime numbers are used in regenerating the decryption keys for saved blocks at the client side when used with a secret in a license delivered from the license server. [00022] To implement DRM, rather than send a decryption key or secret for each block stored locally at the client 106, the multicast/DRM engine 104' of the license and payment server 110 generates a single DRM secret that allows the recipient 106 to replay an arbitrary collection of the stored content blocks, upon request. The single DRM secret enables the client-side content player 112 to generate decryption keys for and only for the specified arbitrary collection of stored content blocks. The license and payment server 110 simply includes the single DRM secret customized to meet the recipient's request in a license to the recipient 106.

Exemplary Engine

[00023] Fig. 2 shows the exemplary multicast/DRM engine 104 of Fig. 1, in greater detail. The illustrated implementation in Fig. 2 is only one example configuration, for descriptive purposes. Many other arrangements of the illustrated components or even different components constituting an exemplary multicast/DRM engine 104 are possible within the scope of the subject matter. Such an exemplary multicast/DRM engine 104 can be executed in hardware, software, or combinations of hardware, software, firmware, etc. [00024] A comprehensive form of the exemplary multicast/DRM engine

104 (or 104') includes a pseudo-random prime number generator 202, a content encryption key generator 204, and a DRM secrets generator 206. Typically, the multicast/DRM engine 104 in the content delivery server 102 includes the pseudo-random prime number generator 202 and the content encryption key generator 204, while the multicast/DRM engine 104' in the license and payment server 110 includes the DRM secrets generator 206. Thus, in some implementations, the versions of the multicast/DRM engine 104 and 104' are different in general but share some information such as s, n, p, and q, (to be described below) and the prime numbers associated with the saved blocks that a client requests to replay.

[00025] The pseudo-random prime number generator 202 includes a prime number generator 208 to produce large prime numbers 210, such as "p" and "q." The prime number generator 208 is included in a prime number multiplier 212, which in one implementation multiplies the large prime numbers 210 together to obtain product n 214. The prime number multiplier 212 is included in a secret generator 216 that produces a secret, such as φ(n) 218, which in one implementation is related to the large prime numbers 210 according to φ(n) = (p - \)(q - 1) . The secret generator 216, in turn, is included in a prime number collection generator 220, which generates a large collection of distinct prime numbers P 222. The pseudo-random prime number generator 202 further includes a number selection engine 224 that implements a selection schema 226 to produce the pseudo-random sequence 228 of distinct prime numbers pj, p₂, ..., P₁ which are all co-prime to φ{n) 218. In one implementation the pseudo-random sequence 228 of distinct prime numbers is generated by selecting pseudo-randomly those numbers from the collection P that are co-prime to φ{ή) 218.

[00026] The content encryption key generator 204 introduced above further includes an inputs manager 230, e.g., for inputting a current prime number p_t 232 of the z-th prime number of the pseudo-random sequence 228 of prime numbers, to be used to generate an encryption key for a corresponding i- th content block. The content encryption key generator 204 further includes a random integer generator 234 for producing a random integer s 236 based on product n 214, which in one implementation is related to the product n 214 according to s e (\,ή) and the integer s 236 is co-prime to the product n 214. The content encryption key generator 204 produces per-block content encryption keys for multicast content delivery 238 and readies the current prime number 232 for transmittal or for embedding in a corresponding content block, both for subsequent DRM.

[00027] The DRM secrets generator 206 may include a block identity manager 240 to receive a list of identities of blocks in a recording — a collection of blocks — to be replayed from the client's local storage. The block identity manager 240 also coordinates obtaining from the system 100 the corresponding prime number for each block in the collection. The DRM secrets generator 206 may include a scalar multiplication engine 242 to produce a product K₁ 244 consisting of the corresponding prime numbers {p,} 232 of the blocks constituting the locally stored collection to be replayed at the client-side content player 112. The DRM secrets generator 206 generates a single DRM secret sj 246 that can be used to derive the decryption keys for each block of the stored content to be replayed. It is worth noting that the blocks in the client's stored collection to be replayed (e.g., a saved computer file of multimedia content) do not have to be contiguous (e.g., blocks corresponding to an advertisement can be omitted) and do not have to be in temporal order (the user may wish to play the content in reverse, or jump around in the content). The single DRM secret 246 is sent to DRM licensing and payment 248, e.g., to a licensing and payment server 110.

[00028] In another implementation, the DRM secrets generator 206 resides in the multicast/DRM engine 104' inside the license and payment server 110. In this implementation, the multicast/DRM engine 104 inside the content delivery server 102 and the multicast/DRM engine 104' inside the license and payment server 110 share the pair of numbers {n,φ{n)} (214, 218, respectively) as well as the collection P 222, the integer s 236, and the selection schema 226. The shared information is used to derive the single DRM secret sj 246 delivered in a DRM license to a client during license acquisition.

Operation of the Exemplary Engine

[00029] In one implementation, the exemplary integrated key schema is based on the strong RSA assumption to generate content encryption keys for multicast. As introduced above, the exemplary key schema dramatically simplifies key management and delivery in DRM subsequently applied to multicast content that has been recorded. In one implementation, encrypted media from multicast is directly saved to a client's local storage. Only a single key, the DRM decryption secret 246, needs to be contained in a license for replaying a recorded content object.

[00030] The exemplary key schema generates content encryption keys for multicast encryption by taking into account the specific requirements of the DRM applied subsequently to recorded contents. As mentioned, the exemplary key schema is based on the strong RSA assumption and in one implementation includes the four processing phases of setting up, multicasting, recording content, and playing back the recorded content.

Setup

[00031] In one implementation, the prime number generator 208 first generates two large prime numbers p and q 210. The prime number multiplier 212 obtains n 214 by processing n = p - q and the secret generator 216 obtains a secret φ(n) 218 by processing φ(n) = (p - \){q - 1) . The prime number collection generator 220 then selects a collection P 222 of distinct prime numbers. A selection schema 226 is used by the number selection engine 224 to pseudo-randomly select numbers co-prime to φ(n) 218 sequentially from P 222 to obtain the pseudo-random sequence 228 of prime numbers. [00032] In one implementation, the selection of the prime numbers from

P 222 is exclusive, i.e., a selected number will not be selected again in future selections. An example selection schema 226 directs the number selection engine 224 to pseudo-randomly permute the numbers in P 222, and then select the numbers that are co-prime to φ{n) 218 according to the resulting order. The equation p_t = P[i] denotes the i -th number of the numbers selected by the selection schema 226 from the collection P 222, which are relatively prime to φ{ή) 218. Thus, the pseudo-random sequence p_l,p₂,p₃,- - - 228 is the sequence of numbers selected from P 222 by the number selection engine 224 that are all relatively prime to φ{n) 218, and no two numbers are equal. The number n 214 and the collection P 222 are publicly known, while the secret number φ{ή) 218 and the selection schema 226 to select numbers from P 222 remain secret information.

[00033] The reason that the selection schema 226 is kept secret is to prevent a hacker from knowing the numbers that may be selected from P 222 by the number selection engine 224 that are not relatively prime to φ{n) 218, since such information can be used to deduce the secret φ(n) 218. The pair of numbers {n,φ{n)} (214, 218, respectively) as well as the collection P 222, the integer s 236, and the selection schema 226 are shared with the license server 110, which uses the information to derive content encryption keys during license acquisition. In one implementation, the content delivery server 102 for multicast also serves as the license server 110 for the DRM system. Multicasting

[00034] Referring to Fig. 3 as well as to Fig. 2, for multicasting, let B₁ denote the i -th encryption block and Jc₁ 304 denote the corresponding encryption key in multicast. To generate the first content encryption key Jc₁ 306, i.e., the encryption key for the first encryption block B₁ 308, the content encryption key generator 204 selects a random integer s 236 (s e (l,ή) ), where s 236 is relatively prime to n 214, and the inputs manager 230 obtains the first prime number p_γ = P[l] 310 co-prime to φ{ή) 218 from the collection P 222.

The content encryption key generator 204 sets the first encryption key Jc₁ 306 to be s^Pl mod n . The number s 236 is also shared with the license server 110 in order to generate keys to deliver in licenses to clients 106 to replay saved contents. The integer s 236 is not kept as a secret, but is publicly available. [00035] When the first rekeying is needed in multicast, the content encryption key generator 204 generates a new content encryption key k₂ 312 to encrypt the second encryption block B₂ 314. To do so, the inputs manager 230 obtains the second prime number p₂ 316 co-prime to φ(n) 218 from P 222, i.e., p₂ = P[2] . The content encryption key Jc₂ 312 for the second encryption

block B₂ 314 is determined by k₂ = s^Pl moan . The content encryption key generator 204 iterates this procedure whenever rekeying is needed, e.g., due to a change in membership of the multicast. [00036] In general, for the i -th rekeying, the content encryption key generator 204 generates the (z + 1) -th content encryption key Jc₁₊₁ to encrypt the

(i + 1) -th encryption block B₁₊₁. This is accomplished by the inputs manager 230 first obtaining the (i + \) -th prime number p_i+l co-prime to φ(n) 218 from the collection P 222: p_i+l = P[i + ϊ\ . The (i + ϊ) -th content encryption key Jc₁₊₁ is

determined by Jc₁₊₁ = s^Pl+l mod/? , where z ≥ 0 .

[00037] As noted above, the prime number, e.g., p_t 318, may be packaged into an auxiliary field 320 in the encryption block B₁ 302 to be sent to clients. Alternatively, the prime number p_t 318 can be multicast in-band to clients separately from the content delivery server 102. In describing the exemplary key schema, it is assumed that there is no loss in transmitting the selected prime numbers 318 to a client 106. If that is not the case in a particular application, then error correction or redundant transmission of the selected prime numbers 318 may be used to ensure that clients 106 receive all the transmitted prime numbers 318. It is worth reemphasizing that the transmitted prime numbers 318 are not used in live multicast decryption. Rather, the prime numbers 318 are used in generating keys by the client-side DRM module when decrypting saved content. Recording Content

[00038] Referring to Fig. 4, in one implementation, an exemplary client- side content player 112 has a live multicast player 402 and a saved content player 404 that includes a client-side DRM module 406. The exemplary client- side content player 112 has access to a local storage medium for content 410 recorded from the live multicast player 402. The client-side content player 112 simply saves the encrypted content 410 received from restricted multicast directly into local storage 408 for subsequent replays. In this implementation, there is no need to perform transcryption. For example, a user 106 may wish to record j + \ consecutive encryption blocks from block B₁ to block B_1+J for replays in the future.

[00039] In one implementation, the encryption blocks B_t,- - -,B_l+J along with the prime numbers p_t,- - -,p_l+J received from multicast are saved to the local storage 408. The saved files 410 can be distributed to other users or devices if desired, since as in a conventional DRM system, the protected content can be redistributed without restriction. Without a proper license, however, a user cannot play protected content.

[00040] A live multicast program may contain some uninteresting content such as advertisements that a user 106 does not wish to replay. In other words, a user 106 may save nonconsecutive encryption blocks into a saved file 410. A saved file 410 containing nonconsecutive encryption blocks can also occur when multiple saved files are merged into a single file. The exemplary integrated key schema works with a saved file 410 containing nonconsecutive encryption blocks. In fact, the exemplary key schema works equally well when a saved file 410 consists of an arbitrary combination of encryption blocks [B₁ 1 i e /} , where / is an arbitrary set of block indices.

Playing Back the Recorded Content

[00041] A valid license with appropriate rights is typically requested before a client-side content player 112 can consume the recorded content 410. A client 106 acquires a license from the license server 110. During license acquisition, the client 106 typically sends the license server 110 a list of the collection of block indices / that the saved file 410 contains, along with other identification information that may be present. A payment is sometimes required at this point in the process. After the license server 110 authenticates the client 106, the DRM secrets generator 206 (Fig. 2), which may be physically located in the license server 110, generates a DRM secret S₁ 246 according to S₁ = s^π'¹ mod n for the encryption blocks [B_t \ i e l} , where the scalar multiplication engine 242 calculates scalar product K₁ 244 as K₁ ≡ Y[ _eI P₁ , and delivers the single DRM secret 246 in a license to the client

106. Only a single secret key 246 is contained in the license to be delivered to a client 106.

[00042] In playing-back recorded encryption blocks B₁J t I , the client- side DRM module 406 calculates the corresponding decryption keys K₁ 304 from both the DRM secret S₁ 246 contained in the license and the received prime numbers p_t 318 via the equation k_t = s/^{π Pι} mod n (in this implementation, encryption and decryption are assumed to be symmetrical, i.e., the encryption key k_t and the decryption key k_t are the same key). Having generated the decryption key K₁ 304, the client-side DRM module 406 can decrypt the i -th block B₁ 302. This process can be applied to all the recorded encryption blocks {BJ i e l} contained in the saved file 410. As analyzed further below, the client-side content player 112 can derive only the content encryption keys 304 associated with the blocks [B₁ \ i e l} , which is exactly the permission to decrypt granted by the license server 110 during the license acquisition. The client-side DRM module 406 cannot derive encryption keys associated with any other blocks.

[00043] It is worth noting that the above playback applies only to the recorded content 410. The exemplary DRM part of the operation does not affect live multicast playing. In fact, content being received via live multicast can be played as usual as if the exemplary integrated key schema was absent.

Exemplary Methods

[00044] Fig. 5 shows an exemplary method 500 of integrating DRM with encrypted multicast. In the flow diagram, the operations are summarized in individual blocks. The exemplary method 500 may be performed by hardware, software, or combinations of hardware, software, firmware, etc., for example, by components of the exemplary multicast/DRM engine 104. [00045] At block 502, a prime number is generated for each block of a data content to be multicast. In one implementation, a prime number generator produces two large prime numbers p and q, and obtains a secret φ(n) by calculating φ(n) = (p - \)(q - 1) . A collection P of prime numbers is created. Then, a selection schema produces a pseudo-random sequence of the distinct prime numbers, where each prime number p_t in the sequence is co-prime to φ(n) and is assigned to a block B₁ of content to be multicast.

[00046] At block 504, a content encryption key is derived for each block from the corresponding prime number p_t of each block. In one implementation, to generate a content encryption key k_t for an encryption block B₁ , a random integer s is generated, wherein s is relatively prime to a product of the two large prime numbers. Then the content encryption key is defined as s^Pl mod(n) .

[00047] Each prime number secret p_t may be packaged into an auxiliary field in the corresponding encryption block to be sent to clients. Or, the prime numbers can be multicast in-band to clients separately from the content. [00048] At block 506, a single DRM decryption secret is derived from the corresponding prime numbers of a stored collection of the blocks. That is, a single DRM key can be derived from the identities of a stored, arbitrary collection of multicast content blocks. The single DRM key is typically transmitted to a client in a license requested by the client. During license acquisition, the client typically sends the license server a list of the block indices / in a collection of blocks constituting a saved recording. The single

DRM key S₁ is generated by calculating S₁ = s^π'' moan for the encryption blocks that happen to be in the client's saved recording file, where π_t ≡ Y\_{t I} P₁ , and P₁ is the prime number associated with the saved block B₁. [00049] In playing-back a recorded encryption block, its decryption key k_t is calculated from the received single DRM secret S₁ contained in the license and the prime number p_t associated with the encryption block B₁ , via the equation K₁ = s/^{π Pι} mod n . Having generated the decryption key K₁ , the i -th block B₁ can be decrypted. This process can be applied to all the recorded encryption blocks included in the client's recording.

Security Analysis of the Exemplary Integrated Key Schema [00050] Security of the exemplary integrated key schema is now analyzed. In one implementation, the security of the exemplary schema depends on the deduction of φ{n) 218, which is usually done by factoring n 214. Factoring a large integer is believed to be a hard problem that the security of well-known RSA encryption schemata also relies upon. Thus, the exemplary key schema appears secure, but further proof is now offered. [00051] The keys {k_t \ i <≡ I} can derive the secret S₁ 246 and vice versa with the selected prime numbers made available. Key K₁ 304 is calculated by S_j ^M mod rc as described above. Reversely, S₁ 246 can be computed from the keys {k_t | / e /} . Since the integers {p_t \ i e l} 318 are different prime numbers, the integers [U₁Ip₁ \ i <≡ I} are co-prime. Recall that scalar product π_t 244 is calculated by U₁ ≡ Y[ p_t . Therefore there exists a set of integers {a_t \ i <≡ I} such that Υ_Ji£i (π_I/p_ι) - a_ι = 1 . The set of integers {a_t | / <≡ /} can be calculated with the Euclidean algorithm. Then, Y\_ιeI k"' = S₁ , that is, S₁ 246 can indeed be calculated from the keys {k_t \ i e /} . It can thus be concluded that knowledge of the keys [k_t \ i <≡ I} is equivalent to knowledge of the key S₁ 246 when all the prime numbers used are publicly available.

[00052] Security of the exemplary integrated key schema is also equivalent to the following mathematical problem:

[00053] Given a message m , a positive integer n = pq of the product of two large unknown primes p and q , and a set of signatures C₁ = m^d' moan signed with the distinct RSA private keys {d_t \ i > 0} , find the signature c₀ = m^d° signed by another private key d₀ , where all the corresponding RSA public keys {e_t 0} are distinct primes.

[00054] The above problem appears to be a hard problem. Like other hard problems in cryptography, it often cannot be proved mathematically that the problem is indeed a hard problem. In the following, we shall prove that the exemplary integrated key schema is equivalent to the strong RSA problem which is believed to be a hard problem. Therefore the exemplary integrated key schema is secure.

[00055] From a different viewpoint for offering proof of security, if an adversary could break the exemplary integrated key schema described above, then it can be shown that, by the same token, the adversary should also be able to solve the "Strong RSA problem", which is believed to be a hard problem. In other words, cracking the security of the exemplary integrated key schema would be tantamount to breaking Strong RSA encryption itself, as now demonstrated:

[00056] Definition (strong RSA assumption): Given a RSA modula n , and a random number c <≡ Z_n ^* , it is hard to compute a pair (e, m) , such that m^e = cmodn .

[00057] Lemma: The exemplary integrated key schema is equivalent to the strong RSA problem.

[00058] Proof: Assume that an adversary A can break the exemplary integrated key schema, then it is possible to build an algorithm B to solve the

Strong RSA problem. On input (n,c) , B aims to output a pair (e,m) , such that m^e = c moan . B uses the following method-of-operation with A .

[00059] First, B chooses a primes p_t (z e [0, • • •,«]) , and sets β = Y\_{ιe 0 a} P₁ , and then computes s = c^β mod/? . Finally, B gives (n,s) to A . This simulates the "setting up" and aspects of the "multicasting" processing

phases of the exemplary integrated key schema described above.

[00060] Then A can ask B for k_t , a times. B replies as (p_t,k_t) , such

JL that ^ = C"¹ mod ft . Note that gcd(β,p_t) = p_t , hence y is an integer. This

simulates the "multicasting," "recording content," and "playing back recorded

content" processing phases of the exemplary integrated key schema, described

above.

[00061] At last, A outputs a valid new key k for a prime e , such that i L k = s^e = c^e modn . Then B can solve the Strong RSA problem, and obtains m

as follows:

1. Since gcd(/?,e) = l , then there is a pair (a,b) , such that aβ + be = l .

2. Compute m = k^a χ c^b modn . Since m^e = (k^a x c^by modn = (c —^e c Y modn c^aβ+be modn = cmodn

This ends the proof.

[00062] The publicly distributed prime numbers {p_t} 228 can be used to

gain some knowledge of the secret φ(n) 218, i.e., φ(n) 218 cannot be divided

by these numbers. If multicast has rekeyed / -1 times, the search space for

φ{^ή) 218 shrinks to Y\_t__γ (P₁ "IVPX-_i P_> ^rel^ati^{ye to tne} original search space. If

all the prime numbers [P₁) 228 are large enough, and the total number of blocks is not very large, shrinkage of the search space is relatively small and should not cause any noticeable security vulnerability.

Comparison With the Conventional Techniques

[00063] The exemplary integrated key schema described above offers some major advantages over the conventional "direct" and "transcryption" straightforward methods described in the Background Section above. [00064] Compared with the conventional transcryption technique, the exemplary integrated key schema has the same simplicity that only a single secret 246 is generated and transmitted to a client 106 in a license, yet without the computational overhead, the complexity of negotiating a conventional DRM encryption key with the license server for re-encryption, and the additional security requirements needed for the conventional transcryption technique. No transcryption is needed in the exemplary key schema. Content from live multicast can be saved directly to the local storage 408 for subsequent replays.

[00065] Compared with the conventional "direct" recording technique, the exemplary integrated key schema has the same efficiency in saving the content directly to local storage 408, yet without the burden of complex key management or a large number of keys being delivered per license to a client. In other words, the integrated key schema combines the advantages of both of the above straightforward methods. [00066] The exemplary integrated key schema has an additional advantage over the conventional transcryption technique when multiple recorded files needing to be merged into a single one. In the conventional transcryption method, yet another transcryption is required since the recorded files are encrypted with different content encryption keys and the merged content needs to be encrypted with a single encryption key so that a license server knows how to generate the key when a client acquires a license. Merging can easily be accomplished in the exemplary integrated key schema (just as it is for the conventional direct recording technique) by simply concatenating recorded files together according to the sequence numbers of the encryption blocks and removing duplicated blocks. The resulting merged file can contain an arbitrary collection of blocks. These blocks are not necessarily consecutive. A new license may be needed to play the merged file. For the exemplary integrated key schema, the license server easily generates a new DRM secret 246 and delivers the single secret 246 to a client 106. But for conventional direct recording techniques, all the encryption keys associated with the encryption blocks contained in the merged file have to be delivered to the client. This means that the size of a conventional license in conventional DRM under the direct recording technique can be quite large. Conclusion

[00067] Although exemplary systems and methods have been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed methods, devices, systems, etc.

Claims

1. A method (500), comprising: generating a content encryption key to encrypt data whenever a rekey is needed in broadcast or multicast (504); and deriving a decryption secret for decrypting a stored collection of blocks of the data (506).

2. The method as recited in claim 1, wherein generating a content encryption key for each block of the data includes: generating a prime number for each block of the data to be multicast or broadcasted; and deriving a content encryption key for each block from each corresponding prime number.

3. The method as recited in claim 2, further comprising: deriving the decryption secret from the corresponding prime numbers of the stored collection of blocks; deriving a decryption key for each block in the collection of blocks from the decryption secret; and sending the decryption secret to a recipient to implement digital rights management (DRM).

4. The method as recited in claim 2, further comprising: generating two large prime numbers; deriving a secret number by multiplying a first quantity comprising the first large prime number minus one times a second quantity comprising the second large prime number minus one; and generating for a current block a prime number co-prime to the secret number and different from the prime numbers used for previous blocks, wherein a prime number can be reused if one of the parameters for generating the prime number is different from the parameters previously used for generating the same prime number.

5. The method as recited in claim 4, wherein generating a prime number for each block of a data content includes: generating a collection of prime numbers; applying a secret selection process to randomly select a prime number from the collection of prime numbers, the selected prime number being different from the previously selected prime numbers and co-prime to a secret obtained by multiplying a first quantity consisting of the first large prime number minus one times a second quantity consisting of the second large prime number minus one; and applying the selected prime number to the current block of the data.

6. The method as recited in claim 2, further comprising embedding each prime number in a corresponding block.

7. The method as recited in claim 2, further comprising transmitting each prime number to a recipient in-band with transmitting corresponding blocks.

8. The method as recited in claim 2, wherein deriving the content encryption key for each block from each corresponding prime number further comprises calculating k_t = s^Pl mod(n) ; wherein k, is the content encryption key for the z-th block; wherein n=pq is a multiplication product of two large prime numbers /? and q; wherein s is an integer in the range of (1, ή) and co-prime to n\ and wherein p_t is the prime number corresponding to the z-th block and co- prime to φ{n) = {p - \){q - 1) .

9. The method as recited in claim 0, wherein deriving the single decryption secret for a collection of the blocks further comprises calculating

S₁ = s^πj mod(«) , wherein sj is the single decryption secret for a collection / of the blocks, n is a multiplication product of two large prime numbers, s is an integer co-prime to n, and π₇ is a scalar multiplication product π_: ≡ \\_ιΛ P₁ , wherein p_t is the prime number corresponding to the z-th block.

10. The method as recited in claim 9, further comprising deriving the decryption key for each block in the collection of blocks from the single decryption secret by calculating k, = s_I ^π'^lp' mod(«) , wherein k, is the content encryption key for the z-th block.

11. The method as recited in claim 1 , further comprising transmitting the decryption secret(s) to a recipient in a license for deriving decryption keys for a collection of blocks of the data content.

12. The method as recited in claim 1, further comprising encrypting blocks of the data content via the content encryption keys; sending the encrypted blocks via multicast or broadcast to a client; wherein the encrypted blocks are stored on a local storage medium of the client; and sending the decryption secret(s) to the client to decrypt the collection of blocks selected from the locally stored encrypted blocks.

13. The method as recited in claim 12, wherein storing the encrypted blocks on the local storage medium further comprises either: storing the encrypted blocks directly on the medium as encrypted multicast or broadcast blocks; or transcrypting the encrypted multicast blocks into a DRM format and then storing the encrypted blocks as DRM encrypted blocks.

14. A system (104), comprising: a content encryption key generator (204) for creating an encryption key for each block of a data content to be multicast or broadcasted; and a rights management (DRM) secrets generator (206) to create DRM decryption secret(s) (246) to be used to derive decryption keys for decrypting a stored collection of blocks (410) of the data content.

15. The system as recited in claim 14, wherein the content encryption key generator creates a new encryption key to begin a new block of the data content whenever rekeying is needed in the multicast or broadcast.

16. A system (104), comprising: a prime numbers generator (202) for creating a prime number for each block of a data content to be multicast or broadcasted; a content encryption key generator (204) for deriving a content encryption key for each block from each corresponding prime number; and a digital rights management (DRM) secrets generator (206) to create a single DRM decryption secret from the corresponding prime numbers associated with a stored collection of blocks.

17. The system as recited in claim 16, wherein the secrets generator includes: a prime number collection generator to generate a collection of prime numbers; a prime number selector to randomly select prime numbers sequentially from the collection of prime numbers to form a random sequence of distinct prime numbers, which are all co-prime to a secret obtained by multiplying a first quantity consisting of the first large prime number minus one times a second quantity consisting of the second large prime number minus one.

18. The system as recited in claim 16, wherein the content encryption key generator calculates Jc₁ = s^Pl moά(n) to generate a content encryption key; wherein k, is the content encryption key for the z-th block; wherein n=pq is a multiplication product of two large prime numbers /? and q; wherein s is an integer in the range of (1, n) and co-prime to n; wherein p_t is the prime number corresponding to the z-th block ; and wherein p_t is a prime number that is co-prime to a secret obtained by multiplying a first quantity consisting of the first large prime number minus one times a second quantity consisting of the second large prime number minus one.

19. The system as recited in claim 16, wherein the DRM secrets generator derives the single DRM decryption secret for an arbitrary collection of the blocks by calculating S₁ = s^π' mod(«) , wherein S₁ is the single decryption secret for the collection / of the blocks, n is a multiplication product of two large prime numbers, s is an integer generated from n, and π_/is a scalar multiplication product π_t ≡ Y[ p_t , wherein p_t is the prime number corresponding to the z-th block, and wherein p_t is a number co-prime to a secret obtained by multiplying a first quantity consisting of the first large prime number minus one times a second quantity consisting of the second large prime number minus one.

20. The system as recited in claim 19, further comprising a client- side DRM module, wherein the client-side DRM module derives a decryption key for each block in the collection of blocks from the single DRM decryption secret by calculating K₁ = s₁ ^π'^lp' mod(«) , wherein k, is the content encryption key for the z-th block.