A vehicle password service management method and system

Abstract

The application provides a vehicle password service management method and system. The method takes the vehicle-end password service bus as the core of the whole vehicle unified password management architecture. The originally heterogeneous password libraries of each ECU, domain controller and upper-layer application are integrated into a distributed password node cluster divided according to security domains, and the password service bus is used as the unified password service entrance of the whole vehicle. At the same time, by identifying the service type and the home security domain of the request, the matching execution node is screened in the distributed password node cluster of the corresponding security domain, the whole vehicle password computing power is scheduled as needed, and the safety execution standard of the password operation is uniformly controlled. Finally, the target password node is called to perform the password operation with the exclusive domain key of the corresponding security domain, the isolation of the key according to the security domain and the controllable management of the whole process are realized, the originally disordered key storage and distribution mode is replaced, the risk of key leakage and illegal tampering is avoided, and the safety of the whole vehicle password service management is effectively improved.

Description

Technical Field

[0001] This application relates to a field of expertise, and in particular to a method and system for managing vehicle password services. Background Technology

[0002] Currently, in-vehicle cryptography systems typically employ independent, heterogeneous cryptographic libraries and key management schemes for ECU domain controllers and upper-layer applications from different suppliers. This leads to a wasteful duplication of in-vehicle computing resources, inconsistent cryptographic service interfaces across different components, and varying security levels across modules, hindering unified vehicle-wide cryptographic management. Furthermore, the vehicle generates numerous different types of keys during operation, based on the type of in-vehicle controller. These keys lack comprehensive vehicle-wide planning and management; some are even stored insecurely in general-purpose flash memory or distributed through insecure channels, posing a high risk of leakage and unauthorized tampering. Summary of the Invention

[0003] In view of the above problems, in order to improve the security of vehicle password service management, this application provides a vehicle password service management method and system.

[0004] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a vehicle cryptographic service management method applied to a vehicle-side cryptographic service bus, wherein the vehicle-side includes multiple in-vehicle applications and multiple security domains; each security domain includes a pre-built distributed cryptographic node cluster, and each security domain is associated with a separate domain key; the domain key is derived from a root key built in the cloud for the vehicle-side; the method includes: In response to a cryptographic service request from the in-vehicle application, a demand analysis is performed on the cryptographic service request to obtain the service request type of the cryptographic service request and the target security domain to which the cryptographic service request belongs. Based on the service request type, cryptographic nodes are filtered within the distributed cryptographic node cluster corresponding to the target security domain to determine the target cryptographic node that matches the service request type. The target cryptographic node is invoked, and the cryptographic operation indicated by the cryptographic service request is executed according to the target domain key corresponding to the target security domain. The execution result of the cryptographic operation is then fed back to the vehicle application.

[0005] In one possible implementation, the step of performing a requirements analysis on the cryptographic service request to obtain the service request type of the cryptographic service request and the target security domain to which the cryptographic service request belongs includes: The cryptographic service request is subjected to demand quantification processing to determine the security level quantification value, performance demand quantification value, and identity identifier of the in-vehicle application of the cryptographic service request. Demand analysis is performed based on the security level quantification value and the performance requirement quantification value to determine the service request type; and functional analysis is performed based on the identity identifier of the in-vehicle application to determine the target security domain.

[0006] In one possible implementation, the cryptographic service request includes a target domain key, a target cryptographic operation, a target amount of data to be processed, and a target latency; the method for determining the security level quantification value includes: The cryptographic service request is subjected to feature parsing to determine the operational security level associated with the target domain key and the operational security weight associated with the target cryptographic operation. Operational safety is quantified based on the operational safety level and the operational safety weight to obtain the quantified value of the safety level. The methods for determining the quantitative values ​​of the performance requirements include: The cryptographic service request is subjected to feature parsing to determine the computational throughput requirement level associated with the target data processing volume and the response timeliness requirement level associated with the target latency. Operational performance is quantified based on the computational throughput requirement level and the response timeliness requirement level to obtain the quantified performance requirement value.

[0007] In one possible implementation, the service request type includes a first service request, a second service request, and a third service request; the step of determining the service request type based on the security level quantification value and the performance requirement quantification value includes: If only the security level quantification value is greater than the security quantification threshold, the service request type is determined to be the first service request; If only the quantified value of the performance requirement is greater than the performance quantification threshold, the service request type is determined to be the second service request; If the security level quantification value is not greater than the security quantification threshold and the performance requirement quantification value is not greater than the performance quantification threshold, the service request is determined to be the third service request. If the security level quantification value is greater than the security quantification threshold and the performance requirement quantification value is greater than the performance quantification threshold, the service request type is determined to be the fourth service request.

[0008] In one possible implementation, the distributed cryptographic node cluster includes a first cryptographic node, a second cryptographic node, and a third cryptographic node; The first cryptographic node is used to store the domain key and the root key of the vehicle terminal, and to perform the cryptographic operations indicated by the cryptographic service request through the built-in HSM module or TEE environment; the security level of the first cryptographic node is higher than that of the second cryptographic node and the third cryptographic node. The second cryptographic node is used to execute the cryptographic operations indicated by the cryptographic service request through a built-in hardware acceleration engine; the computing performance and maximum throughput of the second cryptographic node are greater than those of the first cryptographic node and the third cryptographic node. The hardware resource consumption of the third cryptographic node is lower than that of the first cryptographic node and the second cryptographic node.

[0009] In one possible implementation, the step of filtering cryptographic nodes within the distributed cryptographic node cluster corresponding to the target security domain based on the service request type to determine the target cryptographic node matching the service request type includes: If the service request type is the first service request, the first cryptographic node is determined as the target cryptographic node; If the service request type is the second service request, the second cryptographic node is determined as the target cryptographic node; If the service request type is the third service request, the third cryptographic node is identified as the target cryptographic node; In the case where the service request type is the fourth service request, the first cryptographic node is determined as the target cryptographic node.

[0010] In one possible implementation, prior to performing requirements analysis on the cryptographic service request, the method further includes: The password service request is validated based on the request parameters and preset validity verification rules. If the request parameters match the preset validity verification rules, the validity verification of the password service request is determined to be passed. The request parameters include: application identity token, request operation type, and request key identifier; the preset legality verification rules include: identity verification rules and operation verification rules; The identity verification rules include: the application identity token is matched with a pre-defined set of legitimate applications; The operation verification rules include: the requested operation type matches a pre-defined set of operation types; Specifically, if the request parameters match both the identity verification rule and the operation verification rule, then the request parameters are determined to match the preset legality verification rule.

[0011] In one possible implementation, the method further includes: In response to a domain key update command from the cloud, the domain key indicated by the domain key update command is updated.

[0012] In one possible implementation, after performing the cryptographic operation indicated by the cryptographic service request, the method further includes: Based on the result of the password operation, an audit log for the password service request is generated; The audit log signature is stored in a preset security log area.

[0013] Secondly, embodiments of this application provide a vehicle cryptographic service management system applied to a vehicle-side cryptographic service bus. The vehicle-side includes multiple in-vehicle applications and multiple security domains. Each security domain includes a pre-built distributed cryptographic node cluster, and each security domain is associated with a separate domain key. The domain key is derived from a root key built in the cloud for the vehicle-side. The system includes: The request analysis module is used to respond to the password service request from the vehicle application, perform demand analysis on the password service request, and obtain the service request type of the password service request and the target security domain to which the password service request belongs. The node filtering module is used to filter cryptographic nodes in the distributed cryptographic node cluster corresponding to the target security domain based on the service request type, and determine the target cryptographic node that matches the service request type. The node invocation module is used to invoke the target cryptographic node, execute the cryptographic operation indicated by the cryptographic service request according to the target domain key corresponding to the target security domain, and feed back the cryptographic operation execution result to the vehicle application.

[0014] Compared to existing technologies, this application offers the following advantages: This application provides a vehicle cryptographic service management method and system. The method utilizes a unified vehicle cryptographic management architecture centered on the vehicle-side cryptographic service bus. It integrates the heterogeneous cryptographic libraries of various ECUs, domain controllers, and upper-layer applications into a distributed cryptographic node cluster divided by security domains. The cryptographic service bus serves as the unified cryptographic service entry point for the entire vehicle, uniformly responding to and processing cryptographic service requests from all in-vehicle applications. This achieves standardized compatibility of the vehicle's cryptographic service interface and solves the problem of inconsistent security protection levels among different components, hindering unified vehicle-level cryptographic management. Furthermore, by identifying the service type and security domain of the request, matching execution nodes are selected within the distributed cryptographic node cluster of the corresponding security domain. Vehicle cryptographic computing power is scheduled as needed, and the security execution standards for cryptographic operations are uniformly controlled. Ultimately, the matching target cryptographic node is invoked to perform cryptographic operations using the exclusive domain key of the corresponding security domain. This achieves key isolation by security domain and full-process controllable management, replacing the original disordered key storage and distribution mode, avoiding the risks of key leakage and illegal tampering, and building a unified and controllable cryptographic security management system at the vehicle level, effectively improving the security of vehicle cryptographic service management. Attached Figure Description

[0015] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a vehicle password service management method provided in this application embodiment; Figure 2 A flowchart illustrating a method for determining a service request type and target security domain, provided in an embodiment of this application; Figure 3 A flowchart illustrating another vehicle password service management method provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of a vehicle password service management system provided in an embodiment of this application. Detailed Implementation

[0017] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0018] As described earlier, current in-vehicle cryptography systems typically employ independent, heterogeneous cryptographic libraries and key management schemes for ECU domain controllers and upper-layer applications from different suppliers. This directly leads to a redundant waste of in-vehicle computing resources, a lack of unified compatibility between cryptographic service interfaces of different components, and inconsistent security levels across modules, making it impossible to implement unified cryptographic management at the vehicle level. Furthermore, during vehicle operation, a large number of different types of keys are generated based on the type of in-vehicle controller. These keys lack vehicle-level planning and management, and some keys are even stored insecurely in general-purpose flash memory or distributed through insecure channels, posing a high risk of leakage and unauthorized tampering.

[0019] Based on this, this application provides a vehicle cryptographic service management method and system. This method uses a unified vehicle cryptographic management architecture centered on the vehicle-side cryptographic service bus. It integrates the heterogeneous cryptographic libraries originally provided by each ECU, domain controller, and upper-layer application into a distributed cryptographic node cluster divided by security domain. The cryptographic service bus serves as the unified cryptographic service entry point for the entire vehicle, uniformly responding to and processing cryptographic service requests from all in-vehicle applications. This achieves standardized compatibility of the vehicle cryptographic service interface and solves the problem of inconsistent security protection levels among different components, which prevents unified vehicle-level cryptographic management. Simultaneously, by identifying the service type and security domain of the request, matching execution nodes are selected within the distributed cryptographic node cluster of the corresponding security domain. Vehicle cryptographic computing power is scheduled as needed, and the secure execution standards for cryptographic operations are uniformly controlled. Ultimately, the matching target cryptographic node is invoked to perform cryptographic operations using the exclusive domain key of the corresponding security domain. This achieves key isolation by security domain and full-process controllable management, replacing the original disordered key storage and distribution mode, avoiding the risks of key leakage and illegal tampering, and building a unified and controllable cryptographic security management system at the vehicle level, effectively improving the security of vehicle cryptographic service management.

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0021] See Figure 1 This figure is a flowchart illustrating a vehicle cryptographic service management method provided in an embodiment of this application. It should be noted that the vehicle cryptographic service management method provided in this embodiment is applied to the vehicle-side cryptographic service bus. This bus serves as the scheduling center for the unified cryptographic service of the entire vehicle, undertaking and managing the cryptographic service needs across all vehicle scenarios. The vehicle-side environment includes multiple in-vehicle applications that initiate cryptographic service requests, covering all in-vehicle business scenarios requiring cryptographic capabilities, such as intelligent driving, vehicle control communication, OTA (Over-the-Air Technology) upgrades, and infotainment. Simultaneously, the vehicle-side is divided into multiple isolated security domains based on functional safety levels and business attributes. Each security domain has a pre-built dedicated distributed cryptographic node cluster. This cluster serves as the physical execution carrier for cryptographic operations within the corresponding security domain, providing cryptographic service capabilities with different security levels and computational performance, thereby achieving distributed deployment and hierarchical scheduling of cryptographic computing power across the entire vehicle. Simultaneously, each security domain is associated with a unique domain key, which is derived from the unique vehicle root key generated by the cloud for the corresponding vehicle. Using the cloud root key as the vehicle's trust anchor, a hierarchical and traceable key trust chain is constructed, achieving key isolation and control between different security domains. This prevents the leakage of a single domain key from affecting the overall vehicle's cryptographic security, providing a secure key system and computing power scheduling foundation for unified vehicle cryptographic service management. Specifically, this method includes the following steps: S101: In response to the cryptographic service request from the vehicle application, perform a demand analysis on the cryptographic service request to obtain the service request type of the cryptographic service request and the target security domain to which the cryptographic service request belongs.

[0022] As a key execution node in the cryptographic service management system of this example, the cryptographic service bus relies on a unified request access point for unified cryptographic management. In the application scenario of this example, the vehicle-side cryptographic service bus establishes a unified request access point for all in-vehicle applications. All cryptographic service requests initiated by in-vehicle applications are responded to and received by the cryptographic service bus in real time through this entry point. The bus first performs standardized preprocessing on the received requests, converting heterogeneous format requests initiated by in-vehicle applications from different suppliers and functional domains into a standard data structure that can be uniformly processed within the bus. At the same time, it extracts the feature elements within the requests, including the cryptographic operation attributes corresponding to the request, the business affiliation information of the initiator, and functional association information. After completing the element extraction, the bus conducts a two-dimensional requirements analysis. In the first dimension, based on the business attributes of the cryptographic operation itself, it clearly determines the service request type and distinguishes the corresponding cryptographic service category. In the second dimension, based on the business affiliation and functional association of the request initiator, it matches and determines the target security domain of the entire vehicle to which the request belongs. The entire analysis process is completed locally on the vehicle, without relying on real-time interaction with the cloud, and can adapt to the low-latency processing requirements of the in-vehicle scenario.

[0023] For details, see Figure 2 This figure is a flowchart illustrating a method for determining service request type and target security domain according to an embodiment of this application. The figure describes the process in step S101 of performing a requirements analysis on a cryptographic service request to determine the service request type and target security domain. Specifically, this is achieved through the following three steps: S1011: Perform requirement quantification processing on the cryptographic service request to determine the security level quantification value, performance requirement quantification value, and identity identifier of the vehicle application.

[0024] In response to in-vehicle cryptographic service requests from in-vehicle applications, the cryptographic service bus extracts four characteristics from the request: the target domain key, the target cryptographic operation, the target data processing volume, and the target latency. It also extracts the in-vehicle application's identity credentials and digital signature information attached to the request, completing standardized preprocessing of the original request data. For the security level quantification, the bus uses a preset security level associated with the target domain key as the base weight, combined with the overall vehicle security impact coefficient corresponding to the target cryptographic operation (operations involving key management and secure startup verification correspond to higher security coefficients), and calculates the quantified security level using a weighted average. For the performance requirement quantification, the bus determines the computational throughput requirement level based on the target data processing volume, combines the response time requirement corresponding to the target latency, and adds the computational complexity coefficient of the target cryptographic operation, calculating the quantified performance requirement using a weighted average.

[0025] Specifically, the security level quantification value is determined through the following two steps: Step 1: Perform feature parsing on the cryptographic service request to determine the operational security level associated with the target domain key and the operational security weight associated with the target cryptographic operation.

[0026] This step is implemented based on the feature parsing module built into the service bus and the pre-configured security rule base. First, feature parsing is performed on the cryptographic service request to extract two features: the target domain key and the target cryptographic operation. Then, based on a locally cached key security level mapping table synchronized with the cloud-based vehicle-wide cryptographic policy, the operation security level corresponding to the target domain key is matched. This mapping table pre-classifies different domain keys into multiple security levels based on key type, storage security environment, and the functional security level of the associated security domain. For example, the domain master key and root key correspond to the highest security level, while ordinary business working keys correspond to the standard security level. Simultaneously, the bus determines the corresponding operation security weight based on the business attributes and security impact scope of the target cryptographic operation. Operations involving private key operations, key lifecycle management, and secure startup verification correspond to high weights, while routine integrity checks and non-sensitive data encryption / decryption operations correspond to low weights.

[0027] Step 2: Quantify the operation safety based on the operation safety level and the operation safety weight to obtain the quantified value of the safety level.

[0028] Furthermore, a weighted quantization standardized calculation model is used to output the quantified security level value. Based on the operational security level obtained in step one, a quantified score is established, and operational security weights are used as weighting coefficients. A pre-defined quantification formula is used to perform a weighted calculation, ultimately yielding a quantified security level value that falls within a fixed numerical range. This result can directly provide a clear basis for determining the type of subsequent service requests. The entire quantification calculation process is completed within the vehicle's local security zone, without relying on real-time cloud interaction, adapting to the low-latency processing requirements of in-vehicle scenarios. Simultaneously, the rules and formulas for quantification calculation can be dynamically updated along with the cryptographic policies issued from the cloud, adapting to changes in overall vehicle security requirements.

[0029] On the other hand, the quantified value of performance requirements is determined through the following two steps: Step 1: Perform feature parsing on the cryptographic service request to determine the computational throughput requirement level associated with the target data processing volume and the response timeliness requirement level associated with the target latency.

[0030] The performance requirement quantification is achieved based on the service bus's built-in request feature parsing module and pre-configured performance level mapping rules. First, standardized feature parsing is performed on cryptographic service requests to extract the target data processing volume and target latency from the request parameters. Then, based on a locally cached throughput level mapping table synchronized with the vehicle's cryptographic service strategy, the throughput requirement level corresponding to the target data processing volume is matched. This mapping table is divided into multiple levels according to the data scale of typical in-vehicle business scenarios; for example, GB-level autonomous driving map data corresponds to a high throughput level, and KB-level in-vehicle communication messages correspond to a low throughput level. Simultaneously, the bus determines the response timeliness requirement level by matching the pre-defined timeliness level mapping rules based on the end-to-end processing timeliness requirements corresponding to the target latency; for example, real-time vehicle control communication corresponds to a high timeliness level, and background encryption / decryption of non-sensitive data corresponds to a normal timeliness level.

[0031] Step 2: Quantify the operational performance based on the computational throughput requirement level and the response time requirement level to obtain the quantified performance requirement value.

[0032] Furthermore, a standardized calculation model with dual-dimensional weighting is used to output the quantified value of performance requirements. Using the computational throughput requirement level and response time requirement level obtained in step one as quantification factors, combined with weighting coefficients preset for the vehicle-mounted business scenario, a standardized quantification formula is used to complete the weighted calculation, ultimately yielding a quantified value of performance requirements falling within a fixed numerical range. This result can directly provide a clear basis for determining the type of subsequent service requests.

[0033] S1012: Perform a requirement analysis based on the security level quantification value and the performance requirement quantification value to determine the service request type.

[0034] In this example method, service request types are divided into three types: first service request (which can be understood as a service request with high security requirements), second service request (which can be understood as a service request with high performance requirements), and third service request (which can be understood as a service request with regular requirements). The execution of this step relies on the pre-stored security quantification threshold and performance quantification threshold that are completely consistent with the cloud-based vehicle password security policy. The two types of thresholds can be partitioned and dynamically adjusted according to the vehicle security requirements and business scenario characteristics to ensure that the judgment benchmark always meets the security control requirements.

[0035] After determining the quantified values ​​of security level and performance requirements for a cryptographic service request, the bus simultaneously performs a comparison operation between two quantified thresholds and their corresponding pre-stored thresholds. First, a mutual exclusion check is performed on the three basic types of service requests. If the comparison result shows that only the security level quantified value is greater than the security quantified threshold and the performance requirement quantified value does not exceed the performance quantified threshold, the bus classifies the cryptographic service request as a first-class service request. This type of request corresponds to high-security-priority cryptographic operations for the entire vehicle and requires matching the highest-level cryptographic execution capability. If the comparison result shows that only the performance requirement quantified value is greater than the performance quantified threshold and the security level quantified value does not exceed the security quantified threshold, the bus classifies the cryptographic service request as a second-class service request. This type of request corresponds to high-throughput, low-latency cryptographic operation scenarios and requires matching high-performance cryptographic execution capabilities. If the comparison result shows that both the security level quantified value and the performance requirement quantified value are not greater than the security quantified threshold, the bus classifies the cryptographic service request as a third-class service request. This type of request corresponds to regular, lightweight cryptographic operations and is adapted to basic, general-purpose cryptographic execution capabilities.

[0036] In a special case, when both comparison results exceed the corresponding thresholds, i.e., the security level quantification value is greater than the security quantification threshold, and the performance requirement quantification value is greater than the performance quantification threshold, the bus classifies the cryptographic service request as a fourth service request. This type of request has both high security and high performance requirements. When classifying, the bus follows the core principle of security first and locks the execution benchmark of high security level for this type of request.

[0037] S1013: Perform functional analysis based on the identity identifier of the vehicle application to determine the target security domain.

[0038] Steps S1013 and S1012 are processed in parallel. This step is implemented based on the bus's built-in identity verification module and security domain mapping rule base. First, the pre-stored identity identifier-security domain mapping relationship table is retrieved. This table corresponds to isolated security domains such as the vehicle power domain, intelligent driving domain, body domain, and infotainment domain. Each security domain is configured with a dedicated whitelist of legitimate application identities, clearly defining the functional domain and security control boundary of each in-vehicle application. By matching the security domain corresponding to the identity identifier through the mapping relationship table, the target security domain is determined. At the same time, the matching result is bound to the determined service request type, providing a clear domain range constraint for subsequent password node screening. The entire matching process is completed locally on the vehicle.

[0039] The above is an introduction to step S101 within the method of this example. Next, we will continue to combine... Figure 1 The method in this example will be described in detail.

[0040] S102: Based on the service request type, perform cryptographic node filtering within the distributed cryptographic node cluster corresponding to the target security domain to determine the target cryptographic node that matches the service request type.

[0041] In the vehicle-side application of this example method, the cryptographic service bus is primarily responsible for filtering cryptographic nodes and handling communication between cryptographic nodes within the vehicle application for cryptographic service requests. The actual response to the cryptographic service request, and subsequently the execution of cryptographic operations, is performed by the designated target cryptographic node. In determining the target cryptographic node from the distributed cryptographic node cluster, the first step is to lock down the dedicated distributed cryptographic node cluster for that security domain based on the target security domain identified in the preceding steps. This defines the effective scope of node filtering, ensuring that cryptographic operations are only performed within nodes belonging to the assigned security domain, thus meeting the isolation and control requirements of different security domains.

[0042] In this embodiment, the distributed cryptographic node cluster is divided into three complementary types of cryptographic nodes—a first cryptographic node, a second cryptographic node, and a third cryptographic node—based on security level, computing performance, and resource consumption characteristics, covering the cryptographic service needs of the entire vehicle scenario. The first cryptographic node is the highest security level node in the cluster, built on an automotive-grade HSM (Hardware Security Module) module or a high-security TEE (Trusted Execution Environment). It is used to securely store the domain key and the vehicle root key of the corresponding security domain and perform high-security cryptographic operations. Its security protection capabilities are significantly higher than those of the second and third cryptographic nodes, making it suitable for security scenarios involving key lifecycle management and secure boot signature verification. The second cryptographic node is a high-performance computing node in the cluster, with a built-in dedicated cryptographic algorithm hardware acceleration engine. It is used to perform high-throughput, low-latency batch cryptographic operations. Its computing performance and maximum processing throughput are significantly higher than those of the first and third cryptographic nodes, making it suitable for large-scale data processing scenarios such as autonomous driving perception data encryption and streaming media decryption. The third cryptographic node is a lightweight adaptation node deployed in the resource-constrained vehicle controller. Its hardware resource consumption is much lower than that of the first and second cryptographic nodes. It is used to perform routine lightweight cryptographic operations and cover the basic cryptographic service needs of the vehicle's distributed system.

[0043] Specifically, the process of filtering target cryptographic nodes in step S102 is implemented through the following four steps, which have no processing order restrictions: Step 1: If the service request type is the first service request, determine the first cryptographic node as the target cryptographic node; Step 2: If the service request type is the second service request, then determine the second cryptographic node as the target cryptographic node; Step 3: If the service request type is the third service request, then the third cryptographic node is determined as the target cryptographic node; Step 4: If the service request type is the fourth service request, then the first cryptographic node is determined as the target cryptographic node.

[0044] When screening target cryptographic nodes, the service request type and target security domain information output from the preceding steps are first obtained. The distributed cryptographic node cluster corresponding to this security domain is then selected as the screening scope. Subsequently, the matching and judgment of service request type and node are carried out simultaneously: when the service request type is identified as the first service request, the first cryptographic node in the cluster is directly identified as the target cryptographic node; when the service request type is identified as the second service request, the second cryptographic node in the cluster is identified as the target cryptographic node; when the service request type is identified as the third service request, the third cryptographic node in the cluster is identified as the target cryptographic node; when a fourth service request with both high security and high performance requirements is identified, following the core principle of security first, the first cryptographic node with the highest security level is identified as the target cryptographic node. The entire matching process is completed locally on the vehicle, and the latency of a single round of judgment can be controlled at the millisecond level, adapting to the real-time processing requirements of in-vehicle scenarios.

[0045] This example method provides rule support for the standardized scheduling of vehicle-wide cryptographic services by filtering target cryptographic nodes, solving the problems of unreasonable resource utilization and low security protection levels in traditional vehicle-mounted cryptographic systems. Firstly, by matching service request types with cryptographic nodes in a one-to-one correspondence, it aligns cryptographic needs with node capabilities, avoiding the waste of computing power caused by high-security nodes handling routine lightweight requests, and preventing security risks from low-security nodes handling high-priority requests, thus achieving optimal scheduling of vehicle-wide cryptographic computing power. Secondly, for the fourth service request, which simultaneously requires high security and high performance, the highest security level node is locked based on the principle of security priority, ensuring the bottom line of core vehicle security operations and avoiding the risk of sacrificing security levels for performance requirements. Thirdly, the unified node filtering rules provide standardized scheduling logic for heterogeneous cryptographic nodes throughout the vehicle, solving the problems of incompatibility between cryptographic component interfaces from different suppliers and inconsistent scheduling rules, laying the foundation for unified cryptographic management at the vehicle level.

[0046] S103: Invoke the target cryptographic node, execute the cryptographic operation indicated by the cryptographic service request according to the target domain key corresponding to the target security domain, and feed back the cryptographic operation execution result to the vehicle application.

[0047] Finally, after identifying the target cryptographic node, the standardized and encapsulated cryptographic service request and the legitimate call instruction for the target domain key corresponding to the target security domain are forwarded to the target cryptographic node through the in-vehicle secure communication channel. Upon receiving the request, the target cryptographic node verifies the legitimacy of the request and the key call authorization. If the verification passes, it calls the target domain key within its own secure execution environment and performs the corresponding cryptographic operations indicated by the cryptographic service request, such as encryption, decryption, signing, signature verification, and hash verification. Specifically, the first cryptographic node completes key call and computation within an HSM or TEE isolated environment, the second cryptographic node performs batch computations through a hardware acceleration engine, and the third cryptographic node performs basic computations using a lightweight algorithm. After the computation is completed, the target cryptographic node encrypts and sends the computation result or error information back to the bus. After the bus verifies the integrity of the result, it feeds it back to the in-vehicle application that initiated the request, and simultaneously records the information of this operation in the audit log. The entire process is completed locally in a closed loop at the vehicle end, adapting to the low latency and high security execution requirements of in-vehicle scenarios.

[0048] The above is an introduction to the vehicle password service management method in this embodiment. In one possible implementation, before performing demand analysis on the password service request in step S101, the password service request can also be validated for legality to ensure the security of the request source. Specifically, the validation of the password service request is achieved through the following two steps: Step 1: Perform a validity check on the password service request based on the request parameters and preset validity check rules.

[0049] The legitimacy verification step is a prerequisite for the cryptographic service bus in processing cryptographic service requests. Upon receiving a cryptographic service request initiated by an in-vehicle application, the subsequent requirements analysis process is first paused, triggering a pre-defined legitimacy verification mechanism. The request is first parsed using standardized methods to extract three verification elements from the request parameters: the application identity token, the request operation type, and the request key identifier. Subsequently, the bus retrieves pre-stored legitimacy verification rules from its local secure storage area and initiates a two-dimensional parallel verification process, simultaneously verifying both identity legitimacy and operation compliance. The bus periodically synchronizes the latest legitimacy verification rules through the vehicle-cloud secure channel, including updates to the sets of legitimate applications and legitimate operation types. These rules are also encrypted and cached locally to ensure that the verification process can still be completed normally even when the vehicle is offline, without affecting the normal in-vehicle cryptographic service.

[0050] Step 2: If the request parameters match the preset validity verification rules, determine that the validity verification of the password service request is passed.

[0051] Specifically, the legitimacy verification is implemented through a two-dimensional parallel approach of identity verification rules and operation verification rules. Both rules must be satisfied simultaneously for the verification to pass. For identity verification, the bus verifies the validity of the extracted application identity token, checking its digital signature for legitimacy, validity period, and tampering. After successful verification, the unique identifier of the in-vehicle application corresponding to the token is compared to determine if it belongs to a pre-defined set of legitimate applications. This set, initially configured during vehicle production, includes the identity information of all in-vehicle applications certified by the OEM and authorized to access password services. Application permissions can be dynamically added or revoked via the cloud. Requests from applications not on the whitelist will be directly deemed as failing identity verification. For operation verification, the bus compares the parsed request operation type with a pre-defined set of legitimate operation types to confirm that the operation belongs to a password operation type permitted by the vehicle's password policy. Simultaneously, it verifies whether the operation type matches the pre-defined usage permissions of the corresponding key, preventing unauthorized key usage.

[0052] After completing the dual-dimensional verification, the corresponding processing flow is executed based on the verification results. The validity of the password service request is deemed passed only if the request parameters simultaneously match both the identity verification rule and the operation verification rule, allowing the request to proceed to the subsequent requirements analysis process. If either verification rule fails to match, the request is immediately rejected, and the corresponding error code is returned. The validity verification of password service requests is the first line of defense for the vehicle's password service, intercepting unauthorized calls from applications, unauthorized password operations, and other security risks. It also prevents invalid requests from consuming the computing resources of the bus and password nodes, thus building a basic security access barrier for the unified password service system of the entire vehicle.

[0053] In another possible implementation, the method of this application embodiment can also respond to domain key update instructions from the cloud, updating the target domain key according to the domain key update instructions issued by the cloud. In practical application scenarios, the cryptographic service bus continuously listens for domain key update instructions from the cloud cryptographic policy and key management center. Upon receiving an instruction, it triggers an instruction legality verification process to verify the digital signature, issuer identity, and validity period of the instruction, ensuring that the instruction comes from a legitimate cloud control center and has not been tampered with. After successful verification, the instruction content is parsed to clarify the target security domain corresponding to this update, the encrypted new domain key material, key activation rules, and old key disposal requirements. Subsequently, the first cryptographic node within the target security domain is coordinated to perform the update operation: the first cryptographic node decrypts and obtains the new domain key within its own HSM or TEE isolated security environment, completes the secure storage of the key, and sets a smooth transition period between the old and new keys according to preset rules to ensure the continuity of vehicle services during the update process. After the update is completed, the execution result is fed back to the bus, and the bus synchronously records the core information of the entire update process, generating structured audit records.

[0054] This setup serves two purposes. First, the cloud-triggered domain key update mechanism enables centralized and automated management of vehicle keys. It allows for rapid key updates for specific security domains or the entire vehicle when keys expire or are detected as a risk of leakage, improving the vehicle's cryptographic system's responsiveness to security threats. Second, the independent key update mechanism for each domain ensures isolated key control between different security domains. Key updates in one security domain do not affect the normal operation of other domains, preventing single-domain key leaks from impacting overall vehicle security and ensuring business continuity during vehicle operation.

[0055] In another possible implementation, after executing the password operation indicated by the password service request, a corresponding audit log can be generated based on the executed password operation and stored in a preset security log area on the vehicle, thereby recording the password operation and ensuring traceability. This is achieved through the following two steps: Step 1: Based on the password operation result, generate an audit log for the password service request; Step 2: Store the audit log signature in the preset security log area.

[0056] After the target cryptographic node completes the cryptographic operation and returns the result to the bus, the auditor deployed within the bus immediately triggers the audit log generation and storage process. During log generation, the auditor extracts and integrates core information from the entire process data of this cryptographic service request, generating a standardized, structured audit log. The log contains a unique tracking ID for this request, an operation timestamp, the identity of the in-vehicle application initiating the request, the type of cryptographic operation performed, the key identifier used, the target cryptographic node, the cryptographic operation result and error code, processing time, and other traceable information covering all key aspects of the cryptographic operation. During log storage, the auditor uses a dedicated signature private key pre-stored on the bus to generate an immutable digital signature for the audit log. The signed audit log is then encrypted and stored in a pre-set secure log area on the vehicle. This log area is deployed in the tamper-proof hardware storage of a high-security cryptographic node, with write access only granted to the auditor. Simultaneously, the bus periodically uploads batch-compressed, encrypted audit logs to the cloud audit module. The entire process complies with automotive-grade cybersecurity standards for traceability, providing data support for compliant auditing and risk tracing of vehicle-wide cryptographic operations.

[0057] This application provides a vehicle cryptographic service management method. This method employs a unified vehicle cryptographic management architecture centered on the vehicle-side cryptographic service bus. It integrates the heterogeneous cryptographic libraries of various ECUs, domain controllers, and upper-layer applications into a distributed cryptographic node cluster divided by security domains. The cryptographic service bus serves as the unified cryptographic service entry point for the entire vehicle, uniformly responding to and processing cryptographic service requests from all in-vehicle applications. This achieves standardized compatibility of the vehicle's cryptographic service interface and solves the problem of inconsistent security protection levels among different components, which prevents unified vehicle-level cryptographic management. Simultaneously, by identifying the service type and security domain of the request, matching execution nodes are selected within the distributed cryptographic node cluster of the corresponding security domain. Vehicle cryptographic computing power is scheduled as needed, and the secure execution standards of cryptographic operations are uniformly controlled. Finally, the matching target cryptographic node is invoked to execute the cryptographic operation using the dedicated domain key of the corresponding security domain. This achieves key isolation by security domain and full-process controllable management, replacing the previously disordered key storage and distribution model. It avoids the risks of key leakage and illegal tampering, constructing a unified and controllable cryptographic security management system at the vehicle level, effectively improving the security of vehicle cryptographic service management.

[0058] For a better understanding of the execution flow of the methods in the embodiments of this application, please refer to [link / reference needed]. Figure 3 The flowchart of another vehicle password service management method disclosed herein will not be elaborated upon in this example.

[0059] The following describes a vehicle password service management system provided by an embodiment of this application. The vehicle password service management system described below can be referred to in correspondence with the vehicle password service management method described above.

[0060] See Figure 4 This figure is a schematic diagram of the structure of a vehicle password service management system provided in an embodiment of this application. The system is applied to a password service bus on the vehicle side, which includes multiple in-vehicle applications and multiple security domains. Each security domain includes a pre-built distributed password node cluster, and each security domain is associated with a separate domain key. The domain key is derived from the root key built in the cloud for the vehicle side. The system includes the following modules: The request analysis module 100 is used to respond to the password service request from the vehicle application, perform demand analysis on the password service request, and obtain the service request type of the password service request and the target security domain to which the password service request belongs. The node filtering module 200 is used to filter cryptographic nodes in the distributed cryptographic node cluster corresponding to the target security domain based on the service request type, and determine the target cryptographic node that matches the service request type. The node invocation module 300 is used to invoke the target cryptographic node, execute the cryptographic operation indicated by the cryptographic service request according to the target domain key corresponding to the target security domain, and feed back the cryptographic operation execution result to the vehicle application.

[0061] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the system and method embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The system and method embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0062] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing vehicle password services, characterized in that, A cryptographic service bus applied to the vehicle, wherein the vehicle includes multiple in-vehicle applications and multiple security domains; each security domain includes a pre-built distributed cryptographic node cluster, and each security domain is associated with a separate domain key; The domain key is derived from the root key constructed in the cloud for the vehicle terminal; the method includes: In response to a cryptographic service request from the in-vehicle application, a demand analysis is performed on the cryptographic service request to obtain the service request type of the cryptographic service request and the target security domain to which the cryptographic service request belongs. Based on the service request type, cryptographic nodes are filtered within the distributed cryptographic node cluster corresponding to the target security domain to determine the target cryptographic node that matches the service request type. The target cryptographic node is invoked, and the cryptographic operation indicated by the cryptographic service request is executed according to the target domain key corresponding to the target security domain. The execution result of the cryptographic operation is then fed back to the vehicle application.

2. The method according to claim 1, characterized in that, The step of performing a demand analysis on the cryptographic service request to obtain the service request type and the target security domain to which the cryptographic service request belongs includes: The cryptographic service request is subjected to demand quantification processing to determine the security level quantification value, performance demand quantification value, and identity identifier of the in-vehicle application of the cryptographic service request. Demand analysis is performed based on the security level quantification value and the performance requirement quantification value to determine the service request type; and functional analysis is performed based on the identity identifier of the in-vehicle application to determine the target security domain.

3. The method according to claim 2, characterized in that, The cryptographic service request includes the target domain key, the target cryptographic operation, the target amount of data to be processed, and the target latency; the method for determining the security level quantification value includes: The cryptographic service request is subjected to feature parsing to determine the operational security level of the target domain key association and the operational security weight of the target cryptographic operation association; Operational safety is quantified based on the operational safety level and the operational safety weight to obtain the quantified value of the safety level. The methods for determining the quantitative values ​​of the performance requirements include: The cryptographic service request is subjected to feature parsing to determine the computational throughput requirement level associated with the target data processing volume and the response timeliness requirement level associated with the target latency. Operational performance is quantified based on the computational throughput requirement level and the response timeliness requirement level to obtain the quantified performance requirement value.

4. The method according to claim 2, characterized in that, The service request types include a first service request, a second service request, and a third service request; the process of determining the service request type based on the security level quantification value and the performance requirement quantification value includes: If only the security level quantification value is greater than the security quantification threshold, the service request type is determined to be the first service request; If only the quantified value of the performance requirement is greater than the performance quantification threshold, the service request type is determined to be the second service request; If the security level quantification value is not greater than the security quantification threshold and the performance requirement quantification value is not greater than the performance quantification threshold, the service request is determined to be the third service request. If the security level quantification value is greater than the security quantification threshold and the performance requirement quantification value is greater than the performance quantification threshold, the service request type is determined to be the fourth service request.

5. The method according to claim 4, characterized in that, The distributed cryptographic node cluster includes a first cryptographic node, a second cryptographic node, and a third cryptographic node; The first cryptographic node is used to store the domain key and the root key of the vehicle terminal, and to perform the cryptographic operations indicated by the cryptographic service request through the built-in HSM module or TEE environment; the security level of the first cryptographic node is higher than that of the second cryptographic node and the third cryptographic node. The second cryptographic node is used to execute the cryptographic operations indicated by the cryptographic service request through a built-in hardware acceleration engine; the computing performance and maximum throughput of the second cryptographic node are greater than those of the first cryptographic node and the third cryptographic node. The hardware resource consumption of the third cryptographic node is lower than that of the first cryptographic node and the second cryptographic node.

6. The method according to claim 5, characterized in that, The step of filtering cryptographic nodes within the distributed cryptographic node cluster corresponding to the target security domain based on the service request type to determine the target cryptographic node matching the service request type includes: If the service request type is the first service request, the first cryptographic node is determined as the target cryptographic node; If the service request type is the second service request, the second cryptographic node is determined as the target cryptographic node; If the service request type is the third service request, the third cryptographic node is identified as the target cryptographic node; In the case where the service request type is the fourth service request, the first cryptographic node is determined as the target cryptographic node.

7. The method according to claim 1, characterized in that, Before performing the requirements analysis on the cryptographic service request, the method further includes: The password service request is validated based on the request parameters and preset validity verification rules. If the request parameters match the preset validity verification rules, the validity verification of the password service request is determined to be passed. The request parameters include: application identity token, request operation type, and request key identifier; the preset legality verification rules include: identity verification rules and operation verification rules; The identity verification rules include: the application identity token is matched with a pre-defined set of legitimate applications; The operation verification rules include: the requested operation type matches a pre-defined set of operation types; Specifically, if the request parameters match both the identity verification rule and the operation verification rule, then the request parameters are determined to match the preset legality verification rule.

8. The method according to claim 1, characterized in that, The method further includes: In response to a domain key update command from the cloud, the domain key indicated by the domain key update command is updated.

9. The method according to claim 1, characterized in that, After executing the cryptographic operation indicated by the cryptographic service request, the method further includes: Based on the result of the password operation, an audit log for the password service request is generated; The audit log signature is stored in a preset security log area.

10. A vehicle password service management system, characterized in that, A cryptographic service bus applied to the vehicle, wherein the vehicle includes multiple in-vehicle applications and multiple security domains; each security domain includes a pre-built distributed cryptographic node cluster, and each security domain is associated with a separate domain key; The domain key is derived from the root key constructed in the cloud for the vehicle terminal; the system includes: The request analysis module is used to respond to the password service request from the vehicle application, perform demand analysis on the password service request, and obtain the service request type of the password service request and the target security domain to which the password service request belongs. The node filtering module is used to filter cryptographic nodes in the distributed cryptographic node cluster corresponding to the target security domain based on the service request type, and determine the target cryptographic node that matches the service request type. The node invocation module is used to invoke the target cryptographic node, execute the cryptographic operation indicated by the cryptographic service request according to the target domain key corresponding to the target security domain, and feed back the cryptographic operation execution result to the vehicle application.

Images