29th 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)

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.

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.

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-1 determines 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-1 belongs 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.

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)

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)

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

Theorem 2.

If ot Output, ea Eva, ea(ot) ≤ lvl(ot) then the concrete program guarantees SecDep.

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.

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

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)

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.

Level Association

Inputs Results from external invocations Read attributes

Outputs Parameters of external invocations Modified attributes

Security levels Applet attributes Method invocations between applets

Level Association in our example

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.

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.

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.

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.

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.

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.

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

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);}

SMV (continued..)

switch: switch(<expr>){

<case1>:<stmt1>…. <casen>:<stmtn>[<default>:<dfstmt>]}

default: default

<stmt1>in

<stmt2>

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)

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.

Method Abstraction Module

Simplified version of AirFrance update() method

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

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

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.

Method Abstraction Module

Byte code execution starts at –1 Initially, the stack is empty.

Method Abstraction Module

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.

Method Abstraction Module

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.

Main Module

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 ));

Analysis

Illicit Interaction Detection