SECURE MESSAGE SYSTEM AND METHOD TO USE IT

Abstract

A computer-implemented procedure that causes the data processing hardware to perform operations includes: generating a message with a header containing a message type and a service ID on a first device; receiving the message containing the header and a KSN of the first device on a second device; determining the message type of the message based on the header; verifying a MAC of the message on an HPCA of the second device based on the determined message type being a service event; obtaining a key location from a MACT based on the KSN from the message; identifying a key associated with the key location obtained from the MACT, based on the key location, where the key contains a primary key and / or a secondary key; and verifying the MAC using the key and the key location obtained from the MACT.

Description

INTRODUCTION

[0001] The information in this section serves to present the general context of the disclosure. Works of the inventors mentioned herein, insofar as they are described in this section, as well as aspects of the description that may not have been prior art at the time of filing, are neither expressly nor implicitly admitted as prior art against the present disclosure.

[0002] The present disclosure relates generally to a secure messaging system and a corresponding method, and in particular to a secure messaging system for vehicle equipment.

[0003] Modern vehicles have experienced rapid technological advancements in the amount of electronics and associated software they contain. For example, electronic control units (ECUs) are used as embedded systems within the vehicle to control various electromechanical systems. However, within a service-oriented architecture (SOA) and without adequate security measures, ECUs are vulnerable to manipulation or spoofing by a fraudster or a compromised ECU. To address this issue, systems can include a message authentication code (MAC) generation allow list (MGAL) to determine whether a MAC may be generated for a message to be transmitted by an ECU.

[0004] Without a valid MAC address, the receiving ECUs will reject the transmitted message.

[0005] DE 10 2023 120 351 A1 discloses an electronic control unit designed to use a single key for generating MAC requests from a security peripheral device. The security peripheral device contains the stored shared key and may also contain a policy that enables it to recognize whether a request from the V-ECU is valid and, if so, to generate a MAC. The security peripheral device is also used to store information in a MAC Generate Allow List (MGAL). SUMMARY

[0006] The object of the invention is to provide an improved computer-implemented method.

[0007] To solve the problem, a computer-implemented method with the features of claim 1 is provided. Advantageous embodiments of the invention can be found in the dependent claims, the description, and the drawings.

[0008] In some aspects, a computer-implemented procedure, when executed by data processing hardware, causes the data processing hardware to perform operations. These operations include: generating a message with a header containing a message type and a service identifier (ID) on a first device, where the message type is either a service identification or a service event; receiving the message, containing the header and a key serial number (KSN) of the first device, on a second device; and determining the message type of the message based on the header.The operations also include: verifying a message authentication code (MAC) of the message in a high-performance crypto accelerator (HPCA) of the second device based on the determined message type being the service event; obtaining a key location from a message authentication code table (MACT) based on the KSN from the message; identifying a key associated with the key location obtained from the MACT, based on the key location, where the key contains a primary key and / or a secondary key; and verifying the MAC using the key and the key location obtained from the MACT.

[0009] In some examples, determining the message type may involve ascertaining that the message type is a service identification. Optionally, the operations may include: receiving the message in a secure environment on the second device and generating a KSN / Service ID table outside of a secure environment on the first device, including storing the KSN and Service ID from the message. In some cases, generating the KSN / Service ID table may involve mapping a service offered in the message to the KSN of the second device. Optionally, verifying the MAC may involve determining an error based on the KSN from the message and the Service ID stored in the KSN / Service ID table. In other examples, determining the error may involve issuing an error message and terminating the service event.In other examples, identifying the key may involve executing a key derivation function and generating the secondary key.

[0010] In another aspect, a computer-implemented procedure, when executed by data processing hardware, causes the data processing hardware to perform operations. These operations are: generating a message with a header containing a message type and a service identifier (ID) on a first device, where the message type is either a service identifier or a service event; receiving the message, containing the header and a key serial number (KSN) of the first device, on a second device; determining the message type based on the header; and bypassing a Message Authentication Code (MAC) generation allow list (MGAL) based on the fact that the determined message type is a service event.The operations also include: comparing the service ID from the message with a stored service ID from a Message Authentication Code Table (MACT) based on the KSN from the message; validating the KSN against the MACT based on the service ID matching the stored service ID; and obtaining a key location from the MACT based on the validated KSN. The operations further include: identifying a key associated with the key location obtained from the MACT, based on the key location, where the key contains a primary key and / or a secondary key; and verifying the MAC using the key and the key location obtained from the MACT.

[0011] In some examples, determining the message type might involve ascertaining that the message type is a service identification. Optionally, the operations might include: receiving the message in a secure environment on the second device and generating a KSN / Service ID table outside of a secure environment on the first device, including storing the KSN and Service ID from the message. In other cases, generating the KSN / Service ID table might involve mapping a service offered in the message to the KSN of the second device. In other examples, MAC verification might involve determining an error based on the KSN from the message and the stored Service ID in the KSN / Service ID table, issuing an error message, and terminating the service event.Optionally, bypassing the MGAL can include verifying the service event using a high-performance crypto accelerator (HPCA). In other examples, key identification can involve executing a key derivation function and generating the secondary key.

[0012] In other aspects, a secure messaging system for a vehicle comprises data processing hardware and storage hardware that communicates with the data processing hardware. The storage hardware holds instructions that, when executed on the data processing hardware, cause it to perform operations. These operations include: generating a message with a header containing a message type and a service identifier (ID) on a first device, where the message type is either a service identification or a service event; receiving the message, containing the header and a key serial number (KSN) of the first device, on a second device; and determining the message type based on the header.The operations also include: verifying a message authentication code (MAC) of the message in a high-performance crypto accelerator (HPCA) of the second device based on the determined message type being the service event; obtaining a key location from a message authentication code table (MACT) based on the KSN from the message; identifying a key associated with the key location obtained from the MACT, based on the key location, where the key contains a primary key and / or a secondary key; and verifying the message authentication code (MAC) using the key and the key location obtained from the MACT.

[0013] In some examples, determining the message type may involve ascertaining that the message type is a service identification. Optionally, the operations may include: receiving the message in a secure environment on the second device and generating a KSN / Service ID table outside of a secure environment on the first device, including storing the KSN and Service ID from the message. In some cases, generating the KSN / Service ID table may involve mapping a service offered in the message to the KSN of the second device. In other cases, checking the MAC may involve determining an error based on the KSN from the message and the Service ID stored in the KSN / Service ID table. Optionally, determining the error may involve issuing an error message and terminating the service event. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The drawings described here serve only to illustrate selected configurations and are not intended to limit the scope of this disclosure. Fig. Figure 1 is a schematic representation of a vehicle equipped with a variety of devices configured with a secure messaging system according to the present disclosure; Fig. Figure 2 is an exemplary block diagram for a secure messaging system according to the present disclosure; Fig. Figure 3 is a schematic representation of messages exchanged between devices of a secure messaging system according to the present disclosure; Fig. Figure 4 is an exemplary schematic diagram of service identification between devices of a secure messaging system according to the present disclosure; Fig. Figure 5 is a schematic diagram of a message exchange between devices of a secure messaging system according to the present disclosure; Fig. Figure 6 is an exemplary flowchart of a MAC requirement for a secure messaging system according to the present disclosure; Fig. Figure 7 is an exemplary schematic representation of a service event between devices of a secure messaging system according to the present disclosure; Fig. Figure 8 is an exemplary schematic representation of a manipulated device during a service event between devices of a secure messaging system according to the present disclosure; and Fig. Figure 9 is a flowchart of a procedure for operating the secure messaging system.

[0015] The corresponding reference numbers denote the corresponding parts in the drawings. DETAILED DESCRIPTION

[0016] Exemplary configurations are now described in more detail with reference to the accompanying drawings. Exemplary configurations are provided so that this disclosure is thorough and conveys the full scope of the disclosure to those skilled in the art. Specific details are listed, such as examples of specific components, devices, and processes, to provide a thorough understanding of the configurations of this disclosure. It is clear to those skilled in the art that specific details need not be used, that exemplary configurations can be implemented in many different forms, and that the specific details and exemplary configurations should not be interpreted in such a way as to limit the scope of the disclosure.

[0017] The terminology used here serves only to describe certain exemplary configurations and is not intended to be restrictive. As used here, the singular articles "a," "an," and "the" can also include the plural forms unless the context clearly indicates otherwise. The terms "comprises," "comprehensive," "containing," and "exhibiting" are inclusive and therefore specify the presence of features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The procedural steps, processes, and operations described here are not to be interpreted as necessarily being carried out in the order discussed or presented, unless they are explicitly identified as such.Additional or alternative steps can be applied.

[0018] When an element or layer is described as "on," "engaging," "connected," "attached to," or "coupled" with another element or layer, it may be directly on, engaged, connected, attached, or coupled to that other element or layer, or there may be intervening elements or layers. Conversely, when an element is described as "directly on," "directly engaged with," "directly connected to," "directly attached to," or "directly coupled to" another element or layer, there must be no intervening elements or layers. Other words used to describe the relationship between elements should be interpreted similarly (e.g., "between" versus "directly between," "next to" versus "directly beside," etc.).As used here, the term “and / or” includes all combinations of one or more of the related listed elements.

[0019] The terms "first," "second," "third," etc., may be used here to describe different elements, components, regions, layers, and / or sections. These elements, components, regions, layers, and / or sections should not be restricted by these terms. These terms may only be used to distinguish one element, component, region, layer, or section from another. Terms such as "first," "second," and other numerical terms do not imply any sequence or order unless clearly indicated by the context. 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 deviating from the lessons of exemplary configurations.

[0020] In this application, including 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; memory (shared, dedicated, or group) that stores the code executed by a processor; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, e.g., in a system-on-a-chip.

[0021] The term "code," as used above, can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, and / or objects. The term "shared processor" refers to a single processor that executes some or all of the code from multiple modules. The term "group processor" refers to a processor that, in combination with other processors, executes some or all of the code from one or more modules. The term "shared memory" refers to a single memory that stores some or all of the code from multiple modules. The term "group memory" refers to a memory that, in combination with other memories, stores some or all of the code from one or more modules. The term "memory" can be a subset of the term "computer-readable medium."The term "computer-readable medium" excludes transitory electrical and electromagnetic signals propagating through a medium and can therefore be considered tangible and non-transient storage. Non-restrictive examples of non-transient storage include tangible, computer-readable media, including non-volatile memory, magnetic storage, and optical storage.

[0022] The devices and methods described in this application can be implemented in whole or in part by one or more computer programs executed by one or more processors. The computer programs contain processor-executable instructions stored on at least one non-transitory, tangible, computer-readable medium. The computer programs may also contain and / or access stored data.

[0023] A software application (i.e., a software resource) can refer to computer software that causes a computing device to perform a task. In some examples, a software application may be called an "application," "app," or "program." Examples of applications include system diagnostics applications, system administration applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0024] Non-transitory memory can be physical devices used to temporarily or permanently store programs (e.g., instruction sequences) or data (e.g., program status information) for use by a computer. 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.

[0025] 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 procedural and / or object-oriented high-level language and / or in assembly / machine language.

[0026] The terms "machine-readable medium" and "computer-readable medium" used herein refer to any computer program product, non-transient computer-readable medium, apparatus, and / or device (e.g., magnetic disks, optical disks, memory, programmable logic devices (PLDs)) that serves to provide 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 that serves to provide machine instructions and / or data to a programmable processor.

[0027] Various implementations of the systems and techniques described herein can be realized in digital electronic and / or optical circuits, integrated circuits, specially designed ASICs (application-specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system comprising at least one programmable processor, which can be used for special or general purposes and is coupled such that it receives data and instructions from and transmits data and instructions to a storage system, as well as at least one input device and at least one output device.

[0028] The processes and logical sequences described in this description can be executed by one or more programmable processors, also known as data processing hardware, which run one or more computer programs to perform functions by responding to input data and producing outputs. The processes and logical sequences can also be executed by specialized 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 specialized microprocessors, as well as one or more processors from any type of digital computer. Generally, a processor receives instructions and data from read-only memory, 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 also includes one or more mass storage devices for storing data, such as magnetic, magneto-optical, or optical disks, or is operationally connected to them to receive data from or transmit data to them. However, a computer does not necessarily have to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable media; magneto-optical disks; and CD-ROM and DVD-ROM disks.The processor and memory can be supplemented by special logic circuits or integrated into them.

[0029] To enable interaction with a user, one or more aspects of the revelation can be implemented on a computer that has a display device, such as a CRT (cathode ray tube), LCD (liquid crystal display), or touchscreen monitor to show information to the user, and optionally a keyboard and pointing device, such as a mouse or trackball, with which the user can input information into the computer. Other types of devices can also be used for user interaction; feedback to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and user input can be received in any form, including auditory, verbal, or tactile input.Furthermore, a computer can interact with a user by sending and receiving documents to and from a device used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.

[0030] As in the Fig. 1 and Fig. As shown in Figure 2, a secure messaging system 10 comprises and connects a multitude of devices 12, 12a-n that implement a service-oriented architecture 14. In some examples, the devices 12, 12a-n can be configured as part of a vehicle 16, so that the various devices 12, 12a-n can be communicatively coupled within the vehicle 16 via the secure messaging system 10. The service-oriented architecture 14 is configured on the data processing hardware 18, 18a-n of a controller 20, 20a-n of each device 12, 12a-n. The controller 20, 20a-n also includes storage hardware 22, 22a-n, which is configured to store commands which, when executed on the data processing hardware 18, 18a-n, cause the data processing hardware 18, 18a-n to perform operations according to the service-oriented architecture 14.

[0031] As described in more detail below, each of the devices 12, 12a-n performs corresponding operations, with each device 12, 12a-n being able to perform several operations with different criticalities and to function both as a transmitter 12, 12a-n and as a receiver 12, 12a-n. For example, a receiver 12, 12a-n may contain a brake controller that has several operations, including a low-criticality operation, such as clearing a brake status indicator, and a high-criticality operation, such as applying the brakes. In this example, the transmitting device 12, 12a-n may be permitted to request a transmission to the receiving device 12, 12a-n for a low-criticality operation (e.g., clearing a status indicator), but the transmitting device 12, 12a-n may not be permitted to request a transmission to the receiving device 12, 12a-n for a high-criticality operation (e.g., applying the brakes).By defining permissions at the level of operations, the secure messaging system 10 follows the principle of least privilege, whereby a device 12, 12a-n only receives access to the level of operations that it actually needs for a particular device 12, 12a-n.

[0032] In the example shown, the device 12, 12a-n, which runs the secure messaging system 10, is located in the vehicle 16. However, the secure messaging system 10 can also be implemented on other devices (e.g., on computer devices that communicate with the device 12, 12a-n), such as a smartphone, tablet, smart display, or infotainment system in a vehicle. The devices 12, 12a-n can communicate with each other device 12, 12a-n using standard communication technologies and / or protocols. For example, a network can communicate with the devices 12, 12a-n and may 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 other wireless standards. Vehicle 16 can additionally have one or more access points (APs).access points) (not shown) that are configured to enable wireless communication between the device 12, 12a-n and one or more of the other devices 12, 12a-n.

[0033] As in Fig. 1 and Fig. As shown in Figure 2, the devices 12, 12a-n are configured to exchange messages 30, 30a-n corresponding to the various services 24 assigned to each individual device 12, 12a-n. Each device 12, 12a-n is also capable of generating a message authentication code (MAC) 32, 32a-n, which is generated from the messages 30, 30a-n sent by the devices 12, 12a-n using a secret key 102, 102a-n. Each device 12, 12a-n is equipped with a secret key 102, 102a-n, which is used to generate MACs 32, 32a-n from the messages 30, 30a-n sent to other devices 12, 12a-n, as described here. Each device 12, 12a-n also contains a key serial number (KSN or key serial number) 34, 34a-n, which is unique for the respective device 12, 12a-n.For example, the KSN 34, 34a-n can be based on an Internet Protocol (IP) address of the respective device 12, 12a-n during the initial configuration of the device 12, 12a-n.

[0034] Message 30, 30a-n can be a service offer from one device 12, 12a-n to another device 12, 12a-n. Message 30, 30a-n has a header 40 containing a message type 42 and a service identifier (ID) 44, 44a-n. In some cases, the service ID 44, 44a-n indicates that message type 42 is a service identifier 46. In examples that do not involve service discovery, header 40 contains message type 40, service ID 44, and either a procedure ID or remote procedure call (RPC) ID 48, or a service event ID 50. Thus, header 40 typically contains a service identification 46, a procedure RPC 48, or a service event 50. The procedure described herein with respect to service identification 46 is generally the same for RPC 48, so the procedure described with respect to service discovery 46 can be applied to RPC 48.After service identification 48 is completed, the service ID 44, 44a-n is linked to the KSN 34, 34a-n of the device 12, 12an sending message 30, as described in more detail below. Each device 12, 12a-n is preconfigured with a MAC table (MACT, or message authentication code table) 60. During service identification 46, the MACT 60 links the KSN 34, 34a-n to a specific key location 70, which contains the key 102, 102a-n of the device 12, 12a-n associated with the KSN 34, 34a-n. The MACT 60 can also be used to link headers 40 to key locations 70 for messages 30, 30a-n that differ from the service identification 46. For example, in the case of messages 30, 30an, which are statically defined to originate from the same device 12, 12a-n, a corresponding head 40 of a message 30, 30a-n can be associated with a key location 70.

[0035] As in the Fig. As shown in Figures 2-7, the controller 20, 20a-n of the device 12, 12a-n includes a secure environment 100, 100a-n, which is described below. The secure environment 100, 100a-n can be a hardware security module. The secure environment 100, 100a-n can be configured as part of the data processing hardware 18, 18a-n and / or outside of the controller 20, 20a-n. In this way, the secure environment 100, 100a-n is securely isolated from direct external communication or actions, minimizing the potential for compromise of the secure environment 100, 100a-n. For example, the secure environment 100, 100a-n stores secret keys 102, 102a-n that are associated with the respective device 12, 12a-n. The secret keys 102, 102a-n are protected by the secure isolation of the secure environment 100, 100a-n.In this way, the secure environment 100, 100a-n is protected against potential compromise events that could otherwise impair the service-oriented architecture 14 described in more detail below.

[0036] The secret keys 102, 102a-n of the secure environment 100, 100a-n comprise a primary key 104, 104a-n and a secondary key 106, 106a-n derived from the primary key 104, 104a-n. For example, the secure environment 100, 100a-n uses a key derivation function 64 of the service-oriented architecture 14 to derive the secondary key 106, 106a-n. The primary key 104, 104a-n is also used by the secure environment 100, 100a-n to generate the MAC 32, 32a-n for the message 30, 30a-n. One or more of the devices 12, 12a-n can communicate with each other, and the MAC 32, 32a-n can be used in combination with the respective KSN 34, 34a-n to verify the message 30 generated by a sending device 12, 12a-n by a receiving device 12, 12a-n, as described below.

[0037] The controller 20, 20a-n of the device 12, 12a-n can also contain a high-performance crypto accelerator (HPCA) 200, 200a-n, which is run by the data processing hardware 18, 18a-n. In some cases, the controller 20, 20a-n does not need to contain an HPCA 200, 200a-n. In both configurations, the controller 20, 20a-n is configured to skip enforcing a MAC generation permission list (MGAL) 112 for MAC generation when message type 42 is a service event 50, as described below. In some cases, depending on the message type 42, the controller 20, 20a-n can activate either the secure environment 100, 100a-n or the HPCA 200, 200a-n.In other examples, the controller 20, 20a-n is configured to select either the secure environment 100, 100a-n or the HPCA 200, 200a-n to execute a service 24 based on the message type 42 of the received message 30. The service 24 generates a MAC 32, 32a-n from the message 30, 30a-n, using either the primary key 104, 104a-n for the service identifier 46 or RPCs 48, or the secondary key 106, 106a-n for service events 50. For example, if the message type 42 contains either the service identifier 46 or the RPC 48, the controller 20, 20a-n executes the secure environment 100, 100a-n. The service recognition 46 is configured to establish the service-oriented architecture 14 with respect to the device, so that each subsequent message with a message type 42 of the service event 50 can bypass the secure environment 100, 100a-n.This allows service events 50 to be verified by the HPCA 200, 200a-n instead of being processed by the secure environment 100, 100a-n.

[0038] In the Fig. Sections 2-4 describe the process of executing a service recognition 46. The secure environment 100, 100a-n is configured to determine whether device 12, 12a-n is authorized to transmit a message 30 by checking a MAC generation permission list (MGAL) 112 of device 12, 12a-n. The MAC generation permission list (MGAL) 112 is used by controller 20, 20a-n in conjunction with the primary key 104, 104a-n to determine whether a MAC address 32, 32a-n may be generated and transmitted to controller 20, 20a-n. To ensure that other controllers 20, 20a-n cannot manipulate each other, the secure environment 100, 100a-n uses the secret keys 102, 102a-n to restrict access to the generation of a MAC 32, 32a-n by evaluating the message 30 with the MGAL 112.The process of comparing each message 30 with the MGAL 112 by the secure environment 100, 100a-n is time-consuming and costly, so it is advantageous to selectively bypass the secure environment 100, 100a-n and the enforcement of the MGAL 112 and to use the HPCA 200, 200a-n described below. While the HPCA 200, 200a-n can be used to bypass the secure environment 100, 100a-n, it is also conceivable that the secure environment 100, 100a-n could be bypassed based on message type 42, which is a service event 50. For example, the controller 20, 20a-n can selectively bypass the enforcement of MGAL 112 if the message type 32 is a service event 50, regardless of whether the controller 20, 20a-n is equipped with the HPCA 200, 200a-n.

[0039] The secure environment 100, 100a-n can primarily be used during the execution of the service identification 46 and / or the RPCs 48, since the service identification 46 and / or the RPC 48 is the initial setup of communication between the various control units 20, 20a-n. For example, a first device 12a can send a message 30a with message type 42 "service identification 46", causing the first device 12a to search for another device 12, 12b-n that can offer a specific service 24. The first device 12a then receives a message 30b from the second device 12b offering the service 24, which also has message type 42 "service identification 46". The second device 12b uses the secure environment 100b of the second device 12b to obtain a MAC 32b for message 30b before sending message 30b to the first device 12a.The secure environment 100b first evaluates the MGAL 112 to determine if the device 12, 12a-n is authorized to offer the service 24. If the service 24 is authorized, the secure environment 100b generates the MAC 32b. If the service 24 is not authorized, the secure environment 100b sends back an error as part of message 30. Upon receiving an authorized message 30b, the device 12, 12a-n uses the MACT 60 to determine which secret key 102, 102a-n to use to verify the authenticity of the received message 30b.

[0040] As in Fig. As shown in Figure 6, the controller 20, 20a-n can receive a request regarding the MAC 32, 32a-n. For example, the MAC 32, 32a-n can be verified and / or generated based on a series of steps that depend on the message type 42 of the message 30, 30a-n. The controller 20, 20a-n determines the message type 42 at 500. If the message type 42 is a service identifier 46 or an RPC 48, the controller 20, 20a-n uses the KSN 34, 34a-n to locate key location 70 in a key location number field 72 of the MACT 60. Key slot 70 contains the secret key 102, 102a-n, which is used to verify the MAC 32, 32a-n of the received message 30, 30a-n. Controller 20, 20a-n determines which secret key 102, 102a-n (i.e., primary key 104, 104a-n or secondary key 106, 106a-n) is to be used to verify the MAC 32, 32a-n of the message 30, 30a-n.If the message type 42 is a service identifier 46 or an RPC 48, then the controller 20, 20a-n at 502 uses the KSN 34, 34a-n to find the primary key location 70 in the key location number field 72 of the MACT 60.

[0041] If message type 42 is not a service identifier 46 or an RPC 48, the controller 20, 20a-n determines at 504 whether message type 42 is a service event 50. If message type 42 is a service event 50, the controller 20, 20a-n determines at 506 whether the service ID 44, 44a-n in message 30, 30a-n matches the service ID 44, 44a-n and / or KSN 34, 34a-n stored in MACT 60. If a match is found, the controller (20, 20a-n at 508) uses the KSN (key number) 34, 34a-n, which is linked to the service ID 44, 44a-n, to locate the primary key location 70 in the key location number field 72 in MACT 60. If there is no match, the controller (20, 20a-n at 510) returns an error message indicating that either the check or the generation failed.

[0042] If message 30, 30a-n does not contain message type 42 of service event 50, then controller 20, 20a-n determines at 512 whether message 30, 30a-n has message type 42 of an unfindable service event 50. Controller 20, 20a-n can define service ID 44, 44a-n at the service level, rather than based on message type 42, if the service 24 offered in message 30, 30a-n does not have message type 42 that corresponds to service identifier 46, RPC 48, or service event 50. For example, controller 20, 20a-n can determine whether service ID 44, 44a-n is associated with message ID 84 in MACT 60. If so, then controller 20, 20a-n uses key location 70 in MACT 60. If this is not the case, controller 20, 20a-n checks at 518 whether a protected message ID 80 is contained in MACT 60.If the protected message ID 80 is located in MACT 60, then controller 20, 20a-n can use key location 70 in MACT 60. If this is not the case, controller 20, 20a-n cannot verify or generate MAC 32, 32a-n at 520.

[0043] Each message 30, 30a-n contains, in addition to the message type 42, a service ID 44, 44a-n, which is assigned to the KSN 34, 34a-n of the respective device 12, 12a-n (see Fig. 2 - 6). The MACT 60 links the KSN 34, 34a-n of the sending device 12, 12a-n to the key location 70 based on the service IDs 44, 44a-n contained in the message 30, 30a-n. For example, if the first device 12a receives a message 30b of the authorized service identification 46 from the second device 12b, the offered service 24 of message 30b is linked to the KSN 34b of the second device 12b in a KSN / service ID table 82. Each controller 20, 20a-n is configured with a MACT 60 that identifies a primary key location associated with messages 30, 30a-n that have a message type 42 of the service identification 46. The MACT 60 can be separated from the secure environment 100, 100a-n, so that the HPCA 200, 200a-n can access and reference the MACT 60 during the validation of messages 30.

[0044] As in Fig. As shown in Figures 2-4, the MACT 60 links the KSNs 34, 34a-n to their respective key locations 70 during service discovery 46, and each message 30, 30a-n during service discovery 46 uses the primary key 104, 104a-n of the sending device 12, 12a-n to generate the MAC 32, 32a-n. For example, during service discovery 46, a KSN / Service ID table 82 is created by the controller 20, 20a-n outside the secure environment 100, 100a-n to link each discovered Service ID 44, 44a-n to the KSN 34, 34a-n of the device 12, 12a-n that offered the service. Messages 30 and 30a-n each contain the KSN 34 and 34a-n of each device 12 and 12a-n, and the service ID 44 and 44a-n, in addition to the MAC 32 and 32a-n. MACT 60 links the KSN 34 and 34a-n to key locations 70, which are associated with the secret keys 102 and 102a-n of the respective device 12 and 12a-n.Key positions 70 are located in key position number field 72 of the MACT 60, which is assigned either to the secure environment 100, 100a-n or the HPCA 200, 200a-n.

[0045] The secret key used, 102, 102a-n, can depend on the message type, 42, so that the controller, 20, 20a-n, can determine which secret key, 102, 102a-n, to select based on the message type, 42, and the key location number field, 72. The MACT 60 links the key locations, 70, to the KSN, 34, 34a-n, and the service ID, 44, so that future MACs, 32, 32a-n, can be validated with the MACT 60 regardless of the message type, 42. The location of key location, 70 (i.e., in the secure environment, 100, 100a-n, or the HPCA, 200, 200a-n), specifies which secret key, 102, 102a-n, to use when verifying the message, 30, 30a-n.For example, if key location 70 is in the secure environment 100, 100a-n, the primary key 104, 104a-n is used to verify message 30, 30a-n, and if key location 70 is in the HPCA 200, 200a-n, the secondary key 106, 106a-n is used to verify message 30. The receiving devices 12, 12a-n typically use the HPCA 200, 200a-n to authenticate messages 30, 30a-n, since MGAL 112 enforcement only occurs in the sending device 12, 12a-n.

[0046] In the Fig. 2, Fig. 6 and Fig. Section 7 describes an example of the process for generating and receiving messages 30, 30a-n with a message type 42 of service event 50. Service events 50 include all messages 30, 30a-n published by a server after service identification 46. Messages 30, 30a-n with a message type 42 containing the service event 50 execute services 24 that have been configured and stored as part of the KSN / Service ID table 82 of the receiving device 12, 12a-n. Thus, the controller 20, 20a-n of the sending device 12, 12a-n can use the HPCA 200, 200a-n instead of the secure environment 100, 100a-n to create MACs 32, 32a-n for service events 50 to be transmitted. In other examples, the controller 20, 20a-n can bypass the MGAL 112 and the secure environment 100, 100a-n regardless of the use or configuration of the HPCA 200, 200a-n.

[0047] In one example, a first device 12a receives a message 30 from a second device 12b, which has a message type 42 indicating a service event 50. The first device 12a uses the KSN / Service ID table 82 to determine which KSN 34, 34a-n is associated with the service ID 44, 44a-n. The MACT 60 is then used to look up KSN 34, 34a-n, in order to execute the HPCA 200a to look up the service ID 44 and KSN 34b in the MACT 60 in order to determine the secret key 102b, which will be used to verify message 30b. The first controller 20a identifies key location 70 based on KSN 34b and obtains the secret key 102b, which is assigned to key location 70. Each device 12, 12a-n is only able to generate a MAC 32, 32a-n with the secret key 102, 102a-n, which is associated with the KSN 34, 34a-n of the respective device 12, 12a-n.In this way, it is prevented that a compromised device 12, 12a-n publishes unauthorized service events 50, since each device 12, 12a-n has linked the respective KSN 34, 34a-n of the device 12, 12a-n to an authorized service 24 (i.e. the service ID 44), which is further verified by the secret keys 102, 102a-n.

[0048] Fig. Figure 7 shows an example of three devices 12, 12a-c, where one of the devices 12, 12a-c is compromised. A first device 12a is the receiving device 12a, and a second device 12b and a third device 12c are connected to the first device 12a. The first device 12a stores the second KSN 34b and the second service ID 44b of the second device 12b, as well as the third KSN 34c and the third service ID 44c of the third device 12c, so that both the second and third devices 12b, 12c have previously passed through the service identification 46 with the first device 12a. The third device 12c is compromised and attempts to manipulate the second device 12b. The third device 12c sends a message 30c containing a second MAC 32b.Since message 30c is sent from the compromised third device 12c, message 30c contains a MAC 32c generated with the secret key 102c, which is associated with the third KSN 34c, even though the manipulated second service ID 44b is used. The compromised third device 12c attempts to manipulate message 30b from the second device 12b by inserting the second KSN 34b and the second service ID 44b, which are associated with the second device 12b, as part of the service event 50 of message 30c. However, the third device 12c must use the secret key 102c, which is associated with the third KSN 34c, because each device 12, 12a-n can only use the secret key 102, 102a-n, which is associated with the KSN 34, 34a-n that was originally configured for the respective device 12, 12a-n.

[0049] The first device, 12a, receives message 30b containing the second KSN 34b, the second service ID 44b, and a MAC 32c created with the secret key 102c, which is associated with the third KSN 34c. The first device, 12a, searches (i.e., via the HPCA 200a or the controller 20a) for service ID 44b in the KSN / service ID table 82 and finds the KSN 34b associated with service ID 44b. It then uses MACT 60 to determine which secret key 102, 102a-n, to use for verifying the MAC 32c of message 30b. The MACT 60 check fails because the secret key 102b of the second device, 12b, is associated with service ID 44b. Therefore, the compromised third device 12c is not permitted to send service events 50 for the offered service 24, as message 30b was classified as invalid.Even if the third device 12c were to transmit a message 30b containing the second KSN 34b, the MAC 32b would fail because the third device 12c does not have access to, or authorization to access, the secret keys 102b of the second device 12b. As mentioned earlier, the KSNs 34, 34a-n and the service IDs 44, 44a-n are used to identify the key location 70, which is subsequently used to provide the secret key 102, 102a-n. The device 12, 12a-n receiving the message is unable to use the secret keys 102, 102a-n of other devices 12, 12a-n to generate MACs 32, 32a-n. Rather, the secret keys 102, 102a-n can only be used to authenticate the message 30, 30a-n.

[0050] As in Fig. As shown in Figures 2-7, a single secret key 102, 102a-n is provided for each device 12, 12a-n, and the key derivation function 64 is used to generate the secondary key 106, 106a-n, which is used by the HPCA 200, 200a-n or the secure environment 100, 100a-n when an HPCA 200, 200a-n is not available when service events 50 are executed. Therefore, if a device 12, 12a-n receives a message 30, 30a-n of service identification 46, the controller 20, 20a-n knows that it must use the primary key 104, 104a-n, and the controller 20, 20a-n knows that it must use the secondary key 106, 106a-n when the device 12, 12an receives a message 30 of service event 50.

[0051] Fig. Figure 9 shows a flowchart of an exemplary sequence of operations for a procedure 900 for a secure messaging system 10. At 902, the controller 20, 20a-n of a first device 12, 12a-n generates a message 30, 30a-n with a header 40 containing a message type 42 and a service identifier (ID) 44, 44a-n. The message type 42 is either a service identification 46 or a service event 50. At 904, a second device 12, 12a-n receives the message 30, 30a-n, which contains the header 40 and a KSN 34, 34a-n of the first device 12, 12a-n. At 906, the controller 20, 20a-n determines the message type 42 of message 30, 30a-n based on header 40. At 908, an HPCA 200, 200a-n of the second device 12, 12a-n verifies the MAC 32, 32a-n of message 30, 30a-n based on the determined message type 42, which is service event 50.

[0052] KSN / Service ID table 82 is used to find KSN 34, 34a-n, which is associated with Service ID 44, 44a-n, stored when service 24 was discovered. A key location 70 is then obtained at 910 from a MACT 60 based on KSN 34, 34a-n from message 30, 30a-n. A secret key 102, 102a-n is identified at 912 based on key location 70 and used to verify message 30. The secret key 102, 102a-n is associated with key location 70 and includes a primary key 104, 104a-n and / or a secondary key 106, 106a-n. Finally, MAC 32, 32a-n is checked at 914 using the secret key 102, 102a-n and the key space 70 obtained from MACT 60.

[0053] The secure messaging system 10 (see Fig.1 - 9) has the advantage of securing the messages exchanged between the devices 12, 12a-n. For example, a vehicle 16 equipped with a large number of devices 12, 12a-n can be configured with the secure messaging system 10 to secure the messages 30, 30a-n exchanged between the devices 12, 12a-n. Each device 12, 12a-n is configured as part of the service-oriented architecture 14 to prevent devices 12, 12a-n from offering services 24, publishing service events 50, and sending RPCs 48 that are not among the authorized functions of the device 12, 12a-n. The service-oriented architecture 14 advantageously uses the KSN 34, 34a-n pre-programmed with each device 12, 12a-n in combination with the service ID 44, 44a-n, the MACT 60, the secret keys 102, 102a-n and the key space 70 to generate and verify MACs 32, 32a-n.The device 12, 12a-n requires the verified MAC 32, 32a-n before executing a service 24, so that the cross-reference of the KSN 34, 34a-n and the service IDs 44, 44a-n in the KSN / Service ID table 82 and the MACT 60 prevents the execution of unauthorized services 24.

[0054] Several implementations have been described. However, it goes without saying that various modifications can be made without deviating from the spirit and scope of the disclosure. Accordingly, other embodiments also fall within the scope of protection of the following claims.

[0055] The foregoing description serves for illustration and description purposes. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular configuration are generally not restricted to that particular configuration but are optionally interchangeable and may be used in a selected configuration even if they are not specifically shown or described. The same may also be varied in many ways. Such variations are not to be considered outside the scope of disclosure, and all such modifications are to be included within the scope of protection of the disclosure.

Images