1. Hyperproperties Michael Clarkson George Washington University
Summer School on Formal Methods for the Science of Security
University of Illinois at Urbana-Champaign
July 25, 2013

2. Security Policies Today
Confidentiality
“Protection of assets from unauthorized disclosure”
Integrity
“Protection of assets from unauthorized modification”
Availability
“Protection of assets from loss of use”
Security policies are usually expressed today in terms of three kinds of requirements: confidentiality, integrity, and availability. This classification seems to be intuitive, but it suffers from some deficiencies. In particular:
There is no formalism that enables all three kinds of requirements to be stated.
These requirement are not necessarily disjoint. E.g., “Alice can’t read variable x” could be about confidentiality or availability.
Nor are these requirements expressively complete---we don’t know that these suffice to express all security policies.
Finally, we don’t know of complete verification methodologies for each of these requirements. E.g., we don’t know a methodology that enables us to enforce all confidentiality policies.
Formalize and verify any security policy? 

3. Program Correctness ca. 1970s
Partial correctness (If program terminates, it produces correct output)
Termination
Total correctness (Program terminates and produces correct output)
Mutual exclusion
Deadlock freedom
Starvation freedom
???
Some of you may remember that the field of program correctness actually looked a lot like this in the 1970s.
People were interested in verifying various properties of programs, like partial correctness, etc.
Specific formalizations and methodologies for each these.
Nagging suspicion that tomorrow someone was going to come up with a new property that these specific techniques couldn’t handle.

4. Safety and Liveness Properties
Partial correctness
Bad thing: program terminates with incorrect output
Access control
Bad thing: subject completes operation without required rights
Termination
Good thing: termination
Guaranteed service
Good thing: service rendered
Intuition [Lamport 1977]:
Safety: “Nothing bad happens”
Liveness: “Something good happens”
The picture began to change when, in 1977, Leslie Lamport published a paper about safety and liveness. These are two general classes of properties. Intuitively, safety properties say that “nothing bad happens.” Ex… Liveness properties say that “something good happens.” Examples include…

5. Properties Trace: Sequence of execution states
t = s0s1…
Property: Set of infinite traces
Trace t satisfies property P iff t is an element of P
Satisfaction depends on the trace alone
System: Also a set of traces
System S satisfies property P iff all traces of S satisfy P
Safety and liveness were then formalized, starting by formalizing properties.

6. Properties
System S
Property P
= trace

7. Properties
System S
S satisfies P
Property P
= trace

8. Properties
System S
S does not satisfy P
Property P
= trace

9. Safety and Liveness Properties
Formalized:
Safety property [Lamport 1985]
Bad thing = trace prefix
Liveness property [Alpern and Schneider 1985]
Good thing = trace suffix …
Formalisms are well and good, but thus far we haven’t addressed the issues of expressing and verifying any property.

10.  Success! Alpern and Schneider (1985, 1987):
Theorem. Every property is the intersection of a safety property and a liveness property.
Theorem. Safety proved by invariance.
Theorem. Liveness proved by well-foundedness.
Theorem. Topological characterization:
Safety = closed sets
Liveness = dense sets
Formalize and verify any property?
The success of safety and liveness came from the fact that they do enable such expression and verification
In a series of results, Alpern and Schneider showed that: … 

11. Back to Security Policies
Formalize and verify any property?
Formalize and verify any security policy?  ?
Security policy = Property
Enough of the history lesson, let’s get back to security policies. …
Natural question: Why not equate security policies with properties?

12. Information Flow is not a Property
Secure information flow:
Secret inputs are not leaked to public outputs 
p := 1; 
p := s; 
The answer to that, which many of you already know, is that security policies are not properties.
if (s) then p := 1 else p := 0; 
if (s) then {consume power} else {don’t};

13. Information Flow is not a Property
Secure information flow:
Secret inputs are not leaked to public outputs
secret
secret 
public
public

14. Information Flow is not a Property
Noninterference [Goguen and Meseguer 1982]: Commands of high security users have no effect on observations of low security users 4 23 8 15 42 16 10
t1: 4 8 15 16
t2:
Green=public, red=secret
Black/white=inputs, blue=output
We would have thought that these are safety properties, since there is a bad thing…
Not safety!
Satisfaction depends on pairs of traces …so not a property

15. Service Level Agreements are not Properties
Service level agreement: Acceptable performance of system
Not liveness!
Average response time: Average time, over all executions, to respond to request has given bound
Satisfaction depends on all traces of system …not a property
Any security policy that stipulates relations among traces is not a property
Need satisfaction to depend on sets of traces
Similarly, many service level agreements are not properties.
For example, average response time over all executions is not a property. We would have thought this is liveness. But even though there’s a good thing, which is that responses don’t take too long, on average, satisfaction depends on all the traces of the system, rather than individual traces.
Moreover, any policy…
This says that we if we want to formalize security policies, we need satisfaction to depend on sets of traces. That’s the fundamental premise on which this work began.

16. Hyperproperties A hyperproperty is a set of properties
[Clarkson and Schneider 2008, 2010]
A system S satisfies a hyperproperty H iff S is an element of H
…a hyperproperty specifies exactly the allowed sets of traces

17. Hyperproperties
System S
S does not satisfy H
Hyperproperty H
= trace

18. Hyperproperties
S satisfies H
System S
Hyperproperty H
= trace

19. Hyperproperties Security policies are hyperproperties!
Information flow: Noninterference, relational noninterference, generalized noninterference, observational determinism, self-bisimilarity, probabilistic noninterference, quantitative leakage
Service-level agreements: Average response time, time service factor, percentage uptime …
With these definition, security policies are hyperproperties. We’ve formalized many examples in our work, such as…
Indeed, hyperproperties can express every security policy we’ve considered. I’ll return to this notion of “expressive completeness” later.

20. Beyond Hyperproperties?
Security policies are predicates on systems
Hyperproperties are the extensions of those predicates
Hyperproperties are expressively complete
(for predicates, systems, and trace semantics)
Let’s return to the idea of expressive completeness of HP.
You might ask, what’s to stop Schneider from finding another grad student in 20 (or 2) years to add yet another level of sets? …
Through lens of logic…
Thus, HP are expressively complete, at least for trace semantics.

21. Other System Models Relational semantics Labeled transition systems
State machines
Probabilistic systems
…can define hyperproperties for all these
Have to quantify over set of *representations*, rather than over all systems. …for hypersafety and hyperliveness

22. Probabilistic Hyperproperties
To incorporate probability:
Assume probability on state transitions
Construct probability measure on traces [Halpern 2003]
Use measure to express hyperproperties
We’ve expressed:
Probabilistic noninterference [Gray and Syverson 1998]
Quantitative leakage
Channel capacity
As an example of the completeness of hyperproperties…

23. Hyperproperties Safety and liveness? Verification? Questions??
Since we’re building on the theory of properties, it’s natural to ask: can we express safety and liveness for hyperproperties? And do those have associated verification techniques?

24. Safety Safety proscribes “bad things”
A bad thing is finitely observable and irremediable
S is a safety property [Lamport 85] iff
b is a finite trace
Let’s start with safety.

25. Safety Safety proscribes “bad things”
A bad thing is finitely observable and irremediable
S is a safety property [Lamport 85] iff
b is a finite trace

26. B is a finite set of finite traces
Safety
Safety proscribes “bad things”
A bad thing is finitely observable and irremediable
S is a safety property [Lamport 85] iff
S is a safety hyperproperty (“hypersafety”) iff
b is a finite trace
We get hypersafety merely by upgrading all the domains in the definition of safety, adding a level of sets.
B is a finite set of finite traces

27. Prefix Ordering An observation is a finite set of finite traces
Intuition: Observer sees a set of partial executions
M ≤ T (M is a prefix of T) iff:
M is an observation, and
If observer watched longer, M could become T
I didn’t yet specify what the prefix order on sets of traces is.

28. Safety Hyperproperties
Noninterference [Goguen and Meseguer 1982]
Bad thing is a pair of traces where removing high commands does change low observations
Observational determinism [Roscoe 1995, Zdancewic and Myers 2003]
Bad thing is a pair of traces that cause system to look nondeterministic to low observer …
Now, the security policies we thought might have been safety properties, turn out to be safety hyperproperties.

29. Liveness Liveness prescribes “good things”
A good thing is always possible and possibly infinite
L is a liveness property [AS85] iff
t is a finite trace
Let’s turn to liveness.

30. T is a finite set of finite traces
Liveness
Liveness prescribes “good things”
A good thing is always possible and possibly infinite
L is a liveness property [AS85] iff
L is a liveness hyperproperty (“hyperliveness”) iff
t is a finite trace
T is a finite set of finite traces

31. Liveness Hyperproperties
Average response time
Good thing is that average time is low enough
Possibilistic information flow
Class of policies requiring “alternate possible explanations” to exist
e.g. generalized noninterference [McCullough 1987]
Theorem. All PIF policies are hyperliveness.
The security policies we thought might have been liveness properties, turn out to be hyperliveness.
Long known that PIF harder to verify.

32. Relating Properties and Hyperproperties
Can lift property T to hyperproperty [T]
Satisfaction is equivalent iff [T] = powerset(T)
Theorem. S is safety implies [S] is hypersafety.
Theorem. L is liveness implies [L] is hyperliveness.
…Verification techniques for safety and liveness carry forward to hyperproperties
Having defined safety and liveness for both properties and HP, it’s natural to ask: What’s the relationship? …
Good sanity check, but…

33. Safety and Liveness is a Basis (still)
Theorem. Every hyperproperty is the intersection of a safety hyperproperty and a liveness hyperproperty.
Perhaps the most important theorem about safety and liveness was that they are a basis for all properties. …
This is a basis with a surprisingly deep mathematical explanation.
A fundamental basis…

34. Topology Open set: Can always “wiggle” from point and stay in set
Closed set: “Wiggle” might move outside set
Dense set: Can always “wiggle” to get into set
open
closed
dense

35. Topology of Hyperproperties
For Plotkin topology on properties [AS85]:
Safety = closed sets
Liveness = dense sets
Theorem. Hypersafety = closed sets.
Theorem. Hyperliveness = dense sets.
Theorem. Our topology on hyperproperties is equivalent to the lower Vietoris construction applied to the Plotkin topology.

36. Stepping Back… 
Safety and liveness?
Verification?

37. Logic and Verification
Polices are predicates …but in what logic?
Second-order logic suffices, first-order logic does not.
Last summer: Meseguer says “find a concrete logical syntax”
Verify second-order logic?
Can’t! (effectively and completely)
Temporal logic: LTL, CTL*?
Highly successful for trace properties
But not for security policies [McLean 1994, Alur et al. 2006]
Let’s hyper-ize… with quantification over multiple traces ..
“We just don’t know.”

38. Syntax LTL: [Pnueli 1977] HyperLTL: [Koleini, Clarkson, Micinski 2013]
f ::= p | ¬f | f1 v f2 | … | X f | f1 U f2 | … | G f | …
State propositions: x-equals-42
HyperLTL: [Koleini, Clarkson, Micinski 2013]
y ::= At: y | Et: y | f
State propositions annotated with trace variable: x-equals-42t
…LTL is a fragment of HyperLTL
This the LTL syntax.
Let me remind you the syntax of LTL, which has propositions, Boolean connectives, and temporal connectives.
P is a proposition that expresses the fact over single states.
If you have forgotten what LTL temporal temporal connectives are, don’t worry about it.
Let my remind you just what does G means, that is on all states along a path psi holds.
HyperLTL starts with a sequence of universal and existential quantifiers.
In the scope of quantifiers, we have multipath formula psi.
p is a single state and multistate proposition.
Focus formulas are a way of embedding standard LTL formulas into HyperLTL.
It focuses on each path individually and specifies and LTL formula on that path.
// They let you FOCUS on one trace at a time.
Multipath modalities are similar to LTL, but they work over multiple paths synchronously.

39. Examples At: Au: t[0]=Lu[0] ⇒ t=Lu
Observational determinism [Zdancewic and Myers 2003]:
At: Au: t[0]=Lu[0] ⇒ t=Lu
t[0] =L u[0] is sugar for ∧p ∊ L pt ⇔ pu
(first state in both traces agrees on all propositions in L)
t =L u is sugar for G (t[0] =L u[0])
(both traces agrees on all propositions in L)
Note: multiple paths in scope; syntax that reads like the “normal” math written in noninteference papers.
A system satisfies observational determinism if every pair of executions with the same initial low observation remain indistinguishable by low users.
// Such system is immune against refinement attacks.
For example, as you can see, paths pi1 and pi2 are low equivalent, while they have different high inputs and outputs.
For OD, all pairs of paths in the system should be like that.
The number of paths in the scope of quantifiers is equivalent to the number of quantifiers at the beginning of a formula
After note: this is the key thing, that enables us to express security policies in our logic.

40. At: Eu: t=Lu ∧ G no-highu
Examples
Noninference [McLean 1994]:
At: Eu: t=Lu ∧ G no-highu
state-based variant of GM noninterference
Can also express noninteference itself.
And GNI, restrictiveness, separability, forward correctability…
A system satisfies observational determinism if every pair of executions with the same initial low observation remain indistinguishable by low users.
// Such system is immune against refinement attacks.
For example, as you can see, paths pi1 and pi2 are low equivalent, while they have different high inputs and outputs.
For OD, all pairs of paths in the system should be like that.
The number of paths in the scope of quantifiers is equivalent to the number of quantifiers at the beginning of a formula
After note: this is the key thing, that enables us to express security policies in our logic.

41. P ⊨ At : y iff for all t in T, have P, t=t ⊨ y
Semantics
LTL:
formula modeled by single trace: t ⊨ f
system modeled by set T of traces
HyperLTL:
formula modeled by set of traces (actually, set of named traces i.e. valuation or environment)
system still modeled by set T of traces, which is what quantifiers range over:
P ⊨ At : y iff for all t in T, have P, t=t ⊨ y

42. Semantics
P ⊨ At : y iff for all t in T, have P, t=t ⊨ y P ⊨ Et : y iff exists t in T, s.t. P, t=t ⊨ y P ⊨ pt iff p ∊ P(t)[0] P ⊨ ¬f iff P ⊨ ¬f doesn’t hold P ⊨ f1 v f2 iff P ⊨ f1 or P ⊨ f2 P ⊨ X f iff P[1..] ⊨ f P ⊨ f1 U f2 iff there exists i ≥0 s.t. P[i..] ⊨ f2 and for all j where 0 ≤ j < i, have P[j..] ⊨ f1

43. Model Checking
Adapts LTL algorithm based on Büchi automata [Wolper et al. 1983, Lichtenstein and Pnueli 1985, Vardi and Wolper 1994, …]
Prototype…
builds automata using self-composition [Barthe et al. 2004],
then outsources to GOAL [Tsay et al. 2007] for automata constructions
Supports fragment of HyperLTL
Up to one quantifier alternation, e.g. AE, AAE, EA
Suffices for all our information-flow examples
Yields verification methodology for any linear-time hyperproperty
The model-checking algorithm extends LTL and is based on automata-theoretic approach.
In this approach, system and the negation of the formula are transformed into Buchi automata. The intersection in build up, and the emptiness is checked.
The output is yes (formula holds in the system), or no, and a counterexample will be generated.
We have a prototype, which uses self-composition to generate multipaths.
Prototype uses Buchi automata library GOAL, for complementation and counterexample generation.
Last bullet point: That works for all the examples that I showed in this talk, and the ones that we know so far.

44. Model Checking: Complexity
Fragment with 1 alternation:
Exponential in size of system and
Doubly exponential in size of formula 
Full HyperLTL:
PSPACE-hard
Reduction from quantified propositional temporal logic (QPTL)
…price of security? Or do we need to be more clever?

45. Other Hyper Temporal Logics
HyperCTL* [Finkbeiner et al. 2013]
Like HyperLTL, but quantifiers can be nested
Model checking is NSPACE(f(size of system))-complete
where f involves a tower of exponentials… 
“Hyper modal m-calculus”
Polyadic modal m-calculus [Andersen 1994]
Used by Milushev and Clarke [2012] for incremental hyperproperties

46.   Stepping Back… Safety and liveness? Verification?
Model-checking (expensive)
Reduce to trace properties
Refinement 

47. Verification of 2-Safety
2-safety: “Property that can be refuted by observing two finite traces” [Terauchi and Aiken 2005]
Methodology:
Transform system with self-composition construction [Barthe, D’Argenio, and Rezk 2004]
Verify safety property of transformed system
Implies 2-safety property of original system
…Reduction from hyperproperty to property

48. k-Safety Hyperproperties
A k-safety hyperproperty is a safety hyperproperty in which the bad thing never has more than k traces
Examples:
1-hypersafety: the lifted safety properties
2-hypersafety: Terauchi and Aiken’s 2-safety properties
k-hypersafety: SEC(k) = “System can’t, across all runs, output all shares of a k-secret sharing”
Not k-hypersafety for any k: SEC = k SEC (k)

49. Verifying k-Hypersafety
Theorem. Any k-safety hyperproperty of S is equivalent to a safety property of Sk.
Yields methodology for k-hypersafety
Incomplete for hypersafety
Hyperliveness? In general? …
Raises the question: Can a complete methodology exist?

50. Refinement Revisited Stepwise refinement:
Development methodology for properties
Start with specification and high-level (abstract) program
Repeatedly refine program to lower-level (concrete) program
Techniques for refinement well-developed
Long-known those techniques don’t work for security policies—i.e., hyperproperties
Develop new techniques?
Reuse known techniques?
Post-verification is one way to develop… but can also develop systems hand-in-hand with policies

51. Refinement Revisited
Theorem. Known techniques work with all hyperproperties that are subset-closed.
Theorem. All safety hyperproperties are subset-closed.
Stepwise refinement applicable with hypersafety
Hyperliveness? In general?
We’ve shown you can reuse known techniques, for a particular class of hyperproperties

52.     Stepping Back… Safety and liveness? Verification?
Model-checking (expensive)
Reduce to trace properties (k-safety)
Refinement (hypersafety)
Proof system?
…verify by decomposing to safety+liveness?   

53. Summary Theory of hyperproperties : Parallels theory of properties
Safety, liveness (basis, topological characterization)
Verification (HyperLTL, k-hypersafety, stepwise refinement)
Expressive completeness
Enables classification of security policies…

54. Charting the landscape…

55. All hyperproperties (HP)

56. Safety hyperproperties (SHP) Liveness hyperproperties (LHP)
These touch at “true”
Safety hyperproperties (SHP) Liveness hyperproperties (LHP)

57. Lifted safety properties [SP] Lifted liveness properties [LP]HP
SHP
LHP
[SP]
[LP]
Lifted safety properties [SP] Lifted liveness properties [LP]

58. Access control (AC) is safety Guaranteed service (GS) is livenessHP
SHP
LHP
[SP]
[LP] AC GS
Access control (AC) is safety Guaranteed service (GS) is liveness

59. Goguen and Meseguer’s noninterference (GMNI) is hypersafetyHP
SHP
LHP
[SP]
[LP]
GMNI AC GS
Goguen and Meseguer’s noninterference (GMNI) is hypersafety

60. 2-safety hyperproperties (2SHP)
LHP
2SHP
[SP]
[LP]
GMNI AC GS
2-safety hyperproperties (2SHP)

61. Secret sharing (SEC) is not k-hypersafety for any kHP
SHP
LHP
2SHP
[SP]
[LP]
GMNI
SEC AC GS
Secret sharing (SEC) is not k-hypersafety for any k

62. HP
PNI
SHP
LHP
2SHP
[SP]
[LP]
GMNI
GNI
SEC OD AC GS
Observational determinism (OD) is 2-hypersafety Generalized noninterference (GNI) is hyperliveness Probabilistic noninterference (PNI) is neither

63. Possibilistic information flow (PIF) is hyperlivenessHP
PNI
SHP
LHP
2SHP
[SP]
[LP]
PIF
GMNI
GNI
SEC OD AC GS
Possibilistic information flow (PIF) is hyperliveness

64. Revisiting the CIA Landscape
Confidentiality
Information flow is not a property
Is a hyperproperty (HS: OD; HL: GNI)
Integrity
Safety property?
Dual to confidentiality, thus hyperproperty?
Availability
Sometimes a property (max. response time)
Sometimes a hyperproperty (HS: % uptime, HL: avg. resp. time)
CIA seems unrelated to hyperproperties …
But CIA doesn’t have the advantages of HP:
expressive completeness
fundamental basis of safety and liveness
beginning of a relatively complete verification methodology

65. Reading
Hyperproperties. In Proc. CSF 2008, p. 51–65. With Fred B. Schneider.
Hyperproperties. Journal of Computer Security 18(6):1157–1210, With Fred B. Schneider.
A Temporal Logic of Security. Technical report June With Masoud Koleini and Kristopher Micinski.
Temporal Logics for Hyperproperties. In submission. July With Bernd Finkbeiner, Masoud Koleini, Kristopher Micinski, Markus Rabe, and Cesar Sanchez.
We have designed a logic that can formalize security policies.
This logic is inspired by hyperproperties, introduced by Clarkson and Schneider, which can formalize all security policies, but doesn’t have a general verification methodology.
HyperLTL can express state-based information-flow policies.
A decidable model-checking algorithm is developed and a prototype is implemented.
Last bullet point: We are happy to show you how a demonstration after the talk.

66. Hyperproperties Michael Clarkson George Washington University
Summer School on Formal Methods for the Science of Security
University of Illinois at Urbana-Champaign
July 25, 2013

67. Extra Slides

68. Information-flow Hyperproperties
Noninterference: The set of all properties T where for each trace t in T, there exists another trace u in T, such that u contains no high commands, but yields the same low observation as t.
Generalized noninterference: The set of all properties T where for any traces t and u in T, there exists a trace v in T, such that v is an interleaving of the high inputs from t and the low events from u.
Observational determinism: The set of all properties T where for all traces t and u in T, and for all integer j, if t and u have the same first j-1 low events, then they have equivalent jth low events.
Self-bisimilarity: The set of all properties T where T represents a labeled transition system S, and for all low-equivalent initial memories m1 and m2, the execution of S starting from m1 is bisimilar to the execution of S starting from m2.

69. Representing LTS’s
Rich state is the key

70. Different LTS’s, same trace sets
Representing LTS’s a a a b c b c
{ab, ac}
{ab, ac}
Different LTS’s, same trace sets

71. Representing LTS’s a a a b c b c

72. Different LTS’s, different trace sets
Representing LTS’s x m a a a y z n b c b c t u o p
{(xa)(yb)(t$), (xa)(zc)(u$)}
{(ma)(nb)(o$), (ma)(nc)(p$)}
Different LTS’s, different trace sets

73. Topological Definitions
Open sets: closed under finite intersections and infinite unions
Closed sets: complements of open sets
= closed under infinite intersection and finite union
= contains all its limit points
= is its own closure
Dense sets: closure is the universe

74. Powerdomains We use the lower (Hoare) powerdomain Other powerdomains?
Our ≤ is the Hoare order
Lower Vietoris = lower powerdomain [Smyth 1983]
Other powerdomains?
Change the notion of “observable”
Upper: observations can disappear; impossibility of nondeterministic choices becomes observable
Convex: similar problem
But might be useful on other semantic domains

75. Why not CTL*?
s ⊨ AA f = for all p ∊ M, if t[0] = s then p ⊨ A f = for all p,r ∊ M, if t[0] = u[0] = s then r ⊨ f …only the last trace is “remembered” by semantics

76. Work related to HyperLTL
SecLTL [Dimitrova et al. 12]
LTL plus hide modality (high hidden from observation)
Designed for output-deterministic systems
Can’t seem to express, e.g., generalized noninteference
LKU [Balliu et al. 11]
Linear-time logic of knowledge
Handles declassification policies
Designed for observational determinism
Can’t seem to express, e.g., noninference
Incremental hyperproperties [Milushev and Clarke 12]
Polyadic modal mu-calculus [Andersen 94]
Models are tuples of transition systems
Verifiable by game-based model checking
HyperLTL is simpler and seems to suffice for any state-based information-flow policy
Dimitrova uses hide operator for expressing secrecy for deterministic systems.
Balliu applies epistemic logic to verify information leakage in programs. His work is restricted to observational determinism.
Milushev uses expresses hyperproperties in polyadic mu-calculus and uses game-based model-checking for the verification.