WO2008154283A1 - Procédés et appareils de réalisation d'une gestion des droits numériques (drm) dans un dispositif hôte par l'utilisation d'un système drm téléchargeable - Google Patents

Procédés et appareils de réalisation d'une gestion des droits numériques (drm) dans un dispositif hôte par l'utilisation d'un système drm téléchargeable Download PDF

Info

Publication number
WO2008154283A1
WO2008154283A1 PCT/US2008/065897 US2008065897W WO2008154283A1 WO 2008154283 A1 WO2008154283 A1 WO 2008154283A1 US 2008065897 W US2008065897 W US 2008065897W WO 2008154283 A1 WO2008154283 A1 WO 2008154283A1
Authority
WO
WIPO (PCT)
Prior art keywords
processor
drm
ddrms
encrypted
host
Prior art date
Application number
PCT/US2008/065897
Other languages
English (en)
Inventor
George T. Hutchings
Original Assignee
General Instrument Corporation
Depietro, Mark G.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by General Instrument Corporation, Depietro, Mark G. filed Critical General Instrument Corporation
Publication of WO2008154283A1 publication Critical patent/WO2008154283A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/603—Digital right managament [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management

Definitions

  • the invention relates to digital rights management (DRM). More particularly, the invention relates to enabling different types of DRM systems to be used by various types of host devices, such as, for example, a set-top box (STB) or similar device without having to implement DRM system-specific code in the host processor of the host device.
  • DRM digital rights management
  • Digital rights management generally refers to systems and technologies used to control access to and distribution of digital information, such as digital content.
  • DRM generally includes three components: expression, authentication and protection.
  • Expression typically involves the description of the content, the ownership of the content, and the terms and conditions of use of the content.
  • Authentication typically involves some form of verification that a user of the content has the right to use the resources.
  • Protection typically involves mechanisms, such as encryption and digital keys, used to prevent unauthorized persons from accessing the content.
  • Many user devices such as STBs, wireless telephones, personal digital assistants (PDAs), laptop computers, and personal computers (PCs), have the capability of rendering content (e.g., movies, video games, music, audio books, audio news articles, image files, text files, etc.).
  • Content is distributed by a content provider to various types of user devices over various types of networks.
  • the user devices typically have one or more content Tenderers on them, such as media player application programs, which render the content (e.g., display the content on a display device and/or playback the content on an audio playback device).
  • a cable television provider or multiple service operator may allow a user (typically a paying customer) to download or stream a movie to the user's STB that the user then watches on a display device of, for example, a television set, a laptop computer, a wireless telephone, etc.
  • an Internet online service may allow a user (typically a paying customer) to download content files, such as new articles, video games, music, etc., to a user device for playback or rendering by an appropriate media player program residing on the user device.
  • CA conditional access
  • Most CA systems encrypt digital content so that the content can only be accessed by equipment at the subscriber's premises that has the proper hardware and/or software configuration for decrypting the digital content stream. Therefore, the CA system can be viewed as having a first portion external to the subscriber premises somewhere in the network that encrypts the digital content stream, and a second portion located at the subscriber's premises, which decrypts the digital content stream to enable the subscriber to acquire the service.
  • the second portion is typically located in a STB at the subscriber's premises, but may also be incorporated into a Cablecard or Smartcard that interfaces with a digital cable-ready television or other device.
  • DCASs downloadable CA systems
  • STBs downloadable CA systems
  • DRM downloadable CA systems
  • Such DCASs have not, however, been proposed for use specifically in DRM.
  • DCAS technology eliminates the need to implement a particular CA-system specific hardware architecture in the STB or in a cable card at the subscriber's premises in order to decrypt the encrypted content stream.
  • a CA system software module is securely downloaded from the network to the subscriber's STB.
  • the downloaded software module is executed by a programmable secure processor within the STB to enable the STB to decrypt the digital content stream to enable the user to access the content.
  • FIG. 1 illustrates a block diagram of a known proposed DCAS configuration intended to be employed in a STB 11.
  • a host processor 12 of the STB 11 is programmed to execute a DCAS kernel that is specific to the particular CA system to be used.
  • the STB 11 sends a request to download a DCAS software module to a downloading facility 14, which is typically operated by the network operator that services the subscriber's premises.
  • the DCAS software module transmitted in response to the request is downloaded to the STB 11.
  • the downloaded DCAS software suite is made up of separate modules that are executed by a secure processor 13 and the host processor 12.
  • the CA system software module executed by the host processor 12 controls sending and receiving of messages and commands to and from the secure processor 13 and to and from a transport processor 15.
  • the CA system software module executed by the secure processor 13 responds to messages from the host processor 12.
  • Commands received by the transport processor 15 from the host processor 12 are performed by the transport processor 15 to cause the transport processor 15 to configure itself to look for particular Entitlement Control Messages (ECMs) and Entitlement Management Messages (EMMs) that are transported either as part of the encrypted content stream, or in logically-related data streams.
  • ECMs Entitlement Control Messages
  • EMMs Entitlement Management Messages
  • the ECM contains access criteria and a CAS-encrypted content decryption key called a control word (CW).
  • CW control word
  • the EMM is an encrypted message that contains private conditional access information about the authority a subscriber has to acquire content.
  • the transport processor 15 locates the EMM and ECM, it forwards these messages to the host processor 12.
  • the host processor 12 forwards the ECM and EMM to the secure processor 13, which is executing the downloaded CA system software module.
  • the secure processor 13 checks the EMM to determine whether the subscriber is authorized to access the content. If so, the secure processor 13 decrypts the ECM and obtains the CW, which is then sent to the host processor 12.
  • the host processor 12 sends the CW to the transport processor 15, which it uses to decrypt the content. If the EMM does not indicate that the subscriber has authorization to access the content, the encrypted content will not be decrypted.
  • DCAS technology One of the disadvantages of the DCAS technology described above is that the host processor 12 must be configured to execute some portion of the DCAS kernel. Different STBs use different types of host processors. Therefore, a DCAS kernel designer is faced with potentially having to design a different DCAS kernel for each different type of host processor, which increases the amount of work and the costs associated with implementing a given DCAS.
  • Another disadvantage of the DCAS technology described above is that it allows CA system-specific code to reside in the host processor 12. This increases the observability of certain aspects of the CA system, and could potentially lead to the disclosure of security vulnerabilities that may be exploited by individuals who are attempting to break the CA system to gain unauthorized access.
  • Another disadvantage of the DCAS technology described above is that because specific code must reside on the host processor, the code cannot be written only once, but must be ported for each instance of the host processor and operating system that will be encountered in the field.
  • FIG. 1 illustrates a block diagram of a known proposed DCAS.
  • FIG. 2 illustrates a block diagram of the DDRM CAS in accordance with one illustrative embodiment.
  • FIG. 3 illustrates a block diagram of the configurable secure (CS) processor shown in FIG. 2 in accordance with an illustrative embodiment.
  • FIG. 4 illustrates a block diagram of the DDRMS in accordance with an embodiment, wherein the host processor and CS processor are integrated in a single integrated circuit.
  • FIG. 5 illustrates a flowchart that represents the CAS method performed by the CS processor shown in FIG. 3.
  • FIG. 6 illustrates a flowchart that represents the DRM method performed by the CS processor shown in FIG. 3.
  • FIG. 7 illustrates a block diagram of host device having components that are configurable to execute a DDRMS.
  • DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS [0018]
  • FIG. 2 illustrates a block diagram of a host device 20 having components that are configurable to execute a downloadable digital rights management conditional access system, hereinafter referred to as a DDRM CAS.
  • the DDRM CAS comprises a CA domain and a DRM domain.
  • the CA domain relates to operations performed by components of the host device 20 to decrypt and render content of the type that is normally protected by CA systems.
  • the DRM domain relates to operations performed by components of the host device 20 to decrypt, encrypt and render content of the type that is normally protected by DRM systems.
  • the processes associated with performing operations in these two domains may be mutually exclusive or they may be integrated into a single CA process, as will be described below in detail.
  • the host processor 30 of the host device 20 does not execute any CAS-specific or DRM-specif ⁇ c code. Rather, all CAS-specific code and DRM- specif ⁇ c code is implemented in a configurable secure (CS) processor 40 of the host device 20.
  • the CS processor 40 and the host processor 30 are in communication with each other via a communications channel 50. Benefits associated with implementing all DRM-specific code and all CAS-specific code in the CS processor 40 rather than in the host processor 30 are described below in detail.
  • DDRMS downloadable DRM system
  • the DDRMS will likely be used in combination with a DCAS because programming is typically protected by some type of a CAS.
  • the DDRMS may be used without a CAS, as will be described below with reference to FIG. 7. For example, if the content was being delivered to a host device such as a PC from a server on a network, the content will typically be protected by a DRM system, but not by a CAS.
  • the DDRMS will typically be downloaded to the PC, but a DCAS will not.
  • the DDRMS will be described as being used in conjunction with a DCAS.
  • the DCAS is downloaded prior to downloading the DDRMS, or concurrently therewith.
  • the host device 20 sends a request to download a DCAS software module to the DCAS downloading facility 14, which may be the same as the DCAS downloading facility 14 shown in FIG. 1.
  • the DCAS downloading facility 14 transmits a DCAS software module to the STB 20, which is downloaded into the CS processor 40 of the invention.
  • the host processor 30 executes an application program interface (API) software module that communicates with the CS processor 40 via the channel 50 to cause the CS processor 40 to configure itself.
  • API application program interface
  • the host processor 30 sends generic CAS commands and stream processing commands to the reconf ⁇ gurable CS processor 40, which instruct the CS processor 40 to configure itself to look for the EMMs and ECMs based on the DCAS, and which inform the CS processor 40 of the manner in which the encrypted content stream 51 is to be processed to decrypt the content in the CA domain.
  • the host device 20 sends a request to download a DDRMS software module to a downloading facility, which may be the same as the DCAS downloading facility 14 shown in FIG. 1.
  • the downloading facility 14 transmits a DDRMS software module to the STB 20, which is downloaded into the CS processor 40 of the invention.
  • the host processor 30 executes an API software module that communicates with the CS processor 40 via the channel 50 to cause the CS processor 40 to configure itself.
  • the host processor 30 sends generic DRM commands to the reconf ⁇ gurable CS processor 40, which instruct the CS processor 40 to configure itself to encrypt and decrypt content files in the DRM domain.
  • the CS processor 40 preferably configures itself to perform decryption in a CA domain and to perform encryption and decryption in a DRM domain.
  • the processes of configuring the CS processor 40 in these domains will typically be performed as a single process if the DRM software modules are delivered to the host processor 30 along with the DCAS software modules as part of the DCAS software suite.
  • the processes of configuring the CS processor 40 in these domains are performed as separate processes if the DRM software modules are delivered to the host processor 30 separate from the DCAS software modules.
  • the CS processor 40 will execute one or more DCAS and DDRMS software modules.
  • the DCAS software modules look for and extract the corresponding EMMs and ECMs in the encrypted content stream 51 delivered to the host device 20.
  • the encrypted content stream 51 includes DRM content as well as other types of content.
  • the CS processor 40 extracts the EMMs and ECMs from the encrypted content stream, the CS processor 40 processes them to obtain the CW, and then uses the CW to decrypt the encrypted content stream 51.
  • the CS processor 40 then encrypts the decrypted content in the DRM domain and saves the encrypted DRM content in a storage device 60 via a storage channel 61.
  • the CS processor 40 may be instructed by the host processor 30 to retrieve particular encrypted content from the storage device 60, decrypt it and render it on a display device 70 via a rendering channel 71.
  • the CS processor 40 will permit the host processor 30 to specify DRM actions desired by the user of the host device 20. For example, upon receiving a command from a user via a user interface 80 of the host device 20, the host processor 30 will instruct the CS processor 40 to display a list on the display device 70 of the DRM content stored in the storage device 60. The content titles have previously been designated by the user via the user interface 80 and the host processor 30 and recorded in the storage device 60 along with the encrypted content.
  • the host processor 30 may instruct the CS processor 40 through the aforementioned API to allow the user to perform tasks such as, for example, purchase requests, content copy requests, content delete requests, etc.
  • the DRM software would then access the hardware of the CS processor 40 and utilize the appropriate cryptographic functions to achieve the requested DRM action using methods specific to the downloaded DDRMS.
  • the user will enter a request via the user interface 80 to have a list of content titles to be displayed on the display device 70.
  • the host processor 30 will then instruct the CS processor 40 to retrieve the list of content titles and display them on the display device 70.
  • the CS processor 40 After the CS processor 40 has retrieved the titles and caused them to be displayed on the display device 70, the user will make a selection from the list via the user interface 80.
  • the host processor 30 will receive this request and instruct the CS processor 40 to render the selected content to the display device 70.
  • the CS processor 40 will perform operations in accordance with this module, such as, for example, verifying that the user has authorization to use the requested content in the manner requested. For example, the user may have authorization to view the requested content as many times as desired during a twenty- four hour period starting at the instant in time when the user purchased the content. In this case, the CS processor 40 might determine whether the user has purchased the content, and if so, whether twenty- four hours have lapsed since the content was purchased.
  • the CS processor 40 determines that the requested use is authorized, the CS processor 40 will retrieve the metadata associated with the encrypted content from the storage device 60, decrypt the encrypted content, and cause it to be displayed on the display device 70. If the requested use is not authorized, the CS processor 40 will inform the host processor 30, which will then inform the user by, for example, displaying a message on the display device 70 that informs the user of conditions for using the content (e.g., cost, time period over which the content will be available to the user, whether or not copies can be made, whether or not the user can use the content on other devices, etc.).
  • conditions for using the content e.g., cost, time period over which the content will be available to the user, whether or not copies can be made, whether or not the user can use the content on other devices, etc.
  • rendering device 70 Although the only rendering device described above is a display device 70, a variety of rendering devices are available for rendering content in a variety of forms (e.g., audio, video, text, images, etc.).
  • the rendering device may, but need not be, part of the host device 20.
  • the STB typically does not include rendering devices, but is connected to and operates in conjunction with a rendering device, such as a television set, a stereo system, a home entertainment system, etc.
  • the display device 70 is shown merely for illustrative purposes.
  • the host device 20 may include one or more other input/output (I/O) interfaces 90, such as one or more Universal Serial Bus (USB) interfaces, for example, to enable the host device 20 to communicate with other devices. For example, if the user has DRM permission to play back a requested movie on a mobile telephone (not shown) or laptop computer, the user may connect a USB connection on the telephone or laptop computer to the I/O interface 90 to enable the movie to be downloaded into a memory device of the telephone or laptop computer for subsequent play back on those devices.
  • Examples of DRM tasks that may be performed by the DDRMS software module executed by the CS processor 40 include (1) content management, (2) provisioning management, and (3) device management.
  • Content management typically involves administering rules regarding, for example, the number of "plays” requested by user, the number of "copies” requested by user, the output copy format requested (e.g., small format for a phone, home theatre quality format for a digital video recorder), and the playability lifetime (e.g. one day, one week, one month, forever, etc.).
  • Provisioning management typically involves administering rules that synchronize the DDRMS client being executed by the CS processor 40 with the network "back office" server, which in this case might be the DCAS downloading facility 14. These commands will be used to communicate, for example, rights requested by the user, rights authorized to the user, and configuration of the user's account.
  • Device management typically involves administering rules regarding the list of authorized devices for DRM-enabled content, adding, deleting, updating, the list, and specifying device parameters (e.g., storage capacity, decryption /DRM supported, etc.).
  • API Command Request Some examples of generic DRM commands (API Command Request) that are sent from the host processor 30 to the CS processor 40 and returned from the CS processor 40 to the host processor 30 (CSP Response) include the following: API Command Request CSP Response query rights (content URL) rights_response() modify rights (content URL usage right) modify_rights_response() modify_account(account_ID, Device lD) modify_account_response()
  • the first exemplary command, query usage(content URL) would be used to obtain a content description, existing permissible actions, such as play three times, copy to a DVD, etc.
  • the related DRM module being executed by the CS processor 40 would obtain the file from the location provided in the URL, evaluate the DRM usage rules associated with the content, and return the result in the response to host processor 30.
  • the second illustrative command would enable the host processor 30 to request the CS processor 40 to modify a DRM usage right associated with a particular content asset.
  • the DDRMS client would update the corresponding usage rights to enable the request right, for example, to make a copy of a movie to DVD.
  • the last illustrative command would cause the CS processor 40 to a specified device to update an internal list of recognized, authorized-use devices.
  • one of the benefits of the DDRMS is that no system-specific code is implemented in the host processor 30. Because no system-specific code is implemented in the host processor 30, the host processor 30 is not vulnerable to security risks. All CA-specific code and DRM-specific code are executed entirely within the CS processor 40. In addition, because it is not necessary for a DDRMS or DCAS kernel to be executed by the host processor 30, different DDRMS and DCAS kernels do not have to be designed for different host processors. Consequently, the amount of work and costs associated with implementing a given DDRMS and or DCAS are reduced.
  • API Command Request Some examples of generic CAS commands (API Command Request) that are sent from the host processor 30 to the CS processor 40 and returned from the CS processor 40 to the host processor 30 (CSP Response) include the following: API Command Request CSP Response acquire auth stream (module) module auth status extract_services (module) service list (e.g., PAT) acquire_service (module, service) service_status
  • the above commands are shown in a generic fashion to highlight the point that the host processor 30 and the CS processor 40 could be working with data in different formats, such as, for example, MPEG packets or IP datagrams.
  • the first command acquire auth stream, would be used to acquire system-level module authorization status.
  • the related DCAS module being executed by the CS processor 40 would seek and acquire its related system authorization stream and individual module authorization status, and return the resultant status in the response to the host processor 30.
  • the second illustrative command, extract services would be used by the host processor 30 to obtain a listing of services available to the CS processor 40. In the case of MPEG data streams, the service list would be represented by the presence of the Program Association Table (PAT).
  • PAT Program Association Table
  • the user could make a selection from the list, thus causing the host processor 30 to communicate an acquire service message to the CS processor 40.
  • the illustrative acquire service message would result in decryption of the encrypted content stream if the downloaded CAS client module being executed by the CS processor 40 were authorized for the selected service. In cases where the client module is not authorized, the service status would return an appropriate error status message.
  • the CS processor 40 detects the corresponding EMM and ECM and analyzes the EMM to determine whether the user is authorized to access the content. If the EMM indicates that the user is authorized, the CS processor 40 decrypts the ECM and obtains the CW. The CS processor 40 then uses the CW to decrypt the encrypted content stream. If the EMM does not indicate that the subscriber has authorization to access the content, the encrypted content stream will not be decrypted. In the known proposed DCAS system shown in FIG. 1 and described above, the CWs are transmitted between the host processor IC 12 and the transport processor IC 15.
  • the CWs are subject to being accessed by a hacker and used to obtain unauthorized access to restricted content.
  • the CWs are never transmitted outside of the CS processor 40. This makes it extremely difficult or impossible for a hacker to obtain access to the CWs, and therefore makes the DCAS more secure and less vulnerable to attacks.
  • all DRM encryption and decryption tasks are performed solely within the CS processor 40, which makes it extremely difficult or impossible for a hacker to obtain access to the DRM- protected content.
  • FIG. 3 illustrates a block diagram of the CS processor 40 of the invention in accordance with an illustrative embodiment.
  • the CS processor 40 typically includes an input/output (I/O) interface 101 for communicating with the host processor 30, a CS controller 100 for controlling the operations of the CS processor 40, a memory element 110 for storing the downloaded DCAS software module and data, a stream parsing component 120 for parsing the encrypted content stream to locate the ECMs and EMMs, a CAS decrypting component 130 for decrypting the encrypted content stream, a DRM encrypting component 140 for encrypting the decrypted component in the DRM domain, and a DRM decrypting component 150 for decrypting the DRM-domain encrypted content.
  • I/O input/output
  • the DRM encryption technique performed by component 140 may be the same as the CAS encryption technique used by the downloading facility 14, in which case the DRM encrypting component 140 is not needed.
  • the DRM decryption technique performed by DRM decrypting component 150 may be the same as the CAS decryption technique performed by CAS decrypting component 130, in which case the component 150 is not needed. If the DRM encryption technique is different from the CAS encryption technique, then the DRM encrypting and decrypting components 140 and 150 are needed.
  • the host processor 30 and the CS processor 40 are typically integrated circuits (ICs) mounted on a printed circuit board (PCB) or the like, and are in communication with each other via the communications channel 50, which is typically a PCB bus.
  • the I/O interface 101 of the CS processor 40 receives the CAS and stream processing commands sent over the bus 50 from the host processor 30. Some of the commands are used by the CS processor 40 to configure the stream parsing component 120. Some of the commands are used by the CS processor 40 to configure the CAS decrypting component 130. Some of the commands are used by the CS processor 40 to configure the DRM encrypting component 140. Some of the commands are used by the CS processor 40 to configure the DRM decrypting component 150.
  • the memory element 110 also stores the downloaded DDRMS and DCAS software modules.
  • the DDRMS and DCAS software modules comprise CAS and DRM software programs for performing the CAS and DRM tasks.
  • the CS controller 100 executes this software and controls the operations of the components 110, 120, 130, 140, and 150 in accordance with the software.
  • these programs can be part of a single software module or they can be separate software modules. For ease of discussion, it will be assumed that the DRM and CAS software is all part of a single software module.
  • the stream parsing component 120 executes code of the DCAS software module that enables it to parse the encrypted content stream to locate the EMMs and ECMs, check the EMM to determine whether the subscriber is authorized to access the corresponding content, and extract the CW from the ECM in cases where the EMM indicates that the subscriber is authorized to access the content.
  • the extracted CW is sent to the CAS decrypting component 130, which uses the CW to decrypt the encrypted content stream.
  • the decrypted content stream output from the decrypting component 130 is then ready to be rendered on a rendering device. Some of the decrypted content may then be output from the CS processor 40 and sent to a rendering device (e.g., display device 70).
  • the decrypted content that is to be managed by DRM is input to the DRM encrypting component 140, which encrypts the content in the DRM domain.
  • the DRM-encrypted content is output from the CS processor 40 and sent over communications channel 61 to the storage device 60 (Fig. 2), which stores the DRM-encrypted content.
  • the host processor 30 receives a request for content, it will forward a corresponding request over bus 50 to the CS processor 40.
  • the CS controller 100 will process the request and determine whether the requested use is authorized.
  • the CS controller 100 typically accomplishes this task by analyzing the metadata associated with the requested file, which is also stored in the storage device 60, in accordance with the aforementioned DRM rule set to determine whether the requested use is authorized. If so, the controller 100 will cause the requested content to be retrieved from the memory device 60 and sent to the DRM decryption component 150 for decrypting. The DRM-decrypted content will then be sent to a location designated by the controller 100 via the I/O interface 101 and bus 50. [0040] As stated above, the CS processor 40 is capable of being reconfigured if a new or different DDRMS is to be used.
  • the host processor 30 downloads the DDRMS software module and forwards it to the CS processor 40, which stores it in memory element 110.
  • the host processor 30 then sends commands that are specific to the DDRMS to the CS processor 40, which it uses to reconfigure the components 100, 110, 120, 130, 140, and 150.
  • the CS processor 40 may have multiple DDRMS software modules corresponding to different DDRMSs stored in memory element 50.
  • the host processor 30 is capable of configuring the CS processor 40 to execute any one of these software modules based on the encryption scheme being used at the headend. For example, if certain cable television headend signals are protected by two conditional access systems, DDRMSl and DDRMS2, and if a user desires to tune between the services protected by DDRMSl and DDRMS2, then the host processor 30 will configure the CS processor 40 to use the appropriate DDRMS for each respective service.
  • the CS processor 40 will switch back and forth as required to respond to tuning requests by the user.
  • the host processor 30 will configure the CS processor 40 to simultaneously process services protected by DDRMSl and DDRMS2.
  • the CS processor 40 is typically an integrated circuit (IC), such as, for example, an application specific integrated circuit (ASIC).
  • IC integrated circuit
  • ASIC application specific integrated circuit
  • the CS processor 40 may be any device capable of performing the functions described herein, including, for example, a microprocessor, a microcontroller, a field programmable gate array (FPGA), a programmable logic array, etc.
  • the CS processor 40 may be implemented in hardware, software, firmware, or a combination of hardware, software and/or firmware.
  • the term "processor”, as that term is used herein, is intended to denote these and any other implementations of suitable computational devices.
  • the host processor 30 may be any device capable of performing the functions described herein with reference to the host processor 30, including, for example, a microprocessor, a microcontroller, a field programmable gate array (FPGA), a programmable logic array, etc.
  • the host processor 30 may be implemented in hardware, software, firmware, or a combination of hardware, software and/or firmware.
  • the host processor 30 is typically a microprocessor.
  • SOC system on a chip
  • FIG. 4 illustrates a host device 160 in accordance with an embodiment in which the host processing logic 180 that performs the functions described above with respect to host processor 30 and CS processing logic 190 that performs the functions described above with reference to CS processor 40 are incorporated into a single SOC IC 170.
  • FIG. 5 illustrates a flowchart that demonstrates the method in accordance with an illustrative embodiment for processing an encrypted content stream in the CA domain. It should be noted that the steps represented by the blocks in the flowchart do not have to be performed in the order depicted in FIG. 5, or in any particular order.
  • a DCAS software module is downloaded to the CS processor, as indicated by block 201. Subsequently, CAS and stream processing commands are sent from the host processor to the CS processor, as indicated by block 203. The CS processor configures itself in accordance with the received DCAS commands, as indicated by block 205.
  • the encrypted content stream is then parsed and the EMMs and ECMs are located, as indicated by block 207.
  • Fig. 6 illustrates a flowchart that demonstrates the method of the invention in accordance with an illustrative embodiment for processing an encrypted content stream in the DRM domain. It should be noted that the steps represented by the blocks in the flowchart do not have to be performed in the order depicted in FIG. 6, or in any particular order.
  • a DDRMS software module is downloaded to the CS processor, as indicated by block 221. This step assumes that the DRM system is separate from the DCAS system downloaded in step 201 in Fig. 4, which is not necessarily the case.
  • DRM commands are sent from the host processor to the CS processor, as indicated by block 223.
  • the CS processor configures itself in accordance with the received DRM commands, as indicated by block 225.
  • CS processor determines whether the usage is authorized, as indicated by block 227. As stated above, this is typically accomplished by processing information contained in the metadata stored in the storage device 60 in association with the requested content file. If so, the DRM-protected content is retrieved from memory, as indicated by bock 229, and decrypted and output for rendering, as indicated by block 231. The manner in which the decrypted content is treated after it has been decrypted depends on the usage requested, and so is not shown in Fig. 5. If a determination is made at bock 227 that the requested usage is not authorized, a message is sent to the host processor indicating that the request is to be denied, as indicated by block 233.
  • FIG. 7 illustrates a block diagram of host device 300 having components that are configurable to execute a DDRMS.
  • the host processor 330 of the host device 300 e.g., an STB, laptop computer, mobile phone, PDA, etc.
  • the host processor 330 of the host device 300 does not execute any DRM-specific code. Rather, all DRM-specific code is implemented in the CS processor 340 of the host device 300.
  • the CS processor 340 and the host processor 330 are in communication with each other via a communications channel 350. Benefits associated with implementing all DRM-specific code in the CS processor 340 rather than in the host processor 330 are described below in detail.
  • the DDRMS and DRM-encrypted content are being delivered to a host device such as a PC, for example, from a content provider such as a server on a network, for example.
  • the content is not protected by a CAS, but is only protected in the DDRMS.
  • the host device 300 sends a request to download a DDRMS software module to a downloading facility 314, which, as stated above, may be a content provider that distributes content from one or more servers on a network.
  • the downloading facility 314 transmits a DDRMS software module to the host device 300.
  • the host processor 330 controls the downloading of the DDRMS to the CS processor 340.
  • the host processor 330 executes an API software module that communicates with the CS processor 340 via the channel 350 to cause the CS processor 340 to configure itself. Through this API, the host processor 330 sends generic DRM commands to the reconfigurable CS processor 340, which instruct the CS processor 340 to configure itself to encrypt and decrypt DRM-encrypted content files. [0048] After the CS processor 340 has been configured in the DRM domain, the CS processor 340 will execute one or more DDRMS software modules. DRM-encrypted content received by the host device 300 from the content provider, which may or may not be the same as the DRM downloading facility 314, is sent by the host processor 330 to the CS processor 340.
  • the CS processor 340 decrypts the DRM-encrypted content in the DRM domain and saves the decrypted DRM content in a storage device 360 via a storage channel 361. Alternatively, the CS processor 340 may save the content in the storage device 360 in its encrypted form. At some later time, the CS processor 340 may be instructed by the host processor 330 to retrieve particular content from the storage device 360 and render it on a display device 370 via a rendering channel 371. If the content retrieved from the storage device 360 has previously been decrypted by the CS processor 340, the CS processor 340 will render the content if the CS processor 340 determines that such action is authorized. If the content retrieved from the storage device 360 has not previously been decrypted by the CS processor 340, the CS processor 340 will decrypt the content and then render the content if the CS processor 340 determines that such action is authorized.
  • the CS processor 340 will permit the host processor 330 to specify DRM actions desired by the user of the host device 300. For example, upon receiving a command from a user via a user interface 380 of the host device 300, the host processor 330 will instruct the CS processor 340 to display a list on the display device 370 of the DRM content stored in the storage device 360. The content titles have previously been designated by the user via the user interface 380 and the host processor 330 and recorded in the storage device 360 along with the encrypted content.
  • the host processor 330 may instruct the CS processor 340 through the aforementioned API to allow the user to perform tasks such as, for example, purchase requests, content copy requests, content delete requests, etc.
  • the DRM software would then access the hardware of the CS processor 340, which would then determine whether the requested action is authorized, and if so, utilize the appropriate cryptographic functions to perform the requested DRM action.
  • the invention has been described with reference to particular examples and that the invention is not limited to the examples described herein.
  • the CS processor has been described with reference to FIGS. 2, 3 and 7 as being a single IC, it may instead be made up of a combination of ICs or other devices that operate in conjunction with each other to perform the aforementioned operations.
  • the configuration shown in FIG. 3 is merely an example of one way in which the host device may be configured to perform the DRM, or DRM plus CAS, processing tasks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne, dans un système de gestion de droit numérique téléchargeable (DRM) (DDRMS) exécuté sur un dispositif hôte, de préférence l'ensemble du code spécifique à DRM est mis en œuvre dans un processeur sécurisé configurable (CS) (40) qui est en communication avec le processeur hôte (30) du dispositif hôte. De préférence, aucun code spécifique à DRM n'est exécuté dans le processeur hôte (30). Le processeur hôte délivre des ordres au processeur CS (40), que le processeur CS (40) exécute pour se configurer lui-même selon le schéma de chiffrement des DRM particuliers utilisés par le DDRMS. Une fois configuré, le processeur CS (40) exécute un module logiciel DDRMS qui a été téléchargé sur le processeur CS (40). Le processeur CS (40) exécutant le module logiciel DDRMS traite les requêtes d'utilisation pour le contenu chiffré DRM et entraîne le déchiffrement du fichier demandé dans le domaine DRM seulement si l'utilisation demandée est autorisée. Du fait qu'aucun code spécifique à DRM n'est exécuté dans le processeur hôte (30), la sécurité du DDRMS est moins susceptible d'être compromise.
PCT/US2008/065897 2007-06-07 2008-06-05 Procédés et appareils de réalisation d'une gestion des droits numériques (drm) dans un dispositif hôte par l'utilisation d'un système drm téléchargeable WO2008154283A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US75972807A 2007-06-07 2007-06-07
US11/759,728 2007-06-07

Publications (1)

Publication Number Publication Date
WO2008154283A1 true WO2008154283A1 (fr) 2008-12-18

Family

ID=40130131

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/065897 WO2008154283A1 (fr) 2007-06-07 2008-06-05 Procédés et appareils de réalisation d'une gestion des droits numériques (drm) dans un dispositif hôte par l'utilisation d'un système drm téléchargeable

Country Status (1)

Country Link
WO (1) WO2008154283A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012030649A1 (fr) * 2010-09-02 2012-03-08 General Instrument Corporation Système et procédé de transmission de flux d'informations numériques
US8631430B2 (en) 2010-11-18 2014-01-14 Sony Corporation Enabling DRM-encrypted broadcast content through gateway into the home
JP2015524178A (ja) * 2012-05-02 2015-08-20 サムスン エレクトロニクス カンパニー リミテッド Ｍｍｔにおけるダウンロード可能なｃａｓ又はｄｒｍのためのメッセージを送受信する方法及び装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040133794A1 (en) * 2001-03-28 2004-07-08 Kocher Paul C. Self-protecting digital content
US20060282391A1 (en) * 2005-06-08 2006-12-14 General Instrument Corporation Method and apparatus for transferring protected content between digital rights management systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040133794A1 (en) * 2001-03-28 2004-07-08 Kocher Paul C. Self-protecting digital content
US20060282391A1 (en) * 2005-06-08 2006-12-14 General Instrument Corporation Method and apparatus for transferring protected content between digital rights management systems

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012030649A1 (fr) * 2010-09-02 2012-03-08 General Instrument Corporation Système et procédé de transmission de flux d'informations numériques
US8631430B2 (en) 2010-11-18 2014-01-14 Sony Corporation Enabling DRM-encrypted broadcast content through gateway into the home
JP2015524178A (ja) * 2012-05-02 2015-08-20 サムスン エレクトロニクス カンパニー リミテッド Ｍｍｔにおけるダウンロード可能なｃａｓ又はｄｒｍのためのメッセージを送受信する方法及び装置

Similar Documents

Publication Publication Date Title
US10754930B2 (en) Remotely managed trusted execution environment for digital rights management in a distributed network with thin clients
CA2688581C (fr) Procede et appareil a utiliser dans un systeme d'acces conditionnel telechargeable
US20080222044A1 (en) Protected content renewal
EP2705662B1 (fr) Dispositif récepteur de télévision comportant de multiples modes de déchiffrement
US7650312B2 (en) Method and system to enable continuous monitoring of integrity and validity of a digital content
EP2699014A1 (fr) Terminal basé sur une technologie d'accès conditionnel
CN103026335A (zh) 用于流式传输媒体播放器的安全密钥检索的装置鉴别
KR20070090892A (ko) 디지털 오디오/비디오 데이터 처리 장치 및 액세스 제어방법
US20100262991A1 (en) Method for processing data and iptv receiving device
US20110113443A1 (en) IP TV With DRM
US8406426B2 (en) Method and apparatus for storing and retrieving encrypted programming content such that it is accessible to authorized users from multiple set top boxes
EP3560212B1 (fr) Sécurisation de la transmission d'un contenu, d'une carte à puce d'un récepteur de télévision hôte à un récepteur de télévision client
KR20050050085A (ko) 도메스틱 디지털 네트워크 키의 유효성 인증 방법
EP3317796B1 (fr) Environnement d'exécution sécurisé géré à distance pour une gestion de droits numériques dans un réseau distribué avec des clients légers
US8433926B2 (en) Method and apparatus for storing and retrieving encrypted programming content using an asymmetric key arrangement
WO2008154283A1 (fr) Procédés et appareils de réalisation d'une gestion des droits numériques (drm) dans un dispositif hôte par l'utilisation d'un système drm téléchargeable
JP2006129095A (ja) コンテンツ配信システム
US20240056651A1 (en) Digital rights management using a gateway/set top box without a smart card
EP2990977B1 (fr) Informations de droits d'utilisation pour un contenu protégé comportant deux parties
WO2006026056A1 (fr) Procede pour appliquer un accord drm/ipmp dans un reseau de distribution de contenu multimedia
KR100947313B1 (ko) Ｄｃａｓ 기반 인증 방법 및 장치
Diehl et al. Protection in Broadcast

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08770178

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08770178

Country of ref document: EP

Kind code of ref document: A1