1 / 24

Gilles B ARTHE , Guillaume D UFAY , Line J AKUBIEC , Bernard S ERPETTE , Simão M ELO de S OUSA

A Formal Executable Semantics of the Java Card Platform. Gilles B ARTHE , Guillaume D UFAY , Line J AKUBIEC , Bernard S ERPETTE , Simão M ELO de S OUSA January 7 th. JavaCard. • a subset of Java • designed for Smart Cards. The formalization.

isanne
Download Presentation

Gilles B ARTHE , Guillaume D UFAY , Line J AKUBIEC , Bernard S ERPETTE , Simão M ELO de S OUSA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Formal Executable Semantics of the Java Card Platform Gilles BARTHE, Guillaume DUFAY, Line JAKUBIEC, Bernard SERPETTE, Simão MELO de SOUSA January 7th

  2. JavaCard • a subset of Java • designed for Smart Cards

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

  4. 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 languagesObjective CAML • formal verification environments Isabelle / HOL

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

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

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

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

  9. Abstraction of types

  10. Abstraction correctness • Use the two VM simultaneously • Define a correspondance  (abstraction function) between the two formalizations jcvm_state returned_state abs_jcvm_state (list abs_returned_state) exec_intr  ’ ≤ abs_exec_intr

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

  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 (fixpoint not reached)

  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 biggerthan the saved state Object Interfaces Prim Void Arrays Instances Null 

  15. Well founded recursion • Use the notion of accessibility to describe well-founded 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

  16. 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 accessibilitylrs: (list (Exc abs_returned_state))H: (Acc (list (Exc abs_returned_state)) lt_lers lrs) • Structural induction Elim H.

  17. Offensive JCVM JCVM without static type-checking : • type-checking already performed by BCV • faster for execution

  18. Offensive JCVM correctness Under the assumption that bytecode verification has been successful : exec_intr jcvm_state returned_state off_jcvm_state off_returned_state off ’off off_exec_intr

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

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

  21. 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 Coqadd a special bytecode for invoking these methods

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

  23. Future work • Formalize JavaCardAPI (including native methods) • Formalize JCVM tool in Coq • Prove security properties • Bring the formalization to JVM bytecode

  24. Thank you !

More Related