EP2119092A2 - Method and system for a recursive security protocol for digital copyright control - Google Patents
Method and system for a recursive security protocol for digital copyright controlInfo
- Publication number
- EP2119092A2 EP2119092A2 EP07772246A EP07772246A EP2119092A2 EP 2119092 A2 EP2119092 A2 EP 2119092A2 EP 07772246 A EP07772246 A EP 07772246A EP 07772246 A EP07772246 A EP 07772246A EP 2119092 A2 EP2119092 A2 EP 2119092A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- key
- bit stream
- data structure
- encrypted
- mac
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
- H04L2209/603—Digital right managament [DRM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
- H04N21/2347—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving video stream encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
- H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video stream decryption
Definitions
- This invention relates in general to the protection of digital content, and more particularly, to the protection of digital data through the use of encryption. Even more particularly this invention relates to protecting digital content with a recursive security protocol which provides both greater security and greater flexibility than currently utilized methods .
- Prior art systems utilize a few basic operational categories of digital data encryption and decryption technologies . These categories are based on the use of the security algorithms themselves and are independent of the actual mechanism for encrypting or decrypting the actual data. These well-known technologies and widely described classifications and technologies are:
- security protocol The means by which these technologies are used in a given security system is known as a security protocol .
- security protocol is independent of the actual underlying mechanics of how the various functions are implemented.
- even a perfectly secure encryption algorithm may potentially be used inside a security protocol that compromises overall security in such as way as to defeat the secure aspect of the encryption technology itself. Consequently, the overall security of any given security system is dependent not only on the relative strength of the underlying security technologies but also by the way in which these security technologies are put into use.
- Prior attempts at implementing security system have made (artificial) distinctions between the various types of bit streams to be protected.
- Systems and methods for security protocols which may utilize a variety of encryption techniques to better protect digital content are disclosed. These systems and methods allow allows one to encode any bit stream (such as an audio / video stream or other digital data, such as a software application) in a manner which allows a user to make as many backup copies of the original data set as they wish, but which may still require permission of any copyright holders in order to make use of such copies .
- the bit stream is encrypted and this result is associated with a decryption algorithm.
- This combination is in turn encrypted, with the result of this second encryption yielding a second bit stream, which is in turn associated with a second decryption algorithm.
- each bit stream is decrypted using the associated decryption algorithm and one or more keys.
- these keys may reside on a server or the keys may reside in hardware on the target machine . [0014] In yet other embodiments, these keys are contained in a key data structure.
- Still other embodiments include a key list data structure containing one or more key data structures.
- More specific embodiments include this key list data structure residing on a central server.
- a message digest is used to determine if an encrypted bit stream is genuine.
- a message digest is used to determine if a decrypted bit stream is genuine.
- FIGURE 1 is a block diagram of an embodiment of a security protocol engine .
- FIGURE 2 is a representation of an embodiment of a decryption key data structure.
- FIGURE 3 is a diagram for an embodiment of the encryption and distribution process of a security protocol.
- FIGURE 4 is a diagram of the decryption and loading process for an embodiment of a security protocol.
- FIGURE 5 is a diagram of one embodiment of the encryption/decryption process of a security protocol.
- FIGURE 6 is a representation of an embodiment of a key list data structure; and
- FIGURE 7 is a diagram of an embodiment of the temporary key ownership transfer procedure.
- This capability means that the security protocol can be updated (to fix recently discovered security holes, for example) without requiring any changes to the hardware on which it is running, even during execution.
- the "older.” security system is "subsumed” as a part of the newer security system (i.e., you never have to strip the old protection "wrapper" away in order to add a new, more secure level of protection to the entire system) .
- the entire system is encapsulated in the latest, most secure encryption and/or access control system. Not only may new keys be added, but entirely new security and/or encryption algorithms can be added on top of existing systems as well .
- This flexibility allows the protocol to support a number of business models, including Time-limited Rental, Pay- per-View, Multiple Versioning, Machine-dependent License Revocation and Permanent Transfer of Ownership from one user to another.
- the security protocol described herein does not require any sort of access control system in order to make it useful .
- the security protocols described concentrate on controlling the expression of the copyrighted work, not on the digital data that make up the work itself. As such, the protocol makes no distinction between digital data that is used to encapsulate a copyrighted work or other digital data that is used to describe how that work is to be interpreted. As a result, the protocol can even be used to encapsulate other security protocols.
- Embodiments of the security protocol are designed to enable the author of a piece of software to have a high degree of confidence that their code is protected from disassembly by those who would like to copy or otherwise misappropriate its algorithm. They are also designed to protect this code from modification by those who would attempt to alter its functionality.
- One of the methods by which these primary characteristics can be implemented in an otherwise general purpose computing system is discussed in a following section.
- An additional property, which occurs as a byproduct of these two primary functions, is the ability to control the conditions under which the software can be run (i.e., when and how and on which machine or machines the code is allowed to be executed) .
- the first of these functions may be accomplished by adding a tamper-resistant timer element to the system.
- Others are accomplished by means of implementing a secure data structure, which is used to indicate the desired conditions, which must be met in order to execute the code block in question. Since this data structure is not hardware specific, it can be used in a variety of ways and is able to be modified by updating the software that is used to interpret it. Hardware specific features utilized to implement the protocol more efficiently are discussed, and examples of how these features can be put to use in order to support the protocol are given. Finally, we will show how the protocol can be used to protect a copyrighted work.
- Embodiments of the security protocol depend on the ability to encrypt a block of code in such as way as to only allow it to be decrypted by its intended recipient. This is a well-understood problem and is the basis of a large number of industry-standard encryption algorithms .
- Elements of the security protocol system may include a set of hardware blocks, which implement the protocol in a secure manner on a protocol engine (also known as a "target unit") 100.
- a protocol engine also known as a "target unit” 100.
- An example overall block diagram of a device that is capable of executing this security protocol is shown in Figure 1. These blocks are not required to be cast in hardware in order for the protocol to operate correctly, however, a device that includes all of the hardware elements described below will be capable of implementing the protocol with a minimum of overhead.
- the first of these hardware blocks is a real-time clock 102.
- This is a free-running timer that is capable of being set or reset by a secure interaction with a central server. Although this is not a completely essential block, since the time may be established by conducting a query of a secure time standard, it would be more convenient to have this function be on-chip. This has to do with time-dependent software licenses and examples of such will be given in a later section of this document.
- Another hardware element is a block of memory 110 where code that is to be executed can be stored on-chip.
- This is typically known as an I-cache, but in some embodiments an important characteristic of portions of this I-Cache 110 is that the data contained within certain blocks be readable only by CPU execution unit 120. In other words, this particular block of I-Cache memory 130 is execute- only and may not be read from nor written to by any software.
- this special section of I- Cache as the "secured code block" 130. The manner by which code to be executed is actually deposited in this secured I-Cache block 130 may be by way of another hardware elements .
- Another potential manner for dealing with the "leaking" of register-stored data between secure and non-secure code segments is to identify a unique set of registers which are to be used only when the CPU 120 is executing secured code. For some CPU architectures with large general purpose register sets 140, this might at first seem prohibitively expensive. However, the same effect could be accomplished without requiring an inordinate amount of overhead (i.e., without the silicon overhead involved in implementing a physically distinct set of "secure" registers) by using a modified version of the register renaming and scoreboarding construction, which is practiced in many contemporary CPU designs.
- One-Way Hash Function block 160 is also depicted. It is possible to construct an engine that will be able to execute embodiments of the security protocol without having to implement this functionality in hardware. However, a hardware accelerator for certain parts of the hashing algorithm is certainly a desirable feature. Tradeoffs between hardware and software implementation of this functional block are discussed later.
- Another portion of the target unit 100 may be a hardware- assisted decryption system 170, which uses the target unit's 100 secret keys and public/private keys (described later) to operate on encrypted messages in order to translate them into executable code blocks.
- This decryption system 170 can be implemented in a number of ways. The speed and the security of the entire protocol may be dependent on the construction of this block, so it should be both flexible enough to accommodate security system updates as well as fast enough to allow the system to perform real-time code updates .
- This block is optional. Additionally, it can be replaced by a suitable off-chip method of producing a sequence of sufficiently random numbers, which can then' be used to supply seed values for a software-based pseudo-random number generation system.
- This pseudo-random number generator can also potentially be implemented in hardware or in "secure" software.
- the same principle trade-off between the flexibility of a software-based system versus a hardware implementation applies in this case as well. However, since the case where the target device 100 must generate a random number is not a frequent occurrence in this protocol, it is not likely to have an impact on overall performance if this particular function is not hardware-accelerated.
- Each protocol engine (“target" unit) 100 may have two sets of secret key constants 104 that are stored on-chip; the values of neither of which are software-readable.
- the first of these keys (the primary secret key) can actually be organized as a set of secret keys, of which only one is readable at any particular time. If the "ownership" of a unit is changed (e.g., the equipment containing the chip is sold or otherwise transferred) , then the currently active primary secret key may be "cleared” or overwritten by a different value . This value can either be transferred to the unit in a secure manner or it can be already stored in the unit in such a manner that it is only used when this first key is cleared.
- this is equivalent to issuing a new primary secret key to that particular unit when its ownership is changed or if there is some other reason for such a change (such as a compromised key) .
- the only other place where this primary secret key value is stored is on a central server at a licensing authority.
- the primary secret key may be associated with a particular target unit's 100 serial number 106 in the central server's database.
- the serial number 106 can be stored anywhere on the target device 100, may be software accessible and has no other relationship to the primary secret key. Any updates to the operational aspects of the unit (such as updating the security system) may be accomplished by using the primary secret key. If the value of this key is not known by any parties other than the target unit 100 and the licensing authority, it cannot be used for any secure transactions that do not involve a link through a secure central server. However, since the security of this primary key is of paramount importance, it should be used only when absolutely necessary.
- the secondary secret key may be known only to the target unit 100 itself (and thus, not to the licensing authority) . Since the CPU 120 of the target unit 100 cannot ever access the values of either the primary or the secondary secret keys, in some sense, the target unit 100 does not even "know" its own secret keys 104. These keys are only stored and used within the security block of the target unit's 100 CPU 120. It is the combination of both of these secret keys that enhances the overall security of the target unit. We will describe how they are used later on.
- Yet another set of keys may operate as part of a temporary public/private key system (also known as an asymmetric key system or a PKI system) .
- the keys 108 in this pair are generated on the fly and are used for establishing a secure communications link between similar units, without the intervention of a central server.
- these keys 108 must be larger in size than those of the set of secret keys 104 mentioned above.
- These keys 108 may be used in conjunction with the value that is present in the ⁇ n-chip timer block. Since these keys are generated on the fly, the manner by which they are generated in dependent on some sort of a random number generation system 180.
- care must be taken to ensure that the generated keys 108 should not be contained in the class of so-called "weak" keys.
- the specific set of keys that are considered "weak” are dependent on the specific encryption algorithm used.
- This procedure can be accomplished in one of several locations (for either of the two secret keys, but for logistical reasons, it should be the final step in the assembly process where either the serial number 106 or the secret key 104 can possibly be changed.
- this procedure is most likely performed at the point of final assembly. If the serial number 106 for the unit is stored on-chip, then it would be most practical to carry out this procedure at the last point in the chip manufacturing process (i.e., after the chip has been packaged) , so that any post—production or burn—in fall out has had a chance to winnow out the non-functional parts.
- the initialization procedure should be undertaken at a point where physical security is possible.
- the primary secret key should be initialized (or "burned" into the device) in a different procedure than the one that is used to supply the secondary secret key.
- this secondary key will be known at some point (since it is programmed into the unit at some point during the manufacturing process) , the unit with which it is associated should not be recorded anywhere once it is stored on the target device 100.
- both of these secret keys 104 should be implemented in a tamper- proof manner, for reasons, which are described later. It is not material in which order these two secret keys 104 are initialized. Following the initialization procedure described in the exemplary embodiment, the only location (other than on the actual chip) where the target device 100s' serial number 106 and their associated primary secret keys 104 are co-located should be on the secure server at the licensing authority 510.
- an application After an application is debugged, it is encoded using an application—specific encryption algorithm and key(s), which are known only to the original developer.
- This application-specific algorithm and key(s) can either be a symmetric (secret) key system or an asymmetric (PKI) key- based system.
- Attached to the end of the encrypted block of code is a digital signature (or MAC) , which is signed by the developer 520 using the private key of their published public key/private key pair (which thus forms an unambiguous digital signature for the encrypted code block) .
- Either the digital signature or the original MAC, which was encrypted to form the digital signature and the corresponding Code specific ID number may be supplied to the licensing authority.
- the application developer 520 may also choose to supply the appropriate decoding key(s) as well (we will discuss the tradeoffs of this decision in a later section of this document) .
- the application-specific algorithm is an asymmetric encryption, it does not necessarily need to be encrypted using the same published PKI key pair that is used to generate the message authentication code.
- the MAC that is stored at the end of the code block should be generated using a known hashing algorithm and must also be signed using one of the developer's published public keys (thus forming the digital signature) . This allows the target to verify the authenticity of the MAC using a known hashing function and a public key.
- All application-specific encryption key data structures 210 may contain a number of extra fields (in addition to the decryption key itself 220) .
- One of these fields comprises a timestamp 230 and an associated mask value 240.
- the second contains a "countdown value" 250.
- the mask value 240 is used in conjunction with the other two fields 230, 250 in order to determine when the key is valid.
- An example of this structure is shown in Figure 2 (although there are a number of means by which this same functionality can be implemented) . It should also be noted that it is not relevant to the protocol exactly how many bits are allocated to each of the fields.
- the timestamp value 230 can be used in several ways, depending on bit pattern that is stored the in timestamp mask 240 field.
- the timestamp mask 240 value allows the developer 520 to select some subset of the timestamp figure that is ignored when performing the comparison with the target unit's 100 current time. As an example, however,- if we assume that the smallest resolution which is supported by the timestamp field 230 is one second, then by masking out the lower five bits of the timestamp data 230, a particular key data structure 210 can be generated which is only valid when used over the course of approximately 32 seconds starting at the time which is stored in the timestamp field 230.
- the overall functionality of the security protocol is not dependent on the actual resolution of the lowest order bit of the timestamp field 230.
- mask field 240 There may be other bits that are associated with the mask field 240, some of which can be used to indicate whether the key is valid before or after the value specified in the timestamp 230. Yet another mask field 240 bit can be used to indicate how the timestamp 230 and the "countdown" values 250 are associated. For example, this would be useful in the case where the intent of the application developer 520 was to limit the use of the software to a certain number of iterations either prior to or after a certain date, rather than simply tied to a certain date and time window. Of course, any combination of these conditions can be constructed, so the protocol is quite flexible in this regard.
- further flags can be included in this data structure to indicate other properties, such as how many legal copies of the keys may be simultaneously distributed from the original target unit 100 to others. This would be useful in the case where a multiple-copy license were desired, such as is seen in a digital library, for example.
- FIG. 3 A flow diagram representing one embodiment of the encryption process can be seen in Figure 3 on the next page. Note that there is no substantive difference between the process that would be used to distribute a digital media stream or a software application (such as the decryption instructions used to interpret that media stream) . In either case, there are a couple of different options for distributing the encrypted code block (s) 310, 320; either via an online server or on serialized discs (such as a standard DVD) . In the latter case, the developer 520 can then choose to pre-register the individual serial numbers of the mass-produced discs with the licensing authority 510 (or not) .
- the serial numbers could be permanently affixed to the discs either by burning them into the Burst Cutting Area (in the case of a DVD) or by ink-jet imprinting in the case of a standard CD. Note that the developer 520 cannot embed these serial numbers ' into the data area of the CD or DVD, since the same serial number would be replicated on all of the mass-produced discs. If some sort of a hybrid format were used, where part of the disc could be mass- produced and another portion written once, then this would be another potential method of distributing the discs with individual serial numbers. In any case, a machine-readable serial number is certainly preferable, since it is less prone to errors in the registration process .
- the application developer 520 may either register the code-specific ID or an associated media serial number. In the former case, then the application can be distributed freely (i.e., not tied to a specific release format and media) .
- This function could be accomplished just as well by using a printed manual (or even a simple registration form) with an individual serial number sticker attached to it . All that is required is that the developer 520 must produce some physical object with a unique serial number, which is purchased by the end user. The purpose of this serial number is to act as a "proof-of-purchase" and/or a software registration number. We will discuss how this serial number is used in the protocol in a following section. For the example shown in Figure 3, both the encrypted software application (or media stream) 310 and the machine dependent decryption software 330 are distributed using the same mechanism. It is not a requirement of the protocol that this should be the case and either or both of the encrypted code blocks 310, 330 can be distributed on-line or by pressing a disc.
- the media stream itself is most likely the larger of the two blocks 310, 320 by several orders of magnitude. Thus, in that case, it makes the most sense to effect the distribution of at least this block in a mass-produced disc format.
- the companion encrypted, code block 320 the one which contains the instructions of how to decode the first block
- the primary encrypted code block the companion encrypted, code block 320 (the one which contains the instructions of how to decode the first block) as well as the primary encrypted code block.
- neither of the two data sets would be likely to undergo any changes after publication, so there is no fundamental requirement that they must be distributed online. As such, they are both well-suited to a mass-produced disc based distribution mechanism. Having both of them on the same disc also makes it easier to associate one with the other in an unambiguous fashion.
- the consumer can purchase the disc containing the application in exactly the same manner as a traditional software purchase.
- the end-user would not be able to run the encrypted code block unmodified on the processor of the "target" unit 100.
- the CPU 120 loads the encrypted software block and uses the digital signature (the "signed" MAC) stored at the end of the code block along with the software developer's public key to verify that the code block in question is genuine. This is where the first hardware modification to an otherwise general purpose CPU 120 may come into play.
- the process for loading and decrypting such a block of secured code is shown in Figure 4.
- the CPU 120 In order to make sure that the hashing function is computed correctly (and furthermore, that the comparison between the generated message digest and the "real" message digest is valid) , the CPU 120 must perform this hashing function in a secure manner. Thus, the hashing function must either be generated directly by the hardware of the decoder unit or the hashing function itself must be computed using a block of "secure” code, the operation of which cannot be tampered with by an otherwise "non-secure" program.
- this block of secure code should be considered as a part of the unit' s 100 security system and, as such, may only be able to be downloaded to the player via a secure transaction between the unit 100 and the licensing authority 510.
- the establishment of a "secure" hashing function can be accomplished via the same secure protocols described herein. This recursive behavior for all aspects of the security system is what enables a software-based version of this protocol to be extremely flexible (and thus, updateable) in its encryption/decryption architecture .
- the target unit 100 can be certain that the encrypted code block 310 is genuine (or at least that the code was distributed by the developer 520 whose public key was used to decrypt the digital signature) .
- the target 100 then sends a secure message to the licensing authority 510 requesting a copy of the • decryption key(s), which will be used in concert with the recently verified encrypted code block 310.
- the target unit 100 As a part of setting up the secure connection with the licensing authority 510, the target unit 100 generates a temporary public/private key pair (the public portion of which is supplied to the licensing authority 510 server) .
- the details of the key exchange procedure are well known and we need not go into the exact mechanism by which this is accomplished in this discussion.
- the overall network traffic between the target unit 100 and the central server at the licensing authority 510 is limited to a reasonably small data set, since it consists of a couple of key transfers, the code- specific ID and the MAC which was stored along with it. Assuming that the code-specific ID is one that the licensing authority 510 recognizes, there may be two possible courses of action, depending on whether or not the application author has already provided the licensing authority 510 with a "clear" copy of the requested decryption key(s) .
- the central server transmits a copy of the target device 100' s temporary public key (as well as the code-specific ID in question) to the application developer's server 520.
- the developer's server 520 responds to the licensing authority 510 server with a message containing the requested decryption key(s) (encrypted with the target' s temporary public key) and a message digest generated from the properly decrypted code. In this manner, only the target device 100 can decrypt the message to obtain the decryption key(s) and the licensing authority 510 will not ever have access to the decryption key(s) in clear form.
- the message digest can be pre-computed and stored on the licensing authority' s 520 server, the fact that it may be provided by the developer 520 during the transaction is of potential use if the hashing function (which is used to generate the message digest) should • ever change. If this should happen, the developer 520 would need to provide updated versions of the decrypted code message digests to the licensing authority 510 either prior to or during the actual transaction with the target device 100. The developer 520 must provide this information since the licensing authority 510 should never have access to the original (decrypted) code- As before, the amount of network traffic between the licensing authority's 510 server and the developer's 520 server is still quite small. The encrypted key that was received from the developer 520 is then encrypted yet again with the target device 100' s primary secret key prior to transmission from the licensing authority 510 to the target.
- the application developer 520 wishes to stay "out of the loop" for transactions between the licensing authority 510 and the target device 100 100, they can simply provide the licensing authority 510 with a copy of the relevant decryption key(s) in clear (unencrypted) form and the associated MAC for the decrypted code block (the value of which must be updated each time the hashing algorithm is changed) .
- the central server at the licensing authority 510 would be able to act autonomously and would not be required to establish a communications link to the developer' s server 520 in order to fulfill a key request from a target unit. However, this is a potential security risk to the developer, should this "clear key" information ever be compromised .
- the clear key would still be encrypted prior to transmission (as above) with, both the target device' s 100 temporary public key and then again with the target's primary secret key.
- the target device 100 has the proper decryption key in a doubly encrypted format.
- the licensing authority 510 does not have access to the application specific key 550 information in the clear, then it should not be possible for anyone other than the intended target device 100 to be able to reproduce this key data in clear form, since the secret key for each unit 100 should only be known to the licensing authority 510, and the private key for the transmission is known only by the target 100.
- the encoded decryption key(s) which the target 100 receives from the application developer 520 cannot yet be stored safely in the open at the target 100 (e.g. in a flash ROM or backed up on a hard drive) .
- the problem is that the target device 100 would also have to store a copy of the temporary private key along with the encoded decryption key(s), which were transmitted from the licensing authority 510. If someone at the licensing authority 510 were to then gain access to these two pieces of data by some means, then they would potentially be able to reconstruct the decrypted application specific key 550 (given that they might have access to the target device's 100 primary secret key as well) .
- the target can then use the application specific (clear) key in order to decrypt the code block (or media stream) .
- the only two places where the application code exists in clear form are at the original developer 520 itself and inside the "secured" portion of the target device's 100 I-Cache 110 ⁇ where it can only be executed and can never written back out to memory in clear form) .
- This allows privacy between the user and the licensing authority 510.
- the licensing authority 510 does not have to know what it is that the user has a license to (an enormous privacy issue) , but it is still able to act as a repository (or backup) for the user's key list in the case where their unit 100 is damaged or stolen or otherwise inoperable .
- the message digest of the properly decrypted code is then compared with the digital signature, which was forwarded from the original developer 520 through the licensing authority 510 to the target unit 100.
- this digital signature is created by encrypting the message digest of the unencrypted code block with the application developer's private key.
- this digital signature can also be encrypted again by the developer 520 using another temporary public key 530, which was supplied to the licensing authority 510 when the connection was established.
- the correct message digest can then be decoded by the target device 100 by decrypting the digital signature with the developer's public key.
- this message digest matches the hash of the decrypted code block, then the code is considered to be genuine and it is allowed to run on the target 100.
- This message digest may then be re-encrypted with the target unit' s 100 secondary key 540 for archival along with the re-encrypted application specific key 550.
- the flow diagram for the whole key encryption/decryption process is outlined in Figure 5 below.
- the final step in this procedure is that the newly encrypted version of the application specific key 560 is retransmitted back to the licensing authority 510 server for archival purposes . This transmission serves a few purposes. First, it is an acknowledgement that the target device 100 was able to properly decrypt the code block.
- the licensing authority 510 it is necessary for the licensing authority 510 to have a copy of this encrypted key 560 in order to deal with the case where the end user suffers some sort of catastrophic data failure and they have neglected to make their own backup copy of their access keys.
- the licensing authority 510 can then act as a backup storage facility for any particular user. Yet another reason for this procedure is in order to deal with the case where a particular target device 100 changes hands from one user to another or if the user wishes to upgrade their target device 100.
- This kind of permanent transfer of ownership can involve the transferal of all of the licensed application keys for that unit 100 (in which case, there is nothing which needs to be done other than reregistering the unit under the new owner' s name) .
- the other piece of information that the target device 100 transmits back to the licensing authority 510 server is the message digest of the target device's 100 newly- updated key list data structure 610. This is both an acknowledgement of the newly updated key list data 610 structure and is also used to verify the equivalence of the key list data structure 610 associated with that particular target device 100 on the licensing authority 510 server and on the target device 100.
- the exact construction of this data structure will be described in the following section. We will also discuss methods by which permanent transfer of ownership of a particular key or set of keys is accomplished in a later section.
- the process outlined above is not the only manner in which the protocol can be used to transfer the application specific key 550 from the developer 520 to the target device 100.
- the actual key transfer transaction can involve a direct connection only between the target 100 and the application developer 520.
- a connection must be established between the developer' s 520 server and the licensing authority' s 510 server in order to contribute the device specific encryption information to the transaction.
- this protocol can be made to work in a secure fashion, and the example discussed above is just one of these.
- the common thread is that all three parties must act together in order to ensure that the key data, which is transferred to the target 100, is only useable for that target device 100.
- the structure of a key can be set up to have two pieces : a hardware-specific part as well as an application-specific part. It is not a requirement that these two pieces be completely inseparable. If they are (inseparable) , then we get the properties discussed earlier. If, however, there is a way to make the key pieces independently operable, then we can enable a global set of copy and use restrictions that could be independent of the actual code or of the actual target device 100. In other words, any developer 520 could publish an application or media stream which had no restrictions on distribution, but which could not be read; only executed. This could be useful in the case where the licensing authority 510 wanted to send out a security system update that would run on all devices, regardless of the manufacturer.
- the data structure 610 containing the list of application or media-specific keys, which are licensed to a particular target device 100 is a valuable commodity and, as such, it should be able to be backed up by the owner. Since the individual keys are encrypted with the target' s secondary secret key (as described above) , the list is only useful to the unit to which the keys are licensed. However, we need to be able to make sure that this data structure 610 is secure from tampering, corruption and/or outright loss. In the case of a lost key list data structure 610, the entire data structure 610 can be recovered by requesting a new copy of the key list 610 for that particular target device 100 from the licensing authority 510, as was described earlier.
- the protocol may accommodate a means for identifying such a change as being temporary.
- the top-level encryption of the key list data structure 610 should be performed with the target device 100' s primary secret key.
- the licensing authority 510 must be able to regenerate the encrypted form of this data structure independently of the target device 100 in the case where the local copy of this data structure must be restored. If any other key is used to encrypt this data structure (such as the target's secondary secret key, for example) , then when the target 100 needs to make a change to the data structure (as is the case when a key is added to the list) , the entire list must be transferred to the licensing authority 510 for backup purposes .
- key list data structure 610 be used for the storage of security system-related keys, in addition to being used for the storage of standard application or media stream specific license keys . Since this data structure is able to be regenerated by the licensing authority 510, in cases where it is desirable to update the security software which runs on the target device 100, it would be both more secure and more efficient (from the standpoint of code storage requirements on the target device 100) if the same key list data structure 610 could be used for both functions.
- the encrypted version of the key list data structure 610 includes a message digest of the original key list data structure 610. It should be noted that although each of the individual keys are encrypted, other pieces of the list itself are not separately encrypted at the point when the message digest is calculated. Following the message digest calculation, the entire key list data structure 610 (including the message digest) is then encrypted with the key value and algorithm that are identified by the top-level (or master) key. This is done in order to prevent a malicious third party from tampering with the list, calculating a new message digest and then substituting the modified list for the genuine one .
- this (decrypted) message digest is used to verify the authenticity and validity of the key list itself in the same manner as the way that a MAC is used for any other secure encrypted code block.
- the fact that ail of the elements other than the individual keys are only encrypted with the master key means that the list can be traversed (and the list maintained) without having to have access to any keys other than the top-level key. Also, a key list inventory can be compiled with only a single pass through the decryption block.
- a third principle which is of interest is that the individual application code or media stream specific keys can be made large enough to accommodate individualized keys foe each target device 100.
- the code or the media stream is distributed by way of a mass- produced disc, this would mean that the application developer 520 would need to issue a new code-specific ID along with the individual decryption key(s).
- this may be less efficient from the standpoint of trying to minimize the amount of data which must be transferred between all of the parties involved in the licensing process, it does add functionality to the protocol, including (but not limited to) the ability to track compromised decryption keys. We will also discuss this in a later section dealing with key revocation.
- the key list data structure 610 header shares the same set of characteristics as the application specific keys that make up the rest of the list.
- the header can be thought of as a master key 620 for the rest of the key list data structure 610 itself.
- the same principles of operation can be applied as far as how this key can be used to determine the management of the rest of the list.
- This includes time-dependent management of the security system of the target device 100.
- the target unit 100 can be forced to update its security system at predetermined intervals, which is an extremely powerful concept all by itself .
- the key list could contain a number of sections, each with its own master key 620 (list header) and thus with its own independent encryption mechanism.
- the list header contains a code specific ID field, which can point to an encrypted code block that is used to interpret the key list data structure 610.
- the whole list could then be contained within yet another master list, which includes its own master key (yet another list header) .
- the entire key list data structure 610 can be recursively defined. As before, this recursive property can be used to update the security system by creating new key list data structure 610 s to address shortcomings of previous versions of the same data structure. Since the security of the whole list is contained within the "outermost" (or most recent) security layer, then the security of the entire key list data structure 610 is always based on the latest iteration of the security software.
- the key list 610 may be maintained and/or updated under several common circumstances. These circumstances include (but are not limited to) the case where the status of one or more of the keys contained in the list is modified. There are a few basic mechanisms by which the ownership of a particular key 210 can be transferred from one unit to another and we will discuss these in later sections. In any case, however, the mechanism by which the revised key 03
- the target device 100 can keep track of the current state of the master key list data structure 610 in an unambiguous manner.
- This can be accomplished by having two "master" lists. The first of these two lists (which we will call the permanent key list) is maintained by the licensing authority 510. This list is concerned with the "permanent" ownership of the application specific keys, that are associated with the target unit 100 in question. The second list is of equal importance, but it is that which is concerned with temporary modifications to the "permanent" key list data structure 610. Note that these modifications can either be additions to the list or they can be deletions from the list. There are no necessary differences in the implementation of the data structures of the two lists themselves; the main differences occur in how they are used.
- the main reason is that the temporary key list is most likely updated much more frequently than the permanent key list and we wish to keep the amount of required network traffic between the central licensing authority 510 and the target units 100 to an absolute minimum. Nonetheless, it may be potentially desirable for the licensing authority 510 to be able to make modifications to a particular target's 100 temporary key list for several reasons (some of which we will discuss later) . In this case, it would be desirable to have this list encrypted using the target device's 100 primary secret key (which is known to the licensing authority 510) . As mentioned earlier, the integrity of both of the key list data structures 610 can be verified by using the signed message digest (the digital signature) , which is stored along with the list itself.
- the digital signature the signed message digest
- the temporary key list data structure 610 is constructed in exactly the same manner as is the target device's 100 permanent key list. However, there are a couple of differences between the two. The first difference is that the temporary key list can potentially be encrypted with either one of the target unit's 100 secret keys. Since it is not necessary that the licensing authority 510 be able to reconstruct this data structure .under normal circumstances, it is ostensibly not relevant which one of the keys is used to encrypt it. However, it would potentially be of use to the licensing authority 510 if this list were also encrypted using the unit's 100 primary secret key. The reason for this has to do with license revocation and that situation will be discussed in a later section.
- a second (and more important) distinction between the temporary and the permanent key lists is that a copy of the timestamp value 230 which is associated with the temporary key list data structure is also stored inside the , target device 100.
- This register is not software readable and is only able to be overwritten by secure code, as it is a part of the security block. The value in this register is used to determine what to do in the case where the temporary key list data structure is somehow lost and/or corrupted. We will discuss that procedure later on in this section.
- a target unit 100 is able to (temporarily) transfer ownership of a particular key from its permanent list to another unit's 100 temporary list, but no (correctly operating) device is able to transfer ownership of a particular key from its temporary key list to any other key list.
- This "permanent loan” feature is equivalent to the standard "Copy Once" functionality requirement that is part of most modern digital Copyright Control Information (CCI) systems .
- CCI Copyright Control Information
- the "key ownership" transfer procedure is somewhat similar to the procedure of checking a copy of a book out from a library.
- the lender 710 When the "borrower 720" requests the temporary use of a particular application specific key 550 from the permanent owner (the "lender 710") , then the lender 710 first generates an updated temporary key list for itself which prohibits the use of that particular key for the duration of the key checkout negotiation process. This action prohibits more than one borrower 720 unit from requesting the same key.
- the presence of the "checked out key” on the temporary key list of the lender unit 710 is effectively used as a semaphore to control access to any particular key.
- the initial amount of time that the key is placed w on restriction" should be limited to a relatively short period.
- This relatively short checkout negotiation phase timeout also helps in the battle against the malicious device, which may be attempting to mount the equivalent of a "denial of service" attack against the lender unit 710.
- the lender unit 710 can optionally ignore requests from devices which are not on its "approved borrower" list or if any one of those units should try to make too many requests within a certain time period.
- the exact length of time that this temporary block is placed on the key is not important, but it should be long enough to allow any given checkout procedure to go to completion.
- FIG. 7 A detailed flow diagram depicting the temporary "key checkout" procedure is shown in Figure 7. Note that in the case where more than one copy of a given key is allowed to be simultaneously checked out, the appropriate fields within the lender device's 710 temporary key list can be used to indicate how many copies of a given key are checked out at any one point in time.
- the lender 710 sends an encrypted copy of the key 740 to the borrower 720. This encryption is carried out using a temporary secret key 730, which is known only to the lender device 710.
- the lender 710 When the borrower 720 then acknowledges the accurate receipt of the encrypted key (by means of a message digest which is calculated from the encrypted message) , then the lender 710 extends the "loan period" of the checked out key and then sends the temporary secret key 730 to the borrower device 720.
- the maximum duration of this loan process is not important to the operation of the protocol and there are some tradeoffs that must be made in the choice of this value. We will go over those particular issues later on in this section. In the example discussed above, we assume that the "borrower 720 " and the "lender 710 " devices are able to negotiate the actual length of the checkout period on a key-by-key basis, although this is certainly not a requirement of the protocol.
- a copy of the timestamp value 230 associated with this new temporary list is stored in a non-volatile fashion on the target 100.
- an encrypted version of the temporary key list data structure can be safely written out to memory (or stored in some other, more permanent location, such as on-board NVRAM, Flash ROM or even out to a backup file on some hard disk somewhere 750.
- the temporary key list is potentially read from and updated on a much more frequent basis than the permanent key list, it is desirable that this list should be quickly accessible to the target unit, so it is recommended (although it is not an actual requirement of the protocol) that this list be stored in at least one location where the access latency is relatively short.
- this list it is not recommended that the only place where this list is stored is some volatile storage medium (such as DRAM) , since a power failure could potentially cause the loss of the unit's 100 functionality for an indeterminate amount of time- We will go into details about this issue later on in this section.
- both the borrower 720 and the lender 710 devices can update their respective temporary key list databases independently. Thus, it is not a requirement that the borrower 720 be in contact with the lender 710 unit in order to "return a particular key to circulation". This is a major convenience factor in the case where the borrower 720 and the lender 710 devices are widely separated.
- the security of this operation may depend on a very tight correlation between the on-chip clocks that are used to generate and control the key timestamp records.
- the time/date clock must be an integral part of the security system and, as such, should be able to be overwritten by a transaction with the central server.
- the clocks must be designed to be robust enough to resist tampering in the case where a malicious user tries to modify the internal timestamp value 230 and also to be able to survive normally occurring system power failures. Since it is not inconceivable that this clock is battery powered and that the battery could get removed or it could go dead over time, the system should be designed in such, a way that the clock could potentially be restarted and reset by an interaction with the licensing authority.
- Another possibility for an enhancement is to store a pair of on-chip timestamp 230 values rather than just one.
- the additional timestamp 230 could be used to indicate the earliest (next) time when the temporary key list must be updated. This would make it easier for the target device 100 to decide when it needs to revise its temporary key list, since it would not have to constantly check over the list (which involves going through the decryption process) . Although this feature would be very useful, again, it is not a fundamental requirement in order for a unit to be able to execute this protocol.
- the permanent transfer is a simpler process than the temporary transfer and that the permanent key ownership transfer procedure may utilize an interaction between the licensing authority 510 and the target unit 100.
- the reason that the permanent transfer process is simpler lies in the fact that it does not require the checkout time period negotiations that are prerequisites in the temporary key checkout procedure .
- the reason that the permanent transfer function utilizes an interaction between the licensing authority 510 and the target unit 100 is due to the fact that the updated key list data structure must be able to be reconstructed at both ends of the transaction.
- Since a permanent license transfer usually occurs by means of an interaction with the licensing authority 510/ there is a record of which application or media stream specific keys belong to which target units.
- Another important aspect of the fact that the target unit's 100 permanent key list is maintained by the licensing authority 510 is that this body has the ability to revoke any or all of an individual target unit's 100 license keys in the event that it is proven that the unit 100 has somehow been compromised or if one of the keys has been identified as having been compromised. Since the potential exists to give a unique list of keys to each and every target unit 100 (as was described above) , there could also provide an opportunity for the licensing authority 510 to track the source of any compromised keys. In such a situation, this protocol could fulfill the functionality that is normally associated with that of a "watermark" feature, but without the drawbacks of the traditional watermark process (such as the potential of the watermark to have an adverse effect on the quality of the media stream) .
- the final issue that should be noted about the permanent key transfer process is that it is, in fact, possible to accomplish all of the same functions that the permanent key transfer performs with a temporary key license transfer.
- the maintenance of the target units' 100 security system is a function which should ideally be controlled by a central secure server, so it is necessary to have such a mechanism in place somewhere in the chain.
- the central server can act as a buffer between the copyright holder and the target unit 100 is of great utility.
- the licensing authority 510 is able to act as a central backup storage mechanism for a particular target unit' s 100 permanent key list that sets this functionality aside from the temporary key transfer mechanism.
- a target unit's 100 licenses may be revoked.
- the simplest method is that of simply updating the target's 100 primary secret key. At this point, the target 100 would then be unable to access its permanent key list and thus, it would have to begin the process of creating a new one .
- the primary secret key was not used in the encryption process for the temporary key list data structure, then this temporary key list could potentially still be accessed, even though the permanent key list might be otherwise inaccessible. This point was mentioned earlier in the description of the encryption process for the temporary key list. For this reason, it is probably the best idea to use the target unit' s 100 primary secret key as the encryption key for both the permanent and the temporary key list data structure 610.
- the simplest manner to effect this ownership change is to set the unit's 100 primary secret key to some new value. However, if this occurs before the original owner has the opportunity to recover all of their permanent keys from the target, then they will lose their licenses. In the case where the original owner wishes to transfer the ownership of the associated permanent key list along with the target unit, then nothing need be done to the target unit 100 except to change the ownership information that is associated with that particular device (which is stored at the licensing authority) .
- Yet another manner of license revocation can occur if the licensing authority 510 chooses to override a particular key entry in a target unit's 100 permanent or temporary key lists. This could be used in the case where if a security system upgrade is required or in the case where a particular target unit 100 has been identified as having an unlicensed copy of a particular application or media stream. Since the target unit 100 normally maintains its own key list data structure 610, this procedure will involve a larger than normal amount of network traffic between the licensing authority 510 and the target unit. Thus, this course of action should be reserved for extreme cases .
- the copyright holder wishes to limit the total number of devices to which the primary target is able to temporarily transfer ownership, this may be accomplished by means of establishing a limited number of public/private key pairs that may be active at any one time. Note that this is different than the case where multiple copies of the same application specific key(s) were simultaneously "on loan", which was described in an earlier section. Other scenarios are possible, where the list of devices which are able to "check out” any of the application specific keys from a particular target device 100 can be limited to a certain set of serial numbers.
- the licensing authority 510 can administer such an "approved borrower" list in exactly the same manner that the target unit's 100 security system is managed. Thus, the licensing authority 510 could, for example, limit the set of serial numbers on the "approved borrowers" list to those who have the same ownership information as the original target device 100.
- the problem on this end would ostensibly be limited to the imitation of an otherwise legitimate target unit 100 by an unlicensed device.
- both of a unit's 100 secret keys 104 were discovered by means of such a process, however, it is possible that it would be possible to compromise the security of all of the application specific keys which were licensed to that unit, based on an examination of previously backed up copies of the encrypted key list digests. For this reason, both the primary and the secondary secret keys should be implemented on target chip in a "tamper-proof" manner such that any attempt to discover the value of these keys results in the loss of the key data.
- any digital copyright protection scheme can possibly be defeated by the determined opponent.
- This is even independent, of course, of the fact that access to the secret key information would definitely be a big advantage to the would-be attacker.
- the ability to keep a unit's secret keys from being compromised is therefore an important part of this security protocol.
- the copyright protection protocol described above is unique in several ways. First is the fact that it does not attempt to prohibit the user from having the ability to make backup copies of their legally purchased application or media specific key data. Second, this protocol does not make a distinction between any kinds of digital data and thus, allows the security protocol to be updated as easily as the data streams that it is designed to protect. Third, this protocol allows the user to temporarily transfer ownership of their application or media specific key(s) to another unit that is capable of executing the protocol. Also, this protocol also provides the ability for the licensee to effect a permanent transfer of ownership from one target unit 100 to another. This last property allows the implementation of the consumer' s legal "right of first sale" under this protocol.
Abstract
Description
Claims
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2007/005803 WO2008108764A2 (en) | 2007-03-06 | 2007-03-06 | Method and system for a recursive security protocol for digital copyright control |
Publications (2)
Publication Number | Publication Date |
---|---|
EP2119092A2 true EP2119092A2 (en) | 2009-11-18 |
EP2119092A4 EP2119092A4 (en) | 2012-02-22 |
Family
ID=39738920
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP07772246A Withdrawn EP2119092A4 (en) | 2007-03-06 | 2007-03-06 | Method and system for a recursive security protocol for digital copyright control |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP2119092A4 (en) |
JP (1) | JP2010520703A (en) |
WO (1) | WO2008108764A2 (en) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7203844B1 (en) | 2002-06-20 | 2007-04-10 | Oxford William V | Method and system for a recursive security protocol for digital copyright control |
US8438392B2 (en) | 2002-06-20 | 2013-05-07 | Krimmeni Technologies, Inc. | Method and system for control of code execution on a general purpose computing device and control of code execution in a recursive security protocol |
US8588410B2 (en) | 2009-04-06 | 2013-11-19 | Elster Electricity, Llc | Simplified secure symmetrical key management |
US8509438B2 (en) * | 2010-01-29 | 2013-08-13 | Elster Solutions Llc | Key management in a wireless network using primary and secondary keys |
EP2828759A4 (en) * | 2012-03-20 | 2015-09-30 | Rubicon Labs Inc | Method and system for process working set isolation |
DE102015121861A1 (en) * | 2015-12-15 | 2017-06-22 | Endress + Hauser Flowtec Ag | Access key for a field device |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6398245B1 (en) * | 1998-08-13 | 2002-06-04 | International Business Machines Corporation | Key management system for digital content player |
US20050021941A1 (en) * | 2001-09-27 | 2005-01-27 | Motoji Ohmori | Encryption device a decrypting device a secret key generation device a copyright protection system and a cipher communication device |
US20050058291A1 (en) * | 2003-08-25 | 2005-03-17 | Brant Candelore | Apparatus and method for an iterative cryptographic block |
US20060101524A1 (en) * | 2004-11-05 | 2006-05-11 | Cable Television Laboratories, Inc. | Hierarchical encryption key system for securing digital media |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7809138B2 (en) * | 1999-03-16 | 2010-10-05 | Intertrust Technologies Corporation | Methods and apparatus for persistent control and protection of content |
US6226742B1 (en) * | 1998-04-20 | 2001-05-01 | Microsoft Corporation | Cryptographic technique that provides fast encryption and decryption and assures integrity of a ciphertext message through use of a message authentication code formed through cipher block chaining of the plaintext message |
US7073063B2 (en) * | 1999-03-27 | 2006-07-04 | Microsoft Corporation | Binding a digital license to a portable device or the like in a digital rights management (DRM) system and checking out/checking in the digital license to/from the portable device or the like |
US20020138435A1 (en) * | 2001-03-26 | 2002-09-26 | Williams L. Lloyd | Method and system for content delivery control using a parallel network |
DE10224473A1 (en) * | 2001-06-18 | 2003-12-24 | Hans-Joachim Mueschenborn | Data encryption system has iterative part block encryption and decryption key generation using base decryption and encryption keys |
JP4248208B2 (en) * | 2001-09-27 | 2009-04-02 | パナソニック株式会社 | Encryption device, decryption device, secret key generation device, copyright protection system, and encryption communication device |
US20050172132A1 (en) * | 2004-01-30 | 2005-08-04 | Chen Sherman (. | Secure key authentication and ladder system |
KR101088420B1 (en) * | 2004-02-13 | 2011-12-08 | 아이비아이 스마트 테크놀로지스 인코포레이티드 | Method and apparatus for cryptographically processing data |
US20080209231A1 (en) * | 2004-10-12 | 2008-08-28 | Information And Communications University Research And Industrial Cooperation Group | Contents Encryption Method, System and Method for Providing Contents Through Network Using the Encryption Method |
JP2006222496A (en) * | 2005-02-08 | 2006-08-24 | Matsushita Electric Ind Co Ltd | Digital image receiver and system for receiving digital image |
-
2007
- 2007-03-06 EP EP07772246A patent/EP2119092A4/en not_active Withdrawn
- 2007-03-06 WO PCT/US2007/005803 patent/WO2008108764A2/en active Application Filing
- 2007-03-06 JP JP2009552649A patent/JP2010520703A/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6398245B1 (en) * | 1998-08-13 | 2002-06-04 | International Business Machines Corporation | Key management system for digital content player |
US20050021941A1 (en) * | 2001-09-27 | 2005-01-27 | Motoji Ohmori | Encryption device a decrypting device a secret key generation device a copyright protection system and a cipher communication device |
US20050058291A1 (en) * | 2003-08-25 | 2005-03-17 | Brant Candelore | Apparatus and method for an iterative cryptographic block |
US20060101524A1 (en) * | 2004-11-05 | 2006-05-11 | Cable Television Laboratories, Inc. | Hierarchical encryption key system for securing digital media |
Non-Patent Citations (1)
Title |
---|
See also references of WO2008108764A2 * |
Also Published As
Publication number | Publication date |
---|---|
EP2119092A4 (en) | 2012-02-22 |
WO2008108764A2 (en) | 2008-09-12 |
WO2008108764A3 (en) | 2008-11-27 |
JP2010520703A (en) | 2010-06-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9710617B2 (en) | Method and system for a recursive security protocol for digital copyright control | |
JP5636371B2 (en) | Method and system for code execution control in a general purpose computing device and code execution control in a recursive security protocol | |
WO2013142517A1 (en) | Method and system for process working set isolation | |
US6889209B1 (en) | Method and apparatus for protecting information and privacy | |
US20210294879A1 (en) | Securing executable code integrity using auto-derivative key | |
US7302709B2 (en) | Key-based secure storage | |
US6330670B1 (en) | Digital rights management operating system | |
US8074287B2 (en) | Renewable and individualizable elements of a protected environment | |
JP4884535B2 (en) | Transfer data objects between devices | |
US20090190765A1 (en) | Anchor point-based digital content protection with an escrow anchor point | |
US20060149683A1 (en) | User terminal for receiving license | |
JP2007531127A (en) | Digital license sharing system and sharing method | |
WO2004006075A1 (en) | Open type general-purpose attack-resistant cpu, and application system thereof | |
US20100325431A1 (en) | Feature-Specific Keys for Executable Code | |
TWI461956B (en) | Device and method for digital rights management | |
EP2119092A2 (en) | Method and system for a recursive security protocol for digital copyright control | |
JP2000330783A (en) | Software illegal copy prevention system and recording medium with software illegal copy prevention program recorded thereon | |
JP2015135703A (en) | Method and system for recursive security protocol for digital copyright control | |
KR101604892B1 (en) | Method and devices for fraud prevention of android-based applications | |
Myles et al. | Content protection for games | |
JP2013084294A (en) | Method and system for recursive security protocol for digital copyright control | |
JP2014017871A (en) | Method and system for recursive security protocol for digital copyright control | |
KR20080008328A (en) | Renewable and individualizable elements of a protected computing environment | |
KR20070022257A (en) | Digital license sharing system and method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20090903 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR |
|
DAX | Request for extension of the european patent (deleted) | ||
A4 | Supplementary search report drawn up and despatched |
Effective date: 20120119 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06F 21/00 20060101ALI20120113BHEP Ipc: H04L 9/32 20060101ALI20120113BHEP Ipc: H04N 7/167 20110101ALI20120113BHEP Ipc: H04L 29/06 20060101ALI20120113BHEP Ipc: H04L 9/18 20060101ALI20120113BHEP Ipc: H04L 9/08 20060101AFI20120113BHEP |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: KRIMMENI TECHNOLOGIES, INC. |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: OXFORD, WILLIAM V. |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: RUBICON LABS, INC. |
|
17Q | First examination report despatched |
Effective date: 20160129 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20160409 |