Semantics-based design for Secure Web Services

Transcription

1 1 Semantics-based design for Secure Web Services Massimo Bartoetti Pierpaoo Degano Gian Luigi Ferrari Roberto Zunino Dipartimento di Informatica University of Pisa L.go Bruno Pontecorvo, Pisa, Itay Phone Fax

2 2 Abstract We outine a methodoogy for designing and composing services in a secure manner. In particuar, we are concerned with safety properties of service behaviour. Services can enforce security poicies ocay and can invoke other services that respect given security contracts. This ca-by-contract mechanism offers a significant set of opportunities, each driving secure ways to compose services. We discuss how to correcty pan services compositions in severa reevant casses of services and security properties. To this aim, we propose a graphica modeing framework, based on a foundationa cacuus caed λ req [13]. Our formaism features dynamic and static semantics, so aowing for forma reasoning about systems. Static anaysis and mode checking techniques provide the designer with usefu information to assess and fix possibe vunerabiities. Index Terms Web services, ca-by-contract, anguage-based security, static anaysis, system verification. I. INTRODUCTION Service-oriented computing (SOC) is an emerging paradigm to design distributed appications [42], [41], [25]. SOC appications are obtained by suitaby composing and coordinating (i.e. orchestrating) avaiabe services. Services are stand-aone computationa units distributed over a network, and made avaiabe through standard interaction mechanisms. Composition of services may require pecuiar mechanisms to hande compex interaction patterns (e.g. to impement transactions), whie enforcing non-functiona requirements on the system behaviour, ike e.g. security, avaiabiity, performance, transactionaity, quaity of service, etc. [46]. An important aspect is that services are open, in that they are buit with itte or no knowedge about their operating environment, their cients, and further services therein invoked. Web Services [2], [45], [48] buit upon XML technoogies are possiby the most iustrative and we deveoped exampe of the SOC paradigm. A variety of XML-based technoogies have been devised for describing, discovering and invoking web services [17], [19], [16], [49]. There are aso severa standards for defining and enforcing non-functiona requirements of services, e.g. WS-Security [4], WS- Trust [3] and WS-Poicy [47] among others. The success of the SOC paradigm is highy reated to the deveopment of network infrastructures supporting interoperabe and secure messaging among services, as we as high-eve

3 3 coordination standards. A further eement is the definition of nove methodoogies for modeing, anaysing and certifying SOC systems, see e.g. [26]. A chaenging issue for SOC research is how to compose existing services into more compex ones, aso by propery seecting and configuring services so to guarantee that their composition enjoys some desirabe properties. Non-functiona aspects, e.g security, make service composition even harder. From a methodoogica perspective, Software Engineering shoud faciitate the shift from traditiona approaches to the emerging service-oriented soutions. Aong these ines, one of the goas of this paper is to strenghten the adoption of forma techniques for modeing, designing and verifying SOC appications. In particuar, we propose a SOC modeing framework supporting history-based security and ca-by-contract. The starting point of our work is λ req [13], [8], a foundationa cacuus for describing, seecting and securey composing services. The execution of a program may invove accessing securitycritica resources; these actions are ogged into histories. The security mechanism may inspect these histories, and forbid those executions that woud vioate the prescribed poicies. The ca-bycontract seection mechanism impements a matchmaking agorithm based on service behaviour. This agorithm expoits static anaysis techniques to detect the pans for resoving the ca-bycontract invoved in a service orchestration. In our modeing framework, services are rendered as typed diagrams. Service interfaces extend the WSDL interfaces: besides the standard WSDL attributes, we add semantic information about service behaviour. In our mode, the pubished interface of a service is an annotated functiona type, of the form τ H 1 τ 2. Intuitivey, when suppied with an argument of type τ 1, the service evauates to an object of type τ 2. The annotation H is a sort of context-free grammar that describes a the possibe run-time histories of the services. Thus, H can be expoited to constrain the seection of a service that respects the desired security properties. Service interfaces are mechanicay inferred by a type and effect system. To seect a service that matches a given contract, a cient issues a request of the form. ϕ A request type τ = τ 1 τ2 matches those services with interface τ H 1 τ 2 whose abstract behaviour H respects the poicy ϕ. These services are guaranteed to respect ϕ in a the possibe executions. The seection agorithm searches a service repository for an interface matching the request type. Since service interactions may be compex, it might be the case that a oca choice for

4 4 a service is not secure in a broader, goba context. For instance, choosing a ow-security e- mai provider might prevent you from using a home-banking service that exchanges confidentia data through e-mai. In this case, you shoud have panned the seection of the e-mai and bank services so to ensure their compatibiity. To cope with this kind of issues, we define a static machinery that determines the viabe pans for seecting services that respect a the contracts, both ocay and gobay. The main contributions of the present paper are the foowing: 1) a forma modeing anguage for designing secure services. Our graphica formaism resembes UML activity diagrams, and it is used to describe the workfow of services. Besides the usua workfow operators, we can express activities subject to security constraints. The awareness of security from the eary stages of deveopment wi foster security through a the foowing phases of software production. Our diagrams have a forma operationa semantics, that specifies the dynamic behaviour of services. Moreover, diagrams can be staticay anaysed, to infer the contracts satisfied by a service. Our approach aows for a fine-grained characterization of the design choices that affect security (Section II). We support our proposa with some case study scenarios. 2) the integration of a verification technique to study composition properties of service networks. A static anaysis is used to infer an abstraction of the behaviour of a network. This abstraction is then mode-checked to construct a correct orchestrator that coordinates the running services in a secure manner. Secure orchestration wi aso aow for improving the overa performance by avoiding unnecessary dynamic security checks whie executing services. Studying the output of the mode-checker may highight possibe design faws, and suggest how to revise the cas-by-contract and the security poicies. A the above machinery is competey mechanizabe, and we are impementing a too to support our methodoogy. The fact that the too is based on strong theoretica grounds (i.e. λ req type and effect inference and verifier) positivey impacts the reiabiity to our approach. 3) a study of various panning and recovering strategies. We discuss severa situations in which one needs to take a decision before proceeding with the execution. For instance, when a panned service disappears unexpectedy, one can choose to repan, i.e. to adapt the current pan to the new network configuration. Depending on the boundary conditions and on past experience, one can choose among different tactics. We comment on the feasibiity,

5 5 advantages and costs of each of them. The paper is organized as foows. In Section II we introduce a taxonomy of security aspects in service-oriented appications. Section III, IV and V present our forma mode. In particuar, Section III introduces our design notation and the operationa semantics; Section IV presents service contracts, and outines how they can be automaticay inferred; Section V iustrates how to seect services under the ca-by-contract phiosophy, and discusses some panning and recovering strategies. Two scenarios for secure service composition are presented in Section VI. We concude the paper with some remarks (Section VII) about the expected impact of our methodoogy on Software Engineering, and we discuss some reated works. II. A TAXONOMY OF SECURITY ASPECTS IN WEB SERVICES Service composition heaviy depends on which information about a service is made pubic, on how to choose those services that match the user s requirements, and on their actua run-time behaviour. Security makes service composition even harder. Services may be offered by different providers, which ony partiay trust each other. On the one hand, providers have to guarantee that the deivered service respects a given security poicy, in any interaction with the operationa environment, and regardess of who actuay caed the service. On the other hand, cients may want to protect their sensitive data from the services invoked. In the history-based approach to security, the actua access rights of a running piece of code depend on (a suitabe abstraction of) the execution history of a the pieces of code run so far. This approach has been receiving major attention, both at the eve of foundations [5], [30], [44] and of anguage design and impementation [1], [27]. The observations of security-reevant activities, e.g. opening socket connections, reading and writing fies, accessing critica memory regions, are caed events. Histories are sequences of events. The cass of poicies we are concerned with is that of safety properties of histories, i.e. properties that are expressibe through finite state automata. The typica run-time mechanisms for enforcing history-based poicies are reference monitors, which observe program executions and abort them whenever about to vioate the given poicy. Reference monitors enforce exacty the cass of safety properties [43]. Since histories are the main ingredient of our security mode, our taxonomy speaks about how histories are handed and manipuated by services. We focus on the foowing aspects.

6 6 Stateess / statefu services A stateess service does not preserve its history across distinct invocations (yet it checks the history within each invocation). Instead, a statefu service keeps track of the histories of a the past invocations. Steteess services can enforce poicies that inspect the history of the current invocation ony, e.g. resource usage contro. Statefu services aow for more expressive security poicies: for instance, a statefu service can bound the number of invocations on a per-cient basis, whie a stateess service cannot. More in genera, statefu services can expoit their histories to record security-reevant information about the state of cient sessions. Consider for instance a service that requires password authentication, and that gives ony three chances per hour to authenticate. This can be modeed as a statefu service. In this case the history keeps track of the number of faied authentication attempts. The security poicy prevents the service from being used by a caer for which the history has recorded three faied authentication attempts in the ast hour. Athough stateess services admit security poicies that are ess expressive than those of statefu services, static anaysis can usuay infer enough information to ensure secure composition. For instance, consider a cient that wants to buy some pharmaceuticas through an onine vendor, whie being assured that his shopping ist is not eaked to other services (e.g. insurance companies). Staticay anaysing pharmacy services permits to match the cient with a service conforming to its requirements. This is because the information recorded in stateess histories is enough to show possibe eaks. Loca / goba histories Loca histories ony record the events generated by a service ocay on its site. Instead, a goba history may span over mutipe services. Loca histories are the most prudent choice when services do not trust other services, in particuar the histories they generate. In this case, a service ony trusts its own history but it cannot constrain the past history of its caers, e.g. to prevent that its cient has visited a maicious site. Goba histories instead require some trust reation among services: if a service A trusts B, then the history of A may comprise that of B, and so A may check poicies on the behaviour of B. For instance, consider an aiance of services trusting each other, that wish to impement a distributed back-ist. More in detai, when any of the services in the aiance back-ists (through a suitabe event in the history) an externa service, then a the aiance must abstain from invoking that externa service. This can be impemented

7 7 by making the services in the aiance share a goba history. Before invoking an externa service, the caer inspects the goba history to find whether it has been back-isted beforehand. Note that the trust reationship among the services in the aiance is crucia: even a singe untrusted service coud compromise the security of the aiance, by maiciousy modifying the goba history. To securey impement the goba history, i.e. to protect its integrity, communication between services is done through suitabe cryptographic protocos. These protocos must be designed to be coherent with the existing trust reationship, e.g. signed histories are considered reiabe ony if the signer is trusted [51]. First order / higher order requests A request type τ ϕ τ is first order when both τ and τ are base types (Int, Boo, etc.). Instead, if τ or τ are functiona types, the request is higher order. In particuar, if the parameter (of type τ) is a function, then the cient passes some code to be possiby executed by the requested service. Symmetricay, if τ is a function type, then the service returns back some code to the caer. Mobiity of code impacts the way histories are generated, and demands for particuar mechanisms to enforce security on the site where the code is run. A typica protection mechanism is sandboxing, that consists in wrapping code within an execution monitor that enforces a given security poicy. When there is no mobie code, more efficient mechanisms can be devised, e.g. oca checks on security-critica operations. For instance, Java Appets are mobie code appications running on the cient browser, and they can be invoked through higher order requests. A browser cas a service that returns an appet; the browser runs then the appet, whie enforcing its own security poicy, e.g. the standard Java sandboxing. Actuay, history-based security is more genera than Java, since it checks the a the past execution history, whie Java ony checks the frames in the ca stack [34]. Higher order requests aso aow a cient to pass some mobie code as a parameter to a service. The execution of that code can be constrained both by the cient and by the service, by suitabe poicies imposed on its execution. Dependent / independent threads In a network of services, severa threads may run concurrenty and compete for services. A thread is a computation started from a particuar initiator service in the network. Roughy, initiator services are those deegated by the active actors to attain a given goa. Independent

8 8 threads keep execution histories separated, whie dependent threads may share part of their histories Therefore, dependent threads may infuence each other when using the same service, whie independent threads cannot. Impementing independent threads requires that each service records the history of each thread that invoked that service, i.e. services actuay maintain a mapping from thread initiators to their histories. For instance, consider a service that can be invoked ony once. If threads are independent, this one-shot service has no way to enforce singe use. It can ony check that no thread uses it more than once, because each thread keeps its own history. Dependent threads are necessary to correcty impement the one-shot service. III. SERVICES The basic entity in our graphica formaism is that of service. We sha first describe the syntax of services, and then study how they behave when pugged into a network. A service is represented as a box containing its code. The four corners of the box are decorated with information about the service interface and behaviour. The abe : τ indicates the ocation where the service is made avaiabe, and its certified pubished interface τ (discussed ater on in Section IV). The other abes instead are used to represent the state of a service at run-time. : τ π : τ service ocation + interface τ π orchestration pan B event history (m, Φ) monitor fag m + sequence Φ of active poicies (m, Φ) B service code Fig. 1. Execution state of a service. The abe is an abstraction of the service execution history. In particuar, we are concerned with the sequence of security-reevant events happened sometimes in the past, in the spirit of history-based security [1]. The abe (m, Φ) is a pair, where the first eement is a fag m representing the on/off status of the execution monitor, and the second eement is the sequence ϕ 1 ϕ k of active security poicies. The monitor must check that services adhere to each poicy ϕ i, for i 1..k, when the fag is on. Security poicies are modeed as reguar properties

9 9 of event histories, i.e. properties that are recognizabe by a finite state automaton. Athough the soundness of our design and anaysis techniques does not depend on the ogic chosen for expressing reguar properties of histories, we find it convenient to express poicies through our tempate security automata (see beow). The abe π is the pan used for resoving service choices. A pan formaises how a caby-contract is transformed into a ca-by-name. Pans may come in severa different shapes [11]. Here we focus on a very simpe form of pans, i.e. mappings from request abes r to service ocations. We represent pans with the syntax defined in Fig. 2. π,π ::= 0 empty r[] service choice r[?] unresoved choice π π composition Fig. 2. Syntax of pans. The empty pan 0 has no choices; the pan r[] associates the service pubished at site with the request abeed r. A pan is compete when it has no unresoved choices. Composition on pans is associative, commutative and idempotent, and its identity is the empty pan 0. Since pans are functions, they have a singe choice for each request, i.e. r[] r[ ] impies =. The abe B inside the box is a bock that describes the workfow behaviour of the service, in particuar of the security-reevant activities. Formay, B it is a contro fow graph [40] with nodes modeing activities, and arrows modeing intra-procedura fow. The syntax of activities and fow graphs are defined in Fig. 3, whie Fig. 4 summarizes the reevant syntactic categories. Activities comprise basic activities, events, requests, security bocks, and panning bocks. A basic activity a is an interna computation that does not affect security-critica objects. For instance, evauating a booean or arithmetic expression are basic activities. An event α(o) abstracts from a security-critica action α performed on an object o. For instance, write(foo) for writing the fie foo, sgn() for a certificate signed by, etc. We simpy write α when the target object is immateria. A service request takes the form. The abe r uniquey identifies the request in a

10 10 A ::= activities a basic activity α(o) event request ϕ[b] security bock {B} panning bock B = (N, Λ, ) service fow graph where N finite set of nodes Λ : N A abeing function N N set of arrows Fig. 3. Syntax of services. network of services, and the request type τ is defined by: τ ::= b τ ϕ τ where b is a base type (Int,Boo,void,...). The annotation ϕ on the arrow is the query pattern (or contract ) to be matched by the invoked service. For instance, the request type τ ϕ τ matches services with functiona type τ τ, and whose behaviour respects the poicy ϕ. A security bock ϕ[b] annotates B with the poicy ϕ, with the intention that ϕ must be obeyed whie running B. This can be accompished by enabing the execution monitor, that checks the history against ϕ at each step of the execution of B. We sha see ater on a static anaysis of services that wi aow to turn off the execution monitor, whie guaranteeing that the poicy ϕ is obeyed. A panning bock {B} constructs a pan for the execution of B (see Section V for more detais on how this is accompished). Both kinds of bocks can be nested, and they determine the scope of poicies (hence caed oca poicies [7]) and of panning. Service fow graphs B = (N, Λ, ) are directed graphs, where N is the (finite) set of nodes, Λ is a function that maps nodes to activities, and is the set of arrows. Note that oops are

11 11 o,o,... Obj Objects (a finite set) α,α,... Act Actions (a finite set) α(o),... Ev = Act Obj Events,,... Ev Histories (finite sequences of events) ϕ,ϕ,... Po Poicies (reguar properties of histories) r,r,... Req Request abes,,... Loc Service Locations π,π,... Req Loc Pans (functions from Req to Loc) Fig. 4. Syntactic categories. permitted in fow graphs, to mode iterative computations. We assume that each graph has a singe entry node, and a singe exit node. This graphica formaism is based on λ req, a ca-by-vaue λ-cacuus enriched with oca security poicies and ca-by-contract service requests. Since our main focus is on secure composition, in the graphica mode we do not render a the features of λ req. In particuar, we negect variabes, higher-order functions, and parameter passing. However, we fee free to use these features in our exampes, because their treatment can be directy inherited from λ req. Semantics of services We formay define the behaviour of services through a graph rewriting semantics [6]. In this section, we assume that the services which initiate a computation are furnished with an arbitrary pan. In the next section, we sha discuss a static machinery that wi enabe us to construct these pans so to guarantee that computations wi never go wrong, i.e. they satisfy a the contracts and the security poicies on demand. We sha aso show some strategies to adopt when services disappear unexpectedy (Section V). The graph rewriting semantics for the case of dependent threads is spit in two parts: basic activities, events, security bocks, requests and returns are shown in Fig. 5. Instead, Fig. 10 detais the rues that invove panning and recovering strategies, i.e. panning bocks, requests to unavaiabe services, unresoved requests, services going down and up, and pubication of new services. We sha briefy discuss the case of independent threads beow in this section.

12 12 A the remaining axes in the taxonomy are covered by our semantics When irreevant, we omit the abe τ in services. Note that the actua vaues for some abes in rues REQ and RET are defined ater on in Fig. 6, since they depend on the choice made on the security aspects discussed in Section II. This gives rise to different behaviours of requests and returns according to the possibe choices in the taxonomy. The configurations of our semantics are sets (i.e. networks) of services. We mark the next activity to be performed by a running service with an overine, e.g. α(o) means that the event α(o) is about to be fired. An activity just executed is marked with an underine, e.g. α(o). We extend this notation to bocks B, i.e. B means that the entry node of B is the next activity, whie B means that the exit node of B was the ast executed one. Aso, configurations comprise dashed arrows that connect a running request with the invoked service. We now briefy discuss the graph rewritings in Fig. 5. Note that we ony depict rewriting within a context. For instance, the rewriting a a in the SKIP rue can be appied in any context, i.e. within any bock B containing a. A basic activity is just passed over (rue SKIP). The evauation of an event α(o) requires checking compiance of the new history α(o) with each poicy ϕ in Φ (denoted α(o) = Φ), if the execution monitor is on. If a the poicies are respected (rue EV), then α(o) is appended to the current history, and the execution proceeds to the next bock. Otherwise, if some poicy is vioated (rue FAIL), then the execution goes into a stuck state fai. This state modes a security exception (for simpicity, we do not mode here exception handing; extending our formaism in this direction woud require to define, among the other things, how to compensate from aborted computations, e.g. ike in Sagas [32], [20]) The rue SEQ says that, after a bock B has been evauated, the next activity is chosen among the bocks with incoming arrows from B. Note that branching is a specia case of SEQ, where the bock B is a conditiona or a switch. Entering a security bock ϕ[b] resuts in appending the poicy ϕ to the sequence of active poicies. Leaving ϕ[b] removes ϕ from the sequence. In both cases, as soon as a history is found not to respect ϕ, and the execution monitor is on, the evauation gets stuck. A request under a pan r[ ] π ooks for the service at site. If the service is avaiabe (rue REQ), then the cient estabishes a session with that service (dashed arrow),

13 13 π π π π a SKIP a B SEQ B B i B i (m, Φ) (m,φ) (m, Φ) (m, Φ) π π π π α(o) EV α(o) α(o) FAIL fai (m,φ) if m is on, α(o) = Φ α(o) (m,φ) (m, Φ) m is on, α(o) = Φ (m, Φ) π π π π ϕ[b] SECIN ϕ[b] ϕ[b] SECOUT ϕ[b] (m, Φ) (m, Φϕ) (m, Φϕ) (m, Φ) r[ ] π r[ ] π r[ ] π B REQ B, Φ in Fig. 6 (m,φ) (m, Φ) (m, Φ ) π π π B RET B in Fig. 6 (m,φ) (m, Φ ) (m, Φ) Fig. 5. Semantics of services in the case of dependent threads (Part I). and waits unti it returns. Note that the meaning of the abes and Φ is eft undefined in Fig. 5, since it depends on the choice made on the security aspects discussed in Section II. The actua vaues for the undefined abes are shown in Fig. 6. In particuar, the initia history of the invoked service is: (i) empty, if the service is stateess with oca history; (ii)

14 14 REQ Stateess service Statefu service Loca histories Goba histories Loca histories Goba histories = ε = = = Φ = ε Φ = Φ Φ = ε Φ = Φ RET = = = = Fig. 6. Histories and poicies in four cases of the taxonomy. the invoker history, if the service has a goba history; (iii) the service past history, if the service is statefu, with oca history. Returning from a request (rue RET) requires suitaby updating the history of the caer service, according to chosen axes in the taxonomy. The actua vaues for the history are defined in Fig. 6. The cases N/A, PLG IN, PLG OUT and UNRES are defined in Fig. 10, and they have many possibe choices. When no service is avaiabe for a request (e.g. because the pan is incompete, or because the panned service is down), or when you have to construct a pan for a bock, the execution may proceed according to one of the strategies discussed in Section V. A pan is viabe when it drives no stuck computations (uness some service mentioned in the pan becomes unavaiabe). Under a viabe pan, a service can aways proceed its execution without attempting to vioate some security poicy (therefore the execution monitor is unneeded), and it wi aways manage to resove each request. The static machinery described in Section IV discovers viabe pans. An exampe Consider a network composed by two services at ocations and, both statefu and sharing a goba history. The service at starts with an action α (the omitted target object is immateria in this exampe), and then issues a request r, resoved to by the provided pan. The service at performs α within a security bock ϕ[ ], where the poicy ϕ prevents α from being fired twice. A computation of the network is depicted in Fig. 7, where we assume the execution monitor is on. Note that the pan r[ ] is not viabe, because it drives a computation that fais because of an attempted security vioation, right before the second α is fired at.

15 15 r[ ] r[ ] α ϕ[α] EV α ϕ[α] SEQ ε (on, ) ε α (on, ) ε r[ ] r[ ] r[ ] α ϕ[α] REQ α ϕ[α] SECIN α (on, ) ε α (on, ) α (on, ) r[ ] r[ ] r[ ] r[ ] α ϕ[α] FAIL α fai αα = ϕ α (on, ) α (on, ϕ) α (on, ) α (on, ϕ) Fig. 7. A computation of two statefu services with goba history. Independent threads To mode independent threads, each service must keep a separate history for each thread. Equivaenty, we keep a history for each thread initiator. To this aim, instead of a singe history, services now carry a function L mapping the abe I of each initiator to its corresponding history. Moreover, we keep track of the initiator name: each service invoked on behaf of the initiator I is tagged as such. The semantics of services can now be easiy adapted, making L( I ) pay the roe of in the semantics for dependent threads. We depict in Fig. 8 the rue REQ for independent threads. The reation among,, Φ and Φ is sti the one defined by Fig. 6. Note that is used to update L( I ), ony: a other histories in L are eft unchanged. The rue RET is deat with simiary, as for the rues FAIL, PLG IN and PLG OUT. Modeing security poicies Security poicies ϕ are reguar properties of histories, and they are defined through tempate security automata A ϕ(x). A tempate security automaton gives rise to a finite state automaton

16 16 r[ ] π r[ ] π r[ ] π B REQ B = L( I) I, Φ in Fig. 6 I I L (m, Φ) L L = L{ I } L (m, Φ) L (m, Φ ) Fig. 8. Maintaining separate histories in the case of independent threads. when the parameter x is instantiated to an actua object o. These automata wi be expoited to recognize those histories obeying ϕ. Formay, a tempate security automaton A ϕ(x) is a 5-tupe (S,Q,q 0,F,E), where x is a parameter, and: S Act (Obj {x, x}) is the input aphabet, Q is a finite set of states, q 0 Q \ F is the start state, F Q is the set of fina offending states, E Q S Q is a finite set of tempate edges, written q ϑ q. The edges in a tempate security automaton can be of three kinds: either q α(o) q where o is an object, or q α(x) q, or q α( x) q (where x means different from x ). Given a object o Obj, a tempate security automaton A ϕ(x) is instantiated into a finite state automaton A ϕ(o) by binding the variabe x to o. The intuition is that q α(x) q wi resut in an actua transition q α(o) q, whie q α( x) q wi give rise to a finite set of transitions q α(o ) q, for a o Obj \ {o}. More formay, et A ϕ(x) = (S,Q,q 0,F,E) be a tempate security automaton, and et o Obj. The finite state automaton A ϕ(o) is defined by the 5-tupe (Ev,Q,q 0,F,δ), where the transition reation δ is defined as foows: δ = δ {q α(o ) q o Obj, q : q α(o ) q δ }

17 17 where the auxiiary reation δ is defined as: δ = {q α(o) q q α(x) q E } o Obj\{o} {q α(o ) q q α( x) q E } {q α(o ) q q α(o ) q E } Note that the definition for δ adds sef-oops for a the events not expicity mentioned in the tempate automaton A ϕ(x). We say that a history respects ϕ, written = ϕ, when is not in the anguage of A ϕ(o), for a o Obj. When is in the anguage of A ϕ(o) for some object o, we say that vioates ϕ, written = ϕ. Note that instantiated tempate security automata are non-deterministic. Given a history and a poicy ϕ, we want that a the traces of the instances of A ϕ(x) compy with ϕ. This is a form of diaboic (or interna) non-determinism. To account for that, we make the offending states as fina thus going into a fina state represents a vioation of the poicy, whie the other states mean compiance to the poicy. IV. CALL-BY-CONTRACT A service B is pugged into a network by pubishing it at a site, together with its interface τ. We assume that each site pubishes a singe service, and that interfaces are certified, e.g. they are inferred by the type and effect system simiar to that in [13]. Aso, we assume that services cannot invoke each other circuary, since this is quite unusua in the SOC scenario. Contracts The types τ are annotated with history expressions H that over-approximate the possibe runtime histories. Fig. 9 dispays the syntax of types and history expressions. When a service with interface τ H τ is run, it wi generate one of the histories denoted by H. Note that we overoad the symbo τ to range over both service types and request types τ ϕ τ. History expressions, defined in Fig. 9, are a sort of context-free grammars. They incude the empty history ε, events α, and H H that represents sequentiaization of code, H + H for branching, security bocks ϕ[h], recursion µh.h (µ binds the occurrences of the variabe h in H), ocaization : H, and panned seection {π 1 H 1 π k H k }.

18 18 τ,τ ::= types b base type τ H τ annotated functiona type H,H ::= history expressions ε empty h variabe α(o) event H H sequence H + H choice ϕ[h] security bock µh.h recursion : H ocaization {π 1 H 1 π k H k } panned seection Fig. 9. Service interfaces: annotated types and history expressions The semantics of a history expression is a set of histories, possiby carrying security annotations in the form ϕ[]. We denote by H the semantics of H. We now briefy describe how this semantics is constructed: see [8] for the forma treatment. The semantics of the history expression α is the set of histories {α}. The semantics of H H is the set of histories such that H and H. The semantics of H + H comprises the histories such that H H. The semantics of ϕ[h] is the set of histories ϕ[] such that H. The semantics of µh.h is the east fixed point of the operator f(h) = H {H/h}, where we denote with H ρ the semantics of a history expression H in an environment ρ, mapping variabes h to sets of histories. For instance, the semantics of µh. (γ + α h β) consists of a the histories α n γβ n, for n 0 (i.e. γ, αγβ, ααγββ,...). The construct : H ocaizes the behaviour H to the site. E.g., : α ( : α ) β denotes two histories: αβ occurring at ocation, and α occurring at. A panned seection abstracts the behaviour of service requests. Given a pan π, a panned

19 19 seection {π 1 H 1 π k H k } chooses those H i such that π incudes π i. Intuitivey, the history expression H = {r[ 1 ] H 1,r[ 2 ] H 2 } is associated with a request r that can be resoved into either 1 or 2. The histories denoted by H depend on the given pan π: if π chooses 1 (resp. 2 ) for r, then H denotes one of the histories represented by H 1 (resp. H 2 ). If π does not choose either 1 or 2, then H denotes no histories. Certifying contracts and panning Our panning and verification technique for services is inherited from that of the λ req cacuus. The interested reader can find the forma foundations of our work in [10], [8]. Here, we ony summarize the reevant resuts for our present modeing framework. A static anaysis over our diagrams infers judgements of the form H B : τ. Roughy, this means that the service with code B has type τ, and its execution histories are represented by the history expression H. This static anaysys enjoys two fundamenta resuts. Correctness. Effects correcty over-approximate service run-time histories More formay, consider a service with code B such that H B : τ. If running the service (pugged into a network) generates a history, then B ([8], Th. 1). The second property of our static anaysis is type safety. We say that an effect H is vaid under a pan π when the histories denoted by H never vioate the security poicies in H. Type safety ensures that, if (staticay) the effect of a service B is vaid under a pan π, then (dynamicay) the pan π is viabe for B. Type safety. Vaid effects drive computations that never attempt security vioations. More formay, consider a service with code B such that H B : τ. If H is vaid under π, then the execution is secure (i.e. = Φ whenever a running service carries abes and (m, Φ)), and it never reaches a fai configuration. Moreover, if π is compete (i.e. it has no unresoved choices r[?]) and the chosen services do not disappear, then the execution monitor can be safey kept off ([8], Th. 2). A further resut is that the vaidity of history expressions can be mechanicay verified.

20 20 Mode-checking. Vaidity for history expressions is mode-checkabe. The actua mode-checking agorithm for the vaidity of H returns the set of pans under which H is vaid. Determining such viabe pans is not a trivia task: indeed, resoving requests independenty might not ead to a viabe pan, as discussed in the introduction. Our modechecking technique requires severa preiminary steps. Technicay, we first inearize the history expression H to coect a the pans and the associated effects, whie preserving the semantics of H ([8], Ths. 4 and 5). The resuting history expression has the form of a singe, top-eve panned seection {π 1 H 1 π k H k }. We can then check each H i independenty. First, H i is reguarized to remove the redundant framings ϕ[ ϕ[ ] ] ([8], Th. 6). This makes possibe to construct a finite state automaton that recognizes the vaidity of histories ([8], Lemma 8). This finite state automaton is then used in the actua mode-checking of H i ([8], Th. 8). If H i mode-checks, then the associated pan π i is viabe. Summing up: Panning = Correctness + Type Safety + Mode Checking V. PLANNING AND RECOVERING STRATEGIES We now consider the probem of choosing the appropriate service for a bock of requests. Whie one might defer service seection as much as possibe, thus ony performing it when executing a request, it is usuay advantageous to decide how to resove requests in advance, i.e. to buid a pan. This is because eary panning can provide better guarantees than ate service seection. For instance, consider a bock with two consecutive requests r 1 and r 2. It might be that, if we choose to resove r 1 with a particuar service 1, ater on we wi not be abe to find safe choices for r 2. In this case we get stuck, and we must somehow escape from this deadend, possiby with some expensive compensation (e.g. canceing a reservation). Eary panning, instead, can spot this kind of probems and try to find a better way, typicay by considering aso r 2 when taking a choice for r 1. As seen in the previous section, a compete viabe pan π for a bock B guarantees that B can be securey executed without execution monitoring, and that we wi never get stuck uness a service mentioned in π becomes unavaiabe. When we cannot find a compete viabe pan, we

21 21 coud fa back to using an incompete pan with unresoved requests r[?]. In this case, we get a weaker guarantee than the one above, namey that we wi not get stuck unti an unresoved request must actuay be executed. To provide gracefu degradation in our mode, we aso consider the unfortunate case of executing a request r when either r is sti unresoved in the pan (Rue UNRES), or r is resoved with an unavaiabe service (Rue N/A, for Not Avaiabe). Notationay, unavaiabe services are represented as sashed boxes. Therefore, we wi ook for a way to continue the execution, possiby repairing the pan. Figure 10 formaizes the behaviour of services reated to panning and recovering. Rue DOWN modes an ide service becoming unavaiabe. For simpicity, we assume that services cannot become unavaiabe whie serving a request. Unavaiabe services are modeed as sashed boxes. Rue UP modes an unavaiabe service going back to the avaiabe state. Rue PUB is for service pubishing. The behavioura interface τ of a new service (with code B) must be staticay certified, written H B : τ. Note that H = ε for non-initiator services. The effect of an invoked service with type τ = τ 0 H τ 1 is the atent effect H. Rue N/A modes a request to an unavaiabe service. Recovering from this situation demands for updating the current pan, and possiby activating the execution monitor. Beow in this section we sha examine some possibe strategies for doing that. Rue UNRES handes the case of unresoved requests. These are deat with simiary to the rue N/A. Rue PLN IN describes which actions have to be taken when entering a panning bock {B}. Before start the execution of B, we need to devise a pan for resoving the service requests in B. Again, severa strategies are appicabe, as discussed beow. Rue PLN OUT simpy exits from a panning bock. This operation affects neither the pan nor the execution monitor. We now discuss some strategies for constructing or repairing a pan. As a matter of fact, no strategy is aways better than the others, since each of them has advantages and disadvantages, as we wi point out. The choice of a given strategy depends on many factors, some of which ie outside of our forma mode (e.g. avaiabiity of services, cost of dynamic checking, etc.). We devise four main casses of strategies:

22 22 B DOWN B B UP B : τ r[?] π π H B : τ fresh PUB ε B (m, Φ) UNRES π, m, Φ in Fig. 11 (m, Φ ) r[ ] π π N/A π, m, Φ (m,φ) in Fig. 11 (m, Φ ) π π π π {B} PLNIN {B} {B} PLNOUT {B} π, m, Φ (m,φ) in Fig. 12 (m, Φ ) (m,φ) (m, Φ) Fig. 10. Semantics of services in the case of dependent threads (Part II). Greyfriars Bobby. 1 Foow oyay a former pan. If a service becomes unavaiabe, just wait unti it comes back again. This strategy is aways safe, athough it might obviousy bock the execution for an arbitrariy ong time possiby forever. Patch. Try to reuse as much as possibe the current pan. Repace the unavaiabe services with avaiabe ones, possiby newy discovered. The new services must be verified for compatibiity with the rest of the pan. 1 In 1858, a man named John Gray was buried in od Greyfriars Churchyard in Edinburgh. The famous Skye Terrier, Greyfriars Bobby was so faithfu to his master that for fourteen years, unti his own death, Bobby ay on the grave ony eaving for food.

23 23 Sandbox. Try to proceed with the execution monitor turned on. The new pan ony respects a weak form of compatibiity on types ignoring the effect H, but it does not guarantee that contracts and security poicies are aways respected. Turning on the execution monitor ensures that there wi not be security vioations, but execution might get stuck ater on, because of attempted insecure actions. Repan. Try to reconstruct the whoe pan, possiby expoiting newy discovered services. If a viabe pan is found, then you may proceed running with the execution monitor turned off. A compete pan guarantees that contracts and security poicies wi be aways respected, provided than none of the services mentioned in the pan disappear. In Fig. 11, we describe the effects of these strategies in the context of the N/A and UNRES rues. There, we aso make precise the recovered pan π and the (m, Φ ) appearing in the rue. For the Greyfiars Bobby strategy, we patienty wait for the service to reappear; on timeout, we wi try another strategy. The Patch strategy mends the current pan with a oca fix. Note that the Patch strategy is not aways safe: in the genera case, it is impossibe to change just the way to resove the faiing request r and have a new safe pan. We sha return on this issue ater on. However, as the figure shows, in some cases this is indeed possibe, provided that the pan with the new choice for r is checked for vaidity. The Repan strategy is safe when a suitabe pan is found, but it coud invove staticay re-anaysing a arge portion of the system. When a ese fais, it is possibe to run a service under a Sandbox, hoping that we wi not get stuck. From now onwards, we use the foowing abbreviations for the various aternatives described in Section II: stateess (1) / statefu (ω), oca (L) / goba (G), first order (F) / higher-order (H), dependent (D) / independent (I). For instance, the case IFL1 in the figure is the one about independent threads, first order requests, oca histories, and stateess services. In Fig. 12 we ist the strategies for the rue PLN IN, describing how to buid a pan for a bock B. Note that, when we construct a new pan π we aready have a pan π π B, where π B ony pans the requests inside B. We can then reuse the avaiabe information in π and π B to buid π. The former pan π π B can be non-empty when using nested panning bocks, so reusing parts from it is indeed possibe. Since we can reuse the od pan, the strategies are exacty the same of those for the N/A case. The Greyfriars Bobby strategy waits for a the services mentioned in the od pan to be avaiabe at panning time. This is because it might be wise not to start the bock, if we know

24 24 STRATEGY STATE UPDATE CASE CONDITION Greyfriars Bobby Patch Sandbox Repan π Φ π r[ i ] Φ π r[ i ] (on, Φϕ) π (off, Φϕ) a The current pan π has a choice for r IFL1 ϕ[h i ] is vaid IFLω ϕ[h i ] is vaid, and i π IFG1 ϕ[h i ] is vaid DFL1 ϕ[h i ] is vaid a The service i has type τ τ a The new pan π has a choice for r Fig. 11. Faiure handing strategies for a request ϕ τ. that we wi ikey get stuck ater. Instead, if some services keep on being unavaiabe, we shoud rather consider the other strategies. As for the N/A rue, the Patch strategy is not aways safe, but we can sti give some conditions that guarantee the safety of the pan update, which is oca to the bock B. The Repan strategy, instead, can change the whoe pan, even for the requests outside B. If possibe, we shoud aways find a compete pan. When this is not the case, we might proceed with some unresoved requests r[?], deferring them to the N/A rue. As a ast resort, when no viabe pan can be found, or when we deem Repan to be too expensive, we can adopt the Sandbox strategy that turns on the execution monitor. We now show a situation where the Patch strategy is not safe. We consider the case IFLω case (independent threads, first order requests, oca histories, statefu services). The initiator service, in the midde of Fig. 13, performs two requests r 1 and r 2 in sequence. The two requests have the same contract, and thus they can be resoved with the statefu services 1 and 2. The service at 2 performs an event α, within a security bock ϕ. If ϕ aows a singe occurrence of α, we shoud be carefu and invoke the (statefu) service 2 at most once. The current pan π = r 1 [ 1 ] r 2 [ 2 ] is safe, since it invokes 2 exacty once.

25 25 STRATEGY STATE UPDATE CASE CONDITION Greyfriars Bobby π π B Φ a The pan π B has a choice for a r i IFL1 ϕ[h i ] is vaid, for a i Patch π r i [ i ] Φ IFLω IFG1 ϕ i [H i ] are vaid, i are distinct, and a i π i ϕ i [H i ] are vaid, for a i DFL1 ϕ i [H i ] are vaid, for a i Sandbox π r i [ i ] (on, Φϕ) a The services i have type τ i τ i H vaid under π, where Repan π (off, Φϕ) a is the current history, and H approximates the future behaviour (may need to refine the anaysis) Fig. 12. ϕ Panning strategies for a bock B invoving requests req ri τ i i τ i 1 : τ : τ r 1[ 1] r 2[ 2] 2 : τ req r1 τ req r2 τ ϕ[α] 1 (m 1, Φ 1) (m, Φ) 2 (m 2, Φ 2) Fig. 13. An unsafe use of the Patch strategy. Now, consider what happens if the service 1 becomes unavaiabe. The N/A rue is triggered: if we appy Patch and repace the current pan with r 1 [ 2 ] r 2 [ 2 ], then this patched pan is not viabe. Indeed, the new pan invokes 2 twice, so vioating ϕ. The safety condition in Fig. 11 is fase, because 2 π: therefore, this dangerous patch is correcty avoided.

26 r[ 1] r [ 2] >< >: req r τ 9 >= >; 2 ϕ 6 4 act α β ϕ[α] PLNIN 8 >< >: req r τ 9 >= >; 2 ϕ 6 4 act α β ϕ[α] REQ ε (off, ) ε ε ε (off, ) ε ε 0 r[ 1] r [ 2] 1 r[ 1] r [ 2] 2 0 r[ 1] r [ 2] 1 r[ 1] r [ 2] 2 8 >< >: req r τ 9 >= >; 2 ϕ6 4 act α β ϕ[α] SECIN SKIP SEQ EV SECOUT 8 >< >: req r τ 9 >= >; 2 ϕ6 4 act α β ϕ[α] RET DOWN ε (off, ) ε (off, ) ε ε (off, ) α (off, ) ε 0 r[ 1] r [ 2] r[ 1] r [ 1] >< >: req r τ 9 >= >; 2 ϕ 6 4 act α β ϕ[α] N/A 8 >< >: req r τ 9 >= >; 2 ϕ 6 4 act α β ϕ[α] ε (off, ) α ε ε (on, ) α ε Fig. 14. Semantics Exampe An exampe We show in Fig. 14 a short exampe iustrating our service semantics, in the case of statefu oca histories (ILFω). The network is composed of three services: an initiator (abeed 0 ) and two other services ( 1 and 2 ). The initiator performs two requests using the same contract τ; in this exampe we simpy assume that both services 1 and 2 are compatibe with τ. The service 1, when invoked, runs some activity act and then may perform either the event α or the event β. Instead, 2 may perform α, ony. Both services run their code under a oca poicy ϕ, stating that the event α can be performed at most once, in the whoe ife of each service. In the initia state, a the histories are empty (ε), the initiator has not yet computed a pan (0), and the execution monitor is not active (off ).

27 27 We now comment on the transitions. For brevity, in Fig. 14 we sometimes compacted more steps in a singe one, as we sha point out shorty. First, rue PLNIN is used to form a pan, resoving both requests r and r. There are four possibe pans, since each of the requests can be resoved with either 1 or 2. Invoking 2 twice wi surey vioate the poicy ϕ. Service 1 coud aso invaidate the poicy ϕ if the α branch is taken in both invocations: our static machinery, to err on the safe side, assumes this worst-case situation and consider invoking 1 twice as unsafe. So, the ony viabe pans are r[ 1 ] r [ 2 ] and r[ 2 ] r [ 1 ]. In the figure we choose the first pan. In the second transition we simpy use rue REQ and invoke 1. Then many transition rues are appied: we enter the security bock with rue SECIN; we run act with rue SKIP; we choose the α branch with rue SEQ; we run α with rue EV; we finay exit the security bock with rue SECOUT. The event α is therefore recorded in the history of 1. Finay, we can return to 0 using rue RET. Here, we show what happens if service 2 becomes unavaiabe through rue DOWN. To run request r we can not use rue REQ, but instead we can appy rue N/A and try to recovery from the faiure of 2. We then appy the Sandbox strategy. We turn on the execution monitor, and fix the pan so that r resoves to some avaiabe service compatibe with τ: in the exampe, 1. Doing this, we sha run again service 1. If the service wi attempt to perform another α, this wi be prevented by the execution monitor. If instead 1 wi choose the β branch, it wi compete successfuy. VI. SCENARIOS FOR SECURE SERVICE COMPOSITIONS To iustrate some of the features and design faciities made avaiabe by our framework, we consider two sma case studies. First, we consider a car repair scenario, where a car may break and then request assistance from a tow-truck and a garage. The second scenario is about an embedded computationa device that wants to deegate execution of mobie code. A. Car repair In this scenario, we assume a car equipped with a diagnostic system that continuousy reports on the status of the vehice. When the car experiences some major faiure (e.g. engine overheating, exhausted battery, fat tyres) the in-car emergency service is invoked to seect the appropriate tow-truck and garage services. The seection may take into account some driver custom poicies,