HK1186262A - Digital rights management system and methods for provisioning content to an intelligent storage - Google Patents

Description

Digital rights management system and method for providing content to smart storage

Cross Reference to Related Applications

This patent application claims priority FROM U.S. provisional patent application entitled "DIGITALRIGHTS MANAGEMENT SYSTEM, DEVICES, AND METHODS FOR patent CONTENT", filed on day 10/4/2012, and having application numbers 61/622, 312 (accession number T5453. p), and filed on _______, entitled "DIGITALRIGHTS MANAGEMENT SYSTEM AND DEVICES FOR binding patent TO AN INTELLIGENT rage DEVICE", U.S. patent application number __/_______ (accession number T453), and U.S. patent application filed on _______, entitled "DIGITAL RIGHTS MANAGEMENT SYSTEM AND METHODS FOR access control FROM AN INTELLIGENT STORAGE, and application number __/_______ (accession number T5919), the entire CONTENTs of which are incorporated herein by reference.

Background

Many different digital rights management ("DRM") systems have been proposed and implemented on various platforms. Generally, DRM refers to a technique for controlling the use of digital contents and devices. For example, DRM is often used to prevent unauthorized copying of digital content.

Today, there are a wide variety of computing devices that enable users to copy and distribute digital content, particularly content that has been downloaded or stored on a storage device, such as a hard disk. Moreover, most DRM systems to date have security holes and have been circumvented. Unfortunately, due to these vulnerabilities of current DRM systems, content companies limit their offerings or use DRM systems that are difficult to use.

Drawings

Systems and methods embodying various features of the invention will now be described with reference to the following drawings, in which:

FIG. 1 illustrates an exemplary system according to one embodiment;

FIG. 2 illustrates an exemplary audit system, according to one embodiment;

FIG. 3 illustrates an exemplary download system, according to one embodiment;

FIG. 4 illustrates an exemplary client system, according to one embodiment;

FIG. 5 illustrates an exemplary storage device, according to one embodiment;

FIG. 6 illustrates an exemplary process flow for generating a binding key to bind content to a storage device, according to one embodiment;

FIG. 7 illustrates an exemplary process flow for providing content to a storage device, according to one embodiment;

FIG. 8 illustrates an exemplary process flow for playing content according to one embodiment.

Detailed Description

In one embodiment, digital content may be provided and bound to a particular device, such as a storage device. Digital rights management ("DRM") methods and systems are provided for controlled distribution and playback of digital content. The digital content may include the content itself and metadata. The content may be text, files, audio, video, multimedia, video games, etc. in any known format. The content metadata may be any data or information related to the content for processing the content. The content metadata may be used to provide secure digital content processing and to provide DRM protection. The content metadata may also include one or more digital certificates.

For example, a server providing content may encrypt each copy of the content based on an access key unique to that copy of the content. Thus, if the access key is compromised, the protection of only one copy of the content is compromised. In another embodiment, asymmetric encryption may be used to protect the content. In one embodiment, the encrypted content may be only a portion or portions of text, files, audio, video, multimedia, and so forth.

In addition, based on the configuration of the access key, the content may be uniquely bound to a specific device, such as a smart storage device. For example, an access key for the content is generated from at least two components. The first component is a binding key that is unique to the storage device on which the content is stored. In one embodiment, the storage device may generate the binding key using a random number or inputting the random number into a key generator. The second component is a content key that is specific to or unique to the content. In one embodiment, the algorithm for generating the access key may be implemented as a licensable or updateable function.

In one embodiment, digital content may be securely accessed based on an encryption key, such as a content key. Furthermore, in one embodiment, only certain entities are provided with an algorithm that generates an access key based on two components. For example, the storage device storing the content does not retain any copy of its binding key, nor does it have an algorithm to generate the access key. The algorithm that generates the binding key may be licensable or updatable.

In one embodiment, bidirectional authentication is used, for example, using public key infrastructure ("PKI") and public key certificate-based authentication to ensure that entities in the system are trusted. The various components of the system, such as the storage devices, may be intelligent and thus capable of mutual authentication, which is not possible in the prior art. For example, the storage device and the player or download server may mutually authenticate each other. This form of authentication ensures that the storage device confirms the trust relationship with the player and vice versa. Conventional DVD and blu-ray discs do not contain such components to authenticate or establish a trust relationship with the player or download server. PKI thus provides an environment in which entities of DRM systems can register their identities and establish trust with each other.

In one embodiment, digital content may be provided and bound to a particular device, such as a storage device. In one embodiment, an entity of a DRM system uses a public key certificate, i.e., a digital certificate that attests to its identity, and determines the authorization of various uses of its content. In another embodiment, a trusted party manages a certificate authority ("CA") to oversee PKIs and digital certificates. Further, multiple levels of CA may be provisioned in any embodiment.

Certificates may be issued from one or more of the CAs to all devices of the DRM system. If desired, an embodiment may provide for the complete revocation of an entity's certificate. As described above, mutual authentication may be used between entities to establish a secure communication channel for exchanging and distributing content. Each item of content may also be issued a digital certificate. This allows the content to function in determining whether the device is trusted.

Certain embodiments of the invention will now be described. These embodiments are shown by way of example only and are not intended to limit the scope of the invention. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms. Furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. For the purpose of illustrating some embodiments, reference will now be made to the accompanying drawings.

FIG. 1 illustrates an exemplary system 100 of an embodiment. As shown, the system 100 may include, among other things, an audit system 102, a download system 104, a client system 106, and a network 108. Further description of these components and certain aspects of their operation will now be made.

Audit system 102 acts as a trusted party to system 100. Further, audit system 102 may provide various administrative functions related to the distribution and playback of content in system 100. In one embodiment, the audit system 102 verifies and certifies the encryption key as part of the PKI used in the system 100. The auditing system 102 is further described with reference to FIG. 2.

Download system 104 includes hardware and software components for distributing content in system 100. In one embodiment, the download system 104 includes a website that includes links to content. The download system 104 may also provide a link to allow transactions with the audit system 102, such as a link to a key server and certificate authority. The download system 104 is further described with reference to fig. 3.

Client system 106 may be any device for accessing content provided by system 100. For example, the client system 106 may include a computer, a television, a portable or mobile device, a video game console, a portable video game console, and associated memory. Any device capable of downloading, storing, or playing content may be implemented as part of client system 106. For example, the client system 106 may include a desktop computer, laptop computer, tablet computer, smart phone, television, digital video recorder, set-top box, video game console, or portable video game console, or other form of electronic device. The client system 106 may also include a wired and/or wireless network and storage, such as network attached storage ("NAS") or external drives. Embodiments may be effective with any form of storage device, such as solid state and flash memory. The client system 106 is further described with reference to FIG. 4.

The network 108 provides a communication infrastructure through which the various components of the system 100 communicate. Network 108 may include any collection of networks and network elements. For example, the network 108 may be implemented over the Internet. However, network 108 may include any local, metropolitan, or wide area network and may be implemented as a private network, a public network, or the like. Thus, the network 108 may include wired or wireless communication links.

The system 100 may support several scenarios for downloading and playing content. For example, content may be downloaded from client system 106 to a portable storage device over network 108. The content may then be played on a playback device, such as a blu-ray player, game console, television, by streaming the content from a storage device. As another example, the playback device may include an integrated storage device for downloading and playback of content. As another use case, the content may be downloaded to a NAS system in the client system 106.

Yet another implementation may include a client system 106 having a storage device or media player to which content is bound. The user of the client system 106 may then remotely access the content and play it on a mobile device, such as an iPad, iPod, iPhone, a portable video game console, such as a portable PlayStationOr Nintendo DS, etc., which connects to the storage device or media player through a secure connection, such as a wireless connection, over WiFi, 3G, 4G, or other communication channel. In another implementation of the system 100, the client system 106 includes a portable storage device or media player that is wirelessly accessible, such as through a bluetooth or WiFi or similar communication system. The portable storage device or media player in the client system 106 may thus serve as a source of content in the client system 106 for playback on the portable and network-enabled viewing devices.

FIG. 2 illustrates an exemplary auditing system of an embodiment. As shown, audit system 102 may include a key server 200, a key database 202, and a certificate authority 204.

The key server 200 is a server that receives and provides various encryption keys utilized in one embodiment. The key server 200 may be implemented using known hardware and software. In one embodiment, key server 200 distributes the key as part of a digital certificate. The digital certificate may contain the key and information about the owner of the key. The key server 200 may provide certificates in a known format, such as x.509, PKCS, OpenPGP, and the like.

The key database 202 stores keys and other relevant information used by the key server 200. The key database 202 may be implemented using known database management systems such as Oracle, DB2, microsoft sql, PostgreSQL, and MySQL.

A certificate authority (or CA) 204 issues digital certificates for the system 100. The certificate format and content may be customized for each trusted party in the system 100. Further, in one embodiment, each item of content may have a trusted party certificate as part of its metadata. The certificate allows software associated with the content to independently determine whether a player in the client system 106 is attempting to access trusted content. For example, if a player in client system 106 is not trusted, the content-associated software may restrict the player from accessing high-definition content or other portions of content. In system 100, any trusted party may revoke all certificates, revoke certain certificates or certain portions of issued certificates.

In one embodiment, a Public Key Infrastructure (PKI) is used for certificate signing. For example, in the system 100, PKI is used in the client system 106 during device authentication and is used to establish a secure communication channel between storage devices, the download system 104, or playback devices. In one embodiment, mutual authentication is used between various entities in the system 100. For example, the storage device may be a smart device configured for efficient authentication and to establish a trust relationship with the playback device or download server 104 based on full mutual authentication.

Unique security parameters may be utilized between the entities of system 100 for each secure session. For example, a session key, a session ID, an initialization vector ("IV"), a hash-based message authentication code ("HMAC") key may be specific to each session. In one embodiment, system 100 utilizes a secure communication channel that is protected based on symmetric encryption. In another embodiment, the system 100 may utilize PKI to establish the secure channel.

Fig. 3 illustrates an exemplary download system of an embodiment. As shown, the download system 104 may include a download server 300 and a content database 302.

The download server 300 delivers content to the system 100, for example, to the client system 106. In one embodiment, the download server 30 encrypts the content with an access key that may be derived from the binding key and the content key. The binding key and the content key are further described below.

As shown, the download server 300 may include a web server that provides various web pages 306 to the client system 106, thereby making the content in the content database 302 accessible. In one embodiment, to provide content, the download server 200 provides one or more websites with many web pages 306.

In one embodiment, each copy of the content is uniquely encrypted. The entirety of the content may be uniquely encrypted, or portions of the content may be uniquely encrypted. Thus, if an item of content or its access encryption has been compromised, the damage is limited to that item of content. As will be described further below, only the download server 300 and the player have an algorithm to generate the access key. Further, as described above, the algorithm that generates the access key may be a licensable or updateable function.

The content database 302 stores content, content metadata, and related information provided by the download server. A storage and access infrastructure is provided to provide content items. Such database management systems are known to those skilled in the art.

Content provider 304 conceptually represents a content source. For example, content provider 304 may represent other databases or content repositories, content delivery networks, and the like. Any content source may be included in any embodiment.

FIG. 4 illustrates an exemplary client system 106 of an embodiment. A concern of many content providers is that software-based players in client systems are considered to have a high security risk because they are easy to modify and hack. One benefit of an embodiment is that the client system 106 includes a device with a hardware root of trust. The hardware trust root in the device includes secure cryptographic hardware that enables playback of the content, which is not software-based only, but utilizes the cryptographic hardware provided in the hardware trust root.

For example, in one embodiment, a media player may include dedicated hardware cryptographic processing circuitry and cryptographic boundaries that perform secure computations and secure storage of critical cryptographic parameters. As another example, a network attached storage ("NAS") controller may include dedicated hardware that may act as a root of trust. Accordingly, one embodiment may provide a secure DRM system that enables secure downloading of content, secure storage of content, and secure playback of content.

As will be further described, the client system 106 includes a smart storage device having a controller 408 that includes a hardware root of trust as part of a cryptographic processing module 409. In an embodiment, the encryption processing module 409 is separate from the other controller functions. Plaintext asymmetric and symmetric key access is limited to the encryption module 409. In this embodiment, the asymmetric and symmetric keys may be generated in the encryption module 409. The DRM of system 100 uses a public/private key pair. Any keys stored outside the cryptographic module are cryptographically protected. Because the asymmetric and symmetric keys are within encryption module 409, it is difficult for an attacker to obtain the private key. This allows the secure PKI to be implemented as part of the DRM of system 100. In another embodiment, various keys or encrypted data may be injected or securely stored on the storage device 402. For example, in a secure manufacturing environment, one or more keys may be injected onto the storage device 402.

In one embodiment, the encryption module 409 is used to generate additional keys that are securely within its boundaries. For example, the encryption module 409 may be configured to generate a binding key for binding content to the storage device 402. The encryption module 409 may also include the ability to digitally sign and store secure information in non-secure memory and to digitally sign and encrypt secure information and store it in non-secure memory.

In an embodiment, a playback device in client system 106, such as host device 400, may also be issued a certificate by certificate authority 204. The host device 400 may be, for example, a computer, a television, a portable or mobile device, a video game console, a portable video game console. In one embodiment the certificate may be stored in a secure area that is not accessible to the player's processor. In another embodiment, for example, a player running on a host device may store the certificate anywhere, such as in a user area or other non-secure area of the storage device 402. The playback device may store the certificate in encrypted or protected form, e.g. with a digital signature. When the player and storage device 402 performs authentication, the cryptographic modules in both devices will be the only entities that can access the secure data to perform the authentication and establish a secure communication channel.

However, in one embodiment, the content and content metadata do not provide an access key for accessing the content. Conversely, once a secure communication channel is established, a playback device (such as host device 400) will request the binding and content key from storage device 402. In response to the request, the storage device 402 may then send the binding and content key to the player so that it can generate an access key. The access key is used to decrypt and render the content. Those skilled in the art will appreciate that by utilizing these secure encryption modules for security-related communication and processing of security parameters, content metadata (e.g., binding and content keys), and keys, the DRM of system 100 is more difficult to attack and compromise than existing systems.

As shown, the host device 400 may include, among other things, a processor 404, a host encryption module 405, and an output device 406. Further description of these components of host device 404 will now be made.

The processor 404 includes hardware for executing instructions that direct the operation of the host device 400. Such processors are known to those skilled in the art.

The host cryptographic module 405 includes hardware for performing cryptographic operations for the host device. Further, the host cryptographic module 405 may be packaged or embedded with various security measures to resist tampering.

Output device 406 represents any device intended to output content. For example, output device 406 may include a display, audio speakers, and the like. Such output devices are well known to those skilled in the art.

The storage device 402 may include, among other things, a controller 408, an encryption module 409, and a storage medium 410. Further description of these components of the storage device 402 will now be made.

The controller 408 includes hardware and firmware that controls the operation of the storage device 402 and enables communication with the host device 400. The controller 408 may be implemented using known hardware and components.

The encryption module 409 may provide a trust foundation, such as a hardware root of trust, for the storage device 402. In one embodiment, the encryption module 409 is a secure cryptoprocessor configured to perform various encryption operations. In one embodiment, the encryption module 409 may be implemented as an external system on a chip that is packaged with various security measures to prevent or detect tampering. In another embodiment, the cryptographic module 409 may be implemented as part of or embedded within another system on a chip, or as other hardware packaged with various security measures to detect or resist tampering. The encryption module may or may not be isolated from other system on chip ("SoC") functions.

Storage medium 410 refers to the physical medium used by storage device 402 to store information. In one embodiment, storage media 410 may include magnetic media, optical media, semiconductor media, such as flash memory, and the like. Storage media 410 may include any combination of these media in one embodiment.

FIG. 5 further illustrates an exemplary storage device 402 of an embodiment. As shown, the encryption module 409 may include protected memory 502. Further, the storage medium 410 may include a user area 504 and a non-user area 506.

Protected memory 502 provides a secure area to store sensitive information about the DRM provided by system 100, such as content metadata. In one embodiment, protected memory 502 is implemented as one-time programmable non-volatile memory ("OTP NVM"). As an OTP NVM, the protected memory 502 can be programmed only once and is difficult to change. In addition, protected memory 502 may also include one or more memories, such as ROM (read Only memory), static RAM (random Access memory), and dynamic RAM.

As for the user area 504, this area of the storage medium 410 is provided as a storage space accessible to the host apparatus 400. For example, user area 504 may be addressable according to a Logical Block Address (LBA) used by host device 400.

The storage device 402 may be configured to include partitions in the protected user space 504. That is, the data in this partition may be encrypted using a separate key generated by the encryption module 409. Only authenticated download clients or players (such as players running on host system 400) are permitted access to the partition. In one embodiment, all or some of the data from this partition in user space 504 may be sent only over a secure authenticated channel.

This partition of user space 504 may be used, for example, for additional content metadata files and information regarding the DRM of system 100. The actual content itself may be sent from the download server 300 or to the player in the client system 106 only in encrypted form, so the content may be stored in the user space 504.

As shown, the storage device 402 may also include a non-user area 506. The non-user area 506 is a reserved area of the storage medium 410 that the host 400 cannot directly access. For example, the non-user area 506 may refer to an area that the host system 400 cannot address. In one embodiment, non-user area 506 is reserved for use by controller 408 and encryption module 409, for example, to store various sensitive information about the DRM of system 100, such as content metadata information.

In one embodiment, encryption module 409 may generate new security keys and allow storage device 402 to generate secure unique disk encryption keys for particular partitioned areas of the media that are not visible in user LBA space, such as non-user area 506. Using the key, the encryption module 409 can thus encrypt all data written to the non-user area 506.

The non-user area 506 may be used to store security metadata regarding the DRM of the system 100. The metadata may include, for example, certificates, key files, license files, and the like. For example, storage 402 would have a certificate issued to it from certificate authority 204. The certificate may be stored in this non-user area 506 and will be encrypted with a key for that area. This will bind the certificate to the storage 402. Thus, if a clone copy of the drive is made in some way, the clone will not include the encryption key for the non-user area 506, and therefore, the data stored in that area cannot be properly decrypted. Alternatively, critical security parameters, such as keys, certificates or other objects, may be separately cryptographically protected and stored to the storage medium.

Thus, in one embodiment, the controller 408 and the recording medium 410 cannot function separately from each other in order to access the content. That is, a complete copy of the controller 408 or the media 410 alone would not be sufficient to access the content.

FIG. 6 illustrates an exemplary process flow for generating a binding key for binding content to a storage device. In one embodiment, the storage device 402 may generate the binding key using a random number and inputting the random number into a key generator. The key generator may be software running in the storage device 402 or a hardware component of the storage device 402. In one embodiment, the binding key consists of two parts. In one embodiment, the first portion is based on a defect list of the storage device. The second part is based on a key hidden by the cryptographic module on the storage device. To protect the binding key, the binding key is not stored with the content or content metadata in storage 402. Instead, portions of the binding key are stored separately. Further, in one embodiment, the binding key is generated as a temporary key and, therefore, is computed by the storage 402 only when needed. The method also includes the ability to update the function. As described above, the binding key may be specific to each storage device or to a class of devices, such as the same type of device, etc.

As shown, first, the storage device 402 is prompted to determine or identify unique characteristics about itself. For example, the storage device 402 may determine or identify the defect list 600. In one embodiment, defect list 600 corresponds to a P-list or a time-zero list (time-zero list) of defects that exist on storage medium 410 at the time of manufacture. Of course, in other embodiments, the unique features may originate or originate from other portions of the storage device 402.

Second, the encryption module 409 encrypts the processing defect list 600 and generates a unique identifier 602. For example, the encryption module 409 may compute a hash of the information from the defect list 600. In addition, the encryption module 409 may digitally sign the unique identifier 602. Alternatively, the unique identifier may be generated by generating a random number unique to the storage device using a random number generator. For example, encryption module 409 may include a random number generator that is a physical device or component in encryption module 409 or software running in encryption module 409. Alternatively, the random number generator may be a separate software or hardware device running on the storage device 402.

Third, the encryption module 409 may store the unique identifier 602 in a secure area. For example, as shown, the encryption module 409 may also store a cryptographically secured unique identifier 602 in the non-user area 506.

Fourth, the encryption module 409 may generate the hidden key 604. In one embodiment, key 604 is hidden because it is not stored with other content metadata, but is stored in protected memory 502. The encryption module 409 may generate one or a set of multiple hidden keys 604. Thus, if one of these keys is compromised, the encryption module 409 may switch to the next key in the group. If all keys are used, or if it is not desired to generate or store a key set, then the encryption module 409 may generate a new hidden key 604 upon request. Notably, the controller 408 can be configured to track which content is bound to which key.

Based on the unique identifier 602 and the hidden key 604, the storage device 402 may generate a binding key 606 that is derived from information provided by the controller 408 and unique characteristics of the storage medium 410. In one embodiment, the encryption module 409 temporarily generates the binding key 606.

The binding key 606 cryptographically binds the content to the storage device 402. For example, the binding key 606 may be sent as part of the metadata of the content over a secure communication channel to the download server 300 in the download system 104. The download server 300 can then utilize the binding key as a component of the access key for encrypting the content.

The binding key 606 may also be made available to an authenticated player over a secure channel at an appropriate time for use during playback of the content. For example, the depository 402 may be configured with a dedicated command that is received only when the sending device is authenticated and communicating over a secure channel.

Based on the binding key 606, the cloned media will not be used to render content even if an exact bitwise copy of the overall media 410 is completed, because the hidden key in the storage device is uniquely and securely stored in the protected memory 502 of the encryption module 409 and cannot be copied or cloned to another drive.

FIG. 7 illustrates an exemplary process flow for supplying content to a storage device. In this embodiment, revocable and renewability are attributes of the DRM system. As an additional safety system component, the illustrated process flow may include various renewability features. For example, a random key that may be obsolete or pre-generated may be used with a secure distribution algorithm that changes over time or utilizes multiple keys in a random manner for each item of content provided to the storage 402. For example, embodiments may utilize tokenization of update files applicable to all players.

In one embodiment, the process involves the provision of content and content metadata, such as binding keys and content keys. Other metadata, such as digital certificates, etc., may also be provided as part of an embodiment.

As shown, first, the storage device 402 and the download server 300 establish a secure communication channel with each other. For example, the download server 300 and the storage device 402 may establish a secure communication channel using PKI. In particular, the host 400 may request a certificate from the storage 402. The storage device 402 may retrieve its credentials, for example, from its non-user area 506 in the medium 510. The storage 402 may then send the device session ID and its credentials. The certificate includes its public key; public_Device。

In one embodiment, host 400 (not shown in FIG. 7) verifies the certificate. For example, the host 400 may check the signature on the certificate. The host 400 may also check its revocation list to ensure that the certificate from the storage device 402 has not been revoked. Alternatively, host 400 may communicate with audit system 102 and certificate authority 204 over network 108 to verify certificates and check the revocation status of certificates.

Host 400 then responds by sending the host session ID and its certificate, including its Public key Public, to storage 402_Host. The storage 402 verifies the host certificate and checks the signature. The storage device 402 may also check its own revocation list to ensure that the host 400 has not been revoked.

Host 400 may then request the session key from storage 402. In response, in an embodiment, memory device 402 is Public_HostThe random session key, the random device initialization vector ("IV"), and the random device hash-based message authentication code ("HMAC") key are encrypted and sent to the host 400.

Private for host 400_HostThe information is decrypted to recover the device session key, the device IV, and the device HMAC key. Public for host 400_DeviceEncrypts the random host session key, random host IV, and random host HMAC, and sends this information to storage 402. Then, the storage device 402 uses Private_DeviceThis information is decrypted to recover the session key of host 400, host IV, and host HMAC keys.

The host 400 may also encrypt the random challenge with the device session key and send it to the storage device 402. The storage device 402 decrypts the host random challenge with the device session key and then encrypts the host random challenge with the host session key and sends this information back to the host 400. The host 400 decrypts the host random challenge with the host session key and confirms that it matches the content originally sent to the storage device 402. This proves that the storage device 402 knows the private key corresponding to the public key sent with its device certificate.

To further confirm, the host 400 may request a random challenge from the storage device 402. The storage device 402 encrypts the device random challenge with the host session key and sends this information to the host 400. The host 400 then decrypts the device random challenge with the host session key and encrypts the device random challenge with the device session key and sends this information back to the storage device 402. The storage device decrypts the device random challenge with the device session key and confirms that it matches the content originally sent to the host 400. This proves that the host 400 thus knows the private key corresponding to the public key sent with the certificate of the host 400.

In one embodiment, the storage device 402 may use AES encryption with the host session key and host IV for secure messages to the host 400. The host 400 may also use AES encryption with the device session key and device IV for secure messages to the storage device 402.

Once a secure session has been established, session communication may be implemented using asymmetric or symmetric algorithms. In one embodiment, each security information may include a header with a sequence number and message length, a body message AES encrypted with an appropriate session key and IV, and a footer with SHA-256HMAC for the message body. In another embodiment, session communications are established based on asymmetric encryption and then protected based on symmetric encryption. For example, once a secure session has been established, session communications may be implemented based on symmetric encryption, such as AES encryption and AES decryption with session keys and an establishment IV. Each secure message may include a header with a sequence number and message length, a body message AES encrypted with the appropriate session key and IV, and a footer with SHA-256HMAC for the message body. In another embodiment, asymmetric encryption may also be used to protect traffic during a session.

Second, the download server 300 requests the binding key from the storage device 402 as a result of the secure channel being established. Specifically, the download server 300 may send the message to the storage device 402 over a secure channel. As described above, in one embodiment, the binding key 606 is initially absent from the metadata of the content and is generated when needed.

Third, the storage device 402 generates a binding key 606. In particular, the cryptographic module 409 generates a binding key 606 based on the unique key 602 and the hidden key 604.

In one embodiment, the encryption module 409 generates the binding key, Kb, using a one-way hash algorithm or an Advanced Encryption Standard (AES) algorithm, wherein:

Kb=F（Kroot，IDm）

wherein, F is a one-way function,

kroot is the key generated by the encryption module 409, i.e., the hidden key 604,

IDm is a unique media identifier number, such as a unique identifier 602, assigned during the manufacturing process of the storage device 402.

Alternatively, the encryption module 409 may generate the binding key using a random number, such as a random number from a random number generator, and inputting the random number into a key generator. The key generator may be a software or hardware component in the encryption module 409.

Fourth, the download server 300 requests a content key for protecting the content from the key server 200. The content key may be distributed to the content by various methods. For example, the key server 200 may distribute a content key 700 specific to each item of content. In one embodiment, the content key 700 is provided as part of the metadata of the content and stored on the storage device 402. When sent to host 400, content key 700 may be cryptographically protected.

Fifth, the key server 200 provides the content key 700 to the download server 300. In particular, the key server 200 may establish a secure channel with the download server 300, e.g., based on PKI.

Sixth, the download server 300 generates an access key 706 based on the binding key 606 and the content key 700. In particular, the download server 300 may use a unique algorithm to cryptographically bind the binding key 606 and the content key 700 and generate the access key 706, e.g., based on a one-way hash algorithm. The unique algorithms may be known only to certain entities of the system 100, such as the download server 300 and trusted playback devices in the client system 106. The algorithm may be a licensable or updateable function. Further, one or more algorithms may be passed from the download server 300 to a trusted component in the client system 106 through a field or portion of the secure metadata of the content. For example, a set of multiple algorithms may be initially configured or established in a trusted component of the client system 106. The download server 300 may then provide a pointer or indicator in the secure metadata of the content indicating the set of algorithms used when generating the access key.

In one embodiment, the access key 706 is not included in the content metadata, nor is it stored on the download server 300. For example, the download server 300 may instead be configured to temporarily generate the access key 706. Alternatively, the information used to generate the access key 706 may be archived by the download server 300 to secure remote storage. For example, audit system 102 may act as a secure repository for securely storing binding key 606 and/or content key 700.

Seventh, the download server 300 provides the content key 700 to the storage device 402. Storage device 402 then securely stores content key 700. For example, storage 402 may store content key 700 in non-user area 506.

Eighth, the download server 300 encrypts all or part of the content 702 into encrypted content 704. For example, the download server 300 may use AES encryption to encrypt the content 702 based on the access key 706.

Ninth, the download server 300 provides the encrypted content 704 to the storage device 402. The storage device 402 may then store the encrypted content 704, for example, in its user area 504.

FIG. 8 shows an exemplary process flow for playing content. As shown, first, the host system 400 and the storage device 402 may establish a secure communication channel with each other. For simplicity, an example of PKI-based establishment of a secure channel is provided above with reference to fig. 7. In one embodiment, storage 402 will evaluate the digital certificate and player certificate of the content to determine that the player is suitable for receiving content and/or content metadata.

Second, the host system 400 requests the binding key 606 from the storage device 402 because it is not in the content metadata. Notably, in one embodiment, the storage device 402 does not retain the binding key 606. In another embodiment, the host system 400 requests a binding key 606 that is specific to the content to be played. This feature allows, for example, storage device 402 to use a different algorithm for generating binding key 606, if desired. The algorithm used may depend on various criteria, such as the specific item of content, the type of content, the source of the content, the number of copies of the content, for recovery, theft detection, etc.

Accordingly, third, the storage 112 temporarily generates a binding key 606. Specifically, as described above, the cryptographic module 409 generates the binding key 606 based on a cryptographic combination of the hidden key 604 and the unique identifier 602. Once generated, the storage device 112 may transmit the binding key 606 to the host system 400.

Fourth, the host system 400 requests the content key 700 from the storage device 112. In one embodiment, the content key 700 may be retrieved from content metadata stored in the non-user area 506 on the storage device 402. Host system 400 may request content key 700 based on various parameters, such as a content identifier, etc.

Fifth, storage device 402 provides content key 700 to host system 400. For example, storage device 402 may access non-user area 506 and transmit content key 700 to host system 400. When retrieving the content key 700, the encryption module 409 may need to perform various cryptographic functions, such as decryption, checking for digital signatures, and the like.

Sixth, to decrypt the content, host system 400 generates access key 706. In particular, the encryption module 405 of the host generates the access key 706 based on the encrypted combination of the binding key 606 and the content key 700. The cryptographic module 405 is programmed with a unique algorithm that is known only in the cryptographic module 405. For example, encryption module 405 may include an OTP NVM that is programmed with an algorithm that generates access key 706. This feature allows, among other things, that access key 706 is not substantially in the content metadata.

Seventh, the storage device 402 provides encrypted content 704 to the host system 400. In one embodiment, storage 402 streams encrypted content 704 to host system 400.

Eighth, host system 400 processes encrypted content 704 cryptographically, thereby recovering content 702 in a non-encrypted manner. As described above, in one embodiment, the content is encrypted using access key 706 based on a symmetric encryption, such as AES 128. Once in decoded or unencrypted form, host system 400 may then output content 702 to output 406. Notably, the host system 400 may re-encrypt the content for delivery to the output 406. For example, if output 406 is a high definition multimedia interface ("HDMI") device, host 400 may encrypt the re-encrypted content using the high bandwidth digital content protection ("HDCP") encryption currently specified for HDMI devices and transmit the content in this secure form. In one embodiment, the host 400 may decrypt the content and then re-encrypt the content using a secure transport encryption protocol, such as high-bandwidth digital content protection protocol (HDCP), and output the re-encrypted content to a display device, such as a television, monitor, or the like. In another embodiment, the host 400 decrypts the content, then re-encrypts the content using, for example, Digital Transmission Content Protection (DTCP), and sends the re-encrypted content to a playback device, such as a television, monitor, or the like. Accordingly, in one embodiment, content is always in a protected form when transferred between entities in the system 100.

The features and attributes of the specific embodiments disclosed above can be combined in different ways to form additional embodiments, all of which are within the scope of the present disclosure. For example, in the case of network connected storage (NSA), NSA storage may include one or more storage devices and implement various techniques (e.g., RAID) that result in content being able to be spread across multiple storage devices. In the case of a NAS that includes a single drive, the NAS controller may be configured to bind content to the single drive's storage in a manner similar to that described above. In the case of a NAS that includes multiple drives, the content may be bound to the NAS subsystem rather than or in addition to a particular storage device or storage medium. Accordingly, the NAS subsystem may contain a secure cryptographic module. In this variation of the embodiment, for NAS storage, the unique key set may be generated by the NAS controller and securely stored in the secure storage of the NAS. The binding of the content to the NAS may then be performed in a manner similar to that described above. Thus, even if a clone copy of a drive is completed, the drive will not be usable unless it is installed in the exact same NAS system. The method may be used to replace a failed drive in a NAS RAID system while ensuring that the cloned drive is not useful.

While the present disclosure provides certain embodiments and applications, other embodiments that are apparent to those of ordinary skill in the art, including embodiments that do not provide all of the features and advantages set forth herein, are also within the scope of the present disclosure. Accordingly, the scope of the disclosure is intended to be limited only by reference to the appended claims.

Claims (20)

1. A system configured to provide content to a storage device in encrypted form, the system comprising:

an interface coupled to the storage device; and

a processor configured to determine a first encryption key corresponding to the content, receive a first binding key from the storage device that is unique to the storage device that stores the content in encrypted form, generate an access key based on an encrypted combination of the binding key and the first encryption key, encrypt the content based on the access key to produce an encrypted form of the content, and transmit the encrypted content and the first encryption key to the storage device through the interface.

2. The system of claim 1, wherein the first binding key is based on a key hidden on the storage device.

3. The system of claim 1, wherein the processor is configured to authenticate the storage device, establish a protected communication channel with the storage device through the interface based on the authentication, and transmit the first encryption key to the storage device through the protected communication channel.

4. The system of claim 1, wherein the processor is configured to request a first binding key as a temporary key.

5. The system of claim 1, wherein the processor is configured to generate a temporary access key based on a request received by the storage device.

6. The system of claim 1, wherein the processor is configured to generate the access key based on a one-way function.

7. A digital rights management system, the system comprising:

a storage device comprising a storage medium configured to store content and a storage device controller comprising a hardware cryptographic processor, wherein the hardware cryptographic processor is configured to generate and store a unique number, read defect information from the storage medium, and perform a cryptographic operation on the defect information to obtain a defect number unique to the storage device, store the obtained defect number on the storage medium, perform a cryptographic operation on the unique number and the unique defect number to generate a binding key, and provide the binding key to a content download server;

a content key server configured to provide a content key to a content download server;

a content download server configured to perform an encryption operation on at least a binding key received from a storage device and a content key received from a content key server to generate an access key, encrypt at least a portion of content with at least the content encryption key, provide encrypted content to the storage device, provide the content key received from the content key server; and

a media player configured to receive a binding key and a content key from the storage device, perform an encryption operation on the binding key and content key to generate a content encryption key, and decrypt the content from the storage device based on the content encryption key.

8. The system of claim 7, wherein the media player and the storage device are configured to mutually perform authentication with each other.

9. The system of claim 7, wherein the media player is configured to generate a decryption key for accessing the content based on the binding encryption key in conjunction with the content key and the binding encryption key.

10. The system of claim 7, wherein the hardware encryption processor is configured to generate a set of binding keys.

11. The system of claim 7, wherein the hardware encryption processor is configured to store a digital certificate for authenticating the media player.

12. The system of claim 11, wherein the media player is configured to authenticate with the hardware encryption processor based on a stored digital certificate.

13. The system of claim 7, wherein the storage device is configured as a network-connected memory.

14. The system of claim 7, wherein the hardware encryption processor is configured to receive a private key and a public key in a secure manufacturing environment.

15. A method of providing content from a download site to a storage device, the method comprising:

providing a binding encryption key to the download site for binding content from the download site to the storage device;

receiving, from the download site, a first encryption key associated with content encrypted by the download site;

encrypting the first encryption key;

storing the encrypted first encryption key on the storage device; and

receiving encrypted content from the download site, wherein the encrypted content comprises content encrypted based on an encrypted combination of the first encryption key and the binding key.

16. The method of claim 15, further comprising establishing a protected communication channel with the download station based on authentication of the download station.

17. The method of claim 15, wherein the binding key is unique to each of the storage devices and is based on a key hidden in the storage device.

18. The method of claim 15, wherein the binding key is unique to a class of storage devices and is based on a key hidden in the storage devices.

19. The method of claim 15, wherein authenticating the download site comprises mutually authenticating with the download site.

20. The method of claim 15, wherein providing the bound encryption key comprises temporarily generating the bound encryption key based on information unique to the storage device and the hidden key.