Key provisioning methods and related products

Abstract

A key provisioning method and related products are provided. In the method, a first device receives an access request from a second device requesting access to the first device, determines whether the second device is authorized to access the first device, and based on the determination, transmits an access response to the second device, receives a first provisioning message from the second device, and generates a group key according to the provisioning data. According to the solution provided by the present disclosure, all ECU devices in a vehicle can be provisioned with a group key by one provisioning message including the provisioning data. In this way, the efficiency of key provisioning is improved and the provisioning cost is reduced. The generated group key is used to ensure the security of data communication associated with the ECU devices.

Description

[Technical field]

[0001] The present disclosure relates to the technical field of V2X technology, and in particular to a key provisioning method and related products. [Background technology]

[0002] Vehicle-to-Everything (V2X), which can refer to vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications, is a wireless technology aimed at enabling data exchange between vehicles and their surrounding environment.

[0003] Among the multiple applications related to V2X technology, increasing attention is being paid to vehicular security issues, and one of these issues can be key provisioning in vehicles. Key provisioning refers to the specific task of setting an initial secret key on a device in the vehicle. The key provisioning process is sometimes also called "key setting," "key distribution," "key initialization," or "key configuration," although the key implies some secret information used for data confidentiality and integrity or used to protect other secret keys. These terms are used interchangeably in this specification unless otherwise noted.

[0004] With the increase in cyber attacks, these key settings have become essential. In particular, every vehicle must have a unique key to minimize the impact on security. That is, even if an attacker obtains the key of a vehicle, it should not affect other vehicles. Additionally, current vehicles have many devices and applications for autonomous driving and connected car functions, and have isolated networks based on gateways to enhance security. Therefore, it is necessary to set many private keys for each device.

[0005] This background information is provided to identify information believed by applicant to be of possible relevance to the present disclosure. No admission is necessarily intended, nor should it be construed, that any of the preceding information constitutes prior art to the present disclosure. Summary of the Invention

[0006] In view of the above, the present invention provides a key provisioning method and related products to solve the above problems.

[0007] These and other objects are achieved by the subject matter of the independent claims. Further implementations are evident from the dependent claims, the description and the drawings.

[0008] A first aspect of the present disclosure relates to a key provisioning method implemented by a first device, the first device being onboard a vehicle, the method including: receiving an access request from a second device requesting access to the first device; determining, based on the access request, whether the second device is authorized to access the first device; and, based on the determination, sending an access response to the second device; receiving a first provisioning message from the second device, the first provisioning message including provisioning data for generating a group key, the group key being shared among the first devices in the vehicle; and generating the group key according to the provisioning data.

[0009] According to the solution provided by the present disclosure, all first devices in a vehicle, for example, all ECU devices, can be provisioned with a group key by one provisioning message including provisioning data. In this way, the efficiency of key provisioning is improved and the provisioning cost is reduced. The generated group key is used to ensure the security of data communication associated with the ECU device. Furthermore, by self-generating the key in the ECU device, a reduction in data size with limited information is achieved, and it is also possible to set keys for multiple devices simultaneously. The first device may be any device mounted on the vehicle, and the ECU device is only interpreted as an example for illustrative purposes. Also, the group key here is shared between first devices in the same vehicle, but first devices in different vehicles have different group keys.

[0010] In a possible implementation of the method according to the first aspect, determining whether the second device is authorized to access the first device based on the access request includes sending an authentication request to the second device to verify the authority of the second device, receiving an access token from the second device matching the authentication request, and determining whether the received access token is valid, and sending an access response to the second device based on the determination includes sending a positive access response to the second device if it is determined that the received access token is valid, and sending a negative access response to the second device if it is determined that the received access token is invalid.

[0011] Token-based authentication not only provides end-to-end security between vehicle devices and the KMS server, but also provides key independence for each vehicle and key authentication from the KMS signature.

[0012] In a possible embodiment of the method according to the first aspect, the method further includes, upon triggering of an access request, sending a first provisioning response to the second device, receiving a provisioning request from the second device for provisioning a functionality private key for the first device, generating a functionality private key based on the group key and the pre-stored data, and sending a second provisioning response to the second device.

[0013] A functional private key may be further generated based on the generated group key, and using this functional private key, self-generation of functional private keys by each ECU of any particular group (which may be differentiated by use or purpose, such as Secure On-Board Communication (SecOC), Transport Layer Secure (TLS), etc.) makes it possible to differentiate each ECU device from the functionality point of view, providing more flexibility in secure communication within the vehicle.

[0014] In a possible implementation form of the method according to the first aspect, the method further includes receiving a key confirmation challenge from a third device, where the key confirmation challenge is sent by the third device upon receiving a key confirmation request from the second device to confirm whether the functional private key has been correctly generated; generating a key confirmation response according to the key confirmation challenge, the functional private key, and a second predefined algorithm; and sending the key confirmation response to the third device.

[0015] When a function private key is generated by the ECU device, the generated function private key should be verified by the gateway to ensure that the function private key is correctly generated by the ECU device.

[0016] A second aspect of the present disclosure relates to a key provisioning method implemented by a second device, the method including: sending an access request to a first device to request access to the first device, the first device being onboard a vehicle; receiving an access response from the first device, the access response being returned by the first device based on the access request; and sending a first provisioning message to the first device, the first provisioning message including provisioning data for generating a group key by the first device, the group key being shared among the first devices in the vehicle.

[0017] In a possible implementation of the method according to the second aspect, the method further includes: before sending an access request to the first device to request access to the first device, sending a token request to the server to request an access token corresponding to the group key, the token request including one or more identities of a plurality of vehicles to which the second device plans to provision, the vehicle to which the first device belongs being included in the plurality of vehicles; and receiving from the server the access token corresponding to the group key and a second provisioning message corresponding to the access token.

[0018] In a possible implementation of the method according to the second aspect, the method further includes, before receiving an access response from the first device, receiving an authentication request from the first device to verify the authority of the second device, determining an access token matching the authentication request, and sending the access token matching the authentication request to the first device.

[0019] In a possible implementation of the method according to the second aspect, determining an access token matching the authentication request includes determining a provisioning state of the first device according to the authentication request, and, upon determining that the group key of the first device was not generated by the first device, using the access token corresponding to the group key as the access token matching the authentication request.

[0020] In a possible implementation of the method according to the second aspect, receiving an access response from the first device includes receiving a negative access response from the first device, and the method further includes sending a token update request to a server to update an access token of the first device before sending the first provisioning message to the first device, and receiving the updated access token from the server as an access token corresponding to the group key.

[0021] In a possible implementation of the method according to the second aspect, the method further includes receiving a first provisioning response from the first device, and when the first provisioning response indicates that the group key has been successfully generated by the first device, sending a provisioning request to provision a functional private key to the first device, and receiving a second provisioning response from the first device.

[0022] A possible implementation of the method according to the second aspect comprises: The method is: Sending a request to a server to request an access token for a replacement device of the first device, receiving from the server an access token corresponding to the group key, and provisioning the replacement device using the received access token. , further includingIn a possible implementation, the access token may include the identity of the exchange device, allowing the second device to access the exchange device using this access token, where provisioning of the exchange device may be performed in the same manner as provisioning of the first device.

[0023] In a possible embodiment of the method according to the second aspect, the method further comprises sending a request to a server to request a feature secret access token for updating a feature secret key of the first device, receiving the feature secret access token and corresponding update data from the server, and updating the feature secret key of the first device, where updating the feature secret key may be performed in the same manner as provisioning the feature secret key for the first device.

[0024] A third aspect of the present disclosure relates to a key provisioning method implemented by a server, the method including receiving a configuration request for configuring a first device from a fourth device, the configuration request including an identity of a vehicle to which the first device belongs, the first device being on-board the vehicle, and transmitting local provisioning data to the fourth device, the local provisioning data configured to generate a group key for the first device, the group key being shared among the first devices in the vehicle.

[0025] A fourth aspect of the present disclosure relates to a first device mounted in a vehicle, the first device including a receiving module, a determining module, a transmitting module, and a generating module, the receiving module being configured to receive an access request from a second device requesting access to the first device, the determining module being configured to determine whether the second device is authorized to access the first device based on the access request, the transmitting module being configured to transmit an access response to the second device based on the determination, the receiving module being further configured to receive a first provisioning message from the second device, the first provisioning message including provisioning data for generating a group key, the group key being shared among the first devices in the vehicle, and the generating module being configured to generate the group key according to the provisioning data.

[0026] A fifth aspect of the present disclosure relates to a second device including a transmitting module and a receiving module, the transmitting module configured to transmit an access request to the first device for requesting access to the first device, the first device being mounted in a vehicle, the receiving module configured to receive an access response from the first device, the access response being returned by the first device based on the access request, the transmitting module further configured to transmit a first provisioning message to the first device, the first provisioning message including provisioning data for generating a group key by the first device, the group key being shared among the first devices in the vehicle.

[0027] A sixth aspect of the present disclosure relates to a server including a receiving module and a transmitting module, the receiving module configured to receive a configuration request for configuring a first device from a fourth device, the configuration request including an identity of a vehicle to which the first device belongs, the first device being mounted on the vehicle, the transmitting module configured to transmit local provisioning data to the fourth device, the local provisioning data configured to generate a group key for the first device, the group key being shared among the first devices in the vehicle.

[0028] A seventh aspect of the present disclosure relates to a first device including a memory, a processor, an input interface and an output interface, the memory, the processor, the input interface and the output interface being connected by a bus system, the memory being configured to store instructions, and the processor being configured to execute the instructions stored in the memory to perform the method of the first aspect described above or any possible implementation of the first aspect.

[0029] An eighth aspect of the present disclosure relates to a second device including a memory, a processor, an input interface, and an output interface, the memory, the processor, the input interface, and the output interface being connected by a bus system, the memory being configured to store instructions, and the processor being configured to execute the instructions stored in the memory to perform the method of the second aspect described above or any possible implementation of the second aspect.

[0030] A ninth aspect of the present disclosure relates to a server including a memory, a processor, an input interface, and an output interface. The memory, the processor, the input interface and the output interface are connected by a bus system, the memory being configured to store instructions and the processor being configured to execute the instructions stored in the memory to perform the method of the third aspect described above or any possible implementation of the third aspect.

[0031] A tenth aspect of the present disclosure relates to a computer storage medium storing computer-executable instructions which, when executed, implement a method according to the first, second or third aspect of the present disclosure and any possible implementations thereof.

[0032] An eleventh aspect of the present disclosure relates to a computer program product comprising instructions which, when executed on a computer, cause the computer to perform a method according to the first, second or third aspect above or any possible implementation thereof. [Brief description of the drawings]

[0033] [Figure 1] 1 illustrates a key provided by one embodiment of the present disclosure. [Figure 2a] 1 illustrates a key provisioning system according to one embodiment of the present disclosure. [Figure 2b] 2b illustrates a general provisioning process for the key provisioning system shown in FIG. 2a, according to one embodiment of the present disclosure. [Figure 3a] 2 illustrates a schematic flowchart of a first device configuration in a key provisioning method according to an embodiment of the present disclosure; [Figure 3b] 2 illustrates a schematic flowchart of a first device configuration in a key provisioning method according to an embodiment of the present disclosure; [Figure 4a] 1 illustrates a schematic flowchart of a second device configuration in a key provisioning method according to an embodiment of the present disclosure. [Figure 4b]1 illustrates a schematic flowchart of a second device configuration in a key provisioning method according to an embodiment of the present disclosure. [Diagram 5] 2 shows a schematic flow chart of self-key generation in a key provisioning method according to one embodiment of the present disclosure; [Figure 6a] 2 shows a schematic flow chart of self-key generation in a key provisioning method according to one embodiment of the present disclosure; [Figure 6b] 2 shows a schematic flow chart of self-key generation in a key provisioning method according to one embodiment of the present disclosure; [Figure 6c] 2 shows a schematic flow chart of self-key generation in a key provisioning method according to one embodiment of the present disclosure; [Figure 7a] 1 illustrates a schematic flow chart of generating a functional private key according to an embodiment of the present disclosure. [Figure 7b] 1 illustrates an example of a functional private key, according to one embodiment of the present disclosure. [Figure 8] 1 illustrates an exemplary structure of a self-key generator in an ECU device. [Figure 9a] 1 illustrates a schematic flow chart of a token-based authentication in a key provisioning method according to an embodiment of the present disclosure. [Figure 9b] 1 illustrates a schematic flow chart of a token-based authentication in a key provisioning method according to an embodiment of the present disclosure. [Figure 10] 1 illustrates an exemplary structure of an access token according to one embodiment of the present invention. [Figure 11] 1 shows authentication logic for an ECU device or gateway. [Figure 12] 1 illustrates an exemplary process for authentication and authorization verification, according to one embodiment of the present disclosure. [Figure 13] 1 illustrates an exemplary use case for the Dealership Provisioning Tool. [Figure 14] 1 illustrates an exemplary use case for the Dealership Provisioning Tool. [Figure 15]FIG. 2 shows a schematic structural diagram of a first device according to an embodiment of the present disclosure. [Figure 16] FIG. 2 shows a schematic structural diagram of a second device according to an embodiment of the present disclosure. [Figure 17] FIG. 2 is a schematic structural diagram of a server according to an embodiment of the present disclosure; [Figure 18] FIG. 2 is a schematic block diagram of a first device according to one embodiment of the present disclosure. [Figure 19] FIG. 2 is a schematic block diagram of a second device according to an embodiment of the present disclosure. [Figure 20] FIG. 2 is a schematic block diagram of a server according to one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] In the following description, reference is made to the accompanying drawings, which form a part of this disclosure and which show by way of example certain aspects of the disclosed embodiments or in which the disclosed embodiments may be used. It is understood that the disclosed embodiments may be used in other ways and may include structural or logical changes that are not shown in the drawings. Therefore, the following detailed description should not be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0035] As explained in the Background section, key provisioning for Electronic Control Unit (ECU) devices in vehicles is very important. The private key provides basic system security while protecting against an attacker eavesdropping on the channel and manipulating any message. The security coverage of the private key includes (but is not limited to):

[0036] 1) Communication security inside and outside the vehicle: Message encryption and authentication using private keys to establish secure connections between ECU devices, specifically Secure On-Board Communications (SecOC) and Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS).

[0037] 2) System and software integrity checking: Remote attestation using private keys by verifying firmware or bootloader or bundle decryption updates and integrity checking for secure over-the-air updates and secure reprogramming.

[0038] It should be noted that the above application scenarios are merely intended to illustrate embodiments of the present disclosure and should not be construed as limitations thereof.

[0039] There are various existing solutions for the purpose of key provisioning. Specifically, existing solutions focus on provisioning a unique key to a "single device". In key provisioning methods, a symmetric key shared and used by both the sender and the receiver of the message is used to encrypt and decrypt the message. The key generation server selects a random device-unique key for the hardware device and encrypts the device-unique key with a common key embedded in each hardware device so that only the hardware device can decrypt the device-unique key. Since every device has a different key, the server should create different encrypted messages for many devices.

[0040] Another solution relies on the assumption of an on-chip key, which stores the provisioning key in a secure location in encrypted form by the chip manufacturer, and thus relies on other keys pre-stored in a previous manufacturing step. The provisioning key itself can be encrypted with the on-chip key and transmitted in encrypted form to the "device manufacturer". This provisioning key is thus determined by the "processor manufacturer".

[0041] While existing solutions focus on device manufacturers and provide a way to set their own provisioning keys, our new idea focuses on "vehicle manufacturers" and provides a way to set vehicle keys for many devices on a vehicle based on self-key generation. Therefore, existing solutions can be adopted at an early stage before our solution is implemented. Taking the existing method of supplier manufacturing, provisioning keys can be stored in each ECU device before manufacturing the vehicle.

[0042] However, existing solutions have their own limitations, such as:

[0043] 1) They are deployed to a single device.

[0044] Because time is one of the most important things in vehicle manufacturing system. If it is deployed in a vehicle with many devices, it will take a lot of time to set up each device. If we want to improve or extend the existing solutions applied on the vehicle side, new protocols and systems that can save time must be designed.

[0045] 2) They are based on key distribution as encrypted keys from a server to each device.

[0046] Since many messages in encrypted form are required for each terminal, communication traffic increases when distributing encrypted messages to each terminal, which results in additional delays. Furthermore, the management server and the intermediate tool must manage complex configuration data.

[0047] 3) They require a direct online connection to the server.

[0048] The manufacturing system shall carry out the production process exactly according to the scheduled time and process. Usually, the factory does not have this kind of secure key storage, and therefore needs to connect to an external secure key server. Relying on a real-time connection to obtain new keys for each device may not be suitable for the production schedule, because it is difficult to expect the manufacturing system to always reliably connect to the online server during production.

[0049] For the purpose of such a problem, the goal is to reliably set an initial unique group key for devices in a vehicle (i.e., all ECU devices in the vehicle), so that equipment belonging to other vehicles cannot know these keys. This technique requires a lot of time to set keys for each device in each vehicle, and a complex key management protocol with different device states such as embedded default keys and desired keys. Furthermore, a cumbersome management system is required to collect and manage device information from lot suppliers. It should be noted that the devices in a vehicle may be devices other than ECU devices, which is not limited in this disclosure.

[0050] The present disclosure provides a key provisioning method and related products. First, the present disclosure provides a method for securely provisioning a key to an ECU device of a vehicle, and an authentication method for verifying a provisioning tool, a system, and a received message, thereby achieving secure key setting (authenticated key provisioning). Second, the present disclosure uses self-generation of keys with one message for all devices of a vehicle. Even when deployed in many devices and many vehicles, it helps to reduce traffic overhead and network transmission and operation delays, thereby achieving high-speed operation with minimum latency. Third, the solution provided herein is scalable to deploy many keys on a vehicle standard protocol. In fact, the present disclosure applies "token-based authentication" to the provisioning tool, allowing access to ECU devices without requiring an online connection to a server and without relying on an online connection. Furthermore, it provides scalability with only one message for each vehicle setting on a standard automotive protocol. This reflects the real vehicle production and dealership and mechanic environment, which requires easy management for various types of systems and stakeholders.

[0051] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0052] Before describing the detailed implementation of the present disclosure, we first briefly describe some keys that may be used herein.

[0053] The method described herein may start under the assumption that all devices securely hold a Provisioning Key (PVK) as a pre-shared secret, also called the Group Key, and these two terms are used interchangeably unless otherwise stated. With the proposed method, each ECU device obtains two secret keys: 1) the Group Key, also called the Vehicle Specific Private Key (VSK), and 2) the Functional Private Key (FSK).

[0054] The PVK may be pre-shared with all ECUs throughout the supplier production, e.g., it may be injected by a provisioning tool on the supplier side. The PVK may also be obtained generally from the vehicle manufacturer (OEM), and policies regarding PVK distribution may be specifically determined and managed by the OEM. A possible implementation assumes that the PVK is differentiated according to vehicle type or model.

[0055] The VSK is self-generated by each ECU in the vehicle, for example using the PVK and some random string received from the KMS (Key Management System). The VSK is different for each vehicle (unique to the VIN).

[0056] The FSK is self-generated by each ECU of some particular group, for example using the VSK and a predefined specific string and value, which group can be differentiated by its use or purpose, such as Secure On-Board Communication (SecOC) and Transport Layer Security (TLS).

[0057] The OEM's public key (for the Key Management System (KMS)) is used to validate the received provisioning data.

[0058] As shown in Figure 1, for devices in vehicle 1, all devices share VSK1, and the devices are divided into two groups, each group owns an FSK, i.e., FSK1 and FSK2, and for devices in vehicle 2, all devices share VSK2, and FSK is not provisioned for these devices. Since the VSKs are different for different vehicles, VSK1 is not equal to VSK2.

[0059] FIG. 2a illustrates a key provisioning system according to one embodiment of the present disclosure, and FIG. 2b illustrates a general provisioning process for the key provisioning system shown in FIG. 2a according to one embodiment of the present disclosure.

[0060] As shown in Figure 2a, the key provisioning system can consist of three main parties, including the OEM KMS, the supplier factory provisioning system, and the vehicle-side provisioning tool. First, the KMS is responsible for generating the provisioning message. The provisioning tool is responsible for transmitting this message to the device. The provisioning tool does not have any information about the keys, so the tool does not have secure access to the device. An “access token” allows the provisioning tool to gain access to the vehicle’s devices. It is also provided by the KMS and can be used only once for key setting. Every device can check the current provisioning state using a “counter” value, which is incremented every time the key provisioning state is changed. The counter and the access token will be explained in the later part.

[0061] The KMS is not only responsible for configuring the provisioning tool, but also for configuring the ECU device. On the supplier side, the ECU device is configured in the supplier factory provisioning system during ECU production (supplier production stage). The provisioning tool is a typical device or program for device diagnostics, which may be a hardware device or a software program, such as a specialized vehicle test device on the OEM side, a dealership diagnostic tool / scanner, or an application running on a portable device (cell phone and pad). The provisioning tool generally does not know anything about these aforementioned keys. This term is introduced here only for ease of explanation and does not have any specific restriction on the provisioning tool.

[0062] Figure 2b shows the system components and relationships. In the figure, it is assumed that secure channels between the supplier and the KMS server, and between the provisioning tool and the KMS server are established, for example, using existing technologies. The establishment of these secure channels is not the focus of this disclosure. It is assumed that there must be at least a secure channel such as TLS, the supplier management system (ECU supplier factory provisioning system), etc. Thus, they may share some information in the first and second steps. Security considerations regarding this will be discussed in a later section. Also, the dotted boxes in Figure 2b refer to information obtained from other parties, while the solid boxes in Figure 2b refer to pre-stored local information.

[0063] There are four main components. The whole security depends on the KMS, which manages the provisioning data, the validation keys, and the access tokens. The supplier system (ECU supplier factory provisioning system shown in Figure 2a and Figure 2b) also has a secure tool to inject specific information (keys, timestamp, vehicle, device, etc.) into their product. The ECU device product should have some protected memory to securely hold the provisioning keys and self-generated functions. For example, the device should have a secure storage based on a Hierarchical Storage Management (HSM) or a Trusted Execution Environment (TEE). The tester tool (also called the provisioning tool / system, these two terms are used interchangeably unless otherwise stated) only has the access tokens and the provisioning messages received from the KMS. Its main role is to deliver the provisioning messages to the ECU.

[0064] The provisioning process is divided into three steps: 1) ECU configuration, 2) Provisioning tool configuration, and 3) Self-key generation. The first step is implemented between KMS and supplier factory provisioning system, which is for device configuration in supplier production, where some engineer or system injects secret information inside ECU. In the second step, which is implemented between KMS and provisioning tool, KMS provides the provisioning tool with provisioning data for vehicle key configuration. The main role of the provisioning tool is just to send this data to ECU device. As the last step, which is implemented between supplier factory provisioning system and provisioning tool, self-key generation is performed on each device with the received provisioning data to obtain VSK and FSK.

[0065] The entire provisioning process for a vehicle ECU device may be as follows:

[0066] 1) The supplier production tool imports local provisioning data into its product, for example, the local provisioning data may include a provisioning key, an OEM public key, a timestamp, and other information about the car. Please note that the above data listed here is for illustrative purposes only, and the detailed implementation will be described in the following embodiments. 2) The provisioning tool gains access to all ECUs in the vehicle using the access token received from the KMS and sends provisioning messages to them. 3) Every ECU in the vehicle self-generates a vehicle-specific private key using the provisioning message transmitted by the provisioning tool and signed and public-key authenticated. 4) All ECUs in the vehicle self-generate other function private keys based on the self-generated and verified vehicle-specific private key. 5) The vehicle gateway ensures that all ECUs complete the key provisioning process and notifies the server of the result via the provisioning tool. 6) All ECUs except the Gateway (GW) delete the provisioning key and their own key generation functions. The key provisioning method provided by the present disclosure will be described in conjunction with the detailed information shown in FIG. 2b.

[0067] 3a and 3b show a schematic flow chart of a first device configuration in a key provisioning method according to an embodiment of the present disclosure. 3a and 3b show a specific process in the first step mentioned above, ECU configuration in supplier production. The method may be performed by a server on the OEM side and a supplier device on the supplier side (also called a fourth device in the following description, and these two terms are used interchangeably unless otherwise specified). The flow chart relates to the first step shown in 2a and 2b and functions to configure an ECU device, and the first device may be the ECU device shown in 2b.

[0068] This process is assumed to be performed in the Supplier Manufacturing System. Additionally, as previously mentioned, it is assumed that the server (OEM KMS) and the Supplier Device (provided in the Supplier Manufacturing System) mutually authenticate, validate each other, and establish a secure channel for secure communication.

[0069] The method may include:

[0070] S301: A supplier device sends a configuration request for configuring a first device to a server, and the server receives the configuration request from the supplier device.

[0071] Via the established secure channel, the supplier device sends a configuration request to the KMS server, where the configuration request may include the identity of the vehicle to which the first device belongs, i.e. the vehicle in which the first device (the ECU device shown in Figure 2a) is installed.

[0072] For example, the supplier device may include supplemental information in the configuration request, i.e., information about the product such as vehicle type, product type, supplier identification information, etc., to obtain local provisioning data for the ECU device.

[0073] In a real application, the KMS server may define its own policies for distributing provisioning data, but the policies may vary according to the OEM's choices.

[0074] S302: The server transmits local provisioning data to the supplier device, and the supplier device receives the local provisioning data.

[0075] Exemplarily, referring to FIG. 2b, upon obtaining the vehicle identity, the KMS server may respond to the supplier device with appropriate provisioning data, i.e., local provisioning data, that matches the ECU device, and this local provisioning data may include 1) a provisioning key (provisioning key shown in FIG. 2b), 2) a public key (OEM public key shown in FIG. 2b, also called signature verification key in the ECU), and 3) a local timestamp, where the provisioning key is configured to generate a group key for the ECU device at a later stage, the public key is configured to verify the authority of the second device provided with a provisioning tool to send a provisioning message to the ECU device, and is in fact used for verification to ensure that the received message was generated by the KMS, and the local timestamp is configured to verify the validity of the generated provisioning key, and is in fact used for freshness so as not to allow obsolete or replayed messages, and as a possible implementation, the local timestamp may be the current time.

[0076] S303: The supplier device injects local provisioning data into the first device.

[0077] The injection may be done in the supplier's own secure manner, such as with a secure debug tool. The first device stores the data in a protected memory, such as a secure storage provided by an HSM or a TEE.

[0078] Correspondingly, on the first device side, the first device may obtain local provisioning data.

[0079] Exemplarily, as shown in FIG. 2b, the supplier device and the server may communicate over a secure channel established based on a certain protocol, such as TLS HyperText Transfer Protocol Secure (HTTPS), and the supplier device implemented with an ECU supplier factory provisioning system may receive a provisioning key and an OEM public key, and then inject the provisioning key, the public key and a current timestamp into the ECU, thereby completing the configuration of the ECU device.

[0080] 4a and 4b show a schematic flow chart of the second device configuration in the key provisioning method according to an embodiment of the present disclosure. 4b and 4c show a specific process of the aforementioned second step, provisioning tool configuration, to prepare the provisioning tool provided in the second device to access the ECU device. 4b specifies detailed parameters compared to 4a. As mentioned above, the main role of the provisioning tool is to access the ECU device and pass the provisioning data received from the KMS server to the ECU device. The flow shown in 4 is performed on the OEM side, in particular between the server on the OEM side and the second device on which the provisioning tool may be provided on the OEM side. This flow chart relates to the second step shown in 2a and 2b, and the first device in the following description may be the ECU device shown in 2b. Furthermore, the provisioning tool may be provided to the second device as a software function or hardware, and the provisioning tool may be implemented as the second device, and thus configuration of the provisioning tool is equivalent to configuration of the second device, and throughout the description operations performed by the second device may also be considered to be operations performed by the provisioning tool.

[0081] S401: A second device sends a token request to a server to request an access token corresponding to a group key, and the server receives the token request.

[0082] S402: The server sends, to the second device, an access token corresponding to the token request and a second provisioning message corresponding to the access token.

[0083] Before accessing the first device, the second device first obtains an access token corresponding to the group key (VSK), and the access token is used by the second device to access the first device so that the first device can generate the group key.

[0084] The token request may include the identities of one or more vehicles that the second device plans to provision, including the vehicle to which the first device belongs. In a possible implementation, the token request may simply include the identity of one of the vehicles to which the first device belongs. In another implementation, the token request may include the identities of several vehicles that the second device plans to provision, including the vehicle to which the first device belongs. The identities of several vehicles may optionally be in the form of a list.

[0085] When the token request only includes the identity of one vehicle to which the first device belongs, the server returns a second provisioning message including an access token corresponding to the identity of the vehicle to which the first device belongs, and the provisioning data for the vehicle. Furthermore, it is also possible that the second device aims to provision several vehicles, thus the second device may include a list of vehicle identities in the token request, and the server may in turn send to the second device a second provisioning message including an access token corresponding to the token request, and the provisioning data for the vehicles. Using this access token, the second vehicle may be able to access the vehicles in the list.

[0086] Exemplarily, as shown in Fig. 2b, even if both the provisioning tool and the KMS server belong to the OEM, they may be geographically separated, which means that the provisioning tool (possibly a portable device or program) is separated from the KMS server by a physical distance, such as a "factory system / tool" and a "cloud-based KMS server". Therefore, the KMS server and the second device need a secure channel to share some information. As shown in Fig. 2b, the secure channel may be established using TLS and HTTPS. The proposed method also considers aftermarket dealership tester tools that are not under the control of the OEM (this use case will be explained in a later part).

[0087] The provisioning tool sends a token request for provisioning data and an access token along with the provisioned vehicle identity to the KMS server over the established secure and authenticated channel to let the server know and decide which data to transfer. The provisioning tool knows which vehicles are to be provisioned, such as from the manufacturing control system, production schedule, or direct access to the vehicles. It transfers a list of vehicles and the ECU devices they want to access for provisioning. After verifying that the requester (second device) has authorization for the target vehicle identity (VIN), the server generates and sends an Entitlement Provisioning message to the second device. The server transmission contains two types of data:

[0088] 1) Access Token: This is used to access the ECU device (first device). The tool will have only one access token that identifies the vehicle it can access. In a possible implementation, the access token may also identify the device it can access. Access tokens with different structures may achieve different functions, which will be explained in later sections. 2) Provisioning Data: It is what the second device (or provisioning tool) should transfer to the first device for provisioning, just one message per vehicle is assigned. It consists of the following data: a random string encrypted by a provisioning key (pointing to the provisioning key PVK in the ECU) and a provisioning timestamp (pointing to the current timestamp from the OEM server to the ECU device) encrypted by the provisioning key, the random string and the provisioning timestamp may be used by the ECU device to generate the provisioning key, and the verification signature may be used to verify the validity of the provisioning key generated by the ECU device.

[0089] A possible implementation is the random string RS i and Provisioning Timestamp TS i is the cipher text C i may be included in the

[0090] As mentioned above, if the token request includes multiple vehicle identities, the server may respond with several second provisioning messages including provisioning data for different vehicles, and thus the provisioning data returned in step S402 may be represented by an index i, where i denotes the identifier (target vehicle identity) of the target vehicle i. For example, the provisioning data returned by the server may be a random string RS encrypted by a provisioning key. i and the provisioning timestamp TS encrypted by the provisioning key. i and the verification signature σ i The server may also include a VIN in the provisioning data. -i (the identity of the target vehicle) to inform the second device which provisioning data corresponds to which vehicle. In this case, the validation signature σi is VSK i , R.S. i and T.S. i The signature for the data is VSK. i is the desired key that the ECU device obtains by self-key generation for the dedicated vehicle i. Alternatively, the server and the second device can also negotiate the correspondence between the token request and the second provisioning message before the configuration of the provisioning tool. For example, when the token request includes some identities, the server can add the VIN to the provisioning data included in the second provisioning message. -i The second provisioning messages may be returned in a predefined order so that the second device knows which second provisioning message corresponds to which vehicle, without including the verification signature σ. i is VSK i , VIN -i , R.S. i , T.S. i This means signing the data.

[0091] In the above method, a provisioning tool in the second device may be configured and prepared to perform provisioning on the target vehicle.

[0092] FIG. 5 shows a schematic flow chart of self-key generation in a key provisioning method according to an embodiment of the present disclosure. FIG. 5 shows a specific process of the third step mentioned above, key generation based on provisioning data. The flow shown in FIG. 5 is performed between a first device (ECU device) and a second device (provided with a provisioning tool), in particular between an ECU device installed in a vehicle and a second device where a provisioning tool may be provided at an OEM side. This flow chart relates to the third step shown in FIG. 2a and FIG. 2b, and the first device in the following description may be the ECU device shown in FIG. 2b. Before the process shown in FIG. 5, the first device has been configured in the manner shown in FIG. 3a, and the second device has also been configured in the manner shown in FIG. 4a.

[0093] S501: A second device transmits an access request to a first device to request access to the first device, and the first device receives the access request from the second device.

[0094] In a possible implementation, the access request may simply be a request to write data to the first device. The access request is used to trigger authentication of the second device by the first device.

[0095] S502: The first device determines whether the second device is authorized to access the first device.

[0096] When the first device receives the access request, the first device may determine whether the second device is permitted to access the first device for security purposes. In other words, the determination of the access authority is triggered by the access request.

[0097] S503: The first device sends an access response to the second device based on the determination, and the second device receives the access response from the first device.

[0098] In a possible implementation, when the first device finds that the second device is authorized to access the first device, it may respond with a positive response, otherwise it may respond with a negative response. Thus, the access response is returned by the first device based on the access request.

[0099] S504: The second device sends a first provisioning message to the first device, and the first device receives the first provisioning message from the second device.

[0100] Upon receiving the access response from the first device, the second device may send a first provisioning message to the first device.

[0101] As explained above, the access response returned by the first device may be a positive or negative response, and in a possible implementation, when the response is positive, the second device may send the first provisioning message directly to the first device, and when the response is negative, the second device may interact with a server (e.g., the KMS server shown in Fig. 2b) to update its permissions to access the first device. For example, the second device may update its token and, with the updated token, the second device may access the first device.

[0102] S505: The first device generates a group key according to the provisioning data.

[0103] The first provisioning message includes provisioning data for generating a group key, and when the first device receives the first provisioning message from the second device, it may generate a group key (e.g., a VSK shown in FIG. 2a) according to the provisioning data included in the first provisioning message.

[0104] It should be noted that although only the operation of one first device is shown here, in a real application, all ECU devices in a vehicle may perform the same operation to generate a group key.

[0105] Also, as will be described in detail in the following sections, in a real application, the ECU device may be connected to a gateway in the vehicle, in which case data or information transmitted to the first device from an external source may first encounter the gateway; therefore, since the first vehicle is an ECU device, the reception of the access request in step S501 and the reception of the first provisioning message in step S504 should be interpreted as indirect reception, i.e., receiving such type of data by forwarding from the gateway.

[0106] According to the present disclosure, a second device can access a first device in a vehicle and set a group key for all first devices in the vehicle with one provisioning message, thereby reducing traffic overhead and network transmission and operation delays even when it is deployed for many devices and many vehicles.

[0107] Hereinafter, a detailed implementation of the self-key generation of the ECU device may be described with reference to the accompanying drawings.

[0108] In a real application, an ECU device may be connected to a Gateway (GW), which represents the devices connected to the on-board ECU device and has an interface for communicating with external devices, such as diagnostics. Thus, a second device may encounter the Gateway first when accessing the ECU device.

[0109] Therefore, the third step shown in Figures 2a and 2b may be implemented in two ways depending on where the ECU device is. Figures 6a and 6b show how the third step is done in the GW, and Figure 6c shows the flow for a normal ECU device. When a provisioning tool wants to access the vehicle, it first encounters the GW and needs to go through it to gain access to the ECU devices in the vehicle. Therefore, the GW should be the first provisioning target in vehicle production.

[0110] Figures 6a-6c show a schematic flow chart of self-key generation in a key provisioning method according to one embodiment of the present disclosure. Compared with Figures 5a and 5b, more specific details are added in Figures 6a-6c. It should be noted that prior to the process shown in Figures 6a-6c, the ECU device has been configured in the manner shown in Figure 3a, and the second device has also been configured in the manner shown in Figure 4a.

[0111] The method may include:

[0112] S601: A provisioning tool transmits an access request to a gateway to request access to the gateway, and the gateway receives the access request from the provisioning tool.

[0113] When an access request is triggered, the access request may simply be a request to write data to the first device.

[0114] S602: The gateway determines whether the provisioning tool is permitted to access the gateway.

[0115] Upon receiving the access request, the gateway may determine whether the provisioning tool is authorized to access the first device for security reasons. The determination may be a token-based authentication between the gateway and the provisioning tool. The specific permissions are described below with reference to Figures 8a and 8b.

[0116] S603: The gateway sends an access response to the provisioning tool based on the determination, and the provisioning tool receives the access response from the gateway.

[0117] The access response may be a positive access response or a negative access response.

[0118] If the gateway determines that the received access token is valid, it sends a positive access response to the provisioning tool, and if the gateway determines that the received access token is invalid, it sends a negative access response to the provisioning tool, which may be the case when the access token sent by the provisioning tool has expired.

[0119] On the provisioning tool side, positive Receiving a positive access response may indicate that the provisioning tool has the correct access token to provision the gateway, whereas receiving a negative access response may indicate that the provisioning tool does not have the correct access token to provision the gateway, so when the provisioning tool receives a negative access response from the gateway, it may send a token refresh request to the server to refresh the access token for the gateway and receive the refreshed access token from the server as the access token that corresponds to the group key. In either case, the provisioning tool will eventually be able to access the gateway.

[0120] On the server side, when a token refresh request for refreshing the access token for the gateway is received from the second device, the server sends the refreshed access token to the provisioning tool according to the token refresh request.

[0121] S604: The provisioning tool sends a first provisioning message to the gateway, and the gateway receives the first provisioning message from the provisioning tool.

[0122] Upon receiving the access response from the first device, the provisioning tool may send a first provisioning message to the first device.

[0123] The first provisioning message may include provisioning data for generating a group key by the gateway.

[0124] S605: The gateway generates a group key according to the provisioning data.

[0125] The provisioning data may include a random string encrypted with a provisioning key, a provisioning timestamp encrypted with a provisioning key, and a verification signature.

[0126] The group key may be generated as follows: the gateway uses the provisioning key to decrypt the provisioning data to obtain the random string and the provisioning timestamp, and then generates a group key based on the random string and the provisioning timestamp, and after generating the group key, the gateway verifies the validity of the generated provisioning key according to the verification signature in the provisioning data.

[0127] As described above, besides the group key (VSK), the ECU device may also optionally possess the FSK. The following steps are optional and may be performed according to actual needs.

[0128] S606: The gateway sends a first provisioning response to the provisioning tool, and the provisioning tool receives the first provisioning response.

[0129] After generating the group key, the gateway sends a response to the provisioning tool so that the provisioning tool will know whether the group key was generated successfully or not.

[0130] S607: When the first provisioning response indicates that the group key has been successfully generated by the first device, the provisioning tool sends a provisioning request to provision a functional private key to the gateway, and the gateway receives the provisioning request from the second device.

[0131] S608: The gateway generates a functional private key based on the group key and the pre-stored data.

[0132] The generation of the FSK may be based on the generated group key and some pre-stored data.

[0133] The gateway (if the FKS is generated by the gateway) or the ECU device (if the FKS is generated by the ECU device itself) can use the VSK and a predefined string to obtain the ECU-specific function key and some group-specific function keys. {ECU part number, unique ID, serial number, and additional string (such as "e2e")} can be an example of a predefined string for the ECU-specific key (as an end-to-end secret key between the KMS server and the ECU device).

[0134] A possible implementation of FSK generation is shown in Fig. 7a. Examples of FSKs are shown in Fig. 7b. As shown in Fig. 7a, the predefined string may be some data pre-written in the ECU device, and the generation of the FSK may also be based on the vehicle identity (VIN). The output of the Key Derivation Function (KDF) may be verified using a signature in the ECU device.

[0135] An example of a VSK may be KDF(PVK, VIN||predefined string||RS||TS) using a pseudorandom function (PRF) such as HMAC-SHA256. Also, an example of a functional key may be KDF(VSK, VIN||predefined string).

[0136] In addition, in examples of KDFs such as PBKDF2 (RFC 8018, PKCS#5: Password-Based Cryptography Specification Version 2.1) and scrypt (RFC 7914, The scrypt Password-Based Key Derivation Function), the parameters shown in Figure 7b, such as Pw (password, passphrase), salt, and iteration / cost factor, may be applied.

[0137] S609: The gateway sends a second provisioning response to the second device, and the provisioning tool receives the second provisioning response from the first device.

[0138] The second provisioning response serves to inform the provisioning tool whether the FSK was successfully generated by the gateway.

[0139] S610: The gateway routes the generated key to the ECU device.

[0140] After generating the VSK and FSK, the gateway may route the generated keys to the ECU device.

[0141] In a possible implementation, after generating the VSK and FSK, the gateway may then erase any secret information related to key provisioning, such as the public key and the string for generating the key.

[0142] To better understand the above process, please refer to Fig. 6b. It starts with a VSK provisioning request (access request in step S601) from the provisioning tool to the device. For example, this provisioning request can be a kind of "write data" request on a diagnostic message (UDS, Unified Diagnostic Service). Then, after the token-based authentication is performed, the provisioning tool sends the provisioning data received from the KMS (similar to step S604). When the GW receives this data, it 1) decrypts the ciphertext to get the random string and timestamp from the message, 2) generates a VSK with the decrypted data, and 3) verifies whether the generated data is correct. If these processes are successful, the provisioning tool requests the ECU device to generate FSK provisioning and other functional secret keys. When the device finishes all key generation, it deletes the provisioning data and secret information related to this self-generation. The GW is in charge of routing these received data to the corresponding ECU device in the vehicle.

[0143] Figure 6c shows another possible case where provisioning is done at the ECU device, in which case the gateway typically routes everything received from the provisioning tool to the ECU device. The token-based authentication, group key generation, and FSK are the same as in Figures 6a and 6b, but this is not described in detail for simplicity.

[0144] Additionally, regarding the generation of the VSK, see FIG. 2b, in each ECU, the key generation is performed using a "self-key generator" (which may be implemented as a software function in the ECU device) consisting of a KDF (Key Derivation Function), a secret key, a predefined string and parameters. There are many KDFs, such as HKDF, PBKDF2, Scrypt, etc. Any one of them can be selected. Apart from this, the KDF takes an additional input string received from an external source and generates a result that is unique for the vehicle. Some of the exemplary strings are shown in FIG. 8.

[0145] In addition, the process of the typical ECU device is similar to that in the GW, except for one more step called "key confirmation", in which the GW verifies that the ECU device generates the FSK correctly, as a kind of typical challenge-response authentication. For example, the ECU device may receive a key confirmation challenge from the gateway, where upon receiving a key confirmation request from the provisioning tool to verify whether the function private key is correctly generated, the key confirmation challenge is sent by the gateway, and then the ECU device generates a key confirmation response according to the key confirmation challenge, the function private key, and a second predefined algorithm, and sends the key confirmation response to the gateway.

[0146] In combination with FIG. 6c, the above key confirmation process may be challenge-response as follows:

[0147] 1) The GW sends a “random number” as a challenge to the corresponding ECU. 2) The ECU uses the generated key (the generated FSK) and the MAC VSK A response is made using a cryptographic function such as a form of (FSK|Random) and sent back to the GW, where MAC refers to a message authentication code algorithm, which may be changed to other suitable algorithms according to actual needs and is not limited in this specification. 3) GW will compare it to its own generation and judge it as a failure or success.

[0148] In a possible implementation, the GW does not need to fully validate the access token every time the provisioner tries to access the vehicle. It can reduce the delay by keeping and using a recent authentication log using a cookie or a cache or similar method. For example, the GW can simply check the authorization value in the access token without wasting time validating the signature (by comparing it with a previously validated signature). More details about the authentication process may be explained in a later part.

[0149] As shown in Figure 6c, ECU1 and ECU2 are first provisioned sequentially; in another possible case, the provisioning tool can access multiple devices at the same time if the network and GW can afford to do it. One of the most time consuming processes is the signature verification. Transmission, decryption, and key generation are somewhat fast. During the device verification process, the provisioning tool can access other devices to reduce the overall time. Accessing other devices on different isolated networks helps optimize the entire process by reducing the chance of interruptions.

[0150] 9a and 9b show a schematic flow chart of the token-based authentication in the key provisioning method according to one embodiment of the present disclosure. These figures actually specify the above-mentioned step S602. As mentioned above, the provisioning may be performed directly in the ECU device (FIG. 6c) or in the gateway (FIG. 6b), so that, depending on the specific situation, the token-based authentication may be performed between the ECU device and the second device with the provisioning tool, or between the gateway and the second device. Hereinafter, the description will be given by taking an example where the authorization is performed between the gateway and the provisioning tool. In the case where the authorization is between the ECU device and the second device with the provisioning tool, the operation of the ECU device may refer to the operation of the gateway.

[0151] Figure 9a shows an example flow chart of token-based authentication. The whole authentication process is based on the automotive standard protocol of Unified Diagnostic Services (UDS) authentication, which is known as UDS security access, seed key authentication, or challenge response authentication. Unlike the traditional method of using a random challenge, the ECU device uses a fixed challenge number with a "counter", as shown in Figure 9b. This counter represents some specific status of the provisioning, for example, counter number "1" means that the device now has a PVK and can proceed to the next step of generating a VSK. Every time the device completes provisioning, it increases the counter number by one. Note that this counter can never be decremented and cannot be returned to a smaller number. Upon receiving the counter as a challenge from the ECU device or gateway, the provisioning tool should respond with an access token that matches this counter challenge number. Because the counter is incremented after the provisioning is successfully completed, the provisioning tool cannot reuse the token. Therefore, if someone attempts a relay attack with a previously used token, it must be rejected because it does not match the already incremented counter number.

[0152] The process is further explained in conjunction with FIG. 9b.

[0153] S901: The gateway sends an authentication request to a provisioning tool to verify the authority of the provisioning tool, and the provisioning tool receives the authentication request from the gateway.

[0154] Token-based authentication may also be a challenge-response authentication. Unlike the conventional method that uses a random challenge, the ECU device uses a fixed challenge number using a “counter” as shown in Figure 9b.

[0155] In a possible implementation, the authentication request may include a local counter (such as the counter shown in Figure 2b), which may be configured to reflect the provisioning state of the gateway, and the value of the counter is changed based on rules preset by the gateway when the provisioning state of the gateway changes.

[0156] Here, a specific meaning may be defined for the value of the local counter to block malicious access. For example, as shown in the table of FIG. 9a, a local counter of 0 may represent an unprovisioned state, a local counter of 1 may represent a PVK provisioned state, a local counter of 2 may represent a VSK provisioned state, a local counter of 3 may represent a FSK provisioned state, and a local counter greater than 3 may represent a state in which some keys have been updated. The following description is based on such an assumption, but it should be understood that the specific value of the local counter is for illustration purposes only and should not be construed as a limitation on the present disclosure. Other values ​​are possible as long as they indicate different provisioning states of the ECU device.

[0157] S902: The provisioning tool determines an access token that matches the authentication request.

[0158] The provisioning tool determines the provisioning state of the gateway according to the authentication request, and if it determines that the group key (VSK) of the gateway is not generated by the gateway, the provisioning tool uses the access token corresponding to the group key as the access token that matches the authentication request. Here, the access token may be received from the server by the provisioning tool according to the flow shown in Figure 4a. If the provisioning tool does not have the correct access token, it may request the server to refresh its access token. The refresh process will be described in detail later.

[0159] S903: The provisioning tool sends an access token that matches the authentication request to the gateway, and the gateway receives the access token that matches the authentication request.

[0160] S904: The gateway determines whether the received access token is valid.

[0161] The determination of the validity of the access token may be based on the particular structure of the access token.

[0162] An exemplary structure of an access token is shown in Figure 10. As shown in Figure 10, the access token may include a credential to be verified, generated based on a first predefined algorithm, a counter to be verified, a timestamp to be verified, a vehicle identity to be verified, and a signature to be verified.

[0163] According to this configuration, upon receiving the access token, the gateway may determine whether the received access token is valid; specifically, the gateway may compare each field in the access token with its local data shown in the ECU device of FIG. 2b; and the gateway may determine that the received access token is invalid if a condition is met, which may include any one or more of the following:

[0164] 1) A local credential generated based on a local counter (the counter shown in the ECU device in FIG. 2b) and a first predefined algorithm is inconsistent with the credential to be verified.

[0165] The credentials in the received access token are generated by the server according to a predefined algorithm, and the gateway MAY generate credentials according to the same algorithm to complete the validation.

[0166] In a possible implementation, the credential may be generated on both sides (gateway and server) as follows: Credential=MAC Key (additional string | counter | padding), where Credential is a tag generated using a MAC (Message Authentication Code) algorithm based on a counter and a pre-shared secret, the pre-shared secret may be the PVK or one of the functional keys, e.g., the Authentication Key (AUK), the key is equal to the PVK if Counter=1 or 2, and is the AUK if Counter>2, the additional string in the above algorithm is optional and may be, e.g., an OEM ID, vehicle type, or some pre-defined random string, the padding depends on the algorithm for generating the credential, such as padding 32 and 64 byte lengths to length or zeros.

[0167] 2) The local counter (the counter shown in the ECU device in Figure 2b) is inconsistent with the counter being verified.

[0168] The gateway compares its local counter with the counter to be verified in the received access token, and if the two values ​​do not match, it determines that the access token is invalid.

[0169] Furthermore, as explained above with reference to Figure 9a, in the normal case (for a provisioning tool), i.e. when the PVK is configured and ready for the generation of a VSK, the counter should be equal to 1.

[0170] 3) The local timestamp is later than the timestamp being verified.

[0171] The gateway may compare its local timestamp (the timestamp shown in the ECU device in Figure 2b) with the timestamp to be validated in the received access token and determine that the access token is invalid if these two values ​​do not match.

[0172] Indeed, the verification target timestamp represents the value when the access token was generated, while the local timestamp represents the value injected at manufacturing (factory), i.e. the ECU production time. Therefore, since the token generation time should be more current than the ECU production time, the local timestamp can be used to protect against the case of a "replay attack" where a provisioning tool tries to reuse an old (expired / revoked) token.

[0173] 4) The identity of the vehicle to which the first device belongs is inconsistent with the identity of the vehicle to be verified.

[0174] As mentioned above, during the configuration phase of the provisioning tool, the server may return an access token to the provisioning tool for accessing a certain vehicle, and thus the access token may contain the identity of the vehicle to which the first device belongs and there may be at least one vehicle identity to be verified in at least one access token, which is the case when the token request sent by the provisioning tool to the server (step S402 in Figure 4a) contains a list of vehicle identities and consequently the access token may contain multiple identities of vehicles that the provisioning tool is authorized to access.

[0175] In other words, the timestamp depends on the time the token was generated by the KMS server and is used to check the expiry time (token freshness) of the received access token.

[0176] 5) Failure to check the signature to be verified using the public key.

[0177] The signature to be verified is generated over the preceding data listed above {credentials, counter, accessible target, timestamp} using a KMS private key (paired with a public key held by the target device) and some signature algorithm such as RSASSA-PSS, ECDSA, EdDSA, etc.

[0178] In a possible implementation, the access token may contain fields used to further identify the vehicles and ECUs that can be accessed, such as a list of vehicle groups / types, device types and device identities.

[0179] If the gateway determines that the received access token is valid, it sends a positive access response to the provisioning tool, and if the gateway determines that the received access token is invalid, it sends a negative access response to the provisioning tool.

[0180] Figure 11 shows the authentication logic for the ECU device. The authentication logic in the gateway is similar to that in the ECU device and is omitted for brevity. When the device receives the access token, it first verifies that the credentials and counter are valid, and then sequentially checks that the accessible targets, timestamp, and signature are valid. Each time the verification fails, the number of attempts increases, and if the number exceeds three (which may be definable according to the actual needs), the access may be limited for a certain time (10 seconds). Even though we specify these thresholds for the number of attempts and the delay timer, they may be adjustable according to the car manufacturer's policy. If the entire key provisioning process is completed successfully, the device erases the KDF and the key metadata.

[0181] The above process is a token-based authentication for generating a group key, i.e., VSK.

[0182] As explained in step 902, typically the ECU device is not yet provisioned, so the local counter at the ECU device is equal to 1, which means that the PVK, i.e. the provisioning key shown in Fig. 2b, is already configured for the ECU device, in other words, the configuration of the ECU device has been done, for example based on the flow shown in Fig. 3a, and at this point the ECU device is ready to generate a group key (VSK). Thus, the provisioning tool determines that the gateway is ready for provisioning, and therefore can determine the access token received from the KMS server to generate a VSK as the access token that matches the authentication request.

[0183] In another case, when the challenge is equal to 2, the provisioning tool determines based on the authentication request that the gateway is provisioned with the VSK, in this case, if the gateway still wants to perform provisioning on the gateway, it must access the gateway with the access token corresponding to the FSK, and in combination with the structure of the access token shown in Figure 10, to ensure a validity check at the gateway or ECU device during token-based authentication, the verification target counter in the access token should be equal to 2.

[0184] In another case, when the challenge is equal to 3, the provisioning tool determines based on the authentication request that the gateway is provisioned with the VSK, in this case, if the gateway still wants to perform provisioning on the gateway, it must access the gateway with the access token corresponding to the key update, and in combination with the structure of the access token shown in Figure 10, the verification target counter should be equal to 3 to ensure a validity check at the gateway or ECU device during token-based authentication.

[0185] In Fig. 9b we simply describe the case where the gateway has not been provisioned with a VSK, and therefore the provisioning tool responds to the challenge with an access token corresponding to the group key. In a possible implementation, even when the provisioning tool accesses the gateway or ECU device with an access token that matches the authentication request, it may still be rejected by the gateway or ECU device, which actually considers the security of the provisioning tool. For example, some attacks may reuse previously used, expired, or unauthorized tokens.

[0186] In any case, if the provisioning tool does not have the correct access token that matches the authentication request, it may need to refresh its access token. A possible process for authentication and authorization validation by the provisioning tool is shown in Figure 12, where the provisioning tool may validate the access token and refresh the access token when it receives a negative response from the gateway.

[0187] Specifically, as shown in FIG. 12, when a provisioning tool receives an access token, it may send a UDS authentication request to the gateway, receive a challenge that includes a counter, and then the provisioning tool may determine which access token matches the counter.

[0188] If there is no access token that matches the counter, the provisioning tool may send a token refresh request to the KMS server to request a refreshed access token, the KMS server may determine whether the provisioning tool is authorized to provision the gateway according to its policies, and if so, the KMS server may send a refreshed token to the provisioning tool.

[0189] If there is an access token that matches the counter, the provisioning tool may send the determined access token to the gateway, if the access token fails the validity check at the gateway, i.e., the access token is rejected by the gateway, the provisioning tool upon receiving a negative response from the gateway may check if one of the access target check, timestamp check, or signature check failed. Failure of the access target check may lead to checking the access request of the access token with the target vehicle, failure of the timestamp check may lead to sending a token refresh request as described above, and failure of the signature may lead to sending a verification key ID request, and the gateway may send the verification key ID to the provisioning tool for checking, which is then used in the token refresh request to the KMS server.

[0190] There may be concerns about potential leakage of the provisioning key from the supplier. If an attacker were to obtain the VSK, they should collect at least three pieces of information that are managed in different parts or stages:

[0191] 1) Provisioning Key: Distributed to supplier manufacturing / provisioning tools at supplier production time.

[0192] 2) A predefined string (which may be, for example, the salt shown in Figure 7b, which is used in the key derivation of other subsequent private keys): distributed to the supplier security administrator before supplier production.

[0193] 3) Encrypted RS and TS: Distributed to OEM manufacturing / provisioning tools during vehicle production.

[0194] Therefore, if the VSK is exposed to an attacker, it means that information has been leaked from all of the supplier manufacturing systems, supplier security administrators, and OEM manufacturing systems, or the protected memory of the ECU device (e.g., HSM) has been compromised.

[0195] The security of this disclosure is ensured by the following reasons: Under the assumption of security management of each component and secure channel between the system and the provisioning tool, the dealership provisioning tool can only access certain devices of a specific vehicle that is shipped or sold with the permission of the OEM (not used during the vehicle manufacturing stage). The use case of such an aftermarket provisioning tool is described in the next section.

[0196] The technical solutions of the present disclosure may provide several technical advantages.

[0197] First, it is easy to manage and scale: for example, provisioning tools do not need to obtain access authorization for each ECU, they only get one access token from the server that identifies the targets they can access, and furthermore, the provisioning tool and the KMS server simply manage one message for all ECUs on the vehicle (i.e., one provisioning message from the provisioning tool to the ECU device, and a second provisioning message from the KMS server to the provisioning tool, both provisioning messages containing the provisioning data). Moreover, the technical solution is deployable over standard automotive protocols (such as UDS).

[0198] Secondly, based on the proposed solution, it becomes efficient for mass production with low traffic and high speed operation. The supplier only needs to keep the ECU type secret (no need to manage every ECU differently) and the OEM manufacturer simply keeps one provisioning message for the vehicle type. By self-generating the keys in the ECU device or gateway, a reduction in data size with limited information is achieved and it is also possible to set keys for multiple devices at the same time.

[0199] Third, the proposed solution is also concerned with security issues: indeed, no secrets are shared with other external systems and tools, and therefore the proposed solution provides end-to-end security between the vehicle devices and the KMS server, as well as key independence for each vehicle and key authentication from the KMS signature. Moreover, it is robust against cryptanalytic attacks, since the use and exposure of the PVK is very limited.

[0200] Apart from the aforementioned solutions, the present disclosure also provides a solution for a dealership provisioning tool. As shown in Figure 13 and Figure 14, they show some use cases of the dealership provisioning tool (an aftermarket tool, the provisioning tool here may be implemented as software or hardware). The first case shown in Figure 13 is for part replacement (e.g. ECU replacement), and the second case shown in Figure 14 is for FCK update. Most of the process is the same as described above.

[0201] In Fig. 13, for these testers to access the new replacement device, they must obtain an access token for the desired device from the OEM. The provisioning tool sends a request for access token and provisioning data to the server according to the VIN (vehicle identity) and ECU identity of the new ECU replacement (replacement device of the first device), and upon receiving the specified access token and provisioning data to access the target vehicle (identified by VIN) and target ECU device (identified by ECU identity), the provisioning tool may provision the ECU replacement with the received access token and provisioning data, and the specific operation may be the same as the provisioning of the first device shown in Fig. 5. The replacement of the ECU device may also be applied to the scenario where the ECU device is damaged or old, and the tester may use the proposed method to provision a new ECU device and replace the damaged or old ECU device with a new one.

[0202] Similarly, if the tester wants to update some specific keys, it should obtain a special access token for update authorization with the permission of the OEM. This is because the device presents a larger counter number (e.g., larger than 2). Specifically, the second device may send a request to the server requesting a feature secret access token for updating the feature secret key of the first device, and upon receiving the request, the server may return the feature secret access token and corresponding update data to the second device, and upon receiving the feature secret access token and corresponding update data from the server, the second device may provision the first device similar to the feature secret key provisioning of FIG. 9. For example, as shown in FIG. 14, which shows the process of updating the keys of the ECU device in the vehicle, for a specific key update, the provisioning tool performs a challenge-response authorization with the ECU device, requests the server for an access token corresponding to the counter number in the challenge, and allows the provisioning tool to update the keys in the ECU device with the access token and update data returned from the server. For details on token update, please refer to FIG. 12 and related discussion.

[0203] 15 shows a schematic structural diagram of a first device according to an embodiment of the present disclosure. The first device may be mounted on a vehicle. The first device 1500 includes a receiving module 1501, a determining module 1502, a transmitting module 1503, and a generating module 1504.

[0204] The receiving module 1501 is configured to receive an access request from the second device requesting access to the first device, the determining module 1502 is configured to determine whether the second device is authorized to access the first device based on the access request, the transmitting module 1503 is configured to transmit an access response to the second device based on the determination, the receiving module 1501 is further configured to receive a first provisioning message from the second device, the first provisioning message including provisioning data for generating a group key, the group key being shared among the first devices in the vehicle, and the generating module 1504 is configured to generate the group key according to the provisioning data.

[0205] In a possible implementation, the determination module 1502 is specifically configured to: when an access request is triggered, send an authentication request to the second device to verify the authority of the second device; receive an access token from the second device that matches the authentication request; and determine whether the received access token is valid.

[0206] The transmitting module 1503 is configured to, when determining that the received access token is valid, transmit a positive access response to the second device, and, when determining that the received access token is invalid, transmit a negative access response to the second device.

[0207] In a possible implementation, the first device further includes an acquiring module configured to acquire local provisioning data from the server, the local provisioning data including a provisioning key, a public key, and a local timestamp, the provisioning key configured to generate a group key, the public key configured to verify the authority of the second device, and the local timestamp configured to verify validity of the generated provisioning key.

[0208] In a possible implementation, the provisioning data includes a random string encrypted by a provisioning key, a provisioning timestamp encrypted by a provisioning key, and a verification signature.

[0209] The generating module 1504 is configured to decrypt the provisioning data using the provisioning key to obtain a random string and a provisioning timestamp, generate a group key according to the random string and the provisioning timestamp, and verify the validity of the generated provisioning key according to the verification signature.

[0210] In a possible implementation, the access token includes a credential to be verified generated based on a first predefined algorithm, a counter to be verified, a timestamp to be verified, at least one vehicle identity to be verified, and a signature to be verified.

[0211] Specifically, the determination module 1502 The method is configured to determine that the received access token is invalid if a condition is met, the condition including any one or more of: a local credential generated based on a local counter and a first predefined algorithm and a first predetermined algorithm being inconsistent with a credential to be verified; a local counter being inconsistent with a counter to be verified; a local timestamp being later than a timestamp to be verified; an identity of a vehicle to which the first device belongs being inconsistent with at least one vehicle identity to be verified; and a failure to check a signature to be verified with a public key.

[0212] In a possible implementation, the access token includes any one or more of a list of a vehicle type, a device type, and a device identifier.

[0213] In a possible implementation, the authentication request includes a local counter, the local counter configured to reflect a provisioning state of the first device, and a value of the counter is changed based on a rule preset by the first device when the provisioning state of the first device changes.

[0214] In a possible implementation, the sending module 1503 is further configured to send the first provisioning response to the second device.

[0215] In a possible implementation, the receiving module 1501 is further configured to receive a provisioning request from the second device to provision a function private key for the first device, the generating module 1504 is further configured to generate the function private key based on the group key and the pre-stored data, and the transmitting module 1503 is further configured to transmit a second provisioning response to the second device.

[0216] In a possible implementation, the receiving module 1501 is further configured to receive a key confirmation challenge from the third device, and upon receiving a key confirmation request from the second device to confirm whether the functional private key has been correctly generated, the key confirmation challenge is sent by the third device, the generating module 1504 is further configured to generate a key confirmation response according to the key confirmation challenge, the functional private key, and a second predefined algorithm, and the transmitting module 1503 is further configured to transmit the key confirmation response to the third device.

[0217] According to the solution provided by the present disclosure, all ECU devices in a vehicle can be provisioned with a group key by one provisioning message containing provisioning data. In this way, the efficiency of key provisioning is improved and the provisioning cost is reduced. The generated group key is used to ensure the security of data communication associated with the ECU devices. Furthermore, by self-generating the keys in the ECU devices, a reduction in data size with limited information is achieved, and it is also possible to set keys for multiple devices simultaneously.

[0218] The first device may be applied to implement the technical solutions in any one of the above-mentioned method embodiments. The implementation principles and their technical effects are similar and will not be described in this specification.

[0219] 16 shows a schematic structural diagram of a second device according to an embodiment of the present disclosure. The second device 1600 includes a transmitting module 1601 and a receiving module 1602.

[0220] The transmitting module 1601 is configured to transmit an access request to the first device to request access to the first device, the first device being mounted in a vehicle; the receiving module 1602 is configured to receive an access response from the first device, the access response being returned by the first device based on the access request; the transmitting module 1601 is further configured to transmit a first provisioning message to the first device, the first provisioning message including provisioning data for generating a group key by the first device, and the group key being shared among the first devices in the vehicle.

[0221] In a possible implementation, the sending module 1601 is further configured to send a token request to the server to request an access token corresponding to the group key, the token request including one or more identities of a plurality of vehicles to which the second device plans to be provisioned, the vehicle to which the first device belongs being included in the plurality of vehicles, and the receiving module 1602 is further configured to receive from the server the access token corresponding to the group key and a second provisioning message corresponding to the access token.

[0222] In a possible implementation, the receiving module 1602 is further configured to receive an authentication request from the first device to verify the authority of the second device.

[0223] The second device further includes a determination module, the determination module further configured to determine an access token matching the authentication request, and the transmission module 1601 further configured to transmit the access token matching the authentication request to the first device.

[0224] In a possible implementation, the determination module is further configured to determine a provisioning state of the first device according to the authentication request, and, upon determining that the group key of the first device is not generated by the first device, use an access token corresponding to the group key as an access token matching the authentication request.

[0225] In a possible implementation, the receiving module 1602 is configured to receive a negative access response from the first device, the access response being returned by the first device based on the access request, and the sending module 1601 is further configured to send a token update request to the server to update the access token for the first device, and to receive the updated access token from the server as an access token corresponding to the group key.

[0226] In a possible implementation, the receiving module 1602 is further configured to receive a first provisioning response from the first device.

[0227] The sending module 1601 is further configured to send a provisioning request for provisioning a functional private key to the first device when the first provisioning response indicates that the group key has been successfully generated by the first device.

[0228] The receiving module 1602 is further configured to receive a second provisioning response from the first device.

[0229] In a possible implementation, the sending module 1601 is further configured to send a request to a server to request an access token for a replacement device of the first device, and the receiving module 1602 is further configured to receive from the server an access token corresponding to the group key and provision the replacement device using the received access token.

[0230] According to the present disclosure, a second device can access a first device in a vehicle and set a group key for all first devices in the vehicle with one provisioning message, thereby reducing traffic overhead and network transmission and operation delays even when it is deployed for many devices and many vehicles.

[0231] The second device may be applied to implement the technical solutions in any one of the above-mentioned method embodiments. The implementation principles and their technical effects are similar and will not be described in this specification.

[0232] 17 is a schematic structural diagram of a server according to an embodiment of the present disclosure. The server 1700 includes a receiving module 1701 and a sending module 1702.

[0233] The receiving module 1701 is configured to receive a configuration request for configuring a first device from a fourth device, the configuration request including an identity of a vehicle to which the first device belongs, the first device being mounted in the vehicle, the transmitting module 1702 is configured to transmit local provisioning data to the fourth device, the local provisioning data being configured to generate a group key for the first device, the group key being shared among the first devices in the vehicle.

[0234] In a possible implementation, the receiving module 1701 is further configured to receive a token request from the second device, the token request including identities of one or more vehicles that the second device plans to provision, the vehicle to which the first device belongs being included in the plurality of vehicles, and the sending module 1702 is further configured to send an access token corresponding to the token request and a second provisioning message corresponding to the access token to the second device.

[0235] In a possible implementation, the receiving module 1701 is further configured to receive a token refresh request from the second device to refresh the access token for the first device, and to send the refreshed access token to the second device in accordance with the token refresh request.

[0236] The server may be adapted to implement the technical solutions in any one of the above-mentioned method embodiments. The implementation principles and their technical effects are similar and will not be described in this specification.

[0237] FIG. 18 is a schematic block diagram of a first device according to one embodiment of the present disclosure.

[0238] As shown in FIG. 18, an embodiment of the present disclosure further provides a first device 1800. The device 1800 may be the device 1500 of FIG. 15, which may be configured to implement the content related to the first device corresponding to the method in the method embodiment. The device 1800 includes an input interface 1810, an output interface 1820, a processor 1830, and a memory 1840. The input interface 1810, the output interface 1820, the processor 1830, and the memory 1840 may be connected by a bus system. The memory 1840 is configured to store a program, instruction, or code. The processor 1830 is configured to execute the program, instruction, or code in the memory 1840 to control the input interface 1810 to receive a signal and control the output interface 1820 to transmit a signal, and complete the operations in the aforementioned method embodiment.

[0239] In a specific implementation, the transmitting module 1503 in the device 1500 shown in FIG. 15 may be implemented using the output interface 1820 in FIG. 18, and the receiving module 1501 may be implemented using the input interface 1810 in FIG. 18, and the determining module 1502 and the generating module 1504 in the device 1500 shown in FIG. 15 may be implemented using the processor 1830 in FIG. 18.

[0240] FIG. 19 is a schematic block diagram of a second device according to one embodiment of the present disclosure.

[0241] As shown in FIG. 19, an embodiment of the present disclosure further provides a first user device 1900. The device 1900 may be the device 1600 of FIG. 16, which may be configured to implement content related to the first device corresponding to the method in the method embodiment. The device 1900 includes an input interface 1910, an output interface 1920, a processor 1930, and a memory 1940. The input interface 1910, the output interface 1920, the processor 1930, and the memory 1940 may be connected by a bus system. The memory 1940 is configured to store a program, instruction, or code. The processor 1930 is configured to execute the program, instruction, or code in the memory 1940 to control the input interface 1910 to receive a signal and control the output interface 1920 to transmit a signal, and complete the operations in the aforementioned method embodiment.

[0242] In a particular implementation, the transmitting module 1601 in the device 1600 shown in FIG. 16 may be implemented using the output interface 1920 of FIG. 19, and the receiving module 1602 may be implemented using the input interface 1910 of FIG. 19.

[0243] FIG. 20 is a schematic block diagram of a server according to one embodiment of the present disclosure.

[0244] As shown in FIG. 20, an embodiment of the present disclosure further provides a first user device 2000. The device 2000 may be the device 1700 of FIG. 17, which may be configured to implement a content related to the first device corresponding to the method in the embodiment of the method. The device 2000 includes an input interface 2010, an output interface 2020, a processor 2030, and a memory 2040. The input interface 810, the output interface 2020, the processor 2030, and the memory 2040 may be connected by a bus system. The memory 2040 is configured to store a program, instruction, or code. The processor 2030 is configured to execute the program, instruction, or code in the memory 2040 to control the input interface 2010 to receive a signal, and control the output interface 2020 to transmit a signal, and complete the operations in the embodiment of the method described above.

[0245] In a particular implementation, the transmitting module 1702 in the device 1700 shown in FIG. 17 may be implemented using the output interface 2020 in FIG. 20, and the receiving module 1701 may be implemented using the input interface 2010 in FIG. 20.

[0246] The present disclosure also provides a computer storage medium storing computer-executable instructions that, when executed, implement methods according to embodiments of the present disclosure.

[0247] The present disclosure also relates to a computer program product comprising instructions which, when executed on a computer, cause the computer to perform the method in the above-described embodiments.

[0248] For example, it will be understood that disclosure related to a described method may also be true of a corresponding device or system configured to perform that method, and vice versa. For example, if one or more particular method steps are described, a corresponding device may include one or more units, e.g., functional units, to perform the described method step or steps (e.g., one unit performs one or more steps, or multiple units each perform one or more of the multiple steps), even if such one or more units are not explicitly described or shown in a figure. On the other hand, for example, if a particular apparatus is described in terms of one or more units, e.g., functional units, a corresponding method may include a step to perform the functionality of the one or more units (e.g., one step performing the functionality of the one or more units, or multiple steps, each of the multiple units performing the functionality of one or more of the multiple units), even if such one or more steps are not explicitly described or shown in a figure. Furthermore, it is understood that the features of the various exemplary embodiments and / or aspects described herein may be combined with each other, unless otherwise stated.

[0249] The terms "first", "second", etc. in the specification and claims of this disclosure as well as in the above drawings are intended to distinguish different objects but are not intended to define a particular order.

[0250] Terms such as "and / or" in the embodiments of the present disclosure are only used to describe the association between associated objects, which indicates that there may be three relationships, for example, A and / or B may indicate the presence of only A, the presence of both A and B, and the presence of only B.

[0251] In embodiments of the present disclosure, phrases such as "exemplary," "for example," and the like are used to indicate an example or specific example. In embodiments of the present disclosure, any embodiment or design scheme described as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or design schemes. In particular, the use of "exemplary" or "for example" is intended to present the relevant concept in a particular manner.

[0252] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium, which corresponds to a tangible medium, such as a data storage medium, or a communication medium, which includes any medium that facilitates transfer of a computer program from one place to another, for example according to a communication protocol. In this manner, a computer-readable medium may generally correspond to (1) a tangible computer-readable storage medium that is non-transitory, or (2) a communication medium, such as a signal or carrier wave. A data storage medium may be any available medium accessible by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable storage medium.

[0253] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included within the definition of media. However, computer-readable storage media and data storage media should be understood not to include connections, carrier waves, signals, or other transitory media, but instead to non-transitory, tangible storage media. Disks, as used herein, include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically and disks reproduce data optically with a laser. Combinations of the above should also be included within the scope of computer readable media.

[0254] The instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Thus, the term "processor" as used herein may refer to any of the foregoing structures, or other structures suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein may be provided in dedicated hardware and / or software modules configured for encoding and decoding, or may be incorporated into a combined codec. Also, the techniques may be implemented entirely in one or more circuit or logic elements.

[0255] The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs) or sets of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to highlight functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, the various units may be combined in a codec hardware unit or may be provided by a collection of interoperable hardware units including one or more processors as described above, along with appropriate software and / or firmware.

[0256] A computer-readable non-transitory medium includes all types of computer-readable media, including magnetic storage media, optical storage media, and solid-state storage media, specifically excluding signals. It should be understood that the software may be installed and sold on a router, client, or other network device. Alternatively, the software may be obtained and loaded onto the device, including obtaining the software via disk media, or from any manner of network or distribution system, including, for example, from a server owned by the software creator, or from a server not owned but used by the software creator. The software may be stored on a server for distribution, for example, via the Internet.

[0257] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items defined in the claims. The mere fact that certain measures are defined in mutually different dependent claims does not indicate, exclude or suggest that a combination of these measures cannot be used to advantage. A computer program may be stored or distributed on a suitable medium, such as an optical storage medium, a solid-state medium, supplied together with or as part of other hardware, but also in other forms, such as over the Internet or other wired or wireless telecommunication systems.

[0258] The foregoing detailed description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the subject matter claimed herein to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The described embodiments have been chosen to best explain the principles of the disclosed technology and its practical application so that those skilled in the art can best utilize the technology in various embodiments and with various modifications suitable for the particular use contemplated. It is intended that the scope of the disclosure be defined by the claims appended hereto.

Claims

1. 1. A key provisioning method implemented by a first device, the first device being installed in a vehicle, the method comprising: receiving an access request from a second device requesting access to the first device; determining whether the second device is authorized to access the first device based on the access request; transmitting an access response to the second device based on the determination; and receiving a first provisioning message from the second device, the first provisioning message including provisioning data for generating a group key, the group key being shared among first devices in the vehicle; generating a group key in accordance with the provisioning data; before receiving the access request from the second device; the method further comprising: obtaining local provisioning data from a server, the local provisioning data including a provisioning key, a public key, and a local timestamp, the provisioning key configured to generate the group key, the public key configured to verify authority of the second device, and the local timestamp configured to verify validity of the generated provisioning key.

2. Determining whether the second device is authorized to access the first device based on the access request includes: When the access request is triggered, sending an authentication request to the second device to verify the authority of the second device; receiving an access token from the second device that matches the authentication request; determining whether the received access token is valid; transmitting the access response to the second device based on the determining, upon determining that the received access token is valid, sending a positive access response to the second device; The method of claim 1 , further comprising: upon determining that the received access token is invalid, sending a negative access response to the second device.

3. the provisioning data includes a random string encrypted by the provisioning key, a provisioning timestamp encrypted by the provisioning key, and a verification signature; generating the group key in accordance with the provisioning data, decrypting the provisioning data using the provisioning key to obtain the random string and the provisioning timestamp; generating the group key according to the random string and the provisioning timestamp; and verifying the validity of the generated provisioning key according to the verification signature.

4. the access token includes a credential to be verified generated based on a first predefined algorithm, a counter to be verified, a timestamp to be verified, at least one vehicle identity to be verified, and a signature to be verified; Determining whether the received access token is valid comprises:

4. The method of claim 3, further comprising: determining that the received access token is invalid if conditions are met, the conditions including any one or more of: a local credential generated based on a local counter and the first predefined algorithm and a first predetermined algorithm being inconsistent with the credential to be verified; the local counter being inconsistent with the counter to be verified; the local timestamp being later than the timestamp to be verified; an identity of a vehicle to which a first device belongs being inconsistent with the at least one vehicle identity to be verified; and failing to check the signature to be verified with the public key.

5. The method of claim 4 , wherein the access token includes any one or more of a list of vehicle types, device types, and device identifiers.

6. 6. The method of claim 4 or 5, wherein the authentication request includes the local counter, the local counter being configured to reflect a provisioning state of the first device, and a value of the counter is changed based on a rule preset by the first device when the provisioning state of the first device changes.

7. A first device configured to carry out the method according to any one of claims 1 to 6.

8. A vehicle including a first device according to claim 7.

Images