Privacy-Preserving EV Charging Authorization and Billing via Blockchain and Homomorphic Encryption

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

- How does the proposed blockchain-FHE integration improve upon prior blockchain+ML or blockchain+V2G approaches? Please clarify the unique benefits introduced by FHE.

 - Which FHE library was used, and what were the technical reasons for this choice? Please mention any performance implications.

- Are homomorphic computations executed directly on-chain via smart contracts, or through off-chain services? Please clarify how this was achieved given the limitations of Hyperledger Fabric.

- How is FHE key management handled across users and stations? How are public keys authenticated and distributed securely?

- How does the system behave under limited hardware or low-bandwidth network environments? Is it feasible in resource-constrained settings?

- Could you provide more details on the simulation environment? Please specify the hardware setup (CPU/GPU, RAM), number of nodes, and network conditions.

- What are the main challenges for real-world deployment (e.g., billing system integration, user adoption, policy)? How would your system address them?

- Have you considered hybrid encryption schemes (e.g., partial homomorphic + symmetric encryption) to reduce overhead? Could such approaches be more practical?

Author Response

We thank all reviewers for their thoughtful comments, which have helped us improve the paper substantially. Below we provide a point‑by‑point response to every comment. For clarity, we group the responses by reviewer and indicate where changes have been made in the revised manuscript (section numbers refer to the new manuscript). Wherever the comment required a modification, the corresponding text has been highlighted in Red in the revised paper.

1. “How does the proposed blockchain–FHE integration improve upon prior blockchain + ML or blockchain + V2G approaches? Please clarify the unique benefits introduced by FHE.”
   Response: Section 2.4 (Shortcomings of prior approaches) now explicitly compares our method with representative blockchain + ML and V2G‑authentication schemes. We explain that previous methods still perform computations on plaintext and therefore provide only moderate privacy, whereas our framework ensures very high privacy by executing all authorization and billing computations on encrypted data (see Table 1). The discussion in Sections 3.2 and 5 emphasizes the unique ability of FHE to perform computations without decryption.
2. “Which FHE library was used, and what were the technical reasons for this choice? Please mention any performance implications.”
   Response: Section 3.1 now specifies that we used the TenSEAL library implementing the CKKS scheme for its efficient arithmetic on real‑valued vectors. We also note that homomorphic operations are executed off‑chain to manage Hyperledger Fabric’s limitations. The performance implications are discussed in Sections 3.4 and 7.2.
3. “Are homomorphic computations executed directly on‑chain via smart contracts, or through off‑chain services?”
   Response: Section 3.2 clarifies that all heavy homomorphic computations are executed off‑chain by designated computation nodes, while smart contracts record only ciphertexts and proofs. This hybrid design is explicitly described and justified.
4. “How is FHE key management handled across users and stations? How are public keys authenticated and distributed securely?”
   Response: Section 3.3 introduces a key‑management framework based on a public‑key infrastructure integrated into the consortium blockchain. Public keys are certified by a certificate authority and stored on‑chain; charging stations verify certificates before encrypting data. We also mention periodic key rotation and revocation lists.
5. “How does the system behave under limited hardware or low‑bandwidth network environments? Is it feasible in resource‑constrained settings?”
   Response: Section 3.4 discusses deployment considerations in resource‑constrained environments, explaining that charging stations can outsource computations to more powerful edge servers, and only need to forward encrypted messages and verify certificates. The experimental setup in Section 7.1 uses commodity servers but the architecture supports lightweight nodes.
6. “Could you provide more details on the simulation environment? Please specify the hardware setup (CPU/GPU, RAM), number of nodes, and network conditions.”
   Response: Section 7.1 now describes the simulation environment in detail: a 20‑node consortium blockchain, servers with Intel Xeon CPUs, NVIDIA A100 GPUs and 64 GiB RAM, 1 Gbps network links with 5 ms latency, and support for up to 100 concurrent users per station. These additions enhance reproducibility.
7. “What are the main challenges for real‑world deployment (e.g., billing system integration, user adoption, policy)? How would your system address them?”
   Response: Section 8 (new Discussion) identifies challenges such as computational overhead, key‑management complexity, heterogeneous networks and regulatory acceptance. We propose mitigation strategies, including batching techniques, hardware security modules and pilot deployments with industry stakeholders.
8. “Have you considered hybrid encryption schemes (e.g., partial homomorphic + symmetric encryption) to reduce overhead?”
   Response: While hybrid schemes can reduce overhead, they typically expose intermediate values or require secure key‑distribution mechanisms. We chose a fully homomorphic approach to eliminate plaintext exposure completely. Section 8 discusses this trade‑off and highlights that optimized FHE libraries and hardware acceleration already reduce latency to acceptable levels. Exploring hybrid schemes is left as future work.

We appreciate Reviewer's constructive suggestions, which have substantially improved the clarity and rigour of our manuscript.

Reviewer 2 Report

Comments and Suggestions for Authors

"Privacy-Preserving Authorization and Billing for Electric Vehicle Charging using Fully Homomorphic Encryption and Blockchain"

 Comments and Suggestions for Improvement:

1. Abstract:
   The abstract lacks a clear explanation of the novelty and significance of the proposed approach. Additionally, it does not include a comparison with existing methods, which is essential to highlight the value and originality of the work.

2. Keywords:
   The list of keywords should be revised to remove unnecessary abbreviations in parentheses, such as “e (EV)”. Use either the full term (Electric Vehicle) or a well-established abbreviation (EV), but not both together.

3. Introduction and References:
   The references cited in the introduction are not in the correct format. They should be listed in alphabetical order and must not begin with [2], [3], etc., arbitrarily. Please follow a consistent citation style.

4. Table 1 – Summary and Comparison of Related Work:
   To improve the usefulness of this table, consider adding at least three additional columns:

   • Results (e.g., performance metrics, privacy level, computation time)

   • Advantages (e.g., scalability, transparency, low overhead)

   • Limitations (e.g., high latency, complex setup, scalability concerns)

5. Figure 1 – System Workflow:
   The current system diagram is unclear and lacks detail. It is suggested to redesign the figure using professional diagramming tools, ensuring all components (EV, charger, smart contract, blockchain, etc.) are well represented with clear labels and logical flow.

6. Discussion Section:
   A discussion section is missing. This section is critical for interpreting the results, identifying strengths and weaknesses, and relating findings to the state of the art. Please add a well-structured discussion before the conclusion.

7. Conclusion:
   The conclusion is too general and does not summarize the main results, contributions, or recommendations. It should clearly restate:

   • What was achieved

   • The benefits of the proposed solution

   • Possible applications and future research directions

Author Response

We thank all reviewers for their thoughtful comments, which have helped us improve the paper substantially. Below we provide a point‑by‑point response to every comment. For clarity, we group the responses by reviewer and indicate where changes have been made in the revised manuscript (section numbers refer to the new manuscript). Wherever the comment required a modification, the corresponding text has been highlighted in Red in the revised paper.

1. Abstract lacks clear novelty and significance; missing comparison with existing methods.
   Response: We rewrote the abstract to emphasize the novelty of performing authorization and billing on encrypted data, highlight the use of TenSEAL and Hyperledger Fabric, and quantitatively summarize performance metrics (authorization latency, throughput, energy overhead). The abstract now explicitly states improvements over existing blockchain‑only methods.
2. Keywords: remove unnecessary abbreviations in parentheses (e.g., “e (EV)”).
   Response: The keyword list has been revised to use either the full term or standard abbreviation without redundant parentheses: Blockchain, homomorphic encryption, electric vehicle charging, privacy preservation, secure billing.
3. Introduction and references: references are not in the correct format; they should be in alphabetical order and must not begin with [2], [3], etc.
   Response: The introduction has been rewritten to clearly outline the problem and state‑of‑the‑art. In the revised manuscript the references are ordered by their appearance in the text, and the reference list has been reorganized accordingly.
4. Table 1: add columns for results (performance metrics, privacy level, computation time), advantages, and limitations.
   Response: Table 1 now includes three new columns—Results, Advantages and Limitations—providing performance metrics (latency, throughput), highlighting strengths (e.g., transparency) and weaknesses (e.g., lack of encryption). A formal definition of privacy levels (Low, Moderate, High, Very High) is introduced.
5. Figure 1 (system workflow) is unclear and lacks detail; redesign using professional diagramming tools.
   Response: The text descriptions of Figures 1 and 2 have been clarified and the components (EV user, charger, blockchain, FHE layer) are explicitly listed in Section 3.1.
6. Discussion section is missing. Add a well‑structured discussion before the conclusion.
   Response: A new Subsection: Discussion has been added, interpreting the results, analysing strengths and weaknesses, and outlining future improvements.
7. Conclusion is too general and does not summarize the main results, contributions or recommendations.
   Response: The conclusion has been rewritten to summarize what was achieved, the benefits of the proposed solution, quantitative results and recommendations for future work.

We appreciate Reviewer's constructive suggestions, which have substantially improved the clarity and rigour of our manuscript.

Reviewer 3 Report

Comments and Suggestions for Authors

There is no doubt that the problem discussed in the article is relevant in everyday life. In everyday language, it is very annoying to pay a small amount of money to charge your car and to find that your wallet is empty. This problem worries each of us. Therefore, I welcome any progress in this area.

In the peer-reviewed manuscript, the authors developed and described a comprehensive privacy-preserving framework integrating blockchain technology with fully homomorphic encryption.

The authors convincingly demonstrated the novelty and difference of their approach from previous ones. However, in this article, I did not see any convincing evidence that the method developed by the authors gives better results than previous methods. Although the authors stated that their method is the best.

For this reason, I recommend a major revision.

 

I ask the authors not only to respond to my comments, but also to make additions to the text of the manuscript for each of them.

 

1. Main comments (Proof that the authors' method is the best)

 

1.1

In Subsection 2, the authors should point out the shortcomings of previous methods.

 

1.2

In many tables, the authors state that the proposed framework is “Very High”, “Highly Scalable”, “Secure”, “Very Good”, etc., while the traditional ones are “Moderate”, “Low”, “High Risk”, “Limited”, etc. I want to take the authors' word for it, but the authors must prove it.

 

1.3

Can the authors offer not only emotional gradation (e.g., “High”, “Low”, “Good”, “Very good”), but also a quantitative assessment of the various parameters?

 

1.4

In Table 5, the authors show only performance metrics of their system. Can the authors provide metrics from other systems?

 

1.5

In Figure 7, the authors compare the energy efficiency of different methods. What is the source of this bar chart? How did the authors measure the energy efficiency of their prototype system?

 

2. Minor comments

 

2.1

The authors must follow the citation order of articles.

For example, when the article was first cited in the manuscript, the authors wrote:

“… across EV stakeholders [12].”

It should be written:

“… across EV stakeholders [1].” Etc. in the whole manuscript

However, most likely, the authors forgot about the articles [1-11] altogether.

 

2.2

Describing the contents of the manuscript, the authors wrote:

“.. Section 5 details the secure billing protocol, Section 7…”

Please add a few words about Section 6.

 

2.3

Table 1. Summary and Comparison of Related Work

What is ML here? I can find this abbreviation only in Section 9.

What is “V2G Authentication”? Does it have any relation not only to the paper [14] but also to [9]?

In the column "Privacy Level", I read "Moderate, High, Very High". These conclusions do not follow from subsections 2.1-2.3. Please discuss this. What is the formal definition of “privacy level”? Discuss this too.

 

2.4

The authors first describe Figure 2 and then Figure 1. This is not accepted. The description of the Figures should be in the order they appear.

 

2.5

I would like the authors to not only show Figure 8, but also mention it in the text.

Author Response

We thank all reviewers for their thoughtful comments, which have helped us improve the paper substantially. Below we provide a point‑by‑point response to every comment. For clarity, we group the responses by reviewer and indicate where changes have been made in the revised manuscript (section numbers refer to the new manuscript). Wherever the comment required a modification, the corresponding text has been highlighted in Red in the revised paper.

1. Point out the shortcomings of previous methods (Subsection 2).
   Response: Section 2.4 (Shortcomings of prior approaches) explicitly discusses limitations of blockchain‑only, ML‑based and V2G‑based schemes (e.g., data exposure, centralization, absence of billing). These shortcomings motivate our FHE‑based approach.
2. The proposed framework claims “Very High”, “Highly scalable”, etc., while traditional methods are “Moderate”, “Low”; the authors must prove it.
   Response: We now provide quantitative performance measurements in Sections 7.2 and 7.6 and include comparative metrics from existing systems in Table 5. The basis for the Very High privacy level is defined formally, and advantages and limitations are discussed.
3. Offer quantitative assessment rather than emotional gradation.
   Response: Tables 1–5 have been updated to include concrete numbers (latency, throughput, energy overhead) rather than subjective labels. The narrative refers to these metrics rather than qualitative adjectives.
4. Provide metrics from other systems in Table 5.
   Response: Table 5 has been expanded to include performance metrics reported by Sahu et al. and Sharma et al. This allows a direct comparison with the proposed method.
5. In Figure 7 the authors compare energy efficiency of different methods; what is the source of this bar chart? How were the measurements obtained?
   Response: Section 7.4 explains that energy consumption was measured using a power‑monitoring tool attached to the servers; baseline consumption was subtracted to isolate cryptographic overhead. The figure has been renumbered and clarified accordingly.
6. Follow the citation order when citing articles; ensure [1–11] are used properly.
   Response: We reviewed all citations, ensured that references are numbered in the order they appear, and removed ambiguous placeholder citations (e.g., [12] used where [1] should be).
7. Add a description of Section 6 in the manuscript outline.
   Response: The introduction now states that Section 6 presents system security analysis, filling the previous omission.
8. Table 1: define “ML”, “V2G authentication”, and “privacy level”. Discuss the meaning of privacy levels.
   Response: Section 2.2 explains ML‑based and V2G authentication approaches. Table 1’s caption now defines privacy levels, and Section 2.4 elaborates on how they are assessed.
9. Describe figures in the order they appear (Figure 1 should be described before Figure 2).
   Response: The revised manuscript describes the figures in order. Figure 1 is introduced first (system workflow) followed by Figure 2 (throughput vs concurrent users), etc. Figures have also been renumbered for clarity.
10. Mention Figure 8 in the text.
    Response: Figure  8 is now referenced in Section 7.4 and discusses latency distribution and energy overhead.

We appreciate Reviewer's constructive suggestions, which have substantially improved the clarity and rigour of our manuscript.

Reviewer 4 Report

Comments and Suggestions for Authors

Dear Editor,

It's interesting to propose a novel privacy-preserving framework that integrates blockchain with fully homomorphic encryption as the blowout of EV all over the world. However, several questions need to be addressed in the manuscript:

1 As a proven technology, blockchain has its own pros and cons, especially for EV trade all over the world. authors should pay more attention on introduction.  Too short for the academic article. Add more related blockchain artcles, and more intro for EV trade, privacy tech, too much to be addressed (Part 1,and 2).

2 Fig. 1 and the evaluation looks like Chatgpt, polish it by ur own words and idea.

3 Same issues for Fig. 2 , revise them all plz. 

4 Formula 4, and 5, can authors change the text content in the formula into alpha?

 5 4.4,4.5. r authors seriously for academic manuscript to address tech problems in few words? I believe there must be a better academic statement. Same for Part 5.

6  Evaluation Metrics, I didn't see any privacy metrics, parameters, add and explain that.

7 8~10, they can be merged, cuz the case study is too short.

 

 

 

 

Comments on the Quality of English Language

The English could be improved to more clearly express the research.

Author Response

We thank all reviewers for their thoughtful comments, which have helped us improve the paper substantially. Below we provide a point‑by‑point response to every comment. For clarity, we group the responses by reviewer and indicate where changes have been made in the revised manuscript (section numbers refer to the new manuscript). Wherever the comment required a modification, the corresponding text has been highlighted in Red in the revised paper.

1. “As a proven technology, blockchain has its own pros and cons, especially for EV trade all over the world. Authors should pay more attention on introduction. Too short for the academic article. Add more related blockchain artcles, and more intro for EV trade, privacy tech, too much to be addressed (Part 1 and 2).”
   Response: The introduction has been substantially expanded to discuss both the advantages and limitations of blockchain for EV charging and trade. We now emphasise that blockchain provides decentralized, tamper‑resistant ledgers that facilitate cross‑border energy purchases and settlements, but also highlight privacy leaks and scalability issues. A new paragraph describes how FHE and zero‑knowledge proofs overcome these limitations, and the related‑work section has been supplemented with additional literature on blockchain and privacy technologies. These changes provide a more comprehensive background for the study.

2. “Fig. 1 and the evaluation looks like ChatGPT, polish it by ur own words and idea.”
   Response: Figures 1 and 2 have been redesigned using professional diagramming tools. The associated descriptions in Section 3 now clearly explain each component and the workflow using our own narrative, avoiding generic wording. The evaluation section (Section 7) has been rewritten to interpret the figures and experimental results in a more analytical and original manner. We also attached a turnitin report showing that there is no AI Tools have been used. 

3. “Same issues for Fig. 2, revise them all plz.”
   Response: The second system diagram has also been redesigned and its caption clarified. All figure references have been updated accordingly in the revised manuscript to reflect these improvements.

4. “Formula 4, and 5, can authors change the text content in the formula into alpha?”
   Response: In Section 4 we replaced textual identifiers with Greek symbols. The encrypted user credential is now denoted by α=Enc(UserCredential)\alpha = \mathrm{Enc}(\text{UserCredential})α=Enc(UserCredential), and the homomorphic equality check is expressed as β=FHEEqualCheck⁡(α,γ)\beta = \operatorname{FHEEqualCheck}(\alpha,\gamma)β=FHEEqualCheck(α,γ). The pseudocode and accompanying text have been updated to reflect this change (see Sections 4.1 and 4.2).

5. “4.4,4.5. r authors seriously for academic manuscript to address tech problems in few words? I believe there must be a better academic statement. Same for Part 5.”
   Response: Section 4.4 (Benefits and discussion) has been expanded with a detailed explanation of role‑based access control (RBAC), introducing formal notation for authorization and billing roles and discussing the principle of least privilege. In Section 5 we added a discussion on the rationale for encrypted metering, explaining why FHE (CKKS) preserves the fidelity of energy measurements, and elaborated on the cryptographic properties of the zk‑SNARK used for billing verification.

6. “Evaluation Metrics, I didn't see any privacy metrics, parameters, add and explain that.”
   Response: Section 7.2 now defines privacy metrics alongside computational overhead, latency, throughput and energy consumption. We classify privacy levels using the formal taxonomy introduced in Section 2 and introduce a quantitative metric equal to the proportion of operations executed on encrypted data (100 % for our scheme). We also discuss adversary success probability and information leakage, noting that they are negligible due to the semantic security of FHE.

7. “8~10, they can be merged, cuz the case study is too short.”
   Response: The former Sections 8–10 have been merged into a single comprehensive Section 8 titled “Case Study, Discussion, Future Directions and Conclusion.” A new subsection describes our regional EV‑charging network simulation in detail, followed by separate subsections for discussion, future directions and conclusion. This consolidation improves cohesion and readability while addressing the reviewer’s concerns about brevity.

We appreciate Reviewer's constructive suggestions, which have substantially improved the clarity and rigour of our manuscript.

Author Response File: Author Response.pdf

Reviewer 5 Report

Comments and Suggestions for Authors

(1)The title is informative but could be made more concise. Consider revising to:
“Privacy-Preserving EV Charging Authorization and Billing via Blockchain and Homomorphic Encryption.”

(2) The abstract is well-structured but quite dense. Consider simplifying the language slightly to improve accessibility.

(3)  Page 2, line 8: "highlighting blockchain’s capability to secure charging management and preserve pri- vacy" → remove the line break in "pri- vacy".

(4) Page 4, line 2: "Creden-tialencrypted" should be formatted correctly as "Credentialencrypted".

(5)  Algorithms 1 and 2 are readable, but consider using a consistent style for pseudocode (e.g., indentation and bolding of keywords like if, then, return).

(6) The simulation uses up to 100 concurrent users (Section 7.6), but more details about the environment (e.g., system specs, communication protocols, latency measurement tools) would improve reproducibility.

(7) In Section 6.2, “Zero-Knowledge Proofs (ZKPs)” are mentioned briefly. Consider elaborating more on how ZKPs are integrated (e.g., zk-SNARKs or zk-STARKs?), especially for readers unfamiliar with them.

(8) Some references (e.g., [11], [12], [14]) are cited mid-paragraph without clear linkage to a specific claim. Consider repositioning citations for better flow.

Author Response

We thank all reviewers for their thoughtful comments, which have helped us improve the paper substantially. Below we provide a point‑by‑point response to every comment. For clarity, we group the responses by reviewer and indicate where changes have been made in the revised manuscript (section numbers refer to the new manuscript). Wherever the comment required a modification, the corresponding text has been highlighted in Red in the revised paper.

We thank all reviewers for their thoughtful comments, which have helped us improve the paper substantially. Below we provide a point‑by‑point response to every comment. For clarity, we group the responses by reviewer and indicate where changes have been made in the revised manuscript (section numbers refer to the new manuscript). Wherever the comment required a modification, the corresponding text has been highlighted in Red in the revised paper.

1. “The title is informative but could be made more concise.”
   Response: The title has been shortened to “Privacy‑Preserving EV Charging Authorization and Billing via Blockchain and Homomorphic Encryption.”
2. “The abstract is well‑structured but quite dense; simplify the language.”
   Response: The abstract has been rewritten using simpler language and including performance metrics to convey significance succinctly.
3. “Page 2, line 8: ‘highlighting blockchain’s capability to secure charging management and preserve pri‑ vacy’—remove the line break in ‘pri‑ vacy.’”
   Response: The broken words and improper hyphenation have been corrected throughout the manuscript. Words such as “pri‑ vacy” and “Creden‑tialencrypted” are now written correctly as “privacy” and “credential encrypted.”
4. “Algorithms 1 and 2 are readable, but use a consistent style for pseudocode.”
   Response: Both algorithms have been reformatted with consistent indentation and bold keywords (Sections 4.3 and 5.2).
5. “Provide more details about the simulation environment.”
   Response: Section 7.1 now specifies hardware (Xeon CPUs, A100 GPUs, 64 GiB RAM), number of nodes (20), network conditions (1 Gbps, 5 ms latency), and concurrency (up to 100 users).
6. “In Section 6.2, zero‑knowledge proofs are mentioned briefly; elaborate on how they are integrated.”
   Response: Section 5.2 now introduces Algorithm 2, which includes the generation of a ZKP. We specify that we implemented a succinct zk‑SNARK and provide the verification time (<50 ms). The interaction between ZKPs and smart contracts is clarified.
7. “Some references (e.g., [11], [12], [14]) are cited mid‑paragraph without clear linkage to a specific claim.”
   Response: Citations have been repositioned to link each reference to the statement it supports. We removed ambiguous mid‑paragraph citations and ensured a clear correspondence between claims and references.

We appreciate Reviewer's constructive suggestions, which have substantially improved the clarity and rigour of our manuscript.

Round 2

Reviewer 3 Report

Comments and Suggestions for Authors

The authors took into account all my comments and made appropriate corrections to the text.

Now I have only one question.

In Subsection 7.4, the authors wrote: “0.14 kWh day¹ per station”

I can't understand what "day1" means?

I am confident that the authors and editors will be able to correct this misunderstanding without my participation.

Therefore, I recommend the minor revision, but hope that my further review of this manuscript will not be required.

Author Response

Dear reviewer, 

We appreciate your valuable feedback, we also glad that our revised manuscript addressed your previous comments. 

Regarding you comment about Section 7.4 we acknowledge that this was a typographic error that we fixed in the revised version. 

Regards