Secure and dynamic access control for the Internet of Things (IoT) based traffic system

State of the art

To the best of the authors’ knowledge, there is no availability of a secure and dynamic access control model for IoT-based traffic systems to secure and dynamically handling data sharing and communication. More specifically, it is necessary for secret and vital information communication and sharing to be done through some secure and dynamic system. In this context, access control can be implemented efficiently. In the related literature, the proposed models are not dynamic for IoT-based traffic systems. A secure access control model has been recently proposed, but it provides security officials’ secure communication while traveling in vehicles. The model is implemented on permissions rather than roles, for the internet of connected vehicles (Habib et al., 2019). Moreover, other security and privacy issues and violations relating to the internet of vehicles, have been addressed. Mainly, the focus of research is more on the location privacy of mobile users (Joy & Gerla, 2017).

A distributed traffic control system has been proposed in recent years that work without traffic signals. The system is implemented with the concept of the internet of agents and discussed briefly with a case study. In this system, the connected vehicles can communicate with each other so that the traffic flow becomes smoother as compared to an existing system (Bui & Jung, 2018). Also, different case studies exist related to security and privacy threats in IoT-based devices and systems (Yaqoob et al., 2017). Besides, several design-level challenges have been highlighted for vehicular communications by using the 5G building blocks (Shah et al., 2018). In this connection, a framework has been proposed by researchers to avoid the messages of malicious vehicles. That framework allows only authorized vehicles to communicate and pass messages related to traffic events (Tian et al., 2019).

Researchers have also recommended numerous concepts for improving ABAC (Aftab et al., 2019; Zhang, Zheng & Deng, 2018), such as inserting the idea of roles in the ABAC model so that the number of attributes can be managed efficiently. For the RBAC model, role is of great importance, manually assigned to operators in the archetypal RBAC concept. Mostly, researchers have recommended a concept that routinely assigned operators to roles by employing their features. For instance, operators have specific attributes like location, name, and age. All the operators would be routinely apportioned to their quantified tasks regarding their features, like operators of age 16–20 years can be allotted to their distinct task; this could be referred to as role 1. Those aged 21–25 can be assigned role 2, while the remaining operators of age more than 25 years to be assigned Role 3 (Al-Kahtani & Sandhu, 2002).

There are specific methods that combine ABAC and RBAC because RBAC is stress-free to run and offers significant scrutiny of go-ahead; however, its role structuring is problematic. Additionally, ABAC gives efficient task structuring, but the breakdown of authorizations after allotting to users is hard-hitting as opposite to RBAC. Alternatively, there is a different approach for the union of RBAC and ABAC that resolves the drawbacks of two concepts and offers a further vigorous, active, significantly better role structuring as well as the scrutiny of permission for the administrator (Kuhn, Coyne & Weil, 2010). Another fine-grained access control model has been recently introduced by merging RBAC and ABAC entities so that flexibility, fine granularity, and efficiency can be achieved (Qi, Di & Li, 2018). However, these models are not designed for IoT-based systems.

An access control model for IoT-based healthcare and medical devices also exists that prevents unauthorized access. In this system, only authorized users can access the system after verification through security access tokens (SAT). SAT is proof of an authorized user, as well as, SAT is cryptographically protected (Hossain et al., 2018). A secure and efficient access control scheme is designed for the internet of medical things–primarily based on fog/cloud computing. It is capable of providing high-level security with a short execution time, for the information stored on the cloud (Wang et al., 2018). The integration of cloud computing and IoT has many security issues and challenges that are discussed in the IoT and cloud computing survey (Stergiou et al., 2018). Furthermore, various researchers working on the security and privacy of database-as-a-service, cloud-based secure services, and blockchain, along with the legitimate user recognition, challenges, and performance analysis (Khan et al., 2020; Khan et al., 2019; Ahmad et al., 2018).

SDAC model

Due to both the models’ weaknesses and limitations, the merger of RBAC and ABAC is favored. The SDAC model is an efficient solution in the form of a hybrid model that covers flaws significantly. This model aids in resolving the problems of RBAC (ANSI/INCITS, 2004) and ABAC (Hu et al., 2015) standards, discussed in the earlier section. An administrator usually creates several permissions for the users in an organization so that implementation of the access control is fulfilled in a significant manner. Normally, the administrator creates permissions manually and one by one. This is a time-consuming and challenging job. Under this model, authorization (permissions) are automatically generated by joining the action-level and the object-containers. Authorization is generated when action and object are joined together. The concept encompasses diverse security heights, and each one of them includes certain quantified whereabouts. For level 1, it contains approve, write, print, and delete actions. For level 2, includes writing, edit, and read actions. Then, level 3 has submitted and execute actions only.

These action-levels have been prearranged along with the organizational structure. The overseer could generate additional action-levels if required. Likewise, object ampules have been shaped for the storing of objects. Several ampules could be molded for the storage of objects. Objects are usually allotted to containers concerning the category of the object. In a situation where these objects are apportioned to ampules, then the object-container would relate on an action-level. This procedure routinely produces several authorizations. According to Fig. 2, when an administrator applies action-level two on object-container 1, 12 permissions will be created at once. In this way, an administrator can create multiple permissions at a time. On the other side, the administrator has to create permissions one by one, in the traditional RBAC model. Furthermore, an IoT-based wireless sensor network can be deployed along roadside to monitor and control traffic, as discussed in (Masek et al., 2016).

The network model for sensors inter-operability can be either based on machine to machine communication (M2M) or wireless sensor network based on LoRa (low-power wide-area network technology). The IoT sensing devices can help to provide real-time traffic control along with roadside parking management solutions. There are some limitations in the deployment of these IoT sensors devices along roadside. However, there is a big challenge of providing a secure, fast, and reliable access control mechanism for the secure and reliable operation of these IoT sensors. Therefore, we propose a novel and dynamic access control model that can provide significantly better security for traffic control systems.

Figure 3 illustrates that if the security of the TSS compromises, then a big traffic jam can happen in the presence of sensitive vehicles. The users travelling in the red cars and sensitive vehicles are highlighted with maroon color. After attacking the system, cyberpunks successfully created a deadlock so that the government or military officials may be trapped in a traffic jam, especially when they are travelling in the same fleet. In this manner, the criminal elements can easily attack or capture their target. Therefore, this is necessary that the TSS must be secure enough so that the system is not compromised for any reason; particularly during the movement of sensitive automobiles. In the SDAC model, whenever permissions are required to create, action-levels and object-containers are combined for multiple authorization creation. The base of the model is based on the basic entities of RBAC model like object, actions, roles, and users. In this manner, the model security remains tight enough. The assignment of permissions to roles and roles to users is based on attributes so that the model can behave dynamically.

Formal specification of proposed model

The ALLOY is regarded as an adequate lightweight modeling framework for checking RBAC’s internal accuracy and certain algebraic properties. The conflict-free RBAC was defined using the language ALLOY. The model’s formal specification is as follows.

• ALL_USERS, ALL_ROLES, NET_PERMS, NET_OPRS, and NET_OBJS (all authorized users from every group, all roles, total number of permissions, net number of actions (operations), and net number of objects from every category, respectively).

• USATT, ROATT, PRATT, OPATT, and OBATT denote finite sets of attributes of users, roles, permissions, operations, and objects, respectively.

• OB_CONT and OP_LEV denote object containers for the storage of objects and action level for storing the operations, respectively.

• U_AS ⊆ ALL_USERS × ALL_ROLES: This denotes authorized users to roles assignment with a many to many relationships.

• USER_AS_ROLE: (r : ALL_ROLES) → 2ALL_USERS, the mapping of role r from the set of roles, onto a set of users. This shows roles will be assigned to various users according to the access policy, so that the authorized users can perform their tasks. Besides, the users can only perform those tasks and access those permissions that are assigned to them through roles.

• ASSIGN_USER(r) = {u ∈ ALL_USERS | (u,r) ∈ U_AS}

• P_AS ⊆ NET_PERMS × ALL_ROLES: This shows many-to-many relationships of permission to roles assignment.

• ASSIGN_PERMISSION (r : ALL_ROLES) → 2NET_PERMS, mapping of role r from the set of roles, onto a set of permissions. This shows that permissions are assigned to different roles. In this way, different roles will be designed and assigned to users for fulfilling the organizational tasks.

• ASSIGN_PERMISSION(r) = {p ∈ NET_PERMS | (p, r) ∈ P_AS}

• NET_PERMS = 2(OB_CONT × OP_LEV), this denotes the set of net permissions.

• AUTO_AS_PERMS (atri_r : ALL_ROLES) → 2NET_PERMS, it shows the automatic mapping and assignment of attributed-permissions onto attributed-role atri_r by using attributes. Previously, the administrator used to assign permissions to roles and roles to users, but this model automatically assigns permissions to roles and roles to users by using various attributes.

• AUTO_AS_PERMS (atri_r) = {atri_p ∈ NET_PERMS | (atri_p, atri_r) ∈ P_AS}

• AUTO_AS_ROLES (atri_u : ALL_USERS) → 2ALL_ROLES, it denotes the automatic mapping and assignment of attributed users onto a set of attributed roles atri_r by using attributes.

• AUTO_AS_ROLE (atri_u) = {atri_r ∈ ALL_ROLES | (atri_r, atri_u) ∈ P_AS}

• OP (OP_LV1:OP_LEV) → {OP ⊆ NET_OPRS}, it denotes the mapping of operations onto action-level OP_LV1.

• OB (OB_CT1:OB_CONT) → {OB ⊆ NET_OBJS}, it denotes the mapping of objects onto the object-containers OB_CT1.

Example scenarios

In this subsection, we have elaborated on two different example-based scenarios so that the concept of this work can be easily provided.

Learning management system

The first case study has been taken from the scenario of an education department using a learning management system (LMS). Through the use of LMS, teachers are privileged with giving online quizzes, assignments, providing study materials, and taking attendance. On the other hand, students depend upon teachers and teachers to control the activities and authority of students in the LMS. In conclusion, LMS distinguishes teachers’ and students’ rights as different. For example, providing the authority to teachers so that they can create different educational documents for students; such as slides, pdf, word document, and other study materials. On the condition that a teacher wants to assign a file (like a.pdf) to all students, the teacher is granted the right to access all groups of students or a single student. Additionally, the teacher gets the advantages of defining the authority of each level of student to the file or files uploaded. This shows that the two roles are involved in this action, and the roles are student and teacher.

A teacher can upload files such as slides, quizzes, and results. Moreover, the teacher can also modify files like editing quizzes, deleting the assignment, or replacing files. On the other hand, student’s permissions are: to download the study material, upload assignments, solve online quizzes, and check their marks from anyplace. The students and teachers can only access the resources only after logging into the system so that their identity and authority level can be verified. This way, the educational files are uploaded with the attribute ‘username’, for students to easily access the data from inside and outside of college or university. In the meantime, of attendance and quizzes, files are composed of the attributes ‘IP-address’, ‘date’, and ‘time’. This allows a student to mark attendance only when in class, on a particular date and time.

The availability of exam files is only specific to scholars that are verified in the college or university system, which can all be confirmed from an IP range. Now, consider the situation from the initial point of the SDAC model (objects and actions creation). The teachers add PowerPoint slides, course files, books.pdf, and they are asked to assign attributes value over the files. As the educational-materials are bound for all students, therefore it can be opened, edited, read, and downloaded from the scholars’ side. These records are further added to different object-containers. On the other hand, different actions are facilitated with various attributes. Then actions are assigned to different action-levels. Now, the action-levels are applied to the object-containers for the automatic formation of customized permissions. The example of objects with different attributes, object-containers, action with different attributes, and action-levels is given in Table 1, for better understanding.

When Container1 is combined with Level1 then three different permissions are formed. The attributes of objects and actions are also transferred in the newly created permissions. In the next step, Container2 is employed to Level2 which creates three attributed-permissions at once. After this creation, Container3 is applied on Level3 that creates nine attributed-permissions in the result. Container 3 has three attributed-objects and Level3 also has three attributed-actions. In this way, nine (3 × 3 = 9) permissions are created. Container1 consists of one object ‘File1.txt’ and the users can access this object from the given locations only. Moreover, users can perform actions read, write and edit on this object only within the given time domain and authorized usernames. In this way, these permissions are stricter as compared to the previous model permissions. On the other hand, Container2 object is also accessible from the verified location attribute as well as the actions read, download, and delete can only be performed when the attributes username and date are fulfilled.

In the final permission creation process, there are three different objects in Container3. File3.ppt can be accessible from the given location attribute. File4.doc and File5.xlsx are accessible with the given time and date. In addition, the users can perform actions delete, write, and submit on Container 3's objects, but the location and designation of the users should be correct. As the permissions are attributed and roles are also facilitated with different attributes so the permissions are assigned to roles by matching their attributes. An example is given in Table 2 for a clear understanding. Permissions prms1 to prms9 are allocated dynamically to Role1 as they have attribute, i.e., location. Permissions prms10 to prms15, therefore, get to be allocated to Role2, as they have the same attribute and attribute value, i.e., date and time. Likewise, system allocates Role1 to users’ User1 to User7’, as their attribute values are matched. In addition, Role2 is assigned to users’ User8 to User15’ with the help of their attributes.

Traffic control system

The second case study has been taken from the scenario of a traffic control system (TCS) using IoT-based traffic signals. Through the use of TCS, users are privileged with setting the timing for various signals, block some roads for security/emergency reasons, setting green lights for a complete route for military/government officials, and monitoring TCS. On the other hand, administrator can set the access rights for various users for controlling the activities. Resultantly, TCS distinguishes administrators and end-users rights as different. The end-users need so that they can control and deal with different activities for TCS; such as, set Timers, block a route, open a route, and other related activities. For this purpose, the administrator assigns various access rights to the users, like some users, can set timers for various routes, some users can block/open some routes for the safety measures of sensitive vehicles, and some users can approve the timing as well as blocking/opening of routes.

The administrator will set different rights for different users according to their ranks and security levels. Only the authorized users can access the system that means the users will access the system after providing their credentials. The administrator assigns the authority to users User1 to User6 for setting the timers for TCS, User7 to User10 for blocking/opening the routes, and User11 to User15, to approve/monitor all the tasks. In this way, the user tasks, as well as the approval and monitoring tasks dealing with other users, will tighten the security. In addition, the administrator can control the violation of segregation problems up to some extent. A complete view of the objects, actions, permissions, roles, users, and their particular attributes provided in Table 3. Here, the understanding of the users' access rights with detail can be achieved.

Benefits

SDAC model inherits the features of basic RBAC entities like objects, actions, permissions, roles, and users. Due to these entities, this model is secure and it implements the concept of least privilege (LP) in the SDAC model. Usually, the RBAC model facilitates the organization with LP, but the proposed model is more suitable for LP as it further decreases the access rights of the users. For instance, if a user wants to obtain access to some specified resources then, in RBAC system, all the necessary permissions are assigned to him/her permanently, or we can say that the user can access those permissions all the time. On the other hand, SDAC model is implemented with attributes like date, IP address, time, and username, etc. Therefore, a user can only access the permissions by fulfilling the implemented attributes. For example, if a user has permissions on a resource and the date attribute is set for these granted permissions. The user can only access the permissions on the assigned dates; however, in a typical RBAC model, the user can access the permissions all the time. Therefore, for security concerns, the proposed model serves effectively than the typical RBAC and ABAC models.

The SDAC model is dynamic because of the addition of attributes. Commonly, in the RBAC model, all the tasks are performed manually by the administrator. If any change is needed, the administrator is troubled again since administrator has to work over it once more. This model decreases the burden of the administrator because after creating the objects and actions, the administrator can create number of permissions with a single click. The attributed permissions are automatically assigned to roles and roles are assigned to users on the basis of roles and user attributes. Dealing with the changes in the access control system is another vital issue to be discussed. If the administrator wants to change the access rights of users towards roles, the administrator simply has to change the attributes of the roles. All the users automatically achieve access to the roles according to the new attributes values or unique attributes–reducing the workload of administrator.

Limitations

Even though the proposed model is comparatively effective than the typical RBAC or ABAC models, there are some limitations that can be considered. Firstly, SDAC model is facilitating the permissions to roles assignment on the basis of attributes. This model is not covering the conflicted permissions and conflicted roles feature. This is a limitation regarding conflict of interest because a user can hold both conflicted permissions and there is no restriction for this necessary parameter of access control. The second limitation is that the administrator has to spend more time on the object and action creation stage, as compared to the typical RBAC model. Thirdly, the permissions are assigned to roles on the basis of various attributes. However, permissions are assigned permanently.

In the ABAC system, the whole model is dynamic, so this model is not facilitating the change on the permissions’ end, as if administrator wants to delete permissions from a role or assign them to another role then administrator has to work from the start. The administrator deletes the permissions manually and again generates the permissions with the new attributes so that the newly generated permissions can be assigned to new roles. Such limitations in the proposed model are implied because model must respond to all kinds of changes on the basis of attributes. But, this model is not facilitating the permissions to roles end. However, the authors aim to address these limitations in future work.

Software/environment

• Operating System: Windows 10 64 bit Version 1903 (build 18362.719)

• IDE: Netbeans IDE 8.2

• Java Development Kit: 1.8.0_111

• Database Management System: Microsoft SQL Server 2017 (RTM) - 14.0.1000.169 (X64)

• Java Database Connectivity Driver: Microsoft JDBC Driver 6.2 for SQL Server

Hardware

• Processor: Intel® Core i5 9300H

• Memory: 12288 MB of RAM

• Hardisk: Samsung 256 GB PCI EXPRESS Solid State Drives

• Chipset: Intel® 300 Series

The SDAC model for the IoT-based TSS allows the administrators or authorities to efficiently implement access control by creating multiple permissions at the same time. On the contrary, typical RBAC will enable administrators to create permissions one by one. The results are presented in Fig. 9A and compared with the RBAC model. In Fig. 9A, it is observed that the SDAC model is creating more permissions in every attempt of permission creation. The administrator successfully created multiple permissions in SDAC model (in orange colour bars). In the first attempt, three permissions are created with the merger of object containers and action levels (3 objects × 1 action = 3 permissions). In addition, the second attempt has four permissions that are created by applying object container (2 objects) with action level (2 actions). Furthermore, two permissions are created by applying object container (2 objects) with action level (1 action). Moreover, eight permissions are created by merging object container (4 objects) with action level (2 actions). In comparison, the administrator has created permission one by one in a typical RBAC model (in blue colour bars). In this manner, the administrator can create more permissions through this model as compared to the standard RBAC model.

The results are compiled on the basis of the simulated application and proposed model working criteria. The reason behind more permission creation in our more model is the applying of the object containers with various action levels. In this way, the administrator may build several permissions at the same time. The screenshots of the developed system are also shown in Figs. 8A and 8B. On the other hand, the analysis of the proposed SDAC model has also improved performance concerning memory consumption, role assignment, and permission assignment time. The memory consumption of each entity is provided in Fig. 9B.

Each entity is highlighted with different colors such as role (sky blue bar), permission (brown bar), action (grey bar), object (yellow bar), and user memory consumption (dark blue bar). In addition, the variable processing time is calculated against each permission assignment time and given in Fig. 9C. Moreover, the permission assignment time is compared with other similar models such as permission-based dynamic RBAC (PDRBAC) (Aftab et al., 2019) and hybrid access control model (HAC) (Aftab et al., 2020). The variable permission assignment time of PDRBAC (blue bars) is comparatively better than the HAC model (brown bars). On the other hand, our proposed SDAC model (grey bars) performed significantly better as compared to previously proposed models. Furthermore, the variable role assignment time is also calculated against more than one role. The number of roles and their assignment time can be viewed from Fig. 9D. The role assignment time of PDRBAC (blue bars) is comparatively less than the HAC model (brown bars). On the contrary, SDAC (grey bars) performs well and assigns roles while taking less time, as compared to previous models (PDRBAC and HAC).