Classic Java Security

JVM security mechanisms (in the large)

Java’s answer

• Add as much • Java Virtual Machine

functionality as is • A language-based
prudent while approach to mobile
managing security code security is
risks complex
• JDK 1.0.2 Sandbox • Java is by far the
• JDK 1.1 Code signing best approach
• Java 2 Shades of available
gray • Java has had real
• JVMs for mobility security problems

2
A question of trust

3
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 • Denial of service

• Invasion of privacy • Antagonism

There is some
overlap among these
classes, but they
make the risks easier
to understand
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 • Extensible access control

control structure
– no longer requires hacking – typed permissions and
ClassLoader and automatic handling
SecurityManager • Trust little stance
• Configurable security – built-in code will no longer
policy be trusted
– this is very hard to do – signed local classes
correctly – no more hacking the zip
– managing policy archive!
Stack inspection

• Security decisions in • All three vendors use

Java 2 are made by variation of stack
searching the inspection
runtime call stack • Very little prior art
– this is an – LISP dynamic binding
implementation
– effective UID in unix
dependent strategy
– seemingly ad hoc • Formalized by the
– restricts compiler Princeton team
optimization
Mobile code on smart cards

Java Virtual Machines get really 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

12
How can Java fit on a card?

Supported Java Unsupported Java

Features Features
• packages • dynamic class loading
• dynamic object • security manager
creation • threading
• virtual methods • object cloning
• interfaces • garbage collection
• exceptions • large data types

13
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

14
Java Card security != Java security

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

15
Security risks in Java Card 2.1

• protocol interactions • multi-application risks

– sharing secrets – applets MUST behave
between protocols
introduces new • the usual suspects
problems apply
• security is hard – physical attacks
– linking, export, CAP – side-channel
files monitoring (DPA)
– native methods – the terminal problem
– verification
– object sharing

16
Multi-application issues

Secure Features Risks and Assumptions

• no dynamic class • trust-based applet
loading model
– reduces threat of
– assume applets are
malicious applets
non-malicious
• no multi-threading
– security testing
– non-interference
• JCRE must be perfect
• applet firewalls
– prevents collusion
– prevents referencing
another applet’s • more developers?!
objects
17
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

18
Security is harder than it sounds

• Java Card is not truly • native methods BAD

“cross platform” • INT? (32 bits)
– byte code  CAP
• applet testing and
– export files
debugging issues
• linking problems • sharing methods among
– no strings, thus tables
applets (difficult)
• code verification? • ISO 7816 APDU
– before conversion
problems
• exception handling • hostile applets
– denial of service

19