An adaptive secure vehicle-mounted communication method, system, device and medium under a vehicle-mounted domain centralized architecture

Abstract

An adaptive secure vehicular communication method, system, device, and medium under a centralized domain architecture are disclosed. The method is based on zero-trust model theory and utilizes fuzzy comprehensive evaluation and weighted average methods to assess security risks during service subscription. Simultaneously, an adaptive security mechanism is designed to reduce system overhead while ensuring communication security. Furthermore, a novel adaptive secure vehicular communication scheme is designed within the model, based on symmetric cryptography and message authentication codes, with differentiated security protection measures to safeguard the confidentiality, integrity, and non-repudiation of SOME / IP real-time communication messages. Based on lightweight digital certificates, elliptic curve cryptography, and the Chinese Remainder Theorem, key management methods are designed for various SOME / IP communication scenarios. The system, device, and medium, based on this method, conduct security risk assessments during SOME / IP communication, determine security defense mechanisms, and clarify the management process for secure communication keys. It is compatible with both centralized domain architectures and various SOME / IP communication scenarios, ensuring security.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, and in particular relates to an adaptive secure vehicle communication method, system, device and medium under a centralized vehicle domain architecture. Background Technology

[0002] The centralized domain architecture for automobiles refers to dividing the vehicle into several domains based on function. Each domain is centered around a high-performance domain controller, and communication between domain controllers is achieved via in-vehicle Ethernet. Subnets within a domain can use different types of communication buses as needed. Based on this centralized domain architecture, automotive hardware and software are gradually decoupled, and in-vehicle network communication primarily adopts a service-oriented architecture (SOA). SOA is a loosely coupled, fine-grained software architecture where applications communicate through simple and well-defined standardized service interfaces. The most commonly used communication protocol for implementing SOA is the Scalable Service-Oriented Middleware over IP (SOME / IP) protocol. Located at the application layer, SOME / IP communicates using TCP / UDP, with services as the basic communication unit. Each service contains various callable methods and event groups, transmitting information through service interfaces and allocating services on demand. The SOME / IP protocol enables efficient data exchange, real-time event notification, and flexible method invocation in the domain-centralized architecture, meeting complex in-vehicle communication requirements.

[0003] However, while the above communication methods bring convenience, they also bring new challenges to the data transmission security of in-vehicle networks. These challenges manifest in three aspects: (1) The native SOME / IP protocol lacks privacy protection mechanisms such as data encryption and identity authentication. (2) Existing Ethernet-based security protocols cannot adapt to communication scenarios in a domain-centralized architecture. Classic Ethernet security protocols (such as IPsec, TLS, etc.) are incompatible with in-vehicle communication protocols including SOME / IP and will result in significant communication overhead. (3) Existing secure in-vehicle communication solutions based on a domain-centralized architecture are still imperfect. The AUTOSAR organization proposed using the Security Onboard Communication (SecOC) mechanism to protect SOME / IP communication, which provides identity authentication and message replay protection mechanisms. However, SecOC does not support data encryption and is only applicable to the in-vehicle communication architecture of the AUTOSAR platform, resulting in poor compatibility. Marco Iorio et al. proposed an adaptive SOME / IP secure communication solution, which defines security levels and access permissions for each service instance and adopts a hierarchical secure communication strategy, but does not involve the evaluation method for the security level of service instances or the management mechanism for communication keys. In summary, achieving secure in-vehicle communication, properly managing keys, and minimizing communication overhead in a domain-centralized architecture communication scenario is a challenging problem, and there is currently no good solution. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention aims to provide an adaptive secure in-vehicle communication method under a centralized vehicular domain architecture. It employs the basic idea of ​​a zero-trust model, using fuzzy comprehensive evaluation to obtain a basic security score for each SOME / IP service. When a client subscribes to a SOME / IP service, the server assesses the security risk of the subscription request based on the basic security score and real-time security indicators, and adopts an adaptive security protection strategy based on the assessment results. Based on symmetric cryptography and message authentication codes, differentiated security protection measures are designed to ensure the confidentiality, integrity, and non-repudiation of SOME / IP real-time communication messages. Based on lightweight digital certificates, elliptic curve cryptography, and the Chinese Remainder Theorem, authentication handshake and key management schemes are designed for various SOME / IP communication scenarios, including identity authentication, session key generation, distribution, and updating. Finally, extensive experiments have verified the effectiveness of this invention.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] An adaptive and secure vehicular communication method under a centralized vehicular domain architecture, the method having the following assumptions:

[0007] (1) Each vehicle has a certificate distribution center set up in the central domain controller when it leaves the factory. The certificate is bound to the VIN code (Vehicle Identification Number) of each vehicle. It is only valid within the current vehicle and cannot be used for identity authentication processes in other vehicles' internal networks.

[0008] (2) Service safety risk assessment is subjective. It is necessary to obtain the basic safety score of each service based on the fuzzy comprehensive evaluation model when the vehicle leaves the factory. If the basic safety score needs to be modified, the score is reorganized and sent to each vehicle through OTA upgrade.

[0009] (3) The initialization of key parameters and certificates is performed each time the vehicle is powered on. The certificate distribution center will distribute a lightweight digital certificate for each SOME / IP service, which is only valid during the current vehicle power-on period.

[0010] (4) Considering that SOME / IP service subscriptions within the same domain controller do not need to be transmitted through the vehicle network, the adaptive vehicle security communication method under the centralized vehicle domain architecture is only applicable to SOME / IP service communication between different domain controllers.

[0011] An adaptive and secure vehicular communication method under a centralized vehicular domain architecture, comprising the following steps:

[0012] Step 1: System initialization, including basic security scoring of services and initialization of key parameters and certificates;

[0013] Step 2: SOME / IP Service Subscription Authentication Handshake: When a client subscribes to the SOME / IP service from the server, it sends the certificate of its SOME / IP service to the server for authentication. After receiving the certificate, the server verifies the client's identity and legitimacy.

[0014] Step 3: Security Risk Assessment and Security Policy Determination: After Step 2 is completed, the SOME / IP server and client establish a secure communication channel, and proceed to the security risk assessment and security policy determination stage;

[0015] Step 4: Session Key Management; After determining the security policy in Step 3, session key management is required when encrypted communication is needed; Session key management consists of two parts: key negotiation and key update. Key negotiation is further divided into two scenarios: unicast key negotiation and multicast key negotiation.

[0016] Step 5: SOME / IP Secure Communication; After steps one through four are completed, the SOME / IP server and client start SOME / IP communication according to the determined security defense strategy; if encrypted communication is required, the two parties use the negotiated session key for encrypted communication.

[0017] The specific method for step one is as follows:

[0018] System initialization includes two parts: service basic security scoring and key parameter and certificate initialization.

[0019] I. Service Basic Security Score

[0020] Each SOME / IP service in the system should obtain a corresponding basic security score based on the fuzzy comprehensive evaluation method during the system development and design phase; the calculation process for the basic security score is as follows:

[0021] 1) Determining the Factor Set: Treating SOME / IP services as an information asset within the vehicle, and based on the asset identification method specified in the national standard GB / 20984-2022 "Information Security Technology - Information Security Risk Assessment Method," this method mainly includes four parts: business identification, system asset identification, threat identification, and vulnerability identification. When calculating the basic security score, the factor set considered must include at least the influencing factors from the above four aspects; the basic scoring factor set determined based on this is denoted as U. b ={u b1 ,u b2 ,…,u bn};

[0022] 2) Determine the comment set: V = {v1, v2, ..., v} m}; where v i The i-th evaluation result can be represented by different levels, comments, or numbers;

[0023] 3) Determine the weight set: A = {a1, a2, ..., a n When there is no reference data, the weights are determined by analyzing the factor set using the analytic hierarchy process (AHP); when there is reference data, the weights are determined using the entropy weight method.

[0024] 4) Implementation Evaluation: Experts were invited to conduct a comprehensive evaluation of the factors in the factor set based on relevant regulations on automotive information security. The evaluation results were derived from the comment set V.

[0025] 5) Establish an evaluation matrix: The membership degree represents the proportion of experts selecting a specific evaluation result from the comment set V for a given influencing factor in factor set U; if the membership degree of the i-th element in factor set U to the 1-th element in evaluation set V is r... i1 Then, the result of the single-factor evaluation of the i-th element is represented by a fuzzy set as: R i ={r i1 ,r i2 ,…,r im}

[0026] 6) Using m single-factor evaluation sets R1, R2, ..., R m The rows form a matrix R n×m This constitutes the fuzzy comprehensive evaluation matrix:

[0027]

[0028] 7) Comprehensive evaluation

[0029] For weight A, the fuzzy evaluation vector B is calculated using a weighted average fuzzy operator:

[0030]

[0031]

[0032] The evaluation is based on the principle of maximizing membership degree, among which... These are fuzzy operator symbols; different operator symbols correspond to different fuzzy comprehensive evaluation models.

[0033] 8) Calculate the score and obtain the result.

[0034] For the obtained fuzzy evaluation vector B, the basic safety score s is calculated. base :

[0035]

[0036] Where, μ(v) i The rating for each evaluation factor in the comment set is determined by the evaluator; base All are real numbers in the range of 0 to 4, which are sent to the vehicle by the car manufacturer's cloud platform through the car OTA upgrade and are pre-stored in each domain controller;

[0037] II. Key Parameters and Certificate Initialization

[0038] The central domain controller determines three key parameters: Elliptic Curve E p (a,b), base point G and the order q of the base point, and generate a lightweight digital certificate for each SOME / IP service in all domain controllers. Then, the central domain controller will use the elliptic curve E p (a, b), the base point G and the order q of the base point, the key parameters, and the generated certificate are distributed to all domain controllers.

[0039] The specific method for the SOME / IP service subscription authentication handshake in step two is as follows:

[0040] When a client subscribes to the SOME / IP service from the server, it sends the certificate of its SOME / IP service to the server for authentication. After receiving the certificate, the server verifies the client's identity and legitimacy. The authentication process is as follows:

[0041] 2.1) Client signature

[0042] ① The client selects the certificate private key d of the SOME / IP service it belongs to DC (d DC <q, where q is the order of this G), and the public key P DC = d DC G;

[0043] ② The client selects a random integer k (k < q), calculates the point Q = kG = (x1, y1), and sets r = x1;

[0044] ③ The client calculates z = H(m), where m is the authentication message and H(·) is a hash function;

[0045] ④ The client calculates s = k -1 (z + rd DC )(mod q), obtaining the signature (r, s). If either r or s is 0, re - select the random number k and repeat ④;

[0046] ⑤ The client sends the authentication message m containing certificate information and the signature (r, s) to the server;

[0047] 2.2) Server signature verification

[0048] 2.2.1) After receiving the client information, the server calculates z = H(m), u1 = zs -1 mod q, u2 = rs -1 mod q;

[0049] 2.2.2) The server calculates the point (x1, y1) = u1G + u2P DC ;

[0050] 2.2.3) The server verifies whether the equation r ≡ x1 mod q holds. If it holds, the authentication passes; otherwise, the authentication fails.

[0051] The specific method for the security risk assessment and security policy determination in Step 3 is as follows:

[0052] After Step 2 passes, the SOME / IP server and the client establish a secure communication channel and enter the security risk assessment and security policy determination phase. The specific process is as follows:

[0053] 3.1) Server determines the real - time factor set

[0054] The national mandatory standard "Technical Requirements for Information Security of Automobiles" drafted by the Ministry of Industry and Information Technology stipulates that the following factors should be selected as the real-time factor set: client source, number of current service subscription requests, type of SOME / IP interface for subscription requests, and communication traffic of the service port. All factors in this set can be quantified as data; denoted as:

[0055] U r ={u r1 ,u r2 ,u r3 ,u t4}

[0056] Then, the server uses a weighted average method to perform real-time security scoring on the client making the current request. Assuming there are n clients in the request queue, the formula is as follows:

[0057]

[0058] in, This indicates that the i-th real-time factor data is normalized to a real number in the interval [0,4]; h represents the h-th client in the request queue, x, x max x min These represent the current value, the maximum possible value, and the minimum possible value of the real-time factor data, respectively. i Indicates the weight of different real-time factors; the weights are defined by the automaker.

[0059] Finally, the server will assign its basic security score s base The final security score s is obtained by weighting the real-time security scores of all requesting clients according to the following formula. t :

[0060]

[0061] In the formula, m represents the number of client members requesting to subscribe to the service, and s rj Let m represent the real-time security score of the j-th client member, where m is always equal to 1 in a unicast scenario;

[0062] 3.2) The server bases its authentication handshake result and security score on step two. t Based on the adaptive security defense mechanism arrangement scheme listed in Table 1, corresponding security defense measures are adopted; the security risk level is divided into four levels: no risk, low risk, medium risk, and high risk, which correspond to the risk score obtained from the security risk assessment; the higher the security risk level, the higher the security strength of the cryptographic algorithm used.

[0063] 3.3) Both communicating parties will take corresponding security measures to ensure the secure transmission of service data based on the type of service interface subscribed and the results of the security risk assessment;

[0064] Table 1 Adaptive Security Defense Mechanism Orchestration Scheme

[0065]

[0066]

[0067] Note: Step four is not performed when the risk level is no risk.

[0068] The specific method for session key management in step four is as follows:

[0069] Session key management is divided into two parts: key negotiation and key update. Key negotiation is further divided into two scenarios: unicast key negotiation and multicast key negotiation. The Getter and Setter methods in the Method and Field interfaces of the SOME / IP service use request-response or request-no-response unicast communication. The Notifier method in the Event and Field interfaces is triggered by a specific event. After the event is triggered, the server sends the corresponding message to all clients that have subscribed to the event, using multicast communication. Table 2 shows the communication methods of different SOME / IP communication interfaces and the key management schemes that should be adopted.

[0070] 4.1) Unicast Key Negotiation: In unicast scenarios, session key negotiation is performed directly based on the ECDH key exchange protocol.

[0071] 4.1.1) Both communicating parties determine their respective certificate key pairs. The server uses its own certificate private key to obfuscate a random large integer to obtain the negotiated public-private key d. TS and P TS =d TS G, The client obtains the negotiated public / private key d by obfuscating its own certificate private key with a random large integer. TC and P TC =d TC G; Both communicating parties use their respective certificate private keys to P TS P TC Signatures are used to prevent man-in-the-middle attacks.

[0072] 4.1.2) The server and client exchange P via an insecure in-vehicle communication channel. TS and P TC ;

[0073] Table 2 Key Management Schemes for Different SOME / IP Communication Interfaces

[0074]

[0075] 4.1.3) The server uses its own private key and the client's public key to calculate S = d TC P TS, the client calculates S = d using its own private key and the server's public key TS P TC , thus the two parties negotiate the session key S;

[0076] 4.2) In the multicast scenario, use the group key negotiation scheme based on the Chinese Remainder Theorem. The clients subscribing to a service obtain the group key factors generated by the server and calculate the common group key respectively;

[0077] The server selects the certificate private key d of the service it belongs to DS (d DS <q, where q is the order of the elliptic curve base point G), and the public key P DS = d DS G;

[0078] Before subscribing to the service, the client发起 an authentication handshake request to the server according to Step 2. The server issues a number sid to each client with a successful handshake i and stores sid i ;

[0079] The server selects a large prime number p, satisfying p is used to define the multiplicative group If the number of clients managed by the server is n, then the server selects n pairwise relatively prime positive integers from as the authentication keys {VAK i |i = 1, 2,... n} of each client, where i represents the i-th client managed by the server. The authentication keys are used to calculate the client group key, and all the authentication keys are greater than q (q is the threshold value of the group key); the server sends these authentication keys to these n clients respectively, and then the server performs the following calculation steps:

[0080] 4.2.1) Calculate

[0081] 4.2.2) For i = 1, 2,... n, calculate

[0082] 4.2.3) For i = 1, 2,... n, calculate y i , satisfying x i ×y i ≡ 1 mod VAK i

[0083] 4.2.4) For i = 1, 2,... n, store the results of x i and y i in the variable C i , that is, C i = x i ×y iThe server calculates the group key factor λ of the event group, i.e., λ = ∑C i ;

[0084] 4.2.5) Then the server selects a random number as the group key of the event group and calculates the message

[0085] m = k × λ

[0086] 4.2.6) The server broadcasts the message m to all clients in the event group. The clients belonging to the event group receive m. Since k < q < VAK i < p, and λ mod VAK i = 1, the client directly calculates m mod VAK i to obtain the group key k of the event group;

[0087] 4.3) Unicast key update: In the SOME / IP unicast scenario, if the session key expires, the session key is updated according to the unicast key negotiation process;

[0088] 4.4) Multicast key update: In the SOME / IP multicast scenario, if a subscribed group member leaves or joins, the multicast group key is immediately updated to ensure forward and backward security. At this time, the multicast key update process is triggered; when a new member S i joins the event group, S i sends a subscription request to the server to apply to join the event group. S i sends its certificate to the server. The server authenticates the client according to the process in step 2. After successful authentication, the authentication key is sent to S i , and the following steps are carried out:

[0089] 4.4.1) Recalculate according to step 4.2) to obtain a new group key factor λ';

[0090] 4.4.2) For this event group, select a new group key calculate the message

[0091] m' = k' × λ'

[0092] 4.4.3) The server multicasts k' through the UDP protocol. All members of this event group calculate: m' mod VAK i to obtain the new group key k';

[0093] When a member S j leaves the event group, the server finds the corresponding variable C j of this member calculated in step 4.2.4) in step 4.2), and calculates the new group key factor λ' = λ - C through step 4.4.1 jDelete the member's authentication key information. The subsequent steps are the same as steps 4.4.2) and 4.4.3) for adding a new member to the event group scenario.

[0094] An adaptive and secure vehicular communication method under a centralized vehicular domain architecture, based on the following assumptions:

[0095] (1) Each vehicle has a certificate distribution center set up in the central domain controller when it leaves the factory. The certificate is bound to the VIN code (Vehicle Identification Number) of each vehicle. It is only valid within the current vehicle and cannot be used for identity authentication processes in other vehicles' internal networks.

[0096] (2) Service safety risk assessment is subjective. It is necessary to obtain the basic safety score of each service based on the fuzzy comprehensive evaluation model when the vehicle leaves the factory. If the basic safety score needs to be modified, the score is reorganized and sent to each vehicle through OTA upgrade.

[0097] (3) The initialization of key parameters and certificates is performed each time the vehicle is powered on. The certificate distribution center will distribute a lightweight digital certificate for each SOME / IP service, which is only valid during the current vehicle power-on period.

[0098] (4) Considering that SOME / IP service subscriptions within the same domain controller do not need to be transmitted through the vehicle network, the adaptive vehicle security communication method under the centralized vehicle domain architecture is only applicable to SOME / IP service communication between different domain controllers.

[0099] A system based on the aforementioned centralized vehicular domain architecture for adaptive secure vehicular communication includes:

[0100] The system initialization module is used in step one to initialize certificate information and basic security scores for each SOME / IP service.

[0101] The identity authentication module is used in step two to verify the legitimacy of the SOME / IP service subscription client.

[0102] The risk assessment module is used in step three to perform a security risk assessment on the SOME / IP service subscription request, obtain a security score, and determine a security policy.

[0103] The key management module is used in step four to generate, distribute, and update session keys for both SOME / IP unicast and multicast communication scenarios.

[0104] The secure communication module is used in step five to encrypt SOME / IP communication messages to ensure message confidentiality and generate message authentication codes to ensure message integrity and freshness.

[0105] A device based on the aforementioned adaptive secure vehicular communication method under a centralized vehicular domain architecture includes:

[0106] Memory, used to store computer programs;

[0107] A processor is used to implement the adaptive secure vehicle communication method based on a centralized vehicle domain architecture as described in steps one to five when executing the computer program.

[0108] A computer-readable storage medium storing a computer program, which, when executed by a processor, enables in-vehicle network communication based on the adaptive secure in-vehicle communication method based on a centralized in-vehicle domain architecture as described in any one of steps one to five.

[0109] Compared with the prior art, the present invention has the following advantages:

[0110] This invention, based on the zero-trust model theory, utilizes fuzzy comprehensive evaluation and weighted average methods to assess security risks during service subscription. Simultaneously, it designs an adaptive security mechanism to reduce system overhead while ensuring communication security. Furthermore, a novel vehicular adaptive secure communication scheme is designed within the model. Based on symmetric cryptography and message authentication codes, differentiated security protection measures are implemented to safeguard the confidentiality, integrity, and non-repudiation of SOME / IP real-time communication messages. Key management methods are designed for various SOME / IP communication scenarios based on lightweight digital certificates, elliptic curve cryptography, and the Chinese Remainder Theorem. This method uses service instances in the SOME / IP communication process as the basic unit for security risk assessment, determines security defense mechanisms, and clarifies the management process for secure communication keys. It is compatible with domain-centralized architectures and various SOME / IP communication scenarios, ensuring forward and backward security of communication messages in different scenarios. At the same time, this method minimizes the additional overhead generated by security defense schemes, solving the problems of existing vehicular communication security mechanisms being limited in scope, having high communication overhead, coarse-grained protection, and difficulty in adapting to domain-centralized architecture communication scenarios.

[0111] As a core communication protocol in a domain-centralized architecture, SOME / IP requires a more robust security mechanism to ensure the security of vehicular network communication based on this architecture. This invention addresses the lack of a complete and efficient secure communication model and method in domain-centralized architecture communication scenarios, providing a reliable vehicular secure communication solution for such architectures. It proposes a security risk assessment and adaptive security mechanism orchestration scheme based on service instances in the SOME / IP communication process, and designs a secure communication key management method. While ensuring the confidentiality and integrity of communication messages, it guarantees forward and backward security for vehicular communication under a domain-centralized architecture, while minimizing the additional overhead of the security mechanism. Attached Figure Description

[0112] Figure 1 This invention presents a vehicle-mounted safety communication model based on a domain-centralized architecture and the SOME / IP communication protocol.

[0113] Figure 2 This invention presents an adaptive secure communication method for the SOME / IP protocol.

[0114] Figure 3 This is a system flowchart of the adaptive vehicle-mounted safety communication model of the present invention.

[0115] Figure 4 This relates to the efficiency of SOME / IP service subscription authentication handshake under concurrent requests in this embodiment of the invention.

[0116] Figure 5 This refers to the SOME / IP unicast key negotiation efficiency under different ECC key lengths in the embodiments of the present invention.

[0117] Figure 6 This refers to the SOME / IP multicast key negotiation efficiency under different subscription scales in the embodiments of the present invention.

[0118] Figure 7 This refers to the SOME / IP unicast communication efficiency under different security levels in the embodiments of the present invention.

[0119] Figure 8 This refers to the SOME / IP multicast communication efficiency under different security levels in the embodiments of the present invention. Detailed Implementation

[0120] The present invention will now be described in further detail with reference to the accompanying drawings.

[0121] Related theories and technologies

[0122] This invention proposes an adaptive in-vehicle secure communication model based on a domain-centralized architecture. This model utilizes a fuzzy comprehensive evaluation algorithm and the zero-trust model concept to assess the security risks of the SOME / IP service call process; it employs lightweight digital certificates, message authentication codes, elliptic curve-based key exchange technology, and group key exchange technology based on the Chinese Remainder Theorem to implement key management and security protection for SOME / IP protocol communication. Therefore, we first elaborate on the fuzzy comprehensive evaluation method, zero-trust model theory, elliptic curve-based Diffie-Hellman key exchange algorithm, digital certificate technology, message authentication code technology, and the Chinese Remainder Theorem framework related to this invention.

[0123] 1. Fuzzy Comprehensive Evaluation Method

[0124] Fuzzy comprehensive evaluation is a comprehensive evaluation method based on fuzzy mathematics. This method transforms qualitative evaluation into quantitative evaluation based on the membership theory of fuzzy mathematics, that is, it uses fuzzy mathematics to make an overall evaluation of things or objects constrained by multiple factors. It features clear results and strong systematicity, and can effectively solve fuzzy and difficult-to-quantify problems, making it suitable for solving various uncertain problems.

[0125] The evaluation of multi-factor problems involves a multitude of factors with varying degrees of importance, making the problems highly complex and difficult to decide, thus hindering the application of conventional classical mathematical methods to solve comprehensive evaluation problems. Fuzzy mathematics, however, provides a theoretical basis for solving fuzzy comprehensive evaluation problems, thereby offering a simple and effective evaluation and decision-making method.

[0126] (1) Establish a set of factors for comprehensive evaluation

[0127] The factor set is a general set composed of various factors that affect the evaluation object, usually denoted by U, where U = {u1, u2, ..., u...}. n}, where element u i This represents the i-th factor influencing the evaluation object. These factors typically have varying degrees of ambiguity.

[0128] (2) Establish an evaluation set for comprehensive evaluation

[0129] An evaluation set is a collection of all possible outcomes that an evaluator might make regarding an evaluated object. It is usually denoted by V, where V = {v1, v2, ..., v...} n}, where element v j The j-th evaluation result can be represented by different levels, comments, or numbers, depending on the actual needs.

[0130] (3) Determine the weight of each factor

[0131] In the evaluation process, the importance of each factor varies, therefore, each factor is assigned a value (u). i Assign a weight a i This can be represented as A = {a1, a2, ..., a...} n When there is no data, the weights can be determined using the analytic hierarchy process (AHP); when there is data, the weights can be determined using the entropy weighting method.

[0132] (4) Perform single-factor fuzzy evaluation to obtain the evaluation matrix.

[0133] If the membership degree of the i-th element in factor set U to the 1-th element in evaluation set V is r i1 Then, the result of the single-factor evaluation of the i-th element is represented by a fuzzy set as follows:

[0134] R i ={r i1 ,r i2 ,…,r im}

[0135] With m single-factor evaluation sets R1, R2, ..., R m The rows form a matrix R n×m This is called the fuzzy comprehensive evaluation matrix.

[0136]

[0137] (5) Comprehensive evaluation

[0138] For weight A, calculate And make a judgment based on the principle of maximizing membership degree, among which These are fuzzy operator symbols. Different operator symbols correspond to different fuzzy comprehensive evaluation models. Commonly used operator symbols include the Zadeh operator, weighted average operator, ring product operator, bounded operator, maximum product operator, and bounded minimum product operator. (Based on the operation...) Different definitions of can lead to the following different models:

[0139] Model 1: M(∧,∨) Principal Factor Determining Type

[0140] b j =max{(a i ∧r ij ),1≤i≤n}(j=1,2,…,m)

[0141] Model 2: M(·,∨) Principal Factor Emphasis Type

[0142] b j =max{(a i ·r ij ),1≤i≤n}(j=1,2,…,m)

[0143] Model 3: M(·,+) weighted average

[0144]

[0145] Model 4: Take the smaller upper bound and type

[0146]

[0147] (6) Calculate the score and analyze the results

[0148] For the obtained fuzzy evaluation vector B, if the evaluation set provides a corresponding score, then a weighted average is applied; otherwise, the maximum membership principle is followed.

[0149] (a) Maximum membership principle M = max(S1,S2,…S m )

[0150] (b) Weighted average principle

[0151] 2. Zero Trust Model Theory

[0152] Zero Trust is a new type of network security architecture based on the principles of continuous authentication and authorization, no longer assuming that internal users, devices, or networks are trustworthy. In Zero Trust, all user, device, and network traffic requires authentication and authorization; access to resources is only granted after successful authentication. This model helps prevent malicious users or intruders from gaining unauthorized access to the network.

[0153] The zero-trust model has the following characteristics: (1) Authentication and access control: Authentication is performed on all users and devices to ensure that only authorized entities can access sensitive data and resources. Passwords, biometrics, and other factors can be used to improve the security of authentication. (2) Principle of least privilege: Based on the principle of least privilege, the minimum necessary privileges are assigned to each user and device to limit their access scope, thereby reducing the potential attack surface. (3) Internal and external network isolation: The network is divided into multiple security zones, and access control policies are established between these zones to ensure that only verified entities can access across zones. (4) Session monitoring and analysis: Real-time monitoring of user and device behavior and timely detection of abnormal activities, such as abnormal access patterns and large-scale data downloads. (5) Encryption and data protection: End-to-end data encryption mechanisms are adopted to ensure that data is not easily stolen or tampered with during transmission and storage. In addition, data classification and labeling technologies are used reasonably to classify and process data, and different access control policies are set for data with different sensitivity levels.

[0154] 3. Elliptic Curve-Based Diffie-Hellman Key Exchange (ECDH)

[0155] ECDH is a key-agreement algorithm that allows two communicating parties to exchange shared parameters over an insecure channel, thereby calculating a session key using the shared parameters and their own private parameters. This algorithm is based on Elliptic Curve Cryptography (ECC), a public-key cryptography algorithm based on elliptic curve mathematics. Its security relies on the difficulty of the elliptic curve discrete logarithm problem. ECC can provide the same level of security as the RSA algorithm using a shorter key length.

[0156] The ECDH key negotiation process is as follows:

[0157] ① Both communicating parties choose a common elliptic curve equation, a large prime number P, and a generator G;

[0158] ② Both parties in the communication generate their own private and public keys. The private and public keys of party A are d and d respectively. A and H A =d A G, and the private and public keys of the communicating party B are d respectively. B and H B =d B G

[0159] It is important to note that communication parties A and B use the same domain parameters: the same reference point G on the same elliptic curve defined within the same finite domain.

[0160] ③ Communicator A and Communicator B exchange their public key H through an insecure channel. A and H B Third parties may intercept H A and H B However, it is not possible to derive the private key d simply by using the public key to bypass the discrete logarithm problem. A and d B .

[0161] ④ Communicator A uses its private key and communicator B's public key to calculate S = d A H B Then, communication party B also uses its private key and communication party A's public key to calculate S = d. B H A In fact, for both communication party A and communication party B, this S is the same:

[0162] S = d A H B =d A (d B G)=d B (dA G)=d B H A

[0163] The middleman who intercepts the information only knows H A and H B And other domain parameters, but still cannot obtain the secret information S shared between communicator A and communicator B.

[0164] 4. Digital Certificate Technology

[0165] A digital certificate is a string of numbers that identifies the parties involved in internet communication, containing the applicant's identity information (such as name, ID number, etc.) and a unique key. Digital certificates are digitally signed by a Certificate Authority (CA) to ensure their authenticity and prevent tampering or forgery. Issued by CAs, they provide a way to verify the identity of communicating entities online. Digital certificates operate on the principle of public-key cryptography, which, simply put, uses a "private key signing, public key verification" rule to perform signature and verification operations, ensuring the integrity of electronic documents. Public-key cryptography gives digital certificates uniqueness and privacy, enabling them to function as network identity verification and communication encryption tools. Digital certificate services are commonly referred to in the industry as "security authentication." The "security authentication" provided by digital certificates is a technical means to ensure the security of online transactions, guaranteeing the authenticity of the transacting parties' identities, the confidentiality and authenticity of electronic agreements, the non-repudiation of operational actions, and the legal validity of electronic contracts, but it is completely unrelated to the content of the transaction.

[0166] 5. Message Authentication Code Technology

[0167] A Message Authentication Code (MAC) is an algorithm used to verify the integrity and authenticity of a message. It generates a fixed-length code, called the MAC, by taking the message and a key as input, to guarantee the message's integrity and authenticity. MAC algorithms typically use symmetric cryptographic algorithms, such as DES and AES, and can be considered a one-way hash function associated with a key. MAC algorithms are widely used in network communication to protect data security and reliability. In network communication, MAC can prevent data tampering or impersonation, ensuring data integrity and authenticity.

[0168] 6. Chinese Remainder Theorem

[0169] The Chinese Remainder Theorem, also known as Sunzi's Theorem, is an ancient Chinese method for solving systems of linear congruences. It is of great significance to modern cryptography, and many encryption technologies use the Chinese Remainder Theorem and modular arithmetic operations to construct encryption schemes.

[0170] The definition of the Chinese Remainder Theorem is as follows:

[0171] Theorem 1 (Chinese Remainder Theorem): Let integers m1, m2, ..., m n Pairwise coprime, and Then for any j (1≤j≤n), the following linear congruence x≡α i mod m i There is a unique model The solution is:

[0172]

[0173] in β i γ i ≡1mod m i .

[0174] Based on this theorem, a multicast key negotiation algorithm for SOME / IP service subscription can be designed by combining elliptic curves.

[0175] Embodiments of the present invention

[0176] An adaptive secure vehicular communication model under a centralized domain architecture is proposed. Based on zero-trust model theory, it utilizes fuzzy comprehensive evaluation and weighted average methods to assess security risks during service subscription. Simultaneously, an adaptive security mechanism is designed to reduce system overhead while ensuring communication security. Furthermore, a novel adaptive secure vehicular communication scheme is designed within the model, employing symmetric cryptography and message authentication codes to implement differentiated security protection measures, safeguarding the confidentiality, integrity, and non-repudiation of SOME / IP real-time communication messages. Based on lightweight digital certificates, elliptic curve cryptography, and the Chinese Remainder Theorem, a key management method is designed for various SOME / IP communication scenarios. This method uses service instances in the SOME / IP communication process as the basic unit for security risk assessment, determines security defense mechanisms, and clarifies the management process for secure communication keys. It is compatible with both centralized domain architectures and various SOME / IP communication scenarios, ensuring forward and backward security of communication messages in different scenarios. Simultaneously, this method minimizes the additional overhead generated by security defense schemes, addressing the problems of existing vehicular communication security mechanisms being limited in scope, having high communication overhead, coarse-grained protection, and difficulty in adapting to centralized domain architecture communication scenarios.

[0177] An adaptive and secure vehicular communication method under a centralized vehicular domain architecture, based on the following assumptions:

[0178] (1) Each vehicle has a certificate distribution center (similar in function to a CA) set up in the central domain controller when it leaves the factory. The certificate is bound to the VIN code (Vehicle Identification Number) of each vehicle. It is only valid within the current vehicle and cannot be used for identity authentication processes in other vehicles' internal networks.

[0179] (2) Service safety risk assessment is subjective. It is necessary to obtain the basic safety score of each service based on the fuzzy comprehensive evaluation model when the vehicle leaves the factory. If the basic safety score needs to be modified, the score is reorganized and sent to each vehicle through OTA upgrade.

[0180] (3) The initialization of key parameters and certificates is performed each time the vehicle is powered on. The certificate distribution center will distribute a lightweight digital certificate for each SOME / IP service, which is only valid during the current vehicle power-on period.

[0181] (4) Considering that SOME / IP service subscriptions within the same domain controller do not need to be transmitted through the vehicle network, the adaptive vehicle security communication model proposed in this invention is only applicable to SOME / IP service communication between different domain controllers.

[0182] An adaptive and secure in-vehicle communication method under a centralized vehicular domain architecture, see [link to relevant documentation]. Figure 3 The specific steps are as follows:

[0183] Step 1: System Initialization

[0184] System initialization is divided into two parts: service basic security scoring and key parameter and certificate initialization.

[0185] I. Service Basic Security Score

[0186] Each SOME / IP service in the system should obtain a corresponding basic security score based on the fuzzy comprehensive evaluation method during the system development and design phase; the calculation process for the basic security score is as follows:

[0187] 1) Determining the Factor Set: Treating SOME / IP services as an information asset within the vehicle, and based on the asset identification method specified in the national standard GB / 20984-2022 "Information Security Technology - Information Security Risk Assessment Method," this method mainly includes four parts: business identification, system asset identification, threat identification, and vulnerability identification. When calculating the basic security score, the factor set considered must include at least the influencing factors from the above four aspects; the basic scoring factor set determined based on this is denoted as U. b ={u b1 ,ub2 ,…,u bn};

[0188] 2) Determine the comment set: V = {v1, v2, ..., v} m}; where v i The i-th evaluation result can be represented by different levels, comments, or numbers;

[0189] 3) Determine the weight set: A = {a1, a2, ..., a n When there is no reference data, the weights are determined by analyzing the factor set using the analytic hierarchy process (AHP); when there is reference data, the weights are determined using the entropy weight method.

[0190] 4) Implementation Evaluation: Experts were invited to conduct a comprehensive evaluation of the factors in the factor set based on relevant regulations on automotive information security. The evaluation results were derived from the comment set V.

[0191] 5) Establish an evaluation matrix: The membership degree represents the proportion of experts selecting a specific evaluation result from the comment set V for a given influencing factor in factor set U; if the membership degree of the i-th element in factor set U to the 1-th element in evaluation set V is r... i1 Then, the result of the single-factor evaluation of the i-th element is represented by a fuzzy set as follows:

[0192] R i ={r i1 ,r i2 ,…,r im}

[0193] 6) Using m single-factor evaluation sets R1, R2, ..., R m The rows form a matrix R n×m This constitutes the fuzzy comprehensive evaluation matrix:

[0194]

[0195] 7) Comprehensive evaluation

[0196] For weight m, the fuzzy evaluation vector B is calculated using a weighted average fuzzy operator:

[0197]

[0198]

[0199] The evaluation is based on the principle of maximizing membership degree, among which... These are fuzzy operator symbols; different operator symbols correspond to different fuzzy comprehensive evaluation models.

[0200] 8) Calculate the score and obtain the result.

[0201] For the obtained fuzzy evaluation vector B, calculate the basic safety score s base :

[0202]

[0203] where μ(v i ) is the grade score assigned to each evaluation factor in the evaluation set, which is determined by the evaluator himself; s base are all real numbers in the range of 0 to 4, which are sent to the vehicle by the vehicle enterprise cloud platform through the vehicle OTA upgrade path and pre-stored in each domain controller;

[0204] II. Key Parameters and Certificate Initialization

[0205] The central domain controller determines three key parameters: elliptic curve E p (a, b), base point G, and the order q of the base point, and generates lightweight digital certificates for each SOME / IP service in all domain controllers. Then, the central domain controller sends the elliptic curve E p (a, b), base point G, order q of the base point, key parameters, and the generated certificates to all domain controllers;

[0206] The specific method of the SOME / IP service subscription authentication handshake in step 2 is as follows:

[0207] When a certain client subscribes to the SOME / IP service from the server, it will send the certificate of its affiliated SOME / IP service to the server for authentication. After receiving the certificate, the server verifies the identity legality of the client; the authentication process is as follows:

[0208] 2.1) Client Signature

[0209] ① The client selects the private key d of the certificate of its affiliated SOME / IP service DC (d DC <q, q is the order of this G), and public key P DC = d DC G;

[0210] ② The client selects a random integer k (k < q), calculates the point Q = kG = (x1, y1), and sets r = x1;

[0211] ③ The client calculates z = H(m), where m is the authentication message and H(·) is the hash function;

[0212] ④ The client calculates s = k -1 (z + rd DC )(mod q), and obtains the signature (r, s). If either r or s is 0, reselect the random number k and repeat ④;

[0213] ⑤ The client sends the authentication message m containing certificate information and the signature (r,s) to the server;

[0214] 2.2) Server-side signature verification

[0215] 2.2.1) After receiving the information from the client, the server calculates z = H(m) and u1 = zs. -1 mod q,u2=rs -1 mod q;

[0216] 2.2.2) Server-side calculation point (x1, y1) = u1G + u2P DC ;

[0217] 2.2.3) The server verifies whether the equation r≡x1mod q is true. If it is true, the authentication is successful; otherwise, the authentication fails.

[0218] The specific method for step three, security risk assessment and security strategy determination, is as follows:

[0219] After step two is successful, the SOME / IP server and client establish a secure communication channel, and proceed to the security risk assessment and security policy determination stage. The specific process is as follows:

[0220] 3.1) The server-side determines the real-time factor set based on the national mandatory standard "Technical Requirements for Information Security of Automobile Whole Vehicles" drafted by the Ministry of Industry and Information Technology, which specifies the selection of client source, current number of service subscription requests, type of SOME / IP interface for subscription requests, and communication traffic of the service port as the real-time factor set. All factors in the factor set can be quantified as data; denoted as:

[0221] U r ={u r1 ,u r2 ,u r3 ,u r4}

[0222] Then, the server uses a weighted average method to perform real-time security scoring on the client making the current request. Assuming there are n clients in the request queue, the formula is as follows:

[0223]

[0224] in This indicates that the i-th real-time factor data is normalized to a real number in the interval [0,4]; j represents the j-th client in the request queue, x, x max x min These represent the current value, the maximum possible value, and the minimum possible value of the real-time factor data, respectively. i Indicates the weight of different real-time factors; the weights are defined by the automaker.

[0225] Finally, the server will assign its basic security score of S. base和 The final security score s is obtained by weighting the real-time security scores of all requesting clients according to the following formula. t :

[0226]

[0227] In the formula, m represents the number of client members requesting to subscribe to the service, and s rj Let m represent the real-time security score of the j-th client member, where m is always equal to 1 in a unicast scenario;

[0228] 3.2) The server bases its authentication handshake result and security score on step two. t Based on the adaptive security defense mechanism arrangement scheme listed in Table 1, corresponding security defense measures are adopted; the security risk level is divided into four levels: no risk, low risk, medium risk, and high risk, which correspond to the risk score obtained from the security risk assessment; the higher the security risk level, the higher the security strength of the cryptographic algorithm used.

[0229] 3.3) Both communicating parties will take corresponding security measures to ensure the secure transmission of service data based on the type of service interface subscribed and the results of the security risk assessment;

[0230] Table 1 Adaptive Security Defense Mechanism Orchestration Scheme

[0231]

[0232] Note: Step four is not performed when the risk level is no risk.

[0233] The specific method for session key management in step four is as follows:

[0234] Session key management is divided into two parts: key negotiation and key update. Key negotiation is further divided into two scenarios: unicast key negotiation and multicast key negotiation. The Getter and Setter methods in the Method and Field interfaces of the SOME / IP service use request-response or request-no-response unicast communication. The Notifier method in the Event and Field interfaces is triggered by a specific event. After the event is triggered, the server sends the corresponding message to all clients that have subscribed to the event, using multicast communication. Table 2 shows the communication methods of different SOME / IP communication interfaces and the key management schemes that should be adopted.

[0235] 4.1) Unicast Key Negotiation: In unicast scenarios, session key negotiation is performed directly based on the ECDH key exchange protocol.

[0236] 4.1.1) The two communication parties determine their respective certificate key pairs. The server uses its own certificate private key to be confused with a large random integer to obtain the negotiated public and private key d TS and P TS = d TS G. The client uses its own certificate private key to be confused with a large random integer to obtain the negotiated public and private key d TC and P TC = d TC G; The two communication parties use their respective certificate private keys to sign P TS , P TC to prevent man-in-the-middle attacks;

[0237] 4.1.2) The server and the client exchange P TS and P TC .

[0238] Table 2 Key Management Schemes for Different SOME / IP Communication Interfaces

[0239]

[0240] 4.1.3) The server uses its own private key and the client's public key to calculate S = d TC P TS , and the client uses its own private key and the server's public key to calculate S = d TS P TC , and thus the two parties negotiate the session key S;

[0241] 4.2) In the multicast scenario, a group key negotiation scheme based on the Chinese Remainder Theorem is used. The clients subscribing to a certain service obtain the group key factors generated by the server and calculate the common group key respectively;

[0242] The server selects the certificate private key d DS (d DS <q, where q is the order of the elliptic curve base point G), and the public key P DS = d DS G;

[0243] Before subscribing to the service, the client发起 an authentication handshake request to the server according to Step 2. The server issues a number sid i to each client with a successful handshake and stores sid i ;

[0244] The server selects a large prime number p that satisfies p is used to define the multiplicative group If the number of clients managed by the server is n, then the server selects n pairwise relatively prime positive integers from as the authentication keys {VAKi |i = 1, 2, …, n}, where i represents the i-th client managed by the server. The authentication keys are used to calculate the client group key, and all authentication keys are greater than q (q is the threshold value of the group key); the server sends these authentication keys to the n clients respectively, and then the server performs the following calculation steps:

[0245] 4.2.1) Calculate

[0246] 4.2.2) For i = 1, 2, …, n, calculate

[0247] 4.2.3) For i = 1, 2, …, n, calculate y i , satisfying x i ×y i ≡ 1 mod VAK i

[0248] 4.2.4) For i = 1, 2, …, n, store the results of x i and y i in the variable C i i.e., C i = x i ×y i

[0249] The server calculates the group key factor λ, i.e., λ = ∑C i ;

[0250] 4.2.5) Then the server selects a random number as the group key of the event group and calculates the message

[0251] m = k × λ

[0252] 4.2.6) The server broadcasts the message m to all clients in the event group. The clients belonging to the event group receive m. Since k < q < VAK i < p, and λ mod VAK i = 1, the clients directly calculate m mod VAK i to obtain the group key k of the event group;

[0253] 4.3) Unicast key update: In the SOME / IP unicast scenario, if the session key expires, the session key is updated according to the unicast key negotiation process;

[0254] 4.4) Multicast key update: In the SOME / IP multicast scenario, if a subscribed group member leaves or joins, the multicast group key is immediately updated to ensure forward and backward security, and at this time, the multicast key update process is triggered;

[0255] When the new member Si Join the event group, S i S sends a subscription request to the server to join the event group. i The client sends its certificate to the server. The server then authenticates the client according to the process in step two. After successful authentication, the server sends the authentication key to S. i And perform the following steps:

[0256] 4.4.1) Recalculate according to step 4.2) to obtain the new group key factor λ';

[0257] 4.4.2) For this event group, select a new group key. Compute message

[0258] m'=k'×λ'

[0259] 4.4.3) The server multicasts k' via UDP, and all members of the event group calculate: m'mod VAK i The new group key k' can then be obtained;

[0260] When group member S j After leaving the event group, the server finds the variable C corresponding to that member calculated in step 4.2.4) of step 4.2). j And calculate the new group key factor λ' = λ - C through step 4.4.1). j Delete the member's authentication key information. The subsequent steps are the same as steps 4.4.2) and 4.4.3) for adding a new member to the event group scenario.

[0261] Step 5: SOME / IP Secure Communication

[0262] After the above steps are completed, the SOME / IP server and client initiate SOME / IP communication according to the agreed-upon security defense strategy. If encrypted communication is required, both parties use a negotiated session key for encrypted communication. Figure 3 The process in step ⑤ indicates the data flow direction for that step.

[0263] Experimental verification effect

[0264] In this section, we verified the effectiveness of the proposed solution through a series of experiments. Compared with in-vehicle network security solutions that directly use the Ethernet application layer SSL security protocol, the security model proposed in this invention can provide more granular protection for the SOME / IP communication protocol, better compatibility with the centralized architecture of the in-vehicle domain, and reduce communication overhead. Compared with existing adaptive security solutions for the SOME / IP protocol, this invention improves the service security risk assessment mechanism and the key management mechanism for different communication scenarios of the SOME / IP protocol, providing a more granular security protection solution.

[0265] Experimental environment: The processor was an Apple M1 with 8GB of onboard RAM, and the operating system was an Ubuntu 22.04 virtual machine environment. The programming language was C++, the framework used was vsomeip, and the compilation environment was g++.

[0266] The experimental system framework includes a central domain controller and two functional domain controllers, each with several SOME / IP services.

[0267] The experimental results are as follows:

[0268] Because the native SOME / IP protocol has a concurrent request handling mechanism, it can maintain good performance and response speed when handling a large number of concurrent requests. Figure 4 This study demonstrates the performance difference between native SOME / IP protocol service subscription and SOME / IP service subscription authentication handshake under different numbers of concurrent client requests. Experimental results show that when the number of concurrent client requests reaches 70, the performance difference between the two handshake schemes is approximately 30ms, indicating that the addition of service subscription authentication handshake functionality to the SOME / IP protocol introduces some additional overhead. Since the number of concurrent service subscription requests in each vehicle typically does not exceed 100, and this order of magnitude represents normal communication latency in Ethernet communication, this additional overhead will not affect the real-time performance of in-vehicle communication.

[0269] Figure 5 This paper presents a comparison of the SOME / IP unicast key negotiation efficiency between the proposed scheme and a comparative scheme, under key lengths with similar security performance. The proposed scheme employs an ECDH key negotiation scheme based on the ECC mechanism; the comparative scheme employs an RSA key negotiation scheme based on the SSL protocol. Figure 5 The x-axis of the two schemes was aligned based on the premise of approximate security performance. ECC key lengths of 128, 192, 256, 320, and 384 bits correspond to RSA keys of 1024, 1536, 2048, 2560, and 3072 bits, respectively. Experimental results show that the ECC key negotiation time used in this invention is stable at around 10ms, significantly better than the 30–70ms of the comparative schemes, meeting the high real-time requirements of vehicular networks.

[0270] Figure 6This study demonstrates the efficiency of SOME / IP multicast key negotiation under different subscription sizes. Considering that client subscription requests do not arrive simultaneously in real-world SOME / IP communication scenarios, the experiment batch-processes multicast subscription requests to generate multicast session keys at regular intervals of 1 second. It can be seen that the number of clients in the subscription group is positively correlated with the multicast key negotiation time. When the number of clients in the subscription group is 30, the average negotiation time is approximately 100ms; when the number of clients in the subscription group is 100, the average negotiation time is approximately 250ms. Due to the randomness of finding pairwise coprime authentication keys, the experimental results exhibit some fluctuation, but overall, they follow a linear increasing trend.

[0271] Figure 7 and Figure 8 This study demonstrates the communication efficiency of SOME / IP unicast and multicast transmissions under different security levels. Unicast communication uses the TCP protocol, while multicast communication uses the UDP protocol. The main differences between the different security levels lie in the lengths of the session key and message authentication code. Experimental results show that the communication duration difference between different security levels is less than 0.05ms for both unicast and multicast communication; in other words, the additional communication overhead from the adaptive security scheme is minimal. Furthermore, due to the immediate transmission characteristic of the UDP protocol, multicast communication outperforms unicast communication.

Claims

1. An adaptive and secure in-vehicle communication method under a centralized in-vehicle domain architecture, characterized in that: The specific steps are as follows: Step 1: System initialization, including two parts: service basic security scoring and initialization of key parameters and certificates: I. Service basic security scoring Each SOME / IP service in the system should obtain the corresponding basic security score according to the fuzzy comprehensive evaluation method during the system development and design stage; the calculation process of the basic security score is as follows: 1) Determining the Factor Set: Treating SOME / IP services as an information asset within the vehicle, and based on the asset identification method specified in the national standard GB / 20984-2022 "Information Security Technology - Information Security Risk Assessment Method," this method mainly includes four parts: business identification, system asset identification, threat identification, and vulnerability identification. When calculating the basic security score, the factor set considered must include at least the influencing factors from these four parts. The basic scoring factor set determined based on this is denoted as U. b ={u b1 ,u b2 ,…,u bn }, where n represents the quantity; 2) Determine the comment set: V = {v1, v2, ..., v} m }; where v i Let m represent the i-th evaluation result, expressed in different grades, comments, or numbers, where m represents the quantity. 3) Determine the weight set: A = {a1, a2, ..., a n When there is no reference data, the weights are determined by analyzing the factor set using the analytic hierarchy process (AHP); when there is reference data, the weights are determined using the entropy weight method. 4) Implement evaluation: Invite experts to conduct a comprehensive evaluation of the factors in the factor set according to the relevant regulations on automotive information security, and the type of evaluation result comes from the comment set V; 5) Establish an evaluation matrix: using membership degrees to represent the evaluation of factor set U. b For a certain influencing factor, select the percentage of experts for a certain evaluation result in the comment set V; If the factor set U b The membership degree of the i-th element in the evaluation set V to the 1-th element is r. i1 Then, the result of the single-factor evaluation of the i-th element is represented by a fuzzy set as follows: R i ＝{r i1 ,r i2 ,…,r im} 6) Using m single-factor evaluation sets R1, R2, ..., R... m The rows form a matrix R n×m This constitutes the fuzzy comprehensive evaluation matrix: 7) Comprehensive judgment For the weight A, use the weighted average type fuzzy operator to calculate the fuzzy evaluation vector B: Make a judgment according to the principle of the largest membership degree, where ° is the symbol of the fuzzy operator, and different operator symbols correspond to different fuzzy comprehensive evaluation models; 8) Calculate the score and obtain the result For the obtained fuzzy evaluation vector B, the basic safety score s is calculated. base : Where, μ(v) i The rating for each evaluation factor in the comment set is determined by the evaluator; base All are real numbers in the range of 0 to 4, which are sent to the vehicle by the car manufacturer's cloud platform through the car OTA upgrade and are pre-stored in each domain controller; II. Initialization of key parameters and certificates The central domain controller determines three key parameters: Elliptic Curve E p (a,b), base point G and the order q of the base point, and generate a lightweight digital certificate for each SOME / IP service in all domain controllers. Then, the central domain controller will use the elliptic curve E p (a, b), the base point G and the order q of the base point, the key parameters, and the generated certificate are distributed to all domain controllers. Step 2: SOME / IP service subscription authentication handshake: When a certain client subscribes to a SOME / IP service from the server, it will send the certificate of its affiliated SOME / IP service to the server for authentication, and the server will verify the identity legality of the client after receiving the certificate; Step 3: Security risk assessment and security policy determination: After passing Step 2, a secure communication channel is established between the SOME / IP server and the client, and it enters the security risk assessment and security policy determination link; Step 4: Session key management; after determining the security policy in Step 3, when encrypted communication is required, session key management needs to be carried out; session key management is divided into two parts: key negotiation and key update, and key negotiation is divided into two scenarios: unicast key negotiation and multicast key negotiation; the Getter and Setter methods in the Method interface and Field interface of the SOME / IP service interface use unicast communication of request-response or request-no response; the Notifier method in the Event interface and Field interface is triggered under specific events, and after triggering, the server will send the corresponding message to all clients subscribing to this event, using multicast communication; Step 5: SOME / IP secure communication; after Steps 1 to 4 are all completed, the SOME / IP server and the client start SOME / IP communication according to the determined security defense policy; if encrypted communication is required, the communication parties use the negotiated session key for encrypted communication.

2. The adaptive secure vehicle-mounted communication method under the vehicle-mounted domain centralized architecture according to claim 1, wherein: the specific method of the SOME / IP service subscription authentication handshake in Step 2 is: When a certain client subscribes to a SOME / IP service from the server, it will send the certificate of its affiliated SOME / IP service to the server for authentication, and the server will verify the identity legality of the client after receiving the certificate; the authentication process is as follows: 2.1) Client signature ①The client selects the certificate private key d of the SOME / IP service it belongs to DC , d DC <q, where q is the order of the base point G, and the public key P DC = d DC G; ② The client selects a random integer k (k < q), calculates the point Q = kG = (x1, y1), and sets r = x1; ③ The client calculates z = H(m), where m is the authentication message and H(·) is the hash function; ④ Client-side calculation of s = k -1 (z+rd DC (mod q), to obtain the signature (r, s). If either r or s is 0, then select a random number k again and repeat ④. ⑤ The client sends the authentication message m containing certificate information and the signature (r,s) to the server; 2.2) Server-side signature verification 2.2.1) After receiving the information from the client, the server calculates z = H(m) and u1 = zs. -1 mod q,u2=rs -1 mod q; 2.2.2) Server-side calculation point (x1, y1) = u1G + u2P DC ; 2.2.3) The server verifies whether the equation r≡x1mod q is true. If it is true, the authentication is successful; otherwise, the authentication fails.

3. The adaptive secure vehicle communication method under a centralized vehicle domain architecture according to claim 1, characterized in that: The specific method for step three, security risk assessment and security strategy determination, is as follows: After step two is successful, the SOME / IP server and client establish a secure communication channel, and proceed to the security risk assessment and security policy determination stage. The specific process is as follows: 3.1) The server determines the real-time factor set. According to the national mandatory standard "Technical Requirements for Information Security of Automobile Whole Vehicles" drafted by the Ministry of Industry and Information Technology, the following factors are selected as the real-time factor set: client source, number of current service subscription requests, type of SOME / IP interface for subscription, and communication traffic of service port. All factors in the factor set can be quantified into data. Recorded as: IN r ={in r1 ,in r2 ,in r3 ,in r4 } Then, the server uses a weighted average method to perform real-time security scoring on the client making the current request. Assuming there are n clients in the request queue, the formula is as follows: in, This indicates that the i-th real-time factor data is normalized to a real number in the interval [0,4]; j represents the j-th client in the request queue, x, x max x min These represent the current value, the maximum possible value, and the minimum possible value of the real-time factor data, respectively. i Indicates the weight of different real-time factors; the weights are defined by the automaker. Finally, the server will assign its basic security score s base The final security score s is obtained by weighting the real-time security scores of all requesting clients according to the following formula. t : In the formula, m represents the number of client members requesting to subscribe to the service, and s rj Let m represent the real-time security score of the j-th client member, where m is always equal to 1 in a unicast scenario; 3.2) The server bases its authentication handshake result and security score on step two. t Based on the adaptive security defense mechanism arrangement scheme, corresponding security defense measures are adopted; the security risk level is divided into four levels: no risk, low risk, medium risk, and high risk, which correspond to the risk score obtained from the security risk assessment; the higher the security risk level, the higher the security strength of the cryptographic algorithm used. 3.3) Both communicating parties will take corresponding security measures to ensure the secure transmission of service data based on the type of service interface subscribed and the results of the security risk assessment; The adaptive security defense mechanism orchestration scheme is as follows: Safety rating S t ≤1,1 t ≤2,2 t ≤3,3 t ≤4; corresponding to risk levels of no risk, low risk, medium risk, and high risk respectively; the corresponding security defense measures adopted are plaintext, 128-bit symmetric encryption, 128-bit symmetric encryption + message authentication code, and 256-bit symmetric encryption + message authentication code respectively; when the risk level is no risk, step four is not executed.​​​ 4. The adaptive secure vehicle communication method under a centralized vehicle domain architecture according to claim 1, characterized in that: The specific method for session key management in step four is as follows: Session key management is divided into two parts: key negotiation and key update. Key negotiation is further divided into unicast key negotiation and multicast key negotiation scenarios. The Getter and Setter methods in the Method and Field interfaces of the SOME / IP service interface use request-response or request-no-response unicast communication. The Notifier method in the Event and Field interfaces is triggered by a specific event. After the event is triggered, the server sends the corresponding message to all clients subscribed to the event, using multicast communication. The communication methods and key management schemes for different SOME / IP communication interfaces are as follows: ① For the Method interface The communication method for the Field-Getter interface is unicast, with request-response or no response; the key management scheme uses unicast key management. For the Field-Setter interface, the communication method is unicast, with request-response or no response; the key management scheme uses unicast key management. For the Field-Notifier interface, the communication method is multicast, with event-triggered communication; the key management scheme uses multicast key management. 4.1) Unicast Key Negotiation: In unicast scenarios, session key negotiation is performed directly based on the ECDH key exchange protocol. 4.1.1) Both communicating parties determine their respective certificate key pairs. Both server parties then use their own private key, mixed with a random large integer, to obtain the negotiated public / private key d. TS and P TS =d TS G, the private and public keys of the certificate of the service to which the client belongs are d. TC and P TC =d TC G; Both communicating parties use their respective certificate private keys to P TS P TC Signatures are used to prevent man-in-the-middle attacks. 4.1.2) The server and client exchange P via an insecure in-vehicle communication channel. TS and P TC ; 4.1.3) The server uses its own private key and the client's public key to calculate S = d TC P TS The client uses its own private key and the server's public key to calculate S = d. TS P TC At this point, both parties agreed on the session key S; 4.2) In multicast scenarios, a group key negotiation scheme based on the Chinese Remainder Theorem is used. Clients subscribing to a service obtain the group key factor generated by the server and each calculates the common group key. The server selects the certificate private key d of its affiliated service DS , d DS <q, where q is the order of this G, and the public key P DS = d DS DS G; Before subscribing to the service, the client initiates an authentication handshake request to the server according to step two. The server issues a number SIDi to each client that successfully completes the handshake and stores the SIDi. The server selects a large prime number p that satisfies... p is used to define the multiplication group. If the number of clients managed by the server is n, then the server starts from... Choose n pairwise coprime positive integers as the authentication keys {VAK} for each client. i The authentication keys for each client are |i=1,2,…n}. All authentication keys are greater than q, where q is the threshold value for the group key. The server sends these authentication keys to each of the n clients, and then performs the following calculation steps: 4.2.1) Calculation 4.2.2) For i = 1, 2, ..., n, calculate 4.2.3) For i = 1, 2, ..., n, calculate y i , satisfying x i ×y i ≡1modVAK i 4.2.4) For i = 1, 2, ..., n, let x i and y i The result is stored in variable C i In, that is, C i =x i ×y i The server calculates the group key factor λ, i.e., λ = ∑C i 4.2.5) Then the server selects a random number as the group key of the event group k < q, and calculates the message m=k×λ 4.2.6) The server broadcasts message m to all clients in the event group. The clients belonging to the event group receive m. Since k < q < VAK i <p, and λ mod VAK i = 1, the client directly calculates m mod VAK i to obtain the group key k of the event group; 4.3) Unicast key update: In the SOME / IP unicast scenario, if the session key expires, the session key will be updated according to the unicast key negotiation process; 4.4) Multicast key update: In the SOME / IP multicast scenario, if a member of the subscription group leaves or joins, the multicast group key will be updated immediately to ensure forward and backward security. This will trigger the multicast key update process. When the new member S i Join the event group, S i S sends a subscription request to the server to join the event group. i The client sends its certificate to the server. The server then authenticates the client according to the process in step two. After successful authentication, the server sends the authentication key to S. i And perform the following steps: 4.4.1) Recalculate according to step 4.2) to obtain the new group key factor λ′; 4.4.2) For this event group, select a new group key k′ < q, calculate the message m'=k'×λ' 4.4.3) The server multicasts k' via UDP, and the calculation for all members of this event group is: m' mod VAK. i The new group key k' can then be obtained; When group member S j After leaving the event group, the server finds the variable C corresponding to that member calculated in step 4.2.4) of step 4.2). j And calculate the new group key factor λ' = λ - C through step 4.4.1). j Delete the member's authentication key information. The subsequent steps are the same as steps 4.4.2) and 4.4.3) for adding a new member to the event group scenario.

5. The adaptive secure vehicular communication method under a centralized vehicular domain architecture according to any one of claims 1 to 4, characterized in that: The method is based on the following assumptions: (1) Each vehicle has a certificate distribution center set up in the central domain controller when it leaves the factory. The certificate is bound to the VIN code (Vehicle Identification Number) of each vehicle. It is only valid within the current vehicle and cannot be used for identity authentication processes in other vehicles' internal networks. (2) Service safety risk assessment is subjective. It is necessary to obtain the basic safety score of each service based on the fuzzy comprehensive evaluation model when the vehicle leaves the factory. If the basic safety score needs to be modified, the score is reorganized and sent to each vehicle through OTA upgrade. (3) The initialization of key parameters and certificates is performed each time the vehicle is powered on. The certificate distribution center will distribute a lightweight digital certificate for each SOME / IP service, which is only valid during the current vehicle power-on period. (4) Considering that SOME / IP service subscriptions within the same domain controller do not need to be transmitted through the vehicle network, the adaptive vehicle security communication method under the centralized vehicle domain architecture is only applicable to SOME / IP service communication between different domain controllers.

6. A system based on the aforementioned centralized vehicle domain architecture for adaptive secure vehicle communication, characterized in that: Implementing the adaptive secure vehicular communication method under the centralized vehicular domain architecture as described in any one of claims 1 to 5, comprising: The system initialization module is used in step one to initialize certificate information and basic security scores for each SOME / IP service. The identity authentication module is used in step two to verify the legitimacy of the SOME / IP service subscription client. The risk assessment module is used in step three to perform a security risk assessment on the SOME / IP service subscription request, obtain a security score, and determine a security policy. The key management module is used in step four to generate, distribute, and update session keys for both SOME / IP unicast and multicast communication scenarios. The secure communication module is used in step five to encrypt SOME / IP communication messages to ensure message confidentiality and generate message authentication codes to ensure message integrity and freshness.

7. A device based on the aforementioned adaptive secure vehicle communication method under a centralized vehicle domain architecture, characterized in that: include: Memory, used to store computer programs; A processor, configured to implement the adaptive secure vehicle communication method under a centralized vehicle domain architecture as described in any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by the processor, it can perform in-vehicle network communication based on the adaptive secure in-vehicle communication method under the centralized in-vehicle domain architecture as described in any one of claims 1 to 5.

Images