Distributed and Federated Authentication Schemes Based on Updatable Smart Contracts

Abstract

Federated authentication, such as Google ID, enables users to conveniently access multiple websites using a single login credential. Despite this convenience, securing federated authentication services requires addressing a single point of failure, which can result from using a centralized authentication server. In addition, because the same login credentials are used, anonymity and protection against user impersonation attacks must be ensured. Recently, researchers introduced distributed authentication schemes based on blockchains and smart contracts (SCs) for systems that require high availability and reliability. Data on a blockchain are immutable, and deployed SCs cannot be changed or tampered with. Nonetheless, updates may be necessary to fix programming bugs or modify business logic. Recently, methods for updating SCs to address these issues have been investigated. Therefore, this study proposes a distributed and federated authentication scheme that uses SCs to overcome a single point of failure. Additionally, an updatable SC is designed to fix programming bugs, add to the function of an SC, or modify business logic. ProVerif, which is a widely known cryptographic protocol verification tool, confirms that the proposed scheme can provide protection against various security threats, such as single point of failure, user impersonation attacks, and user anonymity, which is vital in federated authentication services. In addition, the proposed scheme exhibits a performance improvement of 71% compared with other related schemes.

1. Introduction

The rapid development of electronic transactions has significantly improved user privacy and transaction safety. To secure electronic transactions, a user must remember a long password or supply a digital certificate or a one-time password. Most internet sites employ a user authentication scheme based on an isolated identity architecture (isolated authentication scheme), in which a service provider (SP) (providing services) and an identity provider (IdP) (managing login credentials) are combined into a single server [1]. For example, in an isolated authentication scheme based on a password, a user requests a login from an SP by submitting the user’s identity (ID) and password (PW), which are pre-registered with an SP serving as an IdP. Upon receiving the user ID and PW, the SP verifies whether they are in the password table and responds to the user for the authentication result, as shown in Figure 1. Isolated authentication is one of the simplest authentication schemes and is widely used in numerous internet services.

However, this scheme is inconvenient because it requires users to recall and manage their login credentials (for example, user ID, PW, and certificate) for each website. In addition, security threats may occur when managing login credentials for multiple websites [2].

In contrast, a user authentication scheme based on a federated identity architecture (federated authentication scheme), such as Google ID, can authenticate users on multiple websites using a single login credential that is pre-registered at an IdP, such as Google. In this scheme, an SP and IdP can be separated and login credentials can be stored at an IdP rather than with an SP. Furthermore, an SP and an IdP can be classified under the same group [1,3,4].

If a user requests a login from an SP, then the SP redirects the user to an IdP website with which the user has registered. The user enters their login credentials on the IdP website. Upon receipt of the user’s login credentials, the IdP verifies whether the login credentials are in the login table and then responds to the SP with the authentication result, as illustrated in Figure 2.

A federated authentication scheme improves user convenience because it does not require managing login credentials for each website. However, to maintain the security of a federated authentication scheme, the following security principles are required [5,6]:

1.

Avoiding a single point-of-failure: even if the IdP server fails, the SP using the corresponding IdP should be available.

2.

Ensure anonymity: because the same login credentials are used on multiple websites, anonymity must be guaranteed.

3.

Protection against impersonation attacks: login credentials must be protected in federated systems, similar to all other access-protected systems. This is particularly important in federated authentication because if the login credentials are exposed, then user impersonation attacks can occur on multiple websites.

Research [7,8,9,10,11,12] has focused on the high availability and reliability of such systems. In 2022, Xue et al. [13] proposed a distributed authentication scheme that could resist a single point-of-failure using smart contracts (SCs) and investigated the roaming services. In this study, to avoid a single point-of-failure in federated authentication, Xue et al.’s scheme was applied to the federated authentication concept. The vulnerabilities of the scheme of Xue et al. [13] were analyzed and an improved scheme addressing these vulnerabilities was proposed. Moreover, the SCs proposed by Xue et al. [13] cannot maintain previously registered data if they are updated for programming bug fixes or authentication functions that update SCs. Therefore, an updatable SC was designed to address these issues and maintain registered data after updating the SCs. Finally, security and performance analyses were conducted on the proposed scheme, and its safety and performance were compared with those of other state-of-the-art schemes.

1.1. Our Contribution

This study proposed a distributed and federated authentication scheme based on updatable smart contracts by improving Xue et al.’s [13] scheme. The contributions of this study are summarized as follows.

• A scheme was proposed in which each node has a copy of the chain owing to the property of the blockchain to resist a single point of failure.
• The scheme of Xue et al. [13], which allows impersonation attacks and does not guarantee anonymity, was improved. To counter impersonation attacks, verification logic was added to determine whether the owner of the public key is legitimate during the authentication process. In addition to ensuring user anonymity, the proposed scheme does not directly transmit user ID during authentication.
• An updatable SC was designed to support the programming of bug fixes or authentication functions to update an SC and maintain registered data after updating the smart contract.

1.2. Paper Structure

The remainder of this paper is organized as follows. Section 2 presents the related studies. Section 3 provides a preliminary overview of the basic elements used in this study. Section 4 provides a review of Xue et al.’s scheme and Section 5 presents an analysis of the security vulnerabilities of Xue et al.’s scheme. Section 6 presents the system model, assumptions, and security requirements, and Section 7 presents the proposed scheme. Section 8 and Section 9 present security and performance analyses, respectively. Section 10 provides a discussion and limitations, and Section 11 concludes the study.

2. Related Studies

Blockchain-based decentralized authentication schemes have been proposed to satisfy the high availability and reliability requirements of various systems.

Blockchain is a crucial emerging technology in e-health systems for the management of sensitive medical data. The application of blockchain technology provides stable real-time services and enables the distributed storage of medical data. Xiang et al. [7] proposed a decentralized authentication and access control protocol for blockchain-based e-health systems; this protocol uses BAN logic to validate the reliability of the system security protection. Cheng et al. [8] proposed a medical data sharing scheme based on blockchain that realizes medical treatment data sharing and satisfies various security requirements during the authentication phase. Cheng et al. [8] claimed that their scheme provides mutual authentication, anonymity, untraceability, session key security, and perfect forward secrecy. However, Xiang et al. [7] reported that their scheme does not provide mutual authentication without RA. Zhang et al. [9] proposed security and privacy requirements for healthcare blockchains.

For mobile vehicular networks, researchers [10,11,12] have proposed several technologies combined with blockchain technology to ensure secure and real-time communication. Recently, Xue et al. [13] proposed a decentralized fraudproof roaming authentication framework based on the blockchain using SCs. In contrast, the present study focused on using SCs to overcome the single point-of-failure of a centralized system. Notably, various security threats are encountered when applying Xue et al.’s [13] scheme to federated authentication schemes. Although Xue et al.’s [13] scheme addresses the important single point-of-failure in federated authentication, it presents vulnerabilities to anonymity and user impersonation attacks.

Data on a blockchain are immutable, and deployed SCs cannot be changed or tampered with. However, in practice, updates are performed to fix programming bugs, add to the function of an SC, or modify the business logic. Recently, studies have been conducted to identify methods for updating SCs to address the abovementioned functions [14,15,16,17,18]. Zheng et al. [14] introduced various smart contract development platforms in 2020. Representatively, they mentioned Ethereum, Hyperledger fabric, Corda, Stellar, Rootstock, and EOS and compared these platforms based on the execution environment, supported language, data model, consensus algorithms, permissions, and applications of SCs. In 2022, a contract upgrade was implemented using a proxy, delegator, and dispatcher patterns [15]. Additionally, design patterns for smart contracts in Ethereum have been studied [16].

In addition, the applications of SCs have been studied [17]. Shao et al. [17] developed an LSC, which is an anomaly detection mechanism, using SCs. The LSC was developed using Solidity to enable log anomaly detection for log systems running on Ethereum [17]. Górski et al. [18] introduced an SC design and implementation patterns using Java; implemented patterns increased source code reusability and foster testing. This method could reduce the time taken for SC validation [18]. EL PASSO [19] was proposed based on a zero-knowledge algorithm for prohibiting both IdP and RP to determine a user trace. However, this method relies on a single ID provider and can forge IDs if a malicious provider exists.

In this study, a distributed and federated authentication scheme was proposed by improving the scheme of Xue et al. [13] by overcoming anonymity and user-impersonation attacks. Additionally, an updatable SC was designed to support the programming of bug fixes and the authentication function for updating an SC, and to maintain the user revocation status after updating the SC.

3. Preliminaries

This section reviews the background information on updatable SCs and elliptic curve digital signature algorithms.

3.1. Updatable Smart Contracts

Szabo first proposed SCs in 1994 before the introduction of blockchain [20]. However, with the advent of the Ethereum blockchain, alongside the development and application of SCs accelerated [21]. SCs based on blockchain are self-executed programs executed on a decentralized blockchain network. They enable contractual terms of an agreement to be enforced automatically without the intervention of a central authority [14].

The building and execution processes for general SCs are illustrated in Figure 3. The user sends a bytecode that compiles SCs to the blockchain and saves the address of the SC. A person wishing to create an SC can do so using the address of the SC.

These processes are performed in an immutable, transparent, and completely secure manner because an SC is deployed in the blockchain network. Therefore, deployed SCs cannot be changed or tampered with.

However, updates may be performed by fixing programming bugs, adding the function of an SC, or changing business logic. If a new SC is created, deployed, and used over the old one, the previously stored data may be unusable. In addition, distributing the address of the new SC to the user is a convenient approach.

For example, if the saved data and business logic are configured as an SC, as shown in Figure 4, the saved data cannot be maintained when the SC is updated.

To address this, as shown in Figure 5, if SC1 stores data and SC2 contains business logic, and SC1 calls SC2, then the operation result of SC2 is not reflected in SC1.

The updatable smart contract comprises SCs such as SC1 and SC2, as shown in Figure 6, wherein SC1 stores data and SC2 contains business logic. If SC1 calls SC2 (a delegate call), the operational result of SC2 is reflected in SC1.

When an SC update is required for a program change, we change the program and deploy a new SC2. After that, in SC1, we can call a function to set the new address of SC2. Finally, the saved data are maintained even if the new SC2 is updated. The details are shown in Figure 7.

3.2. Elliptic Curve Digital Signature Algorithm (ECDSA)

ECDSA is a standardized digital signature algorithm [22,23] that uses elliptic curve cryptography (ECC). This algorithm comprises three processes [24,25]:

• Key Generation: ECC comprises two types of keys: public and private. Let E be an elliptic curve over a finite field, $F_q$, of characteristic p and base point $G\in E\left(F_q\right)$.
  • Select a random integer d in the interval $[1,n-1]$, where n is a sufficiently large prime.
  • Compute $Q=dG$.
  Therefore, d is the private key and Q is the public key.
• Signature Generation: the signer performs the following steps to generate a digital signature.
  • Select a random number k in the interval $[1,n-1]$.
  • Compute $(x,y)=kG$ and $r=x$ $modn$. If $r=0$, return to step 1.
  • Compute $e=h\left(M\right)$ and $s=k^{-1}(e+rd)modn$, where M represents the data to be signed. If $s=0$, return to step 1.
  Thus, pair $(r,s)$ is a signature for message M.
• Signature Verification: the verifier performs the following steps to verify the digital signature.
  • Verify that r and s are integers in the interval $[1,n-1]$. Otherwise, the signature is considered invalid.
  • Compute $e=h\left(M\right)$, $u_1=e{s}^{-1}modn$, and $u_2=r{s}^{-1}modn$.
  • Compute $(x^{\prime },y^{\prime })=u_{1}G+u_{2}Q$ and $v=x^{\prime }modn$.
  • Verify that $v=r$.
  Thus, if $v=r$, then the signature is valid; otherwise, it is invalid.

4. Review of Xue et al.’s Scheme

This section describes Xue et al.’s distributed authentication scheme [13]. In this study, blockchain-based SCs were used for distributed authentication. The system comprises multiple domains, each of which contain access points (APs) and a network control center (NCC). For example, a home network registering a user comprises home APs and a home NCC (HNCC), whereas a foreign network visited by a user comprises foreign APs (FAPs) and a foreign NCC. Each AP and NCC is connected to a blockchain. An NCC creates and maintains SCs for authentication and deploys them to a blockchain. Additionally, it issues and manages login credentials for users/APs. In addition, APs authenticate users through an SC issued by the NCC. Before authentication, the user must register with the HNCC and issue login credentials. If the user wishes to access a foreign network, the user requests authentication from the FAP. Upon receiving the user authentication request, the FAP authenticates the user through the SCs and provides network access services. The system model of Xue et al.’s scheme is shown in Figure 8.

Xue et al.’s scheme comprises three types of smart contracts: the main contract (MC), the authentication contract (AC), and the revocation contract (RC), as shown in Figure 9. The MC has the address of its own AC and a table that maps the other NCCs to their MC addresses. The AC has an actual authentication function and the address of its own RC, where the RC manages the user’s revocation status.

This scheme comprises four phases: user and AP registration, user authentication, dynamic user enrollment and revocation, and the establishment of a roaming partnership. The billing phase in this study was excluded because it is not directly related to user authentication.

4.1. Registration Phase

In the registration step, the user and APs register with an NCC. Before a user accesses a foreign network, a user must register with an HNCC. Before the registration phase, the NCC generates its own ECDSA key pair, i.e., $S{K}_{NCC}$ and $P{K}_{NCC}$, and deploys smart contracts. The details of the user registration phase are as follows:

• The user sends their identity, $I{D}_U$, to the HNCC through a secure channel.
• Upon receipt of the user’s identity, $I{D}_U$, the HNCC generates an ECDSA private key, $S{K}_U$, an ECDSA public key, $P{K}_U$, and a login credential, $C{R}_U=EC.Sign(S{K}_{NCC}$, $I{D}_U\left|\right|P{K}_U)$, for the user. Subsequently, the HNCC sends $I{D}_U$, $I{D}_{NCC}$, $S{K}_U$, $P{K}_U$, $C{R}_U$, and $MADDR$ to the user through a secure channel. $I{D}_{NCC}$ is the HNCC identity and $MADDR$ is the MC address of the HNCC.

The APs must be registered with their HNCC similarly to the user registration. The details of the user and AP registration phases are presented in Figure 10.

4.2. User Authentication Phase

In this authentication step, a user requests access to a foreign network by submitting a request message, $M_U$, to a FAP. Upon receipt of the user’s request message, $M_U$, the FAP verifies the user’s request message. If the request message is valid, then the FAP sends the response message, $M_{AP}$, to the user. The details of the user authentication phase are as follows:

• The user selects a random number $r_U$ and generates timestamps $t{s}_U$, $R_U=r_U$·G, $T_U=h(R_U\left|\right|t{s}_U)$, and $V_U=EC.sign(S{K}_U,T_U)$. Finally, the user generates a request message as $M_U=$$I{D}_U\left|\right|$$P{K}_U\left|\right|$$C{R}_U\left|\right|$$R_U\left|\right|$$I{D}_{NCC}\left|\right|$$V_U\left|\right|$$t{s}_U$ and sends $M_U$ to the FAP.
• Upon receiving the user’s request message, $M_U$, the FAP verifies whether $t{s}_U$ is within an allowable range. If $t{s}_U$ is valid, then the AP calculates $T_U^{\prime }=h(R_U\left|\right|t{s}_U)$ and verifies whether $T_U$ is equal to $T_U^{\prime }$. If $t{s}_U$ or $T_U$ is invalid, the FAP stops the authentication phase. If the FAP does not generate the main contract’s input as $T{X}_{in}=$$I{D}_{NCC}\left|\right|$$T_U^{\prime }\left|\right|$$I{D}_U\left|\right|$$P{K}_U\left|\right|$$C{R}_U\left|\right|$$V_U$, it invokes the MC and sends $T{X}_{in}$ for user authentication.
• If $I{D}_{NCC}$ points to its own identity, the MC calls its AC to verify whether $C{R}_U$ and $V_U$ are valid. The AC verifies $C{R}_U$ as $EC.Verify(P{K}_{NCC},$$C{R}_U)$ and $V_U$ as $EC.Verify(P{K}_U,$$V_U)$, and performs verification through the RC to confirm whether the user is revoked. If $C{R}_U$, $V_U$, or the response of the RC is invalid, the AC stops this authentication phase and sends a failure response. Otherwise, the AC sends a true response to the FAP. If $I{D}_{NCC}$ points to another NCC, then the MC searches for $I{D}_{NCC}$ in the address mapping table. If $I{D}_{NCC}$ exists in the mapping table, then the MC calls the corresponding MC to verify $T{X}_{in}$ and respond to the resulting receipt by the corresponding MC to the FAP.
• Upon receiving the true response of the MC, the FAP selects a random number $r_{AP}$ and generates $t{s}_{AP}$, $R_{AP}=r_{AP}$·G, $T_{AP}=h(R_{AP}\left|\right|t{s}_{AP})$, and $V_{AP}=EC.sign(S{K}_{AP},T_{AP})$, where $S{K}_{AP}$ is the ECDSA private key of the AP. Finally, the FAP generates a response message as $M_{AP}=$$I{D}_{AP}\left|\right|$$P{K}_{AP}\left|\right|$$C{R}_{AP}\left|\right|$$R_{AP}\left|\right|$$I{D}_{NCC}\left|\right|$$V_{AP}\left|\right|$$t{s}_{AP}$ and sends it to the user. Subsequently, the FAP computes the session key $SK=r_{AP}$·$R_U$.
• Upon receiving the FAP response message, $M_{AP}$, the user process is identical to that of the FAP. Details regarding the user authentication phase are presented in Figure 11.

4.3. Dynamic User Enrollment and Revocation

In Xue et al.’s scheme, if a user wishes to enroll in the system, then the user must register with the HNCC. The user can revocate joining this system because of issues such as key loss and illegal usage. If the user requests the HNCC to revocate, then the HNCC updates the user’s identity, $I{D}_U$, in the RC variable.

4.4. Establishment of Roaming Partnership

Different network operators can enroll in or cancel roaming partnerships. If an NCC wishes to enroll or cancel different network operators, it must update or erase the corresponding address mapping table in its MC.

5. Analysis of Xue et al.’s Scheme

This section analyzes the security vulnerabilities of Xue et al.’s scheme, which allows impersonation attacks (i.e., attacks that do not guarantee anonymity). In addition, the disadvantages of smart contracts are also discussed.

5.1. User Impersonation Attacks

Assume that the attacker can register with the same HNCC as the user and steal the user’s request message, $M_U$, during the user authentication phase. The attacker possesses their own data, $I{D}_A,C{U}_A,P{K}_A$, $S{K}_A$, and stolen user data, $M_U=$$I{D}_U\left|\right|$$P{K}_U\left|\right|$$C{R}_U\left|\right|$$R_U\left|\right|$$I{D}_{NCC}\left|\right|$$V_U\left|\right|$$t{s}_U$. Details regarding user impersonation attacks are described as follows:

• An attacker generates a request message as $M_A=$$I{D}_U\left|\right|$$P{K}_A\left|\right|$$C{R}_A\left|\right|$$R_A\left|\right|$$I{D}_{NCC}\left|\right|$$V_A\left|\right|$$t{s}_A$ and sends it to the FAP pretending to be the user.
• Upon receiving the attacker’s request message, $M_A$, the FAP verifies $t{s}_A$ and $T_A$ and generates the main contract input $T{X}_{i}n$. Subsequently, the FAP sends $T{X}_{i}n$ to the MC, which calls an AC for user authentication.
• The AC verifies $C{R}_A$ as $EC.Verify(P{K}_{NCC},$$C{R}_A)$ and $V_A$ as $EC.Verify(P{K}_A,$$V_A)$. The verification results for $C{R}_A$ and $V_A$ are valid because the AC does not verify whether $P{K}_A$ corresponds to the user.

Consequently, an attacker can impersonate the user. In addition, the attacker who receives the response result can obtain the session key between the FAPs by pretending to be the user.

5.2. Anonymity

Xue et al.’s scheme does not guarantee user anonymity because every transaction includes the user’s identity, $I{D}_U$.

5.3. Disadvantages of Smart Contracts

Xue et al.’s [13] scheme does not define how to maintain registered data when updating the AC for error correction or the authentication function. Consequently, if the AC is updated in the scheme proposed by Xue et al., all users must be re-registered.

6. System Model and Security Requirements

This section introduces the system model and security requirements. In particular, a system model for federated authentication schemes is introduced, along with the security requirements that the scheme satisfies.

6.1. System Model

The system model of the federated authentication scheme comprises IdPs, SPs, and users. The system model of the proposed scheme is shown in Figure 12.

• SCs are of two types, namely, the MC and the AC. The MC and AC correspond to proxy contracts and logic contracts, respectively, in [26]. The MC possesses registered data, i.e., identity, certificate, and revocation status; however, it does not possess authentication logic, whereas an AC possesses only authentication functions. IdPs create, manage, and deploy SCs. Additionally, an SP can serve as an IdP by creating, managing, and deploying SCs. Each user, SP, and IdP interfaces with the MC, and the MC authenticates through the AC. To support AC updating, the IdP must implement the SC such that the MC calls the AC using a delegate call. The design of the SCs in the proposed scheme is illustrated in Figure 13.
• Each user and SP can register with an IdP. If the user or SP requests registration, the IdP registers and stores the registration data in their MC. Subsequently, the IdP issues the login credentials and the address of the MC to the requester.
• Users can log into the SP website using their login credentials. If the user requests a login, the SP requests authentication from the IdP’s MC. The MC authenticates the user through its own AC and then responds to the SP with the result; the SP responds to the user. Subsequently, the user requests authentication from the IdP’s MC for mutual authentication. After authentication is completed through the AC in the aforementioned manner, the user and SP share a session key and communicate securely using the session key.
• Each user and the SP can revocate their registration with the IdP. If the user or SP requests revocation, the IdP requests revocation to its own MC. Subsequently, the MC revocates the registration after completing authentication through its own AC.

6.2. Security Requirements

The proposed scheme should satisfy the following security requirements [5,6]:

• Single point-of-failure: if the IdP system fails, then user authentication should be provided continually.
• User anonymity: user anonymity must be guaranteed in the authentication phase via a public channel.
• User impersonation attack: even if an attacker eavesdrops on messages between the user and the SP transmitted via a public channel, the user impersonation attack must be protected.

6.3. Assumption

This paper assumes that the private key is stored securely in a tamper-proof smart card and protected by the user’s password. In the event that the password is entered incorrectly more than a set number of times, for example, five times, access to the private key will be blocked. To regain access to the service, the user must complete the re-registration process, thereby ensuring that only authorized users can access the private key. This security measure effectively mitigates the risk of unauthorized access and provides a robust solution for secure private key storage.

7. Proposed Scheme

This section proposes a distributed and federated authentication scheme based on updatable SCs that comprise six phases: initialization, user and SP registration, mutual authentication, user revocation, service provider enrollment revocation, and SC updating. The notation used in the proposed scheme are listed in

Table 1. Notation.

Notations and Abbreviations	Description
$I{D}_U$, $I{D}_{SP}$, $I{D}_{IdP}$	Identity of the user, SP, and IdP, respectively
$TI{D}_U$, $TI{D}_{SP}$	Temporary identity of the user and SP, respectively
$P{W}_U$, $P{W}_{SP}$	Password of the user and the SP, respectively
$S{K}_U$, $S{K}_{SP}$, $S{K}_{IdP}$	ECDSA private key of the user, SP, and IdP, respectively
$ES{K}_U$, $ES{K}_{SP}$	Encrypted private key using a password of the user and the SP, respectively
$P{K}_U$, $P{K}_{SP}$, $P{K}_{IdP}$	ECDSA public key of the user, SP, and IdP, respectively
$Cer{t}_U$, $Cer{t}_{SP}$	Certification of the user and SP, respectively
$AD{D}_{IdP}$	Address for an IdP’s MC
$AD{D}_{AC}$	Address for an AC
$Sig(.)$	ECDSA signature generation function
$Verify(.)$	ECDSA signature verification function
$h(.)$	Hash function
‖	Concatenation operator
⊕	Bit wise XOR
$SK$	Session key
$SP$	Service provider
$IdP$	Identity provider
$MC$, $AC$, $SC$	Main contract, authentication contract, and smart contract, respectively

.

7.1. Initialization

During system initialization, each IdP creates and deploys SCs in the blockchain and stores the addresses of the SCs. The detailed content of the SCs is shown in Figure 13. The IdP chooses an elliptic curve, E, defined over a finite field, $F_q$, of characteristic p and base point $G\in E\left(F_q\right)$, and securely generates the ECDSA’s key pair, $S{K}_{IdP}$ and $P{K}_{IdP}$, and the IdP’s identity $I{D}_{IdP}$.

7.2. Registration Phase

In the registration phase, the user and SP register with the IdP. First, the user registration process is as follows:

• The user generates a $P{W}_U$ and an $I{D}_U$.
• The user sends the $I{D}_U$ to the IdP through a secure channel for registration.
• Upon receiving the $I{D}_U$, the IdP generates the ECDSA key pair, $S{K}_U$ and $P{K}_U$, and computes certificate $Cer{t}_U=$$P{K}_U\left|\right|I{D}_U\left|\right|I{D}_{IdP}\left|\right|Sig(S{K}_{IdP},$$P{K}_U\left|\right|I{D}_U\left|\right|I{D}_{IdP})$.
• The IdP stores $I{D}_U$ and $Cer{t}_U$ in its own MC, as presented in

  Table 2. Data stored in the IdP’s MC.

  Data	Description
  $I{D}_{U/SP}$	Identity of user or SP
  $TI{D}_{U/SP}$	Temporary identity of user or SP
  	Initial value = $I{D}_{U/SP}$
  $Cer{t}_{U/SP}$	User or SP certificate.
  Revocation status	Revocation status of user or SP
  	Initial value = false

  .
• The IdP sends $S{K}_U\left|\right|{ADD}_{IdP}$ via a secure channel to the user.
• Upon receiving $S{K}_U\left|\right|{ADD}_{IdP}$, the user stores $I{D}_U$, $ES{K}_U=S{K}_U\oplus h\left(P{W}_U\right)$, and ${ADD}_{IdP}$, as listed in

  Table 3. Data stored in the user or SP.

  Data	Description
  $TI{D}_{U/SP}$	Temporary identity of user or SP
  	Initial value = $I{D}_{U/SP}$
  $ES{K}_{U/SP}$	Encrypted private key of user or SP
  $AD{D}_{IdP}$	Address of the IdP

  .

Second, the registration phase of the SP is identical to that of the users. The SP registration process is as follows:

• The SP generates $P{W}_{SP}$ and $I{D}_{SP}$.
• The SP sends $I{D}_{SP}$ to the IdP through a secure channel for registration.
• Upon receiving $I{D}_{SP}$, the IdP generates the ECDSA key pair, $S{K}_{SP}$ and $P{K}_{SP}$, and computes the certificate $Cer{t}_{SP}=$$P{K}_{SP}\left|\right|I{D}_{SP}\left|\right|I{D}_{IdP}\left|\right|Sig(S{K}_{IdP},$$P{K}_{SP}\left|\right|I{D}_{SP}\left|\right|I{D}_{IdP})$.
• The IdP stores $I{D}_{SP}$ and $Cer{t}_{SP}$ in its MC, as presented in Table 2.
• The IdP sends $S{K}_{SP}\left|\right|AD{D}_{IdP}$ via a secure channel to the SP.
• Upon receiving $S{K}_{SP}\left|\right|{ADD}_{IdP}$, the SP stores $I{D}_{SP}$, $ES{K}_{SP}=S{K}_{SP}\oplus h\left(P{W}_{SP}\right)$, and ${ADD}_{IdP}$, as listed in Table 3.

Details regarding the registration phase are shown in Figure 14.

7.3. Mutual Authentication Phase

In this authentication step, a user and an SP perform mutual authentication using the IdP SCs for the user to access the SP. After this phase, the user and the SP can generate session keys for secure communication. The mutual authentication phase process is as follows:

• The user enters $P{W}_U$ and computes $S{K}_U=ES{K}_U\oplus h\left(P{W}_U\right)$. Subsequently, the user generates timestamp $t{s}_U$ and a random number, $r_U$, and computes $K_U=r_U·G$, $T_U=h(K_U\left|\right|t{s}_U)$, and $V_U=EC.sign(S{K}_U,T_U)$. Subsequently, the user generates the request message $M_U=TI{D}_U\left|\right|AD{D}_{IdP}\left|\right|K_U\left|\right|V_U\left|\right|t{s}_U$.
• The user requests to log in by sending $M_U$ to the SP via a public channel.
• Upon receiving $M_U$, the SP verifies whether $t{s}_U$ is in a valid range. The SP terminates the authentication process if $t{s}_U$ is invalid. Otherwise, the SP generates the MC’s input as $T{X}_{in}=Typ{e}_{entity}\left|\right|TI{D}_U\left|\right||V_U\left|\right|t{s}_U$, where $Typ{e}_{entity}$ represents the “user”.
• The SP invokes the IdP’s MC using $AD{D}_{IdP}$ in $M_U$ by sending $T{X}_{in}$.
• The MC searches for the $I{D}_U$ that matches $TI{D}_U$ in $T{X}_{in}$, and then verifies the revocation status. If the revocation status of the $I{D}_U$ is $true$, then the MC returns the fail signal to the SP; otherwise, the MC searches for a certificate, $Cer{t}_U$, that matches $I{D}_U$.
• The MC calls its own AC as a delegate call by sending $T{X}_{in}$ and $Cer{t}_U$.
• Upon receiving $T{X}_{in}$ and $Cer{t}_U$, the AC verifies $V_U$ in $T{X}_{in}$ as $EC.Verify(P{K}_U,V_U)$. Subsequently, if $Typ{e}_{entity}$ equals “user”, the AC changes the temporary identity of the user to $TI{D}_U$ = $h\left(TI{D}_U\right|\left|V_U\right)$ and stores it in the MC’s storage.
• If $V_U$ is invalid, the AC returns a failed signal to the MC. Otherwise, the AC returns a successful signal to the MC.
• Upon receiving the results of the AC, the MC returns $I{D}_U$ to the SP.
• Upon receiving the results of the MC, the SP enters $P{W}_{SP}$ and computes $S{K}_{SP}=ES{K}_{SP}\oplus h\left(P{W}_{SP}\right)$. Next, the SP generates the timestamp $t{s}_{SP}$ and a random number $r_{SP}$ and computes $K_{SP}=r_{SP}·G$, $T_{SP}=h(K_{SP}\left|\right|t{s}_{SP})$, and $V_{SP}=EC.sign(S{K}_{SP},T_{SP})$. Subsequently, the SP generates a response message, $M_{SP}=TI{D}_{SP}\left|\right|AD{D}_{IdP}\left|\right|K_{SP}\left|\right|V_{SP}\left|\right|t{s}_{SP}$, and generates a session key, $SK=r_{SP}·K_U$.
• The SP allows login for the user corresponding to the identity $I{D}_U$ by sending $M_{SP}$ to the user.
• Upon receiving $M_{SP}$, the user verifies whether $t{s}_{SP}$ is within a valid range. If $t{s}_{SP}$ is invalid, then the user terminates the authentication process. Subsequently, the user changes $TI{D}_U$ to $TI{D}_U$ = $h\left(TI{D}_U\right|\left|V_U\right)$ and generates a session key as $SK=r_U·K_{SP}$. Next, the user generates the MC’s input as $T{X}_{in}=Typ{e}_{entity}\left|\right|TI{D}_{SP}\left|\right|V_{SP}\left|\right|t{s}_{SP}$, where $Typ{e}_{entity}$ represents “SP”.
• The user invokes the IdP’s MC using $AD{D}_{IdP}$ in $M_{SP}$ by sending $T{X}_{in}$.
• The MC searches for the $I{D}_{SP}$ that matches $TI{D}_{SP}$ in $T{X}_{in}$ and then verifies the revocation status. If the revocation status of $I{D}_{SP}$ is true, then the MC returns the fail signal to the user; otherwise, the MC searches for a certificate, $Cer{t}_{SP}$, that matches $I{D}_{SP}$.
• The MC calls its AC as a delegate call by sending $T{X}_{in}$ and $Cer{t}_{SP}$.
• Upon receiving $T{X}_{in}$ and $Cer{t}_{SP}$, the AC verifies $V_{SP}$ in $T{X}_{in}$ as $EC.Verify(P{K}_{SP},V_{SP})$.
• If $V_{SP}$ is invalid, the AC returns a failed signal to the MC. Otherwise, the AC returns a successful signal to the MC.
• Upon receiving the AC’s result indicating a failed signal, the MC returns it to the user. Otherwise, the MC returns the user $I{D}_{SP}$ to the user.

Details regarding the mutual authentication phase are shown in Figure 15.

7.4. Revocation Phase

In this registration phase, the user and SP revoke their registration because of the loss of the ECDSA private key. The user can perform revocation using the SP or IdP, whereas the SP can be revoked using the IdP. The revocation process is as follows:

• The user enters $P{W}_U$ and computes $S{K}_U=ES{K}_U\oplus h\left(P{W}_U\right)$. Next, the user generates timestamp $t{s}_U$, selects the revocation list $textReason$, and computes $T_U=h(t{s}_U\left|\right|textReason)$ and $V_U=EC.sign(S{K}_U,T_U)$. Subsequently, the user generates a request message $M_U=TI{D}_U\left|\right|AD{D}_{IdP}\left|\right|V_U\left|\right|t{s}_U\left|\right|textReason$.
• The user requests the user revocation by sending $M_U$ to the SP or the IdP via a public channel.
• Upon receiving $M_U$, the SP or the IdP verifies whether $t{s}_U$ is within a valid range. If $t{s}_U$ is invalid, the SP or IdP terminates the revocation process. Otherwise, the SP or IdP generates the MC input as $T{X}_{in}=TI{D}_U\left|\right|V_U\left|\right|t{s}_U\left|\right|textReason$.
• The SP or IdP invokes the IdP’s MC using $AD{D}_{IdP}$ in $M_U$ by sending $T{X}_{in}$.
• The MC searches for an $I{D}_U$ that matches $TI{D}_U$ in $T{X}_{in}$; subsequently, the MC verifies the revocation status. If the revocation status of $I{D}_U$ is $true$, the MC returns a fail signal to the requester. Otherwise, the MC searches for a certificate, $Cer{t}_U$, that matches $I{D}_U$.
• The MC calls its own AC as a delegate call by sending $T{X}_{in}$ and $Cer{t}_U$.
• Upon receiving $T{X}_{in}$ and $Cer{t}_U$, the AC verifies $V_U$ in $T{X}_{in}$ as $EC.Verify(P{K}_U,V_U)$. Subsequently, the AC changes the revocation status of $I{D}_U$ to true and stores it in the MC storage.
• If $V_U$ is invalid, the AC returns a failed signal to the MC. Otherwise, the AC returns a successful signal to the MC.
• Upon receiving the AC’s result, the MC returns the result to the SP or the IdP.
• Upon receiving the SP or IdP’s result, the SP or IdP returns the result to the user.

The revocation phase of the SP is identical to that of the users. The SP revocation process is as follows:

• The SP enters $P{W}_{SP}$ and computes $S{K}_{SP}=ES{K}_{SP}\oplus h\left(P{W}_{SP}\right)$. Next, the SP generates timestamp $t{s}_{SP}$, selects the revocation list $textReason$, and computes $T_U=h(t{s}_{SP}\left|\right|textReason)$ and $V_{SP}=EC.sign(S{K}_{SP},T_{SP})$. Subsequently, the user generates a request message, $M_{SP}=TI{D}_{SP}\left|\right|AD{D}_{IdP}\left|\right|V_{SP}\left|\right|textReason$.
• The SP requests revocation by sending $M_{SP}$ to the IdP via a public channel.
• Upon receiving $M_{SP}$, the IdP verifies whether $t{s}_{SP}$ is within a valid range. If $t{s}_{SP}$ is invalid, the IdP terminates the revocation. Otherwise, the IdP generates the MC input as $T{X}_{in}=TI{D}_{SP}\left|\right|V_{SP}\left|\right|t{s}_{SP}\left|\right|textReason$.
• The IdP invokes the IdP’s MC using $AD{D}_{IdP}$ in $M_{SP}$ by sending $T{X}_{in}$.
• The MC searches for the $I{D}_{SP}$ that matches $TI{D}_{SP}$ in $T{X}_{in}$. Subsequently, the MC verifies the revocation status. If the revocation status of $I{D}_{SP}$ is true, the MC returns a fail signal to the requester. Otherwise, the MC searches for a certificate, $Cer{t}_{SP}$, that matches $I{D}_{SP}$.
• The MC calls its own AC as a delegate call by sending $T{X}_{in}$ and $Cer{t}_{SP}$.
• Upon receiving $T{X}_{in}$ and $Cer{t}_{SP}$, the AC verifies $V_{SP}$ in $T{X}_{in}$ as $EC.Verify(P{K}_{SP},V_{SP})$. Subsequently, the AC changes the revocation status of $I{D}_{SP}$ to $true$ and stores it in the MC storage.
• If $V_{SP}$ is invalid, the AC returns a failed signal to the MC. Otherwise, the AC returns a successful signal to the MC.
• Upon receiving the AC’s result, the MC returns the result to the IdP.
• Upon receiving the IdP’s result, the IdP returns the result to the SP.

Details regarding the revocation phase are shown in Figure 16.

7.5. Smart Contract Updating Phase

In the SC updating phase, an IdP can update its AC. The IdP creates and deploys a new AC and updates $AD{D}_{AC}$ in its MC.

8. Security Analysis of Proposed Scheme

This section analyzes the security of the proposed scheme using two methods. For a formal security analysis, the ProVerif [27] protocol verification tool is used to show that the proposed scheme can satisfy security and authentication features. In addition, an informal security analysis is presented to demonstrate that the proposed scheme satisfies the security requirements for federated authentication.

8.1. Formal Security Analysis

Herein, ProVerif [27] was used to analyze the security of the proposed scheme. Recently, Ryu et al. [28], Kang et al. [29], Zhang et al. [30], and Edris et al. [31] have adopted ProVerif [27], which is an automatic cryptographic protocol verifier, for protocol security validation. Based on the formal security analysis in this study, the session key was confirmed to not be exposed. Three channels were used for security analysis. “Private Channel 1” transmits sensitive data between the user and the SP or the IdP. “Public Channel 1” transmits general data between the user and SP. Finally, “Public Channel 2” transmits general data between the user or the SP and SCs.

Table 4. Definitions of channels, variables, and other related parameters.

(*—-channels—-*)

free privateChannel1:channel [private].

free publicChannel1:channel.

free publicChannel2:channel.

(*—-constants—-*)

free IDU:bitstring [private].

free IDSP:bitstring [private].

free ADDAC:bitstring.

(*—-shared key—-*)

free G:bitstring [private].

free SK:bitstring [private].

(*—-functions—-*)

fun concat(bitstring, bitstring):bitstring.

fun h(bitstring):bitstring.

fun mult(bitstring, bitstring):bitstring.

fun sign(bitstring, bitstring):bitstring.

fun verify(bitstring, bitstring):bitstring.

(*—-events—-*)

event startUi(bitstring).

event endUi(bitstring).

event startSP(bitstring).

event endSP(bitstring).

event startAC(bitstring).

event endAC(bitstring).

lists the channels, variables, and related parameters.

Table 5. User process.

(*—-Ui process—-*)

let Ui =

out(privateChannel1,(IDU));

in(privateChannel1, (XSKu:bitstring, ADDIdP:bitstring));

let TIDU=IDU in

event startUi(IDU);

new tsU:bitstring;

new rU:bitstring;

let KU = mult(rU, G) in

let TU = h(concat(KU, tsU)) in

let VU = sign(XSKu, TU) in

out(publicChannel1, (TIDU, ADDIdP, KU, VU, tsU));

in(publicChannel1, (TIDSP:bitstring, ADDIdP2:bitstring, KSP:bitstring, VSP:bitstring, tsSP:bitstring));

let TID=h(concat(TIDU, VU)) in

let SK = mult(rU, KSP) in

new Typeentity:bitstring;

out(publicChannel2, (Typeentity, TIDSP, VSP, tsSP));

in(publicChannel2, (xIDSP:bitstring));

event endUi(IDU).

,

Table 6. SP process.

(*—-SP process—-*)

let SP =

out(privateChannel1,(IDSP));

in(privateChannel1, (XSKsp:bitstring, ADDIdP:bitstring));

let TIDSP=IDSP in

event startSP(IDSP);

in(publicChannel1, (TIDU:bitstring, ADDIdP2:bitstring, KU:bitstring, VU:bitstring, tsU:bitstring));

new Typeentity:bitstring;

out(publicChannel2, (Typeentity, TIDU, VU, tsU));

in(publicChannel2, (xIDU:bitstring));

new tsSP:bitstring;

new rSP:bitstring;

let KSP = mult(rSP, G) in

let TSP = h(concat(KSP, tsSP)) in

let VSP = sign(XSKsp, TSP) in

let SK = mult(rSP, KU) in

out(publicChannel1, (TIDSP, ADDIdP2, KSP, VSP, tsSP));

event endUi(IDSP).

and

Table 7. AC process.

(*—-AC process—-*)

let AC =

in(privateChannel1,(XIDentity:bitstring));

new SKIdP:bitstring;

new PKIdP:bitstring;

new SKentity:bitstring;

new PKentity:bitstring;

new IDIdP:bitstring;

let Certsign = sign(SKIdP, concat(concat(PKentity,XIDentity),IDIdP)) in

event startAC(ADDAC);

in(publicChannel2, (XPKentity:bitstring, Ventity:bitstring));

new true:bitstring;

if (verify(XPKentity, Ventity)=true) then

out(publicChannel2, true);

event endAC(ADDAC).

list the processes of the user, SP, and SCs, respectively, during the registration and mutual authentication phases. The SC process was analyzed for an AC that performs an actual authentication operation. The queries and the main processes are listed in

Table 8. Queries and main processes.

(*—-queries—-*)

query idu:bitstring; inj-event(endUi(idu)) ==> inj-event(startUi(idu)).

query idsp:bitstring; inj-event(endSP(idsp)) ==> inj-event(startSP(idsp)).

query addac:bitstring; inj-event(endAC(addac)) ==> inj-event(startAC(addac)).

query attacker(SK).

(*—-process—-*)

process

((!Ui)|(!SP)|(!AC))

. The results of the proposed scheme are presented in

Table 9. Results.

Verification summary:

Query inj-event(endUi(idu)) ==> inj-event(startUi(idu)) is true.

Query inj-event(endSP(idsp)) ==> inj-event(startSP(idsp)) is true.

Query inj-event(endAC(addac)) ==> inj-event(startAC(addac)) is true.

Query not attacker(SK[]) is true.

. The query, not attackers (SK[]), is true in Table 9, thus indicating that the proposed protocol protects the session key, $SK$, from attackers.

8.2. Informal Security Analysis

• ID Guessing Attack: In the proposed scheme, $I{D}_{U/SP}$ is not directly used. As this study employed $TI{D}_{U/SP}$, which changes every authentication, rather than $I{D}_{U/SP}$, an attacker cannot obtain $I{D}_{U/SP}$ through a public channel. Therefore, the proposed scheme can protect against ID guessing attacks.
• Replay Attack: Even if the attacker steals $M_U$ in the mutual authentication phase and presents it to the SP, the SP can determine whether the message $M_U$ is reused because the SP verifies that the timestamp $t{s}_U$ is within a valid range. Moreover, because $V_U$ is a digital signature that can only be created using the user’s private key, $t{s}_U$ cannot be changed and a signature for the changed $t{s}_U^{{}^{\prime }}$ cannot be generated. Therefore, the proposed scheme can provide protection against replay attacks.
• User Impersonation Attack: Even if the attacker steals $M_U$ and replaces the user’s identity, $TI{D}_U$, with the attacker’s identity, $TI{D}_A$, the SP can identify an invalid user. If the attacker is not registered in the IdP registered by the user, then the MC returns a fail signal to the SP because it can not identify $I{D}_A$ that matches $TI{D}_U$. In addition, if the attacker is registered in the IdP registered by the user, the MC returns a fail signal to the SP because the AC verifies $V_U$ with $Cer{t}_A$ and fails the verification. Therefore, the proposed scheme can provide protection against user impersonation attacks.
• Server Impersonation Attack: For the same reason as user impersonation attacks, the user can determine an invalid SP. Even if the attacker steals $M_{SP}$ and replaces the SP’s identity, $TI{D}_{SP}$, with the attacker’s identity, $TI{D}_{SP}$, the user can determine an invalid SP. If the attacker is unregistered in the IdP registered with the SP, the MC returns a fail signal to the user because the MC cannot find the $I{D}_{SP}$ that matches $TI{D}_{SP}$. In addition, if the attacker is registered in the IdP registered with the SP, the MC returns a fail signal to the user because the AC verifies $V_{SP}$ with $Cer{t}_A$ and fails the verification. Therefore, the proposed scheme can protect against server impersonation attacks.
• Privileged Insider Attack: In the proposed scheme, the SP and IdP are separated and the SP does not possess information related to user authentication; therefore, an attack by an insider of the SP is impossible. In addition, without the random number, $r_U$, possessed only by the user, the session key cannot be obtained with only $I{D}_U$, $TI{D}_U$, and $Cer{t}_U$ stored in the IdP’s SC. Therefore, the proposed scheme can provide protection against privileged insider attacks.
• Session Key Disclosure: Computing the session keys $SK=r_U·r_{SP}·G$, $r_U$ and $r_{SP}$ is required. However, because $r_U$ and $r_{SP}$ contain only the user and SP information, only the user’s session keys and the SP can be generated. Therefore, the proposed scheme can protect against session key disclosure attacks.
• Forward Secrecy and Backward Secrecy: Even if the attacker obtains the session key, they will be unable to access the previous or subsequent keys, as each one is generated randomly with no correlation to the others. Therefore, the proposed scheme can preserve forward and backward secrecy.
• Mutual Authentication: The user and the SP authenticate each other by verifying $M_U$ and $M_{SP}$ because $M_U$ and $M_{SP}$ can utilize their private keys. Therefore, the proposed scheme provides mutual authentication.
• User Anonymity: In the proposed scheme, $TI{D}_{U/SP}$, which changes at every authentication step, was used. Therefore, the proposed scheme ensures user anonymity.
• Single Point-of-Failure: Even if the IdP system fails, user authentication can be performed normally because the proposed scheme uses SCs for authentication. Therefore, the proposed scheme can protect against single-point failures.

The results of the security analysis, with comparisons to related studies, are presented in

Table 10. Comparison of security features.

Security Features	Cheng et al. [8]	Xiang et al. [7]	Xue et al. [13]	Ours
1. ID Guessing Attack	O	O	X	O
2. Replay Attack	O	O	O	O
3. User Impersonation Attack	O	O	X	O
4. Server Impersonation Attack	O	O	X	O
5. Privileged Insider Attack	O	O	X	O
6. Session Key Disclosure	O	O	O	O
7. Forward Secrecy and Backward Secrecy	O	O	O	O
8. Mutual Authentication	O	O	O	O
9. User Anonymity	O	O	X	O
10. Single Point-of-Failure	X	X	O	O

.

9. Performance Analysis

This section analyzes the performance of our system in terms of the computational cost of cryptographic calculations using the same method as that used in numerous authentication-related studies [32,33,34,35,36,37]. The development environment used to analyze the performance is presented in

Table 11. Development environment.

Item	Value
CPU	Intel(R) Core(TM) i7-8565U CPU @ 1.80 GHz 1.99 GHz
RAM	16.0 GB
OS	Windows 10 Home
Software	JDK 17
Security level	secp521r1 ECC

. The five symbols listed in

Table 12. Computational cost of cryptographic calculations (ms).

Symbol	Meaning	Time (ms)
$T_h$	The computational cost of a one-way hash function operation.	$0.007$
$T_m$	The computational cost of scalar multiplication in the field.	$34.32$
$T_e$	The computational cost of symmetric encryption or decryption.	$0.23$
$T_s$	The computational cost of the ECDSA sign.	$22.93$
$T_v$	The computational cost of the ECDSA verification.	$44.03$

were used for the performance analysis of the proposed scheme. A comparison of the computational overhead in the authentication phase was performed between the proposed and other related schemes [7,8,13] (see

Table 13. Comparison of computational costs.

Schemes	Cheng et al. [8]	Xiang et al. [7]	Xue et al. [13]	Ours
User	$4T_m+4T_h+2T_e$	$8T_m+4T_h$	$2T_m+T_h+T_s$	$2T_m+3T_h+T_s$
	$=138.02$	$=274.84$	$=91.64$	$=91.78$
Server	$4T_m+2T_h+T_e$	$9T_m+4T_h$	$2T_m+T_h+T_s$	$2T_m+2T_h+T_s$
	$=137.65$	$=309.16$	$=91.64$	$=91.71$
Smart Contracts	-	-	$T_h+2T_v$	$2T_h+T_v$
	-	-	$=88.13$	$=44.17$
Total	$8T_m+6T_h+3T_e$	$18T_m+8T_h$	$4T_m+3T_h+2T_s+2T_v$	$4T_m+7T_h+2T_s+T_v$
	$=275.67$	$=618.32$	$=271.41$	$=227.66$

).

10. Discussion and Limitations

This study provides a distributed and federated authentication scheme that can resist various security threats, including a single point-of-failure. That is, even if the IdP server fails, the authentication service using the corresponding IdP is not affected. Moreover, this scheme using updatable SCs can support the fixing of programming bugs, adding the function of a smart contract, or changing business logic. For example, the previously registered user and SP data can be easily maintained, even if the cryptographic algorithms must be changed for security. In Section 9, the computational overhead during the authentication phase of the three schemes was compared [7,8,13].

$$(t_1-t_2)/t_2$$

(1)

In Equation (1), $t_1$ represents the average computational cost of the two schemes [7,8] and $t_1$ represents the cost of the proposed method. The results of the computational calculations indicate that the proposed method outperformed the other methods by 71%. Therefore, the proposed scheme is expected to provide federated authentication services efficiently using SCs. However, the proposed scheme assumes that the private key is stored on a tamper-proof smart card. Therefore, the user may have the inconvenience of having to carry a smart card. In future studies, we will focus on improving usability, and we plan to conduct additional research and apply private key protection technology, such as behavior-based biometric authentication, without the need for a smart card.

11. Conclusions

In this study, a distributed and federated authentication scheme was proposed based on updatable SCs. Federated authentication, such as Google ID, enables users to conveniently access multiple websites using a single login credential. In the event of an IdP server failure, the entire service may become inaccessible owing to the IdP server’s general management of all login credentials. Thus, in this study, we focused on using SCs to overcome a single point-of-failure in federated authentication. A security analysis was performed and confirmed that the proposed scheme provides protection against not only single point failure, but also common attacks, including ID guessing attacks, replay attacks, user impersonation attacks, server impersonation attacks, privileged insider attacks, session key disclosure, and forward and backward security. Furthermore, the proposed scheme can maintain previously registered user and SP data even if the SC is updated for bug fixes or to update the authentication function of an SC. In addition, the proposed scheme outperformed other methods by 71%. Thus, it is expected to be widely used as one login credential in various fields such as internet banking and e-commerce without concerns regarding single points-of-failure. However, the user may have the inconvenience of carrying a smart card, because our scheme assumes that the private key is stored in a tamper-proof smart card. Therefore, further studies are required on technologies that protect private keys, such as behavior-based biometric authentication, to improve usability.