When Mobile Code and Smart Cards Meet: Java Card Security Gary McGraw, Ph.D. Vice President, Corporate Technology Cigital http://www.cigital.com
Mar 29, 2015
When Mobile Code and Smart Cards Meet: Java Card Security
Gary McGraw, Ph.D.Vice President, Corporate Technology
Cigitalhttp://www.cigital.com
This lecture made possible by...
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
3
Why use mobile code?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
4
Mobile code is smartMobile 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, ...
5
Mobile code is dumbMobile 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
6
A brief history 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
7
Mobile code and securityMobile 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
8
The classic security tradeoffThe classic security tradeoff
9
Java’s answerJava’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
10
A question of trustA question of trust
Untrusted code is restrictedUntrusted 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 safetyType 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 proneNote: type safety is NOT security
The original sandboxThe 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 classesFour 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
15
A chronology of attack applets
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.
JDK 1.1JDK 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 2Java 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 inspectionStack 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
20
What is a smart card?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
21
How Java and smart cards mix
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
22
How can Java fit on a card?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
23
Multi-application cardsMulti-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
24
Java Card security != Java security
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
25
Security risks in Java Card 2.1
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
26
Multi-application issuesMulti-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?!
27
Physical attacks still applyPhysical 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
28
The terminal problemThe 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
29
Protocol interaction risksProtocol 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
30
Security is harder than it sounds
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
31
What to do?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?
32
ConclusionConclusion
• 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
33
Where to learn moreWhere to learn more
Cigital provides expert advice onsmart card and mobile systemsoftware security issues.• Contact Pat Higgens ([email protected])
• http://www.securingjava.com– Chapter 8: Java Card Security
http://[email protected]