Lightweight identity authentication and key exchange scheme based on SRAM PUF in car networking environment

Abstract

The invention discloses a lightweight identity authentication and key exchange scheme based on an SRAM (Static Random Access Memory) PUF (Physical Unclonable Function) in an Internet of Vehicles environment. The lightweight identity authentication and key exchange scheme comprises the following steps: (1) a one-time registration stage: a vehicle unit (OBU) transmits static random access memory (SRAM) information and identity (ID) information serving as fingerprints to a roadside unit (RSU) under a safe condition; and (2) an identity authentication stage: the OBU and the RSU verify each other through dynamic identity authentication. And the OBU sends a challenge value, the RSU generates a response value by using the stored SRAM fingerprint, and the OBU verifies the identity of the RSU by confirming the correctness of the response value. Then, the RSU generates a new challenge value, the OBU generates and sends a response value through the SRAM PUF, the RSU verifies and confirms the OBU identity, and therefore bidirectional authentication is completed; and (3) key generation: after identity authentication is completed, the OBU and the RSU generate a secure session key through Hash operation. The secret key is used for subsequent encryption communication, and the integrity and confidentiality of data in the transmission process are ensured. The new key generated by each communication session further enhances the security of the system.

Description

Technical Field

[0001] The present invention relates to a lightweight identity authentication and key exchange scheme based on SRAM PUF in a connected vehicle environment. Background Art

[0002] The Internet of Vehicles is part of the Internet of Things, which connects vehicles to other vehicles, infrastructure, and pedestrians, aiming to improve traffic safety, efficiency, and driving experience. However, the security challenges that come with it have become more complex and important. Internet of Vehicles devices need to process a large amount of data, which not only needs to be transmitted in real time, but also must ensure its security and authenticity. Therefore, the Internet of Vehicles places higher demands on security solutions, especially when facing remote access and control. Such a large number of devices increases the size of the potential attack surface, making it equally important to ensure the security of each device.

[0003] In the Internet of Vehicles system, the roadside unit (RSU) and the on-board unit (OBU) play a key role. The RSU is installed on the road infrastructure and is responsible for wireless communication with the vehicle (OBU), transmitting traffic information and road condition data, while collecting and processing surrounding traffic information to achieve regional traffic management and optimization. The OBU is installed on the vehicle, exchanges data with the RSU and other vehicles, processes the received real-time traffic information, optimizes driving decisions, and improves driving safety and efficiency. The collaboration between RSU and OBU not only enhances traffic safety and efficiency, but also enables the Internet of Vehicles system to achieve intelligent traffic management. However, with the increase in the number of devices, the Internet of Vehicles faces more complex security challenges, which requires strict protection of the security of each device, especially in the case of remote access and control, to ensure the security and authenticity of the data.

[0004] IoT devices often face resource constraints, which may include limitations in processing power, storage space, energy supply, etc. These devices are usually designed to be small and low-power, so their computing and storage capabilities may be limited, which may have an impact on their functionality and performance. When designing and developing IoT solutions, special attention needs to be paid to how to effectively utilize these limited resources to ensure the stability and reliability of the devices. In addition, operating under different environmental conditions makes IoT devices vulnerable to various physical intrusions. The keys used by traditional security primitives are usually stored in battery-powered or non-volatile memory (NVM), which is vulnerable to key extraction attacks. In this context, it is not feasible to directly use traditional cryptographic systems for IoT. For IoT devices, lightweight and resource-friendly protocols are needed, which need to provide sufficient protection against different adversarial attacks.

[0005] Physical Unclonable Function (PUF) is a potential alternative to protect Internet of Things (IoT) devices from more traditional computation-based methods that use traditional cryptographic techniques. PUF generates a unique device-related signature that is not replicated and sensitive to tampering by exploiting manufacturing process variations. Whenever a binary sequence (called challenge C) is applied to the PUF system, it produces a corresponding response R. That is, when the same challenge C is applied to different integrated circuits (ICs), they will produce different responses R, and this combination is called a challenge-response pair (CRP). Since the PUF system contains uncontrollable random components, when the challenge C is applied to the PUF system, these components will produce the response R in an unpredictable and random manner. The formula is: f PUF :C i →R i .

[0006] Physical Unclonable Functions (PUFs) can be divided into two categories: weak PUFs and strong PUFs. Weak PUFs usually have only a limited number of challenge-response pairs (CRPs), such as SRAM PUF and Butterfly PUF. Among them, Static Random-Access Memory Physical Unclonable Function (SRAM PUF) is of particular interest because it utilizes the startup values ​​of SRAM cells at power-on, which are random and unique, and are very suitable for device initialization and key generation. SRAM PUFs are simple in design, easy to integrate, and have low computational and power consumption overheads, making them suitable for static authentication and key storage. In contrast, strong PUFs have a large number of CRPs, such as Arbiter PUF and RingOscillator PUF, which can provide different responses and are suitable for dynamic authentication and challenge-response protocols. Strong PUFs are more complex in design and can resist multiple attacks, but they usually require more hardware resources and power consumption. Therefore, choosing the appropriate type of PUF depends on the application scenario and device resource constraints, among which SRAM PUFs are particularly prominent in resource-constrained IoT devices.

[0007] Currently, PUF is widely used in security fields such as identity authentication and key exchange. However, existing PUF-based protocols still have some obvious shortcomings in practical applications. According to the research proposed by Gassend et al. (2002), although PUF technology is innovative, its disadvantages include environmental sensitivity, manufacturing consistency issues, and implementation complexity and high cost. The HELP protocol proposed by Che et al. uses hardware embedded delay PUF. Although encryption is not required, it is vulnerable to denial of service and detection attacks due to the lack of message authentication. The PLAKE method proposed by Sourav Roy, although lightweight, may still face certain complexity in actual implementation and deployment, and there are some redundant parts.

[0008] In order to solve the above technical problems, the present invention provides a lightweight identity authentication and key exchange solution based on SRAM PUF in a vehicle networking environment with simple algorithm and high security.

[0009] The technical solution of the present invention to solve the above technical problems is: a lightweight identity authentication and key exchange solution based on SRAM PUF in a connected vehicle environment, comprising the following steps:

[0010] (1) One-time registration phase: The On Board Unit (OBU) transmits the static random access memory (SRAM) information and identity information (ID) as fingerprints to the Road Side Unit (RSU) under secure conditions. The RSU stores this information in a secure database for subsequent authentication;

[0011] (2) Authentication phase: Before each communication session, dynamic authentication is performed between the OBU and the RSU. The OBU generates and transmits a challenge value, and the RSU generates a response value through the stored SRAM fingerprint. The OBU verifies the correctness of the response value to confirm the identity of the RSU. Then, the RSU generates a new challenge value, and the OBU generates a corresponding response value through its SRAM PUF and sends it to the RSU. The RSU verifies the response value to confirm the identity of the OBU, thus completing the two-way authentication;

[0012] (3) Key generation: After identity authentication is completed, the OBU and RSU generate a secure session key through hash operation. This key is used for subsequent encrypted communications to ensure the integrity and confidentiality of data during transmission. The new key generated for each communication session further enhances the security of the system;

[0013] In the above-mentioned lightweight authentication and key exchange method based on SRAM PUF in the Internet of Vehicles environment, in the step (1), the on-board unit extracts 128 bits of stable SRAM as the device fingerprint. These fingerprints do not need to be stored in the non-volatile memory of the device. It only needs to ensure that when the device is started, the program can read the startup value of the SRAM unit in the first time. These selected fingerprints must meet the following requirements: 50% of the fingerprints are selected from the unit with the startup value of "0", and the other 50% are selected from the unit with the startup value of "1". This method ensures the diversity and anti-attack of the fingerprint, while avoiding the potential security risks caused by the singleness of a certain startup value, and improves the balance and randomness of the fingerprint; select a unit with a stability rate of more than 95% to construct the fingerprint. If there are not enough high-stability units, select units with a stability rate of 94% in turn until a complete fingerprint is constructed. This method of gradually reducing the stability requirements ensures the overall reliability and stability of the fingerprint, while ensuring that enough bits can be obtained to meet security requirements in practical applications. In this way, we can maintain the consistency and reliability of fingerprints under different environmental conditions and improve the anti-interference ability and security of the system. After the fingerprint is constructed, the fingerprint is passed to the ECC algorithm to generate auxiliary data. The auxiliary data is stored in the device's NVM. The fingerprint and its corresponding address value and stability rate are then transmitted to the roadside unit. The roadside unit will generate a unique ID for the device based on the received information and store the ID in the database in association with the fingerprint data. The onboard unit will also store this ID for use in subsequent authentication processes.

[0014] In the above-mentioned SRAM PUF-based lightweight authentication and key exchange method in the Internet of Vehicles environment, the data stored in the roadside unit database is:

[0015] (Roadside Unit ID i , address 1, the value corresponding to address 1, address 2, the value corresponding to address 2..., address n, the value corresponding to address n)

[0016] (Roadside Unit ID i+n , address 1, the value corresponding to address 1, address 2, the value corresponding to address 2..., address n, the value corresponding to address n)

[0017] In the above-mentioned SRAM PUF-based lightweight authentication and key exchange method in the Internet of Vehicles environment, the specific process of the identity authentication phase in step (2) is as follows:

[0018] 2-1) Identity authentication phase connection initialization: The vehicle unit sends a message m1 to the roadside unit, which contains a connection request and device ID i After receiving the information, the roadside unit will iFind the fingerprint and related information stored in advance. Then the roadside unit generates a scrambled address value as a challenge (C i ), and get its corresponding response Ri. Then use Ri and the random number N generated by the roadside unit s XOR to get message M s . s With R i Generate authentication message Auth through hash function s When the initial value is read for the first time, the read data needs to be corrected by ECC. The formula for generating information is as follows:

[0019]

[0020] Auth s ←Hash(M s ||R i )

[0021] Roadside units will C i , M s and Auth s Sent to the onboard unit Node in message m2;

[0022] 2-2) Roadside unit authentication: When the vehicle-mounted unit receives information from the roadside unit, it will i As a challenge, get R as input i ', then according to the obtained R i ' and M s Generate Auth s '. Compare to Auth s and Auth s ', if the information is correct, the roadside unit is authenticated. After authentication, the M s With R i 'XOR to get N s The vehicle-mounted unit generates a random number N d and Challenge C i+1 , and get the response R i+1 . s 、N d , R i and R i+1 The key Key is obtained through hash operation. Parse R i+1 With N d XOR generates M d , and finally M d With R i+1 Generate authentication message Authd. The steps and formula are as follows:

[0023] R i ′←PUF(C i )

[0024]

[0025] Compare(Auths,Auths′)

[0026] After completing the authentication, the node generates a new challenge response and generates information to send to the roadside unit.

[0027]

[0028] R i+1 ←PUF(C i+1 )

[0029] Key←Hash(N s ||N d ||R i ||R i+1 )

[0030]

[0031] Auth d ←Hash(M d ||R i+1 )

[0032] The vehicle-mounted unit equipment will be C i+1 ,M d and Auth d Sent to the roadside unit as message m3.

[0033] 2-3) Authentication of vehicle-mounted units: When the roadside unit receives m3, it passes C i+1 Get R i+1 ', R i+1 ' and M d Perform hash operation to generate Auth d ', with Auth d Make a comparison and proceed to the next step after passing the authentication. The formula is as follows:

[0034] R i+1 ′←PUF(C i+1 )

[0035] Auth d ′←Hash(R i+1 ′||M d )

[0036] Compare(Auth d ,Auth d ′)

[0037] In the above-mentioned SRAM PUF-based lightweight authentication and key exchange method in the Internet of Vehicles environment, the specific process of intra-domain authentication in step (3) is as follows:

[0038] 3-1) Obtain the random number generated by OBU:

[0039]

[0040] 3-2) Generate the key:

[0041] Key←Hash(N s ||N d ||R i ||R i+1 )

[0042] In the above-mentioned SRAM PUF-based lightweight authentication and key exchange method in the Internet of Vehicles environment, in step 2-1), the process of generating the challenge Ci is:

[0043] 1.1: Select multiple address values ​​from a predetermined SRAM cell address range that will serve as the basis for the challenge.

[0044] 1.2: Shuffle the selected SRAM cell addresses and use a pseudo-random number generator (PRNG) or other randomization algorithm to rearrange the order of the address values. The rearranged address value is the challenge Ci

[0045] 1.3: Combine the scrambled address values ​​to form the final challenge Ci.

[0046] The beneficial effects of the present invention are:

[0047] 1. This invention proposes a lightweight authentication and key exchange method for connected vehicle devices based on SRAM PUF. By using SRAM PUF in the vehicle-mounted unit to generate a unique device fingerprint and comparing it in the roadside unit, forgery and replay attacks in traditional authentication methods can be effectively avoided. At the same time, by using randomly generated challenge values ​​in the authentication process, the security of the system is further improved.

[0048] 2. In the method of the present invention, the fingerprint information of the device does not need to be stored in the non-volatile memory for a long time, and only the startup value of the SRAM is read when the device is started. This not only simplifies the management and storage of device fingerprints, but also reduces the risk of fingerprint information being stolen, thereby improving the overall security and reliability of the system.

[0049] 3. The present invention introduces a mechanism of stable SRAM unit selection and scrambled address generation challenge in the authentication process. By selecting SRAM units with high stability to build fingerprints and using scrambled address values ​​as challenges, the accuracy and efficiency of authentication are improved. Combined with the two-way authentication mechanism between the roadside unit and the vehicle-mounted unit, the identity authentication and key exchange of the device can be completed quickly, ensuring the real-time and efficient communication.

[0050] 4. The present invention fully considers the low performance characteristics of edge devices such as vehicle-mounted units and roadside units, and adopts a lightweight authentication and key exchange method. By selecting stable SRAM units and optimizing the challenge generation mechanism, the complexity of calculation and storage is reduced, ensuring that low-performance devices can efficiently complete the authentication and key exchange process under limited resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 It is the overall flow chart of the present invention.

[0052] Figure 2 It is a system framework diagram of the present invention.

[0053] Figure 3 It is a user registration schematic diagram of the present invention.

[0054] Figure 4 This is a schematic diagram of identity authentication and key generation of the present invention. DETAILED DESCRIPTION

[0055] The present invention is further described below with reference to the accompanying drawings and embodiments.

[0056] like Figure 1 As shown, a cross-domain authentication and key negotiation method based on blockchain in an Internet of Things environment includes the following steps:

[0057] 1) One-time registration phase: The vehicle unit (OBU, On Board Unit) transmits static random access memory (SRAM) information and identity information (ID) as fingerprints to the roadside unit (RSU, Road Side Unit) under safe conditions. RSU stores this information in a secure database for subsequent authentication.

[0058] The on-board unit extracts 128 bits of stable SRAM as the device fingerprint. These fingerprints do not need to be stored in the non-volatile memory of the device. It only needs to ensure that when the device is started, the program can read the startup value of the SRAM unit in the first time. These selected fingerprints must meet the following requirements: 50% of the fingerprints are selected from the unit with the startup value of "0", and the other 50% are selected from the unit with the startup value of "1". This method ensures the diversity and anti-attack of the fingerprint, while avoiding the potential security risks caused by the singleness of a certain startup value, and improves the balance and randomness of the fingerprint; select cells with a stability rate of more than 95% to construct the fingerprint. If there are not enough high-stability cells, select cells with a stability rate of 94% in turn until a complete fingerprint is constructed. This method of gradually reducing the stability requirements ensures the overall reliability and stability of the fingerprint, while ensuring that enough bits can be obtained to meet security requirements in practical applications. In this way, we can maintain the consistency and reliability of the fingerprint under different environmental conditions and improve the anti-interference ability and security of the system. After the fingerprint is constructed, the fingerprint is passed to the ECC algorithm to generate auxiliary data. And the auxiliary data is stored in the NVM of the device. The fingerprint and its corresponding address value and stability rate are then transmitted to the roadside unit. The roadside unit generates a unique ID for the device based on the information received and stores the ID in a database in association with the fingerprint data. The onboard unit also stores this ID for use in subsequent authentication processes.

[0059] (2) Authentication phase: Before each communication session, dynamic authentication is performed between the OBU and the RSU. The OBU generates and transmits a challenge value, and the RSU generates a response value through the stored SRAM fingerprint. The OBU verifies the correctness of the response value to confirm the identity of the RSU. Then, the RSU generates a new challenge value, and the OBU generates a corresponding response value through its SRAM PUF and sends it to the RSU. The RSU verifies the response value to confirm the identity of the OBU, thus completing the two-way authentication. The specific steps are:

[0060] 2-1) Identity authentication phase connection initialization: The vehicle unit sends a message m1 to the roadside unit, which contains a connection request and device ID i After receiving the information, the roadside unit will i Find the fingerprint and related information stored in advance. Then the roadside unit generates a scrambled address value as a challenge (C i ), and get its corresponding response Ri. Then use Ri and the random number N generated by the roadside unit s XOR to get message M s . s With R i Generate authentication message Auth through hash function sWhen the initial value is read for the first time, the read data needs to be corrected by ECC. The formula for generating information is as follows:

[0061]

[0062] Auth s ←Hash(M s ||R i )

[0063] Roadside units will C i , M s and Auth s Sent to the onboard unit Node in message m2;

[0064] 2-2) Roadside unit authentication: When the vehicle-mounted unit receives information from the roadside unit, it will i As a challenge, get R as input i ', then according to the obtained R i ' and M s Generate Auth s '. Compare to Auth s and Auth s ', if the information is correct, the roadside unit is authenticated. After authentication, the M s With R i 'XOR to get N s The vehicle-mounted unit generates a random number N d and Challenge C i+1 , and get the response R i+1 . s 、N a , R i and R i+1 The key Key is obtained through hash operation. Parse R i+1 With N d XOR generates M d , and finally M d with Ri +1 Generate authentication message Authd. The steps and formula are as follows:

[0065] R i ′←PUF(C i )

[0066]

[0067] Compare(Auths,Auths′)

[0068] After completing the authentication, the node generates a new challenge response and generates information to send to the roadside unit.

[0069]

[0070] R i+1 ←PUF(Ci +1 )

[0071] Key←Hash(N s ||N d ||R i ||R i+1 )

[0072]

[0073] Auth d ←Hash(M d ||R i+1 )

[0074] The vehicle-mounted unit equipment will be C i+1 ,M d and Auth d Sent to the roadside unit as message m3.

[0075] 2-3) Authentication of vehicle-mounted units: When the roadside unit receives m3, it passes C i+1 GetRi +1 ', will Ri +1 ' and M d Perform hash operation to generate Auth d ', with Auth d Make a comparison and proceed to the next step after passing the authentication. The formula is as follows:

[0076] R i+1 ′←PUF(C i+1 )

[0077] Auth d ′←Hash(R i+1 ′||M d )

[0078] Compare(Auth d ,Auth d ′)

[0079] (3) Key generation: After identity authentication is completed, the OBU and RSU generate a secure session key through hash operation. This key is used for subsequent encrypted communications to ensure the integrity and confidentiality of data during transmission. The new key generated for each communication session further enhances the security of the system. The specific steps are as follows:

[0080] 3-1) Obtain the random number generated by OBU:

[0081]

[0082] 3-2) Generate the key:

[0083] Key←Hash(N s ||N d ||R i ||R i+1 )

[0084] As shown in Figure 2, the figure shows the communication coverage in the Internet of Vehicles environment. The central antenna represents the roadside unit (RSU), and its coverage includes multiple on-board units (OBU). These on-board units communicate with the roadside units through wireless signals. In this system, the RSU is responsible for managing the OBUs within its coverage and acts as a communication bridge between the OBU and other authentication centers. The present invention uses a lightweight authentication and key exchange method based on SRAM PUF to achieve OBU identity authentication and key exchange through the unique device fingerprint generated by SRAM PUF. Through this method, secure and reliable communication between the on-board unit and the roadside unit is ensured, while improving the efficiency of the authentication and key exchange process.

Claims

1. A lightweight identity authentication and key exchange scheme based on SRAM PUF in a connected vehicle environment, characterized in that: The following steps are involved: (1) One-time registration phase: The On Board Unit (OBU) transmits the static random access memory (SRAM) information and identity information (ID) as fingerprints to the Road Side Unit (RSU) under safe conditions; The RSU stores this information in a secure database for subsequent authentication; (2) Identity authentication stage: Before each communication session, dynamic identity authentication is performed between the OBU and the RSU; The OBU generates and transmits a challenge value, and the RSU generates a response value through the stored SRAM fingerprint; the OBU verifies the correctness of the response value to confirm the identity of the RSU; then, the RSU generates a new challenge value, and the OBU generates a corresponding response value through its SRAM PUF and sends it to the RSU; the RSU verifies the response value to confirm the identity of the OBU, thus completing the two-way identity authentication; (3) Key generation: After identity authentication is completed, the OBU and RSU generate a secure session key through hash operation; this key is used for subsequent encrypted communications to ensure the integrity and confidentiality of data during transmission; a new key is generated for each communication session, further enhancing the security of the system.

2. The method for lightweight authentication and key exchange based on SRAM PUF in a connected vehicle environment according to claim 1, characterized in that: In step (1), the specific process of the one-time registration stage is as follows: The onboard unit extracts 128 bits of stable SRAM as device fingerprints; these fingerprints do not need to be stored in the device's non-volatile memory, but only need to ensure that when the device starts, the program can read the startup value of the SRAM unit as soon as possible; these selected fingerprints must meet the following requirements: 1-1) 50% of the fingerprints are selected from the cells with a startup value of "0", and the other 50% are selected from the cells with a startup value of "1". This method ensures the diversity and anti-attack capability of the fingerprints, while avoiding the potential security risks caused by the singularity of a certain startup value, and improves the balance and randomness of the fingerprints; 1-2) Select units with a stability rate of more than 95% to construct the fingerprint; if there are not enough high-stability units, select units with a stability rate of 94% in turn until the complete fingerprint is constructed. This method of gradually reducing the stability requirements ensures the overall reliability and stability of the fingerprint, while ensuring that enough bits can be obtained in practical applications to meet security requirements; in this way, we can maintain the consistency and reliability of the fingerprint under different environmental conditions and improve the anti-interference ability and security of the system; 1-3) After the fingerprint is constructed, the fingerprint is passed into the ECC algorithm to generate auxiliary data; the auxiliary data is stored in the device's NVM; the fingerprint and its corresponding address value and stability rate are then transmitted to the roadside unit; the roadside unit will generate a unique ID for the device based on the received information, and store the ID in association with the fingerprint data in the database. The on-board unit will also store this ID for use in subsequent authentication processes.

3. The SRAM PUF-based lightweight identity authentication and key exchange scheme in the Internet of Vehicles environment according to claim 2, characterized in that: The specific process of the identity authentication phase in step (2) is as follows: 2-1) Identity authentication phase connection initialization: The vehicle unit sends a message m1 to the roadside unit, which contains a connection request and device ID i ; After receiving the information, the roadside unit i Find the fingerprint and related information stored in advance; then the roadside unit generates a scrambled address value as a challenge (C i ), and get its corresponding response R i ; then use R i The random number N generated by the roadside unit s XOR to get message M s ; M s With R i Generate authentication message Auth through hash function s ; When reading the initial value for the first time, the read data needs to be corrected by ECC; the formula for generating information is as follows: M s ←N s ⊕R i Auth s ←Hash(M s ||R i ) Roadside units will C i , M s and Auth s Sent to the onboard unit Node in message m2; 2-2) Roadside unit authentication: When the vehicle-mounted unit receives information from the roadside unit, it will i As a challenge, get R as input i ', then according to the obtained R i ' and M s Generate Auth s ';Compare to Auth s and Auth s ', if the information is correct, the roadside unit is authenticated; after authentication, the M s With R i 'XOR to get N s ; The on-board unit generates a random number N d and Challenge C i+1 , and get the response R i+1 ; N s 、N d , R i and R i+1 The key Key is obtained through hash operation; R i+1 With N d XOR generates M d , and finally M d With R i+1 Generate authentication message Authd; the steps and formula are as follows: R i ′←PUF(C i ) Auth s ′←R i ′⊕M s Compare(Auths,Auths′) (The function of Compare is to compare whether the authentication information is consistent) After completing the authentication, the node generates a new challenge response and generates information to send to the roadside unit; N s ←M s ⊕R i ′ R i+1 ←PUF(C i+1 ) Key←Hash(N s ||N d ||R i ||R i+1 ) M d ←N d ⊕R i+1 Auth d ←Hash(M d ||R i+1 ) The vehicle-mounted unit equipment will be C i+1 ,M d and Auth d Sent to the roadside unit as message m3; 2-3) Authentication of vehicle-mounted units: When the roadside unit receives m3, it passes C i+1 Get R i+1 ', R i+1 ' and M d Perform hash operation to generate Auth d ', with Auth d Make a comparison and proceed to the next step after passing the certification; the formula is as follows: R i+1 ′←PUF(C i+1 ) Auth d ′←Hash(R i+1 ′||M d ) Compare(AUth d ,Auth d ′)。 4. The SRAM PUF-based lightweight identity authentication and key exchange scheme in the Internet of Vehicles environment according to claim 3, characterized in that: The specific process of the intra-domain authentication in step (3) is as follows: 3-1) Obtain the random number generated by OBU: N d ←M d ⊕R i+1 3-2) Generate the key: Key←Hash(N s ||N d ||R i ||R i+1 )。 5. The method for lightweight authentication and key exchange based on SRAM PUF in a connected vehicle environment according to claim 1, characterized in that: The data stored in the roadside unit database are: (Roadside Unit ID i , address 1, the value corresponding to address 1, address 2, the value corresponding to address 2..., address n, the value corresponding to address n) …………… (Roadside Unit ID i+n , address 1, the value corresponding to address 1, address 2, the value corresponding to address 2..., address n, the value corresponding to address n).

6. The SRAM PUF-based lightweight authentication and key exchange method in a connected vehicle environment according to claim 2, characterized in that: In step 2-1), challenge C i The generation process is: 1.1: Select multiple address values ​​from a predetermined SRAM cell address range that will serve as the basis for the challenge; 1.2: Shuffle the selected SRAM cell addresses and use a pseudo-random number generator (PRNG) or other randomization algorithm to rearrange the order of the address values; the rearranged address value is the challenge C i ; 1.3: Combine the scrambled address values ​​to form the final challenge C i .

Images