System for secure provisioning and execution of System-on-Chip (SOC) features

Abstract

The present invention relates to a system for secure provisioning and execution of system-on-chip (SOC) features. A system and method for provisioning IP features in a system-on-chip are disclosed. A plurality of identical chips are manufactured, each of which is capable of having several features that are enabled or disabled. By default, all functions are disabled. A production process is later carried out, in which the chip is installed in a larger device. During this process, the manufacturer requests permission from the IP owner for the enablement of various features. Using secure communications, a permission is granted that identifies the features to be enabled and the quantity of units that are allowed to be manufactured. The permission information is encrypted using a key known to the chip and sent to the manufacturer. The chip receives the permission information during provisioning, extracts the relevant provisioning information using the key, and a secure processing system provisions the relevant features. Log information is generated to allow the IP owner to verify license compliance.

Description

Technical Field

[0001] The present invention relates to a system and method for provisioning features of a system on a chip (SoC). Background Art

[0002] IP owners seeking to have a chip designed and / or manufactured to meet their specifications will often request that the chip be able to perform a large number of features. However, for each specific customer, a small fraction of the available features on a given chip can actually be authorized for use. Traditionally, the provisioning of authorized features has been handled by designing and manufacturing the chip to include all possible features. Then, during the actual manufacturing process of a particular chip, a read-only memory is programmed with the features available to the customer, which results in the features being unlocked. Functions not identified in the memory remain locked and cannot be used by the customer. Summary of the invention

[0003] Aspects of the present invention relate to an integrated circuit chip for production into a host device, and the integrated circuit chip includes: a feature library, which manages multiple functional features that can be implemented by the integrated circuit chip, each of the multiple functional features is in a default disabled state; a central processing unit (CPU), which is configured to receive an encrypted configuration file from a production server; a trusted execution environment, which is preprogrammed with a decryption key and is configured to: decrypt the configuration file using the preprogrammed decryption key; and enable one or more of the multiple functional features based on the decrypted configuration file.

[0004] In another aspect of the present invention, a server for managing licenses between owners of on-chip features and device manufacturers includes: a database; a communication interface configured to receive a license request from the manufacturer for a license to enable the on-chip features, and to transmit a notification to the IP owner associated with the on-chip features to facilitate receipt of the license request; a license generator configured to generate a license contract in response to receiving a license approval, the license contract including a list of features to be enabled and a license date range; and a license manager configured to store a copy of the license contract in the database in association with the manufacturer and the IP owner, and to forward the license contract to the manufacturer.

[0005] In another aspect of the present invention, a server for implementing a provisioning process regarding an integrated circuit chip includes: a transceiver configured to receive a license contract from a license management server, the license contract including a chip identifier and an encrypted payload; a memory storing the license contract; a processor configured to detect a device undergoing provisioning and identify the license contract in the memory based on the detected device; a secure communicator configured to transmit the encrypted payload to the device for provisioning via a secure communication channel and receive a log file when the provisioning is completed, wherein the transceiver is further configured to transmit the log file to the license management server. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the invention and, together with the description, further serve to explain the principles of the invention and enable those skilled in the relevant art to make and use the embodiments.

[0007] Figure 1 A block diagram illustrating an exemplary provisioning environment according to an embodiment of the present invention.

[0008] Figure 2 A block diagram illustrating an exemplary license management system according to an embodiment of the present invention.

[0009] Figure 3 A block diagram illustrating an OEM server supporting a provisioning environment.

[0010] Figure 4 A block diagram illustrating an apparatus (Customer Premises Equipment - CPE) according to an exemplary embodiment of the present invention.

[0011] Figure 5 A flow chart illustrating a method for provisioning features in a device.

[0012] Figure 6 A block diagram illustrating an exemplary field provisioning environment according to an embodiment of the present invention.

[0013] Figure 7 A block diagram illustrating an exemplary computer configuration according to an embodiment of the present invention.

[0014] The present invention will be described with reference to the accompanying drawings. In the drawings, like reference numerals indicate identical or functionally similar elements. In addition, the leftmost digit of a reference numeral identifies the figure in which the reference numeral first appears. DETAILED DESCRIPTION

[0015] The following detailed description refers to the accompanying drawings to illustrate exemplary embodiments consistent with the present invention. References in the detailed description to "an exemplary embodiment," "exemplary embodiment," "example exemplary embodiment," and the like indicate that the exemplary embodiment described may include specific features, structures, or characteristics, but each exemplary embodiment may not necessarily include the specific features, structures, or characteristics. In addition, such phrases do not necessarily refer to the same exemplary embodiment. In addition, when a specific feature, structure, or characteristic is described in conjunction with an exemplary embodiment, it is within the knowledge of a person skilled in the relevant art to implement this feature, structure, or characteristic in conjunction with other exemplary embodiments, whether or not explicitly described.

[0016] The exemplary embodiments described herein are provided for illustrative purposes only and are not intended to be limiting. Other exemplary embodiments are possible, and the exemplary embodiments may be modified within the spirit and scope of the present invention. Therefore, the specific embodiments are not intended to limit the present invention. Rather, the scope of the present invention is defined only by the appended claims and their equivalents.

[0017] The embodiments may be implemented in hardware (e.g., circuits), firmware, software, or any combination thereof. The embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. The machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, the machine-readable medium may include a read-only memory (ROM); a random access memory (RAM); a disk storage medium; an optical storage medium; a flash memory device; an electrical, optical, acoustic, or other form of propagation signal (e.g., a carrier wave, an infrared signal, a digital signal, and the like), and others. In addition, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be understood that such descriptions are merely for convenience, and such actions are actually generated by a computing device, a processor, a controller, or other devices that execute firmware, software, routines, instructions, and the like. In addition, any implementation changes may be implemented by a general-purpose computer, as described below.

[0018] For the purposes of this discussion, any reference to the term "module" should be understood to include at least one of software, firmware, or hardware (e.g., one or more circuits, microchips, or devices, or any combination thereof), and any combination thereof. In addition, it should be understood that each module may include one or more components within an actual device, and each component forming part of the described module may function cooperatively or independently of any other component forming part of the module. Conversely, multiple modules described herein may represent a single component within an actual device. Furthermore, the components within a module may be in a single device or distributed among multiple devices in a wired or wireless manner.

[0019] The following detailed description of the exemplary embodiments will disclose the general nature of the invention so fully that others can easily modify and / or adapt such embodiments for various applications without undue experimentation by applying the knowledge of those skilled in the relevant art without departing from the spirit and scope of the invention. Therefore, based on the teachings and guidance presented herein, such adjustments and modifications are intended to be within the meaning and multiple equivalents of the exemplary embodiments. It should be understood that the terms or terminology herein are for the purpose of description and not limitation, so that the terms or terminology of this specification will be interpreted by those skilled in the relevant art in accordance with the teachings herein.

[0020] Previous implementations for provisioning features in chips required the device manufacturer to receive a list of unlocked features from the IP owner and program memory within the device to specifically identify the unlocked features. Therefore, each device had to be customized for each customer. As a result, the responsibility for enforcing the IP owner's license agreement fell indirectly on the device manufacturer, and there was no reliable means of verification or enforcement.

[0021] In view of the foregoing, there is a need for a provisioning system that can be implemented by IP owners that can allow for verification and / or tracking of licenses to ensure compliance with licensing agreements.

[0022] Supply Environment

[0023] Figure 1 A block diagram of an exemplary provisioning environment 100 according to an embodiment of the present invention is illustrated. The environment 100 includes a production side 110 and a cloud side 150. The cloud side 150 of the environment 100 is responsible for managing production licenses, including obtaining approval and granting such licenses. The cloud side 150 is also responsible for providing compliance monitoring to IP owners. Across a network 130, the production side 110 of the environment 100 is responsible for implementing provisioning and device production, as well as reporting on production results and license usage. These and other aspects of the present invention will be further disclosed in detail below.

[0024] The production side 110 and the cloud side 150 are separated from each other by a network 130. The network 130 is assumed to be neither persistent nor trusted, such as, for example, the Internet. The cloud side 150 of the environment includes a license management server 132, an approver 134, an original terminal manufacturer (OEM) 138, and an IP (intellectual property) owner 136. The IP owner 136 is the licensor in the provisioning process. The IP owner 136 owns the rights to the technology, features, and / or services (hereinafter collectively referred to as "features") to be licensed to the end user or OEM for use. The OEM 138 is the manufacturer of the final device that includes the system on chip with the IP owner's features. The OEM 138 may request to use the IP owner's technology for personal use, or may be a mass-produced device that uses the technology for sale to customers, clients, etc.

[0025] Approver 134 is responsible for managing license management server 132. There are two types of approvers: the IP owner and the custodian of a company that has signed an agreement with the IP owner.

[0026] For the purposes of this discussion, a typical production transaction involves three main parties: chipmakers, IP owners, and OEMs. As discussed above, IP owners own intellectual property rights to the technology placed in the chip. Chipmakers manufacture chips according to specifications provided by IP owners and then place the chips into production devices (e.g., set-top boxes). OEMs manufacture final production devices (also referred to herein as "devices"), which include chips manufactured by chipmakers. In an embodiment, chipmakers like Broadcom Corp often receive requests from IP owners to manufacture chips containing a large number of optional features. These functions are constructed on the chip by hardware, software, or firmware, but are identified as lists in the chip memory. This list (also referred to as a feature library) contains the enabled or disabled state of the features. By default, all optional features are disabled, but can be enabled later by authorized OEMs during device production. On the cloud side 150, OEM 138 transmits feature requests to IP owner 136 via network 140. The feature request contains information sufficient to identify the OEM and the requested features. For example, in an embodiment, the feature request includes a unique identifier associated with OEM 138 and a list of requested features to be authorized. In an embodiment, the feature request may also include a quantity request indicating the number of licenses requested.

[0027] Upon receiving the feature request, IP owner 136 uses the information provided in the request to review and authorize / deny the request. There may be a variety of reasons for denying the request, including that the unique identifier is missing or not recognized, the quantity does not match the stored record, or there is no valid license agreement with OEM 138 associated with the request. On the other hand, if the request is valid and accurate, then IP owner 136 authorizes the request. Authorization is effected by IP owner 136 forwarding a response signal to OEM 138 and license management server 132 via network 140. In an embodiment, the response signal includes the same license information as that included in the initial request signal in order to inform license management server 132 of the information required to authorize OEM 138 at the production side 110 of environment 100.

[0028] Therefore, after receiving the response signal, the license management server 132 generates an IP license contract file and forwards the license contract file to the production side 110 of the environment 100. In an embodiment, the license contract file is an encryption-bound IP license contract file, which contains information such as an encrypted configuration payload that encodes IP activation information (e.g., information used by the production side to implement device production), a data code range that specifies the validity period of the license and the number of licenses granted. Within the license contract file, the effective date can be identified based on a time code that specifies the allowed production period and the period during which the licensed feature is valid (e.g., a feature subscription period). The license contract file may also include additional information, such as a production site code that identifies an authorized location that allows the device to be supplied, and an operating configuration that identifies the allowed operating modes.

[0029] The production side 110 includes an OEM server 114 and a device 112 to be manufactured, also known as customer premises equipment (CPE). The OEM server 114 includes production software 116 and a database 118. The OEM server 114 receives the license contract file via a network 130 and prepares the license information for implementation on the device 112. The trusted application (TA) running in the trusted execution environment (TEE) implements the provisioning in the device 112. Figure 4 TA and TEE are discussed in further detail.

[0030] OEM server 114 stores the license information in an encrypted format in database 118. OEM server 114 then constructs a configuration data block containing the encrypted configuration payload and data code range from the license contract file. The configuration payload remains encrypted throughout this process. Therefore, OEM server 114 is unaware of the contents of the configuration payload (e.g., the configuration payload is transparent to OEM server 114). OEM server 114 then communicates with device 112 via connection 115. It is assumed that connection 115 is persistent during the entire provisioning process.

[0031] OEM server 114 encrypts the configuration data block and encapsulates it in a provisioning message and sends the provisioning message to a trusted application running on device 112. The provisioning message may include provisioning information for multiple IP owners. In the described scenario, a separate configuration data block is included in the provisioning message for each IP owner.

[0032] The trusted application running within the TEE of the device 112 processes the configuration data and performs validation on all received configuration data blocks contained within the provisioning message (discussed in detail below). The TEE then securely activates or deactivates the IP features based on the provisioning information in the configuration payload. The trusted application encrypts the configuration data blocks using the system-on-chip hardware and non-volatile memory keys and provides the encrypted data to the software running on the device 112 for storage. The trusted application then generates a log of enabled IP licenses and encrypts the log into a crypto-binding and sends the log back to the OEM server 114 to be forwarded to the license management server 132 for compliance checking.

[0033] The license management server 132 decrypts and stores the log data for tracking and compliance purposes. The OEM 138 is responsible for periodically uploading the log files to the license management server 132 based on the IP owner 136 requirements. If connected to the cloud, the OEM server 114 can automatically report to the license management server 132.

[0034] The foregoing constitutes an overview of the operation of the exemplary disclosure and is expanded upon in further detail by the individual discussions below with respect to the license management server 132, the OEM server 114, and the device 112.

[0035] License Manager Server

[0036] Figure 2 A block diagram of an exemplary license management server 200 is illustrated according to an embodiment of the present invention. The license management server 200 includes a processing portion 210 and a database portion 240. The processing portion 210 includes a user interface 212, a log importer 214, a license generator 216, a user manager 218, a license manager 220, a log manager 222, and a transceiver 224. The license management server 200 represents an exemplary embodiment of the license management server 132.

[0037] The primary purpose of the license management server 200 is to host the license management software for the purpose of processing authorized licenses and to catalog log data from the OEM server 114 for review and compliance verification. To support these functions, the license management server 200 includes a data storage device of sufficient size for the operation of the software and for data backup. In addition, the license management server 200 has the necessary security provisions to support the security elements of the software. Specifically, the system 200 has access to a security server 230 that handles the security processing associated with license management. In an embodiment, the security server 230 is a hardware security module (HSM).

[0038] like Figure 2, user interface 212 allows a user to interact with the system and the software running on the system. This interaction allows an approver to review and approve / reject the license, etc. As discussed above, the license management server 200 receives a request for authorization from an approver 134 via the user interface 212. Using the user interface 212, the approver is able to associate the authorization with certain parameters and / or restrictions, as discussed in further detail below. Using this information associated with the authorization, the license generator 216 creates a license contract file, which will be forwarded to the OEM server 114 in the production side 110 to allow device production to begin.

[0039] The user manager 218 tracks users who are allowed to access the system and approve / deny permission requests. The license manager 220 maintains various permissions that have been granted and / or denied. In an embodiment, the license manager 220 tracks the issued licenses, the applicable date range associated with the licenses, and the amount of units authorized by the licenses. The log importer 214 receives log data from the OEM server 114 detailing the provisioning that has occurred. Such logs may include the number of units provided, the date of provisioning, the features enabled, etc. The log manager 222 compiles and updates the logs based on the received log information. The license manager 220 reviews the logs against the corresponding license data to ensure compliance and continued validity. For example, the license manager 220 accesses the license in order to determine the parameters and restrictions associated therewith. Then, the license manager 220 retrieves the logs associated with the license. The logs contain various information related to the provisioning that occurred, such as the date of provisioning, the features enabled, etc. By comparing the details in the logs with the parameters / restrictions in the license, the license manager 220 can evaluate whether the provisioning has been carried out within the scope of the license, or whether the license has been violated.

[0040] The license management server 200 may access a database 240 in which information related to users 242, licenses 244, approvals 246, and logs 248 is stored. This data may be retrieved for use by any of the components of the license management server 200, updated, and reloaded into the database 240 for future use. For example, upon receiving new log information related to a particular license, the log manager 222 retrieves previous log data from the log 248 within the database 240. The log manager 222 updates the log information and stores the newly updated information in the database 240. The license manager 220 then retrieves the relevant license from the licenses 244 of the database 240 and retrieves the updated log information stored in the log 248 of the database 240. As discussed above, the license manager 220 checks the log data against the license information for compliance or other purposes. Other components may access, update, and store data in the database for additional purposes.

[0041] OEM Server

[0042] Figure 3 A block diagram of the OEM server 300 is illustrated. The OEM server 300 includes a processing portion 310 and a database portion 330, and represents an embodiment of the OEM server 114.

[0043] Within the processing portion 310, the OEM server includes a license importer 314, a log manager 316, a user interface 312, a configuration container file (CCF) generator), provisioning 322, a license manager 324, customer premises discovery 326, and secure communications 328. The processing portion 310 communicates with a database 330. The database 330 stores various data useful in the provisioning process, including at least licenses 332 and logs 334.

[0044] The OEM server 300 is located at the OEM production facility and is managed by the OEM 138. The primary function of the OEM server 300 is to host the production software that implements the provisioning agreement and interfaces with the device 112. As with the license management server 200, the OEM server 300 should have sufficient storage to support the operation of the software as well as data backup. In addition, the OEM server 300 should have the necessary security provisions to support the security elements of the software.

[0045] The components shown in the processing portion 310 of the OEM server implement the functions of the software. For example, the production software implements two main functions: enforcing licensing policies during production via license verification (discussed in detail below); provisioning IP enablement during device production via a secure provisioning process (discussed in detail below).

[0046] Several of the components of the OEM server 300 perform functions similar to those of the license management system 200. For example, the OEM server 300 is accessible by the OEM 138, and the UI 312 provides an interface for allowing the OEM 138 to access. The log manager 316 records provisioning data. For example, the log manager 316 updates the log with the newly provisioned device information (e.g., date / time of provisioning, features provisioned, corresponding licenses associated with the provisioned features, etc.), and stores the log as log 334 in the database 330. The license importer 314 and the license manager 324 work together to receive, monitor, and verify licenses from the license management system 200. The received license is stored in the database 330 as license 332.

[0047] Provisioning 322 performs license analysis and authorizes provisioning of certain features described in the license. CCF generator 320 creates a configuration container file (CCF) that contains a list of features to be enabled and certain authorization information. The CCF is forwarded to device 112 via secure communication channel 115. Therefore, in an embodiment, the CCF is not encrypted or otherwise protected because channel 115 is secure. Device 112 enables the listed features in response to receipt of the CCF.

[0048] CPE discovery 326 detects the device being produced, and specifically the type of device for identifying the corresponding license. Once the device is discovered and identified, the appropriate license can be obtained and reviewed from database 330. Based on the information contained in the license, provisioning 322 and CCF generator 320 generate provisioning information to be sent to the device for enabling various features. Secure communication 328 manages the transmission and reception of data between device 112 and license management system 200.

[0049] In the OEM server 300, several of the components that communicate with external devices, such as a license importer, etc., are supported in their communication functions by a transceiver 318. The transceiver 318 may be configured to communicate wirelessly or through a wired connection and can act as a receiver and / or transmit data.

[0050] Device

[0051] Figure 4 A block diagram illustrating an apparatus 400 (Customer Premises Equipment - CPE) according to an exemplary embodiment of the present invention. Apparatus 400 includes a system on a chip 420 and represents an exemplary embodiment of apparatus 112.

[0052] The device 400 includes a communication interface 410 that sends and receives data between the OEM server 300 and the system on chip 420. During the provisioning process, the communication interface 410 can find the IP address of the OEM server 300 through configuration or discovery. As discussed above, it is assumed that the communication line between the device 400 and the OEM server 300 is secure. Thus, in an embodiment, the communication interface 410 does not have encryption or other security capabilities. In an embodiment, the network interface 410 can communicate via Ethernet, Multimedia over Coax Alliance (MoCA), Universal Serial Bus (USB), Universal Asynchronous Receiver-Transmitter (UART), etc.

[0053] The system on chip 420 includes a CPU 422, a trusted execution environment (TEE) 424, and a non-volatile memory (NVM) 426, and is connected to a flash memory 430. A host provisioning application (HPA) runs on the CPU 422. The HPA receives an initial provisioning request from the OEM server 300 and sends a request to the trusted application operating on the TEE to start the provisioning process. The CPU 422 is the main CPU of the device and is involved not only in the provisioning process but also in general chip functions. The configuration control file received from the OEM server 300 is stored in the flash memory 430. During provisioning, the TEE 424 handles all security-related tasks and CCF-based feature enablement. These and other features are discussed in further detail below.

[0054] The TEE 424 is used for security purposes. For example, the TEE is a secure virtual computing environment running on the SoC 420 that protects sensitive code and data. Typically, the TEE runs with a rich (untrusted) execution environment (REE). The TEE can be created in a variety of different ways. For example, there may be a dedicated security process where the TEE runs on a separate secure processor. Alternatively, TrustZone may be provided, which is a CPU-specific hardware and software implementation that can virtualize two CPU contexts: a "normal" world and a "secure" world. In addition, the TEE can be virtualized by using a hypervisor to divide the system into TEE and REE virtualization contexts. Within the TEE, a trusted application (TA) 425 operates to implement provisioning instructions authorized by the OEM server 300 as discussed above. As the name implies, the trusted execution environment and trusted applications are secure.

[0055] Supply Process

[0056] Figure 5 Flow chart of a method 500 for provisioning features in a device. The method 500 is mainly performed by the license management server 200, the OEM server 300 and the device 400, as described above with reference to Figures 2 to 4 Description. A description of method 500 is provided below with reference to earlier figures.

[0057] Permit Request / Approval

[0058] Initially, OEM 138 sends a request for an IP license to license management server 132 (510). The request includes all information necessary to identify the OEM and the parameters requested. For example, the request may include an identifier associated with OEM 138, the requested IP features, the amount of units to be authorized, an identifier of IP owner 136, etc.

[0059] After receiving the request, the license management system 132 sends a notification signal about the request to the IP owner 136 identified in the request or associated with the IP feature, thereby seeking its approval (515). This notification can be transmitted via secure email or other secure messaging formats. In response, the IP owner 136 logs into the license management system 132 / 200 via the user interface 212. There, the IP owner 136 can review and approve, reject or modify the request. In an embodiment, the IP owner 136 can also add comments, such as a valid date range that defines the valid time period for the approved license. The license manager 220 of the license management server 200 stores updated or non-updated licenses and IP owner responses in its database 240. In the license, the effective date identified by the IP owner can be included as a time code or date code, which specifies the allowed production period and the period (e.g., feature subscription period) during which the license feature is valid.

[0060] After the license has been approved, the license generator 216 generates a license contract (520). The license contract contains the license information required to implement the provisioning at the OEM production side 110, as well as records, etc. This information includes a configuration payload, an effective date range, OEM and IP owner identification, a production server ID, and a digital summary of the information contained in the license contract. The configuration payload specifies the terms of the license, including a list of IP characteristics and a request / approval timestamp. Once generated, the security server 230 encrypts at least the configuration payload and then forwards the license contract to the OEM server 114 via the network 130. In an embodiment, the OEM 138 is responsible for accessing the license management server 132 and downloading the license contract (523). This can be in response to a notification received from the license management server 132.

[0061] License Verification

[0062] After the OEM server 300 receives the license contract, the license manager 324 constructs a license file (525) based on the license contract. The license file is used to enforce the IP owner 136 license during production. The license file contains much of the same data as provided in the license contract, in addition to data required to oversee provisioning, such as enabled features, authorized units, effective date range, etc. The license file also contains fields to track the number of units that have been produced and / or the number of units to be produced. In an embodiment, the license file is encrypted to prevent tampering, replay, cloning, or other security vulnerabilities.

[0063] Before starting the provisioning process for the device, the license manager 324 verifies the license file (530). This verification process may involve many different checks. For example, the license manager 324 checks that the parameters in the license file are still applicable. These checks include determining that the current date is within the specified validity date range, determining the number of units that have not been reached, etc.

[0064] The verification of the license file may also include a check in conjunction with the license management server 200 to confirm that the license is valid. For example, duplicate use of the license (e.g., cloning) may be proven from repeated supply requests. To prevent cloning, the OEM server 300 establishes a beacon mechanism with the license management server 200. Specifically, the OEM server 300 periodically sends a beacon message to the license management server 200 and waits for confirmation. If the beacon fails (e.g., the response times out) for a predetermined number of times, the OEM server 300 stops supplying until the beacon succeeds. In an embodiment, the beacon signal includes OEM server identification, current license usage (including the original license file and the number of license instances used [e.g., the number of production units with license IP features]), and production line identification. It is worth noting that, in addition to being implemented before production, verification with the license management server 200 may also occur at any time thereafter during production.

[0065] After the license has been verified (530), provisioning begins.

[0066] supply

[0067] Once the license file is verified (530), the OEM server 300 begins exchanging information (535) with the device 400 to initiate provisioning. As part of this exchange, the OEM server 300 transmits a provisioning request to the device 400. In response, the host provisioning application (HPA) running on the CPU 422 of the device 400 sends a provisioning request to the TEE 424 by creating a secure session token with a trusted application operating within the TEE 424. The HPA then also reads the unique chip ID from the SoC 420 currently being generated / configured. The HPA then responds to the request from the OEM server 300. This response signal includes the secure session token and the unique chip ID.

[0068] The information contained in the response signal allows the OEM server 300 to identify all applicable licenses. Once identified, the CCF generator 320 creates a configuration container file (CCF) (540) that includes a configuration data block for each applicable license. Each configuration data block contains the corresponding license contract (including an encrypted configuration payload) and some chip specification information, such as the chip ID and license serial number. The OEM server 300 then forwards the CCF to the HPA operating on the device 400.

[0069] As discussed above, each configuration payload in the CCF is encrypted by the license management system 200, and the OEM server 300 does not have the keys required to decrypt this information. Therefore, the contents of the configuration payload remain invisible to the OEM server 300.

[0070] The device 400 receives the CCF via the communication interface 410 and forwards the CCF to the TEE 424 for processing. The trusted application operating on the TEE 424 is pre-programmed with a decryption key for the configuration payload contained in the CCF. Therefore, when receiving the CCF, the trusted application decrypts each of the configuration payloads (545). After each of the configuration payloads has been decrypted, the trusted application re-encrypts the CCF with the unique chip ID and the TEE specific key, and also generates a log file encrypted with the session encryption key. The log file contains information about the licenses supplied for each IP owner 136 and the features enabled in the device 112. Each IP owner section in the log is encrypted separately using the IP owner key that can only be processed by the license management processing system 132. The information contained in the log file includes a unique chip ID, a license contract, a license serial number, etc. During the supply period, this information is directly copied from the configuration data block received from the OEM server 300. The trusted application in the TEE 424 also generates a digital signal of the log data. The trusted application then forwards both the re-encrypted CCF and the encrypted log file to the HPA operating on CPU 422 .

[0071] The HPA installs the encrypted CCF file into the flash memory 430, which causes the provisioning feature to be enabled (545). Specifically, as discussed above, the chip has been equipped with all available features. However, the features remain in a default disabled state until provisioning occurs. Installing the CCF file into the flash memory 430 causes the registers associated with the provisioning feature to be flipped, thereby identifying the provisioning feature as enabled. In one embodiment, the flash memory 430 is a hard drive or other suitable non-flash memory. Once the feature has been enabled, final device production can be completed (555). After the HPA programs the flash memory 430 using the CCF, the HPA forwards the encrypted log (560) file to the production system 116 at the OEM server 300.

[0072] The license manager 316 within the OEM server 300 decrypts the log with the session encryption key and stores the log (565) in the database 330. The log manager 316 also marks the SoC as "provisioned" to prevent illegal re-provisioning. Periodically, upon request, or after the provisioning process is completed, the OEM server 300 sends the log file (570) to the license management system 200. The specific time to send the log file depends on the requirements associated with each IP owner 136. The log reporting parameters may be received with the original license contract and stored in the database for future reference in association with the received license or in association with the corresponding IP owner.

[0073] Method 500 ends with license management server 200 receiving the log file from OEM server 300 (575). Once at license management server 200, IP owner 136 is allowed to access, review, and analyze the log file for compliance of the license, etc. Additionally, as discussed above, license management server 200 may perform certain automated compliance checks.

[0074] By relative to Figures 1 to 4 The above method steps described with various components described in the present invention provide a secure method for provisioning features within a system on a chip. The method allows IP owners to protect their intellectual property in a secure and reliable manner without placing the burden on chip manufacturers to manufacture chips with different specifications for each customer.

[0075] After the provisioning process is complete, the device saves the multi-dimensional binding information from the licensing contract in its non-volatile memory (e.g., flash memory). This information includes information such as time code, production site code, and operating configuration.

[0076] On-site supply

[0077] Although the secure provisioning process described above is implemented in a device production facility, in other embodiments, provisioning can also be performed in the field - after device production. In such embodiments, device features can be enabled or disabled in the field, allowing dynamic provisioning. The following describes a system for field provisioning modified from a facility provisioning system.

[0078] Figure 6 A field provisioning environment 600 is illustrated according to an exemplary embodiment of the present invention. The environment 600 is similar to the facility provisioning environment 100 and is Figure 1 Components that remain unchanged retain their original numerical designations. New components are given new designations.

[0079] In an off-site configuration, the CCF is generated by the OEM server 114. However, in on-site provisioning, the license management system 132 generates the CCF and encapsulates it within a provisioning message appropriate to the communication method being implemented. For example, if the on-site provisioning is done over the Internet Protocol, the provisioning message will be sent as IP data. For MPEG, the message is sent via a carousel method, etc. The encapsulation wrapper contains the appropriate destination address that identifies the on-site device.

[0080] In this configuration, a host application operating on the CPU 422 of the device 112 receives and recognizes the provisioning message and extracts the CCF file from the transmission. As with the appliance-based configuration, the host application saves the CCF file in flash memory 430 (or other suitable memory). The trusted application running in the TEE 424 performs IP feature activation based on the stored CCF file when the device 112 is initialized. This is performed in substantially the same manner as the appliance-based configuration.

[0081] However, because device 112 does not have the benefit of OEM server 114, license management server 132 provides field provisioning tools to device 112. These tools include secure communication protocols with TEE 424, IP license enforcement, secure generation of configuration data, and secure collection of log data. More specifically, the field provisioning tools implement steps 535 to 560, as described above with reference to Figure 5 At the end of provisioning, the device 112 generates log data and forwards it to the license management server 132 .

[0082] In an embodiment, an operator message bridge 610 is provided between the device 112 and the license management server 132 to facilitate the message exchange between them. For example, the operator message bridge 610 performs the necessary message format adaptation between the Internet backhaul 130 and the access transport of the operator network 140. The operator message bridge 610 bridges the reformatted messages between these two sides. To support field provisioning, the access transport between the operator message bridge 610 and the device 112 is persistent. The backhaul connection between the operator message bridge 610 and the license management system 132 is also persistent.

[0083] In another embodiment, there is a persistent end-to-end Internet Protocol connection between the device 112 and the license management server 132. In this embodiment, the operator message bridge 610 is not required and is therefore excluded from the environment 600. In this embodiment, the scheduling of field provisioning is directly controlled by the license management system 132 or initiated by the device 112.

[0084] Exemplary Computer Implementation

[0085] It will be apparent to those skilled in the relevant art that the various elements and features of the present invention as described herein may be implemented in hardware using analog and / or digital circuits, in software, by the execution of computer instructions by one or more general or special purpose processors, or as a combination of hardware and software.

[0086] For completeness, the following description of a general purpose computer system is provided. Embodiments of the present invention may be implemented in hardware, or in a combination of software and hardware. Thus, embodiments of the present invention may be implemented in the context of a computer system or other processing system. For example, embodiments of the present invention may be implemented in the context of one or more computer systems or other processing systems. Figures 5 to 6 method. Figure 7 An example of such a computer system 700 is shown in FIG. One or more of the modules depicted in the previous figures may be implemented at least in part on one or more distinct computer systems 700.

[0087] Computer system 700 includes one or more processors, such as processor 704. Processor 704 can be a special purpose or general purpose digital signal processor. Processor 704 is connected to communication infrastructure 702 (e.g., a bus or network). Various software implementations are described based on this exemplary computer system. After reading this description, it will be clear to those skilled in the relevant art how to implement the present invention using other computer systems and / or computer architectures.

[0088] The computer system 700 also includes a main memory 706, preferably a random access memory (RAM), and may also include a secondary memory 708. The secondary memory 708 may include, for example, a hard disk drive 710 and / or a removable storage drive 712, which represents a floppy disk drive, a tape drive, an optical disk drive, and the like. The removable storage drive 712 reads from and / or writes to a removable storage unit 716 in a well-known manner. The removable storage unit 716 represents a floppy disk, a tape, an optical disk, and the like, which is read from and written to by the removable storage drive 712. As will be appreciated by those skilled in the relevant art, the removable storage unit 716 includes a computer-usable storage medium having stored therein computer software and / or data.

[0089] In alternative embodiments, the secondary memory 708 may include other similar means for allowing computer programs or other instructions to be loaded into the computer system 700. Such means may include, for example, a removable storage unit 718 and an interface 714. Examples of such means may include a program cartridge and cartridge interface (such as that found in a video game device), a removable memory chip (such as an EPROM or PROM) and associated sockets, a thumb drive and USB port, and other removable storage units 718 and interfaces 714 that allow software and data to be transferred from the removable storage unit 718 to the computer system 700.

[0090] The computer system 700 may also include a communication interface 720. The communication interface 720 allows software and data to be transferred between the computer system 700 and external devices. Examples of the communication interface 720 may include a modem, a network interface (such as an Ethernet card), a communication port, a PCMCIA slot and card, and the like. The software and data transferred via the communication interface 720 are in the form of signals, which may be electronic, electromagnetic, optical, or other signals capable of being received by the communication interface 720. These signals are provided to the communication interface 720 via a communication path 722. The communication path 722 carries the signals and may be implemented using wires or cables, optical fibers, a telephone line, a cellular phone link, an RF link, and other communication channels.

[0091] As used herein, the terms "computer program media" and "computer readable media" are generally used to refer to tangible storage media, such as removable storage units 716 and 718 or a hard disk installed in hard drive 710. These computer program products are means for providing software to computer system 700.

[0092] Computer programs (also referred to as computer control logic) are stored in the main memory 706 and / or the secondary memory 708. The computer programs may also be received via the communication interface 720. Such computer programs, when executed, enable the computer system 700 to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 704 to implement the processes of the present invention, such as any of the methods described herein. Thus, such computer programs represent controllers of the computer system 700. Where the present invention is implemented using software, the software may be stored in a computer program product and loaded into the computer system 700 using the removable storage drive 712, the interface 714, or the communication interface 720.

[0093] In another embodiment, the features of the present invention are implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs) and gate arrays. It will be apparent to those skilled in the relevant art that a hardware state machine is implemented to facilitate the execution of the functions described herein.

[0094] in conclusion

[0095] It should be appreciated that the Detailed Description section, and not the Abstract section, is intended to be used to interpret the claims. The Abstract section may set forth one or more but not all exemplary embodiments, and thus, is not intended to limit the present invention and the appended claims in any way.

[0096] The present invention has been described above with the aid of functional building blocks that illustrate embodiments of specific functions and relationships thereof. For ease of description, the boundaries of these functional building blocks have been arbitrarily defined herein. Alternative boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed.

[0097] It will be apparent to those skilled in the relevant art that various changes in form and details may be made therein without departing from the spirit and scope of the invention. Therefore, the present invention should not be limited by any of the above-described exemplary embodiments, but should only be defined in accordance with the appended claims and their equivalents.

Claims

1. An integrated circuit chip, comprising: a feature library circuit that manages a plurality of functional features that can be implemented by the integrated circuit chip, each of the plurality of functional features being disabled before the configuration file is installed into the flash memory; a central processing unit CPU configured to receive the configuration file from a production server, wherein the configuration file is encrypted; and A trusted execution environment circuit that is preprogrammed with a decryption key and configured to: decrypting the encrypted configuration file using the preprogrammed decryption key; re-encrypting the decrypted configuration file; as well as forwarding the re-encrypted configuration file to the CPU, Wherein the CPU is further configured to install the re-encrypted configuration file to a flash memory to enable one or more of the plurality of functional features based on the installation of a session identifier and the re-encrypted configuration file, wherein the trusted execution environment circuitry is separate from the CPU. 2 . The integrated circuit chip of claim 1 , wherein the configuration file contains a list of functional features to be enabled and identifications associated with owners of the listed functional features.

3. The integrated circuit chip of claim 1 , wherein the trusted execution environment circuit is further configured to: generating a log file including the configuration file, a unique identifier of the integrated circuit chip, and a key associated with the trusted execution environment circuit; encrypting the log file using a session identifier received from the CPU; and forwarding the encrypted log file to the CPU, and Wherein the CPU is further configured to forward the encrypted log file to the production server.

4. The integrated circuit chip of claim 1, wherein the preprogrammed decryption key is pre-associated with a service provider associated with one or more of the plurality of functional features.

5. The integrated circuit chip of claim 4, wherein the trusted execution environment circuit is preprogrammed with a plurality of decryption keys, each of the plurality of decryption keys being pre-associated with a corresponding service provider.

6. The integrated circuit chip of claim 1, wherein the preprogrammed decryption key is associated with a manufacturer of the integrated circuit chip.

7. A method comprising: managing, by a feature library of the device, a plurality of functional features executable by the device, each of the plurality of functional features being in a default disabled state; receiving, by a central processing unit (CPU) of the device, an encrypted configuration file from a server; decrypting the encrypted configuration file using a preprogrammed decryption key through a trusted execution environment preprogrammed with the decryption key; re-encrypting the decrypted configuration file through the trusted execution environment; forwarding the re-encrypted configuration file to the CPU via the trusted execution environment; and One or more of the plurality of functional features are enabled by the CPU based on installation of a session identifier and the re-encrypted configuration file to a flash memory, wherein the trusted execution environment is logically or physically separated from the CPU.

8. The method of claim 7, wherein the configuration file contains a list of features to be enabled and an identification associated with an owner of the listed features.

9. The method according to claim 7, further comprising: generating, by the trusted execution environment, a log file including the decrypted configuration file, a unique identifier of the device, and a key associated with the trusted execution environment; as well as The log file is encrypted by the trusted execution environment using the session identifier, the session identifier having been received from the CPU.

10. The method according to claim 9, further comprising: forwarding the encrypted log file to the CPU through the trusted execution environment; and The encrypted log file is forwarded to the server by the CPU.

11. The method of claim 7, wherein the preprogrammed decryption key is pre-associated with a service provider corresponding to one or more of the plurality of functional features.

12. The method of claim 11, wherein the trusted execution environment is preprogrammed with a plurality of decryption keys, each of the plurality of decryption keys being pre-associated with a corresponding service provider.

13. The method of claim 7, wherein the preprogrammed decryption key is associated with a manufacturer of the device.

14. A non-transitory machine-readable medium comprising instructions that, when executed by circuitry of a device, cause the circuitry to perform operations comprising: managing, by feature library circuitry, a plurality of functional features executable by the device, each of the plurality of functional features being in a default disabled state; receiving a configuration file from a server via a central processing unit (CPU), wherein the configuration file is encrypted; decrypting the encrypted configuration file by a trusted execution environment circuit preprogrammed with a decryption key associated with a service provider different from a manufacturer of the circuit using the preprogrammed decryption key; re-encrypting the decrypted configuration file by the trusted execution environment circuit; forwarding the re-encrypted configuration file to the CPU via the trusted execution environment circuit; and One or more of the plurality of functional features are enabled by the CPU based on installation of a session identifier and the re-encrypted configuration file to a flash memory, wherein the trusted execution environment circuitry is separate from the CPU.

15. The non-transitory machine-readable medium of claim 14, wherein the configuration file includes a list of features to be enabled and identifications associated with owners of the listed features.

16. The non-transitory machine-readable medium of claim 14, wherein the operations further comprise: generating, by the trusted execution environment circuit, a log file including the configuration file, a unique identifier of the device, and a key associated with the trusted execution environment circuit; as well as The log file is encrypted by the trusted execution environment circuitry using a session identifier received from the CPU.

17. The non-transitory machine-readable medium of claim 16, wherein the operations further comprise: forwarding the encrypted log file to the CPU through the trusted execution environment circuit; as well as The encrypted log file is forwarded to the server by the CPU.

18. The non-transitory machine-readable medium of claim 14, wherein the preprogrammed decryption key is associated with a service provider associated with one or more of the plurality of functional features.

19. The non-transitory machine-readable medium of claim 18, wherein the trusted execution environment circuit is preprogrammed with a plurality of decryption keys, each of the plurality of decryption keys being associated with a corresponding service provider.

Images