Event-based Compositional Reasoning of Information-Flow Security for Concurrent Systems

In order to provide a rely-guarantee proof system for concurrent systems, we first introduce events into programming languages in the rely-guarantee method. An example of events in the concrete syntax is shown in Fig. 1. An event is actually a non-atomic and parametrized state transition of systems with a set of guard conditions to constrain the type and value of parameters, and current state. The body of an event defines the state transition and is represented by imperative statements. We provide a special parameter $\kappa$ for events to indicate the execution context of an event, i.e., on which single-processing system that the event is executing. For instance, the $\kappa$ could be used to indicate the current processor core in multicore systems.

An event system represents the behavior of a single-processing system and has two forms of event composition, i.e. event sequence and event set. The event sequence models the sequential execution of events. The event set models the nondeterministic occurrence of events, i.e., events in this set can occur when the guard condition is satisfied. The parallel composition of event systems is fine-grained since small-step actions in events are interleaved in semantics of $\pi$-Core. This relaxes the atomicity constraint of events in other approaches (e.g. Event-B Abrial and Hallerstede [2007]). It is obvious that concurrent programs represented by the languages in Xu et al. [1997]; Nieto [2003]; Liang et al. [2012] could be represented by $\pi$-Core too.

State-action based IFS is defined and proved based on a state machine. We construct a state machine from a parallel event system in $\pi$-Core. Each action of the machine is a small-step action of events. To relate the small step to the action, each transition rule in operational semantics of $\pi$-Core has an action label to indicate the kind of the transition. The action label shows the information about action type and in which event system the action executes. On the other hand, we add a new element, i.e. event context, in the configuration in the semantics. The event context is a function to indicate which event is currently executing in each event system.

Then, IFS of $\pi$-Core is defined on the state machine. In this paper, we use two-level unwinding conditions, i.e. small-step and event unwinding conditions. The small-step UCs examine small steps in events, which is atomic. The unwinding theorem shows that satisfaction of small-step UCs implies the security. This is the IFS semantics of $\pi$-Core by following traditional IFS. The problem of directly applying the unwinding theorem is the explosion of proof space due to interleaving and the small-step conditions. A solution is to enlarge the granularity to the event level, and thus we define the event UCs of $\pi$-Core. Since the guarantee condition of an event characterizes how the event modifies the environment, the event UCs are defined based on the guarantee condition of events. Finally, the compositionality of state-action based IFS means that if all events defined in a concurrent system satisfy the event UCs and the system is closed, then the system is secure. We conclude this by the soundness of event UCs, i.e., event UCs imply the small-step UCs in $\pi$-Core.

By introducing “Events” into concurrent programming languages, we create a language with four levels of elements, i.e., programs represented by programming languages, events constructed based on programs, event systems composed by events, and parallel event systems composed by event systems. The abstract syntax of $\pi$-Core is shown in Fig. 2.

The syntax of programs is intuitive and is used to describe the behavior of events. The $\textbf{Basic}\ {f}$ command represents an atomic state transformation, for example, an assignment and the Skip command. The $\textbf{Await}\ {b}\ {P}$ command executes program $P$ atomically whenever boolean condition $b$ holds. The $\textbf{Nondt}\ {r}$ command defines the potential next states via the state relation $r$. It can be used to model nondeterministic choice. The rest are well-known.

An event is actually a parametrized program to represent the state change of an event system. In an event, $\alpha$ with the type of $(p\times\mathcal{K})\rightarrow(g\times P)$ is an event specification, where $p$ is the parameters, $\mathcal{K}$ indicates the label of an event system, $g$ is the guard condition of the event, and $P$ is a program which is the body of the event. An event $\textbf{BasicEvt}\ {\alpha}$ can occur under concrete parameters $p$ in event system $\kappa$ when its guard condition (i.e. $fst(\alpha(p,\kappa))$) is true in current state. Then, it behaves as an anonymous event $\textbf{AnonyEvt}\ {(snd(\alpha(p,\kappa)))}$. An anonymous event is actually a wrapper of a program to represent the intermediate specification during execution of events.

The event system indeed constitutes a kind of state transition system. It has two forms of event composition, i.e. event sequence and event set. For an event set, when the guard conditions of some events are true, then one of the corresponding events necessarily occurs and the state is modified accordingly. When the occurred event is finished, the guard conditions are checked again, and so on. For an event sequence ${\mathcal{E}};{\mathcal{S}}$, when the guard condition of event $\mathcal{E}$ is true, then $\mathcal{E}$ necessarily occurs and the state is modified accordingly, finally it behaves as event system $\mathcal{S}$.

A concurrent system is modeled by a parallel event system, which is the parallel composition of event systems. The parallel composition is a function from $\mathcal{K}$ to event systems. Note that a model eventually terminates is not mandatory. As a matter of fact, most of the systems we study run forever.

We introduce an auxiliary function to query all events defined in event systems and parallel event systems as follows.

Semantics of $\pi$-Core is defined via transition rules between configurations. A configuration $\mathcal{C}$ is defined as a triple $(\sharp,s,x)$, where $\sharp$ is a specification (e.g., a program, an event, an event system, or a parallel event system), $s$ is a state, and $x:\mathcal{K}\rightarrow\mathcal{E}$ is an event context. The event context indicates which event is currently executed in an event system. We use $\sharp_{\mathcal{C}}$, $s_{\mathcal{C}}$, and $x_{\mathcal{C}}$ to represent the three parts of a configuration $\mathcal{C}$ respectively.

A system can perform two kinds of transitions: action transitions, performed by the system itself, and environment transitions, performed by a different system of the parallel composition or by an arbitrary environment.

A transition rule of actions has the form $(\sharp_{1},s_{1},x_{1})\stackrel{{\scriptstyle{\delta}}}{{\longrightarrow}}(\sharp_{2},s_{2},x_{2})$, where $\delta={t}@{\kappa}$ is a label indicating the kind of transition. $t::=c\ |\ \mathcal{E}$, where $c$ is a program action and $\mathcal{E}$ is the occurrence of event $\mathcal{E}$. $@\kappa$ means that the action $\delta$ occurs in event system $\kappa$. A rule of environment transition has the form $(\sharp,s,x)\stackrel{{\scriptstyle e}}{{\longrightarrow}}(\sharp,s^{\prime},x^{\prime})$, where $e$ is the label of environment transition. Intuitively, a transition made by the environment may change the state and the event context but not the specification.

Transition rules of actions are shown in Fig. 3. The transition rules of programs are mostly standard. The $\stackrel{{\scriptstyle{c^{*}}}}{{\longrightarrow}}$ in the Await rule is the reflexive transitive closure of $\stackrel{{\scriptstyle{c}}}{{\longrightarrow}}$. The program action modifies the state but not the event context. The execution of $\textbf{AnonyEvt}\ {P}$ mimics program $P$. The BasicEvt rule shows the occurrence of an event. The currently executing event of event system $\kappa$ in the event context is updated. The EvtSet, EvtSeq1, and EvtSeq2 rules means that when an event occurs in an event set, the event executes until it finishes in the event system. The Par rule shows that execution of a parallel event system is modeled by a nondeterministic interleaving of the atomic execution of event systems. $\mathcal{PS}(\kappa\mapsto\mathcal{S}^{\prime})$ is a function derived from $\mathcal{PS}$ by mapping $\kappa$ to $\mathcal{S}^{\prime}$.

A computation of $\pi$-Core is a sequence of transitions, which is defined as the form

We define the set of computations of parallel event systems $\Psi_{\mathcal{PS}}$, as the set of lists of configurations inductively defined as follows, where $\#$ is the connection operator of two lists. The one-element list of configurations is always a computation. Two consecutive configurations are part of a computation if they are the initial and final configurations of an environment or action transition.

The computations of programs, events, and event systems are defined in a similar way. We use $\Psi(\mathcal{PS})$ to denote the set of computations of a parallel event system $\mathcal{PS}$. The function $\Psi(\mathcal{PS},s,x)$ denotes the computations of $\mathcal{PS}$ executing from an initial state $s$ and event context $x$. The computations of programs, events, and event systems are also denoted as the $\Psi$ function. For each computation $\varpi\in\Psi(\mathcal{PS})$, we use $\varpi_{i}$ to denote the configuration at index $i$. For convenience, we use $\varpi$ to denote computations of programs, events, and event systems too. We say that a parallel event system $\mathcal{PS}$ is a closed system when there is no environment transition in computations of $\mathcal{PS}$.

We define an equivalent relation on computations as follows. Here, we concern the state, event context, and transitions, but not the specification of a configuration.

In order to discuss the security of a parallel event system $\mathcal{PS}$, we assume a set of security domains $\mathcal{D}$ and a security policy $\leadsto$ that restricts the allowable flow of information among those domains. The security policy $\leadsto$ is a reflexive relation on $\mathcal{D}$. $d_{1}\leadsto d_{2}$ means that actions performed by $d_{1}$ can influence subsequent outputs seen by $d_{2}$. $\mathrel{\mathchoice{{\ooalign{$\displaystyle/$\cr\hfil$\displaystyle\leadsto$\hfil\cr}}}{{\ooalign{$\textstyle/$\cr\hfil$\textstyle\leadsto$\hfil\cr}}}{{\ooalign{$\scriptstyle/$\cr\hfil$\scriptstyle\leadsto$\hfil\cr}}}{{\ooalign{$\scriptscriptstyle/$\cr\hfil$\scriptscriptstyle\leadsto$\hfil\cr}}}}$ is the complement relation of $\leadsto$. We call $\leadsto$ and $\mathrel{\mathchoice{{\ooalign{$\displaystyle/$\cr\hfil$\displaystyle\leadsto$\hfil\cr}}}{{\ooalign{$\textstyle/$\cr\hfil$\textstyle\leadsto$\hfil\cr}}}{{\ooalign{$\scriptstyle/$\cr\hfil$\scriptstyle\leadsto$\hfil\cr}}}{{\ooalign{$\scriptscriptstyle/$\cr\hfil$\scriptscriptstyle\leadsto$\hfil\cr}}}}$ the interference and noninterference relations respectively.

Each event has an execution domain. Traditional formulations in the state-action based IFS assume a static mapping from events to domains, such that the domain of an event can be determined solely from the event itself Rushby [1992]; von Oheimb [2004]. For flexibility, we use a dynamic mapping, which is represented by a function $dom\textunderscore\allowbreak e:S\times\mathcal{K}\times\mathcal{E}\rightarrow\mathcal{D}$, where $S$ is the system state. The $\mathcal{PS}$ is view-partitioned if, for each domain $d\in\mathcal{D}$, there is an equivalence relation $\stackrel{{\scriptstyle{d}}}{{\sim}}$ on $S$. For convenience, we define $\mathcal{C}_{1}\stackrel{{\scriptstyle{d}}}{{\sim}}\mathcal{C}_{2}\triangleq s_{\mathcal{C}_{1}}\stackrel{{\scriptstyle{d}}}{{\sim}}s_{\mathcal{C}_{2}}$. An observation function of a domain $d$ to a state $s$ is defined as $ob(s,d)$. For convenience, we define $ob(\mathcal{C},d)\triangleq ob(s_{\mathcal{C}},d)$.

IFS semantics of $\pi$-Core consider small-step actions of systems. A small-step action in the machine is identified by the label of a transition, the event that the action belongs to, and the domain that triggers the event. We construct a nondeterministic state machine for a parallel event system as follows.

Based on the function $step$, we define the function $run$ as shown in Fig. 4 to represent the execution of a sequence of actions. We prove the following lemma to ensure that the state machine is an equivalent representation of the $\pi$-Core language.

Since we consider closed parallel event systems, there is no environment transition in the computations of $\mathcal{PS}$, i.e., $\forall j<len(\varpi)-1.\ \neg(\varpi_{j}\stackrel{{\scriptstyle e}}{{\longrightarrow}}\varpi_{(j+1)})$.

We now discuss the IFS properties based on the state machine constructed above. By following the security properties in von Oheimb [2004], we define noninterference, nonleakage, and noninfluence properties in this work.

The auxiliary functions used by IFS are defined in detail in Fig. 4. The function $execution(\mathcal{C},as)$ (denoted as ${\mathcal{C}}\triangleright{as}$) returns the set of final configurations by executing a sequence of actions $as$ from a configuration $\mathcal{C}$, where $\lhd$ is the domain restriction of a relation. By the function $execution$, the reachability of a configuration $\mathcal{C}$ from the initial configuration $\mathcal{C}_{0}$ is defined as $reachable(\mathcal{C})$ (denoted as $\mathcal{R}(\mathcal{C})$).

The essence of intransitive noninterference is that a domain $d$ cannot distinguish the final states between executing a sequence of actions $as$ and executing its purged sequence. In the intransitive purged sequence ($ipurge(as,d)$ in Fig. 4), the actions of domains that are not allowed to pass information to $d$ directly or indirectly are removed. In order to express the allowed information flows for the intransitive policies, we use a function $sources(as,d)$ as shown in Fig. 4, which yields the set of domains that are allowed to pass information to a domain $d$ when an action sequence $as$ executes.

The observational equivalence of an execution is thus denoted as ${{\mathcal{C}_{1}}\triangleright{as_{1}}}\stackrel{{\scriptstyle d}}{{\bumpeq}}{{\mathcal{C}_{2}}\triangleright{as_{2}}}$, which means that a domain $d$ is identical to any two final states after executing $as_{1}$ from $\mathcal{C}_{1}$ (${\mathcal{C}_{1}}\triangleright{as_{1}}$) and executing $as_{2}$ from $\mathcal{C}_{2}$. The classical nontransitive noninterference Rushby [1992] is defined as the noninterference property as follows.

The above definition of noninterference is based on the initial configuration $\mathcal{C}_{0}$, but concurrent systems usually support warm or cold start and they may start to execute from a non-initial configuration. Therefore, we define a more general version noninterferece_r as follows based on the function $reachable$. This general noninterference requires that the system starting from any reachable configuration is secure. It is obvious that this noninterference implies the classical noninterference due to $\mathcal{R}(\mathcal{C}_{0})=True$.

The intuitive meaning of nonleakage is that if data are not leaked initially, data should not be leaked during executing a sequence of actions. Concurrent systems are said to preserve nonleakage when for any pair of reachable configuration $\mathcal{C}_{1}$ and $\mathcal{C}_{2}$ and an observing domain $d$, if (1) $\mathcal{C}_{1}$ and $\mathcal{C}_{2}$ are equivalent for all domains that may (directly or indirectly) interfere with $d$ during the execution of $as$, i.e. ${\mathcal{C}_{1}}\stackrel{{\scriptstyle sources(as,d)}}{{\approx}}{\mathcal{C}_{2}}$, then $\mathcal{C}_{1}$ and $\mathcal{C}_{2}$ are observationally equivalent for $d$ and $as$. Noninfluence is the combination of nonleakage and classical noninterference. Noninfluence ensures that there is no secrete data leakage and secrete actions are not visible according to the information-flow security policies. The two security properties are defined as follows. We have that noninfluence implies noninterference_r.

The standard proof of IFS is discharged by proving a set of unwinding conditions Rushby [1992] that examine individual execution steps of the system. This paper also follows this approach. We first define the small-step unwinding conditions as follows.

The locally respects condition means that an action $a$ that executes in a configuration $\mathcal{C}$ can affect only those domains to which the domain executing $a$ is allowed to send information. The step consistent condition says that the observation by a domain $d$ after an action $a$ occurs can depend only on $d$’s observation before $a$ occurs, as well as the observation by the domain executing $a$ before $a$ occurs if that domain is allowed to send information to $d$.

We prove the small-step unwinding theorem for noninfluence and nonleakage as follows.

A rely-guarantee specification for a system is a quadruple $RGCond=\langle pre,R,G,pst\rangle$, where $pre$ is the pre-condition, $R$ is the rely condition, $G$ is the guarantee condition, and $pst$ is the post condition. The assumption and commitment functions following a standard way are defined as follows.

For an event, the commitment function is similar, but the condition $\sharp_{last(\varpi)}=\textbf{AnonyEvt}\ {\textbf{None}}$. Since event systems and parallel event systems execute forever, the commitment function of them is defined as follows. We release the condition on the final state.

Validity of rely-guarantee specification in a parallel event system means that the system satisfies the specification, which is precisely defined as follows. Validity for programs, events, and event systems are defined in a similar way.

We present the proof rules in Fig. 5, which gives us a relational proof method for concurrent systems. $UNIV$ is the universal set.