Method for secure service-oriented architecture with message authentication code generation permission list

Abstract

A method for a secure in-vehicle service-oriented architecture with a MAC generation permission list includes receiving, at a secure environment, a request to transmit a message from a device. The transfer request includes a request for a message authentication code. The method further includes determining an identity of the device based on the transfer request, and generating a permission list based on the message authentication to determine that the transfer request does not exceed a permission level of the device. Here, the permission level of the device is stored in a message authentication generation permission list. The method further includes obtaining a secure environment key assigned to the device, the secure environment key being only accessible by the secure environment, and generating a message authentication code using the secure environment key assigned to the device.

Description

[0001] Introduction

[0002] The information provided in this section is for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors, to the extent described in this section and aspects described that may not otherwise have been considered prior art at the time of filing, is neither expressly nor implicitly admitted to be prior art against the present disclosure. Technical Field

[0003] The present disclosure generally relates to a secure vehicle service-oriented architecture with a Message Authentication Code (MAC) Generation Allow List (MGAL). Background Art

[0004] Modern vehicles have made rapid technological progress in terms of the number of electronic devices and associated software included within the vehicle. For example, Electronic Control Units (ECUs) are used as embedded systems that control various electromechanical systems within the vehicle. However, within a Service-Oriented Architecture (SOA) and without proper security, ECUs are vulnerable to spoofing by impostors or compromised ECUs. To address this issue, a system may include a Message Authentication Code (MAC) Generation Allow List (MGAL) to determine whether a MAC can be generated before an ECU can transmit a message. In the absence of a valid MAC, the receiving ECU will reject the transmitted message. Summary of the Invention

[0005] One aspect of the present disclosure provides a computer-implemented method for a secure vehicle service-oriented architecture with a Message Authentication Code (MAC) Generation Allow List (MGAL) that, when executed on data processing hardware, causes the data processing hardware to perform operations including receiving, at a secure environment, a request to transmit a message from a device, the request to transmit a message including a request for a message authentication code, and determining an identity of the device based on the request to transmit the message. The operations further include determining, based on the Message Authentication Code Generation Allow List, that the request to transmit the message does not exceed a permission level of the identified device, where the permission level of the identified device is stored in the Message Authentication Code Generation Allow List. The operations further include obtaining a secure environment key assigned to the identified device, the secure environment key being accessible only by the secure environment, and generating the message authentication code using the secure environment key assigned to the identified device.

[0006] Embodiments of the present disclosure may include one or more of the following optional features. In some embodiments, the device is located within a vehicle. In some examples, a message authentication code generation allow list is stored in the memory hardware of the secure environment. In some embodiments, the request to transmit a message further includes a message identifier (ID) indicating the criticality level of the transmission request. Here, the criticality level is based on the security impact of the request to transmit the message. In some examples, the secure environment is coupled to the device.

[0007] In some specific embodiments, the request to transmit a message further includes a request for confidential data. In these embodiments, the operation may further include receiving a public key from the device, determining that the device is approved to receive the confidential data based on the message authentication code generation allow list, and receiving an encrypted confidential data key, where the confidential data key is encrypted using the public key. Alternatively, the operation may further include determining that the device is approved to receive the confidential data based on the message authentication code generation allow list, receiving an encrypted confidential data key, where the confidential data key is encrypted using a pre-shared secret key held by the device and the remote system. Alternatively, the operation further includes determining that the device is approved to receive the confidential data based on the message authentication code generation allow list, and receiving a secret confidential data key that is used to decrypt the confidential data. The operation may optionally include determining that the device is approved to receive the confidential data based on the message authentication code generation allow list, establishing a secure connection with the remote system, and receiving the confidential data from the remote system.

[0008] Another aspect of the present disclosure provides a system for a secure in-vehicle service-oriented architecture with a message authentication code (MAC) generation allow list (MGAL), the system including data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed by the data processing hardware, cause the data processing hardware to perform operations including receiving, at a secure environment, a request to transmit a message from a device, the request to transmit the message including a request for a message authentication code, and determining the identity of the device based on the request to transmit the message. The operations further include determining, based on the message authentication code generation allow list, that the request to transmit the message does not exceed the permission level of the identified device. Here, the permission level of the identified device is stored in the message authentication code generation allow list. The operations further include obtaining a secure environment key assigned to the identified device, the secure environment key being accessible only by the secure environment, and generating the message authentication code using the secure environment key assigned to the identified device.

[0009] This aspect may include one or more of the following optional features. In some embodiments, the device is located within a vehicle. In some examples, a message authentication code generation allow list is stored in the memory hardware of a secure environment. In some embodiments, a request to transmit a message further includes a message identifier (ID) indicating the criticality level of the transmission request. Here, the criticality level is based on the security impact of the request to transmit the message. In some examples, the secure environment is coupled to the device.

[0010] In some specific embodiments, a request to transmit a message further includes a request for confidential data. In these embodiments, the operation may further include receiving a public key from the device, determining that the device is approved to receive the confidential data based on the message authentication code generation allow list, and receiving an encrypted confidential data key, where the confidential data key is encrypted using the public key. Alternatively, the operation may further include determining that the device is approved to receive the confidential data based on the message authentication code generation allow list, receiving an encrypted confidential data key, where the confidential data key is encrypted using a pre-shared secret key held by the device and the remote system. Alternatively, the operation further includes determining that the device is approved to receive the confidential data based on the message authentication code generation allow list, and receiving a secret confidential data key that is used to decrypt the confidential data. The operation may optionally include determining that the device is approved to receive the confidential data based on the message authentication code generation allow list, establishing a secure connection with the remote system, and receiving the confidential data from the remote system. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The drawings described herein are for illustrative purposes only for the selected configurations and are not intended to limit the scope of the present disclosure.

[0012] Figure 1 is a schematic diagram of an example system for a secure vehicle service-oriented architecture with a MAC generation allow list (MGAL).

[0013] Figure 2 is Figure 1 a schematic diagram of example components of the system.

[0014] Figures 3A - 3D is for transmitting confidential data Figure 1 a schematic diagram of example components of the system.

[0015] Figure 4 is a flowchart of an example arrangement of operations of a method for a secure vehicle service-oriented architecture with a MAC generation allow list (MGAL).

[0016] In all the drawings, corresponding reference numerals represent corresponding components. DETAILED DESCRIPTION

[0017] Example configurations will now be described more fully with reference to the accompanying drawings. The example configurations are provided so that this disclosure will be thorough and will fully convey the scope of the disclosure to those of ordinary skill in the art. Specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the configurations of this disclosure. It will be apparent to those of ordinary skill in the art that the example configurations may be embodied in many different forms and that specific details and example configurations should not be construed as limiting the scope of this disclosure.

[0018] The terminology used herein is for the purpose of describing particular example configurations only and is not intended to be limiting. As used herein, the singular articles “a,” “an,” and “the” may also be intended to include the plural forms, unless the context clearly dictates otherwise. The terms “comprises,” “comprising,” “including,” and “having” are inclusive and thus specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein should not be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. Additional or alternative steps may be utilized.

[0019] When an element or layer is referred to as being “on,” “engaged to,” “connected to,” “attached to,” or “coupled to” another element or layer, it may be directly on, engaged, connected, attached, or coupled to the other element or layer, or intervening elements or layers may be present. In contrast, when an element is referred to as being “directly on,” “directly engaged to,” “directly connected to,” “directly attached to,” or “directly coupled to” another element or layer, intervening elements or layers may not be present. Other words used to describe the relationship between elements should be interpreted in a like manner (e.g., “between” versus “directly between,” “adjacent” versus “directly adjacent,” etc.). As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0020] The terms "first", "second", "third", etc. may be used herein to describe various elements, components, regions, layers, and / or sections. These elements, components, regions, layers, and / or sections should not be limited by these terms. These terms may be used only to distinguish one element, component, region, layer, or section from another. Unless the context clearly indicates otherwise, terms such as "first", "second", and other numerical terms do not imply an order or sequence. Thus, without departing from the teachings of the example configuration, the first element, component, region, layer, or section discussed below may be referred to as the second element, component, region, layer, or section.

[0021] In this application, including the definitions below, the term "module" may be replaced with the term "circuit". The term "module" may refer to, be part of, or include the following: application specific integrated circuit (ASIC); digital, analog, or mixed analog / digital discrete circuits; digital, analog, or mixed analog / digital integrated circuits; combinational logic circuits; field programmable gate arrays (FPGA); processors (shared, dedicated, or grouped) that execute code; memories (shared, dedicated, or grouped) that store code executed by the processors; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system on a chip.

[0022] As used above, the term "code" may include software, firmware, and / or microcode, and may refer to programs, routines, functions, classes, and / or objects. The term "shared processor" encompasses a single processor that executes some or all of the code from multiple modules. The term "group processor" encompasses a processor that, in combination with additional processors, executes some or all of the code from one or more modules. The term "shared memory" encompasses a single memory that stores some or all of the code from multiple modules. The term "group memory" encompasses a memory that, in combination with additional memories, stores some or all of the code from one or more modules. The term "memory" may be a subset of the term "computer-readable medium". The term "computer-readable medium" does not encompass transient electrical and electromagnetic signals propagated through a medium, and thus may be considered tangible and non-transient memory. Non-limiting examples of non-transitory memory encompass tangible computer-readable media, which include non-volatile memory, magnetic memory, and optical memory.

[0023] The apparatuses and methods described in this application may be implemented in part or in whole by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. The computer programs may also include and / or rely on stored data.

[0024] A software application (i.e., software resource) can refer to computer software that enables a computing device to perform tasks. In some examples, a software application can be referred to as an "application program", "app", or "program". Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0025] A non-transitory memory can be a physical device for temporarily or permanently storing a program (e.g., a sequence of instructions) or data (e.g., program status information) for use by a computing device. A non-transitory memory can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used for firmware such as a boot program). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and magnetic disks or tapes.

[0026] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented in high-level procedural and / or object-oriented programming languages and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., a magnetic disk, an optical disk, a memory, a programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives the machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0027] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuits, integrated circuits, specially designed application-specific integrated circuits (ASICs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementations in one or more computer programs executable and / or interpretable on a programmable system including at least one programmable processor, which can be special-purpose or general-purpose, coupled to receive data and instructions from, and to send data and instructions to, a storage system, at least one input device, and at least one output device.

[0028] The processes and logical flows described in this specification can be performed by one or more programmable processors (also referred to as data processing hardware) that execute one or more computer programs to perform functions by operating on input data and generating output. The processes and logical flows can also be performed by special purpose logic circuitry, such as an FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit). By way of example, processors suitable for the execution of a computer program include both general and special purpose microprocessors, and any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices for storing data (such as magnetic disks, magneto - optical disks, or optical disks), or be operatively coupled to receive data from or transfer data to them or both. However, a computer need not have such devices. Computer - readable media suitable for storing computer program instructions and data include all forms of non - volatile memory, media and memory devices, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto - optical disks; and CD ROM and DVD - ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0029] For providing interaction with a user, one or more aspects of the present disclosure can be implemented on a computer having a display device (such as a CRT (Cathode Ray Tube), LCD (Liquid Crystal Display) monitor, or touch screen) for displaying information to the user and optionally a keyboard and a pointing device (such as a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including sound, voice, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a web page to a web browser on a client device of the user in response to a request received from the web browser.

[0030] Historically, the development of vehicles has employed a data-intensive approach where the vehicle's on-board sensors generate large amounts of data that are sent to each individual electronic control unit (ECU) within the vehicle. In other words, sensor data is blindly sent between each individual ECU regardless of whether it has changed or is relevant to the receiving ECU. Additionally, data is sent regardless of whether other ECUs are subscribed to and / or present on the vehicle's network.

[0031] In contrast, in a service-oriented architecture (SOA), an ECU sends data only when at least one ECU on the network requires the data. Additionally, third-party applications can be installed in the vehicle and used in conjunction with the various ECUs present. Therefore, it is important to ensure that those applications do not impede existing safety protocols and deceive, for example, the ECUs required for braking in order to prevent the braking action of the vehicle driver. Since the ECUs in modern vehicles range from controlling the engine, airbags, brakes to any other critical system functions, preventing unintentional or malicious commands to the ECUs can avoid any outcome from harmless to dangerous. For example, allowing the acceleration ECU to accelerate the vehicle is crucial for preventing potential dangerous consequences. Therefore, ensuring that commands and / or messages are sent only from ECUs that are appropriately authorized to transmit messages and that the messages do not exceed the permissions of a particular ECU is essential for the security of the SOA.

[0032] To counter this, each ECU typically includes its own secret key to ensure that other ECUs cannot deceive each other. In existing designs, the ECUs are pre-populated with information about the identity and secret key of each ECU. Here, the receiving ECU verifies the ECU message received from the sending ECU by checking where the request originated and what permissions the sending ECU has. Therefore, when an ECU requests to transmit a message, the hardware security module (e.g., the secure environment) inside the requesting ECU identifies whether the requesting ECU is using its assigned secret key. Consequently, the hardware security module will not generate a message authentication code (MAC) for an ECU that is not using its assigned secret key. It is worth noting that in these configurations, the source ECU of each message needs to be pre-known by each ECU. However, if the message sent by an ECU moves to another ECU or the permissions change, all ECUs receiving the message must be updated. In contrast, self-regulating MAC generation within the ECU allows any change in the location or permissions of the ECU to be updated locally.

[0033] In addition, recent designs may employ a blunt approach to generating the MAC for an ECU. For example, a security entity may only determine whether a particular ECU can execute a service. However, with reference to a receiving ECU (e.g., a braking module), a first sending ECU may need to send a low-criticality message (e.g., clearing a braking status indicator), while a second sending ECU may need to send a high-criticality message (e.g., applying the brakes). Deciding on the application granularity within to generate the MAC via a self-regulating ECU not only increases the flexibility of the SOA but also allows for an opportunity to increase the protection of the sent critical data by defining ECU permission levels within the self-regulating system. Additionally, leveraging the decision to generate the MAC to define permissions with granularity allows, for example, a quality management client ECU to subscribe to another ECU for quality management messages but not for security rating messages.

[0034] Figure 1 An example system 100 is shown that includes a vehicle 10 and / or a remote system 60 that communicates with the vehicle 10 via a network 40. The vehicle 10 and / or the remote system 60 includes one or more devices 30 (also referred to as electronic control units (ECUs) 30) that execute a secure in-vehicle SOA with a message authentication code (MAC) generation allow list (MGAL) system 200 (also referred to as the MGAL system 200). In particular, the vehicle 10 includes a transmitting device 30T that communicates with a plurality of receiving devices 30R, 32a-n via the network 40. The network 40 may operate as an in-vehicle network 40 that facilitates communication between the devices 30 within the vehicle 10. Optionally, the vehicle 10 may include an in-vehicle network separate from the network 40, where the devices 30 communicate via the separate in-vehicle network.

[0035] In the example shown, the device 30 includes a host 210 and a security environment 220. The security environment 220 of the device 30 executes the MGAL system 200( Figures 2 - 3D) The MGAL system 200 self-regulates transmissions from the host 210 of the device 30 based on the granular permissions of the device 30 stored in the MAC Generation Allow List (MGAL) 232. In particular, in response to receiving a request 216 to transmit a message from the host 210, the MGAL system 200 ensures via the secure environment 220 that the secret key 234 (also referred to as the MAC generation key 234) of the transmitting device 30T cannot be used to generate a MAC 218 for a message with a criticality higher than that allowed for the transmitting device 30T to send. In other words, instead of the transmitting device 30T communicating with an external system to obtain the MAC 218 of the message, the secure environment 220 of the transmitting device 30T self-regulates the transmitting device 30T via the MGAL system 200. Additionally, through self-regulation, the MGAL system 200 provides the benefit of not requiring all receiving devices 30R to determine whether a message / request is from a verified transmitting device 30T and whether the transmitting device 30T is authorized (i.e., has an appropriate permission level 280) to transmit the message.

[0036] It is noted that, and as will be described in further detail below, each device 30 performs corresponding operations, where each device 30 can perform multiple operations with different criticalities and can operate as both a transmitting device 30T and a receiving device 30R. For example, the receiving device 30R can include a brake ECU with multiple operations, including low-criticality operations such as clearing a brake status indicator and high-criticality operations such as applying the brakes. In this example, the transmitting device 30T may have permission to request to send to the receiving device 30R for a low-criticality operation (e.g., clearing the status indicator), but the transmitting device 30T may not have permission to request to send to the receiving device 30R for a high-criticality operation (i.e., applying the brakes). By defining permissions at the operation level, the MGAL system 200 follows the principle of least privilege, where the device 30 is only given access to the operation level that is truly required for a particular device 30.

[0037] In the example shown, the device 30 implementing the MGAL system 200 is disposed within the vehicle 10. However, the MGAL system 200 can be implemented on other devices (e.g., a computing device communicating with the device 30), such as but not limited to a smart phone, a tablet, a smart display, or a vehicle infotainment device. The devices 30 can communicate with each other using standard communication technologies and / or protocols. Thus, the network 40 can include Wi-Fi (e.g., 802.11), Worldwide Interoperability for Microwave Access (WiMAX), 3G, 4G, Long Term Evolution (LTE), 5G, Digital Subscriber Line (DSL), Near Field Communication (NFC) or any other wireless standard. Vehicle 10 may include one or more access points (APs) (not shown) configured to facilitate wireless communication between device 30 and one or more other devices 30.

[0038] As Figure 1 shown, vehicle 10 includes data processing hardware 12 and memory hardware 14 storing instructions that, when executed on data processing hardware 12, cause data processing hardware 12 to perform operations. Remote system 60 (e.g., a server, a cloud computing environment) also includes data processing hardware 62 and memory hardware 64 storing instructions that, when executed on data processing hardware 62, cause data processing hardware 62 to perform operations. Confidential data storage device 66 may overlay memory hardware 64 of remote system 60 and is configured to store a corpus of confidential data 68, 68a - n associated with device 30. Additionally or alternatively, confidential data storage device 66 may be stored within memory hardware 14 of vehicle 10 or within memory hardware 224 of each respective device 30.

[0039] Additionally, host 210 includes data processing hardware 212 and memory hardware 214 storing instructions that, when executed on data processing hardware 212, cause data processing hardware 212 to perform operations. For example, when device 30 is an ECU, host 210 may perform relevant tasks required in such a case, as well as most or all of the application software of the ECU. Secure environment 220 includes data processing hardware 222 and memory hardware 224 storing instructions that, when executed on data processing hardware 222, cause data processing hardware 222 to perform operations. Memory hardware 224 of secure environment 220 includes a relatively small amount of executable code for execution on data processing hardware 222 to perform security - critical functions, such as generating security messages, managing keys, etc. Although secure environment 220 is shown as being physically co - located with host 210 within device 30, it should be understood that secure environment 220 may be coupled to device 30 and / or communicate wirelessly with device 30.

[0040] Reference Figure 1 and Figure 2, shows the MGAL system 200 of device 30, and the MGAL system 200 includes a host 210 communicating with a secure environment 220. The secure environment 220 includes a MAC generator module 230 and a MAC verification module 240. The MAC generator module 230 includes an MGAL 232 and can access the MAC generation key 234 of device 30. The MAC verification module 240 can access the MAC verification keys 236, 236a-n. The MAC generation key 234 and the MAC verification keys 236 are securely stored within the memory hardware 224 of the secure environment 220, and in some configurations, are stored within the MAC generator module 230 and the MAC verification module 240 respectively. It is noted that the MAC generation key 234 for device 30 is only accessible by the secure environment 220 and is not accessible by the host 210 or any third-party application running on or communicating with the host 210.

[0041] The MGAL 232 is stored within the memory hardware 224 of the secure environment 220, and for each device 30, includes one or more method IDs 219 and the corresponding permission levels 280 for each service that device 30 will use to perform operations (i.e., method calls) within the MGAL system 200. In Figure 2 the example shown, the MGAL 232 can sort the method IDs 219 and the corresponding permissions 280 for each service performed by device 30 based on the identity 34 of each device 30. However, it should be understood that the permission levels 280 for each device 30 can be organized in any number of ways, such as based on the criticality level of the permission 280 (i.e., method ID219) rather than the identity 34 of device 30. For example, for each device 30 listed in the MGAL 232, the MGAL 232 can include a list of services (i.e., other devices 30) and the corresponding highest permission levels for the respective services. In some embodiments, the permission level is closely related to the criticality level based on the security impact of the transmitted message request 216. Here, a higher permission level can correspond to a transmitted request 216 that affects the safety aspects of vehicle 10 (e.g., braking, acceleration), while a lower permission level can correspond to a transmitted request 216 related to the quality aspects of vehicle 10 (e.g., brake wear indicator, low windshield washer fluid indicator). For example, the brake module device 30 can be the only device 30 having the permission level 280 to apply brakes in vehicle 10. Thus, any device 30 that sends a transmitted message request 216 to apply brakes other than the brake module device 30 will be denied MAC by its own secure environment 220 for failing to have the permission level 280 to apply brakes.

[0042] When the host 210 of device 30 wishes to transmit a message, it sends a request 216 to transmit the message to the secure environment 220. The transmission request 216 includes a request for a MAC 218 and may also include MAC data such as a method ID 219, the type of data being transmitted, etc. As described above, in order to transmit a message, the secure environment 220 first verifies whether the request 216 to transmit the message exceeds the permissions of device 30 stored in the MGAL 232. For example, the transmission request 216 to transmit the message may also include the identity 34 of device 30 that uniquely identifies device 30, such that the secure environment 220 can determine the identity 34 of device 30 based on the transmission request 216 to transmit the message. Additionally, the transmission request may include a method ID 219 that identifies the type of service / operation requested by the transmission request 216. In some embodiments, the method ID 219 indicates the criticality level of the transmission request 216 to transmit the message, where the criticality level is based on the security impact of the transmission request 216 to transmit the message.

[0043] The secure environment 220 of the transmitting device 30T determines whether the transmission request 216 to transmit the message exceeds the permission level 280 of the identified device 30 based on the MGAL 232. For example, the MAC generator module 230 identifies the permission level 280 of the identified device 30 based on the service represented by the method ID 219 included in the transmission request 216 stored in the MGAL 232. The MAC generator module 230 may compare the criticality level indicated by the method ID 219 included in the transmission request 216 with the permission level 280 of the service that provides the method call for the transmitting device 30T stored in the MGAL 232. When the transmission request 216 to transmit the message does not exceed the permission level 280 of the identified device 30, the MAC generator module 230 may retrieve the MAC generation key 234 assigned to the identified device 30 and use the MAC generation key 234 assigned to the identified device 30 to generate the MAC 218. Conversely, when the transmission request 216 to transmit the message exceeds the permission level 280 of the identified device 30, the secure environment 220 rejects the transmission request 216.

[0044] Continue to refer to Figure 2, when the host 210 receives a message including the MAC 218, it can send the MAC 218 to the secure environment 220 to verify the authenticity of the message. Here, the MAC verification module 240 receives the MAC 218 and any additional MAC verification data to determine whether the received MAC 218 is derived from a genuine key. For example, the MAC verification data can include the key serial number of the MAC generation key 234. The MAC verification module 240 can compare the key serial number of the MAC generation key 234 used to generate the MAC 218 with the MAC verification key 236. When the MAC verification module 240 confirms that the MAC 218 is genuine, it can indicate to the host 210 that the MAC 218 has been verified. Conversely, when the MAC verification module 240 identifies that the MAC 218 represents spoofing, it rejects the message and discards the MAC 218. Additionally, the MAC verification module 240 can indicate to the host 210 that the MAC 218 has not been verified.

[0045] In some embodiments, the request 216 to transmit a message further includes a request for the confidential data 68. Here, the MGAL system 200 can also perform a confidential transmission of the confidential data 68 via the secure environment 220. Refer to Figures 3A - 3D , an exemplary system 300, 300a - d is shown, where the request 216 to transmit a message further includes a request for the confidential data 68. In these embodiments, in addition to verifying that the request 216 to transmit a message does not exceed the permission level 280 of the identified device 30, the secure environment 220 also determines whether the device 30 is approved to receive the confidential data 68. Here, the method ID 219 included in the transmission request 216 can also indicate that the transmission request 216 includes a request for the confidential data 68. Based on the permission 280 in the MGAL 232, the secure environment 220 can determine whether the device 30 is approved to receive the confidential data 68, and when the secure environment 220 determines based on the MGAL 232 that the device 30 is approved to receive the confidential data 68, additional steps can be taken to protect the confidential data 68. Although the following systems 300a - 300d generally refer to the transmitting device 30T communicating with the server 60, it should be understood that these embodiments can be between the transmitting device 30T and the receiving device 30R within the vehicle 10, where the receiving device 30R stores the confidential data 68 that the transmitting device 30T is requesting. Optionally, the secure environment 330 of the receiving device 30R verifies the transmission request 216 including the request for the confidential data 68 by first verifying the MAC 218 on the transmission request 216 received from the transmitting device 30T.

[0046] Specifically refer to Figure 3A, Example system 300a shows that host 210 includes a public-private asymmetric key pair, which includes public key 252 and private key 254. Here, simultaneously with, or shortly after, transmission request 216 including MAC 218 and the request for confidential data 68, security environment 220 receives public key 254 from host 210. Security environment 220 determines that device 30 is approved to receive confidential data 68 based on MGAL 232. Here, remote system 60 can authenticate public key 252 and then use the public key 252 received from host 210 to encrypt confidential data key 256 before sending the encrypted confidential data 68E and encrypted confidential data key 256E to host 210. When host 210 receives the encrypted confidential data key 256E and encrypted confidential data 68E, it can use private key 254 to decrypt the encrypted confidential data key 256E in order to decrypt the encrypted confidential data 68E to access the plaintext confidential data 68.

[0047] Reference Figure 3B , Example system 300b shows host 210 and remote system 60 each including secret key 258. Secret key 258 can be pre-shared during the assembly of vehicle 10. Here, after receiving transmission request 216 including the request for confidential data 68, security environment 220 determines that device 30 is approved to receive confidential data 68 based on MGAL 232. Remote device 60 and / or security environment 220 can confirm the request for confidential data 68 and use the pre-shared secret key 258 to encrypt confidential data key 256 before sending the encrypted confidential data 68E and encrypted confidential data key 256E to host 210. When host 210 receives the encrypted confidential data key 256E and encrypted confidential data 68E, it can use the pre-shared secret key 258 to decrypt the encrypted confidential data key 256E in order to decrypt the encrypted confidential data 68E to access the plaintext confidential data 68.

[0048] Reference Figure 3C , Example system 300c can include an instance where it is acceptable to expose confidential data key 256 to limited device 30 for a limited time. Here, after receiving transmission request 216 including MAC 218 and the request for confidential data 68, security environment 220 determines that device 30 is approved to receive confidential data 68 based on MGAL 232. Thereafter, MGAL system 200 receives the secret confidential data key from remote system 60 and decrypts the encrypted confidential data 68E to access the plaintext confidential data 68.

[0049] Reference Figure 3D, example system 300d may include an instance that can establish a secure connection 262 between the secure environment 220 and the remote system 60. For example, the secure connection 262 may include a virtual local area network (VLAN) that establishes a dedicated communication channel that does not expose the confidential data 68 in an unacceptable manner. In these specific embodiments, after receiving the transfer request 216 that includes a request for the confidential data 68, the secure environment 220 determines, based on the MGAL 232, that the device 30 is approved to receive the confidential data 68. Thereafter, the MGAL system 200 establishes a secure connection 262 with the remote system 60 and receives the confidential data 68 from the remote system 60.

[0050] Figure 4 A flowchart of an example arrangement of operations of a method 400 for a secure vehicle service-oriented architecture having a message authentication code (MAC) generation allow list (MGAL) 232. Data processing hardware (e.g., Figure 1 the data processing hardware 212, 222, 62) may execute instructions stored in memory hardware (e.g., Figure 1 the memory hardware 214, 224, 64) to perform an example arrangement of the operations of method 400. At operation 402, method 400 includes receiving, at the secure environment 220, a request 216 to transfer a message, the request 216 to transfer a message including a request for a message authentication code 218. At operation 404, method 400 further includes determining the identity 34 of the device 200 based on the request 216 to transfer a message.

[0051] Method 400 further includes, at operation 406, determining, based on the message authentication code generation allow list (MGAL) 232, that the request 216 to transfer a message does not exceed the permission level 280 of the identified device 200. Here, the permission level 280 of the identified device 200 corresponds to the method ID 219 of the service being requested and is stored in the MGAL 232. At operation 408, method 400 further includes obtaining a secure environment key 234 (also referred to as a MAC generation key 234). The secure environment key 234 is only accessible by the secure environment 220. At operation 410, method 400 further includes using the secure environment key 234 assigned to the identified device 200 to generate the message authentication code 218.

[0052] Numerous embodiments have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of the present disclosure. Accordingly, other embodiments are within the scope of this application.

[0053] The foregoing description is provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. The individual elements or features of a particular configuration are generally not limited to that particular configuration but, where applicable, are interchangeable and can be used in a selected configuration, even if not specifically shown or described. It can also vary in many ways. Such variations should not be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.

Claims

1. A computer-implemented method that, when executed on data processing hardware, causes the data processing hardware to perform operations, the operations including: Receiving, at a secure environment, a request to transmit a message from a device, the request to transmit a message including a request for a message authentication code; Determining, based on the request to transmit a message, the identity of the device; Determining, based on a message authentication code generation allow list, that the request to transmit a message does not exceed the permission level of the identified device, the permission level of the identified device being stored in the message authentication code generation allow list; Obtaining a secure environment key assigned to the identified device, the secure environment key being accessible only by the secure environment; And Generating the message authentication code using the secure environment key assigned to the identified device.

2. The method according to claim 1, wherein the device is located within a vehicle.

3. The method according to claim 1, wherein the message authentication code generation allow list is stored in a memory hardware of the secure environment.

4. The method according to claim 1, wherein the request to transmit a message further includes a message identifier (ID) indicating a criticality level of the transmission request, the criticality level being based on a security impact of the request to transmit a message.

5. The method according to claim 1, wherein the secure environment is coupled to the device.

6. The method according to claim 1, wherein the request to transmit a message further includes a request for confidential data.

7. The method according to claim 6, wherein the operations further include: Receiving a public key from the device; Determining, based on the message authentication code generation allow list, that the device is approved to receive the confidential data; And Receiving an encrypted confidential data key, the confidential data key being encrypted using the public key.

8. The method according to claim 6, wherein the operations further include: Determining, based on the message authentication code generation allow list, that the device is approved to receive the confidential data; And Receiving an encrypted confidential data key, the confidential data key being encrypted using a pre-shared secret key held by the device and a remote system.

9. The method according to claim 6, wherein the operations further include: Determining, based on the message authentication code generation allow list, that the device is approved to receive the confidential data; And Receiving a secret confidential data key, the secret confidential data key being used to decrypt the confidential data.

10. The method according to claim 6, wherein the operations further include: Determining, based on the message authentication code generation allow list, that the device is approved to receive the confidential data; Establishing a secure connection with a remote system; And Receiving the confidential data from the remote system.

Images