GC6: Dependable Systems Evolution
|
Status 2006The GC6 Steering Committee comprises Jim Woodcock (York, convenor), Cliff Jones (Newcastle), and Peter O’Hearn (Queen Mary). Much of our work is in collaboration with the International Grand Challenge in Verified Software. International Grand Challenge in Verified SoftwareThe International Grand Challenge in Verified Software is a long-term, coordinated programme of research addressing the theoretical, practical, technological, pedagogical, and sociological challenges facing large-scale software verification. Members of the UK Grand Challenge GC6 have been helping to define the International Challenge by developing a Research Roadmap. The key points of the Research Roadmap are summarised below.
GC6 Pilot ProjectsMondexOur major activity this year has been the year-long Mondex pilot project, which was launched in January 2006. Its main objectives were: (1) to demonstrate effective collaboration and competition amongst the verification community; (2) to generate artefacts to populate the Verified Software Repository; and (3) to assess the current state of proof mechanisation. The problem was to verify a key property of the Mondex smart card, an electronic purse hosted on a smart card. This product was developed to the high-assurance standard ITSEC Level E6 by a consortium led by NatWest, the UK high-street bank. Mondex purses interact using a communications device, and strong guarantees are needed that transactions are secure in spite of power failures and mischievous attacks. It must not be possible to counterfeit electronic cash. The problem is compounded by transactions being completely distributed: there is no centralised control, with all security measures being locally implemented with no real-time external audit logging or monitoring. The original verification was seriously security critical, so Logica and the University of Oxford used the Z notation for the development process. They constructed formal models of the overall system and an abstract security policy. They carried out proofs by hand that the system design possesses the security properties. The abstract security policy specification is about 20 pages of Z; the concrete specification (an n-step protocol) is about 60 pages; and the verification (suitable for external evaluation) is about 200 pages of refinement proof and 100 pages of derivation of refinement rules. The original proof was carefully structured for understanding, a fact much appreciated by the Mondex case study groups. The original hand proof was vital in getting the required certification; it was also useful in finding and evaluating different models. The original team made a key modelling discovery by finding an abstraction that gave a precise description of the security property and explained why the protocol is secure. The original proof revealed a bug in the implementation of a secondary protocol. The failed proof explained what had gone wrong, and provided a convincing counterexample that the protocol was flawed and gave the insight to correct the design. Third-party evaluators also found a bug: an undischarged assumption The sanitised version of the Mondex documentation is publicly available as Z specifications of security properties, abstract specification, intermediate-level design, concrete design, and rigorous correctness proofs of security and conformance. Originally, there was no question of mechanising proofs, as it was thought that mechanising such a large proof cost-effectively was beyond the state of the art. The challenge was to investigate the degree of automation that can now be achieved in the correctness proofs. Eight groups took up the challenge and started regular meetings to discuss their work. Teams represented Alloy (MIT), Event-B (Southampton), OCL (Bremen), PerfectDeveloper (Escher), ambient calculi (Newcastle), Raise (Macao/DTU), and Z (York). They agreed to work for one year, without funding. Meanwhile, separately and silently, a group in Augsburg began work using KIV and ASMs. Two distinct approaches emerged. The Archaeologists made as few changes as possible to the original documentation. They reasoned that they should not change the models just to make verification easier: how would they know that their results had anything to do with the original specification? The Technologists wanted to use the best proof technology now available, but these new tools do not work for Z. They had two choices: translate the existing models into new languages, or create new models better suited to new tools. The project demonstrated the following results.
Other GC6 Pilot ProjectsWork has started on a second pilot project: a space-flight file-store in collaboration with Rajeev Joshi and Gerard Holzmann at JPL. Other proposed pilot projects include domain modelling and verification of electronic voting systems and verification of key properties of an open-source web server. GC6 WorkshopsWe held the following workshops.
Papers Published
Meetings Organised
Conference Keynote Talks
GC6 Grant ProposalsEPSRC UK/China Network on Verified Software. Submitted, but rejected. The only feedback was as follows:
Tools and Guidelines for Preserving and Accessing Software Research Outputs. Application to JISC Repositories and Preservation Programme. Outline Project Description Many research outputs come in the form of software and its associated artefacts such as documentation, install scripts, test cases, tutorials, etc. This project will investigate issues around the deposition and preservation of software artefacts in repositories. It will develop guidelines for preservations of software research outputs, in particular, considering the appropriate use of existing software repositories such as sourceForge. It will develop these guidelines from the partners’ experience in running a number of software repositories and in particular by monitoring and analysing in detail the activities around a particular case study which is a thematic software repository in the software engineering domain. The project will focus particularly on:
More generic issues related to preservation of digital objects in general will not be considered here as they are well covered by other projects in this and other programmes. Meetings Planned
Other GC6 ActivitiesMailing list established. Wiki/Repository established. |
Contact: jim@cs.york.ac.uk Last updated: 6th December 2007 |