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

SLIDE 1

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

SLIDE 2

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

SLIDE 3

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

f object-oriented programs

Cassis 2004 – p.2

SLIDE 4

The KeY System

Verification Middleware Deduction Component Commercial CASE Tool Extension for formal specification UML Java OCL Dynamic Logic

Cassis 2004 – p.3

SLIDE 5

Verification Target

JAVA CARD/sequential JAVA source code
Highly expressive specification language (typed FOL)
Specification may be incomplete
No abstraction, full coverage of JAVA CARD features
Theorem prover may require interaction

Cassis 2004 – p.4

SLIDE 6

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

SLIDE 7

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

SLIDE 8

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

SLIDE 9

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

SLIDE 10

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

SLIDE 11

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

SLIDE 12

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

SLIDE 13

Dynamic Logic

Simple Example

card.balance .

= b ⊢ ⊢ ⊢

[card.charge(amount);] card.balance .

= b + amount

Cassis 2004 – p.9

SLIDE 14

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

SLIDE 15

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

SLIDE 16

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

SLIDE 17

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

SLIDE 18

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

SLIDE 19

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

SLIDE 20

Transactions: Example

this.a = 0; int i = 0; JCSystem.beginTransaction(); this.a = 1; i = this.a; JCSystem.abortTransaction(); Final State: this.a

. =

i

. =

1

Transactions even affect semantics of

·
, [·]: influence final state

Cassis 2004 – p.14

SLIDE 21

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

SLIDE 22

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

SLIDE 23

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

SLIDE 24

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

SLIDE 25

Specification Patterns

Data consistency is standard requirement Now have to write logFile.log.get(logFile.currentRecord).balance = balance

Cassis 2004 – p.18

SLIDE 26

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

SLIDE 27

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

SLIDE 28

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

SLIDE 29

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