阅读说明：本技术 车载电子控制单元之间的安全通信 (Secure communication between onboard electronic control units ) 是由 C·比法尔 S·塞加尔 于 2019-01-25 设计创作，主要内容包括：本发明的各方面提出了用于使得车辆中的电子控制单元(ECU)之间能够进行安全通信的系统、方法和设备。所述系统可以包括来自车辆中的多个ECU的第一ECU和第二ECU。所述第一ECU通过执行以下操作使得所述多个ECU之间能够进行安全通信：向第二ECU提供用于认证与第三ECU交换的消息的认证数据,向第三ECU提供安全密钥集,以使得所述第三ECU能够与第二ECU安全地交换消息。第二ECU从第三ECU接收安全消息,所述安全消息是利用来自提供给第三ECU的安全密钥集中的安全密钥来加密签名的,并且第二ECU通过将所述认证数据与认证信号进行比较来认证安全消息。(Aspects of the present invention propose systems, methods and apparatus for enabling secure communication between Electronic Control Units (ECUs) in a vehicle. The system may include a first ECU and a second ECU from a plurality of ECUs in a vehicle. The first ECU enables secure communication among the plurality of ECUs by performing: providing authentication data to the second ECU for authenticating messages exchanged with the third ECU, providing a set of security keys to the third ECU to enable the third ECU to securely exchange messages with the second ECU. The second ECU receives a secure message from the third ECU, the secure message being cryptographically signed with a secure key from a set of secure keys provided to the third ECU, and the second ECU authenticates the secure message by comparing the authentication data to an authentication signal.)

1. A system, comprising:

a first electronic control unit of a plurality of electronic control units in a vehicle, the first electronic control unit enabling secure communication between the plurality of electronic control units; and

a second electronic control unit of the plurality of electronic control units, the second electronic control unit in communication with the first electronic control unit;

the first electronic control unit enables secure communication between the plurality of electronic control units by performing the following operations:

providing a security key set to a third electronic control unit of the plurality of electronic control units to enable the third electronic control unit to securely exchange messages with the second electronic control unit; and

providing authentication data to the second electronic control unit for authenticating messages exchanged between the second electronic control unit and the third electronic control unit, the authentication data comprising one or more attributes regarding communication with the third electronic control unit based on the set of security keys; and

the second electronic control unit further performs the following operations:

receiving a secure message from a third electronic control unit, the secure message cryptographically signed with a secure key from a set of secure keys provided to the third electronic control unit; and

the secure message is authenticated by comparing the authentication data to the authentication signal.

2. The system of claim 1, wherein:

the one or more attributes include a time attribute that defines an expiration time of a security key;

the authentication signal comprises a clock signal held by a second electronic control unit;

wherein the expiration time is compared to the clock signal for comparing authentication data to an authentication signal.

3. The system of claim 2, wherein the second electronic control unit maintains the clock signal based on one or more updates provided by a computer system in communication with the first electronic control unit.

4. The system of claim 2 or claim 3, wherein the operations for enabling secure communication between a plurality of electronic control units further comprise:

requesting updated authentication data from a computer system of a security system for updating authentication data, the updated authentication data including an update to an expiration time of a security key; and

the second electronic control unit is provided with the updated authentication data of the security key.

5. The system of any of claims 1 to 4, wherein:

the one or more attributes include a time attribute defining a time window for sending a message cryptographically signed with a secure key;

the authentication signal comprises a clock signal; and

the second electronic control unit authenticates the safety message by comparing the time window with the clock signal.

6. The system of any of claims 1 to 5, wherein:

the one or more attributes include a message count attribute that defines a maximum message count for a security key; and

the second electronic control unit authenticates the secure message by performing the following operations:

when a secure message is received from the third electronic control unit, incrementing a message counter value, the message counter value corresponding to the message cryptographically signed with the secure key; and

the message counter value is compared to the maximum message count.

7. The system of any of claims 1 to 6, wherein:

the one or more attributes include a component attribute specifying an identifier of a component of the vehicle with which the third electronic control unit is permitted to communicate; and

the second electronic control unit authenticates the safety message by verifying that the safety message relates to operation of a component of the vehicle with which the third electronic control unit is permitted to communicate.

8. The system of any of claims 1 to 7, wherein:

the one or more attributes include an operational attribute specifying an operation that a third electronic control unit is permitted to perform; and

the second electronic control unit authenticates the safety message by verifying that the safety message corresponds to an operation that the third electronic control unit is allowed to perform.

9. The system of any one of claims 1 to 8, wherein the secure message is cryptographically signed with a combination of the authentication signal and the security key.

10. The system of any one of claims 1 to 9, wherein the second electronic control unit further transmits a signal to the first electronic control unit in response to failing to successfully authenticate the security message received from the third electronic control unit, the signal indicating that the security key authentication failed with respect to the third electronic control unit.

11. The system of claim 10, wherein the first electronic control unit restricts operation of the vehicle in response to receiving a signal from the second electronic control unit.

12. The system of claim 11, wherein the first electronic control unit limits operation of the vehicle by placing the third electronic control unit in a limited mode of operation that limits the third electronic control unit from performing one or more operations.

13. The system of claim 10, wherein the first electronic control unit further:

in response to receiving the message from the second electronic control unit, a new security key for the third electronic control unit is requested from the computer system providing the security service.

14. The system of any one of claims 1 to 13, wherein the first electronic control unit further:

receiving a plurality of digital certificates from a computer system providing security services, each digital certificate corresponding to one of a plurality of electronic control units;

sending a request for firmware data for configuring firmware on each of a plurality of electronic control units to a server computer providing a service to transfer firmware, the request including a plurality of digital certificates;

receiving firmware data of each of the plurality of electronic control units from the server computer; and

using the firmware data, firmware is configured on each of the plurality of electronic control units.

15. The system of claim 14, wherein:

each electronic control unit of the plurality of electronic control units initially includes a portion of the program code, each electronic control unit incapable of fully operating with the portion of the program code;

the firmware, once configured on each of the plurality of electronic control units, causes each electronic control unit to have program code that enables the electronic control unit to fully operate.

16. A system, comprising:

one or more processors of a first electronic control unit of a plurality of electronic control units in a vehicle; and

a storage device of the first electronic control unit, the storage device storing:

authentication data for authenticating messages exchanged between a first electronic control unit and a second electronic control unit of the plurality of electronic control units, the authentication data comprising one or more attributes regarding communication with the second electronic control unit based on a security key set provided to the second electronic control unit; and

a set of instructions that, when executed by one or more processors, cause a first electronic control unit to:

receiving a secure message from the second electronic control unit, the secure message cryptographically signed with a secure key from a set of secure keys provided to the second electronic control unit; and

the security message is authenticated by comparing the authentication data with an authentication signal maintained by the first electronic control unit.

17. The system of claim 16, wherein the one or more attributes comprise at least one of:

a first time attribute defining an expiration time of the security key,

a second time attribute defining a time window for sending a message cryptographically signed with a security key,

a message count attribute that defines a maximum message count for the security key;

a component attribute specifying an identifier of a component of the vehicle with which the second electronic control unit is allowed to communicate;

an operation attribute specifying an operation that the second electronic control unit is permitted to perform.

18. The system of claim 16 or claim 17, further comprising:

a third electronic control unit of the plurality of electronic control units in the vehicle, the third electronic control unit enabling secure communication between the plurality of electronic control units by performing:

providing a secure key set to a second electronic control unit of the plurality of electronic control units to enable the second electronic control unit to securely exchange messages with the first electronic control unit; and

the first electronic control unit is provided with authentication data for authenticating messages exchanged between the first electronic control unit and the second electronic control unit.

19. The system of claim 18, wherein:

the set of instructions causing the first electronic control unit to send a message to the third electronic control unit in response to failing to successfully authenticate the security message received from the second electronic control unit, the message indicating that the security key authentication failed with respect to the second electronic control unit; and

the third electronic control unit further performs the following operations:

limiting operation of the vehicle in response to receiving the message from the first electronic control unit; and

in response to receiving the message from the first electronic control unit, a new security key for the second electronic control unit is requested from the computer system providing the security service.

20. A method, comprising:

storing, at a first electronic control unit of a plurality of electronic control units in a vehicle, authentication data comprising one or more attributes relating to communication with a second electronic control unit based on a set of security keys provided to the second electronic control unit;

receiving, by the first electronic control unit, a secure message from the second electronic control unit, the secure message cryptographically signed with a secure key from a set of secure keys provided to the second electronic control unit;

authenticating, by the first electronic control unit, the security message by comparing the authentication data with an authentication signal maintained by the first electronic control unit.

21. A storage medium storing processor-executable instructions that, when executed by at least one processor, cause the at least one processor to perform the method of claim 20.

22. A carrier medium carrying processor-executable instructions that, when executed by at least one processor, cause the at least one processor to carry out the method of claim 20.

23. A method of enabling secure communication between a plurality of electronic control units in a vehicle using a first electronic control unit of the plurality of electronic control units, the method comprising:

providing a security key set to a third electronic control unit of the plurality of electronic control units to enable the third electronic control unit to securely exchange messages with the second electronic control unit; and

providing authentication data to the second electronic control unit for authenticating messages exchanged between the second electronic control unit and a third electronic control unit, the authentication data comprising one or more attributes regarding communication with the third electronic control unit based on a set of security keys; and

the second electronic control unit further performs the following operations:

receiving a secure message from a third electronic control unit, the secure message cryptographically signed with a secure key from a set of secure keys provided to the third electronic control unit; and

the secure message is authenticated by comparing the authentication data to the authentication signal.

24. A storage medium storing processor-executable instructions that, when executed by a first electronic control unit of a plurality of electronic control units in a vehicle, enable the first electronic control unit to conduct secure communications between the plurality of electronic control units by performing the method of claim 23.

25. A carrier medium carrying processor-executable instructions that, when executed by a first electronic control unit of a plurality of electronic control units in a vehicle, enable the first electronic control unit to conduct secure communications between the plurality of electronic control units by performing the method of claim 23.

26. A storage medium storing processor-executable instructions that, when executed by a first electronic control unit of a plurality of electronic control units in a vehicle, cause the first electronic control unit to be configured as the first electronic control unit in the system of any one of claims 1 to 15.

27. A carrier medium carrying processor-executable instructions that, when executed by a first electronic control unit of a plurality of electronic control units in a vehicle, cause the first electronic control unit to be configured as the first electronic control unit in the system of any one of claims 1 to 15.

Technical Field

The subject matter disclosed herein relates to safety in vehicle computing systems including Electronic Control Units (ECUs). Exemplary embodiments provide techniques for secure communications (e.g., communications between ECUs) in a vehicle computing system.

Background

Vehicles such as automobiles, ships, trains, and airplanes are typically composed of discrete components assembled on an assembly line. These components may include a computer system consisting of several Electronic Control Units (ECUs). The ECUs may be embedded systems, each of which controls one or more electrical systems or subsystems in the vehicle. The increase in the number of ECUs in turn increases the vulnerability of the vehicle computing system to safety. This vulnerability may lead to a network threat that causes rogue or malicious control. Currently, all ECU safe connections and automatic connections may be compromised.

Drawings

The various drawings in the figures depict only exemplary embodiments of the subject matter and are not to be considered limiting of its scope.

Fig. 1 is an architecture diagram illustrating a security system having an architecture for automatically and securely incorporating a vehicle Electronic Control Unit (ECU) into a trusted area, according to some embodiments.

Fig. 2 is an architecture diagram illustrating a security system having an architecture for automatically and securely incorporating a vehicle ECU into a trusted area, according to some alternative embodiments.

Fig. 3 is an architecture diagram illustrating a security system having an architecture for automatically and securely incorporating a vehicle ECU into a trusted area, according to some alternative embodiments.

Fig. 4 is an interaction diagram illustrating interactions between components of a safety system when performing a method for enabling secure communications between multiple ECUs of a vehicle, according to some embodiments.

Fig. 5 is an interaction diagram illustrating interactions between components of a safety system when performing a method for securely configuring firmware on multiple ECUs of a vehicle, according to some embodiments.

Fig. 6 is an interaction diagram illustrating interactions between components of a safety system when performing a method for securely configuring firmware on a replacement ECU, according to some embodiments.

Fig. 7 is an interaction diagram illustrating interactions between components of a safety system when performing a method for securely configuring firmware on a replacement ECU, according to some alternative embodiments.

Fig. 8 is a system diagram showing functional components of an ECU according to some embodiments.

Fig. 9 is a conceptual diagram illustrating interactions between components of a safety system when performing a method for securely exchanging messages between ECUs of a vehicle, according to some embodiments.

Fig. 10 and 11 are interaction diagrams illustrating interactions between multiple ECUs of a vehicle when performing a method for securely exchanging messages, according to some embodiments.

Fig. 12 is an interface diagram that illustrates aspects of a graphical interface provided by a security system, according to some embodiments.

Fig. 13 is a diagrammatic representation of a machine in the example form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.

Detailed Description

Reference will now be made in detail to specific exemplary embodiments for carrying out the subject matter. Examples of these specific embodiments are illustrated in the accompanying drawings and specific details are set forth in the following description in order to provide a thorough understanding of the subject matter. It will be understood that these examples are not intended to limit the scope of the claims to the illustrated embodiments. On the contrary, they are intended to cover such alternatives, modifications, and equivalents as may be included within the scope of the invention.

Aspects of the present invention relate to a security architecture for developing a system that enables secure communication within a vehicle between a plurality of components including an Electronic Control Unit (ECU). The secure architecture enables secure Firmware Over-The-Air (FOTA) updates, secure Map Over-The-Air (MOTA) updates, secure communications between ECUs, secure vehicle-to-vehicle and vehicle-to-infrastructure (collectively "V2X") communications, and legitimate ECU replacement.

During vehicle assembly, detailed information of the vehicle ECU may or may not be known. For example, only the type of ECU (e.g., Gateway Control Unit (GCU), Door Control Unit (DCU), Telematics Control Unit (TCU), etc.) may be known. In another case, the precise ECU entering the vehicle may be known. However, neither at or after deployment, the security architecture described herein requires the Original Equipment Manufacturer (OEM) to have accurate knowledge of the details of the network components that need to be protected. In this way, the secure architecture makes it possible to protect the ECU with or without prior detailed knowledge of the ECU. If multiple ECUs are connected to a master ECU (e.g., a central gateway), the multiple ECUs can be identified and then the ECUs can be introduced into a trusted and secured network in an automated fashion using this identity information.

Other aspects of the present invention propose techniques (e.g., systems, methods, or devices) for enabling secure communication between ECUs in a vehicle. The system may include at least a first ECU and a second ECU in a vehicle. The first ECU may communicatively connect a plurality of ECUs to enable secure communication between the ECUs. Upon communicatively connecting the ECUs, the first ECU may provide the second ECU with authentication data for authenticating messages exchanged with the third ECU, and the first ECU may provide the third ECU with a set of security keys to enable the third ECU to exchange messages with the second ECU. The second ECU may receive a secure message from the third ECU, the secure message being cryptographically signed with a security key from a set of security keys provided to the third ECU. The second ECU may authenticate the secure message by comparing the authentication data to an authentication signal.

As an example, the authentication data may include a maximum message count that limits the number of messages that the third ECU may send to the second ECU, and the authentication signal may include a message counter value corresponding to the number of messages sent by the third ECU to the second ECU. In this example, upon receiving a message from the third ECU, the second ECU may increment the message counter value and compare the message counter value to the maximum message count. The second ECU successfully authenticates the message from the third ECU if the message counter value is less than or equal to the maximum message count. If the message counter value is greater than the maximum message count, the second ECU is unable to successfully authenticate messages received from the third ECU.

As an example, the authentication data may comprise an expiration time of a security key for cryptographically signing a message from the third ECU, and the authentication signal may comprise a clock signal. In the example, the second ECU compares the expiration time to the clock signal upon receiving the message from the third ECU. If the expiration time has not elapsed, the second ECU successfully authenticates the message from the third ECU. If the expiration time has elapsed, the second ECU cannot successfully authenticate the message received from the third ECU.

In the event that the second ECU is unable to successfully authenticate a message received from the third ECU, such as in the example discussed above, the second ECU may send a signal to the first ECU indicating that the security key authentication with respect to the third ECU failed. In response, the first ECU may restrict operation of the vehicle. For example, the first ECU may place the third ECU in a limited operation mode that limits the third ECU from performing one or more operations. Additionally or alternatively, the first ECU may request updated authentication data from a security service provided by the security subsystem for updating the authentication data of the second ECU. Additionally or alternatively, the first ECU may request a new security key for the third ECU.

Security architecture

Referring to fig. 1, an exemplary security system 100 is shown, according to some embodiments. The example security system 100 is configured to automatically securely incorporate vehicle ECUs into a trusted area to enable the ECUs to securely communicate with each other. To avoid obscuring the subject matter with unnecessary detail, various functional components (e.g., services and engines) that are not germane to conveying an understanding of the subject matter have been omitted from fig. 1. However, those skilled in the art will readily recognize that the security system 100 may support various additional functional components to facilitate additional functionality not specifically described herein.

As will be appreciated by those skilled in the relevant computer arts, the functional components shown in fig. 1 may represent one or more components, such as hardware components, firmware components or components having a set of executable instructions and corresponding hardware (e.g., memory and processor) for implementing the instructions. Furthermore, it should be understood that although the functional components of FIG. 1 are discussed in the singular, in other embodiments, multiple instances of one or more components may be employed.

As shown in FIG. 1, a security system 100 includes a vehicle system 102 of an assembled vehicle in communication with a network-accessible security subsystem 104, the network-accessible security subsystem 104 providing security services over a network 106. One or more portions of network 106 may be an ad hoc network, an intranet, an extranet, a Virtual Private Network (VPN), a Local Area Network (LAN), a Wireless LAN (WLAN), a Wide Area Network (WAN), a Wireless WAN (WWAN), a Metropolitan Area Network (MAN), the Internet, a portion of the Public Switched Telephone Network (PSTN), a Plain Old Telephone Service (POTS) network, a cellular telephone network, a wireless network,

a network, another type of network, or a combination of two or more such networks. For example, the network 106 or a portion of the network 106 may include a wireless or cellular network, and any of the components shown in fig. 1 connected to the network 106 may be connected to the network 106 via a Code Division Multiple Access (CDMA) connection, a global system for mobile communications (GSM) connection, or another type of cellular or wireless connection. In this example, the connection to the network 106 may implement any of a number of types of data transmission technology, such as single carrier radio transmission technology (1xRTT), evolution-data optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, enhanced data rates for GSM evolution (EDGE) technology, third generation partnership project (3GPP) including 3G, fourth generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standards, other standards defined by various standards-establishing organizations, other remote protocols, or other data transmission technologies.

As shown, the security subsystem 104 includes one or more computer systems, such as a front-end server 110 and a back-end server 112. The vehicle system 102 includes a plurality of control units, for example, an assembly ECU. For example, the vehicle system 102 may include one or more ECUs, such as a master ECU116 (e.g., "gateway"), a TCU 118, a powertrain ECU, a transmission ECU, a suspension ECU, a Brake Control Unit (BCU), an ADA ECU, a cluster ECU, and a brake ECU. The master ECU116 is configured to communicate with each ECU of the vehicle system 102 in the event of a safe environment. The communication between the main ECU116 and the secure subsystem 104 over the network is facilitated by program code 108 (e.g., a software application comprising a set of machine-readable instructions that configure an execution machine to perform certain functions), which program code 108 may be embedded in or executed by, for example, a back-end server 112, a main ECU116, or a computer device (e.g., a security tool). An on-board diagnostics (OBD) system 120 may facilitate further communication with the vehicle system 102, which provides outlet, electrical, and protocol standards.

The TCU 118 controls the tracking of the vehicle and is configured to provide an external interface for mobile communications (e.g., GSM, GPRS, Wi-Fi, WiMAX, or LTE) that provides the tracked values to a centralized Geographic Information System (GIS) database server (not shown) via the network 106. In some embodiments, the TCU 118 may also enable the main ECU116 to communicate directly with the secure subsystem 104 without the need for the program code 108.

As shown, the master ECU116 is also in communication with an in-vehicle infotainment (IVI) system 122, the in-vehicle infotainment (IVI) system 122 configured to present audio and video content to occupants of the vehicle. The IVI system 122 is also configured to communicate with one or more external systems (e.g., external content providing systems) over the network 106 via a communication connection (e.g., Wi-Fi, USB, or ethernet) with one or more external devices.

In the case of the security system 100, the symmetric key is stored in a secure memory component or other secure element of each ECU (e.g., in a process running on the ECU or an element that is not accessible by any process running outside the ECU) during the manufacturing process of each ECU. Further, during the production of each ECU, the backend root certificate is stored in the non-modifiable storage device of each ECU. Near the end of the vehicle assembly process, all assembly ECUs have only a portion of the program code embedded that provides minimal functionality, but only a portion of the program code does not enable vehicle operation. For example, the portion of program code may enable the ECU to communicate a unique identifier (e.g., a public key certificate) to the master ECU 116. The unique identifier of each ECU may be stored in a non-modifiable storage mechanism of the respective ECU during production. The portion of program code may also facilitate other secondary communications between the ECUs to assist in authenticating the ECUs.

According to some embodiments, a device or system executing program code 108 may be connected to the vehicle's main ECU116 during final assembly by the vehicle manufacturer. A device or system executing program code 108 may be connected to master ECU116 in one of at least two ways: 1) trusted communications may be established between the program code 108 and the master ECU116 based on shared secrets (e.g., symmetric and asymmetric keys); alternatively, 2) a secure connection cannot be established, but this process can be carried out at the end of vehicle assembly in a fully controlled and secure environment provided by the automotive OEM.

Once connected to the master ECU116 (e.g., via the OBD system 120), the program code 108 obtains from the master ECU116 a list of unique identifiers (e.g., public key certificates) for all assembled ECUs in the vehicle. With prior knowledge of the precise ECU in the vehicle, the program code 108 makes a comparison between the generated list and the known list (e.g., checklist) to verify the legitimacy of the assembled ECU. The known list may be retrieved, for example, by program code 108 from back-end server 112. In another example, at least a portion of the known list may be provided by a manufacturer of each ECU.

Once the ECUs have been authenticated, the program code 108 communicatively connects all of the ECUs of the vehicle system 102 in a manner that enables secure communications between the ECUs. The program code 108 may issue commands to the master ECU116 that cause the master ECU116 to communicatively connect the ECUs to enable secure communications between the ECUs. Upon receiving the command, the master ECU116 provides each ECU with a secure key set (e.g., encryption key) that connects the ECUs by enabling the ECUs to securely exchange messages with other ECUs. The master ECU116 also provides each ECU with authentication data for authenticating messages received from other ECUs. In some embodiments, the back end server 112 generates security keys for all ECUs and provides them to the master ECU116 through the program code 108. In some embodiments, the master ECU116 may generate a security key pair for each ECU, or each individual ECU may generate its own security key pair. According to these embodiments, the public key of each ECU is provided to the backend server 112 using a unique identifier embedded in each ECU. The security keys may be generated and provided using one of many known techniques. For example, the secure key may be a "key" generated using a known symmetric algorithm, or may be a "public key" generated using a known asymmetric algorithm.

Regarding the connection of the ECUs, according to embodiments, all the ECUs may be connected to each other, each ECU may be connected to the main ECU116 individually, or some ECUs may be connected to each other while other ECUs are connected only to the main ECU 116. To implement such a communication scheme, any one ECU may be provided with a plurality of security keys. Finally, the security key provided to each ECU enables communication with other ECUs, and thus the security key indicates which other ECUs any given ECU enables communication with. In this way, each channel between two ECUs can be protected with a unique key.

Once provided with the security key, the ECUs may securely exchange information with each other. Depending on the implementation, this information may be included in the message encrypted or cryptographically signed with the respective provided security key. According to an embodiment, when exchanging information, the receiving ECU checks whether the signature is a known signature or whether the ECU has a key that enables it to encrypt a session negotiated between the ECUs.

After establishing the secure in-vehicle communication link, the program code 108 then connects the master ECU116 to the back-end server 112, and the back-end server 112 provides the master ECU116 with a digital certificate (e.g., a public key certificate) for each ECU. More specifically, the backend server 112 provides the master ECU116 with an intermediate certificate signed with a backend root certificate to describe a chain of trust certificates. The ECU may utilize these digital certificates to accept new firmware that completes the program code and makes the vehicle fully operational, such as through a FOTA platform or service. This ensures that the vehicle's network is safe before it can operate. Each digital certificate signed with the backend root certificate or any certificate in the backend trust chain is stored in the respective ECU.

When one of the ECUs is replaced by an Original Equipment Manufacturer (OEM), a dealer, or an after market, a secure connection is established between the host ECU116 and the program code 108. Program code 108 establishes a secure connection with secure subsystem 104. The security subsystem 104 authenticates the program code 108 and provides the digital certificate through the back-end server 112. The program code 108 identifies a unique identifier of the replacement ECU, which the program code 108 or back-end server 112 uses to verify the authenticity of the replacement ECU, and the program code 108 communicates the certificate to the replacement ECU using the secure connection. The firmware update is then sent through the FOTA service to complete the program code on the replacement ECU and make the replacement ECU operational.

When an ECU determines that another ECU has been compromised (e.g., due to the lack of a key), the ECU may report such information to the master ECU116, any other ECUs, or components capable of communicating with the secure subsystem 204. The master ECU116 may be designed to determine what actions to take to resolve or resolve a damaged or potentially unsafe ECU. For example, while not limiting the safety mechanisms (e.g., braking systems) of the vehicle, the master ECU116 may place the vehicle in a "safe" mode in which vehicle engine operation is limited. For example, the "safe" mode may limit the vehicle to operating at a threshold of Revolutions Per Minute (RPM) or Miles Per Hour (MPH). As another example, the "safe" mode may enable the vehicle to travel a limited distance (e.g., 100 miles) in the normal mode before being completely shut down. Once the master ECU116 can be connected to the security subsystem 104, the master ECU116 can provide a report of the damaged ECU to the back end server 112.

According to some embodiments, the security system 100 may implement technology and embedded universal integrated circuit card (eUICC) based Subscriber Identity Module (SIM) infrastructure to act as a root of trust for hardware (RoT) to implement secure networks and manage security between vehicle ECUs using the LTE/GSMA/global platform framework. The security system 100 may utilize the embedded RoT of the ECU and external security elements. The RoT or secure element may be stored in embedded pre-shared keys that are securely and privately stored in a non-modifiable storage mechanism during component production. The ECU RoT or external secure element may store a back-end Certificate Authority (CA) certificate and an ECU unique identifier, as well as other data, in a non-modifiable storage mechanism during component production.

In the embodiment shown in fig. 1, the vehicle system 102 communicates with the safety subsystem 104 over the network 106 via program code 108. However, in some embodiments, the vehicle system 102 may communicate directly with the security subsystem 104 to establish a trust zone. For example, fig. 2 shows a security system 200 according to some alternative embodiments, the security system 200 configured to automatically securely incorporate a vehicle ECU into a trusted area. Similar to the safety system 100, the safety system 200 includes a vehicle system 202 and a safety subsystem 204, the vehicle system 202 including an ECU, an OBD system 220, and an IVI system 222; the security subsystem 204 includes a front-end server 210 and a back-end server 212. The ECUs of the vehicle system 202 include a main ECU 216 and a TCU 218. Each of the vehicle system 202 and the safety subsystem 204 includes the same respective components and provides the same respective functions as the vehicle system 102 and the safety subsystem 104 of the safety system 100.

Unlike the safety system 100, however, in the safety system 200, the main ECU 216 may communicate with the safety subsystem 204 via the network 206 without the need for program code. Communication between the main ECU 216 and the secure subsystem 204 may be accomplished through the TCU 218 or through a communication component embedded in the main ECU 216. In the case of the safety system 200, the master ECU 216 is configured to perform the functions of the program code 108 described above with respect to fig. 1.

Although fig. 1 and 2 illustrate a vehicle system that communicates directly or indirectly with a server-based security service over a network, in other embodiments, or the security subsystem of the security system may include a mobile hardware device (e.g., dongle) that is directly connected to the vehicle system. For example, FIG. 3 shows a security system 300 that includes a vehicle system 302 in communication with a dongle-based security subsystem 304.

Similar to the vehicle systems 102 and 202, the vehicle system 302 includes an ECU, an OBD system 320, and an IVI system 322; the ECU includes a main ECU 316 and a TCU 318. Each component of the vehicle system 302 provides the same functionality as the corresponding component in the vehicle system 102 of the security system 100.

Unlike the security subsystem 104 of the security system 100 and the security subsystem 204 of the security system 200, the security subsystem 304 contains only the dongle 312. Dongle 312 is a small mobile hardware device that includes at least a memory, a processor, and means for communicating with at least master ECU 316. In some embodiments, the dongle 312 may be or include a mobile computing device such as a smartphone.

Depending on the embodiment, the vehicle system 302 may communicate with the dongle-based security subsystem 304 with or without the OBD system 320. As shown, the dongle-based security subsystem 304 may be directly connected to the vehicle system 302, and the dongle-based security subsystem 304 may communicate directly with the master ECU 316 through this connection. Depending on the capabilities of the vehicle system 302, the connection medium may be, for example, wireless (e.g., bluetooth or Wi-Fi), wired (e.g., ethernet cable), Universal Serial Bus (USB), or a data bus.

Because the dongle-based security subsystem 304 may be directly connected to the vehicle system 302, the security system 300 may find application in situations where a network connection is not available (which typically occurs with ECU replacement). For example, prior to deployment, a separate network connection device with appropriate security measures will download time-limited credentials to authenticate dongle 312. Once the dongle 312 is authenticated, one or more digital certificates (e.g., public key certificates) and firmware for replacing ECUs may be downloaded into the memory of the dongle 312 and stored encrypted.

Once placed in the field, the dongle 312 mimics the functionality of the server-based security service described above with reference to fig. 1 and 2. For example, the dongle 312 may be connected to the vehicle system 302 and both the digital certificate and firmware may be installed to the replacement ECU. This firmware update completes the program code on the replacement ECU so that the replacement ECU is fully operational. The component list associated with the Vehicle Identification Number (VIN) of the vehicle is updated with the new component information.

In some embodiments, the firmware update provided by the dongle 312 to the replacement ECU completes the program code so that the replacement ECU is fully operational only for a limited amount of time until the vehicle can be brought into a facility where a network connection is available and further information can be provided to the replacement ECU. As such, the firmware update provided by the dongle 312 may include an expiration time and/or date.

Implementing secure communications

Fig. 4 is an interaction diagram illustrating interactions between a security subsystem (e.g., security subsystem 104), program code (e.g., program code 108) of a security system (e.g., security system 100) that provides security services, and a main ECU (e.g., main ECU 116) when executing a method 400 for enabling secure communications between ECUs of a vehicle (e.g., vehicle system 102), according to some embodiments. The method 400 may be embodied as computer-readable instructions for execution by one or more hardware components (e.g., processors).

As shown in fig. 4, the method 400 begins with the security subsystem providing a list of known ECU identifiers to program code (operation 402). Each ECU identifier is a unique number associated with the corresponding ECU. These unique identifiers may, for example, correspond to public key certificates assigned to the ECUs. A list of known ECU identifiers is received by the program code (at operation 404). Each ECU identifier included in the list of known ECU identifiers corresponds to an ECU to be included in a particular vehicle undergoing configuration (e.g., assembly process).

The program code queries the host ECU for a list of assembly ECU identifiers included in the assembly vehicle (operation 406). The master ECU then compiles an identifier from each of the assembled ECUs in the vehicle (operation 408). For example, the master ECU may perform a ping operation on each ECU to request an identifier. The unique identifier associated with each ECU is stored in a non-modifiable storage mechanism of the respective ECU. As described above, each ECU initially includes only a portion of program code that provides minimal functionality, such as the ability to communicate a unique identifier to the master ECU, but which does not render the vehicle operable.

Once the complete list is compiled, the master ECU sends a list of assembled ECUs to the program code (operation 410). Upon receiving the list of assembly ECU identifiers (at operation 412), the program code verifies the authenticity of the assembly ECU by comparing the list of known ECU identifiers to the list of assembly ECU identifiers (operation 414).

In some embodiments, once the authenticity of the assembled ECUs has been verified, the secure subsystem generates a secure key and authentication data for each assembled ECU (operation 416), and the secure subsystem provides the secure key and authentication data to the program code over a secure (e.g., encrypted) channel (operation 418). The program code then provides the secure key and authentication data of the assembled ECU to the master ECU over the secure channel (operation 420), and the master ECU receives the secure key and authentication data from the program code (operation 422).

In other embodiments, the master ECU generates the security key instead of the security subsystem generating the security key. In these embodiments, operations 416, 418, 420, and 422 may be omitted from method 400. Further, in these embodiments, the master ECU notifies the security subsystem through program code of each security key corresponding to each ECU, which the security subsystem may update its records accordingly.

Referring back to fig. 4, the program code issues a connect command to the master ECU (operation 424), which in turn communicatively connects the assembly ECUs (operation 426). The master ECU may connect the assembled ECUs by providing each ECU with a respective security key and authentication data. Once provided with the security key, the ECU may securely exchange information with the master ECU, other ECUs, or a combination of both, depending on how the security key is provided. For example, according to embodiments, all ECUs may be connected to each other, each ECU may be connected to the main ECU individually, or some ECUs may be connected to each other while other ECUs are connected only to the main ECU. To implement such a communication scheme, any one or more ECUs may be provided with a plurality of security keys. Finally, the security key provided to each ECU enables communication with other ECUs, and thus the security key indicates which other ECUs any given ECU is allowed to communicate with. When exchanging messages with another ECU, the sending ECU signs the messages with a security key associated with the communication with the other ECU. In this way, each channel between two ECUs can be protected with a unique key. Further, each ECU authenticates messages received from other ECUs using the authentication data. The authentication data includes one or more attributes regarding communication with other ECUs, for example, a time attribute, a message count attribute, an operation attribute, or a component attribute; the time attribute defines a time window or expiration time for a particular security key; the message count attribute defines a maximum message count that a particular security key can use to sign a message; the operation attribute defines a specific operation that the ECU allows to execute; component attributes define specific components within the vehicle system with which a specific ECU allows communication.

Securely configuring ECU firmware

Fig. 5 is an interaction diagram illustrating interactions between a security subsystem (e.g., security subsystem 104), program code (e.g., program code 108), and a main ECU (e.g., main ECU 116) of a security system (e.g., security system 100) in performing a method 500 for securely configuring firmware on multiple ECUs of a vehicle (e.g., vehicle system 102), according to some embodiments. Method 500 may be implemented as computer-readable instructions for execution by one or more hardware components (e.g., processors). The operations of method 500 may be performed, for example, after the operations of method 400 described above.

As shown, the method 500 begins with the main ECU providing to the program code: an indication of the security key has been provided to the ECU of the vehicle system (operation 502). In response to receiving the indication, the program code connects the main ECU with the safety subsystem (operation 504). The secure subsystem generates a digital certificate (e.g., a public key certificate) for each ECU and provides the digital certificate to the master ECU (operation 506). After receiving the digital certificate, the master ECU may request firmware data for configuring firmware on each ECU from the FOTA service using the digital certificate of each ECU (operation 508). The master ECU receives firmware data from the FOTA service (operation 510) and configures corresponding firmware on each ECU using the firmware data (operation 512). Once configured, the firmware completes the native portion of program code embedded in the ECU, making the vehicle fully operational.

Securely configuring firmware on replacement ECU

Fig. 6 is an interaction diagram illustrating interactions between a security subsystem (e.g., security subsystem 104), program code (e.g., program code 108), and a main ECU (e.g., main ECU 116) of a security system (e.g., security system 100) when executing a method 600 for securely configuring firmware on a replacement ECU, according to some embodiments. The method 600 may be embodied as computer-readable instructions for execution by one or more hardware components (e.g., processors).

As shown, the method 600 begins with the master ECU providing an indication to program code that the ECU has been replaced (operation 602). The indication may include a unique identifier (e.g., a public key) associated with the replacement ECU. Initially, the replacement ECU contains only a portion of the program code, only this portion of the code not making the vehicle operable.

In response to receiving the indication from the main ECU, the program code establishes a secure connection with the security subsystem (operation 604). After establishing the secure connection, the security subsystem verifies the authenticity of the device or system executing the program code (operation 606). The program code authenticates the replacement ECU based on the received identifier as part of the indication (operation 608).

Once the replacement ECU has been authenticated, the security subsystem generates one or more security keys for the replacement ECU from the program code and provides the one or more security keys for the replacement ECU to the master ECU (operation 610). The program code issues a connect command to the master ECU (operation 612), which in turn connects the replacement ECU with one or more other ECUs by providing one or more security keys to the replacement ECU (operation 614). Once the replacement ECU is provided with the one or more security keys, the replacement ECU may securely communicate with one or more other ECUs of the vehicle system. For example, the replacement ECU may utilize one or more security keys to sign encrypted messages exchanged with another ECU. The replacement ECU may be provided with the security key of each of the other ECUs with which the replacement ECU is authorized to communicate. In this way, each channel between the ECU and the replacement ECU can be ensured with a unique key.

Once the replacement ECU is connected to other ECUs in the vehicle system, the security subsystem generates a digital certificate (e.g., a public key certificate) for the replacement ECU and provides it to the main ECU via program code (operation 616). The master ECU116 provides the replacement ECU with a digital certificate (operation 618), which may be stored in a non-modifiable storage mechanism of the replacement ECU. The master ECU may then request firmware data from the FOTA platform or service using the digital certificate for configuring the firmware of the replacement ECU (operation 620). After receiving the firmware data from the FOTA platform or service, the master ECU configures the firmware on the replacement ECU (operation 622). Once the firmware is configured, the firmware completes the native portion of program code embedded in the replacement ECU, making the vehicle fully operational.

Securely configuring firmware on a replacement ECU using a dongle

FIG. 7 is an interaction diagram illustrating the interaction between a dongle (e.g., dongle 312) and a master ECU (e.g., master ECU 316) when performing a method 700 for securely configuring firmware on a replacement ECU, according to some embodiments. Method 700 may be implemented as computer-readable instructions for execution by one or more hardware components (e.g., processors).

As shown, the method 700 begins with the dongle acquiring a digital certificate and firmware for replacing the ECU (operation 702). The dongle may obtain the digital certificates and firmware from a server-based security service (e.g., security subsystem 104), and the dongle may access a network connection that enables it to communicate with the security service. The dongle authenticates the replacement ECU based on a unique identifier (e.g., public key) associated with the replacement ECU (operation 704). The unique identifier may be stored in a non-modifiable storage mechanism of the replacement ECU and may be provided to the dongle by the master ECU. After authenticating the replacement ECU, the dongle provides the digital certificate and firmware for the replacement ECU to the master ECU (operation 706). The dongle may also issue a connect command to the master ECU at operation 706. The connection operation may be performed using a temporary key (e.g., securely stored in the replacement ECU). This may enable a limited time to reach the plant to terminate the replacement process when the access network connection becomes available.

In response to receiving the connect command, the master ECU provides the digital certificate to the replacement ECU (operation 708) and configures firmware on the replacement ECU (operation 710). Once the firmware is configured, the firmware completes the native portion of program code embedded in the replacement ECU, making the vehicle fully operational.

Functional assembly of ECU

Fig. 8 is a system diagram showing functional components of an ECU 800 according to some embodiments. The ECU 800 is an example of the ECU shown in fig. 1-3 and discussed above with respect to fig. 4-7. The ECU 800 is shown to include a secure communication system 802, the secure communication system 802 including a receiver 804, a transmitter 806, an authentication component 808, and a memory 810. The receiver 804 can include a decryption component 812 and the transmitter 806 can include an encryption component 814.

The functional components of the secure communication system 802 enable the ECU 800 to securely exchange messages with other ECUs in the vehicle. For example, the memory 810 stores a security key 816 that enables the ECU 800 to send secure (e.g., encrypted or cryptographically signed) messages to one or more other ECUs and decrypt encrypted messages received from the other ECUs. In addition, the memory 810 also stores authentication data 818 for authenticating messages received from other ECUs. The authentication data 818 includes one or more attributes regarding communication with one or more other ECUs. The one or more attributes may include, for example, one or more of a time attribute, a message count attribute, an operation attribute, and a component attribute; the time attribute specifies an expiration time or time window for the security key; the message count attribute specifies a maximum message count for the security key; the operation attribute specifies one or more operations that the ECU is allowed to perform; the component attributes specify components of the vehicle with which the ECU is allowed to communicate. As described above, a master ECU of a vehicle system (e.g., master ECU 116) may provide a security key 816 and authentication data 818 to ECU 800.

The receiver 804 is responsible for receiving secure (e.g., encrypted or cryptographically signed) messages from other ECUs, and a decryption component 812 of the receiver 804 decrypts the encrypted messages using one of the secure keys 816 stored in the memory 810. The transmitter 806 is responsible for sending messages encrypted and/or cryptographically signed by the encryption component 814 to other ECUs using one of the security keys 816 stored in memory 810. The authentication component 808 authenticates messages received from other ECUs. The authentication component 808 may authenticate a message received from another ECU by comparing authentication data 818 for the other ECU to an authentication signal maintained by the ECU 800. Further details regarding message authentication are discussed below.

The various components of the secure communication system 802 may be configured to communicate with each other (e.g., via a bus, a shared memory, or a switch). Any one or more of the components described may be implemented using hardware alone (e.g., one or more processors of a machine) or a combination of hardware and software. For example, any component of the secure communication system 802 may physically include an arrangement of one or more processors 820 (e.g., a subset of or of one or more processors of a machine) configured to perform the operations described herein for that component. As another example, any component of the secure communications system 802 may include software, hardware, or both that configure an arrangement of one or more processors 820 (e.g., among one or more processors of a machine) to perform the operations described herein for that component. Thus, different components of the secure communication system 802 may include and configure different arrangements of the processors 820 or a single arrangement of the processors 820 at different points in time. Further, any two or more components of the secure communication system 802 may be combined into a single component, and the functionality described herein for a single component may be subdivided among multiple components. Further, according to various exemplary embodiments, components described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.

Secure communication between ECUs

Fig. 9 is a conceptual diagram illustrating interactions between components of a safety system when performing a method 900 for securely exchanging messages between ECUs of vehicle systems, according to some embodiments. Specifically, fig. 9 shows the interaction between a safety subsystem (e.g., safety subsystem 104) and four ECUs (ECU 1, ECU 2, ECU3, and ECU 4). Each of ECU1, ECU 2, ECU3, and ECU4 is an example of ECU 800. Further, the ECU1 may correspond to a master ECU (e.g., the master ECU116, 216, or 316).

As shown, at operation 902, the security subsystem provides ECU1 (e.g., master ECU 116) with a plurality of sets of security keys and associated authentication data for authenticating messages exchanged between the ECUs. The plurality of security key sets includes a first security key set corresponding to ECU 2, a second security key set corresponding to ECU3, and a third security key set corresponding to ECU 4.

In operation 904A, the ECU1 provides the first set of security keys and associated authentication data to the ECU 2. In operation 904B, the ECU1 provides the second set of security keys and associated authentication data to the ECU 3. In operation 904C, the ECU1 provides the third set of security keys and associated authentication data to the ECU 4. Each of ECU 2, ECU3, and ECU4 may store its respective set of security keys in a secure storage device (e.g., memory 810).

In this example, ECU 2 is allowed to exchange messages with ECU3, but ECU 2 is not allowed to exchange messages with ECU 4. Thus, the first set of security keys includes one or more security keys to enable the ECU 2 to securely communicate with the ECU3, and the second set of security keys includes one or more security keys to enable the ECU3 to securely communicate with the ECU 2. For example, the first set of secure keys may include a private key used by ECU 2 to encrypt and/or cryptographically sign messages and a public key that allows ECU 2 to decrypt messages signed by ECU3 (e.g., with the private key provided to ECU 3). Likewise, the second set of secure keys may include a private key for ECU3 to encrypt messages and a public key that allows ECU3 to decrypt messages cryptographically signed by ECU 2.

Furthermore, the authentication data provided to the ECU 2 enables the ECU 2 to authenticate messages from the ECU3, but not the ECU 4. The authentication data includes one or more attributes, which may include, for example, one or more of a time attribute, a message count attribute, an operation attribute, and a component attribute; the time attribute specifies an expiration time or time window for the public key; the message count attribute specifies the maximum message count of the public key; the operation attribute specifies one or more operations that the ECU3 is allowed to perform; the component attributes specify components of the vehicle with which the ECU3 is allowed to communicate.

In operation 906, the ECU3 transmits a secure message to the ECU 2, the secure message being cryptographically signed with a security key from the second set of security keys. Upon receiving the secure message, the ECU 2 successfully authenticates the secure message using the authentication data provided to the ECU 2 and stores the message in the secure storage area (operation 908). As will be discussed further below, authentication of the secure message may include comparing authentication data to an authentication signal.

At operation 910, the ECU4 sends a secure message to the ECU 2, the secure message being cryptographically signed with a security key from the third set of security keys. However, as described above, in this example, the ECU 2 and the ECU4 are not allowed to exchange messages with each other. Accordingly, as shown in operation 912, the authentication of the message received from the ECU4 fails. In response to failing to authenticate the message received from the ECU4, the ECU 2 may discard the message, and may further send a signal to the ECU1 to notify the ECU1 that the security key authentication failed.

Fig. 10 and 11 are interaction diagrams illustrating interactions between multiple ECUs of a vehicle when performing method 1000 for securely exchanging messages, according to some embodiments. More specifically, fig. 10 and 11 illustrate the interaction between ECU1, ECU 2, and ECU3 when executing method 1000. Method 1000 may be embodied as computer-readable instructions for execution by one or more hardware components (e.g., processors), such that the operations of method 1000 may be performed by ECU1, ECU 2, and ECU 3. As described above, the ECU1, the ECU 2, and the ECU3 are examples of the ECU 800. Further, the ECU1 may correspond to a master ECU (e.g., the master ECU116, 216, or 316).

As shown, method 1000 begins with ECU1 (e.g., master ECU 116) providing ECU3 with a set of security keys to enable ECU3 to exchange messages with one or more ECUs including at least ECU 2 (operation 1002). In operation 1004, the ECU3 receives the key set.

The ECU1 provides the ECU 2 with authentication data for authenticating messages exchanged with the ECU3 (operation 1006). In operation 1008, the authentication data is received by the ECU 2. The authentication data includes one or more attributes regarding communication with the ECU3 based on the security key set. The one or more attributes may include, for example, one or more of the following two time attributes, message count attribute, component attribute, and operation attribute: a time attribute defining an expiration time of the security key; a time attribute defining a time window for sending a message cryptographically signed with a security key; the message count attribute defines a maximum message count for the security key; the component attribute specifies an identifier of a component of the vehicle with which the ECU3 is allowed to communicate; the operation attribute specifies an operation that the ECU3 can perform. In some embodiments, the one or more attributes may include a first message count attribute corresponding to an authenticated message and a second message count attribute corresponding to a message that failed authentication.

The ECU3 generates a secure message that is cryptographically signed with a security key from a set of security keys (operation 1010), and the ECU3 sends the secure message to the ECU 2 (operation 1012). The ECU 2 receives a secure message from the ECU3 (operation 1014), which is cryptographically signed with a security key from a set of security keys provided to the ECU 3.

The ECU 2 authenticates the secure message received from the ECU3 using the authentication data (operation 1016). Specifically, the ECU 2 authenticates the secure message by comparing the authentication data with the authentication signal. The authentication signal may be held by the ECU 2. In some embodiments, the authentication signal may be maintained by both ECU 2 and ECU 3. According to these embodiments, the ECU3 may cryptographically sign the secure message using a combination of the secure key and the authentication signal. According to some embodiments, prior to or as part of authenticating the secure message, ECU 2 may decrypt the secure message using one or more secure keys provided to ECU 2.

In a first example, the one or more attributes comprise a time attribute defining an expiration time of the security key, and the authentication signal comprises a clock signal. In a first example, the ECU 2 verifies the secure message from the ECU3 by comparing the expiration time with the clock signal, and if the expiration time has not elapsed, the ECU 2 successfully authenticates the secure message. On the other hand, if the expiration time has elapsed, the authentication fails, and the ECU 2 may transmit a message indicating that the security key authentication with respect to the ECU3 fails to the ECU 1.

In a second example, the one or more attributes include a time attribute defining a time window within which a message signed with a secure key may be transmitted, and the authentication signal includes a clock signal. In a second example, the ECU 2 authenticates the secure message from the ECU3 by comparing the time window with the clock signal, and if the message is sent within the time window, the ECU 2 successfully authenticates the secure message. On the other hand, if the message is sent outside the time window, the authentication fails, and the ECU 2 may send a signal indicating that the security key authentication with respect to the ECU3 fails to the ECU 1. Further, in the case of the first and second examples, the ECU 2 may maintain the clock signal based on one or more clock signal updates provided by a computer system (e.g., the backend server 112) in communication with the ECU 1.

In a third example, the one or more attributes include a message count attribute that defines a maximum message count that limits the number of messages that can be signed with the security key, and the authentication signal includes a message counter value corresponding to the number of messages signed with the security key. In the third example, the ECU 2 authenticates the secure message by incrementing the message counter value after receiving the secure message from the ECU3 and comparing the message counter value with the maximum message count. If the message counter value does not exceed the maximum message count, the ECU 2 successfully authenticates the secure message. If the message counter value exceeds the maximum message count, authentication fails, and the ECU 2 may send a signal to the ECU1 indicating that security key authentication with respect to the ECU3 fails. The message counter value maintained by the ECU 2 corresponds to a message cryptographically signed with a security key of a set of security keys provided to the ECU 3. The maximum message count may correspond to a successfully authenticated message or an unsuccessfully authenticated message, and thus, separate message counter values may be maintained for successfully authenticated messages and unsuccessfully authenticated messages.

In a fourth example, the one or more attributes include component attributes that specify components of the vehicle with which the ECU3 is allowed to communicate, and the ECU 2 authenticates the safety message from the ECU3 by verifying that the safety message is related to operation of the components of the vehicle with which the ECU3 is allowed to communicate.

In the fifth example, the one or more attributes include an operation attribute specifying an operation that the ECU3 is permitted to perform, and the ECU 2 authenticates the secure message by verifying that the secure message corresponds to the operation that the ECU3 is permitted to perform.

As shown in fig. 11, in some embodiments, method 1000 may include operations 1016, 1018, 1020, 1022, 1024, 1026, 1028, 1030, and 1032. According to some embodiments, operations 1016, 1018, 1020, 1022, 1024, 1026, 1028, 1030, and 1032 may be performed after operation 1014 of ECU 2 authenticating the safety message received from ECU 3. As described above, in some cases, the ECU 2 may not successfully authenticate the secure message at operation 1014. In response to the ECU 2 failing to successfully authenticate the security message, the ECU 2 transmits a signal indicating that the security key authentication with respect to the ECU3 has failed to the ECU1 (operation 1016).

Upon receiving the signal from the ECU 2, the ECU1 restricts the operation of the vehicle (operation 1018). The ECU1 may restrict operation of the vehicle by placing one or more ECUs in the vehicle in a restricted operation mode that restricts the one or more ECUs from performing one or more operations (e.g., sending messages). For example, in response to the ECU 2 failing to successfully authenticate a safety message received from the ECU3, the ECU1 may place the ECU3 in a limited operation mode.

Further, the ECU1 causes a notification of the failure of the authentication of the ECU3 to be displayed on the display device (operation 1020). The display device may be a display device of a vehicle (e.g., an instrument panel display device) or a display device of an external computer system (e.g., a diagnostic tool) that communicates with the ECU 1. The notification may be presented within a graphical interface that provides authentication and operating status of each ECU in the vehicle. An example of such a graphical interface is shown in FIG. 12 and discussed below.

In response to receiving the signal from the ECU 2, the ECU1 may also request updated authentication data from the secure subsystem (operation 1022). For example, the updated authentication data may include an updated expiration time of the security key. The ECU1 provides the updated authentication data to the ECU 2 (operation 1024), which is received by the ECU 2 in operation 1026.

In some embodiments, at operation 1028, the ECU1 may additionally request a new security key for the ECU3 to replace the security key that resulted in the failed authentication. In operation 1030, the ECU1 provides the new security key to the ECU3, and in operation 1032, the ECU3 receives the new security key.

Graphic interface (I)

Fig. 12 is an interface diagram illustrating aspects of a graphical interface 1200 provided by a security system (e.g., security system 100, 200, or 300) according to some embodiments. As shown, the graphical interface 1200 includes a list of ECUs in the vehicle and the authentication and operating status of each ECU. Graphical interface 1200 may display a notification of authentication failure. For example, in fig. 12, a notification of authentication failure of "ECU 4" and a notification of "ECU 4" being in the limited operation mode are presented.

Computer system

Fig. 13 illustrates a schematic representation of a machine 1300 in the form of a computer system upon which a set of instructions, for causing the machine 1300 to perform any one or more of the methodologies discussed herein, may be executed, according to an exemplary embodiment. In particular, fig. 13 shows a schematic representation of a machine 1300 in the example form of a computer system in which instructions 1316 (e.g., software, programs, applications, applets, applications, or other executable code) for causing the machine 1300 to perform any one or more of the methodologies discussed herein may be executed. For example, the machine 1300 may correspond to the front-end servers 110 and 210, the back-end servers 112 and 212, the OBD systems 120, 220 and 320, the IVI systems 122, 222 and 322, the dongle 312, the ECU 800, and any of the examples above. Further, the instructions 1316 may cause the machine 1300 to perform any of the methods 400, 500, 600, 700, 900, or 1000. The instructions 1316 transform the general purpose, unprogrammed machine 1300 into a specific machine 1300 programmed to perform the functions described and illustrated herein. In alternative embodiments, the machine 1300 operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 1300 may operate in the capacity of a server machine or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine 1300 may include, but is not limited to, a server computer, a client computer, a Personal Computer (PC), a tablet computer, laptop computer, netbook, smart phone, mobile device, network router, network switch, network bridge, or any machine capable of executing the instructions 1316 in turn or in other manners that specify actions to be taken by the machine 1300. Further, while only a single machine 1300 is illustrated, the term "machine" shall also be taken to include a collection of machines 1300 that individually or jointly execute the instructions 1316 to perform any one or more of the methodologies discussed herein.

The machine 1300 may include a processor 1310, a memory 1330, and I/O components 1350, which processor 1310, memory 1330, and I/O components 1350 may be configured to communicate with one another, for example, via a bus 1302. In an exemplary embodiment, processor 1310 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Radio Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 1312 and processor 1314, which may execute instructions 1316. The term "processor" is intended to include multicore processor 1310, which may include two or more independent processors (sometimes referred to as "cores") that may execute instructions concurrently. Although fig. 13 illustrates multiple processors, the machine 1300 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

Memory 1330 may include main memory 1332, static memory 1334, and storage unit 1336, each of which may be accessed by processor 1310, e.g., via bus 1302. Main memory 1332, static memory 1334, and storage unit 1336 store instructions 1316 that implement any one or more of the methodologies or functions described herein. During execution of the instructions 1316 by the machine 1300, the instructions 1316 may also reside, completely or partially, within the main memory 1332, within the static memory 1334, within the storage unit 1336, within at least one of the processors 1310 (e.g., within a processor's cache memory), or any suitable combination thereof.

I/O components 1350 may include various components to receive input, provide output, generate output, send information, exchange information, capture measurements, and so forth. The specific I/O components 1350 included in a particular machine 1300 will depend on the type of machine. For example, a portable machine such as a mobile phone is likely to include a touch input device or other such input mechanism, while a headless server machine is likely not to include such a touch input device. It will be understood that the I/O components 1350 may include many other components not shown in FIG. 13. The I/O components 1350 are grouped by function for purposes of simplifying the following discussion only, and the grouping is not limiting. In various exemplary embodiments, the I/O components 1350 may include output components 1352 and input components 1354. The output component 1352 may include: visual components (e.g., a display such as a Plasma Display Panel (PDP), a Light Emitting Diode (LED) display, a Liquid Crystal Display (LCD), a projector or a Cathode Ray Tube (CRT)), acoustic components (e.g., speakers), other signal generators, and so forth. The input component 1354 may include: an alphanumeric input component (e.g., a keyboard, a touch screen configured to receive alphanumeric input, an electro-optical keyboard, or other alphanumeric input component), a point-based input component (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or other pointing tool), a tactile input component (e.g., a physical button, a touch screen that provides a location and/or force of a touch or touch gesture, or other tactile input component), an audio input component (e.g., a microphone), and so forth.

Communication may be accomplished using a variety of techniques. I/O components 1350 may include a communications component 1364, communications component 1364 operable to connect machine 1300 to network 1380 or device 1370 via connection 1382 and connection 1372, respectively. For example, the communications component 1364 may include a network interface component or another suitable device to interface with the network 1380. In further examples, the communications component 1364 may include a wired communications component, a wireless communications component, a cellular communications component, a near field communications component, a bluetooth communications component, and a Wi-Fi communications component. The device 1370 may be another machine or any of a variety of peripheral devices (e.g., a peripheral device connected via a Universal Serial Bus (USB)).

Executable instructions and machine storage media

Various memories (e.g., 1330, 1332, 1334 and/or processors 1310's memory) and/or storage unit 1336 may store one or more sets of instructions and data structures (e.g., software) implemented or utilized by any one or more of the methods or functions described herein. The instructions, when executed by the processor 1310, cause various operations to be performed to implement the disclosed embodiments.

As used herein, the terms "machine storage medium," "device storage medium," and "computer storage medium" are synonymous and used interchangeably. The term refers to a single or multiple storage devices and/or media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the executable instructions 1316 and/or data. Accordingly, these terms should be understood to include, but are not limited to, solid-state memories, and optical and magnetic media, including memories internal or external to the processor 1310. Specific examples of machine, computer, and/or device storage media include non-volatile memory, including, for example, semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), field-programmable gate arrays (FPGA), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms "machine storage medium," "computer storage medium," and "device storage medium" specifically exclude carrier waves, modulated data signals, and other such media, and at least some of the media covered by the term "transmission medium" are discussed below.

Transmission medium

In various exemplary embodiments, one or more portions of network 1380 may be: an ad hoc network, an intranet, an extranet, a Virtual Private Network (VPN), a Local Area Network (LAN), a Wireless LAN (WLAN), a Wide Area Network (WAN), a Wireless WAN (WWAN), a Metropolitan Area Network (MAN), the Internet, a portion of the Public Switched Telephone Network (PSTN), a Plain Old Telephone Service (POTS) network, a cellular telephone network, a wireless,

A network, another type of network, or a combination of two or more such networks. For example, the network 1380 or a portion of the network 1380 may include a wireless or cellular network, and the connection 1382 may be a Code Division Multiple Access (CDMA) connection, a global system for mobile communications (GSM) connection, or another type of cellular or wireless connection. In this example, the connection 1382 may implement any of a number of types of data transmission technologies, such as single carrier radio transmission technology (1xRTT), evolution-data optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, enhanced data rates for GSM evolution (EDGE) technology, third generation partnership project (3GPP) including 3G, fourth generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standards, other standards defined by various standards-establishing organizations, other remote protocols, or other data transmission technologies.

The instructions 1316 may be transmitted or received over a network 1380 using a transmission medium by a network interface device (e.g., a network interface component included in the communications component 1364), and may utilize any of a number of well-known transmission protocols (e.g., the hypertext transfer protocol (HTTP)). Similarly, the instructions 1316 may be transmitted or received to the device 1370 via a connection 1372 (e.g., a peer-to-peer connection) utilizing a transmission medium. The terms "transmission medium" and "signal medium" mean the same thing, and may be used interchangeably in the present invention. The terms "transmission medium" and "signal medium" shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions 1316 for execution by the machine 1300, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software. The terms "transmission medium" and "signal medium" shall accordingly be taken to include any form of modulated data signal, carrier wave, or the like. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

Computer readable medium

The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" represent the same thing, and may be used interchangeably in this disclosure. The term is defined to include both machine storage media and transmission media. The term therefore includes both memory devices/media and carrier wave/modulated data signals.

Various operations of the example methods described herein may be performed, at least in part, by one or more processors that are temporarily configured (e.g., via software) or permanently configured to perform the relevant operations. Similarly, the methods described herein may be implemented at least in part by a processor. For example, at least some operations of a method may be performed by one or more processors. The performance of certain operations may be distributed among one or more processors, not only within a single machine, but may be deployed across multiple computers. In some example embodiments, one or more processors may be located at a single location (e.g., within a home environment, office environment, or server farm), while in other embodiments, processors may be distributed across multiple locations.

While embodiments of the present invention have been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the present subject matter. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments shown are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The detailed description is, therefore, not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement, which is calculated to achieve the same purpose, may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

In this document, the terms "a" or "an" as is commonly used in patent documents include one or more than one, independent of any other instances or usages of "at least one" or "one or more". In this document, unless otherwise indicated, the term "or" is used to indicate a non-exclusive or, such as, "a or B" includes "a, but not B," B, but not a "and" a and B. In the appended claims, the terms "including" and "in which" are used as the plain-english equivalents of the respective terms "comprising" and "in which". Furthermore, in the appended claims, the terms "including" and "comprising" are intended to be open-ended; that is, a system, device, article, or process that includes other elements in addition to those listed in a claim after this term is still considered to be within the scope of that claim.