Java VM’s and Security Gary McGraw, Ph.D. [email protected] .

Java VM’s and Security

Gary McGraw, [email protected]://www.cigital.com

2

Today Java lives hereToday Java lives here

3

And requires no wiresAnd requires no wires

Internet

4

Let the games beginLet the games begin

5

The classic security tradeoffThe classic security tradeoff

• How do resource constraints impact Java’s standard security mechanisms?

• Strategy: understand the endpoints– Classic Java Security Architecture– Java Card Security

Classic Java Security

JVM security mechanisms (in the large)

7

Java’s answerJava’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

8

A question of trustA question of trust

Untrusted code is restrictedUntrusted 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 safetyType 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 proneNote: type safety is NOT security

The original sandboxThe 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 classesFour 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

JDK 1.1JDK 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 2Java 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 inspectionStack 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 really small

17

How Java and smart cards mix

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

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

19

Multi-application cardsMulti-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

Java Card security != Java security

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

21

Security risks in Java Card 2.1

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

22

Multi-application issuesMulti-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?!

23

Physical attacks still applyPhysical 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

Security is harder than it sounds

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

25

What to do?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?

The DARPA-hard issue

Provide a scientific framework for understanding VM security mechanisms

27

The Java VM rangeThe Java VM range

J2EE

J2SE

JavaCard

J2ME

MicroChai

TINI

More resources

28

VMs and securityVMs 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?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 nowWhat 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

PointersPointers

• http://www.securingjava.com– Chapter 8: Java Card Security

http://[email protected]