US20200153840A1 - Signaling system switching and key derivation - Google Patents
Signaling system switching and key derivation Download PDFInfo
- Publication number
- US20200153840A1 US20200153840A1 US16/681,465 US201916681465A US2020153840A1 US 20200153840 A1 US20200153840 A1 US 20200153840A1 US 201916681465 A US201916681465 A US 201916681465A US 2020153840 A1 US2020153840 A1 US 2020153840A1
- Authority
- US
- United States
- Prior art keywords
- client
- client device
- group
- message
- client devices
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 230000011664 signaling Effects 0.000 title claims abstract description 83
- 238000009795 derivation Methods 0.000 title description 6
- 238000000034 method Methods 0.000 claims abstract description 69
- 230000009471 action Effects 0.000 claims description 76
- 238000003860 storage Methods 0.000 claims description 17
- 238000012544 monitoring process Methods 0.000 claims 4
- 238000004519 manufacturing process Methods 0.000 description 35
- 230000006870 function Effects 0.000 description 28
- 238000010586 diagram Methods 0.000 description 21
- 238000010200 validation analysis Methods 0.000 description 20
- 238000012545 processing Methods 0.000 description 18
- 230000008569 process Effects 0.000 description 17
- 238000004590 computer program Methods 0.000 description 16
- 230000004913 activation Effects 0.000 description 13
- 230000008859 change Effects 0.000 description 11
- 238000013461 design Methods 0.000 description 10
- 238000009826 distribution Methods 0.000 description 10
- 238000012795 verification Methods 0.000 description 9
- 230000005540 biological transmission Effects 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 238000004364 calculation method Methods 0.000 description 5
- 101100011375 Caenorhabditis elegans egl-4 gene Proteins 0.000 description 4
- 238000013478 data encryption standard Methods 0.000 description 4
- 235000000332 black box Nutrition 0.000 description 3
- 244000085682 black box Species 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000001010 compromised effect Effects 0.000 description 3
- 238000003780 insertion Methods 0.000 description 3
- 230000037431 insertion Effects 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 101150037468 CPD1 gene Proteins 0.000 description 2
- 241000282414 Homo sapiens Species 0.000 description 2
- 101100108853 Mus musculus Anp32e gene Proteins 0.000 description 2
- 101100221809 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) cpd-7 gene Proteins 0.000 description 2
- 101100165815 Oryza sativa subsp. japonica CYP90A3 gene Proteins 0.000 description 2
- 101100490727 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) AIF1 gene Proteins 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 101150025236 dmaW gene Proteins 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000004806 packaging method and process Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 102100030310 5,6-dihydroxyindole-2-carboxylic acid oxidase Human genes 0.000 description 1
- 241000282412 Homo Species 0.000 description 1
- 101000773083 Homo sapiens 5,6-dihydroxyindole-2-carboxylic acid oxidase Proteins 0.000 description 1
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 1
- 101000898746 Streptomyces clavuligerus Clavaminate synthase 1 Proteins 0.000 description 1
- 101000761220 Streptomyces clavuligerus Clavaminate synthase 2 Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000003416 augmentation Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 238000000254 composite pulse decoupling sequence Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 239000012530 fluid Substances 0.000 description 1
- 230000008571 general function Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 238000012958 reprocessing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000007727 signaling mechanism Effects 0.000 description 1
- 229910052710 silicon Inorganic materials 0.000 description 1
- 239000010703 silicon Substances 0.000 description 1
- 238000004513 sizing Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/104—Grouping of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
- H04N21/23895—Multiplex stream processing, e.g. multiplex stream encrypting involving multiplex stream encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
- H04N21/4385—Multiplex stream processing, e.g. multiplex stream decrypting
- H04N21/43853—Multiplex stream processing, e.g. multiplex stream decrypting involving multiplex stream decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4623—Processing of entitlement messages, e.g. ECM [Entitlement Control Message] or EMM [Entitlement Management Message]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4627—Rights management associated to the content
Definitions
- the present invention relates to systems and methods for securely providing media programs and other information to subscribers via a black box Security Provider Programming system, and in particular to a system and method for securely providing data for use by a hardware device of a receiver for conditional access.
- provision of information such as media programs to remote consumers is well known in the art. Such provision may be accomplished via terrestrial or satellite broadcast, cable, closed circuit, or Internet transmission to consumer electronics (CE) devices at the consumer's home or office.
- CE consumer electronics
- a common problem associated with such transmission is assuring that the reception of such information is limited to authorized end-users.
- This problem can be solved via the use of encryption and decryption operations performed by devices with appropriate security functionality. For example, it is well known to encrypt media programs before transmission to CE devices with electronics and processing that permits the encrypted media programs to be decrypted and presented to only authorized users.
- the CE products typically include keys, software, and other data. Since such data is of value to unauthorized users as well, CE companies need a way to protect this valuable information.
- CE devices with special integrated circuits (or chips) with security features enabled and information needed to perform the security functions loaded into chip memory.
- chips can include System on Chips (SOC), which comprise the primary Central Processing Unit (CPU) of the CE device (which may also include secondary processors, security processors, custom Application Specific Integrated Circuits (ASICSs), etc.) or other chip devices that perform the processing of commands within a CE device.
- SOC System on Chips
- CPU Central Processing Unit
- ASICSs custom Application Specific Integrated Circuits
- Conditional Access providers provide content protection schemes to secure broadcast content is paid for when viewed by subscribers. Problems arise when the content protect schemes are either compromised or implemented in a man which security holes or flaws can be exploited by attacker. The cost to design, manufacturer and distribute these CE devices is extremely expensive.
- CA conditional access
- the CE device can be provisioned to support separate and cryptographically isolate CA systems during manufacture. This permits the security provided by another CA vendor 108 B to be used in the event the security provided by another one of the CA vendors 108 B and co-existing on the chip 114 , is compromised.
- What is needed is a system and method for providing a security infrastructure that permits the programming of unique security functions in standardized chip designs and enables switching among different and existing CA systems deployed in CE devices.
- the present invention satisfies that need.
- the present invention discloses a method of controlling a group of the client devices to switch at least one client device of the group of client devices from a first conditional access system to a second conditional access system via a plurality of client device signaling messages, each comprising at least one of a plurality of action codes and payload data.
- the method which can be applied to a system of a plurality of client devices for receiving media programs from a service providers, comprises generating a group identifier identifying the group of the client devices, transmitting a first client device signaling message having the group identifier only to each client device of the identified group of client devices, the group identifier for storage in each client device of the identified group of client devices in non-volatile memory, and transmitting a second client device signaling message to plurality of client devices, the second client device message comprising the group identifier and signaling a switch of each of the identified group of client devices from the first conditional access system to the second conditional access system.
- service provider 102 or broadcaster to utilize high security chip device features to enable in-field switching of CA vendors and/or co-existence of CA vendors for fielded CE Devices.
- This is possible in part, due to a set of base security features that can be integrated into commercially available integrated circuitry for use in CE products, yet customizable for many different applications.
- Use of black box programmed secure silicon features enables service providers or broadcasters to switch CA vendors or for different CA systems from multiple vendors to co-exist in CE devices by cryptographically isolating key sets allocated to and used by independent CA vendors.
- Chip device programming can also occur at the packaging or product manufacturing facility by execution of an in-field programming sequence on the chip device.
- a method for unlocking a hardware device comprises the steps of transmitting a product provisioning key (PPK) encrypted according to a secret value (SV) (E SV [PPK]) from a first entity to a second entity for secure storage in a hardware device; receiving a customer validation code (CVC) from the second entity, the (CVC) computed in the hardware device from the encrypted product provisioning key E SV [PPK]; receiving an unlock request comprising the customer validation code (CVC) and a hardware unique identifier (PID) in the first entity from the second entity; computing an expected customer validation code (CVC) in the first entity from the secret value (SV) and the product provisioning key (PPK); and transmitting data unlocking the hardware device if the expected customer validation code (CVC) computed by the first entity matches the received customer validation code from the second entity.
- SV secret value
- PID hardware unique identifier
- FIG. 1A is a diagram of selected architectural entities described in this disclosure.
- FIG. 1B is a diagram of an exemplary chip
- FIG. 2 illustrates the customer product differentiator field and signed hash block used to verify third party customer input data for fielded SOCs
- FIG. 3 illustrates the Boot ROM signature check over the code section enabling insertion of a CA vendor Public RSA key in a fielded SOC
- FIG. 4A illustrates use of a Secret Value stored in hardware to protect a given CA vendor customer's common block of data or key
- FIG. 4B illustrates use of a Secret Value and Product Provisioning Key both stored in hardware to protect a CA vendor's common block of data or key;
- FIG. 5A is a diagram presenting illustrative method steps that can be used to enable encryption of sensitive code or data and provide it to an independent CA vendors or untrusted consumer electronics (CE) device manufacturer for provisioning;
- CE consumer electronics
- FIG. 5B is a diagram illustrating use of a product provisioning key and secret value stored in hardware to protect a CA vendors' common block of data or key enabling in-field insertion of a secret value post SOC manufacturing;
- FIG. 6 is a diagram of one embodiment of the product identifier (PID) described above;
- FIG. 7 illustrates the boot process, image signing and RSA public key authentication for over the air updates
- FIG. 8A is a diagram illustrating exemplary method steps that can be used to deliver the unlocking data
- FIG. 8B illustrates a more specific example of the calculation and distribution of customer validation data by the CE source 108 after the chip 114 is manufactured
- FIG. 9 is a diagram illustrating exemplary method steps for controlling a group of client devices to switch from a first CAS to a second CAS via a plurality of client device signaling messages;
- FIG. 10 is a diagram illustrating exemplary operations performed by the client devices in receiving and handling the first client device message and the second client device message;
- FIGS. 11-12 illustrate the operations presented in FIGS. 9-10 in greater detail.
- FIG. 13 illustrates an exemplary computer system that could be used to implement the present invention.
- This disclosure describes a system and method that allows third parties to provide set top boxes with advanced security features that (1) allow the signing of a customer's public key, (2) allow programming of chips with secret keys at chip manufacturing facility and (3) provide service providers a method to independently allocate those secret keys to security vendors when the CE device is in the field.
- FIG. 1A is a diagram of selected architectural entities described in this disclosure. They include a service provider 102 , a chip manufacturer 104 , a security provider 106 , a third party vendor(s) 108 and subscriber(s) 110 .
- the service provider 102 transmits media programs and information to consumer electronics (CE) device(s) 112 that are deployed to subscribers 110 .
- the CE device 112 presents the media programs to the subscribers 110 .
- the CE device 112 can include devices such as set-top boxes (STBs) integrated receiver/decoders (IRDs) portable CE devices such as cellphones or personal data assistants (PDAs), laptop computers, tablet computers, and desktop computers. Any device with the required processing and memory capacity having the proper programming or hardware can be used as a CE device.
- An exemplary IRD is disclosed in U.S. Pat. No. 6,701,528, which is hereby incorporated by reference herein.
- the CE devices 112 perform security functions that are implemented at least in part using hardware processing/memory devices 114 (hereinafter alternatively referred to as chips) that are produced by chip manufacturer 104 .
- chips hardware processing/memory devices 114
- the transport module of the IRD disclosed in U.S. Pat. No. 6,701,528, is typically implemented by a chip.
- FIG. 1B is a diagram of an exemplary chip 114 .
- the chip 114 comprises memory 152 communicatively coupled to a processor or CPU 150 .
- the memory 152 stores instructions and/or data such as keys that are used to implement the conditional access functionality of the CE device 112 .
- the memory 152 may include read only memory (ROM) 152 A, one-time-programmable memory (OTP) 152 B, and flash memory 152 C.
- the chip 114 may also comprise a configuration portion 154 , which may include a series of fuses 156 A- 156 C and/or flags 158 A- 156 B.
- the flags 158 may also be reflected by values in the memory 152 .
- the fuses 156 are irreversibly activated by the chip manufacturer 104 to implement particular chip 114 functionality. For example, activation of fuse 156 A may activate a triple data encryption standard (DES) functional capability of the chip 114 , while fuse 156 B may activate an RSA encryption functionality.
- DES triple data encryption standard
- the CE devices 112 are manufactured by a CE source 108 .
- the CE source 108 is defined to include a particular CE manufacturer 108 A that is responsible for the manufacture of a CE device 112 having hardware and software capable of implementing the CA functions allocated to the CE device 112 by a particular CA vendor 108 B, which provides the instructions and data (for example, software and keys) that are used by the CE device 112 hardware to implement the CA functions required for the CA system used by the service provider 102 .
- a particular CE source 108 is identified by a particular CE manufacturer's 108 A product used with a particular CA system from CA vendor 108 B used with the CE device 112 .
- CA vendor 108 B used with the CE device 112 .
- the CE device 112 hardware is capable of performing the CA functions allocated to the CE device 112 for multiple CA vendors 108 B at the same time.
- a first CA vendor 108 B 1 (CA vendor 1) may define a CA system that allocates a first set of CA functions to the CE device 112
- a second CA vendor 108 B 2 (CA vendor 2) may define a second CA system that allocates a second set of CA functions at least partially different than the first set of functions to the CE device 112 .
- the CE device 112 may support both CA systems by storing instructions and data that allow the CE device hardware to perform the CA functions allocated to the CE device 112 in both the first CA system and the second CA system.
- the fielded CE device 112 may be capable of performing the CA functions needed to receive and decrypt media programs and data transmitted by two different service providers 102 (for example, DIRECTV AND ECHOSTAR).
- the CE device 112 hardware may also support the replacement or substitution of one set of allocated CA functions for another set of allocated functions.
- the CE device 112 hardware may be configured such that a first set of allocated CA functions is automatically disabled when the second set of allocated CA functions are enabled. This would allow, for example, a receiver initially configured to receive media programs from a first service provider 102 to be de-configured from receiving such programs, and to instead receive media programs from a second service provider 102 .
- the first service provider 102 could desire a change its content protection services from its initial CA vendor 108 B 1 to those provided by a second CA vendor 108 B 2 .
- the CE device source 108 may also include one or more CA vendors 108 B that are architectural entities separate from the CE manufacturer 108 A.
- the CE device 112 may employ a smart card 114 ′ (for example, as shown by the access card of FIG. 2 of U.S. Pat. No. 6,701,528) or other removable security device having security functions defined by the CA vendor 108 B.
- the CA vendor 108 B may manufacture and provide this security device 114 ′ to the CE manufacturer 108 A for ultimate provision to the subscriber(s) 110 with the CE device 112 .
- the CE source 108 may accept chips 114 from the chip manufacturer 104 and install them into the CE device 112 .
- the present invention allows the chips 114 to be a standard design, yet uniquely and remotely programmable so as to be useful for CE devices 112 from different CE manufacturers 108 A, and that can perform the allocated CA functionality for multiple CA systems enabled by different CA vendors 108 B and used by different service providers 102 .
- the chips 114 are programmed via use of a black box 116 provided by a third party security provider 106 .
- the black box 116 is a device that performs a transformation of data such as code or keys, without revealing how the transformation is performed or disclosing the data.
- the use of the black box 116 in this instance, allows the security provider 106 to program instructions and/or data into the chip 114 at the chip manufacturer's facility and under the control of the chip manufacturer 104 without exposing that information and/or data itself to the chip manufacturer 104 .
- Data from the security provider 106 or the service provider 102 may also be programmed into the chip 114 at the CE source 108 or the subscriber 110 location using the techniques described below.
- a customer product differentiator is used by the security provider 106 and/or the chip manufacturer 104 to identify a customer specific configuration of a specific chip 114 for the functions to be performed by the CE Device 112 from a particular CE Source 108 .
- the customer product differentiator (CPD 202 ) may be assigned to a particular CE Source 108 or service provider 102 , for example, PANASONIC, DIRECTV or ECHOSTAR. Further, a single service provider 102 or CE source 108 may have different CPDs for products that are used in different markets if those products require chips that implement different security functions.
- the customer product differentiator comprises a bit customer product differentiator (CPD 202 ) represented by a 32 bit field.
- FIG. 2 is a diagram illustrating the use of the CPD 202 .
- a customer product differentiator or CPD field 202 is generated and used with a signed hash block 210 to verify CE source 108 input data before that data is used in fielded chips 114 (i.e. deployed in fielded CE devices 112 installed at subscriber 110 locations).
- the security provider 106 uses the CPD 202 field as part of an input to fix chip 114 security data received from the CE source 108 (such as a specific flash-based CE source 108 public RSA key) to a given value.
- the address location for a flash-based third-party public RSA key and/or the CPD 202 can also be used fix input data for a given CE source 108 and incorporated into the signed hash block 210 .
- This process can be implemented as follows.
- the public RSA key of the security provider 106 is stored in ROM 152 A at the mask level or OTP 152 B using the black box 116 .
- Customer-specific data 208 is generated by combining the CPD 202 with a public key 201 of the CE source 108 and optional chip configuration information, as shown in block 206 .
- Chip configuration information may vary according to the CA functions to be implemented by the chip 114 in the CE device 112 .
- a particular chip 114 may have the ability to implement a plurality of encryption/decryption schemes, depending on the setting of internal flags of the activation of internal fuses 156 .
- the chip 114 configuration information may describe the enabled functionality of the chip 114 by indicating, for example, which flags are set and/or which fuses 156 are activated.
- the above combination operation 206 is performed by the security provider 106 .
- the CPD field 202 is assigned by the security provider 106 and the combining operation of block 206 is a hash operation.
- the result is CE source 108 data 208 that is unique and specific to that CE source 108 and customer product. This data may be stored in a map which controls the activation of fuses 156 .
- the customer-specific data 208 generated above is signed with a private key of the security provider 106 Kpr SP .
- this signed combination and the customer product differentiator or CPD 202 is provided to the CE source 108 .
- the CE source 108 writes the signed customer data 208 and the customer product differentiator or CPD 202 to a memory 152 of the chip 114 .
- the customer data 208 signed with the security provider's 106 private RSA key is also securely stored at the CE source 108 site for use in the generation of future customer operations.
- the CE source 108 writes their CE source public key (Kpu CE ) into a memory 152 of the chip 114 and also writes an image of the CE device 112 boot code signed by the private key of the CE source 108 into memory 152 c of the chip 114 .
- Boot code comprises coded instructions that are verified and executed automatically when a CE device 112 is powered up.
- the chip 114 is thereafter installed into the customer device 112 by the CE manufacturer 108 A, and provided to the subscriber 110 for use.
- a boot code 314 is verified, then executed by the chip 114 , as further described with reference to FIG. 3 .
- the security provider 106 generates the signed hash block 208 over the customer-specific data using the chip 114 configuration (provided in block 201 ), the CE source's public RSA key, and the CPD field 202 .
- the CE source 108 can store the signed hash CPD field 202 in one time programmable (OTP) memory 152 B location of the chip 114 as shown in block 214 , however, the CPD 202 could reside in flash memory for example in cases where there is not enough OTP or the chip 114 does not support OTP.
- OTP time programmable
- CE source 108 or other entity were to alter the CPD field 202 or the CE source's public RSA key, then the RSA signature validation described below and illustrated in blocks 310 and 312 using the security provider's 106 signed hash block 308 would fail and the chip 114 will not completely execute the boot code instructions, and will chip 114 and CE device 112 will be otherwise unusable. This is further described below.
- the security provider's public RSA key is embedded in Read Only Memory (ROM) 152 A or One Time Programmable memory (OTP) 152 B within the chip 114 as described below with reference to FIG. 3 . This serves as the hardware root of trust in the chip 114 .
- ROM Read Only Memory
- OTP One Time Programmable memory
- the security provider 106 supplies a 2048 bit RSA public key that is stored in a ROM 152 A of the chip 114 or an OTP bank 152 B within the chip 114 , as shown in block 200 .
- ECC Elliptical Curve Cryptography
- the chip 114 may also include boot code that is used upon power up to boot or start the chip 114 .
- this boot code is signed by the CE source's private key, before storage in the chip 114 so as to permit later validation before further processing as described below.
- FIG. 3 is a diagram presenting an exemplary embodiment of how the boot code image can be verified before it is executed by the chip 114 .
- a boot sequence is initiated by the chip 114 , as shown in blocks 302 and 304 .
- the public key of the second entity in this case, the CE source 108 .
- the signed hash (which was generated with the CE source's public RSA key and the CPD) was stored in block 214 and the CE Source's public key was stored in the chip 114 in block 216 . That hash can be recomputed in the chip 114 using the CPD 202 that was stored in the chip 114 in block 214 , the CE Source public RSA key stored in the chip in block 216 , and the chip configuration data. Further, the signature over the hash, i.e. the signed hash, stored in block 214 can be verified using the security provider's 106 public key which is retrieved from the ROM 152 A or OTP 152 B of the chip 114 . The hash will only be equivalent to the recomputed hash if the CE source's public RSA key written in block 216 is equivalent to the CE source's public RSA key used to generate the hash in block 206 are equivalent.
- boot code image is verified as shown in blocks 314 - 318 and the boot code is executed. If the boot sequence is not verified, chip 114 will again fail to exit the reset mode and will be non-operational.
- a hardware security co-processor built into the chip 114 can read the CE source's public RSA key (which was stored in block 216 ) from memory such as a flash location in the chip 114 and use it to verify the stored signature for the customer application code that has been calculated over the entire section of customer application code to be downloaded for execution.
- the chip 114 memory location from which the security provider's 106 public RSA key is read may be fuse 156 locked to a specific ROM 152 A or OTP 152 B key by the chip manufacturer 104 , that is, at electronic wafer sort or when sensitive immutable data is stored in the chip 114 by the black box 116 provided to the chip manufacturer 104 by the security provider 106 .
- This security provider 106 public RSA key is used as the chip's hardware root of trust in code signing, thereby, enabling use of at CE source 108 or CA vendor 108 B public RSA key.
- the main processor or central processing unit (CPU) 150 of the chip 114 incorporated into the CE device 112 may be held in a reset mode until the boot code check of blocks 314 - 318 is completed, thereby, eliminating the possibility of executing unknown user or malicious boot code.
- the chip 114 must support the ability to extend the public ROM/OTP keys held by the security provider 106 to CE source 108 —defined RSA keys by checking a signed hash stored in the chip 114 .
- This enables a first entity, such as the security provider 106 , to sign the public RSA keys of the second entity (such as the CE source 108 —defined public RSA keys) and allows validation of the CE source's 108 public RSA key based on the security of the root of trust in the security provider's public RSA key stored in ROM/OTP 152 A/ 152 B.
- this hardware-based validation process occurs in a secure manner that is not modifiable or accessible by other elements in the CE device 112 such as a general-purpose processor 904 A or general purpose processor 904 B.
- This process is typically controlled by a hardware state machine or performed on a separate embedded security co-processor executing from a private secure memory location.
- the signed hash 210 used to validate the CE source's public RSA key incorporate the CPD 202 field assigned by the first entity (the security provider 106 ) to properly bind the CE Source's public RSA key to a specific party, that is, the CE Source 108 to which the CPD 202 was assigned. Incorporating additional information such as the address of the memory 152 location of where the CPD 202 value and/or CE source's public RSA are stored further limits potential attacks by fixing values to particular areas in a map of the memory 152 of the chip 114 .
- Having either the CPD field 202 or CPD address field incorporated into the signed hash 210 also enables the CE source 108 to assign an alternate CPD field 202 and/or CPD address, either of which enables switching from a first CA vendor 108 B 1 to a second CA vendor 108 B 2 as discussed below.
- the previous CE source public RSA key could be used once again if the security provider 106 provides another signed hash 210 using the old CE source public RSA key, an old CPD value 202 with a newi CPD address because the new address could used to store the previously old CPD value.
- the generation of the signed hash 210 is typically accomplished using the security providers' private RSA key and the chip manufacturer's supplied tool chain at the security provider's 106 trusted facility.
- the security provider 106 may generate the signed hash 210 through use of publicly available tools such as OpenSSL or custom tools developed by the security provider 106 .
- the signed hash 210 validation in the chip 114 occurs using the security provider's public RSA key stored in the ROM/OTP of the chip 114 .
- a broadcaster or service provider 102 may decide to enable the CA functionality of multiple CA systems provided by multiple distinct CA vendors 108 B (e.g. CA vendor 108 B 1 and CA vendor 108 B 2 ) to be implemented in a single CE device 112 .
- the broadcaster or service provider 102 may assign a single CPD 202 and CE Source public RSA key 201 to verify a CE device 112 boot image that combines the security functionality of both CA vendors 108 B 1 and 108 B 2 .
- the boot code may combine and integrate two distinct portions, a first portion for the first CA vendor 108 B 1 , and a second portion for the second CA vendor 108 B 2 .
- a common CE source public RSA key 201 can be used to verify the combined boot code portion containing the boot sequence for both CA vendors 108 B 1 and 108 B 2 . In future chip 114 designs that can do so, a separate CA vendor public RSA key 201 can be used for each boot code portion.
- the signed hash 210 may be incorporated in the boot flash image 152 C by the CE source 108 as shown in 316 using tools provided by the chip manufacturer 104 once the CE Source 108 has finalized it own boot code.
- the signed hash 210 is validated in the chip 114 each time the chip 114 is powered up and before the chip 114 exits the reset mode.
- the precise boot process may be chip 114 —specific as defined by the chip manufacturer 104 .
- the chip 114 may support several security provider RSA public keys, however, the number of production ROM locations available in the chip 114 is typically limited due to physical storage sizing and timing for the availability of the data (i.e. the security provider's public RSA key placed in ROM must be available at the time of the initial chip design).
- one of the unique features of the present invention is the ability for a standard chip 114 to be used with a multiplicity of different CE sources 108 , service providers 120 and/or CA vendors 108 B, with the security features customized for each CE source 108 and/or application.
- CE sources 108 are typically not known during the development phase of the chip 114 , the security data of every CE source 108 cannot be incorporated into the more secure production ROM during the development stage.
- the techniques discussed below extend the public RSA key of the security provider 106 as the hardware root of trust to multiple CE sources 108 , service providers 102 and/or CA vendors 108 B to enable in-field switching and or augmentation of CA functions implemented in the chip 114 and without the use of a black box 116 .
- this programming system takes a generically manufactured chip 114 and binds a specific flash memory-based CE source 108 —provided public RSA key 201 to a particular customer such as the CE Source 108 or service provider 102 utilizing the security provider's ROM/OTP-based public RSA key 200 as the hardware root of trust.
- a secret value (SV) 451 programmed by the security provider 106 can be stored in the chip 114 OTP memory 152 B, and that SV 451 can be used to indirectly modify or manipulate sensitive data that is externally supplied to the chip 114 .
- sensitive data can be supplied from the service provider 102 via a broadcast, a third party CA vendor 108 B, a USB port, Internet server, DVD or similar means.
- FIG. 4A and FIG. 4B are diagrams illustrating how data (D) can be securely received from one or more CA vendors 108 B and can be provided for use by the chip 114 in a CE device 112 .
- the data is protected from access by unauthorized CA vendors 108 B and potential attackers.
- Such data (D) may be a key for decrypting media programs transmitted by the service provider 102 using the CE device 112 , a common code block of data 408 including instructions for execution by the CE device 112 , or similar data.
- a customer global key (CGK) 402 is generated or assigned by a first entity such as the security provider 106 and transmitted to a second entity such as the CE source 108 or a first CA vendor 108 B 1 .
- the data (D) 408 of interest is encrypted according to the customer global key 402 provided by the security provider 106 to produce encrypted data E CGK [D] as shown in block 410 .
- this encryption may be performed, for example, by the second entity or CE source 108 or CA vendor 108 B.
- the security provider 106 may select the CGK uniquely for each CE source 108 or CA vendor 108 B.
- CA Source 108 A/CA Vendor 108 B Since the CGK is unique to each CA Source 108 A/CA Vendor 108 B, sensitive intellectual property such as code or data can cryptographically isolated and protected from successive CA vendors 108 B in case switching of CA systems or vendors is desired. Such CA systems from CA vendors 108 B can concurrently be implemented in the CE device 112 .
- the customer global key (CGK) 402 is also encrypted according to a secret value (SV) key by the security provider 106 (or CE source 108 ) to produce an encrypted customer global key E SV [CGK] 406 .
- each chip 114 has a unique SV key 451 , and the security provider 106 or CE source 108 encrypts the CGK uniquely for each chip 114 using that chip's unique SV key 451 .
- the encrypted customer global key E SV [CGK] 406 and the encrypted data E CGK [Data] 412 are then transmitted or distributed to the CE device 112 and the chip 114 , where it is received and processed, as shown in blocks 414 and 416 .
- Transmission can be by physical transfer of a storage medium or using wired or wireless data transmission.
- the encrypted customer global key E SV [CGK] 406 is then decrypted according to the SV key 451 stored in the chip 114 to reproduce the customer global key 403 and the encrypted data E CGK [Data] is decrypted with the reproduced customer global key CGK to reproduce the data (D), as shown in blocks 418 and 420 .
- Either or both of these operations can be performed by a third entity (for example, the user's fielded CE device 112 using the chip 114 ).
- these decryption operations are hardware controlled and not accessible or modifiable by the CE device 112 . It is important to note that the CGK is not shared between potential CA vendors 108 B and that this cryptographic isolation is maintained in the chip 114 by encrypting the CGK with the SV key that is unique to each chip 114 .
- the CGK may again be decrypted using the SV key within the key ladder (a secure processing engine that handles security keys in the chip 114 without exposing such secrets to the main CPU or exporting key material for access by software) with the results of this decryption unavailable to the software of the main CPU, thereby supporting both CA switching and CA co-existence in the CE device 112 .
- the decrypted CGK 402 is used to decrypt the E CGK [Data] 412 , resulting in the Data 408 , which is used by the chip 114 to perform security related functions such as decrypting the media program.
- the decrypted Data 408 can also be a key used to further decrypt the broadcast content or a common block of code/data, as shown in block 422 . If the operations of blocks 418 or 420 fail, processing stops, as shown in FIG. 4A . The foregoing operations can be used to transmit data from a second CA Vendor 108 B 2 as well.
- FIG. 4B shows another embodiment of how to securely distribute data from the service provider 102 or CA vendor 108 B.
- the CGK 402 remains unique to each CA vendor 108 B and cryptographic isolation is maintained in the chip 114 by use of a product provisioning key (PPK) 453 that is not shared with any other CA vendor 108 B or third party.
- PPK product provisioning key
- the CGK 402 is decrypted with the PPK 453 within the chip's 114 secure key processing engine that handles content protection keys, the key ladder, whose results are not available to software of the main processor of the chip 114 , thereby supporting switching between CA systems (which may be supplied by different CA vendors 108 B) co-existing in the CE device 112 . Support for CA switching and CA co-existence is discussed in detail in the sections below.
- the security provider 106 generates a secret value (SV) 451 that is unique to each chip 114 and a product provisioning key (PPK) 453 that is unique to a particular chip 114 design or model, but not unique to a particular chip 114 .
- the PPK 453 could be changed for a given number of chips 114 programmed by the black box 116 or manufactured for a specific period of time.
- the SV 451 is programmed into the chip, as shown. Further, the PPK 453 encrypted by the SV 451 is also generated and programmed into the chip 114 .
- These programming operations are performed by the chip manufacturer 104 using the black box 116 provided to the chip manufacturer 104 by the security provider 106 . New keys are periodically loaded into the black box 116 which resides at the chip manufacturer 104 by encrypted DVDs or USB drive images created by the security provider 106 at their secure facility.
- a customer global key (CGK) 402 is generated by a first entity such as the security provider 106 and transmitted to a second entity such as the CE source 108 or CA vendor 108 B.
- the data (D) 408 is encrypted according to the customer global key 402 to produce encrypted data E CGK [D] as shown in block 460 .
- the encryption of the data (D) may be performed, for example, by the second entity such as the CE source 108 or CA vendor 108 B.
- the customer global key (CGK) 402 assigned by the security provider 106 is also encrypted according to a product provisioning key (PPK) 453 by the security provider 106 , as shown in block 457 to produce an encrypted customer global key E PPK [CGK] 459 .
- PPK product provisioning key
- the security provider 106 selects the CGK 402 uniquely for each CE source 108 /CA vendor 108 B combination, thus enabling the security provider 106 to support many third party CA Vendors 108 B and/or CE Sources 108 using chips 114 from multiple chip manufacturers 104 while cryptographically isolating the CGK 402 intended for use by one CA Vendor 108 B 1 from that used by another CA Vendor 108 B 2 and potential attackers by use of the PPK 453 .
- the encrypted customer global key E PPK [CGK] 459 and the encrypted data E CGK [Data] 462 are then transmitted or distributed to the CE device 112 and hence, the chip 114 , where it is received and processed, as shown in blocks 464 and 465 .
- This can be accomplished by physical transmission of media storing the encrypted customer global key E PPK [CGK] 459 and the encrypted data E CGK [Data] 462 or by electronic transmission of the data, by wireless or wired means since the sensitive data is encrypted.
- the security provider 106 may transmit the encrypted customer global key E PPK [CGK] 459 to the CE source 108
- the CE source 108 may transmit both the encrypted customer global key E PPK [CGK] 459 and the encrypted data E CGK [Data] 462 to the CE device 112 .
- the encrypted PPK 453 is recovered by decrypting E SV [PPK] that was programmed into the chip 114 using the SV programmed into the chip. This is shown in block 467 .
- the encrypted customer global key E PPK [CGK] 459 is decrypted according to the recovered PPK 453 to reproduce the customer global key CGK 402 as shown in block 469 and the encrypted data E CGK [Data] is decrypted with the reproduced customer global key CGK 402 to reproduce the data 408 , as shown in blocks 470 and 472 .
- Either or both of these operations can be performed by a third entity (for example, the user's fielded CE device 112 using the chip 114 ).
- these decryption operations are hardware controlled and not accessible or modifiable by the chip's main processor or any other processor associated with the CE device 112 .
- the decrypted data 408 is typically data that is used by the chip 114 to perform security related functions.
- the decrypted data 408 can include a key used to decrypt the broadcast content or can be a common block of code/data for performing security related functions.
- the data may also comprise a media program decryption key also known as the control word (CW) and/or a pairing key (PK) that cryptographically binds the CE device 112 with an external device such as a smart card.
- CW control word
- PK pairing key
- FIG. 5A is a diagram presenting illustrative method steps that can be used for the encryption of sensitive code or data to enable cryptographic separation of code and data for different CA vendors 108 B and CA co-existence.
- the encrypted block can be provided to an untrusted consumer electronics (CE) device manufacturer 108 A for provisioning.
- CE consumer electronics
- the hardware device such as a chip 114 is received from a first entity such as the security provider 106 , wherein the hardware device has a securely stored SV key 451 and a product provisioning key (PPK) 453 encrypted by the SV key (E SV [PPK]), as shown in block 502 .
- a CGK 402 and the CGK encrypted according to the PPK 453 (E PPK [CGK] 459 ) is received from the first entity, as shown in block 506 .
- the Data is 408 encrypted according to the customer global key to produce encrypted data (E CGK [Data] 462 ), and the encrypted data E CGK [Data] 462 and hardware device are transmitted to a third party, as shown in blocks 508 and 510 .
- the SV key and the encrypted product provisioning key E SV [PPK] 455 are securely stored in the hardware device 114 via a black box 116 the first entity.
- the encrypted data E CGK [D] 462 , the encrypted customer global key E PPK [CGK] 459 , and the hardware device 114 are received by the third party such as a CE Source or CA vendor 108 B, as shown in block 512 , and installed into the CE device 112 .
- the encrypted product provisioning key E SV [PPK] 455 is then decrypted according to the SV key 451 stored in the chip 114 , as shown in block 514 .
- the encrypted customer global key E PPK [CGK] 459 is then decrypted according to the decrypted PPK 453 to produce the customer global key CGK 402 , as shown in block 516 .
- the encrypted data E CGK [Data] 462 is decrypted according to the customer global key, as shown in block 520 . The data is then available for use.
- FIG. 5B is a diagram showing a specific example of the operations presented in FIG. 5A .
- the security provider 106 defines a PPK 453 and a SV 451 , and programs the PPK 453 encrypted by the SV key 451 into the chip 114 , as shown in blocks 552 - 554 . This is accomplished via the security provider's black box 114 disposed at the chip manufacturer 114 .
- the PPK 453 is held secret and not exported to software in the CE device 112 , which would leave it vulnerable to unauthorized attack.
- the security provider 106 then provides each CE source 108 (i.e. CE manufacturer 108 A/CA vendor 108 B combination) with a different customer global key, CGK 402 (in one embodiment, a 128 bit value) and the CGK 402 encrypted with the PPK 453 , referred to as the E PPK [CGK], as shown in block 556 .
- CE source 108 i.e. CE manufacturer 108 A/CA vendor 108 B combination
- CGK 402 in one embodiment, a 128 bit value
- E PPK [CGK] the E PPK
- the CE source 108 encrypts their sensitive code/data (D) 408 with the CGK 402 , as shown in block 558 , and provides the encrypted code/data to the CE manufacturer 108 A during CE device manufacturing for the initial load, as shown in block 560 .
- the chip 114 decrypts E SV [PPK] to obtain the PPK, and decrypts the E PPK [CGK] using the obtained PPK 453 to produce the CGK 402 , which is thereafter usable by the third party software application such as CE device 112 or a Set Top Box (STB) User Interface (UI) code executing in the chip 114 , as shown in blocks 562 - 566 .
- the CGK 402 allows the CGK 402 to be unique to each CE Source 108 (CE manufacturer 108 A/CA Vendor 108 B) combination without revealing the PPK external to the security provider 106 and assures that the CGK 402 is known only to the CE Source 108 combination it is assigned to and no other party, excepting the security provider 106 , which assigned the CGK 402 .
- This enables the PPK 453 , CGK 402 , and SV 451 from distinct CA vendors 108 B to be used independently without exposing these keys or other data to other CA vendors 108 B or third parties.
- different key sets E PPK [CGK] 459 and CGK 402 ) can be allocated to each CA vendor 108 B. This permits a plurality of CA vendors 108 B to implement CA functionality on a single chip 114 .
- the CA vendor-specific CGK 402 , the protected code/data segment 408 and the global PPK 453 are not exposed outside the hardware controlled key ladder of the chip 114 , which is the secure key processing engine that handles content protection keys.
- the PPK 453 is held secret by the security provider 106 and not given to the chip manufacturer 104 or any third party and the CGK 402 is never given a third party outside the CE source 108 or CA vendor 108 B.
- the security provider's programming is tied to a particular chip 114 identified by a public value referred to as a Product Identifier (PID) 600 .
- the chip 114 is uniquely programmed and provisioned by the security provider's black box 116 and tracked by the chip manufacturing process.
- the programming methodology taught in this disclosure enables the placement of secondary provisioning/activation server at third party CE product manufacturing facilities 108 A to track actual CE devices 112 produced and tested as opposed to chips 114 manufactured by the SOC chip manufacturer 104 .
- This secondary provisioning/activation server can be located in the CE Source Operations of FIGS. 4A and 4B .
- the programming methodology taught in this disclosure can automate reporting (at chip 114 fabrication and CE device 112 manufacturing) and less is hands-on for authorized third parties to track production of CE devices 112 for accounting purposes such as determining royalty payments for software licensing. This solves a major problem for CE manufacturers 108 A who may not be receiving accurate reports from suppliers or distributors for royalty payment purposes for licensed software or hardware that the CE manufacturer 108 A is due.
- Hardware based storage which cannot be modified by a third party customer or an attacker, can be used for the security provider's Public RSA or security provider's ECC key, CPD field 202 , first secret value (SV) 451 , one or more additional secret values (SV2, SV3, SV4, etc.), product identifier (PID) 600 , JTAG unlock and E SV [PPK] 455 (the PPK encrypted with the SV).
- PID Product Identifier
- FIG. 6 is a diagram of one embodiment of the product identifier (PID) 114 described above.
- the PID 600 identifies the specific chip 114 (not just the chip 114 configuration), and may be provided to the CE source 108 after the chip 114 is manufactured.
- the PID is a 64 bit Public CE Device ID that is generated by the security provider 106 and programmed in the chip 114 by the black box 116 .
- the security provider 106 ensures that the PIDs 600 are globally unique across all supported products, that is, across multiple chip manufacturers 104 and multiple CE device manufacturers 108 A. A system-wide unique value is needed to ensure that any manufactured chip 114 can be allocated to any customer.
- the PID 600 consists of a chip manufacturer identifier 602 , a model number 604 that specifies the type of chip 114 produced by that chip manufacturer 104 , a reserve field 606 for future use and a monotonically increasing serial identifier 608 to uniquely identify the chip 114 within the product family and manufacturer.
- the infrastructure provided by the security provider 106 in chips 114 programmed by the black box 116 allows for a broadcaster or service provider 102 to change Conditional Access Systems (CAS) at its discretion.
- CAS Conditional Access Systems
- the Conditional Access provider held the root RSA key used to sign the boot loading code.
- the boot loader code which is used by the Set Top Box (STB) or CE device 112 internal software to validate and authenticate a software download it has received, performs this critical verification step. This is to ensure an authorized party provides the code. If the boot loader cannot successfully validate the code, the code received in the download message will be rejected.
- the public portion of an RSA key root key is either part of the ROM mask set of the chip 114 or it is programmed into a secure portion of One Time Programmable (OTP) memory as part of the chip manufacturer's foundry process.
- This key can be used by the security infrastructure of the chip 114 to authenticate the download, which has been signed with the corresponding private key section of the programmed RSA key. If the signed hash 210 cannot be validated as shown in FIG. 3 , then the public RSA key verified in 310 is not correct or does not match with the public portion of the RSA key (either 200 or 201 ), the chip 114 will not come out of reset or will not continue with its operations, depending on the security rules of the chip 114 .
- the root public RSA key is extended by storing the CA vendor public RSA key in flash as shown in 216 .
- the CA vendor public RSA key 201 is either held by the broadcaster/service provider 102 , or by a trusted third party that acts as an escrow entity. This allows the broadcaster or service provider 102 wide latitude in operating its system if it wishes to either change out CAS vendors 108 B providers or to use multiple CAS systems in the field.
- This infield CA vendor 108 B replacement scheme enabled by the security provider 106 for its third party customers utilizes a combination of the security provider 106 black box 116 programmed data and the security provider 106 assigned keys given to the third party customer.
- Keys and programmed values that enable switching CA vendors include the security provider 106 ROM RSA key, Product Provisioning Key (PPK) 453 , the Customer Global Key (CGK) 402 , third party customer RSA key 201 signed by the security provider's 106 private RSA key 210 , the Customer Product Differentiator (CPD) 202 , and one or more Secret Value (SV) keys 451 .
- Each chip 114 contains a unique public identifier (the PID) 600 and a private symmetric provisioning key (the Product Provisioning Key (PPK) 453 ).
- the PID 600 can be freely shared with any third party while the PPK 453 is kept private by the security provider 106 and is never released to any third party and/or Consumer Electronic (CE) Source 108 .
- the JTAG password unlocks access to debug information and is only provided if the CE device 112 experiences an in field failure.
- the security provider 106 black box 116 programs a series of Secret Values (SVs) 451 that are allocated to the individual CE source 108 and/or CA vendors 108 B as the CE source 108 or CA vendor 108 B requires as a part of its conditional access system to secure content distribution. If multiple SVs 451 are programmed by the service provider 102 via the security provider 106 black box 116 and distributed to the field, the service provider may later elect to provide one or more of these SVs to an individual CA vendor 108 B when the CE device 112 is first used in the field or the service provider 102 can chose to save one or more SVs 451 for a subsequent CA vendor 108 B switch for the fielded CE device at a later time.
- SVs Secret Values
- These SV values 451 can both be provided by the security provider 106 , i.e. 2 or more keys, and held in escrow or given to the broadcaster or service provider 102 to hold. Another option open to the broadcaster or service provider 102 is for one of the SV values 451 to be provided by the security provider 106 and the others provided by an external key source or some other CA vendor 108 B.
- broadcast methodology i.e. Cable, Satellite distribution, IPTV, etc.
- region i.e. different areas of a particular City or Country, or Geographic Location such as the Asia-Pacific market
- content package High Definition Programming, Sports or Premium content
- a Security Kernel which is used to pass keys, perform certain housekeeping functions, etc. as deemed necessary by that vendor.
- the broadcaster or service provider 102 has control over the in field download via the public RSA root key 201 , it is a simple matter to update these Security Kernels in the field.
- the Security Kernels could be integrated into the “Golden Image” of the CE device 112 code at the manufacturing line, thus eliminating the need to do an in field download.
- the broadcaster or service provider 102 would then be able to use the appropriate CAS infrastructure by utilizing the specific SV 451 and other associated keys for that vendor. Again, this type of flexibility is unprecedented in the Pay TV industry and is only possible utilizing the security provider 106 black box 116 programmed data and the security provider 106 assigned keys given to the third party customer, (i.e. service providers 102 , CE source 108 , and/or CA vendors 108 B).
- the keys and programming infrastructure found in the chip 114 as provided by an independent security provider 106 enables the fielded Consumer Electronic (CE) device 112 to change conditional access (CA) vendors 108 B (hereinafter alternatively referred to as conditional access system (CAS) vendors), thus giving the service provider 102 or broadcaster more flexibility in managing their business.
- CA conditional access
- CAS conditional access system
- a service provider 102 or broadcaster can switch CA vendors 108 B in a legacy conditional access system without swapping fielded CE devices 112 using the method specified herein.
- This in-field CA vendor 108 B replacement scheme enabled by the security provider 106 for its third party customers utilizes a combination of black box 116 programmed data and security provider 106 assigned keys given to the third party customer (i.e. service providers 102 , CE source 108 , and/or CA vendors 108 B).
- Keys and programmed values that enable switching CA vendors 108 B include the security provider 106 ROM RSA key, PPK 543 , CGK 402 , third party customer RSA key 201 signed by the security provider's private RSA key Kpr SP (item 210 ), CPD 202 , and one or more SV keys 451 .
- a system boot code can be securely installed, verified, and executed in the CE device 112 and wherein data (D) used for conditional access can be securely provided to the CE device 112 for use in the conditional access system.
- D data used for conditional access
- the same procedures can be used to either provide additional conditional access functionality (e.g. to support a conditional access system provided by another CA vendor 108 B) or to revoke the conditional access functionality of a CA vendor 108 B and substitute that of another CA vendor 108 B.
- Adding additional functionality to support another CA vendor 108 B can be accomplished by the storage of additional security values, while revoking conditional access functionality of one CA vendor 108 B to substitute another can be accomplished by replacing previously installed security values with the security values for the new CA vendor 108 B.
- a generic bootloader 706 and/or SOC security driver can be installed in the flash memory of the System On a Chip (SOC) 114 using the procedures shown in FIG. 2 and FIG. 3 instead of the CE source 108 specific or secondary boot loader 710 .
- This generic bootloader 706 and/or SOC security driver is capable of accepting a new customer flash application image for the CE device 112 and can authenticate a third party public RSA key 201 associated with the new CA vendor 108 B stored in the new CE device 112 flash image as shown in blocks 302 - 312 of FIG. 3 .
- the new CE device 112 application flash image includes:
- the new CE device application flash image is authenticated as shown in FIG. 3 with the new signed third party RSA key as shown in 310 , new CPD 202 , and new CA vendor 108 B application, thereby, enabling the new CA vendor 108 B application to take control of the CE device 112 and provide content protection services for the service provider 102 .
- FIG. 7 shows a bootloader cascade beginning with the generic bootloader 706 authorizing the secondary bootloader 710 supplied by a CAS provider that in turn authorizes a STB application.
- the generic bootloader 706 is generally not replaced in the field. This bootloader 706 verifies Customer RSA key 201 , i.e. Cust1 as shown in 708 .
- the generic bootloader 706 does not contain the CAS vendor's 108 B public RSA key 201 .
- the generic bootloader 706 needs to be able to point to a new Over-the-Air (OTA) image 716 provided by the CAS vendor and load this image if the new image passes RSA Signature verification from FIG. 3 . Subsequent STB reboots will load the new CAS OTA image 716 , which may contain a revised secondary bootloader 710 .
- OTA Over-the-Air
- a download verification module resident in the STB Application monitors and guides the download process shown in 714 .
- the code needed to download and authenticate the new CE Device 112 image is controlled by the security provider 106 and the broadcaster/service provider 102 .
- the download verification module shown in 714 must be incorporated into the STB code image 716 to accept updates, validate updated image and re-launch the STB application.
- the download verification module shown in 714 assembles data segments of the encrypted image for the OTA update 716 , verifies data integrity and assists generic bootloader 706 in validating the signature. Following validation of the signature, the image 716 is decrypted and made ready for re-launching the updated CE Device 112 image.
- Table I lists the data used by the CE Source 108 and/or CA vendor 108 B in their typical operation in providing a secure content distribution system for their service provider 102 .
- Table II shows what keys and data fields in a particular CE device 112 are fixed (do not change) after a new software image containing an alternate conditional access vendor application has been downloaded and authenticated by the chip 114 .
- the PID 600 is a public identifier and can be freely shared with any third party.
- the PPK 453 is kept private to the security provider 106 and is never released to any third party and/or CE Source 108 (an encrypted version of the E SV [PPK] 455 is stored in the chip 114 , via the black box 116 as is the secret value (SV) 451 needed to decrypt the E SV [PPK] 455 ).
- the JTAG value is only provided if the CE device 112 experiences an in field failure.
- Table II also shows different values of the SV key 451 .
- the first value SV 451 is the value programmed by the security provider 106 via the black box 116 and is allocated to the individual CE source 108 and/or CA vendors 108 B as the CE source 108 or CA vendor 108 B requires as a part of its conditional access system to secure content distribution.
- SV CA2 is distinguished from SV2 451 , which can be optionally programmed by the black box 116 ). Hence, if multiple SVs 451 are programmed by the service provider 102 via the black box 116 and distributed to the field, the service provider 102 may later elect to provide one or more of these SVs 451 (e.g.
- SV SV
- the service provider 102 can chose to save one or more SVs 451 (SV CA2 , SV CA3 , SV CA4 . . . ) for a subsequent CA vendor 108 B switch for the fielded CE device 112 at a later time.
- the downloaded STB image contains the switchable keys from Table III, i.e. the initial image loaded in the STB flash contains CA Vendor key set 0 as defined below:
- CA switch means that the new STB flash for the new STB application contains an image that has values for CA Vendor key set 1.
- the Code Signing verification routine needs to reference these fields from the STB flash image.
- Table III shows the new key and data fields that utilized when a new CE device image implements a switch from one CA vendor 108 B to another CA vendor 108 B.
- Each CA vendor 108 B switch results in the installation and use of a new Customer Public RSA key 201 (i.e. Cust Pub RSA Key1, Cust Pub RSA Key2, Cust Pub RSA Key3 in the Table III).
- the security provider 106 assigns each new CA vendor 108 B a unique CPD 202 (i.e. CPD1, CPD2, CPD3 in Table III).
- the security provider 106 hashes the Customer Public RSA key 201 and CPD 202 producing unique hash values and signs each new hash with the security providers 106 own Private key as requested by the service provider 102 . (i.e. Signed Hash1, Signed Hash2, Signed Hash3 in Table III).
- the address location for the flash-based third-party public RSA key 201 and/or the CPD 202 can also be used fix input data for a given CE source 108 and incorporated into the signed hash block 210 .
- the secret values (SVs) 451 programmed by the black box 116 during SOC manufacturing are allocated as determined by the service provider/broadcaster 102 or CE device 112 owner. In Table III a different SV value 451 is allocated to the CA vendor 108 B after a switch is performed.
- the security provider 106 also assigns a new CGK 456 and generates the E PPK [CGK] 459 for each switch to a new CA vendor 108 B or different conditional access system.
- the new CE device 112 application flash image 716 is authenticated with the new signed Third Party RSA key 210 , new CPD ( 202 ), and new CA vendor 108 B application 716 as shown in FIG. 3 .
- This enables the new CA vendor 108 B application to take control of the CE device 112 and provide content protection services for the service provider 102 with the conditional access system new CA vendor 108 B.
- An existing CE vendor's 108 B conditional access data can also be revoked. This is made possible by incorporating the CPD 202 into the signed hash 210 to enable the CE source 108 to revoke a previously assigned CE source 108 public RSA key 201 .
- the CE Source 108 provides a new public RSA key 201 to the security provider 106 .
- the security provider 106 assigns a new CPD 202 to be used with the new public RSA key 201 , with the new CPD 202 to be stored at the same address as the CPD 202 currently stored and used with the existing public RSA key 201 .
- the security provider 106 returns a new signed hash 210 for the new CE source public RSA key 201 and new CPD 202 .
- the CE source 108 transmits a new software image 716 to the CE device 112 (for example, by wireless means).
- the previously signed CE source public RSA 201 key will no longer be successfully validated by the security provider's signed hash 210 since the signed hash uses old CPD 202 value, which will no longer pass the verification process in blocks 304 - 312 of FIG.
- the previous CE source public RSA key 201 could be used once again if the security provider source provides another signed hash 210 using the old CE source public RSA key, old CPD value 202 with a new CPD address since the CPD value 202 at the old CPD address location has been changed.
- Table IV shows a provisioning example where two CA vendors 108 B can coexist in the same CE device.
- a common Customer private RSA key signs the final CE Device binary image containing the production code 716 .
- the CE Device 112 would verify the signature using the Cust Pub RSA Key0 shown in 708 contained in the image 716 loaded during CE Device manufacturing or sent over the air.
- the Customer who holds/generated the code signing RSA key 201 would be the CE Device 112 owner who is responsible for the overall operation of the STB or CE Device and the Co-existence of both CA vendors 108 B in the field.
- the CE device 112 owner would be responsible for receiving the final binary images from the two CA vendors 108 B and making sure that the applications 716 perform properly together.
- Each CA vendor 108 B maintains its own Secret Value key 451 (SV1 and SV2 respectively) programmed by the black box 116 during SOC manufacturing that protects content related items such as Control Words and subscription entitlements.
- Each CA vendor 108 B also is provided with its own Customer Global Key 202 (CGK1 and CGK2 respectively) that is used to protect sensitive code and CE Device data contained in the application code image 716 .
- CA Co-Existence works in a single CE Device 112 because each CA vendor's 108 B content protection mechanism is cryptographically protected and isolated against the other through the allocation of independent key sets (SV1/E PPK [CGK1] and SV2/E PPK [CGK2] respectively) programmed by the black box 116 .
- the CA vendor 108 B designs their unique content protection and distribution architecture based on these root keys resident in the CE device 112 . Since the root key sets shown in Table IV are unique and separate for each CA vendor 108 B, encrypted subscription entitlements and control words can be delivered uniquely to the CE Device 112 without fear of them being manipulated or falsely created by the other CA vendor 108 B.
- service provider 102 uses a key to protect a Joint Test Action Group (JTAG) port on the chip that is used to obtain access to higher security areas of the chip 114 (e.g. the chip's internal states).
- JTAG Joint Test Action Group
- the value for this key can be programmed by the black box 116 during chip 114 manufacturing.
- the key is a 128-bit JTAG key.
- the JTAG key should be a 128-bit value. Smaller values JTAG key lengths are acceptable if there is a delay function between successive password unlock attempts. For adequate security, the key length should be at least 64 bits in length. Access to the JTAG port is gained when the password is supplied. This key cannot be exported to software.
- FIG. 8A is a diagram presenting exemplary method steps that can be used as a method for a first entity (service provider 106 ) to deliver JTAG data to unlock the hardware device or chip 114 to a second entity (CE source 108 ).
- the chip 114 ownership by the second entity can be verified by the first entity if the second entity delivers an authentication value produced uniquely for each chip 114 as recoded during the manufacturing process.
- FIG. 8A is a diagram illustrating exemplary method steps that can be used to deliver the unlocking data.
- a product provisioning key that has been encrypted with the chip 114 unique secret value SV 451 is transmitted from the first entity (the service provider 102 ) to the second entity (CE source 108 ) for secure storage in the chip 114 . In one embodiment, this is accomplished via the Black box 116 .
- a chip 114 PID 600 is also stored in the chip 114 .
- the chip is provided to the CE Source, which installs the chip 114 in a CE device 112 , and provides the CE device 112 with the chip 114 to third parties, such as end users, as shown in block 804 .
- the CE device When the CE device wishes to unlock the hardware chip using JTAG or similar data, the CE source 108 and transmits, and the service provider 102 receives an unlock request, as shown in block 806 .
- the unlock request comprises a customer validation code CVC 862 that is computed by the chip 114 and reproducible in the service provider 106 as well as chip 114 identifying information such as the PID 600 .
- the CVC 862 is also computed using the CE source 108 unique customer product differentiator (CPD 202 ), the chip 114 unique PID 600 .
- the service provider 102 receives the unlock request having the CVC 862 and PID 600 , and computes an expected CVC 862 from the secret value SV 451 , and CPD/PID/PPK as required, as shown in block 808 .
- the resulting expected CVC 862 is compared to the CVC 862 received from the CE source 108 in the unlock request, and if the two values match, the service provider 102 transmits the requested JTAG data to the CE Source 108 .
- the CE Source can then use that data to unlock the chip 114 as desired.
- FIG. 8B illustrates a more specific example of the calculation and distribution of customer validation data by the CE source 108 after the chip 114 is manufactured.
- the service provider 102 can implement a chip 114 ownership validation scheme that the CE source 108 or subscriber 110 can use to prove ownership of the CE device 112 before the service provider 102 releases a JTAG key to a requesting party.
- the CE source 108 participates in the generation of validation codes when the chip 114 is produced.
- the consumer validation code (CVC 862 ) must be determined. This can be accomplished in a number of ways.
- E SV [PPK] 455 itself us unique, it can be used as the consumer validation code CVC 862 , as shown in block 852 .
- the CVC 862 may be computed inside the chip 114 from different combinations of E SV [PPK], the chip PID 600 , the unique customer product differentiator CPD 202 , and a seed provided by the service provider 102 .
- the CVC 862 can be computed as an XOR of the PID 600 and E SV [PPK] 455 , as shown in block 856 , as an XOR of the PID 600 , the E SV [PPK] 455 , and the CPD 202 , as shown in block 858 , or an XOR of the CPD 202 and the E SV [PPK] 455 , as shown in block 860 .
- CVC 862 calculations are unique to the chip 114 , SV 451 and globally unique PID 600 , which could only be have been produced by a single chip 114 of the entire population of fielded chips 114 .
- the CVC 862 (alternatively referred to hereinafter as the hash validation code) and optionally the PID 600 are recorded as shown in block 864 for later use in validating chip 114 or CE device 112 ownership.
- the service provider 102 needs to be able to validate third party owner of the CE device before the JTAG unlock key can be release to a third party customer (e.g. CE source 108 ).
- the third party customer such as the CE source 108 transmits a JTAG unlock request 866 to the service provider 102 .
- the request includes the CVC 862 862 and PID 600 for the chip 114 for which they require a JTAG unlock key.
- the service provider 102 looks up the SV 451 of the chip 114 using the PID 600 supplied by the third party customer.
- the service provider 102 uses the SV 451 and the PID/CPD to calculate the expected CVC 862 , as shown in blocks 872 and 874 .
- the service provider 102 verifies that the customer supplied CVC 862 matches the calculated expected CVC 862 to determine if they are the legitimate third party owner of the chip 114 . If so, the JTAG data needed to unlock the chip 114 is transmitted to the third party customer, as shown in block 878 .
- client devices 112 It is desirable for service providers to have the capability to segment a population of CE devices 112 (hereinafter alternatively referred to as client devices 112 ) into a number of different groups based on CAS switching requirements. For example, a service provider may want client devices 112 of a particular generation to switch to a second CA system based upon a discovered vulnerability discovered in that particular generation of client device 112 . It is especially desirable that this capability include fielded devices that are already deployed in consumer locations. This fluid ability to define and redefine groups of fielded devices allows different CAS switching paradigms to be defined, including CAS switching that occurs slowly throughout the fielded client device 112 population.
- a CAS switching paradigm and a method for signaling such switching that permits groups of fielded client devices 112 to be defined and redefined as necessary, and provides a technique for signaling when and how such CAS switching should take place.
- the client device 112 has previously received an appropriate application image containing a current CAS application that will be switched out and a new CAS application that will be switched in to replace the current CAS application.
- the CAS switching process is guided by the vendor of the middleware executing on the client device 112 (for example, the CA vendor 108 B), and no direct support is required from the CAS application itself.
- the CAS client runs in the client device 112 on a security processor separate and peripheral from the primary CPU of the client device 112 or a trusted execution environment (TEE), while the middleware typically executes on the same CPU used for the primary CAS application.
- TEE trusted execution environment
- the CAS signaling and switching is performed on a client device 112 compliant with the digital video broadcasting (DVB) specifications, including “Digital Video Broadcasting (DVB): Implementation Guidelines of the DVB Simulcrypt Standard, ETSI TR 102 035, Version 1.1.1, published 2002 by the European Telecommunications Standards Institute; “Digital Video Broadcasting (DVB): Head-end implementation of DVB SimulCrypt,” ESTI TS 103 197, Version 1.5.1, published 2008 by the European Telecommunications Standards Institute; and “Common Interface Specification for Conditional Access and Other Digital Video Broadcasting Decoder Applications,” EN 50221, published February 1977 by the Technical Committee CENELEC TC 206, all of which are hereby incorporated by reference herein.
- DVD Digital Video Broadcasting
- the CAS switching process involves the Application Specific Data (ASD), which is defined in the Digital Video Broadcasting (DVB) specifications as Private Data (PD).
- ASD Application Specific Data
- PD Private Data
- CAS switching data is inserted by the service provider 102 (hereinafter alternatively referred to as the headend 102 ) into the content delivery network (CDN) for delivery to the selected client devices 112 .
- CDN content delivery network
- This data is received and processed by the middleware in the client device 112 to use the appropriate CAS application as directed by the signaling mechanism described herein.
- This process allows the operator of a service provider or headend 102 (COMCAST, DIRECTV, DISHTV, or ECHOSTAR, for example) to set up groups in the client device 112 population as they see fit at the time they intend to perform a switch away from the existing CAS vendor 108 B to a new CAS vendor 108 B whose application resides in the device.
- a CAS switch may be desirable in the event the exiting CAS system has been hacked, due to an expiring business relationship with the existing CAS, or more favorable business terms and/or features are available in a new CAS.
- the CAS data is passed to each defined group of client devices 112 through the middleware based on the ASD.
- the new CAS is signaled to the middleware by a message sent from the headend 102 indicating that the middleware should begin using the new CAS.
- the individual SoC 114 in each client device 112 may require a reboot if required or needed to properly configure the data and key handling resources in the SoC 114 .
- Specific SoCs 114 may be utilizing a derived key mechanism (defined below), which means that the key ladder responsible for calculating the control words used to decrypt encrypted video packets must be properly configured in the SoC 114 for a given CAS client.
- the Private Data Generator (PDG) described in the DVB standard closely resembles an entitlement management message (EMM) generator, receives and processed the ASD.
- EMM entitlement management message
- This implementation is independent of the CA vendor 108 B of the CAS, so it is not necessary to discuss details of the CAS switching implementation or process with individual CAS vendors 108 B.
- the CAS switch is independent of the CAS client itself as it is guided by state in the middleware implemented in the client device 112 . After a switch, entitlements are delivered to the new CAS client (i.e. CAS application for the new operational CAS in the client device) for it to properly provide the subscriber with access to their paid/subscribed programming.
- a CAS switch is performed during off peak viewing hours to minimize disruption in the subscriber/viewing population.
- the switch command is a part of the same signal that delivers the content itself, a switch from one CAS to another will not occur if the client device 112 is not receiving the content delivery signal at the time a CAS switch is requested by the headend 102 . Consequently, a second or third attempt to complete the CAS switch may be required before the switch actually takes place.
- Messages to the middleware could be repeated in a carousel fashion (similar to how electronic program guides (EPGs) are currently distributed), and contain a date/time to perform the actual switch/reboot. That increases the likelihood that all client devices 112 in the group perform the switch command at the same time, irrespective of when each client device 112 may have been tuned to the receive the content delivery signal.
- EPGs electronic program guides
- the DVB standard defines a program association table (PAT) and a conditional access table (CAT). Both the PAT and the CAT are associated with DVB program identifiers (PIDs) that identify each program in a data stream that may comprise multiple programs.
- the data stream may also comprise multiple independent program map table (PMT) sections. Each PMT section is given a unique user-defined PID and maps a program number to the metadata describing the program and the program streams.
- the PIDs associated with each PMT section are defined in the PAT, and are the only PIDs defined there.
- the streams themselves are contained in packetized elementary stream (PES) packets with user-defined PIDs specified in the PMT.
- the PMT is comprised of sections for each program number represented in a transport stream, each section of which contains the packet identifier and characteristics of each elementary stream in the program service.
- the CAT is used for conditional access management of the cypher keys used for decryption of restricted streams.
- the CAT table contains privately defined descriptors of the system used and the PID of the EMM associated with that system. It is used by a network provider to maintain regular key updates.
- FIG. 9 is a diagram illustrating exemplary method steps for controlling a group of client devices 112 to switch from a first CAS to a second CAS via a plurality of client device signaling messages.
- the client device signaling messages each comprise at least one of a plurality of action codes and payload data.
- a group identifier that identifies the group of client devices 112 is generated.
- a first client device signaling message is transmitted to only each client of the identified group of client devices 112 (the first client device signaling message is not transmitted to client devices 112 that are not in the identified group).
- the first client device signaling message includes the group identifier.
- the group identifier is for storage in a non-volatile memory of each client device 112 of the group of client devices 112 .
- a second client device signaling message is transmitted to the plurality of client devices 112 (which may include client devices 112 that are not in the identified group).
- the second client device signaling message includes the group identifier and signals a switch of each of the group of client devices 112 from the first conditional access system to the second conditional access system.
- each of the plurality of devices comprises a middleware module
- the first client device message and the second client device message are transmitted on a conditional access switching message channel monitored by the middleware module of each of the plurality of devices.
- an identifier of the conditional access switching message channel e.g. a switching message PID
- a switching message PID is transmitted to each of the plurality of devices, for example, in a conditional access table.
- FIG. 10 is a diagram illustrating exemplary operations performed by the client devices 112 in receiving and handling the first client device message and the second client device message.
- a middleware module of at least one client device 112 of the group of client devices 112 monitors a channel identified by the identifier of the conditional access switching message channel.
- the middleware module of the at least one of the client devices 112 receives the first client device message transmitted in block 904 (which includes the group identifier).
- the group identifier is stored in non-volatile memory of the at least one of the client devices 112 .
- the middleware of the client devices 112 continue to monitor the conditional access switching message channel, and in block 1008 , the middleware module of the at least one of the group of client devices 112 receives the second client device message.
- Block 1010 determines whether the second client device signaling message comprises the group identifier received and stored in blocks 1004 and 1006 . If so, the at least one client device 112 switches from the first conditional access system to the second conditional access system, as shown in block 1012 .
- FIGS. 11-12 illustrate the operations presented in FIGS. 9-10 in greater detail.
- FIG. 11 illustrates operations that may be performed to assign a client device 112 to a group. This illustrates additional detail regarding the operations illustrated in blocks 902 and 904 of FIG. 9 and blocks 1002 - 1006 of FIG. 10 .
- Client devices 112 are assigned to a particular group upon activation via a group identifier stored in non volatile memory (NVM).
- NVM non volatile memory
- the group identifier allows a subset of the client device 112 population to switch to another CAS system stored in the client device, but dormant (e.g. not installed and operating). This group assignment by provision of the group identifier is in addition to the other actions that may be required by the CAS currently active in the client device. Then an application executing on the client device 112 updates the group identifier by storing it in NVM upon reception of a message having an Assign Group Action.
- an operator 1102 issues an assign group command to the private generator or PDG 1104 .
- the operator 1102 may comprise a human or a computer executing instructions to generate the command based on input from humans or another computer.
- the PDG 1104 generates private data comprising a group identifier, and provides this identifier to a multiplexer 1106 which multiplexes the private data having the group identifier into the data stream transmitted to the client device.
- the private data is then transmitted in a data stream to the client device 112 where it is accepted by the client device 112 (set top box or STB) application 1108 , as shown in 1156 .
- the client device 112 updates the group identifier of the client device 112 by storing the received group identifier in non-volatile memory (NVM) as shown in 1158 .
- NVM non-volatile memory
- FIG. 12 illustrates operations that may be performed to initiate a CAS switch. This illustrates additional detail regarding the operations illustrated in blocks 906 of FIG. 9 and blocks 1008 - 1012 of FIG. 10 .
- a CAS switch is initiated by a Switch CAS message generated by the PDG.
- the Switch CAS messages can be addressed to one or more individual client devices 112 , a group of client devices 112 or all client devices 112 .
- This paradigm permits a single message to be sent to all client device 112 members in the group as opposed to sending many single, independent messages to individual client devices 112 .
- the Switch CAS message may include an activation date to allow pushing of the message before the CAS switch is to actually take place. In such cases where the activation date/time is in the future, the STB application 1108 executing in the client device 112 sets an event and writes the CAS ID to a NVM memory location for future use by the CAS Switch activation event.
- the STB application 1108 When the activation event occurs (in the future or immediately), the STB application 1108 writes the CAS ID to a well-known location memory location in NVM (that is designated to be executed on reboot) and reboots. On reboot, the STB application 1108 reads the CAS ID and activate the corresponding CAS kernel to install and execute the new CAS.
- the operator 1102 selects which group of the client devices 112 are desired for a CAS switch, an identifier of the CAS to be switched to (CAS ID) and issues a CAS switch command identifying these devices and providing the CAS ID, as shown in 1202 .
- the PDG generates private data comprising the group number of the group of client devices 112 for which the CAS switch was desired, and provides that PDG to the multiplexer 1106 , which multiplexes the private data having the group identifier and information indicating that a switch is desired into the data stream as a CAS switch command.
- the private data is then transmitted in a data stream to the client device 112 where it is accepted by the client device application 1108 , as shown in 1208 .
- the CAS switch may be performed immediately upon receipt by the client device, or may be performed as a future event.
- the CAS ID is updated in NVM, and the client device 112 is rebooted as shown in 1210 and 1212 .
- the CAS ID is updated in NVM, and a future event is set, at which time the CAS switch will take place by rebooting 1212 the client device.
- middleware executing on the client device 112 checks the known flash location (designated to be executed on reboot) to determine which CAS to initialize. This information was included in the form of the CAS ID (for example, CAS-A, CAS-B or CAS-C) transmitted with the CAS Switch message described above.
- the middleware executing on the client device 112 provides CAS specific data to a secure processor of the client device 112 (e.g. a SoC 114 or system on a chip) so that the SoC 114 can derive keys associated with the selected CAS and pertaining to the appropriate CAS vendor 108 B.
- keys may include, for example keys or intermediate results required to derive keys for decrypting media programs encrypted by the headend 102 .
- the middleware executing on the client device 112 initializes the appropriate CAS, which then operates as a CAS client.
- the middleware monitors the appropriate channel to receive the CAT from the headend 102 , and once the CAT is received, the middleware passes the CAT to the CAS client.
- the CAS client instructs the middleware to monitor the appropriate channel to receive EMMs.
- the appropriate channel can be defined according to a particular DVB PID, which may be placed in the CAT with a “dummy” CAS identifier. For example, in a DVB system, the PID used for EMM reception may be monitored.
- the middleware receives the PMT and parses the PMT to determine the PID of the ECMs that correspond to the CAS currently in operation (e.g. the CAS recently switched to). The middleware then filters the incoming data stream for ECMs having the determined PID, and passes those ECMs to the CAS client. The CAS client (cooperating with the middleware if necessary) then process the ECM to load decrypting information such as keys and/or software, and uses that information to generate keys or other information that is needed to decrypt media program(s).
- decrypting information such as keys and/or software
- This section provides an exemplary format and syntax of the messages communicated with the client device. It is noted that message of differing format and/or syntax may be used. In a preferred embodiment, the messages themselves are cryptographically protected, either through encryption, hashing or other means.
- Messages communicated with the middle ware include (1) an address (intended target of message, such as global, group, specific), (2) a sequence number (to prevent duplicate processing), (3) a message type, and (4) payload.
- Message types include but are not limited to (1) Assign group, (2) Assign CAS Vendor 108 B, and (3) Reboot. Payloads are specific to a particular message type, as further described below. Based on message type, middleware will take appropriate action (i.e. store group info in flash, store selected CAS vendor 108 B in flash, reboot at the appropriate time).
- Message include an action code, describing a particular action that the message is to command.
- actions are embedded in the message in a tag-length-value (TLV) format.
- Table V defines one embodiment of a minimal list of Actions to implement for CAS Switching messages.
- Each message minimally requires the following Actions (1) Addressing (unique, group, or global) (2) Timestamp (3) Sequence number (4) Primary action (Assign Group or CAS Switch).
- the Sequence Number action (01) is used communicate the sequence number of the message to the STB Application 1108 . This information prevents the STB application 1108 from reprocessing messages. Data associated with this action is presented in Table VI.
- Timestamp action (02) is used to indicate system time. Messages with Timestamps in the past should not be processed. Data associated with this action is presented in Table VII.
- the Unique Addressing action (10) is used to address a single client device. Data associated with this action is presented in Table VIII.
- the Group Addressing (11) action is used to address a group of client devices 112 assigned to a Group Identifier. Data associated with this action is presented in Table IX.
- the Global Addressing (12) action is used to address all client devices 112 . Data associated with this action is presented in Table X.
- the Assign Group (20) action is used to assign a STB to a Group Identifier. Data associated with this action is presented in Table XI.
- the CAS Switch (21) action is used to signal a CAS Switch. Data associated with this action is presented in Table XII.
- SoC 114 permits programming of unique secrets into the SoC 114 at the SoC 114 manufacturing site 104 and permits later allocation of these SoCs 114 to any one of a number of potential CE device manufacturers 108 A and many independent CAS/DRM vendors 108 B. SoC 114 programming can also occur at the packaging or product manufacturing facility by execution of an in-field programming sequence on the SoC 114 .
- a Hardware Root of Trust Security is offered for high value content with easy integration with a CAS and DRM technology to enable many content providers to provide their media programs directly to consumers using their CE devices.
- a security provider independent architecture can support multiple concurrent or serial CAS and DRM implementations using a single black box programming security platform with limited One Time Programming (OTP) resources to store secrets representing the hardware root of trust.
- OTP One Time Programming
- SoCs 114 In a derived key SoC architecture providing security providers with different security key debases is accomplished by allowing SoCs 114 to use black box OTP resources as the basis to derive security keys to enable different security schemes by altering the key generation inputs based on digital rights management (DRM) and CAS vendor 108 B software and possibly CA vendor 108 B unique OTP inputs.
- DRM digital rights management
- the key generation inputs can be provided in the CAS and DRM application that could be loaded at CE device manufacturing or downloaded over the air for fielded CE device(s).
- Key derivation can be accomplished in a number of ways, for example, by taking the black box programmed secret OTP keys, CAS/DRM vendor 108 B software input and possible CAS/DRM vendor 108 B unique OTP values and combining in a series of crypto graphic calculations using AES, DES or Triple DES. Where the black box programmed secret OTP keys are used as the key and the software input and CAS/DRM vendor 108 B unique OTP values are the data in the cryptographic operation. Such operations are standard for those skilled in use and construction of cryptographic calculations.
- the SoC 114 can derive unique key outputs for each CAS and DRM security provider used for a given content provider or broadcaster.
- CAS unique inputs such as their assigned CAS ID may be used to differentiate derived keys for CAS1 versus CAS2.
- security provider in this context is to be broadly construed and reflects the entity who would use the derived key database for a population of fielded CE devices to protect content for purchase by an entity who had a particular CE device in their home.
- These security provider unique key generation outputs enable support for multiple security providers for fielded CE devices typically found in Set Top Boxes, televisions (TVs), Smart TVs and mobile devices.
- the black box security provider provides compatible headend applications to each content provider, so that the media programs are encrypted or otherwise protected using the CAS and DRM implementation used.
- Another advantage of using a derived key database is that the black box programmed OTP key secrets programmed into the SoC 114 OTP do not have to be released to the multiple CAS and DRM security providers, since these security providers would use the derived key databases for their content protection systems. This means that if a derived key database were compromised, it only affects the specific CAS/DRM security provider that was using that specific derived key database, i.e. such compromise would not affect the fielded CE devices or derived key databases of any other such CAS/DRM security provider.
- the keys and programming infrastructure summarized herein as provided by an independent black box security provider enables fielded CE devices to add additional revenue baring applications to the CE device manufacturer or content provider giving these entities more flexibility in managing their business and offering new services.
- a CAS/DRM vendor 108 B Besides switching out a CAS/DRM vendor 108 B for any number of reasons, enabling the ability to add applications supporting new CAS/DRM vendors 108 B in fielded CE devices 112 can result in generating significantly higher content sale revenues without requiring consumers to upgrade their CE devices 112 .
- Consumer savings are realized by extending the field life of the CE device 112 by allowing the consumer to download new software images to enable the purchase of new content services without having to replace their fielded CE devices 112 .
- a client device 112 such as a STB to act as a second and/or dormant backup to be used in emergency situations for business continuity purposes or as an alternative to other CAS clients that may also reside in the client device.
- the operator or broadcaster must assign their content packages and products to the dormant CAS so that package definitions and entitlements can be properly assigned and allow authorization messages to be created and delivered to the STBs.
- Client licensing and headend 102 equipment must also be available to integrate all CAS client applications implemented in the client device 112 , i.e. the primary, backup and/or dormant CAS client must be fully developed, tested and ready to integrate into the client device and middleware application so that they can be fully operational in the event they are needed to replace the primary CAS client in the deployed client device. Implementing this embodiment requires the completion of the following.
- each CAS client must be fully integrated with the client device 112 to provide full capabilities for the second/dormant CAS system. This is to assure compatibility of the CAS system and the middleware executed by the client device. Hence, if the CAS and middleware executed by the client device 112 are from different vendors, they must assure such interoperability is maintained so that the CAS and middleware operate in an integrated manner. Such integration requires marginal additional effort for a single vendor since the CAS integration effort will be conducted for each integrated CAS client.
- related CAS (and middleware)-related applications executing at the headend 102 must be integrated with the CAS clients and middleware executing in the client devices 112 , preferably prior or near system launch.
- the CAS-related headend 102 execute on servers operated by the headend 102 , due to intellectual property concerns and to isolate their execution environments.
- a CAS switch by a limited number of fielded client devices 112 should be tested to ensure proper client device 112 operation before and after the switch.
- the switch to a supported CAS client in the client device 112 may be activated using the above CAS switching protocol with no hardware modifications to the client device 112 or the headend 102 equipment.
- This same switching protocol can be used to switch between the any of the supported CAS clients in the fielded client devices 112 , giving full access to the content protection systems for the new CAS client. Using this approach such CAS switching is transparent to the CAS application running in the client device.
- FIG. 13 is a diagram illustrating an exemplary computer system 1300 that could be used to implement elements of the present invention, including processing elements at the service provider 102 , chip manufacturer 104 , security provider 106 , black box 116 , chip manufacturer 104 and CA vendor 108 B, chips 114 and CE device 112 .
- the computer 1302 comprises a general purpose hardware processor 1304 A and/or a special purpose hardware processor 1304 B (hereinafter alternatively collectively referred to as processor 1304 ) and a memory 1306 , such as random access memory (RAM).
- the computer 1302 may be coupled to other devices, including input/output (I/O) devices such as a keyboard 1314 , a mouse device 1316 and a printer 1328 .
- I/O input/output
- the computer 1302 operates by the general-purpose processor 1304 A performing instructions defined by the computer program 1310 under control of an operating system 1308 .
- the computer program 1310 and/or the operating system 1308 may be stored in the memory 1306 and may interface with the user and/or other devices to accept input and commands and, based on such input and commands and the instructions defined by the computer program 1310 and operating system 1308 to provide output and results.
- Output/results may be presented on the display 1322 or provided to another device for presentation or further processing or action.
- the display 1322 comprises a liquid crystal display (LCD) having a plurality of separately addressable pixels formed by liquid crystals. Each pixel of the display 1322 changes to an opaque or translucent state to form a part of the image on the display in response to the data or information generated by the processor 1304 from the application of the instructions of the computer program 1310 and/or operating system 1308 to the input and commands.
- Other display 1322 types also include picture elements that change state in order to create the image presented on the display 1322 .
- the image may be provided through a graphical user interface (GUI) module 1318 A. Although the GUI module 1318 A is depicted as a separate module, the instructions performing the GUI functions can be resident or distributed in the operating system 1308 , the computer program 1310 , or implemented with special purpose memory and processors.
- GUI graphical user interface
- a special purpose processor 1304 B may be implemented in a special purpose processor 1304 B.
- some or all of the computer program 1310 instructions may be implemented via firmware instructions stored in a read only memory (ROM), a programmable read only memory (PROM) or flash memory within the special purpose processor 1304 B or in memory 1306 .
- the special purpose processor 1304 B may also be hardwired through circuit design to perform some or all of the operations to implement the present invention.
- the special purpose processor 1304 B may be a hybrid processor, which includes dedicated circuitry for performing a subset of functions, and other circuits for performing more general functions such as responding to computer program instructions.
- the special purpose processor is an application specific integrated circuit (ASIC).
- the computer 1302 may also implement a compiler 1312 which allows an application program 1310 written in a programming language such as COBOL, C++, FORTRAN, or other language to be translated into processor 1304 readable code. After completion, the application or computer program 1310 accesses and manipulates data accepted from I/O devices and stored in the memory 1306 of the computer 1302 using the relationships and logic that was generated using the compiler 1312 .
- a compiler 1312 which allows an application program 1310 written in a programming language such as COBOL, C++, FORTRAN, or other language to be translated into processor 1304 readable code.
- the application or computer program 1310 accesses and manipulates data accepted from I/O devices and stored in the memory 1306 of the computer 1302 using the relationships and logic that was generated using the compiler 1312 .
- the computer 1302 also optionally comprises an external communication device such as a modem, satellite link, Ethernet card, or other device for accepting input from and providing output to other computers.
- an external communication device such as a modem, satellite link, Ethernet card, or other device for accepting input from and providing output to other computers.
- instructions implementing the operating system 1308 , the computer program 1310 , and/or the compiler 1312 are tangibly embodied in a computer-readable medium, e.g., data storage device 1320 , which could include one or more fixed or removable data storage devices, such as a zip drive, floppy disc drive 1324 , hard drive, CD-ROM drive, tape drive, or a flash drive.
- a computer-readable medium e.g., data storage device 1320 , which could include one or more fixed or removable data storage devices, such as a zip drive, floppy disc drive 1324 , hard drive, CD-ROM drive, tape drive, or a flash drive.
- the operating system 1308 and the computer program 1310 are comprised of computer program instructions which, when accessed, read and executed by the computer 1302 , causes the computer 1302 to perform the steps necessary to implement and/or use the present invention or to load the program of instructions into a memory, thus creating a special purpose data structure causing the computer to operate as a specially programmed computer executing the method steps described herein.
- Computer program 1310 and/or operating instructions may also be tangibly embodied in memory 1306 and/or data communications devices 1330 , thereby making a computer program product or article of manufacture according to the invention.
- the terms “article of manufacture,” “program storage device” and “computer program product” or “computer readable storage device” as used herein are intended to encompass a computer program accessible from any computer readable device or media.
- the term “computer” is referred to herein, it is understood that the computer may include portable devices such as cellphones, portable MP3 players, video game consoles, notebook computers, pocket computers, or any other device with suitable processing, communication, and input/output capability.
- portable devices such as cellphones, portable MP3 players, video game consoles, notebook computers, pocket computers, or any other device with suitable processing, communication, and input/output capability.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Storage Device Security (AREA)
Abstract
A method and apparatus for controlling a group of the client devices to switch at least one client device of the group of client devices from a first conditional access system to a second conditional access system is disclosed. In one embodiment, the method comprises generating a group identifier identifying the group of the client devices, transmitting a first client device signaling message having the group identifier only to each client device of the identified group of the client devices, and transmitting a second client device signaling message to the plurality of client devices, the second client device signaling message comprising the group identifier and signaling each client device having the group identifier stored in the non-volatile memory to switch from the first system client to the second system client.
Description
- This application is a continuation of U.S. patent application Ser. No. 15/791,260, entitled “SIGNALING CONDITIONAL ACCESS SYSTEM SWITCHING AND KEY DERIVATION,” by Jacob T. Carson, Michael A. Gorman, and Ronald P. Cocchi, filed Oct. 23, 2017, now U.S. Pat. No. 10,476,883, which application:
- claims benefit of U.S. Provisional Patent Application Ser. No. 62/446,196, entitled “SIGNALING METHOD FOR CAS SWITCHING AND KEY DERIVATION,” by Jacob T. Carson, Michael A. Gorman, and Ronald P. Cocchi, filed Jan. 13, 2017;
- is a continuation-in-part of U.S. patent application Ser. No. 14/382,539, entitled “BLACKBOX SECURITY PROVIDER PROGRAMMING SYSTEM PERMITTING MULTIPLE CUSTOMER USE AND IN FIELD CONDITIONAL ACCESS SWITCHING,” by Ronald P. Cocchi et al., filed Sep. 2, 2014, which application is a National Stage Entry of international patent application PCT/US13/28761, entitled “BLACKBOX SECURITY PROVIDER PROGRAMMING SYSTEM PERMITTING MULTIPLE CUSTOMER USE AND IN FIELD CONDITIONAL ACCESS SWITCHING,” by Ronald P. Cocchi et al., filed Mar. 1, 2013, now issued as U.S. Pat. No. 9,800,405, and which application claims benefit of U.S. Provisional Patent Application Ser. No. 61/606,260, entitled “BLACKBOX SECURITY PROVIDER PROGRAMMING SYSTEM PERMITTING MULTIPLE CUSTOMER USE AND FIELD CONDITIONAL ACCESS SWITCHING,” by Ronald P. Cocchi et al., filed Mar. 2, 2012;
- all of which applications are hereby incorporated by reference herein.
- This application is also related to U.S. patent application Ser. No. 15/652,082, entitled “METHOD AND APPARATUS FOR SUPPORTING MULTIPLE BROADCASTERS INDEPENDENTLY USING A SINGLE CONDITIONAL ACCESS SYSTEM,” by Ronald P. Cocchi et al., filed Jul. 17, 2017, which also claims benefit of U.S. Provisional Patent Application Ser. No. 62/446,196, entitled “SIGNALING METHOD FOR CAS SWITCHING AND KEY DERIVATION,” by Jacob T. Carson, Michael A. Gorman, and Ronald P. Cocchi, filed Jan. 13, 2017, all of which applications are hereby incorporated by reference herein.
- The present invention relates to systems and methods for securely providing media programs and other information to subscribers via a black box Security Provider Programming system, and in particular to a system and method for securely providing data for use by a hardware device of a receiver for conditional access.
- The provision of information such as media programs to remote consumers is well known in the art. Such provision may be accomplished via terrestrial or satellite broadcast, cable, closed circuit, or Internet transmission to consumer electronics (CE) devices at the consumer's home or office.
- A common problem associated with such transmission is assuring that the reception of such information is limited to authorized end-users. This problem can be solved via the use of encryption and decryption operations performed by devices with appropriate security functionality. For example, it is well known to encrypt media programs before transmission to CE devices with electronics and processing that permits the encrypted media programs to be decrypted and presented to only authorized users.
- To implement this functionality, the CE products typically include keys, software, and other data. Since such data is of value to unauthorized users as well, CE companies need a way to protect this valuable information.
- Typically, this has required the production of CE devices with special integrated circuits (or chips) with security features enabled and information needed to perform the security functions loaded into chip memory. Such chips can include System on Chips (SOC), which comprise the primary Central Processing Unit (CPU) of the CE device (which may also include secondary processors, security processors, custom Application Specific Integrated Circuits (ASICSs), etc.) or other chip devices that perform the processing of commands within a CE device. Conditional Access providers provide content protection schemes to secure broadcast content is paid for when viewed by subscribers. Problems arise when the content protect schemes are either compromised or implemented in a man which security holes or flaws can be exploited by attacker. The cost to design, manufacturer and distribute these CE devices is extremely expensive. Significant savings can be achieved if a service provider or broadcaster can re-purpose existing CE devices by replacing the conditional access (CA) system used with CE devices that are in the field (distributed to or in use by customers). As an alternative to switching CA systems, the CE device can be provisioned to support separate and cryptographically isolate CA systems during manufacture. This permits the security provided by another
CA vendor 108B to be used in the event the security provided by another one of theCA vendors 108B and co-existing on thechip 114, is compromised. - What is needed is a system and method for providing a security infrastructure that permits the programming of unique security functions in standardized chip designs and enables switching among different and existing CA systems deployed in CE devices. The present invention satisfies that need.
- To address the requirements described above, the present invention discloses a method of controlling a group of the client devices to switch at least one client device of the group of client devices from a first conditional access system to a second conditional access system via a plurality of client device signaling messages, each comprising at least one of a plurality of action codes and payload data. In one embodiment, the method, which can be applied to a system of a plurality of client devices for receiving media programs from a service providers, comprises generating a group identifier identifying the group of the client devices, transmitting a first client device signaling message having the group identifier only to each client device of the identified group of client devices, the group identifier for storage in each client device of the identified group of client devices in non-volatile memory, and transmitting a second client device signaling message to plurality of client devices, the second client device message comprising the group identifier and signaling a switch of each of the identified group of client devices from the first conditional access system to the second conditional access system.
- Hence, disclosed herein is a system and method that
service provider 102 or broadcaster to utilize high security chip device features to enable in-field switching of CA vendors and/or co-existence of CA vendors for fielded CE Devices. This is possible in part, due to a set of base security features that can be integrated into commercially available integrated circuitry for use in CE products, yet customizable for many different applications. Use of black box programmed secure silicon features enables service providers or broadcasters to switch CA vendors or for different CA systems from multiple vendors to co-exist in CE devices by cryptographically isolating key sets allocated to and used by independent CA vendors. - This enables strong and unique encryption of sensitive data (such as HDCP and/or CI+keys) that can be logically associated with data in individual chip devices, and allows CE device manufacturers to prevent unauthorized code being run on the CE devices and protects provisioned data from both independent partners (i.e. CA providers) and attackers. Importantly, techniques and systems described herein also allow chip device manufacturers to design and build chips that can be used by any one of a plurality of customers, service provider, or CA vendors.
- The system described herein also permits programming of unique secrets into the chip device at the chip manufacturing site and permits later allocation of these chip devices to any one of a number of potential CE device manufacturers and/or CA vendors. Chip device programming can also occur at the packaging or product manufacturing facility by execution of an in-field programming sequence on the chip device.
- A method for unlocking a hardware device is also disclosed. In one embodiment, the method comprises the steps of transmitting a product provisioning key (PPK) encrypted according to a secret value (SV) (ESV[PPK]) from a first entity to a second entity for secure storage in a hardware device; receiving a customer validation code (CVC) from the second entity, the (CVC) computed in the hardware device from the encrypted product provisioning key ESV[PPK]; receiving an unlock request comprising the customer validation code (CVC) and a hardware unique identifier (PID) in the first entity from the second entity; computing an expected customer validation code (CVC) in the first entity from the secret value (SV) and the product provisioning key (PPK); and transmitting data unlocking the hardware device if the expected customer validation code (CVC) computed by the first entity matches the received customer validation code from the second entity.
- The keys and programming infrastructure summarized above as provided by an independent security provider enables fielded CE devices to change conditional access vendors giving the service provider or broadcaster more flexibility in managing their business. Enabling the ability to change conditional access vendors in fielded CE devices can result in saving the service provider a significant capital investment. The savings are realized by using the provided vendor independent security architecture and downloading a new software image containing an alternate conditional access vendor application without having to replace fielded CE devices.
- Referring now to the drawings in which like reference numbers represent corresponding parts throughout:
-
FIG. 1A is a diagram of selected architectural entities described in this disclosure; -
FIG. 1B is a diagram of an exemplary chip; -
FIG. 2 illustrates the customer product differentiator field and signed hash block used to verify third party customer input data for fielded SOCs; -
FIG. 3 illustrates the Boot ROM signature check over the code section enabling insertion of a CA vendor Public RSA key in a fielded SOC; -
FIG. 4A illustrates use of a Secret Value stored in hardware to protect a given CA vendor customer's common block of data or key; -
FIG. 4B illustrates use of a Secret Value and Product Provisioning Key both stored in hardware to protect a CA vendor's common block of data or key; -
FIG. 5A is a diagram presenting illustrative method steps that can be used to enable encryption of sensitive code or data and provide it to an independent CA vendors or untrusted consumer electronics (CE) device manufacturer for provisioning; -
FIG. 5B is a diagram illustrating use of a product provisioning key and secret value stored in hardware to protect a CA vendors' common block of data or key enabling in-field insertion of a secret value post SOC manufacturing; -
FIG. 6 is a diagram of one embodiment of the product identifier (PID) described above; -
FIG. 7 illustrates the boot process, image signing and RSA public key authentication for over the air updates; -
FIG. 8A is a diagram illustrating exemplary method steps that can be used to deliver the unlocking data; -
FIG. 8B illustrates a more specific example of the calculation and distribution of customer validation data by theCE source 108 after thechip 114 is manufactured; -
FIG. 9 is a diagram illustrating exemplary method steps for controlling a group of client devices to switch from a first CAS to a second CAS via a plurality of client device signaling messages; -
FIG. 10 is a diagram illustrating exemplary operations performed by the client devices in receiving and handling the first client device message and the second client device message; -
FIGS. 11-12 illustrate the operations presented inFIGS. 9-10 in greater detail; and -
FIG. 13 illustrates an exemplary computer system that could be used to implement the present invention. - In the following description, reference is made to the accompanying drawings which form a part hereof, and which is shown, by way of illustration, several embodiments of the present invention. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.
- This disclosure describes a system and method that allows third parties to provide set top boxes with advanced security features that (1) allow the signing of a customer's public key, (2) allow programming of chips with secret keys at chip manufacturing facility and (3) provide service providers a method to independently allocate those secret keys to security vendors when the CE device is in the field.
-
FIG. 1A is a diagram of selected architectural entities described in this disclosure. They include aservice provider 102, achip manufacturer 104, asecurity provider 106, a third party vendor(s) 108 and subscriber(s) 110. Theservice provider 102 transmits media programs and information to consumer electronics (CE) device(s) 112 that are deployed tosubscribers 110. TheCE device 112 presents the media programs to thesubscribers 110. TheCE device 112 can include devices such as set-top boxes (STBs) integrated receiver/decoders (IRDs) portable CE devices such as cellphones or personal data assistants (PDAs), laptop computers, tablet computers, and desktop computers. Any device with the required processing and memory capacity having the proper programming or hardware can be used as a CE device. An exemplary IRD is disclosed in U.S. Pat. No. 6,701,528, which is hereby incorporated by reference herein. - To assure that only authorized
subscribers 110 receive the media programs and information, theCE devices 112 perform security functions that are implemented at least in part using hardware processing/memory devices 114 (hereinafter alternatively referred to as chips) that are produced bychip manufacturer 104. For example, the transport module of the IRD disclosed in U.S. Pat. No. 6,701,528, is typically implemented by a chip. -
FIG. 1B is a diagram of anexemplary chip 114. Thechip 114 comprisesmemory 152 communicatively coupled to a processor orCPU 150. Thememory 152 stores instructions and/or data such as keys that are used to implement the conditional access functionality of theCE device 112. Thememory 152 may include read only memory (ROM) 152A, one-time-programmable memory (OTP) 152B, andflash memory 152C. Thechip 114 may also comprise aconfiguration portion 154, which may include a series offuses 156A-156C and/orflags 158A-156B. The flags 158 may also be reflected by values in thememory 152. The fuses 156 are irreversibly activated by thechip manufacturer 104 to implementparticular chip 114 functionality. For example, activation offuse 156A may activate a triple data encryption standard (DES) functional capability of thechip 114, whilefuse 156B may activate an RSA encryption functionality. - The
CE devices 112 are manufactured by aCE source 108. In one embodiment, theCE source 108 is defined to include aparticular CE manufacturer 108A that is responsible for the manufacture of aCE device 112 having hardware and software capable of implementing the CA functions allocated to theCE device 112 by aparticular CA vendor 108B, which provides the instructions and data (for example, software and keys) that are used by theCE device 112 hardware to implement the CA functions required for the CA system used by theservice provider 102. Aparticular CE source 108 is identified by a particular CE manufacturer's 108A product used with a particular CA system fromCA vendor 108B used with theCE device 112. For purposes of the discussion below, when thesame CE device 112 is used with the instructions and data (or smart card implementing some or all of the instructions and data) from twodifferent CA vendors 108B, this represents twodistinct CA sources 108 - In one embodiment, the
CE device 112 hardware is capable of performing the CA functions allocated to theCE device 112 formultiple CA vendors 108B at the same time. For example, a first CA vendor 108B1 (CA vendor 1) may define a CA system that allocates a first set of CA functions to theCE device 112, and a second CA vendor 108B2 (CA vendor 2) may define a second CA system that allocates a second set of CA functions at least partially different than the first set of functions to theCE device 112. TheCE device 112 may support both CA systems by storing instructions and data that allow the CE device hardware to perform the CA functions allocated to theCE device 112 in both the first CA system and the second CA system. Thus, using the CA functionality provided by both the first CA vendor 108B1 and the second CA vendor 108B2, the fieldedCE device 112 may be capable of performing the CA functions needed to receive and decrypt media programs and data transmitted by two different service providers 102 (for example, DIRECTV AND ECHOSTAR). - The
CE device 112 hardware may also support the replacement or substitution of one set of allocated CA functions for another set of allocated functions. For example, rather than support both the first set and the second set of allocated CA functions, theCE device 112 hardware may be configured such that a first set of allocated CA functions is automatically disabled when the second set of allocated CA functions are enabled. This would allow, for example, a receiver initially configured to receive media programs from afirst service provider 102 to be de-configured from receiving such programs, and to instead receive media programs from asecond service provider 102. Or, thefirst service provider 102 could desire a change its content protection services from its initial CA vendor 108B1 to those provided by a second CA vendor 108B2. - In another embodiment, the
CE device source 108 may also include one ormore CA vendors 108B that are architectural entities separate from theCE manufacturer 108A. For example, theCE device 112 may employ asmart card 114′ (for example, as shown by the access card of FIG. 2 of U.S. Pat. No. 6,701,528) or other removable security device having security functions defined by theCA vendor 108B. TheCA vendor 108B may manufacture and provide thissecurity device 114′ to theCE manufacturer 108A for ultimate provision to the subscriber(s) 110 with theCE device 112. - The
CE source 108 may acceptchips 114 from thechip manufacturer 104 and install them into theCE device 112. As described below, the present invention allows thechips 114 to be a standard design, yet uniquely and remotely programmable so as to be useful forCE devices 112 fromdifferent CE manufacturers 108A, and that can perform the allocated CA functionality for multiple CA systems enabled bydifferent CA vendors 108B and used bydifferent service providers 102. - In one embodiment, the
chips 114 are programmed via use of ablack box 116 provided by a thirdparty security provider 106. Theblack box 116, as the name implies, is a device that performs a transformation of data such as code or keys, without revealing how the transformation is performed or disclosing the data. The use of theblack box 116 in this instance, allows thesecurity provider 106 to program instructions and/or data into thechip 114 at the chip manufacturer's facility and under the control of thechip manufacturer 104 without exposing that information and/or data itself to thechip manufacturer 104. - Data from the
security provider 106 or theservice provider 102 may also be programmed into thechip 114 at theCE source 108 or thesubscriber 110 location using the techniques described below. - A customer product differentiator, somewhat analogous to a customer number, is used by the
security provider 106 and/or thechip manufacturer 104 to identify a customer specific configuration of aspecific chip 114 for the functions to be performed by theCE Device 112 from aparticular CE Source 108. The customer product differentiator (CPD 202) may be assigned to aparticular CE Source 108 orservice provider 102, for example, PANASONIC, DIRECTV or ECHOSTAR. Further, asingle service provider 102 orCE source 108 may have different CPDs for products that are used in different markets if those products require chips that implement different security functions. In one embodiment, the customer product differentiator comprises a bit customer product differentiator (CPD 202) represented by a 32 bit field. -
FIG. 2 is a diagram illustrating the use of theCPD 202. A customer product differentiator orCPD field 202 is generated and used with a signedhash block 210 to verifyCE source 108 input data before that data is used in fielded chips 114 (i.e. deployed in fieldedCE devices 112 installed atsubscriber 110 locations). Thesecurity provider 106 uses theCPD 202 field as part of an input to fixchip 114 security data received from the CE source 108 (such as a specific flash-basedCE source 108 public RSA key) to a given value. Optionally to further increase security, the address location for a flash-based third-party public RSA key and/or theCPD 202 can also be used fix input data for a givenCE source 108 and incorporated into the signedhash block 210. - This process can be implemented as follows. In
block 200, the public RSA key of thesecurity provider 106 is stored inROM 152A at the mask level orOTP 152B using theblack box 116. Customer-specific data 208 is generated by combining theCPD 202 with apublic key 201 of theCE source 108 and optional chip configuration information, as shown inblock 206. - Chip configuration information may vary according to the CA functions to be implemented by the
chip 114 in theCE device 112. For example, aparticular chip 114 may have the ability to implement a plurality of encryption/decryption schemes, depending on the setting of internal flags of the activation of internal fuses 156. Thechip 114 configuration information may describe the enabled functionality of thechip 114 by indicating, for example, which flags are set and/or which fuses 156 are activated. - Typically, the
above combination operation 206 is performed by thesecurity provider 106. In one embodiment, theCPD field 202 is assigned by thesecurity provider 106 and the combining operation ofblock 206 is a hash operation. The result isCE source 108data 208 that is unique and specific to thatCE source 108 and customer product. This data may be stored in a map which controls the activation of fuses 156. - In
block 210, the customer-specific data 208 generated above is signed with a private key of thesecurity provider 106 KprSP. In blocks 212 and 214, this signed combination and the customer product differentiator orCPD 202 is provided to theCE source 108. TheCE source 108 writes the signedcustomer data 208 and the customer product differentiator orCPD 202 to amemory 152 of thechip 114. Thecustomer data 208 signed with the security provider's 106 private RSA key is also securely stored at theCE source 108 site for use in the generation of future customer operations. - In blocks 216-218, the
CE source 108 writes their CE source public key (KpuCE) into amemory 152 of thechip 114 and also writes an image of theCE device 112 boot code signed by the private key of theCE source 108 into memory 152 c of thechip 114. Boot code comprises coded instructions that are verified and executed automatically when aCE device 112 is powered up. - The
chip 114 is thereafter installed into thecustomer device 112 by theCE manufacturer 108A, and provided to thesubscriber 110 for use. When thecustomer device 112 andchip 114 are powered up, aboot code 314 is verified, then executed by thechip 114, as further described with reference toFIG. 3 . - Continuing with the operations illustrated in
FIG. 2 , thesecurity provider 106 generates the signedhash block 208 over the customer-specific data using thechip 114 configuration (provided in block 201), the CE source's public RSA key, and theCPD field 202. TheCE source 108 can store the signedhash CPD field 202 in one time programmable (OTP)memory 152B location of thechip 114 as shown inblock 214, however, theCPD 202 could reside in flash memory for example in cases where there is not enough OTP or thechip 114 does not support OTP. If theCE source 108 or other entity were to alter theCPD field 202 or the CE source's public RSA key, then the RSA signature validation described below and illustrated inblocks chip 114 will not completely execute the boot code instructions, and will chip 114 andCE device 112 will be otherwise unusable. This is further described below. - The security provider's public RSA key is embedded in Read Only Memory (ROM) 152A or One Time Programmable memory (OTP) 152B within the
chip 114 as described below with reference toFIG. 3 . This serves as the hardware root of trust in thechip 114. - U.S. Patent Publication 2007/0180464, entitled “Method and System for Restricting use of Data in a Circuit,” (hereby incorporated by reference herein) discloses a method for checking the signature of boot code stored in ROM. These techniques can be extended to support code protection as discussed herein.
- The
security provider 106 supplies a 2048 bit RSA public key that is stored in aROM 152A of thechip 114 or anOTP bank 152B within thechip 114, as shown inblock 200. - An Elliptical Curve Cryptography (ECC) key could also be used to perform asymmetric cryptographic operations in a similar manner to which is described below using RSA. Public key storage in a
ROM 152A of thechip 114 is preferred and is the most secure location because it cannot be changed in the field, however, storage as data in theOTP 152B still provides a hardware root of trust. This can be implemented by programming thechip 114 using theblack box 116 provided by thesecurity provider 106 duringchip 114 manufacturing. - The
chip 114 may also include boot code that is used upon power up to boot or start thechip 114. In one embodiment, this boot code is signed by the CE source's private key, before storage in thechip 114 so as to permit later validation before further processing as described below. -
FIG. 3 is a diagram presenting an exemplary embodiment of how the boot code image can be verified before it is executed by thechip 114. When theCE device 112 is powered up, a boot sequence is initiated by thechip 114, as shown inblocks - Recall that the signed hash (which was generated with the CE source's public RSA key and the CPD) was stored in
block 214 and the CE Source's public key was stored in thechip 114 inblock 216. That hash can be recomputed in thechip 114 using theCPD 202 that was stored in thechip 114 inblock 214, the CE Source public RSA key stored in the chip inblock 216, and the chip configuration data. Further, the signature over the hash, i.e. the signed hash, stored inblock 214 can be verified using the security provider's 106 public key which is retrieved from theROM 152A orOTP 152B of thechip 114. The hash will only be equivalent to the recomputed hash if the CE source's public RSA key written inblock 216 is equivalent to the CE source's public RSA key used to generate the hash inblock 206 are equivalent. - If the comparison indicates that the CE source's public key is not valid, processing stops and the
chip 114 will fail to exit the reset mode. If the comparison indicates that the CE source's public key is valid, processing is passed to block 314 where the boot sequence is verified using the verified CE source's public key. - If the boot sequence is verified, the boot code image is verified as shown in blocks 314-318 and the boot code is executed. If the boot sequence is not verified,
chip 114 will again fail to exit the reset mode and will be non-operational. - In the above operations, a hardware security co-processor built into the
chip 114 can read the CE source's public RSA key (which was stored in block 216) from memory such as a flash location in thechip 114 and use it to verify the stored signature for the customer application code that has been calculated over the entire section of customer application code to be downloaded for execution. Thechip 114 memory location from which the security provider's 106 public RSA key is read may be fuse 156 locked to aspecific ROM 152A orOTP 152B key by thechip manufacturer 104, that is, at electronic wafer sort or when sensitive immutable data is stored in thechip 114 by theblack box 116 provided to thechip manufacturer 104 by thesecurity provider 106. In one embodiment, once the location of the security provider's 106public RSA key 200 has been selected, it cannot be changed in the field. Thissecurity provider 106 public RSA key is used as the chip's hardware root of trust in code signing, thereby, enabling use of atCE source 108 orCA vendor 108B public RSA key. - The main processor or central processing unit (CPU) 150 of the
chip 114 incorporated into theCE device 112 may be held in a reset mode until the boot code check of blocks 314-318 is completed, thereby, eliminating the possibility of executing unknown user or malicious boot code. - Typically, the
chip 114 must support the ability to extend the public ROM/OTP keys held by thesecurity provider 106 toCE source 108—defined RSA keys by checking a signed hash stored in thechip 114. This enables a first entity, such as thesecurity provider 106, to sign the public RSA keys of the second entity (such as theCE source 108—defined public RSA keys) and allows validation of the CE source's 108 public RSA key based on the security of the root of trust in the security provider's public RSA key stored in ROM/OTP 152A/152B. Preferably, this hardware-based validation process occurs in a secure manner that is not modifiable or accessible by other elements in theCE device 112 such as a general-purpose processor 904A or general purpose processor 904B. This process is typically controlled by a hardware state machine or performed on a separate embedded security co-processor executing from a private secure memory location. - The signed
hash 210 used to validate the CE source's public RSA key incorporate theCPD 202 field assigned by the first entity (the security provider 106) to properly bind the CE Source's public RSA key to a specific party, that is, theCE Source 108 to which theCPD 202 was assigned. Incorporating additional information such as the address of thememory 152 location of where theCPD 202 value and/or CE source's public RSA are stored further limits potential attacks by fixing values to particular areas in a map of thememory 152 of thechip 114. - Having either the
CPD field 202 or CPD address field incorporated into the signedhash 210 also enables theCE source 108 to assign analternate CPD field 202 and/or CPD address, either of which enables switching from a first CA vendor 108B1 to a second CA vendor 108B2 as discussed below. - Incorporating either the
CPD field 202 or CPD address field into the signed hash enables theCE Source 108 to revoke a previously assignedCE source 108 public RSA key by changing the value of theCPD 202 itself, assigning a new CE source public RSA key for anew CE source 108 and sending a new software image as is also discussed below. The previously signed CE source public RSA key will no longer be successfully validated by the security provider's signedhash 210 since the signed hash incorporates theold CPD value 202, which will no longer pass the verification process ofblocks FIG. 3 since theCPD value 202 has changed, thereby, revoking the signedhash 210 and previous CE source public RSA key. The previous CE source public RSA key could be used once again if thesecurity provider 106 provides another signedhash 210 using the old CE source public RSA key, anold CPD value 202 with a newi CPD address because the new address could used to store the previously old CPD value. - The generation of the signed
hash 210 is typically accomplished using the security providers' private RSA key and the chip manufacturer's supplied tool chain at the security provider's 106 trusted facility. Thesecurity provider 106 may generate the signedhash 210 through use of publicly available tools such as OpenSSL or custom tools developed by thesecurity provider 106. The signedhash 210 validation in thechip 114 occurs using the security provider's public RSA key stored in the ROM/OTP of thechip 114. - As an alternative to switching CA systems, a broadcaster or
service provider 102 may decide to enable the CA functionality of multiple CA systems provided by multipledistinct CA vendors 108B (e.g. CA vendor 108B1 and CA vendor 108B2) to be implemented in asingle CE device 112. In this case, the broadcaster orservice provider 102 may assign asingle CPD 202 and CE Source public RSA key 201 to verify aCE device 112 boot image that combines the security functionality of both CA vendors 108B1 and 108B2. In this case, the boot code may combine and integrate two distinct portions, a first portion for the first CA vendor 108B1, and a second portion for the second CA vendor 108B2. Sincecurrent chip 114 designs cannot independently verify the signed hashes for two distinct boot code regions with two different public keys, a common CE source public RSA key 201 can used to verify the combined boot code portion containing the boot sequence for both CA vendors 108B1 and 108B2. Infuture chip 114 designs that can do so, a separate CA vendor public RSA key 201 can be used for each boot code portion. - The signed
hash 210 may be incorporated in theboot flash image 152C by theCE source 108 as shown in 316 using tools provided by thechip manufacturer 104 once theCE Source 108 has finalized it own boot code. The signedhash 210 is validated in thechip 114 each time thechip 114 is powered up and before thechip 114 exits the reset mode. The precise boot process may bechip 114—specific as defined by thechip manufacturer 104. - The
chip 114 may support several security provider RSA public keys, however, the number of production ROM locations available in thechip 114 is typically limited due to physical storage sizing and timing for the availability of the data (i.e. the security provider's public RSA key placed in ROM must be available at the time of the initial chip design). As described above, one of the unique features of the present invention is the ability for astandard chip 114 to be used with a multiplicity ofdifferent CE sources 108, service providers 120 and/orCA vendors 108B, with the security features customized for eachCE source 108 and/or application. Typically, there are not enough ROM hardware slots in thechip 114 for all of thepossible CE sources 108 to have their security data embedded in the ROM for theproduction chip 114. Also, since allCE sources 108 are typically not known during the development phase of thechip 114, the security data of everyCE source 108 cannot be incorporated into the more secure production ROM during the development stage. The techniques discussed below extend the public RSA key of thesecurity provider 106 as the hardware root of trust tomultiple CE sources 108,service providers 102 and/orCA vendors 108B to enable in-field switching and or augmentation of CA functions implemented in thechip 114 and without the use of ablack box 116. Instead, this programming system takes a generically manufacturedchip 114 and binds a specific flash memory-basedCE source 108—provided public RSA key 201 to a particular customer such as theCE Source 108 orservice provider 102 utilizing the security provider's ROM/OTP-based public RSA key 200 as the hardware root of trust. - A secret value (SV) 451 programmed by the
security provider 106 can be stored in thechip 114OTP memory 152B, and thatSV 451 can be used to indirectly modify or manipulate sensitive data that is externally supplied to thechip 114. Such sensitive data can be supplied from theservice provider 102 via a broadcast, a thirdparty CA vendor 108B, a USB port, Internet server, DVD or similar means. -
FIG. 4A andFIG. 4B are diagrams illustrating how data (D) can be securely received from one ormore CA vendors 108B and can be provided for use by thechip 114 in aCE device 112. The data is protected from access byunauthorized CA vendors 108B and potential attackers. Such data (D) may be a key for decrypting media programs transmitted by theservice provider 102 using theCE device 112, a common code block ofdata 408 including instructions for execution by theCE device 112, or similar data. - A customer global key (CGK) 402 is generated or assigned by a first entity such as the
security provider 106 and transmitted to a second entity such as theCE source 108 or a first CA vendor 108B1. The data (D) 408 of interest is encrypted according to the customerglobal key 402 provided by thesecurity provider 106 to produce encrypted data ECGK[D] as shown inblock 410. In a third party black box programming architecture performed by thesecurity provider 106, this encryption may be performed, for example, by the second entity orCE source 108 orCA vendor 108B. Thesecurity provider 106 may select the CGK uniquely for eachCE source 108 orCA vendor 108B. Since the CGK is unique to eachCA Source 108A/CA Vendor 108B, sensitive intellectual property such as code or data can cryptographically isolated and protected fromsuccessive CA vendors 108B in case switching of CA systems or vendors is desired. Such CA systems fromCA vendors 108B can concurrently be implemented in theCE device 112. - In
block 404, the customer global key (CGK) 402 is also encrypted according to a secret value (SV) key by the security provider 106 (or CE source 108) to produce an encrypted customer global key ESV[CGK] 406. In one embodiment, eachchip 114 has a unique SV key 451, and thesecurity provider 106 orCE source 108 encrypts the CGK uniquely for eachchip 114 using that chip's unique SV key 451. - The encrypted customer global key ESV[CGK] 406 and the encrypted data ECGK[Data] 412 are then transmitted or distributed to the
CE device 112 and thechip 114, where it is received and processed, as shown inblocks chip 114 to reproduce the customer global key 403 and the encrypted data ECGK[Data] is decrypted with the reproduced customer global key CGK to reproduce the data (D), as shown inblocks CE device 112 using the chip 114). In one embodiment, these decryption operations are hardware controlled and not accessible or modifiable by theCE device 112. It is important to note that the CGK is not shared betweenpotential CA vendors 108B and that this cryptographic isolation is maintained in thechip 114 by encrypting the CGK with the SV key that is unique to eachchip 114. - When needed, the CGK may again be decrypted using the SV key within the key ladder (a secure processing engine that handles security keys in the
chip 114 without exposing such secrets to the main CPU or exporting key material for access by software) with the results of this decryption unavailable to the software of the main CPU, thereby supporting both CA switching and CA co-existence in theCE device 112. - In
block 420, the decryptedCGK 402 is used to decrypt the ECGK[Data] 412, resulting in theData 408, which is used by thechip 114 to perform security related functions such as decrypting the media program. The decryptedData 408 can also be a key used to further decrypt the broadcast content or a common block of code/data, as shown inblock 422. If the operations ofblocks FIG. 4A . The foregoing operations can be used to transmit data from a second CA Vendor 108B2 as well. -
FIG. 4B shows another embodiment of how to securely distribute data from theservice provider 102 orCA vendor 108B. In this embodiment, theCGK 402 remains unique to eachCA vendor 108B and cryptographic isolation is maintained in thechip 114 by use of a product provisioning key (PPK) 453 that is not shared with anyother CA vendor 108B or third party. When needed, theCGK 402 is decrypted with thePPK 453 within the chip's 114 secure key processing engine that handles content protection keys, the key ladder, whose results are not available to software of the main processor of thechip 114, thereby supporting switching between CA systems (which may be supplied bydifferent CA vendors 108B) co-existing in theCE device 112. Support for CA switching and CA co-existence is discussed in detail in the sections below. - The
security provider 106 generates a secret value (SV) 451 that is unique to eachchip 114 and a product provisioning key (PPK) 453 that is unique to aparticular chip 114 design or model, but not unique to aparticular chip 114. ThePPK 453 could be changed for a given number ofchips 114 programmed by theblack box 116 or manufactured for a specific period of time. TheSV 451 is programmed into the chip, as shown. Further, thePPK 453 encrypted by theSV 451 is also generated and programmed into thechip 114. These programming operations are performed by thechip manufacturer 104 using theblack box 116 provided to thechip manufacturer 104 by thesecurity provider 106. New keys are periodically loaded into theblack box 116 which resides at thechip manufacturer 104 by encrypted DVDs or USB drive images created by thesecurity provider 106 at their secure facility. - A customer global key (CGK) 402 is generated by a first entity such as the
security provider 106 and transmitted to a second entity such as theCE source 108 orCA vendor 108B. The data (D) 408 is encrypted according to the customerglobal key 402 to produce encrypted data ECGK[D] as shown inblock 460. The encryption of the data (D) may be performed, for example, by the second entity such as theCE source 108 orCA vendor 108B. - As shown in
block 457, the customer global key (CGK) 402 assigned by thesecurity provider 106 is also encrypted according to a product provisioning key (PPK) 453 by thesecurity provider 106, as shown inblock 457 to produce an encrypted customer global key EPPK[CGK] 459. Thesecurity provider 106 selects theCGK 402 uniquely for eachCE source 108/CA vendor 108B combination, thus enabling thesecurity provider 106 to support many third party CA Vendors 108B and/orCE Sources 108 usingchips 114 frommultiple chip manufacturers 104 while cryptographically isolating theCGK 402 intended for use by one CA Vendor 108B1 from that used by another CA Vendor 108B2 and potential attackers by use of thePPK 453. - The encrypted customer global key EPPK[CGK] 459 and the encrypted data ECGK[Data] 462 are then transmitted or distributed to the
CE device 112 and hence, thechip 114, where it is received and processed, as shown inblocks security provider 106 may transmit the encrypted customer global key EPPK[CGK] 459 to theCE source 108, and theCE source 108 may transmit both the encrypted customer global key EPPK[CGK] 459 and the encrypted data ECGK[Data] 462 to theCE device 112. - The
encrypted PPK 453 is recovered by decrypting ESV[PPK] that was programmed into thechip 114 using the SV programmed into the chip. This is shown inblock 467. The encrypted customer global key EPPK[CGK] 459 is decrypted according to the recoveredPPK 453 to reproduce the customer globalkey CGK 402 as shown in block 469 and the encrypted data ECGK[Data] is decrypted with the reproduced customer globalkey CGK 402 to reproduce thedata 408, as shown inblocks CE device 112 using the chip 114). In one embodiment, these decryption operations are hardware controlled and not accessible or modifiable by the chip's main processor or any other processor associated with theCE device 112. - If the operations in
blocks 469 or 470 fail, processing stops, as shown inFIG. 4B . - The decrypted
data 408 is typically data that is used by thechip 114 to perform security related functions. For example, the decrypteddata 408 can include a key used to decrypt the broadcast content or can be a common block of code/data for performing security related functions. The data may also comprise a media program decryption key also known as the control word (CW) and/or a pairing key (PK) that cryptographically binds theCE device 112 with an external device such as a smart card. - Secure Product Code-Data Provisioning by Arbitrary Third Party Customers
-
FIG. 5A is a diagram presenting illustrative method steps that can be used for the encryption of sensitive code or data to enable cryptographic separation of code and data fordifferent CA vendors 108B and CA co-existence. The encrypted block can be provided to an untrusted consumer electronics (CE)device manufacturer 108A for provisioning. - The hardware device such as a
chip 114 is received from a first entity such as thesecurity provider 106, wherein the hardware device has a securely stored SV key 451 and a product provisioning key (PPK) 453 encrypted by the SV key (ESV[PPK]), as shown inblock 502. ACGK 402 and the CGK encrypted according to the PPK 453 (EPPK[CGK] 459) is received from the first entity, as shown inblock 506. The Data is 408 encrypted according to the customer global key to produce encrypted data (ECGK[Data] 462), and the encrypted data ECGK[Data] 462 and hardware device are transmitted to a third party, as shown inblocks hardware device 114 via ablack box 116 the first entity. - The encrypted data ECGK[D] 462, the encrypted customer global key EPPK[CGK] 459, and the
hardware device 114 are received by the third party such as a CE Source orCA vendor 108B, as shown inblock 512, and installed into theCE device 112. - The encrypted product provisioning key ESV[PPK] 455 is then decrypted according to the SV key 451 stored in the
chip 114, as shown inblock 514. The encrypted customer global key EPPK[CGK] 459 is then decrypted according to the decryptedPPK 453 to produce the customer globalkey CGK 402, as shown inblock 516. Finally, the encrypted data ECGK[Data] 462 is decrypted according to the customer global key, as shown inblock 520. The data is then available for use. -
FIG. 5B is a diagram showing a specific example of the operations presented inFIG. 5A . Thesecurity provider 106 defines aPPK 453 and aSV 451, and programs thePPK 453 encrypted by the SV key 451 into thechip 114, as shown in blocks 552-554. This is accomplished via the security provider'sblack box 114 disposed at thechip manufacturer 114. Typically, thePPK 453 is held secret and not exported to software in theCE device 112, which would leave it vulnerable to unauthorized attack. - The
security provider 106 then provides each CE source 108 (i.e.CE manufacturer 108A/CA vendor 108B combination) with a different customer global key, CGK 402 (in one embodiment, a 128 bit value) and theCGK 402 encrypted with thePPK 453, referred to as the EPPK[CGK], as shown inblock 556. - The
CE source 108 encrypts their sensitive code/data (D) 408 with theCGK 402, as shown inblock 558, and provides the encrypted code/data to theCE manufacturer 108A during CE device manufacturing for the initial load, as shown inblock 560. Thechip 114 decrypts ESV[PPK] to obtain the PPK, and decrypts the EPPK[CGK] using the obtainedPPK 453 to produce theCGK 402, which is thereafter usable by the third party software application such asCE device 112 or a Set Top Box (STB) User Interface (UI) code executing in thechip 114, as shown in blocks 562-566. This allows theCGK 402 to be unique to each CE Source 108 (CE manufacturer 108A/CA Vendor 108B) combination without revealing the PPK external to thesecurity provider 106 and assures that theCGK 402 is known only to theCE Source 108 combination it is assigned to and no other party, excepting thesecurity provider 106, which assigned theCGK 402. This enables thePPK 453,CGK 402, andSV 451 fromdistinct CA vendors 108B to be used independently without exposing these keys or other data toother CA vendors 108B or third parties. As a consequence, different key sets (EPPK[CGK] 459 and CGK 402) can be allocated to eachCA vendor 108B. This permits a plurality ofCA vendors 108B to implement CA functionality on asingle chip 114. - Using this process, the CA vendor-
specific CGK 402, the protected code/data segment 408 and theglobal PPK 453 are not exposed outside the hardware controlled key ladder of thechip 114, which is the secure key processing engine that handles content protection keys. Again, thePPK 453 is held secret by thesecurity provider 106 and not given to thechip manufacturer 104 or any third party and theCGK 402 is never given a third party outside theCE source 108 orCA vendor 108B. - Among the advantages of this scheme include:
-
- (1) The
global chip 114 secret,PPK 453, is not given to thechip manufacturer 114 or any third party. It is held secure by only thesecurity provider 106; - (2) Each
CE source 108 orCE manufacturer 108A/CA vendor 108B combination receives their own provisioning key,CGK 402; and - (3) A
hardware chip 114—unique secret (SV 451) is used as the root of trust, and eachCA vendor 108B can be provided a different SV key when several chip unique SVs are provisioned in thechip 114 duringblack box 116 manufacturing.
- (1) The
- In one embodiment, the security provider's programming is tied to a
particular chip 114 identified by a public value referred to as a Product Identifier (PID) 600. Thechip 114 is uniquely programmed and provisioned by the security provider'sblack box 116 and tracked by the chip manufacturing process. The programming methodology taught in this disclosure enables the placement of secondary provisioning/activation server at third party CEproduct manufacturing facilities 108A to trackactual CE devices 112 produced and tested as opposed tochips 114 manufactured by theSOC chip manufacturer 104. This secondary provisioning/activation server can be located in the CE Source Operations ofFIGS. 4A and 4B . The programming methodology taught in this disclosure can automate reporting (atchip 114 fabrication andCE device 112 manufacturing) and less is hands-on for authorized third parties to track production ofCE devices 112 for accounting purposes such as determining royalty payments for software licensing. This solves a major problem forCE manufacturers 108A who may not be receiving accurate reports from suppliers or distributors for royalty payment purposes for licensed software or hardware that theCE manufacturer 108A is due. - The other significant advantage with this architecture is that security is enforced purely in hardware, which is significantly harder to defeat than software based implementations. Hardware based storage, which cannot be modified by a third party customer or an attacker, can be used for the security provider's Public RSA or security provider's ECC key,
CPD field 202, first secret value (SV) 451, one or more additional secret values (SV2, SV3, SV4, etc.), product identifier (PID) 600, JTAG unlock and ESV[PPK] 455 (the PPK encrypted with the SV). -
FIG. 6 is a diagram of one embodiment of the product identifier (PID) 114 described above. ThePID 600 identifies the specific chip 114 (not just thechip 114 configuration), and may be provided to theCE source 108 after thechip 114 is manufactured. In one embodiment, the PID is a 64 bit Public CE Device ID that is generated by thesecurity provider 106 and programmed in thechip 114 by theblack box 116. - The
security provider 106 ensures that thePIDs 600 are globally unique across all supported products, that is, acrossmultiple chip manufacturers 104 and multipleCE device manufacturers 108A. A system-wide unique value is needed to ensure that any manufacturedchip 114 can be allocated to any customer. - In one embodiment, the
PID 600 consists of achip manufacturer identifier 602, amodel number 604 that specifies the type ofchip 114 produced by thatchip manufacturer 104, areserve field 606 for future use and a monotonically increasingserial identifier 608 to uniquely identify thechip 114 within the product family and manufacturer. - The infrastructure provided by the
security provider 106 inchips 114 programmed by theblack box 116 allows for a broadcaster orservice provider 102 to change Conditional Access Systems (CAS) at its discretion. - In traditional systems for
large CA Vendors 108B, the Conditional Access provider held the root RSA key used to sign the boot loading code. The boot loader code, which is used by the Set Top Box (STB) orCE device 112 internal software to validate and authenticate a software download it has received, performs this critical verification step. This is to ensure an authorized party provides the code. If the boot loader cannot successfully validate the code, the code received in the download message will be rejected. - The public portion of an RSA key root key is either part of the ROM mask set of the
chip 114 or it is programmed into a secure portion of One Time Programmable (OTP) memory as part of the chip manufacturer's foundry process. This key can be used by the security infrastructure of thechip 114 to authenticate the download, which has been signed with the corresponding private key section of the programmed RSA key. If the signedhash 210 cannot be validated as shown inFIG. 3 , then the public RSA key verified in 310 is not correct or does not match with the public portion of the RSA key (either 200 or 201), thechip 114 will not come out of reset or will not continue with its operations, depending on the security rules of thechip 114. - In the past, this RSA key signing and authentication process was held by the Conditional Access (CA)
vendor 108B, which could block the broadcaster orservice provider 102 from performing downloads to the fieldedCE device 112 simply by not signing the code. If a broadcaster orservice provider 102 wanted to changeCA vendors 108B and did not get the ability to sign the code from theoriginating CA vendor 108B, then the only option available to the broadcaster orservice provider 102 would be to change out the infield CE device 112 with one that it did have the proper download capability. This is a prohibitively expensive proposition for most broadcaster orservice provider 102, which prevents them from running their system as they wish. - In this proposed infrastructure, the root public RSA key is extended by storing the CA vendor public RSA key in flash as shown in 216. In this case the CA vendor
public RSA key 201 is either held by the broadcaster/service provider 102, or by a trusted third party that acts as an escrow entity. This allows the broadcaster orservice provider 102 wide latitude in operating its system if it wishes to either change outCAS vendors 108B providers or to use multiple CAS systems in the field. - This
infield CA vendor 108B replacement scheme enabled by thesecurity provider 106 for its third party customers (i.e.service providers 102,CE source 108, and/orCA vendors 108B) utilizes a combination of thesecurity provider 106black box 116 programmed data and thesecurity provider 106 assigned keys given to the third party customer. Keys and programmed values that enable switching CA vendors include thesecurity provider 106 ROM RSA key, Product Provisioning Key (PPK) 453, the Customer Global Key (CGK) 402, third partycustomer RSA key 201 signed by the security provider's 106 private RSA key 210, the Customer Product Differentiator (CPD) 202, and one or more Secret Value (SV)keys 451. - Each
chip 114 contains a unique public identifier (the PID) 600 and a private symmetric provisioning key (the Product Provisioning Key (PPK) 453). ThePID 600 can be freely shared with any third party while thePPK 453 is kept private by thesecurity provider 106 and is never released to any third party and/or Consumer Electronic (CE)Source 108. The JTAG password unlocks access to debug information and is only provided if theCE device 112 experiences an in field failure. - The
security provider 106black box 116 programs a series of Secret Values (SVs) 451 that are allocated to theindividual CE source 108 and/orCA vendors 108B as theCE source 108 orCA vendor 108B requires as a part of its conditional access system to secure content distribution. Ifmultiple SVs 451 are programmed by theservice provider 102 via thesecurity provider 106black box 116 and distributed to the field, the service provider may later elect to provide one or more of these SVs to anindividual CA vendor 108B when theCE device 112 is first used in the field or theservice provider 102 can chose to save one ormore SVs 451 for asubsequent CA vendor 108B switch for the fielded CE device at a later time. - These SV values 451 can both be provided by the
security provider 106, i.e. 2 or more keys, and held in escrow or given to the broadcaster orservice provider 102 to hold. Another option open to the broadcaster orservice provider 102 is for one of the SV values 451 to be provided by thesecurity provider 106 and the others provided by an external key source or someother CA vendor 108B. - This allows for the broadcaster or
service provider 102 to havemultiple CA vendors 108B operating in the field at the same time using one STB. This can be done so that the broadcaster orservice provider 102 can segregate their markets by broadcast methodology (i.e. Cable, Satellite distribution, IPTV, etc.), region (i.e. different areas of a particular City or Country, or Geographic Location such as the Asia-Pacific market), or content package (High Definition Programming, Sports or Premium content) or any other market segmentation as market forces dictate. - For each
CA vendor 108B, there is typically some type of code resident in theCE device 112, such as a Security Kernel, which is used to pass keys, perform certain housekeeping functions, etc. as deemed necessary by that vendor. Given that the broadcaster orservice provider 102 has control over the in field download via the publicRSA root key 201, it is a simple matter to update these Security Kernels in the field. - If the broadcaster or
service provider 102 knows in advance that one ormore CA vendors 108B may be operating on their network, the Security Kernels could be integrated into the “Golden Image” of theCE device 112 code at the manufacturing line, thus eliminating the need to do an in field download. - The broadcaster or
service provider 102 would then be able to use the appropriate CAS infrastructure by utilizing thespecific SV 451 and other associated keys for that vendor. Again, this type of flexibility is unprecedented in the Pay TV industry and is only possible utilizing thesecurity provider 106black box 116 programmed data and thesecurity provider 106 assigned keys given to the third party customer, (i.e.service providers 102,CE source 108, and/orCA vendors 108B). - The keys and programming infrastructure found in the
chip 114 as provided by anindependent security provider 106 enables the fielded Consumer Electronic (CE)device 112 to change conditional access (CA)vendors 108B (hereinafter alternatively referred to as conditional access system (CAS) vendors), thus giving theservice provider 102 or broadcaster more flexibility in managing their business. This can result in saving the service provider 102 a significant capital investment by using the provided security architecture (including thechip 114 and CE device 112) and downloading a new software containing analternate CA vendor 108B application without having to replace fieldedCE devices 112. - A
service provider 102 or broadcaster can switchCA vendors 108B in a legacy conditional access system without swapping fieldedCE devices 112 using the method specified herein. This in-field CA vendor 108B replacement scheme enabled by thesecurity provider 106 for its third party customers utilizes a combination ofblack box 116 programmed data andsecurity provider 106 assigned keys given to the third party customer (i.e.service providers 102,CE source 108, and/orCA vendors 108B). Keys and programmed values that enable switchingCA vendors 108B include thesecurity provider 106 ROM RSA key, PPK 543,CGK 402, third partycustomer RSA key 201 signed by the security provider's private RSA key KprSP (item 210),CPD 202, and one ormore SV keys 451. - The foregoing description of describes a system boot code can be securely installed, verified, and executed in the
CE device 112 and wherein data (D) used for conditional access can be securely provided to theCE device 112 for use in the conditional access system. The same procedures can be used to either provide additional conditional access functionality (e.g. to support a conditional access system provided by anotherCA vendor 108B) or to revoke the conditional access functionality of aCA vendor 108B and substitute that of anotherCA vendor 108B. Adding additional functionality to support anotherCA vendor 108B can be accomplished by the storage of additional security values, while revoking conditional access functionality of oneCA vendor 108B to substitute another can be accomplished by replacing previously installed security values with the security values for thenew CA vendor 108B. - For example, a
generic bootloader 706 and/or SOC security driver can be installed in the flash memory of the System On a Chip (SOC) 114 using the procedures shown inFIG. 2 andFIG. 3 instead of theCE source 108 specific orsecondary boot loader 710. Thisgeneric bootloader 706 and/or SOC security driver is capable of accepting a new customer flash application image for theCE device 112 and can authenticate a third party public RSA key 201 associated with thenew CA vendor 108B stored in thenew CE device 112 flash image as shown in blocks 302-312 ofFIG. 3 . - The
new CE device 112 application flash image includes: -
- A new third party RSA key (different from the previous third
party RSA key 201 ofFIG. 2 ), anew CPD 202 and a new EPPK[CGK] 459; - New customer flash conditional
access application code 316 from the same or anew CA vendor 108B with its own content protection scheme; - An optional
new CE device 112 application that potentially uses new conditional access application code to implement the conditional access system; and - The
security provider 106 defined code download and verification module will be included in the deployed software image.
- A new third party RSA key (different from the previous third
- When the
CE device 112 reboots after the successful download, the new CE device application flash image is authenticated as shown inFIG. 3 with the new signed third party RSA key as shown in 310,new CPD 202, andnew CA vendor 108B application, thereby, enabling thenew CA vendor 108B application to take control of theCE device 112 and provide content protection services for theservice provider 102. -
FIG. 7 shows a bootloader cascade beginning with thegeneric bootloader 706 authorizing thesecondary bootloader 710 supplied by a CAS provider that in turn authorizes a STB application. Thegeneric bootloader 706 is generally not replaced in the field. Thisbootloader 706 verifies Customer RSA key 201, i.e. Cust1 as shown in 708. Thegeneric bootloader 706 does not contain the CAS vendor's 108Bpublic RSA key 201. Thegeneric bootloader 706 needs to be able to point to a new Over-the-Air (OTA)image 716 provided by the CAS vendor and load this image if the new image passes RSA Signature verification fromFIG. 3 . Subsequent STB reboots will load the newCAS OTA image 716, which may contain a revisedsecondary bootloader 710. - A download verification module resident in the STB Application monitors and guides the download process shown in 714. The code needed to download and authenticate the
new CE Device 112 image is controlled by thesecurity provider 106 and the broadcaster/service provider 102. The download verification module shown in 714 must be incorporated into theSTB code image 716 to accept updates, validate updated image and re-launch the STB application. The download verification module shown in 714 assembles data segments of the encrypted image for theOTA update 716, verifies data integrity and assistsgeneric bootloader 706 in validating the signature. Following validation of the signature, theimage 716 is decrypted and made ready for re-launching the updatedCE Device 112 image. - Table I lists the data used by the
CE Source 108 and/orCA vendor 108B in their typical operation in providing a secure content distribution system for theirservice provider 102. -
TABLE I Typical keys and data fields used in providing a secure content distribution system Key and/or Security Field Name Resident in Who programs SP Public RSA ROM/OTP key ROM/ OTP SP 102 or (from 210) Chip Mfg. 104 Customer Public RSA key (Cust Flash CE Source 106 in Pub RSA Key) 201 field Customer Product Differentiator OTP CE Source 106 in (CPD) 202 field Hash of Customer Public RSA & Flash CE Source 108 in CPD (Hash) field Signed Hash of Customer RSA Flash CE Source 108 in key and Customer Product field Differentiator (Signed Hash) 210 Customer signature over signed Flash CE Source 108 in code (Cust Sig) 218 field One or more Secret Value (SV) OTP SP 102 by black Key(s) 451 box 116 or via SVinsertion Encrypted Product Provisioning Key OTP SP 102 by black (ESV[PPK]) 455 box 116Encrypted Customer Global Key Flash CE Source 108 in (EPPK[CGK]) 459 field Secret Value 2 (SV2) Key 451OTP CE Source 108 in field Product ID (PID) 600 OTP SP 102 by black box 116 JTAG unlock key OTP SP 102 by black box 116 - Table II shows what keys and data fields in a
particular CE device 112 are fixed (do not change) after a new software image containing an alternate conditional access vendor application has been downloaded and authenticated by thechip 114. -
TABLE II Fixed key and data fields when accepting a new software image for an alternate conditional access vendor application Fixed Keys/Security Fields for all downloaded images used in the CE Device 112SP Public RSA key (stored in ROM or OTP) (block 200) SV, SVCA2, SVCA3, SVCA4, . . . (programmed by black box) 451 ESV[PPK] 455 PID 600JTAG - The
PID 600 is a public identifier and can be freely shared with any third party. ThePPK 453 is kept private to thesecurity provider 106 and is never released to any third party and/or CE Source 108 (an encrypted version of the ESV[PPK] 455 is stored in thechip 114, via theblack box 116 as is the secret value (SV) 451 needed to decrypt the ESV[PPK] 455). The JTAG value is only provided if theCE device 112 experiences an in field failure. Table II also shows different values of theSV key 451. Thefirst value SV 451 is the value programmed by thesecurity provider 106 via theblack box 116 and is allocated to theindividual CE source 108 and/orCA vendors 108B as theCE source 108 orCA vendor 108B requires as a part of its conditional access system to secure content distribution. SVCA2 is distinguished fromSV2 451, which can be optionally programmed by the black box 116). Hence, ifmultiple SVs 451 are programmed by theservice provider 102 via theblack box 116 and distributed to the field, theservice provider 102 may later elect to provide one or more of these SVs 451 (e.g. SV) to anindividual CA vendor 108B when theCE device 112 is first used in the field or theservice provider 102 can chose to save one or more SVs 451 (SVCA2, SVCA3, SVCA4 . . . ) for asubsequent CA vendor 108B switch for the fieldedCE device 112 at a later time. - The downloaded STB image contains the switchable keys from Table III, i.e. the initial image loaded in the STB flash contains CA Vendor key set 0 as defined below:
-
- Cust Pub RSA Key0
- Hash0
- Signed Hash0
- Cust Sig0
- EPPK[CGK0]
- CA switch means that the new STB flash for the new STB application contains an image that has values for CA Vendor
key set 1. The Code Signing verification routine needs to reference these fields from the STB flash image. - Table III shows the new key and data fields that utilized when a new CE device image implements a switch from one
CA vendor 108B to anotherCA vendor 108B. -
TABLE III New Key and Data Fields Utilized in a CE Device After a Switch to a Different CA Vendor 108Bor Different Conditional Access System Keys/Security Downloadable Downloadable Downloadable Fields Keys/Security Keys/Security Keys/Security contained in Fields modified Fields modified Fields modified the initial in first CA in second CA in third CA image loaded provider switch provider switch provider switch into the CE image delivered image delivered image delivered Device at to the fielded CE to the fielded CE to the fielded CE Manufacturing Device Device Device SV1 SV2 SV3 SV4 Cust Pub RSA Cust Pub RSA Cust Pub RSA Cust Pub RSA Key0 Key1 Key2 Key3 (201) (201) (201) (201) CPD0 CPD1 CPD2 CPD3 (202) (202) (202) (202) Hash0 Hash1 Hash2 Hash3 Signed Hash0 Signed Hash1 Signed Hash2 Signed Hash3 (210) (210) (210) (210) Cust Sig0 Cust Sig1 Cust Sig2 Cust Sig3 (218) (218) (218) (218) EPPK[CGK0] EPPK[CGK1] EPPK[CGK2] EPPK[CGK3] (459) (459) (459) (459) - Each
CA vendor 108B switch results in the installation and use of a new Customer Public RSA key 201 (i.e. Cust Pub RSA Key1, Cust Pub RSA Key2, Cust Pub RSA Key3 in the Table III). Thesecurity provider 106 assigns eachnew CA vendor 108B a unique CPD 202 (i.e. CPD1, CPD2, CPD3 in Table III). Thesecurity provider 106 hashes the Customer Public RSA key 201 andCPD 202 producing unique hash values and signs each new hash with thesecurity providers 106 own Private key as requested by theservice provider 102. (i.e. Signed Hash1, Signed Hash2, Signed Hash3 in Table III). To optionally further increase security, the address location for the flash-based third-partypublic RSA key 201 and/or theCPD 202 can also be used fix input data for a givenCE source 108 and incorporated into the signedhash block 210. The secret values (SVs) 451 programmed by theblack box 116 during SOC manufacturing are allocated as determined by the service provider/broadcaster 102 orCE device 112 owner. In Table III adifferent SV value 451 is allocated to theCA vendor 108B after a switch is performed. - The
security provider 106 also assigns a new CGK 456 and generates the EPPK[CGK]459 for each switch to anew CA vendor 108B or different conditional access system. Upon a successful download and aCE device 112 reboot, thenew CE device 112application flash image 716 is authenticated with the new signed Third Party RSA key 210, new CPD (202), andnew CA 716 as shown invendor 108B applicationFIG. 3 . This enables thenew CA vendor 108B application to take control of theCE device 112 and provide content protection services for theservice provider 102 with the conditional access systemnew CA vendor 108B. - An existing CE vendor's 108B conditional access data can also be revoked. This is made possible by incorporating the
CPD 202 into the signedhash 210 to enable theCE source 108 to revoke a previously assignedCE source 108public RSA key 201. In this embodiment, theCE Source 108 provides a new public RSA key 201 to thesecurity provider 106. Thesecurity provider 106 assigns anew CPD 202 to be used with the new public RSA key 201, with thenew CPD 202 to be stored at the same address as theCPD 202 currently stored and used with the existingpublic RSA key 201. If the replacedCPD 202 was stored in OTP, then a few bits of thenew CPD 202 may be changed so that the physical address of theCPD 202 does not change. Thesecurity provider 106 returns a new signedhash 210 for the new CE sourcepublic RSA key 201 andnew CPD 202. TheCE source 108 transmits anew software image 716 to the CE device 112 (for example, by wireless means). The previously signed CE sourcepublic RSA 201 key will no longer be successfully validated by the security provider's signedhash 210 since the signed hash usesold CPD 202 value, which will no longer pass the verification process in blocks 304-312 ofFIG. 3 since theCPD 202 value has changed, thereby, revoking the signed hash and previous CE source public RSA key 201 in theCE Device 112. The previous CE source public RSA key 201 could be used once again if the security provider source provides another signedhash 210 using the old CE source public RSA key,old CPD value 202 with a new CPD address since theCPD value 202 at the old CPD address location has been changed. -
TABLE IV Provisioning for CA Co-Existence Keys/Security Fields Keys/Security Fields allocated to CA Vendor 1allocated to CA Vendor 2loaded into the CE Device at loaded into the CE Device at Manufacturing Manufacturing Cust Pub RSA Key0 201Cust Pub RSA Key0 201CPD0 202CPD0 202Hash0 Hash0 Signed Hash0 210Signed Hash0 210Cust Sig0 218 Cust Sig0 218 SV1 451SV2 451 EPPK[CGK1] 459 EPPK[CGK2] 459 - Table IV shows a provisioning example where two
CA vendors 108B can coexist in the same CE device. A common Customer private RSA key signs the final CE Device binary image containing theproduction code 716. TheCE Device 112 would verify the signature using the Cust Pub RSA Key0 shown in 708 contained in theimage 716 loaded during CE Device manufacturing or sent over the air. In this case the Customer who holds/generated the code signing RSA key 201 would be theCE Device 112 owner who is responsible for the overall operation of the STB or CE Device and the Co-existence of bothCA vendors 108B in the field. TheCE device 112 owner would be responsible for receiving the final binary images from the twoCA vendors 108B and making sure that theapplications 716 perform properly together. EachCA vendor 108B maintains its own Secret Value key 451 (SV1 and SV2 respectively) programmed by theblack box 116 during SOC manufacturing that protects content related items such as Control Words and subscription entitlements. EachCA vendor 108B also is provided with its own Customer Global Key 202 (CGK1 and CGK2 respectively) that is used to protect sensitive code and CE Device data contained in theapplication code image 716. CA Co-Existence works in asingle CE Device 112 because each CA vendor's 108B content protection mechanism is cryptographically protected and isolated against the other through the allocation of independent key sets (SV1/EPPK[CGK1] and SV2/EPPK[CGK2] respectively) programmed by theblack box 116. TheCA vendor 108B designs their unique content protection and distribution architecture based on these root keys resident in theCE device 112. Since the root key sets shown in Table IV are unique and separate for eachCA vendor 108B, encrypted subscription entitlements and control words can be delivered uniquely to theCE Device 112 without fear of them being manipulated or falsely created by theother CA vendor 108B. - In one embodiment,
service provider 102 uses a key to protect a Joint Test Action Group (JTAG) port on the chip that is used to obtain access to higher security areas of the chip 114 (e.g. the chip's internal states). The value for this key can be programmed by theblack box 116 duringchip 114 manufacturing. In one embodiment, the key is a 128-bit JTAG key. The JTAG key should be a 128-bit value. Smaller values JTAG key lengths are acceptable if there is a delay function between successive password unlock attempts. For adequate security, the key length should be at least 64 bits in length. Access to the JTAG port is gained when the password is supplied. This key cannot be exported to software. -
FIG. 8A is a diagram presenting exemplary method steps that can be used as a method for a first entity (service provider 106) to deliver JTAG data to unlock the hardware device orchip 114 to a second entity (CE source 108). Thechip 114 ownership by the second entity can be verified by the first entity if the second entity delivers an authentication value produced uniquely for eachchip 114 as recoded during the manufacturing process. There are numerous methods that can be employed several of which are identified here. -
FIG. 8A is a diagram illustrating exemplary method steps that can be used to deliver the unlocking data. As shown inblock 802, a product provisioning key that has been encrypted with thechip 114 uniquesecret value SV 451 is transmitted from the first entity (the service provider 102) to the second entity (CE source 108) for secure storage in thechip 114. In one embodiment, this is accomplished via theBlack box 116. Achip 114PID 600 is also stored in thechip 114. The chip is provided to the CE Source, which installs thechip 114 in aCE device 112, and provides theCE device 112 with thechip 114 to third parties, such as end users, as shown inblock 804. When the CE device wishes to unlock the hardware chip using JTAG or similar data, theCE source 108 and transmits, and theservice provider 102 receives an unlock request, as shown inblock 806. The unlock request comprises a customervalidation code CVC 862 that is computed by thechip 114 and reproducible in theservice provider 106 as well aschip 114 identifying information such as thePID 600. In one embodiment, theCVC 862 computed in the hardware device from the encrypted product provisioning key ESV[PPK] alone or with an additional seed. In other embodiments, theCVC 862 is also computed using theCE source 108 unique customer product differentiator (CPD 202), thechip 114unique PID 600. Theservice provider 102 receives the unlock request having theCVC 862 andPID 600, and computes an expectedCVC 862 from thesecret value SV 451, and CPD/PID/PPK as required, as shown inblock 808. The resulting expectedCVC 862 is compared to theCVC 862 received from theCE source 108 in the unlock request, and if the two values match, theservice provider 102 transmits the requested JTAG data to theCE Source 108. The CE Source can then use that data to unlock thechip 114 as desired. -
FIG. 8B illustrates a more specific example of the calculation and distribution of customer validation data by theCE source 108 after thechip 114 is manufactured. Theservice provider 102 can implement achip 114 ownership validation scheme that theCE source 108 orsubscriber 110 can use to prove ownership of theCE device 112 before theservice provider 102 releases a JTAG key to a requesting party. TheCE source 108 participates in the generation of validation codes when thechip 114 is produced. - First, the consumer validation code (CVC 862) must be determined. This can be accomplished in a number of ways.
- First, since the ESV[PPK] 455 itself us unique, it can be used as the consumer
validation code CVC 862, as shown inblock 852. - Alternatively, the
CVC 862 may be computed inside thechip 114 from different combinations of ESV[PPK], thechip PID 600, the unique customerproduct differentiator CPD 202, and a seed provided by theservice provider 102. For example, theCVC 862 can be computed as an XOR of thePID 600 and ESV[PPK] 455, as shown inblock 856, as an XOR of thePID 600, the ESV[PPK] 455, and theCPD 202, as shown inblock 858, or an XOR of theCPD 202 and the ESV[PPK] 455, as shown inblock 860. All of theseCVC 862 calculations are unique to thechip 114,SV 451 and globallyunique PID 600, which could only be have been produced by asingle chip 114 of the entire population of fieldedchips 114. The CVC 862 (alternatively referred to hereinafter as the hash validation code) and optionally thePID 600 are recorded as shown inblock 864 for later use in validatingchip 114 orCE device 112 ownership. - The
service provider 102 needs to be able to validate third party owner of the CE device before the JTAG unlock key can be release to a third party customer (e.g. CE source 108). The third party customer such as theCE source 108 transmits aJTAG unlock request 866 to theservice provider 102. The request includes theCVC 862 862 andPID 600 for thechip 114 for which they require a JTAG unlock key. Theservice provider 102 looks up theSV 451 of thechip 114 using thePID 600 supplied by the third party customer. Theservice provider 102 uses theSV 451 and the PID/CPD to calculate the expectedCVC 862, as shown inblocks service provider 102 verifies that the customer suppliedCVC 862 matches the calculated expectedCVC 862 to determine if they are the legitimate third party owner of thechip 114. If so, the JTAG data needed to unlock thechip 114 is transmitted to the third party customer, as shown inblock 878. - It is desirable for service providers to have the capability to segment a population of CE devices 112 (hereinafter alternatively referred to as client devices 112) into a number of different groups based on CAS switching requirements. For example, a service provider may want
client devices 112 of a particular generation to switch to a second CA system based upon a discovered vulnerability discovered in that particular generation ofclient device 112. It is especially desirable that this capability include fielded devices that are already deployed in consumer locations. This fluid ability to define and redefine groups of fielded devices allows different CAS switching paradigms to be defined, including CAS switching that occurs slowly throughout the fieldedclient device 112 population. - Described below is a CAS switching paradigm and a method for signaling such switching that permits groups of fielded
client devices 112 to be defined and redefined as necessary, and provides a technique for signaling when and how such CAS switching should take place. In the embodiment described below, theclient device 112 has previously received an appropriate application image containing a current CAS application that will be switched out and a new CAS application that will be switched in to replace the current CAS application. In this process, the CAS switching process is guided by the vendor of the middleware executing on the client device 112 (for example, theCA vendor 108B), and no direct support is required from the CAS application itself. Typically, the CAS client runs in theclient device 112 on a security processor separate and peripheral from the primary CPU of theclient device 112 or a trusted execution environment (TEE), while the middleware typically executes on the same CPU used for the primary CAS application. - In one embodiment, the CAS signaling and switching is performed on a
client device 112 compliant with the digital video broadcasting (DVB) specifications, including “Digital Video Broadcasting (DVB): Implementation Guidelines of the DVB Simulcrypt Standard,ETSI TR 102 035, Version 1.1.1, published 2002 by the European Telecommunications Standards Institute; “Digital Video Broadcasting (DVB): Head-end implementation of DVB SimulCrypt,” ESTI TS 103 197, Version 1.5.1, published 2008 by the European Telecommunications Standards Institute; and “Common Interface Specification for Conditional Access and Other Digital Video Broadcasting Decoder Applications,” EN 50221, published February 1977 by the TechnicalCommittee CENELEC TC 206, all of which are hereby incorporated by reference herein. In this instance, the CAS switching process involves the Application Specific Data (ASD), which is defined in the Digital Video Broadcasting (DVB) specifications as Private Data (PD). CAS switching data is inserted by the service provider 102 (hereinafter alternatively referred to as the headend 102) into the content delivery network (CDN) for delivery to the selectedclient devices 112. This data is received and processed by the middleware in theclient device 112 to use the appropriate CAS application as directed by the signaling mechanism described herein. - This process allows the operator of a service provider or headend 102 (COMCAST, DIRECTV, DISHTV, or ECHOSTAR, for example) to set up groups in the
client device 112 population as they see fit at the time they intend to perform a switch away from the existingCAS vendor 108B to anew CAS vendor 108B whose application resides in the device. A CAS switch may be desirable in the event the exiting CAS system has been hacked, due to an expiring business relationship with the existing CAS, or more favorable business terms and/or features are available in a new CAS. - The CAS data is passed to each defined group of
client devices 112 through the middleware based on the ASD. The new CAS is signaled to the middleware by a message sent from theheadend 102 indicating that the middleware should begin using the new CAS. Theindividual SoC 114 in eachclient device 112 may require a reboot if required or needed to properly configure the data and key handling resources in theSoC 114.Specific SoCs 114 may be utilizing a derived key mechanism (defined below), which means that the key ladder responsible for calculating the control words used to decrypt encrypted video packets must be properly configured in theSoC 114 for a given CAS client. - The Private Data Generator (PDG) described in the DVB standard closely resembles an entitlement management message (EMM) generator, receives and processed the ASD. This implementation is independent of the
CA vendor 108B of the CAS, so it is not necessary to discuss details of the CAS switching implementation or process withindividual CAS vendors 108B. The CAS switch is independent of the CAS client itself as it is guided by state in the middleware implemented in theclient device 112. After a switch, entitlements are delivered to the new CAS client (i.e. CAS application for the new operational CAS in the client device) for it to properly provide the subscriber with access to their paid/subscribed programming. - Typically, a CAS switch is performed during off peak viewing hours to minimize disruption in the subscriber/viewing population. However, since the switch command is a part of the same signal that delivers the content itself, a switch from one CAS to another will not occur if the
client device 112 is not receiving the content delivery signal at the time a CAS switch is requested by theheadend 102. Consequently, a second or third attempt to complete the CAS switch may be required before the switch actually takes place. Messages to the middleware could be repeated in a carousel fashion (similar to how electronic program guides (EPGs) are currently distributed), and contain a date/time to perform the actual switch/reboot. That increases the likelihood that allclient devices 112 in the group perform the switch command at the same time, irrespective of when eachclient device 112 may have been tuned to the receive the content delivery signal. - The DVB standard defines a program association table (PAT) and a conditional access table (CAT). Both the PAT and the CAT are associated with DVB program identifiers (PIDs) that identify each program in a data stream that may comprise multiple programs. The data stream may also comprise multiple independent program map table (PMT) sections. Each PMT section is given a unique user-defined PID and maps a program number to the metadata describing the program and the program streams.
- The PIDs associated with each PMT section are defined in the PAT, and are the only PIDs defined there. The streams themselves are contained in packetized elementary stream (PES) packets with user-defined PIDs specified in the PMT. The PMT is comprised of sections for each program number represented in a transport stream, each section of which contains the packet identifier and characteristics of each elementary stream in the program service. The CAT is used for conditional access management of the cypher keys used for decryption of restricted streams. The CAT table contains privately defined descriptors of the system used and the PID of the EMM associated with that system. It is used by a network provider to maintain regular key updates.
-
FIG. 9 is a diagram illustrating exemplary method steps for controlling a group ofclient devices 112 to switch from a first CAS to a second CAS via a plurality of client device signaling messages. As described below, the client device signaling messages each comprise at least one of a plurality of action codes and payload data. - In
block 902, a group identifier that identifies the group ofclient devices 112 is generated. Inblock 904, a first client device signaling message is transmitted to only each client of the identified group of client devices 112 (the first client device signaling message is not transmitted toclient devices 112 that are not in the identified group). The first client device signaling message includes the group identifier. The group identifier is for storage in a non-volatile memory of eachclient device 112 of the group ofclient devices 112. - In
block 906, a second client device signaling message is transmitted to the plurality of client devices 112 (which may includeclient devices 112 that are not in the identified group). The second client device signaling message includes the group identifier and signals a switch of each of the group ofclient devices 112 from the first conditional access system to the second conditional access system. - In one embodiment, each of the plurality of devices comprises a middleware module, and the first client device message and the second client device message are transmitted on a conditional access switching message channel monitored by the middleware module of each of the plurality of devices. In this case, an identifier of the conditional access switching message channel (e.g. a switching message PID) is transmitted to each of the plurality of devices, for example, in a conditional access table.
-
FIG. 10 is a diagram illustrating exemplary operations performed by theclient devices 112 in receiving and handling the first client device message and the second client device message. Inblock 1002, a middleware module of at least oneclient device 112 of the group ofclient devices 112 monitors a channel identified by the identifier of the conditional access switching message channel. Inblock 1004, the middleware module of the at least one of theclient devices 112 receives the first client device message transmitted in block 904 (which includes the group identifier). Inblock 1006, the group identifier is stored in non-volatile memory of the at least one of theclient devices 112. The middleware of theclient devices 112 continue to monitor the conditional access switching message channel, and inblock 1008, the middleware module of the at least one of the group ofclient devices 112 receives the second client device message.Block 1010 determines whether the second client device signaling message comprises the group identifier received and stored inblocks client device 112 switches from the first conditional access system to the second conditional access system, as shown inblock 1012. -
FIGS. 11-12 illustrate the operations presented inFIGS. 9-10 in greater detail. -
FIG. 11 illustrates operations that may be performed to assign aclient device 112 to a group. This illustrates additional detail regarding the operations illustrated inblocks FIG. 9 and blocks 1002-1006 ofFIG. 10 . -
Client devices 112 are assigned to a particular group upon activation via a group identifier stored in non volatile memory (NVM). The group identifier allows a subset of theclient device 112 population to switch to another CAS system stored in the client device, but dormant (e.g. not installed and operating). This group assignment by provision of the group identifier is in addition to the other actions that may be required by the CAS currently active in the client device. Then an application executing on theclient device 112 updates the group identifier by storing it in NVM upon reception of a message having an Assign Group Action. - As shown in 1152, an
operator 1102 issues an assign group command to the private generator orPDG 1104. Theoperator 1102 may comprise a human or a computer executing instructions to generate the command based on input from humans or another computer. As shown in 1154, thePDG 1104 generates private data comprising a group identifier, and provides this identifier to amultiplexer 1106 which multiplexes the private data having the group identifier into the data stream transmitted to the client device. The private data is then transmitted in a data stream to theclient device 112 where it is accepted by the client device 112 (set top box or STB)application 1108, as shown in 1156. Theclient device 112 then updates the group identifier of theclient device 112 by storing the received group identifier in non-volatile memory (NVM) as shown in 1158. -
FIG. 12 illustrates operations that may be performed to initiate a CAS switch. This illustrates additional detail regarding the operations illustrated inblocks 906 ofFIG. 9 and blocks 1008-1012 ofFIG. 10 . - A CAS switch is initiated by a Switch CAS message generated by the PDG. The Switch CAS messages can be addressed to one or more
individual client devices 112, a group ofclient devices 112 or allclient devices 112. This paradigm permits a single message to be sent to allclient device 112 members in the group as opposed to sending many single, independent messages toindividual client devices 112. The Switch CAS message may include an activation date to allow pushing of the message before the CAS switch is to actually take place. In such cases where the activation date/time is in the future, theSTB application 1108 executing in theclient device 112 sets an event and writes the CAS ID to a NVM memory location for future use by the CAS Switch activation event. When the activation event occurs (in the future or immediately), theSTB application 1108 writes the CAS ID to a well-known location memory location in NVM (that is designated to be executed on reboot) and reboots. On reboot, theSTB application 1108 reads the CAS ID and activate the corresponding CAS kernel to install and execute the new CAS. - Referring to
FIG. 11 , theoperator 1102 selects which group of theclient devices 112 are desired for a CAS switch, an identifier of the CAS to be switched to (CAS ID) and issues a CAS switch command identifying these devices and providing the CAS ID, as shown in 1202. In 1204, the PDG generates private data comprising the group number of the group ofclient devices 112 for which the CAS switch was desired, and provides that PDG to themultiplexer 1106, which multiplexes the private data having the group identifier and information indicating that a switch is desired into the data stream as a CAS switch command. The private data is then transmitted in a data stream to theclient device 112 where it is accepted by theclient device application 1108, as shown in 1208. As described further below the CAS switch may be performed immediately upon receipt by the client device, or may be performed as a future event. In cases that the update is to occur immediate, the CAS ID is updated in NVM, and theclient device 112 is rebooted as shown in 1210 and 1212. In cases where the update is to occur at a later time or date, the CAS ID is updated in NVM, and a future event is set, at which time the CAS switch will take place by rebooting 1212 the client device. - As a part of the booting process, middleware executing on the
client device 112 checks the known flash location (designated to be executed on reboot) to determine which CAS to initialize. This information was included in the form of the CAS ID (for example, CAS-A, CAS-B or CAS-C) transmitted with the CAS Switch message described above. Next, the middleware executing on theclient device 112 provides CAS specific data to a secure processor of the client device 112 (e.g. aSoC 114 or system on a chip) so that theSoC 114 can derive keys associated with the selected CAS and pertaining to theappropriate CAS vendor 108B. Such keys may include, for example keys or intermediate results required to derive keys for decrypting media programs encrypted by theheadend 102. - Next, the middleware executing on the
client device 112 initializes the appropriate CAS, which then operates as a CAS client. The middleware monitors the appropriate channel to receive the CAT from theheadend 102, and once the CAT is received, the middleware passes the CAT to the CAS client. - Using the CAT, the CAS client instructs the middleware to monitor the appropriate channel to receive EMMs. The appropriate channel can be defined according to a particular DVB PID, which may be placed in the CAT with a “dummy” CAS identifier. For example, in a DVB system, the PID used for EMM reception may be monitored.
- When the
client device 112 is tuned to the appropriate channel, the middleware receives the PMT and parses the PMT to determine the PID of the ECMs that correspond to the CAS currently in operation (e.g. the CAS recently switched to). The middleware then filters the incoming data stream for ECMs having the determined PID, and passes those ECMs to the CAS client. The CAS client (cooperating with the middleware if necessary) then process the ECM to load decrypting information such as keys and/or software, and uses that information to generate keys or other information that is needed to decrypt media program(s). - This section provides an exemplary format and syntax of the messages communicated with the client device. It is noted that message of differing format and/or syntax may be used. In a preferred embodiment, the messages themselves are cryptographically protected, either through encryption, hashing or other means.
- Messages communicated with the middle ware include (1) an address (intended target of message, such as global, group, specific), (2) a sequence number (to prevent duplicate processing), (3) a message type, and (4) payload. Message types include but are not limited to (1) Assign group, (2) Assign
CAS Vendor 108B, and (3) Reboot. Payloads are specific to a particular message type, as further described below. Based on message type, middleware will take appropriate action (i.e. store group info in flash, store selectedCAS vendor 108B in flash, reboot at the appropriate time). - Message include an action code, describing a particular action that the message is to command. In the example below, actions are embedded in the message in a tag-length-value (TLV) format.
- Table V defines one embodiment of a minimal list of Actions to implement for CAS Switching messages.
-
TABLE V Action (Hex) Description Comments 01 Sequence number Sequence number of the message 02 Timestamp Timestamp of the message in system time 10 Unique Addressing Unique address of STB 11 Group Addressing Group address of STB 12 Global Addressing All STB's 20 Assign Group Assign a STB to an addressing Group 21 CAS Switch Switch from current CAS to CAS identified in the message - Each message minimally requires the following Actions (1) Addressing (unique, group, or global) (2) Timestamp (3) Sequence number (4) Primary action (Assign Group or CAS Switch).
- The Sequence Number action (01) is used communicate the sequence number of the message to the
STB Application 1108. This information prevents theSTB application 1108 from reprocessing messages. Data associated with this action is presented in Table VI. -
TABLE VI Field Size Description Action Code 1 01 - Sequence Number Length 1 Length (does not include action or length fields) Sequence Number 2 Sequence number - The Timestamp action (02) is used to indicate system time. Messages with Timestamps in the past should not be processed. Data associated with this action is presented in Table VII.
-
TABLE VII Field Size Description Action Code 1 02 - Timestamp Length 1 Length (does not include action or length fields) Time Var User defined time - The Unique Addressing action (10) is used to address a single client device. Data associated with this action is presented in Table VIII.
-
TABLE VIII Field Size Description Action Code 1 10 - Addressing Unique Length 1 Length (not including action and length fields) Address var The unique address of the STB (Transport Chip ID) - The Group Addressing (11) action is used to address a group of
client devices 112 assigned to a Group Identifier. Data associated with this action is presented in Table IX. -
TABLE IX Field Size Description Action Code 1 11 - Addressing Group Length 1 Length (not including action and length fields) Group ID 2 The Group Identifier - The Global Addressing (12) action is used to address all
client devices 112. Data associated with this action is presented in Table X. -
TABLE X Field Size Description Action Code 1 12 - Addressing Global Length 1 Length (not including action and length fields) Shall be 0 - The Assign Group (20) action is used to assign a STB to a Group Identifier. Data associated with this action is presented in Table XI.
-
TABLE XI Field Size Description Action Code 1 20 - Assign Group Length 1 Length (not including action and length fields) Group ID 2 The Group Identifier - The CAS Switch (21) action is used to signal a CAS Switch. Data associated with this action is presented in Table XII.
-
TABLE XII Field Size Description Action Code 1 21 - CAS Switch Length 1 Length (not including action and length fields) CAS ID 4 CAS ID to switch to Activation 1 The length of the Activation Time to follow Time Length Activation var The time at which the CAS Switch should occur. Time There may be an encoding of ‘Now,’ meaning perform CAS Switch immediately on reception. - The system and method described above permits programming of unique secrets into the
SoC 114 at theSoC 114manufacturing site 104 and permits later allocation of theseSoCs 114 to any one of a number of potentialCE device manufacturers 108A and many independent CAS/DRM vendors 108B.SoC 114 programming can also occur at the packaging or product manufacturing facility by execution of an in-field programming sequence on theSoC 114. - In traditional broadcast and cable system, content is offered to subscribers within the content distribution ecosystem directly from the service provider, i.e. satellite or cable provider. In some embodiments, a Hardware Root of Trust Security is offered for high value content with easy integration with a CAS and DRM technology to enable many content providers to provide their media programs directly to consumers using their CE devices. In both models (i.e. traditional broadcast model versus the content provider direct model) of content distribution, a security provider independent architecture can support multiple concurrent or serial CAS and DRM implementations using a single black box programming security platform with limited One Time Programming (OTP) resources to store secrets representing the hardware root of trust. This security architecture implementation provides a means for instantaneous switching between security profiles offered by different and independent CAS and DRM security providers.
- In a derived key SoC architecture providing security providers with different security key debases is accomplished by allowing
SoCs 114 to use black box OTP resources as the basis to derive security keys to enable different security schemes by altering the key generation inputs based on digital rights management (DRM) andCAS vendor 108B software and possiblyCA vendor 108B unique OTP inputs. The key generation inputs can be provided in the CAS and DRM application that could be loaded at CE device manufacturing or downloaded over the air for fielded CE device(s). - Key derivation can be accomplished in a number of ways, for example, by taking the black box programmed secret OTP keys, CAS/
DRM vendor 108B software input and possible CAS/DRM vendor 108B unique OTP values and combining in a series of crypto graphic calculations using AES, DES or Triple DES. Where the black box programmed secret OTP keys are used as the key and the software input and CAS/DRM vendor 108B unique OTP values are the data in the cryptographic operation. Such operations are standard for those skilled in use and construction of cryptographic calculations. - By changing the key generation inputs, the
SoC 114 can derive unique key outputs for each CAS and DRM security provider used for a given content provider or broadcaster. CAS unique inputs such as their assigned CAS ID may be used to differentiate derived keys for CAS1 versus CAS2. The term security provider in this context is to be broadly construed and reflects the entity who would use the derived key database for a population of fielded CE devices to protect content for purchase by an entity who had a particular CE device in their home. These security provider unique key generation outputs enable support for multiple security providers for fielded CE devices typically found in Set Top Boxes, televisions (TVs), Smart TVs and mobile devices. The black box security provider provides compatible headend applications to each content provider, so that the media programs are encrypted or otherwise protected using the CAS and DRM implementation used. - Another advantage of using a derived key database is that the black box programmed OTP key secrets programmed into the
SoC 114 OTP do not have to be released to the multiple CAS and DRM security providers, since these security providers would use the derived key databases for their content protection systems. This means that if a derived key database were compromised, it only affects the specific CAS/DRM security provider that was using that specific derived key database, i.e. such compromise would not affect the fielded CE devices or derived key databases of any other such CAS/DRM security provider. - The keys and programming infrastructure summarized herein as provided by an independent black box security provider enables fielded CE devices to add additional revenue baring applications to the CE device manufacturer or content provider giving these entities more flexibility in managing their business and offering new services. Besides switching out a CAS/
DRM vendor 108B for any number of reasons, enabling the ability to add applications supporting new CAS/DRM vendors 108B in fieldedCE devices 112 can result in generating significantly higher content sale revenues without requiring consumers to upgrade theirCE devices 112. Consumer savings are realized by extending the field life of theCE device 112 by allowing the consumer to download new software images to enable the purchase of new content services without having to replace their fieldedCE devices 112. - In many cases it is desirable to fully integrate an additional CAS client in a
client device 112 such as a STB to act as a second and/or dormant backup to be used in emergency situations for business continuity purposes or as an alternative to other CAS clients that may also reside in the client device. - The operator or broadcaster must assign their content packages and products to the dormant CAS so that package definitions and entitlements can be properly assigned and allow authorization messages to be created and delivered to the STBs. Client licensing and
headend 102 equipment must also be available to integrate all CAS client applications implemented in theclient device 112, i.e. the primary, backup and/or dormant CAS client must be fully developed, tested and ready to integrate into the client device and middleware application so that they can be fully operational in the event they are needed to replace the primary CAS client in the deployed client device. Implementing this embodiment requires the completion of the following. - First, each CAS client must be fully integrated with the
client device 112 to provide full capabilities for the second/dormant CAS system. This is to assure compatibility of the CAS system and the middleware executed by the client device. Hence, if the CAS and middleware executed by theclient device 112 are from different vendors, they must assure such interoperability is maintained so that the CAS and middleware operate in an integrated manner. Such integration requires marginal additional effort for a single vendor since the CAS integration effort will be conducted for each integrated CAS client. - Second, related CAS (and middleware)-related applications executing at the
headend 102 must be integrated with the CAS clients and middleware executing in theclient devices 112, preferably prior or near system launch. Typically, the CAS-relatedheadend 102 execute on servers operated by theheadend 102, due to intellectual property concerns and to isolate their execution environments. - Third, a CAS switch by a limited number of fielded
client devices 112 should be tested to ensureproper client device 112 operation before and after the switch. - The switch to a supported CAS client in the
client device 112 may be activated using the above CAS switching protocol with no hardware modifications to theclient device 112 or theheadend 102 equipment. This same switching protocol can be used to switch between the any of the supported CAS clients in the fieldedclient devices 112, giving full access to the content protection systems for the new CAS client. Using this approach such CAS switching is transparent to the CAS application running in the client device. -
FIG. 13 is a diagram illustrating anexemplary computer system 1300 that could be used to implement elements of the present invention, including processing elements at theservice provider 102,chip manufacturer 104,security provider 106,black box 116,chip manufacturer 104 andCA vendor 108B,chips 114 andCE device 112. - The
computer 1302 comprises a generalpurpose hardware processor 1304A and/or a specialpurpose hardware processor 1304B (hereinafter alternatively collectively referred to as processor 1304) and amemory 1306, such as random access memory (RAM). Thecomputer 1302 may be coupled to other devices, including input/output (I/O) devices such as akeyboard 1314, amouse device 1316 and aprinter 1328. - In one embodiment, the
computer 1302 operates by the general-purpose processor 1304A performing instructions defined by thecomputer program 1310 under control of anoperating system 1308. Thecomputer program 1310 and/or theoperating system 1308 may be stored in thememory 1306 and may interface with the user and/or other devices to accept input and commands and, based on such input and commands and the instructions defined by thecomputer program 1310 andoperating system 1308 to provide output and results. - Output/results may be presented on the
display 1322 or provided to another device for presentation or further processing or action. In one embodiment, thedisplay 1322 comprises a liquid crystal display (LCD) having a plurality of separately addressable pixels formed by liquid crystals. Each pixel of thedisplay 1322 changes to an opaque or translucent state to form a part of the image on the display in response to the data or information generated by the processor 1304 from the application of the instructions of thecomputer program 1310 and/oroperating system 1308 to the input and commands.Other display 1322 types also include picture elements that change state in order to create the image presented on thedisplay 1322. The image may be provided through a graphical user interface (GUI)module 1318A. Although theGUI module 1318A is depicted as a separate module, the instructions performing the GUI functions can be resident or distributed in theoperating system 1308, thecomputer program 1310, or implemented with special purpose memory and processors. - Some or all of the operations performed by the
computer 1302 according to thecomputer program 1310 instructions may be implemented in aspecial purpose processor 1304B. In this embodiment, some or all of thecomputer program 1310 instructions may be implemented via firmware instructions stored in a read only memory (ROM), a programmable read only memory (PROM) or flash memory within thespecial purpose processor 1304B or inmemory 1306. Thespecial purpose processor 1304B may also be hardwired through circuit design to perform some or all of the operations to implement the present invention. Further, thespecial purpose processor 1304B may be a hybrid processor, which includes dedicated circuitry for performing a subset of functions, and other circuits for performing more general functions such as responding to computer program instructions. In one embodiment, the special purpose processor is an application specific integrated circuit (ASIC). - The
computer 1302 may also implement acompiler 1312 which allows anapplication program 1310 written in a programming language such as COBOL, C++, FORTRAN, or other language to be translated into processor 1304 readable code. After completion, the application orcomputer program 1310 accesses and manipulates data accepted from I/O devices and stored in thememory 1306 of thecomputer 1302 using the relationships and logic that was generated using thecompiler 1312. - The
computer 1302 also optionally comprises an external communication device such as a modem, satellite link, Ethernet card, or other device for accepting input from and providing output to other computers. - In one embodiment, instructions implementing the
operating system 1308, thecomputer program 1310, and/or thecompiler 1312 are tangibly embodied in a computer-readable medium, e.g.,data storage device 1320, which could include one or more fixed or removable data storage devices, such as a zip drive,floppy disc drive 1324, hard drive, CD-ROM drive, tape drive, or a flash drive. Further, theoperating system 1308 and thecomputer program 1310 are comprised of computer program instructions which, when accessed, read and executed by thecomputer 1302, causes thecomputer 1302 to perform the steps necessary to implement and/or use the present invention or to load the program of instructions into a memory, thus creating a special purpose data structure causing the computer to operate as a specially programmed computer executing the method steps described herein.Computer program 1310 and/or operating instructions may also be tangibly embodied inmemory 1306 and/ordata communications devices 1330, thereby making a computer program product or article of manufacture according to the invention. As such, the terms “article of manufacture,” “program storage device” and “computer program product” or “computer readable storage device” as used herein are intended to encompass a computer program accessible from any computer readable device or media. - Of course, those skilled in the art will recognize that any combination of the above components, or any number of different components, peripherals, and other devices, may be used with the
computer 1302. - Although the term “computer” is referred to herein, it is understood that the computer may include portable devices such as cellphones, portable MP3 players, video game consoles, notebook computers, pocket computers, or any other device with suitable processing, communication, and input/output capability.
- This concludes the description of the preferred embodiments of the present invention. The foregoing description of the preferred embodiment of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
Claims (21)
1. In a system of a plurality of client devices for receiving data from a provider, each of the client devices having a securely executing system client and a middleware module communicating with the system client, a method of controlling a group of the client devices to switch at least one client device of the group of the client devices from a first system client to a second system client via a plurality of client device signaling messages, the method comprising:
generating a group identifier identifying the group of the client devices;
transmitting a first client device signaling message having the group identifier only to each client device of the identified group of the client devices, the first client device signaling message signaling an action to assign the client device receiving the message to the identified group of the client devices, the group identifier for storage in each client device of the identified group of the client devices in non-volatile memory; and
transmitting a second client device signaling message to the plurality of client devices, the second client device signaling message comprising the group identifier and signaling each client device having the group identifier stored in the non-volatile memory to switch from the first system client to the second system client;
wherein the first client device signaling message and the second device signaling message are transmitted on a switching message channel monitored by the middleware module of each of the plurality of client devices, the switching message channel identified by an identifier transmitted to each of the plurality of client devices as application specific data.
2. The method of claim 1 , wherein:
the first client device signaling message comprises:
a first action code of a plurality of action codes and payload data;
the first action code signaling the action to assign the client device receiving the message to the identified group of the client devices; and
the payload data including the group identifier of the identified group of the client devices;
the second client device signaling message comprises:
a second action code of the plurality of action codes and second payload data;
the second action code signaling each client device having the group identifier stored in the non-volatile memory to switch from the first system client to the second system client; and
the second payload data identifies the second system client.
3. The method of claim 2 , wherein the second client device signaling message comprises a time at which the switch to the second system client is to be made by the client device.
4. The method of claim 2 , wherein the first client device signaling message and the second client device signaling message are transmitted as private data of a digital video broadcasting (DVB) standard.
5. The method of claim 4 , wherein:
the method further comprises transmitting the identifier of the switching message channel to the plurality of client devices in a access table.
6. The method of claim 5 , wherein the plurality of action codes further comprises:
a first action code addressing all of the client devices; and
a second action code addressing only single client devices.
7. The method of claim 6 , further comprising:
monitoring, by the middleware module of at least one of the identified group of the client devices, the channel identified by the identifier of the switching message channel;
receiving, in the middleware module of the at least one of the identified group of the client devices, the first client device signaling message; and
storing the group identifier in non volatile storage of the at least one of the identified group of the client devices.
8. The method of claim 7 , further comprising:
receiving, in the middleware module of the at least one of the identified group of the client devices, the second client device signaling message;
determining if the second client device signaling message comprises the group identifier; and
if the second client device signaling message comprises the group identifier, switching the at least one client device to the second system client.
9. The method of claim 8 , wherein the first client device signaling message and the second client device signaling message each further comprise:
a sequence number action code and associated sequence number; and
a timestamp action code and associated timestamp;
wherein the group identifier is stored in non-volatile memory only if the sequence number of the sequence number action code is compares favorably with a sequence number of a sequence number action code of a third client device signaling message is numerically previous to the first client device signaling message; and
the at least one of the identified group of the client devices is switched to the second system client only if the timestamp of the associated timestamp action code is temporally ahead of a current system time.
10. The method of claim 9 , further comprising:
initializing the second system client;
providing security data to the second system client to derive keys for decrypting the data;
determining a management message channel identifier from the access table;
receiving a management message on the management message channel identified by the management message channel identifier;
receiving a map table associated with the data;
determining a control message channel identifier corresponding to the second system client from the map table;
receiving control messages on a control message channel identified by the control message channel identifier; and
decrypting the data using the second system client according to the derived keys and the control message.
11. In a system of a plurality of client devices for receiving data from a provider, each of the client devices having a securely executing system client and a middleware module communicating with the system client, an apparatus for controlling a group of the plurality of client devices to switch at least one client device of the group of the client devices from a first system client to a second system client via a plurality of client device signaling messages, comprising:
a private data generator, comprising:
a processor;
a memory, the memory storing processor instructions comprising instructions for:
generating a group identifier identifying the group of the client devices;
a transmitter, communicatively coupled to the private data generator, the transmitter for:
transmitting a first client device signaling message having the group identifier only to each client device of the identified group of the client devices, the first client device signaling message signaling an action to assign the client device receiving the message to the identified group of the client devices, the group identifier for storage in each client device of the group of the client devices in non-volatile memory; and
transmitting a second client device signaling message to the plurality of client devices, the second client device signaling message comprising the group identifier and signaling each client device having the group identifier stored in the non-volatile memory to switch from the first system client to the second system client;
wherein the first client device signaling message and the second device signaling message are transmitted on a switching message channel monitored by the middleware module of each of the plurality of client devices, the switching message channel identified by an identifier transmitted to each of the plurality of client devices as application specific data.
12. The apparatus of claim 11 , wherein:
the first client device signaling message comprises:
a first action code of a plurality of action codes and payload data;
the first action code signaling the action to assign the client device receiving the message to the group of the client devices; and
the payload data including the group identifier of the group of the client devices;
the second client device signaling message comprises:
a second action code of the plurality of action codes and second payload data;
the second action code signaling each client device having the group identifier stored in the non-volatile memory to switch from the first system client to the second system client; and
the second payload data identifies the second system client.
13. The apparatus of claim 12 , wherein the second client device signaling message comprises a time at which the switch to the second system client is to be made by the client device.
14. The apparatus of claim 12 , wherein the first client device signaling message and the second client device signaling message are transmitted as private data of a digital video broadcasting (DVB) standard.
15. The apparatus of claim 14 , wherein:
each of the plurality of client devices comprises:
a client device processor;
a client device memory, storing client device processor instructions implementing the middleware module, the instructions including instructions for:
monitoring a conditional access switching message channel for the first client device message and the second client device messages; and
the transmitter further transmits the identifier of the conditional access switching message channel to the plurality of client devices in an access table.
16. The apparatus of claim 15 , wherein the plurality of action codes further comprises:
a first action code addressing all of the client devices; and
a second action code addressing only single client devices.
17. The apparatus of claim 16 , wherein:
the client device processor instructions implementing the middleware module further comprise instructions for:
monitoring the channel identified by the identifier of the switching message channel;
receiving the first client device signaling message; and
the client device processor instructions further comprise instructions for storing the group identifier in non volatile storage of the at least one of the group of the client devices.
18. The apparatus of claim 17 , wherein:
the client device processor instructions implementing the middleware module further comprise instructions for:
receiving, the second client device signaling message;
determining if the second client device signaling message comprises the group identifier; and
the client device processor instructions further comprise instructions for switching the at least one client device to the second system client if the second client device signaling message comprises the group identifier.
19. The apparatus of claim 18 , wherein the first client device signaling message and the second client device signaling message each further comprise:
a sequence number action code and associated sequence number; and
a timestamp action code and associated timestamp;
wherein the group identifier is stored in non-volatile memory only if the sequence number of the sequence number action code is compares favorably with a sequence number of a sequence number action code of a third client device signaling message is numerically previous to the first client device signaling message; and
the at least one of the group of the client devices is switched to the second system client only if the timestamp of the associated timestamp action code is temporally ahead of a current system time.
20. The apparatus of claim 19 , wherein:
the client device processor instructions implementing the middleware module further comprise instructions for:
initializing the second system client;
providing security data to the second system client to derive keys for decrypting the data;
receiving a management message channel identifier determined by a system client from the received access table;
receiving a management message on the management message channel identified by the management message channel identifier;
receiving a map table associated with the data;
determining a control message channel identifier corresponding to the second system client from the program map table; and
receiving control messages on a control message channel identified by the control message channel identifier;
the client device further comprises a security processor communicatively coupled to a security processor memory, the security processor memory comprising security processor instructions for:
decrypting the data using the second system client according to the derived keys and the control message.
21. In a system of a plurality of client devices for receiving data from a provider, each of the client devices having a securely executing system client and a middleware module communicating with the system client, an apparatus for controlling a group of the plurality of client devices to switch from a first system client to a second system client via a plurality of client device signaling messages, comprising:
a private data generator, comprising:
a processor;
a memory, the memory storing processor instructions comprising instructions for:
generating a group identifier identifying the group of the client devices;
a transmitter, communicatively coupled to the private data generator, the transmitter for:
transmitting a first client device signaling message having the group identifier only to each client device of the identified group of the client devices, the first client device signaling messages signaling an action to assign the client device receiving the message to the identified group of the client devices, the group identifier for storage in each client device of the group of the client devices in non-volatile memory; and
transmitting a second client device signaling message to plurality of client devices, the second client device signaling message comprising the group identifier and signaling each of the group of client device having the group identifier stored in the non-volatile memory to switch from the first system client to the second system client;
wherein:
the first client device signaling message and the second device signaling message are transmitted on a conditional access switching message channel monitored by the middleware module of each of the plurality of client devices, the conditional access switching message channel identified by an identifier transmitted to each of the plurality of client devices as application specific data.
each of the plurality of client devices comprises:
a client device processor;
a client device memory, storing client device processor instructions implementing the middleware module, the instructions including instructions for monitoring the conditional access switching message channel for the first client device signaling message and the second client device switching message; and
the transmitter further transmits the identifier of the conditional access switching message channel to the plurality of client devices as application specific data.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/681,465 US20200153840A1 (en) | 2012-03-02 | 2019-11-12 | Signaling system switching and key derivation |
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261606260P | 2012-03-02 | 2012-03-02 | |
PCT/US2013/028761 WO2013131065A1 (en) | 2012-03-02 | 2013-03-01 | Blackbox security provider programming system permitting multiple customer use and in field conditional access switching |
US201414382539A | 2014-09-02 | 2014-09-02 | |
US201762446196P | 2017-01-13 | 2017-01-13 | |
US15/791,260 US10476883B2 (en) | 2012-03-02 | 2017-10-23 | Signaling conditional access system switching and key derivation |
US16/681,465 US20200153840A1 (en) | 2012-03-02 | 2019-11-12 | Signaling system switching and key derivation |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/791,260 Continuation US10476883B2 (en) | 2009-02-24 | 2017-10-23 | Signaling conditional access system switching and key derivation |
Publications (1)
Publication Number | Publication Date |
---|---|
US20200153840A1 true US20200153840A1 (en) | 2020-05-14 |
Family
ID=62148015
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/791,260 Expired - Fee Related US10476883B2 (en) | 2009-02-24 | 2017-10-23 | Signaling conditional access system switching and key derivation |
US16/681,465 Abandoned US20200153840A1 (en) | 2012-03-02 | 2019-11-12 | Signaling system switching and key derivation |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/791,260 Expired - Fee Related US10476883B2 (en) | 2009-02-24 | 2017-10-23 | Signaling conditional access system switching and key derivation |
Country Status (1)
Country | Link |
---|---|
US (2) | US10476883B2 (en) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10348501B2 (en) * | 2015-07-10 | 2019-07-09 | Inside Secure | Method and apparatus for a blackbox programming system permitting downloadable applications and multiple security profiles providing hardware separation of services in hardware constrained devices |
KR102590165B1 (en) * | 2016-08-11 | 2023-10-17 | 삼성전자 주식회사 | Method and apparatus for installing cas information |
US10839048B2 (en) * | 2017-05-19 | 2020-11-17 | Arris Enterprises Llc | Key-ladder protected personalization data transcription for provisioning |
CN109598105B (en) * | 2018-12-03 | 2020-09-29 | 深圳忆联信息系统有限公司 | Method and device for safely loading firmware by microcontroller, computer equipment and storage medium |
WO2021051002A1 (en) | 2019-09-12 | 2021-03-18 | Intertrust Technologies Corporation | Dynamic broadcast content access management systems and methods |
US11310568B2 (en) * | 2020-05-05 | 2022-04-19 | Panasonic Avionics Corporation | Systems and methods for securely providing preview samples of media content distributed to in-flight entertainment systems |
US11734460B2 (en) * | 2021-03-23 | 2023-08-22 | Intel Corporation | Connectionless trusted computing base recovery |
US12093394B2 (en) * | 2023-02-20 | 2024-09-17 | Xilinx, Inc. | System and method for secure deconstruction sensor in a heterogeneous integration circuitry |
Family Cites Families (62)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4903262A (en) * | 1987-08-14 | 1990-02-20 | General Electric Company | Hardware interface and protocol for a mobile radio transceiver |
US5940504A (en) * | 1991-07-01 | 1999-08-17 | Infologic Software, Inc. | Licensing management system and method in which datagrams including an address of a licensee and indicative of use of a licensed product are sent from the licensee's site |
US5809281A (en) * | 1993-03-30 | 1998-09-15 | Altera Corporation | Field programmable gate array with high speed SRAM based configurable function block configurable as high performance logic or block of SRAM |
US5444686A (en) | 1993-09-28 | 1995-08-22 | Dunlavy; John H. | Method and apparatus for correcting distortion in compact disc recording and playback system |
US20040166942A1 (en) | 1997-02-10 | 2004-08-26 | Muir Robert Linley | Distributed game accelerator |
US6226618B1 (en) | 1998-08-13 | 2001-05-01 | International Business Machines Corporation | Electronic content delivery system |
US7599491B2 (en) | 1999-01-11 | 2009-10-06 | Certicom Corp. | Method for strengthening the implementation of ECDSA against power analysis |
US7225333B2 (en) | 1999-03-27 | 2007-05-29 | Microsoft Corporation | Secure processor architecture for use with a digital rights management (DRM) system on a computing device |
EP1076279A1 (en) | 1999-08-13 | 2001-02-14 | Hewlett-Packard Company | Computer platforms and their methods of operation |
US7010607B1 (en) * | 1999-09-15 | 2006-03-07 | Hewlett-Packard Development Company, L.P. | Method for training a communication link between ports to correct for errors |
US8271336B2 (en) | 1999-11-22 | 2012-09-18 | Accenture Global Services Gmbh | Increased visibility during order management in a network-based supply chain environment |
US7085854B2 (en) | 2000-04-12 | 2006-08-01 | Corente, Inc. | Methods and systems for enabling communication between a processor and a network operations center |
US7389531B2 (en) | 2000-06-16 | 2008-06-17 | Entriq Inc. | Method and system to dynamically present a payment gateway for content distributed via a network |
US7539875B1 (en) | 2000-06-27 | 2009-05-26 | Microsoft Corporation | Secure repository with layers of tamper resistance and system and method for providing same |
US7688975B2 (en) | 2001-10-26 | 2010-03-30 | Authenex, Inc. | Method and apparatus for dynamic generation of symmetric encryption keys and exchange of dynamic symmetric key infrastructure |
US7233669B2 (en) | 2002-01-02 | 2007-06-19 | Sony Corporation | Selective encryption to enable multiple decryption keys |
JP2005038411A (en) | 2003-06-30 | 2005-02-10 | Sony Corp | Equipment authentication information incorporating system, terminal, equipment authentication information processing method, equipment authentication information processing program, providing server, equipment authentication information providing method, equipment authentication information providing program and storage medium |
US20050093572A1 (en) * | 2003-11-03 | 2005-05-05 | Macronix International Co., Ltd. | In-circuit configuration architecture with configuration on initialization function for embedded configurable logic array |
US20090210348A1 (en) | 2004-02-04 | 2009-08-20 | Steffan Gottfried Klein | System and method for electronic commerce |
US7552341B2 (en) | 2004-09-01 | 2009-06-23 | Microsoft Corporation | Licensing the use of software on a particular CPU |
US7707405B1 (en) | 2004-09-21 | 2010-04-27 | Avaya Inc. | Secure installation activation |
US8243925B2 (en) | 2004-10-18 | 2012-08-14 | Syphermedia International, Inc. | Method and apparatus for supporting multiple broadcasters independently using a single conditional access system |
US20060129502A1 (en) | 2004-12-15 | 2006-06-15 | Microsoft Corporation | Generation, distribution and verification of tokens using a secure hash algorithm |
JP4764639B2 (en) | 2005-01-28 | 2011-09-07 | 株式会社オーク情報システム | File encryption / decryption program, program storage medium |
DE602005022194D1 (en) | 2005-07-29 | 2010-08-19 | St Microelectronics Res & Dev | Procedure against unauthorized access to decryption keys using an encrypted digital signature |
JP4630826B2 (en) | 2006-01-27 | 2011-02-09 | 株式会社東芝 | Decryption key generation method, content provider side system, user side system, tracking system, content provision method, encrypted content decryption method, program, encryption device, and decryption device |
US20080003980A1 (en) | 2006-06-30 | 2008-01-03 | Motorola, Inc. | Subsidy-controlled handset device via a sim card using asymmetric verification and method thereof |
US7886355B2 (en) | 2006-06-30 | 2011-02-08 | Motorola Mobility, Inc. | Subsidy lock enabled handset device with asymmetric verification unlocking control and method thereof |
US7801308B1 (en) | 2006-07-17 | 2010-09-21 | Integrated Device Technology, Inc. | Secure key encoding for content protection |
US20090323971A1 (en) | 2006-12-28 | 2009-12-31 | Munguia Peter R | Protecting independent vendor encryption keys with a common primary encryption key |
US8001383B2 (en) | 2007-02-01 | 2011-08-16 | Microsoft Corporation | Secure serial number |
US20080306874A1 (en) | 2007-06-06 | 2008-12-11 | White Charles A | System and method for managing a product through a distribution chain |
US8452967B2 (en) | 2007-08-31 | 2013-05-28 | Microsoft Corporation | Using flash storage device to prevent unauthorized use of software |
PL2043055T3 (en) | 2007-09-28 | 2021-01-25 | Iloq Oy | Lock administration system |
US9892390B2 (en) | 2007-12-12 | 2018-02-13 | Microsoft Technology Licensing, Llc | Digital content packaging, licensing and consumption |
US20090193507A1 (en) | 2008-01-28 | 2009-07-30 | Wael Ibrahim | Authentication messaging service |
US8245308B2 (en) | 2008-06-04 | 2012-08-14 | Microsoft Corporation | Using trusted third parties to perform DRM operations |
US20090326964A1 (en) | 2008-06-25 | 2009-12-31 | Microsoft Corporation | Extensible agent-based license structure |
WO2010010430A2 (en) | 2008-07-25 | 2010-01-28 | Lee Kok-Wah | Methods and systems to create big memorizable secrets and their applications in information engineering |
WO2010047801A1 (en) | 2008-10-22 | 2010-04-29 | Azigo, Inc. | Brokered information sharing system |
US20100274972A1 (en) * | 2008-11-24 | 2010-10-28 | Boris Babayan | Systems, methods, and apparatuses for parallel computing |
KR100969668B1 (en) | 2008-11-25 | 2010-07-14 | 충남대학교산학협력단 | Method for Downloading CAS in IPTV |
US20100153731A1 (en) | 2008-12-17 | 2010-06-17 | Information And Communications University | Lightweight Authentication Method, System, and Key Exchange Protocol For Low-Cost Electronic Devices |
CN102224703B (en) | 2009-04-27 | 2013-11-06 | 华为技术有限公司 | Method, device and system for issuing license |
US8111089B2 (en) * | 2009-05-28 | 2012-02-07 | Syphermedia International, Inc. | Building block for a secure CMOS logic cell library |
JP5476823B2 (en) | 2009-07-06 | 2014-04-23 | 株式会社リコー | DEVICE MANAGEMENT DEVICE, DEVICE MANAGEMENT SYSTEM, SOFTWARE MANAGEMENT METHOD, SOFTWARE MANAGEMENT PROGRAM, AND RECORDING MEDIUM CONTAINING THE PROGRAM |
JP5418025B2 (en) | 2009-07-08 | 2014-02-19 | 株式会社リコー | Information processing apparatus, system management method, system management program, and recording medium recording the program |
JP5792732B2 (en) | 2009-09-30 | 2015-10-14 | アマゾン テクノロジーズ インコーポレイテッド | Modular device authentication framework |
US8474052B2 (en) | 2009-12-09 | 2013-06-25 | Microsoft Corporation | User-administered license state verification |
EP2362573A1 (en) | 2010-02-19 | 2011-08-31 | Irdeto B.V. | Device and method for establishing secure trust key |
US8417965B1 (en) | 2010-04-07 | 2013-04-09 | Xilinx, Inc. | Method and circuit for secure definition and integration of cores |
US8898759B2 (en) | 2010-08-24 | 2014-11-25 | Verizon Patent And Licensing Inc. | Application registration, authorization, and verification |
US8984293B2 (en) | 2010-11-19 | 2015-03-17 | Microsoft Corporation | Secure software product identifier for product validation and activation |
US8775797B2 (en) | 2010-11-19 | 2014-07-08 | Microsoft Corporation | Reliable software product validation and activation with redundant security |
US9210557B2 (en) | 2011-04-12 | 2015-12-08 | Yahoo! Inc. | SMS-initiated mobile registration |
TWI447653B (en) | 2011-05-20 | 2014-08-01 | Abancast Ltd | A mobile phone and a data authentication system of the dual chip of the smart card |
US9532097B1 (en) * | 2011-10-31 | 2016-12-27 | The Directv Group, Inc. | Method and system for controlling a controlled device with a remote control device through a display device |
US8595770B2 (en) * | 2011-10-31 | 2013-11-26 | The Directv Group, Inc. | Aggregated content distribution system and method for operating the same |
US8555079B2 (en) | 2011-12-06 | 2013-10-08 | Wwpass Corporation | Token management |
US9800405B2 (en) | 2012-03-02 | 2017-10-24 | Syphermedia International, Inc. | Blackbox security provider programming system permitting multiple customer use and in field conditional access switching |
US9032501B1 (en) | 2014-08-18 | 2015-05-12 | Bionym Inc. | Cryptographic protocol for portable devices |
US10348501B2 (en) * | 2015-07-10 | 2019-07-09 | Inside Secure | Method and apparatus for a blackbox programming system permitting downloadable applications and multiple security profiles providing hardware separation of services in hardware constrained devices |
-
2017
- 2017-10-23 US US15/791,260 patent/US10476883B2/en not_active Expired - Fee Related
-
2019
- 2019-11-12 US US16/681,465 patent/US20200153840A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
US20180145988A1 (en) | 2018-05-24 |
US10476883B2 (en) | 2019-11-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10476883B2 (en) | Signaling conditional access system switching and key derivation | |
EP2820546B1 (en) | Blackbox security provider programming system permitting multiple customer use and in field conditional access switching | |
US10348501B2 (en) | Method and apparatus for a blackbox programming system permitting downloadable applications and multiple security profiles providing hardware separation of services in hardware constrained devices | |
US20190222878A1 (en) | System and method for managing in-field deployment of multiple conditional access and watermarking systems | |
US11228427B2 (en) | System and method for securing content keys delivered in manifest files | |
US7620179B2 (en) | System and method for security processing media streams | |
KR100408225B1 (en) | Improved conditional access and content security method | |
US9203617B2 (en) | Secure provisioning of integrated circuits at various states of deployment, methods thereof | |
US20060272022A1 (en) | Securely configuring a system | |
CN102075513B (en) | Apparatuses, systems, and methods for renewability with digital content protection systems | |
JP5933705B2 (en) | Receiver software protection | |
US20050066355A1 (en) | System and method for satellite broadcasting and receiving encrypted television data signals | |
JP6146476B2 (en) | Information processing apparatus and information processing method | |
US20200004933A1 (en) | Method and apparatus for a blackbox programming system permitting downloadable applications and multiple security profiles providing hardware separation of services in hardware constrained devices | |
ES2693064T3 (en) | Procedure for transmitting and receiving multimedia content | |
US10397203B2 (en) | Reception device and reception method | |
WO2018130935A1 (en) | Signaling conditional access system switching and key derivation | |
US8621236B2 (en) | Method for activating at least a function on a chipset and chipset for the implementation of the method | |
US11310061B2 (en) | Capability revocation in a content consumption device | |
US9026800B2 (en) | Method and system for allowing customer or third party testing of secure programmable code | |
WO2016088273A1 (en) | Security device and control method | |
Tarate | Using ARM TrustZone to Implement Downloadable CAS Framework and Secure Media Pipeline in IPTV Client Devices | |
KR20110066826A (en) | Method for downloading conditional access system/digital right management by using trusted platform module | |
KR100950596B1 (en) | Broadcasting receiving apparatus based on downloadable conditional access system and method for reinforcing security thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |