Method for securing an on-board service-oriented architecture with an authorization list (MGAL) for generating a message authentication code (MAC)

Abstract

A method for a secure in-vehicle service-oriented architecture with a MAC creation allowlist includes receiving a message delivery request from a device in a secure environment. The delivery request includes a request for a message authentication code. The method also includes determining an identity of the device from the delivery request and determining, using a message authentication allowlist, that the delivery request does not exceed any permission level of the device. The device's permission level is stored in the message authentication allowlist.The method also includes obtaining a secure environment key assigned to the device, the secure environment key being accessible only to the secure environment, and generating the message authentication code using the secure environment key assigned to the device.

Description

INTRODUCTION

[0001] The information contained in this section is intended to provide a general context for the disclosure. Work by the presently named inventors, to the extent described in this section, as well as aspects of the description that might not otherwise be considered prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against this disclosure.

[0002] This disclosure generally relates to a secure on-board service-oriented architecture using a message authentication code (MAC) generate allow list (MGAL). Modern vehicles are experiencing rapid technological advances in in-vehicle electronics and associated software. For example, electronic control units (ECUs) are used as embedded systems in the vehicle that control various electromechanical systems. However, within a service-oriented architecture (SOA) and without appropriate security measures, ECUs are vulnerable to spoofing by a fake or compromised ECU.To solve this problem, systems may include a MAC creation allow list (MGAL) to determine whether a MAC may be created before a message can be transmitted from an ECU.

[0003] Without a valid MAC, the receiving ECUs reject the transmitted message.

[0004] DE 10 2023 120 427 A1 discloses an electronic control unit (ECU) or node configured to use a single key for all virtual ECUs (V-ECUs) that have a message to transmit. The ECU may also include a security peripheral containing the stored common key. The security peripheral may further include a policy that allows it to detect whether a request from the V-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), which may define the policy regarding when the V-ECU is allowed to transmit.

[0005] DE 10 2019 101 628 A1 discloses a vehicle-side relay device that is connected to a first vehicle-side device and a second vehicle-side device via a vehicle-side network and forwards a message transmitted from the first vehicle-side device to the second vehicle-side device, includes a processor configured to receive an authorization request to transmit a first message from the first vehicle-side device, to determine whether the total sum of the utilization rate of the bandwidth of the vehicle-side network used by at least one message that is already allowed to be transmitted via the vehicle-side network and the utilization rate of the bandwidth of the vehicle-side network used by the first message is equal to or less than a predetermined threshold, and to generate a response that allows the transmission of the first message,to the first vehicle-side device if the sum is equal to or less than the specified threshold.

[0006] US 2019 / 0080059 A1 discloses an information processing device comprising one or more processors. The processor is configured to execute a process and manage a process manager. The process includes a key generator, an authentication code generator, and an output unit.

[0007] US 2023 / 0344645 A1 discloses an electronic control unit used in a vehicle and comprising at least one electronic control unit. The at least one electronic control unit is configured to: store a public key; receive a role list for specifying a specific job that may be performed by the at least one electronic control unit; perform signature verification of the role list using the public key; set an available job list based on the role list verified by signature verification; and execute a specific job process when receiving a request message requesting a specific job set in the available job list. SUMMARY

[0008] One aspect of the disclosure provides a computer-implemented method for securing an on-board service-oriented architecture with an allow list (MGAL) for generating a message authentication code (MAC) that, when executed on computing hardware, causes computing hardware to perform operations including receiving a request to transmit a message from a device in a secure environment, the request to transmit the message including a request for a message authentication code, and determining an identity of the device from the request to transmit the message. The request to transmit the message further includes a message identifier (ID) indicating a criticality level of the request to transmit the message. The criticality level is based on a security impact of the request to transmit the message.The operations also include determining, using an allowlist to generate a message authentication code, that the request to transmit the message does not exceed any authorization level of the identified device. The authorization level of the identified device is stored here in the allowlist to generate a message authentication code. The operations also include obtaining a secure environment key assigned to the identified device, where the secure environment key is accessible only to the secure environment, and generating the message authentication code using the secure environment key assigned to the identified device.

[0009] Embodiments of the disclosure may include one or more of the following optional features. In some embodiments, the device is located in a vehicle. In some examples, the allowlist for generating a message authentication code is stored in the memory hardware of the secure environment. In some examples, the secure environment is coupled to the device.

[0010] In some embodiments, the request to transmit the message further includes a request for confidential data. In these embodiments, the operations may further include receiving a public key from the device, determining that the device is authorized to receive the confidential data based on the allowlist to generate a message authentication code, and receiving an encrypted confidential data key, wherein the confidential data key is encrypted with the public key.Alternatively, the operations may further comprise determining from the allowlist that the device is authorized to receive the confidential data to generate a message authentication code, and receiving an encrypted confidential data key, wherein the confidential data key is encrypted using a pre-shared secret key contained within the device and a remote system. Alternatively, the operations may further comprise determining from the allowlist that the device is authorized to receive the confidential data to generate a message authentication code, and receiving a confidential data secret key, wherein the confidential data secret key is used to decrypt the confidential data.The operations may optionally include determining that the device is authorized to receive the confidential data by using the allowlist to generate a message authentication code, establishing a secure connection with a 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 and are not intended to limit the scope of the present disclosure. Fig. Figure 1 is a schematic view of an example secure on-board service-oriented architecture system with a MAC creation allow list (MGAL). Fig. 2 is a schematic view of exemplary components of the system of Fig. 1. Fig. 3A-3D are schematic views of exemplary components of the system from Fig. 1 for the transmission of confidential data. Fig. 4 is a flowchart of an exemplary grouping of operations for a secure onboard service-oriented architecture with a MAC creation allow list (MGAL) method.

[0012] Corresponding reference symbols indicate corresponding parts in the drawings. DETAILED DESCRIPTION

[0013] Example embodiments will now be described in more detail with reference to the accompanying drawings. Example embodiments are provided to fully illustrate this disclosure and to convey its full scope to those of ordinary skill in the art. Specific details are provided, such as examples of specific components, devices, and methods, to provide a thorough understanding of the embodiments of the present disclosure. Those of ordinary skill in the art will recognize that specific details need not be used, that example embodiments may be embodied in many different forms, and that the specific details and example embodiments should not be construed to limit the scope of the disclosure.

[0014] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular articles “a,” “an,” and “the” are intended to include the plural forms where appropriate. The terms “comprise,” “comprising,” “including,” and “having” are inclusive and thus indicate the presence of 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 being performed in the particular order discussed or illustrated unless they are expressly identified as being in such order of performance.Additional or alternative steps may be applied.

[0015] Where an element or layer is described as being "on" or "engaging with" another element or layer, or as being "connected" or "coupled" or "attached" to it, it may be directly on or engaging with, connected, coupled, or attached to the other element or layer, or there may be intervening elements or layers. Conversely, where an element is described as being "directly on" or "directly engaging with" another element or layer, or as being "directly connected" or "directly coupled" or "directly attached" to it, there must be no intervening elements or layers. Other words used to describe the relationship between elements should be interpreted similarly (e.g.,(e.g., "between" versus "directly between," "adjacent" or "contiguous" versus "directly adjacent" or "directly adjacent," etc.). As used herein, the term "and / or" includes any combination of one or more of the related listed items.

[0016] 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 only be used to distinguish one element, component, region, layer, or section from another region, layer, or section. Unless clearly dictated by the context, terms such as "first," "second," and other numerical terms do not imply a particular sequence or order.Thus, a first element, component, region, layer, or section discussed below could be referred to as a second element, component, region, layer, or section without departing from the teachings of the exemplary embodiments.

[0017] For the purposes of this application and the definitions below, the term "module" may be replaced by the term "circuit." The term "module" may refer to, be part of, or include: an application-specific integrated circuit (ASIC), a digital, analog, or mixed analog / digital discrete circuit, a digital, analog, or mixed analog / digital integrated circuit, a combinational logic circuit, a field-programmable gate array (FPGA), a processor (shared, dedicated, or group) that executes code, a memory (shared, dedicated, or group) that stores code executed by a processor, other suitable hardware components that provide the described functionality, or a combination of some or all of the above components, e.g., in a system-on-chip.

[0018] The term "code," as used above, may include software, firmware, and / or microcode and may refer to programs, routines, functions, classes, and / or objects. The term "shared processor" includes a single processor that executes code from multiple modules, in part or in whole. The term "group processor" includes a processor that, in combination with additional processors, executes code from one or more modules, in part or in whole. The term "shared memory" includes a single memory that stores code from multiple modules, in part or in whole. The term "group memory" includes memory that, in combination with additional memory, stores code from one or more modules, in part or in whole. The term "memory" may be a subset of the term "computer-readable medium."The term "computer-readable medium" does not encompass transitory electrical or electromagnetic signals propagating through a medium and can therefore be considered tangible and non-transitory storage. Non-limiting examples of non-transitory storage include tangible, computer-readable medium, including non-volatile memory, magnetic storage, and optical storage.

[0019] The devices 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 be based on stored data.

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

[0021] Non-transitory memory can be physical devices used to temporarily or permanently store programs (e.g., sequences of instructions) or data (e.g., program state information) for use by a computing device. Non-transitory memory can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electronically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware such as boot programs). Examples of volatile memory include random-access memory (RAM), dynamic random-access memory (DRAM), static random-access memory (SRAM), phase-change memory (PCM), and floppy disks or tapes.

[0022] These computer programs (also referred to as programs, software, software applications, or code) contain machine instructions for a programmable processor and may be implemented in a high-level procedural and / or object-oriented programming language and / or assembly language / machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable media, apparatus, and / or device (e.g., magnetic disks, optical disks, memories, programmable logic devices (PLDs)) designed to deliver machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal designed to deliver machine instructions and / or data to a programmable processor.

[0023] Various embodiments of the systems and techniques described herein may be implemented in digital electronic and / or optical circuits, integrated circuits, purpose-built ASICs (Application Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include embodied in one or more computer programs executable and / or interpretable on a programmable system comprising at least one programmable processor, which may be used for special or general purpose and is coupled to receive data and instructions from and transmit data and instructions to a storage system, and at least one input device and at least one output device.

[0024] The processes and logic flows described in this patent may be performed by one or more programmable processors, also referred to as data processing hardware, which execute one or more computer programs to perform functions by responding to input data and generating output. The processes and logic flows may also be performed by special-purpose logic circuits, such as an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit). Processors suitable for executing a computer program include, for example, both general-purpose and special-purpose microprocessors, as well as one or more processors of any type of digital computer. Generally, a processor receives instructions and data from read-only memory or random-access memory, or both.The essential elements of a computer are a processor for executing instructions, and one or more storage devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to, one or more mass storage devices for storing data, such as magnetic, magneto-optical, or optical disks, or both. However, a computer is not required to have such devices. Computer-readable media suitable for storing computer program instructions and data includes all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage 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 memory can be supplemented by or integrated into special logic circuits.

[0025] To enable interaction with a user, one or more aspects of the disclosure may be implemented on a computer having a display device, e.g., a CRT or LCD monitor or a touchscreen for displaying information to the user, and optionally, a keyboard and pointing device, e.g., a mouse or trackball, for the user to provide input to the computer. Other types of devices may also be used to enable interaction with the user; for example, the user may receive any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including auditory, voice, or tactile input. In addition, a computer may interact with a user by sending and receiving documents to and from a device used by the user, e.g.,by sending web pages to a web browser on a user's client device after receiving requests from the web browser.

[0026] Historically, vehicle development has taken a data-intensive approach, with the vehicle's main sensors generating extensive data that was transmitted to every single electronic control unit (ECU) in the vehicle. In other words, sensor data was sent blindly between each ECU, regardless of whether it had changed or was relevant to the receiving ECU. Furthermore, the data was sent regardless of whether other ECUs were logged on and / or on the vehicle's network.

[0027] In contrast, in a service-oriented architecture (SOA), an ECU only transmits data when at least one ECU in the network requires it. Furthermore, third-party applications may be installed in the vehicle and used in conjunction with the various existing ECUs. Therefore, it is important to ensure that these applications do not counteract existing safety protocols and, for example, spoof the ECUs required for braking and prevent the driver from braking. Since ECUs in modern vehicles control the engine, airbags, brakes, and other critical system functions, preventing inadvertent or harmful instructions to an ECU can have both harmless and dangerous consequences. For example, permissions for an acceleration ECU to accelerate the vehicle are crucial to avoiding potentially dangerous consequences.Therefore, it is essential for the security of the SOA to ensure that instructions and / or messages are issued only by an ECU that is properly authorized to send the messages and that the message does not exceed the permissions of the respective ECU.

[0028] To counteract this, each ECU generally has its own secret key to ensure that other ECUs cannot deceive each other. In existing implementations, the ECUs are already equipped with information about the identities and secret keys of each ECU. The receiving ECU verifies the ECU message received from a sending ECU by checking the origin of the request and the sending ECU's permissions. Thus, when an ECU requests the transmission of a message, a hardware security module (e.g., a secure environment) within the requesting ECU determines whether the requesting ECU is using a secret key belonging to it. Therefore, the hardware security module does not generate a message authentication code (MAC) for an ECU that is not using its assigned secret key. In these implementations, the originating ECU of each message must be known in advance to each ECU.However, if a message sent by one ECU is forwarded to another ECU, or if permissions change, all ECUs receiving that message must be updated. In contrast, self-regulating MAC creation within the ECU allows any location or permission changes to be updated locally for the ECU.

[0029] In addition, newer designs can take a direct approach to creating a MAC for an ECU. For example, a secure location can only determine whether a specific ECU can perform a service or not. However, for a receiving ECU (e.g., a brake module), a first sending ECU may need to send low-criticality messages (e.g., clearing a brake status indicator), while a second sending ECU may need to send a high-criticality message (e.g., applying the brake). Granularity in MAC creation decisions through ECU self-regulation not only increases the flexibility of the SOA but also offers the opportunity to increase the protection of the transmitted critical data by specifying ECU authorization levels within the self-regulating system. In addition, specifying granular authorizations in MAC creation decisions allows, for example,a quality-controlled client ECU can switch on another ECU for quality-controlled messages, but not for safety-related messages.

[0030] Fig. 1 shows an exemplary system 100 including a vehicle 10 and / or a remote system 60 communicating with the vehicle 10 via a network 40. The vehicle 10 and / or the remote system 60 include one or more devices 30 (also called electronic control unit (ECU) 30) executing a secure on-board SOA with a message authentication code (MAC) generation permission list (MGAL) system 200 (also called MGAL system 200). In particular, the vehicle 10 includes a transmitting device 30T communicating with a plurality of receiving devices 30R, 32a-n via the network 40. The network 40 may operate as an on-board network 40 that facilitates communication between the devices 30 within the vehicle 10. The vehicle 10 may optionally include an on-board network separate from the network 40, via which the devices 30 communicate with each other.

[0031] In the example shown, the device 30 comprises a host 210 and a secure environment 220. In the secure environment 220 of the device 30, the MGAL system 200 is executed ( Fig. 2-3D) that self-regulates transmissions from the host 210 of the device 30 based on detailed permissions of the device 30 stored in a MAC creation allow list (MGAL) 232. In particular, upon receiving a request to transmit 216 a message from the host 210 via the secure environment 220, the MGAL system 200 ensures that the secret key 234 (also called the MAC creation key 234) for the sending device 30T cannot be used to create a MAC 218 for messages that have a higher criticality than the sending device 30T is authorized to transmit. In other words, the secure environment 220 of the sending device 30T self-regulates the sending device 30T via the MGAL system 200, rather than the sending device 30T communicating with an external system to obtain a MAC 218 for a message.In addition, the MGAL system 200 offers the advantage of self-regulation that not all receiving devices 30R have to determine whether a message / request originates from a verified sending device 30T and whether the sending device 30T is authorized (ie, has an appropriate authorization level 280) to send the message.

[0032] As described in more detail below, each of the devices 30 performs corresponding operations, where each device 30 can perform multiple operations of varying criticality and can function as both a transmitting device 30T and a receiving device 30R. For example, a receiving device 30R can include a brake controller that can perform multiple operations, including a low-criticality operation, such as clearing a brake status indicator, and a high-criticality operation, such as applying the brake. In this example, the transmitting device 30T can have permission to request transmission of the low-criticality operation to the receiving device 30R (e.g., clearing a status indicator), whereas the transmitting device 30T may not have permission to request transmission of the high-criticality operation to the receiving device 30R (i.e., applying the brake).By setting permissions at the operation level, the MGAL system 200 follows the principle of least privilege, where a device 30 is only granted access to the level of operations that it really needs for a particular device 30.

[0033] In the example shown, the device 30 executing the MGAL system 200 is located within the vehicle 10. However, the MGAL system 200 may also be implemented on other devices (e.g., computing devices in communication with the device 30), including, but not limited to, a smartphone, a tablet, a smart display, or a vehicle infotainment device. The device 30 may communicate with each of the other devices 30 using standard communication technologies and / or protocols. The network 40 may thus include Wireless Fidelity (WiFi®) (e.g., 802.11), Worldwide Interoperability for Microwave Access (WiMAX), 3G, 4G, Long Term Evolution (LTE), 5G, Digital Subscriber Line (DSL), Bluetooth®, Near Field Communication (NFC), or any other wireless standard.The vehicle 10 may include one or more access points (APs) (not shown) configured to enable wireless communication between the device 30 and one or more other devices 30.

[0034] As in Fig. 1, the vehicle 10 includes computing hardware 12 and storage hardware 14 storing instructions that, when executed on the computing hardware 12, cause the computing hardware 12 to perform operations. The remote system 60 (e.g., server, cloud computing environment) also includes computing hardware 62 and storage hardware 64 storing instructions that, when executed on the computing hardware 62, cause the computing hardware 62 to perform operations. A confidential data store 66 may be overlaid on the storage hardware 64 of the remote system 60 and is configured to store a corpus of confidential data 68, 68a-n associated with the devices 30.Additionally or alternatively, the storage 66 for confidential data may be stored in the storage hardware 14 of the vehicle 10 or in the storage hardware 224 of the respective devices 30.

[0035] Additionally, host 210 includes computing hardware 212 and memory hardware 214 storing instructions that, when executed on computing hardware 212, cause computing hardware 212 to perform operations. For example, if device 30 is an ECU, host 210 may execute the tasks required under the circumstances, as well as most or all of the application software for the ECU. Secure environment 220 includes computing hardware 222 and memory hardware 224 storing instructions that, when executed on computing hardware 222, cause computing hardware 222 to perform operations.The storage hardware 224 of the secure environment 220 includes a relatively small amount of executable code that runs on the computing hardware 222 to perform security-critical functions such as creating security messages, managing keys, etc. While the secure environment 220 is physically located with the host 210 within the device 30, it should be appreciated that the secure environment 220 may be coupled to the device 30 and / or in wireless communication therewith.

[0036] With reference to Fig. 1 and Fig. 2, the MGAL system 200 of device 30 is shown and includes host 210 in communication with secure environment 220. Secure environment 220 includes a MAC creation module 230, which includes MGAL 232 and has access to the MAC creation key 234 for device 30, and a MAC verification module 240, which has access to the MAC verification keys 236, 236a-n. The MAC creation key 234 and the MAC verification keys 236 are securely stored in the storage hardware 224 of secure environment 220 and, in some embodiments, in the MAC creation module 230 and the MAC verification module 240, respectively. In particular, the MAC creation key 234 for the device 30 is accessible only to the secure environment 220 and not to the host 210 or third-party applications running on or communicating with the host 210.

[0037] The MGAL 232 is stored in the memory hardware 224 of the secure environment 220 and includes, for each device 30, one or more procedure IDs 219 and corresponding authorization levels 280 for each service that the device 30 uses to perform operations (ie, procedure calls) within the MGAL system 200. In the Fig. 2, the MGAL 232 may sort the procedure IDs 219 for each service that the device 30 performs and the corresponding permissions 280 based on the identity 34 of each device 30. However, it should be appreciated that the permission levels 280 for each device 30 may be organized in any manner, such as based on the criticality level (i.e., the procedure ID 219) of the permission 280 rather than based on the identity 34 of the device 30. For example, for each device 30 listed in the MGAL 232, the MGAL 232 may include a list of services (i.e., other devices 30) and a corresponding highest permission level for each service. In some embodiments, the permission levels are tied to a criticality level based on the security implications of the request to transmit 216 the message.A higher authorization level may correspond to a transmission request 216 concerning a safety aspect of the vehicle 10 (e.g., braking, acceleration), while a lower authorization level may correspond to a transmission request 216 concerning a quality aspect of the vehicle 10 (e.g., brake wear indicator, low windshield washer fluid indicator). For example, a brake module device 30 may be the only device 30 that has an authorization level 280 to apply the brake in the vehicle 10. Therefore, any device 30 other than the brake module device 30 that sends a transmission request 216 of a message to apply the brake will be denied a MAC by its own secure environment 220 because it does not have the authorization level 280 to apply the brake.

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

[0039] The secure environment 220 of the transmitting device 30T determines from the MGAL 232 whether the message delivery request 216 exceeds an authorization level 280 of the identified device 30. For example, the MAC creation module 230 identifies the authorization levels 280 of the identified device 30 based on the service represented by the method ID 219 contained in the delivery request 216 stored in the MGAL 232. The MAC creation module 230 may compare the criticality level indicated by the method ID 219 contained in the delivery request 216 with the authorization level 280 of the service providing the method invocation stored in the MGAL 232 for the transmitting device 30T.If the message delivery request 216 does not exceed the authorization level 280 of the identified device 30, the MAC creation module 230 can retrieve the MAC creation key 234 assigned to the identified device 30 and create the MAC 218 using the MAC creation key 234 assigned to the identified device 30. Conversely, the secure environment 220 rejects the message delivery request 216 if the message delivery request 216 exceeds the authorization level 280 of the identified device 30.

[0040] With further reference to Fig. 2, when the host 210 receives a message with a MAC 218, it may send the MAC 218 to the secure environment 220 to verify the authenticity of the message. In doing so, the MAC verification module 240 receives the MAC 218 and any additional MAC verification data to determine whether the received MAC 218 originated from an authentic key. The MAC verification data may include, for example, a key serial number of the MAC creation key 234. The MAC verification module 240 may compare the key serial number of the MAC creation key 234 used to create the MAC 218 with the MAC verification keys 236. If the MAC verification module 240 confirms that the MAC 218 is authentic, it may indicate to the host 210 that the MAC 218 has been verified. However, if the MAC verification module 240 determines that the MAC 218 is a forgery, it rejects the message and discards the MAC 218.Additionally, the MAC verification module 240 may indicate to the host 210 that the MAC 218 has not been verified.

[0041] In some embodiments, the request to transmit 216 the message further includes a request for confidential data 68. In doing so, the MGAL system 200 may further perform a confidential transmission of the confidential data 68 via the secure environment 220. With reference to Fig. 3A-3D illustrate example systems 300, 300a-d in which the message transmission request 216 further includes a request for confidential data 68. In these embodiments, the secure environment 220 not only checks whether the message transmission request 216 does not exceed the authorization level 280 of the identified device 30, but also determines whether the device 30 is authorized to receive the confidential data 68. The method ID 219 included in the transmission request 216 may further indicate that the transmission request 216 includes a request for confidential data 68. The secure environment 220 may determine whether the device 30 is authorized to receive confidential data 68 based on the authorizations 280 in the MGAL 232.If the secure environment 220 determines from the MGAL 232 that the device 30 is authorized to receive the confidential data 68, it may take additional measures to protect the confidential data 68. While the following systems 300a-300d generally refer to a transmitting device 30T in communication with the server 60, it should be appreciated that these embodiments may be located between a transmitting device 30T and a receiving device 30R within the vehicle 10, with the receiving device 30R storing confidential data 68 requested by the transmitting device 30T. The secure environment 330 of the receiving device 30R optionally verifies the request for transmission 216, including the request for confidential data 68, by first verifying the MAC 218 of the request for transmission 216 received from the transmitting device 30T.

[0042] With particular reference to Fig. 3A, the example system 300a shows the host 210 with a public-private asymmetric key pair comprising a public key 252 and a private key 254. The secure environment 220 receives the public key 254 from the host 210 simultaneously with the request for transmission 216 comprising the MAC 218 and the request for confidential data 68, or shortly thereafter. The secure environment 220 then determines from the MGAL 232 that the device 30 is authorized to receive the confidential data 68. The remote system 60 may authenticate the public key 252 and then use the public key 252 received from the host 210 to encrypt a confidential data key 256 before sending the encrypted confidential data 68E and the encrypted confidential data key 256E to the host 210.When the host 210 receives the encrypted confidential data key 256E and the encrypted confidential data 68E, it can use the private key 254 to decrypt the encrypted confidential data key 256E, to decrypt the encrypted confidential data 68E, and to access the plaintext confidential data 68.

[0043] With reference to Fig. 3B, the example system 300b shows that the host 210 and the remote system 60 each include a secret key 258. The secret key 258 may be shared during assembly of the vehicle 10. Upon receiving the transmission request 216 including the request for confidential data 68, the secure environment 220 determines from the MGAL 232 that the device 30 is authorized to receive the confidential data 68. The remote device 60 and / or the secure environment 220 may acknowledge the request for confidential data 68 and use the pre-shared secret key 258 to encrypt a confidential data key 256 before sending the encrypted confidential data 68E and the encrypted confidential data key 256E to the host 210.When the host 210 receives the encrypted confidential data key 256E and the encrypted confidential data 68E, it can use the pre-shared secret key 258 to decrypt the encrypted confidential data key 256E, to decrypt the encrypted confidential data 68E, and to access the plaintext confidential data 68.

[0044] With reference to Fig. 3C, the example system 300c may include cases where it is acceptable to share the confidential data key 256 with limited devices 30 for a limited time. Upon receiving the request to transmit 216, which includes the MAC 218 and the request for confidential data 68, the secure environment 220 determines from the MGAL 232 that the device 30 is authorized to receive the confidential data 68. The MGAL system 200 then obtains the secret confidential data key from the remote system 60 and decrypts the encrypted confidential data 68E to access the plaintext confidential data 68.

[0045] With reference to Fig. 3D, the example system 300d may include instances where a secure connection 262 may be established between the secure environment 220 and the remote system 60. The secure connection 262 could, for example, include a virtual local area network (VLAN) that establishes a private messaging channel that does not improperly disclose the confidential data 68. In these embodiments, upon receiving the request to transmit 216, which includes the request for confidential data 68, the secure environment 220 determines from the MGAL 232 that the device 30 is authorized to receive the confidential data 68. Thereafter, the MGAL system 200 establishes the secure connection 262 to the remote system 60 and receives the confidential data 68 from the remote system 60.

[0046] Fig. 4 includes a flowchart of an exemplary grouping of operations for a method 400 for a secure on-board service-oriented architecture with an allow list (MGAL) for generating a message authentication code (MAC) 232. The computing hardware (e.g., the computing hardware 212, 222, 62 of Fig. 1) can execute instructions that are stored on the memory hardware (e.g., the memory hardware 214, 224, 64 from Fig.1) are stored to perform the exemplary grouping of operations for method 400. At operation 402, method 400 includes receiving a request to transmit 216 a message from a device 200 in a secure environment 220, wherein the request to transmit 216 the message includes a request for a message authentication code 218. At operation 404, method 400 also includes determining an identity 34 of device 200 based on the request to transmit 216 the message.

[0047] At operation 406, the method 400 also includes determining, using an allowlist to create a message authentication code (MGAL) 232, that the request to transmit 216 the message does not exceed an authorization level 280 of the identified device 200. The authorization level 280 of the identified device 200 corresponds to a method ID 219 of the requested service and is stored in the MGAL 232. At operation 408, the method 400 further includes obtaining a secure environment key 234 (also called a MAC creation key 234). The secure environment key 234 is only accessible to the secure environment 220. At operation 410, the method 400 also includes creating the message authentication code 218 using the secure environment key 234 assigned to the identified device 200.

[0048] While several embodiments have been described, it should be understood that various changes may be made without departing from the spirit and scope of the disclosure. Accordingly, other embodiments are also within the scope of the following claims.

[0049] The foregoing description is for purposes of illustration and description. It is not intended to be exhaustive or limiting of the disclosure. Individual elements or features of a particular embodiment are generally not limited thereto, but are interchangeable and may be used in a selected embodiment even if not specifically shown or described. They may also be modified in a variety of ways. Such modifications are not to be construed as a departure from the disclosure, but rather are to be included within the scope of the disclosure.

Claims

[1] Computer-implemented method which, when executed on data processing hardware, causes it to perform operations comprising: receiving a request to transmit a message from a device (3) in a secure environment (220), the request to transmit the message comprising a request for a message authentication code and a message identifier (ID), the message identifier (ID) indicating a criticality level of the request to transmit, the criticality level being based on a security impact of the request to transmit the message; determining an identity of the device (3) based on the request to transmit the message; determining, based on an authorization list for creating a message authentication code, that the request to transmit the message does not exceed any authorization level of the identified device (3), wherein the authorization level of the identified device (3) is stored in the authorization list for creating a message authentication code; obtaining a secure environment key assigned to the identified device (3), the secure environment key being accessible only to the secure environment (220); and the creation of the message authentication code using the secure environment key assigned to the identified device (3). [2] Method according to claim 1, wherein the device (3) is located within a vehicle (10). [3] The method of claim 1, wherein the allowlist for generating a message authentication code is stored in the storage hardware of the secure environment. [4] The method of claim 1, wherein the secure environment (220) is coupled to the device (3). [5] The method of claim 1, wherein the request to transmit the message further comprises a request for confidential data. [6] The method of claim 5, wherein the operations further comprise: obtaining a public key from the device (3); determining, based on the authorization list to create a message authentication code, that the device (3) is authorized to receive the confidential data; and receiving an encrypted key for confidential data, whereby the key for confidential data is encrypted with the public key. [7] The method of claim 5, wherein the operations further comprise: determining, based on the authorization list to create a message authentication code, that the device (3) is authorized to receive the confidential data; and receiving an encrypted confidential data key, wherein the confidential data key is encrypted using a pre-shared secret key contained in the device (3) and in a remote system (60). [8] The method of claim 5, wherein the operations further comprise: determining, based on the authorization list to create a message authentication code, that the device (3) is authorized to receive the confidential data; and receiving a secret key for confidential data, wherein the secret key for confidential data is used to decrypt the confidential data. [9] The method of claim 5, wherein the operations further comprise: determining, based on the authorization list to create a message authentication code, that the device (3) is authorized to receive the confidential data; establishing a secure connection with a remote system (60); and receiving the confidential data from the remote system.

Images