Topics

1. Correctness by Construction:Developing a Commercial Secure System by Anthony Hall Roderick Chapman Computer Security: Art and Science

2. Topics • Introduction • Background • Development Approach • Formal Methods • Programming Languages and Static Analysis • The Use of SPARK in the CA • Results • Summary Computer Security: Art and Science

3. 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 Computer Security: Art and Science

4. 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. Computer Security: Art and Science

5. 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. Computer Security: Art and Science

6. The Development Approach Development deliverables grouped into the main process steps Computer Security: Art and Science

7. 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 Computer Security: Art and Science

8. 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 Computer Security: Art and Science

9. 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 Computer Security: Art and Science

10. 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 Computer Security: Art and Science

11. 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. Computer Security: Art and Science

12. 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 Computer Security: Art and Science

13. 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 Computer Security: Art and Science

14. 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. Computer Security: Art and Science

15. Results • Successful development • The delivered system satisfied its users, performed well, and was highly reliable • 100,000 lines of code. 0.04 defects per KLOC • Productivity-28 lines of code per day Computer Security: Art and Science

16. Results Computer Security: Art and Science

17. 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 ??? Computer Security: Art and Science