Table of Contents
The concrete problem we investigated was authentication of pervasive devices - how can a user be guaranteed that the device they associate with is indeed the device “in front of them”. Only when a device’s authenticity can be established in the first place, further measures can be taken for securing of the communication channel. The authentication problem arises because there is no way in a wireless network to directly match the virtual entity discovered on the network with the physical entity the user “discovered” in the “real world”. Traditional authentication mechanisms are not applicable to this problem - they are relying on a priori knowledge (e.g. shared secrets), trusted third parties, or direct user interfaces for authentication. This project proposed context sensing to obtain human-verifiable device authenticity in the process of spontaneous device association. Context-based authentication was practically uncharted territory, and the aim of this project was to prepare the field by a systematic analysis of the design opportunities and challenges, and by prototyping of experimental systems to gain insights into implementation and deployment issues.
The project was funded by the Commission of the European Union under the FP6 Marie Curie Intra-European Fellowship program contract MEIF-CT-2006-042194 “CAPER” and concluded successfully in 2008.
Context authentication, sometimes also called context-based authentication, means that users and/or devices are authenticated based on context. It is a young and still small, but active research area and currently my main research interest. The term context, as used in pervasive/ubiquitious computing research, describes the situation or environment in which some action takes places. For a more detailed description, please see my page on context prediction. There are many aspects to context, and they can be used to authenticate users and/or devices.
Context authentication verifies that a user and a device or multiple devices share a common part of their context, e.g. that they are at the same location, that they are carried by the same user, or that the experience the same audio scene. Sharing context in this sense can be used for efficient and intuitive authentication protocols, from explicit authentication (where the user explicitly needs to perform some interaction to authenticate) to implicit authentication (where just being in a certain context entails authentication). There exist few projects that use a very specific aspect of context for authentication, but most of them still use it explicitly.
The outcome of this research project was aimed to be two-fold:
- Developing multiple demonstration application using various different sensor technologies will allow to explore which aspects of context work well for authentication purposes. Is it not yet clear which technologies will be intuitive to users and will provide high levels of security at the same time. All demonstration applications should be released under an open source license, but some will necessarily depend on custom sensor hard- and software that might not be available off-the-shelf.
- An open source toolkit for context authentication will be created that offers cryptographic protocols and wrappers for common sensor technology to make it easy for application developers to use context authentication. Although the initial target platform will probably be Java, other platforms will be investigated and ports might be done in the future.
Two demonstration applications have already been developed using Relate sensors. The Relate project provides USB dongles that can be attached to any device with an USB host port and that provide relative spatial positioning. That is, devices with Relate dongles can sense each other with a precision of about 10 cm in distance and 25° in angle (in a plane, 3D coming later).
The source code to all the developed authentication protocols and demonstration applications will soon be released in the form of a general toolkit. It is nearly ready, but I want to add more unit tests and generally run more tests before the first release. Because this includes newly developed authentication protocols, the code should be secure.
For now, the spatial authentication plugin for Relate project applications is available in compiled form.
This project spun out to be developed more independently of Relate: OpenUAT, The Open Source Ubiquitous Authentication Toolkit
These papers were published as part of the project: 1 2 3 4 5 6.
Demonstration application 1: Send it there: Secure file transfer and chat
The first demonstration application allows to create secure connections between devices with Relate dongles. Over these secure connections, file transfer and chat can be used. This secure channel uses IPSec transport connections, and implementations for Linux (with either KLIPS or the native IPSec stack and either the pluto IKE daemon from openswan/strongswan/freeswan or the racoon IKE daemon), MacOS/X Tiger (which uses the racoon IKE daemon) and Windows 2000/XP will soon be released on this page.
For the Linux and MacOS/X implementations, the only requirement is a small change to the pluto/racoon configuration files to include dynamically generated IPSec policy configuration files. For Windows 2000/XP, ipsecpol or ipseccmd (not the typical, but the complete installation!), respectively, need to be installed and the VPNtool binary needs to be available in a system path. To avoid tinkering with the PATH environment variable, I recommend to simply copy ipsecpol.exe/ipseccmd.exe and ipsec.exe to %SystemRoot%\system32. This way, they will be executable by default.
More details about this application can be posted after a submitted paper has been reviewed.
Demonstration application 2: IPSecME: IPSec Made Ease
The second demonstration application supports to easily establish IPSec connections between devices, even when they can not directly share context. One example is to create an IPSec conection between a WLAN client and an access point, when the access point can not be equipped with a Relate dongle or is not directly accessible. More complex configuration are also supported, both in IPSec tunnel and in transport mode.