TWI791244B - 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 starting monitoring system

The present invention relates to electronic system security, in particular to a method and system for self-service security (secure bootstrapping).

The electronic device system uses various types of bus interfaces for communication between the host device and peripheral devices. One example of a bus interface is the Serial Peripheral Interface Bus (SPI bus). Peripheral devices that can support the SPI bus include, for example, serial flash memory devices.

An embodiment of the invention provides a security device, which includes an interface and a processor. This interface is used to connect a bus serving 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 process on the bus. The device obtains an activation code and secures the boot process based on a host device's copy of at least a portion of the activation code.

In some embodiments, the processor is configured to retrieve at least a portion of the boot code from the bus, and when detecting a discrepancy between the at least a portion of the boot code retrieved from the NVM device and the copy In case of non-compliance, initiate a countermeasure.

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 an authentic digest of the at least a portion of the boot code obtained from the NVM device and compares The digest and the true digest of the at least a portion of the boot code obtained from the NVM device to detect the mismatch.

In some embodiments, the processor detects the violation during the boot process. In an exemplary embodiment, in response to detecting the violation, the processor is operable 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 violation, 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 mismatch, the processor responds to the host device on the bus instead of the NVM device to use the replica to complete the boot process. In other embodiments, the processor detects the non-compliance independently of the boot process.

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

In one embodiment, the processor performs the following operations to determine the security of the boot process: responding to the host device on behalf of the NVM device, and providing a boot code to the host device, wherein the boot code causes the host device to run on the host device activity on the bus at the first implementation of the boot sequence different between an instance and a second entity; and monitoring the activity of the host device on the bus, and confirming that the activity matches 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 this by ensuring that the logic states of all data lines and clock lines of the bus do not change , to ensure the safety of the boot process. In another embodiment, the processor secures the boot process by ensuring that only bus commands appearing on a predefined white list are applied to the NVM device.

In an exemplary embodiment, the processor determines the start-up sequence by ensuring that a time delay from a given reset signal or a start-up signal to a given event during the start-up sequence is within a predefined range. Safety. In addition, the processor determines the safety of the boot process by ensuring that an analog parameter value of at least one line of the bus falls within a predefined range. In one embodiment, the boot 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 the boot process is safe.

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

In another embodiment, the invention provides a security device, which includes an interface and a processor. The interface is used to connect a bus serving 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 by the peripheral devices through the bus. The processor is connected to the bus as an additional device. Peripherals connected to the busbar. The processor can disrupt the operation of a bus master attempting to access a given peripheral device on the bus by disrupting dedicated signals associated with the given peripheral device.

In some embodiments, the processor keeps the shared signals on the bus uninterrupted while performing the scrambling operation. In one embodiment, the interface includes an input for receiving dedicated signals from the bus master, and an output for sending dedicated signals to a given peripheral device, and the processor can transmit the dedicated signals by preventing the input from receiving them. to the output to disrupt the above operation. In some embodiments, the processor responds to the bus master instead of the intended peripheral, 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 need 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 that need to be disrupted. The auxiliary interface is located outside the bus.

In one embodiment, the processor indefinitely disturbs dedicated signals until the system is reset. In another embodiment, the processor disrupts the dedicated signal for a limited time period after detecting the above-mentioned operation. In one embodiment, the processor causes operations at one or more peripheral devices to be discarded by disrupting operations. In some embodiments, after the disturb operation, the processor resumes 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 serving one or more peripheral devices. The processor and peripheral devices are connected to the bus, and the processor disrupts the operation of a bus master on the bus trying to access a given peripheral device by responding to the bus master instead of the given peripheral device.

In one embodiment, the bus includes one or more dedicated signals, each dedicated to a peripheral device; and one or more shared signals, which are shared among the peripheral devices served by the bus, and the The dedicated signal related to the peripheral device, and 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 operation, and responds to the request with another data stored inside the secure device. In an exemplary embodiment, the processor responds with another data to the bus master's request to the memory device to access a predefined address area, thereby disrupting the operation.

In another embodiment, the processor identifies an operation in which the bus master attempts to access a given peripheral device based on data sent back from the given peripheral device to the bus master during operation. In yet another embodiment, based on the command code used in the operation, the processor identifies an operation in which the bus master device 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; wherein the bus One or more dedicated signals are included, each dedicated to a peripheral device; and one or more shared signals, shared among peripheral devices served by the bus. A security device is used to disrupt an attempt by a bus master to access a given peripheral on the bus by disrupting 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 The operation of the bus master attempting to access a given peripheral device on the bus is disrupted by responding to the bus master instead of the given peripheral device.

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 a bus master to access a peripheral device on the bus by imposing one or more dummy values on at least one line on the bus in parallel with 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 from peripheral devices on the data line. Additionally, the processor can Imposes dummy values on the clock lines of the bus to disturb the clock signal used for this operation. In addition, the processor can impose dummy values on the chip select lines of the bus, thereby disrupting the selection of peripheral devices by the bus master.

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 to 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 device has written on at least one line. In an exemplary embodiment, the processor can overwrite the value written by the bus master or peripheral device by driving at least one line with a high drive strength to the bus master device or peripheral device. In other embodiments, the device includes at least one resistor inserted on at least one line to attenuate the value written by the bus master or peripheral device from a value written by the processor to a dummy value written by the processor. value.

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

In one embodiment, the processor imposes dummy values indefinitely until the device is reset. In another embodiment, the processor imposes a dummy value for a finite period of time after detecting such an operation. In one embodiment, the processor may resume normal operation of the bus after the disturb operation.

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 may disrupt an unauthorized attempt by a bus master to access a peripheral device on the bus by imposing one or more dummy values on at least one line in parallel with at least a portion of the operation.

According to an embodiment of the present invention, a security method is further provided, which includes the following steps: using a security device coupled to a bus to determine to disturb the operation of a bus master device trying to access a peripheral device without authorization. Disrupting the operation by imposing one or more dummy values on at least one of the buses in parallel with at least a portion of the operation.

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 device

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

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

FIG. 2 is a flowchart 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 according to other embodiments of the present invention, wherein in the security system multiple devices communicate through an SPI bus.

FIG. 6 is a block diagram of a safety 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.

8-10 are block diagrams of a security system showing a security device on an SPI bus enabling 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 of a method for safely booting a host device according to an embodiment of the present invention.

The implementation 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 uses technical means to solve technical problems and achieve technical effects.

overview

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

In some embodiments, the security device monitors transactions on the bus and identifies unauthorized access by peripheral devices by the host device or other bus master 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 values on one or more lines or signals of the bus while parallel to the operation . The aforementioned dummy values can be imposed on, for example, a clock signal, a data signal and/or a chip select (CS) signal.

Disrupting the operation by imposing dummy values on the bus is suitable, for example, for an open-drain bus or an open-collector bus, such as an I ² C bus, And a push-pull bus, such as an SPI bus. Imposing dummy values on the bus in parallel to unauthorized operations can override communications with the peripheral and disrupt clock signals.

Several example techniques for disrupting unauthorized operation on the ^I2C and SPI buses are described below, as well as techniques for restoring normal operation after the disturbance. In some embodiments, the security device may perform the tampering 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 signals. Signals are shared among multiple peripheral devices via 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 the protected peripheral while maintaining shared signals on the bus. It should be noted, however, that not all buses have dedicated signals. For example, on the I ² C bus, all signals are shared signals.

In other embodiments, the security device disrupts the operation by responding to the unauthorized host instead of the protected peripheral device. In an exemplary embodiment, the peripheral device includes a flash memory including one or more address areas for storing sensitive data such as keys, configuration data, and/or boot code. By selectively overriding the CS signal of the flash memory, the security device can override operations to access 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 in the present invention 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 technique disclosed in the present invention does not require additional pins or interconnection lines, thereby reducing overall system size and cost.

In other embodiments, the security device secures a 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 boot from an SPI flash memory device on an SPI bus. In some embodiments, the safety device monitors the bus during the boot sequence and compares the At least a portion of the boot code and a known copy, such as a boot code image or a digest. A countermeasure is triggered when a discrepancy between the boot code obtained on the bus and the copy known to the security device is detected. The technology of the present invention can activate the security device to protect the system against various security threats, such as stolen host or flash memory device, or attacks on bus signals. Several exemplary embodiments and variants of the secure boot procedure 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 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 simplify the description, the host device 24 and the 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.

Security device 36 protects access to peripheral device 28 by monitoring operations on the ^I2C bus and prevents unauthorized access attempts by host 24 or another bus master capable device Unauthorized operation of perimeter 28. The security device 36 is also 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 the I ² C bus 32 , the processor 44 implements the techniques disclosed in the present invention, and the memory 48 stores one or more security policies implemented by the processor 44 .

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

For example, the host may be required to have the security device authenticate its identity before the host is authorized to access the peripheral device. Operations attempted by unauthorized hosts are considered unauthorized. For example, Some challenge-response process can be used between the host and the security device to perform authentication. In addition, the host may be required to prove its identity 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, while the operation of accessing other addresses may be regarded as unauthorized. In another example, a sequence of bits on the bus may represent an unauthorized operation.

In general, processor 44 may distinguish between authorized operations 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 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 herein. By monitoring the SDA line as well as the SCL line, 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 line and/or the SCL line 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 pulled up to a logic “1” state (that is, a high voltage level) by default using a pull-up resistor. Any device can write a "0" value on either the SDA line or the SCL line at any time to impose a logic "0" (ie, low voltage level), regardless of what other device is writing at the same time.

Therefore, in some embodiments, when an unauthorized operation is identified, the processor 44 of the security device 36 will use the interface 40 to impose a logic "0" on the SDA line or the SCL line of the bus 32 (default "0"). 1” logical value opposite value). Here, the "0" value is regarded as a dummy value. A "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 from the peripheral device 28 by the host device 24. Any data value read by edge device 28, or a preset "1" value. A "0" value imposed on the SCL line stops the clock signal. In either case, operation may 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, the processor 44 can restore the host reset 24 and the peripheral reset 28 from the disrupted state to normal operation. Some host resets and/or peripherals do not resume normal operation from clock suspension. Therefore, if the host resets and the peripherals need to return to normal operation, it would be preferable to impose a dummy value on SDA instead of the SCL line.

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

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

In another embodiment, the processor 44 may impose a "0" value on the SDA line until it detects that the SCL line has been high (eg, not disturbed) for at least a predefined time period. This condition can indicate that the host has finished or aborted the operation. Next, processor 44 may deassert the SDA line and may generate an ^I2C stop condition.

In yet another embodiment, the security device 36 may act as an I ² C slave device with the same device address as the peripheral 28 in order to effectively disrupt unauthorized access to data from the peripheral device. Processor 44 of security device 36 may respond to this unauthorized read request with a "0" data value. While the processor 44 is running, the peripheral device 28 will also respond to the read request, but the data value sent by it will be overwritten by the “0” value sent by the security device 36 . This program will continue until the host terminates the operation due to a STOP condition. It should be noted that according to the I ² C specification, the I ² C slave does not drive the ACK/NEGACK bits when transferring data.

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

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

In the above example, detecting unauthorized operations, disrupting unauthorized operations, and restoring normal operation after the disturbances are all accomplished using only the existing lines of the bus. In other embodiments, the security device 36 and the host 24 may 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 pin and the SCL pin of the IC.

In these embodiments, the security device 36 and the host device 24 can use the auxiliary interface to verify that no other host device is accessing the 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, processor 44 does not impose a false "0" value on the bus and lets the operation proceed. When an operation is detected while accessing the peripheral 28 but not notified on the auxiliary interface, the processor 44 assumes that the operation was performed by an unauthorized host, and will impose a "0" value to disrupt the unauthorized host. authorized operation.

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, at monitoring step 50 , processor 44 of security device 36 monitors operations on I ² C bus 32 using interface 40 .

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

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

Secure Access to Peripherals on the SPI Bus

FIG. 3 is a block diagram of a security system 70 according to yet another embodiment of the present invention. In FIG. 3 , 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, security device 86 includes an interface 90 to connect to 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 processor 94. policy.

In this embodiment, the security policy used to distinguish between authorized and unauthorized operations, and the manner in which processor 94 of security device 86 identifies unauthorized operations, is similar to the policies and methods described above for security system 20. . The following technique differs from the above-described manner in which the security device 86 imposes a dummy value on the bus 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 watchdogs 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, host device 74 uses CS line CS2# to select peripheral device 78 and CS line CS1 # to select secure device 86 .

The host device 74 as a master is connected to all CS lines. On the other hand, the peripheral devices are all slave devices, and each peripheral device is only connected to its own CS line. Typically, the host device 74 uses the CS line to select the desired peripheral device and then communicates with the device 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.

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 multiple peripheral devices 78 with their own CS lines, the security device 86 can generally drive any of the CS lines in parallel to the host device 74 .

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

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 overlay mechanism described above can be implemented in a number of ways. The above description is for the CS line CS2# to select the peripheral device 78, but the same mechanism can also be applied to a plurality of peripheral devices and respective CS lines.

In one embodiment, the line driver used by the secure 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 may be inserted on the output CS line CS2# of the host device 74 . Relative to the output of the CS2# line driver of the safety device 86, the resistor 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 override the driving of the CS line CS2# by the host device 74 .

Processor 94 of security device 86 may monitor the CS, CLK, MISO, and/or MOSI lines of 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 device, the processor 94 of the security device 86 de-asserts the CS line of the peripheral device to disrupt the operation. . Since the watchdog 86 overrides the drive of the CS line CS2# by the host device 74, the peripheral device will be reselected, thereby disrupting the operation. On the other hand, when judging that the operation is authorized, the processor 94 will stop its own 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 security system 110 is implemented based on the SPI bus 82, similar to the system 70 of FIG. 3 . 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 overriding mechanism described above may be implemented by having the line drivers of the CLK line, MISO line, and/or MOSI line of the watchdog 86 stronger than the corresponding line drivers of the host device 74 .

In other embodiments, a hybrid scheme combining overlaying CS lines (as shown in FIG. 3 ) and overlaying CLK, MISO 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 (such as an SPI bus) can be divided into shared signals and dedicated signals. The shared signal is a signal of a plurality of peripheral devices (eg, 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. Dedicated signals are signals dedicated to specific peripheral devices. For example, the dedicated signal for this bus is a chip select (CS) signal. In addition, this bus can be expanded to have 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 routed to peripheral devices without passing through the security device. The 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 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 . Instead, the CS line CS2# of the host device 74 is input to the watchdog 86 , which then 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 the security device to the protected peripheral 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 or preventing the CS2# signal from reaching the peripheral device. In the example shown in FIG. 5, the above selection can be performed by setting the control signal MASK_CS2# to be asserted or deasserted.

FIG. 6 is a block diagram of the security device 86 of the system 130 of 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; 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 circuit (IML) 92 . The slave interface logic circuit 91 is used to handle the communication between the security device 86 and the host device 74 . IML 92 is used to monitor, control, and selectively override host device 74 access to peripheral device 78 .

In one embodiment, security device 86 identifies and disrupts unauthorized host device 74 attempting to access peripheral device 78 over SPI bus 82 . It can be understood from FIGS. 5 and 6 that any of the security features of the system shown in FIG. 3 can also be implemented in the system of FIG. 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 security device can be connected as a master device. For example, this embodiment can be applied to a bus protocol that supports multi-master capability.

Response by security device instead of peripheral device to prevent unauthorized operation

In another embodiment, the security device 86 may respond to selected host operations in place of the peripheral device 78 . The following description mainly refers to the configurations shown in FIG. 5 and FIG. 6 for an example description. 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 FIG. 5 and FIG. 6, when it is detected that a read command is directed to a certain address area in the address space of the peripheral device 78, the IML 92 can impose a signal CS2_O# High-level signal, and use the internal memory 98 of the security device to serve (response) 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 can also be applied to the security system 110 of FIG. 4 , for example, the security device can override the MISO signal.

An example of the use of this mechanism is a system where peripheral device 78 includes an SPI flash memory device, and security device 86 covers a portion of the flash memory address space, thereby providing secure flash memory emulation for this address region . For example, security device 86 may include a Trusted Platform Module (TPM) that uses IML 92 to overwrite a flash address area containing initial host boot code. The initial host startup code is a startup command extracted when the host is turned on. The trusted platform module can overwrite the flash memory address area where the verified initial boot code is separately stored, 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. Additionally, the security device 86 may include a suitable interface and circuitry to keep the host device 74 in reset while accessing the SPI flash memory device, usually as part of the system boot process. For example, the security device 86 can be an embedded controller (EC), a super I/O device (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 begins with power-up, ie, 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 (peripheral device 78 ). In the initial load 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 configures the IML 92 to override access to at least one predefined address area in the SPI flash memory (which is the peripheral device 78 in this example). The protected address area may store, for example, one or more keys, configuration data, and/or initial boot data segments for the host device 74 .

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

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

FIG. 7 illustrates an example method of how a secure device overrides access to a predefined address area of a peripheral device. In other embodiments, any other suitable method may be used for this application. Additionally, the security device may use any other suitable means to protect the flash memory device (or other peripheral devices) by overriding and/or disrupting unauthorized operations when impersonating the SPI flash memory device.

Furthermore, the coverage against unauthorized operations is not limited to protecting specific pre-defined address areas. For example, whether to trigger the overlay operation can be determined according to the data returned by the protection peripheral device or the SPI instruction code. For example, a security device may implement a security policy to disable programming, erasing, enabling writes, 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 Corporation on August 24, 2015 has set forth the example specifications of SPI flash memory instructions and control.

Another example, in the method shown in FIG. 7, the sensitive information is located in the flash memory device, activated and read by the secure 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 stores the security device instead of the 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 the bus's dedicated signals (if any) and/or shared signals to override accesses to the peripheral device's predefined address areas via other buses and protocols. For example, the I ² C bus is a pull-up bidirectional bus for supporting slave devices as well as master devices. Therefore, the protocol has a built-in mechanism for handling contention among multiple devices. For example, when an I ² C device detects that the SDA line is "0" while attempting to set it to "1" (that is, a pull-up operation), the device assumes contention and releases the bus until the next operate. In one embodiment, an ^I2C secure device (eg, secure device 36 of FIG. 1 ) is used to overlap some of the address space of another peripheral slave device (eg, peripheral device 28 of FIG. 1 ). For example, a security device can be used to reply with the same data that another peripheral device expects. If the safety device detects that there is a data mismatch, for example, a device tries to pull up to "1" but the SDA line detects "0", the safety device can start to respond, for example, generate a stop condition, in the Driving "0" on one or more data lines, setting an infinite clock stretch, or any other suitable action. This technique uses a conventional ^I2C slave device (no hardware changes required at the physical layer) to monitor the device pulling down the data level.

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 can initiate a response, such as interrupting the operation, resetting the system, locking access to the key, or any other suitable measures.

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

In yet another embodiment, the security device may monitor at least one peripheral device 78 on the bus 82 and verify that the access sequence of the various devices is as expected.

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

˙Cooperate with any signal attested by the security system in Figure 4.

˙Flash memory anti-write (write-protect) signal

˙Control reset signal.

˙Control the power management signal.

˙Control the power to one or more devices.

˙Disable system communication; for example, system communication can be disabled by disabling a network interface controller (NIC).

˙Reset the system.

Safeguard monitors SPI bus to allow host to boot safely from flash memory

In one of the above-mentioned embodiments, in order to protect the security of the boot process, the security device replaces the flash memory to respond 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 (eg, SPI bus). The security device can protect the security of the boot process by monitoring the memory access operation of the host on the bus. The secure device holds or has access to a copy of at least some of the host activation code and/or digest thereof. The security device can compare the copy with the host's activation code from flash memory (computing its digest if necessary), and initiate countermeasures when a discrepancy is detected.

The technique disclosed in the present invention enables security devices to prevent various security threats, for example, security threats of a stolen host or flash memory device, or security threats on upper bus signals. The following description is based on the example of SPI bus and SPI flash memory. The techniques disclosed in the present invention can be applied in a similar manner to any other suitable bus 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 manifest of one or more boot code instructions. The order of instructions in the image can be the explicit order of the boot code, the execution order of the boot code (not necessarily executed sequentially), or any other order. In other embodiments, this copy may contain an actual digest of at least a portion of the activation code. The summary may include functions resulting from the operation of any or all of the startup code. In a In example embodiments, the digest (also referred to as a signature) may include a hash value or a signed hash value. In the present invention, the above-mentioned digest may refer to a secure hash algorithm (such as 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 digest is known with a high degree of confidence that it is uncorrupted and therefore trustworthy. For clarity of description, this actual image or abstract 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, in non-volatile memory of one of the secure devices. 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 signed with the appropriate security key, which is stored in the secure device.

As an example, the configuration described below refers to an SPI bus with a clock signal CLK, a chip select signal CS#, and four data lines D0-D3. Other bus bar types may have different numbers and types of wires. For example, a single data line SPI may have fewer wires. The techniques disclosed in this invention 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 is to protect the security of the host device 144 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 in the present invention. Processor 164 may save or access a copy 168 (eg, an image or digest) of at least a portion of the boot code of host 144 . In this example, the chip select line (CS#) used to select the flash memory device 148 also provides an input to the security device 156 .

FIG. 9 is a block diagram illustrating a security system 170 according to an embodiment of the present invention. The security device 174 of the security system 170 is to protect the boot process that the host device 144 reads from the flash memory 148 on the SPI bus 152. safety. The security device 174 includes an interface 178 for connecting to the SPI bus 152, and a processor 182 for executing the method disclosed in the present invention. Processor 182 can save or access the main A copy 186 (eg, an image or a digest) of at least a portion of the startup code of the machine 144. In this embodiment, all 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 .

FIG. 10 is a block diagram illustrating a security system 189 according to an embodiment of the present invention. The security device 187 of the security system 189 is to protect the security of 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 may implement the techniques disclosed herein as hardware and/or software modules. The secure device further includes a memory (not shown) that stores a copy of at least a portion of host 144's boot code.

Compared to the examples of 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 signals 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 used to select the flash memory device 148 all pass through the safety device 187, so these signal branches are not easy to disconnect , the SPI bus can be monitored without disconnecting the connection between the host computer and the flash memory device. The data and clock lines are not interrupted, but the SPI bus monitor 188 can modify the CS# line. For example, if the boot code fetched on the bus does not match this copy, the SPI bus monitor 188 may reset the CS# line, eg, set it high), thereby disrupting the boot sequence.

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 security devices of the present invention, such as security devices 156, 174 and 187 shown in Figures 8, 9 and 10. To simplify the description, the actions described as being performed by the secure device are actually performed by a processor of the secure device (such as processor 164 or 182 ), or by the SPI bus monitor 188 .

The method begins with a security device holding the host 144 in a reset state at reset hold step 190 . In a get copy step 194, the security device gets a copy, such as an image or a digest, of at least a portion of the host's boot code while the host is in reset. If the copy is from a If the 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 some other stage before the system is provided to an end user. In this embodiment, steps 190 and 194 can be omitted.

In the power-on step 198, the safety device releases the host 144 from the reset state, and the host starts up. 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 boot code obtained.

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 this retrieved code with the copy .

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

In one embodiment, when the copy contains an image of a portion of the boot code, the secure device typically compares the original data value fetched on the bus with the corresponding data value of the copy. When the copy contains a digest of a portion of the boot code, the secure device typically computes a digest of the code fetched on the bus, then compares the computed digest with the copy.

In a compliance check step 206, the security device checks whether the boot code that the host is getting from the flash memory device (intercepted by the security device monitoring the SPI bus) matches the copy. If yes, then upon successful completion of step 210, the security device allows the boot procedure to complete successfully. If not, for example, in the start countermeasure step 214, if it is detected that the two do not match, the security device assumes that the boot procedure has been stolen, and initiates an appropriate countermeasure.

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

In some cases, when calculating the 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 abstract may legally correspond to at least two different copies. Thus, in some embodiments, the secure device may maintain multiple different copies of the digest. The watchdog compares the digest computed from the code intercepted from the bus to the plurality of copies. If the calculated digest matches any of the replicas, the security device may allow the boot process to complete. If the calculated digest does not comply with any of the replicas, the security device triggers countermeasures.

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

˙Trigger system to reset.

˙ Disturb 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.

Disrupt the boot process by disturbing 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.

˙Overlay the signal on one or more lines of the SPI bus between the host device and the NVM device, for example, impose a signal on the bus that conflicts with the original signal.

Replacing the flash device responds to the host device on the SPI bus and uses the copy to complete the boot process.

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

˙Record warning or error logging events in internal memory (eg, RAM or OTP), or issue an alarm signal.

Any other suitable response or combination thereof

In some embodiments, for example, while the boot process is still in progress, the security device can detect on-the-fly a discrepancy between the retrieved boot code and the copy, so the countermeasures for disrupting the boot process are 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 safety device independently detects whether there is a non-compliance situation independently of the boot process, so the non-compliance detection is not in the critical path of the boot process, and the impact on the boot delay Little or no effect. Off-line non-conformance detection can be performed after the boot process is complete, 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 temporary memory for offline comparison of copies. For non-compliance detection to be performed offline, the security device does not need to hold the host device in reset or stall the host device.

In some embodiments, the security device may maintain or access a configurable "white list" of SPI commands that are allowed during boot. While monitoring the bus, the security device can filter SPI commands against this white list, for example, to ensure that only commands on the white list can actually be sent to the flash memory device. This white list can limit the type of command or address to be accessed. For example, read commands to a specified address range may be allowed, while write commands or read commands to locations outside the specified address range may be prohibited.

The arrangement 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 bus bars) are for clarity of description Exemplary configuration diagrams drawn conceptually. 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 bar and the SPI bus bar mentioned in the present invention are only for illustration rather than limitation. In other embodiments, the technology disclosed in the present invention can be implemented with any other suitable type of busbar 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 protect 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 whether any data line or clock line has changed or toggle its logic state. In some systems, the SPI line should not change between logic high and logic low when the flash memory device is not selected during boot time. For example, because there are no other SPI slaves on the bus, or if there are other SPI slaves, they will not be addressed during start-up time. Therefore, when the CS# line has not been asserted (ie, is at a low level) but there is a signal change on the data line or the clock line, it indicates that an attack has occurred. The security device can use this indication to trigger an appropriate response.

Another integrity check that a security device may perform may be a timing integrity check. In one embodiment, during the boot process, the security device may 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 watchdog may measure the time delay between a system reset and the first access command appearing on the SPI bus. If the time delay is not within a predefined range, eg, longer or shorter than normal, the security device may assume that the bus has been tampered with, thereby triggering an appropriate countermeasure. In another embodiment, after the host is released from reset, the security device can check the image or digest obtained by the host within a certain period of time, assuming that the host should end the boot sequence within this time.

In addition, the safety device can measure an analog electrical parameter value of at least one line of the SPI bus, and if the analog electrical parameter value falls outside a predefined range, the safety device triggers a suitable response measure. Analogous values that can be used for the above purposes may include, for example, the capacitance of one or more lines of an SPI bus Capacitance value, propagation time or LRC delay. In some embodiments, such analog electrical parameters may be measured when the corresponding line is not being driven by the host or any other device on the bus, eg, when the host is not powered on or held in reset. 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 technique can be used to measure the analog electrical parameter value of the bus signal. In an exemplary embodiment, a predefined range for a given analog electrical parameter, eg, considering the normal capacitance value of a given line of an SPI bus, may be determined during system manufacture and stored in non-volatile memory. During start-up, the safety device measures the current value of the target parameter and confirms whether the measured value is within the allowed predefined range.

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

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

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

When transmitting SPI signals through vias, it is better to use blind vias, such as using blind vias to connect connections between inner layers, and not allowing contact or access from the outside.

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

To further increase security, the boot code can be set to output some data on the SPI bus, and the security device can confirm this data. For example, the boot code may output some host register values, configuration, status variables, constants, OTP bits, and any other suitable host parameter values, so that the security device can peek at 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 a separate 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 boot code does not necessarily need to cause host activity to be different under each boot program entity, but at least under selected entities. 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 embodiments described above, the security device may provide any suitable code that causes a change in the activity detectable by the host on the bus. For example, the security device can manipulate the boot code image by changing at least one code value without affecting the execution flow. For example, this code value may be a dedicated code fixed value. Thus, in this operation, according to the value of this code, the boot code executed by the host will output a value on the bus; thus, in a manner known to the security device differently than in the case of the boot procedure. The security device reads the above value from the bus and confirms that this value matches the activation code currently provided to the host. The output value can contain, for example, a summary of the code's own checks, the value itself, or any function of it. Additionally, the output value can be determined from a shared secret known by the host and the secure device.

In other embodiments, the startup code may cause the host's activity on the bus to differ in other ways, not necessarily with respect to output values. For example, boot code may cause the host to experience different delays between different entities of the boot process. This difference in latency can be caused by, for example, a security device inserting different numbers of NOP instructions into the startup code of different boot process entities. In this example, the watchdog measures this delay and confirms that the actual delay matches the expected delay. The expected latency can be determined by the actual number of NOP instructions inserted in the current boot process. Additionally, the watchdog can verify that all inserted NOP commands have been read; alternatively, the watchdog can measure the digest of the boot code on the bus and compare this digest with its own copy digest. Anything else that can cause a difference in host activity can be used as long as the security device can detect the difference.

The various devices of the security system 20, 70, 110, 130, 140, 170, 189 may be implemented in any suitable hardware, such as Application Specific Integrated Circuits (ASICs), or Field Programmable Gate Arrays (FPGAs). 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. Memories 48 and 98, and the memories holding copies of the boot 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 an electronic signal over a network, for example, or may be provided and/or stored on a non-transitory tangible medium (such as magnetic, optical, or electrical memory).

In some of the embodiments described above, the security device first detects an unauthorized operation by monitoring the bus, and then disrupts the operation. In other embodiments, the security device may disrupt the above operation without first detecting on the bus or without monitoring the bus. For example, the security device can override a host's chip select (CS) line until or unless the host is authorized. The authorization described above can be performed in any suitable way and does not have to use 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 examples only, and the present invention is not limited thereto.

Although the present invention is disclosed above with the aforementioned embodiments, it is not intended to limit the present invention. Any person familiar with similar skills may 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 what is defined in the scope of patent application attached to this manual.

28: Peripheral devices

32: I ² C bus

36: Safety device

40: interface

44: Processor

48: Memory

Claims (29)

A security device comprising: an interface for connecting a bus serving 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 configured to: detect a boot process on the bus in which the host device obtains a boot code from the non-volatile memory device; and A copy of at least a portion of the boot code that secures the boot process; wherein the processor performs the following operations to secure the boot process: the processor retrieves at least a portion of the boot code from the bus , and upon detecting a discrepancy between the at least a portion of the boot code obtained from the non-volatile memory device and the copy, initiate a response measure; and the processor responds to the detection of the discrepancy, at The bus instead of the non-volatile memory device responds to the host device to use the copy to complete the boot process. The security device of claim 1, wherein the copy includes an image of the at least a portion of the boot code, and the processor compares the image with the boot code obtained from the non-volatile memory device at least in part to detect the nonconformity. The security device as claimed in claim 1, wherein the copy includes a copy of the activation code An authentic digest of the at least a portion, and the processor calculates an authentic digest of the at least a portion of the boot code obtained from the non-volatile memory device and compares the digest to the at least a portion of the boot code obtained from the non-volatile memory device The digest and the true digest of the at least a portion of code are activated to detect the mismatch. The security device as claimed in claim 1, wherein the processor detects the non-compliance when the boot process is performed. The security device of claim 4, 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 4, 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 process. The security device of claim 1, wherein the processor detects the non-compliance independently of the boot process. The security device of claim 1, wherein the processor stores the copy in an internal memory of the security device, or stores the copy in a memory external to the security device. The security device as claimed in 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 as described in claim 1, wherein the processor further performs the following operations to determine the security of the boot process: instead of the non-volatile memory device responding to the host device, and providing a boot code to the host device, wherein the The activation code causes the host device to activity on the bus differs between a first instance and a second instance of the boot process; and monitoring the activity of the host device on the bus and confirming that the activity is consistent with the activity provided to the host The activation code for the device. The security device as claimed in claim 1, wherein when a chip select (CS) line of the bus is not asserted, the processor is by ensuring all data lines and clock lines of the bus The logical state of the system does not change to ensure the safety of the boot process. The security device as claimed in claim 1, wherein the processor ensures the security of the boot process by ensuring that only bus commands appearing on a predefined white list are applied to the non-volatile memory device. The security device as claimed in claim 1, wherein the processor is 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 to Make sure the boot process is safe. The security device as claimed in claim 1, wherein the processor determines the security of the boot process by ensuring that an analog parameter value of at least one line of the bus falls within a predefined range. A security method comprising: using a security device to communicate over a bus to which a host device and a non-volatile memory (NVM) are connected; and using the security device to detect a boot process in which the host device obtains an activation code from the non-volatile memory device and determines the security of the boot process based on a copy of at least a portion of the activation code of the host device; Wherein the step of determining the security of the boot procedure includes: the security device retrieving at least a portion of the boot code from the bus, and when detecting the at least a portion of the boot code obtained from the non-volatile memory device when the copy does not match, a response action is initiated; and when the non-compliance is detected, the security device responds to the host device on the bus instead of the non-volatile memory device and uses the copy to complete the booting program. The security method of claim 15, wherein the copy includes an image of the at least a portion of the boot code, wherein the step of detecting non-compliance includes comparing the at least a portion of the boot code obtained from the non-volatile memory device with that image. The security method of claim 15, wherein the copy includes an actual digest of the at least a portion of the boot code, and the step of detecting a non-compliance includes computing the boot code 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 retrieved from the non-volatile memory device with the real digest. The security method as described in claim 15, wherein the step of detecting the non-compliance is executed simultaneously when the booting procedure is performed. The security method as claimed in claim 18, wherein the step of determining the security of the boot process includes disrupting the boot process by imposing one or more dummy values on at least one line of the bus in response to detection of a non-compliance program. The security method as described in claim 18, wherein the step of determining the security of the boot process includes responding to detection of the non-compliance by disturbing one of the buses between the host device and the non-volatile memory device or multiple lines to disrupt the boot process. The security method as claimed in claim 15, wherein the step of detecting the non-compliance is performed independently of the boot process. The security method described in item 15 of the claim further includes: storing the copy in an internal memory of the security device, or storing the copy in an external memory of the security device. The security method as described in claim 15 further includes: preventing the host device from accessing a predetermined confidential information before determining the security of the boot procedure. The security method as described in claim 15, wherein the step of determining the security of the boot procedure further includes: responding to the host device instead of the non-volatile memory device, so as to provide a boot code to the host device, so that the host device is activated in the host device activity on the bus differs 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 complies with the activity provided to the host device The startup code. The security method as described in claim 15, wherein the step of determining the security of the boot procedure further comprises: when a chip select (CS) line of the bus is not set to be effective (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 process. The security method as described in claim 15, wherein the step of determining the security of the boot program further includes: The boot process is secured by ensuring that only bus commands appearing on a predefined white list are applied to the non-volatile memory device. The security method as described in claim 15, wherein the step of determining the security of the boot procedure further comprises: by ensuring that a time delay from a predetermined reset signal or a boot signal to a predetermined event in the boot procedure falls within a Pre-defined range to determine the security of the boot process. The security method as described in claim 15, wherein the step of determining the security of the boot procedure further comprises: determining the boot procedure by ensuring that an analog parameter value of at least one line of the bus falls within a predefined range safety. The security method of claim 15, wherein the boot 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 The host parameter value is used to determine the security of the boot procedure.

Images