View
215
Download
0
Tags:
Embed Size (px)
Citation preview
SOUPS July 24, 2008SOUPS 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 University
2
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
3
Main Solution Idea
Utilize an Out-Of-Band (OOB) channel between the
deviceso Created with human perceptible (audio, visual, tactile) output
o The OOB channel is physically authenticatable
Place a minimal burden on device userso Usability is of extreme importance
4
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
5
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
6
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,H(RA,pad)
pkB,RB
RA,pad
)( BRBA pkHRSASA
)( BRBB pkHRSASA
B
Accept (pkB,B) if Accept (pkB,A) if )( BRBB pkHRSAS
A )( BRBA pkHRSAS
A
7
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
8
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 fineo different, if there is an attack or fault
Both devices encode these strings using a pattern of o Synchronized beeping/blinkingo The user acts as a reader and verifies if the two patterns
are the same or not
9
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 mistakeso Due to a slight distraction, for example
Motivation for this paper: can we do better?
10
The Proposed Scheme Automate the prior scheme based on manual comparison Utilize an Auxiliary Third Device (ATD) to perform the comparison
S
ucce
ss/F
ailu
reDevice1
or
Device2
ATD
11
Manual vs Automated
or
Manual Pairing using Blink-Blink or Audio-Blink
Automated Pairing using Blink-Blink or Audio-Blink
Device1 Device2
ATD
Success/Failure
Device1
or
Device2
12
Role of the User
When performing automated pairing, a user is responsible foro Pressing a button on one device to start pairingo Adjusting the ATD’s inputs to focus on the devices being
pairedo Pressing a button to activate the ATD’s receivers o Pressing a button on one device to start SAS transmissiono 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
13
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
14
Implementation
For testing, a laptop computer 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
15
Experimental Setup
Overall setup
LEDs used to simulate visual output interfaces
Laptop used as an ATD
Speaker used to simulate an audio output
interface
ATD’s receivers:Camera andmicrophone
16
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
17
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
18
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
19
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 schemeso 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
20
Usability Testing Results
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
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
80% of the subjects (16 out of 20) preferred the automated scheme 20% of the subjects (4 out of 20) preferred the manual scheme.
21
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
22
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
23
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