Gilles BARTHE, Guillaume DUFAY, Marieke HUISMAN

1

Formal Verification of the Java Card Platform

• Gilles BARTHE, Guillaume DUFAY, Marieke HUISMAN
• Line JAKUBIEC, Bernard SERPETTE,
• Simão MELO de SOUSA
• March 21st

2
JavaCard

• a subset of Java
• designed for Smart Cards

3
The formalization

• Precise formal and
  defensive, all aspects captured
• Complete all instructions
  formalized (110)
• Usable from Java programs to
  COQ representation
• Executable step by step execution

4
Applets 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 nat
• ... .

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

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

7
InvokeVirtual

flf InvokeVirtual ? f'flf
Stack
Frames operand stack
...
...
V1
V2
Vnargs
o
l
l
DATA
MANIPULATION
P jcvm_program s stack hp heap operand
nargs
head(s) f l_take(nargs,opstack(f))
l nth(nargs,hp) o
o can be an instance o can be an array
8
Security exceptions
Definition test_exception_invokevirtual
hframeoobj Cases o of (Instance i)
gt (if (eqb_AID (AID_pi (context_ref h))
jcre_AID) then None else (if
(eqb_AID (AID_pi (owner_i i)) (AID_pi
(context_ref h))) then None
else (if (eqb (ptE i) is_ptE)
then None else (Some
Security) ) ) ) (Array a) gt ...
9
JCVM Tool
.java
.class
.cap
.v
Execution_JCVM.vo
Coqtoplevel
Result
linking (constant pool resolution) index
transformation (instructions and values)
10
Abstraction of types

• valu
• typeZ type
• ReturnAddress
• type_prim nat -gttype_prim
• jcvm_state
• sheapheapstack sheapframe
• exec_instr
• returned_state (list returned_state)

11
Abstraction correctness

• Use the two VM simultaneously
• Define a correspondance a between the two
  formalizations
• jcvm_state returned_state
• abs_jcvm_state (list
  abs_returned_state)

exec_intr
a
a
abs_exec_intr
12
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

13
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

14
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

15
Summary

• executable specification of the JCVM and typed
  abstract JCVM
• executable and certified BCV
• JCVM tools CAP files to COQ files

16
Perspectives

• Common Criteria evaluation
• Garbage collection, VOP (Gemplus, Marseilles)
• Prove security properties of Applets
• Formal Specification and Verification tedious
• ? looking for automation.

17
Work in progress Jakarta

• Formal Verification (FV) of the JC Platform
• Use of Proof Assistants (PA) is mandatory, but
  not
• alone!
• Jakarta is intended to give support to FV by
  bringing
• a simple specification language (JSL)
• specification transformation functionalities,
  including abstraction/refinement (JTK)
• and proof support within PA (JPI and JAK)
• While keeping itself independent from PA.

18
An Overview (Cont. 1)

• Clarity of Specification
• JSL polymorphically typed system with functions
  defined by Conditional Rewriting Rules (CRR)
• Tool Independance
• Because of the minimality of the language
• The JPI provides an easy translation of JSL
  specifications into several PA
• The result is close to the original format.

19
An Overview (Cont. 2)

• Support for Partial Functions
• Function definitions by CRR are partial, this
  allows offensive specifications.
• But function transformation is needed for a
  translation into PA language.
• ? The JTK provides an embedding of a partial
  function into a total function using the lift
  monad.
• Proof Automation
• JAK provides, for each JSL function, say f ???,
• a inversion principle that reduce the proof of
  the goal ?x?? , ? (x ,f (x)) into simpler
  subgoals
• (with ? ????Prop).
• ? Done by analysis of rewriting rules

20
An Overview (Cont. 3)

• Automatic support of Abstraction/Refinement
• A significant part of the definition of the
  abstract JCVM was a burocratic translation from
  the concrete definition using the abstraction
  function.
• Given an abstraction function ? or a refinement
  function ?, JTK must offer systematic support to
  abstraction/refinement of specifications w.r.t
  this function.