figure a
figure b

1 Introduction

Hyperproperties [17] relate multiple execution traces of a system and occur frequently when reasoning about information flow [35, 38], robustness [12, 15], independence [3], knowledge [10, 14], and causality [19, 25]. A popular logic for specifying temporal hyperproperties is HyperLTL [16], an extension of LTL with explicit quantification over execution traces. For example, we can use HyperLTL to express a simple non-interference property as follows:

figure c

Informally, this property – called non-inference [33] – requires that any possible observation made via the low-security input (modeled via atomic proposition l) and output (o) is compatible with a fixed “dummy” sequence of high-security inputs (h) [33]. Concretely, \(\varphi _ NI \) states that for any execution \(\pi _1\), some execution \(\pi _2\) combines the low-security observations of \(\pi _1\) with fixed dummy values for h; here, we require that h is constantly set to false, i.e., (cf. [23]).

Verification and Certificates. In recent years, many verification techniques for temporal hyperproperties (expressed, e.g., in HyperLTL) have been developed [2, 8, 9, 16, 24, 30, 35]. However, while checking if a given system satisfies a HyperLTL property is important, an often equally critical aspect is to convince the user of this satisfaction using explainable certificates. For trace properties – specified, e.g., in LTL – user-understandable certificates for positive and negative verification results have been explored extensively [4, 5, 13, 27, 28, 32]. Likewise, for alternation-free HyperLTL formulas (i.e., formulas that use a single type of quantifier), known techniques for LTL apply [29]. In contrast, generating explainable certificates for the satisfaction of alternating properties like \(\varphi _ NI \) is more complex. For example, \(\varphi _ NI \) states that for any trace \(\pi _1\), there exists some matching execution \(\pi _2\). A certificate must thus implicitly define a mapping that, given a concrete choice for \(\pi _1\), produces a witness trace \(\pi _2\). Defining and understanding such a mapping can be complex, even for simple systems with few states.

Strategies as Certificates. In this paper, we propose strategies as certificates for the satisfaction of \(\forall ^*\exists ^*\) HyperLTL formulas (i.e., formulas where an arbitrary number of universal quantifiers is followed by an arbitrary number of existential quantifiers; e.g., \(\varphi _ NI \)). To accomplish this, we take a game-based verification perspective [6, 20]. The key idea is to interpret the verification of a \(\forall \pi _1. \exists \pi _2\mathpunct {.}\psi \) formula (where \(\psi \) is the LTL body) as a game between universal and existential quantification. The \(\forall \)-player controls the universally quantified trace by moving through the system (thereby producing a trace \(\pi _1\)), and the \(\exists \)-player reacts with moves in a separate copy of the system (thereby producing a trace \(\pi _2\)). Any strategy for the \(\exists \)-player that ensures that \(\pi _1\) and \(\pi _2\), together, satisfy \(\psi \), implies that the formula is satisfied on the given system. We can think of a winning strategy as a step-wise Skolem function that, for every trace \(\pi _1\), iteratively constructs a witnessing trace \(\pi _2\).

Visualizing Strategies. In this paper, we introduce HyGaViz, a verification and visualization tool for strategies in the context of HyperLTL verification. In HyGaViz, the user can input (possibly identical) finite-state transition systems and a HyperLTL formula \(\varphi \). HyGaViz then automatically attempts to synthesize a strategy that witnesses the satisfaction of \(\varphi \). If a strategy exists, HyGaViz displays it to the user. Our key insight is that we can let the user explore the strategy interactively by taking control of universally quantified traces. That is, instead of displaying the strategy in its entirety (e.g., as a table or decision diagram), we let the user play a game. In each step of the game, the user decides on a successor state for each universally quantified system (i.e., the user takes the role of the \(\forall \)-player), and HyGaViz automatically updates the states of all existentially quantified systems (i.e., HyGaViz plays the role of the \(\exists \)-player).

Fig. 1.
figure 1

Screenshots of HyGaViz. (Color figure online)

Full size image

Example 1

We consider a simple verification instance in Fig. 1. On HyGaViz’s initial page (Fig. 1a), we create two (in this case, equal) transition systems (labeled A, B) over atomic propositions (APs) o and h, depicted in the top right. In each system, each state is identified by a natural number and lists all APs that hold in the given state. From initial state 0, the system can branch on AP h (states 1 and 2), but, in either case, AP o is set in the next step (states 3 and 4). We want to verify \(\varphi _ NI \), which – due to the absence of low-security input l – simplifies to . Note how, in HyGaViz, the quantifier prefix is determined implicitly by the order and quantifier type of the systems, and the LTL body is displayed on the bottom left. The user can change the systems, the quantification type, the name, and the order of the systems using the buttons above each system. Upon entering the LTL formula, HyGaViz automatically displays a deterministic automaton for the property (top left). After clicking the Verify button (top right), the user is directed to the strategy simulation page (depicted in Fig. 1b). During the simulation, HyGaViz displays the current state of the automaton and the system state for A and B (in green) and lets the user control the state of (the universally quantified) system A. By hovering over the successor state of system A, HyGaViz highlights the next state for system B (in yellow). In this instance, systems A and B are both in state 0. When the user moves system A to state 1, HyGaViz reacts by moving system B to state 2 (as it has to ensure ). By clicking on a successor state for A, the user locks the choice, and the game progresses to the next round.    \(\triangle \)

Related Work. HyperVis [29] is a tool for the visualization of counterexample traces for alternation-free \(\forall ^k\) formulas. Notably, a counterexample to a \(\forall ^k\) property is a concrete list of k traces, so visualization is possible by highlighting the relevant parts of the traces, potentially using causality-based techniques [18]. Our visualization for properties involving quantifier alternations is rooted in the game-based verification approach for HyperLTL [6, 20], which becomes complete when adding prophecies [6] (see Sect. 2.2). To the best of our knowledge, we are the first to propose a principled approach to generate and visualize user-understandable certificates for alternating hyperproperties.

2 HyperLTL, Game-Based Verification, and Prophecies

We fix a finite set of atomic propositions \( AP \). A transition system (TS) is a tuple \(\mathcal {T}= (S, s_ init , \kappa , L)\), where S is a finite set of states, \(s_ init \in S\) is an initial state, \(\kappa : S \rightarrow (2^S \setminus \{\emptyset \})\) is a transition function, and \(L: S \rightarrow 2^ AP \) is a state labeling. HyperLTL formulas are generate by the following grammar

figure g

where \(a \in AP \) is an atomic proposition, and \(\pi \) is a trace variable. In a HyperLTL formula, we can quantify over traces in a system (bound to some trace variable), and then evaluate an LTL formula on the resulting traces. In the LTL body, formula \(a_\pi \) expresses that AP a should hold in the current step on the trace bound to trace variable \(\pi \). See [23] for details.

2.1 Game-Based Verification

HyGaViz’s verification certificates are rooted in a game-based verification method [6]. Given a \(\forall ^*\exists ^*\) HyperLTL formula \(\forall \pi _1\ldots \forall \pi _k\mathpunct {.}\exists \pi _{k+1}\ldots \exists \pi _{k+l}\mathpunct {.}\psi \), we view verification as a game between the \(\forall \)-player (controlling traces \(\pi _1, \ldots , \pi _{k}\)) and the \(\exists \)-player (controlling traces \(\pi _{k+1} \ldots , \pi _{k+l}\)). Each state of the game has the form \(\langle s_1, \ldots , s_{k+l}, q\rangle \), where \(s_1, \ldots , s_{k+l} \in S\) are system states (representing the current state of \(\pi _1, \ldots , \pi _{k+l}\), respectively), and q is the state of a deterministic parity automaton (DPA) that tracks the acceptance of the LTL body \(\psi \). When the game is in state \(\langle s_1, \ldots , s_{k+l}, q \rangle \), the \(\forall \)-player first fixes successor states \(s_1', \ldots , s_k'\) for \(\pi _1, \ldots , \pi _k\) (such that \(s_i' \in \kappa (s_i)\) for all \(1 \le i \le k\)); the \(\exists \)-player responds by selecting successor states \(s_{k+1}', \ldots , s_{k+l}'\) for \(\pi _{k+1}, \ldots , \pi _{k+l}\); and the game repeats from state \(\langle s_1', \ldots , s_{k+l}', q'\rangle \) (where \(q'\) is the updated DPA state).

Fig. 2.
figure 2

Screenshots of HyGaViz when using prophecies.

Full size image

Visualizing Game-Based Verification. In HyGaViz, the user can create a verification scenario by manually creating finite-state transition systems and a HyperLTL formula; see Fig. 1a. Note how the quantification prefix is determined implicitly by the order of the systems. In particular, the traces are resolved on individual (potentially different) transition systems. During simulation (cf. the example in Fig. 1b), we visualize a game state \(\langle s_1, \ldots , s_{k+l}, q \rangle \) by marking the current state of each system – separated into user-controlled (universally quantified) systems (top right) and strategy-controlled (existentially quantified) ones (bottom right) – and display the current state of the DPA (top left). The user takes the role of the \(\forall \)-player and, in each step, determines successor states for all universally quantified systems. Once successor states for all universally quantified systems are confirmed, HyGaViz automatically updates existentially quantified systems (and the DPA state) based on the internally computed strategy, and the game continues to the next stage. Moreover, HyGaViz highlights the next states when the user hovers over possible successor states for the universally quantified systems (once successor states for all but one universally quantified system are confirmed). Using the information tab in the bottom left, the user can jump to previous game states and explore the reaction of the strategy to different choices for the universally quantified systems.

2.2 Prophecies

In our game, the \(\exists \)-player only observes a finite prefix of the traces produced by the \(\forall \)-player (or, equivalently, the user of HyGaViz) and is thus missing information about the future. We can counteract this by using prophecies [1], which are LTL formulas over trace variables \(\pi _1, \ldots , \pi _k\) [6]. Given an LTL prophecy formula \(\theta \), the \(\forall \)-player (i.e., the user) has to, in each step, decide if its future behavior (on \(\pi _1, \ldots , \pi _k\)) satisfies \(\theta \). If the \(\forall \)-player decides that \(\theta \) holds (resp. does not hold), the \(\exists \)-player can play under the assumption that the future behavior of the \(\forall \)-player satisfies (resp. violates) \(\theta \). See [6] for details.

Example 2

We illustrate prophecies with the example in Fig. 2. The two systems A and B in Fig. 2a generate all traces over AP a, and the HyperLTL formula requires that trace B predicts the future behavior of A. Without prophecies, the \(\exists \)-player loses: No matter what successor state the \(\exists \)-player picks, the \(\forall \)-player can, in the next step, violate the prediction of the \(\exists \)-player. HyGaViz communicates the absence of a winning strategy if the user pushes the Verify button. Instead, the user can add the LTL prophecy (cf. Fig. 2a). During simulation, the user (who takes the role of the \(\forall \)-player) has to, in each step, fix a successor state for system A and determine if prophecy holds. We depict an excerpt of the simulation page in Fig. 2b. As expected, the strategy for the \(\exists \)-player (computed automatically by HyGaViz) can use the prophecy to win: For example, if the user states that holds (so the \(\exists \)-player can assume that a hold in the next step in A), HyGaViz moves system B to state 1. If the user violates a previous prophecy decision – e.g., by stating that prophecy holds but, in the next step, moving system A to state 0 where AP a does not hold – HyGaViz detects this violation and forces the user to restart from an earlier state of the game (Fig. 2c).    \(\triangle \)

3 HyGaViz: Tool Overview

HyGaViz consists of a backend verification engine written in F#. The backend uses spot [22] to translate LTL formulas to DPAs and oink [21] to synthesize a strategy for the \(\exists \)-player. We use a stateless Node.js [37] backend that communicates with the verification engine via JSON. HyGaViz’s frontend is written in JavaScript and uses Cytoscape.js [26] to render transition systems and automata.

4 Conclusion

We have proposed the first method to generate and visualize certificates for the satisfaction of \(\forall ^*\exists ^*\) HyperLTL formulas. Our tool, HyGaViz, allows users to interactively explore the complex dependencies between multiple traces by challenging a strategy for existentially quantified traces. Ultimately, HyGaViz is a first step to foster trust in (and understanding of) verification results for complex alternating hyperproperties, as is needed to, e.g., certify information-flow policies like \(\varphi _ NI \). For now, HyGaViz can handle (small) finite state systems, which we visualize as directed graphs. The underlying strategy-centered approach also applies to larger (potentially infinite-state) systems represented symbolically [7]. In future work, one could extend HyGaViz to such systems by exploring different visualization approaches for larger systems [31, 34, 36].