Title: When Mobile Code and Smart Cards Meet: Java Card Security
1When Mobile Code and Smart Cards Meet Java Card
Security
- Gary McGraw, Ph.D.
- Vice President, Corporate Technology
- Cigital
- http//www.cigital.com
2This 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, NISTs Advanced Technology
Program
3Why 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!
- weve only scratched the surface
4Mobile 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, ...
5Mobile code is dumb
- Running somebody elses 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
6A 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
7Mobile 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
8The classic security tradeoff
Security
Functionality
9Javas 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
10A question of trust
11Untrusted 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 Yellins paper or Java Security
- Java Security Hotlist
- http//www.rstcorp.com/javasecurity/hotlist.html
12Type 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 cant 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
13The 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
14Four attack classes
- System modification
- Invasion of privacy
- Denial of service
- Antagonism
There is some overlap among these classes, but
they make the risks easier to understand
15A 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 96Flaw in Microsofts 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.
16JDK 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
17Java 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!
18Stack 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
19Mobile code on smart cards
- Java Virtual Machines get small
20What 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
21How 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
22How 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
23Multi-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
24Java 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
25Security 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
26Multi-application issues
- Secure Features
- no dynamic class loading
- reduces threat of malicious applets
- no multi-threading
- non-interference
- applet firewalls
- prevents referencing another applets objects
- Risks and Assumptions
- trust-based applet model
- assume applets are non-malicious
- security testing
- JCRE must be perfect
- prevents collusion
- more developers?!
27Physical 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
28The 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? (Feltens Usenix 99 paper)
- simple dedicated devices
29Protocol 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
30Security 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
31What 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?
32Conclusion
- 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
33Where to learn more
- Cigital provides expert advice on
- smart card and mobile system
- software security issues.
- Contact Pat Higgens (phiggens_at_cigital.com)
- http//www.securingjava.com
- Chapter 8 Java Card Security
http//www.cigital.com gem_at_cigital.com