1 / 38

Using EMV cards for Single Sign-On

Using EMV cards for Single Sign-On. 26 th June 2004 1 st European PKI Workshop Andreas Pashalidis and Chris J. Mitchell. Outline of Talk. Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions. Outline of Talk. Introduction & Motivation.

hedwig
Download Presentation

Using EMV cards for Single Sign-On

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Typical Information Flow } Repeated as necessary

  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 Issuing Bank Acquiring 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 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 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 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?

  38. Thanks!Questions?email: andreas@xrtc.comwebsite: www.xrtc.com

More Related