Smartcards & RFID

1. Smartcards & RFID Erik Poll Digital Security Radboud University Nijmegen

2. 1900's technology

3. 2000's technology

4. Overview • What are smartcards & RFID ? • Why use them? • Possibilities and limitations • hardware, software, communication protocols • Attacks on security

5. What is a smartcard?

6. What is a smartcard? • Tamper-resistant computer, embedded in piece of plastic, with limited resources • capable of securely • storing information • processing information (This is what makes a smartcard smart; stupid cards can store but not process data)

7. Smartcard form factors • traditional credit-card sized plastic card • ISO 7816 • mobile phone SIM • cut-down in size • contactless cards • aka proximity card or RFID transponder/tag • also possible: dual interface • iButton

8. Smartcard example uses • banking cards • bank or credit card, electronic purse • telephone cardfor use in public phone booths • GSM SIM • pay TV • public transport – eg London Oyster card • health cards • passports and other e-id cards • access cards • to control access to buildings, computer networks, laptops,...

9. Magnetic stripe cards • Older mag-stripe card can only store information, without read/write protection, and cannot process it.

10. Anything suspicious?

11. Skimming

12. Skimming

13. Skimming

14. Skimming

15. Smartcard vs mag-stripe cards • Smartcard cannot easily be copied or altered, unlike a mag-stripe card • Skimming is big criminal business • copying (aka cloning) mag-stripe cards and observing PIN codes is easy... • Still, credit card companies in US are sticking to mag-stripe, and in Europe they are only slowly moving to smartcards • apparently, it is secure enough for them to make a profit

16. smartcard essentials

17. Smartcard contacts External power supply and external clock On a SIM card the clock can be stopped to safe power

18. Smartcard contacts Vpp is higher voltage than Vcc needed for writing EEPROM • no longer used because of security problem • painting over this contact prevents changes to EEPROM

19. Smart vs stupid smartcards Big range in capabilities of smartcards. Rough division: • Memory cards (stupid) • provide a file system • possibly with some access control, or, simpler still, destructive (irreversible) writes as in old payphone-cards • functionality hardwired in ROM • Microprocessor cards (very smart) • contain CPU • possibly also crypto co-processor • programmable • program burnt into ROM, or stored in EEPROM

20. Smartcard hardware • CPU– 8 to 32 bits • memory • RAM • ROM (for some program code) • EEPROM/Flash/...(“hard disk”, for code and data) Modern cards may have 1K RAM, 16K ROM, 64K EEPROM • limited I/O: just a serial port • possibly:crypto co-processor, random number generator

21. Communication (ISO 7816) • All subsequent communication via APDUs • Application Protocol Data Units which are just byte sequences in particular format • Master-Slave mode, with terminal master: • Terminal sends command APDU • Card replies with response APDU etc, etc .... • Smartcard cannot initiate any actions: • on phones the phone polls the SIM periodically

22. Command & response APDU • CLA class byte • INS instruction byte • P1,P2 parameters • Lc length of data block • Data Lc bytes of data • Response Lc bytes of data • SW1, SW2 2 byte status word

23. Smartcard software • (Microprocessor) smartcard contains very simple operating system, capable of executing programs • Programs can be written in • proprietary machine code language, or • higher level language, notably Java Card Most new SIMs are now Java Cards.

24. one program (applet) written in machine code, specific to chip burnt into ROM or uploaded once to EEPROM applet written in high-level language (eg Java Card) compiled into bytecode stored in EEPROM interpreted on card multi-application: several applets on one card post-issuance: adding or deleting applets after it's issued old vs new smartcards

25. Multi-application cards • multi-application vision: everyone carrying just one card, with all their smartcard applications • This is not going to happen. Problems include: • trust: bank won't allow untrusted applet code on their cards, despite any VM+ firewall security guarantees • marketing: who gets to put their logo on the plastic?

26. Post-issuance download • Downloading additional applets protected by digital signatures • Switched of on many cards for security reasons • Enabled on SIMs it allows telco to install new software on the SIM

27. Java Card • dialect of Java for programming smartcards: • superset of a subset of normal Java • subset of Java(due to hardware constraints) • no threads, doubles, strings, garbage collection, and very restricted API • with some extras(due to hardware peculiarities) • communication via APDUs or RMI • persistent & transient data in EEPROM &RAM • transaction mechanism

28. Java Card architecture applet applet applet Java Cardplatform Java Card platform Java Card Virtual Machine Java Card API (mini OS) smartcard hardware

29. Java Card I/O with APDUs OS selects applet and invokes its process method commandAPDU, incl. applet ID applet applet Applet sends response APDU applet applet applet executes Java Cardplatform smartcard hardware

30. Pros of JavaCard • vendor-independance • easy to program • higher-level language => smaller programs with fewer bugs • standard functionality (eg for PINs) provided once by the API • open standard • no reliance on security-by-obscurity • specs can be studied and criticised

31. Cons of JavaCard • overhead of VM makes cards slow and requires lots of memory => expensive • ease of programming may be deceptive: non-experts programming cards may make silly mistakes • every idiot can program a JavaCard, not every idiot should • trust: how secure is the whole JavaCard infrastructure • complicated platform, and complexity <-> security • blank programmable JavaCard easy for attacker to experiment with • security by obscurity may have its merits...

32. Java Card vs Java Java Card applets are executed in a sandbox • like applets in a web browser But important differences: • no bytecode verifier on most cards • due to space required • downloading applets controlled by digital signatures instead • plus bytecode verification, if card supports it • sandbox more restrictive, and includes runtime firewall between applets

33. Java Card firewall eg prevents access to public fields of other applets or references to objects belonging to other applets or JCRE applet applet applet Java CardRuntime Environment (JCRE = VM+API) smartcard hardware

34. Java Card 3.0 • Releases up to Java Card 2.2.2 use traditional smartcard communication model • small byte array (APDU) sent back and forth to applet on the card (using ISO 7816 standard) • Java Card 3.0 (March 2008) introduces new communication model: • smartcard becomes a webserver with IP-stack etc • applets become servlets So you can talk http(s) to the smartcard • Proclaimed goal: easier development of SIM services

35. Why use smartcards?What are the possibilities and limitations of smartcards?

36. Why use smartcard? • SIM responsible for authentication to network • telco doesn't trust phone, but trusts SIM

37. CIA and smartcards • Confidentiality • of data (crypto keys) on card • Integrity • of data and program code • Authentication • because (data on) card cannot be copied • Non-repudiation • because (data on) card cannot be copied • also logging on the smartcard (and integrity of this log)

38. Typical use of smartcard challenge c crypto key K CPU response fK(c) • keyKneverleaves the card • Card issuer does not have to trust the network, the terminal, or card holder

39. Example: logging on over a network • Send password unencrypted over net(eg. rlogin) Trust network, terminal, user • Send password encrypted over net (eg. slogin) Trust terminal, user • Idem, but user, not terminal, does encryption Trust user • Using smartcard Trust no-one, except the smartcard (NB smartcard is controlled by card issuer, not card holder!)

40. NB the problem with cryptography Any use of crypto introduces problems: • key distribution • how do we generate & distribute keys? • key storage • where can we safely store keys? • en/decryption • who do we trust to perform en/decryption? Smartcards can offer a solution

41. TCB and smartcards • Smartcard typically part of the TCB (Trusted Computing Base), ie. the trusted part of the system • NB “trusted” is a negative quality: it means “you have to trust it” not “you can trust it” • If any part of the TCB fails, security is broken • TCB should be as small and reliable as possible

42. RFID

43. RFID tags • RFID = Radio-Frequency IDentification • RFID devices are called tags or transponders • More powerful RFID tags can be called (contactless) smartcards • Inductive coupling is used for • energy transfer to card • transmission of clock signal • data transfer

44. Types of RFID: different capabilities & ranges animal identification product identification (like bar codes) contactless smartcards (possibly dual interface) NFC mobile phones

45. contactless smartcard inside chip antenna

46. Different capabilities of RFID tags • Simplest tags just broadcast fixed data (serial number) when activated • ie only communication from tag to reader • Some tags provide basic file system, with simple access control • ie reading & writing, and communication both ways • More advanced tags can do cryptographic operations to protect data & encrypt communication • Most advanced tags are programmable • Range can be a few mm, a few cm, a few feet or several meters, depending on the type

47. Pros & cons wireless • Advantage • convenience • faster • contacts not subject to wear and tear • Disadvantage • eavesdropping • virtual pickpocketing

48. NFC

49. Near Field Communication (NFC) • Latest Nokia phones have NFC • These can act as RFID tag and as RFID reader

50. NFC • Advantage of NFC phone over smartcard: • (trusted?) display and keyboard • Envisaged use • payment applications • RFID tags providing info to phone • eg in information signs & billboards