Using EMV cards for Single SignOn

1
Using EMV cards forSingle Sign-On
26th June 2004 1st 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
SSO Different Approaches

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

10
SSO Different Approaches

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

11
General SSO Protocol

Repeated as necessary

• Typical Information Flow

12
SSO some examples

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

• Fact 1 SPs need to establish a (typically
  costly) security infrastructure with the ASP.
• Fact 2 ASP has to be available.
• Question 1 Can we construct an SSO scheme based
  on credit/debit smartcards?
• Question 2 Can we construct the scheme s.t.
• it uses the PKI already established for credit
  cards?
• it does not require an online external party?
• it provides proof of possession of the card?

14
Outline of Talk

• Introduction Motivation.
• Introduction to EMV cards.
• How to use them for SSO.
• Conclusions.

15
EMV payments
EMV network
Acquiring Bank
Issuing Bank
Merchant
Cardholder
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
  cards 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
  cards 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 schemes 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 Requirements

• Needs 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 schemes 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?

38
Thanks!Questions? email andreas_at_xrtc.comwebs
ite www.xrtc.com