Bytecode Verification on Java Smart Cards

1
Bytecode Verification on Java Smart Cards

• Xavier Leroy
• Presentation(day 1)
• -Nithya

2
Overview

• JavaCard Architecture
• Sandbox model
• Suns Bytecode verification
• Our Verification Algorithm
• Performance Analysis of both
• Differences

3
Overview of JVM

• Stack based abstract machine
• - Instructions pop their arguments off the
  stack
• - Push their results on the stack
• Set of registers (local variables) can be
  accessed via load and store
• - push the value of a register on the stack
• - store the top of the stack in the register
• Stack register -gt activation record for a method

4
Type-correctness eg. of JVM

• Iadd
• - Stack initially contains at least 2 elements
  of type int and it pushes back result of int
• Getfield C.f. t
• - Top of the stack contains a reference to an
  instance of class C
• - it then pops it and pushes back a value of type
  t (the value of the field f)

5
Conditions for JVMs proper operation

• Type Correctness
• No stack overflow or underflow
• Code containment
• Register initialization
• Object initialization

6
Smart Cards

• What are Smart Cards?
• Security tokens - applications
• Traditional Smart Cards
• - C or Assembler
• Challenged by Open Architectures
• - Multos, Java Card

7
Java Card Architecture

• Applications written in Java and so are portable
  across all Java cards
• Java Cards can run multiple applications which
  can communicate thru shared objects
• New applications called applets can be downloaded
  on the card post issuance

8
Security Issues (by malicious applet)

• Leaking confidential information outside (eg
  PINS and secret cryptographic keys)
• Modifying sensitive information (eg balance of
  an electonic purse)
• Interfering with other honest application on the
  card (Trojan Attack)

9
Solution

• Put forward by Java Programming Environment
• Execute the applets in a so called Sandbox
• Its an insulation layer preventing direct access
  to the hardware resources
• Also implements a suitable access control policy

10
Sandbox Model-3 components

• Applets --gt Bytecode
• VM manipulates secure abstractions of data than
  hardware processor
• No direct access to hardware resources but to a
  set of API classes
• Upon Downloading, applet subject to static
  analysis called Bytecode Verification

11
Bytecode Verification- Purpose

• To check -gtcode is well typed
• Doesnt bypass protections 1 2 by performing
  ill typed operations at runtime
• Forging object references from integers
• Illegal casting of obj ref from one class to
  another
• Calling private methods of API
• Jumping in middle of API method or jumping to
  data as if it were code

12
Java Card Arch Sandbox

• Component 1 Applets executed by JVM
• Component 2 Java Card runtime environment
  provides access control through its firewall
• Component 3 Bytecode Verifier missing!
• complex and expensive process
• requires large amounts of working memory

13
Approach 1

• Relying on off-card tools
• Attesting a cryptographic signature on
  well-typedness of the applet
• Oncard downloading restricted to signed applets
• Drawbacks
• - to extend the trusted computing base to off
  card components
• - practical issues (how to deploy the signature
  keys?)
• - legal issues (who takes liability for a buggy
  applet?)

14
Defensive VM Approach

• To type-check dynamically during applet execution
• VM computes bytecode instructions
• Keeps track of all data it manipulates
• Arguments- correct types?stack overflow or
  underflow?
• Are class member accesses allowed?
• Drawback
• - Dynamic Type-checks expensive in terms of
  execution speed and memory

15
Traditional Bytecode Verifn

• For Straight line code?
• -Verifier checks every instruction of the
  method code
• - Checks whether stack has enough entries
• - Checks whether the entries are of correct
  types
• - Effect of the instruction on Operand stack
  and registers
• Intialisation
• - Stack -gtempty
• - Reg (0n-1) -gt method parameters
• - Reg(nm-1)-gt T (uninitialised reg)
• Method invocations ?

16
Traditional Bytecode Verifn

• For Branches- Forks and Joins
• Forks?
• - must propagate inferred stack reg type to
  all successors
• Joins?
• - makes sure the types of the stack and
  registers along all paths agree

17
Handling joins
18
Dictionary

• A data structure associating a stack and register
  type to each program point that is the target of
  a branch or exception handler
• During analysis, Updates -gttype associated with
  target of branch
• Replacing by -gt LUB(prev type,type inferred for
  the instruction)
• If changed -gt the corr.instrn successors are
  reanalysed until a fixpoint is reached
• This way, the dictionary entry for a branch
  target contains LUB inferred on all branches of
  control that lead to this instrn.

19
Errors

• Stack heights may differ
• An instruction can be reached through several
  paths with inconsistent operand stacks
• Types for a particular stack entry or register
  may be incompatible
• eg branch 1 short
• branch 2 Obj Ref
• Type set to T in dictionary

20
Semi-Lattice
21
Interfaces and LUB

• Property Every pair of types possesses a
  smallest common supertype (LUB)
• Does not hold -gt
• Interfaces are types and classes can implement
  several interfaces

22
Example

• interface I ...
• interface J ...
• class C1 implements I, J ...
• class C2 implements I, J ...

23
Subtyping relation
24
Approach
25
Solution to Interface problem

• Bytecode verification ignores interfaces
• Treats all interface types as class type Object
• Verifier contains proper classes and subtyping
  between them is simply inheritance relation
• Subtyping relation is tree shaped
  -gtforms a semilattice.
• LUB of 2 classes -gtclosest common ancestor in
  inheritance tree

26
Performance Analysis

• Straight line Code
• Time as fast as executing instruction
• Space 1 stack and 1 set of reg types
• (if each type-3 bytes, then
  memory3S3N bytes)
• Similar for method invocation
• Space for method invocation space for
  verification

27
Performance Analysis

• Branches- costly since instructions are analyzed
  several times to reach fixpoint
• Real issue Memory space for storing dictionary
• If B -gtno of branch targets, memory (3S3N3)B
  bytes 3 bytes of overhead for each Dic. Entry
• Drawbacks
• No. of branch targets proportional to method size
  -gt dictionary size increases linearly
• Dictionary entries quite often redundant
• Merging several methods into a larger one result
  in non-verifiable code
• Storing the dictionary in EEPROM not an option.

28
Questions?

• Part II Novel Bytecode Verification Algorithm

29
Background for Our Verification Algorithm

• Operand stack is empty at the beginning and end
  of every statement
• JCVM for e1 ? e2 e3
• code to evaluate e1
• ifeq lbl1
• code to evaluate e2
• goto lbl2
• lbl1 code to evaluate e3
• Lbl2
• (Branch to lbl2 occurs with a non-empty operand
  stack)

30
Background

• In Java source, a local variable has only one
  type throughout the method t
• In JCVM bytecode, register with type T acquires
  the type t at 1st store in reg.
• For Java code,
• A x
• if (cond)
• x new B() // B is a subclass of A
• else
• x new C() // C is another subclass of A
• Register x has type A (ie,LUB(B,C)) when two arms
  merge

31
Background

• short x ...
• C y ...
• Scopes of x y disjoint -gtstore x y in same
  register

32
Requirements

• R1 Operand stack is empty at all branch and
  branch target instructions
• R2 Each register has only one type throughout
  the method code
• R3 On method entry,the VM initialises all
  registers that are not parameters to the bit
  pattern representing null object reference

33
The Algorithm

• Global variables
• Nr,Ns,rNr,sNs,sp,chg
• Initialisation
• Set sp lt- 0
• Set r0,, rn - 1 to the types of the method
  arguments
• Set rn,, rNr - 1 to -
• Set chg lt- true

34
Algorithm

• While chg
• Set chg -gt false
• For each instruction i of the method, in code
  order
• If i is the target of a branch instruction
• If sp ! 0 and the previous instruction falls
  through, error
• Set sp -gt 0
• If i is the target of a JSR instruction
• If the previous instruction falls through,
  error
• Set s0 -gt retaddr and sp -gt 1
• If i is a handler for exceptions of class C
• If the previous instruction falls through,
  error
• Set s0 -gt C and sp -gt 1
• If two or more of the cases above apply, error

35
Algorithm

• Determine the types a1,, an of the arguments of
  i
• If sp lt n, error (stack underflow)
• For k 1,,n If ssp - n k - 1 is not
  subtype of ak, error
• Set sp -gt sp - n
• Determine the types r1,, rm of the results of i
• If sp m gt Ns, error (stack overflow)
• For k 1,,m Set ssp k - 1 -gt rk
• Set sp -gt sp m
• If i is a store to register number k
• Determine the type t of the value written to the
  register
• Set rk -gt lub(T, rk)
• If rk changed, set chg -gt true
• If i is a branch instruction and sp ! 0, error

36
Differences with straight line code verification

• Stack empty?
• When checking Store,reg type -gtLUB
• Typechecking until a fixpoint
• Initialisation
• Stack -gt Empty
• reg(0..n-1) -gt method parameter types
• reg(n..m-1)-gt - not T (REQ R3)

37
Next class

• Subroutines
• Object Initialisation
• Off card code transformations
• Bytecode Transformation on small computers