Universal Device Pairing using an
Auxiliary Device
Nitesh Saxena, Md. Borhan Uddin and Jonathan Voris
Polytechnic Institute of New York University
SOUPS July 24, 2008
The "Pairing" Problem
How to bootstrap secure communication between two
wireless devices when they have
 No prior association
 No common trusted third party
Examples
o Pairing a Bluetooth cell phone with a headset
o Pairing a WLAN laptop with an access point
2
Main Solution Idea
 Utilize an Out-Of-Band (OOB) channel between the
devices
o Created with human perceptible (audio, visual, tactile) output
o The OOB channel is physically authenticatable
 Place a minimal burden on device users
o Usability is of extreme importance
3
Security Model
 Devices are connected by two channel types:
o An insecure, high bandwidth wireless channel
o 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
4
Prior Work
 Seeing-is-Believing by McCune et al. [Oakland’05]
o Based on protocol by Balfanz et al. [NDSS’02]
pkA
pkB
A
H(pkA)
Insecure Channel
B
Authenticated Channel
H(pkB)

Secure with:
o
A weakly CR H()
o
An 80 bit permanent key
o
A 48 bit ephemeral key
5
SAS Protocol
 Short Authenticated Strings (SAS) pairing protocol
by Pasini-Vaudenay [PKC’06]
pkA,H(RA,pad)
Wireless Channel
Unidirectional OOB Channel
pkB,RB
A
An adversary can not succeed with
RA,pad
SAS A  RB  H R A ( pkB )
B

SASB  RB  H R A ( pkB )
Accept (pkB,B) if
SASB  RB  H R A ( pkB )
a probability greater than 2-k
k=15 offers reasonable security in
practice
Accept (pkB,A) if
SAS A  RB  H R ( pkB )
A
6
Drawbacks of Prior Research
 Geared for specific pairing scenarios
 None are universally applicable
o 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
7
A Universal Pairing Method (1)
Prasad-Saxena [ACNS’08]
 Use existing SAS protocols
 The strings transmitted by both devices over OOB
channel are
o the same, if everything is fine
o different, if there is an attack or fault
 Both devices encode these strings using a pattern of
o Synchronized beeping/blinking
o The user acts as a reader and verifies if the two patterns
are the same or not
8
A Universal Pairing Method (2)
 Usability?
o Previous work has shown that human users are capable of
efficiently performing
 Blink-Blink
 Beep-Blink
 However, in practice users will commit mistakes
o Due to a slight distraction, for example
 Motivation for this paper: can we do better?
9
The Proposed Scheme
 Automate the prior scheme based on manual
comparison
 Utilize an Auxiliary Third Device (ATD) to perform the
comparison
Device1
Success/Failure
or
Device2
ATD
10
Manual vs Automated
or
Device1
Device2
Manual Pairing using Blink-Blink or Audio-Blink
or
Device1
Device2
Success/Failure
ATD
Automated Pairing using Blink-Blink or Audio-Blink
11
Role of the User
 When performing automated pairing, a user is
responsible for
o Pressing a button on one device to start pairing
o Adjusting the ATD’s inputs to focus on the devices being
paired
o Pressing a button to activate the ATD’s receivers
o Pressing a button on one device to start SAS transmission
o Accepting or rejecting the pairing session based on the
ATD’s output
 Users do not have to remember what steps to take
o The ATD will provide instructions
12
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
13
Implementation
 For testing, a laptop computer was used as an ATD
o 2.0 megapixel, 30 FPS webcam
 Devices being paired were simulated using a desktop
computer
o Visual output interface: LEDs connected via a parallel port
o Audio output interface: Desktop speakers
14
Experimental Setup
ATD’s receivers:
Camera and
microphone
Overall setup
Speaker used to
simulate an
audio output
interface
Laptop used
as an ATD
LEDs used to simulate visual output interfaces
15
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 interval
Optimal 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
16
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 frames
o 15 data frames
o 3 control frames: All-OFF, All-ON, SYNC
17
Audio Data Processing/Decoding
 Audio data was encoded as spoken English words
using the Microsoft Speech API (SAPI) 5.0 Text-ToSpeech engine
o 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
18
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
o 20 reliability tests for the Blink-Blink and Audio-Blink
schemes
o 4 tests for the robustness of the ATD
 Test goals:
o Determine if the ATD could be used to reliably pair devices
o Determine which scheme:
 Demonstrated the least amount of errors
 Safe errors or false positives, and
 Fatal errors or false negatives
 Users qualitatively preferred
19
Usability Testing Results
Results of Automated Comparison Tests
Combination
Average Timing
(seconds)
Safe Error Rate
(%)
Fatal Error Rate
(%)
Blink-Blink
13.079 (sd=3.524)
1.43
0.00
Audio-Blink
15.261 (sd= 3.387)
7.14
0.00
Results of Manual Comparison Tests
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
 80% of the subjects (16 out of 20) preferred the automated scheme
 20% of the subjects (4 out of 20) preferred the manual scheme.
20
Discussion (1)
 Results indicate that the use of an ATD makes the
pairing process safer and less burdensome
o No fatal errors
o 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-concept
o Users of this scheme must be sure of the origin of the SAS
audio to guard against attacks
21
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 process
o Audio-Blink: Automated is slower than manual due to the
relatively slower audio decoding process
22
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 data that is longer than what
a human user can
23
Thank you!
24