Patent Publication Number: US-9904809-B2

Title: Method and system for multi-level security initialization and configuration

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS/INCORPORATION BY REFERENCE 
     This application is a continuation-in-part of, and claims priority to U.S. patent application Ser. No. 11/362,696, which was filed on Feb. 27, 2006. This patent application also makes reference to, claims priority to and claims benefit from U.S. Provisional Patent Application Ser. No. 60/814,840 filed on Jun. 19, 2006. 
     The above stated application is hereby incorporated herein by reference in its entirety. 
    
    
     FIELD OF THE INVENTION 
     Certain embodiments of the invention relate to security processor systems. More specifically, certain embodiments of the invention relate to a method and system for multi-level security initialization and configuration. 
     BACKGROUND OF THE INVENTION 
     In an increasingly security-conscious world, protecting access to information and/or to systems from unwanted discovery and/or corruption is a major issue for both consumers and businesses. Many consumer or business systems may be vulnerable to unwanted access when the level of security provided within the system is not sufficient for providing the appropriate protection. In this regard, consumer systems, such as multimedia systems, for example, may require the use of integrated architectures that enable security management mechanisms for defining and administering user rights or privileges in order to provide the necessary protection from unwanted access. 
     An example of a multimedia system that may be accessed by many different users may be a set-top box where manufacturers, vendors, operators, and/or home users may have an interest in accessing at least some limited functionality of the system. In some instances, a single device, such as a security processor for example, may be utilized to administer security operations in the multimedia system. The security processor may operate independently of other components in the multimedia system when determining rights or privileges of different users to various features in the multimedia system. For example, vendors may have limited access to some of the functions that may be accessible by the manufacturer. Home users may only have access to a subset of the vendors&#39; access rights. In some instances, secure operations may be managed by specifying, in a single location, secure conditions for each security component supported by the system. 
     However, there may be several limitations with such a straightforward implementation. On a typical security system, the number of user modes and security components may be sufficiently large that the size of the security management and/or control information may require large amounts of memory. There may be a significant number of access control entries that may correspond to instances when access rights may not be granted and/or instances when the access rights may be the same for multiple user modes and/or for multiple security components, such as default settings, for example. The addition or removal of user modes or security components may pose various implementation challenges, which increases hardware and/or software complexity. As software and/or hardware complexity grows by, for example, increasing the number of secure components in the security system, it may become more challenging to manage security operations without introducing security breaches or other concerns. 
     Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings. 
     BRIEF SUMMARY OF THE INVENTION 
     A system and/or method is provided for multi-level security initialization and configuration, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims. 
     These and other advantages, aspects and novel features of the present invention, as well as details of an illustrated embodiment thereof, will be more fully understood from the following description and drawings. 
    
    
     
       BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS 
         FIG. 1  is a block diagram illustrating an exemplary secure system architecture for multi-level initialization and configuration of security components, in accordance with an embodiment of the invention. 
         FIG. 2A  is a block diagram illustrating an exemplary processing unit as a security component in a secure system architecture architecture, in accordance with an embodiment of the invention. 
         FIG. 2B  is a block diagram illustrating an exemplary I/O module or memory controller as a security component in a secure system architecture, in accordance with an embodiment of the invention. 
         FIG. 3  is a diagram illustrating eight exemplary security control operational modes for security components based on three discrete security control states, in accordance with an embodiment of the invention. 
         FIG. 4  is a flow diagram illustrating exemplary steps for establishing a security control operational mode in a security component, in accordance with an embodiment of the invention. 
         FIG. 5  is a flow diagram illustrating exemplary steps for utilizing a CPU configuration command to activate or deactivate an enabled security component, in accordance with an embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Certain embodiments of the invention may be found in a method and system for multi-level security initialization and configuration. Aspects of the invention may comprise a security system that includes a security processor, a host processor, and at least one security component, such as a descrambler. The security processor may enable a security component based on information stored within a non-volatile memory integrated within the security processor. The host processor may enable generation of at least one configuration command communicated to the security processor for configuring the enabled security component. The configuration command may correspond to a security control operational mode for the security component that may indicate, for example, activation or deactivation of the security component. The security processor may authenticate a digital signature in the configuration command. Initialization and configuration may be performed during a system boot sequence of the security system. 
       FIG. 1  is a block diagram illustrating an exemplary secure system architecture for multi-level initialization and configuration of security components, in accordance with an embodiment of the invention. Referring to  FIG. 1 , there is shown a security system  100  that may be implemented as a single integrated chip, for example. In this regard, the security system  100  may be implemented as a system-on-a-chip (SOC) device, for example. The security system  100  may comprise at least one memory controller (MC)  106 , at least one input/output (I/O) module (IOM)  108 , at least one processing unit (PU)  110 , a security processor  102 , a host processor or host central processing unit (CPU)  104 , at least one secure bus  112 , a control bus  116 , and a data bus  118 . The plurality of MCs  106 , the plurality of IOMs  108 , and/or the plurality of PUs  110  may be referred to as security components within the security system  100 . In the exemplary embodiment described in  FIG. 1 , the security system  100  is shown comprising a plurality of processing units labeled PU 1    110   1 , . . . , PU M    110   M , . . . , PU P    110   P , a plurality of I/O modules labeled IOM 1    108   1 , . . . , IOM N    108   N , . . . , IOM Q    108   Q , and a plurality of memory controllers labeled MC 1    106   1 , . . . , MC K    106   K . The bus architecture provided by the security system  100  may enable scalability and may easily support the addition and/or removal of security components. 
     A memory controller  106  may comprise suitable logic, circuitry, and/or code that may enable accessing data from memory and/or storing data to memory. In this regard, the plurality of memory controllers MC 1    106   1 , . . . , MC K    106   K , shown in  FIG. 1  may utilize bidirectional interfaces  122   1 , . . . ,  122   K , respectively, to communicate with memory. An example of a memory controller  106  may be a 32-bit double data rate (DDR) memory controller. A processing unit  100  may comprise suitable logic, circuitry, and/or code that may enable processing of multimedia data. For example, a PU  100  may be an MPEG video or audio decoder that may be implemented in hardware as an application specific integrated circuit (ASIC) module or in a program as software/firmware executed in an integrated digital signal processor (DSP). A PU  100  may also be a descrambler that may be utilized for applications that support data encryption standard (DES), triple DES (TDES) or triple data encryption algorithm (TDEA), advanced encryption standard (AES), conditional access (CA) system for digital video broadcasting (DVB), and/or the block cipher MULTI2 that may be used for encryption of high-definition broadcasts, for example. 
     An I/O module  108  may comprise suitable logic, circuitry, and/or code that may enable communication with devices external to the security system  100 . In this regard, the plurality of plurality of I/O modules IOM 1    108   1 , . . . , IOM N    108   N , . . . , IOM Q    108   Q , described in  FIG. 1  may utilize bidirectional interfaces  120   1 , . . . ,  120   N , . . . ,  120   Q , respectively, to communicate with devices external to the security system  100 . An example of an I/O module  108  may be a universal serial bus (USB) 2.0 interface. Other examples of I/O modules may comprise modules that support inter-integrated circuit (I2C) interface, serial peripheral interface (SPI) bus, joint test action group (JTAG) standard for testing access ports and boundary scanning, and/or enhanced JTAG (EJTAG), for example. 
     The security processor  102  may comprise suitable logic, circuitry, and/or code that may enable control, initialization and configuration, and/or management of security operations and/or functionalities in the security system  100 . In this regard, the security processor  102  may communicate security information to memory controllers, I/O modules, and/or processing units via the at least one secure bus  112 . The security processor  102  may also communicate with the host processor  104  via at least one of the control bus  116  and the data bus  118 . In some instances, the security processor  102  may be disabled and the security system  100  may be operated as a multimedia device with minimum security features controlled by the host processor  104 . The security processor  102  may also comprise a non-volatile memory (NVM)  102   a  and/or a read-only memory (ROM)  102   b . The NVM  102   a  may comprise suitable logic, circuitry, and/or code that may be utilized to store information that may be utilized for initialization and configuration of security components in the security system  100 . Similarly, the ROM  102   b  may comprise suitable logic, circuitry, and/or code that may be utilized to store information that may be utilized for initialization and configuration of security components in the security system  100 . 
     The host CPU  104  may comprise suitable logic, circuitry, and/or code that may enable control and/or management of operations in the security system  100 . In this regard, the host CPU  104  may be utilized for initialization and configuration of security components in the security system  100 , such as memory controllers, I/O modules, and/or processing units, for example. The host CPU  104  may communicate with other components in the security system  100  via at least one of the control bus  116  and the data bus  118 . In this regard, the host CPU  104  may communicate with the security processor  102  via the control bus  116  and the data bus  118 . 
     The data bus  118  may be utilized for multimedia data transfer between components in the security system  100 . The control bus  116  may be utilized for control and initialization and configuration data transfer. For example, the control bus  116  may be utilized to read and/or write to registers. The secure buses  112  may be utilized for security control and configuration data transfer. For example, the secure buses  112  may be utilized to read and/or write to secure registers. In this regard, the secure buses  112  may be communicatively coupled to components of the security system  100  that may require secure registers and/or secure data access. The secure buses  112  may also be utilized for delivery of encryption and/or decryption keys to functional units that require keys for cryptographic operations, such as block cipher operations, for example. For example, the processing unit PU P    100   P  in  FIG. 1  may not utilize encryption and/or decryption keys and need not be connected to a secure bus  112  utilized for key delivery. 
     The bus architecture of the security system  100  need not be limited to the exemplary architecture disclosed in  FIG. 1 . For example, a portion of the at least one secure bus  112  may be implemented as a secure part or band of the control bus  116 . A secure part or band may refer to a portion of the control bus  116  that may be utilized for communicating secure control information, for example. In another example, the functions provided by the data bus  118  may be implemented by a plurality of data buses based on the different types of data being processed in the security system  100 , wherein the plurality of data buses may be connected via bus bridges. 
     The security system  100  may enable multiple levels for the initialization and configuration of the security components. In this regard, in an exemplary embodiment of the invention, the security system  100  may utilize three discrete security control states for each security system component. The three discrete security control states may correspond to the security component being enabled or disabled, active or inactive, and owned or unowned. The use of three discrete security control states may result in eight possible security control operational modes for each component in the security system  100 . Providing any of the eight possible security control operational modes may be achieved, at least in part, by programming the corresponding information in the NVM  102   a  and/or the ROM  102   b  in the security processor  102 . The security processor  102  and/or the host CPU may be utilized for performing initialization and configuration operations to provide security components with the three discrete security control states that correspond to the appropriate security control operational mode. 
       FIG. 2A  is a block diagram illustrating an exemplary processing unit as a security component in a secure system architecture, in accordance with an embodiment of the invention. Referring to  FIG. 2A , there is shown a processing unit  200  that may comprise a secure register  202  and a key memory  204 . The processing unit  200  may comprise suitable logic, circuitry, and/or code that may enable execution of multimedia applications that may require encryption and/or decryption operations. The encryption and/or decryption operations may be based on the DES, TDES, AES, encryption techniques for DVB, and/or MULTI2 for high-definition broadcasts, for example. In this regard, the processing unit  200  may be a descrambler that supports at least one scrambling or encryption technology. General configuration and/or control information to be utilized and/or generated by the processing unit  200  may be communicated via the control bus  116 . General data to be utilized and/or generated by the processing unit  200  may be communicated via the data bus  118 . Moreover, secure initialization and configuration operations provided by the security processor  102  may be communicated via the at least one secure bus  112 . 
     The secure register  202  may comprise suitable logic, circuitry, and/or code that may enable communicating information with the security processor  102  via the at least one secure bus  112 . In this regard, the secure register  202  may only be read and/or be written by the security processor  102 . The secure register  202  may be implemented as a single register or as set of registers, for example. The secure register  202  may be specified based initialization and configuration operations and/or functionalities of the processing unit  200 . For example, at least one bit in the security register  202  may be utilized for enabling and/or disabling control of security functions in the processing unit  200 . At least one bit in the security register  202  may be utilized for activating and/or deactivating control of security functions in the processing unit  200 . At least one bit in the security register  202  may be utilized for controlling a mode of operation of the processing unit  200 . The mode of operation may indicate an input and/or output data routing, allowing and/or disallowing key loading by the security processor  102  and/or the host processor  104 , and/or selection of a security algorithm, for example. The key memory  204  may comprise suitable logic, circuitry, and/or code that may enable storing decryption and/or encryption keys communicated from the security processor  102  via the at least one secure bus  112  and/or from the host CPU  104  via the control bus  116 . In this regard, the key memory  204  may be implemented utilizing a write-only random access memory (RAM), for example. 
       FIG. 2B  is a block diagram illustrating an exemplary I/O module or memory controller as a security component in a secure system architecture, in accordance with an embodiment of the invention. Referring to  FIG. 2B , there is shown an interface block  210  that may comprise a secure register  222  and a key memory  224 . The interface block  210  may correspond to an I/O module  108  or a memory controller  106  as disclosed in  FIG. 1 . The interface block  210  may comprise suitable logic, circuitry, and/or code that may enable communication with devices external to the security system  100  via the interface  212 . In this regard, the interface block  210  may perform secure operations on at least a portion of the communicated data. For example, the interface block  210  may enable high bandwidth digital content protection (HDCP) and may utilize a key protection mechanism for secure interfaces to digital displays, such as digital visual interface (DVI) and high definition multimedia interface (HDMI), for example. The interface block  210  may also support I2C interface, SPI bus, JTAG, and/or EJTAG, for example. General configuration and/or control information to be utilized and/or generated by the interface block  210  may be communicated via the control bus  116 . Data to be utilized and/or generated by the interface block  210  may be communicated via the data bus  118 . Moreover, secure initialization and configuration operations provided by the security processor  102  may be communicated via the at least one secure bus  112 . 
     The secure register  222  and the key memory  224  in the interface block  210  may be the same as or substantially similar to the secure register  202  and the key memory  204  disclosed in  FIG. 2A , respectively. For example, the secure register  222  may only be read and/or be written to by the security processor  102 , may be implemented as a single register or as set of registers, and may be specified based on its functionalities. The key memory  224 , for example, may store decryption and/or encryption keys communicated from the security processor  102  via the at least one secure bus  112  and/or from the host CPU  104  via the control bus  116 , and may be implemented utilizing a write-only RAM, for example. 
       FIG. 3  is a diagram illustrating eight exemplary security control operational modes for security components based on three discrete security control states, in accordance with an embodiment of the invention. Referring to  FIG. 3 , there are shown eight security control operational modes for security components in the security system  100 . The eight security control operational modes may comprise a first mode (S 1 )  302 , a second mode (S 2 )  304 , a third mode (S 3 )  306 , a fourth mode (S 4 )  308 , a fifth mode (S 5 )  310 , a sixth mode (S 6 )  312 , a seventh mode (S 7 )  314 , and an eighth mode (S 8 )  316 . For each mode there are three corresponding discrete security control states. For mode S 1 , the states may be enabled, active, and owned. For mode S 2 , the states may be disabled, active, and owned. For mode S 3 , the states may be enabled, inactive, and owned. For mode S 4 , the states may be disabled, inactive, and owned. For mode S 5 , the states may be enabled, active, and unowned. For mode S 6 , the states may be disabled, active, and unowned. For mode S 7 , the states may be enabled, inactive, and unowned. For mode S 8 , the states may be disabled, inactive, and unowned. 
     Ownership of the security component of a security system may correspond to a first discrete security control state or first level of initialization and configuration. The owner of a security component may be defined as the user who initializes and configures the secret or secure information in the security processor  102 , for example. The owner of the security processor  102  may have the highest level of control of the security system  100 . The process of taking ownership may be user specific and may be controlled, at least in part, by procedural safeguards implemented in the production process. In this regard, the production process may comprise storing the appropriate information into the NVM  102   a  and/or the ROM  102   b  in the security processor  102 . 
     Enabling or disabling a security component and its features in the security system  100  may correspond to a second discrete security control state or second level of initialization and configuration. In some instances, the security components, such as the plurality of MCs  106 , the plurality of IOMs  108 , and/or the plurality of PUs  110  disclosed in  FIGS. 1-2B , and their corresponding features may be enabled or disabled for specified user modes in order to be compliant with system security requirements. The enabling or disabling process may be enforced by the security processor  102  based on information programmed into the NVM  102   b  and on security processor ROM code, for example. 
     A final discrete security control state or level of initialization and configuration may occur after ownership has taken place and the security system  100  is ready for operation. In this regard, during a system boot sequence, the security system  100  may be enabled to transition from a power-off state to one where the security system  100  begins the initialization and configuration level for operation. Entering the system boot sequence may be a result of power being applied to the security system  100  or a hard reset operation, for example. The initialization and configuration for operation may comprise activating or deactivating at least one security component in the security system  100 . Such activation or deactivation operations may be performed based on at least one configuration command communicated to the security processor  102  from the host CPU  104 , for example. 
       FIG. 4  is a flow diagram illustrating exemplary steps for establishing a security control operational mode in a security component, in accordance with an embodiment of the invention. Referring to  FIG. 4 , there is shown a flow diagram  400  for providing a security control operational mode based on establishing three discrete security control state on a security component. In step  404 , after start step  402 , the first discrete security control state of ownership may be established based on specifications or requirements determined by the user through a controlled production process that utilizes procedural safeguards. In this regard, the production process may comprise storing the appropriate security information associated with security components in the security system  100  into the NVM  102   a  and/or the ROM  102   b  in the security processor  102 . 
     In step  406 , the security processor  102  may provide the second discrete security control state of enabling or disabling security components and/or specified features provided by the security components based on information programmed into the NVM  102   b  and on security processor ROM code. In this regard, the security processor  102  may program information into secure registers and/or key memory within the security components for enabling and/or disabling the components or specified features. For example, for the processing unit  200  in  FIG. 2A , the security processor  102  may communicate enabling and/or disabling information via the at least one secure bus  112 . In another example, for the interface block  210  in  FIG. 2A , the security processor  102  may communicate enabling and/or disabling information via the at least one secure bus  112 . 
     In step  408 , the security system  100  may utilize a system boot sequence after powering up or after a hard reset during which additional initialization and configuration operations may occur. In step  410 , the initialization and configuration for operation of the security system  100  may provide a third discrete security control state by activation or deactivation of enabled security components and/or features provided by the enabled security components. In this regard, the security processor  102  may program information into secure registers and/or key memory within the security components for activating and/or deactivating the components or specified features. For example, for the processing unit  200  in  FIG. 2A , the security processor  102  may communicate activation and/or deactivation information via the at least one secure bus  112 . In another example, for the interface block  210  in  FIG. 2A , the security processor  102  may communicate activation and/or deactivation information via the at least one secure bus  112 . The security processor  102  may perform the activation or deactivation operations based on at least one configuration command communicated from the host CPU  104 . 
     With eight modes available for security control operation, the security components in the security system  100  may be flexible and may accommodate a wide range of usage scenarios. In this regard, each security component in the security system  100  may be provided with one of the eight security control operational modes. For example, a DES descrambler in an owned security system may be enabled via a control bit in the NVM  102   a  in the security processor  102  and may be activated or deactivated, also referred to as inactive, via a configuration command provided by the security processor  102  communicated from the host CPU  104 . 
     Utilizing a configuration command may restrict the usage of certain module or security component by programming registers in the security component or by updating checking mechanisms in the security processor  102 . In this regard, the host CPU  104  may not utilize the configuration commands to relax existing restrictions because the system architecture may not enable the use of host software for this purpose. The use of a configuration command may also be applicable to other security features such as features provided by security components for interface security, for example. For example, some bits in the NVM  102   b  may be programmed to enable features and/or security components that support features such as I2C, SPI, JTAG, and/or EJTAG. In this regard, the configuration command may be utilized to set states that restrict these features so that they may be activated after the host CPU  104  passes an authentication test or deactivated for shotdown, for example. 
       FIG. 5  is a flow diagram illustrating exemplary steps for utilizing a CPU configuration command to activate or deactivate an enabled security component, in accordance with an embodiment of the invention. Referring to  FIG. 5 , there is shown a flow diagram  500 . In step  504 , after start step  502 , based on security requirements for the security system  100 , when a bit in the NVM  102   a  is utilized to enable a DVB descrambler in the security system  100 , the process may proceed to step  506 . In step  506 , the host CPU  104  may utilize a configuration command sent to the security processor  102  to activate or deactivate at least a portion of the enabled DVB descrambler. After step  506 , the process may proceed to step  510 . 
     Returning to step  504 , based on security requirements for the security system  100 , when a bit in the NVM  102   a  is utilized to disable a DVB descrambler in the security system  100 , the process may proceed to step  508 . In step  508 , the host CPU  104  may not utilize a configuration command sent to the security processor  102  to activate at least a portion of the disabled DVB descrambler. After step  508 , the process may proceed to step  510 . 
     Accordingly, the present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in at least one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. 
     The present invention may also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form. 
     While the present invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiment disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims.