OpenUAT

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.

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

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 org.openuat.channel.SecureChannel 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.