When Mobile Code and Smart Cards Meet:

Java Card Security

Gary McGraw, 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, Agile, Microstrategy, Ericsson, Motorola,
Microsoft, NSF, DARPA, NIST’s Advanced Technology
Program
Why use mobile code?

• Offload processing • Managing highly

from servers interconnected
– CGI bottlenecks distributed systems
– look and feel – the famed Internet
problems
toaster
– cross-platform
solution desirable – IP numbers for
everything!
• Mobile devices
– we’ve only scratched
– Phones
the surface
– Smart cards
– PDAs

3
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, ...

4
Mobile code is dumb

• Running somebody else’s

code is risky
• What might it do?
• What if it is hostile?
• How can we protect
against possible attack?

Not a new problem!

5
IEEE IC, 2(6), Nov/Dec 1998
A brief history

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

6
Mobile code and security

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

7
The classic security tradeoff

8
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

9
A question of trust

10
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.rstcorp.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
A chronology of attack applets

• February 96: DNS flaw in JDK • February 97: Invasion of

1.0.1 Privacy attack applets
• March 96: Path name bug • March 97: JVM hole
• April 97: Code signing flaw
• March 96: Princeton Class
• May 97: Verifier problems
Loader bug discovered in many VMs
• May 96: type casting attack • July 97: Vacuum bug
• June 96: Array type • August 97: redirect bug
implementation error • July 98: ClassLoader bug
• July 96: More type casting • March 99: Verifier hole
problems • August 99: Race condition
• August 96:Flaw in Microsoft’s • October 99: Verifier hole 2
Java VM • August 2000: Brown Orifice
• October 2000: ActiveX/Java
All of these bugs have been fixed. 15
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 runtime inspection
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 small

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

20
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

21
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

22
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

23
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

24
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

25
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
26
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

27
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

28
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

29
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
• sharing methods among
• linking problems
applets (difficult)
– no strings, thus tables
• ISO 7816 APDU
• code verification? problems
– before conversion • hostile applets
• exception handling – denial of service

30
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?

31
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

32
Where to learn more

Cigital provides expert advice on

smart card and mobile system
software security issues.
• Contact Pat Higgens ([email protected])

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

http://www.cigital.com
[email protected] 33