Method and system for public key infrastructure of serviceable electronic components in a vehicle

Abstract

A method for a public key infrastructure for serviceable electronic components is provided. The method includes identifying a plurality of electronic components in electronic communication with each other and determining that each of the plurality of electronic components is a trusted device from a certificate history including a plurality of signed public keys stored on the respective electronic components. The method also includes distributing a symmetric message authentication code to each of the plurality of electronic components using a Diffie-Hellman key exchange and communicating between the plurality of electronic components using the symmetric message authentication code to implement a tangible function that can be provided by the plurality of electronic components.

Description

[0001] introduction. Technical Field

[0002] This disclosure generally relates to methods and systems for public key infrastructure (PKI) for serviceable electronic components in software-defined vehicles. Background Technology

[0003] Vehicles utilize computerized hardware and software to control the operation of various systems within the vehicle. This computerized hardware may include circuit boards. Some physical components or devices are permanently attached to or soldered to circuit boards. Other devices are replaceable or can be upgraded by removing the old device and replacing it with a new one. Summary of the Invention

[0004] A method is provided for a public key infrastructure for serviceable electronic components. The method includes identifying multiple electronic components that are communicating electronically with each other, and determining that each of the multiple electronic components is a trusted device based on a certificate history including multiple signing public keys stored on the respective electronic components. The method also includes distributing symmetric keys to each of the multiple electronic components using a signed Diffie-Hellman key exchange, and using the symmetric keys to communicate between the multiple electronic components to realize tangible functions that can be provided by the multiple electronic components.

[0005] In some embodiments, establishing each of the plurality of electronic components as a trusted device based on certificate history includes creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the respective electronic component.

[0006] In some embodiments, creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the respective electronic component includes the final product manufacturer's self-signing of the final product manufacturer's public key, the final product manufacturer's signing of the component manufacturer's public key, and the component manufacturer's signing of the device's public key.

[0007] In some embodiments, multiple electronic components are installed in the vehicle. Communication between the multiple electronic components includes providing electronic commands to vehicle systems that affect vehicle operation.

[0008] In some embodiments, the vehicle's systems include one of a navigation system, a braking system, a system for controlling an electric motor, and an infotainment system.

[0009] In some embodiments, establishing each of the plurality of electronic components as a trusted device includes using proof among the plurality of electronic components.

[0010] In some embodiments, the authenticity of the device is determined by proving that each of the electronic components interrogates the other to provide a response signed by a private key, and by verifying the validity of the response.

[0011] In some embodiments, each of the plurality of electronic components is connected to a central computing unit providing electronic communication. A first component of the plurality of electronic components is established as trustworthy by being soldered to the central computing unit. A second component of the plurality of electronic components is challenged using proof including the first component, and the second component is defined as trustworthy based on the response from the second component.

[0012] In some embodiments, distributing a symmetric key to each of the plurality of electronic components using a Diffie-Hellman key exchange includes establishing a shared secret among the plurality of electronic components.

[0013] In some embodiments, establishing a shared secret includes iteratively signing the public keys of the plurality of electronic components with the private keys of the plurality of electronic components to create a signing public key, and defining the shared secret based on the signing public key of the plurality of electronic components.

[0014] According to an alternative embodiment, a method is provided for a public key infrastructure for serviceable electronic components in a vehicle. The method includes identifying a plurality of electronic components that communicate electronically with each other, and establishing that each of the plurality of electronic components is a trusted device based on a certificate history including a plurality of signing public keys stored on the respective electronic components. The method also includes distributing symmetric message authentication codes to each of the plurality of electronic components using a Diffie-Hellman key exchange, and communicating between the plurality of electronic components using the symmetric message authentication codes to realize tangible functions in a vehicle system affecting vehicle operation, which can be provided by the plurality of electronic components.

[0015] In some embodiments, establishing each of the plurality of electronic components as a trusted device based on certificate history includes creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the respective electronic component.

[0016] In some embodiments, creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the respective electronic component includes the final product manufacturer's self-signing of the final product manufacturer's public key, the final product manufacturer's signing of the component manufacturer's public key, and the component manufacturer's signing of the device's public key.

[0017] In some embodiments, establishing that each of the plurality of electronic components is a trusted device includes using proof among the plurality of electronic components.

[0018] In some embodiments, the authenticity of the device is determined by proving that each of the electronic components interrogates the other to provide a response signed by a private key, and by verifying the validity of the response.

[0019] In some embodiments, each of the plurality of electronic components is connected to a central computing unit providing electronic communication. A first component of the plurality of electronic components is established as trustworthy by being soldered to the central computing unit. A second component of the plurality of electronic components is challenged using proof including the first component, and the second component is defined as trustworthy based on the response from the second component.

[0020] In some embodiments, distributing a symmetric message authentication code to each of the plurality of electronic components using Diffie-Hellman key exchange includes establishing a shared secret among the plurality of electronic components.

[0021] In some embodiments, establishing a shared secret includes iteratively signing the public keys of the plurality of electronic components with the private keys of the plurality of electronic components to create a signing public key, and defining a shared secret based on the signing public keys of the plurality of electronic components.

[0022] According to an alternative embodiment, a system is provided for a public key infrastructure for servicing electronic components. The system includes multiple electronic components that communicate electronically with each other. Each of the multiple electronic components is identified as a trusted device based on a certificate history including multiple signing public keys. Each of the multiple electronic components is configured to distribute symmetric message authentication codes using the Diffie-Hellman method.

[0023] This disclosure provides the following technical solutions: 1. A method for a public key infrastructure for servicing electronic components, the method comprising: Identify multiple electronic components that communicate with each other electronically; Based on the certificate history, including multiple signature public keys stored on the respective electronic components, each of the multiple electronic components is established as a trusted device; The symmetric key is distributed to each of the plurality of electronic components using a signed Diffie-Hellman key exchange; and The symmetric key is used to communicate among the plurality of electronic components to realize the tangible functions that can be provided by the plurality of electronic components.

[0024] 2. The method according to technical solution 1, wherein establishing each of the plurality of electronic components as a trusted device based on the certificate history includes creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the respective electronic component.

[0025] 3. The method according to technical solution 2, wherein creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the corresponding electronic component includes: The final product manufacturer self-signs its public key; The final product manufacturer signs the component manufacturer's public key; and The component manufacturer signs the device with the public key.

[0026] 4. The method according to technical solution 1, wherein the plurality of electronic components are installed in the vehicle; and The communication between the plurality of electronic components includes providing electronic commands to the vehicle system that affect vehicle operation.

[0027] 5. The method according to technical solution 4, wherein the vehicle system includes one of a navigation system, a braking system, a system for controlling an electric motor, and an infotainment system.

[0028] 6. The method according to technical solution 1, wherein establishing that each of the plurality of electronic components is a trusted device includes using proof among the plurality of electronic components.

[0029] 7. The method according to technical solution 6, wherein the proof includes mutual questioning of each of the electronic components to provide a response signed by a private key, and the authenticity of the device is determined based on the validity of the response.

[0030] 8. The method according to technical solution 6, wherein each of the plurality of electronic components is connected to a central computing unit providing electronic communication; Among these, the first component of the plurality of electronic components is established as reliable by being soldered to the central computing unit; and Specifically, the proof includes a first component among the plurality of electronic components that interrogates a second component among the plurality of electronic components, and the second component is defined as trustworthy based on the response from the second component.

[0031] 9. The method according to technical solution 1, wherein distributing a symmetric key to each of the plurality of electronic components using Diffie-Hellman key exchange includes establishing a shared secret among the plurality of electronic components.

[0032] 10. The method according to technical solution 9, wherein establishing a shared secret includes: Iteratively sign the public key of the plurality of electronic components using their private keys to create a signing public key; and The shared secret is defined based on the public keys of the signatures of the multiple electronic components.

[0033] 11. A method for a public key infrastructure for serviceable electronic components in a vehicle, the method comprising: Identify multiple electronic components that communicate with each other electronically; Based on the certificate history, including multiple signature public keys stored on the respective electronic components, each of the multiple electronic components is established as a trusted device; The Diffie-Hellman key exchange is used to distribute a symmetric message authentication code to each of the plurality of electronic components; and Communication is achieved between multiple electronic components with symmetric message authentication codes to realize tangible functions that can be provided by the multiple electronic components in a vehicle system that affects vehicle operation.

[0034] 12. The method according to technical solution 11, wherein establishing each of the plurality of electronic components as a trusted device based on the certificate history includes creating and storing on the respective electronic component a final product manufacturer's signature public key, a component manufacturer's signature public key, and the electronic component's signature public key.

[0035] 13. The method according to technical solution 12, wherein creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the corresponding electronic component includes: The final product manufacturer self-signs its public key; The final product manufacturer signs the component manufacturer's public key; and The component manufacturer signs the device with a public key.

[0036] 14. The method according to technical solution 11, wherein establishing that each of the plurality of electronic components is a trusted device includes using proof among the plurality of electronic components.

[0037] 15. The method according to technical solution 14, wherein the proof includes mutual questioning of each of the electronic components to provide a response signed by a private key, and the authenticity of the device is determined based on the validity of the response.

[0038] 16. The method according to technical solution 14, wherein each of the plurality of electronic components is connected to a central computing unit providing electronic communication; and Among them, a first component of the plurality of electronic components is established as reliable by being soldered to the central computing unit; and Specifically, the proof includes a first component among the plurality of electronic components that interrogates a second component among the plurality of electronic components, and the second component is defined as trustworthy based on the response from the second component.

[0039] 17. The method according to technical solution 11, wherein distributing a symmetric message authentication code to each of the plurality of electronic components using Diffie-Hellman key exchange includes establishing a shared secret among the plurality of electronic components.

[0040] 18. The method according to technical solution 17, wherein establishing a shared secret includes: The private keys of the plurality of electronic components are used to iteratively sign the public keys of the plurality of electronic components to create a signing public key; and The shared secret is defined based on the public keys of the signatures of the multiple electronic components.

[0041] 19. A system for a public key infrastructure for servicing electronic components, the system comprising: Multiple electronic components that communicate with each other electronically; Each of the plurality of electronic components has been identified as a trusted device based on a certificate history including multiple signing public keys; and Each of the plurality of electronic components is configured to distribute symmetric message authentication codes using the Diffie-Hellman method.

[0042] The foregoing features and advantages, as well as other features and advantages, of this disclosure will become apparent when taken in conjunction with the accompanying drawings from the following detailed description of the best mode for carrying out this disclosure. Attached Figure Description

[0043] Figure 1 A CCU including a power management MCU is schematically shown according to the present disclosure, the power management MCU being configured to verify the authenticity of electronic components attached to the CCU; Figure 2 This is a flowchart illustrating an exemplary method for establishing a certificate for an ECU according to this disclosure, including signatures from the component manufacturer and the end product manufacturer; Figure 3This is a flowchart illustrating an exemplary method for establishing a certificate for an ECU according to the present disclosure, the certificate including a device ID key created within the ECU and including a signature performed by a component manufacturer; Figure 4 This is a flowchart illustrating an exemplary method for establishing a certificate for an ECU according to the present disclosure, including a device ID key created within the ECU and a device ID key stored locally within the device without a signature. Figure 5 An exemplary device including a vehicle according to the present disclosure is illustrated schematically. The vehicle includes a CCU and a plurality of other vehicle systems controllable by the CCU. Figure 6 An exemplary SoC unit, inserted into slot B of the CCU according to the present disclosure, is schematically shown. Figure 7A and 7B This is a flowchart illustrating a symmetric MAC key distribution method using Diffie-Hellman key exchange according to this disclosure; and Figure 8 This is a flowchart illustrating an exemplary key distribution process according to the present disclosure for creating, signing, and distributing device keys for local use by a local group of electronic devices. Detailed Implementation

[0044] A system and method are provided, including hardware configured to authenticate field-replaceable electronic modules. In one embodiment, authentication enables the screening of counterfeit and malicious devices to be used with plug-in components on a central control unit (CCU). The disclosed system and method utilize an asymmetric key architecture to support localized cryptographic services, including component authentication, Message Authentication Code (MAC) key distribution, and secure non-volatile fast memory (NVMe) cell unlocking for CCU plug-in modules. Plug-in devices or devices with configurable software can be required to authenticate, and based on the authentication, can be established as one of multiple trusted devices. Once multiple trusted devices are identified, a symmetric MAC key can be distributed, and the multiple trusted devices can communicate securely. Incompatible devices or devices whose authentication process fails can be isolated from communicating with the multiple trusted devices. Debugging plug-in or configurable devices does not require an internet connection or specialized service tools. Two key features of the disclosed system and method include the absence of an internet connection, meaning that units can be field-replaced, added, or upgraded; and the electronic unit can automatically configure itself by authenticating legitimate components through authentication and then locally distributing symmetric keys to trusted devices using Elliptic Curve Diffie-Hellman (ECDHE). The device uses a symmetric key to generate a message authentication code to ensure that the message has not been modified by a man-in-the-middle (MitM) device during transmission.

[0045] Public and private keys can be numbers, such as a string of hexadecimal digits. The operation of signing a public key with a private key can be a simple mathematical operation, where the private key operates on the public key through mathematical operations to generate a new number. The public key along with the signature can be described as a certificate. The signing operation may be a one-way function, where it is difficult to reverse the function to determine the private key even if you know the public key number. In this way, by operating on the public key with the private key, it is very certain that the device is acting on the public key. Signatures can be used to verify encrypted messages from the device. A message can also be signed with the private key, and then the message and the accompanying signature can be verified with the public key. The private and public keys are linked together, but the public key is not easily reversed or otherwise manipulated to reveal information about the private key. The signature, the message, and the accompanying signature, along with the contextual material of the signature, can be stored separately within the device and used to establish a certificate history or chain of trust back to the device's root of trust, for example, establishing a root of trust back to the manufacturer or auditing authority.

[0046] According to the disclosed method, the cryptographic key is locally generated, provided, or distributed. A serviceable module or electronic control unit (ECU) is provided, which generates or stores a unique device secret unknown to the component manufacturer or end-product manufacturer. In one embodiment, the ECU may be a vehicle component used in a CCU installed in a vehicle. In this case, the end-product manufacturer is the vehicle manufacturer, and the component manufacturer may be a company that supplies the specific ECU to the manufacturer. The ECU generates and stores a device identity public / private key pair based on the unique device secret. The device identity public key is presented as, for example, signed by the component manufacturer. The ECU stores the signed device identity key or ECU certificate.

[0047] In some embodiments, the ECU certificate may be presented to the end product manufacturer for signing. The ECU may then store the signed ECU certificate or the end product manufacturer's root certificate. In another embodiment, the component manufacturer's signature is a final certificate stored by the ECU, and the ECU certificate is provided to the end product manufacturer for storage in case it needs to be revoked later. Based on the stored certificate (the end product manufacturer's root certificate or the final ECU certificate), the ECU generates a proof public / private key pair using a unique device secret. The ECU uses the device identity private key pair to prove the public key signature. The ECU generates a Diffie-Hellman (DH) public / private key pair and signs it using the device identity private key pair with the DH public key.

[0048] In one embodiment, an ECU including a DH public / private key pair can be used in conjunction with a CCU configured for use with plug-in modules or components. In a process that can be described as utilizing PKI to debug the CCU, the CCU can leverage a trusted component, such as a component soldered to a circuit board, to challenge or request proof from a plug-in or interchangeable component. This proof process enables verification that the ECU and one or more other devices are trusted and authorized for use by the end-product manufacturer. The ECU can utilize the CCU to distribute a signed DH key to establish a shared secret between the ECU and another trusted component attached to the CCU. The use of the signed DH key and the proof process enables the restriction of components' access to Peripheral Component Interconnect Fast (PCIe) connections and the CCU's access to receive power and data transmissions based on a certificate revocation list.

[0049] Using PKI, no internet connection or specialized service tools are needed to provide or distribute plug-in module keys to support localized cryptographic services such as proofs, secure unlocking, and message authentication. Once an authentication device is established, symmetric keys can be automatically established across these trusted devices. The automatic configuration of symmetric keys using asymmetric proofs and key exchange eliminates the significant infrastructure we currently deploy to do this. This allows for the repair or upgrade of components in areas where internet service may be unavailable, infrastructure is compromised, or services are otherwise inoperable. This enables superior parts distribution, serviceability, and scalability.

[0050] The disclosed systems and methods utilize asymmetric keys. Symmetric keys with accompanying infrastructure can also be used alternatively for similar processes. For example, symmetric MAC keys and Message Authentication Calibration Tables (MACTs) can be used to authenticate inter-processor messages. However, this requires significant infrastructure support and coordination, which the disclosed systems and methods do not.

[0051] MACs include Galois Message Authentication Code (GMAC), Hash-based Message Authentication Code (HMAC), Cryptographic Message Authentication Code (CMAC), Poly1305, or other similar MAC types. MACT is used to coordinate different symmetric keys across different ECUs. For example, if there are devices A, B, and C, A and B will share a single symmetric key, A and C will share a different symmetric key, and B and C will share a third symmetric key.

[0052] PCIe data management differs from Ethernet data management because PCIe primarily concerns reading or writing memory blocks. For PCIe, information is not the primary consideration. In this case, the MAC (Mandatory Access Message) can be calculated from the data block, and unverified data can be transmitted between devices along with the MAC using messages defined by the PCIe vendor. At the other end, the receiving device can calculate the MAC of the received data and compare it to the expected MAC received from the sender.

[0053] A private device identifier key, or private ID key, can be used to sign local keys for purposes such as authentication, encryption, remote access, shared access, ownership, MAC, and storage. The device ID public key is used to verify that the local key was signed by a valid private key. Each security operation can have a unique key. Unique keys allow manufacturers to decide whether to incorporate certain features into a system or vehicle. One example includes enabling secure NVMe unit unlocking. This selective feature enabling is useful for over-the-air (OTA) feature additions or remote upgrades.

[0054] Secure NVMe unlocking is a useful benefit derived from the disclosed systems and methods, and is made easier to implement by them. An NVMe unit is a solid-state data drive. Without unlocking information sent to the unit, the NVMe unit is useless (if taken). The disclosed systems and methods enable devices within a vehicle or other applications to sign encrypted unlocking requests to the NVMe unit with a private key. According to the disclosed systems and methods, each of the requesting device and the NVMe unit may have established trust and distributed symmetric keys, making it easy to generate signed unlocking requests. Without a signed unlocking request, the NVMe unit will securely retain and not release the information stored thereon. According to one embodiment, after establishing a shared secret using Elliptic Curve Diffie-Hellman Key Exchange (ECDHE), the requesting device can send an authenticated encrypted unlocking request to the drive. Authentication of the encrypted message can be accomplished using Advanced Encryption Standard - Galois / Counter Mode (AES-GCM) or an equivalent method. In this way, the disclosed systems and methods can use asymmetric and symmetric cryptography techniques to securely unlock NVMe drives, thereby preventing the password from being intercepted during transmission over the local communication link.

[0055] OTA (Over-The-Air) feature additions are a popular way to provide customers with the latest and newest devices or systems. For example, new features for electronic devices, such as enhanced streaming services based on improved cellular connectivity, may become available. When software and firmware code are updated to the system via wireless transmission, the behavior and characteristics of the electronic device may change dramatically. These changes may need to be verified so that the system owner can reliably know that the software or firmware changes are credible and legitimate. The disclosed systems and methods can authenticate the appropriate behavior and responses of electronic devices, and once trust is established, local keys can be generated and distributed, allowing updated devices to continue operating seamlessly with the rest of the system. Complex key distribution schemes from a central office are unnecessary because the disclosed local PKI distribution methods enable the local generation and distribution of symmetric keys.

[0056] A beneficial feature of the disclosed systems and methods is the ease of PKI distribution within a local group of electronic devices or components. Some key distribution methods involve generating and using a single set of keys throughout the device's lifecycle. If an intrusion or fraudulent device is successfully used to obtain these keys from an existing device, the system's data security is compromised. Neither past nor future data in the system remains secret. Using the disclosed systems and methods, if an intrusion or fraudulent device somehow obtains the currently used key, the key can be regenerated each time the system is powered on or reset. The exposure that an intrusion or fraudulent device might cause is limited to the current key being valid. This limitation on the exposure of future data can be described as perfect forward security.

[0057] The proof key may not be anonymous. The device ID can be detectable. Additional layers can be created to separate the device ID from the proof key, thus making it anonymous. Anonymous proof keys can be useful in certain situations.

[0058] Referring now to the accompanying drawings, in which the same reference numerals refer to the same features throughout several views. Figure 1 A CCU 10 is shown, including a power management microcontroller (MCU) 20 configured to verify the authenticity of electronic components attached to the CCU 10. The CCU 10 is shown to include a PCIe switch 30, slot A (computer host unit) 32, slot B (compute unit plug-in #1 34), slot C (compute unit plug-in #2 36), and slot D (compute unit plug-in #3 38). The CCU 10 is further shown to include NVMe units #1 40, #2 42, #3 44, and #4 46. The CCU 10 is further shown to include a connector 15, an Ethernet switching unit 22, a power tree 24, a PCIe retimer 50, a video input unit #1 60, and a video input unit #2 62.

[0059] The CCU 10 operates as a computerized unit. Slot A – Computer Main Unit 32 includes a processor, random access memory (RAM), and memory storage devices, and can provide computerized functionality, performing programming that may include an operating system. The PCIe switch 30, combined with Slot B – Compute Unit Plug-in #1 34, Slot C – Compute Unit Plug-in #2 36, and Slot D – Compute Unit Plug-in #3 38, provides scalable options, where a SoC can be installed into one of these slots. The flexibility provided by slots 34, 36, and 38 can benefit the operation of vehicles including the CCU 10 and provides versatility for vehicle owners. However, the ability to add plug-in components (such as System-on-a-Chip (SoCs)) and other computerized devices to the CCU 10 may lead to the possibility of counterfeit hardware or software connecting to the CCU 10 and operating with the vehicle. The disclosed systems and methods provide vehicle owners with the ability to utilize the versatility of slots 34, 36, and 38 while protecting the vehicle from the adverse effects of counterfeit hardware or software. The disclosed systems and methods can also be used by plug-in modules to ensure that they have been installed in a legitimate CCU 10 before allowing communication. For example, a standalone module can be plugged into a debug device and subsequently modified via PCIe, I2C, SPI, or other communication links.

[0060] Some components of the CCU 10 can be serviced by the end user or ordinary consumer. Other components of the CCU 10 may require knowledge of the hardware and software involved, and may require service technicians with computerized equipment to perform the service. Other components of the CCU 10 may be installed at the original assembly location and may be unserviceable without replacing the CCU 10 with a new unit. Table 1 shows... Figure 1 Exemplary serviceability of the CCU 10 and its components.

[0061] Table 1: Figure 1 Serviceability of components.

[0062] To enable encrypted communication between electronic devices or components that are part of a larger electronic device, public / private key pairs can be securely distributed to each device, utilizing physical security to ensure the key pairs are securely installed on the device. This security-intensive and device-specific process is intensive. The disclosed systems and methods make this physically secure and intensive process unnecessary. Trusted key pairs are created using digital signatures, and these trusted, signed key pairs can be securely distributed electronically to devices. Digital signatures include a certificate chain, which enables auditing or review of signed key pairs, thereby thwarting attempts to forge or spoof key pairs. Figure 8 This is a flowchart illustrating an exemplary key distribution process 600 for creating, signing, and distributing device keys for local use within a local group of electronic devices and for use between local groups. The key distribution process 600 includes a first section 602 through which device identity is established. According to... Figure 8 The exemplary key distribution process 600, in which a fully debugged device includes three signed public keys (also referred to as three certificates or credentials), is stored on the device. Initially, at device startup, the device includes a microprocessor that can generate its private key (which is never shared but is used to sign information throughout the device's lifecycle) and an unsigned public key. In another embodiment, the private key may be injected into the device during a secure process. According to operations 610, 620, and 630, the device's unsigned public key is signed by the component manufacturer. Furthermore, the component manufacturer's public key, signed by the final product manufacturer, is transmitted and stored within the device. Additionally, the final product manufacturer's self-signed public key is transmitted and stored within the device. By storing these three signed public keys on the device, the device can make these signed public keys available to any requesting device, establishing a chain of trust or certificate history for the device, which can be the root of trust for the system. Key distribution process 600 also includes a second part 604, in which local encryption services are completed.

[0063] Part 602 includes operation 610, in which, in sub-operation 612, the final product manufacturer creates a key pair for the device, including the final product manufacturer's private key and the manufacturer's public key, and in sub-operation 614, the final product manufacturer self-signs the key pair. Part 602 also includes operation 620, which is optional, based on whether an individual component manufacturer creates the device. In sub-operation 622, the component manufacturer creates a key pair for the device, and in sub-operation 624, the component manufacturer's public key of the key pair is signed by the manufacturer's private key. Part 602 also includes operation 630, in which, in sub-operation 632, a key pair is created for the device, and in sub-operation 634, the device ID public key of the key pair is signed by the component manufacturer's private key. In embodiments that do not utilize operation 620, the device ID public key may instead be signed by the manufacturer's private key. Part 602 of the key distribution process 600 enables trust to be granted from one trusted source to the next. The final product manufacturer trusts its own remote server device storing its private key. The final product manufacturer grants trust to the component manufacturer by signing with the component manufacturer's public key. The component manufacturer trusts its stored private key and uses that private key to sign, thereby granting trust to the device's public key. In this way, in section 602, a device identity can be established, enabling the device to utilize a secure key that includes a history of signed certificates to establish trust within the device. For example, in one embodiment, when the final product manufacturer manufactures the device, the device will not have a three-signed public key, but rather a two-signed public key.

[0064] Once a device is debugged with three signed public keys or certificates, it can locally create and establish symmetric DH keys without obtaining permission or authorization from a remote manufacturer. The root of trust established within the device is sufficient to enable the device to manage local certificates for local cryptographic services. The second part, 604, of the key distribution process 600 includes providing local cryptographic services locally across a group of devices based on the trust granted in the first part, 602. In operation 640, proof can be used to establish trust among a group of local devices. In sub-operation 642, devices can challenge each other, for example, upon startup, reset, or other defined events, and in sub-operation 644, devices can utilize asymmetric key pairs to create a signature digest in one device (the challenge and measurement values ​​from the challenged device are processed by a hash function and then signed by the device's private key), and check that signature digest in the signature digest of the second device. In this way, trust can be established among a group of electronic devices.

[0065] In operation 650, once trust has been established in operation 640, in sub-operation 652, a Diffie-Hellman process can be used to distribute symmetric MAC keys, which can be used for encryption, authentication, authenticated encryption, or authenticated encryption of associated data. In sub-operation 654, these distributed symmetric MAC keys can be signed with a device ID private key to establish trust in the MAC keys, which can then be used in secure communication between multiple trusted devices.

[0066] Part 2, 604, is useful because the trust granted in each of the multiple devices can be used to establish the multiple trusted devices and distribute security keys among them. While some methods require communication with a remote server to establish trust, downloading a list of revoked device certificates or a certificate revocation list, and incurring delays associated with requiring remote device registration, the key distribution process 600 allows trust to be initially granted to a device, and that trust can then be used locally to establish multiple trusted devices, enabling encrypted communication between the multiple trusted devices without remote intervention.

[0067] Figure 2This is a flowchart illustrating an exemplary method 100 for establishing a certificate for an ECU, including signatures from a component manufacturer and an end-product manufacturer. Vertical line 102 represents method steps taken locally within the ECU. Vertical line 104 represents method steps taken by the component manufacturer. Vertical line 106 represents method steps taken by the end-product manufacturer. In an embodiment where the end product is a vehicle, vertical line 106 represents method steps taken by the vehicle manufacturer. In step 110, the component manufacturer generates an ECU public and private key pair for the device. In step 110, the component manufacturer may additionally sign the ECU public key to create an ECU certificate. In step 120, the method transfers from the component manufacturer to the end-product manufacturer, where the component manufacturer provides the ECU's public key to the end-product manufacturer. In step 130, the end-product manufacturer signs the ECU's public key or ECU certificate to create a root certificate for the end-product manufacturer for the device. In step 140, the end-product manufacturer stores the signed ECU public key as the ECU certificate. In step 150, the method transfers from the end-product manufacturer to the component manufacturer, where the end-product manufacturer provides the end-product manufacturer's root certificate to the component manufacturer. In step 160, the method shifts from the component manufacturer to the device, where the component manufacturer sends the ECU certificate and the root certificate of the end product manufacturer to the device. In step 170, the ECU certificate and the root certificate of the end product manufacturer are transmitted to the device. In step 180, the certificates are stored on the device. In this way, when the device connects to the CCU, a key useful for the operational authentication process can be provided to the ECU to authenticate the device. The same or similar process can be used to provide keys to SOCs, Ethernet control switches, NVMe units, and other authenticable electronic devices.

[0068] Figure 3This is a flowchart illustrating an exemplary method 200 for establishing a certificate for an ECU, including a device ID key created within the ECU and a signature by a component manufacturer. Vertical line 202 represents method steps taken locally within the ECU. Vertical line 204 represents method steps taken by the component manufacturer. Vertical line 206 represents method steps taken by the end-product manufacturer. In an embodiment where the end product is a vehicle, vertical line 206 represents method steps taken by the vehicle manufacturer. In step 210, the device generates or loads a unique device secret (UDS). In step 215, the device uses the UDS to generate a device ID public and private key pair. In step 220, the device stores the ID key pair locally. In step 225, the method transfers to the component manufacturer, who provides the device ID public key to the component manufacturer. In step 230, the component manufacturer signs the device ID public key with the component manufacturer's ECU private key, thereby creating an ECU certificate or device ID certificate. In step 235, the component manufacturer stores the device ID certificate. In step 240, the component manufacturer provides the device ID certificate to the end-product manufacturer. In step 245, the component manufacturer provides the device ID certificate to the device. In step 250, the final product manufacturer stores the device ID certificate. In step 255, the device stores the device ID certificate. In this way, the ECU can possess a key useful for the operational authentication process to authenticate the device when it is connected to the CCU; the key is signed by the component manufacturer. The same or similar process can be used to provide keys to SoCs, Ethernet control switches, NVMe units, and other authenticable electronic devices.

[0069] Figure 4 This is a flowchart illustrating an exemplary method 300 for establishing a certificate for an ECU, including a device ID key created within the ECU and an unsigned device ID key stored locally within the device. Vertical line 302 represents method steps taken locally within the ECU. Vertical line 304 represents method steps taken by the component manufacturer. Vertical line 306 represents method steps taken by the end-product manufacturer. In an embodiment where the end product is a vehicle, vertical line 306 represents method steps taken by the vehicle manufacturer. In step 310, the device generates or loads a UDS and uses the UDS to generate a device ID public and private key pair. In step 315, the device locally signs the device ID public key with the device ID private key, which creates a device ID certificate. In step 320, the device stores the device ID public and private key pair and the device ID certificate. In this way, when the device connects to the CCU, the ECU can possess a key that can be used to operate the authentication process to authenticate the device; the key is created and signed locally by the device. The same or similar process can be used to provide keys to SoCs, Ethernet control switches, NVMe units, and other authenticable electronic devices.

[0070] Figure 5An exemplary device 400 comprising a vehicle is schematically shown, the vehicle including a CCU 10 and several other vehicle systems controllable by the CCU 10. The device 400 includes the CCU 10, a motor 410 configured to provide output torque via an output component 412, a braking system 420, a wireless communication receiver and antenna 430, and a rear-seat entertainment system 440. The disclosed systems and methods enable the CCU 10 to provide computerized control of the illustrated vehicle systems, having a degree of confidence that the modules within the CCU 10 and their software are certified, and will provide operation of the device 400 according to parameters intended by the manufacturer.

[0071] Figure 6 An exemplary SoC unit 90 is schematically shown in slot B—Compute Unit Plug-in #1 34, which is inserted into CCU 10. SoC unit 90 includes a PCIe connector configured to insert into a mating connection on slot B—Compute Unit Plug-in #1 34, which is connected to board 11.

[0072] Diffie-Hellman key exchange is a process by which multiple trusted devices can create a shared secret held by all trusted devices. This shared secret enables secure communication between the trusted devices and prevents unauthorized or compromised devices from communicating. Figure 7A and 7B This is a flowchart illustrating a method 500 for symmetric MAC key distribution using Diffie-Hellman key exchange. Method 500 is provided as an exemplary, relatively simple version of multiple means for creating a shared secret. Method 500 is exemplary, and other versions such as the elliptic curve Diffie-Hellman method can be utilized to increase security and / or ease of use. Figure 7A and 7BA single method 500 is illustrated, where connectors 501, 503, and 505 represent consecutive vertical lines spanning the diagram. Vertical line 502 represents the operation performed by device A. Vertical line 504 represents the operation performed by device B. Vertical line 506 represents the operation performed by device C. Devices A, B, and C represent multiple trusted devices that have mutually verified each other's authenticity through a verification process by possessing private keys with valid certificate chains, and the authenticity of each device and the software therein. In steps 510, 512, and 514, secure and trusted private and public keys are established in each of devices A, B, and C, respectively. For example, steps 510, 512, and 514 are accomplished via the first part 602 of the key distribution process 600. In step 516, device A signs its public key with its private key. This signed public key is a digital output that represents the public key being raised to the power of the private key. In step 518, the signed key is transmitted to device B. In step 520, device B verifies the signing key from device A. In step 522, device B signs the signing key of device A by raising the signing key of device A to a power of device B's private key. This creates a public key of device A signed by both device A and device B, or a double-signed private key. In step 524, the double-signed key is provided to device C. In step 526, device C verifies the double-signed key. In step 528, device C signs the double-signed key by raising the double-signed key to a power of device C's private key. This third signature creates a shared secret among devices A, B, and C.

[0073] In step 530, device C signs its public key with its private key. In step 532, this public key of device C's signature is transmitted to device B. In step 534, the public key of device C's signature is transmitted again, this time to device A. In step 536, device A verifies device C's signature key. In step 538, device B verifies device C's signature key. In step 540, device B signs device C's signature key with device B's private key, thereby creating a second double-signature key. In step 542, device B transmits the second double-signature key to device A. In step 544, device A verifies the second double-signature key. In step 546, device A signs the second double-signature key with device A's private key, thereby creating a second shared secret among devices A, B, and C.

[0074] In step 548, device A can determine the public key of device C, which is signed by the private key of device C. This determined signing key of device C is then signed by the private key of device A to create a third double-signature key. In step 550, the third double-signature key is transmitted to device B. In step 552, device B verifies the third double-signature key. In step 554, device B signs the third double-signature key, thereby creating a third shared secret among device A, device B, and device C.

[0075] Method 500 is useful for establishing a shared secret among three devices, device A, device B, and device C. These are exemplary devices, and the process can be established for multiple devices among a plurality of trusted devices. The shared secret can then be used to establish encrypted communication between the multiple trusted devices, ensuring that no counterfeit, malicious, or fraudulent device can communicate with the multiple trusted devices.

[0076] The disclosed electronic components and combinations thereof can be configured to perform a wide variety of tangible functions. In several non-limiting examples, the electronic components can control access to and content of entertainment systems, operation of wireless communications, provision of navigation commands to units or devices, monitoring of sensors and processing of sensor information, operation and speed of electric motors, and various functions within a vehicle, such as navigation, propulsion, braking, environmental systems, wipers, headlights, and infotainment. The disclosed systems and methods provide enhanced security for these systems to prevent unintentional, malicious, unauthorized, fraudulent, or other inappropriate operation of these systems and their tangible outputs.

[0077] While the best mode of implementing this disclosure has been described in detail, those skilled in the art will recognize various alternative designs and embodiments for implementing this disclosure within the scope of the appended claims.

Claims

1. A method for a public key infrastructure for servicing electronic components, the method comprising: Identify multiple electronic components that communicate electronically with each other, wherein the multiple electronic components include at least a first electronic component, a second electronic component, and a third electronic component; Based on the certificate history, including multiple signature public keys stored on the respective electronic components, each of the multiple electronic components is established as a trusted device; A symmetric key is distributed to each of the plurality of electronic components using a signed Diffie-Hellman key exchange; and The symmetric key is used to communicate between the plurality of electronic components to realize the tangible functions that can be provided by the plurality of electronic components; The distribution of a symmetric key to each of the plurality of electronic components using Diffie-Hellman key exchange includes establishing a shared secret among the plurality of electronic components. Establishing a shared secret includes: Iteratively sign the public key of the plurality of electronic components using their private keys to create a signing public key; and The shared secret is defined based on the public keys of the signatures of the aforementioned electronic components; Establishing a shared secret also includes: The first electronic component signs its public key with its private key to create a first signing public key, and then transmits the first signing public key to the second electronic component; After verifying the first signing public key, the second electronic component signs the first signing public key with its private key to create a second signing public key, and then transmits the second signing public key to the third electronic component. After verifying the second signing public key, the third electronic component signs the second signing public key using its private key to create a third signing public key; and The shared secret is defined based on at least one of the first, second, and third signature public keys.

2. The method according to claim 1, wherein, Establishing each of the plurality of electronic components as a trusted device based on the certificate history includes creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the respective electronic component.

3. The method according to claim 2, wherein, Creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the corresponding electronic components includes: The final product manufacturer self-signs its public key; The final product manufacturer signs the component manufacturer's public key; and The component manufacturer signs the device with the public key.

4. The method according to claim 1, wherein, The multiple electronic components are installed in the vehicle; and The communication between the plurality of electronic components includes providing electronic commands to the vehicle system that affect vehicle operation.

5. The method according to claim 4, wherein, The vehicle system includes one of the following: a navigation system, a braking system, a system for controlling the electric motor, and an infotainment system.

6. The method according to claim 1, wherein, Establishing that each of the plurality of electronic components is a trusted device includes using proof among the plurality of electronic components.

7. The method according to claim 6, wherein, The authenticity of the device is determined by interrogating each of the electronic components to provide a response signed by a private key, and by verifying the validity of the response.

8. The method according to claim 6, wherein, Each of the multiple electronic components is connected to a central computing unit that provides electronic communication; Among these, the first component of the plurality of electronic components is established as reliable by being soldered to the central computing unit; and Specifically, the proof includes a first component among the plurality of electronic components that interrogates a second component among the plurality of electronic components, and the second component is defined as trustworthy based on the response from the second component.

9. A method for a public key infrastructure for serviceable electronic components in a vehicle, the method comprising: Identify multiple electronic components that communicate electronically with each other, wherein the multiple electronic components include at least a first electronic component, a second electronic component, and a third electronic component; Based on the certificate history, including multiple signature public keys stored on the respective electronic components, each of the multiple electronic components is established as a trusted device; A symmetric message authentication code is distributed to each of the plurality of electronic components using a Diffie-Hellman key exchange. and Communication is achieved between multiple electronic components with symmetric message authentication codes to realize tangible functions that can be provided by the multiple electronic components in a vehicle system that affects vehicle operation. The process of distributing a symmetric message authentication code to each of the plurality of electronic components using Diffie-Hellman key exchange includes establishing a shared secret among the plurality of electronic components. Establishing a shared secret includes: The private keys of the plurality of electronic components are used to iteratively sign the public keys of the plurality of electronic components to create a signing public key; and The shared secret is defined based on the public keys of the signatures of the aforementioned electronic components; Establishing a shared secret also includes: The first electronic component signs its public key with its private key to create a first signing public key, and then transmits the first signing public key to the second electronic component; After verifying the first signing public key, the second electronic component signs the first signing public key with its private key to create a second signing public key, and then transmits the second signing public key to the third electronic component. After verifying the second signing public key, the third electronic component signs the second signing public key using its private key to create a third signing public key; and The shared secret is defined based on at least one of the first, second, and third signature public keys.

10. The method according to claim 9, wherein, Establishing each of the plurality of electronic components as a trusted device based on the certificate history includes creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the respective electronic component.

11. The method according to claim 10, wherein, Creating and storing the final product manufacturer's signature public key, the component manufacturer's signature public key, and the electronic component's signature public key on the corresponding electronic components includes: The final product manufacturer self-signs its public key; The final product manufacturer signs the component manufacturer's public key; and The component manufacturer signs the device with a public key.

12. The method according to claim 9, wherein, Establishing that each of the plurality of electronic components is a trusted device includes using proof among the plurality of electronic components.

13. The method according to claim 12, wherein, The authenticity of the device is determined by interrogating each of the electronic components to provide a response signed by a private key, and by verifying the validity of the response.

14. The method according to claim 12, wherein, Each of the plurality of electronic components is connected to a central computing unit that provides electronic communication; and Among them, a first component of the plurality of electronic components is established as reliable by being soldered to the central computing unit; and Specifically, the proof includes a first component among the plurality of electronic components that interrogates a second component among the plurality of electronic components, and the second component is defined as trustworthy based on the response from the second component.

15. A system for a public key infrastructure for servicing electronic components, the system comprising: Multiple electronic components that communicate with each other electronically, wherein the multiple electronic components include at least a first electronic component, a second electronic component, and a third electronic component; Each of the plurality of electronic components has been identified as a trusted device based on a certificate history including multiple signing public keys; and Each of the plurality of electronic components is configured to distribute a symmetric message authentication code using the Diffie-Hellman method; The method of distributing a symmetric message authentication code to each of the plurality of electronic components using the Diffie-Hellman method includes establishing a shared secret among the plurality of electronic components. Establishing a shared secret includes: The private keys of the plurality of electronic components are used to iteratively sign the public keys of the plurality of electronic components to create a signing public key; and The shared secret is defined based on the public keys of the signatures of the aforementioned electronic components; Establishing a shared secret also includes: The first electronic component signs its public key with its private key to create a first signing public key, and then transmits the first signing public key to the second electronic component; After verifying the first signing public key, the second electronic component signs the first signing public key with its private key to create a second signing public key, and then transmits the second signing public key to the third electronic component. After verifying the second signing public key, the third electronic component signs the second signing public key using its private key to create a third signing public key; and The shared secret is defined based on at least one of the first, second, and third signature public keys.

Images