Java VM’s and Security

1. Java VM’s and Security Gary McGraw, Ph.D. gem@cigital.com http://www.cigital.com

2. Today Java lives here

3. Internet And requires no wires

4. Let the games begin

5. The classic security tradeoff Security Functionality • How do resource constraints impact Java’s standard security mechanisms? • Strategy: understand the endpoints • Classic Java Security Architecture • Java Card Security

6. Classic Java Security JVM security mechanisms (in the large)

7. 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 Java’s answer

8. A question of trust

9. 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

10. 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

11. 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

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

13. 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

14. 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! Java 2

15. 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 Stack inspection

16. Mobile code on smart cards Java Virtual Machines get really small

17. 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

18. 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 How can Java fit on a card?

19. 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

20. 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 Java Card security != Java security

21. 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 Security risks in Java Card 2.1

22. 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?! Multi-application issues

23. 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

24. 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 Security is harder than it sounds

25. 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?

26. The DARPA-hard issue Provide a scientific framework for understanding VM security mechanisms

27. The Java VM range JavaCard MicroChai J2EE More resources TINI J2SE J2ME

28. VMs and security • Different resource constraints support different language and VM features • Features removed to save memory/time/battery • Little formal impact analysis • Java’s security architecture is a set of interconnected blocks • Meant to work in concert • Mutually dependant

29. Is this a house of cards? What happens when we knock down a few of the cards supporting the structure? ?

30. What we’re doing now • Examining security models of the Java language and VMs • Bytecode verifier, Class loader, Security Manager, Stack Inspection • Multi-threading, Garbage Collection, etc • Examining select implementations of smaller Java VMs • Real implemented systems • Understanding how physical constraints impact security • Memory • Power (both computational and battery) • Connection • Environment

31. http://www.securingjava.com Chapter 8: Java Card Security Pointers http://www.cigital.com gem@cigital.com