Securing Java applets

Securing Java applets

Erik PollSecurity of Systems (SOS)

groupUniversity of Nijmegen

www.cs.kun.nl/~erikpoll

Erik Poll Securing Java applets 2

Overview

• Security problems of Java Card applets or any other piece of software, for that matter

• Work in the EU-IST project VerifiCard

• Work on formal techniques for applet verification in Nijmegen


Java applet

Java application (piece of software) that is deployed independently on some platform, with some operating system (OS), eg– Java Card smart card applet– mobile phone (eg midlet on MIDP phone)– PDA– web browser– PC– airplane


Old vs new smart cards

• one program (applet)

• written in machine-code,

specific to chip and OS

• burnt into ROM

• Applet written in high-level language (Java Card)

• compiled into bytecode• stored in EEPROM• interpreted on card

Options:• multi-application: several

applets on one card• post-issuance: adding or

deleting applets on card


Java Card platform (JCRE)- miniature OS

Java Card platform (JCRE)- miniature OS

Java Card architecture

smart card hardwaresmart card hardware

ap

ple

tap

ple

t

ap

ple

tap

ple

t

ap

ple

tap

ple

t

JC VirtualMachine

JCAPI

Global Platform


Production of a Java Card applet

bytecode

sourcecode

capfile

compiler

capgenerato

r

downloadOptions:•only pre-loaded applets•only digitally signed applets (using Global Platform)Remaining issue: how do we certify these pre-loaded or signed applets?

bytecodeverifier


Security questions

1. Is my applet correct and secure?“correct” is necessary precondition for

“secure”2. Is the platform correct and secure ?3. Is someone else’s applet is not malicious ie. will it not

– annoy users,– interfere with other applets, or– damage the platform ?


Java applet security

1. language level security– basic guarantees (no buffer

overflows)2. platform level security

– imposes additional restrictions to protect platform & other applets (firewall/sandbox)

3. application level security– applet responsible for own specific

correctness & security needs


Buffer overflows

Example• Application asks for 4-digit PIN code• User supplies a 5-digit PIN code 12345• What happens in the memory ?

0 0 kire0 00 41 2 3 5


Buffer overflows

• Single biggest cause of bugs & security holes– 30-70% of all security alerts

www.cert.org/advisories – 36% of all bugs at Microsoft

• Possible - and frequent - in C, C++ although there are good tools to detect them...

• Impossible in modern languages: Java, C#

• Conclusion: don’t use C(++), use Java or C#


Java applet security

1. language level security– basic guarantees (no buffer

overflows)2. platform level security

– imposes additional restrictions to protect platform & other applets (firewall/sandbox)

3. application level security– applet responsible for own specific

correctness & security needs


Security questions

1. Is my applet correct and secure?“correct” is necessary precondition for “secure”

2. Is the platform correct and secure ?3. Is someone else’s applet is not malicious ie. will it not

– annoy users,– interfere with other applets, or– damage the platform ?

Security evaluations must answer these questions


• NB Even perfectly secure applet running on perfectly secure platform may suffer from malicious applets

• For example– a malicious applet on mobile phone could

simply ask user to type in the PIN code

• Protection against such Trojan Horses will require human source code inspection of untrusted, potentially hostile, applets ?


How do we certify software ?

1. testing but testing that applet does what it should do is easier than testing that applet does not do what it should not

do

2. coding standards, design standards

3. code reviews

4. formal methods...


VerifiCard


VerifiCard

• EU-funded project for developing and applying formal methods for the specification and verification of the Java Card – platform and – applets

• Partners: universities, research institutes, smart card manufacturers

• www.verificard.org


Why formal methods ? (I)

required by highest levels of certification in Common Criteria

and there are increasing demands for higher levels of CC security evaluation


Why formal methods ? (II)

Central problem in ensuring that software is correct or secure:– We have long documents in English giving

functional specs, security requirements, ...– How to ensure that

• these specs are consistent & complete ?• our implementations actually meet them ?

– If we can express parts of these documents in formal languages, we have more options...


Work on platform level

• At INRIA & TUM

• Formalisation of Java Card Virtual Machine

• Development of a provably correct byte code verifier

• This relies on the use of mechanical theorem provers


Work on applet level

• At INRIA, SICS, Kaiserslautern, Nijmegen

• Formal specification and verification of Java Card applets, in particular using JML


Java Card applet specification and

verification using JML


JML (Gary Leavens et al)

• Formal specification language for Java– JML specs added as annotations is Java

source code files

• Easy to learn– small extension of Java syntax

• Supported by a range of tools


JML Example

//@ requires amount >= 0;public void debit(int amount) {....}

Java compiler ignores this line

but JML tools will parse it

19% of bugs are due to lack of input validation

this precondition makes an assumption explicit


JML Example

//@ requires amount >= 0; ensures balance == \old(balance) –

amount; signals (PurseException) balanace == \old(balance); @*/public void debit(int amount) {....}

19% of bugs are due to lack of input validation

this precondition makes an assumption explicit


JML Example

private int balance;final static int MAX_BALANCE;

/*@ invariant 0 <= balance && balance < MAX_BALANCE; @*/


JML Example

private byte[] pin;/*@ invariant pin != null && pin.length == 4 && (\forall int i; 0 <= i && i < 4 ; 0 <= pin[i] && pin[i] <= 9); @*/


JML Example

private byte appletState;/*@ constraint \old(appletState) == BLOCKED ==> appletState == BLOCKED; constraint \old(appletState) != PERSONALISED ==> appletState != PERSONALISED; @*/


Using JML

• Many “soundness/safety” properties of Java (Card) program can be easily specified in JML

• Such properties help in understanding code

• For such properties we can use tools to check that implementations satisfy them

• There are different tools, offering different levels of assurance at different costs...


Tools for JML

• parser & type-checker– no typos in specs

• runtime assertion checker (Iowa State, Gary Leavens)

– tests if any specs are violated at runtime • static checker ESC/Java (Compaq, Rustan Leino et al.)

– automatic verification of simple properties• interactive program verifier LOOP (Nijmegen)

– interactive verification of any property


Testing & verification

• Testing considers a limited set of inputs

• Verification covers all possible inputs

• Testing is easier with a formal (JML) spec that we can test against


Applet verification: achievements

• Verification of real industrial smart card applet (EMV applet)

• Verification revealed uncaught exceptions that were not detected during normal testing

• Gemplus has developed JACK tool supporting JML, integrated in IDE their developers use


Conclusions about applet verification

• Formal specification languages and tools can help when doing a code review

• Interactive program verification probably still too costly, but automated program verification seems to provide good return-on-investment

• How far can we push level of automation ?– Will Moore’s law rescue us here ?


Conclusions


Old vs new generation smart cards

Some points to note:• some security concerns are the same, eg

– is the smart card OS correct and secure ?– is our application correct and secure ?

• possible advantages of Java Card:– Java Card OS better studied than others – our knowledge of and tools for Java may

allow better & cheaper security evaluations


Conclusions

• Java Card interesting opportunity to apply state-of-the-art formal methods developed in academia for Java.

• Increasing need about (security) certification of software. Central challenge: How can we express security requirements in a (semi)-formal way ?

Documents

Securing Java applets