A device includes a reset resistant store and a trusted key service. The reset resistant store maintains data across various different device reset or data invalidation operations. The trusted key service maintains, for each of one or more operating systems that run on the device from a boot configuration, an encrypted key associated with the boot configuration. The device also has a master key that is specific to the device. Each of the keys associated with a boot configuration is encrypted using the master key. When booting the device, the boot configuration being run on the device is identified, and the key associated with that boot configuration is obtained (e.g., from the reset resistant store or the encrypted key vault). The master key is used to decrypt the obtained key, and the obtained key is used to decrypt secrets associated with the operating system run from the boot configuration.

Variables utilized in device firmware that provides various boot and runtime services are repaved in a fault-tolerant manner within a secure store in a durable, non-volatile device memory during an FOTA update process. A spare region in the secure store is utilized to temporarily hold a back-up of a primary region in which the firmware variables are written. Using a transaction-based fault-tolerant write (FTW) process, the variables in the primary region can be repaved with variables contained in a firmware update payload that is delivered from a remote service. In the event of a fault in the variable region repaving process, either the primary or spare region will remain valid so that firmware in a known good state can be utilized to enable the device to boot successfully and the variable region repaving in the FOTA update process may be restarted.

According to some embodiments, an overall chain-of-trust may be established for an industrial control system. Secure hardware may be provided, including a hardware security module coupled to or integrated with a processor of the industrial control system to provide a hardware root-of-trust. Similarly, secure firmware associated with a secure boot mechanism such that the processor executes a trusted operating system, wherein the secure boot mechanism includes one or more of a measured boot, a trusted boot, and a protected boot. Objects may be accessed via secure data storage, and data may be exchanged via secure communications in accordance with information stored in the hardware security model.

A multi-phase boot operation of a virtualization manager at a virtualization host is initiated at an offload card. In a first phase of the boot, a security key stored in a tamper-resistant location of the offload card is used. In a second phase, firmware programs are measured using a security module, and a first version of a virtualization coordinator is instantiated at the offload card. The first version of the virtualization coordinator obtains a different version of the virtualization coordinator and launches the different version at the offload card. Other components of the virtualization manager (such as various hypervisor components that do not run at the offload card) are launched by the different version of the virtualization controller.

An opportunistic hypervisor determines that a guest virtual machine of a virtualization host has voluntarily released control of a physical processor. The hypervisor uses the released processor to identify and initiate a virtualization management task which has not been completed. In response to determining that at least a portion of the task has been performed, the hypervisor enters a quiescent state, releasing the physical processor to enable resumption of the guest virtual machine.

A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

A modified measured boot approach is utilized for establishing a secure communication link between two devices. Each device may execute a respective boot process until the device reaches the stage responsible for establishing the communication link with the other device. Each device may exchange its respective self-signed certificate and extend its certificate chain with the self-signed certificate received from the other device. Each device can then generate a new pair of keys based on its extended certificate chain that includes the identity of the other device, and exchange the public key of the new key pair with the other device. A secure link can be established using the public key of the other device as a based key for a key exchange protocol. A central management entity can attest the measurements of the boot stages for each device using the corresponding public key.

Example implementations relate to custom operating system (OS) images. For example, booting a user device to a custom OS image includes presenting a user interface (UI) for creating a custom OS image for portable use, storing the custom OS image on a database for information technology (IT) management purposes, sending, based on a request, the custom OS image from the database to an secure external device, and authenticating, based on a policy, the custom OS image on the secure external device for use on a user device without an OS image or a hard drive disk (HDD).

A system and method of processing instructions may comprise an application processing domain (APD) and a metadata processing domain (MTD). The APD may comprise an application processor executing instructions and providing related information to the MTD. The MTD may comprise a tag processing unit (TPU) having a cache of policy-based rules enforced by the MTD. The TPU may determine, based on policies being enforced and metadata tags and operands associated with the instructions, that the instructions are allowed to execute (i.e., are valid). The TPU may write, if the instructions are valid, the metadata tags to a queue. The queue may (i) receive operation output information from the application processing domain, (ii) receive, from the TPU, the metadata tags, (iii) output, responsive to receiving the metadata tags, resulting information indicative of the operation output information and the metadata tags; and (iv) permit the resulting information to be written to memory.

According to an example embodiment, a firmware rewriting apparatus includes: call position specifying means for specifying, among instructions described in a program of firmware stored in a memory, the instructions for changing a control flow; free area specifying means for specifying a free area in a storage area of the memory in which the program is not stored; and program rewriting means for rewriting the instruction specified by the call position specifying means into a call instruction of a frequency adjustment code and writing the frequency adjustment code for calling an inspection code at a frequency corresponding to a frequency of calling the frequency adjustment code and the inspection code for performing a security check of the program in response to a call from the frequency adjustment code into the free area specified by the free area specifying means.