Download SmartCard Security and the JavaCard

Java VM’s and Security
Gary McGraw, Ph.D.
[email protected]
http://www.cigital.com
Today Java lives here
2
And requires no wires
Internet
3
Let the games begin
4
The classic security tradeoff
• How do resource constraints impact Java’s standard
security mechanisms?
• Strategy: understand the endpoints
– Classic Java Security Architecture
– Java Card Security
5
Classic Java Security
JVM security mechanisms (in the large)
Java’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
7
A question of trust
8
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
• Invasion of privacy
There is some
overlap among these
classes, but they
make the risks easier
to understand
• Denial of service
• Antagonism
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 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
17
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
18
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
19
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
20
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
21
Multi-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?!
22
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
23
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
24
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?
25
The DARPA-hard issue
Provide a scientific framework for understanding VM
security mechanisms
The Java VM range
JavaCard
MicroChai
J2EE
More resources
TINI
J2ME
J2SE
27
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
28
Is this a house of cards?
What happens when we knock down a few of the
cards supporting the structure?
?
29
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
30
Pointers
• http://www.securingjava.com
– Chapter 8: Java Card Security
http://www.cigital.com
[email protected]
31