Technique for securely communicating and storing programming material in a trusted domain

The present invention relates to communication technology, and more particularly to technology for safely transmitting and storing programming materials in communication systems, such as cable television systems.

The set-top terminal (STT) acts as a gateway between the user's television and the cable TV network that delivers programming content. Such programming content may be delivered as a broadcast signal, or may be delivered by an on-demand method that provides services such as video on demand (VOD), subscription VOD, and movie on demand. In addition, the Network Personal Video Recorder (NPVR) service allows users to perform trick mode functions (rewind, fast forward, pause, etc.) when presenting programming content by using the network. Has already been developed. In fact, the ongoing US Patent Application No. 10 / 302,550, filed November 22, 2002 and transferred to the applicant of the present application, describes the network architecture and features for implementing the NPVR service. In this application, this US patent application is incorporated as a reference example. This NPVR service also allows users to reserve past and future programs so that they can review them even if they were not identified to them before the broadcast.

STT receives programming content over a cable TV network that can be encrypted according to, for example, Data Encryption Standard (DES) technology, to secure the delivery of programming content. DES is a well-known symmetric cipher that uses a single key for both message encryption and decryption. Since the DES algorithm is publicly known, anyone can read the encrypted message by learning the DES key. In this way, both the sender and receiver of the message must keep the DES key secret from others. A DES key is typically an 8-byte sequence, with each byte containing 8 bits. The DES algorithm can be applied a number of consecutive times to improve the integrity of the DES. With such an approach, the DES algorithm uses different keys to encrypt and decrypt data, for example, three times in a sequence, resulting in the so-called Triple DES (3DES) technique.

In contrast to DES technology, public key cryptography, such as RSA technology (an acronym for the developers Rivest, Shamir and Adleman), uses two different keys. The first key, called the private key, is kept secret by the user. Another key, called the public key, is available to anyone who wants to communicate confidentially with the user. These two keys are uniquely matched to each other and are collectively referred to as a public key-private key pair. However, the private key cannot be easily derived from the public key. Stakeholders who want to send a message to a user can use the public key to encrypt the message before sending it. The user then uses the private key to decrypt the message. Conversely, a private key can be used to encrypt the message, in which case the message can then be decrypted with the public key. For example, the key for the RSA algorithm is partly generated mathematically by combining prime numbers. The security and equivalent of the RSA algorithm relies on the use of very large numbers for the key, which are generally 512 bits long.

In the prior art, programming content can be encrypted using a DES key according to the DES algorithm to secure delivery from the headend of the cable TV system to the STT. In order for the STT to decrypt the encrypted programming content, a DES key is sent from the headend to the STT in the Entitlement Control Message (ECM), and the control message is encrypted using the 3DES key according to the 3DES algorithm. Will be done. The 3DES key (also known as the Multisession Key (MSK)) is sent to the STT in a separate entitlement management message (EMM). This management message follows the public key algorithm and is encrypted using the STT public key, and the private key on the other side of this public key algorithm is kept secure in the STT. Therefore, after receiving the encrypted EMM and ECM, the STT decrypts the encrypted EMM using the STT private key to obtain the 3DES key. By using such a DES key, the STT decrypts the encrypted ECM to obtain the internal DES key. The STT can use such a DES key to decrypt the encrypted programming content received by the STT.

Recently, some STTs for cable TV have been improved to implement the Digital Video Decoder (DVR) feature (DVR STT). Like DVRs, such as TiVo or replay TV devices, DVR STTs generally include hard drives, such as discs, for digital recording of TV programs. Like DVRs, DVR STT allows cable TV subscribers to record their favorite TV programs for later review, and for a period of time to record any episode of their favorite program, season. Perform path-like options. This DVR STT can automatically record programs for users based on their viewing habits and preferences. The rewind, pause, and fast-forward functions allow you to manipulate the recorded presentation of programming content.

<p num="0007"> However, we believe that providing unlimited content to our subscribers will result in unacceptable amounts of fraudulent copies. Therefore, there is still a need for policies that allow content to be recorded by subscribers, but at the same time prevent (or control) content from being copied and distributed by fraudulent parties. Numerous technologies have been developed to solve such needs. One such technique uses an indicator, such as an encryption mode indicator (EMI), which can be used in the data stream used to send content from the source device to the destination device. EMI provides information about the status of the content to the destination device, which can indicate whether the content can be copied freely, only once, or not copy-protected. The destination device reads the EMI and decides if it is okay to copy the content. If copying is allowed, the destination device can copy the content. For details on such content protection technology, refer to "5C Digital Transmission Content Protection White Paper" published on July 14, 1998, Hitachi, Ltd., etc., revised edition 1.0.</p><p num="0008"> Another technique requires a device that is supposed to send protected content to determine if the receiving device is authenticated to receive the protected content. This technique can be achieved, for example, by requiring the receiving device to prove knowledge of a set of secret device keys. The sending device delivers the content only if the receiving device proves its legitimacy. An example of such a content protection system is described in "High Bandwidth Digital Content Protection System", Digital Content Protection LLC, Revised 1.1, published June 9, 2003.</p><p num="0009"> Similarly, it allows subscribers to perform authenticated copies of protected content, such as copying content from a set-top terminal to a second device in the subscriber's home, while preventing unauthorized copying. There is a need for a method to do. This need becomes more important as home networking becomes more prevalent. In recent years, a number of systems have been developed to provide interoperability between devices in the home, and home networks can include not only cable set-top terminals, but also personal computers, mobile phones, PDA devices, and so on. .. An example of a system for interconnecting various devices in the home is described in International Publication Patent Application WO 02/21841 published on March 14, 2003.</p>

<p num="0010"> The present invention overcomes the problems of prior art by defining a trust domain that protects programming content from unauthorized access and copying. For example, in a cable TV system, the trust domain is programmed by the cable operator, including, for example, the headend distribution network, and within the total control of the cable operator, as well as the system part where the security of the programming content is protected. It also includes user devices on the subscriber's premises that can receive and securely store content. By using the trust domain approach of the present invention, the cable operator can guarantee the access and use of a given subscriber with respect to the content held in the domain. For example, videos held in the cable operator's trust domain (eg on the user device's hard drive) cannot be visibly delivered over the Internet and for dubbing a large number of visible copies. It cannot be a source.</p><p num="0011"> To achieve a trust domain, use two cryptographic elements (eg, cryptographic keys) associated with the subscriber and each of the subscriber's user devices to control access to the content stored on the user devices in the domain. .. For example, according to DES technology, a secure key can be used to encrypt stored content in a user device. Therefore, when transporting encrypted content from a user device to a new device associated with the same subscriber in the domain, the new device will first encrypt to see and decrypt the encrypted content. Requires an element (eg a secret key). For this purpose, the new device also receives an encrypted first version of the first cryptographic element from the source device. The encrypted first version of the latter first cryptographic element encrypts the first cryptographic element using the second cryptographic element associated with the subscriber (eg, the public key according to the public key algorithm). It is caused by that. The new device provides an encrypted first version of the first cryptographic element, eg, to a remote device in the headend, within which the first cryptographic element is at least encrypted with the first cryptographic element. It will be recovered based on the first version and the data displaying the subscribers. The new device then receives an encrypted second version of the first cryptographic element from the device. This second encrypted version is generated by encrypting the recovered first cryptographic element with a third cryptographic element associated with the new device (eg, a public key according to a public key algorithm). Based on at least the encrypted second version of the first cryptographic element, the first cryptographic element is recovered in order to decrypt the cryptographic content transported to this device within the new device.</p>

<figref num="1">A component of a broadband communication system according to an embodiment of the present invention is shown.</figref><figref num="2">Figure 1 shows the subscriber registry maintained at the system headend.</figref><figref num="3">The device key table maintained at the headend of the system in Figure 1 is shown.</figref><figref num="4">The subscriber key table maintained at the headend of the system in Figure 1 is shown.</figref><figref num="5">The components of the first safety digital video recorder (SDVR) STT according to an embodiment of the present invention are shown.</figref><figref num="6">The storage device in the 1st SDVR STT is shown.</figref><figref num="7">It is a flowchart which shows the routine for encrypting and storing a content file according to one Example of this invention.</figref><figref num="8">FIG. 5 is a flowchart showing a routine for generating an encrypted content key associated with a subscriber according to an embodiment of the present invention.</figref><figref num="9">A component of the second SDVR STT according to an embodiment of the present invention is shown.</figref><figref num="10">FIG. 5 is a flowchart showing a routine for generating an encryption content key related to the second SDVR STT according to an embodiment of the present invention.</figref><figref num="11">FIG. 5 is a flowchart showing a routine for transferring a content file from a first device to a second device, for example, via a home network according to an embodiment of the present invention.</figref>

With reference to the accompanying drawings showing the illustrated examples of the present invention, the following detailed description reveals another object, feature and advantage of the present invention.

The present invention relates to a technique for protecting the security of programming content in a protected area from unauthorized access and copying. Hereinafter, such a protected area is referred to as a trust domain. In cable TV systems, the trust domain has traditionally been programmed by the cable operator, including the headend, distribution network, etc., as well as the system part within the total control of the cable operator. It also includes user devices on the subscriber's premises that can receive and store content, such as DVR STT, and implement conditional access mechanisms in accordance with the present invention. For convenience, the DVR STT that realizes the conditional access mechanism of the present invention is hereinafter referred to as a safe DVR STT (SDVR STT). The trust domain also holds or exchanges data that is encrypted and managed under other devices in the subscriber's premise, such as the conditional access mechanism of the invention. A set of devices connected to the STT (preferred or wirelessly connected) can also be included. Regardless of which device holds the content, the trust domain is a stored content as long as the content remains encrypted under the mechanisms of the invention and remains managed. Is complete. For example, when data is sent from an SDVR STT to a TV monitor for display, once the content is decrypted by the conditional access mechanism, the decrypted content is no longer in the trust domain and is therefore no longer secure.

By using the trust domain approach of the present invention, the cable operator can guarantee the access and use of a given subscriber with respect to the content held within the domain. For example, videos held in the cable operator's trust domain (eg held on the SDVR STT's hard drive) cannot be visibly delivered over the Internet and have many visible copies. It cannot be a source for dubbing. On the other hand, videos held in a trust domain (eg, unencrypted on a third-party DVR hard drive) can be delivered over the Internet and copied to removable media in a visible form. You can also do it.

FIG. 1 shows the components of a broadband-centric system, for example, a cable TV system, which embodies the principles of the present invention. The headend 120 receives programming content attributed to various program channels, eg SDVR. Provides cable television services to STTs, including STT158-1 ~ 158-M (where M represents an integer). It should be understood that the same cable television service is provided for conventional STTs that do not have programming content storage capability, but this conventional STT is not relevant herein. It should also be noted that "transmit channel" and "program channel" should not be confused. The term "transmit channel" refers to a specified frequency band that is passed when transmitting a transport stream containing programming content and / or data, and the term "program channel" is user-selected for viewing. Means the source of programming content or service. For example, the user can select program channel 2 to see the programming content provided by CBS, program channel 14 to see the programming content provided by ESPN, and so on.

In the conventional manner, the headend 120 delivers the programming content downstream to SDVR STT158-1 to 158-M (where M represents an integer) in the service area or in close proximity. As shown in FIG. 1, the SDVR STT158 is connected to network 150 through service area node 161. In this case, network 150 is a multi-network distribution network, including a well-known hybrid fiber coaxial (HFC) cable network.

The programming content is delivered downstream from the headend 120 to the SDVR STT158 through the in-band transmit channel. In one embodiment, these transmit channels may be 6 MHz, which occupies the forward passband of the coaxial cable, eg, the band of 350-750 MHz. The QAM modulator bank 137 in hub 130 modulates the transport stream containing programming content on selected in-band channels according to the QAM scheme.

In addition, downstream data, such as control messages, emergency information, etc., can be transmitted from the headend 120 to the SDVR STT158 via one or more forward data channels (FDCs), sometimes referred to as out-of-band channels. The FDC can occupy a 70-130MHz hand of coaxial cable. The QPSK modem pool 138 in hub 130 modulates the downstream data on the selected FDC according to the QPSK scheme.

Upstream data, such as application data, file requests, etc., can be sent from the SDVR STT158 to the headend 120 via one or more reverse data channels (RDCs) that occupy the coaxial cable's reverse passband, such as the 5-40MHz band. .. Data across the RDC is modulated according to the QPSK scheme. The QPSK modem pool 138 in the hub 130 receives the QPSK signal containing the data from the RDC and performs the necessary demodulation before sending the underlying data to the headend 120. Each STT shares an RDC with other STTs in the network, using a conflict-based access mechanism defined by the standard decision-making mechanism, the Digital Audiovisual Council (DAVIC). By this mechanism, STT, for example SDVR The STT158-1 can send upstream messages without a dedicated connection to the QPSK demodulator. This mechanism also provides the same access to STTs that share an RDC, allowing it to detect and recover from reverse path collisions that occur when two or more of the STTs send application messages at the same time. To. For communication purposes, each STT and network controller 209 is specified by an Internet Protocol (IP) address assigned to them, as also specified by DAVIC. However, these IP addresses can be randomly specified each time the broadband communication system is reconfigured. As a result, the STT IP address or the network controller 209 IP address may change after the system is reconfigured. However, it is also possible to permanently specify a media access control (MAC) address for each STT and network controller 209, leaving the system reconfigured.

The headend 120 specifically includes a program material processing unit 231, an application server 220, a network controller 209 and a switching unit 230. The program material treatment unit 231 receives the programming content in a well-known manner from various sources attributed to different program channels, and generates a transport stream containing the programming content according to, for example, the well-known MPEG-2 method. Under the control of network controller 209, the transport stream switches the transport stream in the QAM modulation bank 137 in the hub 130 by switching the unit 230 to the appropriate modulator, and in this switching unit 230 the transport. The stream is modulated on the corresponding in-band transmit channel so that it can be delivered to the STT over network 150.

The application server 220 can include one or more server systems that provide software applications and services for STT users. For example, the application server 220 can include one or more software applications that provide data services, network management services, interactive program guide services, billing services, and so on. Server 220 can manage the server registry displayed in 360 in Figure 2 in memory 220. Registry 360 is presented in the form of a table, in which column 363 contains an identifier that identifies the STT (STID) for each STT in the system. In this example, each STT is identified by its MAC address. For example, SDVR STT158-1 can be identified by the MAC address displayed as MAC-1. Column 364 contains an identifier ID (eg, subscriber's name, ID number, etc.) that identifies the subscriber to the cable television service associated with each STT. For example, referring to line 368-1, STT 158-1 is associated with the subscriber identified by S-1. In this example, the subscriber S-1 can be, for example, an individual who has purchased or leased the SDVR STT158-1 and is registered by the operator as a user of it. It should be noted that a given subscriber can be associated with more than one STT. For example, see line 368-2, SDVR STT150-2 is also associated with subscriber S-1. In this example, subscriber S-1 may have a purchased or leased STT150-2 in his home for use as a second STT.

In this case, the application server 220 also includes an access control manager 225 for realizing the above access control mechanism according to the present invention. For this purpose, Manager 225 maintains data related to SDVR STT and / or access control for subscribers. For example, manager 225 can maintain a library of device public keys associated with SDVR STT in a cable TV system in memory 222. When the SDVR STT is provided to the subscriber, it anticipates data encryption according to the public key algorithm, and the SDVR STT is assigned one public key / private key pair. The SDVR STT device private key is stored in its internal secure memory, while the device public key can be sent to Manager 225 through the RDC during the SDVR STT initialization process. Unlike this, during SDVR STT registration, if the cable operator does not have the SDVR STT serial number, this SDVR This serial number can be provided to the cable operator so that the cable operator can see the public key associated with the STT. Figure 3 shows the library of device public keys in the form of a table with number 273. Device key table 273, in this case, includes column 276 containing the STID of each SDVR STT in the system, which is the MAC address. For example, SDVR STT158-1 is identified by the address MAC-1 as described above. Column 277 registers the device public key assigned to each STT. In this example, each device public key is 112 bits long. For example, referring to line 279-1, STT158-1 is assigned the public key labeled DPUBKEY-1. It should be noted that Table 273 is for display purposes only. In another embodiment, different identifiers, such as IP addresses, can be used within cable 273 to identify different STTs in the network.

According to the present invention, according to a public key algorithm, another data is expected to be encrypted, and each subscriber associated with SDVR STT is also assigned a public key-private key pair. Manager 225 can maintain the subscriber key table labeled 283 in Figure 4. The subscriber key table 283 includes column 286 listing each subscriber's identifier associated with the SDVR STT, such as S-1, S-2, S-3, and so on. Columns 287 and 288 contain a copy of the subscriber public key and subscriber private key assigned to each subscriber, respectively. Referencing line 289-1, for example, subscriber S-1 is assigned a subscriber public key labeled SPUBKEY-1 and a key private key labeled SPRIKEY-1. Such a key pair can be assigned to each subscriber by the cable operator during service registration by the subscriber. Since the subscriber private key must be kept secret, table 283 can be kept by manager 225 in secure memory 227.

FIG. 5 shows the components of a comprehensive SDVR STT (eg 150-1) involved in the present invention, which in particular include a processor 330, an interface 250, a memory 210, a storage device 610 and an encryption module 165. Processor 330 organizes the operation of the SDVR STT158-1. Interface 250 includes a cable modem 258 capable of demodulating signals containing programming content and data from in-band channels and FDCs and modulating the data signals to RDCs. Interface 250 also performs program content and other well-known formatting and reformatting functions required to send and receive data.

Memory 210 is, for example, a basic function for SDVR STT158-1 and in this case an operating system for providing STID214 to identify SDVR STT158-1, where STID214 is MAC address MAC-1 (not shown). Stores various software applications and data, including. The memory 210 can be, for example, a non-volatile random access memory.

The device private key assigned to STT158-1, such as DPRIKEY-1, is stored in secure memory 212 within encryption module 165 so that it cannot be easily or reliably discovered or tampered with without warning. On the other hand, the device public key assigned to the SDVR STT158-1, for example DPUBKEY-1 (a copy of which is registered in table 273 in the headend 120 as described above), is stored in memory 210.

The storage device 610 is used to record programming content, in which case it can be a removable hard disk drive. It can be seen that the storage device 610 can include, for example, a digital video disc (DVD) drive, a memory stick, a network-based storage device, and the like. Processor 330 can also perform DVR functions such as recording selected programming content in one or more content files and then storing these contents in storage 610. As used herein, the term "content file" means a container that holds a definite amount of programming content. The content file can include, for example, a version of the movie recorded by digital technology, such as "Citizen Kane".

Cable operators have determined that giving subscribers the right to save unlimited programming content results in an unacceptable amount of unauthorized copying. Therefore, the access control mechanism according to the present invention is realized so as to prevent such unauthorized copying. According to the mechanism of the present invention, the encryption module 165 generates a content key, for example, a 3DES key for encrypting a content file provided by the processor 330 before storage according to the 3DES algorithm. In the illustrated embodiment, each of the respective content files are different content key for encrypting the generated Ru. However, it can be seen that one content key can be used to encrypt all content files in the same storage device. You can also see that many content keys are used to encrypt one content file.

In addition, module 165 encrypts and stores each generated content key to form encrypted content key version 1 (V-1) and encrypted content key version 2 (V-2). Stores the encrypted content key version (shown at 603 and 604 in Figure 6, respectively) associated with the corresponding encrypted content file 602 in 610 (for example, a file encrypted using the content key). To do. In the illustrated embodiment, the encrypted content key V-1 is formed by encrypting the content key with the device public key (ie, DPUBKEY-1) assigned to the SDVR STT158-1. On the other hand, in this case, the content key V-2 encrypted by encrypting the content key with the subscriber public key (ie SPUBKEY-1) assigned to the subscriber S-1 associated with SDVR STT158-1. To form.

For example, subscriber S-1 SDVR to record a movie of a specified programming content, eg "Citizen Kane", when broadcast over cable network 150. You can command STT158-1. Therefore, processor 330 generates a content file containing the content of the specified movie received from interface 250. Figure 7 is a flow chart showing a routine for encrypting and storing content files. The encryption module 165 generates the above-mentioned content key associated with the specified content file, which is instructed by such a routine in step 308. In step 310, module 165 uses the content key to encrypt the content file according to the 3DES algorithm above. At step 315, module 165 stores the encrypted content file 602 in storage device 610. At step 318, module 165 retrieves the device public key DPUBKEY1 from memory 210. At step 320, module 165 uses DPUBKEY-1 to encrypt the content key according to the first public key algorithm, for example the RSA algorithm. As described above, the content key encrypted as a result is referred to as the encrypted content key V-1. At step 325, module 165 stores the encrypted content key V-1, labeled 603, in storage 610. In one embodiment, the encrypted content key V-1 is stored in the form of metadata associated with the encrypted content file.

To generate the encrypted content key V-2 labeled 604, module 165 looks up the encrypted content key V-1 from storage 610 and the device private key DPRIKEY-1 from secure memory 212. And search for STID 214 from memory 210. This STID 214 is MAC-1 in this example. Module 165 uses DPRIKEY-1 to decrypt the encrypted content key V-1 and recovers the content key in a clear state. Module 165 then securely transmits the content key to the headend 120 via the RDC. Secure transmission of the content key from the STT158-1 to the headend 120 can be achieved using traditional cryptography, such as traditional public key cryptography, which is within the headend 120. The system private key is stored and the corresponding system public key is published and stored in all STTs including SDVR STT158-1. In this case, SDVR Module 165 in STT158-1 uses traditional public key cryptography to control access manager 225 in application server 220, with a message containing the content key encrypted using the system public key and STID 214. Send.

FIG. 8 is a flowchart showing a routine for generating the content key V-2 encrypted according to one embodiment. At step 427, manager 225 receives the encrypted content key and STID 214 in the message from SDVR STT158-1, and at step 430, the above system private key is used to decrypt the encrypted content key. , Recover the content key to a clear state. At step 431, manager 225 consults with the subscriber registry 360 and uses STID 214, which is MAC-1 in this example, to determine the associated subscriber ID, which is S-1 in this case. At step 432, manager 225 searches the subscriber key table 283 for the subscriber public key, ie SPUBKEY-1 associated with S-1. At step 435, the manager 225 uses the subscriber public key SPUBKEY-1 to encrypt the content key according to the second public key algorithm and generate the encrypted content key V-2. At step 440, manager 225 sends the encrypted content key V-2 to SDVR STT158-1 via the FDC.

After receiving the encrypted content key V-2 from the manager 225, module 165 stores the encrypted content key V-2 labeled 604 in storage device 610. In one embodiment, the encrypted content key V-2 is stored in the form of metadata associated with the encrypted content file 602. To decrypt the encrypted content file 602 to watch the movie content of "Citizen Kane", module 165 uses the DPRIKEY-1 in memory 212 to decrypt the associated encrypted content key V- 1 (603) can be decrypted and the content key can be recovered in a clear state. Module 165 then uses the recovered content key to decrypt the encrypted content file 602.

Unlike the above, the subscriber public key SPUBKEY-1 can be provided to STT158-1. In the same process used to create the encrypted content key V-1, module 165 can use SPUBKEY-1 to generate the decrypted content key V-2.

To prove the portability of the encrypted content file 602, assuming that subscriber S-1 purchases the SDVR STT158-2 for use as a second STT in his home, this subscriber will purchase the content file. Sometimes I want to transfer to SDVR STT158-2 and watch the program on a TV set connected to SDVR STT150-2. In contrast, if the SDVR STT158-1 is broken or is not functioning for some reason, the subscriber S-1 will be SDVR. You may want to see the stored programming content using STT158-2. In order to allow the subscriber S-1 to copy the programming content for this limited purpose, the present invention transfers the programming content stored in the first device (eg STT158-1) to the second device. It relies on an encrypted content key V-2 (604) that is not associated with any particular device to move to (eg STT158-2). More specifically, in order for the second device to obtain the content key for decrypting the copy of the encrypted content file in STT158-2, the second device has the associated encrypted content key V. Requires -1. According to the features of the present invention, the content key V-1 related to STT158-2 is an encrypted content key V-2 (provided that the subscriber related to STT158-2 is also S-1. You can succeed in deriving from 604). The subscriber is S-1 in the case of this specification, which is shown in the subscriber registry 360 in FIG. Next, referring to lines 368-1 and 368-2 in Registry 360, in this case both STT158-1 with MAC-1 address and STT158-2 with MAC-2 address are associated with S-1. ing.

The SDVR STT158-2 in Figure 9 (for example, the content file 602 and encryption encrypted from the SDVR STT158-1 by physically transferring the same storage device 610 as the storage device 910 from the SDVR STT158-1 to the SDVR STT158-2. Assuming that you have a copy of the encrypted content key V-2 (604) in storage 910, the STT158-2 encryption module 965 will have the content key V-2 (64) encrypted from storage 910. Search for STID 914 from 604) and memory 990. Module 965 sends a message containing the encrypted content key V-2 (604) and STID 914 to the headend 120.

The headend 120 uses an encrypted content key V-2 (604) and is an SDVR. Generates encrypted content key V-1 associated with STT158-2. This content key is necessary for STT158-2 to derive the content key for decrypting the encrypted content file 602. FIG. 10 is a flowchart showing a routine for generating an encrypted content key V-1 related to STT158-2 according to an embodiment of the present invention. At step 571, the manager 225 in the headend 120 receives the encrypted content key V-2 (604) and STID914 from the new device STT158-2. At step 572, Manager 225 consults with Subscriber Registry 360 and uses STID 914 (ie MAC-2) to determine the corresponding Subscriber ID (eg S-1). At step 573, manager 225 searches the subscriber key table 283 for the subscriber private key STRIKEY-1 associated with subscriber S-1. At step 574, Manager 225 decrypts the encrypted content key V-2 (604) using the subscriber's private key and recovers the content key in a clear state.

At step 576, manager 225 consults device key table 273 to find the device public key DPUBKEY-2 associated with STID 914, which is MAC-2 in this example. At step 577, Manager 225 uses the device public key DPUBKEY-2 associated with STT158-2 to encrypt the content key. The resulting encrypted version of the content key is referred to as the encrypted content key version 1 (V-1) of the new device (ND). At step 579, Manager 225 sends the ND encrypted content key V-1 to STT158-2 through the FDC.

Module 965 in SDVR STT158-2 receives the ND encrypted content key V-1 from the headend 120. Module 965 stores the ND content key V-1 in the storage device 910. At a later point in time, module 965 looks up the device private key DPRIKEY-2 from memory 912 and uses it to decrypt the ND encrypted content key V-1 and recover the content key. .. Module 965 can then use the content key to decrypt the encrypted content file 602 for viewing the movie content of "Citizen Kane".

In the second embodiment, a system-wide public / private key pair is used instead of the subscriber key pair stored in Table 283. The system public key is open to a group of STTs in the network. The system private key (not shown) is stored by the manager 225 in the headend 120, for example in memory 227. So, for example, in the second embodiment, after the SDVR STT158-1 uses the content key to encrypt the content file, resulting in the encrypted content file 602, the SDVR STT158-1 is in memory 210. The system public key (not shown) is used to encrypt the content key, thus generating the encrypted content key V-2. SDVR STT158-1 is associated with content file 602 and stores the encrypted content key V-2. It should be noted that the encrypted content key V-1 in SDVR STT158-1 remains the same as in the previous embodiment.

To achieve content file portability, the SDVR STT158-1 can transfer the content file and its internal encrypted content key V-2 to a second device, such as the SDVR STT158-2, SDVR STT158. The encrypted content key V-1 associated with -2 can be generated as follows. Module 965 in SDVR STT158-2 sends the received encrypted content key V-2 to the headend 120. Manager 225 in the headend 120 receives the encrypted content key V-2, looks up the system private key from memory 227, and uses it to decrypt the encrypted content key V-2. Recover the content key to a clear state. Manager 225 then consults device key table 273 to find the device public key DPUBKEY-2 associated with SDVR STT158-2. Manager 225 encrypts the content key using the device public key DPUBKEY-2 and generates the ND encrypted content key V-1. The encrypted content key for this ND is SDVR It is sent to STT158-2, where it is stored in storage 910 in relation to content file 602. The encrypted content key V-2 of this ND, which is also stored in the storage device 910, is the same as the encrypted content key V-2 received from the SDVR STT158-1. At a later point in time, module 965 can retrieve the device private key DPRIKEY-2 from memory 912 and use it to decrypt the ND encrypted content key V-1 and recover the content key. Module 965 then uses the content key to decrypt the encrypted content file 602 for viewing the movie content of "Citizen Kane".

In the third embodiment, the subscriber can transfer content from one device to another, for example via a home network, without the involvement of the headend 120 and specifically the control access manager 220. For example, subscriber S-1 sets up a home network in his home and connects both SDVR STT158-1 and SDVR STT158-2 to the network. As mentioned earlier, the movie "Citizen Kane" is stored in the storage device 610 of the SDVR STT158-1 in the form of an encrypted content file 602. Suppose subscriber S-1 wants to transfer a copy of the encrypted content file 602 from SDVR STT158-1 to SDVR STT158-2. FIG. 11 is a flowchart showing a routine for transferring one such content file from the first device to the second device. The SDVR STT158-2 acts as an initiator and sends a request for a copy of the content file 602 to the SDVR STT158-1. SDVR The STT158-2 can also send its device public key (DPUBKEY-2 in this example) to the SDVR STT158-1.

Module 165 receives the request and the device public key associated with the SDVR STT158-2 (step 1105) and responds by identifying the desired content file 602 in storage 610. At step 1120, module 165 looks up the encrypted content key V-1 (603) from storage 610. At step 1125, module 165 looks up DPRIKEY-1 from memory 212, uses DPRIKEY-1 (at step 1130), decrypts the encrypted content key V-1 (603), and decrypts the content key. Recover to a clear state. At step 1150, module 165 uses the received DPUBKEY-2 to encrypt the recovered content key. The resulting encrypted version of the content key is the ND encrypted content key V-1. At step 1160, module 165 sends the ND encrypted content key V-1 to the SDVR STT158-2 along with a copy of the encrypted content file 602.

Module 965 in SDVR STT158-2 receives the ND encrypted content key V-1 from SDVR STT158-1. Module 965 stores the content key V-1 of the ND and the content file 602 in the storage device 910. At a later point in time, module 965 looks up the device private key DPRIKEY-2 from memory 912 and uses it to decrypt the ND encrypted content key V-1 and put the content key in a clear state. Recover. Module 965 can then use the content key to decrypt the encrypted content file 602 to view the content of the movie "Citizen Kane".

Since the above description is merely for explaining the principle of the present invention, those skilled in the art will embody the principle of the present invention, and thus various other devices within the scope of the gist of the present invention. Let's come up with it.

For example, an STT is used as illustrated in the above embodiment, but in addition to or in place of such an STT, another equivalent device, or a functionally equivalent device (eg, a point of deployment (POD)). ) Or CableCard® device) can also be used.

Further, in the embodiment shown in FIG. 1, the transport of the network is realized using the HFC cable network 150 as shown. However, other networks such as Digital Subscriber Line (DSL) networks, Ethernet® networks and satellite networks can be used instead.

Finally, the present specification discloses the system components of FIG. 1 in a form in which various functions are executed by discrete functional blocks. However, one or more functions of these blocks, or all of them, can be similarly embodied, for example, within a device implemented by one or more properly programmed processors.