Information Flow Security for Asynchronous, Distributed ... · Information Flow Security for...

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

current term

Requestparameter

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

αActive object

currentrequest

pendingrequests

Futurevalue

current term

Requestparameter

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

αActive object

currentrequest

pendingrequests

Futurevalue

current term

Requestparameter

• 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

γ 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( )γ

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

Requestparameter

i.m ( i’ )j

βα σα

βAO( )i

Active objectβσ ’

Requestparameter

fα→βi new future

i.m ( i’ )j

βα σα

βAO( )i

Requestparameter

f α βi

i )} :: σα = σ′α

i.m ( i’ )j

βα σα

βAO( )i

Requestparameter

f α βi

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

f α βi

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 )

futurevalue

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

βα σα

ifut ( f )

futurevalue

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

βα σα βσ

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

(task)

targetsubject

r λβ

αλα βλ

( )dλin

tx=b.m

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

processingdata

(task)

targetsubject

r λβ

αλα βλ

( )dλin

tx=b.m

• Transmissions of d and r are restricted by the security

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γ→δ

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γ→δ

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( )

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

communications

λδ < βλ γλ<

AO( )δ

γAO( )

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

communications

λδ < βλ γλ<

AO( )δ

γAO( )

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

communications

λδ < βλ γλ<

AO( )δ

γAO( )

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

communications

λδ < βλ γλ<

AO( )δ

γAO( )

λλδ < γ

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

communications

λδ < βλ γλ<

AO( )δ

γAO( )

λλδ < γ

<βλ γλ

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( )

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

communications

AO( )δ

γAO( )

future reference

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

communications

AO( )δ

γAO( )

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

Stub_BBody

Implementation of the Security Model (contd.)

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Security schema for active objects

ProActivemiddlewarelayer

Applicationlayer

Stub-B

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Applicationlayer

Stub-B

security sublayer EF / DF AF AF EF / DF

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Applicationlayer

Stub-B

Java API Java APIlayerJava

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Applicationlayer

Stub-B

request request

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Applicationlayer

Stub-B

request request

requestauthorized

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Applicationlayer

Stub-B

request request

requestauthorized

reply reply

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Applicationlayer

Stub-B

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

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

intercepted action

ContextHandler

XACMLpolicy

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

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Java API

intercepted action

ContextHandler

XACMLpolicy

fileAF

PIP AOPIP

• AF = Policy Information Point + active object PIP

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Java API

intercepted action

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

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Questions ?

Thank you for your attention

Agenda

• Introduction

• Context

• Objectives

• Mechanisms

• Implementation

• Conclusions

Questions ?

Thank you for your attention

Information Flow Security for Asynchronous, Distributed ... · Information Flow Security for...

Documents

Multi-Objective Optimization Using Asynchronous Distributed Applications

Efficient Agreement Protocols for Asynchronous Distributed

A Fair Synthesis for Asynchronous Distributed … Fair Synthesis for Asynchronous Distributed Systems PAUL GASTIN, LSV, ENS Cachan, INRIA, CNRS NATHALIE SZNAJDER, LIP6/MoVe, Universite´

Returning data-flow to asynchronous programmingllvm.org/devmtg/2018-04/slides/Gilbert-Returning... · Returning data-flow to asynchronous programming Matt Gilbert, Senior Staff Engineer,

02 A fully asynchronous multifrontal solver using distributed dynamic scheduling.pdf

Implementing Asynchronous Distributed Systems Using the ...publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-966.pdfImplementing Asynchronous Distributed Systems Using the IOA Toolkit

Distributed Asynchronous Computation of Fixed …dimitrib/Asynchronous_Plen_Talk.pdfDistributed Asynchronous Computation of Fixed Points and Applications in Dynamic Programming Dimitri

Distributed Asynchronous Bellman-Ford Algorithm

1 Distributed Asynchronous Constrained Stochastic …angelia/tsp_final_single.pdfproblem of cooperative solution to distributed optimization problems [6]–[11]. The algorithms for

Simulator of an Asynchronous Distributed System

DAC: Distributed Asynchronous Cooperation for Wireless Relay Networks

Asynchronous Optimistic Rollback Recovery Using Secure …people.ischool.berkeley.edu/~tygar/papers/Completely... · 2005. 8. 30. · Abstract In an asynchronous distributed computation,

GASGD: Stochastic Gradient Descent for Distributed Asynchronous Matrix Completion via Graph Partitioning

DISTRIBUTED POWER FLOW CONTROLER (DPFC)

Software Exception Flow Analysis for WPF C# Asynchronous ...hosteddocs.ittoolbox.com/boriseligulashviliasyncpaperupdate.pdf · for WPF C# Asynchronous Programs Using Microsoft Visual

Randomized Protocols for Asynchronous Consensus James Aspnes Distributed Computing (2003) 16: 165 - 175

Distributed Asynchronous Online Learning for Natural ...ttic.uchicago.edu/~kgimpel/talks/gimpel+das+smith.conll...Asynchronous, no delay Asynchronous, µ = 5 Single-processor, no delay

Distributed Algorithms 6.046J, Spring, 2015 Part 2 · • Round 2: – If you joined the MIS, ... 505 leaf leaf Asynchronous Distributed ... Distributed Algorithms, Chapter 8

Convergence of Distributed Asynchronous Learning Vector ... · CONVERGENCE OF DISTRIBUTED ASYNCHRONOUS LEARNING VECTOR QUANTIZATION ALGORITHMS most satisfactory almost sure convergence

ASGriDS: Asynchronous Smart-Grids Distributed Simulator