Java Security Meets Smart Cards Gary Mc Graw

Java Security Meets Smart Cards Gary Mc. Graw, Ph. D. Vice President, Corporate Technology Cigital http: //www. cigital. com

This lecture made possible by. . . • Software Risk Management authority: – safety, security, reliability – services and technology for making software behave • Clients include: – Visa, Master. Card, Agile, Microstrategy, Ericsson, Motorola, Microsoft, NSF, DARPA, NIST’s Advanced Technology Program

The classic security tradeoff 3

Java’s answer • Add as much functionality as is prudent while managing security risks • JDK 1. 0. 2 Sandbox • JDK 1. 1 Code signing • Java 2 Shades of gray • JVMs for mobility • Java Virtual Machine • A language-based approach to mobile code security is complex • Java is by far the best approach available • Java has had real security problems 4

A question of trust 5

Untrusted code is restricted • The Virtual Machine mediates access • Some code cannot make direct system calls • Code can be forbidden to: – – access the filesystem open sockets (except back home) interfere with other applets spy on the local environment • See Frank Yellin’s paper or Java Security – Java Security Hotlist – http: //www. cigital. com/javasecurity/hotlist. html

Type safety • Each piece of memory has a type • Type system must work for security to work – type safety is the cornerstone of Java security – guarantee that a program can’t treat pointers as integers and vice versa • Java uses static type checking to ensure this • Because the type system is complicated, it is error prone Note: type safety is NOT security

The original sandbox The Byte Code Verifier • Verify Java byte code before running it The Class Loader System • Load local and network classes separately The Security Manager • Keep tabs on “dangerous” methods

Four attack classes • System modification • Invasion of privacy There is some overlap among these classes, but they make the risks easier to understand • Denial of service • Antagonism

A chronology of attack applets • February 96: DNS flaw in JDK 1. 0. 1 • March 96: Path name bug • March 96: Princeton Class Loader bug • May 96: type casting attack • June 96: Array type implementation error • July 96: More type casting problems • August 96: Flaw in Microsoft’s Java VM • February 97: Invasion of Privacy attack applets • March 97: JVM hole • April 97: Code signing flaw • May 97: Verifier problems discovered in many VMs • July 97: Vacuum bug • August 97: redirect bug • July 98: Class. Loader bug • March 99: Verifier hole • August 99: Race condition • October 99: Verifier hole 2 • August 2000: Brown Orifice • October 2000: Active. X/Java All of these bugs have been fixed. 10

JDK 1. 1 • Classes for developers of secure systems – Crypto API started • SHA, MD 5, digital signatures – More crypto in U. S. • DES • possibly RSA • Signed applets – JDK 1. 1 signing makes classes “local” (system) – trust models introduced

Java 2 • Fine-grained access control – no longer requires hacking Class. Loader and Security. Manager • Configurable security policy – this is very hard to do correctly – managing policy • Extensible access control structure – typed permissions and automatic handling • Trust little stance – built-in code will no longer be trusted – signed local classes – no more hacking the zip archive!

Stack inspection • Security decisions in • All three vendors use Java 2 are made by variation of stack searching the runtime inspection call stack • Very little prior art – this is an implementation dependent strategy – seemingly ad hoc – restricts compiler optimization – LISP dynamic binding – effective UID in unix • Formalized by the Princeton team

Mobile code on smart cards Java Virtual Machines get small

How Java and smart cards mix • Java Card is a stripped down version of Java for smart cards – up to version 2. 1. 1 (and security is improving) – one major vendor behind Java Card is Visa • Java Card makes multi-application cards based on a common platform possible – open up smart card development – use a real language 15

How can Java fit on a card? • • • Supported Java Features packages dynamic object creation virtual methods interfaces exceptions • • • Unsupported Java Features dynamic class loading security manager threading object cloning garbage collection large data types 16

Multi-application cards • Multi-application cards are an important goal – getting more developers on board is essential • Multiple applets can execute on a card – credit, debit, e-cash, loyalty programs • Explicit and covert channels between applets must be eliminated – software risk management – “applet firewall” is minimal at best 17

Java Card security != Java security Good • no dynamic class loading – type safety issues • only one active applet • no threading • objects include rudimentary access control Bad • applets added post issuance (ARGH) • no sandbox – trusted code required • • native method calls no garbage collection object sharing complexity out of band verification 18

Security risks in Java Card 2. 1 • protocol interactions – sharing secrets between protocols introduces new problems • security is hard – linking, export, CAP files – native methods – verification – object sharing • multi-application risks – applets MUST behave • the usual suspects apply – physical attacks – side-channel monitoring (DPA) – the terminal problem 19

Multi-application issues Secure Features • no dynamic class loading – reduces threat of malicious applets • no multi-threading – non-interference • applet firewalls – prevents referencing another applet’s objects Risks and Assumptions • trust-based applet model – assume applets are non-malicious – security testing • JCRE must be perfect – prevents collusion • more developers? ! 20

Physical attacks still apply • Physical attacks attempt to reverse engineer card or monitor a running card to obtain card secrets – Differential power analysis (Kocher) – No card is tamper proof (Anderson & Kuhn) • Cards often include secrets from owner • Some secrets could be used to add functionality and/or add value – Cost of hacking the card must be greater than return on investment 21

The terminal problem • No trusted interface for interacting with users • A common solution is to use PCs – but PCs are easily hacked – windows 95/98 are inherently insecure • Some suggestions – palm pilot? (Felten’s Usenix 99 paper) – simple dedicated devices 22

Protocol interaction risks • Unintended protocol interactions pose risks: – secure protocols do not necessarily compose – different protocols share same key material – observation of protocol P can be used against Q • Shared key material is motivated by: – digital certificates for multi-applications – small memory for public/private key pairs – crypto APIs 23

Security is harder than it sounds • Java Card is not truly “cross platform” – byte code CAP – export files • linking problems – no strings, thus tables • code verification? – before conversion • native methods BAD • INT? (32 bits) • applet testing and debugging issues • sharing methods among applets (difficult) • ISO 7816 APDU problems • hostile applets – denial of service • exception handling 24

What to do? • Assume the platform is secure – it really is getting better – Cigital has extensive security tests for Globlal Platform • Applets must be carefully designed and implemented • Testing applets for security is essential • Java Card Security = platform + applets • Did I say security testing? 25

Conclusion • Java Card and other flavors of Java will open new markets • New technologies pose significant risks when deployed in security-critical applications – Java Card mitigates some risks associated with Java such as dynamic class loading – Existence of multiple applets (mobile code) is a significant risk that must be mitigated by solid software risk management 26

Where to learn more Cigital provides expert advice on smart card and mobile system software security issues. • Contact Ed Mc. Comas (mccomas@cigital. com) • http: //www. securingjava. com – Chapter 8: Java Card Security http: //www. cigital. com gem@cigital. com 27