JP7033383B2 - Safety devices, safety methods, safety systems, and safety equipment - Google Patents

Description

The present invention relates to electronic system security, and in particular to methods and systems for protecting transactions between peripheral devices.

Traditionally, electronic systems use different types of bus interfaces for communication between host devices and peripheral devices. Examples of bus interfaces include Inter-Integrated-Circuit (I2C) buses and Serial Peripheral Interface (SPI) buses. The I2C bus is described, for example, in the "I2C Bus Specification and User Manual" UM10204, NXP Semiconductors, Revision 6, April 4, 2014, which is incorporated herein by reference.

This application is a partial continuation (CIP) of US Patent Application 14 / 714,298 filed May 17, 2015, and US Provisional Patent Application 62/028, filed July 24, 2014. Claims 345 profits. The disclosure of these related applications is incorporated herein by reference. This application was filed on even days in connection with a US patent application named "Secure System Boot Monitor", agent reference number 1041-2004. The disclosure of these related applications is incorporated herein by reference.

US provisional patent application 14/714298 U.S. Patent Application 62/028345

An object of the present invention is to provide a method and system for protecting transactions between peripheral devices.

A safety device according to an embodiment of the present invention includes an interface and a processor, the interface is connected to a bus to which a host and a second device are coupled, and at least the second device is a bus in slave mode. The host operates on the bus, at least on behalf of the safety device, as a bus master initiating a transaction on the bus, and the processor operates over the bus for the safety device. The host is requested to start a transaction to access the second device, and at least within the period during which the host accesses the second device via the bus and executes the requested transaction. It is characterized by monitoring one or more signals on a bus and, based on the monitored signals, identifying whether a security breach has occurred during the execution of the requested transaction.

In one embodiment, the processor is configured to operate on the bus in slave mode. In one embodiment, the safety device is further coupled to the host via another bus different from the bus, and the processor requests the host to initiate the transaction via the other bus. It is configured to do.

In one embodiment, the requested transaction is (1) reading data from the second device, (2) writing data to the second device, and (3) first address of the second device. And the transfer of data between the second address. In one embodiment, the requested transaction specifies expected transaction information, and the processor is configured to monitor the actual transaction information corresponding to the requested transaction on the bus. The security breach is identified by detecting that at least a portion of the expected transaction information is different from the actual transaction information. In one embodiment, the processor detects that at least one element selected from a list including an opcode element, an address element and a data element is different between the expected transaction information and the actual transaction information. It is configured to do.

In one embodiment, the processor is configured to identify a security breach by detecting that a predetermined security policy has been breached on the bus during or outside the requested transaction. Has been done. In one embodiment, the requested transaction comprises reading data from the second device, the processor reading data from the second device by the host via the bus on the bus. It is configured to monitor (snoop). In one embodiment, the processor sends the host to the second device by overwriting the logical value of one or more signals on the bus during the execution of the first write operation by the host. It is configured to initiate the first write operation and request that a second write operation different from the first write operation be applied to the second device.

In some embodiments, the processor sends the host to the second device by overwriting the logical value of one or more signals on the bus during the first read operation by the host. Is configured to initiate the first read operation and request that a second read operation different from the first read operation be applied to the second device. In another embodiment, the processor initiates a transaction to access the second device via the bus, disconnects the signal of the bus connecting the host to the second device, and replaces the host. It is configured to request the host to access the second device via the bus. In another embodiment, the processor performs protective actions in response to the identification of the security breach to prevent disclosure or modification of the data appearing on the bus when accessing the second device. It is configured in.

In the safety device according to one embodiment of the present invention, both the safety device and the second device are mounted in a common package and interconnected via the bus in the common package.

A safety method according to an embodiment of the present invention is a safety device in which a host and a second device are connected to a bus to which at least the second device operates on the bus in slave mode, and the host is at least. On behalf of the safety device, operating on the bus as a bus master initiating a transaction on the bus, and the safety device accessing the second device via the bus for the safety device. Requesting the host to initiate a transaction, and at least one on the bus within a period in which the host accesses the second device via the bus and executes the requested transaction. It is characterized by monitoring the above signals and identifying whether or not a security breach has occurred during the execution of the requested transaction based on the monitored signals.

A safety system according to an embodiment of the present invention comprises a host, a safety device, the host being coupled to a bus, configured to operate as a bus master, and triggered by a slave device and the host. A transaction that accesses the slave device coupled to the bus by mediating a bus access operation, and the safety device is connected to the bus and accesses the second device connected to the bus as a slave. One or more signals on the bus, at least within a period of time that the host accesses the second device via the bus as the host performs the requested transaction. Is characterized by identifying whether a security breach has occurred during the execution of the requested transaction based on the monitored signal.

In one embodiment, the safety device is configured to operate on the bus in slave mode. In another embodiment, the safety device is further coupled to the host via another bus different from the bus, and the safety device initiates the transaction to the host via the other bus. Is configured to require.

In some embodiments, the requested transaction specifies expected transaction information, and the safety device monitors the actual transaction information corresponding to the requested transaction on the bus, said. It is configured to identify a security breach by detecting that at least a portion of the expected transaction information is different from the actual transaction information. In another embodiment, the requested transaction comprises reading data from the second device, and the safety device takes data read from the second device by the host via the bus to the bus. Configured to monitor above. In yet another embodiment, the safety device attaches to the host the second device by overwriting the logical value of one or more signals on the bus during the execution of the first write operation by the host. It is configured to initiate the first write operation to and apply a second write operation different from the first write operation to the second device.

In one embodiment, the safety device requires the host to initiate the first read operation to the second device, one on the bus while the host is performing the first read operation. Alternatively, by overriding the logical values of the plurality of signals, a second read operation different from the first read operation is applied to the second device. In another embodiment, the safety device requests the host to initiate a transaction to access the second device via the bus, and signals the bus connecting the host to the second device. Disconnect and access the second device via the bus on behalf of the host. In yet another embodiment, the safety device is configured to perform protective actions in response to the identification of the security breach to prevent disclosure or modification of the data appearing on the bus when accessing the second device. It is composed of.

Further, according to the embodiments described herein, the safety method is a bus access operation triggered by the slave device and the host in a safety system that includes a host acting as a bus master on the bus to which the slave device is connected. Mediation by the host between. The host is required by the safety device connected to the bus to initiate a transaction to access the second device connected to the bus as a slave. One or more signals are monitored on the bus by the safety device, at least during the time the host accesses the second device over the bus when performing the requested transaction. Based on the monitored signal, the safety device determines if a security breach occurred during the execution of the requested transaction.

According to the embodiments described herein, safety equipment including safety devices and dedicated device drivers running on the host are further provided. The safety device provides security services to the host. The safety device, the host, and the non-volatile memory (NVM) device outside the safety device are coupled to a common bus. The dedicated device driver is configured to mediate between the safety device and the NVM device. The safety device receives the security command from the application program running on the host and issues the security command by accessing the NVM device via the bus transparently to the application program via a dedicated device driver. It is configured to run.

FIG. 1 is a block diagram schematically showing a safety system according to an embodiment described herein. FIG. 2 is a flow chart schematically illustrating a secure method of protecting a master-mediated transaction based on bus monitoring, according to an embodiment described herein. FIG. 3 is a flow chart schematically showing a safe read and write operation method according to the embodiment described herein. FIG. 4 is a flow chart schematically showing a safe read and write operation method according to the embodiment described herein. FIG. 5 is a block diagram schematically showing a safety system that supports disconnection of the master device from the bus according to the embodiments described herein. FIG. 6 is a block diagram schematically showing a secure method for secure access to a slave device by disconnecting the host from the bus, according to the embodiments described herein.

Hereinafter, the present invention will be described based on the embodiments shown in the figure.

In a master-slave configuration, a host device acting as a bus master is typically connected to multiple slave devices via the bus. A host as a bus master can initiate transactions on the bus, but slave devices can only access the bus by responding to the host. However, in some practical scenarios it is desirable for one slave device to be able to initiate and execute transactions with another.

The embodiments described herein provide systems and methods for performing and protecting master mediation transactions between slave devices using bus monitoring. A device that monitors a bus can be connected to a host through an additional different bus and request a transaction from the host through that additional bus.

In some embodiments, the host runs a device driver that mediates transactions on the bus on behalf of one or more applications that may require access to the bus, as well as slave devices.

The host acts as an intermediary between the device driver and other applications attempting to access the bus.

In some embodiments, the first device (eg, slave TPM or other security processor) needs to execute a transaction on the second device (eg, slave flash memory). For this purpose, the first device requests the host's device driver to initiate a transaction on the bus to access the second device, for example using interrupt or polling notification flag technology. The first device monitors the transactions executed on behalf of the host on the bus, for example, to ensure that the transactions are executed correctly so that the host is not compromised.

In some embodiments, the first device violates a (predefined) security policy on the bus, for example, by an attacker accessing the host, as well as to validate the requested transaction as described above. Buses can also be monitored to verify that they are not.

The first device may monitor one or more signals on the bus, at least during the time the host accesses the second device over the bus when performing the requested transaction. The first device identifies whether a security breach occurred during the execution of the requested transaction based on the monitored signal. Upon detecting a security breach, the first device takes protective actions, such as accessing the second device, to prevent the disclosure of data appearing on the bus. In one embodiment, the choice of protective action can be based on a predefined policy.

The first device (1) reads data from the second device, (2) writes data to the second device, or (3) transfers data between different addresses of the second device to the host. Data read from or written to the second device can be encrypted and / or signed.

The first device can identify a security breach by detecting that at least a portion of the transaction information expected in the requested transaction is different from the actual transaction information monitored on the bus. Such discrepancies can occur in at least one transaction element, such as a transaction opcode element or command type element, address element and / or data element. In some embodiments, the first device violates a predefined security policy on the bus (eg, a protected address is accessed) during or outside the requested transaction. A security breach can be identified in response to a detection.

In one embodiment, the requested transaction comprises reading data from a second device, the first device monitoring the bus and monitoring the data read from the second device by the host over the bus. In another embodiment, the first device requests the host to initiate a dummy write (or dummy read) operation to the second device. The first device then performs another write (or read) operation by overwriting the logical value of one or more signals on the bus while the host is performing a dummy write (or dummy read) operation. Applies to devices. In yet another embodiment, during the execution of the requested transaction by the host, the first device disconnects the signal of the bus connecting between the host and the second device, and the second device goes through the bus on behalf of the host. Access the device.

In the configuration example, the safety system comprises a slave safety device and a slave NVM device. To provide security services to the host, the security device needs to access an external NVM device. The host runs a dedicated device driver that acts as an intermediary between the safety device and the NVM device. The safety device receives security commands from the application program running on the host and transparently accesses the application program via a dedicated device driver to access the NVM device via the bus. To execute.

In the disclosed technology, the host acts as a bus master and shares the bus with one or more slave devices by running device drivers that mediate transactions on the bus. The monitoring device monitors the bus to detect security breaches. The monitoring device can be coupled to the bus to monitor and control the signals on the bus and, as a slave device, can request the host to initiate a transaction on the bus. Alternatively, the witness device is further coupled to the host via a different bus to request the host to initiate a transaction on the bus. By monitoring the bus, the monitoring device can also monitor the transactions on the bus and overwrite or replace the transactions on the bus with the desired transactions hidden from the host.

Description of the System FIG. 1 is a block diagram schematically showing a safety system 20 according to an embodiment described herein. In this example, the safety system 20 includes a master host device 24 that connects to peripheral slave devices 28, 32 using the bus 36. Slave devices 28 and 32 are designated as slave 1 and slave 2, respectively. In this example, bus 36 includes a serial peripheral interface (SPI) bus. In other embodiments, the bus 36 can include any other suitable bus, such as a low pin count bus (LPC), or an internally integrated circuit (I2C) bus. The I2C bus can be used, for example, to connect to an electrically erasable read-only memory (EEPROM) device. Other bus interfaces to solid state storage devices may include, for example, secure digital (SD) interfaces, multimedia card (MMC) interfaces, or parallel flash interfaces. Host devices are also referred to simply as "hosts" for brevity.

In some embodiments, the slave 1 is a slave device of the host via the bus 36, which further monitors and controls the bus signal of the bus 36. In an alternative embodiment, the slave 1 is coupled to the bus 36 to monitor and control the bus signal, but is coupled to the host as a slave device via another bus (not shown), such as the I2C bus. To.

In the master-slave configuration of the safety system 20, only the host 24 can initiate a read or write transaction over the bus 36. On the other hand, each slave device can access the bus 36 only in response to a request from the host 24. In this master-slave configuration, the slave 1 and the slave 2 cannot communicate directly via the bus 36, but their communication needs to be mediated by the host. Such mediation is necessary if the slave 1 is a slave via the bus 36 and if the slave 1 is connected to the host via another bus.

Slave 1 and Slave 2 can be configured with any suitable type of device. In one configuration, the slave 1 can include a safety device, sometimes referred to as a trusted platform module (TPM), and the slave 2 can include a non-volatile memory (NVM). Other suitable configurations of slave devices 28, 32 can also be used. Generally, the slave 1 includes a suitable controller such as an embedded controller (EC). In an exemplary embodiment, the slave 2 can include any suitable type of NVM, such as, for example, read-only memory (ROM), one-time programmable (OTP) memory, EEPROM, or flash memory. Alternatively, the slave 2 can include volatile memory such as a random access memory (RAM) device.

It should be noted that a system configuration in which one of the slave devices includes a memory device is not essential. In some embodiments, the slave 1 and the slave 2 include a controller that may need to exchange information with each other via the host while monitoring the bus.

In this example, slave 1 stores a bus interface 40 for connecting to bus 36, a processor 44 configured to perform the disclosed technology, and one or more security policies implemented by the processor 44. A memory 48 configured as described above is provided. The processor 44 includes a slave interface logic 52 and an interface monitor logic (IML) 56. The slave interface logic 52 processes the communication between the slave 1 and the host 24. The IML 56 monitors, controls, and selectively overrides the bus signal when the host 24 accesses the slave 2 instead of the slave 1. In some embodiments, the IML 56 monitors the bus to verify the correct execution of the transaction requested by the host by the slave 1. In one embodiment, the IML 56 further monitors the bus to detect possible violations of one or more predetermined security policies that may be stored in memory 48, not related to a particular requested transaction.

In the safety system 20, slave 1 monitors transactions on bus 36 to prevent unauthorized transactions, for example, by host 24 or another device with bus master functionality attempting to access slave 2 without permission. Use 56 to protect access to slave 2. In some embodiments, the slave 1's IML56 monitors the bus 36 to intercept the transaction requested by the slave 1 that is actually being executed by the host to ensure that the transaction is being executed correctly. In response to the detection of a violation on the bus, the IML56 can apply appropriate protective actions, for example, during the execution of the requested transaction by the host.

In some embodiments, protective actions are used to prevent unwanted leaks or exposure of confidential information that may be exposed to the bus 36 during a transaction. In some embodiments, the protective action is for data stored in slave 2 such as preventing data corruption on the bus or unauthorized attempts to change the setup or configuration information stored in slave 2. Prevent data corruption.

The host 24 includes a CPU 60 that executes one or more applications 64, and a dedicated device driver 68. In some embodiments, the slave 1 comprises a safety device that provides the host 24, along with a dedicated device driver with the features needed to implement Trustworthy Computing and other security policies. The CPU 60 mediates between various programs or processes that the CPU executes and may require access to the bus 36, such as the application 64 and the dedicated device driver 68. Application 64 may include security applications that provide secure storage services, such as controlled access to system resources for stored information.

The dedicated device driver 68 mediates communication between the slave 1 and the slave 2. For example, the device driver 68 transparently provides the slave 1 with indirect access to the slave 2. When performing an internal task or calculation, slave 1 may require access to slave 2, for example, to read data from slave 2 or write data to slave 2. The slave 1 may need access to the slave 2 regardless of the application 64 running on the host 24. Alternatively, the slave 1 needs to access the slave 2 in order to execute a command transmitted from the application 64.

The slave 1 can request the device driver 68 to access the slave 2 in various ways. In one embodiment, the slave 1 internally prepares the request, eg, in a predefined register, and generates an interrupt signal to notify the device driver to read the request via bus 36. In another embodiment, the device driver (68) polls the registers in slave 1 to identify if there are any pending requests. In yet another embodiment, the device driver 68 conditionally checks the register value of slave 1 in response to, for example, application 64 sending a command (eg, a security command) to the slave device.

When the device driver 68 receives a request to access the slave 2 from the slave 1, the CPU mediates between the device driver 68 and another application (64) and accesses the slave 2 via the bus 36 on behalf of the slave 1. do. For example, if slave 2 includes NVM or other memory, slave 1 requests device driver 68 to access bus 36, (1) reads data from a given NVM address, and (2) to a given NVM address. Write data, (3) Copy data from one NVM address to another.

Safety Method Using Bus Monitoring The safety system 20 can be compromised by a rogue attacker, for example by tampering with the host 24. An attacker can, for example, detect a transaction requested by a host by slave 1 and force the host to apply a different transaction to slave 2. By monitoring the bus 36, the slave 1 can detect a violation event on the bus and take protective actions accordingly.

In the following embodiments, it is assumed that the transaction executed by the host 24 using the slave 2 appears on the bus as a sequence of logical values. The sequence corresponding to a given transaction usually includes an address part and a data part, i.e., [address, data]. The sequence of logical values may also include an opcode that identifies the type of transaction, in which case the sequence is displayed as [opcode, address, data] on the bus. In this example, when slave 1 intercepts the opcode portion, the address portion, the data portion, or both can be modified (eg, overwritten with a logical value). The opcode, address, and data portion of a transaction are collectively referred to herein as "transaction information."

FIG. 2 is a flowchart illustrating a method of protecting a master-mediated transaction based on bus monitoring, according to an embodiment described herein. This method may be performed, for example, by the processor 44 of the slave device 28 of FIG. In the description of the method, as a non-limiting example, the slave device 28 (slave 1) includes a safety device, and the slave device 32 (slave 2) has a flash memory, eg, SPI, when the bus 36 includes an SPI bus. Includes flash memory.

This method begins with the processor 44 (of slave 1) booting from flash memory in reset hold step 100. In one embodiment, the processor 44 comprises suitable interfaces and circuits (not shown) for keeping the host 24 at reset while accessing flash memory, typically as part of the system boot process. In one embodiment, in order to load the boot program, the processor 44 loads the data blocks from the flash memory, verifies the authenticity of the data blocks, and stores the authenticated data blocks locally in the memory 48. The above boot mechanism that keeps the host on reset is not required. In alternative embodiments, other suitable boot methods may also be used.

In step 104 requesting a transaction, the processor 44 requests the device driver 68 of the host 24 to initiate a transaction involving accessing the flash memory via the bus 36. The requested transaction may be, for example, (1) reading data from a given flash address, (2) writing data to a given flash address, or (3) data from one flash address to another. May include copying.

In monitoring step 108, processor 44 monitors bus 36 using IML56 and intercepts the requested transaction on the bus to ensure that the transaction is executed as intended. For example, in the case of a write transaction, make sure that the data specified in the transaction is actually written to the address specified in the transaction. The IML monitors one or more bus signals, such as chip select (CS) signals, clock signals, and bus signals carrying data and address information. When the bus 36 includes an SPI bus, the IML 56 can monitor data and address information via a master-out slave-in (MOSI) signal, a master-in-slave out (MISO) signal of the SPI bus, or both.

At step 108, the processor 44 can intercept the requested transaction on the bus, for example, based on information within the requested transaction or other information known to the processor. During the time when the transaction is requested and the time when the transaction requested by the device driver is actually executed, the host may start another transaction on the bus originating from the application 64, which the transaction processor 44 normally ignores. It should be noted that there is. In an exemplary embodiment, in the case of a read, write, or copy transaction, the processor 44 intercepts the address information specified in the requested transaction. For write transactions, the processor intercepts the data to be written (or part of this data).

Further in step 108, in response to interception of the requested transaction (or part of the transaction) on the bus, the processor monitors the bus (using IML) and the requested transaction executes as intended. Make sure it is done. For example, the processor verifies that the host accesses the flash memory over the bus 36 at the address or address range specified in the requested transaction. In a write and copy transaction, the processor verifies that the data to be written or copied matches the data specified in the requested write or copy transaction. The processor can further ensure that it does not violate the security policy specified in memory 48 when executing the requested transaction (or perhaps other transactions as well). Further, the processor 44 can confirm that the specified security policy is not violated regardless of the specific transaction request.

In violation check step 112, the processor checks if a violation has been detected on bus 36. As mentioned above, violations are (1) violations of predefined policies stored in memory 48, such as access to a protected address or address range, or (2) at least partly on the bus. The number of transaction information intercepted may differ from the corresponding transaction information in the requested transaction in step 104.

If no violation is detected in step 112, processor 44 proceeds to transaction completion step 116, completes the transaction, loops back to step 104, and requests a subsequent transaction from the host. The processor can complete a transaction by monitoring the bus until the host completes executing the requested transaction. Alternatively or additionally, the processor completes the transaction through the host's device driver. For example, the processor receives data read from the flash memory by the device driver, a completion notification, or both from the device driver.

In response to detecting the violation in step 112, the processor 44 proceeds to protection step 120, where the processor applies appropriate protective actions to prevent leakage or exposure of confidential information. An example of a protective action is described below. Following step 120, the processor can loop back to step 104 and request the host to initiate a subsequent transaction with the flash memory via bus 36.

At step 120, processor 44 can apply various protective actions. In some embodiments, the protective action involves resetting one or more elements of the safety system 20, eg, resetting the host 24. Alternatively, or in addition, the processor interrupts the bus 36, for example by changing the logical value of one or more signals on the bus, or by disconnecting the host from the bus.

Methods for modifying bus signals are described, for example, in US Patent Application Publication No. 2018/0239727, the disclosure of which is incorporated herein by reference. For example, in some embodiments, the bus interface 40 of slave 1 drives one or more of the bus signals of bus 36 in parallel with the host 24. Slave 1 may interrupt the bus by applying a logical value that overrides the logical value driven in parallel by the host. Overriding the logical value of a bus signal, for example, uses a line driver that is stronger than the host's corresponding line driver, or adds resistance in series to the bus signal driven by the host to attenuate the signal driven by the host. It can be realized by doing. In another embodiment, the host signal is routed to the slave 2 via the slave 1 which masks the logical value of the bus signal as needed. The method of disconnecting the host from the bus will be further described below.

Examples of Methods of Using Bus Monitoring to Protect Transactions with Memory Devices The following exemplary embodiments refer to a system configuration in which the slave 2 includes a memory device, eg, flash memory.

3 and 4 are flowcharts schematically showing a method of safe reading and writing operations according to the embodiments described herein. The methods of FIGS. 3 and 4 are performed, for example, by the processor 44 of slave 1. Also, FIGS. 3 and 4 can be combined with the method of FIG. 2 above.

The method of FIG. 3 begins with a read transaction request step 150, in which the processor 44 requests the host device driver 68 to start a read transaction to read data from a predetermined address in the flash memory (slave 2). In monitoring step 154, the processor monitors bus 36 (using IML56) to identify the requested read transaction being performed by the device driver, as described above.

In some embodiments, the read transaction appears on the bus signal as a set of logical values representing the start address of the read, followed by one or more obtained from the flash memory by reading one or more addresses. Followed by a logical value that represents the data unit (bytes, etc.). In an exemplary embodiment, the processor identifies the requested read transaction on the bus by finding the start address specified in the requested read transaction.

In response to the identification of the read transaction on the bus, the processor continues to monitor the bus in monitoring step 158 and captures the logical values on the bus that represent the data being read in parallel by the host. The processor captures one or more data units (such as bytes) as specified in the requested read transaction.

In some embodiments, the data retrieved from the flash memory is signed using a cryptographic signature, in which case the processor can verify the integrity of the data read using the signature. In some embodiments, the data retrieved from the flash memory is encrypted, in which case the processor can decrypt the read data. In some embodiments, in addition to the data captured on the bus, the processor receives a version of the read data via the device driver. In these embodiments, the processor can verify that the host has not been tampered with by comparing the direct data capture on the bus with the data indirectly read through the device driver. Following step 158, the method of FIG. 3 ends.

In the method of FIG. 3, slave 1 monitors the bus signal during a read transaction applied to the flash memory by the host. The method of FIG. 3 can be used in a similar manner to snoop the bus signal during a write transaction applied to the flash memory by the host. In some embodiments, by snooping the bus, slave 1 ensures that the requested transaction is performed as intended.

In the method of FIG. 4, the processor 44 performs a desired write operation of writing the desired data to the desired address in the flash memory without exposing the address, data, or both written to the host.

The method of FIG. 4 begins with a dummy write transaction request step 200, in which the processor 44 requests the device driver 68 to initiate a dummy write transaction to the flash memory (slave 2) via the bus 36. The dummy write transaction specifies an address in flash memory. This can be a predefined dummy address or a real address for writing. The dummy write transaction probably specifies an opcode and dummy data to be written to the specified address. Dummy write transactions are displayed as [opcode, dummy address, dummy data] on the bus. In this example, the dummy address follows the opcode and the dummy data follows the dummy data over time.

In monitoring step 204, the processor monitors bus 36 (using IML56) to identify the requested dummy write transaction being performed by the device driver. The processor can identify a dummy write transaction on the bus, for example, by finding the opcode and / or dummy address specified in the requested transaction on the bus.

At overriding step 208, the processor overrides the logical value on the bus during the dummy write transaction, and the logical value represents the desired write operation. To this end, the processor 44 overwrites one or more of the data, addresses, and opcode portions of the dummy write transaction with the corresponding values for the desired write operation. As a result, the target data is written to the target address of the flash memory. The host is usually unaware of this bus override operation and the data, address, and opcode values of the desired write transaction remain undisclosed.

In some embodiments, when overriding the bus signal as described above, the processor 44 further monitors the bus signal driven by the bus interface. By monitoring the bus signal, the processor 44 can confirm that the intended data has been written to the intended address, as expected.

In the method of FIG. 4, slave 1 overwrites the dummy write transaction with the desired write transaction of different data and addresses in the flash memory. The method of FIG. 4 can be used in a similar manner to override a dummy read transaction with a desired read transaction, for example, reading from a desired address in flash memory.

How to Disconnect the Host from the Bus and Securely Access the Slave Device FIG. 5 schematically illustrates a safety system 250 that supports disconnection of the master device from the bus according to the embodiments described herein. It is a block diagram which shows. The safety system 250 can be used to implement the safety system 20 of FIG.

In the safety system 250, the host 24 includes a bus master connected to slave devices 28 (slave 1) and 32 (slave 2) via the SPI bus 254. The SPI bus consists of a clock (CLK) line and two data lines called master-out slave-in (MOSI) and master-in-slave-out (MISO). The CLK, MOSI, and MISO lines are common to all devices (host 24, and slave devices 28 and 32 in this example). In addition, each slave device can be selected using a dedicated chip select (CS) line. In this example, the host 24 uses the CS line represented by CS # 1 to select slave 1 and the CS line represented by CS # 2 to select slave 2.

The host 24, which is the master, is connected to all CS lines. On the other hand, each slave device is connected only to its own CS line. Typically, the host 24 initiates a transaction by using each CS line to select a desired slave device and then communicates with the device using the CLK, MOSI and MISO lines. The MOSI line is used for transmission from the host to the slave device, and the MISO line is used for transmission from the slave device to the host.

The slave 1 is defined as a slave unlike the conventional SPI slave, but can drive the CS line of another device such as the CS # 2 line of the slave 2. As shown in FIG. 5, the bus interface 40 of the slave 1 is configured to drive the CS # 2 line in parallel with the host 24. If the system includes a plurality of slave devices having their respective CS lines (eg, slave 2 and the like), the slave 1 may be configured to drive any CS line in parallel with the host device 24.

In FIG. 5, the MOSI line and the MISO line are directly connected to the slave 1. On the other hand, the MOSI and MISO lines are indirectly connected to the slave 2 via the slave 1. In this configuration, the slave 1 controls whether the host's MOSI and MISO lines are connected to or disconnected from the slave 2. Slave 1 includes a MISO selector 260 and a MOSI selector 262. Each of the MISO selector and the MOSI selector consists of two input ports and one output port. At any time, the processor 44 uses the SEL control input to control the selector, making an internal connection between its output port and one of its input ports. The MISO and MOSI selectors can be implemented using any suitable circuit element, for example using a multiplexer element.

When the host 24 reads data from the slave 2, the slave 1 controls the MISO selector to connect the MISO line between the host and the slave 2. In this case, the slave 1 can read the data on the bus in parallel with the host. Alternatively, the slave 1 disconnects the host MISO line from the slave 2 so that the read data is not disclosed to the host. The processor 44 of the slave 1 may inject other data into the host MISO line toward the host instead of the data acquired from the slave 2.

When the host 24 writes data to the slave 2, the slave 1 controls the MOSI selector to connect the host MOSI line to the slave 2 so that the host can write the data to the slave device. Alternatively, slave 1 may use the MOSI selector to disconnect the host MOSI line from slave 2, and processor 44 may inject other addresses and / or data into slave 2 to perform different write transactions. can.

In some embodiments, when the MISO selector connects the host MISO line to slave 2, slave 1 can intercept the host read transaction and override the data / address of the read transaction. Similarly, when the MOSI selector connects the host MOSI line to the slave 2, the slave 1 may intercept the host's write transaction and overwrite the data / address of the write transaction.

It is a flow chart schematically showing the method for secure access to a slave device by disconnecting a host from a bus according to an embodiment described herein. This method can be performed by the processor 44 of the slave device 28 (slave 1) in the protected system 250 of FIG. In this example, slave 1 includes a safety device, slave 2 includes flash memory, and bus 254 includes an SPI bus. The method of FIG. 6 can be combined with the method of FIG. 2 above.

This method begins with transaction request step 300, in which the processor 44 requests the device driver 68 of the host 24 to initiate a dummy write or dummy read transaction to the flash memory. For a dummy read or write transaction, specify the opcode (optional), the real or dummy address in flash memory, and in the case of a write transaction, the real or dummy data.

In monitoring step 304, processor 44 monitors bus 36 (eg, using IML56) to identify the requested dummy write or dummy read transaction being performed by the device driver. The processor can identify a dummy write or dummy read transaction on the bus, for example, by finding the flash memory address and / or opcode specified in the requested transaction.

In disconnect step 308, depending on the requested transaction identification (eg, based on the transaction opcode), the processor disconnects the host from the SPI bus. For write transactions, the processor uses the MOSI selector 262 to disconnect the host from slave 2, while for read transactions, the processor uses the MISO selector 260 to disconnect the host. Alternatively, the processor can use both selectors at the same time to disconnect both the MISO line and the MOSI line. In some embodiments, the processor disconnects the host from the bus regardless of identifying the requested transaction on the bus.

Based on the transaction detected in step 304 being a write or read transaction, the processor proceeds to write step 312 or read step 316, respectively.

At step 312, the processor writes the intended data to the intended address via the SPI bus, regardless of the data and address delivered by the host over the MOSI line. In this technique, the processor overwrites the dummy write transaction with the desired write transaction, which remains hidden from the host. In some embodiments, in addition to writing to flash memory (eg, in parallel), the processor can monitor the MOSI line driven by the host to detect possible violations. In some embodiments, in addition to writing to flash memory (eg, in parallel), the processor may monitor the MOSI line driven by the processor to detect possible violations.

At step 316, the processor reads data from the intended address in flash memory via the SPI bus. The actual data read by the processor remains hidden from the host because the host's MISO line is disconnected from the flash memory. In some embodiments, in addition to reading from flash memory (eg, in parallel), the processor sends other data, such as dummy data, to the host.

Following steps 312 and 316 respectively, the method ends.

The configuration of the safety system 20 and the host device 24, the slave device 28 and the slave device 32 shown in FIG. 1, and the safety system 250 of FIG. 5 are configuration examples and are shown purely for the sake of clarity. Alternatively, other suitable safety system, host device, and slave device configurations can be used. Elements that are not necessary to understand the principles of the invention, such as various interfaces, control circuits, addressing circuits, timing and sequencing circuits, and debug circuits, are omitted from the figure for clarity.

In the exemplary system configuration shown in FIGS. 1 and 5, the CPU 60, slave device 28, and slave device 32 are implemented as separate integrated circuits (ICs). However, in an alternative embodiment, at least two of the CPU, slave device 28, and slave device 32 are integrated into a separate semiconductor die within a single multi-chip package (MCP) or system-on-chip (SoC). Or can be interconnected via an internal bus. In an exemplary embodiment, the slave device 28 (eg, controller) and slave device 32 (eg, flash memory) are mounted in a multi-chip module (MCM). In embodiments where the slave device 28 and the slave device 32 are implemented in the same package (eg, in an MCM or MCP device), both devices are in the same SPI interface line (eg, MISO, MOSI and CLK) in a common package. ) Share. Such an embodiment can provide improved security because it requires an attacker to open a composite device because it attacks or manipulates a signal between two slave devices in an attempt to violate the expected functionality. ..

The different elements of the slave device 28 can be implemented using any suitable hardware such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, some elements of the slave device 28 can be implemented using software or using a combination of hardware and software elements. For example, in this embodiment, the slave interface logic 52 and the IML 56 can be realized as a dedicated hardware module. The memory 48 can include any suitable type of memory and storage technique, such as RAM.

Typically, each of the CPU 60 of the host 24 and the processor 44 of the slave device 28 includes a general purpose processor programmed in software to perform the functions described herein. The software can be downloaded electronically over the network to the relevant processor, or is provided or additionally provided to non-temporary tangible media such as magnetic, optical, or electronic memory. Or it can be stored.

A secure system that includes an encrypted coprocessor. A slave device 28 (slave 1) in which the host 24 acts as a bus master over the bus 36 and acts as an encrypted coprocessor for the host 24, or a host and an encrypted coprocessor. Consider a configuration example of a safety system such as the system 20 of FIG. 1 connected to a slave device 32 (slave 2) including both external non-volatile memory (NVM) devices. The cryptographic coprocessor is also referred to herein as a secure device.

The host runs a security application 64 that provides security services with the help of a safety device. The security application sends a security command to the safety device and receives each command response from the safety device. When providing security applications, a safety device may be required to access the NVM device.

The host runs a dedicated device driver 68 that mediates between the security device and the external NVM device transparently to the security application. The device driver allows the safety device to indirectly access the external NVM via the device driver. When a security command is received from the host, the safety device executes the security command. Security commands may require access to NVM devices over the bus and are transparently executed by the application program via a dedicated device driver.

In some embodiments, for example, when executing a security command requested by a security application, the security device requires the host to initiate a transaction to access the external NVM over the bus. The safety device monitors one or more signals on the bus during the time the host accesses the NVM device over the bus when performing the requested transaction, and is requested based on the monitored signals. Identifies whether a security breach occurred during the execution of a transaction.

As described above, the security system configured by the encrypted coprocessor can use the bus monitoring technology to apply any of the embodiments described above for the security systems 20 and 250.

The above embodiment is given as an example, and other suitable embodiments may be used. For example, although the above embodiments mainly refer to SPI buses, these embodiments are similarly applicable to I2C buses. Further alternative, the disclosed embodiments are not limited to serial buses and are similarly applicable to parallel buses. In some embodiments, the slave 1 is connected to the host (perhaps not necessarily a slave) via a different bus than other slave devices such as the slave 2. In such an embodiment, slave 1 is also connected to a bus to which the host is connected to other slave devices such as slave 2, allowing, for example, monitoring and protection of the bus using the methods and systems described above. do.

In some of the above embodiments, slave 1 detects a transaction by identifying an opcode, address, or data element on the bus. As an alternative, it may be sufficient to detect only some of such devices. For example, slave 1 can detect a transaction by detecting only a part of an address element such as a top-level part that specifies an address range.

Although the embodiments described herein primarily refer to embodiments in which the SPI bus operates in single mode, the disclosed embodiments are similarly applicable to SPI buses operating in double or quad mode. Is.

Although the embodiments described herein primarily deal with SPI and I2C buses for connecting devices, the safety methods and systems described herein include, for example, the Extended Serial Peripheral Interface Bus (eSPI). It can also be used with other suitable types of peripheral buses.

In the above embodiments, the slave 2 is primarily referred to as a flash or NVM device, but the methods and systems described herein include any other suitable slave 2 such as volatile memory or other device in the system. It can also be used in other applications that may be peripheral devices. For example, slave 2 may include any suitable controller or monitoring device.

It will be appreciated that the above embodiments are taken as examples and the claims are not limited to those specifically indicated and described above. Rather, the scope includes both combinations and partial combinations of the various features described above, as well as its modifications and modifications not disclosed in the prior art that one of ordinary skill in the art would come up with when reading the above description. Documents incorporated into this patent application by reference are essential to this application unless the terms are defined in these incorporated documents in a manner that contradicts the definitions made expressly or implicitly herein. Should be considered part. The definitions herein need to be considered.

20 ... Safety system 24 ... Host device 250 ... Safety system 28 ... Slave device 32 ... Slave device 36 ... Bus 40 ... Bus interface 44 ... Processor 48 ... Memory 52 ... Slave interface logic 56 ... Interface monitor logic (IML)
60 ... CPU
64 ... Application 68 ... Device driver

Claims (45)

Equipped with an interface and a processor,
The interface is
The host and the second device are connected to the combined bus, at least the second device operates on the bus in slave mode, and the host initiates a transaction on the bus, at least on behalf of the safety device. Acts on the bus as a bus master,
The processor
Requesting the host to initiate a transaction to access the second device via the bus for the safety device.
At least during the period in which the host accesses the second device via the bus and executes the requested transaction, one or more signals on the bus are monitored.
A safety device comprising identifying whether a security breach has occurred during the execution of the requested transaction based on the monitored signal. The safety device according to claim 1, wherein the processor is configured to operate on the bus in slave mode. The safety device is further coupled to the host via another bus different from the bus, and the processor is configured to require the host to initiate the transaction via the other bus. The safety device according to claim 1. The requested transaction includes (1) reading data from the second device, (2) writing data to the second device, and (3) between the first and second addresses of the second device. The safety device according to claim 1, which comprises any one of the data transfer of the above. The requested transaction specifies the expected transaction information, and the processor is configured to monitor the actual transaction information corresponding to the requested transaction on the bus, said said expected. The safety device according to claim 1, wherein the security breach is identified by detecting that at least a part of the transaction information is different from the actual transaction information. The processor is configured to detect that at least one element selected from a list including an opcode element, an address element and a data element is different between the expected transaction information and the actual transaction information. The safety device according to claim 5. Claims configured such that the processor identifies a security breach by detecting that a predetermined security policy has been breached on the bus during or outside the requested transaction. The safety device according to 1. The requested transaction comprises reading data from the second device, such that the processor monitors the data read from the second device by the host via the bus on the bus. The safety device according to claim 1. The processor overwrites the logical value of one or more signals on the bus while the host is performing the first write operation, thereby causing the host to perform the first write operation to the second device. The safety device according to claim 1, wherein a second write operation different from the first write operation is requested to be applied to the second device. The processor overwrites the logical value of one or more signals on the bus while the host is performing the first read operation, thereby causing the host to perform the first read operation to the second device. The safety device according to claim 1, wherein a second read operation different from the first read operation is requested to be applied to the second device. The processor initiates a transaction to access the second device via the bus, disconnects the signal of the bus connecting the host to the second device, and via the bus on behalf of the host. The safety device according to claim 1, which is configured to request the host to access the second device. The processor is configured to perform protective actions in response to the identification of the security breach to prevent disclosure or modification of the data appearing on the bus when accessing the second device. Item 1. The safety device according to item 1. The safety device according to claim 1, wherein both the safety device and the second device are mounted in a common package and interconnected via the bus in the common package. In a safety device connected to a bus to which a host and a second device are coupled, at least the second device operates on the bus in slave mode and the host at least represents the safety device on the bus. Acting on the bus as a bus master to initiate a transaction,
The safety device requests the host to initiate a transaction to access the second device via the bus for the safety device.
Monitoring one or more signals on the bus, at least during the period in which the host accesses the second device via the bus and executes the requested transaction.
Identifying whether a security breach occurred during the execution of the requested transaction based on the monitored signal.
A safety method characterized by including. 14. The safety method of claim 14, wherein the safety device is configured to operate on the bus in slave mode. The safety device is further coupled to the host via another bus different from the bus, and the safety device is configured to require the host to initiate the transaction via the other bus. The safety method according to claim 14. The requested transaction includes (1) reading data from the second device, (2) writing data to the second device, and (3) between the first and second addresses of the second device. The safety method according to claim 14, wherein the data is transferred according to any one of the above. The requested transaction specifies the expected transaction information and
Monitoring the signal includes monitoring the actual transaction information corresponding to the requested transaction on the bus.
14. The security method of claim 14, wherein identifying the security breach comprises detecting that at least a portion of the expected transaction information is different from the actual transaction information. Identifying the security breach is a claim to detect that at least one element selected from the list including the opcode element, the address element and the data element is different between the expected transaction information and the actual transaction information. Item 14. The safety method according to item 14. 14. The security method of claim 14, wherein identifying the security breach comprises detecting that a predetermined security policy has been breached on the bus during or outside the requested transaction. 14. The requested transaction comprises reading data from the second device and monitoring data read from the second device by the host via the bus on the bus. The safety method described in. By overwriting the logical value of one or more signals on the bus during the execution of the first write operation by the host, the host is requested to start the first write operation to the second device. The safety method according to claim 14, further comprising requesting that a second write operation different from the first write operation be applied to the second device. By overwriting the logical value of one or more signals on the bus while the host is performing the first read operation, the host is requested to start the first read operation on the second device. The safety method according to claim 14, further comprising requesting that a second read operation different from the first read operation be applied to the second device. A transaction to access the second device via the bus is started, the signal of the bus connecting the host and the second device is disconnected, and the second device is connected to the second device via the bus on behalf of the host. 14. The safety method of claim 14, comprising requesting the host to access. 14. The security method of claim 14, wherein in response to the identification of the security breach, a protective action is taken to prevent disclosure or modification of the data appearing on the bus when accessing the second device. The safety method according to claim 14, wherein both the safety device and the second device are mounted in a common package and interconnected via the bus in the common package. Equipped with a host and a safety device,
The host
Accessing the slave device coupled to the bus by being coupled to the bus and configured to act as a bus master and mediating the bus access operation triggered by the slave device and the host.
The safety device is
Requesting the host to initiate a transaction to access a second device connected to the bus and connected as a slave to the bus.
Monitoring one or more signals on the bus, at least during the period in which the host accesses the second device via the bus when performing the requested transaction.
A safety system comprising identifying whether a security breach has occurred during the execution of the requested transaction based on the monitored signal. 27. The safety system of claim 27, wherein the safety device is configured to operate on the bus in slave mode. The safety device is further coupled to the host via another bus different from the bus, and the safety device is configured to require the host to initiate the transaction via the other bus. 27. The safety system according to claim 27. The requested transaction specifies expected transaction information, and the safety device is configured to monitor the actual transaction information corresponding to the requested transaction on the bus, said expected. 28. The security system of claim 27, which identifies the security breach by detecting that at least a portion of the transaction information is different from the actual transaction information. The requested transaction comprises reading data from the second device, such that the safety device monitors the data read from the second device by the host via the bus on the bus. The safety system according to claim 27. The safety device overwrites the logical value of one or more signals on the bus while the host is performing the first write operation, thereby causing the host to perform the first write operation to the second device. 27. The safety system according to claim 27, which is configured to request that a second write operation different from the first write operation be applied to the second device. The safety device causes the host to perform the first read operation to the second device by overwriting the logical value of one or more signals on the bus while the host is performing the first read operation. 27. The safety system according to claim 27, which is configured to request that a second read operation different from the first read operation be applied to the second device. The safety device initiates a transaction to access the second device via the bus, disconnects the signal of the bus connecting the host to the second device, and via the bus on behalf of the host. 27. The safety system of claim 27, configured to require the host to access the second device. The safety device is configured to perform protective actions in response to the identification of the security breach to prevent disclosure or modification of data appearing on the bus when accessing the second device. Item 27. The safety system. In a safety system that includes a host acting as a bus master on a bus to which a slave device is connected, mediation by the host between the slave device and a bus access operation triggered by the host.
Requesting the host to initiate a transaction to access the second device attached to the bus as a slave by the safety device attached to the bus.
By the safety device, at least during the period when the host accesses the second device via the bus and executes the requested transaction, one or more signals on the bus are monitored. ,
Identifying whether a security breach has occurred during the execution of the requested transaction by the safety device based on the monitored signal.
Safety methods including. 36. The safety method of claim 36, wherein the safety device is configured to operate on the bus in slave mode. The safety device is further coupled to the host via another bus different from the bus, and the safety device is configured to require the host to initiate the transaction via the other bus. 36. The safety method according to claim 36. The requested transaction specifies the expected transaction information and
Monitoring the signal includes monitoring the actual transaction information corresponding to the requested transaction on the bus.
36. The security method of claim 36, wherein identifying the security breach comprises detecting that at least a portion of the expected transaction information is different from the actual transaction information. 36. The requested transaction comprises reading data from the second device and monitoring data read from the second device by the host via the bus on the bus. The safety method described in. By overwriting the logical value of one or more signals on the bus during the execution of the first write operation by the host, the host is requested to start the first write operation to the second device. 36, the safety method of claim 36, comprising requesting that a second write operation different from the first write operation be applied to the second device. By overwriting the logical value of one or more signals on the bus while the host is performing the first read operation, the host is requested to start the first read operation on the second device. 36. The safety method of claim 36, comprising requesting that a second read operation different from the first read operation be applied to the second device. A transaction to access the second device via the bus is started, the signal of the bus connecting the host and the second device is disconnected, and the second device is connected to the second device via the bus on behalf of the host. 36. The safety method of claim 36, comprising requesting the host to access. 36. The safety method of claim 36, wherein in response to the identification of the security breach, a protective action is taken to prevent disclosure or modification of the data appearing on the bus when accessing the second device. A security device that provides security services to the host,
With a device driver running on the host,
The safety device, the host, and the non-volatile memory device outside the safety device are coupled to a common bus.
The device driver is configured to mediate between the safety device and the non-volatile memory device.
The safety device is transparent to the application program via the device driver by receiving a security command from the application program running on the host and accessing the non-volatile memory device via the bus. Safety equipment characterized by executing security commands in.

Images