Information flow techniques typically classify information according to suitable security levels and enforce policies that are based on binary relations between individual levels, e.g., stating that information is allowed to flow from one level to another. We argue that some information flow properties of interest naturally require coordination patterns that involve sets of security levels rather than individual levels: some secret information could be safely disclosed to a set of confidential channels of incomparable security levels, with individual leaks considered instead illegal; a group of competing agencies might agree to disclose their secrets, with individual disclosures being undesired, etc. Motivated by this we propose a simple language for expressing information flow policies where the usual admitted flow relation between individual security lev- els is replaced by a relation between sets of security levels, thus allowing to capture coordinated flows of information. The flow of information is expressed in terms of causal dependencies and the satisfaction of a policy is defined with respect to an event structure that is assumed to capture the causal structure of system computations. We suggest applications to secret exchange protocols, program security and security architectures, and discuss the relation to classic notions of information flow control.

1. Many-to-Many Information Flow Policies
Paolo Baldan
Università di Padova
Alessandro Beggiato
IMT Lucca
Alberto Lluch Lafuente
DTU
albl@dtu.dk
DisCoTec/COORDINATION 2017, Neuchâtel, 19-22 June 2017

2. Introduction

3. SECRET
PUBLIC
SECRET
PUBLIC
DECLASSIFIER
MANAGEMENT
PUBLIC
FINANCIALMEDICAL
Information flow policies regulate how information flows between
several security domains. Such policies may be diagrams like:

4. SECRET
PUBLIC
SECRET
PUBLIC
DECLASSIFIER
MANAGEMENT
PUBLIC
FINANCIALMEDICAL
Sometimes one-to-one relations are not enough…
Information flow policies regulate how information flows between
several security domains. Such policies may be diagrams like:
NETWORK
ENGINE
INFOTAINMENT
CONTROL
ENGINE
CONTROL
SCREENS

5. SECRET
PUBLIC
SECRET
PUBLIC
DECLASSIFIER
MANAGEMENT
PUBLIC
FINANCIALMEDICAL
Sometimes one-to-one relations are not enough…
Information flow policies regulate how information flows between
several security domains. Such policies may be diagrams like:
For example, to admit only…
• Paths ENGINE CONTROL→NET→ENGINE
NETWORK
ENGINE
INFOTAINMENT
CONTROL
ENGINE
CONTROL
SCREENS

6. SECRET
PUBLIC
SECRET
PUBLIC
DECLASSIFIER
MANAGEMENT
PUBLIC
FINANCIALMEDICAL
Sometimes one-to-one relations are not enough…
Information flow policies regulate how information flows between
several security domains. Such policies may be diagrams like:
For example, to admit only…
• Paths ENGINE CONTROL→NET→ENGINE
• Flows {SECRET,DECLASSIF.} → PUBLIC
NETWORK
ENGINE
INFOTAINMENT
CONTROL
ENGINE
CONTROL
SCREENS

7. SECRET
PUBLIC
SECRET
PUBLIC
DECLASSIFIER
MANAGEMENT
PUBLIC
FINANCIALMEDICAL
Sometimes one-to-one relations are not enough…
Information flow policies regulate how information flows between
several security domains. Such policies may be diagrams like:
For example, to admit only…
• Paths ENGINE CONTROL→NET→ENGINE
• Flows {SECRET,DECLASSIF.} → PUBLIC
• Flows from {SECRET} → {PUB1,PUB2}NETWORK
ENGINE
INFOTAINMENT
CONTROL
ENGINE
CONTROL
SCREENS

8. SECRET
PUBLIC
SECRET
PUBLIC
DECLASSIFIER
MANAGEMENT
PUBLIC
FINANCIALMEDICAL
Sometimes one-to-one relations are not enough…
For example, to admit only…
• Paths ENGINE CONTROL→NET→ENGINE
• Flows {SECRET,DECLASSIF.} → PUBLIC
• Flows from {SECRET} → {PUB1,PUB2}
What does this mean at all?
How to regulate such flows?
How to keep a visual/intuitive notation?
Information flow policies regulate how information flows between
several security domains. Such policies may be diagrams like:
NETWORK
ENGINE
INFOTAINMENT
CONTROL
ENGINE
CONTROL
SCREENS

9. Plan for today:
• Information flow and causality
• Why collective/simultaneous flows?
• Semantics of policies, by examples
• Some results
• Conclusion

10. Information flow
and causality

11. Alice Bob
Information flow and causal dependencies
send(x);
u := 0;
if g(y) then
z := f(y);
recv(?y);
INTUITION: “if b depends on a then there is some flow from a to b”
...
...

12. Alice Bob
send(x);
u := 0;
if g(y) then
z := f(y);
recv(?y);
INTUITION: “if b depends on a then there is some flow from a to b”
communication flow
...
...
Information flow and causal dependencies

13. Alice Bob
send(x);
u := 0;
if g(y) then
z := f(y);
recv(?y);
INTUITION: “if b depends on a then there is some flow from a to b”
communication flow
explicit data flow...
...
Information flow and causal dependencies

14. Alice Bob
send(x);
u := 0;
if g(y) then
z := f(y);
recv(?y);
INTUITION: “if b depends on a then there is some flow from a to b”
communication flow
explicit data flow
implicit data flow
...
...
Information flow and causal dependencies

15. Our models are labelled event structures, which consist of:

16. H L
Our models are labelled event structures, which consist of:
a set of security labels

17. disclose
read
L
request_secret
listen
ignore
Our models are labelled event structures, which consist of:
a set of security labels
a set of events
H

18. disclose
read
L
request_secret
listen
ignore
Our models are labelled event structures, which consist of:
a relation modelling causality (reflexive, transitive)
a set of security labels
a set of events
H

19. disclose
read
L
request_secret
listen
ignore
Our models are labelled event structures, which consist of:
a relation modelling causality (reflexive, transitive)
another relation modelling conflicts
(irreflexive, symmetric, inherited through causality)
a set of security labels
a set of events
H

20. disclose
H
L
POLICY
read
L
request_secret
listen
ignore
Policies are hyper graphs on the labels
H

21. A model satisfies the policy if every direct causal dependency
between different levels is justified by the policy.
disclose
H
L
POLICY
read
L
request_secret
listen
ignore
H
justified by
Policies are hyper graphs on the labels
unjustified!

22. A model satisfies the policy if every direct causal dependency
between different levels is justified by the policy.
disclose
H
L
POLICY
read
L
request_secret
listen
ignore
H
justified by
Policies are hyper graphs on the labels
unjustified!
How does this relate to existing approaches? Just restricting to
L→H there a huge families of possible semantics.

23. BNDC
(bisimulation-based NI)
RBNI
(structural NI)
SNNI
(trace-based NI)
[N. Busi, R. Gorrieri, “Structural non-interference in elementary and trace nets”, Mathematical Structures in Computer Science, 2009]
[N. Busi, R. Gorrieri, “A survey of non-interference with Petri nets”, Lectures on Concurrency and Petri Nets 2003]
[R. Focardi, R. Gorrieri, “A Classification of Security Properties”, Journal of Computer Security, 1995]
• no H→L dependencies
• no H-L conflicts
Some notions of non-interference (allow L→H only) for safe Petri nets
• no H→L dependencies
• no direct H-L conflicts
• no H→L dependencies
( this paper)

24. l h
l
l h
System
h
lh
hl
Event
Structure
PetriNetTransition
System
Traces
l l
Low view
(only L)
l l
l h
l h
l l
l
Low view
(L+H)
Observational NI can miss H→L dependencies
(a resource transformed by H may be leaked to L)

25. l l
h
l l’
h
System Low view
(only L)
Low view
(L+H)
l l’
h
l
lh
Event
Structure
PetriNetTransition
System
Traces
l
l l
l’
l l’ l l’
l l’
Observational NI miss some H-L conflicts
(L may guess non occurrence of H-events)

27. Why more than
2 levels?

28. Sometimes you really need to disclose
Some information about passwords
is always leaked in login systems

29. disclose
H
Sometimes you really need to disclose
D
read
L
H
Leither you forbid this flow
or you relax the policy
POLICY

30. H
L
disclose
H
read
L
either you forbid this flow
or you relax the policy
POLICY
Sometimes you really need to disclose

31. H
L
disclose
H
read
L
H
L
D
POLICY
Disclosure from H to L
is allowed through a
declassifying level D
POLICY
✗
Sometimes you really need to disclose

32. H
L
check
disclose
H
Sometimes you really need to disclose
D
authorise
read
L
H
L
D
POLICY
Disclosure from H to L
is allowed through a
declassifying level D
POLICY

33. Why “collective”
flows?

34. disclose
H
H
L
D
POLICY
read
L
Disclosure from H to L
is allowed if it depends
on declassifying level D
✗
You may not require H and D to coordinate

35. disclose
H
D
H
L
D
POLICY
authorise
read
L
Disclosure from H to L
is allowed if it depends
on declassifying level D
✔
You may not require H and D to coordinate

36. Why “simultaneous”
flows?

37. POLICY
disclose
H
D
H
L
D
read
L
Disclosure from H to L
is allowed if also D is
influenced
✗
In some cases it would be ok for D to log the leaks

38. POLICY
disclose
H
D
H
L
D
record
read
L
Disclosure from H to L
is allowed if also D is
influenced
✔
In some cases it would be ok for D to log the leaks

39. Semantics of policies,
by examples

40. A
Flows allowed by a policy {A,B} E
B
A
E
B
POLICY
E
a
e
IDEA: A direct causality a e is allowed if …

41. A B
A
E
B
POLICY
E
a b
e
IDEA: A direct causality a e is allowed if it occurs in a context like this
INTUITION: Every time E listens to A, it also
needs to listen to B.
Flows allowed by a policy {A,B} E

42. B
A
E
B
POLICY
E
a
A
IDEA: A direct causality e a is allowed if …
e
Flows allowed by a policy E {A,B}

43. B
A
E
B
POLICY
E
INTUITION: Every time E talks to A, it also talks to B.
B may have other “unrelated” causal or conflict
dependencies.
a b
A
IDEA: A direct causality e a is allowed if it occurs in a context like this
•
e
Flows allowed by a policy E {A,B}

44. A
D
B
POLICYC
a
c
A
IDEA: A direct causality a c is allowed if …
C
Flows allowed by a policy {A,B} {C,D}

45. B
A
D
B
POLICYC
INTUITION: Every time A talks to B, it also talks to D
and B also talks to C and D.
a b
c
A
IDEA: A direct causality a c is allowed if it occurs in a context like this
•
C
D
d
Flows allowed by a policy {A,B} {C,D}

46. Some results

47. Relating/Relaxing Policies

48. Relating/Relaxing Policies
…adding/relaxing flows

49. Relating/Relaxing Policies
…adding/relaxing flows
…splitting the required flow sources
A B
C
A B
C

50. Relating/Relaxing Policies
…adding/relaxing flows
…splitting the required flow sources
…splitting the required flow targets
A B
C
A B
C
A
B C
A
B C

51. The most restrictive policy for a model may not be unique
A CB
a
c
b
The model satisfies both policies.
None of the policies can be
restricted for this model.
A B
POLICY
C
A B
POLICY
C
Example

52. Decidability for a class of event structures
Key ideas:
• Deciding FOL properties of a regular trace event structures is
decidable [Madhusudan, LICS 2013]
• Policy satisfaction can be encoded in FOL

53. Conclusion

54. What we have done:
• Focus on causality-based information flows
• Extend one-to-one policies (e.g. H→D→L,…)
• to many-to-many policies (e.g. {H,D}→L, H→{L,D},…)
• Study some semantic/decidability properties
Concluding remarks

55. What we have done:
• Focus on causality-based information flows
• Extend one-to-one policies (e.g. H→D→L,…)
• to many-to-many policies (e.g. {H,D}→L, H→{L,D},…)
• Study some semantic/decidability properties
What else is in the paper?
• Additional coordination constraints on the flows:
• directness
• fairness
• A case study and some application domains
Concluding remarks

56. What we have done:
• Focus on causality-based information flows
• Extend one-to-one policies (e.g. H→D→L,…)
• to many-to-many policies (e.g. {H,D}→L, H→{L,D},…)
• Study some semantic/decidability properties
What else is in the paper?
• Additional coordination constraints on the flows:
• directness
• fairness
• A case study and some application domains
What we are doing:
• More flexible “Causality Patterns” (see talk at ICE 2017)
• Verification for safe Petri nets / Static analysis for programs
• Consider the actual transfer of (the same) information
Concluding remarks

57. Thanks!