Universal Device Pairing using an Auxiliary Device Nitesh

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 Mc. Cune et al. [Oakland’ 05] o Based on protocol by Balfanz et al. [NDSS’ 02] pk. A pk. B A H(pk. A) Insecure Channel B Authenticated Channel H(pk. B) 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] pk. A, H(RA, pad) Wireless Channel Unidirectional OOB Channel pk. B, RB A RA, pad B An adversary can not succeed with a probability greater than 2 -k Accept (pk. B, B) if k=15 offers reasonable security in practice Accept (pk. B, A) if 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 o the same, if everything is fine different, if there is an attack or fault Both devices encode these strings using a pattern of o o Synchronized beeping/blinking 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 Ø Ø However, in practice users will commit mistakes o Blink-Blink Beep-Blink 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 Device 1 Success/Failure or Device 2 ATD 10

Manual vs Automated or Device 1 Device 2 Manual Pairing using Blink-Blink or Audio-Blink or Device 1 Device 2 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 o o Pressing a button on one device to start pairing Adjusting the ATD’s inputs to focus on the devices being paired Pressing a button to activate the ATD’s receivers Pressing a button on one device to start SAS transmission 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 o Visual output interface: LEDs connected via a parallel port 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 o 15 data frames 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-To. Speech 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 v Safe errors or false positives, and v Fatal errors or false negatives Ø Users qualitatively preferred 19

Usability Testing 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 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