US20140143544A1 - Rights enforcement and usage reporting on a client device - Google Patents
Rights enforcement and usage reporting on a client device Download PDFInfo
- Publication number
- US20140143544A1 US20140143544A1 US13/926,994 US201313926994A US2014143544A1 US 20140143544 A1 US20140143544 A1 US 20140143544A1 US 201313926994 A US201313926994 A US 201313926994A US 2014143544 A1 US2014143544 A1 US 2014143544A1
- Authority
- US
- United States
- Prior art keywords
- client device
- hash
- content
- stored
- integrity
- 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.)
- Abandoned
Links
- 230000015654 memory Effects 0.000 claims description 23
- 238000010200 validation analysis Methods 0.000 claims description 16
- 238000000034 method Methods 0.000 claims description 12
- 238000001514 detection method Methods 0.000 claims 3
- 230000006870 function Effects 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000008092 positive effect Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
Images
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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/109—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by using specially-adapted hardware at the client
-
- 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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
Definitions
- the present invention relates to the field of electronic content management. More specifically, the present invention relates to rights enforcement and usage reporting for content on a client device.
- Electronic content can include a wide variety of audio and/or video presentations, such as music, dialogue, still pictures, movies, and the like.
- a client device can include a wide variety of electronic devices, such as an MP3 player, a personal data assistant (PDA), a cellular phone, and the like.
- Rights enforcement involves defining how content can be used on a client device. For instance, rights information associated with a piece of content may permit rendering the content, but not copying or distributing the content.
- Rights information is often closely tied to usage information. For instance, rights information may define that a piece of content can be played a particular number of times or for a certain duration. In which case, the content's usage may be tracked so that the rights limitation can be enforced.
- a variety of business models can be designed around usage. For instance, with a pay-per-play business model, a user or distributor may pay royalties or license fees based on the number or duration of plays. In which case, the usage information may need to be reported from the client device to a server device.
- the rights and/or usage information needs to be protected in some way. If the information is not protected, a user could, for instance, modify the information to improperly grant himself or herself additional rights or reset the number of plays.
- Protecting rights information usually involves encrypting the rights information. As long as the rights information is encrypted, the information is unreadable. Encryption, however, relies on secret keys, making encryption only as secure the security measures surrounding the code.
- the client device can perform the encryption and decryption itself.
- the client device usually needs an application program interface (API) to manage communications with an external device.
- API application program interface
- a server device may need to establish communications with the client device through an API.
- the API may be able to receive and process a variety of requests from the server device.
- the client device may decrypt the usage information and deliver it to the server through the API in a format that the server device can understandable.
- client devices are intended to be quite simple and inexpensive, lacking the resources to provide an API that can manage content and external communications, which leads to the second commonly used security approach.
- These simple client devices often rely on an external device, such as a server, to provide security of usage reporting.
- externally managed security is ripe for abuse. That is, when the secret, or cryptographic key, is known outside the client device, a persistent user is likely to be able to find it.
- FIG. 1 illustrates one embodiment of a data structure.
- FIG. 2 illustrates one embodiment of a client device.
- FIGS. 3A and 3B illustrate one embodiment of the present invention from the perspective of a client device.
- FIG. 4 illustrates one embodiment of the present invention from the perspective of a server device.
- FIG. 5 illustrates one embodiment of a generic hardware system.
- FIG. 6 illustrates one embodiment of a machine-readable medium to store executable instructions for embodiments of the present invention.
- Embodiments of the present invention can store rights and/or usage information in clear form on a client device while still providing security for the content and integrity for the rights/usage information. Storing the information in clear form can greatly simplify rights enforcement and/or usage reporting because the information does not need to be decrypted before it can be read or used either on the client device or by an external device.
- Security and integrity can be provided on the client device by using a device key that is externally inaccessible from the client device, reducing or eliminating the need to depend on externally known secrets.
- a client device such as an MP3 player or PDA, often includes a hardware key embedded within the device. The hardware key can be used within the device by embodiments of the present invention, but, because the key is usually not accessible through any external data paths, the key can be externally inaccessible and quite secure.
- FIG. 1 illustrates one embodiment of the present invention in the form of a data structure stored on a client device.
- Data structure 100 includes license 110 , external integrity hash 120 , and internal security block 130 .
- License 110 can include rights information 112 , usage information 114 , and any other information associated with a piece of content (not shown) stored on the client device.
- License 110 can be stored in clear form 116 . That is, license 110 need not be encrypted so it can be read using any device that can read the memory of the client device.
- usage reporting can be as simple as reading usage information 114 from the client's memory. For instance, each time a user downloads new content or renews a license, the server can read the usage information.
- External security hash 120 can be a hash of license 110 in combination with external secret 122 .
- a hash is a mathematical compression of a block of data. Virtually any change to the block of data will result in a different hash. So, by comparing two hashes of the block of data, it is possible to determine, to a probabilistic certainty, whether or not the data has been changed between hashes. In other words, a hash can be used to test the integrity of a block data and determine whether or not the data has been tampered with.
- External secret 122 can be a number of bits or bytes of data that are appended, or otherwise combined, with license 110 prior to generating hash 120 . Without knowing secret 122 , it is virtually impossible to recreate license 110 or secret 122 from hash 120 . In which case, hash 120 is often referred as a one-way hash. Any number of hash algorithms can be used to generate hash 120 , including HMAC-SHA1 (Hash Message Authentication Code—Secure Hash Algorithm) or HMAC-MD5 (HMAC—Message Digest 5).
- HMAC-SHA1 Hasash Message Authentication Code—Secure Hash Algorithm
- HMAC-MD5 HMAC—Message Digest 5
- external integrity hash 120 can be stored in clear form 116 so that a device having access to secret 122 can use hash 120 to detect tampering with license 110 .
- license 110 can be stored in clear form 116 , a mildly sophisticated user may find a way to read and modify rights information 112 and/or usage information 114 . However, without secret 122 , the user will not be able to correctly regenerate hash 120 .
- An external device that reads license 110 and knows secret 122 , can compute the hash of the combination and compare it to hash 120 from data structure 100 . If the hashes do not match, the tampering can be detected.
- external secret 122 is known external to the client device. Any of a variety of approaches can be used to try to maintain the security of secret 122 , but, unfortunately, any secret known outside the client device is likely to be vulnerable. A sophisticated and determined user is likely to gain access to secret 122 eventually. But, even if hash 120 is compromised, the illustrated embodiment includes a second layer of security and integrity that does not rely on an externally known secret, namely internal security block 130 .
- Internal security block 130 uses device key 132 to encrypt the contents of the block and store the block in encrypted form 138 .
- Device key 132 is intended to be externally inaccessible from the client device. Any number of cryptographic techniques can be used for the encryption. In one embodiment, dedicated and trusted cryptographic hardware can be used, where the cryptographic hardware itself is also externally inaccessible.
- internal security block 130 includes both content key 136 and internal security hash 134 .
- Internal security hash 134 can be a one-way hash of a combination of license 110 , external integrity hash 120 , and device key 132 . As with external integrity hash 120 , internal security hash 134 can be used to test the integrity of license 110 . However, as long as key 132 is only known on the client device, hash 134 can only be calculated and used on the client device.
- Content key 136 is a cryptographic key that can be used to decrypt the content. That is, the content associated with license 110 can be stored on the client device in encrypted form. The content cannot be used without first decrypting content. key 136 from block 130 .
- the client device can check license 110 to make sure the rights allow the content to be play and/or make sure a usage limit has not been reached. If the rights are satisfied, the client can compute a hash and compare it to internal integrity hash 134 to test for tampering. Assuming no tampering, the client can decrypt content key 136 , play the content using the decryption key, and update usage information 114 . And, of course, after updating usage information 114 , the client can recalculate, re-encrypt, and restore hash 134 , and possibly recalculate and restore hash 120 .
- the client can disable the content, either through some positive action, such as erasing the content, or through some passive action, such as not decrypting content key 136 .
- the client device could also record the tampering event in, for instance, license 110 where it will be externally accessible.
- internal integrity hash 134 will most likely render the content unusable on the client device.
- a user may be able to change usage reporting information 114 for external reporting, but, by doing so, the user will lose access to the associated content.
- FIG. 1 includes a number of implementation-specific details.
- the data structure could be arranged in any number of ways, divided among any number of memory devices, and the like.
- Alternate embodiments may not include all of the illustrated components, may include additional components, and may combine/separate one or more components.
- external integrity hash 120 may not be included at all, may be a hash of just rights information 112 or usage information 114 , or may also be encrypted using the same or a different external secret.
- internal integrity hash 134 may not be encrypted, and may be a hash of just one or more of rights information 112 and usage information 114 .
- external integrity hash 120 may be stored externally, for instance on a server device that also stores secret 122 .
- FIG. 2 illustrates one embodiment of a client device 200 that can use a data structure, such as data structure 100 from FIG. 1 , to manage content.
- Client device 200 could be any of a number of devices, including an MP3 player, a personal data assistant, or a cellular phone.
- Client device 200 includes a register 210 , a memory 220 , an input/output (I/O) port 230 , trusted hardware 240 , and a user interface 260 . Both register 210 and trusted hardware 240 are externally inaccessible from client device 200 . That is, no external I/O path connects to either register 210 or hardware 240 .
- I/O input/output
- Register 210 stores device key 132 from FIG. 1 .
- Memory 220 stores external secret 122 and data structure 100 from FIG. 1 , as well as content 222 .
- I/O port 230 makes memory 220 externally accessible. That is, any number of devices may be able to store and read information from memory 220 .
- User interface 260 may include, for instance, a viewing screen, speaker(s), headphone port, buttons, switches, and the like.
- Trusted hardware 240 includes hash circuit 242 , crypto circuit 244 , tracking circuit 246 , and comparator 248 .
- Trusted hardware 240 could be, for instance, an application specific integrated circuit (ASIC), a programmable gate array, a digital signal processor (DSP), a microprocessor, or any combination thereof that can provide the desired functionality.
- ASIC application specific integrated circuit
- DSP digital signal processor
- Trusted hardware 240 has access to both register 210 and memory 220 .
- Hash circuit 242 can be used to generate hashes 120 and/or 134 in data structure 100 using device key 132 from register 210 and/or external secret 122 from memory 220 .
- Crypto circuit 244 can be used to generated the encrypted form 138 of internal security block 130 using device key 132 .
- Tracking circuit 246 can be used to track usage of content 222 and update usage information 114 .
- Comparator 248 can be used to compare newly generated hashes to hashes 120 and/or 134 to detect tampering.
- Content controller 250 can control user access to content 222 through user interface 260 by, for instance, initiating hash circuit 242 when a play command is received and disabling the content if comparator 248 detects tampering.
- FIG. 2 includes a number of implementation-specific details. Alternate embodiments may not include all of the illustrated components, may include additional components, and may combine/separate one or more components. For instance, other embodiments may store multiple pieces of content and associated rights data on the client device. And, rather than or in addition to an I/O port to download secret 122 , content 222 , and/or various parts of data structure 100 , these data items could be installed using a removable storage medium, such a disk, cartridge, and/or memory stick. In these embodiments, memory 220 could be at least partially located on the removable storage medium.
- FIGS. 3A and 3B illustrate one embodiment of the present invention from the perspective of a client device.
- the client obtains a first integrity hash.
- This first hash could be a hash of rights and/or usage information in combination with an external secret, or key.
- the external key could be received from a server and then used on the client device itself to generate the hash.
- the hash could be generated on an external device using the key and then the hash could be downloaded or installed on the client device.
- the external key may also be downloaded to the client device so that the client device can regenerate the hash as usage information changes.
- the client device obtains a second integrity hash.
- This second hash could also be a hash of rights and/or usage information in combination with a key.
- the key could be the same external key used for the first hash, or it could be a different external key, or it could be the internal device key.
- the client device could receive the key and generate the second hash itself, or the second hash could be generated externally and downloaded or installed on the client, possibly along with the external key.
- the client device can generate the second hash internally.
- the client device encrypts the second integrity hash using the internal secret, the device key in this example.
- the client device stores the rights and/or usage information, and the first integrity hash, in a clear form.
- the client device stores the second integrity hash in an encrypted form at 350 .
- the client also encrypts a content key using the device key at 360 and stores the encrypted content key at 365 .
- the client device In response to a usage request for the content associated with the content key, the client device generates a validation hash of the rights and/or usage information at 370 .
- the validation hash is for comparison with the second hash, so the same set of data used to generate the second hash is used to generate the validation hash.
- the client device uses the device key to decrypt the second hash, and, at 380 , the client device compares the validation hash to the second hash. If the hashes match, no tampering is detected and the content may be accessed. At 385 , however, if tampering is detected, the content is disabled. Disabling the content may include erasing the content from the client's memory, disabling decryption of the content, or the like.
- the client device tracks usage and updates the usage information with any changes in usage. For example, the client device may record the number of times the content has been played, what sections of the content have been played, how long the content or section of the content have been played, and the like. Usage tracking may also include making a record of any tampering.
- the client device may update one or both of the hashes as well at 395 . That is, assuming the hashes include the usage information, the client device will likely need to replace the hashes after any update.
- the first hash can be regenerated and restored.
- the second hash can be regenerated, re-encrypted, and restored.
- FIG. 4 illustrates one embodiment of the present invention from the perspective of a server device.
- the server device reads rights and/or usage information, as well as a first integrity hash, from a client device in clear form.
- the server generates a validation hash using the same set of data used to generate the first integrity hash. That is, if the first integrity hash included both the rights and usage information, then the validation hash does too.
- the server also uses the same external key to generate the validation hash.
- the server compares the validation hash to the first integrity hash to detect tampering with the rights and/or usage information.
- FIGS. 3 and 4 includes a number of implementation-specific details. Alternate embodiments may not include all of the illustrated components, may include additional components, may combine/separate one or more components, and may arrange the components in a different order.
- FIG. 5 illustrates one embodiment of a generic hardware system intended to represent a broad category of computer systems such as personal computers, workstations, and/or embedded systems.
- the hardware system includes processor 510 coupled to high speed bus 505 , which is coupled to input/output (I/O) bus 515 through bus bridge 530 .
- Temporary memory. 520 is coupled to bus 505 .
- Permanent memory 540 is coupled to bus 515 .
- I/O device(s) 550 is also coupled to bus 515 .
- I/O device(s) 550 may include a display device, a keyboard, one or more external network interfaces, etc.
- temporary memory 520 may be on-chip with processor 510 .
- permanent memory 540 may be eliminated and temporary memory 520 may be replaced with an electrically erasable programmable read only memory (EEPROM), wherein software routines are executed in place from the EEPROM.
- EEPROM electrically erasable programmable read only memory
- Some implementations may employ a single bus, to which all of the components are coupled, or one or more additional buses and bus bridges to which various additional components can be coupled.
- a variety of alternate internal networks could be used including, for instance, an internal network based on a high speed system bus with a memory controller hub and an I/O controller hub.
- Additional components may include additional processors, a CD ROM drive, additional memories, and other peripheral components known in the art.
- the present invention could be implemented using one or more hardware systems such as the hardware system of FIG. 5 .
- the systems can be coupled to communicate over an external network, such as a local area network (LAN), an internet protocol (IP) network, etc.
- an external network such as a local area network (LAN), an internet protocol (IP) network, etc.
- the present invention as described above may be implemented as software routines executed by one or more execution units within the computer(s).
- the software routines can be stored on a storage device, such as permanent memory 540 .
- the software routines can be machine executable instructions 610 stored using any machine readable storage medium 620 , such as a diskette, CD-ROM, magnetic tape, digital video or versatile disk (DVD), laser disk, ROM, Flash memory, etc.
- the series of instructions need not be stored locally, and could be received from a remote storage device, such as a server on a network, a CD ROM device, a floppy disk, etc., through, for instance, I/O device(s) 550 of FIG. 5 .
- the instructions may be copied from the storage device into temporary memory 520 and then accessed and executed by processor 510 .
- these software routines are written in the C programming language. It is to be appreciated, however, that these routines may be implemented in any of a wide variety of programming languages.
- the present invention as described above may be implemented in discrete hardware or firmware.
- one or more application specific integrated circuits ASICs
- ASICs application specific integrated circuits
- one or more functions of the present invention could be implemented in one or more ASICs on additional circuit boards and the circuit boards could be inserted into the computer(s) described above.
- FPGAs field programmable gate arrays
- SPGA static programmable gate arrays
- a combination of hardware and software could be used to implement one or more functions of the present invention.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
An integrity hash is obtained of rights information stored at a client device. The rights information is associated with content stored at the client device. The integrity hash is encrypted using a client device key to generate an encrypted hash. The client device key is externally inaccessible from the client device. The encrypted hash is stored on the client device.
Description
- The present invention relates to the field of electronic content management. More specifically, the present invention relates to rights enforcement and usage reporting for content on a client device.
- Electronic content can include a wide variety of audio and/or video presentations, such as music, dialogue, still pictures, movies, and the like. A client device can include a wide variety of electronic devices, such as an MP3 player, a personal data assistant (PDA), a cellular phone, and the like. Rights enforcement involves defining how content can be used on a client device. For instance, rights information associated with a piece of content may permit rendering the content, but not copying or distributing the content.
- Rights information is often closely tied to usage information. For instance, rights information may define that a piece of content can be played a particular number of times or for a certain duration. In which case, the content's usage may be tracked so that the rights limitation can be enforced. Similarly, a variety of business models can be designed around usage. For instance, with a pay-per-play business model, a user or distributor may pay royalties or license fees based on the number or duration of plays. In which case, the usage information may need to be reported from the client device to a server device.
- In order to enforce content rights, the rights and/or usage information needs to be protected in some way. If the information is not protected, a user could, for instance, modify the information to improperly grant himself or herself additional rights or reset the number of plays. Protecting rights information usually involves encrypting the rights information. As long as the rights information is encrypted, the information is unreadable. Encryption, however, relies on secret keys, making encryption only as secure the security measures surrounding the code.
- Security of usage reporting is often handled in one of two ways. In one approach, the client device can perform the encryption and decryption itself. In which case, the client device usually needs an application program interface (API) to manage communications with an external device. For example, if a client device stores the rights and/or usage information in encrypted form, a server device may need to establish communications with the client device through an API. The API may be able to receive and process a variety of requests from the server device. In response to a request to report how many times a particular piece of content has been played, the client device may decrypt the usage information and deliver it to the server through the API in a format that the server device can understandable.
- Many client devices, however, are intended to be quite simple and inexpensive, lacking the resources to provide an API that can manage content and external communications, which leads to the second commonly used security approach. These simple client devices often rely on an external device, such as a server, to provide security of usage reporting. Unfortunately, externally managed security is ripe for abuse. That is, when the secret, or cryptographic key, is known outside the client device, a persistent user is likely to be able to find it.
- Examples of the present invention are illustrated in the accompanying drawings. The accompanying drawings, however, do not limit the scope of the present invention. Similar references in the drawings indicate similar elements.
-
FIG. 1 illustrates one embodiment of a data structure. -
FIG. 2 illustrates one embodiment of a client device. -
FIGS. 3A and 3B illustrate one embodiment of the present invention from the perspective of a client device. -
FIG. 4 illustrates one embodiment of the present invention from the perspective of a server device. -
FIG. 5 illustrates one embodiment of a generic hardware system. -
FIG. 6 illustrates one embodiment of a machine-readable medium to store executable instructions for embodiments of the present invention. - In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, those skilled in the art will understand that the present invention may be practiced without these specific details, that the present invention is not limited to the depicted embodiments, and that the present invention may be practiced in a variety of alternative embodiments. In other instances, well known methods, procedures, components, and circuits have not been described in detail.
- Parts of the description will be presented using terminology commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. Also, parts of the description will be presented in terms of operations performed through the execution of programming instructions. As well understood by those skilled in the art, these operations often take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, and otherwise manipulated through, for instance, electrical components.
- Various operations will be described as multiple discrete steps performed in turn in a manner that is helpful for understanding the present invention. However, the order of description should not be construed as to imply that these operations are necessarily performed in the order they are presented, nor even order dependent. Lastly, repeated usage of the phrase “in one embodiment” does not necessarily refer to the same embodiment, although it may.
- Embodiments of the present invention can store rights and/or usage information in clear form on a client device while still providing security for the content and integrity for the rights/usage information. Storing the information in clear form can greatly simplify rights enforcement and/or usage reporting because the information does not need to be decrypted before it can be read or used either on the client device or by an external device. Security and integrity can be provided on the client device by using a device key that is externally inaccessible from the client device, reducing or eliminating the need to depend on externally known secrets. For example, a client device, such as an MP3 player or PDA, often includes a hardware key embedded within the device. The hardware key can be used within the device by embodiments of the present invention, but, because the key is usually not accessible through any external data paths, the key can be externally inaccessible and quite secure.
-
FIG. 1 illustrates one embodiment of the present invention in the form of a data structure stored on a client device.Data structure 100 includeslicense 110, external integrity hash 120, andinternal security block 130.License 110 can include rights information 112, usage information 114, and any other information associated with a piece of content (not shown) stored on the client device.License 110 can be stored inclear form 116. That is,license 110 need not be encrypted so it can be read using any device that can read the memory of the client device. In other words, usage reporting can be as simple as reading usage information 114 from the client's memory. For instance, each time a user downloads new content or renews a license, the server can read the usage information. - External security hash 120 can be a hash of
license 110 in combination withexternal secret 122. A hash is a mathematical compression of a block of data. Virtually any change to the block of data will result in a different hash. So, by comparing two hashes of the block of data, it is possible to determine, to a probabilistic certainty, whether or not the data has been changed between hashes. In other words, a hash can be used to test the integrity of a block data and determine whether or not the data has been tampered with. - External secret 122 can be a number of bits or bytes of data that are appended, or otherwise combined, with
license 110 prior to generating hash 120. Without knowingsecret 122, it is virtually impossible to recreatelicense 110 or secret 122 from hash 120. In which case, hash 120 is often referred as a one-way hash. Any number of hash algorithms can be used to generate hash 120, including HMAC-SHA1 (Hash Message Authentication Code—Secure Hash Algorithm) or HMAC-MD5 (HMAC—Message Digest 5). - Like
license 110, external integrity hash 120 can be stored inclear form 116 so that a device having access tosecret 122 can use hash 120 to detect tampering withlicense 110. For example, sincelicense 110 can be stored inclear form 116, a mildly sophisticated user may find a way to read and modify rights information 112 and/or usage information 114. However, withoutsecret 122, the user will not be able to correctly regenerate hash 120. An external device that readslicense 110, and knows secret 122, can compute the hash of the combination and compare it to hash 120 fromdata structure 100. If the hashes do not match, the tampering can be detected. - In order to use hash 120 to test the integrity of
license 110,external secret 122 is known external to the client device. Any of a variety of approaches can be used to try to maintain the security ofsecret 122, but, unfortunately, any secret known outside the client device is likely to be vulnerable. A sophisticated and determined user is likely to gain access tosecret 122 eventually. But, even if hash 120 is compromised, the illustrated embodiment includes a second layer of security and integrity that does not rely on an externally known secret, namelyinternal security block 130. -
Internal security block 130 usesdevice key 132 to encrypt the contents of the block and store the block inencrypted form 138.Device key 132 is intended to be externally inaccessible from the client device. Any number of cryptographic techniques can be used for the encryption. In one embodiment, dedicated and trusted cryptographic hardware can be used, where the cryptographic hardware itself is also externally inaccessible. - In the illustrated embodiment,
internal security block 130 includes bothcontent key 136 and internal security hash 134. Internal security hash 134 can be a one-way hash of a combination oflicense 110, external integrity hash 120, anddevice key 132. As with external integrity hash 120, internal security hash 134 can be used to test the integrity oflicense 110. However, as long askey 132 is only known on the client device, hash 134 can only be calculated and used on the client device. -
Content key 136 is a cryptographic key that can be used to decrypt the content. That is, the content associated withlicense 110 can be stored on the client device in encrypted form. The content cannot be used without first decrypting content. key 136 fromblock 130. For example, before playing the content, the client device can checklicense 110 to make sure the rights allow the content to be play and/or make sure a usage limit has not been reached. If the rights are satisfied, the client can compute a hash and compare it to internal integrity hash 134 to test for tampering. Assuming no tampering, the client can decryptcontent key 136, play the content using the decryption key, and update usage information 114. And, of course, after updating usage information 114, the client can recalculate, re-encrypt, and restore hash 134, and possibly recalculate and restore hash 120. - If, on the other hand, tampering is detected, the client can disable the content, either through some positive action, such as erasing the content, or through some passive action, such as not decrypting
content key 136. The client device could also record the tampering event in, for instance,license 110 where it will be externally accessible. - So, even if a user manages to tamper with
license 110, and manages to find external secret 122 to correspondingly update external integrity hash 120, internal integrity hash 134 will most likely render the content unusable on the client device. In other words, a user may be able to change usage reporting information 114 for external reporting, but, by doing so, the user will lose access to the associated content. - The embodiment of
FIG. 1 includes a number of implementation-specific details. In alternate embodiments, the data structure could be arranged in any number of ways, divided among any number of memory devices, and the like. Alternate embodiments may not include all of the illustrated components, may include additional components, and may combine/separate one or more components. For instance, external integrity hash 120 may not be included at all, may be a hash of just rights information 112 or usage information 114, or may also be encrypted using the same or a different external secret. Similarly, internal integrity hash 134 may not be encrypted, and may be a hash of just one or more of rights information 112 and usage information 114. In yet another embodiment, external integrity hash 120 may be stored externally, for instance on a server device that also stores secret 122. -
FIG. 2 illustrates one embodiment of aclient device 200 that can use a data structure, such asdata structure 100 fromFIG. 1 , to manage content.Client device 200 could be any of a number of devices, including an MP3 player, a personal data assistant, or a cellular phone.Client device 200 includes aregister 210, amemory 220, an input/output (I/O)port 230, trusted hardware 240, and a user interface 260. Both register 210 and trusted hardware 240 are externally inaccessible fromclient device 200. That is, no external I/O path connects to either register 210 or hardware 240. -
Register 210 stores device key 132 fromFIG. 1 .Memory 220 storesexternal secret 122 anddata structure 100 fromFIG. 1 , as well ascontent 222. I/O port 230 makesmemory 220 externally accessible. That is, any number of devices may be able to store and read information frommemory 220. User interface 260 may include, for instance, a viewing screen, speaker(s), headphone port, buttons, switches, and the like. - Trusted hardware 240 includes
hash circuit 242,crypto circuit 244, trackingcircuit 246, andcomparator 248. Trusted hardware 240 could be, for instance, an application specific integrated circuit (ASIC), a programmable gate array, a digital signal processor (DSP), a microprocessor, or any combination thereof that can provide the desired functionality. - Trusted hardware 240 has access to both register 210 and
memory 220.Hash circuit 242 can be used to generate hashes 120 and/or 134 indata structure 100 using device key 132 fromregister 210 and/or external secret 122 frommemory 220.Crypto circuit 244 can be used to generated theencrypted form 138 ofinternal security block 130 usingdevice key 132.Tracking circuit 246 can be used to track usage ofcontent 222 and update usage information 114.Comparator 248 can be used to compare newly generated hashes to hashes 120 and/or 134 to detect tampering. -
Content controller 250 can control user access tocontent 222 through user interface 260 by, for instance, initiatinghash circuit 242 when a play command is received and disabling the content ifcomparator 248 detects tampering. - The embodiment of
FIG. 2 includes a number of implementation-specific details. Alternate embodiments may not include all of the illustrated components, may include additional components, and may combine/separate one or more components. For instance, other embodiments may store multiple pieces of content and associated rights data on the client device. And, rather than or in addition to an I/O port to download secret 122,content 222, and/or various parts ofdata structure 100, these data items could be installed using a removable storage medium, such a disk, cartridge, and/or memory stick. In these embodiments,memory 220 could be at least partially located on the removable storage medium. -
FIGS. 3A and 3B illustrate one embodiment of the present invention from the perspective of a client device. At 310, the client obtains a first integrity hash. This first hash could be a hash of rights and/or usage information in combination with an external secret, or key. The external key could be received from a server and then used on the client device itself to generate the hash. Alternatively, the hash could be generated on an external device using the key and then the hash could be downloaded or installed on the client device. In the later situation, the external key may also be downloaded to the client device so that the client device can regenerate the hash as usage information changes. - At 320, the client device obtains a second integrity hash. This second hash could also be a hash of rights and/or usage information in combination with a key. The key could be the same external key used for the first hash, or it could be a different external key, or it could be the internal device key. In the case of an external key, the client device could receive the key and generate the second hash itself, or the second hash could be generated externally and downloaded or installed on the client, possibly along with the external key. In the case of the internal device key, the client device can generate the second hash internally.
- At 330, the client device encrypts the second integrity hash using the internal secret, the device key in this example. At 340, the client device stores the rights and/or usage information, and the first integrity hash, in a clear form. The client device stores the second integrity hash in an encrypted form at 350. In addition to storing the encrypted integrity hash, the client also encrypts a content key using the device key at 360 and stores the encrypted content key at 365.
- In response to a usage request for the content associated with the content key, the client device generates a validation hash of the rights and/or usage information at 370. The validation hash is for comparison with the second hash, so the same set of data used to generate the second hash is used to generate the validation hash.
- At 375, the client device uses the device key to decrypt the second hash, and, at 380, the client device compares the validation hash to the second hash. If the hashes match, no tampering is detected and the content may be accessed. At 385, however, if tampering is detected, the content is disabled. Disabling the content may include erasing the content from the client's memory, disabling decryption of the content, or the like.
- At 390, the client device tracks usage and updates the usage information with any changes in usage. For example, the client device may record the number of times the content has been played, what sections of the content have been played, how long the content or section of the content have been played, and the like. Usage tracking may also include making a record of any tampering.
- Assuming the usage information is updated, the client device may update one or both of the hashes as well at 395. That is, assuming the hashes include the usage information, the client device will likely need to replace the hashes after any update. The first hash can be regenerated and restored. The second hash can be regenerated, re-encrypted, and restored.
-
FIG. 4 illustrates one embodiment of the present invention from the perspective of a server device. At 410, the server device reads rights and/or usage information, as well as a first integrity hash, from a client device in clear form. At 420, the server generates a validation hash using the same set of data used to generate the first integrity hash. That is, if the first integrity hash included both the rights and usage information, then the validation hash does too. The server also uses the same external key to generate the validation hash. At 430, the server compares the validation hash to the first integrity hash to detect tampering with the rights and/or usage information. -
FIGS. 3 and 4 includes a number of implementation-specific details. Alternate embodiments may not include all of the illustrated components, may include additional components, may combine/separate one or more components, and may arrange the components in a different order. -
FIG. 5 illustrates one embodiment of a generic hardware system intended to represent a broad category of computer systems such as personal computers, workstations, and/or embedded systems. In the illustrated embodiment, the hardware system includesprocessor 510 coupled to high speed bus 505, which is coupled to input/output (I/O) bus 515 throughbus bridge 530. Temporary memory. 520 is coupled to bus 505.Permanent memory 540 is coupled to bus 515. I/O device(s) 550 is also coupled to bus 515. I/O device(s) 550 may include a display device, a keyboard, one or more external network interfaces, etc. - Certain embodiments may include additional components, may not require all of the above components, or may combine one or more components. For instance,
temporary memory 520 may be on-chip withprocessor 510. Alternately,permanent memory 540 may be eliminated andtemporary memory 520 may be replaced with an electrically erasable programmable read only memory (EEPROM), wherein software routines are executed in place from the EEPROM. Some implementations may employ a single bus, to which all of the components are coupled, or one or more additional buses and bus bridges to which various additional components can be coupled. Similarly, a variety of alternate internal networks could be used including, for instance, an internal network based on a high speed system bus with a memory controller hub and an I/O controller hub. Additional components may include additional processors, a CD ROM drive, additional memories, and other peripheral components known in the art. - In one embodiment, the present invention, as described above, could be implemented using one or more hardware systems such as the hardware system of
FIG. 5 . Where more than one computer is used, the systems can be coupled to communicate over an external network, such as a local area network (LAN), an internet protocol (IP) network, etc. In one embodiment, the present invention as described above may be implemented as software routines executed by one or more execution units within the computer(s). For a given computer, the software routines can be stored on a storage device, such aspermanent memory 540. - Alternately, as shown in
FIG. 6 , the software routines can be machineexecutable instructions 610 stored using any machinereadable storage medium 620, such as a diskette, CD-ROM, magnetic tape, digital video or versatile disk (DVD), laser disk, ROM, Flash memory, etc. The series of instructions need not be stored locally, and could be received from a remote storage device, such as a server on a network, a CD ROM device, a floppy disk, etc., through, for instance, I/O device(s) 550 ofFIG. 5 . - From whatever source, the instructions may be copied from the storage device into
temporary memory 520 and then accessed and executed byprocessor 510. In one implementation, these software routines are written in the C programming language. It is to be appreciated, however, that these routines may be implemented in any of a wide variety of programming languages. - In alternate embodiments, the present invention as described above may be implemented in discrete hardware or firmware. For example, one or more application specific integrated circuits (ASICs) could be programmed with one or more of the above described functions of the present invention. In another example, one or more functions of the present invention could be implemented in one or more ASICs on additional circuit boards and the circuit boards could be inserted into the computer(s) described above. In another example, field programmable gate arrays (FPGAs) or static programmable gate arrays (SPGA) could be used to implement one or more functions of the present invention. In yet another example, a combination of hardware and software could be used to implement one or more functions of the present invention.
- Thus, rights enforcement and usage reporting for content on a client device is described. Whereas many alterations and modifications of the present invention will be comprehended by a person skilled in the art after having read the foregoing description, it is to be understood that the particular embodiments shown and described by way of illustration are in no way intended to be considered limiting. Therefore, references to details of particular embodiments are not intended to limit the scope of the claims.
Claims (12)
1-33. (canceled)
34. A client device comprising:
hash circuitry to generate a validation hash from at least stored clear rights information associated with content stored on a client device;
encryption circuitry to decrypt an encrypted hash to recover an integrity hash using a client device key that is externally inaccessible from the client device, said integrity hash having been previously generated from at least the stored clear form rights information associated with the content; and
a comparator to compare the validation hash to the integrity hash to detect tampering with the rights information.
35-42. (canceled)
43. The client device of claim 34 further comprising:
a content controller to disable the content on the client device if tampering is detected.
44. The client device of claim 43 wherein the content controller only permits usage of content stored in memory of the client device if the content is not disabled on the client device.
45-61. (canceled)
62. One or more non-transitory computer readable medium having a plurality of instructions stored thereon which, when executed by one or more processors, cause the one or more processors to perform a method, the method comprising:
generating a validation hash from at least stored clear form rights information associated with content stored on a client device;
decrypting an encrypted hash to recover an integrity hash using a client device key that is externally inaccessible from the client device, said integrity hash having been previously generated from at least the stored clear form rights information associated with the content; and
comparing the validation hash to the integrity hash to detect tampering with the clear form rights information.
63. The one or more non-transitory computer readable medium of claim 62 , wherein the method further comprises disabling the content on the client device if tampering is detected.
64. The one or more non-transitory computer readable medium of claim 62 , wherein the method further comprises
receiving a usage request, by the client device, for the content stored at the client device, said usage request to initiate generation of the validation hash and comparison to the integrity hash; and
permitting usage only if the content is not disabled on the client device.
65. A tampering detection system for electronic content, comprising:
one or more processors; and
one or more non-transitory computer readable medium having a plurality of instructions stored thereon, which, when executed by the one or more processors, cause the system to perform a method, the method comprising:
generating a validation hash from at least stored clear form rights information associated with content stored on a client device;
decrypting an encrypted hash to recover an integrity hash using a client device key that is externally inaccessible from the client device, said integrity hash having been previously generated from at least the stored clear form rights information associated with the content; and
comparing the validation hash to the integrity hash to detect tampering with the clear form rights information.
66. The tampering detection system of claim 65 , wherein the method further comprises disabling the content on the client device if tampering is detected.
67. The tampering detection system of claim 65 , wherein the method further comprises
receiving a usage request, by the client device, for the content stored at the client device, said usage request to initiate generation of the validation hash and comparison to the integrity hash; and
permitting usage only if the content is not disabled on the client device.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/926,994 US20140143544A1 (en) | 2003-06-30 | 2013-06-25 | Rights enforcement and usage reporting on a client device |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US48401803P | 2003-06-30 | 2003-06-30 | |
US10/719,674 US7949877B2 (en) | 2003-06-30 | 2003-11-21 | Rights enforcement and usage reporting on a client device |
US13/092,848 US8473745B2 (en) | 2003-06-30 | 2011-04-22 | Rights enforcement and usage reporting on a client device |
US13/926,994 US20140143544A1 (en) | 2003-06-30 | 2013-06-25 | Rights enforcement and usage reporting on a client device |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/092,848 Continuation US8473745B2 (en) | 2003-06-30 | 2011-04-22 | Rights enforcement and usage reporting on a client device |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140143544A1 true US20140143544A1 (en) | 2014-05-22 |
Family
ID=34083302
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/719,674 Expired - Fee Related US7949877B2 (en) | 2003-06-30 | 2003-11-21 | Rights enforcement and usage reporting on a client device |
US13/092,848 Expired - Fee Related US8473745B2 (en) | 2003-06-30 | 2011-04-22 | Rights enforcement and usage reporting on a client device |
US13/926,994 Abandoned US20140143544A1 (en) | 2003-06-30 | 2013-06-25 | Rights enforcement and usage reporting on a client device |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/719,674 Expired - Fee Related US7949877B2 (en) | 2003-06-30 | 2003-11-21 | Rights enforcement and usage reporting on a client device |
US13/092,848 Expired - Fee Related US8473745B2 (en) | 2003-06-30 | 2011-04-22 | Rights enforcement and usage reporting on a client device |
Country Status (1)
Country | Link |
---|---|
US (3) | US7949877B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109074295A (en) * | 2016-07-29 | 2018-12-21 | 惠普发展公司,有限责任合伙企业 | Data with authenticity are restored |
Families Citing this family (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1486850A2 (en) * | 2003-06-06 | 2004-12-15 | Sony Ericsson Mobile Communications AB | Allowing conversion of one digital rights management scheme to another |
US7647507B1 (en) * | 2003-07-08 | 2010-01-12 | Marvell International Ltd. | Secure digital content distribution system and secure hard drive |
KR100493904B1 (en) * | 2003-09-18 | 2005-06-10 | 삼성전자주식회사 | Method for DRM license supporting plural devices |
US7281274B2 (en) * | 2003-10-16 | 2007-10-09 | Lmp Media Llc | Electronic media distribution system |
KR101100391B1 (en) * | 2004-06-01 | 2012-01-02 | 삼성전자주식회사 | Method for playbacking content using portable storage by digital rights management, and portable storage for the same |
KR100698175B1 (en) * | 2004-09-02 | 2007-03-22 | 엘지전자 주식회사 | Method for protecting copy of multimedia data between terminals |
KR100608605B1 (en) * | 2004-09-15 | 2006-08-03 | 삼성전자주식회사 | Method and apparatus for digital rights management |
US8504849B2 (en) * | 2004-12-21 | 2013-08-06 | Sandisk Technologies Inc. | Method for versatile content control |
US8051052B2 (en) * | 2004-12-21 | 2011-11-01 | Sandisk Technologies Inc. | Method for creating control structure for versatile content control |
US8601283B2 (en) * | 2004-12-21 | 2013-12-03 | Sandisk Technologies Inc. | Method for versatile content control with partitioning |
US20070168292A1 (en) * | 2004-12-21 | 2007-07-19 | Fabrice Jogand-Coulomb | Memory system with versatile content control |
US8161524B2 (en) * | 2005-01-13 | 2012-04-17 | Samsung Electronics Co., Ltd. | Method and portable storage device for allocating secure area in insecure area |
US8181266B2 (en) * | 2005-01-13 | 2012-05-15 | Samsung Electronics Co., Ltd. | Method for moving a rights object between devices and a method and device for using a content object based on the moving method and device |
CA2592889C (en) * | 2005-01-13 | 2013-05-07 | Samsung Electronics Co., Ltd. | Device and method for digital rights management |
US7748031B2 (en) * | 2005-07-08 | 2010-06-29 | Sandisk Corporation | Mass storage device with automated credentials loading |
KR101346734B1 (en) * | 2006-05-12 | 2014-01-03 | 삼성전자주식회사 | Multi certificate revocation list support method and apparatus for digital rights management |
US20100138652A1 (en) * | 2006-07-07 | 2010-06-03 | Rotem Sela | Content control method using certificate revocation lists |
US8266711B2 (en) * | 2006-07-07 | 2012-09-11 | Sandisk Technologies Inc. | Method for controlling information supplied from memory device |
US8613103B2 (en) * | 2006-07-07 | 2013-12-17 | Sandisk Technologies Inc. | Content control method using versatile control structure |
US8245031B2 (en) * | 2006-07-07 | 2012-08-14 | Sandisk Technologies Inc. | Content control method using certificate revocation lists |
US8140843B2 (en) * | 2006-07-07 | 2012-03-20 | Sandisk Technologies Inc. | Content control method using certificate chains |
US8639939B2 (en) * | 2006-07-07 | 2014-01-28 | Sandisk Technologies Inc. | Control method using identity objects |
US9104618B2 (en) * | 2008-12-18 | 2015-08-11 | Sandisk Technologies Inc. | Managing access to an address range in a storage device |
KR20100108970A (en) * | 2009-03-31 | 2010-10-08 | 삼성전자주식회사 | Method and apparatus for protecting of drm contents |
US20100312810A1 (en) * | 2009-06-09 | 2010-12-09 | Christopher Horton | Secure identification of music files |
JP5476086B2 (en) * | 2009-10-16 | 2014-04-23 | フェリカネットワークス株式会社 | IC chip, information processing apparatus, and program |
US9299094B2 (en) * | 2010-05-20 | 2016-03-29 | Red Hat Inc. | State-based compliance verification in a disconnected system |
US9154305B2 (en) | 2010-05-20 | 2015-10-06 | Red Hat, Inc. | State-based compliance verification in a connected system |
US20120095877A1 (en) * | 2010-10-19 | 2012-04-19 | Apple, Inc. | Application usage policy enforcement |
US20120137137A1 (en) * | 2010-11-30 | 2012-05-31 | Brickell Ernest F | Method and apparatus for key provisioning of hardware devices |
CN107612685A (en) | 2011-12-29 | 2018-01-19 | 英特尔公司 | Use the secure key storage of physically unclonable function |
US8938792B2 (en) * | 2012-12-28 | 2015-01-20 | Intel Corporation | Device authentication using a physically unclonable functions based key generation system |
US9967749B2 (en) | 2013-09-26 | 2018-05-08 | Dell Products L.P. | Secure near field communication server information handling system support |
US9125050B2 (en) * | 2013-09-26 | 2015-09-01 | Dell Products L.P. | Secure near field communication server information handling system lock |
US10831867B2 (en) * | 2015-05-11 | 2020-11-10 | Honeywell International Inc. | Mechanism and approach to lock a license to a given localization |
US10528707B2 (en) | 2015-06-15 | 2020-01-07 | Samsung Electronics Co., Ltd. | Enabling content protection over broadcast channels |
DE102016118724A1 (en) | 2016-10-04 | 2018-04-05 | Prostep Ag | Method for electronic documentation of license information |
CN111699488B (en) * | 2018-02-13 | 2024-07-19 | 索尼公司 | Information processing device, information processing method, program, electronic device, and information processing system |
WO2023111775A1 (en) * | 2021-12-16 | 2023-06-22 | 3M Innovative Properties Company | System and computer-implemented method for providing responder information |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020152393A1 (en) * | 2001-01-09 | 2002-10-17 | Johannes Thoma | Secure extensible computing environment |
US20030046115A1 (en) * | 2001-08-29 | 2003-03-06 | International Business Machines Corporation | Insurance method, insurance system, transaction monitoring method, transaction monitoring system, and program |
US20030159037A1 (en) * | 2001-01-16 | 2003-08-21 | Ryuta Taki | Apparatus and method for recording/reproducing information |
US6728378B2 (en) * | 2000-10-13 | 2004-04-27 | Eversystems Information Comircio Representagco, Importageo E Exportagco Ltda. | Secret key messaging |
US7062500B1 (en) * | 1997-02-25 | 2006-06-13 | Intertrust Technologies Corp. | Techniques for defining, using and manipulating rights management data structures |
US7080043B2 (en) * | 2002-03-26 | 2006-07-18 | Microsoft Corporation | Content revocation and license modification in a digital rights management (DRM) system on a computing device |
US7133845B1 (en) * | 1995-02-13 | 2006-11-07 | Intertrust Technologies Corp. | System and methods for secure transaction management and electronic rights protection |
US20070079381A1 (en) * | 2003-10-31 | 2007-04-05 | Frank Hartung | Method and devices for the control of the usage of content |
US7430670B1 (en) * | 1999-07-29 | 2008-09-30 | Intertrust Technologies Corp. | Software self-defense systems and methods |
US7966372B1 (en) * | 1999-07-28 | 2011-06-21 | Rpost International Limited | System and method for verifying delivery and integrity of electronic messages |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5638443A (en) * | 1994-11-23 | 1997-06-10 | Xerox Corporation | System for controlling the distribution and use of composite digital works |
US5943422A (en) * | 1996-08-12 | 1999-08-24 | Intertrust Technologies Corp. | Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels |
US6658568B1 (en) * | 1995-02-13 | 2003-12-02 | Intertrust Technologies Corporation | Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management |
US6079018A (en) * | 1997-10-08 | 2000-06-20 | Agorics, Inc. | System and method for generating unique secure values for digitally signing documents |
US6112181A (en) * | 1997-11-06 | 2000-08-29 | Intertrust Technologies Corporation | Systems and methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information |
US6128740A (en) * | 1997-12-08 | 2000-10-03 | Entrust Technologies Limited | Computer security system and method with on demand publishing of certificate revocation lists |
US6959384B1 (en) * | 1999-12-14 | 2005-10-25 | Intertrust Technologies Corporation | Systems and methods for authenticating and protecting the integrity of data streams and other data |
JP2001175606A (en) * | 1999-12-20 | 2001-06-29 | Sony Corp | Data processor, and data processing equipment and its method |
US6789188B1 (en) * | 2000-02-07 | 2004-09-07 | Koninklijke Philips Electronics N.V. | Methods and apparatus for secure content distribution |
US7085928B1 (en) * | 2000-03-31 | 2006-08-01 | Cigital | System and method for defending against malicious software |
US6754642B2 (en) * | 2001-05-31 | 2004-06-22 | Contentguard Holdings, Inc. | Method and apparatus for dynamically assigning usage rights to digital works |
US7882555B2 (en) * | 2001-03-16 | 2011-02-01 | Kavado, Inc. | Application layer security method and system |
-
2003
- 2003-11-21 US US10/719,674 patent/US7949877B2/en not_active Expired - Fee Related
-
2011
- 2011-04-22 US US13/092,848 patent/US8473745B2/en not_active Expired - Fee Related
-
2013
- 2013-06-25 US US13/926,994 patent/US20140143544A1/en not_active Abandoned
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7133845B1 (en) * | 1995-02-13 | 2006-11-07 | Intertrust Technologies Corp. | System and methods for secure transaction management and electronic rights protection |
US7062500B1 (en) * | 1997-02-25 | 2006-06-13 | Intertrust Technologies Corp. | Techniques for defining, using and manipulating rights management data structures |
US7966372B1 (en) * | 1999-07-28 | 2011-06-21 | Rpost International Limited | System and method for verifying delivery and integrity of electronic messages |
US7430670B1 (en) * | 1999-07-29 | 2008-09-30 | Intertrust Technologies Corp. | Software self-defense systems and methods |
US6728378B2 (en) * | 2000-10-13 | 2004-04-27 | Eversystems Information Comircio Representagco, Importageo E Exportagco Ltda. | Secret key messaging |
US20020152393A1 (en) * | 2001-01-09 | 2002-10-17 | Johannes Thoma | Secure extensible computing environment |
US20030159037A1 (en) * | 2001-01-16 | 2003-08-21 | Ryuta Taki | Apparatus and method for recording/reproducing information |
US20030046115A1 (en) * | 2001-08-29 | 2003-03-06 | International Business Machines Corporation | Insurance method, insurance system, transaction monitoring method, transaction monitoring system, and program |
US7080043B2 (en) * | 2002-03-26 | 2006-07-18 | Microsoft Corporation | Content revocation and license modification in a digital rights management (DRM) system on a computing device |
US20070079381A1 (en) * | 2003-10-31 | 2007-04-05 | Frank Hartung | Method and devices for the control of the usage of content |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109074295A (en) * | 2016-07-29 | 2018-12-21 | 惠普发展公司,有限责任合伙企业 | Data with authenticity are restored |
Also Published As
Publication number | Publication date |
---|---|
US20050022025A1 (en) | 2005-01-27 |
US8473745B2 (en) | 2013-06-25 |
US20110197078A1 (en) | 2011-08-11 |
US7949877B2 (en) | 2011-05-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8473745B2 (en) | Rights enforcement and usage reporting on a client device | |
US9009497B1 (en) | Secure methods for generating content and operating a drive based on identification of a system on chip | |
US9342701B1 (en) | Digital rights management system and methods for provisioning content to an intelligent storage | |
JP4884535B2 (en) | Transfer data objects between devices | |
KR100824469B1 (en) | System for identification and revocation of audiovisual titles and replicators | |
US7302709B2 (en) | Key-based secure storage | |
US9363481B2 (en) | Protected media pipeline | |
US6330670B1 (en) | Digital rights management operating system | |
US20020152393A1 (en) | Secure extensible computing environment | |
JP5097130B2 (en) | Information terminal, security device, data protection method, and data protection program | |
US8769675B2 (en) | Clock roll forward detection | |
KR20150011802A (en) | Method and system for process working set isolation | |
US20080289038A1 (en) | Method and apparatus for checking integrity of firmware | |
US20060155651A1 (en) | Device and method for digital rights management | |
US20050060549A1 (en) | Controlling access to content based on certificates and access predicates | |
US8656190B2 (en) | One time settable tamper resistant software repository | |
US6920563B2 (en) | System and method to securely store information in a recoverable manner on an untrusted system | |
JP2006524860A (en) | How to store revocation lists | |
JP6146476B2 (en) | Information processing apparatus and information processing method | |
US20070239617A1 (en) | Method and apparatus for temporarily accessing content using temporary license | |
US20020152396A1 (en) | Method for secure restoration of a database stroring non-secure content | |
JP4673150B2 (en) | Digital content distribution system and token device | |
US20090119744A1 (en) | Device component roll back protection scheme | |
JP2005128960A (en) | Apparatus and method for reproducing content | |
JP2009284231A (en) | Key generating apparatus, key generating method, key generating program, and electronic apparatus |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |