Download SmartCard Security and the JavaCard

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
from servers
– CGI bottlenecks
– look and feel
problems
– cross-platform
solution desirable
• Mobile devices
– Phones
– Smart cards
– PDAs
• Managing highly
interconnected
distributed systems
– the famed Internet
toaster
– IP numbers for
everything!
– we’ve only scratched
the surface
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!
IEEE IC, 2(6), Nov/Dec 1998
5
A brief history
• 1980s
– downloading arbitrary
binaries and executing
them is a BAD IDEA
– Archie and ftp
– risks include:
• Trojan Horses
• viruses
– checksumming to the
rescue?
• 1992
– the Web arrives
– Archie dies
• 1995
– Java and Javascript
introduce widespread
mobile code
– the concept virus
appears
• 1999
– Melissa
• 2000
– The Love Bug
6
Mobile code and security
• JavaScript
– invasion of privacy
– denial of service
– Web spoofing
• Macro problems
– the concept virus
– the Melissa virus
– the Love Bug
• ActiveX
– system modification
attacks
– stealing money
• Java security
– more power equals
more risk
– attack applets in the
lab
7
The classic security tradeoff
8
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
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
• Invasion of privacy
There is some
overlap among these
classes, but they
make the risks easier
to understand
• Denial of service
• Antagonism
A chronology of attack applets
• February 96: DNS flaw in JDK
1.0.1
• March 96: Path name bug
• March 96: Princeton Class
Loader bug
• May 96: type casting attack
• June 96: Array type
implementation error
• July 96: More type casting
problems
• August 96:Flaw in Microsoft’s
Java VM
• February 97: Invasion of
Privacy attack applets
• March 97: JVM hole
• April 97: Code signing flaw
• May 97: Verifier problems
discovered in many VMs
• July 97: Vacuum bug
• August 97: redirect bug
• July 98: ClassLoader bug
• March 99: Verifier hole
• August 99: Race condition
• October 99: Verifier hole 2
• 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
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 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
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
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
• 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
24
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
25
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?!
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
“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
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