A Static Approach to Secure Service Composition

Transcript

1 A Static Approach to Secure Service Composition Massimo Bartoletti Pierpaolo Degano Gian-Luigi Ferrari Roberto Zunino Dipartimento di Informatica Università di Pisa

2 Summary Overview issues in secure service composition safety framings and policies req-by-contract for service request plans for secure orchestration A calculus for service composition syntax and operational semantics type & effect system Plans & Orchestration constructions of plans and linearization model-checking viable plans

3 Programming in a world of services l 1 τ 1 l 3 τ 3 S1 S3 l 2 τ 2 client l 4 τ 4 S2 S4

4 Programming in a world of services service location l 1 τ 1 service code l 3 τ 3 S1 S3 l 2 τ 2 client l 4 τ 4 S2 service interface S4 service orchestration

5 Security and service composition two kinds of security concerns: secrecy of transmitted data, authentication, etc (protocol analysis techniques) control on computational resources (access control, resource usage analysis, information flow control, etc) need for linguistic mechanisms that: work in a distributed setting assume no trust relations among services can also cope with mobile code

6 Security and service composition: safety framings Client wants to protect from untrusted results client applet service Linguistic mechanism: safety framing ϕ[applet] applet service The policy ϕ is enforced stepwise within its scope

7 Security and service composition: safety framings Similarly, services want to protect from clients client remote exec result service (now the safety framing belongs to the service) client remote exec result ϕ [exec] Scoped policies check the local execution histories

8 Security and service composition: service selection Req-by-name: request a given service among many S1 req S2 S2 S3 Why S2 and not S1 or S3, if all functionally equivalent?

9 Security and service composition: service selection Problems with request by name : what if named service S2 becomes unavailable? and if S2 is outperformed by S1 or S3? hard reasoning about non-functional properties of services (e.g. security) security level independent of the execution context (unless hard-wired in the service code) From syntax-based to semantics-based invocation Service names l,l,.. tell me nothing about the behaviour!

10 Security and service composition: service selection Req-by-contract: request a service respecting the desired behaviour req τ S1 only S1 is guaranteed to match the behaviour τ τ1 τ2 τ3 S1 S2 S3 τ imposes both functional and non-functional constraints

11 Use cases for Req-by-contract Example: download an applet that obeys the policy ϕ req τ 0 ( τ 1 ϕ[ ] τ 2 ) Example: a remote executer that obeys the policy ϕ req ( τ 0 τ 1 ) ϕ ϕ [ ] τ 2

12 Observable behaviour access events are the actions relevant for security (e.g. read/write local files, invoke/be invoked by a given service, etc) mechanically inferred, or inserted by programmer. their meaning is fixed globally. access events cannot be hidden. the (abstract) behaviour observable by the orchestrator over-approximates the run-time histories, i.e. sequences of access events (via a type & effect system).

13 What kind of policies? History-based security Policies ϕ are regular properties event histories Policies ϕ,ϕ ϕ have a local scope, possibily nested ϕ[ ϕ ϕ [ ] A policy can only control histories of a single site (no trust among services) Histories are local to stateless service sites (stateful easy)

14 Example: the Chinese Wall policy ϕ Chinese Wall: cannot write (α w ) after read (α r ) A ϕ α r α w q0 q1 q2 q2 non-final sink α w α r * α w α r α w ϕ

15 Principle of Least Privilege Programs should be granted the minimum set of rights needed to accomplish their task A service must always obey all the active policies (no policy override) Policies can always inspect the whole past history (no event can be discarded) Privileged calls implemented by policies that explicitly discard the past

16 Service publication (1) l 1 τ 1 l 1 {S1}: τ 1 l 2 {S2}: τ 2 1. infer τ 3 from S3 2. mark S3 so to prevent spoofing l 2 l 3 S1 τ 2 S2? S3

17 Service publication (2) l 1 τ 1 l 1 {S1}: τ 1 l 2 {S2}: τ 2 l 3 {S3}: τ 3 l 2 S1 τ 2 S2 Service Repository l 3 τ 3 S3

18 Service orchestration l 0 H l 1 S1 l i {S i }: τ i req r τ π 1. combine τ with the τ i to infer the abstract behaviour H 2. extract from H a viable plan π forl 0 l 2 l 3 S2 S3

19 Service orchestration l 0 H req r τ Plan π = r[l 2 ] l 1 l 2 S1 S2 l 3 S3 Names are only known by the orchestrator!

20 What is a plan? A plan drives the execution of an application, by associating each service request with one (or more) appropriate services With a viable plan: executions never violate policies there are no unresolved requests you can then dispose from any execution monitoring! Many kinds of plans: Simple: one service for each request Multi-choice: more services for each request Dependent: one service, and a continuation plan

21 Who do we trust? The orchestrator, that: certifies the behavioural descriptions of services (types annotated with effects H) composes the descriptions, and ensures that selected services match the requested types extracts the viable plans (through model-checking) Also, someone must ensure that services do not change their code on-the-fly

22 Summing up a calculus for secure service composition: distributed services safety framings scoped policies on localized execution histories req-by-contract service invocation static orchestrator: certifies the behavioural interfaces of services provides a client with the viable plans driving secure executions

23 What s next calculus: syntax and operational semantics static semantics: type & effect system types carry annotations H about service behaviour effects H are history expressions, which overapproximate the actual execution histories extracting viable plans: linearization: unscrambling the structure of H model checking: valid plans are viable

24 Services Services e ::= x α if b then e else e λ z x.e e e ϕ[e] req r τ (only in configs) wait l variable access event conditional abstraction application safety framing service request wait reply

25 Networks location service code and published interface N ::= l{e:τ}: η, e N N published service composition running code execution history

26 (Simple) Plans A plan is a function from requests r to services l π ::= 0 r[l] π π empty service choice composition Plans respect the partial knowledge l < l of services about the network (< is a partial ordering)

27 Example: delegating code execution l 1 l 3 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 l 4 α c ;(λx.α r ; ;α w ) req r2 (f) f()

28 Example: delegating code execution l 1 use in certified sites α c only l 3 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 α c ;(λx.α r ; ;α w ) req r2 (f) do not write α w after a read α r l 4 f()

29 Executing a network of services l 0 l 1 l 3 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 l 4 α c ; (λx.α r ; ;α w ) req r2 (f) f() π = r 1 [l 2 ] r 2 [l 3 ]

30 Executing a network of services l 0 l 1 l 3 λx.ϕ[α r ; ] f = wait l 1 α c ; ϕ [f()] l 2 ε l 4 α c ; (λx.α r ; ;α w ) req r2 (f) f() π = r 1 [l 2 ] r 2 [l 3 ]

31 Executing a network of services l 0 l 1 l 3 λx.ϕ[α r ; ] f = wait l 1 α c ; ϕ [f()] l 2 α c l 4 λx.α r ; ;α w req r2 (f) f() π = r 1 [l 2 ] r 2 [l 3 ]

32 Executing a network of services l 1 l 0 l 3 ε λx.ϕ[α r ; ] f = λx.α r ; ;α w α c ; ϕ [f()] l 2 l 4 α c ; (λx.α r ; ;α w ) wait l 3 f() π = r 1 [l 2 ] r 2 [l 3 ]

33 Executing a network of services l 0 l 1 l 3 α c λx.ϕ[α r ; ] ϕ [αr; ; αw] l 2 l 4 α c ; (λx.α r ; ;α w ) wait l 3 f() π = r 1 [l 2 ] r 2 [l 3 ]

34 Executing a network of services l 0 l 1 l 3 α c α r λx.ϕ[α r ; ] ϕ [α w ] l 2 l 4 α c ; (λx.α r ; ;α w ) wait l 3 f() π = r 1 [l 2 ] r 2 [l 3 ]

35 Executing a network of services l 1 l 0 l 3 α c α r α w ϕ λx.ϕ[α r ; ] ϕ [α w ] l 2 l 4 α c ; (λx.α r ; ;α w ) wait l 3 f() π = r 1 [l 2 ] r 2 [l 3 ] not viable!

36 Semantics of services (1) [App1] η,e 1 η,e 1 η, e 1 e 2 η, e 1 e 2 [App2] η,e 2 η,e 2 η, v e 2 η, v e 2 [AbsApp] η, (λ z x.e) v η, e{v/x, λ z x.e/z} [If] η, if b then e true else e false η, e B (b)

37 Semantics of services (2) [Event] η, α ηα, () [Framing Out] [Framing In] η,e η,e η = ϕ η, ϕ[e] η, ϕ[e ] η = ϕ η, ϕ[v] η, v

38 Semantics of networks (1) [Inject] η, e η, e {e:τ} omitted l: η, e π l: η, e N 1 π N 1 [Par] N 1 N 2 π N 1 N 2

39 Semantics of networks (2) [Request] π = r[l ] π -- plan l: η, req r v l {e }: ε, π l: η, wait l l {e }: ε, e v [Reply] l: η, wait l l {e }: η, v π l: η, v l {e }: ε,

40 Other kinds of plans Simple plans π ::= 0 π π r[l] l: req r l : {P} r[l ] l: wait l l : P Multi-choice plans π ::= 0 π π r[l 1 l k ] l: req r l : {P} r[l,l ] l: wait l l : P Dependent plans π ::= 0 π π r[l. π] l: r[l.π] req r l : {P} l: r[l.π] wait l l : π P many others: multi+dependent, regular, dynamic,

41 Static semantics Type & effect system types carry annotations H about service abstract behaviour effects H, namely history expressions, over-approximate the actual execution histories the type & effect inferred for a service depends on its partial knowledge < of the network

42 Types (pretty standard) τ ::= int bool 1 τ τ H

43 Effects (history expressions) H ::= ε α H H H + H h µh.h ϕ[h] l: H {π 1 H 1 π k H k } empty access event sequence choice variable recursion safety framing localization planned selection

44 Semantics of history expressions [[ α ]] π = (?: α) [[ l: H ]] π = [[ H ]] π {l /?} [[{π 1 H 1 π k H k } ]] π = U i=1..k [[ {π i H i } ]] π [[ {π H} ]] π = [[ H ]] π if π π plan π resolves the requests as π 0 π r[l] r[l] π π 0 π 1 π if π 0 π & π 1 π

45 Semantics of history expressions [[ H H ]] π = [[ H ]] π [[ H ]] π [[ H + H ]] π = [[ H ]] π + [[ H ]] π [[ µh.h]] π = U n>0 f n( ) where f(x) = [[ H ]] π { X / h}

46 Example H = {r[l] {r [l 1 ] α 1, r [l 2 ] α 2 }, r[l ] β} π = r[l] r [l 2 ] [[ H ]] π = [[ {r[l] {r [l 1 ] α 1, r [l 2 ] α 2 }} ]] π U [[ {r[l ] β} ]] π = [[ {r [l 1 ] α 1, r [l 2 ] α 2 } ]] π = [[ {r [l 1 ] α 1 } ]] π U [[ {r [l 2 ] α 2 } ]] π = [[ α 2 ]] π = (?: α 2 )

47 Example H = l: {r[l 1 ] l 1 :α 1, r[l 2 ] l 2 :α 2 } β π = r[l 1 ] [[ H ]] π = [[{r[l 1 ] l 1 :α 1, r[l 2 ] l 2 :α 2 } β ]] π {l/?} = [[{r[l 1 ] l 1 :α 1, r[l 2 ] l 2 :α 2 }]] π (l: β) = [[ l 1 :α 1 ]] π (l: β) = (?: α 1 ) {l 1 /?} (l: β) = (l: β, l 1 : α 1 )

48 Typing rules (1) [T-Ev] Γ, α - l α : 1 [T-Var] Γ, ε - l x : Γ(x) [T-Loc] Γ, H - l e: τ Γ, l: H - e: τ [T-Wk] Γ, H - l e: τ Γ, H+H - l e: τ

49 Typing rules (2) [T-If] [T-Fr] Γ, H - l e: τ Γ, ϕ[h] - l ϕ[e] : τ Γ, H - l e: τ Γ, H - l e : τ Γ, H - l if b then e else e : τ

50 Typing rules (3) [T-Abs] Γ; x:τ;z: τ τ, H - l e : τ [T-App] H Γ, ε - l λ z x.e : H Γ, H - l e: τ τ Γ, H H H τ τ H τ - l e e : τ Γ, H - l e : τ

51 Typing Example (1) α - l α:1 z:1 H? - l (λy.zx)β:1 1,α+? - l if b then α else (λy.zx)β:1

52 Typing Example (2) H ε - l (λy.zx):1 1 β - l β:1 α - l α:1 ε β H - l (λy.zx)β:1 z:1 H 1,α+β H - l if b then α else (λy.zx)β:1

53 Typing Example (3) x:1;z:1 H 1, H - l zx:1 H ε - l (λy.zx):1 1 β - l β:1 α - l α:1 z:1 H β H - l (λy.zx)β:1 1,α+ β H - l if b then α else (λy.zx)β:1

54 Typing Example (4) z:1 H H 1, ε - l z:1 1 x:1;z:1 H x:1, ε - l x:1 1, ε ε H - l zx:1 H ε - l (λy.zx):1 1 β - l β:1 α - l α:1 z:1 H β H - l (λy.zx)β:1 1,α+ β H - l if b then α else (λy.zx)β:1

55 Typing Example z:1 H 1,α+ β H - l if b then α else (λy.zx)β:1 ε - l λ z x.if b then α else (λy.zx)β: τ H τ [T-Abs] To use rule the latent and actual effects must be unified, i.e. H = α+ β H A history expression that satisfies the above is: H = µh. α + β h

56 Typing rules (3) [T-Req] τ = U { ρ + r[l] τ A & B & C } A, ε - l e: τ C l <l {e: τ } Γ, ε - l req r ρ : τ B ρ τ

57 Typing rules (3) [T-Req] certified interface τ = U { ρ + r[l] τ A & B & C } A, ε - l e: τ C l <l {e: τ } Γ, ε - l req r ρ : τ B ρ τ

58 Typing rules (3) [T-Req] compatible types τ = U { ρ + r[l] τ A & B & C } A, ε - l e: τ C l <l {e: τ } Γ, ε - l req r ρ : τ B ρ τ

59 Typing rules (3) [T-Req] τ = U { ρ + r[l] τ A & B & C } A, ε - l e: τ C l <l {e: τ } Γ, ε - l req r ρ : τ B ρ τ visibility

60 Certified published interfaces l 1 ϕ[α r ] 1 (1 1) l 3 h (1 1) α c ϕ [h] 1 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 α c α r α w 1 (1 1) l 4 h (1 1) h 1 α c ; λx.α r ; ;α w req r2 (f) f()

61 Abstracting client behaviour l 1 ε ϕ[α r ] 1 (1 1) l 3 h (1 1) α c ϕ [h] 1 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 α c α r α w 1 (1 1) l 4 h (1 1) h 1 α c ; λx.α r ; ;α w req r2 (f) f() { r 1 [l 1 ] l 1 : ε, r 1 [l 2 ] l 2 : α c ] }

62 Abstracting client behaviour l 1 ε ϕ[α r ] 1 (1 1) l 3 h (1 1) α c ϕ [h] 1 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 α c α r α w 1 (1 1) l 4 h (1 1) h 1 α c ; λx.α r ; ;α w req r2 (f) f() { r 2 [l 3 ] l 3 : α c ϕ [{ r 1 [l 1 ] ϕ[α r ], r 1 [l 2 ] α r α w }], r 2 [l 4 ] l 4 : { r 1 [l 1 ] ϕ[α r ], r 1 [l 2 ] α r α w }}

63 Summing up Calculus: operational semantics and type & effect system effects are history expressions, and overapproximate the actual execution histories planned selections therein hinder information about which plans to choose for secure compositions

64 What s next: the road to viable plans linearization: extracting plans and their pure effects by unscrambling the structure of history expressions validity: defining when an effect denotes histories that never go wrong model checking: valid plans are viable transform history expression into BPAs transform policies into FSAs orchestrator: uses viable plans to drive safe service composition

65 Which are the viable plans? { r 1 [l 1 ] l 1 : ε, r 1 [l 2 ] l 2 : α c ] } { r 2 [l 3 ] l 3 : α c ϕ [{ r 1 [l 1 ] ϕ[α r ], r 1 [l 2 ] α r α w }], r 2 [l 4 ] l 4 : { r 1 [l 1 ] ϕ[α r ], r 1 [l 2 ] α r α w }} Difficult to tell: the planned selections are nested! { r 1 [l 1 ] r 2 [l 3 ] l 1 : ε,l 3 : α c ϕ [ϕ[α r ]], { r 1 [l 2 ] r 2 [l 4 ] l 2 : α c, l 4 : α r α w, { r 1 [l 1 ] r 2 [l 4 ] l 1 : ε,l 4 : ϕ[α r ], { r 1 [l 2 ] r 2 [l 3 ] l 2 : α c, l 3 : α c ϕ [α r α w ]} viable viable not viable not viable

66 Linearization transform H into a semantically equivalent H Hsuch that H is in linear form, i.e.: H = {π 1 H 1 π k H k } and the H i have no planned selections. defined through oriented equations that groups r[l] in topmost position

67 Linearization H {0 H} {π i H i } i {π j H j } {π j i π j H i H j } i,j {π i H i } i + {π j H j } j {π i π j H i + H j } i,j ϕ[ {π i H i } i ] {π i ϕ[h i ] } i µh.{π i H i } i {π i µh. H i } i {π i {π i,j H i,j } j } i {π i π i,j H i,j } i,j

68 Example H ϕ[ λ z x. req r ρ; z x ] l 1 l 2 α β H = ϕ[ µh. { r[l 1 ] α, r[l 2 ] β} h ]

69 Example H = ϕ[ µh. { r[l 1 ] α, r[l 2 ] β} h ] ϕ[ µh. { r[l 1 ] α, r[l 2 ] β} {0 h} ] ϕ[ µh. { r[l 1 ] 0 α h, r[l 2 ] 0 β h} ] = ϕ[ µh. { r[l 1 ] α h, r[l 2 ] β h}] ϕ[ { r[l 1 ] µh. α h, r[l 2 ] µh. β h } ] { r[l 1 ] ϕ[ µh. α h], r[l 2 ] ϕ[ µh. β h] }

70 Simple vs multi-choice plans With simple plans: H { r[l 1 ] ϕ[ µh. α h], r[l 2 ] ϕ[ µh. β h] } With multi-choice plans: H { r[l 1 ] ϕ[ µh. α h], r[l 2 ] ϕ[ µh. β h], r[l 1,l 2 ] ϕ[ µh. (α+ β) h]} Plan r[l 1,l 2 ] useful when l 1 or l 2 unavailable

71 Example: bottleneck service l 0 H ϕ= never αα nor ββ l 2 ϕ[req r ; req r ] l 1 reqr1 l 3 α β H = ϕ[ { r[l 1 ] { r 1 [l 2 ] α, r 1 [l 3 ] β} } { r [l 1 ] { r 1 [l 2 ] α, r 1 [l 3 ] β}}]

72 Simple vs dependent plans With simple plans: H { r[l 1 ] r 1 [l 2 ] r [l 1 ] ϕ[α α], r[l 1 ] r 1 [l 3 ] r [l 1 ] ϕ[β β] } With dependent plans: H { r[l 1. r 1 [l 2 ]] r [l 1. r 1 [l 2 ]] ϕ[α α], r[l 1. r 1 [l 2 ]] r [l 1. r 1 [l 3 ]] ϕ[α β], r[l 1. r 1 [l 3 ]] r [l 1. r 1 [l 2 ]] ϕ[β α], r[l 1. r 1 [l 3 ]] r [l 1. r 1 [l 3 ]] ϕ[β β] } not viable not viable not viable viable viable not viable

73 Validity histories are enriched with [ ϕ and ] ϕ to point out the scope of policies. a history is valid when all the policies are respected, within their scopes ex: α w α r [ ϕ α w ] ϕ not valid (write after read) ex: α w [ ϕ α r ] ϕ α w valid (write outside scope of ϕ) a history expression H is π-valid when all the histories in [[ H ]] π are valid.

74 Validity, formally Safe sets: S(ε) = 0 S(η α) = S(η) S(η 0 [ ϕ η 1 ] ϕ ) = S(η 0 η 1 ) U ϕ[ flat(η 0 ) flat pref(η 1 ) ] Example: S([ ϕ α [ Ψ β ] Ψ γ ] ) = S(α [ ϕ Ψ β ] Ψ γ ) U ϕ[{ε, α, αβ,αβγ }] = Ψ[{α, αβ}], ϕ[{ε, α, αβ,αβγ }] η is valid if, for each ϕ[{η 1,,η k }] in S(η): η i = ϕ for 1 i k

75 Verifying validity Model checking: valid plans are viable (drive executions that never go wrong) transform linearized history expression into BPAs (Basic Process Algebras) transform policies into scoped policies (in the form of Finite State Automata)

76 From history expressions to BPAs Example H = β (µh. α + h h + ϕ[h]) BPA(H) = β X, { X = α + X X + [ ϕ X ] ϕ } Theorem: [[ H ]] = [[ BPA(H) ]]

77 From policies to scoped policies Example α w α r * A ϕ α r α w q0 q1 q2 Chinese Wall policy: no write after read

78 From policies to scoped policies Example α w α r α r, α w A ϕ[ ] α r α w q0 q1 q2 ] ϕ ] ϕ [ ϕ [ ϕ q2 α r q3 α w α r

79 From policies to scoped policies Theorem: η valid iff η accepted by A ϕ[ ] for all ϕ occurring in η η w/o redundant framings ϕ[...ϕ[ ]...] =ϕ[......]

80 Model- checking BPAs with FSAs Theorem: H valid iff [[ BPA(H) ]] = A ϕ[ ] ϕ in H

81 Main result Network N = l 1 { e 1 : τ 1 } l k { e k : τ k } 0, H i - e i : τ i for 1 i k / If H i is π-valid then π is viable for e i

82 Summing up hypothesis: client with history expression H linearization: transform H into a semantically equivalent H in linear form, i.e.: H = {π 1 H 1 π k H k } and the H i have no planned selections. verification: model-check the H i for validity theorem: if H i is valid, then π i is viable

83 Conclusions A linguistic framework for secure service composition safety framings, policies, req-by-contract type & effect system verification of effects, to extract viable plans The orchestrator securely composes and runs service-based applications

84 Other issues considered instrumentation: how to compile local policies into local checks, in case that some policy may fail resource creation: how to create fresh resources liveness: how to deal with properties of the form something good will eventually happen multi-choice and dependent plans

85 Future work other kinds of plans (e.g. dynamic) other kinds of effects (e.g. sessions) safety framings and security protocols safety framings for information flow incremental analysis, when new services can be discovered at run-time trust relations between services spatial types and logics

86 References M. Bartoletti, P. Degano, G.L. Ferrari. Types and Effects for Secure Service Orchestration. CSFW 06. M. Bartoletti, P. Degano, G.L. Ferrari. Plans for service composition. WITS 06. M. Bartoletti, P. Degano, G.L. Ferrari. Enforcing Secure Service Composition. CSFW 05. M. Bartoletti, P. Degano, G.L. Ferrari. Checking risky events is enough for local policies. ICTCS 05.