smartphone-based authentication: apps
DESCRIPTION
TRANSCRIPT
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
Motivation: Web authentication (3)
Security tokens
• Hardware cost
• Software tokens prone to malware
• Proliferation vs. usability
• No selective attribute disclosure
8
Motivation: Web authentication (4)
2-factor SMS authentication
• Password/token mgmt
• 2G GSM security questionable
• Part of credentials still malware-prone
9
Motivation: Web authentication (5)
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?