smartphone-based authentication: apps

1

Smartphone-based authentication: apps

WisCy workshop 2011

2

Overview

• Introduction

• Motivation

• Approach 1: IDM architecture

• Approach 2: Idemix

• Comparison

• Demos

3

Introduction

User

• Wants ubiquitous access to Web services

• Concerned about security & privacy

• Personalised services

Service provider

• Google, Facebook,…

• Offers a service

• Wants to obtain reliable user info

Identity provider

• Provide reliable (partial) user info

• Authenticated provisioning

4

Introduction

User

• Wants ubiquitous access to Web services

• Concerned about security & privacy

• Personalised services

Service provider

• Google, Facebook,…

• Offers a service

• Wants to obtain reliable user info

Identity provider

• Provide reliable (partial) user info

• Authenticated provisioning

Example: Shibboleth IDP

5

Motivation: Web authentication

Passwords

• Weak security

• Theft by malware

• Human memory limitations

• No attribute provisioning

6

Motivation: Web authentication (2)

Smartcards

• Suitable hardware required

• Proliferation vs. Usability

• Trust in workstation (PIN)

7


Security tokens

• Hardware cost

• Software tokens prone to malware

• Proliferation vs. usability

• No selective attribute disclosure

8


2-factor SMS authentication

• Password/token mgmt

• 2G GSM security questionable

• Part of credentials still malware-prone

9


Federated Identity Management (FIM)

• Limited user control

• Identity provider can profile users

• One identity provider per user

• User impersonation

• Password/token mgmt

10

Motivation: recent trends

More mobility & more computers

Smartphones omnipresent

Mobile Internet penetration

11

2 approaches, 2 apps

Approach 1

Android

IDM architec-

ture

Secure µSD

Approach 2

Android

Secure µSD

12

Approach 1

User Trusted module Workstation Service

provider 1. Get resource

2. Request access to resource

3. Auth challenge (QR) 4. Auth challenge (Scan QR)

5. Ask for consent

6. Review & give consent

8. Mutually authenticate (out-of-band)

9. Confirm authentication

[consent given]

alt

[else]

8. Abort

7. Resolve query

13

Approach 2

User Workstation

alt

[consent given]

[else]

1. Go to Web service

2. Request Web service

3. Auth challenge (QR) 4. Auth challenge (QR scan)

5. Ask for consent

6. Review & give consent

7. Mutually authenticate (out-of-band)

8. Confirm authentication

7. Abort

Service provider Smartphone

1. Get resource 2. Request access to resource

3. Auth challenge (QR) 4. Auth challenge (Scan QR)

5. Show available policies

6. Select policy

alt

[policy specifies HTTP channel]

[policy specifies QR channel]

7. Generate proof

8. Send proof (out-of-band)

8. Transfer proof (Scan QR)

9. Send proof

14

Comparison

Idemix IDM architecture

Technology Idemix JavaCard

Response Zero-knowledge proofs Queries

Revocation check

By verifier By card

Master secrets • 1 per user • 1 per user • 1 per group

15

Advantages / drawbacks

Idemix IDM architecture

Platform portability Less More (no adjustments in µSD)

Flexibility Highly flexible zero-knowledge proofs

Less flexible queries

Attribute provisioning At time of issuance At time of issuance + realtime

Performance on same platform

Slower Faster

Rev

oca

tio

n

Computational cost

Expensive Lightweight

Realtime? Yes Small vulnerability interval

Trust in phone More Less (mostly in µSD)

16

Extensions

IDM architecture

• Automate decisions (policies)

Idemix

• Master secret on secure µSD

17

Extensions (2)

• Trusted environment on phone

• Standards interoperability

• Integration in advanced Web apps

• Other short-range protocols (NFC, Bluetooth,…)

• Registration, backup and revocation strategies

18

Demo

19

Questions?