Home

Overview

OpenUAT provides components on the layers of cryptographic primitives, key agreement and authentication protocols, secure channels, and dealing with sensor data.

OpenUAT layers

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.

(This overview is an excerpt of the initial paper and as such subject to the same IEEE copyright statement.)