Abstract
Named Data Networking (NDN) is a promising network architecture that differs from the traditional TCP/IP network, as it focuses on data rather than the host. A new secure model is required to provide the data-oriented trust instead of the host-oriented trust. This paper proposes a new secure solution in the NDNs named Secure Mechanism supported by Certificateless Digital Signature and Blockchain (CLDS-B). The CLDS-B scheme employs a certificateless digital signature to guarantee the authentication and integrity of data. On the one hand, the key escrow problem has been solved to eliminate the risks of compromised private key generators; on the other hand, the data name has been bound to the public key to prevent the false public key. Moreover, the blockchain is used to manage cryptographic information. Each domain designates an information service entity to join the blockchain so that the consumer could retrieve the cryptographic information public parameter in the local domain if necessary. Furthermore, due to the decentralization of the blockchain, the CLDS-B would be robust to resist the single-node failure. Simulation results show that the CLDS-B scheme outperforms a classic NDN scheme, although it shows slightly inferior to the other secure NDN scheme. The security verification and analysis show that the CLDS-B would resist the key escrow attack. The CLDS-B would be a competitive solution in scenarios with a high-security level.
1. Introduction
As a candidate for future Internet, Named Data Networking (NDN) [1] is based on a data-centric architecture. Different from the traditional IP networks, the data in the NDNs would be accessed by data names at the network layer rather than host addresses. Moreover, in NDNs, routers are equipped with large memories to cache the forwarding data. If the request for cached data arrives later, routers would reply to the request directly with the cached data instead of forwarding it to the data sources. As a result, the load of the data sources would be relieved and the delay of the reply would become smaller in NDNs. Moreover, the overhead of the network would be reduced [2].
The data-centric architecture implies that NDNs have new security requirements to protect data rather than the communication channels in the IP networks. The data-oriented security mainly includes data authentication, data integrity, data confidentiality, and data privacy [3, 4]. Data authentication and data integrity are our focuses. Data authentication requires that the received data must be produced by the authenticated data sources no matter which network entity data are replied by; and data integrity requires that the received data must not be tampered with by others after they are produced by the data sources. IP networks use the digital signature to provide security services of the authentication and integrity for the communication channels. Therefore, similarly, NDNs have incorporated digital signatures to ensure data authentication and integrity. A signature would be generated by the data source to attach to the data to be delivered in the NDNs. As a result, public keys of data sources would be required to be distributed to all the data requesters. It seems that the traditional public key infrastructure (PKI) [5] is a good candidate for public key distribution. In PKI, certificate authorities (CAs) would serve as the trust anchor. It would issue certificates and publish the valid certificates on the website. The certificates bind the identity information and the public key information. All the users who need the information on public keys could download the certificates and then retrieve the public key from the certificates. However, the certificate issue and management are costly and resource-intensive. To eliminate the cumbersome certificate management, the concept of an identity-based cryptosystem (IBC) has been proposed in [6]. In NDNs, IBC would use identity information as the public key directly. Since the identity information is usually assumed to be known by users, there are no additional demands for public key distribution so as to eliminate the need to request and exchange certificates. However, in the context of the IBC, a highly trusted third party is required to generate the private keys, which leads to the problem of key escrow to violate the nonrepudiation. Key escrow involves entrusting the generation and storage of private keys to a trusted third party. However, this method may compromise nonrepudiation, as the third party could potentially deny generating the private key, thus impacting the trustworthiness and traceability of transactions.
Therefore, the concept of certificateless public key cryptography (CL-PKC) has been proposed in [7], which avoids the key escrow problem in the IBC and reduces the complexity of traditional PKI-based cryptosystems. The CL-PKC is a convergence between the traditional PKI and the IBC. On the one hand, the Key Generation Center (KGC), as a trusted third party, would still be employed by certificateless public key systems to generate partial private keys instead of complete private keys. The complete private keys are generated using the partial private keys designated by KGC and the secret values chosen by the key owners. As a result, KGC would just know the partial private key rather than the complete private keys, and only the key owners could know their complete private keys. The key escrow problem is solved by the CL-PKC so that true nonrepudiation would be achieved. On the other hand, the user generates their own public key, and it does not require authentication from a CA. Consequently, the public key does not need a certificate to validate its authenticity. In this sense, CL-PKC should be a better solution to provide the public key for NDNs.
Moreover, trust models for authentication and key management are also important challenges for NDN security. At present, most trust models are based on centralized trust anchors. Traditionally, centralized trust authorities usually hold the authority and trustworthiness to reliably authenticate and verify the user’s identity. Moreover, the structures of the centralized trust models are relatively simple, so that their management would be easy. However, the centralized trust models are vulnerable since they may suffer from the risk of single-node failure. The centralized trust authority would become the main subject of the distributed Denial of Service (DDoS) attacks. Once it is compromised, the whole cryptographic system would sustain information leakage and privacy violations. Therefore, decentralized models would be pursued by NDNs. Blockchain, as a decentralized distributed system, should be a solution that can effectively mitigate the abovementioned risks. On the one hand, blockchain can generate and manage cryptographic keys with its decentralized feature, which can solve the possible single-node failure problem and other security problems such as opacity and dependency. On the other hand, blockchain adopts a peer-to-peer architecture to transfer data directly between nodes, reducing the risk of information leakage and tampering. Although certificateless digital signature encryption is a digital signature and authentication technology without a trust center. It still requires some trusted authority to distribute the public keys and identity information. Blockchain technology ensures the security and reliability of public keys while enabling the management of them.
In this paper, we focus on the security mechanisms in NDNs to implement data-oriented authentication and to verify the integrity of Data packets. We propose a blockchain-based certificateless digital signature scheme (CLDS-B) for secure communication in NDNs. In the CLDS-B, the certificateless digital signature algorithm would be employed to sign and verify the data. Since no certificates are required, there is no heavy load of the certificate management. Moreover, the KGC does not know the complete private keys of the data sources, so that there is no risk of the key escrow. On the other hand, the blockchain is used to store the public keys of the data sources. Due to the decentralized structure of the blockchain, a single failure would not cause the trust collapse of the entire network. Meanwhile, this solution maintains a comparable network performance with inspired by the solution in [8], which. However, there are still some security services that need to be improved to fix the key escrow problem. Compared with the solution in [8], the CLDS-B scheme achieves a higher level of security with the ability to solve the problem of key escrow.
The major contributions in this paper could be summarized as follows: We propose the novel CLDS-B scheme to improve the security and nonrepudiation of signatures to mitigate some flaws in the AHISM-B scheme, avoiding a potential disaster of forged signatures from key escrow. We conduct simulation experiments to evaluate the performance of the CLDS-B and compare it with the classic NDN scheme in [9], the HISM-B scheme in [10], and the AHISM-B scheme in [8].
The rest of this paper is organized as follows: Section 2 describes related work on security mechanisms in NDNs. Section 3 introduces certificateless digital signature and the network model. We then propose the security-enhanced CLDS-B scheme in Section 4. Section 5 provides a security analysis of the CLDS-B scheme. Section 6 formally validates the CLDS-B scheme. Section 7 performs performance evaluation of the CLDS-B scheme and comparison with other schemes. Section 8 concludes the whole paper.
2. Related Work
2.1. Secure Model in NDN
NDNs bring new challenges to traditional security mechanisms. In recent years, several solutions to address these challenges have been proposed, which can be broadly classified into traditional PKI-based encryption schemes and identity-based encryption schemes.
In the literature for NDNs, the solution of PKI-based cryptography has focused on two areas, including public key management and namespaces. Public key management deserves attention due to the widespread use of public key signatures in NDNs. It is argued in [11] that an NDN requires public key certificates as a trusted assertion. Also, it uses well-defined certificate formats and various systems and protocols that support certificate distribution and revocation to authenticate and manage public keys. In addition, several methods for providing certificates and the design of certificate revocation have been discussed. The issuance and revocation of certificates play an important role in securing and trusting data in the NDNs. The certificate revocation problem in NDNs has been explored in [12] with a proposal of a certificate revocation framework named CertRevoke. The framework aims to address the security and efficiency issues of certificate revocation in the NDNs. Specifically, CertRevoke utilizes naming conventions and trust models to ensure the legitimacy of revocation records and to improve efficiency by caching these records in the networks. At the same time, a new idea and approach to certificate management in NDNs has been presented. In addition to public key management, namespace management is an important safeguard to ensure that NDNs can share and transmit data efficiently. The NDN Certificate Management Protocol has been proposed in [13] to manage cryptographic keys and certificates. It uses a namespace to generate certificates and certificates of subnamespaces. Meanwhile, a flexible mechanism to obtain trust between delegated certificates has been designed in [14], which explores two requirements needed to implement trust establishment in NDNs, which are namespace management and public key management. Through a survey of NDN applications, a framework has been derived to systematically evaluate and assess namespace and public key management systems and relate their functionality to Domain Name System Security Extensions and Web PKI. In addition, existing approaches have been compared with the two most prominent implementations currently available on the Internet. A valuable reference for the design and implementation of future NDN applications has been provided. However, although the PKI-based encryption algorithm is an important approach to secure data exchanges in NDNs, there are some disadvantages and limitations, such as the digital certificates need to be verified and distributed with a high management cost. At the same time, the certificate needs to be issued by a third party, and once it fails, the whole communication system is exposed to great risks.
Recently, in the field of authentication and encryption, the applicability of IBC in NDNs has been explored. The requirements of a naming system for NDNs have been defined in [15] to provide security services that bind naming and content. Then, PKI and hierarchical identity-based cryptography are combined to enhance the security of the NDNs. A distributed authentication and authorization scheme (DAAS) has been proposed in [16] that addresses the excessive traffic overhead caused by secure distributed data sharing. The attribute manifest distribution and automatic attribute updates proposed by the DAAS scheme can reduce the cost of retrieval, which is well suited for the NDNs that use data names for retrieval. A signature scheme has been proposed in [17] based on the concept of a hyperelliptic curve’s identity that emphasizes the integrity and authenticity of the content. It cannot only protect NDNs from possible content poisoning attacks (CPA) but can also provide the same level of security as the Rivest–Shamir–Adleman (RSA), bilinear pairing, and the elliptic curve cryptosystem (ECC). The access control on the information service entity scheme (ACISE) has been proposed in [18], which is supported by an ISE for NDNs. The IBC is used to generate private keys and signatures for authorized consumers at the ISE. The ACISE scheme is not subject to cache contamination attacks and can maintain a small response latency under attacks. A solution, called AHISM in [8], enables secure communication and data sharing in NDNs, which works based on blockchain. On the one hand, hierarchical identity-based cryptography is used to bind data names to public keys in AHISM. Valid public parameters would be requested by the consumer using the Interest packet so that the consumer could compose the producer’s public key to authenticate the producer and verify the integrity of the requested Data packets. On the other hand, a blockchain is used to manage the public parameters to avoid disasters due to the failure of a single node. However, these schemes based on IBC would face the problem of key escrow that violates the nonrepudiation. If the private key generated by a third party is attacked and someone impersonates a third party to forge a signature, consumers would be exposed to security threats.
In summary, the researches on secure NDN schemes have still been challenged by the certificate management and the key escrow. Inspired by literatures [8–10], we would explore the certificateless digital signatures in NDNs for data authentication and data integrity.
2.2. Certificateless Signature
As a suitable alternative to traditional PKI and identity-based digital signature schemes, certificateless signature schemes have gained wide attention from both academia and industry since they get rid of the complex certificate management and prevent the private key generator to know users’ private keys. Yeh et al. [19] proposed a certificateless signature scheme specifically designed for Internet of Things (IoT) smart devices. In addition, other researchers [20–22] have also been attempting to provide more efficient certificateless signature methods for data authentication in industrial IoT infrastructure. The certificateless digital signatures, with their outstanding features, have been widely deployed in various practical applications, such as e-healthcare [23, 24] and vehicular ad hoc networks [25, 26].
In practical environments, to meet different business requirements, researchers have combined the certificateless cryptography scheme with other cryptographic primitives to design and propose many certificateless digital signature schemes with special properties. Among them, certificateless schemes based on proxy resignature can solve the problem of long signature chain conversion and uncertainty in trust relationships between communication parties [27, 28]. Certificateless signature schemes with batch verification could simultaneously verify the correctness of a large number of signatures from different signers for different messages, improving the efficiency of signature verification [29, 30]. The integrated digital signature schemes have also attracted much attention [31, 32] in order to support heterogeneous device environments where sensors in industrial IoT environments adopt ID-based cryptographic systems, and smart devices adopt CL-based cryptographic systems. Therefore, the certificate-less signature scheme has broad prospects for development and application scenarios and would become one of the important technological solutions for future digital signatures and identity verification.
2.3. Certificateless Signature in NDN
Recent research has made significant strides in NDN and certificateless signature schemes. In order to address the security challenges in the IoT environment, Huang et al. [33] proposed a certificateless group signature scheme based on mobile edge computing (MEC). It has offloaded signature pressure from the data source to the MEC server to satisfy the resource-constrained IoT devices. Hussain et al. [34] focused on defense against CPA in NDN-based IoT networks. Additionally, Ullah et al. [35] and Rao et al. [36] applied NDN to the healthcare sector. They proposed the NDN-based medical IoT framework that adopts lightweight certificateless signatures and utilizes the hyperelliptic curve cryptosystem to enhance security while reducing costs. These studies collectively advance the security and efficiency of NDN in IoT applications, offering new ideas and solutions for future network security and optimization.
In this paper, we focus on improving the efficiency of certificateless signature schemes applied to the NDNs.
3. System Model
Certificateless digital signature aims to address some of the limitations of PKI-based digital signature schemes and identity-based digital signature schemes. Unlike previous approaches, certificateless digital signature does not require the use of digital certificates issued by trusted third parties, nor does it face the key escrow problem associated with identity-based encryption algorithms. It combines private keys and keys generated by a KGC to solve the trust management issue of keys. Therefore, adopting a certificateless trust management approach has the potential to provide a solution for trust management in NDN.
3.1. Generic Certificateless Digital Signature
In a certificateless signature scheme, there are three legitimate participants: signer, verifier, and KGC. The scheme consists of the following algorithms:
System Initialization: The algorithm is performed by the KGC. Its input is a system parameter k, and its outputs are the system master key s and the system public parameters params.
Secret Value Generation: The algorithm is performed by KGC. Its inputs are system parameters params, system master key s, and user identity ID, and its output is the user’s secret value DA.
Private Value Generation: The algorithm is performed by the signer. Its inputs are system parameters params, user identity ID, and a random value, and its output is the user’s private value XA.
Partial Private Key Generation: The algorithm is performed by the signer. Its inputs are system parameters params, user’s secret value DA, and private value XA, and its output is the user’s partial private key SA.
Partial Public Key Generation: The algorithm is performed by the signer. Its inputs are system parameters params, user’s private value XA, and its output is the user’s partial public key PA.
Signing: The algorithm is performed by the signer. Its inputs are the message m to be signed, the user’s identity ID, and the user’s partial private key SA, and its output is a signature σ.
Verification: The algorithm is performed by the verifier. Its inputs are the message m, the signature σ, system public parameters params, the signer’s partial public key PA, and the user’s identity ID. If the signature is valid, its output is True; otherwise, its output is False.
3.2. Network Model
The topology of our network is shown in Figure 1, which is composed of the fundamental network devices in NDNs, including producers, consumers, routers, and special servers, named ISEs.
The producers, consumers, and routers in the network are all devices in a standard NDN. The producer would play the role of signer, and the consumer would play the role of verifier. An ISE would play the role of a KGC, which is used to generate the producer’s partial private key and ISE’s key pair.
The entire network consists of the blockchain network and the NDN. The blockchain network is a multidomain network whose participants are the ISEs designated by each domain. It takes charge of the management of the cryptographic information, including public parameters and partial public keys of producers. In NDNs, producers would generate the signature for every Data packet, and consumers would verify the signature encapsulated in the received Data packet to guarantee the data integrity and data authentication. The partial private key used to signature generation would fetch from ISE, and the public key used to signature verification may retrieve form the blockchain network.
3.2.1. Two Assumptions
In this work, there are two assumptions as follows: (1) There are secure channels between the producers and their ISEs. These secure channels are used to distribute the domain parameters, and producer’s secret value to producers, and to register producer’s public keys to the ISE. (2) The ISE has distributed the domain public key to all the consumers located at its domain.
3.2.2. Data Naming
The hierarchical structure would be used to name data in our scheme, which consists of three fields, starting with “/.” The first field indicates the category to which the name belongs. The second field provides identifier information, and the third field contains data information. Each field is organized hierarchically into one or more components separated by a “/.” There are two categories of data name: the names whose first fields are “/ndn/Data” and the names whose first fields is “/ndn/Crypto.” The former one is used to name the data that are requested by the application at the consumers and are published by producers. Therefore, its second fields are the producers’ routing identifiers, i.e., their identities IDs, and its third field usually includes the file name, the file version, and the segment number. The latter one is used to name the data that are managed by the ISEs using the blockchain. Therefore, its second fields are the ISEs’ routing identifiers, and the third fields are usually the identities of the producers and the version. The name indicates the data are the cryptographic information of a producer, which is managed by the ISE.
3.3. Blockchain Smart Contracts
In the CLDS-B scheme, the design based on Hyperledger Fabric serves as the underlying infrastructure of the blockchain network. This scheme utilizes blockchain to manage cryptographic information, effectively reducing the computational costs and preventing attacks such as public key substitution and forged signatures.
In this scheme, one ISE would be authorized to join the blockchain network at the blockchain initialization. After that, other ISEs should request to join the blockchain network. The request would be reviewed by ISEs that have already joined the network. Once approved, the ISEs would synchronize block information and would install the chaincode to become a new member in the blockchain. All the ISEs that have joined the blockchain would take charge of announce the cryptographic information for all the producers that locate at the same domain to the ISEs. The cryptographic information includes the producer’s identity ID, the producer’s partial public key PA, the domain public parameters params, and their validity period. If this announcement is approved by the consensus algorithm, a new block encapsulating the cryptographic information, would be added to the blockchain. Since blocks in the blockchain would be synchronized among all participating ISEs, any ISE can obtain cryptographic information for all producers in any domain from its local blockchain.
This approach effectively utilizes blockchain technology to manage cryptographic information, enhancing system security and trustworthiness. Additionally, the integration with Hyperledger Fabric leverages its mature network infrastructure and smart contract functionality to provide robust support for the certificateless signature scheme (CLDS-B).
3.4. Threat Model
Our network model involves two types of separate adversaries as follows: Attacker is a malicious signer who cannot obtain part of the legitimate user’s private key, and attacker is a malicious but passive KGC cannot obtain the user’s secret value and replace the user’s public key.
Game I. The game is completed by the interaction between the challenger and the attacker .
Initialization Phase: input security parameter k, then run the Setup algorithm to generate params and s. only sends params to .
Inquiry Phase:
Secret-Value-Query: selects an identity to submit to . When a submitted partial private key query is received, runs the Secret-Value-Gen algorithm to generate secret value and return to .
Private-Value-Query: selects an identity to submit to . When a submitted private value query is received, runs the Partial-Value-Gen algorithm to generate and return a secret value to . If the partial public key of the signer is replaced, terminates this query.
Partial-Public-Key-Query: selects an identity and submits it to . When receiving the public key interrogation submitted by , runs the Partial-Public-Key-Gen algorithm to generate and return the partial public key to .
Replacement-Partial-Public-Key-Query: selects an identity and a new public key to submit to . When receiving the replacement partial public key query submitted by , replaces the original partial public key with the new partial public key .
Signature-Query: selects an identity and message m to submit to . Upon receiving the signature query submitted by , runs the Sign algorithm to generate the signature of message m and returns to . Here, satisfies , where is the current partial public key, and this partial public key can be the partial public key after replaces it.
Forgery Phase: outputs , where is the target user that chooses to forge the signature, is the forged message, is the forged signature about (). If the forged signature is a valid signature and could not submit to Secret-Value-Query and Signature-Query, then attacker wins the game.
Game II. The game is completed by the interaction between the challenger and the attacker .
Initialization Phase: Input security parameter k, then run the Setup algorithm to generate params and s. sends params and s to .
Inquiry Phase: The inquiry process is consistent with Game I.
Forgery Phase: outputs , where is the target user that chooses to forge the signature, is the forged message, is the forged signature about (). If the forged signature is a valid signature and could not submit to Private-Value-query and Signature-query, then attacker wins the game.
If attackers and can win Game I and Game II, respectively, the scheme is unforgeable under adaptation and identity attacks.
4. The Proposed CLDS-B Scheme
The CLDS-B scheme employs the certificateless digital signature and the blockchain to achieve data authentication and data integrity in NDNs. It consists of four phases: network initialization, producer registration, Data packet publication, and Data packet verification.
The notations used in this section and their descriptions are defined in Table 1. The complete process of our proposed solution is shown in Figure 2.
4.1. Network Initiation
An ISE is responsible for generating the domain key pair following Expressions (1) and (2), including the domain public key PKI and the domain private key SKI. It would keep the domain private key SKI confidential and notify the domain public key PKI to all the consumers in the same domain as Assumption (2).
4.2. Producer Registration
In this phase, the producers would generate their key pairs with the assistance of their ISEs and would register their public keys at their ISEs. The key pair generation would follow the general process of the certificateless algorithm that has been introduced in Section 3.1.
4.2.1. System Initialization
The ISE would play the role of the KGC, which uses the system parameters k as its input and generates the system public parameters params and the system master key s as output, as shown in Expression (3).
After generating the params and s, KGC would specify their validity period t.
4.2.2. Interaction
The interaction between producers and their ISEs for registration would be divided into two stages, as shown in Figure 3. Based on Assumption (1), the information exchange in this phase would be protected within a secure channel.
(1)The producer initiates a request, which includes its identity information ID. The ISE would authenticate the producer. The authentication method could be online or offline, which has been beyond this paper. Upon successful authentication, the ISE would calculate a secret value DA using params and ID, as shown in Expression (4). Subsequently, ISE would respond to the producer with both DA and params.
After receiving DA and params, the producer would calculate the privacy value XA itself. It chooses a random value, random, and calculates its privacy value using the public parameter params, its identity ID, and random, as shown in Expression (5).
After has been calculated, the producer uses the public parameter params, the secret value DA, and the XA to calculate the partial private key SA, as shown in Expression (6).
At the same time, the producer also calculates the partial public key PA from the public parameter params and the privacy value XA, as shown in Expression (7).
At the end of this stage, the producer has owned its key pair. The private key is composed of the SA and the ID, and the public key is composed of the PA, the ID, and the params. Since the random is chosen by the producer, the ISE cannot calculate the same SA as the producer, so that it cannot know the private key of the producer.(2)After the has been calculated, the producer would send a registration request to ISE. In the registration request, the PA would be notified to the ISE. For an authenticated producer, ISE would store the producer’s identity ID, public parameters params, and the received PA onto the blockchain. Consequently, the blockchain would record the IDs, the params, and the PAs for all the authentication producers.
4.3. Data Packet Publication
As shown in Figure 4, both producers and ISEs would publish packets in NDNs.
(a)
(b)
When an Interest packet is received with the name prefix “/ndn/Data,” the producer would query its local memory for the requested data by the received Interest and then publish a Data packet. The Data packet would include the requested data name, Name, the request data content, Content, and the signature, , at least. The calculation process of signature is as follows: Using a hash function to calculate the digest for the Name and Content. Then, the digest would be signed using the producer’s private key to generate a signature according to Equation (8). Here, the producer’s private key is composed of the ID and the SA. The ID used in the public key must be the same as the second field of the Name.
When an Interest packet is received with the name prefix “/ndn/Crypto,” the ISE would query its blockchain the requested cryptographic data and then publish a Data packet. The Data packet would include the requested data name, Name, the requested cryptographic information, Content, and the signature, , at least. The cryptographic information, Content, includes the public parameters, params, their expiration date, and the producer’s partial public key, PA. The calculation process of signature is as follows: using a hash function to calculate the digest for the Name and Content. Then, the digest would be signed using the domain private key to generate a signature according to Equation (9).
4.4. Data Packet Verification
As shown in Figure 5, when a Data packet arrives, the consumer would process the Data packet with two steps, including data name examination and Data packet verification. In the data name examination, the first field of the data name (Name) is examined. If the first field is neither “/ndn/Crypto” nor “/ndn/Data,” the consumer would discard the Data packet directly due to the illegal data name. Otherwise, Data packet verification would be triggered. In the Data packet verification, the consumer would retrieve the corresponding public key to verify the signature as follows:
If the name prefix is “/ndn/Data,” the Data packet would be considered to be published by the producer, so that the consumer must obtain the public key of the producer to verify the Data packet. The consumer would query the producer’s cryptographic information in its local memory according to the producer’s routing identifier that is contained in the second field of the Name. If the cryptographic information could be found in the local memory, the expiration date in the cryptographic information would be checked. If it indicates the cryptographic information does not expire, the cryptographic information would be used directly for the Data packet verification. Otherwise, no matter whether the cryptographic information expires or it cannot be found, the consumer would send a new Interest packet to request the cryptographic information of the producer. In detail, the first field of the data name in the new Interest packet would be “/ndn/Crypto,” and the second field of the data name would be the routing identifier of the ISE that locates the same domain as the consumer. Moreover, the third field of the data name would be the routing identifier of the producer. Therefore, the data name would indicate that the new Interest would be routed to the ISE and the cryptographic information of the producer is requested. As a result, a new Data packet would be received as a response to the new Interest. Its verification detail would be described in the next paragraph. If the verification result is true, the cryptographic information contained in the Content would be used for the verification of the current Data packet. The cryptographic information fetched from the local memory or the Data packet whose name prefix is “/ndn/Crypto” would include the public parameters, params, their expiration date, and the producer’s partial public key, PA. The public key of the producer would be composed of the params, the PA, and the ID. The params and the PA could be obtained from the fetched cryptographic information easily, and the ID would refer to the routing identifier of the producer contained in the second field of the data name. As a result, the signature could be verified according to Equation (10). In detail, the received signature would be decrypted by the producer’s public key to get the digest , and the hash algorithm is used to calculate the other digest for the Name and Content as . If is equal to , the verification result is True. The Data packet would be determined as the one with data authentication and data integrity. Therefore, it would be forwarded to the NDN application at the consumer. Otherwise, the verification result is False. The Data packet would be determined as the one from the unauthenticated producer or the one that has been modified. Therefore, it would be discarded as follows:
When the name prefix is “/ndn/Crypto,” the Data packet would be considered to be published by the ISE so that the consumer would verify the Data packet using the domain public key, PKI. The PKI has been distributed from the ISE to all network entities in the same domain as Assumption (2) so that the consumer could fetch the PKI from its local memory easily. The signature is verified according to Equation (11). In detail, the received signature would be decrypted by PKI to get the digest , and the hash algorithm is used to calculate the other digest for the Name and Content as . If is equal to , the verification result is True. The Data packet would be determined as the one with data authentication and data integrity. Therefore, the cryptographic information in the Content field would be used to verify the Data packet with the name prefix “/ndn/Data” and would also be stored in the local memory of the consumer. Otherwise, the verification result is False. The Data packet would be determined as the one that is published by an unauthenticated producer or the one that has been modified. Therefore, it would be discarded as follows:
5. Security Analysis
This section would analyze the security of our CLDS-B. Both the formal analysis and the informal analysis would be presented, respectively.
5.1. Formal Security Analysis
5.1.1. Certificateless Signature Algorithm
Any Certificateless Signature Algorithm that can provide high-security strength could be a candidate for our CLDS-B scheme. Here, a certificateless digital signature based on elliptic curve cryptography is selected as our referenced algorithm [8]. There are three legitimate participants in the CLDS-B: the producer, the consumer, and the ISE. The producer and the consumer would play the role of the signer and the role of the verifier, respectively, and the ISE would play the role of a KGC. The scheme consists of the following algorithm:
Setup: It is executed by the ISE. A prime number q with a length of λ-bit is selected first. G is an elliptic additive group of order q over finite field . is a generator. Then, the ISE randomly selects the system master private key and calculates = sP. At the same time, it picks three hash functions as follows:
At last, the ISE would combine the system parameters as follows:
In summary, the Setup algorithm inputs parameter λ and outputs s and system parameter params at an ISE.
Secret-Value-Generation: It is also executed by the ISE. After obtaining the producer’s routing identity , the ISE randomly chooses and then computes , , mod q. After that, it must verify an equation , since + . If the equation holds, the si would be referred to as the secret value and then the (, ) would be delivered to the producer using a secure channel described in Assumption (1). Otherwise, the ISE must restart the Secret-Value-Generation.
Private-Value-Generation: It is executed by the producer. An number is randomly selected as the privacy value .
Partial-Private-Key-Generation: It is also executed by the producer. The partial private key, SAi, would be composed of the secret value and the privacy value, i.e., , and the private key of the producer would be viewed as the combination of the SAi and the IDi.
Partial-Public-Key-Generation: It is also executed by the producer. The calculation is performed as follows: , , + , and then the partial public key, PAi, is composed of the Ri and the Qi, i.e., , and the public key of the producer would be viewed as the combination of the , the params, and the IDi.
Signature: It is also executed by the producer. The Name and the Content in the Data packet are viewed as the message m. Therefore, the inputs would be the m, and the public key of the producer that includes the param, the and t, and the output is the signature . The calculation procedure is as follows: The producer randomly chooses and computes , where , denotes the x-coordinate, y-coordinate respectively. The it calculates mod q, , , and mod q. After that, the combination of the T and the would be viewed as the signature, i.e., .
Verification: It is executed by the consumer. The inputs would be the message, the signature, and the public key of the producer, i.e., (m, σ, params, ). The output is the verification result, whose value is True or False. The value of True indicates the m is data-authenticated and data-integral, and the value of False indicates the m is published by an unauthenticated producer or is modified. The verification procedure is as follows: The consumer calculates , , and mod q. Then it checks whether holds. If it does, the consumer outputs True, else it outputs False.
The Proof for the verification is shown as follows:
5.1.2. Algorithm Security Analysis
The proposed CLDS-B scheme would be Existential Unforgeability against chosen-message attacks (EUF-CMA), safe against super adversaries if the Elliptic Curve Discrete Logarithm Problem (ECDLP) is difficult to handle in a random prediction machine.
Lemma 1. Under the stochastic prediction machine model, if is a Type I adversary that can attack the unforgeability of signatures in this scheme in polynomial time by a nonnegligible margin , there exists an ECDLP challenger that can solve the ECDLP with in polynomial time by a nonnegligible margin.
: the number of producers generated queries made by adversary to the random prediction machine.
the number of secret value queries made by adversary .
Proof. Assume that is an attacker against ECDLP. ,
makes its subroutine an adversary to break through the proposed signature scheme under adaptive selected message attacks.
maintains lists , , , respectively, recording the hash queries to , , .
maintains lists to record queries on partial private keys, secret values, public keys, and signatures.
Initialization Phase: runs Setup algorithm to calculate system parameters params and send to .
Inquiry Phase: makes the following inquiries: -Query: The format of each item in the list is (,). When a query is received, if (, ), then returns to . Otherwise randomly picks and creates (, ) in and returns to . -Query: The format of each item in the list is (, ). When a query is received, if (, ), then returns to . Otherwise randomly picks , updates (, ) in and returns to . -Query: The format of each item in the list is (, m, ). When a query is received, if (, m, ), then returns to . Otherwise randomly picks , updates (, m, ) in and returns to .
Secret-Value-Generation-Query: The format of each item in the list is (, ). When a query is received, if (, ), then returns to . Otherwise randomly picks , calculates , creates (, ) in and returns () to .
Partial-Private-Key-Query: The format of each item in the list is (, ). When a query is received, if (, ), then returns to . Otherwise randomly picks , updates (, ) in and returns to .
Partial-Public-Key-Query: The format of each item in the list is (, ). When a query is received, if (, ), then returns () to . Otherwise randomly picks , creates (, ) in and returns to . Otherwise queries corresponding (, ) and (, ) using in list and list . Then calculates and + , updates () in , and returns () to .
Partial-Public-Key-Replacement-Query: selects a new public key , and sends (, ) to . When receives a public key replacement query from , updates in .
Signature-Query: The format of each item in the list is (). When a query is received, if (), then randomly picks , calculates , , and mod q, and returns to . Otherwise randomly picks , calculates , and returns to .
Forgery Stage: outputs a forged signature about the identity , message after the above queries. In Game I, is not allowed to submit to Partial-Private-Key-query and () has never been queried to Signature-query. If , then terminates the game. If is valid, the following expression holds:
According to the bifurcation priming, different hash functions can be selected to get two forged signatures and . The following equations can be obtained:
, , are unknown variables. could calculate the value from the equation.
If the following events occur, can successfully utilize attacker to solve ECDLP. : Adversary does not submit to Partial-Private-Key-query. : Adversary successfully outputs a signature with . : Adversary successfully forges two different valid signatures.
During the query phase, makes partial private key queries in total, with a probability of finding the for each query. So .
The probability of that forges a signature with output during the forgery stage is . So .
The probability of successfully outputting a valid forged signature is , and according to the bifurcation lemma, the probability of adversary successfully forging two different valid signatures is .
The probability of event occurring is . If is not negligible, then challenge can solve ECDLP with a probability of , which cannot be ignored either.
Lemma 2. Under the stochastic prediction machine model, if is a Type adversary that can attack the unforgeability of signatures in this scheme in polynomial time by a nonnegligible margin , then there exists an ECDLP challenger that can solve the ECDLP with in polynomial time by a nonnegligible margin.
: the number of producers generated queries oracle queried by adversary to the random prediction machine.
: the number of Secret-Value-queries oracle queried by adversary .
: the number of Public-Key-Replacement-queries oracle queried by adversary .
The proof of Lemma 2 is similar to that of Lemma 1 with the difference that adversary has the KGC master key but cannot replace the producer’s public key. Since does not know the privacy value of the producer, the objective of is to solve to get the privacy value .
Initialization Phase: runs Setup algorithm to calculate system parameters params and s, then send and s to .
Inquiry Phase: The inquiry process is consistent with Lemma 1.
Forgery Stage: outputs a forged signature about the identity , message after the above queries. In Game , is not allowed to submit to Secret-Value-query and Public-Key-Replacement-query, and () has never been queried to Signature-query. If , then terminates the game. If is valid and the following equation holds:
According to the bifurcation priming, we can choose a different hash function to get a new forged signature and the following equation holds:
, are unknown variables. could calculate the value from the equations. If the following event occurs, can successfully utilize attacker to solve ECDLP. : Adversary does not submit to Secret-Value-query and Public-Key-Replacement-query. : Adversary successfully outputs a signature with . : Adversary successfully forges two different valid signatures.
During the query phase, since makes secret value queries and public key replacement queries in total with the probability of finding the ID in each query to be 1/q, .
The probability of forged signature with output during the forgery stage is . So .
The probability of successfully outputting a valid forged signature is , and according to the bifurcation lemma, the probability of adversary successfully forging two different valid signatures is .
The probability of event occurring is . If is not negligible, then challenge can solve ECDLP with a probability of , which cannot be ignored either.
5.2. Informal Security Analysis
The security of the CLDS-B would be analyzed for Four kinds of attacks as follows:
Data Authentication Attacks: In the CLDS-B, all the Data packets must encapsulate signatures, and then consumers would verify the signatures in Data packets to discard the Data packets with illegal signatures. Since consumers fetch public keys for signature verifications from ISEs, producers would register themselves to deliver their cryptographic information to ISEs. During the registration, producers would be authenticated at ISEs. Moreover, the producer’s routing identifiers IDs that are encapsulated in the second field of the data names in Data packets are the element of public keys of signature verifications. Therefore, no imposture public keys could be provide to consumers. As a result, the Data packets that have been verified successfully must be published by the authenticated producers. Our CLDS-B scheme could resist the data authentication attack.
Data Integrity Attacks: In the CLDS-B, a signature is included in the Data packet. Any modification for the Data packet would cause the failure of verification for the signature. As a result, our CLDS-B could resist the data integrity attack.
KGC Internal Attacks: In the CLDS-B, the certificateless signature is employed instead of an identity-based signature. The ISE would take the role of the KGC to calculate the secret value DA for the producer. However, the producer’s private key is the combination of the secret value DA, the privacy value XA, and the producer identifier ID. Therefore, the DA is just one element of the producer’s private key. Since the XA is selected by the producer secretly, the ISE cannot calculate the XA, so that it cannot obtain the produces private key. As a result, any attempt by the ISE to fabricate a signature would be futile. The CLDS-B could prevent KGC internal attacks.
KGC Trust Attacks: In NDNs, both previous identity-based signature schemes and traditional certificateless signature schemes rely on a centralized trust center. However, these centralized schemes face the same security risk. The entire network’s security is compromised if the centralized KGC is attacked. In contrast, our scheme leverages blockchain technology to implement decentralized smart contracts. The consensus algorithm of blockchain ensures that all the ISEs would maintain the consistent cryptographic information of producers. At the same time, the blocks at the blockchain have also record the digests of the previous blocks so that the modification of one block would result in all the following blocks must be modified. As a result, it is judged as impossible to tamper with the cryptographic information recorded at the blocks because the modification of all the following blocks in all the ISEs would take too many resources to be performed. Therefore, our scheme could prevent potential KGC trust attacks.
DDoS Attacks and Reply Attacks: Since our CLDS-B scheme still maintains the most mechanisms of the previous NDNs, the attacks that previous NDNs could prevent would also be prevented by our CLDS-B scheme. Since routers could reply to the Interests directly if they have cached the requested Data packets, the load for producers to reply would be mitigated greatly. Thus, producers would also be far away from the DDoS attacks in our CLDS-B scheme. Moreover, the Data packet has been viewed as the reply to the Interest packet so that the routes and consumers would discard the Data packets that do not match against any items of their PITs. Therefore, the Reply Attacks for the Data packet would be prevented.
6. Formal Security Verification
To demonstrate the security characteristics, we have formally validated the CLDS-B scheme by using Automatic Validation of Internet Security Protocols and Applications (AVISPA), an automatic formal verification tool to validate security protocols. Although it was originally designed for the Internet, AVISPA can be applied to NDN work without any difficulty.
6.1. Modeling Using HLPSL
The High-Level Protocol Specification Language (HLPSL) is used in the AVISPA system to describe secure communication and to verify authentication and integrity according to the CLDS-B scheme. By the CLDS-B scheme, there are two types of participants in the communication, the requester and the responder, where the requester refers to the consumer. Responders can be producers, ISEs, or routers, while producers and ISEs are able to publish packets, and routers act as packet caches. Different from IP networks, the NDNs only focus on the authentication of the packet publisher rather than that of the responder. Therefore, the role of the router is ignored in our formal verification model. Our verification is divided into two cases:(a)Modeling the communication between the consumers and the producers.(b)Modeling communication between consumers and ISEs.
Since the verification process is relatively similar for the two cases, only case (a) is presented in this section.
6.1.1. Basic Roles
Two basic roles, the consumer and the producer, have been defined in the verification model. The consumer will request the specified data via an Interest packet, while the producer will respond using a Data packet. These two basic roles would receive parameters from the combined role, declare their local variables, and perform transitions to simulate the interaction, as shown in Figure 4(a).
6.1.2. Parameters
Two more parameters have been defined besides the two basic roles. The first parameter, named H, is used for the Hash function in the signature. The other one, named PK, is used to simulate the producer’s public key (i.e., ID, PA, and params). The ID in the public key is fetched from the second field of the data name in the Data packet so that it binds the data name to the producer’s public key. Moreover, the params and PA have been delivered to the consumer through communication between the consumer and its ISE. Therefore, it is reasonably assumed that the consumer has the correct public key of the producer.
6.1.3. Local Variables
There are two local variables, named Name and Content, to model the payloads in the packet. The variable Name is used to model the name of the requested data in the Interest packet and the Data packet, while the variable Content is used to model the published data in the Data packet. The two variables are treated as new values at runtime so that they are generated locally by the new () operation in HLSPL.
6.1.4. Goals
The authentication goal is modeled in the validation. It works based on the producer’s signature to guarantee packet integrity and data source authentication.
6.2. Verification Results
Both the CL-AtSe backend and the OFMC backend have been used to validate the CLDS-B scheme. The protocol verification at the sender side in a principal position is shown in Figure 6, and a snapshot of the intruder verification is shown in Figure 7. The verification result is “SAFE,” as shown in Figures 8 and 9, which indicate the goals specified in HLSPL have been achieved, namely the data authentication and the data integrity.
7. Performance Evaluation
Since the CLDS-B has integrated the blockchain into the NDN, the performance evaluation would be performed from two respects, including the blockchain performance evaluation and the NDN performance evaluation.
The blockchain performance is analyzed as follows: Although the blockchain network is a multidomain network, its participants are the ISEs in each domain. Compared to that of producers and consumers in the NDNs, the scale of ISEs would be viewed as much smaller. Since the blockchain in our CLDS-B only takes charge of storing the cryptographic information of producers, the transactions in the blockchain network would be triggered only when the cryptographic information is created for a new producer or is updated. For one producer, it is one time to create its public key, and the frequency to its public key would be several weeks or months. Even if there are several thousands of producers, the transaction volume in the blockchain network would be small. To evaluate the performance of the blockchain network, we have implemented a blockchain experiment based on Hyperledger Fabric [37]. In our experiment, there are 11 ISEs that play three orders and eight peers, and the bandwidth among ISEs is 1 Mbps. The transaction size was between 1 and 3 KB. The experiment result shows that it is approximately 1 s to perform one transaction. This implies that the delay of the blockchain operation would be smaller compared to the secure NDN. Hence, in this section, we would primarily focus on the performance evaluation of the secure NDN.
The NDN simulator, named ndnSIM [38], is extended to simulate the secure NDN network of the proposed CLDS-B scheme. Moreover, the secure schemes of the AHISM-B, the HISM-B scheme, the HISM-B scheme, and the classic NDN scheme would also been simulated as the contrast schemes.
7.1. Network Topology and Configuration
The Abilene network topology [39] is used in our simulation, as shown in Figure 10. In the Abilene network, there are 12 routers with bi-directional links between the routers. We consider a network system with multiple producers and consumers, which are interconnected by some routers. In detail, the routers with the minimal number of links are selected to connect to four consumers respectively. In addition, the two routers with the second minimal number of links are selected to connect to two producers, respectively.
The network parameters are configured as follows: The propagation delay of one hop is d milliseconds, and the bandwidth is b Mbps. Two producers would publish Data packets independently. The population of the Data packet would follow a Zipf-Mandelbrot distribution with parameters q and s and the number of the Data packet published by each producer would be o packets. The cache size of each router is measured directly by the number of packets. It is configured to c packets. The arrival rate of Interest packets at all consumers follows a Poisson distribution with a mean value of r packets per second. The value of r would change in the simulation experiments to show the network performance at different traffic intensities. The data name and the data encapsulated in the packet are simply considered to have a fixed length, so that the Interest packets and the Data packet have a fixed length. In the simulations, the length of the Interest packet is li bytes, and the length of the Data packet is ld bytes. The simulation time of the experiment is t minutes. The parameter value is shown in Table 2.
7.2. Parameter Evaluation
In the secure NDN, the evaluation for the signature delay and the verification delay of the Data packets are critical since they are important components of the response delay of the Interest packets. The signature delay is the time required for the producer to sign a Data packet, while the verification delay is the time used by the consumer to verify the Data packet.
The evaluation of the signature delay and the verification delay is dependent on the cryptographic algorithm. In our evaluation, the AHISM-B scheme and the HISM-B scheme are assumed to use the HESS algorithm [25] to calculate and verify the producer’s signature. With the HESS algorithm, the length of param and the length of the private key are both 128 bytes. The classic NDN scheme uses the elliptic curve digital signature algorithm (ECDSA) with a key size of 571 bits. The CLDS-B scheme uses Jia’s algorithm [40] that is based on the ECC with its key length of 256 bits. All the above secure schemes would choose the secure hash algorithm SHA-256 to calculate the message digest. The HISM-B scheme also employs the RSA algorithm and the Message-Digest 5 (MD5) algorithm for its domain signature. The HESS algorithm, the RSA algorithm, the ECDSA algorithm, and Jia’s algorithm are implemented over the operating system of Ubuntu 16 with the compiler of GCC to sign and verify the multiple Data packets.
The average signature and verification delay per packet in the four secure schemes are shown in Table 3. On the one hand, it is clear that the CLDS-B scheme has the shortest signature delay. On the other hand, the CLDS-B scheme consumes less verification delay than the classic NDN scheme and longer verification delay than both the AHISM-B scheme and the HISM-B scheme. Although it does not have the smallest verification delay, the CLDS-B scheme would present higher lever security. The ISE, which plays the role of the KGC, only generates a partial private key for the producers, and it does not know the user’s full private key. The producers’ private keys are only known to the producers, avoiding the key escrow problem, which allows the CLDS-B to achieve the true nonrepudiation.
7.3. Performance
The performance of the CLDS-B scheme, the AHISM-B scheme, the HISM-B scheme, and the classic NDN scheme would be shown in this section. Our performance metrics mainly include the average number of Interest packets satisfied and the average response delay.
On one hand, the number of satisfied Interest packets is the number of Interest packets that have been replied by the requested Data packets. Therefore, the average number of satisfied Interest packets is the average value of the number of satisfied Interest packets at each consumer. On the other hand, the response delay refers to the time required from the moment to send an Interest packet at the consumer to the moment to receive a verified Data packet at the consumer. Therefore, the average response delay is the average value of the response delay at each consumer.
The average number of satisfied Interest packets is impacted by the average arrival rate of Interest packets, as shown in Table 4. The differences among the four schemes are not large at the low arrival rate of Interest packets. In detail, the number of satisfied Interest packets by the CLDS-B is slightly larger than that of the classic NDN scheme but slightly smaller than that of the AHISM-B scheme and HISM-B scheme. With the increase of the arrival rate, the differences become larger. The reason can be explained by the differences of the verification delay as follows: All Data packets must be verified at the consumer. If the verification delay is large, it could cause Data packets to be queued at the consumer. If the Date packet queue is long enough, some Data packets would be dropped directly. When the arrival rate of Interest packets becomes large, the packet loss rate would increase. Once the Data packets are dropped, the Interest packets need to be retransmitted to request the lost Data packets, which would aggravate the network congestion further. In summary, the larger verification delay is, the less average number of satisfied Interest packets. The verification delay of the CLDS-B is less than that of the classic NDN and is larger than that of the AHISM-B and the HISM-B. Therefore, the average number of satisfied Interest packets of the CLDS-B is larger than that of the classic NDN and is less than that of AHISM-B and the HISM-B.
The average response delay at each consumer is shown in Figures 11–14. As we expected, the curve of the CLDS-B is always below the cure of the classic NDN. It indicates that the CLDS-B has a shorter average response delay than that of the classic NDN scheme at all arrival rates of Interest packets. It is because the signature delay and verification delay of the CLDS-B scheme are much lower than those of the classic NDN scheme. With the increase of the arrival rate, the gap between the CLDS-B curve and the classic NDN curve is widened. It is because the longer signature delay and verification delay would cause a longer queue delay. When the arrival rate is larger, the queue delay would be aggravated. As a result, the CLDS-B would express a greater advantage compared to the classic NDN.
However, the curve of the CLDS-B intersects with both the curve of the AHISM-B and the curve of the HISM-B in Figures 11–13, and there is one intersection in Figure 14. Although it could maintain the shorter response delay when the arrival rate of Interest packets is less, the CLDS-B would show a longer response delay, unfortunately, with the increase of the arrival rate of Interest packets. The response delay is mainly composed by five types of the delay, including the propagation delay, the signature delay, the verification delay, the queue delay, and the retransmission delay. Since the four schemes share the same network topology and the bandwidth, the propagation delay in the four schemes would be very similar. When the arrival rate of the Interest packet is low, the queue delay and the retransmission delay would be zero or very little, so that the response delay is determined by the verification delay and the signature delay mainly. The signature delay of the CLDS-B is much smaller than that of the AHISM-B and HISM-B, and the verification delay of CLDS-B is a little larger than that of the AHISM-B and HISM-B. Although the number of verifications at consumers would be more than the number of signatures at the producer for a Data packet due to the router cache, the signature delay still has the most significant impact on the response delay. As a result, in the low arrival rate, the CLDS-B would express a smaller response delay than the AHISM-B and the HISM-B in Figures 11–13, and it would have a smaller response delay than the HISM-B in Figure 14. With the increase of the arrival rate, the queue delay would become large. In the NDN, routers can cache Data packets to alleviate the load of producers so that almost no queues would appear at producers. Therefore, the queue delay mainly focuses on the queue delay at consumers. The larger the verification delay is, the longer the queue would be at consumers. Since the verification delay of the CLDS-B is a little larger than that of the AHISM-B and HISM-B, the queue delay of the CLDS-B would be a little larger. Therefore, the response delay of the CLDS-B would be a little larger. When the arrival rate increases further, the queue would overflow, so the retransmission would be incurred. The retransmission delay causes the response delay gap among the three schemes to be a little bigger.
In conclusion, the proposed CLDS-B scheme performs better than the classic NDN scheme and shows slight inferiority to the AHISM-B scheme and the HISM-B scheme in terms of the number of satisfied Interest packets and the response delay. However, it has been verified and analyzed to provide stronger security to solve the key escrow problem. As a result, it would be a competitive solution in scenarios with a high-security level.
8. Conclusions
This paper proposes a new secure solution for NDN named Secure Mechanism supported by Certificateless Digital Signature and Blockchain (CLDS-B). The proposed scheme utilizes certificateless digital signatures to provide the data-oriented trust, ensuring identity verification and data integrity while eliminating key escrow issues. The use of blockchain technology allows for the management of encrypted information and enhances security through decentralization. The CLDS-B scheme outperforms the classical NDN scheme in terms of security and network performance, and it is competitive with other schemes. This proposed scheme is well-suited for high-security level scenarios and represents a competitive choice for such environments.
Data Availability
All datasets used in this submission are publicly available and can be accessed through the references cited in the text.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Authors’ Contributions
Mingxuan Zheng performed the experimental operations, Bing Li performed the manuscript writing, and Maode Ma reviewed the manuscript and provided improvement suggestions.