A Blockchain-Based Decentralized Public Key Infrastructure for Information-Centric Networks

Abstract

How to achieve secure content distribution and accountability in information-centric networking (ICN) is a crucial problem. Subscribers need to verify whether the data came from a reliable source, rather than from a spoofing adversary. Public key cryptography was introduced to achieve a method of authentication that binds the data packet to its owner. In existing prototypes, PKIs, identity-based signatures (IBSs) and recommendation networks are the common schemes used to ensure the authenticity and availability of public keys. However, CA-based PKIs and KGC-based IBSs have been proven to be weak when it comes to resisting security attacks, with recommendation networks being too complex to deploy. In this respect, we designed a novel distributed authentication model as a secure scheme to support public key cryptography. Our model establishes a decentralized public key infrastructure by combining the smart contracts of blockchain and optimized zero-knowledge proof-verifiable presentations by utilizing the DID project, which realizes the management of public key certificates through blockchain and ensures the authenticity and availability of public keys in decentralized infrastructure. Our scheme fundamentally solves the issues of security and feasibility in existing schemes and provides a more scalable solution with respect to authenticating data sources. An experiment demonstrated that our proposal is 20% faster than the original zero knowledge proof scheme in registration.

1. Introduction

Information-centric networking (ICN) is a focus of research in the Next Generation. Internet (NGI) paradigm, which has been included in 5G standards by the International Telecommunication Union (ITU) [1]. By decoupling content identifiers and network addresses, ICN realizes high throughput and low latency data distribution. Caching, multihoming, multicast and multipathing are inherently supported by this paradigm [2]. DONA (data-oriented network architecture) [3], CCN (content-centric networking) [4], NDN (named data networking) [5], NetInf (network of information) [6] et al. are typical architectures of ICN [7]. ICN considers the security at the beginning of design. Its security model is attached directly to the data and its naming scheme, which is called intrinsic security [8]. Public key cryptosystems are a pivotal technology in making the design of ICN a reality. In the original design, PKIs [9] were the most-commonly used scheme to manage and distribute public keys. With the maturation of ICN architecture and naming design, the inadaptability of this scheme has been noticed. Considering that ICN is a highly distributed system [10], the centralized PKI model greatly limits the development and security of ICN [11,12]. Therefore, researchers have reconsidered distributed models based on identity-based cryptography (IBC) and recommendation networks. However, identity-based based signatures suffer from the inherent key escrow problem, and the recommendation mechanism can only be applied in small group scenarios, which requires a certain amount trust among group members, and cannot be extended to large-scale network application scenarios as an authentication method. The question of how to complete distributed public key distribution and authentication in ICN architecture remains unresolved [13,14]. The decentralized public key infrastructure (DPKI) based on distributed identity proposed in recent years provided a breakthrough in addressing this problem. DPKI solves the problems of security and flexibility associated with centralized PKI systems by designing an efficient and reliable decentralized public key authentication scheme, which can provide strong support for the further deployment of an ICN network.

Therefore, we designed a DPKI-based distributed authentication model for ICN by combining blockchain and verifiable presentations [15]. The public key certificates realize distributed management and verification through the smart contract and distributed ledger technology of blockchain. Meanwhile, the verifiable presentations enable users to prove their identification claims to semi-trusted consensus nodes without unnecessary undermining privacy. In this way, the consensus nodes on the blockchain can authenticate the true identity of the users applying for reliable certificate registration. Our scheme fundamentally solves the binding between public key and physical identity and realizes the distributed management of public key certificates so as to provide a complete decentralized public key infrastructure. The main contributions of this paper are as follows:

(1)

We propose a secure identification approach without revealing the privacy of users to semi-trusted nodes and define a certificate generation and management protocol to bind their true identity based on blockchain, which is a decentralized and secure alternative for public key authentication in ICN.

(2)

An optimized zero-knowledge proof scheme was designed in the verifiable presentations, which increase the efficiency and security of the verifiable presentations. We introduced the Schnorr signature and Schnorr zero-knowledge proof for verifiable presentation verification, which is compatible with efficiency and security and is easier to deploy. An aggregate signature scheme was presented to support multi-attribute rapid verification. An experiment demonstrated that our proposal is 20% faster than the original zero knowledge proof scheme in registration.

(3)

The process of secure communication was introduced and proved to be reliable. Our model registers the certificate ID in the standalone name resolution approach (SNR) system along with the network address (NA), which ensures the security of issuing certificate ID during the initial interaction.

The structure of this paper is organized as follows. In Section 2, we briefly introduce the related work of our scheme. Section 3 illustrates the system requirements and architectural model of our proposal. The design protocol for certificate generation and management is detailed in Section 4, including its working process and the related algorithms. Section 5 provides an analysis of the security of the whole scheme. The simulation results are presented and analyzed in Section 6. Finally, Section 7 offers our conclusion.

2. Related Work

In order to realize reliable asynchronous data exchange in an untrusted network environment, publishers and subscribers establish a trust model based on public key cryptography. Public key management schemes have also become the key to ensure network security, which has attracted the wide attention of researchers. Yu et al. [16] presented a centralized public key management in NDN. The certificate format, distribution and revocation were discussed and provide a starting point for the definition of a PKI. Mauri et al. [17] described an up-to-date key management method for ICN. The method is to keep a public key repository for trusted TA institutions and each consumer. After each key update, TA modifies it for all consumers. Li et al. [18] introduced a distributed authentication and authorization scheme based on identity-based cryptography (IBC) in ICN architecture. The authentication of the data source is integrated with a distributed scheme through the use of an identity-based signature. Hamdane et al. [19] proposed a hybrid scheme which combines public-key infrastructure (PKI) and hierarchical identity-based cryptography (HIBC) for CCN and NDN, which realized reliable public key management though a private key generator (PKG) and a PKI. Yu et al. [20] proposed building automatic trust network applications in ICN network architecture to protect communication security. In the proposed method, taking the recommendation result as proof, the newly added users in the groups are accepted by the existing users. Yang et al. [21] demonstrated a hierarchical public key authentication in which the namespace matches the trust delegation hierarchy. The key with a specific name issued by each layer can only sign the specified data package. When the subscribers receive the data packet, they can verify the public key from bottom to top through the hierarchical relationship until they find the root key to complete the authentication of the data packet. This authentication method is applicable to ICN architectures with hierarchical names such as NDN and CCN.

To sum up, there are three main directions to address with respect to the authenticity and availability of public keys: PKIs, identity-based signatures and the recommendation trust model. Combined with the introduction in the previous section, we provide a comparison of existing works. The limitations of the existing literature are briefly summarized in

Table 1. The limitations of the existing literature.

	Key Management	System Model	Security	Scenario
PKI	CA	Centralized	Weak (single point attack)	All
IBS	KGC	Distributed	Weak (KGC single point attack)	All
Trust network	Self-verifying	Distributed and decentralized	Weak (collusion Attacks)	Small group
DPKI	Blockchain	Distributed and decentralized	High (tamper resistant)	All

.

In addition, research on decentralized public key authentication is also in progress. The authors of [22,23,24,25,26] focus on the public and decentralized PKI system model and described a detailed scheme and the application of decentralized, PKI-based secure communication. Their designs provide the essential functions of PKIs, such as the registering, updating, revoking and verifying of the ownership of a public key. Furthermore, decentralized identifiers (DIDs) [27] and verifiable credentials [28] have become a project of primary concerned and represent a new type of identifier that enables verifiable, decentralized digital identities. Relevant research has also been conducted in the form of in-depth discussions [29,30,31]. The authors of [32,33] discussed the applicability of DIDs and VCs in ICN networks. Compared with these schemes, we hope to design a more secure, efficient and suitable DPKI scheme for ICNs. The following sections outline the proposed scheme based on these goals.

3. System Overview

In this section, we briefly introduce the design requirements and architectural model of our proposal.

3.1. Design Goals

The goal behind our model was to build a decentralized public key infrastructure (DPKI) on an ICN, which would allow for the identity and attributes to be retrieved and validated by other peers during secure data communication. The functions of DPKI systems include the granting of certificates as well as their generation and management and the updating, revocation and establishment of new and old user certificate libraries. Blockchain is used as the underlying support to provide the infrastructure with distributed reliability. In order to realize the basic DPKI model, the design is divided into three basic functions:

(1)

An input as a proof (P) for identity confirmation without CA;

(2)

A verification procedure (V) for P to grant system management (generation, update, revocation);

(3)

An output in the form of a certificate (G) for secure communication.

3.2. Adversarial Model

Based on the above design, we mainly considered three malicious adversary models:

(1)

The miner nodes are semi-trusted. They truthfully perform the contracts of the blockchain, verify the registration request and add the certificates to a distributed ledger of the blockchain after verifying the identity. However, they may reveal the user data and lead to the leakage of private data;

(2)

Malicious adversaries will try to steal the P of legitimate users to forge the identity of legitimate users in the process of certificate registration;

(3)

Malicious adversaries will try to steal the certificates or private keys of legitimate users to forge the identity of legitimate users in the process of data exchange.

In addition, our system allows for the adversary to corrupt up to t of the n consensus nodes, for t is less than the fault tolerance threshold of the consensus algorithm.

Therefore, the P and V should be carried out using the zero-knowledge proof method to protect users’ privacy and provide reliability with respect to proof of identity. Additionally, the functions of P, G and V should have the following properties (i and j are two peer user nodes in public key verification):

(1)

P_i ≠ P_j, i.e., in this sense, P should be a one-way function which should be hard to break. This prevents adversaries impersonating legal identities;

(2)

Miners on blockchain can verify a user’s identity via V and the P must not reveal any information not intended to be revealed by users;

(3)

G (i, sk_i) ≠ G (k, sk_i), i.e., k is an attacker who steals the private key sk_i of a legitimate user i. k should not be able to generate i’s certificate using sk_i without proof P_i. Otherwise, k can impersonate i;

(4)

P_i(n) ≠ P_i(n + 1), i.e., a user should be able to generate different proofs given different challenges. Meanwhile, the P should add the timestamp. This prevents adversaries from using an old proof to impersonate legal identities.

3.3. System Model

The system model for our proposal is illustrated in Figure 1. We will describe the main parts in detail.

• Issue Credentials: Steps 1 and 2 illustrate the process for issuing verifiable credentials [34,35,36]. Users submit the necessary documents to credential issuers, which creates a verifiable credential from these claims and transmits the verifiable credential to applying users. Verifiable credentials can be used to build verifiable presentations [37], which can also be cryptographically verified as proof of identity attributes.
• Certification generation and management: The verifiable presentations using derived credentials will be the proof of users for identity confirmation in certification generation and management. A decentralized architecture was developed using blockchain as a database to store metadata such as public keys, digital signatures and other attributes. Smart contracts enable users to create and manage their identities and related attributes on a blockchain network.
• Secure communication: Communication verifiers including network devices and peer users’ information interactions. Devices or peers can retrieve the active public key certificates from the immutable ledger of the blockchain. If they find the certificate, it performs the signature verification process. It should be noted that the certificate ID is obtain from the SNR in the NA lookup process. When accessing the ICN, users will register their user ID along with a certificate ID in the SNR.

In next section, the generation rules of P and V used to grant certificate management (its generation, update and revocation) will be described in detail.

4. Optimization Scheme

We introduce an authentication presentation using zero-knowledge proof to illustrate the scheme of P and V in Section 4.1. The corresponding certificate management scheme is described in Section 4.2. Verifiable presentations offer the possibility of integrating various identity attributes into certificates, which associates the certificates of individuals or organizations with their real identities. This process ensures the unforgeability of public key certificates and solves the identification dilemma via private key disclosure in an anonymous authentication scheme. The scheme of secure data exchange using DPKI is described in Section 4.2.

4.1. An Authentication Scheme Using Zero-Knowledge Proof

Zero-knowledge proof (ZKP) mechanisms [38] introduce key capabilities to express multiple verifiable credentials from multiple issuers into a single proof without revealing any unnecessary information. The W3C Model [39] represents one way of using a Camenisch–Lysyanskaya (CL) signature method [40] in verifiable presentations as zero-knowledge proof, which provides a unique feature to support issuing of an anonymous credential. The CL ZKP has been shown to increase the system overhead. Related research has considered the BBS+ [41] signature. However, BBS+ signatures do not support claims aggregation. Research on the zero-knowledge proof of verifiable presentations is ongoing. We present a practical method based on the Schnorr signature [42] and Schnorr ZKP [43] for the purpose of designing a public key certificate system. The digital signature property of a CL signature can be completed by a Schnorr signature. Meanwhile, the linear nature of the Schnorr signature can provide aggregation verification and reduce the overhead. The Schnorr ZKP can realize the zero-knowledge property of a CL signature. Our scheme realizes computational security based on the integer factoring problem and discrete logarithm problem. Compared with the existing research, our scheme is efficient, secure and easier to deploy. The process of zero-knowledge identity authentication is as follows:

First of all, our scheme is a tripartite scheme involving the issuer, user (prover) and verifier. The interactive proof process is divided into two stages: issuers issue the verifiable credential to users and the user as a prover submits the verifiable presentation derived from the verifiable credentials based on zero-knowledge proof to the verifier for the verification. It should be noted that the EC group is a trusted third-party endorsement signature that verifies the reliability of the verifiable credential certificate, and the modular group is necessary to complete a VP proof verification of the zero-knowledge proof between the user and verified nodes. We will explain the details of the tripartite process in the following description.

• Issuer:

The issuer publishes the system parameters as a trusted third party and uses the private key to sign the parameter v which ensures that the subsequent verifiers can verify the authenticity of the zero-knowledge proof parameters v through an asymmetric signature. The steps of the issuing process are as follows:

• Setting up the system parameters: choosing large prime p, q, g and p − 1 = 0 mod q. A cyclic group G⊂ Z_p* of prime order q is chosen, in which it is assumed that the DLP is difficult, along with a generator g∈G. A hash function H: {0, 1}*→ G is chosen. The public parameters are pp = (p, q, g, G, H). A prime field of order p is represented by the symbol F_p. The base point of the elliptic curve F_p is Q. Asymmetric keys (SK_issuer, PK_issuer) meet the equality PK_issuer = (SK_issuer) Q;
• Generating an endorsement signature: The applicant defines a secret value s which is only shared by the issuer and the applicant. It can be chosen according to the privacy information (e.g., ID number) submitted by the applicant. Then the issuer calculates a parameter v = g^s mod p as a private authenticator with the modular group and the endorsement signature Sig1 = kQ = K, Sig2 = SIG {H (v||K||credential), SK_issuer} = k + H (v||K||credential)* SK_issuer with the EC group, where k is random, k∈Z_p*. These three parameters (v, Sig1, Sig2) are written as the proof statement in the verifiable credential with other credential metadata and the verifiable credential is sent to the credential applicant. The parameters (Sig1, Sig2) are the Schnorr signature result. V is the ZKP parameter of the hidden knowledge s. It should be noted that the issuers are a completely trusted third party (e.g., government or police bureaus), which can obtain the user’s privacy for identity authentication and will not reveal it.

• Prover:

Prover wants to prove the knowledge s, which is hidden as v = g^s mod p, to prove that the prover providing the VP proof is indeed a legal user with the correct identity, who knows the secret s and does not steal and reproduce the proof of others. The validation parameters are calculated by the prover from their verifiable credential according to the following steps:

(1)

Pick r ∈ Z_p* and compute x = g^r mod p;

(2)

Calculate e = Hash(v||K||credential);

(3)

Calculate y = r + se mod q;

(4)

Publish v, e, x, y, Sig1, Sig2 to verifier.

• Verifier:

The verifier conducts a zero-knowledge proof interaction with the prover and between the two parties. The steps of the verification process are as follows:

(1)

Check Ver {(Sig2)Q = Sig1 + Hash(v||K||credential)* PK_issuer} $\stackrel{?}{=}$ true;

(2)

Check x $\stackrel{?}{=}$ g^yv^−e mod p;

(3)

Accept if (1) and (2) are true.

Meanwhile, if the verifiable presentation is provided by multiple verifiable credentials, the aggregation nature of Schnorr can be utilized to reduce the verification overhead. For instance, a film company’s certificate verification does not only attribute their identity but also the qualification credentials, which can be regarded as a service attribute. According to Schnorr’s linear properties, verifiers can check the signature by using following calculation:

(1)

Sum {Sig1_i} = (Sig1₁)Q + (Sig1₂)Q + … + (Sig1_n)Q = {Sig1₁ + Sig1₂ + … + Sig1_n}Q;

(2)

Sum {Sig2_i} = Sum{K_i + e_i* PK_issueri} = Sum{K₁ + K₂ + … + K_n} + Sum{e₁* PK_issuer1 + e₂* PK_issuer2 + … + e_n* PK_issuern};

(3)

Check x $\stackrel{?}{=}$ g^yv^−e mod p. Provers can select the same v when applying for credentials to reduce the verification overhead.

4.2. Essential Functions

In this sub-section, we describe a detailed scheme for building a decentralized PKI. In order to provide these essential functions, transaction information upon registration, the updating of this information and the revoking of public keys are posted to the blockchain. Meanwhile, the blockchain also stores new and old user certificates in the form of a library.

• Certification generation:

The user creates a self-signed certificate that contains a certificate ID, public key, signature, proof version, certificate version, timestamp and metadata. The certificate ID is defined as a hash of the certificate content, which can be used to ensure the integrity of certificate data. Key pairs (PK, SK) and signature values are generated locally by the user. The metadata contain information needed for the security functions, such as key usage or a signature algorithm identifier. Users can also add additional information according to their own needs to increase the functions expressed by the certificate. Meanwhile, users derive a verifiable presentation from verifiable credentials in a cryptographically verifiable format as proof of identity. An example of a self-signed certificate and proof are provided in Figure 2.

When a user registers a public key certificate on the blockchain, the self-signed certificate is passed along with an identity proof for verification by miners. The verification process is described in Figure 3. Once the certificates have been verified, they will be stored on the blockchain.

• Updating and revoking:

When users update or revoke the public key certificate, a claim, in the form of a new certificate, is passed along with the identity proof for verification. Examples of updating and revoking claims are shown in Figure 4. The red elements are unique to the updating process. Miners verify the signature using the old public key (PK1) of the certificate. After the verification of the old version of the signature is complete, the verification is performed with the new public key (PK2). Then, the miners verify the proof of identity as before. The new certificate is added to the distributed ledger after the verification. The verification process is described in Figure 5.

• Secure communication:

The secure communication process is illustrated in Figure 6. To be clear, our communication model is based on the architecture of standalone name resolution system [44,45,46], which is suitable for prototype systems such as DONA, Netlnf, etc. The designed ICN communication mode is a single handshake mode, so there is no three-handshake process of ACK before certificate exchange. In order to ensure security, after obtaining the network address through naming resolution, user A first queries and checks the certificate of user B according to the certificate ID in the decentralized PKI based on the blockchain. When the certificate is verified as correct, user A makes a communication request, encrypts and sends their certificate ID to the user B. Because the SNR system will not check the correctness of ID-NA registration, that is, if there are malicious users, it is not guaranteed that the ID-NA registered for content resources is a valid content link, and the certificate verification in advance can ensure that it will not be linked to the phishing address and be attacked. At the same time, the certificate ID needs to be registered with the user ID in the SNR system to provide anchoring and query services for the user ID and the corresponding certificate ID. During the initial interaction, there is no public key certificate between the communication parties. If the certificate ID is sent in clear text, the security of the information cannot be guaranteed. Therefore, SNR is responsible for issuing the certificate ID during the initial interaction. Here, user A represents the subscriber and user B represents the provider of services, which may be publishing or caching.

5. Security Analysis

According to the adversary model we proposed in Section 3.2, the security analysis is mainly interpreted according the following three perspectives: proof security, certificate security and communication security.

5.1. Proof Security

Since the consensus nodes are semi-trusted nodes and malicious adversaries may steal the proof P of legitimate users to fake the identity in the process of certificate registration, we discuss the security of our proof in three parts: zero-knowledge, to ensure the protection of privacy, completeness, to prove the rationality of the verifiable presentation of the proof and soundness, to explain the unforgeability of the proof, all of which are the security properties of zero-knowledge proof.

Completeness: As the secret value s is not disclosed, and the honest prover follows our protocol, the proof π = {x, Sig1, Sig2} can be accepted by the honest verifier in the following checking list as Section 4.1. The verifier checks the issuer signature Sig1 and Sig2 according to the rules (Sig2)Q = (k+ H (v||K||credential)* SK_issuer)Q = kQ + H(v||K||credential)* (SK_issuerQ) = Sig1 + Hash(v||K||credential)* PK_issuer and verifies the computed value of the x according to the rules g^yv^−e = g^+sev^−e = g^r+se (g^s)^−e mod p = g^rmod p = x. If the proof π passes successfully, s must be the shared secret value to calculate parameter v, and the verifier believes the prover knows the secret value s, which proves the identity of the prover.

Soundness: Based on the difficulty of solving discrete logarithm problems (DLPs), adversaries rarely forge the parameters x, Sig1, Sig2 without the secret s, private random k and SK_issuer, according to the rules in Section 4.1. Therefore, the proof π remains secret and hidden, which means that after the prover publishes the proof π, the probability of changing the secret and generating the same proof is negligible. In addition, if the adversaries do not know the secret value s and the SK_issuer, they have little chance of guessing the proof π. Even if they steal the proof π of a legal prover, the timestamp ensures that they cannot launch replay attacks. Meanwhile, due to the rules that P_i(n) ≠ P_i(n + 1), provers can generate different proofs given at random r, which ensures that they can regenerate new proof and timestamps when a proof is stolen. These rules prevent adversaries from using an old proof to impersonate legal identities. Therefore, our protocol provides the property of soundness.

Zero-knowledge: During the whole protocol, the verifier does not have any further information other than proof π. The secret value s and other unnecessary private data are not revealed. The prover does not interact with the verifier and the prover can convince the verifier that they knows s without revealing knowledge of s according to the verification rules, which proves the zero-knowledge of our scheme.

Therefore, the authentication presentation using zero-knowledge proof is secure as an identity proof and also provides further security for the following certificate generation and management process.

5.2. Certificate Security

In the previous sub-section, we proved the security and unforgeability of the verifiable presentation as identity proof. Additionally, malicious adversaries will attempt to steal the certificates or the private keys of legitimate users to forge the identity of legitimate users in the process of data exchange. Since the identity proof is unforgeable, even if a user’s private key is lost or stolen, an old certificate can be revoked and regenerated with the identity proof. Therefore, adversaries cannot forge a user’s self-signed certificate by stealing and replaying, which ensures the security of the certificate in the process of data exchange. In the revocation and update phase, we designed two guarantees: identity and old version ownership verification, which makes it difficult for the adversaries to tamper with the user certificate on the blockchain.

5.3. Communication Security

In order to ensure the security of communication, we register the certificate ID in the SNR system along with the network address, because the hash name of the certificate ID must be reliable as the validation proof to prove the integrity of the certificate. After that, users can conduct further certificate interaction and prove their ownership of the private key through the nonce challenge. Asymmetric encryption guarantees the security of the remaining steps. If one party is a fake user, they cannot pass the nonce challenge of authentication, which ensures the security of communication security in our scheme.

6. Experiments and Performance

The experiments of our scheme are deployed based on an open-source blockchain platform called FISCO BCOS [47,48]. This platform includes many features, such as security, reliability and scalability. Our implementation consists of two parts. One is smart contract algorithms based on the blockchain. The smart contracts should implement basic functions consisting of registering transactions and retrieving data on the blockchain. The other is the implementation of verification functions for cryptography calculations which do not include smart contracts, such as proof and signature verification. The blockchain we chose features Java SDK, offering APIs for developers to program through the Java SDK, providing parameters for the smart contract and the calling of the functions implemented by smart contracts, which is shown as Figure 7. Therefore, we first used register and query smart contracts to implement the basic functions with respect to the blockchain and then wrote a Java application to complete the entire experiment as required.

Because it is possible to deploy several different nodes on the same server for a test chain, we used a Linux server to deploy nodes. The CPU of this server possesses a dual physics core and eight logical cores with an Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz on each core. The memory was 64 GB. We ran 10 test cases for every experiment to obtain average results. The communication link delay was set as 100ms. The consensus algorithm employed in our experiments was PBFT.

We first investigated the delay of the registration phase under the CL signature and our proposal. As presented in Figure 8, it is obvious that the verification of the CL signature takes longer, which delays the certificate registration. With an increase in the number of credential claims that need to be verified in verifiable presentations, the advantages of the Schnorr signature become clearer. On average, the proposed scheme saves about 20% in terms of the registration delay compared to the Cl signature in the context of multiple claim verification.

Then we counted the delay of the registration phase under different numbers of consensus nodes. The results are presented in Figure 9, in which it is possible to see how the delay increases along with the blockchain height and more consensus nodes, which is because more time is required to ensure consistency and reach a consensus.

Finally, we focused on the query delay, updating delay and revoking delay of certificates. The number of consensus nodes was eight. Meanwhile, since the certificate query was based on the blockchain distributed database and the query will not have been concentrated on one node, we assumed that there would be no waiting delay by default. As shown in Figure 10, the query time for certificates increase rapidly along with the blockchain height. This is because the increase in data size of distributed ledger slows down the query traversal time, which may be a challenge faced by all blockchain-based decentralized PKIs. Therefore, the optimization of the certificate query delay will be discussed in detail in future research by our groups. Figure 11 shows the updating and revoking delays for certificates. Due to the influence of the query delay, the delays in terms of update and revocation were also longer.

7. Conclusions

In this paper, a complete decentralized PKI scheme was presented by combining the DID, verifiable credentials project and blockchain. We designed an optimized zero-knowledge proof verifiable representation scheme, so that users can prove their real-world identities without undermining their privacy. We complete the binding of the identity with the public key certificates and realize the certificate generation and certificate management through the blockchain. Meanwhile, we also provided the application of the decentralized certificates in ICN secure communication and discussed the security and basic performance of the whole scheme.

Meanwhile, there are still some limitations of current work in terms of in-depth research on the integration of ICN and DPKI. Using the characteristics of the ICN, the blockchain can sink various technologies into the network. In addition, the query time for certificates increased rapidly along with the blockchain height, which may be a challenge faced by DPKI. Therefore, in future work, we hope to apply the scheme to a practical project and, on this basis, we will optimize our scheme in terms of certificate efficiency, storage and queries by using additional characteristics of ICN networks, such as caching, routing, etc. The discovery and certificate revocation of malicious nodes, as well as blacklist synchronization, will also be discussed by our groups in future work.