Hyperproperties: Introduction

As introduced in the previous section, we model systems executions as traces of states, where a state is the most precise information we have about the system in a particular inter- val of time. We maintain the notation of the previous section, denoting with Σs_{⊆ D the state} space of a particular system s, where D is the set of all possible state denotations of all possi- ble systems. Then, we have a lot of choices for execution denotations. For instance, maximal traces, input/output relations, states, etc. In this section we reason about specifications, in a way independent of the choice of executions denotations. Hence, in the following, we de- note with Den a generic set of executions denotations. For instance, we have that Den = Σ∞~ if we chose maximal traces. We model systems semantics as set of executions, namely the semantics domain is ℘(Den). It is clear that, in this settings, a specification is modeled as a set of sets of executions, namely an element of ℘(℘(Den)). Specifications modeled in this way are called hyperproperties [Clarkson and Schneider,2010] in the literature. The authors of [Clarkson and Schneider,2010] had to introduce the prefix “hyper”, in order to distin- guish specifications described as set of sets of executions from specifications described as

44 44

Chapter 4. Systems, Semantics and Specifications M. Pasqua

sets of executions. These latter were called improperly systems properties and were used for decades as the general formalization for systems specifications. The terminology is im- proper since a set of executions cannot be termed as a property, in the mathematical sense, of systems. In fact they are properties of executions, since they are defined by means of a characteristic function with domain Den, instead of ℘(Den). In order to disambiguate, from now on we call hyperproperties the properties of systems, defined on ℘(℘(Den)), and we call trace properties the properties of executions, defined on ℘(Den). Finally we will use “property” in order to denote the general concept of mathematical property. We synthesize these concepts in the following definitions.

• Given a set X, a (mathematical) property over X is just a subset of X.

• Given a set of systems executions denotations Den, a hyperproperty is just a property over ℘(Den), namely it is a subset of ℘(Den).

• Given a set of systems executions denotations Den, an trace property is just a property over Den, namely it is a subset of Den.

Note that hyperproperties generalize trace properties since, as we will see formally later, these latter are isomorphic to a subset of hyperproperties. From now on, we will denote specifications as hyperproperties. Recalling Chapter3, we say that s satisfies an hyperprop- erty Hp ∈ ℘(℘(Den)), in symbols s |= Hp, when I(s) ∈ Hp. Here I(s) ∈ REPSys , Den is the semantics of s, namely an element of the hierarchy presented the previous section. Analo- gously, we can state when a system satisfies a trace property. We use again the same symbol |= in order to denote the satisfiability relation for trace properties: a system s satisfies a trace property P ∈ ℘(Den), written s |= P, when I(s) ⊆ P.

It is clear that, being predicates on single executions, trace properties could express safety requirements like “the system does not go in an error state” but they cannot express, for instance, confidentiality requirements. These latter need to compare different executions of the system, hence a predicate on single executions is not sufficient. Hyperproperties, in- stead, could express relations between executions, since the level of set of sets allows to use predicates over multiple executions. This difference is depicted in Figure4.4. More expres- siveness comes at a cost: the verification of hyperproperties is significantly more complex than the verification of trace properties, as we will see in the next chapters.

We continuously maintain this parallel between hyperproperties and trace properties since the majority of works about specifications analysis/verification deal with these latter only. In the following sections we investigate hyperproperties from a theoretical point of view. First, by a topological point of view (Subsection4.2.2) and then from an algebraic point of view (Subsection4.2.3). We will exploit these theoretical findings in order to build verification methods for hyperproperties in Chapters6,7and8.

It is worth noting that in order to disprove that a system fulfills a trace property it is necessary to show one trace, which is the counterexample. Analogously, in order to dis- prove that a system fulfills a hyperproperty is necessary to show a set of traces (potentially all system traces). Finally, the trace property ∅, written Pfalse_{, is the one which cannot be}

satisfied, by any system, i.e. @s . I(s) ⊆ Pfalse

(∅ is not a representation of any system). Du- ally, the trace property Den, written Ptrue_{, is the one which is satisfied by every system, i.e.}

∀s . I(s) ⊆ Ptrue_{. Analogously, we can define Hp}false

and Hptrue

for hyperproperties as ∅ and ℘(Den), respectively.

M. Pasqua 4.2. Formalizing Specifications Trace properties: sets of traces . . . . . . “properties” of traces (error-free executions) Hyperproperties: sets of sets of traces

. . .

. . .

“properties” of semantics (non-interferent executions-sets)

Figure 4.4: Trace properties and hyperproperties.

Remark. In [Clarkson and Schneider,2010] the authors define Hpfalse

as {∅} instead of ∅. From the point of view of verification, the two definitions are equivalent. In fact, both ∅ and {∅} are unsatisfiable: there is not a system s such that I(s) ∈ ∅ or I(s) ∈ {∅}. We prefer to use ∅ since, by an algebraic point of view, it is more general (see Section4.2.3).

Examples of Hyperproperties. As we have already said, information flows are expressible only with hyperproperties. Now we give other examples of useful specifications, which are not expressible with trace properties. Processes synchronization requirements are hyperprop- erties. In a symmetric mutual exclusion protocol, for every pair of mutual exclusive requests to a critical section the respective grant to enter the section should be answered eventually, but not at the same time. Service Level Agreements are hyperproperties. For instance, the average time, over all executions, to respond to requests must be lower than a given thresh- old. Error resistant codes requirements are hyperproperties. Error resistant codes enable the transmission of data over noisy channels. A typical model of errors bounds the number of flipped bits that may happen for a given code word length. Then, error correction coding schemes must guarantee that all code words have a minimal Hamming distance. This is an hyperproperty, since for every pair of executions with different input data, the encoder must produce code words with, at least, a given Hamming distance. Finally, also crypto-

graphic protocols requirements are hyperproperties. For instance, in a secret-sharing scheme

a (secret) sensitive data is divided in k parts and each part is distributed to a distinct agent. All k of these shares are required to reconstruct the original secret data. In this setting, a system should not, across all of its executions, output all k parts.