Device(-to-Device) Authentication

1
Device(-to-Device) Authentication

• Nitesh Saxena
• Polytechnic University

2
The Problem Pairing

• How to bootstrap secure communication between
  Alices and Bobs 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 Mobisys05

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(10L), 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)
4 1.294
5 12.915
6 129.657
7 1315.332
8
Timing of Attack and User Issues

• ASCII PINs O(90L), 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
Seeing-is-Believing (McCune et al. Oakland05)

• Protocol (Balfanz, et al. NDSS02)

Insecure Channel
Authenticated Channel
A
B
Rohs, Gfeller PervComp04
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
Protocol Short Authenticated Strings (SAS)
Vaudenay Crypto05
Insecure Channel
Authenticated Channel
RA e 0,1k
cA,dA ? comm(pkA,RA)
RB e 0,1k
cB,dB ? comm(pkB,RB)
RA ? open(pkA,cA,dA)
B
A
dB
RB ? open(pkB,cB,dB)
SASA
SASA RA RB
SASB
SASB RA RB
Accept (pkB,B) if SASB RA RB
Accept (pkB,A) if SASA RA RB
Laur et al. eprint05
Pasini-Vaudenay PKC06
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
Unidirectional SAS (Saxena et al. SP06)

• Blinking-Lights

Insecure Channel
Authenticated Channel
User I/O
A
B
Galois MAC
Muliple Blinking LEDs (Saxena-Uddin MWNS08)
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 doesnt 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 ACNS08
• 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. SOUPS08
• 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. Pervasive09
• Manual Comparison
• Numbers (Uzun et al. USEC06)
• Spoken/Displayed Phrases
• LC (Goodrich et al. ICDCS06)
• Images (Random Arts, see http//www.random-art.org
  /)
• Synchronized Comparison
• Blink-Blink and Beep-Blink
• BEDA (Soriente et al. IWSSI07)
• Automated
• SiB (McCune et al. SP05)
• Blinking Lights (Saxena et al. SP06)
• Audio Transfer (HAPADEP variant) (Soriente et al.
  IWSSI07)
• Automated testing framework
• Three-phases over a 2 month long period
• Surprise
• Users dont like automated methods handling
  cameras not easy

24
Device/Equipment Requirements Device/Equipment Requirements User Actions User Actions User Actions
Pairing Method Sending Device Receiving Device Phase I Setup Phase II Exchange Phase III Outcome OOB Channels
Resurrecting Duckling Hardware port (e.g., USB) on both and extra cable Hardware port (e.g., USB) on both and extra cable Connect cable to both devices NONE NONE Cable
Talking to Strangers IR port on both IR port on both Activate IR on both find /align IR ports NONE NONE IR
Visual Comparison Image, Number or Phrase Display user-input on both Display user-input on both NONE Compare 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 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 one One button on both user-output on one Touch or hold both devices Simultaneously press buttons on both devices wait a short time, repeat, until output signal NONE (unless synch. error) Tactile
Copyand-Confirm Display user-input Keypad user-output NONE Enter value displayed by sending device into receiving device Abort or accept on sending device based on receiving device decision Visual
Choose-and-Enter User input on both devices User 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 device Audio
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 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 2-axis accelerometers on both user-output on one Hold both devices Shake/twirl devices together, until output signal NONE (unless synch. error) Tactile motion
25
Comparative Usability Study Time
26
(No Transcript)
27
Comparative Usability Study Ease-of-Use
28
Comparative Usability Study Preference
29
(No Transcript)
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 Submitted08
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