1. SOUPS July 24, 2008 Universal Device Pairing using an Auxiliary Device Nitesh Saxena, Md. Borhan Uddin and Jonathan Voris Polytechnic Institute of New York University

2. 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. 3 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

4. 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. 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. 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,H(R A,pad) pk B,R B R A,pad B Accept (pk B,B) if Accept (pk B,A) if

7. 7 Drawbacks of Prior Research  Geared for specific pairing scenarios  None are universally applicable oRequire 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. 8 A Universal Pairing Method (1) Prasad-Saxena [ACNS’08]  Use existing SAS protocols  The strings transmitted by both devices over OOB channel are othe same, if everything is fine odifferent, if there is an attack or fault  Both devices encode these strings using a pattern of oSynchronized beeping/blinking oThe user acts as a reader and verifies if the two patterns are the same or not

9. 9 A Universal Pairing Method (2)  Usability? oPrevious work has shown that human users are capable of efficiently performing  Blink-Blink  Beep-Blink  However, in practice users will commit mistakes oDue to a slight distraction, for example  Motivation for this paper: can we do better?

10. 10 The Proposed Scheme  Automate the prior scheme based on manual comparison  Utilize an Auxiliary Third Device (ATD) to perform the comparison Success/Failure Device1 or Device2 ATD

11. 11 Manual vs Automated or Manual Pairing using Blink-Blink or Audio-Blink Automated Pairing using Blink-Blink or Audio-Blink Device1Device2 ATD Success/Failure Device1 or Device2

12. 12 Role of the User  When performing automated pairing, a user is responsible for oPressing a button on one device to start pairing oAdjusting the ATD’s inputs to focus on the devices being paired oPressing a button to activate the ATD’s receivers oPressing a button on one device to start SAS transmission oAccepting or rejecting the pairing session based on the ATD’s output  Users do not have to remember what steps to take oThe ATD will provide instructions

13. 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. 14 Implementation  For testing, a laptop computer 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

15. 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 and microphone

16. 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 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

17. 17 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

18. 18 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

19. 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 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

20. 20 Usability Testing Results CombinationAverage Timing (seconds) Safe Error Rate (%) Fatal Error Rate (%) Blink-Blink13.079 (sd=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  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. 21 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

22. 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 process o Audio-Blink: Automated is slower than manual due to the relatively slower audio decoding process

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

24. 24 Thank you!