Architecture to protect in-vehicle service orientation with MAC generation permission list enforcement in host device

Abstract

An electronic control unit (ECU) or node is configured to generate a request from a secure peripheral for the MAC using a single key. The secure peripheral includes a stored shared key. The secure peripheral may also include a policy that enables it to detect whether a request from the V-ECU is valid, in which case it generates the MAC. The secure peripheral is also used to store information in a MAC generation permission list (MGAL). In some embodiments, a receiving node in a network receives data based on a response of a secure peripheral to a transmitting node request for a MAC. The receiving node uses this knowledge to avoid spoofing.

Description

[0001] introduce

[0002] Modern cars have witnessed technological advances in the amount of electronic equipment and software associated with both performance and luxury standards. For example, electronic control units (ECUs) are used extensively as embedded systems within the vehicle to control different electromechanical systems. Modern vehicles include different ECUs for controlling a large number of different vehicle systems, from engine control to entertainment devices.

[0003] Vehicle service-oriented architecture ("SOA") has increased the advancement of ECU technology in vehicles by re-architecting many of the large amounts of code in the 100+ ECUs in a modern vehicle into more explicit middleware. SOA combines certain components to act as middleware between applications or services on the one hand, and the vehicle operating system on the other. Middleware helps decouple the various software components from the vehicle hardware, resulting in greater software portability and a simpler development process. As in the computer world, SOA hides more abstraction layers and makes it easier for multiple third-party devices to port software applications to different parts of the ECU network.

[0004] Vehicle SOA has considerable security concerns. Previous vehicle implementations were hardwired or at least configured so that high priority messages were transmitted over dedicated, known data lines between ECUs. In contrast, SOA provides different possible implementations and relies on a service discovery period to make the various processing circuits aware of which sources the safety-critical messages are coming from. This architectural flexibility can lead to spoofing and other malicious attacks, in which foreign devices inserted into the vehicle network send false safety-critical messages to target devices in the vehicle to apply vehicle brakes, change vehicle speed, or perform other unauthorized and potentially dangerous actions.

[0005] Unless handled correctly, the “in-car network” can translate into more third-party malicious code that attempts to deceive other legitimate nodes, causing the vehicle to take actions with unintended consequences. Summary of the invention

[0006] A system for service-oriented authorization of messages includes a secure peripheral device and a host device, the host device being coupled to the secure peripheral device and including a processor, the processor being configured to execute code in a local memory therein to generate an encryption interface driver, the encryption interface driver being configured to determine whether the host device is authorized to send a security-critical first message from the host device to a receiving device by maintaining a message authentication code (MAC) generation allowance list (MGAL) implementation module at the host device, the MGAL implementation module being used to enable the host device to provide a MAC generation message including a first identifier (ID) to a MAC generation module executed on the secure peripheral device, wherein when the first message is authorized, the MAC generation module of the secure peripheral device is configured to retrieve a corresponding first key based on the first ID, generate a first MAC based on the corresponding first key, and send the first MAC to the encryption interface driver of the host device, and the host device is configured to send the first message together with the first MAC to the receiving device.

[0007] In various embodiments, when the first message is not authorized, the MAC generation module of the secure peripheral device is unable to identify the key and refrains from generating the MAC. When the host device receives a security-critical second message together with a second ID and a second MAC from the sending device, the encryption interface driver can be configured to determine whether the sending device is authorized to send the second message to the host device by enabling the host device to send the second ID and the second MAC together with a key serial number (KSN) for identifying the key to be retrieved to a MAC verification module executed within the secure peripheral device, wherein when the MAC verification module uses the KSN to retrieve the corresponding second key in the secure peripheral device, the secure peripheral device determines that the second message is authorized; and when the MAC verification module cannot use the KSN to identify the corresponding second key, the secure peripheral device determines that the second message is not authorized.

[0008] In various embodiments, the MGAL implementation module includes an authentication policy to determine whether a message is allowed to be transmitted. The first ID may include a secure vehicle communication data identifier (SecOCDataID). The processor may be configured to enable the encryption interface driver to have exclusive access to the secure peripheral device so that the message will be sent from the host device or received from the sending device. The processor may also be configured to execute code to include an encryption service manager module, which is operatively coupled to the encryption interface driver for transmitting security-critical message types requiring MAC verification or MAC generation to and from the secure peripheral device via the encryption interface driver, a communication stack module, which is operatively coupled to the encryption service manager module for transmitting non-security-critical message types to and from other vehicle devices, and for transmitting security-critical message types to and from the secure peripheral device via the encryption interface driver, and an application software module, which is operatively coupled to the communication stack module for performing corresponding functions based on the non-security-critical and security-critical message types transmitted from the communication stack module, wherein only the encryption interface driver can interface with the secure peripheral device.

[0009] In various embodiments, the processor includes a plurality of processor cores, at least one of the plurality of processor cores being configured to execute code to include one or more software applications, a communications stack module, and a cryptographic service manager module; and another of the plurality of processor cores comprising a secure peripheral device. A first identifier (ID) along with a first message transmitted from a host device to the secure device also includes a key sequence number configured to identify a service type associated with the message and determined during an earlier service discovery period. The host device and the secure peripheral device are parts of the same integrated circuit.

[0010] In various embodiments, the host device acts at least partially as a server; the server is configured to authorize a first client device to set or change a target value, authorize a second client device to read the target value, and restrict the second client device from setting or changing the target value.

[0011] In another aspect of the present disclosure, a system for authorizing messages in a service-oriented vehicle architecture includes: a plurality of nodes, each node including a secure peripheral device; and a host device coupled to the secure peripheral device and including a processor, the processor configured to execute code in a local memory therein to generate an encryption interface driver, the encryption interface driver configured to determine whether the host device is authorized to send a security-critical first message from the host device to one of the receiving nodes by maintaining a message authentication code (MAC) generation allowance list (MGAL) implementation module at the host device, the MGAL implementation module being used to enable the host device to provide a MAC generation message including a first identifier (ID) to a MAC generation module executed on the secure peripheral device, wherein when the first message is authorized, the MAC generation module of the secure peripheral device is configured to retrieve a corresponding first key based on the first ID, generate a first MAC based on the corresponding first key, and send the first MAC to the encryption interface driver of the host device, and the host device is configured to send the first message together with the first MAC to one of the receiving nodes.

[0012] In various embodiments, when the first message is not authorized, the MAC generation module of the secure peripheral device is unable to identify the key and refrains from generating the MAC. In addition, when the host device receives a security-critical second message together with a second ID and a second MAC from a sending device within a plurality of nodes, the encryption interface driver is configured to determine whether the sending device is authorized to send the second message to the host device by enabling the host device to send the second ID and the second MAC together with a key serial number (KSN) for identifying the key to be retrieved to a MAC verification module executed within the secure peripheral device, wherein when the MAC verification module uses the KSN to retrieve the corresponding second key in the secure peripheral device, the secure peripheral device determines that the second message is authorized, and when the MAC verification module cannot use the KSN to identify the corresponding second key, the secure peripheral device determines that the second message is not authorized.

[0013] In various embodiments, the MGAL implementation module includes an authentication policy to determine whether to allow the message to be transmitted. The first ID may include a secure airborne communication data identifier (SecOCDataID). The host device may include an Android virtual machine running on a hypervisor. The host device may download an Android package. The private key authorization field is used to fill in the manifest of the Android package and sign the manifest, and the public key corresponding to the private key verifies the signature.

[0014] In various embodiments, the MGAL implementation module may initiate an uninstallation of a version of the dynamic MGAL, if the uninstalled version is the only application with service information, the MGAL deletes the service information (if any) corresponding to the uninstalled version; and if the uninstalled version is not the only application with service information, the MGAL saves the service information (if any) corresponding to the uninstalled version. The host device includes a plurality of virtual machines running across hypervisors. The host device includes a security module for generating a verification key and a separate security module for generating a generation key, the generation key being used to create a MAC consistent with an MGAL policy.

[0015] The above overview is not intended to represent every embodiment or every aspect of the present disclosure. Rather, the foregoing overview merely provides examples of some of the novel concepts and features set forth herein. When understood in conjunction with the accompanying drawings and the appended claims, the above-mentioned features and advantages of the present disclosure and other features and attendant advantages will be apparent from the following detailed description of the illustrated examples and representative modes for implementing the present disclosure. In addition, the present disclosure explicitly includes various combinations and sub-combinations of the elements and features presented above and below.

[0016] The present invention also includes the following solutions.

[0017] Solution 1. A system for authorizing messages in a service-oriented vehicle architecture, comprising:

[0018] Security peripherals; and

[0019] a host device coupled to the secure peripheral device and comprising a processor configured to execute code in a local memory therein to generate a cryptographic interface driver configured to determine whether the host device is authorized to send a security-critical first message from the host device to a receiving device by maintaining a message authentication code (MAC) generation allow list (MGAL) implementation module at the host device, the MGAL implementation module for receiving a first identifier (ID) for determining whether the first message is authorized, and for enabling the host device to provide a MAC generation message including the first identifier (ID) to a MAC generation module executing on the secure peripheral device when the first message is authorized, wherein

[0020] The MAC generation module of the secure peripheral device is also configured to retrieve the corresponding first key based on the first ID, generate a first MAC based on the corresponding first key, and send the first MAC to the encryption interface driver of the host device, and the host device is configured to send the first message together with the first MAC to the receiving device.

[0021] Solution 2. The system according to Solution 1, wherein when the first message is not authorized, the MAC generation module of the secure peripheral device is unable to recognize the key and refrains from generating the MAC.

[0022] Option 3. The system according to Option 1, wherein:

[0023] When the host device receives the security-critical second message together with the second ID and the second MAC from the sending device, the cryptographic interface driver is configured to determine whether the sending device is authorized to send the second message to the host device by enabling the host device to send the second ID and the second MAC together with a key serial number (KSN) for identifying a key to be retrieved to a MAC verification module executed within the secure peripheral device, wherein

[0024] When the MAC verification module uses the KSN to retrieve the corresponding second key in the secure peripheral device, the secure peripheral device determines that the second message is authorized; and

[0025] When the MAC verification module cannot identify the corresponding second key using the KSN, the secure peripheral device determines that the second message is not authorized.

[0026] Solution 4. The system according to Solution 1, wherein the MGAL enforcement module includes an authentication policy to determine whether to allow transmission of a message.

[0027] Solution 5. The system according to Solution 1, wherein the first ID comprises a secure onboard communications data identifier (SecOCDataID).

[0028] Embodiment 6. The system of embodiment 1, wherein the processor is configured such that the encryption interface driver has exclusive access to the secure peripheral device for messages to be sent from the host device or received from a sending device.

[0029] Embodiment 7. The system of embodiment 1, wherein the processor is further configured to execute code to include:

[0030] a cryptographic services manager module operatively coupled to the cryptographic interface driver for communicating security critical message types requiring MAC verification or MAC generation to and from the secure peripheral device via the cryptographic interface driver;

[0031] a communications stack module operatively coupled to the cryptographic services manager module for communicating non-safety critical message types to and from other vehicle devices and for communicating safety critical message types to and from the secure peripheral device via the cryptographic interface driver; and

[0032] an application software module operatively coupled to the communication stack module for executing one or more software applications for performing one or more corresponding functions based on the non-safety critical message type and the safety critical message type communicated from the communication stack module,

[0033] Only the encryption interface driver can interface with secure peripheral devices.

[0034] Option 8. The system according to Option 7, wherein:

[0035] The processor includes a plurality of processor cores,

[0036] At least one processor core of the plurality of processor cores is configured to execute code to include the one or more software applications, the communications stack module, and the cryptographic service manager module; and

[0037] Another processor core of the plurality of processor cores is configured to execute code to include therein an encryption interface driver and an MGAL implementation module.

[0038] Option 9. A system according to Option 1, wherein the first identifier (ID) together with the first message transmitted from the host device to the secure peripheral device also includes a key serial number, and the key serial number is configured to identify the type of service associated with the first message and determined during an earlier service discovery period.

[0039] Option 10. The system according to Option 1, wherein:

[0040] The host device also includes a non-volatile memory coupled to the local memory;

[0041] The host device is further configured to participate in a service discovery procedure, wherein one or more key serial numbers (KSNs) are stored in the non-volatile memory, each of the one or more KSNs corresponding to a server configured to provide a specified service, or a client subscribed to receive a specified service;

[0042] Following the service discovery procedure, any data and any remote procedure call received by the host device corresponding to one of the designated services that is not accompanied by a corresponding KSN of the one or more KSNs stored in the non-volatile memory is rejected.

[0043] Embodiment 11. The system according to embodiment 1, wherein:

[0044] The MGAL implementation module of the host device is configured to determine a permission of the host device based on the first ID, the permission comprising:

[0045] (1) Whether the host device is authorized to act as a client to set or change the target value;

[0046] (2) whether the host device is authorized to act as a client to read the target value; and

[0047] (3) Whether the host device is authorized to act as a server to publish values ​​or provide subscriptions, and

[0048] When the MGAL implementation module determines according to (1) or (2) that the host device is authorized to act as a client, the host device uses the MGAL implementation module to determine whether security-critical messages generated thereafter by the host device are authorized.

[0049] Solution 12. A system for authorizing messages in a service-oriented vehicle architecture, comprising:

[0050] Multiple nodes, each node includes:

[0051] Security peripherals; and

[0052] a host device coupled to the secure peripheral device and including a processor configured to execute code in a local memory therein to generate a cryptographic interface driver configured to determine whether the host device is authorized to send a security-critical first message from the host device to a receiving node among the plurality of nodes by maintaining a message authentication code (MAC) generation allowance list (MGAL) implementation module at the host device, the MGAL implementation module for enabling the host device to provide a MAC generation message including a first identifier (ID) to a MAC generation module executing on the secure peripheral device, wherein

[0053] When the first message is authorized, the MAC generation module of the secure peripheral device is configured to retrieve the corresponding first key based on the first ID, generate a first MAC based on the corresponding first key, and send the first MAC to the encryption interface driver of the host device, and the host device is configured to send the first message together with the first MAC to one of the receiving nodes.

[0054] Embodiment 13. The system according to embodiment 12, wherein when the first message is not authorized, the MAC generation module of the secure peripheral device is unable to recognize the key and refrains from generating the MAC.

[0055] Embodiment 14. The system according to embodiment 12, wherein:

[0056] When the host device receives a security-critical second message along with a second ID and a second MAC from a sending device within the plurality of nodes, the cryptographic interface driver is configured to determine whether the sending device is authorized to send the second message to the host device by enabling the host device to send the second ID and the second MAC along with a key serial number (KSN) for identifying a corresponding second key to be retrieved to a MAC verification module executed within the secure peripheral device, wherein

[0057] When the MAC verification module uses the KSN to retrieve the corresponding second key in the secure peripheral device, the secure peripheral device determines that the second message is authorized; and

[0058] When the MAC verification module cannot identify any key using the KSN, the secure peripheral device determines that the second message is not authorized.

[0059] Embodiment 15. The system according to embodiment 12, wherein the MGAL enforcement module includes an authentication policy to determine whether to allow transmission of a message.

[0060] Embodiment 16. The system according to embodiment 12, wherein the first ID comprises a secure onboard communications data identifier (SecOCDataID).

[0061] Embodiment 17. The system according to embodiment 12, wherein:

[0062] The host device includes an Android virtual machine running on a hypervisor.

[0063] Download the Android package on the host device.

[0064] The private key authorizes the Android package's manifest to be populated with the expected fields, and the private key signs the manifest; and

[0065] The public key corresponding to the private key verifies the signature.

[0066] Embodiment 18. The system according to embodiment 12, wherein:

[0067] The MGAL implementation module initiates the uninstallation of the dynamic MGAL version;

[0068] If the uninstalled version of the dynamic MGAL is the only application having service information, the MGAL implementation module deletes the service information (if any) corresponding to the uninstalled version; and

[0069] If the uninstalled version is not the only application having service information, the MGAL implementation module saves the service information (if any) corresponding to the uninstalled version of the dynamic MGAL.

[0070] Option 19. The system of Option 12, wherein the host device comprises a plurality of virtual machines running across hypervisors.

[0071] Embodiment 20. The system of embodiment 12, wherein the host device comprises a security module for generating a verification key and a separate security module for generating a generation key, wherein the generation key is used to create a MAC consistent with an MGAL policy. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present disclosure and, together with the description, explain the principles of the present disclosure.

[0073] Figure 1 is a conceptual diagram of an example electronic control unit (ECU) including secure peripherals and a host device implemented using a vehicle's service-oriented architecture (SOA), according to various embodiments.

[0074] Figure 2 is a conceptual diagram of an example ECU including a host device having two processor cores, wherein a first processor core is configured to execute an application software module, a communication stack module, and a cryptographic service manager module, and wherein a second processor core is configured to execute a cryptographic interface driver.

[0075] Figure 3 is an example timing diagram of a data packet according to one embodiment.

[0076] Figure 4 is a timing diagram illustrating the difference between a "get" and "set" license compliance node in a vehicle according to one embodiment

[0077] Figure 5 A representation of downloading an Android application package (APK) onto an Android virtual machine of a dual virtual machine processor to process a firmware update is shown according to one embodiment.

[0078] Figure 6 A representation of a dynamic MGAL update using relevant information for two virtual machines on a computer is shown according to one embodiment.

[0079] Figure 7 is a hardware representation of one aspect of the present disclosure.

[0080] The drawings are not necessarily to scale and may present simplified representations of various features of the present disclosure as disclosed herein, including, for example, specific dimensions, orientations, positions, shapes, and proportions. Details related to such features will be determined in part by the specific intended application and use environment. DETAILED DESCRIPTION

[0081] The present disclosure allows for embodiments in many different forms. Representative examples of the present disclosure are shown in the accompanying drawings and described in detail herein as non-limiting examples of the disclosed principles. For this reason, elements and limitations described in the abstract, introduction, summary, and detailed description sections but not explicitly set forth in the claims should not be incorporated into the claims individually or collectively by implication, inference, or otherwise.

[0082] For the purposes of this specification, unless otherwise stated, the use of the singular includes the plural and vice versa, the terms "and" and "or" shall be conjunctions and disjunctions, and the words "including", "comprising", "comprising", "having", etc. shall mean "including but not limited to". For example, "optimal vehicle routes" may include one or more optimal vehicle routes. In addition, approximate words (such as "approximately", "almost", "substantially", "generally", "approximately", etc.) may be used herein in the following senses: "at, close to, or nearly at" or "within 0-5% of..." or "within acceptable manufacturing tolerances", or logical combinations thereof. As used herein, a component "configured to" perform a specified function is capable of performing the specified function without change, not merely having the potential to perform the specified function after further modification. In other words, the described hardware, when explicitly configured to perform a specified function, is specifically selected, created, implemented, utilized, programmed and / or designed for the purpose of performing the specified function.

[0083] The principles of the present disclosure are directed to vehicle networks and nodes, and their particular susceptibility to spoofing and other malware attacks when vehicles are implemented in a SOA-based network environment using multiple host devices for performing different functions. According to certain aspects, this vulnerability can be addressed and the problem solved by using a secure peripheral / cryptographic accelerator device (hereinafter referred to as a "secure peripheral" for convenience) to verify the integrity of security-critical messages and generate a message authentication code (MAC) on the message to be sent for each transmitting node. For the purposes of this disclosure, a security-critical message may include any message sent from a transmitting device to a receiving device that performs a function that requires security verification, including but not limited to message types involving performing physical actions or functions, such as braking, accelerating, setting different values ​​that other devices may rely on, and performing standard safety-based functions required to avoid damage to the vehicle or injury to passengers within the vehicle.

[0084] Physically, the host device is a hardware component or a portion thereof, which can be implemented using, for example, a processor and other components in an ECU in a vehicle. The secure peripheral is also a hardware component or a portion thereof, and can be physically implemented in any number of ways. For example, the secure peripheral can reside on a different part of the same integrated circuit device on which the host device resides. In other embodiments, the secure peripheral can be implemented on a separate integrated circuit and physically coupled to the host device. In yet other embodiments, the host device and the secure peripheral can be embedded in different housings and coupled together via wires.

[0085] Figure 1 1 is a conceptual diagram of an example ECU 100 including a secure peripheral device 104 and a host device 102 implemented using a service-oriented architecture (SOA) in a vehicle according to various embodiments. The ECU 100 includes the host device 102. The host device may include one or more processors, microcontrollers, and memory (see Figure 4 ). The host device 102 is connected to the secure peripheral 104. In various embodiments, the secure peripheral 104 includes a cryptographic accelerator, discussed further below. An ECU may sometimes be referred to as a node. For purposes of this disclosure, a node may be any processor in an ECU or device that includes the security measures resident underneath. In one aspect of the present disclosure, a secure peripheral 104 (or another higher privileged module or core (which may also include a cryptographic accelerator) that potentially has exclusive access to the secure peripheral 104) within a transmitting node (e.g., ECU 100 or other processor or node) in a vehicle or other transportation mechanism uses policies present in the MGAL enforcement module 122 for internal supervision that ensures that secret keys within the ECU 100 cannot be used to generate MACs on messages that the ECU 1000 / node is not otherwise allowed to send. A more detailed description of this innovation is provided below with respect to Figure 1 To present.

[0086] An ECU is a device in a vehicle that controls one or more of the vehicle's electrical systems. An ECU instructs the vehicle how to operate. In most cases, the heart of an ECU is one or more processors that execute instructions from embedded software. A virtual ECU (V-ECU) is a software model of the target ECU hardware that can help perform ECU functions and simulations, but it can be implemented entirely in software, such as on the ECU's microprocessor. For example, a V-ECU advantageously enables vehicle functions to be tested in the lab using a microcontroller before the functions are deployed in a vehicle to be sold. Each instance of a V-ECU can be simply deployed with a test solution, after which the functions can be thoroughly tested. For complex ECUs, a V-ECU can be used as an independent entity within the system to perform authorized tasks.

[0087] As a pair Figure 1 In a brief introduction to the operation of the circuit, the MAC generation module 109 is used in conjunction with the MAC generation allow list (MGAL) implementation module 122 when an application in the application software module 114 at the host device 102 generates a security critical message and sends (via the communication stack module 116, the cryptographic service manager module 118, and the cryptographic interface driver 120 within the host device 102) a request to generate a MAC for use on a secure (security critical) message that the host device 102 wants to send to a target ECU (node) or virtual ECU (within a node). If the message is non-security critical, the communication stack module 116 sends the non-security critical message back to the application software module 114 for execution by the application, or if the request is intended for another node, the communication stack module 116 instead sends the non-security critical message over the network (conceptually indicated by one of the arrows 188) for execution by the intended receiving node or ECU. If the request is a security critical request intended for another node, the request will require a MAC. A non-exhaustive explanation of how an authorized, security critical message obtains a MAC is set forth below. In addition, the following excerpt further describes how and when security-critical messages are considered unauthorized and rejected accordingly.

[0088] Figure 1The configuration in is a hardware / software-based ECU solution that, when activated, tends to reduce the cost of the entire network node without losing its capabilities. The host device 102 can initiate the process by sending a MAC generation request (received at the communication stack module 116, as discussed further below) to the MAC generation module 109 of the individual secure peripheral device 104a via the hardware connection 110. However, the information sent from the host device 102 to the MAC generation module 109 via the hardware connection 110 depends on whether the message meets the relevant policies of the MGAL implementation module 122 of the encryption interface driver 120 in the host device, as explained further below. If the MGAL implementation module 122 authorizes the passage of the security-critical message to obtain a MAC (which in turn will authorize it to be executed at the receiving node), the MAC generation message is first sent to the MAC generation module 109 via the hardware connection 110. The MAC generation message may also include criteria such as a message identifier (referred to as SecOCDataID in this configuration), KeySlotNum ("key slot identifier"), and other security-related information elements. In some embodiments, the host device 102 may also include MAC data, which may include a service type, a type of data transmitted, and the like. In yet another embodiment, the MAC generation module 109 can use hardware to check the relevant content of the MGAL implementation module 122, and determine whether the MAC of the host device 102 can be generated based on the host's previous history and relevant factors based on the MAC ID. For example, the MAC generation module 109 can further check the history of the MGAL implementation module 122 that lists the MAC IDs (in embodiments where they are available). In other configurations, the MGAL publishes one or more policies about which nodes / ECUs were previously allowed to send which messages to what modules related to what topics. In the previous embodiment, if the MAC ID is not listed in the MGAL, the MAC generation module 109 will not be able to generate a MAC and will return an error. If the information of the MGAL shows that the message is authentic and the host device 102 is public, the MAC generation box can retrieve the key from the MAC generation key module 107, can generate a MAC, and can send it back to the host via the hardware connection 112. As noted, the receiving node can be made aware of the generation (or lack of MAC) of the MAC for this device. Using this information and similar background information, the receiving node can ultimately understand which devices may be trusted and untrusted with respect to which MAC IDs or in general.

[0089] MAC verification module 103 may alternatively be used when host device 102 has received a message from a different node in the network so that the different node wants host device 102 to perform the function in the message. To verify the authenticity of the MAC, host device 102 may obtain the received MAC and send a MAC verification message to the MAC verification module via hardware connection 106 along with factors similar or identical to those listed above with reference to hardware connection 110. If MAC verification module 103 determines that the MAC represents spoofing, it does not return a MAC and host device 102 may deny the request. Otherwise, if MAC verification module 103 finds or retrieves a key that matches the key serial number in the provided MAC verification message from MAC verification key module 105, MAC verification key module 105 may use the retrieved key serial number to generate or find the corresponding MAC and send the retrieved MAC back to host device 102 via hardware connection 108.

[0090] Although the host device 102 and the secure peripheral device 104 can be packaged in an ECU 100 or similar module, this configuration is not required, and in some embodiments, an ECU is not used. In addition, for the purposes of this disclosure, the term "processor" can constitute more than one processor. The term processor can refer to any kind of controller or microcontroller used to perform various tasks. In some cases, at least a portion of the processor can be dedicated hardware, such as in a digital signal processor (DSP). The processor may also be available as an application-specific integrated circuit (ASIC), a system on a chip (SoC), a combinational Boolean logic circuit that performs the necessary digital functions, or the like, or implemented therein (partially or completely). The transistors used in the processor may include complementary metal oxide semiconductor (CMOS) technology, bipolar transistors, gallium arsenide transistors, and combinations thereof. The processor can execute middleware, and in some embodiments, it may rely at least in part on one or more application programming interfaces to communicate with other systems. The processor may also include upgradeable firmware as discussed herein. In addition, the hardware portion of the host device 102 may also include a local memory 723 ( Figure 7 ). Local storage 723 ( Figure 7 ) may be coupled to the processor 721 for storing data and code, including enabling the processor to generate Figure 1Executable code for the various functional modules depicted in . Memory 723 can be any form of volatile and / or non-volatile memory, including but not limited to dynamic random access memory (DRAM), static random access, etc. Host device 102 may also include other forms of memory 723, including any non-volatile computer accessible storage device or solid-state drive for long-term storage of data, and NAND and NOR-based flash memory, which are also generally non-volatile in nature. Memory 423 can be customized to form any database or repository or combination thereof for use in EPC.

[0091] Return to reference Figure 1 The host device 102 includes at least one processor and a local memory of the processor for executing codes for performing various functions. Figure 1 1 and 120. Each of the modules 114, 116, 118, and 120 within the host device 102 is separated by a bidirectional arrow. These arrows represent the conceptual flow of information with the various modules (sometimes referred to as layers) and the interactions between the various modules as they each run as one or more execution threads on the core(s) of one or more processors.

[0092] Figure 1 The application software module 114 enables the host device 102 to be populated by one or more low-level applications. For example, in the case where the ECU 100 is dedicated to performing a specific function (such as reading engine temperature data and providing it to other ECUs), the application software module 114 can be configured to perform this function and provide output data to the communication stack module 116 via the lower horizontal arrow. The application software module 114 can also obtain data from other ECUs via the communication stack module 116 using the upper horizontal arrow. In some embodiments, the communication stack module 116 can function like a network layer, where data is passed to and from the host device 102 through a physical network such as Ethernet (or any of a variety of different network embodiments). As illustrated by the conceptual input arrow 188, data received at the communication stack module 116 and intended for one of the local applications running in the application software module 114 can be passed to the module 114. Similarly, in the case where the application software is configured to output data from the host device 102, the application in question can pass the device to the communication stack module 116, where the data is then passed to the conceptual output arrow 188. The arrows 188 collectively represent the paths by which data is transferred to and from other ECUs at the communication stack module 116 .

[0093] Referring back to the application software module 114, it will be appreciated that this module lacks direct access to the safety peripherals 104. Thus, the application software module 114 is free to run low-privilege, non-critical functions and pass the results to the communication stack module 116 for transmission to other locations in the vehicle. Non-safety critical functions are typically those that have no detrimental effect on vehicle control and do not convey erroneous information to the driver that could cause an external force event, a fault, or other problem. This is in contrast to safety critical messages, which may include messages instructing the vehicle to accelerate, brake, or perform some other potentially critical function. As noted, in an SOA configuration, different plug-ins, custom ECUs, and other processing or control devices can be dynamically added to or removed from a vehicle or other transportation mechanism during the life of the vehicle or other transportation mechanism. Unlike existing static, hardwired vehicle configurations, where private messages travel over dedicated lines, creating little suspicion as to where the message came from, the more flexible SOA requires that safety-critical messages or data from a sending ECU (or sending node) be accompanied by a verifiable message authentication code (MAC) so that the receiving node can use its own security enforcement hardware and software to verify that the message is authorized before the receiving node acts on it. If this were not the case, in an SOA, a malicious user could (for example) attach a plug-in device to a vehicle's infotainment system. The plug-in system could then transmit an unauthorized safety-critical message to a receiving node responsible for applying the vehicle's brakes. Without the MAC authorization requirement, the plug-in module could effectively trick the receiving node into randomly applying the brakes, which could result in a dangerous crash event.

[0094] In contrast to non-safety critical messages, safety critical messages need to be accompanied by an appropriate MAC, which can be generated by a private key in a repository within the secure peripheral device and verified for its authenticity. Aspects of these measures are discussed further below, where the application software layer 114 is performing a safety critical task to send to another ECU or is receiving a safety critical message.

[0095] The host device 102 also includes an encryption service manager module 118. The encryption service manager module 118 is a software module generated by executable code of the processor. The encryption service manager module 118 is operatively coupled to the communication stack module 116 and the encryption interface driver 120 via two sets of four horizontal bidirectional lines connected to the encryption service manager module 118. These bidirectional lines are illustrated to reflect that the encryption service manager module 118 can send and receive messages to and from the communication stack module 116 and the encryption interface driver 120. The importance of this operational coupling is also discussed further below.

[0096] Similar to modules 114 and 116, the encryption service manager module 118 is configured to send and receive non-security critical messages (for its part). Similarly, similar to modules 114 and 116, the encryption service manager module 118 does not have access to the secure peripheral device 104. In one embodiment, the encryption service manager module 118 can receive messages from the communication stack module 116 and can forward those messages to the encryption interface driver 120. In addition, the encryption service manager module 118 can receive messages from the encryption interface driver 120 and pass the messages to the communication stack module 116 via the appropriate horizontal operation connection. Depending on the destination of the message, the communication stack and conceptual arrow 188 can be used to send the message to another receiving node in the vehicle. Alternatively or additionally, the message from the encryption service manager module 118 can be sent to the communication stack module 116, where it is forwarded to the application software module 114 for use by the application or function resident thereon.

[0097] Because this aspect of the present disclosure prevents low-level modules in the architecture from accessing high-security features, processors in vehicles that implement these principles cannot be easily deceived or otherwise maliciously compromised. Safety-critical messages need to be transmitted along with a MAC to authorize the function in the message to be executed. Therefore, if the communication stack module 116 receives a safety-critical message from a sending node in another part of the vehicle, the module 118 cannot simply forward the message to the application software module 114 for execution because the application software module 114 is configured to only execute non-safety-critical functions of the vehicle without the correct permission. Conversely and for the same reason, the application in the module 114 cannot generate a safety-critical message and pass it to the communication stack module 116 via one of the arrows 188 along the transmission hardware of the ECU 100 to the receiving node because the safety-critical message lacks a MAC. The receiving node will recognize the lack of a MAC (or in some examples, a wrong MAC) and will simply discard or ignore the message. Therefore, even in SOA, the lack of a correct MAC will prevent safety-critical messages from being authorized for execution, and the integrity of the SOA vehicle system is still maintained.

[0098] Still reference Figure 1As noted, the host device 102 may also include an encryption interface driver 120. One purpose of the encryption interface driver 120 is to authorize security-critical messages to be executed on the EPC 100 or another node. More specifically, the encryption interface driver 120 is a software module that is operatively coupled to the communication stack module 116 and coupled to a separate secure peripheral device 104a (which may include a cryptographic accelerator as described herein) via hardware connections 110, 112. In addition, while the encryption interface driver 120 is a software module or data structure implemented on the host device 102, the secure peripheral device 104 is a hardware component that may reside on the same integrated circuit as the host device, or may reside on a common printed circuit board (PCB) with the host device 102, where the host device 102 and the secure peripheral device 104 are connected together using hardware, or may reside as a separate physical component connected to the host device.

[0099] According to aspects of the present disclosure, the host device 102 can quickly and efficiently implement non-safety critical messages, typically without the need for further authorization. However, in the absence of the exemplary procedures outlined below, the host device 102 lacks authorization to perform safety critical messages, thereby maintaining the security of the SOA vehicle network.

[0100] In the host device 102, the encryption interface driver 120 includes a MAC generation allow list (MGAL) implementation module 122. The MGAL can be a policy or policy group implemented in software, or as a data structure in a data repository within the host device 102 and accessible to the encryption interface device 120. In various embodiments, the purpose of the encryption interface driver 120 is twofold. First, for security-critical messages from a sending device (e.g., another ECU located in a vehicle, etc.), the encryption interface driver 120 can use the hardware connections 106 and 108 to directly interface with the secure peripheral device 104 to determine whether the sending device is authorized to send the security-critical message, so that, for example, if an attached MAC accompanies the message and the MAC is legitimate, the message can be passed to a local application within the application software module 114 on the host device 102 to perform the function described in the message. In this case, when a security-critical message is sent along with a verified MAC (e.g., in or with the message payload) that is recognized by the secure peripheral device 104 and authorizes the host device 102 to execute the instructions in the message to perform the intended function, the security-critical message can be considered valid. In some embodiments, the message may also include other relevant information that may be used by the secure peripheral 104 (eg, a key sequence number and a message identifier).

[0101] Second, for security-critical messages generated by an application on an application software module 114 of a host device 102 (in this example, a sending device), the cryptographic interface driver 120 can be configured to use the MGAL implementation module 122 in conjunction with the hardware connections 110 and 112 to and from the secure peripheral device 104 to determine whether the host device 102 is authorized to send security-critical messages from the host device 102 to a receiving device (e.g., another processor, ECU, or other component performing a function). If the host device 102 is authorized, the security-critical message along with the generated MAC and potentially other information can be sent to the communication stack module 116 and output to the receiving device. Upon verifying the integrity of the attached MAC, the receiving device can then proceed to perform the security-critical function.

[0102] Therefore, in order to perform a security-critical function or to generate a security-critical message to be sent for performing a potentially critical function on a receiving device, the application software module must ultimately receive authorization from the secure peripheral device by first passing through the encryption interface driver, where the policy of the corresponding MGAL is determined to identify whether the security-critical message is authorized. If not authorized, the message is ignored or discarded. If the host device 102 is receiving a message from a sending device with a MAC, the MGAL implementation module 122 is not involved. Alternatively, the existing MAC is verified as being credible or untrustworthy. Examples of these two standards are described in more detail below.

[0103] Generates a safety-critical message on a host device for performing a priority function on another device

[0104] Continue to refer Figure 1, showing a non-exhaustive embodiment of the above-described procedure. Beginning with an application software module 114, an application or database therein can generate a message. The present application can also generate other information associated with the message, such as a message identifier (ID) and a source. The message is then transmitted to the communication stack module 116. If the message is a non-safety-critical message for execution on a receiving device (e.g., an instruction to read a value), the communication stack module 116 simply sends the message to the receiving module over the physical network in place (shown by the conceptual outgoing arrow 188). In other cases, the message may be a safety-critical message, such as a braking command that is ultimately intended to be executed by an ECU associated with a braking device ("receiving device"). The braking message may or may not constitute a malicious spoofing attempt. In any case, the communication stack module 116 in this embodiment determines that the message is a safety-critical message when examining the relevant fields in the message, and if the message is to be sent to the designated receiving device and executed, the message needs to have a valid MAC attached thereto. (If a message is simply sent by the communications stack module 116 over the physical network to a destination receiving device via one of arrows 188 without a valid MAC, the message will be ignored or, if the message is deemed safety-critical, an error message will be generated).

[0105] Therefore, when the application sends the generated message to the communication stack module 116, the communication stack module 116 instead sends the security-critical message to the cryptographic service manager module 118 of the host device 102. The cryptographic service manager module 118 can then forward the message to the encryption interface driver 120. This information can indicate to the cryptographic service manager module 118 that the device originated from the host device 102, but must be verified as authentic and authorized before it is transmitted to the intended receiving device. That is, a MAC should be generated and attached to the message to verify that the security-critical message is authorized.

[0106] In these embodiments, the encryption interface driver 120 is a high privilege module for processing security-critical messages. This is in contrast to the other modules 114, 116, and 120 in the host device 102. Because the latter modules constitute low privilege modules strictly for non-security-critical messages, if malicious code or deception attempts to damage the low privilege modules, the corresponding messages will be sent by the encryption interface driver before they can be executed or acted upon. Because the encryption interface driver 120 is a high privilege module solely responsible for security implementation, the corresponding security-critical but deceived messages are rejected based on the implementation policy of the MGAL implementation module 122 in the encryption interface driver 120. In short, because the three modules 114, 116, and 118 in these embodiments are low privilege modules, they cannot access the secure peripheral device 104 without authorization from the encryption interface driver 120. This fact ensures that: even in SOA, no non-security-critical module can perform security-critical functions without first receiving authorization from the secure peripheral device 104. In this way, security and message integrity are maintained.

[0107] Referring back to the previous example, the security critical message is passed from module 118 to the MGAL implementation module 122 of the encryption interface driver 120. The encryption interface driver 120 may first check the authentication policy identified in the MGAL 122 to determine whether the specific message to be sent is authorized to be transmitted by the node, which authentication policy may include a data structure or may reference a data repository. If the security critical message lacks a valid MAC, the receiving node will reject the security critical message. One advantage of executing the MGAL implementation module at the host is that the processor typically has a much higher clock speed and can execute instructions faster than the secure peripheral device 104.

[0108] In various embodiments, the cryptographic interface driver 120 uses the MAC ID or other ID (e.g., secure onboard communications data identifier (SecOCDataID), key sequence number (KSN), etc.) and compares it to the policy of the MGAL implementation module 122 to determine whether a MAC for the present security-critical message can or should be generated at the host device 102. For the purposes of this disclosure, unless otherwise specified or clear from the context, the term "identifier" or "ID" refers to a MAC ID (i.e., an ID that can be used to generate or retrieve a corresponding MAC), or some other identifying tag that exists that, by itself or in conjunction with other information, allows a recipient to determine that a MAC should be provided for a security-critical message. In some embodiments, the SecOCDataID itself can be used to determine whether an appropriate MAC should be given to the message, which in turn can be appended to or in conjunction with the MAC generation message before the message is sent to the secure peripheral device 104.

[0109] In yet other embodiments, the host device 102 may also use the MGAL implementation module 122 to consider results from previous discoveries, the host's previous history, and related factors. For example, in some embodiments, the encryption interface driver 120 may further check the history records of the MGAL implementation module 122 (where they are available), which may list the relevant MAC IDs associated with different security-critical messages. In other configurations, the MGAL implementation module 122 may issue one or more policies regarding which nodes / ECUs were previously allowed to send which messages to what modules and on what topics.

[0110] If the MAC ID is not listed in or otherwise identifiable from the MGAL implementation module 122 (at the host device 102), or the corresponding key cannot be found or retrieved from the MAC generation key module (at the secure peripheral device 104), the secure peripheral device 104 will not be able to generate a MAC and may return an error or simply discard the message. If the MGAL's information shows that the message is public, as noted, the host device 102 can send a MAC generation message to the secure peripheral device 104. The MAC generation module 109 can use the ID in the message to retrieve the key from the MAC generation key module 107, which can be a data repository and can include hardware and / or software. Using the retrieved key, the MAC generation module 109 can generate a MAC and can send it back to the host device 102 via the hardware connection 112. As noted, in some arrangements, the receiving node can be made aware of the generation (or lack of a MAC) of the MAC for this device. In some embodiments, using this and similar background information, the receiving node can ultimately understand which devices can and cannot be trusted with respect to this MAC ID or in general.

[0111] After the MGAL implementation module 122 determines that the ID accompanying the security-critical message is legitimate, the MGAL implementation module 122 may thereafter send a MAC generation message to the secure peripheral device 104 via the hardware connection 110. In one embodiment, the MAC generation message may include a message ID (e.g., SecOCDataID), a data payload of the message (optional), and a key sequence number (KSN) indicating the source of the message.

[0112] At the secure peripheral device 104, a security critical message is received at a MAC generation module 109. The MAC generation module 109 may be a hardware or software component, or a combination thereof. The MAC generation module 109 may be coupled to a MAC generation key module 107. In various embodiments, the MAC generation key module 107 may include a list of secret keys that may also be shared by various devices authorized to encrypt and decrypt the security critical messages to which they are respectively associated. In some embodiments, the MAC generation key module 107 instead includes one or more algorithms for enabling the MAC generation module 109 to retrieve the corresponding key based on the ID in the message.

[0113] If the security-critical message is authorized (e.g., not a spoofing attempt), the MAC generation module 109 can use the message ID to identify, generate, and retrieve the corresponding key from the MAC generation key module 107. As noted, the key can be in a list in the MAC generation key module 107, or it can be generated based on the ID supplied to it from the MAC generation module 109 and potentially other criteria. Thereafter, the MAC generation module 109 uses the key to generate a MAC. The MAC can be generated by the key using software, combinatorial logic, or other means. The generated MAC can be attached to or otherwise accompanied by the security-critical message. As noted, after the MAC generation module 109 generates the MAC based on the retrieved key, the MAC generation module 109 can transmit the result of the procedure along with the MAC back to the host device 102 via the hardware connection 112. In various embodiments, the result may include messages and other indications that an error has not occurred and that the security-critical message along with the MAC is authorized to be sent to the receiving device.

[0114] In various embodiments, as described above, the MGAL implementation module 122 will receive a message ID. If the message is authentic, the message ID will be included in the MGAL implementation module as the message type to which it will add a MAC. That is, the MGAL implementation module 122 uses the message ID as an index into a permission table. The permissions in the table will indicate whether the host device 102 is authorized to act as a server or client for messages relative to another node (e.g., another host or ECU), and depends on the message type and the context of the transaction. When acting as a client, the MGAL will typically specify whether the host 102 has one of two client types. One such client type may act as a client, where it may only read data, such as from some target source. Another type is a client that can actually write or set data, such as with respect to a client. Figure 4 discussed in more detail.

[0115] In these embodiments, MGAL implementation module 122 may not only consider the message ID, but it may also consider the message type which indicates what host 102 is doing in the final sent message. In some embodiments, the message type is based solely on the message ID or is included within the ID and may be understood by MGAL implementation module 122 upon receiving the ID. In other embodiments, the message type may be gleaned by MGAL implementation module 122 based on additional information provided to it.

[0116] The message type may specify different actions taken by the requesting device. For example, the message type may specify whether the message type will publish data, such as making the speed of the vehicle (or other types of information) available to other devices. In order to obtain a state to others, the permission table may specify whether the requesting host has the appropriate permission to perform the function specified by the message. In other examples, the message type may simply be to read the specified data. Therefore, in these embodiments, the MGAL implementation module 122 may include additional criteria for specifying what the host 102 or device is trying to do for a specific service. Regarding the latter example, the SecOCDataID may specify the service ID itself, and then the message type. As noted, example message types include publishing (e.g., where the device is authorized to act as a publishing server for a specific type of data). Another example message type is a request, which is typically performed by a remote procedure call (RPC). As another example, the SecOCDataID also includes a method ID that describes whether the message is trying to set (write) or get (read) data. For example, depending on the method ID and the message type, the MGAL implementation module 122 may use different permissions. In some cases, the message ID may also include a bit indicating whether the device or host can act as a client that can set data for this message. This bit may be reserved for devices with higher permissions in the vehicle.

[0117] Receiving, at a host device, a safety critical message for performing a priority function on the host device

[0118] In another aspect of the present disclosure, the EPC 100 may receive a message at the host device 102 from a sending node, which may be another EPC or a dedicated processor in the vehicle. Figure 1, receiving a message via a wired connection, which is conceptually represented by an input arrow 188 corresponding to the communication stack module 116. If the message is considered a non-safety-critical message by the communication stack module 116, the message can be passed to the application software module 114, where the instructions in the message can be executed. Conversely, if the message is considered a high-privileged message and lacks a MAC, the communication stack module 116 can discard or ignore the message, or optionally send an error message to one or more devices in the vehicle network. In addition, if the message is considered a high-privileged message and includes a MAC, the communication stack module 116 passes the message to the encryption service manager module 118. The encryption service manager module 118 forwards the message to the encryption interface driver 120 using the operational coupling indicated by line 189. In this embodiment, the host device 102 attempts to verify the authenticity of the MAC to ensure that the safety-critical message is authorized. Therefore, in this case, the MGAL implementation module 122 is not required.

[0119] The encryption interface driver 120 then transmits a MAC verification message to the MAC verification module 103 of the secure peripheral device 104 through the hardware connection 106. In various embodiments, the MAC verification message may include an ID corresponding to the MAC (e.g., SecOCDataID, etc.) together with the MAC to be verified. In addition, the host device 102 may include a key serial number (KSN) in the MAC verification message. In this embodiment, the host device 102 may indicate which key to use for the secure peripheral device 104 by including the KSN. At the secure peripheral device 104, the MAC verification module 103 receives the MAC verification message. The MAC verification module 103 may be generated by code running on the secure peripheral device, or it may be implemented in hardware, middleware, or a combination of hardware and software.

[0120] Based on the KSN as an index, etc., the MAC verification module 103 retrieves the corresponding key from the MAC verification key module 105. Like the MAC generation key module 107, the MAC verification key module may include a data repository of private keys used by the host device 102. The specific key identified may depend on the function of the security-critical message and, in this case, is specified by the KSN. The MAC verification module 103 uses the KSN to retrieve the corresponding key. The key is then used to determine whether the MAC sent for verification is actually valid. It should be noted that the KSN is typically initially determined during the service discovery phase. In that case, the KSN of the arriving security-critical message should match that of the KSN discovered by the host device 102. If there is no match, the arriving message is rejected as unauthorized. Thus, for example, during a service discovery period, the host device may participate in a service discovery procedure in which the key serial number (KSN) is stored in the host device's non-volatile memory 723 (see Figure 7 ). Each of the KSNs corresponds to a server configured to provide a specified service, or a client subscribed to receive a specified service. After the service discovery procedure, any data received by the host device corresponding to one of the specified services that is not accompanied by a corresponding KSN stored in non-volatile memory during service discovery is rejected. The above discovery period can also be applied to the server side, so that when a client (which can be another device in the vehicle) subscribes to a service and the host device acts as a server for that service, the host device stores the KSN associated with the client. Thereafter, the server continues to ensure that any remote procedure calls (RPCs) received are accompanied by the same KSN stored during the service discovery period. If the KSNs are different, the server rejects the RPC.

[0121] If the retrieved key is successfully used by MAC verification module 103 to match the MAC received from encryption interface driver 120, then secure peripheral device 104 determines that the security critical message is valid. MAC verification module 103 of secure peripheral device 104 sends this result back to encryption interface driver 120 of host device 102 through hardware connection 108, authorizing the processing of the message. The result can then be forwarded along with the message across the module chain from module 120 to module 118, module 116, and application software module 114, where the instructions included in the present security critical message are executed and the action is performed.

[0122] In summary, if a database or other entity associated with the application software module 114 has a message to send to the designated receiving component, the message is passed to the communication stack module 116. If the message is a non-safety critical message, the message is then sent to the designated receiving component via the communication stack module 116 for execution on the receiving module using whatever network or hardware connection is in place. If the non-safety critical message specifies that it is intended for use in the application software module 114 of the host device 102, the communication stack module 116 simply passes the message back to the application software module 114 for execution. If the communication stack module 116 instead determines that the message from the application software module 114 is a safety critical message, the communication stack module 116 determines that the message requires a MAC. The MAC is then sent using Figure 1 The group of horizontal arrows in the lower center are used to pass the message through various modules 116, 118, and 120. As discussed above, at the encryption interface driver 120, the MGAL implementation module 122 is used to determine whether the MGAL policy allows the message to be given a MAC. If the message is authorized, a MAC generation message (such as the MAC generation message described above) is passed to the MAC generation module 109 of the secure peripheral device 104 using the hardware connection 110 (which can be one conductor or multiple conductors). The secure peripheral device generates a MAC, which is returned back to the host device 102 via the hardware connection 112 (which can include one or more conductors). The message is then passed from the modules 120 and 118 to the communication stack module 116. In the case of attaching a MAC to the message, the message is then sent to the designated receiving device for execution.

[0123] Thus, the precise transmission procedures according to aspects of the present disclosure enable the principles of SOA with service discovery in a network while preventing vehicle nodes, messages, or services from being spoofed or otherwise subject to harmful consequences resulting from an attack while inside the in-vehicle network. The KSN may also be used to verify the MAC of a received security-critical message. When the KSN is received as part of a message, the host device 102 may compare it to the expected KSN obtained during the service discovery procedure. If the received KSN does not match the expected KSN, the MGAL implementation module 122 may determine that the received message is not authorized.

[0124] Aspects of the present disclosure also relate to making safety procedures more compact and efficient in entities such as network nodes (e.g., electronic control units or ECUs) of vehicles. The total number of objects and instructions within a node can be reduced without reducing (and in some cases increasing) the effectiveness of high safety techniques within and between nodes. Because these software-equipped ECUs control functions including braking, acceleration, etc., maintaining adequate safety in these situations is of paramount importance.

[0125] At the same time, while these ECU-based systems do a lot to improve efficiency, usability, occupant comfort, driver assistance and reduce costs, previous vehicle families that rely on ECU and / or node-based technologies have historically been difficult to upgrade in a cost-effective manner. For example, automobiles have traditionally suffered from a lack of viable software platforms that abstract the hardware layer, which would otherwise make it easier for developers to write code that is compatible with a specific vehicle type. Alternatively, many ECUs have software written to very low layers, including the physical layer. Similarly, the lack of a tangible, unified platform across applications in existing vehicles and transportation agencies is itself an obstacle to finding effective exploitation of deception or other malicious behavior in vehicle networks. These challenges exist, in part, because different vehicle brands rely on software at different levels, and the industry lacks a standard platform to effectively develop widely parked network software that operates in a recognized and predictable manner.

[0126] Apparently recognizing at least some of these issues, SOA for the automotive industry has recently become popular. To meet demand and facilitate the exchange of critical information, the vehicle becomes a natural candidate for this technology. From a communications perspective, SOA operates on an "on-demand" basis. For example, a sender of data can transmit information if it is known that at least one listener in the network needs the data. Initially, this architecture avoids participating in unnecessary chit-chat that occupies the vehicle's communication system.

[0127] The above advancements are in contrast to previous approaches, where few or no restrictions were placed on transmission instructions. That is, the development of vehicles initially took a data-intensive approach, where the vehicle's primary sensors generated large amounts of data, which in turn was periodically transmitted to different nodes in the vehicle. For example, sensor data was blindly sent between entities, regardless of whether the data had changed. The data was also sent from the point of view of the sending device. That is, if the sender determined that the data was at least marginally relevant, the data was sent, regardless of whether there were actually listeners on the vehicle's network.

[0128] In contrast, in the more recently developed SOA, a more pragmatic approach is taken. The sender transmits data when at least one recipient on the current network needs the data. These limited communications avoid a large number of redundant transmissions, which only consume bandwidth and increase latency even for high-priority messages. In some implementations, a further development advance is that SOA can rely on the presence of middleware. With known middleware in circulation and used in and across SOAs, developers can focus on scalable architectures to design SOA software for vehicles so that the complexity and number of instructions can be proportional to the size and functional complexity level of the vehicle. Scalable service-oriented middleware over IP is responsible for the acronym SOME / IP. Another popular open source middleware is the Automotive Open System Architecture (AUTOSAR), an alliance that includes global automakers as members. To date, AUTOSAR has promulgated solutions that use more customized and unified standards to provide increased flexibility.

[0129] To maximize this flexibility, third party applications can be installed in the vehicle and used in conjunction with the various ECUs. It is important to ensure that such applications are not able to thwart existing security protocols and spoof, for example, the node(s) required for braking, display vehicle key figures such as speed, rpm, etc., or other important tasks, for example, in order to prevent unwanted braking actions by the driver. These are just a few of many examples of why security across these network nodes is important. As noted, ECUs can range from controlling the engine to airbags to brakes, and many other systems. An ECU may often receive inputs that include information about whether to perform a certain task, and after performing some related calculations using that input, the ECU may output data intended for an actuator to allow the actuator to perform another related action based on a defined set of parameters.

[0130] With respect to security, techniques according to the present disclosure subject such security-critical messages to authorization by the MGAL enforcement module prior to being sent to the secure peripheral 104 to obtain a MAC, which are designed to address these same issues that SOAs in vehicles are otherwise susceptible to. Likewise, for messages with a MAC that arrive at a receiving node for execution, aspects disclosed herein rely on the secure peripheral being able to retrieve the correct corresponding key to successfully match the key that originally generated the MAC, thereby providing authorization to the receiving node to execute the corresponding message.

[0131] Existing solutions fall into the category of assigning each V-ECU its own transmission key to prevent spoofing when generating messages, where spoofing in this context involves impersonating another entity to make the recipient of the message believe that the V-ECU is allowed to transmit the present message. The present message actually attempts to perform an unauthorized action, which could be dangerous to the driver if left unchecked. In the case of ECUs, the number of entities or V-ECUs within a single ECU is increasing in many vehicle designs.

[0132] The same logic can be applied to architectures with multiple V-ECUs in a single ECU. Existing designs may also include some type of “crypto engine” built into the exemplary four-V-ECU network host. The crypto engine or MGAL implementation module can be populated with information, or otherwise appropriately configured via hardware, so that the crypto engine knows which V-ECU is making the requests of the four ECUs because the crypto engine knows the keys for each V-ECU. The idea is that if V-ECU 2 attempts to make a request to generate a message authentication code (“MAC”) for a message using a key belonging to V-ECU 3 instead of its own key, the crypto engine will know in advance that the wrong key is being used by V-ECU-2. Therefore, the crypto engine will not let V-ECU 2 generate a MAC to execute an instruction that it is not otherwise allowed to form. Therefore, the request is rejected.

[0133] Until recently, in-vehicle networks used static configurations where there was little or no need to activate mobile sensors or nodes. Therefore, in those cases, it was easy to know what nodes would need to send or receive which messages. In such static configurations, most data exchanges were known in advance, except for system updates. However, even in the latter case, updates were usually for both the transmit and receive circuits.

[0134] The concept of a service-oriented architecture may include information publishers and subscribers. A vehicle user or passenger may choose to subscribe to some services, but the providers and publishers of information may move around over time. This means that in some cases, the owner or driver may need to wait until a new provider is available. Therefore, in this context, the concept of a service-oriented architecture may provide the need to make devices move around and therefore provide the vehicle with discretion to make spoofing and other negative measures difficult against the ECU or other control devices.

[0135] For the long-standing concept of static vehicle architecture, internal security was not a major concern because the critical paths within the vehicle were well known and dedicated hardware was configured to repeatedly perform specific tasks, including moving, shifting, navigating, accelerating, braking, etc. However, the concept of SOA has changed the face of manufacturing, and with these changes, security measures must meet the needs of updating the increasing complexity and capabilities of vehicles. For example, a vehicle user or passenger may choose to subscribe to one or more of the many services provided, which means that the location of (multiple) information provision structures in the vehicle and the physical location of the ECUs or nodes that give and receive instructions can be dynamic and can change in real time. Dedicated connections may be rare. Therefore, with the possibility of such changes, the concept of SOA can create a need to move data and instructions around, and thereby provide the vehicle's electronic equipment with the discretion to do so.

[0136] In this system, where entities (e.g., including plug-in devices (or the location of applications and functions on different processors in the vehicle) move around a lot and they become more dynamic rather than static, this is a growing trend that could make the entities less stressed about the identity of the supplier, which could also change over time based on the movement of these entities within the vehicle. In the case where the entities actually become dynamic, the service provider may not try to follow the random pattern of ECU movement, especially as this trend continues to grow with vehicles. Therefore, in Figure 1 In aspects of the present disclosure illustrated in subsequent figures, spoofing by other nodes can be prevented by using a secure peripheral device 104 in conjunction with an MGAL implementation module 122 in a cryptographic interface driver 120 of a host device 102 to restrict what message types this host device 102 and other nodes in the network can have a legitimate MAC generated for. This information is potentially critical to the reliable operation of the vehicle.

[0137] Additionally, host device 102 may include software components, such as a communication stack, ie, software for communicating with other nodes. Figure 1 The host in is shown coupled to a secure peripheral 104. The secure peripheral 104 may include a MAC verification module 103 and a MAC generation module 109. The MAC verification module 109 has access to a corresponding MAC verification key module 105, while the MAC generation module 109 has access to a MAC generation key module 107. The MAC verification and generation keys are securely stored, and in some embodiments, are stored with the MAC verification module 103 and / or the MAC generation module 109. The secure peripheral 104 may include executable code for performing security-critical functions, generating security messages, managing keys, etc.

[0138] In short, by requiring the transmitting node of a security-critical message to generate a message authentication code (MAC) on the message to be sent using a secure peripheral 104 or cryptographic accelerator module, the problem of nodes (e.g., ECUs) being susceptible to spoofing when achieving SOA-compliant flexibility in a network (e.g., an in-vehicle network) is also mitigated if not addressed. The secure peripheral 104 or another module with access to the secure peripheral 104 or cryptographic accelerator will check the authentication policy in the MGAL implementation module 122 to determine whether the message is allowed to be transmitted by the node. If the message does not have a valid MAC, the receiving node(s) (e.g., another node or ECU located at a different part of the vehicle, whether nearby or not) rejects the message.

[0139] In some embodiments, the MGAL of the MGAL implementation module 122 indicates whether the device (e.g., host 102) attempting to send a message is (1) permitted to be a client that sets or changes a target value, (2) permitted to be a client that reads a value, or (3) instead a server that publishes a value and provides subscriptions. Thus, for example, in the scenarios involving (1) and (2) in this paragraph, the device is a client, and it is the client that polices itself (via the MGAL implementation module) to prevent itself from performing actions that it is not authorized to perform. The device is not a server in (1) or (2), in which case the server is the receiving device of the message.

[0140] Figure 2 is a conceptual diagram of an example ECU 200 including a host device 102 having two processor cores 224 and 226, wherein a first processor core is configured to execute an application software module 114, a communication stack module 116, and an encryption service manager module 118, and wherein a second processor core is configured to execute an encryption interface driver 120 (and an MGAL implementation module 122 therein). Figure 2 The ECU 200 in the embodiment also has a separate safety peripheral device 104a (such as Figure 1 , which may include an encryption accelerator), and otherwise Figure 1 In various embodiments, a processor may include multiple cores such that different functions are dedicated to each core. Figure 2 The exemplary analysis is for simplicity and shows a processor with two cores.

[0141] Figure 2 The node is functionally equivalent to Figure 1224, while the encryption interface driver 120 is executed on another physical core 226. There are benefits to isolating non-safety-critical modules and safety-critical modules on separate cores. Some settings may be assigned to modules on one core versus others. As an example, because the modules on the physical core 224 do not have the ability to interact directly with the secure peripherals 104, the manufacturer can set up the system so that the core 224 only accepts commands and messages to and from the core 226. By configuring the host in this way, MGAL implementation can be ensured in the event that safety-critical messages are generated at the application software module 114 or received at the communication stack module 116. Then, in this example, the core 226 can be dedicated to safety-critical security implementations.

[0142] Figure 3 is an example diagram of a data packet 204.4 used to transfer information between ECUs or other nodes according to one embodiment. The data packet (PDU) 204.4 is for example purposes, and different information items may be transferred between nodes depending on the implementation and purpose. In general, the horizontal direction of the diagram represents time. Figure 3 This involves using different texture maps to represent different fields, thereby transmitting the information shown symbolically.

[0143] As noted, a trusted node in the vehicle network (e.g., in a new or different physical location) can still send transmissions, and the receiving node may still be able to use the MGAL implementation module 122 to authenticate the graph—e.g., the transmitted MAC may include a key sequence number (KSN) 210 (also highlighted as field 212) in its message. The KSNs 210 may be linked to keys stored in a secure peripheral device of the receiving node so that the receiving node can know which keys to use to authenticate the received MAC. The KSN 210 may also be linked to a specific transmitting node, and it will change if the node is moved to a new location where new keys are needed.

[0144] The security PDU header 206 (both SD and non-SD) includes header information related to the SD request type (if applicable) and the KSN 210 embedded in the PDU 204.4, which, as noted, provides a link to the transmit key to be used, which in turn implicitly identifies the node from which the message was transmitted. Following the security PDU header 208 is the SOME / IP serialized payload 208, followed by the KSN 210, followed again by a freshness value ("FV" value) describing the relative freshness (e.g., relative to time or relative to other similar data) of the data 214. The FV 214 is finally followed by the MAC 216.

[0145] The PDU 204.4 above is one of many possible examples, and many PDUs may be used depending on the purpose and goals of the architecture. As noted, certain aspects of the present disclosure require the transmission of a Key Sequence Number (KSN) 210. The data is transmitted between the server ECU and the client ECU over a physical network cable (connected by a TCP protocol (if the data is requested from the server) or a UDP protocol (if the data is requested from the client). Figure 1 The data is transmitted within the vehicle through the middleware (via the application software modules) as conceptually represented by arrows 188 running on the network hardware. In this example, the PDU 204.4 represents a service discovery ("SD") message including a SOME / IP serialized payload 206. The acronym SOME / IP refers to "Scalable Service-Oriented Middleware over IP." As discussed herein, today's vehicles are more feature-rich than other vehicles that employ non-SOA architectures. The reliability of SOA vehicles using ECU-ECU protocols such as CAN and MOST is limited, given the low bandwidth and lack of interoperability of the latter protocols and the vehicles in which they will be used, making the latter primarily suitable for low-functionality vehicles with static and dedicated connections. In contrast, the SOME / IP serialized payload 206 is operable across multiple different units of the ECU. IP refers to the fact that SOME / IP is an Ethernet-based protocol.

[0146] As noted above, the receiving nodes of the message do not need to be concerned with the specific identity of the entity sending the message to them, assuming they are trusted nodes. This makes the entire process of moving nodes easier. At the same time, the sending node still undergoes Figure 1 The system can ensure that a node cannot send messages or data that it is not authorized to send based on the contents of the MGAL policy module or the secure peripheral. From the receiving side, services can be moved without having to rename the moved nodes or reconfigure policies because in the above example, the trustworthiness of the sender is based on whether the MAC ID or service ID they requested appears on the MGAL list. Therefore, nodes can be moved to new locations without losing their validity.

[0147] Figure 4 is a timing diagram illustrating the distinction between nodes in a vehicle that comply with "get" and "set" permissions, according to one embodiment. Figure 4 The functions in can be implemented by a combination of hardware and software. For example, the "get" and "set" schemes (below) can be managed by the processor in conjunction with the encryption interface driver 120 and the secure peripheral device 104.

[0148] Depend on Figure 4The get / set scheme shown provides assurance that when multiple nodes / ECUs within a vehicle are performing functions or implementing features, such as obtaining the vehicle's speed for the purpose of making airbag-related calculations. ECU network 400 is intended to be a micro-portion of an ECU network; however, the scheme is also intended to operate at a much larger capacity. Only three devices on the network are shown to fully convey the principles of this powerful embodiment.

[0149] For the purposes of this example, assume that the client at device A 402 is a node that has been at least partially taken over by a malicious intruder. Device A 402 may, for example, constitute the infotainment system of a vehicle. Assume that the intruder has plugged a black box into a port on the entertainment system in an attempt to modify the vehicle speed to a very high or very low value. Meanwhile, the client corresponding to device B 404 may be an ECU with controls over the accelerator, while the client at device C 406 may be an electronic device that controls a fuel injection system or a battery-powered device to directly accelerate the motor on the device under the right circumstances. In one aspect of the present disclosure relative to the above-described examples, whether a given client only has the right to "get" a value (e.g., read the vehicle speed and / or transmit it) versus whether the client also has the right to "set" a value (e.g., depress the accelerator and increase the vehicle speed) may be determined by Figure 1 The MGAL implementation module 122 controls the application's permissions.

[0150] refer to Figure 4 , the black box inserted into the infotainment system (device A-402) can send instructions to device B 404, which can be used to adjust the accelerator. Device B 404 can get instructions from device A402 (via path 408). Device A 402 can then receive the data, for example, via path 412, after which device A 402 can use path 410 to transfer the data to the recipient device. Based on the KSN or other ID present in the MAC 218 or message, device B can easily determine that client A 402 lacks the authority to "set" values, for example, to set (and effectively change) the speed of the vehicle. In this case, it is assumed that although device A has the "set" privilege to display the vehicle speed and estimated miles per gallon on the infotainment system, the MGAL implementation module 122 knows to prohibit device A 402 from setting or changing the speed, and the malicious attempt of the intruder is frustrated. Client 5404 can reject the request to adjust the speed, as indicated by the thick circle with a diagonal line through it below device B 404.

[0151] Similarly, the client at device B 404 can be identified as the driver's foot pressing the accelerator pedal. This action can initiate a request to device C 406 to set a new speed at device B 406, which is sent via path 416. Therefore, the request to increase the device speed can flow to client C 406. After confirming the validity of the request in the message sent back to device B (404) from device C 406, optionally using path 414, client C and device C 406 can use the KSN or other ID to determine whether the MA 218 attached to the message of device B matches the MAC attached to the message from device B 404. Finally, the infotainment system (device A-402) can send a request to device B to "get" the speed for use in mapping and traffic. Device A, when recognizing that device B is valid for the MGAL implementation policy of "get", can proceed to provide the requested information to device A-402. Therefore, although device A lacks the privilege to adjust the speed, device B is still allowed to display the current speed to device A.

[0152] The above is only one example of "get" and "set" actions that are authorized or prohibited by the relevant MGAL implementation policy. An advantage of this approach is that key actions can be completed with low latency. Another advantage of this approach is that it can adapt to changes in devices. The source of the device is not necessarily important, assuming the MGAL implementation policy matches.

[0153] In short, the use of the principles of the present disclosure enables network elements to be moved to different physical locations without compromising the effectiveness of the network to prevent spoofing attacks and other malicious forms of hacking by maintaining information in the transmitting module. Therefore, vehicle operators or other individuals can enjoy services provided by the same network in different geographical locations, so that only the transmitting nodes need to be updated. The information in dozens or hundreds of receiving nodes can be left alone, and the operator can still provide and exchange common services simply by adding information to a few new transmitting nodes, and without loading data into many receiving devices in the vehicle.

[0154] (1) A shared secret key is established in a node (e.g., an ECU) and stored in the node's secure peripheral in such a way that each node has a dedicated key for transmission and the receiving nodes store the same key to authenticate messages from the transmitting node in their secure peripheral in a way that prohibits the key from being used to generate a MAC. When the transmitting node needs to send a protected message with a MAC, it requests the secure peripheral to generate a MAC and the secure peripheral will use the MGAL to check whether the message is allowed to be sent by the node. If the MGAL indicates that the message is not allowed to be sent, the secure peripheral does not provide a MAC. (2) The secure peripheral will use the bitmask-based MGAL to select which nodes the entry applies to for non-service discovery messages. (3) The table used to build the MGAL configuration for each node will be based on the secure peripheral key sequence number and the key usage flag and organized in a way that entries can be accessed directly with a pointer rather than using a lower performance search algorithm. (4) The secure peripheral will use the configuration options field at the beginning of the options section in the service discovery (SD) header to determine whether SD messages should be allowed to be sent based on the entries in the MGAL. (5) If multiple cores are used and have different access rights, the MGAL is structured in parts for each core as an ordered list of pairs to make it easier to handle. (6) When a protected message is transmitted by a node, it will include the key sequence number (KSN) in the SOME / IP packet to convey the key ID while minimizing the changes required in the communication stack module 116 to process new packets. (7) The SOA message ID is decoupled from the secure peripheral key sequence ID to allow dynamic discovery of services and use of the correct key material at runtime. (8) If the transmitting node needs to be able to provide a new service, the MGAL is updated prior to use via a signature calibration or firmware update authenticated by the secure peripheral.

[0155] The cryptographic accelerator portion of the secure peripheral 104 may be included to perform operations that require very low latency (e.g., protecting messages sent between devices in the vehicle). In addition to separate secure peripherals, some microcontrollers may have dedicated cryptographic accelerators to perform these low-latency operations. These separate cryptographic accelerators tend to have significantly better performance than separate secure peripherals, at least because they are hardware-based and not executing software. However, because the cryptographic accelerator does not execute software, the MGAL implementation software cannot be placed within it. Therefore, in another aspect of the present disclosure, the vehicle can obtain the performance benefits of using a cryptographic accelerator instead of a secure peripheral for such low-latency requests by including the MGAL implementation module in an entity in the host device, and limiting access to the cryptographic accelerator to that entity.

[0156] The principles of the present disclosure are equally applicable to newly installed programs, where a secret key is used to generate a MAC, and a public key is used to verify that the generated MAC is authentic. Therefore, nodes in the network maintain their trusted status even when relocated, with minimal software intervention for one or several nodes.

[0157] Figure 5 A representation 500 of downloading an Android APK to an Android virtual machine of a dual virtual machine to process a firmware update is shown according to one embodiment. That is, Figure 5 An Android virtual machine is shown running along with a Linux virtual machine. The two virtual machines run as a collection 504 on top of a hypervisor, which is a type of hardware that runs on the physical layer of the host. This enables multiple virtual machines to run as clients on a single host. The hypervisor provides a virtual operating platform for the virtual machines and typically manages the system using native hardware. The "u" prefix before several logical blocks in the virtual machine simply specifies the name of the common technology and can be ignored for the purpose of this figure.

[0158] When the vehicle is initially manufactured, it is simple to establish the initial settings and implement the desired MGAL policy. Newer vehicles may have an "app store" where the driver will download applications and services from the app store. For example, the OTA manager and installer 527 can download and install an Android application 502 in the form of an Android package from the Internet. Depending on the nature of the application or service, the application 532 or service 530 can be forwarded across the Android bus 534, where a bridge 538 can be used to segment and stream it (e.g., using SOME / IP). The two virtual machines can cache the SecOC ID value at 518 and 540 for identifying the MAC.

[0159] When the update is done, it is important to ensure that the MGAL (here the SHE compliant TA2 524 and MGAL2 modules 526) is also dynamically updated. Figure 5 is a conceptual description showing the need to have MGAL permission to update MGAL in order for an application to be able to perform authorized functions. So when an Android application is downloaded from an app store, it may be accompanied by a manifest to which the virtual machine may add metadata. This data may include (for example here) the name and value of the MGAL, and the ID and number of the various functions it can perform as a server for client services that it can perform. The goal at this point is that the Android application will have the required MGAL information so that no matter what trusted application is implementing MGAL, it can obtain the information from the designated logistics department where the private key authorizing MGAL updates is held.

[0160] In other words, the Android app will have the information needed so that whatever trusted app is doing the implementation of MGAL, the trusted app will get the relevant information and the signature generated by the vehicle's back office. Back office has the private key for the update so that it has access to the signature and thereby authorizes the action. Figure 5 , if a user tries to make their own malicious application and install it on the vehicle with multiple permissions, they cannot compromise the system in this way because they are not allowed to sign private keys. The keys are protected in the hardware security module and cannot be signed without authorization. Each virtual unit can include a corresponding MGAL unit, such as a SHE-compliant TA 1520 storing an MGAL 1 module 522 for use in a Linux virtual machine, and a SHE-compliant TA2624 storing an MGAL 2 module 626 for use in an Android virtual machine.

[0161] The entity implementing MGAL has a public key associated with the signing key. Therefore, the public key can be used to verify (but not create) the signature of the updated application. In this way, the system knows whether the requested permission is actually authorized by the logistics department. Through this tool, it is possible to verify that the entity executing MGAL has the public key used to verify the signature. Unverified signatures are considered to be malicious attempts to deceive the trusted logistics department.

[0162] The term "TEE IDs" in Android update 502 stands for "Trusted Execution ID". Multiple trusted IDs can be used at the same time. When the Android update 502 enters the OTA manager / installer 528, the installer 528 can use dynamic MGAL update (DynaMGALupdate) (MGALinfo) data to transmit MGAL information to MGAL2. For example, a public key can be used at MGAL 2 to verify the trusted execution ID. Similarly, an update (not shown) can be provided to a Linux virtual machine and received at the OTA manager / installer 506. The data can be forwarded via the application module 508 or the service module 510, via the bus 512 and the streamer 514 when applicable, and then packaged using the Some / IP protocol described above. At the same time, the OTA manager / installer 506 can provide MGAL information corresponding to the relevant metadata, which can be checked at MGAL1 with a SHE-compliant TA 1520.

[0163] Multiple trusted applications can be executed simultaneously. Linux virtual machines can each run with their own MGAL, because for example on the Android platform, infotainment type actions can be run, and therefore there is a need to have separate licenses, because the Linux environment may be able to issue certain messages that are not allowed by Android.

[0164] It should be noted that because Linux and Android run on top of a hypervisor, which in turn executes on hardware, memory access may require additional steps. For example, if a Linux application needs to access memory, Linux will first go through the hypervisor. Linux and Android machines run on top of a hypervisor, which in turn runs on hardware. Therefore, if a Linux virtual machine wants to access memory, Linux first goes through the hypervisor, which controls what resources the Linux machine can access. The hypervisor is a layer that ensures the two virtual machines are together.

[0165] The APK flows through the VM, and at the end (MGAL), the MGAL ensures that the data is authentic. For example, a SHE-compliant TA1 can check the signature to ensure the update went through. CCU stands for Cyclic Computation Unit.

[0166] Figure 6 FIG. 6 shows a representation of a dynamic MGAL update module 600 using relevant information of two virtual machines on a computer according to one embodiment. Figure 5 An embodiment of Figure 6 A set 604 of virtual machines (here two): Linux and Android. In this embodiment, Linux is executed on a system on a chip (SoC) in the ECU. Figure 5 The one that is different, Figure 6 The slightly more difficult security task of uninstalling a program while ensuring that the program's resources are not compromised by malicious actions is shown. The Linux virtual path includes an over-the-air (OTA) manager / installer 606, an application module 608 (for processing applications), a service module 610 (for processing services), a bus 612 for coupling applications and services to a streamer 614, and an encapsulation unit 616 (e.g., for dividing data into data units). Both encapsulation units 516 can have access to SecOC 518 and 520 to verify the MAC. The Android virtual path includes an OTA manager / installer 628, an application module 632 (for processing applications), a service module 630 (for processing services), a bus 634 for coupling applications and services to a streamer 636, and an encapsulation unit 638 including a SecOC 640. Each virtual unit may include a corresponding MGAL unit, such as a SHE-compliant TA 1 620 storing an MGAL 1 module 622 for use in a Linux virtual machine, and a SHE-compliant TA 2 624 storing an MGAL 2 module 626 for use in an Android virtual machine.

[0167] Maintaining security and functionality when dynamically uninstalling programs means that the dynamic MGAL 602 should include not only each of the versions and identities of the software, but also metadata, including services, service IDs, clients, and client IDs. The uninstaller needs to track which pass has permission to access which service ID. The entity performing the MGAL implementation tracks which service licenses are associated with which applications to be able to prevent the removal of required licenses that may be in use by authorized applications. If the MGAL does not track service licenses for different programs / versions, then when a version is uninstalled, it becomes unclear whether other licenses associated with that version should or should not be removed.

[0168] Thus, in one aspect of the present disclosure, the dynamic MGAL 602 is perused when installation occurs. For example, if uE ID2 / v3 is removed, service ID $1234 is retained because uE ID2 / v2 remains installed and also uses that service ID. In contrast, if uE ID2 / v3 is uninstalled, $1235 can be deleted because no other active applications are using that service / service ID. The result is a streamlined list of applications in which only the required metadata is retained.

[0169] refer to Figure 5 and Figure 6 , a shared secret key is established in a node (e.g., ECU) and stored in the node's secure peripheral in such a way that each node has a dedicated key for transmission, and the receiving nodes store the same key to verify messages from the transmitting node in their secure peripheral in a way that prohibits the key from being used to generate a MAC. When the transmitting node needs to send a protected message with a MAC, it requests the secure peripheral to generate a MAC, and the secure peripheral will use MGAL to check whether the message is allowed to be sent by the node. If the MGAL indicates that the message is not allowed to be sent, the secure peripheral does not provide a MAC. The secure peripheral can use the bitmask-based MGAL to select which nodes this entry applies to for non-service discovery messages.

[0170] The table used to build the MGAL configuration for each node can be based on the secure peripheral key serial number and key usage flags, and organized in a way that enables entries to be accessed directly with pointers rather than using a lower performance search algorithm. The secure peripheral can use the configuration options field at the beginning of the options section in the service discovery (SD) header to determine whether SD messages should be allowed to be sent based on the entries in the MGAL.

[0171] If multiple cores are used and have different access rights, the MGAL is structured in parts for each core as an ordered list of pairs to make it easier to handle. When a protected message is transmitted by a node, it will include a key sequence number (KSN) in the SOME / IP packet to convey the key ID while minimizing the changes required in the communication stack module 116 to process new packets. The SOA message ID is decoupled from the secure peripheral key sequence ID to allow dynamic discovery of services and use of the correct key material at runtime. If the transmitting node needs to be able to provide a new service, the MGAL is updated via a signature calibration or firmware update authenticated by the secure peripheral before use.

[0172] Figure 7 is a hardware representation of a node 700 in one aspect of the present disclosure, to which the principles of the present disclosure may be applied. Figure 7 This can be a transmitting node or a receiving node such as an ECU. Figure 7 Including host device 702. In some embodiments, such as in secure peripheral device 704, it is not necessary Figure 7 Each element of the structure shown in . Node 700 may include a processor 721, which may actually include one or more processors, general-purpose processors, RISC (reduced instruction set computer) processors, digital signal processors (DSPs), or processing devices that can implement functions and / or instructions entirely in software, partially in software, or in a mixture of hardware and software. The processor is coupled to a memory 723, which may be a dynamic random access memory (DRAM), a static random access memory (SRAM); a non-volatile memory (e.g., for storing KSN during a service discovery period), a disk drive, a solid-state drive, other non-volatile memory, a cache memory, or some combination of different types of memory, including those described above. For example, the receiving node may also include one or more sensors 725 for measuring and reporting results in the vehicle. To this end, such a receiving node may cover a wide range of sensor types and may be used in ECUs and transmitting nodes in some cases.

[0173] Node 700 may also include a transceiver 728 for sending and receiving messages to other nodes in the network via a compatible vehicle wireless medium. As noted, some ECUs have keys for generating or verifying MACs. In order to avoid making the scope of this disclosure overly ambiguous, both are shown here as examples. A secure peripheral 733 for MAC generation and an accompanying MGAL may be found in or coupled to a host node as part of an ECU. Separately, element 735 is a module for MAC verification. In some configurations including secure peripherals, both modules 735 and 733 may be found in a single secure peripheral. In other configurations, they are divided into different elements. The MAC generation peripheral 733 may also include a MAC engine 731 for executing low-level commands.

[0174] The detailed description and the accompanying drawings or figures support and describe the present teaching, but the scope of the present teaching is limited only by the claims. Although the best mode and some of the other embodiments for implementing the present teaching have been described in detail, there are various alternative designs and embodiments to practice the present teaching defined in the appended claims. In addition, the present disclosure explicitly includes the combinations and sub-combinations of the elements and features presented herein.

Claims

1. A system for authorizing messages in a service-oriented vehicle architecture, comprising: Security peripherals; and a host device coupled to the secure peripheral device and comprising a processor configured to execute code in a local memory therein to generate a cryptographic interface driver configured to determine whether the host device is authorized to send a security-critical first message from the host device to a receiving device by maintaining a message authentication code (MAC) generation allow list (MGAL) implementation module at the host device, the MGAL implementation module for receiving a first identifier (ID) for determining whether the first message is authorized, and for enabling the host device to provide a MAC generation message including the first identifier (ID) to a MAC generation module executing on the secure peripheral device when the first message is authorized, wherein The MAC generation module of the secure peripheral device is also configured to retrieve the corresponding first key based on the first ID, generate a first MAC based on the corresponding first key, and send the first MAC to the encryption interface driver of the host device, and the host device is configured to send the first message together with the first MAC to the receiving device. 2 . The system of claim 1 , wherein when the first message is not authorized, a MAC generation module of the secure peripheral device is unable to recognize a key and refrains from generating a MAC.

3. The system of claim 1, wherein: When the host device receives the security-critical second message together with the second ID and the second MAC from the sending device, the cryptographic interface driver is configured to determine whether the sending device is authorized to send the second message to the host device by enabling the host device to send the second ID and the second MAC together with a key serial number (KSN) for identifying a key to be retrieved to a MAC verification module executed within the secure peripheral device, wherein When the MAC verification module uses the KSN to retrieve the corresponding second key in the secure peripheral device, the secure peripheral device determines that the second message is authorized; and When the MAC verification module cannot identify the corresponding second key using the KSN, the secure peripheral device determines that the second message is not authorized.

4. The system according to claim 1, wherein: The MGAL enforcement module includes an authentication policy to determine whether transmission of a message is allowed.

5. The system of claim 1, wherein the first ID comprises a secure onboard communications data identifier (SecOCDataID).

6. The system of claim 1, wherein the processor is configured to cause the cryptographic interface driver to have exclusive access to the secure peripheral device for messages to be sent from the host device or received from a sending device.

7. The system of claim 1, wherein the processor is further configured to execute code to include: a cryptographic services manager module operatively coupled to the cryptographic interface driver for communicating security critical message types requiring MAC verification or MAC generation to and from the secure peripheral device via the cryptographic interface driver; a communications stack module operatively coupled to the cryptographic services manager module for communicating non-safety critical message types to and from other vehicle devices and for communicating safety critical message types to and from the secure peripheral device via the cryptographic interface driver; and an application software module operatively coupled to the communication stack module for executing one or more software applications for performing one or more corresponding functions based on the non-safety critical message type and the safety critical message type communicated from the communication stack module, Only the encryption interface driver can interface with secure peripheral devices.

8. A system according to claim 1, wherein the first identifier (ID) together with the first message transmitted from the host device to the secure peripheral device also includes a key serial number, and the key serial number is configured to identify the type of service associated with the first message and determined during an earlier service discovery period.

9. The system of claim 1, wherein: The host device also includes a non-volatile memory coupled to the local memory; The host device is further configured to participate in a service discovery procedure, wherein one or more key serial numbers (KSNs) are stored in the non-volatile memory, each of the one or more KSNs corresponding to a server configured to provide a specified service, or a client subscribed to receive a specified service; Following the service discovery procedure, any data and any remote procedure call received by the host device corresponding to one of the designated services that is not accompanied by a corresponding KSN of the one or more KSNs stored in the non-volatile memory is rejected.

10. The system of claim 1, wherein: The MGAL implementation module of the host device is configured to determine a permission of the host device based on the first ID, the permission comprising: (1) Whether the host device is authorized to act as a client to set or change the target value; (2) whether the host device is authorized to act as a client to read the target value; and (3) Whether the host device is authorized to act as a server to publish values ​​or provide subscriptions, and When the MGAL implementation module determines according to (1) or (2) that the host device is authorized to act as a client, the host device uses the MGAL implementation module to determine whether security-critical messages generated thereafter by the host device are authorized.

Images