Key distribution method and vehicle

Abstract

The application relates to a key distribution method and a vehicle, and relates to the technical field of information security. The method comprises the following steps: obtaining a to-be-distributed key and a security attribute control policy; the following steps are executed by a hardware security module of a vehicle-end security gateway: extracting multi-dimensional constraint parameters from the security attribute control policy, and obtaining an attribute declaration of a target electronic control unit; comparing the multi-dimensional constraint parameters with multi-dimensional attribute parameters in the attribute declaration one by one; and judging whether the to-be-distributed key is distributed to the target electronic control unit according to the comparison result. The method can break the limitation that the lower limit of vehicle safety protection is restricted by a low-protection-grade auxiliary ECU, block the path of unauthorized acquisition of high-security-grade keys by low-specification ECUs from the distribution source, reduce the risk of illegal key injection, key theft and leakage, and comprehensively fill the safety short board of unified control of vehicle-mounted keys, so that the key distribution safety protection capability of a differentiated security-specification ECU cluster under a vehicle domain control architecture is improved.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a key distribution method and vehicle. Background Technology

[0002] As automotive electronic and electrical architecture evolves towards domain control, vehicles are equipped with a large number of ECUs (Electronic Control Units) with varying safety specifications. Core ECUs for powertrain, chassis, and autonomous driving integrate HSMs (Hardware Security Modules), possessing independent hardware encryption / decryption and secure storage capabilities, while auxiliary ECUs within the vehicle body have lower levels of protection. Currently, services such as vehicle key matching, program updates, and remote diagnostics all require key distribution and injection operations to various ECUs.

[0003] Existing in-vehicle key distribution and authentication systems mostly adopt a fixed processing scheme that uses a unified broadcast and relies solely on the device ID for matching, with authentication verification relying on a single device identifier. This single, fixed key distribution and authentication mode limits the overall vehicle security protection capabilities to low-specification ECUs, making it highly susceptible to security issues such as unauthorized key access, illegal injection, and key theft and leakage. The in-vehicle key security management system has significant shortcomings in protection. Summary of the Invention

[0004] This application provides a key distribution method, apparatus, vehicle, and storage medium that overcomes the limitation of vehicle security protection being constrained by low-protection-level auxiliary ECUs. By establishing a layered authentication threshold through refined verification of multi-dimensional operating conditions and hardware security specification parameters, it blocks low-specification ECUs from unauthorizedly obtaining high-security-level keys at the distribution source, reducing risks such as illegal key injection, key theft, and leakage. This comprehensively addresses the security shortcomings of unified vehicle key management and enhances the key distribution security protection capabilities of ECU clusters with differentiated security specifications under the vehicle domain control architecture. The specific technical solution is as follows: In a first aspect of this application, a key distribution method is provided, the method comprising: Obtain the keys to be distributed and the security attribute management policy; The following steps are performed through the hardware security module of the vehicle-side security gateway: extracting multi-dimensional constraint parameters from the security attribute control strategy and obtaining the attribute declaration of the target electronic control unit, wherein the attribute declaration contains multi-dimensional attribute parameters characterizing the actual operating conditions of the target electronic control unit; comparing the multi-dimensional constraint parameters with the multi-dimensional attribute parameters one by one; Based on the comparison results, determine whether to distribute the key to be distributed to the target electronic control unit.

[0005] In an optional implementation, before performing the step of obtaining the key to be distributed and the security attribute control policy, the method further includes: Obtain the attribute declaration of the target electronic control unit, and digitally sign the attribute declaration through the hardware security module of the vehicle-side security gateway; Encapsulate the attribute declaration carrying the digital signature into a key request, and send the key request to the cloud attribute authentication server so that the cloud attribute authentication server performs the following steps: The key request request contains the attribute declaration of the digital signature, and the digital signature is verified. Once the digital signature verification is successful, the corresponding original working key is obtained from the key management server based on the attribute declaration, and a security attribute control policy is generated. The original working key and the security attribute control policy are encrypted to obtain an encrypted attribute policy package; The encryption attribute policy package is sent to the vehicle-side security gateway. The acquisition of the key to be distributed and the security attribute control strategy include: The encrypted attribute policy package is received, and the encrypted attribute policy package is decrypted through the hardware security module of the vehicle-side security gateway to obtain the original working key and the security attribute control policy. The original working key is determined as the key to be distributed.

[0006] In an optional implementation, the step of determining whether to distribute the key to be distributed to the target electronic control unit based on the comparison result includes: When the multidimensional constraint parameters and the multidimensional attribute parameters are matched one by one, a temporary session random number is generated by the hardware security module of the vehicle-side security gateway, and the session random number and the key to be distributed are encrypted using the trusted identity identifier of the target electronic control unit to obtain a ciphertext packet. The encrypted packet is distributed to the target electronic control unit, causing the target electronic control unit to perform the following steps: The encrypted packet is decrypted using the hardware security module of the target electronic control unit and its trusted identity identifier to obtain the session random number and the key to be distributed. Compare the session random number with the locally stored historical session random number. If the session random number is inconsistent with the historical session random number, inject the key to be distributed into the local key slot in ciphertext form. If the session random number matches the historical session random number, the key to be distributed is discarded and a security alarm is generated.

[0007] In an optional implementation, before the hardware security module of the vehicle-side security gateway generates a temporary session random number, the method further includes: The security level of the target electronic control unit is determined, and if the security level reaches a preset high security level threshold, the step of generating a temporary session random number through the hardware security module of the vehicle-side security gateway is executed.

[0008] In an optional implementation, the method further includes: If the security level does not reach the preset high security level threshold, the key to be distributed is distributed to the target electronic control unit so that the target electronic control unit injects the key to be distributed into its local key slot.

[0009] In an optional implementation, the attribute declaration carries a timestamp; before obtaining the corresponding original working key from the key management server based on the attribute declaration and generating the security attribute control policy, the method further includes: Verify whether the timestamp is within the valid validity period; If the timestamp is within the valid time limit, the steps of obtaining the corresponding original working key from the key management server according to the attribute declaration and generating the security attribute control policy are executed. If the timestamp is not within the valid time limit, the steps of obtaining the corresponding original working key from the key management server based on the attribute declaration and generating the security attribute control policy shall be refused.

[0010] In an optional implementation, obtaining the attribute declaration of the target electronic control unit includes: Determine the security level of the target electronic control unit and obtain the attribute declaration of the target electronic control unit that is compatible with the security level.

[0011] In an optional implementation, the step of obtaining the corresponding original working key from the key management server based on the attribute declaration, and generating a security attribute control policy, includes: If the key management server stores an original working key that matches the attribute declaration and is in a normal state, then obtain the original working key; If there is no matching original working key in the key management server or the matching original working key has expired, the attribute declaration is used as the derivation seed, and a unique original working key is generated by combining the hardware true random entropy value with the key derivation function, and then bound and stored with the attribute declaration. Extract all multidimensional attribute parameters from the attribute declaration, and extract the appropriate multidimensional attribute parameters from all the multidimensional attribute parameters according to the security level of the target electronic control unit; Based on the adapted multidimensional attribute parameters, a security attribute management strategy is generated.

[0012] In an optional implementation, injecting the key to be distributed into a local key slot in ciphertext form includes: Determine the security level of the key to be distributed, and retrieve the local key slot that matches the security level; The key to be distributed is injected in encrypted form into a local key slot that matches the security level.

[0013] In a second aspect of this application, a key distribution apparatus is also provided, the apparatus comprising: The key acquisition module is used to acquire the key to be distributed and the security attribute control policy; The parameter comparison module is used to perform the following steps through the hardware security module of the vehicle-side security gateway: extracting multi-dimensional constraint parameters from the security attribute control strategy and obtaining the attribute declaration of the target electronic control unit, wherein the attribute declaration contains multi-dimensional attribute parameters characterizing the actual operating conditions of the target electronic control unit; and comparing the multi-dimensional constraint parameters with the multi-dimensional attribute parameters one by one. The key distribution module is used to determine whether to distribute the key to be distributed to the target electronic control unit based on the comparison result.

[0014] In a third aspect of the embodiments of this application, a vehicle is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the key distribution methods described in the first aspect above.

[0015] In a fourth aspect of the embodiments of this application, a storage medium is also provided, the storage medium storing instructions that, when run on a computer, cause the computer to execute any of the key distribution methods described in the first aspect above.

[0016] In a fifth aspect of the embodiments of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the key distribution methods described above.

[0017] The technical solution provided in this application embodiment obtains the key to be distributed and the security attribute management policy; and performs the following steps through the hardware security module of the vehicle-side security gateway: extracting multi-dimensional constraint parameters from the security attribute management policy and obtaining the attribute declaration of the target electronic control unit, the attribute declaration containing multi-dimensional attribute parameters characterizing the actual operating conditions of the target electronic control unit, comparing the multi-dimensional constraint parameters with the multi-dimensional attribute parameters one by one; and determining whether to distribute the key to be distributed to the target electronic control unit based on the comparison results.

[0018] This solution first obtains the key to be distributed and the security attribute management policy. Relying on the hardware security module built into the vehicle-side security gateway, it extracts multi-dimensional constraint parameters within the policy and reads multi-dimensional attribute parameters from the attribute declaration of the target ECU. The two types of parameters are cross-compared one by one before determining the key distribution permission. Compared with the fixed processing solution that uses unified broadcast and only relies on device ID to complete the matching, it can get rid of the limitation that the lower limit of vehicle security protection is restricted by low-protection-level auxiliary ECUs. By establishing a layered authentication threshold through the fine verification of multi-dimensional operating conditions and hardware security specification parameters, it blocks the path of low-specification ECUs to obtain high-security-level keys from the distribution source, reduces the risks of illegal key injection, key theft and leakage, and comprehensively makes up for the security shortcomings of unified management of vehicle-mounted keys, and improves the key distribution security protection capability of ECU clusters with differentiated security specifications under the vehicle domain control architecture. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0022] Figure 1 This is a schematic diagram illustrating the basic implementation process of a key distribution method shown in the embodiments of this application; Figure 2 This is a schematic diagram of the architecture of a key distribution system shown in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the basic implementation process of another key distribution method shown in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of a key distribution device shown in an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of a vehicle device shown in an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0025] The current automotive electronic and electrical architecture is undergoing a comprehensive upgrade towards domain control, with vehicles gradually being equipped with a large number of ECUs (Electronic Control Units) of varying security specifications. Core functional domain ECUs, such as those for powertrain, chassis, and autonomous driving, are equipped with independent HSM (Hardware Security Management) modules, possessing high-level security capabilities including hardware-level encryption / decryption and secure storage. However, auxiliary ECUs such as those for windows, lights, and seats, due to cost considerations, lack dedicated security encryption hardware, resulting in a lower overall security level. During daily vehicle operation, core business scenarios such as key matching, controller program updates, remote fault diagnosis, and encrypted vehicle-to-cloud interaction all require key distribution, injection, and authorization authentication between multiple ECUs throughout the vehicle.

[0026] During the R&D phase, multiple rounds of real-vehicle integration testing and penetration testing revealed that existing in-vehicle key distribution systems generally employ a globally unified broadcast transmission key and a fixed processing logic that only uses a single device ID for identity matching. This results in a single authentication and verification dimension, failing to differentiate between the hardware security specifications, operating conditions, and business access permissions of various ECUs. Under this model, the overall vehicle security protection standard is forced to accommodate the weakest-protected auxiliary ECUs in the vehicle body, resulting in significant shortcomings in the security system. Penetration testing repeatedly demonstrated high-risk security vulnerabilities such as low-level ECUs unauthorized interception and theft of high-security keys, illegal program injection to tamper with keys, and cross-domain key leakage. This system is unsuitable for the overall vehicle security management requirements of a domain control architecture with multiple security-level ECUs coexisting.

[0027] To address the security deficiencies of the existing technologies, this application proposes an in-vehicle key distribution authentication scheme based on multi-dimensional attribute constraints. The overall approach relies on the HSM hardware security module built into the vehicle-side security gateway and introduces a security attribute management strategy to achieve layered and refined authentication. Instead of relying solely on a single device identifier for verification, the scheme extracts multi-dimensional constraint parameters from the strategy and compares them item by item with the multi-dimensional attribute parameters in the attribute declaration of the target ECU under actual operating conditions. Based on the comparison results, the key distribution permissions are dynamically managed, intercepting unauthorized access behavior from the source of key distribution, thus adapting to the security management requirements of ECU clusters with differentiated safety specifications in the vehicle.

[0028] Based on the above inventive concept, such as Figure 1 The diagram shown illustrates the implementation flow of a key distribution method provided in this application embodiment. This method is applied to a vehicle-side security gateway and specifically includes the following steps: S101, Obtain the key to be distributed and the security attribute control policy.

[0029] In this embodiment, obtaining the key to be distributed and the security attribute control strategy are the preliminary steps for the entire key authentication and distribution process. The key to be distributed is the key data that needs to be sent to the target ECU to complete encrypted interaction and program verification in business scenarios such as key matching, program refresh, and remote diagnostics. The security attribute control strategy is a pre-configured authentication constraint rule that distinguishes ECUs with different security levels. The strategy defines various dimensions and standards that need to be verified for key distribution.

[0030] The two types of data originate from various sources, such as cloud-based distribution and local gateway pre-storage. The vehicle-side security gateway can retrieve the distribution key and security attribute control policy corresponding to this service from the cloud security platform, or it can directly read the distribution key and security attribute control policy pre-fixed in the local security storage area. After the gateway completes the reading of both types of data, it sends them to the built-in HSM hardware security module for subsequent multi-dimensional parameter comparison and authentication.

[0031] S102, the following steps are executed through the hardware security module of the vehicle-side security gateway.

[0032] S103, extract multi-dimensional constraint parameters from the security attribute control strategy.

[0033] S104, Obtain the attribute declaration of the target electronic control unit. The attribute declaration contains multi-dimensional attribute parameters that characterize the actual operating conditions of the target electronic control unit.

[0034] S105 compares the multidimensional constraint parameters with the multidimensional attribute parameters one by one.

[0035] In this embodiment, after obtaining the key to be distributed and the security attribute control policy, all authentication and comparison logic is executed in isolation within the hardware security module built into the vehicle-side security gateway. This prevents sensitive data such as keys and policies from being exposed in the gateway's ordinary memory, thus preventing data tampering and theft. As an independent security hardware carrier, the hardware security module possesses independent encryption and secure storage isolation capabilities, ensuring that the subsequent multi-dimensional constraint parameter extraction and ECU attribute parameter comparison processes are not interfered with by external programs, thus meeting the requirements of the vehicle-mounted SHE hardware security specification.

[0036] This step includes two consecutive sub-operations: First, extracting preset multi-dimensional constraint parameters from the acquired security attribute control strategy, and simultaneously reading the attribute declarations pre-uploaded by the target electronic control unit and signed and stored by the gateway. The attribute declarations contain multi-dimensional attribute parameters that can characterize the hardware security level label, chip identifier, and real-time security status (such as whether secure startup is complete) of the target electronic control unit. Second, comparing and verifying the extracted multi-dimensional constraint parameters with the multi-dimensional attribute parameters in the attribute declarations item by item, and completely storing the comparison results of each dimension to provide a complete basis for subsequent key distribution permission determination.

[0037] For example, when a vehicle performs an autonomous driving domain controller program refresh, the gateway first retrieves the dedicated key to be distributed for this refresh, along with the corresponding security attribute control policy issued from the cloud. Then, it sends both sets of data to the local hardware security module. The hardware security module extracts multi-dimensional constraint parameters from the security attribute control policy, including the chip's unique ID, security level label, and real-time safety conditions. It then reads the attribute declaration uploaded by the autonomous driving domain controller, extracting the ECU chip's unique ID, real-time safety conditions, security level label, and other multi-dimensional attribute parameters. The module compares the multi-dimensional constraint parameters with the ECU's multi-dimensional attribute parameters one by one, recording the matching result for each dimension. This data is used for subsequent comprehensive determination of whether to allow the key to be issued.

[0038] S106, determine whether to distribute the key to be distributed to the target electronic control unit based on the comparison result.

[0039] In this embodiment, this step is the final determination stage of authentication and distribution. All determination logic is still completed within the hardware security module of the vehicle-side security gateway. The distribution permission is determined by comprehensively judging all verification records generated from the comparison of multi-dimensional constraint parameters and multi-dimensional attribute parameters in the previous stage. The determination rule adopts a full-dimensional pass mechanism: the key distribution process is only executed when all multi-dimensional attribute parameters of the target electronic control unit match the multi-dimensional constraint parameters corresponding to the security attribute control strategy, and all comparison items pass the verification.

[0040] If any dimension parameter comparison fails to meet the constraints, the key distribution request is directly intercepted, the key data to be distributed is discarded, and a security anomaly audit log is simultaneously generated and uploaded to the cloud server. This judgment logic differs from the traditional fixed solution that relies solely on matching a single device ID. It forms fine-grained access control through joint verification of multi-dimensional attributes, eliminating risks such as low-protection-level ECUs obtaining high-security keys without authorization and illegal key injection from the source. It adapts to the management needs of ECU clusters with differentiated security specifications under the vehicle domain control architecture, and also conforms to the permission isolation requirements for key distribution in the SHE hardware security specification.

[0041] For example, after the hardware security module completes the comparison of each multi-dimensional parameter, the target ECU chip ID, security level label, and real-time safety conditions all match the multi-dimensional constraint parameters in the control strategy. All comparison results are passed. The hardware security module determines that it is allowed to distribute the dedicated key to be distributed for this refresh to the autonomous driving domain controller. Then, it performs the secondary encryption and bus-based key ciphertext packet distribution process. The ECU-side HSM completes the key security injection in accordance with the SHE specification.

[0042] Based on the above description of the technical solution provided in the embodiments of this application, the key to be distributed and the security attribute management strategy are obtained; the hardware security module of the vehicle-side security gateway performs the following steps: extracting multi-dimensional constraint parameters from the security attribute management strategy, and obtaining the attribute declaration of the target electronic control unit, the attribute declaration containing multi-dimensional attribute parameters characterizing the actual operating conditions of the target electronic control unit, comparing the multi-dimensional constraint parameters with the multi-dimensional attribute parameters one by one; and determining whether to distribute the key to be distributed to the target electronic control unit based on the comparison results.

[0043] This solution first obtains the key to be distributed and the security attribute management policy. Relying on the hardware security module built into the vehicle-side security gateway, it extracts multi-dimensional constraint parameters within the policy and reads the multi-dimensional attribute declarations of the target ECU containing real operating condition information. The two types of parameters are cross-compared one by one before determining the key distribution permission. Compared with the fixed processing solution that uses unified broadcast and only relies on device ID to complete the matching, it can get rid of the limitation that the lower limit of vehicle security protection is restricted by low-protection-level auxiliary ECUs. By establishing a layered authentication threshold through the fine verification of multi-dimensional operating conditions and hardware security specification parameters, it blocks the path of low-specification ECUs to obtain high-security-level keys from the distribution source, reduces the risks of illegal key injection, key theft and leakage, and comprehensively makes up for the security shortcomings of unified management of vehicle-mounted keys, and improves the key distribution security protection capability of ECU clusters with differentiated security specifications under the vehicle domain control architecture.

[0044] In addition, such as Figure 2 The diagram shown is an architectural schematic of a key distribution system provided in an embodiment of this application, comprising three logical layers: a cloud-based key service layer, a vehicle-side security gateway layer, and an ECU execution layer.

[0045] When a vehicle needs to distribute a new key to an ECU (such as an intelligent driving domain controller), the vehicle-side security gateway (SGW) first collects the target ECU's unique hardware identifier (such as a chip ID), current security status (such as whether secure boot is complete), and its preset security level label. This information is packaged into an "attribute statement." The SGW digitally signs this "attribute statement" using its internal HSM certificate and then sends it along with the key request to the cloud-based attribute authentication server (AS).

[0046] After the cloud-based AS verifies the digital signature, it obtains or generates the corresponding raw working key (Key_raw) from the Key Management Server (KMS) based on the target ECU's "attribute declaration". Then, the cloud-based AS formulates an "attribute policy", such as: "This key is only allowed to be injected into ECUs with chip ID 123... and a high security level". The cloud-based AS uses a public key encryption algorithm that only the SGW can decrypt to encrypt and package the Key_raw and the attribute policy to generate an "encrypted attribute policy package", which is then sent to the SGW.

[0047] Upon receiving the "encrypted attribute policy packet," the SGW decrypts it using its own HSM's private key, obtaining the plaintext attribute policy and Key_raw. The SGW's HSM rigorously verifies the attribute policy: checking whether the ECU identifier and security level specified in the policy match the actual ECU status in the vehicle. If verification fails, the key is immediately discarded and an alarm is triggered.

[0048] After successful verification, the SGW's HSM will perform a crucial step – secondary dynamic encryption. Instead of sending the Key_raw directly, it generates a temporary session nonce and, combined with the target ECU's hardware ID, re-encrypts the Key_raw using a lightweight encryption algorithm (e.g., AES-128), generating a one-time, device-bound ciphertext packet. The SGW then sends this one-time ciphertext packet to the target ECU via the vehicle bus (e.g., CAN FD or Ethernet).

[0049] For high-security ECUs with integrated HSMs, the HSM can use its stored unique key and hardware ID to reverse-engineer the Nonce and Key_raw, and then inject the Key_raw in encrypted form into its key slot strictly following SHE and other standard procedures. The Key_raw can then be used for message authentication or data encryption. For standard security ECUs, the process is simplified; the decrypted Key_raw can be used directly, but the system will record a lower level of security audit log.

[0050] Based on the above, such as Figure 3The diagram shown illustrates the implementation flow of another key distribution method provided in this application embodiment. This method is applied to a vehicle-side security gateway and may specifically include the following steps: S301: Obtain the attribute declaration of the target electronic control unit and digitally sign the attribute declaration through the hardware security module of the vehicle-side security gateway.

[0051] In this embodiment of the application, the attribute declaration of the target electronic control unit is obtained, and the attribute declaration is digitally signed by the hardware security module of the vehicle-side security gateway.

[0052] The vehicle-side security gateway obtains the attribute declaration reported by the target electronic control unit (ECU). This attribute declaration contains multi-dimensional attribute parameters characterizing the actual operating conditions of the target ECU. The attribute declaration is then sent to the hardware security module of the vehicle-side security gateway, which performs a digital signature operation. The hardware security module has a pre-installed dedicated signature private key, which is only processed internally and cannot be exported. During the signing process, a hash digest of the complete attribute declaration is first calculated, and then the digest is encrypted using the built-in private key to generate a digital signature. This digital signature is then bound to the original attribute declaration to obtain an attribute declaration carrying the digital signature, which is subsequently encapsulated into a key application request and sent to the cloud-based attribute authentication server.

[0053] The cloud-based attribute authentication server holds the corresponding verification public key, which can be used to verify digital signatures. This not only confirms that the key application request was issued by a compliant vehicle-side security gateway, preventing the forgery of attribute declarations to obtain keys, but also identifies multi-dimensional attribute parameters that have been tampered with during transmission. If the verification fails, the key issuance process is terminated directly.

[0054] Taking the vehicle body controller as the target electronic control unit as an example, the vehicle-side security gateway obtains the attribute declaration of the body controller through the in-vehicle bus. This attribute declaration includes multi-dimensional attribute parameters such as the body controller's trusted identity identifier (e.g., hardware identification code or hardware fingerprint), security level, and current security status. The vehicle-side security gateway submits this attribute declaration to its own hardware security module, which uses its internally fixed private key to digitally sign the attribute declaration. The signed attribute declaration is then encapsulated into a key request and uploaded to the cloud attribute authentication server. The cloud attribute authentication server parses the attribute declaration with the digital signature in the key request and verifies the digital signature. If the multi-dimensional attribute parameters in the attribute declaration are tampered with during transmission, the digital signature verification fails. The cloud will not retrieve the original working key from the key management server, nor will it generate a security attribute control policy, directly blocking the illegal key distribution process.

[0055] S302, encapsulate the attribute declaration carrying the digital signature into the key request request, and send the key request request to the cloud attribute authentication server so that the cloud attribute authentication server performs the following steps.

[0056] In this embodiment, after the vehicle-side security gateway completes the digital signature of the attribute declaration, it packages the original attribute declaration and the corresponding digital signature into a complete key application request message, and uploads it to the cloud attribute authentication server through the vehicle-cloud communication channel, triggering the entire key processing process on the cloud side, that is, executing subsequent steps S303~S306.

[0057] For example, taking the vehicle power controller as the target electronic control unit: the gateway assembles the power controller attribute declaration with its own HSM signature into a key request request, uploads it to the cloud attribute authentication server through the vehicle TBOX, and after receiving the message, the cloud performs parsing, signature verification, key acquisition, policy generation, encryption packaging, and distribution operations in sequence.

[0058] S303, resolve the attribute declaration of the digital signature carried in the key request and verify the digital signature.

[0059] In this embodiment, after receiving the key application request, the cloud-based attribute authentication server splits the message to extract the attribute declaration carrying the digital signature; and uses the verification public key paired with the signature private key of the vehicle-side security gateway hardware security module to verify the validity of the digital signature.

[0060] If the multidimensional attribute parameters in the attribute declaration are tampered with during transmission, or if the message is externally forged, the digital signature verification will fail, and the cloud will directly terminate the process and will no longer perform subsequent key and policy generation operations.

[0061] S304: If the digital signature verification is successful, obtain the corresponding original working key from the key management server according to the attribute declaration, and generate a security attribute control policy.

[0062] In this embodiment of the application, after the digital signature verification is correct and the attribute declaration is confirmed to be true and tamper-proof, the cloud attribute authentication server uses the multi-dimensional attribute parameters contained in the attribute declaration as a basis to coordinate with the key management server to process the original working key and generate a unique security attribute control policy.

[0063] The process involves retrieving the key management server. If a matching, valid original working key exists, it is retrieved directly. If no matching key exists or the original key has expired, a new original working key is generated based on the attribute declaration and bound to the attribute declaration of the target electronic control unit. All multi-dimensional attribute parameters from the attribute declaration are extracted and combined with the security level adaptation verification dimensions of the target electronic control unit to generate a security attribute control strategy for vehicle-side comparison and verification.

[0064] For example, after the digital signature verification is successful, the cloud-based attribute authentication server queries the key management server based on the attribute declaration of the power controller; if there is no valid key, the attribute declaration is used as the seed derived key; at the same time, based on the multi-dimensional attribute parameters in the attribute declaration of the power controller, corresponding multi-dimensional constraint parameters are generated and written into the security attribute control policy.

[0065] S305 encrypts the original working key and security attribute control policy to obtain the encrypted attribute policy package.

[0066] In this embodiment, the cloud-based attribute authentication server merges the acquired / generated original working key and security attribute control policy into a set of data, encrypts it as a whole using the public key of the vehicle-side security gateway hardware security module, and generates an encrypted attribute policy package to prevent the key and control policy from being leaked or tampered with in plaintext during vehicle-to-cloud transmission.

[0067] For example, the cloud-based attribute authentication server merges the original working key corresponding to the power controller and the matching security attribute control policy, encrypts it with the public key in the SGW's HSM, and generates an encrypted attribute policy package. The key and multi-dimensional constraint parameters cannot be directly read from the message.

[0068] S306 sends the encryption attribute policy package to the vehicle-side security gateway.

[0069] In this embodiment, after the cloud-based attribute authentication server completes the encryption and packaging, it sends the encrypted attribute policy package to the vehicle-side security gateway through the vehicle-cloud link. The vehicle then decrypts the package to separate the original working key and the security attribute control policy, and performs subsequent multi-dimensional parameter comparison and key distribution processes.

[0070] For example, the cloud-based attribute authentication server sends an encrypted attribute policy package to the vehicle-mounted TBOX, which then forwards it to the vehicle-side security gateway. The vehicle-side security gateway decrypts the policy package using its local HSM private key, extracting the original working key corresponding to the power controller as the key to be distributed, as well as the corresponding security attribute control policy.

[0071] S307 receives the encrypted attribute policy packet and decrypts it through the hardware security module of the vehicle-side security gateway to obtain the original working key and security attribute control policy.

[0072] S308, the original working key is determined as the key to be distributed.

[0073] In this embodiment, the vehicle-side security gateway receives the encrypted attribute policy package sent by the cloud attribute authentication server and sends the encrypted attribute policy package to its own hardware security module to perform decryption. The hardware security module uses the built-in, non-exportable gateway private key to decrypt the temporary symmetric session key encrypted by the public key in the encrypted attribute policy package, and then uses the temporary symmetric session key to decrypt the ciphertext, separating two plaintext data segments: the original working key and the security attribute control policy.

[0074] After decryption, an integrity check is performed. If the check passes, the original working key is extracted and defined as the key to be distributed. At the same time, the security attribute control policy is retained for subsequent extraction of multi-dimensional constraint parameters, which are compared with the multi-dimensional attribute parameters of the target electronic control unit one by one. If decryption fails or the integrity check fails, the data packet is discarded directly, and the subsequent key comparison and distribution process is not carried out.

[0075] For example, the cloud-based attribute authentication server sends the encrypted attribute policy package corresponding to the power controller to the vehicle-side security gateway; the vehicle-side security gateway HSM uses its built-in private key to decrypt and obtain the cloud-based temporary SM4 symmetric key, and decrypts the original working key and security attribute control policy; after verifying that the data is complete and correct, the original working key is marked as the key to be distributed, and multi-dimensional constraint parameters are extracted from the security attribute control policy, in preparation for comparison with the multi-dimensional attribute parameters in the power controller attribute declaration.

[0076] Decryption is completed using a hardware security module, and the gateway private key is not exposed to the outside world, thus avoiding the leakage of the original working key and multi-dimensional constraint parameters during the decryption process. After decryption, two types of core data are separated to distinguish between the key to be distributed and the control strategy for verification, which supports the subsequent local authentication and verification logic on the vehicle side. Only decrypted and legitimate data packets can proceed to the next stage of distribution judgment.

[0077] S309, the following steps are performed through the hardware security module of the vehicle-side security gateway.

[0078] S310 extracts multi-dimensional constraint parameters from the safety attribute control strategy and obtains the attribute declaration of the target electronic control unit. The attribute declaration contains multi-dimensional attribute parameters that characterize the actual operating conditions of the target electronic control unit.

[0079] S311 compares the multidimensional constraint parameters with the multidimensional attribute parameters one by one.

[0080] In this embodiment, after decryption to obtain the original working key and security attribute control policy, all verification operations are independently executed by the hardware security module of the vehicle-side security gateway, without going through the gateway's ordinary application layer, to prevent parameters and keys from being stolen and tampered with by upper-layer programs.

[0081] The hardware security module reads the security attribute control policy stored locally and parses out the multi-dimensional constraint parameters pre-configured by the cloud attribute authentication server. This set of parameters is the admission verification standard for this key distribution.

[0082] The hardware security module reads the attribute declaration reported by the target electronic control unit through the in-vehicle communication bus. This attribute declaration carries multi-dimensional attribute parameters that can reflect the actual operating conditions of the target electronic control unit, and is the actual identity and operating status data of the device side.

[0083] The hardware security module matches and compares each constraint parameter in the security attribute management policy with each corresponding attribute parameter in the attribute declaration, records the comparison results item by item, and uses all the comparison results as the basis for determining whether to issue a key in the future.

[0084] S312, determine whether to distribute the key to be distributed to the target electronic control unit based on the comparison result.

[0085] In this embodiment of the application, when the multidimensional constraint parameters and multidimensional attribute parameters are matched one by one, a temporary session random number is generated by the hardware security module of the vehicle-side security gateway, and the session random number and the key to be distributed are encrypted using the trusted identity identifier of the target electronic control unit to obtain a ciphertext packet.

[0086] The vehicle-side security gateway distributes the encrypted packet to the target electronic control unit (ECU), enabling the ECU to perform the following steps: using the ECU's hardware security module and its trusted identity identifier, the encrypted packet is decrypted to obtain a session random number and a key to be distributed; the session random number is compared with locally stored historical session random numbers; if the session random number does not match the historical session random number, the key to be distributed is injected into the local key slot in encrypted form; if the session random number matches the historical session random number, the key to be distributed is discarded and a security alarm is generated.

[0087] When all multi-dimensional constraint parameters of the security attribute control strategy match the multi-dimensional attribute parameters in the target electronic control unit's attribute declaration, the key distribution admission conditions are met, and the encryption distribution process begins. Otherwise, the key is immediately discarded and an alarm is triggered. The vehicle-side security gateway's hardware security module generates a temporary session random number, which is bound to a single key distribution session to defend against message replay attacks. Using the encryption key corresponding to the target electronic control unit's trusted identity as the encryption factor, the session random number and the key to be distributed are encrypted together to generate a ciphertext packet. The encryption operation is completed entirely within the hardware security module, and the key to be distributed will not leak out of the hardware in plaintext form. The vehicle-side security gateway distributes the assembled ciphertext packet to the target electronic control unit via the vehicle bus, where the target electronic control unit's local hardware security module performs decryption verification.

[0088] The target electronic control unit invokes its own hardware security module, using the decryption key corresponding to its trusted identity identifier to decrypt the encrypted packet. After decryption, two sets of data are separated: a session random number and a key to be distributed. The session random number obtained from this decryption is compared with historical session random numbers stored locally, and handled in two ways: If they do not match, it is determined to be a brand new and legitimate key distribution session, and the key to be distributed is encrypted and stored in the corresponding key slot on the local machine for long-term use; if they match, it is determined to be a replay attack, and the key to be distributed in this instance is discarded, and a local security alarm is generated to record the abnormal behavior.

[0089] For example, taking the vehicle powertrain controller (high-security ECU) as the target electronic control unit: If all multi-dimensional constraint parameters and powertrain controller multi-dimensional attribute parameters pass the comparison, the vehicle-side security gateway (HSM) generates a new temporary session random number. The HSM uses the powertrain controller's trusted identity identifier and associated key to encrypt the session random number and the original working key together, and outputs an encrypted packet to the powertrain controller. The powertrain controller's built-in HSM decrypts the encrypted packet using its own trusted identity identifier, reading out the session random number and the key to be distributed. The powertrain controller retrieves the previous session random number stored in its local flash memory for comparison: If the two sets of random numbers are different, the key to be distributed is encrypted and written to its own dedicated high-security key slot; if the two sets of random numbers are exactly the same, the intercepted old message has been repeatedly sent, the key is discarded directly, and a security alarm log is recorded and uploaded to the vehicle-side security gateway.

[0090] This approach ensures that encrypted key delivery is only initiated after all dimensional parameters have passed verification, intercepting devices that do not comply with security policies from the source. A single-session random number is introduced to bind the transmitted message, ensuring that multiple deliveries using the same key produce completely different ciphertexts, preventing attackers from intercepting messages and retrieving the key. The ECU locally stores historical session random numbers for comparison, accurately identifying replay attacks and preventing the repeated delivery of stolen messages and unauthorized rewriting of controller keys. The key is transmitted and stored in ciphertext form throughout the entire process, and encryption and decryption are performed by the hardware security modules at both ends based on the trusted identity identifier of the device. The plaintext key is not exposed on the vehicle's bus, improving the overall vehicle bus transmission security.

[0091] Furthermore, in this embodiment, before generating a temporary session random number through the hardware security module of the vehicle-side security gateway, the security level of the target electronic control unit can be determined. If the security level reaches a preset high security level threshold, the step of generating a temporary session random number through the hardware security module of the vehicle-side security gateway is executed. If the security level does not reach the preset high security level threshold, the key to be distributed is distributed to the target electronic control unit, so that the target electronic control unit injects the key to be distributed into its local key slot.

[0092] Here, a hierarchical distribution branch is set up. Before the vehicle-side security gateway HSM generates a session random number, the security level of the target electronic control unit is determined. Based on whether the preset high security level threshold is reached, two differentiated key distribution processes are executed.

[0093] After the multidimensional constraint parameters and multidimensional attribute parameters are compared one by one and the access conditions are met, the vehicle-side safety gateway reads the safety level label carried in the attribute declaration of the target electronic control unit and compares it with the preset high safety level threshold.

[0094] If the security level of the target electronic control unit reaches the preset high security level threshold, the high security distribution link is executed: the hardware security module of the vehicle security gateway generates a temporary session random number, which is then combined with the ECU's trusted identity to encrypt the session random number and the key to be distributed to form an encrypted packet for distribution. The ECU performs anti-replay verification of the session random number locally and then stores it in the key slot.

[0095] If the security level of the target electronic control unit does not reach the preset high security level threshold, a simplified distribution process is adopted: the key to be distributed is directly sent to the target electronic control unit, eliminating the steps of session random number generation, compound encryption, and local random number comparison; after receiving the key, the target electronic control unit directly injects the key to be distributed into the local key slot, and at the same time generates a low security level special audit log for local storage, which is used for cloud traceability and verification.

[0096] For example, the target electronic control unit is the vehicle power controller, whose attribute declaration indicates a security level of 3. The system presets a high security level threshold of level 2, and the system determines that it meets the standard. The vehicle-side security gateway (HSM) generates a session random number, encrypts and packages it for distribution, and the controller verifies that the random number is not duplicated before storing it in the high security dedicated key slot.

[0097] The target electronic control unit is the vehicle lighting controller, with an attribute declaration indicating a security level of 1, which does not meet the preset high security level threshold. The vehicle-side security gateway directly issues the key to be distributed, and the lighting controller receives it and writes it directly into the ordinary key slot. The vehicle-side security gateway simultaneously records the simplified distribution audit log.

[0098] This tiered approach adapts to the security requirements of different controllers. High-security ECUs incorporate multiple layers of protection, including session random numbers, double-layer encryption, and replay protection verification. Standard ECUs simplify the process and reduce hardware computational overhead for gateways and ECUs, balancing security with vehicle real-time performance. Differentiated management based on device security levels prevents low-security ECUs from consuming hardware encryption and random number generation resources, reducing the amount of data exchange on the vehicle's bus. Standard ECUs are equipped with an audit log retention mechanism to compensate for the lack of replay protection verification capabilities in the simplified process. Key issuance behavior can be traced back through cloud logs afterward, forming a security safety net.

[0099] Furthermore, in this embodiment, before obtaining the corresponding original working key from the key management server according to the attribute declaration and generating the security attribute control policy, it is also possible to verify whether the timestamp is within the valid validity period; if the timestamp is within the valid validity period, the steps of obtaining the corresponding original working key from the key management server according to the attribute declaration and generating the security attribute control policy are executed; if the timestamp is not within the valid validity period, the steps of obtaining the corresponding original working key from the key management server according to the attribute declaration and generating the security attribute control policy are refused.

[0100] This section, located after the cloud-based attribute authentication server completes digital signature verification and before retrieving the original working key and generating security attribute control policies, performs timeliness verification on the timestamp carried in the attribute declaration, dividing the process into two branches.

[0101] The cloud-based attribute authentication server extracts the timestamp attached to the vehicle-side security gateway when it reports the attribute declaration, which has passed verification. This timestamp is the local standard time when the vehicle collects the ECU attribute declaration and initiates the key application request. The cloud reads its own standard synchronization time and matches it against the system's preset valid time window to determine whether the timestamp attached to the attribute declaration falls within the valid time range.

[0102] If the timestamp is within the valid period, the key request is considered a fresh message that has not been intercepted and retained for a long time, and the subsequent process proceeds normally: the original working key is obtained from the key management server based on the attribute statement, and a security attribute control policy is generated. If the timestamp is outside the valid period, the message is considered an expired message, posing a security risk of being intercepted and replayed with delays. The process is terminated directly, the original working key is refused to be retrieved, the security attribute control policy is refused to be generated, and the abnormal request is logged for future reference.

[0103] For example, taking the key application process of a vehicle body controller as an example: When the vehicle-side security gateway collects the attribute declaration of the body controller, it adds a local timestamp, signs it with an HSM, and uploads it to the cloud; the cloud completes digital signature verification, extracts the timestamp from the attribute declaration, and the system presets a valid time window of 60 seconds; Scenario 1: The difference between the current time in the cloud and the timestamp of the message is 20 seconds, which is within the valid time window, and the original working key is obtained by normally retrieving the key management server, and the corresponding security attribute control policy is generated; Scenario 2: The message is intercepted by the attacker and resent after being held for 2 minutes. The cloud compares the timestamp difference and finds that it exceeds the 60-second time window, so it directly refuses to generate the key and control policy and records the timeout exception log.

[0104] This method of intercepting long-term expired messages compensates for the limitation of digital signatures, which only verify integrity and cannot distinguish between new and old messages, providing a two-layer protection against message delay replay attacks. It also filters offline retained and delayed reissue requests for old keys, preventing attackers from repeatedly using historically valid messages to fraudulently obtain ECU working keys. Furthermore, it implements pre-verification of timeliness, intercepting abnormal requests before key and policy generation, reducing the overhead of invalid queries on the cloud key management server, and improving cloud processing efficiency. Expired requests are logged, allowing maintenance personnel to locate security incidents such as bus eavesdropping and message hijacking based on these logs.

[0105] Furthermore, in this embodiment, step S104, obtaining the attribute declaration of the target electronic control unit, can specifically be related to the security level of the target electronic control unit. That is, determining the security level of the target electronic control unit and obtaining the attribute declaration of the target electronic control unit that matches the security level.

[0106] This section describes how the vehicle-side security gateway collects attribute statements from target electronic control units (ECUs). The collected content is adapted to the different security levels of the devices: The vehicle-side security gateway first identifies the preset security level of the target ECU, distinguishing between high-security-level and standard-security-level devices. Based on the identified security level, it reads the corresponding multi-dimensional attribute parameters and assembles them to form an attribute statement adapted to that security level.

[0107] Specifically, if the security level reaches the preset high security threshold: multi-dimensional attribute parameters are collected, including complete information such as the target electronic control unit's trusted identity identifier, firmware integrity verification value, secure boot status, real-time operating conditions, and hardware fault status, forming a high-dimensional attribute declaration; if the security level does not reach the preset high security threshold: only basic dimension parameters are collected, retaining only the trusted identity identifier and basic operating conditions, simplifying the attribute declaration collection content and reducing the amount of bus data interaction. After collection, the complete attribute declaration adapted to the security level is sent to the hardware security module for digital signature execution, proceeding to the subsequent key application and upload process.

[0108] For example, the target electronic control unit is the vehicle brake controller, and the safety level reaches the preset high safety level threshold; the gateway collects complete multi-dimensional parameters, including hardware trusted identity, firmware verification code, safety start flag, and braking system operating condition, and generates a high-dimensional attribute declaration before signing and uploading it.

[0109] The target electronic control unit is an exterior rearview mirror controller, and its security level does not reach the preset high security level threshold. The gateway only collects two basic parameters: hardware trusted identity and basic working status, generates a simplified attribute declaration, and then signs and uploads it.

[0110] This tiered data collection system matches the protection capabilities of the devices. High-security ECUs collect more verification dimensions, supporting cloud-based generation of more stringent security attribute control strategies and enhancing the protection strength of high-risk devices. Ordinary low-security ECUs simplify the collection parameters, reduce the load on the in-vehicle bus transmission, reduce the amount of data for gateway HSM signature calculations, and improve the real-time performance of vehicle communication. The attribute declaration dimensions correspond one-to-one with the device security level. When multi-dimensional constraint parameters are subsequently generated in the cloud and compared item by item on the vehicle, the parameter dimension matching is redundant, avoiding the consumption of hardware resources by comparing invalid parameters.

[0111] Furthermore, in this embodiment, in step S304 above, obtaining the corresponding original working key from the key management server according to the attribute declaration and generating a security attribute control strategy can specifically be as follows: if the key management server stores an original working key that matches the attribute declaration and is in a normal state, then the original working key is obtained; if the key management server does not have a matching original working key or the matching original working key has expired, then the attribute declaration is used as a derivation seed, and a unique original working key is generated by combining the hardware true random entropy value with a key derivation function, and then bound and stored with the attribute declaration; all multi-dimensional attribute parameters in the attribute declaration are extracted, and according to the security level of the target electronic control unit, suitable multi-dimensional attribute parameters are extracted from all multi-dimensional attribute parameters; and a security attribute control strategy is generated based on the suitable multi-dimensional attribute parameters.

[0112] Here, the cloud-based attribute authentication server synchronously completes two major tasks—original working key retrieval / generation and security attribute management policy generation—after the attribute declaration timestamp validity verification and digital signature verification have all passed. The overall process is divided into two logic segments: key processing and policy generation.

[0113] The cloud-based attribute authentication server uses the multi-dimensional attribute parameters in the attribute declaration as matching conditions to search the key management server: if a matching original working key with a normal status is found, it is directly read; a normal key status means that the key has not expired, has not reached the maximum number of issuances, and the device has not been blacklisted; if there is no matching key, or the matching key has expired, the number of issuances has been exhausted, or the device is blacklisted and deemed invalid, the key derivation process is initiated; the multi-dimensional attribute parameters such as trusted identity identifier, security level, and operating condition parameters contained in the attribute declaration are used as derivation seeds, and the entropy value output by the cloud hardware true random source is superimposed and input into the key derivation function to generate the original working key unique to the device; after generation, the new key is bound and associated with the current attribute declaration and stored in the key management server, and the corresponding binding record is retained.

[0114] Extract all multi-dimensional attribute parameters carried in the attribute declaration and perform screening and adaptation based on the security level of the target electronic control unit: for high-security-level devices, retain all dimension parameters as verification standards; for low-security-level devices, remove some unnecessary verification dimensions and retain only basic identification parameters. Based on the screened and adapted multi-dimensional attribute parameters, construct a multi-dimensional constraint parameter set, and write the parameter matching rules, verification failure handling logic, and policy validity period into it to generate a security attribute control policy specific to this key distribution.

[0115] This reuse of valid keys reduces redundant derivation operations. When a key expires, a new key is derived based on the device's unique attributes, ensuring one key per device. Key leakage only affects a single ECU, preventing the risk from spreading. Keys are stored in a bound manner with attribute declarations, allowing the cloud to trace the device identity and application status corresponding to each key, facilitating post-event security audits. The verification dimensions of the control strategy are dynamically tailored according to security levels, with multiple verifications for high-security devices and lightweight verifications for low-security devices, balancing overall vehicle security with cloud computing efficiency. Policies are strongly bound to device attributes and security levels, enabling differentiated and refined access control and avoiding the risk of unauthorized access caused by uniform and lenient policies.

[0116] In addition, in this embodiment of the application, injecting the key to be distributed into the local key slot in ciphertext form can be related to the security level of the key to be distributed, that is, determining the security level of the key to be distributed, retrieving the local key slot that matches the security level, and injecting the key to be distributed into the local key slot that matches the security level in ciphertext form.

[0117] This is the key storage logic for the target electronic control unit side. It is executed after the session random number comparison is inconsistent and the session is deemed legitimate. The keys are stored in partitions according to their security level to avoid mixing keys with different protection levels.

[0118] The target electronic control unit's hardware security module reads the security level tag corresponding to the currently received key to be distributed, and this security level corresponds to the target electronic control unit's own security level.

[0119] The ECU locally divides multiple independent and isolated key slots, with each key slot pre-bound to a corresponding security level; based on the identified key security level, it retrieves the exclusive matching key slot in the local storage space.

[0120] The encrypted key to be distributed is written into an independent key slot that matches the security level; keys of different security levels are isolated from each other, and low-privilege logic cannot read data in the key slot of a high-security level.

[0121] For example, when a motor controller issues a high-security key to be distributed, the ECU recognizes that the key's security level has reached a preset high-security threshold, retrieves the local high-security isolated key slot, and stores the working key in encrypted form into that dedicated key slot, which ordinary applications do not have access to.

[0122] This key slot is physically / logically isolated according to security level, preventing low-level programs from unauthorizedly reading high-security keys and reducing the attack surface for key leakage; each key is matched with a storage area, facilitating local permission control of the ECU and accurate location of the corresponding key during key rotation and destruction; different storage areas avoid mixing high and low security keys, reducing the risk of all keys being leaked if a single storage area is compromised.

[0123] Corresponding to the above method embodiments, this application also provides a key distribution device, such as... Figure 4 As shown, the device may include: a key acquisition module 410, a parameter comparison module 420, and a key distribution module 430.

[0124] The key acquisition module 410 is used to acquire the key to be distributed and the security attribute control policy; The parameter comparison module 420 is used to perform the following steps through the hardware security module of the vehicle-side security gateway: extracting multi-dimensional constraint parameters from the security attribute control strategy and obtaining the attribute declaration of the target electronic control unit, wherein the attribute declaration contains multi-dimensional attribute parameters characterizing the actual operating conditions of the target electronic control unit; and comparing the multi-dimensional constraint parameters with the multi-dimensional attribute parameters one by one. The key distribution module 430 is used to determine whether to distribute the key to be distributed to the target electronic control unit based on the comparison result.

[0125] This application also provides a vehicle, such as... Figure 5 As shown, it includes a processor 501, a communication interface 502, a memory 503, and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504. Memory 503 is used to store computer programs; When processor 501 executes the program stored in memory 503, it performs the following steps: Obtain the key to be distributed and the security attribute management policy; perform the following steps through the hardware security module of the vehicle-side security gateway: extract multi-dimensional constraint parameters from the security attribute management policy, and obtain the attribute declaration of the target electronic control unit, wherein the attribute declaration contains multi-dimensional attribute parameters characterizing the actual operating conditions of the target electronic control unit; compare the multi-dimensional constraint parameters with the multi-dimensional attribute parameters one by one; determine whether to distribute the key to be distributed to the target electronic control unit based on the comparison results.

[0126] The communication bus mentioned in the above vehicles can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0127] The communication interface is used for communication between the aforementioned vehicle and other devices.

[0128] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0129] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0130] In another embodiment provided in this application, a storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute any of the key distribution methods described in the above embodiments.

[0131] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the key distribution methods described in the above embodiments.

[0132] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a storage medium or transmitted from one storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0133] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0134] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0135] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A key distribution method, characterized in that, Applied to a vehicle-side security gateway, the method includes: Obtain the keys to be distributed and the security attribute management policy; The following steps are performed through the hardware security module of the vehicle-side security gateway: extracting multi-dimensional constraint parameters from the security attribute control strategy and obtaining the attribute declaration of the target electronic control unit, wherein the attribute declaration contains multi-dimensional attribute parameters characterizing the actual operating conditions of the target electronic control unit; comparing the multi-dimensional constraint parameters with the multi-dimensional attribute parameters one by one; Based on the comparison results, determine whether to distribute the key to be distributed to the target electronic control unit.

2. The method according to claim 1, characterized in that, Before performing the step of obtaining the key to be distributed and the security attribute control policy, the following steps are also included: Obtain the attribute declaration of the target electronic control unit, and digitally sign the attribute declaration through the hardware security module of the vehicle-side security gateway; Encapsulate the attribute declaration carrying the digital signature into a key request, and send the key request to the cloud attribute authentication server so that the cloud attribute authentication server performs the following steps: The key request request contains the attribute declaration of the digital signature, and the digital signature is verified. Once the digital signature verification is successful, the corresponding original working key is obtained from the key management server based on the attribute declaration, and a security attribute control policy is generated. The original working key is sent to the vehicle-side security gateway as the key to be distributed, along with the security attribute control policy.

3. The method according to claim 1, characterized in that, The step of determining whether to distribute the key to be distributed to the target electronic control unit based on the comparison result includes: When the multidimensional constraint parameters and the multidimensional attribute parameters are matched one by one, a temporary session random number is generated by the hardware security module of the vehicle-side security gateway, and the session random number and the key to be distributed are encrypted using the trusted identity identifier of the target electronic control unit to obtain a ciphertext packet. The encrypted packet is distributed to the target electronic control unit, causing the target electronic control unit to perform the following steps: The encrypted packet is decrypted using the hardware security module of the target electronic control unit and its trusted identity identifier to obtain the session random number and the key to be distributed. Compare the session random number with the locally stored historical session random number. If the session random number is inconsistent with the historical session random number, inject the key to be distributed into the local key slot in ciphertext form. If the session random number matches the historical session random number, the key to be distributed is discarded and a security alarm is generated.

4. The method according to claim 3, characterized in that, Before the hardware security module of the vehicle-side security gateway generates a temporary session random number, the method further includes: The security level of the target electronic control unit is determined, and if the security level reaches a preset high security level threshold, the step of generating a temporary session random number through the hardware security module of the vehicle-side security gateway is executed.

5. The method according to claim 4, characterized in that, The method further includes: If the security level does not reach the preset high security level threshold, the key to be distributed is distributed to the target electronic control unit so that the target electronic control unit injects the key to be distributed into its local key slot.

6. The method according to claim 2, characterized in that, The attribute declaration carries a timestamp; before obtaining the corresponding original working key from the key management server based on the attribute declaration and generating the security attribute control policy, the process also includes: Verify whether the timestamp is within the valid validity period; If the timestamp is within the valid time limit, the steps of obtaining the corresponding original working key from the key management server according to the attribute declaration and generating the security attribute control policy are executed. If the timestamp is not within the valid time limit, the steps of obtaining the corresponding original working key from the key management server based on the attribute declaration and generating the security attribute control policy shall be refused.

7. The method according to claim 2, characterized in that, The acquisition of the attribute declaration of the target electronic control unit includes: Determine the security level of the target electronic control unit and obtain the attribute declaration of the target electronic control unit that is compatible with the security level.

8. The method according to claim 2, characterized in that, The step of obtaining the corresponding original working key from the key management server based on the attribute declaration, and generating a security attribute control policy, includes: If the key management server stores an original working key that matches the attribute declaration and is in a normal state, then obtain the original working key; If there is no matching original working key in the key management server or the matching original working key has expired, the attribute declaration is used as the derivation seed, and a unique original working key is generated by combining the hardware true random entropy value with the key derivation function, and then bound and stored with the attribute declaration. Extract all multidimensional attribute parameters from the attribute declaration, and extract the appropriate multidimensional attribute parameters from all the multidimensional attribute parameters according to the security level of the target electronic control unit; Based on the adapted multidimensional attribute parameters, a security attribute management strategy is generated.

9. The method according to claim 3, characterized in that, The step of injecting the key to be distributed into the local key slot in ciphertext form includes: Determine the security level of the key to be distributed, and retrieve the local key slot that matches the security level; The key to be distributed is injected in encrypted form into a local key slot that matches the security level.

10. A vehicle, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-9.

Images