Abstract: The embodiments described herein describe technologies for Module management, including Module creation and Module deployment to a target device in an operation phase of a manufacturing lifecycle of the target device in a cryptographic manager (CM) environment. One implementation includes a Root Authority (RA) device that receives a first command to create a Module and executes a Module Template to generate the Module in response to the first command. The RA device receives a second command to create a deployment authorization message. The Module and the deployment authorization message are deployed to an Appliance device. A set of instructions of the Module, when permitted by the deployment authorization message and executed by the Appliance device, results in a secure construction of a sequence of operations to securely provision a data asset to the target device.

Abstract: Values and a sequence of operations associated with generating a key may be received. A determination may be made as to whether the sequence of operations associated with the key matches an authorized sequence of operations. The key may be outputted when the received sequence of operations matches the authorized sequence of operations and the key may not be outputted when the received sequence of operations does not match the authorized sequence of operations.

Abstract: A request associated with one or more privileges assigned to a first entity may be received. Each of the one or more privileges may correspond to an operation of an integrated circuit. Information corresponding to the first entity and stored in a memory that is associated with the integrated circuit may be identified. Furthermore, the memory may be programmed to modify the information stored in the memory that is associated with the integrated circuit in response to the request associated with the one or more privileges assigned to the first entity.

Abstract: A first instruction to store an entity identification (ID) in a memory of a device may be received. The entity ID may be stored in the memory in response to receiving the first instruction. Furthermore, a second instruction to store a value based on a key in the memory of the device may be received. A determination may be made as to whether the value based on the key that is to be stored in the memory corresponds to the entity ID that is stored in the memory. The value based on the key may be stored in the memory of the device when the value based on the key corresponds to the entity ID.

Abstract: A request associated with one or more privileges assigned to a first entity may be received. Each of the one or more privileges may correspond to an operation of an integrated circuit. Information corresponding to the first entity and stored in a memory that is associated with the integrated circuit may be identified. Furthermore, the memory may be programmed to modify the information stored in the memory that is associated with the integrated circuit in response to the request associated with the one or more privileges assigned to the first entity.

Abstract: The embodiments described herein describe technologies for Module management, including Module creation and Module deployment to a target device in an operation phase of a manufacturing lifecycle of the target device in a cryptographic manager (CM) environment. One implementation includes a Root Authority (RA) device that receives a first command to create a Module and executes a Module Template to generate the Module in response to the first command. The RA device receives a second command to create a deployment authorization message. The Module and the deployment authorization message are deployed to an Appliance device. A set of instructions of the Module, when permitted by the deployment authorization message and executed by the Appliance device, results in a secure construction of a sequence of operations to securely provision a data asset to the target device.

Abstract: A request associated with one or more privileges assigned to a first entity may be received. Each of the one or more privileges may correspond to an operation of an integrated circuit. Information corresponding to the first entity and stored in a memory that is associated with the integrated circuit may be identified. Furthermore, the memory may be programmed to modify the information stored in the memory that is associated with the integrated circuit in response to the request associated with the one or more privileges assigned to the first entity.

Abstract: The embodiments described herein describe technologies for Module management, including Module creation and Module deployment to a target device in an operation phase of a manufacturing lifecycle of the target device in a cryptographic manager (CM) environment. One implementation includes a Root Authority (RA) device that receives a first command to create a Module and executes a Module Template to generate the Module in response to the first command. The RA device receives a second command to create a deployment authorization message. The Module and the deployment authorization message are deployed to an Appliance device. A set of instructions of the Module, when permitted by the deployment authorization message and executed by the Appliance device, results in a secure construction of a sequence of operations to securely provision a data asset to the target device.

Abstract: Pairing data associated with a second device may be received at a first device. The pairing data may be received from a server. A first authentication proof may be generated based on the pairing data received from the server. A second authentication proof may be received from the second device. Furthermore, an authentication status of the second device may be updated based on a comparison of the first authentication proof that is based on the pairing data received from the server and the second authentication proof that is received from the second device.

Abstract: A request associated with one or more privileges assigned to a first entity may be received. Each of the one or more privileges may correspond to an operation of an integrated circuit. Information corresponding to the first entity and stored in a memory that is associated with the integrated circuit may be identified. Furthermore, the memory may be programmed to modify the information stored in the memory that is associated with the integrated circuit in response to the request associated with the one or more privileges assigned to the first entity.

Abstract: A request associated with one or more privileges assigned to a first entity may be received. Each of the one or more privileges may correspond to an operation of an integrated circuit. Information corresponding to the first entity and stored in a memory that is associated with the integrated circuit may be identified. Furthermore, the memory may be programmed to modify the information stored in the memory that is associated with the integrated circuit in response to the request associated with the one or more privileges assigned to the first entity.

Abstract: Values and a sequence of operations associated with generating a key may be received. A determination may be made as to whether the sequence of operations associated with the key matches an authorized sequence of operations. The key may be outputted when the received sequence of operations matches the authorized sequence of operations and the key may not be outputted when the received sequence of operations does not match the authorized sequence of operations.

Abstract: A mechanism for providing secure feature and key management in integrated circuits is described. An example integrated circuit includes a secure memory to store a secret key, and a security manager core, coupled to the secure memory, to receive a digitally signed command, verify a signature associated with the command using the secret key, and configure operation of the integrated circuit using the command.

Abstract: Pairing data associated with a second device may be received at a first device. The pairing data may be received from a server. A first authentication proof may be generated based on the pairing data received from the server. A second authentication proof may be received from the second device. Furthermore, an authentication status of the second device may be updated based on a comparison of the first authentication proof that is based on the pairing data received from the server and the second authentication proof that is received from the second device.

Abstract: The embodiments described herein describe technologies for Module management, including Module creation and Module deployment to a target device in an operation phase of a manufacturing lifecycle of the target device in a cryptographic manager (CM) environment. One implementation includes a Root Authority (RA) device that receives a first command to create a Module and executes a Module Template to generate the Module in response to the first command. The RA device receives a second command to create a deployment authorization message. The Module and the deployment authorization message are deployed to an Appliance device. A set of instructions of the Module, when permitted by the deployment authorization message and executed by the Appliance device, results in a secure construction of a sequence of operations to securely provision a data asset to the target device.

Abstract: A mechanism for providing secure feature and key management in integrated circuits is described. An example method includes receiving, by a root authority system, data identifying a command that affects operation of an integrated circuit, singing, by the root authority system, the command using a root authority key to create a root signed block (RSB), and providing the RSB to a security manager of the integrated circuit.

Abstract: A first instruction to store an entity identification (ID) in a memory of a device may be received. The entity ID may be stored in the memory in response to receiving the first instruction. Furthermore, a second instruction to store a value based on a key in the memory of the device may be received. A determination may be made as to whether the value based on the key that is to be stored in the memory corresponds to the entity ID that is stored in the memory. The value based on the key may be stored in the memory of the device when the value based on the key corresponds to the entity ID.

Abstract: The embodiments described herein describe technologies for Module management, including Module creation and Module deployment to a target device in an operation phase of a manufacturing lifecycle of the target device in a cryptographic manager (CM) environment. One implementation includes a Root Authority (RA) device that receives a first command to create a Module and executes a Module Template to generate the Module in response to the first command. The RA device receives a second command to create a deployment authorization message. The Module and the deployment authorization message are deployed to an Appliance device. A set of instructions of the Module, when permitted by the deployment authorization message and executed by the Appliance device, results in a secure construction of a sequence of operations to securely provision a data asset to the target device.

Abstract: Pairing data associated with a second device may be received at a first device. The pairing data may be received from a server. A first authentication proof may be generated based on the pairing data received from the server. A second authentication proof may be received from the second device. Furthermore, an authentication status of the second device may be updated based on a comparison of the first authentication proof that is based on the pairing data received from the server and the second authentication proof that is received from the second device.

Abstract: Values and a sequence of operations associated with generating a key may be received. A determination may be made as to whether the sequence of operations associated with the key matches an authorized sequence of operations. The key may be outputted when the received sequence of operations matches the authorized sequence of operations and the key may not be outputted when the received sequence of operations does not match the authorized sequence of operations.