INTERFACE PROTECTION SYSTEM FOR PROTECTING COMMUNICATIONS
BETWEEN INTEGRATED CIRCUITS
RELATED APPLICATIONS The present application claims priority under 35 U.S.C. § 120 of U.S. Provisional
Application 60/277,486, filed March 21, 2001.
FIELD OF THE INVENTION
This present invention relates to a method for protecting an interface between two integrated circuits (ICs) on a printed circuit board (PCB).
BACKGROUND OF THE INVENTION
Conditional access (CA) systems are well known. Conditional access systems allow access to services (e.g., television, internet, etc.) based on payment and/or other requirements, such as authorization, identification and registration. In a CA system, a user (subscriber) enters into a service agreement with a service provider to obtain access rights.
Conventional CA systems include cable, satellite, and terrestrial broadcast systems. A typical CA system includes a source of content and entitlement messages, a receiving device, such as a set top box (STB), and a display device for the content, such as a digital television (DTN). As is well known, the content and entitlement messages are typically encrypted before they are transmitted to the receiving device.
In a first conventional CA system, the STB includes a printed circuit board (PCB) with at least one integrated circuit (IC) disposed thereon for carrying out the various functions of the STB (e.g., decryption of content, etc.). The STB also typically includes a smart card which is coupled to the IC through an interface. The IC receives an input data stream which includes encrypted data and entitlement messages. The IC separates the encrypted data from the entitlement messages and sends the entitlement messages to the smart card. In the smart card, the entitlement messages are deciphered to extract a decryption key or keys for decrypting the encrypted data stream. The decryption key(s) are typically in the Data Encryption Standard (DES) format, but may exist in any suitable format (e.g., Advanced Encryption Standard (AES), etc.). The decryption key(s) are then returned to the IC to
decrypt the encrypted input data stream. The decryption key(s) are typically sent from the smart card to the IC 'in the clear' (i.e., not encrypted), and thus may be easily accessed by hackers.
In a second conventional CA system, the STB includes a PCB with at least two ICs disposed thereon for carrying out the various functions ofthe STB (e.g., decryption of content, etc.). A first IC typically contains a Central Processing Unit (CPU) for, among other functions, assisting in the decryption of content (the 'transport' IC). A second IC typically contains security data (the 'security' IC) such as keys for decryption. As will be noted from the foregoing discussion, the security IC provides an additional measure of protection, as opposed to the first conventional embodiment. The 'security' IC and the 'transport' IC are typically coupled to each other by a first interface. This interface may comprise a series of electrical traces on the PCB, or may be some other equivalent interface. As in the first conventional embodiment, the STB also typically includes a smart card which is coupled to the transport IC through a second interface. The transport IC receives an input data stream which includes encrypted data and entitlement messages. The transport IC then separates the encrypted data from the entitlement messages and sends the entitlement messages to the smart card. In the smart card, the entitlement messages are deciphered to extract a decryption key or keys for decrypting the encrypted data stream. As with the first conventional embodiment, the decryption key(s) are typically in the DES format, but may exist in any suitable format (e.g., Advanced Encryption Standard (AES), etc.). The decryption key(s) are then returned to the transport IC to decrypt the encrypted data. However, in the second conventional embodiment the key(s) are re-encrypted before they are returned to the transport IC (i.e., they are not sent 'in the clear'). The re-encrypted keys are then routed to the security IC across the second interface. The security IC decrypts the key(s) and returns them to the transport IC 'in the clear' across the second interface. Finally, the key(s) are used in the transport IC to decrypt the encrypted input data stream.
As mentioned above, the information or content (e.g., television program, movie, etc.) and the entitlement messages transmitted to the STB are protected (e.g., encrypted) before they are delivered to the subscriber. Presently, there are two (2) types of entitlement messages associated with each program or service. Entitlement control messages (ECMs) carry descrambling keys (sometimes referred to as 'control words') and a brief description ofthe
program (e.g., program number, date, time, cost, etc.). Entitlement management messages (EMMs) specify the service-related authorization levels (e.g., indicating the type of service, the duration ofthe service, etc.). The EMMs can be distributed on the same channel as the service, or may be sent on a separate channel, such as a telephone line. As mentioned above, the ECMs are typically multiplexed and sent with the associated program.
As described above with reference to the first and second conventional embodiments, as a program (input data stream) is received at the STB, the received portions thereof are decrypted and displayed on the DTV or other equivalent display device.
In the first conventional embodiment described above, the decryption key(s) are sent 'in the clear' over the interface between the IC and the smart card. Various methods presently exist for protecting content passing back and forth across the smart card/IC interface. However, present interface protection methods require a key (or secret) to be stored at one or both ends ofthe interface (e.g., in a nonvolatile memory within the IC or the smart card or both). If these key(s) are the same across all STBs (as is commonly the case), security is compromised in the event that a hacker gains access to one of these keys. In particular, the hacker can use the key to discover the decryption keys used to decrypt the data stream for all STBs.
In the second conventional embodiment described above, information and content must be transmitted back and forth over the second interface between the transport IC and the security IC before the program is displayed on the DTN. Various methods presently exist for protecting content passing back and forth across an interface between ICs in a STB. However, present interface protection methods require a key (or secret) to be stored at one or both ends ofthe interface (e.g., in a nonvolatile memory within the transport IC or the security IC or both). As noted above, if these key(s) are the same across all STBs (as is commonly the case), security is compromised in the event that a hacker gains access to one of these keys. In particular, the hacker can use the key to discover the decryption keys used to decrypt the data stream for all STBs. Making a key or keys unique to each STB presently involves the addition of a non-volatile memory unit to the IC for storing the key(s). While this approach addresses the security problem, it also increases the cost and complicates the production and handling ofthe IC.
Thus, there is presently a need for interface protection system and method which provides security without requiring a key (or secret) to be stored at either end ofthe interface.
SUMMARY OF THE INVENTION
The present invention is a method for protecting a communications interface between a first device and a second device, including, generating at least one pseudo-random number in a first device, and encrypting a content stream sent from a second device to the first device utilizing the at least one pseudo-random number.
The present invention also comprises an interface protection system including a first device including a pseudo-random number generator, a second device, and an interface coupling the first and second devices together to permit transfer of information therebetween.
Further, the present invention comprises a conditional access system including a content transmitting device and a content receiving device, wherein the content receiving device includes a ring oscillator and a random number generator for protecting transmissions across an interface ofthe content receiving device.
Additionally, the present invention comprises a receiver including a first integrated circuit including a ring oscillator and a pseudo-random number generator, a second integrated circuit, and an interface coupling the first and second integrated circuits, wherein the ring oscillator and the pseudo-random number generator collectively generate at least one pseudorandom number for encrypting communications between the first and second integrated circuits across the interface.
Finally, the present invention comprises a method for protecting a communications interface between a first device and a second device, including generating at least one key pair in a first device, and encrypting a content stream sent from a second device to the first device utilizing a first key ofthe at least one key pair.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a block diagram showing an interface protection system according to an exemplary embodiment ofthe present invention.
DETAILED DESCRIPTION
The present invention provides a mechanism to cryptographically protect an interface, such as an interface between integrated circuits (ICs) in set top box (STB) deployed/used in a conditional access (CA) system. An interface between the ICs in the STB may be protected by a key or keys which are generated by one ofthe ICs. The key is preferably unique to each set of ICs, and may be changed at regular intervals (e.g., every 3 seconds) to ensure the interface remains secure. The interface may be further protected through the use of secure key exchange method.
In the present invention a secret (e.g., pseudo-random number) generated locally at a receiver is utilized to protect an interface between ICs ofthe receiver. The pseudo-random number is preferably generated in one ofthe ICs ofthe receiver, and used to generate a cryptographic (preferably a public key of a public/private key pair) key which is then later transmitted to the other ofthe ICs. The transmission ofthe cryptographic key between ICs is preferably accomplished by a secure key transmission algorithm such as the Diffie-Hellman algorithm. The Diffie-Hellman algorithm is well known to those of ordinary skill in the cryptographic art. It permits a piece of information (in this case a cryptographic key generated from the pseudo-random number) to move from one device to another over an interface without ever placing the information itself onto the interface.
Figure 1 shows a block diagram of an interface protection system 100 according to an exemplary embodiment ofthe present invention. The system 100 comprises a printed circuit board (PCB) 110, which includes a first integrated circuit (IC) 120 ('transport' IC), and a second IC 130 ('security' IC). As described herein the PCB is preferably an integral part of a STB, but those of ordinary skill in the art will note that the PCB may be part of any system. An interface 125 between the first and second ICs 120, 130 provides a conduit for the sharing of information between the ICs. The interface 125 may comprise a series of electrical traces on the PCB, or any other equivalent interface.
The first IC 120 includes a security central processing unit (CPU) 135 coupled to the interface 125. The first IC 120 also includes a Read-Only Memory (ROM) 140, a ring oscillator 145, a pseudo-random number generator 150, an interface protection key register 155, a counter 160, a security chip interface circuit 165, a Content Protection Control Word (CPCW) keys register 170, and a Control Word (CW) keys register 175. A Voltage Controlled Oscillator (VCXO) 210, which may on the PCB 110 or external to the PCB, provides a clock signal to the counter 160. The CPCW keys stored in the CPCW keys register 170 are preferably used to protect content stored on a hard disk drive (HDD) 220 external to the PCB 110. The CW keys stored in the CW keys register 170 are preferably used to decrypt broadband data which comes into the PCB 110 from a cable, satellite, terrestrial line, Digital Subscriber Line (DSL), or other broadband data input source.
The first IC 120 also includes a demultiplexer 180, a broadband decrypt circuit 185, a hard disk drive (HDD) decrypt circuit 186, an HDD encrypt circuit 187, and a clock recovery circuit 190. The demultiplexer 180 includes a first input for receiving cable, satellite, terrestrial line, DSL, or other broadband data ('broadband data'), and a second input for receiving data from a hard disk drive (HDD) 220. No matter what the source ofthe input data (e.g., cable/satellite/terrestrial line/DSL or HDD), the entitlement data (e.g., EMMs, ECMs, etc.) is separated from the A/V data and routed to separate portions ofthe first IC 120. Time stamp signals are also issued from the demultiplexer 180 corresponding to each new set of input data which is received. These time stamp signals are applied to the clock recovery circuit 190 and used to lock the local system clock ofthe PCB 110 to the system clock ofthe transmitter (e.g., cable sub-station, satellite, etc.).
Referring to the clock recovery circuit 190, it will be noted by those skilled in the art that a digital encoder at the transmitter has a specific system reference clock. Further, the transmitted broadband data packets contain a time stamp reference related to the state ofthe encoder system reference clock at the time of transmission. A local counter on the PCB 110, clocked by the NCXO 210 (system clock), is sampled at the moment a packet carrying a reference time stamp is received at the PCB 110. The sample ofthe local counter and the received reference time stamp are then compared in the clock recovery circuit 190 to determine whether the system clock (NCXO 210) is running faster or slower than the encoder system clock. The difference signal is then used to either increase or decrease the local
system clock rate and, and thus lock the local system clock to the encoder system clock. Locking the local and encoder system clocks insures that data is consumed at the proper rate to prevent buffer overflow or underflow failure conditions at the receiver (e.g., PCB 110). Of course, those of ordinary skill in the art will understand that the above description assumes an equal delay system, such as terrestrial or satellite transmission. In the case of a non-equal delayed system, such as Ethernet, other buffering or network de-jittering mechanisms should be employed to either recover the reference clock or manage the consumption of data and minimize the likelihood of buffer management errors.
The second IC 130 contains the security information necessary to decrypt encrypted keys (e.g., CWs, CPCWs) transmitted to the security CPU 135 from a smart card 200. The smart card 200 is external to the PCB 110, and may be coupled thereto through an interface.
Separate processes will be performed to decrypt incoming data depending upon the source ofthe data. If the data is transmitted from a cable/satellite/terrestrial line/DSL source, Control Words (CWs) will typically be utilized to decrypt the data. However, if the data is transmitted from the HDD 220, Copy Protection Control Words (CPCWs) will typically be used to decrypt the data.
In the situation where data is received at the first IC 120 from a cable/satellite/terrestrial line/DSL source, the process proceeds as follows. As data is received by the first IC 120, such data is demultiplexed at demultiplexer 180 to separate the Audio/Visual (A/V) data from the entitlement data (e.g., EMMs, ECMs, etc.). The entitlement data is then transmitted to the smart card 200 where it is deciphered to generate keys for decrypting the A/V data. These decryption keys (referenced in Figure 1 as 'smart card encrypted keys'), which are commonly referred to as Control Words (CWs), are then re- encrypted and sent to the security CPU 135. The security CPU 135 then passes the encrypted decryption keys (CWs) on to the second IC 130 through security chip interface circuit 165 and IC interface 125.
The second IC 130 first decrypts the CWs to generate CWs 'in the clear' within the second IC 130. The second IC 130 will then use the Diffie-Hellman secure key exchange algorithm over interface 125 to communicate the decrypted keys to the first IC 120. The
security CPU 135 in the first IC 120 will execute code stored in ROM 140 to effect the Diffie- Hellman key exchange algorithm. The CWs transmitted to the first IC 120 are preferably stored in the CW keys register 175 for later use in the decryption of A/V content.
The ROM 140 contains the algorithms executed by the security CPU 135 to decrypt the CWs. If Diffie-Hellman key exchange is used to protect the interface 125, then it will be the security CPU 135 that implements the Diffie-Hellman key exchange algorithm. If RSA or PGP are used to protect the data traveling from the second IC 130 to the first IC 120 then the RSA or PGP decryption algorithm will run on the security CPU 135. In order to substantially prevent a hacker from taking control ofthe security CPU 135, the security CPU is only able to execute code from the ROM 140.
In the situation where data is received at the first IC 120 from the HDD 220, the process proceeds as follows. As data is received by the first IC 120, such data is demultiplexed at demultiplexer 180 to separate the Audio/Visual (A/V) data from the entitlement data (e.g., EMMs, ECMs, etc.). The entitlement data is then transmitted to the smart card 200 where it is deciphered to generate keys for decrypting the A/V data. These decryption keys (referenced in Figure 1 as 'smart card encrypted keys'), which are commonly referred to as Copy Protection Control Words (CPCWs), are then re-encrypted and sent to the security CPU 135. The security CPU 135 then passes the encrypted decryption keys
(CPCWs) on to the second IC 130 through security chip interface circuit 165 and IC interface 125.
The second IC 130 first decrypts the CPCWs to generate CPCWs 'in the clear' within the second IC 130. The second IC 130 will then use the Diffie-Hellman secure key exchange algorithm over interface 125 to communicate the decrypted keys to the first IC 120. The security CPU 135 in the first IC 120 will execute code stored in ROM 140 to effect the Diffie- Hellman key exchange algorithm. The CPCWs transmitted to the first IC 120 are preferably stored in the CPCW keys register 170 for later use in the decryption of A/V content.
The ROM 140 contains the algorithms executed by the security CPU 135 to decrypt the CPCWs. If Diffie-Hellman key exchange is used to protect the interface 125, then it will be the security CPU 135 that implements the Diffie-Hellman key exchange algorithm. If RSA
or PGP are used to protect the data traveling from the second IC 130 to the first IC 120 then the RSA or PGP decryption algorithm will run on the security CPU 135. In order to substantially prevent a hacker from taking control ofthe security CPU 135, the security CPU is only able to execute code from the ROM 140.
The ring oscillator 145 and the pseudo-random number generator 150 are two important elements ofthe above-described interface protection system 100. The ring oscillator 145 produces a clock signal with a frequency that is a function ofthe process used when the first IC 120 was manufactured, and the voltage and temperature applied to the first IC when implemented in the interface protection system 100. As is well known in the art, ambient noise on the PCB 110 provides for an initialization of one ofthe inverters ofthe ring oscillator 145. Once one ofthe inverters ofthe ring oscillator has been initialized to a particular level (e.g., 1 Volt) by ambient noise, the succeeding inverter provides and opposing signal (e.g., zero Volts) and so on until a continuous clock signal is generated. The three values which determine the parameters ofthe clock signal ofthe ring oscillator 145 (e.g., process type, voltage and temperature) will be similar as between each IC 120, but are unlikely to be identical. Thus, the ring oscillator 145 provides a level of uniqueness for each IC 120 and PCB 110. Since the pseudo-random number generator 150 generates pseudorandom numbers based on the clock signal ofthe ring oscillator 145, providing a unique clock signal produces a unique generation of pseudo-random numbers.
Preferably, the pseudo-random number generator 150 is not reset to a known value (e.g., 0) during power up or reset. Thus, the count sequence will not always begin at the same point after a power up or reset, and will be more difficult to determine for a hacker. The repeat cycle count (i.e., the time between repeated numbers) ofthe pseudo-random sequence can be made as long as required to ensure a good key value for the protection ofthe interface.
The pseudo-random number generator 150 may be sampled at fixed intervals as measured by the system clock (produced by VCXO 210) of the first IC 120. As the pseudo- random numbers are sampled by the system clock they are placed into the interface protection key register 155. It will be noted that the pseudo-random number produced by the pseudorandom number generator 150 comprises a temporary secret stored in the first IC 120, and is typically not communicated outside the first IC. The generated pseudo-random numbers may
be utilized directly or indirectly by the security CPU 135 to generate a public/private key pair for an asymmetric encryption algorithm (e.g., Pretty Good Privacy (PGP), Rivest Shamir Adelman (RSA), etc.). The public key generated by the security CPU 135 will be sent from the first IC 120 to the second IC 130 over the interface 125. The second IC 130 may then use the public key to encrypt CWs and CPCWs sent back from the second IC to the first IC 120. The private key will be used in the first IC 120 to decrypt the encrypted CWs and CPCWs transmitted from the second IC 130. Since the private key will not be known outside the first IC 120, the interface 125 remains as secure as the encryption algorithm.
Although the above discussion centers on a pseudo-random number generator 145 to create return path unique keys, other equivalent state machines may also be used. For example, a counter could be clocked by the output ofthe ring oscillator and used to generate key values.
Although the invention has been described in terms of exemplary embodiments, it is not limited thereto. Rather, the appended claims should be construed broadly, to include other variants and embodiments ofthe invention which may be made by those skilled in the art without departing from the scope and range of equivalents ofthe invention.