Implementation and Evaluation of the Zero-Knowledge Protocol for Identity Card Verification

1  Introduction

Computer and Network Security coupled with cryptography plays a crucial role in safeguarding data at rest and in transit. An identity card is a document that can be used to prove a person’s identity [1]. Identity fraud has been prevalent in most parts of the world and these acts are often perpetuated by cyber criminals often residing within the West African region [2]. Until recently, these cybercriminals targeted Western countries before the uptake of mobile money, internet banking, and government e-services during the COVID-19 pandemic [3,4]. The COVID-19 pandemic accelerated this trend, as remote work, online education, and telemedicine became essential, driving a 70% increase in global internet usage [5]. While this digital transformation enabled continuity during lockdowns, it also exposed vulnerabilities in data security frameworks, leading to a surge in cyber threats such as phishing, ransomware, and data breaches.

Zero Knowledge Proof (ZKP) is a viable solution to all these discussed threats. ZKP has been around theoretical and a few practical applications have been implemented till date. This can be attributed to its computational complexity. Advancements in computing and programming languages bears forth a very secure protocol, which can allow an individual to prove the possession of National ID Card to a verifier without the individual disclosing or releasing any information on the National ID card to verifier. A bad actor either at the National Identification Authority or a bad actor actively monitoring the communication link between the individual and verifier will have no information about the card since no direct card related information was shared in the verification scheme.

Zero-Knowledge Proofs (ZKP) are cryptographic protocols which enables one party (the prover) to demonstrate to another party (the verifier) that a certain statement is true without revealing any information beyond the validity of the statement itself. This concept was first introduced by Goldwasser, Micali, and Rackoff in 1985. ZKPs operate through interactive or non-interactive protocols:

1. Interactive Zero-Knowledge Proofs: In this technique, the prover and verifier have a sequence of interactions. The verifier provides challenges that the prover must answer successfully, indicating knowledge of the truth without exposing the information itself.

2. Non-Interactive Zero-Knowledge Proofs: The prover creates a proof that the verifier can independently validate without additional intervention. This approach frequently depends on shared randomness or cryptographic assumptions.

ZKPs offer several benefits and advantages in improving data security:

1. Improved Security: ZKPs enable the testing of data attributes without revealing the data itself. For example, a user can demonstrate possession of a valid credential without disclosing its information, so maintaining privacy.

2. Enhanced Authentication: By employing ZKPs, systems can authenticate users without transmitting sensitive information, reducing the risk of data interception and misuse.

3. ZKPs enable the testing of data attributes without revealing the data itself. For example, a user can demonstrate possession of a valid credential without disclosing its information, so maintaining privacy.

4. Secure Multi-Party Computation: ZKPs enable collaborative computations in which parties can compute a function over their inputs without disclosing them, hence improving security in applications such as cooperative data analysis.

This research seeks to evaluates existing Zero Knowledge protocols, Identity Card verification schemes, Know-your-customer (KYC) schemes and finally implement a verification scheme with ZKP.

Proof-of-knowledge protocols have primarily remained theoretical due to computational constraints, which historically hindered practical implementations since they were resource expensive and mostly platform dependent. Although some secure authentication schemes exist, they continually implement and carry over a weak link which could be easily compromised and this is the human link in systems and infrastructures. The human link becomes the weakest link in cybersecurity and any secure cryptographic scheme and the need to safeguard data at rest and transit from the weakest link is more than important now [6].

1.1 Background and Research Motivation

In 2020, a group of researchers [7] also explored the use of Zero Knowledge Proof for a two-factor authentication scheme using a trusted device and trusted provisioning server. In their paper they introduced a two–factor login scheme which utilizes zero knowledge proof to convince a server that they are who they are on an unsecured network without transmitting any sensitive information. In this paper a secured device and verification server were used which is synonymous to the architecture of SSL. They introduced a confidentiality and anonymity-preserving scheme tailored for IoT critical infrastructure, specifically addressing cybersecurity threats in sustainable healthcare. To achieve this, they implemented a zero-knowledge proofs-based Authenticated Key Agreement (AKA) protocol for IoHa [8]. These papers will form the basis of this research’s evaluation and implementation of an ID card verification scheme with ZKP. The principal aim of this study is to implement an ID verification scheme with ZKP and also contribute to the knowledge of Zero Knowledge Proof.

The objectives of the research work include:

1.    To compare ZKP schemes with traditional identity verification in terms of privacy and security.

2.    To integrate Camenisch–Lysyanskaya signatures to remove the need for trusted setups.

3.    To evaluate trade-offs between computational overhead and communication complexity.

4.    To implement and experimentally validate the scheme under simulated attack scenarios.

There is a need to have an ID card verification scheme with ZKP which will be an improvement over the existing verification schemes. The following research questions need to be addressed:

1.    What are the theoretical privacy and security advantages of ZKP-based verification over traditional methods in national ID systems?

2.    How do existing implementations of ZKP in other domains (e.g., blockchain, healthcare) address identity theft risks?

3.    What design principles from GDPR/NIST can guide the integration of ZKP into national ID systems?

The outcome of this research will aid system engineers and security architects in developing a more secure ID card verification scheme and in adhering strictly to the directives of the data protection act. The relevant stakeholders could also use this scheme as a standard for verification of ID cards, linked services to the ID Cards and even further extend the protocol to the verification of financial transactions and e-voting schemes. This study will contribute to Zero-Knowledge Proofs while limiting it to only the verification of ID cards.

A limitation of this study is the heavy reliance on JavaScript for client-side computations in the ZKP implementation for client-side computations and if the browser does not fully support JavaScript the proof of concept will not be able to complete the necessary interactive rounds of proof to validate the protocol. With some privacy-first browsers like TOR and Cocoon, JavaScript is also disabled by default hence ID cards cannot be validated in such browsers.

1.2 Organization of the Thesis

The study begins with brief introduction to the research, and then presents an overview of ZKP, ID cards, statement of problem, aim of the study, specific objectives, research questions, and organization of study. Then Section 2 which is the Literature Review, presents a review of related research work. The chapter reviews related published articles on the key concepts of the research, such as zero-knowledge proof-of-identity and the benefits of the technology in the context of identity card verification. The Methodology presents the methodology adopted for testing and analyzing. It includes the installation of tools used, the setup of the test environment for testing. Implementation, testing and Results conducts a comparative evaluation of the benefits of the proposed architecture vis-à-vis existing zero-knowledge proof-of-identity architectures in terms of security, transparency and trust. Finally, Discussions, Conclusions and Recommendations discusses the results for comparative evaluation of the proposed architecture and makes relevant conclusions as well as recommendations for the implementation and evaluation of the zero-knowledge protocol for the verification of identity cards.

2  Literature Review

2.1 Introduction

In the rapidly evolving digital landscape, securing personal data against unauthorized access and misuse has become a critical priority [8]. As the use of mobile devices and personal computing expands, robust authentication mechanisms are essential for protecting sensitive information. Zero-Knowledge Protocols (ZKPs) offer a revolutionary approach to identity verification, allowing individuals to prove their identity without revealing any underlying data [9]. This literature review explores the development, applications, and future directions of ZKPs in the context of identity verification, drawing on existing research and introducing new insights into their potential.

Identity verification has traditionally relied on various mechanisms, such as passwords, biometric data, and multi-factor authentication. These methods, while effective to an extent, involve the exchange and storage of sensitive personal information, which poses significant security risks [10]. Passwords can be forgotten or stolen, biometric data can be spoofed, and multi-factor authentication can be cumbersome and still vulnerable to phishing attacks. In light of these challenges, the need for a more secure and privacy-preserving method of identity verification has become increasingly evident.

Zero-Knowledge Protocols (ZKPs) present an innovative solution to these issues. A ZKP is a cryptographic method by which the prover, can convince the verifier, about how correct a statement is without revealing any extra information beyond the fact that the statement is correct. This concept, initially introduced by Goldwasser, Micali, and Rackoff in 1985, revolutionized the field of cryptography by providing a means to enhance security without compromising privacy [11]. The significance of ZKPs extends beyond theoretical cryptography into practical applications across various domains, including digital identity verification, blockchain technology, and secure communications. The application of ZKPs in identity verification is particularly promising because it allows persons to prove their identity without revealing any private information, thereby addressing privacy concerns and mitigating dangers that comes with breach of data and theft of identity.

In the literature review, we will delve into the evolution of identity verification methods, the fundamentals of Zero-Knowledge Protocols, their historical development, and their application in modern identity verification systems. We will also explore broader applications of ZKPs, regulatory implications, and future research directions.

2.2 Current Authentication Methods

The process of verifying one’s identity has undergone significant transformation over the years. Traditional methods such as passwords and physical tokens have gradually given way to more sophisticated techniques involving biometrics and multi-factor authentication. Each of these methods has its own set of advantages and limitations. The COVID-19 pandemic exacerbated these limitations, as the rapid adoption of remote work and online services increased reliance on weak authentication methods. In Table 1, the current identity verification and authentication methods were compared based on their security risks and ZKP mitigations.

2.2.1 Password-Based Verification

Passwords are the most common form of identity verification. They are simple to implement but suffer from various security vulnerabilities, such as phishing, brute-force attacks, and credential reuse. This increases the risk of unauthorized access. Unlike passwords, ZKP requires no secret transmission, eliminating interception risks.

2.2.2 Biometric Verification

Biometrics, such as fingerprints, facial recognition, and iris scans, provide a higher level of security by leveraging unique physical characteristics of individuals. However, biometric data can be spoofed or stolen, and once compromised, it cannot be changed like a password. ZKP proofs validate biometric ownership without exposing raw data.

2.2.3 Multi-Factor Authentication

Multi-factor authentication (MFA) combines two or more verification factors, such as SMS codes, to enhance security. However, SMS-based MFA is vulnerable to SIM-swapping and man-in-the-middle (MITM) attacks, which can compromise its effectiveness. In contrast, non-interactive zero-knowledge proofs (ZKPs) mitigate these vulnerabilities by reducing dependence on insecure communication channels, thereby offering a more robust approach to authentication in sensitive applications.

The limitations of these traditional methods have paved the way for the exploration of Zero-Knowledge Protocols, which promise enhanced security and privacy.

2.3 Common Types of Breaches

One the most prevalent breaches include:

1.   Phishing: This is the act of using deceptive website or emails to trick users into revealing credentials. During the pandemic, phishing attacks surged by 600%, with attackers exploiting the increased reliance on remote work tools [12].

2.   Man-in-the-Middle (MITM) attacks: Interception of unencrypted data during transmission.

3.   Ransomware: This is the encryption of data for extortion, resulting from the exploitation of weak authentication. Ransomware attacks increased by 148% during the pandemic, with healthcare and education sectors being prime targets [13].

4.   Insider Threats: Employees exploit their access to leak data.

5.   Credential Stuffing: Leaked credentials are reused by attackers across platforms.

2.4 Applications in Identity Verification

One of the most compelling applications of ZKPs is in identity verification. Traditional methods often require the disclosure of sensitive personal information, raising concerns about privacy and the potential misuse of data. ZKPs provide a solution by allowing individuals to show their identity without making known any personal information. This is particularly relevant in digital identity systems, where privacy and security are paramount. Platforms like Ghana.Gov, which rely on National ID card verification systems, face significant challenges, including data breaches and identity theft.

Case Study: National ID Verification

Ghana’s national ID system is vulnerable due to plaintext storage of citizen data and phishing attacks via fraudulent portals. By integrating Zero-Knowledge Proofs (ZKPs), citizens can verify critical attributes (e.g., being over 18) without disclosing sensitive information. This approach minimizes data exposure and complies with the “Privacy by Design” principles [14].

2.5 Broader Applications of Zero-Knowledge Protocols

Beyond identity verification, ZKPs have extensive applications in cryptocurrencies, blockchain technology, two-factor authentication, e-commerce, and online services.

2.5.1 Cryptocurrencies

In the cryptocurrency domain, ZKPs enable confidential transactions that preserve the privacy of transacting parties. Bullet-proofs, a type of zero-interactive zero-knowledge proof, provide short and efficient proofs for confidential transactions [15,16]. Similarly, zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) are used in various blockchain applications to ensure transaction confidentiality and integrity [17]. Table 2 summarizes key applications of ZKPs in cryptocurrencies, highlighting examples such as Zcash for confidential transactions, Ethereum’s zk-SNARKs for blockchain integrity, and Zerocash for anonymous payments, illustrating their role in enhancing privacy and security.

2.5.2 Two-Factor Authentication (2FA)

In two-factor authentication (2FA) systems, ZKPs enhance security by allowing users to authenticate without transmitting sensitive data over insecure channels. Traditional 2FA methods, such as authentication codes sent via SMS or email, are vulnerable to interception. ZKPs address these vulnerabilities by enabling secure verification processes that do not expose sensitive information [18].

2.6 Challenges in Zero Knowledge Proof Implementation

ZKPs offer significant theoretical benefits for data security and privacy; nevertheless, their practical implementation involves notable complexities and computational demands that can impact their feasibility in real-world applications.

2.6.1 Computational Demands in ZKP Implementation

The computational overhead ZKPs incur stems from the mathematical operations necessary to ensure soundness, completeness, and zero-knowledge properties. These demands differ depending on the type of ZKP; interactive or non-interactive, and the underlying cryptographic construction, such as zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) or zk-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge).

1.   Proof Generation: Generating a ZKP entails constructing a cryptographic proof, which frequently requires the prover to execute difficult arithmetic operations over finite fields or elliptic curves. For zk-SNARKs, this includes polynomial evaluations and commitments utilizing pairing-based cryptography [19]. The computational cost scales with the size of the statement being proven, often requiring O(n) to O(n log n) operations, where n represents the number of constraints in the arithmetic circuit encoding the computation. Specialized hardware, such as graphics processing units (GPUs), can help to mitigate bottlenecks by parallelizing compute-intensive tasks like Fast Fourier Transforms (FFTs) and multi-scalar multiplications (MSMs). GPU-accelerated zk-SNARK implementations provide proofs 10–100 times quicker than CPU-based systems [15].

2.   Verification: While zk-SNARKs are succinct, implying verification is efficient (typically O(1) or O(log n)), the verifier must still conduct costly operations, such as elliptic curve pairings. In contrast, zk-STARKs, which avoid trusted setups, use hash functions and polynomial interpolation, leading in greater proof volumes and verification durations that grow logarithmically with the computation size [20].

3.   Setup Phase: Many ZKP systems, notably zk-SNARKs, rely on a trustworthy setup to generate a common reference string (CRS). This procedure requires generating cryptographic parameters, which is computationally expensive and must be conducted securely to avoid compromising the system’s integrity [21].

4.   Energy Efficiency: GPU-optimized ZKP frameworks provide 3–5x greater throughput-per-watt than CPUs, solving sustainability issues in large-scale deployments [15]. Ethereum’s zk-rollups use GPU clusters to execute 1200 transactions per second (TPS), resulting in a 50x gain over CPU-bound solutions.

2.6.2 Implementation Complexities and Trade-Offs

1. Trusted Setup Requirements: zk-SNARKs rely on a secure multi-party computation (MPC) procedure to produce the CRS. A compromised setup compromises the overall system’s security, posing practical and ethical challenges [22]. In contrast, zk-STARKs and Bulletproofs avoid trusted setups while sacrificing proof succinctness or verification speed [17].

2. Most ZKPs (such as zk-SNARKs) rely on elliptic curve encryption, which is susceptible to quantum attacks. Post-quantum alternatives, such as lattice-based ZKPs, are under development, but have a greater computational cost [23].

3. Algorithmic trade-offs: zk-SNARKs are small proofs (~200 bytes) but require trustworthy settings [19]. In zk-STARKs, although quantum-resistant and transparent, proofs are typically ~100 kB in size [17]. Bulletproofs do not require a trusted setup but result in slower verification due to larger proof sizes.

2.6.3 Impact on Implementation Practicality

1. High computational needs can result in longer processing times and higher energy consumption, both of which are significant in applications such as mobile devices and large-scale systems [24].

2. In scenarios requiring several simultaneous proofs, such as blockchain networks, the accumulated computing burden might impede scalability and degrade overall system performance [25].

Developing and integrating ZKPs into existing systems requires specific cryptography knowledge, potentially increasing development costs and time.

2.7 Identity Governance and Administration

Identity Governance and Administration (IGA) is a vital aspect of modern information security frameworks, ensuring organizations can effectively manage digital identities and access rights. The increasing complexity of IT environments and the growing regulatory requirements necessitate robust IGA practices to maintain security, compliance, and operational efficiency. This section elaborates on the key components, strategies, benefits, challenges, best practices, and emerging trends in IGA, referencing authoritative sources from your provided list.

2.7.1 Key Components of Identity Governance and Administration

IGA integrates several functionalities to provide a comprehensive framework for managing identities and access within an organization. The primary components include:

1.    Identity Lifecycle Management which encompasses the processes involved in creating, maintaining, and deactivating user accounts.

2.    Access Management also involves controlling user access to resources.

3.    Role-Based Access Control (RBAC) as well also simplifies access management by assigning permissions to roles rather than individual users.

4.    Policy management ensures that access controls align with organizational policies and regulatory requirements.

5.    Auditing and reporting are critical for maintaining accountability and demonstrating compliance.

2.7.2 Strategies for Effective Identity Governance and Administration

Implementing effective IGA requires a strategic approach that aligns with organizational goals and regulatory requirements. Key strategies include:

1.    The Centralized identity management simplifies the administration of user identities and access controls.

2.    The Risk-based access control tailors access decisions based on the risk associated with granting access.

3.    The Automating provisioning and de-provisioning processes ensures timely and accurate updates to user accounts and access rights.

4.    The Implementing MFA enhances the security of the authentication process by requiring multiple forms of verification.

5.    The Continuous monitoring and auditing are essential for detecting and responding to security threats.

2.7.3 Cryptographic Properties of ZKP vs. Traditional Systems

Zero-Knowledge Proofs (ZKPs) provide unique cryptographic guarantees compared to traditional authentication methods. Below is a formal analysis of their properties. Table 3 compares ZKP-based systems with traditional systems (e.g., RSA, ECC, AES), highlighting advantages such as zero-knowledge privacy with no PII leakage, robust soundness against forged proofs, and quantum-resistant variants like lattice-based ZKPs, alongside trade-offs like higher computational overhead for proof generation.

2.8 Conclusion

Zero-Knowledge Protocols represent a transformative approach to identity verification, offering unparalleled security and privacy. By enabling individuals to prove their identity without revealing personal information, ZKPs address critical challenges associated with traditional verification methods. The application of ZKPs extends beyond identity verification to various domains, including cryptocurrencies, two-factor authentication, and e-commerce. As research continues to advance, ZKPs are poised to play a pivotal role in shaping the future of secure and privacy-preserving digital interactions.

3  Research Methodology

Table 4 defines key notations used throughout this methodology, including symbols for the claimant (C), trusted authority (A), verifier (V), and cryptographic elements like commitments (Com(x, r)) and ZKP proofs (π), facilitating a clear understanding of the system’s variables.

3.1 A Brief Description of the Methodology

This study adopts a quantitative approach to carefully check how well the protocol works and how safe it is. This means gathering and studying data about important things like how long it takes to run the process, how strong the security is, and how much memory is used while the protocol is working. The quantitative analysis helps us accurately check how well the system can grow and how dependable it is in different situations.

The project uses an engineering design process. It starts by figuring out the problem of how to check an identity card without showing personal information. Next, different ZKP systems are examined and the right one is chosen. The design process includes making a system architecture that connects the ZKP with existing identity verification systems, making sure they work well together and are easy to use.

A working solution is created by continuously making and testing models. This means creating the ZKP system, testing it out, and improving the solution based on the results. The final solution is checked using standard methods to make sure it provides better privacy and security while still working well. This method makes sure that the ZKP-based system is strong, scalable, and is good for checking identities in the real world.

3.2 Security Model

The identification card verification system based on Zero-Knowledge Proof (ZKP) follows a well-defined security model that describes roles, assumptions, threat model, adversarial aims, and desirable security attributes. This model offers a formal framework for evaluating the system’s assurances and resistance to assaults.

3.2.1 Roles

The system has three major entities:

1.   Claimant (C): An individual who want to confirm their identification without disclosing personally identifiable information (PII). The claimant creates ZKP proofs to establish possession of valid identifying attributes (such as age and citizenship).

2.   Authority (A): A trustworthy government-approved institution that verifies the claimant’s identification claims using official papers. To ensure the veracity of claims, the authority provides cryptographic signatures (such as Camenisch-Lysyanskaya signatures).

3.   Verifier (V): The entity that verifies ZKP proofs to ensure the correctness of the claimant’s identification characteristics. Following successful verification, the verifier gives access to services (such as government portals).

3.2.2 Assumptions

The security model is based on the following assumptions:

1.   Trusted Authority: The authority (A) is completely trusted to assess claims correctly and securely. It does not save claimant data after validation and does not collaborate with other organizations.

2.   Semi-Honest Verifier: The verifier (V) follows the protocol faithfully but may operate as an honest-yet-curious opponent, seeking to deduce extra information from the proofs or interactions.

3.   Secure Channels: To avoid tampering, communications between C, A, and V are encrypted using secure cryptographic protocols (e.g., SSL/TLS), while attackers may attempt to intercept or replay messages.

4.   Computational Hardness: The system’s security is based on common cryptographic assumptions, such as the discrete logarithm problem or lattice-based hardness for post-quantum variations.

3.2.3 Threat Model

The threat model analyzes attackers with the following capabilities:

1.   External adversaries are malicious actors that can eavesdrop on communications, intercept messages (for example, through man-in-the-middle attacks), or attempt to replay intercepted proofs in order to acquire unauthorized access.

2.   Malicious Claimants are those who seek to manufacture incorrect identity claims or impersonate others by manipulating proofs or promises.

3.   Curious Verifiers: Verifiers who follow the procedure but seek to obtain PII or associate numerous proofs with the same claimant.

4.   No Collusion: The authority and verifier do not conspire since such activity undermines their credibility and the system’s integrity.

3.2.4 Adversarial Goals

1.   Adversaries want to accomplish one or more of the following objectives:

2.   Forgery: Create valid proof of an invalid or unauthorized identity assertion.

Identity theft involves impersonating a valid claimant in order to acquire unlawful access to services.

3.   Privacy Violation: Extract PII or link several proofs to a single claimant, jeopardizing anonymity or unlinkability.

4.   System disruption involves replaying intercepted communications or injecting fake data to disrupt the verification process.

3.2.5 Desired Security Properties

The ZKP-based system aims to accomplish the following security properties:

1.   Soundness: The verifier accepts only genuine identification claims supported by authentic documents and verified by the appropriate authorities. A dishonest claimant cannot manufacture proof of an invalid claim.

2.   Zero-Knowledge: The proofs reveal no information other than the validity of the asserted attribute (e.g., “age > 18”), preventing PII leaking to the verifier or eavesdroppers.

3.   Unforgeability: Adversaries are unable to construct valid proofs or signatures without access to the claimant’s private key or the authority’s consent.

4.   Unlinkability: Multiple proofs from the same claimant cannot be connected to one another or the claimant’s identity, ensuring anonymity between sessions.

5.   Replay Resistance: Nonces, timestamps, or session-specific keys ensure that intercepted proofs cannot be reused between sessions.

3.3 Detailed Description of the Methodology

The methodology for implementing a zero-knowledge protocol (ZKP) for identity card verification follows a clear engineering design process. This process makes sure the system works well and is safe for everyday use. The main steps are:

Ask: The process starts by identifying the problem—how to check a person’s identity using their ID card while keeping private information safe. This stage identifies methods to maintain privacy, especially in sectors like banking and government services where protecting personal information is critical.

Research: A lot of research is done on current ZKP systems to see how they can be used for identity verification. We look at different ways to protect information, the tools to use, and the privacy needs to find the best system.

Imagine: In this stage, many different ideas for solutions are thought of. Possible designs for the identity verification system are being looked at, taking into account how well they can work with current ID card systems, how easy they are for users to use, and how secure they are. The aim here is to understand how ZKP can check a person’s identity without showing their personal information.

Plan: A clear plan is made, showing how the chosen ZKP framework will be added to the system. This involves making flow diagrams, choosing cryptographic libraries, and setting up ways for the cardholder (prover) and authority (verifier) to communicate. The plan also has important steps for building and testing.

Create; The real work on developing the system happens in this stage. The ZKP protocol is used in an identity verification system, and some test versions are created. Cryptographic tools are added to make sure the protocol works safely.

Test: The system is carefully checked to see how secure, fast, and easy it is to use. We measure things like verification speed, scalability, and privacy preservation in specific test situations. We also test for extreme situations, like security problems and too much demand on the system.

Improve: The system gets better step by step based on test results. We fix any problems that slow down performance, cause security risks, or make it hard to use. This makes sure that the final ZKP solution is strong and easy for users. This method makes sure that the identity card verification system using ZKP is created to be very efficient, safe, and private.

3.4 ZKP-Based ID Verification

This part explains our plan for a system that can identify and confirm who you are without sharing any personal information. First, we explain the main parts needed to create our solution. Next, we describe the ID verification process and how it’s used in everyday situations. For platforms like Ghana.Gov, ZKP-based ID verification can significantly enhance security by enabling citizens to prove their identity without revealing sensitive information. The parties get a zero-knowledge identity after a government-approved authority checks and approves their information. Each party can have different names on their legal documents. However, a special identification number, like the National ID number for each person, is something that is common in all identities. The parties can show they have a real identity using their information without revealing any details. This information can be updated. So, if your ID card has expired, you can request to update your identity without sharing personal information. ZKP-based ID verification is special, and a user cannot have two different identities for the same information. If someone is being malicious by sharing their login details, the system will take away the access code, and it will no longer work. We will explain the details of the protocol in the next sections.

3.4.1 Preliminaries

This part gives the basic tools we need to create our ID verification system using zero-knowledge proofs (ZKP).

3.4.2 Notation

We show that we are picking randomly from a set S by writing y∈S. A proof that shows someone knows a relationship R={(x;w):P(x,w)} for a specific instance x is evidence that they know the witness w, as long as the condition P(x,w) is met. A commitment to a value x with some uncertainty r is called Com(x;r). The variable x represents the groups involved in the agreement. The value x in brackets [x] is the encrypted version of x.

3.4.3 Non-Interactive Zero-Knowledge Proof of Knowledge (NIZK)

A Non-Interactive Zero-Knowledge Proof of Knowledge (NIZK) is a way for one person (the prover) to show another person (the verifier) that they know something important (the witness) without actually sharing that information. This can be done without needing to talk or exchange messages back and forth. Unlike interactive zero-knowledge proofs, NIZK systems only need one message from the person proving something to the person checking it. This makes them very efficient for real-life uses like secure logins, digital signatures, and blockchain technology.

Groth (2016) [21] created a system to prove things that has the following features.

1.    NIZK.Setup(1λ)→pp: creates public settings for the bilinear group. It is the starting point for all other processes.

2.    NIZK.Prove(x,w)→π: This creates a proof, where x is the claim and w is the supporting evidence.

3.    NIZK.Verify(π,x)→{0,1}: is a function that checks the proof π against x and returns 1 if it is correct.

3.4.4 CL Signatures

Camenisch-Lysyanskaya (CL) [26] Signatures are a way to create digital signatures that help keep people’s identities private and support secure identification without revealing personal information. CL signatures, created by Jan Camenisch and Anna Lysyanskaya, let a person make signatures for messages they have created without showing the actual content of those messages. The plan helps make quick zero-knowledge proofs, allowing users to show they have a real signature on private data without revealing the data itself. This makes CL signatures perfect for safe systems that rely on identity, where keeping information private is very important. They are often used when people need to stay anonymous, like in online identity checks and secure ways to log in without giving away personal information.

In this study, to create a good identity-based solution for people, they need to get a signature on their private information. So, we use the Camenisch-Lysyanskaya (CL) signature method (2004) to get the signature. Later, we will explain how to show that they know this signature on their information without revealing any details.

CL.Setup: takes a security number 1λ and gives us ppCL=(G,G,g,g,e). These parameters are the starting points for all the other algorithms.

CL.KeyGen: each user does these steps:

1.    Choose x←Zq,y←Zq, and 1≤i≤l,zi←Zq.

2.    Pick x from the set of integers modulo q, pick y from the same set, and choose i such that 1 is less than or equal to i and i is less than or equal to l, where l is an integer and zi is also in the set of integers modulo q.

3.    Let X=gx,Y=gy and, for 1≤i≤l,Zi=gzi,Wi=Zq.

4.    Let X = g raised to the power of x, Y=g raised to the power of y, and for each number i from 1 to l, Zi=g raised to the power of zi. Wi is equal to Zq.

5.    Return sk=(x,y,z1,...,zl), and pk=(q,G,G,g,g,e,X,Y,{Zi},{Wi}).

We utilize the Camenisch–Lysyanskaya (CL) signature scheme based on bilinear maps [26], which requires no trusted setup and provides efficient protocols for signing committed values and proving knowledge of knowledge of such signatures in zero-knowledge. All algorithms (key generation, signing, verification, blind issuance protocol, and ZK proof protocol) follow Camenisch and Lysyanskaya [26].

CL.AskSig: The CL.AskSig algorithm takes as input a structured message M, along with the signer’s secret key and relevant public parameters. It starts with a message M=gm(0)∏i=1lZim(i), which is a special safe version of a set of messages (m(0),m(1),...,m(l)).The signer has a secret key made up of values sk=(x,y,z1,...,zl), and a public key that includes pk=(q,G,G,g,g,e,X,Y,{Zi},{Wi}). Next, it goes on like this.

1.    The user sends a proof that they understand what the commitment means to the person who gives the signature.

PK{(u(0),...,u(l)):M=gu(0)∏i=1lZiu(i)}

CL.IssueSig: The person giving the signature will run the algorithm and will do the following if they are happy with the proof showing that the commitment can be opened.

1.    The issuer picks a random number α→Zq and calculates a=gα. Ai=azi, for 1≤i≤l, let b=ay,Bi=(Ai)y, Let c=axMaxy.

2.    The user shows the signature as σ=(a,{Ai},b,{Bi},c).

CL.Verify: the user runs the algorithm to check if the signature is correct. It takes in pk=(q,G,G,g,g,e,X,Y,Zi), a message M, and a signature σ=(a,Ai,b,Bi,c), and then verifies them in the following way.

1.    {Ai} were made correctly: e(a,Zi)=e(a,Ai).

2.    b and {Bi} were created correctly: e(a,Y)=e(g,b) and e(Ai,Y)=e(g,Bi).

3.    c was made correctly by using e(X,a).e(X,b)m(0)Πi=1le(X,Bi)m(i)=e(g,c).

This signature system allows two people to securely create a signature for a message using a special mathematical method called discrete logarithm and the signer’s public key. The signer can only see a promise related to a group of messages, but this promise keeps the user’s original information secret and does not show any details to the signer.

3.5 System Model

The ZKP-based ID verification system includes a Claimant C who wants to create a zero-knowledge identity proof. They do this by committing to several claims and providing supporting documents (date of birth, full ID details, country of residence, driver’s license, or health certificate). This information is secured with their private key, showing that they know the details in the claim. An Authority A is a government-approved group that can check if the information given by C is real and trustworthy. If A believes that the proofs from C show that the commitment information belongs to the Claimant, it adds a tag to the submitted data that helps create a verification identity based on ZKP.

There is a verifier V, who gets the authentication tag from A, adds it to C‘s proof, and then gives C a special identity that keeps their information secret.

The ZKP-based ID verification is a method that helps prove a person’s identity and other personal information, like health data and memberships, in a safe way. It makes sure that this information is correct and checked by a trusted organization. This way, it follows the law, acts like a Know Your Customer (KYC) process, and is easy to use without showing any private user information.

No identity is completely independent and can make a claim about another identity (like a person, organization, or machine), while still keeping the information trustworthy and easy to check. The protocol is zero-knowledge, which means that the identities of the people involved and any data shared do not give away any information about them or the transactions.

C begins the process by sending their documents and public key, along with an ID number, to authority A. A then checks if everything is valid. If A is happy with the accuracy of the information it got, it creates a tag and sends the same confirmed values to V. Then, C agrees to the information and sends the agreement and proof to V. The verifier signs the claimant’s promise using their own private key. They create proof that shows they know the signature and send it to the person who requested it; each user gets a special zero-knowledge identity.

This process is done only once. Later, imagine that users want to show that they can use a certain website that only needs them to prove they are over 18 years old. In that case, you just need to create a short proof showing the user’s birth year and add it to the identity that uses zero-knowledge proof (ZKP). Using the ZKP-based identity and this sub proof can help convince the website to let the user in and use their services. We describe how the different groups interact in Fig. 1.

Figure 1: Interactions of the parties

3.6 Security Goal

The aim of the proposed solution is to keep people’s personal information safe and make sure that data is accurate.

The proposed system ensures the following standard privacy properties for identity verification:

1. Unlikability:

Multiple ZKP-based verification sessions cannot be linked to the same identity, even by colluding parties (e.g., verifiers or authorities).

Formally, for any two proofs πr1πr2 generated by the same user, no probabilistic polynomial-time adversary can determine πr1 and πr1.

2. Anonymity:

The verifier learns only the validity of the proof (i.e., whether the claimant possesses a valid credential) but gains no information about the claimant’s identity or credential attributes beyond what is explicitly disclosed (e.g., “over 18”).

3. Non-Attributability:

Even if an adversary observes all protocol interactions, they cannot attribute actions (e.g., service access) to a specific identity holder. This is achieved through session-randomized commitments and zero-knowledge proofs.

The authenticator A is assumed to be a trusted entity who doesn’t have access to the system details and is not allowed to keep any information about the individuals after they are approved.

Authority A is a reliable group. We believe it only checks if the document is valid and does not keep a copy of it. In our situation, the person making a claim (C) can be influenced by bad actors who can change the rules of the system and try to change the information to harm the system. Our security goals focus on dealing with these kinds of problems. On the other hand, the verifier is semi-honest, meaning they stick to the rules and cannot change the information. However, it can be curious and may gather information without permission from the things people say and do using the system. In real life, the person checking your identity and the one giving you access are not working together to cheat because doing so could harm both of their reputations.

3.7 Design Challenges

This part shows possible ways that a malicious person might try to attack our system. We also describe our suggested solution for each situation.

One way an attack can happen is when a malicious person (called an “attacker”) makes a fake profile using the personal information of real users (called “claimants”). Let’s say a person gets a ZKP-based identity on their National ID card. The attacker, who doesn’t have a driver’s license, takes the claimant’s document and sends it to the verifier to request a ZKP-based identity on the driver’s license. They do this by providing information about the driver’s license and the attacker’s public key. If the verifier is satisfied with the evidence from the claimant, it gives the ZKP-based identity to the dishonest user. We stop this attack by making sure people confirm their identity before we give them the ZKP-based identity. The people making a claim and the truth of the document must be checked. Once a tag is created and sent to the person checking it, the process continues. If a new ZKP-based identity for the given driving license is not created, the process stops.

Another possibility is that the verifier gives an identity for random messages that the claimant didn’t provide, and then uses the claimant to access some services. The protocol stops the attack by making the person claiming something check the signature given by the verifier to ensure it was computed correctly with the provided data. The process stops if the CL signature made by the verifier does not meet the claimant’s verification needs.

Another situation is when a group has specific rules for who can use their services, and they need users to show that they meet these rules. They can connect two displayed IDs and find out who the people are. We stop this attack by using a special system that keeps information secret and can be changed at random. Different ZKP-based IDs for the same document or two different documents by the same person can’t be connected to each other.

3.8 ZKP-Based ID Verification Construction

This part puts together everything basic and creates a way to check someone’s identity using zero-knowledge proofs. The ZKP-based ID verification system includes the following parts: ID={Id.Setup,Id.KeyGen,Id.Auth,Id.Ask,Id.Issue,Id.Show,Id.Revoke}. Here is a simple explanation of each step. We believe that the government gives each person an identification card before they use it. They get a document with sections labeled as secret. Also, each user has a special ID called wid.

3.8.1 Set Up and Key Generation

ppId←Id.Setup(1λ): The algorithm uses a security parameter λ and calls the CL.Setup function, which generates and gives the system parameters ppCL. It sets ppId=ppCL and uses them in all the algorithms listed below.

A smart contract that works on its own is needed to look at the public information, and this can be done using a smart contract based on zero-knowledge proofs (ZKP). The starting values are given when the contract is set up. Everyone can see it as a simple function or a fixed value. This step removes the need for a trusted setup.

(ski,pki)←Id.KeyGen(ppId): Each party on the ppId calls the key generation method, CL.KeyGen to create a pair of keys for each user i.

3.8.2 Request

R←Id.Auth(wid,doc,Com(pkc),Com(doc)): C sends previously government-issued doc={inf1,inf2,…,infl} with a commitment to its value, Com(doc), the id, wid, and a commitment to their public key Com(pkc) to the authority. We assume that A uses a method like face recognition to make sure that the information is accurate and belongs to the C. The, A outputs a response R=(wid,Com(pkc,v),Com(doc,r),1) to V. If not, it stops the process.

Q←Id.Ask(Com(doc;r),Com(pkc,v)): C gets the information about the claimant’s doc and public key. It uses NIZK.Prove to create a proof that shows knowledge of each infi in the doc and produces the output πdoc based on the provided identity information. It also uses the same method for the public key and gives a proof of the matching secret key πpk. The C sends Q=(Com(pkc;v),πpk),(Com(doc,r),πdoc). To the verifier (V) using the address that corresponds to the wid from the earlier step. In this situation, the verifier gives a secret identity to the person asking for it.

3.8.3 Issue

σ←Issue(R,Q): The verifier gets the authentication response from A for the claimant’s ID, leaving out the wid and 1 parameter. It also gets the request Q from the C. The V says that the commitments from R and Q are the same. Next, V calls NIZK.Verify(πdoc,πpk). If the result is 1, the verifier then calls CL.IssueSig on the Com(doc;r),Com(pkc,v), and the wid, output σ.

Also, the verifier scrambles the request [Q]=Enc(Q,pkO) and [σ]=Enc(Q,pkO) from the claimant σ using the public key of O. It includes wid and sends E=(wid,[Q],[σ]) to the compliance officer. The compliance officer keeps these values in a list.

C uses the signature verification method CL.Verify(σ,pkc,doc,wid)→0/1. It uses three things: the signature σ, the claimant’s public key, and the infi. If C believes that the signature is made correctly using the data given before, it shows 1. If not, it shows 0.

The claimant makes a commitment to this signature and shows they understand it. It produces a unique ID for the user that uses zero-knowledge proof: (Com(σ;u),πσ) for the given document of the person making the claim.

3.8.4 Show

We think that there is a group called M that has specific rules for letting people use its services. For example, the hotel needs to check that the guest’s visa date is valid before they can check in. We call this rule μ, and C needs to show that the ZKP-based ID we gave earlier has a real visa expiration date that matches the M’ requirement. C works like this.

The person making the claim uses the proof-making process of the NIZK proof system to create a proof that infi in the doc meets the access requirement μ. It runs NIZK.Prove(zkID,μ) and sends the proof πμ to the M.

The person making the claim must also show that they have a valid ZKP-based ID, which is proof of membership that shows the ZKP-based ID is in the O′s list L. It uses NIZK.Prove(wid,L,zkID) to create πL.

The claimant provides the outputs (πμ, πL) to demonstrate that they understand the right rules and have valid proof from a verifier.

3.8.5 Revoke

If there is fraud or any changes to the information in a government document that was already issued, the compliance officer O will unlock the information E, cancel the signature for the specific wid, and remove it from the list L with D‘s approval.

The protocol keeps people’s privacy safe when they ask for a zero-knowledge universal identity. Also, this solution helps ensure that the data is accurate and trustworthy. We added to Fig. 1 to show how the algorithm works with a smart contract in Fig. 2.

Figure 2: Architecture of the ZKP-based identity verification system

3.9 Compliance with GDPR and NIST Standards

The ZKP-based ID verification system aligns with GDPR and NIST guidelines through the following design principles. Table 5 outlines how the system ensures compliance, detailing implementations such as data minimization via ZKP attribute validation, strong authentication with non-interactive proofs, post-quantum security, and privacy-focused role-based access control.

4  Data Analysis and Findings

This section deals with the data analysis and presentation of findings. We concentrate on showing two important security properties: replay resistance (ensuring that intercepted communications cannot be replayed) and protection against Personally Identifiable Information (PII) leaks (ensuring that no sensitive data appears in captured packets). In this chapter, four tests were performed to examine the functionality and output of the protocol. These tests include; the man-in-the-middle attack, replay attacks, data breaches and information leakage, and clone attack. For each of these tests, a detailed analysis was performed to ascertain the role the ZKP protocol for identity card verification plays in mitigating these attacks.

4.1 Man-in-the-Middle (MITM) Attack Analysis

A Man-in-the-Middle (MITM) attack involves an attacker intercepting and potentially altering the data exchanged between two communicating parties by inserting themselves between them. Our goal was to ensure that the ZKP protocol eliminates PII leaking and message replay under MITM situations.

4.1.1 MITM Attack Test Setup for ZKP-Based Identity Card Verification

We simulated an MITM attack by redirecting communication between the claimant (client) and verifier (server) via an attacker’s workstation. The attacker attempted to collect and analyze packets with Wireshark in order to extract PII or reuse captured proofs. We have illustrated the man-in-the-middle attack set up in Fig. 3.

Figure 3: Man-in-the-Middle Attack Set-up

The purpose of the test was to establish whether the ZKP protocol could reduce the impact of a MITM attack by keeping confidential information safe, even if intercepted.

4.1.2 MITM Attack Setup

1.    The attacker managed to come between the two parties communicating by altering their ARP caches.

2.    Even though the attacker managed to redirect the traffic to their own server, they were unable to tamper with the ZKP traffic as it did not depend on transferring confidential information such as passwords or personal data. ZKP uses cryptographic evidence instead of sharing personal identity information.

3.    During the MITM attack, it was noticed that there was an extra delay in the communication, suggesting that there was a third party diverting the traffic between the client and server.

The specifications of the test environment were as follows:

The results of the MITM attack simulation, using ARP poisoning, are shown in Table 6:

The average latency was calculated using 20 ping packets in each case to shorten the testing time and make analyzing results easier. To guarantee consistency and accuracy, the test was performed 10 times.

4.1.3 Observations and Results

1.    No PII Leakage: A packet examination found no PII in the collected traffic. The ZKP protocol sends cryptographic proofs (e.g., Com(M, r), σ) instead of raw identification data, assuring zero-knowledge even if packets are intercepted.

2.    Replay Resistance: Because of session-specific nonces and keys, intercepted proofs could not be used again. Since every proof was associated with a distinct session identification, the verifier rejected every replay attempt.

3.    ZKP Resilience: The ZKP protocol demonstrated resilience to the MITM attack. Even though the attacker could intercept and redirect traffic, they were unable to access or alter any important data because Zero Knowledge Proofs (ZKP) only utilize cryptographic proofs, which are of no value to the attacker without the private data needed to create them.

These findings indicate that the ZKP protocol retains privacy and integrity despite MITM attacks, in accordance with the zero-knowledge and soundness criteria.

4.2 Replay Attacks in Zero-Knowledge Protocol for Identity Card Verification

A Replay Attack happens when a hacker captures and sends valid data again to might access without permission. When utilizing the Zero-Knowledge Protocol (ZKP) for ID card verification, a potential attack could occur if an attacker intercepts the communication between a user and the verification system and later replays that information to obtain unauthorized access.

During a replay attack, the offender could resend a previously captured authentication message to the system to pretend to be the real user. If timestamping, nonce usage, or other anti-replay methods are not in place, these attacks can get around traditional authentication systems. If encrypted data is not adequately safeguarded against retransmission, it can still be susceptible to replay attacks.

In Fig. 4, Ann is attempting to demonstrate her identity to Ban through a post. Ban requests her password to verify her identity, to which Ann discloses the password; at the same time, El eavesdrops on the conversation and retains the password. El masquerading as Ann interacts with Ban [27]. A replay attack involves listening to network communication, mimicking a message, and replaying it to the host and devices. The host and equipment do not appear to recognize valid data simultaneously.

Figure 4: Illustration of a replay attack

4.3 Simulation of Replay Attack on ZKP-Based Identity Verification

In order to evaluate the ZKP implementation security for ID card verification against replay attacks, we established a simulation environment based on hardware as detailed in Table 7. It specifies the hardware configurations for the verification server, client, and attacker. The objective was to determine if an intruder could replay verification messages undetected in order to access unauthorized information.

The simulation of a replay attack focused on disrupting the communication between the client (who holds the identity) and the verification system (server). The assault plan aimed to intercept and resend the verification messages, checking if the ZKP protocol could identify and stop the unauthorized resending of such messages.

The test environment was created to simulate a real-life situation where ID card verification is done over a network, with the attacker trying to intercept and replay the verification process. The testbed environment of the attack scenario is described in Fig. 5.

Figure 5: Testbed environment—an attack scenario

4.4 Replay Attack Simulation and Results

The simulation involved the following steps:

1.    The attacker monitored the network traffic between the identity card holder and the verification server using a packet sniffing tool (Wireshark).

2.    After intercepting a valid verification message from the identity holder, the attacker replayed the message to the server.

3.    The replayed message was analyzed to determine if the ZKP protocol could detect the fraudulent verification attempt.

The results of the simulation are summarized in Table 8:

1.    Replay Resistance: All 30 tries failed. The ZKP protocol employs nonces, timestamps, and session-specific keys to ensure that each proof is only valid for one session. The verifier identified reused nonces or expired keys and rejected fraudulent attempts.

2.    No PII Leakage: Captured packets included only cryptographic proofs (e.g., π, σ) and no recoverable PII, confirming the zero-knowledge characteristic.

3.    Unlinkability: Multiple intercepted proofs could not be traced to the same claimant since each proof was unique and randomized for each session.

4.5 Discussion on Replay Attack Prevention in ZKP

The ZKP protocol for identity card verification incorporates robust anti-replay mechanisms, ensuring that any previously used message is rendered invalid upon a second attempt. These mechanisms include:

1.    Nonces: A unique random value generated for each communication session. The server checks the nonce to ensure it has not been reused.

2.    Timestamps: Time-based mechanisms to ensure messages are only valid for a specific period, preventing delayed retransmissions.

3.    Session Keys: Temporary keys that are unique to each session, ensuring that messages are encrypted with a different key each time.

These security measures prevent attackers from effectively using captured data again. In our experiment, the ZKP system effectively thwarted all repeated messages, proving its capability in stopping such attacks.

In this experiment, the identity verification system based on ZKP showed strong protection against replay attacks. The protocol ensures each message is valid only once using nonces, session keys, and timestamps, preventing replay attacks from being successful. The intruder failed to access unauthorized information by replaying messages, demonstrating that ZKP is a reliable way to verify identity cards, even when facing sophisticated network attacks such as replay attempts.

4.6 Data Breaches and Information Leakage Analysis

In this section, we examine the possibility of data breaches and information disclosure in Zero-Knowledge Protocol (ZKP)-enabled and non-ZKP (traditional) identity card verification systems, with the testbed environment detailed in Table 9, specifying the client, server, and attacker configurations. Data breaches happen when unauthorized individuals successfully access crucial information, typically because of insufficient security measures or weaknesses in data transmission procedures. Information leakage is defined as the accidental disclosure of confidential information.

This examination compares the susceptibility of non-ZKP techniques (such as HTTP Basic Authentication) to ZKP-driven identity verification, utilizing network monitoring tools to identify possible vulnerabilities. Both systems were assessed for data risk, exploitation difficulty, and the efficiency of encryption and obfuscation methods.

The test setup imitated common network conditions in which a hacker employs Wireshark to intercept communication between the client and server in order to identify leaks of confidential information. Wireshark monitored and examined traffic in ZKP-enabled and non-ZKP-enabled techniques.

The key specifications of the testbed environment are as follows:

The network topology for this test environment is illustrated in Fig. 6 below:

Figure 6: Network topology for data breach and information leakage analysis

For this analysis, the following steps were taken:

1.    The client logged into a sample web application using non-ZKP-based authentication (HTTP Basic Authentication).

2.    The attacker, equipped with Wireshark, monitored and captured all data packets exchanged between the client and the server.

3.    The captured packets were saved into a .PCAP file for further analysis.

4.    The process was repeated for the ZKP-enabled authentication method to assess whether sensitive data (such as user credentials or personal information) was exposed during transmission.

The results were as follows:

1. Non-ZKP Authentication (HTTP Basic Authentication):

PII Leakage: Captured packets exposed plaintext credentials (username, password) and PII (e.g., complete name), exposing the system to data breaches.

Security Flaw: The lack of encryption allows attackers to extract sensitive data straight from packets.

Fig. 7 shows the Wireshark screenshot of the captured data in the non-ZKP authentication process.

Figure 7: A screenshot of captured data during the non-ZKP authentication process

2. ZKP-Enabled Authentication:

No PII Leakage: Packet analysis revealed only cryptographic proofs (e.g., Com(M, r), π), with no PII or credentials recovered, confirming the zero-knowledge characteristic.

Replay Resistance: Nonces and session keys rendered intercepted proofs worthless in subsequent sessions.

Unlinkability: Proofs could not be traced to a single claimant, so protecting privacy.

Fig. 8 shows the Wireshark screenshot of the captured data in the ZKP authentication process.

Figure 8: A screenshot of captured data during the non-ZKP authentication process

The comparison highlights the superior security of ZKP-enabled systems in preventing data breaches and unintentional information leakage.

4.7 Clone Attack Threat Analysis

The subsequent analysis performed was the Threat Analysis for Clone Attacks, with the testbed environment detailed in Table 10, which outlines the client, server, and attacker configurations. During a clone attack, attackers can effortlessly seize and manipulate sensors to insert numerous clones into the network. These clones possess authentic network access, allowing them to engage in network activities like a real node. Subsequently, the attacker carries out various insider attacks. If these clones go unnoticed at the earliest opportunity, the network will be open to attacks and therefore very fragile. Hence, attackers who clone are extremely damaging. Therefore, in order to prevent this attack [28], we require effective and efficient solutions to minimize their impact by implementing the concept of Secure positioning of wireless devices. Continuous monitoring of nodes makes it difficult to identify potential tampering and duplication. Therefore, it is essential to have reliable and speedy methods for detecting these attacks.

In this study, we assessed the resistance of both the standard non-ZKP authentication method and the ZKP-enabled authentication method against clone attacks. The testing environment replicated a scenario in which a malicious actor tries to copy the identity verification credentials of a genuine user to gain unauthorized access to a secure system. The objective of the analysis was to evaluate how strong the ZKP protocol is in defending against attacks when compared to the weaknesses of traditional authentication methods such as HTTP Basic Authentication.

The test environment was arranged to simulate actual network conditions, and a hacker was brought in to try cloning using specialized tools for copying credentials. The following environment specifications were used:

To perform the clone attack analysis, the following steps were executed:

1.    The client logged into a sample web application using non-ZKP-based authentication (HTTP Basic Authentication).

2.    The attacker used credential-cloning tools to replicate the client’s identity verification credentials. These tools attempted to intercept and duplicate data packets and session tokens exchanged between the client and server.

3.    The attack was repeated using the ZKP-enabled authentication method to evaluate whether the same cloning attempt could successfully replicate and misuse the client’s credentials.

4.    All traffic was captured using Wireshark, and the cloned credentials were saved in a .PCAP file for further analysis.

4.8 Results of the Analysis

1.    Non-ZKP Authentication (HTTP Basic Authentication): The clone attack was successful. The attacker was able to replicate the client’s identity credentials, including username, password, and session tokens. Using these cloned credentials, the attacker gained unauthorized access to the system, effectively impersonating the legitimate user.

2.    ZKP-Enabled Authentication: The clone attack failed. The ZKP protocol, which relies on cryptographic proofs rather than the transmission of sensitive identity data, prevented the attacker from replicating any usable credentials. The zero-knowledge nature of the protocol ensured that no sensitive information could be intercepted, cloned, or reused by the attacker.

These results demonstrate the superior protection offered by ZKP-enabled systems against clone attacks. In contrast to traditional authentication methods, which expose credentials to potential interception and misuse, the ZKP protocol ensures that even if an attacker intercepts communication, no useful information can be cloned or replicated for unauthorized access.

4.9 Performance Analysis

The Zero-Knowledge Protocol (ZKP) for identity card verification provides a balance between security and efficiency, making it an excellent choice for secure authentication systems. This section analyzes the protocol’s performance in terms of computational overhead, message size, and communication efficiency, highlighting its advantages over traditional methods like public-key and symmetric-key protocols.

4.9.1 Computational Efficiency

The computational overhead of using ZKP for identity card verification is minimal when compared to more complicated cryptographic algorithms. In contrast to public-key protocols, which necessitate complex mathematical operations like encryption and decryption with keys, ZKP relies on simpler, lighter computations. This is ideal for situations with limited computational resources, like mobile devices and IoT systems.

In contrast to public-key cryptography’s use of tasks such as modular exponentiation or elliptic curve computations, ZKP has much lower computational demands. This enables quicker verification times while maintaining security, making it perfect for instant authentication procedures such as identity card verification.

4.9.2 Message Size and Communication Overhead

ZKP has the advantage of having a reduced message size compared to previous cryptographic models. As the protocol does not send sensitive information or confidential keys, the message sizes are kept small to reduce bandwidth usage.

Yet, the ZKP-based ID card verification process entails numerous exchanges of information between the client (card holder) and the server (verifying entity). These series of challenge-response pairs are crucial for upholding the zero-knowledge characteristic, making sure that no sensitive information is disclosed by either party in the authentication process. Despite this leading to more communication, it guarantees that the protocol stays strong in the face of threats such as replay or man-in-the-middle attacks.

Even though symmetric-key protocols only need one round of communication, they do not offer the same security as ZKP. The ZKP’s iterative process raises the quantity of communications, yet the total communication overhead is a valuable trade-off for improved security.

4.9.3 Comparison with Other Protocols

In comparison with other widely-used authentication protocols, ZKP offers a unique balance between security and performance, as summarized in Table 11 below.

1.    ZKP: While ZKP requires more communication rounds (multiple iterations) and medium-level computational resources, it offers strong security guarantees without the high computational demands of public-key protocols.

2.    Public-Key Protocols: These protocols are computationally intensive due to the cryptographic operations involved, but they require fewer communication rounds. Their high computational cost can make them less efficient for real-time authentication.

3.    Symmetric-Key Protocols: Symmetric protocols are the most efficient in terms of computation and message size but do not offer the same level of security as ZKP, particularly when key distribution and management are concerns.

4.9.4 Hardware Acceleration for ZKP Efficiency

The integration of specialized hardware, such as GPUs, addresses critical bottlenecks in ZKP implementations. GPUs excel at parallelizing repetitive tasks like elliptic curve operations and FFTs, which dominate proof generation. Key performance improvements include:

1. Reduced Latency: A single NVIDIA A100 GPU processes 1 million MSM points in 2 s, compared to 30 s on a 16-core CPU.

2. Energy Efficiency: GPUs provide 3–5x greater throughput-per-watt than CPUs, resulting in lower energy costs for high-throughput applications like blockchain [15].

3. Scalability: Batch proof generation on GPUs enables simultaneous processing of multiple proofs, as demonstrated by Zcash’s GPU-optimized zk-SNARKs, which increased throughput from 40 to 400 TPS.

4.10 Communication vs. Security Trade-Off

Although ZKP involves a higher number of communication rounds than symmetric-key protocols, this compromise leads to improved security. The client and server engage in several challenge-response interactions to hinder attackers from obtaining any beneficial information when intercepting the communication. This is essential for reducing risks such as replay attacks or impersonation.

In situations where secure identity confirmation is crucial, like in government services, financial institutions, or healthcare, the extra communication steps in ZKP are warranted due to the high level of security it offers. While symmetric protocols may be less computationally intensive and involve fewer communication steps, they lack effectiveness in handling advanced attacks.

The identity card verification Zero-Knowledge Protocol strikes a good balance among computational efficiency, communication overhead, and security. Although it involves more rounds of communication than symmetric-key protocols, it surpasses public-key protocols in computational complexity, making it an appealing option for secure, real-time identity verification. ZKP’s security assurances make it especially apt for high-stakes settings where safeguarding confidential information is crucial.

5  Conclusion

In conclusion, this study demonstrates the transformative potential of Zero-Knowledge Protocols (ZKPs) in redefining identity verification by addressing critical security and privacy challenges. ZKP-based solutions fundamentally eliminate the exposure of personally identifiable information (PII), offering a stark departure from traditional methods reliant on vulnerable hashed or encrypted credentials. For instance, our simulations of man-in-the-middle (MITM) attacks (Section 4.1) revealed that ZKP-based verification prevented data leakage even under interception, whereas conventional methods like HTTP Basic Authentication exposed plaintext credentials. This resilience is further underscored by formal cryptographic analysis (Section 2.8), which highlights ZKP’s soundness and quantum-resistant variants (e.g., lattice-based schemes [24]) as key advantages over classical systems such as RSA and ECC.

Building on ZKP’s proven success in blockchain (e.g., Zcash ) and healthcare [29], our work adapts these principles to national ID systems through the Camenisch-Lysyanskaya (CL) signature scheme. This approach allows citizens to validate credentials—such as birthdates or citizenship—without disclosing sensitive fields, directly mitigating identity theft risks. The architecture’s seamless integration with IoT and blockchain networks (Section 4.10) demonstrates scalability and interoperability, while specialized hardware like GPUs addresses computational bottlenecks, enabling 10–100× faster proof generation for resource-constrained environments.

The system rigorously aligns with global regulatory frameworks, adhering to GDPR’s “Privacy by Design” principle (Article 25 [13]) through cryptographic minimization of data exposure and satisfying NIST’s Authenticator Assurance Levels (AAL3) via non-interactive proofs and hardware-backed key storage (Section 3.7). Comparative analyses with conventional techniques (Table 10) validate ZKP’s balance between communication overhead and computational efficiency, positioning it as a superior alternative for secure, user-centric digital interactions.

By bridging theoretical rigor, practical implementation, and regulatory compliance, this research lays a robust foundation for future advancements in privacy-preserving identity management. These contributions not only advance academic discourse but also empower policymakers and industry stakeholders to adopt ZKP-based solutions, fostering secure and trustworthy digital ecosystems.

Acknowledgement: We thank all reviewers who has participated and will participate in the review of this study.

Funding Statement: We declare that there was no funding to support this study.

Author Contributions: The authors confirm their contributions to this article as follows: Study conception and design: Edward Danso Ansong, Simon Bonsu Osei; Data collection: Simon Bonsu Osei; Results analysis and interpretation: Edward Danso Ansong, Raphael Adjetey Adjei; Manuscript preparation: Edward Danso Ansong, Simon Bonsu Osei, Raphael Adjetey Adjei. All authors reviewed the results and approved the final version of the manuscript.

Availability of Data and Materials: Due to the nature of this study, the authors did not agree to publicly give out their data from this study.

Ethics Approval: This study involves using only synthetic data in simulations. No ethical approval required.

Conflicts of Interest: The authors declare no conflicts of interest to report regarding the present study.

Glossary/Nomenclature/Abbreviations

References

1. Schlatt V, Sedlmeir J, Feulner S, Urbach N. Designing a framework for digital KYC processes built on blockchain-based self-sovereign identity. Inf Manag. 2022;59(7):103553. doi:10.1016/j.im.2021.103553. [Google Scholar] [CrossRef]

2. Rybalchenko L, Ryzhkov E, Ciobanu G. Global consequences of the loss of business in countries around the world caused by fraud. Philos Econ Law Rev. 2022;2(1):118–26. doi:10.31733/2786-491x-2022-1-118-126. [Google Scholar] [CrossRef]

3. Chigada J, Madzinga R. Cyberattacks and threats during COVID-19: a systematic literature review. SA J Inf Manag. 2021;23(1):2–11. doi:10.4102/sajim.v23i1.1277. [Google Scholar] [CrossRef]

4. Aldiabat K, Al-Gasaymeh A, Alebbini M, Alsarayreh A, Alzoubi A, Alhowas E. The COVID-19 pandemic and its impact on consumer’s interaction on mobile banking application: evidence from Jordan. Int J Data Netw Sci. 2022;6(3):953–60. [Google Scholar]

5. ITU. Measuring digital development—facts and figures 2021. Geneva, Switzerland: ITU Publications; 2021. [Google Scholar]

6. Kioskli K, Fotis T, Nifakos S, Mouratidis H. The importance of conceptualising the human-centric approach in maintaining and promoting cybersecurity-hygiene in healthcare 4.0. Appl Sci. 2023;13(6):3410. doi:10.3390/app13063410. [Google Scholar] [CrossRef]

7. Aditya CVV, Megalingam DRK. Zero-knowledge proof based authentication over untrusted networks. Int J Innov Technol Explor Eng. 2020;9(9):238–41. doi:10.35940/ijitee.i6917.079920. [Google Scholar] [CrossRef]

8. Abhishek P, Deshmukh DAR, Yashwant K, Anmo S. Importance of data security and privacy compliance. Int J Res Appl Sci Eng Technol (IJASET). 2023;11(11):1561–5. [Google Scholar]

9. Biegon KC, Kibet A, Kahonge AM. Preserving privacy: how governments and digital services can harness zero-knowledge proofs for secure identification. Int Know Shar Platf. 2023;13(2):63–70. [Google Scholar]

10. Alanzi H, Alkhatib M. Towards improving privacy and security of identity management systems using blockchain technology: a systematic review. Appl Sci. 2022;12(23):12415. doi:10.3390/app122312415. [Google Scholar] [CrossRef]

11. Goldwasser S, Micali S, Rackoff C. The knowledge complexity of interactive proof-systems. In: Proceedings of the Seventeenth Annual ACM Symposium on Theory of Computing—STOC ‘85; 1985 May 6–8; Providence, RI, USA. p. 291–304. doi:10.1145/22145.22178. [Google Scholar] [CrossRef]

12. Bitaab M, Cho H, Oest A, Zhang P, Sun Z, Pourmohamad R. Scam pandemic: how attackers exploit public fear through phishing. In: 2020 APWG Symposium on Electronic Crime Research (eCrime); 2020 Nov 16–19; Boston, MA, USA. p. 1–10. [Google Scholar]

13. Hejase HJ, Fayyad-Kazan HF, Hejase AJ, Moukadem IA. Cyber security amid COVID-19. Comput Inf Sci. 2021;14(2):1–10. doi:10.5539/cis.v14n2p10. [Google Scholar] [CrossRef]

14. Patil C, Jain S, Khare RA, Lahire S. Age verification using zero-knowledge proof. In: 2024 IEEE International Conference on Blockchain and Distributed Systems Security (ICBDS); 2024 Oct 17–19; Pune, India. p. 1–9. doi:10.1109/ICBDS61829.2024.10837396. [Google Scholar] [CrossRef]

15. Bünz B, Bootle J, Boneh D, Poelstra A, Wuille P, Maxwell G. Bulletproofs: short proofs for confidential transactions and more. In: 2018 IEEE Symposium on Security and Privacy (SP); 2018 May 20–24; San Francisco, CA, USA. p. 315–34. doi:10.1109/SP.2018.00020. [Google Scholar] [CrossRef]

16. Naidu D, Wanjari B, Bhojwani R, Suchak S, Baser R, Ray NK. Efficient smart contract for privacy preserving authentication in blockchain using zero knowledge proof. In: 2023 OITS International Conference on Information Technology (OCIT); 2023 Dec 13–15; Raipur, India. p. 969–74. doi:10.1109/OCIT59427.2023.10430710. [Google Scholar] [CrossRef]

17. Chen T, Lu H, Kunpittaya T, Luo A. A review of zk-SNARKs. arXiv:2202.06877. 2022. [Google Scholar]

18. Agal M, Kishan KP, Shashidhar R, Vantmuri SS, Honnavalli P. Non-interactive zero-knowledge proof based authentication. In: 2021 IEEE Mysore Sub Section International Conference (MysuruCon); 2021 Oct 24–25; Hassan, India. p. 837–43. doi:10.1109/MysuruCon52639.2021.9641514. [Google Scholar] [CrossRef]

19. Ben Sasson E, Chiesa A, Garman C, Green M, Miers I, Tromer E, et al. Zerocash: decentralized anonymous payments from Bitcoin. In: 2014 IEEE Symposium on Security and Privacy; 2014 May 18–21; San Jose, CA, USA. p. 459–74. doi:10.1109/sp.2014.36. [Google Scholar] [CrossRef]

20. El-Haj B, Roelink BO. Evaluating the efficiency of zk-SNARK, zk-STARK, and bulletproof in real-world scenarios: a benchmark study. Information. 2024;15(8):23–6. [Google Scholar]

21. Groth J. On the size of pairing-based non-interactive arguments. In: Advances in Cryptology-EUROCRYPT 2016: 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques. Berlin/Heidelberg, Germany: Springer; 2016. p. 305–26. [Google Scholar]

22. Bowe S, Gabizon A, Miers I. Scalable multi-party computation for zk-SNARK parameters in the random beacon model. Cryptology ePrint Archive. 2017. [Google Scholar]

23. Phan DH, Wen W, Yan X, Zheng J. Zero-knowledge proofs of quantumness. Cryptology ePrint Archive. 2025 [Google Scholar]

24. Samudrala S, Wu J, Chen C, Shan H, Ku J, Chen Y, et al. Performance analysis of zero-knowledge proofs. In: 2024 IEEE International Symposium on Workload Characterization (IISWC); 2024 Sep 15–17; Vancouver, BC, Canada. p. 144–55. doi:10.1109/IISWC63097.2024.00022. [Google Scholar] [CrossRef]

25. Pan R, Shi Z, Belloum A, Zhao Z. Operating ZKPs on blockchain: a performance analysis based on hyperledger fabric. In: 2024 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPS); 2024 Jul 15–18; Shanghai, China. p. 69–78. doi:10.1109/DAPPS61106.2024.00018. [Google Scholar] [CrossRef]

26. Camenisch J, Lysyanskaya A. Signature schemes and anonymous credentials from bilinear maps. In: Advances in Cryptology—CRYPTO 2004. Berlin/Heidelberg, Germany: Springer; 2004. p. 56–72. doi:10.1007/978-3-540-28628-8_4. [Google Scholar] [CrossRef]

27. Schuba CL, Krsul IV, Kuhn MG, Spafford EH, Sundaram A, Zamboni D. Analysis of a denial of service attack on TCP. In: Proceedings of 1997 IEEE Symposium on Security and Privacy; 1997 May 4–7; Oakland, CA, USA. p. 208–23. doi:10.1109/SECPRI.1997.601338. [Google Scholar] [CrossRef]

28. Choi H, Zhu S, La Porta TF. SET: detecting node clones in sensor networks. In: 2007 Third International Conference on Security and Privacy in Communications Networks and the Workshops—secureComm 2007. 2007 Sep 17–21; Nice, France. p. 341–50. doi:10.1109/SECCOM.2007.4550353. [Google Scholar] [CrossRef]

29. Alharbi M, Hussain FK. A systematic literature review of blockchain technology for identity management. In: Advanced information networking and applications. Cham, Switzerland: Springer International Publishing; 2022. p. 345–59. doi: 10.1007/978-3-030-99619-2_33. [Google Scholar] [CrossRef]