SCR: A Practical Approach to Building a High Assurance COMSEC System

SCR: A Practical Approach toBuilding a High Assurance COMSEC System�To be presented at ACSAC '99, Phoenix, AZ, December 6-10, 1999James Kirby, Jr. Myla Archer Constance HeitmeyerCode 5546, Naval Research Laboratory, Washington, DC 20375fkirby, archer, [email protected] date, the tabular-based SCR (Software Cost Re-duction) method has been applied mostly to the devel-opment of embedded control systems. This paper de-scribes the successful application of the SCR method,including the SCR* toolset, to a di�erent class of sys-tem, a COMSEC (Communications Security) devicecalled CD that must correctly manage encrypted com-munications. The paper summarizes how the tools inSCR* were used to validate and to debug the SCR spec-i�cation and to demonstrate that the speci�cation sat-is�es a set of critical security properties. The devel-opment of the CD speci�cation involved many tools inSCR*: a speci�cation editor, a consistency checker, asimulator, the TAME interface to the theorem proverPVS, and various other analysis tools. Our experienceprovides evidence that use of the SCR* toolset to de-velop high-quality requirements speci�cations of moder-ately complex COMSEC systems is both practical andlow-cost.1 IntroductionCOMSEC (Communications Security) devices, de-vices which manage encrypted communications, arevital to the correct operation of U.S. military sys-tems. CD, the COMSEC device of interest in thispaper, is designed to provide cryptographic processingfor a U.S. Navy radio receiver. In addition to generat-ing keystreams compatible with another cryptographicdevice and supporting multiple channels and multiplecryptographic algorithms, CD downloads associated al-gorithms and keys into working storage, assigns themto designated communication channels, maintains theassociation between an algorithm and its keys, andclears algorithms and keys from memory. CD, basedon a technology called PEIP (Programmable, Embed-dable INFOSEC Product) for implementing COMSECdevices in software as well as hardware, presents anew challenge in the development of COMSEC devices.While a solid base of experience exists for implement-ing trustworthy COMSEC devices in hardware, imple-�This work is funded by ONR. For related work, seehttp://www.chacs.itd.nrl.navy.mil/SCR.

menting COMSEC devices in software is rare.During the last decade, numerous formal methods,many with automated support, have been proposed fordeveloping high assurance software systems. Becausestudies (e.g., [6]) show that errors, such as securityproperty violations, that are introduced early in systemdevelopment are both the most common and the mostexpensive to �x, the goal of many formal methods isto discover and eliminate aws during the early stagesof system development. While mechanically supportedformal methods hold great promise for identifying er-rors early, the exceptional user expertise and e�ort usu-ally required to apply them present a major barrier totheir use in the development of practical systems.The SCR (Software Cost Reduction) method [15,11] is a formal method which o�ers a user-friendly tab-ular notation for specifying system requirements, anda set of tools called SCR* for detecting, often auto-matically, aws in the requirements speci�cation. Al-though originally designed to specify the requirementsof safety-critical control systems, SCR can also be usedto specify the required behavior of other systems, suchas COMSEC systems. To make SCR* useful to prac-titioners, the tools are designed to be as automatic aspossible and to complement and support one another.Included among the tools in SCR* are an automatedconsistency checker, a simulator, and various veri�ca-tion tools.To provide a high degree of assurance in the correct-ness of CD's speci�cation, we have applied the SCRmethod, including the SCR* tools [12, 13, 11]. Ourresults suggest that applying the SCR method in thedevelopment of COMSEC devices of moderate size andcomplexity is practical, e�ective, and low-cost. In ap-proximately one person-month, we were able to repre-sent a signi�cant subset of a prose requirements doc-ument for CD in the the SCR notation and to estab-lish that the SCR speci�cation satis�es a set of se-curity properties. The product of this e�ort is a high-quality requirements speci�cation in whose correctnesswe have a high degree of con�dence. This requirementsspeci�cation can guide both the development of thesource code and the development of test sets for eval-1

uating the conformance of the source code with thesystem requirements.The paper is organized as follows. It �rst introducesthe SCR method and the SCR* toolset in Section 2,and then describes in Section 3 how the tools were ap-plied to CD. Section 4 discusses the results of apply-ing SCR* to the CD speci�cation. Finally, section 5discusses related work, and Section 6 presents our con-clusions.2 The SCR Method and ToolsThe SCR method is a formal method designed tospecify and analyze the requirements of safety-criticalcontrol systems. Since its introduction in 1978, theSCR requirements method has been applied success-fully to a wide range of critical systems, includingavionics systems, space systems, telephone networks,and control systems for nuclear power plants. See,e.g., [15, 23, 8, 7, 22, 19].An SCR requirements speci�cation describes boththe system environment, which is nondeterministic,and the required system behavior, which is usuallydeterministic [12, 14]. Quantities in the environmentthat the system monitors and controls are representedby monitored and controlled variables. SCR speci�-cations also use two types of auxiliary variables: modeclasses (whose values are calledmodes) and terms, bothof which often capture historical information. In theSCR model, the system environment nondeterministi-cally produces a sequence of input events, where an in-put event is a change in some monitored quantity. Thesystem is represented as a state machine (i.e., automa-ton) whose current state is determined by the valuesof the state variables, where a state variable is eithera monitored or controlled variable, a mode class, ora term. Executions of the system begin in some ini-tial state, after which the system responds to each in-put event in turn by changing state and by producingzero or more output events, where an output event is achange in a controlled quantity. The system behavioris assumed to be synchronous: the system completelyprocesses one input event before the next input eventis processed.An SCR speci�cation de�nes the transitions of asystem using of a set of tables. Each table describesthe value of a given state variable in the new state.Each dependent variable, i.e., each controlled variable,term, and mode class, has a corresponding table. Twoconstructs used in the tables are conditions and events.A condition is a predicate on system states. An eventoccurs when the value of any variable changes. Thenotation \@T(c) WHEN d" denotes a conditioned eventde�ned as @T(c) WHEN d def= :c ^ c0 ^ d;

where the unprimed conditions c and d are evaluatedin the \old" state, and the primed condition c0 is eval-uated in the \new" state. Informally, this denotes theevent \predicate c becomes true in the new state whenpredicate d holds in the old state". The table for amode class is a mode transition table, which maps asource mode and an event to a destination mode. Thetable for any term or controlled variable is either anevent table, which maps conditioned events to valuesof the variable in the next state, or a condition table,which maps conditions on the next state to values ofthe variable in the next state.In addition to tables, an SCR speci�cation containsdictionaries of types, variable declarations, constantdeclarations, environmental assumptions, and speci�-cation assertions. The speci�cation assertion dictio-nary records required system properties, e.g., securityproperties. Our experience with practical systems isthat most system properties can be represented as ei-ther state invariants or transition invariants, where astate invariant is a property that holds in every reach-able state and a transition invariant is a property thatholds in every reachable prestate/poststate pair (i.e.,reachable transition).The SCR* toolset [12, 13, 11] is a set of softwaretools developed by NRL to provide mechanized sup-port for the SCR method. The tools include a speci�-cation editor for creating and modifying both an opera-tional requirements speci�cation (i.e., a state-machinerepresentation of the required behavior) and a set ofproperties, such as safety and security properties; adependency graph browser to display the dependenciesamong the variables in the speci�cation; an automatedconsistency checker to expose missing cases, unwantednondeterminism, and other application-independenterrors [12]; a simulator to allow users to validate thespeci�cation; an interface to the model checker Spin[16] to detect violations of critical application prop-erties; and an invariant generator [18] that computesstate invariants from an SCR speci�cation. To provideformal underpinnings for the tools and for the anal-ysis techniques the tools implement, a formal modelde�nes the semantics of SCR requirements speci�ca-tions [14, 12].Several additional tools have been recently inte-grated with SCR* by automatically translating theinternal representation of an SCR speci�cation intothe input languages of the tools. These tools in-clude TAME (Timed Automata Modeling Environ-ment) [1, 2], an interface to the theorem prover PVS[25] for proving properties of automata models, a va-lidity checker [4] which uses an integrated set of deci-sion procedures to automatically check whether a given2

property is a state or transition invariant of an SCRspeci�cation, and a test set generator [9] that automat-ically generates test sets from an SCR speci�cation.3 Applying SCR* to CDThis section describes the translation of a subset ofthe prose speci�cation provided by the CD developersinto an SCR speci�cation and the results of applyingthe SCR* tools to the SCR speci�cation. The tools andanalysis techniques that were applied include the con-sistency checker, simulator, invariant generator, Spin,TAME, and the validity checker. This section also de-scribes our plan to use the SCR* testing tool to auto-matically construct test sets from the SCR speci�ca-tion of CD.3.1 From Prose to SCR RequirementsTo develop the SCR speci�cation, we studied theCD Systems Requirement Document (SRD) providedby the CD project manager, focusing on the constraintsit imposed on the required system behavior and repre-senting those constraints using SCR constructs. TheCD SRD, a traditional 2167A-style document, was suf-�ciently precise and complete about key and algorithmmanagement, modes of operation, and security require-ments relating to power, tampering, and zeroizing forus to capture the required behavior in the SCR speci-�cation of CD. We obtained security properties by ex-amining the SCR speci�cation and surmising the goalsof the required behavior and by interpreting descrip-tions of functions in the CD SRD as security require-ments. The CD project manager has reviewed theset of security properties that we formulated and con-�rmed that, except for one, they are reasonable se-curity properties of CD. The exception, according tothe project manager, was a property whose hypothesis(backup power is over voltage), would never be satis-�ed.Our SCR speci�cation describes the part of CD's be-havior (as described in the SRD) that is consistent withthe SCR model of black-box requirements. In SCR,the CD behavior is described in terms of inputs (thestatus of primary and backup power, data provided bythe host, and positions of switches), outputs (indicatorlights and status messages), and modes. In addition,our speci�cation describes some memory managementbehavior that goes beyond SCR's usual modeling ofblack-box requirements. Usually, in SCR, memory isconsidered to be internal to the black box, and thusinvisible from the outside, but we treat it as externallyvisible by de�ning controlled variables that representthe memory locations in which the CD software canstore algorithms and keys. This memory managementbehavior models the rules in the CD SRD for loadingalgorithms and keys, associating them with channels,

and clearing them from memory. There is (intention-ally) not enough information in the CD SRD to specifythe rules for cryptographic synchronization and gener-ating keystreams. As a result, our SCR speci�cationomits some required behavior that would be relevantand useful to reason about.The CD SRD assumes that an unlimited number ofalgorithms and keys can be distributed among an un-speci�ed number of storage locations and an unspec-i�ed number of channels. In the SCR speci�cation,we assume that there are two key banks, each withtwo key storage locations; at most 1,000 di�erent al-gorithms and 1,000 di�erent keys; and two channels.The SCR CD speci�cation has one more mode thandescribed in the CD SRD: we add an O� mode so thatthe system is always in exactly one mode.

Figure 1. Full dependency graph for SCR CD.Our SCR speci�cation contains 39 variables|17monitored variables, one mode class, two terms, and19 controlled variables. Figure 1 shows the variabledependency graph for the complete SCR speci�cationof CD. Variables are represented as boxes, and an ar-row from one variable to a second variable indicatesthat the value of the �rst variable in the new statedepends on the value of the second variable in eitherthe current state or the new state. The heavy linesare backarrows; the number of backarrows re ects thecomplexity of the dependencies among the variables,which is also re ected in the complexities of the tables.Although this graph has cycles, the SCR* consistencychecker was used to assure that there were no circu-lar dependencies among the \new-state" variables (seeSection 3.2).Most of the e�ort spent in building the SCR speci�-cation of CD took place as a background activity overa nine-month period. The initial build of the speci�ca-3

tion required approximately one person-week. Aboutone additional person-week was needed to re�ne andcomplete the speci�cation, with frequent use of theconsistency checker (see Section 3.2).3.2 Applying the Consistency CheckerThe consistency checker uses static analysis tech-niques to expose syntax and type errors, variable namediscrepancies, unwanted nondeterminism (called dis-jointness errors), missing cases (called coverage er-rors), and circular de�nitions (i.e., cycles in the de-pendencies among new-state variables). The checksare fully automatic and thus require no user inputor guidance. When an error is detected, the consis-tency checker facilitates error correction by providingdetailed feedback. For some types of errors (e.g., dis-jointness and coverage errors), the checker, in additionto describing the error, will highlight where in the spec-i�cation the error occurs, and display a transition orstate that demonstrates the error.The consistency checker may be used at any stage inthe development of a speci�cation. All checks, exceptthose for missing cases and nondeterminism, executein a few seconds and are typically invoked many timesduring an editing session. In developing the CD spec-i�cation, we frequently used the less expensive consis-tency checks as \sanity" checks. Since applying themore expensive checks for missing cases and nondeter-minism to the entire CD speci�cation usually requiresbetween �ve and nine minutes, we invoked these checksless frequently.iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Error Message from Tool SCR* Highlights Diagnosisiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii‘‘smOperation Mode Transition Table: Name of mode Events in tableCycle Detection ERROR: Cycle #1: class in mode for smOperationTable smOperation uses mode class transition table introduce a cycle insmOperation in the Name field; Function the new state variableis smOperation Mode Transition Table’’ dependenciesiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiic

ccccccc

cccccccc

cccccccc

cccccccc

Figure 2. Consistency checker feedback.Figure 2 gives an example of an error message gen-erated by the consistency checker during our develop-ment of the SCR speci�cation of CD. The �rst columngives the error message displayed by the tool. The sec-ond and third columns describe the part of the spec-i�cation that is highlighted at user request and ourdiagnosis of the error. In this example, the error isa circular de�nition, i.e., a cycle among the new statedependencies. This cycle occurred on our �rst attemptto describe CD's mode transitions in cases where theprose requirements described entry into a mode as ulti-mately resulting in exit from that mode to some othermode.3.3 Simulating the CD Speci�cationIn contrast to other tools in SCR*, which are forveri�cation, the simulator is a tool for validation. The

purpose of veri�cation is to prove that the speci�ca-tion satis�es selected system properties, such as stateand transition invariants; the purpose of validation isto con�rm that the speci�cation captures the opera-tional system behavior intended by the customer. Thesimulator permits application experts to validate thebehavior de�ned by the speci�cation before the systemis built. They can do so by running scenarios throughthe simulator rather than by reading the detailed SCRspeci�cation.A scenario is a sequence of input events, each ofwhich assigns a new value to one of the monitored vari-ables. For each input event in the sequence, the sim-ulator updates the values of the dependent variablesbefore processing the next input event. In addition topresenting the current state of the execution, the simu-lator can present a history of the execution and reportwhen a scenario violates speci�ed properties.The simulator's standard generic interface presentsthe current state of an execution in terms of the currentvalues of the state variables, i.e., the monitored vari-ables, mode classes, terms, and controlled variables. Adisadvantage of the generic interface is that it presentsan abstract description of the system state that appli-cation experts �nd unnatural. To overcome this prob-lem, the simulator supports the rapid construction ofgraphical front-ends customized for particular appli-cations. Each application-speci�c front-end containsgraphical representations of switches, indicator lights,dials, and other entities in the human-computer inter-face that, in contrast to the generic interface, clearlyand directly communicate information about the sys-tem behavior to the user.We found an application-speci�c front-end for CDuseful in interacting with the CD project manager. Af-ter viewing a simulation of CD using the CD-speci�cfront-end (built in less than a day), the CD projectmanager provided us with useful feedback on the SCRspeci�cation of the CD. Thus, evaluation of the CDspeci�cation through this front-end to the simulatorallowed a very e�ective use of a very scarce commod-ity, the project manager's time.3.4 Automatic Invariant GenerationThe SCR* invariant generator is based on an algo-rithm for constructing state invariants from the func-tions de�ning the dependent variables. Consider a de-pendent variable v, de�ned by a mode transition tableor an event table, which takes values in a �nite setfa1; a2; : : : ; ang. The algorithm examines the condi-tions that can cause the value of variable v to changeand generates for each ai an invariant of the form(v = ai)) Ci;4

where Ci is a predicate de�ned in terms of variableson which v depends. When v can take values in avery large (even in�nite) set, the hypotheses v = ai arereplaced by predicates de�ning a �nite partition on therange of v; for example, when v has a numeric value,each predicate will de�ne an interval. The appropriateintervals can often be computed automatically fromthe speci�cation by identifying the values with whichv is compared.The automatic invariant generator currently pro-vided in SCR* partially implements the algorithmfor generating invariants from a mode transition ta-ble. The full algorithm, which we currently executeby hand, includes methods for generating invariantsfrom event tables and condition tables and a strength-ened method for mode transition tables; it will ulti-mately be implemented in SCR*. Figure 3 lists thenontrivial invariants that were generated automaticallyfrom the mode transition table for the CD mode classsmOperation.iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiNo. Description Generated Invariantiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii1 In Idle mode, the system smOperation = sIdle

is healthy and backup power ⇒ mHealthyBackground ANDis not overvoltage mBackupPower =/ overvoltageiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

2 In Standby mode, smOperation = sStandbybackup power is neither ⇒ mBackupPower =/ undervoltage ANDundervoltage nor unavailable mBackupPower =/ unavailableiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

3 In Traffic Processing mode, smOperation = sTrafficProcessingthe system is healthy and ⇒ mHealthyBackground ANDbackup power is not overvoltage mBackupPower =/ overvoltageiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

4 In Configuration mode, smOperation = sConfigurationthe system is healthy and ⇒ mHealthyBackground ANDbackup power is not overvoltage mBackupPower =/ overvoltageiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiicc

cccccccccccccccc

cccccccccccccccccc

cccccccccccccccccc

cccccccccccccccccc

Figure 3. Nontrivial invariants generated au-tomatically for the mode class smOperation.Although the invariants generated from the speci�-cation are not the strongest possible invariants, theyare often su�cient to establish interesting safety prop-erties [18]. While applying the full invariant genera-tion algorithm to CD did not provide results su�cientby themselves to establish the security properties wewished to verify, the generated invariants did play anextremely useful role: they provided every auxiliarylemma we needed to complete the proofs of all valid se-curity properties that we investigated. Although thereis no guarantee that this will always happen, that itdid happen for CD suggests that applying invariantgeneration is a useful �rst step in verifying a set ofproperties, particularly since, once the full algorithmis implemented in SCR*, invariant generation will befully automatic.Three of the seven properties that we analyzed couldnot be proven automatically with either TAME or theSCR* validity checker (see Sections 3.6 and 3.7). Toprove these properties, a total of �ve auxiliary invari-

ants were needed. Of these �ve invariants, which arelisted in Figure 4, invariants 1A, 2A, and 3A can bederived from invariants generated by the implementedalgorithm. For example, invariant 1A is implied byinvariant 4 in Figure 3, one of the invariants gener-ated automatically from the mode transition table forsmOperation. Invariant 4A follows immediately fromadditional invariants which were generated by hand us-ing the strengthened algorithm for mode transition ta-bles. The contrapositive of invariant 5A is generatedby applying the algorithm by hand to the event tablede�ning the integer-valued variable cKeyBank1Key1.iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

No. Description Auxiliary Invariantiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii1A In Configuration mode, backup smOperation = sConfiguration

power is not overvoltage ⇒ mBackupPower =/ overvoltageiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii2A In Idle mode, backup smOperation = sIdle

power is not overvoltage ⇒ mBackupPower =/ overvoltageiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii3A In Traffic Processing mode, backup smOperation = sTrafficProcessing

power is not overvoltage ⇒ mBackupPower =/ overvoltageiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii4A If primary power is unavailable, mPrimaryPower = unavailable

then CD is in Standby, Alarm, ⇒ (smOperation = sStandbyor Off mode or smOperation = sAlarm

or smOperation = sOff)iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii5A If CD is in Off mode, smOperation = sOff

then key 1 in keybank 1 is 0 ⇒ cKeyBank1Key1 = 0iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiicccccccccccccccccc

cccccccccccccccccc

cccccccccccccccccc

cccccccccccccccccc

Figure 4. Auxiliary invariants needed for CD.3.5 Model Checking PropertiesWhen, as in SCR, a software speci�cation describesa �nite-state automaton, one can model check its prop-erties. Model checking performs an exhaustive searchof the state space of the automaton. If the num-ber of state variables is large, and particularly if|asis common in software speci�cations|the individualvariables take values in a large (even in�nite) set, thestate space can become so large that direct exhaus-tive search of the entire space is di�cult or impossible.This problem, referred to as the state explosion prob-lem, can often be alleviated by abstraction.For SCR*, we have developed automatable abstrac-tion methods that reduce the state space either byeliminating variables irrelevant to a property (variablerestriction) or by reducing the range of variable val-ues (variable abstraction) [5, 11]. When, as often hap-pens, even abstraction does not allow the state space tobe searched exhaustively, a partial search of the statespace can often �nd states that violate a speci�ed prop-erty. In addition to �nding property violations, mostmodel checkers produce counterexamples in the formof scenarios (i.e., execution sequences) that lead to thebad state. Below, we refer to counterexample scenariossimply as counterexamples.Since model checking is largely automatic, using amodel checker to check the validity of a property beforetrying to establish the property with a theorem prover5

is often a useful screening strategy. If Spin �nds aviolation, it produces a counterexample, thus savingthe e�ort needed to generate a counterexample froma dead-end in a proof. In checking security propertiesfor CD, we followed this strategy.iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

No. Description Propertyiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii1 If CD is tampered with, then @T(mTamper)

key 1 in keybank 1 is zeroized ⇒ cKeyBank1Key1′ = 0iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii2 When the zeroize switch is activated, @T(mZeroizeSwitch = on)

key 1 in keybank 1 is zeroized ⇒ cKeyBank1Key1′ = 0iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii3 No key can be stored in location 1 cKeyBank1Key1 =/ 0

of keybank 1 before an algorithm ⇒ cAlgStoreSegment1 =/ 0has been loaded into the first locationof algorithm storage segment 1iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

4 If backup power has an undervoltage @T(mBackupPower = undervoltage)when primary power is unavailable, WHEN mPrimaryPower = unavailablethe CD enters either Alarm mode or ⇒ smOperation′ = sAlarmOff mode OR smOperation′ = sOffiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

5 If backup power is overvoltage mBackupPower = overvoltagethen the CD is in Initialization, ⇒ smOperation = sInitializationStandby, Alarm, or Off mode OR smOperation = sStandby

OR smOperation = sAlarmOR smOperation = sOffiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

6 If primary power has an overvoltage @T(mPrimaryPower) = overvoltagethen either the CD is in Initialization, ⇒ smOperation = sStandbyStandby, Alarm, or Off mode, or the CD OR smOperation = sAlarmenters Initialization mode OR smOperation = sOff

OR smOperation′ = sInitializationiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii7 If primary power has an undervoltage @T(mPrimaryPower) = undervoltage

then either the CD is in Initialization, ⇒ smOperation = sStandbyStandby, Alarm, or Off mode, or the CD OR smOperation = sAlarmenters Initialization mode OR smOperation = sOff

OR smOperation′ = sInitializationiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiccccccccccccccccccccccccccccccccccccc

ccccccccccccccccccccccccccccccccccccc

ccccccccccccccccccccccccccccccccccccc

ccccccccccccccccccccccccccccccccccccc

Figure 5. Sample true properties for SCR CD.Figure 5 lists seven security properties that theSCR speci�cation of CD satis�es. Before we triedto prove any CD security property with TAME (seeSection 3.6), we �rst used the Spin model checker tosearch for violations of the property. For each property,we used SCR* to automatically extract an abstrac-tion from the CD speci�cation and the property, us-ing the variable restriction method described in [5, 11]to remove all variables irrelevant to the validity of theproperty. Then, by hand, we applied the variable ab-straction method described in [11]. By limiting therange of values that certain variables can assume, thismethod usually produces a smaller abstraction. In ourCD study, the abstractions for di�erent properties var-ied very little. A typical abstraction contained 28 vari-ables, a reduction of 28% from the 39 variables in thecomplete SCR speci�cation.Using Spin, we discovered a few property violations.In each case, closer examination of the property showedthat the formulation of the property was incorrect. Asone would expect, model checking was unable to �ndany violations of the properties subsequently veri�edby theorem proving. Because the model checker ranout of memory before the analysis was complete, wewere unable to search the complete state space of any ofthe abstract speci�cations and therefore to verify anyof the properties listed in Figure 5. The importance

of the theorem proving phase was demonstrated whenwe were able to use theorem proving both to provethat certain properties were invariants and to establishthat one property for which Spin was unable to �nd aviolation is not an invariant (see below).3.6 Checking Properties with TAMEThe tool TAME provides an interface to PVS forproving properties of automata models. TAME's goalis to reduce the human e�ort required in using PVSto specify these automata models and to prove stateinvariant properties for the models. TAME was orig-inally designed to specify and reason about Lynch-Vaandrager (LV) timed automata [21] but has beenadapted to I/O automata [20] and the automata modelunderlying SCR (see [2]). TAME provides more thantwenty specialized strategies that implement proofsteps mimicking the high-level proof steps typicallyused by humans in proving invariant properties. Ex-perience has shown that for automata models whosestate variables have simple types (such as numerical,boolean, or enumerated types), nearly all state invari-ants can be proved using the TAME steps exclusively.We have integrated TAME into SCR* by develop-ing an automatic SCR-to-TAME translator and specialTAME strategies for the automatic analysis of proper-ties of SCR automata [2]. For many SCR automata|in particular, those not involving timing constraintsor other complexities such as tolerances for controlledquantities|a single TAME strategy can automaticallyprove many state invariants.As stated in Section 2, most invariant propertiesof interest for an SCR automaton are either state in-variants (one-state properties) or transition invariants(two-state properties). State invariants are typicallyproved by induction, with a base case for the initialstates and an action case for each kind of input event.Although induction can be used in proving transitioninvariants, it is seldom appropriate, since the transi-tions possible from any given state seldom have anyconnection to the transitions possible from one of itssuccessor states. Rather, transition invariants are nor-mally proved by reasoning directly about the transitionrelation of the SCR automaton.In TAME, the strategy SCR INDUCT PROOF per-forms the standard parts of an induction proof for astate invariant, and SCR DIRECT PROOF does thesame for a transition invariant. A universal invari-ant proof strategy identi�es the invariant as either aone-state or two-state property and then applies eitherSCR INDUCT PROOF or SCR DIRECT PROOF asappropriate.Properties 1, 2, and 3 in Figure 5 took a few daysto prove because the initial TAME representation of6

CD combined with the initial versions of the strategiesSCR INDUCT PROOF and SCR DIRECT PROOFled to unmanageably large data structures in the PVSprover. These problems led us to improve both ourtranslation scheme and our proof strategies. Afterthese improvements were made, we were able to proveproperties 5, 6, and 7 in Figure 5 in less than an hour.The proof of property 4 took longer|about 2 days|because we needed to discover and to prove two lay-ers of auxiliary invariants. This time would have beengreatly reduced if the full invariant generation algo-rithm (see Section 3.4) had been automated.When TAME's universal invariant strategy fails tocomplete the proof of an invariant, two possibilitiesexist: either the invariant is false, or additional invari-ants are needed in the proof. Associated with everyproof \dead-end" is a problem transition. For one-state properties, this is the transition of the action casein the induction proof in which the dead-end appears.For two-state properties, this is the transition from thegiven state via some enabled automaton action to thesuccessor state; the strategy SCR DIRECT PROOFproduces only dead-ends in which the action is known,and hence for deterministic SCR speci�cations, thesuccessor state (in terms of the given state) is known.TAME provides an analysis strategy to display the de-tails of any problem transition. Once these details areunderstood, the user can determine whether the transi-tion is reachable|in which case, the property is false|or whether it is unreachable, either because it wouldviolate some transition invariant, or because one or theother of the states in the transition violates some stateinvariant.Applying abstraction to a speci�cation is less impor-tant in theorem proving than in model checking. Sincea theorem prover can reason about abstract values, re-ducing the range of a variable using variable abstrac-tion results in little or no improvement in the num-ber of cases the theorem prover must consider. How-ever, variable restriction can reduce both the number ofcases and the complexity of reasoning about state tran-sitions. Therefore, prior to analyzing a property withTAME, we applied variable restriction to the speci�-cation. Because the resulting abstractions for the indi-vidual properties were very similar, we used the sameabstraction for all.Applying the TAME strategies to the seven prop-erties in Figure 5 resulted in the automatic proof offour of the properties. For two of the remaining prop-erties, we proposed an auxiliary invariant, which wasproved automatically and then applied to completethe proof. Property 1 in Figure 5 is an example of aproperty requiring a single auxiliary invariant, invari-

ant 5A in Figure 4, in its proof. Examination of theevent table for the variable cKeyBank1Key1, in Fig-ure 6 shows why the auxiliary invariant is needed:1when CD is in mode sOff, the event @T(mTamper) doesnot change the value of cKeyBank1Key1. Invariant 5A,which states that cKeyBank1Key1 is 0 in mode sOff,clearly covers this case.

Figure 6. Event table for cKeyBank1Key1In the case of the third remaining property, we sug-gested an auxiliary invariant that completed the proof.However, applying the automatic proof strategy to theauxiliary invariant resulted in several dead-ends, andwe therefore proposed three additional auxiliary invari-ants. These three new invariants were then proved au-tomatically using the universal invariant strategy. Asnoted in Section 3.4, each of the needed auxiliary in-variants was subsumed or implied by invariants that ei-ther were, or could be, generated automatically. Thus,once the invariant generator is extended and commu-nication between the invariant generator and TAMEis possible, the class of invariants that can be provedautomatically using TAME will be extended.Figure 7 shows a proposed eighth property thatdoes not hold in the CD speci�cation. Although Spiniiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Description PropertyiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiIf CD is in Alarm mode, then smOperation = sAlarmkey 1 in keybank 1 is 0 ⇒ cKeyBank1Key1 = 0iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiicc

ccc

ccccc

ccccc

Figure 7. A false property for SCR CD.1Some of the conditions and events have been abbreviatedusing ellipsis.7

was unable to produce a counterexample for this prop-erty, TAME's analysis of the property found 14 prob-lem transitions. Some intelligent exploration using theSCR* simulator produced a scenario that leads to oneof these transitions, thus demonstrating that the prop-erty does not hold in the SCR speci�cation. Detailedexamination of the feedback from TAME shows thatno obvious invariants forbid the other problem transi-tions, so it is likely that they also correspond to coun-terexamples.3.7 Applying the Validity CheckerThe SCR* validity checker VC [4] checks the valid-ity of �rst-order one-state or two-state properties di-rectly by using an initial term-rewriting phase followedby application of a decision procedure that uses BDDs(binary decision diagrams) to evaluate propositionalformulae and a constraint solver to reduce simple in-teger arithmetic formulae (Presburger formulae). Thevariable ordering used in the BDDs is particularly ef-�cient for SCR speci�cations. VC can also performan induction proof of a property by �rst applying apreprocessor to generate the appropriate base and in-duction cases and then applying the direct method tothe generated cases. An automatic translation of SCRspeci�cations into input for VC has been built.VC has been applied to many of the same exam-ples to which TAME has been applied, including theCD properties (after abstraction, as with TAME). Therun time required by VC to analyze the CD propertieswas about half the time required by TAME. For thefalse property in Figure 7, VC produced a single prob-lem transition, a special case of one of the 14 problemtransitions reported by TAME. This is the same prob-lem transition for which we used the simulator to �nda counterexample. Thus, VC, like TAME, can be usedin demonstrating that a property is invalid.Unlike TAME, VC cannot be used to prove proper-ties interactively. Therefore, the CD properties whoseproofs required auxiliary invariants were checked af-ter �rst including all necessary auxiliary invariantsas assumptions, rather than by interactively invok-ing an analog of TAME's strategy for applying an in-variant lemma. Mechanically checking the validity ofcomplex properties (such as properties involving non-linear numerical constraints or numerical constraintsover real numbers, or properties whose proofs requiretypes of higher-order reasoning other than inductionover reachable states) requires a general-purpose theo-rem prover, such as PVS through TAME. However, VCcan provide an e�cient �rst screening for invariancefor any property of an automaton that involves onlypropositional logic, simple integer constraints, and uni-versal quanti�cation over states or state pairs.

3.8 Generating Test SetsApplying the formal techniques described aboveproduces very high-quality requirements speci�cations.Although such high-quality requirements speci�ca-tions are valuable, the ultimate objective of the soft-ware development process is to produce high-qualitysoftware|software that satis�es its requirements. Toweed out errors introduced by the implementation andto convince customers that the system performance isacceptable, the software needs to be tested. An enor-mous problem, however, is that software testing, espe-cially of secure systems, is extremely costly and time-consuming. It has been estimated that current testingmethods consume between 40% and 70% of the soft-ware development e�ort [3].The high-quality speci�cation produced by the SCRmethod can play a valuable role in software testing. Wehave developed an automated technique [9] that con-structs a suite of test sets from an SCR requirementsspeci�cation. Each test set is a sequence of system in-puts in which each input is coupled with the requiredsystem outputs. To ensure that the test sets \cover"the set of all possible system behaviors, our techniqueorganizes all possible system executions (i.e., traces)into equivalence classes and builds one or more testsets for each class. These test sets can then be usedto automatically evaluate the implemented software.By reducing the human e�ort needed to build and torun the test sets, such an approach can reduce boththe enormous cost and the signi�cant time and humane�ort associated with current testing methods.With our technique, a model checker's ability to pro-duce counterexamples is used to construct the test sets.The requirements speci�cation is used both to gener-ate a valid sequence of inputs and as an oracle thatdetermines the outputs the system is required to gen-erate from a given system input. To obtain a validsequence of inputs, the input sequence is constrainedto satisfy the environmental assumptions in the SCRrequirements speci�cation.We have built a prototype tool in Java that auto-matically translates an SCR speci�cation into the lan-guage of either of two model checkers, executes themodel checker to build the test sets, analyzes its out-puts, and �nally produces a �le containing the gener-ated test sets. Our prototype tool has been appliedto a number of speci�cations, including a sizable com-ponent of a contractor-speci�ed weapons system [11].Given the tool's early success in constructing test setse�ciently, we expect that applying the tool to the CDspeci�cation should be equally successful. The CDproject manager has expressed interest in using testsets generated by our tool to test the CD software.8

4 DiscussionThe Complexity of CD. Our SCR speci�cation ofCD re ects the application's signi�cant complexity andmoderate size. As noted in Section 3.1, the SCR spec-i�cation has 39 variables, and the relationships amongthese variables is complex. In any state after the ini-tial state, the monitored variable mHostCommand cantake one of 17 values, and therefore, in any state ofthe CD, there are 16 possible input events involvingchanges in this variable. In addition, there are 17 otherinput variables. As a result, the mode transition tableis large, involving 55 events to de�ne 25 mode transi-tions, and many event tables in the speci�cation arealso large: the average number of events per table is 8,with the largest table containing 16 events.Time and e�ort required. Despite the complexityof CD, the total time taken in this study to developand analyze the SCR CD speci�cation was only oneperson-month.2 Formalizing the speci�cation of CDin SCR, including the use of the analysis tools to per-form sanity checks, took only two person-weeks, andeven the most complex consistency checks ran in min-utes. The graphical front-end for simulation of CD wasconstructed in one day. Improvements to formulationof the properties based on feedback from the modelchecker took only a few days. TAME and the validitychecker underwent signi�cant improvement during ouranalysis of the SCR speci�cation of CD, and as a re-sult, analyzing a property with these tools now takesat most a few minutes, and sometimes only a few sec-onds. The most labor-intensive part of the analysisof a property is analyzing proof dead-ends to deter-mine their cause and their resolution. As noted above,we plan to fully implement the invariant generationalgorithm. This extension of SCR* should reduce sig-ni�cantly the problem of discovering useful auxiliaryinvariants.The practicality of SCR. For our SCR speci�cationof CD, we analyzed eight security properties. For eachproperty, we were able to de�nitively answer the ques-tion, \Does the operational speci�cation satisfy thisproperty?" When the answer was \No," we provided acounterexample illustrating the failure. Although thefull set of security properties for CD (to which we donot have access) numbers in the hundreds, our successwith the properties we considered and the relativelyshort time required support the proposition that SCRand the analysis techniques supported in SCR* pro-vide a practical, low-cost approach to providing highassurance. Typical concerns expressed by practitioners2Additional time was needed to make improvements in someof the SCR* techniques. These improvements were suggested byour experience with CD.

regarding the practicality of formal methods are ad-dressed in more detail in our discussion in [17] of thelessons we learned from our application of the SCR*tools to CD.5 Related WorkRSML (Requirements State Machine Language) [10]is another requirements method in which, as in SCR,a system is speci�ed as a state machine. RSML hasbeen successfully applied to �nding errors in the speci-�cation of a complex avionics system: the Tra�c alertand Collision Avoidance System II (TCAS II). LikeSCR speci�cations, RSML speci�cations include a setof tables and may be checked for consistency and for(a version of) completeness. SCR and RSML also haveimportant di�erences. First, RSML has a Statecharts-style interface through which it explicitly supportsspeci�cation features, such as hierarchical states andlocal variables, not explicitly supported in SCR (al-though similar e�ects can be obtained with SCR). Fur-ther, the AND/OR tables in RSML specify details oftransitions, while SCR tables specify how dependentstate variables are updated. Because a state machinehas many more transitions than state variables, anRSML speci�cation of a system contains many moretables than an SCR speci�cation of the same system.Finally, automated support for the analysis of RSMLspeci�cation properties beyond consistency and com-pleteness is not yet extensive.Reference [24] describes an earlier application ofSCR to the development of another COMSEC device,the External COMSEC Adaptor (ECA). The develop-ment, from modeling the device through implement-ing and verifying its design, was done using the high-level SCR method, but not the SCR* toolset. Theoperational requirements were speci�ed using SCR ta-bles, and the critical requirements model|the desiredproperties|was speci�ed using the CSP (Communi-cating Sequential Processes) language. In this e�ort,both formal and informal transitions between stageswere used, with some automated support for the formaltransitions from another mechanized theorem prover.6 ConclusionSCR o�ers a practical, low-cost approach to build-ing a high assurance COMSEC device. Before imple-mentation and design, the SCR* toolset can be usedto build and analyze, often automatically, a mathe-matically precise requirements speci�cation. Opera-tional personnel can use the SCR* simulator to val-idate the behavior of the speci�ed system. Further,model checking often can be used to identify securityproperties which the operational speci�cation violates,and theorem proving can be used to verify the correct-9

ness of security properties and suggest possible prop-erty violations. When analyses have established su�-cient con�dence in the requirements speci�cation, thesystem can be built to satisfy that speci�cation. Aplanned extension to SCR*, a tool to generate Javacode from speci�cations, will help with this phase ofdevelopment. Once the source code is available, testsets automatically generated from the operational re-quirements speci�cation by the test set generator canbe used to test the system implementation.AcknowledgementsWe thank Stan Chincheck and Tom Sasala for pro-viding us with their prose speci�cation of CD. We alsothank Stan, Tom, and Bruce Labaw for many helpfuldiscussions. Our colleague Ralph Je�ords executed byhand those parts of the invariant generation algorithmthat are not yet mechanized. Our colleague RameshBharadwaj and Steven Sims applied the SCR* validitychecker to the CD properties, and Ramesh Bharad-waj discovered a counterexample corresponding to theproblem transition found by this tool for the false prop-erty described above. Stuart Faulk, Ralph Je�ords,and Ramesh Bharadwaj gave us helpful comments onearly versions of this paper.References[1] M. Archer and C. Heitmeyer. Mechanical veri�cation oftimed automata: A case study. In Proc. 1996 IEEEReal-Time Technology and Applications Symp. (RTAS'96),pages 192{203. IEEE Computer Society Press, 1996.[2] M. Archer, C. Heitmeyer, and S. Sims. TAME: A PVS in-terface to simplify proofs for automata models. In Proc.User Interfaces for Theorem Provers 1998 (UITP '98),Eindhoven, Netherlands, July 1998.[3] B. Beizer. Software Testing Techniques. Van NostrandReinhold, 1983.[4] R. Bharadwaj and S. Sims. Salsa: Combining decision pro-cedures for fully automatic veri�cation. Draft.[5] R. Bharadwaj and C. Heitmeyer. Model checking completerequirements speci�cations using abstraction. AutomatedSoftware Engineering, 6(1), January 1999.[6] B. W. Boehm. Software Engineering Economics. Prentice-Hall, Englewood Cli�s, NJ, 1981.[7] S. Easterbrook and J. Callahan. Formal methods for veri�-cation and validation of partial speci�cations: A case study.Journal of Systems and Software, 1997.[8] S. R. Faulk, J. Brackett, P. Ward, and J. Kirby. TheCoRE method for real-time requirements. IEEE Software,9(5):22{33, September 1992.[9] A. Gargantini and C. Heitmeyer. Automatic generation oftests from requirements speci�cations. In Proc. ACM 7thEur. Software Eng. Conf. and 7th ACM SIGSOFT Symp.on the Foundations of Software Eng. (ESEC/FSE99),Toulouse, FR, September 1999.[10] M. P. E. Heimdahl and N. G. Leveson. Completenessand consistency in hierarchical state-based requirements.IEEE Transactions on Software Engineering, 22(6):363{377, June 1996.

[11] C. Heitmeyer, J. Kirby, B. Labaw, M. Archer, andR. Bharadwaj. Using abstraction and model checking to de-tect safety violations in requirements speci�cations. IEEETrans. on Softw. Eng., 24(11):927{948, November 1998.[12] C. L. Heitmeyer, R. D. Je�ords, and B. G. Labaw. Auto-mated consistency checking of requirements speci�cations.ACM Transactions on Software Engineering and Method-ology, 5(3):231{261, April{June 1996.[13] C. Heitmeyer, J. Kirby, and B. Labaw. Tools for for-mal speci�cation, veri�cation, and validation of require-ments. In Proc. 12th Annual Conf. on Computer Assurance(COMPASS '97), Gaithersburg, MD, June 1997.[14] C. L. Heitmeyer, R. D. Je�ords, and B. G. Labaw. Tools foranalyzing SCR-style requirements speci�cations: A formalfoundation. 1999. Draft.[15] K. Heninger, D. L. Parnas, J. E. Shore, and J. W. Kallan-der. Software requirements for the A-7E aircraft. TechnicalReport 3876, Naval Research Lab., Wash., DC, 1978.[16] G. J. Holzmann. Design and Validation of Computer Pro-tocols. Prentice-Hall, 1991.[17] J. Kirby, M. Archer, and C. Heitmeyer. Applying formalmethods to an information security device: An experiencereport. In Proc. 4th IEEE International Symposium onHigh Assurance Systems Engineering (HASE '99). IEEEComputer Society Press, November 1999.[18] R. Je�ords and C. Heitmeyer. Automatic generation ofstate invariants from requirements speci�cations. In Proc.6th International Symposium on the Foundations of Soft-ware Engineering (FSE-6), Orlando, FL, November 1998.[19] R. R. Lutz and H.-Y. Shaw. Applying the SCR* require-ments toolset to DS-1 fault protection. Technical ReportJPL-D15198, Jet Propulsion Laboratory, Pasadena, CA,December 1997.[20] N. Lynch and M. Tuttle. An introduction to Input/Outputautomata. CWI-Quarterly, 2(3):219{246, September 1989.Centrum voor Wiskunde en Informatica, Amsterdam, TheNetherlands.[21] N. Lynch and F. Vaandrager. Forward and backward sim-ulations { Part II: Timing-based systems. Information andComputation, 128(1):1{25, July 1996.[22] S. Miller. Specifying the mode logic of a ight guidance sys-tem in CoRE and SCR. In Proc. 2nd Workshop on FormalMethods in Software Practice (FMSP'98), 1998.[23] D. L. Parnas, G. J. K. Asmis, and J. Madey. Assessmentof safety-critical software in nuclear power plants. NuclearSafety, 32(2):189{198, April{June 1991.[24] C. N. Payne, A. P. Moore, and D. M. Mihelcic. An expe-rience modeling critical requirements. In Proc. COMPASS'94, pages 245{256, Gaithersburg, MD, June 1994. IEEEPress.[25] N. Shankar, S. Owre, and J. Rushby. The PVS proofchecker: A reference manual. Technical report, ComputerScience Lab., SRI Intl., Menlo Park, CA, 1993.10