1. Device(-to-Device) Authentication Nitesh Saxena Polytechnic University

2. The Problem: “Pairing” How to bootstrap secure communication between Alice’s and Bob’s devices when they have  no prior context  no common trusted CA or TTP Examples (single user setting)  Pairing a bluetooth cell phone with a headset  Pairing a WiFi laptop with an access point

3. PIN-based Bluetooth Pairing

4. Authentication 1 2

5. (In)Security of PIN-based Pairing Long believed to be insecure for short PINs  Why? First to demonstrate this insecurity; Shaked and Wool [Mobisys’05]

6. Attack Implementation Coded in C on linux platform  Given a piece of code for SAFER algorithm, implemented the encryption functions E 22, E 21, E 1 Hardware for sniffing: bluetooth packet analyzer with windows software Log Parser (in perl): reads the sniffer log, and parse it to grab IN_RAND, RAND_A \xor K init, RAND_B \xor K init, AU_RAND_A, AU_RAND_B, SRES

7. Timing Measurements of Attack Theoretically: O(10^L), with decimal digits  Assuming the PINs are chosen uniformly at random Empirically, on a PIII 700MHz machine: No. of digits in PIN (L) CPU time (sec) 41.294 512.915 6129.657 71315.332

8. Timing of Attack and User Issues ASCII PINs: O(90^L), assuming there are 90 ascii characters that can be typed on a mobile phone  Assuming random pins However, in practice the actual space will be quite small  Users choose weak PINs;  User find it hard to type in ascii characters on mobile devices Another problem: shoulder surfing (manual or automated)

9. The Problem: “Pairing” Idea  make use of a physical channel between devices  with least involvement from Alice and Bob Authenticated: Audio, Visual, Tactile

10. Seeing-is-Believing (McCune et al. [Oakland’05]) Protocol ( Balfanz, et al. [NDSS’02] ) AB pk A pk B H(pk A ) H(pk B ) Insecure Channel Rohs, Gfeller [PervComp’04] Secure if  H(.) weak CR 80-bit for permanent 48-bit for ephemeral Authenticated Channel

11. Challenges OOB channels are low-bandwidth! One of the device might not have a receiver! Neither has a receiver and only one has a good quality transmitter  (Non-)Universality! [Usability Evalutation!] Protocols might be slow – multiple executions! Multiple devices – scalability!

12. Challenges OOB channels are low-bandwidth! One of the device might not have a receiver! One of the device might not have a receiver! Neither has a receiver and only one has a good quality transmitter Neither has a receiver and only one has a good quality transmitter  (Non-)Universality! Usability! Usability! Protocols might be slow – multiple executions! Protocols might be slow – multiple executions! Multiple devices -- scalability Multiple devices -- scalability

13. Protocol: Short Authenticated Strings (SAS) A B pk A,c A pk B,c B dAdA dBdB Secure (with prob. 1-2 -k ) Insecure Channel Authenticated Channel SAS A SAS B c A,d A  comm(pk A,R A ) R A ε {0,1} k R B ε {0,1} k c B,d B  comm(pk B,R B ) SAS A = R A R B SAS B = R A R B Accept (pk B,B) if SAS B = R A R B Accept (pk B,A) if SAS A = R A R B Vaudenay [Crypto’05] R A  open(pk A,c A,d A ) R B  open(pk B,c B,d B ) Laur et al. [eprint’05] Pasini-Vaudenay [PKC’06]

14. Challenges OOB channels are low-bandwidth! OOB channels are low-bandwidth! One of the devices might not have a receiver!  e.g., keyboard-desktop; AP-phone Neither has a receiver and only one has a good quality transmitter Neither has a receiver and only one has a good quality transmitter  (Non-)Universality! [Usability!] [Usability!] Protocols might be slow – multiple executions! Protocols might be slow – multiple executions! Multiple devices -- scalability Multiple devices -- scalability

15. Unidirectional SAS (Saxena et al. [S&P’06]) A B pk A, H(R A ) pk B, R B RARA hs(R A,R B ;pk A,pk B ) Galois MAC Success/Failure Secure (with prob. 1-2 -15 ) if  15-bit AU hs() Blinking-Lights Insecure Channel Authenticated Channel User I/O Muliple Blinking LEDs (Saxena-Uddin [MWNS’08])

16. Challenges OOB channels are low-bandwidth! OOB channels are low-bandwidth! One of the device might not have a receiver! One of the device might not have a receiver! Neither has a receiver and only one has a good quality transmitter  e.g., AP-laptop/PDA [Usability!] [Usability!] Protocols might be slow – multiple executions! Protocols might be slow – multiple executions! Multiple devices -- scalability Multiple devices -- scalability

17. Drawbacks with Prior Research Geared for specific pairing scenario None are universally applicable  Require hardware and interfaces not common across all devices User doesn’t know what method to use on what pair of devices  confusion! We believe: universality would immensely improve security as well as usability

18. A Universal Pairing Method Prasad-Saxena [ACNS’08] Use existing SAS protocols The strings transmitted by both devices over physical channel should be  the same, if everything is fine  different, if there is an attack/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

19. Is This Usable? Our test results are promising  Users can verify both good test cases and bad ones Blink-Blink the easiest  Very low errors (less than 5%)  Execution time ~22s Then, Beep-Blink  Very low errors with a learning instance (less than 5%)  Execution time ~15s Beep-Beep turns out error-prone

20. Further Improvement: Auxiliary Device Saxena et al. [SOUPS’08] Auxiliary device needs a camera and/or microphone – a smart phone Does not need to be trusted with cryptographic data Does not need to communicate with the devices A B Success/Failure

21. Further Improvement: Auxiliary Device Blink-Blink  ~14s (compared to 22s of manual scheme) Beep-Blink  Approximately takes as long as the same as manual scheme  No learning needed In both cases,  False negatives are eliminated  False positives are reduced It was preferred by most users

22. Challenges OOB channels are low-bandwidth! OOB channels are low-bandwidth! One of the device might not have a receiver! One of the device might not have a receiver! Neither has a receiver and only one has a good quality transmitter Neither has a receiver and only one has a good quality transmitter  (Non-)Universality! [Comparative Usability!] Protocols might be slow – multiple executions! Protocols might be slow – multiple executions! Multiple devices -- scalability Multiple devices -- scalability

23. Comparative Usability Study: Summary Kumar et al. [Pervasive’09] Manual Comparison  Numbers (Uzun et al. [USEC’06])  Spoken/Displayed Phrases L&C (Goodrich et al. [ICDCS’06])  Images (Random Arts, see http://www.random-art.org/) http://www.random-art.org/  Synchronized Comparison Blink-Blink and Beep-Blink BEDA (Soriente et al. [IWSSI’07]) Automated  SiB (McCune et al. [S&P’05])  Blinking Lights (Saxena et al. [S&P’06])  Audio Transfer (HAPADEP variant) (Soriente et al. [IWSSI’07]) Automated testing framework Three-phases; over a 2 month long period Surprise:  Users don’t like automated methods: handling cameras not easy

24. Device/Equipment RequirementsUser Actions Pairing MethodSending DeviceReceiving Device Phase I: SetupPhase II: ExchangePhase III: OutcomeOOB Channels Resurrecting DucklingHardware port (e.g., USB) on both and extra cable Connect cable to both devices NONE Cable Talking to StrangersIR port on bothActivate IR on both & find /align IR ports NONE IR Visual Comparison: Image, Number or Phrase Display + user-input on bothNONECompare two images, or two numbers, or two phrases Abort or accept on both devices Visual Seeing is Believing (SiB) Display + user-input Photo camera + user-output Activate photo mode on receiving device Align camera on receiving device with displayed barcode on sending device, take picture Abort or accept on sending device based receiving device decision Visual Blinking Lights LED + user-input User-output + Light detector or video camera Activate light detector or set video mode on receiving device Initiate transmittal of OOB data by sending device Abort or accept on sending device based receiving device decision Visual Loud & Clear  Display-Speaker  Speaker-Speaker User-input on both +  display on one & speaker on other, or  speaker on both NONE Compare: two vocalizations, or display with vocalization Abort or accept on both devices  Audio, or  audio + visual Button-Enabled (BEDA)  Vibrate-Button  LED-Button  Beep-Button User input +  vibration, or  LED, or  beeper User output + One button +Touch or hold both devices For each signal (display, sound or vibration) by sending device, press a button on receiving device Abort or accept on sending device based receiving device decision  Tactile, or  Visual + tactile, or  Audio + tactile Button-Enabled (BEDA)  Button-Button One button on both + user-output on oneTouch or hold both devices Simultaneously press buttons on both devices; wait a short time, repeat, until output signal NONE (unless synch. error) Tactile Copy–and-Confirm Display + user-input Keypad + user-outputNONE Enter value displayed by sending device into receiving device Abort or accept on sending device based on receiving device decision Visual Choose-and-EnterUser input on both devices NONE Select “random” value and enter it into each device NONE (unless synch. Error) Tactile Audio Pairing (HAPADEP) Speaker + user-input Microphone + user-output NONE Wait for signal from receiving device. Abort or accept on sending deviceAudio Audio/Visual Synch.  Beep-Beep  Blink-Blink  Blink-Beep User-input on both +  Beeper on each, or,  LED on each, or  Beeper on one & LED on other NONE Monitor synchronized:  beeping, or  blinking, or  beeping & blinking Abort on both devices if no synchrony  Visual, or  Audio, or  Audio + visual Smart-its-Friends, Shake-Well-Before-Use 2-axis accelerometers on both + user-output on one Hold both devicesShake/twirl devices together, until output signal NONE (unless synch. error) Tactile + motion

25. Comparative Usability Study: Time

27. Comparative Usability Study: Ease-of-Use

28. Comparative Usability Study: Preference

30. Challenges OOB channels are low-bandwidth! OOB channels are low-bandwidth! One of the device might not have a receiver! One of the device might not have a receiver! Neither has a receiver and only one has a good quality transmitter Neither has a receiver and only one has a good quality transmitter  (Non-)Universality! [Usability!] [Usability!] Protocols might be slow – multiple executions! Protocols might be slow – multiple executions! Multiple devices – scalability  Bootstrapping key pre-distribution on sensors

31. Sensor Network Initialization Saxena-Uddin [Submitted’08]

32. Sensor Network Initialization 16 sensors with three LEDs each

33. Sensor Network Initialization

35. Other open questions? Pairing using color comparison Two-user setting Group-setting Rushing User?

36. References Some of them on my publications page