Formal Verification of the Java Card Platform Gilles

Formal Verification of the Java Card Platform Gilles BARTHE, Guillaume DUFAY, Marieke HUISMAN Line JAKUBIEC, Bernard SERPETTE, Simão MELO de SOUSA March 21 st Appsem’ 01

Java. Card • a subset of Java • designed for Smart Cards Appsem’ 01

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

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 : nat; . . . }. Appsem’ 01

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. Appsem’ 01

Instructions • One step execution for each instruction jcvm_state * operands ® returned_state • JCVM state jcvm_state : = static heap * stack • Returned state Inductive returned_state : Set : = Normal : jcvm_state ® returned_state | Abnormal : xcpt * jcvm_state ® returned_state. Appsem’ 01

Invoke. Virtual f: : lf Stack Invoke. Virtual f': : f: : lf V 1 V 2 . . . Vnargs o l’ l DATA P : jcvm_program s : stack hp : heap operand : nargs Frame’s operand stack MANIPULATION head(s) = f l_take(nargs, opstack(f)) = l nth(nargs, hp) = o o can be an instance o can be an array Appsem’ 01

Security exceptions Definition test_exception_invokevirtual : = [h: frame][o: obj] Cases o of (Instance i) => (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 (pt. E i) is_pt. E) then None else (Some Security) ) | (Array a) =>. . . Appsem’ 01

JCVM Tool. java Javac. class * Converter . cap * JCVM tool . v Coqc Execution_JCVM. vo Coqtoplevel Result linking (constant pool resolution) index transformation (instructions and values) Appsem’ 01

Abstraction of types type*Z type_prim sheap*stack returned_state valu : = type Return. Address : nat ->type_prim jcvm_state : = sheap*frame exec_instr: (list returned_state) Appsem’ 01

Abstraction correctness • Use the two VM simultaneously • Define a correspondance between the two formalizations jcvm_state exec_intr returned_state abs_exec_intr abs_jcvm_state abs_returned_state) (list Appsem’ 01

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 Appsem’ 01

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 Appsem’ 01

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 Interfaces Array Instances ^ Appsem’ 01

Summary • executable specification of the JCVM and typed abstract JCVM • executable and certified BCV • JCVM tools: CAP files to COQ files Appsem’ 01

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

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. Appsem’ 01

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. Appsem’ 01

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 Appsem’ 01

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. Appsem’ 01