Patent Application
20090285401
Key management systems typically employ messages known as entitlement control messages (ECMs) and entitlement management messages (EMMs) to control access to data streams. EMMs are control messages that convey access privileges and keys to subscriber devices. Unlike ECMs, which are embedded in transport multiplexes and are broadcast to multiple subscribers, EMMs are typically sent unicast-addressed to each subscriber device. That is, an EMM is usually specific to a particular subscriber.
For example, typically, each subscriber based on his or her access type receives an appropriate key in an EMM. For example, monthly subscribers to a channel receive an EMM which delivers a key valid for a full month, while subscribers to a smaller time portion of a channel or service would receive their EMM which delivers a less broad-in-time key, and pay per view subscribers would receive an EMM which delivers only the lowest level program specific key.
Conventionally, a separate ECM is employed for each service offering for different levels of subscribers based on their level of access. For example, there may be one ECM for monthly subscribers, and another for pay-per-view, or equivalently, a single much longer ECM. However, this wastes bandwidth and is often problematic in systems where bandwidth is an issue. Many conditional access systems, such as mobile TV systems, have very little bandwidth, yet still need to be sufficiently flexible to support a wide variety of access types.
Features of the present invention will become apparent to those skilled in the art from the following description with reference to the figures, in which:
For simplicity and illustrative purposes, the present invention is described by referring mainly to exemplary embodiments. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. However, it will be apparent to one of ordinary skill in the art that the present invention may be practiced without limitation to these specific details. In other instances, well known methods and structures have not been described in detail to avoid unnecessarily obscuring the description of the embodiments.
In an embodiment of the present invention, authorized access to content to a device is provided by providing the same entitlement control message (ECM) to multiple devices. An entitlement management message (EMM) delivering a service key is also provided to the multiple devices. The ECM includes a single encrypted traffic key for decrypting content at each of the multiple devices. Each of the multiple devices derives an access key from its EMM delivered service key and the ECM, according to a business model level of access to the content for a user of the device, and uses the access key to decrypt the traffic keys to access the content.
In an embodiment, a request for access to content is received from a first device and an EMM including a service key appropriate to the requested level of access as well as an ECM including an encrypted traffic key for decrypting content in the first device is provided. A request for access to content is received from a second device and an EMM including a service key appropriate to the requested level of access as well as the same ECM that is provided to the first device is provided for decrypting content in the second device.
In a conditional access system, each content stream is associated with a stream of ECMs that serves two basic functions: (1) to specify the access requirements for the associated content stream (i.e., what privileges are required for access for particular programs); and (2) to convey the information needed by subscriber devices to compute the cryptographic key(s), which are needed for content reception. ECMs are transmitted in-band alongside their associated content streams. Typically, in traditional CA systems, ECMs are cryptographically protected by a “monthly key”, which changes periodically, usually on a monthly basis. The monthly key is typically distributed by EMMs prior to or concurrently with the ECMs.
EMMs are control messages that convey access privileges and keys to subscriber devices. Unlike ECMs, which are embedded in transport multiplexes and are broadcast to multiple subscribers, EMMs are typically sent unicast-addressed to each subscriber device. That is, an EMM is specific to a particular subscriber. In a typical implementation, an EMM contains information about the monthly key, as well as information that allows a subscriber device to access an ECM, which is sent concurrently or later. In an embodiment of the present invention, EMMs also define the level of subscription for each subscriber. With reference to cable services, for example, a first EMM may allow access to HBO™, ESPN™, and CNN™. A second EMM may allow access to ESPN™, TNN™, and BET™, etc. A third EMM for a different subscriber may allow access to a 24-hour period for ESPN. A fourth EMM may allow access to a specific event (program) of TNN. These are examples of different services and different business model levels of access to the content for the services.
The system 100 includes a service provider 110, a wireless transmission network 120, such as a Wireless Wide Area Network (WWAN), WiMax, 3GPP, terrestrial or a satellite transmission network, and a landline transmission network 130, such as a Wide Area Network (WAN), DSL, fiber or a cable network. The system 100 also includes a plurality of devices 140a-140n and 150a-150n for users to receive content from the service provider 110 via the satellite transmission network 120 and via the landline transmission network 130, respectively. As referred herein, content provided to users includes any audio or video data or information, such as streamed audio services, streamed video services, streamed data services or files that are broadcast using a protocol such as File Delivery over Unidirectional Transport (FLUTE). As also referred herein, a user is an individual, a group of individuals, a company, a corporation, or any other entity that purchases, subscribes, or is authorized otherwise to receive access to one or more particular content services. Examples of users include but are not limited to Cable TV (CATV) subscribers, satellite TV subscribers, satellite radio subscribers, IPTV subscribers, and Pay-Per-View (PPV) purchasers of PPV events. As also referred herein, a PPV event is a particular content program for which a user is charged when or just before such content is accessed.
As further referred herein, a service provider is an individual, a group of individuals, a company, a corporation, or any other entity that distributes content to one or more users. Examples of service providers are CATV, satellite TV, satellite radio, wireless mobile service provider, and online music providers or companies. In turn, the service provider receives content from one or more content providers (not shown), such as film studios, record companies, television broadcasting networks, etc. It should be noted that a content provider is also operable as a service provider to directly provide its content to users in the same manner as shown for the service provider 110 in
As referred herein, EMMs are the messages delivering service keys. An access key is derived from service keys, such as a long-term key, a short-term key and a program key. To use a single access key to encrypt a traffic key for all the services, according to an embodiment of the present invention, a hierarchy of keys is employed to minimize the length of the ECMs.
Long-term key (LTK) 210 is a subscription service key that allows access to particular content for a specific length of time. Typically, the length of time is based on a monthly subscription schedule. However, the length of time may be longer than a month. The LTK 210 typically changes based on the designated billing cycle of every subscription (i.e., monthly) and is unique for each content service. A content service or service may be a single channel, and thus have its own long-term service key, or it may be a group of channels, such as the “basic” package, where the same LTK 210 service key is used for all channels within the basic package. As each subscriber may choose a different set of channels to view, multiple LTKs 210 may be delivered to the subscribers. For example, the channels in a basic service package may use the same long-term key LTK0 210. HBO™ channels for premium service may use LTK1 210. As such, the basic service subscribers will get LTK0 210 only and the premium service subscribers will get both LTK0 210 and LTK1 210. In this example, all of the long-term keys are updated during each billing period. In addition, only the subscribers who continue their service subscription get the updated LTKs 210. If the user stops his subscription, the device will not receive the LTK 210 for that subscription. Consequently, the device will be unable to derive the program key and access the content.
The LTK 210 may be used to derive a short-term key (STK) 230, which allows access to content for a short period. STK 230 is only valid within a short-term subscription interval to provide the short-term subscription service, such as a one-day subscription (this is a variant of a pay-by-time service). The STK 230 would change in every short-term subscription interval and is also unique for each content service. The service provider may define the minimum time interval for short-term subscription, for instance, from 3 to 24 hours. If the short-term subscriber purchases multiple time intervals, multiple STKs 230 will be delivered to the short-term subscriber. Each STK 230 is associated with a different Short-Term Label (STL) identifier 220 and derived by the LTK 210 and STL 220, according to an embodiment of the present invention. If the subscriber has selected short-term services on different channels, multiple STKs 230 may be delivered to that subscriber.
When a user receives an EMM containing the long term service key, the LTK can be identified by its service ID and a long term interval number. This number may start from 0 and increment by 1 for every long-term interval. The same service ID and number are delivered in the ECM corresponding to that service.
When a user receives an EMM containing an STK, the STK can be identified by the combination of the Service ID, and the long term interval number, and a short term interval number. This last number is an ID for each short-term interval within a long-term interval. It may start from 0 and increment by 1 for each short-term interval. Once a new long-term subscription period starts, it may be reset to zero and restart again. This short term number is also delivered in the ECM corresponding to that service.
When a user receives an EMM containing the program key, the program key can be identified by a channel number and a program number. The program number may start from 0 and is incremented by 1 for each program on a channel. When a new long term interval starts, it may be reset to zero and restart again. The channel number and program number are also delivered in the ECM corresponding to that service.
The Short-Term Label for a short-term subscription interval will be used in deriving the STK. It includes: (a) the service ID, (b) the long term interval number, and (c) the short-term interval number.
The STK derivation process uses the STL as input to an Advanced Encryption Standard (AES) encryption function, with the LTK as the encryption key. The resulting encrypted data is the STK. Users that receive the STK cannot reverse this process since they do not have the LTK. Therefore, by purchasing a short term service, a user cannot gain access to the higher level LTK and thus gain access to the entire service. Other one-way cryptographic functions may be used for deriving keys. Short-term subscribers receive the STK in their EMMs while long-term service subscribers have to derive the STK using the LTK they received in their EMM and the STL information received in the common ECM.
The STK 230 may be used to derive a program key (PK) 250. The PK 250 is a key used to decrypt the traffic keys for each program. The PK 250 changes for each program. The PK 250 is also unique for each program. The PK 250 may be derived from the STK 230 using the Program Label (PL) 240 received in the ECM. The PL 240 includes channel number and program number, and may include other program related information, such as copy protection information (e.g., one byte of CCI bits), blackout information, and control information. A short-term subscriber may derive a program key 250 using the STK 230 to get traffic keys (TKs) 260. Finally, the TK 260 is the key to decrypt the content 270. The TK 260 may change as often as once every second.
Users that purchased a single program will receive the PK in their EMMs while long-term and short-term service subscribers have to derive the PK using the STK they derived from LTK or received in their EMMs, respectively, and the PL information received in the common ECM.
The PK derivation process uses the PL, including optionally some other service or program related data, as an input to an AES encryption function, using the STK as the encryption key. The resulting encrypted data is the PK. Users that receive the PK cannot reverse this process since they do not have the STK. Therefore, by purchasing a single program (or event), a user cannot gain access to the higher level keys such as the STK or LTK and thus gain access to content he did not pay for.
Note that the TK in the ECM may not be encrypted by the PK directly. Instead, there may be an intermediate key called the access key 255 which decrypts the encrypted TK. In this case, the PL above includes only the program number and the channel number, and any other program related data, such as Copy Control Information (CCI), Program Control Information (PCI), Blackout Information (BI) (if present) and other data, is input into another AES based key derivation step as program data 245. This derivation is designed to provide CCI, PCI, and BI authentication for the ECM messages.
Program data 245 can in general be extended to include any data that needs to be authenticated for the content or program. As shown, by way of example, the program data 245 is used in conjunction with the program key 250 to derive the access key 255. Using the access key 255, the encrypted traffic key 257 may be decrypted to get the TK 260 and using the TK 260, the encrypted content 265 may be decrypted and a user may access the content 270.
Here, three levels of services have been described: long-term subscription, short-term subscription and PPV. The different levels of services are referred to as different business model levels or access types. Each business model level has different EMMs, which include Long-term subscription EMM, Short-term subscription EMM, and PPV EMM. The Long-term subscription EMM has to be delivered to all subscribers every month. By way of example, if the service provider has tens of millions of subscribers and each message has to be broadcast many times, vast amount of bandwidth will be required. The short-term subscription EMM is only delivered to the short-term service subscribers after they have purchased short-term subscription service. The short-term subscription EMM includes the STL 220 and the STK 230 for the time intervals that the purchaser is allowed to access the content. Here the STL 220 is used as an ID for the STK 230. The PPV EMM is only delivered to PPV users after they have purchased the PPV service. The PPV EMM includes the PL 240 and the PK 250 for the program the user purchased. Here the PL 240 is also used as an ID for the PK 250.
An embodiment of a method in which the system 100 may be employed for providing authorized access to content to a device will now be described with respect to the flow diagrams of the methods 300 and 400 depicted in
At step 310, EMMs are provided to the multiple devices. Here, one EMM may be provided to one device or one EMM may be provided to a group of devices. Each EMM includes at least one service key for one or more devices. The EMM is typically delivered uniquely to each of the multiple devices, with a service key corresponding to the purchased access model.
At step 320, an ECM is provided to the multiple devices. Although each of the multiple devices may have different business model levels of access to the content, the ECM provided to the multiple devices here is the same ECM for every device. The ECM includes an encrypted traffic key for decrypting content.
At step 330, each of the multiple devices derives one access key using the key delivered in the EMM and ECM according to the business model level of access to the content for a user of the device. For instance, a user who purchased a single event (or program) will receive the PK in his EMM and will have to derive from the ECM the access key. A subscriber to the entire service will receive an LTK in his EMM and will have to derive the STK first, then the PK and finally the access key.
At step 340, each of the multiple devices uses the key derived in step 330 to decrypt the traffic key(s) to access the content according to its own business model level of access to the content. In this step, the traffic keys are common to the multiple devices and each of the service keys is used for the appropriate business model level of access to the content.
Here, examples of the different business model levels of access to the content are a long-term subscription, a short-term subscription, and access to a single program. The short-term subscription has a shorter period of subscription than the long-term subscription, such as a weekly subscription or a daily subscription, whereas the long-term subscription has a monthly subscription or a yearly subscription. Examples of the service key are the long-term key 210, the short-term key 230, and the program key 250 in
At step 410, a request for access to the content is received at the service provider from multiple devices.
At step 420, an EMM is provided to each of the multiple devices. The EMM includes a service key for each device.
At step 430, an ECM is provided to the multiple devices. Each ECM includes a single encrypted traffic key for decrypting content. The ECM is typically provided continuously with the content, while the EMMs are delivered on request (step 410) or in advance.
At step 440, the device determines the business model level of access to the content for a user of the device as a long-term subscription, a short-term subscription, or access to a single program.
At step 450, if the business model level of access to the content for a user of the device is a long-term subscription, the device receives the LTK 210 from the EMM, and the device may derive the STK 230 and the PK 250 using the STL 220 and the PL 240 received from the ECM.
At step 460, if the business model level of access to the content for a user of the device is a short-term subscription, the device receives the STK 230 from the EMM, and the device may derive the PK 250 using the PL 240 received from the ECM.
Finally, at step 470, if the business model level of access to the content for a user of the device is access to a single program, the device receives the PK 250 from the EMM.
In step 480, each device derives the access key and, in step 490, decrypts the TK delivered in the ECM such that they all can decrypt the actual content. Here, each step of steps 450, 460, and 470 is operable as a one-way process or a one-way function and there is no return path available from lower level of business model service key to higher level of business model service key in the access key hierarchy.
It should be noted that the steps are repeated for each ECM for a particular time interval. For example, an ECM may be delivered for a traffic key that can be used to access a few seconds of content. Then, another ECM is delivered to access the next interval of time content, and so on. The method 400 can be used to derive the access key for each ECM for each time interval.
The secure hardware module 550 contains a security processor 551, a secure code 535, and a memory 560, such as a computer readable medium. In one embodiment, the secure hardware module 550 is a secure silicon hardware device, such as a tamper resistant silicon microchip. The security processor 551 is a secured processor that handles the processing functions for the secure hardware module 550, such as the execution of the one-way function (OWF) 555 used to produce the PK 250 or the STK 230 to decrypt the traffic key 260 as described earlier. The secure code 535 is a portion of the secure hardware module 550 that comprises various software code and applications that is executed by the security processor 551. Notably, one secure code 535 includes the OWF 555. As described earlier, it is possible to implement the access key hierarchy 200 as a computer-readable data structure that is implemented on a computer readable medium, such as the memory 560 in the secure hardware module 550. This ensures the security of the various encryption/decryption keys within the secure hardware module 550. In an alternative embodiment, a public/private key pair and associated digital certificate are stored on the smart card, and keys in the lower levels, such as service keys including a long-term key, a short-term key, a program key, and a traffic key are derived and stored in the memory 560.
The computer system 600 includes a processor 620, providing an execution platform for executing software. The processor 620 is configured to provide an EMM including a service key to the plurality of devices. The processor 620 is further configured to provide a same ECM to the plurality of devices. The ECM comprises a single encrypted traffic key for decrypting content. The EMM generation software may run on a different computer system or processor than the ECM generation function. The computer system 600 may also include a secure Database for storing service, program and user related information including the LTKs and UKs. The computer system 600 may also include a HW security module to protect the ECM and EMM key derivation algorithms and to improve performance of the encryption or decryption functions.
Commands and data from the processor 620 are communicated over a communication bus 630. The computer system 600 also includes a main memory 640, such as a Random Access Memory (RAM), where software may reside during runtime, and a secondary memory 650. The secondary memory 650 may include, for example, a nonvolatile memory where a copy of software is stored. In one example, the secondary memory 650 also includes ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and other data storage devices, include hard disks. The main memory 640 as well as the secondary memory 650 may store the EMM, the ECM, the access key, the traffic key, and the business model levels.
The computer system 600 includes I/O devices 660. The I/O devices 660 may include a display and/or user interfaces comprising one or more I/O devices, such as a keyboard, a mouse, a stylus, speaker, and the like. A communication interface 680 is provided for communicating with other components. The communication interface 680 may be a wireless interface. The communication interface 680 may be a network interface. The communication interface 680 is configured to receive requests for EMMs and to send the EMMs and the ECMs.
Although described specifically throughout the entirety of the instant disclosure, representative embodiments of the present invention have utility over a wide range of applications, and the above discussion is not intended and should not be construed to be limiting, but is offered as an illustrative discussion of aspects of the invention.
What has been described and illustrated herein are embodiments of the invention along with some of their variations. The terms, descriptions and figures used herein are set forth by way of illustration only and are not meant as limitations. Those skilled in the art will recognize that many variations are possible within the spirit and scope of the invention, wherein the invention is intended to be defined by the following claims and their equivalents in which all terms are mean in their broadest reasonable sense unless otherwise indicated.
The present application is related to provisional U.S. Patent Application Ser. No. 61/054,373 (Attorney Docket No. BCS05115), titled “Improved Cipher Conditional Access System And Method”, filed May 19, 2008, which is incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61054373 | May 2008 | US |
