1 using emv cards for single sign-on 26 th june 2004 1 st european pki workshop andreas pashalidis...
TRANSCRIPT
1
Using EMV cards forSingle Sign-On
26th June 20041st European PKI Workshop
Andreas Pashalidis and Chris J. Mitchell
2
Outline of Talk
Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.
3
Outline of Talk
Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.
4
Why do we need SSO ?Current Situation:
Network users interact with multiple service providers.
5
Why do we need SSO ?Problems:
Usability, security, privacy…
6
What is SSO ?
A mechanism that allows users to authenticate themselves only once, and then log into multiple service
providers, without necessarily having to re-authenticate.
7
SSO – How ?Introduce a component, called the
Authentication Service Provider (ASP).
8
SSO – How ?1) Initially the user authenticates himself to the ASP.
2) ASP takes care of subsequent user-to-SP authentications.
9
1. Service providers are aware of the ASP SPs/ASP have to establish explicit trust
relations, policies, contracts and supporting security infrastructure (e.g. PKI).
ASP is either a trusted third party or part of the user system (requires tamper-resistant hardware, e.g. smartcard, TPM).
2. Service providers are NOT aware of ASP ASP is transparent to SPs – no trust relations. Either local software or proxy-based.
SSO – Different Approaches
10
1. Service providers are aware of the ASP SPs/ASP have to establish explicit trust
relations, policies, contracts and supporting security infrastructure (e.g. PKI).
ASP is either a trusted third party or part of the user system (requires tamper-resistant hardware, e.g. smartcard, TPM).
2. Service providers are NOT aware of ASP ASP is transparent to SPs – no trust relations. Either local software or proxy-based.
SSO – Different Approaches
11
General SSO Protocol
Typical Information Flow
} Repeated as
necessary
12
SSO – some examplesMicrosoft Passport
ASP = www.passport.com Assertion = (symmetrically) encrypted cookie
Liberty Alliance ASP = “Identity Provider” Assertion = digitally signed XML document
Kerberos ASP = Kerberos server Assertion = ticket (+ proof-of-knowledge of session key)
13
Motivation
14
Outline of Talk
Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.
15
EMV payments
Cardholder
Merchant
Acquiring Bank
Issuing Bank
EMV network
16
Card/Terminal Interaction
SELECT (Application selection, session begins).GET PROCESSING OPTIONS, READ RECORDS (Card sends necessary data files to Terminal).INTERNAL AUTHENTICATE (Terminal authenticates card’s validity).CARDHOLDER VERIFICATION (Cardholder has to insert his/her PIN).…remainder of transaction…
17
Card/Terminal Interaction
SELECT (Application selection, session begins.)GET PROCESSING OPTIONS, READ RECORDS (Card sends necessary data files to Terminal).INTERNAL AUTHENTICATE (Terminal authenticates card’s validity).CARDHOLDER VERIFICATION (Cardholder has to insert his/her PIN).…remainder of transaction…
18
INTERNAL AUTHENTICATE
Static or Dynamic Data Authentication.Each DDA-capable card contains: Issuer public key certificate (signed by scheme). A unique Key Pair (installed by Issuer). Certificate for its public key (signed by Issuer).
Terminal contains the scheme’s root key.1) Terminal reads and verifies certificates.2) Challenge/Response protocol is executed.
19
CARDHOLDER VERIFICATION
Cardholder enters PIN into keypad.
PIN is verified either Online to the Issuer, or Offline to the card (VERIFY). Blocked
after a certain limit of failures.
CARDHOLDER VERIFICATION is optional.
20
Outline of Talk
Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.
21
System Entities
The Card.Cardholder System (CS).Service Provider.
CS and Card act as the ASP.Online presence of Issuer not required.
22
Card RequirementsNeeds an additional EMV application, the Authentication Application (AA).
In the AA The PAN and all PII has to be replaced with
non-identifying information.
The certificate for the card public key must not contain any PII (hence, new certificate).
A “Pin Verification Data Element” (PVDE) has to maintain state within the current session.
23
CS Requirements
Network access device, wired or wireless.
Needs smartcard reader.
Needs special software that communicates with card and Service Providers for login, the “SSO Agent”.
24
Service Provider Requirements
Acts in an analogous manner to merchant terminals.
Needs a copy of the scheme’s public key.
Needs to have a human-readable, unique identifier (SPID), e.g. a DNS name.
Needs special software in order to support the SSO scheme.
25
SSO Protocol
26
SSO Protocol
27
SSO Protocol
28
SSO Protocol
29
SSO Protocol
30
SSO Protocol
31
SSO Protocol
32
SSO Protocol
33
SSO Protocol
Authentication Assertion
34
Advantages
SP chooses strength of user authentication Proof of possession of card. Proof of knowledge of PIN.
A rogue CS cannot compromise the above.
Manual interaction minimal.
Initial goals met. Uses already established PKI. Does not require online party.
35
Disadvantages
Works only for EMV cardholders.
Requires a card reader in the CS.
Card cannot authenticate reader/terminal.
No trust management at the Issuer level.
36
Outline of Talk
Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.
37
Conclusions
SSO using EMV cards is technically possible.
Reusing existing PKI.
Optionally two factor user authentication.
“Business” questions: who pays for… card readers? additional application on card? software?
