GeneSyst: a Tool to Reason about Behavioral Aspects of B Event Specifications. Application to Security Properties.

arXiv:1004.1472v1 [cs.LO] 9 Apr 2010 GeneSyst: a Tool to Reason about Behavioral Aspects of B Event Specifications. Application to Security Properties⋆ Didier Bert, Marie-Laure Potet, and Nicolas Stouls Laboratoire Logiciels Syst`emes R´eseaux - LSR-IMAG - Grenoble, France {Didier.Bert, Marie-Laure.Potet, Nicolas.Stouls}@imag.fr Abstract. In this paper, we present a method and a tool to build sym- bolic labelled transition systems from B specifications. The tool, called GeneSyst, can take into account refinement levels and can visualize the decomposition of abstract states in concrete hierarchical states. The re- sulting symbolic transition system represents all the behaviors of the initial B event system. So, it can be used to reason about them. We il- lustrate the use of GeneSyst to check security properties on a model of electronic purse. 1 Introduction Formal methods, such as the B method [1], ensure that the development of an application is reliable and that properties expressed in the model are satisfied by the final program. However, they do not guarantee that this program fulfills the informal requirements, nor the needs of the customer. So, it is useful to propose several views about the specifications, in order to be sure that the initial model is suitable for the customer and that the development can continue on this basis. One of these important insights is the representation of the behavior of programs by means of diagrams (statecharts). Moreover, some particular views, if they are themselves formal, can provide new means to prove properties that cannot easily be checked in the first model. In this paper, we present a method and a tool to extract a labelled transition system from a model written in event-B. The transition system gives a graphical view and represents symbolically all the behaviors of the B model. The method is able to take into account refinement levels and to show the correspondence between abstract and concrete systems, by means of hierarchical states. We present also an application of this tool, namely, the verification of secu- rity properties. The security properties assert the occurrence or the absence of some particular events in some situation. They are a case of atomicity property of transactions. This is illustrated by an example of specification of an elec- tronic purse, called Demoney[16,15], developed in the SecSafe project [19]. This ⋆This work was done in the GECCOO project of program “ACI : S´ecurit´e Informa- tique” supported by the French Ministry of Research and New Technologies. It is also suported by CNRS and ST-Microelectronics by the way of a doctoral grant. case study, written in Java Card [21], is an applet that has all the facilities required by a real electronic purse. Indeed, the purse can be debited from a terminal in a shop, credited by cash or from a bank account with a terminal in a bank or managed from special terminal in bank restricted area. Transactions are encrypted if needed and different levels of security are used depending on the actions. Demoney also supports to communicate with another applet on the card, for example, to manage award points on a loyalty plan. The specification of Demoney is public in version 0.8 [16], but the source code is copyrighted by Trusted Logic S.A.1. In Section 2, we recall the main features of event-B systems and refinements. We introduce a notion of behavioral semantics by the way of sequences of events. In Section 3, we define symbolic labelled transition systems (SLTS) and the links between SLTS and event-B systems are stated. In Section 4, we present the GeneSyst tool and an example of generation of SLTS dealing with the error cases in the Demoney case study. Section 5 presents security properties required in the application and shows how the GeneSyst diagrams can be used to check these properties. Then, we review related works, and we conclude the paper with some research perspectives in Section 6. 2 Event-B 2.1 General presentation Event-B was introduced by J.-R. Abrial [2, 3]. It is a formal development method as well as a specification language. In event-B, components are composed of con- stant declarations (sets, constants, properties), state specification (vari- ables, invariant), initialisation and set of events. The events are defined by e b= eBody where e is the name of the event and eBody is a guarded generalized substitution [1]. The events do not take parameters and do not return result values. They do not get preconditions and do terminate. Their effect is only to modify the internal state. If S is a component, then we denote by Interface(S) the set of its events. A well-typed and well-defined component is consistent if initialization Init establishes the invariant of the component and if each event preserves the invari- ant. So, using the notation [S]R as the weakest precondition of R for substitution S, the consistency of a component is expressed by the proof obligations: [Init]I and I ⇒[eBody]I for each even

…(Full text truncated)…

This content is AI-processed based on ArXiv data.