OpenUAT
Table of Contents
Short Summary
OpenUAT provides combinations of cryptographic primitives and techniques with methods from sensor data analysis to create new authentication methods for ubiquitous computing. It is an open source Java implementation of various methods and protocols for research purposes.
If you are looking for latest source code, the current main repositories are at Github:
Context-based authentication
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/mobile computing research, describes the situation or environment in which some action takes place. 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.
OpenUAT tries to collect different sensor-/context-based authentication methods into one common framework in Java. It will run with desktop Java, Android, or J2ME.
The Toolkit
The purpose of OpenUAT is to provide methods for creating shared secrets between two (or multiple) devices. These secrets should be authenticated to prevent man-in-the-middle (MITM) attacks. Authentication between personal devices and the environment is difficult, because such devices are small, mobile, and typically have limited resources. The absence of large screens and efficient input devices makes authentication based on sensor information even more attractive.
Main design goals are for OpenUAT to be:
- lightweight: Resources on mobile, battery-powered devices are generally sparse. This includes storage and run-time memory, CPU, communication bandwidth, but also battery lifetime, input/output devices, and user attention. OpenUAT tries to be as small as reasonably possible, use static memory buffers when possible, and minimise communication. These aims are conflicting, and when no generally acceptable compromise can be found in some case, the respective components should be parameterisable for application developers.
- self-contained: Devices and platforms where the toolkit might be used are expected to be extremely diverse. Therefore, we can not depend on specific libraries to be available. Any dependencies that are not included in the default platforms should be included in OpenUAT.
- simple to use: An authentication toolkit is most useful if it can be used without great care on the side of application developers. This has two reasons: if it is too complex to learn, developers will not use it for simple applications, and if it is complex to use, it is likely that it will be used erroneously and thus insecurely. Ideally, the various components of OpenUAT can be used as black boxes with simple interfaces, and can be combined with each other and with application-specific hooks to build secure context authentication protocols without knowing about the internals.
- extensible: It is obvious that a toolkit should be easily extensible by additional components.
- vertical: As context based authentication concerns all layers from sensing hardware, input/output devices, networking, application context, up to user interaction, OpenUAT should provide components that span the layers. High-level components that relate to complete use-cases can make use of primitives from various lower-level layers.
- interoperable: Ubiquitous computing environments are inherently heterogeneous. Authentication protocols therefore need to be interoperable between different platforms. Thus, network communication should either be based on standardized protocols (e.g. IETF RFCs) or use simple ASCII line based protocols in the spirit of SMTP, HTTP, and others.
This list is an excerpt of the initial paper and as such subject to the same IEEE copyright statement.
Overview
OpenUAT provides components on the layers of cryptographic primitives, key agreement and authentication protocols, secure channels, and dealing with sensor data.
These components/layers are:
- Cryptographic primitives: Implementations of ciphers, secure hashes, etc. are widely available, even as part of newer Java 2 runtimes (generally starting with version 1.4). However, this so-called Java cryptography extension (JCE) has not yet been included in the J2ME standard that is supported by most Java implementations on small, mobile devices. To fulfill the goal of being self-contained, the toolkit therefore uses wrappers around the JCE algorithms where necessary, and includes alternative implementations from the Bouncycastle cryptographic library. When JCE is not supported on a target platform, the toolkit can use these as a fallback, albeit typically with slightly worse performance due to missing native implementations. Classes from Bouncycastle are also used to augment JCE primitives where they lack higher-level support. On top of these primitives, OpenUAT adds small wrapper and utility classes that make the underlying algorithms as simple to use as possible.
- Communication channels: Java already offers good support for working with TCP or UDP connections. OpenUAT again adds utility classes for simplifying setup and use of these protocols for standard cases.
- Key management protocols: This layer uses cryptographic primitives and communication channels to provide simple key agreement protocols.
- Sensors and feature extractors: Dealing with sensor data is an important part for context authentication; this includes interfacing to the hardware sensors for data acquisition, handling of time series, and extracting appropriate features.
- Context authentication protocols: Components on this layer tie together key agreement and authentication based on sensor data to create context authentication protocols. The result of a successful execution of one of these protocols is an authenticated secret shared key that can be used by applications. This is the main focus of OpenUAT.
- Secure channels: The last layer implements secure communication channels, preferably based on standard protocols. These protocols generally depend on either trusted third parties, which can not be realistically assumed for ubiquitous computing environments, or shared secrets, as e.g. generated by components of the context authentication protocols layer.
All key agreement and authentication protocols are event based and executed in the background. Three types of events can be generated: success (with the resulting shared secret key embedded into the event), failure (with a message giving reason for the failure), and progress (optionally with indication of how many steps have been finished and how many are left). These events can be used to provide user feedback in applications.
The Log4j framework is used for run-time configurable logging and JUnit for an extensive set of unit tests. Test cases cover single components as well as combinations spanning multiple layers, and special tests including real-world data samples for the context authentication protocols. Additional utility classes are used for defensive and fail-safe programming, like a “safety belt” timer used to terminate authentication protocols after timeouts.
Developers can use components simply by adding the single JAR file (or only the required components if program size is an issue) and using the provided classes. Applications only need to implement a single interface to process standard authentication. Extending OpenUAT with new components is similarly simple: there is no central structure that needs to be followed for every part, nor are there main interfaces that must be implemented. OpenUAT provides some basic infrastructure, and extensions are free to use it. Its design loosely follows the principle of UNIX command line tools: to combine components with simple interfaces into more complex parts. When no suitable context authentication protocol is available for a specific applications, then the more basic layers should help in constructing it, ideally also adding it as a new component to OpenUAT.
Archival copy of old website
Archival copy of openuat.org
