Enforcing spatio-temporal access control in mobile applications

Abstract

Mobile application technology is quickly evolving and being progressively utilized in the commercial and public sectors. Such applications make use of spatio-temporal information to provide better services and functionalities. Authorization to such services often depends on the credentials of the user and also on the location and time. Although researchers have proposed spatio-temporal access control models for such applications, not much has been done with respect to enforcement of spatio-temporal access control. Towards this end, we provide a practical framework that allows one to enforce spatio-temporal policies in mobile applications. Our policy enforcement mechanism illustrates the practical viability of spatio-temporal authorization models and discusses potential challenges with possible solutions. Specifically, we propose an architecture for enforcing spatio-temporal access control and demonstrate its feasibility by developing a prototype. We also provide a number of protocols for granting and revoking access and formally analyze these protocols using the Alloy constraint solver to provide assurance that our proposed approach is indeed secure.

Appendices

Appendix A

1.1 Alloy specification of the access control protocol

Appendix B

1.1 Alloy specification of successful MITM attack

Appendix C

1.1 Spatio-temporal access control model specification

We present our complete model and formalize its specification using the unified modeling language (UML) and the object constraint language (OCL).

1.2 Effect of spatio-temporal constraints on RBAC entities

The RBAC entities: users, roles, permissions, and objects are associated with spatio-temporal zones.

Users We assume that each valid user, interested in doing some location-sensitive operations, carries a locating device that is able to track his location. The location of a user changes with time. The spatio-temporal zone associated with a user gives the user’s current location and time.

Note that, time and location can have different levels of granularity. For example, the current time can be expressed as 12:00:05 or 12:00 pm. Similarly, a user’s current location can be Fort Collins or it can be Colorado. The user’s current location and time information will be used for making access decisions. Consequently, we require the minimal temporal and location be used to express the spatio-temporal zone associated with a user. We define the function $currentzone$ that returns the minimal spatio-temporal zone associated with a user. This function is formally defined as follows:

• $currentzone: Users \rightarrow STZones$

Objects Objects may also be mobile like the user. Here again, we have locating devices that track the location of an object. Moreover, an object may not be accessible everywhere and anytime. For example, tellers can only review customer information at a teller office during working hours. The ozones function returns the spatio-temporal zones that determine where and when every object is available.

• $ozones: Objects \rightarrow 2^{STZones}$

Roles Role can be assigned or activated only in specific locations and time. The role of on-campus student can only be assigned/activated inside the campus during the semester. The spatio-temporal zone associated with a role gives the location and time from which roles can be assigned or activated. The $rzones$ function gives the set of spatio-temporal zones associated with a given role.

• $rzones: Roles \rightarrow 2^{STZones}$

Permissions Permissions are also associated with a spatio-temporal zone that indicate where and when a permission can be invoked. For example, a permission to perform a backup of servers can be executed only from the department after 10 pm on Friday nights. The function $pzones$ gives the zones in which a specific permission can be accessed.

• $pzones: Permissions \rightarrow 2^{STZones}$

Figure 10 shows the class diagram of GSTRBAC. Therefore, a security policy of a mobile application can be specified as one possible instance of this GSTRBAC class diagram. The GSTRBAC entities: User, Role, Permission, Object, Activity, and STZone, are represented by classes. Permission is represented in the GSTRBAC class diagram as an aggregation of the classes Object and Activity. The STZone class aggregates the location and time subclasses. In STZone class, zcontainment is a reflexive association specifying that a zone can contain other zones. Different relationships between entities including UserRoleAssignment, UserRoleActivation, PermissionRoleAssignment, RoleHierarchy, and SoD are modeled using association classes which are transformed to normal classes following the modeling guidelines in [19, 28]. These association classes have binary relationships with STZone class to enforce the spatio-temporal constraints.

Fig. 10

UML class model for STRBAC

1.3 Effect of spatio-temporal constraints on RBAC operations

User-role assignment A user-role assignment is location and time dependent. That is, a user can be assigned to a role provided the user is in specific locations. For example, a person can be assigned the on-campus student role only when he is in the campus during the semester. This requirement is expressed using the zone concept:

• UserRoleAssignment $\subseteq$ users $\times$ roles $\times$ STZones

This relationship is depicted in the GSTRBAC class diagram as association class UserRoleAssignment. The OCL operation assignRole assigns role $r$ to user $u$ in zone $z$ if $z$ is in the set of rzones, user $u$ is present in zone $z$, and role $r$ is not already assigned to user $u$ in zone $z$. For the lack of space, we omit the descriptions of the OCL queries used in the assignRole operation.

User-role activation A user can activate a role if the role can be activated on the specific zone and it is already assigned to that user. For example, the role of doctor trainee can only be activated in a hospital during the training period. We define the UserRoleActivation relation to determine the current active roles based on zones:

• UserRoleActivation $\subseteq$ users $\times$ roles $\times$ STZones

In GSTRBAC class diagram, UserRoleActivation class is specified in a manner similar to UserRoleAssignment. The only difference is that the activateRole operation ensures that a user is already assigned to a role before the role is being activated.

Check access This operation checks whether a user is authorized to perform some operation on an object during a certain time and from a certain location. A user is allowed to fire a missile if he is assigned the role of top secret commander and he is in the controller room of the missile during a severe crisis period. Thus, a user can access an object in a certain zone if that user has activated a role which has an appropriate permission for that object in that zone.

Permission-role assignment Permissions can only be assigned to a role during specific time and locations. For example, the permission of opening a cashier drawer in a store should be only assigned to a salesman role during the day time. The assignment of permissions to roles is specified based on zones.

• PermissionRoleAssignment $\subseteq$ permissions $\times$ roles $\times$ STZones

The following OCL operation assigns permission $p$ to role $r$ in zone $z$ if $z$ is in the set of $pzones$ and $rzones$.

1.4 Spatio-temporal role hierarchy

The permission-inheritance hierarchy (I-Hierarchy) and the role-activation hierarchy (A-Hierarchy) are two variations of role hierarchy (RoleHierarchy) in RBAC [27, 41]. In our model, a senior role could have a subset of junior roles in a particular zone. The spatio-temporal role hierarchies are formally defined as follows:

• RoleHierarchy $\subseteq$ Roles $\times$ Roles $\times$ STZones

• I-Hierarchy $\subseteq$ RoleHierarchy, A-Hierarchy $\subseteq$ RoleHierarchy, and I-Hierarchy $\cap$ A-Hierarchy = $\phi$

The subtypes of RoleHierarchy are represented in the GSTRBAC class diagram by the subclasses I-Hierarchy and A-Hierarchy, which are connected to STZone class to restrict the roles associations.

Permission-inheritance hierarchy In permission-inheritance hierarchy, a senior role $r$ can only inherit junior role $r'$ permissions in zone $z$ if both roles are available in zone $z$. A project manager inherits the permissions of a developer when he is at the customer site giving a demo. The following OCL expression specifies the spatio-temporal constraint on I-Hierarchy for adding new junior role.

The delete operation of a junior role in I-Hierarchy can be defined in the similar manner. The I-Hierarchy relationship is acyclic as shown by the following OCL constraint.

The boolean operation inheritsIH(r,z) returns true if role $r$ is directly or indirectly a junior role of the context role in particular zone, otherwise it returns false.

We define the OCL query operation getAuthorizedPermissions(z) to get the authorized permissions for a given role at zone $z$ through direct assignment or indirect I-Hierarchy.

Role-activation hierarchy Restricted spatio-temporal A-Hierarchy allows members of senior roles to activate junior roles in predefined spatio-temporal zones. For example, a department chair can activate a staff role during the semester inside the department building. The OCL operations of adding and deleting junior roles to the A-Hierarchy are defined in similar manner to I-Hierarchy. Further, the acyclic constraints on A-Hierarchy is enforced in the same way of the I-Hierarchy.

The only differences are that, the OCL query operation getAHJuniorRoles(z) returns all the junior role in A-Hierarchy of the context role in particular zone. Moreover, the OCL query operation getAuthorizedRoles(z) gives the authorized activation roles for the context user that are either explicitly assigned or implicitly obtained through A-Hierarchy in certain zones.

1.5 Spatio-temporal separation of duty

The static SoD (SSoD) and dynamic SoD (DSoD) are two special classes of the SoD constraints in RBAC [17]. Further, the role SSoD (RSSoD) constraints are defined on roles assignment, while the permission SSoD (PSSoD) constraints are defined on permissions assignments.

In our model, the conflicting roles and permissions in SoD are defined over some zones. The spatio-temporal RSSoD, PSSoD, and DSoD relations are formally defined as follows:

• RSSoD $\subseteq$ Roles $\times$ Roles $\times$ STZones

• DSoD $\subseteq$ Roles $\times$ Roles $\times$ STZones, and RSSoD $\cap$ DSoD = $\phi$

• PSSoD $\subseteq$ permissions $\times$ permissions $\times$ STZones

The static and dynamic SoD relations are represented in the GSTRBAC class diagram using the associations classes RSSoD, PSSoD, and DSoD, which connect the conflicting entities with certain zones.

Role SSoD The same individual should not be assigned to specific roles in specific location for some duration. For example, the same user should not be assigned to billing clerk and account receivable clerk roles in the same time at specific trade corporation. The following OCL invariant forbids the assignment of conflicting roles in a particular zone.

However, the above constraint might be violated through role hierarchy relation. For example, a billing supervisor role might be a senior role of the two conflicting roles billing clerk and account clerk at the same time and in the same accounting department. The following OCL constraint prevents such situation.

Permissions SSoD PSSoD prevents the assignment of conflicting permissions to a role. For example, a loan officer is not permissible to issue loan request and approve it in the bank building during the day-time. The following OCL invariant expresses the PSSoD requirement in our model.

However, this constraint might be violated through I-Hierarchy in which a senior role inherits some junior roles that have been mutually assigned conflicting permissions. The following OCL invariant prevents the violation of PSSoD via I-Hierarchy.

DSoD Two conflicting activation roles cannot be activated in some spatio-temporal zones by the same user. For example, the simultaneous activation of cashier and cashier supervisor is forbidden during the working hours in the same store to deter such user from committing a fraud. The DSoD constraints are expressed in OCL invariants in a similar manner to the RSSoD constraints. The only difference is that the OCL invariants prevent the activations of conflicting roles that are connected by DSoD in some zones through either the explicit role assignment or the implicit A-Hierarchy.

1.6 Spatio-temporal prerequisite constraints

In RBAC, the prerequisite constraints obligates that some actions to be taken prior to performing an operation [16].

Prerequisite constraints on user-role assignment The prerequisite constraint on roles assignments imposes that a user must be assigned to some less critical roles in a given spatio-temporal zone before being assigned more critical roles in specific zones. For example, the role of emergency-nurse can be assigned to John in the urgent care unit from 12:00 to 5:00 am if he is assigned the role of nurse-on-night-duty at the hospital during those hours. The following OCL invariant expresses the prerequisite constraints on user-role assignment. The query operation getPreqAssRoles() returns all the assignment prerequisite roles needed for assigning a certain role.

Prerequisite constraints on permission-role assignment The prerequisite constraints on permissions assignments indicates that a role can be assigned a permission in a specific zone if some prerequisite permissions are already assigned to that role in the same zone. For example, a bank teller must have the permission of reading an account during working hours before he can be given the permission to update that account. The prerequisite constraint on permission-role assignment can be specified using OCL expression as follows.

Prerequisite user-role activation A role can be activated if some prerequisite roles are already activated in specific zones. For example, in a university the teaching assistant role can be activated during a semester in a department if the student role can be activated during the same time. This requirement is specified in our model in the same way of the prerequisite user-role assignment constraint except that the OCL query getPreqAssRoles() is substituted with getPreqActRole(). The query operation getPreqActRole() returns all activation prerequisite roles needed to activate a role.