WO2007021830A1

WO2007021830A1 - Protecting digital media of various content types

Info

Publication number: WO2007021830A1
Application number: PCT/US2006/031185
Authority: WO
Inventors: Anders E. Klemets; James M. Alkove; Sanjay Bhatt; Eduardo P. Oliveira; Anand Paka
Original assignee: Microsoft Corporation
Priority date: 2005-08-11
Filing date: 2006-08-10
Publication date: 2007-02-22
Also published as: EP1922642A1; RU2008104858A; CN101243431A; US8321690B2; US20070038873A1; KR101312910B1; BRPI0615147A2; KR20080036601A; RU2427898C2; EP1922642A4; MX2008001850A; CN101243431B; JP5686951B2; JP2009505506A

Abstract

Systems and/or methods ('tools') are described that enable a digital rights management policy to be associated with digital media having an arbitrary content type or transfer control protocol. In some embodiments, the tools encrypt data segments of a media file and add a descriptor to each of those segments. These descriptors can enable a receiver of the encrypted media file to decrypt the file and consume it according to the correct digital rights management policy.

Description

PROTECTING DIGITAL MEDIA OF VARIOUS CONTENT TYPES

BACKGROUND

Digital Rights Management (DRM) refers to techniques that are used to protect content, such as by controlling or restricting the use of digital media content on electronic devices. One characteristic of DRM is that it can bind the media content to a given machine or device. Thus, a license that pertains to a particular piece of content and that defines rights and restrictions associated with the piece of content will typically be bound to the given machine or device. As a result, a user may not take the piece of content and move it to another machine in order to playback the content.

Current DRM techniques have limitations. They are often compatible with only two types of protocols for transferring digital media — HTTP and RTSP. But other protocols may now or in the future be better suited for transferring digital media. Also, content protected by DRM may be limited to a particular content type. One particular content type — ASF files — permits only one set of rights and restrictions, i.e. "policies", to apply to an entire ASF file. For example, when a video file is rendered, either Macrovision may be required to be enabled on an analog video output for the whole file, or it may not be required at all.

SUMMARY

Systems and/or methods ("tools") are described that enable a digital rights management policy to be associated with digital media having an arbitrary content type or transfer control protocol. In some embodiments, the tools encrypt data segments of a media file and add a descriptor to each of those segments. These descriptors can enable a receiver of the encrypted media file to decrypt the file and consume it according to the correct digital rights management policy.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 illustrates an exemplary registration procedure of a protocol with which the inventive embodiments can be employed in one embodiment.

Fig. 2 illustrates an exemplary proximity detection procedure of a protocol with which the inventive embodiments can be employed in one embodiment.

Fig. 3 illustrates an exemplary session establishment procedure of a protocol with which the inventive embodiments can be employed in one embodiment.

Fig. 4 illustrates an exemplary data transfer procedure of a protocol with which the inventive embodiments can be employed in one embodiment.

Fig. 5 illustrates aspects of a streaming protocol with which the inventive embodiments can be utilized in accordance with one embodiment.

Fig. 6 illustrates aspects associated with root licenses and leaf licenses, in accordance with one embodiment.

Fig. 7 illustrates aspects associated with root licenses and leaf licenses, in accordance with one embodiment.

Fig. 8 illustrates an exemplary single media file having seven portions associated with five different exemplary digital rights management policies.

Fig. 9 illustrates the single media file of Fig. 8 with exemplary data segments associated with Key IDs (KIDs).

Fig. 10 illustrates, for a data segment shown in Fig. 9, a packet in accordance with one embodiment.

Fig. 11 is a flow diagram showing one manner in which the tools enable content-independent encryption and decryption.

Fig. 12 illustrates sample encryption in accordance with one embodiment.

Fig. 13 is a flow diagram showing communication of root and leaf licenses in accordance with one embodiment. DETAILED DESCRIPTION

Overview

Tools are described that enable a digital rights management policy to be associated with digital media having an arbitrary content type or transfer control protocol. In some embodiments, the tools encrypt data segments of a media file and add a descriptor to each of those segments. These descriptors can enable a receiver of the encrypted media file to decrypt the file and consume it according to the correct digital rights management policy.

In the discussion that follows, a section entitled "Content Security and License Transfer Protocol" is provided and describes one particular system in which the inventive techniques can be employed. Following this, sections entitled "RTSP" and "HTTP" are provided to give the reader who is unfamiliar with these protocols understanding of the inventive techniques in these spaces.

Following this section, a section entitled "Root and Leaf Licenses" is provided and describes the notion of an initial, root license enabling multiple other licenses for a media file. Following this section, a section entitled "A Single, Encrypted Media File with Multiple Leaf Licenses" is provided and describes how a media file can be associated with more than one digital rights management policy using leaf licenses associated with portions of the media file.

Following these sections, two sections, the first entitled "Descriptors" and the second entitled "Content-Independent Data Encryption" describe descriptors for data segments of a media file and manners in which the tools may use these descriptors to enable encryption of a media file regardless of its type of digital content. The last section, "Using Root and Leaf Licenses" describes one way in which the tools may use root and leaf licenses.

Content Security and License Transfer Protocol

The following provides a discussion of an exemplary protocol that provides security and transfers licenses for content flowing over digital links. This protocol constitutes but one exemplary protocol with which the various inventive techniques can be employed. It is to be appreciated and understood that other protocols can be utilized without departing from the spirit and scope of the claimed subject matter. The following cryptographic notation is used in this description:

K {data} data is encrypted with secret key K.

K[data] data is signed with secret key K.

{data}_DeVj_Ce data is encrypted with the device's public key.

[data]_Devi_ce data is signed with the device's private key.

In this particular protocol, there are five primary procedures: Registration, Revalidation, Proximity Detection, Session Establishment, and Data Transfer.

In the Registration procedure, a transmitter (i.e. a device that has content that is to be transmitted to another device) can uniquely and securely identify an intended receiver (i.e. a device to which content is to be transmitted). In this particular protocol, the transmitter maintains a database with registered receivers and ensures that no more than a small predetermined number of receivers are used simultaneously. During the registration process, the transmitter also employs a Proximity Detection procedure to ensure that the receiver is located "near" the transmitter in the network, in order to prevent wide distribution of protected content.

The Revalidation procedure is utilized to ensure that the receiver continues to be "near" the transmitter. Content is not delivered to receivers unless they have been registered or revalidated within a predetermined period of time in the past.

The Session Establishment procedure is used whenever the receiver requests content from the transmitter. The transmitter enforces that devices must be registered and recently validated before the Session Establishment can be completed.

Once the session is established, the Data Transfer of the requested content can take place in a secure way. The receiver may reuse the session to retrieve specific portions of the content (seeking), but must establish a new session in order to retrieve a different content. Consider now the Registration procedure in connection with Fig. 1 and the table just below that describes the various messages that are passed between the transmitter and the receiver during registration.

Here, the receiver sends a registration request message that contains, among other information, the receiver's digital certificate. Responsive to receiving the registration request message, the transmitter validates the receiver's certificate, generates a seed and a random session ID, returning the same in the form indicated above to the receiver in a registration response message. The receiver then validates the transmitter's signature, obtains the session ID and performs the other actions indicated in the figure. The receiver and the transmitter can then undergo a proximity detection process which is described below.

With regard to Revalidation, the same procedures as outlined above are performed, with the difference being that during Revalidation, the receiver is already registered in the database.

With regard to Proximity Detection, consider the following in connection with Fig. 2.

During the Proximity Detection procedure, the receiver sends to the transmitter a message containing the Session Id indicated in a Proximity Detection Initialization Message. The transmitter then sends to the receiver a message containing a Nonce (128-bit random value), and measures the time it takes for the receiver to reply with the nonce encrypted using a Content Encryption key. Finally, the transmitter sends a message to the receiver indicating if the proximity detection was successful or not.

The receiver may repeat the process until it has a confirmation that the proximity detection succeeded. When this particular protocol is used over IP-based networks, the proximity detection messages are exchanged over UDP. The receiver learns the transmitter's address via the Registration Response message. The receiver's address does not need to be separately communicated since it can be determined by inspecting the incoming IP header of the UDP packet that carries the Proximity Detection Initialization Message.

The following table describes the messages that are exchanged during Proximity Detection:

Message Value Description

With regard to Session Establishment, consider the following in connection with Fig. 3 and the table just below which describes messages that are exchanged during Session Establishment.

In this example, a License Request Message is sent from the receiver to the transmitter and contains the information described above. In response, the transmitter can send a License Response Message that contains the information described above.

In this particular example, the License is represented in XMR format and includes a Content Encryption key, a Content Integrity key, a Version of the Transmitter's CRL, a 128-bit Rights Id and a 128-bit Serial Number. The License also contains an OMAC calculated using the Content Integrity key using OMAC.

With regard to the Data Transfer procedure, consider the following in connection with Fig. 4. Once the Session Establishment is complete, the data transfer is executed in a control protocol specific manner. Both the Data Transfer request and response must be specifically defined for the control protocol and content type. This is conceptually represented in Fig. 4. Having now provided a brief overview of an exemplary protocol with which the inventive embodiments can be employed, consider now some background information on RTSP.

RTSP

The Real Time Streaming Protocol or RTSP is an application-level protocol for control over the delivery of continuous media (e.g., data with real-time properties like streaming), as will be appreciated by the skilled artisan. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP.

RTSP establishes and controls either a single or several time-synchronized streams of continuous media such as audio and video. It does not typically deliver the continuous streams itself, although interleaving of the continuous media stream with the control stream is possible. In other words, RTSP acts as a "network remote control" for multimedia servers.

The set of streams to be controlled is defined by a presentation description. In RTSP, there is no notion of an RTSP connection; instead, a server maintains a session labeled by an identifier. An RTSP session is in no way tied to a transport-level connection such as a TCP connection. During an RTSP session, an RTSP client may open and close many reliable transport connections to the server to issue RTSP requests. Alternatively, it may use a connectionless transport protocol such as UDP, as will be appreciated by the skilled artisan.

The streams controlled by RTSP may use RTP, but the operation of RTSP does not depend on the transport mechanism used to carry continuous media.

Consider now a typical RTSP request/response exchange in connection with Fig. 5, between a client/receiver 500 and a server/transmitter 502.

Preliminarily, the RTSP requests/responses have headers which, for the sake of brevity, are not described. In RTSP, a client/receiver 500 typically issues what is known as a DESCRIBE request which is directed to retrieving a description of a presentation or media object identified by a request URL from server 502. The server 502 responds with a description of the requested resource which is represented in the SESSION DESCRIPTION PROTOCOL (SDP). The DESCRIBE response (SDP) contains all media initialization information for the resource(s) that it describes.

Next, client 500 sends a SETUP request for a URI that specifies the transport mechanism to be used for the streamed media. In the Fig. 5 example, a SETUP request is sent for both audio and video. Client 500 also indicates, in the SETUP request, the transport parameters that it will be utilizing. A transport header in the SETUP request specifies the transport parameters acceptable to the client for data transmission. The RESPONSE from server 502 contains the transport parameters selected by the server. The server also generates session identifiers in response to the SETUP requests.

At this point, the client can issue a PLAY request which tells the server to start sending data via the mechanism specified in the SETUP. Responsive to receiving a PLAY request, the server can start streaming the content which, in this example, is the audio/video content. In this example, the streaming content is encapsulated using RTP packets and is sent over UDP, as will be appreciated by the skilled artisan.

The RTSP protocol has other methods of interest which include PAUSE, TEARDOWN, GETJP ARAMETER, SET_P ARAMETER, REDIRECT, and RECORD. For additional background on RTSP, the reader should consult the RTSP RFC, Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, available at http://www.ietf.org/rfc/rfc2326.txt. April 1998.

Root and Leaf Licenses

In the illustrated and described embodiment, the notion of a root license and leaf licenses are employed. Here, the root license is utilized to set up and securely deliver a content key (a root content key) to the client/receiver so that the client/receiver can decrypt subsequently-delivered leaf license(s). Once the root content key is securely delivered to the client/receiver, content keys for various leaf licenses {leaf content keys) can be encrypted by the server/transmitter using the root content key sent to the client/receiver. Using the root content key, the client can decrypt the leaf content keys and associated policies in the leaf licenses. Each of the leaf licenses also have a unique identifier capable of associating the leaf license with a portion of a media file. Here the unique identifier is referred to as the Key ID, or KID and for each leaf license numbered 1 to n (leaf,_!, leaf_-2, ... leaf_-n), KIDi_eaf-n.

To provide but one example of how this particular scheme can be implemented, consider the following in connection with Fig. 6. In this particular example, the system of Fig. 6 is configured to use 1024-bit RSA keys for public key cryptographic operation and 128-bit AES keys for symmetric cryptographic operations. Of course, this is provided as but one example and is not intended to limit application of the claimed subject matter.

In this example, client/receiver 600 has a public/private key pair 650 and the server/transmitter 602 has the client/receiver's public key. In this example, each of the client/receiver's public and private keys is a 1024-bit RSA key. Using the client/receiver's public key, the server/transmitter builds a root license that contains a root content key that is encrypted with the client/receiver's public key. The root content key is a 128-bit AES content key. This root license is then sent to the client/receiver. In Fig. 6, this is shown as the first communication that takes place between the client/receiver and server-transmitter, where the encrypted root content key is represented as {content key_root} _CLIENT- It is to be appreciated, however, that other communication prior to the illustrated communication can take place.

Having received the encrypted root content key from the server/transmitter, the client/receiver can now decrypt the root content key using its private key and can securely store the decrypted root content key for future use.

At this point, consider what has occurred. The server/transmitter has securely communicated a key to the client/receiver that can now serve as the basis for subsequent cryptographic operations. More specifically, consider now that multiple, particular policies may pertain to multiple, particular pieces of DRM-protected content in a single media file. In this case, the server/transmitter can prepare multiple leaf licenses each containing a digital rights management policy and an encrypted version of a particular leaf content key. In this example, each leaf content key is a 128-bit AES content key that has been encrypted using the root content key. Thus, the computational complexity and expense experienced and incurred by the client/receiver associated with decrypting new and additional leaf content keys is reduced over that associated with 1024-bit RSA key operations because now, the client/receiver only needs to decrypt using a 128-bit AES content key (i.e. the root content key).

HTTP

Having now discussed the notion of a root and leaf license and how each can be employed in the contexts described above, consider now how the root and leaf license can be delivered using HTTP.

When HTTP is utilized for carrying DRM-protected content, the client issues two requests to the server/transmitter. First, the client issues a POST request to retrieve a root license. Second, the client issues a GET request for retrieving the DRM-protected content. The client issues the requests in this example because in HTTP, the server typically cannot initiate communication with a client.

Specifically, consider Fig. 7 in connection with the following discussion. When a client wishes to receive a root license, it issues a POST request to the server. The POST request contains a license request message, as discussed above. Responsive to receiving this communication, the server responds with a license response message that contains a root license which, in at least one embodiment, is expressed in XMR. Having received the root license and processed it accordingly, the client issues a GET request to the server asking for the DRM-protected content. Responsive to the GET request, the server replies with segments of the requested content interleaved with one or more license response messages. The license response messages each contain a leaf license that pertains to a particular portion of the DRM- protected content. Any suitable mechanism or interleaving technique can be used for formulating the server's reply.

As but one implementation example in one particular context, consider the following.

In but one example, a four-byte framing header is used to encapsulate data and control blocks. The framing header contains a one byte ASCII dollar sign (0x24), followed by a one byte block type identifier, followed by a two byte length of the encapsulated data, represented in network byte order.

A Control block uses an ASCII 'c' character (0x63) as its type identifier. This block contains a message, typically a License Response message.

A Data block uses an ASCII 'd' character (0x63) as its type identifier. This block contains a Data Segment descriptor immediately followed by media data.

The Data Segment descriptor can be associated with content that is encrypted or in the clear. An encrypted flag in the descriptor conveys this information. A Data Segment descriptor is associated with a portion of the transmitted file to which, if encrypted, a single policy and content encryption key apply. In other words, the content encryption key and policies cannot be changed within the segment.

In accordance with one embodiment, a typical HTTP response with link encryption is comprised of the following blocks:

1. Control block [$c] carrying a License Response message with a Chained License.

2. One or more Data blocks [$d].

In case there is a key or policy change during the transmission of the file, then the following steps are added:

3. A new Control block [$c] carrying a License Response message with a new Chained License.

4. One or more Data blocks [$d]. Note that steps 3 and 4 may occur multiple times in the case of multiple key or policy changes.

A Single. Encrypted Media File with Multiple Leaf Licenses

The tools enable a single encrypted media file to have portions associated with different policies. The single encrypted media file may be of an arbitrary content type (e.g., ASF, MPEG, WAV, or other files) and be transferred using various control protocols.

In the following illustrated and described embodiment of Figure 8, a single, encrypted media file 800 has seven portions 802, 804, 806, 808, 810, 812, and 814. Assume that this media file is a media program about the history of music videos. The first portion is an introduction to music videos, the second is a music video, the third an advertisement, the fourth is another music video, the fifth is another music video, the sixth is another advertisement, and the seventh is a conclusion to the program.

Here the creator of the media program desires to have different rights for various portions. The creator may be willing to permit users of the media program to play the introduction and conclusion portions and copy them a certain number of times. The creator may not be willing to grant the same rights to the music videos; assume here that the creator of the program does not own these music videos, and so they are subject to different policies of use. The creator may also be willing to have the advertisements used freely — and thus they may be copied, used, and played in any way a user likes.

To govern the usage of each of these portions, each is associated with a policy. Here the policy is in a leaf license having a KID and content key. Assume that one root license and five leaf licenses are received for this media program. The leaf licenses are shown in Figure 8 at 816, 818, 820, 822, and 824. Each of the leaf licenses has a unique KID (KID₁, KID₂, KID₃, KID₄, and KID₅) and a unique leaf content key (leaf content key_h leaf content key₂, leaf content key₃, leaf content key₄, and leaf content key₅). Each leaf license also contains a policy (policy _ls policy₂, policy₃, policy₄, and policy ₅) permitting or excluding certain rights for using the media of each of the associated portions. These leaf licenses are expressed in XMR (extensible Media Rights), though other languages may also be used.

The first policy (that of leaf license #1) permits media associated with it to be played up to ten times and copied up to three times. This policy permits, therefore, the introduction and the conclusion of the program to be played and copied a certain number of times.

The second policy permits media associated with it to be played only once and not copied. Thus, the first music video of the program can only be played once. If a user attempts to play the entire program a second time, this video will not play.

The third policy permits media associated with it to be used in any way desired. The policy itself can set this out — that there are no restrictions on the play, copying, or other use of associated media. In some embodiments, however, the portions of the media may instead be in the clear (not encrypted). An example of this is described below. In either case, both the first and second advertisements may be used in any way desired.

The fourth policy permits media associated with it to by played as many times as a user likes, but cannot be copied. Thus, the second music video can be played but not copied.

The fifth policy permits media associated with it to be played as many times as a user likes and copied, but only as an analog file. Thus, the third music video may be played, and copied in a certain way only.

The association between each of the portions and the licenses are shown in Figure 8 with dashed lines. Ways in which the tools may establish this association are set forth in greater detail below.

Descriptors

The tools can associate policies with portions of a single media file. Continuing the illustrated and described embodiment of Figure 8, each of the portions is associated with a policy through a leaf license. To better explain how this association may be established, one portion of single media file 800 is illustrated in greater detail.

Fig. 9 illustrates media file 800 with fourth portion 808 expanded to show one way in which this portion can be associated with a policy. Here the media file is received with the portions generally in order. In this example the root license is received, followed by a first leaf license, followed by the first portion of the media file, followed by the second leaf license, followed by the second portion, and so on. Here the leaf licenses are not all received prior to receiving the beginning of the media file as described above. Because of this, the first and third leaf licenses may be sent again prior to the portion associated with them (thus, the first leaf license may be sent before the first portion and again before the seventh portion).

When a new policy is to be followed for a portion of the media file, a new leaf license (here fourth leaf license 822) is sent prior to the portion of the media associated with the fourth leaf license.

Here the leaf license is sent as part of a control block 902, followed by data segments 904-914 of fourth portion 808. In RTSP, however, the licenses are delivered in SDP descriptors or ANNOUNCE messages. This particular embodiment focuses on use of HTTP, though use and communication of leaf licenses and data may also use RTSP, such as is set forth in the description relating to Fig. 7 above. The control block comprises leaf license 822 of Figs. 8 and 9. The leaf license has the leaf content key₄, the policy₄, and the KED₄. Once received, the fourth leaf license can be decrypted using the root content key. The KID can be sent in the clear or encrypted but capable of being decrypted.

Each of the data segments is associated with a policy, here data segments 904- 914 are associated with the corresponding fourth policy. This association is established with the KID of the fourth leaf license. The KID, or an identifier associated with the KID, is stored in each data segment. The KID can be a relatively short piece of information, even an integer taking up less than a byte of memory. Thus, the receiver can associate the data segment with the appropriate policy based on the KID indicating the appropriate policy. The descriptor can be used with various control and data protocols and packet structures now in existence or that may be created in the future. One such exemplary data protocol is RTP. Here the descriptor is oriented appended to the end of each packet. In another embodiment, an HTTP control protocol is used. Here the descriptor is oriented appended at the beginning of each frame.

Fig. 10 illustrates a descriptor associating a data segment with a leaf license in accordance with RTSP.

In this example, data segment 1000 can include an RTP payload format header 1008 and payload data 1010. Here the payload data and payload format header are encrypted, an example of which is described as part of Fig. 11 below.

Here the descriptor is appended to the end of the payload data according the RTP protocol, though it can be placed at any suitable location permitted by the data protocol. Placing the descriptor at the end of the payload data can mitigate backward compatibility issues, as will be appreciated by the skilled artisan.

In this embodiment, the RTP packet — with the exception of the RTP header- is associated with the descriptor 1012. Descriptor 1012, in turn, carries with it the encryption parameters that can be used in a decryption process that enables payload data 1010 and RTP payload format header 1008 to be decrypted (e.g., the Initialization Vector (IV) associated with the fourth leaf content key). In this particular example, a single policy and content encryption key applies to the payload data 1010.

In accordance with one embodiment, descriptor 1012 comprises a data structure as follows:

RBπfiffla ■ IU¹IWlSJM

In this example, the Flags section is a bit-field indicating attributes of the Data Segment. The following bit is currently defined: Bit 0 (Encrypted Data.) When this bit is set to 1, it indicates that the Data Segment is in encrypted form. Otherwise, the Data Segment is in the clear.

The extension section comprises the KID and IV; here the KID is the KID₄ and the IV is associated with the leaf content key₄.

With regard to the Extensions section, the Number of Extensions field indicates the number of variable length extensions included in this descriptor. With regard to the Variable Length Extension field, each extension has the following format:

IsMfI

8-bit Extension Type

16-bit Extension Length

Variable Length Extension

In accordance with one embodiment, the KID and IV are defined as follows:

KID

Extension Type: Must be set to 1 for Key ID Extension.

Extension Length: Must be set to 16, which represents 128 bits (16 bytes).

Extension: Must contain the Key ID value for the encrypted media delivered in conjunction with this descriptor. This extension is only used when the Encrypted Data flag is set to 1.

Initialization Vector (IV)

Extension Type: Must be set to 2 for Initialization Vector Extension.

Extension Length: Must be set to 8, which represents 64 bits (8 bytes).

Extension: Must contain the Initialization Vector for the encrypted media delivered in conjunction with this descriptor. This extension is only used when the Encrypted Data flag is set to 1. With regard to the Length section, in this embodiment, this section must contain the total length of the descriptor in bytes. This length does not include the size of the media data delivered in conjunction with this descriptor.

Content-Independent Data Encryption

Fig. 11 is a flow diagram that describes steps in a method in accordance with one embodiment. This method can be performed in connection with any suitable hardware, software, firmware or combination thereof. In one embodiment, the method can be implemented in connection with systems, such as those illustrated and described above. Additionally, in the discussion that follows, some of the acts that are performed are depicted as being performed by a server/transmitter, and other acts are depicted as being performed by a client/receiver. Examples of server/transmitters and client/receivers are provided above.

Step 1102 receives a media file. The media file can have any content type permitting the media file to be broken into data segments, encrypted, transmitted, received, and decrypted. It can be, for instance, an ASF, MPEG2 TS, MPEG2 ES, or WAV file.

Step 1104 divides the media file into data segments. These data segments can comprise packets, other pieces of data, or frames conforming to various controls protocols, such as RTP or HTTP.

Step 1106 encrypts each data segment. Step 1106 may do so according to any of the embodiments described herein. Thus, it may encrypt the payload data with a leaf content key and encrypt that leaf content key with a root content key. With the root content key, a receiver may later decrypt the leaf content key and use that leaf content key to decrypt the payload data.

In one embodiment, step 1106 encrypts each data segment or part thereof using an AES in Counter mode. Fig. 12 illustrates a process for encrypting a single data segment using this technique. In this embodiment, Counter mode creates a stream of bytes that are then XOR' d with the clear text bytes of the data segment to create the encrypted data segment. The Key Stream Generator uses an AES round to generate 16-byte blocks of key stream at a time. The inputs to the AES round are the Content Encryption key (Kc) (e.g., the leaf content key) and the 128-bit concatenation of a Data Segment ID and the block number within the data segment.

The output of key stream generator should be XOR' d byte by byte with the data from the corresponding block (i) of the data segment. In the case that the data segment is not evenly divisible by 16 bytes only the valid bytes of the media data from the last block should be XOR' d with the key stream and retained for the encrypted data segment.

Step 1108 adds a descriptor to each encrypted data segment. The descriptor can comprise a KID, IV, or other elements set forth herein. Each descriptor indicates an associated digital rights management policy by which the payload data of the data segment should be governed. This digital rights management policy, according to one embodiment above, is contained within a previously-received leaf license. Each descriptor can also indicate a content key (e.g., a particular leaf content key) usable to decrypt the data segment.

Note that the result of these steps can be a media file of an arbitrary content type broken into data segments, each data segment encrypted and having a descriptor by which the encrypted data can later be associated with a digital rights management policy.

In one embodiment, the descriptor contains a length indicator. With this length indicator, a receiver of an encrypted data segment can determine when the descriptor ends or begins. This length indicator permits the descriptor to be added to an encrypted data segment at various locations in the data segment or its packet. For the RTP protocol, for instance, the descriptor is added to the end of an RTP packet having the data segment. For the HTTP protocol, for instance, the descriptor is added to the beginning of the frame having the data segment. Note that the descriptor, by having a discernable length, can be added to various portions of a data segment and thus enable use of the descriptor with various transfer protocols.

Step 1110 transmits the encrypted data segments (and clear data segments, if any) with descriptors to a receiver. The receiver is enabled to orient (e.g., place in correct order) the data segments in manners known in the art. The receiver may decrypt the data segments using a content key associated with the data segments. Further, the receiver, using the descriptor, pan determine what rights policy should be used with the media file or a portion thereof. If the media file has portions that should be governed by different rights policies, this method can also divide the data segments based on their portion of the media file and assign different descriptors to data segments of different portions in step 1104.

Step 1112 receives and decrypts the encrypted data segments. A receiver (such as client/receiver 500 or 600) decrypts the data segments and assigns the appropriate rights policy to them based on their descriptor. In one embodiment, the receiver decrypts the data segments using an Initialization Vector in the descriptor. The receiver determines the appropriate leaf content key based on the KID, which it then uses to decrypt the data segments after decrypting the leaf content key with a root content key.

Step 1114 associates each data segment with a rights policy. In one embodiment, the receiver does so using a Key ID (KID) found in the descriptor and in the leaf license having the rights policy.

Using Root and Leaf Licenses

Fig. 13 is a flow diagram that describes steps in a method in accordance with one embodiment. This method can be performed in connection with any suitable hardware, software, firmware or combination thereof. In one embodiment, the method can be implemented in connection with systems, such as those illustrated and described above. Additionally, in the discussion that follows, some of the acts that are performed are depicted as being performed by a server/transmitter, and other acts are depicted as being performed by a client/receiver. Examples of server/transmitters and client/receivers are provided above.

Step 1300 encrypts a root content key using a public key of a client/receiver. Any suitable content key can be utilized with but one example being given above. Step 1302 sends a root license containing the encrypted root content key to a client/receiver. Any suitable method can be utilized to implement this step. In the discussion that follows, two specific examples that draw upon two different protocols are provided. It is to be appreciated and understood that these constitute examples and are not intended to limit application of the claimed subject matter to only the specific protocols that are described.

Step 1304 receives the root license sent by the server/transmitter and step 1306 decrypts the enciypted root content key. In this example, this step is performed by using the client/receiver's private key to decrypt the encrypted root content key.

Step 1308 prepares a leaf license and encrypts a leaf content key with the root content key. Step 1310 sends the leaf license to the client/receiver. Recall that the leaf license can and typically does contain policies for DRM-protected content. It should be understood and appreciated that steps 1308 and 1310 can be executed multiple times for a given piece of DRM-protected content. That is, for each portion having a different policy, a corresponding leaf license can be prepared and sent to the client/receiver.

Step 1312 receives the leaf license and step 1314 decrypts the leaf content key using the root content key that was previously received. Step 1316 then uses the decrypted leaf content key to decrypt content. It also associates the appropriate leaf license with a portion of the media file (if the media file has portions) using a descriptor described above.

It is to be appreciated and understood that steps 1312, 1314 and 1316 can be performed for each new leaf license that is received by the client/receiver.

Conclusion

This document describes techniques by which a digital rights management policy may be associated with digital media having an arbitrary content type or transfer control protocol. In some cases this enables a receiver of an encrypted media file to decrypt the file and consume portions of the file according to different digital rights management policies. In some cases this also permits a transmitter to encrypt many different types of media files with one set of techniques. Although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are disclosed as preferred forms of implementing the claimed invention.

Claims

1. A computer-implemented method comprising: encrypting data segments of a media file having an arbitrary content type to provide encrypted data segments; and adding descriptors to the encrypted data segments, each encrypted data segment's descriptor indicating an associated digital rights management policy for the encrypted data segment and Key ID usable to decrypt the encrypted data segment.

¹ 2. The method of claim 1, wherein the act of encrypting encrypts the data segments using an AES in counter mode.

3. The method of claim 1 , wherein the descriptors comprise Initialization Vectors, each encrypted data segment's Initialization Vector associated with the content key usable to decrypt the encrypted data segment.

4. The method of claim 1, wherein each descriptor has a Key ID that is also in its associated digital rights management policy.

5. The method of claim 1, wherein each encrypted data segment's descriptor comprises a length indicator enabling differentiation between the encrypted data segment and its descriptor.

6. The method of claim 1 , wherein the media file comprises a first portion and a second portion, the first portion associated with a first digital rights management policy and the second portion associated with a second digital rights management policy, and wherein the act of adding adds a first descriptor indicating the first digital rights management policy to encrypted data segments of the first portion and adds a second descriptor indicating the second associated digital rights management policy to encrypted data segments of the second portion.

7. The method of claim 1 , wherein the encrypted data segment comprises a packet conforming to an RTP data protocol or a frame conforming to an HTTP protocol.

8. The method of claim 7, wherein the act of adding concatenates the descriptor to the end of the encrypted data segment if the encrypted data segment comprises a packet conforming to an RTP protocol or the beginning of the encrypted data segment if the encrypted data segment comprises a frame conforming to an HTTP protocol.

9. A system comprising one or more computer-readable media, the computer-readable media comprising a digital media file comprising data segments, each data segment added to a descriptor and comprising encrypted payload data, each data segment's descriptor having encryption parameters enabling decryption of the data segment's payload data and association of the data segment's payload data with a digital rights management policy.

10. The system of claim 9, wherein each descriptor's encryption parameters comprise a Key ID also comprised by the digital rights management policy.

11. The system of claim 9, wherein each data segment's payload data is encrypted using a content key and the data segment's descriptor comprises a Key ID associated with the content key, the content key usable to decrypt the payload data.

12. The system of claim 9, wherein the digital media file further comprises first and second portions, the first portion having first data segments and the second portion having second data segments, at least one of the first data segment's descriptors enabling the first portion to be associated with a first digital rights management policy and at least one of the second data segment's descriptors enabling the second portion to be associated with a second digital rights management policy.

13. The system of claim 9, wherein each data segment's payload data is encrypted and its descriptor is not.

14. The system of claim 9, wherein the digital media file further comprises a data segment added to a descriptor and comprising clear payload data, the data segment's descriptor enabling association of the data segment's¹ clear payload data with another digital rights management policy.

15. The system of claim 9, wherein the digital media file is streaming media.

16. A computer-implemented method comprising: transmitting an encrypted media file having a first portion and a second portion to a receiver; enabling the receiver of the encrypted media file to decrypt the first portion and the second portion; and enabling the receiver to associate the first portion with a first rights policy indicating permitted usage of the first portion, and the second portion with a second rights policy indicating permitted usage of the second portion.

17. The method of claim 16, further comprising transmitting the first rights policy and the second rights policy to the receiver.

18. The method of claim 16, wherein the act of enabling the receiver to associate builds a first descriptor into the first portion and a second descriptor into the second portion, the first descriptor indicating that the first portion is associated with the first rights policy and the second descriptor indicating that the second portion is associated with the second rights policy.

19. The method of claim 18, wherein the act of enabling the receiver to decrypt builds a first Key ID into the first descriptor and a second Key ID into the second descriptor, the first Key ID usable to decrypt the first portion and the second Key ID usable to decrypt the second portion.

20. The method of claim 16, further comprising receiving a media file of an arbitrary content type and encrypting the media file to provide the encrypted media file.