Key Updatable Cross-Domain-Message Anonymous Authentication Scheme Based on Dual-Chain for VANET

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

1. The manuscript does not clearly explain how the consensus mechanism works in the consortium chain. It refers to RSUs and TAs as "full nodes," but does not specify how they agree on the "global temporary public key chain."
2. The security of the "Key Update Parameters" (r, P_r, T_{expr}) is very important. If r is compromised, the entire identity-based system for that period is at risk. The manuscript does not adequately discuss how "Forward Secrecy" applies to these updates.
3. Although the abstract claims that there are "reduced computational and communication costs," the "Results" section does not provide a clear comparison against state-of-the-art schemes (e.g., [19], [22]) in terms of throughput or storage overhead on RSUs.
4. In Section 5, in the Security Analysis - Traceability. It is suggested to refer from the paper: ”A time-aware LSTM model for detecting criminal activities in blockchain transactions “. While the manuscript covers traceability through identity recovery, the reference offers additional insights on monitoring changes in blockchain addresses over time. It provides a basis for detecting harmful behaviors through transaction patterns before starting the identity recovery process.
5. The manuscript should include a clear description of the consensus algorithm (e.g., PBFT or PoS) used in the consortium chain. It should also explain how "dual-chain" synchronization is maintained without creating a "centralized bottleneck."
6. The authors should add a formal security analysis (e.g., using the ROM or ProVerif) to demonstrate the system's resistance to impersonation and man-in-the-middle attacks, particularly during the cross-domain query phase.
7. The manuscript should correct phrases such as "which shorts the authentication delay" to "which shortens the authentication delay."

Author Response

Comments 1:The manuscript does not clearly explain how the consensus mechanism works in the consortium chain. It refers to RSUs and TAs as "full nodes," but does not specify how they agree on the "global temporary public key chain."

Responses 1: the second and third paragraphs of Section 3.2 of the article, we present how TA, as a full node, achieves consensus with private chains.

“The global temporary public key chain utilizes the Proof of Authority (POA) pre-authorization algorithm inherent to consortium blockchains. All TA nodes gener-ate blocks for the global temporary public key chain in strict compliance with the pre-authorized sequence. RSUs and certain edge nodes endowed with strong robust computational capabilities employ smart contract algorithms to download blocks con-taining temporary public key information pertaining to nodes within their designated regions. Vehicles and other nodes accomplish authentication by querying the tempo-rary public key blocks specific to their regions or by accessing the temporary public key information embedded within the blocks of the global temporary public key chain .”

 

Comments 2:The security of the "Key Update Parameters" (r, P_r, T_{expr}) is very important. If r is compromised, the entire identity-based system for that period is at risk. The manuscript does not adequately discuss how "Forward Secrecy" applies to these updates.

Responses 2: We assume that TA possesses strong security. To prevent the leakage of ‘r ‘ from compromising the security of the entire network for a certain period of time, we modify the scheme so that each region maintains a separate ’r’. This way, even if r is leaked, it will only affect the security of one region for a certain period of time. We replace with .

Comments 3:Although the abstract claims that there are "reduced computational and communication costs," the "Results" section does not provide a clear comparison against state-of-the-art schemes (e.g., [19], [22]) in terms of throughput or storage overhead on RSUs.

Responses 3: To compare the communication overhead, we compared the communication overhead of our scheme with that of other schemes, such as the one described in Reference 22, in Section 6.2 of the article. This included the number of communication interactions and blockchain query accesses.

Comments 4: In Section 5, in the Security Analysis - Traceability. It is suggested to refer from the paper: ”A time-aware LSTM model for detecting criminal activities in blockchain transactions “. While the manuscript covers traceability through identity recovery, the reference offers additional insights on monitoring changes in blockchain addresses over time. It provides a basis for detecting harmful behaviors through transaction patterns before starting the identity recovery process.

Responses 4:In Chapter 5, "Traceability Analysis," we drew inspiration from the detection method presented in this literature.

Comments 5:The manuscript should include a clear description of the consensus algorithm (e.g., PBFT or PoS) used in the consortium chain. It should also explain how "dual-chain" synchronization is maintained without creating a "centralized bottleneck."

Responses 5: In the second and third paragraphs of Section 3.2, we have explained how the dual-chain works. To avoid bottlenecks, we adopt a dual-layer, zoned management approach. Only when a vehicle is registered will a block be uploaded to the blockchain. When a key update is required, TAs update the global temporary public key chain, and RSU and edge nodes download the temporary public key information of vehicles in their respective zones from TAs. During vehicle authentication, if the vehicle belongs to the current zone, it can directly access the local consortium chain. If it belongs to another zone, it will access the global public key chain. Moreover, the global temporary public key chain can be stored in different zones to enhance query efficiency. This approach can address the bottleneck issue in authentication.

Comments 6:The authors should add a formal security analysis (e.g., using the ROM or ProVerif) to demonstrate the system's resistance to impersonation and man-in-the-middle attacks, particularly during the cross-domain query phase.

Responses 6: In Chapter 5, "Security Analysis," we present security proofs under the random oracle model by utilizing Lemma 1 and Lemma 2, and conduct a detailed analysis of attacks such as forgery resistance in cross-domain authentication.

Comments 7: The manuscript should correct phrases such as "which shorts the authentication delay" to "which shortens the authentication delay."

Responses 7: We have made the necessary modifications. Thank you very much .

Reviewer 2 Report

Comments and Suggestions for Authors

1: The limitations of identity-based PKI solutions do not provide a quantitative comparison using a more formalized performance metric.

2: Definition 1 of the ECDLP  lacks a clear specification of the computational instance and the adversary's goal. Definition 2: lack of a full formalization of the CDH problem.

3: The presence of a TA that manages critical information on both chains reintroduces a possible central point of trust that contradicts the fact of overcoming dependence on centralized entities.

4: The generation of temporary keys using hash functions of the type (line 156) is unclear because it is unclear whether the hash operates on serialized representations of the point or on affine coordinates, and how the uniformity of the output in Zq* is guaranteed.

5: The coincidence of the temporary key and the temporary public key (lines 156–158) could suggest a possible deterministic derivation that could expose the system to precomputation attacks if the parameter r were compromised. An analysis of forward or backward secrecy in the event of exposure of r or X_t is missing.

6: While equation (1) algebraically corresponds to signature generation, the scheme should be formally defined and proven to be secure according to a standard model (e.g., EUF-CMA).

7: The game model reported in lines 285–290 is only sketched; it lacks a formal definition of the adversary's capabilities, the number of allowed queries, and the notion of advantage. It is not shown how a signature forger implies an efficient algorithm for solving the CDH problem. Equations 294–296, as defined, allow for the possibility of obtaining two signatures with the same nonce r, without this having been justified, perhaps by introducing a rewind lemma or a forking technique.

8: The computational times in Table 2 lack details such as the elliptic curve used, the size of the security parameters, the compilation method of the MIRACL library, and the number of iterations for statistical averaging.

9: The assumption that the cost of common TA parameters is negligible for a large number of vehicles has no value if it is not supported by a scalability analysis and appropriate large-scale simulations.

10: It is unclear whether the percentage comparisons (lines 362–364, 377–379) imply compared protocols implemented in the same experimental environment or whether the data comes from heterogeneous sources.

11:The communication overhead assessment should consider the intrinsic blockchain overhead, including block headers, consensus signatures, and propagation latency. The conducted analysis completely ignores the impact of network congestion and the high mobility typical of VANETs.

 

Author Response

Comments 1: The limitations of identity-based PKI solutions do not provide a quantitative comparison using a more formalized performance metric.

Responses 1: We sincerely apologize for the fact that we are currently unable to conduct a quantitative analysis on the flaws of the PKI-based scheme. However, we can refer to some quantitative analysis methods presented in the literature. We have included a citation [27] in the article .

Comments 2: Definition 1 of the ECDLP  lacks a clear specification of the computational instance and the adversary's goal. Definition 2: lack of a full formalization of the CDH problem.

Responses 2: In Section 3.1 of our article, we provide a more detailed re-explanation of Definitions 1 and 2.

Comments 3: The presence of a TA that manages critical information on both chains reintroduces a possible central point of trust that contradicts the fact of overcoming dependence on centralized entities.

Responses 3: In the second and third paragraphs of Section 3.2, we have explained how the dual-chain works. To avoid bottlenecks, we adopt a dual-layer, zoned management approach. Only when a vehicle is registered will a block be uploaded to the blockchain. When a key update is required, TAs update the global temporary public key chain, and RSU and edge nodes download the temporary public key information of vehicles in their respective zones from TAs. During vehicle authentication, if the vehicle belongs to the current zone, it can directly access the local consortium chain. If it belongs to another zone, it will access the global public key chain. Moreover, the global temporary public key chain can be stored in different zones to enhance query efficiency. This approach can address the bottleneck issue in authentication and avoid centralization.

Comments 4: The generation of temporary keys using hash functions of the type (line 156) is unclear because it is unclear whether the hash operates on serialized representations of the point or on affine coordinates, and how the uniformity of the output in Zq* is guaranteed.

Responses 4: In this article, a hash function is employed to generate keys. Specifically, points on the elliptic curve are first serialized, and then hash functions such as SHA256 from cryptography are applied to achieve better uniformity on Zq*.

Comments 5: The coincidence of the temporary key and the temporary public key (lines 156–158) could suggest a possible deterministic derivation that could expose the system to precomputation attacks if the parameter r were compromised. An analysis of forward or backward secrecy in the event of exposure of r or X_t is missing.

Responses 5: We assume that TA possesses strong security. To prevent the leakage of ‘r ‘ from compromising the security of the entire network for a certain period of time, we modify the scheme so that each region maintains a separate ’r’. This way, even if r is leaked, it will only affect the security of one region for a certain period of time. We replace (r,Pr,AID,Texpr) with (r,Pr,Texpr). To prevent the leakage of the vehicle's original shared key x, we have set multiple original shared keys for the vehicle. To prevent the leakage of r from compromising the security of the entire network for a certain period of time, we modify the scheme so that each region maintains a separate r .This way, even if r is leaked, it will only affect the security of one region for a certain period of time. To enhance the security of vehicle keys, the scheme proposed in this paper utilizes t original shared keys . It employs these t shared keys and the region update parameter Pr to collectively update the vehicle's individual key. The compromise of the vehicle's individual key only affects the signature at a specific moment. Attackers are unable to update the key based on the updated parameters, thus preventing them from forging future signatures. In Chapter 5, "Security Analysis," we have included an analysis of forward security.

Comments 6: While equation (1) algebraically corresponds to signature generation, the scheme should be formally defined and proven to be secure according to a standard model (e.g., EUF-CMA).

Responses 6: In Chapter 5, "Security Analysis," we present security proofs under the random oracle model by utilizing Lemma 1 and Lemma 2, and conduct a detailed analysis of attacks such as forgery resistance in cross-domain authentication.

Responses 7: The game model reported in lines 285–290 is only sketched; it lacks a formal definition of the adversary's capabilities, the number of allowed queries, and the notion of advantage. It is not shown how a signature forger implies an efficient algorithm for solving the CDH problem. Equations 294–296, as defined, allow for the possibility of obtaining two signatures with the same nonce r, without this having been justified, perhaps by introducing a rewind lemma or a forking technique.

Responses 7: In Chapter 5, "Security Analysis," we present security proofs under the random oracle model by utilizing Lemma 1 and Lemma 2, and conduct a detailed analysis of attacks such as forgery resistance in cross-domain authentication. Bifurcation theory was applied in the analysis. In Chapter 5, the anonymity analysis utilizes the CDH (Computational Diffie-Hellman) hard problem.

Comments 8: The computational times in Table 2 lack details such as the elliptic curve used, the size of the security parameters, the compilation method of the MIRACL library, and the number of iterations for statistical averaging.

Responses 8: In Section 6.1, we have included detailed parameter settings for the experimental environment.

Comments 9: The assumption that the cost of common TA parameters is negligible for a large number of vehicles has no value if it is not supported by a scalability analysis and appropriate large-scale simulations.

Responses 9:The calculation of the public parameters published by TA was 1+1= 0.7761ms，the TA performed once for all vehicles in region. Assuming there are 100 vehicles in the area, the computation time for a single key for each vehicle is 0.0078ms, which has a negligible impact on overall performance and can thus be ignored.

Comments 10: It is unclear whether the percentage comparisons (lines 362–364, 377–379) imply compared protocols implemented in the same experimental environment or whether the data comes from heterogeneous sources.

Responses 10:The comparison in this experiment is based on the actual data presented in Tables 3 and 4, which were calculated under the same environmental parameters. See the first paragraph of sections 6.1 and 6.2 for parameter settings.

Comments 11:The communication overhead assessment should consider the intrinsic blockchain overhead, including block headers, consensus signatures, and propagation latency. The conducted analysis completely ignores the impact of network congestion and the high mobility typical of VANETs.

Responses 11: To analyze the impact of high-speed mobility in VANET on the proposed scheme, we have included an analysis of additional communication overheads in Section 6.3.

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

From a theoretical point of view, the formalization of cryptographic problems (ECDLP/CDH) remains imprecise instead of being fully rigorous. The security proofs, even declared in the random oracle model, are still partial and also do not comply with established standards, such as EUF-CMA. The game model remains inadequately defined, and the demonstration steps still need to be further justified. Furthermore, the derivation of temporary keys is not described with sufficient clarity and formality.

The presence of the Trusted Authority effectively introduces a central point of trust that clearly conflicts with the stated goal of decentralization. The answers provided on this aspect are merely descriptive and not conclusive.

Some assumptions, such as the negligible cost of the TA, are not supported by large-scale simulations, while the actual impact of blockchain in terms of latency, consensus, and network congestion remains only marginally considered.

Author Response

Comments 1:From a theoretical point of view, the formalization of cryptographic problems (ECDLP/CDH) remains imprecise instead of being fully rigorous. The security proofs, even declared in the random oracle model, are still partial and also do not comply with established standards, such as EUF-CMA. The game model remains inadequately defined, and the demonstration steps still need to be further justified. Furthermore, the derivation of temporary keys is not described with sufficient clarity and formality.

Responses 1: We have reformulated the formalization of the cryptographic problems (ECDLP/CDH), as detailed in Section 3.1. The proof under the random oracle model has been supplemented, as demonstrated in Lemma 1 of Chapter 5. We have provided supplements to address the unclear descriptions in the derivation process of the temporary key. Please refer to Section 4.7.

Comments 2: The presence of the Trusted Authority effectively introduces a central point of trust that clearly conflicts with the stated goal of decentralization. The answers provided on this aspect are merely descriptive and not conclusive.

Responses 2: The article indeed introduces a trusted center. To mitigate the risk associated with a single node in the trusted center, we have incorporated blockchain and implemented hierarchical multi-node management. However, complete decentralization cannot be achieved, so we have revised the descriptions in the abstract and introduction. We sincerely apologize that the current solution is still not fully satisfactory.

Comments3: Some assumptions, such as the negligible cost of the TA, are not supported by large-scale simulations, while the actual impact of blockchain in terms of latency, consensus, and network congestion remains only marginally considered.

Responses 3: We sincerely apologize that currently, we are unable to conduct simulation tests on vannet to measure network latency and throughput. Instead, we can only rely on relevant literature 21 and 23 for quantitative analysis.