Download Slides (Powerpoint)

A Formal Executable Semantics
of the Java Card Platform
Gilles BARTHE, Guillaume DUFAY, Line JAKUBIEC,
Bernard SERPETTE, Simão MELO de SOUSA
January 7th
JavaCard
• a subset of Java
• designed for Smart Cards
Luminy 02
The formalization

Precise
formal, all aspects captured
(exceptions handling, firewall, interfaces, arrays,…)

Complete
all instructions formalized (110)

Usable
from Java programs to COQ representation

Executable
step by step execution
Luminy 02
The functional language
The functional language in COQ has several advantages :
rather close to an implementation
 well suited to verify program properties
 can easily be brought to



pure functional languages
Objective CAML
formal verification environments
Isabelle / HOL
Luminy 02
Applet’s data
Record jc_program : Set := { (* Post linking *)
classes : (list Class);
methods : (list Method);
interfaces : (list Interface) }.
Record Method : Set := {
nargs : nat;
nlocal : nat;
bytecode : (list Instruction);
handler_list : (list handler_type);
owner : Package;
... }.
Luminy 02
Memory
• Stack as a list of frames
Record frame : Set := {
opstack : (list valu);
locvars : (list valu);
method_loc : nat;
context_ref : Package;
p_count : nat }.
• Heap as a list of objects
Inductive object : Set :=
Instance : type_instance  object |
Array
: type_array  object.
Luminy 02
Instructions
• One step execution for each instruction
jcvm_state * operands  returned_state
• JCVM state
jcvm_state := static heap * heap * stack
• Returned state
Inductive returned_state : Set :=
Normal : jcvm_state  returned_state |
Abnormal : xcpt * jcvm_state  returned_state.
Luminy 02
Instruction
Definition NEW := [idx:cap_class_idx][state:jcvm_state][cap:jcprogram]
Cases state of
(sh, (hp, ((cons h lf) as s))) =>
(* Extract the owner class from the cap_file *)
Cases (Nth_elt (classes cap) idx) of
(* then a new instance is created and pushed into the heap *)
(value cl) => let new_obj = ... in
(Normal (sh, ((app hp new_obj),
(cons (update_opstack
(cons ((Ref (Ref_instance idx)), (inject_nat (S (length hp))))
(opstack h)) h)
(tail s))))) |
error => (AbortCode class_membership_error state)
end |
_ => (AbortCode state_error state)
end.
Luminy 02
Abstraction of types
Concrete VM
Abstract VM
type*Z
type
returnAddress
type_prim
nat->type_prim
jcvm_state :=
sheap*heap*stack
sheap*frame
exec_instr :
returned_state
(list returned_state)
valu :=
Luminy 02
Abstraction correctness

Use the two VM simultaneously
 Define a correspondance  (abstraction function) between
the two formalizations
jcvm_state
exec_intr

abs_jcvm_state
abs_exec_intr
returned_state
’
≤
(list abs_returned_state)
Luminy 02
Abstract instruction
Definition abs_NEW :=
[idx:cap_class_idx][state:abs_jcvm_state][cap:jcprogram]
Cases state of
(sh, h) =>
Cases (Nth_elt (classes cap) idx) of
(value cl) => (update_absframe
(Build_absframe
(cons (absRef (absRef_instance idx))
(absOpstack h))
...
(S (absP_count h))) state) |
error => (abs_AbortCode class_membership_error state)
end |
_ => (abs_AbortCode state_error state)
end.
Luminy 02
Bytecode verifier
At any instruction of a program :

Correct type for local variables and instance variable
 Methods called with the appropriate arguments
 Instructions used with the appropriate operands
When successively passing through an instruction:

Same operand stack size and similar types of value
Luminy 02
Algorithm
• Use abstract VM for the execution of the instructions of
one method
• Unify the returned state with the saved state for the
considered instruction
• Keep the unified state as the new saved state
• If the result of the unification differs from the saved state,
the execution continues (fixpoint not reached)
Luminy 02
Types lattice - Termination

To ensure the termination of
the algorithm :
• Use a lattice for VM types
• Show that the result of the
unification is bigger
than the saved state
Object
Prim Void
Interfaces
Instances
Arrays
Null

Luminy 02
Well founded recursion

Use the notion of accessibility to describe wellfounded relation
Inductive Acc [A:Set; R:A->A->Prop] : A ->Prop :=
Acc_intro : (x:A)((y:A)(R y x)->(Acc A R y))->
(Acc A R x)

Use structural induction on a proof of accessibility

Then use this structural induction to ensure the
termination of the algorithm
Luminy 02
Structural induction

Theorem (Bytecode verifier)
Theorem run_verification :
(lrs:(list (Exc abs_returned_state)))
(rs:abs_returned_state)(m:Method)(cap:jcprogram)
(Acc (list (Exc abs_returned_state)) lt_lers lrs) ->
(well_ordered_lers lrs) ->
(list (Exc abs_returned_state)).

Proof of accessibility

Structural induction
lrs: (list (Exc abs_returned_state))
H: (Acc (list (Exc abs_returned_state)) lt_lers lrs)
Elim H.
Luminy 02
Offensive JCVM
JCVM without static type-checking :

type-checking already performed by BCV

faster for execution
valu :=
Concrete VM
Offensive VM
type*Z
Z
Luminy 02
Offensive JCVM correctness
Under the assumption that bytecode
verification has been successful :
jcvm_state
exec_intr
off
off_jcvm_state
returned_state
’off
off_exec_intr
off_returned_state
Luminy 02
Offensive Instruction
Definition NEW :=
[idx:cap_class_idx][state:off_jcvm_state][cap:jcprogram]
Cases state of
(sh, (hp, (cons h lf))) =>
(* Extract the owner class from thew cap_file *)
Cases (Nth_elt (classes cap) idx) of
(* then a new instance is created and pushed into the heap *)
(value cl) => let new_obj = ... in
(Normal (sh, ((app hp new_obj),
(cons (update_opstack
(cons (inject_nat (S (length hp))))
(opstack h)) h)
(tail s))))) |
error => (AbortCode class_membership_error state)
end |
_ => (AbortCode state_error state)
end.
Luminy 02
Generalisation
Given a defensive VM for a particular property (object
initialization, security policy, ...) :

Abstract a VM with this property
 Extract a corresponding executable bytecode verifier
 Proove its correctness w.r.t. the concrete VM
Develop a tool to help us dealing with this mechanism
and with the proofs : Jakarta
Luminy 02
Formalizing APIs
The Java Card Dispatcher class from
com.sun.javacard.framework is needed.
Its is written in Java, it can be converted BUT :

it relies on APDUs :
add I/O buffers for APDUs in our JCVM state

it contains natives method
write these methods in Coq
add a special bytecode for invoking these methods
Luminy 02
Summary

Representation of Java Card programs and of the JCVM memory

Semantics of all JCVM instructions as executable functions

Development of a JCVM tool in Java

Realization of several abstractions on the JCVM

Realization of a certified bytecode verifier

Development of a Coq tactic for use with our correctness proofs
Coq development : 15000 lines
Java development : 3500 lines
Luminy 02
Future work

Formalize JavaCard API (including native methods)

Formalize JCVM tool in Coq

Prove security properties

Bring the formalization to JVM bytecode
Luminy 02
Thank you !
Luminy 02