When Mobile Code and Smart Cards Meet: Java Card Security Gary McGraw, Ph.D. Vice President, Corporate Technology Cigital

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

3 Why use mobile code? Offload processing from servers –CGI bottlenecks –look and feel problems –cross-platform solution desirable Mobile devices –Phones –Smart cards –PDAs Managing highly interconnected distributed systems –the famed Internet toaster –IP numbers for everything! –weve only scratched the surface

4 Mobile code is smart Code that traverses the network during its lifetime and executes at the destination machine –send around data that automatically executes –the more platforms, the better –embedded, mobile devices need this! Many forms –Java, ActiveX, Postscript, TCL/tk, Word macros, JavaScript, VBScript,...

5 Mobile code is dumb Running somebody elses code is risky What might it do? What if it is hostile? How can we protect against possible attack? Not a new problem! IEEE IC, 2(6), Nov/Dec 1998

6 A brief history 1980s –downloading arbitrary binaries and executing them is a BAD IDEA –Archie and ftp –risks include: Trojan Horses viruses –checksumming to the rescue? 1992 –the Web arrives –Archie dies 1995 –Java and Javascript introduce widespread mobile code –the concept virus appears 1999 –Melissa 2000 –The Love Bug

7 Mobile code and security JavaScript –invasion of privacy –denial of service –Web spoofing Macro problems –the concept virus –the Melissa virus –the Love Bug ActiveX –system modification attacks –stealing money Java security –more power equals more risk –attack applets in the lab

8 The classic security tradeoff

9 Javas answer Add as much functionality as is prudent while managing security risks JDK 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

10 A question of trust

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 Yellins paper or Java Security –Java Security Hotlist –

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 cant 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 Denial of service Antagonism There is some overlap among these classes, but they make the risks easier to understand

15 A chronology of attack applets February 96: DNS flaw in JDK 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 Microsofts 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: ClassLoader bug March 99: Verifier hole August 99: Race condition October 99: Verifier hole 2 August 2000: Brown Orifice October 2000: ActiveX/Java All of these bugs have been fixed.

JDK 1.1 Classes for developers of secure systems –Crypto API started SHA, MD5, 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 ClassLoader and SecurityManager 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 Java 2 are made by searching the runtime call stack –this is an implementation dependent strategy –seemingly ad hoc –restricts compiler optimization All three vendors use variation of stack inspection Very little prior art –LISP dynamic binding –effective UID in unix Formalized by the Princeton team

Mobile code on smart cards Java Virtual Machines get small

20 What is a smart card? A simple processor embedded in a plastic card –Same size as a credit card New technology allows multiple applications on the same card Useful for hundreds of applications –Debit, credit, cash –Identity, cryptography

21 How Java and smart cards mix Java Card is a stripped down version of Java for smart cards –up to version 2.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

22 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

23 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

24 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

25 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

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

27 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

28 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? (Feltens Usenix 99 paper) –simple dedicated devices

29 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

30 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 exception handling 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

31 What to do? Assume the platform is secure –it really is getting better Applets must be carefully designed and implemented Testing applets for security is essential Java Card Security = platform + applets Did I say security testing?

32 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

33 Where to learn more Cigital provides expert advice on smart card and mobile system software security issues. Contact Pat Higgens –Chapter 8: Java Card Security