OpenUAT protocols

OpenUAT implements different authentication protocols from a user respectively application point of view. However, on implementation and wire-protocol level, most of these have now been unified with the newly developed Unified Auxiliary Channel Authentication Prococol (UACAP). UACAP can use the following interaction modes:

  • input: The user acts as an information provider and causes common input to all authentication parties, for example by entering the same password/PIN or shaking both devices in the same hand.
  • transfer: The user assists in transferring a message from one device to the other, for example by reading from the screen and entering the displayed string on the other device or by capturing a displayed 2D barcode with the camera of the other device.
  • verify: The user acts as a verifier and compares the output of all authentication parties, for example by verifying that the strings displayed on both devices are equal or that audio tunes match.

These different modes distinguish protocol flow before and after the common key agreement phase:

UACAP protocol overview

Implemented main (in-band) channels

Currently, OpenUAT implements the following channels for normal communication. These are not assumed to be secure in any way and are used to exchange messages for key agreement and authentication as well as for mass data transfer.

Generally, in-band channels implement the org.openuat.util.RemoteConnection interface and are thus exchangeable. One prominent user of this interface is the org.openuat.util.HostServerBase class which implements an abstract listener for incoming connections, and in turn hands control over to the central org.openuat.authentication.HostProtocolHandler for handling incoming authentication requests.

  • RemoteTCPConnection: Uses standard TCP sockets for transparent communication. Hosts are represented by their IP addresses.
  • BluetoothRFCOMMChannel: Uses Bluetooth RFCOMM channels for communication. Hosts are represented by their Bluetooth MAC addresses.

 Future channels will probably include communication via HTTP (directly and/or indirectly via message-board style servers) to get around NAT and firewall issues and more easily support mobile phone clients and potentially Jabber for similar reasons.

In addition to this standard unicast communication, multicast is also support in form of the MessageListener interface, currently implemented by UDPMulticastSocket.

Implemented auxiliary (out-of-band) channels

OpenUAT also implements the following out-of-band channels that are assumed to have some properties that main communication channels lack, for example integrity, confidentiality, stall-freeness, or - most importantly - (partial or complete) authenticity.

These channels generally implement the org.openuat.authenticationOOBChannel and/or  org.openuat.authentication.OOBMessageHandler interfaces to be exchangeable.

  • VisualChannel respectively J2MEVisualChannel: Implements transfer mode by displaying a 2D barcode (specifically a QRcode) on one device screen and capturing this code with the camera of another.
  • AudioChannel respectively J2MEAudioChannel: Implements both transfer and verify modes by playing generated MIDI tunes on one or both devices and optionally capturing these messages with a microphone and trying to decode them on the other device.
  • ButtonChannel and its sub-classes: Implements both input and transfer modes based on synchronized button presses.

Additional out-of-band channels in the current release are not (yet) based on the common OOBChannel infrastructure because of different handling of sensor data:

  • RelateAuthenticationProtocol: Implements authentication based on relative spatial locationship as measured by ultrasonic pulses. The specific implementation relies on USB dongles produced by the EC "Relate" project.
  • ShakeWellBeforeUseProtocol1 and ShakeWellBeforeUseProtocol2: Implement authentication based on common movement by shaking devices together in one hand and sensing the movement with embedded accelerometers. Specific sensor implementations are currently provided for:
    • WiTilt mobile sensors connected via Bluetooth or serial port
    • Nokia ("old" and "new") sensor API, tested on Nokia 5500 and Nokia N95
    • prototype code for Windows Mobile for PocketPC phones: Samsung Omnia i900 and HTC Touch Diamond
    • Pulse-width sampled accelerometers connected directly to a parallel port

Implemented secure channels

On top of insecure channels, secure channels can be established after authentication. OpenUAT currently brings support for the following secure channel types.

These channels generally implement the interface to be exchangeable.

  • IPSecConnection: Implement creating, starting, and stopping IPSec (transport mode) connections for:
    • Linux with Openswan/strongSwan or Racoon.
    • MacOS/X with Racoon.
    • Windows XP/Vista.

Future channels may include TLS-PSK for application-level communication without operating system support.

This page was last modified on 2014-02-24