We present a framework for enforcing the application of context-aware Role-based Access Control policies based on an Internet of Things eco-system inspired by the Google's Physical Web. In this setting we are interested in capturing three contextual dimensions, namely whowhere-when, and using these information to restrict access to shared resources. Formally, the framework consists of features types, an automatabased model of time-sensitive roles, context-aware permission rules, and an IoT infrastructure based on Eddystone Beacons for validating a policy against the current state of users.
In modern distributed systems based on the Internet of Things (IoT), security layers of software applications must be tightly integrated with the underlying system/network infrastructure. The integration is needed in order to increase the privacy of user data, to ensure availability of access control con guration services, and to integrate edge and fog components in the, possibly seamless, eco-system that governs information assurance. In particular, devices at the edges of an IoT system can be employed as active parts of location-based and time-dependent access control policies enforcement mechanisms. Furthermore, a tighter integration between the security layer and distributed infrastructures could provide better provenance on data and information ows.
According to this idea, in this paper we present a framework for
enforcing the application of geo-referenced Role Based Access Control (RBAC)
policies [
Our framework consists of features types, context-aware permission rules, and an IoT infrastructure for validating a policy against the current state of users. In this setting, we are interested in capturing three contextual dimensions, namely who-where-when, and use these information to restrict access to shared resources. Users are assigned to stateful roles. A role must be considered as a slowly changing condition of users, whereas a state represents time-dependent a behavior associated with a speci c role (e.g. typically a faculty member can act as instructor, mentor, course attendee, etc). Similarly, locations have timedependent states that capture possible di erent usages of the same physical space (e.g. a room can be used for meetings, seminars, courses, etc). Our time model is based on deterministic nite-state automata inspired by logical speci cation languages for the linear time ow. Access control rules are de ned on top of role and location states. Therefore, they can be used to de ne complex (i.e. automata-based) time-dependent access policies.
We illustrate the main ideas underlying the speci cation language of contextaware control access policies using an example. Consider a campus which physical spaces are organized in buildings, oors, and rooms. A room may have several usages, e.g., meeting room, seminar room, lecture room. The usage depends on a prede ned time schedule. The same room can have di erent usages in di erent time slots. Users can assume di erent roles, e.g., student, teacher, mentor. Furthermore, users perform actions like consulting and updating records related to attendance at a given lecture, nding information on teachers, retrieving statistics, etc. Permission rules formalize access control policies to public and private data. Permissions are context-aware in that access to speci c data can be constrained by the physical location of the user. Permission rules have to specify properties such as: a student can update its attendance record only when she/he gets access to the system from a classroom, teachers can get statistics on student attendance anywhere, students can get information of teacher presence anywhere in the department building, etc. This scenario can be nicely formalized by introducing a time-dependent stateful model for roles and locations. The timed model is based on a linear ow of time represented as an automata with a total transition function (i.e., automata that have a lasso shape). Roles and locations have an associated labeling function dependent of time that determines the dynamics in each role specialization and in the usage of physical spaces. Validation is de ned against permission rules associated to user operations by considering a notion of state based on the current user location and the system time.
The main novelty of our proposal w.r.t. classical approaches like GeoRBAC
[
A prototype of the system is currently under evaluation in our University with the aim of providing an automated support for the management of typical Academic Campus services like registration of attendance to lectures and meetings, rooms and lectures allocations, etc. Speci cally, lecture attendance is often a problem for the performance of academic degrees (especially bachelor). Intermediate tests are often used as a way to encourage students to actively attend lectures and take exams. The platform provides (physical) web services and mobile applications for the registration and analysis of lecture/meeting attendance. Beacons are used to detect, in almost real-time, the presence of a student in a lecture room. Our speci cation language can then be used to formally con gure access control to private data ensuring that users can modify their own record only when they are physically present in a given room authenticated in the system with their own smartphones. Furthermore, the same architecture can be applied in every scenario that requires a veri ed list of attendees, for example in the case of meetings in which it is mandatory to generate on-the- y reports or collect results of several voting during the same meeting.
A prototype of the system has been developed using the Node.js serverside technology and Android for dedicated mobile app interfaces. The internal structure of Node.js allows the system to handle a large number of connections in a short period of time reducing potential risks of denial of service failures and attacks. Furthermore, Android OS provides natively support for beacons, for secure network connectivity, and for protecting device resources. In our system private data are exposed to the server only after obtaining permissions from the users. The system has been tested in a real scenario in the Database course of the Computer Science Bachelor degree at the University of Genova (more than 120 students).
In the paper, we present the speci cation language, the validation mechanism, system requirements, design principles, and implementation choices of the proposed architecture. The remainder of the paper is organized as follows. Sections 2 and 3 specify the model, in terms of policy speci cation language and enforcement. Section 4 focuses on infrastructure and system requirements. Section 5 discusses software related issues (architecture, data model, and prototype solutions) while Section 6 concludes. 2
Based on models for georeferenced and temporal access control languages [
Linear Time Model In this paper we consider a linear time model de ned via a nite automata AT = hP; succi, such that P is a nite set of time points and succ : P ! P is a total function that de nes the successor succ(p) of any point p 2 P . In other words, AT is an automata that can only consist of an initial nite su x entering into a nite and simple loop. The automata AT will be used to model di erent time granularities, e.g., possibly repeated time/days slots during a week, months, etc.
Roles We de ne roles using feature types, i.e., a partially ordered set of entities. More speci cally, the set of roles is de ned by a nite set Role equipped with a binary relation v such that hRole; vi forms a lattice, i.e., Role has top and bottom element, and every subset of elements in Role admits a least upper bound and a greatest lower bound. The v relation can be viewed as a hierarchy relation (specialization) that can be used to build role hierarchies. For instance, bachelorstudent v student Every role r 2 Role comes with a nite set of possible states Stater and a labeling function r : P ! Stater that associates a given state to every time point. The labeling function must be compatible with v in that if R1 v R2 the R1 inherits all permits of R2. In our model permits are associated with states, thus compatibility requires that if R1 v R2, then StateR2 StateR1 , i.e., state containment is contravariant w.r.t. role specialization.
Locations The set of physical spaces Location is a nite set equipped with a binary relation v such that hLocation; vi forms a lattice. Every l 2 Location comes with a nite set of possible states Statel and a labeling function l : P ! Statel that associates a given state with every time point. Similarly to roles, the location labeling function must be compatible with the hierarchy relation, i.e., if L1 v L2, then StateL2 StateL1 , i.e., state containment is contravariant w.r.t. location speci city (i.e. speci c users may have enlarged permissions in xed locations inside a building).
Operations Operations are de ned by a nite set of labels Ops. Example 1. As an example, consider a linear time automata AT with states f0; 1; 2; 3; 4g s.t. succ(i) = i + 1 mod 5 s.t. 1 = M on, 2 = T ue, etc. Now let us consider the set
Role = fStudent; T eacherg Statestudent = fAttendant; M entorg
Stateteacher = fT eacherg where we omit top and bottom elements for simplicity. We assume here that users can be either students or teachers that access with two types of resources. Now we assume that Student(i) = Attendant for i 2 f0; : : : ; 3g, and Student(4) = M entor. Furthermore,
Location = fBuilding; F loor; Room1; Room2g s.t. Room v F loor v Building,
StateRoom1 = StateRoom2 = fM eeting; Course; F loor; Buildingg StateF loor = fF loor; Buildingg
StateBuilding = fBuildingg where we omit top and bottom elements for simplicity. Furthermore, Room1(i) = Course for i 2 f0; : : : ; 3g, and Room1(4) = M eeting, Room2(i) = M eeting for i 2 f0; : : : ; 4g.
Finally, we consider the following set of operations
Ops = fGetRecord; U pdateRecord; F indT eacher; GetStatisticsg The get/update record actions correspond to read/write operations on database containing student activity reports, such as course attendance data, mentoring activities, etc, that require certi ed time accountability, e.g., courses in which attendance is mandatory for a given percentage of hours. FindTeacher allows users to check for the presence of a teacher during speci c time window and in speci c locations. GetStatistics corresponds to read operations on aggregate data such as course attendance. 3
Based on the previous sections, we are now ready to introduce our notion of permissions in order to de ne context-aware access control rules. De nition 1 (Permission). A permission rule is a tuple
p = hOp; RoleState; LocationStatei where Op 2 Ops, RoleState is a role state in Sr2Role Stater, and LocationState is in Sl2Location Statel.
To clarify the meaning of permission rules, we need to introduce users, sessions, and then a validation mechanism.
Let Id be a denumerable set of user identi ers. Every user has an associated labeling function session that associates to the user an instance role. Permissions are then de ned by rules associated to role and location states. More precisely, we introduce a notion of current state of a user via a state function de ned as follows. For u 2 Id, state(u; t) = loc, where we assume that loc is an instance of Locations.
De nition 2 (Validation of an operation). User u can perform operation Op at time t if and only if there exists a permission rule p = hOp; RS; LSi s.t. { state(u; t) = loc, { session(u) = role, { for every R 2 Role s.t. role 2 R we have that R(t) = RS { for every L 2 Location s.t. loc 2 L we have that L(t) = LS. Example 2. We list below some examples of permissions.
{ p1 = hU pdateRecord; Attendant; Coursei s.t. students can update their attendance records from the room of a course only. { p2 = hU pdateRecord; M entor; M eetingi s.t. mentors can update their mentor accounting records from a meeting room only. { p3 = hGetStatistics; T eacher; Buildingi: teachers can consult the student records anywhere in a building. { p4 = hF indT eacher; M entor; Buildingi: only mentors are allowed to use the service to locate a teacher in a building. 4
A prototype of the context-aware access control validation mechanism has been implemented using a IoT infrastructure based on the combination of beacons, wi- network technology, mobile, web, and database management components a typical scenario of the Physical Web paradigm proposed by Google. Our operative scenario is a typical example of an Academic Campus and we assume that each classroom is equipped with at least one beacon con gured with a unique identi er consisting of three sub elds called UUID, MajorID, and MinorID. In our experimental setup we adopted Estimote beacons. For lecture rooms for at most 180 students a x beacon turned out to be su cient to detect all enabled smartphones. We also assume that rooms of sta members are equipped with beacons to inform students of their presences in the building and o ce-hour updates. Finally, we assume that each room provides wi- access to students, e.g., via Eduroam (https://www.eduroam.org/) access points. A (Web) server must be installed either on an external cloud provider or on a local server. In both cases it must be reachable from the local network, i.e., the rewall con guration must provide access to Web APIs needed by the smartphone and Web applications.
The platform is based on a combination of hardware and software solutions that must be deployed in physical spaces like lecture and meeting rooms in an academic campus. The infrastructure and system requirements can be summarized as follows. 1. The system should provide precise indoor localization of users via their smartphones. The required precision must be in the order of a few tens of meters (i.e., to cover a lecture room). 2. Registration of user presence must be done in real-time. The server must be reachable from every lecture room. 3. Rooms must be viewed as geofences. Only users inside a given room should be able to update data with georeferenced permissions. 4. The system should be resistant to server failures, e.g., by using multiple server instances on di erent machines. 5. Logged data must be stored persistently in a data storage system. Data storage must be accessible to the application and administrators, only. 6. Users must be informed that the server makes use of localization data. 7. Users must give their permission for releasing data stored in the device (IMEI). 8. Data stored in the server should not be released to third parties. 9. Users must be uniquely identi ed via o cial credentials such as the matriculation (sta ) number assigned by the central administration. 10. User devices must be identi ed uniquely using IMEIs. Every user must associate a unique device (IMEI) to the corresponding personal identi er. 11. Data exchanged with the users must be encrypted and sent on secure channels. 12. To limit the budget, hardware and software infrastructures must be composed by low cost devices, standard networking services provided in academic environments (e.g. server on virtual machines), open-source software and development frameworks for server-side and mobile applications. To meet all the above requirements, we need to satisfy constraints both at the physical level (infrastructure and hardware) and at the software level (networking and platform). 5
The software platform consists of an app with di erent views depending from the current user (e.g., students, teacher, administrator), a Web application, and a persistency server as described in the next sections. The server provides secure APIs (secure TCP) for accepting user requests and for sending noti cations. Persistent data are stored in a MySQL server accessible only from the server. The Web application allows sta members to create and modify user pro les, visualize historical data and statistics for both classrooms and individual students. Although responsive, this functionality must be viewed as an access point designed for a traditional (non mobile) browser. Role and Location are modeled using relational schemes. The state machines that de nes RoleStates and LocationStates is stored as a relation containing a key for the time points, and states for each role instance. Thus validation of user state can be reduced to a query in the record associated to the current time point. Machine time is mapped to virtual time used in the access control speci cation by using a mapping function that is selected by the administrator. The mapping models the granularity of the considered time model (e.g, it extracts current day and hour from machine time or sim.). This provides an alignment between machine time and automata time used in the enforcement step.
As an example, assume that Alice Smith is enrolled in the rst year of a Computer Science Bachelor degree. Alice has student ID 3471890 and the association between her identi er and the IMEI of her smartphone (and of other two students) is shown in Table 1. The association between beacons identi ers and rooms is shown in Table 3. According the permission rule p1 = hU pdateRecord; Attendant; Coursei and p2 = hU pdateRecord; M entor; M eetingi attendance and tutoring hours registration for Alice Smith is synchronized in accordance to the data in Table 2 and Table 3 and the current location of Alice and time. Timing is based on the server time in order to avoid manipulation of timestamps sent with user requests. Registration in all other cases (di erent location, times) is forbidden.
The middleware underlying the platform has been implemented combining di erent technologies. The server has been implemented using the Node.js IoT framework, an e cient server-side development framework based on Javascript and on the npm eco-system. Node.js provides very e cient packages for handling secure TCP connections, Web servers, and applications. Node.js server-side libraries are optimized for network intensive applications even when executed on single host or cluster. Indeed, Node.js allows to handle a large number of connections in a short period of time reducing potential risks of denial of service (this is very useful in our context since the system has to handle hundreds of requests in a few minutes). This property is due to the internal structure of the Node.js event-driven engine. Requests are not handled using multiple threads as in the Apache server model since the Node.js engine is based on an event loop that executes callbacks sequentially. Callbacks are picked from multiple priorities FIFO queues. Furthermore, thread pool implemented using the C++ libuv concurrency library supports the execution of asynchronous callbacks. Di erently from server architectures based on multiple threads, in Node.js the response to connection requests require few system resources since they basically require the emission of events whose synchronous e ect is that of enqueuing callback invocations in the I/O queue. This choice mitigates the risk of classical denial of service attacks based on a high number of simultaneous requests that could congest the server by exhausting system resources (e.g., creation of new threads to scale up the server).
The prototypes of the mobile applications have been developed in the Android OS. Android OS provides native support for beacons (e.g., using OS noti cation management or beacon SDKs like Estimote SDK). It also provides secure network connections and access control policy management that protects private data. Private data are exposed to the server only after obtaining permissions from the owner. The authentication mechanism built on top of associations between user and device identi er relies on secure network connections (secure TCP sockets) between the smartphone application and the server. A smartphone app, con gured to detect beacons using libraries like the Estimote SDK, is provided in two di erent versions: students and teachers. The student app provides sign-up, sign-in, and sign-out and a wide range of functionalities. The sign-up service associates the smartphone IMEI to the unique student enrollment number and to his contact details. After the rst user registration, sign-in is automatically enabled whenever the app is activated by the user. Indeed, the server can retrieve the IMEI of the smartphone from the initial connection request issued by the app. Thus, the silent authentication stage is based on the association between the user identi er and the registered IMEI. Upon authentication, students can register their attendance to a given lecture in a given time-slot. The lectures schedule of each student is indeed synchronized, server-side, with the lectures and rooms allocations plan, for each enrollment year. Thanks to this synchronization, attendance is enabled only in speci c time-slots and in physical spaces. In addition the app provides user interfaces for visualizing the historical data stored in the persistence server (pro le, attendance log) and interfaces to visualize, via a calendar widget, lecture plans (according to the corresponding study plan), seminars, and other events registered by sta members.
Using protocols similar to those adopted for the student view, the teacher app provides a user interface for visualizing statistics on students attendance, lectures and events calendar. The aggregated number of presences provides indications for each course trend: it is indeed possible to understand if the number of students attending at the beginning of the course decreases signi cantly or remains stable during the semester. It is also possible to check if there are days or time-slots with a signi cant decrease in attendance and consequently try to implement strategies to avoid such drop out. The app also provides a control widget for the noti cation of presence in o ce-hours. Sta members can create, modify, and delete events that will be noti ed to users and visualized in their calendar view. Furthermore, they can access the room allocation service that is moderated by a dedicated administrator. 6
The Google's Physical Web project { center stage at the Google IO developer
conference in 2016{ was conceived to enable smartphone users to interact with
physical objects and locations through the use of beacon technology. The Google
Physical Web architecture has been supported with physical devices such as
Estimote beacons and client API's. Beacons are low cost radio transmitters that
typically transmit a unique ID on a regular interval, e.g. 100-1000ms, in a range
of approximatively 30 meters. Bluetooth-enabled devices can detect a beacon and
receive its corresponding identi er, following the so-called lighthouse metaphor.
Smartphone applications can use such ID to signal their physical presence in the
beacon vicinity to a remote server and the limited transmission range of these
transmitters provides precise users localization. The typical application domain
of physical web is that of proximity marketing [
Acknowledgments The authors would like to thank Claudio Orlando for his contribution to the prototype implementation.