Verification and Formal Methods : Practice and Experience

security policy model and the lower-level concrete architectural design, and to provide a formal proof of correspondence between the two, in order to show that the concrete design obeys the abstract security properties. The evaluation was carried out by the Logica Commercial Licenced Evaluation Facility, with key parts of the work subcontracted to the University of York to ensure independence. The target platform smartcard had an 8-bit microprocessor, a low clock speed, limited memory (256 bytes of dynamic RAM, and a few kilobytes of slower EEPROM), and no built-in operating system support for tasks such as memory management. Power could be withdrawn at any point during the processing of a transaction. Logica was contracted to deliver the specification and proof using Z [Spivey 1989; Woodcock and Davies 1996]. They had little difficulty in formalising the concrete architectural design from the existing semi-formal design documents, but the task of producing an abstract security policy model that both captured the desired security properties (in particular, that “no value is created” and that “all value is accounted for”) and provably corresponded to the lower-level specification, was much harder. A very small change in the design would have made the abstraction much easier, but was thought to be too expensive to implement, as the parallel implementation work was already well beyond that point. The 200-page proof was carried out by hand, and revealed a small flaw in one of the minor protocols; this was presented to platform seven in the form of a security-compromising scenario. Since this constituted a real security problem, the design was changed to rectify it. The extensive proofs that were carried out were done manually, a decision taken at the time to keep costs under control. Recent work (reported below) has shown that this was overly cautious, and that Moore’s Law has swung the balance further in favour of cost-effective mechanical verification. In 1999, Mondex achieved its ITSEC Level E6 certificate: the very first product ever to do so. As a part of the ITSEC E6 process, the entire Mondex development was additionally subject to rigorous testing, which was itself evaluated. No errors were found in any part of the system subjected to the use of formal methods. Mondex was revived in 2006 as a pilot project for the Grand Challenge in Verified Software (described further in Sect. 6). The main objective was to test how the state of the art in mechanical verification had moved on in ten years. Eight groups took up the challenge using the following formal methods: Alloy [Ramananandro 2008], ASM [Haneberg et al. 2008], Event-B [Butler and Yadav 2008], OCL [Kuhlmann and Gogolla 2008], PerfectDeveloper, π-calculus [Jones and Pierce 2007], Raise [George and Haxthausen 2008], Z [Freitas and Woodcock 2008]. The main results showed that mechanising the proof of correctness of Mondex was clearly within the state of the art in 2006. The cost of mechanising the Z proofs of the original project was 10% of the original development cost, and so did not dominate costs as initially believed. Interestingly, almost all techniques used in the Mondex pilot achieved the same level of automation, producing similar numbers of verification conditions and requiring similar effort. 4.4 Rockwell Collins Miller reports experiences from several formal methods projects carried out at Rockwell Collins [Miller 1998]. One of their earliest experiments was to specify and refine a micro Real Time Executive μRTE in the RAISE notation, RSL [RAISE Language ACM Computing Surveys, Vol. 41, No. N, June 2009. 20 · Woodcock et al. Verification & Formal Methods: Practice & Experience Group 1992; RAISE Method Group 1995]. This was not a successful a project: the language was thought to be too complex and required substantial training, and the only tools available were syntax and type checkers, with no support for developing and managing proofs. A subsequent experiment with SRI International, sponsored by NASA Langley [Miller and Srivas 1995; Srivas and Miller 1995], formally verified the microcode for the AAMP5 microprocessor using PVS [Owre et al. 1992]. The AAMP5 is a proprietary microprocessor widely used in Rockwell Collins products. It has a stack-based architecture, a large instruction set, makes extensive use of microcode, has a pipelined architecture, and complex processing units, such as a Lookahead Fetch Unit. It contains approximately 500,000 transistors and provides performance somewhere between an Intel 386 and 486. Rockwell Collins specified the AAMP5 at both the register transfer and instruction set level, with an abstraction function mapping between the two to prove the correctness of microcode instructions. The main lesson learned from the AAMP5 project was that it was technically possible to prove the correctness of microcode, and that their engineers can read and write formal specifications. Two errors were found in the AAMP5 microcode while creating the specification, and this convinced them that there is value in just writing a formal specification. But they also convinced themselves that mechanical proofs of correctness provide a very high level of assurance. They did this by seeding two very subtle errors in the microcode that they delivered to SRI, and then waiting to see if they would find them. SRI did indeed discover the errors using a systematic process: the only way not to have found the errors would have been to fail to carry out the proofs. The biggest problem for the AAMP5 project was that the cost was too high: more than 300 hours per instruction. This figure appears to have been inflated for a variety of reasons, including the steep learning curve using PVS for the first time and the need to develop many supporting application-oriented theories. They knew their costs would drop dramatically the next time around, but they could not predict by how much, so they undertook a second experiment [Miller et al. 1996], the verification of the microcode in the AAMP-FV, again sponsored by NASA and with SRI. The goal was to demonstrate dramatic reduction in cost through reuse of the AAMP5 infrastructure and expertise. Significantly, the AAMP-FV project confirmed that the expertise gained on the AAMP5 project could be exploited to dramatically reduce the cost of formal verification. Of the 80 AAMP-FV instructions, 54 were proven correct, and the cost of their verification dropped by almost an order of magnitude from that of the AAMP5 project. But as more complex instructions were attempted, proof techniques first developed on the AAMP5 project broke down and new approaches had to be devised. This phase progressed more as an exploratory project, with a steep learning curve and unexpected delays. One of the main contributions of the AAMPFV project was the development of methods to handle instructions with complex microcode. The latest project involves the AAMP7 processor, which has a separation kernel built into the micro-architecture. Rockwell carried out a proof in ACL2 that a lineby-line model of the microcode adheres to a security policy about how partitions ACM Computing Surveys, Vol. 41, No. N, June 2009. Woodcock et al. Verification & Formal Methods: Practice & Experience · 21 are allowed to communicate [Wilding et al. 2001; Greve and Wilding 2002]. What is hard about proofs of this kind is the complexity of dealing with pointer-laden data structures. The work received National Security Agency certification as a Multiple Independent Levels of Security device for use in cryptographic applications, at EAL-7 of the Common Criteria.