Securing Digital Identity in the Zero Trust Architecture: A Blockchain Approach to Privacy-Focused Multi-Factor Authentication

As network systems advance and become more sophisticated, the associated security challenges grow more complex. The zero trust model emerges as a new paradigm to address this, significantly emphasizing robust and continuous identity verification. Multi-factor authentication (MFA) methods have become crucial for enhancing authentication security within this framework. Additionally, the integration of blockchain technology is increasingly recognized for its potential to strengthen identity trustworthiness further, complementing the zero trust approach by providing a more secure and transparent identity verification process. However, privacy concerns remain, especially in public blockchain environments where personal data is vulnerable to inadvertent exposure. Also, using centralized servers for authentication, even in systems integrated with blockchain, presents the risk of creating single points of failure. This paper introduces a privacy-preserving MFA system that harnesses the decentralized capabilities of blockchain technology to enable a Distributed Authentication Mechanism (DAM) as a network of authenticators for enhancing the reliability of the authentication process. This system utilizes blockchain-based Zero-Knowledge Proofs (ZKP) as a privacy mechanism to prove the knowledge of a One-Time Password (OTP). This approach not only ensures the authenticity of the proof authenticity but also confirms the identity of the prover. In the final stage of the MFA process, non-transferable, non-fungible tokens (NFTs) are employed as authentication tokens for identity verification. Our experimental results and comparative security analyses suggest a relevant contribution to secure, private, and dependable MFA framework research.

SECTION I. Introduction

The evolution of network systems has transformed the traditional network security concept. Historically, network access was confined to specific physical locations, such as the premises of a company, where security was primarily managed through physical means and supplemented by basic authentication mechanisms [1]. However, technologies such as Software Defined Networking (SDN), Network Function Virtualization (NFV), and cloud computing have redefined networks, extending their reach beyond physical boundaries [2]. This shift has rendered traditional perimeter-based security measures insufficient, as users can now access network resources virtually anywhere, introducing numerous new security challenges [3].

The emergence of the zero trust model signifies a paradigm shift in addressing contemporary security challenges [4]. Unlike traditional models focusing on securing the perimeter, zero trust operates on a principle of “never trust, always verify,” recognizing that threats can originate from outside and inside the network. This approach requires a robust authentication system and continuous verification of all users and devices, regardless of location or point of access.

A key component in this new model is the emphasis on identity verification, acknowledging that authentication is essential for network access control. As digital environments have advanced, authentication methods have evolved from simple password-based systems to more sophisticated Multi-Factor Authentication (MFA) techniques. MFA enhances security by requiring multiple verification forms, mitigating risks associated with weak or compromised credentials [5], [6].

Despite their efficacy, MFA systems face their own set of challenges. These systems are not immune to sophisticated cyber-attacks like man-in-the-browser (MITB) and man-in-the-middle attacks (MITM), which can potentially compromise the reliability of the messages exchanged in the authentication process [7], [8]. Furthermore, the centralized nature of many authentication systems introduces single points of failure, making them attractive targets for malicious actors [9]. The centralization of authentication systems, particularly those relying on Public Key Infrastructure (PKI) and Certificate Authorities (CA), raises concerns about trust and the integrity of the security mechanisms. If the integrity of a CA is compromised, it can result in widespread security vulnerabilities [10].

Blockchain technology presents an opportunity in this context. Its decentralized and immutable ledger offers a robust solution for enhancing the reliability of MFA systems and supporting the principles of zero trust [11], [12], [13]. At its core, blockchain is a data structure designed for verifiability and distribution of trust. When integrated into an authentication system, characteristics of the blockchain can enhance the resilience of the system resilience against potential threats [14]. The distributed ledger of the blockchain technology ensures that every transaction, or in this case, every authentication event, is independently verified and recorded across multiple nodes. This evenly distributes trust among numerous entities, reducing the risk of centralized vulnerabilities and ensuring that each authentication step is transparent and immutable. The tamper-proof nature of blockchain records means that once an authentication event is logged, it cannot be altered or deleted, providing a clear, unchangeable history of access and identity verification.

The distribution of the trust model is achieved through a consensus mechanism [15]. This approach makes compromising the blockchain challenging, as it would require influencing most nodes rather than targeting a single point of failure. Additionally, using smart contracts [16] in blockchain for authentication strengthens security by automating tasks like credential verification and access control. These contracts execute based on unchangeable, predefined rules, ensuring a verifiable and consistent mode of operation that can be tuned to the security requirements of authentication tasks.

However, while blockchain holds promise for security enhancements, it also raises privacy concerns, particularly in public blockchain environments where transaction details are transparent and accessible to all [17]. Also, despite the decentralized nature of blockchain, its practical implementation often involves interaction through Web3 applications or traditional server models, which are commonly centralized. As a result, these centralized servers or applications become potential targets for cyber-attacks. A successful breach in these systems could compromise the entire authentication process, negating the decentralized security benefits of the blockchain. Therefore, a solution that not only leverages the security benefits of blockchain but also addresses the privacy and centralization vulnerabilities inherent in the current models of blockchain interaction is needed.

This paper introduces a novel, distributed, and privacy-preserving multi-factor authentication framework within zero trust Networks, aiming to address the challenges in current blockchain-based authentication methods. In this framework, a Distributed Authentication Mechanism (DAM) is utilized, where each node within the blockchain network plays an authentication part, distributing the MFA functionality across the network. A partial secret generation scheme is integrated into the DAM, where every participating node contributes to creating a segment of a secret. These segments are then aggregated as a One-Time Password (OTP) used in the multi-factor authentication process.

The proposed framework incorporates a Zero-Knowledge Proof (ZKP) scheme based on a Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARKS) approach to ensure the privacy and secrecy of the OTP verification. This scheme allows the authentication process to verify the OTP without revealing its value, thus maintaining confidentiality and preventing exposure to third parties. This paper proposes a method for verifying the ZKP through on-chain transactions using smart contracts to ensure the identity of the ZKP prover. In addition to these measures, the framework employs modified ERC721 tokens to create unique, untransferable authentication tokens. These tokens, which have a specific period of validity, are used for authenticating user access within their valid time frame. The authentication mechanism is secured using the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Cryptography (ECC), providing asymmetric encryption methods to ensure the reliability and integrity of communications during the MFA process. A proof of concept of the proposed mechanism is realized through an open-source Ethereum blockchain deployment, smart contracts, Web3 libraries, and an open-source ZKP framework. The main contributions of this work are as follows:

• We propose a DAM that capitalizes on the decentralized architecture of blockchain technology. This approach places the authentication functionality on each validator node within the blockchain, eliminating single points of failure and enhancing system resilience.

• We suggest a distributed method for OTP creation, where each validator node in the blockchain network contributes to generating a partial secret. This collaborative method aims to minimize attacks on software-based random number generators (RNG) by not relying on a single entity.

• We leverage the inherent traceability of the blockchain to enhance the reliability of ZKP verifications, ensuring they are recorded and validated on the blockchain. By placing the ZKP verification on-chain, a smart contract can reliably verify the identity of the prover before accepting a ZKP proof.

• We introduce the use of untransferable authentication tokens within our framework. Based on modified ERC721 standards, these tokens provide a secure and controlled method for verifying user authentication. They are designed with a specific validity period and cannot be transferred between users, ensuring the authentication process remains regulated and secure.

The paper is organized as follows: Section II presents the related work with relevant studies concerning blockchain authentication. Section III discusses the supporting technology and concepts utilized in the proposed system. Section IV presents the proposed system description. Section V describes the approach taken to implement the system as a proof of concept. Section VI discusses the experimental testbed, security comparative analysis, and performance results. Finally, Section VII concludes the paper.

SECTION II. Related Work

Several studies focus on the integration of blockchain into the authentication process. In [18], the authors explore the potential of blockchain technology for enhancing online authentication and identity verification while emphasizing the current limitations of online authentication methods, which rely on passwords or occasionally dual-factor authentication via SMS or third-party services. According to the authors, blockchain could offer a more robust solution with its decentralized ledger system. Distributing the ledger across the network prevents malicious alterations, ensuring data integrity. The authors propose using public key encryption, such as Rivest–Shamir–Adlema (RSA), to securely transmit credentials, which can then be verified against an entry in the immutable blockchain, offering a highly secure method for identity verification. In [19], the authors introduce “AuthChain,” a decentralized blockchain-based authentication system designed to address the vulnerabilities of centralized authentication providers, which are susceptible to large-scale account hacking. By leveraging Distributed Ledger Technology (DLT), AuthChain decentralizes the ownership of credentials, providing a secure platform for online service providers to authenticate users, thereby reducing the risk of attacks and data leaks. While the proposed solutions in [18], [19] offer a tamper-proof method to verify personal data, incorporating a privacy-preserving approach can address the concerns about storing some user information as plain text data in the blockchain.

In [20], the authors address the challenges posed by the use of low-cost sensors in IoT. These cost-effective sensors often compromise data accuracy, quality, and reliability. The authors highlight fog computing as a potential solution to these issues but also point out its inherent security challenges due to its distributed architecture. The paper introduces a decentralized user authentication system that leverages blockchain technology, specifically Ethereum smart contracts. The system employs email addresses, usernames, Ethereum addresses, passwords, and biometric data for user registration and authentication. A significant drawback of the research is using personal information, such as usernames and passwords, as input for Ethereum smart contract functions used in authentication. Even if the transaction data is encoded, parameter values can be derived from the bytecode, which is publicly accessible, potentially revealing sensitive information.

The authors in [21] address the security vulnerabilities of emerging metaverse platforms like Roblox, Minecraft, and Fortnite. The paper introduces a blockchain-based system model for secure communication in the metaverse, recognizing the risks of managing sensitive user data on public channels. This model employs ECC and biometric data for enhanced mutual authentication between users and platform servers. Through security analysis, the authors demonstrate the robustness of their proposed authentication scheme against potential threats. In [22], the authors explore the challenges of centralized authentication mechanisms in the metaverse. Given the dynamic interactions of users, avatars, and devices across various technologies like Augmented Reality (AR), Virtual Reality (VR), and Extended Reality (XR), the paper highlights issues such as impersonation, server spoofing, and mutual authentication. They introduce a blockchain-enabled architecture designed to authenticate avatars and users securely within the metaverse. By linking an identity with a blockchain implementation, their proposed framework decentralizes authentication and ensures traceability of avatars, addressing several security concerns. However, the framework proposed by the authors in [21] has a notable limitation: it relies on an entity functioning as a CA, which becomes a potential single point of failure due to operating outside the blockchain. This issue is addressed in the design presented in [22]. However, the authors assume that their framework inherently ensures privacy through the use of blockchain technology. Nevertheless, without additional mechanisms to guarantee privacy, data stored on the blockchain remains accessible and viewable by anyone with access to it.

In [23], [24], the authors address the security concerns of 2FA in the IoT domain. While 2FA offers enhanced protection through OTP, its reliance on third-party services for token generation poses significant risks, including potential information leaks and susceptibility to Man-In-The-Middle (MITM) attacks. The papers introduce a Two-Factor Authentication (2FA) mechanism leveraging blockchain and smart contract technologies to mitigate these vulnerabilities. However, the application responsible for smart contract interaction during 2FA verification is centralized, which serves as a single point of failure for the system. In [25], the authors introduce an out-of-band two-factor authentication scheme tailored for IoT devices, leveraging the blockchain infrastructure. However, the profile information of the IoT devices is stored plainly in the blockchain, which can reveal sensitive information about the device.

In [26], the authors introduce a two-factor authentication framework that eliminates the need for third-party services for token or OTP generation. The framework integrates the Ethereum blockchain with a decentralized application (dApp) to offer a robust defense against token theft and MITM attacks. However, the authentication token creation method currently operates outside the blockchain. The research could utilize blockchain-based tokens to ensure their validity and proof of ownership. The authors in [27] introduce the Microservices and Blockchain-Based OTP protocol. This protocol decentralizes the authentication process to mitigate risks such as denial of service (DoS) and MITM attacks. The versatility of the protocol is highlighted by its adaptability to both private and public blockchain configurations. However, the multiple blockchain transactions executed during the OTP process affect OTP generation in performance tests. In [28], the authors address the vulnerabilities of the widely used OTP-SMS method in 2FA, especially its susceptibility to MITM and third-party attacks. By leveraging blockchain technology and smart contracts, the proposed framework encrypts the OTP, enhancing the security and efficiency of the authentication process. However, since the authors create the OTP on-chain using the smart contract functionality of Ethereum, there is a need for further evaluation regarding the security of the OTP, which is important to consider because all information stored on the blockchain can be accessed.

In [29], the authors recognize the deficiency of traditional username and password systems and introduce “BAuth-ZKP,” a blockchain-based multi-factor authentication mechanism. Their approach leverages smart contracts and ZKP to facilitate secure and privacy-preserving transactions within the smart city ecosystem. However, the ZKP mechanism is not fully disclosed. Meanwhile, in [30], the authors propose the integration of blockchain with multi-factor authentication, emphasizing its potential to build trust across different IoT domains. Their proposed protocol encodes multiple authentication factors using hardware fingerprints, minimizing storage overhead on the blockchain and ensuring efficient verification of un-linkable identities. However, the authentication relies on a single trusted authority per domain, which can serve as a potential single point of failure.

SECTION III. Preliminaries

A. Zero Trust

The term “zero trust” was conceived by John Kindervag while at Forrester Research [31]. The report “No More Chewy Centers: The Zero Trust Model of Information Security” [32] centered on recognizing the weakness of current security models and how the “trust but verify” approach cannot be adequate to avoid modern threats as most attacks come from positions of trust. According to Forrester, the three key fundamental principles of the zero trust model are “all sources must be verified and secured”, “access control”, and “inspect and log all network traffic.”

An architecture standard for zero trust has been proposed by the National Institute of Standards and Technology (NIST) [33]. Considering the recommendations of Forrester, NIST emphasizes the critical role of identity and credential management in the zero trust architecture. This approach is centered on the principle that trust is never assumed and must be continually validated. The framework proposed by NIST highlights that rigorous authentication and authorization are central to the zero trust model. Through continuous validation of identity and security status, the zero trust architecture seeks to minimize unauthorized access risks and enhance overall network security, reflecting a shift from traditional perimeter-based security models to a more dynamic, identity-centric approach.

B. Blockchain

Blockchain technology reinforces the fundamental tenets of zero trust by offering a secure, transparent, and tamper-proof authentication mechanism. In a blockchain network, trust is distributed across all participating nodes through cryptographic algorithms and consensus mechanisms [34].

The integrity and consistency of data within a blockchain network are maintained through consensus mechanisms like Proof of Work (PoW), Proof of Stake (PoS), and Proof of Authority (PoA), ensuring unanimity among nodes [35], [36]. The Quorum Byzantine Fault Tolerance (QBFT) consensus is an example, where validators vote on the validity of a proposed block, with a supermajority (typically 2/3) required for block addition [37]. QBFT operates as an enhancement of the Practical Byzantine Fault Tolerance (PBFT) mechanism. In a QBFT system, up to f nodes can be faulty, as shown in (1), where n signifies the total number of validator nodes present. To achieve consensus on a transaction or specific state, approval is mandated from at least h validator nodes, as shown in (2). $$\begin{align*} f=& \frac {n-1}{3} \tag {1}\\ h=& \frac {2n}{3} + 1 \tag {2}\end{align*}$$

Each transaction added to the blockchain is verified and recorded across multiple nodes, ensuring transparency and immutability. This decentralized architecture eliminates the need for a central authority and minimizes the risk of a single point of failure or malicious manipulation.

Furthermore, the cryptographic techniques employed in blockchain ensure that data integrity is maintained, enhancing security and mitigating the risk of unauthorized access or tampering. Participants in the blockchain network utilize cryptographic key pairs for secure transactions, where a private key $(PrK)$ signs transactions and a corresponding public key $(PuK)$ verifies ownership and integrity [38]. Addresses $(PuAdd)$ generated from public keys allow for the association of identity attributes in a manner that is both verifiable and resistant to fraud. This attribute makes blockchain addresses particularly useful in authentication systems for verifying the uniqueness and authenticity of an individual.

Smart contracts automate agreements within blockchain networks, executed in environments like the Ethereum Virtual Machine (EVM), showcasing the flexibility of blockchain applications [39]. Also, decentralized applications (dApps) can be built upon smart contracts to drive transparency and reduce tamper risks in operations, including authentication processes. Yet, the reliance on centralized components for certain operations in the dApps, as shown in Fig. 1, can introduce single point vulnerabilities [40].

FIGURE 1.

Architecture of a blockchain-based authentication system showing the authentication server with dApp logic and its potential as a single point of failure.

Non-fungible tokens (NFTs) extend blockchain’s application to digital ownership and identity authentication. NFTs (ERC-721), or specifically designed soul-bound tokens (ERC-5484), can represent unique, non-transferable identities, further securing authentication processes [41], [42].

These features make the blockchain versatile, with applications ranging from financial transactions to supply chain management [43]. In the context of authentication, the trust-enabling attributes of the blockchain align with the principles of zero trust, where trust is continuously verified by the operation of the blockchain, thus enhancing the overall security posture.

C. Asymmetric Encryption and Digital Signatures

Digital Signature Algorithms (DSA) and asymmetric encryption are foundational for secure communications between parties. Blockchain platforms like Ethereum operate on ECC and the ECDSA. In Ethereum, the blockchain keys generated and used within its framework are suited for implementing secure communication channels outside the blockchain operations. These keys facilitate encrypted messaging and authenticated transactions, allowing for a cohesive cryptographic approach without integrating disparate systems.

Ethereum’s utilization of the secp256k1 curve in ECC is a notable aspect of its security infrastructure [44]. The secp256k1 curve provides a 256-bit level of cryptographic robustness, making it difficult to compromise the keys generated and ensuring the integrity and security of communications and transactions [45].

D. Zero Knowledge Proofs

ZKPs are cryptographic methods designed to maintain privacy and confidentiality. They enable one party to prove the truth of a statement to another party without revealing any specific information about the statement itself. The core aim of ZKPs is to allow for a verification process where the verifier gains confidence in the truth of a claim without acquiring any additional knowledge, thus keeping sensitive information concealed while still facilitating necessary validations [46], [47].

The zk-SNARKs are a specific type of ZKP. They streamline the interaction between the prover and the verifier. Unlike traditional ZKPs, which may require several interactions or challenges, zk-SNARKs allow the proof to be established non-interactively in a single step [48]. The prover can create a proof and send it to the verifier, who can verify it without further communication. The ‘succinct’ aspect of zk-SNARKs refers to their efficiency; the proofs are small in size and quick to verify. This makes zk-SNARKs particularly useful in blockchain applications where efficiency and scalability are essential. The basic flow involves using a specific computational circuit representing the model of what must be proven. The circuit is used to create a set of keys: a proving key pk for the prover and a verifying key vk for the verifier. The prover generates a “proof” to demonstrate their knowledge of a statement, and the verifier verifies this “proof” without gaining any information about it other than its accuracy. The simplified process is shown in Algorithm 1.

Algorithm 1 ZKP Verification (zk-SNARKs)

1:

Setup Phase:

2:

$\text {Circuit} \gets \text {Define(Computation)}$

3:

$(\text {Proving Key}, \text {Verifying Key}) \leftarrow \text {Setup}( \text {Circuit} )$

4:

Prover receives Proving Key (pk)

5:

Verifier receives Verifying Key (vk)

6:

Verification Phase:

7:

Prover uses pk to $\xrightarrow {\text {generates}}$ Proof

8:

Prover sends Proof to Verifier

9:

Verifier uses vk to$\xrightarrow {\text {checks}}$ Proof

10:

if Proof is valid then

11:

$\text {Outcome} \gets \text {True}$

12:

Knowledge Verified

13:

else

14:

$\text {Outcome} \gets \text {False}$

15:

Knowledge not Verified

16:

end if

E. Software-Based Random Number Generators

Software-based random number generators (RNGs) are algorithms used to produce sequences of numbers that approximate the properties of random numbers. Typically, these are employed in applications requiring unpredictability, such as creating an OTP. A vital component of an RNG is the ‘seed,’ the initial starting point or input value used by the algorithm to generate the random sequence. The seed determines the sequence of numbers generated by the RNG; the same seed will always produce the same sequence. RNGs calculate new numbers based on this seed, often using complex mathematical operations to ensure the randomness of the output.

However, the security of software-based RNGs can be compromised if the seed value is known or predictable, as noted in [49]. If an attacker gains control of the system and can determine the seed, they can replicate the number sequence of the RNG, potentially exposing sensitive data. This vulnerability underscores the importance of using unpredictable and well-protected seed values alongside robust algorithms in RNGs, particularly for security-critical applications. A novel approach to further enhance security involves distributing the random number creation process [50]. Doing so reduces the dependency on a single point (the seed), bolstering the resilience of the RNG against attacks.

F. Identity Registration

The identity registration step in blockchain-based authentication systems must be distinct from the authentication process. This separation is essential to ensure the privacy preservation of user details. The registration of identities is ideally handled by a dedicated entity, often tied to a specific organization, as it may involve adherence to particular business rules or collecting specific user details.

To effectively integrate identity registration with blockchain technology, user identities are recorded on the blockchain by associating them with a unique PuAdd. This can be achieved by employing hashing techniques to obscure user details, ensuring that the privacy of the user is maintained while also considering the uniqueness of each hash when it is mapped to a PuAdd. This approach guarantees that each identity is distinct and securely represented on the blockchain. The detailed steps are shown in the Fig. 2 sequence diagram, which depicts a process for securely registering the information of a user on a blockchain, utilizing asynchronous encryption, signature, and hashing techniques. The step-by-step explanation of the depicted process is as follows:

1. The Registration Server RS provides its Public Key $(PuK_{RS})$ to the User.

2. The User prepares their personal information, encapsulated in a tuple $I=(P,C)$ , where P refers to personal details and C refers to contact information.

3. The User encrypts the personal information tuple I using the Public Key of the $RS~(PuK_{RS})$ to get the encrypted information EI.

4. The User signs the encrypted information EI using their Private Key $(PrK)$ to produce the signed encrypted information SEI.

5. The User submits the encrypted information EI and the signed encrypted information SEI to the RS.

6. The RS verifies the signature on SEI to ensure its validity and extracts the User’s Public Key $(PuK_{u})$ from the signature.

7. The RS decrypts EI using its Private Key $(PrK_{RS})$ to retrieve the original personal information tuple I.

8. The RS verifies the personal information I. (e.g., if it belongs to the organization) **This step is governed by the organization’s rules for handling user information and is not detailed in this research**.

   • If the verification is invalid, the flow goes to step 12.

9. The RS hashes the personal information I using a hash function of 256 bits to get H.

10. The RS computes the PuAdd from the $PuK_{u}$ .

11. The RS stores H on the blockchain, mapping it to the PuAdd.

12. The RS confirms the successful registration to the User.

13. If the verification carried out in step 8 is invalid, the RS sends an “Invalid request” message to the User and ends the flow.

FIGURE 2.

Identity registration process with privacy preservation of user details in the blockchain.

The authentication process operates independently of the registration. It solely focuses on the hashed blockchain-based identities associated with their public addresses. This approach ensures transparency and respects user privacy.

G. Glossary

Table 1 lists the abbreviations commonly used in the paper and their descriptions.

TABLE 1 List of Abbreviations

SECTION IV. Proposed System

The proposed model presented in this paper addresses the necessity of a secure and private authentication mechanism by introducing a robust MFA framework tailored to the needs of zero trust networks (ZTN). This framework is centered on decentralization, enhanced security, privacy preservation, and verifiable trust.

1) Decentralization

The overall design of the framework can be seen in Fig. 3. The basis of the proposed model is a Distributed Authentication Mechanism (DAM). By integrating blockchain technology and adhering to its decentralized architecture, the model aims to eliminate any single point of failure within the MFA system and distribute MFA requests across multiple validator nodes. This approach decentralizes the authentication process and enhances the resilience of the system against adversarial actions and system failures.

FIGURE 3.

System architecture of the proposed privacy-preserving distributed MFA mechanism.

2) Enhanced Security

An integral part of the framework is to augment the security of creating an OTP through a collaborative secret generation mechanism. Every validator node within the blockchain network contributes to generating a partial secret. This collective effort aims to fortify the OTP against potential threats, thereby improving the overall security of the MFA process.

3) Privacy Preservation

The proposed model employs asymmetric encryption techniques to ensure the confidentiality of user information throughout the MFA process. While keeping the authentication process transparent and verifiable, the model ensures that users’ personal and transactional data remain private. More importantly, ZKP is integrated into the MFA framework to enhance its privacy-preserving aspect. This inclusion allows users to affirm the knowledge of a secret (OTP) without exposing the actual data.

4) Verifiable Trust

The model extends the verifiability of ZKP by integrating them into the blockchain. Each ZKP verification is recorded and validated on the blockchain, enhancing the security and trustworthiness of each authentication event. This blockchain-verified ZKP feature leverages the inherent verifiability of blockchain technology, enhancing the overall trust and security within the authentication process.

A simplified flow of the proposed model is as follows:

1. A User request authentication to the DAM.

   • The DAM, with its collection of decentralized nodes, receives the request on one of the authenticators.

2. An Authenticator executes the OTP generation process.

   • It requests and receives partial secrets from the other nodes.

   • It generates its own partial secret.

   • It aggregates the secrets as an OTP.

3. The Authenticator hashes the OTP and stores it in the blockchain.

4. The Authenticator sends the encrypted secret OTP to the User.

5. The User decrypts the secret and creates a ZKP asserting that it knows the OTP.

6. The User interacts with the ZKP verifier smart contract to demonstrate the knowledge of the secret.

7. The ZKP verifier executes an event with a result of the verification.

8. Finally, the DAM decides to authenticate or deny the user’s request based on the verification result. The authentication is granted by means of an authentication token.

All interactions are signed, and the exchanged information is encrypted throughout the entire process. A detailed description of the functionality of the components of the proposed model is presented in the following subsections.

A. Distributed Authentication Mechanism (DAM)

The DAM is designed to spread the authentication process across multiple nodes. It draws inspiration from the inherently distributed nature of the blockchain, specifically, a blockchain utilizing the QBFT consensus mechanism. In a typical blockchain environment, nodes are spread across various geographical locations. The QBFT consensus mechanism ensures that most nodes (validators) in the network agree upon a particular state or transaction before it is added to the blockchain. Even if a few nodes act maliciously or provide incorrect information, the system can still function correctly if the majority consensus is maintained.

Expanding upon the QBFT foundation, this research extends the role of validator nodes beyond merely maintaining the blockchain. In this system, validators also take on the responsibility of executing the logic required for authentication within a zero-trust framework. Each validator node adopts an “Authenticator” role A in the DAM framework. Alongside their inherent responsibilities in the QBFT consensus, these validator nodes also form the core of the authentication mechanism. When a user seeks authentication, these Authenticator nodes (acting as validators) work together to execute the MFA process, adhering to the QBFT mechanism to handle faulty nodes.

The research addresses a common weakness in many blockchain-based authentication systems: the risk of a single point of failure. The traditional setup, as depicted in 1, typically relies on a centralized authentication system to manage crucial authentication tasks. If this system faces issues or gets compromised, it can disrupt all authentication requests. On the other hand, the method presented in this work spreads out the authentication tasks across the blockchain, as seen in Fig. 4. Instead of relying on one central point, the system uses multiple validator nodes for authentication.

FIGURE 4.

Distribution of authentication functionality across nodes in a blockchain.

The DAM receives MFA authentication requests, which a single authenticator A serves amongst the total $A_{N}$ in the system. The authentication process requires a pre-registration step in which user details are hashed and securely stored in the blockchain. The DAM does not manage the registration process. Instead, it is externally handled, for instance, by institutions or organizations wishing to adopt a blockchain-based MFA authentication system as part of their system.

B. MFA Process

The authenticator A plays a pivotal role in managing MFA requests initiated by users. Its key responsibilities are to cross-check user information against records stored within the blockchain, to compute the OTP secret, which is vital for verifying user authentication requests, and to provide an authentication token after the MFA is completed. The MFA mechanism is targeted to blockchain-based authentication systems, so it is assumed that every entity interacting in the process has proper PrK and PuK alongside PuAdd.

1) User Request Validation

In the initial phase of the authentication process, the focus is on validating the MFA request initiated by a user. This phase is critical as it establishes the genuineness of the request, ensuring it originates from a legitimate user. Upon receiving an MFA request from a user, the DAM engages one of its authenticators, A, to handle the request. The mechanics of receiving this request can be expressed as $R=Receive(MFA_{request})$ , where R denotes the reception of the MFA request by the authenticator.

The $MFA_{request}$ is described in (3). The contents are a signature of the 256-bit hash of the identity information of the user $I=(P,C)$ where P denotes personal details and C stands for contact information. The $MFA_{request}$ request also includes the blockchain public address of the user $PuAdd_{u}$ . Finally, the request includes an email address used for the MFA OTP verification. There is no message accompanying the signature in the request; instead, the signature encapsulates the necessary data for validation. $$\begin{align*} MFA_{\text {request}} = \begin{cases} \text {S}\left ({{\text {PrK}_{u},\text {H256}(I)}}\right ) & \text {Signature of hashed}~ I , \\ \text {PuAdd}_{u} & \text {Public Address of the user,} \\ \text {Email} & \text {Email of the user.} \end{cases} \tag {3}\end{align*}$$

The authenticator proceeds by extracting the signature S from the request, and the $PuAdd_{u}$ of the requesting user. Subsequently, it verifies the validity of the request by cross-referencing data on the blockchain. Specifically, it performs the following steps:

1. Retrieve the hash associated with the public address of the user from the map stored on the blockchain: $H(I), PuAdd = {BlockchainMap}({PuAdd_{u}})$ .

2. Use the retrieved hash $H(I)$ as the message to compute the public key $( {PuK_{u}'} )$ of the requester through the signature verification process:${PuK_{u}'} = {V}({S}, H(I))$ .

3. Derive the public address $( {PuAdd_{u}'} )$ from the computed public key:${PuAdd_{u}'} = {GetAdd}({PuK_{u}'})$ .

4. Check if the derived public address matches the public address initially retrieved from the blockchain map:${IsValid} = ({PuAdd_{u}'} { {=} {=}} {PuAdd})$ .

If there is a match, it confirms the validity of the request, marking it as a legitimate initiation of the MFA process by the user. In the proposed authentication process, the hash of the identity information $H(I)$ plays a crucial role in the verification process. The core premise is that a valid signature in the ECDSA framework can only be generated by someone who possesses the corresponding PrK to the PuK (or PuAdd) stored in the blockchain. When a user sends an MFA request, the request is accompanied by a signature created using the PrK of the user. This signature is unique to the user and the message being signed, which includes the hash $H(I)$ .

Upon receiving an MFA request, the DAM extracts the signature and performs a verification process. This process involves computing the $PuK_{u}^{\prime }$ from the signature and the message hash $H(I)$ and comparing the computed $PuK_{u}^{\prime }$ associated $PuAdd_{u}^{\prime }$ with the public address stored in the blockchain. If the two addresses match, the request is deemed valid; otherwise, it is rejected. Even if an adversary obtains the hash $H(I)$ and attempts to forge a signature, they will need the corresponding private key to generate a valid signature that would pass the verification process. Without the private key, any forged signature will yield a different $PuK_{u}^{\prime }$ during the verification process, leading to a mismatch in public addresses and thus failing the verification. In essence, the signature serves as a robust proof of ownership of the private key and, by extension, proof of the authenticity of the MFA request. The whole process is expressed in the Algorithm 2. With the request validated, the process transitions to OTP generation phase.

Algorithm 2 Authentication Process

1:

Participant: User, Authenticator, Blockchain

2:

User initiates MFA request:

3:

$MFA_{\text {request}}: (S(\text {PrK}_{u}, \text {H256}(I)), \text {PuAdd}_{u}, \text {Email})$

4:

Authenticator retrieves hash from Blockchain:

5:

$H(I), PuAdd {=} \text {BlockchainMap}(\text {PuAdd}_{u})$

6:

if Hash Exists then

7:

Blockchain returns $H(I), \text {PuAdd}$ to Authenticator

8:

Authenticator computes public key:

9:

$\text {PuK}_{u}' {=} V(S, H(I))$

10:

Authenticator derives public address:

11:

$\text {PuAdd}_{u}' {=} \text {GetAdd}(\text {PuK}_{u}')$

12:

Authenticator verifies address match:

13:

$\text {IsValid} {=} (\text {PuAdd}_{u}' {=} {=} \text {PuAdd})$

14:

if Addresses Match then

15:

Authenticator proceeds to OTP generation

16:

else

17:

Authenticator indicates authentication

18:

end if

19:

else

20:

Authenticator indicates authentication failed to User

21:

end if

2) OTP Generation

The uniqueness of the OTP generation process in this framework is derived from its decentralized design, which takes advantage of the distributed nature of the blockchain. This approach differs from traditional centralized methods and involves the collaborative effort of all validator nodes within the blockchain for the OTP generation process.

Upon receiving a valid authentication request from a user, the authenticator initiates a parallel request for ‘partial secrets’ to all other authenticators within the network, including itself. Each node in this interconnected network contributes to the OTP generation by computing a segment of the password, termed a ‘partial secret.’ The process of partial secret generation is illustrated as follows:

1. Verification of active OTP:

   • The authenticator queries the OTPMap to check for an active OTP associated with the public address of the user: $activeOTP = OTPMap(PuAdd_{u})$ .

   • It fetches the current block number from the blockchain: $currentBN = FetchBN()$ .

   • It compares the current block number with the timer of the stored OTP to check its validity:

     $IsValid = (currentBN \leq (activeOTP.timer))$ .

   • If the OTP is still valid $( \text {IsValid} = \text {true} )$ , the process halts; if not, the process continues to the next step: $Continue = (IsValid == false)$ .

2. Initiation of partial secret:

   • The authenticator (acting as the aggregator) sends a parallel request to all other authenticators within the network, including itself, for the generation of a partial secret $ROTP = RequestOTP(PuK_{a})$ where $PuK_{a}$ is the public key of the aggregator.

3. Generation of partial secrets:

   • Each authenticator computes a partial secret by executing a random integer function:

     $partialSecret = rand(1, int(1e10))$ .

   • The function rand is utilized to generate a random integer between 1 and $10^{10}$ . This function is called by each authenticator in the network, thus generating a unique partial secret. The range is defined to ensure a sufficiently large pool of possible values.

4. Encryption of partial secrets:

   • The authenticators encrypt the generated partial secret using the aggregator’s public key:

     $ES_{i} = E(PuK_{a}, partialSecret_{i})$ .

5. Response of partial secrets:

   • The authenticators sign the encrypted partial secret using their private key $(PrK_{A_{i}})$ , and respond to the aggregator: $ROTP_{i} \leftarrow S(PrK_{A_{i}}, ES_{i}), ES_{i}$ .

6. Verification of authenticator’s signature:

   • The aggregator verifies the signature of each response to ensure the integrity.

     $IsValid_{i} = \text {Verify}(PuK_{A_{i}}, S(PrK_{A_{i}}, ES_{i}), ES_{i})$ . Where $IsValid_{i}$ is a boolean indicating the validity of the i-th authenticator’s signature, and Verify is the function that checks if the signature $S(PrK_{A_{i}}, ES_{i})$ created with the private key $PrK_{A_{i}}$ correctly corresponds to the message $ES_{i}$ using the public key $PuK_{A_{i}}$ . The aggregator only trust responses from validators in the blockchain.

7. Collection of responses:

   • The aggregator collects the responses from all authenticators as expressed in (4) $$\begin{equation*} \text {SuccessCount} = \sum _{i=1}^{N} IsValid_{i} \tag {4}\end{equation*}$$ where $IsValid_{i}$ is 1 if the response from the i-th authenticator is successful, and 0 otherwise.

8. Verification of majority response:

   • Upon collecting the responses, the aggregator verifies the successful replies according to the QBFT majority of nodes formula from (5). Should the majority of nodes fail to respond with a partial secret, the process terminates, deeming the system insecure for completing the MFA authentication. $$\begin{equation*} \text {IsMajority} = \left ({{ \text {SuccessCount} \geq \frac {2N}{3} + 1 }}\right ) \tag {5}\end{equation*}$$

9. Decryption of partial secrets:

   • The aggregator decrypts the encrypted partial secrets using its private key $PrK_{a}$ to obtain the decrypted partial secrets as per (6): $$\begin{equation*} \text {DS}_{i} = D\left ({{\text {PrK}_{a}, \text {ES}_{i}}}\right ) \quad \text {for}~ i = 1, 2, \ldots , N \tag {6}\end{equation*}$$

10. Aggregation of decrypted partial secrets:

    • The decrypted partial secrets are aggregated to generate the complete OTP:

      $\text {OTP} = \text {Aggregate}(\text {DS}_{1}, \text {DS}_{2}, \ldots , \text {DS}_{N})$ .

11. Hashing of OTP:

    • The complete OTP is then hashed using a 256-bit hash function. The userOTP tuple comprises the hash value $H256(OTP)$ and a timer, calculated as the sum of the current block number and a predefined value consisting in a number of blocks in the future, $blockNumber + B_{n}$ :

      $userOTP = (\text {H256}(OTP), timer)$ .

12. Storage of userOTP:

    • The userOTP tuple is stored in a map, indexed by the requesting public address of the user $(PuAdd_{u})$ . This mapping ensures a secure and accessible storage of the OTP for the upcoming verification stage:

      $OTPMap = PuAdd_{u} \rightarrow userOTP$ .

13. Encryption of OTP:

    • Simultaneously, the aggregator encrypts the OTP using the public key of the user $PuK_{u}$ . The public key was obtained during the user request validation process: $\text {EO} = E(\text {PuK}_{u}, OTP)$ .

14. Transmission of the encrypted OTP:

    • The encrypted OTP is sent to the email of the user, thus completing the OTP generation process and transitioning to the OTP verification phase.

3) OTP Verification

The procedure to finalize the MFA involves ensuring a secure and verified generation and transferring an authentication token $Auth_{t}$ to the user. This process starts with verifying the OTP using a ZKP technique (disclosed in Section IV-C), followed by creating and transferring an authentication token if the ZKP verification is successful. The steps are described as follows:

1. ZKP verification of OTP:

   • A ZKP verification is performed on the OTP sent to the user. This verification process is executed by a smart contract deployed on the blockchain. The user provides proof of knowledge of the OTP as ${ZKP_{Verify}}({OTP_{proof}})$ . The verification is executed as a transaction in the blockchain, which inherently uses the $PuAdd_{u}$ as described in Algorithm 4.

2. Notification to DAM:

   • Post verification, the smart contract sends a notification to the DAM, ${Notify_{DAM}}(status, PuAdd_{u})$ , indicating the verification status and the public address of the prover.

3. Check verification status:

   • The DAM checks the verification status. If the verification is unsuccessful, the process is halted. If it is successful, the process continues to the next step.

4. Authentication token creation:

   • Upon successful verification, the DAM triggers the creation of the authentication token. The token is structured as an NFT with the following format: ${Auth_{t}} = \{UID, exp, meta\}$ , where UID is a unique identifier for the token, exp is the expiry time of the token computed as $blockNumber\ +\ B_{n}$ , and meta contains additional information related to the token structure.

5. Token transfer:

   • The DAM transfers the created $Auth_{t}$ to the public address of the user on the blockchain:

     ${Token_{Transfer}}(\text {Auth}_{t}, \text {PuAdd}_{u})$ .

   • The transfer creates a map on the blockchain associating the public address of the user with the authentication token, establishing the user’s ownership of the token, ${Token_{Map}} = \text {PuAdd}_{u} \rightarrow \text {Auth}_{t}$ .

6. Notification to the user:

   • Transaction confirmation is sent to the DAM, and a notification to the user confirming the successful creation and transfer of the authentication token, thus completing the MFA procedure, ${Notify_{User}}(\text {TransferStatus})$ .

Algorithm 4 ZKP Verification Process

1:

Smart contract receives $OTP_{proof}$ from user with $PuAdd_{u}$ .

2:

Trigger $ZKP_{Verify}(OTP_{proof})$

3:

Fetch public values of hash H from the blockchain by querying OTPMap using $PuAdd_{u}$ .

4:

if Hash H is not found then

5:

End process (Invalid request)

6:

else

7:

Verify the proof using verifying key vk and public values of H.

8:

Send verification result as a blockchain event: True or False.

9:

end if

These steps encapsulate the final phase of the MFA procedure, ending with the creation and transfer of an authentication token to the user; the entire procedure is illustrated in Algorithm 3. Upon receipt of this token, the user is granted authenticated access, thus concluding the MFA process. The design ensures that only a user who has successfully verified the OTP can receive an authentication token.

Algorithm 3 MFA Completion

1:

Participants: User, DAM, Blockchain

2:

User verifies knowledge of OTP:

3:

$ZKP\_{Verify}(OTP_{proof})$

4:

Blockchain notifies DAM of successful verification:

5:

$Notify\_{DAM}(status, PuAdd_{u})$

6:

if status Successful then

7:

DAM creates authentication token:

8:

$Auth_{t} {=} \{UID, exp, met\}$

9:

DAM transfers the token to the user:

10:

$Token\_{Transfer}(Auth_{t}, PuAdd_{u})$

11:

Blockchain confirms transfer to DAM

12:

DAM notifies User of authentication completion:

13:

$Notify\_{User}(TransferStatus)$

14:

else

15:

DAM notifies User of authentication failure:

16:

$Notify\_{User}(Verification\_Failure)$

17:

end if

C. Zero Knowledge Proof

Ensuring the confidentiality and integrity of the OTP during the verification phase is crucial. The core challenge lies in enabling a user to prove the knowledge of the OTP to the DAM without exposing the OTP itself. Since the user has demonstrated the ability to decrypt the OTP, thanks to possessing the corresponding private key of the asymmetric encryption process, the next step is to communicate this knowledge to the DAM securely. In the OTP generation stage, the hash of the OTP was associated with a unique map, OTPMap, linking it to a specific user through their public address, $PuAdd_{u}$ . This association ensures that a particular OTP is designated for a specific user alone. The blockchain must conduct the ZKP verification to uphold this association and prevent misuse. By doing so, the blockchain, through a transaction, validates that the correct user is undertaking the verification, thereby maintaining the integrity and confidentiality of the MFA process. This way, the user can demonstrate the possession and knowledge of the OTP without revealing it, and the DAM can securely confirm the authenticity of the user.

The specific variant of ZKP adopted in this work is zkSNARK. This variant facilitates the user to prove the possession and knowledge of the OTP without disclosing it, while the DAM is enabled to affirm the authenticity of the user securely. Creating a ZKP using zkSNARKs to prove the knowledge of an OTP without revealing it is described as follows:

1. Circuit creation (preliminary step):

   • A superuser (administrator of the system or deployer) creates a circuit that will be used to generate and verify proofs. This circuit is designed to validate the knowledge of a hash preimage, in this case, the preimage of the OTP. The logic of the circuit can expressed as (7), where x is the preimage (OTP), h is the hash of the OTP, and C is the circuit function. The circuit verifies that hashing x results in h. $$\begin{equation*} C(x, h)= \left ({{ \text {H256}(x) - h }}\right ) = 0 \tag {7}\end{equation*}$$

   • The superuser generates a proving key pk and a verification key vk for the circuit. The pk and the circuit are securely transmitted to the user. Both of these keys are public and can be shared by any means. The pk is used to interact with the circuit and create a proof. The vk is used to verify the proof generated. These keys are generated only once, unless the logic of the circuit changes.

2. Witness Computation:

   • The user computes the witness w on the circuit using their OTP and the proving key pk:

     $w = \text {ComputeWitness}({pk}, {OTP})$ .

3. Proof Generation:

   • The user generates a proof $\pi$ using the proving key pk, the witness w, and the circuit C:

     $\pi = \text {GenerateProof}(pk, w, C)$ .

4. Proof Submission:

   • The user submits the proof $\pi$ to the blockchain by interacting with the smart contract designed to verify the proof.

5. Proof Verification:

   • The smart contract on the blockchain verifies the proof $\pi$ using the verification key vk and the hash of the OTP h stored in the OTPMap associated with the user’s public address $PuAdd_{u}$ . This is expressed as, $\text {IsValid} = \text {VerifyProof}(\text {vk}, \pi , h^{\prime })$ . The verification key is embedded in the smart contract.

   • The Verify function checks whether the proof $\pi$ is valid given the verification key vk. If the proof is valid, it returns True, indicating that the user has successfully proven the knowledge of the OTP without revealing it. If the proof is not valid, it returns False, indicating that the proof is incorrect, and the verification fails.

In the scenario of the MFA system discussed in this work, the circuit is used as a secure and privacy-preserving verification of the OTP. The core objective is to allow a user to prove the knowledge of the OTP without disclosing the actual value to anyone, including the verifying party. This is crucial for maintaining the confidentiality and integrity of the authentication process.

The specific circuit C is designed to achieve this goal by verifying the knowledge of a hash preimage x (the OTP) against a known hash value h. The circuit leverages the properties of cryptographic hash functions, which are deterministic yet non-reversible, to ensure that the user can prove the knowledge of the OTP without revealing it. The zkSNARK framework then enables the creation and verification of proof that asserts the truthfulness of this claim in a zero-knowledge manner without revealing any additional information other than the validity of the claim itself.

The uniqueness of proof verification is guaranteed by the blockchain transaction, which ties the verification to the specific public address $PuAdd_{u}$ of the receiver of the OTP. Only the designated user can correctly verify the proof, as the hash is tied to their specific public address, verified by the blockchain transaction. The verification is described in Algorithm 4.

D. MFA in a Zero Trust Environment

The user can utilize $Auth_{t}$ to access a ZTN system as long as the token remains valid. During this period, an MFA process is not required. This verification is managed through the possession of the token, which is associated with the $PuAdd_{u}$ and is consequently linked to the blockchain keys that correspond to that address. The ZTN system must implement a mechanism to verify the existence of authentication tokens continuously. However, the detailed mechanism is beyond the scope of this research, as the work primarily focuses on the MFA process. A simple description is shown in Fig. 5, described as follows.

1. Connection request:

   • The user initiates a connection request to the ZTN. This request is signed using the blockchain keys associated with the identifier of the user $S(PrK_{u}, UserID)$ , which is represented as public address $PuAdd_{u}$ , establishing a proof of ownership for the system.

2. Authentication token verification:

   • Upon receiving the connection request, the ZTN queries the blockchain to verify the existence and validity of an authentication token $Auth_{t}$ associated with the public address of the user $PuAdd_{u}$ :

     $Auth_{t} = Fetch_{t}(PuAdd_{u})$ .

3. Verify validity of the token:

   • The validity of $Auth_{t}$ is checked against the current block height to ensure it has not expired:

     $\text {IsValid} = (currentBN \leq (Auth_{t}.\exp ))$ .

   • If no $Auth_{t}$ exists for the $PuAdd_{u}$ , the process ends.

4. Connection authorization:

   • If the user has a valid $\text {Auth}_{t}$ , the connection to the ZTN is authorized.

5. Denied connection:

   • If the $Auth_{t}$ is expired, the connection request is denied, and the user must execute the MFA process to obtain a new $Auth_{t}$ .

6. Invalid request:

   • In case of a non-existent $Auth_{t}$ , the user must execute the MFA process.

FIGURE 5.

ZTN connection and authentication process with blockchain verification.

SECTION V. Proof of Concept

This section presents the practical implementation of the proposed MFA mechanism. The core components of this mechanism are the ZKP framework, the blockchain, and the DAM.

• The chosen framework for implementing ZKP in this work is ZoKrates [51], a toolbox for zkSNARKs on Ethereum that provides a high-level, easy-to-use domain-specific language (DSL) for specifying generic computations that can be compiled into a set of zkSNARKs.

• Hyperledger Besu [52] has been employed as the open-source Ethereum client to set up the blockchain infrastructure. It facilitates a range of consensus algorithms, and the QBFT PoA consensus mechanism has been utilized for this implementation. The blockchain deployment comprises five nodes acting as validators. These validators are responsible for proposing, validating, and finalizing blocks in the blockchain, ensuring the integrity and consistency of the data recorded. Each validator node has a known identity, and trust is placed in these entities to uphold the network’s operation and security. The block generation time has been set to 2 seconds. The configuration of the blockchain can be seen in Table 2.

• The DAM orchestrates the MFA verification, which encompasses verifying user data on the blockchain, distributed OTP generation, and authentication token generation. It is designed as a network of authenticators working collectively for the MFA process. It is implemented using Python, employing the Flask framework to communicate through RESTFul APIs [53].

TABLE 2 Blockchain Configuration

A. ZKP Using ZoKrates

The core of the zkSNARKs implementation is the creation of a cryptographic circuit that validates the knowledge of a hash preimage for the OTP. The circuit representation in DSL is shown in Fig. 6, which mimics the purpose of 7.

FIGURE 6.

Representation of zkSNARKs circuits in a domain-specific language for ZoKrates.

The import line specifies a package capable of processing 512 bits of input data and hashing it into a 256-bit output. The imported module is aliased as sha256packed to conveniently reference it within the circuit. The logic of the code and its comparison 7 is described as follows:

1. Hashing operation

   • In (7) the function $H256(x)$ denotes the SHA-256 hash operation on the input x.

   • In Fig. 6, the line field[2] h = sha256packed([0, 0, 0, OTP]); performs the SHA-256 hash operation on the concatenated inputs 0,0,0, OTP, which are four fields of 128-bits padded values that are concatenated (this is how ZoKrates operates) akin to the representation of x in the equation. The output is two fields of 128-bits (The 256-bit hash).

2. Hash comparison

   • In (7), the subtraction operation H256(x) - h represents the difference between the computed hash and the expected hash h.

   • In Fig. 6, the lines assert(h[0] == H1); and assert(h[1] == H2); check that each part of the computed hash h matches the corresponding part of the expected hash H.

3. Zero equality check

   • In (7), the expression $(\mathrm {H256}(x)-h)=0$ checks that the difference between the computed hash and the expected hash is zero, indicating a match.

   • In Fig. 6, the assertions ensure the same zero difference through direct equality checks rather than a subtraction operation.

In both the equation and the code, the core objective is to verify that a certain hash pre-image is known without revealing it. This is denoted by the function parameter, marked as a private field, which means these are the private inputs to the circuit that the prover knows but does not reveal. The parameters $H1$ and $H2$ are public inputs to the circuit, and the public 256-bit hash value of the OTP is divided into two fields of 128 bits.

Once the circuit is compiled, ZoKrates generates the pk and vk. The pk and the compiled circuit are embedded in the user’s client software, and the vk is embedded in a smart contract for verifying ZKPs. Although ZoKrates can generate a contract that verifies ZKPs without executing blockchain transactions, the security requirements of the MFA process require the traceability of the origin of the proof. The ZKP verification process is executed as a transaction via the verifyTx function. This function is public, allowing users to trigger it. Its primary purpose is to confirm the identity of the user, attempting to verify proof. Additionally, it checks the expiration of the OTP using a require statement (require(block.number ¡= expiration, “OTP has expired”)) before proceeding with the verification.

The ZKP verification contract utilizes an interface IOTPContract to interact with another smart contract dedicated to OTP mapping. It uses an instance of this interface, otpContract, to interact with the OTP smart contract. The primary function, verifyTx, retrieves the OTP hash and its expiration time from the OTP smart contract using this interface.

The ZKP contract emits an event, VerificationCompleted, to notify the DAM of the outcome of the ZKP verification. The event is triggered with either emit VerificationCompleted (true, msg.sender); or emit VerificationCompleted (false, msg.sender);, depending on the verification result.

B. Smart Contracts

The smart contracts contain the ZKP verification logic, OTP mapping, and authentication token generation. Additionally, a user registration smart contract is included. Although it is not part of the MFA process, it is essential for fulfilling the requirements of identity hash mapping. The basic structure of the four smart contracts is shown in Table 3. In the proposed MFA mechanism for this work, smart contracts play a crucial role in managing the authentication process. These contracts are programmed using the Solidity language [54], a statically typed programming language designed to develop smart contracts that run on the EVM.

TABLE 3 Smart Contracts Overview

The User Registration, OTP Mapping, and Authentication token smart contracts incorporate a security mechanism through a function modifier, isOwner. This modifier enforces a check ensuring that only the authorized entity, which matches the one stored in the contract, can execute certain transactions or invoke specific methods. This mechanism ensures unauthorized entities cannot interfere or tamper with the data and the logic encapsulated in these contracts.

Initially, a specially designated entity known as the ‘superuser’ is tasked with deploying smart contracts onto the Ethereum blockchain. During this deployment phase, the contract owner field is set to the Ethereum account of the superuser by a constructor in the smart contract, which executes initialization tasks during contract deployment. The smart contract deployment is a blockchain transaction that can be executed utilizing the Remix Ethereum IDE [55]. The msg.sender receives the value of the entity executing the transaction. This setup ensures that only the superuser can interact with these contracts, providing a secure setup phase.

However, the ownership does not remain with the superuser. Post-deployment, the superuser transfers the ownership to the respective entities that manage and interact with these contracts. Specifically:

• The ownership of the User Registration contract is transferred to an entity acting as the registration server, which takes over the responsibility of managing user registrations.

• The DAM, represented by collective authenticators, is assigned the ownership of the Authentication token and the OTP Mapping contracts.

This change in ownership is a one-time setup step, after which the respective entities assume control over their designated smart contracts, managing the logic and data of user registrations, OTPs, and authentication tokens as per the designed MFA mechanism. This structured ownership transfer and the isOwner modifier enforce a strong access control policy, ensuring that only authorized entities can interact with the smart contracts, thus enhancing the security and integrity of the entire MFA mechanism.

The Authentication token smart contract overrides the standard ‘transferFrom’ and ‘safeTransferFrom’ functions to prevent the transfer of tokens. This design choice ensures that tokens can only be controlled by authorized entities, thus preserving the integrity of the MFA process. The smart contract builds upon the ‘ERC721’ and ‘ERC721Enumerable’ classes from the OpenZeppelin library, known for providing compliant implementations of ERC-721 NFTs. By overriding the transfer functions, the contract upholds the fundamental security principle of controlled token transfer, which is vital to meet the requirements of the MFA process.

C. DAM Implementation

The DAM leverages Web3 libraries to facilitate interaction with the Ethereum blockchain, facilitating multi-factor authentication by verifying user credentials, managing OTPs, handling authentication tokens, and managing identity and transaction signing. ECC libraries handle cryptographic operations, ensuring data confidentiality and integrity. During the first deployment of the DAM, the authenticators generate and locally store their accounts’ encrypted PrKs. Cryptography relies on ECC libraries for encryption, decryption, and message signing.

The DAM supports multithreading (natively through Flask) for parallel request handling, especially in distributed OTP generation and aggregation. Each authenticator generates a partial OTP using a random integer between 1 and 10 billion, later aggregated into the final OTP.

The implementation handles peer node connections through a URL array, facilitating intercommunication during OTP generation and aggregation, e.g., node_urls[“A1:port”, “A2:port”…]. The authenticators contain a simple SMTP implementation for sending the encrypted OTP back to the users (The SMTP server implementation is not secure; it uses a disposable GMAIL address to achieve the functionality proposed in this work).

A blockchain event listener receives verification results from the ZKP smart contract, triggering the creation and transfer of the authentication token. The DAM adopts a modular design, encapsulating functionalities like cryptographic operations, blockchain interactions, and request handling in separate modules, as shown in Table 4.

TABLE 4 Overview of DAM Functionality (Per Authenticator)

SECTION VI. Security Analysis and Results

A. Experimental Setup

An experimental setup was conducted on a dedicated Linux server boasting an Intel Xeon Gold 6130 CPU and 256 GB of RAM. Hyperledger Besu nodes were configured and run as individual processes, each having distinct domain names and ports ranging from node1 on port 9545 to node5 on port 9549. Parallelly, the DAM was deployed on the same server on different ports, from node1 on port 5001 to node5 on port 5005.

A user/client application to engage in the MFA and ZKP verification processes was setup using Python on a separate machine with an Intel Core i5-7400 and 16GB of RAM connected within the same network as the DAM, as shown in Fig. 7. The user/client embeds Web3 libraries and ZoKrates functionality for creating a ZKP. The domain names for nodes were mapped to the IP address of the Linux server, facilitating a uniform IP scheme across the nodes.

FIGURE 7.

Deployment map of the experimental testbed.

Upon initiating the DAM, Ethereum accounts were successfully created for each authenticator as follows:

• $A_{1}$ : ‘0xd5a68bB8c76c05722Df562166ec0a1326Eb7dB66’

• $A_{2}$ : ‘0x94b74af81845F86ddf14F889F9F0d2543a419943’

• $A_{3}$ : ‘0xa2A28BcD89C5950A5926E6c19f2F43A0109a3ed2’

• $A_{4}$ : ‘0xc656Cf666B7788185d2c4CA5A64aa08369AA57a7’

• $A_{5}$ : ‘0x7CbBeedc618272298c5C6A0863abD9E671BAABf7’

A superuser was designated to handle the smart contracts’ deployment (User Registration, ZKP verification, Authentication token, and OTP mapping). Post-deployment, the ownership of the Authentication token and OTP Generation contracts was transferred to the respective five DAM authenticators’ addresses. The superuser also executes the registration steps as shown in Fig. 2 (acting as the Registration Server), registering a user on the network with the following credentials:

• $PuAdd_{u}$ : ‘0xd6A0530324cAa949A79B4816B8b8BC8CdbFa362c’

• $H256(I)$ : ‘28b8e7bfc7ea2c17fd2333333da8373176ea898d78b122b2feed6fc14f2ab223’

B. Security Analysis

With the initial setup completed, the registered user can now initiate the request for authentication to the DAM. Upon this initiation, a security analysis is conducted under various conditions to measure the effectiveness of the MFA measures against an array of potential threats. The attack scenarios recreated for this analysis comprise network sniffing, man-in-the-middle attacks, and attempts to disrupt the operations of the system. The resulting insights primarily focus on the capability of the system to prevent unauthorized access, uphold data integrity, and evaluate the effectiveness of the deployed encryption methodologies.

The security properties of the system are shown using probabilistic success metrics representing an attacker’s potential to compromise different aspects of the system. The defined metrics are shown in Table 5.

TABLE 5 Probabilities in DAM Security Analysis

The cumulative probability of a successful attack, denoted as $P_{A}$ , is specified in (8) where $P_{i}$ is related to impersonation attacks and $P_{j}$ to the knowledge of the secret used for MFA. These probabilities, associated with potential security breaches, are expected to be notably low due to the robust security measures incorporated within the proposed framework, driving the overall probability of a successful attack to $P_{A}\rightarrow 0$ . In (8), terms represented as sums indicate individual events that could compromise the system if they occur, such as impersonation involving the knowledge of the PrK of the user. Conversely, terms multiplied together imply that specific conditions, like an attacker obtaining the OTP value, will not independently affect the overall reliability of the MFA process. $$\begin{equation*} P_{A} = \left ({{ \sum _{i \in \{ia, iu, p, t\}} P_{i} }}\right ) + \left ({{ \prod _{j \in \{de, g, u\}} P_{j} }}\right ) \tag {8}\end{equation*}$$

The impact of (8) on the overall security of the system is explained through a threat model for the proposed blockchain-based MFA system. This model is crucial for systematically identifying and analyzing potential threats that could compromise the system’s security and privacy. Additionally, it explains the capabilities of potential attackers and the impact of various attack vectors.

The threat model considers the following actors:

• External Attackers$(A_{ext})$ : Individuals or groups outside the organization attempting to gain unauthorized access or disrupt the MFA system.

• Insider Threats$(A_{ins})$ : Individuals within the organization who might inadvertently cause security breaches.

The threat model defines the potential actions of these threat actors against the blockchain-based MFA system. Let S be the set of system states, where each state $s \in S$ represents a unique step in the MFA. Let A be the set of actions that can be performed by an attacker, where $A = A_{ext} \cup A_{ins}$ , representing the union of actions available to external attackers and insider threats.

The potential impact of an attack can be represented by a transition function $T~: ~S \times A \rightarrow S$ , which maps a system state and an attacker action to a new system state. An attack is successful if there exists an action $a \in A$ such that $T(s, a)= s^{\prime }$ leads to a compromised system state $s^{\prime }$ .

1) External Attackers $\textit {(}A_{Ext}\textit {)}$

• Actions$\textit {(}A_{ext}\textit {)}$ : Include phishing, exploitation of public-facing vulnerabilities, and blockchain network attacks.

• Mitigation Strategy: Implement advanced cryptographic techniques to ensure that $T(s, a_{ext}) \cancel {\rightarrow } s^{\prime }$ for any $s \in S$ and $a_{ext} \in A_{ext}$ , where $s^{\prime }$ is a compromised state. This includes using ZKP for authentication without revealing the personal information of users and the contents of exchanged secrets.

2) Insider Threats $\textit {(}A_{Ins}\textit {)}$

• Actions$\textit {(}A_{ins}\textit {)}$ : Inadvertent disclosure of sensitive information and potential collusion with external attackers (The insider can attempt to execute the same actions as the external attackers).

• Mitigation Strategy: Employ access control mechanisms to prevent unauthorized actions by insiders. Define $T(s, a_{ins})$ such that it continuously verifies the credentials $(C)$ to prevent transition to a compromised state: $T(s, a_{ins}) \rightarrow s$ if $C(a_{ins}) = \text {True}$ .

The analysis of state transitions for impersonation, OTP compromise, authentication token exploitation, and DoS attacks is presented as follows:

Impersonation attempt: The blockchain serves as a fundamental countermeasure against impersonation attacks, primarily through the employment of smart contracts during the initial setup phase. The verification process against a blockchain-mapped identity ensures that only authenticated users or authenticators can interact with the system, leveraging the ‘onlyOwner’ modifier in smart contracts. This mechanism effectively safeguards against unauthorized attempts to mimic legitimate users or authenticators. Suppose an impersonator attempts to imitate a user or an authenticator. In that case, the blockchain will reject any requests since the verifications are tied to public addresses derived from the signed interactions, as shown in Fig. 8.

FIGURE 8.

Prevention of impersonation attacks by using the blockchain.

Attack vector$(A_{imp})$ : An impersonation attempt by an adversary ($A_{ext}$ or $A_{ins}$ ) is represented by the action $A_{imp}$ , where the adversary tries to assume the identity of a legitimate user or authenticator within the system.

State$(s)$ to compromised state$(s')$ transition: The blockchain’s integrity checks, tied to public addresses derived from signed interactions, prevent the transition $T(s, A_{imp}) \rightarrow s^{\prime }$ , ensuring the system remains in a secure state $(s)$ .

The only event in which an attacker can successfully impersonate a user or an authenticator is when the PrK of the Ethereum accounts are compromised. However, these private keys are stored locally and encrypted, so the attacker must also crack the encryption of the private keys. $$\begin{equation*} R_{imp} = 1 - \left ({{\frac {1}{N^{L}}}}\right ) \tag {9}\end{equation*}$$

The resilience of the encryption is represented in (9), Where $R_{imp}$ denotes the resistance against impersonation attacks, N is the number of possible characters of a password used for encryption, and L is the password’s length used for private key $(PrK)$ encryption. The design of the system requires that an attacker compromise the private keys $(PrK)$ of Ethereum accounts, which are locally stored and encrypted. The cryptographic strength, represented by $R_{imp}$ , ensures a negligible probability of successful impersonation, further augmented by the non-transmission of sensitive user details to authenticators.

OTP Compromise: Potential risk scenarios include the unintentional sharing of decrypted OTPs or device compromise through malware. The system employs ZKP verifier smart contracts, accessible publicly but requiring a transaction signed with the user’s private key for verification.

Attack vector$(A_{otp})$ : The compromise or unauthorized acquisition of the OTP by an adversary is denoted by $A_{otp}$ .

Verification and resistance mechanism: The verification process mandates a matching public address in the OTP map on the blockchain, ensuring that only the initiating user can validate the OTP’s knowledge. This mechanism effectively nullifies $A_{otp}$ by requiring proof that third parties cannot furnish, as shown in Fig. 9.

FIGURE 9.

Prevention of third-party use of the OTP for ZKP by employing the blockchain.

Authentication token exploitation: The authentication token is modeled as a non-transferable NFT, with an expiration determined by the blockchain’s block count, ensuring its validity and singular ownership.

Attack vector$(A_{token})$ : The unauthorized use or theft of the authentication token is represented by $A_{token}$ .

Security principle and token integrity: The inherent design of the NFT and its implementation ensures uniqueness and ownership, rendering $A_{token}$ infeasible without compromising the user’s private keys.

DoS Attack Resilience: The system’s resilience to DoS attacks is directly proportional to the network’s node distribution, enhancing its mitigation capability against such attacks.

Consensus Model$(QBFT)$ : The QBFT approach highlights the system’s fault tolerance, as detailed in equations (1) and (2). This consensus model resists faults because it can continue to operate correctly even if some nodes fail or act dishonestly. The system can maintain its integrity and continue functioning by adhering to the QBFT conditions, even in the face of network floods characteristic of DoS attacks.

C. Security Comparison

Table 6 compares the system’s security features proposed in this work with three related works considering using ZKP. The comparison is structured to provide a clear understanding of how each system measures resilience against various cyber threats. The features examined include resilience to DoS attacks, OTP guessing, OTP stealing, OTP misuse by third parties, third-party OTP knowledge proving, and authentication token resilience.

TABLE 6 Security Comparison With Research From Similar Studies

The study in [29] keeps user privacy intact by not storing personal details on the blockchain but using public addresses for identification purposes. However, handling passwords that function similarly to this work’s OTP presents a critical weakness. In their setup, the smart contract processes the password into a hash, which, unfortunately, makes it susceptible to frontrunning attacks [57]. Frontrunning is an issue that arises when transactions are lined up and waiting for confirmation. In this period, an attacker with access to the blockchain node that receives the transactions can see the inputs of all the smart contract functions. This problem worsens if the blockchain has a long block period, like the 15-second duration in public Ethereum blockchains. In such cases, an attacker could steal the password and send a similar transaction with a higher gas price to confirm it faster than the waiting transactions.

Moreover, the implementation of ZKP in Ahmad et al.’s work leans on an external server/database that falls outside the trusted setup in the blockchain. The server can become the target for DoS attacks, reducing the reliability of the ZKP process. The dependency on external systems for critical functions like ZKP verification may introduce vulnerabilities and potential points of failure, detracting from the overall security and reliability of the system.

The works in [30], [56] demonstrate more robust MFA process mechanisms. Nevertheless, some notable dependencies and potential single points of failure in these systems could affect their resilience and security stance. In the case of [56], the authentication process significantly depends on the availability of the platform server and certificate authorities situated outside of the blockchain’s distributed framework. This dependency could potentially introduce risks associated with server downtimes or compromises and the trustworthiness and security of external certificate authorities.

Similarly, the system depicted in [30] has a notable dependency where a single server manages the intra-domain authentication. This arrangement could create a single point of failure. In scenarios where the server faces downtimes or is compromised, the entire intra-domain authentication process could be disrupted, consequently affecting the security and functionality of the system.

D. Performance Evaluation

The performance evaluation of the proposed MFA system is carried out by measuring the time taken to complete the operations in the authentication flow. The testing process is divided into two phases to provide a clear analysis of the system’s performance during the operation of the MFA process. The performance evaluation excludes users’ time to access their email, focusing solely on the operations within the MFA flow. 1000 MFA requests were recorded to generate the results.

1) Phase 1. User Request for MFA

In the first phase, the focus is on measuring the time interval from when a user initiates a request for MFA to the DAM to the point where the OTP is generated and dispatched via email. This phase encapsulates the system’s performance metrics in processing the MFA request and generating the OTP, which is crucial for a prompt user authentication experience. The results of the tests for each iteration are shown in Fig. 10.

FIGURE 10.

Execution times during phase 1 over 1000 iterations.

2) Phase 2. ZKP of the OTP

The second phase starts once the user receives the encrypted OTP via email. It encapsulates when a user starts proving the knowledge of the OTP using ZKP to the point where an Authentication token is generated and mapped to the address of the user. The results of the tests for each iteration are shown in Fig. 11.

FIGURE 11.

Execution times during phase 2 over 1000 iterations.

3) Comparative Results

The accumulated values of the execution times are shown in Fig. 12, where the mean and standard deviation for both phases are presented. It is clear from the data that phase 2 takes longer to complete compared to phase 1. Additionally, the standard deviation values for phase 2 show a higher variation in execution times during this phase.

FIGURE 12.

Accumulated execution times per phase: Mean and standard deviation.

The longer and more variable execution times in phase 2 can be attributed to the two blockchain transactions carried out in sequence during this phase - one for ZKP verification and another for Authentication token Creation. Given the configured block period of 2 seconds on the blockchain, each transaction can take up to 2 seconds to be completed. The time taken for these transactions may vary slightly depending on the exact timing within the block period. Since these operations are carried out one after the other, their times add together, leading to a greater variation in total execution time for phase 2.

On the other hand, phase 1 involves only a single blockchain transaction, which does not have a subsequent dependent step. This transaction is executed without waiting for confirmation as the subsequent steps (user manually opening their email to retrieve the encrypted OTP) occur outside this flow. Therefore, phase 1 exhibits a shorter and more consistent execution time as the blockchain transaction execution times do not affect the flow, reflected in the lower standard deviation value.

The overall time taken to complete the MFA process in this study is obtained by adding the mean values of execution times from both phases, resulting in an approximate total of 3.2 seconds. A comparative table is presented in Table 7 to illustrate the performance of our proposed work. This table presents the time it takes to complete an MFA process considering blockchain-based approaches. The comparison includes the works presented in [23], [27], [30], as discussed in Section II.

TABLE 7 Comparison of MFA Completion Times

The time taken to complete the authentication process in [23] is 15 seconds. The authors attribute this to implementing MFA using a PoW consensus approach for the blockchain used in their proof of concept. In [27], the performance results for a private blockchain show a total of 10.98 seconds for the execution time of all the steps required for the MFA approach. Lastly, [30] reports that the overall performance of operations, including cross-domain authentication and mutual verification, adds up to 4.02 seconds. This performance analysis shows that our study reduces the time required for a privacy-focused MFA approach.

The results presented in Table 7 demonstrate the efficiency of blockchain-based MFA in achieving acceptable processing times, suggesting its promising application in practical scenarios. It is important to note that the time disclosed in this work could increase when considering the manual steps taken by the users to check their email and input the decrypted OTP. Nonetheless, according to [58], the average time recorded for successful real-world MFA attempts is about 19.75 seconds, with authentication times extending to 75 seconds and going as low as 6 seconds. This range highlights the efficiency of the proposed research in achieving acceptable MFA processing times. The comparison is presented in Fig. 13.

FIGURE 13.

Comparative analysis of the MFA process completion time.

Adding to the analysis of execution times are transaction costs, which correlate with the amount of gas utilized for each transaction within the MFA process. Table 8 details three critical transactions: the OTP mapping, the ZKP verification, and the Authentication token mint, which encompasses creation and transfer. It is clear from the table that the transaction associated with the NFT incurs the highest cost, primarily due to the combined actions of creation and transfer within a single transaction. Furthermore, the metadata suggests that the gas amount could vary. For the ZKP transaction, the gas cost is lower since it only triggers an event with the verification result; the actual verification operation is not written to the blockchain. The OTP mapping transaction’s gas reflects the storage of the OTP hash and the public address of the user, balancing cost with the necessity of securely associating OTPs with user identities.

TABLE 8 Gas Costs for Operations

SECTION VII. Conclusion

The paper outlines an MFA system designed with privacy at its core, utilizing the decentralized structure of blockchain to forge a robust network of authenticators. This setup aligns with zero trust security principles, adopting a ‘never trust, always verify’ philosophy. The MFA system uses blockchain technology to establish a verifiable identity through the DAM. This system employs authenticators coordinating to generate and validate user OTPs, providing a secure authentication method. The system integrates ZKPs to further strengthen the identity verification process. Moreover, the mechanism’s approach to verifying the origin of the proof via the blockchain adds a layer of trustless verification.

Furthermore, the security analysis presented a comparative examination of this system against other research works in the domain, effectively highlighting the advantages and enhancements the current research contributes to the field. Performance tests evaluated the efficiency of the system, focusing on the time to complete the authentication process. While the involvement of the blockchain brought some delays due to its inherent transaction confirmation times, the findings were promising. The measured time for completing the MFA process was found to be competitive compared to standard MFA completion times. This indicates a potential for practical applications, suggesting that the proposed system can provide a secure, privacy-preserving MFA solution without sacrificing efficiency. Although our proof of concept implementation does not incur gas fees, it is crucial to consider them for public Ethereum blockchains, where executing transactions requires Ether. This cost consideration is essential for real-world applications of the system.

Still, there are opportunities for further research to enhance and expand upon the work presented in this work to achieve a comprehensive zero-trust architecture. This may include integrating open-source projects such as OpenZiti [59] to function as the zero trust network, utilizing the MFA system proposed in this work to establish a foundational trust between identities. Preliminary work on this integration has been outlined in [60], [61], [62]. Nonetheless, the MFA system could benefit any platform. The Authentication token is designed to serve as a robust verification method, where the metadata format can be adjusted to fit the business logic of a zero trust platform. Moreover, the distributed nature of the system comes with certain challenges, especially considering that trust constantly changes. A blockchain or authenticator node today might not be trusted in the future. Therefore, an automatic mechanism that can evaluate the level of trust and maintain a record of it is necessary. Future work could include research on an intelligent reputation system capable of assessing the degree of trust and effectively permitting or denying the operation of blockchain/authentication nodes within the DAM.