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

Abstract

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 specifically 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${}_{\alpha }$, an attribute-based access control model for smart-home IoT. We formally define $HABA{C}_{\alpha }$ and demonstrate its features through two use-case scenarios and a proof-of-concept implementation. Furthermore, we present an analysis of $HABA{C}_{\alpha }$ as compared to the previously published EGRBAC (extended generalized role-based access control) model for smart-home IoT by first describing approaches for constructing $HABA{C}_{\alpha }$ specification from EGRBAC and vice versa in order to compare the theoretical expressiveness power of these models, and second, analyzing $HABA{C}_{\alpha }$ and EGRBAC models against standard criteria for access control models. Our findings suggest that a hybrid model that combines both $HABA{C}_{\alpha }$ and EGRBAC capabilities may be the most suitable for smart-home IoT, and probably more generally.

1. 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 smart-home 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 $HABA{C}_{\alpha }$, 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 $HABA{C}_{\alpha }$ to the previously published EGRBAC model for smart-home IoT [8]. We chose to compare $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ in terms of theoretical expressiveness power. In Section 5 we conduct a comprehensive theoretical comparison between EGRBAC and $HABA{C}_{\alpha }$ against standard criteria for access control models. Section 6 discusses the insights of this work. Finally, Section 7 concludes the paper.

2. 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 $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ (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 Section 4.1 and Section 4.2.

2.1. 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 $e{r}_i$ to the subset of related environment conditions $E{C}_i$. It implies that when each $e{c}_i\in E{C}_i$ is active, the environment role $e{r}_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 $\left(\right\{weekends,$$evenings\}$, $Entertainment\_Time)$ to the set EA.

Each role pair $r{p}_i\in 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 $r{p}_i$ is active, when each environment role $e{r}_i$ in the set of environment role $E{R}_i$ is active, where $E{R}_i$ is associated with $r{p}_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 $pr{c}_i$, where $pr{c}_i=(\left\{(Oven,On)\right\},\left\{Kids\right\})$. This constraint prevents any $rpdr{a}_i$ assignment relation from being added to the set RPDRA, if $rpdr{a}_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.

3. HABAC_α 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 $HABA{C}_{\alpha }$ (Home-IoT Attribute-Based Access Control) model. This model governs smart-home user-to-device interactions.

3.1. Formal Definition

The $HABA{C}_{\alpha }$ model is inspired by [31,56]. The basic model components are illustrated in Figure 2 and are formally defined in

Table 1. $HABA{C}_{\alpha }$ Model formalization part I: basic components.

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\left(s\right):S\to 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\to 2^{OP}$ specifies the valid operations for each device (device manufacturer-specified) – $ES=\left\{current\right\}$ 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\left(s\right))$. For every inherited attribute function $att\in theUSA$, $att\left(s\right)=att\left(user\right(s\left)\right)$ 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\cup DA\cup OPA\cup ESA$, $Range\left(att\right)$ is the attribute range, a finite set of atomic values – $attType:USA\cup DA\cup OPA\cup ESA\to \{set,atomic\}$. – Each $att\in theUSA\cup DA\cup OPA\cup 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\mathrm{or}S\mathrm{or}D\mathrm{or}OP\mathrm{or}\left\{current\right\}\to \left\{\begin{array}{cc}Range\left(att\right),\hfill & \mathrm{if}attType\left(att\right)=atomic\hfill \\ 2^{Range\left(att\right)},\hfill & \mathrm{if}attType\left(att\right)=set\hfill \end{array}\right.$$ – Every $att\in theUSA\cup DA\cup OPA\cup 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

– $UAConstraint\subseteq UAP\times 2^{UAP}$ is the user attribute constraints relationship (homeowner-specified) where $$UAP=\left\{\right(usa,v)\mid usa\in theUSA\wedge v\in Range(usa\left)\right)\}$$ Each $uac=((us{a}_x,v_y),UA{P}_j)\in UAConstraint$ specifies the following invariant: $$\left\{\begin{array}{cc}(\forall u_l\in U)(\forall (us{a}_m,v_n)\in UA{P}_j)[us{a}_x\left(u_l\right)=v_y\Rightarrow us{a}_m\left(u_l\right)\ne v_n],\hfill & \mathrm{if}attType\left(us{a}_x\right)=attType\left(us{a}_m\right)=atomic\hfill \\ (\forall u_l\in U)(\forall (us{a}_m,v_n)\in UA{P}_j)[v_y\in us{a}_x\left(u_l\right)\Rightarrow v_n\notin us{a}_m\left(u_l\right)],\hfill & \mathrm{if}attType\left(us{a}_x\right)=attType\left(us{a}_m\right)=set\hfill \end{array}\right.$$ – $SAConstraint\subseteq UAP\times 2^{UAP}$ is the session attribute constraints relationship (homeowner-specified) Each $sac=((us{a}_x,v_y),UA{P}_j)\in SAConstraint$ specifies the following invariant: $$\left\{\begin{array}{cc}(\forall s_l\in S)(\forall (us{a}_m,v_n)\in UA{P}_j)[s_l\mathrm{inherits}us{a}_x\wedge us{a}_x\left(user\right(s_l\left)\right)=v_y\wedge us{a}_m(user\left(s_l\right))=v_n\Rightarrow s_l\mathrm{does} \mathrm{not} \mathrm{inherit} us{a}_m],\hfill & \mathrm{if}attType\left(us{a}_x\right)=attType\left(us{a}_m\right)=atomic\hfill \\ (\forall s_l\in S)(\forall (us{a}_m,v_n)\in UA{P}_j)[s_l\mathrm{inherits}us{a}_x\wedge vy\in us{a}_x\left(user\right(s_l\left)\right)\wedge vn\in us{a}_m\left(user\right(s_l\left)\right)\Rightarrow s_l\mathrm{does} \mathrm{not} \mathrm{inherit} us{a}_m],\hfill & \mathrm{if}attType\left(us{a}_x\right)=attType\left(us{a}_m\right)=set\hfill \end{array}\right.$$

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 $o{p}_k$, device $d_j$ and environment-state $current$ as specified in Table 2

CheckAccess Predicate

– $CheckAccess$ is evaluated when session $s_i$ attempts operation $o{p}_k$ on device $d_j$ in context of environment-state $current$ – $CheckAccess(s_i,o{p}_k,d_j,current)$ evaluates to true or false using the following formula: $o{p}_k\in ops\left(d_j\right)\wedge Authorization(s_i,o{p}_k,d_j,current))$

and

Table 2. $HABA{C}_{\alpha }$ Model formalization part II: attribute authorization function.

Attribute authorization function

– $Authorization(s:S,op:OP,d:D,current:ES)$ is a first-order logic formula specified using the following grammar. $\alpha ::=term\mid term\wedge term\mid term\vee term\mid \left(term\right)\mid \neg term\mid \exists x\in set.\alpha \mid \forall x\in set.\alpha$ $term::=setsetcompareset\mid atomic\in set\mid atomic\notin set\mid atomicatomiccompareatomic$ $setcompare::=\subset \mid \subseteq \mid ⊈$ $atomiccompare::=<\mid =\mid \le$ $set::=usa\left(s\right)\mid opa\left(op\right)\mid esa\left(current\right)\mid da\left(d\right)$, where $attType\left(usa\right)=attType\left(opa\right)=attType\left(esa\right)=attType\left(da\right)=set$ $atomic::=usa\left(s\right)\mid opa\left(op\right)\mid esa\left(current\right)\mid da\left(d\right)\mid value$, where $attType\left(usa\right)=attType\left(opa\right)=attType\left(esa\right)=attType\left(da\right)=atomic$ – For a specific session $s_i$, device $d_j$ and operation $o{p}_k$, the authorization function $Authorization(s_i,o{p}_k,d_j,current)$ is evaluated by substituting the actual attribute values of $usa\left(s_i\right)$, $da\left(d_j\right)$, $opa\left(o{p}_k\right)$ and $esa\left(current\right)$ 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

. It consists of four sets as follows: Users (U), Environment States (ES), Operations (OP), and Devices (D). These sets are presented in ovals. Moreover, attribute functions are presented in squares. We have four attribute functions, User/Session Attributes (USA), Environment-State Attributes (ESA), Operation Attributes (OPA), and Device Attributes (DA). The rectangles indicate two types of constraints: constraints on user attributes and constraints on session attributes.

3.1.1. 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\left(s\right)$.

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\left(d\right)$ maps each device d to the set of valid operations on d.

The Environment States set ($ES=\left\{current\right\}$) 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.

3.1.2. 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\left(s\right)$. If a session s inherited a user session attribute $usa$ from his user $user\left(s\right)$, then it is required that $usa\left(s\right)=usa\left(user\right(s\left)\right)$. 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 environment-state 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\left(bob\right)$ is not semantically correct.

Basically, an attribute range is composed of a finite set of atomic values. Each attribute function $at{t}_i$ has a range $Range\left(at{t}_i\right)$, where $Range\left(at{t}_i\right)$ represents the range of values to which the attribute function $at{t}_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 atomic-valued 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 atomic-valued 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\left(alex\right)$ 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\left(TV\right)$ 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$.

3.1.3. Constraints

These are invariants that must never be violated. There are two types of constraints defined by $HABA{C}_{\alpha }$. 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:

$$ua{c}_i=((Relationship,kid),\left\{(Adults,True)\right\})$$

The above constraint implies that for any user u if $Relationship\left(u\right)=kid$, then it is required that $Adults\left(u\right)\ne 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 $HAB{A}_{\alpha }$, 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. $HABA{C}_{\alpha }$ 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.

3.1.4. 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 $o{p}_k$, and device $d_j$ the authorization function $Authorization(s_i,o{p}_k,d_j,current)$ is evaluated by substituting the actual attribute values of $usa\left(s_i\right)$, $da\left(d_j\right)$, $opa\left(o{p}_k\right)$ and $esa\left(current\right)$ 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.

$HABA{C}_{\alpha }$ 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.

3.1.5. Check Access Predicate

The $CheckAccess$ predicate is evaluated in each access request. When a session $s_i$ attempts operation $o{p}_k$ on device $d_j$ in the context of environment-state $current$ the $CheckAccess$$(s_i,o{p}_k,d_j,current)$ predicate evaluates to be true if the following conditions are satisfied:

• The operation $o{p}_k$ is assigned to the device $d_j$ by the device manufacturer.
• The authorization function is evaluated to be true.

3.2. Use Cases

In this section, we describe two use cases to illustrate the components and configurations of $HABA{C}_{\alpha }$.

3.2.1. Use Case A

In this use case, the goals are as follows: (a) Kids should be allowed to use kid-friendly 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 $HABA{C}_{\alpha }$ 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\left(s\right)$. There are five devices $TV,PlayStation,Oven,Fridge$ and $FrontDoor$. $Oven$, and $Fridge$ are assigned the following device attributes by the house owner $Fridge\leftarrow$$(DangerouseKitchenDevices:False)$, and $Oven\leftarrow (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)\leftarrow (KidsFriendly:$$True)$, while $(PG$, $A12$, $BuyGames)\leftarrow (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, we have six terms (atomic declarative sentences) which are: (a) $Relationship\left(s\right)=kid$, (b) $day\left(current\right)\in \{Sa,S\}$, (c) $12:00\le time\left(current\right)\le 19:00$, (d) $day\left(current\right)\in \{M,T,W$, $Th,F\}$, (e) $17:00\le time\left(current\right)\le 19:00$, (f) $KidsFriendly\left(op\right)=True$. In the second propositional statement, teenagers are only permitted access to dangerous kitchen devices when one of their parents is present in the kitchen. Here, we have three terms, which are: (a) $Relationship\left(s\right)=teenager$, (b) $ParentInKitchen\left(current\right)=True$, (c) $DangerouseKitchen$$Devices\left(d\right)=True$. The third statement permits teenagers to use non-dangerous kitchen devices unconditionally. It contains two terms, which are: (a) $Relationship\left(s\right)=teenager$ (b) $DangerouseKitchen$$Devices\left(d\right)=False$. According to the fourth statement, teenagers are allowed to access both kid-friendly and non-kid-friendly operations without restriction. It contains three terms, which are: (a) $Relationship\left(s\right)=teenager$, (b) $KidsFriendly\left(op\right)=True$, (c) $KidsFriendly\left(op\right)=False$. Finally, the fifth statement guarantees parents access to anything at any time and contains one term: (a) $Relationship\left(s\right)=parent$.

3.2.2. Use Case B

The objectives of this use case are as follows: (a) Kids should be allowed to use kid-friendly 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 $HABA{C}_{\alpha }$ 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\left(s\right)$. There are three devices $iPad,FrontDoor$ and $lawnMower$. $FrontDoor$ is assigned to the following device attributes by the house owner $FrontDoor\leftarrow (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)\leftarrow (KidsFriendly:$$True)$, while $(A11$, $Games$, and $Movies)\leftarrow (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.

3.3. Proof-of-Concept Implementation

3.3.1. Enforcement Architecture

$HABA{C}_{\alpha }$ 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.

3.3.2. 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.

3.3.3. Local Communication Handling

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.

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.

3.3.4. 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. One user sending requests to multiple devices.

Number of Users	Number of Devices	Lambda Processing Time in ms	Total Number of Requests
1	1	1.4671	10
1	3	1.33123	30 (10 per request)
1	5	1.34384	50 (10 per request)

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.

The values presented in

Table 4. Multiple concurrent instances of one user sending request to one device.

Number of Users	Number of Devices	Lambda Processing Time in ms	Total Number of Requests
1	1	1.4671	10
3	3	1.6925	30 (10 per request)
5	5	2.0460	50 (10 per request)

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 5. Multiple users sending requests to one device.

Number of Users	Number of Devices	Lambda Processing Time in ms	Total Number of Requests
1	1	1.4671	10
3	1	1.47577	30 (10 per request)
5	1	1.55134	50 (10 per request)

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.

4. HABAC_α 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 $HABA{C}_{\alpha }$ 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].

4.1. From EGRBAC to $HABA{C}_{\alpha }$

Here, we introduce the $HABA{C}_{\alpha }$ configuration that translates EGRBAC configuration to be implemented by $HABA{C}_{\alpha }$ model.

In this configuration, for differentiation purposes, every EGRBAC component is followed with the suffix ${}_{EGRBAC}$. Similarly, every $HABA{C}_{\alpha }$ component is followed with the suffix ${}_{HABA{C}_{\alpha }}$. The configuration of $HABA{C}_{\alpha }$ for a given EGRBAC configuration is shown in

Table 6. EGRBAC configuration in $HABA{C}_{\alpha }$.

- $U_{HABA{C}_{\alpha }}=U_{EGRBAC}$ - $US{A}_{HABA{C}_{\alpha }}=\left\{Relationship\right\}$ - $Range\left(Relationship\right)=R_{EGRBAC}$ - $Relationship:u\in U_{HABA{C}_{\alpha }}\to 2^{R_{EGRBAC}}$ - $Relationship:s\in S_{HABA{C}_{\alpha }}\to 2^{R_{EGRBAC}}$ - $(\forall u_i\in U_{HABA{C}_{\alpha }})[Relationship\left(u_i\right)=\left\{r_x\right|(u_i,r_x)\in U{A}_{EGRBAC}\}]$ - $UAConstrain{t}_{HABA{C}_{\alpha }}=\left\{ua{c}_i\right\}$, where: - $\forall (ssd{c}_i=(r_i,R_j)\in SSDConstraint{s}_{EGRBAC})[ua{c}_i=((Relationship,r_i),UA{P}_j)]$, where: $UA{P}_j=\left\{(Relationship,r_n)\right|r_n\in R_j\}$ - $SAConstrain{t}_{HABA{C}_{\alpha }}=\left\{sa{c}_i\right\}$, where: - $\forall (dsd{c}_i=(r_i,R_j)\in DSDConstraint{s}_{EGRBAC})[sa{c}_i=((Relationship,r_i),UA{P}_j)]$, where: $UA{P}_j=\left\{(Relationship,r_n)\right|r_n\in R_j\}$ - $E{S}_{HABA{C}_{\alpha }}=\left\{Current\right\}$ - $ES{A}_{HABA{C}_{\alpha }}=E{R}_{EGRBAC}$ - $(\forall es{a}_i\in ES{A}_{HABA{C}_{\alpha }})[es{a}_i:es\in E{S}_{HABA{C}_{\alpha }}\to \{True,False\}]$ - $D_{HABA{C}_{\alpha }}=D_{EGRBAC}$, $O{P}_{HABA{C}_{\alpha }}=O{P}_{EGRBAC}$ - $D{A}_{HABA{C}_{\alpha }}=OP{A}_{HABA{C}_{\alpha }}=D{R}_{EGRBAC}$ - $(\forall d{a}_i\in D{A}_{HABA{C}_{\alpha }})$$[d{a}_i:d\in D_{HABA{C}_{\alpha }}\to \{True,False\}]$ - $(\forall op{a}_i\in OP{A}_{HABA{C}_{\alpha }})[op{a}_i:op\in O{P}_{HABA{C}_{\alpha }}\to \{True,False\}]$ - $(\forall (d{r}_y\in D{R}_{EGRBAC},p_x\in \left\{p_i\right|(p_i,d{r}_y)\in PDR{A}_{EGRBAC}\}))[d{r}_y(p_x.op)=True,d{r}_y(p_x.d)=True]$ - Initialize the authorization function $Authorization(s:S_{HABA{C}_{\alpha }},op:O{P}_{HABA{C}_{\alpha }},d:D_{HABA{C}_{\alpha }},current:E{S}_{HABA{C}_{\alpha }})$ - For each $rpdr{a}_i=((r_i,E{R}_i),d{r}_i)\in RPDR{A}_{HABA{C}_{\alpha }}$, we construct an authorization function as follows: $SetOfESA=“TRUE”$. $\forall (esa\in E{R}_i)[SetOfESA=SetOfESA+“\wedge ”+“esa\left(current\right)=True”]$. $CurrentAuth=“r_i”+“\in ”+“Relationship\left(s\right)”+“\wedge ”+“d{r}_i\left(op\right)=True”+“\wedge ”+“d{r}_i\left(d\right)=True”+“\wedge ”+“SetOfESA”$. $Authorization(s:S_{HABA{C}_{\alpha }},op:O{P}_{HABA{C}_{\alpha }},d:D_{HABA{C}_{\alpha }},current:E{S}_{HABA{C}_{\alpha }})\leftarrow Authorization(s:S_{HABA{C}_{\alpha }},op:O{P}_{HABA{C}_{\alpha }},d:D_{HABA{C}_{\alpha }},current:E{S}_{HABA{C}_{\alpha }})+“\vee ”+“CurrentAuth”$.

.

Essentially, the objective is to be able to translate any EGRBAC configuration towards its equivalent $HABA{C}_{\alpha }$ configuration, so that the authorizations in the $HABA{C}_{\alpha }$ match those under EGRBAC. The inputs are EGRBAC component sets $R_{EGRBAC},$$U_{EGRBAC}$, $U{A}_{EGRBAC},$$E{C}_{EGRBAC},$$E{R}_{EGRBAC},$$E{A}_{EGRBAC},$$D{R}_{EGRBAC},$ $PDR{A}_{EGRBAC},$$P_{EGRBAC},$$D_{EGRBAC},$ $O{P}_{EGRBAC},RPDR{A}_{EGRBAC}$, $DSDConstraint{s}_{EGRBAC}$, and $SSDConstraint{s}_{EGRBAC}$. The outputs are $U_{HABA{C}_{\alpha }},$$US{A}_{HABA{C}_{\alpha }},$$E{S}_{HABA{C}_{\alpha }},$$ES{A}_{HABA{C}_{\alpha }},$$O{P}_{HABA{C}_{\alpha }},$$OP{A}_{HABA{C}_{\alpha }},$$D_{HABA{C}_{\alpha }},$$D{A}_{HABA{C}_{\alpha }},$$UAConstrain{t}_{HABA{C}_{\alpha }}$, $SAConstrain{t}_{HABA{C}_{\alpha }}$, and the authorization function $Authorizatio{n}_{HABA{C}_{\alpha }}(s:S_{HABA{C}_{\alpha }},op:O{P}_{HABA{C}_{\alpha }},$$d:D_{HABA{C}_{\alpha }},es:E{S}_{HABA{C}_{\alpha }})$.

Both systems have the same users, devices, and operations. In $HABA{C}_{\alpha }$, 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 $HABA{C}_{\alpha }$. Similarly, constraints related to the dynamic separation of duties are mapped into session attribute constraints in $HABA{C}_{\alpha }$.

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 $HABA{C}_{\alpha }$, 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=(o{p}_x,d_x)$, where $p_x\in P_{EGRBAC}$ is assigned to the device role $d{r}_y$, where $d{r}_y\in D{R}_{EGRBAC}$, then $d{a}_y\left(d_x\right)=True$ and $op{a}_y\left(o{p}_x\right)=True$, where $op{a}_y\in OP{A}_{HABA{C}_{\alpha }}$, $d{a}_y\in D{A}_{HABA{C}_{\alpha }}$, and $op{a}_y$ and $d{a}_y$ are the operation and device attributes which were created to be equivalent to the device role $d{r}_y\in D{R}_{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 $rpdr{a}_i=((r_i,E{R}_i),d{r}_i)\in 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.

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 $HABA{C}_{\alpha }$, 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 $HABA{C}_{\alpha }$. 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 $HABA{C}_{\alpha }$-like models would need to enforce them at the time of enforcement.

To summarize, the construction of $HABA{C}_{\alpha }$ 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.

4.2. From $HABA{C}_{\alpha }$ to EGRBAC

Throughout this section, we will describe our methodology for generating EGRBAC components and configurations from $HABA{C}_{\alpha }$ configuration. This methodology is inspired by the approach proposed in [56], which follows a bottom-up role engineering approach. It applies for $HABA{C}_{\alpha }$ 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.

4.2.1. 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\in U$, $d_j\in D$, and $o{p}_k\in 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$, $o{p}_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,o{p}_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 $o{p}_k$, or the condition references an undefined attribute value for the evaluated operation $o{p}_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$, $o{p}_k$, $e{s}_l$, $C)$ denotes that the user $u_i$ is allowed to perform an operation $o{p}_k$ on a device $d_j$ during the environment state $e{s}_l$ whenever the set of environment and session conditions in C are satisfied.

Table 7. AA for Use Case B (Different colors represent authorization fields for different users).

User u	Device d	Operation op	Environment State es	Conditions C
Suzanne	iPad	$A5$	current	X
Suzanne	iPad	$A8$	current	X
Suzanne	iPad	$A5$	current	Z
Suzanne	iPad	$A8$	current	Z
Bob	iPad	$A5$	current	$\left\{Relationship\right(s)=parent\}$
Bob	iPad	$A8$	current	$\left\{Relationship\right(s)=parent\}$
Bob	iPad	$A11$	current	$\left\{Relationship\right(s)=parent\}$
Bob	iPad	$Games$	current	$\left\{Relationship\right(s)=parent\}$
Bob	iPad	$Movies$	current	$\left\{Relationship\right(s)=parent\}$
Bob	lawnMower	$ON$	current	$\left\{Relationship\right(s)=parent\}$
Bob	lawnMower	$OFF$	current	$\left\{Relationship\right(s)=parent\}$
Bob	FrontDoor	$Lock$	current	$\left\{Relationship\right(s)=parent\}$
Bob	FrontDoor	$Unlock$	current	$\left\{Relationship\right(s)=parent\}$
John	iPad	$A5$	current	$\left\{Relationship\right(s)=teenager\}$
John	iPad	$A8$	current	$\left\{Relationship\right(s)=teenager\}$
John	iPad	$A11$	current	$\left\{Relationship\right(s)=teenager\}$
John	iPad	$Games$	current	$\left\{Relationship\right(s)=teenager\}$
John	iPad	$Movies$	current	$\left\{Relationship\right(s)=teenager\}$
John	FrontDoor	$Lock$	current	Y
John	FrontDoor	$Unlock$	current	Y

X = $\left\{Relationship\right(s)=kid$, $day\left(current\right)\in \{Sa,S\},12:00\le time\left(current\right)\le 19:00\}$; Y = $\left\{Relationship\right(s)=teenager$, $ParentInTheHouse\left(current\right)=True\}$; Z= $\left\{Relationship\right(s)=kid$, $day\left(current\right)\in \{M,T,W,Th,F\},17:00\le time\left(current\right)\le 19:00\}$.

provides the AA for Use Case B. Different colors represent authorization fields for different users.

4.2.2. Approach

The goal is to construct EGRBAC elements, assignments, and derived relationships from $HABA{C}_{\alpha }$ policies so that the authorizations are the same as those under $HABA{C}_{\alpha }$. In this construction, for differentiation purposes, every EGRBAC component is followed with the suffix ${}_{EGRBAC}$. Similarly, every $HABA{C}_{\alpha }$ component is followed with the suffix ${}_{HABA{C}_{\alpha }}$.

The inputs are $HABA{C}_{\alpha }$ components $U_{HABA{C}_{\alpha }}$, $D_{HABA{C}_{\alpha }},$$O{P}_{HABA{C}_{\alpha }}$, $US{A}_{HABA{C}_{\alpha }}$, $ES{A}_{HABA{C}_{\alpha }}$, $OP{A}_{HABA{C}_{\alpha }}$, $D{A}_{HABA{C}_{\alpha }}$, and the authorization array $AA$. The outputs are EGRBAC components $U_{EGRBAC},$$R_{EGRBAC},$$U{A}_{EGRBAC},$$E{C}_{EGRBAC},$$E{R}_{EGRBAC},$$E{A}_{EGRBAC},$$R{P}_{EGRBAC},$$RPR{A}_{EGRBAC},$$RPE{A}_{EGRBAC},$$D_{EGRBAC},$$O{P}_{EGRBAC},$$P_{EGRBAC},$$D{R}_{EGRBAC},$$PDR{A}_{EGRBAC}$, and $RPDR{A}_{EGRBAC}$. The steps are following:

Step 1: Initialization. Both systems have the same set of users, devices, and operations, hence $U_{EGRBAC}=U_{HABA{C}_{\alpha }},D_{HABA{C}_{\alpha }}=D_{HABA{C}_{\alpha }},$ and $O{P}_{EGRBAC}=O{P}_{HABA{C}_{\alpha }}$. For every operation $o{p}_i$, and device $d_j$ pair, where $o{p}_i$ is assigned to $d_j$ by the device manufacturers, create a permission.

Step 2: Create the set of device roles $D{R}_{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,o{p}_j)$, where $d_i$ is not assigned to any device attributes, and $o{p}_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 $D{R}_{EGRBAC}$ set (constructed in Step 2). To construct $PDRA$ we first make a column for each $dr\in D{R}_{EGRBAC}$, and make a row for each permission $p\in 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 $d{r}_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,d{r}_j)$ to the set $PDRA$ of EGRBAC. See

Table 8. PDRA array for Use Case B.

	DangerouseDevices = True	DangerouseDevices = False	KidsFriendly = True	KidsFriendly = False	RemPerm
$(iPad,A5)$	0	0	1	0	0
$(iPad,A8)$	0	0	1	0	0
$(iPad,A11)$	0	0	0	1	0
$(iPad,Games)$	0	0	0	1	0
$(iPad,Movies)$	0	0	0	1	0
$(lawnMower,ON)$	0	0	0	0	1
$(lawnMower,OFF)$	0	0	0	0	1
$(FrontDoor,Lock)$	1	0	0	0	0
$(FrontDoor,Unlock)$	1	0	0	0	0

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$$\subseteq U_{EGRBAC}\times D{R}_{EGRBAC}$, a many-to-many mapping between $U_{EGRBAC}$ and $D{R}_{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]\in UDRAA$ we check the $AA$ for every $u_i,$ and $p_x$ combination, where $(p_x,d{r}_j)\in PDRA$. $u_i$ is the user corresponding to the row i, while $d{r}_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 $d{r}_j$ without any condition. (b) $UDRAA[i,j]=Y$, 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 $d{r}_j$. Please note that these sets of conditions must be the same for each permission assigned to $d{r}_j$. (c) Finally, $UDRAA[i,j]=0$ if user $u_i$ is not allowed to access all the permissions assigned to the device role $d{r}_j$, or is allowed to access different permissions in $d{r}_j$ but under different set of conditions.

Table 9. UDRAA for Use Case B.

	DangerouseDevices = True	DangerouseDevices = False	KidsFriendly = True	KidsFriendly = False	RemPerm
Suzanne	0	0	$\{X,Z\}$	0	0
Bob	$\left\{\right\{Relationship\left(s\right)=parent\left\}\right\}$	0	$\left\{\right\{Relationship\left(s\right)=parent\left\}\right\}$	$\left\{\right\{Relationship\left(s\right)=parent\left\}\right\}$	$\left\{\right\{Relationship\left(s\right)=parent\left\}\right\}$
John	$\left\{Y\right\}$	0	$\left\{\right\{Relationship\left(s\right)=teenager\left\}\right\}$	$\left\{\right\{Relationship\left(s\right)=teenager\left\}\right\}$	0

X = $\left\{Relationship\right(s)=kid$, $day\left(current\right)\in \{Sa,S\},12:00\le time\left(current\right)\le 19:00\}$; Y = $\left\{Relationship\right(s)=teenager$, $ParentInTheHouse\left(current\right)=True\}$; Z= $\left\{Relationship\right(s)=kid$, $day\left(current\right)\in \{M,T,W,Th,F\},17:00\le time\left(current\right)\le 19:00\}$.

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}$, $E{C}_{EGRBAC}$, $E{R}_{EGRBAC},$$R{P}_{EGRBAC})$, assignments $(U{A}_{EGRBAC},E{A}_{EGRBAC},RPDR{A}_{EGRBAC})$, and derived relations $(RPR{A}_{EGRBAC},$$RPE{A}_{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.

4.2.3. EGRBAC Users and Environment Roles Constructing Algorithm

The goal is to construct EGRBAC elements $(R_{EGRBAC}$$,E{C}_{EGRBAC}$, $E{R}_{EGRBAC}$, $R{P}_{EGRBAC})$, assignments $(U{A}_{EGRBAC},E{A}_{EGRBAC},RPDR{A}_{EGRBAC})$, and derived relations $(RPR{A}_{EGRBAC},$$RPE{A}_{EGRBAC})$ from $UDRAA$. See Algorithm 1 for the full algorithm. The input is $UDRAA$. The outputs are $R_{EGRBAC}$, $U{A}_{EGRBAC}$, $E{C}_{EGRBAC}$, $E{R}_{EGRBAC}$, $E{A}_{EGRBAC}$, $R{P}_{EGRBAC},$ and $RPDR{A}_{EGRBAC}$. The steps are shown as follows:

Algorithm 1 EGRBAC Users and Environment Roles Construction

Require:$UDRAA$ Require:$ColumnDR\left(j\right)$: return the device role corresponding to the column j in $UDRAA$. Require:$RawUser\left(i\right)$: return the user corresponding to the row i in $UDRAA$. Require:$IsESC\left(c\right)$: Return True if c is an environment-state condition. Require:$ToString\left(x\right):$ Convert x into a string format.   1: Initilize$n=$ Number of users, $m=$ Number of device roles, $R_{EGRBAC}=\left\{\right\}$, $U{A}_{EGRBAC}=\left\{\right\}$, $E{C}_{EGRBAC}=\left\{\right\}$, $E{R}_{EGRBAC}=\left\{\right\}$, $E{A}_{EGRBAC}=\left\{\right\}$, $R{P}_{EGRBAC}=\left\{\right\}$, and $RPDR{A}_{EGRBAC}=\left\{\right\}$,   2: for$j\leftarrow 1$ to m do   3:     for $i\leftarrow 1$ to n do   4:         if $UDRAA[i,j]=1$ then   5:            $e{r}_x=Any\_Time$, $e{c}_x=True$   6:            $E{C}_{EGRBAC}=E{C}_{EGRBAC}\cup \left\{e{c}_x\right\}$, $E{R}_{EGRBAC}=E{R}_{EGRBAC}\cup \left\{e{r}_x\right\}$   7:            $E{A}_{EGRBAC}=E{A}_{EGRBAC}\cup \left\{(\left\{e{c}_x\right\},e{r}_x)\right\}$   8:            $SER=\left\{e{r}_x\right\}$   9:            $r_m=ToString\left(ColumnDR\left(j\right)\right)$ 10:            $R_{EGRBAC}=R_{EGRBAC}\cup \left\{r_m\right\}$ 11:            $R{P}_{EGRBAC}=R{P}_{EGRBAC}\cup \left\{r{p}_z\right\}$, where $r{p}_z.r=r_m,r{p}_z.ER=SER$ 12:            $RPDR{A}_{EGRBAC}=RPDR{A}_{EGRBAC}\cup \left\{(r{p}_z,ColumnDR\left(j\right))\right\}$ 13:            $U{A}_{EGRBAC}=U{A}_{EGRBAC}\cup \left\{(RawUser\left(i\right),r_m)\right\}$ 14:             15:         else if $UDRAA[i,j]\ne 1\wedge UDRAA[i,j]\ne 0$ then 16:            for each $X\in UDRAA[i,j]$ do 17:                $SER=\left\{\right\}$ 18:                for each $y\in \left\{y\right|(y\in X)\wedge IsESC\left(y\right)\}$ do 19:                    Create $e{c}_y,$ and $e{r}_y$ 20:                    $E{C}_{EGRBAC}=E{C}_{EGRBAC}\cup \left\{e{c}_y\right\}$, $E{R}_{EGRBAC}=E{R}_{EGRBAC}\cup \left\{e{r}_y\right\}$ 21:                    $E{A}_{EGRBAC}=E{A}_{EGRBAC}\cup \left\{(\left\{e{c}_y\right\},e{r}_y)\right\}$ 22:                    $SER=SER\cup \left\{e{r}_y\right\}$ 23:                end for 24:                if $SER==\left\{\right\}$ then 25:                    $e{r}_x=Any\_Time$, $e{c}_x=True$ 26:                    $E{C}_{RC}=E{C}_{RC}\cup \left\{e{c}_x\right\}$, $E{R}_{RC}=E{R}_{RC}\cup \left\{e{r}_x\right\}$ 27:                    $E{A}_{RC}=E{A}_{RC}\cup \left\{(\left\{e{c}_x\right\},e{r}_x)\right\}$ 28:                    $SER=\left\{e{r}_x\right\}$ 29:                end if 30:                $r_m=ToString\left(ColumnDR\left(j\right)\right)$$+“\wedge ”+$$ToString\left(X\right)$ 31:                $R_{EGRBAC}=R_{EGRBAC}\cup \left\{r_m\right\}$ 32:                $R{P}_{EGRBAC}=R{P}_{EGRBAC}\cup \left\{r{p}_z\right\}$, where $r{p}_z.r=r_m,r{p}_z.ER=SER$ 33:                $RPDR{A}_{EGRBAC}=RPDR{A}_{EGRBAC}\cup (r{p}_z,ColumnDR\left(j\right))$ 34:                $U{A}_{EGRBAC}=U{A}_{EGRBAC}\cup \left\{(RawUser\left(i\right),r_m)\right\}$ 35:            end for 36:         end if 37:     end for 38: end for

Step 1: Initialize the following EGRBAC sets $R_{EGRBAC}=\left\{\right\},U{A}_{EGRBAC}=\left\{\right\},$$E{C}_{EGRBAC}=\left\{\right\},E{R}_{EGRBAC}=\left\{\right\},E{A}_{EGRBAC}=\left\{\right\},R{P}_{EGRBAC}=\left\{\right\},RPDR{A}_{EGRBAC}=\left\{\right\}$, and the following constants $m=$ Number of device roles, $n=$ Number of users.

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. $\mathit{UDRAA}[\mathit{i},\mathit{j}]=\mathbf{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 $d{r}_j$ unconditionally. In this case, the algorithm does the following:

• Create an environment role $e{r}_x=Any\_Time$ and add it to the set $E{R}_{EGRBAC}$. Create an environment condition $e{c}_x=True$ and add it to the set $E{C}_{EGRBAC}$. Add $(\left\{e{c}_x\right\},e{r}_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 $e{r}_x$ to it $SER=\left\{e{r}_x\right\}$.
• Create a role $r_m=ToString\left(ColumnDR\left(j\right)\right)$ which corresponds to accessing this column device role anytime and unconditionally. Add this role to the set $R_{EGRBAC}$.
• Define a role pair $r{p}_z$, where $r{p}_z.r=r_m$ and $r{p}_z.ER=SER$. Add $r{p}_z$ to the set $R{P}_{EGRBAC}$.
• Assign the role pair $r{p}_z$ to the device role corresponding to this column by adding the pair $(r{p}_z,ColumnDR\left(j\right))$ to the set $RPDR{A}_{EGRBAC}$.
• Assign the role $r_m$ to the user corresponding to this row by adding the pair $(RawUser\left(i\right),r_m)$ to the set $U{A}_{EGRBAC}$.

B. $\mathit{UDRAA}[\mathit{i},\mathit{j}]\ne \mathbf{1}\wedge \mathit{UDRAA}[\mathit{i},\mathit{j}]\ne \mathbf{0}$, which means that the user $u_i$ can access the device role $d{r}_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 $d{r}_j$. Loop through each set of conditions $X\in UDRAA[i,j]$; for each X perform the following steps:

• Loop through each condition $y\in X$. If y is an environment-state attribute condition, the algorithm creates a corresponding environment condition $e{c}_y$ and adds it to the set $E{C}_{EGRBAC}$, environment role $e{r}_y$ and adds it to the set $E{R}_{EGRBAC}$. Adds $(\left\{e{c}_x\right\},e{r}_x)$ to the set $E{A}_{EGRBAC}$. Moreover, the algorithm adds $e{r}_y$ to the set of environment roles $SER$.
• 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 $e{r}_x=Any\_Time$ and add it to the set $E{R}_{EGRBAC}$, an environment condition $e{c}_x=True$ and add it to the set $E{C}_{EGRBAC}$. Add $(\left\{e{c}_x\right\},e{r}_x)$ to the set $E{A}_{EGRBAC}$, this implies that the environment role $Any\_Time$ will always be active. Add $e{r}_x$ to it $SER=\left\{e{r}_x\right\}$.
• The algorithm creates a corresponding user role $r_m=ToString\left(ColumnDR\left(j\right)\right)$$+“\wedge ”+$$ToString\left(X\right)$ 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}$.
• Define a role pair $r{p}_z$, where $r{p}_z.r=r_m$ and $r{p}_z.ER=SER$. Add $r{p}_z$ to the set $R{P}_{EGRBAC}$.
• Assign the role pair $r{p}_z$ to the device role corresponding to this column by adding the pair $(r{p}_z,ColumnDR\left(j\right))$ to the set $RPDR{A}_{EGRBAC}$.
• Finally, assign the role $r_m$ to the user corresponding to this row by adding the pair $(RawUser\left(i\right),r_m)$ to the set $U{A}_{EGRBAC}$.

4.2.4. 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:

• For every role pair $r{p}_k$, in which the role part of it $r{p}_k.r$ is equal to $r_i$, change the role part of it to $r_j$ ($r{p}_k.r=r_j$).
• Remove $r_i$ from the set of roles $R_{EGRBAC}$.
• For every $(u_l,r_i)\in U{A}_{EGRBAC}$, remove the pair $(u_l,r_i)$ from the set $U{A}_{EGRBAC}$.
• For every $((r_i,E{R}_x),d{r}_y)\in RPDR{A}_{EGRBAC}$, remove $(r_i,E{R}_x),d{r}_y)$ from the set
  $RPDR{A}_{EGRBAC}$, and instead add the pair $((r_j,E{R}_x),d{r}_y)$ to the set $RPDR{A}_{EGRBAC}$. For the detailed algorithm, please refer to Algorithm 2.

Upon implementing the first five steps outlined in Section 4.2.2, we will end up with a set of nine roles, as shown in Figure 9. Different roles will be assigned to different users as follows:

$$UA=\{(suzanne,r_3),(suzanne,r_4),(bob,r_1),(bob,r_5),(bob,r_7),(bob,r_9),(john,r_2),(john,r_6),(john,r_8))\}.$$

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\equiv r_1,r_5,r_7,r_9,r_b\equiv r_2,r_6,r_8,r_c\equiv r_3,r_4\}.$$

$$UA=\{(bob,r_a),(john,r_b),(suzanne,r_c),\}.$$

Algorithm 2 Users Roles Combining Algorithm

Require:: $R_{EGRBAC}$: The set of roles Require:$U\left(r\right)$: Returns the set of users assigned to the role r. Require:$RP\left(r\right)$: Returns the set of role pairs associated with the role r.   1: for each$r_i,r_j\in R_{EGRBAC}$do   2:     if $U\left(r_i\right)=U\left(r_j\right)$ then   3:         for each $r{p}_k\in RP\left(r_i\right)$ do   4:            $r{p}_k.r=r_j$   5:         end for   6:            7:         $R_{EGRBAC}=R_{EGRBAC}\backslash r_i$   8:            9:                                                                                 ▹ Delete all $UA$ pairs related to $r_i$ 10:         for each $(u_l,r_i)\in U{A}_{EGRBAC}$ do 11:            $UA=UA\backslash (u_l,r_i)$ 12:         end for 13:          14:                                                                   ▹ Replace all $RPDRA$ pairs related to $r_i$ 15:         for each $((r_i,E{R}_x),d{r}_y)\in RPDR{A}_{EGRBAC}$ do 16:            $RPDR{A}_{EGRBAC}=RPDR{A}_{EGRBAC}\backslash ((r_i,E{R}_x),d{r}_y)$ 17:            $RPDR{A}_{EGRBAC}=RPDR{A}_{EGRBAC}\cup$ 18:                                                                                  $\left\{((r_j,E{R}_x),d{r}_y)\right\}$ 19:         end for 20:     end if 21: end for

4.2.5. The output of EGRBAC Constructing Approach on Use Case B

The output of EGRBAC role constructing algorithm for Use Case B is shown in

Table 10. The output of EGRBAC constructing approach on Use Case B.

(a) $U_{EGRBAC}=U_{HABA{C}_{\alpha }},D_{EGRBAC}=D_{HABA{C}_{\alpha }},O{P}_{EGRBAC}=O{P}_{HABA{C}_{\alpha }}$, $P_{EGRBAC}=\{(iPad,A5)$, $(iPad,A8)$, $(iPad,A11)$, $(iPad,Games)$, $(iPad,Movies)$, $(FrontDoor,Lock)$, $(FrontDoor,Unlock)$, $(lawnMower,ON)$, $(lawnMower,OFF)\}$

(b) $DR=\{DangerouseDevices=True,$

$DangerouseDevices=False,$

$KidsFriendly=True$, $KidsFriendly=False$,

$RemPerm\}$.

(c) $PDRA=\left\{\right((iPad,A5),KidsFriendly=True)$,

$(iPad,A8),KidsFriendly=True),$

$\left(\right(iPad,A11),KidsFriendly=False),$

$\left(\right(iPad,Games),KidsFriendly=False),$

$\left(\right(iPad,Movies),KidsFriendly=False),$

$\left(\right(FrontDoor,Lock),DangerouseDevices=True),$

$\left(\right(FrontDoor,Unlock),DangerouseDevices=True),$

$\left(\right(lawnMower,ON),RemPerm),$

$\left(\right(lawnMower,OFF),RemPerm)\}$.

(d) $EC=\{True,$

$e{c}_1$≡$ParentInTheHouse\left(current\right)=True$,

$e{c}_2$≡$day\left(current\right)\in \{Sa,S\}$,

$e{c}_3$≡$12:00\le time\left(current\right)\le 19:00$,

$e{c}_4$≡$day\left(current\right)\in \{M,T,W,Th,F\}$,

$e{c}_5$≡$17:00\le time\left(current\right)\le 19:00\}$.

(e) $ER=\{Any\_Time,$

$e{r}_1$≡$ParentInTheHouse\left(current\right)=True$,

$e{r}_2$≡$day\left(current\right)\in \{Sa,S\}$≡$Weekend$,

$e{r}_3$≡$12:00\le time\left(current\right)\le 19:00$≡$Afternoon$$and$$Evening$,

$e{r}_4$≡$day\left(current\right)\in \{M,T,W,Th,F\}$≡$Weekdays$,

$e{r}_5$≡$17:00\le time\left(current\right)\le 19:00$≡$Evening\}$.

(f) $EA=\left\{\right(\left\{True\right\},Any\_Time)$, $(\left\{e{c}_1\right\},e{r}_1)$,

$(\left\{e{c}_2\right\},e{r}_2)$, $(\left\{e{c}_3\right\},e{r}_3)$, $(\left\{e{c}_4\right\},e{r}_4)$, $(\left\{e{c}_5\right\},e{r}_5)$ }.

(g) $R=\{r_a,r_b,r_c\}$.

(h) $UA=\{(bob,r_a),(john,r_b),(suzanne,r_c)\}$.

(i) $RP=\{(r_a,Any\_Time),$

$(r_b,Any\_Time),$

$(r_b,\left\{e{r}_1\right\}),$

$(r_c,\{e{r}_2,e{r}_3\}),$

$(r_c,\{e{r}_4,e{r}_5\})\}$.

(j) $RPDRA=\left\{\right((r_a,An{y}_{T}ime)$, $DangerouseDevices=True),$

$((r_a,\{Any\_Time\})$, $KidsFriendly=True),$

$((r_a,\{Any\_Time\})$, $KidsFriendly=False),$

$((r_a,\{Any\_Time\})$, $RemPerm),$

$((r_b,\left\{e{r}_1\right\})$, $DangerouseDevices=True),$

$((r_b,\{Any\_Time\})$, $KidsFriendly=True),$

$((r_b,\{Any\_Time\})$, $KidsFriendly=False),$

$((r_c,\{e{r}_2,e{r}_3\})$, $KidsFriendly=True),$

$((r_c,\{e{r}_4,e{r}_5\})$, $KidsFriendly=True\left)\right\}$.

.

The maximum number of created device roles is $O\left(\right|OPA|+|DA\left|\right)$. Since we create an environment role and an environment condition for each logical environment condition, the maximum number of environment roles and conditions is $\Omega \left(\right|ESA\left|\right)$. Finally, the maximum number of user roles is $O\left(2^{\left|SA\right|+\left|ESA\right|}\right)$.

5. Comprehensive Theoretical Comparison

In this section, we compare and analyze $HABA{C}_{\alpha }$ and EGRBAC against access control criteria adapted from [9]. These criteria are classified into two types: (a) Basic and main criteria. (b) Quality criteria.

5.1. Basic and Main Criteria

Six elements are included in this type of criteria. Each element will be discussed below.

Table 11. Evaluating $HABA{C}_{\alpha }$ and $EGRBAC$ against basic and main criteria.

Criteria	$\mathit{EGRBAC}$	$\mathit{HABAC}$
1. Constraints
a. Static separation of duty	Yes	Yes
b. Dynamic separation of duty	Yes	Yes
c. P-R constraints	Yes	No
2. Attributed-based specifications
a. Static	Yes	Yes
b. Dynamic	No	Yes
3. Least privilege principle	Yes	Yes
4. Authentication	Positive (Close)	Positive (Close)
5. Access administration
a. User provisioning	Easy	Complicated
b. Policy provisioning	Complicated	Easy
6. Access review	Easy	Complicated
7. Administrative policies	Centralized	Centralized

summarizes this type of criteria comparison.

5.1.1. Constraints

These are invariants that must be maintained. EGRBAC supports three constraints: static separation of duty, dynamic separation of duty, and permission–role constraints. $HABA{C}_{\alpha }$, however, cannot support permission–role constraints, as we will discuss in Section 6.

5.1.2. 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$.

5.1.3. 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 $HABA{C}_{\alpha }$) 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.

5.1.4. 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.

5.1.5. 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 $HABA{C}_{\alpha }$). 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$.

5.1.6. 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 $HABA{C}_{\alpha }$) [66].

5.1.7. 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.

5.2. Quality Criteria

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

5.2.1. 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 $HABA{C}_{\alpha }$. 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.

5.2.2. 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 smart-home IoT requirements, it should be dynamic, fine-grained, and suitable for constrained smart-home devices. Moreover, The model should be constructed specifically for smart-home 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 $HABA{C}_{\alpha }$ 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 ABAC-based models (including $HABA{C}_{\alpha }$), it is more challenging to provision new policies in RBAC-based models than in ABAC-based models.

5.2.3. 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.

6. Discussion

In this paper, we present $HABA{C}_{\alpha }$. An attribute-based access control model for smart-home 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, $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ and $EGRBAC$, we introduced approaches for translating $EGRBAC$ configuration into an equivalent $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$, 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 $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ 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\left(d_x\right)=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 $d{r}_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) $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ 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.

7. Conclusions

In this paper, we defined the $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ 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 $HABA{C}_{\alpha }$ to prevent future authorizations of specific users from accessing specific operations on particular devices.

Finally, we conducted a comprehensive theoretical comparison between EGRBAC and $HABA{C}_{\alpha }$ against previously published criteria for access control models. We concluded that a hybrid model incorporating $HABA{C}_{\alpha }$ and EGRBAC features would be most appropriate for use in IoT-enabled smart homes, as well as more broadly.