CONNIE HEITMEYER

Center for High Assurance Computer SystemsNaval Research Laboratory

Washington, DC

Workshop on the Verification Grand ChallengeSRI International

February 21-23, 2005

APPLICATIONSAPPLICATIONS

29/24/03

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

Applying SCR to the Fault Detection, Isolation and

Recovery (FDIR) Module of theThermal Radiator Rotary Joint Manager

(NASA’s Internat. Space Station)

Applying SCR to the Fault Detection, Isolation and

Recovery (FDIR) Module of theThermal Radiator Rotary Joint Manager

(NASA’s Internat. Space Station)

CONSISTENCY

CHECKER

SPECIFICATIONEDITOR

SIMULATOR

modes

events

mon vars

cont vars

conditionsterms

software requirements specification

49/24/03

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

59/24/03

EXAMPLE:APPLYING SCR TO THE FDIR MODULE

Source Mode Event Dest. ModeBlind @T(Blind_Ops_Timeout_Exceeded) WHEN

(Motor_Comm_AND_Status_Torque_Motor_OnAND NOT Inhibit_Time_Limit_BlindOps_Resp)

Shutdown

Autotrack @T(Pers_Autotrack_Failure_Exceeded) WHENNOT Inhibit_String_Fail_Autotrack_Response

Switchover

Autotrack @T(Pers_Autotrack_Failure_Exceeded) WHENInhibit_String_Fail_Autotrack_Response

Checkout

OriginalOriginalrequirementsrequirementsdocumentdocument• no explicit no explicit semanticssemantics• cannotcannot check check mech’lymech’ly

SCRSCRrequirementsrequirementsspecificationspecification• well-defined well-defined semanticssemantics• can apply toolscan apply tools

ID FailureCondition

Failure De-tection Phase

FailureCriteria

Persistence FailureNotif.

Recovery Response

Inhibit

1a Failure to Autotrack

Autotrack Mode

PosErr>=ThreshAutotrack_Err

Pers AutotrackFailure

CWAAutotrack or JointFailure

TransitionToSwitchover Mode

NOTInhibitStringAutotrack Resp

1b Failure to Autotrack

Autotrack Mode

PosErr>=ThreshAutotrack_Err

Pers AutotrackFailure

CWAAutotrack or JointFailure

1 Send PowerOff to SEPS2 Trans. to Checkout Mode

InhibitStringAutotrack Resp

… … … … … … … …

5 Blind OpTimeoutexceeded

Blind Mode &MotorComm & Status isTorque Motor On

Blind OpTime Dur >ThreshAutotrack_Err

None CWATimeLimitBlindOps

Trans. toShutdownMode

InhibitTime LimitBlindOps Resp

69/24/03

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 maintainedand the SCR tools used “under the hood” to expose defects

This is an example where the original tabular notion could be maintainedand the SCR tools used “under the hood” to expose defects

THEOREM PROVERTAME

INVARIANTGENERATOR

DEPENDENCYGRAPH BROWSER

SPECIFICATIONEDITOR

MODELCHECKER

system spec

CONSISTENCYCHECKER

modes

events

mon vars

cont vars

conditionsterms

SIMULATOR

APPLYING TAME/SCR TO THE SEP. KERNEL OFCD II, A MEMBER OF A

FAMILY OF SOFTWARE-BASED CRYPTO SYSTEMS

APPLYING TAME/SCR TO THE SEP. KERNEL OFCD II, A MEMBER OF A

FAMILY OF SOFTWARE-BASED CRYPTO SYSTEMS

89/24/03

To: To: …………From:From:…………Subj: ISR AssetsSubj: ISR Assets…………………………………………

CD

encryptencrypt

CD

decryptdecrypt

comm.comm.systemsystem

• 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

CDCD SERVICES

CD FAMILYCD FAMILY OFOF CRYPTOGRAPHIC DEVICES

CD: CCryptographicryptographic D Deviceevice

Each memberEach memberis implementedis implementedin handwarein handwareandand softwaresoftware

99/24/03

ChannelChannel

CHANNELCHANNEL ii CHANNEL CHANNEL jj

processprocessforfor

datadataencrypt/encrypt/decryptdecrypt

on on channel ichannel i

ded’dded’dmemorymemory

for for channel ichannel i

processprocessforfor

datadataencrypt/encrypt/decryptdecrypt

on on channel jchannel j

ded’dded’dmemorymemory

for for channel jchannel j

processprocessforfor

storingstoringsharedshared

algorithmsalgorithmsandandkeyskeys

sharedsharedmemorymemory

for for algs/keysalgs/keys

SHAREDSHARED

CD II

Red arrows show data flows that violate separation

1

2

3

WHAT SECURITY POLICY MUST CD II SATISFY?

Data on channel i is not influenced by data on channel j and vice versa Data on channel i is not influenced by data on channel j and vice versa

SECURITY POLICY: ENFORCE DATA SEPARATION

109/24/03

HOW TO OBTAIN ASSURANCE THAT CD II ENFORCES SEPARATION?

SHARED COMMANDSSHARED COMMANDS

DEDICATEDDEDICATEDchannel channel jj

SHAREDSHAREDDEDICATEDDEDICATED channelchannel ii

CHANNEL COMMANDSCHANNEL COMMANDS

The function of the Separation Kernel is to prevent illegal data flows.

SEPARATION KERNEL

SOLUTION: IMPLEMENT A “SEPARATION KERNEL”TO MEDIATE EVERY ACCESS TO MEMORY*

SOLUTION: IMPLEMENT A “SEPARATION KERNEL”TO MEDIATE EVERY ACCESS TO MEMORY*

**John Rushby,John Rushby, “Design and verification of secure systems,” “Design and verification of secure systems,” Proc. Proc. 8th Symp. on Operating System Principles, 8th Symp. on Operating System Principles, Pacific Grove, CA, Dec., 1981.Pacific Grove, CA, Dec., 1981.

119/24/03

• Develop a formal SECURITY POLICY MODEL to describe the CD II notion of data separation

• Produce ABSTRACT SPEC--a formal spec of the behavior of the CD II separation kernel (Use the style of [1])

• Prove that the ABSTRACT SPEC satisfies the SECURITY POLICY MODEL

• Produce CONCRETE SPEC-- a formal spec of the CD II implementation of the separation kernel

• Prove that the CONCRETE SPEC refines the ABSTRACT SPEC.

• Show that the CD II code (i.e., the implementation) satisfies the CONCRETE SPEC

SECURITY POLICY MODEL

ABSTRACT SPEC: spec of security-relevant behavior

CONCRETE SPEC: spec of security-relevant code

Prove ABSTRACT SPEC satisfies model

Show that CONCRETE SPEC correctly implements the ABSTRACT SPEC

Show that the CODE corresponds to the CONCRETE SPEC

CODE WALK-THROUGHCODE WALK-THROUGHTAME TOOL SUPPORTTAME TOOL SUPPORT

OBTAINING A HIGH ASSURANCE SEPARATION KERNEL

security-relevant CODE

[1] Landwehr, Heitmeyer, McLean, ACM TOCS, 1984.

?

129/24/03

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)