Lightweight SOME / IP authentication method based on physical unclonable function

Abstract

The invention discloses a lightweight SOME / IP authentication method based on a physical unclonable function. The method comprises the steps that a PUF challenge response pair of a vehicle-mounted ECU is extracted, and ECU registration is completed; end-to-end authentication without the participation of the gateway is realized between the ECUs by using a pre-stored secret value; session keys are respectively negotiated for the SOME / IP request response and the publish-subscribe mode based on an ECDH algorithm; and carrying out authentication encryption on the SOME / IP message in combination with an STROBE cryptographic framework. According to the invention, the physical uniqueness of the PUF is utilized to realize key-free storage, the resource consumption of the ECU is reduced, the decentralized design avoids the single-point fault of the gateway, unicast and multicast communication is supported at the same time, attacks such as man-in-the-middle and replay can be effectively resisted, and the real-time and security requirements of the vehicle-mounted Ethernet are met.

Description

Technical Field

[0001] This invention relates to the field of vehicle Ethernet communication security technology, specifically to a lightweight SOME / IP authentication method based on physically unclonable functions. Background Technology

[0002] Currently, the global automotive industry is undergoing a major technological transformation, with automobiles evolving from "transportation tools" to "intelligent mobile terminals," leading to an exponential increase in the demand for in-vehicle data transmission. This trend places stringent requirements on automotive communication networks, especially in terms of high bandwidth and low latency. Traditional buses face two key challenges: first, security becomes increasingly vulnerable as network scales up; second, they cannot support the high bandwidth demands of modern sensing systems such as in-vehicle cameras and radar, which have become the core of sensing tasks. Automotive Ethernet, with its standardized protocols, high scalability, and lightweight advantages, has become the preferred choice for next-generation in-vehicle networks. In addition to automotive Ethernet, the rise of SOA has spurred the demand for new communication middleware. Unlike traditional signal-oriented communication (such as CAN) which relies on static predefined messages, SOA emphasizes dynamic service discovery and on-demand communication. To meet this need, SOME / IP emerged. As an application layer protocol for automotive Ethernet, SOME / IP is a middleware solution specifically designed for the needs of automotive electronic systems. It has been incorporated into the AUTOSAR standard and possesses strong portability, supporting multiple devices and operating systems.

[0003] However, the SOME / IP protocol faces multiple security risks due to the lack of native security mechanisms. One of the most common threats is MITM (Mixed Message-to-Method), where attackers can forge messages or hijack session identifiers to tamper with vehicle control commands or eavesdrop on sensitive data. Furthermore, service spoofing attacks allow malicious entities to broadcast fake service instances across the network, tricking clients into connecting to unauthorized nodes; attackers may also use unauthenticated communication requests to initiate malicious subscriptions, leading to server resource exhaustion or interception of critical event notifications. Therefore, it is urgent to design effective authentication mechanisms to ensure the integrity and reliability of SOME / IP communication.

[0004] The design of the SOME / IP middleware authentication scheme faces several challenges. First, the multicast nature of SOME / IP means that existing authentication solutions typically rely on GECUs to distribute certificates and private keys, increasing communication and storage overhead. Second, the large number of vehicle ECUs results in key storage occupying a significant amount of space, and the number of keys that each ECU needs to store increases with the total number of ECUs. Given the limited computing resources and memory of ECUs, maintaining a large keystore is not feasible.

[0005] For example, Chinese patent application CN114389812A discloses a lightweight privacy-protected batch authentication method for vehicle networking based on PUF. This technical solution relies on a single Trusted Center (TA), has poor resilience, and is only suitable for batch authentication in vehicle networking (V2X), failing to meet the needs of point-to-point communication and multicast within the vehicle's ECU. Chinese patent application CN119602956A discloses a lightweight in-vehicle network identity authentication and key negotiation method based on PUF, which relies on a domain controller (DC) to centrally process keys, has a single point of failure risk, and is not compatible with the SOME / IP protocol, resulting in an incomplete protection mechanism. Summary of the Invention

[0006] Purpose of the Invention: The purpose of this invention is to address the shortcomings of existing technologies and provide a lightweight SOME / IP authentication method based on physically unclonable functions. This invention adopts a decentralized design, and end-to-end authentication of the ECU does not require the participation of a gateway, thus avoiding the risks of centralized nodes. It is specifically adapted to the request-response and publish-subscribe patterns of SOME / IP, integrates the STROBE framework to enhance transmission security, and uses PUF to achieve keyless storage, reducing ECU resource consumption. It also supports unicast / multicast and has advantages in security, compatibility, and lightweight design.

[0007] Technical solution: The present invention provides a lightweight SOME / IP authentication method based on physically unclonable functions, comprising the following steps:

[0008] Step (1), System initialization phase: The vehicle manufacturer extracts challenge response pairs from the on-chip PUF of the vehicle client ECU. The challenge response codes (CRPs) are encrypted and stored on the vehicle manufacturer's cloud server; the gateway electronic control unit (GECU) periodically synchronizes and updates the CRPs from the cloud; the onboard client ECU registers with the gateway electronic control unit (GECU), obtains and stores the secret value of the communicating party; the specific method is as follows:

[0009] Step (1-1): The vehicle manufacturer inputs a random challenge into the ECU. Generate response Collect CRPs and encrypt them before uploading them to a cloud server (to store CRPs for authentication).

[0010] Steps (1-2): GECU periodically downloads and updates CRPs from the cloud;

[0011] Steps (1-3): GECU selects the client Challenges and client Challenges Calculated by fuzz extractor Auxiliary data and private information , and Auxiliary data and private information , Generate random numbers And send message tuples Message tuple To the corresponding ECU;

[0012] Steps (1-4) Calculate the response with noise. Calculate private information using noise cancellation functions Hash value 1. Randomly select a random number And send message tuples To GECU, Generate hash values ​​by performing similar operations And randomly select a random number y to form a message tuple. And send it to GECU;

[0013] Steps (1-5), GECU verification Then, calculate the hash value. Hash value XOR value Hash value =H( ), hash value =H( XOR value encrypt to generate ciphertext ciphertext ;

[0014] Steps (1-6) Receive ciphertext Decryption later and If the extracted random number matches the random number sent during this registration process, then... Stored as a secret value Perform similar operations and store ;

[0015] Step (2), the authentication phase, initiating authentication Generate random numbers Send a message containing identity information, challenge value, and authentication request to ; After verification, private information is recovered using PUF and a fuzz extractor, the response is encrypted and returned; A secondary response is generated after successful verification. Verification completes two-way authentication;

[0016] Step (3), Session Key Negotiation Phase, Request-Response Mode, and Calculate the session key using the ECDH algorithm. In publish-subscribe mode, the server ECU (referring to the vehicle client ECU that provides service data) negotiates the session key with the client, encrypts the multicast group key, and distributes it.

[0017] Step (4), the secure communication phase, involves the client ECU and the server ECU (referring to the onboard client ECU that provides service data) sharing a session key. It can use a key pair for secure SOME / IP message exchange; an enhanced scheme based on the STROBE protocol framework authenticates and encrypts the payload, and injects the SOME / IP header fields as associated data, tightly binding the ciphertext with the header fields; and encrypts the payload through its symmetric encryption module to ensure secure communication after authentication.

[0018] In this invention, the vehicle-mounted ECU may be a client ECU or a server ECU under different communication conditions.

[0019] Furthermore, the specific process of the authentication phase in step (2) is as follows:

[0020] Step (2-1) Generate random numbers ,send to ;

[0021] Step (2-2) take over After receiving the message, first check Whether it is a registered client for its SOME / IP service, i.e., verifying whether it is stored in local memory. , and ;

[0022] If it exists, extract it from the corresponding secret value. , and ; Calculate the response Private information , Key Randomly select a random number Generate ciphertext and random numbers And send message tuples to ;

[0023] Steps (2-3) calculate , , Decryption and verification Then, calculate the hash value. Key Randomly select a random number Generate ciphertext And send to ;

[0024] Steps (2-4) Calculate hash value ,by Decrypt the key from Received ,get and .like and If matched, then Successful authentication .

[0025] Furthermore, in step (3) of the session key negotiation phase, the client ECU and the server ECU respectively decrypt in the request-response mode. = and Obtain the other party's session public key parameter and ; through their respective and Perform elliptic curve scalar multiplication, complete ECDH key exchange, and generate session keys. ;

[0026] The specific process under the publish-subscribe model is as follows:

[0027] Step (3-1): The client ECU initiates a service discovery request of type FindService (0x00) to the server ECU via the SOME / IP-SD protocol;

[0028] Step (3-2): The server ECU generates a corresponding session key for each client ECU via ECDH. The session key is then used to encrypt the group key subsequently used for multicast, and a message authentication code is attached for integrity verification.

[0029] Step (3-3): The server ECU encapsulates the ciphertext and message authentication code in a SOME / IP-SD message payload of type OfferService (0x01) based on the message identifier and request identifier, and sends it to the corresponding client ECU.

[0030] Furthermore, the specific process of step (4), the secure communication phase, is as follows:

[0031] Step (4-1): The two communicating parties use the session key. As the basic encryption key, a globally unique random number is generated for each SOME / IP message transmission as a session identifier to resist replay attacks; the receiver can resist replay attacks by verifying the timeliness or randomness of the random number.

[0032] Step (4-2): In the authentication encryption mode, use the protocol header and other immutable metadata as the associated data input; encrypt the plaintext data to generate ciphertext, and calculate the message authentication code based on the ciphertext and associated data.

[0033] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0034] (1) This invention addresses the problem of high key storage overhead and complex management in existing SOME / IP authentication schemes in multi-ECU scenarios by proposing a PUF-based SOME / IP security protection scheme to achieve lightweight key generation and distribution. By utilizing the inherent key derivation and key-free characteristics of PUF, the key storage requirements of ECUs are effectively reduced.

[0035] (2) In order to eliminate the high dependence of the SOME / IP authentication process on GECU and the resulting single point of failure and performance bottleneck problem, the present invention designs a mechanism independent of GECU, supports point-to-point authentication and group key distribution in both SOME / IP communication modes, and provides source authentication for both SOME / IP unicast and multicast communication.

[0036] (3) Based on the ROR model and detailed security analysis, the present invention provides a formal proof of the security of the scheme; the experimental results verify the good performance of the scheme in ensuring the security of SOME / IP communication. Attached Figure Description

[0037] Figure 1 This is a system model diagram of the present invention;

[0038] Figure 2 This is a flowchart of the system initialization phase in the embodiment;

[0039] Figure 3 This is a flowchart of the authentication phase in the embodiment;

[0040] Figure 4 This is a comparison chart of computational overhead in the examples;

[0041] Figure 5 This is a comparison chart of communication overhead in the embodiments. Detailed Implementation

[0042] The technical solution of the present invention will be described in detail below, but the scope of protection of the present invention is not limited to the embodiments described.

[0043] As a core application layer protocol, SOME / IP is widely used in service discovery and remote procedure call implementation in automotive Ethernet. With the deepening of SOME / IP research, researchers have found that its protocol specification lacks any embedded native security mechanisms, lacks authentication and message integrity protection, and is vulnerable to attackers exploiting this vulnerability to forge services or hijack communications. Therefore, it is necessary to propose a novel PUF-based authentication scheme to enhance the security of SOME / IP communication.

[0044] like Figure 1 As shown, this invention mainly involves the following three participating entities: the vehicle manufacturer's cloud server, the GECU, and the ECU. The vehicle manufacturer's cloud server is a trusted entity in the model, possessing sufficient storage capacity. Since the in-vehicle gateway cannot store a large number of CRPs, the vehicle's CRPs are stored in the vehicle manufacturer's cloud server, which periodically updates the CRPs to the in-vehicle gateway. The GECU, as a trusted entity within the vehicle, is responsible for registering all ECUs participating in in-vehicle communication. It also acts as a bridge between the vehicle manufacturer's cloud server and the in-vehicle ECUs, storing the in-vehicle ECUs' CRPs and periodically requesting updates from the vehicle manufacturer's cloud server. Each ECU is equipped with a PUF (Programmable Activated Function), capable of performing storage and related cryptographic calculations. Because ECUs are vulnerable to attacks, they are considered untrusted devices; therefore, they must register with the gateway and perform two-way authentication before communication.

[0045] This invention embeds lightweight security features into the standard SOME / IP communication process: During system initialization, challenge-response pairs (CRPs) are extracted from the on-chip PUF of the vehicle ECU. Due to limited GECU resources, these CRPs are encrypted and stored on the vehicle manufacturer's cloud server, and periodically synchronized with the GECU, reducing the security risks of directly storing encryption keys in the ECU. According to the system's predefined communication configuration, each ECU obtains the secret value of the target communication node by interacting with the GECU and stores it locally. During the authentication phase, ECUs use the pre-stored secret value to achieve end-to-end bidirectional authentication without the need for GECU involvement, forming a decentralized, lightweight authentication process that significantly reduces computational and storage overhead. After successful authentication, the communicating parties establish a symmetric session key, and the confidentiality and integrity of SOME / IP communication are ensured using the Strobe protocol framework.

[0046] like Figures 1 to 3 As shown, this embodiment uses a lightweight SOME / IP authentication method based on physically unclonable functions, which includes the following steps:

[0047] Step (1), System initialization phase: The vehicle manufacturer extracts challenge response pairs from the on-chip PUF of the vehicle client ECU. The challenge response codes (CRPs) are encrypted and stored on the vehicle manufacturer's cloud server; the gateway electronic control unit (GECU) periodically synchronizes and updates the CRPs from the cloud; the onboard client ECU registers with the gateway electronic control unit (GECU), obtains and stores the secret value of the communicating party; the specific method is as follows:

[0048] Step (1-1): The vehicle manufacturer inputs a random challenge into the ECU. Generate response Collect CRPs and encrypt them before uploading them to a cloud server;

[0049] Steps (1-2): GECU periodically downloads and updates CRPs from the cloud;

[0050] Steps (1-3): GECU selects the client Challenges and client Challenges Calculated by fuzz extractor Auxiliary data and private information , and Auxiliary data and private information , Generate random numbers And send message tuples Message tuple To the corresponding ECU;

[0051] Steps (1-4) Calculate the response with noise. Calculate private information using noise cancellation functions Hash value 1. Randomly select a random number And send message tuples To GECU, Generate hash values ​​by performing similar operations And randomly select a random number y to form a message tuple. And send it to GECU;

[0052] Steps (1-5), GECU verification Then, calculate the hash value. Hash value XOR value Hash value =H( ), hash value =H( XOR value encrypt to generate ciphertext ciphertext ;

[0053] Steps (1-6) Receive ciphertext Decryption later and If the extracted random number matches the random number sent during this registration process, then... Stored as a secret value Perform similar operations and store ;

[0054] Step (2), the authentication phase, initiating authentication Generate random numbers Send a message containing identity information, challenge value, and authentication request to ; After verification, private information is recovered using PUF and a fuzz extractor, the response is encrypted and returned; A secondary response is generated after successful verification. Verification completes two-way authentication;

[0055] Step (3), Session Key Negotiation Phase, Request-Response Mode, and Calculate the session key using the ECDH algorithm. In publish-subscribe mode, the server ECU negotiates session keys for clients, encrypts multicast group keys, and distributes them.

[0056] Step (4), the secure communication phase, involves the client ECU and the server ECU sharing a session key. It can use a key pair for secure SOME / IP message exchange; an enhanced scheme based on the STROBE protocol framework authenticates and encrypts the payload, and injects the SOME / IP header fields as associated data, tightly binding the ciphertext with the header fields; and encrypts the payload through its symmetric encryption module to ensure secure communication after authentication.

[0057] The specific process of step (2) authentication in this embodiment is as follows:

[0058] Step (2-1) Generate random numbers ,send to ;

[0059] Step (2-2) take over After receiving the message, first check Whether it is a registered client for its SOME / IP service, i.e., verifying whether it is stored in local memory. , and ;

[0060] If it exists, extract it from the corresponding secret value. , and ; Calculate the response Private information , Key Randomly select a random number Generate ciphertext and random numbers And send message tuples to ;

[0061] Steps (2-3) calculate , , Decryption and verification Then, calculate the hash value. Key Randomly select a random number Generate ciphertext And send to ;

[0062] Steps (2-4) Calculate hash value ,by Decrypt the key from Received ,get and .like and If matched, then Successful authentication .

[0063] In this embodiment, step (3) of the session key negotiation phase, in the request-response mode, decrypts the client ECU and the server ECU respectively. = and Obtain the other party's session public key parameter and ; through their respective and Perform elliptic curve scalar multiplication, complete ECDH key exchange, and generate session keys. ;

[0064] The specific process under the publish-subscribe model is as follows:

[0065] Step (3-1): The client ECU initiates a service discovery request of type FindService (0x00) to the server ECU via the SOME / IP-SD protocol;

[0066] Step (3-2): The server ECU generates a corresponding session key for each client ECU via ECDH. The session key is then used to encrypt the group key subsequently used for multicast, and a message authentication code is attached for integrity verification.

[0067] Step (3-3): The server ECU encapsulates the ciphertext and message authentication code in a SOME / IP-SD message payload of type OfferService (0x01) based on the message identifier and request identifier, and sends it to the corresponding client ECU.

[0068] The specific process of step (4) secure communication phase in this embodiment is as follows:

[0069] Step (4-1): The two communicating parties use the session key. As the basic encryption key, a globally unique random number is generated for each SOME / IP message transmission as a session identifier to resist replay attacks; the receiver can resist replay attacks by verifying the timeliness or randomness of the random number.

[0070] Step (4-2): In the authentication encryption mode, use the protocol header and other immutable metadata as the associated data input; encrypt the plaintext data to generate ciphertext, and calculate the message authentication code based on the ciphertext and associated data.

[0071] This embodiment uses the widely accepted cryptographic library MIRACL to measure the execution time of cryptographic operations. An NXPS32K344 development board is used as the ECU node (based on an automotive-grade MCU, using an ARM Cortex-M7 architecture, 160MHz clock speed), and a Raspberry Pi 5 is used as the GECU (2.4GHz clock speed). Since the S32K344 does not have a built-in PUF module, the time of one PUF operation is used as the PUF operation time in this scheme. This embodiment executes these operations 5000 times to obtain the average time.

[0072] Specifically, SHA-256 is used as the hash function, RSA is used as the asymmetric encryption and signature algorithm, and a noise cancellation function based on SHA-256 and BCH encoding is used.

[0073] This implementation uses AES-256 as the symmetric encryption method, and the elliptic curve scalar multiplication uses the elliptic curve secp256k1. The results are shown in Table 1.

[0074] Table 1 ;

[0075] The computational overhead of the technical solution of this invention in actual application is compared with that of other solutions, and the results are as follows: Figure 4 As shown, the proposed solution has lower computational overhead compared to other solutions that also protect SOME / IP.

[0076] The communication overhead of the technical solution of this invention in actual application is compared with the communication overhead of other solutions, and the results are as follows: Figure 5 As shown, the technical solution of the present invention controls the communication overhead during the authentication phase within a reasonable range, which is significantly better than the high-load authentication design of Iorio et al.

Claims

1. A lightweight SOME / IP authentication method based on physically unclonable functions, characterized in that, Includes the following steps, Step (1), System initialization phase: The vehicle manufacturer extracts challenge response pairs from the on-chip PUF of the vehicle client ECU. The challenge response codes (CRPs) are encrypted and stored on the vehicle manufacturer's cloud server; the gateway electronic control unit (GECU) periodically synchronizes and updates the CRPs from the cloud; the onboard client ECU registers with the gateway electronic control unit (GECU), obtains and stores the secret value of the communicating party; the specific method is as follows: Step (1-1): The vehicle manufacturer inputs a random challenge into the ECU. Generate response Collect CRPs and encrypt them before uploading them to a cloud server; Steps (1-2): GECU periodically downloads and updates CRPs from the cloud; Steps (1-3): GECU selects the client Challenge and client Challenge Calculated by fuzz extractor Auxiliary data and private information , and Auxiliary data and private information , Generate random numbers And send message tuples Message tuple To the corresponding ECU; Steps (1-4) Calculate the response with noise. Calculate the secret value using a noise cancellation function Hash value 1. Randomly select a random number And send message tuples To GECU, Generate hash values ​​by performing similar operations And randomly select a random number y to form a message tuple. And send it to GECU; Steps (1-5), GECU verification Then, calculate the hash value. Hash value XOR value Hash value =H( ), hash value =H( XOR value encrypt to generate ciphertext ciphertext ; Steps (1-6) Receive ciphertext Decryption later and If the extracted random number matches the random number sent during this registration process, then... Stored as a secret value Perform similar operations and store ; Step (2), the authentication phase, initiating authentication Generate random numbers Send a message containing identity information, challenge value, and authentication request to ; After verification, private information is recovered using PUF and a fuzz extractor, the response is encrypted and returned; A secondary response is generated after successful verification. Verification completes two-way authentication; Step (3), Session Key Negotiation Phase, Request-Response Mode, and Calculate the session key using the ECDH algorithm. In publish-subscribe mode, the server ECU negotiates session keys for clients, encrypts multicast group keys, and distributes them. Step (4), the secure communication phase, involves the client ECU and the server ECU sharing a session key. Alternatively, a key can be used for secure SOME / IP message exchange; an enhanced scheme based on the STROBE protocol framework authenticates and encrypts the payload, and injects the SOME / IP header fields as associated data, tightly binding the ciphertext with the header fields; Its symmetric encryption module encrypts the payload, ensuring secure communication after authentication.

2. The lightweight SOME / IP authentication method based on physically unclonable functions according to claim 1, characterized in that: The specific process of the authentication phase in step (2) is as follows: Step (2-1) Generate random numbers ,send to ; Step (2-2) take over After receiving the message, first check Whether it is a registered client for its SOME / IP service, i.e., verifying whether it is stored in local memory. , and ; If it exists, extract it from the corresponding secret value. , and ; Calculate the response Private information , Key Randomly select a random number Generate ciphertext and random numbers And send message tuples to ; Steps (2-3) calculate , , Decryption and verification Then, calculate the hash value. Key Randomly select a random number Generate ciphertext And send to ; Steps (2-4) Calculate hash value ,by Decrypt the key from Received ,get and ;like and If matched, then Successful authentication .

3. The lightweight SOME / IP authentication method based on physically unclonable functions according to claim 1, characterized in that: In step (3) of the session key negotiation phase, the client ECU and server ECU decrypt in the request-response mode respectively. = and Obtain the other party's session public key parameter and ; through their respective and Perform elliptic curve scalar multiplication, complete ECDH key exchange, and generate session keys. ; The specific process under the publish-subscribe model is as follows: Step (3-1): The client ECU initiates a service discovery request of type FindService (0x00) to the server ECU via the SOME / IP-SD protocol; Step (3-2): The server ECU generates a corresponding session key for each client ECU via ECDH. The session key is then used to encrypt the group key subsequently used for multicast, and a message authentication code is attached for integrity verification. Step (3-3): The server ECU encapsulates the ciphertext and message authentication code in a SOME / IP-SD message payload of type OfferService (0x01) based on the message identifier and request identifier, and sends it to the corresponding client ECU.

Images