This subject matter is generally related to secure multi-processor architectures.
Secure integrated circuit cards, commonly referred to as smart cards, are often used in applications where sensitive information is to be stored and shared. Set-top boxes that facilitate pay-per-view or video-on-demand features may use a smart card to supply user account information to a provider along with a request for access to such features, and to subsequently decrypt encrypted digital video streams that may be provided in response to the request. A Subscriber Identity Module (SIM) card in a Global Systems for Mobile Communications (GSM) phone may be used to store a user's personal information, such as his or her phone book, device preferences, preferred network(s), saved text or voice messages and service provider information. Smart cards may be used in a variety of other applications, including but not limited to electronic payment systems, specialized auto-debit devices, personal identification documents, medical identification cards, etc.
Due to security concerns, encryption standards or algorithms may be used to protect sensitive information on a smart card. For example, the Digital Encryption Standard (DES) may be used to encrypt information with a 56-bit key. Access to private data may only be available to a holder of the key. Newer updates to this standard, such as Triple-DES and Advanced Encryption Standard (AES) may offer an even more complex (and secure) encryption key algorithm. Another example standard is RSA (an acronym derived from the surnames of its three creators-Rivest, Shamir and Adleman), a public key encryption standard with private-key decryption. Because of the value of information that may be stored on and protected by a smart card, hackers may employ various techniques to break or bypass various encryption algorithms used to protect sensitive information on a smart card. These techniques may generally be categorized as invasive attacks and non-invasive attacks.
For example, a hacker may grind off a portion of the smart card packaging to access internal signals and bypass security measures that may be in place. As another example, a hacker may subject the smart card to various kinds of radiation (e.g., laser light directed to exposed internal circuits or x-ray or gamma radiation directed through packaging) in an attempt to corrupt protected data. In some implementations, corruption of protected data at certain locations in the device can cause the device to bypass security measures (e.g., encryption algorithms) or to yield information to the hacker regarding device architecture or the protected data itself.
Smart cards can also be subject to attacks such as code reverse engineering. In a reverse engineering attack, the goal of a hacker is to study embedded instructions and data (or “code”) in the smart card memory to clone the smart card functionality on an easily available programming device. Hardware countermeasures such as memory encryption and implanted read-only memories (ROMs) are commonly implemented on secure microcontrollers to prevent such code reverse engineering. However, the smart card's central processing unit (CPU) typically has unencrypted access to the entire program memory contents and can be manipulated to output the entire contents of memory. Once sensitive information has been extracted from a device, the information can be used for various nefarious purposes. For example, a hacker can obtain pay-per-view or video-on-demand services using another user's account, the hacker can access telecommunication services that are billed to another user, the hacker can steal another user's bank account funds; the hacker can steal another's identity, etc.
Conventional smart card systems include a single processor to manage sensitive tasks and non-critical tasks such as data exchange with external systems. These conventional smart cards use hardware (e.g., a hardware firewall) and software protections to provide a secure barrier between sensitive and non-critical tasks. This barrier, however, is subject to hacker attacks with the intention of extracting critical information (e.g., cryptographic keys).
A secure communication interface for a secure multi-processor system is disclosed. The secure communication interface can include a secure controller that is operable to transfer data between a first memory that is directly accessible by a first (master) processor and a second memory that is directly accessible by a secure second (slave) processor in the multi-processor system. One or more control and status registers accessible by the processors facilitate secure data transfer between the first memory and a memory window defined in the second memory. One or more status and violation registers shared by the processors can be included in the secure communication interface for facilitating secure data transfer and for reporting security violations based on a rule set.
The secure communication interface provides a secure communication path between one or more secure, slave processors and associated data memories for processing and storing sensitive information, and one or more master processors and associated data memories for processing and storing requests from external systems. The secure communication interface prevents a master processor from directly reading or modifying data in a memory directly accessible by a secure, slave processor or to dump secure program code from the memory when attacked by an external system.
The secure communication interface prevents a slave processor from transferring secure data to an external system when attacked by an external system.
The secure communication interface performs fast and secure data transfer between master and slave processors without using the processors' resources, thus the processors can perform other tasks or operations in parallel with the data transfer.
In some implementations, the master CPU 102 and/or the slave CPU 104 include intrusion prevention systems 110 (“IPs”) that can be customized to specific applications. An analog block 112 can include general analog hacker safeguards, such as a frequency monitor, a power supply monitor, a temperature sensor, and a voltage regulator. The master CPU 102 can include one or more microprocessor cores 124 and program and data memory 126 (hereinafter also referred to as “data memory 126”), and the slave CPU 104 can include one or more microprocessor cores 122 and program and data memory 114 (hereinafter also referred to as “data memory 114”)
The slave CPU 104, which handles sensitive information, can be protected by a hardware shield that includes protections that isolate the slave CPU 104 from the master CPU 102 or from external systems. A separate power supply 116 can provide galvanic isolation from the external system's power supply but also from the master CPU 102 and the remainder of the chip power supply. The separate power supply 116 prevents power glitches applied on an external pin from propagating to the slave CPU 104. A separate clock system 118 prevents clock glitches from propagating to the slave CPU 104 and allows the slave CPU 104 to participate in anti differential power analysis counter measures. A separate program and data memory 114 in the slave CPU 104 prevents the master CPU 102 from reading or modifying sensitive information on the slave CPU 104 directly or when under attack. In some implementations, the data memory 114 can include parity bits which allow for the detection of fault injection attacks on the data memory 114. Dedicated analog sensors 120 monitor the slave CPU 104's environmental conditions for signs of attack. A physical shield (e.g., a metallic cover not shown) enclosing the slave CPU 104 and, optionally, the master CPU 102, can reduce the likelihood that a hacker will gain access to internal signals or subject the slave CPU 104 to various kinds of radiation in an attempt to corrupt sensitive information.
In some implementations, data exchange between the master CPU 102 and the slave CPU 104 can be managed through the secure communication interface 108. The master CPU 102 can also place processing requests for the slave CPU 104 through the secure communication interface 108. Such requests can be received “as is” from external systems and the master CPU 102 would, in this case, be used as a simple mailbox. In some implementations, the master CPU 102 has no access to processing methods or information within the slave CPU 104. The slave CPU 104 processes the request and transfers results (if any) to the master CPU 102 through the secure interface 108.
In some implementations, the secure communication interface 108 can also include status registers, control registers, or combinations of these, as described in reference to
In some implementations, a secure communication protocol is implemented to guarantee a secure communication between the master CPU 102 and the slave CPU 104 over the secure communication interface 108. Data sent by the master CPU 102 to the slave CPU 104 through the secure interface 108 can be signed to allow the slave CPU 104 to verify the integrity of the data before processing the data. Moreover, data sent by the slave CPU 104 to the master CPU 102 can likewise be digitally signed. In some implementations, a request from the master CPU 102 to the slave CPU 104 is encrypted with keys known by the slave CPU 104. Similarly, responses to requests can be digitally signed, encrypted or both and returned to the master CPU 102 for transmission to external systems, such that the master CPU 102 acts as a passive conduit between the slave CPU 104 and the external systems.
An interface 211 provides a means for the smart cards 201A or 201B to interact with external systems, such as, for example, a smart card reader 214A or 214B. In some implementations, the interface 211 works in conjunction with a wireless communication channel 217A that includes, for example, radio frequency (RF) signals that are adapted for a particular communication protocol (e.g., a protocol characterized by ISO/IEC 14443 or ISO 15693). In some implementations, the interface 211 works in conjunction with a wired communication channel 217B that is adapted for a particular communication protocol (e.g., a protocol characterized by ISO/IEC 7816 or ISO/IEC 7810).
The smart cards 201A or 201B are powered by a power source. For example, the smart card 201A can be powered by an integrated power storage device 220, such as a battery or low-loss capacitor. As another example, the smart card 201A can be powered by an antenna and conversion circuit 223 that receives RF signals and converts energy in the RF signals to electrical energy that can be used to power the components of the smart card 201A. As another example, the smart card 201B can be powered by a source that is external to the smart card itself, such as a power supply 226 that is integrated in a corresponding smart card reader 214B.
In operation, the smart card reader 214A or 214B can request protected information from the smart card 201A or 201B, respectively. In some implementations, the smart card reader 214A or 214B provides an encryption key for the smart card 201A or 201B to use in encrypting the protected information before transmitting it to the reader 214A or 214B. In some implementations, the protected information is already stored in encrypted form, and the smart card 201A or 201B provides a decryption key for the smart card reader 214A or 214B to use in decrypting the protected information. In some implementations, the smart card 201A or 201B performs other operations on the protected information. Smart cards can also include other intrusion prevention systems such as timers, cryptography processors, cryptography accelerators, etc.
In some implementations, the master CPU 102 and the secure slave CPU 104 exchange requests (e.g., interrupt requests) through the secure communication interface 108, which is responsible for managing communication between the two processors. The control and status registers 408, 410, located in the master CPU 102 and secure slave CPU 104, respectively, allow each processor to send a request to the other processor.
In conventional single processor systems, data transfer is often performed by a single CPU using move software instructions. This method, however, can be subject to fault injection attacks (e.g., laser attacks, glitch attacks) that can change the address operand of move instructions and then force the CPU to transfer sensitive information to an external system. The secure communication interface 108 addresses this security flaw by controlling data transfer between the slave CPU 104 and the master CPU 102. For example, data transfer can be supervised by the slave CPU 104 which can terminate the transfer using a transfer enable control signal or other mechanism. The secure controller 402 makes data exchange more secure as the hardware secure communication interface 108 is more robust to fault injection attacks than software move instructions used by convention secure systems. Moreover, data transfer between processors in a multi-processor system can be digitally signed or otherwise encrypted to increase data transfer robustness.
To increase immunity of the slave CPU 104 to external attacks, software data moved from the slave CPU 104 to the master CPU 102 can be physically forbidden by set of rules. A first rule specifies that data memory 126 directly accessible by the master CPU 102 must not be accessible by (“visible”) to the slave CPU 104. For example, the program code executed by the slave CPU 104 cannot be allowed to fetch instructions or read data from the data memory 126 directly accessible by the master CPU 102. Likewise, the slave CPU 104 cannot use software instructions to transfer sensitive information to external systems, except for reading and writing to a status register 404 and a violation register 406 in the secure communication interface 108 which are shared between the processors 102, 104. Only the secure controller 402 can access the data memory 114 of the slave CPU 104 for data exchange operations. Second, the data memory 114 of the slave CPU 104 must not be directly accessible by the master CPU 102. For example, the program code executed by the master CPU 102 cannot address the data memory 114 of the slave CPU 104. Based on these foregoing rules, the slave CPU 104 cannot directly access the data memory 126 of the master CPU 102. Likewise, the master CPU 102 cannot directly access the data memory 114 of the slave CPU 104.
In some implementations, the secure controller 402 can be configured in emission mode or receiving mode. In emission mode, the secure controller 402 can read the data memory 114 of the slave CPU 104 and write the data memory 126 of the master CPU 102. In receiving mode, the secure controller 402 can read the data memory 126 of the master CPU 102 and write the data memory 114 of the slave CPU 104. The secure controller 402 can be controlled by Input/Output (I/O) control registers as described in reference to
A register ADR1 is the base address of the data memory 126 of the master CPU 102. In receiving mode, the ADR1 register stores the first address location of the data memory 126 that the secure controller 402 will read. In emission mode, the register ADR1 stores the first address location that the secure controller 402 will write. The last address read or written will be “ADR1+Nb−1.”
A register ADR2 is the base address of the data memory 114 of the slave CPU 104. In emission mode, the register ADR2 stores the first address location of the data memory 114 that the secure controller 402 will read. In receiving mode, the register ADR2 stores the first address location that the secure controller 402 will write. The last address to be read or written will be “ADR2+Nb−1.”
Registers ADR2max ADR2min represent high and low addresses (“limits”) of the data memory 114, respectively. These limits are accessible in read and write modes to the slave CPU 104 only. These limits allow the slave CPU 104 to define a memory window in the data memory 114 which will be reserved for the secure controller 402 during a data transfer. During data transfer, any fault injected into the current address to make it point outside the memory window defined by the contents of registers ADR2max ADR2min can be detected by the secure controller 402 and reported through the violation register 406, and/or other security action taken by one or both of the processors 102, 104 or the security controller 402.
For security reasons, the control and status register 408 of the master CPU 102 can be written and read by the master CPU 102, but read only by the slave CPU 104. Likewise, the control and status register 410 of the slave CPU 104 can be written and read by the slave CPU 104, but read only by the master CPU 102. When the master CPU 102 is ready to transfer data to the slave CPU 104, the master CPU 102: sets the base address ADR1 in data memory 126; sets the number of bytes Nb to be transferred or emitted; and sets a direction bit MDIR to indicate a direction of data transfer from the master CPU 102 to the slave CPU 104. The master CPU 102 then sends a transfer request to the slave CPU 104 by setting the MRQ bit and MDIR bit (e.g., set to “1”) in the control & status register 408. Setting the MRQ and MDIR bits causes an interrupt of the slave CPU 104 to be automatically triggered to inform the slave CPU 104 that a request from the master CPU 102 is pending. The slave CPU 104 can then fill the ADR2max ADR2min registers, and set the transfer enable bit STEN in the control & status register 408 to start the data transfer.
In emission mode, the slave CPU 104 sets the ADR2, ADR2max, ADR2min/ and Nb registers and sets the SDIR bit in the control & status register 410. The slave CPU 104 then sends a transfer request to the master CPU 102 by setting the SRQ bit in the control & status register 410. Setting the SRQ and SIR bits causes an interrupt of the master CPU to be automatically triggered to inform the master CPU 102 that a transfer request from the slave CPU 104 is pending. The master CPU 102 can then read the Nb register, set the ADR1 register and set the transfer enable bit MTEN in the control & status register 110 to start the data transfer.
In some implementations, the security violation register 406 in the secure communication interface 108, which is accessible by the processors 102, 104, can be used to report security violations. Security violations can occur, for example, when both MTEN and STEN are set (e.g., set to “1”) or both MDIR and SDIR are set (e.g., set to “1”). These example bit states represent security violations because the bit states indicate that the processors 102, 104 have attempted to perform a data transfer at the same time. Other bit states using various numbers of bits are also possible.
In emission and receiving mode, the secure controller 402 can start the data transfer (e.g., when one of MTEN or STEN is set) if a rule set is complied with. Otherwise, a security violation can be triggered and the current data transfer can be automatically aborted. An example rule set can include a first rule that the slave base address ADR2 must be located in the memory window defined by ADR2max, ADR2min, and a second rule that “ADR2+Nb” must be less than ADR2max. Other rule sets are also possible including rule sets with more or fewer rules.
In some implementations, the secure controller 402 can include an internal counter (not shown). When a data transfer starts, the internal counter (which is not accessible to the processors 102, 104) counts the number of data transferred and triggers a security violation if the counter exceeds Nb. A security violation can be generated if during the data transfer, the current address of the data memory 114 of the slave CPU 104 is higher than ADR2max or higher than “ADR2+Nb” or lower than ADR2min.
Thus, a fault injected during the configuration of the secure controller 402 or during data transfer will be detected through the violation register 406 in the secure communication interface 108. The slave CPU 104 can disable the data transfer operation using the “transfer enable” signal described in reference to
In some implementations, data values that are subject to data transfer are not protected. For such implementations, the data values can be protected using a data signature mechanism, which can be implemented using a communication protocol, as described below.
Data packets exchanged between processors 102, 104 through the secure controller 402 can follow a data format that, in some implementations, includes at least three fields. A first field is Data Length. The Data Length field defines the number of data that are subject to data transfer. A second field is Data Content. The Data Content field includes the data values to be transferred. A third field is Data Signature. The Data Signature field (e.g., a Cyclic Redundancy Check (CRC) field) represents the signature of the combined Data Length and Data Content fields. The command type can be part of the Data Content field. After checking the request (e.g., checking the data signature of the Data Length and Content fields), the slave CPU 104 generates an acknowledge flag (e.g., a flag stored in shared status register 404) reporting the result of the request checking. If the request checking is successful, the slave CPU 104 processes the request and returns the result of the processing through the secure communication interface 108.
A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made. For example, elements of one or more implementations may be combined, deleted, modified, or supplemented to form further implementations. As yet another example, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims. For example, each claim can recite a separate implementation and combinations of claims can recite separate implementations.
This subject matter is generally related to U.S. patent application Ser. No. 11/558,367, for “Bi-Processor Architecture For Secure Systems,” filed Nov. 9, 2006, which patent application is incorporated by reference herein in its entirety.