1. July 24, 2008 SOUPS 2008 Universal Device Pairing using an Auxiliary Device Nitesh Saxena, Md. Borhan Uddin and Jonathan Voris Polytechnic Institute of New York University nsaxena@poly.edu, borhan@cis.poly.edu, jvoris@cis.poly.edu

2. SOUPS 2008 2 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

3. SOUPS 2008 3 Main Solution Idea  Utilize an Out-Of-Band (OOB) channel between the devices o Created with “human-sensory” (audio, visual, tactile) output o The OOB channel is physically authenticatable  Place a minimal burden on device users o Usability is of extreme importance

4. SOUPS 2008 4 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

5. SOUPS 2008 5 Prior Work  Seeing-is-Believing by McCune et al. [Oakland’05] oBased on protocol by Balfanz et al. [NDSS’02] AB pk A pk B H(pk A ) H(pk B ) Insecure Channel Secure with: o A weakly CR H() o An 80 bit permanent key o A 48 bit ephemeral key Authenticated Channel

6. SOUPS 2008 6 SAS Protocol A Wireless Channel Unidirectional 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 pk A, c A pk B, R B dAdA B Accept (pk B,B) if Accept (pk B,A) if

7. SOUPS 2008 7 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

8. SOUPS 2008 8 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

9. SOUPS 2008 9 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?

10. SOUPS 2008 10 The Proposed Scheme  Automate the prior scheme based on manual comparison  Utilize an auxiliary device to perform the comparison A B Success/Failure

11. SOUPS 2008 11 Manual vs Automated or Manual Pairing using Blink-Blink or Audio-Blink Automated Pairing using Blink-Blink or Audio-Blink Device1 Device2 Device1 Device2 ATD Result

12. SOUPS 2008 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. SOUPS 2008 13 Implementation  For testing, a Dell Laptop was used as an ATD o2.0 megapixel, 30 FPS webcam  Devices being paired were simulated using a desktop computer oVisual output interface: LEDs connected via a parallel port oAudio output interface: Desktop speakers

14. SOUPS 2008 14 Experimental Setup Overall setup Audiovisual receiver: Laptop camera and microphone LEDs used to simulate two devices’ visual output interfaces

15. SOUPS 2008 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. SOUPS 2008 16 Visual Data Processing/Decoding  Visual data was encoded using blinking LEDs oSignal 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 o15 data frames o3 control frames: All-OFF, All-ON, SYNC

17. SOUPS 2008 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 oSignal 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. SOUPS 2008 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  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 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. SOUPS 2008 19 Testing Interface (1) Blink-Blink Setup: Failed Pairing

20. SOUPS 2008 20 Testing Interface (2) Audio-Blink Setup: Successful Pairing

21. SOUPS 2008 21 Testing Interface (3)

22. SOUPS 2008 22 Usability Testing Results CombinationAverage Timing (seconds) Safe Error Rate (%) Fatal Error Rate (%) Blink-Blink13.079 (sd a =3.524)1.430.00 Audio-Blink15.261 (sd= 3.387)7.140.00 CombinationAverage Timing (seconds) Safe Error Rate (%) Fatal Error Rate (%) Blink-Blink20.983 (sd=3.107)2.00 Beep-Blink13.583 (sd=2.659)1.0020.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.

23. SOUPS 2008 23 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

24. SOUPS 2008 24 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

25. SOUPS 2008 25 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 not oLonger strings oMultiple simultaneous output interfaces

26. SOUPS 2008 26 Thank you!