Patent Application
20240370591
The integrity and trustworthiness of embedded devices in industrial and automotive applications is critical as disruptions in operation may have direct security consequences. Fault attacks are employed to attempt to compromise such devices. A fault attack is some form of intentional manipulation of an embedded device with the goal of causing an error that puts the device in an unintended, vulnerable state that, for example, allows access to security critical information or disables internal protection mechanisms. Types of fault attacks include clock fault injection, voltage fault injection, electromagnetic fault injection, and optical fault injection.
Examples of the present disclosure relate to methods and devices that provide hardware countermeasures in a fault tolerant security architecture. In one aspect, a system includes a processor; a set of devices including a first device that includes a set of registers; and a set of firewalls, each configured to couple the processor to a respective device of the set of devices. The set of registers is configured to store a first value determined by a plurality of bits; and the first device is configured to determine whether to cause a first firewall of the set of firewalls to operate in a bypass mode based on a relationship between values of adjacent bits of the first value.
In another aspect, a system includes a processor; a first firewall and a second firewall; a memory coupled to the first firewall; and a security manager coupled to the second firewall. The security manager includes a set of registers configured to store a first set of bits defining a first value and a second set of bits defining a second value. The security manager is configured to cause the first firewall to operate in a bypass mode based on the first value; and the security manager is further configured to perform at least one of the following: permit execution of a function based on the second value, and prohibit modification of any of the first set of bits based on the second value.
In still another aspect, a method of operating a device includes receiving a power on reset (POR) signal; latching the POR signal, using a latch circuit, outputting a latched POR signal to components of the device, and clearing the latch circuit in response to receipt of a signal indicating that POR is complete with respect to the components; reading, from a memory, a first set of bits indicating a device type and reading a second set of bits for validating the first set of bits; validating the device type using the second set of bits; reading a plurality of security values, each having multiple bits, from the memory; and storing the plurality of security values in a plurality of registers of the device, including storing a first security value of the plurality of security values in a first register of the plurality of registers, in which the first security value determines whether to set a firewall of the device to a bypass mode.
Specific examples of the disclosure will now be described in detail with reference to the accompanying figures. Like elements in the various figures are denoted by like reference numerals for consistency.
The SoC 100 further includes an eFuse controller 126 which includes an eFuse ROM 128, e.g., configuration storage. The eFuse ROM 128 is a bank of fuses arranged in an array of rows and columns that may be used to store security keys and various boot configuration values, including configuration values such as the device type and security flag values for the fault tolerant security architecture. The eFuse controller 126 is configured to scan the array during a power-on reset (POR) of the SoC 100 to determine which eFuses are open and which are closed, convert that information into a binary 0 or 1, and provide the binary information to relevant components of the SoC 100.
System memories and peripheral interfaces in the SoC 100 are protected by hardware firewall modules. Further, initiator side control (ISC) modules are coupled to transaction initiation components in the SoC 100 to apply security attributes to initiated transactions. The ISC modules ensure that transactions are assigned source identifiers and access privileges such that a firewall module interfaced to a target component can use this information to permit the target component to carry out selective processing based on the source and access privileges. In some examples, the SoC 100 implements a firewall/ISC architecture as described in U.S. patent application Ser. No. 15/679,307, entitled “Flexible Hybrid Firewall Architecture, filed Aug. 17, 2017, which is incorporated by reference herein.
The SoC 100 further includes a device management security controller (DMSC) 106 configured to manage system services including initial boot, security, safety, and power management.
The bus subsystem 212 includes a firewall architecture for the DMSC 106. Initiator side control (ISC) modules 226, 228, 230 implemented in the bus subsystem 212 control security attributes applied to transactions initiated by the processor 204 via the bus interfaces 206, 208, 210. Further, firewall (FW) modules 232, 234, 236, 238, 240 implemented in the bus subsystem 212 control access to respective protected components of the DMSC 106, i.e., the memories 214, 216, 218, the security manager 220, and other device management components 222.
Other device management components 222 include components for power management, interrupt aggregation, memory fault detection and correction, debug authorization, configuration of the SoC 100 firewall modules, timer management, and an encryption engine. Access to each of the components 222 is controlled by a respective FW of the FWs 240.
The DMSC 106 acts as the security master of the SoC 100, controlling the initial security configuration at boot time and controlling the security critical assets of the SoC 100 during run time. Security configurations of security critical assets such as emulation control, debugging, ISC modules, and firewall modules are performed by the DMSC 106. The security manager 220 incorporates much of the security management functionality of the DMSC 106 including SoC 100 security management, device type control, emulation control, debug control, and key management.
The security manager 220 is one of the initial blocks enabled at a power on reset (POR) of the SoC 100 in order to configure the security settings of the SoC 100 prior to bringing the rest of the SoC 100 out of reset. As an initial action, the security manager 220 decodes a device type of the SoC 100, e.g., test, emulator, high security, or general purpose, received from the eFuse ROM 128. Each device type indicates different capabilities for test, debug, and emulation as well as different behavior in operating mode, thus indicating whether security mechanisms should be relaxed or enforced. The security manager 220 determines the security level based on the device type and changes values in security control registers 221 accordingly.
A hardware countermeasure is employed to protect the device type information supplied to the security manager 220 because the device type is read from the eFuse ROM 128 in a different voltage domain from that of the security manager 220. A voltage crossing between domains operating at different voltages can cause signal corruption. In general, the hardware countermeasure involves including a set of validation bits when signaling a set of security critical bits. In some examples, the value of the set of validation bits is the inverse of the value of the security critical bits. The recipient of the security critical bits and the validation bits can use the validation bits to confirm that the security critical bits are valid before relying on the security critical bits.
In one example embodiment, the device type is signaled as a 16-bit value of two sets of eight bits that are bit-wise-inverse of each other. That is, eight security critical bits in the 16-bit value include the actual device type and the other eight bits are validation bits that are the inverse of the eight security critical bits. The security manager 220 verifies that no corruption has occurred during transfer as part of determining the device type as illustrated in the example pseudo code of Table 1. In this pseudo code, device_type_raw is the 16-bit value received from the eFuse ROM 128.
The security manager 220 outputs various security control signals to security critical hardware assets based on the values of security flags initially configured by values read from the eFuse ROM 128. The security flags are stored in security control registers 221 protected by the firewall module 228 corresponding to the security manager 220. In some examples, the security control registers 221 are memory mapped registers. Further, some of the registers 221 storing configured security flags can be locked until the next power cycle of the SoC 100 by setting security flags referred to as lock flags in the registers. Note that the combination of firewall protection and register locking provides two levels of protection for security critical assets.
To help protect security critical hardware assets, e.g., a debug port or a firewall module, from fault attacks that rely on flipping a single bit, security flags for such hardware assets are specified, stored, and output as multi-bit values rather than single bit values. Any suitable number of bits and any suitable values for the multiple bits that provide protection against fault attacks may be used. In some examples, four-bit values are used, where bit values that are equal Hamming distance away from each other, e.g., 1010, indicate access is enabled and any other value indicates that access is not enabled. Further, lock values are similarly multi-bit values.
Tables 2-6 are examples of register layouts in the security manager 220 utilizing these multi-bit values. Table 2 is a register controlling firewall bypass that includes a 4-bit lock flag and 4-bit flags controlling bypassing the DMSC 106 firewall modules and bypassing the SoC 100 firewall modules. Table 3 is a register providing master control of tracing, emulation, and debugging of the SoC 100 that includes 4-bit flags for enabling or disabling each. Tables 4-6 are registers controlling access to a key encryption key (KEK), also referred to as the random key, a master public key (MPK), and a master encryption key (MEK), respectively. Each register includes a 4-bit lock flag and 4-bit flags controlling access to the respective key.
The security manager 220 also provides for optional security flags that can be accessed by software executed from the ROM 214. Similar to the security flags for security critical hardware assets, the optional security flags are specified, stored, and output as multi-bit values rather than single bit values too help protect these flags from fault attacks that rely on flipping a single bit. Any number of optional security flags can be provided. Any suitable number of bits and any suitable values for the multiple bits may be used. In some examples, four-bit values are used, where bit values that are equal Hamming distance away from each other, e.g., 1010, indicate the ROM-defined option associated with the flag is enabled and any other value indicates that the option is not enabled.
Table 8 is an example of a register in the security manager 220 that allows for enabling or disabling eight optional security flags. The values of these flags and usage of these flags can determined by the system designer and the values stored in the eFuse ROM 128. The initial values of these register fields are set by the security manager 220 during eFuse scanning at POR.
The reset circuitry 300 is designed to remove this sensitivity to premature de-assertion of the reset signal from the POR process. Rather than relying on propagation of the external reset signal to internal modules, the external reset signal is latched by the latching circuitry 302 and the resulting latched reset signal is propagated to the internal modules. The latching circuitry 302 can be, for example, a latch or a set/reset (SR) flip-flop. The latching circuitry 302 clears the latch only when a reset complete signal is received indicating that the POR processing is complete. Any de-assertion or re-assertion of the external POR signal is ignored until the POR processing by the SoC modules is completed and the latching circuitry 302 clears the latch.
While the disclosure has been described with respect to a limited number of examples, those having benefit of this disclosure will appreciate that other examples can be devised which do not depart from the scope of the disclosure as described herein.
For example, the multi-bit values of the security control flags and/or the number of bits in a security control flag can differ from among the flags.
It is therefore contemplated that the appended claims will cover any such modifications of the examples as fall within the true scope of the disclosure.
This application is a continuation of U.S. patent application Ser. No. 17/391,132, filed Aug. 2, 2021, which is a continuation of U.S. patent application Ser. No. 16/048,711, filed Jul. 30, 2018 (now U.S. Pat. No. 11,080,432), each which is incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17391132 | Aug 2021 | US |
| Child | 18772617 | US | |
| Parent | 16048711 | Jul 2018 | US |
| Child | 17391132 | US |
