ABSTRACT:
Sharing sensitive context information among multiple distributed components in mobile environments introduces major security concerns. The distributed sensing, processing and actuating components of these applications can be compromised and modified or impersonated to extract private and confidential information or to inject false information.
In this paper we present the Anubis protocol for remote code attestation and access control of distributed components using remote execution of trusted code. Our Anubis protocol leverages previous work in the fields of wireless sensor networks and secure web-browsing.
Anubis allows new components to be introduced to the environment without updating existing components. Our implementation of Anubis in Android G1 based applications shows that the protocol introduces manageable overhead (less than 600 ms latency and 35 kB packet overhead) which does not significantly impact the user experience.
SNIPPETS:
Models and Assumptions:
In this section, we present the assumptions made in the design of the Anubis protocol, the trust model Anubis creates and the types of attacks it repulses.
A. Distributed Application Model – Widget Model:
While the Anubis protocol can be applied to most distributed computational applications in general, in this paper we focus on using Anubis to secure distributed context-aware applications. The context-aware applications we consider use the widget model presented by Dey et al.
B. System Model:
n this work, we make minimal assumptions about the hardware on which widgets exist and execute, but are more concerned about the software existing on the system on which each widget resides.We assume that a device has sufficient computing power to verify public-key signatures, and that a device has sufficient memory to store a public key, a couple of hash values and code files used for remote execution.
C. Trust Model:
Anubis’ trust model is built upon a widget securely ensuring another widget’s application logic is unchanged from the point in time at which the second widget was signed. Before deployment a widget is submitted to an authentication service which verifies whether the widget should have the authority to provide or consume context regarding a particular entity, then it generates signed authentication information about the widget.
D. Attacker Model:
Here we present attackers with two types of intent (encompassing the most common types of attacks on distributed context-aware applications), 1) to extract secret information from the system or 2) inject false information into the system.
ANUBIS:
Anubis is a protocol that allows loosely coupled components in a distributed context-aware application to remotely attest to their code and provide access control to context information.
A. Logical Architecture of a Widget:
The Anubis system logically divides up a widget into four
separate sections (Figure 2). The logical sections are:
1) Code Area (contains the widget’s application logic)
2) Data Area (holds all application variables and context information)
3) Code Interpreter (an interpreter with a simple instruction set, used by other widgets in the authentication process of this widget)
4) Code Interpreter Data Area (area for variables belonging to scripts running on the code interpreter).
B. Anubis Protocol Overview:
The Anubis protocol has two stages of operation, the signing stage and the authentication stage.
Signing Stage:
The signing stage of a widget occurs offline before deployment, by an Authentication Service (AS). The AS must have the credentials to sign on behalf of the entity whose context information the widget will be handling.
Authentication Stage:
The authentication stage is triggered when a widget (widget A) discovers another widget (B) from which it requires context information and they setup a secure channel through which A requests a connection from B.
C. Code Interpreter and Code Files:
The code interpreter is a simplistic interpreter used to execute code files received from other widgets during authentication. Code files running on the interpreter have three tasks, i.e. to calculate hash codes of sections of the widget, to check the return address of the code interpreter to the main body of code, and transmit the calculated values to the code file’s parent widget.
Authentication Process of Widget a by Widget B over a Established Secure Channel.
D. Authenticating for Multiple Entities:
In cases where a widget is interested in context information belonging to more than one entity, Anubis can simply be implemented separately for each entity. The widget would be separately signed by authentication services that have credentials for each entity.
IMPLEMENTATION:
We have implemented a prototype version of the Anubis protocol and created a sample application which uses the protocol, as proof of concept and for collecting performance statistics. The implementations are on commodity laptops running Ubuntu Linux and HTC Android G1 phones. The Android platform was selected as a proof of concept for operation in mobile computing environments.
EVALUATION:
A. Method:
In the first performance evaluation we use the Anubis system on two widgets executing on two Dell Latitude D630 laptops running Ubuntu Linux, while in the second evaluation we use two Android G1 mobile phones.
B. Results:
As can be seen from Figures 4 and 5, the authentication processing time increases as the size of a widget increases. This comes as no surprise as the amount of binary code the code file has to hash increases with the size of the widget.
Authentication Process Time.
CONCLUSION:
In this work, we presented the Anubis protocol for online attestation and access control of distributed software components for context-aware applications, but it can be easily expanded to general distributed component-based software. Anubis achieves online component attestation using component signatures created at design-time and compared against actual components at run-time by a component on a communicating device.
The primary benefit of Anubis is that it does not rely on the run-time presence of a trusted authority. Moreover, the system allows new components to be introduced into the distributed environment without interaction or modification of existing components. We believe that the security provided by the Anubis protocol is a reasonable trade for the marginal increase in execution time and required storage space on each component, both well within the capabilities of existing commercial devices.
Source: Carnegie Mellon University
Authors: Senaka Buthpitiya | Feng-Tso Sun| Heng-Tze Cheng | Patrick Tague | Martin Griss | Anind K. Dey
>> More Wireless Sensor Networks Projects Abstract for Final Year Students