checking security properties by model checking

SOFTWARE TESTING, VERIFICATION AND RELIABILITYSoftw. Test. Verif. Reliab. 2003; 13:181–196 (DOI: 10.1002/stvr.272)

Checking security properties bymodel checking

Nicoletta De Francesco and Giuseppe Lettieri∗ ,†

Dipartimento di Ingegneria della Informazione, Universita di Pisa, Via Diotisalvi 2,I-56126, Pisa, Italy

SUMMARY

A method is proposed for checking security properties in programs written in high-level languages.The method is based on the model checking technique. The SMV tool is used. The representationof the program is a Kripke structure modelling the control flow graph enriched with securityinformation. The properties considered are secure information flow and the absence of covert channelscaused by program termination. The formulae expressing these security properties are given using thelogic CTL. Copyright c© 2003 John Wiley & Sons, Ltd.

KEY WORDS: security; information flow; model checking

1. INTRODUCTION

In a multilevel secure system, data with different security levels are processed and computed [1,2].Levels are ordered in ascending secrecy. In a scenario with two levels, the lower one corresponds topublic data and the other models private information. A security property for multilevel secure systemsis that information at a given security level does not flow to lower levels.

A program, with variables partitioned into two disjoint sets of high and low security, has secureinformation flow [3–6] if observations of the final value of the low security variables do not reveal anyinformation about the initial values of the high security variables. Assume x is a high security variableand y a low security variable. Examples of violation of secure information flow are: (1) y := x and(2) if x = 0 then y := 0 else y := 1. In the first case there is an explicit informationflow from x to y, while, in the second case there is an implicit information flow: in both cases, checkingthe final value of y reveals information on the value of the higher security variable x. While explicitinformation flow occurs with assignments, implicit information flows are generated by branchingcommands, which in high-level languages are if and while commands. There is always an implicitflow from the guard of the condition to its branches.

∗Correspondence to: Giuseppe Lettieri, Dipartimento di Ingegneria della Informazione, Universita di Pisa, Via Diotisalvi 2,I-56126, Pisa, Italy.†E-mail: [email protected]

Copyright c© 2003 John Wiley & Sons, Ltd.Received 26 September 2002

Accepted 4 June 2003

182 N. DE FRANCESCO AND G. LETTIERI

exp ::= k | x | exp op expcom ::= i : skip | i : x:=exp |

i : if exp then com else com |i : while exp do com | com; com

Figure 1. Command syntax.

High-level information can be revealed not only by the values of the variables, but by the behaviourof the program [7,8]. These leakages are also known as covert channels. Consider the program while(x > 0) do skip, where x is a high variable. It loops indefinitely when x is greater than zero.Thus high-level information can be leaked by examining the termination behaviour of the program.Programs whose termination does not depend on high information satisfy the secure terminationproperty.

This paper shows how the model checking technique can be applied to the analysis of the securityproperties of a program. Model checking [9] is an automated technique for verifying finite statesystems. This is accomplished by checking whether a structure, representing the system, satisfies atemporal logic formula describing the expected behaviour. In this paper the SMV model checker [10]is used. The program representation is a transition system (Kripke structure) obtained by enriching theprogram’s control flow graph with some information on the security level of variables and expressions.A set of temporal logic formulae in the computation tree logic (CTL) are defined expressing the secureinformation flow and the secure termination properties. The method is formally proved correct.

The paper is organized as follows. Section 2 presents the language and the security model. Section 3presents the model checking approach for verifying the security properties. Section 4 reports the cor-rectness results. Section 5 shows a case study. Finally, Section 6 discusses the results and related work.

2. THE SECURITY PROPERTIES

Consider a core of an imperative language with simple commands, assignment and skip, andbranching commands, if and while. All commands are labelled by a set L ⊆ IN of labels, rangedover by i. The syntax of commands is reported in Figure 1, where op stands for the usual arithmeticand logic operations, k ranges over a set of constants, and x, y, . . . are variables.

Assume the existence of a set S = {l, h} of two security levels, ordered by l � h. Level l representspublic information, while private information has level h. The restriction to two levels is made forsimplicity. The model can be extended to any number of levels. Given σ, τ ∈ S, σ �τ denotes the leastupper bound of σ and τ .

A program P is a triple 〈c, L,H 〉 where c ∈ com, and the variables occurring in c are partitionedinto two sets, L and H , containing the low and high security variables, respectively. The low securityvariables are intended to be used to store public data, while the high security variables store privateinformation. Moreover, if Var(c) denotes the variables occurring in c, let E : Var(c) → S be a functionsuch that E(x) = l if and only if (iff for short) x ∈ L and E(x) = h iff x ∈ H .

Copyright c© 2003 John Wiley & Sons, Ltd. Softw. Test. Verif. Reliab. 2003; 13:181–196

CHECKING SECURITY PROPERTIES BY MODEL CHECKING 183

Table I. Standard semantics rules.

Exprconst 〈k,m〉 −→expr kExprvar 〈x, m〉 −→expr m(x)

Exprop 〈e1,m〉 −→expr k1, 〈e2,m〉 −→expr k2, k1 op k2 = k3〈e1 op e2,m〉 −→expr k3

Assign 〈e, m〉 −→expr k

〈i : x := e, m〉 i−→〈λ, m[k/x]〉

Iftrue 〈e, m〉 −→expr true

〈i : if e then c1 else c2,m〉 i−→〈c1, m〉

Iffalse 〈e, m〉 −→expr false

〈i : if e then c1 else c2,m〉 i−→〈c2,m〉

Skip

〈i : skip,m〉 i−→〈λ,m〉

Whiletrue 〈e, m〉 −→expr true

〈i : while e do c , m〉 i−→〈c;while e do c ,m〉

Whilefalse 〈e, m〉 −→expr false

〈i : while e do c ,m〉 i−→〈λ,m〉

Seq1 〈c1, m〉 i−→〈λ,m′〉〈c1; c2,m〉 i−→〈c2,m′〉

Seq2 〈c1,m〉 i−→〈c′1,m′〉

〈c1; c2,m〉 i−→〈c′1; c2,m′〉

The standard semantics of the language is given by means of an operational semantics, defininga labelled transition system. Each state is a pair 〈c,m〉 of a command, representing the programcontinuation, and a memory. M = Variables −→ Values is the set of memories, ranged over by m.In a state the continuation can also be λ and in that case 〈λ,m〉 represents a state in which no actioncan be executed (final state). The set of labels of the transitions, A, coincides with the labels of thecommands: A = L. A transition is labelled by i if it is caused by the execution of the commandlabelled by i. The transition relation is defined by the rules in Table I. −→expr is used to computethe value of the expressions. The expression m[k/x] denotes the memory m′ which agrees with m onall variables, except for x, for which m′(x) = k. In the following, c

δ−→ c′ is an abbreviation forc

i1−→· · · in−→ c′, where δ ∈ A∗ and δ = i1, . . . , in, n ≥ 1.



The secure information flow property for a program describes the fact that information with highsecurity level is kept secret by the execution of the program. This notion is elsewhere called non-interference [11]. It uses the following definition, introducing pairs of memories that agree on the lowsecurity variables.

Definition 1. (Low equivalence) Let P = 〈c, L,H 〉 be a program and m1,m2 ∈ M.

m1 =L m2 if and only if ∀x ∈ L, m1(x) = m2(x)

Definition 2. (Secure information flow) Let P = 〈c, L,H 〉 be a program. P has the secure informationflow property if and only if ∀m1,m2 ∈ M such that m1 =L m2

if 〈c,m1〉 δ−→〈λ,m′1〉 and 〈c,m2〉 γ−→〈λ,m′

2〉, then m′1 =L m′

2,

where δ, γ ∈ A∗.

The secure information flow property guarantees that if the program terminates starting with twomemories which agree on the value of the low security variables, then the resulting memories alsoagree on the value of the low security variables, regardless of the initial value of the high securityvariables. This means that the initial value of the high security variables does not influence the finalvalue of the low security variables in all executions.

This definition considers only terminating executions. Even if a program has the secure informationflow property, its termination may be influenced by the high security information. Consider the program(with x a high security variable)

1: while x > 0 do2: skip

The program satisfies the secure information flow property. However, observing the termination of theprogram reveals that x was greater than 0. This violation of security is an example of the so-calledcovert flows [8]. The following property expresses that the termination of the program is not affectedby the high security information.

Definition 3. (Secure termination) A program P = 〈c, L,H 〉 has secure termination if and only if∀m1,m2 ∈ M such that m1 =L m2:

〈c,m1〉 δ−→〈λ,m′1〉 implies 〈c,m2〉 γ−→〈λ,m′

2〉 for some γ,m′2

where δ, γ ∈ A∗.

3. MODEL CHECKING THE SECURITY PROPERTIES

This section describes a framework where the security properties of a program are verified by means ofmodel checking. Model checking [9] is an automatic technique for verifying finite state systems. This isaccomplished by checking whether a structure representing the system, which is usually a transitionsystem, satisfies a temporal logic formula, describing a desirable property. A model checker accepts



two inputs, the transition system representing the system, and the temporal formula, and returns true ifthe transition system satisfies the formula and false otherwise. The existing verification environmentsbased on model checking follow either an action-based approach (see, for example, [12]), or a state-based one (see, for example, [10]). In the first case the transitions are labelled by a set of actionlabels and the logics make assertions on the labels of the paths of the systems (e.g. mu-calculus[13]). In the second case the states are characterized by the value of a set of state variables andthe transition function takes into account these variables. The logics used in this case allow makingassertions on the value of the state variables when some paths of the transition system are considered(e.g. CTL [9]).

3.1. SMV and CTL

In this paper, a state-based model checking approach is used, and the SMV model checker [10]is applied. In SMV the input to the model checker is a Kripke structure [9]. A Kripke structureis a transition system, where the states are characterized by means of a set atomic propositions.Formally, a Kripke structure K = (Q,Q0, AP, B,→) is a 5-tuple where Q is a set of states; Q0 ⊆ Q

is a set of initial states; AP is a finite set of atomic propositions; B : Q → 2AP is a function that labelseach state with the set of atomic propositions true in that state; →⊆ Q × Q is a transition relation onQ which gives the possible transitions between states. → must be total, i.e. for every q ∈ Q, ∃q ′ ∈ Q

such that (q, q ′) ∈→.Properties of states connected to the transitional behaviour are expressed as CTL formulae [9].

There are two types of formulae in CTL: state formulae and path formulae. A state formula specifiesa property of a single state in the Kripke structure, while a path formula specifies a property of a path.A path is defined as an infinite sequence of states π = s0s1s2 . . . such that for all i ≥ 0, si → si+1.The syntax of state and path formulae is given by the following rules.

If p ∈ AP, then p is a state formula.If f and g are state formulae, then (f ),¬f, f ∧ g are state formulae.If f is a path formula, then Ef is a state formula.If f and g are state formulae, then Xf,Gf, fUg are path formulae.

The satisfaction relation |= is defined as follows, where s is a state and π = s0s1s2 . . . is a path:

s |= p iff p ∈ B(s)

s |= (f ) iff s |= f

s |= ¬f iff s �|= f

s |= f ∧ g iff s |= f and s |= g

s |= Ef iff there exists a path π originating from state s, such that π |= f

π |= Xf iff s1 |= f

π |= Gf iff for all i ≥ 0, si |= f

π |= fUg iff there exists j ≥ 0 such that sj |= g and, for all 0 ≤ i < j, si |= f



The following abbreviations are used in the rest of the paper:

f ∨ g = ¬(¬f ∧ ¬g)

f → g = ¬f ∨ g

Ff = (trueUf )

Af = ¬E(¬f )

The SMV syntax for formulae is SPEC f , where SPEC is an SMV keyword and f is a state formula.Then, SMV verifies that all initial states of the Kripke structure satisfy the formula f .

3.2. The representation of the program

Given a program P , the control flow graph of P , denoted by CFG(P ), encodes all possible executionsof the program. CFG(P ) is the directed graph (V ,E), where V = L is the set of nodes and E ⊆ V ×V

contains the edge (i, j) from node i to node j if and only if the instruction labelled by j can beimmediately executed after that labelled by i. In the following, suppose, without loss of generality, thatthe last instruction of a program is a simple command.

The Kripke structure K(P) associated with a program P is the control flow graph of P , annotatedwith some information useful for checking the security properties. The function level : exp −→ Sstatically computes the security level of an expression occurring in P . If level(e) = l, then in e no highsecurity variable occurs. The definition of level is the following:

level(k) = l

level(x) = E(x)

level(e1 op e2) = level(e1) � level(e2)

Given a program P = 〈c, L,H 〉,K(P ) = (Q,Q0, AP, B,→) is defined as follows. A state isexpressed as a configuration of four variables, LABEL, OPCODE, VLEVEL and ELEVEL, whereLABEL and OPCODE are the label and the kind of instruction, VLEVEL is the security level of thevariable on the left-hand side of an assignment and ELEVEL is the security level of the expressionon the right-hand side of the assignment, or the security level of the condition for the if andwhile instructions. In the other cases, VLEVEL and ELEVEL are undefined (represented by − inthe following).

The set Q of states is the following. Let CFG(P ) = (V ,E). ∀i ∈ V there exists in Q the stateR(i) = 〈LABEL, OPCODE, VLEVEL, ELEVEL〉 where R is defined as follows.

R(i : x := e) = 〈i, assign, E(x), level(e)〉R(i : if e then c1 else c2) = 〈i, if ,−, level(e)〉R(i : while e do c) = 〈i, while,−, level(e)〉R(i : skip) = 〈i, skip,−,−〉

The initial state Q0 is the state that corresponds to the first instruction of the program. The functionB assigning to each state a set of atomic propositions is defined in such a way that each statesatisfies an atomic proposition expressing for each variable its value in the state. For example,



R(i) = 〈i, assign, l, h〉 satisfies the atomic propositions LABEL = i ∧ OPCODE = assign ∧VLEVEL = l ∧ ELEVEL = h.

The transition relation of K(P) is defined according to the edges of the control flow graph. There isa transition from state R(i) to state R(j) if and only if there is an edge from the node i to the nodej in the control flow graph. In addition, there is a transition from the state corresponding to the lastinstruction of the program to itself (this is necessary to make the transition → total).

3.3. The formulae

First consider the secure information flow property. A sufficient condition to ensure this property isthat in each state of the program execution the value of the low security variables does not depend onthe value of the high security variables. Static conditions to ensure this are as follows.

1. For each assignment to a low security variable, no high security variable occurs on the right-handside of the assignment.

2. No assignment to a low security variable must occur in the scope of if and while commandswith a high security guard, i.e. a guard containing a high security variable.That is, whenever an if command with a high security condition begins, no assignment to a lowsecurity variable is performed until the end of the if is reached. A similar condition must holdfor the while command.

The first condition controls the explicit flows. The second condition avoids illegal implicit flows fromthe high security variables occurring in the guard of a branching command to the low security variables.Condition 1 is checked by the following formula:

explicit = AG((OPCODE = assign ∧ VLEVEL = l) → ELEVEL = l);

To express Condition 2 precisely, it is necessary to select the set of instructions in the scope of abranching instruction. Given a command labelled by i, let END(i) be the label of the first instructionfollowing the command (if i is the last instruction in the program, END(i) = i). If i is a branchingcommand, END(i) is the first instruction common to the two paths starting from i. For each instructioni, Condition 2 for if commands is checked by the following formula:

implicit if i =AG((LABEL = i ∧ OPCODE = if ∧ ELEVEL = h) →

¬E((¬(LABEL = END(i)))U(OPCODE = assign ∧ VLEVEL = l)));

The first line of the formula selects all the states corresponding to a high security if. The second lineof the formula requires that, in all states belonging to the scope of the if, no assignment is made toa low security variable. The states belonging to the scope of an if instruction at label i are all thestates in all the paths originating from the state with LABEL = i and ending as soon as a state withLABEL = END(i) is reached. Note that the instruction labelled by END(i) does not belong to the scopeof the corresponding if.



For each instruction i, Condition 2 for while commands is checked by the following formula:

implicit whilei =AG((LABEL = i ∧ OPCODE = while ∧ ELEVEL = h) →

¬E((¬(LABEL = END(i)))U(OPCODE = assign ∧ VLEVEL = l)));The formula implicit while is similar to the formula implicit if . In the following, the formula implicit =∧

i∈L implicit if i ∧ implicit whilei is used.Consider now covert flows that arise from the termination–nontermination behaviour of the program.

A covert flow of this kind can occur when the termination–nontermination of the program depends onsome high security information flow generated by some while command. This occurs when a whilecommand with a high security condition is executed, or when the program does not terminate in one ofthe two branches of a high security if. Sufficient conditions to avoid these situations are:

1. no while with a high security condition can occur;2. all if instructions that test a high security condition must eventually terminate.

Condition 1 is checked by the following formula:

no high while = AG(OPCODE = while → ELEVEL = l);Condition 2 is checked by the following formula:

term high if i =AG((LABEL = i ∧ OPCODE = if ∧ ELEVEL = h) →AF(LABEL = END(i)));

The formula implies that no while in the scope of an if with a high security condition can occur.In the following, the formula termination = (

∧i∈L term high if i ) ∧ no high while is used.

4. CORRECTNESS

This section formally proves the correctness of the analysis. Theorem 1 shows that the model checkinganalysis is consistent with the operational characterization of the secure information flow propertygiven in Section 2 in terms of the standard semantics of the language. Theorem 2 shows the analogousresult for the secure termination property given in Section 2. Some lemmas are useful in the proof ofthe main theorems.

The following lemma states that each execution path of a program P is abstracted onto a path ofK(P).

Lemma 1. Let P = 〈c, L,H 〉 be a program. For each path: 〈c,m〉 i1−→〈c1,m1〉 i2−→ · · · in−→〈cn,mn〉.K(P) contains the path R(i1) −→R(i2) · · · −→R(in).

Proof. By construction, since K(P) is isomorphic to the control flow graph of P . �



The following lemma ensures that the evaluation of a low security expression in two low equivalentmemories gives the same result.

Lemma 2. Let m1,m2 ∈ M with m1 =L m2. For each expression e with level(e) = l it is〈e,m1〉−→expr k if and only if 〈e,m2〉−→expr k.

Proof. By induction on the syntax of expressions. �

The following lemma ensures that if K(P) satisfies the explicit property, then the executions of acommand in two low equivalent memories perform two transitions leading to low equivalent memoriesand, if the command generating the transitions is not an if or a while with a high security guard,then also the same continuation of the program is reached.

Lemma 3. Let P = 〈c, L,H 〉 be a program. Let m1,m2 ∈ M with m1 =L m2 and supposeK(P) |= explicit

〈c,m1〉 i−→〈c1,m′1〉 implies 〈c,m2〉 i−→〈c2,m

′2〉

with m′1 =L m′

2. Moreover, if the instruction labelled by i is different from if e then c′ else c′′and from while e do c′ with level(e) = h, then it is also c1 = c2.

Proof. By considering the instruction generating the transition.

Case 1: x := e. If x ∈ H , then m′1 =L m′

2, since no low security variable is affected. If x ∈ L, fromLemma 1 and the hypothesis that explicit is satisfied, it is level(e) = l. Thus the value assignedto x is the same by Lemma 2. Obviously, the program continuation is the same.

Case 2: if e then c′ else c′′. Since m′1 = m1 and m′

2 = m2, then m′1 =L m′

2. If level(e) = l,from Lemma 2 the evaluation of e in the two memories gives the same result; hence c1 = c2.

Case 3: while e do c′. Similar to the if case.

Case 4: skip. Obvious. �

Theorem 1. Let P = 〈c, L,H 〉 be a program. If K(P) |= (explicit ∧ implicit), then P satisfies thesecure information flow property.

Proof. Consider two terminating computations δ, γ ∈ A∗ starting from two low equivalent memoriesm1 =L m2. By Lemma 1, δ and γ are two paths of K(P).

1. Consider the prefix θ , possibly empty, of δ containing only labels of instructions different froman if or a while with high security condition. If δ = θδ′ for some δ′, from Lemma 3 γ = θγ ′for some γ ′. If θ = δ, the proof is complete.

2. Suppose that an i:if or i:while instruction with high security guard is executed (i is thefirst item of δ′ and γ ′). Consider the two states of the two computations at instruction i (after thecommands in θ have been executed) 〈c,m′

1〉 and 〈c,m′2〉, respectively, with m′

1 =L m′2. In this

case δ′ = iδ′′END(i)δ′′′ and γ ′ = iγ ′′END(i)γ ′′′ for some δ′′, δ′′′, γ ′′, γ ′′′. Note that theend of the if command is reached in both computations, since they terminate by hypothesis.Consider the states 〈c′,m′′

1〉 and 〈c′,m′′2〉 reached by the two computations immediately before

END(i). It is possible that δ′′ �= γ ′′, but the memories of all the states traversed by δ′′ are



all low equivalent to m′1, because no assignment to a low security variable occurs in the

scope of the branching command, since K(P) |= implicit. Analogously, the memories of thestates corresponding to γ ′′ are all low equivalent to m′

2. Hence m′′1 =L m′

1 and m′′2 =L m′

2.Thus m′′

1 =L m′′2 by transitivity of equivalence. As a consequence, the states where δ′′′ and γ ′′′

begin have low equivalent memories and the same continuation (beginning at the end of the sameconditional command).

Steps (1) and (2) above can be alternately repeated until termination. �

Theorem 2. Let P = 〈c, L,H 〉 be a program. If K(P) |= (explicit ∧ implicit ∧ termination), thenP has secure termination.

Proof. Consider two computations starting from two low equivalent memories m1 =L m2.

1. From Lemma 3, until no if with high security guard is reached, the two computations executethe same sequence of commands, and produce at each step a pair of low equivalent memories.No while with high security guard can be reached, since K(P) |= no high while. Hence eitherboth computations terminate or they both do not terminate. If no high security if is encountered,the proof is complete.

2. Suppose that an if with high security guard is executed. The end of this command is reached inboth computations, since K(P) |= term high if i for each i.

Steps (1) and (2) of the proof can be alternately repeated. �

4.1. Example

As a simple example, consider the program in Figure 2. Input to the program is given by storing valuesin the program variables prior to execution, and output is obtained by reading the final values of thevariables when the program terminates. Moreover, assume that x is a high security variable, while yand z are low security variables.

Figure 3 shows the Kripke structure of the example program. The formula explicit is true for thisstructure, since there is no state 〈LABEL, assign, l, h〉. For each i, the formula implicit whilei is alsotrue, since there is no state 〈LABEL, while,−, h〉. The formula implicit if i , however, is not satisfiedfor i = 2. In fact, since the state 〈2, if ,−, h〉 satisfies LABEL = 2 ∧ OPCODE = if ∧ ELEVEL = h,this state must also satisfy the second part of the formula. To satisfy the second part of the formulaimplicit if 2, there should be no state that is an assignment to a low security variable if it is in the scopeof the high security if. Since END(2) = 7, the scope of the if at label 2 ends at state 〈7, skip,−,−〉.However, the state 〈4, assign, l, l〉 represents an assignment to a low security variable and it is in thescope of the if. In fact, there exists a path 〈2, if ,−, h〉〈3, while,−, l〉〈4, assign, l, l〉 from the highsecurity if to the low security assignment, with no intervening state with LABEL = 7 (thus, the pathsatisfies (¬(LABEL = END(i)))U(OPCODE = assign ∧ VLEVEL = l)). Since the formula implicitis not satisfied, the program does not satisfy the secure information flow property. In fact, observingthe final value of the low security variable y, one can deduce if the initial value of the high securityvariable x was greater than 10.



1: y := 0;2: if x > 10 then3: while y < 10 do {4: y := y + z;5: x := x - 1;

}else

6: skip;7: skip

Figure 2. An example program.

<1, assign, l, l>

<6, skip, , >

<4, assign, l, l>

<5, assign, h, h>

<3, while, , l>

<7, skip, , >

<2, if, , h>

Figure 3. Kripke structure of the program in Figure 2.

Now, consider the termination formulae. The formula no high while is satisfied, since there is nostate 〈LABEL, while,−, h〉. The formula term high if i , instead, is not verified for i = 2. In fact,the state 〈2, if ,−, h〉 satisfies LABEL = 2 ∧ OPCODE = if ∧ ELEVEL = h, but it does notsatisfy AG(EF(LABEL = 7)). This formula is not satisfied because of the path of states withLABEL = 2, 3, 4, 5, 3, 4, 5, . . . . In fact, setting the initial value of variable z to a negative number,the program will not terminate if the initial value of variable x is greater than 10. Thus, the programtermination reveals that the initial value of the high security variable x was lower than 10.



5. A CASE STUDY

In this section, the method is applied to a simplified version of the Electronic Purse case study of thePACAP project [14]. PACAP is a project aimed at realizing a prototype that checks the informationflows between different applets onto a Java Card. For the purpose of this discussion, an applet canbe thought of as a set of programs (methods) accessing a private state. The methods and the state arepersistently stored in the Java Card. The Java Card communicates with the outside world by meansof I/O messages. For each applet, there is an entry method and an I/O message that selects the applet.When the Java Card run-time environment receives an I/O message that selects a given applet, it invokesthe entry method of that applet. The applet can also communicate with other applets by invoking oneof their methods. Normally, the entry method will send a reply I/O message before terminating.

The case study consists of three applets that can share data through some interface methods. The firstapplet is an Electronic Purse that can perform debit and credit operations in different currencies, plussome administration functions. It stores the records of the operations carried out in a transaction log.The other two applets (Loyalty Air France and Loyalty Rent-A-Car) get data from the purse transactionlog to update their loyalty points. Moreover, a commercial agreement exists, so that part of theRent-A-Car loyalty points can be used to obtain Air France loyalty points as well. Because of the finitesize of the transaction log, the purse can overwrite old records to save new ones. Before overwriting,the purse invokes a distinguished method of the applets that have paid for the special ‘logfull’ service.Thus, the applets registered to this service have a chance to examine the full transaction log beforeolder records are overwritten, so that they can update their points without losing any transaction.

Assume that only Loyalty Air France has payed for this service. It must be shown that theimplementations of Air France, Loyalty Rent-A-Car and Purse applets assure that the logfull service isnot available to applets not subscribed to this service.

First, the case study has to be modelled using the language defined in Section 2. I/O messages aremodelled using two variables, req and res, for input and output, respectively. A sequence of ifinstructions inspects the value of variable req and chooses the method to be invoked. All methodinvocations are replaced by the code of the invoked method, since the language lacks procedure calls.The transaction log is modelled using a fixed number of logi variables. Variable to read storesthe number of log variables yet to be read by the Loyalty Air France applet. The variables points1and points2 are used to store the loyalty points of Loyalty Air France and Loyalty Rent-A-Car,respectively. Each execution of the program models a single interaction between the Java Card andthe outside world, starting with the receipt of an I/O message and ending with the termination of thecorresponding entry method.

The next step is defining the security policy. The variable to read contains the information usedby the logfull service; hence it can be considered a high security variable. In contrast, the private stateof the Loyalty Rent-A-Car applet must be considered at a low security level. Assigning a security levelto all other variables is more difficult. Indeed, those variables are not directly related to the informationflow that must be checked. Nonetheless, the information can flow indirectly through them. For example,data could be read from the variable to read and stored into another variable work. Then, duringthe same execution or in a subsequent one, data could be read from work and used to update variablepoints2, thus violating the security policy. A solution to this problem is to consider work a highsecurity variable as well. To discover which variables need to be considered at a high security level, themodel checking can be iterated several times. In the first iteration, the set V of variables directly related



to the information flow are identified and a security level is assigned to them. All other variables areassigned the low security level. Then, the formulae are checked. If an error is reported on a variablev /∈ V , v is added to V , with E(v) = h, and the formulae are checked again. The process ends when allformulae are found to be true, or an error is reported on a variable v ∈ V .

For this case study, V is initially equal to {to read,points2} and the initial assignment ofsecurity levels is

E(v) ={

h if v = to read

l otherwise

To keep the presentation short, only the secure information flow property is discussed. Similarconsiderations hold for the secure termination property. The first time the model checker is run, theimplicit formula is found to be false. The counterexample produced by the model checker shows anexecution path ending at label 30. The code fragment around label 30 is the following:

29: if to_read = 4 then {30: i := 0;31: while i < 4 do {

Thus the variable i must be given a high security level, since it is assigned in the scope of a highsecurity if. The process is iterated in a similar way 13 times, until the formula implicit results in falsedue to an execution path leading to the following instruction:

68: points2 := points2 + amount2

Since points2 ∈ V , the process ends. Since the formula implicit is not satisfied, the secureinformation flow property is not guaranteed for this program. In fact, while servicing the logfullrequest, Loyalty Air France asks for the points of Loyalty Rent-A-Car, due to the existing commercialagreement. However, when Loyalty Rent-A-Car receives this request, it scans the transaction log andupdates its own points. Thus, Loyalty Rent-A-Car becomes aware that the log is full. Hence it neverloses transactions, even if it has not paid for the logfull service.

The problem can be solved by adding a separate method through which Loyalty Air France canask for the points of Loyalty Rent-A-Car. In this new method, only the current value of points2 isreturned, with no update actions. If this set of applets is modelled and checked, the formula implicitis found to be true after six iterations. The complete description of the case study, that is the programfor the Electronic Purse, the SMV source files, and the verification session are shown in detail in [15].The SMV source files are automatically generated from the program and the security policy by aconversion tool written in C++ and using the standard lex and yacc facilities.

6. DISCUSSION AND RELATED WORK

The main point of the work is to show that checking secure information flow can be suitably donewith model checking techniques and that the use of these techniques has some advantages overother approaches. The idea is not new: in [16] a similar approach has been defined to check secureinformation flow in Java cards. Also in that work the tool used was SMV. In [17,18] one of the authorsand others show an approach combining model checking with abstract interpretation to check secure



information flow in Java bytecode. In the present paper the use of SMV is not crucial: it is possible touse any other model checker.

The most popular approach to the secure information flow problem is type checking. In this approach,the security information of any variable belongs to its type and the secure information flow is checkedby means of a type system [11]. Recent works following the type-based approach are [19–21], wherefunctional languages, objects and higher order programs are considered, and [22], where an extensionto the Java language is presented that adds flow annotations to program information.

One of the advantages of using model checking instead of a type system is flexibility: other securityproperties can be checked without any new effort except that a new formula must be given. Instead, withtyping, a new type system must be developed to check a new property. For example, considerdeclassification, as described in Jflow [22]. Declassification is the ability of arbitrarily weakeningsecurity restrictions. It is a desirable feature, since strict information flow control may be too restrictivefor some real applications. For example, a program that checks if a given password is valid will alwaysleak a bit of information from the secret passwords file (i.e. if the password is stored in the password fileor not) and, thus, will always be rejected by a strict secure information flow policy. Declassification canbe used in this case to allow this bit of information to be leaked. Checking secure information flow inthe presence of declassification is not easily performable by static type checking. For example, in Jflow,declassification is handled dynamically with run-time checks. With model checking, declassificationcan be implemented simply by assigning to the same information different security levels in differentcontexts. For example, it is possible to impose that a variable can hold information whose security leveldepends on the instruction where the variable itself is assigned. The formula

AG(OPCODE = assign ∧ VLEVEL = l ∧ LABEL �= i) → ELEVEL = l

expresses the fact that the information at instruction i is declassified (no check is performed on theassignment with label i).

Another advantage is related to the representation of the program as a transition system. This allowsinformation to be kept which is not strictly related to the input–output behaviour of the program, butconcerns the state of the program during the execution. It is possible to consider, for example, thesecure termination property, that needs to inspect the intermediate states of the execution. Other covertflows can be investigated in this framework, like timing channels [8], where the number of instructionsexecuted in a computation may reveal high security information.

Finally, the power of model checking can be suitably exploited in handling parallel languages.Checking the information flow in a parallel program, composed of a set of concurrent processes,needs to take into account the interactions among processes. In fact some process can be permanentlyblocked waiting for a communication, and this fact may introduce some data dependency. Since atyping system checks each process separately, and thus has no global view of the system, it oftenimposes non-necessary restrictions on the set of certified programs [23–25]. With a model checkingapproach, instead, it is possible to examine the behaviour of the whole program, represented by asuitable transition system, and thus it is possible to give weaker conditions for security. The work [26]applies the model checking approach described in the present paper to parallel programs: the abstractbehaviour of the program is represented by a transition system, that is model checked to prove secureinformation flow.

Other approaches to check information flow are semantics-based. Among semantics-basedapproaches [27,28] present methods based on abstract interpretation. In [29] an approach is described



based on an axiomatic semantics, while the work [30] defines a method based on partial equivalencerelations. While semantics-based approaches are often able to certify more programs than staticapproaches, they suffer the disadvantage of not being completely automatic.

Other works define non-interference on concurrent processes described with process algebras;see for example [31–33]. Values are not considered and the communications are only synchronisations.In these works the events of the system (the communications) are divided into high and low eventsand a trace semantics is assumed. Non-interference means that the traces of a set of concurrentprocesses must not be affected by the occurrence of the high events. Non-interference is checked eitherby model checking or by checking suitable bisimulation equivalences. Non-interference and secureinformation flow are related notions. However, non-interference concentrates on the parallel behaviourof the concurrent processes, and does not consider data values, while secure information flow, that isaddressed in the present paper, is connected to the functional behaviour of programs. For a survey ofmethods to check the information flow see [34].

Future work will be the extension of the language to include procedures and other language featuresand the verification of other security properties defined in the literature.

ACKNOWLEDGEMENTS

We thank Cinzia Bernardeschi and Antonella Santone for useful discussions on the formalisation of the securityproperties as logic formulae.

REFERENCES

1. Bell DE, La Padula LJ. Secure computer systems: Mathematical foundations and model. Technical Report M74-244,MITRE Corporation, Bedford, MA, 1973.

2. Goguen J, Meseguer J. Security policies and security models. Proceedings of the 1982 IEEE Symposium on Security andPrivacy, Oakland, CA, April 1982; 11–20.

3. Denning DE. A lattice model of secure information flow. Communications of the ACM 1976; 19(5):236–243.4. Denning DE, Denning PJ. Certification of programs for secure information flow. Communications of the ACM 1977;

20(7):504–513.5. Andrews GR, Reitman RP. An axiomatic approach to information flow in programs. ACM Transactions on Programming

Languages and Systems 1980; 2(1):56–76.6. Banatre J, Bryce C, Metayer DL. Compile-time detection of information flow in sequential programs. Proceedings of the

European Symposium on Research in Computer Security (Lecture Notes in Computer Science, vol. 875). Springer: Berlin,1994; 55–73.

7. Lampson BW. A note on the confinement problem. Communications of the ACM 1973; 16(10):613–615.8. Volpano D, Smith G. Eliminating covert flows with minimum typing. Proceedings of the 10th IEEE Computer Security

Foundation Workshop, Rockport, MA, June 1997; 156–168.9. Clarke EM, Emerson EA, Sistla AP. Automatic verification of finite-state concurrent systems using temporal logic

specifications. ACM Transactions on Programming Languages and Systems 1986; 8(2):244–263.10. McMillan KL. The SMV language. Cadence Berkeley Labs, Cadence Design Systems: Berkeley, CA, March 1999.11. Volpano D, Smith G, Irvine C. A sound type system for secure flow analysis. Journal of Computer Security 1996; 4(3):

167–187.12. Cleaveland R, Parrow J, Steffen B. The concurrency workbench. Proceedings of the International Workshop on Automatic

Verification Methods for Finite State Systems (Lecture Notes in Computer Science, vol. 407), Grenoble, 1989; 24–37.13. Stirling C. An introduction to modal and temporal logics for CCS. Concurrency: Theory, Language, and Architecture

(Lecture Notes in Computer Science, vol. 391), 1989.14. Cazin J, El-Marouani A, Girard P, Lanet JL, Wiels V, Zanon G. The PACAP prototype: A tool for detecting illegal flows.

Java Card Workshop Proceedings, Cannes, September 2000 (Lecture Notes in Computer Science, vol. 2041). Springer:Berlin, 2000.



15. De Francesco N, Lettieri G. Checking security properties by model checking: A case study. Internal Report IET 51-03,April 2003.

16. Bieber P, Cazin J, Girard P, Lanet J-L, Wiels V, Zanon G. Checking secure interactions of smart card applets. ESORICS2000 Proceedings, 2000 (Lecture Notes in Computer Science, vol. 1895). Springer: Berlin, 2000.

17. Barbuti R, Bernardeschi C, De Francesco N. Checking security of Java bytecode by abstract interpretation. Proceedings ofthe 17th ACM Symposium on Applied Computing: Special Track on Computer Security, Madrid, March 2002.

18. Bernardeschi C, De Francesco N. Combining abstract interpretation and model checking for analysing security propertiesof Java bytecode. Proceedings of the Third International Workshop on Verification, Model Checking and AbstractInterpretation, Venice, January 2002 (Lecture Notes in Computer Science, vol. 2294). Springer: Berlin, 2002.

19. Heintze N, Riecke JG. The Slam Calculus: Programming with secrecy and integrity. Proceedings of the 25th ACMPrinciples of Programming Languages Conference, San Diego, CA, 1998; 365–377.

20. Abadi M, Banerjee A, Heintze N, Riecke JG. A Core Calculus of dependency. Proceedings of the 26th Annual ACMSIGPLAN-SIGACT Symposium on Principles of Programming Languages Conference, San Antonio, TX, 1999; 147–160.

21. Pottier F, Conchon S. Information flow inference for free. Proceedings of the ACM ICFP’00, Montreal, Canada, September2000; 46–57.

22. Myers AC. Jflow: Practical mostly-static information flow control. Proceedings of the 26th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, San Antonio, TX, 1999; 228–241.

23. Smith G, Volpano D. Secure information flow in a multi-threaded imperative language. Proceedings of the 25th AnnualACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, San Diego, CA, 1998; 1–10.

24. Sabelfeld A, Sands D. The impact of synchronization on secure information flow in concurrent programs. Proceedings ofthe Andrei Ershov 4th International Conference on Perspective of System Informatics (Lecture Notes in Computer Science,vol. 2244), Novosibirsk. Springer: Berlin, 2001.

25. Smith G. A new type system for secure information flow. Proceedings of the 14th IEEE Computer Security FoundationsWorkshop (CSFW’01), Cape Breton, Nova Scotia, June 2001; 115–125.

26. De Francesco N, Santone A. Checking secure information flow in concurrent languages by abstract interpretation + modelchecking. Workshop on Concurrency Specification and Programming, Berlin, October 2002 (Informatik-Bericht, Nr. 161).Humboldt University: Berlin, 2002.

27. Mizuno M, Schmidt DA. A security flow control algorithm and its denotational semantics correctness proof. Formal Aspectsof Computing 1992; 4(6A):727–754.

28. Barbuti R, Bernardeschi C, De Francesco N. Abstract interpretation of operational semantics for secure information flow.Information Processing Letters 2002; 83(2):101–108.

29. Leino KRM, Joshi R. A semantic approach to secure information flow. Science of Computer Programming 2000;37(1):113–138.

30. Sabelfeld A, Sands D. A PER model of secure information flow in sequential programs. Proceedings of the 8th EuropeanSymposium on Programming, ESOP’99 (Lecture Notes in Computer Science, vol. 1576). Springer: Berlin, 1999; 40–58.

31. Roscoe AW, Woodcock JCP, Wulf L. Non-interference through determinism. Journal of Computer Security 1996; 4(1):27–54.

32. Focardi R, Gorrieri R. The compositional security checker: A tool for the verification of information flow securityproperties. IEEE Transactions on Software Engineering 1997; 23(9):550–571.

33. Ryan PYA, Schneider SA. Process algebra and non-interference. Journal of Computer Security 2001; 9(12):75–103.34. Sabelfeld A, Myers AC. Language-based information-flow security. IEEE Journal on Selected Areas in Communications

2003; 21(1):5–19.


checking security properties by model checking

Documents