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

Device-to-Device Authentication

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

A B

pkA

pkB

H(pkA)

H(pkB)

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 One of the device might not have a

receiver!receiver! Neither has a receiver and only one has Neither has a receiver and only one has

a good quality transmittera good quality transmitter (Non-)Universality!(Non-)Universality!

Usability!Usability! 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 Neither has a receiver and only one has a good quality transmittera good quality transmitter (Non-)Universality!(Non-)Universality!

[Usability!][Usability!] 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 [ICICS’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!] Multiple devices -- scalabilityMultiple 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

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 One of the device might not have a

receiver!receiver! Neither has a receiver and only one has Neither has a receiver and only one has

a good quality transmittera good quality transmitter (Non-)Universality!(Non-)Universality!

Comparative Usability! Multiple devices -- scalabilityMultiple 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 Comparison

Number Comparison “65473” =? “75853”

Phrase Comparison “Alice buys jackets” =? “John likes elephants”

Image Comparison

=?


Loud and Clear (L&C) variants Speaker-Speaker

=?

Display-Speaker

=?

John buys a

car

John buys a

car

John buys a

car

John buys a car


Audiovisual synchronization methods Beep-Blink

Blink-Blink

Button enabled (BEDA) methods LED-Button

Vibrate-Button

Button-Button

Tested Methods: Manual Transfer/Entry

Tested Methods: Automated Transfer

Seeing is Believing (SiB)

Blinking Lights

… … ….. HAPADEP Variant

Study Results: Fatal Errors

*Cases with 0% fatal errors are removed from the table

Method name Specific test case Avg. fatal error rate

Image Comparison Mismatched Images 0%

Number Comparison*First Digit Mismatch 10%

Middle Digit Mismatch 5%

Phrase Comparison*2-Word Mismatch 5%

Middle Word Mismatch 5%BEDA (Led-Button) Reject Signal 0%

BEDA (Vibrate-Button) Reject Signal 0%Loud & Clear (Display-Speaker)* First Word Mismatch 5%

Loud & Clear (Speaker-Speaker)*

2-Word Mismatch 5%First Word Mismatch 10%Last Word Mismatch 5%

Audio/Visual (Beep-Blink)*First Bit Mismatch 20%

Middle Bit Mismatch 5%

Audio/Visual (Blink-Blink)*

4-Bit Mismatch 5%First Bit Mismatch 30%

Synchrony Bit Mismatch 5%Middle Bit Mismatch 5%

Study Results: Safe ErrorsMethod name Specific test case Avg. completion

time (seconds)Avg. safe error rate

Image Comparison Matching Images 12.7 (sd*=10.7) 15%Number Comparison Matching Numbers 8.6 (sd=4.9) 0%Phrase Comparison Matching Phrases 12.7 (sd=8.0) 10%

BEDA (Led-Button) Accept Signal 49.5 (sd=27.5) 0%

BEDA (Vibrate-Button) Accept Signal 44.3 (sd=18.0) 0%

Loud & Clear (Display-Speaker) Matching Phrases 15.5 (sd=6.3) 0%

Loud & Clear (Speaker-Speaker) Matching Phrases 21.3 (sd=6.8) 0%

Blinking Lights Accepting Receving Device 28.8 (sd=10.4) 0%Seeing Is Believing Accepting Receving Device 26.9 (sd=7.5) 5%

Audio/Visual (Beep-Blink) Matching Patterns 26.3 (sd=5.3) 5%

Audio/Visual (Blink-Blink) Matching Patterns 27.8 (sd=10.3) 0%

HAPADEP Variant Accepting Receving Device 10.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 displayNumeric Comparison Phrase Comparison >= Image Comparison

one device doesn’t have a display but an audio interfaceHAPADEP (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 possibleBEDA 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 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 – scalability

Bootstrapping key pre-distribution on sensors

Sensor Network InitializationSaxena-Uddin [CANS’09]

Sensor Network Initialization

16 sensors with three LEDs each



Some open questions?

Two-user setting Group-setting Rushing User

References

Most of them on my publications page http://cis.poly.edu/~nsaxena/publications.html

Documents

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