Ownership types provide a statically enforceable notion of object-level encapsulation. We extend ownership types with computational e#ects to support reasoning about objectoriented programs. The ensuing system provides both access control and e#ects reporting. Based on this type system, we codify two formal systems for reasoning about aliasing and the disjointness of computational e#ects. The first can be used to prove that evaluation of two expressions will never lead to aliases, while the latter can be used to show the non-interference of two expressions.

This paper distinguishes several different approaches to organising a Weakest Precondition (WP) calculus in a theorem prover. The implementation of two of these approaches for Java within the LOOP project is described. This involves the WP-infrastructures in the higher order logic of the theorem prover PVS, together with some associated rules and strategies for automatically proving JML specifications for Java implementations. The soundness of all WP-rules has been proven on the basis of the underlying Java semantics. These WP-calculi are integrated with the existing Hoare logic, and together form a verification toolkit in PVS: typically one uses Hoare logic rules to break a large verification task up into smaller parts that can be handled automatically by one of the WP-strategies.

This paper discusses a verification in PVS of the AID (Application Identifier) class from the JavaCard API. The properties that are verified are formulated in the interface specification language JML. This language is also used to express the properties that are assumed about the native methods from the Util class that are used in the AID class. These properties include invariants for classes and behaviour specifications for methods; the latter give pre- and post-conditions describing the functional behaviour, and also specify when exceptions may be thrown.

This paper extends PVS's standard bitvector library with multiplication, division and remainder operations, together with associated results. This extension is needed to give appropriate semantics to Java's integral types in program verification. Special emphasis is therefore put on Java's widening and narrowing functions in relation to the newly defined operations on bitvectors.

The next generation of smart cards will be used for services where security is a key issue. Reliability and trust are necessary for a large scale adoption and success of these smart cards. New validation techniques are needed, based on well-defined mathematical models, using special tools for mathematically proving correctness, going well beyond testing. A EU-funded consortium `VerifiCard' of 5 academic and 2 industrial partners, coordinated by Nijmegen, will work on the correctness of crucial components of the chosen (JavaCard) platform and of individual applications. This brief note will give an introduction to smart cards and their importance in computer science today. Additionally, it will give an impression of the work done in Nijmegen on these topics.

Abstract. The Java dialect Java Card for programming smartcards contains some features which do not exist in Java. Java Card distinguishes persistent and transient data (data stored in EEPROM and RAM, respectively). Because power to a smartcard can suddenly be interrupted by a so-called card tear, by someone removing the smartcard from the reader, Java Card provides a notion of transaction to ensure that updates of multiple fields in persistent memory can be performed atomically. This paper describes a way to reason about these Java Card specific language features. 1

This abstract provides some background information on smart cards, and explains the challenges these cards represent for formal verification of software.

JavaCard is a variant of the Java programming language specifically designed for use on Smart Cards. In order to support the secure execution of several different applets on a Smart Card, the JavaCard Virtual Machine implements a firewall that isolates applets from each other by preventing unwanted information sharing and communication between applets.