1, originated byopen1of the client, to br, and the request 3 fromopen3 of the broker, tos3. We callπ1 valid, because it drives a computation where both the security constraints and compliance of clients/services are guaranteed.
Suppose now that the plan π2 for the second client maps request 2 to br
and request 3 (from the second instance of the broker) tos2. SinceS2does not comply withBr, at run-time a communication involving the actionDelcannot be performed because the broker has no actionDel. Our assumption that the service can decide what to send on its own is violated. For this reason, we say that this plan is not valid. Finally, consider a plan that maps request 3 to s3, that this time is compliant with the broker. HoweverS3 is black-listed by C2, and so a policy violation occurs; also this plan is not valid.
Our task in the next sections will be defining a static analysis that allows us to construct valid plans, only. With such plans, neither violations of security, nor missing communications can occur, so there is no need for any execution monitor at run-time.
Secure and Unfailing Services 173 Intuitively, ε is the history expression that cannot do anything, and thus we stipulateε·H ≡H ≡H·ε.
Infinite behaviour is denoted by μh.H, restricted to be tail-recursive and guarded by communication actions ¯a or a. Events αcan occur, if they do not violate any active policy. The expressionH1·H2is the sequential composition.
An expression can send/receive on a channel messages, indexed by a set I.
To stress that the non-deterministic choice of the outputai is up to the sender only (internal choice), we use⊕, while the external choice only involves inputs ai and is denoted by Σ.
Framing ϕHsays that while H is running, the policyϕ must be enforced (sometimes we assumeϕH≡ϕ·H·ϕ). As anticipated, a policy is a (sort of) finite state automaton that accepts those strings of access events that violate it, in the default-accept paradigm. An example is “never write (αwrite) after read (αread)”, and a trace that violates it is αreadαwrite. When entering a security framing, all the history, i.e. the sequence of events previously fired, must respect the policy: ours is a history-dependent approach. We remark that policies are safety properties: nothing bad occurred so far.
A service is engaged in a session with another through openr,ϕHcloser,ϕ, where r is a unique identifier and ϕis the policy to be enforced while the re- sponding service is active. Later on we will require that a client must be able to synchronize with the server and correctly terminate the session, i.e. client and service have to be compliant.
The following rules inductively define the semantics of a stand-alone history expression.
Operational Semantics of History Expressions
)
i∈Iai.Hi ai
Hi (I-Choice) i∈Iai.Hi ai
Hi (E-Choice) αα ε (Acc) openr,ϕ.H.closer,ϕ
openr,ϕ
H.closer,ϕ (S-Open) ϕHϕ H·ϕ (P-Open) H λ H
H·Hλ H·H
(Conc)
H{μh.H/h}λ H μh.H λ H
(Rec)
We now turn our attention to our specification of networks of services N. In the following definition, we also introduce the notion of planπ.
Definition 2 (Network and Plan)
N ::=NN | S S::=:H | [S, S]
π= [π1, . . . , πn], whereπi, πi::=∅ |r[]|π∪π
Operational Semantics of Networks
H
openr,ϕ
H r[j]∈π {j:Hj} ⊆R |=ηϕ
η, i:H −→openπ,Rr,ϕ ηϕ,[i:H, j:Hj]
(Open)
H
closer,ϕ
H
η,[i:H, j:Hj]−→closeπ,Rr,ϕ ηη, i:H
η=Φ(Hj)ϕ (Close)
η, S−→λ π,Rη, S |=η η,[S, S]−→λ π,R η,[S, S]
(Session)
ηi, Ni λ
−→πi,Rηi, Ni |=ηi (π)i=πi −−−→
(η, N)i=ηi, Ni
−−−→(η, N)−→λ π,R−−−−−−−−−−−−−−−−→
(η, N)[ηi, Ni→ηi, Ni]
(Net)
Hγ H |=ηγ
η, i:H−→γ π,R ηγ, i:H γ∈Ev∪Frm (Access) Hi
a Hi Hj co(a)
HJ
η,[i:Hi, j:Hj]−→τ π,R η,[i:Hi, j:Hj] a∈Comm (Synch) whereΦ(H1·H2) =Φ(H1)·Φ(H2) Φ(ϕ) =ϕ Φ(H) =εotherwise
A networkN is composed of the parallel composition of different clientsH, each hosted at a location∈Loc, and of sessions S involving a client (or a service) and a service. Services are published in a global trusted repository R = {j : Hj|j∈J}, and they are always available for joining sessions.
We assume that the operator is associative, but not commutative, so a network can be written as a vectorN. Instead, we stipulate that [S, S ]≡[S, S].
We can have nested sessions, modelling that a service involved in a session can open a new session with another service. In this case the previous session will be restored upon termination of the new one.
The semantic of networks is the transition system, inductively defined by the rules in the table below. Its configurations have the formi∈Iηi, Siabbreviated by−−→
η, N, whereηi is thehistory of Si. As a matter of fact, access eventsαand policy framingsϕ,ϕare logged into the historyηi. A session can evolve only if its history respects all the active policies inηi, denoted by|=ηi (see below).
We briefly comment on the rules of the operational semantic of networks. The first rule is for opening a session: the service ati fires an eventopenr,ϕ(in the stand-alone semantics); the planπi selects the service atj; and the client and
Secure and Unfailing Services 175 the server get involved in a new session. However, this only occurs if the history η, updated with ϕ recording the policy imposed by the client, satisfies all the policies that are active (see below for a precise definition).
Symmetrically, the ruleCloseends a session. The client continues computing on its own, while the serverHjis terminated. The history of the client is updated with the closing frames of all the policies still active inHj that now make no sense (computed through the auxiliary functionΦ) and the closing frame of the policyϕimposed over the session.
Rule Session governs the independent evolution of an element within a ses- sion; and similarly, ruleN etupdates the network according to the evolution of one of its components.
Rule Access fires an event γ, either an access event or a policy framing;
appends it to the current historyη; and checksηγfor validity.
The premises of rule Synch require a service to send/receive a message ¯a/a, and its partner to receive/send it, written as the co-actiona/¯a. The resulting communication is labelled with the (non observable) actionτ. Note that a com- munication can only take place if both services are inside the same session.
As usual, a computation starts from the initial configurationN0=j∈Jε, Hj, and it is a sequence N0
−→λ π,R i∈Iηi, Ni λ
−→π,R i∈Iηi, Ni. . . Some remarks are now in order, on the way computations proceed, rather on the two ways its participants may get stuck. The first is when all the access events a serviceH may perform violate the security policies that are active. In this case, a resource monitor, formalised by the validity relation |= η, aborts the execution of H.
Note however, that the computation proceeds if there is an event thatH can fire without violating any active policies: our semantics implements the so-called angelic non-determinism.
The second way for deadlocking a component of a network is when two services in a session want to communicate, but the output of one of them is not matched by an input of the other, in other words, the two services arenot compliant. Also here our semantic is angelic, in that it does not respect the requirement saying that the choice among various outputs is done regardless of the environment and of its capability of accepting the sent message.
The main task of our paper is proposing an automated technique to construct plans that drive executions with no deadlocks, namelyvalid plans. We present a static analysis, that checks the text of clients and services and guarantees that the networks, that they originate,only have computations that can always proceed, i.e. that at run-time a component of a network neither violates any security policies, nor does it get stuck because of missing communications. While these problems have been already studied in isolation [5,4,12,13], the combined solution we offer here is new.
We address the security issue along the lines of [5,4]. That machinery, briefly summarised below, can easily be extended to our case. Checking compliance is addressed in the next section.
3.1 Statically Checking Validity
We first intuitively define when a historyη∈(Ev∪Frm)∗ is valid, written|=η;
more detailed definitions are in [5,4]. A history η is balanced when eitherη is empty or is an event, orη=ϕηϕ withη balanced, orη =ηη with bothη andηbalanced. Hereafter, we shall only deal with histories that are prefixes of a balanced history, because such are those that show up when executing a network.
Now, letη be the history obtained by erasing all the framing events from it.
For example, ifη0=γαϕβϕ thenη0=γαβ. A history ηrespects a policyϕ, in symbols η |= ϕ, if it is not recognized by the automaton ϕ; it is valid if it respectsall the polices that are opened, but not closed, i.e. the policies active in η. Since our approach to security is history-dependent, we actually require that all the prefixes ofη respect the relevant policies. For example, consider again the historyη0above, and letϕrequire that noαoccurs afterγ. Then,η0 isnot valid according to our intended meaning, because when firing β, the policy ϕ is activated and the prefixγα does not obey ϕ — note instead thatϕγ ϕαβ would be valid, asϕis no longer active afterγ is fired.
The definition of validity follows, in which we use the auxiliary function AP for computing the multi-set of the active policies inη (&is multi-set union).
Validity
AP(ε) =∅ AP(αη) =AP(η)
AP(ϕη) =AP(η)& {ϕ} AP(ϕη) =AP(η)\ {ϕ} A historyη isvalid (|=η) when∀η0η1 s.t.η0η1=η, ϕ∈ AP(η0).η0|=ϕ
Now the problem is verifying if all the histories generated by a given network lead to a final configuration, with no security violations. This can be done by separately checking if all its clientsHare valid, i.e. that all the histories generated when it is executed are valid. Most likely, H will contain some requests, and serving them will open and eventually close possibly nested sessions with other servicesH, H, . . ., made available by the repositoryR. The idea is to suitably assemble the history expressionsH, H, H, . . ., and recording in a plan for H which service to invoke for each request, so obtaining the pair ˆH, π. Note that Hˆ may be non-valid, even if the composing selected services are valid, each in isolation. Indeed, the impact on the execution history of selecting a serviceHr
for a requestris not confined to the execution ofHr, but it spans over the whole execution, because security is history-dependent. The validity of the composed service ˆH depends thus on the global orchestration, i.e. on the planπ.
In order to ascertain the validity of ˆH, we resort to model checking. The history expressions ˆH is naturally rendered as a BPA process, while finite state automata check its validity against the policies to be enforced. Because of the possible nesting of security framings, validity of history expressions is a non- regular property, so standard model checking techniques cannot be directly
Secure and Unfailing Services 177 applied. In [5,4], a semantic-preserving transformation is presented, that removes the context-free aspects due to policy nesting: it suffices recording the opening of policies, and removing those already opened and their corresponding closures, in a stack-like fashion. In this way, (standard) model checking is efficiently feasible through specially-tailored finite state automata [5,4].