Practical Security Systems with Smartcards

1. Practical Security Systems with Smartcards Naomaru Itoi CITI University of Michigan

2. Contents • Introduction • Related work • Three components • Future directions

3. Project Goals • Develop, Build, and Deploy a secure system with smartcards in the University of Michigan. • Provide a smartcard which handles computer authentication, Internet access, identification, banking, payment, etc… in everybody’s pocket. • Feedback to computer science world

4. Why? - Smartcard is good • Secure hardware • Tamper-resistance • Restricted communication (serial port) • File protection (PIN, cryptographic) • Cryptographic algorithms • Portability • Convenience • Security • Multi-functionality • One smartcard for several tasks

5. Smartcard Applications • Telecommunication payment • Majority of smartcard used in Europe • Health care • Government applications • Store customer based information • Banking • Visa Cash, MasterCard • More secure than magnetic stripe credit card But these are in Europe

6. No Killer-Application in the US Applications in the US? • Only 2% of smartcard product shipped to the US in 1995 • Telecommunication payment? • No global infrastructure • Health care? • Government? • No large centralized government application • Banking? • Customers and merchants are familiar with magnetic stripe credit card

7. Information Technology Business • Demand for secure computer environment is large • Users are ready to new hardware Can be the Killer-Application in the US

8. Computer environment goals • Security • Solve typical problems e.g. vulnerability of passwords • Secure authentication • Secure Internet access • Convenience • Store personal information in a smartcard • Single Sign-On

9. Related Work • Secure coprocessor • Doug Tygar et al. in CMU • Build physically tamper-proof coprocessor • Build secure bootstrapping, etc. • Build an operating system to take advantage of it • Theoretical approach • Butler Lampson et al. in DEC • Develop theory of authentication in distributed systems • Build secure bootstrapping, etc. • Build an operating system, then prove it to be secure

10. Our approach • Take existing secure hardware - smartcard • Integrate smartcards with existing infrastructure • Secrets in a smartcard remain secure even if hardware / software is compromised • Store critical information in a smartcard

11. Three components • Smartcard development environment • Smartcard integration with the UNIX filesystem • Smartcard authentication • Smartcard integration with Kerberos V5 • Smartcard, Pluggable Authentication Module, and Windows NT

12. Smartcard development toolkit current situation • ISO-7816 • Standard smartcard interface • Primitive message framing protocol • Too primitive to be useful • Vendor dependencies • Smartcard Programming Toolkit • IBM MFC, Microsoft PC/SC, OpenCard Framework, EMV’96, PKCS#11 … • Building everything over a smartcard - language, API, toolkit, library, application, etc. • Hassle to learn yet another new toolkit • Not interoperable

13. SCFS goals • Implement VFS layer that handles smartcards • UNIX filesystem API • UNIX commands • Can handle any smartcard as long as it supports ISO-7816

14. scfsd Smartcard Application XFS VFS SCFS design • Arla like 2-level architecture User level Kernel level • XFS handles application requests • Scfsd translates requests to smartcard commands • Scfsd pops up a Tk window to ask PIN when a file is protected

15. arlad AFS server Application XFS VFS Arla - free AFS client • Written by Assar Westerlund et al. in Royal Institute of Technology, Sweden User level Kernel level

16. SCFS implementation xfs_mount() Send a reset signal to a smartcard Choose smartcard type from the configuration table Mount the scfs filesystem xfs_read() Translate FID into a smartcard file Select the file Send “read” APDU Copy data to the user space with uiomove() ...

17. SCFS performance (ms) Command Total Smartcard Scfs Overhead Read 8 Bytes 28.9 28.2 0.7 (2.4%) Read 128 Bytes 190.2 189.4 0.8 (0.4%) Write 8 Bytes 63.4 62.7 0.7 (1.1%) Write 128 Bytes 1259.5 1258.9 0.7 (0.1%) Start reading smartcard Read() call Finish reading smartcard Read() return Total Smartcard access Scfs overhead Scfs overhead

18. SCFS conclusion • Smartcard files seem almost identical to UNIX files -- except the length of a file • UNIX filesystem API • UNIX commands ls, cd, pwd, etc. • Useful development toolkit • Secure storage can be implemented with symbolic links • User profiles, Netscape cookies, Kerberos tickets, etc. • Overhead is fairly small (up to 2.4%)

19. Smartcard Integration with Kerberos • Kerberos - the most widely used network authentication protocol • U of M computer environment is protected by Kerberos V4 • Security limitations (Steven Bellovin et al.,AT&T): • Need for an external encryption device • Need for a secure key storage • Dictionary attack to passwords • Solve these problems with a smartcard

20. Decrypt Need for encryption device Kerberos KDC 1) username Ku User password Workstation 2) {TGT}Ku Ku • A workstation decrypts TGT. • A workstation is a vulnerable secure storage. • A workstation may not be trusted.

21. Need for secure storage • Keys are stored in a hard disk or in memory in a workstation. • Hard disks are not secure • Adversary with an administrator right can access keys. • Data in a hard disk may be backed up in a mass storage device. • Memory is not secure • Adversary can run memory scan. • Data in memory can be paged out to a hard disk.

22. Dictionary Attack • Obtain a <plaintext, ciphertext> pair • Create a list of English words, names, etc. • Derive keys from the words in the list • Decrypt the ciphertext with the derived key • If the plaintext is recovered, the key used for decryption is the secret key in quest • Kerberos gives up <plaintext, ciphertext> pair easily • Real problem in U of M -- 4,000 accounts are compromised

23. Decrypt Countermeasures - use a smartcard Kerberos KDC 1) username Ku • Ku is not exposed either a user, networks, or a workstation. • There is no password. Workstation 3) {TGT}Ku 2) {TGT}Ku Smartcard DES engine 4) TGT Ku

24. Implementation • Smartcard called STARCOS v. 2.1 from Giesecke & Devrient • Modify Kerberos v5-1.0.5 by M.I.T. • Modify Kerberos client • Kerberos server remains unmodified

25. Kerberos-Smartcard performance • The authentication protocol takes 2.51s. • Decryption is the bottleneck -- takes 2.09s. • Fine breakdown shows it is possible to improve performance with CBC-in-a-smartcard approach. Card reset Kinit start Start decryption End decryption Kinit finish (ms) 0 20 370 2460 2520

26. Kerberos-Smartcard conclusion • Practical smartcard authentication method • Solve limitations of Kerberos • The protocol works fairly fast • There is still room to improve

27. Smartcard, Pluggable Authentication Module, and Windows NT • Smartcard authentication in UNIX and NT • UNIX-PAM • Flexible authentication method • Single Sign-On • Need PAM in NT

28. Design • Use PAM - standard security framework • Implement PAM in Windows NT • Integrate Kerberos-Smartcard protocol with PAM

29. NT without PAM GINA AFS NT domain NetWare LSA Kerberos4 Kerberos5 NetWare • No Single Sign-On • Poor configuration method authenticated services authentication systems

30. NT with PAM NI_PAM GINA Kerberos4 Kerberos5 NetWare LSA • Single Sign-On performed • Configuration centralized in Configuration Table authenticated service NT Local Kerberos4 Kerberos5 Netware authentication systems

31. Implementation Winlogon WlxLoggedOffSAS() NI_GINA Config table in Registry NI_PAM NI_KRB4 NI_KRB5 NI_NW LSA Kerberos4 Kerberos5 Netware4.0

32. NI_PAM Performance User Logon PAMStart K5 Start K5 End PAMEnd 0 0.05 0.82 299.82 299.91 (ms) • PAM is fast

33. NI_PAM conclusion • First step to smartcard authentication in NT • Flexible and integrated security configuration method • Common method among Solaris, Linux, and Windows NT • Single Sign-On with Kerberos V4, Kerberos V5, and Netware 4.0

34. NI_PAM contribution • Developed in summer of 1997 • Presented in 1998 USENIX Windows/NT symposium • ITD plans internal deployment in Fall/1998 • University-wide deployment in Winter/1999 term

35. Conclusion - OverallGoals revisited • Security • Solve typical problems e.g. vulnerability of passwords -- Kerberos-Smartcard • Secure authentication -- Kerberos-Smartcard • Secure Internet access • Convenience • Store personal information in a smartcard -- Smartcard Filesystem • Single Sign-On -- PAM in NT • Improved development environment • Smartcard -- Smartcard Filesystem • Windows NT security -- PAM in NT

36. Future Directions • Kerberos-Smartcard • Secure key storage for Kerberos servers • Decryption performance optimization • IP in a smartcard • A computer can talk with smartcards even if they are not directly connected to its serial ports • Secure bootstrapping with a smartcard • PAM • Single Sign-On with PAM and smartcards

37. Related Work - comparison Secure computer system Secure operating system Secure bootstrapping Secure computer system Existing operating system Existing bootstrapping Secure hardware Authentication theory Existing hardware + Smartcard