SOUPS 2008SOUPS 2008 July 24, 2008

Universal Device Pairing using an Auxiliary Device

Nitesh Saxena, Md. Borhan Uddin and Jonathan VorisNitesh Saxena, Md. Borhan Uddin and Jonathan Voris

Polytechnic Institute of New York Universitynsaxena@poly.edu, borhan@cis.poly.edu, jvoris@cis.poly.edu

SOUPS 2008SOUPS 20082

The "Pairing" Problem

How to bootstrap secure communication between two wireless devices when they have No prior association No common trusted third partyExamples

o Pairing a Bluetooth cell phone with a headset

o Pairing a WLAN laptop with an access point

SOUPS 2008SOUPS 20083

Main Solution Idea

Utilize an Out-Of-Band (OOB) channel between the

deviceso Created with “human-sensory” (audio, visual, tactile) output

o The OOB channel is physically authenticatable

Place a minimal burden on device userso Usability is of extreme importance

SOUPS 2008SOUPS 20084

Security Model

Devices are connected by two channel types:o An insecure, high bandwidth wireless channelo An authenticable, (typically) low bandwidth OOB channel

Adversary has complete control over the wireless channel

o Can eavesdrop on, delay, drop, replay, reorder, and modify messages

Adversary has a limited control over the OOB channel

o Can not modify messages, but can eavesdrop on, delay, drop, replay, and reorder messages

SOUPS 2008SOUPS 20085

Prior Work

Seeing-is-Believing by McCune et al. [Oakland’05]o Based on protocol by Balfanz et al. [NDSS’02]

A B

pkA

pkB

H(pkA)

H(pkB)

Insecure Channel

Secure with:o A weakly CR H()

o An 80 bit permanent key

o A 48 bit ephemeral key

Authenticated Channel

SOUPS 2008SOUPS 20086

SAS Protocol

A

Wireless ChannelUnidirectional OOB Channel

Short Authenticated Strings (SAS) pairing protocol

by Pasini-Vaudenay [PKC’06]

An adversary can not succeed with

a probability greater than 2-k

k=15 offers reasonable security in

practice

pkA, cA

pkB, RB

dA

)( BRBA pkHRSASA

)( BRBB pkHRSASA

B

Accept (pkB,B) if Accept (pkB,A) if )( BRBB pkHRSAS

A )( BRBA pkHRSAS

A

SOUPS 2008SOUPS 20087

Drawbacks with Prior Research

Geared for specific pairing scenarios None are universally applicable

Require hardware and interfaces not common across all devices

User doesn’t know what method to use with what pair of devices confusion!

We believe: universality would immensely improve security as well as usability

SOUPS 2008SOUPS 20088

A Universal Pairing Method (1)

Prasad-Saxena [ACNS’08] Use existing SAS protocols The strings transmitted by both devices over

OOB channel are the same, if everything is fine different, if there is an attack or fault

Both devices encode these strings using a pattern of Synchronized beeping/blinking The user acts as a reader and verifies if the two

patterns are same or not

SOUPS 2008SOUPS 20089

A Universal Pairing Method (2)

Usability? It was shown that human users are capable of

efficiently performing Blink-Blink Beep-Blink

However, in practice users will commit mistakes Due to a slight distraction, for example

Motivation for this paper: can we do better?

SOUPS 2008SOUPS 200810

The Proposed Scheme Automate the prior scheme based on manual comparison Utilize an auxiliary device to perform the comparison

A B

S

ucce

ss/F

ailu

re

SOUPS 2008SOUPS 200811

Manual vs Automated

or

or

Manual Pairing using Blink-Blink or Audio-Blink

Automated Pairing using Blink-Blink or Audio-Blink

Device1Device2

Device1Device2

ATD

Result

SOUPS 2008SOUPS 200812

ATD Requirements In the Blink-Blink setup, the ATD requires a camera

as a receiver For the Audio-Blink setup, the ATD requires a

camera and a microphone as receivers Both require a screen or speaker to output the pairing

outcome Today’s camera phones are suitable ATDs The ATD does not connect over the wireless channel

with the devices being paired The ATD does not need to trusted with any

cryptographic secret

SOUPS 2008SOUPS 200813

Implementation

For testing, a Dell Laptop was used as an ATDo 2.0 megapixel, 30 FPS webcam

Devices being paired were simulated using a desktop computero Visual output interface: LEDs connected via a parallel porto Audio output interface: Desktop speakers

SOUPS 2008SOUPS 200814

Experimental Setup

Overall setup

Audiovisual receiver:Laptop camera and microphone

LEDs used to simulate two devices’ visual output interfaces

SOUPS 2008SOUPS 200815

Encoding Method

A ‘1’ SAS bit is expressed by activating the output interface for a given signal interval A ‘0’ SAS bit is represented by disabling the output interface for the duration of the signal intervalOptimal intervals determined experimentally

o Dependant on the ATD’s processing speed Which output interfaces are used depends on which pairing scheme is in use In our experiments, we used a 15-bit SAS

SOUPS 2008SOUPS 200816

Visual Data Processing/Decoding Visual data was encoded using blinking LEDs

o Signal interval: 250 ms The ATD used saturation and luminance

measurements to detect LEDs and capture their encoded SAS data

Overall transmission time: 4.5 seconds to transmit and capture 18 frameso 15 data frameso 3 control frames: All-OFF, All-ON, SYNC

SOUPS 2008SOUPS 200817

Audio Data Processing/Decoding

Audio data was encoded as spoken English words using the Microsoft Speech API (SAPI) 5.0 Text-To-Speech engineo Signal interval: 400 ms

The ATD captured the audio data via a microphone and decoded it using the SAPI Speech Recognition engine

Overall transmission time: 7.2 seconds

SOUPS 2008SOUPS 200818

Usability Testing

Schemes tested with 20 subjects The same tests were performed with the manual and automated setup Each subject was presented 24 test cases

20 reliability tests for the Blink-Blink and Audio-Blink schemes 4 tests for the robustness of the ATD

Test goals:o Determine if the ATD could be used to reliably pair deviceso Determine which scheme:

Demonstrated the least amount of errors safe errors or false positives, and fatal errors or false negatives

Users qualitatively preferred

SOUPS 2008SOUPS 200819

Testing Interface (1)

Blink-Blink Setup: Failed Pairing

SOUPS 2008SOUPS 200820

Testing Interface (2)

Audio-Blink Setup: Successful Pairing

SOUPS 2008SOUPS 200821

Testing Interface (3)

SOUPS 2008SOUPS 200822

Usability Testing ResultsCombination Average Timing

(seconds)Safe Error Rate (%) Fatal Error Rate

(%)

Blink-Blink 13.079 (sda=3.524) 1.43 0.00

Audio-Blink 15.261 (sd= 3.387) 7.14 0.00

Combination Average Timing (seconds)

Safe Error Rate (%) Fatal Error Rate (%)

Blink-Blink 20.983 (sd=3.107) 2.00 2.00

Beep-Blink 13.583 (sd=2.659) 1.00 20.00

Results of Automated Comparison Tests

Results of Manual Comparison tests

a= Estimated Standard Deviation from the sample

80% of the subjects (16 out of 20) preferred the automated scheme 20% of the subjects (4 out of 20) preferred the manual scheme.

SOUPS 2008SOUPS 200823

Discussion (1)

Results indicate that the use of an ATD makes the pairing process safer and less burdensome

o No fatal errorso Reduced safe error rate

The higher safe error rate of Audio-Blink is attributable to the ATD picking up background noise

o The ATD’s audio robustness is expected to improve when implemented on a smartphone as opposed to the current proof-of-concepto Users of this scheme must be sure of the origin of the SAS audio to guard against attacks

SOUPS 2008SOUPS 200824

Discussion (2)

Whether the ATD is a help or hindrance in terms of speed is dependant on its decoding rate for a particular setup

o Blink-Blink: Automated is faster than manual due to the fast visual decoding processo Audio-Blink: Automated is slower than manual due to the relatively slower audio decoding process

SOUPS 2008SOUPS 200825

Conclusion

Both the manual and automated schemes are universally applicable to any pairing scenario

Use of an ATD is not mandatory, but test results show it increases usability when available

An ATD can handle SAS encodings that a human users can noto Longer stringso Multiple simultaneous output interfaces

SOUPS 2008SOUPS 200826

Thank you!