Checking Secure Interactions of Smart Card Applets: extended version

1. 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 : ot  Output, e  Ev, e’  Ev, e ~aut(ot) e’  e(ot) = e’(ot) where aut(ot) = {o’t’  Input | t’ < t, lvl(o’t’ ) ≤ lvl(ot)} and e ~aut(ot) e’ iff o’t’  aut(ot), 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, ot) • Contains objects with date t-1 used by instruction at program location i to compute the value ot. • Program counter • Internal object such that pct-1determines the current instruction used to compute the value of ot. • Whenever and object is modified(i.e. ot-1 is different from ot) then we consider that pct-1belongs to dep(i,ot). • Function lvldep • Associates a computed level with each object for each evolution. • If ot is an input object then lvldep(e,ot) = lvl(ot) otherwise lvldep(e,ot) = max{lvldep(e,o’t-1) | o’t-1  dep(e(pct-1), ot) } where max denotes the least upper bound in the lattice of levels.

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

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

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

8. Theorem 2. If ot  Output, ea Eva, ea(ot) ≤lvl(ot) 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,ot). • 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{ <cond1> : <stmt1> .. <condn> : <stmtn> [default : <dfstmt>] } • for: • for(i=0; i<3; i=i+1){ t[i] := i);}

23. SMV (continued..) • switch: • switch(<expr>){ <case1>:<stmt1> …. <casen>:<stmtn> [<default>:<dfstmt>] } • default: • default <stmt1> in <stmt2>

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