User behaviour App Locker Architecture 77 

In the following background section a brief introduction to the Android architecture is presented. Then, the subsequent sections describe the User behaviour App Locker architecture and flowchart design.

4.7.2.1 Android System Architecture

Figure 26 shows the Android architecture (left). Android uses a Linux kernel as hardware abstraction layer for the management of memory, resources, processes, network stack, security, etc. The native libraries are compiled and preinstalled by the vendor according to specific hardware abstractions required. Native libraries include media codecs, graphics, databases, surface manager, and others.

78

Figure 26 Android Architecture

Applications do not make calls directly to the Linux kernel, but instead they use the (android virtual machine) Dalvik which sits on top of the kernel. The android runtime environment consists of the Dalvik Virtual Machine (DVM) and a set of core java libraries. Dalvik is a Java Virtual Machine optimised for low memory usage and allows multiple virtual machine (VM) instances to be run at the same time. The application frameworks layer provides the high level building blocks to create powerful applications. Application frameworks include: activity manager, content providers, location manager, resource manager, notification manager, etc. The top layer is the applications layer and consists of all installed end-user applications, e.g. phone, contacts, web browser, “user behaviour application-locker”, etc.

4.7.2.1.1 Application security sandboxing 

Each application installed in Android lives in its own security sandbox. The Android architecture features a multi-user Linux system in which each application is a different user. By default, the system assigns each application a unique Linux user ID. When an application is launched it runs in its own instance of a DVM and each DVM runs in its own Linux process. This is depicted in Figure 26 (right). This security architecture provides application isolation and allows Android to enforce inter-application security constraints. Applications must request specific permissions to access device resources such as files, network, directories, and APIs in general. Also, an application cannot access the data and/or source code of another application living in a different Linux process (unless the latter provides the corresponding permissions).

4.7.2.2 User behaviour App Locker Architecture

Figure 27 describes the system architecture for the application User behaviour App Locker. In this section the system components are described.

79 4.7.2.2.1 Launch Service Detector 

This component runs as a thread. It obtains the current runtime environment and accesses, reads and monitors the device’s logging system in order to detect when an application or data file is about to be launched. This component informs the Event Handler component.

4.7.2.2.2 Event Handler 

This component checks whether the application or data file being launched contains an associated (sticky) policy. If it does the Event Handler performs the following steps:

 Requests from the Blocking Interface to block the launch and requests the ID (i.e. username) of the user attempting the action.

 Upon receiving the ID of the user requesting access, the Event Handler makes a policy evaluation request to the Policy Manager including the user ID and the name of the application (to be launched). The Event Handler waits for the evaluation.

 Once the evaluation decision (allow/deny) is returned from the Policy Manager, the Event Handler requests from the Blocking Interface to allow or deny access to the user accordingly. In the case of data files, the Event Handler encrypts/decrypts files via the OTFE (On-the-fly Encryption) module.

4.7.2.2.3 Blocking Interface 

From a Model-View-Controller architectural perspective, this component acts to some extent as the interface that separates the view layer (Blocking Screen GUI) from the model/controller layers. The Blocking Interface has three main functionalities:

 It receives requests from the Event Handler to block/unblock the resource being launched. This component achieves this by opening/closing the Blocking Screen GUI on the device’s screen.

 If requested by the end-user (e.g. by pressing back button) or by the Event Handler (deny launch), the Blocking Interface can also kill the process that hosts the resource being launched.

 It obtains the end-user credentials, via Blocking Screen GUI, and executes identification/authentication tasks. When a user is satisfactorily identified and authenticated, the Blocking Interface sends the end-user ID back to the Event Handler.

80

Figure 27 User behaviour App Locker Architecture

4.7.2.2.4 Blocking Screen GUI 

This component is the user interface itself (window, widget, etc.) displayed on the device’s screen. Its main functionality is to block protected resources (at view level) from being displayed on the device’s screen. The Blocking Screen GUI provides a conventional login form for the end-user to enter username and credentials to be sent to the Blocking Interface for authentication purposes.

4.7.2.2.5 Policy Manager 

This component processes policy evaluation requests from the Event Handler and returns an evaluation decision (allow/deny). The Policy Manager performs the following steps:

 Retrieves the applicable sticky policies (app_policy.xml) from the System Repositories.  Requests the required attributes for policy evaluation from the Attribute Resolver.  Evaluates the policies

81 4.7.2.2.6 Attribute Resolver 

This component resolves attributes requested by the Policy Manager. The Attribute Resolver provides the interfaces needed to communicate with the Application Frameworks APIs. This component consists of different subcomponents dedicated to obtain specific attribute values.

4.7.2.2.7 Application Frameworks (APIs) 

This component provides high level APIs to access to/interact with the different resources available in the device’s system. For instance in the Android platform, application frameworks include: activity manager, content providers, location manager, resource manager, notification manager, etc.

82 4.7.2.3 Flowchart design

83