Source authentication of download information in a conditional access system

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

(Related patent application) The present invention is a partial continuation of the following US patent application, all of which are entrusted to a designated agent of this US patent application. [0002]

US Patent Application No. 08 / 765,535 of Robert O. Banker and Glendon L. Akins III, filed December 16, 1996, Preventing Replay Attacks on Digital Information Distributed by Network Service Providers. [0003]

US Pat. No. 5,742,677 of Pinder et al., Information Terminal Having Reconfigurable Memory, filed April 3, 1995. [0004]

US Patent Application No. 08 / 580,759 by Wasilewski et al., Filed December 29, 1995, Method and MFP for Providing Conditional Access in Connection-Oriented Interactive Networks with a Multiplicity of Service Providers. [0005]

US Patent Application No. 09/111,958 by Seaman et al., Filed July 8, 1998, Mechanism and MFP for Encapsulation of Encapsulation Authorization in Conditional Access System. [0006]

The patent application also claims priority under US Patent Application No. 60 / 054,575 by Wasilewski et al., Conditional Access System, filed August 1, 1997. Furthermore, this application is one of seven applications with the same detailed description. All of these applications have the same filing date and the same designated agent. The names of the other six applications are as follows. [0007]

(D-3318), Wasilewski et al., Conditional Access System, filed July 31, 1998. [0008]

(D-3373), Method and MFP for Geographically Limiting Service in a Conditional Access System, by Akins et al., Filed July 31, 1998. [0009]

(D-3457), Authorization of Services in a Conditional Access System, by Wasilewski et al., Filed July 31, 1998. [0010]

(D-3472), Akins et al., Representing Entitlements to Service in a Conditional Access System, filed July 31, 1998. [0011]

(D-3365), Pinder et al., Encryption Devices for use in a Conditional Access System, filed July 31, 1998. [0012]

(D-2999), Pinder et al., Verification of the Source of Program Information in a Conditional Access System, filed July 31, 1998. [0013]

(Field of invention) The present invention relates to a system for protecting information, and more particularly to a system for protecting information transmitted by a wired or wireless medium from unauthorized access. [0014]

(Background of invention) One way to distribute information is to broadcast it, that is, to distribute the information to a medium and receive it by any device that communicates with that medium. Television and radio are well-known broadcast media. If you want to distribute information and make money through broadcast media, there are two options. The first is to find sponsors who will pay to broadcast the information. The second is to allow only those who have paid the price access to the broadcast information. This is generally done by broadcasting the information in a scrambled or encrypted form. Any device connected to the medium can receive the scrambled or encrypted information, but only the device of the user who paid for access to the information can descramble or decrypt the information. [0015]

Service distribution agencies, such as CATV companies or satellite television companies, provide information to subscribers from a number of program sources, i.e. a collection of certain types of information. For example, a history channel is a program source that provides a television program about history. Each program provided by the History Channel provides an "instance" of its program source. When a service distribution agency broadcasts an instance of a program source, it encrypts or scrambles the instance to generate a cryptographic instance. Cryptographic instances contain instance data. This is the cryptographic information that makes up the program. [0016]

The crypto instance is broadcast via the transmission medium. The transmission medium can be wireless or is "wired", i.e. supplied via wire, coaxial cable, or optical cable. Cryptographic instances are received by a number of set-top boxes. The function of the set-top box is to determine if the crypto instance should be decrypted, and if so, decrypt it to generate the decryption instances that make up the program. This information is transmitted to the television set. Known set-top boxes include decryptors that decrypt crypto instances. [0017]

The subscriber generally purchases the service on a monthly basis (although the service may be completed once), and after the subscriber purchases the service, the service distribution agency provides the authority information for the purchased service. Send a set-top box that belongs to the subscriber message required to provide. Permission information can be sent with the instance data or to a set-top box via a separate channel, such as an out-of-band RF link. Various techniques have been used to decrypt authority information. The authority information may include a key for the service of the service distributor and an indication of which program of the service the subscriber has registered to watch. If the subscriber is registered to watch the crypto instance program and the permission information is displayed, the set-top box decrypts the crypto instance. [0018]

It should be understood that "encryption" and "scramble" are similar processes, and "decryption" and "descrambling" are similar processes. The difference is that scrambling and descrambling are generally analog in nature, but the encryption and decryption processes are usually digital. [0019]

Access control is required for both analog and digital systems. In all systems, access restrictions have been overcome by making full use of constant technological improvements, and there is a need for safer and more flexible access restrictions. As more systems switch from analog to digital, or hybrid systems that include both analog and digital formats, flexible access restrictions are needed. [0020]

Restricting access to broadcast information is more important in digital information. The reason for this is that, first of all, each copy of digital information is as good as the original. Second, digital information can be compressed, and as a result, in digital form, a given amount of bandwidth carries much more information. Third, the service distributor provides a return route that allows messages to be sent from the set-top box to the service distributor, allowing for a variety of interactive services. [0021] [0021]

Therefore, service distribution agencies require safer and more flexible access restrictions than traditional systems. [0022]

(Detailed description of preferred embodiments) The reference code in the figure has at least 3 digits. The right two digits are the reference codes in the figure. The numbers to the left of them are the numbers in the figure where the member indicated by the reference code first appeared. For example, the member of reference numeral 203 first appears in FIG. [0023]

The following detailed description first provides a general introduction to conditional access systems and encryption and decryption, and then how service instance encryption and decryption is performed in a preferred embodiment. Describe and based on this, the techniques used in the preferred embodiments for certifying the ECM and EMM of the preferred embodiments will be described. The detailed description then describes how EMMs can be used to dynamically add and remove access to services and the role of encryption and authentication in their operation. Finally, how the techniques described above are used in broadcast data distribution with node structures and reply paths from set-top boxes to headends, and in preferred embodiments, security processors to protect keys and registration information. And how the memory is used and how a given operation is performed in a preferred embodiment. [0024]

(Overview of conditional access system) FIG. 1 provides an overview of System 101 for restricting access to broadcast information. Such a system is referred to as a "conditional access system". A service distribution agency 103, such as a CATV company or satellite television company, provides subscribers with information from many services, a set of information of a predetermined type. For example, the History Channel is a service that provides a television program on history. Each program offered by the History Channel is an "instance" of that service. When a service distributor broadcasts an instance of a service, it encrypts or scrambles the instance to generate a cryptographic instance 105. Cryptographic instance 105 includes instance data 109, which is cryptographic information constituting the program, and registration control message (ECM) 107. The registration control message contains the information necessary to decrypt the encrypted portion of the associated instance data 109. A given registration control message is sent several times per second and is immediately available to any new viewer or service. To make it more difficult for the infringer to decrypt the instance data 109, the content of the registration control message is changed every few seconds or more often. [0025]

The crypto instance 105 is broadcast via the transmission medium 112. The medium can be wireless or "wired", i.e. supplied via wire, coaxial cable, or optical cable. Cryptographic instances are received by a number of set-top boxes 113 (0 ... n), each set-top box connected to a television set. The function of the set-top box 113 is to determine if the crypto instance 105 should be decrypted, and if so, decrypt it to generate the decryption instance 123 that is transmitted to the television set. As detailed with reference to set-top box 113 (0), set-top box 113 includes a decryptor 115 that uses the control word 117 as a key to decrypt the crypto instance 105. The control word 117 is generated by the control word generator 119 from the information contained in the registration control message 107 and the authority information 121 stored in the set-top box 113. For example, authorization information 121 may include a key to the service and an indication of which program of the service the subscriber has registered to watch. If authorization information 121 indicates that the subscriber is entitled to view the program on crypto instance 105, control word generator 119 uses this key along with information from ECM 107 to generate control word 117. To do. Of course, a new control word is generated for each new ECM107. [0026]

The authority information used in the particular set-top box 113 (i) is obtained from one or more registration management messages 111 addressed to the set-top box 113 (i). The subscriber generally purchases the service on a monthly basis (although the service may be completed once), and after the subscriber purchases the service, the service distribution agency 103 registers the subscriber upon request. Sends set-top box 113 (i) belonging to management message 111 to provide the required authorization information 121 for the purchased service. The registration management message (EMM) is sent in the same manner as the ECM107, interleaved with the instance data 109, or sent to the set-top box 113 (i) via a separate channel, such as the bandwidth perimeter RF link. Obtain, store the information from the registration management message (EMM) 111 in the authority information 121. Of course, various techniques have been used to encrypt registration management information. [0027]

(General encryption and decryption) The encryption and decryption techniques used to encrypt and decrypt service instances fall into two general categories. That is, symmetric key technology and public key technology. In symmetric key encryption technology, each entity wishing to communicate has a copy of the key. The sending entity uses key duplication to encrypt the message, and the receiving entity uses key duplication to decrypt the message. An example of a symmetric key encryption / decryption system is the Digital Encryption Standard (DES) system. In a public key cryptosystem, each entity wishing to communicate has its own public / private key pair. Messages encrypted with a public key can only be decrypted with a private key, and vice versa. Thus, as long as a given entity keeps the private key secret, it can provide the public key to any other entity that wants to communicate. Other entities simply encrypt the message they want to send to a given entity with the public key of the given entity, and the given entity decrypts this message with the private key. The private key can also be used for digital signature processing and provides authentication. For more information on cryptography in general and specific symmetric and public key cryptography, see Bruce Schneier's Applied Cryptography, John Wiley and Sons, New York, 1994. [0028]

Designing an encryption system for a given application requires a lot of consideration. As shown below, some of the most important considerations in a broadcast message environment include: Key security: If a third party has access to a key shared by a communicator, the symmetric key system is useless and someone other than the owner of a given public key can access the corresponding private key. If so, the public key system is also useless. Proof of Key: How does the recipient know that the key he receives is the key that belongs to the entity that he really wants to send the encrypted message to, not the key that belongs to another entity that he wants to block the message? Do you confirm it? · Message Authentication: How does the recipient of a message verify that the message is from the person as indicated and / or that the message has not been modified? Cryptographic and decryption speeds: Symmetric key cryptosystems are generally faster than public key cryptosystems and are preferred for use in real-time media. Key size: The longer the key commonly used in an encryption system, the more resources it takes to break the encryption and thus gain access to the message. [0029]

All of the above considerations are influenced by the fact that the environment in which the conditional access system operates must be inferred to be hostile. Many broadcast service customers do not consider deceiving the service provider to be particularly bad, and can physically tamper with parts of the conditional access system contained in the receiver or use various crypto-attacks to key it. I don't feel like stealing or deceiving the recipient about the source of the message they receive. Moreover, the provider of the system that actually broadcasts the service does not necessarily have the same interests as the provider of the service content, so not only who accesses a given instance of the service, but which entity You also need to control the ability to service a given recipient. [0030]

(Service Instance Encryption and Decryption: Figures 2A and 2B) In general, the cryptosystem according to the invention uses symmetric key cryptography to encrypt and decrypt service instances and uses public key cryptography to be used in service provider key symmetric key technology. Transport one copy of the key to the set-top box. [0031]

In Figure 2A, a clear service, such as an elementary digital bitstream containing an MPEG-2 program, is transmitted via a first level of encryption called Program Encryption Function 201. The program encryption function 201 is preferably a symmetric cipher such as a well-known DES algorithm. Each elementary stream is individually encrypted and the generated cipher stream is sent to the MUX200 to be combined with other elementary streams and private data such as conditional access data. The key used for the program encryption function 201 is called the control word (CW) 202. CW202 is generated by the control word generator 203. The control word generator 203 is either a physical random number generator or a sequential counter with a suitable random algorithm for generating a stream of random CWs. counter) can be used. New CWs are generated frequently, perhaps once every few minutes, and are given to each elementary stream on the same time scale. Each new CW is encrypted by the control word encryption and message authentication function 204 using the multi-session key (MSK) 208 provided by the multi-session key (MSK) generator 205. The CW will then be incorporated into the ECM107 along with other service-related information. The ECM107 is authenticated by the control word encryption and message authentication function 204. The control word encryption and message authentication function 204 uses a keyed hash value derived from the message content combined with a secret that can be shared in the inbound set-top box 113 to generate a message authentication code. This secret is preferably part of all MSK208. The message verification code is attached to the rest of the ECM107. The CW200 is always encrypted before being sent to the MUX200 along with the rest of the ECM. This cipher is preferably a symmetric cipher, such as the triple DES algorithm, which uses two different 56-bit keys (combined to form the MSK208). [0032]

MSK208 has a longer life than CW202. The lifespan of an MSK is typically hours to days. The MSK208 is both encrypted and digitally signed by the MSK encryption and digital signature function 206 before being transmitted to the MUX200 enclosed in the EMM111. [0033]

Other parts of the MSK208 and EMM111 are preferably encrypted using a public key algorithm, such as the well-known RSA algorithm, along with the public key associated with the particular set-top box 113 to which the EMM is addressed. .. The public keys of all set-top boxes 113 in system 101 are stored in public key database 207. The public key in this database is preferably certified by a certification authority. The digital signature feature in 206 is preferably an RSA digital signature method, but others may be used. In the case of RSA digital signatures, the private key used to sign belongs to the registration agent within the service distribution agency 103, which is responsible for authenticating related services. [0034]

In Figure 2B, the corresponding DHCT private key and associated DHCT public security microserial number are stored in memory 232 of the decoder 240. By being provided with a public security microserial number, the demultiplexer 230 may select a cryptographic multisession key addressed to the decoder 240 from the transport data stream (TDS). Encrypted multi-session key E_KprIs decrypted in decoder 234 using the DHCT private key from memory 232 to provide a multi-session key MSK. The demultiplexer 230 also uses a TDS-encrypted control word (CW) E from the transport data stream._MSKSelect (CW). The cryptographic CW is processed by the decryptor 236 using the multi-session key MSK as the decryption key to provide the unencrypted CW. The unencrypted CW preferably changes at a high speed, eg, once every few seconds. The demultiplexer 230 is a TDS-encrypted service E from the transport data stream._CWAlso select (SERVICE). The cryptographic service uses CW as the decryption key and is processed by the decryptor 238 to restore the unencrypted service. [0035]

(Detailed implementation of the encryption system in Figure 2: Figure 3) FIG. 3 provides in more detail a suitable implementation of the system of FIG. The encryption / decryption system 301 has two main elements. That is, the service start element 305 and the service acceptor element 333. The two are connected by a transmission medium 331. The transmission medium 331 can be any medium that carries a message from the service start element 305 to the service acceptor element 333. The service receiving element 333 is implemented in a set-top box and is referred to herein as a digital home communication terminal (DHCT). However, the service receiving element 333 may be implemented in any device having the required computing power, such as a personal computer, workstation, or "intelligent" television set. In the service start element, at least the portion labeled 306 is implemented in equipment located at the head end of the broadcast system, such as cable television (CATV) or satellite TV systems. However, in some embodiments, the headend may be supplied with an encrypted instance of the service. The remaining portion 308 may also be located at the headend, but may be located anywhere with some access to the headend 306 and the service accepting element 333. The latter is especially the case when the EMM is transmitted out of bandwidth by a wide area network such as the Internet. Further, the transmission medium can be a storage medium, where the service start point can be the manufacturer of the medium, and the service receiving element can be an element that reads the storage medium. For example, the transmission medium can be a CD-ROM, DVD, floppy disk, or any other medium that can be physically, electrically, or otherwise transferred. [0036]

First, in the service start portion 305, the random number generator 307 is used to generate the MSK309. Next, EMM315 including MSK309 and related information are generated. EMM315 also includes a sealed digest. The sealed digest has two purposes. Make sure that the information placed on the EMM 315 by the service start 305 is the same as the information that arrived at the DHCT333, and that the information actually came from the entity entitled to access the service. Is to confirm. [0037]

The sealed digest is generated in two stages. First, the digest of the EMM content (here MSK309 and related information) is generated by hashing with a security one-way hash function, forming a relatively short bitstring. The security one-way hash function has three attributes. -Content hashed to form a short bitstring cannot be defined by that short bitstring. -Any change by hashing forms a short bitstring change. The construction of different messages that form the same short bitstring as the EMM is computationally infeasible. [0038]

Therefore, the output of the short bitstrings of the hash function can be used to determine if the EMM content has been modified in the transfer without publishing the content. A preferred embodiment uses the message digest 5 one-way hash function indicated by the code MD5. For details on the one-way hash function, refer to the above-mentioned Schneier literature. The digest is a sealed digest. This is because the digest is encrypted with the public key SPKr310, which belongs to the Registration Agent (EA), which has the right to give the DHCT access to the service that uses the MSK to generate the key. The digest must be decrypted using the registered agent's public key before the sealed digest can be used to ensure that the EMM is being sent correctly. Therefore, the sealed digest convinces the DHCT that the EMM content was transmitted correctly and that the EMM source is a registered agent. [0039]

Once the sealed digest is generated, the EMM content (here MSK309 and related information) is encrypted with the public key DHCTKu312 of the DHCT333 to which the EMM315 is addressed, and the EMM315 contains the encrypted content and the sealed digest. Is transmitted to the DHCT333 via the transmission medium 331. In the following, the code Kr is used to indicate the private key and the code Ku is used to indicate the public key. The code RSA indicates that the encryption is done using the well-known RSA public key algorithm. [0040]

As shown in DHCT333, EMM315 can only be encrypted by DHCT333, whose private key 337 (DHCT Kr) corresponds to the public key used to encrypt EMM315. The DHCT333 decrypts the EMM315 and uses the sealed digest to determine if the EMM315 was sent correctly. This decision is made by the registration agent using the public key SP Ku335 to decrypt the sealed digest. The EMM315 content is then hashed using the same security one-way hash function that was used to generate the digest. If the result of this hash is the same as the decrypted sealed digest, the decision is successful. If the transmission to the DHCT333 is tampered with (garbled) during transmission, or if the DHCT333 does not have a private key that corresponds to the public key used to encrypt the EMM (ie, the EMM315 is not the intended DHCT333). ), Or the corresponding public key 335 (SP) that corresponds to the private key used to generate the sealed digest. If the DHCT333 does not have Ku), the confirmation of the sealed digest will fail. The latter is when the DHCT333 does not have access to the services provided by the registration agent. The EMM315 addressed to the DHCT333 is sent repeatedly. As a result, if the problem is tampering in transit, the untampered EMM315 is immediately received and the decision is successful. How the DHCT333 will have the SP Ku335 needed to decrypt the sealed digest will be explained in detail later. [0041]

The next step in the service start 305 is to generate the control word 319 that actually encrypts the service instance 325 and to carry the information needed to decrypt the service instance to the DHCT333. The control word 319 is generated by the random number generator 317. This can be a true random number generator, the output of which is the result of some basic underlying random physical process, or, for example, using MSK as a key (per use). It is another means such as the result of encrypting a value called a "counter" with 3DES. For true random numbers, the encrypted control word is sent to the ECM. For counter-based control word generation, a clear version of the "counter" is used in the transmitted ECM. As mentioned above, the control word is a short-term key, i.e. a lifetime of a few seconds or less. Included in ECM323 is a digest of the content and an MSK generated using the MD5 one-way hash mentioned above. Including the MSK in the digest generation gives the registered agent to which the ECM323 belongs a shared secret with the DHCT333 registered to receive the service instance from the registered agent, resulting in the ECM323's "spoofing", ie. , Prevents the acquisition of ECM323 from sources other than registered agents. As will be described in detail later, a preferred embodiment generally uses a shared secret technique to authenticate a message, including a message having a real-time value for an instance of the service. [0042]

The ECM323 is sent to the DHCT333 along with the cryptographic content 329. The first ECM323 for a given portion of the cryptographic content 329, of course, arrives at the DHCT333 before the cryptographic content arrives. In a preferred embodiment, the content 325 and ECM323 are encoded according to the MPEG-2 standard. This standard provides a transport stream that contains a large number of element streams. One of them carries content 329, another carries ECM323, and the third carries EMM315. Only the stream carrying content 329 is encrypted by DES329. This is because the control words in ECM323 and the contents of EMM315 are already encrypted and do not require further encryption when transmitted by the MPEG-2 transport stream. The mode in which EMM and ECM are transported by the MPEG-2 transport stream will be described in detail later. [0043]

When the ECM323 is received by the DHCT333, the control word 319 is discovered by decrypting or using the MSK to encrypt the counter value at 343. The integrity of the ECM323 content is confirmed by comparing the content with the resulting value of hashing some or all MSKs (based on cryptographic principles) in a one-way hash function, along with the message digest contained in the EMC323. To. Included in the content is the control word 319 and information that identifies the service instance 325 with the ECM323. The identity information is used with the authorization information received by the EMM 315 to determine if the DHCT333 has been authenticated to receive the service instance 325. If so, the control word 319 is used by the service decryptor 347 to decrypt the encrypted content and generate the original content 325. [0044]

System 301 offers a number of security benefits. Where speed is needed, it takes advantage of the speed of the symmetric encryption system to decrypt the control words in the encrypted content 329 and ECM323. The control word is protected by being encrypted using the MSK, and the ECM323 is authenticated by using some or all of the MSK309s as a shared secret between the registration agent and the DHCT333. The MSK309 then contains the fact that it was sent in an EMM encrypted using the DHCT's public key, and the fact that the EMM contains a sealed digest encrypted using the registration agent's private key. Protected by. Further security is provided by the fact that the authorization information received by the EMM 315 before the control word 319 is delivered to the service decoder 347 must match the service identification information from the ECM 323. For example, as detailed in the Banker and Akins parent applications mentioned above, a single use of the information in ECM323 and EMM315 prevents what is called a "replay attack" on cryptographic services. .. In addition to being safe, System 301 is flexible. The authorization information contained in the EMM315 and the service identification information contained in the ECM323 allow extensive access to the service instance received by the DHCT333. [0045]

(Dynamic provision of multiple registration agents to DHCT333: Figure 4) A sealed digest in EMM315 means that DHCT333 will not respond to EMM315 unless DHCT333 has a public key for the registration agent who has the right to grant registration to the service decrypted by MSK in EMM315. This is part of a broader arrangement that dynamically provides one or more registration agents to the DHCT333 and dynamically removes the registration agents provided by the DHCT333. [0046]

The entity that provides or removes registration agents is called the Conditional Access Authority (CAA). This arrangement further allows the registration agent provided to the DHCT333 to dynamically modify their authority information in the DHCT333. All information needed to perform these actions is sent via the EMM, along with a sealed digest. The sealed digest is used to ensure that only the CAA can add or remove registered agents, and only the registered agent to which the authority information belongs can modify the authority information. [0047]

The above arrangement has a number of advantages. -Enables multiple registration agents. -Enables dynamic addition and deletion of registered agents. Limits the services that registered agents can allow registration, but allows registered agents to manage their authority information. -Separate the business that provides the service and registration to the service instance from the business that actually provides the instance of the service. As a result, the CATV operator simply acts as a distribution utility. -Separate the business that grants the entity the right to be a registration agent from the business that is a registration agent. Provide an easy way for customers to change registered agents according to their beliefs. The DHCT333 provides a secure arrangement that allows the reply route to communicate with the registration agent, conditional access authority, or possibly the provider of the service instance. [0048]

FIG. 4 shows how this arrangement is implemented in a preferred embodiment. Figure 4 is best understood as an extension of Figure 3. Both Figures 4 and 3 have the same key elements. That is, the service start 305, the DHCT333, and the transmission medium 331 that combines the two. In addition, a cipher 313 and a decryptor 339 are used in both figures. Also, as indicated by reference numeral 308, the EMM is transmitted with the service instance or via another channel. In addition, FIG. 4 shows an additional element of the DHCT333, the EMM manager 407. EMM manager 407 is implemented by software running on the security processor in the DHCT333. The task of EMM Manager 407 is to respond to EMMs that add or remove enrollment agents and EMMs that modify authentication for enrollment agents. EMM manager 407 further supplies messages depending on which DHCT333 can communicate with the registration agent or conditional access authority. [0049]

First, an EMM is generated that modifies the entitlement information of the enrollment agent in response to the modification information 403 provided by the enrollment agent or requested by the network operator. As shown in 313, the modified information has a sealed digest encrypted using the public key 312 for the DHCT333 and encrypted using the private key 310 for the registration agent. The generated authority modification EMM405 is transmitted to the decoder 339 included in the DHCT333 via the transmission medium 331. Here, the authority modification EMM405 is decrypted and confirmed in the manner described above with respect to the EMM315 included in the MSK. However, the EA modification information 403 contained in the EMM proceeds to the EMM manager 407, which uses this information to modify the authority information for the registered agent in the DHCT333. Examples of modifications include adding or canceling services provided by the registration authority and changing the conditions under which access to an instance of a given service is granted. [0050]

As mentioned above, the sealed digest is encrypted with the registration agent's private key. As a result, the validity of the EMM can only be determined if the DHCT333 has the public key of the enrollment agent. The public key to the enrollment agent is provided to the DHCT333 by the Conditional Access Authority by the EA Assignment EMM413. EMM413 contains registration agent allocation information 409 from the conditional access authority. At a minimum, the registration agent allocation information 409 includes a public key for the registration agent, and also includes information about the amount of memory the registration agent has in the DHCT333 and the types of services that the registration agent can provide. For example, registration agents may not be allowed to provide interactive services. Information 409 is encrypted with DHCT333's public key 312, and the sealed digest is encrypted with Conditional Access Authority's private key 411. [0051]

In DHCT333, EMM413 is decrypted using the private key 337 belonging to DHCT333, and the sealed digest is decrypted using CAA's public key 415. If the digest confirms the correctness of the EMM content, the EMM manager 407 allocates a storage location for the registration agent whose public key is contained in the EMM 413. Once this is done, the EMM manager 407 places the registration agent's public key in the storage location. This storage location provides a location to store the registration agent's public key, the authority information for the services and service instances provided by the registration agent, and the MSK provided by the registration agent. Once the DHCT333 has the enrollment agent's public key and the enrollment agent's authority information and storage location for the MSK, the EMM manager 407 can respond to the EMM from the enrollment agent. Of course, in order to decrypt the sealed digest, the DHCT333 must have the public key 415 for the conditional access authority. As will be shown in more detail later, in a preferred embodiment, the public key 415 and the public and private keys for the DHCT333 are installed on the DHCT333 when it is manufactured. [0052]

When a customer orders a service, the above-mentioned arrangement interacts as follows. 1. If the customer's DHCT333 is serviced by a registration agent that does not have a public key, the conditional access authority must first send the EA assignment EMM413 to the DHCT333. EMM manager 407 responds by allocating a storage location for the registration agent. Only conditional access authorities can send EA allocation EMM413, so that the conditional access authority (CAA) can control access by registered agents to customers of a particular service distribution agency. 2. If the DHCT333 has the registration agent's public key, at some point in the past, step (1) has been performed or has been performed, so the registration agent will modify it along with the newly ordered service or service instance. Send EMM405 to DHCT333. EMM manager 407 responds by storing the privilege information in the allocated space. 3. Once step (3) is complete, the DHCT333 can receive the EMM315 along with the MSK for the service from the registration agent. EMM manager 407 stores the MSK in the allocated space. 4. When the actual service instance is sent, it is accompanied by an ECM containing the current control word. The MSK is used to decrypt the ECM, and the control words obtained from the ECM are used to decrypt the instance of the service. [0053]

Therefore, the use of EMM and ECM described above to control access to an instance of a service is that the registration agent cannot access the DHCT333 without the permission of the conditional access authority and that the registration agent does not allow the service to be serviced by the registration agent. Guarantee that you cannot access an instance of. It also allows the registration agent to have full control over the service. Access to the service is defined by EMM 405 and 315, which may be sent by the registration agent to the DHCT333 independently of the service distributor. In addition, it is the registration agent that provides the MSK used to generate the control word and decrypts the ECM to both the service distributor and the DHCT333. In fact, if the registration agent wants to do so, it can provide a cryptographic instance of the service to the service distributor on its own, in which case the service distributor simply acts as a route between the registration agent and the DHCT333. .. [0054]

(Message security transmission via return route) Figure 4 also shows how EMM security technology also secures messages sent from the DHCT333. The example shown in Figure 4 is a transfer purchase message (FPM). Transfer purchase messages are used for interactive purchases of instances of the service. An example of such a purchase is what is called an impulse-pay-per-view or IPPV. In such a system, the beginning of an event, such as a baseball game, is commonly broadcast, deciding whether the customer wants to see everything. In that case, the DHCT333 must be provided with an input indicating that it wants to see the entire event. The EMM manager 407 responds to the input by generating an FPM and sending it to the registration agent, which ensures that the registration agent can charge the customer for the event and the DHCT333 can continue to decrypt the event. Send EMM315. The information required by the registration agent is transfer registration information 417. To ensure customer privacy, this information is encrypted with key 420 using the 3DES algorithm and provides encrypted transfer registration information 419, as shown in 343. Key 420 consists of two 56-bit DES keys. The 3DES encryption process is a sequence of three DES processes. That is, encryption using the first DES key, decryption using the second DES key, and encryption using the first DES key. Key 420 is then encrypted using the registration agent's public key 335 and a sealed digest is generated using the DHCT333's private key. All of these parts together make up a forwarding purchase message 421 that addresses the registration agent. [0055]

The registration agent decrypts key 420 using the registration agent's private key 310 and decrypts the sealed digest using DHCT's public key 312. The encrypted transfer registration information (EFEI) 419 contained in FPM421 is determined to have not been tampered with and passed to 3DES decryption 443. The 3DES decryption 443 decrypts using the key 420 and provides the transfer registration information 417 to the registration agent. Immediately obvious, the same technique can be used to send a message to any entity for which the DHCT333 has a public key, with or without 3DES encryption of the content of the message. At a minimum, this includes CAA and any enrollment agent assigned within the DHCT333. [0056]

(Authentication of global broadcast message) Global broadcast messages are those that are not addressed to any individual DHCT333 or any group of DHCT333. In a preferred embodiment, the global broadcast message accompanies an instance of the service and includes relevant information corresponding to the accompanying instance. As a result, the encryption and authentication techniques used for global broadcast messages enable high-speed decryption and authentication verification. An example of a global broadcast message is ECM. Another example is the various types of global broadcast authentication messages, namely GBAM. ECM needs to prevent spoofing of global broadcast messages, which is done in the same way as ECM. More specifically, a digest is generated using some or all MSKs with the content of the global broadcast message. Therefore, the MSK acts as a secret shared between the registration agent and the DHCT333. Upon receiving the global message, the EMM manager 407 uses the content of the received message and the MSK to generate a digest and responds to the received message only if the digest matches what is contained in the message. The advantage of using the MSK-generated digest to authenticate global broadcast messages is that the digest is generated and verified very quickly. [0057]

(Implementation of conditional access system in digital broadcasting distribution system) The conditional access system has been described above from the viewpoint of ECM, EMM, and other messages, and from the viewpoint of how the message and its digest are encrypted and decrypted. The conditional access system described above allows an instance of the service to be propagated to the DHCT along with an ECM or other broadcast message, allowing the DHCT to receive the EMM from the conditional access authority and one or more registration agents. Works with any communication arrangement. However, conditional access systems are particularly well suited for use in modern digital broadband transmission systems, and the following describes how conditional access systems are implemented in such transmission systems. [0058] [0058]

(Overview of Digital Wideband Transmission System: Figure 5) Figure 5 provides an overview of the Digital Wideband Transmission System (DBDS) 501. The DBDS501 includes an infrastructure 503, a headend 515, a carrier 517, a hub 519 (0 ... n), an access network 521 (0 ... n), and a digital home communication terminal (DHCT) 333. The service infrastructure is the service provision in the value-added service provider (VASP) system 509, which is a system that provides services to the broadband transmission system, and the digital network control system (DNCS) 507, DBDS501 that manages and controls the services provided by the DBDS501. A core network that interconnects elements of the management gateway (AG) 505, which is the source of privilege information, the network management system (NMS) 511, which maintains a database of system state and performance information, and other service infrastructure 503, to the headend 515. Includes 513. In a preferred embodiment, the core network 513 includes ATM-based switching and transmission functions. The headend 515 provides an interface between the service infrastructure 503 and the transport infrastructure 517. The transport board 517 provides a high bandwidth interconnect from the headend 515 to the hub 519 (0 ... n). Each hub 519 (i) provides access network 521 (i), which includes hybrid fiber coaxial (HFC) node 523 connected from the coaxial bus network to DHCT333. Therefore, a given DHCT333 (k) in DBDS501 belongs to HFC node 532 (j) in access network 521 (i). The transport board 517 and the access network 523 provide only transfer channels from the headend 515 to a given DHCT333 (k), but may preferably provide both transfer channels and return routes. Each instance of DBDS501 generally provides services in metropolitan areas. [0059]

DBDS501 can be implemented in a variety of configurations and adapts to the context of a particular service environment. For example, headend equipment can be deployed within headend 515, inside hub 519 (i), or as part of VASP system 509. The DNCS element 506 can be deployed within the headend 515 or is distributed within the hub 519. The transport board 517 may utilize SONET add / drop multiplexing, analog fiber technology, or other transport technology. [0060]

(Overview of Conditional Access System: Figure 6) FIG. 6 shows the elements of a preferred embodiment of the conditional access system 601 in the DBDS 501. Conditional access system 601 is a collection of elements DNCS507, headend 515, and DHCT333 that together provide security and conditional access services. [0061]

The elements of the conditional access system 601 perform the following functions: 1. Service content encryption 2. Control word encryption used for service encryption 3. ECM authentication included in the cryptographic control word 4. Delivery of ECM to DHCT 5. Managing the subscriber authority database 6. EMM encryption and authentication including subscriber registration information 7. EMM delivery to DHCT 8. Decryption of EMM and confirmation of its validity in DHCT 9. Response to EMM by modifying authorization information in DHCT 10. Response to ECM by authenticating ECM, decrypting control words and confirming registration with DHCT333 11. Decryption of service content if ECM is legitimate and authentication is permitted These requirements are met by Conditional Access System 601: [0062]

Stream cipher and ECM streamer module 620 in headend 515, Control suite 607 in DNCS507. Transaction cryptographic device 605 in headend 515 with security link to I.DNCS507 II. Service Decoder Module in DHCT333 625 III. Security Manager Module in DHCT333 626 IV. DHCTSE627 in DHCT333 Figure 6 shows a typical configuration of these elements for security digital services within the DBDS501. These elements will be described in more detail below. [0063]

(Service Encryption and ECM Streamer Module 620) The service encryption and ECM streamer (SEES) module 620 is an element of the QAM module 619 that operates under the command of control suite 607 and is the MPEG-2 used in a preferred embodiment for transmitting service content 325. Encrypt transport stream packets. As shown in FIG. 6, service content 325 may be received from a source such as digital satellite distribution system 613, digital terrestrial distribution system 611, or media server 609. The media server 609 may be connected to the headend 515 by a high bandwidth built-in gateway 615. SEES620 uses MSK309 to generate control word 319 used for service encryption and ECM323 to carry control word 319 along with cryptographic service content 329 in the output MPEG-2 transport stream. To do. The SEES620 encrypts the control words in the ECM323 with the MSK309. The MSK is generated by the TED603 and sent to the SEES620 in encrypted form for messages such as EMM. [0064]

(DHCT333) The DHCT333 is connected between the HFC network 521 and the customer's television set. The DHCT333 receives and interprets EMMs, ECMs and GBAMs and decrypts instances of the service. The DHCT333 further provides a customer interface to the DBDS501 and receives customer input 628 from the customer. In response to customer input, the DHCT333 may generate FPM or other messages transmitted via the return route to the CAA or EA. In a preferred embodiment, the DHCT333 is implemented using a combination of general purpose processors, ASICs, and security elements (which can be implemented independently or internally). For the purposes of this description, the DHCT333 has three key components. That is, the service decoder module 625, the security manager 626, and the DHCT security element (DHCTSE) 627. The service decoder module 625 is preferably implemented in the ASIC and the security manager 626 is preferably implemented in the software. The DHCTSE627 is a security element that performs security and conditional access related functions. [0065]

(Service Decoder Module 625) The service decoder module 625 is an element of the DHCT333 that decrypts encrypted MPEG-2 transport stream packets. The service decoder 625 receives the control word used for service decryption from the DHCTSE627. The DHCTSE627 controls which transport stream packets are decrypted by simply passing the control word for the authenticated service to the service decoder 625. [0066]

(Security Manager 626) Security Manager 626 is a DHCT software module that provides an interface between applications running on DHCT333 that use a conditional access system and DHCTSE627. It also integrates the processing between the service decoder module and the DHCTSE627. [0067]

(DHCTSE627) The DHCTSE627 stores keys, interprets EMMs and ECMs, and generates FPMs. With EMM and ECM, the DHCTSE627 performs the decryption and authentication required for interpretation, and the FPM generates a sealed digest to encrypt the FPM. Therefore, in a preferred embodiment, the EMM manager 407 is implemented in security element 617. In addition, the DHCTSE627 provides encryption, decryption, digest, and digital signature services for other applications running on the DHCT333. Security element (DHCTSE) 627 includes a microprocessor and memory that is accessed only by the microprocessor. Both the memory and the microprocessor are housed in a tamper-proof package. In interpreting the EMM, the DHCTSE627 acquires and stores the key and registration information, and in interpreting the ECM, the DHCTSE627 uses the registration information to register the DHCT333 that receives the ECM to the instance of the service with the ECM. Determine if you have it. If so, the DHCTSE627 processes the ECM and supplies the control word to the service decoder module 625 in a manner that can be used to decrypt or descramble the service. In addition, the DHCTSE627 records purchases of information for impulse-buyable services such as IPPV and stores purchase data until the data is successfully transferred to Control Suite 607 via a transfer purchase message. The DHCTSE627 maintains the MSK for the EA, the private / public key pair for the DHCT333, and the public key for the conditional access authority and registration agent. [0068]

(Control Suite 607) Control suite 607 is a member of the DNCS family of software. Control suite 607 controls the encryption of services performed by SEES module 620 based on input from the DNCS broadcast control suite element. Control Suite 607 also maintains a subscriber authority database based on transactions received from Management Gateway 511. Control suite 607 generates EMMs and communicates subscriber privileges and other conditional access parameters to the DHCTSE627. Control suite 607 acts as a substitute for the registration agent. The EMM generated by control suite 607 and communicating subscriber privileges and other conditional access parameters to the DHCTSE627 is encrypted with the DHCT333's public key and instructed to authenticate with the EA's private key. The EA is maintained by Transaction Encryption Device (TED) 603. The DHCTSE627 maintains the EA's public key and uses it to verify the EMM authentication generated by Control Suite 607 for the EA. [0069]

In addition, Control Suite 607 allows the establishment of a Conditional Access Authority (CAA). Control suite 607 generates an EA allocation EMM413 that passes the EA's public key to the DHCTSE627. These EMM 413s are encrypted as described above, but are authenticated using a digital signature generated by the CAA's private key maintained by TED603. DHCTSE627 is provided in advance with the CAA's public key to verify the validity of these EMM413s. [0070]

Communication between control suite 607 and the rest of the conditional access system 601 is via LAN interconnects 605 and 617. Device 605 connects control suite 607 to registration gateway 505, from which it receives the information needed to generate ECMs and EMMs. Device 617 connects control suite 607 to the SEES module 620 in the QAM modulator and the QPSK modulator 621 and QPSK demodulator 623 connected to the HFC network 521. The connection between control suite 607 and DHCT333 via LAN interconnect 617, modulator 621, demodulator 623, and HFC network 521 provides the necessary reply path to messages such as FPM421 and to DHCT333. A transmission channel is also implemented. This transmit channel is independent of the transmit channel used to provide the service. In conditional access system 601 the control suite 607 may send an EMM or broadcast message to the DHCT333 either by the transmission channel described above or with an instance of the service. [0071]

(Transaction encryption device 603) Transaction Cryptographic Device (TED) 603 acts as a peripheral for Control Suite 607. Under the command of control suite 607, the TED603 encrypts various conditional access system messages, including EMM, and produces a sealed digest. The TED603 also generates the (MSK) used to encrypt the ECM control word with SEES620 and decrypt the DHC TSE627 control word. In addition, the TED603 uses the MSK to authenticate the global broadcast message classification of conditional access system messages. Authentication is done by hashing the content of the message with some or all MSKs. The TED603 decrypts the forwarding purchase message 421 sent from the DHCT333 and other messages sent using the return route, and verifies its validity. The TED603 maintains the CAA's private key and EA and receives the DHCT's public key from the DNCS that receives the message. As described in more detail below, the TED603 receives a public key from a source that verifies the validity of each key. Finally, the TED603 uses the CAA and EA private keys to generate an EMM sealed digest to conform to the EMM. [0072]

(Use of conditional access system to support services and programs running on DHCT333 or Service Infrastructure 507) The conditional access system may ensure service delivery and provide security services to programs running on the DHCT333 or programs in control suite 607. Providing security services does not require the DHCT programs that support the services to be secure. The reason for this is that only the DHCTSE627 or TED603 in the DHCT333 can do the following: [0073]

Generation of MSK Storage of MSK · EMM encryption and / or decryption and key storage required to verify the sealed digest Storage of registration information received from EA · EMM encryption and / or decryption · Control word encryption or decryption -Providing MSK to SEES module 607 and providing decrypted control words to service decoder module 625 · Generate and verify digests with shared secrets -Generation and confirmation of sealed digest -Confirm that DHCT333 is registered to receive services Programs running on the DHCT333, or programs in control suite 607, do not have access to any information stored in the DHCTSE627 or TED603, except to ask the DHCTSE627 or TED603 to generate or interpret EMMs and ECMs. Is not related to EMM and ECM. For example, when the DHCT333 receives an EMM, it only passes the EMM to the DHCTSE627 for processing. Do the same when you receive the ECM. If the authority information contained in the ECM and stored in the DHCTSE627 indicates that the DHCT333 is registered with the service, the DHCTSE627 provides the decrypted control word in the service decryption module 625. [0074]

Conditional access systems also generally perform a safety check on the program. For example, a program running on a DHCT333 that requires information downloaded from a server application can predict that a sealed digest was attached before the information was downloaded, and the program used DHCTSE627. You can check the sealed digest to determine if the information is valid, but it is up to the program to decide what to do with the information when the DHCTSE627 shows that it is not valid. [0075]

(Message details in conditional access system 601) In conditional access system 601 the ECM, EMM, FPM, and GBAM are all different types of conditional access messages. All conditional access messages have a common format: header, message itself, and message authentication code, ie MAC. The header contains the following information: [0076]

-Whether the message type is ECM, EMM, GBAM, or something else Message length -Identifier for conditional access system · An identifier for the type of security algorithm used for the message, including message encryption and content authentication. Length of message content The header is followed by an encrypted message and MAC, which can be a sealed digest, depending on the type of message, or a digest generated by some or all of the MSKs that accompany the message. [0077]

In the digital wideband transmission system 501, CA messages travel either in an MPEG-2 data stream or in an IP packet. An IP packet is a packet generated according to the rules of the Internet Protocol. Other transport protocols such as ATM may also be used. In a preferred embodiment, the message from control suite 607 to DTCH333 travels within MPEG-2 or an IP packet. The control suite 607 message from the DHCT333 travels according to the IP packet on the return path provided by the QPSK demodulator 623 and the LAN interconnect device 617. In general, messages to DHCT333 that are closely related to a particular instance of a service, such as ECM and GBAM, travel within the MPEG-2 data stream. The EMM travels within the MPEG-2 transport stream or according to the IP packets provided by the QPSK modulator 621 and the LAN interconnect device 617. [0078]

(CA message in MPEG-2 transport stream: Figure 7) FIG. 7 is a schematic diagram of the MPEG-2 transport stream 701. The MPEG-2 transport stream is generated in a sequence of transport packets 703 that are 188 bytes long. Packet 703 in the stream, when combined with DHCT333, carries an instance of the service and information that determines access to the service from a given DHCT333. There are two broad categories of information. Program 709 and Program Specific Information (PSI) 711 required to generate the actual video and audio. The PSI711 provides information on matters such as how the transport stream should be sent to the network, how the program 709 is packetized, and what data is used to restrict access to the program 709. is there. Each of these broad categories has multiple subcategories. For example, program 709 may include video information and some channels of audio information. [0079]

Each transport packet 703 has a packet identifier, i.e. a PID, and all of the packets 703 carrying information for a given subcategory have the same PID. Therefore, in FIG. 7, all packet transport videos I have a PID (a), and packets belonging to the lower category are identified by 705 (a). Similarly, all packets carrying Audio I, Packets that have a PID (b) and belong to that category are identified by 705 (b). In this way, the subcategories of information are identified by the identifier of the packet. As shown in output packet 707, the output from MUX704 can be encrypted with any part of all MPEG-2 transport streams 701, which is a sequence of adjacent individual packets from various subcategories. However, packet headers and adaptation fields are never encrypted. In a preferred embodiment, the set of packets constituting program 709 is encrypted according to the DES algorithm with the control word as the key. [0080] [0080]

Two of the subcategories are special. What is identified by PID0 (705 (e)) and PID1705 (c)) can be used to enumerate other service-related packets and discover all information related to any service. The packet of PID1 705 (c)) has, as its content, a conditional access table that lists the PIDs of other packets, including EMMs. A set of such packets is represented as the EMM packet 705 (d) indicated by from CAT710 to packet 705 (d). Each packet 703 in packet 705 (d) contains private information, i.e., confidential information of the conditional access system 601. As described in more detail below, for the purposes of the present invention, private information 713 is a sequence of CA messages, each containing an EMM, and private information 719 is a sequence of messages, each of which is a sequence of messages. Includes ECM. [0081]

A PID (705 (e)) packet contains a program-related table that lists the PIDs of packets associated with an instance of a particular service. One such packet set is program map packet 705 (f), which includes program map table 717, which specifically enumerates the PIDs of transport packet 703 containing the ECM for the program. One such set of packets is shown in 705 (g). Each of the transport packets contains private information 719, which in this case is a sequence of CA messages, each containing ECM. [0082]

FIG. 8 details how the EMM is transported within the transport packet 703. Payload space 719 in the packet carries the data from CA_PRIVATE_SECTION layer 803, followed by the sequence of CA message 805. Each of the CA messages 805 contains EMM807. The set of packets 705 (g) carrying the ECM uses the 3DES algorithm with the MSK as the key to encrypt the control words in the ECM. In the packet 705 (d) pair carrying the EMM, the EMM is encrypted using the intended DHCT333 public key. As is immediately apparent, the techniques described above can be used to send any CA message 805 as part of an MPEG-2 transport stream. [0083]

(Mapping CA messages to IP protocol packets: Figure 9) Figure 9 shows how EMM is mapped to Internet Protocol (IP) packets used to communicate between control suite 607 and DHCT333 via LAN device 617, QPSK modulator 621 and demodulator 623. Indicates whether or not. IP packet 903 is simply a variable length packet consisting of a header and a payload. The header contains the source and destination IP address for the packet. For EMM, the source address is the IP address of the CA or EA, and the destination address is the IP address of the DHCT333. In a preferred embodiment, the IP address of the DHCT333 is constructed using its serial number. The IP address in DBDS51 is separated by HFC node 523. The payload of the IP packet is packet 905 belonging to the User Datagram Protocol (UDP), packet 905 containing CA_PRIVATE_SECTION803 as its payload, and CA_PRIVATE_SECTION803 containing the sequence of CA message 805. Each of the CA messages 805 contains an EMM 807. [0084]

(Details of ECM structure: Figure 10) FIG. 10 shows the structural details of the ECM1008 and shows the mapping 1001 from the ECM1008 to set 705 (e) of the MPEG-2 forwarding packet 703. As described above, the data of CA_PRIVATE_SECTION803 is transferred in a set of MPEG-2 transfer packets 703 having the same PID. That data is a sequence of header 1003 and CA message 805 for secret section 803. Each of the CA messages 805 contains a CA message header 1005, a CA ECM message 1007, and an ECM MAC 1013. CA ECM message 1007 and ECM MAC1013 together make up ECM1008. [0085]

Figure 10 also shows how control words are protected in the ECM1008 and how the ECM MAC1013 is generated. The control word using MSK as the key is either encrypted using 3DES encryption or created by encrypting the counter value using 3DES encryption at random. Value. In either case, the preferred embodiment requires an MSK consisting of two 56-bit DES keys, and the 3DES encryption operation is a sequence of three DES operations: encryption using the first DES key. , Decryption using the 2nd DES key, and encryption using the 1st DES key. The control word can also have even or odd parity. As shown in 1013, the odd control word (after proper encryption) becomes part of ECM_entitlement_unit_message1011 and, along with some or all MSKs in unencrypted form, the MD5 one-way hash function. Used as input, ECM Generate MAC1013. The same procedure is used with even parity control words. The contents of ECM_entitlement_unit_message1011 other than the control words will be examined in more detail below. [0086]

(Details of EMM structure: Figure 11) Figure 11 shows a CA message 805 containing the EMM 1112. CA message 805 has a header 1003, a CA EMM message 1101, and a sealing digest 1103. CA EMM message 1101 consists of CA EMM message header 1105, EMM message 1107, and CRC error detection code 1109. EMM message 1107 includes the EMM header 1113 and EMM_inside_data1115. EMM_inside_data115 is encrypted using the public key of the target DHCT333. The encrypted data is EMM data 1129, which consists of EMM_inside_header1123 and EMM command_data1125 along with padding 1127. EMM data 1129 is also entered into the MD5 one-way hash function to generate EMM MAC1119, and the seal digest 1103 is EMM_signing_header1117, EMM. This is done by encrypting MAC1119, EMM_signing_header1117, and padding 1121 with the public key of either the registration agent or the conditional access authority, depending on what EMM it is. [0087]

EMM_signing_header is information from EMM_inside_header. This information is particularly sensitive and therefore, for privacy reasons, is encrypted by both the DHCT333's public key and the registration agent's or conditional access authority's public key. If signature verification fails upon receipt and after privacy decryption, the EMM is rejected by the DHCT333. This information includes the ID for the conditional access system, the type of CA message, the microprocessor serial number in the DHCTSE627 of the DHCT, the identifier for the CAA or EA that is the source of the EMM, and the security of the DHCT333. An indication of which of the three public keys for the CAA in the element is used to decrypt the sealed digest, and an indication of the EMM format. The contents of EMM command_data1125 are explained in more detail in the discussion of operations performed using EMM. [0088]

(Details of DHCTSE627: Figures 12-14) The DHCTSE627 has five main functions in the conditional access system 601. · Public and private keys for DHCT333, public keys for CAA, public keys for EA (DHCT333 is authenticated by EA to receive service), and keys containing MSKs provided by these EA Safely store. -Securely store the registration information sent by the EA. · Decrypt, authenticate, and respond to EMM. -Decrypts the control word in the ECM, authenticates the ECM, and provides the control word to the service decoder 625 when the DHCT333 is authenticated to receive the service instance to which the ECM belongs. -Provide encryption, decryption, and authentication services to applications running on the DHCT333. [0089]

The DHCTSE627 includes a microprocessor (which can perform DES), which is dedicated hardware for RSA encryption and decryption, and a security memory element. All of the components of the DHCTSE627 are contained within a single tamper-proof package, such as a package in which the information contained within the package is corrupted when attempted to access it. Only DHCTSE627 components access the information stored in the security memory element. Any attempt by a user to access any part of the DHCTSE627 disables the DHCTSE627 and renders its contents unreadable. The DHCTSE627 can be an integral part of the DHCT333 or can be included in a user-installable module such as a "smart card". The user makes the DHCT333 "for himself" by installing the module inside the DHCT333. [0090]

Figure 12 provides an overview of the components of the DHC TSE627. As shown, all components of the DHCTSE627 are connected to bus 1205. Starting with interface 1203, interface 1203 allows the transfer of data between the remaining components of the DHCT333 and the DHCTSE627 to the general purpose processor that the application runs on the DHCT333, but the remaining components of the DHCT333 are in memory on the DHCTSE627 Do not allow addressing and reading of content with secret values. Microprocessor 1201 encrypts, decrypts, and authenticates, and executes code to interpret EMM and ECM; RSA hardware 1217 is dedicated hardware that performs operations related to RSA encryption and decryption. Wear. Memory 1207 contains code, keys, and registration information executed by microprocessor 1201. In a preferred embodiment, there are two types of physical memory in memory 1207: ROM 1219, which is read-only memory whose contents are fixed when the DHCTSE627 is manufactured, and read and write like normal random access memory. Is possible, but non-volatile memory (NVM) 1209 that maintains current values even when the DHCTSE627 is powered off. Non-volatile memory 1209 is a set of non-volatile storage cells (NVSC) 1211 (0.) as described in US Pat. No. 5,742,677, Pinder et al., Information Terminal Having Reconfigurable Memory, filed April 3, 1995. It is configured as .n). [0091]

Code running on microprocessor 1201 dynamically assigns NVSC1211 to a registration agent, as described in more detail below. In a preferred embodiment, the NVM1209 is used for storing information that can be rewritten by the EMM, and the ROM 1219 is used for code that cannot change until the DHCTSE627 collapses. [0092]

FIG. 13 is a schematic overview of the contents of memory 1207 in DHCTSE627. Memory is divided into two main parts: a read-only storage 1301 that contains code and other information that does not change as a result of EMM interpretation, and a non-volatile storage that changes as a result of EMM interpretation. There is an NVA storage unit 1303. RO storage 1301 includes code 1305. [0093]

Code 1305 falls into four categories: Code 1307 for cryptographic, decryption, and authentication operations performed by DHCTSE627, code for interpreting EMM1313, code for interpreting ECM1321, and FPM and Code for handling other CA messages such as GBAM. Code 1307 includes code 1308 for the MD5 one-way hash algorithm, code 1309 for the RSA public key algorithm, and code 1311 for the 3DES algorithm. EMM code 1313 is divided into three classes: Code 1315, which interprets the EMM received from the conditional access authority, interprets the EMM used by the registration agent to configure the storage allocation that the registration agent receives from the CAA. Code 1317, and code 1319 that interprets the EMM including the MSK and registration. Thus, codes 1315, 1317 and 1319 implement EMM manager 407 in a preferred embodiment. The code to interpret the ECM1321 decrypts the control words contained in the ECM and checks if the DHCT333 is allowed to access the instance of the service with the ECM, and if so, its decryption. The controlled control word is provided to the service decryption module 625. The code for other CA messages 1323 handles messages such as FPM and GBAM. [0094]

The NVA enclosure 1303 has two main components: the management enclosure 1330 and the EA enclosure 1331. The management storage unit 1330 includes a DHCT key 1325, a CAA key 1329, and CAA data 1330. First, in the case of the DHCT key 1325, each DHCT333 has two public-private key pairs. One public key in the pair acts as the public key used to encrypt the EMM sent to the DHCT333, and the private key is used in the DHCT333 to decrypt the message; the other in the pair. The private key is used to encrypt the sealed digest of the message sent by DHCT333, and the public key is used by other network elements to decrypt the sealed digest of the message received from DHCT333. To. The key pair is installed during the DHCTSE627 when the DHCTSE627 is manufactured. [0095]

In a preferred embodiment, the manufacturer of DHCT333 maintains a certified database with the serial number of each DHCT and the pair of public keys belonging to it. If the CAA or EA wishes to initiate transmission of the EMM to the DHCT333, it sends a message to control suite 607 along with the DHCT serial number. Control suite 607 responds to the request by requesting a public key for DHCT from a database maintained by the manufacturer of DHCT333. The database responds to the message by sending a proven copy of the public key for DHCT to control suite 607. In this way, the manufacturer acts as a proof authority for the key. Control suite 607 stores the public key in its own database. For more information on key proofs, see Schneier, pp. 425-428 above. Obtaining a public key for DHCT from the manufacturer has two advantages: first, it solves the problem of proving the key; second, the public key is not from DHCT333 but the manufacturer. In conditional access system 601 it is not necessary for the DHCT333 to have a path to control suite 607, as it comes from. [0096]

CAA key 1329 is a public key for conditional access authority. In a preferred embodiment, the CAA key 1329 comprises three public keys for a conditional access authority. These keys are installed from the beginning when the DHCTSE627 is manufactured, but can be modified in response to the EMM, as described in more detail below. CAA data 1330 contains parameters and maps used by CAA in managing EA containment 1331. The map maps NVSCs belonging to a particular enrollment agent to 8-bit names, which allows CAA and enrollment agents to manipulate NVSC1211 by name. [0097]

The registration agent 1331 has EA information 1331 for each registration agent, and the DHCT333 including the DHCTSE627 can obtain the service from the EA information. The CAA uses EMM to assign NVSC1211 for the enrollment agent, and then the enrollment agent uses EMM to configure the contents of information 1333 for that enrollment agent. [0098]

FIG. 14 shows how NVSC1211 is organized in the EA enclosure 1331 in a preferred embodiment. There are two types of NVSC1211: the "thin" NVSC as shown by 1405 and the "thick" NVSC as shown by 1409. Thick NVSC is composed of many thin NVSCs. The vault 1403 containing the three CAA public keys also contains two pointers: one is 1402 and points to the unassigned thin NVSC freelist 1407, and the other is 1404 and is assigned. Refers to the registered agent list 1406 of the thick NVSC1409. There is such a bold NVSC1409 (i) for each registered agent from which the DHCT333 can receive services. Each of these NVSC1409 (i) also has a list of NVSCs 1411 which can be thin NVSC1405, thick NVSC1409, or a combination of both. The given NVSC1409 (i) and its narrow NVSC list constitute EA information 1333 (i) for the EA. Bold NVSC1409 is an EA descriptor. As shown in 1333 (i), the narrow NVSC1411 contains information for the services provided by the registration agent. That information includes MSKs for services, bitmaps of registration information, and information needed for interactive services such as IPPV. (Control of NVA storage unit 1303) In a preferred embodiment, the allocation and deallocation of NVSC1211 can ultimately be controlled by either CAA or DHCTSE627. When the CAA controls allocation and deallocation, the CAA normally acts as the operator of the DBDS501, but negotiates with each of the registration agents and agrees to the various types of NVSC assignments for that registration agent. EA management code 1317 checks to ensure that when interpreting an EMM from a registration agent, the registration agent does not use more NVSCs of each type than the NVSCs assigned to it. [0099]

When the DHCTSE627 controls the NVA storage 1303, the CAA operator negotiates with the service provider and agrees to the storage allocation required for the service provided. The CAA then sends an encrypted message to the enrollment agent. Encrypted messages include allocations based on data type, and registration agents prevent service providers from requesting more resources than negotiated. Nevertheless, if the DHCTSE627 receives a request for more storage space than is available in the NVA1303, the DHCTSE627 indicates via the user interface that further storage is not available, and some services to the user. Requests the DHCT333 user to either remove the provider resource or cancel the request. [0100]

(Details of operation specified by EMM) The following is an example of the operation specified by EMM. The operation begins with a CAA public key change, through establishing an EA in DHCTSE627, and ends with broadcasts, events, and interactive services. In a preferred embodiment, one CAA controls the allocation of the EA vault 1331 to the registration agent. In other embodiments, there may be more than one CAA. There are two types of registration information: one for broadcast services and one for interactive services. Storage for broadcast registration is more permanent than that for interactive registration. [0101]

There is a limit to the amount of memory 1207 in the DHCTSE627. The CAA manages this inadequate resource and allocates it to the enrollment agent. The DHCT333 receives the service from the registration agent. Different EA can be allocated different amounts of storage as needed. Once the EA receives the allocation from the CAA, it may configure the storage area within the limits specified by the CAA. Different EA can have different limits and different kinds of limits. In extreme cases, the CAA only limits the total number of NVSC1211s an EA can have in its EA information 1333. The CAA may impose stricter restrictions by limiting the types of NVSC1211 and / or the number of each type. In this way, the CAA may restrain the EA from providing certain types of services and limit the amount of such services provided, i.e. the amount of time such services are provided. [0102]

When CAA assigns thick and thin NVSC1211 for EA, it gives each assigned NVSC1211 a "name", i.e. NVSC1211 has an identifier such as an 8-bit identifier. The CAA associates the EA assigned NVSC1211 with its identifier. The CAA and EA refer to the NVSC1211 in the EMM that operates the NVSC, using the name for the NVSC1211. The NVSC name does not have to be related to its physical location in NVM1209. The namespace of the name is 8 bits wide, so it is specified using a 256 bitmap. A registration agent can make an NVSC any type of NVSC if it has the name of an NVSC, but that type is allowed for the EA and the total number of NVSCs of that type belonging to the EA is the EA. Only if the limit set by the CAA that authenticates the is not exceeded. [0103]

Once the CAA allocates the EA storage area during the DHCTSE, it is the EA that makes up that storage area. The first step is to load certain parameters such as PIN into the descriptor for the EA. The second step is to determine which type of NVSC will be used for the protected services provided. The name assigned by the CAA is then distributed among the various types of NVSCs. Finally, each NVSC is loaded by sending the appropriate EMM. [0104]

(EMM addressing) In the conditional access layer, the EMM is addressed to a particular DHCTSE627 according to the index by the CAA or EA. This indexing method is dealt with in the EMM header 1113. The EMM header 1113 contains a unique identifier for the CAA or EA that is the source of the EMM, and is therefore associated with the private key used to create the EMM seal digest. The EMM header also contains a serial number for the DHCTSE627. The DHCTSE627 responds only to EMMs that include a serial number. If the CAA is the source of the EMM, there is also a value in the header that indicates which of the CAA public keys is the public key for the source of the message. Conditional access messages can be forwarded during other data protocols that may include other addressing mechanisms. [0105]

DHCTSE627 ignores EMMs addressed to CAAs or EA that are not "known" to DHCTSE627 (ie, no CAA corresponding to CAAID or EMM corresponding to EAID). Information about individual registrations is contained in NVSC1211 for registrations, as described in more detail below. Each of these NVSCs has a type, and the EA may change the type or content of the NVSC1211 by sending an EMM identifying the name of the NVSC1211 to be changed. DHCTSE627 modifies NVSC1211 as shown in the EMM. Unless the registered agent does not have an NVSC with that name, or its changes do not meet the constraints set by the CAA. In these cases, the EMM is ignored by the DHCTSE627. Conditional access system 601 does not require the digital broadband delivery system 501 to have a reverse path, or even if there is a reverse path, any band on the reverse path will be an EMM conditional access function. Does not require it to be available. Therefore, the DHCT333 responds to the EMM with no approval, confirmation, or error message. Therefore, the CAA or EA that is the source of the EMM tracks the allocation of NVSC1211 and sends only the EMM that requires correct operation. In other embodiments, a reverse path may be required, and for these embodiments, the reverse path may be used for approval or error messages. [0106]

(Change of CAA) As mentioned above, CAA is represented by its public key in DHCTSE627. The three public keys for the CAA will be installed in the DHCTSE627 when it is manufactured. Occasionally it may be necessary to change the CAA of the DHCTSE627. One situation where such a need may arise is when the private key for the CAA is compromised; another situation may be when a new entity hijacks the ability to authenticate the enrollment agent. This situation can occur, for example, as a result of selling all or part of the DBDS501. [0107]

Either of the public keys for the CAA can be replaced by two EMM sequences. Of the two EMMs, the first EMM has a sealed digest encrypted with the public key corresponding to the first EMM of the other two public keys, and the second EMM is It has a sealed digest encrypted with a private key that corresponds to the second EMM of the other two private keys. Each of the two EMMs contains an identifier, a CAAID for the new CAA, a key selection that indicates which of the three CAA public keys should be replaced, and a public key for the new CAA. After the 1st EMM has been successfully authenticated by the DHCTSE627 by verifying the digital signature applied by the 1st CAA key, the DHCTSE627 calculates and stores the MD5 hash of the new CAA public key in this 1st EMM. To do. After the second EMM is successfully authenticated by DHCTSE by verifying the digital signature applied by the second CAA key, DHCTSE calculates the MD5 hash of the new CAA public key contained in this second EMM. This second hash is compared to the first hash. If these hashes are identical, the new CAA public key and CAAID replaces the CAA public key and CAAID identified by the key selection value. One CAA public key must not be changed twice without one of the other two CAA public keys being changed in the middle. [0108]

(Dynamic addition and removal of enrolled agents in DHCTSE627; Figure 15) When the CAA authenticates the DHCT333 and receives services from the registration agent, it does so by sending a sequence of EMMs that create the registration agent descriptor EAD1409 for the new registration agent. Figure 15 shows the CAA A detailed diagram of EAD1409 (i) as created by EMM is shown. Header 1502 is common to all NVSC1211. Cell status 1501 indicates whether NVSC1211 has been assigned. Cell type 1503 indicates what kind of data it contains, along with EAD1409. Cell type 1503 indicates that the cell is a "thick" NVSC. The cell name 1505 is the 8-bit name that the CAA gives to the cell when it allocates the cell. The name is per EA. That is, the EA information 1333 for one EA contains up to 255 NVSCs. Next element 1507 is a pointer to the next element in the list to which NVSC belongs. Therefore, the next element 1507 is a pointer to the next NVSC in the free list 1407 in the unassigned NVSC; in EAD1409, a pointer to the next element in the EAD list 1406; and part of Listing 1411. In one thin NVSC, it is the next thin NVSC in the list. The next element 1507 is set in response whenever the list is manipulated by the EMM. [0109]

The remaining fields are specific to EAD1409. The fields labeled 1506 in Figure 15 are all set by EMM from the CAA. EAID1509 is an identifier for the registration agent to which EAD1409 belongs; in a preferred embodiment, EAID1509 is used to deploy EAD1409 for a given registration agent. CAA flag 1511 is a set of flags that indicates (1) the class of service that the registration agent can grant access to, and (2) whether the public key for the registration agent is installed in EAD1409. .. The first narrow NVSC 1513 is a pointer to the narrow NVSC list 1411 belonging to EA information 1333 to which EAD1409 belongs. EA Max 1515 defines the maximum amount of service for the EA to which EA Information 1333 belongs. The last field 1506 set by the CAA is the EA public key 1527, which is the public key for the EA belonging to EA information 1333. [0110]

The fields in the EA field 1516 contain information related to the customer to which the DHCT333 belongs. That field is set by the EMM received from the EA after EAD1409 is assigned and field 15106 is set. The DHCT flag 1517 includes a flag indicating the service provided by the EA currently entitled to receive by this particular DHCT333. The stored credit limit field 1519 is used with an instance of the impulse service, that is, an instance of the service that does not need to be purchased in advance. The stored credit limit service field 1519 indicates the maximum amount of service that an interactive customer can use without authentication from the EA. Certification is obtained by sending the FPM to the EA and receiving a confirmation EMM from the EA, as detailed below. The X coordinate 1521 and the Y coordinate 1523 define the position of the DHCT333 in the coordinate system established by the registration agent (fully described below). The coordinate system can be geographical and, for example, can be used to determine if the DHCT333 is in an area that should be blacked out during the broadcast. The coordinate system is also commonly used to define a subset of EA customers. For example, the X and Y coordinates are used to define customers who do not want to receive movies with a rating other than G or PG-13. A PIN is a multi-character code used by customers for DHCT to identify themselves to registered agents. [0111]

The EMM that the CAA sends to set up EA information 1333 for the EA is: EA assignment name map setting EA maximum allocation setting Registration agent public key update [0112]

The EMM header 1113 in all of these EMMs contains a CAAID for the CAA, and all of the EMMs have a sealed digest encrypted with the CAA's private key. The CAA uses these EMMs to not only set the EA information 1333, but also modify the existing EA information 1333 for the EA and remove the EA information 1333 for the EA. If the latter is done, the DHCTSE627 will no longer respond to EMM or ECM from the enrollment agent. [0113]

(EA assigned name map setting) The EA assignment name map configuration EMM contains an EAID that uniquely identifies the EA that EA Information 1333 is creating or modifying, and a name map. The map has 1 bit per name; if the CAA allocates NVSC for the EA, the bit corresponding to the NVSC name is set. CAA's EMM code 1315 responds to this EMM. The response assigns the required NVSC to EA information 1333, maps the name for the EAID to the physical location of the NVSC, creates Listing 1411, and sets the first NVSC flag 1513 to point to it. This is done by setting, adding a new EA descriptor 1409 to the beginning of the EA list 1406, and setting the next element pointer 1507 accordingly, and satisfying header fields 1502 and EAID fields 1509. [0114]

CAA's EMM code 1315 can store the current name map for EA in CAA data 1330, and as a result, compare the newly received set EA assigned name map EMM with the current name map. If one name is identified in both name maps, the EA Assigned Name Map Configuration command will not affect NVSC1211 with that name. If the name map in the EMM identifies a name that was not in the current name map, the NVSC1211 corresponding to that name is added to Listing 1411. If the name map in the EMM no longer specifies the name previously assigned to the registration agent, the NVSC1211 corresponding to that name is returned in freelist 1407. After this is done, the namemap in the EMM becomes the current namemap. [0115]

Registration agents and conditional access authorities typically work together in deciding how large Listing 1411 should be. For example, if the registration agent requires less space, a message for its effect can be sent to the CAA, which contains the name of NVSC1211 to be removed that the registration agent desires, and in the EMM sent by the CAA. The name map can only specify the name of NVSC1211 that the registration agent wants to keep. However, it is possible that the enrollment agent is uncooperative or that the conditional access authority must reduce the size of Listing 1411 for the enrollment agent before receiving a message from the enrollment agent. In this case, the CAA can remove NVSC1211 from Listing 1411 by name value, that is, it starts with the name with the highest number, the second highest number, and so on until the required number of NVSC1211 is removed. Be done. [0116]

The CAA also uses the set EA assignment name map EMM to remove EA information for the EA from the DHCTSE627. When EMM is used in this way, no bits are set in the name map. CAA's EMM code 1315 returns all of the NVSCs in the EA information 1333 and EA descriptor 1409 (i) for the EA identified by the EAID in the EMM to the freelist 1407, and optionally the EA list. Respond by relinking 1406. [0117]

(EA maximum allocation setting) The EA maximum allocation setting includes the EAID for the EA with registration information 1333 being created or modified, and also includes the values for fields 1511 and 1515 of EAD1409. CAA's EMM code 1315 responds to this EMM. This response is made by reading the EA list 1406 using the EAID specified in the EMM until it finds the EA descriptor 1409, and then using the values in the EMM to set fields 1511 and 1515 of EAD1409. .. When a registration agent sends an EMM to a DHCTSE627 that has established registration information for a given type, such as an event, the code that interprets the EMM checks the EA maximum allocation to see if it exceeds the maximum number of registrations for that EA. To determine. In a preferred embodiment, registration is represented by NVSC. Therefore, what is limited is the number of NVSCs of a given type in Listing 1411. [0118]

(Registration agent public key update) The registration agent public key update EMM contains the EAID for the EA that has the registration information being created or modified, and the EA's public key. The response of CAA's EMM code 1315 to this EMM is made by placing the EA descriptor 1409 as described above and setting field 1527 from the public key in the EMM. With the EA's public key in place, the DHCTSE627 can use the EMM's signed digest to verify that the EMM is from the EA. This confirmation is possible. This is because the EA performs the signing operation using the private key corresponding to the updated public key. [0119]

(EA EMM to change registration information 1333) EA's EMM, which modifies registration information, has sealed a sealed digest that is encrypted using the EA's public key. EMMs are divided into two groups: EMMs that modify EA field 1516 in EAD1409 and EMMs that modify the contents of NVSCs that make up Listing 1411. As described for EAD1409, each NVSC has a name, and each NVSC in Listing 1411 has a type. NVSC is named by the CAA, as described above, and its name cannot be changed by the registration agent. However, the registration agent changes the type and content of the NVSC depending only on the maximum value for the type established during EAD1409 for the EA. It is the enrollment agent that tracks the type and content of NVSCs in EA Information 1333. [0120]

The EMM that modifies EA field 1516 in EAD1409 is the registration agent property update EMM. The second group of EMMs is further subdivided according to the type of registration provided by the EMM. There are two broad systems of registration: broadcast registration for non-interactive services and interactive registration for interactive sessions. Within the broadcast registration, there is an event registration for the event that the user pays individually. Such cases include pay-per-view events, interactive pay-per-view events, and near-video-on-demand events. Non-event broadcast EMMs include: MSK update Digital bitmap update Digital list update Analog MSK and bitmap update Analog MSK and list update Analog bitmap update Analog list update Is. Broadcast EMMs for events include: New event storage · Add / Remove PPV events Approved IPPV / NVOD event Is. EMMs for interactive sessions include: Store new interactive session Additional interactive session · Removal interactive session Is. As can be seen from the name of the EMM, the EA relies only on the maximum value identified in EAD1409 to change the type of named NVSC assigned by the CAA as needed for events and interactive sessions. obtain. [0121]

There is a separate CAA EMM for assigning NVSCs, setting limits on NVSC types, and granting public keys to enrollment agents. Also, the EA's EMM for writing NVSC1211 can do that by name, and change the type and content of NVSC1211. Therefore, the access control system 601 has a high degree of controllability and flexibility. The CAA dynamically constrains the total number of registrations that a registration agent can give, the type of registration, and the total number of registrations of each type, as needed. The CAA may also change its constraints, in part or in whole, and either in collaboration with a registered agent or alone. However, within the constraints imposed by the CAA, the registration agent not only modifies the registration of a given type, but even the type itself, and is free to dynamically manage its own registration. [0122]

(Updated registration agent properties) This EMM contains the value for EA field 1516 of EAD1409. The EA-managed EMM code 1317 simply reads the EMM header 1113, obtains the EAID for the EA of interest in the EMM, and sets field 1516 from the EMM in the EAD1409 for the EA. [0123]

(Non-event broadcast EMM) Four types of non-event broadcast EMMs are considered here. There are combinations of MSK updates, bitmap updates, list updates, and MSK and list or bitmap updates. One of ordinary skill in the art can readily apply the principles described below to EMMs that perform the functions indicated by the names of other non-event broadcast EMMs. For example, the principles of digital EMM can be applied to analog EMM. There is a separate type of NVSC1405 for each information type provided by the non-event broadcast EMM. FIG. 16 shows the contents of these four types of NVSCs. Consider each NVSC type with an EMM that provides information containing it. [0124]

(MSK update) The MSK update EMM is used to send a new MSK for a set of services provided by the EA identified by the EMM. The new MSK and other information related to that MSK are stored in the MSK NVSC1601 in Listing 1411 for EA Information 1333 belonging to the EA identified by the EMM. Included in the MSK NVSC1601 is the header 1502. For header 1502, NVSC1601 is MSK Specifies that it is an NVSC, gives it the name of the NVSC, and contains the next element pointer 1507 to the next element in Listing 1411. Other fields contain information about the MSK. In a preferred embodiment, the MSK1608 has two 128-bit portions: an even MSK1609 and an odd MSK1611. Each part is two halves, the first and second halves, with 56 key bits and 8 unused parity bits, respectively. MSK1608 is associated with the pair identifier 1603 for MSK1608, the due date 1605 for MSK1608, and flag 1607 to indicate whether the values for due date 1605 should be ignored. If the due date 1605 is not ignored, the DHCTSE627 does not use the MSK1608 to decrypt the control word after the due date. The identifier 1603 exists for each EA, and as a result, a given EA has one or more MSKs to store multiple different MSKs. The NVSC1601 can be held at any given time. Therefore, the conditional access system 601 not only allows for a separate security partition for each EA, but also allows for a security partition within the EA. [0125]

The update MSK EMM header contains the EAID needed to place the EA information 1333 for the EA; the message specifies the name of the NVSC receiving the MSK, the MSK pair ID for the MSK to be updated. The MSK Pair Selector, a set of flags that allows the EA to selectively change the MSK Pair ID 1603, one half of the Expiration Date 1605, the Expiration Date 1607, and the MSK1608, and the required to make that change. Contains information. The EMM contains the maximum, the value for the MSK pair ID 1603, the value for the due date 1605, the value for the non-expiration date 1607, and the value for the even MSK1609 and the odd MSK1611. Update MSK EMM processing with MSK code 1319 for EA places EA information 1333 for the EA identified by the EAID in the EMM header, places the appropriate NVSC using the cell name, and MSK type to that NVSC. Is then done by writing to the MSK NVSC1601 as required by the flags and information in the EMM. This method is an update MSK for both analog and digital The same is true for EMM. The difference is in the EMM command code in the EMM header 1123 and NVSC type 1503. [0126]

(Registration identifier) As described in more detail below, the ECM provides the service instance with which it accompanies, (1) the EAID for the registration agent that is the source of the ECM, and (2) the 32-bit registration ID for that instance. Specified by ,. A registration ID exists for each EA. By making the registration ID 32-bit long, each EA may have sufficient registration ID even for transient services such as pay-per-view events and interactive services. In a preferred embodiment, the DHCTSE627 has identified in the ECM whether the DHCT333 has been granted the right to decrypt the instance when interpreting the ECM, the registration ID corresponding to the registration ID identified in the ECM. Check by looking in EA Information 1333 for EA. Registration IDs in EMM and EA information 1333 are represented in at least two ways. One way is to simply list the registration IDs. The drawbacks of this technology are that the 32-bit registration ID is large and NVSC is an inadequate resource. The other method is by starting registration ID value and bitmap. Any registration ID having a value within 255 of the registration ID value identified by the start registration ID value can be identified by setting 1 bit in the bitmap. This technique is described in the above patent applications of Banker and Akins. In particular, see Figure 2 of the Banker and Akins patent applications and a review of that figure. The following study of identifying a registration ID by starter ID and bitmap extends the study of the above patent application. [0127]

(Bitmap update EMM) This EMM updates the bitmap that identifies one or more registration IDs. Bitmaps are stored in the registered bitmap NVSC1613. The NVSC1613 has a header 1502 with its NVSC cell number and type; the first registration ID 1615, which is the first registration ID that can be identified by the bitmap; the first registration ID 1615 and when the registration ID identified by the bitmap expires. It has a deadline date 1617; which specifies whether the deadline date actually exists; a non-deadline date flag 1619; and a bitmap 1621. The update bitmap EMM contains a cell name for the NVSC1613 to be set, a set of flags indicating the information in the NVSC1613 set by that EMM, and a value for the information. The EMM may set any or all primary registration IDs 1615, expiration dates 1617, non-expiration dates 1619, and bitmap 1621. The EA-managed EMM code 1317 responds to the EMM by setting the specific NVSC1613 fields as shown in the EMM. The procedure is the same for both digital bitmap update and analog bitmap update EMMs. The difference is in the EMM command code in the EMM header 1123 and NVSC type 1503. [0128]

(List update EMM) List update The EMM updates the list of registration IDs contained in the registration list NVSC1623. The NVSC1623 has a header 1502 with the cell name and type for that NVSC and contains up to 6 registered ID elements 1625. The elementary each bet includes a flag 1631 indicating whether the registration ID1627, the registration ID expiration date 1629, and the registration ID has a due date. The list update EMM contains the cell name for NVSC, the value for the flag, the due date, and the value for up to 6 registered ID elements 1625. The procedure is the same for both digital list update and analog list update EMMs. The difference is in the EMM command code in the EMM header 1123 and NVSC type 1503. [0129]

(Broadcast event) Broadcast events are one-time services such as pay-per-view broadcasts of boxing matches. In a preferred embodiment, there are two types of broadcast events: a regular pay-per-view broadcast event that the customer pre-orders to see the event, and a customer determines when the event that the customer wants to order will be broadcast. It is an impulse event. There are different types of impulse events: impulse pay-per-view (IPPV) events, which are pay-per-view events, and popular movies where customers can decide to buy the event at the time of the event. Near Video on Demand (NVOD), which rebroadcasts at short intervals and allows the customer to decide when to rebroadcast regardless of whether the customer wants to see it. The concept of "events" may refer to any service (whether broadcast or non-broadcast) for a particular period of time, such as video-on-demand events or other types of events not listed herein. It is the approval of those skilled in the art. [0130]

For pay-per-view events, the customer orders the event from a registration agent, who responds by sending an EMM containing the required registration information. For events where the customer wants to purchase the event at broadcast time, purchase information, that is, information about registrations that can be purchased, must be distributed with the event. In these cases, the purchase information will be distributed by the Global Broadcast Certified Message or GBAM. The customer provides an input 628 that identifies the purchase. The DHCT333 responds to input 628 by storing a record of purchases in DHCTSE627 and then initiating decoding of the event. The DHCT333 then sends a forwarding purchase message (FPM) to the registration agent indicating what was purchased by the customer, and the registration authority responds using EMM. The EMM confirms the purchase and contains the required registration information. A record of the purchase remains until the EMM confirming the purchase is received by the DHCTSE627. [0131]

(Event NVSC: Figure 17) Figure 17 shows the event NVSC1701 used to store registration information for an event. Header field 1502 is similar to that for other NVSC1701s. Each event NVSC1702 can contain up to three event descriptors 1703. Each descriptor 1703 describes an event. Each descriptor 1703 contains a flag field 1705. Flag fields 1705 include (1) whether the event is active, (2) whether its end time has been extended, (3) whether the registration agent has confirmed the purchase of the event, and (4) at any time the customer. Whether it can be canceled, (5) whether the customer can cancel in the cancel window, (6) whether the customer canceled the purchase, (7) whether the right to copy the event was purchased, and (8) Includes a flag that indicates whether the event is an analog or digital service. Purchase time 1709 is after the start time of the event or the time the customer purchased the event. The end time 1709 is the time when the event ends. Cost 1711 is the cost of the event to the customer, and registration ID 1713 is the registration ID for the event. [0132]

(New event storage EMM) The CAA contains a value in the EA maximum 1515 that limits the number of events NVSC1701 that a registration agent can have when configuring registration agent descriptor 1409 for registration agents. However, within that value, the registration agent is free to allocate event NVSC1701 from the total number of NVSC1405 belonging to the registration agent and reuse the existing event NVSC1701. To assign the event NVSC, the EA uses the new event storage EMM. The new event storage EMM simply contains the cell name for the assigned NVSC. Once the event NVSC1701 is assigned, its fields are set as follows: · For normal PPV, the field is set by the add / remove event EMM; For IPPV or NVOD events, the fields are set partially from GBAM for the event and partly from customer input 628. [0133]

The content of event NVSC1701 is to receive an ECM that includes the time beyond the event end time, either by the add / remove event EMM or during event NVSC1701, if the event record was previously approved by receiving the approval event EMM. Will be deleted by. [0134]

(Add / Remove Event EMM) The add / remove event EMM contains a flag that indicates whether the EMM is setting or deleting an event. In the latter case, the EMM content must match the current content of NVSC1701 to be deleted. In the former case, the EMM value includes a flag indicating whether the time extension is possible and whether the right to copy has been purchased. Also included are values for the start and end times of the event and the registration ID for the event. If the add / delete flag indicates "delete", the EA control code deletes the contents of NVSC1701. If the add / remove flag indicates "add", the code sets the corresponding field in NVSC1701 to the value specified in the EMM. A flag indicating whether the EA has approved the purchase is set to indicate that. [0135]

(Global Broadcast Certified Message: Figure 18-20) Global Broadcast Certified Messages (GBAM) are CA messages such as EMM, ECM, and EPM. GBAM will be broadcast to DHCT333 by a registered agent. Figure 18 shows a CA message 805 containing the GBAM 1801. Message 805 includes CA message header 1003 and CA GBAM message 1803, and CA GBAM message 1803 is composed of GBAM header 1807 and global broadcast data 1809. Global broadcast data 1809 is not encrypted, but GBAM1801 is authenticated in the same way as ECM: header 1807, global broadcast data 1809, and MSK1015 belonging to the EA that sent GBAM are hashed by the one-way hash function MD5. Create GBAM MAC1805. Like the ECM, the MSK1015 is a shared secret between the EA that sent the GBAM and the DHCT333 that has the EA information 1333 for the EA. [0136]

FIG. 19 shows the GBAM header 1807 in detail and further illustrates the form that global data 1809 takes when using GBAM 1801 to provide registration information for IPPV or NVOD. GBAM header 1807 has a conditional access system ID 1901 that identifies the CA system 601 in which GBAM 1801 is used, a tag that indicates that the message is GBAM, and a registration agent identifier 1905 that sends GBAM. Fields 1907 and 1909 identify the key used to create the MAC1805. Field 1907 identifies half the parity of the MSK used to create the digest, and the MSK selector 1911 is an identifier for the MSK itself. [0137]

Purchaseable registration data 1913 relates to the form of global broadcast data 1809 used to provide registration information for IPPV or NVOD. Of the fields related to the current discussion, registration ID 1915 is the registration ID for events associated with GBAM, and flag 1917 is what kind of cancellation is possible and the time for the event. Includes a flag indicating whether it can be extended. The number of modes 1919 indicates how many different modes exist for purchasing an event. The rights the buyer receives for the event and the amount the buyer has to pay will vary with the mode. In a preferred embodiment, the event can have up to 5 purchase modes. More GBAMs may be sent if more purchase modes are needed. The rights and amounts for each mode are indicated by an array. Each array has as many valid elements as the mode. The value of the element corresponding to the mode indicates the right or price of that mode. Therefore, the mode copy right field 1921 is a bit array; if one bit for one mode is set, the purchaser of that mode has the right to copy the event. Similarly, the mode length field 1927 contains a value for each mode indicating the time length for an event in that mode. The mode cost field 1929 contains a value for each mode indicating the cost for the event in that mode. The first start field 1923 gives the earliest time that registration for an event can start, and the last end field 1925 gives the last time that registration must end. [0138]

When the DHCT333 receives the GBAM1801, it passes the GBAM1801 to the DHCTSE627 to authenticate the global broadcast data 1809. If the DHCTSE627 does not have the required MSK, the authentication will fail. If (1) DHCTSE627 has the required MSK, and (2) global broadcast data 1809 is data 1913, DHCT333 allows the customer to purchase the event. In doing so, the customer must prove himself to the DHCT333 by PIN, and that PIN must match PIN1525 in EAD1409 for the registration agent that sent the GBAM. The customer also identifies the mode associated with making the purchase. Given the mode and cost information in GBAM, the DHCT333 determines by ordering an impulse event whether the customer exceeds the amount (time, money, etc.) specified in the stored credit limit 1519 in EAD1409. obtain. If the customer does not exceed the limit, the information from GBAM and the buyer's input will be used to create the event descriptor 1703 for the event. The DHCT333 passes that information to the DHCTSE627. DHCTSE627 sets the fields in event descriptor 1703 according to the values provided by DHCT333. The flag indicating whether the purchase information has been approved is cleared, and the cost of the event is added to the current credit balance. [0139]

(Forward purchase message: Figure 21) In a preferred embodiment, the forwarded purchase message (FPM) serves two purposes: · The forwarding purchase message notifies the registration agent that the customer has purchased an IPPV or NVOD event; and The forwarding purchase message notifies the registration agent that the customer has canceled the purchase of any event. [0140]

In other embodiments, messages such as FPM can be used to transfer any kind of information from the DHCT333 to the CAA or EA. For example, such a message can be used to transfer monthly order information from the DHCT333 to the EA. [0141]

The DHCT333 sends a transfer purchase message with purchase information to the registration agent that transmitted the GBAM via the reverse channel. The FPM is included in the reverse channel data packet addressed to the EA. Figure 21 provides an overview of the FPM and the cryptographic means used to protect its contents. FPM2101 is CA message 805 and is therefore transmitted using CA message header 1003. The FPM2101 itself consists of the FPM encryption envelope key 2103. The FPM encryption envelope key 2103 includes an EAID for the registration agent and an FPM key 2119 for decrypting the purchase information contained during the FPM encryption event 2113. The key of envelope key 2103 and other contents are encrypted for privacy using the public key of the enrollment agent targeted by FPM2101. CA FPM message 2105 includes CA FPM header 211. CA The FPM header 211 contains the EAID for the target EA, and the FPM encryption event 2113. The latter is encrypted using the 3-DES algorithm with the key in the envelope key 2103. The part of CA FPM message 2105 contains header 213, FPM clear event 2133, and padding 2135. FPM Clear Event 2133 includes purchase information. The final part of the FPM2101 is the FPM-signed authentication 2107 encrypted with the private key of the DHCT333 that sends the FPM message 2101. [0142]

Cryptographic material includes FPM signature header 2125, FPM MAC2127, and padding 2129. The FPM MAC2127 is created from the FPM clear event 2133 using the MD5 one-way hash algorithm. Only the EA targeting the FPM decrypts the envelope key 2103 to get the key 2119 to decrypt the FPM encryption event 2123, and that EA has the public key for the DHCT333 to send the FPM 2101. Only if you can check the authentication of FPM clear event 2133. [0143]

A more interesting part of the specification of FPM2101 is the FPM clear event 2133. The information in that part of the FPM includes the serial number of the DHCTSE627 in the DHCT333 that sent the message, the EAID of the destination EA, and an indication of the number of events that the FPM contains purchase information. Information for each event is included in the forwarding event data for that event. Forwarding event data is retrieved from GBAM1801 and the event descriptor 1703 for the event. The fields of interest in the current context include flags that indicate (1) whether the event has been extended, (2) whether the user has canceled the event, and (3) whether the customer has purchased the right to copy. .. Other information includes the time the event started or purchased, whichever is later, the time the event ends, the cost to the customer of the event, and the registration ID for the event. The DHCT333 sends an FPM with the same message to cancel any event, including regular pay-per-view events, except for the event canceled flag set to indicate cancellation. The conditions under which the DHCT333 sends an FPM cancellation message are described in detail below. FPM can also be used to purchase other service types, such as monthly subscriptions or data downloads. [0144]

(Approved IPPV / NVOD Event EMM) When the registration agent receives an FPM, it enters the information contained in that FPM into its customer information database and returns the approved IPPV / NVOD event EMM to the DHCT333. The EMM command data 1125 in this EMM contains an exact copy of the transfer event data in the FPM approved by the EMM. When the DHCTSE627 receives this EMM, it decrypts and authenticates it, and then places the event NVSC1701 for the event using the registration ID for each item of the copied transfer event data. .. When DHCTSE627 places event NVSC1701, it compares the copied transfer event data with the corresponding field in event NVSC1701. If they are the same, DHCTSE627 sets a flag in flag field 1705 to indicate that the purchase has been confirmed and adjusts the stored credit balance. If the EMM is set to its "cancel" flag, the "in use" flag in event NVSC1701 is set to indicate that event NVSC1701 is not in use and is therefore available for reuse by the registration agent. Will be done. [0145]

(Other uses of GBAM1801) GBAM1801 can be commonly used to broadcast authenticated messages to the DHCT333 via an MPEG-2 transfer system, or other transfer mechanism. The CA system 601 itself uses the GBAM 1801 in two other ways: how to broadcast the time value to the DHCT333 on a regular basis, and how to extend the time of the event. In the former case, GBAM1801 simply carries a time value, which is a safe time, with GBAM authentication. The code in the DHCT333 that performs the task for the registration agent that sends the system time GBAM uses the time value to coordinate its behavior with the behavior of the EA. However, this configuration allows the use of time schemes per registered agent. It is also uniform throughout the digital broadcast delivery system by setting one registration agent in each DHCT333 of the digital broadcast delivery system as a "system time registration agent" and addressing the system time GBAM to the system time registration agent. Allows you to establish system time. [0146]

Extending the time of an event GBAM1801 carries the registration ID for the event and the number of minutes for which the time for the event is extended. When the GBAM1801 is received and provided to the DHCTSE627, the security element appends a fraction to the end time 1709. [0147]

FIG. 20 shows a registration agent 2005 and a server application 2001 running on a processor with access to an MPEG-2 transfer system received by a group of DHCT333s. Server application 2001 sends a message authenticated using GBAM1801 to DHCT333. The server application 2001 sends a message to the registration agent 2005. Registration Agent 2005 uses its transaction encryption device 603 to create GBAM1801 containing the payload. Registration agent 2005 then returns GBAM to server application 2001, which sends application data along with GBAM to client application 2009 in DHCT333, as shown in 2007. Each client application sends a GBAM1801 to the DHCTSE627 that authenticates it. If the authentication is successful, DHCTSE627 sends the authorization to the client application 2009. It should be noted here that it is the registration agent that authenticates the payload, not the server application 2001. [0148]

(NVSC and EMM for interactive sessions) DBDS501 can also be used for interactive sessions. Examples of such use are browsing the Internet or playing video games. In such applications, the data sent to the customer is generally transferred via the MPEG-2 transfer stream, while the data sent by the customer is transferred via the reverse channel. Such a configuration is advantageous for many interactive applications where the customer receives a large amount of data (eg, data representing an image), makes a short response, and then receives another large amount of data. [0149]

Each currently occurring interactive session with a user of DHCT333 has an interactive session NVSC1211 in Listing 1411 that belongs to a registration agent that gives access to that interactive session. The interactive session NVSC contains the session key for the interactive session and the registration ID for the interactive session. The DHCTSE627 assigns an interactive session NVSC in response to a new interactive session storage EMM from the enrollment agent. The new interactive session storage EMM simply contains the NVSC cell name used for that interactive session. [0150]

Once the NVSC is established, the EA sends an "additional interactive session" EMM. The additional interactive session EMM contains the name of the newly assigned NVSC, and the registration ID, and the key for the interactive session. The security element places the registration ID and key in NVSC. If the EA determines that the interactive session has ended, it sends a "removal interactive session" EMM with the registration ID for the interactive session, and the security element deletes the contents of the NVSC. It is of course possible for the registration agent to send a new interactive storage EMM when all of the interactive session NVSCs assigned to the EA by the CAA are already in use. The DHCTSE627 in a preferred embodiment handles this situation by knowing the last time each interactive session transmitted or received data. If a new interactive session is needed and not available at all, the DHCTSE627 shuts down the interactive session that most recently sent or received data, and uses the interactive session NVSC for that interactive session. To do. Another solution is to ask the user to select an interactive session to end. [0151]

(Details of ECM: Figure 22) Information in the ECM used to determine whether an instance of the service associated with the ECM is decrypted at a given DHCT333 is contained in ECM registration unit message 1011. FIG. 22 gives details of the contents of ECM registration unit message 1011 for a preferred embodiment of the present invention. First, in message ID 2205, two fields 2201 and 2203 identify this message as an ECM registration unit message. EAID2207 is an identifier for a registration agent that grants registration to access an instance of the service that ECM accompanies. [0152]

Decryption information 2209 is information used to generate control word 2235. The control word counter value 2235 is encrypted using the 3DES algorithm in a preferred embodiment. This algorithm uses two keys, and in a preferred embodiment, each key is 1/2 of the MSK. There are also two versions of MSK: even and odd. MSK Parity 2211 identifies which version is used in the 3DES algorithm. MSK ID 2213 identifies which MSK of the enrollment agent is used, and if the ECM involves data for an interactive session, identifies that key is found in the NVSC for that interactive session. The control word parity 2215 identifies the parity of the unencrypted control word 2235. Parity count 2217 is a 0-1 counter with a value of 0 if the parity of the control word is even and a value of 1 if it is odd. [0153]

Free preview 2219 is a flag indicating that the ECM is accompanied by a part of the service instance that is the free preview. That is, as long as the customer has an MSK for the service instance, the customer does not need any further registration to view the free preview portion of the service. Free preview is mainly used with IPPV or NVOD services. Copy protection level 2221 is a value that indicates how much the instance is copied. Blackout / Spotlight 2223 is a value that indicates how Blackout / Spotlight Information 2236 is used: not used at all, blackout, or spotlight (ie, the service covers a particular area). Target). [0154]

The registration ID2225 number identifies the number of registration IDs 2245 contained in this ECM. The maximum value in a preferred embodiment is 6 in one ECM. Multiple ECMs can be sent for each service. IPPV Possible 2229 is a flag that indicates whether a service instance can be viewed on a per IPPV or NVOD basis. Cancel window 2231 is a bit set during a service instance that can be viewed as an event to indicate the end of the period during which the customer can cancel the event. Timestamp 2233 is a time stamp indicating the time when the ECM was created. The encryption control word 2235 is a control word included in the ECM. It is encrypted using the 3DES algorithm and the MSK for service instances. [0155]

Blackout / Spotlight Information 2236 defines a geographic area that is blacked out or spotlighted by an instance of the service. This is done by the x centroid 2239 and the y centroid 2241. These two centroids define a point in the geographic coordinate system defined by the registration agent and a blackout radius of 2237. Blackout radius 2237 is used to determine a square centered on the points defined by fields 2239 and 2241 and having sides twice the value of blackout radius 2237. The registration ID list 2243 contains 1 to 6 registration IDs for the instances of the service with which the ECM accompanies. [0156]

(Details of Blackout / Spotlight Information 2236: Figures 26 and 27) The coordinate system used in the preferred embodiment is used in FIG. The coordinate system 2601 is a 256-unit x 256-unit square whose origin is in the lower left corner. In that coordinate system, it is the lines that are numbered, not the space between the lines. The registration agent to which the coordinate system 2601 belongs assigns each DHCT333 in the area covered by the coordinate system to the coordinates of the intersection of the line perpendicular to the x-axis and the line perpendicular to the y-axis. Thus, the DHCT333 (k) can be assigned a point (i, j) 2603 in the coordinate system 2601. [0157]

FIG. 27 shows how regions are defined in coordinate system 2601. Region 2705 has its center of gravity 2701 at the point whose coordinates are (57,90). The radius of the area is 2703, where this number is added and subtracted from each coordinate value of the center of gravity, a square with the lower left corner at (54,87) and the upper right corner at (60,93). Generate 2705. In a preferred embodiment, points on the left and bottom lines are included in the region and points on the top and right lines are not included in the region. [0158]

(Determining whether to decrypt a service instance with ECM) Conceptually, what happens when a DHCT333 receives an ECM with an instance of a service is that the DHCT333 provides that ECM to the DHCTSE627, which inspects the NVSC in the EA enclosure 1331 and belongs to the DHCT333. Finding out if a customer is registered to receive an instance of the service. If the customer is so registered, the DHCTSE627 decodes the control word in the ECM and provides it to the service decoder 625. The service decoder 625 uses it to decode MPEG-2 packets containing audio and video for the service. However, the number of different types of services, the number of different ways in which services can be purchased, and the number of ways in which access can be restricted all work together to rather complicate the way the DHCTSE627 handles ECM. [0159]

The simplest case is for broadcast services such as standard CATV channels. Here, the customer with the DHCT333 pays his monthly fee for the service, and the registration authority has sent two EMMs to the DHCT333: the MSK EMM with the monthly MSK for the service, and for the service. An EMM that identifies the registration ID of. As pointed out above, the latter EMM may include either a list of registration IDs, or a first registration ID and a bitmap. All of these EMMs can also include an expiration date: for MSK EMMs there is an MSK expiration date; for registration ID lists EMMs there is an expiration date for each registration ID on the list. For registered bitmap EMMs, there is an expiration date for all bitmaps. [0160]

At a minimum, EA information 1333 for registration agents that provide registration for service instances with ECM is EA descriptor 1409, MSK NVSC1601, and registration bitmap NVSC1613 or registration list NVSC1623 for services to which the instance belongs. including. EA Information 1333 also includes NVSCs with registration information for other services or instances. [0161]

The ECM for a service instance may include at least the registration agent ID 2207 for the service instance, decryption information 2209, time stamp 2233, encryption control word 2235, and one registration 2245. [0162]

If the DHCT333 receives an ECM, it delivers the ECM to the DHCTSE627, which reads the EA list 1406 until it finds an EA descriptor 1409 with a value in EAID1509 that is the same as the value EAID2207 in the ECM. The DHCTSE627 then proceeds from the first NVSC pointer 1513 to Listing 1411 and looks for the MSK NVSC1601 with the MSK ID field 1603 containing the same value as the MSK ID field 2213 in the ECM. If such an MSK NVSC is found, the DHCTSE627 determines from the indefinite date flag 1607 whether the due date field 1605 has a valid time value, and if so, the DHCTSE627 has that value and the ECM timestamp. Compare with stamp field 2233. If the value in timestamp field 2233 is more recent in time, DHCTSE627 does not use MSK1608 from MSK NVSC1601 to decode control word 2235. The security element is the appropriate MSK Continue searching for MSK NVSCs by ID and non-expired MSK, and if it finds such an MSK NVSC, use that MSK NVSC; if the security element does not find such an MSK NVSC, the control word Do not decrypt. [0163]

DHCTSE627 simply searches list 1411 for the registration bitmap NVSC1613, or registration list NVSC1623 that contains a registration ID that is the same as one of the registration IDs 2245 in the ECM. If (1) DHCTSE627 finds an NVSC with such a registration ID, and (2) there is no valid expiration time in the NVSC that identifies a registration ID earlier than the time stamp 2233 in the ECM, and (3) ) DHCTSE627 is also a valid MSK as described above If NVSC1601 is found, DHCTSE627 decodes control word 2235 using the MSK and decryption information 2209 in the ECM. Decryption is done using the 3DES algorithm used to encrypt the control word. In a preferred embodiment, the control word contained in the ECM is a counter value as described above, and the DHCTSE627 decrypts the service instance by re-encrypting the integer using the MSK and 3DES algorithms. Generate a control word that is actually used in. The control word available by the service decoder is then returned to the service decryption module 625, which uses the control word to decrypt the service instance. [0164]

As is clear from the above, when the DHCTSE627 searches the registration agent information 1333 for a registration agent for a given registration for a service, it either finds the NVSC containing that registration or reaches the end of Listing 1411. Continue searching. What this logically means is that the registration that a given registration agent can give is a logical OR specified in the registration agent information 1333. For example, if one registration bitmap NVSC with the same registration ID as the ECM has expired, but not yet, DHCTSE627 removes the expired NVSC and generates control word 2235 based on the active NVSC. To do. [0165]

It should be further pointed out here that the timestamp 2233 in ECM and the expiration information in NVSC suppress the reuse of the MSK in the previous month to decrypt the instance in the current month, and also the Banker and above. Suppress the reuse of previous month's registrations in the current month to provide protection against the regenerative attacks described in Akins' patent application. [0166]

If additional restrictions are imposed on the registration, the DHCTSE627 looks for that information in the registration agent information 1333 as well. For example, if the ECM blackout / spotlight field 2223 indicates that the blackout applies to the service, the DHCTSE627 is identified by x-coordinate 1521 and y-coordinate 1523 using blackout / spotlight information 2236. Determines if the position is within the square identified by blackout / spotlight information 2236; if so, DHCTSE627 does not decode control word 2235. If a spotlight is applied, the procedure is of course the opposite: DHCTSE627 decodes the control word only if the x-coordinate field 1521 and the y-coordinate field 1523 locate within the square. [0167]

As mentioned above, the techniques used to award registrations according to geographic area can be generalized to award registrations to various subsets of customers. For example, the registration can be conceptually represented in the Venn diagram, the blackout / spotlight information 2236 can identify the area in the Venn diagram that represents the set of customers registered to receive the service, and the x-coordinate 1521 and The y coordinate 1523 identifies the customer's location on the Venn diagram. One use of such a configuration is to limit access to an instance of the service according to the customer's desire that the customer's DHCT does not have access to the instance with undesired content. In other embodiments, many coordinates, or other methods of representing the parent-child relationship of a set, can of course be used. [0168]

(Event service) If the ECM is accompanied by an example of an event, the ECM is interpreted as described above, except that the registration information for this event is contained within the event NVSC1701. DHCTSE627 retrieves entitlement information 1333 for a registration agent with an ECM EAID for event NVSC1701 that contains an event descriptor 1703 with a registration ID 1713 that is the same as one of the registration IDs 2245 in the ECM. If the event is a standard pay-per-view event, DHCTSE627 examines flag 1705 to determine if the customer has canceled the event and if the purchase of the event has been confirmed. (Always done in standard pay-per-view.) The DHCTSE627 then compares the purchase time 1707 and end time 1709 with the time stamp 2233 so that the time indicated by the time stamp is within the period indicated in fields 1707 and 1709. Determine if there is. When the investigation of event NVSC1701 shows that the customer is entitled to the event, DHCTSE627 decrypts control word 2235 as described above. [0169]

For IPPV or NVOD events, the allowed IPPV flag 2229 in the ECM should indicate that the event is an event that does not need to be purchased in advance. The free preview flag 2219 can also be set to indicate that some of the examples of events with ECM are part of the free preview, and the cancel window flag 2231 indicates that the event can still be cancelled. It can be further set as shown. If the free preview flag 2219 is set, the DHCTSE627 simply looks for the MSK NVSC1601 in the EA information 1333 containing the MSK specified by the MSK ID 2213 in the ECM. [0170]

If the free preview flag 2219 is not set, DHCTSE627 goes to event NVSC1701 with registration ID 1713 which is the same as registration ID in ECM field 2245. If the flag contained in flag 1705 indicates that the purchase of the event has been confirmed and the event has not been canceled, DHCTSE627 decodes control word 2235. If the event has not been canceled and has not been confirmed, but the time stamp 2233 indicates a time within a given time period after the purchase time 1707 indicated in event descriptor 1703, the DHCTSE627 also controls. Decrypt word 2235. In this way, the service example continues to be decrypted between the time when the FPM is sent to the registration agent and the time when the registration agent returns the acknowledge IPPV / NVOD event EMM. This sets the confirmation flag in flag 1705. [0171]

(Cancellation of registration for event: Figures 17, 19, and 22) Whether a user can cancel a registration for an IPPV / NVOD event that the user has already purchased is preferably determined by that event. There are three possibilities for this: Registration can be canceled up to 2 minutes after purchase. -Events can be canceled during a period called the "cancellation window". The event cannot be canceled. Which of the three possibilities is relevant to a given event is determined by the purchaseable registration data 1913 in GBAM that accompanies the event. One flag in flag 1917 indicates whether the event can be canceled, and another flag indicates in the cancel window that it can be canceled. If neither flag is set, the event cannot be canceled. DHCTSE627 forms an event descriptor 1703 for that event. The value of the flag in GBAM is used to set a flag in flag 1705 that indicates whether the event can be canceled or can only be canceled during the cancel window. Again, if neither flag is set, the event cannot be canceled. [0172]

The user cancels the event by requesting the DHCT333 to cancel via customer input 628. If the DHCT333 receives its input, the DHCT333 uses the EAID and registration ID to place an event NVSC1701 containing the event descriptor 1703 for that event, a cancellation request containing the EAID and registration ID for this example, DHCTSE627. To provide. A flag in flag 1705 indicates to the user that canceling the registration cannot cancel the registration. If the flag indicates that the registration can be canceled, the DHCTSE627 simply sets the canceled flag in the event descriptor 1703. If the registration can only be canceled during the cancel window and the flag indicates that the ECM flag indicating that the cancel window has ended has not yet been received, the DHCTSE627 sets the cancel flag in the event descriptor 1703. .. Otherwise, it will indicate to the DHCT333 that the registration cannot be canceled and the DHCT333 will notify the user. If the event is canceled, the DHCTSE627 clears the approved flag and this action causes the registration agent for the event to send a new FPM. The enrollment agent responds to the FPM by adjusting its billing required by the cancellation and sending a new approved EMM. [0173]

(Interactive session) The main difference between a broadcast service and an interactive service is that each session of the interactive service has its own interactive session key, which is included in the interactive session NVSC for that interactive session. NVSC for interactive sessions also includes a registration ID for interactive sessions. In an ECM with an MPEG-2 stream for an interactive session, the MSK ID field 2213 is set to a value indicating that the MPEG-2 stream will be decrypted using the interactive session key. When DHCTSE627 interprets ECM etc., DHCTSE627 uses registration ID 2245 to find the NVSC for that interactive session and decrypts control word 2235 using the interactive session key contained in NVSC. [0174]

(Detailed description of transaction encryption device 603: Figures 24 and 25) Each CAA that can authorize a registration agent in Digital Broadband Distribution System 501, and each EA that can authorize registration in System 501, has a transaction encryption device or TED603 in System 501. Preferably, each CAA or EA has its own separate TED within system 601. Alternatively, TED can be combined into one device. The TED603 has the hardware and software to store the private keys used by the entity to which it belongs and to perform the encryption, decryption, key generation, and authentication required by that entity. Run TED without user interface or user I / O device, run TED inside a non-tamperable container, connect TED only to DNCS, and use security links for that connection, and more Keys are kept secure by keeping TED in a physically safe environment such as a lock room. [0175]

For the TED603 for the CAA, the TED603 stores the private keys corresponding to the three public keys representing the CAA in the DHCT333, encrypts and provides the sealed digest of the EMM from the CAA to the DHCT333, and Decrypt and authenticate the message from the DHCT333 to the CAA. For TED603 for EA, EA TED does the following: (1) Stores the public and private keys for the EA and the MSK for the EA. (2) Generate EA public key, private key and MSK. (3) Encrypt and prepare the sealed digest for the EMM sent on behalf of the EA. (4) Prepare a shared secret digest used to authorize global broadcast messages. (5) Provide MSK to SEES module 620 to use the service example for encryption. (6) Interactive Sessions Generate interactive session keys (ISKs) for EMMs and provide them to SEES module 620 to encrypt interactive sessions. (7) Decrypt the FPM and other messages sent from the DHCT333 to the registration agent. [0176]

(TED603 in Conditioned Access System 601: Figure 24) FIG. 24 shows the relationship between the number of TED603s and the rest of the conditional access system 601. Part 2401 of Conditional Access System 601 contains CAA TED 2427 for CAAs that authorize registered agents in System 601. Part 2401 also includes one EA TED 2425 for each of the n + 1 registered agents owned by the CAA, which is currently authorized for DHCT333 in Digital Broadband Distribution System 501. Alternatively, all EA TED2425 features can be combined into a single TED. This single TED is a CAA May include TED2427 function. Each TED is maintained within the physically secure area 2428 and is connected to the DNCS507 by a secure fast link 2423 that connects only to the DNCS507 and TED603. In a preferred embodiment, the security link is a security Ethernet link. The DNCS507 uses TED605 to encrypt the EMM, decrypt the FPM, generate the EA public and private keys, generate the MSK and ISK, and prepare the global broadcast message digest. The DNCS607 has a remote procedure call interface to the TED603 that performs these operations, and as a result, programs running on the DNCS607 may use the TED mechanism by simply making a procedure call. [0177]

The DNCS507 is the only connection between the given TED603 and the rest of the conditional access system 601. The DNCS507 is connected by network 2415 to systems belonging to the CAA and various EA. Each of these entities has a database containing information related to its function. CAA2405 is authorized for CAA database 2403, which contains at least three public keys of CAA and three corresponding private keys of the encrypted version, registration agent identifiers for registration agents that CAA authorizes, and authority for DHCT. Each enrollment agent has a per-DHCT database containing the NVSC name, type, and number to which the CAA is assigned. [0178]

Each EA2409 (i) has its own EA database 2407 (i). The EA database 2407 (i) preferably contains a database of EA IDs for the EA, MSK IDs and expiration dates for the MSKs currently in use by the EA, and services and / or instances provided by the EA. including. The database for this service contains at least a registration ID for each service. EA Database 2407 (i) also includes a per-DHCT database of registration IDs, registration expiration times, and MSK IDs for registrations and MSKs sent to the DHCT within the EMM. The per-DHCT database also contains customer billing information such as the information required to handle purchase information within the FPM. [0179]

Key certification authority 2413 is an entity that certifies the public key of DHCT333 to DNCS507. In a preferred embodiment, the key certification authority 2413 is maintained by the manufacturer of the DHCT333. DHCT Key Database 2411 contains a database of DHCT serial numbers and their public keys. If a user of the DHCT333 wants to purchase an instance of the service provided by the EA, the user sends a purchase offer to the EA that has the DHCT333 serial number (which is also the IP address). The EA provides the DNCS507 with a serial number, which maintains the DHCT public key database 2421 by serial number. If this serial number is not in the database, DNCS507 sends a request for the public key to KCA. The request includes a serial number and the key certificate authority responds to the request by sending a digitally signed message 2412 to the DNCS507. This message contains the DHCT public key. DNCS507 has the public key for the key certification authority and uses the public key and digital signature to verify the validity of the DHCT public key in the message. If the public key is valid, DNCS507 places it in the public key database 2421. [0180]

The DNCS507 is further connected to the SEES620 via another high speed link 2417. The SEES620 has an MSK that encrypts an instance of the service. In addition, the DNCS507 provides global broadcast messages (GBAM) and EMM for broadcast to the DHCT333 via transport link 517. Finally, the DNCS507 is connected to the DHCT333 via the reverse path provided by the LAN interconnect device 617 and receives the FPM from the DHCT333. In other embodiments, the DHCT333 may also transmit EMMs to the DHCT333 by this route. [0181]

The data flow within part 2401 is indicated by a label on the arrow connecting the components. Therefore, the EA2408 (i) sends the EA EMM unencrypted content 2410 and the global broadcast message to the DNCS507 and receives the FPM unencrypted content 2412 for the EA from the DNCS507. For EA EMM and global broadcast messages, DNCS507 uses EA TED2425 (i) to perform the required encryption, digest generation, and key generation, and encrypts and authenticates EMM and global broadcast messages, as well as MSK. Send to SEES620 as shown in 2426 and 2418. In the case of EMMs, the EMMs are repeatedly sent to the DHCT for an extended period of time, while the DNCS507 stores the encrypted EMMs in the EMM database 2420 and provides them to the SEES620 from here. At FPM, DNCS507 is the EA for EA2409 (j) to which the FPM is addressed. Decryption and authentication are performed using TED2425 (j), and the decrypted FPM content 2412 is transmitted to EA2409 (i). The DNCS507 processes CAA EMMs in the same way as EA EMMs, except that encryption and digest generation are performed using CAA TED2427. [0182]

DNCS507 also includes a database 2419 of encrypted entity information. It contains an encrypted copy of the private key and MSK stored on the TED609 connected to the DNCS507. In the unlikely event that a TED malfunction or physical corruption results in the loss of key information, this encrypted entity information will be used to re-store the TED. Encryption is done within TED using path phase. When the information is encrypted, this encrypted information is output to DNCS507 and stored in database 2419. If the TED is re-stored, this information is entered into the TED along with the path phase. Then, this TED decrypts the key information. [0183]

(Detailed execution of TED2425 (i): Figure 25) FIG. 25 is a detailed block diagram of a preferred embodiment of the EA TED 2425 (i). In a preferred embodiment, the EA TED2425 (i) is performed using a chassis with a standard computer motherboard and a standard Ethernet board, as well as additional means of facilitating RSA encryption and decryption. [0184]

As shown in Figure 25, the main components of the TED2425 (i) are the CPU 2501, memory 2505, hardware random number generator 2537, Ethernet board 2541, and multiple RSA accelerator boards 2539 (0 ... n). All are interconnected by bus 2503. With more than one RSA accelerator board 2539, RSA encryption and / or decryption is done in parallel. As a result, a preferred embodiment of the TED2425 (i) performs multiple EMMs at extremely high speeds, eg, within 1 second, while performing other operations, including encryption, digest generation, or decryption at similar speeds. , Can be encrypted. [0185]

Memory 2505 contains EA information 2507, which is the public and private key for the registration agent to which TED2425 (i) belongs, MSK for the EA, and code 2523, which is the code executed by CPU2501. The portion of memory 2505 containing code 2523 and EA information 2507 is non-volatile, the portion containing code 2523 is read-only, and the portion containing EA information 2507 is readable and writable. The code used in this explanation is: (1) MSK generation code 2525 that generates MSK and ISK from the random numbers provided by the random number generator 2537. (2) RSA key generator 2517 that generates public and private RSA keys from random numbers (3) MD5 code 2529 that executes the MD5 one-way hash algorithm (4) 3DES code 2531 for 3DES encryption and decryption (5) GBAM grant code 2533 to generate a shared secret digest used to authenticate global broadcast messages (6) RSA encryption / decryption code 2535, which performs RSA encryption / decryption with the assistance of RSA hardware 2539. (7) EA information encryption code 2536 that encrypts EA information 2507 in the pass phase for storage in DNCS507. (8) EMM code 2538 to generate encrypted and authenticated EMM (9) FPM code 2540 that decrypts and checks FPM EA Information 2507 contains the information required to encrypt and authenticate GBAM and EMM transmitted on behalf of the EA represented by TED2425 (i). EA Information 2507 also facilitates and contains information for decrypting and validating the FPM directed to that EA. In a preferred embodiment, the EA information 2507 is at least (1) EAID2509, which is the EAID for EAID2409 (i), EA Ku2511 and EA Kr2513, which are the public and private keys for EA2409 (i), respectively, and ( 2) Includes the MSK entry (MSKE) 2515, for each MSK used by EA2409 (i) in the conditional access system 601 to which TED2425 (i) belongs. Each MSKE2515 contains the MSK identifier 2517 for the MSK, the expiration time 2519 for the MSK, if any, the MSK parity 2520 for the MSK, and the MSK2521 itself. [0186]

(Actions performed by EA TED2425 (i)) Once initialized, the EA TED2425 (i) is provided with an EAID for the EA represented by the TED2425 (i). The EA TED2425 (i) stores the EAID in 2509 and uses the RSA key generation code 2517 and the random numbers from the randomizer generator 2537 to generate the EA public key 2511 and the EA private key 2513. The EA public key 2511 and the EA private key 2513 are stored in EA information 2507. Remote Procedure Call (RPC) allows DNCS507 to read the EA public key 2511. Other RPCs have DNCS507 read the serial number of TED2425 (i), get and set the system time of TED2425 (i), and call TED2425 (i) to determine if it is responding. Allow. TED2425 (i) answers this call with its serial number. EA TED2425 (i) also reports multiple alarm conditions to DNCS507. These include cryptographic and global failures, random number generation failures, memory failures, and TED and Ethernet overloads. [0187]

While continuing to encrypt and authenticate the EMM, the DNCS507 has two RPCs, usually one for the EMM and the other for the MSK EMM. If the DNCS507 generates a non-MSK EMM for the EA2049 (i), the DNCS507 receives the following from the EA2049 (i): (1) Serial number of DHCT333, which is the destination of EMM (2) EAID for EA2049 (i) (3) EMM type (4) Information required for that particular type of EMM, such as a registration bitmap, along with a first registration ID, expiration date, and non-expiration date flags. [0188]

DNCS507 uses the serial number to look up the public key for DHCT333 in the public key database 2421 and uses EAID to determine which TED2425 to use and format the information required for this type of EMM. , And provide the formatted information (1123, 1125, 1127 in Figure 11) to TED2425 (i) via RPC along with the DHCT public key. EMM code 2538 then uses MD5 code 2529 to generate a digest of the formatted information, and RSA E / D code 2535 to encrypt the information formatted with the DHCT public key, and Encrypt the digest with private key 2513 for EA. The encrypted and formatted information and the encrypted digest are provided to the DNCS507. The DNCS507 places the EMM in the EMM database 2420, adding something else needed. [0189]

For MSK EMM, DNCS507 receives EAID, DHCT serial number, EMM type, MSK parity, MSKID, and expiration date from EA2409 (i). The DNCS507 then retrieves the DHCT serial number, formats the information, and generates the RPC call described earlier. In this case, the EMM code 2538 looks into the EA information 2507, finds the MSK corresponding to the MSK ID, and adds the MSK to the formatted information. The EMM code 2538 then uses the RSA encryption / decryption code to encrypt the information formatted with the DHCT's public key and the digest with the EA's private key, and, as described above, Return EMM to DNCS507. [0190]

The interface that gives the authentication information to the global broadcast message requires the MSKID of the supplied secret MSK and the contents of the global broadcast message. The GBAM authorization code 2533 in TED2425 (i) uses the MSKID to place the MSKE2525 for the MSK, combine the MSK2521 with the content of the global message (GBAM header 1807 and global broadcast data 1809 in Figure 18), and the MD5 code. Use 2529 to generate a digest (GBAM MAC1805). This digest returns to DNCS507. [0191]

In a message sent from the DHCT333 to the EA, such as a forwarded purchase message, the IP packet from which the message was sent contains the IP address of the DHTC333 that is the source of this message, and this IP address is the serial of the DHCT333. Includes number. The DNCS507 uses this serial number to place the public key for the DHCT333 in the public key database 2421, and the public key is signed from the FPM with the encrypted envelope key 2103, CA FPM message 2105, and FPM. Provided to TED2425 (i) with certification 2107. Next, FPM code 2540 is: (1) Decrypt FPM-encrypted envelope key 2103 using EA public key 2511 and RSA encryption / decryption code 2535; (2) Decrypt FPM-encrypted event 2113 using 3DES code 2531 and the decrypted envelope key; (3) Decrypt FPM authentication 2107 using the public key for RSA encryption / decryption code 2535 and DHCT333; (4) Using the encrypted and then decrypted event with MD5 code 2529, generate a new hash to compare with the decrypted value of FPM authentication 2107. If this comparison shows that the FPM is valid, TED2425 (i) returns the decrypted event to DNCS507. DNCS507 forwards them to EA2409 (i). [0192]

The MSK in the MSK2515 is generated by TED2425 (i). The interface for MSK generation simply requires the MSKID for the new MSK, the parity for the new MSK, and any expiration time. The MSK generation code 2525 receives a random number from the random number generator 2537 and uses the random number to generate a new MSK. The MSKE2515 for the new MSK is then generated and added to the EA Information 2507. If an MSKE2525 for the MSKID for the new MSK already exists, the new MSKE will replace the existing MSKE. TED2425 (i) also generates an interactive session key for the additional interactive session EMM. Key generation is as described for MSK EMM. Once the TED2425 (i) provides the DNCS507 with EMM content with an encrypted key, the TED2425 (i) overwrites the area in memory 2505 where the interactive session key is stored. [0193]

(CAA TED) The CAA TED2427 has the same hardware as the EA TED, but in a preferred embodiment it only encrypts the CAA EMM used to establish a registration agent within the DHCT333. EMM encryption is done exactly as described for EA TED. The only keys required for CAA TED encryption and authentication are the DHCT333 public key and the CAA private key. Therefore, it is only required to store one of the three public key private key pairs that represent the CAA. The CAA public private key pair is generated somewhere else. The private key, along with its key pair, is encrypted using the path phase provided to the CAA TED2405. CAA TED then decrypts the private key and stores the decrypted private key in memory 2505 instead of the path phase. The encrypted private key, not the path phase, is also stored in the encrypted entity information 2419 in DNCS507. [0194]

(Authentication of data for applications running on DHCT333: Figure 23) The above is how the conditional access system 601 is required to decrypt an instance of the service using the conditional access authority, registration agent, DHCTSE627, and transaction encryption device 603. Also disclosed whether to provide security for keys and registration information. Another function of Conditional Access System 601 is to ensure secure data downloads for applications running on the DHCT333. There are two paths from which data can be downloaded: (1) in an MPEG2 stream via a high bandwidth path from SEES619 via transport network 517 to HFC network 521 and then to DHCT333, and (2). Within an IP packet over a low bandwidth path from control suite 607 through LAN interconnect device 617 and QPSK modulator 621 to HFC network 521 and DHCT333. [0195]

As seen in the data used in Conditional Access System 601 there are two aspects to the problem: security and authentication. Security is achieved by encrypting the data. For data delivered by high bandwidth aisles, the data is directed to a particular DHCT333, either by DES with MSK if the data is directed to all DHCT333s that have a given registration agent. In some cases, encryption can be done with the public key for the DHCT. For data delivered by low bandwidth aisles, the data can be addressed to a specific DHCT333 IP address and encrypted with the DHCT333's public key. When encrypting with the MSK, the MSK is provided by the transaction encryption device 603, and when encrypting with the public key of the DHCT333, the transaction encryption device 603 can provide the key or by itself. Can be encrypted. The DHCTSE627 contains the key required to perform the decryption required by the DHCT333. [0196]

The authentication entity in the conditional access system 601 includes a conditional access authority and a registration agent. Authentication of downloaded data is similar to EMM, that is, it uses a one-way hash function to generate a digest of the downloaded data, and then encrypts that digest with the authentication entity's private key. This is done by generating a sealed digest. In a preferred embodiment, the sealed digest is generated on the transaction encryption device 603. When the downloaded data arrives at DHCT333, DHCTSE627 uses the authentication entity's public key to decrypt the sealed digest and then uses a one-way hash function to hash the downloaded data again. .. If the downloaded data is legitimate and is not destroyed during transmission, then the decrypted digest of the sealed digest and the result of hashing the data with the one-way hash function are equal. It should be noted here that the authentication is done by the CAA or EA known to the digital broadband distribution system, not by the originator of the data. Moreover, since the CAA or EA is already known to the DHCT333, downloading the authentication data to the DHCT333 can occur without the intervention of the DHCT333 user. [0197]

There are many ways to associate authentication with authenticated data. One method is to use GBAM, as described above for Figure 20. In such cases, GBAM payload 2003 is a digest of the downloaded data, and registration agent 2005 encrypts the digest with a private key in addition to generating the digest using payload 2003 and MSK. .. Another method is to simply send the message, as well as the data, via the MPEG-2 transport stream or by using an IP packet that contains an authentication part. [0198]

Certain types of data that can be downloaded using the above techniques are code executed by a general purpose processor in the DHCT333. The memory that can be used by the processor includes a portion that is flash memory. That is, this memory cannot be written like normal writable memory, but can only be rewritten as a whole. Such memory is typically used to hold downloadable code. Figure 23 shows a message containing downloadable code. Code message 2301 has two parts: authentication part 2303 and code part 2305. Code portion 2305 contains encrypted or unencrypted code, if circumstances require. Authentication part 2303 contains at least two items of information: Authentication Identifier (AID) 2307 and Sealed Digest 2309. Authentication identifier 2307 is a CAAID or EAID for a conditional access authority or a registration agent with authentication code 2305. The sealed digest 2309 is generated by hashing code 2305 within a one-way hash function to generate a digest, and then encrypting this digest with the private key of the CAA or EA authenticating the code. .. SD2309 is generated by transaction encryption device 605 in a suitable environment. [0199]

Code message 2301 may send either an MPEG-2 transport stream or an IP packet. Message 2301 may be broadcast to a DHCT333 with certified CAA or EA, or may be sent to a particular DHCT333. In that case, the packet carrying code message 2301 contains the address for DHCT333. In a preferred embodiment, the address is the DHCT333 serial number. When code message 2301 arrives at DHCT333, the code running on the processor executes a one-way hash function on code 2305 and provides the result to DHCTSE627 along with AID2307 and the sealed digest 2309. The DHCTSE627 uses the AID2307 to place the public key for the CAA or EA, and then uses the public key to decrypt the sealed digest 2309. Finally, DHCTSE627 compares the hash values in digest 2309, which decrypted the sealed digest, with the hash values provided by the code running on the processor, and if they are equal, The DHCTSE627 signals that the code has been authenticated. [0200]

(Public key hierarchy (Fig. 28)) The various elements of the system described herein collectively execute the public key hierarchy 2801 within the network. Such a hierarchy establishes a "trust chain" that supports scaleable and spontaneous commercial interactions between the DHCT333 and other networks that use public-key security, such as the Internet. It is advantageous because it can be used to. Can be used to establish credibility in user commercial interactions with DBDS501. [0201]

Figure 28 shows the hierarchy of public key certificates in DBDS. Shows two independent "trust chains". On the left-hand side is the "DHCT chain", which establishes the validity of the public key associated with the DHCT333 and allows for the trusted use of digital signatures made by the DHCT333. On the right-hand side is the "operator chain", which establishes the variability of public keys associated with network operators and underlying EA within each system and enables trusted use of the signatures of these entities. [0202]

The DHCT signature 2806 can be used to authenticate messages sent by the DHCT333, as described elsewhere herein. However, in order for the recipient to trust such a DHCT signature to be legitimate, the public key requested to be associated with the DHCT333 is received as a legitimate key that actually matches the DHCT's private key. One needs to be convinced. This is achieved by certifying the DHCT Certificate 2806 with the Factory Programmer Certification Authority (FPCA) signature. The FPCA signature can be trusted because a reference to the FPCA certificate 2805 can be made. The DHCT certificate 2806 and the FPCA signature, like the FPCA certificate 2805, are preferably generated in a secure manner when the DHCT333 is generated. Each FPCA certificate is also certified with the signature of the DHCT root, which may have its own certificate 2804, as it may eventually be necessary to issue a new FPCA certificate and use the new FPCA signature. This DHCT root certificate 2804 can be signed by itself or certified by another institution. DHCT root signatures are preferably managed on good, non-tamperable devices, such as those that meet the requirements of FIPS40-1 Level 3 certificates. [0203]

In the operator chain, various EA certificates 2803 are used to sign as described elsewhere herein. Similarly, an operator CAA signature with an operator CAA certificate 2802 is used to certify each EA signature, as already described herein. On top of the operator CAA signature, two root CAA signatures can be used to introduce the operator CAA2802 into the DHCT333 in a secure manner. In fact, preferably at generation time, the three root CAA public keys are placed within the secure NVM of the DHCT333. A legitimate message from either two of the root CAA is then used to replace the third root CAA public key with the operator CAA public key whose key is certified in the operator CAA certificate 2802. obtain. The root CAA is preferably managed by the manufacturer within a non-tamperable device that meets or exceeds the requirements of the FIP140-1 Level 3 Certificate. However, it is possible to change all root CAA public keys to other CAA public keys that are not under the control of the manufacturer through a proper sequence of messages. Therefore, the manufacturer can be excluded from the signature chain. In this case, the root CAA can be some other mechanism approved by more than one operator, or it can be managed by an operator. [0204]

Each operator may have multiple EA, as shown in FIG. 28 and described elsewhere herein. In a preferred embodiment, there is a different EA and associated EA certificate 2803 for each operating site of any operator. This ensures that DHCT cannot be moved between operational sites without the knowledge and involvement of operator CAA signature 2802. [0205]

The geo-political CA certificate 2807 shown in Figure 28 is not required to perform the operator's normal conditional access and electronic activity. However, the operator may wish to link its signature chain to a larger chain so that it can participate in a transaction involving an entity outside the operator's DBDS, or DHCT333 can participate in that transaction. .. In this case, the signature chain is a chain of geopolitical CAs by having the public key of one or all of the DHCT root signature 2804, root CAA signature 2808, or operator CAA signature 2802 certified by the geopolitical CA signature. And its signature 2807 can be easily linked. This is achieved by having a certificate located in the database for each of the public keys associated with signatures 2804, 2808, and 2802. The above certificate is signed with the private key of Geopolitical CA2807. [0206]

Figure 29 shows the EMM generator 2901. As described elsewhere herein, DHCTs operated by different operators within different DBDS instances are preferably controlled by that operator and the CAA of the system-specific operator. Since the DHCT333 at generation time is not configured to be controlled by any operator CAA, instead it is controlled by three root CAA public keys that are placed in the memory of the security processor during manufacturing. The DHCT333 needs to be reconfigured to be controlled by a different operator. This needs to be done safely. As described elsewhere herein, messages with digital signatures of two of the root CAAs can be used to reconfigure the terminal for a third CAA. The EMM generator 2901 is used to generate one of the two messages required to introduce the new operator CAA public key into the DHCT333 in a proven manner. You can see that the DHCT public key certificate 2902 is entered into the EMM generator and a DHCT message is generated for it. The DHCT controlled by a particular operator can be located in a separate file on the input device or can be associated with the operator in other ways apparent to those skilled in the art. [0207]

Prior to generating the introductory EMM2903, the various operator-proven public keys provided by the EMM generator 2901 are loaded into the public key memory 2904 of the EMM generator 2901. Therefore, when the EMM generator 2901 reads the DHCT input that needs to be introduced to operator A, the EMM generator uses operator A's public key read from memory 2904 to use operator A's public key. Generate an EMM containing. Similarly, the root CAA private key must be loaded into the private key memory 2905 of the EMM generator 2901 prior to generating the introductory EMM2903. The EMM is digitally signed by the EMM generator 2901 using the root CAA private key contained in memory 2905. Since the private signing key is contained in memory 2905 of EMM generator 2901, EMM generator 2901 must be run in a secure manner to prevent the value of the root CAA private key stored in memory 2905 from being discovered. There is. Therefore, the EMM generator 2901 meets the requirements of a FIPS40-1 Level 3 certificate or runs in a higher degree of tamper-proof device. [0208]

Since it is necessary to use two root CAA private keys to sign individual CAA introduction EMM2903s, two EMM generators 2901 are preferably provided, each corresponding to each of the two root CAA private keys. To do. The EMM generator 2901 is preferably operated in individual physical equipment. [0209]

The detailed description of the preferred embodiments described above is considered to be exemplary and not limiting. The scope of the present invention disclosed herein is determined from the scope of claims interpreted in the maximum range permitted by patent law.

[Simple explanation of drawings]

[Figure 1]

It is a block diagram of a conditional access system. [Fig. 2A]

It is a block diagram of the service instance encryption technique disclosed in this application. [Fig. 2B]

It is a block diagram of the service instance decoding technique disclosed in this application. [Fig. 3]

It is a more detailed block diagram of the service instance encryption and decryption technology disclosed in this application. [Fig. 4]

FIG. 6 is a block diagram of the technology used to dynamically provide registration for DHCT. [Fig. 5]

FIG. 6 is a block diagram of a digital broadband transmission system in which a conditional access system is implemented. [Fig. 6]

It is a block diagram of the conditional access system in the digital wideband transmission system of FIG. [Fig. 7]

It is a figure of an MPEG-2 transport system. [Fig. 8]

It is a diagram of how to map an EMM to an MPEG-2 transport system. [Fig. 9]

It is a figure of the method of mapping an EMM to an IP packet. [Fig. 10]

It is a figure of the method of mapping ECM to an MPEG-2 transport system. [Fig. 11]

It is a detailed diagram of EMM. [Fig. 12]

It is a figure of a preferable embodiment of DHCTSE627. [Fig. 13]

It is a figure of the memory content of DHCTSE627. [Fig. 14]

It is a figure of the method of assigning NVSC to a registration agent in a preferred embodiment. [Fig. 15]

It is a figure of EAD NVSC. [Fig. 16]

It is a figure of another kind of NVSC. [Fig. 17]

It is a figure of the event NVSC. [Fig. 18]

It is a figure of a global broadcast authentication message (GBAM). [Fig. 19]

It is a kind of figure of GBAM. [Fig. 20]

It is a figure which shows the method of generally providing data to a client application using GBAM. [Fig. 21]

It is a figure of the sent purchase message. [Fig. 22]

It is a figure of the registration unit message in ECM. [Fig. 23]

It is a figure of a code message. [Fig. 24]

It is a figure which shows the relationship between TED and the rest of conditional access system 601. [Fig. 25]

It is a detailed figure of TED. [Fig. 26]

FIG. 5 is a diagram of a coordinate system used for spotlights and blackouts. [Fig. 27]

It is a figure which shows the method of calculating the area in the coordinate system of FIG. [Fig. 28]

It is a figure of a public key hierarchy. [Fig. 29]

It is a figure of the EMM generator by this invention.