DUCEx: Enabling Efficient Deployment of the DUCE Data-Sharing Model for IoT
Abstract
The Internet of Things (IoT) is increasingly becoming a ubiquitous computing service, wherein data storage and sharing are outsourced to multiple cloud providers, considering IoT’s resource-constrained, self-organizing networks and short-range communication characteristics. Recently, DUCE, a distributed usage control enforcement model, was proposed to mitigate the privacy concerns brought about by the loss of control over sharing data. DUCE utilizes blockchain and trusted execution environment (TEE) technologies to achieve reliable and continuous life-cycle enforcement for cross-domain data-sharing scenarios. However, the requirement that maintains an individual TEE in each application agent makes DUCE deployment difficult, and data transferring to the application makes for less trustworthy usage. In this paper, we propose an alternate architecture called DUCEx to support the functionality of DUCE; nevertheless, DUCEx constructs the TEE via commitments of blockchain rather than one-to-one correspondence with application agents. Further, the policy administration point is also distributed and controlled by the data owner, who can modify the rules anywhere and anytime. The eXtensible Access Control Markup Language (XACML) expression rules are parsed and enforced as the smart contract at run time. A detailed explanation of the enforcement process is given for a typical example of the “delete-after-use” rule subsequently. By using Intel Software Guard eXtensions (SGX) to implement the prototype system, the experimental results show that DUCEx achieves a more trustworthy usage than DUCE and is easier to deploy along with appropriate performance. We believe our study will contribute to building secure, scalable, and privacy-preserving infrastructure for the IoT era.
1. Introduction
The Internet of Things (IoT) extends the boundary of the familiar Internet by incorporating smart physical objects (things) embedded with sensors, actuators, software, and communication hardware, for the purpose of connecting and exchanging data with other devices and systems [1–3]. The emerging trend of cloud edge–enabled IoT introduces a new computing paradigm. In this paradigm, cloud computing services are leveraged to provide convenient access to online applications and services. IoT services enable the sensing and control of the physical world, facilitating increasingly comprehensive data interactions that empower “smarter” applications for end users. With IoT applications encompassing a diverse range of consumer, industrial, and professional scenarios, the growing trend of data sharing among IoT carries immense potential and may even shape the future of the Internet [4].
However, cloud-enabled IoT presents significant privacy concerns, especially in consumer-oriented applications such as home IoT [5–7]. To address these concerns, the distributed usage control enforcement model DUCE was recently proposed [8]. DUCE explicitly addresses scenarios where the IoT device data are hosted by cloud servers, and any entity seeking to access these data must be authorized by the user and even be under the user’s control. This enables the sharing of sensitive and private data along with the ability to enforce policies such as the “Rights to erasure” in the General Data Protection Regulation (GDPR) [9]. DUCE utilizes trusted execution environment (TEE) technology to address the limitation of traditional access control mechanisms, which can prevent data leakage during access but cannot restrict, control, and monitor external applications once the data are shared. DUCE is an appropriate privacy-preserving mechanism developed to mitigate the limitations and realize the true potential of such data sharing. Nevertheless, the requirement of an individual TEE in each application agent makes deployment difficult. Furthermore, essential data transfer from data stores to the data consumer makes for a less trustworthy use. DUCE is further discussed in Section 4.
- 1.
A design overview of DUCEx is provided, highlighting the system components, which include distributed policy decision/enforcement points (PDPs/PEPs) and trusted applications (TAs) in TEEs. DUCEx utilizes permissioned blockchain technology to establish a trusted relationship between data-sharing parties, ensuring that the rules and enforcement records are tamper-proof and visible to users. TEEs, constructed through the commitment of blockchain, guarantee a trustworthy enforcement process for rules and enable users to maintain control over the data usage. These two aspects effectively eliminate privacy concerns related to data leakage and unauthorized access.
- 2.
The policy administration model also is provided and illustrated with the example of “delete-after-use” in the eXtensible Access Control Markup Language (XACML). Such XACML policies are automatically translated into smart contracts in the Solidity language for enforcement, and policies in smart contract format support distributed and automatic enforcement without the need for centralized trusted authorities.
- 3.
The critical enforcement process of the above example data-sharing access is demonstrated, which consists of initialized preparation and detailed defense against usage violations via multiple cloud services.
- 4.
A prototype system is implemented and deployed using a permissioned blockchain system named fisco-bcos and a TEE called Intel Software Guard eXtensions (SGX). The end-to-end delay and throughput of the system are evaluated and analyzed by comparing with those of DUCE and the OAuth 2.0 system, and the results demonstrate the viability and scalability.
The remainder of the paper is structured as follows. Section 2 reviews essential background technical concepts. Section 3 provides a typical user scenario with the problem statement and the design goals of our solution. Then, DUCEx model is illustrated in Section 4, including its administrative model, detailed enforcement process, and feature analysis. The prototype of implementation is demonstrated, along with the evaluation of the experimental results in Section 5. Related work is summarized in Section 6, and finally, Section 7 concludes the paper.
2. Background
In this section, we review the foundational technologies of DUCEx, including XACML, usage control, IoT architecture, blockchain technology, and TEE.
2.1. Access Control
2.1.1. XACML
XACML is a specification language provided by OASIS [10] for defining and enforcing access control policies to system resources. For modularity and fine-grained access control, XACML organizes policies into several components, namely, PolicySet, Policy, Rule. A PolicySet is a collection of other PolicySets or Policies, whereas a Policy consists of one or more Rules. Each Rule is the minimum component of an XACML policy and can either grant or deny access. Every policy applies to a specific target while matching a request. An example of a specific usage control policy rule is explained in Section Model.
2.1.2. Usage CONtrol Model (UCON)
The essence of access control decision in any access control model [11] is a triple (s, o, r), which denotes the subject s ∈ S exercising a right r ∈ R for object o ∈ O. The enforcement model based on the policies of the access control model covers components of PDPs, PEPs, policy administration points (PAPs), policy retrieval points (PRPs), and policy information points (PIPs). Specifically, PDPs are the system components in charge of policy evaluation and authorization decision supply, which make decisions on access requests forwarded from PEPs using the policy obtained from PAP/PRP and the additional information obtained from the PIP. Different from traditional access control models [11] that deal with authorization as the sole basis for access decisions and typically focus only on server-side controls, the usage control model [12–14], i.e., UCONABC, enables mutability of subject and object attributes, as well as continuity of control on the usage of digital resource and focuses on both server-side and client-side controls. UCONABC comprises eight core components, subjects, subject attributes, objects, object attributes, rights, authorizations, obligations, and conditions. The three functional predicates are evaluated for usage decisions, in which “authorizations” denote specific rights that subjects may exercise, “obligations” denote actions that subjects must perform, and “conditions” denote criteria influenced only by the administration.
2.2. IoT
According to most of the researcher’s consensus, IoT architecture [15, 16] is considered to comprise the perception layer, network layer, and application layer and has been utilized in various fields such as business, government, academia, and industry, as shown in Figure 1. The perception layer is a physical layer organizing environmental information sensors in charge of identifying objects and collecting information, such as QR codes/RFID tags and readers, cameras, and GPS. The network layer connects to intelligent network devices and servers for transmitting and processing sensor data via heterogeneous communication networks. The application layer provides users with specific application services and defines different applications for IoT, such as smart homes, cities, and intelligent health.
The three-tier architecture defines the core idea of IoT, in which the information transmitted among layers is mutual, interactive, and diverse. Thus, the data of things, such as identifiers and static/dynamic information, play an essential role in a specific application system. Moreover, IoT devices are typically resource-constrained and close to data provenance, while cloud computing provides elastic storage, computing, and analysis. Therefore, the emerging and widely used architecture integrates the IoT and cloud, wherein service providers expand services and applications via the Internet on existing foundations based on the above basic IoT.
2.3. Distributed Ledger Technology (Blockchain)
Blockchain [17] is the technology linking records expressed as blocks on a chain through cryptography, deployed to address the double-spending and currency generation problems of Bitcoin cryptocurrency [18]. Each block contains a cryptographic hash of the previous block, time-stamp, and transaction data expressed as Merkle tree. For use as a distributed ledger, nodes in blockchain systems are usually managed by the peer-to-peer (p2p) network and encouraged to follow protocols for communicating and validating new blocks by incentives. Since the records on the ledger are unalterable due to combining cryptography, consensus mechanisms, and the p2p network, blockchain is assuredly secure and considered a distributed computing system with high Byzantine fault tolerance. As a decentralized infrastructure and distributed computing paradigm with characteristics of tamper-proof, traceability, and joint maintenance by multiple parties, blockchain can build a trustworthy relationship between participants and has considerable promise for future IoT systems’ construction. As an autonomous application program running in isolated virtual machines on blockchain systems, the smart contract provides a novel mechanism to manage interaction rules and autonomously implement them between participants. Even though there is no supervision of centralized authority, the structure and value of smart contracts cannot change made by participants without consensus.
2.4. TEE
A TEE [19] is a secure area of the host processor that guarantees the confidentiality and integrity of information, such as code and data loaded and TAs running inside. By implementing unique, immutable, and confidential architectural security, such as Intel SGX, ARM TrustZone [19], AMD SEV, and Apple SEP, TEE offers hardware-based memory encryption that isolates specific application codes and data in memory. A complete function call usually originates from a client application (CA) in a rich execution environment (REE), is subsequently implemented by the TA, and ends with a data return. Specifically, several frameworks are implemented based on X86 and ARM architecture, which apply to specific scenarios. We use more stable SGX in the cloud server to maintain the same choice as most researchers in our experiments.
3. Problem Statement and Design Goals
In this section, we first discuss a typical use case scenario for IoT data sharing, then analyze the general problem, and finally state our design goals.
3.1. A User Scenario for IoT Data Sharing
Consider a typical citizen Alice who acquires a wristband for sensing her health data such as heartbeat, exercise, and sleep. Subsequently, under her control, she expects that the wristband platform shares the wristband data with a professional institute to get a professional report since the wristband platform merely provides data storage and primary computing services. There are sensitive elements in the wristband data. As stipulated in article 17 of the GDPR, i.e., “Rights to erasure,” users have the right to require forgetting their data. Accordingly, Alice expects the data to be deleted immediately after use by the application platform. In the current system, data usage must comply with Alice′s will, with unauthorized copying or sharing strictly prohibited. We clarify that solutions to such requirements impose some perimeter restriction whereby all the data processing happens within the perimeter. In particular, analog hole operations, such as taking screen photos or manually copying data, are beyond the scope of purely technical solutions.
Figure 2 demonstrates the process for the satisfaction above. The wristband data are uploaded constantly to the device platform. Subsequently, a click event on Alice’s smartphone launches a health report request, which triggers the professional institute’s application platform to send data requests to the device platform, as shown in steps a and b. After receiving the request, the device platform indicates a visualized view without ambiguity to Alice for authorization in step c. Then, the request redirects the interface back to the application along with the permission, as indicated in step d. The successful authorization allows the data to be communicated and shared with the application platform in step e. Finally, the data are used for computing and analysis to generate the health report returning to Alice in step f.
3.2. Problem Statement
In the above scenario, Alice wants a professional analysis report of her health, which is a task that a device platform or a general data storage party cannot fulfill. Thus, users expect to share the data with a third party, such as a health institution. However, users lose control once sharing within a distributed architecture. Moreover, Alice wants continued control wherein a “delete-after-use” rule is defined. Therefore, due to an untrustworthy relationship between participants, users cannot be sure whether the application platform follows the rules. Also, the application platform cannot prove to users that they did not break the rules or breach user privacy.
3.3. Design Goals
A trustworthy relationship between participants drives to prevent privacy compromises and keep the usage fully visible and absolutely under user control. It motivates our goals to achieve distributed control and design a privacy-preserving enforcement model which provides constant control and visibility for end users to share IoT data. Moreover, being easy to deploy is essential for enabling solutions in the IoT context.
3.3.1. Distributed Control
The crucial challenges and desired traits in distributed control include distributed administration, decision making, and enforcement. Distributed administration means that the entire life cycle of policy referenced by a control system should be managed in distributed ways so that end users can define and modify authorization/revocation anytime and anywhere. Distributed decision making requires decisions made jointly by independent and isolated parties to be predictable and reproducible to assure authenticity. Distributed enforcement not only requires that the specific actions correspond to the overall decision completed by distributed entities but also requires the integrity of decisions received from others and the secrecy of the results.
3.3.2. Continuity of Control and Visibility
Further, the solution provides continuous service to end users with privacy-preserving, integrity protection, and traceability. Specifically, privacy-preserving requires that both shared user data and keys in authorization should be prevented from external leakage. Integrity protection requires that the policy administrated by users and enforcement records should not be tampered with. Traceability requires trails to be traceable and visible to the user through enforcement records.
3.3.3. Efficient Deployment
Given the characteristics of IoT devices, the goal enforcement model should be convenient for implementation and deployment. Achieving privacy-preserving distributed usage control requires a minimal and necessary incremental design built on existing IoT systems while being amenable to customized deployment.
4. The DUCEx Model for IoT
In this section, we present the overview of the design followed by details on its various components. Subsequently, we develop an administration model to configure the enforcement model. Lastly, we give a feature analysis of the model after an illustrated enforcement process in the IoT scenario.
4.1. Overview of Model
We make full use of the natural strengths exhibited by blockchain in building trust relationships between data-related parties and the smart contract running environment. Further, the privacy protection in the whole process of user data is provided by using TEE, so that the transparency of the blockchain only acts on the enforcement record, to avoid the performance burden caused by data transmission upon the blockchain. For the sake of simplicity, the overview model is divided into three phases, as shown in Figure 3. Administration involves component PAP, which is mainly responsible for policy definition and management. Decision-making components include PRP, PIP providing policy and attributes for decision making, and distributed policy decision point (dPDP), which is responsible for decision making after receiving requests and responding to PEP based on the relevant decision and information. Enforcement is affected by the components PEP and TEE, including decision enforcement, usage, rule enforcement, and notifications/alerts for end users.
Recently, a trusted and distributed enforcement model, namely DUCE [8], was proposed utilizing blockchain technology to achieve the first two goals, i.e., distributed control and continuity of control and visibility. As shown in Figure 4(a), DUCE leverages a blockchain service to construct a trusted and distributed architecture among orchestrated participants (viz., entities who maintain blockchain nodes or use blockchain clients). After the XACML-based policy is translated into smart contracts and stored upon the duplicated policy repository of nodes, the dPDP, composed of PDPsacross all nodes, queries for consistent policies and enforces policy evaluation via smart contract execution. Due to the blockchain characteristics, policy administration and decision making ensure consistent effects from distributed decisions. TEE provides runtime environment with privacy-preserving for the smart contract–based policy enforcement to avoid the leakage of user sensitive data. However, a disadvantage of this architecture that detracts from the third goal of efficient deployment is the strong requirement of individual TEE in application agent.
To achieve the third goal of efficient deployment, we propose the alternate architecture of DUCEx, as shown in Figure 4(b), to achieve the functionality of DUCE while not requiring an individual TEE per application agent. The crucial difference between Figures 4(a) and 4(b) is on the lower right side of the diagrams. DUCEx allows aggregation of the TEEs in shared usage providers with the commitment of blockchain service. A shared usage provider is responsible for integrating usage services across multiple application agents. In the extreme case, every application agent, all as shared usage providers, provides unique TEE for aggregation, whereby the DUCEx architecture would be pruned to DUCE with commitments. Of course, only if multiple application agents utilize the same shared usage provider does the benefit of the DUCEx architecture accrues. Thus, the TEEs can be appropriately integrated with cloud, edge, or end services. Given the fragmented nature of these current IoT applications, the balance between security abilities and performance that should be considered by the application provider, and the requirements for the integrated application of intelligent models and the provision of personalized services by device providers, a common IoT application involves decentralized IoT data, confidential models, and expensive TEEs. The lightweight, incremental, and pluggable trusted usage service (TAs) provided by DUCEx can reduce the whole cost just through the trustworthy relationship. In the application agent, it is worth noting that the decision making and enforcement in both DUCE and DUCEx are continuous within the usage process. Moreover, usage violations will trigger denied decisions, which block the usage process, deny output results, send notifications to the user, and destroy all relevant data to prevent privacy leakage.
4.2. System Components
- •
PAP is a component responsible for management and storage service during the evaluation process of requests. Meanwhile, PAP helps decision makers to define and modify policies or perform other complex and related policy management actions. In our design, PAP translates the rules expressed by XACML into smart contracts for policy administration and storage in step ⑤.
- •
PRP is where the policies coding in smart contracts maintained via blockchain service are stored and fetched by the dPDP in step ⑥.
- •
PIP serves as the static/dynamic source of subject and object attributes, obligation, and environmental condition data required for policy evaluation to provide the information needed by the dPDP in step ⑦ to make authorization, obligation, and condition decisions. PIP deploys as interactive interfaces between diversified attribute managers. Offering attribute retrieval and update services, PIP can provide attribute sets required for evaluation and collected via different attribute managers and protocols.
- •
dPDP is an adjudicator who makes decisions (i.e., permit or deny) after evaluating the applicable rules in step ⑧ based on the collective information provided by PIP and PRP and returns the distributed decision evaluated via applicable rules administrated in the smart contract by different blockchain nodes to PEPs in step ⑨.
- •
PEP is a component coupled with protected resources (i.e., the user data stored in a data store), which can forward usage requests initiated by accessing subjects to trigger a decision regarding the access request via available attributes in steps ③-④ and then enforce the decision returned by dPDP in steps ⑨-⑩. Finally, the data are shared with PEP for calculation and usage as allowed, as shown in steps ⑪ of DUCE and ⑪-⑫ of DUCEx. In DUCEx, the PEP is a distributed engine to enforce usage requests and perform specific decisions for user data. Additionally, the PEPs incorporate the TEE which plays the role of usage guard in an entire usage policy decision-making process and manages usage workflow by interacting with all other components. In the TEE of PEPs, the TA provides trusted agents/applications for usage and enforces specific operations in steps ⑫ of DUCE and ⑬ of DUCEx to meet the rule, e.g., delete the data after usage. TA interacts with an external untrusted environment to get the data and keys for use and send results to the user for notification or alert in steps ⑬ of DUCE and ⑭ of DUCEx.
- •
Data store is a custodian of the resources that transfers the data to the encrypted data store for TA usage. Specifically, the resources in the data store, e.g., the encrypted data that IoT devices collected, the encrypted algorithms that the application provided, the encrypted services that the developer shared, etc., cannot be disclosed to unauthorized subjects.
- •
Data owner is the owner or issuer of the resource who has the right to control the usage of the resources via defined XACML-based rules and wishes to ensure his/her privacy. The data owner can initiate a data usage request through the application via the smartphone in steps ①-②.
- •
Data consumer is responsible for offering users customized applications by providing trusted algorithms for the TA to use. An application initializes usage requests with its authentication credentials. It provides algorithms that access protected data in the TEE of a shared usage provider.
- •
Shared usage providers are responsible for integrating usage services across multiple application agents with the commitment of blockchain service. Each shared usage provider includes a TEE. In this manner, a single TEE in a shared usage provider, like a service sharding, can serve various applications to reduce the number of TEEs required relative to the number of applications.
- •
Blockchain service provides distributed usage control services to keep a continuity of control for users. As a distributed policy decision service, blockchain nodes provide policy administration services, including policy definition, translation, execution, distributed decision services to allow or deny requests, and the trusted environment in policy enforcement services to prevent violations from the usage process.
The requirement of an individual TEE in each application agent makes DUCE deployment difficult. DUCEx removes this requirement and breaks the limitation of isolated trusted usage services, enabling a shared service with distributed control. Different from DUCE, DUCEx integrates the shared usage service through TEE/TA combination, which adds an algorithm transferring step in ⑪. Notably, there is no trust between applications leveraging blockchain service to maneuver the distributed usage in TEEs.
4.3. Administrating the Model
We use DUCEx to realize usage control. Particularly, policies are translated into smart contracts by the PAP so that the dPDP can execute the smart contracts [20] to make usage decisions.
4.3.1. Policy Administration
XACML standard is currently the most popular language to express attribute-based access control policy. The core components of UCON include subject attributes and object attributes. Therefore, XACML is used to help data owners to define policy. A “delete-after-use” example of XACML-based UCON policy is shown in Algorithm 1.
-
Algorithm 1: XACML-based usage control policy.
-
<Policy PolicyID = “UCONPolicy”>
-
<Rule Effect = “Permit” RuleID = “usage-data-consumer-rule”>
-
<Target><AllOf>
-
<Match MatchID = “urn:oasis:names:tc:xacml:1.0:function:date-greater-than”>
-
<AttributeValue
-
DataType = “https://www.w3.org/2001/XMLSchema#date”> 2024-02-22
-
</AttributeValue>
-
<AttributeDesignator
-
AttributeId = “urn:oasis:names:tc:xacml:1.0:resource: data-collected-date”
-
Category = “urn:oasis:names:tc:xacml:3.0:attribute-category:wristband”
-
DataType = “https://www.w3.org/2001/XMLSchema#date”
-
Issuer = “ID-data-owner”
-
DeleteAfterUse = “true”
-
UsageCondition = “ID-TEE”/>
-
</Match>
-
</AllOf></Target>
-
</Rule>
-
</Policy>
In Algorithm 1, “UCONPolicy” identifies the policy, which consists of multiple rules “Rule.” A Rule identified by RuleID and the specific effect “Permit” consists of multiple “Targets” representing the user-defined scope of specific subjects. For example, AllOf means all subjects that meet the following conditions, whereas TopOf means the first subject, etc. Then, the Match identified by MatchID represents a specific object and usage permission, like an object filter. For instance, “date-greater-than” is a function to retrieve the user data with the creation and updating date which meets the condition, and parameters include tags AttributeValue and AttributeDesignator. AttributeValue defines attribute value used as an actual parameter, i.e., date greater than 2024-02-22. AttributeDesignator represents how to single out a specific object. The parameters include tag AttributeId, which refers to the resource attributes; tag Category, which describes the resource category; tag DataType, which refers to the resource type; tag Issuer, which refers to the rule maker or authorizer (viz., data owner); tag DeleteAfterUse, which refers to the obligation functional predicate “delete-after-use”; and tag UsageCondition, which refers to the condition predicate “in trusted computing environment.” In short, this example UCON policy briefly describes that the data owner grants the “Permit” permission to the subject who obeys the two conditions “delete the data after use” and “use and delete in a trusted computing environment” and the data consumer is allowed to use the data in “wristband” category and after the date “2024-02-22.”
4.3.2. Policy Execution
We use blockchain service to make participants trust each other in DUCEx. The smart contract is a core component that supports trusted and distributed policy decision-making services utilizing blockchain technology. It ensures the functionality and security of policy through the automated execution and evaluation of smart contracts. Algorithm 2 depicts the steps taken by the policy administrator for defining and publishing a new rule to the blockchain based on the above-shown policy. Firstly, the rule and the corresponding authorized subject s are obtained from the parsing of the XACML file. Line 4 shows the locating of the approximate usage object by using the parameter to retrieve and then assigns the result to res′. Starting from line 5, iterating the result returned by the previous step, the function assigns the data that meet the conditions to the object o and then records the obligation functional predicate, condition predicate, and permissions, respectively, into b, c, r, which implies the successful parsing of the XACML file. Starting from line 11, the issuer invokes the function constructSC( ) to construct a smart contract data structure and instantiate a rule manager. If the data processed in the uconManager do not exceed the scope of o, r, and b, c is true, then “Permit” in the manager is updated to be true. Subsequently, the uconManager is assigned to the smart contract sc to return. Finally, the smart contract is published via blockchain service and waits for execution triggers to make data usage decisions.
-
Algorithm 2: UCON policy translation.
- 1.
procedureTRANSLATE(xa, sc) # translate a XACML file into a smart contract
- 2.
rule ⟵xa.Rule
- 3.
s ⟵rule.Target
- 4.
res′⟵retrieve (rule.{Category, AttributeID, AttributeValue, Issuer})
- 5.
whileres ∈ res′do traverse # traverse res to find the data
- 6.
if (res.AttributeValue ∈rule.MatchID) then
- 7.
o ∈ res. AttributeValue
- 8.
end if
- 9.
end while
- 10.
b⟵rule. DeleteAfterUse
- 11.
c⟵rule. UsageCondition
- 12.
r⟵rule. Effect # parse XACML file to object successfully
- 13.
sc⟵constructSC () # begin to construct a smart contract to load object
- 14.
uconManager⟵uconManagerContract (rule. Issuer)
- 15.
if (uconManager. AttributeValue ∈o) then
- 16.
if (r = = “Permit” && b = = “true” && c = = “true”) then
- 17.
uconManager. Permit ⟵ “true”
- 18.
else
- 19.
uconManager. Permit ⟵ “false”
- 20.
end if
- 21.
sc⟵uconManager
- 22.
end if
- 23.
returnsc # translate xacml file into a smart contract successfully
- 24.
end procedure
4.4. Enforcement Process
We follow the above “delete-after-use” rule as an example to describe distributed usage control in IoT and illustrate the overall enforcement process as the initialization phase and enforcement phase, as shown in Figure 5.
4.4.1. Initialization Phase
The initialization phase refers to preparing services, communication, and resources, specifically, the distributed policy decision services and usage ledger (viz., ledger for usage records storage), i.e., nodes of a permissioned blockchain; the agent of user and application (e.g., smartphone); and the communication ability, such as the p2p network or an internal protocol between entities. Moreover, the resources uploaded by devices should be prepared and retrievable in the resource store (e.g., the cloud or gateway of the IoT device platform). In this paper, to protect user privacy, we assume that the resources are encrypted for storage with user authorization using the Diffie–Hellman algorithm to negotiate keys between the device platform or end user and the TEE. Here, we omit further details of this phase and focus on the next enforcement phase.
4.4.2. Enforcement Process
- •
Authorization: Users customize the XACML file through the agent anytime and anywhere and send it to the transform module for translation. The translated rules in smart contracts are stored in the repository via online transactions for subsequent query and acquisition during distributed evaluation, as we explained in above section and shown in step ⑤.
- •
Request and authentication: After the cloud server receives a request from the application agent, it first validates the app’s credentials for authentication, such as a general account address. Once authenticated, the agent is required to provide relevant IoT contexts, such as attributes, which represent the success of the request and authentication, as shown in steps ①–④. Then, the request is recorded in the usage ledger to trigger the next segment (distributed decision making). It is worth mentioning that other blockchain nodes synchronize the current system state at any time, making the distributed cloud service upon blockchain nodes and the TEEs ready for distributed evaluation at any time.
- •
Query and decision making: This segment focuses on distributed usage decisions via smart contract execution. Specifically, “permit” or “deny” decisions are made individually and reach a consensus based on the rules retrieved from the stored policies, the contexts such as attributes of the data and application, the obligation obtained from the application (e.g., consent form for “delete-after-use”), and the trusted usage environment provided by the shared usage providers that can indeed verify the condition (i.e., “use in TEE”), as shown in steps ⑥–⑨.
- •
Enforcement and alert: This crucial segment enforces the decisions and guards against violations by monitoring for suspicious activities (see steps ⑩–⑬). The resources involved are transferred from the resource store (the IoT device platform) to the TEE (see step ⑫), and the algorithms are transferred from the application platform to the TAs (see step ⑪). We assume that all the sensitive processing occurs within the TEE.
- •
Revocation: Taking into account the dynamicity of our designed authorization model, we identify two alternative revocation modes. In the first mode, the user is alerted to redefine and update the rules each time a warning or alert is received. In the second mode, revocation is enforced automatically by defining the policy of constraint rules, such as timeout-based, limited frequency-based, and violation-based policy. Various scenario requirements entail different choices.
- •
Response and notification: Notification requirements are significant in privacy protection contexts. Essentially, as long as completing the computing of the user concerned within the TEE or monitoring any suspicious activities, the TEE or cloud service should send notifications to the user regardless of the use progress via blockchain service. The result should be reported to the application when completing all the above segments. If one of the above steps fails, the application should retrigger enforcement usage requests, as shown in steps ⑭-⑮. TAs specifically deny responding to the application with the computing results while the application violates the previously signed consent form for “delete-after-use.” Meanwhile, we log the violation upon the usage ledger and alert the user via the blockchain network to keep the visibility and controllability of the use process for the user.
4.5. Feature Analysis
This section explores the type of choice associated with permissionless and permissioned blockchains and some practice projects, seeking to establish that they apply to our model. And the feature of distributed usage control with security and privacy requirements and efficient deployment is analyzed.
4.5.1. Blockchain Service Support
Permissionless blockchains include trading cryptocurrencies such as Bitcoin, Litecoin, and Ethereum1, in which the hashing together of transaction blocks depends on the work of anonymous miners competing to solve through trial and error, a complex mathematical algorithm for that block of transactions, namely, consensus. Permissioned blockchains usually involve a consortium of organizations where transactions are blocked together and verified by authorized gatekeepers instead of anonymous miners. In general, the uncertain number of participants in a permissionless blockchain and the specific approach to consensus lead to inefficiencies. On the other hand, the transparency and temporality of authorization and control during processes guide the selection of permissioned chains that can run the smart contracts, such as Hyperledger, Fisco bcos2, Coco, Quorum, and Corda3. Developers choose different chains according to the performance requirements of their implementation scenarios.
4.5.2. Distributed Administration, Decisions, and Enforcement
For the policy administration, the policy defined as smart contracts for distributed storage on blockchain nodes ensures integrity. Also, users can authorize and revoke it anytime and anywhere. Then, the combination of component dPDP and blockchain service makes the decision making automatic and consensual while ensuring the integrity of the decisions communicated to PEPs. Finally, the enforcement process is authentic and credible by integrating TEEs with PEPs. The end user can enjoy continuous controllable and visible service with preventing sensitive IoT data from leakage during usage.
4.5.3. Security and Privacy Preserving
Due to the leverage of the permissioned blockchain for trust relationship construction, in our design, only the encrypted user data are stored in resource stores for sharing, and the keys for decryption only are issued through authorization provided via blockchain service. Moreover, user data can only be decrypted and used in a TEE. In strict compliance with a “delete-after-use” rule, the keys and data are deleted after use to prevent leakage. By fully utilizing the TEE, the keys cannot leak out even if the data are stolen, even though user data are cached in an external untrusted environment. Then, the distributed policy decision-making manner by executing rules in smart contracts meets the integrity protection requirement while recording the rule fetching and all interactions among entities upon for nontampered storage and execution on the blockchain. Once a violation occurs, smart contract is automatically triggered to alert and notify the user. Furthermore, on-chain records are used for violation auditing since traceability is an inherent feature of the blockchain.
4.5.4. Easy to Deploy
TEEs are separated from application platforms to form a shared trusted computing environment service. Since the data usage is no longer limited to the TEE of the application platform itself, the model deployment beomes easier, especially in the IoT environment where the basic systems are complete. Ultimately, applications that need to access target data can provide TEE to achieve cluster services, which is compatible with our previous work [8].
5. Performance Evaluation
In this section, we prototype DUCEx and evaluate the performance on a real testbed. Comparing our implementation with DUCE and OAuth 2.0 system (OAuth4) [8], we demonstrate acceptable overhead and scalability of our design.
5.1. Implementation
We prototype DUCEx by building the authentication, authorization, and processing of the data upon REST APIs invoked via Python code. In particular, Fisco bcos, an open-source permissioned blockchain based on Ethereum, is utilized to construct the blockchain service. Besides, we develop authentication and authorization using smart contracts and invoking the CRUD (which refers to the four basic operations a software application should be able to perform, including Create, Read, Update, and Delete) libraries. Intel SGX is chosen to process the incoming data for policy enforcement, invoking the BASE64 decoding library when the encrypted data and keys are transmitted into the enclave as input. Moreover, we set up flags to check for suspicious violations. Deleting the decrypted data and keys following the “delete-after-use” rule triggers smart contract execution to send notifications to users. For simplicity, the policy enforcement process above is referred to as “usage service” hereafter.
5.2. Experiment Setup
- •
The end-to-end delay measures the time consumption required from the end where the usage request or thread launches to the end where the processed result is returned.
- •
The throughput measures the maximum number of concurrent requests handled and responded to per second by DUCEx.
6. Experiment Results
We use our prototype to measure the performance, including delay, throughput, and scalability of DUCEx, averaging all experiment results after around hundred runs in total.
6.1. Delay
- •
Authentication delay: We measure the authentication delay with 20 concurrent requests. We observed that the time consumption is approximately the same in DUCE and DUCEx, while these models take around 14.5 ms more than OAuth.This indicates that leveraging blockchain incurs just a 2.7% overhead. Thus, authentication in DUCEx is efficient.
- •
Authorization delay: We measure the delay incurred by the authorization with 20 concurrent requests. As shown in Figure 6(a), DUCE, DUCEx, and OAuth incur similar delays. In particular, as discussed above, DUCEx can grant permissions in advance, so the authorization delay is significantly kept flat even using blockchain. Furthermore, authorization makes up more than 50% of the overall delay for a response.
- •
Delay incurred by usage service: We measure the delay incurred by the cloud-based usage service deployed with a single SGX node in DUCEx. Compared to the delay of the local usage services in OAuth and DUCE also deployed with a single SGX node, we observe that migrating the usage service from local to cloud deployment resulted in a roughly 60 ms delay increase. However, as the cloud usage service is easy to deploy, this over 11.5% delay is acceptable.
6.2. Throughput Performance
- •
Authentication throughput: We measure the authentication throughput with 2000 concurrent requests. DUCE and DUCEx have similar throughput. Compared to OAuth, the throughput in DUCEx is reduced by roughly 260 tps/s. Specifically, the compromise to handle cryptographical verification for secure authentication in DUCEx and DUCE causes around a 16.7% reduction in throughput. However, we can choose other efficient blockchains to mitigate the authentication throughput.
- •
Authorization throughput: Now we measure the authorization throughput with 200 concurrent requests. We find that DUCEx outperforms OAuth by about 48% throughput in authorization due to leveraging smart contracts on the blockchain.
- •
Throughput for usage service: We also measure the throughput for usage services. The throughput of usage service deployed with a single SGX node is almost the same as that without SGX, which demonstrates that the cloud-based deployment will not seriously impact the throughput.
6.3. Scalability
We also evaluate the DUCEx scalability. As shown in Figure 7, we measure the delay and throughput of DUCEx with the number of concurrent requests ranging from 100 to 1000 for different cloud-based SGX nodes from 1 to 4. The delay reduces with nodes (see Figure 7(a)). Obviously, DUCEx has over 5 times delay reduction with 2 nodes compared to a single node. Also, with 100 concurrent requests, the delay decreases by over 30% with the increase of the number of nodes from 3 to 4. Note that the delay with one node is relatively longer, which is incurred by SGX. Similarly, the throughput increases by over 38% when deploying an additional node, which indicates that the throughput of DUCEx can be significantly improved by increasing the number of SGX nodes (see Figure 7(b)). Therefore, we believe that more nodes can effectively improve the performance of DUCEx while incurring acceptable delays.
7. Related Work
7.1. Cryptography-Based Private IoT Data Protection
Cryptography techniques, such as encryption for storage and anonymization of sensitive information, are used to prevent the direct leakage of data from static storage [21, 22]. Specifically, leveraging blockchain technology tends to be a preference by academic and industrial designers, such as Microsoft, Amazon, and Google [23]. As discussed by Urooj [24], a novel algorithm has been developed that incorporates both techniques (Advanced Encryption Standard (AES) and ECC cryptography) along with clustering through standard LEACH protocol for improving energy efficiency, data security, and network lifetime. Patil et al. [25] designed a blockchain-based approach and declared that the security and complexity issues can be mitigated with improved electronic health record monitoring and administration. Parmar and Shah [26] proposed an IoT-blockchain lightweight cryptographic approach (IBLWC) to address the clock synchronization issue of IoT nodes with blockchain using a network time protocol and secure the entire IoT-blockchain ecosystem. Andersen et al. [27] presented an expressive authorization framework offering decentralized trust by storing permissions data in an untrusted storage solution to protect permissions.
7.2. Privacy-Preserving IoT Data Sharing
Many efforts have been made to mitigatedata leakage duringshared data transmission and computing, Fernández et al. [28] designed a data collection and sharing model based on the DataBank and Privasee platform, which focuses on data collection and sharing and considers privacy problems slightly. Nevertheless, we pay more attention to providing constant control of private data for users. Yin et al. [29] used sparse differential gradient to improve the raw data transmission and storage efficiency in federal learning training protecting the characteristics of the data and the weight of each participant in the weighted summation procedure. Shen et al. [30] designed evolutionary privacy preservation learning strategies and constructed a payoff matrix to address the data-sharing privacy exposure issue when IoT devices make malicious requests for filching sensitive information from a cloud storage system through edge nodes. Zhang and Fan [31] designed Cerberus by combining blockchain technology that provides distributed data deposition, and TEE maintains states while outsourcing data storage and off-chain computing to edge nodes.
7.3. Access Control for IoT Data Protection
Access control models have been extensively studied to ensure data access in the literature [32–36], and usage control models [37, 38] have been applied to ensure IoT data. By analyzing the probability distribution of optical signals, Meng [39] proposed a method to identify any potential security threats or anomalies in the communication channel, enabling the network to dynamically adapt its security measures and protocols to counteract unauthorized access attempts. Wu [40] proposed an attribute-based access control scheme which benefits from the smart contract technology while ensuring the privacy of attributes and policies, and an additive homomorphic cryptosystem is utilized to encrypt attributes and access policies. As discussed by Khalid et al. [41], smart contract is used to resolve the intricacy of policy management, forged policies, dissemination and tracking of access control policies, and implementing immutable, verifiable, adaptive, and automated access control policies for IoT devices. Similarly, we express our rules as smart contracts for decentralized storage and execution in DUCEx with the protection of sensitive data usage and permissions.
8. Conclusions
The trend of utilizing emerging blockchain or distributed ledger technology to build a trustworthy relationship between participants in a data-sharing scenario and prevent user privacy leakage is on the rise. While IoT device data contain sensitive information, combining cloud and edge computing with IoT can provide efficient services with privacy-preserving for users. In data-sharing scenarios, to address the problem that applications service or data consumer violates articles such as “Right to erasure” in GDPR and leads to user privacy disclosure, we propose DUCEx to support the functionality of DUCE [8], a distributed enforcement architecture with efficient deployment. DUCEx replaces the individual TEE in each application agent with shared TEEs backed by blockchain commitments. In DUCEx, distributed PDPs and PEPs enforce the distributed usage control policy defined in XACML to make decisions, while translating the policy into contracts for automatic execution. We demonstrate a detailed enforcement process and evaluate the performance and scalability of our prototype built upon Fisco bcos and SGX. However, the decision making of IoT scenarios requires massive attributes for support. Moreover, the limitation of TEEs requires providing only the most sensitive computing. Thus, in future work, we aim to work on a dynamic and efficient access control model for IoT with privacy-preserving.
Conflicts of Interest
The authors declare no conflicts of interest.
Author Contributions
Na Shi and Dejun Huang contributed equally to this manuscript.
Funding
There is no funding regarding this paper.
Endnotes
1https://bitcoin.org. https://litecoin.org. https://ethereum.org.
2https://www.hyperledger.org. http://www.fisco-bcos.org.
3https://github.com/Azure/coco-framework. https://www.corda.net/.
4OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service. The OAuth 2.0 system is built upon the OAuth authorization framework.
Open Research
Data Availability Statement
There is no need for providing available data since the experiment can be reproduced easily.
