Domain-oriented centralized electronic and electrical architecture vehicle system key management method

Abstract

The invention discloses a domain centralized electronic and electrical architecture-oriented vehicle system key management method. The method comprises the following steps that: each SOME / IP service executes a two-way service authority authentication mechanism based on a BLS short signature to complete authentication; dividing inter-domain communication into unicast communication and multicast communication according to the communication interface of each SOME / IP service; for unicast communication, when a vehicle system is powered on, a server and a client corresponding to each SOME / IP service negotiate a symmetric key; for multicast communication, a server and a client corresponding to each SOME / IP service carry out service handshake and establish a service group through publishing and subscribing of the service, and members of the service group negotiate and share a group key; and each DCU and the in-domain ECU calculate an in-domain communication encryption key according to the public parameters required by the in-domain communication encryption key distributed by the gateway. The method is suitable for an automobile domain centralized electronic and electrical architecture.

Description

Technical Field

[0001] The present invention belongs to the field of information security technology, and in particular relates to a vehicle system key management method for a domain-centralized electronic and electrical architecture. Background Art

[0002] As cars become more intelligent and connected, the communication security risks they face are also increasing. However, cars were originally designed without any security mechanisms in mind, making them vulnerable to various types of attacks, which may cause abnormal car functions or even serious accidents. As a popular in-vehicle network architecture, the domain-centralized architecture needs to deploy corresponding security mechanisms to ensure the communication security of the in-vehicle network.

[0003] The centralized electrical and electronic architecture of the automotive domain divides the car into several functional domains according to its functions. Each domain is centered on a high-performance domain controller unit (DCU). Different domains are connected through gateways and use automotive Ethernet with a higher transmission rate to exchange information. Different types of communication buses, such as CAN bus and LIN bus, can be used within each domain according to different needs. The electronic control unit (ECU) communicates with the DCU of the domain through these buses. The automotive Ethernet used for inter-domain communication uses the service-oriented architecture (SOA) and uses scalable service-oriented middleware over IP (SOME / IP) as its application layer communication protocol to achieve dynamic service-oriented communication. SOME / IP is based on the server-client communication mode and provides an abstract service-oriented interface for applications, aiming to provide a flexible, efficient, and service-oriented communication mechanism. SOME / IP supports functions such as service discovery, service registration, and message passing, greatly enhancing the ability of internal vehicle network interconnection and meeting complex vehicle communication requirements. There are significant differences in computing and storage resources between the DCU and ECU in the intra-domain communication network, and the complex data and control functions within the domain will be uniformly processed by the DCU. The ECU only needs to execute the instructions issued by the DCU, thereby achieving more efficient and centralized vehicle management.

[0004] While the above-mentioned in-vehicle architecture brings convenience to in-vehicle network communication, it also brings new challenges to the data transmission security of in-vehicle networks. The main manifestations are in three aspects: (1) The existing security protocols designed for traditional Ethernet cannot adapt to the communication scenarios of domain-centralized architecture. Classic Ethernet security protocols (such as IPsec, TLS, etc.) are not well compatible with in-vehicle communication protocols including SOME / IP, and will bring large communication overhead. (2) Existing research on the field of in-vehicle Ethernet is still relatively scarce, and most studies have not fully considered the characteristics of different services in the SOME / IP protocol. In addition, these studies have not proposed specific key management solutions. (3) At present, research on in-vehicle network security is mainly focused on the CAN bus, but these solutions are not well applicable to the resource imbalance between DCU and ECU under the domain architecture. Hu et al. proposed a Gatekeeper solution for IPsec, MACsec and TLS protocols in Ethernet, which can be used by the receiver to verify the identity of the sender. Iorio et al. assigned security levels to services according to the importance of the services, and different security levels correspond to different security solutions. However, none of the above solutions provide specific key management solutions. Cui et al. proposed a matrix-based key management scheme for the CAN bus, where 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 keys on the CAN bus. Shen et al. proposed a two-layer ECU group key management scheme, where ECUs in the same group share a group key. However, these schemes are not well suited to network structures with unbalanced resources within a domain under a domain-centralized electrical and electronic architecture.

[0005] In summary, how to achieve secure, efficient and fine-grained key management in the communication scenario of the centralized electronic and electrical architecture in the automotive domain is a challenging problem, and there is currently no good solution. Summary of the invention

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

[0007] An embodiment of the present invention provides a vehicle system key management method for a domain-centralized electronic and electrical architecture, the method comprising:

[0008] 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 authority authentication mechanism based on a BLS short signature to complete the authentication;

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

[0010] 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.

[0011] Beneficial effects of the present invention:

[0012] The vehicle system key management method for domain-centralized electronic and electrical architecture proposed in the present invention solves the problem of lack of efficient and fine-grained key management model in the communication scenario of automobile domain-centralized electronic and electrical architecture, and designs a key management scheme for different services of SOME / IP between domains and network structure with unbalanced resources within domains: the scheme includes two parts: inter-domain key management and intra-domain key management; in the cross-domain communication network, digital certificates are provided for SOME / IP services of all domain controllers, and service authority authentication is performed based on BLS short signatures, and a variety of communication mechanisms of SOME / IP services are fully considered, and a service-based key management scheme suitable for two types of communication, unicast and multicast, is proposed to ensure the confidentiality and integrity of communication; in the intra-domain communication network, for the network structure with unbalanced resources between DCU and ECU, it is proposed to let high-performance DCU undertake relatively more computing tasks, thereby alleviating the key management burden of ECU. The effectiveness of the method proposed in the present invention has been confirmed by a large number of experiments. In general, the present invention solves the problems of existing vehicle-mounted communication key management mechanisms, such as high communication overhead, coarse protection granularity, and difficulty in adapting to domain-centralized electronic and electrical architectures, improves the efficiency of key management, and provides security for vehicle-mounted communications.

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

[0014] Figure 1 It is a flow chart of a vehicle system key management method for a domain-centralized electronic and electrical architecture provided by an embodiment of the present invention;

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

[0016] Figure 3 It is a schematic diagram for explaining commonly used symbols involved in the key management process provided by an embodiment of the present invention;

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

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

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

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

[0021] Figure 8 It is a schematic diagram comparing the computational overhead of inter-domain group key negotiation in two cases where HSM is used and HSM is not used provided by an embodiment of the present invention;

[0022] Fig. 9 1 is a schematic diagram comparing the computational overhead of key agreement in the time domain when N=256 and when HSM is used and HSM is not used, provided in an embodiment of the present invention;

[0023] Fig.10 It is a schematic diagram comparing the computational overhead of intra-domain key agreement in two cases where HSM is used and HSM is not used and N=512, provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0024] The present invention is further described in detail below with reference to specific embodiments, but the embodiments of the present invention are not limited thereto.

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

[0026] 1. Diffie-Hellman key exchange algorithm

[0027] The Diffie-Hellman key exchange protocol relies on the difficulty of discrete logarithms, enabling two parties sharing keys to securely negotiate a shared key. The effectiveness of the Diffie-Hellman key exchange algorithm depends on the difficulty of computing discrete logarithms: Given a large prime number p and one of its primitive roots g, for a given A = g i mod p where (0 ≤ i ≤ p - 1), it is extremely difficult to compute i, while it is relatively easy to compute A given i.

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

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

[0030] (2) Assume two communicating parties, Alice and Bob, who wish to obtain a communication key. Then Alice selects a private key a < p and computes the public key using X = g a mod p. Communicator Alice stores a confidentially but makes X public to Bob. Similarly, communicator Bob also selects a random number b < p to compute the public key Y = g b mod p. Bob stores b confidentially so that Y can be publicly obtained by Alice.

[0031] Alice computes the key using K = Y a mod p. Similarly, Bob computes 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 Curves

[0033] The elliptic curves used in cryptography are elliptic curves over a finite field where p is a prime number. If a, b ∈ GF(p) and (x, y) ∈ GF(p) 2 , the following 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, and the elliptic curve satisfies the discriminant: Δ = -16(4a 3 +27b 2 )≠0;

[0036] E P 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), and P is not the inverse of Q, then P+Q=(x3,y3). The calculation process of x3 and y3 is as follows:

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

[0038]

[0039] 3. Bilinear pairing technology

[0040] Let p, q be large prime numbers and satisfy q|p-1. Represents the elliptic curve E p The cyclic additive group on (a,b), represents a cyclic multiplication group on the same elliptic curve, and and The order of is q. Then, we can define a bilinear map And satisfy the following properties:

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

[0042] (2) Non-degeneracy: existence Make Here express The unit element of .

[0043] (3) Computability: For any There is an efficient algorithm to calculate

[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. The signature result is just a point on the elliptic curve. Therefore, it is suitable for use in environments with limited bandwidth such as network communications.

[0047] Assume that user A wants to generate a BLS short signature for message m, then A first selects a random number As his own private key, and then calculate the public key Q = dP. Then, user A signs the message m with his own private key. A calculates a hash value H(m) for the message m, where The signed message is If user B wants to verify the signature The legitimacy of the Is it true? If true, it means the signature is legal; otherwise, the signature is illegal.

[0048] 5. Digital certificate technology

[0049] As a key component of the Internet communication security system, digital certificates are carefully designed digital identity identifiers that are designed to clearly define and distinguish the identity information of communication participants. They also embed detailed identity information of the applicant and its exclusive key. The certificate is officially issued by a highly authoritative CA (i.e., certificate authority) and is supplemented by the digital signature of the CA to ensure the authenticity of the certificate content and effectively resist any form of tampering and forgery. Digital certificates are based on the public key cryptography mechanism and strictly follow the logic of "private key signature, public key verification", providing security for the integrity of electronic file content. The public key cryptography mechanism makes digital certificates unique and private. Therefore, digital certificates can play the role of network identity identification and communication information encryption. This technology can strictly verify the true identity information of both parties to the transaction, ensure the confidentiality and authenticity of the electronic agreement, ensure that each step of the transaction process is non-repudiable, and give the electronic contract a legal formal effect. It is worth noting that this series of security measures is completely independent of the transaction content itself and has nothing to do with the transaction content.

[0050] Based on the above theoretical foundation, in order to solve the problem that the existing vehicle network key management solution is not suitable for the centralized electronic and electrical architecture of the automotive domain, please refer to Figure 1 The embodiment of the present invention provides a vehicle system key management method for a domain-centralized electronic and electrical architecture. The domain-centralized electronic and electrical architecture is as follows: Figure 2 For ease of reading, the commonly used symbols used in the present invention are as shown in Figure 3 The corresponding meanings are given as shown, and the corresponding methods include:

[0051] S10. 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 authority authentication mechanism based on the BLS short signature to complete the authentication.

[0052] Each vehicle will have a digital certificate distribution center (similar in function to CA) set up in the gateway when it leaves the factory, which is recorded as the gateway. The certificate is bundled with the VIN code (Vehicle Identification Number) of each vehicle, which is only legal in the current vehicle and cannot be used for the identity authentication process of other vehicle internal networks. At the same time, the key parameters and certificate initialization are performed every time the vehicle is powered on. The gateway will distribute 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 work is performed immediately after each vehicle is powered on. The vehicle system initialization mainly includes the secure startup of the in-vehicle hardware and the distribution of digital certificates and parameters required for key negotiation, which is only valid during the current vehicle system power-on period. In addition to each DCU having a digital certificate to prove its identity, the gateway also distributes a digital certificate for each SOME / IP service. These digital certificates contain the unique identification ID of the OME / IP service and the unique identification ID of the DCU.

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

[0055] (1) First, the client selects a random number As its temporary private key, and calculate the temporary public key Q c =aP, Each time an authentication is performed, the client will reselect a random number a. The client first calculates its unique identifier id c 、Temporary public key Q c and the current timestamp T c The hash value of c ||Q c ||T c ). Then use the private key s belonging to the service c Sign it to get Sign c =s c H(idc ||Q c ||T c ), the client will Sign c , Q c , P c and T c Sent to the server together, where P c Serve the public key for the client.

[0056] (2) The server receives the signature from the client. c After that, first verify the freshness of the message TT c <ΔT, where T is the newly generated timestamp. If the verification is successful, the subsequent authentication will continue. The server uses the equation e(Sign c ,P)=e(H(id c ||Q c ||T c ),P c )Verify Sign c If the equation is not true, the server will reject the client's application to use the service. Then the server selects a random number As its temporary private key, calculate the temporary public key Q s = dP. Every time an authentication is performed, the server will reselect a random number d. The server first calculates its unique identifier id s 、Temporary public key Q s and the current timestamp T s The hash value of s ||Q s ||T s ). Then use the private key s belonging to the service s Sign it to get Sign s =s s H(id s ||Q s ||T s ), the server will Sign s , Q s , P s and T s Sent to the client together, where P s It is the server's public key.

[0057] (3) The client receives the signature from the server s After that, first verify the freshness of the message TT s <ΔT, where T is the newly generated timestamp. If the verification is successful, the subsequent authentication will continue. The client verifies the equation e(Sign s ,P)=e(H(id s||Q s ||T s ),P s ) to judge Sign s If the equation is not true, the client believes that the server does not have the authority to provide the service. Otherwise, the client and the server have achieved two-way service authority authentication and can carry out subsequent communication.

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

[0059] In the embodiment of the present invention, all components in the vehicle system are equipped with corresponding HSM (Hardware Security Module). The HSM specification (EVITAHSM) divides HSM into three levels, namely Full, Medium, and Light. The Full-level HSM provides the greatest functionality and security, and is mainly used for secure communication of V2X; for the gateway and each DCU, the Medium-level HSM can meet their needs, and it can support secure storage of data; for each ECU, we are equipped with a Light-level HSM.

[0060] SOME / IP has three different communication interfaces, namely Method, Field, and Event. Generally speaking, during the communication process of each SOME / IP service, 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 triggers the server to send the corresponding message to all clients subscribed to the specific event under a specific event, using multicast communication, so the inter-domain key management is divided into two scenarios: unicast and multicast.

[0061] Next, the two inter-domain key managements of unicast and multicast are introduced in detail.

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

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

[0064] In the unicast communication scenario, the server and client need to authenticate the service permissions first. After the service authentication is successful, the server and client use the random numbers d and a selected during the service authentication and the temporary public key Q of the other party respectively. c and Q s Negotiate a symmetric key for subsequent communications.

[0065]

[0066] Each time the vehicle is powered on, the server and client will re-authenticate the service and negotiate a new symmetric key, and the symmetric key will be used throughout the operation 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 authenticate the service permissions first. After authentication, the server and client can perform service handshake and set up a service group through service publishing and subscription. Service group members negotiate a shared group key for subsequent communication. In order to simplify the understanding of the key management scheme, the description of the specific message transmission process is omitted. By default, all messages are transmitted after encryption, which can ensure the source, authenticity and integrity of the message.

[0069] After the service group is established, the server will send a message to all clients in the group. i ) is sorted, 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. The list is updated only when the client membership changes.

[0070] Before the service group members in the multicast communication of the embodiment of the present invention negotiate to share the group key, the method 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 The 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) Use your own service private key s j and client j-1 The 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 the 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 in the embodiment of the present invention includes:

[0077] The first step is to execute the process as follows Figure 4As shown in the left part, it includes: starting from the server, the server calculates the first key of the server according to its own service private key and the service public key of the first client, stores the first key of the server in the HSM, encrypts the first key of the server and sends it to the first client; the first client receives the encrypted first key of the server and parses it to obtain the first key of the server, stores the first key of the server in the HSM, takes out the first key of the first client from the HSM, calculates the new first key of the first client according to the first secret of the server and the first key of the first client, encrypts the new first key of the first client and sends it to the second client; the i-th client receives the encrypted new first key of the i-1-th client and parses it to obtain the new first key of the i-1-th client, stores the first key of the i-1-th client in In the HSM, i=2,…,n-1, n represents the number of clients in the service group, and the first key of the i-th client is taken out from the HSM, and the new first key of the i-th client is calculated according to the first key of the i-th client and the new first key of the i-1-th client, and the new first key of the i-th client is encrypted and sent 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 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, stores the first key of the n-1-th client in the HSM, and takes out the first key of the n-th client from the HSM, and calculates the group key of the n-th client according to the first key of the n-1-th client and the new first key of the n-1-th client;

[0078] The second step is to execute the process 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 according to 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 according to the new second key of the j+1th client and the first key of the jth client. The group key of the jth client is calculated based on the second key of the jth client and the first key of the jth client, and the new second key of the jth client is encrypted and sent to the j-1th 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, and calculates the group key of the server based on the new second key of the first client and the first key of the server. 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 As 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 key IK1 of the first client from the HSM, IK1 = getFromHSM (key1), according to the first key IK s ' and the first key IK1 of the first client to calculate the new first key IK1 of the first client' = IK s '⊕IK1, encrypt the new first key IK1' of the first client and send it to the second client with m1={IK1'};

[0082] Next, the client i (i=2,…,n-1) receives m i-1 After that, parse to get the client i-1 New first key IK i ' -1 , for subsequent key updates, the client i IK i ' -1 Store it securely, that is, 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 Calculation client i New first key IK i '=IK i ' -1 ⊕IK i .client i M i ={IK i '}Send to the client securely i+1 Here, the value of i starts from 2 because the processing process of client1 has been explained 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, the client n IK n ' -1 Store it securely, that is, 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 As 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) received from client j+1 Sent m j ' +1 After that, parse to get the client j+1 New second key MK j+1 , and fetch the stored second key PK from the HSMj-1 and the first key IK j , namely PK j-1 =getFromHSM(key' j ), IK j =getFromHSM(key j ). According to MK j+1 and IK j You can calculate the client j The group key KG = MK j+1 ⊕IK j , according to KG group key and PK j-1 Calculation client j New MK j =(KG⊕PK j-1 ), client j Will m' j ={MK j}Send to the client securely j-1 , until the first client client1 encrypts the first client's new second key MK1 and sends m1'={MK1} to the server.

[0087] After receiving m1', the server parses and obtains MK1, and retrieves the first key IK stored in the HSM s , according to MK1 and IK s The group key KG = MK1⊕IK can be calculated s At this point, the group key negotiation is completed, and all members of the service group share the group key KG.

[0088] Furthermore, in the multicast communication scenario of the embodiment of the present invention, 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 takes out the first key of the n-1th client from the HSM, and 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, and calculates the nth client based on the first key of the n-1th client and the first key of the n+1th client. The client obtains a new first key, encrypts the new first key of the nth client and sends it to the n+1th client; the n+1th client receives the encrypted first key of the nth client and parses it 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 based on its own service private key and the service public key of the server, stores the first key of the n+1th client in the HSM, calculates the group key of the nth client based on the first key of the nth client and the first key of the n+1th client; and continues to re-execute the second step from the n+1th client. It can be seen that for the case of a newly joined client, since the newly joined client is added to the last position of the service group by default, all original clients except the last client keep the first step execution process unchanged, and the last client and the newly joined client continue the first step execution process of the above-mentioned intermediate client and the last client. Since the newly joined client will affect the negotiation of the shared group key, the second step execution process is re-executed starting from the newly joined client. The specific process refers to the specific process of negotiating the shared group key between service group members in the above-mentioned multicast communication, which will not be repeated here.

[0089] Furthermore, in the multicast communication scenario of the embodiment of the present invention, if the first client exits, the first step execution process and the second step execution process are re-executed starting from the server. Since the exit of the client will affect the negotiation of the shared group key, in the case where the first client exits, the second client acts as the new first client and re-executes all processes starting from the server. For the specific process, refer to the specific process of negotiating the shared group key between the service group members in the multicast communication, which will not be repeated here.

[0090] Furthermore, in the multicast communication scenario of the embodiment of the present invention, if the l-th client except the first client exits, the l-1th client and the l+1th client become neighbors, l=2,…,n: all clients before the l-1th client retain their respective 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, and calculates the 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. The new first key is encrypted and sent to the l+1th client after the new first key of the l-1th client is received by the l+1th client; the l+1th client receives the encrypted first key of the l-1th client and parses it to obtain the first 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+1th client from the HSM, calculates the new first key of the l+1th client according to the first key of the l-1th client and the first key of the l+1th client, and encrypts the new first key of the l+1th client and sends it to the next client, until the nth client calculates the group key of the nth client; and continues to re-execute the second step from the nth client. Different from the case where the first client exits, when the intermediate client exits, the client before the intermediate client does not need to re-execute the first step, but only needs to start from the previous client of the intermediate client, and continue the first step of the intermediate client and the last client, and then continue the second step from the last client. For the specific process, please refer to the specific process of negotiating the shared group key between the service group members in the multicast communication, which will not be repeated here.

[0091] It should be noted here that the server will not exit by default, because if the server exits, it means that the SOME / IP service will stop being provided, and the group key will no longer be needed.

[0092] The embodiment of the present invention greatly reduces the computational complexity by designing an offline-online combined computing solution based on HSM.

[0093] The security analysis of the process of negotiating and sharing a group key between service group members in the multicast communication proposed in the embodiment of the present invention is as follows:

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

[0095] The proposed process of negotiating and sharing group keys between service group members in multicast communication can resist man-in-the-middle attacks against SOME / IP services. Both the server and the client need to undergo service authority authentication before providing or using SOME / IP services. Only legitimate DCUs can obtain the corresponding service certificates. Attackers cannot obtain the corresponding service certificates, nor can they obtain service certificates of other DCUs from the HSM. Therefore, attackers cannot pass the service authority authentication and cannot participate in subsequent key negotiation and communication.

[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 and can only obtain the group key after joining. Therefore, the new member cannot know the previous communication information, which can ensure forward security.

[0098] (3) Backward safety

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

[0100] (4) Collusion attack

[0101] The proposed process of negotiating and sharing group keys between service group members in multicast communication can resist collusion attacks on the SOME / IP service group key. Collusion attacks refer to multiple members who have left the group cooperating to try to obtain the updated group key. Since the group member list is updated every time there is a member change, all members no longer use the previous key. At the same time, the key IK involved in the key negotiation i The service private key of the members is required for calculation. Members who leave the group cannot infer the service private key of the group members through the information they share, so attackers cannot obtain the current group key through collusion attacks.

[0102] S30. Each DCU and the ECU in the domain calculate the intra-domain communication encryption key according to the public parameters required for 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] Generally, the computing power of DCU and ECU in a vehicle system facing a domain-distributed electronic and electrical framework is equivalent. In order to cope with the scenario where the computing power of DCU in a vehicle system facing a domain-centralized electronic and electrical framework is greater than the computing power of ECU in the domain, an embodiment of the present invention proposes that each DCU and 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 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 it 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, and 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, and calculates the corresponding second parameter based on the selected subset, and sends the second parameter to the DCU; after the DCU receives the second parameter, it calculates the intra-domain communication encryption key based on the second parameter, and takes out the first parameter from the HSM, and broadcasts the first parameter to each ECU in the domain; after each ECU receives the first parameter, it 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 by 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 the subset S. The ECU will time stamp T ECU and K ECU Signed with your own service private key And will include K ECU , and TECU The message is sent securely to DCU.

[0107] (2) DCU selects a random number And calculate the first parameter Then according to the second parameter K ECU Calculate the encryption key for intra-domain communication The DCU can calculate the first parameter K in advance in the HSM when it is offline. DCU The value of and stored in the HSM, that is, storeToHSM(ID sk , K DCU ), and take out the first parameter K at the beginning of the negotiation DCU , that is, K DCU =getToHSM(ID sk ); After receiving the message sent by ECU, parse out the second parameter K ECU , DCU can be based on the second parameter K ECU Calculate the encryption key for intra-domain communication Finally, DCU timestamps T DCU and the first parameter K DCU Signed with your own service private key And will include K DCU , and T DCU The message is securely broadcast to every ECU in the domain.

[0108] (3) Each ECU receives the message sent by DCU and parses the first parameter K DCU , according to the first parameter K DCU and the respective selected subset S to calculate the corresponding intra-domain communication encryption key

[0109]

[0110] At this point, the key negotiation is completed, and the DCU and ECU share the symmetric intra-domain communication encryption key SK. DCU They are exactly the same, but because the set S selected by each ECU is different, 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 a domain-centralized electronic and electrical architecture provided by an embodiment of the present invention, the following experiment is performed for verification.

[0112] 1. Experimental environment:

[0113] The embodiment of the present invention is an experiment carried out on a computer (i5-13400F@2.5GHz, 16G memory, windows11), and C++ is used to simulate cryptographic primitives. Specifically, the cryptographic libraries used are libpbc and openssl.

[0114] 2. Experimental results:

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

[0116] Before the formal inter-domain key negotiation, the server and client need to authenticate the service permissions. The server and client need to perform the operations of generating, signing, and verifying the temporary public and private keys, respectively. The rest of the low-latency calculations are ignored. In the signing phase, we selected the SHA-256 hash function. The computational overhead of the DCU is denoted as T auth ≈18.6ms. The computational overhead of the authentication phase is relatively large, but since service authentication is performed before communication, and almost all service authentication is completed when the car is powered on, it does not affect the real-time communication of SOME / IP. During unicast key negotiation, the DCU only needs to perform a point multiplication operation on the elliptic curve once, and the computational overhead is T sy ≈0.712ms. Figure 8 The computational overhead of inter-domain multicast key negotiation with and without HSM is demonstrated for different numbers of requesting clients. The experimental results show that the computational overhead of key negotiation is significantly reduced after using HSM. While providing the same level of security protection, the use of HSM can reduce the computational time by about 88%. Since the number of service subscription requests in each vehicle at the same time usually does not exceed 100, and this order of magnitude is a normal communication delay in Ethernet communication, the additional overhead will not affect the real-time performance of vehicle-mounted communications.

[0117] Fig. 9 and Fig.10 The computational overhead of intra-domain negotiation is shown for N = 256 and N = 512. We can see that the computational overhead increases with the increase of N and k, and the performance is significantly improved when we use HSM for offline calculation of DCU modular exponentiation operation. When k = 32, using HSM can reduce the computation time by approximately 37.12% and 44.66%, respectively.

[0118] Communication overhead (unit: byte): The payload required to exchange data during key negotiation. Table 1 shows the communication overhead of each stage in the method proposed in the present invention. It can be seen from Table 1 that since the negotiation of inter-domain symmetric keys depends on the temporary private key generated during service authentication, inter-domain symmetric key negotiation does not require additional communication overhead. The communication overhead of inter-domain group key negotiation is related to the number n of service group members. As the number of group members increases, the communication overhead will also increase. However, since the number of clients participating in the service is limited, the communication overhead of group key negotiation will not increase indefinitely. The communication overhead of intra-domain key negotiation is related to the number N of selected random elements and the order q of the cyclic group. The q selected in the experiment is a 128-bit prime number. It can be seen from Table 2 that the communication overhead of ECU is independent of the size of N, and the communication overhead of DCU is related to the size of N. However, in the method proposed in the present invention, DCU only needs to broadcast the key negotiation message once, that is, the communication overhead of DCU is independent of the number of ECUs and will not increase due to the increase in the number of ECUs in the domain.

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

[0120]

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

[0122]

[0123] Storage overhead (unit: byte): The storage cost of each DCU and ECU when performing key negotiation. Table 3 shows the additional storage overhead when each DCU performs a service authority authentication, unicast key negotiation and multicast key negotiation in the inter-domain key negotiation model. Table 4 shows the storage overhead of the intra-domain key negotiation model. The q selected in the experiment is a 128-bit prime number. It can be seen from Tables 3 and 4 that 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 the set S and will not be affected by N.

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

[0125]

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

[0127]

[0128] Compared with the existing key management scheme for automotive Ethernet, the key management scheme proposed in the present invention can provide more fine-grained protection for the SOME / IP communication protocol; compared with the existing key management scheme for the CAN bus, the present invention takes into account the network structure with unbalanced resources on the intra-domain bus, allowing the high-performance DCU to bear more key negotiation overhead, alleviating the burden on the ECU. At the same time, the present invention uses HSM to reduce computing overhead and can be better compatible with 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 proposed in the embodiment of the present invention solves the problem of lack of efficient and fine-grained key management model in the communication scenario of the automobile domain-centralized electronic and electrical architecture, and designs a key management scheme for different services of SOME / IP between domains and the network structure with unbalanced resources within the domain: the scheme includes two parts: 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, and service authority authentication is performed based on the BLS short signature, and the various communication mechanisms of the SOME / IP service are fully considered, and a service-based key management scheme suitable for both unicast and multicast communication types is proposed to ensure the confidentiality and integrity of the communication; in the intra-domain communication network, for the network structure with unbalanced resources between DCU and ECU, it is proposed to let the high-performance DCU take on relatively more computing tasks, thereby alleviating the key management burden of the ECU. The effectiveness of the method proposed by the present invention has been confirmed by a large number of experiments. In general, the present invention solves the problems of existing vehicle-mounted communication key management mechanisms, such as high communication overhead, coarse protection granularity, and difficulty in adapting to domain-centralized electronic and electrical architectures, improves the efficiency of key management, and provides security for vehicle-mounted communications.

[0130] In the description of the present invention, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0131] Although the present invention is described herein in conjunction with various embodiments, in the process of implementing the claimed invention, those skilled in the art may understand and implement other variations of the disclosed embodiments by viewing the specification and its drawings. In the specification, the word "comprising" does not exclude other components or steps, and "a" or "one" does not exclude multiple situations. Certain measures are recorded in different embodiments, but this does not mean that these measures cannot be combined to produce good results.

[0132] The above contents are further detailed descriptions of the present invention in combination with specific preferred embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.

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 authority authentication mechanism based on a BLS short signature to complete the authentication; According to the communication interface of each SOME / IP service, the inter-domain communication is divided into unicast communication and multicast communication; for the inter-domain key management of unicast communication, when the vehicle system is powered on, the server and the client corresponding to each SOME / IP service negotiate a symmetric key to perform inter-domain communication according to the symmetric key; for the inter-domain key management of multicast communication, the server and the client corresponding to each SOME / IP service perform a service handshake and establish a service group through service publishing and subscription, and the service group members negotiate a shared group key to perform inter-domain communication through 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; wherein, the HSM equipped with the gateway is a Medium-level HSM; the HSM equipped with each DCU is a Medium-level HSM; and the HSM equipped with 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 that subscribe 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: Except for the server, each client in the service group calculates its own first key in the HSM equipped with it according to its own service private key and the service public key of the next client, and stores it in the HSM equipped with it; among them, the last client calculates the first key of the last client in the HSM equipped with it according to its own service private key and the service public key of the server, and stores it in the HSM equipped with it; Starting from the last client in the service group, each client calculates its own second key in the HSM equipped with it according to 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 according to 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 between service group members in multicast communication includes: The first step execution process includes: starting from the server, the server calculates the first key of the server according to its own service private key and the service public key of the first client, stores the first key of the server in the HSM, encrypts the first key of the server and sends it to the first client; the first client receives the encrypted first key of the server and parses it to obtain the first key of the server, stores the first key of the server in the HSM, and takes out the first key of the first client from the HSM, calculates the new first key of the first client according to the first secret of the server and the first key of the first client, encrypts the new first key of the first client and sends it to the second client; the i-th client receives the encrypted new first key of the i-1-th client and parses it to obtain the new first key of the i-1-th client, stores the first key of the i-1-th client in In the HSM, i=2,…,n-1, n represents the number of clients in the service group, and the first key of the i-th client is taken out from the HSM, and the new first key of the i-th client is calculated according to the first key of the i-th client and the new first key of the i-1-th client, and the new first key of the i-th client is encrypted and sent 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 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, stores the first key of the n-1-th client in the HSM, and takes out the first key of the n-th client from the HSM, and calculates the group key of the n-th client according to the first key of the n-1-th client and the new first key of the n-1-th client; The second step execution process 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 according to 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 according to 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 according to 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 according to the new second key of the first client and the first key of the server, and now the group key negotiation within the service group is completed, and 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: If a new client joins the multicast communication scenario, 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 takes out the first key of the n-1th client from the HSM, and 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+1th client receives the encrypted new first key of the nth client and parses it 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 based on its own service private key and the service public key of the server, stores the first key of the n+1th client in the HSM, calculates the group key of the nth client based on the first key of the nth client and the first key of the n+1th client; and continues to re-execute the second step from the n+1th client.

7. The vehicle system key management method for a domain-centralized electronic and electrical architecture according to claim 5, characterized in that: In the 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 the multicast communication scenario, if the lth client other than the first client exits, the l-1th client and the l+1th client become neighbors, l = 2, ..., n: all clients before the l-1th client retain their respective 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 of the l-2th client and the first key of the l-1th client. The first key of the l-1th client is obtained by parsing, 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 according to 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 continued from the nth client and the execution process is re-executed.

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 calculate 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 according to the public parameters required for the intra-domain communication encryption key distributed by the gateway, calculates a corresponding second parameter according to 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 according to the second parameter, takes out 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