TWI740409B - Verification of identity using a secret key - Google Patents

Abstract

A method includes receiving, by a computing device, a message from a host device. In response to receiving the message, the computing device generates an identifier, a certificate, and a key. The identifier is associated with an identity of the computing device, and the certificate is generated using the message. The computing device sends the identifier, the certificate, and the key to the host device. The host device verifies the identity of the computing device using the identifier, the certificate, and the key.

Description

Authentication using key

At least some of the embodiments disclosed herein are generally about identity verification, and more specifically (but not limited to), at least some of the embodiments disclosed herein are about identity verification using a key.

A physical uncopyable function (PUF) provides, for example, a digital value that can serve as a unique identifier for a semiconductor device (such as a microprocessor). PUF is based on, for example, physical changes that occur naturally during semiconductor manufacturing and allow to distinguish between other identical semiconductor wafers.

PUF is commonly used in cryptography. A PUF can be, for example, a physical entity embodied in a physical structure. PUF is usually implemented as an integrated circuit and is usually used in applications with high safety requirements. For example, PUF can be used as a unique and non-tamperable device identifier. PUF can also be used for security key generation and used as a source of randomness.

In an example of device identification, the Microsoft® Azure® IoT platform is a set of cloud services provided by Microsoft. The Azure® IoT platform supports Device Identification Combination Engine (DICE) and many different types of hardware security modules (HSM). DICE is a future standard of the Trusted Computing Group (TCG) for device identification and authentication, which enables manufacturers to use silicon gates to generate hardware-based device identification. HSM is used to make device identification secure and provide advanced functions such as hardware-based device authentication and zero-touch provisioning.

DICE provides an extensible security framework that uses an HSM footprint to anchor trust for building security solutions such as authentication, secure boot, and remote authentication. DICE is used in the current environment of constrained computing featuring IoT devices and replaces more traditional security framework standards, such as the Trusted Computing Group (TCG) and Trusted Platform Module (TPM). The Azure® IoT platform provides HSM support for DICE in HSM from some silicon vendors.

In an example of trust services, the Robust Internet of Things (RIoT) is an architecture used to provide trust services to computing devices. Trust services include device identification, authentication, and data integrity. The RIoT framework can be used to remotely rebuild the trust of devices that have been compromised by malware. In addition, RIoT services can be provided on even very small devices at low cost.

Improved security technology requires more frequent software updates for field products. However, these updates must be managed and verified without any involvement. RIoT can be used to solve these technical problems.

RIoT provides a basis for cryptographic operations and key management of many security solutions. Authentication, integrity verification, and data protection require cryptographic keys to encrypt and decrypt, and institutions to hash and mark data. Most Internet-connected devices also use passwords to secure communications with other devices.

The cryptographic services provided by RIoT include device identification, data protection and authentication. Regarding device identification, the device usually authenticates itself by proving that it possesses a cryptographic key. If the key associated with a device is extracted and copied, the device can be disguised.

Regarding data protection, devices usually use passwords to encrypt and integrity protect data stored locally. If the password key can only access the authorization code, unauthorized software cannot decrypt or modify the data.

Regarding authentication, the device sometimes needs to report its running code and its security configuration. For example, certification is used to prove that a device is running the latest code.

If only the software is used to manage the key, the vulnerability of the software component will cause the key to be leaked. For pure software systems, the main way to restore trust after a key is leaked is to install updated software and supply a new key for the device. This is time-consuming for servers and mobile devices, and is not suitable for when the device cannot be physically accessed.

Some methods for remotely re-provisioning security use hardware-based security. Software-level attacks can allow hackers to use hardware-protected keys but cannot extract them. Therefore, hardware-protected keys are a useful building block for the secure re-supply of compromised systems. A trusted platform module or TPM is an example of a security module that provides hardware protection of keys and also allows a device to report (authenticate) its running software. Therefore, a compromised device equipped with a TPM can safely issue a new key and provide an authentication report.

TPM can be widely used in computing platforms (for example, using SoC integration and processor mode isolation firmware TPM). However, TPM is generally not practical. For example, a small IoT device cannot support a TPM without a large increase in cost and power requirements.

RIoT can be used to provide device security for small computing devices, but it can also be applied to any processor or computer system. If the software components outside the RIoT core are damaged, RIoT provides security repairs and re-supply. RIoT also uses a different method for cryptographic key protection. The most protected cryptographic key used by the RioT framework is only temporarily available during startup.

According to an aspect of the present invention, a method includes: receiving a message from a host device by an arithmetic device; generating an identifier, a certificate, and a key by the arithmetic device, wherein the identifier is one of the arithmetic device The identity is associated, and the certificate is generated using the message; and the computing device sends the identifier, the certificate, and the key to the host device, where the host device is configured to use the identifier, the certificate, and The key verifies the identity of the computing device.

According to one aspect of the present invention, a system includes: at least one processor; and a memory containing instructions configured to instruct the at least one processor to send a message to a computing device; The computing device receives an identifier, a certificate, and a key, where the identifier is associated with an identity of the computing device, and the certificate is generated by the computing device using the message; and using the identifier, the certificate, and the key The key verifies the identity of the computing device.

According to one aspect of the present invention, a non-transitory computer storage medium stores instructions that, when executed on a computing device, cause the computing device to at least: receive a message from a host device; generate an identifier and a certificate And a key, wherein the identifier corresponds to an identity of the computing device, and the certificate is generated using the message; and the identifier, the certificate, and the key are sent to the host device for verifying the computing device Of the identity.

Related applications

This application is related to the U.S. Non-Provisional Application No. 15/970,660 named "Key Generation and Secure Storage in a Noisy Environment" filed by Pisasale et al. on May 3, 2018. The entire content of the application is as if The full description of the citation method is incorporated into this article.

This application is related to the U.S. non-provisional application No. 15/853,498 named "PHYSICAL UNCLONABLE FUNCTION USING MESSAGE AUTHENTICATION CODE" filed by Mondello et al. on December 22, 2017. The entire content of the application is described as if it were in full. The way of reference is incorporated into this article.

This application is related to the U.S. non-provisional application No. 15/965,731 filed by Mondello et al. on April 27, 2018, entitled "SECURE DISTRIBUTION OF SECRET KEY USING A MONOTONIC COUNTER". The entire content of the application is as if The full description of the citation method is incorporated into this article.

At least one embodiment of this document relates to the authentication of one or more computing devices. In various embodiments, a host device verifies the identity of the computing device by sending a message to a computing device. The computing device uses the message to generate an identifier, a certificate, and a key sent to the host device. The host device uses the generated identifier, certificate, and key to verify the identity of the computing device.

In some examples, the computing device may be a flash memory device. In some instances, flash memory is used to add a strong security capability level in a computing system (such as an application controller of an autonomous vehicle).

Flash memory is used in many computer systems. Various types of flash memory exist today, including serial NOR ("inverse OR"), parallel NOR, serial NAND ("inverse AND"), parallel NAND, e.MMC, UFS, and so on. These sockets are used in most embedded systems across various industries and applications.

For example, serial NOR is used in various applications such as medical devices, factory automation boards, automotive ECUs, smart meters, and Internet gateways. In view of the diversity of chipset architectures (processors, controllers or SoCs), operating systems, and supply chains used across these applications, flash memory systems are one of the common denominator building blocks in these systems.

Computer system resilience nowadays is usually characterized by the location of the root of trust integrated into the device and used by the solution for the security functions provided by the device. For more information about the root of trust, refer to the definition produced by the National Institute of Standards and Technology (NIST) Special Publication 800-164. The existing industry uses a system-level root-of-trust change implementation plan, which uses a combination of hardware and software capabilities to cause technical problems such as method segmentation and confusion of security levels. This series of confused options is also subject to the limitation of how to maintain the key of the non-volatile memory in which the key code and data are stored.

Existing methods rely on processors and other secure components (such as hardware security modules (HSM)) to provide critical security services to their systems. This has created a security gap at the lowest startup level of many systems where the discrete flash memory components store system key codes and data. Flash has become a target for many hackers to generate advanced persistent threats (APT) that can disguise themselves as higher-level codes to prevent them from being removed. In many of these cases, the flash memory is reshaped or rewritten by new malicious code, which destroys the integrity of the device.

Various embodiments of the present invention provide a technical solution to one of the above-mentioned technical problems. In some embodiments, a computing device integrates a hardware-based root of trust into a flash memory device to implement strong password identification and health management of the IoT device. With the basic security element in the mobile memory, it becomes easier to protect the integrity of the code and data contained in the memory itself. This method can significantly enhance system-level integrity while minimizing the complexity and cost of implementation.

In one embodiment, a new IoT device management capability utilizes flash memory by implementing device onboard and management using flash memory and associated software in the Microsoft® Azure® IoT cloud. In one example, solution provisioning becomes one of the foundations of key device provisioning services (such as Azure IoT Center Device Provisioning Service (DPS)) for password identification. In one example, this DPS can be used with memory to enable zero-touch provisioning of devices to the correct IoT center and other services.

In some embodiments, the device recognition combination engine (DICE) is used to implement the above capabilities (DICE is a future standard from the Trusted Computing Group (TCG)). In one instance, enabling memory only allows trusted hardware to access the Microsoft Azure IoT cloud. In one example, the health and identity of an IoT device are verified in the memory in which key codes are usually stored. The unique identity of each IoT device can now provide a new level of end-to-end device integrity to start the boot process. This can achieve additional functions, such as hardware-based device authentication and supply, and device management and repair (if needed).

In one embodiment, a method includes: receiving a message from a host device (such as a CPU, GPU, FPGA, or an application controller of a vehicle) by a computing device (such as a serial NOR flash memory device) ; Generated by the computing device an identifier (such as a public identifier ID _L1 public key), a certificate (such as ID _L1 certificate) and a secret key (such as K _L1 public key), where the identifier is related to an identity of the computing device And the certificate usage message is generated; and the identifier, certificate, and key are sent by the computing device to the host device, where the host device is configured to use the identifier, certificate, and key to verify the identity of the computing device.

In some embodiments, the aforementioned computing device (such as a flash memory device) integrates the DICE-RIoT function, which is used to generate the aforementioned identifier, certificate, and key, and is used by the host device to verify the identity of the computing device. In one example, the computing device stores a device secret that serves as an original key, and the sequence of identification steps between the layers of the DICE-RIoT protocol is based on the original key. In one example, hardware and/or software are used in the computing device to implement the layers L ₀ and L _{1 of the} DICE-RIoT function. In one example, layer L ₀ is implemented only in hardware.

FIG. 1 shows a host device 151 for verifying the identity of a computing device 141 according to an embodiment. The host device 151 sends a message to the computing device 141. In one embodiment, the host device 151 includes a freshness mechanism (not shown in the figure), which generates freshness for sending messages to the computing device 141 to avoid replay attacks. In one example, each message sent to the computing device 141 includes a freshness generated by a monotonic counter.

In an example, the message is an empty string, a conventional string (a string of text numbers known to the manufacturer or operator of the host device 151), or another value (for example, an identification value assigned to the computing device). In one example, the message is a unique identification (UID) of the device.

In response to receiving the message, the computing device 141 generates an identifier, a certificate and a key. The identifier is associated with an identity of the computing device 141. The computing device 141 includes one or more processors 143 that control the operation of the identification component 147 and/or other functions of the computing device 141.

The identifier, credential, and key are generated by the identification component 147 and based on the device secret 149. In one example, the device secret 149 is a unique device secret (UDS) stored in the memory of the computing device 141. In an example, the identification component 147 uses UDS as an original key for implementing one of the DICE-RIoT protocols. The identifier, certificate, and key are _{output from layer L 1} of the DICE-RIoT protocol (for example, refer to FIG. 6). In one embodiment, _{the identity of layer L 1} corresponds to the identity of the computing device 141, the manufacturer of the computing device 141, the manufacturer of the computing device 141 as one of the components, and/or the memory stored in the computing device 141 An application or other software in the body. In one example, the application identity (such as an ID number) is used for a unique combination of text and numbers to identify things such as a mobile phone, a TV, an STB, and so on.

In one example, _{the identity of layer L 1} is an ASCII string. For example, the identity may be a manufacturer's name concatenated with a thing name (for example, LG | TV_model_123_year_2018, etc.). In an example, the identity can be represented in hexadecimal form (for example, 53 61 6D 73 75 6E 67 20 7C 20 54 56 5F 6D 6F 64 65 6C 5F 31 32 33 5F 79 65 61 72 5F 32 30 31 38).

In one embodiment, a manufacturer can use a UDS for a type or group of items produced. In other embodiments, each item itself may have a unique UDS. For example, the UDS of a TV can be UDS=0x12234...4444, and the UDS of a laptop computer can be UDS=0xaabb...00322.

In one embodiment, the device secret 149 is a key stored in the memory 145 by the computing device 141. The identification component 147 uses the key as an input of a message authentication code (MAC) to generate a derived secret. In one example, the derived secret is the Fusion Derived Secret (FDS) in the DICE-RIoT protocol.

In one example, the memory 145 includes a read-only memory (ROM) that stores an initial activation code used to activate the computing device 141. The FDS is a key provided by the processor 143 to the initial startup code during a startup operation. In one example, the ROM corresponds to layer L _{0 of the} DICE-RIoT protocol.

The host device 151 uses the identifier, the certificate, and the key as the input of the verification component 153, and the verification component 153 verifies the identity of the computing device 141. In one embodiment, the verification component 153 uses the identifier to perform at least one decryption operation to provide a result. The result is compared with the key to determine whether the identity of the computing device 141 is valid. If it is valid, the host device 151 uses the key received from the computing device 141 to perform further communication with the computing device 141. For example, once the host device 151 has verified the "triple" (identifier, certificate, and key), the key can be used to authenticate any other information exchanged between the computing device 141 and the host device 151.

In one embodiment, a number of "things" are assigned to a digital identification (for example, according to the Internet of Things). In one example, the thing is a physical object, such as a vehicle or a physical object existing in the vehicle. In one example, the thing is a person or animal. For example, each person or animal can be assigned a unique digital identifier.

In some cases, the manufacturer of the product expects each product to be certified as authentic. Currently, this problem is solved by buying things from only a trusted seller or buying things from other people using some kind of legal certificate to ensure that the things purchased are genuine. However, in the case of theft of a thing, if the thing does not have an electronic identity, it is difficult to block or locate the thing so that the thing cannot be used improperly. In one instance, positioning is based on the identity of the thing when it tries to interact with the public infrastructure. In one instance, the blocking is based on the inability to prove the identity of a thing that wants to use a public infrastructure.

In one embodiment, the computing device 141 uses the identification component 147 to implement the DICE-RIoT protocol to associate the unique signature with a trust chain corresponding to the computing device 141. The arithmetic device 141 establishes layers L ₀ and L ₁ . The chain of trust is continued by the host device 151 that _{establishes layer L 2...} In one example, a unique identifier can be assigned to every object, person, and animal in any defined environment (eg, a trust zone defined by geographic parameters).

In one embodiment, the computing device 141 is a component of things that are expected to be given an identity. For example, the thing may be an autonomous vehicle including the computing device 141. For example, the computing device 141 may be a flash memory used by an application controller of the vehicle.

When manufacturing the computing device 141, the manufacturer can inject a UDS into the memory 145. In one example, the UDS can be consistent and shared with a customer who will use the computing device 141 to perform additional manufacturing operations. In another example, the UDS may be randomly generated by the original manufacturer and then transmitted to the customer using a secure infrastructure (for example, via a network, such as the Internet).

In one example, the customer may be a manufacturer of a vehicle that incorporates the computing device 141. In many cases, the vehicle manufacturer desires to change the UDS so that it is not known by the seller of the computing device 141. In these cases, the client can replace the UDS with one of the authentication replacement commands provided by the host device 151 to the computing device 141.

In some embodiments, the customer can inject customer immutable information into the memory 145 of the computing device 141. In one example, immutable information is used to generate a unique FDS, and not only as a distinguisher. Customer immutable information is used to distinguish various objects manufactured by customers. For example, customer immutable information can be a combination of letters and/or numbers to define the original information (for example, some or all of the following information: date, time, lot location, wafer location, x, y in a wafer Location etc.).

For example, in many cases, immutable information also includes data from a password feature configuration executed by a user (for example, a customer who receives a device from a manufacturer). This configuration or setting can be done only by using an authentication command (a command that needs to know a key to be executed). The user knows the key (for example, based on the key provided by the manufacturer via a secure infrastructure). Immutable information represents a form of the cryptographic identity of a computing device, which is different from the unique ID (UID) of the device. In one example, the password configuration included in the immutable information group provides users with a tool for self-customizing immutable information.

In one embodiment, the computing device 141 includes a freshness mechanism for generating a freshness. The freshness may be provided together with the identifier, the certificate, and the key when it is sent to the host device 151. Freshness can also be used with other communications of the host device 151.

In one embodiment, the computing device 141 is a component on an application board. Another component on the application board (not shown in the figure) can use the knowledge of the device secret 149 (for example, a knowledge injected into UDS) to verify the identity of the computing device 141. The component requests the computing device 141 to use a message authentication code to generate an output to prove the possession of the UDS. For example, the message authentication code can be as follows: HMAC (UDS, "Application Board Message|Freshness").

In another embodiment, FDS can also be used as a criterion to prove possession of the device (for example, knowledge of key(s)). FDS is derived from UDS in this way: FDS=HMAC-SHA256 [UDS, SHA256 ("L ₁ Identity")]. Therefore, the message authentication code can be as follows: HMAC (FDS, "Application Board Message|Freshness").

FIG. 2 shows an example computing system with an identification component 107 and a verification component 109 according to an embodiment. A host system 101 communicates with a memory system 105 via a bus 103. A processing device 111 of the memory system 105 reads/writes access to the memory areas 111, 113,..., 119 of the non-volatile memory 121. In one example, the host system 101 also reads data from the volatile memory 123 and writes data to the volatile memory 123. In one example, the identification component 107 supports layers L ₀ and L _{1 of the} DICE-RIoT protocol. In one example, the non-volatile memory 121 stores the activation code.

The verification component 109 is used to verify the identity of one of the memory systems 105. The verification component 109 uses a triple including an identifier, a certificate, and a key generated by the identification component 107 in response to receiving a host message from the host system 101, such as described above.

The identification component 107 is an example of the identification component 147 in FIG. 1. The verification component 109 is an example of the verification component 153 in FIG. 1.

The memory system 105 includes a key storage 157 and a key generator 159. In one example, the key storage 157 may store the root key, the session key, a UDS (DICE-RIoT), and/or other keys used for cryptographic operations by the memory system 105.

In an example, the key generator 159 generates a public key that is sent to the host system 101 for verification by the verification component 109. The public key is sent as part of the triplet that also contains an identifier and certificate, as described above.

The memory system 105 includes a freshness generator 155. In an example, the freshness generator 155 can be used to authenticate commands. In an example, multiple freshness generators 155 may be used. In an example, the freshness generator 155 may be used by the host system 101.

In one example, the processing device 111 and the memory regions 111, 113, ..., 119 are located on the same chip or die. In some embodiments, the memory area stores data used by the host system 101 and/or the processing device 111 during the machine learning process or other operations generated by the software program(s) running on the host system 101 or the processing device 111 Time information.

The computing system may include a writing component in the memory system 105, which selects a memory area 111 (for example, a record segment of flash memory) for recording new data from the host system 101. The computing system 100 may further include a writing component in the host system 101, which coordinates with the writing component 107 in the memory system 105 to at least facilitate the selection of the memory area 111.

In one example, the volatile memory 123 is used as a system memory of a processing device (not shown in the figure) of the host system 101. In one embodiment, a program of the host system 101 selects a memory area for writing data. In one example, the host system 101 may select a memory area based in part on data from sensors and/or software programs running on an autonomous vehicle. In one example, the aforementioned data is provided by the host system 101 to the processing device 111 that selects the memory area.

In some embodiments, the host system 101 or the processing device 111 includes at least a part of the identification component 107 and/or the verification component 109. In other embodiments or in combination, one of the processing device 111 and/or the host system 101 includes at least a part of the identification component 107 and/or the verification component 109. For example, the processing device 111 and/or one of the processing devices of the host system 101 may include logic circuits that implement the identification component 107 and/or the verification component 109. For example, a controller or processing device (such as a CPU, FPGA, or GPU) of the host system 101 can be configured to execute instructions stored in memory to execute the identification component 107 and/or the verification component 109 described herein. operate.

In some embodiments, the identification component 107 is implemented as an integrated circuit chip disposed in the memory system 105. In other embodiments, the verification component 109 in the host system 101 is a part of an operating system, a device driver, or an application program of the host system 101.

An example of the memory system 105 is a memory module connected to a central processing unit (CPU) via a memory bus. Examples of memory modules include a dual in-line memory module (DIMM), a small form factor DIMM (SO-DIMM), a non-volatile dual in-line memory module (NVDIMM), and so on. In some embodiments, the memory system may be a hybrid memory/storage system that provides one of memory functions and storage functions. Generally speaking, a host system can utilize a memory system that includes one or more memory areas. The host system can provide data stored in the memory system and can request data retrieved from the memory system. In one example, a host can access various types of memory including volatile and non-volatile memory.

The host system 101 can be a computing device, such as a controller in a vehicle, a web server, a mobile device, a cellular phone, an embedded system (for example, having a single chip system (SOC) and internal or External memory (an embedded system) or any computing device including a memory and a processing device. The host system 101 can include or be coupled to the memory system 105 so that the host system 101 can read data from the memory system 105 or write data to the memory system 105. The host system 101 can be coupled to the memory system 105 via a physical host interface. As used herein, "coupled to" generally refers to a connection between components, which can be an indirect communication connection or a direct communication connection (for example, no intervening components) (wired or wireless), including electrical, optical, magnetic Wait for the connection. Examples of a physical host interface include (but are not limited to) a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect (PCIe) interface, a Universal Serial Bus (USB) interface, Fibre Channel, Serial Attachment Connect to SCSI (SAS), a double data rate (DDR) memory bus, etc. The physical host interface can be used to transfer data between the host system 101 and the memory system 105. The physical host interface can provide an interface for transferring control, address, data, and other signals between the memory system 105 and the host system 101.

FIG. 2 shows a memory system 105 as an example. Generally speaking, the host system 101 can access multiple memory systems via a same communication connection, multiple individual communication connections, and/or a combination of communication connections.

The host system 101 may include a processing device and a controller. The processing device of the host system 101 may be, for example, a microprocessor, a central processing unit (CPU), a processing core of a processor, an execution unit, and so on. In some examples, the controller of the host system may refer to a memory controller, a memory management unit, and/or an initiator. In an example, the controller controls the communication between the host system 101 and the memory system 105 via the bus 103. These communications include sending a host message for verifying the identity of the memory system 105, as described above.

A controller of the host system 101 can communicate with a controller of the memory system 105 to perform operations such as reading data, writing data, or erasing data at the memory area of the non-volatile memory 121. In some examples, the controller is integrated in the same package of the processing device 111. In other cases, the controller and the processing device 111 are packaged separately. The controller and/or processing device may include hardware, such as one or more integrated circuits and/or discrete components, a buffer memory, a cache memory, or a combination thereof. The controller and/or processing device can be a microcontroller, a dedicated logic circuit (such as a field programmable gate array (FPGA), a dedicated integrated circuit (ASIC), etc.), or another suitable processor.

In an embodiment, the memory areas 111, 113, ..., 119 may include any combination of different types of non-volatile memory components. In addition, the memory cells in the memory area can be grouped into memory pages or data blocks, which can refer to a unit for storing data. In some embodiments, the volatile memory 123 may be (but not limited to) random access memory (RAM), dynamic random access memory (DRAM), and synchronous dynamic random access memory (SDRAM).

In one embodiment, one or more controllers of the memory system 105 can communicate with the memory areas 111, 113,... 119 to perform operations such as reading data, writing data, or erasing data. Each controller may include hardware, such as one or more integrated circuits and/or discrete components, a buffer memory, or a combination thereof. Each controller can be a microcontroller, a dedicated logic circuit (such as a field programmable gate array (FPGA), a dedicated integrated circuit (ASIC), etc.) or another suitable processor. The controller(s) may include a processing device (processor) that is configured to execute instructions stored in local memory. In one example, the local memory of the controller includes an embedded memory that is configured to store various programs, operations, logic flows, and routines (including processing memory) used to perform operations that control the memory system 105 The communication between the system 105 and the host system 101) commands. In some embodiments, the local memory may include a memory register for storing memory indicators, searching for data, and so on. The local memory may also include read-only memory (ROM) for storing microcode.

Generally speaking, the controller(s) of the memory system 105 can receive commands or operations from the host system 101 and/or the processing device 111 and can convert the commands or operations into commands or appropriate commands to achieve data writing based on the memory area Enter the counter to select a memory area. The controller can also be responsible for other operations, such as wear leveling, discarded item collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and a logical block address associated with the memory area. Address conversion between addresses of a physical block. The controller may further include a host interface circuit to communicate with the host system 101 via the physical host interface. The host interface circuit can convert commands received from the host system into command commands to access one or more of the memory areas and convert responses associated with the memory areas into information of the host system 101.

The memory system 105 may also include additional circuits or components (not shown in the figure). In some embodiments, the memory system 105 may include a cache or buffer (such as DRAM or SRAM) and an address that can receive an address from one or more controllers and decode the address to access the memory area Circuits (such as a column decoder and a row decoder).

In some embodiments, one of the controller and/or the processing device 111 in the host system 101 or the memory system 105 includes at least a part of the identification component 107 and/or the verification component 109. For example, the controller and/or the processing device 111 may include logic circuits that implement the identification component 107 and/or the verification component 109. For example, a processing device (processor) can be configured to execute instructions stored in the memory to perform operations that provide read/write access to the memory area of the identification component 107, as described herein. In some embodiments, the verification component 109 is part of an operating system, a device driver, or an application program.

FIG. 3 shows an exemplary computing device of a vehicle 100 according to an embodiment. For example, the vehicle 100 may be an autonomous vehicle, a non-autonomous vehicle, an emergency vehicle, a service vehicle, or the like.

The vehicle 100 includes a vehicle computing device 110, such as an onboard computer. The vehicle computing device 110 is an example of the host device 151 in FIG. 1. In another example, the vehicle computing device 110 is an example of the host device 101 in FIG. 2, and the memory 160 is an example of the memory system 105.

The vehicle computing device 110 includes a processor 120 coupled to an in-vehicle communication component 130 (such as a reader, writer, and/or other computing device capable of performing the functions described below), and the in-vehicle communication component 130 is coupled to ( Or include) an antenna 140. The in-vehicle communication component 130 includes a processor 150 coupled to a memory 160 (such as a non-volatile flash memory), but the embodiment is not limited to this type of memory device.

In one example, the memory 160 is adapted to store all information related to the vehicle by providing this information by using a communication interface (such as the so-called DICE-RIoT protocol) when the vehicle 100 approaches a checkpoint. (For example, the driver, passengers, and cargo carried), as described below.

In one example, vehicle information (such as vehicle ID/license plate number) has been stored in the vehicle memory 160, and the vehicle 100 can, for example, pass through the communication component 130 and by using a known DICE-RIoT protocol or a similar protocol Identify the electronic ID of the passenger and/or the ID of the carried luggage, cargo, and the like, and then store this information in the memory 160. In one example, the electronic ID, the luggage being transported and the cargo container are equipped with wireless transponders, NFC, Bluetooth, RFID, contactless sensors, magnetic sticks and the like, and the communication component 130 can use a reader and / Or the electromagnetic field obtains the required information from these remote sources.

In one example, all passenger IDs and/or IDs of carried luggage, cargo, and the like are equipped with electronic devices capable of exchanging data with a communication component. The electronic devices can be active or passive components, as far as they can be active, because they are powered by electricity or can be activated and powered by an external power source that only provides the required power when the electrical device is located nearby.

A rental vehicle or autonomous vehicle can use a reader and/or electromagnetic field to obtain information in or near the vehicle or as an alternative, it can even receive information from a remote source, such as when the driver of a rental vehicle has already made a reservation due to a previous reservation. When the rental system is known. When the driver comes to pick up the car, a further inspection can be performed immediately.

Similarly, all information about the luggage and cargo (and also about passengers) carried by the vehicle 100 can always be kept up to date. For this reason, the electronic ID of the passenger and/or the ID of the carried luggage and cargo are updated in real time due to the wireless transponder associated with the luggage and cargo or owned by the passenger (not shown in the figure).

In one example, the communication between the in-vehicle communication component 130 and the proximity source (such as a cargo transponder and the like) occurs via the DICE-RIoT protocol.

In one example, the vehicle computing device 110 can control operating parameters of the vehicle 100, such as steering and speed. For example, a controller (not shown in the figure) may be coupled to a steering control system 170 and a speed control system 180. In addition, the vehicle computing device 110 can be coupled to an information system 190. The information system 190 can be configured to display a message (such as route information or a checkpoint safety message) and can display visual warnings and/or output audible warnings. The communication component 130 can receive information from an additional computing device (such as an external computing device (not shown in the figure)).

4 shows an example system 390 having a host device 350 in communication with an example computing device of a vehicle 300, according to an embodiment. The computing device includes a passive communication component 310, such as a short-range communication device (such as an NFC tag). The communication component 310 may be located in the vehicle 300. The vehicle 300 may be configured as shown for the vehicle 100 in FIG. The communication component 310 includes a chip 320 (for example, a CPU or an application controller that implements the vehicle 300), which has one of storing information about the vehicle 300 (such as vehicle ID, driver/passenger information, carried cargo information, etc.) Non-volatile storage component 330. The communication component 310 may include an antenna 340.

The host device 350 is, for example, an active communication device (for example, it includes a power supply), which can receive information from the communication component 310 and/or transmit information to the communication component 310. In some examples, the host device 350 may include a reader (eg, an NFC reader) (such as a toll reader) or other components. The host device 350 may be an external device configured (eg embedded) near a checkpoint (eg, at the boundary of a trusted zone) or generally, an external device near a limited access area. In some embodiments, the host device 350 can also be carried by a policeman for use as a portable device.

The host device 350 may include a processor 360, a memory 370 (such as a non-volatile memory), and an antenna 380. The memory 370 may include an NFC protocol that allows the host device 350 to communicate with the communication component 310. For example, the host device 350 and the communication component 310 may communicate using the NFC protocol, such as, for example, at about 13.56 MHz and in accordance with the ISO/IEC 18000-3 international standard. Other methods of using RFID tags can be used.

The host device 350 can also communicate with a server or other computing devices (for example, communicate with a central operation center via a wireless network). For example, the host device 350 may be wirelessly coupled or hard-wired to a server or a communication center. In some examples, the host device 350 may communicate with the operation center via WIFI or via the Internet. When the vehicle 300 brings the antenna 340 into one of the communication distances of the antenna 380, the host device 350 can provide power to the communication component 310. In some examples, the host device 350 can receive real-time information from the operation center and can transmit the information to the vehicle 300. In some embodiments, the communication component 310 may have its own battery.

In one embodiment, the host device 350 is adapted to read/send information from the vehicle 300 to the vehicle 300. The vehicle 300 is equipped with a communication component 310 (such as an active device) configured to allow information exchange.

Referring again to FIG. 3, the on-board communication component 130 of the vehicle 100 can function internally to instantly pick up relevant information about the passenger ID, luggage and/or cargo (for example, when equipped with the corresponding wireless device discussed above with respect to FIG. 4). Communication components). The computing device of the vehicle can detect information within a spatial range of several meters (for example, 2 meters to 3 meters), so that all data corresponding to passengers, luggage, and cargo can be obtained. In one example, this occurs when the vehicle approaches an external communication component (such as a server or other computing device acting as a host device) within a certain proximity so that communication can start and/or become stronger. The communication distance is (for example) 2 meters to 3 meters.

In one example, the in-vehicle communication component 130 can encrypt data when transmitting to an external entity and/or communicating with an internal entity. In some cases, information about the luggage, cargo, or even passengers being transported may be confidential or contain confidential information (for example, the health status of a passenger or a confidential document or a dangerous material). In this case, it is desirable that the information and data stored in the memory portion associated with the vehicle computing device remain encrypted data.

In various embodiments to be discussed below, a method for encrypting and decrypting communication between an internal vehicle computing device and an external entity (for example, a server serving as a host device) is discussed. In one example, this method can even be applied between the internal vehicle computing device and the electronic components associated with the passengers, luggage, and cargo carried on the vehicle.

In one example, the in-vehicle communication component 130 sends a vehicle public key to the external communication component (for example, acting as a host device 151), and the external communication component sends an external public key to the in-vehicle communication component 130. These public keys (vehicle and external) can be used to encrypt data sent to each respective communication component and verify the identity of one of each communication component, and also exchange confirmations and other information. As an example, as will be further described below, the in-vehicle communication component 130 can use the received external public key to encrypt data and send the encrypted data to the external communication component. Similarly, the external communication component can use the received vehicle public key to encrypt data and send the encrypted data to the in-vehicle communication component 130. The data sent by the vehicle 100 may include car information, passenger information, cargo information, and the like. The information may be sent with a digital signature as appropriate to verify the identity of one of the vehicles 100. Furthermore, the information can be provided to the vehicle 100 and displayed on a dashboard of the vehicle 100 or sent to an e-mail of a computing device associated with the vehicle 100 (such as a user device or a central server that monitors the vehicle). The vehicle can be identified based on a vehicle identification, a VIN number, etc., and a vehicle digital signature.

In an example, the data exchanged between the vehicle and the external entity may have a freshness that is used by the other. As an example, the data sent by the vehicle to the external entity to indicate the same instruction can be changed for each of a specific time frame or for a specific amount of data sent. This prevents a hacker from intercepting the confidential information contained in the previously sent data and sending the same data again to cause the same result. If the data has been slightly changed, but the same command is still instructed, the hacker can send the same information at a later point in time, and the same command will not be executed because the recipient expects the same command to be executed by changing the data.

Many encryption and/or decryption methods can be used to exchange data between the vehicle 100 and an external entity (such as a computing system or device) (not shown in the figure), as will be described below. The security of the data can ensure that unauthorized activities are prevented from interfering with the operation of the vehicle 100 and external entities.

FIG. 5A shows an application board that generates a triple including an identifier, a credential, and a key sent to a host device according to an embodiment. The host device uses triples to verify the identity of one of the application boards. The application board is an example of the computing device 141 in FIG. 1. The host device is an example of the computing device 151 in FIG. 1.

In one embodiment, the application board and the host include a communication component that uses a device recognition combination engine (DICE)-Robust Internet of Things (RIoT) protocol to perform communication encryption and/or decryption operations (for example, information and data). In one example, the DICE-RIoT protocol is applied to the communication between the in-vehicle communication component and an external communication component, and the in-vehicle communication component and various wireless electronic devices (which are related to each of the passenger ID, luggage, cargo, and the like) One of the communication is performed within the vehicle environment.

FIG. 5B shows an example computing system activated in the stage of using the layer according to an embodiment. The system includes an external communication component 430' and an in-vehicle communication component 430" according to an embodiment of the present invention. When the vehicle is close to or near an external entity, the associated on-board communication component 430" of the vehicle can, for example, use a sensor (such as a radio frequency identification sensor or RFID or the like) to exchange data with the external entity , As described above.

In other embodiments, the component 430' can be an application board located in a vehicle, and the component 430" can be a host device also located in the vehicle, which uses the DICE-RIoT protocol to verify the identity of the component 430' ( For example, discussed above with respect to Figure 1).

In one embodiment, the DICE-RIoT protocol is used by a computing device to start in the stage of using layers, where each layer identifies and loads a subsequent layer and provides increasingly complex runtime services at each layer. Therefore, a layer can be served by a previous layer and a subsequent layer can be served to thereby generate one of the interconnected web pages that accumulate on the lower layer and serve the higher layer. Alternatively, other protocols can be used to replace the DICE-RIoT protocol.

In an exemplary implementation of the communication protocol, the security of the communication protocol is based on a secret value, which is a device secret (such as a UDS) set during manufacturing (or later). The device secret UDS exists in the device on which the device secret UDS is supplied (for example, stored as the device secret 149 of FIG. 1).

The device secret UDS can be accessed to the first stage ROM-based boot loader at boot time. Then, the system provides a mechanism to make the device secret inaccessible before the next boot cycle, and only the boot loader (such as the boot layer) can permanently access the device secret UDS. Therefore, in this method, the activation is layered in a specific architecture starting with the device secret UDS.

As shown in FIG. 5B, layer 0 L ₀ and layer 1 L _{1 are} located in the external communication component 430'. Layer 0 L ₀ can provide a fusion derived secret FDS key to layer 1 L ₁ . The FDS key can be based on _{the identification of the code in layer 1 L 1} and other security-related information. A specific protocol (such as the Robust Internet of Things (RIoT) core protocol) can use FDS to verify the core _{of the layer 1 L 1 it loads.} In one example, the specific protocol may include a device identification combination engine (DICE) and/or RIoT core protocol. As an example, FDS may include a layer of 1 L ₁ firmware image itself, a display of one of the encrypted identification authorization layer 1 L ₁ firmware, a firmware version number of a signed firmware in the background of a secure boot implementation, and/or Safety-critical configuration settings of the device. The device secret UDS can be used to generate FDS and stored in the memory of the external communication component. Therefore, layer 0 L ₀ never reveals the actual device secret UDS and it provides a derived key (such as an FDS key) to the next layer in the boot chain.

The external communication component 430' is adapted to transmit data (as shown by the arrow 410') to the vehicle communication component 430". The transmitted data may include a public external identification, a certificate (for example, an external identification certificate), and/or an external public key, as will be shown in conjunction with FIG. 6. _{The layer 2 L 2 of the in-} vehicle communication component 430" can receive the transmitted data, and execute the data in the operation of the operating system OS (for example, a first application App ₁ and a second application App _2).

Similarly, the in-vehicle communication component 430" can transmit data (as shown by the arrow 410"), which includes a public vehicle identification, a certificate (for example, a vehicle identification certificate), and/or a vehicle public key. As an example, after authentication (for example, after verifying the certificate), the in-vehicle communication component 430" may send a vehicle identification number VIN to further authenticate, identify and/or verify the vehicle.

As shown in FIG. 5B and FIG. 6, in an example operation, the external communication component 430' can read the device secret DS, an _{identity of the hash layer 1 L 1} , and perform the following calculations:

FDS=KDF [UDS, hash ("immutable information")]

KDF is a cryptographic one-way key derivation function (such as HMAC-SHA256). In the above calculation, the hash can be any cryptographic primitive, such as SHA256, MD5, SHA3, and so on.

In at least one example, the vehicle can communicate using either an anonymous login or an authenticated login. The authentication log allows the vehicle to obtain additional information that cannot be accessed when communicating in an anonymous mode. In at least one example, authentication may include providing a vehicle identification number VIN and/or authentication information, such as an exchange of a public key, as described below. In either of the anonymous mode and the authentication mode, an external entity (such as a checkpoint police at a border of a trusted zone) can communicate with the vehicle to provide an external public key associated with the external entity to the vehicle.

FIG. 6 shows an exemplary computing device that uses an asymmetric generator to generate an identifier, credential, and key according to an embodiment. In one embodiment, the arithmetic apparatus according to a program to determine parameters (e.g., a layer L ₁ of an external device or alternative embodiments, L ₁ in the inner layer of the apparatus in an internal operation).

In one embodiment, the determining comprises transmitting followed (e.g., 510 'indicated to the vehicle communications component (e.g., with reference to the FIG. 5B by arrow 430)'') of the outer layer 2 L ₂ is identified in common, the external public key certificates and external The parameters. Arrows 510' and 510" in FIG. 6 correspond to arrows 410' and 410" in FIG. 5B, respectively. In addition, the layer in FIG. 6 corresponds to the layer in FIG. 5B.

In another embodiment, a message from the host device ("host message") is merged with an external public key by pattern (data) merge 531 to provide merged data for encryption. The combined data is input by one of the encryptors 530. In one example, the host message is concatenated with the external public key. The generated parameters include triples sent to a host device and used to verify the identity of an arithmetic device. For example, the external public identification, the external certificate, and the external public key are used by a verification component of the host device to verify the identity. In one example, the host device is the host device 151 of FIG. 1.

Shown in Figure 6, FDS 0 L0 layer from the layer sent to a ₁ L 1 and an asymmetric ID generator for generating a public and a private identification to identify IDlkpublic IDlkprivate. In the abbreviation "IDlkpublic", "lk" indicates a common layer k (in this example, layer 1 L ₁ ), and "public" indicates that the identification is publicly shared. The public identification IDlkpublic is shown as shared by the arrows _{extending to the right and outside of layer 1 L 1 of the external communication components.} The generated private identification IDlkprivate is used as a key input to an encryptor 530. The encryptor 530 can be, for example, any processor, computing device, etc. used to encrypt data.

The layer 1 L _{1 of the} external communication component may include an asymmetric key generator 540. In at least one example, a random number generator RND can input a random number into the asymmetric key generator 540 as appropriate. The asymmetric key generator 540 can generate a public key KLkpublic (referring to an external public key) and a private key KLkprivate (referring to an external private key) associated with an external communication component (such as the external communication component 430′ in FIG. 5B). key).

The external public key KLkpublic can be input to one of the encryptors 530 (as "data"). As mentioned above, in some embodiments, the host message previously received from the host device as part of an authentication process is combined with KLkpublic to provide the combined data as the input data of the encryptor 530.

The encryptor 530 can use the input of the external private identification IDlkprivate and the external public key KLkpublic to generate a result K′. The external public key KLkprivate and the result K′ can be input into an additional encryptor 550 to cause the output K″. Output K '' based transport layer to ₂ L 2 (or alternatively, the transmission to verify the identity of one of the host device) of the external document IDL1certificate. The external certificate IDL1certificate can provide the ability to verify and/or authenticate the origin of data sent from a device. As an example, the data sent from the external communication component can be associated with the identity of one of the external communication components by verifying the certificate, as will be further described in conjunction with FIG. 7. In addition, the external public key KL1public key can be transmitted to layer 2 L ₂ . Therefore, the public identification IDl1public, the certificate IDL1certificate, and the external public key KL1public key of the external communication component can be transmitted to the layer 2 L _{2 of the in-} vehicle communication component.

FIG. 7 shows a verification component that uses a decryption operation to verify the identity of a computing device according to an embodiment. The verification component includes decryptors 730 and 750. The verification component implements a procedure to verify a credential according to an embodiment of the present invention.

In the example shown in FIG. 7, a public key KL1public, a certificate IDL1certificate, and a public identification IDL1public are provided from an external communication component (for example, from the layer 1 L ₁ of the external communication component 430' in FIG. 5B).

The information of the certificate IDL1certificate and the external public key KL1public can be used as input to the decryptor 730. The decryptor 730 can be any processor, computing device, etc., used to decrypt data. The decryption result of the certificate IDL1certificate and the external public key KL1public can be used together with the public identification IDL1public as an input to the decryptor 750 to cause an output. As shown in block 760, the external public key KL1public and the output from the decryptor 750 can indicate whether to verify the certificate to result in a "yes" or "no" as an output. The private key is associated with a single layer and a specific certificate can only be generated by a specific layer.

In response to the verification certificate (for example, after authentication), the data received from the verified device can be accepted, decrypted, and/or processed. In response to an unverified certificate, you can discard, remove, and/or ignore the data received from the verified device. In this way, unauthorized devices that send malicious data can be detected and avoided. As an example, it is possible to identify a hacker who sends one of the data to be processed and does not process the hacking data.

In an alternative embodiment, the public key KL1public, a certificate IDL1certificate, and a public identification IDL1public are provided from the computing device 141 in FIG. 1 or from the memory system 105 in FIG. 2. This triple is generated by the computing device 141 in response to receiving a host message from the host device. Before the IDL1 certificate is provided as one of the input of the decryptor 730, the IDL1 certificate and a message from the host device ("host message") are merged by the pattern (data) merge 731. In one example, one of the merged data is concatenated. The combined data is provided as input to the decryptor 730. Then, the verification procedure is performed in other ways, as described above.

FIG. 8 shows a block diagram of an exemplary procedure for verifying a certificate according to an embodiment. In the case where a device sends data that can be verified to avoid subsequent denial, a signature can be generated and sent with the data. As an example, a first device can make a request to a second device, and once the second device executes the request, the first device can indicate that the first device has never made such a request. An anti-repudiation method (such as using a signature) can avoid denial by the first device and ensure that the second device can perform the requested task without subsequent difficulties.

A vehicle computing device 810" (such as the vehicle computing device 110 in FIG. 3 or the computing device 141 in FIG. 1) can send the data Dat" to an external computing device 810' (or generally to any other computing device). The vehicle computing device 810" can use the vehicle private key KLkprivate to generate a signature Sk. The signature Sk can be transmitted to the external computing device 810'. The external computing device 810' can use the data Dat' and the previously received public key KLkpublic (for example, the vehicle public key) for verification. In this way, the signature verification is performed by encrypting the signature with a private key and decrypting the signature with a public key. In this way, the unique signature of each device can be kept secret from the device sending the signature, while allowing the receiving device to decrypt the signature for verification. This is in contrast to data encryption/decryption, which is encrypted by the sending device using the public key of the receiving device and decrypted by the receiving device using the private key of the receiver. In at least one example, the vehicle can verify the digital signature by using an internal cryptographic program, such as elliptic curve digital signature (ECDSA) or a similar program.

Due to the exchange and verification of certificates and public keys, devices can communicate with each other in a secure manner. When a vehicle approaches an external entity (such as a trusted zone boundary, a border security entity, or generally an electronic control host device), the respective communication devices (which have the ability to verify the respective certificates shown in Figure 7) exchange certificates and Communicate with each other. After authentication (for example, after receiving/verifying the certificate and public key from an external entity), the vehicle can therefore transmit all required information related to it and stored in its memory, such as license plate number/ID, VIN, insurance number, Driver information (such as ID, final permission for border transition), passenger information, cargo information and the like. Then, after checking the received information, the external entity sends the result of the transition request to the vehicle. This information may be encrypted with the public key of the receiver. The exchange of messages/information can be encrypted/decrypted using the aforementioned DICE-RIoT protocol. In some embodiments, so-called immutable information (such as license plate number/ID, VIN, insurance number) is not encrypted, and other information is encrypted. In other words, in the exchange of messages, there can be unencrypted data and encrypted data: information can therefore be encrypted or unencrypted or mixed. Then, the correctness of the message is ensured by using the certificate/public key to verify that the content of the message is valid.

FIG. 9 shows a method of verifying the identity of an computing device using an identifier, a certificate, and a key according to an embodiment. For example, the method of FIG. 9 can be implemented in the system of FIG. 1 to FIG. 7.

The method of FIG. 9 may include hardware (such as processing devices, circuits, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuits, etc.), software (such as running on a processing device or The executed instruction) or a combination of processing logic is executed. In some embodiments, the method of FIG. 9 is at least partially executed by the identification component 147 and the verification component 151 of FIG. 1.

Although shown in a specific sequence or order, unless otherwise specified, the order of the program can be modified. Therefore, the illustrated embodiments should only be understood as examples, and the illustrated procedures may be executed in a different order, and some procedures may be executed in parallel. In addition, one or more procedures may be omitted in various embodiments. Therefore, not all procedures are required in every embodiment. Other procedures are feasible.

In block 921, a message is received from a host device. For example, the computing device 141 receives a message (such as "host message" or "host message|freshness") from the host device 151.

In block 923, an identifier, a certificate, and a secret key (for example, a public key K _L1 public) are generated. The identifier is associated with an identity of a computing device. The certificate is generated using the message from the host device (such as "host message"). In one embodiment, the message is combined with the public key before encryption. This encryption uses the private identifier ID _L1 private as a key. The private identifier ID _L1 private is associated with the public identifier ID _L1 public (for example, an associated pair generated by the asymmetric ID generator 520).

In one example, the identification component 147 generates an identifier, a credential, and a key to provide a triplet. In an example, triples are generated based on the DICE-RIoT protocol. In an example, triples are generated as shown in FIG. 6.

In one example, using the DICE-RIoT protocol, each layer (L _k ) provides a set of keys and certificates to the next layer (L _k+1 ), and each certificate can be verified by the receiving layer. The Fusion Derived Secret (FDS) is calculated as follows: FDS=HMAC-SHA256 [UDS, SHA256(" _{identity of L 1} ")]

In one example, a DICE-RIoT architecture of layer ₁ L 1 using the credentials generated by one of the host device sending host message. Layer 1 calculates the two associated key pairs as follows: (ID _{lk public} , ID _{lk private} ) and (KL _{k public} , KL _{k private} )

Layer 1 also calculates the two signatures as follows: K'=encryption (ID _{lk private} , KL _{k public} | host message) K''=encryption (KL _{k private} , K')

Since the above processing, layer 1 provides triples as follows: K _L1 = {ID _{L1 public} , ID _L1 credential, K _{L1 public} } More specifically, each layer provides triples as follows: K _Lk = {key and credential The group}, where k=1:N uses their own triples, and each layer can prove its identity to the next layer.

In one example, layer 2 corresponds to application firmware, and subsequent layers correspond to an application program of an operating system and/or host device.

In block 925, the generated identifier, certificate, and key are sent to the host device. The host device uses the identifier, certificate, and key to verify the identity of the computing device. In an example, the host device 151 receives the identifier, the credential, and the key from the computing device 141. The host device 151 uses the verification component 153 to verify the identity of the computing device.

In one example, the verification component 153 performs a decryption operation as part of the verification process. Decryption includes combining the message and certificate from the host before decryption using the key received by the self-calculating device 141. In one example, the verification of the identity of the computing device is performed as shown in FIG. 7.

In an example, the decryption operation is performed as follows: Use KL _{1 public to} decrypt (ID _L1 certificate) to provide K'Use ID _{L1 public to} decrypt K'to provide the result of comparison with KL _{1 public} . If the result is equal to KL _{1 public} , the identity is verified. In one example, the identity of an application board is verified.

In one example, the identity of a person or one of the animals is proved. Similar to the verification of the identity of a computing device 141 (as described above), the verification of the identity of a person is performed. In one example, the computing device 141 is integrated into a passport of one person. A public administration in a country that has issued a passport can use a UDS dedicated to a type of document (such as a driver’s license, passport, ID card, etc.). For example, the UDS of the Messina Passport Office in Sicily, Italy = 0x12234...4444. UDS=0xaabb...00322 of the Munich Passport Office of Bavaria, Germany.

In an example of a passport, the identity of L1 is the following ASCII string: Country|Document Type|etc (e.g. "Italy, Sicily, Messina Passport Office") The "granularity" of the distribution can be determined by the public administration of each country.

Various embodiments of the method of Figure 9 provide various advantages. For example, a thing can be identified and authenticated as being produced by a specific factory instead of using a third-party key infrastructure (for example, PKI=Public Key Infrastructure). Prevent malicious or hacking attacks due to being protected by replays. The method can be used for mass production of things.

In addition, the client UDS is protected at the hardware level (for example, layer 0 cannot be accessed outside the component). UDS cannot be read by anyone, but it can be replaced (for example, only the customer can do so by using a security protocol). Examples of security protocols include security protocols based on authentication and replay protection commands and/or secret sharing algorithms (such as Diffie-Hellman (such as ECDH elliptic curve Diffie-Hellman)). In one example, the UDS is delivered to the customer (rather than the end user) by using a secure infrastructure. UDS can be customized by customers.

In addition, component identification can work without an Internet or other network connection. In addition, the method can be used to easily check the identity of things, animals, and humans at the borders of a trust zone (such as a national border, internal checkpoints, etc.).

In one example, the knowledge of UDS allows the host device to safely replace the UDS. For example, it can be replaced in the following situations: the host expects to change the identity of a thing or the host expects that anyone else (including the original manufacturer) does not know the identity of the thing.

In another example, a replacement command is used by the host device. For example, the host device can send a replacement UDS command to the computing device. The replacement command includes the existing UDS and the new UDS assigned to the computing device. In one example, the replacement command has a field containing one of the following hash values: hash (existing UDS|new UDS).

In another example, one of the following fields is used to identify the replay protection command: Replace_command|Freshness|Signature Where signature=MAC[key, Replace_command|freshness|hash (existing UDS|new UDS)] The key is an additional key and is a key used for authentication commands existing on the device. For example, the key may be a session key, as will be described below (for example, refer to FIG. 12).

In one embodiment, a method includes: receiving a message from a host device (such as host device 151) by a computing device (such as computing device 141); generating an identifier, a certificate, and a key by the computing device, wherein The identifier is associated with an identity of the computing device, and a certificate use message is generated; and the computing device sends the identifier, certificate, and key to the host device, where the host device is configured to use the identifier, certificate, and key to verify The identity of the computing device.

In one embodiment, the verification of the identity of the computing device includes a concatenated message and a certificate to provide the first data.

In one embodiment, verifying the identity of the computing device further includes using a key to decrypt the first data to provide the second data.

In one embodiment, verifying the identity of the computing device further includes using the identifier to decrypt the second data to provide a result and a comparison result and a key.

In one embodiment, the identifier is a public identifier, and the computing device stores a secret key. The method further includes: using the secret key as an input of a message authentication code to generate a derived secret; wherein the public identifier uses the derived secret Generated as an input of an asymmetric generator.

In one embodiment, the identifier is a first public identifier, and the computing device stores a first device secret used to generate the first public identifier. The method further includes: receiving a replacement command from the host device; and responding to receiving The replacement command replaces the first device secret with a second device secret; and sends a second public identifier generated using the second device secret to the host device.

In one embodiment, the key is a public key, and the generated certificate includes a concatenated message and the public key to provide a data input for encryption.

In one embodiment, the identifier is a public identifier, and a first asymmetric generator generates a public identifier and a private identifier as an associated pair; the key is a public key, and a second asymmetric The generator generates a public key and a private key as an associated pair; and generating a certificate includes: concatenating the message and the public key to provide the first data; encrypting the first data with a private identifier to provide the second data; and using the private key Encrypt the second data to provide credentials.

In one embodiment, the key is a public key, and the method further includes generating a random number as an input of an asymmetric key generator, wherein the public key and an associated private key are generated using the asymmetric key generator.

In one embodiment, the random number is generated using a physical uncopyable function (PUF).

In one embodiment, a system includes: at least one processor; and memory, which contains instructions configured to instruct at least one processor: send a message to a computing device; receive an identifier from the computing device A certificate and a key, wherein the identifier is associated with an identity of the computing device, and the certificate is generated by the computing device using information; and the identifier, the certificate and the key are used to verify the identity of the computing device.

In one embodiment, verifying the identity of the computing device includes: concatenating a message and a certificate to provide first data; using a key to decrypt the first data to provide second data; using an identifier to decrypt the second data to provide a result; and Compare the result with the key.

In one embodiment, the identifier is a first public identifier, the computing device stores a first device secret used to generate the first public identifier, and the instruction is further configured to instruct at least one processor: replace a The command is sent to the arithmetic device, and the replacement command causes the arithmetic device to replace the first device secret with a second device secret; and the self-calculating device receives and generates a second public identifier using the second device secret.

In one embodiment, the computing device is configured to use the second device secret as an input to provide a message authentication code of a derived secret and use the derived secret to generate the second public identifier.

In one embodiment, the replacement command includes a field having a value based on the first device secret.

In one embodiment, the system further includes a freshness mechanism configured to generate a freshness, wherein the message sent to the computing device includes freshness.

In one embodiment, the identity of the computing device includes a string of words and numbers.

In one embodiment, a non-transitory computer storage medium stores instructions, which when executed on a computing device, cause the computing device to at least: receive a message from a host device; generate an identifier, a certificate, and a key, The identifier corresponds to an identity of the computing device, and the certificate use message is generated; and the identifier, the certificate and the key are sent to the host device for verifying the identity of the computing device.

In one embodiment, the identifier is a public identifier associated with a private identifier, the key is a public key associated with a private key, and generating a certificate includes: concatenating a message with the public key to provide the first One data; the first data is encrypted with the private identifier to provide the second data; and the second data is encrypted with the private key to provide the certificate.

In one embodiment, verifying the identity of the computing device includes using an identifier to perform a decryption operation to provide a result and a comparison result and a key. Use Physical Uncopyable Function (PUF) to generate values

At least some of the embodiments to be disclosed below provide an improved architecture that uses a physical uncopyable function (PUF) to generate values. In some embodiments, the PUF value itself can be used as a device secret or used to generate a device secret. In an example, the PUF value is used as one of the unique device secrets (UDS) for use with the DICE-RIoT protocol, as described above (for example, see FIGS. 5A and 5B). In one example, a value generated by a PUF is used as an input of a message authentication code (MAC). The output from MAC is used as UDS.

In some embodiments, the PUF value or a value generated from the PUF value can be used as a random number (for example, a device-specific random number). In one example, when generating the associated public key and private key via the aforementioned asymmetric key generator (for example, refer to FIG. 6), a random number (for example, RND) is used as an input.

Generally speaking, the following architecture generates an output by feeding input provided from one or more PUFs into a message authentication code (MAC). The output from the MAC provides an improved PUF (such as the UDS described above).

Generally speaking, semiconductor chip manufacturers face the problem of key injection, which is to program a unique key for each chip or die provided from a semiconductor wafer, for example. It is desirable to program key injection in a secure environment to avoid leakage or reveal the key injected into the chip. It is also desirable to ensure that the key will not be stolen or read back after the chip is produced. For example, in some cases, the key injection procedure is certified or executed by a third-party infrastructure.

Chip manufacturers expect to reduce the production cost of chips that include encryption capabilities. Chip manufacturers also expect to simplify the production process while maintaining a consistent level of safety performance for manufacturing chips. However, key injection is a relatively expensive production step.

Chip manufacturers also face the problem of improving uniformity when PUF is used as a pseudo-random number generator. In some cases, this problem may include a cross-correlation between crystal grains due to the phenomenon on which a seed value provided by the PUF is based.

A PUF is based on unique unpredictable physical phenomena of each die, such as, for example, on-chip parasitics, on-chip path delays, and so on. These phenomena are used, for example, to provide a seed value of a pseudo-random number generator.

The two different wafers selected in the production line must have different PUF values. During the life of the device, the PUF value generated in each chip cannot be changed. If two chips have similar keys (for example, there is a low Hamming distance between the chips), one of the chips can be used to guess the key of the other chip (for example, hacking) .

Using the improved PUF architecture described below can provide a solution to one or more of the above problems by providing output values suitable for providing a PUF function on each chip or die. The following improved PUF architecture uses a PUF, which enables each chip or die to automatically generate a unique security key when each chip or die is powered on. The security key does not need to be stored in a non-volatile memory that may be hacked or otherwise damaged.

The improved PUF architecture further uses a MAC to generate an improved PUF output (such as a unique key) for use in, for example, cryptographic functions or programs integrated into a semiconductor chip. Using MAC can, for example, increase the Hamming distance between keys generated on different chips.

In at least some embodiments disclosed herein, an improved PUF architecture using one of the outputs from a MAC is provided as a way to generate seeds or other values. Therefore, the improved PUF architecture provides, for example, a way to perform key injection, which reduces manufacturing costs and improves the reliability and/or uniformity of PUF operations on the final chip.

In one embodiment, a method includes: providing at least one value from at least one PUF; and generating a first output based on a MAC, wherein the MAC uses at least one value provided by the at least one PUF as an input for generating the first output .

In one embodiment, a system includes: at least one PUF device; a message authentication code (MAC) module configured to receive a first input based on at least one value provided by at least one PUF device; at least one processing器; and memory, which contains instructions configured to instruct at least one processor to generate a first output from the MAC module based on the first input. In various embodiments, the MAC module can be implemented using hardware and/or software.

In one embodiment, the system further includes a selector module for selecting one or more of the PUF modules used to provide the value to the MAC module. For example, values provided from several PUF devices can be linked and provided as one of the inputs of the MAC module. In various embodiments, the selector module can be implemented using hardware and/or software.

FIG. 10 shows a system for generating a unique key 125 by receiving an input, a message authentication code (MAC), and an output from a physical uncopyable function (PUF) device 121 according to an embodiment. The system provides a PUF structure 111 for generating a unique key 125 (or other value) from an output of a message authentication code (MAC) module 123. The MAC module 123 receives an input value from the PUF device 121.

The PUF device 121 in FIG. 10 can be, for example, any of various known types of PUF. The MAC module 123 provides, for example, a one-way function, such as SHA1, SHA2, MD5, CRC, TIGER, and so on.

The framework 111 can, for example, improve the PUF value or Hamming distance of codes generated between chips. The MAC function is unpredictable (for example, only an input sequence with a unitary difference provided to the MAC function provides two completely different output results). Therefore, it is impossible to identify or determine the input of the MAC function when only the output is known. The architecture 111 can also, for example, improve the uniformity of PUF as a pseudo-random number generator.

In one example, the value generated by the PUF structure 111 (for example, the unique key 125 or another value) may be a number with N bits, where N depends on the chip containing the PUF structure 111 (for example, memory The device 103 or another device) implements a cryptographic algorithm. In one example, the chip implementation uses a cryptographic function of HMAC-SHA256. In this case, the output from the MAC module 123 has a size N of 256 bits. The output from the MAC module 123 is used to provide a message length suitable for use as an output value of a key (without further compression or padding).

The PUF architecture 111 is implemented by a device (such as the memory device 103 shown), or can be implemented with other types of computing devices (such as, for example, an integrated circuit implemented in a number of semiconductor chips provided by a wafer manufacturing line ) Implementation.

In one embodiment, the MAC module 123 and the cryptographic module 127 cooperate and/or are integrated into the cryptographic module 127 or are part of the cryptographic module 127. For example, the cryptographic module 127 can provide the cryptographic function of the memory device 103 . For example, since the MAC is used by the memory device 103 for other cryptographic purposes, the output of the MAC module 123 can be suitably used as a key.

The operation of the PUF structure 111, the cryptographic module 127, and/or other functions of the memory device 103 can be controlled by a controller 107. The controller 107 may include, for example, one or more microprocessors.

In FIG. 10, a host 101 can communicate with the memory device 103 via a communication channel. The host 101 can be a computer with one or more central processing units (CPUs), via a computer peripheral device (such as a memory device 103), via an interconnect (such as a computer bus (such as a peripheral component interconnection (PCI)). ), Expansion PCI (PCI-X), Fast PCI (PCIe)), a communication part and/or a computer network) to attach the CPU.

In one embodiment, the unique key 125 is used as a UDS to provide an identity of the memory device 103. The controller 107 implements layer 0 L ₀ and layer 1 L ₁ in a DICE-RIoT architecture. In response to receiving host messages from the host 101 via the host interface 105, the cryptographic module 127 performs processing to generate triples, as described above. The host 101 uses the triples to verify the identity of the memory device 103. The memory device 103 is an example of the computing device 141.

For illustrative purposes, it should be noted that there are usually two technical problems. The first question is to prove the identity of the board to the host. The problem can be handled by using public triples and asymmetric ciphers, as discussed above for DICE-RIoT. This method is safe and simple, but in some cases, it is too expensive/time-consuming to be directly used by a circuit board itself. A second question is to prove the identity of the memory on the board to the board (for example, to avoid unauthorized memory replacement) (this (for example) is executed after each power-on). The second problem can be solved using the above-mentioned public triples and asymmetric ciphers. However, a lighter security mechanism based only on a MAC function is usually sufficient to deal with the second problem.

The memory device 103 can be used to store the data of the host 101 in, for example, a non-volatile storage medium 109. Examples of memory devices generally include hard disk drives (HDD), solid state drives (SSD), flash memory, dynamic random access memory, magnetic tape, network attached storage devices, and so on. The memory device 103 has a host interface 105 that uses a communication channel to implement communication with the host 101. For example, in one embodiment, the communication channel between the host 101 and the memory device 103 is a fast peripheral component interconnect (PCI Express or PCIe) bus; and the host 101 and the memory device 103 use the NVMe protocol (non-volatile Memory Host Controller Interface Specification (NVMHCI), also known as Fast NVM (NVMe)) communicate with each other.

In some embodiments, the communication channel between the host 101 and the memory device 103 includes a computer network, such as a local area network, a wireless local area network, a wireless personal area network, a cellular communication network, A broadband high-speed full-time connection wireless communication connection (such as a current or future generation mobile network link); and the host 101 and the memory device 103 can be configured to use data storage management and use commands (similar to the data storage in the NVMe protocol Management and use commands) to communicate with each other.

The controller 107 can run the firmware 104 to perform operations in response to communications from the host 101 and/or other operations. Firmware is generally a type of computer program that provides control, monitoring, and data manipulation of engineering computing devices. In FIG. 10, the firmware 104 controls the operation of the controller 107 when operating the memory device 103, such as the operation of the PUF architecture 111, as will be discussed further below.

The memory device 103 has a non-volatile storage medium 109, such as a magnetic material coated on a rigid disk and/or a memory cell in an integrated circuit. The storage medium 109 is non-volatile, because power is not required to maintain the data/information stored in the non-volatile storage medium 109, and the data/information can be retrieved after the non-volatile storage medium 109 is powered off and then powered on again. Memory cells can be implemented using various memory/storage technologies (such as flash memory based on NAND gate, phase change memory (PCM), magnetic memory (MRAM), resistive random access memory and 3D XPoint) , So that the storage medium 109 is non-volatile and can store the data stored in it for days, months, and/or years without power.

The memory device 103 includes a volatile dynamic random access memory (DRAM) 106 for storing run-time data and commands. The run-time data and commands are used by the controller 107 to improve the computing performance of the controller 107 and/or provide it in A buffer for data transferred between the host 101 and the non-volatile storage medium 109. The DRAM 106 is volatile because it needs power to maintain the data/information stored in it. When the power is interrupted, the data/information is lost instantly or quickly.

The volatile DRAM 106 generally has less delay than the non-volatile storage medium 109, but loses its data quickly when power is removed. Therefore, it is advantageous to use the volatile DRAM 106 to temporarily store the instructions and data for the controller 107 to perform its current operation tasks to improve performance. In some cases, the volatile DRAM 106 is replaced with a volatile static random access memory (SRAM) that uses less power than DRAM in some applications. When the non-volatile storage medium 109 has the same data access performance as the volatile DRAM 106 (for example, in terms of delay and read/write speed), the volatile DRAM 106 can be eliminated; and the controller 107 can operate the non-volatile The instructions and data on the storage medium 109 are not operated on the volatile DRAM 106 to perform calculations.

For example, cross-point storage and memory devices (such as 3D XPoint memory) have data access performance equivalent to that of the volatile DRAM 106. A cross-point memory device uses non-transistor memory elements, each of which has a memory cell and a selector stacked together as a column. The memory element pillars are connected via two vertical wire layers, one of which is located above the memory element pillar and the other layer is located below the memory element pillar. Each memory device can be individually selected at one of the intersections of one of the wires on each of the two layers. The cross-point memory device is fast and non-volatile and can be used as a unified memory pool for processing and storage.

In some examples, the controller 107 has an in-processor cache, which has better data access performance than the volatile DRAM 106 and/or the non-volatile storage medium 109. Therefore, during the operation of the controller 107, the part of the instruction and data used in the current operation task is cached in the cache memory in the processor of the controller 107. In some cases, the controller 107 has multiple processors, each of which has its own internal cache memory.

The controller 107 uses the data and/or instructions organized in the memory device 103 to perform data-intensive in-memory processing as appropriate. For example, in response to a request from the host 101, the controller 107 performs real-time analysis of a set of data stored in the memory device 103 and responsively transmits a reduced data set to the host 101. For example, in some applications, the memory device 103 is connected to a real-time sensor to store sensor input; and the processor of the controller 107 is configured to perform machine learning and/or pattern recognition based on the sensor input It supports the implementation of an artificial intelligence (AI) system at least partially through the memory device 103 and/or the host 101.

In some embodiments, the processor of the controller 107 is integrated with the memory (such as 106 or 109) in the manufacture of computer chips to achieve in-memory processing and thus overcome the von Neumann bottleneck, which is due to the combination of a processor and The delay of data movement between the memory separately configured according to the Van Neumann architecture causes a limitation of the processing capacity and limits the computing performance. The integration of processing and memory improves processing speed and memory transfer rate and reduces latency and power usage.

The memory device 103 can be used in various computing systems, such as a cloud computing system, an edge computing system, a fog computing system, and/or a stand-alone computer. In a cloud computing system, remote computer servers are connected in a network to store, manage, and process data. An edge computing system optimizes cloud computing by performing data processing at the edge of a computer network close to the data source and thus reduces communication with a central server and/or data storage. A fog computing system uses one or more end-user devices or devices close to the user's edge to store data and therefore reduces or eliminates the need to store data in a central data warehouse.

At least some of the embodiments disclosed herein can be implemented using computer commands (such as firmware 104) executed by the controller 107. In some cases, the hardware circuit can be used to implement at least some of the functions of the firmware 104. The firmware 104 can be initially stored in the non-volatile storage medium 109 or another non-volatile device and loaded into the volatile DRAM 106 and/or the in-processor cache for execution by the controller 107.

For example, the firmware 104 can be configured to operate the PUF architecture using the techniques discussed below. However, the techniques discussed below are not limited to use in the computer system of FIG. 10 and/or the examples discussed above.

In some embodiments, the output of the MAC module 123 can be used to provide, for example, a key or a seed value. In other embodiments, the output can be used to generate one or more session keys.

In one embodiment, the output from the MAC module 123 can be transmitted to another computing device. For example, the unique key 125 can be transmitted to the host 101 via the host interface 105.

FIG. 11 shows a system for generating a unique key 125 from an output of the MAC 123 according to an embodiment. The MAC 123 is free to a selector module 204 to select one or more PUF devices to receive input. According to an embodiment, the system uses a PUF architecture similar to the architecture 111 of FIG. 10 but including a plurality of PUF devices 202 and selector modules 204 to generate a unique key 125 from one of the MAC modules 123 output. The MAC module 123 frees the selector module 204 to select one or more PUF devices 202 to receive input. In an example, PUF device 202 includes PUF device 121.

The PUF devices 202 may, for example, be the same or different (e.g., based on different random physical phenomena). In one embodiment, the selector module 204 acts as a smart PUF selection block or circuit to select one or more of the PUF devices 202 that provide the value obtained therefrom as input to the MAC module 123.

In one embodiment, the selector module 204 makes the selection of the PUF device 202 based at least in part on the results from the test PUF device 202. For example, the selector module 204 can test the repeatability of each PUF device 202. If any PUF device 202 fails the test, the selector module 204 refuses to use the failed device to provide an input value to the MAC module 123. In one example, failed devices can be eliminated temporarily or indefinitely.

In some implementations, the selector module 204 allows the PUF function of each chip to be tested during production and/or during field use (for example, by checking the repeatability of the values provided by each PUF device 202). If two or more values provided by a given PUF device are different, the PUF device is judged as a failure and rejected as one of the inputs of the MAC module 123.

In one embodiment, the selector module 204 is used to simultaneously use multiple PUF devices 202 as a source for calculating an improved PUF output from the MAC module 123. For example, the selector module 204 can link a value from a first PUF device and a value from a second PUF device to provide as an input to the MAC module 123. In some implementations, this architecture allows a robust PUF output to be obtained due to its dependence on several different physical phenomena.

Figure 12 shows a system for generating a unique key from an output of a MAC according to an embodiment. The MAC receives input from one or more PUF devices and an input from a monotonic counter 302 (and/or from another A freshness institution (such as NONCE, time stamp, etc.) receives an input). According to an embodiment, the system generates a unique key 125 from one of the MAC modules 123 output. Except for including a monotonic counter 302 to provide the value to the selector module 204, the PUF structure shown in FIG. 12 is similar to the PUF structure shown in FIG. 11. In various embodiments, the monotonic counter 302 can be implemented using hardware and/or software.

The MAC module 123 receives input from one or more PUF devices 202 and an input from the monotonic counter 302. In one example, the values obtained from the PUF device 202 and the monotonic counter 302 are linked and connected as an input and provided to the MAC module 123. In some embodiments, the monotonic counter 302 is a non-volatile counter that increments only one of its values when requested. In some embodiments, the monotonic counter 302 is incremented after each power cycle of a wafer.

In some embodiments, the PUF architecture of FIG. 12 can be used to provide a way to securely share keys between a semiconductor chip and other components in an application (such as, for example, a public key mechanism).

In some implementations, the monotonic counter 302 is incremented before each calculation of a PUF, which ensures that the input of the MAC module 123 is different in each cycle, and the provided output (and/or output pattern) is therefore different. In some instances, this method can be used to generate a session key, where each session key is different.

In some embodiments, the selector module 204 can selectively include or exclude the monotonic counter 302 (or other freshness mechanism, such as NONCE, time stamp) to provide a counter value as an input of the MAC module 123.

In some embodiments, the monotonic counter 302 is also used by the cryptographic module 127. In some embodiments, a PUF architecture including a monotonic counter can be used as a session key generator to ensure that a different key in each cycle is different. In some implementations, the generated session key is protected in this way: session key=MAC [one or more PUF|MTC or other freshness].

In other embodiments, a mechanism is used as follows: Session key=MAC _{key_based} [Root_Key, MTC, or other freshness mechanism] Where Root_Key=an output value provided from the above-mentioned MAC module 123 or any other type existing on the chip Key. The above-mentioned MAC _{key_based} function is, for example, a MAC algorithm based on a key. For example, there can be two types of MAC algorithms in a password: 1. An algorithm based on a key, such as (for example) the HMAC family (HMAC-SHA256 is based on a key); 2. One that is not based on a key Algorithms, such as SHA256 (SHA alone is not based on keys). It should be noted that the key-based MAC can be converted in the non-key-based MAC by setting the key to a known value (for example, 0x000...0xFFFF, etc.).

FIG. 13 shows a method of generating an output from one or more inputs provided by one or more PUFs from a MAC according to an embodiment. For example, the method of FIG. 13 can be implemented in the memory device 103 of FIG. 10.

The method of FIG. 13 includes in block 411, one or more values are provided by at least one PUF (for example, values are provided from one or more of PUF devices 202).

In block 413, the repeatability of one or more of the PUFs may be tested, for example, as described above. This test is optional.

In block 415, if the test has been performed in block 413 and it has been determined that a PUF device has failed the test, the failed PUF device is rejected and provides an input to the MAC. This exclusion can be performed by, for example, the selector module 204, as discussed above.

In block 417, a value is provided from a monotonic counter (eg, monotonic counter 302). The use of monotonic counters in the PUF architecture is optional.

In block 419, an output is generated from the MAC, and the MAC uses one or more values provided by the PUF (and optionally at least one value from the monotonic counter) as the input of the MAC.

Various other embodiments of a method implemented in a computing device will now be described below. The method includes: providing at least one value by at least one physical uncopyable function (PUF); and generating a second value based on a message authentication code (MAC) An output, where the MAC uses at least one value provided by at least one PUF as an input for generating the first output.

In one embodiment, the computing device is a first computing device, and the method further includes transmitting the first output to a second computing device, wherein the first output is a unique identifier of the first computing device.

In one embodiment, providing at least one value includes selecting a first value from a first PUF and selecting a second value from a second PUF.

In one embodiment, the method further includes: providing a value from a monotonic counter; wherein generating the first output further includes using the value from the monotonic counter as an additional input of the MAC for generating the first output.

In one embodiment, the method further includes: generating a plurality of session keys based on respective outputs provided by the MAC, wherein the monotonic counter provides a value used as an input to the MAC; and incrementing the monotonic counter after each of the session keys is generated.

In one embodiment, the method further includes: testing the repeatability of the first PUF of one of the at least one PUF; and based on determining that the first PUF test fails, rejecting the first PUF to provide any input to the MAC when generating the first output.

In one embodiment, the test includes comparing two or more values provided by the first PUF.

In one embodiment, the computing device is a memory device, and the memory device includes a non-volatile storage medium configured to store an output value generated using MAC.

In an embodiment, the method further includes executing at least one cryptographic function by at least one processor, wherein executing the at least one cryptographic function includes generating an output value using MAC.

In one embodiment, a non-transitory computer storage medium stores instructions. When the instructions are executed on a memory device (such as memory device 103), the memory device causes the memory device to execute a method. The method includes: The function (PUF) provides at least one value; and generates a first output based on a message authentication code (MAC), wherein the MAC uses at least one value provided by the at least one PUF as an input for generating the first output.

In various other embodiments to be described below, the method of FIG. 4 can be executed on a system, and the method includes: at least one physical uncopyable function (PUF) device; a message authentication code (MAC) module, which is configured Receive a first input based on at least one value provided by at least one PUF device; at least one processor; and memory, which contains instructions configured to instruct at least one processor to generate from the MAC module based on the first input A first output.

In one embodiment, the MAC module includes a circuit. In one embodiment, the first output from the MAC module is to identify a key of a die. In one embodiment, the first output from the MAC module is a key, and the instructions are further configured to instruct at least one processor to use one of the outputs from the MAC module to generate a session key.

In one embodiment, the system is part of a semiconductor chip (for example, one of several chips obtained from a semiconductor wafer), the first output from the MAC module is a unique value of the identification chip, and the commands are further grouped State to instruct at least one processor to transmit the unique value to an arithmetic device.

In one embodiment, at least one PUF device includes a plurality of PUF devices (such as PUF device 202), and the system further includes a selector module configured to select at least one PUF device that provides at least one value.

In one embodiment, the selector module is further configured to generate the first input of the MAC module by linking a first value from a first PUF device and a second value from a second PUF device .

In one embodiment, the system further includes a monotonic counter configured to provide a counter value, and the instruction is further configured to instruct at least one processor to link the counter value with at least one value provided by the at least one PUF device To generate the first input.

In one embodiment, the system further includes a selector module configured to select at least one PUF device that provides at least one value, wherein the link counter value and the at least one value provided by the at least one PUF device are provided by the selector module implement.

In one embodiment, the monotonic counter is further configured to increment the counter value to provide an increment value after generating the first input; and the instruction is further configured to instruct at least one processor to be based on the increment value and provided by at least one PUF device The at least one new value is generated from the MAC module to generate a second output.

Figure 14 shows a system for generating a key from an output of a MAC and adding an additional MAC to generate a session key according to an embodiment. The MAC receives input from one or more PUF devices and from a monotonic The counter receives an input (and/or receives an input from another freshness mechanism (such as NONCE, time stamp, etc.)).

In one embodiment, the system generates a root key from an output of a MAC according to an embodiment (MAC receives input from one or more PUF devices 202 and an input from a monotonic counter 302 (and/or from another The organization (such as NONCE, time stamp, etc.) receives an input)) and adds an additional MAC module 504 to use a key input to generate a session key. In this embodiment, the MAC module 123 provides the root key 502 as the output from the MAC module 123. The root key 502 is an input of the MAC module 504, and the MAC module 504 can use a MAC function, such as session key=MAC _{key_based} [Root_Key, MTC or other freshness mechanism], as described above. The root key input in this key-based function can be the root key 502 shown.

In addition, in one embodiment, the monotonic counter 302 can provide one of the inputs of the MAC module 504. In other embodiments, instead of using the monotonic counter 302, a different monotonic counter or other value from the chip can be provided as one of the inputs of the MAC module 504. In some cases, the monotonic counter 302 provides a counter value to the MAC module 504 instead of the selector module 204. In other cases, the counter value can be provided to or excluded from both MAC modules. Key generation and secure storage

As mentioned above, PUF can be used for security key generation. The various embodiments discussed below relate to generating an initial key using at least one PUF, applying processing to increase the obfuscation of the initial key, and storing the final obfuscated key in a non-volatile memory. The final obfuscation key and/or an intermediate key used to generate the final obfuscation key can be shared with another computing device and used for secure communication with another computing device (for example, using a symmetric cipher to transmit messages based on a shared key). In some embodiments, security key generation is performed for a computing device used in automotive applications (for example, a controller in an autonomous vehicle).

In an alternative embodiment, the initial key is generated in other ways that do not require the use of at least one of the aforementioned PUF devices. In one embodiment, the initial key can be generated by using an injected key. For example, the initial key exists in a chip due to being injected in a factory or other secure environment. In this case, the application process is performed by applying the obfuscation process to the injected key to increase the confusion of the initial key.

The automotive environment has a technical problem of introducing "noise" during the key generation phase. The following various embodiments provide a technical solution to this problem by using a method to reduce or avoid key changes. The key changes are attributed to the confusion induced by storing an obfuscated key in a non-volatile memory area. News.

The automotive environment can affect key generation in various ways. For example, powering on an engine can cause the power applied to a computing device to drop, causing a key to be generated in an erroneous manner. The extreme temperature will also affect the circuit that generates the key. Other sources (such as magnetic fields from power lines) can cause inter-symbol interference or crosstalk so that a host cannot recognize the device.

In contrast, if the key is generated in a secure environment and stored in memory, it will be protected from noise. A secure environment can, for example, be directly installed in a car, a test environment, or a factory (for example, it manufactures computing devices that generate keys), depending on the use of computing device products for dissemination between end users/customers Key strategy.

In one example, ADAS or other computing systems used in vehicles are subject to power supply changes. This can occur during, for example, starting the vehicle, braking, powering the engine, and so on.

As will be discussed below, various embodiments for generating and storing a key provide the advantage of being substantially independent of external factors such as power supply fluctuations, temperature, and other external noise sources. In some embodiments, another advantage is that, for example, the key vector generated in each cycle is the same.

When storing the key, another advantage provided in some embodiments is that the key is substantially protected from hardware attacks (such as hardware attacks that can be done by hackers). For example, an attack is to monitor the power-on current of a device so that current changes are associated with the bits associated with the key. Other attacks can use (for example) voltage measurement (for example a Vdd supply voltage). Some attacks can use, for example, temperature changes to interfere with the operation of a device.

In some embodiments, the initial key may be generated using the method and/or architecture described above with respect to FIGS. 10-14. For example, a PUF is used to generate the secret key in each power-on cycle of the computing device storing the secret key. In alternative embodiments, other methods may be used to generate the initial key.

In an exemplary method, as discussed earlier above, the key injection uses at least one PUF and one MAC algorithm (such as SHA256) to generate significantly different from other devices (such as adjacent dies located on a wafer) One key for one device. The MAC encryption algorithm provides the benefit of increasing the entropy of the bits generated by the PUF.

In one embodiment, after performing preprocessing on the key, the generated key (for example, the initial key provided from a PUF and then a MAC algorithm) is stored in a non-volatile area of the device to reduce or Avoid hacker attacks and also improve the reliability of storage keys. In one embodiment, after storing the key, the circuit for generating the key can be disabled. Preprocessing is generally referred to as obfuscation in this article. In one example, circuits and/or other logic are used to obfuscate the device. In one example, the stored key can be read by the device because the key is independent of external noise sources. An internal mechanism is used to read any data of the device.

In various embodiments, storing the key as described herein increases the anti-noise margin. In addition, this makes it difficult for a hacker, for example, to use a power monitoring or other hacking methods to read the stored key.

At least some embodiments herein use a PUF and an encryption algorithm (such as HMAC-SHA256) to generate a key independently of external factors (such as the key that would cause one of the devices to be powered on differently from the temperature or voltage of the next power on) . If this happens, it may be difficult for a host to exchange messages with the device. Various embodiments generate the key more robustly by placing the stored key in the memory so that it is not affected by external factors.

In one embodiment, the key is generated once on a device and stored in the non-volatile memory of the device. In one example, before adding a heavy facility to an SRAM, the contents of the SRAM can be used to generate a key. The key (which is a function of the PUF) is generated using the pseudo-random value output from the PUF. Read the contents of SRAM before resetting equipment or other devices. It is also possible to regenerate the key through a command sequence at other times as desired. In an example, the generated key is used as one of the UDS in the DICE-RIoT protocol, as described above. In one example, the command sequence uses a replacement command to replace a previously generated UDS with a new UDS, as described above.

In one embodiment, the key generation is independent of the encryption implemented by the device. The generated key is shared with a host. This embodiment prevents an attacker from guessing the key and internally using the key (such as, for example, by analyzing the shape of the current drawn by the analysis device during the key use period) to store the key and/or in the reading device. The key.

In addition, for example, in an asymmetric cipher, the generated key becomes a variable pass code, which is the key of the system. The key is not shared with others. For public key cryptography, the key is used to generate a corresponding public key.

In various embodiments, an initial key is generated using an injection key or one or more PUFs (for example, to provide an initial key PUF0). Next, the initial key is subjected to one or more steps of obfuscation processing to provide an intermediate key (for example, PUF1, PUF2, ..., PUF5), such as will be described below. The output from this process (e.g. PUF5) is an obfuscated key stored in the non-volatile memory of the device. When an injected key is used, obfuscation is applied to the injected key, similar to what is described below for the non-limiting example of PUF0.

In one embodiment, as mentioned above, for an initial injection key, a mechanism uses the following: Session key=MAC _{key_based} [Root_Key, MTC or other freshness mechanism] Where: Root_Key=existing on the chip Any other kind of key (for example, the key can be an initial key injected into the chip in a factory or other secure environment)

In one embodiment, during the first power-up of a device, a special sequence wakes up at least one circuit of the device (eg, a read circuit) and verifies that the circuit(s) are operating properly. Next, the device generates an initial key PUF0, as mentioned above. This key can be stored or further processed to make it more robust for secure storage, as will be described below.

An intermediate key PUF1 is generated by concatenating PUF0 with a predetermined bit sequence (for example, a sequence known from another) to generate PUF1. In one embodiment, PUF1 is used to verify that the device reads the key correctly and to ensure that noise (such as fluctuations in power supply) does not affect the ability of the generated key.

Generate the next intermediate key PUF2. PUF1 is interleaved with an inverted phase element pattern (for example, formed by inverting the bits of PUF1, and sometimes referred to as inverted PUF1 herein) to generate PUF2.

In one embodiment, PUF2 has the same bit number of 0 and 1. The shape of the device current used for any key (for example, any key stored on the device) is substantially the same. This reduces the possibility that a hacker can guess the key value by looking at the shape of the device current when the key is read by the device.

Generate the next intermediate key PUF3. The bits of PUF2 are interleaved with pseudo-random bits to form PUF3. This helps to further obfuscate the key. In one embodiment, the pseudo-random bits are derived from PUF1 or PUF2 by using a hash function. For example, these derived bits are added to PUF2 to form PUF3.

Generate the next intermediate key PUF4. The Error Correction Code (ECC) is generated by the internal circuitry of the device (for example, during programming). ECC bits are added to PUF3 to generate PUF4. In one embodiment, the ECC bit helps prevent the aging effects of non-volatile memory (such as NVRAM) caused by, for example, the endurance limit of the device, X-rays, and particles. The aging of non-volatile memory can also be caused by, for example, an increase in the number of electrons in NV cells that can cause bit flips.

Generate the next intermediate key PUF5. PUF5 is one of several copies of PUF4 in series. Make the redundancy of multiple PUF4 copies exist in PUF5 by increasing the possibility of being able to read the key correctly at a later time to further improve the robustness. In one embodiment, several copies of PUF5 are stored in various areas of the non-volatile memory storage to further improve the robustness. For example, even if PUF5 is damaged in one area, PUF5 can be read from other areas and therefore the correct key can be extracted.

In one embodiment, PUF1 or PUF3 is shared with a host for a symmetric cipher or a key used to generate a public key of an asymmetric cipher. In one embodiment, PUF4 and PUF5 are not shared with end users or a host.

The above method is modular, because PUF2, PUF3, PUF4, and/or PUF5 are not required to generate an obfuscated key. On the contrary, in various embodiments, one or more of the aforementioned obfuscation steps can be applied to the initial key, and the order can be further changed. For example, a known system that does not have a Vdd voltage supply drop can reduce the number of aliasing steps.

In one embodiment, when the obfuscated key is stored, the bit pattern disperses the entities in the non-volatile storage medium (for example, in different rows and words). For example, the device can read bits at the same time and prevent multi-bit errors.

FIG. 15 shows an arithmetic device 603 for storing an obfuscated key 635 in a non-volatile memory (such as a non-volatile storage medium 109) according to an embodiment. The arithmetic device 603 is an example of the arithmetic device 141 in FIG. 1. In one example, the obfuscated key is used as a UDS. (Note) For example, obfuscation adds entropy to the bits of the key to prevent a hacker from trying to understand the value of the key. The device can always extract the key by removing the added bits used as obfuscation. In one example, a co-hacking attack consists of guessing the generated/designed secret key inside the device by using statistical tools to process the current distribution absorbed by the device in certain time frames.

An initial key 625 is generated based on a value provided by at least one physical non-copyable function device 121. The obfuscated key 635 is generated based on the initial key 625. After the generation, the obfuscated key 635 is stored in the non-volatile storage medium 109.

In one embodiment, a message authentication code (MAC) 123 uses the value from the PUF device 121 as an input and provides the initial key 625 as an output. In one embodiment, the obfuscation processing module 630 is used to perform processing on the initial key 625 to provide an obfuscation key 635 (such as PUF5), such as discussed above.

In one embodiment, the obfuscation key 635 is securely distributed to another computing device, such as the related U.S. non-temporary "SECURE DISTRIBUTION OF SECRET KEY USING A MONOTONIC COUNTER" filed by Mondello et al. on April 27, 2018. As described in Application No. 15/965,731, the entire content of the case is incorporated into this article as if it were cited in its entirety. In other embodiments, any one or more of the initial key 625 and/or the intermediate key from the obfuscation process described herein can be securely distributed in the same or a similar manner. An end user/customer uses the above method to read the value of an initial key (for example, PUF0), an intermediate key, and/or a final obfuscated key (for example, PUF5) as appropriate. For example, the end user can verify the proper execution of keys generated by the device and/or monitor the statistical quality of key generation.

FIG. 16 shows an example of an intermediate key (PUF2) generated by the obfuscation module 630 during an obfuscation process according to an embodiment. As mentioned above, the bits of PUF1 are inverted to provide an inverted phase element 702. Bit 702 is interleaved with the bit of PUF1 shown. For example, every second bit in the illustrated key is an interleaved inverse phase element 702.

FIG. 17 shows an example of another intermediate key (PUF3) generated during the obfuscation procedure of FIG. 16 according to an embodiment (in this example, PUF3 is based on PUF2). As mentioned above, the bits of PUF2 are further interleaved with pseudo-random bits 802. As shown in the figure, bits 802 are interleaved with PUF2. For example, every third bit in the illustrated key is an interleaved pseudo-random bit 802.

FIG. 18 shows a method for generating an obfuscated key (such as obfuscated key 635) and storing the obfuscated key in a non-volatile memory (such as non-volatile storage medium 109) according to an embodiment. In one example, the memory system 105 of FIG. 2 stores the obfuscated key in the non-volatile memory 121.

In block 911, an initial key is generated based on a value provided by at least one physically uncopyable function (PUF).

In other embodiments, in block 911, the initial key is generated by key injection. For example, during manufacturing, the initial key may only be one value injected into a wafer during manufacturing.

In block 913, an obfuscated key is generated based on the initial key. For example, the generated obfuscated key is PUF3 or PUF5.

In block 915, the obfuscated key is stored in a non-volatile memory of a computing device. For example, the obfuscated key is stored in a NAND flash memory or an EEPROM.

In one embodiment, a method includes: generating an initial key using key injection; generating an obfuscated key based on the initial key; and storing the obfuscated key in a non-volatile memory. For example, the initial key may be a key injected during a key injection procedure at the time of manufacture.

In one embodiment, a method includes: generating an initial key provided by key injection or based on a value provided by at least one physical uncopyable function (PUF); generating an obfuscated key based on the initial key; and The obfuscated key is stored in a non-volatile memory of the computing device.

In one embodiment, generating the initial key includes using a value from the PUF (or another value on the chip, for example) as an input of a message authentication code (MAC) to generate the initial key.

In one embodiment, the obfuscated key is stored in a non-volatile memory outside the user-addressable memory space.

In one embodiment, generating the obfuscated key includes concatenating the initial key and a predetermined pattern of bits.

In one embodiment, concatenating the initial key and the predetermined pattern of bits provides a first key (such as PUF1); and generating the obfuscated key further includes interleaving the first key with an inverse phase element pattern , Where the inverted phase element pattern is provided by inverting the bits of the first key.

In one embodiment, interleaving the first key and the inverse phase element pattern provides a second key (such as PUF2); and generating the obfuscated key further includes interleaving the second key with pseudo-random bits.

In one embodiment, the method further includes using a hash function to derive pseudo-random bits from the first key or the second key.

In one embodiment, interleaving the second key and pseudo-random bits to provide a third bit (such as PUF3); and generating the obfuscated key further includes concatenating the third key and error correction code bits.

In one embodiment, the computing device is a first computing device, and the method further includes sharing at least one of the initial key, the first key, or the third key with a second computing device and receiving and using it from the second computing device A message encrypted by at least one of the initial key, the first key, or the third key.

In an embodiment, concatenating the third key and the error correction code bit provides a fourth key (such as PUF4); and generating the obfuscated key further includes concatenating one of the fourth key and the fourth key or Multiple copies.

In an embodiment, concatenating one or more copies of the fourth key and the fourth key provides a fifth key (for example, PUF5); and storing the obfuscated key includes storing the first copy of the fifth key Stored in at least one of the rows or blocks of non-volatile memory on which the second copy of the fifth key is different from that of the row or block.

In one embodiment, a system includes: at least one physical non-copyable function (PUF) device (such as PUF device 121) configured to provide a first value; a non-volatile memory (such as non-volatile storage) Medium 109), which is configured to store an obfuscated key (such as key 635); at least one processor; and memory, which contains instructions configured to instruct at least one processor: based on at least one PUF The first value provided by the device generates an initial key; generates an obfuscated key based on the initial key; and stores the mixed key in a non-volatile memory.

In one embodiment, the system further includes a message authentication code (MAC) module (such as MAC 123) configured to receive one of the values provided by the at least one PUF device, wherein generating the initial key includes using the first value as the MAC Enter one of the modules to generate the initial key.

In one embodiment, generating the obfuscated key includes at least one of the following: concatenating a key and a predetermined pattern of bits; making a first key and an inverse phase element pattern of the first key Interleaving; interleaving a key and pseudo-random bits; concatenating a key and error correction code bits; or concatenating a second key and one or more copies of the second key.

In one embodiment, the stored obfuscated key has an equal number of 0 bits and 1 bit.

In one embodiment, generating the obfuscated key includes concatenating the initial key and a first pattern of bits.

In one embodiment, concatenating the initial key and the first pattern of bits provides a first key; and generating the obfuscated key further includes interleaving the first key with a second pattern of bits.

In one embodiment, generating the obfuscated key further includes interleaving a key with pseudo-random bits.

In one embodiment, generating the obfuscated key further includes concatenating a key and error correction code bits.

In one embodiment, a non-transitory computer storage medium stores instructions that, when executed on a computing device, cause the computing device to execute a method. The method includes: using at least one physical uncopyable function (PUF) to generate an initial key ; Generate an obfuscated key based on the initial key; and store the obfuscated key in non-volatile memory.

FIG. 19 shows a computing device 1003 for generating an initial key 625 based on key injection 1010, obfuscating the initial key, and storing the obfuscated key in a non-volatile memory according to an embodiment.

In one embodiment, the initial key 625 is generated by using the injected key 1010. For example, the initial key 625 exists in a chip by being injected in a factory or other secure environment during manufacturing or other assembly or testing. In an example, the initial key 625 is used as an initial UDS of the computing device 1003. Confusion can also be imposed on UDS. UDS is the secret that DICE-RIoT started to use to generate keys and credentials for secure generation. The application process is performed by applying the obfuscation process (via the module 630) to the injected key (for example, the value from the key injection 1010) to increase the obfuscation of the initial key. In other embodiments, the obfuscation process can be applied to any other value that can be stored or otherwise existed on a chip or die. Changes in key generation and secure storage

Various additional non-limiting embodiments will now be described below. In one embodiment, after (or during) the first power-on of a system board, a special sequence is initiated to activate a device containing a cryptographic engine (such as a cryptographic module 127). The sequence further wakes up the internal PUF and verifies its function. Then, the PUF generates an initial value PUF0, such as described above. The PUF0 value is processed by an on-chip algorithm (for example, by the obfuscation processing module 630) and written in a special area (outside the user addressable space) of a non-volatile array. In an alternative embodiment, an injection key instead of the PUF0 value is similarly processed by the on-chip algorithm (as described below) to provide an obfuscated key for storage.

In one embodiment, obfuscation is performed to prevent Vdd (voltage) and/or temperature fault hacking attacks. This process involves concatenating PUF0 with a well-known pattern (for example, it contains a fixed amount of 0/1 bits). These bits allow to determine whether the reading circuit can properly distinguish 0/1 bits when reading the PUF value internally during the life of the device (such as a chip). For example, PUF1=PUF0 || 010101…01.

Then, the result of the above processing (for example, PUF1) is further embodied as virtual bits (for example, to avoid Icc hacker analysis). Specifically, for example, the bits of PUF1 are interleaved with an inverted version of PUF1 (ie, inverted PUF1, which is formed by inverting the bits of PUF1). For example, PUF2=PUF1 interleaved inverted PUF1.

In one embodiment, the interleaving rule depends on the type of row decoder (such as a row decoder of an NV non-volatile array) existing on the chip/device. The device ensures that in each reading of the PUF value (from the non-volatile array), the reading circuit processes (in a single time) the same number of bits from PUF1 and inverted PUF1. This ensures that the same number of bits with values 0 and 1 are read, which provides a regular shape of the supply current (Idd).

Then, the bits of PUF2 are further interleaved with pseudo-random bits. In one example, the interleaving depends on the non-volatile array row decoder structure. In one embodiment, the output is such that the same number of PUF2 bits are filled with a specific number of pseudo-random bits (for example, one final residual correlation may exist in the PUF2 pattern for confusion).

In one embodiment, the pseudo-random bits can be derived from PUF1 or PUF2 by using a hash function. Other alternative methods can also be used.

In one embodiment, to reduce or prevent bit loss due to non-volatile aging, PUF3 bits are concatenated with error correction code (ECC) bits as appropriate. In one embodiment, the bit of PUF4 is repeated one or more times as appropriate (it also extends ECC capability). For example, the above situation can be implemented on a NAND memory. In one embodiment, PUF5=PUF4 || PUF4 || ... || PUF4.

In one embodiment, the value of PUF5 can be written two or more times in different rows and/or blocks of a non-volatile memory array.

Due to (for example) the above-mentioned obfuscation process, once the final PUF value is written into a non-volatile array block, the key reliability (for example due to noise or charge loss) or any attempt can be reduced or ignored. Use the value when inferring its value by Idd analysis or forcing its value by Vdd fault attack.

In one embodiment, once the obfuscation processing has been completed, the PUF circuit can be displayed. In one embodiment, after deactivation, the PUF device can provide internal use on a device for other purposes (for example, using a standard read operation inside the non-volatile array).

In one embodiment, when extracting a key from PUF3, the key bits are distinguished from random bits. For example, the internal logic of a device that stores a key knows the location and the method required to restore from PUF 5 to a previous or original PUF (such as PUF3).

In one embodiment, the device extracts the key to know the bit position of the key bit. For example, the internal logic of the device may receive one of the intermediate PUF or the final key PUF5 depending on the design choice. Then, applying the operation(s) in the reverse order will obtain the original PUF. For example, the processing steps from PUF1 to PUF5 are executed in order to store obfuscated PUF in one of the following two ways: read the content (such as the key bits) and also know what is applied to restore and determine the original key (Several) operations. in conclusion

A non-transitory computer storage medium can be used to store the instructions of the firmware 104 or store the instructions of the processor 143 or the processing device 111. When the instruction is executed by, for example, the controller 107 of the memory device 103 or the computing device 603, the instruction causes the controller 107 to perform any of the methods discussed above.

In the [Embodiment Mode], various functions and operations can be described as being executed or caused by computer instructions to simplify the description. However, those skilled in the art should realize that these expressions mean that the functions are derived from the execution of computer instructions by one or more controllers or processors (such as a microprocessor). Alternatively or in combination, dedicated circuits can be used to implement functions and operations with or without software instructions, such as dedicated integrated circuits (ASIC) or field programmable gate arrays (FPGA). The embodiments can be implemented without software instructions or in combination with software instructions using fixed-wire circuits. Therefore, the technology is neither limited to any specific combination of hardware circuits and software, nor is it limited to any specific source of instructions executed by the data processing system.

Although some embodiments can be implemented by fully operating computers and computer systems, various embodiments can be distributed as a computing product in various forms and can be applied, regardless of the specific type of machine or computer-readable medium used to actually affect the distribution.

At least some aspects disclosed may be at least partially embodied in software. That is, the technology can be implemented in a memory (such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device) in response to its processor (such as a microprocessor or microcontroller). The sequence of commands is implemented in a computer system or other data processing system.

The routines executed to implement the embodiments can be implemented as part of an operating system or a specific application, component, program, object, module, or command sequence (referred to as "computer program"). A computer program usually includes one or more instructions of various time settings in various memories and storage devices in a computer, and when the instructions are read and executed by one or more processors in a computer, they cause the computer to execute and execute. The operations required for the elements of the state.

A tangible, non-transitory computer storage medium can be used to store software and data, which, when executed by a data processing system, cause the system to execute various methods. Executable software and data can be stored in various locations including, for example, ROM, volatile RAM, non-volatile memory, and/or cache. Part of this software and/or data can be stored in any of these storage devices. In addition, data and commands can be obtained from a central server or a peer-to-peer network. Different parts of the data and commands can be obtained from different central servers and/or peer-to-peer networks at different times and in different communication sessions or in the same communication session. All data and instructions can be obtained before running the application. Alternatively, the part of the data and instructions can be obtained dynamically and in real time only when it needs to be executed. Therefore, it is not necessary for all the data and instructions to be on a machine-readable medium at a specific point in time.

Examples of computer-readable storage media include (but are not limited to) recordable and non-recordable media, such as volatile and non-volatile memory devices, read-only memory (ROM), random access memory (RAM), fast Flash memory devices, floppy disks and other removable disks, disk storage media and optical storage media (such as CD ROM, digital versatile disc (DVD), etc.), etc. The instructions may be embodied in a temporary medium (such as electrical, optical, acoustic, or other forms of propagated signals, such as carrier waves, infrared signals, digital signals, etc.). A temporary medium is usually used to transmit instructions, but it should not be regarded as capable of storing instructions.

In various embodiments, fixed-wire circuits can be used in combination with software commands to implement the technology. Therefore, the technology is neither limited to any specific combination of hardware circuits and software, nor is it limited to any specific source of instructions executed by the data processing system.

Although some figures show several operations in a specific order, operations that are not related to the order can be reordered and other operations can be combined or interrupted. Although some reordering or other groupings are specifically mentioned, those skilled in the art should be aware of other reorderings or groupings and therefore do not present an exhaustive list of alternatives. Furthermore, it should be recognized that the stages can be implemented in hardware, firmware, software, or any combination thereof.

The above description and drawings are illustrative and should not be construed as limiting. Describe many specific details to provide a thorough understanding. However, in specific examples, well-known or well-known details are not described in order to avoid making the description unclear. Reference to one embodiment of the present invention does not necessarily refer to the same embodiment; and these references mean "at least one."

In the above description, the present invention has been described with reference to specific exemplary embodiments of the present invention. Obviously, various modifications can be made to the present invention without departing from the broader spirit and scope described in the scope of the following patent applications. Therefore, this specification and drawings should be regarded as intended to illustrate rather than limit.

100: computing system/vehicle 101: host system/host 103: bus/memory device 104: Firmware 105: Memory System/Host Interface 106: Volatile Dynamic Random Access Memory (DRAM) 107: Identify component/write component/controller 109: Verify components/non-volatile storage media 110: Vehicle computing device 111: Processing device/memory area/physical non-copyable function (PUF) architecture 113, ..., 119: memory area 120: processor 121: Non-volatile memory/PUF device 123: Volatile memory/message authentication code (MAC) module 125: unique key 127: Password Module 130: In-vehicle communication components 140: Antenna 141: arithmetic device 143: Processor 145: Memory 147: Identify components 149: Device Secret 150: processor 151: host device 153: Verification component 155: Freshness Generator 157: Key Storage 159: Key Generator 160: memory 170: Steering Control System 180: Speed control system 190: Information System 202: PUF device 204: Selector Module 300: Vehicle 302: Monotonic Counter 310: Passive communication components 320: chip 330: Non-volatile storage components 340: Antenna 350: host device 360: processor 370: Memory 380: Antenna 390: System 410': Arrow 410'': Arrow 411: Block 413: Block 415: Block 417: Block 419: Block 430': External communication components 430'': On-board communication components 502: Root Key 504: MAC module 510': Arrow 510'': Arrow 520: Asymmetric ID generator 530: Encryptor 531: pattern (data) merge 540: Asymmetric key generator 550: Extra Encryptor 603: Computing Device 625: initial key 630: Obfuscation Processing Module 635: Confusion key 702: Inverse Phase Element 730: Decryptor 731: Pattern (data) merger 750: Decryptor 760: block 802: pseudo-random bit 810': External computing device 810'': Vehicle computing device 911: block 913: block 915: Block 921: block 923: block 925: block 1003: computing device 1010: Key injection/key injection

The drawings illustrate the embodiments by way of example rather than limitation, wherein the same element symbols indicate similar elements.

FIG. 1 shows a host device for verifying the identity of a computing device according to an embodiment.

Figure 2 shows an exemplary computing system with an identification component and a verification component according to an embodiment.

Fig. 3 shows an exemplary computing device of a vehicle according to an embodiment.

Figure 4 shows an example host device in communication with an example computing device of a vehicle according to an embodiment.

FIG. 5A shows an application board for generating an identifier, a certificate, and a key of a host device according to an embodiment.

FIG. 5B shows an example computing system activated in the stage of using the layer according to an embodiment.

FIG. 6 shows an exemplary computing device that uses an asymmetric generator to generate an identifier, credential, and key according to an embodiment.

FIG. 7 shows a verification component that uses a decryption operation to verify the identity of a computing device according to an embodiment.

FIG. 8 shows a block diagram of an exemplary procedure for verifying a certificate according to an embodiment.

FIG. 9 shows a method of verifying the identity of an computing device using an identifier, a certificate, and a key according to an embodiment.

FIG. 10 shows a system for generating a unique key by receiving an input, a message authentication code (MAC), and an output from a physical uncopyable function (PUF) device according to an embodiment.

FIG. 11 shows a system for freely a selector module to select one or more PUF devices to receive a MAC and output a unique key according to an embodiment.

Figure 12 shows a method for receiving input from one or more PUF devices and receiving an input from a monotonic counter (and/or receiving an input from another freshness mechanism (such as NONCE, time stamp, etc.)) according to an embodiment One output of a MAC generates a unique key system.

FIG. 13 shows a method of generating an output from one or more input values provided by one or more PUFs from a MAC according to an embodiment.

Figure 14 shows a system for generating a key from an output of a MAC and adding an additional MAC to generate a session key according to an embodiment. The MAC receives input from one or more PUF devices and from a monotonic The counter receives an input (and/or receives an input from another freshness mechanism (such as NONCE, time stamp, etc.)).

FIG. 15 shows an arithmetic device for storing an obfuscated key in a non-volatile memory according to an embodiment.

Figure 16 shows an example of an intermediate key generated during an obfuscation procedure according to an embodiment.

FIG. 17 shows an example of another intermediate key generated during the obfuscation procedure of FIG. 16 according to an embodiment.

Figure 18 shows a method for generating an obfuscated key and storing the obfuscated key in a non-volatile memory according to an embodiment.

FIG. 19 shows an operation device for generating an initial key based on key injection, obfuscating the initial key, and storing the obfuscated key in non-volatile memory according to an embodiment.

921: block

923: block

925: block

Claims (18)

An identity verification method comprising: receiving a message from a host device by an arithmetic device; generating an identifier, a certificate and a key by the arithmetic device, wherein the identifier is associated with an identity of the arithmetic device, And the certificate is generated using the message; and the computing device sends the identifier, the certificate, and the key to the host device, wherein the host device is configured to use the identifier, the certificate, and the key to verify The identity of the computing device, wherein the identifier is a first public identifier, and the computing device stores a first device secret for generating the first public identifier, the method further includes: receiving from the host device A replacement command; in response to receiving the replacement command, replace the first device secret with a second device secret; and send a second public identifier generated using the second device secret to the host device. Such as the method of claim 1, wherein verifying the identity of the computing device includes concatenating the message and the certificate to provide the first data. Such as the method of claim 2, wherein verifying the identity of the computing device further includes using the key to decrypt the first data to provide the second data. Such as the method of claim 3, wherein verifying the identity of the computing device further includes using the The identifier decrypts the second data to provide a result and compares the result with the key. For example, the method of claim 1, wherein the identifier is the first public identifier, and the computing device stores a key, the method further includes: using the key as an input of a message authentication code to generate a derived secret ; Wherein the first public identifier is generated using the derived secret as an input of an asymmetric generator. Such as the method of request 1, wherein the key is a public key, and generating the certificate includes concatenating the message and the public key to provide a data input for encryption. Such as the method of claim 1, wherein: the identifier is the first public identifier, and a first asymmetric generator generates the first public identifier and a private identifier as an associated pair; the key is A public key, and a second asymmetric generator generates the public key and a private key as an associated pair; and generating the certificate includes: concatenating the message and the public key to provide the first data; using the private identification Encrypting the first data to provide the second data; and using the private key to encrypt the second data to provide the certificate. For example, the method of claim 1, wherein the key is a public key, the method further includes generating a random number as an input of an asymmetric key generator, wherein the public key and an associated private key use Use this asymmetric key generator to generate. Such as the method of claim 8, wherein the random number is generated using a physical uncopyable function (PUF). An identity verification system, comprising: at least one processor; and a memory, which contains instructions configured to instruct the at least one processor: send a message to a computing device; receive a message from the computing device An identifier, a certificate, and a key, wherein the identifier is associated with an identity of the computing device, and the certificate is generated by the computing device using the message; and the identifier, the certificate, and the key are used to verify the The identity of the computing device, wherein the identifier is a first public identifier, the computing device stores a first device secret used to generate the first public identifier, and the instructions are further configured to indicate the at least A processor: sending a replacement command to the computing device, the replacement command causing the computing device to replace the first device secret with a second device secret; and receiving from the computing device using the second device secret to generate one The second public identifier. For example, the system of claim 10, wherein verifying the identity of the computing device includes: concatenating the message and the certificate to provide the first data; Use the key to decrypt the first data to provide the second data; use the identifier to decrypt the second data to provide a result; and compare the result with the key. Such as the system of claim 10, wherein the computing device is configured to use the second device secret as an input to provide a message authentication code of a derived secret and use the derived secret to generate the second public identifier. Such as the system of claim 10, wherein the replacement command includes a field having a value based on the first device secret. Such as the system of claim 10, which further includes a freshness mechanism configured to generate a freshness, wherein the message sent to the computing device includes the freshness. Such as the system of claim 10, wherein the identity of the computing device includes a string of characters and numbers. A non-transitory computer storage medium that stores instructions that, when executed on an arithmetic device, cause the arithmetic device to at least: receive a message from a host device; generate an identifier, a certificate, and a key, wherein The identifier corresponds to an identity of the computing device, and the certificate is generated using the message; and the identifier, the certificate, and the key are sent to the host device for verifying the identity of the computing device, wherein the identification Symbol is a first public identifier, and the arithmetic device stores it for A first device secret of the first public identifier is generated, and the instructions further cause the computing device to at least: receive a replacement command from the host device; in response to receiving the replacement command, replace the first device secret with a A second device secret; and sending a second public identifier secretly generated using the second device to the host device. For example, the non-transitory computer storage medium of claim 16, wherein the identifier is the first public identifier associated with a private identifier, the key is a public key associated with a private key, and the The certificate includes: concatenating the message and the public key to provide first data; using the private identifier to encrypt the first data to provide second data; and using the private key to encrypt the second data to provide the certificate. For example, the non-transitory computer storage medium of claim 16, wherein verifying the identity of the computing device includes using the identifier to perform a decryption operation to provide a result and comparing the result with the key.

Images