TWI756156B - Monitor system booting security device and method thereof - Google Patents

Abstract

A security device includes an interface and a processor. The interface is configured for connecting to a bus that serves a host device and a non-volatile memory (NVM) device. The processor is connected to the bus in addition to the host device and the NVM device. The processor is configured to detect on the bus a boot process, in which the host device retrieves boot code from the NVM device, and to ascertain a security of the boot process, based on an authentic copy of at least part of the boot code of the host device.

Description

Safety device and method for monitoring system startup

The present invention relates to an electronic system security, and more particularly, to a method and system for secure bootstrapping.

Electronic device systems use various types of bus interfaces for communication between host devices and peripheral devices. An example of a bus interface is a serial peripheral interface bus (SPI bus). Peripherals that can support the SPI bus include, for example, serial flash memory devices.

An embodiment of the present invention provides a security device including an interface and a processor. This interface is used to connect a bus serving a host device and a non-volatile memory (NVM) device. A processor is connected to the bus, the host device and the NVM device are also connected to the bus, the processor is used to detect a boot process on the bus, in the boot process the host device from the NVM The device obtains a boot code, and determines the security of the boot procedure based on a copy of at least a portion of the boot code of the host device.

In some embodiments, the processor is used to retrieve at least a portion of the boot code from the bus, and when detecting a relationship between the at least a portion of the boot code obtained from the NVM device and the copy In the event of non-compliance, a response action is initiated.

In one embodiment, the copy includes an image of the at least a portion of the boot code, and the processor compares the image with at least a portion of the boot code obtained from the NVM device to detect the non-compliance . In another embodiment, the copy includes an authentic digest of the at least a portion of the boot code, and the processor calculates a digest of the at least a portion of the boot code obtained from the NVM device, and compares The digest of the at least a portion of the boot code obtained from the NVM device and the real digest to detect the non-compliance.

In some embodiments, the processor detects the non-compliance while the boot process is in progress. In an exemplary embodiment, in response to detecting the non-compliance, the processor is configured to impose one or more dummy values on at least one line of the bus to disrupt the boot process. In one embodiment, in response to detecting the non-compliance, the processor disrupts the one or more lines of the bus between the host device and the NVM device to disrupt the boot process. In another embodiment, in response to detecting the non-compliance, the processor responds to the host device on the bus instead of the NVM device to use the copy to complete the boot process. In other embodiments, the processor detects the non-compliance independently of the boot process.

In one embodiment, the processor maintains the copy in an internal memory of the security device or in a memory external to the security device. In another embodiment, the processor prevents the host device from accessing a given confidential information until the security of the boot procedure is determined.

In one embodiment, the processor performs the following operations to ensure the security of the boot process: responding to the host device in place of the NVM device and providing a boot code to the host device, wherein the boot code causes the host device to Activity on the bus is the first instance of the start-up procedure. differing between an instance and a second entity; and monitoring the activity of the host device on the bus and confirming that the activity complies with the activation code provided to the host device.

In yet another embodiment, when a chip select (CS) line of the bus is not asserted, the processor does not change by ensuring that the logic states of all data and clock lines of the bus do not change , to determine the security of the boot procedure. In another embodiment, the processor secures the boot process by ensuring that only bus commands that appear on a predefined whitelist are applied to the NVM device.

In an exemplary embodiment, the processor determines the boot process by ensuring that a time delay in the boot process from a given reset signal or boot signal to a given event is within a predefined range Safety. In addition, the processor ensures the safety of the boot process by ensuring that the value of an analog parameter of at least one line of the bus falls within a predefined range. In one embodiment, the startup code instructs the host device to output one or more host parameter values on the bus, and the processor monitors and validates the host parameter values output on the bus to Make sure the boot procedure is safe.

An embodiment of the present invention provides a security method comprising the steps of: using a security device to communicate through a bus, wherein a host device and a non-volatile memory (NVM) are connected to the bus; and using the The security device detects a boot process on the bus in which the host device obtains a boot code from the NVM device and determines the boot based on a copy of at least a portion of the boot code for the host device program security.

In another embodiment, the present invention provides a security device including an interface and a processor. The interface is used to connect a bus that serves one or more peripheral devices. The bus includes one or more dedicated signals, which are respectively used for a peripheral device; and one or more shared signals, which are shared with the peripheral devices through the bus. The processor is connected to the bus as an additional device. Peripherals connected to the busbar. The processor may disrupt the operation of the bus master on the bus attempting to access a given peripheral by disrupting dedicated signals associated with the given peripheral.

In some embodiments, the processor maintains the shared signal on the bus bar uninterrupted while the scrambling operation is performed. In one embodiment, the interface includes an input for receiving dedicated signals from the bus master, and an output for transmitting dedicated signals to a given peripheral device that the processor can transmit by preventing the input from receiving dedicated signals. to the output to disrupt the above operation. In some embodiments, the processor responds to the bus master in place of the intended peripheral device, thereby disrupting the dedicated signal. In an exemplary embodiment, the dedicated signal includes a chip select (CS) signal.

In one embodiment, the processor detects operations to be disturbed by monitoring the bus. In yet another embodiment, the processor communicates with the bus master over an auxiliary interface to detect operations to be disturbed. The auxiliary interface is located outside the busbar.

In one embodiment, the processor indeterminately scrambles the dedicated signal until the system is reset. In another embodiment, the processor scrambles the dedicated signal for a limited period of time after detecting the above operation. In one embodiment, by scrambling the operation, the processor causes the operation to be discarded at one or more peripheral devices. In some embodiments, after disturbing operation, the processor reverts to normal operation of the bus.

According to an embodiment of the present invention, a security device is further provided, which includes an interface and a processor. The interface connects to a bus that serves one or more peripheral devices. The processor and peripheral are connected to the bus, and the processor responds to the bus master by substituting the intended peripheral to disrupt the bus master's attempt to access a given peripheral on the bus.

In one embodiment, the bus includes one or more dedicated signals, which are respectively dedicated to peripheral devices; and one or more shared signals, which are shared among the peripheral devices served by the bus, and the processor is configured by disturbing the predetermined The dedicated signal related to the peripheral device responds to the bus master device when the dedicated signal is disturbed, so as to disturb the operation of the bus master device.

In some embodiments, the peripheral device includes a memory device, and the processor recognizes a request from the bus master to read data from the memory device during the operation, and responds to the request with another data stored within the secure device. In an exemplary embodiment, the processor disrupts this operation by responding to the bus master's request for the memory device to access a predefined address region with another data.

In another embodiment, the processor identifies the operation of the bus master attempting to access the intended peripheral based on data returned by the intended peripheral to the bus master during operation. In yet another embodiment, based on the instruction code used in the operation, the processor identifies the operation of the bus master attempting to access a given peripheral device.

According to an embodiment of the present invention, a security method is further provided, which includes the following steps: using a security device to communicate through a bus bar, wherein a host device and one or more peripheral devices are connected to the bus bar; wherein the bus bar It includes one or more dedicated signals, which are respectively dedicated to peripheral devices; and one or more shared signals, which are shared among the peripheral devices served by the bus. A security device is used to disrupt the operation of the bus master on the bus attempting to access a given peripheral by disrupting the dedicated signals associated with the given peripheral.

According to an embodiment of the present invention, a security method is further provided, which includes the following steps: using a security device to communicate through a bus, wherein a host device and one or more peripheral devices are connected to the bus; using the security device By responding to the bus master in place of the intended peripheral, the operation of the bus master attempting to access a given peripheral on the bus is disrupted.

According to another embodiment of the present invention, a security device is provided, which includes an interface and a processor. The interface communicates through a bus. The processor disrupts an unauthorized attempt by the bus master to access a peripheral on the bus by imposing one or more dummy values on at least one line on the bus parallel to at least a portion of the operation.

In one embodiment, the processor imposes a dummy value on a data line of the bus, thereby disrupting the transmission of data values sent or received on the data line from peripheral devices. In addition, the processor can Imposing a dummy value on the clock line of the bus, thereby disturbing the clock signal used for this operation. Additionally, the processor may impose dummy values on the bus's chip select line, thereby disrupting the selection of peripherals by the bus master.

In some embodiments, the bus includes an open-drain or open-collector bus with a predetermined logic value, and the processor can write the opposite of the predetermined logic value through at least one line of the bus. , to impose a dummy value.

In some embodiments, by imposing a dummy value, the processor can override the corresponding corresponding value that the bus master or peripheral has written on at least one line. In an exemplary embodiment, the processor can overwrite the value written by the bus master device or the peripheral device by driving at least one line of the bus master device or the peripheral device with a strong drive strength. In other embodiments, the device includes at least one resistor, inserted on at least one line, for attenuating the value written by the bus master or the peripheral device to be weaker than the virtual value written by the processor value.

In some embodiments, the processor only uses the existing wiring of the bus that communicates between the bus master and peripheral devices to impose dummy values. In some embodiments, the processor monitors the bus to detect operations to be disturbed. In one embodiment, the processor detects the operation to be disturbed by communicating with the bus master over the auxiliary interface. The auxiliary interface is located outside the busbar.

In one embodiment, the processor imposes the dummy value indefinitely until the device is reset. In another embodiment, after detecting this operation, the processor imposes a dummy value for a limited period of time. In one embodiment, after disturbing the operation, the processor can resume normal operation of the bus.

According to an embodiment of the present invention, a safety system is further provided, which includes a peripheral device and a safety device. One or more bus master devices can access peripheral devices through a bus. The security device may disrupt operation of the bus master from unauthorized attempts to access peripheral devices on the bus by imposing one or more dummy values on at least one line parallel to at least a portion of the operation.

According to an embodiment of the present invention, a security method is further provided, which includes the steps of: using a security device coupled to a bus to determine to disrupt the operation of the bus master device from unauthorized attempts to access a peripheral device. This operation is disrupted by imposing one or more dummy values on at least one line of the bus in parallel to at least a portion of the operation.

110, 189, 130, 140, 170, 70, 20: Security Systems

144, 74, 24: host device

148: Flash memory

152, 82: SPI bus bar

178, 160, 90, 40: Interface

182, 164, 94, 44: Processor

186, 168: Copy

187, 174, 156, 86, 36: Safety devices

188: SPI bus monitor

28, 78: Peripherals

32: I ² C bus

48, 98: memory

91: Slave interface logic circuit

92: Interface monitoring logic circuit

S100, 104, 108, 112, 116, 120, 190, 194, 198, 202, 206, 210, 214, 62, 66, 50, 54, 58: Steps

FIG. 1 is a block diagram of a security system according to an embodiment of the present invention, wherein a plurality of devices in the security system communicate through an I ² C bus.

FIG. 2 is a flow chart illustrating a method for securely accessing a peripheral device on an I ² C bus according to an embodiment of the present invention.

3-5 are block diagrams illustrating a security system in which multiple devices communicate through an SPI bus in the security system according to other embodiments of the present invention.

FIG. 6 is a block diagram illustrating a safety device according to an embodiment of the present invention.

FIG. 7 is a flowchart of a method of securely booting a host device according to an embodiment of the present invention.

FIGS. 8-10 are block diagrams illustrating a security system in which a security device on an SPI bus enables a host device to obtain a secure boot procedure from a flash memory according to an embodiment of the present invention.

FIG. 11 is a flowchart illustrating a method for safely booting a host device according to an embodiment of the present invention.

The embodiments of the present invention will be described in detail below in conjunction with the drawings and examples, so as to fully understand and implement the implementation process of how the present invention applies technical means to solve technical problems and achieve technical effects.

Overview

Embodiments of the present invention describe a method and apparatus for securing access to peripheral devices on a bus interface. Peripheral devices may include, for example, encryption engines, memory devices that store sensitive data, or any other similar device that may be accessed through a bus.

In some embodiments, the security device monitors transactions on the bus and identifies unauthorized access by the host device or other bus master to peripheral devices. Such operations may be classified into authorized operations and unauthorized operations according to any suitable criterion or policy.

When an unauthorized operation is identified, the security device can disrupt the unauthorized operation by deliberately imposing some dummy value on one or more lines or signals of the bus while running parallel to the operation . The dummy value described above can be imposed, for example, on a clock signal, a data signal and/or a chip select (CS) signal.

The way to perturb the operation by imposing a dummy value on the bus is suitable, for example, an open-drain bus or an open ^- collector bus, such as an I2C bus, And push-pull busbars, such as SPI busbars. Imposing a dummy value on the bus parallel to the unauthorized operation can overwhelm the communication with the peripheral and disturb the clock signal.

Several example techniques for scrambling unauthorized operation on the I ² C and SPI buses will be described below, as well as techniques for restoring normal operation after scrambling. In some embodiments, the security device may disrupt without first detecting this unauthorized operation on the bus, or even monitoring the bus. For example, a security device may impose dummy values on a host's chip select (CS) line until or unless the host is authorized.

In some embodiments, such as in an SPI bus, the bus protected by the security device includes: (i) one or more dedicated signals, each dedicated to a peripheral device; and (ii) one or more shared The signal is shared among multiple peripheral devices through the bus. Examples of shared signals are data signals and clock signals. An example of a dedicated signal is the CS signal. In some embodiments, the security device disrupts this unauthorized operation by disrupting dedicated signals associated with protected peripheral devices while maintaining shared signals on the bus. However, it should be noted that not all bus bars have dedicated signals. For example, on an I ² C bus, all signals are shared.

In other embodiments, the security device disrupts this operation by responding to the unauthorized host in place of a protected peripheral device. In an exemplary embodiment, the peripheral device includes a flash memory that includes one or more address areas for storing sensitive data, such as keys, configuration data, and/or boot codes. By selectively overriding the CS signal of the flash memory, the security device can override the operation of accessing data in the flash memory. The security device responds to the host with its internally stored data. This secure boot procedure will be described below.

The techniques disclosed herein provide instant secure selective access to peripheral devices on a transaction-by-transaction level. In the embodiment of the present invention, only the existing signals of the bus are used for operation identification and operation disturbance. Therefore, the techniques disclosed in the present invention do not require additional pins or interconnects, thereby reducing overall system size and cost.

In other embodiments, the security device secures the boot process of the host device in which the host device obtains a boot code from a non-volatile memory (NVM) device through a bus. For example, the host can boot from an SPI flash memory device on an SPI bus. In some embodiments, the security device monitors the bus during the boot process and compares the host at least a portion of the boot code and a known copy, such as a boot code image or digest. A response action is triggered when a discrepancy between the activation code obtained on the bus and a known copy of the security device is detected. This technique of the present invention enables the security device protection system to resist various security threats, such as a stolen host or flash memory device, or attacks on bus signals. Several exemplary embodiments and variations of secure boot procedures will be described below.

Secure access to peripherals on the I ² C bus

FIG. 1 is a block diagram of a security system 20 according to one embodiment of the present invention. In this example, the security system 20 includes a host device 24 and a peripheral device 28 connected to an I ² C bus 32 . To simplify the description, host device 24 and peripheral device 28 may be referred to as host and peripheral, respectively. The host device 24 is also sometimes referred to as a bus master.

The security device 36 protects access to peripheral devices 28 by monitoring operation ^on the I2C bus and prevents unauthorized access attempts by the host 24 or another bus master capable device Unauthorized operation of perimeter 28. Security device 36 is also sometimes referred to as a control device or trusted platform module (TPM). In this example, the security device 36 includes an interface 40 , a processor 44 and a memory 48 . Interface 40 is used to connect to I ² C bus 32 , processor 44 implements the techniques disclosed herein, and memory 48 stores one or more security policies implemented by processor 44 .

Processor 44 may classify a transaction according to any predefined or set policy. Generally, unauthorized operations attempt to write data to the peripheral device, read data from the peripheral device, set or transmit commands to the peripheral device, or access the peripheral device in any other way. Policies enforced by a secure device may include positive policies, such as whitelists; negative policies, such as blacklists; policies that depend on device addresses or register offsets; or any other type of strategy.

For example, the host may be required to have the security device authenticate the identity before the host is authorized to access the peripheral device. An operation attempted by an unauthorized host is considered unauthorized. E.g, Some challenge-response process may be used between the host and the security device to perform authentication. Additionally, the host may be required to authenticate in other suitable ways, or to successfully complete a secure boot procedure.

Furthermore, some types of operations (eg, read operations) may be considered authorized, while other types of operations (eg, write operations) may be considered unauthorized. In another example, the operation of accessing the default address of the peripheral device may be regarded as authorized, and the operation of accessing other addresses may be regarded as unauthorized. In another example, some sequence of bits on the bus may represent an unauthorized operation.

In general, processor 44 may distinguish between authorized and unauthorized operations in any suitable manner. At least one policy for distinguishing authorized operations from unauthorized operations may be stored in memory 48 .

The I ² C bus 32 includes a serial data (SDA) line for carrying a serial data signal; and a serial clock (SCL) line for carrying a serial clock signal. The terms "line or line" and "signal" are used interchangeably herein. By monitoring the SDA line as well as the SCL line, the processor 44 can monitor any operations interacting ^on the I2C bus and identify unauthorized operations.

When an unauthorized operation is identified, processor 44 disrupts the unauthorized operation by imposing one or more dummy values on the DSA and/or SCL lines of I ² C bus 32 . This mechanism is possible due to the open drain/open collector structure of the I ² C bus. Usually, the SDA line and the SCL line are pre-set to a logic "1" state (ie, a high voltage level) using pull-up resistors. Any device can write a "0" value on the SDA line or the SCL line at any time to impose a logic "0" (ie, a low voltage level), regardless of what other devices are writing at the same time.

Thus, in some embodiments, when an unauthorized operation is identified, the processor 44 of the security device 36 may use the interface 40 to impose a logic "0" on the SDA line or the SCL line of the bus 32 (the default "0" 1" is the opposite of the logical value). Here, the "0" value is regarded as a dummy value. A "0" value is imposed on the SDA line to override any data values written from the host device 24 to the peripheral device 28, or the host device 24 from the peripheral device 24. Any data value read by the side device 28, or a default "1" value. A "0" value imposed on the SCL line stops the clock signal. In either case, operation can be disrupted.

In some embodiments, processor 44 continues to impose a "0" value indefinitely, eg, until a power-on reset is performed. In other embodiments, processor 44 may cause host reset 24 and peripheral reset 28 to restore normal operation from a state of disturbed operation. Some host resets and/or peripherals fail to resume normal operation from a clock hiatus. Therefore, if the host resets and the peripheral needs to return to normal operation, it is preferable to impose a dummy value on the SDA rather than the SCL line.

In one embodiment, the processor 44 generates an I2C stop or restart condition ^on the bus in order to revert to normal operation after a disturbed operation. Herein, an ^I2C stop or restart condition may include any sequence of bus signal values that inform the device that the bus is free to begin operation.

The processor 44 may use a variety of techniques to recover from scrambled operation to normal operation. In one embodiment, processor 44 only imposes a "0" value for a predefined length of time, which is sufficient to disrupt this unauthorized operation. Any predefined length of time can be used. For example, the SMBus specification has a defined pause time of 25mS. Therefore, in the application of SMBus (SMBus-over-I ² C) running on I ² C, the pre-defined time length can be set to 25mS to trigger the pause.

In another embodiment, processor 44 may impose a "0" value on the SDA line until it is detected that the SCL line has been high (eg, not perturbed) for at least a predefined period of time. This condition can indicate that the host has ended or abandoned the operation. Next, the processor 44 can release the SDA line and possibly generate an ^I2C stop condition.

In yet another embodiment, secure device 36 may act as an I ² C slave device with the same device address as peripheral 28 in order to effectively disrupt unauthorized operations to read data from peripheral devices. The processor 44 of the security device 36 may respond to the unauthorized read request with a "0" data value. While the processor 44 is operating, the peripheral device 28 will also respond to the read request, but the data value sent by the peripheral device 28 will be overwritten by the “0” value sent by the security device 36 . This routine continues until the host terminates the operation due to a stop condition. It should be noted that according to the I2C specification, the ^I2C slave does not drive the ACK/ ^NEGACK bit when transmitting data.

In another embodiment, processor 44 may impose a "0" value on the SDA line in order to effectively scramble read operations as well as write operations. Then, if the host device 24 does not recognize the jammer, the operation ends normally with a "0" data on the bus, thereby replacing the data sent from the peripheral 28 . If host device 24 detects a jammer (eg, because it supports an I ² C multi-master arbitration mechanism) and discards the operation, processor 44 may generate additional clock cycles on the SCL line to take over the discarded operation by host 24 . Next, processor 44 may complete the byte currently being transmitted and issue a stop condition to end the operation.

The above-described scrambling and recovery techniques are illustrative only. In other embodiments, the processor 44 of the security device 36 may use any other suitable technique to disrupt operation, and to recover from disruption to normal operation.

In the above example, detecting unauthorized operations, disrupting unauthorized operations, and restoring normal operation after disruption is accomplished using only the existing wiring of the bus. In other embodiments, the security device 36 and the host 24 can also be connected to each other through some auxiliary interfaces outside the bus bar 32 . This mechanism is applicable, for example, when the security device 36 and the host 24 are integrated in the same integrated circuit (IC) and share the SDA and SCL pins of the IC.

In such embodiments, security device 36 and host device 24 may use a secondary interface to ensure that no other host device is accessing peripheral device 28 . In an exemplary embodiment, whenever the host device 24 accesses the peripheral device 28, the host device 24 notifies the security device 36 through the auxiliary interface. In response to this notification, the processor 44 does not impose a false "0" value on the bus, and allows the operation to proceed. When an operation is detected accessing the peripheral 28 without notification on the auxiliary interface, the processor 44 assumes that the operation was performed by an unauthorized host and imposes a value of "0" to disrupt the unauthorized access. Authorize operations.

FIG. 2 is a flowchart illustrating a method for securely accessing peripheral devices on the I ² C bus 32 according to an embodiment of the present invention. Initially, in a monitoring step 50 , the processor 44 of the security device 36 uses the interface 40 to monitor operations on the I ² C bus 32 .

In an operation detection step 54 , the processor 44 identifies the operation of the host device 24 attempting to access the peripheral device 28 . In a check step 58, the processor 44 checks whether the operation is authorized. For example, processor 44 may check whether this operation violates a security policy stored in memory 48 .

At a consent step 62, if the operation is found to be authorized, the processor 44 allows the operation to proceed normally. Otherwise, in a perturbation step 66, if the operation is found to be unauthorized, processor 44 imposes a dummy "0" value on the SCL and/or SDA lines of bus 32 to perturb the operation.

Secure access to peripherals on the SPI bus

FIG. 3 is a block diagram illustrating a security system 70 according to yet another embodiment of the present invention. In FIG. 3 , the security system 70 includes a host device 74 , a peripheral device 78 , and a security device 86 , all of which are connected to an SPI bus 82 .

Security device 86 identifies and disrupts unauthorized attempts by host device 74 to access perimeter 78 . In this example, the security device 86 includes an interface 90 to connect to the SPI bus 82 , a processor 94 to perform the techniques disclosed above, and a memory 98 to store one or more security devices implemented by the processor 94 policy.

In this embodiment, the security policy for distinguishing between authorized and unauthorized operations, and the manner in which the processor 94 of the security device 86 identifies unauthorized operations, is similar to the policy and manner of the security system 20 described above. . The following techniques differ from the above-described manner in which the security device 86 imposes a dummy value on the bus bar 82 to disrupt unauthorized operation.

The SPI bus 82 includes a clock (CLK) line and two data lines, including a master-out-slave-in (MOSI) line and a master-in-slave-out (MISO) line. The CLK, MISO, and MOSI lines are common to all devices, such as the safety devices 74, 78, and 86 in this embodiment. Besides, you can use a A dedicated chip select (CS) line is used to select each slave device. In this example, host device 74 uses CS line CS2# to select peripheral device 78 and CS line CS1# to select security device 86.

The host device 74 as a master is connected to all CS lines. On the other hand, peripheral devices are all slave devices, and each peripheral device is only connected to its own CS line. Typically, the host device 74 selects the desired peripheral device using the CS line and then communicates with the device using the CLK, MOSI and MISO lines to initiate a transaction. The MOSI line is used to transfer data from the host device to the peripheral device, and the MISO line is used to transfer data from the peripheral device to the host device.

Unlike conventional SPI slaves, watchdog 86 is defined as a slave that drives all CS lines. As shown in FIG. 3 , the interface 90 of the security device 86 can drive the CS line CS2# parallel to the host device 74 . When the system includes a plurality of peripheral devices 78 with respective CS lines, the safety device 86 can generally drive any CS line parallel to the host device 74 .

In some embodiments, the safety system is designed such that when host device 74 and watchdog 86 drive the CS line with opposite logic values, the logic value driven by watchdog 86 can override the logic value driven by host device 74 . That is, if the host device 74 and the watchdog 86 drive the CS line with opposite logic values, the peripheral device will receive the logic value driven by the watchdog 86 and act according to the received logic value.

In order to disrupt unauthorized operation between the host device and peripheral devices, another example is to cover the CS line to block operation on this bus. The above-mentioned overlay mechanism can be implemented in various ways. The above description is based on the CS line CS2# selecting the peripheral device 78, but the same mechanism can be applied to a plurality of peripheral devices and their respective CS lines.

In one embodiment, the line driver used by the security device 86 to drive the CS line CS2# of the interface 90 may be stronger than the line driver used by the host device 74 to drive the CS line CS2#. In one embodiment, a series resistor 100 may be inserted on the CS line CS2# of the output of the host device 74 . Resistor 100 attenuates the output of the CS2# line driver of the host device 74 relative to the output of the CS2# line driver of the safety device 86. out. In addition, any other method may be used by the watchdog device 86 to override the driving of the CS line CS2# by the host device 74 .

The processor 94 of the security device 86 may monitor the CS, CLK, MISO and/or MOSI lines of the SPI bus 82 in any suitable manner to identify unauthorized operations. In some embodiments, when an unauthorized host device 74 is identified as attempting to access a peripheral, the processor 94 of the security device 86 de-asserts the peripheral's CS line to disrupt this operation . Since the safety device 86 would override the drive of the CS line CS2# by the host device 74, the peripheral device would be reselected, thereby disrupting this operation. On the other hand, when determining that the operation is authorized, the processor 94 will stop its CS2# line driver, thereby allowing the host device to access the peripheral device 78 without being affected.

FIG. 4 is a block diagram illustrating a security system 110 according to another embodiment of the present invention. The safety system 110 is implemented based on the SPI bus 82, similar to the system 70 of FIG. However, the security system 110 does not override the CS line, but rather the security device 86 disrupts unauthorized operation by imposing dummy values on the CLK, MISO, and/or MOSI lines.

In this example, in the security system 110, the security device 86 overrides the driving of the CLK line, the MISO line and/or the MOSI line by the host device 74. As shown in the figure, the series resistor 100 is inserted on the CLK line, the MISO line and the MOSI line to realize the above functions. In this example, since the CS line CS2# is not covered, there is no series resistor inserted on the CS line.

In other embodiments, the above-described overlay mechanism may be implemented by making the line drivers of the CLK, MISO, and/or MOSI lines of the security device 86 stronger than the corresponding line drivers of the host device 74 .

In other embodiments, a hybrid scheme combining overlay CS lines (as shown in FIG. 3 ) and overlay CLK lines, MISO lines, and/or MOSI lines (as shown in FIG. 4 ) may also be used.

Overlay dedicated point-to-point signals for secure access to peripherals

The signals of a bus (eg, SPI bus) can be divided into shared signals and dedicated signals. The shared signal is the signal of a plurality of peripheral devices (eg, all peripheral devices) connected in parallel on the bus bar. For example, the shared SPI signals include data signals (MOSI and MISO signals) and clock (CLK) signals. A dedicated signal is a signal dedicated to a special peripheral device. For example, the dedicated signal for this bus is a chip select (CS) signal. In addition, the bus can be expanded to include additional dedicated signals, such as write-protect (WP) signals, which can be used when peripheral devices include memory devices. Dedicated signals may also be referred to as point-to-point (PTP) lines.

In some embodiments, the dedicated signal passes through the security device 86 before reaching the peripheral device. In contrast, shared signals are traditionally transmitted to peripheral devices without passing through the security device. This interconnection mechanism activates the safety device to effectively protect the safety of peripheral devices, which will be described in detail below.

FIG. 5 is a block diagram of a security system 130 according to yet another embodiment of the present invention. The safety system 130 of FIG. 5 is similar to the safety system 70 of FIG. 3 , but the CS2# signal of the system of FIG. 5 does not directly drive the input of the peripheral device 78 . Alternatively, the CS line CS2# of the host device 74 is input to the watchdog 86, which in turn drives the CS2_O# signal connected to the input of the peripheral device 78.

In this embodiment, the CS2# signal is used as an example of a dedicated PTP signal connected through a security device to protected peripheral devices. As shown in the figure, the shared signals (MOSI, MISO and CLK) between the host device 74 and the peripheral device 78 are not unbroken.

The security device 86 disrupts the operation between the host device 74 and the peripheral device 78 by selectively enabling the CS2# signal to the peripheral device or preventing the CS2# signal from reaching the peripheral device. In the example of FIG. 5, the above selection can be performed by setting the control signal MASK_CS2# to assert or deassert.

FIG. 6 is a block diagram of the security device 86 of the system 130 of FIG. 5 according to one embodiment of the present invention. In this example, the security device 86 includes an interface 90 for connecting to the SPI bus 82; a a processor 94 for implementing the techniques disclosed above; and a memory 98 for storing one or more security policies implemented by the processor 94 . The processor 94 includes a slave interface logic circuit 91 and an interface monitor logic (IML) 92 . Slave interface logic 91 handles communications between security device 86 and host device 74 . IML 92 is used to monitor, control, and selectively override host device 74 access to peripheral devices 78 .

In one embodiment, security device 86 identifies and disrupts unauthorized host device 74 attempts to access peripheral device 78 on SPI bus 82 . It can be understood from Figures 5 and 6 that any security features of the system shown in Figure 3 can also be implemented in the system of Figure 5.

In the above embodiments, the safety device is connected to the busbar and acts as an additional slave device. However, in other embodiments, the safety device may be connected as a master device. For example, such an embodiment may be applied to a bus protocol supporting multi-master capability.

Reply by the security device instead of the peripheral device to prevent unauthorized operation

In another embodiment, the security device 86 may respond to the selected host operation in place of the peripheral device 78 . The following description mainly refers to the configuration shown in FIG. 5 and FIG. 6 , for an exemplary description of the formula. Generally speaking, the technology disclosed in the present invention is not limited to a specific system configuration and can be applied to any other configuration, such as the system configuration shown in FIG. 3 or FIG. 4 .

In an exemplary embodiment related to the configurations of FIGS. 5 and 6, when a read command is detected for an address region in the address space of peripheral device 78, IML 92 may impose signal CS2_O# The high-level signal is used, and the internal memory 98 of the security device serves (responds to) the read command (or a part of the read command) of the host. The host device 74 is generally unaware that the response is not from a peripheral device. In some embodiments, the above mechanism may also be applied to the security system 110 of FIG. 4, eg, the security device may override the MISO signal.

An example of the use of this mechanism is a system where peripheral device 78 includes an SPI flash device, and secure device 86 covers a portion of the flash address space, thereby providing secure flash emulation for this address area . For example, the secure device 86 may include a Trusted Platform Module (TPM) that uses the IML 92 to overlay the flash memory address area containing the initial host boot code. The initial host startup code is a startup command extracted when the host is powered on. The trusted platform module can overwrite the flash memory address area where the verified initial boot code is stored separately, eg, the verified initial boot code can be verified before program execution jumps to the rest of the code.

In some embodiments, the security device 86 further includes a host interface for the SPI flash memory device. In addition, the security device 86 may include a suitable interface and circuitry to keep the host device 74 in a reset state when accessing the SPI flash device, a mechanism that is typically part of the system boot process. For example, the security device 86 may be an embedded controller (EC), a super I/O, or a baseboard management controller (BMC) device.

FIG. 7 is a flowchart illustrating an example of a secure boot procedure according to an embodiment of the present invention. This method starts from power up, eg, the system power is supplied. In the reset maintenance step S100, the security device 86 maintains the host device 74 in a reset state and optionally enables the SPI flash memory (peripheral device 78). In the initial loading step 104 (this is an optional step), the security device 86 loads a data segment from the SPI flash memory, verifies the authenticity of the data segment, and stores it in the internal memory 98 .

In an override step 108, the security device 86 sets the IML 92 to override access to at least one predefined address region in the SPI flash memory, which is the peripheral device 78 in this example. This protected address area may store, for example, one or more segments of keys, configuration data, and/or initial startup data for host device 74 .

In a reset release step 112, the security device 86 releases the reset state of the host device. Therefore, in a start-up step 116, the host device 74 begins its own boot-up procedure. During the start-up procedure, in A region access sub-step 120, with internal memory 98 serviced by the security device 86 to access a predefined address region.

In this way, the security device can securely protect sensitive information such as keys, configuration data and/or initial boot codes. The host device 74 does not know that the information it receives is from the secure device and not the SPI flash.

FIG. 7 illustrates an example method of how a security device can override access to a pre-defined address area of a peripheral device. In other embodiments, any other suitable method can be used for this application. Furthermore, when impersonating the SPI flash device, the security device may use any other suitable means to protect the flash device (or other peripheral devices) by covering and/or disrupting unauthorized operation.

Furthermore, coverage against unauthorized operations is not limited to protecting specific predefined address areas. For example, whether to trigger the overwrite operation can be determined according to the data returned by the protection peripheral device or the SPI command code. For example, a security device may implement a security policy to disable program, erase, enable write, status/configuration commands, and/or any other command or function of the flash memory device. The "SPI 3V Flash Memory with Dual/Quad SPI and QPI" document published by Winbond Electronics Co., Ltd. on August 24, 2015 has stated the example specification of the SPI flash memory instruction and control.

In another example, in the method shown in FIG. 7, the sensitive information is located in the flash memory device, activated and read by the security device as part of the boot process. In other embodiments, the sensitive information may be initially stored in the secure device, eg, both the secure device and flash memory store the sensitive information, or the secure device stores the secure device in place of flash memory. In this embodiment, the security device does not need to read this sensitive information from the flash memory device.

In another example, the method shown in Figure 7 is used with an SPI bus. In other embodiments, the security device may use bus dedicated signals (if any) and/or shared signals to override access to predefined address areas of peripheral devices via other busses and protocols. For example, the I2C bus is a pull ^- up bidirectional bus that supports slave devices and master devices. Therefore, the protocol has an embedded mechanism for handling competition among multiple devices. For example, when an I2C device tries to set it to " ¹ " (ie, a pull-up operation) and detects that the SDA line is "0", the device will assume contention and release the bus until the next time operate. In one embodiment, an I ² C security device (eg, security device 36 in FIG. 1 ) is used to overlap some address space of another peripheral slave device (eg, peripheral device 28 in FIG. 1 ). For example, a security device can be used to answer the same data expected by another peripheral device. If the watchdog detects a data inconsistency, eg, a device tries to pull up to a "1" but the SDA line detects a "0", the watchdog can start responding, eg, generating a stop condition, on Drive "0" on one or more data lines, set an infinite clock stretch, or any other suitable action. This technique uses a conventional I2C slave ⁽ no hardware changes required at the physical layer) to monitor devices pulling down data levels.

In yet another embodiment, the watchdog 86 (which uses the ILM 92) also monitors the data phase of the SPI address. When a data discrepancy is identified, the security device may initiate response measures, such as interrupting the operation, resetting the system, locking access to the key, or any other suitable measure.

In an example scenario, the security device 86 holds a signature or digest stored in a certain portion of code in SPI flash memory. The security device monitors the host device 74's access to the SPI flash memory and computes the signature or hash value of this portion of the code in the background. If a signature error, hash value error, or SPI extraction sequence error is detected, the security device 86 may initiate appropriate response actions.

In yet another embodiment, the security device may monitor at least one peripheral device 78 on the bus bar 82 and verify that the different devices are accessed in the same order as expected.

In yet another embodiment, the security device 86 uses one or more signals (other than the CS signal) to restrict access to or enforce the peripheral device 78 when an authorized operation of the peripheral device 78 is detected. A certain system state, such as the following example, but the invention is not limited by it:

‧Combined with any signal certified by the security system in Figure 4.

‧Write-protect signal of flash memory

‧Control reset signal.

‧Control power management signal.

• Control power to one or more devices.

• Disabling system communications; for example, disabling system communications by disabling a network interface controller (NIC).

‧Reset the system.

Watchdog monitors the SPI bus, allowing the host to safely boot from flash memory

In the above-mentioned embodiment, in order to protect the security of the boot process, the security device replaces the flash memory to respond to the boot code to a host device. In other embodiments described below, the host device may obtain the boot code from flash memory through a bus (eg, an SPI bus). The security device can protect the security of the boot procedure by monitoring the host computer's access to the memory on the bus. The secure device holds or has access to a copy of at least some of the host boot code and/or its digest. The security device can compare the replica with the boot code obtained by the host from flash memory (compute its digest if necessary), and initiate response actions when a non-compliance is detected.

The technology disclosed in the present invention activates the security device to protect against various security threats, such as a compromised host computer or a security threat from a flash memory device, or a security threat on an upper bus signal. The following descriptions use SPI bus and SPI flash memory as examples. The techniques disclosed in this disclosure can be applied in a similar manner to any other suitable bus bar and any other suitable non-volatile memory (NVM).

In various embodiments, the copy includes a true image of at least a portion of the boot code, eg, a listing of one or more boot code instructions. The order of instructions in this image can be the explicit order of the boot code, the order in which the boot code is executed (not necessarily sequentially), or any other order. In other embodiments, this copy may contain a true digest of at least a portion of the startup code. The summary may contain functions resulting from any or all of the operations of the startup code. In a In example embodiments, the digest (also referred to as a signature) may contain a hash value or a signed hash value. In the present invention, the above-mentioned digest may refer to a preservation hash algorithm (eg, SHA-256), or refer to a code signature using a mechanism like HMAC/CMAC, or refer to any other suitable algorithm.

The term "authentic" means that the image or summary is known and there is a high degree of confidence that it is uncorrupted and therefore trustworthy. For clarity of description, this real image or summary is referred to in the following paragraphs as a "copy" of at least a portion of the host's boot code. In the following example, the copy is stored internally, ie, a non-volatile memory of the security device. However, in other embodiments, this copy may be stored in non-volatile memory external to the secure device; in the latter embodiment, the copy may be marked with an appropriate security key, which is stored in the secure device.

As an example, the configuration described below refers to an SPI bus having a clock signal CLK, a chip select signal CS#, and four data lines D0-D3. Other bus types may have different numbers and types of wiring. For example, a single data line SPI may have fewer lines. The techniques disclosed herein can be implemented with any type of busbar.

FIG. 8 is a block diagram of a security system 140 according to an embodiment of the present invention. The security device 156 of the security system 140 protects the host device 144 from obtaining the boot procedure from the flash memory 148 on the SPI bus 152. . The security device 156 includes an interface 160 for connecting to the SPI bus 152, and a processor 164 for performing the methods described herein. The processor 164 may save or access a copy 168 (eg, an image or a digest) of at least a portion of the boot code of the host 144 . In this example, the chip select line (CS#) used to select flash memory device 148 also provides input to security device 156 .

FIG. 9 is a block diagram of a security system 170 according to one embodiment of the present invention. The security device 174 of the security system 170 protects the boot process of the host device 144 reading from the flash memory 148 on the SPI bus 152 of safety. The security device 174 includes an interface 178 for connecting to the SPI bus 152, and a processor 182 to perform the methods disclosed herein. The processor 182 may store or access the host A copy 186 of at least a portion of the boot code of the machine 144 (eg, an image or a digest). In this embodiment, all lines of SPI bus 152 (including four data lines D0 - D3 , clock line CLK, and CS# line for selecting flash memory device 148 ) provide input to security device 174 .

FIG. 10 is a block diagram of a security system 189 according to one embodiment of the present invention. The security device 187 of the security system 189 protects the host device 144 from reading the boot program from the flash memory 148 on the SPI bus. . In this example, the security device 187 includes an SPI bus monitor 188, which can implement the techniques disclosed herein using hardware and/or software modules. The security device further includes a memory (not shown) that stores a copy of at least a portion of the host 144 boot code.

Compared to the examples in FIGS. 8 and 9 , in this example, the CS# line of the flash memory of the SPI bus passes through the safety device 187 . Thus, the security device 187 can disconnect and/or modify the signal between the host 144 and the flash memory 148 . In this example, the data lines (D0~D3), the clock line (CLK), and the CS# line for selecting the flash memory device 148 all pass through the safety device 187, so these signal branches are not easily disconnected , SPI bus monitoring can be performed without disconnecting the connection between the host and the flash memory device. The data lines and clock lines are not interrupted, but the SPI bus monitor 188 can modify the CS# line. For example, if the boot code retrieved on the bus does not match this copy, the SPI bus monitor 188 can reset the CS# line, eg, set it high), thereby disrupting the boot process.

FIG. 11 is a flow chart of a method for protecting the startup security of the host device 144 according to an embodiment of the present invention. Variations of the method may be performed by the safety devices of the present invention, such as safety devices 156, 174 and 187 shown in Figures 8, 9 and 10. To simplify the description, the actions being performed by the security device are actually performed by the security device's processor (eg, processor 164 or 182 ), or by the SPI bus monitor 188 .

At the beginning of the method, at reset hold step 190, a security device keeps the host 144 in a reset state. At the get copy step 194, the security device obtains a copy of at least a portion of the host's boot code, eg, an image or a digest, while the host is in the reset state. If the copy is from a External memory is obtained and marked, the security device will usually verify the authenticity of the copy before processing. In one embodiment, a copy may be pre-stored in a secure device, such as during production of the system or at other stages before the system is provided to end users. In this embodiment, steps 190 and 194 may be omitted.

In the power-on activation step 198, the security device releases the host 144 from the reset state, and the host is powered on. During the boot process, the host 144 obtains the boot code from the flash memory device 148 through the SPI bus 152 and executes the obtained boot code.

During the boot process of the host, in a monitor and compare step 202, the security device monitors the data transmitted on the bus, and retrieves at least a portion of the boot code being transmitted, and compares the retrieved code to a copy .

In one embodiment, the security device may identify operations related to the boot process by identifying the address at which the host is accessing, which is designated as the address of the boot code.

In one embodiment, when the replica contains an image of a portion of the boot code, the security device typically compares the original data value fetched on the bus with the replica's corresponding data value. When the replica contains a digest of a portion of the boot code, the security device typically computes a digest of the code taken on the bus, and then compares the computed digest to the replica.

In a compliance check step 206, the watchdog checks whether the boot code that the host is fetching from the flash memory device (intercepted by the watchdog monitoring the SPI bus) matches the copy. If so, in the successful completion step 210, the security device allows the boot procedure to be successfully completed. If not, for example, in the start countermeasure step 214, if a non-compliance is detected, the security device assumes that the boot procedure has been compromised and initiates an appropriate countermeasure.

The flow chart shown in FIG. 11 is an exemplary flow chart for clearly describing the concepts. In other embodiments, any other suitable procedure may be used. For example, the security device does not necessarily need to keep the host device in a reset state. In other embodiments, for example, the secure device may obtain a copy before or after the host's boot process begins without stalling the host device.

In some cases, when computing a digest of at least a portion of the boot code intercepted on the SPI bus, the digest may be affected by system state or other parameters. Therefore, this digest may legitimately conform to at least two different copies. Thus, in some embodiments, the security device may maintain a plurality of different copies of the digest. The security device compares the digest calculated from the code intercepted by the bus with the plurality of copies. If the calculated digest matches any of the copies, the security device may permit the boot process to complete. If the calculated digest does not match either copy, the security device triggers a response action.

In various embodiments, when non-compliance is detected in step 206, the security device may perform or initiate various response measures, such as, but not limited to, the following exemplary actions.

‧Trigger the system to reset.

• Disturbing the boot process by imposing one or more dummy values on at least one line of the SPI bus 152. Any of the scrambling techniques described herein can be used.

The boot process is disrupted by disrupting one or more lines of the SPI bus between the host device and the NVM device, such as the CS# signal of the flash memory.

• Overlaying a signal on one or more lines of the SPI bus between the host device and the NVM device, eg, imposing a conflicting signal on the bus with the original signal.

Instead of the flash device, respond to the host device on the SPI bus and use the copy to complete the boot process.

‧Prevent the host device from accessing the resources of the security device, for example, to access predetermined confidential information stored in the security device.

‧Record warning or error record event in internal memory (eg, RAM or OTP), or issue an alarm signal.

any other suitable response or a combination thereof

In some embodiments, for example, when the boot process is still in progress, the security device can detect on-the-fly the inconsistency between the obtained boot code and the copy, so the response to disrupt the boot process is still Effective.

In other embodiments, the security device detects the above-mentioned non-compliance offline, such as in the background. In the present invention, the so-called "offline" means that the security device independently detects whether there is a non-compliance situation independently of the boot process. Therefore, the non-compliance detection is not in the critical path of the boot process, which affects the boot delay. little or no effect. Offline non-compliance detection can be performed after the boot process is completed, or in parallel or semi-parallel to the boot process. In these embodiments, the security device usually stores all or at least a part of the obtained activation code in a memory register for offline comparison of copies. For off-line non-compliance detection, the security device does not need to keep the host device in a reset state or stall the host device.

In some embodiments, the security device may maintain or access a configurable "whitelist" of SPI commands allowed during startup. When monitoring the bus, the security device can filter SPI commands against this whitelist, eg, to ensure that only commands on the whitelist can actually be delivered to the flash memory device. The whitelist can restrict the type of instruction or the address that can be accessed. For example, read commands to a specified address range may be permitted, while write commands or read commands to locations outside the specified address range may be inhibited.

The arrangement of systems 20, 70, 110, 130, 140, 170, and 189, and the arrangement of various system devices (such as various safety devices and busbars) shown in Figures 1, 3-6, and 8-10 are for clarity of description An exemplary configuration diagram illustrating the concept. In other embodiments, any other suitable configuration may be used.

For example, for clarity of description, only a single peripheral device and a single host device are shown in the above figures. In some embodiments, the system may include at least two peripheral devices and/or at least two host devices. The I ² C bus and the SPI bus described in the present invention are only illustrative, not limiting. In other embodiments, the techniques disclosed in the present invention may be implemented with any other suitable type of busbars or with necessary modifications.

As mentioned above, the security device can act as a slave device on the SPI bus. However, in this embodiment, even if the boot process is not required by the host device, the security device can still secure the boot process. Furthermore, in some embodiments, the security device may run one or more negative tests during the boot process. For example, when the CS# line is not asserted (eg, at a logic high level), the watchdog can check if any data or clock lines have changed or toggled their logic state. In some systems, when the flash memory device is not selected during the startup time, the SPI line should not change between a logic high level and a logic low level. For example, because there are no other SPI slaves on the bus, or even if there are other SPI slaves, they will not be addressed during the startup time. Therefore, when the CS# line has not been asserted (ie, at a low level) but the signal on the data line or the clock line is changing, it indicates that an attack is present. The safety device can use this indication to trigger an appropriate response.

Another integrity check that the security device may perform may be a timing integrity check. In one embodiment, during the boot process, the security device may verify that the time delay from a predetermined reset signal or power-on signal to a predetermined event is within a predefined range. For example, the watchdog may measure the time delay from a system reset to the occurrence of the first access instruction on the SPI bus. If the time delay is not within a predefined range, eg the time delay is longer or shorter than normal, the security device may assume that the busbar has been tampered with and trigger an appropriate response. In another embodiment, when the host is released from reset, the security device may check the images or digests taken by the host for a certain period of time, assuming that the host should end the boot sequence within this period of time.

In addition, the safety device can measure the analog electrical parameter value of at least one line of the SPI bus, and if the analog electrical parameter value falls outside the predefined range, the safety device triggers appropriate response measures. Analog values that can be used for the above purposes may include, for example, the capacitance value of one or more lines of an SPI bus Capacitance value, transit time or LRC delay. In some embodiments, such specific electrical parameters can be measured when the corresponding line is not being driven by the host or any other device on the bus, such as when the host is not powered on or remains in a reset state. Such techniques have been addressed in US Patent 7,797,115, the disclosure of which is incorporated herein by reference. In addition, any other suitable detection techniques can be used to measure the values of electrical parameters such as bus signals. In an exemplary embodiment, a predefined range for a given analog electrical parameter, eg, a range considering the normal capacitance values of a given line of an SPI bus, can be determined during system manufacture and stored in non-volatile memory. During startup, the safety device measures the current value of the target parameter and confirms that the measured value is within the allowable predefined range.

To improve security, the routing and physical layout of the SPI signals between the host device, the security device, and the NVM device may follow specific guidelines. For example, when implementing the system of the present invention on a printed circuit board (PCB), the following principles can make the SPI bus less vulnerable to attack.

The host device and the security device use a ball matrix (BGA) type package.

Transport in inner layers of the printed circuit board, eg, in layers that are not directly contactable or accessible from the outside.

When transmitting SPI signals through vias, it is preferable to use blind vias, for example, blind vias are used to connect connections between inner layers, and contact or access from the outside is not allowed.

Place the security device as close to the SPI pins of the host device as possible.

To further enhance security, the boot code can be set to output some data on the SPI bus, and the security device can validate this data. For example, the startup code can output some host register values, configurations, state variables, constants, OTP bits, and any other suitable host parameter values so that the security device can peer into the bus to verify these values. In some embodiments, the host parameter value may be processed as part of the code image/digest, while in other embodiments the host parameter value has reference data or an individual copy of the digest.

In some embodiments, the security device ensures the security of the boot process by responding to the host instead of the NVM device and responding to the host with a copy of the boot code instead of the NVM device. In one embodiment, the boot code that the security device responds to is variable, which causes the host's activity on the SPI bus to be different for different instances of the boot process. The startup code does not necessarily need to cause the host activity to be different under each bootloader entity, but at least under the selected entity causes the host activity to be different. By monitoring the activity of the host device on the bus, the security device can confirm that the boot code executed by the host in the physical boot process matches the boot code provided by the security device to the host device.

In the above-described embodiments, the security device may provide any suitable code that can cause a change in the activity detectable by the host on the bus. For example, the security device can operate the boot code image by changing at least one code value without affecting the execution flow. For example, this code value can be a dedicated code fixed value. Therefore, in this operation, according to this code value, the boot code executed by the host will output a value on the bus; thus, in a manner known by the safety device, as is the case with the boot procedure. The safety device reads the above value from the bus and confirms that the value matches the activation code currently provided to the host. The output value can contain, for example, the code's self-check summary, the value itself, or any function of it. Additionally, the output value may be determined by a shared secret known to the host and the security device.

In other embodiments, the start-up code may cause the host's activity on the bus to differ in other respects, not necessarily with respect to the output value. For example, the boot code may cause the host to experience different delays between different entities of the boot process. This delay difference can be achieved by, for example, the security device inserting a different number of NOP instructions into the boot code of different boot program entities. In this example, the safety device measures the delay and confirms that the actual delay matches the expected delay. The expected delay can be determined by the actual number of NOPs inserted in the current boot routine. Additionally, the watchdog can verify that all interposed NOP commands have been read; alternatively, the watchdog can measure a digest of the boot code on the bus and compare this digest to its own copy digest. Any other discrepancy in host activity can be used as long as the security device can detect the discrepancy.

The various means of the security systems 20, 70, 110, 130, 140, 170, 189 may be implemented in any suitable hardware, such as an application specific integrated circuit (ASIC), or a field programmable logic gate array (FPGA). In some embodiments, some means of the security device of the present invention, eg, the processor 44 or 94, may be implemented in software, or a combination of hardware and software modules. Memories 48 and 98, as well as memory holding a copy of the startup code shown in Figures 8-10, may be implemented by any suitable type of memory device, such as random access memory (RAM) or flash memory.

In some embodiments, processor 44, 94, 164 and/or 182 may comprise a general-purpose programmable processor programmed by software to perform the functions of the present invention. The software may be downloaded to the processor in the form of electronic signals over a network, for example, or may be provided and/or stored on non-transitory tangible media (eg, magnetic, optical, or electrical memory).

In some of the above-described embodiments, the security device first detects an unauthorized operation by monitoring the bus, and then disrupts the operation. In other embodiments, the safety device may disrupt this operation without first detecting on the bus or without monitoring the bus. For example, the security device can override the chip select (CS) line of a host until or unless the host is authorized. The above authorization may be performed in any suitable manner, not necessarily using the same busbars.

The methods and systems of the present invention can be used in various applications, such as secure memory applications, Internet of Things (IoT) applications, embedded applications, or automotive applications. The above are only examples, and the present invention is not limited thereto.

Although the present invention is disclosed above by the aforementioned embodiments, it is not intended to limit the present invention. Anyone who is familiar with the similar arts can make some changes and modifications without departing from the spirit and scope of the present invention. The scope of patent protection shall be determined by the scope of the patent application attached to this specification.

28: Peripherals

32: I ² C bus

36: Safety device

40: Interface

44: Processor

48: Memory

Claims (32)

A security device for monitoring system startup to ensure electronic system security, comprising: an interface for connecting to a bus serving a host device and a non-volatile memory (NVM) device; and a processor for connecting to The bus, the host device and the NVM device are also connected to the bus, and the processor is used to: detect a boot process on the bus in which the host device from the non-volatile memory The device obtains a boot code; and determines the security of the boot program according to a copy of at least a portion of the boot code of the host device; wherein the processor performs the following operations to determine the security of the boot program: in place of the non-volatile memory The device responds to the host device and provides an activation code to the host device, wherein the activation code causes the activity of the host device on the bus to be between the first and second instances of the boot procedure and monitoring the activity of the host device on the bus and confirming that the activity complies with the activation code provided to the host device. The security device of claim 1, wherein the processor is for retrieving at least a portion of the startup code from the bus, and when detecting a portion of the startup code obtained from the non-volatile memory device When there is a discrepancy between the at least part and the copy, a response action is initiated. The security device of claim 2, wherein the copy includes a copy of the activation code An image of the at least a portion, and the processor compares the image with at least a portion of the boot code obtained from the non-volatile memory device to detect the non-compliance. The security device of claim 2, wherein the copy includes an authentic digest of the at least a portion of the boot code, and the processor computes the boot code obtained from the non-volatile memory device at least a portion of a digest, and comparing the digest of the at least a portion of the boot code obtained from the non-volatile memory device with the real digest to detect the non-compliance. The security device of claim 2, wherein the processor detects the non-compliance while the boot process is in progress. The security device of claim 5, wherein in response to detecting the non-compliance, the processor is configured to impose one or more dummy values on at least one line of the bus to disrupt the boot process. The security device of claim 5, wherein in response to detecting the non-compliance, the processor disrupts the one or more lines of the bus between the host device and the non-volatile memory device to disrupt the boot procedure. The security device of claim 5, wherein in response to detecting the non-compliance, the processor responds to the host device on the bus in place of the non-volatile memory device to use the copy to complete the boot process. The security device of claim 2, wherein the processor detects the non-compliance independently of the boot process. The security device of claim 1, wherein the processor maintains the copy in an internal memory of the security device or in a memory external to the security device. The security device of claim 1, wherein the processor prevents the host device from accessing a given confidential information until security of the boot procedure is determined. The safety device of claim 1, wherein when a chip select (CS) line of the bus is not asserted, the processor operates by securing all data and clock lines of the bus The logical state of the device does not change to determine the safety of the boot procedure. The security device of claim 1, wherein the processor secures the boot process by ensuring that only bus commands that appear on a predefined whitelist are applied to the non-volatile memory device. The security device of claim 1, wherein the processor protects the system by ensuring that a time delay from a predetermined reset signal or power-on signal to a predetermined event in the boot procedure is within a predefined range Make sure the boot procedure is safe. The safety device of claim 1, wherein the processor secures the boot procedure by ensuring that an analog parameter value of at least one line of the bus falls within a predefined range. The safety device of claim 1, wherein the activation code instructs the host device to output one or more host parameter values on the bus, and the processor monitors and confirms the output on the bus by monitoring and confirming The host parameter value to determine the security of the boot procedure. A security method for monitoring system startup to ensure electronic system security, comprising: using a security device to communicate through a bus, wherein a host device and a non-volatile memory (NVM) are connected to the bus; and Using the security device to detect a boot process on the bus, in which the host device obtains a boot code from the non-volatile memory device, and based on at least a portion of the boot code of the host device A copy determines that the boot program is secure; wherein the step of determining that the boot program is secure includes: responding to the host device in place of the non-volatile memory device to provide a boot code to the host device to cause the host device to run on the bus differs between a first entity and a second entity of the boot procedure; and monitors the activity of the host device on the bus and confirms whether the activity is consistent with the boot provided to the host device code. The security method of claim 17, wherein the step of determining the security of the boot program comprises: retrieving at least a portion of the boot code from the bus, and when detecting that the boot code obtained from the non-volatile memory device is detected A response action is initiated when the at least a portion of the activation code does not conform to the copy. The security method of claim 18, wherein the copy includes an image of the at least a portion of the boot code, wherein the step of detecting a non-compliance includes comparing the at least a portion of the boot code obtained from the non-volatile memory device with this image. The security method of claim 18, wherein the copy includes a true digest of the at least a portion of the boot code, and the step of detecting non-compliance includes computing the boot code obtained from the non-volatile memory device. a digest of at least a portion, and comparing the digest of the at least a portion of the boot code obtained from the non-volatile memory device with the digest of the real digest. The security method of claim 18, wherein the detection is performed when the boot procedure is performed The non-conforming steps are executed simultaneously. The security method of claim 21, wherein the step of determining the security of the boot process comprises disrupting the boot by imposing one or more dummy values on at least one line of the bus in response to detecting a non-compliance program. The security method of claim 21, wherein the step of determining the security of the boot process comprises responding to detection of the non-compliance by disrupting one of the buses between the host device and the non-volatile memory device or multiple lines to disrupt the boot procedure. The security method of claim 21, wherein the step of determining the security of the boot process comprises: responding to the detection of the non-compliance, responding to the host device on the bus in place of the non-volatile memory device, and using the copy to complete the startup procedure. The security method of claim 18, wherein the step of detecting the non-compliance is performed independently of the boot process. The security method of claim 17, further comprising: saving the copy in an internal memory of the security device, or saving the copy in a memory outside the security device. The security method of claim 17, further comprising: preventing the host device from accessing a predetermined confidential information before the security of the boot procedure is determined. The security method of claim 17, wherein the step of determining that the boot process is secure further comprises: when a chip select (CS) line of the bus is not asserted, by The safety of the boot procedure is ensured by ensuring that the logic states of all data lines and clock lines of the bus do not change. The security method of claim 17, wherein the step of determining that the boot process is secure further comprises: determining the non-volatile memory device by ensuring that only bus commands that appear on a predefined whitelist are applied to the non-volatile memory device. Boot procedure security. The security method of claim 17, wherein the step of determining that the boot process is secure further comprises: by ensuring that a time delay from a predetermined reset signal or boot signal to a predetermined event in the boot process falls within a A predefined range to determine the security of the boot procedure. The security method of claim 17, wherein the step of determining the security of the boot process further comprises: determining the boot process by ensuring that an analog parameter value of at least one line of the bus falls within a predefined range of safety. The security method of claim 17, wherein the startup code instructs the host device to output one or more host parameter values on the bus, and the processor monitors and confirms the output on the bus by monitoring and confirming The host parameter value to determine the security of the boot procedure.

Images