TWI738135B - 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 particularly relates to a secure bootstrapping method and system.

The electronic device system uses various types of bus interfaces to communicate between the host device and the peripheral devices. An example of a bus interface is the serial peripheral interface bus (SPI bus). Peripheral devices that can support 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 that serves a host device and a non-volatile memory (NVM) device. The processor is connected to the bus, and the host device and the NVM device are also connected to the bus. The processor is used to detect a boot procedure on the bus, in which the host device is connected from the NVM The device obtains a startup code, and determines the safety of the startup procedure according to at least one copy of the startup code of the host device.

In some embodiments, the processor is used to retrieve at least a part of the activation code from the bus, and when it is detected that there is a gap between the at least part of the activation code obtained from the NVM device and the copy In case of non-compliance, a response measure 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 part of the startup code, and the processor calculates a digest of the at least part of the startup code obtained from the NVM device, and compares The abstract and the true abstract of the at least a part of the activation code obtained from the NVM device to detect the non-conformity.

In some embodiments, the processor detects the non-conformance while the boot process is in progress. In an exemplary embodiment, when the non-conformance is detected in response, the processor is used to impose one or more dummy values on at least one line of the bus to disturb the boot process. In one embodiment, in response to detecting the non-conformity, 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 replaces the NVM device on the bus to respond to the host device to use the copy to complete the boot process. In other embodiments, the processor detecting the non-conformance is independent of the boot process.

In one embodiment, the processor saves the copy in an internal memory of the security device, or saves the copy in a memory external to the security device. In another embodiment, before the security of the boot process is determined, the processor prevents the host device from accessing a predetermined confidential information.

In one embodiment, the processor performs the following operations to determine the safety of the boot process: instead of the NVM device responding to the host device, and providing a boot code to the host device, wherein the boot code causes the host device to be in the host device The activities carried out on the bus are the first actual There is a difference between an instance and a second entity; and monitor the activity of the host device on the bus, and confirm that the activity complies with the activation code provided to the host device.

In another embodiment, when a chip select (CS) line of the bus is not set to assert, the processor ensures that the logic state of all data lines and clock lines of the bus does not change , To confirm the safety of the boot procedure. In another embodiment, the processor ensures the safety of the boot process by ensuring that only bus commands appearing on a predefined whitelist are applied to the NVM device.

In an exemplary embodiment, the processor ensures that a time delay from a predetermined reset signal or a startup signal to a predetermined event in the startup procedure is within a predefined range to determine the start procedure Safety. In addition, the processor ensures the safety of the boot process by ensuring that one of the analog parameter values of at least one circuit of the bus falls within a predefined range. In one embodiment, 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 host parameter values output on the bus to Make sure that the boot procedure is safe.

An embodiment of the present invention provides a security method, which includes the following steps: 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 according to at least one copy of the boot code of the host device The safety of the program.

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 device through the bus. The processor is connected to the bus as an additional device. Peripheral device It is connected to the bus. The processor can disrupt the dedicated signal related to the predetermined peripheral device to disrupt the operation of the bus master device trying to access the predetermined peripheral device on the bus.

In some embodiments, the processor keeps the shared signal on the bus uninterrupted during the jamming operation. In one embodiment, this interface includes an input to receive a dedicated signal from the bus master device; and an output to transmit a dedicated signal to a predetermined peripheral device, and the processor can transmit a dedicated signal by preventing the input from being received To the output to disrupt the above operation. In some embodiments, the processor replaces the established peripheral device in response to the bus master 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 that must be disrupted by monitoring the bus. In another embodiment, the processor communicates with the bus master device on an auxiliary interface to detect operations that must be disrupted. The auxiliary interface is located outside the bus.

In one embodiment, the processor disturbs the dedicated signal indefinitely until the system is reset. In another embodiment, after detecting the above operation, the processor disturbs the dedicated signal for a limited period of time. In one embodiment, by disrupting the operation, the processor causes one or more peripheral devices to discard the operation. In some embodiments, after disturbing the operation, the processor resumes the 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 the peripheral device are connected to the bus. The processor responds to the bus master device by replacing the predetermined peripheral device to disrupt the operation of a bus master device on the bus that attempts to access a predetermined peripheral device.

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 between peripheral devices served by the bus, and the processor disturbs the predetermined Dedicated signals related to peripheral devices, and respond to the bus master device when the dedicated signals are disrupted, so as to disrupt the operation of the bus master device.

In some embodiments, the peripheral device includes a memory device, and the processor recognizes the request of the bus master device to read data from the memory device during the operation, and responds to the request with another data stored in the security device. In an exemplary embodiment, the processor responds with another data to the bus master's request for the memory device to access a predefined address area, thereby disrupting this operation.

In another embodiment, based on the data returned by the predetermined peripheral device to the bus master during operation, the processor recognizes the operation of the bus master attempting to access the predetermined peripheral device. In yet another embodiment, according to the instruction code used in the operation, the processor recognizes the operation of the bus master device trying to access a predetermined 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, wherein a host device and one or more peripheral devices are connected to the bus; wherein the bus Contains one or more dedicated signals, which are respectively dedicated to peripheral devices; and one or more shared signals, which are shared between peripheral devices of the bus service. Use a security device to disrupt the dedicated signal associated with a given peripheral device to disrupt the operation of the bus master device on the bus that attempts 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, wherein a host device and one or more peripheral devices are connected to the bus; using a security device By replacing the predetermined peripheral device in response to the bus master device, the operation of the bus master device trying to access a predetermined peripheral device on the bus is disturbed.

According to another embodiment of the present invention, a security device is provided, which includes an interface and a processor. The interface communicates via a bus. The processor imposes one or more dummy values on at least one line on the bus by being parallel to at least a part of the operation, so as to disrupt an unauthorized attempt to access a peripheral device on the bus by the bus master device.

In one embodiment, the processor imposes a virtual value on a data line of the bus, so as to disrupt the transmission of data values sent or received from peripheral devices on the data line. In addition, the processor can A virtual value is imposed on the clock line of the bus to disturb the clock signal used for this operation. In addition, the processor can impose dummy values on the chip selection line of the bus, thereby disrupting the selection of peripheral devices by the bus master device.

In some embodiments, the bus includes an open-drain or open-collector bus with a preset logic value, and the processor can write the opposite value of the preset logic value by at least one line of this bus To impose a virtual value.

In some embodiments, by imposing a virtual value, the processor can overwrite the corresponding corresponding value written on at least one line by the main bus device or the peripheral device. In an exemplary embodiment, the processor may drive at least one circuit with a strong drive strength bus main device or peripheral device that knows the drive strength to cover the value written by the bus main device or the peripheral device. In other embodiments, the device includes at least one resistor, which is inserted in at least one circuit to weaken the value written by the main bus device or peripheral device, and make it weaker than the virtual value written by the processor. value.

In some embodiments, the processor only uses the existing lines of the bus for communication between the main bus device and peripheral devices to impose a virtual value. In some embodiments, the processor monitors the bus to detect operations that must be disrupted. In one embodiment, the processor communicates with the main bus device on the auxiliary interface to detect operations that must be disrupted. The auxiliary interface is located outside the bus.

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

According to an embodiment of the present invention, a security system is further provided, which includes a peripheral device and a security device. One or more bus master devices can access peripheral devices through a bus. The security device can impose one or more virtual values on at least one line in parallel to at least a part of the operation, so as to disrupt the operation of the bus master device on the bus that attempts to access peripheral devices without authorization.

According to an embodiment of the present invention, a security method is further provided, which includes the following steps: using a security device to couple to a bus, and deciding to disrupt an unauthorized attempt to access a peripheral device by the bus master device. By imposing one or more dummy values on at least one line of the bus by at least a part of the operation in parallel, this operation is disrupted.

110, 189, 130, 140, 170, 70, 20: security system

144, 74, 24: host device

148: flash memory

152, 82: SPI bus

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: Peripheral devices

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

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

FIG. 2 is a flowchart illustrating a method for securely accessing a peripheral device ^{on an I 2 C bus according to an embodiment of the present invention.}

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

Figure 6 is a block diagram of a security device according to an embodiment of the present invention.

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

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

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

The following describes the implementation of the present invention in detail with the drawings and embodiments, so as to fully understand and implement the implementation process of how the present invention uses technical means to solve technical problems and achieve technical effects.

Overview

The embodiments of the present invention describe a method and device for protecting the access security of peripheral devices on the bus interface. Peripheral devices can include, for example, encryption engines, memory devices that store sensitive data, or any other similar devices that are accessed through a bus.

In some embodiments, the security device monitors transactions on the bus, and recognizes unauthorized access by the host device or other bus master devices to peripheral devices. According to any suitable criteria or policies, these operations can be classified into authorized operations and unauthorized operations.

When an unauthorized operation is identified, the security device can deliberately impose some virtual values on one or more lines of the bus or on the signal while parallel to this operation, so as to disrupt the unauthorized operation . The aforementioned virtual value may be imposed on, for example, a clock signal, a data signal, and/or a chip select (CS) signal.

By imposing a virtual value on the bus to disrupt the operation is suitable, for example, an open-drain bus or an open-collector bus, such as an I ² C bus, And push-pull bus, such as SPI bus. Parallel to unauthorized operations at the same time, imposing virtual values on the bus can override the communication with the peripheral device and disrupt the clock signal.

The following will describe several ^{example techniques for disturbing unauthorized operations on the I 2} C and SPI bus, and also describe techniques for restoring normal operation after disturbing. In some embodiments, the security device does not need to detect this unauthorized operation on the bus, or even monitor the bus, to perform the disturbance. For example, the security device can impose a dummy value on the chip select (CS) circuit of a certain host until or unless the host obtains authorization.

In some embodiments, for example, in the SPI bus, the bus protected by the security device includes: (i) one or more dedicated signals, which are respectively 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 related to the protected peripheral device while maintaining a shared signal on the bus. However, it should be noted that not all buses have dedicated signals. For example, in the I ² C bus, all signals are shared signals.

In other embodiments, the security device responds to the unauthorized host by replacing the protected peripheral device to disrupt this operation. In an exemplary embodiment, the peripheral device includes a flash memory, which includes one or more address areas for storing sensitive data (such as keys, configuration data, and/or activation codes). By selectively overriding the CS signal of the flash memory, the security device can cover the operation of accessing the data of the flash memory. The security device responds to the host with the data stored in it. This kind of secure boot procedure will be described below.

The technology disclosed in the present invention provides real-time safe and selective access to peripheral devices at a transaction-by-transaction level. In the embodiment of the present invention, only the existing signal of the bus is used for operation identification and operation disturbance. Therefore, the technology disclosed in the present invention does not require additional pins or interconnection lines, thereby reducing the overall system size and cost.

In other embodiments, the security device protects the security of the boot process of the host device. During the boot process, the host device obtains a boot code from a non-volatile memory (NVM) device through a bus. For example, the host can start booting from an SPI flash memory device on an SPI bus. In some embodiments, during the boot process, the security device monitors the bus and compares the host to obtain At least a part of the boot code and a known copy, such as boot code image or digest. When a discrepancy between the activation code obtained on the bus and the known copy of the security device is detected, a response measure is triggered. The technology of the present invention can activate the security device protection system to resist a variety of security threats, for example, a stolen host or flash memory device, or an attack on a bus signal. In the following, several exemplary embodiments and variations of the secure boot procedure will be described.

Safely access peripheral devices on the I ^{2 C bus}

FIG. 1 is a block diagram of a security system 20 according to an 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 make the description more concise, the host device 24 and the peripheral device 28 may be referred to as the host and the peripheral, respectively. The host device 24 is sometimes referred to as a bus master.

The security device 36 ^{protects the access to the peripheral device 28 by monitoring the operation on the I 2} C bus, and prevents the host 24 or another device capable of the bus master from attempting to access without authorization Unauthorized operation of peripheral 28. The security device 36 is sometimes referred to as a control device or a trusted platform module (TPM). In this example, the security device 36 includes an interface 40, a processor 44, and a memory 48. The interface 40 is used to connect to the I ² C bus 32, the processor 44 executes the technology disclosed in the present invention, and the memory 48 stores one or more security policies implemented by the processor 44.

According to any predefined or set strategy, the processor 44 can classify a transaction. Generally speaking, unauthorized operations will attempt to write data to the peripheral device, read data from the peripheral device, set or send commands to the peripheral device, or access the peripheral device in any other way. The strategy implemented by the security device can include a positive strategy, such as a whitelist; a negative strategy, such as a blacklist; a strategy that depends on the device address or register offset; or any other type The strategy.

For example, before the host is authorized to access peripheral devices, the host may be required to allow the security device to verify its identity. Operations attempted by unauthorized hosts will be deemed unauthorized. E.g, Some challenge-response processes can be used between the host and the security device to perform authentication. In addition, the host may be required to prove the identity in other suitable ways, or successfully complete a secure boot procedure.

In addition, some types of operations (for example, read operations) can be regarded as authorized, while other types of operations (for example, write operations) can be regarded as unauthorized. In another example, the operation of accessing the preset address of the peripheral device can be regarded as authorized, and the operation of accessing other addresses can be regarded as unauthorized. In another example, some bit sequences on the bus may represent an unauthorized operation.

Generally speaking, the processor 44 can distinguish between authorized operations and unauthorized operations in any suitable manner. At least one strategy for distinguishing between authorized operations and unauthorized operations can be stored in the memory 48.

The I ² C bus 32 includes a serial data (SDA) line for transmitting a serial data signal; and a serial clock (SCL) line for carrying a serial clock signal. The terms "line" and "signal" are used interchangeably in this article. By monitoring the SDA line and the SCL line, the processor 44 can monitor ^{any operations interacting on the I 2} C bus and identify unauthorized operations.

When an unauthorized operation is identified, the processor 44 imposes one or more virtual values on the DSA line and/or SCL line of the ^{I 2 C bus 32 to disrupt the unauthorized operation.} This mechanism is feasible due to the open drain/open collector structure of the ^{I 2 C bus.} Generally, the SDA line and the SCL line are pulled up to a logic "1" state (that is, a high voltage level) by using a pull-up resistor. Any device can write a "0" value on the SDA line or the SCL line at any time to impose a logic "0" (ie, low voltage level), regardless of what value is written by other devices at the same time.

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

In some embodiments, the processor 44 continues to impose a "0" value indefinitely, for example, until a power-on reset is performed. In other embodiments, the processor 44 can restore the host reset 24 and the peripheral reset 28 to normal operation from the state of being disturbed. Some host resets and/or peripheral devices cannot resume normal operation from a clock pause. Therefore, if the host is reset and the peripheral devices need to be restored to normal operation, it is better to impose a dummy value on the SDA instead of imposing a dummy value on the SCL line.

In one embodiment, in order to return to normal operation after the disturbed operation, the processor 44 generates an I ² C stop or restart condition on the bus. In this article, the I ² C stop or restart condition can include any sequence of bus signal values that inform the device that the bus can start operating freely.

The processor 44 can use a variety of techniques to recover from disrupted operation to normal operation. In one embodiment, the processor 44 only imposes a "0" value for a predefined length of time, which is sufficient to disrupt this unauthorized operation. Any pre-defined length of time can be used. For example, the SMBus specification defines a pause time of 25mS. Thus, operation ^{SMBus (SMBus-over-I 2} C) applications on the I ² C, can be set as the predefined length of time 25 mS, to trigger the suspension.

In another embodiment, the processor 44 may impose a "0" value on the SDA line until it is detected that the SCL line has been at a high level (for example, without disturbance) for at least a predefined time period. This condition can indicate that the host has ended or abandoned this operation. Then, the processor 44 can release the SDA line and possibly generate an I ² C stop condition.

In another embodiment, in order to effectively disrupt the unauthorized operation of reading data from the peripheral device, the security device 36 can be used as an I ² C slave device with the same device address as the peripheral device 28. The processor 44 of the security device 36 can respond to this unauthorized reading request with a "0" data value. While the processor 44 is operating, the peripheral device 28 will also respond to this read request, but the data value transmitted by it will be overwritten by the "0" value sent by the security device 36. This program will continue to execute until the host ends the operation due to a stop condition. It should be noted that according to the I ² C specification, the I ² C slave device will not drive the ACK/NEGACK bit when transmitting data.

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

The above-mentioned disturbance and recovery techniques are only illustrative. In other embodiments, the processor 44 of the security device 36 can use any other suitable technology to disrupt the operation, and restore from the disruption to normal operation.

In the above example, the detection of unauthorized operation, the disturbance of unauthorized operation, and the restoration of normal operation after the disturbance are all realized by using the existing lines 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 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 pin and the SCL pin of the integrated circuit.

In these embodiments, the security device 36 and the host device 24 can use an auxiliary interface to confirm that no other host device accesses the peripheral device 28. In an exemplary embodiment, whenever the host 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 will not impose a pseudo "0" value on the bus, but will allow this operation to proceed. When an operation is detected to access the peripheral 28 but there is no notification on the auxiliary interface, the processor 44 assumes that the operation is performed by an unauthorized host, and then imposes a value of "0" to disrupt the unauthorized operation. Authorized operation.

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

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

In an agreement step 62, if the operation is found to be authorized, the processor 44 allows the operation to proceed normally. Otherwise, in a jamming step 66, if it is found that the operation is unauthorized, the processor 44 imposes a false "0" value on the SCL line and/or SDA line of the bus 32 to disrupt the operation.

Secure access to peripheral devices on the SPI bus

FIG. 3 is a block diagram of a security system 70 according to 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, and these devices are all connected to an SPI bus 82.

The security device 86 recognizes and disrupts the operation of the host device 74 attempting to access the periphery 78 without authorization. In this example, the security device 86 includes an interface 90 to connect to the SPI bus 82, a processor 94 to execute the techniques disclosed above, and a memory 98 to store one or more security implemented by the processor 94 policy.

In this embodiment, the security policy used to distinguish between authorized operations and unauthorized operations, and the way that the processor 94 of the security device 86 recognizes unauthorized operations is similar to the policies and methods of the security system 20 described above. . The following technology is different from the above-mentioned way that the security device 86 imposes a virtual value on the bus 82 to disrupt unauthorized operations.

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 line, the MISO line, and the MOSI line are commonly used for all devices, such as the security devices 74, 78, and 86 in this embodiment. In addition, you can use a A dedicated chip select (CS) line is used to select each slave device. In this example, the host device 74 uses the CS line CS2# to select the peripheral device 78 and the CS line CS1# to select the 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. Generally, the host device 74 uses the CS line to select the required peripheral devices and then communicates with the devices using the CLK line, MOSI line, and MISO line to start a transaction. The MOSI line is used to transmit data from the host device to the peripheral device, and the MISO line is used to transmit data from the peripheral device to the host device.

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

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

In order to disrupt unauthorized operations between the host device and peripheral devices, another example is to cover the CS line to block operations on this bus. The above-mentioned coverage mechanism can be implemented in a variety of ways. The above description is based on the CS line CS2# selecting the peripheral device 78, but the same mechanism can also 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 is stronger than the line driver used by the host device 74 to drive the CS line CS2#. In one embodiment, a series resistor 100 can be inserted into the output CS line CS2# of the host device 74. Compared with the output of the CS2# line driver of the safety device 86, the resistance 100 will weaken the output of the CS2# line driver of the host device 74 out. In addition, the security device 86 can use any other method to cover the driving of the CS line CS2# by the host device 74.

The processor 94 of the security device 86 can monitor the CS line, the CLK line, the MISO line and/or the MOSI line of the SPI bus 82, and use any suitable method to identify unauthorized operations. In some embodiments, when it is recognized that an unauthorized host device 74 attempts to access a peripheral device, the processor 94 of the security device 86 will reset (de-assert) the CS line of the peripheral device to disrupt this operation . Since the safety device 86 will cover the driving of the CS line CS2# by the host device 74, the peripheral device will be reselected, thereby disrupting this operation. On the other hand, when it is determined that this 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 of a security system 110 according to another embodiment of the present invention. The security system 110 is implemented based on the SPI bus 82, which is similar to the system 70 in FIG. 3. However, the security system 110 does not cover the CS line, but the security device 86 disrupts unauthorized operations by imposing dummy values on the CLK line, MISO line, and/or MOSI line.

In this example, in the security system 110, the security device 86 will cover 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 in the CLK line, the MISO line and the MOSI line to realize the above-mentioned functions. In this example, since the CS line CS2# is not covered, there is no series resistor inserted in the CS line.

In other embodiments, the line driver of the CLK line, MISO line, and/or MOSI line of the security device 86 can be stronger than the corresponding line driver of the host device 74 to achieve the above-mentioned coverage mechanism.

In other embodiments, a hybrid mechanism combining covering the CS line (as shown in Figure 3) and covering the CLK line, MISO line and/or MOSI line (as shown in Figure 4) can also be used.

Overlay dedicated point-to-point signals for secure access to peripheral devices

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

In some embodiments, the dedicated signal passes through the security device 86 before the dedicated signal reaches the peripheral device. In contrast, shared signals will be transmitted to peripheral devices in a traditional way and will not pass through security devices. This interconnection mechanism will activate the safety device to effectively protect the safety of the surrounding devices, which will be described in detail below.

FIG. 5 is a block diagram of the security system 130 according to another embodiment of the present invention. The security system 130 in Fig. 5 is similar to the security system 70 in Fig. 3, but the CS2# signal of the system in 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 security device 86, and then the security device 86 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 to a protected peripheral device through a security device. As shown in the figure, the shared signals (MOSI, MISO, and CLK) between the host device 74 and the peripheral device 78 will not be unbroken.

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

FIG. 6 is a block diagram of the security device 86 of the system 130 in FIG. 5 according to an embodiment of the present invention. In this example, the security device 86 includes an interface 90 for connecting to the SPI bus 82; The processor 94 is used to execute the techniques disclosed above; and a memory 98 is used to store 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. The slave interface logic circuit 91 is used to handle the communication between the security device 86 and the host device 74. The IML 92 is used to monitor, control and selectively cover the access of the host device 74 to the peripheral device 78.

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

In the above embodiment, the safety device is connected to the bus bar and used as an additional slave device. However, in other embodiments, the safety device can be connected as a master device. For example, this embodiment can be applied to a bus protocol that supports the capability of a multi-master device (mult-master).

Respond from peripheral devices by security devices to prevent unauthorized operations

In another embodiment, the security device 86 can replace the peripheral device 78 to respond to selected host operations. The following description mainly refers to the configuration shown in FIG. 5 and FIG. 6 for exemplification. Generally speaking, the technology disclosed in the present invention is not limited to a special system configuration but 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 configuration of FIGS. 5 and 6, when a read command is detected for an address area in the address space of the peripheral device 78, the IML 92 can impose the signal CS2_O# The high-level signal, and the internal memory 98 of the security device serves (responds to) the host's read command (or part of the read command). The host device 74 usually does not know that the response is not from a peripheral device. In some embodiments, the above-mentioned mechanism can also be applied to the security system 110 in FIG. 4, for example, the security device can cover the MISO signal.

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

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

FIG. 7 is a flowchart of an example of a secure boot procedure according to an embodiment of the present invention. This method starts from power-on, for example, the system power is supplied. In the reset maintenance step S100, the security device 86 maintains the host device 74 in the reset state and optionally activates 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 a covering step 108, the security device 86 sets the IML 92 to cover access to at least one predefined address area in the SPI flash memory (which is the peripheral device 78 in this example). This protected address area can store, for example, one or more keys, configuration data, and/or the initial activation data segment of the host device 74.

In a reset release step 112, the security device 86 releases the reset state of the host device. Therefore, in a booting step 116, the host device 74 starts its own booting process. In the boot process, in In a region access sub-step 120, the security device 86 uses the internal memory 98 to serve the access to the predefined address region.

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

Figure 7 shows an example method of how the security device covers the access to the pre-defined address area of the peripheral device. In other embodiments, any other suitable methods can be used for this application. In addition, when the SPI flash memory device is impersonated, the security device can use any other suitable method to protect the flash memory device (or other peripheral devices) by covering and/or disrupting unauthorized operations.

Furthermore, the coverage of unauthorized operations is not limited to the protection of special pre-defined address areas. For example, it can be determined whether to trigger the overwrite operation based on the data returned by the protection peripheral device or the SPI command code. For example, the security device can implement a security policy to disable programming, erasing, enabling writing, status/configuration commands, and/or any other commands or functions 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 already contains sample specifications for SPI flash memory commands and controls.

In another example, in the method shown in Figure 7, the sensitive information is located in the flash memory device and is 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 security device. For example, both the security device and the flash memory store the sensitive information, or the security device replaces the flash memory and stores the security device. 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 can use the dedicated signal (if any) of the bus and/or the shared signal to cover access to the pre-defined address area of the peripheral device through other buses and protocols. For example, the I ² C bus is a pull-up two-way bus, which is used to support multiple slave devices and multiple master devices. Therefore, this protocol has an embedded mechanism for handling competition among multiple devices. For example, when an I ² C device tries to set it to "1" (that is, it is 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, the I ² C security device (for example, the security device 36 in Figure 1) is used to overlap some address spaces of another peripheral slave device (for example, the peripheral device 28 in Figure 1). For example, a security device can be used to answer the same data expected by another peripheral device. If the security device detects that there is data that does not match, for example, a device tries to pull up to "1" but the SDA line detects it as "0", the security device can start to respond, for example, generate a stop condition, Drive "0" on one or more data lines, set an infinite clock extension, or any other suitable actions. This technology uses a traditional I ² C slave device (the physical layer does not require hardware changes) to monitor the device that pulls down the data level.

In another embodiment, the security device 86 (which uses ILM 92) also monitors the data phase of the SPI address. When it is recognized that there is data inconsistency, the security device can initiate response measures, such as interrupting the operation, resetting the system, locking access to the key, or any other suitable measures.

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

In another embodiment, the security device can monitor at least one peripheral device 78 on the bus 82 and verify whether the access sequence of different devices is the same as expected.

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

‧Any signal certified by the security system in Figure 4.

‧Write-protect signal of flash memory

‧Control the reset signal.

‧Control the power management signal.

‧Control the power to one or more devices.

‧Disable system communication; for example, you can disable system communication by disabling a network interface controller (NIC).

‧Reset the system.

The security device monitors the SPI bus, allowing the host to safely boot from the flash memory

In one of the above embodiments, 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 can obtain the boot code from the flash memory through a bus (such as an SPI bus). The security device can protect the security of the boot process by monitoring the host's access to the memory on the bus. The security device holds or has access to a copy of at least some of the host startup code and/or its digest. The security device can compare the copy with the activation code that the host obtains from the flash memory (compute its digest if necessary), and initiate response measures when a non-compliance is detected.

The technology disclosed in the present invention activates a security device to prevent multiple security threats, for example, a security threat from a stolen host or flash memory device, or a security threat on the upper bus signal. The following description takes SPI bus and SPI flash memory as an example. The technology disclosed in the present invention can be applied to any other suitable bus and any other suitable non-volatile memory (NVM) in a similar manner.

In various embodiments, the copy includes a real image of at least a portion of the boot code, for example, a list of one or more boot code instructions. The order of instructions in this image can be the explicit order of the startup code, the execution order of the startup code during execution (not necessarily in sequence), or any other order. In other embodiments, this copy may include a true summary of at least a portion of the activation code. The summary can include functions generated by any part or all of the operations of the startup code. In a In an exemplary embodiment, the summary (also referred to as a signature) may include a hash value or a signed hash value. In the present invention, the above abstract can refer to a secure hash algorithm (such as SHA-256), or use a mechanism similar to HMAC/CMAC to refer to code signatures, or refer to any other suitable algorithm.

The term "true" means that the image or abstract 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 as a "copy" of at least a part of the host's startup code in the following paragraphs. In the following example, the copy is stored internally, which is a non-volatile memory of the security device. However, in other embodiments, the copy may be stored in a non-volatile memory outside the security device; in the latter embodiment, the copy may be marked with a suitable security key, which is stored in the security device.

As an example, the configuration described below refers to an SPI bus with a clock signal CLK, a chip selection signal CS#, and four data lines D0~D3. Other bus types can have different numbers and types of lines. For example, a single data line SPI may have fewer lines. The technology disclosed in the present invention can be implemented with any type of bus.

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 program 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 executing the method described in the present invention. The processor 164 may save or access a copy 168 (for example, an image or a digest) of at least a part of the boot code of the host 144. In this example, the chip select line (CS#) used to select the flash memory device 148 also provides input to the security device 156.

Figure 9 is a block diagram of a security system 170 according to an embodiment of the present invention. The security device 174 of the security system 170 protects the host device 144 from the boot process read from the flash memory 148 on the SPI bus 152的安全。 The safety. The security device 174 includes an interface 178 for connecting to the SPI bus 152, and a processor 182 to execute the method disclosed in the present invention. The processor 182 can save or access the main A copy 186 (for example, an image or a summary) of at least a portion of the boot code of the machine 144. In this embodiment, all the lines of the SPI bus 152 (including the four data lines D0~D3, the clock line CLK, and the CS# line for selecting the flash memory device 148) provide input to the security device 174.

Figure 10 is a block diagram of a security system 189 according to an 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 use hardware and/or software modules to implement the technology disclosed in the present invention. The security device further includes a memory (not shown in the figure), which stores a copy of at least a part of the activation code of the host 144.

Compared with the examples in Figs. 8 and 9, in this example, the CS# line of the flash memory of the SPI bus passes through the security device 187. Therefore, the safety device 187 can disconnect and/or modify the signal between the host 144 and the flash memory 148. In this example, the data line (D0~D3), the clock line (CLK), and the CS# line used to select the flash memory device 148 all pass through the safety device 187, so these signal branches are not easy to disconnect , You can perform SPI bus monitoring without disconnecting the connection between the host and the flash memory device. The data line and the clock line are not interrupted, but the SPI bus monitor 188 can modify the CS# line. For example, if the boot code obtained on the bus does not match this copy, the SPI bus monitor 188 can reset the CS# line, for example, set it to a high level, thereby disrupting the boot process.

FIG. 11 is a flowchart of a method for protecting the host device 144 to start securely according to an embodiment of the present invention. Variations of the method can be implemented by the safety device of the present invention (for example, the safety devices 156, 174, and 187 shown in Figures 8, 9 and 10). To make the description more concise, the actions being performed by the security device are actually executed by the processor (such as the processor 164 or 182) of the security device, or by the SPI bus monitor 188.

At the beginning of the method, in the reset holding step 190, a security device keeps the host 144 in a reset state. In step 194 of obtaining a copy, when the host is in the reset state, the security device obtains a copy of at least a part of the boot code of the host, for example, an image or a summary. If the copy is from a If the external memory is obtained and marked, the security device usually verifies the authenticity of the copy before processing. In one embodiment, the copy may be pre-stored in the security device, for example, during the production of the system or at other stages before the system is provided to the end user. In this embodiment, steps 190 and 194 can be omitted.

In the booting step 198, the security device releases the host 144 from the reset state, and the host starts to boot. During the boot process, the host 144 obtains the boot code from the flash memory device 148 through the SPI bus 152 and runs the obtained boot code.

During the boot process of the host, in a monitoring and comparison step 202, the security device monitors the data transmitted on the bus, and retrieves at least a part of the boot code being transmitted, and compares the retrieved code with the copy .

In one embodiment, the security device can identify operations related to the boot process by identifying the address that the host is accessing (which is designated as the address of the startup code).

In one embodiment, when the copy contains an image of a part of the activation code, the security device usually compares the original data value obtained on the bus with the corresponding data value of the copy. When the copy contains a summary of part of the activation code, the security device usually calculates the summary of the code obtained on the bus, and then compares the calculated summary with the copy.

In a compliance check step 206, the security device checks whether the boot code (which the security device monitors the SPI bus intercepted by the security device monitors the SPI bus) that the host is getting from the flash memory device conforms to the copy. If yes, after successfully completing step 210, the security device allows the boot process to be successfully completed. If not, for example, in the starting countermeasure step 214, if it is detected that the two do not match, the security device assumes that the boot process has been stolen, and initiates a suitable countermeasure.

The flowchart shown in Fig. 11 is an exemplary flowchart for clearly describing the concept. In other embodiments, any other suitable procedures can 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 security device can obtain a copy before or after the start of the boot process of the host without stalling the host device.

In some cases, when calculating the summary of at least a part of the startup code intercepted on the SPI bus, the summary may be affected by system status or other parameters. Therefore, this abstract may legally correspond to at least two different copies. Therefore, in some embodiments, the security device can store multiple different copies of the digest. The security device compares the digest calculated from the code intercepted by the bus with multiple copies. If the calculated summary matches any copy, the security device may permit the boot process to complete. If the calculated digest does not match any copy, the security device triggers a response measure.

In various embodiments, when a non-compliance is detected in step 206, the security device may execute or initiate various response measures, for example, but the present invention is not limited to the following exemplary actions.

‧Trigger the system to reset.

‧ Disrupt the boot process by imposing one or more dummy values on at least one line of the SPI bus 152. Any of the jamming techniques described in this invention can be used.

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, the boot process is disrupted.

‧Overlay the signal on one or more lines of the SPI bus between the host device and the NVM device, for example, imposing a conflicting signal on the bus with the original signal.

Instead of the flash memory 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, access to the established confidential information stored in the security device.

‧Record alarms or error events in internal memory (for example, RAM or OTP), or issue an alarm signal.

Any other suitable response measures or their combination

In some embodiments, for example, when the boot process is still in progress, the security device can immediately (on-the-fly) detect 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 aforementioned non-compliance offline, for example, in the background. In the present invention, the so-called "offline" means that the security device independently detects whether there is a non-conformance independent of the boot process. Therefore, the non-conformance detection is not in the critical path of the boot process, which affects the boot delay. Small or no impact. Offline non-conformance 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 the memory register for offline comparison of the copy. For offline non-conformance detection, the security device does not need to keep the host device in a reset state or delay the host device.

In some embodiments, the security device can save or access a configurable "white list" of SPI commands allowed during startup. When monitoring the bus, the security device can filter SPI commands based on this whitelist, for example, to ensure that only commands on the whitelist can actually be sent to the flash memory device. This whitelist can restrict the types of commands or the addresses to be accessed. For example, a read command to a specified address range can be allowed, while a write command or a read command to a location outside the specified address range is prohibited.

The settings of systems 20, 70, 110, 130, 140, 170, and 189 shown in Figures 1, 3-6 and 8-10, and the configuration of various system devices (such as various safety devices and busbars) are for clear description Conceptually drawn exemplary configuration diagram. In other embodiments, any other suitable configuration can 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 2} C bus and the SPI bus described in the present invention are also only examples, not limitations. In other embodiments, the technology disclosed in the present invention can be implemented with any other suitable type of bus or be modified as necessary.

As mentioned above, the security device can be used 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 protect the boot process security. 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 set to be valid (for example, at a high logic level), the security device can check whether any data line or clock line has changed or toggle its own logic state. In some systems, when the flash memory device is not selected during the boot 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 slave devices on the bus, or even if there are other SPI slave devices, they will not be addressed during the boot time. Therefore, when the CS# line has not been set to be valid (that is, at a low level) but the signal on the data line or the clock line has changed, it indicates that an attack has occurred. The safety device can use this indication to trigger a suitable response measure.

Another integrity check that the security device can perform may be a timing integrity check. In one embodiment, during the boot process, the security device can verify whether the time delay from a predetermined reset signal or power-on signal to a predetermined event is within a predefined range. For example, the security device can measure the time delay between the system reset and the appearance of the first access command on the SPI bus. If the time delay is not within the pre-defined range, for example, the time delay is longer or shorter than the normal value, the security device can assume that the bus has been tampered with and trigger a suitable response measure. In another embodiment, after the host is released from reset, the security device can check the image or digest obtained by the host in a certain period of time, assuming that the host should end the boot sequence within this time.

In addition, the safety device can measure the analog electrical parameter value of at least one line of the SPI bus. If the analog electrical parameter value falls outside the predefined range, the safety device triggers a suitable response measure. The analog value that can be used for the above purposes can include, for example, the capacitance value of one or more lines of the SPI bus Capacitance value, transmission time or LRC delay. In some embodiments, such specific electrical parameters can be measured when the corresponding line is not driven by a host on the bus or any other device, for example, when the host is not powered on or remains in a reset state. Such technology has been solved in US Patent 7,797,115, the disclosure of which is incorporated herein by reference. In addition, any other suitable detection technology can be used to measure the value of the analog electrical parameters of the bus signal. In an exemplary embodiment, the predetermined range of the predetermined analog electrical parameters, for example, the range of the normal capacitance value of the predetermined circuit of the SPI bus can be determined and stored in the non-volatile memory during system manufacturing. During startup, the safety device measures the current value of the target parameter and confirms whether the measured value is within the allowable predefined range.

In order to improve security, the route and physical layout of the SPI signal between the host device, the security device, and the NVM device can follow specific guidelines. For example, when the system of the present invention is implemented 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 are packaged in a ball matrix (BGA) type.

Transfer in the inner layer of the printed circuit board, for example, in a layer that cannot be directly contacted or approached from the outside.

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

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

In order to improve security, the startup code can be set to output some data on the SPI bus, and the security device can confirm 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 peek into the bus to confirm these values. In some embodiments, the host parameter values can be processed as part of the code image/summary, while in other embodiments, the host parameter values have reference data or individual copies of the digest.

In some embodiments, the security device responds to the host instead of the NVM device and responds to the host with a copy of the boot code instead of the NVM device to ensure the security of the boot process. In one embodiment, the activation code responded by the security device is variable, which causes the activity of the host 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 for each boot procedure entity, but at least cause different host activities under the selected entity. By monitoring the activity of the host device on the bus, the security device can confirm that the boot code executed by the host during the boot process matches the boot code provided by the security device to the host device.

In the above embodiment, the security device can provide any suitable code, which can cause changes in the host's detectable activity on the bus. For example, without affecting the execution process, the security device can manipulate the startup code image by changing at least one code value. For example, this code value can be a fixed value for a dedicated code. Therefore, under this operation, according to this code value, the startup code executed by the host will output a value on the bus; therefore, it is different from the startup procedure in the known way of the safety device. The security device reads the above-mentioned value from the bus and confirms that this value matches the activation code currently provided to the host. The output value can include, for example, the code self-checking summary, the value itself, or any of its functions. In addition, the output value can be determined by the shared secret known by the host and the security device.

In other embodiments, the startup code may cause differences in other aspects of the activity of the host on the bus, which is not necessarily related to the output value. For example, the startup code can cause the host to experience different delays between different entities in the startup process. This delay difference can be achieved by, for example, the security device inserting different numbers of NOP commands into the startup codes of different boot process 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 judged by the actual number of NOP commands inserted in the current boot process. In addition, the security device can confirm that all inserted NOP commands have been read; or, the security device can measure the summary of the startup code on the bus and compare this summary with its own copy summary. Anything else that can cause a difference in host activity can be used, as long as the security device can detect this difference.

The different devices of the security system 20, 70, 110, 130, 140, 170, 189 can be implemented by any suitable hardware, such as a special application integrated circuit (ASIC) or a field programmable logic gate array (FPGA). In some embodiments, some devices of the security device of the present invention, for example, the processor 44 or 94 can be implemented by software, or a combination of hardware and software modules. The memory 48 and 98, and the memory storing the copy of the startup code shown in Figs. 8-10, can be implemented by any suitable type of memory device, such as random access memory (RAM) or flash memory.

In some embodiments, the processors 44, 94, 164, and/or 182 may include a general-purpose programmable processor, which is programmed by software to perform the functions of the present invention. This software can be downloaded to the processor in the form of electronic signals via the Internet, for example, or can be provided and/or stored in non-transitory tangible media (such as magnetic, optical, or electrical memory).

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

The method and system 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 by them.

Although the present invention is disclosed in the foregoing embodiments as above, it is not intended to limit the present invention. Anyone familiar with similar art can make some changes and modifications without departing from the spirit and scope of the present invention. Therefore, the present invention The scope of patent protection shall be subject to the definition of the scope of patent application attached to this specification.

28: Peripheral devices

32: I ² C bus

36: safety device

40: Interface

44: processor

48: memory

Claims (32)

A security device includes: an interface for connecting a bus that serves a host device and a non-volatile memory (NVM) device; and a processor connected to the bus, the host device, and the NVM device Also connected to the bus, the processor is used to: detect a boot process on the bus, in which the host device obtains a boot code from the non-volatile memory device; and according to the host device A copy of at least a part of the activation code to ensure the safety of the boot process, wherein the activation code instructs the host device to output one or more host parameter values on the bus, and the processor is monitored and confirmed by Output the host parameter value on the bus to determine the safety of the boot process. The security device according to claim 1, wherein the processor is used to retrieve at least a part of the activation code from the bus, and when the activation code obtained from the non-volatile memory device is detected When there is a discrepancy between the at least one part and the copy, a response measure is initiated. The security device according to claim 2, wherein the copy includes an image of the at least a part of the activation code, and the processor compares the image with the activation code obtained from the non-volatile memory device At least part of it to detect the non-conformity. The security device according to claim 2, wherein the copy includes an authentic digest of the at least part of the activation code, and the processor calculates the activation code obtained from the non-volatile memory device At least a part of a summary, and compare the at least a part of the summary of the activation code obtained from the non-volatile memory device with the real summary to detect the non-conformity. The security device according to claim 2, wherein the processor detects the non-compliance when the booting process is in progress. The security device according to claim 5, wherein when the non-conformity is detected in response, the processor is used to impose one or more dummy values on at least one line of the bus to disturb the boot process. The security device according to claim 5, wherein when the non-conformity is detected in response, 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-conformity, the processor replaces the non-volatile memory device on the bus to respond to the host device, so as to use the copy to complete the boot process. The security device according to claim 2, wherein the processor detects the non-conformity independently of the execution of the boot process. The security device according to claim 1, wherein the processor saves the copy in an internal memory of the security device, or saves the copy in a memory external to the security device. The security device according to claim 1, wherein the processor prevents the host device from accessing a predetermined confidential information before the security of the boot process is determined. The security device according to claim 1, wherein the processor performs the following operations to determine the safety of the boot process: responding to the host device in place of the non-volatile memory device, and providing a boot code to the host device, wherein the The activation code causes the activity of the host device on the bus to be different between the first entity (instance) and the second entity of the boot process; and Monitor the activity of the host device on the bus, and confirm that the activity matches the activation code provided to the host device. The security device according to claim 1, wherein when one of the chip select (CS) lines of the bus is not set to assert, the processor ensures that all data lines and clock lines of the bus The logic state does not change to ensure the safety of the boot procedure. The security device according to claim 1, wherein the processor ensures that only bus commands appearing on a predefined white list are applied to the non-volatile memory device to ensure the security of the boot process. The security device of claim 1, wherein the processor ensures that a time delay from a predetermined reset signal or a power-on signal to a predetermined event in the boot process is within a predefined range to Make sure that the boot procedure is safe. The safety device according to claim 1, wherein the processor ensures the safety of the boot process by ensuring that an analog parameter value of at least one circuit of the bus falls within a predefined range. A security method includes: 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 the data on the bus A boot procedure in which the host device obtains a boot code from the non-volatile memory device, and determines the security of the boot procedure according to at least one copy of the boot code of the host device, wherein the boot The code instructs the host device to output one or more host parameter values on the bus, and the processor determines the safety of the boot process by monitoring and confirming the host parameter values output on the bus. The security method according to claim 18, wherein the security of the boot procedure is determined The steps include: retrieving at least a part of the activation code from the bus, and initiating a response when it is detected that the at least part of the activation code obtained from the non-volatile memory device does not match the copy measure. The security method according to claim 19, wherein the copy includes an image of the at least part of the activation code, and the step of detecting non-conformance includes comparing the at least part of the activation code obtained from the non-volatile memory device With that image. The security method according to claim 19, wherein the copy includes a true summary of the at least a part of the activation code, and the step of detecting non-conformance includes calculating the activation code obtained from the non-volatile memory device At least a part of a summary, and comparing the at least part of the summary of the activation code obtained from the non-volatile memory device with the summary of the real summary. The security method according to claim 19, wherein the step of detecting non-conformance is performed simultaneously when the booting process is performed. The security method according to claim 22, wherein the step of determining the safety of the boot process includes responding to the detection of non-compliance, by imposing one or more dummy values on at least one line of the bus to disturb the boot program. The security method according to claim 22, wherein the step of determining the security of the boot process includes responding to detecting the non-conformity by disrupting one of the bus between the host device and the non-volatile memory device Or multiple lines to disrupt the boot process. The security method according to claim 22, wherein the step of determining the security of the boot process includes: responding to the detection of the non-compliance, replacing the non-volatile memory device on the bus to respond to the host device, and using the Copy to complete the boot process. The security method according to claim 19, wherein the execution of the step of detecting the non-conformity is independent of the execution of the booting process. The security method according to claim 18, further comprising: storing the copy in an internal memory of the security device, or storing the copy in a memory external to the security device. The security method described in claim 18 further includes: preventing the host device from accessing a predetermined confidential information before determining the security of the boot process. The security method according to claim 18, wherein the step of determining the safety of the boot process includes: responding to the host device instead of the non-volatile memory device to provide a startup code to the host device to cause the host device to flow in the bus The activity of the row is different between a first entity and a second entity of the boot process; and monitoring the activity of the host device on the bus, and confirming whether the activity matches the one provided to the host device Start the code. The security method according to claim 18, wherein the step of determining the safety of the boot process further includes: when one of the chip select (CS) lines of the bus is not set to be valid (assert), by ensuring that all of the bus The logic state of the data line and the clock line does not change to ensure the safety of the boot procedure. The security method according to claim 18, wherein the step of determining the security of the boot process further comprises: ensuring that only bus commands appearing on a pre-defined white list are applied to the non-volatile memory device to determine the The safety of the boot process. The security method according to claim 18, wherein the security of the boot procedure is determined The steps further include: ensuring the safety of the booting process by ensuring that a time delay from a predetermined reset signal or booting signal to a predetermined event in the booting process falls within a predefined range. The security method according to claim 18, wherein the step of determining the safety 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的安全。 The safety.

Images