Securing Java applets

1
Securing Java applets

• Erik Poll
• Security of Systems (SOS) group
• University of Nijmegen
• www.cs.kun.nl/erikpoll

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

3
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

4
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

5
Java Card architecture
applet
applet
applet
Java Card platform (JCRE) - miniature OS
JC Virtual Machine
JC API
Global Platform
smart card hardware
6
Production of a Java Card applet
bytecode verifier
cap generator
compiler
byte code
source code
cap file

• Options
• only pre-loaded applets
• only digitally signed applets (using Global
  Platform)

download
Remaining issue how do we certify these
pre-loaded or signed applets?
7
Security questions

• Is my applet correct and secure?
• correct is necessary precondition for secure
• Is the platform correct and secure ?
• Is someone elses applet is not malicious
• ie. will it not
• annoy users,
• interfere with other applets, or
• damage the platform ?

8
Java applet security

• language level security
• basic guarantees (no buffer overflows)
• platform level security
• imposes additional restrictions to protect
  platform other applets (firewall/sandbox)
• application level security
• applet responsible for own specific correctness
  security needs

9
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
k
i
r
e
0
0
0
4
1
2
3
5
10
Buffer overflows

• Single biggest cause of bugs security holes
• 30-70 of all security alerts www.cert.org/advisor
  ies
• 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 dont use C(), use Java or C

11
Java applet security

• language level security
• basic guarantees (no buffer overflows)
• platform level security
• imposes additional restrictions to protect
  platform other applets (firewall/sandbox)
• application level security
• applet responsible for own specific correctness
  security needs

12
Security questions

• Is my applet correct and secure?
• correct is necessary precondition for secure
• Is the platform correct and secure ?
• Is someone elses applet is not malicious
• ie. will it not
• annoy users,
• interfere with other applets, or
• damage the platform ?
• Security evaluations must answer these questions

13

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

14
How do we certify software ?

• testing
  
• but testing that applet does what it should do is
  easier
• than testing that applet does not do what it
  should not do
• coding standards, design standards
• code reviews
• formal methods...

15
VerifiCard
16
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

17
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

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

19
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

20
Work on applet level

• At INRIA, SICS, Kaiserslautern, Nijmegen
• Formal specification and verification of Java
  Card applets, in particular using JML

21
Java Card applet specification and verification
using JML
22
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

23
JML Example
Java compiler ignores this line
but JML tools will parse it

• //_at_ requires amount gt 0
• public void debit(int amount)
• ....

this precondition makes an assumption explicit
19 of bugs are due to lack of input validation
24
JML Example

• //_at_ requires amount gt 0
• ensures balance \old(balance) amount
• signals (PurseException)
• balanace \old(balance)
• _at_/
• public void debit(int amount)
• ....

this precondition makes an assumption explicit
19 of bugs are due to lack of input validation
25
JML Example

• private int balance
• final static int MAX_BALANCE
• /_at_ invariant 0 lt balance
• balance lt MAX_BALANCE
• _at_/

26
JML Example

• private byte pin
• /_at_ invariant
• pin ! null
• pin.length 4
• (\forall int i 0 lt i i lt 4
• 0 lt pini pini lt
  9)
• _at_/

27
JML Example

• private byte appletState
• /_at_ constraint
• \old(appletState) BLOCKED
• gt appletState BLOCKED
• constraint
• \old(appletState) ! PERSONALISED
• gt appletState ! PERSONALISED
• _at_/

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

29
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

30
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

31
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

32
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 Moores law rescue us here ?

33
Conclusions
34
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

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