The reactive simulatability (RSIM) framework for asynchronous systems

Michael Backes, Birgit Pfitzmann, Michael Waidner
2007 Information and Computation  
We define reactive simulatability for general asynchronous systems. Roughly, simulatability means that a real system implements an ideal system (specification) in a way that preserves security in a general cryptographic sense. Reactive means that the system can interact with its users multiple times, e.g., in many concurrent protocol runs or a multi-round game. In terms of distributed systems, reactive simulatability is a type of refinement that preserves particularly strong properties, in
more » ... cular confidentiality. A core feature of reactive simulatability is composability, i.e., the real system can be plugged in instead of the ideal system within arbitrary larger systems; this is shown in follow-up papers, and so is the preservation of many classes of individual security properties from the ideal to the real systems. A large part of this paper defines a suitable system model. It is based on probabilistic IO automata (PIOA) with two main new features: One is generic distributed scheduling. Important special cases are realistic adversarial scheduling, procedurecall-type scheduling among colocated system parts, and special schedulers such as for fairness, also in combinations. The other is the definition of the reactive runtime via a realization by Turing machines such that notions like polynomial-time are composable. The simple complexity of the transition functions of the automata is not composable. As specializations of this model we define security-specific concepts, in particular a separation between honest users and adversaries and several trust models. The benefit of IO automata as the main model, instead of only interactive Turing machines as usual in cryptographic multi-party computation, is that many cryptographic systems can be specified with an ideal system consisting of only one simple, deterministic IO automaton without any cryptographic objects, as many follow-up papers show. This enables the use of classic formal methods and automatic proof tools for proving larger distributed protocols and systems that use these cryptographic systems. The basic idea of reactive simulatability, sometimes abbreviated as RSIM, is to define under what conditions one system, typically a real cryptographic system, securely implements another system, typically a much simpler specification called ideal system. Roughly, we define that this is true if everything that can happen to the honest users of the real system, with strong real adversaries, can also happen to the same honest users if they use the ideal system, where adversaries do not occur or at least have far less power. What happens to the users includes the aspect of the adversary's knowledge about the users' behavior and secrets. Definitions of a real system implementing a specification are well-known in the field of distributed systems and often called refinement; however, normal refinement does not retain confidentiality properties and is therefore not suitable for most security systems, in particular for most cryptographic systems and protocols. For instance, if one defines an ideal secure channel essentially as a black box where messages are put in on one side and come out on the other side, normal notions of correct implementation by a distributed system allow that intermediate parties learn the messages. For security and cryptography, however, this should not happen if the ideal secure channel gives no information to such parties. In cryptography, a suitable notion of secure implementation, typically called simulatability, was already defined for ideal systems (specifications) that are just functions: each party makes one input at the beginning and obtains one output at the end. Essentially, we extend this notion to reactive systems, i.e., systems where parties may make inputs and obtain outputs at many different times. Examples of reactive cryptographic systems are multi-round auctions, protocols with many concurrent sessions, and untraceable electronic cash systems because whether a payment succeeds depends on prior cash withdrawal actions. For all these systems one requires confidentiality properties, so that the relation between a real system and a specification cannot only be the classical refinement of distributed systems. Reactive simulatability makes the real-and-ideal system specification technique available for such types of systems. An important property of reactive simulatability is composability. Roughly this means that a larger system can be defined based on the specification of a subsystem, in other words with an ideal subsystem, and then the real subsystem can be plugged in instead without causing any significant difference. The notion of "no significant difference" is again reactive simulatability. Composability is generally required of refinement relations in distributed systems. The idea of reactive simulatability has also become known as universal composability (UC) for such properties. (We describe the history of these terms and theorems in Section 1.7.) Reactive simulatability also offers property preservation, i.e., if one proves certain important properties of an ideal system, then they also hold for the real system. An example of such a property is that the participants in a payment system cannot spend more money than they put in initially or received. Such properties are not always trivial to show for an ideal system, but usually very much easier than if one had to do it directly for the real system. However, for length reasons of this first journal version with detailed definitions, we do not prove any composition and property preservation theorems here although the first ones were in the corresponding conference publication. Link to formal methods and tool-supported proofs As just explained, reactive simulatability with its notion of ideal systems is an important new way of specifying reactive cryptographic systems and protocols, besides the classical way of defining many individual properties, where each property immediately contains details about adversaries, polynomial-time considerations, and error probabilities. Besides this general motivation, a specific motivation for defining reactive simulatability was that it offers an important link between cryptography and formal methods, in particular automated proof tools such as model • S H := S * ∩ free([H]). •M H := {M H, |M ∈ H}, where M H, = (name M , Ports M H, , States M , M H, , l M , Ini M , Fin M ) is defined as follows: − The sequence Ports M H, is derived by the following algorithm. Ports M H, := ( ).
doi:10.1016/j.ic.2007.05.002 fatcat:r2vscqglnfcttcglezdwuvci4u