An Attribute-Based Approach toward a Secured Smart-Home IoT Access Control and a Comparison with a Role-Based Approach

: The area of smart homes is one of the most popular for deploying smart connected devices. One of the most vulnerable aspects of smart homes is access control. Recent advances in IoT have led to several access control models being developed or adapted to IoT from other domains, with few speciﬁcally designed to meet the challenges of smart homes. Most of these models use role-based access control (RBAC) or attribute-based access control (ABAC) models. As of now, it is not clear what the advantages and disadvantages of ABAC over RBAC are in general, and in the context of smart-home IoT in particular. In this paper, we introduce HABAC α , an attribute-based access control model for smart-home IoT. We formally deﬁne HABAC α and demonstrate its features through two use-case scenarios and a proof-of-concept implementation. Furthermore, we present an analysis of HABAC α as compared to the previously published EGRBAC (extended generalized role-based access control) model for smart-home IoT by ﬁrst describing approaches for constructing HABAC α speciﬁcation from EGRBAC and vice versa in order to compare the theoretical expressiveness power of these models, and second, analyzing HABAC α and EGRBAC models against standard criteria for access control models. Our ﬁndings suggest that a hybrid model that combines both HABAC α and EGRBAC capabilities may be the most suitable for smart-home IoT, and probably more generally.


Introduction and Motivation
The Internet of Things (IoT) describes the network of physical objects (things) that are embedded with sensors, software, and other technologies to connect and exchange data with other devices and systems over the Internet [1]. IoT has been used in a wide variety of applications, including infrastructure applications (smart cities, energy management), consumer applications (smart homes, elder care), organizational applications (medical and health care, vehicular communication systems), industrial applications (manufacturing, agriculture), and military applications (Internet of Battlefield Things).
In 2017, the global market for the Internet of Things (IoT) surpassed USD 100 billion in revenue for the first time, and forecasts suggest that the figure will rise to USD 1.6 trillion by 2025. As a result of such a prognosis, it is predicted that the technology will reach heights that no one could imagine. However, with the growing popularity of IoT devices, there will be an increase in IoT security concerns.
Smart homes are among the most popular areas for deploying smart connected devices. They are changing our lifestyles. However, with new opportunities come new challenges. Surprisingly little attention has been paid to access control policy specification and authentication in home IoT. Smart homes differ from traditional computing domains in many notable ways [2]. Home-IoT users have complex social relationships and use the same devices. In addition, most smart-home devices lack screens and keyboards, which makes them more convenient, but makes access control management more difficult. Several real-world examples of the deficiencies of current policies and authentication procedures for controlling access to home-IoT devices have emerged [2][3][4].
To attain the best results and minimize risks and threats, an organization must select an appropriate access control model in light of its diverse structure, requirements, and specifications. Several access control models have been described in the literature for IoT in general, a few of which have been developed specifically for smart homes. Most of the proposed IoT AC models are based on ABAC or RBAC. According to some researchers, RBAC is better suited for IoT since it is easier to manage and review, whereas ABAC is more challenging [5][6][7]. Other researchers assert that ABAC models are more scalable and dynamic because they can capture information about different devices and contexts. However, RBAC models can be extended to be dynamic and fine-grained. For example, the recent EGRBAC (extended generalized role-based access control) model [8] for smarthome IoT. EGRBAC can express environment and device characteristics and is suitable for constrained home environments. Therefore, in the case of smart homes, it is not completely clear what the advantages of ABAC over RBAC are, and vice versa.
In this paper, we introduce H ABAC α , an attribute-based access control model for smart-home IoT. Our model is dynamic and fine-grained. It captures users, environment, operations, and devices characteristics. We provide a detailed formal definition of our model and illustrate its features through two use-case scenarios and a proof-of-concept implementation.
Furthermore, we compare H ABAC α to the previously published EGRBAC model for smart-home IoT [8]. We chose to compare H ABAC α against EGRBAC for the following reason. EGRBAC is a dynamic contextual-aware RBAC-based access control model specifically designed to meet smart-home challenges. Our primitive insight is that a hybrid approach will better address smart-home IoT access control requirements, as this was the case for some traditional access control domains. However, this insight needs to be further explored by comparing RBAC and ABAC-based models specifically defined to meet smart-home challenges. In addition, this comparison will serve as a guide in developing appropriate hybrid models. Toward this goal, in this paper, we provide approaches for constructing H ABAC α specification from EGRBAC and vice versa to compare the theoretical expressiveness power of these models. Then, we evaluate these models against standard criteria for access control models adapted from [9] The paper is organized as follows. In Section 2, we provide an analysis and review of related work, including an overview of EGRBAC [8]. In Section 3, we introduce the H ABAC α model along with two use-case scenarios and a proof-of-concept implementation. Furthermore, we conducted different test scenarios to depict the performance of our implementation. In Section 4 we compare between EGRBAC and H ABAC α in terms of theoretical expressiveness power. In Section 5 we conduct a comprehensive theoretical comparison between EGRBAC and H ABAC α against standard criteria for access control models. Section 6 discusses the insights of this work. Finally, Section 7 concludes the paper.

Related Work
Presently, IoT is one of the most researched topics in the literature. However, the entire IoT ecosystem still faces security challenges, from manufacturers to users. A number of researchers have studied IoT security and privacy issues [10][11][12][13][14][15]. Furthermore, some researchers have investigated the security risks and design concerns of IoT frameworks [15][16][17][18][19][20]. Most researchers generally accept that access control is a critical service in IoT.
The literature has presented many access control solutions (users to devices and/or devices to devices) that apply to different IoT applications. In [21], the authors extensively surveyed access control in IoT environments. However, few of them explicitly addressed smart-home challenges.
Some solutions rely on RBAC [22,23] (as in [5,8,[24][25][26][27][28][29]). Other solutions, however, rely on ABAC [30,31]. For instance, the authors in [32] introduced an ABAC-based model that focuses on device-to-device access control. However, they did not illustrate their model through a performance analysis or at least a use-case scenario. In [33,34] the authors focused on providing sophisticated attribute-based encryption (ABE) models for smart grids, while they did not discuss the ABAC models that they consider. Additionally, for computationally constrained smart-home devices, an ABE model may not be appropriate. In [35] the authors introduced a formalized dynamic and fine-grained ABAC model for smart cars, which does not apply to the smart-home case. Recently, Bhatt et al. [36] proposed a conceptual attribute-based access control and communication control model for IoT. However, their access control model does not capture environment attributes. Our proposed H ABAC α model is an ABAC-based model that is dynamic and fine-grained. Moreover, it captures the characteristics of users, environments, operations, and devices.
Some researchers argue that contrary to ABAC-based models, RBAC-based models fail to capture changing characteristics such as environment attributes (time of the day, weather information) and device characteristics (device type, device state). However, the authorization process in RBAC is much simpler. Therefore, a combined access control model has been proposed by [6].
Additionally, the literature proposes several models that are based on blockchain technology [37][38][39][40][41]. However, as described by [39], blockchain technology possesses some technical characteristics that could limit its application, such as processing time and cryptocurrency fees. Only a few solutions based on UCON [42][43][44] have been presented in the literature, e.g., [45][46][47]. There have been some other access control models proposed for the Internet of Things. For example, in [48] the authors presented a certificate-based device access control scheme in an IoT environment. Researchers in [7,21,[49][50][51] conducted surveys on different IoT access control models in the literature.
The authors of [2] presented a new perspective on home-IoT access control policies. They argued that smart-home IoT has unique characteristics that necessitate a rethinking of access control. However, few solutions in the literature are proposed specifically to meet smart-home IoT challenges. Here are some examples. In [32], the authors provided a device-to-device ABAC access control framework for smart homes. The authors in [24] introduced an RBAC-based access control model for aware homes. Moreover, in [52] the authors used identity-based encryption to implement a function-based access control model in smart homes. In [53], the authors proposed a protocol for authentication and key exchange in smart homes. Researchers in [54] developed a high-level access control mechanism for a multi-user and multi-device smart-home environment.
Based on analysis by He et al. [2] and a survey by Ouddah et al [21], Ameer et al [8] recently presented criteria for home-IoT access control models. Moreover, the same authors proposed the EGRBAC model. It is a policy model for smart-home IoT access control, which is based on RBAC and conforms to both of the [2,8] characteristics. As opposed to traditional RBAC, EGRBAC captures contextual environmental changes and different devices characteristics. Therefore, it refutes the argument that RBAC-based models are unsuitable and rigid when dealing with changes in the environment and device or permissions characteristics. Therefore, it is not entirely clear what the advantages of ABAC over RBAC are, and vice versa, in the setting of home IoT. In this paper, we analyze H ABAC α (our proposed ABAC-based model) compared to EGRBAC [8] (a dynamic, fine-grained RBAC-based model), and vice versa. We briefly review this model below since it is relevant to Sections 4.1 and 4.2.

Background: EGRBAC Model
Ameer et al introduced the extended generalized role-based access control model [8]. It is a dynamic, fine-grained RBAC-based model that grants access based on the specific permission required rather than at device granularity. In addition to the usual concept of user roles, EGRBAC incorporates the notion of device roles and environment roles. This is illustrated in Figure 1. EGRBAC uses the familiar User (U), Role (R), and Session (S) sets in RBAC [22,23]. The term "user" refers to a person who uses smart-home devices as authorized. Roles (R) are similar to the traditional RBAC user roles. Nevertheless, in the case of smart homes, a role explicitly represents the relationship between a user and his or her family. Roles are assigned to different users through the many-to-many relationship UA. The system allows users to establish sessions to activate a subset of the roles they have been assigned to. A user may have more than one session active at the same time. SU is a many-to-one relationship that maps each session to its unique, controlling user. SR is a many-to-many relationship that maps each session to the set of roles associated with it.
A Device (D) is a smart-home device such as a smart door lock. Operations (OP) represent actions performed on devices according to manufacturer specifications. A permission is an approval to perform an operation on one device, i.e., it is a device-operation pair. Furthermore, as a way of categorizing permissions for different devices, device roles (DR) are defined. For example, we can categorize the dangerous permissions of various smart devices by creating a device role called dangerous devices and assigning dangerous permissions (such as turning on the oven, turning on the mower, and opening and closing the front door lock) to it. The many-to-many PDRA relationship specifies this assignment.
Environmental contexts, such as daytime/nighttime and winter/summer, are captured through the environment roles (ER) component. Environment roles are turned on/off (i.e., triggered) by environment conditions (EC). EA maps each environment role er i to the subset of related environment conditions EC i . It implies that when each ec i ∈ EC i is active, the environment role er i is also active. For example, suppose the environment role Entertainment_Time should be active on weekend evenings. To express this environment role in EGRBAC, we create the environment condition weekends, which will be active during the weekend, and the environment condition evenings, which will be active during the evening and add the relationship ({weekends, evenings}, Entertainment_Time) to the set EA.
Each role pair rp i ∈ RP combines a role and a subset of environment roles. A role pair rp has a role part rp.r that is the single role associated with rp, and an environment role part rp.ER denotes the set of environment roles associated with rp and is a subset of ER. RPRA associates each role to one or more role pairs. RPEA associates each role pair to a subset of ER. A role pair rp i is active, when each environment role er i in the set of environment role ER i is active, where ER i is associated with rp i through the relation RPEA.
All these components are brought together by RPDRA, which assigns device roles to role pairs. Therefore, for each role pair rp, the single role associated with it through RPRA rp.r can access all device roles assigned to it through RPDRA, as long as the set of environment roles associated with rp through RPEA, which is rp.ER is active.
Essentially, the basic idea in EGRBAC is that a user is assigned a subset of roles and, according to the current active roles in a session and the current active environment roles, some role pairs will be active, giving the user access to the permissions assigned to the device roles assigned to the currently active role pairs. Figure 1 illustrates EGRBAC.
EGRBAC describes three types of constraints. (a) Permission-role constraints. These constraints prevent specific roles from accessing specific permissions during assignment time. This type of constraint is applied to the RPDRA relationship. For example, if we have a permission-role constraint prc i , where prc i = ({(Oven, On)}, {Kids}). This constraint prevents any rpdra i assignment relation from being added to the set RPDRA, if rpdra i gives the role Kids access to the permission (Oven, On). (b) Static Separation of Duty (SSD) is the familiar SSD in RBAC. It enforces constraints on the assignment of users to roles. This type of constraint is applied to the UA relationship. (c) Dynamic Separation of Duty (DSD) is the familiar DSD in RBAC. With DSD, it is permissible for a user to be authorized as a member of a set of roles that do not constitute a conflict of interest when acted independently but produce policy concerns when allowed to be acted simultaneously [55] in the same session. This type of constraint is applied to the SR relationship.

H ABAC α Model for Smart-Home IoT
Models based on ABAC are arguably well-suited for sophisticated domains, such as smart homes. By using attributes of users, sessions (subjects), environments, operations, and objects, they can specify dynamic, flexible, and fine-grained authorization policies. This section introduces our H ABAC α (Home-IoT Attribute-Based Access Control) model. This model governs smart-home user-to-device interactions.

Formal Definition
The H ABAC α model is inspired by [31,56]. The basic model components are illustrated in Figure 2 and are formally defined in Tables 1 and 2

Basic Sets and Functions
-U is a finite set of users (homeowner-specified) -S is the set of sessions (each session is created, terminated and controlled by an individual user) -S is the set of sessions (each session is created, terminated and controlled by an individual user) -The function user(s) : S → U maps each session to its unique creator and controlling user -D is the set of devices deployed in the smart home (homeowner-deployed) -OP is the set of possible operations on devices (device manufacturer-specified) -The function ops : D → 2 OP specifies the valid operations for each device (device manufacturer-specified) -ES = {current} is a singleton set where current denotes the environment at the current time instance Attribute functions and values -USA, DA, OPA and ESA are sets of user/session, device, operation and environment-state attribute functions respectively, where for convenience we require USA, DA, OPA and ESA to be mutually exclusive -Each session s inherits a subset of the attribute functions in USA from its unique user creator (controlled by the session creator user(s)). For every inherited attribute function att ∈ theUSA, att(s) = att(user(s)) at all times unless otherwise specified use of a non-inherited session attribute in a logical formula renders that formula false -For each attribute att in USA ∪ DA ∪ OPA ∪ ESA, Range(att) is the attribute range, a finite set of atomic values -attType : USA ∪ DA ∪ OPA ∪ ESA → {set, atomic}.
-Each att ∈ theUSA ∪ DA ∪ OPA ∪ ESA correspondingly maps users in U / sessions in S, devices in D, operations in OP or the environment-state current to atomic or set attribute values. Formally: att : U or S or D or OP or {current} → Range(att), if attType(att) = atomic 2 Range(att) , if attType(att) = set -Every att ∈ theUSA ∪ DA ∪ OPA ∪ ESA, att is designated to be either a static or dynamic attribute where dynamic attributes must have corresponding sensors deployed in the smart home (under homeowner control) -Static attribute ranges and values are set and changed by administrator actions (by homeowner or device manufacturer) -Dynamic attribute ranges and values automatically determined by sensors deployed in the smart home (under homeowner control) Constraints -U AConstraint ⊆ U AP × 2 U AP is the user attribute constraints relationship (homeowner-specified) where Each uac = ((usa x , v y ), U AP j ) ∈ U AConstraint specifies the following invariant: -SAConstraint ⊆ U AP × 2 U AP is the session attribute constraints relationship (homeowner-specified) Each sac = ((usa x , v y ), U AP j ) ∈ SAConstraint specifies the following invariant: if attType(usa x ) = attType(usa m ) = set

Attributes Authorization Function
-Authorization(s : S, op : OP, d : D, current : ES) is a logic formula defined using the grammar of Table 2 (homeowner-specified). It is evaluated for a specific session s i , operation op k , device d j and environment-state current as specified in Table 2 CheckAccess Predicate -CheckAccess is evaluated when session s i attempts operation op k on device d j in context of environment-state current -CheckAccess(s i , op k , d j , current) evaluates to true or false using the following formula: Attribute authorization function -Authorization(s : S, op : OP, d : D, current : ES) is a first-order logic formula specified using the following grammar.

Basic Sets and Functions
User set (U) refers to human beings communicating directly with smart objects (things). The system allows users to create sessions during which they can perform some operations on the system. Sessions (S) operate similarly to subjects in [31]. Only the user who initiates the session has the authority to terminate it. Each session s is associated with its unique user creator by the function users(s).
Devices (D) refer to smart-home devices (smart things); for instance, smart TV. Operations (OP) are activities performed on devices in accordance with manufacturer specifications. The function ops(d) maps each device d to the set of valid operations on d.
The Environment States set (ES = {current}) is a singleton set that only includes the state "current". The state current denotes the picture of the environment at the current time instant. However, future extensions of this component, for instance, may be ES = {current, yesterday, lastweek}, which include other instants of time such as yesterday and last week. However, such generalization requires a careful investigation on how we will track time and to what extent.

Attribute Functions and Values
Each of the users, sessions, environment states, devices, and operations possess characteristics that are expressed as their attributes. An attribute is a function that takes an element such as a user and returns a certain value from its range. User/Session attribute functions set (USA) is the set of attributes associated with both users and sessions. Each session s inherits a subset of the attributes of its unique user creator. This is controlled by the unique user creator user(s). If a session s inherited a user session attribute usa from his user user(s), then it is required that usa(s) = usa(user(s)). The device attribute functions set (DA) consists of attributes related to smart devices, such as "kitchen devices" and "Alex devices". The operation attribute functions set (OPA) is a collection of attributes corresponding to different operations. For example, if you wish to characterize kid-friendly operations, you may create an operation attribute entitled "Kid-Friendly Operations" and associate it with those operations. Environment-state attribute functions set (ESA) describes the environment condition of the current instance of time. For example, "day", "time", and "weather condition".
To better demonstrate the concept of attributes, we will use the use case illustrated in Figure 3. We should mention that this use case is incomplete since it does not contain an authorization function. However, the main purpose is to illustrate the concept of attributes. In this use case, we have three users bob, alex, and anne. The user/session attribute function Relationship captures the user relationship to the home. From Figure 3 we can notice that bob is the parent, alex is the kid, and anne is the teenager in the house. The user/session attribute function UserLocation captures the user's current location inside the house. Moreover, we have four devices TV, Oven, Fridge, and FrontDoor. We have one device attribute function DangerouseKitchenDevices. DangerouseKitchenDevices captures whether the device is a dangerous kitchen device or not. Finally, we have two environmentstate attribute functions, day and UsersInTheHouse, which capture the current day and users inside the house, respectively. The main reason for using different sets of attribute functions for different components in our model is that different components have different attribute functions. For instance, the user/session attribute function Relationship is not relevant to the set of devices D. Moreover, the device attribute function DangerouseKitchenDevices does not apply to the set of users. We cannot consider a specific user as a dangerous kitchen device; the evaluation DangerouseKitchenDevices(bob) is not semantically correct.
Basically, an attribute range is composed of a finite set of atomic values. Each attribute function att i has a range Range(att i ), where Range(att i ) represents the range of values to which the attribute function att i can be evaluated. For example, in Figure 3, the user/session attribute function Relationship range is {parent, kid, teenager}, the user/session attribute function UserLocation range is {Bedroom1, Bedroom2, Gameroom, Kitchen, Livingroom, Bathroom1, Bathroom2}. Similarly, the device attribute function DangerouseKitchenDevices range is {True, False}, the environment-state attribute function day range is {S, M, T, W, Th, F, Sa}, and finally the environment-state attribute function UsersInTheHouse range is the set of users U.
Each attribute function is an atomic-valued attribute or a set-valued attribute. An atomicvalued attribute will return exactly one value from its range. In the use case given in Figure 3, the user/session attribute functions Relationship and UserLocation are both atomic-valued attributes since they map different users into one value only from the attribute range. The device attribute function DangerouseKitchenDevices is an atomicvalued attribute too. It takes one device as an input and returns only one value from the attribute function range as an output, either True or False, since one device cannot be dangerous and non-dangerous at the same time. Similarly, the environment-state attribute function day is an example of an atomic-valued attribute.
On the other hand, a set-valued attribute will return a subset of the range, and not only one value from the range as in the case of atomic-valued attribute functions. For instance, in the use case given in Figure 3, the environment-state attribute function UsersInTheHouse is a set-valued attribute. UsersInTheHouse attribute function has a range equal to the set of users U, and it maps the environment state to a subset of values from that range. It returns a set with the names of users who are currently inside the house.
Moreover, we distinguish between two types of attributes: static and dynamic. All attributes indeed may change over a long time. However, some attributes are "relatively" static, as they tend to remain static (they evaluate to the same values) over a long period of time. Setting and changing the values of static attributes may require administrator intervention. For example, in our use case, the user/session attribute function Relationship is considered static. To further illustrate this, let us consider the user alex. The attribute function Relationship, in this case, evaluates to kid, which tends to remain constant for a long time till alex grows up and becomes a teenager, at which point an administrator action is required to change the value of this attribute to teenager; as a result, Relationship(alex) will evaluate to teenager. Similarly, DangerouseKitchenDevices is considered a static device attribute too.
On the other hand, dynamic attributes are always changing due to various circumstances, such as time of the day, user location, etc. In our use case, UserLocation, day, and UsersInTheHouse are all considered to be dynamic attributes. Values of dynamic attributes are automatically determined by sensors deployed in the smart home and under homeowner control.
User/session attribute functions, device attribute functions, operation attribute functions, and environment-state attribute functions can all be classified as static or dynamic attribute functions. Moreover, all attribute functions can be classified as static or dynamic, whether atomic-valued or set-valued. However, the differentiation between static and dynamic attribute functions is unnecessary for how the model works formally. The process for triggering different attributes is outside the scope of our model.
Operation and device attribute functions are partial functions. Hence, some devices or operations will not be associated with some attributes. User/Session and environment-state attributes, on the other hand, are total functions.
In mathematics, a partial function f from a set X to a set Y is a function from a subset S of X (possibly X itself) to Y [57]. Since operation attribute functions and device attribute functions are defined as partial functions, in the use case illustrated in Figure 3, the device attribute function DangerouseKitchenDevices does not have to map each device d in the set of devices D into a value from the range {True, False}. The DangerouseKitchenDevices attribute function only maps the devices Oven and Fridge into the values True and False respectively. However, it does not map the devices TV and FrontDoor into any value. In other words, DangerouseKitchenDevices(TV) will be evaluated to be undefined.
On the other hand, total functions are defined for all elements in its domain. That being said, any static or dynamic attribute function att in the set of user/session attribute functions USA is defined for every user u i in the set of users U. For instance, the user/ session attribute function Relationship is defined for every user u in the set of users U. Moreover, any static or dynamic environment-state attribute function att in the set of environment-state attribute functions ESA is defined for every environment state es in the set of environment state ES.
All other values are undefined

Constraints
These are invariants that must never be violated. There are two types of constraints defined by HABAC α . First is constraints on user attributes. These constraints impose restrictions on user attributes. In other words, if a specific attribute value is assigned to a user, the user is prohibited from being assigned to another attribute value. For example, consider the following user attribute constraint: The above constraint implies that for any user u if Relationship(u) = kid, then it is required that Adults(u) = True.
The second type of constraint is constraints on session attributes. These constraints restrict the attributes that may be used in sessions. Here, it is permissible for a user to be assigned to different attribute values that do not constitute a conflict of interest when inherited independently by different sessions but produce policy concerns when allowed to be inherited together in the same session.
The concept of constraints is an integral part of H ABA α , and it is a powerful mechanism for laying out higher-level policy. When specific attribute values are declared to be mutually exclusive, there is less concern about assigning conflicting or mutually exclusive attribute values to individual users. H ABAC α is an operational access control model. Managing and enforcing constraints is part of the administrative access control, which is outside the scope of this manuscript.

Attributes Authorization Function
A two-valued Boolean function is evaluated for each access decision. It is defined using the grammar of Table 2. For a specific session s i , operation op k , and device d j the authorization function Authorization(s i , op k , d j , current) is evaluated by substituting the actual attribute values of usa(s i ), da(d j ), opa(op k ) and esa(current) for the corresponding symbolic placeholders and evaluating the resulting logical formula to be true or false. Any term that references an undefined attribute value is evaluated as false.
The term refers to any atomic logical declarative sentence. An atomic sentence is a type of declarative sentence that is either true or false and which cannot be broken down into other simpler sentences [58]. Consider Use Case A for more illustration.
H ABAC α is an operational access control model. Authorization function creation, check, and management tasks are considered part of administrative access control, hence outside the scope of this model.

Check Access Predicate
The CheckAccess predicate is evaluated in each access request. When a session s i attempts operation op k on device d j in the context of environment-state current the CheckAccess (s i , op k , d j , current) predicate evaluates to be true if the following conditions are satisfied: 1.
The operation op k is assigned to the device d j by the device manufacturer.

2.
The authorization function is evaluated to be true.

Use Cases
In this section, we describe two use cases to illustrate the components and configurations of H ABAC α .

Use Case A
In this use case, the goals are as follows: (a) Kids should be allowed to use kidfriendly operations on entertainment devices (G and PG contents on TV, A3 (games for group aged below three years old), and A7 (games for children under the age of seven) on PlayStation) during a specific time (weekend afternoons and evenings, and weekday evenings). (b) Teenagers should only be permitted to use dangerous kitchen devices (Oven) if one of their parents is present in the kitchen. (c) Provide teenagers with unconditional permission to use non-dangerous kitchen devices (Fridge). (d) Provide teenagers with unconditional access to entertainment devices. (e) Parents should be permitted to use any operation on any device without restrictions. Figure 4 illustrates how H ABAC α can be configured to achieve these objectives. Here, we have five users, bob, alex, suzanne, john, and anne with user attribute Relationship respectively assigned to the values parents, kids, kids, teenagers, and teenagers. Upon creation of a session s, this session will automatically inherit a subset of attributes from user(s). There are five devices TV, PlayStation, Oven, Fridge and FrontDoor. Oven, and Fridge are assigned the following device attributes by the house owner Fridge ← (DangerouseKitchenDevices: False), and Oven ← (DangerouseKitchenDevices: True). There are 12 operations G, PG, A3, A7, A12, BuyGames, ON, OFF, Open, Close, Lock, and Unlock. These operations are assigned to operation attributes as follows: (G, A3, and A7) ← (KidsFriendly: True), while (PG, A12, BuyGames) ← (KidsFriendly : False). Since device attribute functions and operation attribute functions are partial functions, all other operations and devices attributes values are undefined. Any term that references an undefined attribute value is evaluated as false. The environment-state current has three attribute functions (day, time, and ParentInKitchen).
The authorization function is a disjunction of five propositional statements. The disjunctions between different propositional statements are marked red for semantic illustration purposes only. In the first statement, children have access to kid-friendly operations on weekday evenings or weekends in the afternoons and evenings. Here,

Use Case B
The objectives of this use case are as follows: (a) Kids should be allowed to use kidfriendly operations on the iPad (A5, and A8 contents (applications for the group aged below five years old and below eight years old, respectively) during a specific time (weekends afternoons and evenings, and weekdays evenings). (b) If a parent is not present in the house, a teenager should not use dangerous devices (FrontDoor). (c) Give teenagers unconditional access to the iPad. (d) Parents should be permitted to use any operation on any device without restrictions. Figure 5 illustrates how H ABAC α can be configured to achieve these objectives. Here, we have three users, bob, suzanne, and john with user attribute Relationship respectively assigned to the values parents, kids, and teenagers. Upon creation of a session s, this session will automatically inherit a subset of attributes from user(s). There are three devices iPad, FrontDoor and lawnMower. FrontDoor is assigned to the following device attributes by the house owner FrontDoor ← (DangerouseDevices : True). There are nine operations A5, A8, A11, Games, Movies, ON, OFF, Lock, and Unlock. These operations are assigned to operation attributes as follows: (A5 and A8) ← (KidsFriendly : True), while (A11, Games, and Movies) ← (KidsFriendly : False). Since device attribute functions and operation attribute functions are partial functions, all other operations and devices attributes values are undefined. Any term that references an undefined attribute value is evaluated as false. The environment-state current has three attribute functions (day, time, and ParentInTheHouse).
The authorization function is a disjunction of four propositional statements configured to maintain the four objectives of this use case.

Enforcement Architecture
H ABAC α is an abstract policy model that can be used with different enforcement models. Each enforcement model can use different implementation models which incorporate different underlying technologies.
Here, we adopted the smart-home IoT enforcement architecture shown in Figure 6, which was first introduced by Geneiatakis et al. [59]. According to this architecture, IoT devices are directly connected to a corresponding hub. Thus, other devices and users cannot access them directly. Here, there are two types of access. Local access provides users with direct access to the IoT devices through the connectivity services provided by the hub. Remote access allows users to access IoT devices remotely via cloud services. These cloud services then communicate with the smart hub over the Internet.
Moreover, we used the Amazon Web Services (AWS) IoT service [60] as an implementation technology to implement Use Case A presented in Section 3.2. However, in our enforcement, we only handled local access.
First, we created an AWS account, then we configured and deployed Greengrass [61]. Through Greengrass SDK (Software Development Kit), cloud capabilities can be extended to the edge, which is the smart home. Hence, Greengrass acts as a hub and a policy engine within the smart home. Greengrass was installed on a dedicated virtual machine with one virtual CPU, two GB of RAM, and running on Ubuntu server 18.04 LTS. Second, we simulated the five users (the devices which users use to access the smart things, e.g., their phones) and the five devices (the smart things that users want to access) of Use Case A using the AWS IoT device SDK for Python [62] provided by AWS on different virtual machines. Each machine has one virtual CPU and two GB of RAM running Ubuntu server 18.04.5 LTS. Third, we created one virtual object (digital shadow) for each physical device (smart thing devices needing access or a user access device) using the AWS IoT management console. Each physical device is cryptographically linked to its shadow by a digital certificate accompanied by authorization policies. Devices and users communicate with the AWS IoT service using MQTT protocol [63] with TLS security [64]. The MQTT standard is a lightweight machine-to-machine (M2M) publish/subscribe messaging protocol designed explicitly for use by constrained devices. Each shadow has a set of predefined MQTT topics/channels to interact with other IoT devices and applications.

Use Case A Enforcement
To enforce Use Case A, we created four json files as follows, UsersAttributes.json, DevicesAttributes.json, OperationAttributes.json, and EnvironmnetAttributes.json to capture different users/session attributes, devices attributes, operations attributes, and environment attributes, respectively. How to automatically update different attributes values in these files is outside the scope of this work. Moreover, we used the AWS IoT lambda function to receive different user requests, analyze those requests according to the contents of the json files, allow or deny the requested accesses, and then trigger the corresponding devices to carry out the desired action. The code is written in Python 3.7 and runs on a long-lived lambda function with a memory limit of 500 MB and a timeout of 30 s.  Figure 7 depicts the sequence of actions in our local communication implementation. Sequence (a) illustrated in red demonstrates the sequence of actions when a request is denied. Sequence (b) in green illustrates the sequence of actions when a request is authorized. For instance, if the user wishes to turn on the smart oven using his smartphone from inside the house, first, through the publish/subscribe relationship between the user's phone and the local shadow, a request is initially sent via MQTT protocol to the virtual object (or local shadow) corresponding to the user phone in Greengrass. Upon receiving the request, the local shadow sends the message to the lambda function using the MQTT publish/subscribe protocol. After that, the lambda function analyzes the request based on UsersAttributes.json, DevicesAttributes.json, OperationAttributes.json, and EnvironmnetAttributes.json files and makes the decision.

Local Communication Handling
If the request is denied, the lambda function publishes to the user's shadow update topic. When the local shadow becomes aware of this, it updates the user's phone. During this scenario, the smart oven does not receive any indication that someone is attempting to access it. In the event that the request is granted, the local shadow of the smart oven will be notified through its update topic, and the smart oven will be updated accordingly. Once the oven is turned on, it publishes a message to the shadow update topic. A notification is sent from the oven's local shadow to the lambda function, which in turn notifies the user phone's local shadow. As a final step, the shadow of the user's phone informs the user's phone that the smart oven has been turned on successfully.

Performance Results
In this section, we evaluate the performance of our implementation by conducting multiple test cases. We examined three different situations with three different sets of requests. Each set of requests was executed ten times to determine the average lambda processing time.  Table 3 shows the average lambda function execution time measured when one user sends requests to more than one device at once. The first row shows the average lambda execution time when Bob requests to lock the front door lock. The second row shows the average lambda execution time when Bob requests to lock the front door lock, turn on the TV, and turn on the PlayStation simultaneously. Finally, the third row shows the average lambda execution time when Bob requests to lock the front door lock, open the fridge, and turn on the oven, the TV, and the PlayStation. All the requests were approved as they were supposed to according to our configured policies. Table 3. One user sending requests to multiple devices. The values presented in Table 4 represent the measured average execution time of the lambda function when multiple users are sending requests to multiple devices at the same time (one user per device). The first row describes the average execution time when the parent Bob requests to lock the front door lock. The second row shows the execution time when Bob requests to lock the front door lock, the kid Alex requests to turn on the oven, and the teenager Anne requests to open the fridge simultaneously. Additionally, the third row describes the average time when the access requests tested in the second row are repeated, the kid Suzanne requests to turn on the TV, and the teenager John requests to open the oven while one of the parents is in the kitchen. The majority of the requests were approved except for those when Alex attempted to turn on the oven, which is not allowed according to our configuration, and when Suzanne tried to turn on the television, which is not permitted according to our configuration since testing was performed on a Monday morning. Table 4. Multiple concurrent instances of one user sending request to one device.  Table 5 displays the average execution time of the lambda function when multiple users simultaneously send requests to one device. The first, second, and third rows show the average time when one user (the parent Bob), three users (the parent and the two kids), and five users (the parent, the two kids, and the two teenagers) respectively all request to lock the front door lock at the same time. All the requests were denied except for when the parent Bob requested to lock the front door lock. Table 5. Multiple users sending requests to one device.

H ABAC α vs. EGRBAC in Terms of Theoretical Expressiveness Power
Our goal in this section is to determine if any EGRBAC configuration can be expressed fully in the H ABAC α model, and vice versa, and if not, which model is more expressive and in which terms. The approach used in this section is an extension of the previously published approach in [56].

From EGRBAC to H ABAC α
Here, we introduce the H ABAC α configuration that translates EGRBAC configuration to be implemented by H ABAC α model.
In this configuration, for differentiation purposes, every EGRBAC component is followed with the suffix EGRBAC . Similarly, every H ABAC α component is followed with the suffix H ABAC α . The configuration of H ABAC α for a given EGRBAC configuration is shown in Table 6.
Essentially, the objective is to be able to translate any EGRBAC configuration towards its equivalent H ABAC α configuration, so that the authorizations in the H ABAC α match those under EGRBAC. Both systems have the same users, devices, and operations. In H ABAC α , roles are expressed using the user/session attribute Relationship. This attribute takes as an input a user or session and returns a set of roles that have been assigned to that user or session.
Constraints related to the static separation of duties SSDConstraints are mapped into constraints related to user attributes in H ABAC α . Similarly, constraints related to the dynamic separation of duties are mapped into session attribute constraints in H ABAC α .
Environment roles are mapped into atomic environment-state attributes that have a range of possible values equal to {True, False}. True indicates that the environment state is currently satisfied or the equivalent environment role in EGRBAC should be active. False indicates that the environment state is currently not satisfied or the equivalent environment role in EGRBAC should be inactive. It is outside the scope of this model to explain how to trigger different attributes of the environment state in response to changes in the environment.
In EGRBAC, device roles are ways of categorizing permissions. In H ABAC α , we do not have permissions. Hence, we translate device roles in EGRBAC into atomic operation attributes and atomic device attributes with a range of values equal to {True, False}. If a permission p x = (op x , d x ), where p x ∈ P EGRBAC is assigned to the device role dr y , where dr y ∈ DR EGRBAC , then da y (d x ) = True and opa y (op x ) = True, where opa y ∈ OPA H ABAC α , da y ∈ DA H ABAC α , and opa y and da y are the operation and device attributes which were created to be equivalent to the device role dr y ∈ DR EGRBAC .
In the final step, we construct the authorization policies. In EGRBAC, the RPDRA provides specific role pairs and consequently users with access to specific device roles and therefore permissions. Therefore, an authorization function is created for each rpdra i = ((r i , ER i ), dr i ) ∈ RPDRA. Each authorization function is then a disjunct in the final authorization function.
At the end of the translation process, there is a single user/session attribute, which is Relationship. The number of user attribute constraints is equal to the number of SSDConstraints. The number of subject attribute constraints is equal to the number of DSDConstraints. The number of operation attributes and the number of device attributes equals the number of device roles. The number of environment-state attributes is equal to the number of environment roles. - -Initialize the authorization function Authorization(s : S H ABAC α , op : OP H ABAC α , d : D H ABAC α , current : ES H ABAC α ) -For each rpdra i = ((r i , ER i ), dr i ) ∈ RPDRA H ABAC α , we construct an authorization function as follows: 1.

4.
Authorization EGRBAC grants access to a specific set of permissions through a series of assignments, as explained in Section 2.1. RPDRA is the most important assignment, which assigns device roles to role pairs. To put it another way, controlling RPDRA allows us to decide which role pairs and, therefore, roles are authorized to access specific device roles and, subsequently, permissions. In H ABAC α , however, no such point of vulnerability or "attack point" can be controlled to prevent specific access. Therefore, we are unable to create something equivalent to EGRBAC PRConstraints in H ABAC α . Only by checking individual requests to access permissions and searching for prohibited users will it be possible to ensure that particular prohibited users will not be granted access to particular permissions. EGRBAC offers the advantage of the ability to enforce such constraints at the time of assignment, whereas H ABAC α -like models would need to enforce them at the time of enforcement.
To summarize, the construction of H ABAC α shown in Table 6 is equivalent to the given EGRBAC configuration, including static and dynamic separation of duty constraints. Since the construction is straightforward and one-for-one, the claim of equivalence is intuitively logical. Ref. [65] can be used for a formal argument.

From H ABAC α to EGRBAC
Throughout this section, we will describe our methodology for generating EGRBAC components and configurations from H ABAC α configuration. This methodology is inspired by the approach proposed in [56], which follows a bottom-up role engineering approach. It applies for H ABAC α policies containing environment attributes and static user/session, operation, and device attribute functions. However, it is incapable of handling policies that compare two different types of attributes. As a result of certain limitations in EGRBAC, it is either impossible to capture policies involving dynamic user/session, operation, and device attribute functions or extremely expensive (resulting in a role explosion).
In the following sections, we describe our approach and demonstrate it step by step. Our demonstration starts from Use Case B introduced in Figure 5 and applies our methodology to construct its equivalent EGRBAC configuration.

From Authorization Function to Authorization Array
Here, as a preliminary step, we first transform the authorization function into a disjunctive normal form (DNF). In Figure 8, we display the authorization function of Use Case B, which is presented in Figure 5 after transforming it into a DNF format by following the standard approach.
We call each conjuncted term a condition. We have the session, environment, device, operation, and mix conditions, which receptively involve user/session, environment, device, operation, and more than one type of attribute. In Figure 8 we have six conjunctive clauses. There is one conjunctive clause per access authorization rule.  To build the authorization array we examine every u i ∈ U, d j ∈ D, and op k ∈ OP combination against each conjunctive clause, whenever a combination satisfies every term (condition) in a conjunctive clause except those conditions that involve environment-state attributes, where we create a row (u i , d j , op k , current, C) for that combination in the authorization array. C denotes the set of session and environment-related conditions in the evaluated conjunctive clause. When evaluating a combination u i , d j , op k against a conjunctive clause, unsatisfying a device condition means that either the condition is not true for the evaluated device d j , or the condition references an undefined attribute value for the evaluated device d j . Similarly, unsatisfying an operation condition means either the condition is not true for the evaluated operation op k , or the condition references an undefined attribute value for the evaluated operation op k . Finally, unsatisfying a user condition means that the condition is not true for the evaluated user u i .
Authorizations array (AA): an authorization of row (u i , d j , op k , es l , C) denotes that the user u i is allowed to perform an operation op k on a device d j during the environment state es l whenever the set of environment and session conditions in C are satisfied. Table 7 provides the AA for Use Case B. Different colors represent authorization fields for different users.

Approach
The goal is to construct EGRBAC elements, assignments, and derived relationships from H ABAC α policies so that the authorizations are the same as those under H ABAC α . In this construction, for differentiation purposes, every EGRBAC component is followed with the suffix EGRBAC . Similarly, every H ABAC α component is followed with the suffix The inputs are H ABAC α components U H ABAC α , D H ABAC α , OP H ABAC α , USA H ABAC α , ESA H ABAC α , OPA H ABAC α , DA H ABAC α , and the authorization array AA. The outputs are EGRBAC components U EGRBAC , R EGRBAC , U A EGRBAC , EC EGRBAC , ER EGRBAC , EA EGRBAC , RP EGRBAC , RPRA EGRBAC , RPEA EGRBAC , D EGRBAC , OP EGRBAC , P EGRBAC , DR EGRBAC , PDRA EGRBAC , and RPDRA EGRBAC . The steps are following: Step 1: Initialization. Both systems have the same set of users, devices, and operations, hence U EGRBAC = U H ABAC α , D H ABAC α = D H ABAC α , and OP EGRBAC = OP H ABAC α . For every operation op i , and device d j pair, where op i is assigned to d j by the device manufacturers, create a permission.
Step 2: Create the set of device roles DR EGRBAC . (a) Create a device role dr for each operation attribute instance or device attribute instance. DR here are represented as a condition of the form opa = x, or da = x. Where x is an instance of the attribute value. (b) Create one device role called remaining permissions RemPerm for all the permissions p l = (d i , op j ), where d i is not assigned to any device attributes, and op j is not assigned to any operation attribute. This device role captures the cases where some users have access to specific permissions directly without involving the device's or operation's attributes.
Step 3: Build the permission device role assignment array PDRA. It is a many-to-many mapping of P EGRBAC set and DR EGRBAC set (constructed in Step 2). To construct PDRA we first make a column for each dr ∈ DR EGRBAC , and make a row for each permission p ∈ P EGRBAC . Then, we fill the array PDRA, where PDRA[i, j] = 1 in two cases, first if for the permission p i (corresponding to the row i) p i .op or p i .d satisfies the condition corresponding to the device role of the column j dr j . Second, if p i .op is not assigned to any operation attribute, and p i .d is not assigned to any device attribute, and the device role corresponding to this column is RemPerm. PDRA[i, j] = 0 otherwise. For every PDRA[i, j] = 1, add the pair (p i , dr j ) to the set PDRA of EGRBAC. See Table 8 for the PDRA array of Use Case B.
Step 4: Build the user device role authorization array UDRAA from the authorization array AA, and PDRA. UDRAA ⊆ U EGRBAC × DR EGRBAC , a many-to-many mapping between U EGRBAC and DR EGRBAC . To construct UDRAA, we first make a row for each user, and a column for each device role. Then, for every UDRAA[i, j] ∈ UDRAA we check the AA for every u i , and p x combination, where (p x , dr j ) ∈ PDRA. u i is the user corresponding to the row i, while dr j is the device role corresponding to the column j in UDRAA. Here, we have three cases: (a) UDRAA[i, j] = 1 if user u i can access all the permissions assigned to the device role dr j without any condition.
where Y is a set of conditions sets. Each conditions set is a set of session, and environment conditions that need to be satisfied together for a u i to access all the permissions assigned to dr j . Please note that these sets of conditions must be the same for each permission assigned to dr j . (c) Finally, UDRAA[i, j] = 0 if user u i is not allowed to access all the permissions assigned to the device role dr j , or is allowed to access different permissions in dr j but under different set of conditions. Table 9 shows UDRAA for Use Case B.
Step 5: Follow the EGRBAC users and environment roles constructing algorithm presented in Section 4.2.3 to construct the rest of the EGRBAC components (R EGRBAC , EC EGRBAC , ER EGRBAC , RP EGRBAC ), assignments (U A EGRBAC , EA EGRBAC , RPDRA EGRBAC ), and derived relations (RPRA EGRBAC , RPEA EGRBAC ). The set of user roles R EGRBAC constructed here is the set of candidate user roles.
Step 6: Combine similar user roles. To achieve this, we run the role combining algorithm described in Section 4.2.4.

EGRBAC Users and Environment Roles Constructing Algorithm
The goal is to construct EGRBAC elements (R EGRBAC , EC EGRBAC , ER EGRBAC , RP EGRBAC ), assignments (UA EGRBAC , EA EGRBAC , RPDRA EGRBAC ), and derived relations (RPRA EGRBAC , RPEA EGRBAC ) from UDRAA. See Algorithm 1 for the full algorithm. The input is UDRAA. The outputs are R EGRBAC , U A EGRBAC , EC EGRBAC , ER EGRBAC , EA EGRBAC , RP EGRBAC , and RPDRA EGRBAC . The steps are shown as follows: Step Step 2: Loop through the columns of UDRAA, Table 9 for Use Case B. Each column corresponds to user access rights to a specific device role. Inside each column, loop through the fields of different rows. Here we have two cases: A. U DRAA[i, j] = 1, according to the way UDRAA was constructed, this means the user corresponding to this row u i can access the device role of this column dr j unconditionally. In this case, the algorithm does the following:

1.
Create an environment role er x = Any_Time and add it to the set ER EGRBAC . Create an environment condition ec x = True and add it to the set EC EGRBAC . Add ({ec x }, er x ) to the set EA, this implies that the environment role Any_Time will always be active. Create a set of environment roles SER and add er x to it SER = {er x }.

2.
Create a role r m = ToString(ColumnDR(j)) which corresponds to accessing this column device role anytime and unconditionally. Add this role to the set R EGRBAC .

3.
Define a role pair rp z , where rp z .r = r m and rp z .ER = SER. Add rp z to the set RP EGRBAC .

4.
Assign the role pair rp z to the device role corresponding to this column by adding the pair (rp z , ColumnDR(j)) to the set RPDRA EGRBAC . 5.
Assign the role r m to the user corresponding to this row by adding the pair(RawUser(i), r m ) to the set U A EGRBAC .
B. U DRAA[i, j] = 1 ∧ U DRAA[i, j] = 0, which means that the user u i can access the device role dr j under specific a set of user and environment conditions defined by UDRAA[i, j]. Here, UDRAA[i, j] is a set of sets of conditions, where each set of conditions defines a group of session, and environment conditions that need to be satisfied together for the user u i to be able to access the device role dr j . Loop through each set of conditions X ∈ UDRAA[i, j]; for each X perform the following steps:

1.
Loop through each condition y ∈ X. If y is an environment-state attribute condition, the algorithm creates a corresponding environment condition ec y and adds it to the set EC EGRBAC , environment role er y and adds it to the set ER EGRBAC . Adds ({ec x }, er x ) to the set EA EGRBAC . Moreover, the algorithm adds er y to the set of environment roles SER.

2.
After looping through each condition in X, if the set SER is empty, this means this set of conditions does not contain an environment-state condition. In other words, the user of this row can access the device role of this column without any environment condition. In this case the algorithm creates an environment role er x = Any_Time and add it to the set ER EGRBAC , an environment condition ec x = True and add it to the set EC EGRBAC . Add ({ec x }, er x ) to the set EA EGRBAC , this implies that the environment role Any_Time will always be active. Add er x to it SER = {er x }.

3.
The algorithm creates a corresponding user role r m = ToString(ColumnDR(j)) +" ∧ "+ ToString(X) which represents accessing this column device role when the set of conditions that form X is satisfied. Add this role to the set R EGRBAC . 4.
Define a role pair rp z , where rp z .r = r m and rp z .ER = SER. Add rp z to the set RP EGRBAC . 5.
Assign the role pair rp z to the device role corresponding to this column by adding the pair (rp z , ColumnDR(j)) to the set RPDRA EGRBAC . 6.
Finally, assign the role r m to the user corresponding to this row by adding the pair(RawUser(i), r m ) to the set U A EGRBAC .

Users Roles Combining Algorithm
This algorithm is designed to combine roles with similar user assignments. When two roles r i , r j are assigned to the same set of users, the algorithm performs the following: 1.
For every role pair rp k , in which the role part of it rp k .r is equal to r i , change the role part of it to r j (rp k .r = r j ).

2.
Remove r i from the set of roles R EGRBAC . 3.
For every (u l , r i ) ∈ U A EGRBAC , remove the pair (u l , r i ) from the set U A EGRBAC . 4.
For every ((r i , ER x ), dr y ) ∈ RPDRA EGRBAC , remove (r i , ER x ), dr y ) from the set RPDRA EGRBAC , and instead add the pair ((r j , ER x ), dr y ) to the set RPDRA EGRBAC . For the detailed algorithm, please refer to Algorithm 2.
As a result of the user role-combining algorithm, the constructed nine roles will be merged into three roles. Moreover, the user role assignment set will be composed of three pairs, as follows: R = {r a ≡ r 1 , r 5 , r 7 , r 9 , r b ≡ r 2 , r 6 , r 8 , r c ≡ r 3 , r 4 }. if U(r i ) = U(r j ) then 3: for each rp k ∈ RP(r i ) do 4: rp k .r = r j 5: end for 6: 7: R EGRBAC = R EGRBAC \ r i 8: 9: Delete all U A pairs related to r i 10: for each (u l , r i ) ∈ U A EGRBAC do 11: U A = U A \ (u l , r i ) 12: end for 13: 14: Replace all RPDRA pairs related to r i

15:
for each ((r i , ER x ), dr y ) ∈ RPDRA EGRBAC do 16:  The output of EGRBAC role constructing algorithm for Use Case B is shown in Table 10. The maximum number of created device roles is O(|OPA| + |DA|). Since we create an environment role and an environment condition for each logical environment condition, the maximum number of environment roles and conditions is Ω(|ESA|). Finally, the maximum number of user roles is O(2 |SA|+|ESA| ).

Comprehensive Theoretical Comparison
In this section, we compare and analyze H ABAC α and EGRBAC against access control criteria adapted from [9]. These criteria are classified into two types: (a) Basic and main criteria. (b) Quality criteria.

Basic and Main Criteria
Six elements are included in this type of criteria. Each element will be discussed below. Table 11 summarizes this type of criteria comparison. These are invariants that must be maintained. EGRBAC supports three constraints: static separation of duty, dynamic separation of duty, and permission-role constraints. H ABAC α , however, cannot support permission-role constraints, as we will discuss in Section 6.

Attributed-Based Specifications
As explained in Section 3.1, we have two types of attributes, static and dynamic. Both models can support environment attributes. Furthermore, they both support static users, devices, and operations attributes. Dynamic users, devices, and operations attributes, however, are not supported by EGRBAC.

Least Privilege Principle
Under this principle, a subject of a system should only be permitted to have access to the least privileges required for performing the user duties. Both models adhere to this principle. They both include the component session, and a user belonging to several roles (in EGRBAC), or has different attributes corresponding to his roles in the house (in H ABAC α ) can invoke any subset of them that enables tasks to be accomplished in a session. Accordingly, a powerful user can keep some roles or attributes deactivated and activate them when necessary.

Authentication
Both models support positive (closed) authentication. They allow access only when there is an affirmative authorization for it and deny it in other circumstances.

Access Administration
Our comparison here is based on two administrative tasks, user provisioning and policy provisioning. Provisioning users is easier in RBAC-based models (including EGRBAC) than in ABAC-based models (including H ABAC α ). In RBAC models, user provisioning requires the administrator (the homeowner) to assign roles. Alternatively, in ABAC-based models, the administrator must configure different attribute values for newly provisioned users and devices. On the contrary, in ABAC-based model, policy provisioning only requires the addition of those policies to the authorization function. By contrast, in the RBAC-based model, this requires configuring a series of assignments as in EGRBAC.

Access Review
In RBAC-based models (such as EGRBAC), to calculate the maximum permission available for a user, it is sufficient to look into his roles, while this could be more complicated in ABAC-based models (such as H ABAC α ) [66].

Administrative Policies
To determine how administrative privileges are organized in any model, an access control administration model is required. In both models, it is assumed that the homeowner is responsible for granting or revoking permissions. Accordingly, we can conclude that they both support centralized administrative policies.

Quality Criteria
Here we have three essential criteria, as explained in the following.

Expressiveness and Meaningfulness
We believe that for an AC model to be expressive, it must maintain at least the following three characteristics. First, it must be formally defined to have a precise and rigorous specification of the intended behavior. Second, it must be sufficiently meaningful and expressive to support different types of constraints. Finally, The model should capture different types of static and dynamic attributes. Both models are formally defined. Moreover, they both maintain different constraints except for the permission-role constraints, which are not supported by H ABAC α . Finally, as explained in the Attributed-based specifications criterion in Section 5.1, they both capture environment attributes and different types of static attributes. EGRBAC, however, does not capture the user's and device's dynamic attributes.

Flexibility
Several factors need to be evaluated to determine whether an AC model is flexible. Here, we identify three of them. First, the model must be flexible enough to meet the requirements of smart-home IoT. Furthermore, the model should support delegation, which is the ability for a subject to delegate some or all his privileges to another user. Additionally, the model should provide flexibility for adding new users or policies.
According to the criteria proposed in [8] for an access control model to fulfill smarthome IoT requirements, it should be dynamic, fine-grained, and suitable for constrained smart-home devices. Moreover, The model should be constructed specifically for smarthome IoT or interpreted for the smart-home domain, using appropriate use cases. The model should be demonstrated in a proof-of-concept to be credible using commercially available technology. Finally, the model should have a formal definition so that the intended behavior is precise and rigorous. As discussed in [8], EGRBAC meets these criteria. However, as we discussed earlier, EGRBAC is not dynamic enough to capture dynamic attributes. On the other hand, the H ABAC α is dynamic, fine-grained, suitable for the constrained home environment, designed specifically for smart-home IoT, illustrated with two use-case demonstrations, has proof-of-concept implementation, and is formally defined. Hence, it meets the criteria proposed in [8].
As for delegation support, it is not feasible to determine this without an administration model for access control. In general, though, it has been demonstrated that RBAC-based and ABAC-based models are capable of delegation.
Both models are capable of provisioning new users and policies. Although new users are more easily provisioned in RBAC-based models (including EGRBAC) than in ABACbased models (including H ABAC α ), it is more challenging to provision new policies in RBAC-based models than in ABAC-based models.

Efficiency Level and Scalability
The access control model should address two main factors regarding efficiency and scalability. The model's validity in the real world will be questionable if it cannot be expanded easily. In addition, the development of the model should not adversely affect its efficiency. To analyze these factors accurately, a more detailed study needs to be performed. Generally, however, smart-home IoT involves a relatively small number of users and devices. Furthermore, organizations of different sizes have widely adopted ABAC-based models and RBAC-based models, proving their scalability.

Discussion
In this paper, we present H ABAC α . An attribute-based access control model for smarthome IoT that governs user-to-device authorization. User authentication is outside the scope of this model. The model captures the characteristics of different users, environments, operations, and devices. Furthermore, H ABAC α can give user access to some operations within a single device without giving them access to the entire device. Therefore, it is a fine-grained model. We illustrated our model with two use-case scenarios and demonstrated its applicability with a proof-of-concept implementation on the Amazon Web Services (AWS) platform. Overall, our model is functional and can be easily applied. We can notice that the captured average lambda processing times are generally low. We understand that practical smart homes will have different and more complicated scenarios. A detailed performance evaluation is ultimately required by simulating a large set of smart things; however, our proof-of-concept implementation in AWS is meant to demonstrate the practical applicability and effectiveness of fine-grained security policies in the context of smart homes. Incorporating many scenarios from the real world will not result in a change in security policy evaluation. Nevertheless, we are considering the possibility of a more detailed performance analysis as an extension of this study. The expressiveness of the model is discussed in Section 5.1. However, to deploy this model for commercial use, a more general sophisticated expressiveness study should be conducted.
Furthermore, we carefully investigated H ABAC α against EGRBAC. Both models are specifically designed to meet smart-home challenges. Towards this goal, we first compared the theoretical expressiveness power of these models in Section 5.2. Then, we evaluated both models against access control models criteria adapted from [9].
In comparing the theoretical expressiveness power of H ABAC α and EGRBAC, we introduced approaches for translating EGRBAC configuration into an equivalent H ABAC α setting so that the authorization rights are the same in both systems and vice versa. These approaches are adapted from [56]. Nevertheless, as discussed in Section 4.1, in H ABAC α , it is not possible to create something similar to EGRBAC PRConstraints. Therefore, it is difficult to prevent future authorization of specific users to access particular devices or operations as this can only be done dynamically when the user is attempting to access the prohibited operation, as opposed to in EGRBAC, which permits this prevention to be implemented upon assignment. It can be challenging to determine the role structure in EGRBAC, but once it has been determined, it is straightforward to determine which users have what permissions and which users do not have future access to such privileges.
The EGRBAC construction approach is capable of handling H ABAC α policies containing environment attributes in addition to users/sessions, devices, and operations static attributes. However, due to certain limitations in EGRBAC, our approach cannot handle H ABAC α policies that deal with users, sessions, or devices with dynamic attributes. According to Section 3.1, dynamic attributes are those attributes that are rapidly changing. For instance, device temperature. According to our approach, attribute instances of the devices and permissions are translated into device roles. A device role in EGRBAC is a way to categorize permissions of different devices based on relatively static characteristics. Whenever permission is assigned to a specific device role, it remains associated with that role until an administration change is made. It is impossible to activate and deactivate device roles dynamically or activate and deactivate permissions assignments to different device roles. For instance, in H ABAC α we can create a device attribute device_temperature : d : D ←− {Low, High}. We can easily configure an access policy that authorizes some users to access a device d x only if device_temperature(d x ) = Low. To do so in EGRBAC, we have two options. The first is to create two device roles, one for high temperature and another for low temperature for each device. For many devices and dynamic attributes, this option may lead to a role explosion. The second option is for those devices which have similar access conditions. We create a device role for low-temperature devices and a device role for high-temperature devices. However, there is no way to dynamically activate or deactivate devices membership in different device roles according to their temperatures. Furthermore, no mechanism in EGRBAC can dynamically activate d x 's high-temperature device role while deactivating the low-temperature device role when the temperature of dr x is high and vice versa. A similar argument holds when we deal with dynamic user/session attributes.
In the process of constructing the EGRBAC, we did not take into account the following: (1) Policies that compare two types of attributes. (2) H ABAC α configurations that involve user attribute constraints and session attribute constraints. However, this may be a potential future development.
In Section 5 we conducted a comprehensive theoretical comparison between H ABAC α and EGRBAC. We analyzed each model against the access control model criteria adapted from [9].
Based on the above analysis, a hybrid model that incorporates H ABAC α and EGRBAC features is likely to be the most suitable for smart-home IoT, and probably more generally. Future directions could involve the development of a combined model that will prevent a "role explosion" while providing access authorizations that cover different users, environment, operations, or devices characteristics while maintaining the advantages of EGRBAC, such as ease of access review.

Conclusions
In this paper, we defined the H ABAC α access control model for smart homes. The model captures different user, environment, operation, and device characteristics based on a dynamic, fine-grained ABAC approach. Additionally, we presented two use-case scenarios for our model and demonstrated its applicability through a proof-of-concept implementation in Amazon Web Services. Furthermore, we provided a performance test to demonstrate how our system responds in different scenarios. Based on the evaluation, we can conclude that our model is applicable and functional.
Moreover, we assessed the theoretical expressiveness power of our model in comparison to EGRBAC [8], a dynamic contextually aware RBAC-based access control model. We accomplished this by providing approaches for the conversion of H ABAC α specifications into EGRBAC and vice versa. According to our findings, EGRBAC can handle relatively static attributes of devices and users as well as those of the environment but is incapable of handling relatively dynamic attributes of users and devices. However, unlike EGRBAC, it is difficult for H ABAC α to prevent future authorizations of specific users from accessing specific operations on particular devices.
Finally, we conducted a comprehensive theoretical comparison between EGRBAC and H ABAC α against previously published criteria for access control models. We concluded that a hybrid model incorporating H ABAC α and EGRBAC features would be most appropriate for use in IoT-enabled smart homes, as well as more broadly.