Download Power point

Java Security Meets Smart Cards
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, MasterCard, Agile, Microstrategy, Ericsson,
Motorola, Microsoft, NSF, DARPA, NIST’s Advanced
Technology Program
The classic security tradeoff
3
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
4
A question of trust
5
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
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.
10
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
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
15
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
16
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
17
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
18
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
19
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?!
20
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
21
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
22
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
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
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
26
Where to learn more
Cigital provides expert advice on
smart card and mobile system
software security issues.
• Contact Ed McComas
([email protected])
• http://www.securingjava.com
– Chapter 8: Java Card Security
http://www.cigital.com
[email protected]
27