Device to device authentication
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

Device(-to-Device) Authentication PowerPoint PPT Presentation


  • 72 Views
  • Uploaded on
  • Presentation posted in: General

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)

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Device to device authentication

Device(-to-Device) Authentication

Nitesh Saxena

Polytechnic University


The problem pairing

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

PIN-based Bluetooth Pairing


Authentication

Authentication

1

2


In security of pin based pairing

(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

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

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:


Timing of attack and user issues

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 pairing1

The Problem: “Pairing”

Authenticated: Audio, Visual, Tactile

  • Idea

  • make use of a physical channel between devices

  • with least involvement from Alice and Bob


S eeing i s b elieving mccune et al oakland 05

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


Challenges

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!


Challenges1

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


Protocol s hort a uthenticated s trings sas

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]


Challenges2

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


Unidirectional sas saxena et al s p 06

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


Challenges3

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


Drawbacks with prior research

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

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

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

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


Further improvement auxiliary device1

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


Challenges4

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


Comparative usability study summary

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


Comparative usability study time

Comparative Usability Study: Time


Comparative usability study ease of use

Comparative Usability Study: Ease-of-Use


Comparative usability study preference

Comparative Usability Study: Preference


Challenges5

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


Sensor network initialization

Sensor Network Initialization

Saxena-Uddin [Submitted’08]


Sensor network initialization1

Sensor Network Initialization

16 sensors with three LEDs each


Sensor network initialization2

Sensor Network Initialization


Sensor network initialization3

Sensor Network Initialization


Other open questions

Other open questions?

  • Pairing using color comparison

  • Two-user setting

  • Group-setting

  • Rushing User?


References

References

  • Some of them on my publications page


  • Login