Verify identification of emergency vehicles during operations

Abstract

The present invention relates to a method, comprising: receiving a command from a host device by a computing device of a first vehicle; in response to receiving the command, storing a new device secret in a memory; generating a triplet including an identifier, a certificate, and a public key by the computing device using the new device secret; and sending the triplet by the computing device to a second vehicle, wherein the second vehicle is configured to verify the identity of the first vehicle using the triplet.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. patent application serial number 16 / 363,088, filed on March 25, 2019, and entitled “VERIFYING IDENTITY OF AN EMERGENCY VEHICLE DURING OPERATION,” the entire disclosure of which is hereby incorporated herein by reference.

[0003] This application is related to U.S. non-provisional application serial number 15 / 970,660 filed by Pisasale et al. on 05 / 03 / 2018, entitled “KEY GENERATION AND SECURE STORAGE IN A NOISY ENVIRONMENT,” the entire contents of which are incorporated herein by reference as if set forth in full.

[0004] This application is related to U.S. non-provisional application serial number 15 / 853,498, entitled “PHYSICAL UNCLONABLE FUNCTION USING MESSAGE AUTHENTICATION CODE,” filed by Mondello et al. on 12 / 22 / 2017, the entire contents of which are incorporated herein by reference as if set forth in full.

[0005] This application is related to U.S. non-provisional application serial number 15 / 965,731 filed by Mondello et al. on April 27, 2018, entitled “SECURE DISTRIBUTION OF SECRET KEY USING A MONOTONIC COUNTER,” the entire contents of which are incorporated herein by reference as if set forth in full. Technical Field

[0006] At least some embodiments disclosed herein relate generally to identification of computing devices, and more particularly, but not limited to, to verifying the identification of a vehicle during operation. Background Art

[0007] A Physical Unclonable Function (PUF) provides a digital value that can be used, for example, as a unique identification of a semiconductor device, such as a microprocessor. A PUF is based on physical variations that occur naturally, for example during semiconductor manufacturing, and allow otherwise identical semiconductor chips to be distinguished.

[0008] PUFs are commonly used in cryptography. PUFs can be physical entities, for example, embedded in physical structures. PUFs are often implemented in integrated circuits and are often used in applications with high security requirements. For example, PUFs can be used as unique and unalterable device identifiers. PUFs can also be used for secure key generation and as a source of randomness.

[0009] In an example involving device identification, The IoT platform is a set of cloud services provided by Microsoft. The IoT platform supports the Device Identity Combination Engine (DICE) and many different types of hardware security modules (HSM). DICE is an upcoming device identification and authentication standard from the Trusted Computing Group (TCG) that enables manufacturers to create hardware-based device identities using silicon gates. HSMs are used to protect device identities and provide advanced functionality such as hardware-based device authentication and zero touch provisioning.

[0010] DICE provides an extensible security framework that uses HSM footprints to anchor trust for building security solutions such as authentication, secure boot, and remote attestation. DICE is useful for characterizing the current constrained computing environments of IoT devices and provides an alternative to more traditional security framework standards such as the Trusted Computing Group (TCG) and Trusted Platform Module (TPM). The IoT platform has HSM support for DICE in HSMs from some silicon vendors.

[0011] In one example involving trust services, the Robust Internet of Things (RIoT) is an architecture for providing trust services to computing devices. Trust services include device identification, authentication, and data integrity. The RIoT architecture can be used to remotely reestablish trust in devices that have been compromised by malware. Moreover, RIoT services can be provided at low cost on even small devices.

[0012] Improved security technologies have created a need for more frequent software updates to products in the field. However, these updates must be managed and verified without human involvement. RIoT can be used to address these technical issues.

[0013] RIoT provides the foundation for cryptographic operations and key management for many security use cases. Authentication, integrity verification, and data protection require cryptographic keys to encrypt and decrypt, as well as mechanisms to hash and sign data. Most Internet-connected devices also use cryptography to secure communications with other devices.

[0014] Cryptographic services provided by RIoT include device identification, data protection, and authentication. Regarding device identification, a device typically authenticates itself by proving possession of cryptographic keys. If the keys associated with a device are extracted and cloned, the device is impersonated.

[0015] Regarding data protection, devices typically use cryptography to encrypt and integrity-protect locally stored data. If the encryption key is only accessible to authorized code, unauthorized software cannot decrypt or modify the data.

[0016] Regarding attestation, a device sometimes needs to report the code it is running and its security configuration. For example, attestation is used to prove that a device is running the latest code.

[0017] If keys are managed only in software, vulnerabilities in software components can lead to key compromise. For software-only systems, the primary way to restore trust after a key compromise is to install updated software and provision new keys for the device. This is time-consuming for servers and mobile devices, and is not possible when the device is not physically accessible.

[0018] Some methods of making remote reprovisioning secure use hardware-based security. Software-level attacks can allow hackers to use hardware-protected keys but not extract them, so hardware-protected keys are a useful building block for making compromised systems securely reprovisioned. A Trusted Platform Module, or TPM, is an example of a security module that provides hardware protection for keys and also allows a device to report (attest) the software it is running. Thus, a new key can be securely issued to a compromised TPM-equipped device, and it can provide an attestation report.

[0019] TPMs are widely used on computing platforms (e.g., using SoC integration and processor mode isolation firmware TPMs). However, TPMs are often impractical. For example, small IoT devices cannot support TPMs without a substantial increase in cost and power requirements.

[0020] 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 a software component outside the RIoT core is compromised, RIoT provides security patches and re-provisioning. RIoT also uses different methods for encryption key protection. The most protected encryption keys used by the RIoT framework are only available briefly during startup. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like reference numerals indicate similar elements.

[0022] Figure 1 A host device is shown verifying an identity of a computing device according to one embodiment.

[0023] Figure 2 An example computing system having an identification component and a verification component is shown according to one embodiment.

[0024] Figure 3 An example computing device of a vehicle is shown according to one embodiment.

[0025] Figure 4 An example host device is shown in communication with an example computing device of a vehicle according to one embodiment.

[0026] Figure 5A An application board is shown that generates an identifier, certificate, and key for a host device according to one embodiment.

[0027] Figure 5B An example computing system is shown that uses a tiered phased boot according to one embodiment.

[0028] Figure 6 An example computing device is shown that generates identifiers, certificates, and keys using an asymmetric generator according to one embodiment.

[0029] Figure 7 A verification component is shown that verifies an identity of a computing device using a decryption operation according to one embodiment.

[0030] Figure 8 A block diagram showing an example process for validating credentials according to one embodiment.

[0031] Fig. 9 A method of verifying an identity of a computing device using an identifier, a certificate, and a key is shown according to one embodiment.

[0032] Fig.10 A system for generating a unique key from the output of a message authentication code (MAC) that receives input from a physically unclonable function (PUF) device is shown according to one embodiment.

[0033] Fig.11 A system for generating a unique key from the output of a MAC that receives input from one or more PUF devices selected by a selector module is shown according to one embodiment.

[0034] Fig.12A system for generating a unique key from the output of a MAC that receives input from one or more PUF devices and from a monotonic counter (and / or from another freshness mechanism such as a NONCE, a timestamp, etc.) is shown according to one embodiment.

[0035] Fig.13 A method of generating an output from a MAC using one or more input values ​​provided from one or more PUFs is shown according to one embodiment.

[0036] Fig.14 A system for generating a root key from the output of a MAC that receives input from one or more PUF devices and from a monotonic counter (and / or from another freshness mechanism such as a NONCE, timestamp, etc.) and adds additional MACs to generate session keys is shown according to one embodiment.

[0037] Fig.15 A computing device for storing obfuscated keys in non-volatile memory is shown according to one embodiment.

[0038] Fig.16 An example of an intermediate key generated during the obfuscation process according to one embodiment is shown.

[0039] Fig.17 Demonstrating an embodiment of Fig.16 An instance of another intermediate key generated during the obfuscation process.

[0040] Fig.18 A method for generating an obfuscated key and storing the obfuscated key in a non-volatile memory according to one embodiment is shown.

[0041] Fig.19 A computing device for generating an initial key based on key injection, obfuscating the initial key, and storing the obfuscated key in a non-volatile memory is shown according to one embodiment.

[0042] Fig. 20 A computing device for generating an identity using a Physical Unclonable Function (PUF) according to one embodiment is shown.

[0043] Fig.21 A system is shown that sends an initial value provided by a monotonic counter of the system for determining whether tampering with the system has occurred, according to one embodiment.

[0044] Fig. 22 A method for generating an identity of a computing device using a Physical Unclonable Function (PUF) according to one embodiment is presented.

[0045] Fig.23A nearby vehicle is shown verifying the identity of an emergency vehicle using one or more credentials according to one embodiment.

[0046] Fig.24 A method for verifying the identity of a vehicle using an identifier, a certificate, and a public key is presented according to one embodiment. DETAILED DESCRIPTION

[0047] At least some embodiments herein relate to verification of the identity of one or more computing devices. In various embodiments, a host device verifies the identity of a computing device by sending a message to the computing device. The computing device uses the message to generate an identifier, certificate, and key that are sent to the host device. The host device uses the generated identifier, certificate, and key to verify the identity of the computing device.

[0048] Other embodiments relate to generating an identity for a computing device using a physically unclonable function (PUF). In various embodiments described below, the computing device may generate its own identity using at least one PUF before the host device verifies the identity as described above. Various embodiments regarding generating an identity using one or more PUFs are described below in the section entitled "Generating an Identity for a Computing Device Using aPUF".

[0049] Still other embodiments relate to assigning an identity to a first vehicle and verifying the identity of the first vehicle using a second vehicle. In one embodiment, the first vehicle is an emergency vehicle. In other embodiments, the first vehicle may be a vehicle associated with an operating state and / or vehicle class. Various embodiments regarding assigning and verifying the identity of a vehicle (e.g., an emergency vehicle) are described below in the section entitled "Assigning and Verifying Identity for a Vehicle."

[0050] In some instances involving identity verification, the computing device may be a flash memory device. In some instances, flash memory is used to add strong security capabilities in computing systems, such as application controllers in autonomous vehicles.

[0051] Flash memory is used in many computer systems. There are various types of flash memory available today, including serial NOR, parallel NOR, serial NAND, parallel NAND, e.MMC, UFS, etc. These interfaces are used in most embedded systems across a variety of industries and applications.

[0052] For example, serial NOR is used in a variety of applications such as medical devices, factory automation boards, automotive ECUs, smart meters, and Internet gateways. Given the diversity of chipset architectures (processors, controllers, or SoCs), operating systems, and supply chains used in these applications, flash memory is the common denominator building block in these systems.

[0053] Computer system resiliency today is often characterized by the location of a root of trust integrated into the device and the solution utilization of the security functions it provides. For more information on the root of trust, refer to the definition created by the National Institute of Technology (NIST) in Special Publication 800-164. The existing industry uses a mix of hardware and software capabilities to use various implementations of system-level roots of trust, resulting in technical issues of fragmented approaches and confusing security levels. This confusing array of options also suffers from the key limitation of how to protect the non-volatile memory in which critical code and data are stored.

[0054] Existing approaches rely on processors and other security elements such as hardware security modules (HSMs) to provide critical security services to their systems. This has created a minimum boot-level security gap in many systems where discrete flash memory components store system critical code and data. Flash has become a target for many hackers to create advanced persistent threats (APTs) that can mask themselves from higher level code and resist removal. In many of these cases, the flash memory is reimaged or overwritten with new malicious code that destroys the integrity of the device.

[0055] Various embodiments of the present disclosure related to identity verification provide technical solutions to the above technical problems. In some embodiments, a computing device integrates a hardware-based root of trust into a flash memory device to achieve strong cryptographic identification and health management of IoT devices. By moving basic security primitives in memory, it becomes simpler to protect the integrity of code and data contained in the memory itself. This approach can significantly enhance system-level security while minimizing the complexity and cost of the implementation.

[0056] In one embodiment, new IoT device management capabilities are implemented using flash memory and associated software. The solution provides a cryptographic identity that becomes the basis for key device provisioning services such as the Azure IoT Hub Device Provisioning Service (DPS). In one example, this DPS together with the enabled storage enables zero-touch provisioning of devices to the correct IoT hub, as well as other services.

[0057] In some embodiments, to implement the above capabilities, the Device Identity Combination Engine (DICE) is used (DICE is an upcoming standard from the Trusted Computing Group (TCG)). In one example, only trusted hardware is allowed to access the Microsoft Azure IoT cloud with enabled memory. In one example, the health and identity of the IoT device is verified in the memory where critical code is usually stored. The unique identity of each IoT device can now provide a new level of end-to-end device integrity, starting from the boot process. This can enable additional functionality such as hardware-based device certification and provisioning, as well as management repair of the device if necessary.

[0058] In one embodiment, a method includes: receiving, by a computing device (e.g., a serial NOR flash memory device) a message from a host device (e.g., a CPU, GPU, FPGA, or application controller of a vehicle); generating, by the computing device, an identifier (e.g., a public identifier ID L1 public), certificates (such as ID L1 certificate) and key (for example, K L1 public), wherein the identifier is associated with the identity of the computing device, and the certificate is generated using a message; and the identifier, the certificate, and the key are sent by the computing device to a host device, wherein the host device is configured to verify the identity of the computing device using the identifier, the certificate, and the key.

[0059] In some embodiments, the computing device described above (e.g., a flash memory device) integrates DICE-RIoT functionality that is used to generate the identifiers, certificates, and keys described above and used by the host device to verify the identity of the computing device. In one example, the computing device stores a device secret that acts as a raw key, and the sequence of identification steps between the DICE-RIoT protocol layers is based on the raw key. In one example, layers L0 and L1 of the DICE-RIoT functionality are implemented in the computing device using hardware and / or software. In one example, layer L0 is implemented only in hardware.

[0060] Figure 1 A host device 151 is shown verifying the identity of a computing device 141 according to one embodiment. Host device 151 sends a message to computing device 141. In one embodiment, host device 151 includes a freshness mechanism (not shown) that generates freshness for sending messages to computing device 141 to avoid replay attacks. In one example, each message sent to computing device 141 includes freshness generated by a monotonic counter.

[0061] In one example, the message is an empty string, a conventional known string (such as an alphanumeric string known to the host device 151 manufacturer or operator), or may be another value (such as an identification value assigned to the computing device). In one example, the message is a unique identification (UID) of the device.

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

[0063] The identifier, certificate, and key are generated by the identification component 147 and are 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 one example, the identification component 147 uses the UDS as a raw key for implementing the DICE-RIoT protocol. The identifier, certificate, and key are output from layer L1 of the DICE-RIOT protocol (see, e.g., Figure 6 In one embodiment, the identification of layer L1 corresponds to the identification of the computing device 141 itself, the manufacturer of the computing device 141, the manufacturer of an object that includes the computing device 141 as a component, and / or an application or other software stored in the memory of the computing device 141. In one example, the application identification (e.g., ID number) is used for mobile phones, TVs, STBs, etc., and its unique combination of letters and numbers is used to identify the object.

[0064] In one example, the identifier of layer L1 is an ASCII string. For example, the identifier may be a manufacturer name concatenated with a thing name (e.g., LG|TV_model_123_year_2018, etc.). In one example, the identifier may be represented in hexadecimal form (e.g., 53 61 6D 73 75 6E 67 20 7C 20 54 56 5F 6D 6F 64 65 6C 5F 31 32 33 5F7965 61 72 5F 32 30 31 38).

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

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

[0067] In one example, memory 145 includes a read-only memory (ROM) that stores an initial boot code for booting computing device 141. FDS is a key provided to the initial boot code by processor 143 during a boot operation. In one example, ROM corresponds to layer L0 of the DICE-RIoT protocol.

[0068] Host device 151 uses the identifier, certificate, and key as input to verification component 153, which verifies the identity of computing device 141. In one embodiment, verification component 153 performs at least one decryption operation using the identifier to provide a result. The result is compared to the key to determine whether the identity of computing device 141 is valid. If valid, host device 151 performs further communications with computing device 141 using the key received from computing device 141. For example, once host device 151 verifies the "triplet" (identifier, certificate, and key), the key can be used to verify any other information exchanged between computing device 141 and host device 151.

[0069] In one embodiment, digital identities are assigned to a plurality of "things" (e.g., in accordance with the Internet of Things). In one embodiment, a thing is a physical object such as a vehicle or a physical item present inside a vehicle. In one example, a thing is a person or an animal. For example, each person or animal may be assigned a unique digital identifier.

[0070] In some cases, product manufacturers want every product to be provably authentic. Currently, this problem is solved by only purchasing things from trusted vendors or other parties that have some kind of legal certificate that ensures that the purchased things are authentic. However, in the case of stolen things, if the things do not have electronic identification, it is difficult to block or locate the things so that the things are not used improperly. In one example, the location is based on the identification when the things try to interact with the public infrastructure. In one example, the blocking is based on the inability to prove the identification of the things that want to use the public infrastructure.

[0071] In one embodiment, computing device 141 implements the DICE-RIoT protocol using identification component 147 in order to associate a unique signature with a trust chain corresponding to computing device 141. Computing device 141 establishes layers L0 and L1. The trust chain continues with host device 151 to establish layers L2, ... In one example, a unique identifier may be assigned to each object, person, and animal in any defined environment, such as a trust zone defined by geographic parameters.

[0072] In one embodiment, computing device 141 is a component in a thing to which an identity is desired to be assigned. For example, the thing may be an autonomous vehicle that includes computing device 141. For example, computing device 141 may be a flash memory used by an application controller of the vehicle.

[0073] When computing device 141 is manufactured, the manufacturer may inject the UDS into memory 145. In one example, the UDS may be consistent and shared with customers who will use 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 (e.g., via a network such as the Internet).

[0074] In one example, the customer may be the manufacturer of a vehicle that incorporates computing device 141. In many cases, the vehicle manufacturer wishes to change the UDS so that it is not known to the vendor of computing device 141. In such cases, the customer may replace the UDS using an authenticated replacement command provided to computing device 141 by host device 151.

[0075] In some embodiments, the customer may inject customer immutable information into the memory 145 of the computing device 141. In one example, the immutable information is used to generate a unique FDS and is not merely used as a discriminator. The customer immutable information is used to distinguish between various objects manufactured by the customer. For example, the customer immutable information may be a combination of letters and / or numbers that define the original information (e.g., a combination of some or all of the following information: date, time, lot location, wafer location, x,y location in a wafer, etc.).

[0076] For example, in many cases, the immutable information also includes data from a cryptographic feature configuration performed by a user (e.g., a customer who receives a device from a manufacturer). This configuration or setting can be accomplished only by using authenticated commands (commands that require knowledge of a key to execute). The user already knows the key (e.g., based on provision of the key from the manufacturer via a secure infrastructure). The immutable information represents a form of cryptographic identification of the computing device that is different from the unique ID (UID) of the device. In one example, including the cryptographic configuration in a set of immutable information provides the user with tools useful for customizing the immutable information.

[0077] In one embodiment, computing device 141 includes a freshness mechanism that generates freshness. Freshness may be provided along with the identifier, certificate, and key when sent to host device 151. Freshness may also be used in conjunction with other communications with host device 151.

[0078] In one embodiment, computing device 141 is a component on an application board. Another component on the application board (not shown) can verify the identity of computing device 141 using knowledge of device secret 149 (e.g., knowledge injected into the UDS). The component requests computing device 141 to produce an output using a message authentication code in order to prove possession of the UDS. For example, the message authentication code may be as follows: HMAC(UDS, "App Board Message | Freshness").

[0079] In another embodiment, FDS can also be used as a criterion for proving possession of the device (e.g., knowledge of a secret key). FDS is derived from UDS in this way: FDS = HMAC-SHA256[UDS, SHA256("Identity of L1")]. Therefore, the message authentication code can be as follows: HMAC(FDS, "App Board Message | Freshness").

[0080] Figure 2 An example computing system with an identification component 107 and a verification component 109 is shown according to one 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 memory areas 111, 113, ..., 119 of a non-volatile memory 121. In one example, the host system 101 also reads data from and writes data to the volatile memory 123. In one example, the identification component 107 supports layers L0 and L1 of the DICE-RIoT protocol. In one example, the non-volatile memory 121 stores boot code.

[0081] Verification component 109 is used to verify the identity of memory system 105. Verification component 109 uses a triplet including an identifier, a certificate, and a key generated by identification component 107 in response to receiving a host message from host system 101, such as described above.

[0082] The identification component 107 is Figure 1 The verification component 109 is an instance of the identification component 147. Figure 1 An instance of the verification component 153.

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

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

[0085] The memory system 105 includes a freshness generator 155. In one example, the freshness generator 155 can be used for authenticated commands. In one example, multiple freshness generators 155 can be used. In one example, the freshness generator 155 can be used by the host system 101.

[0086] In one example, processing device 111 and memory areas 111, 113, ..., 119 are on the same chip or die. In some embodiments, the memory areas store data used by host system 101 and / or processing device 111 during machine learning processing or other runtime data generated by software processes executed on host system 101 or on processing device 111.

[0087] The computing system may include a write component in the memory system 105 that selects a memory region 111 (e.g., a recording segment of a flash memory) for recording new data from the host system 101. The computing system 100 may further include a write component in the host system 101 that coordinates with the write component 107 in the memory system 105 to at least facilitate the selection of the memory region 111.

[0088] In one example, volatile memory 123 is used as system memory for a processing device (not shown) of host system 101. In one embodiment, a process of host system 101 selects a memory region for writing data. In one example, host system 101 may select a memory region based in part on data from sensors and / or a software process executing on the autonomous vehicle. In one example, the aforementioned data is provided by host system 101 to processing device 111, which selects a memory region.

[0089] In some embodiments, the host system 101 or the processing device 111 includes at least a portion of the identification component 107 and / or the verification component 109. In other embodiments or combinations, the processing device 111 and / or the processing device in the host system 101 includes at least a portion of the identification component 107 and / or the verification component 109. For example, the processing device 111 and / or the processing device of the host system 101 may include logic circuitry that implements 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 may be configured to execute instructions stored in a memory for performing the operations of the identification component 107 and / or the verification component 109 described herein.

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

[0091] An example of a memory system 105 is a memory module connected to a central processing unit (CPU) via a memory bus. Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), non-volatile dual in-line memory modules (NVDIMMs), etc. In some embodiments, the memory system may be a hybrid memory / storage system that provides both memory functions and storage functions. In general, a host system may utilize a memory system that includes one or more memory regions. The host system may provide data stored at the memory system and may request data retrieved from the memory system. In one example, the host may access various types of memory, including volatile and non-volatile memory.

[0092] The host system 101 may be a computing device, such as a controller in a vehicle, a network server, a mobile device, a cellular phone, an embedded system (e.g., an embedded system with a system on a chip (SOC) and internal or external memory), or any computing device that includes a memory and a processing device. The host system 101 may include or be coupled to a 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 may 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 may be an indirect communication connection or a direct communication connection (e.g., without an intermediary component), whether wired or wireless, including connections such as electrical, optical, magnetic, etc. Examples of physical host interfaces include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, Fibre Channel, Serial Attached SCSI (SAS), a Double Data Rate (DDR) memory bus, etc. The physical host interface may be used to transfer data between the host system 101 and the memory system 105. The physical host interface may provide an interface for passing control, address, data, and other signals between the memory system 105 and the host system 101.

[0093] Figure 2 Memory system 105 is illustrated as an example. In general, host system 101 can access multiple memory systems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0094] 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, etc. In some examples, the controller of the host system may be referred to as a memory controller, a memory management unit, and / or an initiator. In one example, the controller controls communications between the host system 101 and the memory system 105 via the bus 103. These communications include the sending of host messages for verifying the identity of the memory system 105, as described above.

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

[0096] In one embodiment, memory regions 111, 113, ..., 119 may include any combination of different types of non-volatile memory components. In addition, memory cells of a memory region may be grouped into memory pages or data blocks, which may refer to a unit for storing data. In some embodiments, volatile memory 123 may be, but is not limited to, random access memory (RAM), dynamic random access memory (DRAM), and synchronous dynamic random access memory (SDRAM).

[0097] In one embodiment, one or more controllers of the memory system 105 may 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, buffer memory, or a combination thereof. Each controller may be a microcontroller, a dedicated logic circuit system (such as a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor. The controller may include a processing device (processor) configured to execute instructions stored in a local memory. In one example, the local memory of the controller includes an embedded memory configured to store instructions for executing various processes, operations, logic flows, and routines for controlling the operation of the memory system 105, including handling communications between the memory system 105 and the host system 101. In some embodiments, the local memory may include memory registers that store memory pointers, extracted data, etc. The local memory may also include a read-only memory (ROM) for storing microcode.

[0098] In general, the controller of the memory system 105 may receive commands or operations from the host system 101 and / or the processing device 111 and may convert the commands or operations into instructions or appropriate commands to enable selection of a memory region based on a data write counter of the memory region. The controller may also be responsible for other operations associated with the memory region, such as wear leveling, obsolete item collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address translation between logical block addresses and physical block addresses. The controller may further include a host interface circuit system that communicates with the host system 101 via a physical host interface. The host interface circuit system may convert commands received from the host system into command instructions to access one or more of the memory regions and convert responses associated with the memory regions into information for the host system 101.

[0099] The memory system 105 may also include additional circuitry or components not illustrated. In some embodiments, the memory system 105 may include a cache or buffer (such as DRAM or SRAM) and address circuitry (such as row decoders and column decoders) that can receive addresses from one or more controllers and decode the addresses to access memory regions.

[0100] In some embodiments, a controller and / or processing device 111 in the host system 101 or the memory system 105 includes at least a portion of the identification component 107 and / or the verification component 109. For example, the controller and / or processing device 111 may include logic circuitry that implements the identification component 107 and / or the verification component 109. For example, the processing device (processor) may be configured to execute instructions stored in a memory for performing operations that provide read / write access to a memory area of ​​the identification component 107. In some embodiments, the verification component 109 is part of an operating system, a device driver, or an application.

[0101] Figure 3 An example computing device of a vehicle 100 is shown according to one embodiment. For example, the vehicle 100 may be an autonomous vehicle, a non-autonomous vehicle, an emergency vehicle, a service vehicle, or the like.

[0102] Vehicle 100 includes a vehicle computing device 110, such as an onboard computer. Vehicle computing device 110 is Figure 1 In another example, the vehicle computing device 110 is Figure 2 1 is an instance of host system 101, and memory 160 is an instance of memory system 105.

[0103] The vehicle computing device 110 includes a processor 120 coupled to an on-board communication component 130 (e.g., a reader, writer, and / or other computing device capable of performing the functions described below), which is coupled to (or includes) an antenna 140. The on-board communication component 130 includes a processor 150 coupled to a memory 160 (e.g., non-volatile flash memory), but embodiments are not limited to such memory devices.

[0104] In one example, memory 160 is adapted to store this information in a manner that enables vehicle 100 to provide all information related to the vehicle (e.g., driver, passengers, and cargo) when approaching a checkpoint by using a communication interface (e.g., the so-called DICE-RIoT protocol), as described below.

[0105] In one example, vehicle information (e.g., vehicle ID / license plate number) is already stored in vehicle memory 160, and vehicle 100 is able to identify electronic IDs of passengers and / or IDs of transported luggage, cargo, and the like, for example, through communication component 130 and by using known DICE-RIoT protocols or similar protocols and then store this information in memory 160. In one example, electronic IDs, transported luggage, and cargo containers are equipped with wireless transponders, NFC, Bluetooth, RFID, touchless sensors, magnetic strips, and the like, and communication component 130 can use readers and / or electromagnetic fields to obtain the required information from such remote sources.

[0106] In one example, all passenger IDs and / or IDs of carried luggage, cargo and the like are equipped with an electronic device capable of exchanging data with the communication component. The electronic device may be an active or passive element in the sense that it may be active, because supplied by electricity or may be activated and powered by an external power supply that provides the required power only when the electrical device is in its vicinity.

[0107] The rental vehicle or autonomous vehicle may use readers and / or electromagnetic fields to obtain information inside or near the vehicle, or alternatively, may even receive information from a remote source, such as when the driver of the rental vehicle is known to the rental system due to a previous reservation. Another check may be performed in real time when the driver arrives to pick up the vehicle.

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

[0109] In one example, communication between the vehicle communication component 130 and nearby sources (such as cargo transponders and the like) occurs via the DICE-RIoT protocol.

[0110] 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) can 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 messages such as route information or checkpoint safety messages, and can display visual warnings and / or output audible warnings. The communication component 130 can receive information from additional computing devices, such as from an external computing device (not shown).

[0111] Figure 4 An example system 390 is shown having a host device 350 in communication with an example computing device of a vehicle 300 according to one embodiment. The computing device includes a passive communication component 310, such as a short-range communication device (e.g., an NFC tag). The communication component 310 may be in the vehicle 300, which may be as shown in FIG. Figure 31 and includes components of the vehicle 100 in addition to a communication component 310, which may be configured as an in-vehicle communication component 130. The communication component 310 includes a chip 320 (e.g., a CPU or application controller implementing the vehicle 300) having a non-volatile storage component 330 that stores information about the vehicle 300 (e.g., vehicle ID, driver / passenger information, cargo information, etc.). The communication component 310 may include an antenna 340.

[0112] Host device 350 is, for example, an active communication device (e.g., it includes a power supply) that can receive information from and / or transmit information to communication component 310. In some examples, host device 350 may include a reader (e.g., an NFC reader), such as a toll reader or other component. Host device 350 may be an external device arranged (e.g., embedded) near a checkpoint (e.g., at the boundary of a trust zone) or generally near a limited access zone. In some embodiments, host device 350 may also be carried by police for use as a portable device.

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

[0114] Host device 350 may also communicate with a server or other computing device (e.g., via a wireless network with a central operations center). For example, host device 350 may be wirelessly coupled or hardwired to a server or communications center. In some instances, host device 350 may communicate with the operations center via WIFI or via the Internet. Host device 350 may power on communication component 310 when vehicle 300 brings antenna 340 within communication range of antenna 380. In some instances, host device 350 may receive real-time information from the operations center and may transmit the information to vehicle 300. In some embodiments, communication component 310 may have a battery of its own.

[0115] In one embodiment, host device 350 is adapted to read / send information from / to vehicle 300 that is equipped with a communication component 310 (eg, an active device) configured to allow for the exchange of information.

[0116] Reference again Figure 3The vehicle 100's onboard communication component 130 may be internally active to collect real-time information related to passenger ID, transported luggage and / or cargo (e.g., when equipped with the above-mentioned Figure 4 The vehicle's computing device can detect information within a spatial range of several meters (e.g., 2 to 3 meters) so that all data corresponding to passengers, luggage, and cargo can be acquired. In one example, this occurs when the vehicle approaches an external communication component (e.g., a server or other computing device used as a host device) within a certain proximity so that communication can begin and / or become intensified. The communication distance is, for example, 2 to 3 meters.

[0117] In one embodiment, the vehicle communication component 130 may enable data to be encrypted when transmitted to external entities and / or when communicating with internal entities. In some cases, data regarding transported luggage, cargo, or even passengers may be confidential or contain confidential information (e.g., a passenger's health status or confidential files or hazardous materials). In such cases, it is desirable that the information and data stored in the memory portion associated with the vehicle computing device remain encrypted data.

[0118] In various embodiments discussed below, methods for encrypting and decrypting communications between an internal vehicle computing device and an external entity (e.g., a server acting as a host device) are discussed. In one example, this method can even be applied between the internal vehicle computing device and electronic components onboard the vehicle associated with passengers, luggage, and cargo.

[0119] In one example, the in-vehicle communication component 130 sends the in-vehicle public key to the external communication component (e.g., used as the host device 151), and the external communication component sends the external public key to the in-vehicle communication component 130. These public keys (in-vehicle and external) can be used to encrypt data sent to each respective communication component and verify the identity of each, and also exchange confirmation and other information. As an example, as 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 in-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 can optionally be sent with a digital signature to verify the identity of the vehicle 100. In addition, the information can be provided to the vehicle 100 and displayed on the dashboard of the vehicle 100 or sent to an email to a computing device associated with the vehicle 100 (e.g., a user device or a central server monitoring the vehicle). Vehicles can be identified based on the vehicle's logo, VIN number, etc. and the on-board digital signature.

[0120] In one example, data exchanged between a vehicle and an external entity may have freshness for use by the other. As an example, data indicating the same instruction sent by a vehicle to an external entity may be altered at each of a specific time frame or for a specific amount of data sent. This may prevent a hacker from intercepting confidential information contained in previously sent data and sending the same data again to cause the same result. If the data has been slightly altered but still indicates the same instruction, the hacker may send the same information at a later point in time, and the same instruction will not be implemented because the recipient expects the altered data to implement the same instruction.

[0121] Data exchanged between the vehicle 100 and an external entity (such as a computing system or device) (not shown) may be performed using a number of encryption and / or decryption methods, as described below. Protection of data may ensure that unauthorized activities are prevented from interfering with the operation of the vehicle 100 and the external entity.

[0122] Figure 5A An application board is shown generating a triplet containing an identifier, a certificate, and a key that is sent to a host device according to one embodiment. The host device uses the triplet to verify the identity of the application board. The application board is Figure 1 The host device is an instance of a computing device 141. Figure 1 An example of a host device 151.

[0123] In one embodiment, the application board and the host include a communication component that performs encryption and / or decryption operations of communications (e.g., regarding information and data) using a Device Identity Combination Engine (DICE)-Robust Internet of Things (RIoT) protocol. In one example, the DICE-RIoT protocol is applied to communications between an onboard communication component and an external communication component, and to communications performed within a vehicle environment between the vehicle communication component and various wireless electronic devices associated with each of a passenger ID, luggage, cargo, and the like.

[0124] Figure 5B An example computing system is shown that uses a layered phased startup according to one embodiment. The system includes an external communication component 430' and an onboard communication component 430". As the vehicle approaches or is in the vicinity of an external entity, the vehicle's associated onboard communication component 430" can exchange data with the external entity as described above, for example using a sensor (e.g., a radio frequency identification sensor or RFID or the like).

[0125] In other embodiments, component 430′ may be an application board located in a vehicle, and component 430″ may be a host device also located in the vehicle that uses the DICE-RIoT protocol to verify the identity of component 430′ (e.g., as described above with respect to Figure 1 Discussion).

[0126] In one embodiment, the DICE-RIoT protocol is used by a computing device to boot in stages using layers, where each layer authenticates and loads the next layer and provides increasingly complex runtime services at each layer. Thus, one layer can be served by the previous layer and serve the next layer, thereby creating an interconnected network of layers built on lower layers and serving higher layers. Alternatively, other protocols can be used in place of the DICE-RIoT protocol.

[0127] In one example implementation of the communication protocol, the security of the communication protocol is based on a secret value set during manufacturing (or also later) as a device secret (e.g., UDS). The device secret UDS exists on the device secret UDS provisioned thereon (e.g., stored as Figure 1 The device secret 149) is within the device.

[0128] The device secret UDS can be accessed by the first stage ROM based boot loader at boot time. Then, the system provides a mechanism to make the device secret inaccessible until the next boot cycle, and only the boot loader (e.g., boot layer) can access the device secret UDS at any time. Therefore, in this method, boot is layered in a specific architecture that starts with the device secret UDS.

[0129] like Figure 5B , layer 0L0 and layer 1L1 are within the external communication component 430'. Layer 0L0 may provide a fused derived secret (FDS) key to layer 1L1. The FDS key may be based on the identification of the code of layer 1L1 and other security-related data. A specific protocol (e.g., the Robust Internet of Things (RIoT) core protocol) may use the FDS to validate the code of layer 1L1 that it loads. In an example, the specific protocol may include a device identification combination engine (DICE) and / or the RIoT core protocol. As an example, the FDS may include the layer 1L1 firmware image itself, a manifest that cryptographically identifies the authorized layer 1L1 firmware, a firmware version number of the signed firmware in the context of a secure boot implementation, and / or security-critical configuration settings of the device. The device secret UDS may be used to create the FDS and is stored in the memory of the external communication component. Therefore, layer 0L0 never discloses the actual device secret UDS and it provides the derived key (e.g., FDS key) to the next layer in the boot chain.

[0130] The external communication component 430' is adapted to transmit data to the onboard communication component 430' as illustrated by arrow 410'. The transmitted data may include a public external identification, a certificate (eg, an external identification certificate), and / or an external public key, as will be incorporated into the Figure 6 Description: The layer 2 L2 of the vehicle communication component 430 ″ can receive the transmitted data and execute the data in the operation of the operating system OS, for example, on the first application App1 and the second application App2.

[0131] Similarly, the vehicle communication component 430" can transmit data including a public vehicle identification, a certificate (e.g., a vehicle identification certificate) and / or a vehicle public key as illustrated by arrow 410". As an example, after authentication (e.g., after verifying the certificate), the vehicle communication component 430" can send a vehicle identification number VIN for further authentication, identification and / or verification of the vehicle.

[0132] like Figure 5B and Figure 6 In an example operation, the external communication component 430' may read the device secret DS, hash the identity of layer 1L1, and perform the following calculations:

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

[0134] Where KDF is a cryptographic one-way key derivation function (e.g. HMAC-SHA256). In the above calculation, the hash can be any cryptographic primitive, such as SHA256, MD5, SHA3, etc.

[0135] In at least one example, the vehicle may communicate using either an anonymous login or an authenticated login. Authenticated login may allow the vehicle to obtain additional information that is not accessible when communicating in anonymous mode. In at least one example, authentication may include providing a vehicle identification number (VIN) and / or authentication information, such as a public key exchange, as will be described below. In either of the anonymous and authenticated modes, an external entity (such as a checkpoint police at a trust zone boundary) may communicate with the vehicle to provide an external public key associated with the external entity to the vehicle.

[0136] Figure 6 An example computing device is shown that generates identifiers, certificates, and keys using an asymmetric generator according to one embodiment.In one embodiment, the computing device implements a process to determine parameters (eg, within layer L1 of an external device, or in an alternative embodiment within layer L1 of an internal computing device).

[0137] In one embodiment, parameters including an external public identifier, an external certificate, and an external public key are determined, which are then sent (as indicated by arrow 510') to a vehicle communication component (eg, Figure 5B Reference object 430” in layer 2L2. Figure 6 The arrows 510' and 510" correspond to Figure 5B Arrows 410' and 410". Furthermore, Figure 6 The layers in correspond to Figure 5B layer.

[0138] In another embodiment, a message from a host device ("host message") is merged with an external public key via pattern (data) merge 531 to provide merged data for encryption. The merged data is input to encryptor 530. In one example, the host message is concatenated with the external public key. The resulting parameters include a triplet that is sent to the host device and used to verify the identity of the computing device. For example, the external public identity, external certificate, and external public key are used by the host device's authentication component to verify the identity. In one example, the host device is Figure 1 host device 151.

[0139] like Figure 6 , the FDS from layer 0L0 is sent to layer 1L1 and is used by asymmetric ID generator 520 to generate a public identity IDlkpublic and a private identity IDlkprivate. In the abbreviation "IDlkpublic", "lk" indicates a common layer k (layer 1L1 in this example), and "public" indicates that the identity is publicly shared. The public identity IDlkpublic is illustrated as being shared by the arrows to the right and outside of layer 1L1 extending to the external communication components. The generated private identity IDlkprivate is used as a key input into an encryptor 530. The encryptor 530 can be, for example, any processor, computing device, etc. for encrypting data.

[0140] Layer 1L1 of the external communication component may include an asymmetric key generator 540. In at least one example, a random number generator RND may optionally input a random number into the asymmetric key generator 540. The asymmetric key generator 540 may generate a random number that is consistent with the external communication component (e.g., Figure 5B The public key KLkpublic (referred to as the external public key) and the private key KLkprivate (referred to as the external private key) associated with the external communication component 430' in FIG.

[0141] The external public key KLkpublic may be input (as "data") into the encryptor 530. As mentioned above, in some embodiments, a host message previously received from a host device as part of an identification verification process is combined with KLkpublic to provide the combined data as input data to the encryptor 530.

[0142] The encryptor 530 may use the input of the external private identity IDlkprivate and the external public key KLkpublic to produce a result K'. The external private key KLkprivate and the result K' may be input into an additional encryptor 550, thereby producing an output K". The output K" is an external certificate IDL1certificate that is transmitted to layer 2L2 (or alternatively transmitted to a host device that verifies the identity). The external certificate IDL1certificate may provide the ability to verify and / or authenticate the data source sent from the device. As an example, data sent from an external communication component may be associated with the identity of the external communication component by verifying the certificate, such as by combining Figure 7 Further description. In addition, the external public key KL1publickey can be transmitted to the layer 2L2. Therefore, the public identification ID11public of the external communication component, the certificate IDL1certificate and the external public key KL1publickey can be transmitted to the layer 2L2 of the onboard communication component.

[0143] Figure 7 A verification component is shown that verifies the identity of a computing device using a decryption operation according to one embodiment. The verification component includes decryptors 730, 750. The verification component implements a process of verifying a certificate according to an embodiment of the present disclosure.

[0144] exist Figure 7 In the illustrated example, the public key KL1public, the certificate IDL1certificate and the public identifier IDL1public are transmitted from an external communication component (e.g., from Figure 5B The external communication component 430' in layer 1L1) is provided.

[0145] The data of the certificate IDL1certificate and the external public key KL1public can be used as input into the decryptor 730. The decryptor 730 can be any processor, computing device, etc. for decrypting data. The decryption result of the certificate IDL1certificate and the external public key KL1public can be used as input into the decryptor 750 together with the public identification IDL1public, thereby generating an output. As illustrated at block 760, the external public key KL1public and the output from the decryptor 750 can indicate whether the certificate is verified, resulting in 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.

[0146] In response to the certificate being verified (e.g., after authentication), data received from the verified device can be accepted, decrypted, and / or processed. In response to the certificate not being verified, data received from the verified device can be discarded, removed, and / or ignored. In this way, unauthorized devices sending malicious data can be detected and avoided. As an example, a hacker sending data to be processed can be identified and the hacker attack data is not processed.

[0147] In an alternative embodiment, the public key KL1public, the certificate IDL1certificate and the public identifier IDL1public are obtained from Figure 1 The computing device 141 or from Figure 2 105. This triplet is generated by computing device 141 in response to receiving a host message from a host device. Before providing IDL1certificate as input to decryptor 730, IDL1certificate and the message from the host device ("host message") are merged by pattern (data) merge 731. In one example, the merge is a concatenation of the data. The merged data is provided as input to decryptor 730. Then, the verification process continues as described above.

[0148] Figure 8 A block diagram showing an example process of verifying a certificate according to one embodiment. In the case where a device is sending data that can be verified in order to avoid subsequent repudiation, 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 performs the request, the first device can instruct the first device never to make such a request. Non-repudiation methods such as using signatures can avoid repudiation by the first device and ensure that the second device can subsequently perform the requested task without difficulty.

[0149] Vehicle computing device 810" (e.g. Figure 3 The vehicle computing device 110 or Figure 1The vehicle computing device 141) may send data Dat" to an external computing device 810' (or, in general, to any other computing device). The vehicle computing device 810" may generate a signature Sk using the on-board private key KLkprivate. The signature Sk may be transmitted to the external computing device 810'. The external computing device 810' may verify using the data Dat' and a previously received public key KLkpublic (e.g., an on-board public key). In this manner, signature verification operates by encrypting the signature using the private key and decrypting the signature using the public key. In this manner, the unique signature of each device may be kept secret from the device sending the signature while allowing the receiving device to be able to decrypt the signature for verification. This is in contrast to encryption / decryption of data that is encrypted by the sending device using the public key of the receiving device and decrypted by the receiving device using the receiver's private key. In at least one example, the vehicle may verify the digital signature by using an internal encryption process such as an elliptic curve digital signature (ECDSA) or a similar process.

[0150] Due to the exchange and verification of certificates and public keys, the devices are able to communicate with each other in a secure manner. When the vehicle approaches an external entity (such as a trust zone boundary, a border security entity or, in general, an electronic control host device), the corresponding communication device (which has Figure 7 The two entities exchange certificates and communicate with each other (e.g., the ability to verify the corresponding certificates shown in ). After authentication (e.g., after receiving / verifying the certificates and public keys from the external entity), the vehicle is therefore able to transmit all the required information related to it and stored in its memory, such as the license plate number / ID, VIN, insurance number, driver information (e.g., ID, final permission for border transition), passenger information, transported goods information, and the like. Then, after checking the received information, the external entity transmits the result of the transition request to the vehicle, which information may be encrypted using the public key of the receiver. The exchanged messages / information can be encrypted / decrypted using the above-mentioned DICE-RIoT protocol. In some embodiments, so-called immutable information (e.g., license plate number / ID, VIN, insurance number) is not encrypted, while other information is encrypted. In other words, in the exchanged messages, there may be unencrypted data as well as encrypted data: the information may therefore be encrypted or not encrypted or mixed. Then, the correctness of the message is ensured by confirming that the content of the message is valid using the certificate / public key.

[0151] Fig. 9 A method of verifying the identity of a computing device using an identifier, a certificate, and a key according to one embodiment is shown. For example, Fig. 9 The method can be implemented in Figures 1 to 7 in the system.

[0152] Fig. 9The method may be performed by processing logic, which may include hardware (such as a processing device, a circuit system, a dedicated logic, a programmable logic, a microcode, hardware of a device, an integrated circuit, etc.), software (such as instructions running or executing on a processing device), or a combination thereof. In some embodiments, Fig. 9 The method is at least partly based on Figure 1 The identification component 147 and the verification component 153 are executed.

[0153] Although shown in a particular sequence or order, the order of the processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0154] At block 921, a message is received from a host device. For example, computing device 141 receives a message from host device 151 (eg, "Host Message" or "Host Message|Freshness").

[0155] At block 923, an identifier, certificate, and key (eg, a public key K L1 The ID is associated with the identity of the computing device. The certificate is generated using a message from the host device (e.g., a "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 the key. Private identifier ID L1 Private and public identifiers L1 public association (eg, an association pair generated by asymmetric ID generator 520).

[0156] In one example, the identification component 147 generates an identifier, a certificate, and a key to provide a triplet. In one example, the triplet is generated based on the DICE-RIoT protocol. In one example, the triplet is as follows: Figure 6 It is produced as described in the description.

[0157] 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 fused derived secret FDS is calculated as follows:

[0158] FDS = HMAC-SHA256[UDS,SHA256("L1 ID")]

[0159] In one example, Layer 1 L1 in the DICE-RIoT architecture generates a certificate using a host message sent by a host device. Layer 1 calculates two associated key pairs as follows:

[0160] (ID lk public ,ID lk private ) and (KL k public ,KL k private )

[0161] Layer 1 also calculates two signatures as follows:

[0162] K'=encrypt(ID lk private ,KL k public |Host message)

[0163] K"=encrypt(KL k private ,K')

[0164] From the above processing, layer 1 provides triples as follows:

[0165] K L1 ={ID L1public ,ID L1 certificate,K L1public}

[0166] More generally, each layer provides a triplet as follows:

[0167] K Lk = {a set of keys and certificates}, where each k = 1:N

[0168] Using the corresponding triples, each layer can prove its identity to the next layer.

[0169] In one example, layer 2 corresponds to application firmware, and subsequent layers correspond to an operating system and / or application programs of the host device.

[0170] At block 925, the generated identifier, certificate, and key are sent to the host device. The host device verifies the identity of the computing device using the identifier, certificate, and key. In one example, host device 151 receives the identifier, certificate, and key from computing device 141. Host device 151 verifies the identity of the computing device using verification component 153.

[0171] In one example, verification component 153 performs a decryption operation as part of the verification process. Decryption includes combining the message from the host with the certificate before decrypting using a key received from computing device 141. In one example, verification of the identity of the computing device is performed as shown in FIG. Figure 7 Execute as described in .

[0172] In one example, the decryption operation is performed as follows:

[0173] Using KL 1public Decryption (ID L1 certificate) to provide K'

[0174] Use ID L1public Decrypt K' to provide the result

[0175] Results and KL 1public Compare. If the result is equal to KL 1public , then the identity is verified. In one example, the application board identity is verified.

[0176] In one embodiment, the identity of a human or animal is proven. Verification of the identity of a person is performed similarly to verifying the identity of computing device 141, as described above. In one example, computing device 141 is integrated into a person's passport. The national public administration that issues passports may use a UDS for a class of documents (e.g., driver's licenses, passports, ID cards, etc.). For example, for the Passport Office in Messina, Sicily, Italy, UDS = 0x12234...4444. For the Passport Office in Munich, Bavaria, Germany, UDS = 0xaabb...00322

[0177] In an example about a passport, the identifier of L1 is the following ASCII string:

[0178] Country | File Type | Etc. (e.g. "Italy, Sicily, Messina, Passport Office")

[0179] The “granularity” of the assignment can be determined by the public administration of each country.

[0180] Fig. 9 Various embodiments of the method provide various advantages. For example, things can be identified and certified as being manufactured by a specific factory without the use of a third-party key infrastructure (e.g., PKI = Public Key Infrastructure). Man in the middle or hacker attacks are prevented due to replay protection. The method can be used for mass production of things.

[0181] Furthermore, the customer UDS is protected at the hardware level (e.g., inaccessibility of layer 0 outside the component). The UDS cannot be read by anyone, but it can be replaced (e.g., only the customer can do this by using a secure protocol). Examples of secure protocols include security protocols based on authenticated, replay-protected commands and / or based on secret sharing algorithms such as Diffie Hellman (e.g., ECDH Elliptic Curve Diffie-Hellman). In one example, the UDS is delivered to the customer (not the end user) using a secure infrastructure. The UDS can be customized by the customer.

[0182] Additionally, component identification can work without an Internet or other network connection. Furthermore, the method can be used to easily check the identities of things, animals, and humans at trust zone boundaries (e.g., national borders, internal checkpoints, etc.).

[0183] In one example, knowledge of the UDS permits the host device to safely replace the UDS. For example, replacement may be done if the host wishes to change the identity of a thing, or the host wishes the identity of a thing not to be known by anyone else, including the original manufacturer.

[0184] In another example, a replace command is used by a host device. For example, the host device may send a replace UDS command to the computing device. The replace command includes an existing UDS and a new UDS to be attributed to the computing device. In one example, the replace command has a field including the following hash value: hash(existing UDS|new UDS).

[0185] In another example, an authenticated replay protection command is used with the following fields: Replace_command|Freshness|Signature

[0186] Where signature = MAC[secret key,Replace_command|freshness|hash(existing UDS|new UDS)]

[0187] The secret key is an additional key and is a key for authenticated commands present on the device. For example, the secret key may be a session key described below (see, e.g., Fig.12 ).

[0188] In one embodiment, a method includes: receiving, by a computing device (e.g., computing device 141), a message from a host device (e.g., host device 151); generating, by 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 using the message; and sending, by the computing device, the identifier, the certificate, and the key to the host device, wherein the host device is configured to verify the identity of the computing device using the identifier, the certificate, and the key.

[0189] In one embodiment, verifying the identity of the computing device includes concatenating a message and a certificate to provide the first data.

[0190] In one embodiment, verifying the identity of the computing device further comprises decrypting the first data using the key to provide the second data.

[0191] In one embodiment, verifying the identity of the computing device further comprises decrypting the second data using the identifier to provide a result and comparing the result to the key.

[0192] In one embodiment, the identifier is a public identifier and the computing device stores a secret key, the method further comprising: using the secret key as an input to a message authentication code to generate a derived secret; wherein the public identifier is generated using the derived secret as an input to an asymmetric generator.

[0193] 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, and the method further includes: receiving a replacement command from a host device; in response to receiving the replacement command, replacing the first device secret with a second device secret; and sending a second public identifier generated using the second device secret to the host device.

[0194] In one embodiment, the key is a public key and generating a certificate includes concatenating the message with the public key to provide data input for encryption.

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

[0196] In one embodiment, the key is a public key, the method further comprising generating a random number as an input to an asymmetric key generator, wherein the public key and the associated private key are generated using the asymmetric key generator.

[0197] In one embodiment, the random number is generated using a Physically Unclonable Function (PUF).

[0198] In one embodiment, a system includes: at least one processor; and a memory containing instructions configured to direct the at least one processor to: send a message to a computing device; receive an identifier, a certificate, and a key from the computing device, 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 verify the identity of the computing device using the identifier, the certificate, and the key.

[0199] In one embodiment, verifying the identity of the computing device includes: concatenating the message and the certificate to provide first data; decrypting the first data using the key to provide second data; decrypting the second data using the identifier to provide a result; and comparing the result to the key;

[0200] 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, and the instructions are further configured to instruct at least one processor to: send 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 receive from the computing device a second public identifier generated using the second device secret.

[0201] In one embodiment, the computing device is configured to use the second device secret as an input to a message authentication code that provides a derived secret and to generate the second public identifier using the derived secret.

[0202] In one embodiment, the replace command includes a field having a value based on the first device secret.

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

[0204] In one embodiment, the identification of the computing device comprises an alphanumeric string.

[0205] In one embodiment, 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, a certificate, and a key, wherein the identifier corresponds to an identification of the computing device and the certificate is generated using the message; and send the identifier, the certificate, and the key to the host device for verifying the identification of the computing device.

[0206] In one embodiment, the identifier is a public identifier associated with a secret identifier, the key is a public key associated with the secret key, and generating a certificate includes: concatenating a message with the public key to provide first data; encrypting the first data using the secret identifier to provide second data; and encrypting the second data using the secret key to provide a certificate.

[0207] In one embodiment, verifying the identity of the computing device includes performing a decryption operation using the identifier to provide a result and comparing the result to a key.

[0208] Generates value using Physically Unclonable Function (PUF)

[0209] At least some embodiments disclosed below provide an improved architecture for generating values ​​using a Physical Unclonable Function (PUF). In some embodiments, the PUF value itself can be used as a device secret, or used to generate a device secret. In one example, the PUF value is used as a unique device secret (UDS) for use with the DICE-RIoT protocol, as described above (see, for example, Figure 5A and Figure 5B ). In one example, the value generated by the PUF is used as input to a message authentication code (MAC). The output from the MAC is used as the UDS.

[0210] In some embodiments, the PUF value or a value generated from the PUF value can be used as a random number (e.g., a device-specific random number). In one example, a random number (e.g., RND) is generated as described above (e.g., see Figure 6 ) is used as input to generate associated public and private keys by an asymmetric key generator.

[0211] In general, the following architecture generates an output by feeding the 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).

[0212] Generally, semiconductor chip manufacturers face the problem of key injection, which is the programming of a unique secret key for each chip or die provided, for example, from a semiconductor wafer. It is desirable to perform key injection in a secure environment to avoid leaking or disclosing the secret key injected into the chip. It is also desirable to ensure that the key cannot be hacked or read back after the chip is manufactured. In some cases, for example, the key injection procedure is authenticated or performed by a third-party infrastructure.

[0213] Chip manufacturers want to reduce the manufacturing cost of chips that include encryption capabilities. Chip manufacturers also want to simplify the manufacturing process while maintaining a consistent level of security performance for the chips they manufacture. However, key injection is one of the more expensive manufacturing steps.

[0214] Chip manufacturers also face the problem of improving the consistency of PUFs when used as pseudo-random number generators. In some cases, this problem can include cross-correlation between dies due to the phenomenon on which the seed values ​​provided by the PUF are based.

[0215] PUF is based on unpredictable physical phenomena that are unique to each die, such as, for example, on-chip parasitics, on-chip path delays, etc. These phenomena are used, for example, to provide seed values ​​for pseudo-random number generators.

[0216] Two different chips selected in a production line must have different PUF values. The PUF value generated in each chip must not change during the lifetime of the device. If two chips have similar keys (e.g., there is a low Hamming distance between them), then the key of one chip can be used to guess the key of the other chip (e.g., pre-image hacking).

[0217] Use of the improved PUF architecture described below can provide a solution to one or more of the above problems by providing an output value of a function suitable for providing a PUF on each chip or die. The improved PUF architecture below uses a PUF that enables each chip or die to automatically generate a unique security key each time the chip or die is powered on. The security key does not need to be stored in non-volatile memory that can be hacked or otherwise leaked.

[0218] The improved PUF architecture further uses a MAC to generate an improved PUF output (eg, a unique key) for use by a cryptographic function or process, such as integrated into a semiconductor chip. The use of a MAC can, for example, increase the Hamming distance between keys generated on different chips.

[0219] In at least some embodiments disclosed herein, an improved PUF architecture is provided that uses the output from the MAC as a way to generate a seed or other value. Thus, the improved PUF architecture provides, for example, a way to perform key injection that reduces manufacturing costs and improves the reliability and / or consistency of the PUF operation on the final chip.

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

[0221] 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 the at least one PUF device; at least one processor; and a memory containing instructions configured to instruct the 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.

[0222] In one embodiment, the system further includes a selector module for selecting one or more of the PUF devices for providing values ​​to the MAC module. For example, values ​​provided from several PUF devices can be concatenated and provided as input to the MAC module. In various embodiments, the selector module can be implemented using hardware and / or software.

[0223] Fig.10 A system for generating a unique key 125 from the output of a message authentication code (MAC) 123, which receives input from a physical unclonable function (PUF) device 121, according to one embodiment is shown. The system provides a PUF architecture 111 for generating a unique key 125 (or other value) from the output of a message authentication code (MAC) module 123. The MAC module 123 receives an input value obtained from a physical unclonable function (PUF) device 121.

[0224] Fig.10 The PUF device 121 in the MAC module 123 may be, for example, any of various known types of PUFs. The MAC module 123 provides one-way functions such as, for example, SHA1, SHA2, MD5, CRC, TIGER, etc.

[0225] The architecture 111 can, for example, improve the Hamming distance of the PUF values ​​or codes generated between chips. The MAC function is unpredictable (e.g., an input sequence with only a single bit difference provided to the MAC function provides two completely different output results). Therefore, the input to the MAC function cannot be identified or determined when only the output is known. The architecture 111 can also, for example, improve the consistency of the PUF as a pseudo-random number generator.

[0226] In one example, the value generated by the PUF architecture 111 (e.g., the unique key 125 or another value) can be a number having N bits, where N depends on the encryption algorithm implemented on the chip (e.g., the memory device 103 or another device) that includes the PUF architecture 111. In one example, the chip implements an encryption function using HMAC-SHA256, in which case the output from the MAC module 123 has a size N of 256 bits. Using the output from the MAC module 123 provides a message length suitable for an output value used as a key (without further compression or padding).

[0227] The PUF architecture 111 is implemented in a device, such as the illustrated memory device 103, or may be implemented in other types of computing devices, such as, for example, integrated circuits in a number of semiconductor chips provided by a wafer fabrication line.

[0228] In one embodiment, MAC module 123 cooperates with and / or is integrated into or is part of encryption module 127, e.g., encryption module 127 may provide encryption functions for memory device 103. For example, the output of MAC module 123 may be suitable for use as a key because the MAC is used by memory device 103 for other encryption purposes.

[0229] The operation of the PUF architecture 111, the encryption module 127, and / or other functions of the memory device 103 may be controlled by the controller 107. The controller 107 may include, for example, one or more microprocessors.

[0230] exist Fig.10 In the embodiment, the host 101 can communicate with the memory device 103 via a communication channel. The host 101 can be a computer having one or more central processing units (CPUs), and computer peripheral devices such as the memory device 103 can be attached to the CPU via interconnects such as a computer bus (e.g., Peripheral Component Interconnect (PCI), PCI eXtended (PCI-X), PCI Express (PCIe)), a communication portion, and / or a computer network.

[0231] In one embodiment, unique key 125 is used as UDS to provide identification of memory device 103. Controller 107 implements layer 0L0 and layer 1L1 in the DICE-RIoT architecture. In response to receiving a host message from host 101 via host interface 105, cryptographic module 127 performs processing to generate a triplet, as described above. Host 101 uses the triplet to verify the identification of memory device 103. Memory device 103 is an example of computing device 141.

[0232] For exemplary purposes, it should be noted that there are generally two technical problems. The first problem is proving the identity of the board to the host. The problem can be handled by using public triplets and asymmetric cryptography, as discussed, for example, above for DICE-RIoT. This method is secure and concise, but may be too expensive / time consuming in some cases to be used directly by the circuit system board itself. The second problem is proving the identity of the memory on the board to the board (e.g., to avoid unauthorized memory replacement) (this is performed, for example, after each power-up). The second problem can be solved using the public triplets and asymmetric cryptography described above. However, a more lightweight security mechanism based solely on a MAC function is generally sufficient for handling the second problem.

[0233] The memory device 103 can be used to store data of the host 101 in, for example, a non-volatile storage medium 109. Examples of memory devices generally include a hard disk drive (HDD), a solid state drive (SSD), a flash memory, a dynamic random access memory, a tape, a network attached storage device, etc. The memory device 103 has a host interface 105 that implements communication with the host 101 using a communication channel. For example, in one embodiment, the communication channel between the host 101 and the memory device 103 is a 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 NVM Express (NVMe)) to communicate with each other.

[0234] In some implementations, 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 connected 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 communicate with each other using data storage management and usage commands similar to the data storage management and usage commands in the NVMe protocol.

[0235] Controller 107 may execute firmware 104 to perform operations in response to communications from host 101 and / or to perform other operations. Firmware is generally a type of computer program that provides control, monitoring, and data manipulation of an engineering computing device. Fig.10 In the embodiment, firmware 104 controls controller 107 to operate the operation of memory device 103, such as the operation of PUF architecture 111, as further discussed below.

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

[0237] The memory device 103 includes volatile dynamic random access memory (DRAM) 106 for storing runtime data and instructions used by the controller 107 to improve the computing performance of the controller 107 and / or to provide a buffer for data transferred between the host 101 and the non-volatile storage medium 109. The DRAM 106 is volatile because it requires power to maintain the data / information stored therein, which is immediately or quickly lost when power is interrupted.

[0238] Volatile DRAM 106 typically has less latency than non-volatile storage media 109, but loses its data quickly when power is removed. Therefore, volatile DRAM 106 is advantageously used to temporarily store instructions and data used by controller 107 in its current computing task to improve performance. In some examples, volatile DRAM 106 is replaced with volatile static random access memory (SRAM) that uses less power than DRAM in some applications. When non-volatile storage media 109 has comparable data access performance (e.g., in terms of latency, read / write speed) to volatile DRAM 106, volatile DRAM 106 can be eliminated; and controller 107 can perform calculations by operating instructions and data on non-volatile storage media 109 instead of on volatile DRAM 106.

[0239] For example, cross-point storage and memory devices, such as 3D XPoint memory, have data access performance comparable to volatile DRAM 106. Cross-point memory devices use transistor-free memory elements, each of which has memory cells and selectors stacked together in a column. The columns of memory elements are connected via two vertical layers of wires, one layer above the columns of memory elements and the other layer below the columns of memory elements. Each memory element can be individually selected at the intersection of one wire on each of the two layers. Cross-point memory devices are fast and non-volatile, and can be used as a unified memory pool for processing and storage.

[0240] In some examples, the controller 107 has an in-processor cache memory that has better data access performance than the volatile DRAM 106 and / or the non-volatile storage media 109. Therefore, portions of instructions and data used in the current computing task are cached in the in-processor cache memory of the controller 107 during computing operations of the controller 107. In some examples, the controller 107 has multiple processors, each with its own in-processor cache memory.

[0241] Optionally, controller 107 performs data-intensive in-memory processing using data and / or instructions organized in memory device 103. For example, in response to a request from host 101, controller 107 performs real-time analysis of a set of data stored in memory device 103 and in response transmits a reduced set of data to host 101. For example, in some applications, memory device 103 is connected to a real-time sensor to store sensor input; and the processor of controller 107 is configured to perform machine learning and / or pattern recognition based on the sensor input to support an artificial intelligence (AI) system implemented at least in part via memory device 103 and / or host 101.

[0242] In some embodiments, the processor of controller 107 is integrated with memory (e.g., 106 or 109) in computer chip manufacturing to enable processing in memory and thus overcome the von Neumann bottleneck that limits computing performance due to throughput limitations caused by latency in data movement between processors and memories configured separately according to the von Neumann architecture. The integration of processing and memory increases processing speed and memory transfer rates and reduces latency and power usage.

[0243] The memory device 103 may be used in various computing systems such as cloud computing systems, edge computing systems, fog computing systems, and / or stand-alone computers. In cloud computing systems, remote computer servers are connected in a network to store, manage, and process data. Edge computing systems optimize cloud computing by performing data processing at the edge of a computer network close to the data source and thereby reduce data communications with centralized servers and / or data storage devices. Fog computing systems use one or more end-user devices or edge devices near users to store data and thereby reduce or eliminate the need to store data in centralized data warehouses.

[0244] At least some embodiments disclosed herein may be implemented using computer instructions, such as firmware 104, executed by controller 107. In some examples, hardware circuitry may be used to implement at least some of the functionality of firmware 104. Firmware 104 may initially be stored in non-volatile storage media 109 or another non-volatile device and loaded into volatile DRAM 106 and / or in-processor cache memory for execution by controller 107.

[0245] For example, firmware 104 may be configured to operate a PUF architecture using the techniques discussed below. However, the techniques discussed below are not limited to use for Fig.10 's computer system and / or the examples discussed above.

[0246] In some implementations, the output of MAC module 123 may be used to provide, for example, a root key or seed value. In other implementations, the output may be used to generate one or more session keys.

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

[0248] Fig.11 A system for generating a unique key 125 from the output of a MAC 123, which receives input from one or more PUF devices selected by a selector module 204, is shown according to one embodiment. According to one embodiment, the system uses a method similar to Fig.10 The PUF architecture of the embodiment of the present invention but including multiple PUF devices 202 and a selector module 204 generates a unique key 125 from the output of the MAC module 123. The MAC module 123 receives input from one or more PUF devices 202 selected by the selector module 204. In one example, the PUF device 202 includes the PUF device 121.

[0249] PUF devices 202 may be, for example, identical or different (e.g., based on different random physical phenomena). In one embodiment, selector module 204 functions as a smart PUF selection block or circuit that selects one or more PUF devices 202 from which values ​​provided as input to MAC module 123 are obtained.

[0250] In one embodiment, the selector module 204 selects the PUF device 202 based at least in part on the results from testing the PUF device 202. For example, the selector module 204 may test the repeatability of each PUF device 202. If any PUF device 202 fails the test, the selector module 204 excludes the failed device for providing input values ​​to the MAC module 123. In one example, the failed device may be excluded temporarily or indefinitely.

[0251] In some implementations, the selector module 204 permits testing of the PUF functionality of each chip during manufacturing and / or during field use (e.g., 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 determined to be unqualified and is excluded from use as input to the MAC module 123.

[0252] In one embodiment, the selector module 204 is used to simultaneously use multiple PUF devices 202 as sources for calculating an improved PUF output from the MAC module 123. For example, the selector module 204 may concatenate a value from a first PUF device with a value from a second PUF device to provide as input to the MAC module 123. In some implementations, this architecture permits a robust PUF output to be obtained because it relies on several different physical phenomena.

[0253] Fig.12 A system for generating a unique key from the output of a MAC is shown according to one embodiment, the MAC receiving input from one or more PUF devices and from a monotonic counter 302 (and / or from another freshness mechanism such as a NONCE, a timestamp, etc.). According to one embodiment, the system generates a unique key 125 from the output of a MAC module 123. Fig.12 The PUF architecture described in is similar to Fig.11 The PUF architecture described in FIG. 2 merely includes a monotonic counter 302 that provides a value to the selector module 204. In various embodiments, the monotonic counter 302 may be implemented using hardware and / or software.

[0254] The MAC module 123 receives input from one or more PUF devices 202 and receives input from a monotonic counter 302. In one example, the values ​​obtained from the PUF device 202 and the monotonic counter 302 are concatenated and then provided as input to the MAC module 123. In some implementations, the monotonic counter 302 is a non-volatile counter that increments its value only when requested. In some embodiments, the monotonic counter 302 is incremented after each power cycle of the chip.

[0255] In some embodiments, Fig.12 The PUF architecture 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 authority.

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

[0257] In some embodiments, the selector module 204 may selectively include or exclude the monotonic counter 302 (or other freshness mechanisms such as NONCE, timestamp) for providing the counter value as input to the MAC module 123 .

[0258] In some embodiments, the monotonic counter 302 is also used by the encryption module 127. In some embodiments, the PUF architecture including the monotonic counter can be used as a session key generator that guarantees a different key in each cycle. In some implementations, the generated session key is protected in this way: Session Key = MAC [One or more PUFs | MTC or freshness]

[0259] In other embodiments, the mechanism is used as follows:

[0260] Session Key = MAC key_based [Root_Key, MTC or other fresh mechanism]

[0261] Where Root_key = the output value provided from the above-mentioned MAC module 123 or any other kind of key present on the chip.

[0262] The above MAC key_based The function is, for example, a MAC algorithm based on a secret key. For example, there may be two types of MAC algorithms in cryptography:

[0263] 1. Secret key based algorithms, such as the HMAC family (HMAC-SHA256 is secret key based).

[0264] 2. Algorithms that are not based on secret keys, such as SHA256 (SHA alone is not key-based).

[0265] It should be noted that a key-based MAC can be transformed into a non-key-based MAC by setting the key to a known value (eg, 0x000...0xFFFF, etc....).

[0266] Fig.13 A method of generating an output from a MAC using one or more input values ​​provided from one or more PUFs is shown according to one embodiment. For example, Fig.13 The method can be implemented in Fig.10 in the memory device 103.

[0267] Fig.13 The method includes providing one or more values ​​by at least one PUF at block 411 (eg, providing values ​​from one or more of the PUF devices 302 ).

[0268] At block 413, one or more of the PUFs may be tested for repeatability, such as described above. This testing is optional.

[0269] At block 415, if testing has been performed at block 413 and it has been determined that the PUF device has failed the test, then the failed PUF device is excluded from providing input to the MAC. This exclusion may be performed, for example, by the selector module 204, as discussed above.

[0270] At block 417, a value is provided from a monotonic counter, such as monotonic counter 302. The use of a monotonic counter in a PUF architecture is optional.

[0271] At block 419, an output is generated from the MAC, which uses as input one or more values ​​provided to the MAC by the PUF (and optionally at least one value from a monotonic counter).

[0272] Various other embodiments of a method implemented in a computing device are now described below, the method comprising: providing at least one value by at least one physically unclonable function (PUF); and generating a first output based on a message authentication code (MAC), wherein the MAC uses at least one value provided by at least one PUF as an input for generating the first output.

[0273] 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.

[0274] 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.

[0275] In one embodiment, the method further comprises: providing a value from a monotonic counter; wherein generating the first output further comprises using the value from the monotonic counter as an additional input to the MAC for generating the first output.

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

[0277] In one embodiment, the method further includes: testing a first PUF of the at least one PUF for repeatability; and based on determining that the first PUF failed the test, excluding the first PUF from being used to provide any input to the MAC in generating the first output.

[0278] In one embodiment, the testing includes comparing two or more values ​​provided by the first PUF.

[0279] In one embodiment, the computing device is a memory device, and the memory device includes a non-volatile storage medium configured to store output values ​​generated using the MAC.

[0280] In one embodiment, the method further includes performing, by the at least one processor, at least one cryptographic function, wherein performing the at least one cryptographic function includes using an output value generated using the MAC.

[0281] In one embodiment, a non-transitory computer storage medium stores instructions that, when executed on a memory device (e.g., memory device 103), cause the memory device to perform a method, the method comprising: providing at least one value by at least one physically unclonable function (PUF); and generating a first output based on a message authentication code (MAC), wherein the MAC uses at least one value provided by at least one PUF as an input for generating the first output.

[0282] In various other embodiments described below, the system may be executed Figure 4 The system includes: at least one physically unclonable function (PUF) device; a message authentication code (MAC) module configured to receive a first input based on at least one value provided by the at least one PUF device; at least one processor; and a memory containing instructions configured to instruct the at least one processor to generate a first output from the MAC module based on the first input.

[0283] In one embodiment, the MAC module includes circuitry. In one embodiment, a first output from the MAC module is a key identifying the die. In one embodiment, the first output from the MAC module is a root key, and the instructions are further configured to instruct at least one processor to generate a session key using the output from the MAC module.

[0284] In one embodiment, the system is part of a semiconductor chip (e.g., one of several chips obtained from a semiconductor wafer), the first output from the MAC module is a unique value identifying the chip, and the instructions are further configured to instruct at least one process to transmit the unique value to a computing device.

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

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

[0287] In one embodiment, the system further includes a monotonic counter configured to provide a counter value, and the instructions are further configured to direct the at least one processor to generate the first input by concatenating the counter value with at least one value provided by the at least one PUF device.

[0288] In one embodiment, the system further includes a selector module configured to select the at least one PUF device providing the at least one value, wherein concatenating the counter value with the at least one value provided by the at least one PUF device is performed by the selector module.

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

[0290] Fig.14 A system for generating a root key from the output of a MAC that receives input from one or more PUF devices and from a monotonic counter (and / or from another freshness mechanism such as a NONCE, timestamp, etc.) and adds additional MACs to generate session keys is shown according to one embodiment.

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

[0292] Additionally, in one embodiment, the monotonic counter 302 may provide an input to the MAC module 504. In other embodiments, a different monotonic counter or another value from the chip may be provided as an input to the MAC module 504 rather than using the monotonic counter 302. In some cases, the monotonic counter 302 provides the counter value to the MAC module 504 rather than to the selector module 204. In other cases, the counter value may be provided to both MAC modules or excluded from both modules.

[0293] Key generation and secure storage

[0294] As mentioned above, PUFs can be used for secure key generation. Various embodiments discussed below relate to generating an initial key using at least one PUF, applying processing to increase obfuscation of the initial key, and storing the final obfuscated key in non-volatile memory. The final obfuscated key and / or the intermediate key used to generate the final obfuscated key can be shared with another computing device and used to securely communicate with the other computing device (e.g., sending messages using symmetric encryption based on the shared key). In some embodiments, secure key generation is accomplished for computing devices used in automotive applications, such as controllers in autonomous vehicles.

[0295] In an alternative embodiment, the initial key is generated in other ways without using the at least one PUF described above. In one embodiment, the initial key can be generated by using an injected key. For example, the initial key is present in the chip due to injection in a factory or other secure environment. In this case, the application process of increasing the obfuscation of the initial key is performed by applying an obfuscation process to the injected key.

[0296] The automotive environment presents a technical problem of introducing "noise" during the key generation phase. The various embodiments described below provide a technical solution to this problem by using a method to reduce or avoid key changes due to this induced noise by storing obfuscated keys inside a non-volatile memory area.

[0297] The automotive environment can affect key generation in a variety of ways. For example, powering up the engine can cause a drop in power to the computing device, causing keys to be generated in an erroneous manner. Temperature extremes can also affect the circuits that generate the keys. Other sources, such as magnetic fields from power lines, can cause inter-symbol interference, or crosstalk, preventing the host from recognizing the device.

[0298] In contrast, if the keys are generated and stored in memory in a secure environment, they will be immune to noise. The secure environment may be, for example, installed directly in a car, a test environment, or a factory (e.g., where the computing devices where the keys are generated are manufactured), depending on the strategy used to propagate the keys among end users / customers of the computing device products.

[0299] In one example, an ADAS or other computing system used in a vehicle is subject to power supply changes. This may occur, for example, during vehicle turn-on, braking, powering the engine, etc.

[0300] The various embodiments of generating and storing keys discussed below provide the advantage of being substantially independent of external factors such as power supply variations, temperature and other external noise sources. In some embodiments, another advantage is that for each cycle, for example, the generation of the key vector is the same.

[0301] When storing a key, another advantage provided in some embodiments is that the key is substantially immune to hardware attacks (such as those that a hacker may perform). For example, one such attack is to monitor the power-on current of the device in order to correlate current changes with bits associated with the key. Other attacks may use, for example, voltage measurements (such as the Vdd supply voltage). Some attacks may use, for example, temperature changes to interfere with the operation of the device.

[0302] In some embodiments, the initial key may be used as described above for Figures 10 to 14 The described methods and / or architectures generate. For example, a PUF is used to generate a key for each power-on cycle of a computing device that is storing a key. In alternative embodiments, other methods may be used to generate the initial key.

[0303] In one exemplary method, as discussed earlier above, key injection uses at least one PUF and a MAC algorithm (e.g., SHA256) to generate a key for a device that is significantly different from other devices (e.g., significantly different from an adjacent die positioned on a wafer). The MAC encryption algorithm provides the benefit of increasing the entropy of the bits generated by the PUF.

[0304] In one embodiment, the generated key (e.g., the initial key provided from the PUF and then from the MAC algorithm) is stored in a non-volatile area of ​​the device after pre-processing the key in order to reduce or avoid hacker attacks and also improve the reliability of the stored key. In one embodiment, after the key is stored, the circuit that generates the key can be disabled. Pre-processing is generally referred to as obfuscation in this article. In one example, the circuit system and / or other logic is used to implement obfuscation on the device. In one example, the stored key can be read by the device because the key is independent of external noise sources. The internal mechanism is used to read any data of the device.

[0305] In various embodiments, storing the key as described herein increases the noise immunity margin. Moreover, this makes it difficult for hackers to read the stored key, for example using power monitoring or other hacking methods.

[0306] At least some embodiments herein use PUF and encryption algorithms (e.g., HMAC-SHA256) to make key generation independent of external factors such as temperature or voltage that would otherwise cause the key to be different from one power-on of the device to the next. If this occurs, it can become a problem for the host to be able to exchange messages with the device. Various embodiments make key generation more robust by placing the stored key in memory so that it is not affected by external factors.

[0307] In one embodiment, the key is generated once on the device and stored in the non-volatile memory of the device. In one example, the key can be generated using the contents of the SRAM before a reset is applied to the SRAM. The key as a function of the PUF is generated using a pseudo-random value output from the PUF. The contents of the SRAM are read before the appliance or other device is reset. The key can also be regenerated at other times as needed through a command sequence. In one example, the generated key is used as a UDS in the DICE-RIoT protocol, as described above. In one example, the command sequence uses a replace command to replace a previously generated UDS with a new UDS, as described above.

[0308] In one embodiment, the key generation is independent of the cryptography implemented by the device. The generated key is shared with the host. This embodiment stores and / or reads the key in the device in a manner that prevents a hacker from guessing the key and using it internally, such as, for example, by analyzing the shape of the current drawn by the device during use of the key.

[0309] In addition, for example, in asymmetric encryption, the generated key becomes a variable password, which is the secret key of the system. The key is not shared with others. For public key encryption, the key is used to generate the corresponding public key.

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

[0311] In one embodiment, as mentioned above, the mechanism uses the following for the initial injection of keys:

[0312] Session Key = MAC key_based [Root_Key, MTC or other fresh mechanism]

[0313] Where Root_Key = any other kind of key present on the chip (e.g., the key may be the initial key injected into the chip at the factory or other secure environment)

[0314] In one embodiment, when the device is powered on for the first time, a special sequence wakes up at least one circuit of the device (e.g., a reading circuit) and verifies that the circuit is performing 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 described below.

[0315] The intermediate key PUF1 is generated by concatenating PUF0 with a predetermined bit sequence (eg, a sequence known to others) to generate PUF1. In one embodiment, PUF1 is used to verify the ability of the device to correctly read the key and to ensure that noise (eg, fluctuations in the power supply) does not affect the generated key.

[0316] The next intermediate key PUF2 is generated. PUF1 and the inverted bit pattern (formed, for example, by inverting the bits of PUF1 and sometimes referred to herein as ) are interleaved to generate PUF2.

[0317] In one embodiment, PUF2 has the same number of bits of 0s and 1s. This makes the shape of the device current essentially the same for any key (e.g., any key stored on the device). This reduces the likelihood 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.

[0318] The next intermediate key PUF3 is generated. The bits of PUF2 are interleaved with pseudo-random bits to form PUF3. This further helps 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.

[0319] The next intermediate key PUF4 is generated. An error correction code (ECC) is generated by the internal circuitry of the device (e.g., during programming). The bits of the ECC are added to PUF3 to generate PUF4. In one embodiment, the ECC bits help prevent the effects of aging of non-volatile memory (e.g., NVRAM) which can be caused by, for example, device endurance limits, X-rays, and particles. Non-volatile memory aging can also be caused, for example, by an increase in the number of electrons in the NV cell that can cause a bit flip.

[0320] The next intermediate key PUF5 is generated. PUF5 is a concatenation of several copies of PUF4. The redundancy of multiple copies of PUF4 in PUF5 further improves robustness by increasing the probability that the key can be correctly read at a later time. In one embodiment, several copies of PUF5 are stored in various non-volatile memory storage areas to further improve robustness. For example, even if PUF5 is damaged in one area, PUF5 can be read from other areas and the correct key can be extracted.

[0321] In one embodiment, PUF1 or PUF3 is a key shared with the host for symmetric encryption, or is used to generate a public key for asymmetric encryption. In one embodiment, PUF4 and PUF5 are not shared with the end user or the host.

[0322] The above method is modular in that PUF2, PUF3, PUF4 and / or PUF5 are not required for generating the obfuscated key. Instead, in various embodiments, one or more of the aforementioned obfuscation steps may be applied to the initial key, and the ordering may be changed in addition. For example, the number of obfuscation steps may be reduced for systems that are known not to have a Vdd voltage supply drop.

[0323] In one embodiment, when storing an obfuscated key, the bit pattern will be physically distributed throughout the non-volatile storage medium (e.g., in different rows and words). For example, a device is able to read bits simultaneously and be immune to multi-bit errors.

[0324] Fig.15 A computing device 603 is shown for storing an obfuscated key 635 in a non-volatile memory (e.g., non-volatile storage medium 109) according to one embodiment. The computing device 603 is Figure 1 141 of the computing device 141. In one example, an obfuscated key is used as UDS. (It should be noted) For example, obfuscation adds entropy to the bits of the key to avoid possible attempts by hackers to understand the value of the key. The device is always able to extract the key by removing the added bits used for obfuscation. In one example, a common hacker attack includes guessing the secret key generated / crafted inside the device by processing the distribution of current absorbed by the device in a certain time frame with statistical tools. Obfuscation alleviates this problem to a considerable extent.

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

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

[0327] In one embodiment, the obfuscated key 635 is securely distributed to another computing device as described in related U.S. non-provisional application Ser. No. 15 / 965,731, filed Apr. 27, 2018, by Mondello et al., entitled “SECURE DISTRIBUTION OF SECRET KEY USING A MONOTONIC COUNTER,” the entire contents of which are incorporated herein by reference as if fully set forth. In other embodiments, the initial key 625 and / or any one or more of the intermediate keys from the obfuscation process described herein may be securely distributed in the same or similar manner. Optionally, an end user / customer reads the value of the initial key (e.g., PUF0), the intermediate key, and / or the final obfuscated key (e.g., PUF5) using the aforementioned methods. For example, the end user may verify that the internal generation of the key is properly performed by the device and / or monitor the statistical quality of the key generation.

[0328] Fig.16 An example of an intermediate key (PUF2) generated by the obfuscation processing module 630 during the obfuscation process according to one embodiment is shown. As mentioned above, the bits of PUF1 are reversed to provide reversed bits 702. Bits 702 are interleaved with the bits of PUF1 as illustrated. For example, every second bit in the illustrated key is an interleaved reversed bit 702.

[0329] Fig.17 Demonstrating an embodiment of Fig.16 802. As mentioned above, the bits of PUF2 are further interleaved with pseudo-random bits 802. As illustrated, bits 802 are interleaved with PUF2. For example, every third bit in the illustrated key is an interleaved pseudo-random bit 802.

[0330] Fig.18 A method for generating an obfuscated key (e.g., obfuscated key 635) and storing it in a non-volatile memory (e.g., non-volatile storage medium 109) according to one embodiment is shown. In one example, Figure 2 The memory system 105 stores the obfuscated key in the non-volatile memory 121.

[0331] At block 911 , an initial key is generated based on a value provided by at least one physically unclonable function (PUF).

[0332] In other embodiments, an initial key is generated by key injection at block 911. For example, the initial key may simply be a value injected into the chip during manufacturing.

[0333] At block 913, an obfuscated key is generated based on the initial key. For example, the generated obfuscated key is PUF3 or PUF5.

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

[0335] 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 process at manufacturing time.

[0336] In one embodiment, a method includes: generating an initial key provided by key injection or based on a value provided by at least one physically unclonable function (PUF); generating an obfuscated key based on the initial key; and storing the obfuscated key in a non-volatile memory of a computing device.

[0337] 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 to a message authentication code (MAC) to generate the initial key.

[0338] In one embodiment, the obfuscated key is stored in non-volatile memory outside of the user addressable memory space.

[0339] In one embodiment, generating the obfuscated key includes concatenating the initial key with a predetermined bit pattern.

[0340] In one embodiment, concatenating the initial key and a predetermined bit pattern provides a first key (eg, PUF1); and generating the obfuscated key further includes interleaving the first key and an inverted bit pattern, wherein the inverted bit pattern is provided by inverting bits of the first key.

[0341] In one embodiment, interleaving the first key with the inverted bit pattern provides a second key (eg, PUF2); and generating the obfuscated key further includes interleaving the second key with pseudo-random bits.

[0342] In one embodiment, the method further comprises deriving pseudo-random bits from the first key or the second key using a hash function.

[0343] In one embodiment, interleaving the second key with pseudo-random bits provides a third key (eg, PUF3); and generating the obfuscated key further includes concatenating the third key with error correction code bits.

[0344] 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 a message encrypted using the shared at least one of the initial key, the first key, or the third key from the second computing device.

[0345] In one embodiment, concatenating the third key with the error correction code bits provides a fourth key (eg, PUF4); and generating the obfuscated key further includes concatenating the fourth key with one or more copies of the fourth key.

[0346] In one embodiment, concatenating a fourth key with one or more copies of the fourth key provides a fifth key (e.g., PUF5); and storing the obfuscated key includes storing a first copy of the fifth key on at least one of a row or block of a non-volatile memory that is different from a row or block on which a second copy of the fifth key is stored.

[0347] In one embodiment, a system includes: at least one physically unclonable function (PUF) device (e.g., PUF device 121) configured to provide a first value; a non-volatile memory (e.g., non-volatile storage medium 109) configured to store an obfuscated key (e.g., key 635); at least one processor; and a memory containing instructions configured to direct the at least one processor to: generate an initial key based on the first value provided by the at least one PUF device; generate an obfuscated key based on the initial key; and store the obfuscated key in the non-volatile memory.

[0348] In one embodiment, the system further includes a message authentication code (MAC) module (eg, MAC 123) configured to receive a value provided by the at least one PUF device, wherein generating the initial key includes generating the initial key using the first value as an input to the MAC module.

[0349] In one embodiment, generating the obfuscated key includes at least one of: concatenating the key with a predetermined bit pattern; interleaving a first key with an inverted bit pattern of the first key; interleaving the key with pseudo-random bits; concatenating the key with error correction code bits; or concatenating a second key with one or more copies of the second key.

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

[0351] In one embodiment, generating the obfuscated key includes concatenating the initial key with the first bit pattern.

[0352] In one embodiment, concatenating the initial key and the first bit pattern provides the first key; and generating the obfuscated key further includes interleaving the first key and the second bit pattern.

[0353] In one embodiment, generating the obfuscated key further comprises interleaving the key with pseudo-random bits.

[0354] In one embodiment, generating the obfuscated key further comprises concatenating the key with error correction code bits.

[0355] In one embodiment, a non-transitory computer storage medium stores instructions that, when executed on a computing device, cause the computing device to perform a method comprising: generating an initial key using at least one physically unclonable function (PUF); generating an obfuscated key based on the initial key; and storing the obfuscated key in a non-volatile memory.

[0356] Fig.19 A computing device 1003 is shown for generating an initial key 625 based on key injection 1010, obfuscating the initial key, and storing the obfuscated key in non-volatile memory, according to one embodiment.

[0357] In one embodiment, the initial key 625 is generated by using the injection key 1010. For example, the initial key 625 is present in the chip by injection in a factory or other secure environment during manufacturing or other assembly or testing. In one example, the initial key 625 is used as the initial UDS of the computing device 1003. Obfuscation can also be applied to the UDS. The UDS is a securely generated secret that DICE-RIoT begins using to generate keys and certificates. The application process of increasing the obfuscation of the initial key is performed by applying the obfuscation process (via module 630) to the injection key (e.g., the value from the key injection 1010). In other embodiments, the obfuscation process can be applied to any other value that may be stored on or originally present on the chip or die.

[0358] Changes in key generation and secure storage

[0359] Various additional non-limiting embodiments are now described below. In one embodiment, after (or during) the first power up of the system board, a special sequence is activated to turn on the device containing the cryptographic engine (e.g., cryptographic module 127). The sequence further wakes up the internal PUF and verifies its functionality, and then the PUF generates an initial value PUF0, such as described above. The PUF0 value is processed by an on-chip algorithm (e.g., by the obfuscation processing module 630) and written in a special area of ​​the non-volatile array (outside the user addressable space). In an alternative embodiment, instead of the PUF0 value, the injection key is processed by the on-chip algorithm similar to that described below to provide an obfuscated key for storage.

[0360] In one embodiment, an obfuscation process is performed to prevent Vdd (voltage) and / or temperature fault hacking attacks. This process includes cascading PUF0 with a well-known pattern (e.g., it contains a fixed amount of 0 / 1 bits). These bits permit the determination of whether the read circuitry can properly distinguish 0 / 1 bits when reading the PUF value internally during the lifetime of the device (e.g., chip). For example, PUF1 = PUF0||010101...01.

[0361] Next, the result of the above processing (e.g., PUF1) is further embodied with dummy bits (e.g., to avoid Icc hacker analysis). Specifically, for example, the bits of PUF1 are compared with the inverted version of PUF1 (i.e., It is formed by inverting each bit of PUF1) interleaved. For example, PUF2 = PUF1 interleaved

[0362] In one embodiment, the interleaving rules depend on the type of column decoders (e.g., of the NV non-volatile array) present on the chip / device. The device ensures that each time a PUF value is read (from the non-volatile array), the read circuitry processes (in a single trigger) both the PUF1 and the PUF2 values. This ensures that the same number of 0-valued and 1-valued bits are read, which provides a regularly shaped supply current (Idd).

[0363] Next, the bits of PUF2 are further interleaved with pseudo-random bits. In one example, the interleaving depends on the non-volatile array column decoder structure. In one embodiment, the output has the same number of PUF2 bits padded with a specific number of pseudo-random bits (e.g., in order to obfuscate the last remaining correlation that may exist in the PUF2 pattern).

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

[0365] In one embodiment, optionally, to reduce or prevent bit loss due to non-volatile aging, the bits of PUF3 are concatenated with error correction code (ECC) bits. In one embodiment, the bits of PUF4 are optionally replicated one or more times (which also extends the ECC capacity). For example, the foregoing can be implemented on a NAND memory. In one example, PUF5 = PUF4 || PUF4 || ... || PUF4.

[0366] In one embodiment, the value of PUF5 may be written two or more times on different rows and / or blocks of the non-volatile memory array.

[0367] As a result of the obfuscation process described above, for example, once the final PUF value is written to a non-volatile array block, the value can be used with reduced or no concern for key reliability (e.g., due to noise or charge loss) or any attempts to infer its value through Idd analysis or to rob its value through Vdd fault attacks.

[0368] In one embodiment, once the obfuscation process is complete, the PUF circuitry may be disabled. In one embodiment, after deactivation, the PUF device may provide values ​​used internally on the device for other purposes (eg, using standard read operations within a non-volatile array).

[0369] In one embodiment, the key bits are distinguished from the random bits when the key is extracted from PUF3. For example, the internal logic of the device storing the key knows the location and method needed to return from PUF5 to the previous or original PUF (eg, PUF3).

[0370] In one embodiment, the device extracting the key knows the bit positions of the key bits. For example, the internal logic of the device may receive one of the intermediate PUF or the final key PUF5, depending on design choice. Then, applying the operations in reverse order will obtain the original PUF. For example, the processing steps from PUF1 to PUF5 are performed to store the obfuscated PUF in a way that a hacker must both: read the content (e.g., the key bits), and also know the operations applied in order to go back to and determine the original key.

[0371] Using PUF to generate identity for computing devices

[0372] Various embodiments related to generating an identity of a computing device using a Physical Unclonable Function (PUF) are now described below. The generality of the following description is not limited by the various embodiments described above.

[0373] In previous methods, the manufacturer of the computing device is required to share one or more secret keys with the customer who purchases the computing device in order to establish the identity of the computing device. However, sharing secret keys poses technical problems due to the need for cumbersome, complex and expensive secure channels and infrastructure with the customer for sharing the keys. In addition, human services are required to implement key sharing. In addition, the aforementioned security requirements increase the risk that security measures may be compromised by hackers or other unauthorized persons.

[0374] The various embodiments of the present disclosure discussed below provide technical solutions to the above technical problems. In various embodiments, a computing device generates an identifier using one or more PUFs. In one example, the identifier is a UDS.

[0375] In one embodiment, the computing device's identity generation is assigned in an automated manner (e.g., based on a scheduled time or occurrence of a predetermined event in response to which the computing device will self-generate a UDS using the PUF). By using the PUF to assign identities, the complexity and expense of identity assignment may be reduced.

[0376] After the computing device generates the identification, it can be used to generate a triple of an identifier, a certificate, and a key. In one embodiment, the triple is generated in response to receiving a message from a host device. The host device can use the generated identifier, certificate, and key to verify the identification of the computing device. After verifying the identification, further secure communications with the computing device by the host device can be performed using the key.

[0377] In some embodiments, the computing device generates an identification in response to receiving a command from a host device. For example, the command may be a secure replacement command authenticated by the computing device. After generating the identification, the computing device sends a confirmation message to the host device confirming the generation of the replacement identification. In one example, the replacement identification is a new UDS stored in non-volatile memory and replaces a previously stored UDS (e.g., a UDS assigned by the original manufacturer of the computing device).

[0378] In one embodiment, the identification is a device secret (such as a UDS used in a DICE-RIoT protocol, such as discussed above, for example) stored in a memory of a computing device. At least one value is provided by one or more PUFs of the computing device. The computing device generates the device secret using a key derivation function (KDF). The value provided by the one or more PUFs is an input to the KDF. The output of the KDF provides the device secret. The output of the KDF is stored in a memory of the computing device as the device secret.

[0379] In one example, the KDF is a hash. In one example, the KDF is a message authentication code.

[0380] In one embodiment, the computing device stores a secret key for communicating with a host device, and the KDF is a message authentication code (MAC). At least one value provided by the one or more PUFs is a first input to the MAC, and the secret key is used as a second input to the MAC.

[0381] In some examples, the computing device may be a flash memory device. For example, a serial NOR may be used.

[0382] Fig. 20Computing device 141 is shown for generating an identity, such as a UDS of computing device 141, using a Physical Unclonable Function (PUF) 2005, according to one embodiment. More specifically, a value is provided by PUF 2005. This value is provided as input to a Key Derivation Function (KDF) 2007. The output from the KDF is stored as device secret 149.

[0383] In one embodiment, device secret 149 is a UDS used in the DICE-RIoT protocol. Similar to the above description, UDS can be used as a basis for generating a triplet sent to host device 151. This triplet contains a public key that can be used by host device 151 to communicate securely with computing device 141.

[0384] In one embodiment, the generation of the device secret is performed in response to receiving a command from the host device 151 via the host interface 2009. In one example, the command is a replace command. In one example, the command is accompanied by a signature signed by the host device 151 using a secret key. After the device secret is generated, a confirmation message is sent to the host device 151 via the host interface 2009.

[0385] In one embodiment, computing device 141 stores secret key 2013. For example, secret key 2013 may be shared with host device 151. In one example, host device 151 uses secret key 2013 to sign a signature sent with the replace command.

[0386] In one embodiment, KDF 2007 is a message authentication code. Secret key 2013 is used as the key input to KDF 2007 when generating the device secret. The value from PUF 2005 is used as the data input to KDF 2007.

[0387] The freshness mechanism is implemented in computing device 141 using monotonic counter 2003. Monotonic counter 2003 can provide a value for use as freshness to communicate securely with host device 151.

[0388] A unique identifier (UID) 2001 is stored in the memory of the computing device 141. For example, the UID 2001 is injected at the factory.

[0389] In one embodiment, computing device 141 is delivered to the customer with a well-known UDS (e.g., commonly used UDS = 0x00000 ... 000 or similar). The customer uses host device 151 in its factory to request computing device 141 to self-generate a new UDS (e.g., UDS_puf). This step can be accomplished using authenticated commands. Only the customer or host device that knows secret key 2013 can do this (e.g., secret key 2013 can be more commonly used to manage the authenticated command set supported by computing device 141).

[0390] Once UDS_puf is generated, it is used to replace the original (common) UDS. The replacement occurs by using an authenticated command. An external host device (client) can read UDS_puf.

[0391] The generated UDS_puf may be used to implement the DICE-RIoT protocol. For example, FDS may be calculated using UDS_puf, similar to that described above for identification component 147 and identification component 107. In one example, FDS = HMAC-SHA256[UDS, SHA256("Identification of L1")].

[0392] In addition, a triplet of identifier, certificate, and key (e.g., K L1 ) can be generated using UDS_puf, similar to the above for Figure 1 Description. The host device uses a key (such as K L1 public) to communicate with computing device 141 in a trusted manner.

[0393] In one embodiment, the above-mentioned identification generating mechanism can be automatically executed by a computing device (e.g., an application board including a processor) when the application board is used for the first time or after a scheduled or predetermined event occurs (e.g., as scheduled / determined by the customer and stored in memory 145 as a configuration of the computing device, such as an update, etc.).

[0394] In one embodiment, self-identification generation is performed as follows: A configurator host device (e.g., a laptop computer with software) is connected to a computing device coupled to an autonomous vehicle bus (e.g., using a secure over-the-air interface, etc.). The host device requests the computing device to self-generate a UDS (e.g., a UDS PUF ). Authentication is based on a secret key 2013 (eg, the secret key may be injected by the manufacturer and provided to the customer using a secure infrastructure).

[0395] Authenticated command execution is confirmed with an authenticated response (e.g. Fig. 20 In UDS PUFWhen the generation is complete, the host device is notified of the UDS generated by using a secure protocol (e.g., by sending via a secure wired and / or wireless network using the freshness provided by the monotonic counter 2003). PUF .

[0396] In one embodiment, host interface 2009 is a command interface that supports authenticated and replay protected commands. In one embodiment, authentication is based on a secret key (e.g., secret key 2013) and uses a MAC algorithm (e.g., HMAC). In one example, an identification generation command is received from host device 151 that includes a signature based on the command opcode, command parameters, and freshness. In one example, signature = MAC (opcode | parameters | freshness, secret key).

[0397] In one embodiment, computing device 141 provides an identification generation confirmation including a signature. In one example, signature = MAC (command result | freshness, secret key).

[0398] In one embodiment, the secret key 2013 is injected at the factory. In one example, the secret key can be symmetric (e.g., based on HMAC-SHA256). In another example, the secret key can use an asymmetric scheme (e.g., ECDSA).

[0399] Device Secret 149 (eg UDS PUF ) can be generated using various options. For example, once the generation process is activated, by using appropriately authenticated and replay-protected commands, UDS PUF Generated by selecting the following command options:

[0400] Option #1: From PUF pattern (sometimes called "PUF RAW") (sometimes also denoted as UDS RAW ) is read and fed into a KDF 2007 (key derivation function) (e.g. SHA256). The result of this process is the final key. Therefore: UDS PUF =KDF(UDS RAW ).

[0401] Option #2: PUF RAW Mode (UDS RAM ) is read and UDS PUF Calculated as: UDS PUF =KDF(UDS RAW |UID), where UID is a public unique ID assigned to all devices (in some cases, UIDs may also be assigned to non-secure devices). In one embodiment, UID 2001 is used as input to the KDF.

[0402] Option #3: PUF RAW Mode (UDS RAM ) is read and UDS PUF Calculated as: UDS PUF =KDF(UDS RAW |UID|HASH(user-mode)), where the user-mode is provided by the host in the command payload requesting the self-identification generation.

[0403] Option #4: PUF RAW Mode (UDS RAM ) is read and UDS PUF Calculated as: UDS PUF =KDF(UDS RAW |UID|HASH(user mode)|freshness), where freshness is, for example, the freshness provided in the command payload.

[0404] More generally, UDS is calculated as UDS PUF =KDF[(information provided by the host device|information present in the device)] The KDF function can be used as a simple HASH function (such as SHA256) or a MAC function (such as HMAC-SHA256) using a secret key.

[0405] In one example, when a MAC function is used as a KDF, the secret key used is the same key used to provide authenticated commands. A device secret (such as a UDS) may be generated using one of the following options:

[0406] Option #5: UDS PUF =MAC[Secret_Key,(UDS RAW )]

[0407] Option #6: UDS PUF =MAC[Secret_Key,(UDS RAW |UID)]

[0408] Option #7: UDS PUF =MAC[Secret_Key,(UDS RAW |UID|HASH(user mode))]

[0409] Option #8: UDS PUF =MAC[Secret_Key,(UDS RAW |UID|HASH(user mode)|freshness)]

[0410] More generally, UDS PUF =MAC[Secret_Key, (information provided by the host | information present in the device)]

[0411] As mentioned above, UDS PUF After being generated, it can be transmitted to the host device 151. In one embodiment, the host device 151 can directly read the UDS PUF .UDS PUF Can only be read a predetermined number of times (e.g. only once or a few times). In one example, the following Fig.21 Describe the process. Reading UDS PUF After a predetermined number of times, the reading mechanism is permanently disabled. For example, this method can be used in a secure environment such as a customer's factory when assembling a computing system or other product using computing device 141.

[0412] In one example, UDS PUF The public key is encrypted by computing device 141 using the public key received from host device 151 and then UDS PUF sent to the host device 151. After this procedure, UDS is permanently disabled PUF Read the institution.

[0413] In another embodiment, the computing device 141 includes an obfuscation processing module 2011. The obfuscation processing module 2011 is Fig.15 The obfuscation processing module 630 or Fig.19 An instance of the obfuscation processing module 630.

[0414] In one embodiment, the UDS PUF The host public key is encrypted and transmitted to the host device; the host device decrypts it using its corresponding secret key. The host public key is transmitted to the computing device 141 during a specific communication establishment phase. In one embodiment, the UDS PUF The sharing of may be accomplished by a direct read operation using an authenticated command, and after a predetermined number of reads (e.g., typically only once), this read operation is permanently disabled. The computing device 141 stores the UDS key in a tamper-proof area. At each use of the UDS key also for internal (computing device) use, an obfuscation mechanism is used to avoid information leakage (e.g., by avoiding any possibility of a hacker guessing the stored UDS key, such as by a hacker analyzing the current or voltage wave distribution). For example, the obfuscation mechanism used may be as described above for Fig.15 , 18 、19Description.

[0415] In one embodiment, computing device 141 obfuscates the device secret before sending the encrypted device secret to host device 151 .

[0416] Fig.21A system is shown that sends an initial value provided by a monotonic counter of the system for determining whether system tampering has occurred according to one embodiment. In one example, the system is Fig. 20 The computing device 141.

[0417] In some embodiments, the system uses a secret key to securely communicate with other devices, such as host device 151. The secret key is generated and stored on the system (eg, by factory key injection after initial assembly of the system board). The system's monotonic counter is used to provide an initial value.

[0418] In another embodiment, the secret key is a UDS used with the DICE-RIoT protocol. The secret key is generated in response to a command from a host device (eg, host device 151).

[0419] In one embodiment, the initial value is sent by electronic communication to an intended recipient of the physical system (e.g., the recipient will receive the physical system after the physical system is physically transported to the recipient's location). After receiving the system, the recipient reads the output value from the monotonic counter. The recipient (e.g., using a computing device or server of the recipient that earlier received the initial value) compares the initial value to the output value to determine whether system tampering has occurred. In one example, tampering is an unauthorized attempt by an intruder to access a secret key of the system during physical transport of the system.

[0420] In one embodiment, the secret key may be generated, for example using a true RNG (Random Number Generator) or PUF, or previously injected into the system (memory) in a secure environment like a factory.

[0421] In one embodiment, the generated key is associated with an initial value of a monotonic counter. The initial value is used by the recipient of the system to determine whether unauthorized access to the stored key has been attempted. In one embodiment, the key injection process can use the output from a Physical Unclonable Function (PUF) to generate a key for each power-on cycle of the computing device storing the key.

[0422] More specifically, Fig.21 A system 351 is shown sending an initial value provided by a monotonic counter 355 for determining whether tampering of the system 351 has occurred, according to one embodiment. For example, it may be determined whether the system 351 has been tampered with by a hacker seeking to gain unauthorized access to a stored key during physical transport of the system 351. In one example, the system 351 is a system board including non-volatile memory 306, processor 304, monotonic counter 355, and power supply 318.

[0423] One or more keys 314 are generated under the control of the processor 304. The non-volatile memory 306 is used to store the generated keys. The non-volatile memory 306 is, for example, a non-volatile memory device (eg, a 3D cross point memory device).

[0424] The monotonic counter 355 is initialized to provide an initial value. This initial value is associated with the stored key 314. The initial value is sent by the processor 304 to another computing device via the external interface 312. For example, the initial value may be sent to a server of a receiver to which the system 351 will ship after manufacturing and key injection is complete.

[0425] When the system 351 is received by the receiver, the receiver's computing device determines the initial value. For example, the computing device may store the initial value received when sent as described above in a memory. The computing device reads the output value from the monotonic counter 355. This output value is compared with the initial value to determine whether the system 351 has been tampered with.

[0426] In one embodiment, the computing device of the receiver determines the number of events that have occurred that caused the monotonic counter 355 to be incremented. For example, the output value from the monotonic counter 355 may be configured to increment upon each power-on operation of the system 351 (e.g., as detected by monitoring the power supply 318). The output value from the monotonic counter 355 may additionally and / or alternatively be configured to increment upon each attempt to perform a read access of the stored key 314.

[0427] By tracking the number of known events that cause a monotonic counter to increment, for example, the initial value received from the transmitter can be adjusted based on this known number of events. The adjusted initial value is then compared to the output value read from the monotonic counter 355. If the values ​​match, then no tampering has occurred. If the values ​​do not match, then the computing device determines that tampering has been detected.

[0428] In response to determining that tampering has been detected, one or more functions of the system 351 may be disabled. In one embodiment, the processor 304 receives a communication from the computing device of the receiver including an indication that tampering has been detected. In response to receiving the communication, the processor 304 disables at least one function of the system 351. In one example, the disabled function is read access to the stored key 314.

[0429] In one embodiment, the system 351 may be configured so that the counter value output from the monotonic counter 355 does not exceed a predetermined maximum value. For example, as each counter value is read from the monotonic counter 355, a determination is made as to whether the counter value exceeds the predetermined maximum value. If the counter value exceeds the predetermined maximum value, read access to the stored key 314 may be permanently disabled (e.g., under the control of the processor 304).

[0430] In one embodiment, system 351 is embodied on a semiconductor die. In another embodiment, system 351 is formed on a system board. Applications are stored in system memory 353 and executed by processor 304. Execution of the applications occurs after system 351 is powered on. For example, a receiver of system 351 may execute an application after determining that no system tampering has occurred.

[0431] In one embodiment, key 314 is generated using output values ​​from one or more physically unclonable functions (PUFs). For example, a key is generated for each power-on cycle of system 351. In another example, key 314 is a UDS generated in response to a replacement command received from a host device via external interface 312.

[0432] In one embodiment, system 351 is a controller storing key 314. External interface 312 is used to send the initial value from monotonic counter 355 to an external non-volatile memory device (not shown) on the same system board as the controller. The external non-volatile memory device determines whether tampering has occurred by reading the output value from monotonic counter 355 and comparing the output value with the initial value received from system 351.

[0433] In one embodiment, system memory 353 includes volatile memory 308 and / or non-volatile memory 306. Cryptographic module 316 is used to perform cryptographic operations for secure communication via external interface 312 using key 314 (eg, a symmetric key).

[0434] Secret key sharing is now described in various further embodiments. A secure communication channel is established by sharing keys between the participants involved in the communication. Components used in Trusted Platform Module boards typically do not have sufficient processing power to implement schemes such as, for example, public key encryption.

[0435] In one embodiment, one or more secret keys are shared between the device / board manufacturer and the OEM / end customer. Also, keys can be physically shared between different devices in the same board as needed. One or more monotonic counters are used inside the security device, as discussed above.

[0436] In one example, before a device leaves the factory or manufacturer's test line, one or more secret keys are injected into the device (for example, one or more secret keys are as follows: Secret_Key k , where k = 1, ..., N), which depends on the device capabilities and user requirements.

[0437] One or more monotonic counters are initialized to (N(N≥1) different MTC→MTC depending on device capabilities and user needs k=0). The monotonic counter (MTC) is configured to increment the output value any time system / device power-on occurs and any time the stored secret key is (attempted) to be read.

[0438] Each MTC k The value of may be public and shared with clients (e.g. as an MTC k A command sequence (eg, as arbitrarily determined by a system designer) is used to read the key from the device, and the command sequence may be public (eg, the strength of the method is not based on the confidentiality of the read protocol).

[0439] In one embodiment, each secret key does not need to use a dedicated MTC. This may vary depending on the type of security service used. For example, some keys may be read together and only a single MTC is needed.

[0440] In one embodiment, after the system arrives at the receiver (e.g., client / user) location, several operations are performed. The receiver's computing device first determines the initial value of the monotonic counter 355. For example, retrieve the MTC k =(MTC0) k The value of each MTC or associated key (e.g., the initial value written and sent when the device leaves the factory). k The value can be different.

[0441] Next, the receiver client / user powers on the system 351. The first addressing operation is MTC k If each MTC k The value matches the expected (received) initial value [e.g., MTC k =(MTC0+1) k ], then the device is determined to have not been powered on during physical shipping or other transfer, and the system 351 is deemed authentic (and not tampered with) by the end user / customer.

[0442] If one or more values ​​do not match, tampering has occurred. For example, an unauthorized person powered on the device and attempted to read the stored key. If tampering has occurred, the device is discarded and a tamper indication is transmitted to the sender (e.g., the transmitting company) to avoid further technical security issues.

[0443] In another embodiment, multiple read operations are performed by a receiver of system 351. For example, a device leaves the factory and arrives at a customer / OEM. The customer reads one or more keys and the associated MTC k Increment by 1. If the MTC is incremented j exceeds the value preset by the silicon factory (sender) (MTC j MAX ), then the key (Secret_Keyj ) is permanently disabled.

[0444] In this example, MTC j MAX is a predetermined maximum value per MTC agreed upon by the sender and the customer. This method allows one or more key read attempts to be made after / before a read of the MTC value can be checked or performed. This allows, for example, to discover any unauthorized access while also ensuring that the OEM / customer performs a read of the key a few times before deactivation.

[0445] If during the read process one or more MTCs have unexpected values ​​(e.g., the initial value does not match the read value after a known number of read and power-on operations), then the device is discarded. In one embodiment, once all keys are read, the relevant MTCs are k is cleaned and can be reused for other purposes (such as cryptographic processing functions, etc., as configured and desired by the system designer).

[0446] In another example, the monitoring device / board uses. This example uses a monotonic counter that already exists on the secure device (e.g., exists to be used by the encryption module 316). Before the device leaves the silicon factory, the following is performed on the test line: Initialize M (M≥1) different MTC → MTC k =0.

[0447] Such MTC counters are incremented each time the device is powered on. Each counter may be initialized to zero (or another initial value, if desired).

[0448] The receiver end user can use the received MTC k The value obtains various information about the system 351, such as (for example): detection of unauthorized use of components / boards, determination that a component has been desoldered and used outside the board to hack it, power cycle counting for customer based service implementation charging mechanism, device board warranty policy and power consumption.

[0449] In one embodiment, implementing a charging mechanism involves associating a value with a specific usage. An application may be provided to a customer, and the customer must pay a fee to unlock a specific usage.

[0450] In one embodiment, the secret key is shared between different devices on the same system board (eg, physically shared when used by an end user). The key is shared by exchanging between components on the same board (eg, between processors).

[0451] In one embodiment, each of the one or more monotonic counters (MTCk) is initialized by setting its initial value to zero. In one example, when MTCk=0 is set, MTCk is a counter associated with a specific key indicated by the number k. MTCk=0 indicates that the initial value of the counter is zero. Each k indicates one of the counter numbers corresponding to the number of internal keys stored in the device. The value of each counter is stored in a non-volatile memory area of ​​the device.

[0452] In one embodiment, power-on (also sometimes referred to as power-up) of a device is detected. The device includes internal circuitry that measures the value of a power supply. When the power supply exceeds a certain threshold, the circuitry triggers an internal signal to indicate that a power-on event exists (is detected). This signal may cause a monotonic counter to increment.

[0453] In one embodiment, an attempt to read a secret key is detected. A counter (MTCk) is incremented each time power is detected (as mentioned above) and further each time a command sequence to read the key is recognized by the device interface. Knowing the initial MTCk value allows the final recipient of the device (e.g., end user / customer) to know the device (and counter) state when the device is shipped. Therefore, if an attempt is made to power on and / or read the device during transit, this results in a change in the counter value stored in each MTCk.

[0454] In one embodiment, a command sequence is used to read a key from a device. For example, the device has an external interface that accepts commands from other computing components or devices. The key can be used to read until a maximum counter value is reached. In one example, the device has a sequence at the interface: command (e.g., 0x9b) + arguments (0x34) + signature. The device knows that the key will be read and provided at the output.

[0455] In one embodiment, after testing the device (e.g., at the initial factory), the MTCk for each key will have an initial value from initialization. So, for example, if k=3, then: MTC0=20d, MTC1=25d, MTC2=10. The values ​​MTC0, MTC1, MTC2 are sent / transmitted to the customer as a set of initial values. When the device is received by the customer, the customer uses a command sequence to read the values. Then, the customer (e.g., using a computing device) determines whether the device was damaged during shipping. In one example, the monotonic counter value is read using the command sequence described above.

[0456] In one embodiment, a predetermined maximum counter value is preset. For example, the preset maximum value can be selected based on the customer program. For example, assume that the customer wants to read the key 10 times. In addition, assume that MTCk is incremented only when the power is turned on, and assume that there are two counters: MTC0 (only associated with power on) and MTC1 (only associated with the key read command program). After factory testing, based on monitoring the MTC0 and MTC1 values, it is found that: MTC0=30, MTC1=25. In one example, the internal threshold of MTC0 is set to 40, and the internal threshold of MTC1 is set to 35.

[0457] In one embodiment, the MTC associated with the key is incremented upon power-up and an attempt to read the key. The MTC is incremented each time one of two events occurs.

[0458] In one embodiment, the monotonic counter is cleared after the last read of the stored key (and optionally can be reused for other processing on the device). The system designer can configure this as needed. For example, when the purpose of the MTC counting is as a detector of malicious events, the final read is no longer needed. This frees up the counter as a resource (which can be used for other purposes), or the counter can keep counting.

[0459] In one embodiment, the monotonic counter can be used to obtain various types of information, such as a component being desoldered, implementing a charging mechanism, implementing a warranty, etc. The counter can be used to monitor different types of occurrences because the increment of the counter value can be triggered externally.

[0460] In one embodiment, a multi-key read option is provided. In one example, for initialization of the MTC value (for the MTCk associated with the key), a maximum threshold is set to allow each key to be read by the component and / or the end user's receiver. The multi-read option allows the threshold to be changed according to the maximum number of attempts to read a specific key (which may be different for each key).

[0461] In one embodiment, various types of devices can use the above method. For example, a CPU or MCU typically has an internal hardware security module that is not accessible to external access. In one example, it is necessary to have the same key stored in the device or component (for example, when using a symmetric key method) in order to operate correctly. In this case, the CPU / MCU benefits from the distribution / sharing of the key to authorized entities, devices or components. This sharing allows the key to be read (for example, this sharing corresponds to programming the value within the MTCK threshold).

[0462] In one embodiment, the above method is used for customer firmware injection. For example, the above method allows critical content to be stored inside the device (such as application firmware) and the movement of the device to be implemented in an unsecured environment (without compromising the integrity of the firmware / device). In one example, for firmware injection, unexpected changes in the MTCk counter value during transportation are used as an indicator that firmware corruption has occurred.

[0463] Fig. 22 A method for generating an identity of a computing device using a physically unclonable function (PUF) according to one embodiment is shown. For example, Fig. 22 The method can be implemented in Fig. 20 in the system.

[0464] Fig. 22 The method may be performed by processing logic, which may include hardware (such as a processing device, a circuit system, a dedicated logic, a programmable logic, a microcode, hardware of a device, an integrated circuit, etc.), software (such as instructions running or executing on a processing device), or a combination thereof. In some embodiments, Fig. 22 The method is at least partly based on Fig. 20 Executed by processor 143.

[0465] Although shown in a particular sequence or order, the order of the processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0466] At least one value is provided by at least one physically unclonable function (PUF) at block 2211. For example, PUF 2005 provides a value as an output.

[0467] At block 2213, a device secret is generated using a key derivation function (KDF). At least one value provided by at least one PUF is used as an input to the KDF. For example, the output from PUF 2005 is used as an input to KDF 2007.

[0468] At block 2215, the generated device secret is stored. For example, KDF 2007 generates an output that is stored as device secret 149.

[0469] In one embodiment, a method includes: generating a device secret (e.g., a UDS stored as device secret 149) by a computing device, the generation comprising: providing at least one value by at least one physically unclonable function (PUF); and generating the device secret using a key derivation function (e.g., KDF 2007), wherein at least one value provided by at least one PUF is an input to the KDF; and storing the generated device secret in a memory of the computing device.

[0470] In one embodiment, storing the generated device secret includes replacing a previously stored device secret in a memory with the generated device secret.

[0471] In one embodiment, the KDF is a hash or a message authentication code.

[0472] In one embodiment, the method further includes storing a secret key for communicating with the host device, wherein the KDF is a message authentication code (MAC), the at least one value provided by the at least one PUF is a first input to the MAC, and the secret key is a second input to the MAC.

[0473] In one embodiment, the device secret is generated in response to an event, and the event is the receipt of a command by the computing device from the host device.

[0474] In one embodiment, the method further includes: receiving a host public key from the host device; encrypting the generated device secret using the host public key; and sending the encrypted device secret to the host device.

[0475] In one embodiment, the method further includes permanently disabling read access to the device secret in the memory after sending the encrypted device secret to the host device.

[0476] In one embodiment, the method further includes obfuscating the device secret prior to sending the encrypted device secret to the host device.

[0477] In one embodiment, the method further includes storing, by the computing device, a secret key (eg, secret key 2013) in a memory, wherein the command is authenticated by the computing device using a message authentication code (MAC) and the secret key is used as an input to the MAC.

[0478] In one embodiment, the host device sends a signature for authenticating the command, the signature is generated using a MAC, and the freshness generated by the host device is used as an input to the MAC.

[0479] In one embodiment, freshness is an additional input to the KDF.

[0480] In one embodiment, the host device provides the user pattern with a command, and wherein a hash of the user pattern is an additional input to the KDF.

[0481] In one embodiment, the method further includes authenticating, by the computing device, the command prior to generating the device secret.

[0482] In one embodiment, the method further includes storing a unique identifier of the computing device, wherein the unique identifier is an additional input to the KDF.

[0483] In one embodiment, the device secret is generated in response to an event, and the event is detection of usage of the computing system by the computing device.

[0484] In one embodiment, the use is the execution of an application by a computing system. In one embodiment, the use is the initiation of a boot loading process.

[0485] In one embodiment, wherein the device secret is generated in response to an event, and the event is a scheduled event.

[0486] In one embodiment, a system includes: at least one processor; and

[0487] A memory containing instructions configured to instruct at least one processor to: generate a device secret, the generation comprising: providing at least one value by at least one physically unclonable function (PUF); and generating the device secret using a key derivation function (KDF), wherein the at least one value provided by the at least one PUF is an input to the KDF; and storing the generated device secret in a memory of a computing device.

[0488] In one embodiment, the instructions are further configured to instruct at least one processor to: receive a replace command from a host device; and send a public identifier generated using a generated device secret to the host device; wherein the device secret is generated in response to receiving the replace command; wherein storing the generated device secret includes replacing a previously stored device secret with the generated device secret.

[0489] In one embodiment, a non-transitory computer storage medium stores instructions that, when executed on a computing device, cause the computing device to at least: provide at least one value by at least one physically unclonable function (PUF); and generate a device secret using a key derivation function (KDF), wherein the at least one value provided by the at least one PUF is an input to the KDF; and store the generated device secret in a memory.

[0490] Assign and verify vehicle identification

[0491] Various embodiments involving assigning and verifying identities of vehicles are now described below. In various embodiments, an identity is assigned to a first vehicle (e.g., an emergency vehicle), and a second vehicle verifies the identity of the first vehicle. For example, the identity may be based on a computer (e.g., a computer) provided by the first vehicle. Figure 1 computing device 141) from a host device (e.g. Figure 1 The host device 151) receives a replacement command to assign.

[0492] For example, the identification may be verified by the second vehicle using a verification method based on a triplet provided by the first vehicle. This verification method is performed similarly to that performed by the host device 151 using the triplet received from the computing device 141. The first vehicle may be a vehicle associated with an operating state and / or a class of vehicles (e.g., the first vehicle may be a member of a fleet of vehicles owned by a particular entity). The generality of the following description is not limited by the various embodiments described above.

[0493] In previous methods, the identification of a vehicle as an emergency vehicle, police vehicle, or another vehicle with a special status has been indicated by manual methods and / or methods isolated to emergency vehicles because the identification is not electronically transmitted outside the vehicle. For example, a flashing red light or other emergency indicator is activated to indicate that the vehicle is an emergency vehicle in an emergency operating state. However, this emergency status is not transmitted in any way outside the vehicle.

[0494] The foregoing creates technical problems in identifying vehicles and / or the status of vehicles. For example, other vehicles cannot easily determine the emergency identification or status of the emergency vehicle. For example, other vehicles must rely on visual observation to determine the identification and / or status of the emergency vehicle. This can cause delays in other vehicles taking appropriate responses or reactions to the emergency vehicle. For example, other vehicles are slow to move aside in response so that the emergency vehicle cannot pass faster.

[0495] In addition, for autonomous vehicles, safe traffic management wants autonomous vehicles to have the ability to recognize a specific class of vehicles. This part allows the autonomous vehicle to take appropriate response measures when a specific class of vehicles exists. Vehicle categories may include emergency vehicles such as police cars, fire trucks, and ambulances. Other classes of vehicles may include public service vehicles such as taxis and buses. Still other classes of vehicles may include vehicles in private or company fleets. The inability of an autonomous vehicle to recognize another vehicle of the appropriate class may result in an improper traffic navigation response, which may cause an accident or other injury.

[0496] Furthermore, the lack of a secure identity mechanism may allow hacker attacks such as vehicle cloning, man-in-the-middle attacks, and replay attacks. These may result in the safety and security operation of autonomous vehicles being compromised.

[0497] The various embodiments of the present disclosure discussed below provide technical solutions to the above-mentioned technical problems regarding the assignment and verification of the identification of emergency vehicles. In various embodiments, a computing device (e.g., computing device 141) generates an identification of a vehicle and permits the vehicle to be verified by other vehicles. The identification corresponds to a vehicle class. In one example, the identification is a unique device secret (UDS) for the DICE-RIoT protocol, as described above.

[0498] In one embodiment, a public or private organization or entity customizes the identity of a fleet (e.g., the identity corresponds to a class of vehicles). This is accomplished by sending an authenticated command (e.g., the replace command discussed above) to each vehicle. The command causes the vehicle to assign a UDS provided by the host device or to generate an updated UDS (e.g., using a PUF on the vehicle's computing device, as described above). The UDS is then used by other nearby vehicles to verify the identity of the customizing vehicle during operation.

[0499] In one embodiment, each nearby vehicle receives one or more certificates and keys from an "emergency" vehicle. For purposes of exemplary discussion, an emergency vehicle is described and illustrated below. However, the embodiments below are not limited to use with only emergency vehicles. Alternatively, these embodiments may be used with other types of vehicles. Furthermore, the vehicle may be a land, air, and / or water vehicle (e.g., a drone, a boat, an airplane, etc.).

[0500] In one embodiment, the nearby vehicle has a computing device that includes a verification component for verifying the identity of the emergency vehicle. In one example, the verification component is Figure 1 Authentication component 153. In one example, the nearby vehicle receives the certificate and public key as part of a triplet generated using the DICE-RIoT protocol, such as described above. The nearby vehicle confirms the presence of the emergency vehicle / police car / other vehicle, which allows a secure communication exchange with the emergency vehicle (e.g., insurance coordinates, license plate data, etc.). One advantage is that this secure wireless communication allows nearby vehicles to identify the emergency vehicle without having to look at the emergency vehicle's license plate, etc. In the case of a non-autonomous vehicle, communications with the emergency vehicle can be transmitted to the driver using other methods (e.g., presenting an alert on a display and / or using an in-vehicle entertainment system, cluster, etc.).

[0501] In one embodiment, the emergency vehicle and all nearby vehicles have computing devices that support identification assignment and verification using the DICE-RIoT protocol. Each vehicle with this identification equipment can be customized by a public agency or private enterprise to become part of a fleet (e.g., a fleet of emergency vehicles, taxis, etc.).

[0502] The computing device in each vehicle can be originally manufactured with UDS generic, such as described above. The owner of the vehicle can customize the vehicle using his computing device by replacing the UDS using authenticated and replay-protected commands (such as the replacement commands described in various embodiments above). One advantage is that there is no risk of component replacement because the components have the ability to prove their identity.

[0503] In one embodiment, the UDS generic Replacement allows public authorities to inject their private UDS (such as UDS police department 、UDS fire fighter ). This UDS is used to generate one or more public certificates that can be recognized by the public (including other vehicles). This allows public authorities and / or other vehicles to perform security services by communicating with the vehicle in a secure manner. In one example, the generated certificate is part of a triplet generated using the UDS and identification component 147, as described above for Figure 1 Discussion.

[0504] In one example, a private enterprise can inject its private UDS to identify vehicles in its own fleet and implement secure wireless communication with the vehicles. Vehicles can include, for example, taxis, buses, ships, drones, etc.

[0505] Communication with the vehicle through a central server of a public or private agency can be performed by various wired or wireless communication systems (such as Wi-Fi, 3G to 5G cellular, Bluetooth, etc.), optical wireless communication (OWC), etc.

[0506] Fig.23 A nearby vehicle 2311 is shown verifying the identity of an emergency vehicle 2303 using one or more credentials 2321, according to one embodiment. The identity of the emergency vehicle 2303 has been previously assigned by an authoritative computing device 2305. In one example, the authoritative computing device 2305 sends a replacement command to the computing device 2301 via the host interface 2009.

[0507] In response to receiving the replacement command, the computing device 2301 stores the new device secret in the memory of the computing device 2301 and / or the emergency vehicle 2303. The identification component 147 uses the new device secret to generate a certificate, which is stored as part of the certificate 2321. In one example, the identification component 147 generates a triplet that includes the certificate. The generated triplet also includes the public key stored in the key storage device 157.

[0508] In one embodiment, the nearby vehicle 2311 is an autonomous vehicle that detects the presence of an emergency vehicle 2303 nearby (e.g., within a distance of 500 meters or less, or 50 meters or less, or 5 meters or less). In response to detecting the presence of the emergency vehicle 2303, the nearby vehicle 2311 sends a communication requesting identification. In response to this request, one or more credentials 2321 are transmitted to the verification component 153 of the nearby vehicle 2311. In one example, the verification component 153 receives a triplet, as discussed above for the DICE-RIoT protocol.

[0509] The verification component 153 verifies the identification of the emergency vehicle 2303. In one example, the identification is assigned and then verified using the method described above with respect to FIGS. 5-7 and 9.

[0510] In one embodiment, after verifying the identification of the emergency vehicle 2303, the nearby vehicle 2311 can determine a class of vehicle associated with the identification. For example, the nearby vehicle 2311 can determine that the category corresponds to an emergency vehicle. In one embodiment, the nearby vehicle 2311 can communicate with a public server 2307 that maintains a public database of public identifiers and corresponding categories. In one embodiment, each time the emergency vehicle 2303 is assigned a new identification via the host interface 2009, the authoritative computing device 2305 sends an update communication to the public server 2307.

[0511] In other embodiments, the emergency vehicle 2303 also communicates with the traffic control infrastructure. For example, the traffic control system 2309 can detect the approaching presence of the emergency vehicle 2303 (e.g., similar to that described above for the nearby vehicle 2311) and request identification, similar to that described above for the nearby vehicle 2311. In response to verifying the identification of the emergency vehicle 2303, the traffic control system 2309 can change the state so as to permit the emergency vehicle 2303 to pass freely. For example, the traffic control system 2309 can change the traffic control light from red to green to permit the emergency vehicle to pass.

[0512] After nearby vehicle 2311 verifies the identification of emergency vehicle 2303 , nearby vehicle 2311 may use the public key received from emergency vehicle 2303 as part of a triplet in order to perform subsequent secure communications using communication interfaces 2313 and 2315 .

[0513] In one embodiment, the controller 2319 of the nearby vehicle 2311 executes software to implement the verification component 153. In response to verifying the identification as an identification of an emergency vehicle, the controller 2319 can change the configuration and / or operation of various systems of the nearby vehicle 2311. For example, an alert can be presented to the driver and / or passengers on the display 2317. In addition, for example, the navigation path and / or speed of the vehicle can be changed. In addition, the vehicle's system, such as the braking system, can be activated to slow the vehicle.

[0514] Fig.24 A method for verifying the identity of a vehicle using an identifier, a certificate, and a public key is shown according to one embodiment. For example, Fig.24 The method can be implemented in Figure 1 , 2 and 20 systems.

[0515] Fig.24 The method may be performed by processing logic, which may include hardware (such as a processing device, a circuit system, a dedicated logic, a programmable logic, a microcode, hardware of a device, an integrated circuit, etc.), software (such as instructions running or executing on a processing device), or a combination thereof. In some embodiments, Fig.24 The method is at least partly based on Fig. 20 Executed by processor 143.

[0516] Although shown in a particular sequence or order, the order of the processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0517] At block 2401 , a command is received by a first vehicle from a host device. For example, an authenticated command is received by a computing device 2301 of an emergency vehicle 2303 from an authoritative computing device 2305 .

[0518] In response to receiving the command, a new device secret is stored in memory at block 2403. For example, the command is a replace command, and the computing device 2301 stores a new device secret (e.g., UDS) in memory. The new device secret replaces the previously stored device secret. The new device secret may be received from the authoritative computing device 2305 along with the command. Alternatively, the new device secret may be generated by the computing device 2301, for example, using a PUF.

[0519] In one example, authoritative computing device 2305 is a police car. In response to the existence of an emergency situation, the police car can elevate the status of emergency vehicle 2303 from a regular passenger car to a vehicle in an emergency state. This can be an assignment that only exists for a predetermined amount of time, distance, or until the elevated vehicle reaches a designated destination.

[0520] At block 2405, a triplet is generated using the new device secret. The triplet includes an identifier, a certificate, and a public key. In one example, the computing device 2301 generates the triplet using the identification component 147, similar to the description above for various embodiments.

[0521] At block 2407, the triplet is sent to the second vehicle. The second vehicle is configured to verify the identity of the first vehicle using the triplet. For example, the triplet includes the certificate 2321 and one or more corresponding keys (e.g., a public key and a public identifier) ​​from the key storage device 157. The verification component 153 of the nearby vehicle 2311 verifies the identity of the emergency vehicle 2303 using the triplet. In one embodiment, the nearby vehicle 2311 is configured to perform an action in response to verifying the identity as, for example, a vehicle in an emergency state.

[0522] In one embodiment, a method includes: receiving a command by a computing device of a first vehicle (e.g., emergency vehicle 2303) from a host device (e.g., authoritative computing device 2305); storing a new device secret in a memory of the computing device in response to receiving the command; generating, by the computing device, a triplet including an identifier, a certificate (e.g., certificate 2321), and a public key using the new device secret; and sending, by the computing device, the triplet to a second vehicle (e.g., nearby vehicle 2311), wherein the second vehicle is configured to use the triplet to verify the identification of the first vehicle.

[0523] In one embodiment, the new device secret is: received from the host device; or generated by the computing device after receiving a command from the host device.

[0524] In one embodiment, the new device is secretly associated with a predetermined state or category of the first vehicle. For example, the state is an emergency state.

[0525] In one embodiment, the second vehicle is configured to perform an action in response to verifying the identification of the first vehicle.

[0526] In one embodiment, the action is at least one of: presenting an alert on a user display of the second vehicle; changing a navigation path or speed of the second vehicle; or activating a braking system of the second vehicle.

[0527] In one embodiment, the method further includes sending, by the computing device, the triplet to a traffic control system (e.g., traffic control system 2309), wherein the traffic control system is configured to: verify the identification of the first vehicle using the triplet; and in response to verifying the identification of the first vehicle, change the state of the traffic control system to allow the first vehicle to pass.

[0528] In one embodiment, the new device secret replaces a previously stored device secret in the memory of the computing device.

[0529] In one embodiment, the method further includes storing a secret key for communicating with the host device, wherein the secret key is used as an input to a message authentication code to generate a new device secret.

[0530] In one embodiment, the command is authenticated using a secret key, and the method further includes sending, by the computing device to the host device, a confirmation that the new device secret has been stored.

[0531] In one embodiment, the method further includes, after the second vehicle verifies the identification of the first vehicle: encrypting, by the computing device, a message using a private key, wherein the private key and the public key are an associated pair secretly generated using a new device; and sending, by the computing device, the encrypted message to the second vehicle, wherein the encrypted message includes freshness.

[0532] In one embodiment, the message includes configuration data, the second vehicle is configured to perform an action in response to receiving the message, and the action is performed by the second vehicle in accordance with the configuration data.

[0533] In one embodiment, a system for use in a first vehicle includes: at least one processor; and a memory containing instructions configured to instruct the at least one processor to: receive a command from a host device; in response to receiving the command, store a new device secret; generate a certificate using the new device secret; and send the certificate to a second vehicle, wherein the second vehicle is configured to use the certificate to verify the identity of the first vehicle.

[0534] In one embodiment, the new device secret is: received from the host device; or generated by the system after receiving a command from the host device.

[0535] In one embodiment, the system further includes a memory storing a secret key for communicating with the host device, wherein the instructions are further configured to direct the at least one processor to generate a new device secret using the secret key as an input to the message authentication code.

[0536] In one embodiment, the second vehicle is configured to perform an action in response to verifying the identification of the first vehicle, and wherein the action is at least one of: presenting an alert on a user display of the second vehicle; changing the navigation path or speed of the second vehicle; or activating a braking system of the second vehicle.

[0537] In one embodiment, the new device is secretly associated with a predetermined state or category of the first vehicle.

[0538] In one embodiment, a non-transitory computer storage medium stores instructions that, when executed on a computing device of a first vehicle, cause the computing device to at least: receive a command from a host device; in response to receiving the command, store a new device secret in a memory; generate a triplet including an identifier, a certificate, and a public key using the new device secret; and send the triplet to a second vehicle, wherein the second vehicle is configured to verify the identity of the first vehicle using the triplet.

[0539] In one embodiment, storing the new device secret in the memory includes replacing a previously stored device secret with the new device secret, and the instructions further cause the computing device to send the identifier to the host device.

[0540] In one embodiment, the identifier is a public identifier, and the first asymmetric generator generates the public identifier and the private identifier as an associated pair; and the second asymmetric generator generates the public key and the private key as an associated pair.

[0541] In one embodiment, the triple includes: receiving a message from a host device; concatenating the message with a public key to provide first data; encrypting the first data using a private identifier to provide second data; and encrypting the second data using the private key to provide a certificate.

[0542] In one embodiment, a UDS is assigned to one or more vehicles by a public or private agency (e.g., using an authoritative computing device 2305). Each agency may assign a specific UDS. authority (or UDS customer ).

[0543] For example, the authority may connect a configurator (e.g., a laptop with software) to the vehicle bus (e.g., using SOTA, OTA, etc.). By using authenticated command loading, a new device secret (UDS) is loaded as a UDS authority Stored in a register of a computing device (eg, computing device 2301). Authentication is based on a secret key injected by the manufacturer and provided to the customer using a secure infrastructure, such as described above. The freshness mechanism is implemented with a monotonic counter, as described above.

[0544] In one example, UDS authority The current UDS is replaced by using an authenticated replace command. However, replacing the UDS is not necessary. The UDS assignment process may be stored in the computing device for the initial UDS.

[0545] Each authenticated command execution is confirmed with an authenticated response from the computing device. Using UDS authority The computing device generates a triplet including a public identifier, a public certificate, and a public key. The computing device also generates a private key and a private identifier, as described above.

[0546] In one embodiment, the receiver vehicle (e.g., nearby vehicle 2311) verifies the identity of the assigned identified vehicle, as described above. In one example, the vehicle is an emergency vehicle, and no Internet or wireless connection is required to perform the verification. The emergency vehicle generates a well-known public triple {ID L1public ,ID L1 certificate,K L1public} and use KL1private key Sign all messages. The receiver vehicle signs the K of the sender vehicle. L1public Verify the signature. This provides evidence that the message came from the authorized proper sender vehicle, since only that vehicle knows K L1private key , which is K L1public Emergency vehicle credentials may be pre-installed in all such vehicles to ensure that emergency vehicle identification can be performed in the absence of an Internet or other communications connection.

[0547] In one example, the vehicle is controlled by a utility service. The Internet or other communication connection is used to communicate with the vehicle. If necessary, the receiver vehicle can verify the triple {ID L1public ,ID L1certificate ,K L1public}. All messages are marked with K L1public key Signed, and the receiver vehicle uses the transmitter vehicle's K L1public to verify the signature.

[0548] In one example, the vehicles are private vehicles in a fleet controlled by a private enterprise. Each vehicle generates a triple {ID L1public ,ID L1certificate ,K L1public}. Vehicle K L1private key All messages are signed and the receiver vehicle uses the sender vehicle’s K L1public to verify the signature.

[0549] In one embodiment, the communication between vehicles is performed by exchanging packets. Each packet has a freshness field to avoid replay attacks. Examples of communication between vehicles include information such as: stop, follow the sender vehicle, the accident occurred somewhere, data about the accident location, request for help, request for road condition information, etc.

[0550] Conclusion

[0551] Non-transitory computer storage media may be used to store instructions for firmware 104 or to store instructions for processor 143 or processing device 111. When the instructions are executed by controller 107, such as memory device 103 or computing device 603, the instructions cause controller 107 to perform any of the methods discussed above.

[0552] In this description, various functions and operations may be described as being performed or caused by computer instructions to simplify the description. However, those skilled in the art will recognize that such expressions mean that the functions are caused by one or more controllers or processors (such as microprocessors) executing computer instructions. Alternatively or in combination, the functions and operations may be implemented using dedicated circuitry, with or without software instructions (such as using an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA)). Embodiments may be implemented using hard-wired circuitry, without software instructions, or in combination with software instructions. Therefore, the technology is neither limited to any specific combination of hardware circuitry and software, nor to any specific source of instructions executed by a data processing system.

[0553] While some embodiments may be implemented on fully functional computers and computer systems, the various embodiments are capable of being distributed as various forms of computing products and can be used regardless of the specific type of machine or computer readable medium used to actually perform the distribution.

[0554] At least some aspects disclosed may be embodied at least in part in software. That is, the techniques may be implemented in a computer system or other data processing system in response to its processor (e.g., a microprocessor or microcontroller) executing sequences of instructions contained in a memory (e.g., ROM, volatile RAM, non-volatile memory, cache, or remote storage device).

[0555] The routines executed to implement the embodiments may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions (referred to as a "computer program"). A computer program generally includes one or more instructions that are placed at various times in various memories and storage devices in a computer, and when read and executed by one or more processors in a computer, causes the computer to perform operations required to execute the elements involved in various aspects.

[0556] Tangible non-transitory computer storage media can be used to store software and data, which when executed by a data processing system causes the system to perform various methods. Executable software and data can be stored in various locations, including, for example, ROM, volatile RAM, non-volatile memory and / or cache. Portions of this software and / or data can be stored in any of these storage devices. In addition, data and instructions can be obtained from a centralized server or a peer-to-peer network. Different portions of data and instructions can be obtained from different centralized servers and / or peer-to-peer networks at different times and in different communication sessions or in the same communication session. Data and instructions can be fully obtained before executing an application. Alternatively, portions of data and instructions can be dynamically obtained only when execution is required. Therefore, data and instructions do not need to be completely on machine-readable media at a specific time.

[0557] Examples of computer-readable storage media include, but are not limited to, recordable and non-recordable media (e.g., volatile and non-volatile memory devices), read-only memory (ROM), random access memory (RAM), flash memory devices, floppy disks and other removable disks, magnetic disk storage media, and optical storage media (e.g., compact disk read-only memory (CD ROM), digital versatile disk (DVD), etc.), etc. Instructions may be embodied in transitory media, such as electrical, optical, acoustical or other forms of propagated signals, such as carrier waves, infrared signals, digital signals, etc. Transient media are generally used to transmit instructions, but are not considered capable of storing instructions.

[0558] In various embodiments, hard-wired circuitry may be used in conjunction with software instructions to implement the technology. Thus, the technology is neither limited to any specific combination of hardware circuitry and software nor to any specific source for the instructions executed by the data processing system.

[0559] Although some of the figures illustrate several operations in a particular order, operations not related to order may be reordered and other operations may be combined or decomposed. Although some reorderings or other groupings are specifically mentioned, other reorderings or groupings will be apparent to one of ordinary skill in the art, and therefore no exhaustive list of alternatives is presented. Furthermore, it should be recognized that the stages may be implemented in hardware, firmware, software, or any combination thereof.

[0560] The above description and drawings are illustrative and should not be construed as limiting. Numerous specific details are described to provide a thorough understanding. However, in certain examples, well-known or conventional details are not described to avoid obscuring the description. Reference to one or an embodiment in the present disclosure is not necessarily reference to the same embodiment; and such reference means at least one.

[0561] In the foregoing description, the present disclosure has been described with reference to specific exemplary embodiments of the present disclosure. It should be understood that various modifications may be made thereto without departing from the broader spirit and scope set forth in the appended claims. Therefore, the specification and drawings should be regarded as intended to be illustrative rather than restrictive.

Claims

1. A method wherein include: receiving, by a computing device of the first vehicle, a command from a host device having authority in a traffic control system; In response to receiving the command, secretly storing the device in a memory of the first vehicle; Generating, by the computing device using the device secret, a triplet including an identifier, a certificate, and a public key, comprising: generating, by the computing device using the device secret, a first associated asymmetric encryption key pair comprising the identifier as a public identifier and a private identifier; generating, by the computing device using the device secret, a second associated asymmetric encryption key pair comprising the public key and a secret key; and generating the certificate using the private identifier, the private key, and the public key; and The triplet is sent by the computing device from the first vehicle to a second vehicle to produce an action by the second vehicle, wherein the second vehicle is configured to verify an identification of the first vehicle using the triplet and perform the action based on the identification that the first vehicle is an emergency vehicle.

2. The method of claim 1, wherein the device secret: received from the host device; or Generated by the computing device after receiving the command from the host device.

3. The method of claim 1, wherein the device is secretly associated with a predetermined state or category of the first vehicle.

4. The method of claim 1, wherein the action is at least one of: presenting an alert on a user display of the second vehicle; changing a navigation path or speed of the second vehicle; or activating a braking system of the second vehicle.

5. The method of claim 1, further comprising sending, by the computing device, the triplet to the traffic control system, wherein the traffic control system is configured to: verifying the identity of the first vehicle using the triplet; and In response to verifying the identification of the first vehicle, a state of the traffic control system is changed to allow the first vehicle to pass. The method of claim 1 , wherein the device secret replaces a previously stored device secret in the memory.

7. The method of claim 1, further comprising storing a secret key for communicating with the host device, wherein the secret key is used as an input to a message authentication code to generate the device secret.

8. The method of claim 7, wherein the command is authenticated using the secret key, the method further comprising sending, by the computing device, to the host device a confirmation that the device secret has been stored.

9. The method of claim 1, further comprising, after the second vehicle verifies the identification of the first vehicle: encrypting, by the computing device, a message using the private key; and The encrypted message is sent, by the computing device, to the second vehicle, wherein the encrypted message includes freshness.

10. The method of claim 9, wherein the message includes configuration data; the second vehicle is configured to perform the action in response to receiving the message; and the action is performed by the second vehicle in accordance with the configuration data.

11. A system, wherein the system include: a first vehicle having a first communication interface; a second vehicle having a second communication interface, wherein the first vehicle and the second vehicle are configured to exchange communications via the first communication interface and the second communication interface; and a host device, which has authority in traffic control; wherein at least one processor and a memory are configured in the first vehicle; The memory contains instructions which, when executed by the at least one processor, are configured to instruct the at least one processor to perform the following operations: Storage device secrets; Secretly generate an identifier, a certificate, and a public key and a triplet including the identifier, the certificate, and the public key using the device, wherein the identifier is a public identifier and the public key is a second public key; and in order to generate the triplet, the instructions, when executed by the at least one processor, are further configured to cause the at least one processor to perform at least the following operations: receiving a message from the host device; generating a first asymmetric encryption key pair, wherein the first asymmetric encryption key pair includes a first private key as a private identifier and a first public key as the public identifier; generating a second asymmetric encryption key pair, wherein the second asymmetric encryption key pair comprises a second private key and the second public key; concatenating the message with the second public key to provide first data; encrypting the first data using the first secret key as the secret identifier to provide second data; and encrypting the second data using the second private key to provide the certificate; and sending the credential from the first vehicle to the second vehicle to effectuate a traffic control action; and Wherein the second vehicle is configured to verify the identification of the first vehicle using the certificate and perform the action based on the identification that the first vehicle is an emergency vehicle.

12. The system of claim 11, wherein the device secret: received from the host device; or Generated by the system after receiving a command from the host device.

13. The system of claim 11, further comprising a memory storing a secret key for communicating with the host device, wherein the instructions are further configured to instruct the at least one processor to generate the device secret using the secret key as an input to a message authentication code.

14. A system according to claim 11, wherein the second vehicle is configured to perform the action in response to verifying the identification of the first vehicle, and wherein the action is at least one of: presenting an alert on a user display of the second vehicle; changing the navigation path or speed of the second vehicle; or activating a braking system of the second vehicle.

15. The system of claim 11, wherein the device is secretly associated with a predetermined state or category of the first vehicle.

16. A non-transitory computer storage medium storing instructions that, when executed on a computing device of a first vehicle, cause the computing device to at least: receiving, in the computing device configured in the first vehicle, a command from a host device authoritative in a traffic control system; In response to receiving the command, secretly storing the device in a memory of the first vehicle; generating, using the device secret, an identifier, a certificate, and a public key and a triplet including the identifier, the certificate, and the public key, wherein the identifier is a public identifier, and wherein to generate the certificate, the instructions, when executed by the computing device, are further configured to cause the computing device to at least: generating the public identifier and the private identifier as a first associated asymmetric encryption key pair; generating the public key and the private key as a second associated asymmetric encryption key pair; and generating the certificate using the private identifier, the private key, and the public key; and The triplet is sent from the first vehicle to a second vehicle to produce an action by the second vehicle, wherein the second vehicle is configured to verify an identification of the first vehicle using the triplet and perform the action based on the identification that the first vehicle is an emergency vehicle.

17. The non-transitory computer storage medium of claim 16, wherein the device secret stored in the memory replaces a previously stored device secret in the memory, and wherein the instructions further cause the computing device to send the identifier to the host device.

18. The non-transitory computer storage medium of claim 16, wherein the public key is a second public key; and wherein to generate the triplet, the instructions, when executed by the computing device, are further configured to cause the computing device to at least: receiving a message from the host device, in: The first associated asymmetric encryption key pair is generated to include a first private key as the private identifier and a first public key as the public identifier; The second associated asymmetric encryption key pair is generated to include a second private key and the second public key; concatenating the message with the second public key to provide first data; encrypting the first data using the first secret key as the secret identifier to provide second data; and The second data is encrypted using the second private key to provide the certificate.

Images