Abstract
Access control is a key technology in providing security in the Internet of Things (IoT). The mainstream security approach proposed for the sensing layer of the IoT concentrates only on authentication while ignoring the more general models. Unreliable communications and resource constraints make the traditional access control techniques barely meet the requirements of the sensing layer of the IoT. In this paper, we propose a model that combines space and time with reputation to control access to the information within the sensing layer of the IoT. This model is called spatiotemporal access control based on reputation (STRAC). STRAC uses a lattice-based approach to decrease the size of policy bases. To solve the problem caused by unreliable communications, we propose both nondeterministic authorizations and stochastic authorizations. To more precisely manage the reputation of nodes, we propose two new mechanisms to update the reputation of nodes. These new approaches are the authority-based update mechanism (AUM) and the election-based update mechanism (EUM). We show how the model checker UPPAAL can be used to analyze the spatiotemporal access control model of an application. Finally, we also implement a prototype system to demonstrate the efficiency of our model.
1. Introduction
As a dynamic global ubiquitous network, the Internet of Things (IoT) links physical and virtual objects by integrating sensors, smart terminals, and global positioning systems (GPSs). Authoritative institutes predicate that the IoT will create hundreds of billions of dollars in savings and productivity gains for businesses, governments, and households: Cisco believes that the IoT will create a US$14.4 trillion business opportunity in 2020 (http://www.eetimes.com/document.asp?doc_id=1263115) and Groupe Speciale Mobile Association (GSMA) predicts that, in 2020, the connected life (one part of the IoT) will bring a US$4.5-trillion global impact on people and businesses (http://www.gsma.com/newsroom/gsma-announces-the-business-impact-of-connected-devices-could-be-worth-us4-5-trillion-in-2020/).
Along with the increasingly rapid development of the IoT, security issues have also become increasingly serious, especially when industrial controllers are either directly or indirectly connected to IoT. A typical example of this type of security compromise is the worm Stuxnet. Known as the first cyber-warfare weapon, Stuxnet was used to attack the Natanz uranium enrichment facility in Iran and is believed to have caused its production to drop by 15% in 2009 [1]. Obviously, security problems will cause a serious impact to the IoT.
As one of the key technologies involved in providing security, access control—determining who is allowed access, when access is permitted, and where access takes place—has been widely studied [2]. Access control models, which have been widely used, include role-based access control (RBAC) and usage control (UCON) [3, 4], Internet content control (ICCON) [5], Attribute-based access control [6], and user-driven access control [7].
Although these models succeed in the traditional Internet and operating systems, the IoT has raised several new and challenging issues surrounding the use of digital resources and its following critical characteristics make the above models not efficient any more. (1) Uncontrollable environments: sensors could be deployed in unattended environments, where physical nodes are more likely lost and false messages are more easily injected and transmitted. (2) Sensor-node resource constraints: computing and storage resources for sensor nodes are usually very limited, thereby severely constraining their ability to store and process the sensed data. Therefore high-weight access control models for the Internet should be revised for the sensing layer of the IoT. (3) Unreliable communications: the wireless communication adopted by the sensor nodes is often unreliable and unstable; therefore nodes may not receive the authorization in time. As a result, security in the IoT becomes more severe.
To minimize these threats, we proposed spatiotemporal access control based on reputation (STRAC), which considers time, location, and reputation as key elements in deciding whether access is granted or not. STRAC uses a lattice structure to decrease the storage complexity of policy bases. To reduce the risk caused by unreliable communications, we proposed nondeterministic authorizations (i.e., pessimistic, optimistic, and trade-off authorizations) and stochastic authorization. We demonstrate that pessimistic and trade-off authorizations are secure and that optimistic and stochastic authorizations can improve the QoS. In order to correctly update the reputation of nodes, we propose two novel policies (authority-based updates and election-based updates), based on the “group” characteristics of the sensing layer, and we prove that our proposed policies are secure. Our experiments show the efficiency of our model.
2. Related Work
Research about access control for the sensing layer can be divided into two general categories: access control algorithms (ACAs) and access control models (ACMs). ACAs mainly focus on new node addition. New node addition algorithms prevent malicious nodes from joining the sensor network. For example, [8] uses the self-certified elliptic curve Diffie-Hellman protocol to establish a pairwise key between new sensor nodes and the controller node, which launches a two-way authentication with the new nodes. However, in this scheme, all nodes share a network-wide key. Once one node is compromised, the secret key for all nodes must be updated, thereby causing huge losses. In order to solve this problem, [9, 10] proposes a new dynamic access control protocol, which uses hash functions to reduce computations and communications between two nodes.
In ACMs, much effort is spent on extending RBAC for pervasive computing. Reference [11] proposes a dynamic role-based access control (DRBAC) model, which provides context aware access control by dynamically adjusting role assignments and permission assignments based on context information. However, important features of the IoT (i.e., location and time) are not considered. In order to make RBAC more pervasive, many researchers extend RBAC by introducing time and location [12–15], where [12, 14] imposes spatiotemporal constraints on user-role assignments and permission assignments, and [15] introduces the concept of spatiotemporal zones and allows spatiotemporal constraints to be specified with prerequisite constraints. In addition, [16] adopts RBAC-based (role-based access control) authorization method using the thing’s particular role(s) and application(s) in the associated IoT network. Reference [17] designs a capability-based access control delegation model for the federated IoT network. Reference [18] focuses on a minimal use of computation, energy, and storage resources at wireless sensors and proposes a novel access control solution for wireless network services in Internet of Things scenarios.
Although RBAC is often extended for pervasive computing, these extensions cannot be widely adopted for the sensing layer of the IoT because of the PSPACE-completeness [19] of RBAC.
Other spatiotemporal models that are not based on RBAC are also proposed. Reference [20] uses composition algebra to regulate access to patient data and balances the rigorous nature of traditional access control systems with the “delivery of care comes first” principle. Recently, reputation has been incorporated into models of access control for cyber-physical systems as in [21, 22]; however, these particular models do not deal with the loss of nodes.
Our work differs from the above solutions in several ways. First, we consider reputation, rather than roles, as a fundamental factor of access control for the sensing layer of the IoT, because the behavior of selfish nodes can be directly modeled by reputation but not easily modeled by roles. Such a change is nontrivial. If a node becomes selfish, then we are only required to assign a lower reputation to it. Therefore, reputation is more suitable than roles in controlling access to the sensing layer.
Second, the existing access control models do not efficiently handle the problem caused by unreliable communications. We propose nondeterministic authorizations and stochastic authorizations to solve this problem. Our method reduces the security risks of security-critical systems when failing to receive the key authorization instructions.
Finally, the existing models for the IoT do not consider the group characteristics of the sensing layer. In our work, node’s reputation is cooperatively updated based on the group characteristics, thereby simplifying the reputation-update process.
3. Formalizing Time, Space, and Reputation
In order to construct a spatiotemporal access model based on reputation, we first formally define time, space, and reputation.
3.1. Reputation Description
Due to the limitations of storage and the computing resources, some nodes do not cooperate with others and demonstrate selfishness. In order to obtain more benefits, some nodes may attack others and demonstrate misbehavior. Because reputation (the opinion of one entity regarding another) can reflect both selfishness and misbehavior in interactions, it is adopted in modeling the behavior of nodes in our study.
Generally, from the aspect of reputation obtainment, reputation includes direct reputation (DR) and indirect reputation (IR), where DR and IR, respectively, refer reputation estimated by estimators based on their first-hand and second-hand experiences. From the aspect of goal, individual reputation should be distinguished with group reputation. Reference [23] surveys notions of reputation. In this paper, we only focus on individual and direct reputation, as follows.
We define reputation to have different ratings, and thus it can be denoted by a finite set; that is, , where is a reputation rating . Given any and in , they are mutually comparable, that is, or . Thus, is a total order set. For a given node, its reputation is formed and updated through direct observations of its behavior and through feedback provided by other nodes. In this paper, we concentrate on general access models and do not discuss the methods of computing reputation in detail.
3.2. Time Description
In order to describe operations that can only be executed within a given time period, the notion of a calendar is adopted [24, 25]. A calendar consists of a countable set of contiguous intervals, for example, years, months, and days. Because two calendars can have different granularities, a subcalendar relationship can be established among them. That is, given two calendars and, is a subcalendar of (written as ), if and only if there exists a natural number, such that . For example, days are a representative subcalendar of months. Obviously, is a partial order relation. A calendar base represents a set of calendars and generally changes with different contexts. For example, if a school curriculum is comprised of years, semesters, and weeks, then its is {years, semesters, weeks}.
Definition 1 (calendar time). Given , calendar time is defined as , where, and for all , one has .
Let be a set of calendar times. Generally, any two calendar times are always comparable. That is, for any and in , one can have or ( is the total order relation). In the IoT, different types of time constraints exist, such as the earliest access time (), the latest access time (), the earliest finish time, and the latest finish time. In our study, and are adopted.
Definition 2 (time constraints). Time constraint is a set of two-dimensional vectors of calendar times, where the first dimension and the second dimension represent and , respectively. Time constraints must satisfy the following condition: for any , .
Example 3. Given , , and an event satisfies , if access time (from start time to end time) of the event falls entirely within the time range from to , or within the time range from to .
A time constraint with overlapping ranges can be reduced to , based on the following definition.
Definition 4 (simplest time constraints). A time constraint is the simplest, if for any and , , , .
Henceforth, one assumes that time constraints are always the simplest. Given two time constraints and shown in Figure 1, where (1) — of —is greater than or equal to that of and (2) — of —is less than or equal to that of . If an event satisfies , then it will satisfy ; this means that is stricter than . Thus, one has Definition 5.
Definition 5 (order relation on ). Given and in , (meaning that is stricter than ), if and only if and , where and .
Proposition 6. on is a partial order.
Definition 7 (order relation on ). Given any and , (meaning that is stricter than ), if and only if, for any , there exists with .
Proposition 8. on is a partial order.
In the real environment, time constraints can be constructed by way of union or intersection of some constraints. One defines the intersection and the union as follows.
Definition 9 (intersection). Intersection is a function from to defined as where
Definition 10 (union). Union is a function from to defined as .
Because the time constraints obtained by computing are not always the simplest, one reduces them to the simplest form as follows. Given a time constraint , if there exists , , , with , , , then both , and (, ) are deleted from and , , , are inserted into . Obviously, the original is semantically equivalent to the modified . Henceforth, one assumes that the intersection and the union of time constraints are always the simplest.
Proposition 11. Given any and in , if is closed under and , then and are the supremum and the infimum of , respectively.
The definitions above concentrate on physical time. However, in some cases, logical time (such as work time or class time) is more important.
Definition 12. : is a function mapping to the nonempty power set of , where represents a set of names of logical time.
Definition 13 (order relation on ). Given any and in , if and only if .
Proposition 14. on is a partial order.
Definition 15 (intersection on ). (Here, we do not differentiate the of Definition 9 from the of Definition 15, because they are easily distinguished; Similarly, we also do not differentiate of Definition 10 and of Definition 16). is an intersection function mapping to , defined as , where and .
Definition 16 (union on ). is a union function mapping to , defined as , where
Proposition 17. For any and in , if is closed under and , then and are the supremum and the infimum of , respectively.
Proof that the supremum of is : from Definition 15, we have and ; therefore, is the upper boundary of . Next, we prove that is the least element of the upper boundary of . Let and ; then, for any , there exists and , such that and . According to Proposition 11, . According to Definition 15, ; therefore, so is the supremum of .
3.3. Location Description
In the IoT, physical locations are often distinguished from logical locations. Physical locations are divided into two classes: hierarchical (topological, descriptive, or symbolic), such as a room, and Cartesian (coordinate, metric, or geometric), such as GPS position [12, 14, 26]. Logical locations represent the boundaries of the logical space that corresponds to the physical space.
Let ,…, be a set of physical locations, where is a specific physical location, such as a 50 50 unit square area. Let ,…, represent the set of logical locations, where each in denotes the notion for one or more physical locations. Generally, relations between physical and logical locations are illustrated as a many-to-many map, denoted by .
Definition 18. A function : maps to the power set of , returning all physical locations assigned to a given logical location. In other words, .
Definition 19. A function : maps to the power set of , returning all assigned logical locations of a given physical location. In other words, .
Given two logical locations, a containment relation may exist. This is defined as follows.
Definition 20. A logical location is contained in another logical location , written as , if and only if .
Generally, physical locations of a given logical location are unchanged within a period; therefore, for simplicity, a logical location is used to denote its corresponding physical location. Similarly, one can define intersection and union based on logical locations, but one does not discuss them.
4. STRAC Framework
First, we provide an overview of the framework of our model. As shown in Figure 2, STRAC consists of two core components: the access request component (ARC) and the reference monitor component (RMC). The ARC of a node creates an access request, which has two forms: the first form includes five elements: the node’s , the accessed object , the expected operation to be performed on , the node’s current location (generally, a node’s location information may come from GPSs or wifi), and the node’s reputation ; the second form includes three elements: the node’s , the accessed object , the expected operation to be performed on , and the node’s current location . In the first form, each node locally stores its reputation and physical location; in the second form, the reputation of each node is centrally stored in PEP (see the next paragraph for PEP) and its physical location is tracked by PEP.
RMC includes two modules: policy enforcement point (PEP) and policy decision point (PDP). The PEP module receives the user request, consults with the PDP module about the user authorization, and ensures that all access requests go through the PDP module. PEP is comprised of two submodules (access request extractor (ARE) and authorization token requester (ATR)) and two access tables which map the current time and physical locations to the logical time and the logical location, respectively (the two tables are called ID-RTL table in Figure 2). When the PEP module receives an access request from a user, ARE executes two steps: (1) it accepts the request and extracts the encapsulated location, , , , , and if the first type of access requests is adopted; it extracts , , and if the second type is used, and (2) it queries the access database and returns the ’s logical location and logical time (in addition to the three elements, it returns the reputation of node if the second type of access requests is used). ATR encapsulatesthis information , , , , and and sends it to the PDPmodule to request an authorization token (AT). Once this request is granted, an AT will be returned, and the user can access the target resources using this AT. PEP maintains a list of users’ ATs, and this list is updated at a specified interval. AT will be revoked when the user deactivates the task or when the location and time associated with the use are out of the allowed scope.
The PDP module, comprised of one submodule (Authorization Token Granter (ATG)) and one policy base, makes the authorization decision based on a set of rules or policies. When PDP receives an AT request, it extracts the information , , , , and from the request and consults the security policies. If the polices denote that a node with reputation at the time period in the location has the right to perform the operation on the target , then ATG grants to access request.
The source of authority (SOA) is administrator or a group of administrators, who define the policies. SOA can also update the policy at runtime if necessary. In some cases, group nodes may also cooperatively update the node’s reputation and make access decisions based on stochastic information (stochastic authorization in Figure 2).
Our model can be implemented with two alternative modes: ACI and AII. ACI focuses on authorization when complete information is available, while AII deals with authorization having only incomplete information. The precondition for ACI is that decision makers always can obtain authorization information in time. In other word, ACI requires a stable communication. Contrarily, this precondition is not necessary in AII. AII is very useful because unstable communications in the IoT are considered to be persuasive phenomenon. Generally, while in the ACI mode both PEP and PDP are mounted in the gateway and ARC is integrated into terminal nodes. Contrarily, to implement the AII mode, ARC and two lightweight modules, PEP and PDP, are mounted into terminal nodes.
5. STRAC Model
5.1. Basic Components of STRAC
The basic STRAC model is comprised of the following components: ,…, is a set of node IDs; ,…, is a set of reputations; for example, , ; ,…, is a set of logical time constraints; ,…, is a set of logical locations; for example, , ; ,…, is a set of operations; for example, , ; ,…, is a set of target objects; for example, , ; is a set of permissions, where , means that is performed on . For example, if , is assigned to device , then the device owns the permission to open ; is a set of , where each access zone is a triple , , ; is a many-to-many map of connections between permissions and access zones. , means that any node with has permission . For example, denotes that a node satisfying the constraint of with reputation at location can execute operation on object ; : assigns a permission level to access zones, where , ; that is, given a , function returns all access zones which the can access. For example, if , , , , , , , , , , , , , , , then , , , , , , ; : assigns an access zone to permissions, where , ; that is, given an , function returns all permissions by which the can be accessed. For example, in the example of , , , , , , ; : , is a predicate; if it returns true, then node requests permission to execute on . Recall that the storage of is either distributed or centralized. To model the two cases, we remove from access requests; for simplicity, we also remove the ID’s location and reputation from access requests and encapsulate the three elements into the function (we will discuss it next); : , is a predicate; if it returns true, then node is allowed to on ; : , is a predicate; if it returns true, then node is not allowed to execute on ; : , is a predicate; if it returns true, then the permission that node executes on will be revoked; : is a function and returns ’s current reputation, its logical time, and logical locations (a node may be located in many different logical locations).
In order to return the logical locations of a node, its physical location must be first obtained, and then its logical locations can be computed using the function . Because a physical location can be associated with many logical areas, returns a set of logical locations.
5.2. Mechanism for Authorization and Revocation
Intuitively, if a node located in an appropriate area has an acceptable reputation and satisfies the given time constraints, its requests to execute some operations on an object should be allowed. In order to avoid using too many symbols, we overload the notation , as follows.
Given , , and , let and = ; if and only if there exists ∈ with , ( if and only if holds, where ) and . The authorization schemes are as follows:(1)(2)(3).
Formulas (1) and (2) show the following: (1) if the node requests permission to execute on , and if (the current reputation, access time, and location of ) satisfies the conditions to execute on , then the request will be allowed; (2) if the node requests permission to execute on , but does not satisfy the conditions to execute on , then the request will be denied. Formula (3) suggests that if node has received the permission of executing on and no longer satisfies the conditions to execute on longer, the permission will be revoked.
6. Access Lattice
Because terminal nodes could move into many areas at different times, enumerating all areas and periods of time rapidly increases the size of PA (as shown above, PA connections between permissions and the power set of access zones). As a result, the size of the PA table could exceed the storage capacity. In addition, querying a big table consumes more energy and computing resources, thereby decreasing the efficiency of queries and even reducing a node’s lifetime. Thus, decreasing the size of permission access table is critical. In order to achieve this goal, we adopted the access lattice in this study.
We make the following realistic assumptions regarding the sensing layer of the IoT. (1) A node with a high reputation can be granted all permissions of a lower-reputation node. (2) If a task can be executed in a wide area or a longer time period, then it can be also executed in a narrow area or a shorter time period. These assumptions mean that if one node owns two access zones and , where is stricter than , then can be omitted from the set of access zones, because any permission allowed under is allowed under . We chose the lattice to decrease the size of the permission access table, because it models the strict relationship among elements. In order to formally describe the access lattice, we first define the order relation.
Definition 21 (). Given any and , , if and only if , , .
Theorem 22. If (1) is closed under and and (2) is closed under and , then is a lattice.
Proof that there exists a supremum and an infimum for any , : if and are comparable, then there exists a supremum and an infimum for them. Even if and are incomparable, there exists a supremum and an infimum for them. Because on is a total order, there exists a supremum for ; let the supremum be , because is closed under both and , and is closed under and ; therefore, is in and is the upper boundary of and . Let be another upper boundary of and , then we have and ; therefore, . Because is the supremum of , . According to Proposition 17, we have . Thus, . Therefore, is a supremum of and . Similarly, is an infimum of and , where is an infimum of .
We assume that is closed under and , is closed under and . We redefine the permission function under a lattice, as follows:
: maps the access zones to permissions, and .
Because and are similar and easily distinguished from one another; therefore, is adopted to denote the two functions in the sequel. Similarly, is used to denote .
Theorem 23. Given any and , if , then .
Theorem 24. Consider the following.
If , then .
If , then .
If , then .
Theorem 24 shows (1) if a node with a low reputation can execute on , then another node with a higher reputation is also able to perform the same operation; (2) if a node with a high reputation is unable to execute operation on , then a node with a lower reputation is also unable to do so; and (3) if access permissions are revoked from a node with a high reputation, then the corresponding permissions are also revoked from a node with a lower reputation.
The following example illustrates that the lattice can efficiently decrease the size of policy bases.
Example 25. Let , , , , , , , , , . The access base for each permission is as follows: , , , , , , , and , . From above, the cardinality of , , , , and , is 4, 2, and 1, respectively.
Assuming that a lattice can be formed from these access zones as shown in Figure 3, then the access base for each permission could be changed as follows: , , , , and , . This means that the cardinality of all three bases is 1. Given an access request , , from node with reputation and assuming that node is at the location and the current time satisfies , then , , will be true, because . From this example, we can deduce that the size of policy bases can be decreased using an access lattice.
Regarding the example given in the beginning of this section, if the above lattice is used, the storage complexity and the computing complexity are reduced to and 1, respectively.
7. Authorization under Incomplete Information
In the above discussion, we mainly focused on authorization with complete information available (ACI), which is also called deterministic authorization. In other words, decision makers have the ability to obtain authorization information in time. However, this is not always the case. For example, when a node moves into a location where communication is unstable, it may not be able to obtain complete authorization information in time. In this case, decision makers have to choose whether to grant authorization or not, based on their own knowledge, such as historical experiences. This is related to authorization with incomplete information (AII). Lack of complete information presents the following challenges: (1) designing a secure authorization policy and (2) balancing security with QoS. To address these two challenges, we propose both nondeterministic authorizations and stochastic authorizations.
7.1. Nondeterministic Authorization
Nondeterministic authorization includes three alternative policies: pessimistic, optimistic, and compromise authorizations. Nodes run under the lowest permission levels in a pessimistic authorization, thus, providing only the most basic security.
Policy 1 (pessimistic authorization). Given a access lattice formed by and an access request , if , then the request is allowed, where represents the greatest lower bound of set i.e., the smallest elements of .
In order to execute Policy 1, all elements in must be locally stored. Although additional storage space is required by Policy 1, because both the greatest lower bounds of a lattice are unique, the storage complexity of the access rule table in Policy 1 is ; therefore, it is acceptable for the majority of weak-resources devices. Because glb() is granted to the lowest permissions, Policy 1 is always secure (see Theorem 27 for the proof); however, this policy might have a lower QoS. For example, if the least permission is (empty), then any request will be automatically denied.
Contrary to pessimistic authorization, optimistic authorization concentrates on QoS while ignoring security. In this policy, nodes are granted the highest allowable permissions. From Theorem 22, is the largest element of , where represents the least upper boundary of . Thus, the greatest permissions are granted to .
Policy 2 (optimistic authorization). Given an access lattice formed by and an access request , if , then the request is allowed.
As with Policy 1, all elements of must be locally stored. Because any node in this policy is granted the greatest permissions, Policy 2 is not considered to be secure (see Example 28 for an example). However, this policy can efficiently improve QoS. For example, if the number of nodes with access to a film in digital rights management (DRM) is only optionally counted, any node can access this film anytime and anywhere, even when communications have been interrupted. If the film is stored locally, Policy 2 should be adopted, because security is not as much of an issue; if Policy 1 was used, the benefits surrounding optionally counting accesses cannot be achieved. Thus, Policy 2 has a higher QoS.
In many cases, security and QoS are needed to be balanced. To achieve this goal, we propose three compromise authorization policies: (1) trade-off authorization based on reputation , (2) trade-off authorization based on space , and trade-off authorization based on time . We first discuss .
Let : be a function from to , defined as , representing the greatest lower boundary of access zones accessed by a node with reputation .
Policy 3 (). Given an access lattice formed by and an access request in , if , where is the reputation of node , then the request is allowed.
Similarly, let : map from logical locations to , defined as , representing the greatest lower boundary of access zones accessed by a node in logical location .
Policy 4 (). Given an access lattice formed by and access request in , if , where is the current logical location of node , then the request is allowed.
Let : be a function from to , defined as , representing the greatest lower boundary of access zones accessed by a node satisfying time constraint .
Policy 5 (). Given an access lattice formed by and an access request in , if , where (function : returns the current time), then the request is allowed.
Because Policies 1–5 are related to incomplete information, their security must be formally analyzed.
Definition 26 (security under ). A policy is secure under if for any access request , under is the same as under .
Theorem 27. Policy 1 and Policies 3–5 are secure.
Proof that Policy 1 is secure: given node id with reputation and an access request , because is allowed under Policy 1, we have . Let be the reputation, the current time, and the logical location of node under , where exists with , if and and . Because is the least element of , we have . According to Policy 1 and Theorem 23, we have ; therefore, , under is true. That is, Policy 1 is secure.
Although Policy 1 and Policies 3–5 are secure, Policy 2 is insecure. An example is as follows.
Example 28. Let with . According to Theorem 23, there exists with -. will be allowed if Policy 2 is adopted; however, this request will be denied under . This means that Policy 2 is insecure. Because security obeys the “leaky bucket” principle, Policy 2 is not suitable for security-critical systems.
7.2. Stochastic Authorization
In some cases, authorization may be considered to be stochastic. For example, when an automatically driven car arrives at crossroads, its central controller selects the road with the most gains (including both time and fuel-saving gains) by computing the distance to the destination and forecasting the probability of road congestion. In this case, road congestion is stochastic; as a result, the authorization is stochastic. Although stochastic authorization is actual requirement in the IoT, no efforts are spent on it in existing studies. In our study, we propose the (to the best of our knowledge) expectation-based authorization (EBA), where decision makers evaluate access requests by analyzing its potential gains in the successor states that would occur if the authorizations were granted. If the potential gains of the request are greater than or equal to a given threshold, it will be allowed. includes the following elements besides the components mentioned in Section 5.1:(1) is a set of states representing the potential successor states which the systems can arrive to after authorization.(2): is a gain function, and represents the gain of decision makers in state , is a real number.(3): is a probability distribution of state set , and denotes the probability that systems would reach state .(4)Threshold .
The authorization rule is as follows: for any Access Request, if , then this request is granted. If several access requests exist and only one is allowed, then the request with the maximum gain is granted permission. Additionally, if multiple requests could have the maximum gain, then the decision maker randomly chooses among those requests.
As with Policy 2, expectation authorization improves the QoS. In the above example of automatic-driving systems, pessimistic authorization would deny any access request to each road, whereas optimistic authorization would allow all access requests for all roads. This is unacceptable for the automatic-driving systems. Thus, nondeterministic authorization (pessimistic/optimistic authorization) is unsuitable for automatic-driving systems. Conversely, because both the road environment and the historical experiences are taken into consideration to ensure that only the request with the maximum gain is allowed, stochastic authorization is suitable for automatic-driving systems.
8. Mechanism for Updating Reputation
Because nodes of the IoT are easily tampered with, the reputation of the tampered nodes must be updated in time. In this section, we borrow the idea of downgrading in programming languages [27] and propose a new mechanism to update the reputation for the sensing layer of the IoT. In this mechanism, every node is bound to an update policy and any change to a node’s reputation must be consistent with the bound policy; that is, the reputation can be updated, only if a given policy for that node is satisfied. The syntax of the general update mechanism is defined in Table 1.
The above definitions are based on Backus Normal Form; for example, is grammatically correct. In Table 1, if the empty policy is adopted for a node, then its reputation is preserved. Given for a node means that if condition is true, then the reputation of the node will be updated to , and the successor of the policy is updated to . The formal semantics of this mechanism are as follows: where represents the node as bound to andfunction : returns the current reputation of a given node. [/] denotes that is substituted by . indicates that if the predicate is true, then the current reputation of node will be updated to and its new policy is . stops the update. Specifically, when the update policy for a node is , then its reputation will be mandatorily updated to . In contrary, if the policy is , then the update will be forbidden.
In Table 1, basic predicates are coarse-grained and difficult to use. In order to solve this problem, we propose two submechanisms: authority-based update mechanisms and election-based update mechanisms .
8.1. Authority-Based Update Mechanisms (AUM)
In , only the authority node can update the reputation of other nodes. A node is called an authority node if its reputation is greater than or equal to a given threshold , where represents the authority reputation. To formally define semantics, we first provide the following definitions.
: returns the current time and the set of current logical locations for a given node.
is a subset of the product of and . A node is granted the update permission, only if its current time and one of its current logical locations belong to the set . In other words, node can update the reputation of other nodes, only if (let , and , ,…,, , we define , if and only if there exists such that and , .
The formal semantics of AUM are as follows:
The predicate is true, if and only if there exists with , , , , and . The rule states that the reputation of node can be updated to if the following conditions are satisfied: (1) ; that is, node is an authority node. (2) ; that is, node satisfies the temporal and spatial constraint. (3) The current reputation of node and its reputation after update are both greater than or equal to .
AUM can prevent a node’s reputation from being illegally updated even if authority nodes are lost. For example, the authority node in the location can update the reputation of others. If is lost, it may not be in the location . Let be in the location with , therefore, making . This means that no longer has the ability to update the reputation of other nodes.
8.2. Election-Based Update Mechanisms (EUM)
Although can be used to decrease the risk caused by the loss of nodes, authority nodes are security-critical because of the huge risks involved if they are compromised. In order to solve this problem, we propose . In , a group of nodes with a lower reputation are able to update the reputation of others through elections. When the majority of voters (nodes) agree on an update, the reputation of a specific node can be updated. In order to precisely define this mechanism, we first define the update function , which maps to : If a voter requests to update the reputation of candidate to , then . The formal semantics of is as follows: where , , and is a natural number. shows that if at least nodes satisfying the given time constraints in the given areas request to update the reputation of node to , then these requests will be approved and id’s reputation will be updated. Because can update the reputation of any other node, must be carefully defined, especially in networks where malicious nodes are dominant. Generally, could be equal to or , where is the number of voters.
Example 29. Let the update policy of node be ; we have the following results.(1)If the current reputation of is greater than , then the reputation of will be preserved.(2)If authority node , which is not located in the given areas or does not satisfy the given time constraints (i.e., ), requests to update the reputation of node will be denied and the reputation of will be preserved.(3)If the current reputation of is less than and authority node requests to update the reputation of node , where and , then this request will be approved and the reputation of will be updated to .
Example 30. Let the update policy of node be and let its current reputation be . In this case, if at least 10 nodes at a given period and location send requests to update the reputation of to , then the reputation will be updated.
8.3. Order Relation
It is possible that a single node owns two update policies, with one policy being stricter than the other. In this case, an order relation can be constructed to decrease the consumption of computing resources. Let denote that is stricter than; that is, if can be adopted, then can be used. is recursively defined as follows (note that only is considered here):
shows that the empty policy is the loosest because it can be used anywhere and anytime; denotes that if (1) is greater than or equal to and (2) is stricter than , then is stricter than .
To study the properties of , we define the necessary function , which maps policy to the reputation, as follows:
Proposition 31. If , then first.
Proposition 32. If and , then / /.
Theorem 33. is a total order, where is a set of policies.
Theorem 34. For any nonempty policies and , such that , if there exists a nonempty policy with : : , then there also exists a nonempty policy with : : and .
Proof. Let be . From and ruleauthority, we have with , , , , and . Let be . Because , we have and . Because , we have . From Proposition 32, we have , where .
9. Verification of Security Policy
The STRAC model has many features that could interact with each other, causing conflict and inconsistency between security policies. As a result, security policies must be verified before they are applied. Tediousness and proneness of manual analyses make automatic verification necessary. UPPAAL [28] is an integrated model checker for modeling, validation, and verification of real-time systems modeled as networks of timed automata. In this study, UPPAAL is used to verify whether the policy conforms to security requirements or not. When requirements are violated, the tool pictorially shows how the property has been violated and generates a counterexample to help security designers fix the policy.
To illustrate how to formally specify and verify a STRAC policy, we consider smart home applications. We assume the existence of four smart devices in this example: (1) a TV set , (2) an air conditioning unit, (3) a microwave , and (4) an electric rice cooker . Each of these devices can be remotely controlled using mobile terminals. We also stipulate that parents and their children can use these devices only in the office, school, and home. In order to provide the necessary security for these devices, we make the following security policies: (1) the TV set and the can be closed or opened either remotely or locally because of the low heat produced by such devices; (2) the can only be opened locally but can be closed remotely because of the high degree of heat that it produces; the can be opened by parents either remotely or locally but cannot be opened by children remotely, because of the heat produced by the and the need to configure a time parameter, which can be performed only by parents; because of the limitations regarding power load, the maximum number of devices that is able to run simultaneously is set to three; every device only runs during the specified time.
9.1. Model
We integrate the components of STRAC as follows: is a set of mobile terminal IDs based on the assumptions that (1) Terminal 0 is owned by children and is used in school and at home, (2) Terminals 1 and 2 are owned by parents and are used in multiple locations (school, office, and home), and , , where and denote high reputation and low reputation, respectively. We assume that the reputation of Terminal 0 is low and the others are high. , , , is a set of logic constraint times, for operating , , , and . , , , , , , , , , , and , , ; is the product of , , and . is a core component determined by control policies, as shown in Table 2. In Table 2, the product of the left and right columns of any row is an element of . For example, , . According to Table 2, and can be obtained (not discussed in this paper). For any access request, a decision can be made. For example, a child requesting to open in will be denied.
9.2. Policy Verification
In the home applications discussed above, three kinds of entities exist: mobile terminals, RM (as shown in Section, RM denotes reference monitor), and the related devices , , , and . In UPPAAL, these entities are denoted as , , and , respectively. In this scenario, mobile terminals send access requests to the RM. Upon receiving these requests, RM retrieves the stored access rule table, decides whether to approve these requests, and sends the result to the controlled devices.
An access request consists of six parameters (as shown in Section 3.1, only three parameters are needed; however, in UPPAAL, we cannot get the current time; therefore, the parameter is necessary. For simplicity, both and are provided here): (ID of the mobile terminals), (location of the mobile terminals), tm_rm_time (current time), (target device), (operation to perform on the target device), and (timer for ). Figure 4 gives the timed automata of mobile terminals, where is an input parameter, is a channel, and is a set of all locations , , and . The remaining variables are similar to .
As shown in Figure 5, receives access requests from the channel , checks the state (busy or free) of the controlled device, and makes a decision according to the reputation and location of the mobile terminals and the current time. This decision is then sent to the corresponding device.
Figure 6 illustrates the timed automata of controlled devices. The initial state of each device is DevOff. When the instruction arrives, the corresponding device starts to run. If the instruction arrives, the corresponding device stops running. In , is used to store the time parameter of the timer.
The composition (MobileTerm Device) of the above three timed automata forms a timed automation network, and we can use this network to verify policies. In our studies, three properties are verified: (1) “deadlock must be avoided in smart home applications.” This can be specified as “A not deadlock” by using computation tree logic (CTL); (2) the number of simultaneously running devices is always less than or equal to three. This can be specified as “A not (Device(TV).DevOn and Device(AC).DevOn and Device(RC).Heating and Device.DevOn)”; (3) when the parents open a microwave in office, the microwave would always switch to the state, which is “(tm_rm_id==1&&tm_rm_loc==office&& tm_rm_time==8&&tm_rm_dev==&& tm_rm_op== open) -->Device.Ripe,” where the reputation of Terminal 1 (belonging to the parents) is high and the current time (m_rm_time==8) is within the work time of .
We use UPPAAL to verify the three properties, and the result shows that the first two properties are true. This means that the system is deadlock-free and that the number of simultaneously running devices is always less than or equal to three. Property (3) is proven to be false, meaning that, even when parents start the microwave while in the office, the microwave does not necessarily switch to the state. A counterexample is as follows: if parents start the microwave and the rice cooker at the same time in the office, the child will not be able to start the air conditioning and watch TV due to the power load limitation. In this case, children could stop the microwave, thus preventing it from switching to the state.
10. Experiments
We develop a prototype (shown in Figure 7) that implements STRAC. In our prototype, we use a network topology consisting of 10 terminal nodes (TeNs) uniformly deployed in a area with TeNs surrounding a sink node (SiN), where Texas Instruments CC2530 chips with 8-KB RAM and 256-KB programmable flash are adopted for the TeNs and an ST Microelectronics STM32 chip with 64-KB RAM and 512-KB programmable flash was used for the SiN (CC2530 and STM32 chips are widely used as wireless transceivers and data processors in industry). The ZigBee protocol is used for communications between the TeNs and the SiN. The ARC component is mounted on the TeNs while RMC components are mounted on the SiN. ARC and RMC are written as traditional programs.
Generally, heavyweight database servers, such as MySQL, are not appropriate for terminal nodes because of their limitations in storage and computing resources. To solve this problem, we implement a table query algorithm in our prototype and we also design two database tables: an ID-RTL table that maps node ID to an RTL triple (the reputation of the node, the current logic time, and the current time location) and an access rule table that stores PA (as shown in Section 5, PA connects permissions with access zones). The ID-RTL table is integrated into the PEP components and is only accessible by TeNs and PDP, while the access rule table is mounted into PDP components and is only accessible by PEP. Our experiment setup is as follows: (1) reputation is set to 5 ratings, (2) TeNs could move into 100 different areas at 10 logical time periods, and (3) TeNs may perform 3 operations on 50 objects. After is explicitly defined, a series of experiments are conducted. The results reported in this section are averaged over 10 runs.
Experiment 1 (correctness of implementation). To evaluate correctness of implementation, we create two groups ( and ) of access requests in two local files: any request of Group is in the access rule table; that is, any request from should be approved; all elements in Group are out of the access rule table; that is, any request from should be rejected. Groups and allow us to test whether our prototype works as anticipated. The experiment result shows that all requests from group are approved and all requests from group are rejected. This fact demonstrates the correctness of our implementation.
Experiment 2 (storage resources). In this experiment, two cases are considered in one is “given one permission, the number of its access zones is randomly generated” (called random scheme); the other is “given one permission, the number of its access zones is constant” (called constant scheme). The experiment result is as follows.
Random Scheme. If PA is compiled with the nonlattice strategy, 7500 access rules occupy 36.5 KB of programmable flash; however, if the lattice strategy is adopted, only 3750 access rules are needed; as a result, 36.62 KB of programmable flash is consumed, which is about 100.3% of memory used by the nonlattice strategy.
Constant Scheme. If PA is compiled with the nonlattice strategy, 15000 access rules occupy 73.24 KB of programmable flash; however, if the lattice strategy is adopted, only 3900 access rules are needed; as a result, 30.48 KB of programmable flash is consumed, which is about 41.6% of memory used by the nonlattice strategy.
Note. In this experiment, PA is stored via a two-dimensional array. This means that for any two permissions, their consumed storages are the same and equal to ()/ (). As a result, in the random scheme,the storage occupied by the lattice strategy is slightly greater than that of the lattice strategy. If PA is stored via files or pointers, the occupied storage will approach the constant scheme.
Experiment 3 (average response time, ). To evaluate the response time of our scheme, we add a Group of access requests: almost half of the access requests in Group are in the access rule table. Each TeN continuously sends 1400 access requests to the SeN. The experiments show that the , which is the average delay from receiving a request to returning the response, is 21.4 ms if the nonlattice policy is adopted. The is reduced to 18.6 ms if the lattice policy is used, which is about 86.9% of the time used by the nonlattice strategy.
Experiments 2 and 3 show that the lattice policy is better overall than nonlattice policy and that the storage resource consumed and the response time of our model are acceptable for the sensing layer of the IoT.
11. Conclusions
The IoT presents new types of architectures, vulnerabilities, and requirements. Consequently, existing access control models have to be revised to accommodate these changes. Although spatiotemporal access models have been proposed in previous studies, most of them ignore some important characteristics of the sensing layer of the IoT. In this paper, we abstract the basic characteristics of the IoT’s sensing layer and propose a model (called STRAC) that combines space and time with reputation for access control of the IoT’s sensing layer. Our model solves the problem of deciding and to authorize access requests and is able to access information by using spatial/temporal information, and it uses nondeterministic/stochastic authorizations to deal with unstable communications. These methods either provide better security or improve the QoS. In order to more precisely manage the reputation of nodes, we present a novel mechanism to update reputation and demonstrate its security. STRAC overcomes the inadequacies of existing access controls while acting as an access control foundation for the sensing layer of the IoT. In future work, we will design a scheme to find the optimal trade-off between security and QoS.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This work was supported by the National High Technology Research and Development Program of China (Grant no. 2013AA014002), the National Natural Science Foundation of China (Grant nos. 61100181, 61100186, and 61262008), Guangxi Natural Science Foundation (Grant no. 2014GXNSFAA118365), and the Key Project of Education Department of Guangxi.