Device(-to-Device) Authentication

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 E22, E21, E1 • 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 Kinit, RAND_B \xor Kinit, 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:

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” Authenticated: Audio, Visual, Tactile • Idea • make use of a physical channel between devices • with least involvement from Alice and Bob

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

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! • Neither has a receiver and only one has a good quality transmitter • (Non-)Universality! • Usability! • Protocols might be slow – multiple executions! • Multiple devices -- scalability

13. Secure (with prob. 1-2-k) pkA,cA pkB,cB dA Protocol: Short Authenticated Strings (SAS) Vaudenay [Crypto’05] Insecure Channel Authenticated Channel RAε {0,1}k cA,dA comm(pkA,RA) RBε {0,1}k cB,dB comm(pkB,RB) RA open(pkA,cA,dA) B dB A RB open(pkB,cB,dB) SASA SASA = RA RB SASB SASB = RA RB Accept (pkB,A) if SASA = RA RB Accept (pkB,B) if SASB = RA RB Laur et al. [eprint’05] Pasini-Vaudenay [PKC’06]

14. Challenges • 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 • (Non-)Universality! • [Usability!] • Protocols might be slow – multiple executions! • Multiple devices -- scalability

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

16. 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 • e.g., AP-laptop/PDA • [Usability!] • Protocols might be slow – multiple executions! • 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. Success/Failure 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

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! • One of the device might not have a receiver! • Neither has a receiver and only one has a good quality transmitter • (Non-)Universality! • [Comparative Usability!] • Protocols might be slow – multiple executions! • 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/) • 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

25. Comparative Usability Study: Time

27. Comparative Usability Study: Ease-of-Use

28. Comparative Usability Study: Preference

30. 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!] • 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

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