Information-Flow Interfaces

. Contract-based design is a promising methodology for taming the complexity of developing sophisticated systems. A formal contract distinguishes between assumptions , which are constraints that the designer of a component puts on the environments in which the component can be used safely, and guarantees , which are promises that the designer asks from the team that implements the component. A theory of formal contracts can be formalized as an interface theory , which supports the composition and re(cid:12)nement of both assumptions and guarantees. Although there is a rich landscape of contract-based design methods that address functional and extra-functional properties, we present the (cid:12)rst interface theory that is designed for ensuring system-wide security properties. Our framework provides a re(cid:12)nement relation and a composition operation that support both incremental design and independent implementability. We develop our theory for both stateless and state-ful interfaces. We illustrate the applicability of our framework with an example inspired from the automotive domain.


Introduction
The rise of pervasive information and communication technologies seen in cyberphysical systems, internet of things, and blockchain services has been accompanied by a tremendous growth in the size and complexity of systems [28].Subtle dependencies involving multiple architectural layers and unforeseen environmental interactions can expose these systems to cyber-attacks.This problem is further exacerbated by the heterogeneous nature of their constituent components, This project has received funding from the European Unions Horizon 2020 research and innovation programme under grant agreement No 956123 and was funded in part by the FWF project W1255-N23 and by the ERC-2020-AdG 101020093.
which are often developed independently by different teams or providers.In such a scenario, defining and enforcing security requirements across components at an early stage of the design process becomes a necessity.This engineering approach is called security-by-design.Although in recent years there has been impressive progress in the verification of security properties for individual system components, the science of compositional security design [22,23] is still in its infancy.
Security policies are usually enforced by restricting the flow of information in a system [30].Information-flow policies define which information a user or a software/hardware component is allowed to observe or to interfere with while interacting with another component.
The goal of information-flow control is to ensure that a system as a whole satisfies the desired policies.It is especially challenging to verify that there are no side-channels or implicit flows that violate a given policy.For example, in a modern car, the tight coupling between the cyber and the physical components allows an attacker to infer computational properties, such as secrets used for encryption, from side-channels, such as power consumption and electromagnetic radiation [17].Moreover, the increasing connectivity of automotive systems with their environment makes it easier for the attacker to gather data about the system behavior.The attacker can use this data to exploit weaknesses of the system implementation and gain control over the system [32,7].These attacks often rely on analyzing and comparing multiple observations to deduce protected information.From a formal-language perspective, such security vulnerabilities are not characterized by properties of a single system execution, but rather by properties of sets of execution traces, which are called hyperproperties [12].
The rigorous design of systems that satisfy information flow requirements is essential from the security perspective.This activity can be supported by the verification of information flow properties, a well-studied problem with a rich landscape of both theory and tools, ranging from language-based [29,18,15,11] to simulation-based [25] approaches.Nevertheless, the existing verification solutions do not address two important aspects.First, components in complex systems are often heterogeneous and cannot be analysed with a single verification tool.Moreover, it is not clear how to combine component verification outcomes to infer system-level information-flow properties.Second, existing methods do not provide guidelines on which information flow properties need to be verified against individual components to provide system-level guarantees regarding leakage of information.
In this paper, we present a contract-based design [8] approach for the structural aspect of information-flow policies.Contract-based design provides a formal framework for building complex systems from individual components, mixing both top-down and bottom-up steps.A top-down step decomposes and refines system-wide requirements; a bottom-up step assembles a system by combining available components.A formal contract distinguishes between assumptions, which are constraints that the designer of a component puts on the environments in which the component can be used safely, and guarantees, which are promises that the designer asks from the team that implements the component.A theory of formal contracts can be formalized as an interface theory, which supports the composition and refinement of both assumptions and guarantees [2,3,31].While there is a rich landscape of interface theories for functional and extra-functional properties [10,4,13,20], we present the first interface theory that is designed for ensuring system-wide security properties, thus paving the way for a science of safety and security co-engineering.
The focus on the structural aspects of information flow and abstraction from concrete semantics enables compositional reasoning in presence of heterogeneous components and is complementary to the existing body of work on information flow verification.A different component implementation verified under different semantics could result in different flows being detected.However, after deriving the component flows from the implementation under some concrete semantics, the theory can be agnostic about the underlying semantic interpretation.Hence it enables the design of secure systems from trusted components by abstracting away how information flows and by focusing on whether it can flow at all.In essence, our approach enables to decompose system-level information flow requirements and derive component properties that need to hold, thus providing a divide-and-conquer procedure for organizing verification tasks.
Our theory is based on information-flow assumptions as well as informationflow guarantees.As an interface theory, our theory supports both incremental design and independent implementability [3].Incremental design allows the composition of different system parts, each coming with their own assumptions and guarantees, without requiring additional knowledge of the overall design context.Independent implementability enables the separate refinement of different system parts by different teams that, without gaining additional information about each other's design choices, can still be certain that their designs, once combined, preserve the specified system-wide requirements.While in previous interface theories, the environment of a component is held responsible for meeting assumptions, and the implementation of the component for the guarantees, there are cases of information-flow violations for which blame cannot be assigned uniquely to the implementation or the environment.In information-flow interfaces we therefore introduce, besides assumptions and guarantees, a new, third type of constraint-called properties-whose enforcement is the shared responsibility of the implementation and the environment.We develop our framework for both stateless and stateful interfaces.Stateless information-flow interfaces are built from primitive information-flow constraintsassumptions, guarantees, and properties-of the form "the value of a variable x is always independent of the value of another variable y." Stateful informationflow interfaces add a temporal dimension, e.g., "the value of y is independent of x until the value of z is independent of x."The temporal dimension is introduced through a natural notion of state and state transition for interfaces, not through logical operators.We prove that our calculus of information-flow interfaces satisfies the principles of incremental design and independent implementability.We showcase the applicability of our theory with an example from the automotive industry: a stepwise design of a shared communication infrastructure (a bus) from distance warners and a wheel sensor to the braking system and the odometer.We adapted this use-case from the industrial case study presented by Marcus Mikulcak et al. [25].The main goal of this system design is to ensure the integrity of a communication channel used to perform a safety-critical functionality.We consider two integrity levels, high and low, to characterize functionalities in our system.Then, we want to guarantee that data exchanged by high-integrity functionalities is not compromised by low-integrity functions.
Distance warners sense the car's proximity to other objects and send their analysis to other components.In our example, we have two distance warners, at the front and the back of the car, that use the shared bus to communicate with the braking system.The wheel sensor senses the wheel rotations and sends this information through the shared bus to the odometer.The braking system is a high-integrity system since it performs safety-critical functions.Hence the communication channel between the distance warners and the braking system is classified with high-integrity, while the communication between the wheel sensor and the odometer is low-integrity.Thus, data sent by the wheel sensor should not interfere with the high-integrity channel to prevent distance warnings sent to the braking system from being delayed or lost.The main goal of our design process is to guarantee that the closed system requirement that information from the wheel sensor does not flow to the braking system is propagated accordingly to subsystems through successive decomposing and refinement steps.Figure 1 shows the graphical representation we adopt throughout the paper for the objects in our theory.We represent the open system no-flows requirements with dashed arrows.Then, arrows to input ports are assumptions while arrows to output parts are guarantees.The closed system noflows, properties, are represented as dotted arrows.To improve the readability of the drawings, it is implicit that for each drawn property, we have the same guarantee over the open system.When it is clear from the context we may omit port(s) names.We present, in Fig. 2, the stepwise design of the security requirement that data from the wheel sensor, wheel tick, should not flow to the target of the distance warners, distw f t and distw b t.The first interface in Fig. 2 includes two properties that specify this security requirement.The system is then decomposed into the sending subsystems (warners and wheel sensor), the shared bus, and the receiving subsystems.
Naturally, we keep the two properties from the first interface as properties in the Bus interface.However, this natural decomposition does not define a well-formed interface according to our theory because the properties in the Bus interface cannot be satisfied given the interface's current assumption and 1.

decompose and refine
Fig. 2: Top-down design of a shared communication infrastructure used by two distance warners, distw f s and distw b s, and a wheel sensor, wheel tick, to communicate with the braking system, distw f t and distw b t, and the odometer, odometer, respectively.guarantee.As the environment allows a flow from wheel tick to the source of the front distance warner, wheel tick distw f s then, with the flow allowed by the guarantee from a distance warner source to its target, we have the flow wheel tick distw f s distw f t.This flow is forbidden by the interface's properties.If we specified the no-flow properties in the Bus interface as guarantees, then the interface would be well-formed.However, the composition of the three subsystems would not satisfy the initial specification because guarantees only apply to implementations of their interface, and the flow described above would still be allowed in the composition of the three subsystems.This illustrates two applications of the information-flow interface theory: to detect inconsistent noflow specifications and faulty decompositions.Moreover, when an interface is not well-formed we can provide a witness for the property violation.We can use this witness to guide the refinement of an ill-formed interface into a well-formed one.
In the second step of our refinement, in Figure 2, we add the missing assumptions to the Bus interface.Our notion of composition compatibility between interfaces requires that the Sending interface includes guarantees that implies the Bus assumptions, as the Sending interface will be part of the Bus environment.At this point, with a certified decomposition of the original specification, our theory guarantees that each subsystem can now be further refined independently (possibly by different teams).The last step illustrates an independent refinement of the Sending and the Receiving interfaces.
In Fig. 3, we present the stateful view of the system, which requires that the system satisfies the composition of the Sending, the Bus, and the Receiving interfaces derived in Fig. 2 at all times.We present, as well, a refinement of that specification, which requires that in each time point only one of the sending components can use the bus.The interfaces that define each state are named after the sending component that can use the bus (e.g. in the state S wheel only the wheel tick can use the bus).If the access to the bus is mutually exclusive, then we can simplify the assumptions on the environment in the Bus interface.With more guarantees on the implementations we need fewer assumptions to satisfy the properties.Fig. 3: Design of mutually exclusive shared communication infrastructure for distance warners and the wheel odometer.Each state is defined by the composition of the interfaces inside.
Finally, the components of our system can be, for instance, the Simulink and Stateflow models provided to the authors [25] by their industrial partners.We can then use the tool introduced in their work to verify whether these components implement the stateful interfaces we derived.
In summary, our framework defines relations on both stateless and stateful interfaces specifying information-flow policies that allow to check if: (i) a given interface refines (or abstracts) the current specification; (ii) two interfaces are compatible for composition; (iii) a specification is consistent; (iv) informationflows in a component define an implementation of a given interface; and (v) a system decomposition refines the system specification.

Stateless Information-flow Interfaces
In this section, we introduce a stateless interface and component algebra for secure information flow.Information flows between two variables when the value of one influences the other.
We are interested in the structural properties of information flow within a system and define relations abstracting flows, flow relations, as being both reflexive and transitively closed.An information-flow component abstracts the implementation of a system by a flow relation.An information-flow interface specifies forbidden flows in an open system by defining three kinds of constraints: assumptions, guarantees, and properties.The assumption characterizes flows that we assume are not part of the environment while the guarantee describes all flows the system forbids and that are local to it.The property qualifies the forbidden flows at the interaction between the system and its environment.Hence, it represents a requirement on the closed system that needs to be enforced by guarantees on the open system and assumptions on its environment.Given an interface F we are interested in components that do not implement flows forbidden by either the interface guarantees (called implementations of F ) or the interface assumptions (called environments of F ).In Figure 4, we have the first refinement of the interface Bus from our application example.The Bus interface specifies the requirement on the closed system (using properties) that there are no-flows from wheel tick to both distw f s and distw b s.The Bus interface specifies this requirement as a guarantee on the open system, too.Then, the bus component is an implementation of Bus because it has only a flow from distw f s to distw f t, which is not in the guarantees of the Bus interface.Bus does not have any assumptions, then the sending component is an environment for Bus.When we compose the components sending and bus, there is a flow from wheel tick to distw f t, which is in the properties of the Bus.Hence the assumption and guarantee specified over the open system are not enough to ensure the property over the closed system.The composition of these two components witness that the Bus interface is not well-formed.
An information-flow interface is well-formed when it has at least one implementation and one admissible environment.Therefore, all of its relations must be irreflexive.We refer to irreflexive relations as no-flow relations.A well-formed interface ensures, additionally, that an interface property is consistent with its assumptions and guarantees.An interface property is not consistent when the flow relation defined by the composition of one of the interface's admissible environments with one of its implementations includes a pair specified in the interface property.To check whether the property is consistent, we compute the flow relation of the closed system defined by an interface F , which includes all flows that are in the composition of any of the interface's admissible environments with one of its implementations.The main challenge is that, in general, the complement of an interface's guarantee (assumption) may not define the flow relation of any of its implementations (environments).Hence there may be no maximal implementation or admissible environment for a given interface.
In Figure 5, we have two components, bus s and bus t , that implement the interface Bus from the previous example.A maximal implementation of Bus must include the flows in both bus s and bus t .As flows are transitively closed, the maximal implementation would include a flow from wheel tick to distw f t, which violates the Bus guarantees.
Given that we do not have maximal implementations and maximal admissible environments, then we cannot characterize all flows of the closed system defined by an interface F by computing the transitive closure of all pairs in the complement of F 's assumption and guarantee -(A ∪ G) * .This approach would yield more flows than the flows of the closed system defined by F .Instead, we consider all pairs (z, z ) such that there exists a path from z to z that alternates between flows in the complement of the assumption, A, and the guarantee, G.We define this notion below as the composition between no-flow relations.In Proposition 1 we prove that this definition captures our intended relation between an interface property and its environments and implementations.
We have now all the ingredients to define well-formed interfaces.

Composition and Incremental Design
We now present how to compose components and interfaces.We introduce a compatibility predicate that checks whether the composition of two interfaces is a well-formed interface.We prove that these two notions support the incremental design of systems.
The different types of variables between interfaces F and F are defined as . The same definition applies to components f and f .The composition of components f and f is the reflexive and transitive closure of the union of the individual component flows, i.e. f ⊗ f = (X f,f , Y f,f , (M ∪ M ) * ).We present interface composition by defining separately A, G and P of the composed interface.
We compose interfaces through their shared variables.Shared variables between two interfaces are all variables that are an input variable in one of the interfaces and an output variable in the other one.The composite flows between two interfaces is the set with all flows that are in the composition of any of their implementations.As for the definition of flows in the closed system defined by an interface, the composite flows are the composition of the guarantees of the interfaces being composed (as defined in Definition 3).The composition of two interfaces should not restrict their sets of implementations, thus the composite guarantees are the complement of the composite flows.The assumption of an interface resulting from the composition of multiple interfaces is the weakest condition on the environment that allows the interfaces being composed to work together.Additionally, it must support incremental design, i.e. the admissibility of an environment must be independent of the order in which the interfaces are composed.
Naturally, all assumptions of each interface must be considered during composition.However, not all of them can be kept as assumptions of the composite interface, because shared variables will be output variables of the composition.If the environment can still influence the information flow to a shared variable, then we may need to add assumptions to prevent such a flow.Propagated assumptions between two interfaces are derived by looking in their respective assumptions for no-flow pairs pointing to a shared variable.In Figure 6, we depict an interface specifying information-flow policies for a car immobilizer, F imm , along with an interface for a Controller Area Network (CAN bus), F can .Interface F imm has only one assumption that key does not flow to can.In this design, the immobilizer uses the CAN to communicate with the car electronic control unit (ECU).Our goal is to compose both interfaces.These interfaces share the port can.Thus, can will be an output port of their composition.The interface F can cannot guarantee that the only assumption in F imm is satisfied after composition because it does not have a port key.As we are working with open systems and assume that the environment is helpful, we can add further assumptions to ensure the correctness of this composition.For example, we can add assumptions that prevent key from flowing to an input port in F can that can flow to can.Such flows could be part of a flow from key to can, which would violate the assumption we want to enforce.In this case, we note that in F can information in ecu can flow to can.So, the composite interface needs to include the assumption that key does not flow to ecu.This is a propagated assumption.Definition 6.The set of assumptions propagated from F = (X, Y, A, G, P) The set with all propagated assumptions of F and F is ÂF,F = ÂF →F ∪ ÂF →F .The composite assumptions of F and F are defined as A F,F = (A ∪ A ∪ ÂF,F ) ∩ (Z F,F ×X F,F ), also denoted by A F ⊗F .Example 4. From the example before, information from the ports ecu, imm and deb can all flow to can.So, they are flows in the composite interface and, by Definition 5, {(ecu, can), (imm, can), (deb, can)} ⊆ G Fimm,Fcan .Then, ÂFimm→Fcan = {(key, ecu), (key, imm), (key, deb)}.From those assumptions only (key, ecu) points to a variable in X F,F , so A Fimm,Fcan = {(key, ecu)}.
The properties of the composition contains all properties of each interface being composed.They include, additionally, all derived properties from the assumptions and guarantees of the composite.Derived properties are guarantees that hold under any admissible environment.They are defined by all pairs (z, y) in an interface guarantee s.t.there is no combination of flows allowed by its assumptions and guarantees that creates a flow from z to y.Then, the derived properties of an assumption A and guarantee G is defined as The composite properties of F and F are P F,F = P ∪ P ∪ P A F,F ,G F,F .Definition 7. The composition of two interfaces F and F is the interface: F ⊗ F = (X F,F , Y F,F , A F,F , G F,F , P F,F ), where A F,F is defined in Definition 6, G F,F defined in Definition 5 and P F,F in the previous paragraph.
We allow composition for any two arbitrary interfaces.However, not all compositions result in a well-formed interface.We define next the notions of two interfaces being composable and compatible.Composability imposes the syntactic restriction that both interface's output variables are disjoint.Compatibility captures the semantic requirement that whenever an interface F provides inputs to another interface F , then F needs to include guarantees that imply the assumptions of F .Definition 8. Two interfaces F = (X, Y, A, G, P) and F = (X , Y , A , G , P ) are composable iff Y ∩ Y = ∅.The interfaces F and F are compatible, denoted F ∼ F iff they are composable and Clearly, both the composition operator and the compatibility relation are commutative.Additionally, we prove that composition preserves well-formedness and that it supports incremental design of systems.The full proofs are in the appendix.
Theorem 1.Let F and F be well-formed interfaces.If the interfaces are compatible, F ∼ F , then their composition, F ⊗ F , defines a well-formed interface.
Theorem 2 (Incremental design).Let F , F and F be interfaces.
Proof.We proved first that composite assumptions are associative.We assume that F ∼ F and (F ⊗ F ) ∼ F .The most interesting case is when (z, s) is an assumption of F and s is a shared variable between F and F ⊗ F .Then, we need to prove that (z, s) ∈ G F,F ⊗F .We prove this by assuming towards a contradiction that (z, s) ∈ G F,F ⊗F .We illustrate it in Figure 7.By composite flows being associative, (z, s) ∈ G F ⊗F ,F .By (z, s) being an assumption of F and (s , s) ∈ G F ⊗F , then we have the derived assumption (z, s ) ∈ ÂF →F and, so (z, s ) ∈ A F ⊗F .Moreover, (z, s ) ∈ G F ⊗F ,F , because z can flow to s when F ⊗ F is composed with F .This contradicts our initial assumption that (F ⊗ F ) ∼ F .
We prove additionally that composition is associative for compatible interfaces.
Finally, we show that flows resulting from the composition of any components that implement two given interfaces are allowed by the composition of these interfaces.
Proposition 2. For all two interfaces F and F , and all two components f = (X, Y, M) and f = (X , Y , M ) that implement them, f |= F and f |= F , then the composition of the components implements the composition of the interfaces, f ⊗ f |= F ⊗ F .

Refinement and Independent Implementability
We now define a refinement relation between interfaces.Intuitively, an interface F refines F iff F admits more environments than F , while possibly constraining its implementations.Definition 9. Interface F = (X , Y , A , G , P ) refines F = (X, Y, A, G, P), written F F , when A ⊆ A, G ⊆ G and P ⊆ P .
Let F and F be interfaces s.
Additionally, we show below that refinement and composition supports independent implementability.
Theorem 4 (Independent implementability).For all well-formed interfaces Proof.The challenging part is to prove that the refined composite contains all properties of the abstracted one, i.e.P F1⊗F2 ⊆ P F 1 ⊗F2 .We prove by induction on n ∈ N that if a pair of variables (z, y) cannot be defined by assume-guarantee paths of size at most n of the abstract composition, then it cannot be defined by assume-guarantee paths of size at most n of the refined composition.We can see easily for the base case.If for all (z, s) ∈ A F1,F2 s.t.there exists (s, y) ∈ G F1,F2 , then, by F 1 F 1 , it follows that for all (z, s) ∈ A F 1 ,F2 there exists (s, y) as well.

Discussion
Properties.In this work, we consider transitively closed flows.In this setting, in an open system, information can flow from z to z by flowing from z to s through the environment, and then from s to z through one of its implementations.As our algebra focuses on the design of structural requirements of no-flows in open systems, it needs to support the specification of global no-flow requirements.We made them explicit by introducing properties.If we did not include properties in our interfaces, then either assumptions or guarantees would need to take over the role of specifying global no-flows.Let's assume that, alternatively, guarantees would be interpreted as global no-flows.Then, to support incremental design, the compatibility criteria between interfaces would turn out to be overly restrictive, with intuitive and correct designs being considered incompatible.This led us to the distinction between guarantees and properties, where properties may be supported by assumptions on the environment that can restrict the set of compatible interfaces.In other words, the main advantage of having properties is that the designer can choose how to split the responsibilities between the environment and the implementations to satisfy a global no-flow.
Semantics.The structural approach that abstracts away semantic considerations is an important feature of our theory.The practicability of our approach lies in the support for the design of such requirements by decoupling the design process from (its orthogonal) semantic considerations.Hence, our approach does not deny semantics, but rather separates the design of specifications from component implementation concerns.The presented approach even allows using tailored semantics and tools for different parts of the design.For example, at the bottom (component) level, no-flows and flows relations can be instantiated with different semantic interpretations.After deriving the component no-flows from the implementation under a concrete semantics, the theory can be agnostic about the underlying semantic interpretation and can focus on whether there exists a flow at all.

Stateful Information-Flow Interfaces
We extend our theory with stateful components and interfaces.These are transition systems in which each state is a stateless component or interface, respectively.
Definition 10.Let X and Y be disjoint sets of input and output variables, respectively, with Z = X ∪ Y the set of all variables.Let Q be a set of states with q ∈ Q being the initial state and δ : is a state labeling such that for all states q ∈ Q, M(q) defines a flow relation.We denote by f (q) = (X, Y, M(q)) the stateless component implied by the labeling of q.A stateful information-flow interface F is a tuple (X, Y, Q, q, δ, A, G, P), where A : Q → 2 Z×X is called assumption; G : Q → 2 Z×Y is called guarantee; and P : Q → 2 Z×Y is called property.For each state q ∈ Q we denote by F(q) = (X, Y, A(q), G(q), P(q)) the stateless interface implied by the assumption, guarantee and property of q.
A stateful interface F is well-formed iff F(q) is a well-formed stateless interface, and for all q ∈ Q reachable from q the stateless interface F(q) is well-formed.In what follows, F = (X, Y, Q, q, δ, A, G, P) and F = (X , Y , Q , q , δ , A , G , P ) are stateful interfaces, and A stateful component f implements a stateful interface F if there exists a simulation relation from f to F such that the stateless components in the relation implement the stateless interfaces they are related to.Admissible environments require a simulation relation from them to the interface they are admissible on.
q) ∈ H and for all (q f , q) ∈ H: (i) f (q f ) |= F(q); and (ii) if q f ∈ δ f (q f ), then there exists a state q ∈ δ(q) s.t.(q f , q ) ∈ H.A component f E is an admissible environment for the interface F, denoted by f E |= F, iff there exists a relation H ⊆ Q × Q E s.t.(q, qE ) ∈ H and for all (q, q E ) ∈ H: (i) f (q E ) |= F(q); and (ii) if q ∈ δ F (q), then there exists a state q E ∈ δ E (q E ) s.t.(q , q E ) ∈ H.
As for stateless interfaces, we have that interface's properties are satisfied after we compose any of its implementations f with any of its admissible environments f E .Proposition 3.For all well-formed interfaces F, and all relations H ⊆ Q f × Q and H E ⊆ Q × Q E that witness f |= F and f E |= F, respectively, it holds: (i) (M(q f ) ∪ E(q E )) * ∩ P(q) = ∅; and (ii) for all q ∈ Q that are reachable from q, if (q f , q) ∈ H and (q, q E ) ∈ H E , then (M(q f ) ∪ E(q E )) * ∩ P(q) = ∅.
Composition of two components is defined as their synchronous product.The composition of two interfaces is defined as their synchronous product, as well.However, we only keep the states that are defined by the composition of two compatible stateless interfaces.Definition 12. Let F and F be two interfaces.Their composition is defined as the tuple: F ⊗ F = (X F,F , Y F,F , Q F,F , qF,F , δ F,F , A F,F , G F,F , P F,F ), where: qF,F = (q, q ) and Q F,F = {q F,F }∪{(q, q ) | F(q) ∼ F (q )}; (q 2 , q 2 ) ∈ δ F,F (q 1 , q 1 ) iff q 2 ∈ δ(q 1 ) and q 2 ∈ δ (q 1 ); for all (q, q ) ∈ Q F,F : F F,F (q, q ) = F(q) ⊗ F (q ).Two stateful interfaces are compatible if the stateless interfaces defined by their initial states are compatible, i.e.F(q) ∼ F (q ).It follows from the results proved for the stateless interfaces that compatibility is commutative, composition preserves well-formedness and stateful interfaces support incremental design.Given an interface, we define transitions parameterized by no-flows on its input variables (i.e. with fixed assumptions) or on its output variables (i.e. with fixed guarantees and properties).Definition 13.Let F be an interface.Input transitions from a given state q ∈ Q are defined as δ X (q) = {δ X (q, A) | A ⊆ Z × X} with δ X (q, A) = {q ∈ δ(q) | A(q ) = A}.Output transitions from a given state q ∈ Q are defined as δ Y (q) = {δ Y (q, G, P) | G ⊆ Z × Y and P ⊆ Z × Y } with δ Y (q, G, P) = {q ∈ δ(q) | G(q ) = G and P(q ) = P}.
Interface F R refines F A , if all output steps of F R can be simulated by F A , while all input steps of F A can be simulated by F R .This corresponds to alternating refinement [5].Definition 14. Interface F R refines F A , written F R F A , iff there exists a relation H ⊆ Q R ×Q A s.t.(q R , qA ) ∈ H and for all (q R , q A ) ∈ H: (i) F R (q R ) F A (q A ); (ii) for all set of states O ∈ δ Y R (q R ), there exists O ∈ δ Y A (q A ) s.t. for all set of states I ∈ δ X A (q A ), there exists x y y x q 3 q 2 q 1 q 2 q 1 q1 q2 q3 q1 q2 Fig. 8: Refined interfaces with witness: (a) relation {(q 1 , q 1 ), (q 2 , q 2 )}; and (b) relation {(q 1 , q 1 ), (q 2 , q 2 ), (q 3 , q 2 )}.
Example 5.In Figure 8 we depict two examples of refined stateful interfaces.
In Figure 8(a) the stateless interface in each state only uses output ports and it only specifies properties.The initial state of both stateful interfaces is the same, so they clearly refine each other.As there are no assumptions and guarantees, then, by Definition 14, we need to check that for all successors of the initial state in the refined interface q s , there exists a successor of the initial state in the abstract interface q s such that P A (q s ) ⊆ P R (q s ).This holds for the states (q 2 , q 2 ).Hence the relation {(q 1 , q 1 ), (q 2 , q 2 )} witnesses the refinement.Note that the refined interface is obtained by removing a nondeterministic choice on the transition function.
The witness relation for the refinement depicted in Figure 8(b) is {(q 1 , q 1 ), (q 2 , q 2 ), (q 3 , q 2 )}.The initial states are the same, so the condition (i) in Definition 14 is trivially satisfied.The refined interface has two distinct output transitions from the initial state q1 .It can either go to state q 2 by choosing the set of guarantees and proposition with only one element (x, y) or it can transition to state q 3 by committing to the set of no-flows {(x, y), (x , y)} for the guarantees and {(x, y)} as property.From the initial state of the abstract interface, there exists only one input transition possible, to assume that x does not flow to x and y does not flow to x.The following holds for both states accessible from the initial state in the refined interface: A R (q 2 ) ⊆ A A (q 2 ) and A R (q 3 ) ⊆ A A (q 2 ).The refined interface specifies an alternative transition from the initial state (represented by state q 3 ) that allows more environments while restricting the implementation and preserving the property.
Theorem 6 (Independent implementability).For all well-formed interfaces The composition operation on stateful information-flow interfaces can be generalized to distinguish between compatible and incompatible transitions of interfaces when they are composed.Usually this is done by labeling transitions with letters from an alphabet, so that only transitions with the same letter can be synchronized.While necessary for practical modeling, we omit this technical generalization to allow the reader to focus on the novelty of our formalism, which is the ability to specify information-flow constraints (environment assumptions, implementation guarantees, and global properties) at each state of an interface.

Related Work
To the best of our knowledge, we are the first to provide a theory for top-down and bottom-up design of information-flow system requirements that supports both incremental design and independent implementability of systems.The literature closest to our work about information-flow focus on the semantic aspects of it.The novelty of our work lies on explicit separation of the structural concerns from the semantic aspects of information-flow.
Language-based techniques have been proved useful to verify and enforce information flow policies [29].Examples range from type systems [15] to program analysis using program-dependency graphs (PDGs) [18,16].In our approach we aim at composition and refinement notions that are independent of the language adopted for the implementations.
Information-flow properties can be specified with respect to the observed behavior of a system, in which each of its execution runs is abstracted as a trace.In this approach, properties often compare multiple executions of a system to certify that no forbidden flow can be deduced by an observer.Such properties over multiple execution traces are called hyperproperties [12].Temporal logics [26], like LTL or CTL* are used to specify trace properties of reactive systems.HyperLTL and HyperCTL* [11] extend temporal logics by introducing quantifiers over path variables.They allow relating multiple executions and expressing informationflow security properties [12,11].Epistemic temporal logics (ETL) [9] provide the knowledge connective with an implicit quantification over traces.With ETL we can reason about the knowledge gain of agents over time.Then, we can specify which information can be learned by the agents while interacting with the system [6].All these LTL extensions reason about closed systems while our approach allows compositional reasoning about open systems.Moreover, we focus here on the structural aspect of information-flow, and not yet on its semantic interpretation.Thus, all information-flow trace-based semantics are orthogonal to our approach.
Interface theories belong to the broader area of contract-based design [8], originally popularized by Meyer [24], following earlier ideas introduced by Floyd and Hoare [14,19].Our theory follows closely the philosophy for formal frameworks for systems design introduced for Interface automata (IA) [1] and Assume/Guarantee (A/G) [2] interfaces.Interface theories were later extended with extrafunctional requirements such as resource [10], timing [4,13] and security [21] requirements.Unlike in previous interface formalisms, we had to introduce the notion of properties which capture the intent of the designer and can be used to steer the refinement of interfaces.
Interface for structure and security (ISS) [21] is a variant of IA that enables specification of two types of actions on (1) low and (2) high confidential information.ISS uses a bisimulation-based notion of non-interference that checks whether the system behaves in the same way when high actions are performed or when they are considered hidden actions.Our approach is orthogonal to IA and their extensions: we do not characterise the type of actions of each component, but only their input/output ports, defining explicitly the information-flow relations between variables.
Our approach took inspiration from relational interfaces (RIs) [31].RIs specify the legal inputs that the environment is allowed to provide to the component along with the legal outputs that the component can generate when provided with these input.RIs do not have assumptions and guarantees defined separately.Instead, they have a contract that specifies the desired input-output behavior.A contract in RIs is expressed over individual traces.Then, an RI contract can only relate input and output values in a trace, and not across multiple traces.This restricts considerably RIs expressivity concerning information-flow properties.Besides, RIs are trace-based interfaces, while in our approach we focus on the structural aspect of information-flow, which may change from state to state (in the stateful case).Our approach can be seen as a limited way to introduce relational properties into A/G interfaces, namely solely for guiding refinement.This limited way avoids many of the technical complexities of general relational interfaces [31].

Conclusion
We propose a novel interface theory to specify information-flow properties.Our framework includes both stateless and stateful interfaces and supports both incremental design and independent implementability.To achieve this, unlike in previous interface formalisms, we introduce the notion of properties which captures the intent of the designer for the interaction between assumptions and guarantees.Moreover, properties can be used to steer the refinement of interfaces.It will be interesting to study the introduction of such design-guiding properties in the context of other interface languages.
As future work, we will explore how to extend our theory with sets of mustflows, i.e. support for modal specifications [27].This will enable, for example, to specify flows that a state q must implement so that the system can transition to a different state, which is useful to specify declassification of information.Another direction is to explore trace semantics for our interfaces.
or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material.If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Fig. 1 :
Fig. 1: Representation of the objects in our theory.

Definition 1 .
Let X and Y be disjoint sets of input and output variables, respectively, with Z = X ∪ Y the set of all variables.A stateless informationflow component is a tuple (X, Y, M), where M ⊆ Z × Y is a (reflexive and transitive) flow relation, called flows.A stateless information-flow interface is a tuple (X, Y, A, G, P), where: A ⊆ Z × X is a relation, called assumption; G ⊆ Z × Y is a relation, called guarantee; and P ⊆ Z × Y is a relation, called property.

Definition 4 .
An interface (X, Y, A, G, P) is well-formed iff A, G and P are no-flow relations; and the property is consistent, i.e. (A • G) ∩ P = ∅.Proposition 1.For all well-formed interfaces F = (X, Y, A, G, P), and for all components f = (X, Y, M) and f E = (Y, X, E): if f implements F , f |= F , and f E is an admissible environment of F , f E |= F , then their combined flows are consistent with the property of F , (M ∪ E) * ∩ P = ∅.

Definition 5 .
Let F = (X, Y, A, G, P) and F = (X , Y , A , G , P ) be two interfaces.Their composite flows are G F,F = G • G .The composite guarantees of F and F are defined as G F,F = (Z F,F ×Y F,F )\G F,F , also denoted by G F ⊗F .