An information handling system includes a first memory and a baseboard management controller. The first memory stores a first firmware partition and a second firmware partition. The baseboard management controller includes a second memory. The baseboard management controller begins execution of a DM-Verity daemon, and performs periodic patrol reads of the first firmware partition. The baseboard management controller detects one or more block failures in the first firmware partition, and stores information associated with the one or more block failures in a message box of the second memory. In response to the entire first firmware partition being scanned, the baseboard management controller switches a boot partition from the first firmware partition to the second firmware partition, and initiates a reboot of the information handling system.

An Information Handling System (IHS) includes at least one hardware device in communication with a Baseboard Management Controller (BMC). The hardware device includes executable instructions for establishing a secure communication channel with the BMC, and subsequently receiving a list of allowed commands from the BMC. When a command is received by the hardware device, it determines whether the command is included in the list such that when the command is in the list and the command is received within the secure communication channel, the hardware device performs the command. However, when the command is in the list and the command is received outside of the secure communication channel, the hardware device ignores the command.

A firmware update shared key management method using a flash memory includes: a firmware data registration step of receiving, from a manufacturer server, at least one of information of a user device that is a firmware update target, and firmware information and registering the received information as firmware data; a firmware data management step of receiving a request from a firmware update server in which the registered firmware data is stored, and storing and managing the registered firmware data in a specific area of a flash memory included in the user device via a network; a shared key verification execution step of using a shared key to execute verification on a command communicating between the user device including the flash memory and the firmware update server that performs firmware update; and a firmware update execution step of performing firmware update of the user device through the firmware update server only when the encrypted command and the shared key pass the verification.

The components of a firmware that are to be executed are identified, such as firmware device drivers and SMI interrupt handlers. Performance data is also obtained for the components. An inventory identifying the components and the performance data are provided to a BMC. The BMC provides the inventory and the performance data to a remote management client through an out-of-band (“OOB”) network connection. The BMC might also receive a blacklist instruction from the management client. The blacklist instruction provides an indication to the BMC that one or more of the components of the firmware are not to be executed by the computing system. The BMC provides the blacklist instruction to the firmware. The firmware adds the component, or components, identified in the blacklist instruction to a blacklist. The next time the computing system is booted, the firmware will not execute the components identified in the blacklist.

A structured document is verified for changes that are made during and after deployment of an application. The structured document includes first fields that are designated as mutable, and second fields that are designated as immutable. An attempted change is detected to the structured document during or after deployment of the application. Upon detecting the attempted change, a digital signature is generated of the second fields of the structured document. A determination is made whether the generated digital signature of the second fields matches a reference digital signature of the second fields. Upon determining that the generated digital signature matches the reference digital signature, the change to the structured document is permitted. Upon determining that the generated digital signature does not match the reference digital signature, the change is blocked to the structured document.

A system for a cryptographic agile bootloader for upgradable secure computing environment, the cryptographic agile bootloader comprising a computing device associated with a first bootloader is presented. The computing device includes a secure root of trust, the secure root of trust configured to produce a first secret and a second secret and a processor. The processor is configured to load a second bootloader, wherein the second bootloader is configured to generate a secret-specific public datum as a function of the second secret, wherein the secret-specific public datum further comprises a bootloader measurement, load a first bootloader, wherein the first bootloader is configured to sign the secret-specific public datum as a function of the first secret, and replace the first bootloader with the second bootloader.

A secure programming system and method for provisioning and programming a target payload into a programmable device mounted in a programmer. The programmable device can be authenticated before programming to verify the device is a valid device produced by a silicon vendor. The authentication process can include a challenge-response validation. The target payload can be programmed into the programmable device and linked with an authorized manufacturer. The programmable device can be verified after programming the target payload by verifying the silicon vendor and the authorized manufacturer. The secure programming system can provision different content into different programmable devices simultaneously to create multiple final device types in a single pass.

A communication system and a comparison method for securing a communication path for a legitimate user via a terminal apparatus (“TA”). A vehicle-mounted communication device (“VMCD”) transmits a device ID identifying the VMCD to a TA, acquires a terminal ID from the TA, and transmits the device ID and the terminal ID acquired from the TA to a central apparatus. The TA transmits a terminal ID identifying the TA to the VMCD, acquires a device ID from the VMCD, and transmits the terminal ID and the device ID acquired from the VMCD to the central apparatus. The central apparatus receives a device ID and a terminal ID transmitted from the VMCD and a device ID and a terminal ID transmitted from the TA, and compares the device ID and the terminal ID received from the VMCD with the device ID and the terminal ID received from the TA.

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.

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.