US 20080168568 A1
A digital rights management (DRM) system for distribution of digital content such as audio or video uses a token passing scheme to enhance security of the content from unauthorized access and use, including access by unauthorized players. The token is requested from the central content or DRM server by a host device such as a user's computer, using security related information. The token is then passed to a media player associated with the host device, the token being encrypted using a key special to that particular player. Upon receipt of the token, the player transmits back to the server certain related security information confirming receipt of the token and in return receives keys for decryption of the associated digital content. In the absence of proper passing of the token, player access to the content, or further access to other content, is denied. This also allows the player to communicate directly with the server for obtaining the keys.
1. A computer enabled method for controlling distribution of media content between a source, a host device, and a player associated with the host device, the method comprising the acts of:
exchanging authentication data between the player and the host device;
transmitting a request for a token from the host device to the source;
receiving the token at the host device;
sending the token to the player;
sending identification data from the player to the host source including the token; and
receiving at the player, in response to the token, at least one key relating to encryption or decryption of the content to be distributed.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
8. The method of
9. The method of
10. A computer readable medium carrying computer code for performing the portions of the method of
11. A computer readable medium carrying computer code for performing the portions of the method of
12. A programmed apparatus programmed to perform the portions of the method of
13. The method of
14. The method of
15. The method of
16. A computer enabled method for controlling distribution of media content to a player from a source, the player having an associated host device, the method comprising the acts of:
the player exchanging authentication data with the host device;
receiving at the player a token originating at the source, via the host device;
sending identification data from the player to the source, the data including the token; and
receiving at the player, in response to the token, at least one key relating to encryption or decryption of the content to be distributed.
17. The method of
18. The method of
19. The method of
20. The method of
21. The method of
22. The method of
23. The method of
24. The method of
25. A computer readable medium carrying computer code for carrying out the method of
26. A programmed apparatus programmed to carry out the method of
27. The method of
28. The method of
29. The method of
30. A computer enabled method for controlling distribution of media content to a host device for playing on an associated player, the method comprising the acts of:
the host device exchanging authentication data with the player;
transmitting from the host device a request for a token from the host device to the source;
receiving the token at the host device; and
sending the token from the host device to the player; and
thereby the player being enabled to decrypt or encrypt the content to be distributed.
31. The method of
32. The method of
33. The method of
34. The method of
35. The method of
36. The method of
37. The method of
38. The method of
39. A computer readable medium carrying computer code for performing the method of
40. A programmed apparatus programmed to carry out the method of
41. The method of
42. The method of
43. The method of
44. A player for storing and playing media content received from an external source, and having a digital rights management (DRM) portion, the DRM portion comprising:
an input/output port adapted to receive the media content and to send and receive DRM information;
a storage for an authentication certificate of the player, coupled to the port;
a storage for a global identifier of the player, coupled to the port;
a storage for a token received from the source, coupled to the port;
a key repository, coupled to the port for storing keys for decrypting the media content;
a storage for an additional token, coupled to the port; and
a processor coupled to the port and to the global identifier storage and to the token storage, and for assembling identification data including the global identifier, the token, a signature of the token, the authentication certificate, and a size of the token signature and a size of the authentication certificate to be transmitted from the port.
This invention relates to Digital Rights Management (DRM) for protection of audio and video data in a playback device such as a computer or audio or video media player.
The protection of digital content transferred between computers over a network and transferred from a computer or other host device or a server to an associated playback device is important for many organizations. The DRM process often involves encrypting the pieces of content (e.g., encrypting the binary form of the content) to restrict usage to those who have been granted a right to the content, which is typically pieces of music or video programs.
Cryptography is the traditional protection method, but for many digital file transfer situations, a party that legitimately receives the content might try to break the DRM protection scheme, so as to give illicit access to third parties. Hence an identified weak link in the DRM security is in the overall process, rather than the encryption scheme. For instance, one of the more successful DRM schemes distributes music and video content via the Internet. The DRM system distributes to a user's computer content that has been encrypted. The user's computer then decrypts the received content, generates local keys for encrypting the content, and uses the local keys to re-encrypt the content. Typically the content in encrypted form may also be downloaded, via a local connection such as a USB (universal serial bus) connection, to an associated playback-only device such as an audio or video media player, which similarly decrypts and re-encrypts the content before playing same.
The present inventors have identified a potential security issue with this approach. There is a need to strengthen the security linking a particular playback device to the associated host device (computer) and also to the central server from which the content and/or DRM information is downloaded.
In accordance with the invention, the playback (player) device, such as a media player or computer, is linked to the associated host device, such as a computer, and to a central server, by a token passing protocol (process) intended to guarantee that before any content is made available for play on the playback device, the genuineness of the playback device is established, in the sense that it indeed is authorized to receive and play the content. This improvement in the DRM system is intended to strengthen the overall system security, and especially to better secure the content (typically copyrighted material) from authorized access or use.
Thereby, a three way token exchange is provided which involves the content and/or DRM central server, or other source of the content or DRM information, the computer-like host device (such as a computer, cell phone, PDA, etc.) and the playback device also referred to here as the player (such as a media player but which also may be a cell phone or PDA.) Note that the central server may be in fact be a group of servers, such as an on-line music and video “store” selling such material. In some cases, the player has no user keypad (such as when it is a media player device), so the present process is intended in one embodiment to avoid the user of the player from having to enter authorization passwords, etc. into the player, since that would be inconvenient. In the present process, the host device is first conventionally authorized to communicate with the server. Then a DRM security protocol, of conventional type, is exchanged between the host device (which is for this process the “master” in computer network nomenclature) and the player (which is the “slave”) Note the references here to the “host device” more particularly refer to a digital media player software application (computer program) for playing and organizing digital music and video files, and executed on a computer or equivalent. The program is also an interface to manage the content stored on a linked player, and allows connection to the server to download (typically purchased) digital content. Such applications are well known and typically supported on computers running various operating systems, such as the Apple Mac OS or Windows 2000, and may also run on other computer-like-devices such as cell phones, PDAs, etc.
After the protocol exchange, the player and host device each thereby have in their appropriate memory areas (storage) the conventional authorization certificate of the other device and an encryption key. The host device then sends to the server certain DRM related information, and receives from the server an authentication token, of a type known in the computer security/networking field. Typically such tokens operate as a “ticket”, allowing only one entity to transmit a message at any given time. In this case the token is encrypted with a key related to the player, and the token is sent (via the host or directly) to the player, and not stored in the host device. In one embodiment the player is equipped with the requisite components and software to connect to the Internet for instance, and thereby directly to the central server, bypassing the host device.
The player upon receipt of the token sends back to the server (either directly, or via the host device), additional DRM related information, including the token itself and associated authenticating information. Last, the player receives from the server (directly or via the host device) the relevant DRM key(s) for conventionally decrypting the content, and a new token to be used for the next request. At this point, the player can download and play content from the host device or server. Of course, if the token passing fails, the content will not download, or at least the relevant keys will not be downloaded or are not accessible, preventing playing of the content. Hence successful token passing is essential for the DRM system to allow downloading/playing. One attendant advantage is that this prevents unauthorized players from obtaining the digital content and/or keys.
To further describe this token exchange process, the DRM token is transmitted from the host device, which is typically a “client” software application relative to the media content server, to the player. The token entitles the player to obtain the requisite DRM information directly from the server without, in some embodiments, the subsequent participation of the host device. In one embodiment, the request for the token comes from the host device to the server. The token is sent in response from the server back to the host device, which then in turn sends it to the player. The token is then sent by the player back to the server to obtain the proper decryption key(s) from the server, to allow play back of any media content obtained from the server. This process thereby allows direct communications between the server and player to obtain the keys. This is an improvement in terms of convenience over prior approaches not involving a token, but always requiring “synchronization” between the player and host device for obtaining both the DRM information and the media content. Hence this process allows the player to operate in more independent fashion.
Referring to the numbered lines in
At 2, the host device sends the following to the server to request the token for the player:
An account ID (identification number) associated with the particular user of the host device or the host device itself, with the server.
The GUID (global universal identifier) of the server (the source ID). GUID is a standard term referring to e.g. a 128 bit binary number used to identify in the computer field a component, file, user, etc.
The GUID of the player (the destination ID).
An authentication string (data) which is equal to the value of HMAC_HASH (source ID+destination ID+account ID+transformed key account+key ID of the transformed account key). Here HMAC_HASH refers to a well known mathematical function which is a hash (one-way) function based message authorization code well known in cryptography; well known types of HMAC are MD5, SHA, and others. Each key has an associated ID. Each key is conventionally obfuscated in storage (the key repository), and an obfuscated key is considered to be “transformed.” Here the authentification uses information known to the authenticating device. The key ID is used if possible, but if it is not found then instead another key ID is used.
The key ID of the selected transformed account key.
The user name/user password for the account. (The user here is the consumer—the player owner.)
Next, at 3 the host device receives from the server the authentication token, which has already been encrypted with a key specially derived from some aspect (such as hardware) of the player. This key is intended to be unique to that particular player device. An example of the derivation uses an HMAC_HASH function as explained above, so the key value is equal to HMAC_HASH (destination GUID+Account ID+Static “Random”). In this case the value of Static “Random” may be a supplied random number. This token is preferably not stored in any key repository in the host device, but is sent at 4 to the player. (The key depository is conventionally storage—memory locations—allocated for encryption keys.)
Note that at 4, when the host device sends the token to the player, the token itself is sent in encrypted form, the encryption using the security protocol key derived in step 1 above. The player stores this key in its key repository.
Then at 5, the player retrieves the token from its key repository. The associated DRM session key is stored in an encrypted context that is passed back and forth from the host device to the player. The player then sends the following information to the server, directly as shown or via the host device:
The player GUID
The server GUID
The account ID
The token as received in step 4, signed (provided with a cryptographic signature) with e.g. the signature's public key.
A signature of the token. (The signature is of a type conventional in cryptography as an authentication technique, using in one embodiment public key-private key cryptography.)
The size (length in bits) of the token signature.
The player authorization certificate.
The size of the player authorization certificate.
Next at 6, the player receives the relevant key(s) for its key repository from the server directly, or via the host device, for the particular user account and player, and also a new token to be used for the next token request, and stores both in its storage. The received key(s) then are used conventionally by the player to decrypt the associated digital content, which is transferred to player 30 conventionally.
This process is shown (in somewhat less detail) in
It is to be understood that the process of
This disclosure is illustrative and not limiting; further modifications will be apparent to one skilled in the art in light of this disclosure, and are intended to fall within the scope of the appended claims.