A Symmetry-Enhanced Secure and Traceable Data Sharing Model Based on Decentralized Information Flow Control for the End–Edge–Cloud Paradigm

Abstract

The End–Edge–Cloud (EEC) paradigm hierarchically orchestrates Internet of Things (IoT) devices, edge nodes, and cloud, optimizing system performance for both delay-sensitive data and compute-intensive processing tasks. Securing IoT data sharing in the EEC-driven paradigm while maintaining data traceability poses critical challenges. In this paper we propose STDSM, a symmetry-enhanced secure and traceable data sharing model for the EEC-driven data sharing paradigm. STDSM enables IoT data owners to share data securely by attaching symmetric security labels (for secrecy and integrity) to their data. This mechanism symmetrically controls both data outflow and inflow. Furthermore, STDSM can also track data user identity. Subsequently, the security properties of STDSM, including data confidentiality, integrity, and identity traceability, are formally verified; the verification takes 280 ms, using a novel approach that combines High-Level Petri Net modeling with the satisfiability modulo theories library and the Z3 solver. In addition, our experimental results show that STDSM reduces time overhead by up to 15% while providing enhanced traceability.

1. Introduction

The proliferation of Internet of Things (IoT) [1] devices, including sensors, actuators, and mobile devices, has led to an exponential growth of data generated at the network edge. This trend is further amplified by the increasing deployment of data-intensive applications, such as those powered by artificial intelligence [2,3], that require timely processing and sharing of data.

In the era of IoT, data sharing mainly comprises the cloud-assisted IoT data sharing paradigm [4] or the edge-assisted IoT data sharing paradigm [5]. In the cloud-assisted IoT data sharing paradigm, data processing is delegated to cloud platforms; this overcomes resource restrictions through on-demand computing and massive data storage, yet it fails to answer the delay-sensitive requirements of IoT applications. Alternatively, in the edge-assisted IoT data sharing paradigm the collected data are transferred to the edge servers that provide delay-sensitive services to the users, the edge servers being located in proximity to the end IoT users. Nonetheless, edge servers exhibit constrained processing power and modest storage capacity, while excelling in low-latency computational tasks.

Accordingly, we are likely to see a hierarchical computing paradigm that could revolutionize the current cloud computing and edge computing architecture [6]. This consists of a large number of end IoT ends, distributed edge servers near the network edge, and the cloud center. As shown in Figure 1, the three-layer End–Edge–Cloud (EEC) paradigm requires synergistic operation across all layers to achieve optimal performance. This synergy enables both high-throughput processing and real-time responsiveness, meeting the evolving demands of data sharing.

From the perspective of data sharing in the EEC-driven paradigm, the end data owner first collects data using the sensors and then uploads that data to edge servers through the wireless network. In the edge layer, the edge servers store the uploaded data or transfer the data to the cloud according to the delay-sensitive characteristic of the data. That is, the edge servers will locally store and process the received data if the data are delay-sensitive. Otherwise, the data will be transferred to the cloud, which provides powerful capability for the data processing services for the ends. Moreover, the edge servers and cloud center also execute data sharing decisions to decide whether the requested data can be shared with the data users.

To ensure secure data sharing within the EEC-driven paradigm illustrated in Figure 1, the following three fundamental security properties must be preserved:

• Data confidentiality is essential, as the shared data often contain sensitive information. This property prevents unauthorized data users or malicious entities from accessing the data during its transmission and storage across the edge and cloud layers. By ensuring confidentiality, data owners will be willing to share their data.
• Data integrity guarantees the accuracy and reliability of data throughout the entire sharing process, from the original data owner to the end user. This ensures that the data has not been altered or tampered with, maintaining its trustworthiness.
• Identity traceability is equally critical, as it enables the system to track the identity of data users in the event of illegal access or for accountability purposes. This capability acts as a deterrent against misuse and provides a mechanism for forensic analysis should a security incident occur.

Accordingly, this paper proposes STDSM, a symmetry-enhanced secure and traceable data sharing model based on the decentralized information flow control (DIFC) model [7], for the EEC-driven secure data sharing paradigm. We believe STDSM is the first DIFC-based model specifically designed for the EEC paradigm that integrates symmetrical security labels (secrecy and integrity) to protect data confidentiality and integrity and also identity traceability via owner tags and trace data. This paper makes the following key contributions:

(1)

The confidentiality and integrity of the shared data are preserved:

To preserve data confidentiality and integrity, the secrecy label and integrity label are attached on the share data before the data are uploaded to the edge servers and the cloud center. Here, the secrecy label restricts read access for unauthorized users, while the integrity label blocks write operations by unauthorized users, thereby preserving data confidentiality and integrity.

(2)

Identity traceability is achieved by STDSM:

In order to achieve identity traceability, STDSM introduces the owner tag and trace data. Furthermore, owner tags serve as identifiers for both data owner and user, while trace data capture user identities during data sharing. When data sharing occurs, the data owner’s owner tag attached on the shared data and the owner tag of data user are used to generate trace data. Such trace data records data flow information, thereby enabling STDSM to enable identity traceability.

(3)

The security of STDSM is formally verified and performance evaluation is conducted:

To verify the security of STDSM, we employ a novel method that combines High-Level Petri Net (HLPN) modeling with the satisfiability modulo theories library (SMT-Lib) and the Z3 solver. This method implements bounded model checking [4] to validate STDSM. Our verification results show that STDSM has the capabilities of protecting data confidentiality and integrity, and it can also track data user identity. Our performance evaluation results show STDSM’s high efficiency compared with the related works.

Unlike prior works that often lack rigorous formal analysis for the DIFC-based model, we introduce a comprehensive verification method. This method utilizes HLPN for precise system modeling and employs SMT-Lib theories along with the Z3 solver for automated, rigorous verification of security properties. This methodological combination, applied specifically to a symmetric DIFC model, represents a novel contribution to the field.

The outline of this paper is as follows: Section 2 reviews the related works, and preliminaries are given in Section 3. Section 4 proposes STDSM and its workflows, Section 5 formally analyzes STDSM, Section 6 conducts performance evaluation of STDSM, and Section 7 concludes and discusses this paper.

2. Related Work

2.1. Secure Data Sharing in EEC Paradigm

As for secure data sharing in the EEC-driven paradigm, Ciphertext-Policy Attribute-Based Encryption (CP-ABE) [8], Proxy Re-encryption (PRE) [9], Identity-Based Encryption (IBE) [10], Blockchain [11], and smart contract [12,13] are usually used in the literature. Fan et al. [14] firstly presented a data sharing approach for the EEC paradigm, which achieves cross-domain data sharing. In this proposal, the cloud service provider is responsible for system initialization and facilitates cross-domain data sharing by precisely directing users to target domains. Lin et al. [15] utilized CP-ABE to prevent a revoked user from colluding with a non-revoked user. Ding et al. [16] proposed the LSHS system to secure IoT-based sharing. LSHS also supports lightweight edge-assisted data integrity verification and preserves the privacy of the patient’s identity. Nonetheless, LSHS does not focus on providing delay-sensitive data sharing services but on secure edge-assisted data storage. Based on homomorphic encryption [17], Zhang et al. [11] developed a blockchain-enabled data sharing framework for mobile edge computing (MEC) scenarios, where edge nodes are tasked with dual cryptographic operations while concurrently handling time-sensitive data processing and user service delivery. Additionally, the powerful data processing and analysis services are performed in the cloud center. The HDS framework [18] enables seamless regional and cross-regional data sharing in MEC environments through a dual-component design: (1) an optimized intra-region protocol for accelerated data localization, and (2) a single-hop geographic routing mechanism for efficient cross-region data access. For vehicular edge computing and networking [19], Zuo et al. [20] proposed to use blockchain securely stored data from autonomous vehicles across multiple edge nodes, reducing the risks associated with data transmission. In addition, Liu et al. [21] utilized the route hash-chain on vehicles’ driving routes to track data and achieve identity authentication.

Nonetheless, the aforementioned works entail complex cryptographic computation to achieve data confidentiality protection and identity traceability, causing high computation costs to the end data owner. Additionally, these works cannot achieve end-to-end data confidentiality and integrity protection.

2.2. Decentralized Information Flow Control

Alternatively, DIFC [22,23] enables data confidentiality and integrity protection through attaching security labels (i.e., secrecy and integrity labels) to the shared data; it also defines the enforceable information flow rules to restrict data sharing, preserving the end-to-end confidentiality and integrity of the data. In DIFC, every active distributed entity has corresponding privileges to manage its security context, which is suitable for securing data sharing in the EEC-driven scenario. Myers et al. [22] introduced the foundational DIFC model for decentralized environments, employing dual security classification (secrecy and integrity) to preserve both data confidentiality and integrity. Thereafter, DIFC-AC [24] was proposed to track data flow through attaching security labels on shared Pass data. Furthermore, DIFC-AC sets authorization conditions on security labels to restrict data access. However, the scalability of DIFC-AC is limited by the authorization conditions stipulated on the label. FlowK [25] and Camflow [7] constituted complementary information flow control systems in platform as the service (PaSS) cloud. While FlowK’s Pileus component maintained data confidentiality and integrity even in compromised cloud environments, Camflow specialized in three key areas: (1) application sand boxing, (2) cross-boundary data sharing, and (3) leakage mitigation. Nonetheless, FlowK and Camflow required operation system integration; consequently, they were nly suitable for PaSS cloud. Subsequently, Camflow was used for securing patients’ health data sharing in cloud-assisted IoT data sharing scenarios, presenting secure-Camflow [26]. By leveraging the DIFC model, Lu et al. [27] proposed the DIFCS scheme to secure data sharing in cross-cloud data sharing scenarios. The DIFCS scheme also demonstrated that DIFC-based approaches have less computation cost compared with encryption-based approaches, to some degree. However, DIFCS is only suitable for data sharing scenarios in multi-clouds. In summary, the comprehensive comparisons of the aforementioned works are shown in

Table 1. Mechanistic comparison of traceability support in DIFC models.

Model/Scheme	Core Enforcement Mechanism	Application Scenario
DIFC-AC [24]	security labels + authorization conditions	PaaS cloud
FlowK [25]	security Labels + OS-level enforcement	PaaS cloud
Camflow [7]	security labels + OS-level enforcement	PaaS cloud
Secure-Camflow [26]	security labels + cryptography	Cloud-assisted IoT
DIFCS [27]	security labels + privilege delegation	Multi-clouds
STDSM (Ours)	symmetrical labels + owner tags	EEC Paradigm

.

Nevertheless, current DIFC-based methods in data sharing scenarios exhibit two critical limitations: absence of identity-tracking mechanisms and lack of theoretical analysis of their security properties. Accordingly, the main purposes of this paper are addressing identity traceability using DIFC to secure data sharing in the EEC-driven paradigm and providing a novel theory analysis method to prove the security properties for DIFC-based schemes.

3. Preliminaries

This section mainly introduces HLPN, SMT-Lib, and Z3 solver, which are used to formally analyze and verify the security of STDSM in this paper. In addition, they are also used to prove the security property of the proposals, such as the xDAuth protocol [28] and the CTAC model [29].

3.1. High-Level Petri Net

Although Petri Nets [30,31] are broadly applicable for system modeling, their graphical representation suffers from scalability issues when applied to complex systems, manifesting as exponential growth in component count. To address these limitations, HLPN [4,27,32,33], was introduced as an advanced modeling formalism. This semi-graphical technique enhances traditional Petri Nets through three key innovations: (1) abstraction via high-level data structures as tokens, (2) algebraic annotation of network components, and (3) integrated support for system specification, design, and verification. In this paper, HLPN is also used for formally modeling and analyzing STDSM, in which the definition of HLPN is introduced as detailed in our previous works [4,27].

3.2. SMT-Lib and Z3 Solver

The satisfiability modulo theory (SMT) [4] constitutes a specialized branch of automated reasoning that investigates the decidability of first-order logical expressions. The SMT framework examines formulaic instances in first-order predicate calculus where function and predicate symbols may possess context-dependent semantic interpretations. At its core, this paradigm addresses the fundamental decision problem of establishing solution existence for such constrained logical expressions. Through domain-specific theoretical restrictions—particularly though not exhaustively applied to quantifier-free formula classes—these dedicated techniques enable solver implementations demonstrating superior computational efficiency compared to universal theorem-proving systems. Within computing science, SMT finds extensive application across diverse domains including but not limited to automated planning protocols, formal model verification, and systematic test case synthesis.

SMT-Lib [34] establishes a unified specification language and evaluation infrastructure for satisfiability modulo theories implementations. This framework supplies foundational logical theories—including array, bit-vector, and finite set formalisms—that underpin SMT problem formulations. Modern SMT solvers accept as input both a target theory and the corresponding logical formula f, subsequently determining f’s satisfiability within the specified theoretical constraints. Our verification methodology employs the Z3 theorem prover [35] in conjunction with SMT-Lib’s array theory constructs, leveraging Z3’s demonstrated efficiency in formal verification tasks to analyze the STDSM model.

4. STDSM

At first, this section presents the STDSM model, in which the elements and corresponding rules are defined and designed, respectively. Subsequently, the EEC-driven data sharing paradigm is formally modeled using STDSM. The workflows of STDSM in the EEC-driven data sharing paradigm are finally depicted.

4.1. Model Description

This subsection describes STDSM as follows:

Entity. Entity consists of subject and object. In STDSM, subject means the end data owners and end data users. Object refers to the accessed or shared data. For example, in an EEC-driven e-health system, the patients’ health data are the objects, and patients and medical persons are the subjects. In the EEC scenario, edge servers and the cloud server are the subjects. In particular, an active subject can create a new subject or object.

Tag and label. Tags, denoted by t, are defined as random characters, which means some security properties of secrecy or integrity. Tags have no inherent meaning until they are assigned to the corresponding secrecy or integrity labels, denoted by L. In STDSM, an entity is associated with a symmetric pair of security labels ($L_S$ for secrecy and $L_I$ for integrity) and an owner tag ($t_O$). This symmetry between secrecy and integrity is fundamental: the secrecy label symmetrically restricts read access, while the integrity label symmetrically restricts write operations, thereby providing a balanced and comprehensive protection mechanism. The strength of IFC lies in its ability to ensure that aspects of the security context do not interfere [7] with each other.

Owner tag and trace data. Owner tag, denoted by $t_O$, is used to mark the owner. It is also used to record the data flow trace from data sender to data receiver. In the EEC-driven paradigm, a data item flowing from end data owner (EO) to end data user (EU), $t_O\left(EO\right)\to t_O\left(EU\right)$, means the trace data from EO to EU, while $t_O$ is also attached to data and is propagated along with the data. Additionally, except for the data owner, the owner tag cannot be changed by other entities in the EEC-driven paradigm.

Decentralized privileges. When generating a new tag t, the creating subject immediately receives modification privileges (add privilege or remove privilege) for t within both its secrecy or integrity label. In detail, $t\in P_X^{+}\left(E\right)$ means an entity E with the privilege of adding t to its secrecy label or integrity label, and $t\in P_X^{-}\left(E\right)$ implies an entity with the privilege of removing t from its secrecy label or integrity label, in which X can be secrecy or integrity. Accordingly, a subject has the symmetric privileges of $P_S^{+}\left(E\right)$, $P_S^{-}\left(E\right)$, $P_I^{+}\left(E\right)$, and $P_S^{-}\left(E\right)$.

Definition 1 

(creating a new entity). $A\Rightarrow A^{\prime }$ is denoted as entity A creates $A^{\prime }$ in STDSM, which must meet the following rule:

$$ifA\Rightarrow A^{\prime }\mathit{then}\left\{\begin{array}{c}{L}_X\left(A^{\prime }\right):=L_X\left(A\right)\\ t_O\left(A^{\prime }\right):=t_O\left(A\right)\\ P_X^{\prime }\left(A^{\prime }\right)\stackrel{assign}{⟵}{P}_X^{\pm }\left(A\right).\end{array}\right.$$

This rule mandates that the creating entity configures the security context appropriately for the new entity. That is, the created entity $A^{\prime }$ inherits the security context of its creator A, and entity A assigns the corresponding privileges to the created entity $A^{\prime }$, where $P_X^{\prime }\left(A^{\prime }\right)\subseteq P_X^{\pm }\left(A\right)$. In particular, X can be S or I, and $P_X^{\prime }\left(A^{\prime }\right)$ can be $P_X^{+}\left(A^{\prime }\right)$ or $P_X^{-}\left(A^{\prime }\right)$.

Definition 2 

(secure information flow rule with trace). After executing the secure information flow rule in Definition 1, the allowed and prevented flows of information are recorded in trace data. The rule is shown below:

$$L_S\left(A\right)\subseteq L_S\left(B\right)\wedge L_I\left(B\right)\subseteq L_I\left(A\right)\underset{N}{\overset{Y}{\to }}{\xi }_{\left\{t_O\left(A\right),t_O\left(B\right)\right\}}^{A\to B}.$$

As for security check ($L_S\left(A\right)\subseteq L_S\left(B\right)$), the receiver (B) must have at least all the secrecy tags of the sender (A). Think of this as the receiver needing a high enough security clearance to read the data. As for integrity check ($L_I\left(B\right)\subseteq L_I\left(A\right)$), the sender (A) must have at least all the integrity tags of the receiver (B). This ensures the data comes from a trusted source that the receiver approves. In this rule, the information flow trace is also recorded in the trace data, ${\xi }_{\left\{t_O\left(A\right),t_O\left(B\right)\right\}}^{A\to B}$, regardless of whether the information flow satisfies the secure information flow rule. Here, $t_O\left(A\right)$ and $t_O\left(B\right)$ are the owner tag of entity A and B, respectively. Accordingly, the trace data can be used to reveal the actual identity of entity A and B. Under the constraint of this rule, STDSM not only enables secure data flow from sender to receiver but also achieves identity traceability.

Example: Patient Alice (EO) wants to send her health data to Doctor Bob (EU). Alice’s data have labels $L_S\left(Alice\right)=\left\{medical,alice\_private\right\}$, $L_I\left(Alice\right)=\left\{from\_alice\_device\right\}$:

• Bob can read the data only if his secrecy label $L_S\left(Bob\right)$ also contains both $medical$ and $alice\_private$;
• Bon will accept the data only if his integrity label $L_I\left(Bob\right)$ is a subset of Alice’s, e.g., $L_I\left(Bob\right)=\{from\_alice\_device\}$, meaning he trusts data from Alice’s device;
• Regardless of the decision, the trace data $\xi$ records that Alice and Bob attempted this data transfer.

Definition 3 

(label change rule). $L_X\left(A\right)\hookrightarrow L_X^{\prime }\left(A\right)$ denotes label change of entity A, which must obey the following:

$$L_X\left(A\right)\hookrightarrow L_X^{\prime }\left(A\right)\Rightarrow \left\{\begin{array}{c}{L}_X^{\prime }\left(A\right)-\left\{t\right\}=L_X\left(A\right)\mathit{if}t\in P_X^{+}\left(A\right)\hfill \\ L_X\left(A\right)-\left\{t\right\}=L_X^{\prime }\left(A\right)\mathit{if}t\in P_X^{-}\left(A\right)\hfill \end{array}\right.,$$

where X means secrecy (S) or integrity (I). In STDSM, there are declassifier (D) and endorser (E) subjects with the corresponding privileges to change their security context. Furthermore, D and E change their labels with privilege $P_X^{\pm }\left(D\right)$ and $P_X^{\pm }\left(E\right)$, respectively.

Example: A declassifier (D) might be a hospital administrator. They have the privilege ($P_X^{+}\left(D\right)$) for a tag $deidentified$. They can add this tag to Alice’s data, effectively lowering its secrecy level from $alice\_private$ to a less sensitive $deidentified$ version, allowing it to be used for research.

Definition 4 

(privileges delegation rule). Privilege delegation is intrinsically limited, as entity E can only assign privileges it currently possesses. The security condition for valid delegation requires $t\in P_X^{\pm }\left(E\right)$, where X represents either secrecy (S) or integrity (I).

4.2. Modeling

The EEC-driven data sharing paradigm is formally modeled with the STDSM model, as shown in Figure 2. The owner subjects labels the shared objects before the objects are outsourced to the edge and cloud. Additionally, the blue and red objects in Figure 2 mean delay-sensitive objects and delay-insensitive objects, respectively. The defined secure rules are deployed in the edge and cloud to prevent the outsourced data from maliciously accessing.

4.3. Workflows

This section depicts the workflows of EEC-driven data sharing using STDSM. There are five entities, namely end owner (EO), end user (EU), trusted authority (TA), edge server (ES), and cloud server (CS), in which TA is introduced to assign the unique ID and compute tags for the other participants.

EO and EU. In the EEC-driven paradigm, EO and EU must register at TA to achieve legal data request and upload. EO first labels the shared data using the distributed security labels and its owner tag, then uploads data to the edge server. EU requests the data it needs from the edge server by sending a request message that contains the security labels and its owner tag.

TA. It is trusted by other participants in the EEC-driven data sharing paradigm, taking charge of user registration and assigning a unique ID to EO, EU, ES, and CS. In particular, TA computes tags for other entities, and it distributes the owner tags simultaneously when it assigns the unique ID to EO and EU, respectively. Moreover, TA also stores the trace data generated based on the owner tags.

ES and CS. They are the honest-but-curious entities; that is, they would honestly enforce the security policies—however, they are curious about the contents of the uploaded data. ES takes charge of storing the delay-sensitive data and providing a delay-sensitive service for the ends. CS provides powerful computation services for the EEC ends and takes charge of the complex computations and analysis tasks.

The workflows, shown in Figure 3, for EEC-driven data sharing by using STDSM are as follows:

(1)

EO and EU are registered at the TA using their attributes, and then TA generates and distributes the unique ID to them. Furthermore, TA also simultaneously computes and distributes the owner tag $t_O\left(EO\right)$ and $t_O\left(EU\right)$ to them, respectively.

(2)

On the EO side, it first aggregates raw data, then requests secrecy $L_S\left(EO\right)$ and integrity labels $L_I\left(EO\right)$ from TA and, finally, labels raw data using $L_S\left(EO\right)$, $L_I\left(EO\right)$, and owner tag $t_O\left(EO\right)$ based on the rule of Definition 1. After that, EO uploads the labeled data to ES. In addition, the labels and owner tag are also propagated along with the data.

(3)

Once the labeled data are received, ES first checks the data and determines whether it is delay-sensitive, and if so then ES locally stores the data. Otherwise, ES uploads the received data to the cloud.

(4)

EU first requests secrecy, $L_S\left(EU\right)$, and integrity labels, $L_I\left(EU\right)$, from TA, then requests data by sending a request message to ES, in which the EU secrecy label $L_S\left(EU\right)$, the integrity label $L_I\left(EU\right)$, and the owner tag $t_O\left(EU\right)$ are contained in the message.

(5)

Once ES has determined that the requested data are delay-sensitive, it then makes a sharing decision by enforcing the secure rules of Definition 2 to 3.

(6)

Subsequently, the trace data are also generated according to $t_O\left(EO\right)$ and $t_O\left(EU\right)$, and it is stored in TA regardless of the sharing decision. Meanwhile, upon verification of a positive data sharing decision, the requested data are transmitted to the end user. Finally, EU accesses the shared data based on the rule of Definition 4.

(7)

Alternatively, once the requested data are delay-insensitive, ES redirects the data request to the cloud. Then, CS makes a sharing decision by enforcing the secure rules of Definition 2 to 3 to decide whether to share data.

(8)

The trace data are also generated according to $t_O\left(EO\right)$ and $t_O\left(EU\right)$ and are stored in TA regardless of the sharing decision. Meanwhile, upon verification of a positive data sharing decision, the requested data are transmitted to the end user. Finally, EU accesses the shared data based on the rule of Definition 4.

Step (1) and step (2) depict user registration and data labeling. Step (3) depicts data outsource. Step (4) to step (8) depict data request and delivery.

5. Formal Analysis and Verification of STDSM

The present section develops a formal HLPN-based model of STDSM, followed by automated verification through SMT-Lib theorem proving and Z3 solver validation, thereby proving both functional correctness and security guarantees.

5.1. Formal Analysis

Figure 4 presents an HLPN model of STDSM, while

Table 2. The places and their mappings.

Places	Description	Explanation
$\phi \left(EO\right)$	$\mathbb{P}(o\_attribute\times o\_info.\times o\_id\times o\_owner\_tag\times o\_rg\_result\times o\_data\times o\_data\_time\times o\_data\_type\times o\_data\_description\times o\_data\_name\times o\_data\_result\times o\_privileges\times o\_label\_result\times o\_privilege\times o\_secrecy\_label\times o\_integrity\_label)$	End data owner’s attributes
$\phi \left(TA\right)$	$\mathbb{P}(t\_e\_attribute\times t\_c\_info.\times t\_owner\_tag\times t\_oid\times t\_IO\_mapping\times t\_trace\_data\times t\_o\_owner\_tag\times t\_u\_owner\_tag)$	Attributes of TA
$\phi \left(EU\right)$	$\mathbb{P}(u\_attribute\times u\_info.\times u\_id\times u\_owner\_tag\times u\_result\times u\_data\times u\_data\_type\times u\_data\_description\times u\_data\_name\times u\_integrity\_tag\times u\_secrecy\_label\times u\_integrity\_label\times u\_privilege)$	End data user’s attributes
$\phi \left(SD\right)$	$\mathbb{P}(data\times data\_type\times data\_name\times data\_time\times data\_name\times data\_description)$	Attributes of the shared data
$\phi \left(LC\right)$	$\mathbb{P}(lc\_data\_type\times lc\_data\_name\times lc\_tag\times lc\_ta{g}^{\prime }\times lc\_secrecy\_label\times lc\_integrity\_label\times lc\_privilege\times lc\_result)$	Attributes of TA’s label center
$\phi \left(LD\right)$	$\mathbb{P}(l\_owner\_tag\times l\_secrecy\_label\times l\_integrity\_label\times l\_data\times l\_data\_name\times l\_data\_time\times l\_labeled\_data\times l\_data\_result\times l\_o\_id\times l\_o\_info.)$	Attributes of the labeled data
$\phi \left(ES\right)$	$\mathbb{P}(es\_id\times es\_info.\times es\_o\_id\times es\_o\_info.\times es\_u\_id\times es\_u\_info.\times es\_data\times es\_upload\_result\times es\_secrecy\_label\times es\_integrity\_label\times es\_o\_owner\_tag\times es\_auth\_result\times es\_u\_owner\_tag\times es\_data\_type\times es\_data\_name\times es\_access\_result)$	Attributes of the edge server
$\phi \left(ATHE\right)$	$\mathbb{P}(ae\_o\_id\times ae\_o\_info.\times ae\_result\times ae\_u\_id\times ae\_u\_info.)$	Holds attributes of authentication center on edge
$\phi \left(DC\right)$	$\mathbb{P}(dc\_auth\_result\times dc\_data\_type\times dc\_labeled\_data\times dc\_secrecy\_label\times dc\_integrity\_label\times dc\_o\_owner\_tag\times dc\_sensitive\_result\times dc\_search\_result\times dc\_data\_name)$	Attributes of edge server’s data center
$\phi \left(TSD\right)$	$\mathbb{P}(ts\_sensitive\_result\times ts\_labeled\_data\times ts\_data\_type\times ts\_secrecy\_label\times ts\_integrity\_label\times ts\_o\_owner\_tag\times ts\_search\_result\times ts\_data\_name\times ts\_decision\_result\times \times ts\_es\_access\_result\times ts\_es\_access\_false)$	Attributes of the time-sensitive data
$\phi \left(FD\right)$	$\mathbb{P}(fd\_sensitive\_result\times fd\_labeled\_data\times fd\_data\_type\times fd\_secrecy\_label\times fd\_integrity\_label\times fd\_o\_owner\_tag\times fd\_id\times fd\_info.\times fd\_transfer\_result\times fd\_data\_name\times fd\_u\_secrecy\_label\times fd\_u\_integrity\_label\times fd\_u\_owner\_tag\times fd\_u\_id)$	Attributes of the forwarded data
$\phi \left(CS\right)$	$\mathbb{P}(Cs\_id\times cs\_info.\times cs\_e\_id\times cs\_e\_info.\times cs\_labeled\_data\times cs\_data\_type\times cs\_secrecy\_label\times cs\_integrtiy\_label\times cs\_e\_owner\_tag\times cs\_u\_owner\_tag\times cs\_u\_secrecy\_label\times cs\_u\_integrity\_label\times cs\_transfer\_result\times cs\_auth\_result\times cs\_u\_id\times cs\_access\_result)$	Attributes of the cloud
$\phi \left(ATHC\right)$	$\mathbb{P}(a\_cid\times a\_info.\times a\_e\_id\times a\_e\_info\times a\_auth\_result\times a\_u\_id)$	Attributes of authentication center on edge
$\phi \left(UD\right)$	$\mathbb{P}(ud\_auth\_result\times ud\_labeled\_data\times ud\_data\_type\times ud\_secrecy\_label\times ud\_integrtiy\_label\times ud\_e\_owner\_tag\times ud\_decision\_result\times ud\_data\_name\times ud\_search\_result\times cs\_access\_result\times cs\_access\_false)$	Attributes of received data
$\phi \left(DPE\right)$	$\mathbb{P}(pe\_o\_secrecy\_label\times pe\_o\_integrity\_label\times pe\_o\_owner\_tag\times pe\_u\_secrecy\_label\times pe\_u\_integrity\_label\times pe\_o\_owner\_tag\times pe\_screcy\_result\times pe\_integrity\_result\times pe\_decision\_result\times pe\_trace\_data)$	Attributes of the decision point on edge
$\phi \left(DPC\right)$	$\mathbb{P}(pc\_o\_secrecy\_label\times pc\_o\_integrity\_label\times pc\_o\_owner\_tag\times pc\_u\_secrecy\_label\times pc\_u\_integrity\_label\times pc\_o\_owner\_tag\times pc\_screcy\_result\times pc\_integrity\_result\times pc\_decision\_result\times pc\_trace\_data)$	Attributes of the decision point on cloud
$\phi \left(AD\right)$	$\mathbb{P}(labeled\_data\times s\_label\times i\_label\times o\_tag\times data)$	Attributes of shared data

enumerates place and mappings and

Table 3. Data types used in STDSM.

Items	Types
attribute(s)	A string type for attributes
info.	A string type for information
id	An integrity number type for identity
tag	A string type for tags
label	A string type for security labels
result	A Boolean type for authentication result, tag generation result, etc.
data	A data type for IoT data
time	A date type for time
description	A string type for the description of IoT data
name	A string type for the name of IoT data
privileges	An enumeration type for security privileges
mapping	A string type for the places mappings

specifies the employed data types.

5.1.1. Register and Data Labeling

At first, both EO and EU register at TA to acquire the unique ID and owner tag. Subsequently, EO aggregates data and requests security labels and owner tag from TA, and then attaches such labels and tag to data. This procedure is shown in Figure 5.

End data owner and data user register at the trusted authority. The registration outcomes can be successes or failures. The transition $orgs$ depicts the successful registration of the end data owner, shown as the EO place in Figure 5, in which TA computes ID using the function of GEN_ID() and assigns it to the end data owner. Subsequently, TA computes the owner tag based on the ID using the OWNER_TAG() function and simultaneously distributes it to the end data owner for later usage, as shown in (1). Furthermore, TA generates and maintains a mapping against the end data owner’s ID and owner tag. The constraint must be checked, as the registration outcome in the EO place must be TRUE:

$$\begin{array}{cc}\hfill & R\left(orgs\right)=\forall c\in C,\forall d\in D\mid c\left[5\right]=\mathit{TRUE}\hfill \\ \hfill & \to d\left[1\right]:=c\left[1\right]\wedge d\left[2\right]:=c\left[2\right]\wedge d\left[4\right]:=GEN\_ID\left(\right[2],c[1\left]\right)\wedge \hfill \\ \hfill & c\left[3\right]:=d\left[4\right]\wedge d\left[3\right]:=OWNER\_TAG\left(c\right[2],c[3\left]\right)\wedge d\left[5\right]:=MAP\left(d\right[3],d[4\left]\right)\wedge \hfill \\ \hfill & C^{\prime }=C\cup \{c\left[3\right],c\left[4\right]\}\cap D^{\prime }=D\cup \{d\left[1\right],d\left[2\right],d\left[3\right],d\left[4\right],d\left[5\right]\}.\hfill \end{array}$$

(1)

The transition $orgf$ depicts the failed registration of the end data owner. The rule of the end data owner failed registration is depicted in (2), where the registration outcome is FALSE:

$$\begin{array}{cc}\hfill & R\left(orgf\right)=\forall c\in C,\forall d\in D\mid c\left[5\right]=\mathit{FALSE}\to C^{\prime }=C.\hfill \end{array}$$

(2)

The successful registration of end data user is depicted in $urgs$. Similar to (1), the corresponding rule is shown in (3), in which TA generates a unique ID using the GEN_ID() function and assigns it to the end data user. TA computes the owner tag based on the computed ID using the OWNER_TAG() function and simultaneously distributes it to the end data user for later usage. Moreover, TA generates and maintains a mapping against the end data user’s ID and owner tag. The constraint must be checked, as the registration outcome in the EU place must be TRUE:

$$\begin{array}{cc}\hfill & R\left(urgs\right)=\forall ee\in EE,\forall dd\in DD\mid ee\left[5\right]=\mathit{TRUE}\hfill \\ \hfill & \to dd\left[1\right]:=ee\left[1\right]\wedge dd\left[2\right]:=ee\left[2\right]\wedge dd\left[4\right]:=GEN\_ID\left(ee\right[2],ee[1\left]\right)\wedge \hfill \\ \hfill & ee\left[3\right]:=dd\left[4\right]\wedge dd\left[3\right]:=OWNER\_TAG\left(ee\right[2],ee[3\left]\right)\wedge dd\left[5\right]:=MAP\left(dd\right[3],dd[4\left]\right)\wedge \hfill \\ \hfill & E^{\prime }=EE\cup \{ee\left[3\right],ee\left[4\right]\}\cap D{D}^{\prime }=DD\cup \{dd\left[1\right],dd\left[2\right],dd\left[3\right],dd\left[4\right],dd\left[5\right]\}.\hfill \end{array}$$

(3)

As shown in (4), the transition $urgf$ depicts the failed registration for the end data user, in which the registration result of the end data user is FALSE:

$$\begin{array}{cc}\hfill & R\left(urgf\right)=\forall ee\in EE,\forall dd\in DD\mid ee\left[5\right]=\mathit{FALSE}.\hfill \end{array}$$

(4)

Afterward, as shown in (5), the end data owner collects data from the physical world through the sensors on their devices, such as heart rate meter, micro-camera, etc. The transition $dc$ depicts this procedure; the collected data are temporarily stored in their devices, in which the data collection result mapped at TC and EO must be matched, and its value must be TRUE:

$$\begin{array}{cc}\hfill & R\left(dc\right)=\forall a\in A,\forall b\in BB,\forall ac\in AC\mid bb\left[5\right]=aa\left[1\right]=\mathit{TRUE}\hfill \\ \hfill & \to a\left[6\right]:=ac\left[1\right]\wedge a\left[7\right]:=ac\left[4\right]\wedge a\left[8\right]:=ac\left[2\right]\wedge a\left[9\right]:=ac\left[6\right]\wedge a\left[10\right]:=ac\left[3\right]\wedge \hfill \\ \hfill & b\left[5\right]:=a\left[11\right]\wedge A^{\prime }=A\cup \{a\left[6\right],a\left[7\right],a\left[8\right],a\left[9\right],a\left[10\right]\}\cap B^{\prime }=B\cup \left\{b\left[5\right]\right\}.\hfill \end{array}$$

(5)

Once the data have been collected, as shown in (6), the end data owner first requests tags from TA, and then TA computes and generates tags and security labels according to data information, using the functions of GEN_TAG(), SEC_LABEL(), and INT_LABEL(), respectively. Finally, TA distributes the security labels to EO:

$$\begin{array}{cc}\hfill & R\left(lr\right)=\forall f\in F,\forall g\in G\mid f\left[13\right]=g\left[8\right]=TRUE\hfill \\ \hfill & \to g\left[1\right]:=f\left[8\right]\wedge g\left[2\right]:=f\left[10\right]\wedge g\left[3\right]:=GEN\_TAG\left(f\right[1\left]\right)\wedge g\left[4\right]:=GEN\_TAG\left(f\right[2\left]\right)\wedge \hfill \\ \hfill & g\left[5\right]:=SEC\_LABEL\left(g\right[3],g[7\left]\right)\wedge g\left[6\right]:=INT\_LABEL\left(g\right[3],g[4],g[7\left]\right)\wedge \hfill \\ \hfill & f\left[14\right]:=g\left[7\right]\wedge f\left[15\right]:=g\left[5\right]\wedge f\left[16\right]:=g\left[6\right]\wedge F^{\prime }=F\cup \{f\left[14\right],f\left[15\right],f\left[16\right]\}\hfill \\ \hfill & G^{\prime }=G\cup \{g\left[1\right],g\left[2\right],g\left[3\right],g\left[4\right],g\left[5\right],g\left[6\right],g\left[7\right]\}.\hfill \end{array}$$

(6)

As soon as the security labels are received, by executing the DATA_LABELING() function, EO attaches security labels and an owner tag to the collected data, based on their privileges, as shown in (7). The transition $dls$ depicts the successful data labeling, in which the data labeling result must be TRUE:

$$\begin{array}{c}R\left(dls\right)=\forall h\in H,\forall j\in J\mid j\left[8\right]=\mathit{TRUE}\hfill \\ \to j\left[1\right]:=h\left[4\right]\wedge j\left[2\right]:=h\left[15\right]\wedge j\left[3\right]:=h\left[16\right]\wedge j\left[4\right]:=h\left[6\right]\wedge j\left[5\right]:=h\left[10\right]\wedge \hfill \\ j\left[7\right]:=DATA\_LABELING\left(h\right[4],h[15],h[16],h[14\left]\right)\wedge \hfill \\ J^{\prime }=J\cup \{j\left[1\right],j\left[2\right],j\left[3\right],j\left[4\right],j\left[5\right],j\left[7\right]\}.\hfill \end{array}$$

(7)

However, data labeling will fail if the data labeling result is checked to be FALSE. The transition dlf depicts this procedure, and the corresponding rule is shown in (8):

$$\begin{array}{cc}\hfill & R\left(\mathit{dlf}\right)=\forall h\in H,\forall k\in K,\forall j\in J\mid j\left[8\right]=FALSE\to J^{\prime }=J.\hfill \end{array}$$

(8)

5.1.2. Data Outsource

After EO has labeled its aggregated data, it uploads those data to the edge server. Subsequently, those data are stored in the edge server once the received data are checked as delay-sensitive. Otherwise, the labeled data are transferred and stored in the cloud server. This procedure is depicted in HLPN, shown in Figure 6:

The end data owner uploads the labeled data to the edge server. As shown in (9), the transition $ups$ depicts the successful data upload, in which the security labels and owner tag of the end data owner propagate along with the labeled data:

$$\begin{array}{c}R\left(ups\right)=\forall l\in L,\forall q\in Q\mid q\left[8\right]=l\left[8\right]=TRUE\hfill \\ \to q\left[3\right]:=l\left[9\right]\wedge q\left[4\right]:=l\left[10\right]\wedge q\left[7\right]:=l\left[7\right]\wedge q\left[9\right]:=l\left[2\right]\wedge \hfill \\ q\left[10\right]:=l\left[3\right]\wedge q\left[11\right]:=l\left[1\right]\wedge q\left[8\right]:=l\left[8\right]\wedge \hfill \\ L^{\prime }=L\cup \left(l\left[8\right]\right)\wedge Q^{\prime }=Q\cup \{q\left[3\right],q\left[4\right],q\left[7\right],q\left[9\right],q\left[10\right],q\left[11\right]\}.\hfill \end{array}$$

(9)

When receiving the uploaded data and corresponding information from the end data owner, the edge server first authenticates the end data owner. The transition $autho$ performs successful authentication of the end data owner, in which the constraint is that the authentication result mapped at ATHE, ES, and DC must be matched, and its value must be TRUE. As shown in (10), the edge server is triggered to store or provisionally store the uploaded data after the end data owner is successfully authenticated:

$$\begin{array}{c}R\left(ahto\right)=\forall r\in R,\forall n\in N,\forall v\in V\mid n\left[12\right]=r\left[3\right]=v\left[1\right]=TRUE\hfill \\ \to r\left[1\right]:=n\left[3\right]\wedge r\left[2\right]:=n\left[4\right]\wedge n\left[3\right]:=AUTHO\left(n\right[3],n[4\left]\right)\wedge \hfill \\ n\left[12\right]:=r\left[3\right]\wedge v\left[1\right]:=r\left[3\right]\wedge N^{\prime }=N\cup \left(n\left[12\right]\right)\wedge \hfill \\ R^{\prime }=R\cup \{r\left[1\right],r\left[2\right],r\left[3\right]\}\wedge V^{\prime }=V\cup \left\{v\left[1\right]\right\}.\hfill \end{array}$$

(10)

As soon as the end data owner is successfully authenticated, the edge server checks whether the received data are delay-sensitive. As shown in (11), the transition $cks$ depicts the successful delay-sensitive data checking, in which the edge server first checks the uploaded data with the SENSITIVE_CHECK() function, then locally stores such data once the check result is TRUE. That is, the received data are delay-sensitive; such data are used to provide delay-sensitive service to the end data users:

$$\begin{array}{c}R\left(cks\right)=\forall o\in O,\forall p\in P\mid p\left[1\right]=o\left[7\right]=TRUE\hfill \\ \to p\left[1\right]:=SENSITIVE\_CHECK\left(o\right[2],o[3\left]\right)\wedge o\left[7\right]:=p\left[1\right]\wedge \hfill \\ p\left[2\right]:=o\left[3\right]\wedge p\left[3\right]:=o\left[2\right]\wedge p\left[4\right]:=o\left[4\right]\wedge p\left[5\right]:=o\left[5\right]\wedge p\left[6\right]:=o\left[6\right]\wedge \hfill \\ O^{\prime }=O\cup \left\{o\left[7\right]\right\}\wedge P^{\prime }=P\cup \{p\left[1\right],p\left[2\right],p\left[3\right],p\left[4\right],p\left[5\right],p\left[6\right]\}.\hfill \end{array}$$

(11)

Alternatively, the edge server transfers data to the cloud once the delay-sensitive checking result is FALSE; that is, such data are delay-insensitive. As shown in (12), the transition $ckf$ depicts this procedure, in which the received data are transferred to the cloud center and the output of the SENSITIVE_CHECK() must be FALSE:

$$\begin{array}{c}R\left(ckf\right)=\forall t\in T,\forall y\in Y\mid y\left[1\right]=t\left[7\right]=FALSE\hfill \\ \to y\left[1\right]:=SENSITIVE\_CHECK\left(t\right[2],t[3\left]\right)\wedge t\left[7\right]:=p\left[1\right]\wedge \hfill \\ y\left[2\right]:=t\left[3\right]\wedge y\left[3\right]:=t\left[2\right]\wedge y\left[4\right]:=t\left[4\right]\wedge y\left[5\right]:=t\left[5\right]\wedge y\left[6\right]:=t\left[6\right]\wedge \hfill \\ T^{\prime }=T\cup \left\{t\left[7\right]\right\}\wedge P^{\prime }=P\cup \{y\left[1\right],y\left[2\right],y\left[3\right],y\left[4\right],y\left[5\right],y\left[6\right]\}.\hfill \end{array}$$

(12)

Data propagation to the cloud is mediated by transition $etc$, as shown in (13), with successful transmission contingent upon a TRUE result:

$$\begin{array}{c}R\left(etc\right)=\forall kk\in KK,\forall nn\in NN\mid nn\left[13\right]=kk\left[9\right]=TRUE\hfill \\ \to nn\left[3\right]:=kk\left[7\right]\wedge nn\left[4\right]:=kk\left[8\right]\wedge nn\left[5\right]:=kk\left[2\right]\wedge nn\left[6\right]:=kk\left[3\right]\wedge \hfill \\ nn\left[7\right]:=kk\left[4\right]\wedge nn\left[8\right]:=kk\left[5\right]\wedge nn\left[9\right]:=kk\left[6\right]\wedge \hfill \\ N{N}^{\prime }=NN\cup \{nn\left[3\right],nn\left[4\right],nn\left[5\right],nn\left[6\right],nn\left[7\right],nn\left[8\right],nn\left[9\right]\}.\hfill \end{array}$$

(13)

Once the transferred data and corresponding information from the edge server are received, the cloud first authenticates the edge server on transition $athse$ using the AUTH_EDGE() function. Then, the authentication result is also fed to the data center of the cloud shown as place UD in Figure 6. Moreover, the authentication result mapped at the CS place, UD place, and ATHC places must be the same, and its value must be TRUE:

$$\begin{array}{c}R\left(athse\right)=\forall ss\in SS,\forall rr\in RR,\forall pp\in PP\mid rr\left[1\right]=pp\left[5\right]=ss\left[14\right]=TRUE\hfill \\ \to pp\left[3\right]:=ss\left[7\right]\wedge pp\left[4\right]:=ss\left[8\right]\wedge pp\left[5\right]:=AUTH\_EDGE\left(ss\right[7],ss[8\left]\right)\wedge \hfill \\ rr\left[1\right]:=pp\left[5\right]\wedge ss\left[14\right]:=pp\left[5\right]\wedge P{P}^{\prime }=PP\cup \{pp\left[3\right],pp\left[4\right],pp\left[5\right]\}\wedge \hfill \\ S{S}^{\prime }=SS\cup \left\{ss\left[14\right]\right\}\wedge R{R}^{\prime }=RR\cup \left\{rr\left[1\right]\right\}.\hfill \end{array}$$

(14)

Afterwards, the cloud server stores the received data at its data center once the edge server is successfully authenticated. The transition $ds$ depicts this procedure, and its rule is shown in (15):

$$\begin{array}{c}R\left(ds\right)=\forall tt\in TT,\forall uu\in UU\mid \hfill \\ uu\left[2\right]:=tt\left[5\right]\wedge uu\left[3\right]:=tt\left[6\right]\wedge uu\left[4\right]:=tt\left[7\right]\wedge uu\left[5\right]:=tt\left[8\right]\wedge uu\left[6\right]:=tt\left[9\right]\wedge \hfill \\ U{U}^{\prime }=UU\cup \{uu\left[2\right],uu\left[3\right],uu\left[4\right],uu\left[5\right],uu\left[6\right]\}.\hfill \end{array}$$

(15)

5.1.3. Data Request and Delivery

EU requests data that it needs from the edge server through triggering a data request that contains $L_S\left(EU\right)$, $L_I\left(EU\right)$, and $t_O\left(EU\right)$. Subsequently, the edge server authenticates the end data user and searches for the requested data. Once the requested data have been searched, the edge server makes a sharing decision by enforcing the rule in Definition 2. In addition, the trace data are also generated and stored in TA regardless of the data sharing decision. In response, the edge server delivers the requested data to EU once the data sharing decision result is TRUE. Otherwise, the data request is redirected to the cloud. Then, the cloud makes a similar enforcement as that of the edge server to deliver data and generates the trace data. This procedure is depicted in HLPN, shown as Figure 7:

Before requesting data from the edge server, as shown in (16), tags are first computed by TA. Subsequently, TA generates security labels based on the SEC_LABEL() function and the INT_LABEL() function, respectively. Finally, TA distributes such labels to EU:

$$\begin{array}{c}R\left(url\right)=\forall jk\in JK,\forall kj\in KJ\mid kj\left[8\right]=jk\left[17\right]\hfill \\ \to kj\left[1\right]:=jk\left[7\right]\wedge kj\left[2\right]:=jk\left[9\right]\wedge kj\left[3\right]:=GEN\_TAG\left(jk\right[1\left]\right)\wedge kj\left[4\right]:=GEN\_TAG\left(jk\right[2\left]\right)\wedge \hfill \\ kj\left[5\right]:=SEC\_LABEL\left(kj\right[3],kj[7\left]\right)\wedge kj\left[6\right]:=INT\_LABEL\left(kj\right[3],kj[4],kj[7\left]\right)\wedge \hfill \\ jk\left[10\right]:=kj\left[5\right]\wedge jk\left[11\right]:=kj\left[6\right]\wedge jk\left[12\right]:=kj\left[7\right]\wedge J{K}^{\prime }=JK\cup \{jk\left[10\right],jk\left[11\right],jk\left[12\right]\}\wedge \hfill \\ K{J}^{\prime }=KJ\cup \{kj\left[1\right],kj\left[2\right],kj\left[3\right],kj\left[4\right],kj\left[5\right],kj\left[6\right]\}.\hfill \end{array}$$

(16)

Once the labels are successfully distributed, EU requests data from the edge server by sending a request message that contains $L_S\left(EU\right)$, $L_I\left(EU\right)$, and $t_O\left(EU\right)$, which is depicted in (17):

$$\begin{array}{c}R\left(dr\right)=\forall ff\in FF,\forall gg\in GG\mid \hfill \\ gg\left[5\right]:=ff\left[3\right]\wedge gg\left[6\right]:=ff\left[2\right]\wedge gg\left[9\right]:=ff\left[14\right]\wedge gg\left[10\right]:=ff\left[15\right]\wedge \hfill \\ gg\left[13\right]:=ff\left[4\right]\wedge gg\left[14\right]:=ff\left[7\right]\wedge gg\left[15\right]:=ff\left[9\right]\wedge \hfill \\ G{G}^{\prime }=GG\cup \{gg\left[5\right],gg\left[6\right],gg\left[9\right],gg\left[10\right],gg\left[13\right],gg\left[14\right],gg\left[15\right]\}.\hfill \end{array}$$

(17)

As shown in (18), once the data request is received, the edge server first authenticates the end data user, in which process the edge server authenticates EU using the AUTHU() function. In particular, the authentication output mapped at places among ES, ATHE, and DC must be TRUE:

$$\begin{array}{c}R\left(ath{u}^{\prime }\right)=\forall w\in W,\forall m\in M,\forall s\in S\mid w\left[12\right]=m\left[3\right]=s\left[1\right]=TRUE\hfill \\ \to m\left[4\right]:=w\left[5\right]\wedge m\left[5\right]:=w\left[6\right]\wedge m\left[3\right]:=AUTHU\left(w\right[5],w[6\left]\right)\wedge \hfill \\ w\left[12\right]:=m\left[3\right]\wedge s\left[1\right]:=m\left[3\right]\wedge W^{\prime }=W\cup \left(w\left[12\right]\right)\wedge \hfill \\ M^{\prime }=M\cup \{m\left[3\right],m\left[4\right],m\left[5\right],m\left[6\right]\}\wedge S^{\prime }=S\cup \left\{s\left[1\right]\right\}.\hfill \end{array}$$

(18)

Subsequently, the edge server locally searches data and checks whether the requested data are delay-sensitive and if so then the edge server will outsource those data to EU. As shown in (19), the edge server searches the requested data using the DATA_SEARCH() function and checks the requested data using the SENSITIVE_CHECK() function, respectively. In addition, the data search result and data delay-sensitive checking result must be TRUE:

$$\begin{array}{c}R\left(dss\right)=\forall z\in Z,\forall x\in X\mid x\left[7\right]=z\left[8\right]=TRUE\wedge z\left[7\right]=x\left[1\right]=TRUE\hfill \\ \to x\left[8\right]:=z\left[9\right]\wedge x\left[7\right]:=DATA\_SEARCH\left(z\right[9\left]\right)\wedge z\left[8\right]:=x\left[7\right]\wedge \hfill \\ x\left[3\right]:=z\left[2\right]\wedge x\left[1\right]:=SENSITIVE\_CHECK\left(z\right[2],z[9\left]\right)\wedge z\left[7\right]:=x\left[1\right]\wedge \hfill \\ Z^{\prime }=Z\cup \{z\left[7\right],z\left[8\right]\}\wedge X^{\prime }=X\cup \{x\left[1\right],x\left[3\right],x\left[7\right],x\left[8\right]\}.\hfill \end{array}$$

(19)

After that, the edge server makes a data sharing decision by executing the secure trace-supported information flow control rule at its decision point. As shown in (20), the transition $dsme$ depicts the decision-making procedure, in which the decision point executes the SUBSET_SEC() function, the SUBSET_INT() function, and the DECISION() function to decide whether to agree to provide the requested data to the end data user. The requested data are provided to the requester once the output of the DECISION() function is TRUE. In addition, the trace data are also generated using the TRACE() function and stored at TA regardless of whether or not the decision point agrees to share with the requester. In particular, the value of the data sharing decision output mapped at DPE and TSD places must be TRUE:

$$\begin{array}{c}R\left(dsme\right)=\forall aa\in AA,\forall bb\in BB,\forall cc\in CC\mid bb\left[9\right]=aa\left[9\right]=TRUE\hfill \\ \to bb\left[7\right]:=SUBSET\_SEC\left(aa\right[4],bb[4\left]\right)\wedge bb\left[8\right]:=SUBSET\_INT\left(bb\right[5],aa[5\left]\right)\wedge \hfill \\ bb\left[9\right]:=DECISION\left(bb\right[7],bb[8\left]\right)\wedge aa\left[9\right]:=bb\left[9\right]\wedge cc\left[6\right]:=TRACE\left(aa\right[3],bb[6\left]\right)\wedge \hfill \\ C{C}^{\prime }=CC\cup \left\{c\left[6\right]\right\}\wedge A{A}^{\prime }=AA\cup \left\{aa\left[9\right]\right\}\wedge B{B}^{\prime }=BB\cup \{bb\left[7\right],bb\left[8\right],bb\left[9\right]\}.\hfill \end{array}$$

(20)

When a data sharing decision is TRUE, as shown in (21), the edge server then delivers the shared data to the end data user:

$$\begin{array}{c}R\left(etu\right)=\forall oo\in OO,\forall ii\in JJ\mid mm\left[9\right]=TRUE\hfill \\ \to ii\left[6\right]:=mm\left[4\right]\wedge ii\left[7\right]:=mm\left[3\right]\wedge ii\left[9\right]:=mm\left[8\right]\wedge ii\left[10\right]:=mm\left[4\right]\wedge ii\left[11\right]:=mm\left[5\right]\wedge \hfill \\ ii\left[4\right]:=oo\left[6\right]\wedge I{I}^{\prime }=II\cup \{ii\left[4\right],ii\left[6\right],ii\left[7\right],ii\left[9\right],ii\left[10\right],ii\left[11\right]\}.\hfill \end{array}$$

(21)

Alternatively, if the delay-sensitive checking result is FALSE then the edge server will redirect the data request to the cloud server. As shown in (22), transition $rr$ performs data request redirection, in which all request parameters are sent to the cloud center:

$$\begin{array}{c}R\left(rr\right)=\forall oo\in OO,\forall ll\in LL\mid \hfill \\ oo\left[3\right]:=ll\left[7\right]\wedge oo\left[4\right]:=ll\left[8\right]\wedge oo\left[10\right]:=ll\left[13\right]\wedge oo\left[11\right]:=ll\left[11\right]\wedge oo\left[12\right]:=ll\left[12\right]\wedge \hfill \\ oo\left[15\right]:=ll\left[14\right]\wedge O{O}^{\prime }=OO\cup \{oo\left[3\right],oo\left[4\right],oo\left[10\right],oo\left[11\right],oo\left[12\right],oo\left[15\right]\}.\hfill \end{array}$$

(22)

When the redirected data request is received, as shown in (23), the cloud center first authenticates the end data user using the AUTHU() function. Additionally, the authentication outcome, requiring the value of TRUE, is also fed to the data center of the cloud server:

$$\begin{array}{c}R\left(athu\right)=\forall xx\in XX,\forall vv\in VV,\forall ww\in WW\mid xx\left[14\right]=ww\left[5\right]=vv\left[1\right]=\mathit{TRUE}\hfill \\ \to ww\left[6\right]:=xx\left[15\right]\wedge ww\left[5\right]:=AUTHU\left(xx\right[15\left]\right)\wedge xx\left[14\right]:=ww\left[5\right]\wedge \hfill \\ vv\left[1\right]:=ww\left[5\right]\wedge V{V}^{\prime }=VV\cup \left\{vv\left[1\right]\right\}\wedge X{X}^{\prime }=XX\cup \left\{xx\left[14\right]\right\}\wedge \hfill \\ W{W}^{\prime }=WW\cup \{ww\left[5\right],ww\left[6\right]\}.\hfill \end{array}$$

(23)

Then, the cloud server makes a data sharing decision by executing the trace-supported secure information flow rule after the cloud successfully authenticates the end data user. As shown in (24), the transition $dsmc$ depicts successful decision making in the cloud, in which the decision point executes the SUBSET_SEC() function, the SUBSET_INT() function, and the DECISION() function to decide whether or not to provide the requested data to the data requester. The requested data are provided to EU after the output of the DECISION() function is TRUE. Additionally, the trace data are also generated using the TRACE() function and then stored at TA regardless of whether the sharing decision point of the cloud, shown as the DPC place in Figure 7, agrees to share the requested data with the end data user:

$$\begin{array}{c}R\left(dsmc\right)=\forall ab\in AB,\forall zz\in ZZ,\forall yy\in YY\mid yy\left[7\right]=zz\left[9\right]=TRUE\hfill \\ \to zz\left[7\right]:=SUBSET\_SEC\left(yy\right[4],yy[4\left]\right)\wedge zz\left[8\right]:=SUBSET\_INT\left(yy\right[5],yy[5\left]\right)\wedge \hfill \\ zz\left[9\right]:=DECISION\left(zz\right[7],zz[8\left]\right)\wedge yy\left[7\right]:=zz\left[9\right]\wedge ab\left[6\right]:=TRACE\left(yy\right[6],zz[3\left]\right)\wedge \hfill \\ Y{Y}^{\prime }=YY\cup \left\{yy\left[7\right]\right\}\wedge A{B}^{\prime }=AB\cup \left\{ab\left[6\right]\right\}\wedge Z{Z}^{\prime }=ZZ\cup \{zz\left[7\right],zz\left[8\right],zz\left[9\right]\}.\hfill \end{array}$$

(24)

As shown in (25), the cloud-to-EU data delivery, formalized by transition $dtu$, is conditionally executed only when the data search operation yields a TRUE verification result:

$$\begin{array}{c}R\left(dtu\right)=\forall oo\in OO,\forall jj\in JJ\mid oo\left[9\right]=TRUE\hfill \\ \to jj\left[6\right]:=oo\left[2\right]\wedge jj\left[7\right]:=oo\left[3\right]\wedge jj\left[9\right]:=oo\left[8\right]\wedge jj\left[10\right]:=oo\left[4\right]\wedge jj\left[11\right]:=oo\left[5\right]\wedge \hfill \\ jj\left[4\right]:=oo\left[6\right]\wedge J{J}^{\prime }=JJ\cup \{jj\left[4\right],jj\left[6\right],jj\left[7\right],jj\left[9\right],jj\left[10\right],jj\left[11\right]\}.\hfill \end{array}$$

(25)

Following the data delivery process, shown in (26), EU retrieves the shared resources through transition $url$:

$$\begin{array}{c}R\left(ac\right)=\forall ad\in AD,\forall ea\in EA\mid \hfill \\ ea\left[1\right]:=ad\left[6\right]\wedge ea\left[2\right]:=ad\left[10\right]\wedge ea\left[3\right]:=ad\left[11\right]\wedge ea\left[4\right]:=ad\left[4\right]\wedge \hfill \\ ea\left[5\right]:=ACCESS\_DATA(ad\left[6\right],ad\left[12\right])\wedge E{A}^{\prime }=EA\cup \{ea\left[1\right],ea\left[2\right],ea\left[3\right],ea\left[4\right],ea\left[5\right]\}.\hfill \end{array}$$

(26)

The systematic enforcement of these transition rules enables secure data sharing between data owners and designated data users.

5.2. Formal Verification

For this section, firstly the security properties of STDSM were specified, and then the security properties of STDSM and its HLPN model, which included transition rules and security constraints, were systematically encoded into SMT-Lib’s array theory. During verification, the QF_AUFLIA logic of SMT-Lib was used for the implementation. Finally, Z3 verified STDSM by taking those implementations as input.

5.2.1. Assertions for Security Properties

To verify the security of STDSM, this paper designed the assertions of data confidentiality, integrity, and identity traceability, which are depicted as follows:

• Assertion for data confidentiality. Let $L_S$ be the secrecy label attached to data d in EEC system S. Data confidentiality is preserved if

  $$\forall d\in S,\forall t\in T,L_S(d,t)=L_s(d,t_0),$$

  where d is the shared data, S means the data set within system, T is the system lifetime, and $t_0$ is the labeling time. Accordingly, our formal verification adopts this foundational assertion:

  $$\begin{gathered} \left(\mathit{assert}\right(\mathit{not}\left(\mathit{or}\right(\mathit{and}(=(\mathit{select}\mathit{l}\mathit{2}\left)\right(\mathit{select}\mathit{x}\mathit{4}\left)\right)(=(\mathit{select}\mathit{x}\mathit{4}\left)\right(\mathit{select}\mathit{ii}\mathit{2}\left)\right)) \\ \hspace{1em}\hspace{1em}(\mathit{and}(=(\mathit{select}\mathit{l}\mathit{2}\left)\right(\mathit{select}\mathit{uu}\mathit{4}\left)\right)(=(\mathit{select}\mathit{uu}\mathit{4}\left)\right(\mathit{select}\mathit{ii}\mathit{12}\left)\right)\left)\right)\left)\right)\left(\mathit{check}\text{-}\mathit{sat}\right). \end{gathered}$$
• Assertion for data integrity. Similarly, let $L_I$ be the secrecy label attached to data d in EEC system S. Data integrity is preserved if

  $$\forall d\in S,\forall t\in T,L_I(d,t)=L_I(d,t_0).$$
  Accordingly, our formal verification utilizes this foundational assertion:

  $$\begin{gathered} \left(\mathit{assert}\right(\mathit{not}\left(\mathit{or}\right(\mathit{and}(=(\mathit{select}\mathit{l}\mathit{3}\left)\right(\mathit{select}\mathit{x}\mathit{5}\left)\right)(=(\mathit{select}\mathit{x}\mathit{5}\left)\right(\mathit{select}\mathit{ii}\mathit{13}\left)\right)) \\ \hspace{1em}\hspace{1em}(\mathit{and}(=(\mathit{select}\mathit{l}\mathit{3}\left)\right(\mathit{select}\mathit{uu}\mathit{5}\left)\right)(=(\mathit{select}\mathit{uu}\mathit{5}\left)\right(\mathit{select}\mathit{ii}\mathit{13}\left)\right)\left)\right)\left)\right)\left(\mathit{check}\text{-}\mathit{sat}\right). \end{gathered}$$
• Assertion for identity traceability. Similarly to the confidentiality and integrity assertions, let $t_O$ be the owner tag attached to data d in EEC system S. Identity traceability is preserved if

  $$\forall d\in S,\forall t\in T,\exists \tau \in \mathcal{T},\tau (d,t)=(t_O\left(EO\right),t_O\left(EU\right),t^{\prime }),$$

  where $t_O\left(EO\right)$ and $t_O\left(EU\right)$ represent the owner tag of data owner and data user. In STDSM, the shared data are also labeled using the owner tag. Accordingly, our formal verification utilizes this foundational assertion:

  $$\left(\mathit{assert}\right(\mathit{not}\left(\mathit{and}\right(=\left(\mathit{select}\mathit{l}\mathit{1}\right)\left(\mathit{select}\mathit{dd}\mathit{7}\right)\left)\right(=\left(\mathit{select}\mathit{dd}\mathit{8}\right)\left(\mathit{select}\mathit{ii}\mathit{4}\right)\left)\right)\left)\right)\left(\mathit{check}\text{-}\mathit{sat}\right).$$

5.2.2. Result

The translated model performed well and produced the expected results with $unsat$ within 280 ms during automatic verification in the Z3 solver, which indicates that STDSM satisfies confidentiality, integrity, and identity traceability.

6. Performance Evaluation

6.1. Experimental Setup

For this section, we conducted experiments to evaluate STDSM’s performance based on Python 3.0, which mainly evaluates the time overhead of the secure information flow rule, trace data generation, and identity tracking. During our experiments, a server with Ubuntu 18.04 and a desktop with Windows 11 served as cloud and edge server, respectively. Additionally, EO and EU were equipped with two mobile phones. The detailed implementation environments are shown in

Table 4. Experimental implementation environments.

Devices	CPU	Memory	System
Mobile phones	Kirin 710	4 GB	Android 8
	Snapdragon 750	6 GB	Android 10
Desktop	Intel i7-8809	32 GB	Windows 11
Laptop	Intel i7-7560U	16 GB	Windows 11
Server	Gold-6330	256 GB	Ubuntu 18.04

. Furthermore, SHA-256 was used for computing tags and labels, with the number of tags increasing from 5 to 200. All the experimental results were run 100 times, and the average value was taken as the final results. In addition, while evaluating the overhead of the data sharing compared with the related works, the data size was set to increase from 10 MB to 100 MB. Such overhead of all the compared works signified the turnaround time from tag generation to data access.

6.2. Numerical Result

The numerical results mainly consist of STDSM’s performance and comparison of the data sharing overhead, shown in Figure 8 and Figure 9, respectively.

Figure 8a depicts the time overhead of the secure information flow rule execution ($T\_se$) with varying data users’ attributes, which shows that the time increases with the attributes of the data users. It can also be seen that the label size has less effect for $T\_se$. For instance, under 1024 bits tag condition, $T\_se$ rises from 40 ms to 200 ms. Furthermore, $T\_se$ is almost stabilized to 115 ms when the number of tags is set to 100. The reason is that secure execution of the information flow control rule is mainly based on the tag number.

Figure 8b shows the time overhead of the trace data generation and identity tracking ($T\_ti$) under varying tag sizes. As for the time overhead of the trace data generation, it slightly increased with increasing tag size. The reason was that the larger tag size took more time to generate trace data. Additionally, Figure 8b further demonstrates that variations in tag size exhibited negligible impact on the time required for identity tracking.

The time overhead of STDSM for sharing data compared with the related works is shown in Figure 9, which demonstrates STDSM took the lowest time overhead. In detail, in DIFC-AC [24] the authorization conditions related to the user roles and attributes were set on each label to restrict data users’ read and write access. Therefore, STDSM reduced the time overhead by up to 14.3% compared with DIFC-AC. Unlike DIFC-AC, both Flowk [25] and Secure-Camflow [26] used the Chinese wall policy (CWP) [36] when sharing data to check the conflict of interests, leading to lower overhead compared with DIFC-AC. Both FlowK and Camflow reduced the time overhead by almost 5.8%. However, Secure-Camflow utilized the lightweight cryptographic primitive, thereby taking almost 1.5% more time overhead compared with FlowK and CamFlow. In addition, Secure-camflow took 14.5% less overhead compared with DIFC-AC. DIFCS [27] took the less overhead compared with DIFC-AC, FlowK, Camflow, and Secure-Camflow. However, STDSM took the lowest time overhead, reducing the time overhead by up to 15% compared with the above four related works.

6.3. Storage Overhead Analysis

Beyond the time overhead evaluation, we analyzed the storage overhead introduced by STDSM’s core components: security labels, owner tags, and trace data. This analysis was crucial for assessing the model’s suitability for resource-constrained environments like the EEC paradigm.

The storage overhead in STDSM primarily originates from three sources:

Security Labels: Each data object is associated with a secrecy label and an integrity label. In our implementation, a label is a set of tags, and each tag is generated as an SHA-256 hash value. The storage required for a single label is 32 × n bytes, where n is the number of tags in that label. Since each data object has two labels, the total storage overhead for labels per data object is 64 × n bytes.

Owner Tag: Each entity (data owner and user) has a unique owner tag, which is also a 256-bit hash. This tag is attached to the data and propagated during the sharing process. The storage overhead for a single owner tag is 32 bytes. For any data sharing transaction, the owner tags of both the data owner and the data user are involved in generating the trace data. However, only the data owner’s tag is physically attached to the data object itself, adding a constant 32 bytes per object.

Trace Data: Trace data is generated for every data access request, regardless of whether it is granted. Each trace record contains the owner tags of the data owner and the data user. A single trace record therefore requires 64 bytes.

6.4. Functional Comparison

This section mainly compares STDSM with the related works [7,25,26,27], shown in

Table 5. Functions comparison with related works.

Models	Comparison Items
	C	I	T	Auth.	Sca.	Trade-Offs/Limitations
DIFC-AC [24]	✓	✓	×	Limited	Limited	OS kernel and highest overhead.
Flowk [25]	✓	✓	×	Supported	High	OS kernel and mod. overhead.
Camflow [7]	✓	✓	×	Supported	High	OS kernel and mod. overhead.
Secure-
Camflow [26]	✓	✓	×	Supported	High	Cry. with higher overhead.
DIFCS [27]	✓	✓	×	Supported	High	Multi-clouds and less overhead.
STDSM	✓	✓	✓	Supported	High	CTA and lowest overhead.

Note: C: Confidentiality; I: Integrity; T: Traceability; OS: Operation System; Auth.: Authorization; Sca.: Scalability; Cry.: cryptography; mod.: moderate; CTA: Centralized Trusted Authority.

, from the aspects of security functions, such as data confidentiality, data integrity, etc.

STDSM exhibits notable advancements over existing decentralized information flow control (DIFC) models by integrating comprehensive security features with operational efficiency. As summarized in Table 4, while prior approaches including DIFC-AC [24], FlowK [25], DIFCS [27], Camflow [7], and Secure-Camflow [26] provide foundational confidentiality and integrity protections, they uniformly lack inherent identity traceability capabilities. Furthermore, DIFC-AC imposes restrictive, label-centric authorization policies that attenuate scalability and administrative flexibility. Although FlowK and Camflow require operation system integration, they take less overhead, due to the simplified label-based rules. In addition, DIFCS is only used in multi-cloud scenarios with moderate overhead compared with other models. In contrast, STDSM introduces a novel owner tag mechanism coupled with trace data recording, enabling robust user identity tracking without necessitating additional label constraints. STDSM supports dynamic authorization while maintaining minimal operational overhead. Consequently, STDSM represents a substantively improved framework, while maintaining stringent security guarantees and superior performance metrics.

7. Conclusions and Discussions

This paper proposes STDSM, a symmetry-enhanced model, to secure EEC-driven paradigm data sharing based on DIFC. STDSM leverages the symmetry between dual security labels and the balance between data sharing and traceability to allow end data owners to securely share their data. By enforcing the designed secure data flow rules, symmetrical control over data outflow and inflow is achieved. We presented a novel formal verification methodology integrating HLPN, SMT-Lib, and Z3, which not only proves the security properties of STDSM but also provides a re-usable and automated framework for rigorously analyzing DIFC-based schemes. Our formal verification results reveal that STDSM has the aforementioned security properties. Performance evaluation was conducted, thereby demonstrating that STDSM can reduce time overhead by up to 15% when sharing data compared with the related works.

From a theoretical perspective, STDSM is expected to perform well in extensive IoT deployments. Computationally, the core security decision relies on set inclusion checks with complexity linearly related to the number of tags. In terms of communication, the security labels and owner tags are of fixed size, introducing constant overhead. However, we acknowledge the primary limitations of this work. Firstly, the empirical validation was constrained to a controlled testbed, leaving its scalability in large-scale, consumption-of-end-devices, real-world deployments unproven. Secondly, this paper does not account for a compromised TA in real and extensive IoT deployment. Lastly, the trace data are stored in a trusted TA, which does not consider the task offloading for TA.

In the near future, by considering a compromised TA, task offloading for TA, and integrating STDSM with Blockchain, hash chain, and policy hidden mechanism, STDSM will be practically implemented in more complex EEC-driven data sharing scenarios, such as intelligent remote healthcare, ad hoc networks, and industrial IoT, to evaluate its effectiveness and practicality.