System for authorizing messages in a service-oriented vehicle architecture

Abstract

An electronic control unit (ECU) or node is configured to use a single key for generating MAC requests from a security peripheral. The security peripheral contains the stored shared key. The security peripheral may also contain a policy that allows it to determine whether a request from the ECU is valid and, if so, generate a MAC. The security peripheral is also used to store information in a MAC Generate Allow List (MGAL). In some embodiments, receiving nodes in a network receive data based on the security peripheral's response to a transmitting node's MAC request. The receiving nodes use this knowledge to prevent spoofing.

Description

[0001] Modern vehicles have experienced technological advances in the amount of electronics and software relevant to both performance and luxury criteria. Electronic control units (ECUs), for example, are used in greater numbers as embedded systems within the vehicle, controlling various electromechanical systems. Modern vehicles contain various ECUs to control a wide variety of different vehicle systems, from engine management to entertainment devices.

[0002] Service-Oriented Architecture for Vehicles ("SOA") has advanced the development of ECU technology in vehicles by transforming much of the voluminous code in the more than 100 ECUs of modern vehicles into better-defined middleware. SOA includes specific components that 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, leading to greater software portability and a simpler development process. Similar to computing, SOA hides more abstract layers and makes it easier for multiple third-party developers to port software applications to different parts of the ECU network.

[0003] Vehicle SOAs pose significant security concerns. Previous vehicle implementations were hard-wired, or at least configured to transmit high-priority messages over dedicated, known data lines between ECUs. In contrast, SOAs offer various possible implementations and rely on a service discovery period for the various processing circuits to learn the sources of safety-critical messages. This architectural flexibility can lead to spoofing and other malicious attacks, where foreign devices connected to the vehicle network send spoofed safety-critical messages to a target device in the vehicle to apply the vehicle brakes, change the vehicle speed, or perform other unauthorized and potentially dangerous actions.

[0004] If not addressed properly, an on-board mesh can lead to malicious third-party code attempting to spoof other legitimate nodes, causing the vehicle to perform actions with unintended consequences.

[0005] DE 10 2017 219 661 A1 describes a method for operating a control unit in which data is transmitted with the aid of software, wherein end-to-end protection is carried out and a safety which checks the data with regard to functional safety using monitoring software and modifies it if necessary, and a security which has access to at least one key for cryptographic functions are taken into account, wherein the safety is provided transparently between a calling component and the security so that the data can be checked by the safety even though it is protected by the security.

[0006] DE 10 2021 117 500 A1 describes a device for secure communication between control units in a vehicle, as well as a correspondingly equipped electronic control unit and a vehicle. The control units are each equipped with at least one communication interface via which they can be connected to a first part of a wired vehicle bus system for exchanging messages. The device is characterized in that at least one secured control unit is provided that is connected to the vehicle bus system, wherein the secured control unit is provided with at least one further communication interface to which a separate part of the vehicle bus system is connected.The protected control unit is provided with a gateway function and security equipment that fulfils at least the function of a firewall, which fends off attacks from the first part of the vehicle bus system (on one of the control units in the separated part of the vehicle bus system).

[0007] Specification of Crypto Driver AUTOSAR CP R22-11, AUTOSAR, November 24, 2022, pages 1-125 describes the Crypto Driver program.

[0008] The invention is defined by the independent claim.

[0009] According to the invention, a system for authorizing messages in a service-oriented system is provided, comprising a security peripheral and a host device coupled to the security peripheral, the host device comprising a processor configured to execute code in local memory to generate a crypto interface driver, wherein the crypto interface driver is 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 generate allow list (MGAL) enforcement module in the host device, the MGAL enforcement module to enable the host device to provide a MAC generation module executing on the security peripheral with a MAC generation message comprising a first identifier, ID, if the first message is authorized,The MAC generation module of the security peripheral device is configured to retrieve a corresponding first key based on the first ID, to generate a first MAC based on the corresponding first key, and to send the first MAC to the crypto interface driver of the host device, and the host device is configured to send the first message along with the first MAC to the receiving device. The processor is further configured to execute code to include: a crypto service manager module operatively coupled to the crypto interface driver for forwarding security-critical message types requiring MAC verification or MAC generation to and from the security peripheral device via the crypto interface driver; a communication stack module;which is operatively coupled to the crypto service manager module for forwarding non-safety-critical message types to and from other vehicle devices and for forwarding the safety-critical message types to and from the safety peripheral via the crypto interface driver; and an application software module operatively coupled to the communication stack module for executing one or more software applications. The one or more software applications for performing one or more corresponding functions are based on the non-safety-critical and safety-critical message types forwarded by the communication stack module. Only the crypto interface driver is capable of interfacing with the safety peripheral.

[0010] According to one embodiment, if the first message is unauthorized, the MAC generation module of the security peripheral is unable to identify a key and refrains from generating a MAC.

[0011] According to another embodiment, when the host device receives a security-critical second message along with a second ID and a second MAC from a sending device, the crypto 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, to identify the key to be retrieved to a MAC verification module executing within the security peripheral. If the MAC verification module uses the KSN to retrieve a corresponding second key in the security peripheral, the security peripheral determines that the second message is authorized.If the MAC verification module cannot identify a corresponding second key using the KSN, the security peripheral determines that the second message is unauthorized.

[0012] According to another embodiment, the MGAL enforcement module includes an authentication policy to determine whether a message may be transmitted.

[0013] According to a further embodiment, the first ID comprises an identifier for the secure communication data on board, SecOCDataID.

[0014] According to another embodiment, the processor is configured so that the crypto interface driver has exclusive access to the security peripheral for messages sent by the host device or received by a sending device.

[0015] According to another embodiment, the processor comprises a plurality of processor cores, wherein at least one processor core of the plurality is configured to execute code comprising the one or more software applications, the communication stack module, and the crypto service manager module; and another processor core of the plurality comprises the security peripheral.

[0016] According to another embodiment, the first identifier, ID, along with the first message transmitted from the host device to the security device, further comprises a key serial number, wherein the key serial number is configured to identify a service type associated with the message and determined during a previous service discovery period.

[0017] According to another embodiment, the host device and the security peripheral device are parts of the same integrated circuit.

[0018] According to another embodiment, the host device functions 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 prevent the second client device from setting or changing the target value.

[0019] In one example, a system for authorizing messages in a service-oriented vehicle architecture includes a plurality of nodes, each node including a security peripheral; and a host device coupled to the security peripheral and including a processor configured to execute code in a local memory thereof to generate a crypto interface driver, wherein the crypto interface driver is 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 permission list MGAL enforcement module at the host device, the MGAL enforcement module to enable the host device to provide a MAC generation message to a MAC generation module executing on the security peripheral,containing a first identifier, ID, wherein, if the first message is authorized, the MAC generation module of the security 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 crypto interface driver of the host device, and the host device is configured to send the first message together with the first MAC to the one of the receiving nodes.

[0020] In one example, the MAC generation module of the security peripheral is unable to identify a key if the first message is unauthorized and refrains from generating a MAC. 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 crypto interface driver is further 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 the key to be retrieved to a MAC verification module executing within the security peripheral, wherein, when the MAC verification module uses the KSN to retrieve a corresponding second key in the security peripheral,the security peripheral determines that the second message is authorized, and if the MAC verification module cannot identify a corresponding second key using the KSN, the security peripheral determines that the second message is unauthorized.

[0021] In one example, the MGAL enforcement module contains an authentication policy to determine whether a message may be transmitted. The first ID contains an identifier for the onboard secure communication data, SecOCDataID. A host device contains an Android virtual machine running on a hypervisor. The host device downloads an Android package. A private key authorizes the Android package's manifest to be populated with fields and signs the manifest, and a public key corresponding to the private key verifies the signature.

[0022] In one example, the MGAL enforcement module initiates an uninstallation of a version of a dynamic MGAL, where the MGAL optionally deletes service information corresponding to the uninstalled version if the uninstalled version is the only application with the service information; and the MGAL optionally preserves the service information corresponding to the uninstalled version if the uninstalled version is not the only application with the service information. The host device includes a plurality of virtual machines running over a hypervisor. The host device includes a security module for generating a verification key and a separate security module for generating a generation key, where the generation key is for generating the MAC in accordance with the MGAL policy.

[0023] The above summary is not intended to describe every embodiment or aspect of the present description. Rather, the above summary is merely an exemplary illustration of some of the novel concepts and features set forth herein. The above features and advantages, as well as other features and associated advantages of this description, will be readily apparent from the following detailed description of illustrated examples and representative modes for carrying out the present description when considered in conjunction with the accompanying drawings and the appended claims. Furthermore, this description expressly includes the various combinations and subcombinations of the elements and features set forth above and below.

[0024] The accompanying drawings, which form a part of this description, illustrate embodiments of the description and, together with the description, explain the principles of the description. Fig. 1 is a conceptual diagram of an example electronic control unit (ECU) with a host device and a safety peripheral implemented using a service-oriented architecture (SOA) of a vehicle. Fig. 2 is a conceptual diagram of an example controller including a host device with two processor cores, the first processor core configured to execute the application software module, the communication stack module, and the crypto service manager module, and the second processor core configured to execute the crypto interface driver. Fig. Figure 3 is an example of a timing diagram of a data packet. Fig. Figure 4 is a timing diagram illustrating the distinction between get and set permissions for nodes in a vehicle. Fig. Figure 5 shows an illustration of downloading an Android application package (APK) to an Android virtual machine of a dual virtual machine processor for handling firmware updates. Fig. Figure 6 shows a representation of a dynamic MGAL update using relevant information with two virtual machines on one computer. Fig. 7 is a hardware diagram.

[0025] The accompanying drawings are not necessarily to scale and may represent a simplified representation of various features of the present specification as described herein, including, for example, specific dimensions, orientations, positions, shapes, and scales. The details associated with these features will be determined in part by the particular intended application and environment of use.

[0026] This description may be embodied in many different forms. Representative examples of the description are illustrated in the drawings and are described in detail herein as non-limiting examples of the principles described. To this end, elements and limitations described in the "Summary," "Introduction," "Summary," and "Detailed Description" sections, but not expressly set forth in the claims, should not be incorporated into the claims, either individually or collectively, by implication, inference, or otherwise.

[0027] For the purposes of this description, the use of the singular includes the plural and vice versa, unless expressly excluded; the terms "and" and "or" apply both subjunctive and disjunctive; and the words "including," "containing," "comprising," "having," and the like mean "including without limitation." For example, "optimal vehicle routes" may encompass one or more optimal vehicle routes. Furthermore, words of approximation such as "approximately," "almost," "substantially," "generally," "about," and so on may be used herein to mean "at, near, or almost at," or "within 0-5% of," or "within acceptable manufacturing tolerances," or logical combinations thereof.A component "configured" to perform a specific function is capable of performing that specific function without modification, rather than merely having the potential to perform that specific function after further modification. In other words, if the described hardware is expressly configured to perform the specified function, it is specifically selected, created, implemented, used, programmed, and / or designed to perform the specified function.

[0028] The principles of this description relate to vehicular networks and nodes and their particular vulnerability to spoofing and other malware attacks when the vehicle is implemented in an SOA-based network environment that utilizes a variety of host devices to perform various functions. According to certain aspects, this vulnerability can be addressed and the problem solved by using a security peripheral / crypto accelerator (hereinafter referred to simply as a "security peripheral") to verify the integrity of security-critical messages and generate a message authentication code (MAC) for each of the transmitting nodes over the message to be sent.For the purposes of this description, safety-critical messages may include any message sent from a sending device to a receiving device that performs functions that require safety verification, including, but not limited to, message types that involve performing physical actions or functions such as braking, accelerating, setting various values ​​that other devices may rely on, and performing standard safety-related functions necessary to prevent damage to the vehicle or harm to the vehicle's occupants.

[0029] Physically, the host device is a hardware component or part thereof that can be implemented, for example, with a processor and other components in a control unit in the vehicle. The safety peripheral is also a hardware component or part thereof and can be physically implemented in various ways. For example, the safety peripheral can be located on a different section of the same integrated circuit on which the host device is housed. In other embodiments, the safety peripheral can be implemented on a separate integrated circuit and physically coupled to the host device. In still other embodiments, the host device and the safety peripheral can be embedded in different housings and connected to each other via wiring.

[0030] Fig. 1 is a conceptual diagram of an example control unit 100 having a host device 102 and a safety peripheral 104 implemented using a service-oriented architecture (SOA) in a vehicle according to various embodiments. The control unit 100 includes a host device 102. The host device may include one or more processors, microcontrollers, and memory (see Fig. 4). The host device 102 is connected to a security peripheral 104. In various embodiments, the security peripheral 104 includes a crypto accelerator, described further below. The controller may also be referred to as a node. For the purposes of this description, a node may be a controller or any processor within the device that includes the security measures described further below.In one aspect of the description, a security peripheral 104 (or possibly another higher-privileged module or core with exclusive access to the security peripheral 104 (which may also include a crypto accelerator)) within a transport node in a vehicle or other transport mechanism (e.g., a control unit 100 or another processor or node) may perform internal monitoring using a policy present in the MGAL enforcement module 122 that ensures that the secret keys within the control unit 100 cannot be used to generate a MAC over messages that the control unit 100 / node is otherwise not authorized to send. A more detailed description of this innovation is provided below with reference to FIG. Fig. 1 given.

[0031] An ECU is a device in a vehicle that controls one or more of the vehicle's electrical systems. The ECU instructs the vehicle how to operate. In most cases, the core of an ECU consists of 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 assist in performing ECU functions and simulations, but can be implemented purely in software, for example, on an ECU's microprocessor. V-ECUs have the advantage that vehicle functions can be tested in the laboratory using microcontrollers before the functions are deployed, for example, in vehicles for sale. Any instance of the V-ECU can be easily deployed with the test solution, after which its functionality can be thoroughly tested.For sophisticated control units, V-ECUs can be used as independent units within the system to perform authorized tasks.

[0032] As a short introduction to the functionality of the circuits in Fig. 1, the MAC generation module 109 is used in conjunction with the MGAL (MAC Generate Allow List) enforcement module 122 when an application in the application software module 114 of the host device 102 generates a security-critical message and sends (via the communication stack module 116, the crypto service manager module 118, and the crypto interface driver 120 in the host device 102) a request to generate a MAC for use over a secure (security-critical) message that the host device 102 wishes to send to a target ECU (node) or virtual ECU (within a node).(If the message is not safety-critical, the communications stack module 116 sends the non-safety-critical message back to the application software module 114 for execution by an application, or if the request is intended for a different node, the communications stack module 116 instead sends the non-safety-critical message over a network (conceptually indicated by one of the arrows 188) for execution by the intended receiving node or the controller. If the request is a safety-critical request intended for a different node, the request requires a MAC. The following is a non-exhaustive explanation of how an authorized, safety-critical message receives a MAC. In addition, the following excerpts describe how and when safety-critical messages are considered unauthorized and rejected accordingly.

[0033] The configuration in Fig. 1 is a hardware / software-based ECU solution that, when active, tends to reduce the cost of the entire network nodes without losing their capabilities. The host device 102 can initiate the process by sending a MAC generation request (received at the communication stack module 116, as explained further below) over the hardware connection 110 to the MAC generation module 109 of the separate security peripheral 104a. However, the information sent over the hardware connection 110 from the host device 102 to the MAC generation module 109 depends on whether the message meets the relevant policies of the MGAL enforcement module 122 of the crypto interface driver 120 in the host device, as explained further below.If the MGAL enforcement module 122 authorizes forwarding of the security-critical message to obtain a MAC (which in turn authorizes execution at a receiving node), a MAC generation message is first sent to the MAC generation module 109 over the hardware connection 110. The MAC generation message may also include criteria such as the message identifier (referred to as SecOCDataID in this configuration), the KeySlotNum ("key slot identifier"), and other security-related information elements. The host device 102, in some embodiments, may also include the MAC data, which may include the service type, the type of data being transmitted, and so on.In another embodiment, the MAC generation module 109 may use hardware to examine the relevant contents of the MGAL enforcement module 122 and, based on the MAC ID, determine whether a MAC can be generated for the host device 102 based on the host's history and related factors. For example, the MAC generation module 109 may further examine the historical records of the MGAL enforcement module 122 (in embodiments where they are available) in which the MAC IDs are listed. In other configurations, the MGAL announces one or more policies about which nodes / ECUs were previously permitted to send which messages to which modules on which topic. In the first embodiment, if the MAC ID is not listed in the MGAL, the MAC generation module 109 may not generate the MAC and returns an error.If the MGAL information shows that the message is authentic and the host device 102 is safe, the MAC generation box can retrieve a key from the MAC key generation module 107, generate a MAC, and send it back to the host via the hardware connection 112. As previously mentioned, the receiving nodes can be alerted to the generation of the MAC (or lack thereof) for that device. Based on this and similar background information, the receiving nodes can ultimately learn which devices can and cannot be trusted, based on which MAC IDs or in general.

[0034] The MAC verification module 103 may instead be used when the host device 102 has received a message from another node in the network, such that the other node wants the host device 102 to perform the function in the message. To verify the authenticity of the MAC, the host device 102 may take the received MAC and send a MAC verification message and factors similar or identical to those listed above with reference to the hardware connection 110 to the MAC verification module over the hardware connection 106. If the MAC verification module 103 determines that the MAC is a forgery, it does not return a MAC, and the host device 102 may reject the request.Otherwise, if the MAC verification module 103 finds or retrieves a key from the MAC verification key module 105 that matches a key serial number in the provided MAC verification message, the MAC verification key module 105 may use the retrieved key serial number to generate or find the corresponding MAC and return the retrieved MAC to the host device 102 via the hardware connection 108.

[0035] While the host device 102 and the safety peripheral 104 may be encapsulated in an ECU 100 or similar module, this configuration is not required, and in some embodiments, no ECU is used. Further, for the purposes of this description, the term "processor" may refer to more than one processor. The term "processor" may refer to any type of controller or microcontroller for performing various tasks. In some cases, at least a portion of the processor may be specialized hardware, such as a digital signal processor (DSP). The processor may also be available as, or implemented (partially or entirely) within, an application-specific integrated circuit (ASIC), a system on a chip (SoC), combinational Boolean logic circuits that perform the required digital functions, and so on.The transistors used in the processor may be complementary metal oxide semiconductor (CMOS) technology, bipolar transistors, gallium arsenide transistors, or a combination of these. The processor may execute middleware, and in some embodiments, may rely, at least in part, on one or more application programming interfaces to communicate with other systems. The processor may also include updatable firmware, as described herein. In addition, the hardware portion of host device 102 may also include local memory 723 (. Fig. 7). The local memory 723 ( Fig. 7) may be connected to the processor 721 to store data and code, including executable code that enables the processor to perform the various Fig. 1. Memory 723 may be any form of volatile and / or non-volatile memory, including, but not limited to, dynamic random access memory (DRAM), static random access, and the like. Host device 102 may also include other forms of memory 723, including non-volatile computer-accessible memory or solid-state drives for longer-term data storage, as well as NAND and NOR-based flash memory, which are also typically non-volatile. Memory 723 may be adapted to form any database or repository, or a combination thereof, for use in the EPC.

[0036] Back to Fig. 1: The host device 102 includes at least one processor and a processor-local memory for executing code that performs various functions described in Fig. 1 as the application software module 114, the communications stack module 116, the crypto service manager module 118, and the crypto interface driver 120. Each of the modules 114, 116, 118, and 120 within the host device 102 is separated by bidirectional arrows. These arrows represent the conceptual flow of information with and interaction between the various modules (sometimes referred to as layers) as they each execute as one or more threads of execution on the core(s) of the one or more processors.

[0037] With the application software module 114 from Fig. 1, the host device 102 may be populated with one or more low-level applications. For example, if the control unit 100 is dedicated to a specific function, such as reading and providing engine temperature data to other control units, the application software module 114 may be configured to perform that function and provide output data to the communication stack module 116 via the lower horizontal arrow. The application software module 114 may also receive data from other control units via the communication stack module 116 using the upper horizontal arrow. The communication stack module 116 may, in some implementations, function like a network layer, with data being transferred to and from the host device 102 over a physical network such as Ethernet (or any other network implementation).Data received at the communications stack module 116 and intended for one of the local applications running in the application software module 114 may be forwarded to the module 114, as represented by the conceptual input arrow 188. If the application software is configured to output data from the host device 102, the application in question may forward the device to the communications stack module 116, where the data is then forwarded to the conceptual output arrow 188. The arrows 188 collectively represent a path for transferring data to and from other control devices on the communications stack module 116.

[0038] It is clear that the application software module 114 does not have direct access to the safety peripheral 104. Therefore, the application software module 114 can perform low-privileged, non-critical functions and forward the results to the communication stack module 116 for transmission elsewhere in the vehicle. Non-safety-critical functions are generally functions that do not adversely affect the control of the vehicle and do not convey misinformation to the driver that could lead to an external force event, breakdown, or other problem. This is in contrast to safety-critical messages, which may include messages instructing the vehicle to accelerate, brake, or perform another potentially critical function.As mentioned earlier, in the SOA configuration, various plug-ins, custom ECUs, and other processing or control devices can be dynamically added or removed throughout the lifetime of the vehicle or other transport mechanisms. Unlike existing static, hard-wired vehicle configurations, where dedicated messages run over dedicated wires, leaving little doubt as to the origin of the message, the more flexible SOA requires that security-critical messages or data from a sending ECU (or transmitting node) be accompanied by a verifiable message authentication code (MAC), allowing the receiving node to use its own security enforcement hardware and software to verify that the message is authorized before the receiving node responds to it.If this were not the case, a malicious user in an SOA (for example) could connect a plug-in device to the vehicle's infotainment system. The plug-in system could, in turn, send an unauthorized safety-critical message to a receiving node responsible for applying the vehicle's brakes. Without the MAC authorization requirements, the plug-in module could spoof the receiving node that randomly applies the brakes, potentially resulting in a dangerous crash.

[0039] Unlike non-safety-critical messages, safety-critical messages must be accompanied by the corresponding MAC, which can be generated from private keys stored within the security peripheral and verified for authenticity. Aspects of these measures, where the application software layer 114 executes a safety-critical task to be sent to another control device or receives a safety-critical message, are discussed further below.

[0040] The host device 102 also includes a crypto service manager module 118. The crypto service manager module 118 is a software module generated by executable code of the processor. The crypto service manager module 118 is operatively coupled to the communication stack module 116 and the crypto interface driver 120 via the two sets of four horizontal, bidirectional lines connected to the crypto service manager module 118. These bidirectional lines are shown to illustrate that the crypto service manager module 118 is capable of sending and receiving messages to and from the communication stack module 116 and the crypto interface driver 120. The significance of this operative coupling will be discussed further below.

[0041] Like modules 114 and 116, the crypto service manager module 118 is configured (in and of itself) to send and receive non-safety-critical messages. Like modules 114 and 116, the crypto service manager module 118 does not have access to the security peripheral 104. In one embodiment, the crypto service manager module 118 may receive messages from the communication stack module 116 and forward those messages to the crypto interface driver 120. Furthermore, the crypto service manager module 118 may receive messages from the crypto interface driver 120 and forward the messages to the communication stack module 116 via the appropriate horizontal operational connection. Depending on the destination of the message, the message may be sent to a different receiving node in the vehicle using the communication stack and conceptual arrows 188.Alternatively or additionally, the message may be sent from the crypto service manager module 118 to the communication stack module 116, where it is forwarded to the application software module 114 for use by an application or function residing thereon.

[0042] Because this aspect of the description prevents lower-level modules in an architecture from accessing high-security features, processors in a vehicle that implement these principles cannot easily be spoofed or otherwise maliciously compromised. Safety-critical messages must be transmitted along with a MAC to authorize the execution of the function contained in the message. Thus, if the communications stack module 116 receives a safety-critical message from a transmission node in another part of the vehicle, the module 118 cannot simply forward the message to the application software module 114 for execution because, lacking the proper permissions, the application software module 114 is configured to execute only non-safety-critical functions of the vehicle.Conversely, and for the same reason, an application in module 114 cannot generate a safety-critical message and forward it to the communication stack module 116 via one of the arrows 188 to the transmission hardware of the control unit 100 to a receiving node because the safety-critical message lacks a MAC. A receiving node detects the absence of a MAC (or an incorrect MAC, in some examples) and simply discards or ignores the message. Thus, even in an SOA, the absence of correct MACs will prevent safety-critical messages from being authorized for execution, and the integrity of the SOA vehicle system is maintained.

[0043] As in Fig. As shown in Figure 1, host device 102 may also include a crypto interface driver 120. One purpose of crypto interface driver 120 is to authorize security-critical messages for execution on EPC 100 or another node. More specifically, crypto interface driver 120 is a software module operatively coupled to communication stack module 116 and, via hardware connections 110, 112, to a separate security peripheral 104a (the latter may include a crypto accelerator as described herein).While the crypto interface driver 120 is a software module or data structure implemented on the host device 102, the security peripheral 104 is a hardware component that may be located on the same integrated circuit as the host device, or may be located on a common printed circuit board (PCB) as the host device 102, with the host device 102 and the security peripheral 104 connected using hardware, or may be located as a separate physical component connected to the host device.

[0044] According to aspects of the description, host device 102 can implement non-safety-critical messages quickly and efficiently, often without the need for further authorization. However, in the absence of the exemplary methods described below, host device 102 lacks authorization to execute safety-critical messages, thereby maintaining the security of the SOA vehicle network.

[0045] In the host device 102, the crypto interface driver 120 includes a MAC Generate Allow List (MGAL) 122 enforcement module. The MGAL may be a policy or set of policies implemented in software or as a data structure in a data store within the host device 102 and accessible to the crypto interface device 120. In various embodiments, the crypto interface driver 120 serves a dual purpose.First, for security-critical messages from a sending device (e.g., another control unit in the vehicle, and so on), the crypto interface driver 120 may use the hardware connections 106 and 108 to communicate directly with the security peripheral 104 to determine whether the sending device is authorized to send the security-critical message so that the message may be forwarded, for example, to a local application within the application software module 114 on the host device 102 to perform the function described in the message if an attached MAC accompanies the message and the MAC is legitimate.In this case, the security-critical message may be considered valid if it is sent along with a verified MAC (e.g., in or with a payload of the message) that is recognized by the security peripheral 104 and that authorizes the host device 102 to execute the instructions in the message to perform the intended function. In some embodiments, the message may also include other pertinent information (e.g., a key serial number and a message identifier) ​​that may be used by the security peripheral 104.

[0046] Second, upon receiving a security-critical message generated by an application on the application software module 114 of the host device 102 (in this example, the sending device), the crypto interface driver 120 may be configured to use the MGAL enforcement module 122, along with the hardware connections 110 and 112 to and from the security peripheral 104, to determine whether the host device 102 is authorized to send the security-critical message from the host device 102 to a receiving device (e.g., another processor, control device, or other component performing functions). If the host device 102 is authorized, the security-critical message, along with the generated MAC and possibly other information, may be sent to the communication stack module 116 and to the receiving device.The receiving device can then perform the security-critical function after verifying the integrity of the attached MAC.

[0047] Therefore, to perform security-critical functions or generate a security-critical message to be sent to a receiving device to perform potentially critical functions, the application software module must ultimately obtain authorization from the security peripheral by first passing through the crypto interface driver, where the policies of the corresponding MGAL are determined to determine whether the security-critical message is authorized or not. If it is unauthorized, the message is ignored or discarded. When the host device 102 receives a message from a sending device with a MAC, the MGAL enforcement module 122 is not involved. Instead, the existing MAC is verified as authentic or inauthentic. Examples of these two criteria are described in more detail below.

[0048] Generating a security-critical message on the host device to perform a priority function on another device

[0049] With continued reference to Fig. 1 shows a non-exhaustive embodiment of the above method. Starting with the application software module 114, an application or database can generate a message therein. The application in question can also generate other information relevant to the message, such as a message identifier (ID) and the origin. The message is then transmitted to the communications stack module 116. If the message is a non-safety-critical message that is to be executed on a receiving device (for example, an instruction to read a value), the communications stack module 116 simply sends the message over the existing physical network to the receiving module (represented by the conceptual arrow 188).In other cases, the message may be a safety-critical message, such as a brake command ultimately intended for execution by a control device connected to a brake device (the "receiving device"). The brake message may or may not represent a malicious spoofing attempt. Regardless, in this embodiment, upon examining the relevant fields in the message, the communication stack module 116 determines that it is a safety-critical message, which must be appended with a valid MAC if it is to be sent to the intended receiving device and executed. (If the message were simply sent from the communication stack module 116 via one of the arrows 188 over a physical network to a target receiving device without a valid MAC, the message would be ignored or an error message would be generated if the message was determined to be safety-critical.)

[0050] 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 crypto service manager module 118 of the host device 102. The crypto service manager module 118, in turn, can forward the message to the crypto interface driver 120. This information can signal the crypto service manager module 118 that the device originated from the host device 102 but must be verified as authentic and authorized before being transmitted to the receiving destination device. This means that a MAC should be generated and appended to the message to validate the security-critical message as authorized.

[0051] In these embodiments, the crypto interface driver 120 is a highly privileged module for processing security-critical messages. This is in contrast to the other modules 114, 116, and 120 on the host device 102. Since the latter modules are low-privileged modules solely responsible for non-security-critical messages, if malicious code or spoofing attempts to compromise the low-privileged modules, the corresponding messages would be passed through the crypto interface driver before they can be executed or processed. Because the crypto interface driver 120 is a highly privileged module solely responsible for security enforcement, the corresponding security-critical but forged messages are rejected based on the enforcement policies of the MGAL enforcement module 122 in the crypto interface driver 120.Since the three modules 114, 116, and 118 in these embodiments are low-privileged modules, they cannot access the security peripheral 104 without authorization from the crypto interface driver 120. This ensures that, even in an SOA, no non-safety-critical module can perform a safety-critical function without first obtaining authorization from the security peripheral 104. Security and message integrity are thus maintained.

[0052] As in the previous example, the security-critical message is forwarded from module 118 to the MGAL enforcement module 122 of the crypto interface driver 120. The crypto interface driver 120 may first examine an authenticated policy identified in an MGAL 122, which may contain a data structure or reference a data store, to determine whether the particular message to be sent is authorized to be transmitted by the node in question. Receiving nodes will reject a security-critical message if it does not have a valid MAC. One advantage of running the MGAL enforcement module on the host is that the processor typically has a much higher clock speed and can execute instructions faster than the security peripheral 104.

[0053] In various embodiments, the crypto interface driver 120 uses a MAC ID or other ID (e.g., on-board secure communication data identifier (SecOCDataID), key serial number (KSN), and so on) and compares it with the policies of the MGAL enforcement module 122 to determine whether a MAC can or should be generated for the security-critical message in question on the host device 102. For the purposes of this description, unless otherwise stated 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 other identifying characteristic that is present and, alone or in conjunction with other information, allows the recipient to determine that the security-critical message should be tagged with a MAC.In some embodiments, the SecOCDataID itself may be used to determine whether the message should be tagged with an appropriate MAC, which in turn may be appended to or generated along with the MAC generation message before the message is sent to the security peripheral 104.

[0054] In still other embodiments, the host device 102 may also use the MGAL enforcement module 122 to consider the results of previous reconnaissance, the host's history, and similar factors. For example, in some embodiments, the crypto interface driver 120 may review the historical records of the MGAL enforcement module 122 (if available), which list the relevant MAC IDs associated with various security-critical messages. In other configurations, the MGAL enforcement module 122 may issue one or more policies regarding which nodes / entities were previously permitted to send which messages to which modules and regarding which subject matter.

[0055] If the MAC ID is not listed in the MGAL enforcement module 122 (on the host device 102) or is otherwise identifiable, or the corresponding key cannot be found or retrieved from the MAC key generation module (on the security peripheral 104), the security peripheral 104 is unable to generate the MAC and may return an error or simply discard the message. As mentioned, if the MGAL information indicates that the message is safe, the host device 102 may send a MAC generation message to the security peripheral 104. The MAC generation module 109 may use the ID in the message to retrieve a key from the MAC key generation module 107, which may be a data store and may include hardware and / or software. Using the retrieved key, the MAC generation module 109 can generate a MAC and send it back to the host device 102 via the hardware connection 112.As mentioned above, in some arrangements, the receiving nodes may be informed of the generation of the MAC (or lack thereof) for that device. In some embodiments, using this and similar background information, the receiving nodes may ultimately learn which devices can and cannot be trusted with respect to the MAC ID in question or in general.

[0056] After the MGAL enforcement module 122 determines that the ID attached to the security-critical message is legitimate, the MGAL enforcement module 122 may then send the MAC generation message to the security peripheral 104 over the hardware connection 110. In one embodiment, the MAC generation message may include a message ID (e.g., SecOCDataID), the message's data payload (optional), and a key serial number (KSN) indicating the message's source.

[0057] At the security peripheral 104, the security-critical message is received by 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 key generation module 107. In various embodiments, the MAC key generation module 107 may contain a list of secret keys that may also be shared among the various devices authorized to encrypt and decrypt the security-critical messages to which they refer. In some embodiments, the MAC key generation module 107 instead contains one or more algorithms that enable the MAC generation module 109 to determine the appropriate key based on the ID in the message.

[0058] 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 key generation module 107. The key can be contained in a list of the MAC key generation module 107, as mentioned, or it can be generated based on the ID and possibly other criteria supplied to it by the MAC generation module 109. The MAC generation module 109 then uses the key to generate the MAC. The MAC can be generated by the key using software, combinational logic, or other means. The generated MAC can be appended to the security-critical message or accompany it in some other way.After the MAC generation module 109 generates the MAC based on the retrieved key, the MAC generation module 109 may return the results of the procedure, along with the MAC, to the host device 102 via the hardware connection 112, as mentioned. In various embodiments, the results may include the message and other indications that no error occurred and that the security-critical message, along with the MAC, is authorized for transmission to the receiving device.

[0059] In various embodiments, the MGAL enforcement module 122 receives the message ID, as described above. If the message is authentic, the message ID is incorporated into the MGAL enforcement module as a message type, to which it adds a MAC. That is, the MGAL enforcement module 122 uses the message ID as an index into a table of permissions. The permissions in the table indicate whether the host device 102 is authorized to act as a server or client for the message with respect to another node (e.g., another host or a control device), depending on the message type and the circumstances of the transaction. When the MGAL is acting as a client, it typically indicates whether the host 102 has one of two client types. Such a client type may act as a client that can only read data, for example, from a target source.Another type is a client that can actually write or set data, as in . Fig. 4 is explained in more detail.

[0060] In these embodiments, the MGAL enforcement module 122 may consider not only the message ID, but also the message type, which indicates what the host 102 ultimately does when sending the message. In some embodiments, the message type is based only on the message ID or is contained within the ID and can be understood by the MGAL enforcement module 122 upon receiving the ID. In other cases, the message type can be determined by the MGAL enforcement module 122 based on additional information provided to it.

[0061] The message type can specify various actions of the requesting device. For example, the message type can specify whether to publish data, such as the vehicle's speed (or other types of information). To obtain one or the other status, the permission table can indicate whether the requesting host has the appropriate permissions to perform the function specified in the message. In other examples, the message type can simply be to read certain data. Accordingly, in these embodiments, the MGAL enforcement module 122 can include additional criteria indicating what the host 102 or device is attempting to do for a designated service. Regarding the latter example, the SecOCDataID can specify the service ID itself and then also the message type.As mentioned previously, an example of a message type is publication (for example, when the device is authorized to act as a publication server for a particular data type). Another example message type is a request, which is often made via a remote procedure call (RPC). As another example, the SecOCDataID also contains a method ID that describes whether the message attempts to set (write) or get (read) data. For example, the MGAL enforcement module 122 may use different permissions depending on the method ID and message type. In some cases, a message ID may also contain a bit indicating whether the device or host is permitted to act as a client that can set data for the message in question. This bit may be reserved for devices in the vehicle with higher permissions.

[0062] Receiving a security-critical message on the host device to perform a priority function on the host device

[0063] In another aspect of the description, the EPC 100 may receive a message at the host device 102 from a transmission node, which may be another EPC in the vehicle or a dedicated processor. As in Fig. 1, the message is received over a wired connection, conceptually represented by the input arrow 188, which corresponds to the communication stack module 116. If the message is classified as a non-safety-critical message by the communication stack module 116, the message may be forwarded to the application software module 114, where the instructions in the message may be executed. Conversely, if the message is classified as a high-privilege message and lacks a MAC, the communication stack module 116 may discard or ignore the message, or optionally send an error message to one or more devices on the vehicle network. If the message is classified as high-privilege and contains a MAC, the communication stack module 116 forwards the message to the crypto service manager module 118.The crypto service manager module 118 forwards the message to the crypto interface driver 120 using the operational coupling specified in line 189. In this embodiment, the host device 102 attempts to verify the authenticity of the MAC to ensure that the security-critical message is authorized. Accordingly, the MGAL enforcement module 122 is not required in this case.

[0064] The crypto interface driver 120 then sends a MAC verification message to the MAC verification module 103 of the security peripheral 104 via the hardware connection 106. In various embodiments, the MAC verification message may include an ID corresponding to the MAC (e.g., SecOCDataID or similar) along with the MAC to be verified. Furthermore, the host device 102 may include a key serial number (KSN) in the MAC verification message. In this embodiment, the host device 102 may instruct the security peripheral 104 which key to use by including the KSN. At the security peripheral 104, the MAC verification module 103 receives the MAC verification message. The MAC verification module 103 may be generated by code running on the security peripheral, or it may be implemented in hardware, middleware, or a combination of hardware and software.

[0065] Based on the KSN as an index or similar, the MAC verification module 103 retrieves the corresponding key from the MAC verification key module 105. Like the MAC key generation module 107, the MAC verification key module may also contain a data store for the private keys used by the host device 102. The specific key may depend on the function of the security-critical message and, in this case, is specified by the KSN. The MAC verification module 103 retrieves the corresponding key based on the KSN. The key is then used to determine whether the MAC sent for verification is actually valid. Note that the KSN is often not discovered until the service discovery period. In this case, the KSN of the incoming security-critical message should match the KSN discovered by the host device 102.If there is no match, the incoming message is rejected as unauthorized. For example, during a service discovery period, the host device may participate in a service discovery process that stores key serial numbers (KSNs) in the host device's non-volatile memory 723 (see ). Fig. 7). Each of the KSNs corresponds to a server configured to offer a designated service or to a client subscribed to receive a designated service. Following the service discovery procedure, any data received by the host device that corresponds to one of the designated services and is not accompanied by the corresponding KSN stored in non-volatile memory during the service discovery period is rejected. The above discovery period can also apply on the server side, so that when a client (which may 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. After that, the server continues to ensure that each received Remote Procedure Call (RPC) is accompanied by the same KSN that was stored during the service discovery period.If the KSN is different, the server rejects the RPC.

[0066] If the MAC verification module 103 successfully compares the retrieved key with the MAC received from the crypto interface driver 120, the security peripheral 104 determines that the security-critical message is valid. The MAC verification module 103 of the security peripheral 104 sends this result back to the crypto interface driver 120 of the host device 102 via the hardware connection 108, thereby authorizing processing of the message. The result can then be forwarded, along with the message, through the module chain from module 120 to module 118, module 116, and application software module 114, where the instruction contained in the relevant security-critical message is executed and the action performed.

[0067] Thus, when a database or other entity connected to the application software module 114 has a message to send to a specific receiving component, the message is forwarded to the communications stack module 116. If the message is non-safety-critical, it is sent via the communications stack module 116 to the intended receiving component for execution on the receiving module using the existing network or hardware connections. If the non-safety-critical message indicates that it is intended for use in the application software module 114 of the host device 102, the communications stack module 116 simply forwards 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 security-critical message, the communication stack module 116 determines that the message requires a MAC. The message is then forwarded using the lower set of horizontal arrows in . Fig. 1 through the various modules 116, 118, and 120. At the crypto interface driver 120, the MGAL enforcement module 122 determines whether the MGAL policies allow the message to receive a MAC, as described above. If the message is authorized, a MAC generation message, such as the one described above, is forwarded to the MAC generation module 109 of the security peripheral 104 over the hardware connection 110 (which may consist of one or more conductors). The security peripheral generates a MAC, which is sent back to the host device 102 over the hardware connection 112 (which may comprise one or more wires). The message is then forwarded by modules 120 and 118 to the communications stack module 116. With the MAC appended to the message, the message is then sent to the intended receiving device for execution.

[0068] Consequently, the sophisticated transmission techniques according to the aspects of the description make the principles of SOA feasible with service discovery in networks while preventing vehicle nodes, messages, or services from being forged or otherwise suffering adverse consequences from attacks within an on-board network. The KSN can also be used to verify the MAC for a received security-critical message. If the KSN is received as part of the message, the host device 102 can compare it to an expected KSN determined during a service discovery process. If the received KSN does not match the expected KSN, the MGAL enforcement module 122 can determine that the received message is unauthorized.

[0069] Aspects of the present description also aim to make safety procedures in units such as network nodes (e.g., electronic control units or ECUs) of a vehicle more compact and efficient. The total number of objects and commands within a node can be reduced without reducing—and in some cases, increasing—the effectiveness of high-security techniques within and between nodes. Since these software-based control units control functions such as braking, acceleration, and the like, maintaining adequate safety in these cases is of utmost importance.

[0070] While these ECU-based systems contribute significantly to increasing efficiency, usability, occupant comfort, driver assistance, and reducing costs, earlier vehicle lines that relied on ECU- and / or node-based technologies have historically been difficult to upgrade in a cost-effective manner. First, there has been a lack of a viable software platform that abstracts the hardware layers and makes it easier for developers to write code compatible with specific vehicle types. Instead, many ECUs have rewritten their software to very low levels, including the physical layer. The lack of a tangible, unified platform for applications in existing vehicles and transportation mechanisms has also been an obstacle to developing effective solutions against spoofing or other malicious practices in vehicular networks.These challenges arose, in part, from the fact that different vehicle brands relied on software at different levels and the industry lacked a standard platform for the effective development of widely used network software that operates in a recognized and predictable manner.

[0071] In apparent recognition of at least some of these issues, SOA has recently become popular for the automotive industry. To meet demand and facilitate the exchange of critical information, vehicles became a natural candidate for this technology. From a communications perspective, SOAs operate on an "on-demand" basis. For example, a sender of data can transmit information if it is known that at least one listener on the network needs the data. This architecture preemptively avoids involvement in the unnecessary chatter that burdens the vehicle's communications system.

[0072] The above-mentioned advances contrast with previous approaches, which placed little or no restrictions on the transmission of instructions. That is, vehicle development originally followed a data-intensive approach, with the vehicle's key sensors producing extensive data, which in turn was regularly transmitted to various nodes within the vehicle. For example, sensor data was transmitted blindly between units, regardless of whether the data had changed. The data was also transmitted from the perspective of the transmitting device. That is, if the transmitting device believed the data was at least somewhat relevant, it was transmitted, regardless of whether there were actually any listeners on the vehicle's network.

[0073] In contrast, newer SOAs take a more pragmatic approach. The sender transmits data when at least one receiver in the network needs it. This restricted communication avoids many redundant transmissions that only consume bandwidth and increase latency, even for high-priority messages. Another evolutionary advance in some implementations is that SOA can rely on the presence of middleware. With well-known middleware in circulation, used within 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 sophistication of the vehicle. Scalable Service-Oriented Middleware over IP is responsible for the acronym SOME / IP.Another popular open-source middleware is AUTomotive Open System ARchitecture (AUTOSAR), which includes a consortium of global automotive manufacturers as members. To date, AUTOSAR has released solutions that offer greater flexibility through customized and unified standards.

[0074] To maximize this flexibility, third-party applications can be installed in the vehicle and used in conjunction with various control units. It is important to ensure that such applications are not able to circumvent existing security protocols and, for example, spoof the node(s) required for braking, display vehicle-critical figures such as speed, revolutions per minute, and so on, or perform other important tasks, for example, to prevent unwanted braking by the driver. These are just a few of many examples why the security of these network nodes is important. As mentioned above, control units can range from engine control to airbags to brakes and many other systems.A control unit often receives inputs, including information about whether to perform a particular task, and after performing some relevant calculations using the input, the control unit may output data intended for an actuator to enable the actuator to perform another related action based on a defined set of parameters.

[0075] From a security perspective, the techniques described, where such security-critical messages must be authorized by the MGAL enforcement module before being sent to the security peripheral 104 to obtain a MAC, are designed to address the same problems to which the SOA in a vehicle is otherwise vulnerable. For the same reason, the aspects described here, for messages with a MAC arriving at a receiving node for execution, rely on a security peripheral capable of retrieving the correct corresponding key to successfully match the key that originally generated the MAC, thereby authorizing the receiving node to execute the corresponding message.

[0076] Existing solutions are limited to assigning each V-ECU a unique transmission key to prevent spoofing when generating messages. Spoofing, in this context, involves impersonating another entity to convince the recipient of the message that the V-ECU is permitted to send the message in question. The subject message actually attempts to perform an unauthorized action that, if permitted, could be dangerous for the driver. In the case of an ECU, the number of entities or V-ECUs within a single ECU is increasing in many vehicle designs.

[0077] The same logic can be applied to an architecture with multiple V-ECUs in a single ECU. Existing designs may also include some sort of "crypto engine" built into a network host with, say, four V-ECUs. The crypto engine, or MGAL enforcement module, can be populated with information or otherwise configured via hardware so that the crypto engine knows which V-ECU is making the request from the four ECUs, since the crypto engine knows the key 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 V-ECU 3's key instead of its own, the crypto engine knows in advance that the wrong key will be used by V-ECU 2.Therefore, the Crypto Engine of the V-ECU 2 will not allow it to generate the MAC to execute the command, which it is otherwise not allowed to generate. The request is therefore rejected.

[0078] Until recently, onboard networks used static configurations that required little or no activation of mobile sensors or nodes. In such cases, it is easy to know which nodes need to send or receive which messages. In this static configuration, most data exchanges were known in advance, with the exception of system updates. However, even then, the updates were typically addressed to both the sending and receiving circuits.

[0079] The service-oriented architecture concept can encompass both information publishers and subscribers. The vehicle user or passenger may choose to subscribe to a service, but the information provider and publisher may change over time. This means that in some cases, the vehicle owner or driver may have to wait until a new provider becomes available. With this in mind, the service-oriented architecture concept can eliminate the need to switch devices, thus enabling vehicles to more difficultly engage in spoofing and other negative measures against ECUs or other control devices.

[0080] With the long-standing concept of static vehicle architectures, internal security was not such a primary concern, as the critical paths within the vehicle were known and specialized hardware was configured to repeatedly perform specific tasks such as driving, shifting, navigating, accelerating, braking, and the like. However, the concept of SOAs has changed the manufacturing landscape, and with these changes, security measures must also meet the demands of increasingly sophisticated and capable vehicles. For example, the vehicle user or occupant can opt into one or more of the many offered services, which means that the location of the information-providing structure(s) within the vehicle and the physical position of the control unit or node that gives and receives instructions can be dynamic and change in real time.Dedicated connections may be rare and widely spaced. Accordingly, given the possibility of such changes, the SOA concept may entail the need to move data and commands, thus enabling vehicle electronics to do so.

[0081] In this system, where the units (for example, including the connectors (or the location of applications and functions on different processors in the vehicle)) move a lot and become more dynamic than static, which is a growing trend, it may be beneficial for the units to place less emphasis on the identity of the providers, which may also change over time depending on the movement of these units within the vehicle. If the units do become dynamic, the service providers cannot try to follow the random pattern of the control unit's movement, especially as this trend continues to increase with the vehicles. Accordingly, in the Fig. 1 and the following figures, spoofing by other nodes can be prevented by using the security peripheral 104 in conjunction with the MGAL enforcement module 122 in the crypto interface driver 120 of the host device 102 to restrict which message types this host device 102 and other nodes on the network can generate a legitimate MAC for. This information is potentially critical to the reliable operation of the vehicle.

[0082] In addition, the host device 102 may contain software components such as the communication stack, i.e., the software for communicating with other nodes. The host in Fig. 1 is coupled to a security peripheral 104. The security peripheral 104 may include a MAC verification module 103 and a MAC generation module 109. The MAC verification module 109 has access to the corresponding MAC verification key module 105, while the MAC generation module 109 has access to the MAC key generation module 107. The MAC verification and generation keys are securely stored, and in some embodiments, they are stored with the MAC verification module 103 and / or the MAC generation module 109. The security peripheral 104 may include executable code for performing security-critical functions, generating security messages, managing keys, and the like.

[0083] In short, the problem of nodes (e.g., ECUs) being vulnerable to spoofing when leveraging SOA flexibility in a network (e.g., an in-vehicle network) is mitigated, though not solved, 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 security peripheral 104 or a crypto accelerator module. The security peripheral 104, or another module with access to the security peripheral 104 or the crypto accelerator, checks an authenticated policy in the MGAL enforcement module 122 to determine whether the message may be transmitted by the node.The receiving node(s) (for example, another node or an ECU located in another part of the vehicle, whether nearby or not), rejects the message if it does not have a valid MAC.

[0084] In some embodiments, the MGAL of the MGAL enforcement module 122 indicates whether the device attempting to send the message (e.g., host 102) may be (1) a client that sets or modifies a target value, (2) a client that reads values, or (3) is instead a server that publishes values ​​and offers subscriptions. For example, in a scenario with (1) and (2) in this paragraph, the device is the client, and it is the client that monitors itself (via the MGAL enforcement module) to prevent it from performing an action for which it is not authorized. The device is not the server in (1) or (2), which in this example is the receiving device of the message.

[0085] Fig. Figure 2 is a conceptual diagram of an example ECU 200 including a host device 102 with two processor cores 224 and 226, where the first processor core is configured to execute the application software module 114, the communication stack module 116, and the crypto service manager module 118, and where the second processor core is configured to execute the crypto interface driver 120 (and the MGAL enforcement module 122 contained therein). The ECU 200 in Fig. 2 also has a separate safety peripheral 104a (which, as in Fig. 1, may contain a crypto accelerator) and otherwise identical components as in Fig. 1. In various embodiments, the processor may include a plurality of cores such that each core is assigned different functions. The exemplary analysis in Fig. 2 is for simplification and shows that the processor has two cores.

[0086] The knot of Fig. 2 corresponds functionally to that of Fig. 1, the main difference being that modules 114, 116, and 118 execute on one physical core 224, while the crypto interface driver 120 executes on another physical core 226. Isolating the non-safety-critical modules and the safety-critical modules on separate cores has advantages. Some settings can be assigned to the modules on one core over the other. For example, since the modules on physical core 224 cannot directly interact with the security peripheral 104, the manufacturer can configure the system so that core 224 only accepts commands and messages from and to core 226. By configuring the host in this way, MGAL enforcement can be ensured when a safety-critical message is generated at application software module 114 or received at communication stack module 116.In this example, core 226 can then be used to enforce safety-critical security requirements.

[0087] Fig. Figure 3 is an example diagram of a data packet 204.4 for use in transferring information between ECUs or other nodes according to one embodiment. Data packet (PDU) 204.4 serves as an example, and depending on the implementation and objectives, different information may be transferred between nodes. In general, the horizontal direction in the figure represents time. Fig. 3 involves the transmission of symbolically represented information using different texture maps to represent the different fields.

[0088] As previously mentioned, a trusted node in the vehicle network, for example, at a new or different physical location, may still send a transmission, and the receiving node may still be able to authenticate the card using the MGAL enforcement module 122—for example, the transmitted MAC may include a key serial number (KSN) 210 in its message (also highlighted as field 212). KSNs 210 may be associated with keys stored in the security perimeter of the receiving nodes so that the receiving nodes know which keys to use to authenticate the received MACs. The KSN 210 may also be associated with the respective transmitting node and will change if the nodes relocate to a new location requiring a new key.

[0089] The Secured PDU header 206 (both SD and Non-SD) contains header information relevant to the type of SD request (if applicable), as well as the KSN 210 embedded in the PDU 204.4, which, as mentioned, contains a link to the transmission key to be used, which in turn implicitly identifies the node from which the message was transmitted. The Secured PDU header 208 is followed by a serialized SOME / IP payload 208, followed by the KSN 210, and then by a Freshness Value ("FV") value describing the relative freshness of the data 214 (for example, relative to time or relative to the frequency of other similar data). Finally, the FV 214 is followed by the MAC 216.

[0090] The above PDU 204.4 is one of many possible examples, and depending on the architectural goals, numerous PDUs can be used. As previously mentioned, certain aspects of the description involve the transmission of a key serial number (KSN) 210. Data is transmitted within the vehicle via the middleware (via the application software module) over a physical network cable (conceptually represented by the arrows 188 in Fig. 1, which runs over the network hardware) between the server ECU and a client ECU using the TCP protocol (when data is requested from the server) or the UDP protocol (when data is requested from the client). In this example, PDU 204.4 represents a Service Discovery ("SD") message containing a serialized SOME / IP payload 206. The acronym SOME / IP stands for "Scalable Service-Oriented MiddlewarE over IP." As mentioned earlier, today's vehicles are equipped with more features than other vehicles that do not use SOA architectures.SOA vehicles using ECU-to-ECU protocols such as CAN and MOST are of limited use due to the low bandwidths and lack of interoperability of the latter protocols and the vehicles in which they are used, making the latter primarily suitable for vehicles with a lower feature set and static and dedicated connections. In contrast, the serialized SOME / IP payload 206 can be operated across a number of different units within an ECU. The IP refers to the fact that SOME / IP is an Ethernet-based protocol.

[0091] As mentioned above, the recipients of a message do not need to worry about the identity of the sender, as long as they are trusted nodes. This makes the entire process of node relocation much easier. At the same time, the sending nodes remain subject to the protection provided by the MGAL and the Fig. 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 security peripheral. On the receiving side, the service can be moved without renaming the moved nodes or reconfiguring the policies, since in the above examples, the trustworthiness of the senders is based on whether their requested MAC ID or service ID was present in the MGAL list. Thus, the nodes can be relocated to a new location without losing their effectiveness.

[0092] Fig. 4 is a timing diagram illustrating the distinction between "get" and "set" permissions for nodes in a vehicle according to one embodiment. The functions in Fig. 4 can be implemented using a combination of hardware and software. For example, the "get" and "set" schemes (see below) can be controlled by the processor in conjunction with the crypto interface driver 120 and the security peripheral 104.

[0093] The Fig. The "get / set" scheme illustrated in Figure 4 ensures that when multiple nodes / ECUs within a vehicle perform a function or implement a feature, such as detecting the vehicle's speed for the purpose of performing airbag-related calculations, the ECU network 400 is intended as a miniature part of the ECU network; however, the scheme is also intended to function at a much larger capacity. Only three devices of the network are shown to adequately convey the principles of this powerful embodiment.

[0094] For the purposes of this example, it is assumed that the client of Device A 402 is a node that has been at least partially maliciously taken over by an intruder. For example, Device A 402 may be a vehicle's infotainment system. It is assumed that the intruder has connected a black box to a port of the entertainment system in an attempt to change the vehicle speed to a very high or very low value. Meanwhile, the client corresponding to Device B 404 may be an ECU with control over the accelerator pedal, while the client at Device C 406 may be an electronic device that controls the fuel injection system or battery-powered power to directly accelerate the engine at the device under the right circumstances. In one aspect of the description with respect to the above example, the algorithm implemented in the MGAL enforcement module 122 of Fig. 1 applied permissions can be used to control whether a specific client is allowed to only “receive” a value (for example, read and / or pass on the vehicle speed) or whether the client is also allowed to “set” the value (for example, press the accelerator pedal and increase the vehicle speed).

[0095] As in Fig. As shown in Figure 4, the black box connected to the infotainment system (Device A-402) can send an instruction to Device B 404, which can then be used to adjust the accelerator pedal. Device B 404 can receive the instructions from Device A 402 (via path 408). Device A 402 can then receive the data, for example, via path 412, after which Device A 402 can transmit the data to a receiving device via path 410. Based on the MAC 218 or a KSN or other ID included in the message, Device B can easily determine that Client A 402 lacks the authority to "set" a value, for example, to set (and effectively change) the vehicle's speed.In this case, it is assumed that while Device A has permission to display the vehicle speed on the infotainment system and estimate fuel consumption, the MGAL enforcement module 122 knows to prohibit Device A 402 from setting or changing the speed, and the intruder's malicious attempts are thwarted. Client 5 404 can deny the request to adjust the speed, as indicated by the bold circle with the slash under Device B 404.

[0096] Conversely, the client at Device B 404 may be recognized as the driver's foot pressing the accelerator pedal. This action may trigger a request to set a new speed at Device B 406 to Device C 406, sent via path 416. Thus, the request to increase the device's speed may be forwarded to Client C 406. Client C and Device C 406, after optionally confirming the validity of the request in a message sent from Device C 406 back to Device B (404) via path 414, may use the KSN or other ID to determine whether the MA 218 attached to the message from Device B matches the MAC attached to the message from Device B 404. Finally, the infotainment system (Device A - 402) may send a request to Device B to "get" the speed for use in mapping and traffic.If Device A detects that Device B's MGAL enforcement policy is valid for "get," it can proceed to provide Device A with the requested information. Thus, while Device A is not authorized to change the speed, Device B is still permitted to display the current speed to Device A.

[0097] This is just one embodiment of the "get" and "set" actions authorized or prohibited by the corresponding MGAL enforcement policy. One advantage of this approach is that critical actions can be performed with low latency. Another advantage of this approach is that it can accommodate changes to the devices. The source of the device is not necessarily important, provided the MGAL enforcement policy matches.

[0098] In short, applying the principles of the description makes it possible to relocate network elements to a different physical location without compromising the network's effectiveness, preventing spoofing attacks and other malicious forms of hacking by preserving the information in the transmitting modules. This allows a vehicle operator or other individual to use the services of the same network at a different geographical location, requiring only the transmitting node to be updated. The information in the dozens or hundreds of receiving nodes can remain untouched, and the operator can continue to provide and exchange the usual services by simply supplying information to a few new transmitting nodes without loading data into the numerous receiving devices in the vehicle.

[0099] (1) Shared secret keys are set up in the nodes (e.g., control units) and stored in the security perimeter of the nodes in such a way that each node has its own key for transmission, and the receiving nodes store the same key for authenticating messages from sending nodes in their security perimeter in such a way that the key cannot be used to generate MACs. When the transmitting node needs to send a protected message with a MAC, it requests the security perimeter to generate the MAC, and the security perimeter uses 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 security perimeter does not provide the MAC.(2) The security peripheral uses a bitmask-based MGAL to select which nodes the entry for non-service discovery messages applies to. (3) The table used to construct the MGAL configuration for each node is based on the security peripheral key serial number and key usage flags and is organized so that an entry can be accessed directly with a pointer rather than using a less powerful lookup algorithm. (4) The security peripheral uses the configuration options field at the beginning of the options section in the Service Discovery (SD) header to determine whether SD messages are allowed to be sent based on the entries in the MGAL. (5) When multiple cores with different access rights are used, the MGAL is organized into sections for each core as a sorted list of pairs to facilitate processing.(6) When the protected message is transmitted by a node, it includes a key serial number (KSN) in SOME / IP packets to convey the key IDs while minimizing the changes required in the communication stack module 116 to process new packets. (7) SOA message IDs are decoupled from the security peripheral key serial numbers to enable dynamic discovery of services and the use of the correct key material at runtime. (8) When a transmitting node needs to be able to offer a new service, the MGAL is updated via a signed calibration or firmware update that is authenticated before the security peripheral is used.

[0100] The crypto accelerator of the security peripheral 104 can be used to perform operations that require very low latency (for example, securing messages sent between vehicle devices). Some microcontrollers may have their own crypto accelerator in addition to a separate security peripheral to perform these low-latency operations. These separate crypto accelerators are typically significantly more powerful than the separate security peripheral, at least because they are hardware-based and do not execute software. However, because the crypto accelerators do not execute software, the MGAL enforcement software cannot be housed within them.Accordingly, in another aspect of the description, a vehicle may achieve the performance benefit of using the crypto accelerator instead of the security peripheral for such low-latency requirements by incorporating the MGAL enforcement module into an entity in the host device and restricting access to the crypto accelerator to that entity.

[0101] The principles of the description are also applicable to newly installed programs that, if authorized, use secret keys to generate MACs and public keys to verify the authenticity of the generated MACs. In this way, the nodes in the network maintain their trusted status even when relocated, with minimal software interventions directed at one or a few nodes.

[0102] Fig. 5 shows a representation 500 of a download of an Android APK to an Android virtual machine of a dual virtual machine for handling firmware updates, according to one embodiment. That is, in Fig. 5 An Android virtual machine runs alongside a Linux virtual machine. The two virtual machines run as a collection 504 on a hypervisor, which is a type of hardware that runs on top of the physical layer of a host machine. This allows multiple virtual machines to run as guests on a single host machine. The hypervisor provides a virtual operating platform for the virtual machines and manages the systems, typically using the native hardware. The "u" prefix that precedes several logic blocks in the virtual machines simply specifies a name for a common technology and can be ignored for the purposes of these figures.

[0103] When a vehicle is first manufactured, it is easy to establish the basic settings and implement the desired MGAL policy. Newer vehicles may have "app stores" from which the driver can download applications and services. 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 type of application or service, the application 532 or service 530 may be forwarded via the Android bus 534, where it can be partitioned and streamed using the bridge 538 (for example, with SOME / IP). Both virtual machines can cache the SecOC ID value at 518 and 540 to identify the MAC.

[0104] When updating, it is important to ensure that the MGAL (here the SHE-compliant TA2 524 and the MGAL2 module 526) is also updated dynamically. Fig. Figure 5 is a conceptual description showing that MGAL permission is required to update the MGAL so that the application can perform authorized functions. When the Android application is downloaded from an app store, it may be accompanied by a manifest to which the virtual machine can add metadata. This data may include, as here, the name and value of the MGAL, as well as the ID and number of different functions it can perform as a server of the client services it can execute. The goal at this point is for the Android application to have the necessary MGAL information so that the trusted application enforcing the MGAL can obtain the information from a specific back office where the private key authorizing the MGAL update is kept.

[0105] In other words, the Android application has the necessary information, so any trusted application enforcing the MGAL receives the relevant information and a signature generated by the vehicle's back office. The back office has a private key for the update, so it has access to the signature and thus authorizes the actions. If a user attempts to create their own malicious application and install it on the vehicle with a variety of permissions, they cannot compromise the system this way because they are not allowed to sign the private key (see Fig. 5). The key is secured in a hardware security module and cannot be signed without authorization. Each virtual unit can contain a corresponding MGAL unit, for example, the SHE-compliant TA1 520, which stores the MGAL1 module 522 for use in the Linux virtual machine, and the SHE-compliant TA2 624, which stores the MGAL2 module 626 for use in the Android virtual machine.

[0106] The entity enforcing the MGAL possesses the public key linked to the signing key. The public key can therefore be used to verify (but not create) the signature of updated applications. This way, the system knows whether the requested permissions were actually authorized by the back office. This allows it to verify whether the entity enforcing the MGAL possesses the public key to verify the signature. Signatures that cannot be verified are known to be malicious attempts to forge the trusted back office.

[0107] The term "TEE IDs" in Android update 502 stands for "Trusted Execution IDs." Multiple trusted IDs can be used at once. When the Android update 502 enters the OTA manager / installer 528, the installer 528 can transfer the MGAL information to the MGAL2 using the DynaMGALupdate (MGALinfo) data. The trusted execution IDs can be verified in the MGAL2, for example, using the public key. Similarly, an update (not shown) received by the OTA manager / installer 506 can be made available to the Linux virtual machine. The data can be forwarded via the application module 508 or the service module 510, as needed, via the bus 512 and the streamer 514, and then packaged using the aforementioned Some / IP protocol.Meanwhile, the OTA Manager / Installer 506 can provide the MGAL information corresponding to the relevant metadata, which can be verified on the MGAL1 of the SHE-compliant TA 1 520.

[0108] Multiple trusted applications can run simultaneously. The Linux virtual machine can run each with its own MGAL, as the Android platform can perform infotainment-like actions, for example, and therefore requires separate permissions, as the Linux environment may be capable of sending certain messages not permitted by Android.

[0109] Because Linux and Android run on a hypervisor, which in turn runs on the hardware, memory access may require an extra step. For example, if the Linux application needs to access memory, Linux first goes through the hypervisor. The Linux and Android machines run on a hypervisor, which in turn runs on the hardware. So, if the Linux virtual machine wants to access memory, Linux must first go through the hypervisor, which controls which resources the Linux machine can access. The hypervisor is the layer that ensures the two virtual machines work together.

[0110] The APK runs through the virtual machine, and at the end (MGAL), the MGAL ensures that the data is authentic. For example, the SHE-compliant TA 1 can verify the signature to ensure the update is performed. CCU stands for Cycle-Compute Unit.

[0111] Fig. 6 shows a representation of a DynaMGAL update module 600 using relevant information with two virtual machines on a computer, according to one embodiment. As the embodiment of Fig. 5 contains Fig. 6 a collection of 604 (here two) virtual machines: Linux and Android. In this embodiment, Linux is executed on a System on a Chip (SoC) in the control unit. In contrast to Fig. 5 shows Fig. 6 the somewhat more difficult security task of uninstalling a program while ensuring that the program's resources are not compromised by malicious actions. The virtual Linux path includes an over-the-air (OTA) manager / installer 606, an apps module 608 (for processing applications), a services module 610 (for processing services), a bus 612 for coupling the apps and services with the streamer 614, and an encapsulation unit 616 (for example, for splitting data into data units). The encapsulation units 516 can both have access to the SecOC 518 and 520 to verify the MAC. The virtual Android path includes the OTA manager / installer 628, the application module 632 (for processing applications), the service module 630 (for processing services), the bus 634 for coupling the applications and services with the streamer 636, and the encapsulation unit 638 including the SecOC 640.Each virtual unit may contain a corresponding MGAL unit, for example, SHE-compliant TA 1 620, which stores the MGAL 1 module 622 for use in the Linux virtual machine, and SHE-compliant TA2 624, which stores the MGAL 2 module 626 for use in the Android virtual machine.

[0112] Maintaining security and functionality during dynamic program uninstallation means that the Dynamic MGAL 602 should contain not only the individual versions and identifications of the software, but also the metadata, including service, service ID, client, and client ID. When uninstalling a program, it is necessary to track which pass had permission to access which service ID. The entity performing MGAL enforcement tracks which service permissions are associated with which applications to prevent the removal of needed permissions that an authorized application might be using. If the MGAL does not track service permissions for different programs / versions, when uninstalling a version, it becomes unclear whether the other permissions associated with that version should be removed or not.

[0113] Accordingly, in one aspect of the description, the dynamic MGAL 602 is reviewed when an installation occurs. For example, if uE ID2 / v3 is removed, the service ID $1234 is retained because uE ID2 / v2 remains installed and also uses that service ID. However, if uE ID2 / v3 is uninstalled, $1235 can be deleted because no other active application is using that service ID. The result is a streamlined list of applications that retains only the required metadata.

[0114] With reference to the Fig. 5 and Fig. 6, shared secret keys are set up in the nodes (e.g., control units) and stored in the nodes' security perimeters in such a way that each node has its own key used for transmission, and the receiving nodes store the same key for authenticating messages from sending nodes in their security perimeters in such a way that the key cannot be used to generate MACs. When the transmitting node needs to send a protected message with a MAC, it requests the security perimeter to generate the MAC, and the security perimeter uses the MGAL to check whether the message may be sent from the node. If the MGAL indicates that the message may not be sent, the security perimeter does not provide the MAC.The security perimeter can use a bitmask-based MGAL to select which nodes the non-service discovery message entry applies to.

[0115] The table used to construct the MGAL configuration for each node can be based on the security peripheral key serial number and key usage flags and organized so that an entry can be accessed directly with a pointer, rather than using a less powerful search algorithm. The security peripheral can use the "config option" field at the beginning of the "options" section in the "service discovery" (SD) header to determine whether SD messages may be sent based on the entries in the MGAL.

[0116] When multiple cores with different access rights are used, the MGAL is structured into sections for each core as a sorted list of pairs to facilitate processing. When the protected message is transmitted from a node, it includes a key serial number (KSN) in the SOME / IP packets to convey the key IDs while minimizing the change required in the communication stack module 116 to process new packets. SOA message IDs are decoupled from security peripheral serial key IDs to enable dynamic discovery of services and the use of the correct key material at runtime. When a transmitting node needs to be able to offer a new service, the MGAL is updated via a signed calibration or firmware update, which is authenticated by the security peripheral before use.

[0117] Fig. 7 is a hardware representation of a node 700 in one aspect of the present description to which the principles of the present description may be applied. Fig. 7 can be a transmission node, such as a control unit, or a reception node. Fig. 7 includes a host device 702. In some embodiments, such as a security peripheral 704, not every element of the Fig.7 is required. Node 700 may include a processor 721, which in practice may comprise one or more processors, general-purpose processors, reduced instruction set computer (RISC) processors, digital signal processors (DSP), or a processing device that can implement functions and / or instructions purely in software, partially in software, or in a mixture of hardware and software. The processor is coupled to memory 723, which may be dynamic random access memory (DRAM), static random access memory (SRAM), non-volatile memory (for example, for storing KSNs during a service discovery period), a magnetic disk drive, a solid-state drive, other non-volatile memory, cache memory, or a combination of various memory types, including those mentioned above.Receiving nodes may also include one or more sensors 725, for example, to perform measurements in vehicles and report the results. For this purpose, such receiving nodes may cover a variety of sensor types and, in some cases, may be used in control units and transmission nodes.

[0118] Node 700 may also include a transceiver 728 for sending and receiving messages to other nodes in the network over a compatible vehicle wireless medium. As previously mentioned, some ECUs have keys for generating or verifying MACs. To avoid overly obscuring the scope of the description, both are presented here as examples. A MAC generation security peripheral 733 and an associated MGAL may be located within an ECU or coupled to host nodes as part of an ECU. A separate element 735 is a MAC verification module. In some configurations, including the security peripheral, both modules 735 and 733 may be housed in a single security peripheral. In other configurations, they are split across different elements. The MAC generation peripheral 733 may also include a MAC engine 731 for executing low-level instructions.

Claims

[1] System for authorizing messages in a service-oriented vehicle architecture, comprising: a security peripheral device (104); and a host device (102) coupled to the security peripheral device (104) and comprising a processor (721) configured to execute code in a local memory (723) to generate a crypto interface driver (120), wherein the crypto interface driver (120) is configured to determine whether the host device (102) is authorized to send a security-critical first message from the host device (102) to a receiving device by maintaining a message authentication code (MAC) generate allow list, MGAL, enforcement module (122) in the host device (102), the MGAL enforcement module (122) for receiving a first identifier, ID, for determining whether the first message is authorized, and for enabling the host device (102) to provide a MAC generation module (109) running on the security peripheral device (104) is designed to provide a MAC generation message comprising the first identifier (ID),if the first message is authorized, where, the MAC generation module (109) of the security peripheral device (104) is further configured to retrieve a corresponding first key based on the first ID to generate a first MAC based on the corresponding first key and send the first MAC to the crypto interface driver (120) of the host device (102), and the host device (102) is configured to send the first message along with the first MAC to the receiving device; wherein the processor (721) is further configured to execute code to include: a crypto service manager module (118) operatively coupled to the crypto interface driver (120) for forwarding security-critical message types requiring MAC verification or MAC generation to and from the security peripheral device (104) via the crypto interface driver (120); a communication stack module (116) operatively coupled to the crypto service manager module (118) for forwarding non-safety-critical message types to and from other vehicle devices and for forwarding the safety-critical message types to and from the safety peripheral device (104) via the crypto interface driver (120); and an application software module (114) operatively coupled to the communication stack module (116) for executing one or more software applications, the one or more software applications being configured to perform one or more corresponding functions based on the non-safety-critical message types and the safety-critical message types passed by the communication stack module (116), wherein only the crypto interface driver (120) is capable of interfacing with the security peripheral device (104). [2] The system of claim 1, wherein if the first message is unauthorized, the MAC generation module (109) of the security peripheral (104) is unable to identify a key and refrains from generating a MAC. [3] The system of claim 1, wherein: when the host device (102) receives a security-critical second message together with a second ID and a second MAC from a transmitting device, the crypto interface driver (120) is configured to determine whether the transmitting device is authorized to send the second message to the host device (102) by enabling the host device (102) to send the second ID and the second MAC together with a key serial number, KSN (210), for identifying the key to be retrieved to a MAC verification module (103) executing within the security peripheral device (104), wherein when the MAC verification module (103) uses the KSN (210) to retrieve a corresponding second key in the security peripheral device (104), the security peripheral device (104) determines that the second message is authorized; and if the MAC verification module (103) cannot identify a corresponding second key using the KSN (210), the security peripheral (104) determines that the second message is unauthorized. [4] The system of claim 1, wherein the MGAL enforcement module (122) includes an authentication policy to determine whether a message may be transmitted. [5] The system of claim 1, wherein the first ID comprises an on-board secure communication data identifier, SecOCDataID. [6] The system of claim 1, wherein the processor (721) is configured such that the crypto interface driver (120) has exclusive access to the security peripheral device (104) for messages sent by the host device (102) or received by a sending device. [7] The system of claim 1, wherein the first identifier (ID) along with the first message transmitted from the host device (102) to the security peripheral device (104) further comprises a key serial number (210), the key serial number (210) being configured to identify a service type associated with the first message and determined during a previous service discovery period. [8] The system of claim 1, wherein: the host device (102) further comprises a non-volatile memory (723) coupled to the local memory (723); the host device (102) is further configured to participate in a service discovery process in which one or more key serial numbers, KSNs (210), are stored in the non-volatile memory (723), each of the one or more KSNs (210) corresponding to a server configured to offer a designated service or a client that has registered to receive a designated service; following the service discovery process, all data and remote procedure calls received by the host device (102) that correspond to one of the designated services and are not accompanied by the corresponding KSN (210) of the one or more KSNs (210) stored in the non-volatile memory (723) are rejected. [9] The system of claim 1, wherein: the MGAL enforcement module (122) of the host device (102) is configured to determine the permissions of the host device (102) based on the first ID, the permissions comprising: (1) whether the host device (102) is authorized to act as a client that sets or changes a target value; (2) whether the host device (102) is authorized to act as a client reading the target value; and (3) whether the host device (102) is authorized to act as a server that publishes values or offers logins, and if the MGAL enforcement module (122) determines that the host device (102) is authorized to act as a client according to (1) or (2), the host device (102) uses the MGAL enforcement module (122) to determine whether security-critical messages subsequently generated by the host device (102) are authorized.

Images