MLS-ABAC: E ffi cient Multi-Level Security Attribute-Based Access Control Scheme

Realizing access control to sensitive data o ffl oaded to a Cloud is challenging in the Internet of Things, where various devices with low computational power and di ff erent security levels are interconnected. Despite various solutions, the National Institute of Standards and Technology (NIST)’s Attribute-Based Access Control (ABAC) model is one of the preferred techniques in the literature. In this model, users who satisfy access policies using both static and dynamic attributes are allowed to access the data. However, NIST’s ABAC model does not support encryption and therefore does not satisfy data confidentiality. Attribute-Based Encryption (ABE) is a known cryptographic primitive that enables fine-grained access control over encrypted data. However, currently the existing ABE schemes do not meet NIST’s ABAC requirements or are not computationally e ffi cient enough for IoT applications. In this paper, we propose a Multi-Level Security ABAC (MLS-ABAC) scheme that satisfies the requirements of NIST’s ABAC model. Our construction is e ffi cient and relies on a decryption outsourceable Ciphertext-Policy ABE scheme. Additionally, based on realistic application scenarios, only the authorized data users can decrypt the ciphertext, and check the integrity of the retrieved message. Furthermore, we present both conceptual and formal models for our proposed MLS-ABAC architecture along with performance metrics. The experimental results show that the proposed MLS-ABAC achieves a constant ciphertext size of ∼ 230 bytes and with encryption and decryption running times of ∼ 18 and ∼ 10 milliseconds, respectively, independent of the number of attributes.


Introduction
The Internet of Things (IoT) is an evolving paradigm that enables wide-range connectivity among smart devices. With the intelligent nature of IoT networks and the openness of their associated applications, such as the Internet of Medical Things (IoMT), users can conduct real-time interactions any time and anywhere to take advantage of services such as tele-care [1]. This immediate connectivity undoubtedly raises information security and privacy challenges. Controlling user's conduct based on multiple access levels, i.e., multi-level access control mechanism, is critical. For example, only an authorized entity that fulfills the access control criteria for accessing the information in a healthcare network (e.g., roles and resources) can acquire access.
Besides, in the IoT networks, access control schemes should be energy-efficient. It means that the scheme proposed for being used in these systems must be lightweight to not impose high computational costs on resource-constrained elements of these systems. Using lightweight functions instead of heavyweight functions, such as lightweight hash functions, lightweight authenticated encryption function, etc. makes the access control scheme efficient.
Background: Envision an IoT system where the data owner (e.g., patient) stores his/her sensitive information in either local servers or cloud systems, while the end-user (e.g., employees in the hospital) can read that data with some pre-defined access control rules. In this scenario where the system's access control is static (define once -used multiple times), the system administrator would typically use a classic access control model like Role-Based Access Control (RBAC) [2]. In traditional RBACbased systems, the roles such as a doctor, nurse, and healthcare provider are assigned to the users, and the permissions of the roles are defined, i.e., to which objects/data in the system access is granted.
Generally, RBAC models cannot meet all the requirements of an IoT environment, such as heterogeneity and real-time. For instance, using personal mobile devices -the concept of Bring-Your-Own-Device (BYOD) -presents new security and privacy threats to the IoT that are not dealt with by RBAC. Luckily, there is an alternative solution called the Attribute-Based Access Control (ABAC) model. In ABAC, users can access the data if and only if they have all the associated attributes with the data. The basic ABAC model is based on a set of pre-defined and static attributes, such as "user identity," "user profession," and "user company," through which permissions are given to the users if they present all of the owned attributes. However, in this kind of ABAC system, a person with authorization will be able to access data for a lifetime, and from anywhere, with a mobile device. Some cases can cause privacy and security issues. For instance, assume the authorized user would access the confidential data in a public place, where there are many entities in close proximity, such as humans and espionage devices. There is a high risk that confidential data gets leaked in such a setting due to, for example, shoulder surfing or a camera recording. Alternatively, even worse, an attacker could access the data by stealing the mobile device. The problem here is (i) that there are no dynamic attributes that provide real-time verification and (ii) all the static attributes are stored inside the mobile device. As depicted in Fig. 1, the standard National Institute of Standards and Technology (NIST)'s ABAC model [3] consists of three kinds of entity attributes: (i) subject attributes, e.g., the role or the job title of the data user; (ii) object attributes, e.g., resource and files created by the data owner; and (iii) environment attributes, e.g., location and time. Using the full potential of NIST's ABAC model, i.e., employing both static and dynamic attributes (e.g., "time" and "location"), could overcome these problems. Dynamic attributes are derived from user behavior, so access is granted to the user who meets static attributes and provides dynamic attributes 1 .
However, we need to go even one step further. Due to the sensitivity of the information (e.g., healthcare records) outsourced to the cloud, this information should be securely stored (i.e., encrypted). Only an authorized user who has the security key should be able to read the information. Thus, integrating ABAC into Attribute-Based Encryption (ABE) provides us a possibility to encrypt the outsourced information and protect these from the cloud system itself. Using ABE, even if a cloud system were honest but curious, it would not be able to read the sensitive information.
Besides, it is not desirable in many applications that all information is accessible to all authorized users. This could cause unauthorized access to users who have sufficient features but only a lower security level. Specifying multi-level security (MLS) for the users and data enables two features: (i) users can access the information that is stored with the same security level as assigned to them, and (ii) at the same time prevents users from getting access to information for which they cannot satisfy the security level. Thus, MLS-based access control should be in place to ensure that access to confidential data is strictly controlled. Typically, MLS-based access control implicates Mandatory Access Control (MAC) such as the Bell-LaPadula (BLP) model [4] that uses security labels for both subjects and objects. However, there are several problems with MLS, such as "sanitization," "covert channels," and "bypass" that should be considered. Besides confidentiality, also data integrity is an essential issue in IoT applications. In fact, the data should not have been altered and an authorized user who decrypts the information must be sure of its integrity, validity and consistency. Moreover, for schemes where the decryption is outsourced, the correctness of this operation should be checked as well. Employing an authenticated encryption schemes would be an excellent solution to overcome these issues.
1-Subject requests access to Object. 2-ABAC access control mechanism assesses i) Rules, ii) Subject attributes, iii) Object attributes and iv) Environment conditions for authorization. 3-Subject is allowed access to Object if authorized. Recently, Perazzo et al. in [5] evaluate the performance of the Bethencourt et al.'s representative CP-ABE scheme [6], considering the worst-case scenario on two popular IoT platforms, namely ESP32 [7] and RE-Mote [8]. It is demonstrated that if the CP-ABE scheme in [6] employs up to 10 attributes in ciphertexts and leverage hardware cryptographic acceleration, it can actually be used on IoT applications with resourceconstrained devices. Thus, if the ABE scheme can have a constant execution time (e.g., with a better performance than [6] with 10 attributes) for its key generation, encryption, and decryption algorithms over total number of the attributes, it can easily be employed as a building block in ABAC for IoT applications. In the performance analysis section, we will discuss it in detail. Our Contributions: In particular, we proposed a multi-level security attribute-based access control (MLS-ABAC) scheme with below functionalities.
-Robust against compromised attacks: MLS-ABAC ensures that a data user who can present all the necessary static and dynamic attributes can access the information for which they can satisfy the security level.
-Compatible with IoT networks: MLS-ABAC is lightweight and can be used in the context of IoT. This efficiency gain primarily comes from our proposed efficient decryption outsourceable CP-ABE construction, which is fast, flexible and lightweight.
-Data Integrity: The data integrity of the plaintext in case of outsourced decryption is preserved using authenticated encryption scheme.
-MLS access control: By using the attribute token and access token, only the user who satisfies the security level embedded inside the access token and meets the required policies can get access the ciphertext labeled with this security level.
-Practical scheme: The effectiveness and efficiency of MLS-ABAC are evaluated using the charm-crypto framework.
Moreover, we formalized our proposed access control model to demonstrate that it can be applied in real-world applications and is compatible with the NIST's distributed ABAC model.

Roadmap:
The rest of the paper is organized as follows. The related work concerning the CP-ABE schemes is discussed in Sec. 2. The high-level overview of the proposed scheme is presented in Sec. 3. The necessary preliminaries and definitions and the main cryptographical building blocks and their security properties are formally defined in Sec. 4 along with our proposed decryption outsourceable CP-ABE. The proposed MLS-ABAC construction is defined in Sec. 5. The security requirements and the intuition behind the security along with the performance analysis are discussed in Sec. 6. In Sec. 7, we provide our implementation results and show how the MLS-ABAC construction is compatible with the IoT context. In Sec. 8, we discuss the introduced MLS-ABAC model in detail and its main applications and use-cases. Finally, we conclude the main contributions of the paper in Sec. 9.

Related Work
Although NIST's ABAC model has many deceptive benefits, this model faces various security vulnerabilities, such as attribute forgery and permission counterfeiting. This is especially noteworthy for open environments such as IoT. In what follows, we list the related works in the literature.

ABE schemes
An excellent solution for this problem is using cryptographic access control. An ABE scheme is a superior cryptographic tool for fine-grained access control of encrypted data, which is utilized in various applications [9]. Goyal et al. in [10], formulated two types of ABE schemes: (i) Key-Policy ABE (KP-ABE) and (ii) Ciphertext-Policy ABE (CP-ABE).
• In KP-ABE, the secret keys are labeled by a function f (.), and the sender is unable to alter it. So, KP-ABE allows the access policies to be determined in the setup phase and cannot be modified afterward.
• The CP-ABE embeds a (policy) function f (.) in the ciphertext to dictate which recipients are permitted access to the message's contents. In this method, the ciphertext gets a label depending on an arbitrary function f (.), and secret keys are paired with attributes in the domain of f (.). The plaintext can be decrypted by the receivers if and only if the data users' attribute set meets the condition f (.), that is, f (A) = 1. So, CP-ABE allows the data owner to define the access policies and data control.
In our paper, we use the CP-ABE for the design of our ABAC model, which is more suitable for access control schemes.
The first CP-ABE scheme, proposed by Bethencourt et al. in [11], enabled the protected data to satisfy access policies arbitrarily defined by the data owners with respect to any monotonic formula. The main drawback of this scheme is that it is based on the Generic Group Model (GGM), which is regarded as a weak security model. As a subsequent work, Cheung et al. [12] constructed a variant of the CP-ABE scheme in the standard model that is capable of dealing with constraints generated from any AND-gates circuit. Despite the short ciphertext size of this scheme, its policy function is limited to AND-gate circuits only. The decryption algorithm of this scheme requires a linear number of pairings which makes it inefficient in practice. Waters in [13] proposed a CP-ABE scheme that is asymptotically efficient in the standard model. Its design is based on a Linear Secret Sharing Scheme (LSSS) to construct an arbitrary access policy. As this scheme also requires a linear number of pairings to decrypt, it is not efficient in practice. In [14], the authors proposed a CP-ABE scheme that supports users' revocation based on lattices. However, their revocation mechanism is based on the principle that every time access permissions of a particular node need to be changed, the corresponding keys need to be updated for that node. This mechanism is not efficient.
The authors in [15] proposed an anonymous decentralized CP-ABE scheme based on bilinear pairings and secure outsourcing. However, their scheme does not support user revocation and delegation. They also employ cryptographic accumulators to verify the user's attributes anonymously. Moreover, the authors only consider static attributes. Cui et al. in [16] propose a key regeneration-free ABE scheme based on CP-ABE. This scheme is based on bilinear pairings and provides user key traceability for a user who delegates his/her decryption key. This scheme does not support dynamic attributes and user revocation.
In [17], the authors proposed a hierarchical ABE scheme that allows a trusted server to delegate part of its responsibility to other authorities, which can independently decide on the semantics of their attributes. Hierarchical ABE also allows for proxy re-encryption, but it forces a fixed structure for the access policies, limiting the flexibility of the access control system. In [18], Sedaghat et al. presented a decryption outsourceable Ciphertext-Policy Attribute-Based Signcryption (CP-ABSC) construction based on linear secret sharing schemes. Though authorized end users are given a constant computational complexity to decrypt a message, they must store a linear number of keys in the memory. Moreover, their architecture cannot accommodate the multi-level security paradigm. The CP-ABE scheme proposed in [19] can verify the correctness of the transformed ciphertext for authorized users and unauthorized users. This scheme is based on bilinear pairings and Message Authentication Codes (MAC). This scheme also does not provide user revocation. In Table 1, we compare the related ABE schemes in different aspects.

Multi-Level schemes
The authors of [21] and [22] both propose new ABE schemes and claim that their proposed schemes provide multi-level access control. As in classical ABE schemes, these schemes require that the data user satisfy a set of attributes to be able to decrypt any given encrypted data considering the access structure. But their proposed schemes does not offer multi-level access to encrypted data based on the security level of the data users. To address this issue, the authors of [23] proposed a new ABAC model with two layers of encryption on the data owner side and on the cloud side. However, in this model, the cloud performs an extra fine-grained encryption on top of the encrypted data, which is inefficient. Additionally, these schemes are not conform to NIST's ABAC model.

ABAC schemes
Another aspect to highlight is the mathematically grounded policy based on formal access control models. Our literature review for ABAC schemes based on ABE suggests that little or no effort has been made to provide a conceptual model. Gupta and Sandhu [24] proposed an administration model for Hierarchical Group and Attribute-Based Access Control (HGABAC) to control the assignment and removal of attributes, using three sub-models: User Attribute Assignment (UAA), User-Group Attribute Assignment (UGAA) and User to user-Group Assignment (UGA). However, they did not propose any scheme for their model. Bhatt et al [25] formalized a restricted HGABAC model called rHGABAC, and implemented their model in the NIST Policy Machine (PM) tool [26,27,28]. The authors of [29] propose an ABAC model based on a broadcast key management scheme for attribute-based access control based on Single-Layer Encryption (SLE) schemes. In this scheme, the data owner in the encryption phase enforces access control policies (ACPs). Despite SLE's improvement over its predecessors, it consumes a lot of computational and storage resources for changing the group key [30] regularly. The approach also requires that all ACPs to be enforced by encryption, both initially and subsequently after users are added or revoked. This encryption work must be done by the data owner, which incurs high communication and computation costs. In this paper, we formalize our proposed access control scheme by providing a conceptual and formal model, in contrast to prior work in ABEbased ABAC.
Additionally, it is our primary objective to minimize the ciphertext size, while existing CP-ABE schemes suffer from either a large ciphertext size or a high computational overhead. To accomplish this, CP-ABE schemes based on AND-gate circuits are considered promising candidates. Based on the concept of AND-gate circuits, several constant-size ciphertext CP-ABE schemes are proposed [31,32,33], their ciphertext contains at least one element of the target group.

MLS-ABAC Scheme Overview
This section provides an overview of the proposed scheme, including the proposed architecture and a high-level description of the proposed MLS-ABAC, which complies with NIST's ABAC model.
As illustrated in Fig Although the NIST's ABAC model supports all the ABAC functionalities, it does not provide data confidentiality. To overcome this shortcoming, we proposed the MLS-ABAC model, which not only works based on the original workflow of the standard ABAC model but also ensures data confidentiality.
Further, as stated in [34], in the ABAC models the cloud server may be required to search the entire database in order to grant one data to a data user. Consequently, retrieval times can be very long and, as a result databases are difficult to maintain. As part of our proposed MLS-ABAC scheme, the cloud server first determines the data user's security level, then searches the database based on the security level. Therefore, MLS-ABAC is more practical than traditional ABAC models.

MLS-ABAC Architecture
The architecture of our solution is illustrated in Fig. 3, there are five main entities, including: -Attribute Authority Server (AAS) is a trusted party that generates the system parameters and also the secret keys for the data users.
-Identity and Access Management Server (IAMS) creates tokens for users corresponding to their access security level based on sets of security levels. It is noteworthy that AAS creates, deletes and updates these sets and then submits them to the IAMS.
-Cloud Server (CS) acts as a repository and stores ciphertexts that are offloaded from IoT data producers. CS also checks the validity of the received tokens from another IoT device as a data consumer. Then CS decides whether access should be granted based on the defined predicate functions. It is assumed CS is honest-but-curious, which  means it follows the protocol while curious to learn sensitive data.
-Data Owner (DO) is an IoT data producer who wants to share a sensitive message amongst users by defining a security level. To this end, it generates a ciphertext that carries some metadata as well. Therefore, to prevent data leakage, the DO chooses the security level for the ciphertext and uploads both ciphertext and associated security level to CS.
-Data User (DU) is a lightweight IoT device that wants to read data from the CS using its credentials (i.e., data consumer). To this aim, it requests a token from the IAMS and then transmits it to CS. If the DU passes the verification phase, it can obtain the ciphertext. Finally, if DU's attributes satisfy the access policy, the DU can decrypt the ciphertext to learn the entire message; otherwise, it learns nothing.
As depicted in Fig. 3, in the proposed MLS-ABAC model, the PAP component relies on the AAS and DO, the PIP component relies on the DO, CS and DU and finally, IAMS, CS and DO are acting as PEP and PDP components that are entirely consistent with the standard ABAC model.

Multi-Level Security for ABAC
First, we would like to provide an example of MLS-ABAC as illustrated in Fig. 4.
In this example, {UserType, HospitalId} is the set of static attributes and {Section, Time} is the set of dynamic attributes. Our proposed model has a set of four security levels which are Top Secret, Secret, Confidential, and Unclassified where User A belongs to security level Top Secret, User B and User C belong to Secret, User D and User E belong to Confidential, and User F belongs to Unclassified security level. The admin of the system (here, IAMS) defines this partial order hierarchy among users and will update them when the system policy changes.
In this system, the entity User E can download the information which are uploaded in to the security levels Confidential and Unclassified, and can decrypt the ones that are wrapped with the User E's static and dynamic attributes. Further, if the security level for User E is upgraded to Secret, it can download the information which are uploaded in to the security levels Secret, and below, and can decrypt the ones that wrapped with the Anesthesiologist's static and dynamic attributes.
Based on the above scenario, the admin of the system easily can revoke or delegate the access right of the User E to the wrapped information uploaded in to the security level Secret.
As demonstrated above, the MLS-ABAC scheme should ensure that a DU who can present all the necessary static and dynamic attributes is allowed to access the information for which they can satisfy the security level. Besides, the information should be stored securely to the CS. Thus, the ABE scheme should encrypt the information in such a way that the encrypted data can only be accessed by DU who have the credentials for the defined attributes. Moreover, the data integrity of the plaintext in the case of outsourced decryption should be preserved using an encryption scheme that simultaneously verifies the confidentiality and authenticity of data. Therefore, a lightweight authenticated encryption scheme should be deployed. Therefore, by combining the observations above, we can now summarize the main building blocks in our proposed MLS-ABAC scheme: (i) CP-ABE, (ii) authenticated encryption and cryptographic hash function. In the next section, we  Figure 4: Multi-level Security with ABAC Example. 5 will zoom in on these different building blocks.

Building-Block Collection
In this section, we first provide definitions and preliminaries, and then provide the main building-block of the MLS-ABAC scheme including our proposed Decryption Outsourceable CP-ABE scheme, ASCON Cipher Suite [35] and JSON Web Token (JWT) [36].

Preliminaries and Definitions
Throughout the paper, we take λ as a predetermined security parameter, where negl(λ) denotes a negligible function. The i th component scalar of each set A is represented by A i . The notation x ←$ χ indicates that x is sampled uniformly according to a distribution χ. The integer numbers between 1 and n (i.e, the set of {1, . . . , n}) is expressed by [n]. For a randomized algorithm (out) ← alg(in), the term alg(in; r) assigns a certain random value r to the algorithm. For a given prime order field F, the set of univariate polynomials of degree less than d over F is denoted by F <d [X]. Finally, PPT stands for "Probabilistic Polynomial Time".
Definition 1 (Binary Representation of a Subset). For a given universe set U of size n, each subset A can be represented as a binary string of length n. Particularly, the i th element of a binary string for the set A ⊆ U is equal to 1 (i.e., We denote a binary representation set as a binary tuple (a [1], . . . , a[n]) ∈ Z n 2 .
Definition 2 (Zero-polynomial). For a finite set of U = {k 1 , . . . , k n }, we define the zero-polynomial Z A (X) for a nonempty subset of is the binary representation of the complement set A. In other words, this univariate polynomial vanishes on all the components of the set U such that the binary representation of the subset A is zero.
-For all [ Where we use bracket notation and for randomly selected generators g ∈ G 1 and h ∈ G 2 and [x] 1 denotes x · g ∈ G 1 . Moreover, we denote the pairing with square bracket notation asê(g a , Definition 4 ((l, m, t) -MSE-DDH assumption [38]). Under security parameter λ, we select an asymmetric bilinear group generator BG(λ) = (G 1 , G 2 , G T , p,ê). For given three integers l, m, t, let f and h be two univariate composite polynomials of degree l and m that vanishes on pairwise distinct points ⃗ x = (x 1 , . . . , x l ) and ⃗ y = (y 1 , . . . , y m ), respectively.
For randomly chosen integers α, δ, k ←$ Z * p , the (l, m, t)-Multi-Sequence of Exponents Diffie-Hellman assumption states that no PPT adversary A can distinguish between Γ = k f (α) T and a random element Γ ←$ G T with a non-negligible advantage, when given four tuples The advantage of a PPT adversary A for solving the (l, m, t)-MSE-DDH assumption is, Definition 5 (Access Structure [39]). Let P be a set of parties Consequently a monotone collection of non-empty subset of P is defined as a monotone access structure in which all the sets in this monotone collection are called the authorized sets. On the contrary, all the sets that are not in this monotone collection are called unauthorized sets.

Decryption Outsourceable CP-ABE Scheme
Next we propose a decryption outsourceable CP-ABE scheme with constant key and ciphertext size. This construction is under the formal definition of decryption outsourceable CP-ABE schemes which is formalized as follows.
Definition 6 (Decryption outsourceable CP-ABE). A decryption outsourceable CP-ABE scheme over message space M, ciphertext space C and a Boolean relation where Σ k is the set of key indices and Σ c denotes the ciphertext indices, consists the following PPT algorithms.
-(pp, msk) ← ABE.Pgen(λ, U): This probabilistic algorithm takes the security parameter λ and an attribute space as inputs and generates the pair of public parameters and master secret key (pp, msk).
-(dk x ) ← ABE.KGen(msk, x): This randomize algorithm takes a key index x ∈ Σ k and master secret key msk, and returns a private decryption key dk x underlying key index x ∈ Σ k .
-(Ct) ← ABE.Enc(pp, m, y): The encryption algorithm to encrypt secret message m ∈ M, gives public parameters pp and a ciphertext index y ∈ Σ c as inputs. It returns ciphertext Ct along with the underlying access rights y.
-(tk x , ϵ) ← ABE.Tgen(pp, dk x ): The token generation algorithm is a probabilistic algorithm that takes pp and a secret decryption key dk x and returns a corresponding token tk x along with some auxiliary information ϵ as outputs.
The partial decryption algorithm takes pp, a token tk B and underlying auxiliary information ϵ along with a ciphertext under access policy y ∈ Σ c . If Br(x, y) = 1, it computes the partially decrypted value pd x and auxiliary information ϵ ′ , otherwise, it responses by ⊥.
This deterministic algorithm to decrypt a ciphertext with access policy y takes pp and a valid secret decryption key dk x . It responses by m ′ ∈ M iff Br(x, y) = 1, else returns ⊥.
The main security requirements for a decryption outsourceable CP-ABE scheme are Correctness and INDistinguishability against Chosen Plaintext Attack (IND-CPA).
Definition 7 (Correctness). We call a decryption outsourceable CP-ABE scheme consistent if we have, -2 nd Query phase. Upon receiving the challenge ciphertext Ct * , A can query the oracles in the first query phase within the restriction that she cannot request the decryption of Ct * under key indices x i ∈ Q and challenge access policy y * .
-Guess. A guesses the bit b ′ ∈ {0, 1} and we say a PPT adversary A wins the IND-CPAsecurity game if she guesses the random bit b better than by chance.

For the advantage
For a given Type-III bilinear group pairing (G 1 , G 2 , G T , p,ê), the introduced CP-ABE scheme over AND-gate access structures (Definition 5) consists the following PPT algorithms. The encryption algorithm takes public parameters pp as inputs and encrypts a secret message m ∈ M under an access structure P ⊂ U. More precisely, it samples a random integer r ←$ Z * p , computes the Zero-polynomial
The token generation algorithm is a probabilistic algorithm that takes pp and a secret decryption key dk B and then samples a uniformly random integer µ ←$ Z * q . It finally returns tk B = dk µ B , C ′ 1 = C µ 1 and secret auxiliary value ϵ = µ as outputs. Proof. We prove this theorem in Appendix A.2.

ASCON Cipher Suite
In order to enable message integrity and prevent sending target group elements as part of the ciphertext, we integrate the ASCON cipher suite to combine provably secure authenticated encryption (Ascon-128) and hashing (Ascon-Hash) algorithms with our proposed ABE scheme [35]. Ascon-128 provides 128-bit security for confidentiality of plaintext as well as the integrity of both plaintext and associated data. Also, Ascon-Hash has output length of 256-bit and provides 128-bit security against collision and (second) pre-image attacks [35]. Our MLS-ABAC scheme consists of Ascon.AENC(·), Ascon.H(·) and Ascon.NGen(·) algorithms which are Ascon-128, Ascon-Hash and nonce generation functions described as follows.
Ascon-128 is a lightweight authenticated encryption/decryption scheme based on a sponge construction which uses 320-bit permutation boxes. Fig. 5 demonstrates all four states of the Ascon-128 encryption. The decryption process in Ascon-128 is the same as the encryption process with the only difference that after the assosiated data phase, the ciphertext is used instead of the plaintext in the third stage. The encryption process gets as input a plaintext of arbitrary length, a 128-bit secret key, a 128-bit nonce, and an associated data of arbitrary length. It then returns the ciphertext with the same length as the plaintext and 128-bit tag as the output. The tag will be used in the decryption process to authenticate both associated data and plaintext.
Initialization State. Initialization state of Ascon-128 consists of 320 bits named init and formed by the 128-bit secret key, a 128-bit nonce, as well as an initial vector (IV).
Associated Data. Associated data is additional data that is optional. Associated data is not encrypted and its integrity will be confirmed in the decryption process. The encryption and decryption processes of Ascon-128 are as below.

Algorithm 1: Ascon-128 Decryption Algorithm
Input: C, T C , nonce N, associated data A, secret key K Output: P or ⊥ 1 (P, T ′ C ) ← ADEC(K, N, A, C); 2 if T ′ C == T C then return: P 3 else return: ⊥ Decryption process. Algorithm 3 presents this process. This algorithm returns the plaintext P if the tag T C is verified. The Ascon-Hash function is based on sponges [40]. This hash function has an output length of 256-bit and uses the Algorithm 7 to generate this output, where p a is the a-round permutation. The architecture of the Ascon-Hash function is shown in Fig. 6.

Algorithm 2: Ascon-Hash Hashing Algorithm
Initialization. In Ascon-Hash, initialization state consists of a 320-bit bitstring named init Hash . This string contains an initial vector IV as well as 256-bit 0.

JSON Web Token Structure
JWT is a string comprising three parts, namely a header, a payload, and a signature. The header contains "alg" and "kid" which are the signing algorithm being used and a hint for the identity of the key used to secure the JWT, respectively. Since the IAMS has only one private/public key pair, "kid" is not used in our JWT. In our scheme we use the RS256 algorithm in which the digital signature algorithm is RSASSA-PKCS1-v1 5 using SHA-256 3 . The payload contains claims stored inside the JWT which are the security levels of the DU, the identity of the IAMS, and the expiration time/date of the Token. The last part of the JWT contains the signature of the header and the payload using the private key of the IAMS [36]. We use this Token (T K it ) for the information exchange process between DU and IAMS as well as the authentication process between DU and CS. Figure 7 shows an example of a header and payload in our scheme.  JWT is an encoded signed string that includes the DU claims as "sl":"security level(s)", "aud":"identity of the IAMS" and "exp":"Token expiration time". We use this Token (T K it ) for the information exchange process between DU and IAMS, as well as the authentication process between DU and CS. Due to the expiration time included in the JWT, it is only valid for a limited amount of time and it will fail to authenticate if the JWT is expired. An JWT scheme can be formalized using the following algorithms, which are based on our specifications.
-(sk, vk) ← JWT .svGen(λ): This algorithm takes the security parameter λ as input and returns the pair of signing and verification keys (sk, vk).
-T K it ← JWT .Tgen(sk, sl, aud, exp): This algorithm takes the signing key sk, DU's security level sl, the aud which is the identity of the IAMS, and the expiration date exp as inputs, and then returns the token T K it as output.
-(1, ⊥) ← JWT .Vf(vk, T K it ): This algorithm takes the token verification key vk and the token T K it as inputs. It checks the validity of the IAMS signature and the token expiration times and returns 1 in the case of acceptance, otherwise it responses by ⊥.

Proposed MLS-ABAC Scheme
In this section, we first explain both Ascon-128 and Ascon-Hash initialization states, and then we describe our proposed MLS-ABAC scheme which consists of seven PPT algorithms.

Ascon-Hash and Ascon-128 Initialization
The initialization phase of Ascon-Hash consists of 320 bits named init Hash and is defines as follows: init Hash = p a (0 8 ∥ns∥nd∥0 8 ∥h∥0 256 ) in which ns and nd denote the number Header: { "typ": "JWT", "alg": "RS256" } Payload: { "sl": "security level(s)", "aud": "identity of the IAM server", "exp": a number that indicates expiration time } of static attributes and dynamic attributes respectively. Each of these are defined as an 8 bits integer. Moreover, h = 256 is 32 bits integer and p a is the a-round permutation. Also, the initialization phase of Ascon-128 consists of 320 bits named init. In the proposed scheme, init can be derived as init = H 64 ∥K∥N in which H 64 is the first 64 bits of H = Ascon.H(ψ 1 ∥ψ 2 ∥ . . . ∥ψ m ∥d), K is 128 bits secret key and N is 128 bits nonce. Where, {ψ i } i∈[m] is a bit-string representation of the dynamic attributes and d is an element in the target group G T .

MLS-ABAC Construction
The proposed MLS-ABAC scheme is presented in Algorithm 3 and described as follows.
-AAS Parameter Generation: AAS by taking the security parameter λ and the attribute space U executes this probabilistic algorithm and returns the master secret key and public parameters of the system.
-IAMS Key Generation: This algorithm is executed by IAMS. It takes the security parameter λ and returns the pair of signing and verification keys (sk, vk) and publishes vk while keeps secure the signing key sk.
-Key Generation: This randomized algorithm is executed by AAS and produces the secret decryption key as output under the static attribute set B ⊂ U.
-Encryption: The encryption algorithm is executed by the DO and it is based on Ascon.AENC(·) and ABE.Enc(·) algorithms described in Sections 4.3 and 4.2, respectively. The DO determines the access rights to the secret encrypted message in both static and dynamic attribute sets and grants access to the ciphertext only to a specific group of DUs. In this algorithm, ψ 1 ∥ψ 2 ∥ . . . ∥ψ m are the bit-string representation of the m numbers of dynamic environmental attributes.
-Token Generation: In this probabilistic algorithm, the DU first sends the quary to the IAMS and requests a JSON Web Token T K it to get access to the stored ciphertexts in the CS. At this point, the IAMS decides whether DU is allowed to get access to a ciphertext with a certain security level (i.e., DU ∈ sl). To this end, IAMS generates the JWT token T K it signed with sk using JWT .Tgen(·) algorithm including security level and also expiration time and returns them back the DU. Next, the DU uses a valid private decryption key and executes the ABE.Tgen(·) phase of the proposed decryption outsourceable CP-ABE to generate (tk B ) to outsource the resource-intensive part of the computations to CS.
-Partial Decryption: The CS checks the validity of the DU's token by running the JWT .Vf(vk, T K it ) algorithm first. If the DU is allowed to have access to the stored ciphertext based on the given token T K it , then the ciphertext is partially decrypted and returned to the DU, otherwise it returns ⊥. It is important to stress that the JWT .Vf(·) algorithm verifies the IAMS signature and the token expiration date and the condition [sl ∈ Ct sl ] verifies whether the ciphertext that the DU requested has the security level mentioned in the Token's claim.
-Decryption: This algorithm uses a partially decrypted value along with a hidden auxiliary information µ that is used in the token generation phase to securely decrypt data. In this algorithm, {ψ ′ i } i∈[m] is a bit-string representation of the DU's dynamic attributes that should be equal to {ψ i } i∈ [m] . Also, H ′65 192 and H ′193 256 mean 128 bits of H ′ from 65-th bit to 192-th bit and the last 64 bits of H ′ , respectively.

Security and Performance
In this section, we briefly discuss the security intuition behind the proposed MLS-ABAC scheme and also provide a discussion about its performance.

Security Analysis
We informally discuss three main security features for the proposed MLS-ABAC construction in terms of correctness, the secrecy of the plaintext and token unforgeability. Confidentiality: This security feature makes it impossible for an adversary to learn meaningful information when (s)he does not comply with the ciphertext access rights. It is mainly derived from the concepts behind hard cryptographic assumptions like Discrete Logarithm and MSE-DDH assumptions and one-wayness of the underlying Ascon-hash function. Recall the IND-CPA security of the proposed CP-ABE, where no PPT adversary can win the defined indistinguishability security game. It is to be expected that an adversary without having knowledge on value d must correctly guess the inputs of the Ascon-hash function to execute the Ascon encryption successfully. Since the first cyclic group generator is hidden and the ciphertext is blinded by an initial random number, r, only those users who satisfy the ciphertext access right (i.e., [P ⊆ B]) can obtain the correct partially decrypted value pd B . Moreover, since the decryption tokens are generated using a uniformly random integer µ, only the users who generated this token can deduce d µ −1 by knowing µ and pd B . In addition, CS has no way to learn information from decryption tokens since they are re-randomized by the DU under a random integer µ. We assume Distributed Denial-of-Service (DDOS) and Replay attacks [41,42] resistance to be important yet orthogonal to our work.
Unforgeability: This security property ensures that an adversary A cannot generate a verifiable JSON web token unless the token is created by the IAMS. This naturally comes from the unforgeability nature of the the intended digital signature used in JWT. Moreover, since the proposed outsourceable CP-ABE scheme is secure against the collude attack, then an adversary in the CP-ABE's token generation phase cannot generate a decryption token beyond the authorized private decryption key and underlying attributes.

Performance Analysis
MLS-ABAC, as mentioned earlier, is based on our proposed decryption outsourceable CP-ABE scheme. This means that the performance of our CP-ABE construction determines the efficiency of the MLS-ABAC system. This section describes how the proposed CP-ABE scheme performs. More precisely, we compare our proposed scheme with the existing decryption outsourceable ABE schemes in terms of communication and computation costs. Additionally, we will evaluate the obtained results for the proposed MLS-ABAC experiment in Section 7.
It can be seen from Table 2 that our proposed decryption outsourceable CP-ABE employed in our MLS-ABAC scheme is more efficient and has less communication overhead in comparison with the existing IoT-friendly ABE schemes. Precisely, the time required to execute the encryption phase in our proposed CP-ABE varies by the total number of attributes minus the number of attributes intended to the policy without any pairing. In addition, since the heavy computational parts of decryption are outsourced to the CS, a DU only needs to compute one exponentiation to decrypt a ciphertext. The length of public parameters grows linearly with the total number of attributes in the network. As well, a DU only requires to store one single base group's element in the storage, while in the other constructions, this size increases linearly with the number of attributes of the DU. The proposed scheme also introduces only a small and constant ciphertext length that infects the communication overhead.
We will next evaluate the achieved experiments for the proposed MLS-ABAC with some well-known CP-ABE schemes in practice.

Our Results
In this section, we compare the performance of our proposed MLS-ABAC construction with Bethencourt et al. [6], BSW07 in short, and two recent works in the literature; Nasiraee et al. [15], NA20 in short, and Xiong et al. [20], XZPZY20 in short. We have chosen to evaluate our work with the BSW07 scheme because it is widely used in practical implementations. Moreover, as we mentioned before (cf. Section 1), BSW07 can be employed in an IoT context if it uses up to 10 attributes in ciphertexts. In this section, we show that our proposed CP-ABE construction is more efficient than BSW07 and has a constant execution time for encryption, decryption, and key generation. We also explain that our proposed CP-ABE is more efficient than the existing IoT-based construction such as BA20 and XZPZY20. Also note that, based on the applications, our construction is based on AND-gate circuits, whereas both NA20 and XZPZY20 schemes are proposed under a stronger Linear Secret Sharing Scheme (LSSS) approach.
We obtained the benchmarks on Ubuntu 20.04.2 LTS with an Intel Core i7-9850H CPU @ 2.60 GHz and 16 GB of memory. We implemented the construction by using the Charm-Crypto framework [43], a Python library for Pairing-based Cryptography 4 . We utilized a super-singular curve "SS512" with a base field size of 512 bits and an embedding degree of 2. Fig. 8 consists of six graphs depicting the following relationships.
-Total number of Attributes versus Setup time (top left graph): This graph displays the time required to generate the parameter of the system over total number of the attributes. The setup time, as an offline phase, in BA20 and XZPZY20 schemes increases linearly with the number of attributes, while BSW07 has a constant computational cost; our proposed construction has less complexity than BA20 and XZPZY20 and insignificantly more than BSW07. It is worth noting that this phase can be run offline and when considering for example a generous number of 1000 attributes, it only requires ∼ 250 milliseconds (msec).
-Number of attributes versus secret decryption key size (top centre graph): In this graph if we look at the size of Table 2: Computation and Communication Comparison. |G| and |G T | denote the bit-length of elements in base group G and target group G T , respectively. U and S denote the number of attributes in the universe attribute set and DU attribute set, respectively. L expresses the number of attributes in the access policy and y is the maximum number of elements in DU's attribute set in the system. F and I are the elements of the set of attribute mapping functions and the number of attributes used for decryption, respectively. ℓ is the bit-length of an access policy for the access matrix X and r is the number of the rows of X. Finally, P, M, and E are pairing, multiplication and exponentiation costs, respectively.

Scheme
Enc. Cost Dec. Cost pp. size dk. length Ct. length Nasiraee et al. [15] (2S Xiong et al. [20] P + (48S the secret keys over the total number of attributes owned by the users. We can see that this relationship is linear for BSW07, NA20 and XZPZY20 schemes. However our proposed scheme requires a quasi constant storage. For instance, in our scheme the required memory for secret keys is ∼ 1.3 kilobytes (kbytes) for 1000 attributes which is significantly lower the other schemes.
-Number of attributes versus key generation time (top right graph): This graph shows the relationship between the number of attributes of each user and the time to generate decryption key. As can be seen, this time for our scheme is constant -equal to ∼ 1 msec-while it grows linearly for the other schemes over the number of the attributes.
-Number of attributes versus Encryption time (bottom right graph): This graph displays the relationship between the number of embedded attributes in the policy and the Encryption time. As can be seen, the time required to encrypt a ciphertext in our scheme is constant (less than ∼ 20 msec), while in the other schemes, it grows linearly.
-Number of attributes versus ciphertext size (bottom left graph): This graph displays the relationship between length of ciphertext in link between sender and the cloud and the number of attributes in the access policy. As it is illustrated, our scheme achieves a constant size of ciphertext (less than ∼ 230 bytes) while in other schemes, it grows linearly with the number of attributes in the access policy. Noted this result is primarily due to the circuit level applied to the constructions.
-Number of attributes versus Decryption time (bottom center graph): This graph shows the relationship between the total number of attributes of each user and the decryption time. As can be seen, the time required to decrypt a ciphertext in all three decryption outsourceable constructions (Ours, BA20 and XZPZY20) is constant and is always less than ∼ 15 msec, while this overhead grows in BSW07 linearly with the number of attributes in the access policy.
Our MLS-ABAC scheme is lightweight because of two reasons: our proposed lightweight CP-ABE construction and the lightweight ASCON Cipher Suite. With our CP-ABE, the encryption phase is pairing-free and the heavy parts of the decryption phase can be outsourced to the CS (i.e., DU only needs to compute one exponentiation to decrypt a ciphertext). The DU only stores one element of the base group in the storage, regardless of the number of DU's attributes. Additionally, the proposed scheme has a constant ciphertext length, which does not increase with the number of attributes in the access policy. As a result, our proposed CP-ABE, which is used in our MLS-ABAC scheme, is more efficient and has fewer communication overheads than the existing constructions and provides the largest efficiency gain.
In addition to comparing the proposed CP-ABE scheme with other constructions, we would like to point out that our proposed scheme is more efficient than the BSW07 construction [6]. This is important because, based on the results presented in [5], any CP-ABE scheme with better performance than BSW07 can easily be implemented in an IoT context. In [5], the authors analyze the performance of the BSW07 construction, considering the worst-case scenario on two popular IoT platforms, namely the ESP32 [7] and RE-Mote [8]. By leveraging hardware cryptographic acceleration, the CP-ABE scheme in [6] can be used on IoT applications with resource-constrained devices if it employs up to 10 attributes in ciphertexts. According to the above discussion and the information presented in Table  2, both DO and DU have low computation and communication costs. Hence, our proposed MLS-ABAC scheme, based on our CP-ABE construction, as well as a lightweight ASCON Cipher Suite, is efficient enough to be applied in the IoT context.

Conceptual and Formal Model for MLS-ABAC
In Fig. 9, we illustrate the conceptual MLS-ABAC model followed by formal definitions in Table 3. The access control components involved in this model are Users (U), Subjects (S), Objects (OB), Security levels (SL), Identity and Access Management Services (IAMS), Attribute Authority Services (AAS), Cloud server services (CS), JWT Tokens (T), Operations on IAMS (OP ACC ), and Operations on objects in cloud server services (OP Token ). User Static Attributes (USA) and User Dynamic Attributes (UDA) are the set of user attributes for users and their associated subjects. Object Dynamic Attributes (OBDA) is the set of dynamic attributes assigned to data objects (OB). These attributes (which are only set-values specified by attType) can be directly assigned to users and objects to values from the set of atomic values (denoted by R(att)). These attributes are same as the dynamic attributes assigned to the subjects (UDA). The attribute function att u is the attribute function in USA ∪ UDA that maps a user to a set of values in the power set of R(att u ) and assigns attributes to the users. A similar function (att obd ) is defined for the objects associated with cloud services. In our MLS-ABAC model, users and their associated subjects are assigned to multiple security levels, which are denoted by the many to many function directUSL. The security levels hierarchy (SH) (the self-loop on SL), is a partial order relation on SL and presented by ⪰ sl . The equation sl 1 ⪰ sl sl 2 denotes that sl 1 is senior to sl 2 and sl 1 inherits all the security properties of sl 2 . A token (T) is assigned by the IAMS to a subject based on the witness provided by the subject. This token will have set of security levels, a timestamp and a creator IAMS, which will be assigned to the subject, as denoted by the one to one relation TA. The function security levels takes as input the subject along with the assigned token, and maps it to a set of security levels for which the subject is allowed to access the objects. Function issued by defines the IAMS which created the token. A subject s created by the user u (denoted by SubCreator) has a subset of the attribute values of its creator.
In Table 3, two authorization functions of our proposed MLS-ABAC are presented. The first one is the IAMS service token request authorization function (Auth op (s : S, sr : IAMS)) where op ∈ OP ACC and the second one is the data and service authorization function (Auth op (s : S, cs : CS, ob : OB)) where op ∈ OP Token operations.
More precisely, for Auth op (s : S, sr : IAMS), a subject s ∈ S is permitted to perform an operation op ∈ OP ACC (i.e., receiving the access token) when the security level in IAMS is satisfied (i.e., the accumulator parameters from the subject and its security level satisfied the policies stated in IAMS). Similarly, for Auth op (s : S, cs : CS, ob : OB), a subject s ∈ S is permitted to perform an operation op ∈ OP Token (i.e., accessing to the object ob ∈ OB) when the security level of the object in CS is satisfied (i.e., Auth access (s : S, t : T, cs : CS) = True, meaning the security level stated in the token satisfied the policies stated in CS) and the attributes of s ∈ S satisfied the attributes of object ob. Thus, a subject s is permitted to perform an operation on an object ob in a service cs iff Auth receive token (s : S, iams : IAMS),  -TA ⊆ T × S, a one to one relation for binding a token to subject. -security levels : S × T → 2 SL , mapping each subject and its assigned token to allowed security levels. Formally, security levels (s,t) = {sl ∈ SL | (sl, iams, timestamp) = t ∈ T ∧ (t,s) ∈ TA}. -issued by : T → IAMS, mapping a token to its issuer IAMS. Formally, issued by (t : T) = iams ∈ IAMS such that (sl, iams, timestamp) = t.
-SubCreator : S → U, mapping each subject to its creator user.
-∀ att u ∈ USA ∪ USDA. att u : S → 2 R(attu) maps subjects to a set of static and dynamic attribute values. It is required that : att u (s) ⊆ att u (SubCreator(s)).
-directUSL: S → 2 SL maps each subject to a set of security levels.
Authorization Functions -IAMS Service Authorization Function: For each op ∈ OP ACC , Auth op (s : S, sr : AAS) is a propositional logic formula returning true or false, which is defined using the following policy language: -α ::= α ∧ α | α ∨ α | (α) | ¬α | ∃x ∈ set.α | ∀x ∈ set.α | set△set | atomic ∈ set | atomic set -△ ::=⊂ | ⊆ | ⊈ | ∩ | ∪ -set ::= att u (s) | directUSL(s) for att u ∈ USA ∪ UDA -atomic ::= value -Cloud Service Authorization Function: For access operation on cloud service cs from subject s using the token t, Auth access (s : S, t : T, cs : CS) is a propositional logic formula returning true or false and defined using the above policy language stated above with the following changes: -set ::= att u (s) | issued by(t) | security levels(s,t) for att u ∈ USA ∪ UDA -atomic ::= value -Data Objects Authorization Function: For each op ∈ OP Token on object ob ∈ OB belonging to cloud server service cs ∈ CS, Auth op (s : S, cs : CS, ob : OB) is a propositional logic formula returning true or false and defined using the above policy language stated above with the following changes: -set ::=att u (s) | att obd (ob) | directOBSL(ob) for att u ∈ USA ∪ UDA, for att obd ∈ OBDA -atomic ::= value Access Operation Decision -A subject s ∈ S is allowed to perform an operation op ∈ OP ACC to receive an access token which is created by a service sr ∈ IAMS, if the policies stated in the authorization function, i.e the security levels of the subject assigned by the AAS as a part of witness and the accumulator parameters in IAMS satisfy Auth op (s : S, sr : IAMS) . Formally, Auth op (s : S, sr : IAMS) = True. -A subject s ∈ S is permitted to perform an operation op ∈ OP Token on an object ob ∈ OB in cloud server service cs ∈ CS with a token t ∈ T, if subject s is permitted to access services cs based on the Token t and the attributes of subject and object satisfy the required policies. 14 Auth access (s : S, t : T, cs : CS) and Auth op (s : S, cs : CS, ob : OB) returns True.

Use-case and Application for MLS-ABAC
An example MLS-ABAC configuration is illustrated in Fig.  10. Here, a user who wants to access the data creates a subject (here, DU) with the subset of the user's attributes. Then, DU sends the token request along with the witness to the IAMS and receives the token T K it including the user's security level. At this point, DU generates the token tk B based on his attributes and sends it to the CS along with the token T K it . In response, if these tokens can pass both the authentication and authorisation steps, CS partially decrypts the ciphertext and returns this value to the DU for decryption. Finally, DU who has already generated the token tk B can decrypt the partially decrypted message and access the data. The details of this example that explains the policies Auth access and Auth op are as follows.
A user Bob has attributes UserType(Bob) = {Doctor}, UserId(Bob) = {d67890}, Section(Bob) = {Surgery, Pharmacy}, HospitalId(Bob) = {h135}, and Time(Bob) = {07:00-15:00}. An initialized subject S has attributes which are the subset of Bob attributes who is its creator. In this subset, the dynamic attribute Section only includes value 'Surgery' meaning this subject only can decrypt the encrypted data (read objects) that are wrapped with the dynamic attribute Section with value 'Surgery' and Time with value {07:00-15:00}. After creating the subject, it is permitted to receive the access token 't' from IAMS if the subject can prove its membership in at least one security level (SL). We have a security hierarchy SH , a total order relation on SL such that SH = {(SL1, SL2), (SL2, SL3), (SL3, SL4)}.
A subject is permitted to download, decrypt and perform an operation op on an object ob in cloud server service cs if the policy Auth access (s:S, t:T, cs:CS)=True ∧ Auth op (s:S, cs:CS, ob:OB)=True is satisfied meaning that the subject s is permitted to access services cs based on the token 't' and the effective attributes of subject s (the subject that has static and dynamic attributes can generate Tk B token), attributes of cloud server services (the security level), and the attributes of object ob (both static and dynamic attributes). For example, a policy Auth access (s:S, t:T, cs:CS) ≡ {SL2, SL3, SL4} ∈ security levels(s,t) ∧ issued by(t) = iams ∈ IAMS, meaning that the subject received the valid token with security levels SL2, SL3, and SL4 which was created by an IAMS, and can access the wrapped data objects stored in SL2, SL3, and SL4 levels of the cloud service cs, i.e all data objects ob such that directOBSL(ob) is equal to SL2, SL3 or SL4.

Conclusion
In this paper, we proposed a novel outsourceable MLS-ABAC scheme based on both static and dynamic user attributes in combination with the assigned security level that satisfies the requirements of NIST's ABAC model. Our proposed ABE construction is based on CP-ABE with a constant decryption key size. Adding a security level verification before partial decryption facilitates the management of the access control and improves the security and privacy of IoT systems. Using lightweight functions instead of heavyweight functions, such as lightweight Ascon-hash and Ascon authenticated encryption functions, as well as our proposed lightweight CP-ABE, makes MLS-ABAC efficient. Besides considering security level verification and dynamic attributes, MLS-ABAC also protects the data integrity of the plaintext in case of outsourced decryption, using an authenticated encryption scheme. Moreover, to demonstrate the use-case and application of our proposed MLS-ABAC scheme, we formalize our proposed access control model by providing a conceptual and formal model as well as performance metrics. The results of our implementation and a brief comparison of proposed scheme performance with predecessor work provide an excellent incentive to use MLS-ABAC in some real-world IoT scenarios. We leave the implementation of our proposed MLS-ABAC on an IoT platform as future work. Another open question is the construction of an efficient MLS-ABAC under a general Boolean relation.
B ∈ Σ k can retrieve message encrypted under access policy P ∈ Σ c iff P ⊆ B.
Appendix A.2. Proof of Theorem 2 Proof. We plan to prove this theorem by the reduction. Let there exists a Probabilistic Polynomial Time (PPT) adversary, A, who can break the proposed scheme in the introduced security game in Definition 8 with a non-negligible advantage of ϵ. Then we are going to show that how a PPT adversary B can solve (l, m, t)-MSE-DDH problem defined in 4 with a nonnegligible advantage of at least ϵ 2 . In fact, B takes on the role of the challenger and utilizes the adversary A in order to solve the mentioned hard problem.
Let the challenger C of Decisional (l, m, t)-MSE-DDH hard assumption runs the asymmetric bilinear group generator BG(λ) for the security parameter λ and takes (G 1 , G 2 , G T , p,ê) such that [1] 1 , [1] 2 and [1] T be the generators of the defined cyclic groups. The challenger C first chooses three integers l, m, t, along with two univariate coprime polynomials f and h of degree l and m with pairwise distinct roots ⃗ x = (x 1 , . . . , x l ) and ⃗ y = (y 1 , . . . , y m ). It samples integers α, δk ←$ Z * p uniformly at random and then flips a fair coin, β ←$ {0, 1}, outside B's view. If β = 0, C sets Γ = k f (α) T , otherwise, it sets Γ = R, where R is a random element of the target cyclic group G T . The challenger C sends Γ and the pair of vectors ⃗ x and ⃗ y along with ⃗ v 1 = , [kh(α)] 2 to the adversary B.
Initialization: In this phase, the simulator B sets the universe attribute set of U as the all possible attributes in the defined network and a collision-resistant Hash function H ←$ H. Then B publishes U and receives back the challenge access policy P * along with the query set Q as a group of attribute sets B i ⊆ U for i ≤ s, such that |B i | ≤ e from A and also P * ⊈ {B i } s i=1 (i. e., Bf(B i , P * ) = 0 for 1 ≤ i ≤ s. At this point, B computes the following polynomial that is the multiplication of zero-polynomials corresponding for the chosen subsets B i in the query set Q.
Where b i [ j] represents the j th binary representation of subset B i . The degree of univariate polynomial Y Q (x) is bounded by s(n − e). Moreover, since B knows h(x) = m i=0 (x − y i ), it is assumed Z P * (x) = Y Q (x)h(x) such that |P * | = n − (s(n − e) + m). This can be feasible by defining hash function H in the Random Oracle Model. Although the generator of the first cyclic group is not public, she assumes G = f (α)Y Q (α) 1 as a new generator for the cyclic group G 1 . To generate g 2 under the new generator it computes f (x)Y Q (x) = l+s(n−e) j=0 p j x j and we have, 1 st Query phase. The adversary A after receiving the public parameters has access to the following oracles for a polynomially bounded number of queries.
Simulating the O KGen (B i ) oracle. The adversary A has access to this oracle which is provided by B, to receive private decryption key corresponding to the attribute set B i ∈ Q. In this end, B calculates the univariate polynomial Λ i (x) to simulate secret decryption key, such that f (x)Y Q (x) = Λ i (x) · Z B i (x). Based on the definition of polynomial Y Q (x), we know it is divisible by Z B i (x) and we can rewrite the above equation as Λ i (x) = ( f (x)Y Q (x))/Z B i (x). Since the polynomial Λ i (x) is not rational then we can take the coefficients in the standard basis as Λ i (x) = q j=0 λ j x j and f (x)Y Q (x) = l+s(n−e) j=0 p j x j . Finally, the challenger returns the following equation as the simulated secret decryption key dk B i corresponding to key index B i .
Simulating the O Enc (m, P) oracle. The adversary A can adaptively request to encrypt arbitrary messages from the message space M under a certain access structure P. The challenger B samples a random integer r ←$ Z * p , uniformly and computes the following equations and sends back the tuple Ct = (P, C, C 1 , C 2 ) to A. The only condition is that (m−2) ≥ n−|P|+1, i.e., |P| ≥ n−m+3.
Simulating the O Tgen (dk B , C) oracle. It takes a correctly generated decryption key dk B and the cipher value C as inputs. It selects a random integer µ ←$ Z * p . It returns tk B = dk µ B along with C ′ 1 = C µ 1 . Simulating the O Dec (pd B , C; µ) oracle. The adversary A has access to this oracle to receive the full decryption of Ct by providing partially decrypted value pd B . It returns m ′ = C · pd 1/µ B as output. 17 Challenge: The adversary A chooses two same length plaintexts {m 0 , m 1 } ←$ M × M and sends them to B. Then B flips a fair coin to have the biased bit b ←$ {0, 1}, and computes the challenge ciphertext Ct * = (P * , C * , C * 1 , C * 2 ) as follows, It is assumed r * = k/(αY Q (α)) as the randomness for the challenge ciphertext. To put it in a nutshell, based on (l, m, t)-MSE-DDH assumption, there are two cases for the received challenge Γ with the same probability 1/2. If Γ = k f (α) T then C * = m b k f (α) T = m b r * α f (α)Y Q (α) T and also C * 2 = [kh(α)] 2 = r * αY Q (α)h(α) 2 = [r * αZ P * (α)] 2 are in the correct format. While in the case of an independent and random element in the group G T , the computed C * is a random element out of the construction and the adversary can distinguish by chance.
2 nd Query phase. The adversary A after receiving the challenge ciphertext Ct * has access to the defined queries in the first phase on the condition that she cannot query the partial decryption and decryption oracles.
Guess. Afterwards, A returns back a bit b ′ . Let β ′ be the value that is guessed by B about the value of β. If b ′ = b, B outputs β ′ = 0, i.e, Γ = k f (α) T . Otherwise, B outputs β ′ = 1, which indicates that it receives a random element in the cyclic group G T . When β = 1, the adversary A obtains no information about b. So she can guess by chance and we have Pr[b ′ = b | β = 1] = 1/2. On the other hand, when b ′ b, the guess value by the adversary B is β ′ = 1, so we have Pr[β ′ = β | β = 1] = 1/2. Particularly, if β = 0, A can distinguish with a non-negligible advantage ϵ because she has received the true format of the ciphertext for the message m b . Thus, we have Pr[b ′ = b | β = 0] ≥ ϵ + 1/2. As adversary B correctly guesses the value of β when β = 0, we have Pr[β ′ = β | β = 0] ≥ ϵ +1/2. Therefore, the overall advantage of the adversary B in solving the (l, m, t)-MSE-DDH problem is, Therefore, the adversary B can play the (l, m, t)-MSE-DDH game with non-negligible advantage ϵ 2 . By contradiction, since we know there is no PPT adversary B to break the (l, m, t)-MSE-DDH assumption with a non-negligible advantage, then the proposed CP-ABE scheme in 4.2 is secure in the IND-CPA game.