1. 1 Using EMV cards for Single Sign-On 26 th June 2004 1 st European PKI Workshop Andreas Pashalidis and Chris J. Mitchell

2. 2 Outline of Talk Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.

3. 3 Outline of Talk Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.

4. 4 Why do we need SSO ? Current Situation: Network users interact with multiple service providers.

5. 5 Why do we need SSO ? Problems: Usability, security, privacy…

6. 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. 7 SSO – How ? Introduce a component, called the Authentication Service Provider (ASP).

8. 8 SSO – How ? 1) Initially the user authenticates himself to the ASP. 2) ASP takes care of subsequent user-to-SP authentications.

9. 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. 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. 11 General SSO Protocol Typical Information Flow } Repeated as necessary

12. 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. 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. 14 Outline of Talk Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.

15. 15 EMV payments Cardholder Merchant Acquiring BankIssuing Bank EMV network

16. 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. 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. 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. 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. 20 Outline of Talk Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.

21. 21 System Entities The Card. Cardholder System (CS). Service Provider. CS and Card act as the ASP. Online presence of Issuer not required.

22. 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. 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. 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. 25 SSO Protocol

26. 26 SSO Protocol

27. 27 SSO Protocol

28. 28 SSO Protocol

29. 29 SSO Protocol

30. 30 SSO Protocol

31. 31 SSO Protocol

32. 32 SSO Protocol

33. 33 SSO Protocol Authentication Assertion

34. 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. 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. 36 Outline of Talk Introduction & Motivation. Introduction to EMV cards. How to use them for SSO. Conclusions.

37. 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. 38 Thanks! Questions? email: andreas@xrtc.com website:www.xrtc.com