CONNIE HEITMEYER Center for High Assurance Computer Systems Naval Research Laboratory

1. APPLICATIONS CONNIE HEITMEYER Center for High Assurance Computer Systems Naval Research Laboratory Washington, DC Workshop on the Verification Grand Challenge SRI International February 21-23, 2005

2. APPLICATIONS TO PRACTICAL SYSTEMS • In May 2004, NASA Ames recommended the SCR tools for “improving software development practice at NASA” • Three applications of SCR to NASA applications (recently) • Fault Protection Engine, a software module present in current spacecraft and software currently under development for future spacecraft (Jet Propulsion Lab) • Failure Detection, Isolation & Recovery in Thermal Radiator Rotary Joint Manager Subsystem for the Intern. Space Station (with NASA IV&V Fac.) • Incubator Display software for the Space Station’s Fundamental Space Biology Mission • with NASA Ames Research Center/Intrinsyx Tech. Corp. (to begin in March 2005) • Application of TAME (some SCR) to the verification of the separation kernel of a software-based cryptographic device

3. Applying SCR to the Fault Detection, Isolation and Recovery (FDIR) Module of theThermal Radiator Rotary Joint Manager(NASA’s Internat. Space Station) SPECIFICATION EDITOR modes terms CONSISTENCY CHECKER conditions cont vars SIMULATOR events mon vars software requirements specification

4. APPLYING SCR TO THE FDIR MODULE(NRL AND NASA IV&V FACILITY) • System purpose: If certain events occur in a given mode, • Output a failure notification and/or • Sound one of two different alarms • Our task: Use SCR tools to detect and correct defects in existing requirements documentation • Available resources • Existing requirements documents • Tabular description of required software behavior • Finite state diagram of modes and events triggering mode transitions • Domain expert

5. EXAMPLE:APPLYING SCR TO THE FDIR MODULE • Original • requirements • document • no explicit • semantics • cannot • check • mech’ly • SCR • requirements • specification • well-defined • semantics • can apply tools

6. LESSONS LEARNED • While its semantics were implicit, the requirements documentation for the FDIR module was a good basis for developing the SCR requirements spec • The domain expert, a NASA contractor, told us how to interpret the tables and helped us fill in missing information • The original tabular spec already referred to several system modes and described transitions between modes • Hence, there was no need for us to “discover” the important system modes • The process of translating (some of) the requirements into an SCR requirements spec exposed two serious errors in less than one week’s time • The action required in two modes had been erroneously switched • The spec contained undesirable implementation bias • While tools did not detect these errors, the tools did help us (consistency checking and simulation) in debugging the SCR spec that we constructed • We subsequently taught a 2 1/2 day course on the SCR method and tools • Based on our experience in teaching the course and subsequent experience working with NASA contractors, it is clear that learning to develop high quality specs is very difficult This is an example where the original tabular notion could be maintained and the SCR tools used “under the hood” to expose defects

7. APPLYING TAME/SCR TO THE SEP. KERNEL OFCD II, A MEMBER OF A FAMILY OF SOFTWARE-BASED CRYPTO SYSTEMS

8. CD FAMILYOFCRYPTOGRAPHIC DEVICES encrypt decrypt C D C D To: …… From:…… Subj: ISR Assets ………… ………… comm. system CDSERVICES • Load and remove crypto algorithms and keys • Configure a channel with an algorithm and a key • Encrypt and decrypt data on a channel • Take emergency action when, e.g., device is tampered with • Provide the above services for m channels Each member is implemented in handware andsoftware CD:Cryptographic Device

9. WHAT SECURITY POLICY MUSTCD IISATISFY? 2 3 Red arrows show data flows that violate separation 1 CD II Channel SHARED CHANNELi CHANNEL j process for data encrypt/ decrypt on channel j process for data encrypt/ decrypt on channel i process for storing shared algorithms and keys ded’d memory for channel i ded’d memory for channel j shared memory for algs/keys SECURITY POLICY: ENFORCE DATA SEPARATION Data on channel i is not influenced by data on channel j and vice versa

10. HOW TO OBTAIN ASSURANCE THATCD IIENFORCES SEPARATION? SEPARATION KERNEL SOLUTION: IMPLEMENT A “SEPARATION KERNEL” TO MEDIATE EVERY ACCESS TO MEMORY* *John Rushby,“Design and verification of secure systems,” Proc. 8th Symp. on Operating System Principles, Pacific Grove, CA, Dec., 1981. DEDICATED channeli SHARED DEDICATED channel j SHARED COMMANDS CHANNEL COMMANDS The function of the Separation Kernel is to prevent illegal data flows.

11. Develop a formal SECURITY POLICY MODEL to describe theCD IInotion of data separation Produce ABSTRACT SPEC--a formal spec of the behavior of theCD IIseparation kernel(Use the style of [1]) ProvethattheABSTRACT SPEC satisfies the SECURITY POLICY MODEL Produce CONCRETE SPEC-- a formal spec of theCD IIimplementation of the separation kernel Prove that the CONCRETE SPEC refines the ABSTRACT SPEC. Show thattheCD IIcode(i.e., the implementation)satisfies theCONCRETE SPEC OBTAINING A HIGH ASSURANCE SEPARATION KERNEL Prove ABSTRACT SPEC satisfies model Show that CONCRETE SPEC correctly implements the ABSTRACT SPEC Show that the CODE corresponds to the CONCRETE SPEC SECURITY POLICY MODEL ABSTRACT SPEC: spec of security-relevant behavior ? CONCRETE SPEC: spec of security-relevant code security-relevant CODE TAME TOOL SUPPORT [1] Landwehr, Heitmeyer, McLean, ACM TOCS, 1984. CODE WALK-THROUGH

12. LESSONS LEARNED • Determining the precise meaning of data separation (e.g., what does “influence” mean) was challenging • Even more challenging was determining the separation-relevant behavior of the separation kernel • Determining the intended behavior of the kernel was hard • Useful mechanism for eliciting requirements -- scenarios • The SCR simulator was useful in constructing and debugging the spec that determines the kernel’s response to each input in the scenario • Hard part is the code verification -- e.g., demonstrating the correctness of the functions the kernel performs (e.g., loading the appropriate entry from the access matrix, properly performing sanitization)