Message authentication with secure code verification

Abstract

System, comprising: a client device (120) that stores a code; and a security device (118) coupled to the client device (120) and configured to: Selecting a plurality of memory address ranges of an authorized code; determining a corresponding portion of the authorized code for each of the plurality of memory address ranges; Calculating a corresponding first property of each determined portion of the authorized code; Storing first information indicating the corresponding first properties of the parts of the authorized code and second information indicating the respective memory address ranges in the security device; and Linking memory address ranges from the plurality of memory address ranges with first properties from the first properties of the parts, Receiving a first property of the code generated by the client device (120); Checking the correctness of the first property of the code based on information associated with the authorized code to determine that the code is authorized, the information being stored in the security device; in response to determining that the code is authorized, enabling the security device to access initial secret data stored in the secure memory of the security device; and Generating a second property of a first message based on the first secret data; wherein the client device (120) is for: Receiving the second property of the first message from the security device (118); generating the second property of a second message based on second secret data stored in the client device (120), the second secret data corresponding to the first secret data stored in the security device (118); Determining whether the second property of the second message is valid based on a comparison of the second property of the second message and the second property of the first message; and Determining whether to execute an application on the client device (120) using the code based on a result of determining whether the second property of the second message is valid.

Description

[0001] This disclosure relates generally to security techniques, particularly to message authentication with secure code verification.

[0002] In an example scenario, a method for authenticating messages between devices is implemented. A client device generates a message authentication code (MAC) by applying a hash algorithm to a message with a shared secret stored on the client device, and transmits the message along with the MAC to a host device. The shared secret is also stored on the host device. The host device verifies the message by generating a MAC using the received message and the stored shared secret. If the received MAC and the generated MAC are the same, the message is authenticated. However, an attacker could fake the secure boot of the client device and still use the message authentication method to make a fake system work properly, e.g.communicates with the host device, which may cause fraudulent operation.

[0003] US 2009 / 0 232 301 A1 discloses network communication using a session key. US 2002 / 0 087 873 A1 describes the provision of execution permissions for a program installed on a computer. To protect computers from malware, US 2015 / 0 082 304 A1 describes a virtual machine manager for verifying the integrity of code in memory. DE 10 2013 215 970 A1 relates to the verification of the use of a client device by a host device in a secure system. US 2013 / 0 217 332 A1 concerns the localization of a wireless ID transmitter based on radio identification packets.

[0004] The object of the invention is to provide methods, circuits, and computer-readable media for message authentication with secure code verification. In one aspect, a system includes a client device storing a code and a security device coupled to the client device. The security device is configured to receive a property of the code generated by the client device, verify the correctness of the property of the code based on information associated with the code, and determine that the code is an authorized code, the information stored within the security device. In response to determining that the code is the authorized code, the security device enables access to the data stored within the security device and generates a property of a message based on the data.

[0005] The details of one or more of the disclosed implementations are explained in the accompanying drawings and the description below. Other features, aspects, and advantages will be apparent from the description, drawings, and claims. Short description of the drawings Fig. 1 is a diagram of an example environment according to an example embodiment. Fig. 2 is a diagram of an example system including an example security device and an example client device, according to an example embodiment. Fig. 3 is a flowchart of an example process by which a security device performs message authentication with secure code verification for a client device, according to an example embodiment. Fig. 4 is a flowchart of an example process by which a security device performs message authentication with secure code verification for a client device, according to another example embodiment. Fig. 5 is a flowchart of an example process by which a security device performs message authentication with secure code verification for a client device, according to another example embodiment. Fig. 6 is a flowchart of an example process by which a security device performs message authentication with secure code verification for a client device, according to another example embodiment. Fig. 7A is a flowchart of an example process by which a security device verifies the authenticity of firmware, according to an example embodiment. Fig. 7B is a flowchart of another example process by which a security device stores information of a portion of firmware, according to an example embodiment. Fig. 8 is a flow diagram of an example process by which a security device performs message authentication with secure partial verification for code stored within a client device, according to an example embodiment. Fig. 9 is a flowchart of an example process by which a security device performs message authentication with secure partial verification for code stored within a client device, according to another example embodiment. Detailed descriptionSystem overview

[0006] Fig. 1 is a diagram of an example environment 100 according to one implementation. For illustrative purposes, the environment 100 includes a system 116 (e.g., a client-side system) that includes a security device 118 and a client device 120. The security device 118 is configured to verify (or validate) whether code stored within the client device 120 is authorized (or authenticated). In some examples, the code includes boot code for a client device 120 to boot (or power up), application firmware for the client device 120 to execute the application, or operational code for the client device 120 to perform a corresponding operation.

[0007] During code verification, the security device 118 performs an action. In one embodiment, during code verification, the security device 118 enables the client device 120 to perform message authentication. The security device 118 enables access to and use of secret (or private) data (e.g., information or values) stored in the security device for message authentication. In one embodiment, during code verification, the security device 118 enables changing the state of a port (pin) of the security device 118. The port may enable (or indicate or enable) a component in the system 116. In one embodiment, during code verification, the security device 118 enables subsequent operations to be performed on the security device 118 that may not be enabled without code verification.In one embodiment, during code verification, the security device 118 enables access to or use of secret / private information on the security device 118, e.g., reading (or writing) a value. In one embodiment, during code verification, a computation unit is enabled, e.g., by the security device 118, so that it is available for use. In one embodiment, during code verification, an I / O channel on the system 116 is activated for use, e.g., for another use. In one embodiment, during code verification, a timer is reset to allow the system 116 to run much longer than intended or normal before a next check takes place.

[0008] The security device 118 is coupled to the client device 120 via a connection 119. In some implementations, the security device 118 and the client device 120 are in close proximity to each other, and the connection 119 is established via a data cable (e.g., a fiber optic cable or an electrically conductive cable) or wirelessly. In some other implementations, the security device 118 and the client device 120 are physically coupled, and the connection 119 is a hardware interface, such as a PCI interface on a motherboard. In other implementations, where the security device 118 and the client device 120 are integrated on a common circuit board, the connection 119 is a conductor. The security device 118 and the client device 120 may be separate chips and integrated on the same circuit board.

[0009] In one embodiment, as discussed in detail below, the system 116 is further configured to communicate with one or more remote devices or systems (host device 112, computing devices 106a, 106b, and / or server computer system 108) over a network 102. Indeed, in one embodiment, the system 116 is a client of the network 102, and the security device 118 and the client device 120 are therefore "locally" coupled to each other on the client side. The host device 112, the computing devices 106a, 106b, or the server computing system 108 is a host of the network 102, which is remotely coupled to the system 116 on the host side. The network 102 may be an external network to the system 116, e.g., a public communications network (e.g.,the Internet, cellular data network, dial-up modems over a telephone network), a WAN (wide area network), a LAN (local area network), a CAN (controlled area network), a private communications network (e.g. private LAN, leased lines) or any suitable combination thereof.

[0010] In some implementations, client device 120 communicates with the remote devices via security device 118. Security device 118 can encrypt messages transmitted from client device 120 with secret data (or keys) and send the encrypted messages to the remote devices. The remote devices validate the encrypted messages with appropriate secret data or keys and, based on the validation result, determine whether the messages from client device 120 are authenticated or not. In some other implementations, client device 120 communicates directly with the remote devices via network 102. Security device 118 ensures that client device 120 performs secure boot, applications, or operations.

[0011] In some cases, the client device 120 is not secured or lacks security, e.g., due to cost constraints. An attacker may attack the client device 120, e.g., to modify the codes stored within the client device 120 for fraudulent purposes, to spoof the client device 120 to communicate with the host-side devices, to determine the code validation method and generate fraudulent code, or to publish a simpler method for attacking the client device 120. In some implementations, the security device 118 is a reliable or secured device, as described in connection with Fig. 2. To address these security issues with security device 118, security device 118 is coupled to client device 120 and configured to first verify whether codes (e.g., application firmware) stored within the client device are authorized codes. Code verification may be performed as described in U.S. patent applications 15 / 044,693 and 15 / 044,770, both entitled "CONTROLLED SECURE CODE AUTHENTICATION" and filed February 16, 2016, the contents of which are hereby incorporated by reference in their entirety.

[0012] If the security device 118 determines that the code is unauthorized code, the security device 118 determines that the boot or the application (or operation) running on the client device 120 is not secured. The security device 118 is then placed in a secure mode, which, for example, prevents or restricts the security device 118 itself from accessing critical information, such as secret data or cryptographic keys stored in secure storage. The secure storage may be contained within the security device 118 or coupled externally to the security device 118. In this way, fraudulent operations can be minimized or eliminated, and the security of the client device 120 can be enhanced.

[0013] In some implementations, in response to determining that the code is authorized, the security device 118 enables access to critical information, such as secret data. The security device 118 may then use the secret data to protect a message associated with the client device 120. In some examples, the security device 118 receives the message from the client device, which is directed to a remote device, such as the host device 112, the computing devices 106a, 106b, or the server computing system 108. The security device 118 performs message authentication with the remote device. For example, the security device 118 may generate a MAC using the message and the secret data and transmit the message with the MAC to the remote device. The remote device also contains secret data corresponding to the secret data stored in the security device 118.The remote device verifies the message by generating a MAC using the received message and the stored shared secret. If the received MAC and the generated MAC are the same or match, the remote device determines that the message is authenticated and trusts the message from the client device. Otherwise, the remote device determines that the message is not authenticated and does not trust the message from the client device.

[0014] In some examples, the security device 118 performs message authentication with the client device 120, which may be used to control, boot, or execute an application on the client device. In one embodiment, the security device 118 performs message authentication with the client device 120 using a symmetric scheme or algorithm. The security device 118 may receive a digest of the code stored in the client device 120. After verifying the code, the security device 118 uses the digest of the code (and / or a nonce) as a message, generates a MAC using the message and the secret data, and transmits the MAC to the client device 120. The client device 120 generates the MAC using the digest of the code and / or the nonce and the same secret data stored in the client device 120.If the two MACs match, client device 120 executes an application that uses the code or proceeds with booting. Otherwise, client device 120 prevents itself from executing the application or booting. In this way, the function of client device 120 is controlled by the result of message authentication, which in turn is controlled by the result of code verification. Other symmetric schemes (or algorithms) can also be used for message authentication.

[0015] In another embodiment, security device 118 performs message authentication with client device 120 using an asymmetric scheme or algorithm. For example, client device 120 computes a signature generation operation, and security device 118 performs a signature verification operation. Other asymmetric (or differential) schemes (or algorithms) may also be used for message authentication.

[0016] In one example, security device 118 includes secure memory. Security device 118 stores information associated with authorized code for client device 120 in the secure memory. In some implementations, the information includes a full image of the authorized code, a signature of the authorized code, a digest of the authorized code, a message authentication code (MAC) of the authorized code, or other properties of the authorized code. In some implementations, the information includes properties of a variety of options of the authorized code, e.g., a digest or signature or MAC for each part, or an address range for each part.In some implementations, the information does not contain the entire image of the authorized code, but only the excerpt or the signatures or MACs of portions of the authorized code and corresponding address ranges. In some examples, the security device 118 stores cryptographic keys to verify the authenticity of the code stored in the client device 120.

[0017] Security device 118 and client device 120 can download and / or update images of the respective authorized code from a source. This source can be a secure source (e.g., secure hardware or a secure server) or a non-secure source. Security device 118 can verify a signature or MAC of the entire code image before downloading or updating the stored information of the code image.

[0018] In some implementations, host device 112 is a controller that communicates with system 116 and one or more subsystems. Each subsystem includes a client device and a security device coupled to the client device. The security device is configured to perform secure code authentication and / or message authentication for the client device.

[0019] In some implementations, users 104a, 104b use computing devices 106a, 106b to communicate with system 116 over a network 102. The computing devices 106a, 106b may each be a computing device, such as a mobile device, a laptop computer, a desktop computer, a smartphone, a personal digital assistant, a portable media player, a tablet computer, or any other computing device used to communicate with system 116. For illustration purposes, Fig. 1, computing device 106a is depicted as a mobile device, and computing device 106b is depicted as a desktop computer. User 104a or 104b may be an entity connected to system 116. User 104a or 104b may use computing device 106a or 106b to check a status of system 116 or to remotely control an operation of system 116 via network 102. For example, user 104a or 104b may use computing device 106a or 106b to verify whether the code stored within client device 120 is an authorized code for client device 120 and to exchange messages with client device 120.

[0020] In some implementations, server computing system 108 communicates with system 116 over network 102. Server computing system 108 includes one or more computing devices and one or more machine-readable repositories or databases. Server computing system 108 is configured to communicate with a number of systems, including system 116. For each system, server computing system 108 can securely store corresponding authorized codes for the respective client devices and security devices within the system. The client devices and security devices can download the corresponding authorized codes from server computing system 108 over network 102. A user 109, e.g., an administrator or an operator, of server computing system 108 can use server computing system 108 to communicate with a single system, such as system 116.

[0021] The disclosed implementations may be used in different environments. In some implementations, environment 100 is a vehicle environment. System 116 may be a control unit (e.g., an ECU) for a component in the vehicle, e.g., a window control unit, a brake control unit, or a wheel control unit. Host device 112 may be a central computing system of the vehicle, e.g., an electronic control unit (ECU), or a gateway for forwarding messages from the client device to a remote computing device, e.g., server computing system 108, or computing devices 106a or 106b. User 104a or 104b may be the owner of the vehicle and may communicate with the vehicle using a cellular phone 106a or a computer 106b over network 102.The server computing system 108 may be a server configured to control a series of vehicles and may be associated with an entity, such as a vehicle manufacturer, a vehicle dealer, or a company. It should be understood that the disclosed implementations are not limited to the vehicle environment and are applicable in other contexts. For example, the system 116 may be included in a device such as a light, an alarm system, a garage door opener, or a sensor of a home network.

[0022] In some examples, a digest is associated with a cryptographic hash function. A device, e.g., security device 118 or client device 120, takes a block of data, e.g., code, a program, or firmware, and uses the cryptographic hash function to compute a string, where the string is the (cryptographic) hash value. The data to be encoded may be referred to as a "message," and the hash value may be referred to as a "message digest" or simply a "digest." The cryptographic hash function may, for example, include a secure hash algorithm (SHA), such as SHA1, SHA2, SHA3, SHA-256, or an MD5 message digest algorithm. The generated digest may have a fixed length or a variable length. However, the present technique is not limited to implementing such an example algorithm, and other types of hash functions may be implemented.

[0023] In some examples, a signature is a mathematical scheme for proving the authenticity of a digital message, e.g., a digest of a code. The signature may be generated by a digital signature algorithm (DSA), e.g., ECDSA (Elliptic Curve Digital Signature Algorithm). A device may use the DSA to calculate or generate a signature of a digest using the digest and a key, e.g., a private key or a public key. However, the present technique is not limited to implementing such an example algorithm, and other types of signature algorithms may be implemented.

[0024] In some examples, a message security code (MAC) is a piece of information used to authenticate a message. An algorithm accepts a secret key and a message to be authenticated as input and outputs a MAC. The algorithm can be, for example, an HMAC (keyed-hash message authentication code) or an AES (Advanced Encryption Standard) CMAC (Cipher-based Message Authentication Code) (AES-CMAC) algorithm, or one of many others.

[0025] In some examples, a checksum (or hash sum) is a small piece of information extracted from a block of digital data (e.g., a code) for detecting errors that may have occurred during its transmission or storage. The checksum can be used to verify data integrity. A checksum can be generated by a checksum algorithm or a checksum function.

[0026] In some implementations, authorized code for a device represents original code without changes or modifications, such as those intended by an OEM (Original Equipment Manufacturer) of the device or an entity associated with the device. A code is authorized code if it is unchanged or unmodified and is unauthorized code if it is altered or modified. An OEM signature of authorized code is a signature generated by the manufacturer using the authorized code and an OEM private key.

[0027] In some examples, secrets or data are information known only to a specific device or system, but unknown to other devices or systems. An example type of secret is an I / O protection secret, which is generated on one or the other device when a PC board is manufactured and written to persistent memory on both devices, e.g., a security device and a client device. The I / O protection secret can be generated by an RNG, by a security set during device manufacturing, or stored in a metal layer of a chip, or implemented through other options.The essential properties of the I / O protection secret may include: 1) each board has a unique I / O protection secret shared between the client device and the security device; 2) it is difficult for any entity to determine a value of the I / O protection secret for this board, which means confidentiality. Example security and client devices

[0028] Fig. Figure 2 is a block diagram of an example system 200 according to one embodiment. An example security device 202 performs secure code authentication and message authentication for an example client device 204. The system 200 may be similar to the system 116 of Fig. 1. The security device 202 may be similar to the security device 118 of Fig. 1. The client device 204 may be similar to the client device 120 from Fig. 1. The security device 202 is coupled to the client device 204 using a connection 208.

[0029] Connection 208 can be assigned to connection 119 from Fig. 1. The connection 208 is, for example, a physical transmission bus or a transmission cable (or other communication medium) to which components of the security device 202 and the client device 204 are physically or communicatively coupled. In one embodiment, the security device 202 and the client device 204 are placed in close proximity to each other, and the connection 208 is either wireless or via a data cable (e.g., an optical fiber cable or an electrically conductive cable). In some other embodiments, the security device 202 and the client device 204 are physically coupled, and the connection 208 is a hardware interface, such as a PCI interface on a motherboard. In other embodiments, where the security device 202 and the client device 204 are integrated on the same circuit board, the connection 208 is a conductor.The security device 202 and the client device 204 may be separate chips and integrated on the same circuit board.

[0030] The client device 204 may be unprotected or lack a certain level of security. For example, the memory 222 in the client device 204 is unprotected, and the code stored in the memory 222 and / or associated information may be modified by an attacker. The security device 202 is configured to first verify whether the code stored in the client device 204 is authorized code. During verification, the security device 202 performs message authentication for the client device 204.

[0031] In some implementations, the security device 202 includes, among other things, a cryptographic (crypto) module 212, a random number generation module 214, a secure memory 216, and an authentication module 218. In one embodiment, the cryptographic module 212, the random number generation module 214, the secure memory 216, and the authentication module 218 are different programs, subprograms, or pieces of code stored within one or more storage devices within the security device 202. These modules therefore do not have to be separate physical components, but can be software modules. In some implementations, the secure memory 216 is external to the security device 202 and is connected to the security device 202 via a protected or secure channel. The secure memory 216 can, for example, be located in a trusted third-party entity. The security device 202 can retrieve information from the secure memory 216.

[0032] The cryptographic module 212 is configured to generate cryptographic properties of code or messages and to perform cryptographic functions. The cryptographic module 212 may generate a digest, a signature, a message authentication code (MAC), or a checksum for the codes or messages. In some implementations, the cryptographic module 212 performs encryption and / or decryption (or decryption) functions. For example, the client device 204 encrypts the code stored within the client device 204. The cryptographic module 212 may decrypt the encrypted code to obtain the original code.

[0033] In some implementations, the cryptographic module 212 generates a challenge for the client device 204, e.g., different challenges at different times. A challenge includes a query to the client device 204 requesting a property of a code (or a portion of such code) stored in the client device 204. The property may be a cryptographic property, e.g., a digest, a signature, a checksum, or a MAC. A challenge may also include a request for a property of a specific portion of the authorized code. In some examples, the specific portion corresponds to a memory address range (physical or virtual), e.g., an address pair containing a start address and an end address, a middle address with a width, a start address with a width, or an end address with a width.The challenge may contain the address range to specify the specific portion. In some implementations, a challenge contains information associated with cryptographic or authentication keys for secure authorization and / or authentication.

[0034] The random number generation module (RandGen) 214 is configured to generate a random number, for example, used as a seed for cryptographic operations performed by the security device 202. The random number generation module 214 may include, for example, a random number generator (RNG) that returns a specific number of random bytes (e.g., 32 random bytes) to the cryptographic module 212. In one embodiment, the random number generation module 214 generates a nonce for direct use from an RNG. In one embodiment, the cryptographic module 212 combines this generated random number with a separate input number to generate a cryptographic "nonce" that is stored within the security device 202 and can be used for subsequent commands. In one embodiment, a protocol nonce is a combination of a nonce from a client device and a nonce from a security device.The protocol nonce can be used for cryptographic operations.

[0035] In some examples, a nonce is an arbitrary number used only once in a cryptographic communication between devices. The nonce can be a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in a replay attack. A nonce can also be used to ensure the security of a stream cipher. To ensure that a nonce is used only once, it can be time-dependent (e.g., by including a suitable, fine-grained timestamp in its value) or generated with sufficiently random bits to make the probability of repeating a previously generated value sufficiently small.

[0036] The secure storage 216 is configured to store secure information, including information about an authorized code for the client device 204, secret data 215, and / or keys 217. The secret data 215 includes, for example, the I / O protection secret that the security device 202 can use to protect messages. The keys 217 can include a symmetric cryptographic key or an asymmetric cryptographic key for authentication or cryptographic functions. The keys 217 can include, for example, an OEM public key corresponding to a private key used to generate an OEM signature of an authorized code corresponding to the code stored in the client device. The security device 202 can use the OEM public key to generate a signature of a digest of the code stored within the client device 204.The secret data 215 and / or keys 217 may be stored in the security device 202 during a phase of the security device 202, such as manufacturing, factory initialization, personalization, or distribution.

[0037] In some implementations, the information about the authorized code stored in the security device 216 includes an entire image or copy of the authorized code, an excerpt of the authorized code, a signature of the authorized code, a MAC of the authorized code, or another property of the authorized code. The entire image of the authorized code may be stored in the secure memory 216 during a manufacturing phase of the security device 202. The entire image of the authorized code may also be copied or downloaded from a secure source, e.g., secure hardware or a secure server, such as the server computing system 108 of Fig. 1. The security device 202 may also update the stored authorized code information from the secure source. In some implementations, the authorized code information stored in the secure storage 216 does not include the entire image or copy of the authorized code, but rather the excerpt of the authorized code, the signature of the authorized code, and / or the MAC of the authorized code.

[0038] In some implementations, the authorized code signature is an OEM signature for the client device 204, which is stored in the security device 202 during the manufacturing phase of the security device 202, or copied, downloaded, or updated to the security device 202 after the manufacturing phase. In some examples, the security device 202 generates the authorized code signature based on the authorized code digest using an OEM public key 217. The security device 202 can verify the authenticity of the entire authorized code image by comparing the generated signature to the OEM signature.

[0039] In some implementations, the authorized code information stored in secure storage 216 includes information about a plurality of individual pieces of the authorized code, such as a copy of an individual piece, a digest, a signature, or a MAC of the individual piece, and / or an address range of the individual piece. In some examples, secure storage 216 stores the part information without the information associated with the entire authorized code image. In some examples, secure storage 216 stores a signature or digest of the entire authorized code image, e.g., the OEM signature, in secure storage 216 along with the section information.

[0040] In some implementations, the security device 202 selects a number of memory address ranges corresponding to a number of parts of the authorized code, e.g., during downloading the entire image from a secure source. The security device 202 determines a corresponding part for each memory address range. The security device 202 may then calculate a corresponding digest for each part using a cryptographic hash function or algorithm and store the digests of the parts in the secure memory 216. The security device 202 may also calculate a corresponding signature for each part using the respective digest and store the signatures in the secure memory 216. In some implementations, the security device 202 stores first information that describes the respective properties (e.g.,Second information indicating the respective memory address range (an excerpt or signature) of the parts of the authorized code, and second information indicating the respective memory address range in the security device 202 and associating the respective memory address ranges from the number of memory address ranges with properties from the number of properties of the parts in the security memory 216. Each time a new code verification starts, the cryptographic module 212 can select a random address range from the number of address ranges and generate a challenge based on the selected address range. The cryptographic module 212 can also randomly select two or more address ranges and generate a challenge based on a combination of the two or more address ranges.

[0041] The secure storage 216 may be part of the security device 202, which implements strong security mechanisms so that the data contained in the secure storage 216 cannot be easily copied, cloned, or modified, and any unauthorized changes to the data can be detected, e.g., by a verifying device. In one embodiment, the verifying device is remotely coupled to the security device 202. The security device may encrypt and sign a collection of information stored with respect to a key of the client device 204 and send an encrypted block and / or signature to the verifying device, which then evaluates the encrypted block and / or signature. In one embodiment, the security device 202 has an internal integrity check on the internal, protected non-volatile memory, e.g., the secure storage 216.The security device 202 may verify the integrity check before performing an operation.

[0042] In some implementations, secure storage 216 includes persistent storage, such as electronically erasable read-only memory (EEPROM), flash memory, a hard disk drive, or other suitable storage mechanisms configured to store data in a persistent manner. As previously stated, secure storage 216 may be used to store information associated with the authorized code of client device 204, secret data 215, keys 217, various read-write, read-only, or secret data, usage records, and security configurations. Access to the various sections of secure storage 216 may be restricted in a variety of ways, and the configuration may then be locked to prevent changes.

[0043] In some implementations, secure memory 216 includes volatile memory for temporary data storage. The volatile memory may, for example, be static random access memory (SRAM) in which downloaded or updated images of the authorized code are buffered during secure communication with a secure source, or results of cryptographic operations or authentication operations are buffered during secure communication with client device 204. In one embodiment, secure memory includes SRAM backed up by a power source, such as a battery or capacitor. In some implementations, volatile memory is used to store input commands or output results and intermediate results. The entire contents of volatile memory may be invalidated each time secure memory 216 enters a sleep mode or the power supply is turned off.

[0044] The authentication module 218 is configured to determine whether the code stored within the client device 204 is an authorized code. The authentication module 218 is configured to communicate with and obtain information from the secure storage 216, the cryptographic module 212, and / or the random number generation module 214. The cryptographic module 212 sends, for example, a challenge requesting a cryptographic property of a code of the client device 204. The client device 204 can return a response containing a cryptographic property of the code stored in the client device 204. The authentication module 218 can obtain the cryptographic property of an authorized code corresponding to the code of the client device 204, for example,of information associated with authorized code stored in secure storage 216, and determine whether the cryptographic property of the code received in the response matches the received cryptographic property of the authorized code. If the cryptographic property of the code matches the received cryptographic property of the authorized code, the authentication module 218 may determine that the code stored within the client device 204 is the authorized code. If the cryptographic property of the code does not match the received cryptographic property of the authorized code, the authentication module 218 determines that the code is unauthorized or unauthorised.

[0045] In some implementations, client device 204 includes, among other things, a processor 220 and a memory 222. Memory 222 may be internal or external memory of processor 220. Memory 222 is configured to store one or more codes (e.g., application firmware) 223 of client device 204 and secrets 225. Secrets 225 include, for example, a shared I / O protection secret that corresponds to I / O protection secret 215 stored in security device 202. Client device 204 may generate a MAC using the shared I / O protection secret. Secrets 225 may be stored in memory 222 during a manufacturing phase of memory 22 or client device 202. Secrets 225 may be read-only and difficult to modify.

[0046] A code and / or information associated with the code (e.g., an OEM signature of the code) may be stored in memory 222 during a manufacturing phase of client device 204, such as manufacturing, factory initialization, personalization, or distribution. The code and / or associated information may also be copied or downloaded from a secure source, such as secure hardware or a secure server. Client device 204 may also update the code and / or associated information from the secure source.

[0047] The processor 220 is configured to perform operations using the code stored in the memory 222. For example, the processor 220 boots using boot code, executes an application using application firmware, or performs an operation using operation code. The processor 220 may perform cryptographic functions to generate cryptographic properties of the code, e.g., calculating a hash of the code to generate a digest, calculating a hash of a message to generate a MAC, encrypting the code, or generating a signature. In some embodiments, the processor 220 includes a random number generation module similar to the random number generation module 214 that may generate a random number or a nonce.

[0048] In some implementations, processor 220 is configured to respond to challenges or queries from security device 202. In some cases, client device 204 receives a request from security device 202 containing a challenge for a cryptographic property of the code, e.g., a digest or signature or MAC of the code. Processor 220 may obtain or generate a cryptographic property of the code based on information from memory 222, including the stored code and / or associated information, and return a response containing the obtained cryptographic property of the code. In some examples, the challenge requests a cryptographic property of a specific portion of the code. For example, the challenge contains a specific address range corresponding to the specific portion.The processor 220 may identify a portion of the code corresponding to the determined address range and generate the cryptographic property of the corresponding portion of the code. Example flowcharts and embodiments

[0049] Fig. Figure 3 is a flowchart of an example process 300 by which a security device performs secure message authentication with secure code verification for a client device. For example, the operations in box 301 are performed by the client device, whereas the operations in box 303 are performed by the security device. The security device may be associated with the security device 118. Fig. 1 or the security device 202 Fig. 2. The client device can be the client device 120 from Fig. 1 or the client device 204 Fig. 2 are similar.

[0050] The client device generates a property of the code stored within the client device (302). The code may be boot code, application firmware, or operational code. The property of the code may be an excerpt of the code or encrypted data of the code. The client device may be prompted to execute step 302, for example, by a predetermined schedule (e.g., every second), or after a certain period of time after the previous code authentication, or each time the client device reboots, or upon receipt of a request from the security device or a remote device, such as the host device 112, the computing devices 106a, 106b, or the server computing system 108. Fig. 1. As detailed in connection with the Fig. 8 and Fig. As discussed in Figure 9, the client device receives a request from the security device, the request including a memory address range corresponding to a piece of code. The client device can determine the piece of code based on the memory address range and generate a property of the piece of code.

[0051] The client device sends the generated property of the code to the security device (304). In some examples, the client device sends a generated digest of the code to the security device along with a validated signature of the code, e.g., a DEM signature.

[0052] The security device receives the property of the code from the client device (306) and verifies the correctness of the property of the code (308). If the security device determines the incorrectness of the property of the code, the security device determines that the code is unauthorized or an unauthorized code (310). In response to the determination that the code is unauthorized, the security device enters a secure mode (312). The security device prevents itself from accessing critical information, such as secret data or keys, stored in a secure memory, such as the secure memory 216 of Fig. 2. In some cases, in response to determining that the code is unauthorized, the security device prevents the client device from communicating with a remote device over a network, e.g., network 102 of Fig. 1.

[0053] If the security device determines the correctness of the property of the code, the security device determines that the code is authorized or is an authorized code (314). In response to determining that the code is authorized, the security device enables access to critical information, such as secret data or keys, stored in the secure memory (316).

[0054] In some examples, the property of the code is a digest of the code generated by the client device. The security device generates a signature of the code based on the received digest of the code and a public key (e.g., a DEM public key) stored within the security device (e.g., in secure memory). The security device then determines whether the generated signature of the code matches the signature of an authorized code corresponding to the code (e.g., an OEM signature of the code). In some cases, the signature of the authorized code is stored within the security device (e.g., in secure memory). In some cases, the client device stores the signature of the authorized code and sends it to the security device for code verification.If the generated signature of the code matches the signature of the authorized code, the security device determines that the code is the authorized code (314). Otherwise, the security device determines that the code is not the authorized code (310).

[0055] In some examples, the property of the code is the digest of the code. The security device stores a digest of the authorized code. For example, when the security device receives an entire image of the authorized code, the security device calculates a digest of the authorized code and generates a signature of the digest for verification against an OEM signature of the authorized code. If the generated signature matches the OEM signature, the security device stores the digest of the authorized code in secure storage, e.g., without storing the entire image of the authorized code. When performing step 308, the security device may compare the received digest of the code with the stored digest of the authorized code to determine if they match. In some cases, the security device stores an entire image of the authorized code and generates a digest of the authorized code for comparison with the.received excerpt of the code from the client device.

[0056] In some examples, the property of the code contains encrypted data of the code. The client device encrypts the code to generate the encrypted data. The security device decrypts the received encrypted data of the code, for example, to obtain the code originally stored on the client device. The security device can then generate a digest of the decrypted data of the code. As shown above, to verify the correctness of the property of the code, the security device can generate a signature of the code based on the generated digest and a stored public key and determine whether the generated signature of the code matches the signature of the authorized code.

[0057] Successful verification of the code stored in the client device (314) allows the security device to access the secret data or keys stored in the secure memory (316). In some implementations, the stored secret data or keys can only be accessed by the security device based on the successful verification of the code. The security device can then use the secret data or keys to authenticate one or more messages with the client device.

[0058] In some implementations, the security device uses the secret data for message authentication with a remote device, e.g., the host device 112, the computing devices 106a, 106b, or the server computing system 108 of Fig. 1, with which the client device communicates. The client device sends a message directly to the remote device. The security device receives the message from the client device and generates an attribute of the message based on the stored secret data or key. For example, the security device generates a MAC of the message using the stored secret data shared with the remote device. The security device can append the generated MAC to the message and send the message with the appended MAC to the remote device. The remote device can use the shared secret data stored in the remote device to generate a MAC of the message and validate the received MAC from the security device with the generated MAC. If the received MAC matches the generated MAC, the remote device determines that the message from the client device is authentic or trusted.Otherwise, the remote device determines that the message is not authentic or untrustworthy.

[0059] In some implementations, the security device uses the secret data for message authentication with the client device. In some examples, in response to determining that the code is authorized (314), the security device generates a value indicating successful verification of the code. The security device may also generate a nonce. The security device uses the value and / or the nonce as the message to be authenticated. In some examples, the client device generates a nonce and sends the nonce to the security device. The security device uses the nonce and / or the received property of the code as the message to be authenticated.

[0060] With further reference to Fig. 3, the security device generates a property of the message (318) and sends the property of the message to the client device (320). The property of the message may be a MAC of the message based on the message and the secret data. In some examples, the security device sends the message, e.g., the indicative value and / or the generated nonce, to the client device.

[0061] The client device receives the property of the message (322) and generates a property of a second message based on second secret data stored in the client device (324). The second secret data may be the same as the secret data stored within the security device, e.g., a shared I / O protection secret. The second message may contain the same information as the message. In some examples, the message contains the indicator value and the nonce generated by the security device, and the second message also contains the indicator value and the nonce received from the security device. In some examples, the message contains the property of the code and / or a nonce generated by the client device, and the second message contains the property of the code and / or the nonce.

[0062] The client device compares the received property of the message with the generated property of the second message (326) and determines whether these two properties match (328). If the client device determines that the two properties match, the client device executes an application using the code (332). If the code is, for example, boot code, the client device proceeds with booting. If the code is application firmware, the client device executes a corresponding application. If the code is operation code, the client device performs a corresponding operation. Otherwise, if the client device determines that the two properties do not match, the client device prevents itself from executing the application using the code (334).

[0063] Fig. Figure 4 is a flowchart of an example process 400 by which a security device performs message authentication with secure code verification for a client device, according to another example embodiment. For example, the operations in box 401 are performed by the client device, whereas the operations in box 403 are performed by the security device. The security device may be associated with the security device 118. Fig. 1 or the security device 202 Fig. 2. The client device can be the client device 120 from Fig. 1 or the client device 204 Fig. 2. For illustrative purposes, the code here is application firmware stored on the client device.

[0064] The client device generates a dump of the application firmware (402) and sends the dump of the application firmware to the security device (404). The client device also sends a firmware signature (e.g., a DEM signature of the application firmware) stored in the client device to the security device (406).

[0065] The security device receives the application firmware dump (408) and receives the firmware signature (410). The security device then verifies the correctness of the application firmware dump (414) using the received dump, the firmware signature, and a public key (412) stored in the security device. The public key can be an OEM public key. The security device generates a signature of the application firmware dump based on the public key and then compares the generated signature with the firmware signature.

[0066] If the generated signature does not match the firmware signature, the security device determines that the verification was not successful (416), i.e., the firmware is not authorized, and the security device goes into a secure mode (418), similar to step 312. Fig. 3. If the generated signature matches the firmware signature, the security device determines that the verification was successful (420), i.e., the firmware is authorized. In response to the successful verification of the firmware, the security device enables access to the I / O protection secret (422) stored in the security device, e.g., in a secure memory in the security device. The security device generates a value to indicate the successful verification of the firmware (424). This value can be a number, a sequence, or a pattern. For representational purposes only, a Boolean "1" is used in Fig. 4 is used for this value. The security device can also receive a nonce, e.g., a random number, from the client device and store the nonce in a register (426). The security device uses the Boolean "1" and the nonce as the message and generates a MAC of the message based on the I / O protection secret (428). The security device then sends the generated MAC to the client device.

[0067] The client device receives the value, e.g., the Boolean "1," (430) from the security device, generates the nonce using a random number generator (RNG) (432), and uses the Boolean "1" and the nonce as the message. The client device then generates a MAC of the message (436) based on the I / O protection secret (434) stored in the client device. The client device then compares the received MAC from the security device with the generated MAC to determine if they match (438). If the generated MAC matches the received MAC, the client device proceeds to execute a corresponding application using the verified firmware (440). If the generated MAC does not match the received MAC, the client device is prevented from executing the application (442).

[0068] Fig. 5 is a flowchart of an example process 500 by which a security device performs message authentication with secure code verification for a client device, according to another example embodiment. For example, the operations in box 501 are performed by the client device, whereas the operations in box 503 are performed by the security device. The security device may be associated with the security device 118. Fig. 1 or the security device 202 Fig. 2. The client device can be the client device 120 from Fig. 1 or the client device 204 Fig. 2. For illustrative purposes, the code here is application firmware stored on the client device. The client device stores the application firmware and an I / O protection secret in a memory of the client device. The I / O protection secret can be stored in a secured portion of the memory. The security device stores a factory public key and a firmware signature (e.g., an OEM signature of the application firmware), e.g., in secure storage.

[0069] The client device generates a digest of the application firmware (402) by, for example, performing a cryptographic hash function. The cryptographic hash function may, for example, include a secure hash algorithm (SHA) such as SHA1, SHA2, SHA3, SHA-256, or an MD5 (message digest) algorithm. In a preferred embodiment, SHA-256 is used as the cryptographic hash function. The present technique is not limited to the implementation of such an example algorithm, and other types of hash functions may also be implemented.

[0070] The client device sends the generated application firmware dump to the security device (504). After receiving the firmware dump (506), the security device verifies the authenticity of the firmware (512) using the received firmware dump, a stored firmware signature (506), and a stored public key (510). The security device generates a signature based on the received firmware dump and the stored public key and compares the generated signature with the stored firmware signature to determine if they match. If the generated signature does not match the stored firmware signature, the security device determines that the firmware verification was unsuccessful (514), i.e., the firmware stored in the client device is unauthorized, and the security device enters a secure mode (516), similar to the secure mode 312 in Fig. 3.

[0071] If the generated signature matches the stored firmware signature, the security device determines that the firmware verification was successful (518). In response to the successful firmware verification, the security device enables access to the I / O protection secret stored in the security device (520). The I / O protection secret is in the form of shared secret data with the client device, which stores a corresponding I / O protection secret (528).

[0072] The client device uses an RNG to generate a nonce (522), e.g., a counter, a random number, and / or a time, and sends the nonce to the security device. The security device receives and stores the nonce in a register (524) and uses the nonce and the application firmware digest as a message. The security device generates a MAC of the message using the I / O protection secret (526), e.g., by an algorithm. The algorithm can be, e.g., HMAC (keyed-hash message authentication code) or an AES (Advanced Encryption Standard) CMAC (Cipher-based message authentication code) (AES-CMAC) algorithm, or one of many other algorithms. In a preferred embodiment, the security device uses an encryption MAC algorithm, e.g., AES-CMAC, to generate the MAC of the message.

[0073] The client device uses the generated firmware digest (504) and the nonce (522) as a message and generates a MAC of the message (530) using the stored shared I / O protection secret (528). The client device receives the MAC generated by the security device and compares the received MAC with the generated MAC in step 530 to determine if these two MACs match (532). If these two MACs match, the client device determines that the message authentication was successful and proceeds with executing an application using the stored firmware (534). Otherwise, if the two MACs do not match, the client device determines that the message authentication failed and prevents the application from executing (536).

[0074] Fig. 6 is a flowchart of an example process 600 by which a security device performs message authentication with secure code verification for a client device, according to a fourth example embodiment. For example, the operations in box 601 are performed by the client device, whereas the operations in box 603 are performed by the security device. The security device may be associated with the security device 118. Fig. 1 or the security device 202 Fig. 2. The client device can be the client device 120 from Fig. 1 or the client device 204 Fig. 2. For illustrative purposes, the code here is firmware stored on the client device. The client device stores the application firmware and an I / O protection secret in a memory of the client device. The I / O protection secret can be stored in a secured portion of the memory. The security device stores a factory public key and a firmware signature (e.g., an OEM signature of the application firmware), e.g., in secure storage.

[0075] The client device encrypts the application firmware stored in the client device (602). The client device may use an encryption function, e.g., AES, TEA (Tiny Encryption Algorithm), XTEA (eXtended TEA), SEAL (Software-Optimized Encryption Algorithm), WAKE, or one of many other algorithms. The client device sends the encrypted firmware to the security device (604). The security device decrypts the received encrypted firmware to obtain the firmware originally stored in the client device (606). The security device then generates a digest of the decrypted firmware (608). The security device may include a hardware hash engine, e.g., the cryptographic module 212 of Fig. 2, which can generate the hash value at high speed. The encryption function used by the client device and the decryption function used by the security device can ensure high speed and / or high security.

[0076] The security device verifies the authenticity of the firmware (614) using the generated digest, the stored firmware signature (610), and the stored public key (612). The security device generates a signature of the digest using the stored public key and compares the generated signature with the stored firmware signature. If the generated signature does not match the stored firmware signature, the security device determines that the verification was unsuccessful (616) and enters a secure mode (618). If the generated signature matches the stored firmware signature, the security device determines that the verification was successful (620) and allows access to the stored I / O protection secret (622).

[0077] The client device uses an RNG to generate a nonce (624) and sends the nonce to the security device. The security device receives and stores the nonce in a register (626) and uses the nonce as a message. The security device then generates a MAC of the message (628) using the I / O protection secret and sends the generated MAC to the client device. The security device can generate the MAC in parallel with I / O activities.

[0078] The client device also uses the generated nonce (624) as a message and generates a MAC of the message (632) using the I / O protection secret stored in the client device, which may be the same as the I / O protection secret stored in the security device. The client device compares the generated MAC with the received MAC from the security device and determines if the two MACs match (634). If the two MACs match, the client device determines that message authentication was successful and proceeds with executing an application using the stored firmware (636). Otherwise, if the two MACs do not match, the client device determines that message authentication failed and prevents the application from executing (638).

[0079] To increase security and / or improve speed, a security device may perform partial verification of code stored in a client device, e.g., verification of a portion of the code. Fig. 7A is a flowchart of an example process 700 by which a security device verifies the authenticity of application firmware of a client device, according to an example embodiment. Fig. 7B is a flowchart of another example process 750 by which a security device stores information from portions of the firmware for the client device, according to an example embodiment. Fig. 8 and Fig. 9 show example processes by which the security device performs message authentication with secure partial verification of the firmware for the client device.

[0080] The security device can be assigned to the security device 118 Fig. 1 or the security device 202 Fig. 2. The client device can be the client device 120 from Fig. 1 or the client device 204 Fig. 2. For illustrative purposes, the code here is application firmware stored on the client device. The client device stores the application firmware and an I / O protection secret in a memory of the client device. The I / O protection secret may be stored in a secured portion of the memory. The security device stores a factory public key (e.g., an OEM public key) and an authenticated firmware signature (e.g., an OEM signature), e.g., in secure storage.

[0081] Referring to Fig. 7A, the security device receives an image of the application firmware (702), e.g., from a source. The source may be the original manufacturer or a reliable or secure source, such as the host device 112, the computing devices 106a, 106b, or the server computing system 108 of Fig. 1. The security device can update information associated with the application firmware by downloading a new application firmware image from the source.

[0082] The security device calculates a digest of the application firmware (704) and then generates a signature of the application firmware digest using a public key (706), e.g., an OEM public key stored within the security device. The security device compares the generated OEM signature with the stored firmware signature (708) and verifies the authenticity of the application firmware based on the comparison (710). If the generated signature does not match the stored firmware signature, the security device determines that the received application firmware image is unauthorized or inauthentic. The security device can then discard the received image. If the generated signature matches the stored firmware signature, the security device determines that the received application firmware image is authorized or authentic.The security device may store a dump of the new application firmware image in the secure memory, or continue with step 750, e.g., without storing the entire application firmware image.

[0083] Referring to Fig. 7B, process 750 may be executed after the authenticity of the received application firmware image has been verified. The security device selects a plurality of address ranges for a plurality of portions of the application firmware (752). The security device may randomly select the plurality of address ranges from an address range defined by a start address and an end address of the application firmware. The selected address ranges may be different from each other and may have the same or different sizes. The selected address ranges may include address ranges corresponding to critical portions of the application firmware. The security device may check the critical portions more frequently than other non-critical portions.Each time the security device updates a new application firmware image, the security device can select a different set of address ranges that are different from the previous address ranges.

[0084] The security device determines a corresponding part for each address range (754) and calculates a corresponding digest for each part (756). The security device stores first information indicating the respective properties of the parts of the application firmware and second information indicating the respective memory address ranges in the secure memory area (758), and links corresponding memory address ranges from the plurality of memory address ranges to properties from the plurality of properties in the secure memory area (760). Note that the security device only needs to store digests with linked memory address ranges, without storing the application firmware image or parts of the application firmware.

[0085] With reference to Fig. 8, process 800 shows that the security device performs message authentication with secure partial verification of the firmware for the client device. The operations in box 801 are performed, for example, by the client device, whereas the operations in box 803 are performed by the security device. The security device selects an address range (802) from the memory address ranges stored in the secure memory. The security device can select the address range randomly from the number of memory address ranges. The security device can also select the address range to correspond to a critical part of the application firmware. The security device can also select the address range based on the sizes of corresponding parts of the address memory ranges.To take into account certain constraints on the startup time, the security device can select an address range corresponding to a part with a smaller scope or a larger scope.

[0086] In some implementations, the client device is required to perform a new validation based on a predefined schedule, e.g., every second or every time the client device boots. The security device can select a different memory area corresponding to a different piece of application firmware each time, allowing multiple pieces of application firmware stored on the client device to be verified over time. The security device can also vary the statistics for selecting different pieces to make it difficult to keep track of the stored memory areas.

[0087] In some implementations, a system contains a number of subsystems, each containing a corresponding client device and a corresponding security device. The subsystems can be identical to each other. The client devices perform the same operation, e.g., a boot operation using the same code. Each of the security devices can select a set of code portions and use this set of portions for secure code authentication with the corresponding client device. Different security devices can select different sets of code portions and / or have different sets of address ranges for the client devices. In some cases, a security device updates a new image of the code and selects a new set of code portions. The new set of code portions can be different from the previous set of portions selected by the same security device.

[0088] In some implementations, the subsystems differ from one another. The client device in each subsystem can perform a corresponding operation using a corresponding code. Each security device can select a set of parts of the corresponding code and use the set of parts for secure code authentication with the corresponding client device. The codes for different client devices can differ from one another. Different security devices can select different sets of parts of the different codes for secure code authentication with the client devices.

[0089] With further reference to Fig. 8, the client device receives the selected address range from the security device (804). The client device determines a corresponding portion of the application firmware stored in the client device based on the address range. The client device then generates a dump of the portion of the application firmware (806).

[0090] The client device sends the generated dump of the portion of the application firmware to the security device (808). The security device receives the dump from the client device (810) and verifies the received dump with a stored dump (812) linked to the selected address range in the secure memory (814). If the received dump does not match the stored dump, the security device determines that the verification was unsuccessful (816), i.e., the portion of the application firmware stored in the client device is unauthorized. The security device may determine that the firmware stored in the client device is unauthorized or untrusted. In response to determining that the verification was unsuccessful, the security device enters a secure mode (818), similar to the secure mode (312) of Fig. 3.

[0091] If the received digest matches the stored digest, the security device determines that the verification was successful (820), meaning that the portion of the application firmware stored on the client device is authorized. The security device may determine that the firmware stored on the client device is also authorized. In some cases, the security device may select one or more different address ranges for subsequent verifications with the client device. If all verifications are successful, the security device determines that the firmware stored on the client device is authorized.

[0092] In response to determining that the verification was successful, the security device releases access to the I / O protection secret stored in secure memory, which is shared with the client device (822). In some implementations, the client device uses an RNG to generate a nonce (824) and sends the nonce to the security device. The security device receives and stores the nonce in a register (826) and uses the received nonce and the received digest of the portion of the application firmware as the message. The security device generates a MAC of the message using the stored I / O protection secret (828) and sends the generated MAC to the client device.

[0093] The client device stores the shared I / O protection secret (830). The client device uses the generated digest of the portion of the application firmware to generate a nonce as a message, and generates a MAC of the message based on the shared I / O protection secret (832). The client device determines whether the generated MAC matches the received MAC from the security device (834). If the two MACs match, the client device proceeds with executing a corresponding application using the stored application firmware, e.g., continues booting (836). Otherwise, if the two MACs do not match, the client device prevents itself from executing the application (838).

[0094] Referring to Fig. 9, process 900 illustrates another implementation in which the security device performs message authentication with secure partial firmware verification for the client device. For example, the operations in box 901 are performed by the client device, whereas the operations in box 903 are performed by the security device.

[0095] The security device selects an address range from a plurality of memory address ranges stored in the secure memory (902). The selected address range corresponds to a portion of the application firmware and is associated with a digest of the portion of the application firmware (912) stored in the secure memory of the security device. Step 902 may be similar to step 802 of Fig. 8 resemble.

[0096] The client device receives the selected address range from the security device (904). Based on the address range, the client device determines a portion of the application firmware stored on the client device. The client device then encrypts the determined portion of the application firmware (906) and sends the encrypted portion of the application firmware to the security device.

[0097] The security device decrypts the received encrypted portion (908) to obtain the original portion of the application firmware. The security device then generates a dump of the portion of the application firmware (910) and verifies the correctness of the portion of the application firmware (914) by comparing the generated dump with the stored dump (912) associated with the address range in the secure memory. If the generated dump does not match the stored dump, the security device determines that the verification was unsuccessful (916) and enters a secure mode (918). If the generated dump matches the stored dump, the security device determines that the verification was successful (920).Based on the successful verification of the application firmware portion, the security device can further determine that the firmware stored on the client device is authorized (or trusted).

[0098] In response to the successful verification of the portion of the firmware, the security device releases access to the I / O protection secret stored in secure memory (922). The I / O protection secret is shared with the client device. The client device uses an RNG to generate a nonce (924) and sends the nonce to the security device. The security device receives and stores the nonce in a register (926) and uses the nonce as a message. The security device generates a MAC of the message using the stored I / O protection secret (928) and sends the generated MAC to the client device.

[0099] The client device stores the shared I / O protection secret (930). The client device uses the generated nonce as a message and generates a MAC of the message based on the shared I / O protection secret (932). The client device determines whether the generated MAC matches the received MAC from the security device (934). If the two MACs match, the client device proceeds with executing a corresponding application using the stored application firmware, e.g., proceeds with boot (936). Otherwise, if the two MACs do not match, the client device prevents itself from executing the application (938).

[0100] Certain embodiments of the subject matter described in this specification may be implemented to achieve one or more of the following advantages. This technique provides a solution to combine secure code authentication, e.g., secure boot, with message protection. It enables the use of secret data as part of a verification MAC, provided that the secure boot has been verified. If the secure boot has not been verified, it prevents the use of the secret as part of the verification MAC, thereby making a hardware-based man-in-the-middle attack more difficult. This technique enables the use of low-performance microcontrollers with security capabilities as part of a CAN (controlled area network), e.g., in automotive or other industrial security applications. A client processor, for example, hasdoes not have the required computing power or memory capacity to perform a secure boot operation, and this can be handed over to a security device. This technique can be used for hierarchical secure boot, which can be used for larger rich OS-based systems. A pre-boot ROM, for example, uses a security device to verify the authenticity of the boot code stored within a client device. For example, the security device can use partial verification of the boot code. The boot code may contain software, e.g., loader software, to verify a next level of code. The loader software can check code before it is loaded into memory, which can be important to validate arbitrary trusted code. The technique can be used in infotainment, telematics, and / or other systems running Linux, Android, Unix, etc.

[0101] Embodiments of the subject matter and the functional operations described herein may be implemented in digital electronic circuits, in embodied computer software or firmware, in computer hardware, or in other structures described herein and their structural equivalents, or in combinations thereof. Embodiments of the subject matter described in this specification may be implemented in the form of one or more computer programs, i.e., in the form of one or more modules of computer program instructions stored on a tangible, non-transitory program memory for execution by, or for controlling the operation of, data processing units. Alternatively or additionally, the program instructions may be based on artificially generated propagation signals, e.g.Machine-generated electrical, optical, or electromagnetic signals generated to encode information for transmission to suitable receiving devices for execution by a data processing device. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access storage device, or a combination of one or more of these.

[0102] The processes and logic sequences described in this specification may be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic sequences may also be performed by, and the devices may be implemented as, logic circuits for specific tasks, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0103] Computers suitable for executing a computer program may be based on general-purpose or special-purpose microprocessors, or both, or any other type of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory or RAM, or both. The essential elements of a computer are a central processing unit for carrying out or executing instructions and one or more storage devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to, one or more mass storage devices for storing data, such as magnetic, magneto-optical disks, or optical disks. However, a computer need not have any such devices. In addition, a computer may be contained within another device, such asa mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a GPS (Global Positioning System) receiver, or a portable storage device, e.g. a USB (universal serial bus) memory, to name just a few.

[0104] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, such as semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or included within, special-purpose logic circuitry.

Claims

[1] System comprising: a client device (120) that stores a code; and a security device (118) coupled to the client device (120) and configured to: Selecting a plurality of memory address ranges of an authorized code; determining a corresponding portion of the authorized code for each of the plurality of memory address ranges; Calculating a corresponding first property of each determined portion of the authorized code; Storing first information indicating the corresponding first properties of the parts of the authorized code and second information indicating the respective memory address ranges in the security device; and Linking memory address ranges from the plurality of memory address ranges with first properties from the first properties of the parts, Receiving a first property of the code generated by the client device (120); Checking the correctness of the first property of the code based on information associated with the authorized code to determine that the code is authorized, the information being stored in the security device; in response to determining that the code is authorized, enabling the security device to access initial secret data stored in the secure memory of the security device; and Generating a second property of a first message based on the first secret data; wherein the client device (120) is for: Receiving the second property of the first message from the security device (118); generating the second property of a second message based on second secret data stored in the client device (120), the second secret data corresponding to the first secret data stored in the security device (118); Determining whether the second property of the second message is valid based on a comparison of the second property of the second message and the second property of the first message; and Determining whether to execute an application on the client device (120) using the code based on a result of determining whether the second property of the second message is valid. [2] The system of claim 1, wherein the client device (120) is configured to: Selecting a particular memory address range from the plurality of memory address ranges; and Causing data indicating the particular memory address range to be sent to the client device (120), wherein the particular memory address range corresponds to a particular portion of the authorized code. [3] The system of claim 2, wherein the first property of the code comprises a digest of a portion of the code, and wherein the security device (118) verifies the correctness of the first property of the code by determining that the digest of the portion of the code matches a digest of the particular portion of the authorized code stored in the security device. [4] The system of claim 2, wherein the first property of the code comprises encrypted data of a portion of the code, wherein the security device (118) is for: Decrypting the encrypted data of the part of the code to obtain a decrypted part of the code; Generating an extract of the decrypted part of the code, and Determine that the generated excerpt of the decrypted part of the code matches the stored excerpt of the specific part of the authorized code in order to verify the correctness of the first property of the code. [5] Method comprising: Providing a client device (120) that stores a code; and a security device (118) coupled to the client device (120); selecting, by the security device (118), a plurality of memory address ranges of an authorized code; Determining, by the security device (118), a corresponding portion of the authorized code for each of the plurality of memory address ranges; calculating, by the security device (118), a corresponding first property of each determined portion of the authorized code; Storing, by the security device (118), first information indicating the corresponding first properties of the parts of the authorized code, and second information indicating the respective memory address ranges in the security device (118); and Linking, by the security device (118), memory address ranges from the plurality of memory address ranges with first properties from the first properties of the parts, Receiving, by the security device (118), a first property of a client device-generated code from a client device (120), Verifying, by the security device (118), the correctness of the first property of the code based on information associated with the code to determine that the code is authorized, the information being stored in the security device; in response to determining that the code is authorized, enable the security device to access first secret data stored in the secure memory of the security device (118); generating, by the security device (118), a second property of a first message based on the first secret data; Receiving, by the client device (120), the second property of the first message from the security device (118); generating, by the client device (120), the second property of a second message based on second secret data stored in the client device (120), wherein the second secret data corresponds to the first secret data stored in the security device (118); Determining, by the client device (120), whether the second property of the second message is valid based on a comparison of the second property of the second message and the second property of the first message; and Determining, by the client device (120), whether to execute an application on the client device (120) using the code based on a result of determining whether the second property of the second message is valid. [6] A method according to claim 5, comprising: Selecting, by the security device (118), a particular memory address range from the plurality of memory address ranges; and Causing, by the security device (118), data indicating the particular memory address range to be sent to the client device (120), wherein the particular memory address range corresponds to a particular portion of the authorized code. [7] The method of claim 6, wherein the first property of the code comprises an excerpt of the portion of the code. [8] The method of claim 7, wherein the verification of the correctness of the first property of the code comprises: Determining, by the security device (118), that the extract of the portion of the code matches an extract of the specific portion of the authorized code stored in the security device (118). [9] The method of claim 6, wherein the first property of the code comprises encrypted data of a portion of the code. [10] A method according to claim 9, comprising: Decrypting, by the security device (118), the encrypted data of the portion of the code to obtain a decrypted portion of the code; and Generating, by the security device (118), an extract of the decrypted part of the code, and Determining, by the security device (118), that the generated digest of the decrypted portion of the code matches the stored digest of the particular portion of the authorized code to verify the correctness of the first property of the code.

Images