NACDA: Naming-Based Access Control and Decentralized Authorization for Secure Many-to-Many Data Sharing

Abstract

The rapid development of wearable technology has facilitated the collection and sharing of health data, allowing patients to benefit from caretakers and medical research. However, these personal health data often contain sensitive information and it is typically not known in advance with whom the information will be shared. Therefore, messages must be encrypted and shared while adhering to the decoupled communication model. This paper presents NACDA, a secure many-to-many data-sharing service on the Named Data Network (NDN). NACDA uses Identity-Based Encryption with Wildcard Key Derivation (WKD-IBE) to allow naming-based access control, enabling data subjects to share data securely and flexibly regardless of the data processor. In addition, NACDA supplements a decentralized authorization mechanism with blockchain to ensure data subjects’ data ownership and enforce access policies. We developed an NDN-based prototype and performed a security analysis to demonstrate NACDA’s feasibility.

1. Introduction

In recent years, with the development of communication technology, wearable devices have rapidly developed in the healthcare domain. This trend promotes users sharing medical and health data with multiple hospitals or research institutions to enable disease diagnosis and health analysis [1,2]. Thus, the relationship between the user and the institution is a complex many-to-many communication rather than a one-to-one communication. In addition, medical and health data often contain a large amount of private information that, if leaked, would seriously threaten the security of users’ personal property. Therefore, secure healthcare data sharing in many-to-many communication scenarios is crucial.

Secure sharing in many-to-many communications requires data subjects (i.e., the owner of data) to securely, selectively, and flexibly grant access to data processors (i.e., someone who wants to access data). Ideally, it provides the four following features: (i) decoupling data subjects and data processors: data subjects that classify and publish data to storage servers, and data processors that request or subscribe to specific data types; (ii) data confidentiality and integrity: encryption primitives are independent of the data processor, and encryption operations are relatively efficient and can be verifiable; (iii) fine-grained access control: data subjects limit what data types to share and who can access which time range of the data; (iv) decentralized management: data subjects are free from dependence on trusted intermediaries, such as resource management and access authorization, avoiding the problems of transparency and single point of failure.

Most current many-to-many communication systems rely on TCP/IP. However, TCP/IP does not directly support many-to-many communication but requires the implementation of complex logic at the application layer [3]. We implement the four above features by utilizing the functionalities provided by NDN, a data-centric network architecture [4]. In NDN, the data receivers drive communication by hierarchical names and fetch cryptographic data from intermediate caches by intelligent forwarding strategies. On top of NDN, several access control schemes have been proposed to enable secure data sharing in NDN, such as role-based access control (RBAC) and attribute-based encryption (ABE) [5]. However, these schemes rely on the role or attributes of the data receivers, and users may not know which institutions they will share in advance. With the publish–subscribe paradigm in NDN, a more appropriate encryption idea is to encrypt the based on the data’s properties.

This paper leverages WKD-IBE [6] in NDN. WKD-IBE is a public key encryption scheme that enhances the concept of hierarchical identity-based encryption (HIBE) [7] by allowing more general key delegation patterns. We take NDN’s hierarchical naming as a pattern of WKD-IBE to implement naming-based access control. In addition, access control and authorization need to be designed together to enable a complete data-sharing process. We further introduce blockchain technology [8] as a trusted intermediary to address the trust risk of centralized data retrieval and authorization services in NDN. In brief, we build a secure many-to-many data-sharing framework called NACDA with naming-based access control and decentralized authorization. The NACDA’s contributions are as follows.

• A naming-based access control model is proposed based on WKD-IBE, which ensures data confidentiality and integrity as well as fine-grained access control for many-to-many communications in NDN.
• To effectively and securely share resources, we introduce a decentralized authorization mechanism, which allows data subjects to manage the data and access policies. Furthermore, this mechanism grants permissions in a transparent and auditable manner.
• We evaluate the prototype of NACDA and analyze its security.

The remainder of this paper is organized into seven sections. Section 2 describes the background and related work. Section 3 describes NACDA at a high level, including design concepts and architecture. Section 4 presents a name-based access control model that encrypts the data for fine-grained access control in NDN. Section 5 offers a decentralized authorization mechanism that manages data and policies for trusted authorization with the blockchain. Section 6 implements and evaluates the prototype. Finally, Section 7 concludes and discusses this paper.

2. Background and Related Work

This section introduces the related work of access control in NDN and blockchain-based authorization.

2.1. Access Control in NDN

NDN communication consists of two types of packets: an interest packet and data packet, as shown in Figure 1. A processor sends an interest packet, specifying the name of the desired data, and then obtains a data packet containing the data’s content if the storage or route node owns the data. Therefore, NDN drives communication based on the content name and decouples the content from its original location. This phenomenon leads to a loss of control over the content, which causes challenges in achieving effective access control mechanisms [9]. The existing solutions are as follows.

Zhang et al. [10] proposed a well-designed naming convention that facilitates explicitly communicating access policies and efficiently assigning access control keys. In this work, the data subject generates a production credential named a key encryption key (KEK) and a consumption credential named a key decryption key (KDK) related to the data naming. The data producer obtains the KEK and uses it to encrypt the content key (CK), and the authorized processor will obtain the corresponding KDK and decrypt the data. Fan et al. [11] extended [10] to support spatio-temporal policies by adding location information to the KEK and KDK names. However, in fine-grained data access control cases, the data subject needs to generate, manage and transmit many KEKs and KDKs, resulting in high resource consumption.

Feng et al. [5] propose a decentralized CP-ABE scheme. The publisher creates an access policy and encrypts the data according to the policy, the current time, and the time the router caches the data. However, having full knowledge of the processor attributes in advance in large-scale publish/subscribe systems is not practical, and the solution also requires publishers to be available at all times.

Fotiou et al. [12] used HIBE to build name-based security mechanisms for content distribution. The content owner utilizes the Namecoin blockchain to deliver the system parameters. A subscriber then obtains system parameters to verify a digital signature over the item, no matter the providing endpoint. However, it has limitations in hierarchical key derivation, a helpful function of data sharing in NDN.

Table 1. Comparison of NACDA With Other Name-based Access Control.

Related Research	Name-Based Security	Multiple Naming Granularity	Keys Distribution Flexibility	Decoupling and Namespace Delegation	Namespace Granting Simplicity
[10]	Y	N	N	N	N
[11]	Y	Y	N	N	N
[5]	Y	Y	Y	N	N
[12]	Y	Y	Y	Y	N
Our work	Y	Y	Y	Y	Y

compares NACDA with other name-based access control research regarding key features. Our work focuses on many-to-many data-sharing service with efficiently fine-grained access control.

2.2. Blockchain-Based Authorization

While a content-based access control scheme is appropriate in NDN, this scheme cannot be directly associated with data processors. Therefore, it requires additional authorization mechanisms to complement the secure sharing process. The authorization mechanism based on trusted third parties may have the problems of a single point of failure and a non-transparent authorization process. In contrast, blockchain technology is a new decentralized infrastructure and distributed computing paradigm. It has the properties of decentralization, persistency, and auditability, which make the authorization process more secure and credible. The current solutions are presented below.

Ouadda et al. [13] store access policies in blockchain transactions. They use authorization tokens to represent unspent transaction output (UTXO), which can be passed from one peer to another via transactions, thus enabling authorization management. However, its decision-making process counts on a centralized authorization entity, which still suffers from a single point of failure.

Truong et al. [14] proposed a resource access control scheme based on smart contracts, which consists of two ledgers: the 3A_ledger, which is responsible for storing resource summaries and access policies, and the log_ledger, which records authorization tokens. Afterwards, resource servers can query the authorization records in the log_ledger to verify whether the data processors’ requests are legitimate. This work implements the OAuth2 standard [15] authorization process but does not further consider data security and fine-grained access control.

Our research combines a content encryption-based access control scheme with a smart contract-based authorization mechanism to achieve a complete secure sharing process in NDN.

3. NACDA’s Overview

This section describes NACDA in a nutshell and its architecture.

3.1. NACDA in a Nutshell

NACDA is a decentralized access control system that enables data subjects to securely, selectively, and granularly share their data with data processors in a scenario of many-to-many communication. NACDA is designed to use namespaces as the basis for data search, data encryption, and access control, as shown in Figure 2. First, NDN uses hierarchical semantic names to identify content, and the resulting namespace is used for NDN data requests (Section 4.2). Second, since fine-grained data sharing is based on fine-grained data encryption, the namespace naturally serves as the basis for fine-grained encryption. That is, the leaf nodes of the namespace serve as the minimum granularity of data encryption (Section 4.3). Thirdly, the data subject sets the namespace’s node associated with the access policy (Section 5.1) and then denotes the sub-namespace right to a data processor as an access token (Section 5.2). Finally, since fine-grained data encryption generates many keys, there may be problems with key management and distribution. Therefore, we have adopted an access control approach based on hierarchical encryption, where authorized data processors obtain the decryption keys corresponding to the namespace’s nonleaf nodes, and then derive all decryption keys for that sub-namespace themselves (Section 4.3).

Note that we covered the terms authorization and access control, which are relatively easy to confuse. Authorization is the specification of access policies, and access control is the enforcement of access policies [16]. In the above paragraph, we discuss the specification of access control policies and their mappings to access tokens, which we summarize as a decentralized authorization mechanism (Section 5). The remaining parts are summarized as a name-based access control model (Section 4).

3.2. Architecture

Figure 3 shows the architecture of NACDA, and

Table 2. Notation of entries in NACDA architecture.

Notation	Description	Function
IoT devices	Devices for producing data	Producing, encrypting, and uploading data
Data subject	The owner of data	The management of names, spaces, access policies, and decryption keys
Data controller	Someone or an institution who manages personal data	Assuring the rights of data subjects
Data processor	Someone who wants to access data	Requesting access rights, decryption keys, and decrypting data
NDN	Internet architecture	Storing, caching, and forwarding data
Blockchain	Decentralized servers	Storing namespaces, access policies, and granting access rights

explains the entities and components involved. It is essential to note that data sharing should comply with GDPR’s requirements when EU citizens are involved, so we define the entities referring to GDPR [14,17].

The name-based access control model takes namespaces as the basis for data encryption, as shown in the upper part of Figure 3. First of all, the data subject initializes the namespace, which contains a hierarchy of resources and time, and grants sub-namespace to the IoT devices (Step 1). Furthermore, IoT devices generate and encrypt data in the related namespace (Step 2). The encryption process allows different resources to be encrypted at different times using unique encryption parameters and does not require generating and managing extensive encryption keys. Then, the encrypted data are packaged and published on the NDN (Step 3). NDN uses an in-network cache mechanism so that each node in the transmission path can cache the content and quickly respond to the corresponding request. Additionally, the authorized data processor requests data from the NDN (Step 8) and can decrypt the data with the corresponding decryption keys (Steps 10–12).

The name-based access control module ensures data confidentiality. However, it does not adequately consider how to authorize data processors (including verifying identity, managing access policies, and granting access rights). Therefore, the blockchain is introduced to implement a decentralized authorization mechanism, which acts as an agent to handle authorization requests from data processors in a unified manner, as illustrated in the lower part of Figure 3. The data subject uploads the namespace and the corresponding access policy to the blockchain (Steps 4–5). Then, the data processor requests the blockchain to obtain the exact name of the packets and access token (Steps 6–7). When a data processor requests data, the NDN’s node that caches the data will validate access permission again based on the blockchain’s authorization log and choose to allow or deny the data access request (Step 9).

4. Name-Based Access Control Model

The objectives of the name-based access control model can be summarized as follows: (i) data encryption: using the namespace as the basis for the fine-grained and effective encryption primitives. (ii) access control: a data processor can get succinct keys for an access scope grant. Given all the above, the critical point is that NDN naturally organizes the data into hierarchies, resulting in a namespace that could act as the encryption parameter of the lightweight encryption algorithm WKD-IBE. Furthermore, a WKD-IBE’s decryption key related to a namespace can derive all keys of its sub-namespace but not for the parent namespace (Section 4.1). The detailed workflow of the name-based access control module is shown in Figure 4, which is further broken down into name-based encryption (Section 4.2) and fine-grained access control (Section 4.3).

4.1. Generic WKD-IBE

Algorithms

WKD-IBE normally generates a secret key based on an identity string template where wildcards can replace elements. Then, this secret key can derive keys for other identity string vectors that match the above template. Although the original WKD-IBE scheme focuses on the user’s identity information as a template, it can also abstract other details as a template. For example, Kumar et al. [18] proposed that in a system where resources have hierarchical structures, a user has a key with the resource prefix a/b/*, i.e., a/b/* is encoded as a string template and * denotes a wildcard, then it can derive keys with resources a/b/c, a/b/d, etc.

WKD-IBE consists of four operations: Setup, KeyDer, Enc, and Dec. They are described as follows [18]:

• Setup$\left(1^{\ell }\right)\to Params,MasterKey$. This operation outputs public parameters (Params) and master secret key (MasterKey).
• $\mathbf{KeyDer}(Params,Ke{y}_{Patter{n}_A},Patter{n}_B)\to Ke{y}_{Patter{n}_B}$. This operation derives a key for $Patter{n}_B$, where $Ke{y}_{Patter{n}_A}$ is $MasterKey$ or $Patter{n}_A$ matches $Patter{n}_B$.
• $\mathbf{Enc}(Params,Pattern,m)\to Ciphertex{t}_{Pattern,m}$. This operation receives a ciphertext encrypted by $Params$ and $Pattern$.
• $\mathbf{Dec}(Ke{y}_{Patter{n}_A},Ciphertex{t}_{Pattern,m})\to m$. This operation receives a ciphertext encrypted by $Params$ and $Pattern$. Then, it obtains a plain text message m with the help of $Ke{y}_{Pattern}$.

WKD-IBE can also be used to sign data to verify its integrity. It is illustrated as follows:

• $\mathbf{Sign}(Params,Ke{y}_{Patter{n}_m},m)\to S$. This operation uses $Ke{y}_{Patter{n}_m}$ to sign a message m and output the signature S.
• $\mathbf{Verify}(S,Params,Patter{n}_m,m)\to \top or\perp$. This operation uses the $Patter{n}_m$ and the message m to verify the signature S. The output ⊤ indicates a successful verification and the output ⊥ indicates a failed one.

4.2. Name-Based Encryption

The named-based encryption part includes the following steps: the data subject initializes the namespace and WKD-IBE (Section 4.2.1), then grants the IoT devices the right to generate data under the sub-namespace (Section 4.2.2). Finally, the IoT devices generate, encrypt, and publish the data (Section 4.2.3).

4.2.1. Initialization

NDN names resources with hierarchically structured names similar to URI, which group data with similar attributes in the same namespace. This naming way reflects the relationship between different data blocks and facilitates the management and sharing of resources. The data subject and the processor can agree to express a standard namespace structure. Taking the health scenario as an example, the data subject Alice uses the health app to collect her health data and activity data, dividing the corresponding namespace into two sub-namespaces: alice/health and alice/activity, where health data are further divided into blood pressure and heart rate data, corresponding to the sub-namespace: alice/health/BP and alice/health/HR, as shown in Figure 5. Once the resource hierarchy is determined, the resources can be further divided according to the set temporal granularity, i.e., a temporal hierarchy is added to the hierarchy of resources. For example, layers 4–6 in Figure 5 divide the resources by year, month, and day, and the namespace corresponding to the blood pressure data generated by Alice on 12 December 2020 are called alice/health/BP/2020/12/12. The granularity of the namespace division determines the granularity of the subsequent data encryption and sharing.

After defining the NDN’s namespace, the data subject initiates WKD-IBE, which takes the depth of the namespace as input parameters and outputs the public parameters and the master key. This step is represented as follows.

• $\mathbf{Setup}\left(1^{\ell }\right)$: select $g,g_2,g_3,h_1,\dots ,h_{\ell },h_s\stackrel{\$}{\leftarrow }\mathbb{G}$, $\alpha \stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and let $g_1=g^{\alpha }$. Then, the output: $Params$$=\left(g,g_1,g_2,g_3,h_1,\dots ,h_{\ell },h_s\right)$ and $MasterKey$$=g_2^{\alpha }$. $\mathbb{G}$ is a bilinear group if the group action in $\mathbb{G}$ can be efficiently computed and there exists both a group ${\mathbb{G}}_1$ and an efficiently computable bilinear map e: $\mathbb{G}$ × $\mathbb{G}$ → ${\mathbb{G}}_1$.

This datum subject performs this step (or the authority trusted by the data subject) and keeps $MasterKey$ secret. $Params$ can be stored publicly, which data processors use subsequently, so we can use blockchain to disseminate $Params$, i.e., holding them along with the namespace in the data subject’s blockchain account.

Subsequently, the data subject has two aspects of work. One is to grant the right to generate data under the sub-namespace to the IoT devices, and the other is to distribute the decryption keys of an authorized sub-namespace for the data processors. Both of these tasks rely on the key derivation step. Note that we can distinguish encryption and sign by adjusting $Params$ and $MasterKey$ [19].

• $\mathbf{KeyDer}(Params,K,Pattern)$: when K is $MasterKey$, let $K=g_2^{\alpha }$, and $r\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$. The private key for the $Pattern$ of sub-namespace is:

  $$\left(g_2^{\alpha }·{\left(g_3·\prod _{\left(i,a_i\right)\in fixed\left(Pattern\right)}{h}_i^{a_i}\right)}^r,g^r,{\left\{\left(j,h_j^r\right)\right\}}_{j\in free\left(Pattern\right)}\right).$$

  when K is not $MasterKey$, then parse K as $\left(k_0,k_1,B\right)$, $B=\left\{\left(i,b_i\right)\right\}$. Let $t\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$. The private key for S is:

  $$\begin{array}{c}\hfill \left(k_0·{\left(g_3·{\displaystyle \prod _{\left(i,a_i\right)\in fixed\left(Pattern\right)}}{h}_i^{a_i}\right)}^t·{\displaystyle \prod _{\begin{array}{c}\left(i,a_i\right)\in fixed\left(Pattern\right)\\ \left(i,b_i\right)\in B\end{array}}}{b}_i^{a_i},g^t·k_1,\right.\\ \hfill \left.{\left\{\left(j,h_j^t·b_j\right)\right\}}_{j\in free\left(Pattern\right)}\right).\end{array}$$

The $KeyDer$ step considers the case where K is $MasterKey$ or not. Generally, the data subject depends on $MasterKey$ derivation because these have the right to their entire namespace. The case where K is not $MasterKey$, on the other hand, is typically when the IoT devices or data processors obtain the derived key and handle their own sub-namespace.

4.2.2. Sub-Namespace Authorization

The security of the NDN is built into the data themselves, which requires that each packet be signed. The digital signature’s legitimacy ensures the integrity and authentication of the message, preventing it from being tampered with or forged.

Specifically, the data subject grants the producer permission to produce data under its sub-namespace. These permission keys could use an out-of-band channel (e.g., Bluetooth low energy) to exchange between the subject and devices. Then, the devices obtain the keys, generate data, and sign the hash of the data, which is subsequently published to the NDN along with the data packet. The data processor then obtains the data packet and verifies its origin and integrity. The above process is summarized in two steps.

• $\mathbf{Sign}(Params,Ke{y}_{Patter{n}_m},Has{h}_m)\to S$: Parse the key K as $\left(k_0,k_1,B\right)$, $\left(s,b_s\right)\in B$. $Has{h}_m$ is the hash value of message m whose pattern is $Patter{n}_m$, and $Ke{y}_{Patter{n}_m}$ is the corresponding sign key. Select $t\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and output the signature S:

  $$\left(k_0·{\left(g_3·h_s^{Has{h}_m}·\prod _{\left(i,a_i\right)\in fixed\left(Patter{n}_m\right)}{h}_i^{a_i}\right)}^t·b_s^{Has{h}_m},g^t·k_1\right)$$
• $\mathbf{Verify}(Params,S,Patter{n}_m,Has{h}_m)\to \top or\perp$: parse the signature S as $\left(s_0,s_1\right)$. Check:

  $$e\left(s_0,g\right)\stackrel{?}{=}e\left(g_1,g_2\right)·e\left(g_3·h_s^{Has{h}_m}·\prod _{\left(i,a_i\right)\in f\mathrm{fixed}\left(Patter{n}_m\right)}{h}_i^{a_i},s_1\right)$$

The $Sign$ function is usually combined with the $KeyDer$ function (usually when K is not MasterKey) since the sub-namespace obtained by the IoT device is often not a specific sub-namespace. In addition, the data processor verifies the received S to check whether the signature is correct. If the device is authorized, then the hash value can verify the integrity of the data. We use an example to further illustrate the process. Data subject Alice derives the signing key ${Key}_{alice/health}$ for sub-namespace alice/health and sends it to her device. When Alice produces plaintext data m under alice/health/BP/2020/12/12, she calculates the $Has{h}_m$ and signs it, i.e., $\mathbf{KeyDer}(Params,Ke{y}_{alice/health},Patter{n}_{alice/health/BP/2020/12/12})\to Ke{y}_{alice/health/BP/2020/12/12}$, then $\mathbf{Sign}(Params,Patter{n}_{alice/health/BP/2020/12/12},Has{h}_m)\to S$. The data processor obtains the signature S and uses $Patter{n}_{alice/health/BP/2020/12/12}$ to verify the origin and integrity of the m.

4.2.3. Data Encryption

IoT devices generate the data, encrypt them according to WKD-IBE, and publish them to the NDN. Given that IoT devices are usually low-power and have a large amount of data, a hybrid encryption scheme combining WKD-IBE and symmetric encryption is suitable. In detail, the data devices encrypt the plaintext data using a symmetric key and invoke WKD-IBE to encrypt the symmetric key based on the temporal granularity of the namespace. The next encryption round will flip the symmetric key and modify the WKD-IBE encryption parameter. The process is brief in the following step.

• $\mathbf{Enc}(Params,Patter{n}_m,K_m)\to C{T}_{K_m}$: $K_m$ is the symmetric key of message m, then selects $s\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and outputs $C{T}_{K_m}$:

  $$\left(e{\left(g_1,g_2\right)}^s·K_m,g^s,{\left(g_3·\prod _{\left(i,a_i\right)\in fixed\left(Patter{n}_m\right)}{h}_i^{a_i}\right)}^s\right).$$

To further explain the process, we consider an instance of datum m generated under alice/health/BP/2020/12/12. The IoT devices use the AES algorithm to sample a symmetric key $K_m$ to encrypt m. The corresponding generated ciphertext $C{T}_m$, together with the signature information in Section 4.2.2, are packaged and published to the NDN. Meanwhile, as another data packet, $K_m$ is encrypted to generate the key ciphertext $C{T}_{K_m}$. Note that the minimum time granularity of alice/health/BP/2020/12/12 is in days, so the data producer flips the symmetric key and invokes WKD-IBE to encrypt it once a day. The finer temporal hierarchy brings in the finer encryption’s granularity, which benefits flexible data sharing. However, this may cause resource waste, so a balance between granularity and consumption is best based on practical cases.

4.3. Fine-Grained Access Control

The fine-grained access control consists of the following steps: the authorized data processor sends an interest packet to the NDN and requests decryption keys within its authorization from the key server (Section 4.3.1). The data processor then obtains the decryption keys and decrypts the data (Section 4.3.2). Note that this subsection assumes that the data processor has already obtained an access token (Section 5).

4.3.1. Decryption Keys Delegation

When requesting data from the NDN, an authorized data processor first retrieves the ciphertext packet, which usually contains the corresponding key packet name so that the data processor can continue to request key packets. In addition, NDN’s node will verify the data processor’s access token by the blockchain’s authorization log before returning the data, which could intercept data requests from attackers or those with expired authorization tokens.

The data processor also needs to request the decryption keys within the scope of the access token. We previously mentioned in Section 4.2.1 that data subjects distribute decryption keys for data users. However, it would be stressful for the data subject to generate and distribute all decryption keys in advance, so we generate them when the authorized data processor triggers the request. In addition, the single point of failure and performance problems may occur if the only data subject is the only key server responding to a decryption key request.

Considering the derivation nature of WKD-IBE’s keys, the data processor with privileges and the data subject can act together as a key server. When a user requests authorization from the blockchain, the blockchain acts as an authorization server to determine that the user is legitimate and returns the token along with other processors that can derive the decryption key. After receiving the token, the user requests one of the processors to obtain the decryption key (the token supports obtaining the decryption key only once, and decryption keys could be encrypted with the user’s public key), decrypt the data, and verify it against the signature.

4.3.2. Data Decrypt

After obtaining the two packets and the decryption keys, the data processor first decrypts the symmetric key from the key packet and then decrypts the plaintext data using the symmetric key. The operation is succinct in the step below.

• $\mathbf{Dec}(Ke{y}_{Patter{n}_m},C{T}_{K_m})\to K_m$: Parse the $Ke{y}_{Pattern}$ as $\left(k_0,k_1,B\right)$, and the ciphertext $C{T}_{K_m}$ as $(X,Y,Z)$. Output $K_m$:

  $$X·e\left(k_1,Z\right)·e{\left(Y,k_0\right)}^{-1}$$

The $Dec$ function also depends on the $KeyDer$ function to obtain the decryption keys of specific sub-namespace. For example, Bob achieved $Ke{y}_{alice/health}$ and then $\mathbf{KeyDer}(Params,Ke{y}_{alice/health},Patter{n}_{alice/health/BP/2020/12/12})\to Ke{y}_{alice/health/BP/2020/12/12}$. He used the key to decrypt the symmetric key of alice/health/BP/2020/12/12.

5. Decentralized Authorization Mechanism

The decentralized authorization mechanism consists of two parts: (i) content management: the data subject publishes the namespace and access policy, and the data processor retrieves the relevant content; (ii) decentralized authorization: the data processor is granted an access token according to the access policy. We utilize smart contracts to manage the content and automate the authorization operations for those two parts. As shown in Figure 6, there are three smart contracts: the namespace smart contract, the policy smart contract, and the decentralized authorization smart contract. Moreover, all user operations are recorded in the ledgers for auditing at any time.

5.1. Content Management

When a data processor requests dynamically generated data in the NDN, the data are usually retrieved based on the part of the data name. For instance, the data processor sends an interest packet with the name alice/health/BP to retrieve a data packet with the name alice/health/BP/2020/12/12 if it exists and then requests the actual packet. This retrieval process may send multiple interest packets to obtain the datum’s exact name, resulting in more invalid interest packets and inefficient retrieval in the NDN. It is desirable to have a retrieval mechanism to confirm the data name before sending interest packets. Centralized retrieval mechanisms run the risk of a single point of failure. Blockchain, as a decentralized and trusted intermediary, can be used to establish a transparent and reliable named retrieval mechanism. Hence, the data subject publishes the namespace on the blockchain, and the data processor queries to efficiently obtain the exact name of the data (Section 5.1.1). Furthermore, the data subject can further update the access policy based on the namespace, allowing the owner to take ownership of its data and share them selectively and flexibly (Section 5.1.2).

5.1.1. Naming Management

The namespace contract implements naming management, which contains creating and updating namespaces by data subjects and retrieving naming by data processors. The first ledger in Figure 6 shows the structure of the content.

Initially, the data subject registers credentials based on a uniquely named prefix identifier, representing the ability to create and update smart contracts. In addition, the namespace uses a dictionary tree as a storage structure, which is query-efficient. The data subject also stores the hash of static resources and the public parameters of WKD-IBE on the namespace, which assists the data processor in validating and decrypting the data. When a data processor retrieves a naming, the contract checks whether the naming format is standardized and retrieves the dictionary tree. If the naming is already fully named, returning exists. Otherwise, it uses naming as a prefix to search for the relevant specific name and returns the set of names (other restricted parameters can be added, such as the rightmost child, which improves the retrieval efficiency). Overall, data processors can reduce the number of invalid interest packets in the NDN by confirming the specific name before sending the interest packet. Algorithm 1 illustrates the naming retrieval process.

Algorithm 1: Naming Retrieval.

5.1.2. Policy Management

Policy management is implemented in the policy contract, which contains the creation and updating of the policy by data subjects and the retrieval of the policy by data processors. The second ledger in Figure 6 shows the structure of the content.

When a data subject creates an access policy, nodes in the namespace are bound to different access control lists (ACLs) to enable fine-grained access. We can set the ACL to the same level node of the namespace. For example, the data subject Alice uniformly sets her authorization granularity to the fifth level of the namespace, i.e., to authorize access to data by month. This approach improves the efficiency of policy retrieval but limits the minimum sharing granularity. We can also set the ACL to any node of the namespace, which increases the retrieval time but allows flexibility in setting sharing granularity. Algorithm 2 illustrates the policy update process. In addition, there are two types of data-operation abilities for data processors. The authorized data processor can only read the data or further delegate keys to other data processors.   

Algorithm 2: Policy update.

Naming and policies need to be regularly maintained and updated. For the case of data subjects cleaning up outdated data, leading to updates to the namespace. In addition, some malicious users need to be removed from the policy as soon as they are discovered. The data subject must periodically check its namespace and policy whilst the data processors of the relevant updates are notified.

5.2. Decentralized Authorization

The smart contract for decentralized authorization checks the access policy after receiving the request from the data processor. Then, it returns the result and records it in the log ledger. The third ledger in Figure 6 shows the structure of the content.

When a data processor requests read or delegated rights to the resources, the decentralized authorization contract determines the naming’s legitimacy based on the naming contract, and whether the processor is in the access policy based on the policy contract. If the conditions are met, the authorization contract returns an access token for the data processor. Algorithm 3 illustrates the decentralized authorization process. The access token consists of the token header and the token payload, where the token header contains the token ID and the token type. The token ID is a (pseudo) random and unique string, and the token type indicates it is a read or delegated operation. The payload contains specific authorization information, including the grantor (data subject), the grantee (data processor), the scope of the authorization, the authorization time, and the expiration. Moreover, decentralized authorization smart contracts confirm the access token, i.e., whether the data processor requests keys or content, the corresponding node will recheck the token to verify its validity.

Algorithm 3: Decentralized authorization.

6. Implementation and Evaluation

This section describes the experiment environment and evaluates the experimental results.

6.1. Experimental Environment

In this section, we implement the NACDA prototype based on the above design ideas. The name-based access control model was developed in C++ and used the Named Data Networking Forwarding Daemon (NFD) [20] to route and forward NDN packets. The decentralized authorization mechanism built the blockchain environment with the Hyperledger Fabric (HLF) [21] platform. The HLF is a consortium blockchain [22] that allows authenticated and authorized nodes to join the network, resulting in higher levels of security. Therefore, HLF is designed for enterprise environments and is more suitable for this paper’s many-to-many data-sharing usage scenario. All of the above were evaluated in a macOS Monterey 12.6 operating system configured with a 2 GHz quad-core Intel Core i5, 16 GiB RAM.

6.2. Experimental Results

The goal of the decentralized authorization mechanism is that the data subject publishes the namespace and access policy information on the blockchain, and the data processor retrieves the relevant content and obtains an access token. The detailed experimental design is as follows: (i) The HLF platform consists of two peer organizations, Org1 and Org2, each with two Peers, Peer0, and Peer1. It also configures a single-node Raft ordering service. All HLF participants are issued certificates by the built-in fabric certificate authority (CA). (ii) We measured the performance of the authorization mechanism using Caliper [23], an evaluation tool developed for the Hyperledger Foundation. (iii) The mechanism consists of three smart contracts and two ledgers. Namespace and policy information are stored in one ledger, and the access token is stored in another to facilitate the subsequent token verification operations.

Figure 7 and Figure 8 shows the evaluated results of the decentralized authorization mechanism. Figure 7 interprets the performance results for the query ledger (query naming and policy). Figure 7a sets the Caliper to submit 2000 transactions per round. By varying the transaction’s rate controller from 100TPS to 1000TPS, it can be seen that the throughput leveled off after a period of increase, but the latency kept trending upwards. Figure 7b sets the transaction’s rate controller to 750 TPS for each round. By varying the number of transactions submitted from 1000 to 10,000, the maintained throughput remained at approximately 700 TPS, with the success rate of transactions at a high level. Figure 7 illustrates that, when the transaction’s rate controller reaches approximately 700 TPS, an increase in the transaction throughput is blocked, i.e., the local system processing bottleneck is reached. Figure 8 shows the performance results for the updated ledger (update authorization token). The combination of Figure 8a,b demonstrates that the maximum processing capacity of the system is of approximately 150TPS. Accordingly, comparing Figure 7 and Figure 8, it is evident that the performance of the query ledger is much higher than that of the updated ledger because the query ledger operation involves the interaction with only one peer node. On the contrary, the updated ledger operation involves multiple participants (peer endorser, orderer, committer peer) and multiple stages [15].

In the naming-based access control model, the device encrypts and publishes data packets based on the resource namespace. The data processor sends interest packets to achieve encrypted data and decryption keys and decrypts data according to the derived keys. We assume that all data packets the data processor requests can be returned, and the obtained decryption key can decrypt all relevant data. Furthermore, the calculated time of the data producer includes the total time from generating the data to publishing them, and the data processor’s total time includes requesting the data to decrypt them.

Figure 9 shows the time of publishing/receiving data with different packet sizes and numbers with the namespace depth equal to 10. In Figure 9a,b, the different size packets merged multiple data points ranging from 1 KB to 6 KB (up to 8 KB per packet). The results show that the time spent on encryption, decryption, signing, and verification accounts for relatively little of the total time. The remaining time includes packet and communication time in NDN, spending a relatively large amount of time. In addition, as the packet size increases, there is a slight increase in the time spent in each phase. In Figure 9c,d, we fix the packet size to 4 KB to verify the effect of namespace depth on the published and received data. The results show that the time spent in each phase increases as the number of packets increases, where the majority of time is still spent in the NDN.

Figure 10 assesses the relationship between the latency time and packet numbers with different namespace depths. The results of Figure 10a indicate that as the packet numbers increase, a different namespace depth does not have much effect on the publishing time. In contrast, Figure 10b shows that time spent by data processors significantly increases with higher namespace depths. This is because, when the device encrypts data, the namespace’s length has little effect on the encryption operation. Instead, the data processor needs to derive multiple keys when deeper in the namespace’s length.

Subsequently, we compare NACDA to NAC-ABE [24], which uses ABE in NDN, as shown in Figure 11. Since our method considers a data-centric encryption approach, the user attributes and attribute policies in NAC-ABE are converted into data-centric representation. Take the two sub-namespaces /alice/health/BP and /alice/health/HR as examples. In data encryption, both NACDA and NAC-ABE use “1-alice, 2-health, 3-BP” and “1-alice, 2-health, 3-HR” as encryption parameters. When distributing decryption keys, NACDA only needs to share the key for /alice/health/*. In contrast, NAC-ABE needs to share the key for the policies “(1-alice AND 2-health AND 3-BP) or (1-alice AND 2-health AND 3-HR)”. Thus, our method only needs to distribute a smaller size key, which is an advantage, especially when the namespace depth is large. As for decryption, NACDA has one more key derivation step than NAC-ABE. However, we can learn from Figure 9 that the operation in NDN takes more time than data encryption- and decryption-related steps. Thus, reducing the key size can further reduce the time spent on packaging and communication in the NDN, which further reduces the overhead of decryption.

6.3. Security Analysis

In this section, we analyze the security of our method. We focus on privacy protection and access control in NDN, which includes four security objectives: (i) data security: data security is built into the data themselves and is not dependent on the recipient. (ii) data integrity: the data need to prove their origin; they cannot be altered once created; and (iv) access control: only authorized data processors can access the data. Next, we analyze the objectives and the corresponding attacks in theory and practice. Note that the attacks associated with routing in NDN networks are beyond our scope.

6.3.1. Data Security

NDN relies on WKD-IBE for data security. The WKD-IBE scheme is IND-sWKID-CAP security, described as follows.

Theorem 1. 

A WKD-IBE scheme is indistinguishable under a selective-identity, chosen-plaintext attack, i.e., IND-sWKID-CAP secure (Indistinguishability against Selective-Identity with Wildcard Key, Chosen-Plaintext Attack), if and only if for all probabilistic polynomial-time attacker $\mathcal{A}$ whose advantage of winning the following game interacting with challenger C is negligible for the security parameter k [6].

$Initialization.$ Give the depth of the namespace ℓ and security parameter k, C run $Setup$ to generate the public parameters $Params$ and the master key $MasterKey$, and then $\mathcal{A}$ obtains $Params$ from the blockchain.

$Query1.$ $\mathcal{A}$ asks C for the keys of its sub-namespace. In the ith query, $\mathcal{A}$ adaptively selects a sub-namespace s. C runs $KeyDer$ to generate $s{k}_s$ and sends it to $\mathcal{A}$.

$Challenge.$ $\mathcal{A}$ chooses two messages, $m_0$ and $m_1$, with the same length and sends them to C. Then, C chooses a random bit $b\in \left\{0,1\right\}$, encrypts $m_b$ under the pattern p, runs $Enc(Params,p,m_b)$, and sends the generated ciphertexts to $\mathcal{A}$.

$Query2.$ $\mathcal{A}$ can continue to query like Query 1.

$Guess.$ $\mathcal{A}$ outputs guess $b^{\prime }$. if $b=b^{\prime }$, $\mathcal{A}$ wins the game. The advantage of $\mathcal{A}$ is $\left|Pr\left[b=b^{\prime }\right]-\frac{1}{2}\right|$.

Analysis. Based on the IND-sWKID-CAP security guarantee, we analyze data security in NDN. In $Initialization$, each data subject initializes $MasterKey$ and $Params$, respectively, and $MasterKey$ remains private while $Params$ is propagated by the blockchain, avoiding single-point-failure attack. In the data encryption phase, IoT devices only encrypt the data but cannot access decryption keys. The decryption keys are also not shared with storage services, intermediate nodes, or authorization services. Then, an A $Query$ step is performed by $\mathcal{A}$, and we divide it into two cases. The first case assumes that $\mathcal{A}$ is a non-authorized user. $\mathcal{A}$ will request the authorization service to obtain an access token before requesting the decryption keys. However, $\mathcal{A}$ is not qualified to obtain that token and, thus, not eligible to request the decryption keys. The second case assumes that $\mathcal{A}$ is a user authorized by a data subject. $\mathcal{A}$ obtains an access token and requests the decryption key. Additionally, $\mathcal{A}$ wants to obtain decryption keys outside the authorized scope. However, the token for the keys only supports $Query$ once, and does not perform continuous querying. Thus, attacker $\mathcal{A}$ does not have the opportunity to perform an ongoing $Query$, so it is challenging to perform a successful $Guess$.

Accordingly, our method guarantees data confidentiality in the NDN and can block constant attempts by attackers. Furthermore, even if the key of the sub-namespace is compromised, the data storage node will validate the data access token to check whether it is an authorized user. Taking a further step back, even if both the key access token and the data access token are compromised, the attacker can only access data in that sub-namespace scope within the token’s validity time.

6.3.2. Data Integrity

The integrity guarantees can be formalized using a game similar to Theorem 1. We do not repeat the description here.

Analysis. Our method is based on WKD-IBE to guarantee data integrity. The data subject allocates to each IoT device a signing key certificate associated with the authorized sub-namespace. Then, the devices put their signing key name into each NDN’s packet before publishing. The data processor can verify the signature, which prevents the message from being tampered with or forged. Therefore, the authentication mechanism of each packet prevents the malicious tampering of the message by man-in-the-middle attacks.

6.3.3. Access Control

The standard blockchain threat model assumes that the blockchain network is secure if an adversary cannot control a large percentage of nodes.

Analysis. NDNs are named after content and need to add access control to the content to establish a relationship with authorized consumers. Our approach is based on the blockchain to provide a decentralized authorization service. The decentralized nature of the blockchain ensures that an adversary cannot compromise the blockchain network to make unauthorized changes to the ledger. In addition, if the authorized token is compromised during transmission, a secondary verification mechanism can reconfirm it to prevent compromise, which alleviates token impersonation attacks.

7. Conclusions and Future Work

This paper introduces NACDA, a decentralized access control framework based on NDN. It enables data subjects to share their data autonomously and securely in a many-to-many communication scenario. Specifically, the named-based access control model provides encryption and access control schemes that decouple data subjects and processors, enabling secure, flexible, and selective data sharing. The decentralized authorization mechanism solves the problem of a single point of failure for NDN data retrieval and authorization services, allowing data subjects to customize access policies. Our experimental results and security analysis indicate the feasibility and applicability of NACDA in many-to-many communication scenarios.

There are two aspects to be improved. Firstly, NDN’s naming concerns data semantics and access control. An attacker may infer sensitive information about a user by monitoring the user’s requests. Therefore, the main challenge for naming is maintaining name privacy while ensuring the routability and decodability. Secondly, blockchain immutability provides the ability to audit authorization records to verify users’ compliance with GDPR. However, there exists conflict between the immutability of recorded transactions and the GDPR’s ‘right to be forgotten’. The above-mentioned decodability can be a way to mitigate that conflict since the ‘right to be forgotten’ is associated with the ability to decode a namespace on the ledger.