Distributed Public Key Certificate-Issuing Infrastructure for Consortium Certificate Authority Using Distributed Ledger Technology

. With the development of cloud services and the Internet of Tings, the integration of heterogeneous systems is becoming increasingly complex. Identity management is important in the coordination of various systems, and public key infrastructure (PKI) is widely known as an identity management methods. In PKI, a certifcate authority (CA) acts as a trust point to guarantee the identity of entities such as users, devices, and services. However, traditional CAs that delegate the operations to a specifc organization are not always suitable for heterogeneous services, and a new methodology is required to enable multiple stakeholders to securely and cooperatively operate a CA. In this study, we introduce the concept of a consortium CA and propose a distributed public key certifcate-issuing infrastructure that realizes a consortium CA. Te proposed infrastructure enables multiple organizations to cooperatively operate a CA suitable for services involving multiple stakeholders. We identify four requirements for the cooperative operation of a consortium CA and design the proposed infrastructure with distributed ledger technology. Furthermore, we present the implementation of smart contracts with Hyperledger Fabric and prove that the proposed infrastructure satisfes the four requirements. Finally, we confrm that certifcate issuance and verifcation are stable at approximately 4 and 3 ms, respectively.


Introduction
Identity is critical to security mechanisms such as authentication and access control. Weak identity management mechanisms allow for impersonation attacks.
Public key infrastructure (PKI) is widely known as a mechanism for confrming the identity of entities and linking the identity to a public key certifcate. In PKI, a certifcate authority (CA) acts as a trust point to guarantee the identity of entities, such as users, devices, and services and allows only authenticated entities to connect to the system. A CA issues a public key certifcate that contains a public key and the identity of its owner. By verifying the public key certifcate, the verifer can believe that the CA guarantees that the owner possesses the public key. A CA is responsible for the authenticity of the content of a public key certifcate and is called a single trust point.
CAs can be classifed into two types depending on operation forms: public and private. Public CAs are operated as services by socially trusted companies for Internet use. Te main role of a public CA is to issue public key certifcates to web servers. Public CAs and browser vendors release baseline requirements that all public CAs must follow [1]. Unlike a public CA, which is strictly enforced, private CAs are not required to be as strict as public CAs. A private CA has the same function as a public CA in issuing public key certifcates, but a private CA is operated only within a specifc domain by a private organization. Tus, a private CA can be used in a form suitable for domain-specifc situations: when issuing numerous public key certifcates at a high frequency, when issuing public key certifcates dedicated to a specifc framework, or when policy prohibits the use of a public CA.
With the development of cloud services and wireless technology, various services and devices are being linked together. Tis is known as the Internet of Tings, which involve connecting numerous devices to the Internet, not just people accessing the Internet with a browser. Tis trend has led to the creation of heterogeneous systems such as cross-domain services [2], cyber-physical systems [3], and digital twins [4]. Such a system involving various stakeholders requires fexible ID management according to individual situations, but it is difcult for public CAs and their additional mechanism, Certifcate transparency (CT), to manage IDs fexibly. In CT, issued certifcates are recorded in CT logs and made public. According to [5], client certifcates published in CT logs can leak private enterprise information, such as business relationships, user growth measurements, and the existence of internal projects prior to their public announcements. Te same is true for device certifcates, which can reveal what kinds of devices and how many devices company own. In addition, there are fnancial cost issues with device certifcates, and there are cases where public CAs are not suitable. Te fexibility of private CAs may be suitable for this issue, but overcoming the stakes and operating a CA securely is challenging. Figure 1 is an example of a cross-domain service [2]. A consumer can use the charging services while using the parking services; this is an interdomain scenario. Moreover, mobility service domains, for instance, may provide route optimization services by integrating and combining diferent mobility services; this is a single-domain scenario. In this scenario, if a particular organization operates a private CA, the issuance of certifcates would be managed by that organization. In such an operation, it is difcult to detect arbitrarily issued certifcates. If each organization operates its own private CA, certifcate issuance is not dependent on any one organization, but since each organization operates its own CA, the attack points increase. In addition, sufcient security measures must be taken by each organization to ensure that security is breached from the weakest point, that is, a methodology for securely operating a private CA under multiple stakeholders is required. In this study, we propose a distributed public key certifcate-issuing infrastructure that allows multiple organizations to cooperatively operate CAs suitable for consortium-type services. In consortium-type services, because multiple organizations cooperate in providing services, the operation of the service should not be infuenced by any particular organization. Terefore, to strictly guarantee the identity of service use in consortiumtype services, the participating organizations in the consortium must be able to operate CAs in a cooperative manner. However, many security risks are associated with CA operations. Te security risks increase if many organizations are involved in the operation of a CA. In this study, we focus on the risk of the unauthorized use of private keys. If a CA's private key is compromised by any organization in the consortium, the organization can issue arbitrary public key certifcates using the compromised private key.
For security use of the CA's private key, we employ distributed ledger technology (DLT), also known as blockchain. Te proposed infrastructure is built on a DLT system, and all organizations participate in the DLT system. Use of the private key is restricted to smart contracts only in the proposed infrastructure because the availability of the private key in any context leads to arbitrary public key certifcates. Smart contracts have business logic agreed upon by all organizations. As long as a private key is used in a smart contract, its use can be considered as authorized by the participating organizations. However, smart contracts do not protect the confdentiality of the data they use; the private key could be compromised during the execution of smart contracts. In the proposed infrastructure, we use Hyperledger Fabric Private Chaincode (FPC) [6] and protect the confdentiality of the private key during the execution of smart contracts.
Tis study contributes to the following: (i) We introduce the concept of a consortium CA and identify the requirements for operating the consortium CA. (ii) We design a distributed public key certifcateissuing infrastructure as a consortium CA using DLT. (iii) We implement a prototype system for the proposed infrastructure with Hyperledger Fabric and evaluate the execution time of smart contracts that perform CA functions. Te prototype system maintains the confdentiality of CA's private key using private chaincode, which is an extension of Hyperledger Fabric.
Te remainder of this paper is organized as follows: Section 2 describes PKI, Intel Software Guard Extensions (Intel SGX), Hyperledger Fabric, and Hyperledger FPC, which are the technologies used in this proposal. Section 3 describes the concepts of consortium CA and the design policy of this proposal, and Section 4 discusses the data structures and transactions designed to implement the distributed public key certifcate-issuing infrastructure. Section 5 describes the implemented smart contract. Section 6 provides a security analysis. Section 7 provides a qualitative and quantitative evaluation. Section 8 compares the proposed infrastructure with those in related studies, and Section 9 concludes the paper.

Background
2.1. PKI. PKI is a framework that links a public key and its owner's identity and provides a mechanism for verifying that the communicating party is actually the owner of the public key based on public key cryptography. A CA, which is a single trust point, is responsible for guaranteeing the identity of the owner and issues a public key certifcate to the owner after confrming their identity. Te CA signs the public key certifcate with its own private key to guarantee its contents. Te owner can prove its authenticity by presenting the public key certifcate to other parties with whom it communicates.
A typical example of a public key certifcate is X.509. Te X.509 certifcate format is standardized by the International Telecommunication Union (ITU). As shown in Table 1, an X.509 public key certifcate consists of a presigned certifcate, signature algorithm, and signature value. Te presigned certifcate contains basic information such as a subject name, a validity period, a public key, and extensions.
Public key certifcates must be classifed according to their purpose, and a major classifcation is whether they are public key certifcates for CAs. Public key certifcates for CAs are used to guarantee the ownership of public keys and verify other public key certifcates issued by the CA. Whether a certifcate is a CA certifcate or not is expressed by a dedicated fag in the extensions feld of the X.509 certifcate. Figure 2 shows the fow of the application, issuance, and verifcation processes. In PKI, a certifcate holder (CH) presents a public key certifcate to a relying party (RP), and the RP identifes the CH with the certifcate. Public key certifcates are issued by authorities: a registration authority (RA) and a certifcate authority (CA). In the application process, the CH generates a key pair and signs a certifcate signing request (CSR) with the private key (Step 1-1). Te CSR contains all information necessary for the CA to issue a certifcate, such as a common name, organization name, and public key of the CH. Ten, the CSR is sent to the RA (Steps 1-2). Te RA verifes and confrms the identity of the CH (Steps 1-3). After confrming the identity, the application process is completed. In the issuance process, the RA sends the CSR to the CA and requests issuing a public key certifcate (Steps 2-1). Upon receiving the request, the CA frst creates a presigned certifcate based on the CSR. Ten, the CA signs the presigned certifcate with the CA's private key to create a public key certifcate (Step 2-2) and issues this public key certifcate to the CH (Steps 2-3). Te CA maintains a repository that publishes the issued public key certifcates and certifcate revocation lists (CRL) and updates the repository as necessary. In the verifcation process, the CH presents the public key certifcate issued by the CA to the relying party to prove the identity of the CH (Steps 3-1). Te relying party obtains the CRL and CA's public key certifcate (Steps 3-2) and verifes the certifcate presented by the CH (Step 3-3). Te information retrieved from the repository can be cached; thus, so the relying party does not need to access the repository's every verifcation process. If the verifcation is successful, the relying party can trust the identity of the CH. Figure 3 shows the processes of signing and verifying public key certifcates. Te signing process is performed by encrypting the hashed presigned certifcate with the CA's private key, as shown on the left side of Figure 3, that is, the signature value of the certifcate can only be created by the CA. Te CA is required to sign the certifcate with the agreement of its content, thereby guaranteeing the content of the certifcates. Moreover, as shown on the right side of Figure 3, the verifcation is performed by checking whether  [7] and the four cornered trust model [8,9] are among the latest PKI technologies.
CT is an additional mechanism for increasing certifcate transparency, in which the CA stores a record of every certifcate it issues in third-party CT logs. By reviewing the CT log, the certifcate holder can verify that no fraudulent certifcates or certifcates from nonpolicy CAs have been issued for his or her domain. Tis prevents the RP from trusting a fraudulently issued certifcate. When a certifcate is provided to the CT log, the CT logs return data called a signed certifcate timestamp (SCT). Te certifcate owner presents the SCT with the certifcate when it is presented. Te RP can use the certifcate and SCT to verify that the certifcate's data are registered in the CT log.
Te four cornered trust model adds an entity called a trust broker to the traditional PKI. Te trust broker objectively evaluates the trustworthiness of the CA and its certifcates; the RP does not trust the CA directly but trusts this trust broker. Te trust broker provides three types of information to the RP: (i) Quality of Certifcate (QoCER): a score from 0 to 1 indicating the level of trust that can be placed in the certifcate (ii) Confdence level (CL): a score from 0 to 1 indicating the degree of confdence the trust broker has in the QoCER recommendation sent to the RP (iii) Usage information about the recommended or allowed uses of the certifcate  Based on the information provided by the trust broker, the RP will determine if the CA is trustworthy. In addition, the trust broker is responsible for the information provided to the RP and must respect and protect the privacy of the RP. Te trust broker must be independent of the CA. Possible organizations that operate trust brokers include the following: (i) A commercial organization whose business is to make recommendations regarding certifcates (ii) Governments wishing to promote electronic commerce in their countries (iii) An international organization such as the United Nations to facilitate international trade 2.2. Intel Software Guard Extensions. Intel SGX [10,11] is a trusted execution environment (TEE) that provides a secure execution environment in hardware. Intel SGX creates a cryptographically protected area called an Enclave and executes programs within the Enclave to protect data and execute programs securely. A function called "sealing" encrypts sensitive data within the Enclave, allowing it to be stored outside the Enclave in encrypted form. A function called "unsealing" can then decrypt the encrypted data within the Enclave. Terefore, sensitive data can be protected even outside the Enclave because it is encrypted rather than simply plain text when outside the Enclave.
Tere is a study [12] that uses Intel SGX to generate keys and certifcates. Tis study seeks to improve the security of key generation and key distribution. Te keys are securely generated and encrypted in the secure environment of Intel SGX. Te encrypted key is then distributed as an optical signal for secure key distribution. [13], which is a DLTframework, is a Hyperledger project [14]. Hyperledger Fabric consists of two types of nodes: peer and orderer. A peer has a distributed ledger, communicates the execution of smart contracts, and updates data in the ledger to the orderer as transactions. Te orderer sequences the transactions it receives from the peer and distributes the blocks generated from the transactions to all peers. Te Fabric network consists only of authenticated nodes, which join the Fabric network using certifcates issued by a dedicated private certifcation authority. Smart contract installation is based on the permission of each node participating in the Fabric network. Terefore, no particular administrator can arbitrarily decide which smart contracts to install, and only those smart contracts that are agreed upon by all nodes are installed.

Hyperledger Fabric. Hyperledger Fabric
Two types of commands are used to invoke smart contracts: invoke, which generates a transaction, and query, which does not generate a transaction. Te invoke command can update data in the ledger by generating a transaction, but time is required for all nodes to synchronize their ledgers. Because the query command does not generate a transaction, it can only perform read operations that do not require updating the data in the ledger, thereby eliminating the need for synchronization time.
When a client invokes a smart contract via invoke, the following processes are performed. First, the client requests the creation of a transaction from multiple peers. Upon receiving the request, the peers execute the smart contract and return the result as a transaction to the client. After receiving transactions from all peers, the client sends the transaction to the orderer, which orders the transactions, generates the blocks, and sends the blocks to all peers. Peers verify each transaction in the block, and if no problems are identifed, the transaction is refected in the ledger.
In a DLT, each peer signs a transaction to prove that it has executed it. Te key for signing is generated and managed by each peer. In Hyperledger Fabric, each organization can have a CA, and when a node joins the DLT, each CA generates a certifcate for that node. When a node joins the DLT, each CA generates a certifcate for that node, which is then used to verify the signatures in the blocks. If the keys used for signatures are compromised, there is a possibility of identity theft, so measures to prevent key compromise are considered. Some of the proposed key compromise countermeasures include the use of multisignature [15], the generation of secret keys from biometric information [16], and the use of hardware security module (HSM) [17].

Private Chaincode. Hyperledger FPC [6]
is a mechanism to run Hyperledger Fabric on Intel SGX. Te FPC allows and protects the execution of distributed ledgers and smart contracts, which are key-value type databases. Te FPC is designed based on [18].
In FPC, the content of a peer can be protected by Intel SGX. Because the smart contract is executed within Enclave, no one can know the details of the smart contract execution and it can be executed securely. Data to be stored in the ledger are encrypted within Enclave and stored in the ledger in an encrypted state. When data are retrieved from the ledger, the data are retrieved in its encrypted state and decrypted in Enclave. At this time, the key for decryption exists only in Enclave. In addition, communication between nodes is protected by secure sockets layer (SSL) communication using a certifcate issued at the time of registration.
In a blockchain such as Fabric, a peer executes the smart contract, and the peer can know the execution details of the smart contract. Terefore, utilizing highly private data is unsuitable in blockchains. However, the execution of smart contracts using Intel SGX, such as FPC, can be useful when leveraging highly private data.
A possible use case for FPC is to train a model for detecting brain abnormalities as a convolutional neural network (CNN) [19]. To obtain a highly accurate model, data owned by a single entity are insufcient; more data are required. Terefore, collecting data from many entities is desirable, but regulations under the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act of 1996 (HIPAA) make sharing CT scans and MRI images of the brain difcult. In such cases, Security and Communication Networks FPC can be used to protect privacy while sharing information.

Concepts of Consortium CA and Design Policy
In this section, we introduce the concept of a consortium CA and defne the design policies of a distributed public key certifcate-issuing infrastructure for a consortium CA. Figure 4 shows the concepts of a consortium CA. Concept 1 is that the consortium CA should be operated by multiple organizations. Organizations participating in the consortium should have equal rights to use the consortium CA and not be restricted in their use by any particular organization. Concept 2 is that the transparency of certifcate issuance should be guaranteed. To operate the consortium CA securely, all organizations should enable early detection of unauthorized certifcates. Concept 3 is that the transparency of certifcate validation should be guaranteed. No organization within the consortium should interfere with the RP's certifcate validation. A naive approach for cooperative operation among multiple organizations is to share the private key of the CA to an administrator of each organization, and issue public key certifcates under the responsibility of each administrator. However, this approach is impractical because it requires trusting each administrator, and a malicious administrator can issue unauthorized public key certifcates in secret using the private key illegally. For multiple organizations to cooperate in operating a distributed public key certifcate-issuing infrastructure, public key certifcates must be issued only when necessary at the administrators' discretion while preventing unauthorized issuance of certifcates by administrators. Terefore, we defne four requirements for the proposed infrastructure.
(1) Req. 1: public key certifcates are issued without depending on a specifc organization (2) Req. 2: all public key certifcates issued must be recorded (3) Req. 3: the issuance of a public key certifcate cannot be erased (4) Req. 4: relying parties can confrm that a public key certifcate has been issued Req. 1 comes from Concept 1, Reqs. 2 and 3 come from Concept 2, and Req. 4 comes from Concept 3. Req. 1 prevents an administrator from arbitrarily issuing certifcates. Tis requirement prohibits the delegation of the management of CA's private key to a specifc administrator. Req. 2 guarantees the transparency of certifcate issuance. Tis requirement provides accountability around certifcate issuance and enables administrators to detect unauthorized certifcates. Req. 3 also guarantees the transparency of certifcate issuance. Tis requirement reinforces Req. 2 in terms of the permanence of the record. Req. 4 guarantees the transparency of certifcate verifcation. Tis requirement allows RPs to check public key certifcates without inhibition by any organizations.
We approach these requirements using smart contracts and distributed ledgers with DLT, that is, our approach is to design the logic of certifcate issuance with smart contracts and the record of public key certifcates with distributed ledgers. Because smart contracts allows transactions to be executed without a third party because the processing logic is predetermined, a public key certifcate can be issued based on the logic agreed upon by all participants. Tis feature satisfes Req. 1. Although the logic may be shared, public key certifcates may be issued independently of smart contracts if the private key can be used outside of smart contracts. In this case, such certifcates are not recorded in distributed ledgers.

Org1
Org3 Org2 Org4 Org5 Terefore, we limit the use of the private key within smart contracts. In this study, we refer making a specifc private key used to sign public key certifcates available only for a specifc smart contract as "enclosing private keys." We approach Req. 2 with this idea. From Reqs. 1 and 2, distributed ledgers ensure that a record of issued public key certifcates is maintained in a manner that cannot be tampered. Consequently, this is expected to conform with Req. 3. Based on the design, public key certifcates can be managed in distributed ledgers and placed under the control of the smart contract. Te transparency of the issuance and management of public key certifcates in the consortium CA is guaranteed. From this approach, we determine how to employ permissioned DLT as the proposed infrastructure. Tere are two reasons for this determination. First, designing an infrastructure that can be operated only among the identifed organizations is possible. Because the CA functions are implemented using smart contracts, limiting entities that can use the functions is necessary. Permissionless DLT allows an unspecifed number of entities to use smart contract. Second, permissionless DLT does not provide transaction fnality. Te lack of fnality causes a potential risk of revoking an issued public key certifcate. In permissioned DLT, transactions can be fnalized by agreement among the participants. For these reasons, realizing the proposed infrastructure is desirable using permissioned DLT.

RP CH
Finally, from the decision to use permissioned DLT, Req. 4 is derived. Te decision to use permissioned DLT reduces the transparency of certifcate verifcation. Because DLT system participants can only execute smart contracts, verifcation transparency is also required against a relying party, which is not a participant in the DLT system. Tis study incorporates the idea that the RP directly verifes the certifcate verifcation results produced by the smart contract. Tis idea allows RPs to verify certifcates without interfering with the organizations.
In this study, we design a distributed public key certifcate-issuing infrastructure that satisfes the four requirements using Hyperledger Fabric, which is a permissioned DLT framework. Furthermore, we enclose private keys using FPC. Te CA's private keys are securely used in smart contracts' Enclave.

Design of a Distributed Public Key
Certificate-Issuing Infrastructure 4.1. Overview. Figure 5 shows the structure of the proposed infrastructure. Te functionality of a CA is implemented by smart contracts on the FPC network and multiple organizations corresponding to RAs manage peers, which form the FPC network. Each RA can use CA functions by executing smart contracts through peers. In the FPC network, the ledgers held by each peer are synchronized, and the same information is written in all ledgers. Each organization runs a peer on an Intel SGX-enabled device. Tis ensures that the processing content and input/output of the smart contracts executed by peers, as well as the input/output to the ledgers, are maintained secretly. Te entities that comprise the distributed public key certifcate-issuing infrastructure are as follows.
(1) Certifcate holder (CH): A certifcate holder is an entity that requests a certifcate issuance to the proposed infrastructure. that reads and writes data on a distributed ledger in DLT. In the distributed public key certifcateissuing infrastructure, it realizes the function of a CA. (6) Data store (DS): A data store is a ledger for storing data. In a distributed public key certifcate-issuing infrastructure, the ledger is protected by Intel SGX and stores the private keys used for issuance and public key certifcates issued.

Data Structure.
Te distributed ledger stores the CA's private key, public key certifcates issued by the distributed public key certifcate-issuing infrastructure, and revoked public key certifcate information. Table 2 presents the structure of the data stored in the distributed ledger.
Te distributed ledger holds two types of private keys sk CA and sk Audit . Te former is a private key for signing public key certifcates, and the latter is a private key for guaranteeing verifcation results. In addition, a public key certifcate corresponding to each private key is also stored. Tese data are stored using pointers, which is the string concatenated string "CA" and hash values of a public key pk CA corresponding to sk CA , as a key.
Because the hash value of pk CA is unique, a diferent key is generated for each key encapsulation, allowing multiple private keys to be stored. To identify which of the multiple private keys will be used to sign public key certifcates, the pointer of the valid private key is stored with string "val-idKey" as a key.
Ten, the counter value of the serial number assigned to the public key certifcate is stored with string "Serial-Number" as a key, and the issued public key certifcate is stored with its serial number as a key.
Revoked public key certifcates are stored with the serial number, revocation date and time, and reason codes of the revoked public key certifcate as the key "CRL." Finally, the issuer's information and maximum validity period of the public key certifcate are stored with string "Confg" as the key.

Transaction.
Te distributed public key certifcateissuing infrastructure has four transactions: setup, certifcate issuance, certifcate verifcation, and certifcate revocation. Te variables of the proposed infrastructure are listed in Table 3. Figure 6 shows the sequence of the setup. Te setup prepares for the issuance of public key certifcates in the distributed public key certifcate-issuing infrastructure after the FPC network is activated. First, the necessary information for certifcate issuance, such as issuer information and maximum validity period, is set by executing setConfg (Step 1). In setConfg, the issuer information and maximum expiration date are stored (Steps 2-3). Ten, two key pairs are generated. sk CA is used for certifcate issuance, and sk Audit is used during the certifcate verifcation process (Step 4). Ten, the generated key pair is enclosed in a distributed ledger by executing encloseKeys (Steps 5-7). Finally, the IM deletes the generated keys (Step 8). Figure 7 shows the sequence of certifcate issuance. In a certifcate issuance transaction, a public key certifcate is issued to a CH. First, a CH creates a CSR and sends it to a CI, which requests for certifcate issuance (Steps 1-2). Ten, the CI executes issueCert to issue the certifcate and returns it to the CH (Steps 3-6). Figure 8 shows the sequence of certifcate verifcation. In a certifcate verifcation transaction, a CV checks the validity of the CH's certifcate cert CH ′ . First, the CV sends cert CH ′ and a random number r1 to a CI to check whether the public key certifcate cert ′ CH to be verifed is registered in the distributed public key certifcate-issuing infrastructure (Step 1). Te CI executes checkCert with cert CH ′ and the random number r1 as Private key sk Audit Serial number of cert Audit "validKey" "CA." + hash (pk CA ) "SerialNumber"

Certifcate Verifcation.
Serial number counter value Serial number of a public key certifcate Public key certifcate "CRL" List of a serial number of revoked public key certifcate, revocation date, and reason code "Confg" Issuer information Maximum expiry date arguments and checks whether cert CH ′ is a certifcate stored in the ledger (Steps 2-3). If it can be confrmed, the SC signs r1 with sk Audit and returns cert Audit and sig r1 (Steps 3-4), and the CI sends them to the CV (Step 5). If not stored in the ledger, cert CH ′ is not a public key certifcate issued by the distributed public key certifcate-issuing infrastructure, and the CV is notifed of this. Finally, the CV performs the verifcation (Step 6). In verifcation, after verifying cert Audit

Step3 OK
Step2 setConfig Step6 encloseKeys  Security and Communication Networks using cert CA , sig r1 can be verifed using cert Audit to confrm that it has been processed by the SC execution. Ten, cert CH ′ is verifed using cert CA . It is noted that cert CA is assumed to be known in advance. Figure 9 shows the sequence of certifcate revocation. Te certifcate revocation transaction revokes a public key certifcate. First, a CH makes a revocation request and sends the serial number of the public key certifcate to be revoked to a CI (Step 1). Te CI executes getCert and retrieves the public key certifcate with its serial number as a key (Steps 2-4). Ten, identifcation is required to confrm that the retrieved public key certifcate belongs to the CH. To verify the identity, the CI requests the CH to sign a random number r2. Te CI sends a random number r2 to the CH, and the CH generates a signature sig r2 for r2 using their private key (Steps 5-8). Te CI verifes sig r2 with cert CH (Step 9). If sig r2 is verifed, the public key in cert CH corresponds to CH's private key, which confrms that cert CH belongs to the CH. Ten, the public key certifcate is revoked by executing revokeCert with the serial number of cert CH , revocation date and time, and reason code as arguments (Steps 10-13).

Smart Contract Implementation
Six SCs are implemented, and the FPC's SCs can be developed using C++. Te OpenSSL library is used to create and sign public key certifcates. Table 4 provides the functions used in the proposed infrastructure.

setConfg.
Algorithm 1 provides the pseudocode of setConfg. In setConfg, the putState function stores the issuer information and the maximum validity period with string "Confg" as a key.

encloseKeys.
Algorithm 2 provides the pseudocode of encloseKeys. encloseKeys takes key information and an expiration date as arguments. First, in line 16, the serial number and confguration information are obtained by the getState function to obtain the information necessary to generate a public key certifcate. Two public key certifcates are generated: cert CA with pk CA as the public key and cert Audit with pk Audit as the public key. In line 3, a public key certifcate is generated, and the issuer information, subject information, serial number, and expiration date are set as the certifcate information. Ten, the public key certifcate is signed with sk CA . Ten, in line 22, a hash value of pk CA is calculated, and the key information is stored in a ledger with string "CA.hash (pk CA )" as a key. String "CA.hash (pk CA )" is also stored with string "validKey" as a key, and the serial number is incremented.

issueCert.
Algorithm 3 provides the pseudocode of issueCert. issueCert takes the CSR and expiration date as arguments. First, to obtain the information necessary to generate a public key certifcate, the serial number, confguration information, and string "CA.hash (pk CA )" are obtained using the getState function, and key information is obtained using string "CA.hash (pk CA )" as a key. Ten, from line 5, a public key certifcate is generated. Te certifcate version is set to "3" to use the extended part of the public key certifcate. In addition to setting the issuer information, subject information, serial number, and expiration date as certifcate information, string "CA.hash (pk CA )" is inserted into the Authority Key Identifer area of the extended part of the public key certifcate. Tis allows for the identifcation of which key signed the public key certifcate during verifcation. In line 16, the public key certifcate can then be signed with sk CA , and a public key certifcate can be generated. Finally, the generated public key certifcate is stored in the ledger, and the serial number is incremented using the putState function.

checkCert.
Algorithm 4provides the pseudocode of checkCert. checkCert frst retrieves the serial number from the public key certifcate cert CH ′ using the getState function. From the serial number, it retrieves the public key certifcate cert stored in the ledger and compares cert CH ′ with the cert. Tis comparison determines whether cert CH ′ is a public key certifcate stored in the ledger. In line 6, the getState function obtains the CRL and checks the revocation status of cert CH ′ . Ten, the certifcate is signed to guarantee that it has been processed by SC execution. In line 15, to identify the key that issued cert CH ′ , the extension from cert CH ′ is extracted. Te extension contains CA.hash (pk CA ), which can be used as a key to retrieve the key information. After extracting the key information, sign r1 with sk Audit and generate sig r1 . Ten, cert Audit , which is necessary for verifying sig r1 , is extracted and output.

getCert.
Algorithm 5 provides the pseudocode of get-Cert. In getCert, the public key certifcate is retrieved from the serial number using the getState function. 5.6. revokeCert. Algorithm 6 provides the pseudocode of revokeCert. In revokeCert, the CRL stored in the ledger is retrieved. Ten, sn, rd, and rc are added to the CRL, and the updated CRL is stored with string "CRL" as a key.

Security Analysis
In Section 6.1, we evaluate whether the proposed infrastructure satisfes the four requirements indicated in the design policy. In Section 6.2, we establish the threat model and we perform the security analysis based on the threat model in Section 6.3.

Evaluation of Meeting Requirements
6.1.1. Evaluation for Req. 1. Because a public key certifcate is signed with a private key to guarantee the issuing entity, a CA is required to strictly manage the private key. For multiple organizations to cooperate in operating the proposed infrastructure, CIs must be able to use the CA's private key, but simply sharing the private key increases the risk of private key leaks and unauthorized use.

Evaluation for Req. 2.
Each organization cooperates to maintain the proposed infrastructure; ans simultaneously plays a role in monitoring the other organizations to ensure that no fraudulent public key certifcates are issued. Because the public key certifcate creation process is defned by the SC, a certain level of security is guaranteed, such as prohibiting the use of weak cryptographic algorithms. However, being able to evaluate items that cannot be evaluated uniformly, such as the eligibility of the subject of issuance and validity of the expiration date, using public key certifcates that have actually been issued is desirable.
In the proposed infrastructure, the SC must be performed to issue a public key certifcate. Te certifcate issuance process is realized as a single transaction of issuance and recording, with public key certifcates being stored in the distributed ledger at the same time they are created. Tis ensures that all public key certifcates issued are recorded in the distributed ledgers. By managing the public key certificates in the distributed ledgers, the public key certifcates issued are shared by all organizations. Meanwhile, the proposed infrastructure requires the infrastructure manager to enclose the private keys in the distributed ledgers. Te IM must confrm that the enclosed private keys have been securely deleted, as shown in Figure 6. If the private keys are not deleted, the IM can create public key certifcates in secret. However, public key certifcates created without executing an SC are not recorded in the distributed ledgers; thus, only public key certifcates that have been legitimately issued are recorded. Te certifcate verifcation sequence also checks whether a public key certifcate is registered in the Input: cert' CH , r1 Output: sig, cert Audit (1) //Retrieve a certifcate using cert' CH serial number (2) cert ← getState (cert' CH .sn) (3) ifcert and cert' CH are not matched then (4) return Error ("Cert is invalid") (5) end if (6) crl ← getState ("crl") (7) i ← 0 (8) //Confrm revocation status (9) whilecert.sn ! � crl [i].sn do (10) i ← i + 1 (11) end while (12) ifcert is revoked then (13) return Error ("Cert is revoked") (14) end if (15) 3. If the issuance of a public key certifcate can be erased, inconvenient issuance facts can be erased later. Because the issuance of a public key certifcate is recorded as the storage of the public key certifcate in distributed ledgers, the erasure of the issuance of a public key certifcate means the erasure of the public key certifcate stored in the distributed ledgers.
In relation to Req. 2, even if the public key certifcates issued are recorded in the distributed ledgers without omission, fraudulent public key certifcates cannot be detected if the records are being tampered with or deleted. Te public key certifcates stored in a distributed ledger cannot be deleted based on the distributed ledger's tamper resistance, which is generally provided by DLT. In addition, the proposed infrastructure, no SC can delete public key certifcates recorded in the distributed ledgers, and the public key certifcates cannot be deleted by abusing legitimate SCs. Even if SCs cannot delete public key certifcates, issuance of public key certifcates cannot be confrmed if they are no longer recognized by the proposed infrastructure. Terefore, public key certifcates issued are stored with their hash value as a key to ensure that they are stored uniquely without being overwritten. In this manner, the proposed infrastructure satisfes Req. 3. Req. 4. Te verifcation of public key certifcates involves checking that the public key certifcate is signed with sk CA and that the public key certifcate is recorded in the distributed ledgers. As shown in Figure 5, the existence of this record is verifed by a CI who has the authority to execute the SC. Tere is a risk concerning the CI returning incorrect results because the CI can replace the verifcation results.

Evaluation for
Te proposed infrastructure uses sk Audit to sign the verifcation results in addition to sk CA to sign public key certifcates. Te SC that performs the verifcation process signs the verifcation results with sk Audit enclosed in the distributed ledgers. Terefore, the verifcation results are guaranteed to originate from the SC. Te CV can verify the existence of public key certifcates without unauthorized intervention by the CI. In this manner, the proposed infrastructure satisfes Req. 4.

Treat Models.
Since the proposed infrastructure allows CIs to issue certifcates, we conduct threat modeling by assuming a CI to be a malicious entity. Te attacker's goal is to create a fraudulent certifcate that will pass authentication checks. From the modeling assumption, the attacker has the capability of a CI. Terefore, the attacker is able to propose deploying smart contracts, agree upon processing of smart contracts, and execute smart contracts. According to the attacker's capability, there can be two types of attacks: deploying a smart contract with incorrect process injected and intervening in the verifcation process. In the former type, the attacker proposes a smart contract including the function that is advantageous in attacking. In this paper, we analyze the possibility of a smart contract that can issue a CA certifcate. In the latter type, the attacker illegally intervenes in the verifcation process to avoid detection of invalid certifcates. If the attacker obtains sk CA , the attacker can generate invalid certifcates using it. In this type of attack, the attacker needs to spoof that the invalid certifcates are recorded on the distributed ledger.

Security Analysis Based on Treat Models.
For the attack of issuing a CA certifcate, if the attacker can generate a CA certifcate by issueCert, the attacker uses a private key of that CA certifcate and can issue certifcates with that CA certifcate as their parent. In this case, the CA certifcate issued by the attacker is an intermediate certifcate for the root CA certifcate stored in the distributed ledger. Tis attack is detectable from two points of view: installation of smart contracts at each CI and verifcation of certifcates. For the frst point, the attacker proposes a smart contract, which includes the function issuing a CA certifcate to all CIs, and all CIs have to install that smart contract. Since CA certifcates are also a type of public key certifcate [20], they can essentially be generated in the proposed infrastructure. However, the diference can be determined by the usage of certifcates expressed in the extension area of certifcates (e.g., Basic Constraints and Key Usage). Each CI is required to understand these diferences and decide whether or not to install smart contracts. Although the specifc scheme is the future work of this study, it is necessary to establish a policy to determine whether or not to install smart contracts and a system that allows all CIs to check the policy mechanically. For the second point, although the intermediate certifcate generated by the attacker is recorded in the distributed ledger, subordinate certifcates of that intermediate certifcate are not recorded in the distributed ledger. Terefore, invalid certifcates can be detected by checkCert.
For the attack of spoofng certifcate issuance records on the distributed ledger, the attacker attempts to spoof that certifcates are recorded in the distributed ledger on the certifcate verifcation sequence. Since this attack falsifes certifcates created without using issueCert as legitimate certifcates, it is expected to be used in conjunction with the attack of issuing an intermediate CA certifcate. In this attack, the attacker attempts to manipulate the checkCert results either by altering the checkCert results or by falsifying the records of the distributed ledger. Te checkCert results are guaranteed by Req. 4, as shown in Section 6.1.4. In addition, it is not possible to spoof certifcate issuance records in the distributed ledger since the attacker cannot inject invalid records into the distributed ledger by Req. 2 and Req. 3. If the attacker can obtain sk Audit , the attacker can generate the proof without checkCert. However, the attackable period is very short since sk Audit is deleted by the IM at Step 8 in the setup sequence.

Experiment's Summary.
We evaluated the basic performance of the proposed infrastructure. Our evaluation aims to analyze the proposed infrastructure from the following three perspectives: (i) Te trend in the time required for the certifcate issuance (ii) Te trend in the time required for the certifcate verifcation (iii) Te trend in the time required for the certifcate revocation In the experiments, we executed the proposed SCs in the order shown in Figure 10. After setting up the proposed infrastructure with setConfg and encloseKeys, we repeatedly issued, verifed, and revoked certifcates 100 times with issueCert, checkCert, getCert, and revokeCert. Within each trial, we measured the execution time for each SC.
To conduct the experimental evaluation, we implemented the system shown in Figure 11. Two peers and one orderer were created as containers, and an FPC network was constructed with them. Our proposed SCs were executed on the FPC network, and its processing time was measured. Te measurement was performed with SGX in simulation mode. Table 5, and time to update the status of all ledgers is shown in Table 6. IssueCert and revokeCert write data to the ledger. Terefore, an operation to update the status of all ledgers is necessary to synchronize the ledgers. Looking at the frst execution time, setConfg, getCert, and revokeCert required less than 1 ms, whereas encloseKeys, issueCert, and checkCert required several ms. setConfg and getCert have short execution time due to their small amount of processing.

Evaluation Results. Te execution times are shown in
First, we describe the evaluation results of the certifcate issuance where issueCert is used. From Figure 12, issueCert has the longest execution time, and it is within a range of approximately 3.9 to 4.2 ms. As shown in Algorithm 3, since issueCert only uses the input data to create a certifcate, the execution time is considered to be constant and consistent with the evaluation results. From Table 6, the time to update the status of all ledgers for issueCert is also in the range of 0.91 to 0.98 ms. From the implementation of the algorithm and the experimental results, we confrmed that the proposed infrastructure tends to be able to issue certifcates stably.
Ten, we describe the evaluation results of the certifcate verifcation where checkCert is used. From Figure 12, the execution time for checkCert is within a range of approximately 2.9 to 3.4 ms. As shown in Algorithm 4, since checkCert performs a linear search of the CRL to check that the certifcate has not been revoked, the execution time is considered to increase linearly. However, our evaluation results showed no clear increase in execution time for as few as 100 CRLs. Once a revoked certifcate is listed on CRLs, it is removed from the CRLs when the certifcate expires. In other words, the number of CRLs does not continue to increase monotonically, and there is basically an upper limit to the number of CRLs. Te upper limit depends on the application to which the consortium CA is applied, but we confrmed that about 100 CRLs have no signifcant efect on the performance change.
Finally, we describe the evaluation results of the certifcate revocation where getCert and revokeCert are used. From Figure 12, the execution time for getCert shows little change, ranging from about 0.5 to 0.6 ms. As shown in Table 2, certifcates are stored with its serial numbers as keys, and certifcates can be retrieved from the ledger by simply inputting the key as shown in Algorithm 5. As a result, the processing cost of getCert is constant and small. On the other hand, the execution time for revokeCert increased from 0.7 to 2.2 ms. In revoke-Cert, the inputting certifcate is added to the CRLs; hence, it takes the execution time to read and write the CRLs. Te number of CRLs increases monotonically in this experiment. Tus, the size of data to be read and written has increased, and the processing time seems to have increased accordingly. However, the execution time is smaller than that of checkCert, which will be executed more frequently, and the number of CRLs is expected to be capped, so performance is not expected to be signifcantly impacted. From Table 6, in addition, the time to update the status of all ledgers for revokeCert is in the range of 0.67 to 0.75 ms. Compared to the time to update the status of all ledgers for issueCert, the time for revo-keCert is smaller. Tis suggests that the amount of data written to the ledger is related to the time to update the status of all ledgers. Terefore, the time for revokeCert did not show an obvious increase in time, although the amount of data to be written would increase as the number of executions increased.  Table 7 shows a comparison of the proposed infrastructure and related studies combining CA-based PKI and blockchain. We reviewed the basic characteristics of them and analyzed them with regard to the fulfllment of the proposed requirements. Te basic characteristics of Table 7 are listed below.

Related Work
(i) Permission type: this indicates whether the study employs permissioned or permissionless blockchain (ii) Blockchain type: this indicates a type of blockchain systems used in the study (iii) Private key location: this indicates where the private key used for the certifcate is stored (iv) Certifcate generation: this indicates which entity generates the certifcate (v) Certifcate verifcation: this indicates whether the certifcate verifcation process is performed locally or using the SC (vi) Certifcate revocation: this indicates how certifcate revocation is performed (vii) Registration confrmation: this indicates whether a process is used to confrm that the certifcate is recorded on the blockchain Our objective is to propose a consortium CA that can be cooperatively operated by multiple organizations. In contrast, most of the related studies proposing blockchain-based PKI have the objective of resolving the single point of trust of the CA and making the PKI more secure or improving the system for that purpose. Although the diferences in the purpose make a complete comparison difcult, we analyzed whether the related studies meet the following four requirements defned in this paper and compared the differences among the related studies.
(i) Req. 1: this indicates whether "Public key certifcates are issued without depending on a specifc organization." is satisfed (ii) Req. 2: this indicates whether "All public key certifcates issued must be recorded." is satisfed (iii) Req. 3: this indicates whether "Te issuance of a public key certifcate cannot be erased." is satisfed (iv) Req. 4: this indicates whether "Relying parties can confrm that a public key certifcate has been issued." is satisfed Te results of the analysis show that the related studies can be divided into fve categories from the perspective of the requirements, as shown in Table 7. Te frst is a category that satisfes none of the requirements. Tis category includes those that apply blockchain technology for purposes other than certifcate issuance (e.g., sharing revocation information or CA policies). Lei et al. [21] propose an efcient certifcate revocation scheme in vehicle communication systems (VCS). Ahmed and Aura [22] propose a SC-assisted public key infrastructure (SCP) to manage certifcate trust statuses. CAs and domain owners register and publish their certifcate policies on the blockchain such that each participant can verify the trust status of certifcates. IKP [23] incentivizes CAs to act ethically and report fraud, thereby discouraging abusive behavior. Elloh Adja et al. [24] propose     a new certifcate revocation method and status verifcation scheme. It stores certifcate revocation information in a public blockchain and provides a mechanism like a CRL distribution point. Te second is a category that satisfes only Req. 3. Te studies in this category tend to utilize the blockchain's tamper-resistance capabilities to ensure the accountability of PKI for specifc peers authorized to participate in the blockchain system. Certchain [25] involves an auditing scheme using blockchain for secure SSL communications. It records, publishes, and audits certifcate operations such as certifcate registrations, renewals, and revocation on the blockchain. BlockCAM [26] proposes a cross-domain authentication model using blockchain. Te CA becomes a node on the blockchain, and the CA registers its issued certifcates on the blockchain. Boyen et al. [27] propose DPKIT, which eliminates the CA as a single point of failure and ensures transparency in certifcate issuance and revocation. Although DPKIT employs permissionless blockchain, auditing requires the cooperation of a dedicated node called DPKIT peer.
Te third is a category that satisfes Reqs. 3 and 4. Te studies in this category tend to utilize the blockchain technology for ensuring the accountability of PKI for even entities that do not participate in the blockchain system. However, certifcates registered in the blockchain are still under the control of a CA, and there is a possibility of omission of certifcate registration or registration of fraudulent certifcates. CBPKI [28] involves a blockchainbased cloud-based PKI. It aims to leverage the security measures of cloud platforms by ofoading certifcation authority to the cloud. Wang et al. [29] propose a certifcate and revocation transparency system to prevent impersonation attacks using fraudulent certifcates. Hwang et al. [30] solve the PKI problem using public blockchains that cannot handle numerous certifcates using TP-Merkle trees. Kubilay et al. [31] propose a new PKI model with blockchain-based certifcate transparency, CertLedger. CertLedger manages the states of all certifcates and their revocation status and the set of the trusted CA certifcates in blockchain.
Te fourth is a category that satisfes Reqs. 3 and 4 and partially satisfes Req. 2. Te studies in this category include an additional mechanism to prevent the registration of fraudulent certifcates for the third category. Terefore, Req. 2 is partially satisfed. Yakubov et al. [32] propose a blockchain-based PKI management framework for managing certifcates. Each CA has a dedicated SC, which allows it to register and revoke certifcates. Rashid et al. [33] propose a blockchain-based mechanism for the issuance and management of transparent and secure digital certifcates that can prevent CA abuse. Te proposed system can solve attacks like Sybil attack, Spoofng attack, and MITM attack.
Te ffth is a category that satisfes Reqs. 2, 3, and 4. Te studies in this category have an additional mechanism to enforce that all of the certifcates are recorded in blockchain for the fourth category. Specifcally, the recording process is integrated into the issuing process. Saleem et al. [34] propose a decentralized PKI framework, ProofChain, to improve security. Blockchain miners act as CAs and issue certifcates by storing them in the blockchain after each CA signs them. Dykcik et al. propose BlockPKI [35] to reduce the power of individual CAs and to make their actions publicly visible and accountable. A domain owner publishes a request on the blockchain for the issuance of a certifcate along with the expected set of CAs. Ten, each of the designated CAs performs domain validation and publishes a certifcate with multisignature on the blockchain. Li et al. [36] propose a possible solution with new blockchain technology to solve problems like single-point attacks and man-in-the-middle attacks. Tere is no CA as a third party, and the verifer acts as a CA. When a user registers credential information with the blockchain, the verifer issues the user a certifcate for its own server, which is stored in the blockchain. Te user can then retrieve the certifcate from the blockchain.
In addition to CA-based PKI, a blockchain-based Web of Trust PKI has also been proposed. WoT-based PKI guarantees an identity of a public key without relying on a single point of trust such as a CA. BCTrust [37] proposes a secure communication protocol in wireless sensor networks (WSN). Web of Trust does not use certifcates, but authenticates messages by recording them on a blockchain. BlockPGP [38] proposes a blockchain-based framework that manages pretty good privacy (PGP) certifcates and keyserver infrastructure with high trust. Certifcate holders can register and revoke PGP certifcates on the blockchain and sign the certifcates of others. Blockstack [39] is a blockchain-based naming and storage system . It associates public keys, data, and usernames in a similar manner as PGP using blockchain. DPKI [40] proposes a PKI solution to address attacks coming from a single point of failure in the Industrial Internet of Tings (IIoT). DPKI uses a permissioned blockchain, where the participants are all devices in the IIoT network. SCPKI [41] is an alternative PKI system based on a decentralized and transparent design using the Web-of-Trust model and smart contracts on the Ethereum blockchain. Each entity stores its identity in the blockchain, and its authenticity is guaranteed by signatures of other entities. Te blockchain stores identities and public keys, and each participant signs these data. Fromknecht et al. propose Certcoin [42], which ensures the association of public keys and identities with a public ledger. Ten, Patsonakis et al. [43] improve Certcoin in terms of data size and implement their proposed system in [44]. Qin et al. propose Cecoin [45], which resolves a single point of failure of PKI by recording certifcates as currencies to the Bitcoin system. Cecoin has the identity assignment to support delegation of certifcate ownership.
Te proposed infrastructure is classifed into a new category, which satisfes all of the requirements. One major diference from existing research is the capability of storing private keys in a distributed ledger by applying Intel SGX. In most existing studies, a private key of a CA is stored in a CA's local storage. Tis capability allows the SC to use the private key for generating and confrming certifcates.
According to our analysis, none of the existing studies satisfy Req. 1. In the consortium CA, it is important to be able to use a private key cooperatively among CAs participating in the consortium and to prevent fraud by a specifc CA. Te proposed infrastructure satisfes Req. 1 by employing blockchain technology and Intel SGX. As a different approach from our proposal, there are some studies that utilize multisignature (e.g., [34,35]). However, we conclude that they do not satisfy Req. 1 because a CA that creates a multisignature may be able to deny a request based on a CSR.

Conclusions
In this paper, we defne four requirements of a consortium CA and propose a distributed public key certifcate-issuing infrastructure that can be cooperatively operated by multiple organizations. To achieve cooperative operation, the proposed infrastructure encloses CA's private keys in a distributed ledger and enforces the usage of them. We design the proposed infrastructure to meet four requirements and evaluate the fulfllment of those requirements.
In addition, we measured the basic performance of the proposed infrastructure: issuing, verifying, and revoking public key certifcates. Trough the experimental evaluation, we confrm that the proposed infrastructure can work stably. Te proposed infrastructure can issue public key certifcates with a processing time of approximately 4 ms and can check that public key certifcates are issued by the proposed infrastructure with a processing time of approximately 3 ms.

Data Availability
Te data used to support the fndings of this study are included within the manuscript.

Conflicts of Interest
Te authors declare that they have no conficts of interest.