Information Flow Security for Asynchronous, Distributed ... · Information Flow Security for Asynchronous, Distributed, and Mobile Applications Felipe LUNA DEL AGUILA OASIS Project

Information Flow Security for Asynchronous,Distributed, and Mobile Applications

Felipe LUNA DEL AGUILA

OASIS ProjectINRIA Sophia Antipolis

CNRS - I3S - Universite Nice–Sophia Antipolis

Agenda

• Introduction

PhD Defense - jump to start 1

Agenda

• Introduction

• Context (informal and formal perspectives)


Agenda

• Introduction


– ProActive


Agenda

• Introduction


– ProActive– ASP calculus and communication reduction rules


Agenda

• Introduction



• Objectives


Agenda

• Introduction



• Objectives

• Related Security Mechanisms


Agenda

• Introduction



• Objectives


• The ASP Security Model


Agenda

• Introduction



• Objectives



• Implementation of the Security Model


Agenda

• Introduction



• Objectives



• Implementation of the Security Model

• Conclusion


Introduction

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• ASP SecurityModel

• Implementation

• Conclusions

Recent paradigms


Introduction

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Recent paradigms

SystemsDistributed


Introduction

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Recent paradigms

SystemsDistributed

ProgrammingObject-oriented


Introduction

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Recent paradigms

SystemsDistributed


Service-orientedComputing


Introduction

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Recent paradigms

SystemsDistributed



Security


Introduction

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Recent paradigms

SystemsDistributed



Security

Security focused specifically on Information Flow


Context

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

ProActive main characteristics

• Middleware library for distributed applications


Context

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• 100% Java


Context

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• 100% Java

• Existence of passive and active objects


Context

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• 100% Java


• Asynchronous communications between active objects


Context

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• 100% Java



– Principle of wait-by-necessity and futures:1. future reference


Context

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• 100% Java




(ex.: http://www.anysite.com/anypage.html)


Context

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• 100% Java





2. future value


Context

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• 100% Java





2. future value

(ex.: HTML error: 404 Not Authorized)


ASP semantics and ProActive

• The ASP language entities:

– activity α

α




– activity α, active object a

αActive object




– activity α, active object a, passive objects

αActive object




– activity α, active object a, passive objects, activity β

αActive object

β




– activity α, active object a, passive objects, activity β, active object reference AO(α)

αActive object

β




– activity α, active object a, passive objects, activity β, active object reference AO(α), future

fα→βi and request queue (with pending, current, and completed requests)

αActive object

β

references tofuture values

currentrequest

pendingrequests

Futurevalue





fα→βi and request queue (with pending, current, and completed requests), future references

fut(fα→βi )

αActive object

β


currentrequest

pendingrequests

Futurevalue

f2

current term

Requestparameter

foo

f

f3






fut(fα→βi ), and store σ

αActive object

β


currentrequest

pendingrequests

Futurevalue

f2

current term

Requestparameter

foo

f

f3

σβ






fut(fα→βi ), and store σ

αActive object

β


currentrequest

pendingrequests

Futurevalue

f2

current term

Requestparameter

foo

f

f3

σβ

• Parallel configurations are then of the form: P,Q ::= α [a; σ; ι; F ; R; f ] ‖ β [· · · ] ‖ · · ·


ASP parallel reduction rules



(a, σ) →S (a′, σ′) →S does not clone a future

α[a; σ; ι; F ; R; f ] ‖ P −→ α[a′; σ′; ι; F ; R; f ] ‖ P(local)

γ fresh activity ι′ 6∈ dom(σ) σ′ = {ι′ 7→ AO(γ)} :: σ σγ = copy(ι′′, σ)

α[R[Active(ι′′, mj)]; σ; ι; F ; R; f ] ‖ P −→ α[R[ι′]; σ′; ι; F ; R; f ] ‖ γ[ι′′.mj(); σγ; ι′′; ∅; ∅; ∅] ‖ P(newact)

σα(ι) = AO(β) ι′′ 6∈ dom(σβ) fα→βi new future ιf 6∈ dom(σα)

σ′β = Copy&Merge(σα, ι′ ; σβ, ι′′) σ′α = {ιf 7→ fut(fα→βi )} :: σα

α[R[ι.mj(ι′)]; σα; ια; Fα; Rα; fα] ‖ β[aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P −→

α[R[ιf ]; σ′α; ια; Fα; Rα; fα] ‖ β[aβ; σ′β; ιβ; Fβ; Rβ :: [mj; ι′′; fα→βi ]; fβ] ‖ P

(request)

R = R′ :: [mj; ιr; f ′] :: R′′ mj ∈ M ∀m ∈ M, m /∈ R′

α[R[Serve(M)]; σ; ι; F ; R; f ] ‖ P −→ α[ι.mj(ιr) ⇑ f,R[[]]; σ; ι; F ; R′ :: R′′; f ′] ‖ P(serve)

ι′ 6∈ dom(σ) F ′ = F :: {f 7→ ι′} σ′ = Copy&Merge(σ, ι ; σ, ι′)

α[ι ⇑ f ′, a; σ; ι; F ; R; f ] ‖ P −→ α[a; σ′; ι; F ′; R; f ′] ‖ P(endservice)

σα(ι) = fut(fγ→βi ) Fβ(f

γ→βi ) = ιf σ′α = Copy&Merge(σβ, ιf ; σα, ι)

α[aα; σα; ια; Fα; Rα; fα] ‖ β[aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P −→α[aα; σ′α; ια; Fα; Rα; fα] ‖ β[aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P

(reply)



(a, σ) →S (a′, σ′) →S does not clone a future

α[a; σ; ι; F ; R; f ] ‖ P −→ α[a′; σ′; ι; F ; R; f ] ‖ P(local)

γ fresh activity ι′ 6∈ dom(σ) σ′ = {ι′ 7→ AO(γ)} :: σ σγ = copy(ι′′, σ)

α[R[Active(ι′′, mj)]; σ; ι; F ; R; f ] ‖ P −→ α[R[ι′]; σ′; ι; F ; R; f ] ‖ γ[ι′′.mj(); σγ; ι′′; ∅; ∅; ∅] ‖ P(newact)

σα(ι) = AO(β) ι′′ 6∈ dom(σβ) fα→βi new future ιf 6∈ dom(σα)

σ′β = Copy&Merge(σα, ι′ ; σβ, ι′′) σ′α = {ιf 7→ fut(fα→βi )} :: σα


α[R[ιf ]; σ′α; ια; Fα; Rα; fα] ‖ β[aβ; σ′β; ιβ; Fβ; Rβ :: [mj; ι′′; fα→βi ]; fβ] ‖ P

(request)

R = R′ :: [mj; ιr; f ′] :: R′′ mj ∈ M ∀m ∈ M, m /∈ R′

α[R[Serve(M)]; σ; ι; F ; R; f ] ‖ P −→ α[ι.mj(ιr) ⇑ f,R[[]]; σ; ι; F ; R′ :: R′′; f ′] ‖ P(serve)

ι′ 6∈ dom(σ) F ′ = F :: {f 7→ ι′} σ′ = Copy&Merge(σ, ι ; σ, ι′)

α[ι ⇑ f ′, a; σ; ι; F ; R; f ] ‖ P −→ α[a; σ′; ι; F ′; R; f ′] ‖ P(endservice)


γ→βi ) = ιf σ′α = Copy&Merge(σβ, ιf ; σα, ι)

α[aα; σα; ια; Fα; Rα; fα] ‖ β[aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P −→α[aα; σ′α; ια; Fα; Rα; fα] ‖ β[aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P

(reply)


Reduction rules: 1) New Activity

γ fresh activity ι′ 6∈ dom(σ) σ′ = {ι′ 7→ AO(γ)} :: σ

α[R[Active(ι′′, mj)]; σ; ι; F ; R; f ] ‖ P −→α[R[ι′]; σ′; ι; F ; R; f ] ‖ γ[ι′′.mj(); σγ; ι′′; ∅; ∅; ∅] ‖ P

α γσ γσ



γ fresh activity copy(ι′′,σ) = σγ ι′ 6∈ dom(σ) σ′ = {ι′ 7→ AO(γ)} :: σ

α[R[Active(ι′′, mj)]; σ; ι; F ; R; f ] ‖ P −→α[R[ι′]; σ′; ι; F ; R; f ] ‖ γ[ι′′.mj(); σγ; ι′′; ∅; ∅; ∅] ‖ P

α γσ γσ

Object toactivate

i”



γ fresh activity copy(ι′′,σ) = σγ

i”.m ()j

α γσγσ

Active object



γ fresh activity copy(ι′′,σ) = σγ ι′ 6∈ dom(σ) σ′= {ι′ 7→ AO(γ)} :: σ

α[R[Active(ι′′, mj)];σ; ι; F ; R; f ] ‖ P −→α[R[ι′];σ′; ι; F ; R; f ] ‖ γ[ι′′.mj(); σγ; ι′′; ∅; ∅; ∅] ‖ P

i”.m ()j

α γσγσ

Active object

AO( )γ

’

i’


Reduction rules: 2) Request

σα(ι) =AO(β)

fα→βi new future ιf 6∈ dom(σα) {ιf 7→ fut(fα→β

i )} :: σα = σ′α


α[R[ιf ]; σ′α; ια; Fα; Rα; fα] ‖ β[aβ; σ′

β; ιβ; Fβ; Rβ :: [mj; ι′′; fα→βi ]; fβ] ‖ P

σβ

i.m ( i’ )j

βα σα

βAO( )i

Active object



σα(ι) =AO(β) ι′′ 6∈ dom(σβ) Copy&Merge(σα, ι′ ; σβ, ι′′) = σ′β


i )} :: σα = σ′α


α[R[ιf ]; σ′α; ια; Fα; Rα; fα] ‖ β[aβ; σ′

β; ιβ; Fβ; Rβ :: [mj; ι′′; fα→βi ]; fβ] ‖ P

σβ

i.m ( i’ )j

βα σα

βAO( )i

Active object

i’

Requestparameter




i.m ( i’ )j

βα σα

βAO( )i

Active objectβσ ’

Requestparameter

i”




fα→βi new future

i.m ( i’ )j

βα σα

βAO( )i


Requestparameter

i”

f α βi





i )} :: σα = σ′α

i.m ( i’ )j

βα σα

βAO( )i


Requestparameter

i”

f α βi

α β

i f

ifut ( f )

’





i )} :: σα = σ′α

α[R[ι.mj(ι′)];σα; ια; Fα; Rα; fα] ‖ β[aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P −→

α[R[ιf ];σ′α; ια; Fα; Rα; fα] ‖ β[aβ; σ′

β; ιβ; Fβ; Rβ :: [mj;ι′′;fα→β

i ]; fβ] ‖ P

i.m ( i’ )j

βα σα

βAO( )i


Requestparameter

i”

f α βi

α β

i f

ifut ( f )

’


Reduction rules: 3) Reply

σα(ι) =fut(fγ→βi ) Fβ(f

γ→βi ) = ιf = σ′

α

α[aα; σα; ια; Fα; Rα; fα] ‖ β[aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P −→α[aα; σ′

α; ια; Fα; Rα; fα] ‖ β[aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P

βα σα

ifut ( f )

i

βγ

βσ

futurevalue

fi




γ→βi ) = ιf Copy&Merge(σβ, ιf ; σα, ι) = σ′

α



βα σα

ifut ( f )

i

βγ

βσ

futurevalue

fi




γ→βi ) = ιf Copy&Merge(σβ, ιf ; σα, ι) = σ′

α



βα σα βσ

i

’

futurevalue


Objectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Main objective: Information Flow Control


Objectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


1. To guarantee data confidentiality

Confidentiality in MLS: follows the basic principle of no writedown, no read up


Objectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions




2. Define a security policy to apply to asynchronous,distributed, and mobile applications


Objectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions





Main issue: Presence of asymmetric patterns of communications(result of the future and wait-by necessity concepts)


Objectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions






3. Provide a formal security model


Objectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions






3. Provide a formal security model which is verifiable

mathematically


Objectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions






3. Provide a formal security model which is verifiable

mathematically

4. Propose an architecture for the implementation of the

security model


Related Security Mechanisms

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models

– Mandatory Access Controls (MAC)



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models


– Discretionary Access Controls (DAC)



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods

– Non-interference



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods


– π-calculus, Asynchronous-π, and Spi calculus



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods



– Ambients, and Mobile Ambients



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods




– Seals, Boxed Ambients, and Secure Safe Ambients



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods





• Informal approaches



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods






– Exceptions (in the security policy)



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods






– Exceptions (in the security policy), labels



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods






– Exceptions (in the security policy), labels, tickets



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Models



• Formal methods






– Exceptions (in the security policy), labels, tickets,

certificates . . .


The ASP Security Model

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Syntax and semantics of the security framework



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


• S set of activities acting as subjects, where

α, β, γ, ... ∈ S



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



α, β, γ, ... ∈ S

• D set of data objects sent as arguments in REQUEST

actions: Rqα→β(d)



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



α, β, γ, ... ∈ S

• D set of data objects sent as arguments in REQUEST

actions: Rqα→β(d)

• R is the set of objects associated to futures, and

returned in REPLY actions: Rpβ→α(r)


The ASP Security Model (cntd.)Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• L finite set of security levels λ, partially ordered by

the relation ≤, where ∀i ∈ S ∪ D, λi ∈ L



• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



processingdata

ms

mt

(task)

targetsubject

r λβ

αλα βλ

aλα

λα

b

( )dλin

dλin

β

λβ

βλ

tx=b.m



• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



processingdata

ms

mt

(task)

targetsubject

r λβ

αλα βλ

aλα

λα

b

( )dλin

dλin

β

λβ

βλ

tx=b.m

• Transmissions of d and r are restricted by the security

rules


The ASP Security Model (cntd.)

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Actions

• A set of actions, where a ∈ A



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Actions


• ASP actions are now rewritten to include security

properties:



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Actions



properties:

Nw(γ, λγ) is a modified NEWACT



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Actions



properties:


Rqα→β(d, λin) is a modified REQUEST



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Actions



properties:



Rpβ→α(r) is an unchanged REPLY



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Actions



properties:



Rpβ→α(r) is an unchanged REPLY

• In general,

a = {Nw(γ, λγ), Rqα→β(d, λin), Rpβ→α(r)}



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Additional entities

• M matrix of explicit (discretionary) rights



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Additional entities


M = S × S → P(A)



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Additional entities


M = S × S → P(A)P(A) set of actions whose assignation of a security

level is explicitly allowed



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Additional entities




In general, p ∈ P(A) if and only if

p = {Nw(γ, λγ), Rqα→β(d, λin)}



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Additional entities






• T set of authorized (access) transmissions



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Additional entities






• T set of authorized (access) transmissions

T = S × S ×A


Application of the security framework

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

1.- Base statements:

• Creation (and migration) of new activities are secure

• Emission of requests, with modifiable security levels in the datasent, are secure

• Emission of replies are secure



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions





2.- Support concepts:

• Elementary flows of information

• Flow-paths



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions





2.- Support concepts:

• Elementary flows of information

• Flow-paths

3.- Results:

Confidentiality, from end-to-end in a flow-path, is guaranteed


Secure Activity Creation

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, γ ∈ S



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, γ ∈ S: (α, γ, Nw(γ, λγ)) ∈ T ⇐⇒

A new activity action is considered secure iff:



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, γ ∈ S: (α, γ, Nw(γ, λγ)) ∈ T ⇐⇒(λα ≤ λγ)


1. The new activity has a higher security level compared

to its creator



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, γ ∈ S: (α, γ, Nw(γ, λγ)) ∈ T ⇐⇒(λα ≤ λγ) ∨Nw(γ, λγ) ∈M(α, γ)



to its creator

2. or, in case the new activity has a lower security (i.e. a

downgrade), the creation action must be explicitly

allowed



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, γ ∈ S: (α, γ, Nw(γ, λγ)) ∈ T ⇐⇒(λα ≤ λγ) ∨Nw(γ, λγ) ∈M(α, γ)



to its creator

2. or, in case the new activity has a lower security (i.e. a

downgrade), the creation action must be explicitly

allowed

Special case: Migration of an existing activity


Secure Request Transmission

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, β ∈ S



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, β ∈ S: (α, β, Rqα→β(d, λin)) ∈ T ⇐⇒

A request transmission action is considered secure iff:



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, β ∈ S: (α, β, Rqα→β(d, λin)) ∈ T ⇐⇒(λin ≤ λβ)∧


1. Data is ”released” to an authorized target, AND



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, β ∈ S: (α, β, Rqα→β(d, λin)) ∈ T ⇐⇒(λin ≤ λβ)∧(λα ≤ λin)



2. Either:

• The data has a higher level than the sender



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


∨ ((λα > λin) ∧Rqα→β(d, λin) ∈M(α, β))



2. Either:


• If data has a lower level than the sender (i.e. a

downgrade), the action must be explicitly allowed



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


∨ ((λα > λin) ∧Rqα→β(d, λin) ∈M(α, β))∨ ∃γ, δ, fi, d = fut(fγ→δ

i )



2. Either:


• If data has a lower level than the sender (i.e. a

downgrade), the action must be explicitly allowed

• The data is a future reference


Secure Reply Transmission

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, β ∈ S



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, β ∈ S: (α, β, Rpβ→α(r)) ∈ T ⇐⇒

A reply transmission action is considered secure iff:



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, β ∈ S: (α, β, Rpβ→α(r)) ∈ T ⇐⇒(λβ ≤ λα)


1. The data contained in the reply r (hence of level λβ)

can be released to the corresponding receiving subject

(with λα)



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

∀α, β ∈ S: (α, β, Rpβ→α(r)) ∈ T ⇐⇒(λβ ≤ λα) ∨ (∃γ, δ, fi, r = fut(fγ→δ

i ))


1. The data contained in the reply r (hence of level λβ)

can be released to the corresponding receiving subject

(with λα)

2. or, if the data in the reply is only a reference to a

future


Secure ASP reduction rules




σγ = copy(ι′′, σ) (α, γ, Nw(γ, λγ)) ∈ T

αλ[R[Activeλa(ι′′, mj)]; σ; ι; F ; R; f ] ‖ P −→αλ[R[ι′]; σ′; ι; F ; R; f ] ‖ γλa[ι′′.mj(); σγ; ι′′; ∅; ∅; ∅] ‖ P

(SecNEWACT)

σα(ι) = AO(β) ι′′ 6∈ dom(σβ) fα→βi new future

ιf 6∈ dom(σα) σ′β = Copy&Merge(σα, ι′ ; σβ, ι′′)

σ′α = {ιf 7→ fut(fα→βi )} :: σα (α, β, Rqα→β(σα(ι′), λin)) ∈ T

αλα[R[ι.mj(ι′λin)]; σα; ια; Fα; Rα; fα] ‖ β

λβ [aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P −→αλα[R[ιf ]; σ′α; ια; Fα; Rα; fα] ‖ β

λβ [aβ; σ′β; ιβ; Fβ; Rβ :: [mj; ι′′; fα→βi ]; fβ] ‖ P

(SecREQUEST)


γ→βi ) = ιf

σ′α = Copy&Merge(σβ, ιf ; σα, ι) (β, α, Rpβ→α(σβ(ιf))) ∈ T

αλα[aα; σα; ια; Fα; Rα; fα] ‖ βλβ [aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P −→

αλα[aα; σ′α; ια; Fα; Rα; fα] ‖ βλβ [aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P

(SecREPLY)




σγ = copy(ι′′, σ) (α, γ, Nw(γ, λγ)) ∈ T

αλ[R[Activeλa(ι′′, mj)]; σ; ι; F ; R; f ] ‖ P −→αλ[R[ι′]; σ′; ι; F ; R; f ] ‖ γλa[ι′′.mj(); σγ; ι′′; ∅; ∅; ∅] ‖ P

(SecNEWACT)

σα(ι) = AO(β) ι′′ 6∈ dom(σβ) fα→βi new future

ιf 6∈ dom(σα) σ′β = Copy&Merge(σα, ι′ ; σβ, ι′′)

σ′α = {ιf 7→ fut(fα→βi )} :: σα (α, β, Rqα→β(σα(ι′), λin)) ∈ T

αλα[R[ι.mj(ι′λin)]; σα; ια; Fα; Rα; fα] ‖ β

λβ [aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P −→αλα[R[ιf ]; σ′α; ια; Fα; Rα; fα] ‖ β

λβ [aβ; σ′β; ιβ; Fβ; Rβ :: [mj; ι′′; fα→βi ]; fβ] ‖ P

(SecREQUEST)


γ→βi ) = ιf

σ′α = Copy&Merge(σβ, ιf ; σα, ι) (β, α, Rpβ→α(σβ(ιf))) ∈ T

αλα[aα; σα; ια; Fα; Rα; fα] ‖ βλβ [aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P −→

αλα[aα; σ′α; ια; Fα; Rα; fα] ‖ βλβ [aβ; σβ; ιβ; Fβ; Rβ; fβ] ‖ P

(SecREPLY)

Parallel configurations are now of the form:

P, Q ::= αλα[a;σ; ι;F ;R; f ] ‖ βλβ[· · · ] ‖ · · ·


The Secure Information Flow

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• The concept elementary flow of information is based

on the ”release” or transmission of information from

an activity



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



an activity

• Hence, it is derived the secure information flownotion:

(α, β, Rqα→β(σ(ι′), λin)) ∈ T

Secϕ∅(α, β)

(β, α, Rpβ→α(σα(ιf))) ∈ T

Secϕ∅(β, α)

(α, γ, Nw(γ, λγ)) ∈ T

Secϕ∅(α, γ)



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



an activity

• Hence, it is derived the secure information flownotion:

(α, β, Rqα→β(σ(ι′), λin)) ∈ T

Secϕ∅(α, β)

(β, α, Rpβ→α(σα(ιf))) ∈ T

Secϕ∅(β, α)

(α, γ, Nw(γ, λγ)) ∈ T

Secϕ∅(α, γ)

The syntax Secϕ∅(α, β) means there is a secure flow

(Secϕ), with no other intermediate activities (∅),happening between activities α and β


The Secure Path for Information Flow

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• A flow of information is composed of several elementary flowshappening in a sequential order



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


• A flow-path (fp) is produced when intermediate activities arepresent in between the communication of two given activities(i.e. the end points)



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• Formally, the secure path for information flow is:

Secϕfp1(α, γ) Secϕfp2(γ, β)

Secϕfp1.γ.fp2(α, β)



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• Formally, the secure path for information flow is:

Secϕfp1(α, γ) Secϕfp2(γ, β)

Secϕfp1.γ.fp2(α, β)

• There is a secure information flow from end-to-end on any flowpath when:

Secϕγ1···γn(α, β) ⇐⇒Secϕ∅(α, γ1) ∧ Secϕ∅(γ1, γ2) ∧ · · · ∧ Secϕ∅(γn, β)


Service-Oriented Computing and futures

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Impossible future updates with symmetric patterns of

communications

β

Active Object Active Object Active Object

λδ < βλ γλ<

γ

AO( )δ

δ

γAO( )



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


communications

β


λδ < βλ γλ<

γ

AO( )δ

δ

γAO( )

Reqγ



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


communications

β


λδ < βλ γλ<

γ

AO( )δ

δ

γAO( )

Reqγ

f 2



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


communications

β


λδ < βλ γλ<

γ

AO( )δ

δ

γAO( )

Reqγ

f 2

Reqδ



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


communications

β


λδ < βλ γλ<

γ

AO( )δ

δ

γAO( )

Reqγ

f 2

Reqδ

2f’



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


communications

β


λδ < βλ γλ<

γ

AO( )δ

δ

γAO( )

Reqγ

f 2

Reqδ

2f’

λλδ < γ



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


communications

β


λδ < βλ γλ<

γ

AO( )δ

δ

γAO( )

Reqγ

f 2

Reqδ

2f’

λλδ < γ

<βλ γλ


Service-Oriented Computing and futures (contd.)

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Future updates are possible in asymmetric patterns of

communications

β


λδ < βλ γλ<2f’

γ

AO( )δ

δ

γAO( )

Reqγ

f 2

Reqδ



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


communications

β



γ

AO( )δ

δ

γAO( )

Reqγ

f 2

Reqδ

future reference



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


communications

β



γ

AO( )δ

δ

γAO( )

Reqγ

f 2

Reqδ

future reference

λλδ < β


Implementation of the Security Model

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Architecture of active objects

passiveobject

futurevalue

currentrequest

pendingrequests


FutureProxy

BodyProxy

future

local JVM remote JVM

Request queue structure

A

Stub_BBody

B


Implementation of the Security Model (contd.)

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Security schema for active objects

ProActivemiddlewarelayer

Applicationlayer

A

Stub-B

B

Body



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Applicationlayer

A

Stub-B

B

Body

security sublayer EF / DF AF AF EF / DF



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Applicationlayer

A

Stub-B

B

Body


JVM Y

Java API Java APIlayerJava

JVM X



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Applicationlayer

A

Stub-B

B

Body


JVM Y


JVM X

request request



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Applicationlayer

A

Stub-B

B

Body


JVM Y


JVM X

request request

requestauthorized



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Applicationlayer

A

Stub-B

B

Body


JVM Y


JVM X

request request

requestauthorized

reply reply



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Applicationlayer

A

Stub-B

B

Body


JVM Y


JVM X

request request

requestauthorized

reply reply

authorizedreply



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Detailed Security sub-layer



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


flow control SecurityManager

Java API

EF

or migrateTo)reply,request,turnActive,(newActive,

intercepted action

• EF = flow control mechanism as a Java Security Manager



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Java API

EF


intercepted action

setup

DFPDP

ContextHandler

XACMLpolicy

file


• DF = Context Handler + Policy Decision Point + XACML file



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Java API

EF


intercepted action

setup

DFPDP

ContextHandler

XACMLpolicy

fileAF

PIP AOPIP



• AF = Policy Information Point + active object PIP



Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



Java API

EF


intercepted action

setup

DFPDP

ContextHandler

XACMLpolicy

fileAF

PIP AOPIP



• AF = Policy Information Point + active object PIP


Conclusions

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


Conclusions

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Expresiveness:

– Assignation of specific security levels to request

parameters and created activities


Conclusions

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Expresiveness:



• Scalability:

– Dynamic checks performed only at activity creation,

and inter-activity communications


Conclusions

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• Expresiveness:



• Scalability:

– Dynamic checks performed only at activity creation,

and inter-activity communications

• Extendable:

– XACML features provide a finer control on the

discretionary access control


Perspectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions


Perspectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

• TCSEC/ITSEC/CC level A/EAL7 can be attained (i.e.

formal design and verification)


Perspectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions



• Further study of covert channels in distributed systems


Perspectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions




• Static type checking in Java can be complemented

with our model


Perspectives

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions




• Static type checking in Java can be complemented

with our model

• The security mechanism can be applied to the

Components paradigm


Q&A

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Questions ?

Thank you for your attention


Q&A

Agenda

• Introduction

• Context

• Objectives

• Mechanisms


• Implementation

• Conclusions

Questions ?

Thank you for your attention


Documents

Information Flow Security for Asynchronous, Distributed ... · Information Flow Security for Asynchronous, Distributed, and Mobile Applications Felipe LUNA DEL AGUILA OASIS Project