The problem. Initializing Security Associations for Personal Devices. Outline. Setting up the first connection

Size: px

Start display at page:

Download "The problem. Initializing Security Associations for Personal Devices. Outline. Setting up the first connection"

Edmund Greer
5 years ago
Views:

1 Initializing Security ssociations for Personal Devices N. sokan Nokia Research Center, Helsinki TKK - Helsinki University of Technology Outline The problem: What is First Connect and why is it hard to secure? Proposed solutions: recent efforts addressing this issue in research literature standard specifications Usability analysis and some open issues ZISC workshop on Wireless Security, September Latest version of the presentation available at ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Setting up the first connection The problem First Connect: setting up contexts for subsequent communication. Typically for proximity communications between personal devices, e.g.: Pairing a luetooth phone and headset Enrolling a Phone or PC in the home WLN More instances to come: Wireless US, WiMedia Problem: Secure First Connect for personal devices Initializing security associations (as securely as possible) No security infrastructure (no PKI, key servers etc.) Ordinary non-expert users Cost-sensitive commodity devices ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

Current mechanisms are not intuitive and not very

5 2006,2007 Nokia N sokan, September 2007 6

usability measures damage security Naïve security

to retrieve and use session keys from a mobile phone

users have to enter 16-character passcodes More

2 Current mechanisms are not intuitive and not very secure SSID? WP? Passcode? ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Naïve usability measures damage security Naïve security measures damage usability Car kits allow a car phone to retrieve and use session keys from a mobile phone smartcard Car kit requires higher level of security users have to enter 16-character passcodes More secure = Harder to use? ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

3 Wanted: Secure, intuitive, inexpensive first connect Two (initial) problems to solve Peer discovery: finding the other device uthenticated key establishment: setting up a security association Key establishment protocols for first connect (1) We will update this chart as we go along Key establishment Key transport via OO channel Key agreement ssumption: Peer devices are physically identifiable Symmetric crypto only symmetric crypto uthenticated uthenticated Short keys vulnerable to passive attackers Secure against passive attackers ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 uthenticating key agreement Proposed solutions: research literature Use an auxiliary channel to transfer information needed for authentication Two possibilities for realizing secure channel User assistance Out-of-band secure channels: physical communication channel E.g., Near Field Communication, infrared, ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

4 uthenticating key agreement: user-assisted key agreement: e.g., exchange PK, PK uthentication User bandwidth is low (4 to 6 digits) Directionality depends on available hardware (1-way or 2-way) Security properties (integrity-only, or integrity+secrecy) Insecure in-band communication Secure user input/output User as the secure channel Peer discovery by user conditioning : introduce a special first connect mode E.g., Press a button to put device into the special mode Demonstrative/indexical identification uthentication by entering a short secret Passkey, or Comparing short non-secret check codes (aka short authentication string ) Short key/code should not hamper security Standard security against offline attacks Good enough security against active man-in-the-middle ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 uthentication using a short passkey: a first attempt Man-in-the-middle in authentication using a short passkey P P P P PK PK PK C1 PK PK C2 PK h MC( PK PK, P) h h MC( PK PK, P) PK C2 h C Figure out P by trial-and-error h C2 MC( PK PK C2, P) PKC1 h MC( PK PK, P) h h MC( PK PK, P) h MC( PK PK, P) h C2 MC( PK PK, P) h C2 h C1 h h C1 MC( PK PK, P) P is a short passkey (e.g., 4 digits) MC() is a message authentication code: e.g., HMC-SH1 ut a man-in-the-middle can easily defeat this protocol! Guess a value x for P; calculate h x = MC( PK PK C2, X); Check h h x If P is a n-digit PIN, attacker needs at most 10 n guesses; Each guess costs one MC calculation typical modern PC can calculate MCs in 1 second ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

5 uthentication using interlocking short passkeys uthentication using interlocking short passkeys P Executed once P P Executed once P Choose long random R i Choose long random R i Choose long random R i Choose long random R i key agreement: exchange PK, PK key agreement: exchange PK, PK Calculate commitment h h(, PK PK, Pi, R i ) Send commitments h h Calculate commitment h h(, PK PK, Pi, R i ) Calculate commitment h h(, PK PK, Pi, R i ) Send commitments h h Calculate commitment h h(, PK PK, Pi, R i ) Verify commitment h h(, PK PK, Pi, R i ) ,2007 Nokia N sokan, September 2007 Open commitments R i R i Verify commitment h h(, PK PK, Pi, R i ) One-time passkey P is split into k parts (k > 1): next 4-round exchange repeated k times h() is a hiding commitment; in practice SH-256 Up to 2 -(l-1) ( unconditional ) security against man-in-the-middle (l is the length of P) Verify commitment h h(, PK PK, Pi, R i ) ,2007 Nokia N sokan, September 2007 Open commitments R i R i Verify commitment h h(, PK PK, Pi, R i ) One-time passkey P is split into k parts (k > 1): next 4-round exchange repeated k times h() is a hiding commitment; in practice SH-256 Up to 2 -(l-1) ( unconditional ) security against man-in-the-middle (l is the length of P) Originally proposed by Jan-Ove Larsson [2001]: essentially multi-round MN III uthentication by comparing short strings: a first attempt uthentication by comparing short strings Choose long random R key agreement: exchange PK, PK Calculate commitment h h(, R ) key agreement: exchange PK, PK Send commitments h Choose long random R R v H(,,PK PK ) v H(,,PK PK ) v v v H(,,PK PK,R,R ) Open commitment R v v Verify commitment h h(, R ) bort on mismatch v H(,,PK PK,R,R ) v and v are short strings (e.g., 4 digits), User approves acceptance if v and v match s before, a man-in-the-middle can easily defeat this protocol ,2007 Nokia N sokan, September 2007 User approves acceptance if v and v match 2 -l ( unconditional ) security against man-in-the-middle (l is the length of v and v ) h() is a hiding commitment; in practice SH-256 H() is a mixing function; in practice SH-256 output truncated ,2007 Nokia N sokan, September 2007

6 uthentication by comparing short strings uthentication by comparing short strings Choose long random R Initially due to Zimmerman in PGPfone biometric authentication [1996] Calculate commitment h h(, R ) key agreement: exchange PK, PK Send commitments h Choose long random R Recent variations: reuse of public keys, formal analyses Gehrmann et al, Čagalj et al, Vaudenay et al, Pasini et al, Laur et al, R Open commitment R Verify commitment h h(, R ) v H(,,PK PK,R,R ) v v bort on mismatch v H(,,PK PK,R,R ) User approves acceptance if v and v match 2 -l ( unconditional ) security against man-in-the-middle (l is the length of v and v ) h() is a hiding commitment; in practice SH-256 MN IV by Laur, sokan, Nyberg [ICR report] Laur, Nyberg [CNS 2006] ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Key establishment protocols for first connect (2) Key establishment Problems with user-as-secure-channel Relies on availability of specific hardware (display, keypad, buttons, ) Key transport via OO channel Key agreement Needs a negotiation protocol Symmetric crypto only symmetric crypto What about usability? uthenticated uthenticated uthentication by integrity checking uthentication by shared secret Short string comparison ,2007 User-assisted Nokia N sokan, September 2007 User-assisted ,2007 Nokia N sokan, September 2007

Out-of-band secure channel Idea: use a physically secure channel to transfer security critical information Minimize user involvement better usability uthenticating key agreement:

can be detected) Sometimes secrecy as well Insecure in-band communication Secure out-of-band communication Different out-of-band channels have different andwidth Directionality

7 Out-of-band secure channel Idea: use a physically secure channel to transfer security critical information Minimize user involvement better usability uthenticating key agreement: out-of-band channel key agreement: e.g., exchange PK, PK Peer discovery is intuitive uthentication Demonstrative/indexical identification Channel must have certain security properties integrity (tampering with messages can be detected) Sometimes secrecy as well Insecure in-band communication Secure out-of-band communication Different out-of-band channels have different andwidth Directionality (1-way or 2-way) Security properties (integrity-only, or integrity+secrecy) ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 What out-of-band channels can you think of? Seeing Is elieving Near Field Communication udio touch to connect h h(pk ) key agreement: exchange PK, PK h McCune et al, [IEEE S&P 2005] h h(pk ) h Visual ody-area communication Rohs, Gfeller [PervComp 04] touch to connect ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

8 Drawbacks of Si Mutual authentication with one-way visual channel 1. Mutual authentication requires that both devices have cameras and switch roles key agreement: exchange PK, PK Slow and difficult for the user! Potential solution: one-way visual channel + user confirmation h h(pk PK ) h 2. Not all devices have big enough displays to show two-dimensional bar codes Typically these constrained devices do not have cameras either h h(pk PK ) bort on mismatch Problem: secure first connect for constrained devices with minimal additional hardware? ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Supporting display constrained devices Use a short authentication string protocol like MN IV Supporting display constrained devices Use a short authentication string protocol like MN IV Choose long random R key agreement: exchange PK, PK Choose long random R Choose long random R key agreement: exchange PK, PK Choose long random R h h(, R ) h h h(, R ) h R R R h h(, R ) bort on mismatch R h h(, R ) bort on mismatch v H(,,PK PK, R, R ) v v H(,,PK PK, R, R ) v H(,,PK PK, R, R ) v v H(,,PK PK, R, R ) Check v v show Check v v show bort if v v bort if v v ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Saxena, Ekberg, Kostiainen, sokan [IEEE S&P 2006]

Supporting display constrained devices Key establishment protocols for first connect (3) Pairing phone and laptop with LED Pairing two phones Key transport via OO channel Key establishment Key

Hybrid/one-way OO Hardware needed: Single LED (cheap) Key commitments via OO channel Short string comparison Video camera (common on smartphones) 33 2006,2007 Nokia N sokan, September 2007 Saxena,

specific (possibly new) hardware interfaces Deployability Universally deployed auxiliary channel needed Otherwise how to discover common auxiliary channels between the devices?

In-band integrity checking ssumption: genuine device emits energy during transmission; a distant attacker cannot easily drown this out I-codes by Čagalj et al Common radio environment ssumption:

9 Supporting display constrained devices Key establishment protocols for first connect (3) Pairing phone and laptop with LED Pairing two phones Key transport via OO channel Key establishment Key agreement Symmetric crypto only symmetric crypto uthenticated uthenticated Suitable for access points, wireless headsets uthentication by integrity checking uthentication by shared secret Hybrid/one-way OO Hardware needed: Single LED (cheap) Key commitments via OO channel Short string comparison Video camera (common on smartphones) ,2007 Nokia N sokan, September 2007 Saxena, Ekberg, Kostiainen, sokan [IEEE S&P 2006] ,2007 User-assisted Nokia N sokan, via September OO 2007 channel User-assisted via OO channel Problems with out-of-band channels Cost vailability of specific (possibly new) hardware interfaces Deployability Universally deployed auxiliary channel needed Otherwise how to discover common auxiliary channels between the devices? Leave-it-to-the-user: visible well-known logos Negotiation protocol Can we use the radio interface itself for authentication? In-band integrity checking ssumption: genuine device emits energy during transmission; a distant attacker cannot easily drown this out I-codes by Čagalj et al Common radio environment ssumption: genuine devices hear the same radio signals; a distant attacker likely hears something different migo by Varshavsky et al Spatial indistinguishability ssumption: a distant attacker cannot tell which device is transmitting Shake-them-up by Castelluccia et al ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

10 Integrity protection in-band: I-Codes Key establishment protocols for first connect (2) Message Encoded message Transmitted signal Manchester coding On-off keying Recipient measures the presence/absence of energy (1-bit/0-bit) ttacker cannot change 1 0 Issues Modifications to lower layers in the communication stack No genuine radio interference Key establishment Key transport via OO channel Key agreement Symmetric crypto only symmetric crypto uthenticated uthenticated uthentication by integrity checking uthentication by shared secret Hybrid/one-way OO Key commitments via OO channel Short string comparison Čagalj, Čapkun, Rengaswamy, Tsigkogiannis, Srivastava, Hubaux [IEEE S&P 2006] ,2007 Nokia N sokan, September ,2007 User-assisted Nokia N sokan, via September OO 2007 channel User-assisted via OO channel Key establishment protocols for first connect (3) Key establishment uthenticating key agreement: secret extraction from common environment key agreement: e.g., exchange PK, PK Key transport via OO channel Key agreement Symmetric crypto only symmetric crypto S S uthenticated uthenticated Use S and S for authentication uthentication by integrity checking uthentication by shared secret Key commitments Short string comparison via unspoofable channel ,2007 User-assisted Nokia N sokan, via unspoofable September 2007 channel User-assisted via OO channel Hybrid/one-way OO Sensing common private environment Measure some environmental features For co-located (in space and time) sensors measurements should be almost identical For anyone else, measurement must be unpredictable Radio signal strength [Varshavsky, Scanneli, LaMarca, de Lara, HotMobile 2007, UICOMP 2007] ccelerometer readings [Mayrhofer and Gellersen, Pervasive 2007] ,2007 Nokia N sokan, September 2007

11 uthentication using interlocking extracted secrets uthentication using interlocking extracted secrets key agreement: exchange PK, PK key agreement: exchange PK, PK Choose long random R S S Choose long random R Choose long random R S S Choose long random R Calculate commitment h h(, PK PK, S, R ) Send commitments ready h h ready Calculate commitment h h(, PK PK, S, R ) Calculate commitment h h(, PK PK, S, R ) Send commitments ready h h ready Calculate commitment h h(, PK PK, S, R ) continue continue continue continue Open commitments S, R S, R Verify commitment h h(, PK PK, S, R ) Check if S matches S h() is a hiding commitment; in practice SH ,2007 Nokia N sokan, September 2007 Verify commitment h h(, PK PK, S, R ) Check if S matches S Open commitments S, R S, R Verify commitment Verify commitment h h(, PK PK, S, R ) h h(, PK PK, S, R ) Check if S matches S Check if S matches S h() is a hiding commitment; in practice SH-256 pplication of MNIII by Gehrmann, Nyberg, Mitchell [RS Cryptobytes 2004] ,2007 Nokia N sokan, September 2007 Issues with secret extraction Key establishment protocols for first connect (3) User involvement re the assumptions valid? Key transport via OO channel Key establishment Key agreement If a long shared secret can be extracted, key agreement may not be necessary Symmetric crypto only symmetric crypto uthenticated uthenticated uthentication by integrity checking uthentication by shared secret Hybrid/one-way OO Key commitments via unspoofable channel Short string comparison ,2007 Nokia N sokan, September ,2007 User-assisted Nokia N sokan, via unspoofable September 2007 channel User-assisted via OO channel

12 Key establishment protocols for first connect (4) Key establishment Key establishment protocols for first connect (5) Key establishment Key transport via OO channel Key agreement Key extraction from shared environment P1: Key transport via OO channel Key agreement P12: Key extraction from shared environment Symmetric crypto only symmetric crypto Symmetric crypto only symmetric crypto uthenticated uthenticated P2: uthenticated P3: uthenticated P11: uthentication by integrity checking uthentication by shared secret Hybrid/one-way OO uthentication by integrity checking uthentication by shared secret P10: Hybrid/one-way OO Key commitments via unspoofable channel Short string comparison P4: Key commitments via unspoofable channel Short string comparison ,2007 User-assisted Nokia N sokan, via unspoofable September 2007 channel User-assisted via OO channel Secret extraction from shared environment 46 P5: 2006,2007 User-assisted Nokia N P6: sokan, via September unspoofable 2007 channel P7: User-assisted P8: via OO channel P9: Secret extraction from shared environment Emerging standards for first connect luetooth (released July 2007) Just works, 2-way NFC, Comparison of short check strings, 6-digit passkey (20 rounds), NFC tags P11, P4, P5, P7, P10 Proposed solutions: emerging standards WiFi lliance Protected Setup (released January 2007) Flash drives, Push button, 2-way NFC, short passkey (2 rounds), NFC tags P1, P11, P4, P7, P10 lso Windows Connect Now: P1, P7 (released Summer 2006) Wireless US ssociation Models (released early 2006) US cable, Comparison of short check strings P1, P5 Others in the works ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Suomalainen, Valkonen, sokan [ESS 2007]

13 Key establishment in luetooth pairing luetooth Secure Simple pairing Key establishment is based on symmetric-key algorithms uthentication of key establishment based on a PIN usually short, for usability ll input to key establishment except PIN is visible to passive eavesdroppers When short PINs are used, passive attacker can mount a dictionary attack Can recover PINs, encryption and authentication keys: 4 digit PINs in a few seconds Needs to record messages exchanged using pairing ut an active attacker can force re-pairing Objectives Make pairing easier for the end user Improve its security Security goals Strong security against passive attackers Good-enough security against active attackers ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Easier device discovery Protection mechanisms Out-of-band E.g., T device addresses exchanged via NFC No need for luetooth Inquiry User conditioning Devices participate in pairing only in response to user action Passive eavesdroppers: Diffie-Hellman key agreement ctive attackers: uthentication of key agreement Multiple options for authenticating: association models ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

14 ssociation Models (1/2) ssociation Models (2/2) Out-of-band channel User touches one device or its tag with another Commitments to public keys and secret passkeys exchanged via out-of-band Numeric comparison User compares 6-digit numbers displayed by each device indicates if they are the same or not Passkey entry One device shows a 6-digit number; user types it into the other device Just Works No authentication (but still secure against passive attackers) Choice of model depends on I/O capabilities of devices ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 T: luetooth Phases in Stage 1 Protocol for numeric comparison Security Establishment uthentication Initiating Device Step 1: Same for all protocols Steps 2-8: Protocol dependent Steps 9-11: Same for all protocols Step 12: Same for all protocols Step 13: Same for all protocols Non-initiating Device Public Key Exchange uthentication Stage 1 uthentication Stage 2 Link Key Calculation Encryption Initiating Device 2a. Select random Na 3a. Set ra and rb to 0 Non-initiating Device uthentication Stage 1: NumericComparison 2b. Select random Nb 3b. Set rb and ra to 0 3c. Compute commitment: Cb=f1(PKb,PKa, Nb, 0) Send commitments 4. Cb 5. Na Open commitment 6. Nb 6a. check if Cb=f1(PKb,PKa, Nb, 0) If check fails, abort Va and Vb are 6 digit numbers to be displayed on each side (for no-display devices numbers are NOT displayed) 7a. Va=g(PKa,PKb,Na,Nb) 7b. Vb=g(PKa,PKb,Na,Nb) Main idea must choose Na before knowing Nb must choose Nb before knowing Na ttacker cannot control any input to g() ased on MN IV (6-digit checksum) ctive attacker has 2-20 chance of succeeding Not dependent on his computational resources Proceed if user confirms ok 8. USER checks if Va=Vb and confirms on each end (for no-display devices user confirms ok ) Proceed if user confirms ok ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

15 Stage 1 Protocol for out-of-band authentication Stage 1 Protocol for passkey entry If OO communication is 2- way, authentication takes place in steps 5a and 5b If OO communication is one-way, one direction of authentication postponed to stage 2 Send commitments Open commitments Main idea In each round, each party demonstrates knowledge of 1-bit of secret passkey ased on multi-round MN III 6 digit passkey, 20 rounds ctive attacker has 2-19 chance of succeeding 50% chance of getting each bit right Not dependent on his computational resources Passkey must not be reused ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Stage 2 Protocol OO Capability Mapping to uthentication Stage 1 Primarily for key confirmation When OO is 1-way, Ea (or Eb) serves as proof-of-knowledge of secret rb (or ra) Device Device Has not received remote OO authentication data Has received remote OO authentication data Has not received remote OO authentication data Use the IO capability mapping table Use OO association with ra from OO rb = 0 Has received remote OO authentication table Use OO association with ra = 0 rb from OO Use OO association with ra from OO rb from OO ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

16 Mapping I/O capabilities to association models Cryptographic algorithms in Simple Pairing Key agreement uses elliptic curve Diffie-Hellman Initiator Responder DisplayOnly DisplayYesNo KeyboardOnly DisplayOnly Numeric Comparison with automatic confirmation on both devices. Numeric Comparison with automatic confirmation on device only. Passkey Entry: Initiator Display, Responder Input. DisplayYesNo Numeric Comparison with automatic confirmation on device only. Numeric Comparison: oth Display, oth Confirm. Passkey Entry: Initiator Display, Responder Input. KeyboardOnly Passkey Entry: Responder Display, Initiator Input. Passkey Entry: Responder Display, Initiator Input. Passkey Entry: Initiator and Responder Input NoInputNoOutput Numeric Comparison with automatic confirmation on both devices. Numeric Comparison with automatic confirmation on device only. Numeric Comparison with automatic confirmation on both devices. FIPS P-192 curve Security level thought to be comparable to 1024-bit RS or 80-bit symmetric key algorithms Reasons for choosing ECDH over DH in MODP groups Message sizes are smaller Time, memory use, and code footprint are comparable or better ctual performance figures depends on platform. See for some sample figures SH256 is the building block for commitment and MC functions NoInputNoOutput Numeric Comparison with automatic confirmation on both devices. Numeric Comparison with automatic confirmation on device only. Numeric Comparison with automatic confirmation on both devices. Numeric Comparison with automatic confirmation on both devices. f1(), f2(), f3() are HMC-SH256 truncated to 128 bits (MSs) g() is SH-256 truncated to 32 bits (LS); encoded as 6 digits uthenticated ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Summary WiFi Protected Setup (WPS) luetooth Simple Pairing is intended to improve usability and security Registrar is the controller of the WiFi network Easier device discovery Strong security against passive eavesdroppers (EC DH key agreement) Good enough (1-in-a-million success probability) security against active attackers Part of luetooth 2.1 specification (July 2007) Enrollee E Registrar M ccess Point Enrollee and Registrar perform key agreement Three types of authentication for key agreement Push utton : Device Password Out-of-band: Flash drive or NFC Resulting key is used for Transporting the actual WLN key ( ConfigData in next slides) Long device password for future device management ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

17 WPS Registration Protocol WPS Registration Protocol: the essentials Enrollee DevicePassword DevicePassword Registrar Choose 128-bit random ES-1, ES-2 Compute commitments E-Hash1 HMC uthkey (E-S1 PSK1 PK E PK R ) E-Hash2 HMC uthkey (E-S2 PSK2 PK E PK R ) Verify commitments R-Hash1 HMC uthkey (R-S1 PSK1 PK E PK R ) M 1 and M 2 : exchange PK E, PK R Choose 128-bit random ES-1, ES-2 Compute commitments Send commitments M E-Hash1 HMC uthkey (E-S1 PSK1 PK E PK R ) 3 = E-Hash1 E-Hash2 E-Hash2 HMC uthkey (E-S2 PSK2 PK E PK R ) M 4 = R-Hash1 R-Hash2 ENC KeyWrapKey (R-S1) Open commitments M 5 = ENC KeyWrapKey (E-S1) R-Hash2 HMC uthkey (R-S2 PSK2 PK E PK R ) M 6 = ENC KeyWrapKey (R-S2) M 7 = ENC KeyWrapKey (E-S2) M 8 = ENC KeyWrapKey (ConfigData) Verify commitments E-Hash1 HMC uthkey (E-S1 PSK1 PK E PK R ) E-Hash2 HMC uthkey (E-S2 PSK2 PK E PK R ) PSKi first 128 bits of HMC-SH-256 uthkey (i th half of DevicePassword) uthkey and KeyWrapKey are derived from the Diffie-Hellman key ased on multi-round MN III (4- or 8-digit password, 2 rounds) ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 WPS Registration Protocol: the essentials Cryptographic algorithms in WiFi Protected Setup Enrollee Choose 128-bit random ES-1, ES-2 Compute commitments E-Hash1 HMC uthkey (E-S1 PSK1 PK E PK R ) E-Hash2 HMC uthkey (E-S2 PSK2 PK E PK R ) Verify commitments R-Hash1 HMC uthkey (R-S1 PSK1 PK E PK R ) DevicePassword DevicePassword Registrar M 1 and M 2 : exchange PK E, PK R Choose 128-bit random ES-1, ES-2 Compute commitments Send commitments M E-Hash1 HMC uthkey (E-S1 PSK1 PK E PK R ) 3 = E-Hash1 E-Hash2 E-Hash2 HMC uthkey (E-S2 PSK2 PK E PK R ) M 4 = R-Hash1 R-Hash2 ENC KeyWrapKey (R-S1) Open commitments M 5 = ENC KeyWrapKey (E-S1) Key agreement uses Diffie-Hellman 1536-bit MODP group 5 from RFC 3526 SH-256 is used as the building block for key derivation, commitment and message authentication functions Encryption keys are 128 bits ES in CC mode is used for Key wrapping R-Hash2 HMC uthkey (R-S2 PSK2 PK E PK R ) M 6 = ENC KeyWrapKey (R-S2) M 7 = ENC KeyWrapKey (E-S2) M 8 = ENC KeyWrapKey (ConfigData) Verify commitments E-Hash1 HMC uthkey (E-S1 PSK1 PK E PK R ) E-Hash2 HMC uthkey (E-S2 PSK2 PK E PK R ) PSKi first 128 bits of HMC-SH-256 uthkey (i th half of DevicePassword) uthkey and KeyWrapKey are derived from the Diffie-Hellman key ased on multi-round MN III (4- or 8-digit password, 2 rounds) ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

Wireless US ssociation Models Wireless US connection between US hosts and US devices Two association models supported Cable model Numeric model WUS Numeric ssociation Model: the essentials start

18 Wireless US ssociation Models Wireless US connection between US hosts and US devices Two association models supported Cable model Numeric model WUS Numeric ssociation Model: the essentials start start Device Host Choose long random Choose long random PK D g mod p. Send commitment PK h H g mod p. h D D SH-256(PK D N D ) PK H Open commitment N D,PK D h D SH-256(PK D N D ) bort on mismatch N = N D v D h(pk D PK H displayed digest ) mod 10 N N = max (4, N D ) v D h(pk D PK H displayed digest ) mod 10 N v v ok/not ok User approves acceptance if v and v match h(): first 32-bits SH-256() output mod 10 N ok/not ok Similar to MN IV with 2-4 digit checksums, but key pairs cannot be reused ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 WUS Numeric ssociation Model: the essentials start start Device Host Choose long random Choose long random PK D g mod p. Send commitment PK h H g mod p. h D D SH-256(PK D N D ) PK H Open commitment h D SH-256(PK D N D ) N D,PK D bort on mismatch Cryptographic algorithms in WUS ssociation Models Key agreement uses Diffie-Hellman 3072-bit MODP group 15 from RFC 3526 SH-256 is used for commitments Encryption keys are 128 bits ES in CC mode is used for Key wrapping N = N D v D h(pk D PK H displayed digest ) mod 10 N N = max (4, N D ) v D h(pk D PK H displayed digest ) mod 10 N v v ok/not ok User approves acceptance if v and v match h(): first 32-bits SH-256() output mod 10 N ok/not ok Similar to MN IV with 2-4 digit checksums, but key pairs cannot be reused ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

19 Key establishment protocols for first connect Comparison of security levels P1: Key transport via OO channel Key establishment Key agreement P12: Key extraction from shared environment ssociation Model Protection luetooth Simple Pairing Offline attacks Work Protection Online active attacks Success Probability Protection Work* Numeric Comparison DH P digit checksum b nonce Symmetric crypto only symmetric crypto Passkey DH P digit passkey, 20 rounds b nonce Just Works DH P none 1 0 P2: uthenticated P3: uthenticated P11: 2.1 Out-of-band WiFi Protected Setup Out-of-band DH P-192 OO + DH Gr OO OO b nonce 128b nonce + 64-bit key uthentication by integrity checking uthentication by shared secret P10: Hybrid/one-way OO In-band DH Gr digit passkey, 2 rounds b nonce + 4-digit key P4: Key commitments via unspoofable channel Short string comparison 2.1 Push utton DH Gr Wireless US ssociation Models Numeric DH Gr or 4-digit checksum or b nonce Cable OO OO * verage work needed to find the right pre-image (with probability 1) P5: 2006,2007 User-assisted Nokia N P6: sokan, via September unspoofable 2007 channel P7: User-assisted P8: via OO channel P9: Secret extraction from shared environment ,2007 Nokia N sokan, September 2007 Suomalainen, Valkonen, sokan [ESS 2007] Comparative usability testing (preliminary) Comparing short non-secret check codes (P5) Compare-and-Confirm, Select-and-Confirm, Copy-and-Confirm Towards analyzing usability Using a short secret Passkey (P7) Copy (a passkey from one device to another), Choose-and-enter (your passkey to bothe devices) Distinguish between safe and fatal user errors Fatal errors lead to violation of a security objective Quantitative measurements and subjective feedback ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Uzun, Karvonen, sokan [USEC 07]

Who Tested the protocols Two groups of forty people Copy Passkey User copies passkey from one device to the other 4-8- and, 6-digit passkeys No fatal error possibility 30-34 35-39 ge 40+ 18-24 Female

20 Who Tested the protocols Two groups of forty people Copy Passkey User copies passkey from one device to the other 4-8- and, 6-digit passkeys No fatal error possibility ge Female 40% Sex Distribution Male 60% Highest Grade Completed Doctorate 10% Masters 57% High School 3% achelor 30% Results Users opinion: hard to use, professional, preferred 6-digit passkey: takes around 15 seconds 3% safe error rate ge Sex Distribution Highest Grade Com pleted Female 30% N/ mmattitutkinto 5% 8% Doctorate 15% High School 24% Male 70% Masters 25% Uzun, Karvonen, sokan [USEC 07] achelor 23% Uzun, Karvonen, sokan [USEC 07] ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Compare-and-Confirm (1/2) Each device shows a short code and the user is asked to compare the shown values. Round 1 Näive implementation: Yes/No question Takes around 15 seconds. 85% found it easiest but only 10% found it professional 20% fatal error rate: pressing yes without reading instructions! Compare-and-Confirm (2/2) Lessons from Round 1 Safe default [Saltzer and Schroeder] Use of unfamiliar labels Round 2 Takes around 17 seconds Only 40% found it the easiest No fatal errors, 2.5% safe error rate Uzun, Karvonen, sokan [USEC 07] Uzun, Karvonen, sokan [USEC 07] ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

21 User testing: observations and next steps User perception vs. reality Ease-of-use, security Too easy is not always good? Outlook for the future Need to revisit Secure First Connect? key agreement may be the winner: cost and usability ut some scenarios would require authentication: input devices, medical devices? Wanted: inexpensive, intuitive, secure techniques for first connect? Use of unfamiliar labels vs. learning effects Fatal errors vs. safe errors Reducing safe errors is important, too More controlled testing Testing in: familiar environments, repeated attempts, task-oriented Other interaction methods Extending First Connect eyond security associations How can users easily specify access control policies? Group first connect ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Summary cknowledgements Secure first connect is currently difficult Standards are emerging but the jury is still out Security Thanks to the folks who helped make some of the slides in this set, Kari Kostiainen, Nitesh Saxena, Ersin Uzun to those whose provided valuable feedback, Silke Holtmanns, Seamus Moloney, Kaisa Nyberg, John Solis Usability Need to balance security, usability and cost Usable security is more than just nice UIs May call for new protocols, algorithms and system design Cost and to those students and colleagues who collaborated in some of the research presented. Jan-Erik Ekberg, Philip Ginzboorg, Kristiina Karvonen, Kari Kostiainen, Seamus Moloney, Sven Laur, Kaisa Nyberg, Nitesh Saxena, Jani Suomalainen, Ersin Uzun, Jukka Valkonen ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

Pointers to some references First Connect Standards MN IV [CNS 2006], LNCS 430,1 pp 90 107, http://dx.doi.org/10.

org/10.1109/sp.2006.35 [ICR report 2006] http://eprint.iacr.org/2006/050 Usability testing [USEC 2007] http://www.usablesecurity.org/papers/uzun.

pdf Comparative survey of First Connect standards [ESS 2007], LNCS 4572, pp 43-57 http://dx.doi.org/10.

Higher layer key exchange techniques for luetooth security. Open Group Conference, msterdam October 24, 2001. [PGPfone1996] http://web.mit.

com/luetooth/learn/technology/core_specification_v21 E DR.htm WiFi Protected Setup http://www.wi-fi.

22 Pointers to some references First Connect Standards MN IV [CNS 2006], LNCS 430,1 pp , [ICR report 2005] linking lights (Saxena et al) [IEEE S&P 2006] [ICR report 2006] Usability testing [USEC 2007] [NRC report 2007] Comparative survey of First Connect standards [ESS 2007], LNCS 4572, pp [NRC report 2007] [Larsson 2001] Jan-Ove Larsson. Higher layer key exchange techniques for luetooth security. Open Group Conference, msterdam October 24, [PGPfone1996] luetooth Part of luetooth 2.1 specification: E DR.htm WiFi Protected Setup lso see, Windows Connect Now-NET: Netspec.mspx Wireless US ssociation Models ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 luetooth pairing today dditional background information Not easy Not cheap Not secure ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

23 luetooth pairing: Link key generation luetooth Mutual uthentication ll information except PIN is available to eavesdropper He can test candidate PINs against SRES Step 1: Compute K_init Step 2: Compute K_ab Shaked and Wool, Shaked and Wool, ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007 Secure Simple pairing flow diagram WF Protected Setup Registration protocol Step 1: Optional OO Information Collection Step 2: Enable Simple Pairing Enrollee Registrar: M 1 = Version N1 Description PK E Enrollee Registrar: M 2 = Version N1 N2 Description PK R [ ConfigData ] HMC uthkey (M 1 M 2 *) Step 3a: L2CP Connection Request for a Secure Service Step 3b: Optional OO Information Transfer Enrollee Registrar: M 3 = Version N2 E-Hash1 E-Hash2 HMC uthkey (M 2 M 3 *) Step 4: Start Simple Pairing Enrollee Registrar: M 4 = Version N1 R-Hash1 R-Hash2 ENC KeyWrapKey (R-S1) HMC uthkey (M 3 M 4 *) Step 5: IO Capability Exchange Enrollee Registrar: M 5 = Version N2 ENC KeyWrapKey (E-S1) HMC uthkey (M 4 M 5 *) Step 6: Public Key Exchange Enrollee Registrar: M 6 = Version N1 ENC KeyWrapKey (R-S2) HMC uthkey (M 5 M 6 *) Step 7a: Optional Numeric Comparison Step 7b: Optional Passkey Entry Step 7c: Optional OO Enrollee Registrar: M 7 = Version N2 ENC KeyWrapKey (E-S2 [ ConfigData]) HMC uthkey (M 6 M 7 *) Step 8: DHKey Checks Enrollee Registrar: M 8 = Version N1 [ ENC KeyWrapKey (ConfigData) ] HMC uthkey (M 7 M 8 *) Step 9: Calculate Link Key Step 10: Enable Encryption uthkey and KeyWrapKey are derived from the Diffie-Hellman key of PKE and PKR Step 11: L2CP Connection Response PSKi = first 128 bits of HMC uthkey (ith half of DevicePassword) X-Hashi = HMC uthkey (X-Si PSKi PKE PKR) ,2007 Nokia N sokan, September ,2007 Nokia N sokan, September 2007

The case for Usable Mobile Security

The case for Usable Mobile Security N. Asokan, Nokia Research Center Joint work with Cynthia Kuo (NRC) August 2012 2 http://www.dilbert.com (11/16/2007) Outline Why worry about usable security? What is