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

Device(-to-Device) Authentication

Nitesh SaxenaNitesh SaxenaPolytechnic 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)

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

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)

4 1.294

5 12.915

6 129.657

7 1315.332

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)

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

A B

pkA

pkB

H(pkA)

H(pkB)

Insecure Channel

Rohs, Gfeller [PervComp’04]

Secure if H(.) weak CR

80-bit for permanent 48-bit for ephemeral

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 Neither has a receiver and only one has a

good quality transmittergood quality transmitter (Non-)Universality!(Non-)Universality!

Usability!Usability! Protocols might be slow – multiple executions!Protocols might be slow – multiple executions! Multiple devices -- scalabilityMultiple devices -- scalability

Protocol: Short Authenticated Strings (SAS)

A B

pkA,cA

pkB,cB

dA

dB

Secure (with prob. 1-2-k )

Insecure Channel


SASA

SASB

cA,dA comm(pkA,RA)

RA ε {0,1}k

RB ε {0,1}k

cB,dB comm(pkB,RB)

SASA = RA RB

SASB = RA RB

Accept (pkB,B) if

SASB = RA RB

Accept (pkB,A) if

SASA = RA RB

Vaudenay [Crypto’05]

RA open(pkA,cA,dA)

RB open(pkB,cB,dB)

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 Neither has a receiver and only one has a


[Usability!][Usability!] Protocols might be slow – multiple executions!Protocols might be slow – multiple executions! Multiple devices -- scalabilityMultiple devices -- scalability

Unidirectional SAS (Saxena et al. [S&P’06])

A B

pkA , H(RA)

pkB, RB

RA

hs(RA,RB;pkA,pkB)Galois MAC

Success/Failure

Secure (with prob. 1-2-15) if 15-bit AU hs()

Blinking-LightsInsecure Channel


User I/O

Muliple Blinking LEDs (Saxena-Uddin [MWNS’08])

Challenges

OOB channels are low-bandwidth!OOB channels are low-bandwidth! One of the device might not have a One of the device might not have a

receiver!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 Protocols might be slow – multiple

executions!executions! Multiple devices -- scalabilityMultiple devices -- scalability

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

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

S

ucce

ss/F

ailu

re

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 Neither has a receiver and only one has a


[Comparative Usability!] Protocols might be slow – multiple executions!Protocols might be slow – multiple executions! Multiple devices -- scalabilityMultiple devices -- scalability

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

Device/Equipment Requirements 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

Connect cable to both devices

NONE NONE Cable

Talking to Strangers 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 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 LightsLED + 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


Visual

Loud & ClearDisplay-SpeakerSpeaker-Speaker

User-input on both +display on one & speaker on other, orspeaker on both

NONECompare: two vocalizations, or display with vocalization

Abort or accept on both devices

Audio, or audio + visual

Button-Enabled (BEDA) Vibrate-ButtonLED-ButtonBeep-Button

User input +vibration , orLED, 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


Tactile, orVisual + tactile, orAudio + tactile

Button-Enabled (BEDA) Button-Button

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

Copy–and-ConfirmDisplay + 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 devicesNONE

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-BeepBlink-BlinkBlink-Beep

User-input on both +Beeper on each , or, LED on each, orBeeper on one & LED on other

NONEMonitor synchronized:beeping, or blinking, or beeping & blinking

Abort on both devices if no synchrony

Visual, or Audio, orAudio + visual

Smart-its-Friends, Shake-Well-Before-Use

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

Comparative Usability Study: Time

Comparative Usability Study: Ease-of-Use

Comparative Usability Study: Preference

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 Neither has a receiver and only one has a


[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 InitializationSaxena-Uddin [Submitted’08]

Sensor Network Initialization

16 sensors with three LEDs each



Other open questions?

Pairing using color comparison Two-user setting Group-setting Rushing User?

References

Some of them on my publications page

Documents

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