1. 29 th October 2003 Checking Secure Interactions of Smart Card Applets: extended version P. Bieber, J. Cazin, P. Girard, J. –L. Lanet, V. Wiels, and G. Zanon Published in Journal of Computer Security Presented By: Sruthi Bandhakavi (Day 2)

2. Definitions Set of Evolutions A program is described by a set of evolutions that associate a value with each object at each date. Ev  Objects X Dates  Values Set Objects X Dates is made of three disjoint subsets: Input objects : not computed by the program Output objects: computed by the program and are directly observable Internal objects: not observable. Function lvl Associates a security level with input and output objects.

3. Secure Dependency Property(SecDep) Requires that the value of the output objects with security level l only depends on the value of input objects whose security level is dominated by l :  o t  Output,  e  Ev,  e’  Ev, e ~ aut(ot) e’  e(o t ) = e’(o t ) where aut(o t ) = {o’ t’  Input | t’ < t, lvl(o’ t’ ) ≤ lvl( o t )} and e ~ aut(ot) e’ iff  o’ t’  aut(o t ), e(o’ t’ ) = e’ (o’ t’ ). Cannot be directly proved by a model checker like SMV because it is neither a safety or liveness property nor a refinement property. So sufficient conditions of SecDep that are better handled by SMV are looked up.

4. Definitions 2 Set dep(i, o t ) Contains objects with date t-1 used by instruction at program location i to compute the value o t. Program counter Internal object such that pc t-1 determines the current instruction used to compute the value of o t. Whenever and object is modified(i.e. o t-1 is different from o t ) then we consider that pc t-1 belongs to dep(i, o t ). Function lvldep Associates a computed level with each object for each evolution. If o t is an input object then lvldep(e, o t ) = lvl(o t ) otherwise lvldep(e, o t ) = max{lvldep(e, o’ t-1 ) | o’ t-1  dep(e(pc t-1 ), o t ) } where max denotes the least upper bound in the lattice of levels.

5. Hypothesis 1. The value of o t computed by the program is determined by the values of objects in dep(e(pc t-1 ), o t ) :  o t  Output,  e  Ev,  e’  Ev, e ~ dep(e(pct-1 ), ot) e’  e(o t ) = e’(o t )

6. Theorem 1. A program satisfies SecDep if the computed level of an output object is always dominated by its security level:  o t  Output,  e  Ev, lvldep(e, o t ) ≤ lvl(o t )

7. Hypothesis 2. We suppose that the set of abstract evolution Ev a is such that the image Ev by abs is included in Ev a, where abs(e)(o t ) = lvldep(e,o t ) if o ≠ pc and abs(e)(pc t )=e(pc t ).

8. Theorem 2. If  o t  Output,  e a  Ev a, e a (o t ) ≤ lvl(o t ) then the concrete program guarantees SecDep.

9. Applet Certification Decompose global analysis of interacting applets on a card in local verifications of a subset of the methods of one applet. Implement local implementations.

10. Global Analysis Technique Determine what program we want to analyze One method of one applet All methods in one applet All methods of all applets Identify inputs and outputs and assign them a level

11. Call Graph Methods we are interested in Interface methods that can be called from other applets (logFull) Methods that invoke external methods of other applets(askForTransactions)

12. Program being analyzed Analyze subsets of the call graph that include interaction methods. Analyze subset that only contains methods that belong to the same applet.

13. Level Association Inputs Results from external invocations Read attributes Outputs Parameters of external invocations Modified attributes Security levels Applet attributes Method invocations between applets

14. Level Association in our example

15. Security Properties Associated with each output variable. Sresult When a result is produced, the computed level of the result is dominated by the level of the interaction Smethod When an external method is invoked, the computed level of the parameters is dominated by the security level of the interaction. Sfield When an attribute is modified, the computed level of the attribute is dominated by the security level of this attribute.

16. Verification of security policies Compute all the evolutions of a program. For each instruction i and object o of the program, compute the set dep(i,o t ). For java byte code, in addition to input and output objects, we have to take into account the operand stack and the program counter.

17. Verification of Hypothesis 1 and 2. Hypothesis 1. Trivially true because byte code instructions are deterministic. Hypothesis 2. Also satisfied because each Java byte code instruction corresponds to one abstract byte code instruction that manipulates levels instead of values. We can thus associate with each sequence of instruction of a concrete evolution a sequence of instructions that corresponds to an abstract evolution. Abstract evolution associates with each object its computed level except for the program counter that keeps the same value as the concrete evolution.

18. Assume-Guarantee Verification Allows to verify a set of methods locally on each applet even if the methods call methods in other applets through shared interfaces. Allows users to focus the analysis on the new applet that the card issuer wants to download on the card.

19. Local Analysis Technique Verification is based on three elements Abstraction Abstract all the values by computed levels Sufficient condition Verify an invariant that is a sufficient condition of the security property. Model checking Verify this invariant by model checking.

20. Approach Uses modularity capabilities of SMV Builds an SMV module that abstracts a method byte code for each method Builds a main module that contains instances of each of the method abstraction modules and describes the interconnections between these modules.

21. SMV (Symbolic Model Verifier) Types: booleans, enumerated and integer intervals Specification: Set of equations describing evolution of variable values. Give value at each time instant variable := expression Give initial value and the next value init(variable) := expr1, next(variable) := expr2 Non deterministic assignments are possible Ex: b := {0,1} specifies that b takes either value 0 or value 1 Module: Specifications are organized in modules. Gathers declarations and assignments Has input and output parameters Can be instantiated several times, with different parameters

22. SMV (continued..) Control Structures if: if (c) x := expr1 else x := expr2 case: case{ :.. : [default : ] } for: for(i=0; i<3; i=i+1){ t[i] := i);}

23. SMV (continued..) switch: switch( ){ : …. : [ : ] } default: default in

24. SMV (continued…) Property: Linear Temporal Logic formulas that have to be satisfied by every execution of the program. Specified using temporal operators G(always), F(eventually), X(next) and U(until) Defined using assert. Ex. Prop1: assert G(x=0)

25. Properties that can be verified using SMV Safety Property Holding in all paths and all states (  G p), p is the property to be verified. Liveliness Property Holding in some states in some paths or all paths (  F p) or (  F p) Refinement Property Allows one model to represent the behavior of a design simultaneously at many levels of abstraction. Allows one to verify in a compositional manner that each level of the design is a correct implementation of the level above.

26. Method Abstraction Module Simplified version of AirFrance update() method

27. Module Parameters Active Input of the module Boolean that is true when the method is active Context Boolean representing context level of the caller Param Array containing the levels of parameters of the method Field Array containing the levels of attributes used by the method Method Array containing levels of the results of the external methods invoked by the given method Public Boolean representing bottom in the lattice levels

28. Module Variables pc : program counter lpc: level of the program counter, the context level of the method mem[i]: an array modeling memory locations stck[i]: an array modeling operand stack stckP: stack pointer ByteCode: the name of the current instruction

29. Levels Values of the variables are abstracted into levels Defined in a module called Levels in such a way that level is represented by a boolean. Disjunction models Least Upper bound Conjunction models sharing Implication encodes the fact that a level is dominated by another.

30. Method Abstraction Module Byte code execution starts at –1 Initially, the stack is empty.

31. Method Abstraction Module

32. Effect of instructions on a variable Load : pushes the level of memory onto the stack Store: pops the top of the stack and stores the least upper bound of this and lpc in the memory location Dup: duplicates on the top of the stack Op: computes the lub of the levels of first two locations on the stack. Invoke: pops from the stack the parameter and pushes onto the stack the result of this method invocation Getfield: pushes on top of the stack the level of attribute extendedbalance. Putfield: pops from the stack the level of the attribute.

33. Method Abstraction Module

34. Parts of main module First part manages the connections between methods (definition of active method, parameter passing) Second part assigns levels to attributes and interactions.

35. Main Module

36. Invariants Sfield_220: assert G (Bytecode = putfield_0 -> ((stck[stckP+1]|lpc) -> field[0])); Smethod_179: assert G (Bytecode = invoke_179 -> ((stck[stckP+1]|lpc) -> method[0])); Sresult: assert G (m_lgf.Bytecode=return -> (m_lgfl.lpc -> L.AF & L.P ));

37. Analysis Illicit Interaction Detection