Version 02U-1 Computer Security: Art and Science1 Correctness by Construction: Developing a Commercial Secure System by Anthony Hall Roderick Chapman

Version 02U-1 Computer Security: Art and Science2 Topics Introduction Background Development Approach Formal Methods Programming Languages and Static Analysis The Use of SPARK in the CA Results Summary

Version 02U-1 Computer Security: Art and Science3 Introduction Correctness by construction is building correctness in every step of the development process. Correctness by construction demands Rigorous requirements definitions Precise system behavior specification Solid and verifiable design Code whose behavior is precisely understood

Version 02U-1 Computer Security: Art and Science4 Background Development of CA for the Multos smart card scheme on be half of Mondex International by Praxis Critical Systems The CA produces the necessary information to enable cards and signs certificates that permit application loading and deletion from Multos cards. Made use of COTS hardware and infrastructure software Development had to be in keeping with the UK Information technology Criteria Forced the customer and supplier to explicitly and unambiguously understand system requirements.

Version 02U-1 Computer Security: Art and Science5 The Development Approach Requirements Used requirements engineering methods, Reveal, to define CA’s environment and business objectives UR document consisted of context diagrams, class diagrams, structured operation definitions UR document included an informal security policy that identified assests, threats and countermeasures.

Version 02U-1 Computer Security: Art and Science6 The Development Approach Development deliverables grouped into the main process steps

Version 02U-1 Computer Security: Art and Science7 The Development Approach Specification and architecture Detailed system behavior specification System’s look and feel FTLS-functionality behind the interface High-level design Description of the System’s internal structure and intercomponent communication Aimed at ensuring satisfaction of security and throughput requirements

Version 02U-1 Computer Security: Art and Science8 The Development Approach Detailed Design Defined the set of software modules and processes and allocated the functionality across them. Used Z to specify the module that manages cryptographic keys and their verification on system startup. Code Used technologies fashionable at the time Avoided use of COTS as far as was practical Used Spark Ada to implement system’s security enforcing kernel

Version 02U-1 Computer Security: Art and Science9 The Development Approach Code Used Ada95 to implement the system’s infrastructure for instance, remote procedure call mechanisms and concurrency. Avoided security related functionality in GUI, implemented in C++ using MFC Used C to implement device drivers for cryptographic hardware. Enforced rigorous coding standards and reviewed all the code against these standards and relevant source documents such as FTLS and UIS. Used automatic static analysis tools where possible

Version 02U-1 Computer Security: Art and Science10 The Development Approach Verification and Validation Testing Incremental to-down build up of the system. Tests derived directly from the system specification. Ran the tests using Rational’s Visual Test Instrumented the code using IPL’s AdaTest to measure the statement and branch coverage achieved by the system tests. Devised extra design-based test scenarios where the system tests failed to cover parts of the code

Version 02U-1 Computer Security: Art and Science11 Formal Methods Formal top-level specification Used numerous schemas to capture each operation’s different security-relevant aspects. Used separate schemas to define each operation’s inputs, displayed information, and outputs Used separate schemas to define when an operation was valid or available.

Version 02U-1 Computer Security: Art and Science12 Formal Methods Process Design Modeled the process structure in the CSP language. Mapped sets of Z operations in the FTLS to CSP actions Introduced actions to represent interprocess communications The CSP model let check if the overall system was deadlock free and if there was no concurrent processing of security-critical functions

Version 02U-1 Computer Security: Art and Science13 Programming Languages and Static Analysis Conventional programming language Inherently ambiguous Favor dynamic behavior and performance over safety Inappropriate for static analysis Formal specification language Counter sloppy implementation Unambiguous Enables static analysis

Version 02U-1 Computer Security: Art and Science14 The Use of Spark in the CA Information flow-centered software architecture Maximizes cohesion and minimizes coupling Used both Spark and Ada95 for each compilation unit, on the basis of the required separation between security-related functions in the system. All Spark code had to pass through Spark Examiner with no unjustified warnings or errors before any other review or inspection activity Let reviewers focus on important topics such as Does this code implement the FTLS ? Used basic form of annotation and analysis offered by the Examiner.

Version 02U-1 Computer Security: Art and Science15 Results Successful development The delivered system satisfied its users, performed well, and was highly reliable 100,000 lines of code defects per KLOC Productivity-28 lines of code per day

Version 02U-1 Computer Security: Art and Science16 Results

Version 02U-1 Computer Security: Art and Science17 Summary A secure system can be built using insecure components, including COTS. Use formal methods when required. Formal methods reduce the number of late discovered errors and the over all system cost. Spark supports strong static analysis and proof of program properties which enables it to meet the CC requirements for formal development process. Questions/Comments ???