TWI751962B - Secured device, secured method, secured system, and secured apparatus - Google Patents

Abstract

A secured device includes an interface and a processor. The interface is configured to connect to a bus, to which a host and a second device are coupled. At least the second device operates over the bus in a slave mode, and the host operates on the bus as a bus master that initiates transactions on the bus, at least on behalf of the secured device. The processor is configured to request the host to initiate, for the secured device, a transaction that accesses the second device over the bus, to monitor one or more signals on the bus, at least within a period during which the host accesses the second device over the bus in performing the requested transaction, and to identify, based on the monitored signals, whether a security violation occurred in performing the requested transaction.

Description

Safety device, safety method, safety system, and safety device

The present invention relates to the technical field of electronic system security, in particular to a method and system for protecting data handling between peripheral devices.

Electronic systems use various types of bus interfaces to communicate between host devices and peripheral devices. Examples include a bus interface integrated circuit between the internal ^{I 2 C (Inter-Integrated-} Circuit, I 2 C) bus, and the serial peripheral interface (Serial Peripheral Interface, SPI) bus. I ² C bus such as are described in the April 4, 2014 in the NXP Semiconductors UM10204, Revision 6 of "I ² C bus specification and user manual", which is hereby incorporated by reference.

CROSS-REFERENCE TO RELATED APPLICATIONS:

This application is a continuation-in-part (CIP) of US Patent Application 14/714,298, filed May 17, 2015, which claims priority to US Provisional Patent Application 62/028,345, filed July 24, 2014. This application is incorporated herein by reference. This application is related to US Patent Application, Attorney Docket No. 1041-2004, filed even date, entitled "Secure System Boot Monitor". The disclosures of these related applications are incorporated herein by reference.

Embodiments described herein provide a security device that includes an interface and a processor. The interface is configured to be connected to a bus bar coupled by a master and a second device, wherein at least the second device operates on the bus in a slave mode, and wherein the master operates Acting as a bus master on the bus can at least initiate data processing on the bus on behalf of the security device.

In one embodiment, the processor is configured to operate on the busbar in a slave mode. In another embodiment, the security device is further coupled to the host through another bus than the bus, and the processor is configured to request the host to initiate the data handling via the other bus.

In some embodiments, the requested data handling includes one of: (i) reading data from the second device, (ii) writing data to the second device, and (iii) at the second device's Data is sent between the first and second addresses. In other embodiments, the requested material disposition specifies expected material disposition information, and the processor is configured to monitor on the bus for actual disposition information corresponding to the requested material disposition, and to detect by At least part of the expected disposition information differs from the actual disposition information to identify the security violation. The processor is configured to detect that at least one element is selected from a list including an opcode element, an address element and a data element, the at least one element being different between the expected disposition information and the actual disposition information.

In one embodiment, the processor is configured to identify the security violation by identifying that a predetermined security policy has been violated on the bus, either during or outside the requested data handling period. In another embodiment, the requested data handling includes reading data from the second device, and the processor is configured to monitor, on the bus, data read on the bus by the host from the second device material. In yet another embodiment, the processor is configured to request the host to initiate the first write operation by overriding the logic value of one or more signals on the bus during execution of a first write operation by the host A write operation is performed to the second device, and a second, different write operation is applied to the second device.

In some embodiments, the processor is configured to request the host to initiate the first read by overriding the logic value of one or more signals on the bus during execution of a first read operation by the host Fetch operations to the second device, and apply a second, different read operation to the second device. In other embodiments, the processor is configured to request the host to initiate a data process accessing the second device through the bus, disconnect a signal connecting the bus between the host and the second device , and replace the host to access the second device through the bus. In other embodiments, in response to identifying the security violation, the processor is configured to perform a protective action to prevent exposure or modification of data present on the bus when the second device is accessed.

In one embodiment, both the safety device and the second device are implemented in a common package and are interconnected by the busbars within the common package.

In accordance with embodiments described herein, there is also provided a method comprising: in a safety device, the safety device is connected to a bus to which a host and a second device are coupled, wherein at least the second device is at the bus The bus operates in a slave mode, and wherein the master operates on the bus as a master and at least initiates data processing on the bus on behalf of a security device. requesting the host by the security device to initiate a data process for the security device that accesses the second device through the bus; monitoring at least during the host's access to the second device through the bus to perform the requested data process one or more signals on the bus; and based on the monitored signals, identifying whether a security violation occurred while performing the requested data processing.

According to embodiments described herein, there is also provided a security system including a host and a security device. Including: a master coupled to a bus, the master configured to operate as a bus master and to access the bus coupling by arbitrating between slave devices and bus access operations triggered by the master a slave device; and a safety device coupled to the bus and configured to: request the host to initiate data handling for accessing a second device connected to the bus as a slave; at least when the host passes During the period during which the bus accesses the second device to perform the requested data processing, monitoring one or more signals on the bus; and identifying, based on the monitored signals, whether a signal occurred while performing the requested data processing Security violation.

In one embodiment, the safety device is configured to operate on the busbar in a slave mode. In another embodiment, the security device is further coupled to the host through another bus than the bus, and the security device is configured to request the host to initiate the data handling via the other bus.

In some embodiments, the requested data disposition specifies expected data disposition information, wherein the security device is configured to monitor the actual disposition information corresponding to the requested data disposition on the bus, and to identify the A security violation by detecting that at least part of the expected disposition information differs from the actual disposition information. In other embodiments, the requested data handling includes reading data from the second device, and wherein the security device is configured to monitor on the bus, read by the host from the second device on the bus information on the row. In other embodiments, the security device is configured to request the host to initiate the first write by overriding the logic value of one or more signals on the bus during execution of the first write operation by the host write operations to the second device, and apply a second, different write operation to the second device.

In one embodiment, the security device is configured to request the host to initiate the first read by overriding the logic value of one or more signals on the bus during execution of a first read operation by the host Fetch operations to the second device, and apply a second, different read operation to the second device. In another embodiment, the security device is configured to request the host to initiate a data process that accesses the second device through the bus, disconnecting a connection to the bus between the host and the second device signal, and replace the host to access the second device through the bus. In yet another embodiment, in response to identifying the security violation, the security device performs a protective action to prevent exposure or modification of data present on the bus when the second device is accessed.

In accordance with embodiments described herein, there is also provided a method comprising a safety system including a host operating on a bus as a bus master, a slave device coupled to the host, by the host operating on a bus by the slave Arbitration between a slave device and a bus access operation triggered by the host; through a safety device coupled to the bus, the host is requested to initiate a data processing to access a first slave coupled to the bus that is the most slave two devices; monitoring, via the security device, one or more signals on the bus, at least during the host accessing the second device through the bus to perform the requested data processing; and based on the monitored signals, Identifying, by the security device, whether a security violation occurred while performing the requested data processing

In accordance with embodiments described herein, there is also provided apparatus comprising: a security device providing a security service to a host, wherein the security device, the host and a non-volatile memory (NVM) external to the security device are coupled to a common bus; and a dedicated device driver executing on the host, wherein the device driver is configured to mediate between the secure device and the non-volatile memory (NVM) device, and wherein the secure device is configured to receive a security command from an application executing on the host, and execute the security command by accessing the non-volatile memory (NVM) device on the bus, to the application through the dedicated device driver transparent.

These and other embodiments can be more fully understood from the following detailed description of the embodiments in conjunction with the accompanying drawings, in which:

In a master-slave configuration, the master device, which is the bus master, is typically coupled to multiple slave devices through the bus. A master as a bus master is allowed to initiate data processing on that bus, but slaves can only access the bus by responding to the master. However, in some practical situations, it is desirable for one slave device to be able to initiate and perform data processing with another slave device.

Embodiments described herein provide systems and methods for data handling using bus monitoring to perform and protect master mediation between slave devices. The device monitoring the bus can be coupled to the host through an additional different bus and request data handling from the host through the additional bus.

In some embodiments, the host executes one or more applications that may require access to the bus, and a device driver mediates data handling on the bus. The host arbitrates between the device driver and other applications trying to access the bus.

In some embodiments, a first device (eg, a slave Trusted Platform Module (TPM) or other secure processor) needs to execute data in a second device (eg, a slave flash memory) dispose of. To this end, the first device requests the device driver in the host to initiate data handling on the bus to access the second device on its behalf, eg, by using an interrupt or polling notification flag technique. The first device monitors data processing performed by the host on its behalf on the bus to ensure that data processing is performed correctly, eg, without harming the host.

In some embodiments, the first device may not only monitor the bus as described above for verifying the requested data disposition, but may also monitor that a security policy (eg, predefined) has not been violated on the bus, eg, by An attacker with access rights to the host.

The first device may monitor one or more signals on the bus during a time period when the host accesses the second device through the bus at least in performing the requested data handling. The first device identifies, based on the monitored signals, whether a security breach has occurred in performing the requested data processing. When a security violation is detected, the first device may perform protective actions, eg, actions that prevent exposure of data present on the bus bar when the second device is accessed. In one embodiment, protection actions may be selected based on predefined policies.

The first device may request the host to initiate any suitable data handling, eg, (i) reading data from the second device, (ii) writing data to the second device, or (iii) at a different address in the second device transfer data between. Data read from or written to the second device may be encrypted and/or signed.

The first device may identify a security violation by detecting that at least a portion of the expected disposition information specified in the requested material disposition differs from the actual disposition information monitored on the bus. Such a mismatch may occur in at least one data handling element, such as an opcode or command type element of the data handling, an address element and/or a data element. In some embodiments, the first device may respond to detecting that a predefined security policy has been violated on the bus (eg, a protected bit has been accessed, within or outside the time period of the requested data handling) address) to identify security violations.

In one embodiment, the requested data handling includes reading data from the second device, and the first device monitors the bus to monitor data read by the host from the second device via the bus. In another embodiment, the first device requests the host to initiate a virtual write (or virtual read) operation to the second device. The first device then applies a different write (or read) operation to the second device by overriding the logic value of one or more signals on the bus while the host is performing the virtual write (or virtual read) operation device. In other embodiments, the first device disconnects the signal from the bus between the host and the second device and accesses the second device through the bus rather than the host during the host's execution of the requested data handling.

In an example configuration, the safety system includes a slave safety device and a slave non-volatile memory (NVM) device. In order to provide security services to the host, the security device needs to access a non-volatile memory (NVM) device located outside the security device. The host implements a dedicated device driver that mediates between the secure device and the non-volatile memory (NVM) device. The security device receives security commands from the application program running on the host, and accesses the non-volatile memory (NVM) device through the bus, and executes the security command transparently to the application program through the dedicated device driver.

In the disclosed technology, a master operates as a bus master and shares the bus with one or more slave devices by running a device driver that mediates on the bus. The monitoring device monitors the busbars to detect safety violations. A monitoring device is coupled to the bus for monitoring and controlling signals on the bus, and can request the host to initiate data processing on the bus. Alternatively, the monitoring device is additionally coupled to the host through a different bus for requesting the host to initiate data processing on the bus. By monitoring the bus, the monitoring device can snoop the data disposition on the bus and/or even override or replace the data disposition on the bus with a desired data disposition hidden from the host.

System Description Figure 1 is a block diagram schematically illustrating a security system 20 according to embodiments described herein. In this example, the safety system 20 includes a host device 24 connected to peripheral slave devices 28 and 32 using a bus bar 36 . Slave devices 28 and 32 are designated SLAVE1 and SLAVE2, respectively. In this example, the busbars 36 include Serial Peripheral Interface (SPI) busbars. In other embodiments, the bus bar 36 may comprise any other suitable bus bar, such as a Low Pin Count bus (LPC) or an Inter-Integrated Circuit (I ² C) bus Row. For example, I ² C bus is connected to an electronic erasable programmable read only memory (Electrically Erasable Programmable Read-Only Memory , EEPROM) device. Other bus interfaces of the solid state storage device may include, for example, a Secure Digital (SD) interface, a Multimedia Card (MMC) interface or a parallel Flash interface. For the sake of brevity, the host device is also simply referred to as the "host".

In some embodiments, SLAVE1 shown in FIG. 1 is the master slave 28 on the bus 36 and additionally monitors and controls the bus signal of the bus 36 . In alternative embodiments, slave1 coupled to bus 36 to monitor and control signal bus, however, through another bus (not shown), for example, I ² C bus coupled to the host as possible slave.

In the master-slave configuration of security system 20 , only master device 24 is allowed to initiate read or write transactions through bus 36 . On the other hand, each slave device can only access the bus 36 in response to a request from the master device 24 . In this master-slave configuration, SLAVE1 and SLAVE2 cannot communicate directly with each other via bus 36, but require their communication to be mediated by the master. This mediation is required for SLAVE1 as a slave on bus 36 and for SLAVE1 to be coupled to the host through another bus.

SLAVE1 and SLAVE2 may comprise any suitable type of device. In one configuration, slave device 28 (SLAVE1 ) may include a safety device sometimes referred to as a Trusted Platform Module (TPM), while slave device 32 (SLAVE2) may include non-volatile memory (NVM). Other suitable configurations of driven devices 28 and 32 may also be used. In general, SLAVE1 may include any suitable controller, such as an Embedded Controller (EC). In example embodiments, SLAVE2 may include any suitable type of non-volatile memory (NVM), eg, Read Only Memory (ROM), One Time Programmable (OTP) memory, EEPROM or flash memory. Alternatively, SLAVE2 may include volatile memory, such as a random access memory (RAM) device.

Note that the system configuration of one of the slave devices, including the memory device, is not mandatory. In some embodiments, SLAVE1 and SLAVE2 include controllers that may need to process information from each other via the host while monitoring the bus.

In this example, SLAVE1 includes a bus interface 40 for connecting to bus 36, a processor 44 configured to perform the disclosed techniques, and memory configured to store one or more security policies enforced by the processor 44 48. The processor 44 includes slave interface logic (Slave interface logic) 52 and interface monitor logic (IML) 56 . Slave interface logic 52 handles communications between SLAVE1 and host device 24 . When host device 24 accesses SLAVE2 on behalf of SLAVE1, interface monitor 56 (IML 56) monitors, controls, and selectively overrides bus signals. In some embodiments, via SLAVE1, interface monitor 56 (IML 56) monitors the bus to verify proper execution of data processing requested from the host. In one embodiment, interface monitoring 56 (IML 56 ) additionally monitors the bus to detect possible violations of one or more predefined security policies that are unrelated to the particular requested data handling and may be stored in memory 48 .

In security system 20, SLAVE1 protects access to SLAVE2 by monitoring data handling on bus 36 and preventing unauthorized data handling, such as using interface monitoring 56 (IML 56), host device 24 or another A bus master capable device attempted unauthorized access to SLAVE2. In some embodiments, SLAVE1's interface monitoring 56 (IML 56) monitors bus 36 to intercept data processing actually performed by the host requested via SLAVE1 and to verify that the data processing is performed correctly. In response to detecting a violation on the bus, eg, during the execution of the requested data processing by the host, the interface monitoring 56 (IML 56) may apply appropriate protective actions.

In some embodiments, protective actions are used to prevent undesired leakage during data handling, or exposure of secret information that may be exposed to bus 36 . In some embodiments, the protection action prevents data corruption on the bus or to data stored in SLAVE2, such as unauthorized attempts to modify settings or configuration information stored in SLAVE2.

Host device 24 includes a CPU 60 that executes one or more application programs 64 , and a dedicated device driver 68 . In some embodiments, SLAVE1 includes a security device with dedicated device drivers that provide host device 24 with the functionality needed to implement trusted computing and other security policies. CPU 60 arbitrates between various programs or programs that the CPU executes and may need to access bus 36 , such as application programs 64 and special-purpose device drivers 68 . Applications 64 may include, for example, secure applications that provide secure storage services, eg, system resource control access to stored information.

A dedicated device driver 68 coordinates communications between SLAVE1 and SLAVE2. For example, device driver 68 transparently provides application 64 with indirect access to SLAVE1, SLAVE2. SLAVE1 may need to access SLAVE2 when performing internal tasks or calculations, for example, in order to read data from SLAVE2 or write data to SLAVE2. SLAVE1 may need to access SLAVE2 independently of the application 64 executing on the host device 24. Alternatively, SLAVE1 needs to access SLAVE2 to complete the command issued by application 64.

SLAVE1 may request slave driver 68 to access SLAVE2 in various ways. In one embodiment, SLAVE1 internally prepares the request, eg, in a predetermined register, and generates an interrupt signal to notify the device driver of the read request via bus 36 . In another embodiment, the device driver (68) polls the scratchpad within SLAVE1. to determine if there are pending requests. In yet another embodiment, the device driver 68 conditionally checks the scratchpad value in SLAVE1, eg, in response to the application 64 sending a command (eg, a security command) to the slave device.

When device driver 68 receives a request from SLAVE1 to access SLAVE2, the CPU arbitrates between device driver 68 and other applications (64) and accesses SLAVE2 through bus 36 on behalf of SLAVE1. For example, when SLAVE2 contains non-volatile memory (NVM) or other memory, SLAVE1 may request device driver 68 to access bus 36 to perform data processing, such as (i) from a given non-volatile memory (NVM) address read data, (ii) write data to a given non-volatile memory (NVM) address, (iii) copy data from one non-volatile memory (NVM) address to another non-volatile memory (NVM) address Memory (NVM) address.

Safe method using bus monitoring

Security system 20 may be compromised by an unauthorized attacker, such as tampering with host device 24 . An attacker may, for example, detect the data disposition requested by the controlled device 1 (SLAVE1) from the host, and cause the host to apply to the controlled device 2 (SLAVE2) for a data disposition different from the requested data disposition. For example, for disclosure of confidential information or for unauthorized modification of data, for example, to information stored in SLAVE2. By monitoring the busbar 36, SLAVE1 can detect violations on the busbar and take appropriate protective measures.

In the description of the following embodiments, it is assumed that the data processing performed by the host device 24 through the slave device 2 (SLAVE2) appears on the bus as a sequence of logical values. A sequence corresponding to a given data disposition usually consists of an address part and a data part, ie [address, data]. A sequence of logical values may also include an opcode that identifies the type of data disposition processing, in which case the sequence may be displayed on the bus as [opcode, address, data]. In this example, when SLAVE1 truncates the opcode portion, it can modify (eg, overwrite its logical value) the address portion, the data portion, or both. The opcodes, addresses, and data parts for data handling are also collectively referred to herein as "transaction information."

FIG. 2 is a flow diagram schematically illustrating a method for securing master mediation data handling based on bus monitoring, according to embodiments described herein. The method may be performed, for example, by the processor 44 of the slave device 28 of FIG. 1 . In describing the method, as a non-limiting example, the slave device 28 (SLAVE1 ) includes a safety device, and the slave device 32 (SLAVE2 ) includes flash memory, such as SPI flash memory, - while the busbar 36 includes SPI bus.

The method begins with processor 44 (of SLAVE1 ) booting from flash memory at reset hold step 100 . In one embodiment, processor 44 includes suitable interfaces and circuitry (not shown) to maintain host device 24 in a reset state when accessing flash memory, typically as part of a system startup process. In one embodiment, to load the boot program, the processor 44 loads the data block from flash memory, verifies the authenticity of the data block, and stores the authenticated data block locally in memory 48. The boot mechanism described above to keep the host in reset is not mandatory. In alternate embodiments, other suitable activation methods may also be used.

At data handling request step 104 , the processor 44 requests the device driver 68 of the host device 24 to initiate data handling, which includes accessing flash memory through the bus 36 . The requested data handling may include, for example (i) reading data from a given flash memory address, (ii) writing data to a given flash address, or (iii) copying data from a flash address to a different Flash address.

At monitor step 108, processor 44 monitors bus 36 using interface monitor 56 (IML 56) to intercept the requested data disposition on the bus to verify that the data disposition is performed as expected. For example, in the case of a write disposition - verify that the data specified in the data disposition was indeed written to the address specified in the disposition. The IML monitors one or more bus signals, such as Chip-Select (CS) signals, clock signals, and bus signals that carry data and address information. When the busbar 36 includes an SPI busbar, the interface monitor 56 (IML 56) can output a slave-in (Master-Out Slave-In, MOSI) signal through the master control of the SPI busbar, the master input slave output (Master-Out Slave-In, MOSI) signal In Slave-Out, MISO) signal or both to monitor data and address information.

At step 108, the processor 44 may intercept the requested material disposition on the bus in various ways, eg, based on information in the requested material disposition or other information known to the processor. Note that between the time a data disposition is requested and the time the device driver actually performs the requested data disposition, the host may initiate other data dispositions on the bus initiated by the application 64, which the data disposition processor 44 typically ignores dispose of. In the example embodiment, in the case of a read, write, or copy transaction, processor 44 intercepts address information specific to the requested material transaction. In the case of a write disposition, the processor may intercept the material (or part of that material) to be written.

Further at step 108, in response to intercepting the requested data disposition (or a portion of the data disposition) on the bus, the processor monitors the bus (using IML) to verify that the requested data disposition is performed as expected. For example, the processor verifies that the host accesses flash memory through bus 36 at the address or address range specified in the requested data handle. In write and copy dispositions, the processor can verify that the material to be written or copied matches the material specified in the requested write or copy disposition. The processor may additionally verify that the security policy specified in memory 48 is not violated in performing the requested data handling (or possibly other data handling as well). Additionally, processor 44 may verify that a security policy specified independently of any particular material handling request has not been violated.

In a violation checking step 112 , the processor checks whether a violation is detected on the bus bar 36 . As discussed above, a violation may arise from (i) a violation of a predetermined policy stored in memory 48 (eg, access to a protected address or address range), or (ii) the occurrence of an event in which a bus At least a portion of the intercepted material disposition information on the row is different from the corresponding disposition information in the requested material disposition of step 104 .

When no violation is detected at step 112, processor 44 proceeds to data disposition complete step 116 to complete the data disposition, and loops back to step 104 to request subsequent data disposition by the host. The processor may complete the data disposition by monitoring the bus until the host completes performing the requested data disposition. Alternatively or additionally, the processor performs data handling through the host's device driver. For example, a processor slave device receives data that the device driver has read from flash memory, a completion notification, or both.

In response to detecting a violation at step 112, the processor 44 proceeds to a protection step 120 in which the processor applies appropriate protection actions to prevent leakage or exposure of confidential information. Exemplary protection actions are described below. After step 120, the processor may loop back to step 104 to request the host to initiate subsequent data processing with flash memory via bus 36.

At step 120, the processor 44 may apply various protective actions. In some embodiments, the protective action includes resetting one or more elements of the security system 20 , such as resetting the host device 24 . Alternatively or additionally, the processor destroys the busbar 36, eg, by modifying the logic value of one or more signals on the busbar. , or disconnect the host from the bus.

Methods of modifying busbar signals are described, for example, in US Patent Application Publication 2018/0239727, the disclosure of which is incorporated herein by reference. For example, in some embodiments, bus interface 40 of SLAVE1 drives one or more bus signals of bus 36 in parallel with host device 24 . SLAVE1 can destroy the bus by applying a logic value that overrides the logic value driven in parallel by the host. Overriding of the logic value of the bus signal can be achieved, for example, by using a stronger line driver than the corresponding line driver of the host, or by adding a resistor in series with the bus signal driven by the host to attenuate the signal driven by the host ( Overriding). In another embodiment, the host signal is routed to SLAVE2 through SLAVE1, which masks the logic value of the bus signal as needed. The method for disconnecting the host from the busbar will be described further below.

Example method for securing data handling using bus monitoring and memory devices

The following example embodiments refer to a system configuration in which the controlled device 2 (SLAVE2) includes a memory device, such as a flash memory.

Figures 3 and 4 are flowcharts schematically illustrating methods for secure read and write operations according to embodiments described herein. The methods of Figs. 3 and 4 are executed, for example, by the processor 44 of SLAVE1. Figures 3 and 4 described below may be combined with the method of Figure 2 described above.

The method of FIG. 3 begins at a read process request step 150, where the processor 44 requests the host's device driver 68 to initiate a read process that reads data from a given address in flash memory (SLAVE2) . As described above, at monitor step 154, the processor monitors bus 36 (using interface monitor 56 (IML 56)) to identify requested read transactions being performed by the device driver.

In some embodiments, the read data is disposed on the bus signal as a sequence of logic values representing the starting address for the read, followed by a sequence of logic values representing when one or more locations are read, from the flash The logical value of one or more data units (eg, bit units) retrieved from memory. In an example embodiment, the processor identifies the requested read transaction on the bus by detecting the starting address specified in the requested read transaction.

In response to identifying the read transaction on the bus, the processor continues to monitor the bus at monitoring step 158 to capture logical values on the bus representing the data being read in parallel by the host. The processor captures one or more data units (eg, bytes) specified in the requested read disposition.

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

In the method of Figure 3, SLAVE1 supervises the bus signal during a read process applied to the flash memory by the host. The method of Figure 3 can be used in a similar manner to listen for bus signals during write transactions applied to flash memory by the host. In some embodiments, by listening to the bus, SLAVE1 verifies that the requested data handling is performed as expected.

In the method of FIG. 3, processor 44 performs a desired write operation that writes desired data to desired addresses in flash memory without exposing the written bits to the host address, data or both.

The method of FIG. 4 begins at a dummy write transaction request step 200, where processor 44 requests device driver 68 to initiate a dummy write transaction to flash memory (SLAVE2) via bus 36. A dummy write handles a specified address in flash memory. Flash memory, either a predefined virtual address or an actual address for writing. A dummy write process may specify an opcode and write dummy data to the specified address. A virtual write disposition may appear on the bus as [opcode, virtual address, virtual data]. In this example, the dummy addresses pass over time, and the dummy material follows the dummy material over time.

At monitor step 204, the processor monitors bus 36 (using interface monitor 56 (IML 56)) to identify requested dummy write transactions performed by the device driver. The processor may identify a dummy write transaction on the bus, eg, by detecting the opcode and/or dummy address specified in the requested data transaction on the bus.

In an overriding step 208, the processor overriding the logical values on the bus during virtual write handling, where the logical values represent the desired write operation. To do so, processor 44 overwrites one or more of the dummy write handle's data, address and opcode portions with corresponding values for the desired write operation. As a result, the desired data is written to the desired address in the flash memory. Note that the host is generally unaware of this bus overriding operation, and the data, address and opcode values that need to be written to remain unchanged.

In some embodiments, the processor 44 additionally monitors the bus signals driven by the bus interface when the bus signals are overridden as described above. By monitoring the bus signal, the processor 44 can verify that the expected data was written to the expected address as expected.

In the method of Figure 4, SLAVE1 overwrites the dummy write handle with the desired write handle of the different data and possibly an address in flash memory. The method of Figure 4 can be used in a similar manner to overwrite a dummy write read transaction with a desired read transaction, eg, reading from a desired address in flash memory.

Method for safely accessing slave devices by disconnecting the master from the bus

FIG. 5 is a block diagram schematically illustrating a safety system 250 that supports disconnecting a master device from a bus, according to embodiments described herein. Security system 250 may be used to implement security system 20 of FIG. 1 .

In safety system 250 , master device 24 includes a bus master connected to slave devices 28 ( SLAVE1 ) and 32 ( SLAVE2 ) through SPI bus 254 . The SPI bus includes a clock (CLK) line and two data lines, called master output slave input (Master-Out Slave-In, MOSI) and master input master output Master-In Slave-Out, MISO) . The CLK, MOSI and MISO lines are common to all devices (in this example, master device 24 and slave devices 28 and 32). In addition, each slave can be selected using a dedicated Chip-Select (CS) line. In this example, host device 24 selects SLAVE1 using the CS line denoted CS#1, and selects SLAVE2 using the CS line denoted CS#2.

The host device 24 as a host is connected to all CS lines. On the other hand, each slave is only connected to its own CS line. Typically, the master device 24 initiates data handling by selecting the desired slave device using the corresponding CS lines, and then communicates with that device using the CLK, MOSI and MISO lines. The MOSI line is used for the transfer from the master to the slave, while the MISO line is used for the transfer from the slave to the master.

Unlike traditional SPI slaves, SLAVE1 is defined as a slave, but is still capable of driving the CS line of other devices, such as the CS#2 line of SLAVE2. As can be seen in Figure 5, the bus interface 40 of SLAVE1 is configured to drive the CS#2 line to the host device 24 in parallel. When the system includes multiple slave devices (eg, SLAVE2 ) with respective CS lines, SLAVE1 may be configured to drive any CS line in parallel with the master device 24 .

In Figure 5, the MOSI and MISO lines are connected directly to SLAVE1. On the other hand, MOSI and MISO lines are indirectly connected to SLAVE2 through SLAVE1. In this configuration, SLAVE1 controls whether the host's MOSI and MISO lines are connected to or disconnected from SLAVE2. SLAVE1 includes MISO selector 260 and MOSI selector 262 . Each of the MISO and MOSI selectors includes two input ports and a single output port. At any given time, the processor 44 uses the SEL control input to control the selector to internally connect between its output port and one of its input ports. The MISO and MOSI selectors may be implemented using any suitable circuit elements, such as using multiplexer elements.

When the host device 24 reads data from SLAVE2, SLAVE1 can control the MISO selector to connect the MISO line between the host and SLAVE2, in this case, SLAVE1 can read data on the bus in parallel. Alternatively, SLAVE1 disconnects the host MISO line from SLAVE2 to prevent the read data from being exposed to the host. The processor 44 of SLAVE1 may inject other data into the host MISO line than the data retrieved from SLAVE2.

When the host device 24 writes data to SLAVE2, SLAVE1 can control the MOSI selector to connect the host MOSI line to SLAVE2, thereby allowing the host to write data to the slave device. Alternatively, SLAVE1 uses the MOSI selector to disconnect the host MOSI line from SLAVE2, and processor 44 may inject additional addresses and/or data into SLAVE2 to perform a different write transaction.

In some embodiments, when the MISO selector connects the host MISO line to SLAVE2, SLAVE1 can intercept the host read handle and overwrite the data/address of the read handle. Similarly, when the MOSI selector connects the host MOSI line to SLAVE2, SLAVE1 can intercept the host write disposition and overwrite the data/address of the write disposition.

Figure 6 is a flow diagram schematically illustrating a method of securely accessing a slave device by disconnecting a master from a bus, according to embodiments described herein. The method may be performed by the processor 44 of the slave device 28 (also labeled SLAVE1 in FIG. 5 ) in the safety system 250 of FIG. 5 . In this example, SLAVE1 includes a security device, SLAVE2 includes flash memory, and bus 254 includes an SPI bus. The method of Figure 6 may be combined with the method of Figure 2 above.

The method begins at a data handling request step 300 where the processor 44 requests the device driver 68 of the host device 24 to initiate a dummy write transaction or a dummy read transaction to flash memory. A dummy read or write process specifies an opcode (optional), a real or virtual address in flash memory, and possibly real or dummy data when a write process is performed.

At monitor step 304, processor 44 monitors bus 36 (eg, using interface monitor 56 (IML 56)) to identify requested dummy write or dummy read transactions performed by the device driver. The processor may identify a dummy write or dummy read transaction on the bus, eg, by detecting the flash memory address and/or opcode specified in the requested data transaction.

At disconnect step 308, the processor disconnects the host from the SPI bus in response to identifying the requested data disposition (eg, an opcode based on the data disposition). In the case of a write transaction, the processor uses the MOSI selector 262 to disconnect the host from SLAVE2, and in the case of a read transaction, the processor uses the MISO selector 260 to disconnect the host. Alternatively, the processor may use the MISO selector 260 to disconnect the MISO and MOSI lines. Select both selectors at the same time. In some embodiments, the processor disconnects the host from the bus independently of identifying the requested data disposition on the bus.

Based on whether the data disposition detected at step 304 is a write or read disposition, the processor proceeds to a write step 312 or a read step 316, respectively.

At step 312, the processor writes to the flash memory via the SPI bus, writing the expected data to the expected address, regardless of any data and address transmitted by the host over the MOSI line. In this technique, the processor overwrites the virtual write disposition with the desired write disposition hidden from the host. In some embodiments, in addition to writing to flash memory (eg, in parallel), the processor may 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 desired address of the flash memory via the SPI bus. Since the host MISO line is disconnected from the flash memory, the host remains hidden from the actual data read by the processor. In some embodiments, in addition to (eg, in parallel with) reading from flash memory, the processor also sends other data, such as dummy data, to the host.

After each of steps 312 and 316, the method ends.

The configurations of safety system 20 and master device 24 shown in FIG. 1 , slave devices 28 and slave devices 32 , and safety system 250 in FIG. 5 are example configurations and are shown for conceptual clarity only. Alternatively, any other suitable safety system, master device and slave device configuration may be used. Elements not essential to understanding the principles of the invention, such as various interfaces, control circuits, addressing circuits, timing and sequencing circuits, and debugging circuits, have been omitted from the figures for the sake of clarity.

In the example system configuration shown in Figures 1 and 2, with reference to Figures 1 and 5, CPU 60, slave device 28 and slave device 32 are implemented as separate integrated circuits (ICs). However, in alternative embodiments, at least two of the CPU, slave device 28 and slave device 32 may be integrated in a single Multi-Chip Package (MCP) or System on Chip (SoC) on individual semiconductor dies and can be interconnected by internal busbars. In an example embodiment, the slave device 28 (eg, a controller) and the slave device 32 (eg, flash memory) are implemented in a Multi-Chip Module (MCM). In embodiments where slave device 28 and slave device 32 are implemented within the same package (eg, in an MCM or MCP device), both devices share the same SPI interface lines (eg, MISO, MOSI and CLK). Such an embodiment provides improved security, since attacking or manipulating the signal between two slaves in an attempt to violate the intended function requires an attacker to open the composite device.

The various elements of slave device 28 may be implemented using any suitable hardware, such as in an application specific integrated circuit (ASIC) or a Field Programmable Gate Array (FPGA). In some embodiments, some elements of the slave device 28 may be implemented using software or using a combination of hardware and software elements. For example, in this embodiment, slave interface logic 52 and interface monitor 56 (IML 56) may be implemented as dedicated hardware modules. Memory 48 may include any suitable type of memory and storage technology, such as RAM.

Typically, CPU 60 in master device 24 and processor 44 in slave device 28 each comprise a general-purpose processor programmed in software to perform the functions described herein. The software may be downloaded to the relevant processor in electronic form, eg over a network, or it may alternatively or additionally be provided and/or stored on a non-transitory tangible medium, such as magnetic, optical or electronic memory.

Security system including a cryptographic co-processor

Consider an example configuration of a safety system, such as system 20 in FIG. 1, where master device 24 is connected to slave device 28 (also labeled SLAVE1 in A cryptographic co-processor that acts as the master device 24, and is connected to a slave device 32 (also labeled SLAVE2 in FIG. 1), the slave device 32 comprising the host and cryptographic co-processors -processor) Both external non-volatile memory (NVM) devices. The cryptographic co-processor is also referred to herein as a security device.

The host executes a security application 64, which provides security services by means of a security device. The safety application sends safety commands to the safety device and receives corresponding command responses from the safety device. When servicing a secure application, it is sometimes necessary for the secure device to access the NVM device.

The host implements a dedicated device driver 68 that transparently mediates between the security device and the external NVM device for the security application. The device driver enables the secure device to indirectly access external NVMs through the device driver. After receiving a security command from the host, the security device will execute the security command, which may require access to the NVM device through the bus through a dedicated device driver, transparently to the application.

In some embodiments, for example, when executing a security command requested by the security application, the security device requests the host to initiate data handling for the security device to access the external NVM over the bus. The security device monitors one or more signals on the bus during the time that the host is accessing the NVM device through the bus while performing the requested data processing, and identifies, based on the monitored signals, whether a security violation has occurred in the execution of the request Data handling.

As described in this paragraph, a security system configured with a cryptographic co-processor may apply any of the above-described embodiments to security systems 20 and 250 using bus monitoring techniques.

The embodiments described above are given as examples and other suitable embodiments may also be used. For example, although the above embodiment relates SPI bus, these embodiments are similarly applied to I ² C bus. Further alternatively, the disclosed embodiments are not limited to serial busbars, but are similarly applicable to parallel busbars. In some embodiments, SLAVE1 is connected to the master (possibly but not necessarily as a slave) through a different bus than other slaves (eg, SLAVE2). In such an embodiment, SLAVE1 is also connected to a busbar where the master is connected to other slaves such as SAVE2 to allow busbar monitoring and protection, eg, using the methods and systems described above.

In some of the above-described embodiments, SLAVE1 detects data dispositions by identifying opcodes, addresses, or data elements on the bus. Alternatively, it may be sufficient to detect only a part of such an element. For example, SLAVE1 can detect data dispositions by detecting only a portion of an address element (eg, the most significant portion of a specified 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 busses operating in dual mode or quad mode.

Although the embodiments described herein mainly for SPI and I ² C bus for connecting between the devices, the methods and systems described herein may be used with other suitable types of peripheral bus together, such as enhanced serial peripheral Interface bus (Enhanced Serial Peripheral Interface, eSPI).

Although in the above-described embodiments, SLAVE2 is primarily referred to as a flash memory or NVM device, the methods and systems described herein can also be used in other applications where SLAVE2 can be any other suitable peripheral device, such as a volatile memory or other device in the system. For example, SLAVE2 may include any suitable controller or monitoring device.

It should be understood that the above-described embodiments are cited by way of example and that the appended claims are not limited to what has been particularly shown and described above. Rather, the scope includes combinations and subcombinations of the various features described above, as well as variations and modifications thereof that would occur to one skilled in the art upon reading the foregoing description and which are not disclosed in the prior art. The documents incorporated by reference into this patent application should be considered to be a part of this application, except that the scope of any term is defined in such incorporated documents in a manner inconsistent with any express or implied definition in this specification, consideration should be given to Definitions in this specification.

20: Security System 24: Host device 250: Security Systems 28: Slave device 32: Slave device 36: Serial peripheral interface bus 40: Bus interface 44: Processor 48: Memory 52: Slave Interface Logic 56: Interface monitoring 60: CPU central processing unit 64: Apps 68: Device Driver

Figure 1 is a block diagram schematically illustrating a security system according to embodiments described herein. Figure 2 is a flow diagram schematically illustrating a method for securing master-media material handling based on monitoring, in accordance with embodiments described herein. Figures 3 and 4 are flowcharts that schematically illustrate methods for secure read and write operations in accordance with embodiments described herein. Figure 5 is a block diagram schematically illustrating a safety system supporting disconnection of a master device from a bus bar, according to embodiments described herein. as well as 6 is a block diagram schematically illustrating a method of secure access to a slave device by disconnecting a master from a bus, according to embodiments described herein.

20: Security System

24: Main control device (host)

250: Security Systems

28: Slave device

32: Slave device

36: Serial peripheral interface bus

40: Bus interface

44: Processor

48: Memory

52: Slave Interface Logic

56: Interface monitoring

60: CPU central processing unit

64: Apps

68: Device Driver

Claims (10)

A safety device comprising: A security device provides a security service to a host, wherein the security device, the host and a non-volatile memory (NVM) device external to the security device are coupled to a common bus; and a device driver executes on the host, wherein the device driver is configured to mediate between the secure device and the non-volatile memory (NVM) device, and wherein the secure device is configured to receive a secure command from an application executing on the host , and execute the security command by accessing the non-volatile memory (NVM) device on the bus, transparent to the application through the device driver. The security device of claim 1, wherein a plurality of applications that need to access the common bus are executed on the host, the device driver mediates data handling on the common bus, and the host computer performs data processing on the device driver and other Arbitration is made between the applications attempting to access the bus to access the NVM device on behalf of the secure device coupled to the common bus. The security apparatus of claim 2, wherein the security device requests the device driver in the host to initiate the data handling on the common bus to access the NVM device on its behalf by using an interrupt or poll notification flag technique , and the security device monitors the data processing performed by the host on its behalf on the common bus to ensure that the data processing is performed correctly. The security device of claim 2, wherein between the time the data handling is requested and the time the device driver actually performs the requested data handling, the host initiates the application-initiated program on the common bus an other data disposition that the safety device ignores. The security apparatus of claim 2, wherein the security device monitors the common bus to identify the requested data handling being performed by the device driver. The security apparatus of claim 2, wherein the security device verifies that the host has not been tampered with by comparing data captured directly on the common bus with data indirectly read through the device driver. The security device of claim 2, wherein the security device monitors at least one signal on the common bus during periods when the host is accessing the NVM device through the common bus while performing the requested data processing, and Data processing to identify whether a security violation has occurred during the process of executing the request according to the at least one signal monitored. The security device of claim 1, wherein the NVM device is a read only memory (ROM), a one-time programmable (OTP) memory, an electronically erasable programmable memory Rewrite read-only memory (Electrically-Erasable Programmable Read-Only Memory, EEPROM) or a flash memory. The security device of claim 1, wherein the security device is a cryptographic co-processor. The security device of claim 2, wherein the data processing comprises reading data of the NVM device according to a read address, writing data to the NVM device according to a write address, and interacting with the NVM device according to the read address The write address copies the data of the NVM device to at least one of the other NVM devices.

Images