Verification of Safety Properties in Presence of Transactions - PowerPoint PPT Presentation

Verification of Safety Properties in Presence of Transactions Bernhard Beckert Reiner Hähnle Wojciech Mostowski Chalmers University of Technology http://www.key-project.org/ Cassis 2004 Marseille, March 2004 Cassis 2004 – p.1

Background: The KeY Project Formal methods must – and can – be integrated into commercially used methodologies, tools, and languages for software development Cassis 2004 – p.2

Background: The KeY Project Formal methods must – and can – be integrated into commercially used methodologies, tools, and languages for software development Integrated tool for modelling formal specification verification of object-oriented programs Cassis 2004 – p.2

The KeY System Extension Commercial for formal CASE Tool specification UML Java OCL Verification Middleware Dynamic Logic Deduction Component Cassis 2004 – p.3

Verification Target • J AVA C ARD /sequential J AVA source code • Highly expressive specification language (typed FOL) • Specification may be incomplete • No abstraction, full coverage of J AVA C ARD features • Theorem prover may require interaction Cassis 2004 – p.4

Java Class Requirement Specification • Class Invariant Restrict legal attribute values in each stable execution state • Method Contract For initial states satisfying precondition, implementation must guarantee postcondition after execution Cassis 2004 – p.5

Java Class Requirement Specification • Class Invariant Restrict legal attribute values in each stable execution state • Method Contract For initial states satisfying precondition, implementation must guarantee postcondition after execution Additional challenges in Java Card • Incomplete termination (card rip-out) • Intentional non-termination (controllers) Require finer granularity than stable state semantics Cassis 2004 – p.5

Java Card Safety Properties Safety Nothing bad will happen during execution (eg, when card is ripped out) Property (Example) Sensitive data must be in consistent state at all times Strong Invariant (s.a. Leino’s object invariant) Holds throughout program execution (in all intermediate states): [[ · ]] (throughout) modality Transaction Statements in scope of transaction executed completely or not at all Cassis 2004 – p.6

Dynamic Logic Intuitive rules and proofs (sequent calculus) Formulas contain programs (programs are first-class citizen, no encoding of programs as formulas) Cassis 2004 – p.7

Dynamic Logic Intuitive rules and proofs (sequent calculus) Formulas contain programs (programs are first-class citizen, no encoding of programs as formulas) Basic rules for each programming construct Applying rules corresponds to – symbolic execution and/or – simple (local) program transformation Cassis 2004 – p.7

Dynamic Logic Syntax Basis: typed first-order logic � � Modal operators [ p ] and � � p � � for each (Java-)program p , i.e., each executable piece of Java code Class/interface definitions are in separate context (not in p ) Cassis 2004 – p.8

Dynamic Logic Syntax Basis: typed first-order logic � � Modal operators [ p ] and � � p � � for each (Java-)program p , i.e., each executable piece of Java code Class/interface definitions are in separate context (not in p ) Semantics [ p ] F : If p terminates normally, then in its final state F holds (partial correctness) � � � p � � � F : p terminates normally and in its final state F holds (total correctness) Cassis 2004 – p.8

Dynamic Logic Simple Example card.balance . = b ⊢ ⊢ ⊢ [ card.charge(amount); ] card.balance . = b + amount Cassis 2004 – p.9

Throughout Modality Semantics [[ p ]] F : F holds in all states during the execution of p including the initial and the final state excluding states while a transaction is in progress Cassis 2004 – p.10

Throughout Modality Semantics [[ p ]] F : F holds in all states during the execution of p including the initial and the final state excluding states while a transaction is in progress Remarks • Related to always ✷ in temporal logic • Program p may contain statements that form transactions • Sequent calculus for [[ · ]] (Beckert & Mostowski, FASE 2003) Cassis 2004 – p.10

Proof Obligations Typical Proof Obligation involving throughout In KeY attach strong invariant to classes Let TOut be strong invariant of C Let Inv be (weak) invariant of C , Pre precondition of C :: m () Activating context-sensitive menu of method C :: m () in KeY (KeYExtension | Throughout Correctness | PreservesThroughout) Cassis 2004 – p.11

Proof Obligations Typical Proof Obligation involving throughout In KeY attach strong invariant to classes Let TOut be strong invariant of C Let Inv be (weak) invariant of C , Pre precondition of C :: m () Activating context-sensitive menu of method C :: m () in KeY (KeYExtension | Throughout Correctness | PreservesThroughout) Starts proof of ( TOut & Inv & Pre ) → [[ m ();]] TOut Cassis 2004 – p.11

Demo • Can prove strong invariant with proper initialization sequence • Cannot prove strong invariant with buggy initialization sequence Demo key/myprojects/cassisdemo/LogRecord.java::setrecord() Cassis 2004 – p.12

Transactions Transaction mechanism Allows the programmer to guarantee data consistency JCSystem.beginTransaction(); Assignments to persistent locations (only) are done preliminarily JCSystem.commitTransaction(); All preliminary assignments are finalised (in one atomic step) JCSystem.abortTransaction(); All preliminary updates are forgotten Cassis 2004 – p.13

Transactions: Example this.a = 0; int i = 0; JCSystem.beginTransaction(); this.a = 1; i = this.a; JCSystem.abortTransaction(); . this.a 0 Final State: = i . 1 = � � Transactions even affect semantics of � �·� � , [ · ] : influence final state Cassis 2004 – p.14

Demo Demo key/myprojects/cassisdemo/Client.java::processSale() Typical data consistency property: balance in current log entry and balance in application are in sync Cassis 2004 – p.15

How Realistic is the Example? Demoney: Realistic Java Card purse (demo) application (Trusted Logic) Our case study is similar to Demoney in several respects: Stores transaction log records (Demoney card spec p17) Stipulates consistency of persistent data (p18) Cassis 2004 – p.16

How Realistic is the Example? Demoney: Realistic Java Card purse (demo) application (Trusted Logic) Our case study is similar to Demoney in several respects: Stores transaction log records (Demoney card spec p17) Stipulates consistency of persistent data (p18) Major difference: In Demoney, one log record is single array of bytes For example, short balance : two fields within log record array Cassis 2004 – p.16

Design for Verification Storage optimization problematic for verification Record type encoded into homogeneous array, consequences: Comparison of values requires wrapping/unwrapping (Un)wrapping involves non-trivial Java modulo arithmetics Design for verification Represent data in object-oriented fashion Serialise objects only when necessary (for I/O) Decouple application from communication model (Krishna) Loosely coupled design likely to enable decomposable verification Cassis 2004 – p.17

Specification Patterns Data consistency is standard requirement Now have to write logFile.log.get(logFile.currentRecord).balance = balance Cassis 2004 – p.18

Specification Patterns Data consistency is standard requirement Now have to write logFile.log.get(logFile.currentRecord).balance = balance Instead would like to mark occurrences of balance in class diagram and say “prove data consistency” Cassis 2004 – p.18

Specification Patterns Data consistency is standard requirement Now have to write logFile.log.get(logFile.currentRecord).balance = balance Instead would like to mark occurrences of balance in class diagram and say “prove data consistency” Develop and implement library of specification patterns Good starting point (for security relevant properties): R. Marlet & D. Le Metayer. Security Properties and Java Card Specificities to be Studied in the SecSafe Project, 2001. SECSAFE-TL-006 Make tools accessible to non-experts (Leino, Vétillard) Cassis 2004 – p.18

Performance setRecord – 4 LoC processSale – 3 nested method calls, 15 LoC, transaction Time (sec) Steps Branches Nodes [[ setRecord ]] 3.0 238 29 251 � setRecord � 1.2 110 8 102 [[ processSale ]] 1 334.4 5929 224 4902 [[ processSale ]] 2 462.3 9838 578 8304 [[ processSale ]] 3 467.2 4820 269 4107 1 ideal arithmetic, no null pointer checks 2 ideal arithmetic, with null pointer checks 3 Java arithmetic, with null pointer checks Cassis 2004 – p.19

Summary • Safety properties of non-trivial Java Card programs verified automatically • Full coverage of Java Card features like transactions, aliasing, Java int , null pointer analysis, exception handling, object types, . . . • Speed can be improved (theorem provers, simplifiers, better indexing — work in progress) • Loops require non-trivial interaction But: most loops eg. in Demoney used for initialization • Design with verification in mind makes big difference Design patterns for to-be-verified code • Specification patterns help to create formal requirements • Mostly automatic verification of software like Demoney possible Cassis 2004 – p.20