1 / 36

Device(-to-Device) Authentication

Device(-to-Device) Authentication. Nitesh Saxena Polytechnic University. 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)

chelsey
Download Presentation

Device(-to-Device) Authentication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  24. Comparative Usability Study: Time

  25. Comparative Usability Study: Ease-of-Use

  26. Comparative Usability Study: Preference

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

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

  29. Sensor Network Initialization 16 sensors with three LEDs each

  30. Sensor Network Initialization

  31. Sensor Network Initialization

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

  33. References • Some of them on my publications page

More Related