A vehicle system key management method for a domain centralized electronic and electrical architecture

Abstract

The application discloses a vehicle system key management method for a domain centralized electronic and electrical architecture, and comprises the following steps: each SOME / IP service performs a bidirectional service authority authentication mechanism based on a BLS short signature to complete authentication; according to the communication interface of each SOME / IP service, inter-domain communication is divided into unicast communication and multicast communication; for unicast communication, the server and the client corresponding to each SOME / IP service on the vehicle system negotiate a symmetric key when the vehicle system is powered on; for multicast communication, the server and the client corresponding to each SOME / IP service perform service handshake through service publishing and subscribing and establish a service group, and the members of the service group negotiate a shared group key; and each DCU and the ECUs in the domain calculate the intra-domain communication encryption key according to the public parameters required by the intra-domain communication encryption key distributed by the gateway. The application is suitable for the automotive domain centralized electronic and electrical architecture.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of information security, and particularly relates to a vehicle system key management method for a domain centralized electronic and electrical architecture. BACKGROUND

[0002] With the continuous deepening of the intelligence and networking of automobiles, the communication security risks faced by the automobiles are also growing. However, the automobiles are not designed with any security mechanism at the beginning, and are vulnerable to various types of attacks, which can cause abnormal functions of the automobiles or even serious accidents. The domain centralized architecture is a popular vehicle network architecture at present, and needs to deploy corresponding security mechanisms to ensure the communication security of the vehicle network.

[0003] The automobile domain centralized electronic and electrical architecture divides the automobile into a plurality of functional domains according to functions, each domain takes a high-performance domain controller (DCU) as the core, the different domains are connected through a gateway, and the information exchange is implemented by using an automobile Ethernet with higher transmission rate. Different types of communication buses such as CAN bus and LIN bus can be used in each domain according to different requirements, and the electronic control unit (ECU) communicates with the DCU of the domain through the buses. The automobile Ethernet used for inter-domain communication uses the Service-Oriented Architecture (SOA) to take the Scalable service-Oriented MiddlewarE over IP (SOME / IP) as the application layer communication protocol, and realizes the dynamic service-oriented communication. SOME / IP provides an abstract service-oriented interface for the application program based on the server-client communication mode, and aims to provide a flexible, efficient and service-oriented communication mechanism. SOME / IP supports service discovery, service registration and message transmission, and greatly enhances the ability of the internal network interconnection of the vehicle, and meets the complex vehicle communication requirements. The DCU and the ECU in the intra-domain communication network have significant differences in computing and storage resources, and the complex data and control functions in the domain are uniformly processed by the DCU, and the ECU only needs to execute the instructions issued by the DCU, so as to realize more efficient and centralized vehicle management.

[0004] The vehicle-mounted architecture brings convenience to vehicle-mounted network communication, but also brings new challenges to the security of vehicle-mounted network data transmission. The main performances are three aspects: (1) the existing security protocols designed for traditional Ethernet cannot adapt to the communication scenario of domain centralized architecture. The classic Ethernet security protocols (such as IPsec, TLS, etc.) cannot well compatible with the vehicle communication protocol including SOME / IP, and will bring a large communication overhead. (2) The existing researches in the field of vehicle Ethernet are relatively scarce, and most of the researches do not fully consider the characteristics of different services in the SOME / IP protocol. In addition, these researches also do not propose a specific key management scheme. (3) The current researches on vehicle network security mainly focus on CAN bus, but these schemes cannot well adapt to the characteristics of unbalanced resources between DCU and ECU under the domain architecture. Hu et al. proposed a Gatekeeper scheme for IPsec, MACsec and TLS protocols in Ethernet, which can be used for receiver to verify the identity of the sender. Iorio et al. assigned a security level to the service according to the importance of the service, and different security levels correspond to different security schemes. However, the above schemes do not give a specific key management scheme. Cui et al. proposed a matrix-based key management scheme for CAN bus, and the symmetric key shared between ECUs can be established using a secret matrix D and a public matrix G. Musuroi et al. used the STS protocol, a variant of the Diffie-Hellman protocol, to implement the exchange of group key on CAN bus. Shen et al. proposed a two-layer ECU group key management scheme, and ECUs in the same group share a group key. However, these schemes cannot well adapt to the unbalanced network structure of resources within the domain under the domain centralized electronic and electrical architecture.

[0005] In summary, how to realize secure and efficient and fine-grained key management in the communication scenario of automobile domain centralized electronic and electrical architecture is a challenging problem, and there is no good solution at present. SUMMARY

[0006] In order to solve the above problems existing in the prior art, the application provides a vehicle system key management method for a domain centralized electronic and electrical architecture. The technical problem to be solved by the application is solved by the following technical scheme:

[0007] The embodiment of the application provides a vehicle system key management method for a domain centralized electronic and electrical architecture, and the method comprises the following steps:

[0008] After the vehicle system is powered on, the gateway distributes a digital certificate containing a unique identifier of a service and a unique identifier of a DCU for each SOME / IP service of each DCU; based on the digital certificate, a client and a server corresponding to each SOME / IP service perform a two-way service authority authentication mechanism based on a BLS short signature to complete authentication;

[0009] Inter-domain communication is divided into unicast communication and multicast communication according to a communication interface of each SOME / IP service; for inter-domain key management of unicast communication, a server and a client corresponding to each SOME / IP service negotiate a symmetric key when the vehicle system is powered on, so that inter-domain communication is performed according to the symmetric key; for inter-domain key management of multicast communication, a server and a client corresponding to each SOME / IP service perform service handshake through service publishing and subscribing and establish a service group, and members of the service group negotiate a shared group key, so that inter-domain communication is performed through the negotiated shared group key.

[0010] Each DCU and an ECU in a domain calculate an intra-domain communication encryption key according to a public parameter required by the gateway for distributing the intra-domain communication encryption key, so that intra-domain communication is performed according to the intra-domain communication encryption key; wherein the computing capability of the DCU is greater than the computing capability of each ECU in the corresponding domain.

[0011] The beneficial effects of the present application are as follows:

[0012] The vehicle system key management method for the domain centralized electronic and electrical architecture provided by the present application solves the problem of lack of efficient and fine-grained key management model in the communication scenario of the domain centralized electronic and electrical architecture of an automobile, and a set of key management scheme is designed for different services of inter-domain SOME / IP and the unbalanced network structure of intra-domain resources: the scheme includes inter-domain key management and intra-domain key management; in the cross-domain communication network, digital certificates are provided for the SOME / IP services of all domain controllers, service authority authentication is performed based on BLS short signature, and various communication mechanisms of the SOME / IP service are fully considered, and a service-granularity key management scheme suitable for unicast and multicast communication types is proposed, so that the confidentiality and integrity of communication are guaranteed; in the intra-domain communication network, for the unbalanced network structure of DCU and ECU resources, the high-performance DCU is made to undertake relatively more computing tasks, so as to relieve the key management burden of the ECU. A large number of experiments prove the effectiveness of the method provided by the present application. In general, the present application solves the problems of large communication overhead, coarse protection granularity and difficulty in adapting to the domain centralized electronic and electrical architecture of the existing vehicle communication key management mechanism, improves the efficiency of key management, and provides security protection for vehicle communication.

[0013] The present application will be further described in detail below with reference to the accompanying drawings and embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 is a flowchart of a vehicle system key management method for a domain centralized electronic and electrical architecture provided by an embodiment of the present application;

[0015] Figure 2 is a schematic diagram of a domain centralized electronic and electrical architecture provided by an embodiment of the present application;

[0016] Figure 3 is a schematic diagram of common symbols involved in a key management process provided by an embodiment of the present application;

[0017] Figure 4 is a schematic diagram of an inter-domain group key negotiation process provided by an embodiment of the present application;

[0018] Figure 5 is a detailed processing schematic diagram of a first step execution process in the inter-domain group key negotiation provided by an embodiment of the present application;

[0019] Figure 6 is a detailed processing schematic diagram of a second step execution process in the inter-domain group key negotiation provided by an embodiment of the present application;

[0020] Figure 7 is a detailed negotiation process schematic diagram of an inter-domain negotiation key provided by an embodiment of the present application;

[0021] Figure 8 is a comparison schematic diagram of a calculation overhead of an inter-domain group key negotiation in two cases of using HSM and not using HSM provided by an embodiment of the present application;

[0022] Figure 9 is a comparison schematic diagram of a calculation overhead of an intra-domain key negotiation in two cases of using HSM and not using HSM provided by an embodiment of the present application, and N = 256;

[0023] Figure 10 is a comparison schematic diagram of a calculation overhead of an intra-domain key negotiation in two cases of using HSM and not using HSM provided by an embodiment of the present application, and N = 512. DETAILED DESCRIPTION

[0024] The present application will be further described in detail below with specific embodiments, but the embodiments of the present application are not limited thereto.

[0025] First, the basic theories and technologies related to the present application are described, such as Diffie-Hellman key exchange algorithm, elliptic curve, bilinear pairing technology, BLS signature technology, and digital certificate technology.

[0026] 1. Diffie-Hellman key exchange algorithm

[0027] Diffie-Hellman key exchange protocol relies on the difficulty of discrete logarithm, so that the two parties sharing the key can safely negotiate the shared key. The effectiveness of Diffie-Hellman key exchange algorithm depends on the difficulty of calculating discrete logarithm: when a large prime number p and one of its primitive root g are given, for a given A = g i mod p, where (0≤i≤p-1), it is very difficult to calculate i, while it is relatively easy to calculate A given i.

[0028] From the above, the Diffie-Hellman key exchange algorithm is described as follows:

[0029] (1) Assume that any two public parameters, a large prime number p and an integer g, where g is a primitive root of p.

[0030] (2) Assume that two communication parties Alice and Bob want to obtain a communication key, then Alice selects a private key a < p, and calculates the public key X = g a mod p. Alice keeps a secret, but X needs to be made public to Bob. Similarly, Bob also selects a random number b < p to calculate the public key Y = g b mod p, and Bob keeps b secret so that Y can be obtained by Alice.

[0031] Alice calculates the key using K = Y a mod p. Similarly, Bob calculates the key using K = X b mod p, where K = Y a mod p = (g b ) a mod p = (g a ) b mod p = X b mod p. At this point, both parties have obtained a common shared key K.

[0032] 2. Elliptic curve

[0033] The elliptic curve used in cryptography is an elliptic curve in the finite field , where p is a prime number, and if a, b ∈ GF(p), (x, y) ∈ GF(p) 2 , an elliptic curve can be obtained:

[0034] E P (a, b) = {(x, y): y 2 = x 3 + ax + b (mod p)} ∪ {O};

[0035] Where O represents the point at infinity, the elliptic curve satisfies the discriminant: Δ = -16(4a 3 + 27b 2 )≠0;

[0036] E P The addition on (a, b) is defined as follows: P + O = P, if P = (x, y), its additive inverse is P' = -P = (x, -y). Let P = (x1, y1), Q = (x2, y2), P is not the inverse of Q, then P + Q = (x3, y3), x3, y3 are calculated as follows:

[0037] x3 = λ 2 - x1 - x2 (mod p), y3 = λ 2 (x1 - x3) - y1 (mod p);

[0038]

[0039] 3. Bilinear pairing technology

[0040] Let p, q be large prime numbers and satisfy q | p - 1. Let denote the cyclic additive group on the elliptic curve E p (a, b), denote the cyclic multiplicative group on the same elliptic curve, and and both have order q. Then a bilinear map can be defined and satisfies the following properties:

[0041] (1) Bilinearity: for any then: e (aP, bQ) = e (bP, aQ) = e (P, Q) ab ;

[0042] (2) Non-degeneracy: there exists such that Here denotes the identity element of .

[0043] (3) Computability: for any there exists an efficient algorithm to compute

[0044]

[0045] 4. BLS signature technology

[0046] BLS is a digital signature algorithm based on elliptic curve cryptography. It signs the hash value of the message, and the result of the signature is only a point on the elliptic curve, so it is suitable for use in bandwidth-limited environments such as network communication.

[0047] Suppose user A wants to generate a BLS short signature for message m, then A first chooses a random number r as his private key, and then computes the public key Q = dP. Next, user A signs the message m with his private key. A computes a hash value H(m) for message m, where The signed message is If user B wants to verify the legality of the signature , user B only needs to verify whether it is true. If it is true, the signature is legal; otherwise, the signature is not legal.

[0048] 5. Digital certificate technology

[0049] As a key component of the Internet communication security system, digital certificate is a carefully designed digital identity identifier, which aims to clearly define and distinguish the identity information of communication participants, and embed the detailed identity information and exclusive key of the applicant. The certificate is officially issued by a highly authoritative CA agency (i.e. certificate authority center), and is supplemented by the digital signature of the CA agency to ensure the authenticity of the certificate content and effectively resist any form of tampering and forgery. Digital certificate is based on public key cryptography and strictly follows the logic of "private key signature and public key verification", which provides security for the integrity of electronic file content. Public key cryptography makes digital certificate unique and private, so digital certificate can play the role of network identity recognition and communication information encryption. This technology can strictly verify the true identity information of both parties of a transaction, protect the confidentiality and authenticity of electronic protocols, ensure the non-repudiation of every step of the transaction process, and give electronic signatures legal formal effect. It is worth noting that this series of security measures are completely independent of the transaction content itself and completely unrelated to the transaction content.

[0050] Based on the above theoretical basis, in order to solve the problem that the existing vehicle-mounted network key management scheme is not applicable to the centralized electronic and electrical architecture of the automobile domain, please refer to Figure 1 , the embodiment of the present application provides a vehicle system key management method for a domain centralized electronic and electrical architecture. As shown in Figure 2 , for easy reading, the commonly used symbols involved in the present application are shown in Figure 3 to give the corresponding meanings, and the corresponding method includes:

[0051] S10, after the vehicle system is powered on, the gateway distributes a digital certificate containing the unique identification of the service and the unique identification of the DCU for each SOME / IP service of each DCU; based on the digital certificate, the client and the server corresponding to each SOME / IP service will perform a two-way service authority authentication mechanism based on BLS short signature to complete the authentication.

[0052] Each vehicle has a digital certificate distribution center (similar to CA) set in the gateway at the time of factory shipment, denoted as gateway, the certificate bundles the VIN code (Vehicle Identification Number) of each vehicle, and is only legal within the current vehicle and cannot be used for identity authentication process of the internal network of other vehicles. At the same time, the initialization of key parameters and certificates is performed every time the vehicle is powered on, and the gateway distributes a digital certificate for each SOME / IP service of the domain controller, which is only valid during the current vehicle power-on period.

[0053] The vehicle system initialization is immediately performed after the vehicle is powered on, and the vehicle system initialization mainly includes the secure start of the in-vehicle hardware and the distribution of the digital certificate and the key negotiation required parameters, which are only valid during the current vehicle system power-on period. In addition to having a digital certificate to prove its identity, the gateway also distributes a digital certificate for each SOME / IP service of each DCU, which contains the unique identification ID of the SOME / IP service and the unique identification ID of the DCU.

[0054] Before the client and the server of a SOME / IP service communicate, based on the digital certificate, the client and the server corresponding to each SOME / IP service will perform a two-way service authority authentication based on BLS short signature. The client and the server will send the certificate of the SOME / IP service they belong to to each other, and after receiving the certificate, they will verify the service authority. More specifically, the authentication process is as follows:

[0055] (1), first, the client selects a random number as its temporary private key, and calculates the temporary public key Q c = aP, The client will select a random number a every time the authentication is performed. The client first calculates the hash value of its unique identification id c , temporary public key Q c and current timestamp T c , that is, H(id c || Q c || T c ). Then use the private key s c belonging to the service to sign it to get Sign c = s c H(idc ||Q c ||T c ), the client sends Sign c , Q c , P c and T c to the server, where P c is the server's public key.

[0056] (2) After receiving the signature Sign c from the client, the server first verifies the freshness of the message T-T c <ΔT, where T is the newly generated timestamp. If the verification is passed, the subsequent authentication is continued. The server verifies the correctness of Sign c by the equation e(Sign c , P) = e(H(id c || Q c || T c ), P c ). If the equation is not established, the server will reject the client's application to use the service. Then the server selects a random number as its temporary private key, and calculates the temporary public key Q s = dP. The server will reselect a random number d every time the authentication is performed. The server first calculates the hash value of its unique identifier id s , the temporary public key Q s and the current timestamp T s , i.e. H(id s || Q s || T s ). Then it is signed by the private key s s belonging to the service to obtain Sign s = s s H(id s || Q s || T s ). The server sends Sign s , Q s , P s and T s to the client, where P s is the server's public key.

[0057] (3) After receiving the signature Sign s from the server, the client first verifies the freshness of the message T-T s <ΔT, where T is the newly generated timestamp. If the verification is passed, the subsequent authentication is continued. The client verifies the correctness of Sign s by the equation e(Sign s||Q s ||T s ),P s ) to judge the correctness of Sign s . If the equation is not established, the client considers that the server does not have the right to provide the service. Otherwise, the client and the server realize the two-way service authority authentication, and the subsequent communication can be carried out.

[0058] S20, inter-domain communication is divided into unicast communication and multicast communication according to the communication interface of each SOME / IP service; for inter-domain key management of unicast communication, the server and the client corresponding to each SOME / IP service on the vehicle system negotiate a symmetric key when the vehicle system is powered on, so as to perform inter-domain communication according to the symmetric key; for inter-domain key management of multicast communication, the server and the client corresponding to each SOME / IP service perform service handshake through service publishing and subscribing and establish a service group, and the members of the service group negotiate a shared group key, so as to perform inter-domain communication through the negotiated shared group key.

[0059] In the embodiment of the application, all components in the vehicle system are equipped with corresponding HSM (Hardware Security Module), and the HSM specification (EVITA HSM) divides the HSM into three levels, which are Full, Medium and Light. The Full level HSM provides the maximum functionality and security, and is mainly used for the secure communication of V2X; for the gateway and each DCU, the Medium level HSM can meet the requirements thereof, and it can support the secure storage of data; for each ECU, the Light level HSM is equipped.

[0060] SOME / IP has three different communication interfaces, which are Method, Field and Event. Generally, the Getter and Setter methods in the Method communication interface and the Field communication interface of each SOME / IP service in the communication process adopt unicast communication of request-response or request-no response; the Notifier method in the Event communication interface and the Field communication interface is triggered by the server under a specific event to send corresponding messages to all clients subscribing to the specific event, and adopts multicast communication, so the inter-domain key management is divided into two scenarios of unicast and multicast.

[0061] Next, the inter-domain key management of unicast and multicast is introduced in detail.

[0062] (I) Inter-domain key management in unicast communication

[0063] For unicast communication, the server and client corresponding to each SOME / IP service negotiate a symmetric key when the vehicle system is powered on, and inter-domain communication is performed according to the symmetric key. More specifically:

[0064] In the unicast communication scenario, the server and the client need to perform service permission authentication first. After the service authentication is successful, the server and the client use the random number d and a selected during the service authentication and the temporary public key Q c and Q s of the other party to negotiate a symmetric key for subsequent communication.

[0065]

[0066] The server and the client will re-perform service authentication and negotiate a new symmetric key every time the vehicle is powered on. The symmetric key will be used during the running process of the vehicle.

[0067] (II) Inter-domain key management in multicast communication

[0068] In the multicast communication scenario, the server and all clients need to perform service permission authentication first. After the authentication is passed, the server and the client can perform service handshake through service publishing and subscribing and establish a service group. The members of the service group perform subsequent communication by negotiating a shared group key. In order to simplify the understanding of the key management scheme, the description of the specific message transmission process is omitted. It is assumed that all messages are transmitted after being encrypted, which can ensure the source, authenticity and integrity of the messages.

[0069] After the service group is established, the server (server) sorts all clients (client i ) in the group. The server is always the first member of the group. It generates a group member list list={server,client1,client2,…,client n n represents the number of clients in the service group, and is shared by all group members. Only when the client member changes will the list be updated.

[0070] Before the service group members in the multicast communication of the embodiment of the present invention negotiate to share the group key, it includes: except for the server, each client in the service group calculates its own first key in the HSM equipped for it according to its own service private key and the service public key of the next client and stores it in the HSM equipped for it; wherein, the last client calculates the first key of the last client in the HSM equipped for it according to its own service private key and the service public key of the server and stores it in the HSM equipped for it; starting from the last client in the service group, each client calculates its own second key in the HSM equipped for it according to its own service private key and the service public key of the previous client and stores it in the HSM equipped for it; wherein, the first client calculates the second key of the first client in the HSM equipped for it according to its own service private key and the service public key of the server and stores it in the HSM equipped for it.

[0071] More specifically:

[0072] Clients other than the server in the service group, client i (i=1,2,…,n-1) Use your own service private key s i and client i+1 Service public key P i+1 Calculate U i,i+1 , U i,i+1 =s i P i+1 =(x i,i+1 ,y i,i+1 ), (x i,i+1 ,y i,i+1 ) represents the coordinates of a point on the elliptic curve. Calculate t based on two points on the elliptic curve i,i+1 =x i,i+1 ⊕y i,i+1 , from which we can get client i The first key IK i =H(id i ||id i+1 ||t i,i+1 ), client i The first key IK i Store it in the HSM configured for it, that is, storeToHSM(key i ,IK i ) and can be used at any time when needed. n Use your own service private key n And the server's service public key P s Calculate U n,s , U n,s =s n P s=(x n,s ,y n,s ), (x n,s ,y n,s ) represents the coordinates of a point on the elliptic curve. Calculate t based on two points on the elliptic curve n,s =x n,s ⊕y n,s , from which we can get client n The first key IK n =H(id n ||id s ||t n,s ), client n The first key IK n Store it in the HSM configured for it, that is, storeToHSM(key n ,IK n These steps can be executed when the service group key negotiation begins, that is, the client i It can be executed in advance when offline, without waiting for the client i-1 After execution, the first key IK of all clients in the service group is completed. i Offline calculation.

[0073] Similarly, starting from the last client in the service group, client j (j=n,n-1,…,1) uses its own service private key s j and client j-1 Service public key P n-1 Calculate U j-1,j =s j P j-1 =(x j-1,j ,y j-1,j ), (x j-1,j ,y j-1,j ) represents the coordinates of a point on the elliptic curve. Calculate t based on two points on the elliptic curve j-1,j =x j-1,j ⊕y j-1,j , from which we can get client j The second key PK j-1 =H(id j-1 ||id j ||t j-1,j ).client j The second key PK j-1 Store it in the HSM configured for it, that is, storeToHSM(key' j ,PK j-1) and can be used at any time when needed. Client1 uses its own service private key s1 and server's service public key P s Calculate U s,1 =s1P s =(x s,1 ,y s,1 ), (x s,1 ,y s,1 ) represents the coordinates of a point on the elliptic curve. Calculate t based on two points on the elliptic curve s,1 =x s,1 ⊕y s,1 , from which we can get the second key PK of client1 s =H(id s ||id1||t s,1 ). client1 uses the second key PK s Store it in the HSM configured for it, that is, storeToHSM(key1',PK s ).

[0074] These steps can be executed when the service group key negotiation begins, that is, the client j It can be executed in advance when offline, without waiting for the client j-1 After the execution is completed, the offline calculation of the second keys of all clients in the service group is completed.

[0075] It should be noted that the storage and retrieval operations mentioned later are all performed within the HSM equipped on the server or client side.

[0076] Furthermore, the specific process of negotiating a shared group key between service group members in multicast communication according to the embodiment of the present invention includes:

[0077] The first step is to execute the process as follows Figure 4The left part shows that the process includes: from the server, the server calculates the first key of the server according to the service private key of the server and the service public key of the first client, stores the first key of the server in the HSM, and sends the encrypted first key of the server to the first client; the first client receives the encrypted first key of the server, obtains the first key of the server by parsing, stores the first key of the server in the HSM, takes the first key of the first client from the HSM, calculates the new first key of the first client according to the first key of the server and the first key of the first client, encrypts the new first key of the first client, and sends the encrypted new first key of the first client to the second client; the ith client receives the encrypted new first key of the (i-1)th client, obtains the new first key of the (i-1)th client by parsing, stores the first key of the (i-1)th client in the HSM, i=2,…,n-1, n represents the number of clients in the service group, takes the first key of the ith client from the HSM, calculates the new first key of the ith client according to the first key of the ith client and the new first key of the (i-1)th client, encrypts the new first key of the ith client, and sends the encrypted new first key of the ith client to the (i+1)th client, until the (n-1)th client encrypts the new first key of the (n-1)th client and sends the encrypted new first key of the (n-1)th client to the nth client; the nth client receives the encrypted new first key of the (n-1)th client, obtains the new first key of the (n-1)th client by parsing, stores the first key of the (n-1)th client in the HSM, and takes the first key of the nth client from the HSM, calculates the group key of the nth client according to the first key of the nth client and the new first key of the (n-1)th client;

[0078] The second step execution process is as follows Figure 4As shown on the right, it includes: starting from the nth client, the nth client takes out the second key of the nth client from the HSM, calculates the new second key of the nth client based on the group key of the nth client and the second key of the nth client, encrypts the new second key of the nth client and sends it to the n-1th client; the jth client receives the encrypted new second key of the j+1th client and parses it to obtain the new second key of the j+1th client, j=n-1,n-2,…,1, takes out the second key of the jth client and the first key of the jth client from the HSM, and calculates the new second key of the j+1th client based on the new second key of the j+1th client and the first key of the jth client. The jth client's group key is calculated based on the jth client's second key and the jth client's first key. The jth client's new second key is encrypted and sent to the j-1th client, until the first client encrypts the first client's new second key and sends it to the server. The server receives the encrypted first client's new second key and parses it to obtain the first client's new second key. It then retrieves the server's first key from the HSM and calculates the server's group key based on the first client's new second key and the server's first key. At this point, the group key negotiation within the service group is completed, and all members of the service group share the group key. More specifically:

[0079] The first step is to execute the process as follows Figure 5 Shown, including:

[0080] Starting from the server, the server uses its own service private key s s Calculate U with the service public key P1 of the first client client1 s,1 , U s,1 =s s P1=(x s,1 ,y s,1 ), (x s,1 ,y s,1 ) represents the coordinates of a point on the elliptic curve. Calculate t based on the point on the elliptic curve s,1 =x s,1 ⊕y s,1 , from which we can get the server's first key IK s =H(id s ||id1||t s,1 ), where IK s '=IK s Then, the server will IK s 'After encryption S ={IK s}Send to client1;

[0081] Client1 receives the encrypted first key m from the server S And parse to obtain the first key IK of the server s ', for subsequent key updates, the server's first key IK s 'Stored in HSM, that is, storeToHSM(update,IK s '), and take out the first client's first key IK1 from the HSM, IK1 = getFromHSM (key1), according to the first key IK s 'Calculate the new first key IK1 of the first client with the first key IK1 of the first client'=IK s '⊕IK1, encrypt the first client's new first key IK1' m1 = {IK1'} and send it to the second client;

[0082] Next, the client i (i=2,…,n-1) receives m i-1 After that, parse and get the client i-1 New first key IK i ' -1 , for subsequent key updates, client i IK i ' -1 Store it securely, i.e. storeToHSM(update,IK i ' -1 ).client i Get the stored first key IK from the HSM i , that is, IK i =getFromHSM(key i ), according to the client i-1 IK i ' -1 and client i IK i Computing client i New first key IK i '=IK i ' -1 ⊕IK i .client i M i ={IK i '}Safely sent to the client i+1 Here, the value of i starts from 2 because the processing of client 1 has been described above.

[0083] The last client nReceived from client n-1 Sent m n-1 After that, IK is obtained by analysis n ' -1 , for subsequent key updates, client n IK n ' -1 Store it securely, i.e. storeToHSM(update,IK n ' -1 ).client n Get the stored first key IK from the HSM n , that is, IK n =getFromHSM(key n ), according to the client n-1 IK n ' -1 and client n IK n You can calculate the client n The group key KG = IK n ' -1 ⊕IK n .

[0084] The second step is to execute the process as follows Figure 6 Shown, including:

[0085] client n After calculating the group key KG, the stored second key PK is retrieved from the HSM n-1 , namely PK n-1 =getFromHSM(key' n ), according to PK n-1 and KG calculation client n New second key MK n =KG⊕PK n-1 ,client n MK n After encryption, m' n ={MK n}Send to the client securely n-1 .

[0086] client j (j=n-1,n-2,…,1) receives the client j+1 Sent m j ' +1 After that, parse and get the client j+1 New second key MK j+1 , and retrieve the stored second key PK from the HSMj-1 and the first key IK j , i.e. PK j-1 = getFromHSM (key j ), IK j = getFromHSM (key j ). From MK j+1 and IK j , the group key KG = MK j Θ IK j+1 of client j can be calculated. From the group key KG and PK j-1 , the new MK j = (KG Θ PK j ) of client j-1 can be calculated. Client j sends m' j = {MK j} securely to client j-1 , until the first client client1 sends m1' = {MK1} to server after encrypting the first client's new second key MK1.

[0087] After receiving m1', server parses MK1 and gets IK s from HSM. From MK1 and IK s , the group key KG = MK1 Θ IK s can be calculated. Thus, the group key agreement is finished and all members of the service group share the group key KG.

[0088] Further, when a new client joins in the multicast communication scenario of the embodiment of the present application, the new client is added to the last position of the service group as the n+1th client; all the clients and the server before the nth client keep their processing in the first step; starting directly from the nth client, the nth client takes out the first key of the n-1th client from the HSM, and calculates the first key of the nth client according to its service private key and the service public key of the n+1th client, updates the first key of the nth client in the HSM, calculates the new first key of the nth client according to the first key of the n-1th client and the first key of the nth client, and sends the encrypted first key of the nth client to the n+1th client; the n+1th client receives the encrypted first key of the nth client, parses to obtain the first key of the nth client, stores the first key of the nth client in the HSM, calculates the first key of the n+1th client according to its service private key and the service public key of the server, stores the first key of the n+1th client in the HSM, and calculates the group key of the nth client according to the first key of the nth client and the first key of the n+1th client; the second step is continued to be executed again starting from the n+1th client. It can be seen that for the case of a new client, since the new client is added to the last position of the service group by default, all the original clients except the last client keep the first step unchanged, and the last client and the new client continue the first step of the above-mentioned intermediate client and the last client. Since the new client will affect the negotiation of the shared group key, the second step is executed again starting from the new client, and the specific process is described above and will not be repeated here.

[0089] Further, when the first client exits in the multicast communication scenario of the embodiment of the present application, the first step and the second step are executed again starting from the server. Since the exiting client will affect the negotiation of the shared group key, for the case of the first client exiting, the second client is taken as the new first client, and all the processes are executed again starting from the server. The specific process is described above and will not be repeated here.

[0090] Further, in the multicast communication scenario, if the lth client (l≠1) exits, the (l-1)th client and the (l+1)th client become neighbors, l=2,…,n: all the clients before the (l-1)th client keep the processing in the first step; starting from the (l-1)th client, the (l-1)th client calculates the first key of the (l-1)th client according to the service private key of the (l-1)th client and the service public key of the (l+1)th client, updates the first key of the (l-1)th client in the HSM, takes the first key of the (l-2)th client from the HSM, calculates the new first key of the (l-1)th client according to the first key of the (l-2)th client and the first key of the (l-1)th client, and sends the encrypted first key of the (l-1)th client to the (l+1)th client; the (l+1)th client receives the encrypted first key of the (l-1)th client, obtains the first key of the (l-1)th client by parsing, updates the first key of the (l-1)th client in the HSM, takes the first key of the (l+1)th client from the HSM, calculates the new first key of the (l+1)th client according to the first key of the (l-1)th client and the first key of the (l+1)th client, and sends the encrypted first key of the (l+1)th client to the next client until the (n)th client calculates the group key of the (n)th client; the second step is re-executed starting from the (n)th client. Different from the case that the first client exits, when the intermediate client exits, the clients before the intermediate client do not need to re-execute the first step, and the first step of the above-mentioned intermediate client and the last client is continued starting from the last client of the intermediate client, and the second step is continued to be executed from the last client, and the specific process is referred to the specific process of the negotiation of the shared group key between the service group members in the multicast communication, which is not described herein again.

[0091] It should be noted that the default server does not exit, because if the server exits, it means that the SOME / IP service stops providing, and there is no need for a group key.

[0092] The embodiment of the application greatly reduces the calculation complexity by designing an offline-online combined calculation scheme based on the HSM.

[0093] Security analysis is performed on the process of the negotiation of the shared group key between the service group members in the multicast communication according to the embodiment of the application.

[0094] (1) Man-in-the-middle attack

[0095] The proposed process of negotiating shared group key among members of a service group in multicast communication can resist man-in-the-middle attacks against SOME / IP services. Both the server and the client need to go through service permission authentication before providing or using SOME / IP services. Only a legitimate DCU can obtain the corresponding service certificate, and an attacker cannot obtain the corresponding service certificate, nor can the attacker obtain the service certificate of other DCUs from the HSM. Therefore, the attacker cannot participate in the subsequent key negotiation and communication through service permission authentication.

[0096] (2) Forward security

[0097] When a new member joins the SOME / IP service group, the group members will update the group key. Since the new member does not know the private keys of other members, the new member cannot infer the previous group key from the existing information, but can only obtain the group key after joining. Therefore, the new member cannot know the previous communication information, and the forward security can be guaranteed.

[0098] (3) Backward security

[0099] When a member exits the SOME / IP service group, the remaining group members will update the group key. Since the exiting member does not know the private keys of other members, the exiting member cannot infer the group key of the subsequent service group from the known old group key. Therefore, the exiting member cannot know the subsequent communication information, and the backward security can be guaranteed.

[0100] (4) Conspiracy attack

[0101] The proposed process of negotiating shared group key among members of a service group in multicast communication can resist conspiracy attacks against the group key of the SOME / IP service group. A conspiracy attack refers to multiple members who have exited the group cooperating with each other to try to obtain the updated group key. Since the group member list is updated every time a member changes, all members no longer use the previous key. At the same time, the key IK i involved in the key negotiation needs to be calculated using the service private key of the member, and the members who have left the group cannot infer the service private key of the group members from the information they share. Therefore, the attacker cannot obtain the current group key through a conspiracy attack.

[0102] S30, each DCU calculates the intra-domain communication encryption key according to the public parameters required by the intra-domain communication encryption key distributed by the gateway, so as to perform intra-domain communication according to the intra-domain communication encryption key; wherein the computing power of the DCU is greater than the computing power of each ECU in the corresponding domain.

[0103] Typically, the computing power of the DCU and ECU in a vehicle system with a domain-distributed electrical and electronic framework is comparable. To address scenarios where the computing power of the DCU in a vehicle system with a domain-centralized electrical and electronic framework is greater than that of the ECU within the domain, an embodiment of the present invention proposes a method in which each DCU and the ECU within the domain calculate the intra-domain communication encryption key based on the public parameters required for the intra-domain communication encryption key distributed by the gateway, and conduct intra-domain communication based on the intra-domain communication encryption key. Specifically: Before calculating the intra-domain communication encryption key, each DCU calculates the corresponding first parameter based on the public parameters required for the intra-domain communication encryption key distributed by the gateway, and stores the first parameter in the HSM. Furthermore, each DCU and the ECU in the domain calculate the intra-domain communication encryption key based on the public parameters required for the intra-domain communication encryption key distributed by the gateway. The process includes: each ECU randomly selects a subset based on the public parameters required for the intra-domain communication encryption key distributed by the gateway, calculates the corresponding second parameter based on the selected subset, and sends the second parameter to the DCU; after receiving the second parameter, the DCU calculates the intra-domain communication encryption key based on the second parameter, extracts the first parameter from the HSM, and broadcasts the first parameter to each ECU in the domain; after receiving the first parameter, each ECU calculates the intra-domain communication encryption key based on the first parameter and the selected subset. More specifically:

[0104] The public parameters for the intra-domain key negotiation are distributed by the gateway when the vehicle system is initialized. Specifically, they include the generator g, the cyclic group G with a prime order of q; N uniform random elements y1,…,y n ∈G, where y i ≠1(1≤i≤n).

[0105] In the embodiment of the present invention, the DCU only needs to perform calculation once and calculate the first parameter K DCU It is sent to all ECUs in the domain through broadcasting, and the most time-consuming modular exponentiation operation during key negotiation can be pre-calculated by the DCU with stronger computing power when offline, and the ECU with weaker computing power only needs to perform relatively simple modular multiplication operations. Figure 7 As shown:

[0106] (1) Each ECU randomly selects a subset S containing k elements, ECU calculates the corresponding second parameter K ECU =∏ i∈S y i , if K ECU =1, then reselect subset S. ECU will timestamp T ECU and K ECU Signed with your own service private key And will include K ECU 、 and TECU sending the message security to the DCU.

[0107] (2) The DCU selects a random number and calculates the first parameter Then, according to the second parameter K ECU , the intra-domain communication encryption key is calculated The DCU can calculate the value of the first parameter K DCU in advance in the HSM when offline and store it in the HSM, that is, storeToHSM(ID sk , K DCU ), and take out the first parameter K DCU , that is, K DCU = getToHSM(ID sk ) at the beginning of negotiation; after receiving the message sent by the ECU, the second parameter K ECU is parsed, and the DCU can calculate the intra-domain communication encryption key according to the second parameter K ECU Finally, the DCU signs the timestamp T DCU and the first parameter K DCU with its own service private key to obtain and sends a message security broadcast containing K DCU , and T DCU to each ECU in the domain.

[0108] (3) After each ECU receives the message sent by the DCU, the first parameter K DCU is parsed, and the corresponding intra-domain communication encryption key is calculated according to the first parameter K DCU and the selected subset S of each ECU

[0109]

[0110] At this point, the key negotiation is completed, and the DCU and the ECUs share the symmetric intra-domain communication encryption key SK. Although all ECUs receive the same K DCU , but because each ECU selects a different set S, the intra-domain communication encryption key SK shared by the DCU and each ECU is different.

[0111] In order to verify the effectiveness of the vehicle system key management method for the domain centralized electronic and electrical architecture provided by the embodiment of the application, the following experiments are performed for verification.

[0112] I. Experimental environment:

[0113] ​The embodiments of the present application are experiments performed on a computer (i5-13400F@2.5GHz, 16G memory, windows11), and C++ is used to simulate the cryptography primitives. The specific cryptography library used is libpbc and openssl.

[0114] II. Experimental results

[0115] Computational overhead (unit: ms): the total time required to perform the key agreement operation in the method of the present application. The computational overhead is related to the performance of the hardware platform, so all experiments are performed on the same hardware platform. Since the execution time of generating timestamps and performing conditional judgments is very short and almost negligible, it is not considered in the experiment.

[0116] Before performing the formal inter-domain key agreement, the server and the client need to perform the service permission authentication. The server and the client need to perform the generation, signature and verification of the temporary public and private key operation once, and the remaining low-delay calculation is ignored. In the signature stage, we choose the SHA-256 hash function, and the computational overhead of the DCU end is T auth ≈18.6ms. The computational overhead of the authentication stage is relatively large, but since the service authentication is performed before communication, and almost all service authentication is completed when the car is powered on, it will not affect the real-time communication of SOME / IP. When unicast key agreement, the DCU only needs to perform a point multiplication operation on the elliptic curve, and the computational overhead is T sy ≈0.712ms. Figure 8 The computational overhead of inter-domain multicast key agreement using HSM and not using HSM is shown under different number of request clients. The experimental results show that: after using HSM, the computational overhead of key agreement is obviously reduced. Under the premise of providing the same level of security protection, using HSM can reduce about 88% of the calculation time. Since the number of service subscription requests in each vehicle is usually not more than 100, and this order of magnitude is normal communication delay in Ethernet communication, the additional overhead will not affect the real-time performance of vehicle communication.

[0117] Figure 9 and Figure 10 The computational overhead of the intra-domain agreement when N=256 and N=512 is shown respectively. We can see that the computational overhead will increase with the increase of N and k, and the performance is obviously improved when we use HSM to perform offline calculation of DCU modular operation. When k=32, using HSM can reduce about 37.12% and 44.66% of the calculation time respectively.

[0118] Communication overhead (unit: byte): the payload required for exchanging data during key agreement. Table 1 shows the communication overhead of each phase in the proposed method. As can be seen from Table 1, the inter-domain symmetric key agreement does not require additional communication overhead, because it relies on the ephemeral private key generated during the service authentication. The communication overhead of the inter-domain group key agreement is related to the number of service group members n, and increases with the number of group members. However, the number of clients participating in the service is limited, so the communication overhead of the group key agreement does not increase indefinitely. The communication overhead of the intra-domain key agreement is related to the number of selected random elements N and the order q of the cyclic group. In the experiment, q is selected as a 128-bit prime number. As can be seen from Table 2, the communication overhead of ECU is independent of the size of N, while the communication overhead of DCU is related to the size of N. However, in the proposed method, DCU only needs to broadcast the key agreement message once, that is, the communication overhead of DCU is independent of the number of ECUs and does not increase with the number of ECUs in the domain.

[0119] Table 1 Communication overhead of inter-domain key agreement

[0120]

[0121] Table 2 Communication overhead of intra-domain key agreement

[0122]

[0123] Storage overhead (unit: byte): the storage cost of DCU and ECU when performing key agreement. Table 3 shows the additional storage overhead of each DCU when performing service authentication, unicast key agreement and multicast key agreement in the inter-domain key agreement model. Table 4 shows the storage overhead of the intra-domain key agreement model, and q is selected as a 128-bit prime number in the experiment. As can be seen from Tables 3 and 4, the storage overhead of DCU and ECU is not the same, the storage overhead of DCU is relatively large and is related to the value of N; the storage overhead of ECU is only related to the value of the number of elements k in set S and is not affected by N.

[0124] Table 3 Storage overhead of inter-domain key agreement

[0125]

[0126] Table 4 Storage overhead of intra-domain key agreement

[0127]

[0128] Compared with the existing key management scheme for vehicle Ethernet, the key management scheme provided by the application can provide finer granularity protection for the SOME / IP communication protocol; compared with the existing key management scheme for CAN bus, the application considers the unbalanced network structure of resources on the bus in the domain, and lets the high-performance DCU bear more key negotiation overhead, thereby relieving the burden of the ECU. Meanwhile, the application reduces the calculation overhead by using the HSM, and can better adapt to the centralized electronic and electrical architecture of the vehicle domain.

[0129] In summary, the vehicle system key management method for the domain centralized electronic and electrical architecture provided by the embodiment of the application solves the problem of lack of efficient and fine-grained key management model in the communication scenario of the centralized electronic and electrical architecture of the automobile domain, and a key management scheme is designed for the different services of the SOME / IP between domains and the unbalanced network structure of resources in the domain: the scheme includes inter-domain key management and intra-domain key management; in the cross-domain communication network, digital certificates are provided for the SOME / IP services of all domain controllers, service authority authentication is performed based on the BLS short signature, and the multiple communication mechanisms of the SOME / IP service are fully considered, and a service-granularity key management scheme suitable for the two communication types of unicast and multicast is proposed, thereby ensuring the confidentiality and integrity of the communication; in the intra-domain communication network, for the unbalanced network structure of resources of the DCU and the ECU, the high-performance DCU is made to bear relatively more calculation tasks, thereby relieving the key management burden of the ECU. A large number of experiments prove the effectiveness of the method provided by the application. In general, the application solves the problems of large communication overhead, coarse protection granularity and difficulty in adapting to the centralized electronic and electrical architecture of the existing vehicle communication key management mechanism, improves the efficiency of key management, and provides security protection for vehicle communication.

[0130] In the description of the application, it should be understood that the terms "first", "second" are only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined as "first", "second" can explicitly or implicitly include one or more of the features. In the description of the application, the meaning of "multiple" is two or more, unless otherwise specifically limited.

[0131] Although the application is described herein in conjunction with various embodiments, other variations of the disclosed embodiments can be understood and implemented by those skilled in the art with reference to the specification and drawings. In the specification, the word "comprising" does not exclude other components or steps, and "one" or "an" does not exclude a plurality. Some measures are described in mutually different embodiments, but this does not mean that these measures cannot be combined to produce good results.

[0132] The above description is further detailed in connection with specific preferred embodiments of the present application, and it is not to be construed that the specific implementation of the present application is limited to these descriptions. For those skilled in the art of the present application, without departing from the concept of the present application, a number of simple deductions or substitutions can be made, and all of them should be considered as falling within the protection scope of the present application.

Claims

1. A vehicle system key management method for a domain-centralized electronic and electrical architecture, characterized in that: The method comprises: After the vehicle system is powered on, the gateway distributes a digital certificate containing the unique identifier of the service and the unique identifier of the DCU to each SOME / IP service of each DCU. Based on the digital certificate, the client and server corresponding to each SOME / IP service will execute a two-way service authorization authentication mechanism based on BLS short signature to complete the authentication. Inter-domain communication is divided into unicast communication and multicast communication based on the communication interface of each SOME / IP service. For inter-domain key management of unicast communication, the server and client corresponding to each SOME / IP service negotiate a symmetric key when the vehicle system is powered on, and then conduct inter-domain communication based on the symmetric key. For inter-domain key management of multicast communication, the server and client corresponding to each SOME / IP service conduct a service handshake through service publishing and subscription and establish a service group. The service group members negotiate a shared group key and then conduct inter-domain communication based on the negotiated shared group key. Each DCU and the ECU in the domain calculate the intra-domain communication encryption key based on the public parameters required for the intra-domain communication encryption key distributed by the gateway, so as to perform intra-domain communication based on the intra-domain communication encryption key; wherein, the computing power of the DCU is greater than the computing power of each ECU in the corresponding domain.

2. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 1, characterized in that: The gateway, each DCU, and each ECU are equipped with an HSM. The HSM equipped on the gateway is a medium-level HSM; the HSM equipped on each DCU is a medium-level HSM; and the HSM equipped on each ECU is a light-level HSM.

3. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 1, characterized in that: The communication interfaces used by each SOME / IP service during the communication process include Method, Field, and Event. Among them, the Getter and Setter methods in the Method communication interface and the Field communication interface adopt request-response or request-no-response unicast communication. The Notifier method in the Event communication interface and the Field communication interface uses multicast communication to trigger the server to send the corresponding message to all clients subscribed to the specific event under a specific event.

4. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 2, characterized in that: Before the service group members in multicast communication negotiate a shared group key, the following steps are also required: Each client in the service group, except for the server, calculates its own first key in its assigned HSM based on its own service private key and the next client's service public key, and stores it in its assigned HSM. The last client calculates its first key in its assigned HSM based on its own service private key and the server's service public key, and stores it in its assigned HSM. Starting from the last client in the service group, each client calculates its own second key in the HSM equipped with it based on its own service private key and the service public key of the previous client and stores it in the HSM equipped with it; among them, the first client calculates its second key in the HSM equipped with it based on its own service private key and the service public key of the server and stores it in the HSM equipped with it.

5. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 1, characterized in that: The specific process of negotiating a shared group key among service group members in multicast communication includes: The first step of the execution process includes: starting from the server, the server calculates the server's first key based on its own service private key and the first client's service public key, stores the server's first key in the HSM, encrypts the server's first key and sends it to the first client; the first client receives the encrypted server's first key and parses it to obtain the server's first key, stores the server's first key in the HSM, and takes out the first client's first key from the HSM, calculates the first client's new first key based on the server's first key and the first client's first key, encrypts the first client's new first key and sends it to the second client; the i-th client receives the encrypted i-1-th client's new first key and parses it to obtain the i-1-th client's new first key, stores the i-1-th client's first key in In the HSM, i = 2, ..., n-1, where n represents the number of clients in the service group. The first key of the i-th client is retrieved from the HSM, and a new first key of the i-th client is calculated based on the first key of the i-th client and the new first key of the i-1-th client. The new first key of the i-th client is encrypted and sent to the i+1-th client, and the process continues until the n-1-th client encrypts the new first key of the n-1-th client and sends it to the n-th client. The n-th client receives the encrypted new first key of the n-1-th client and parses it to obtain the new first key of the n-1-th client. The n-1-th client stores the first key of the n-1-th client in the HSM, retrieves the first key of the n-th client from the HSM, and calculates the group key of the n-th client based on the first key of the n-th client and the new first key of the n-1-th client. The second step includes: starting from the nth client, the nth client takes out the second key of the nth client from the HSM, calculates the new second key of the nth client based on the group key of the nth client and the second key of the nth client, encrypts the new second key of the nth client and sends it to the n-1th client; the jth client receives the encrypted new second key of the j+1th client and parses it to obtain the new second key of the j+1th client, j=n-1,n-2,…,1, takes out the second key of the jth client and the first key of the jth client from the HSM, calculates the new second key of the j+1th client based on the new second key of the j+1th client and the first key of the jth client. Calculate the group key of the j-th client, calculate the new second key of the j-th client based on the second key of the j-th client and the first key of the j-th client, encrypt the new second key of the j-th client and send it to the j-1-th client, until the first client encrypts the new second key of the first client and sends it to the server; the server receives the encrypted new second key of the first client and parses it to obtain the new second key of the first client, and takes out the first key of the server from the HSM, calculates the group key of the server based on the new second key of the first client and the first key of the server, and the group key negotiation within the service group is completed. All members of the service group share the group key.

6. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 5, characterized in that: In a multicast communication scenario, if a new client joins, the new client is added to the last position of the service group as the n+1th client. All clients and servers before the nth client retain their respective processing in the first step. Starting directly from the nth client, the nth client retrieves the first key of the n-1th client from the HSM, calculates the first key of the nth client based on its own service private key and the service public key of the n+1th client, updates the first key of the nth client in the HSM, calculates the new first key of the nth client based on the first key of the n-1th client and the first key of the nth client, encrypts the new first key of the nth client and sends it to the n+1th client. The (n+1)th client receives the encrypted new first key of the (n)th client and parses it to obtain the first key of the (n)th client. The client stores the first key of the (n)th client in the HSM, calculates the first key of the (n+1)th client based on its own service private key and the service public key of the server, stores the first key of the (n+1)th client in the HSM, calculates the group key of the (n)th client based on the first key of the (n)th client and the first key of the (n+1)th client; and then re-executes the second step starting from the (n+1)th client.

7. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 5, characterized in that: In a multicast communication scenario, if the first client exits, the first and second steps are re-executed starting from the server.

8. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 5, characterized in that: In a multicast communication scenario, if the lth client, excluding the first client, exits, the l-1th client and the l+1th client become neighbors, where l = 2, …, n: all clients before the l-1th client retain their processing in the first step. Starting directly from the l-1th client, the l-1th client calculates the first key of the l-1th client based on its own service private key and the service public key of the l+1th client, updates the first key of the l-1th client in the HSM, takes out the first key of the l-2th client from the HSM, calculates the new first key of the l-1th client based on the first key of the l-2th client and the first key of the l-1th client, encrypts the new first key of the l-1th client and sends it to the l+1th client; the l+1th client receives the encrypted first key. The first key of the l-1th client is obtained by parsing it, the first key of the l-1th client in the HSM is updated, the first key of the l+1th client is taken out from the HSM, the new first key of the l+1th client is calculated based on the first key of the l-1th client and the first key of the l+1th client, and the new first key of the l+1th client is encrypted and sent to the next client, until the nth client calculates the group key of the nth client; the second step is repeated starting from the nth client.

9. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 2, characterized in that: Before calculating the encryption key for intra-domain communication, it also includes: Each DCU calculates the corresponding first parameter based on the public parameters required for the intra-domain communication encryption key distributed by the gateway and stores it in the HSM.

10. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 9, characterized in that: Each DCU and the ECU in the domain use the public parameters required for the intra-domain communication encryption key distributed by the gateway. The process of calculating the intra-domain communication encryption key includes: Each ECU randomly selects a subset based on the public parameters required for the intra-domain communication encryption key distributed by the gateway, calculates the corresponding second parameter based on the selected subset, and sends the second parameter to the DCU; After receiving the second parameter, the DCU calculates the intra-domain communication encryption key based on the second parameter, retrieves the first parameter from the HSM, and broadcasts the first parameter to each ECU in the domain; After receiving the first parameter, each ECU calculates the intra-domain communication encryption key according to the first parameter and the selected subset.

Images