Java Card 101 - Black Hat USA 2003

1. Java Card 101 - Black Hat USA 2003 Bruce Potter bpotter@cigital.com Senior Security Consultant Cigital, Inc.

2. Who Am I and Why Care About this Talk? • 3 years of Java Card security experience • Other security foo • Senior Security Consultant at Cigital • Founder of The Shmoo Group • Smart cards gaining traction… finally. • Post 9/11 security concerns • US Gov’t deploying 11k smart cards a day • Java card puts smart card tech within reach • Last talk before heavy drinking • Hopefully a good segue • Broad coverage of Smart Cards security and Java Card Technology

3. What is a Smart Card • Originally, there were mag stripes cards • Predefined card shape, strength, etc • Information encoded on a magnetic stripe on card • You’ve seen a credit card, right? • Easily copied • Data is static • Physical and electronic characteristics defined by ISO7816 • Same form factor as mag stripe • Now, “punch outs” for phone like applications • Many other specifications.. EMV talks about financial trans • Integrated Circuit Card (embedded microprocessor) • Not a memory card!

4. What is a Smart Card • Receives clock and power from external source • Never trust your environment • Contact and contact-less • Three types of memory • ROM (64KB-ish) • EEPROM (32KB-ish) • RAM (8KB-ish) • Used to be much less memory • But we’ll never need more than 640KB

5. Talking to a Smart Card - Entities • Terminal • Contains off-card application • Card is useless without something to interact with it • Reader • Physically interface with card • “smart” and “dumb” readers • Sometimes contained within the terminal • Card • Surprise! • Application Creator • Card Issuer

6. Uses of Smart Cards • Stored Value • It’s money in there, ma… • Wallet Applet • Cuz carrying your regular wallet is hard • Loyalty Applications • Keeping track of your airline miles • Identity • Access Control • Secure storage • All of the above?

7. Talking to a Smart Card - Conversation • Command - Response based • I ask, you tell… no independent thought • Application Protocol Data Unit (APDU) • Basic building block of a conversation • ISO 7816-4 • There’s lower level (encoding) specs too… • T=0 - byte oriented (real simple) • T=1 - block oriented (no so simple) • Answer to Reset (ATR) • On power-on, card tells about protocol and other low-level comms parameters

8. Command APDU • CLA - Class of the APDU • INS - Particular instruction within the class • P1, P2 - Parameters (case 1 ends here) • Lc - # of bytes of data (case 3 and case 4) • Data - as you would expect • Le - # of byes expected (case 2 and 4)

9. Response APDU • Data - Sent if Le was set in command APDU • SW - Status word. Like an exit code, but with more info (2 bytes)

10. Attacks Against Smart Cards • First off… just because you use smart cards doesn’t make you secure • Just like using SSL, etc… • Glitching • Pulling power at appropriate times • Under/over clocking • Under/over volting • Differential power analysis • Kocher et al - http://www.cryptography.com/ • Watching the power draw over repeated cryptographic operations • Performing differential cryptanalysis

11. Attacks Against Smart Cards • Ross Andersen’s work - http://www.cl.cam.ac.uk/users/rja14/ • Low budget but sophisticated attacks • Inducing errors with a lightbulb! • Using laser cutters and microprobes to change data within card • Shaving the ICC • Yes Virginia, there are physical changes to registers • Able to see 1’s and 0’s in memory • Vendor Response? • Make ICC’s more complicated • Multi-dimensional tangle of circuits • Still, with time and tools, ICC can be mapped • Difficult to interact with ICC

12. Attacks Against Smart Cards Systems • The card may not be the weak point • Reverse-engineering *gasp* really lame protocols • Watch yourself…. DMCA is being used as a hammer • By-passing smart card system • Some systems use mag-stripes as backups • Much easier to dupilicate

13. Java Card • So, you still want to deploy them? • Back in the day, cards were made from a mask that contained the program • Cards were single vendor and fixed applications • Application mistake in the mask meant reissuance • More advanced operating systems now allow for applications to be added post-fabrication • Lots can be done with multi-application, dynamic cards • Sounds like a good place for Java, eh? • A really, really, really stripped down version of Java • Applets need to be compiled to a few KB of bytecode • Smaller than J2ME

14. New uses for Smart Cards Thanks to JC • Smaller, custom deployments for Access Control and Identification • Cheaper, large scale deployments • Buy a vendors Java Card implementation • All you need to do is write some card code, terminal code, and backend code • Spoofing for other Smart Card systems • If you know the APDU’s and transaction structure for another system (say stored value), write an applet to subvert terminal • Nice hacking too, eh?

15. Java Card API • Java.lang - a subset of the java language • Objects • No double, long, chars • Exceptions • Javacard.framework - classes for the core functionality of an applet • APDU • PIN • JCSystem • Javacard.security - Security Classes • Keys • Random Data • Javacardx.crypto - mad crypto foo

16. Java Card Virtual Machine • Actually split into two parts • Off card Converter (yes.. Part of the VM is off card) • Performs security checks • Creates optimized bytecode • Initializes static variables • Creates class datastructures • Final Result: CAP file… like a shrunken JAR file • On card installer • On card interpreter • For execution, bytecode is interpreted by on-card VM • Handles memory allocation and very limited garbage collection

17. Java Card Virtual Machine

18. Java Card Runtime Environment • Think of it as “the OS” • Lifetime of JCRE is lifetime of card • A bit non-intuitive… unlike Java on a PC • Instantiation of an applet usually only happens once • Applet and Runtime remain between card resets • Subset of the JRE • Focused on things that matter to card in hostile environment • Protects applets from each other and the world

19. Java Card Runtime Environment • Command Processing • APDU dispatch to the applet’s process() method • Handling of Transient objects • Allows objects to be created and used in RAM for security and performance • Transactions and atomicity • Any single field write is made atomic by JCRE • Futher, JCRE provides for safety within transactions boundaries • Interrupting a transaction can be profitable if not properly handled

20. Java Card Runtime Environment • Applet isolation via applet firewall • Unlike standard java, applets cannot invoke other applet’s methods • Each applet in a package (basically a CAP file in JC case) runs in its own context • Applet firewall forces applets to explicitly share interfaces to allow external access • Exception Handling • Key for a safe and secure application, card, and system

21. Java Card Security Architecture • Type-safety • Most important verification done off-card • Byte code verified during compile • Checks for language violation • No bad datatypes, no threatds • Once code on the card, most of the checks are runtime issues • During the interim period, code (and ergo the cards, ultimately) are vulnerable • Malicious bytecode a real problem • Needs extra juice • Applet firewall prevents silliness • If properly implemented, remarkably effective

22. Controlling Code • So… it’s good that anyone can load an applet, right? • Situation: Credit Card Vendor gives you a smart card which allows post-issuance applet loading • Wallet applet • Loyalty program • Attack: Malicious applet loaded on card to attack other applets • Attack: Malicious terminal terminates wallet applet • Attack: Legit terminal tries to load code on card… code changed in transit • Need a higher level controls to limit post-issuance code loading • Also, due to off card validation, need some code signing mechanism to verify that code can be trusted

23. Controlling Code • Enter Global Platform (from Visa originally) • APDU MAC’ing • Cryptographically signed CAP file • Authentication process for loading and installing code • If multi-application, multi-vendor smart cards ever take off in the consumer financial industry.. They’ll use GP

24. Issuing Smart Cards • Pre-issuance - card assumed physically secure • Post-issuance - Wild Wild West • Card needs to protect itself • No native methods may be declared • Direct interaction with ICC would compromise all Java card security - no verification mechanism

25. Important Methods • Skipping a complete sample applet… • install() • Called when card installer wants to install a new Applet • Instantiates applet (basically like regular Java) public static void install ( byte[] bArray, short bOffset, byte bLength) { new myApplet(null); } Note: myApplet must call register() so the JCRE knows the new applet has been instantiated

26. Important Methods • select() • When an off card entity wants to use an applet, it must be selected first • Upon reception of SELECT APDU, JCRE calls applets select() method • Applet verifies it is selectable and gets ready to receive more commands • deselect() • When another applet is selected, previous JCRE calls deselect() on previous applet first • JCRE will not allow previous applet to block and stop deselection • No DoS for you!

27. Important Methods • process() • The real meat of the thing • When an APDU is received and the applet is selected, its process method is called by the JCRE and the passes it an APDU object. • Now you can parse the APDU, do what you need to do with it and then respond.

28. Example Execution # power on card and select AID 1 2 3 4 5 6 7 8 poweron: card turned on; connection establish sendraw: transmitting (raw) (13): 0x80 0x50 0x00 0x00 0x08 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 sendraw: receiving: (2): 0x61 0x1c # there are 27 bytes of data to get. Get them. sendraw: transmitting (raw) (5): 0x00 0xc0 0x00 0x00 0x1c sendraw: receiving: (30): 0x00 0x00 0x02 0x80 0x00 0x00 0x29 0x31 0x00 0xa7 0x0d 0x01 0x59 0x11 0xfe 0x51 0x49 0x45 0x4e 0x09 0x19 0x35 0xec 0x2c 0x5a 0x8e 0xe0 0xb4 0x90 0x00

29. Secure Coding Guidelines • A bad applet can destroy the system • Use some manner of code signing… home brewed or otherwise • Barring that, verify chain of custody of code before installing • Velocity Checking • Note: Not like typical Velocity checking • On a smart card, time has no meaning • Any sensitive activity should only be allowed a reasonable number of times… then lock/terminate • Don’t forget harvesting “random” data • Only share what you need to • Watch out for transitivity issues with Shared Interface Objects

30. Secure Coding Guidelines • Proper exception handling • Hacking a smart card may rely on making bad things happen • Detect, throw, protect • Use transient data where needed. Use transactions where needed • When updating sensitive information, wrap in a transaction boundary • Check commit capacity first • JCSystem.beginTransaction(); • JCSystem.endTransaction(); • Don’t forget to abortTransaction() if things go wrong

31. Secure Coding Guidelines • Remember things are smaller on smart cards • Int may not be supported • Keep your code tight • When designing your protocol… think like an attacker • Both terminal and card can be forged • How does a fake terminal effect the card • Vice-versa • A simple Command-ACK protocol will likely be subverted • Cryptographically sign sensitive operations • Lots of prior art here • See resent Blackboard ID hack • http://features.slashdot.org/article.pl?sid=03/04/14/1846250

32. Extra bits • MUSCLE Project • Movement for Use of Smart Cards in Linux Environments • www.linuxnet.com • PC/SC Daemon • Lots of reader drivers • Sun’s stuff • http://java.sun.com/products/javacard/ • “Java Card Technology for Smart Cards” - Zhiqun Chen

33. Card Vendors • Oberthur - http://www.oberthurcs.com/ • Gemplus - http://www.gemplus.com/ • Low priced development kits with reader/cards • Schlumberger - http://www.smartcards.net • $50 readers / $12 a card • Cards with USB logic imbedded in card

34. Questions? • Buy some books!