when mobile code and smart cards meet java card security l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
When Mobile Code and Smart Cards Meet: Java Card Security PowerPoint Presentation
Download Presentation
When Mobile Code and Smart Cards Meet: Java Card Security

Loading in 2 Seconds...

play fullscreen
1 / 33

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


  • 272 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'When Mobile Code and Smart Cards Meet: Java Card Security' - arleen


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
when mobile code and smart cards meet java card security

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

Why use mobile code?
mobile code is smart
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, ...
mobile code is dumb
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

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

A brief history
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

Mobile code and security
the classic security tradeoff
The classic security tradeoff

Security

Functionality

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

Java’s answer
untrusted code is restricted
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
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 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

Denial of service

Antagonism

Four attack classes

There is some overlap among these classes, but they make the risks easier to understand

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

A chronology of attack applets

All of these bugs have been fixed.

jdk 1 1
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!

Java 2
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

Stack inspection
mobile code on smart cards

Mobile code on smart cards

Java Virtual Machines get small

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

How can Java fit on a card?
multi application cards
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
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

Java Card security != Java security
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

Security risks in Java Card 2.1
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?!

Multi-application issues
physical attacks still apply
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
the terminal problem
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
protocol interaction risks
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
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

Security is harder than it sounds
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?
conclusion
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
where to learn more
Cigital provides expert advice on

smart card and mobile system

software security issues.

Contact Pat Higgens (phiggens@cigital.com)

http://www.securingjava.com

Chapter 8: Java Card Security

Where to learn more

http://www.cigital.com

gem@cigital.com