When Mobile Code and Smart Cards Meet: Java Card Security - PowerPoint PPT Presentation

About This Presentation
Title:

When Mobile Code and Smart Cards Meet: Java Card Security

Description:

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 ... – PowerPoint PPT presentation

Number of Views:645
Avg rating:3.0/5.0
Slides: 34
Provided by: RST
Category:

less

Transcript and Presenter's Notes

Title: When Mobile Code and Smart Cards Meet: Java Card Security


1
When Mobile Code and Smart Cards Meet Java Card
Security
  • Gary McGraw, Ph.D.
  • Vice President, Corporate Technology
  • Cigital
  • http//www.cigital.com

2
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, NISTs Advanced Technology
    Program

3
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!
  • weve only scratched the surface

4
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, ...

5
Mobile 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
6
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 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 tradeoff
Security
Functionality
9
Javas 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 trust
11
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 Yellins paper or Java Security
  • Java Security Hotlist
  • http//www.rstcorp.com/javasecurity/hotlist.html

12
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 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
13
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

14
Four 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
  • 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.
16
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

17
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!

18
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

19
Mobile code on smart cards
  • Java Virtual Machines get small

20
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
  • 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?
  • 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 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
  • 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
  • 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 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?!

27
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

28
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? (Feltens Usenix 99 paper)
  • simple dedicated devices

29
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

30
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?
  • 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
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

33
Where 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
Write a Comment
User Comments (0)
About PowerShow.com