Universal Device Pairing using an Auxiliary Device

1. 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 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 • Pairing a Bluetooth cell phone with a headset • Pairing a WLAN laptop with an access point SOUPS 2008

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

4. Security Model • Devices are connected by two channel types: • An insecure, high bandwidth wireless channel • An authenticable, (typically) low bandwidth OOB channel • Adversary has complete control over the wireless • channel • Can eavesdrop on, delay, drop, replay, reorder, and modify messages • Adversary has a limited control over the OOB • channel • Can not modify messages, but can eavesdrop on, delay, drop, replay, and reorder messages SOUPS 2008

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

6. An adversary can not succeed with • a probability greater than 2-k • k=15 offers reasonable security in practice pkA, cA pkB, RB dA SAS Protocol • Short Authenticated Strings (SAS) pairing protocol • by Pasini-Vaudenay [PKC’06] Wireless Channel Unidirectional OOB Channel A B Accept (pkB,B) if Accept (pkB,A) if 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 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 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? SOUPS 2008

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

11. Manual vs Automated or Device1 Device2 Manual Pairing using Blink-Blink or Audio-Blink or Device1 Device2 Result ATD Automated Pairing using Blink-Blink or Audio-Blink 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 SOUPS 2008

13. Implementation • For testing, a Dell Laptop was used as an ATD • 2.0 megapixel, 30 FPS webcam • Devices being paired were simulated using a desktop computer • Visual output interface: LEDs connected via a parallel port • Audio output interface: Desktop speakers SOUPS 2008

14. Experimental Setup Audiovisual receiver: Laptop camera and microphone Overall setup LEDs used to simulate two devices’ visual output interfaces 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 • 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 2008

16. Visual Data Processing/Decoding • Visual data was encoded using blinking LEDs • 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 • 15 data frames • 3 control frames: All-OFF, All-ON, SYNC 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 • 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 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: • Determine if the ATD could be used to reliably pair devices • Determine which scheme: • Demonstrated the least amount of errors • safe errors or false positives, and • fatal errors or false negatives • Users qualitatively preferred SOUPS 2008

19. Testing Interface (1) Blink-Blink Setup: Failed Pairing SOUPS 2008

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

21. Testing Interface (3) SOUPS 2008

22. Usability Testing Results a=Estimated Standard Deviation from the sample 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. SOUPS 2008

23. Discussion (1) • Results indicate that the use of an ATD makes the • pairing process safer and less burdensome • No fatal errors • Reduced safe error rate • The higher safe error rate of Audio-Blink is attributable • to the ATD picking up background noise • The ATD’s audio robustness is expected to improve when implemented on a smartphone as opposed to the current proof-of-concept • Users of this scheme must be sure of the origin of the SAS • audio to guard against attacks 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 • Blink-Blink: Automated is faster than manual due to the fast visual decoding process • Audio-Blink: Automated is slower than manual due to the relatively slower audio decoding process 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 • Longer strings • Multiple simultaneous output interfaces SOUPS 2008

26. Thank you! SOUPS 2008