Device-to-Device Authentication Nitesh Saxena Polytechnic Institue of NYU

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

PIN-based Bluetooth Pairing

Authentication 1 2

(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]

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

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)

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) Yet another problem: hard-coded PINs

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

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 Authenticated Channel

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!

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! Multiple devices -- scalability Multiple devices -- scalability

Protocol: Short Authenticated Strings (SAS) A B pk A,c A pk B,c B dAdA dBdB Secure (with prob 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]

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!] Multiple devices -- scalability Multiple devices -- scalability

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 ) if  15-bit AU hs() Blinking-Lights Insecure Channel Authenticated Channel User I/O Muliple Blinking LEDs (Saxena-Uddin [ICICS’08])

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!] Multiple devices -- scalability Multiple devices -- scalability

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

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

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

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

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! Multiple devices -- scalability Multiple devices -- scalability

Selected Methods (Kumar et al. [Percom’09; PMC’09]) Manual Comparison  Numbers (Uzun et al. [USEC’06])  Spoken/Displayed Phrases L&C (Goodrich et al. [ICDCS’06])  Images (Random Arts) (Perrig-Song [Cryptec’99])  Synchronized Comparison (Prasad-Saxena [ACNS’08]) Manual Transfer  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) (Soriente et al. [ISC’08])

Tested Methods: Manual Compariso n Number Comparison “65473” =? “75853” Phrase Comparison “Alice buys jackets” =? “John likes elephants” Image Comparison =?

Tested Methods: Manual Compariso n Loud and Clear (L&C) variants  Speaker-Speaker =?  Display-Speaker =? John buys a car

Tested Methods: Manual Compariso n Audiovisual synchronization methods  Beep-Blink  Blink-Blink

Button enabled (BEDA) methods  LED-Button  Vibrate-Button  Button-Button Tested Methods: Manual Transfer/E ntry

Tested Methods: Automated Transf er Seeing is Believing (SiB) Blinking Lights … … ….. HAPADEP Variant

Study Results: Fatal Errors *Cases with 0% fatal errors are removed from the table Method nameSpecific test case Avg. fatal error rate Image ComparisonMismatched Images0% Number Comparison* First Digit Mismatch10% Middle Digit Mismatch5% Phrase Comparison* 2-Word Mismatch5% Middle Word Mismatch5% BEDA (Led-Button)Reject Signal0% BEDA (Vibrate-Button)Reject Signal0% Loud & Clear (Display-Speaker)*First Word Mismatch5% Loud & Clear (Speaker- Speaker)* 2-Word Mismatch5% First Word Mismatch10% Last Word Mismatch5% Audio/Visual (Beep-Blink)* First Bit Mismatch20% Middle Bit Mismatch5% Audio/Visual (Blink-Blink)* 4-Bit Mismatch5% First Bit Mismatch30% Synchrony Bit Mismatch5% Middle Bit Mismatch5%

Study Results: Safe Errors Method nameSpecific test case Avg. completion time (seconds) Avg. safe error rate Image ComparisonMatching Images12.7 (sd*=10.7)15% Number ComparisonMatching Numbers8.6 (sd=4.9)0% Phrase ComparisonMatching Phrases12.7 (sd=8.0)10% BEDA (Led-Button) Accept Signal49.5 (sd=27.5)0% BEDA (Vibrate-Button) Accept Signal44.3 (sd=18.0)0% Loud & Clear (Display-Speaker) Matching Phrases15.5 (sd=6.3)0% Loud & Clear (Speaker-Speaker) Matching Phrases21.3 (sd=6.8)0% Blinking LightsAccepting Receving Device28.8 (sd=10.4)0% Seeing Is BelievingAccepting Receving Device26.9 (sd=7.5)5% Audio/Visual (Beep-Blink) Matching Patterns26.3 (sd=5.3)5% Audio/Visual (Blink-Blink) Matching Patterns27.8 (sd=10.3)0% HAPADEP VariantAccepting Receving Device10.8 (sd=2.6)5% BEDA (Button-Button) Normal Protocol Behavior Until Pairing Is Successful 31.9 (sd=32.1)N/A *Estimated Standard Deviation from the sample

Completion Timing

Ease of Use Ratings

Cluster Analysis: All measures together

Conclusions from the Study Users did not like camera-based methods Best overall choices when:  both devices have a display Numeric Comparison Phrase Comparison >= Image Comparison  one device doesn’t have a display but an audio interface HAPADEP (if microphone is available on one, and speaker on the other) L&C Display-Speaker (if one has a display and the other has a speaker.  device(s) are highly interface constrained BEDA Vibrate-Button if possible BEDA LED-Button otherwise

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

Sensor Network Initialization Saxena-Uddin [CANS’09]

Sensor Network Initialization 16 sensors with three LEDs each

Sensor Network Initialization

Some open questions? Two-user setting Group-setting Rushing User

References Most of them on my publications page