CONSTANCE HEITMEYER CENTER FOR HIGH ASSURANCE COMPUTER SYSTEMS NAVAL RESEARCH LABORATORY WASHINGTON, DC McMaster University March 17, 2003 TOOLS FOR BUILDING

CONSTANCE HEITMEYERCENTER FOR HIGH ASSURANCE COMPUTER SYSTEMS

NAVAL RESEARCH LABORATORYWASHINGTON, DC

McMaster UniversityMarch 17, 2003

TOOLS FOR BUILDING ANDTOOLS FOR BUILDING AND

EVALUATING HIGH ASSURANCE EVALUATING HIGH ASSURANCE

SOFTWARE SYSTEMS AND COMPONENTSSOFTWARE SYSTEMS AND COMPONENTS

204/19/23

• Background– History of SCR SCR

– SCRSCR Tools

• Applying the tools to high assurance systems1 Navy’s A-7 Flight Program2 Rockwell’s Flight Guidance System3 Navy’s Weapon Control Panel4 NASA’s Flight Protection Engine5 Navy Family of Cryptographic Devices

a CDCD I I - - case studyb CDCD II II - - formal specification/verification of real device

• Specification-based test case generation

• Role of invariants in formal analysis

OUTLINE

304/19/23

HISTORY OFSCR SCR APPROACH

1978: Heninger,Parnas+ publish A-7/SCR requirements document— Tabular notation — Events and conditions— Mode classes and terms

1980s-early 1990s: SCR applied to a wide range of systems— Telephone networks (AT&T Bell Labs)— Submarine communications (NRL) — Control software for nuclear plants (Ontario Hydro)— Avionics software (Grumman)

Early 1990s: Development of Four Variable Model and CoRE— Parnas+ introduce and apply Four Variable Model— Softw. Productivity Consortium develops CoRE (based on SCR)— Lockheed applies CoRE and SCR tables to C-130J flight program

1992-present: NRL develops formal SCR model and tools

SCR SCR SSoftware C Cost R Reduction

404/19/23

SCR REQUIREMENTS MODEL: SOME TERMINOLOGY AND NOTATION

A system is represented as a state machine A condition is a predicate on a state A conditioned event is denoted @T(c) WHEN d, where c

and d are conditions. It is defined by

@T(c) WHEN d = ¬ c c’ d,

where the unprimed c denotes c in the old state and the primed c denotes c in the new state

Changes in monitored variables (called monitored events) provide the input alphabet

Each table (condition or event) defines the value of a dependent variable (mode class, term, controlled variable) as a function

The next-state function of the state machine is the composition of the functions defined by the tables

504/19/23

SPECIFY THE SYSTEMPRECISELY

Use a TABULARTABULARnotation with anexplicit formal semantics to specify therequired behavior

APPLY“CONSISTENCY

CHECKING”

Automatically check spec fortype errors,missing cases,nondeterminism,circular defs, etc.

SIMULATETHE

SYSTEM BEHAVIOR

Symbolicallyexecute the system basedon the (executable) req. specs

SCRSCR GOAL: MAKE ‘FORMALMETHODS’ PRACTICAL

As we move down the chain, we increaseassurance in the spec

INCREASING EFFORT,

INCREASED

EXPERTISE

VERIFYSPECS USING

THEOREM PROVING

VERIFYSPECS USING

MODEL CHECKING

Checkcriticalapplicationproperties

• Usable, scalable tabular notation• Integrated set of robust, powerful software tools

– light-weight tools whose use does not require math. sophistication/thm proving

– heavy-duty tools (e.g., theorem prover)

604/19/23

• Consistency and completeness – Is the spec well-formed?

• Validation– Is this the right spec?– I.e., does the spec capture the

intended behavior?• Verification

– Is the spec right?– I.e., does the spec satisfy critical

properties (e.g., safety, security)?

THEOREM PROVER

INVARIANTGENERATOR

SCRSCR TOOLSETTOOLSET

PROPERTYCHECKER (Salsa)

DEPENDENCYGRAPH BROWSER

SPECIFICATIONEDITOR

MODEL CHECKER

system spec

CONSISTENCY

CHECKER

modes

events

mon vars

cont vars

conditionsterms• most mature tools

• installed at 100+ org’ns in industry, govt., and academia

SCRSCR TOOLS FOR DEVELOPING SOFTWARE REQUIREMENTS*

SIMULATOR

New New ANALYSIS ANALYSIS TOOLS TOOLS

*Heitmeyer et al., Proc. CAV ‘98.

TOOLS FOR TESTING & TOOLS FOR TESTING & CODE SYNTHESIS ARE BEING DEVELOPEDCODE SYNTHESIS ARE BEING DEVELOPED

THEOREM PROVER(TAME)

INVARIANTGENERATOR

New New ANALYSIS ANALYSIS TOOLS TOOLS

SCR SCR TOOLSETTOOLSET

PROPERTYCHECKER (Salsa)

CONSISTENCY

CHECKER


SPECIFICATIONEDITOR

MODEL CHECKER

system spec

SIMULATOR

modes

events

mon vars

cont vars

conditionsterms

• most mature tools

• installed at 100+ org’ns in industry, govt., and academia

• TAME is an interface to PVS designed to prove properties of state machine models

TEST CASE GENERATOR

SOURCE CODE

GENERATOR

Research Prototypes Research Prototypes

Next step: Optimized, provablyNext step: Optimized, provably correct source codecorrect source code

APPLYING CONSISTENCY CHECKING TO THE A-7

REQUIREMENTS DOCUMENT

APPLYING CONSISTENCY CHECKING TO THE A-7

REQUIREMENTS DOCUMENT

CONSISTENCY

CHECKER

system spec

modes

events

mon vars

cont vars

conditionsterms

904/19/23

• Checked all 36 condition tables, a total of 98 rows– Results: 17 rows in 11 tables violated the

Coverage Property (i.e., identified missing cases)

• Checked all 3 mode transition tables, a total of 700 rows (4319 logical expressions)– Results: 57 violations of the Disjointness Property

were detected (identified non-determinism)

CONSISTENCY CHECKING THE A-7 REQ. DOCUMENT: RESULTS1

Consistency checking finds MANY errors that human inspections miss and usually does so in

a very short time (seconds to minutes)

Consistency checking finds MANY errors that human inspections miss and usually does so in

a very short time (seconds to minutes)

1Heitmeyer et al., ACM TOSEM, 1996.

- @F f - - - - - - - t - - - - - ---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - - - f - - - - @T - t - - - - - - - - - f - - - - @T - - t - - - - - - - - f - - - - t - @T - - - - - - - - - f - - - - t - - @T - - - - ---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- f - - t - - f - @T - t - - - - - - f - - t - - f - @T - - t - - - - - - - - t - - f - t - @T - - - - - - - - - t - - f - t - - @T - - - - ---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- f - - - - - t f @T - - t - - - - - f - - - - - t f @T - t - - - - - - - - - t - - t f t - @T - - - - - - - - - t - - t f t - - @T - - - - - f - - - - - - f @T t - - t - - - - f - - - - - - f t @T - - t - - - ---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- @T - - - - - - - - - - - - - - - ---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - - - - - - - - - - - - - @T - - ---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - - - - - - - - - - - - - - @T - ---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - - - - - @F - - - - - - - - - - ---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - - - - - - - @T - - - - - - - - -

Current

Mode

*I*

New Mode

*Airaln*

*DIG*

*OLB*

*DI*

*Mag sl*

*Grid*

*IMS fail*

*PolarI*

*Landlan*

For each error detected, theconsistency checker displays1. the table containing the error with erroneous entry highlighted2. a state pair demonstrating the error (counterexample)

EXAMPLE: DETECTION OF A DISJOINTNESS ERROR

Event that could trigger either transition@T(Doppler_up) WHEN [NOT

CA_stage_complete AND latitude > 70 deg. AND NOT present_position_entered AND NOT latitude > 80 deg. AND IMSMODE=Gndal]

@T(Doppler_up) WHEN [NOT CA_stage_complete AND latitude > 70 deg. AND NOT present_position_entered AND NOT latitude > 80 deg. AND IMSMODE=Gndal]

counterexample

Excerptfrom 14-pagetable in theA-7 req.document

Old Mode New ModeEvent

The two The two rowsrowsthat that overlapoverlap

APPLYING THE SCR TOOLS TO ROCKWELL’S FLIGHT GUIDANCE SYSTEM

APPLYING THE SCR TOOLS TO ROCKWELL’S FLIGHT GUIDANCE SYSTEM

CONSISTENCY

CHECKER

SPECIFICATIONEDITOR

system spec

SIMULATOR

modes

events

mon vars

cont vars

conditionsterms

1204/19/23

ROCKWELL-COLLINS AVIATION:FLIGHT GUIDANCE SYSTEM

Experimental application of SCR tools by Rockwell Despite extensive reviews by Rockwell engineers, the tools found

many errors in the spec– 28 errors detected, “many of them significant”– one third each: constructing the specification, applying the

completeness and consistency checks, and simulating the system behavior based on the specification

Example: Disjointness error leading to two possible flight modes

Example: Missing cases (Lateral Armed Annunciation field undefined in certain cases)

“...preliminary execution of the specification and completeness and consistency checking [with theSCR tools] has found several errors in a specification that represented our best effort at producing a correct specification manually.”

“...preliminary execution of the specification and completeness and consistency checking [with theSCR tools] has found several errors in a specification that represented our best effort at producing a correct specification manually.”

Steve MillerRockwell-Collins Aviation

APPLYING THE SIMULATOR AND MODEL CHECKING TO A WEAPONS CONTROL PANEL

APPLYING THE SIMULATOR AND MODEL CHECKING TO A WEAPONS CONTROL PANEL

CONSISTENCY

CHECKER


SPECIFICATIONEDITOR

MODEL CHECKER

system spec

SIMULATOR

modes

events

mon vars

cont vars

conditionsterms

1404/19/23

ANALYZING A CONTRACTOR REQ. SPEC OF A WEAPONS CONTROL PANEL

WCP OVERVIEW• WCP used to prepare & launch weapons• Sizable, complex program (~15KLOC)• Monitored quantities

– switches and dials– numeric quantities (read by sensors)

• Controlled quantities– lights– doors and valves (set by actuators)

PRODUCING THE SCR SPEC• Used scanner and OCR to read in contractor

spec of the WCP (250+ vars)• Used text editor to convert to SCR spec

Part of WEAPONS CONTROL PANEL Interface

Weapons Control Panel

Weapons Control Panel

USER-FRIENDLY SIMULATION• Scanned in diagrams of operator interface• Used interface builder to develop realistic simulator front-end• Operators unfamiliar with SCR can run scenarios to validate requirements spec

1Heitmeyer et al., IEEE TSE, 1998.

1504/19/23

ANALYZING THE WCP SPECIFICATION FOR SAFETY PROPERTIES

@T(cVENT_SOLENOID)

kMinTRANS_OK < TRANS_A’ TRANS_A’ < kMaxTRANS_OK kMinTRANS_OK < TRANS_B’ TRANS_B’ < kMaxTRANS_OK

Opening the Torpedo Tube Vent Valve shall be prevented unless the Missile-to-Torpedo-Tube differential pressure is within safe limits

EXAMPLE SAFETY PROPERTY

minimum allowablefor launch

maximum allowablefor launch

1604/19/23

MODEL CHECKING THEWCP SPECIFICATION (1)

Dependency Graph of Original Spec

Dependency Graph of Abstraction

Reduces spec from 250+ to 55 variables

(~80% reduction)

PROBLEM: TOO MANY VARIABLESSOLUTION: REMOVE VARIABLES IRRELEVANT TO THE VALIDITY OF THE PROPERTY

1704/19/23

MODEL CHECKING THEWCP SPECIFICATION (2)

PROBLEM: Some variables are real-valued

SOLUTION: Apply data abstraction -- i.e., replace each real-valued variable with a variable with a small, discrete value set

Size of type set oftSEL_TRANS goesfrom infinite to 3

l u

9.2l u

9.2l u14.8

0 if l tSEL_TRANS < 9.2

f (tSEL_TRANS) = 1 if 9.2 tSEL_TRANS < 14.8

2 if 14.8 tSEL_TRANS u

• Spec refers to real-valued variable tSEL_TRANS in two expressions:

tSEL_TRANS < 14.8 and tSEL_TRANS < 9.2• The first expression partitions the interval [l,u] into 2 subintervals• The second expression partitions the interval [l, 14.8) into 2 subintervals• The new abstract variable has the type set {0, 1, 2}.• The function f mapping the concrete var to the abstract var is defined by

EXAMPLE

1804/19/23

USING SIMULATION TO VALIDATE VIOLATION OF A SAFETY PROPERTY

18.0

Corresponding system history (each input and its results)

Simulatornotificationof violationin spec

Input sequence (scenario) that produces violation

Spin notificationof violation in abstract model

18.0

1904/19/23

APPLYING SCR TO WCP: REQUIRED EFFORT

PERSON- WEEKS

Translate contractor SRS into SCR 0.8Use light-weight tools to detect errors 0.2Correct errors 0.3Abstraction/Detection of safety violation 0.7 Develop customized simulator front-end 3.0

~5

TASK

This small effort is quite surprising given that• the contractor-produced SRS was large and complex• the contractor had no prior knowledge of SCR

TOTAL0.12+

CONSISTENCYCHECKER


SPECIFICATIONEDITOR

system spec

SIMULATOR

modes

events

mon vars

cont vars

conditionsterms

TEST CASEGENERATOR

APPLYING THE SCR TOOLS, INCLUDING THE TEST CASE GENERATOR, TO NASA’S

FAULT PROTECTION ENGINE (FPE)

APPLYING THE SCR TOOLS, INCLUDING THE TEST CASE GENERATOR, TO NASA’S

FAULT PROTECTION ENGINE (FPE)

2104/19/23

PROBLEM• NASA is using slightly different

implementations of the FPEFPE in various spacecraft

• NASA needs high reliance in the correctness of each version of the FPEFPE code

• Our task– To develop a formal spec of the FPEFPE

beh.– From the spec, to constuct a set of test

cases satisfying some coverage criteria– The tests will be used to check the FPE

code

Idle No_WayPoint

Run_Int_Resp WayPoint

Current request completed when no higher-priority requests queued and time-out not expired

Current request is completed and at least one higher-priority request is queued

Waypoint detected when no higher-priority responses are queued

Time-out expired when no higher-priority requests queued

One or more requests received (no requests queued and none being processed)

Current request is completed and no other requests queued OR FlushAllResps received

FlushAllResps received FlushAllResps

received

Waypoint detected when higher-priority responses queued

FPE Algorithm

TEST CASE GENERATIONFOR NASA’S FPE

2204/19/23

EXPERIENCE TO DATE

• Our goal is to produce– A good requirements spec of the required FPE behavior

• Describes precisely and clearly normal and abnormal behavior• Avoids both overspecification and underspecification• Describes likely ways that the FPE component will change

– A set of critical properties that the FPE code must satisfy– Proof that the spec satisfies the properties and validation that the spec

captures the intended behavior– A set of test cases satisfying some coverage criterion

• Progress to Date– An SCR spec that is well-formed and relatively understandable– A simulator for use in validating the spec– A small set of test cases constructed using our algorithm

NASA personnel learned to read andNASA personnel learned to read andunderstand the SCR specs very quicklyunderstand the SCR specs very quicklyNASA personnel learned to read andNASA personnel learned to read and

understand the SCR specs very quicklyunderstand the SCR specs very quickly

2304/19/23

FPE SIMULATOR INTERFACEFPE SIMULATOR INTERFACEFPE SIMULATOR INTERFACEINPUTSINPUTSINPUTS OUTPUTSOUTPUTSOUTPUTS

Request forGround Response

Request forInterrupting

Response

Request forNon-Interrupting

Response

ID Type

WayPoint Entered

TimeOut Expired

Flush All Responses

IDID ID

CommandResponse

ID Type

Error Messages

MODE AND OTHER AUXILIARY VARIABLESMODE AND OTHER AUXILIARY VARIABLESFPE Mode Currently Active Response

ID Type

Saved Non-Inter. Response

ID

DEFERRED RESPONSE QUEUES

Timed Out?

CompletedResponse

Ground ResponsesQueue

Non-Inter. ResponsesQueue

Interrupting ResponsesQueue

Current Length = Current Length = Current Length =

TECHNICAL AND OTHER ISSUES

SCR LANGUAGE• FPE algorithm involves many complex constructs

that “stretch” our model– e.g., feedback loops, queues, simult. input events,

priorities, etc.

• Problem: How to specify these in a way that satisfies our criteria

PROPERTIES/LIKELY CHANGES • How to determine what these are• Little of this is captured in the current documentation

TEST CASE GENERATION• How to deal with the input data at a more abstract

level • How to reduce the length of the test cases

2404/19/23

GUIDELINES FOR WRITING AGUIDELINES FOR WRITING AREADABLEREADABLE (FORMAL)(FORMAL) REQ. SPECREQ. SPEC

• Begin with a spec language that practitioners can easily learn and that is designed for describing requirements

• Choose short variable names that the applications expert will understand– Make it easy to distinguish input and output variables

• To the extent feasible, eliminate redundancy from the spec– Reduces the length of the spec, so there is less to validate– Reduces the opportunity for errors– Some planned redundancy is ok -- e.g., critical system properties

• Given a choice between implementation bias and readability, opt for readability• Minimize the use of artifacts in the spec

– Select variable types very carefully (e.g., do not use a boolean if you only need a toggle switch)• Identify key parts of the spec and focus on making those readable• If some aspect of the requirements makes the spec hard to understand, postpone introducing that

aspect • Organize the spec for ease of understanding and ease of change • Provide comments that explain the rationale for the requirements

THEOREM PROVERTAME

INVARIANTGENERATOR


SPECIFICATIONEDITOR

MODELCHECKER

system spec

CONSISTENCYCHECKER

modes

events

mon vars

cont vars

conditionsterms

SIMULATOR

APPLYING THE SCR TOOLS TO CD I, A MEMBER OF A FAMILY

OF CRYPTO SYSTEMS

APPLYING THE SCR TOOLS TO CD I, A MEMBER OF A FAMILY

OF CRYPTO SYSTEMS

2604/19/23

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

PEIP

encryptencrypt

PEIP

decryptdecrypt

comm.comm.systemsystem

• Load (and zeroize) crypto algorithms and keys• Configure channel (i.e., write alg and key into channel space)• Encrypt and decrypt data using a crypto algorithm and a key• 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

Each family member is implementedEach family member is implementedin handware in handware andand softwaresoftware

2704/19/23

Objective Reduce human effort needed to

verify properties with a theorem prover

Why build upon PVS? Avoid reinventing existing, well-known techniques Use PVS logic as a flexible means of further proof support for automata models State properties in the expressive but natural logic of PVS

Timed AutomatonTheory & Logic

Proof System

PVS

Reasoning in theTimed Automata

ModelR.-T. System

Modeledas Timed Automata

Specialized Top Layer

Templates

Higher-OrderLogic

TypeTheory

InductionSimulati

on

User-Defined

Strategies

TAMETAME

Timed Automata Modeling Environment

Design Goals Easy to create specs Natural formulation of properties ‘Natural’ proof steps that match in

size/kind steps used in hand proofs Proofs similar to hand proofs

TAMETAME -- A SPECIALIZED PVS INTERFACE*TAMETAME -- A SPECIALIZED PVS INTERFACE*

2804/19/23

STEPS IN HAND PROOFS VS. STEPS IN PVS PROOFS

In proving A ⇒ B:“supposeA” (FLATTEN)Inproving∀a.P(a):“fixa=a0” (SKOLEM<fnum>“a0”)“Bythedefinitionof<function>” (EXPAND“<function>”)Toshow“∃a.P(a)becauseP(a0)” ( INST<fnum>“a0”)???(Amiraclehappenshere--maybe) (GRIND)Knowing“eventπprecedesstatesandP(π,s)holds”adduce“thelastevent

π0beforessuchthatP(π0,s)”

(let((exists_case_body(formatnil...)).. .)(then(branch(caseexists_case_body)(then...(branch(apply_lemma“last_event”(.. .)))))))

Instartingtheproofofastateinvariant:“Useinduction. ”

(then(branch(auto_casesinv)((then(base_caseinv)(systimpl_simp_probe)(postpone))(branch(induct_casesinv)(then(reduce_case_one_var_expinv“t_1”)(match_univ_and_systimpl_simp_probe)(postpone))

. . .(then(reduce_case_no_var_expinv)(match_univ_and_systimpl_simp_probe)(postpone))

Introducetheconstraintsapplyingtoanondeterministicεvalueinthepoststate

(let((eps_lemma...)(inst_pred...))(then(lemmaeps_lemma)(inst-1inst_pred)(branch(split-1)((.. .)(postpone))))))

HUMAN-STYLE PVS

TAME Goal: Provide natural proof stepsTAME Goal: Provide natural proof steps

2904/19/23

1 When the zeroize switch is activated, the keys are zeroized

2 No key can be stored before an algorithm in the assoc. location is activated

3 If undervoltage occurs in backup power while primary power is un-available, CD enters alarm or off mode

4 If backup power is overvoltage, then CD is in initialization, standby, alarm, or off mode

5 When an overvoltage occurs in primary power, then CD is in standby, alarm or off mode, or goes into initialization

6 When an undervoltage occurs in primary power, then CD is in standby, alarm, or off mode, or goes into initialization mode

7 If CD is tampered with, the keys are zeroized

SECURITY PROPERTIES

VERIFYING THE CD I SPEC (1)

proved directly by induction using TAME

3004/19/23

1 When the zeroize switch is activated, the keys are zeroized

2 No key can be stored before an algorithm in the assoc. location is activated

3 If undervoltage occurs in backup power while primary power is unavailable, CD enters alarm or off mode

4 If backup power is overvoltage, then CD is in initialization, standby, alarm, or off mode

5 When an overvoltage occurs in primary power, then CD is in standby, alarm or off mode, or goes into initialization

6 When an undervoltage occurs in primary power, then CD is in standby, alarm, or off mode, or goes into initialization mode

7 If CD is tampered with, the keys are zeroized

• In Initialization mode, primary power is not unavailable

• In Configuration mode, the system is healthy, backup power is not overvoltage, and primary power is not unavailable

• In Idle mode, the system is healthy, backup power is not overvoltage, and power power is not unavailable

• In Traffic Processing mode, the system is healthy, backup power is not overvoltage, and primary power is not unavailable

• In Off mode, KeyBank1Key1=0...

SECURITY PROPERTIES AUTOMATICALLY GENERATED INVARIANTS*

VERIFYING THE CD I SPEC† (2)

*Jeffords, Heitmeyer, 1998, 2001.*Jeffords, Heitmeyer, 1998, 2001.†Kirby, Archer, Heitmeyer, 1999.

..

THEOREM PROVERTAME

INVARIANTGENERATOR


SPECIFICATIONEDITOR

MODELCHECKER

system spec

CONSISTENCYCHECKER

modes

events

mon vars

cont vars

conditionsterms

SIMULATOR

APPLYING THE SCR TOOLS TO CD II OF CRYPTO SYSTEMS

APPLYING THE SCR TOOLS TO CD II OF CRYPTO SYSTEMS

3204/19/23

NEW EFFORT: VERIFYING THE SECURITY OF CD II

• CD I has been certified by National Security Agency (NSA) and is currently installed aboard US Navy platforms

• To certify CD II as a multi-level secure device, NSA requires an “EAL7-like” Common Criteria evaluation of the CD II separation kernel

• Our plan: Use the SCR/TAME tools to support the evaluation

Unlike CD I, CD II • both receives and transmits data • processes data at many

different security levels

QuickTime™ and aGIF decompressor

are needed to see this picture.

3304/19/23

ChannelChannel

WHAT SECURITY POLICY MUST CD II SATISFY?

CHANNELCHANNEL ii CHANNEL CHANNEL jj

processprocessforfor

datadataencrypt/encrypt/decryptdecrypt

on on channel ichannel i

ded’dded’dmemorymemory

for for channel ichannel i



on on channel jchannel j


for for channel jchannel j


storingstoringsharedshared

algorithmsalgorithmsandandkeyskeys

sharedsharedmemorymemory

for for algs/keysalgs/keys

SHAREDSHARED

CD II

Data never flows from channel i to channel j and vice versa Data never flows from channel i to channel j and vice versa

SECURITY POLICY: ENFORCE SEPARATION

USER COMMANDSUSER COMMANDS

3404/19/23

ChannelChannel

CHANNELCHANNEL ii CHANNEL CHANNEL jj



on on channel ichannel i


for for channel ichannel i



on on channel jchannel j


for for channel jchannel j


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 never flows from channel i to channel j and vice versa Data never flows from channel i to channel j and vice versa

SECURITY POLICY: ENFORCE SEPARATION

3504/19/23

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.

3604/19/23

• Develop a formal SECURITY POLICY MODEL to describe the CD II notion of separation (Use style of [1])

• Produce ABSTRACT SPEC--a formal spec of the behavior of the CD II separation kernel

• Prove that the ABSTRACT SPEC satis-fies 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

Prove CONCRETE SPEC refines the ABSTRACT SPEC

Show that the CODE satisfies the CONCRETE SPEC

CODE WALK-THROUGHCODE WALK-THROUGHSCR TOOL SUPPORTSCR TOOL SUPPORT

OBTAINING A HIGH ASSURANCE SEPARATION KERNEL

security-relevant CODE

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

3704/19/23

WHY IS THIS A HARD PROBLEM?

• Should we use a top-down or bottom-up approach?

• How is the separation kernel’s environment represented?

• What is the security perimeter? The answer is not obvious

• Exactly what kernel does is not obvious– Mediates access to storage (i.e., grant/revoke R, W, and X privileges)

• includes mediating access to temporary and working storage – Handles interrupts– Initiates processes in response to interrupts– Copies sensitive data from one storage area to another– When switching from one subtask to another, sanitizes storage areas

• We have largely mechanized proofs of invariant properties– However, automated support of refinement requires extensions to our mechanized

theorem proving support

The devil is in the details...The devil is in the details...

3804/19/23

CONSISTENCYCHECKER


SPECIFICATIONEDITOR

system spec

SIMULATOR

modes

events

mon vars

cont vars

conditionsterms

TEST CASEGENERATOR

AUTOMATED TEST CASE GENERATION FROM

REQUIREMENTS SPECIFICATIONS

AUTOMATED TEST CASE GENERATION FROM

REQUIREMENTS SPECIFICATIONS

3904/19/23

Test CaseGenerator

Test Driver

AUTOMATIC TEST CASE AUTOMATIC TEST CASE GENERATION*GENERATION*

SystemReq. Spec

Test Harness

Test Case

Our approach to software testing• specification-based• black-box: does the software satisfy the requirements specification?

OUR FOCUSOUR FOCUS

Our technique• Generates one or more test

cases for each decision point in the spec

• Does so in a manner that “covers” all possible system executions described by the spec

• Uses req. spec. as an oracle to generate the system response associated with an input sequence

• Uses the counterexample capability of a model checker to construct the test cases

**Gargantini, Heitmeyer, ESEC/FSE, 1999.

4004/19/23

Test Case: A sequence of inputs, each input paired with a set of outputs (also called Test Sequences)Test Suite: A collection of test cases

Test Predicate: A predicate used to construct test cases

(also called a Test Purpose)

Goals of Test Case Generation:• The number of test sequences in the test suite should be as small as possible

• The test suite should “cover” all errors that any implementation may contain

SOME BASICS

NOTE: To simplify the discussion, we refer to inputs and outputs(rather than to monitored and controlled variables).

4104/19/23

• Based on a control system in a real nuclear power plant* • System is required to turn on SafetyInjection when water

pressure (WaterPres) falls below a threshold Low=10. • Operator can set a Block button to inhibit safety injection and a

Reset button to reset the system after blockage

• We assume WaterPres may never increase by more than 3 from one state to the next and its initial value is 2.

EXAMPLE: EXAMPLE: THETHE SAFETYSAFETY INJECTION SYSTEMINJECTION SYSTEM (SIS)(SIS)

*Courtois,Parnas, “Documentation for Safety-Critical Software,” Proc., ICSE’93, Baltimore.

Environment

Safety Injection SystemEnvironme

nt

WaterPresBlockReset

SafetyInjection

Monitored

Variables

ControlledVariable

s

ConstantsTermOverridden {Low

Permit

ModeClass High

Pressure

Permitted

TooLow

req’drelation

assumption

4204/19/23

CONSTRUCTINGCONSTRUCTING TEST PREDICATESFROMFROM SYSTEM PROPERTIES

@T(WaterPres < Low) WHEN Block = On Reset = Off SafetyInjection’ = Off

Suppose the SCR spec of SIS satisfies the following safety property:

• To operate safely, all executions of the SIS must satisfy this safety property • This property is an example of a test predicate• Each test predicate may be used to generate one or more test cases.

4304/19/23

LIMITATIONS OF THIS APPROACHLIMITATIONS OF THIS APPROACH

• A set of system properties may not be available

• The set of system properties is incomplete --i.e., all possible system behaviors are not usually covered

4404/19/23

CONSTRUCTING CONSTRUCTING TEST PREDICATESFROM AFROM A STATE MACHINE SPEC

OLD MODE EVENT NEW MODETooLow @T(WaterPres Low) PermittedPermitted @T(WaterPres Permit) High

@T(WaterPres Low) TooLowHigh @T(WaterPres Permit) Permitted

Event Table Defining the Mode Class Pressure

Total Function That the Table Defines (Single else Clause)

if † Pressure = TooLow

@T(WaterPres Low) Pressure’ = Permitted† Pressure = Permitted

@T(WaterPres Permit) Pressure’ = High † Pressure = Permitted

@T(WaterPres Low) Pressure’ = TooLow† Pressure = High

@T(WaterPres Permit) Pressure’ = Permitted† (else) Pressure’ = Pressurefi

4504/19/23

GENERATING MORE

TEST PREDICATES

Alternate Representation of the Function Defining Pressure With One else Clause per Mode

if Pressure = TooLow if

@T(WaterPres Low) Pressure’ = Permitted C1C1 (else) Pressure’ = Pressure C2C2

fi Pressure = Permitted if

@T(WaterPres Permit) Pressure’ = High C3C3 @T(WaterPres Low) Pressure’ = TooLow C4C4

(else) Pressure’ = Pressure C5C5 fi Pressure = High if

@T(WaterPres Permit) Pressure’ = Permitted C6C6† (else) Pressure’ = Pressure C7C7 fifi

4604/19/23

CONSTRUCTING TRAP PROPERTIESFROM SYSTEM PROPERTIES


How to generate a test sequence from predicate P

• If Spec satisfies P and P = (R S) , use Spec as the state machine model

• Then, use a model checker, say SMV, to check Spec for the property ¬R

• This generates a counterexample, a system execution allowed by Spec that

satisfies R (and S as well, since R S)

• This counterexample defines a test case that can be used to test the

correctness of the software

Suppose the SCR spec of SIS satisfies the following safety property:

TestPredicate P

4704/19/23

CONSTRUCTING TRAP PROPERTIESFROM SYSTEM PROPERTIES


P = (R S) , where R = @T(WaterPres < Low) WHEN Block = On Reset = Off S = SafetyInjection’ = Off

We use TRAP PROPERTIESTRAP PROPERTIES to force the model checker to to force the model checker to construct a counterexample -- i.e., a desired test caseconstruct a counterexample -- i.e., a desired test case

We use TRAP PROPERTIESTRAP PROPERTIES to force the model checker to to force the model checker to construct a counterexample -- i.e., a desired test caseconstruct a counterexample -- i.e., a desired test case

TestPredicate P

The above is an example of a TRAP PROPERTYTRAP PROPERTY

Translation of¬R into CTL

AG!( EX(WaterPres<Low) & ! WaterPres<Low & Block = On & Reset = Off )

4804/19/23

GENERATING A TEST SEQUENCE FROM A SYSTEM PROPERTY

The above Test Case may be represented more concisely as:

< (r,off; -), (w,5; -), (w,8; -), (w,10; s,off), (b,on; -), (w,8; -) >

Step Monitored Var. Mode Class Controlled Var.No. Value Value Value

0 WaterPres=2 Pressure=TooLow SafetyInjection=On Block=Off Reset=On

1 Reset=Off2 WaterPres=53 WaterPres=84 WaterPres=10 Pressure=Permitted SafetyInjection=Off5 Block=On6 WaterPres=8 Pressure=TooLow

Test Case built from SMV counterexample

initial state


Testpredicate

4904/19/23

GENERATING A TEST SEQUENCE FROM AN OPERATIONAL SPEC

• The above trap property causes SPIN to construct a counterexample• This counterexample is the basis for the following test case:

Test Sequence Constructed from SPIN Counterexample

Step Monitored Var. Controlled Var. Step Monitored Var. Controlled Var.No. Value Value No. Value Value

1 Block On 11 WaterPres 42 Reset Off 12 Block On SafetyInjection Off3 Block Off 13 Block Off4 Block On SafetyInjection Off 14 Reset On SafetyInjection On5 Block Off 15 Block On6 WaterPres 3 16 Reset Off7 Block On 17 WaterPres 58 Reset On SafetyInjection On 18 WaterPres 69 Block Off 19 WaterPres 9

10 Reset Off 20 WaterPres 10 SafetyInjection Off

Pressure = TooLow @T(WaterPres Low) Pressure’ = Permitted

assert(CasePressure)! = 1Trap Property

5004/19/23

ACHIEVING BRANCH COVERAGE(ALSO CALLED DECISION COVERAGE)

Our technique, called “branch coverage,” uses the following rules to ensure coverage

1. In each event table, each event is tested at least once. 2. In each condition table, each condition not equivalent to

false is tested at least once.3. In each event table, in each mode, each no-change case is

tested at least once.

To produce more test cases, rule 3 can be replaced with a

stronger rule:3’. In each event table, in each mode, a change in each

monitored variable that does not change the value of the variable the table defines is tested at least once.

5104/19/23

AUTOMATIC GEN. OF TEST CASES:EXPERIMENTAL RESULTS

SPIN vs. SMV• SPIN produces very long counterexamples, while SMV produces the shortest

possible counterexamples

• But, SMV produces more test sequences than SPIN

• Also, SMV does poorly on specs with wide numerical ranges and on large specs

Infeasible Test Cases• Some predicates define an impossible state transition

• By analyzing a test predicate, we can determine whether a test case is infeasible

– Apply assumptions, e.g., a transition from TooLow to High is ruled out because WaterPres can only change by 3

– Apply state invariants, e.g., IgnOn becomes false when CC mode doesn’t change

Spec No. of No. of Vars Preds SPIN SMV SPIN SMV SPIN SMV SPIN SMV

Small SIS 6 33 7 14 5 11 73s 3.7s 280 62Large SIS 6 33 12 14 3 11 165s 4099s 10,529 778Cruise Cont. 5 27 19 23 7 15 100s 5.1s 245 66

WCP1 55 50 15 none 10 none 500s out of mem. 4795 none

Total Test Cases Useful Test Cases Exec. Time Total Steps

APPLYING STATE INVARIANTS

APPLYING STATE INVARIANTS

5304/19/23

USE OF STATE INVARIANTSIN SOFTWARE DEVELOPMENT

• Validation of requirements specification– show invariants to domain experts to determine whether specification correctly captures the

required behavior

• Verification of requirements specification– use invariants as auxiliary lemmas in proving that the specification satisfies properties of

interest– use invariants and “Incremental Compositional Proof Rule” to prove properties more

efficiently (Jeffords and Heitmeyer)

• Generation of counterexamples in formal analysis of spec– use invariants to rule out candidate counterexamples (e.g., unreachable state

pairs)

• Specification-based generation of test cases– use invariants to rule out infeasible test cases (e.g., a state invariant rules out a

given state transition)

• Optimizing code generated from the specification– use invariants to detect parts of the specification that would lead to dead code

(e.g., unreachable code) or redundant code

APPLYING STATE INVARIANTSIN VERIFICATION

APPLYING STATE INVARIANTSIN VERIFICATION

5504/19/23

MORE EFFICIENT VERIFICATION USING COMPOSITION AND INVARIANTS

Incremental Compositional Proof Rule Makes formal analysis more efficient.a. Divide system into subsystems 1 and . 1 is based on one or more

dependent variables from which invariants P constructed . based on remaining vars.

b. Introduce invariants P of 1 as additional constraints in .

c. If we can prove properties of under the constraints P, then the original system satisfies the propertiesINCREMENTAL COMPOSITIONAL PROOF RULE1 (ICPR)

Given two “compatible” subsystems 1 and , suppose P is a state invariant, and we want

to prove Q. Then, if 1 satisfies P and satisfies P Q, then 1 satisfies Q.

“” is the composition operator

Let represent the CD I CD I spec, IM the

invariants derived from the mode machine M, and suppose Q1, Q2, and Q3 are

properties CD ICD I must satisfy

• Because IM is an invariant, M satisfies IM • With a theorem prover, we showed

\ M satisfies IMQi, i=1,2,3 • By ICPR, (\ M M) sat. Qi, i=1,2,3

Analysis without composition required 660s, whereas analysis with composition Analysis without composition required 660s, whereas analysis with composition required 194s. Thus, applying the proof rule gives a required 194s. Thus, applying the proof rule gives a three-fold speed-upthree-fold speed-up. .

Analysis without composition required 660s, whereas analysis with composition Analysis without composition required 660s, whereas analysis with composition required 194s. Thus, applying the proof rule gives a required 194s. Thus, applying the proof rule gives a three-fold speed-upthree-fold speed-up. .

EXAMPLE

1Halbwachs, 1992

APPLYING STATE INVARIANTSIN OPTIMIZATION

APPLYING STATE INVARIANTSIN OPTIMIZATION

SCR TabularSCR TabularSpecSpec

IntermediateIntermediateSpecSpec

OptimizedOptimizedSpecSpec

SourceSourceCodeCode

APPROACHAPPROACH

• Apply a sequence of Apply a sequence of transformations totransformations to the tabular specthe tabular spec

• Prove that each Prove that each transformation istransformation is a refinement of the a refinement of the preceding specpreceding spec

• This process produces This process produces a a provably correct,provably correct, efficientefficient program program

Original specOriginal spec produced producedby a userby a user

Use a Use a grammargrammar and a set of and a set ofsemantic rulessemantic rules to translate the to translate thetabular spec to an equivalent tabular spec to an equivalent intermediate representationintermediate representation

To produce To produce efficient codeefficient code,,apply a set of apply a set of optimizationoptimizationtechniques to the spectechniques to the spec

Transform the optimizedTransform the optimizedspec into spec into source codesource code (e.g., (e.g.,C or Java)C or Java)

prove refinementprove refinement

prove refinementprove refinement

equivalenceequivalence

SYNTHESIZING SOURCE CODESYNTHESIZING SOURCE CODEFROM SPECIFICATIONSFROM SPECIFICATIONS

5804/19/23

RELATED WORK

Optimization– R. Paige et al., "Finite differencing of computable expressions," TOPLAS, 1982.

Refinement– D. Smith, "KIDS: A semiautomatic program development system,” IEEE TSE,

1990.

– ...

On-the-Fly Translation Validation– A. Pnueli, Siegel, and Singerman, “Translation validation,” Proc. 4th Intern. Conf.

on Tools and Analysis of systems (TACAS ‘98), LNCS 1384, Springer.– G. Necula, "Translation validation for an optimizing compiler," Proc. PLDI, 2000.

5904/19/23

ELIMINATE PARTS OF THE SPECTHAT ARE UNREACHABLE

Unreachable parts of the spec will lead toUnreachable parts of the spec will lead to dead dead codecode


GENERATED STATE INVARIANT

MODE PressureTooLow, @T(Block=on) @T(Pressure=High)Permitted WHEN Reset =off OR @T(Reset=on)High False @F(Pressure=High)

Overridden'= true false

EVENTS

Overridden = true Pressure ≠ High

truetrue if @T(Block=on) WHEN Reset=off if @T(Block=on) WHEN Reset=off AND Pressure in {TooLow, Permitted}AND Pressure in {TooLow, Permitted} AND Overridden=falseAND Overridden=false

falsefalse if @T(Pressure=High)ORif @T(Pressure=High)OR @T(Reset=on}@T(Reset=on} WHENWHEN Pressure in {TooLow, Permitted}Pressure in {TooLow, Permitted} ANDAND Overridden=trueOverridden=true

OR OR @F(Pressure=High) WHEN Pressure = High@F(Pressure=High) WHEN Pressure = High AND Overridden=trueAND Overridden=true

Overridden’=Overridden’=

6004/19/23

ELIMINATE PARTS OF THE SPECTHAT ARE UNREACHABLE



GENERATED STATE INVARIANT

MODE PressureTooLow, @T(Block=on) @T(Pressure=High)Permitted WHEN Reset =off OR @T(Reset=on)

Overridden'= true false

EVENTS

Overridden = true Pressure ≠ High

truetrue if @T(Block=on) WHEN Reset=off if @T(Block=on) WHEN Reset=off AND Pressure in {TooLow, Permitted}AND Pressure in {TooLow, Permitted} AND Overridden=falseAND Overridden=false

falsefalse if @T(Pressure=High)ORif @T(Pressure=High)OR @T(Reset=on}@T(Reset=on} WHENWHEN Pressure in {TooLow, Permitted}Pressure in {TooLow, Permitted} ANDAND Overridden=trueOverridden=true

Overridden’=Overridden’=

6104/19/23

IDENTIFY PARTS OF SPECTHAT ARE UNNEEDED

Row Old Mode M Event New Mode M'

1 Off @T(IgnOn) Inactive2 Inactive @F(IgnOn) Off3 Inactive @T(Lever=const) WHEN EngRunning Cruise

AND NOT Brake AND IgnOn

4 Cruise @F(IgnOn) Off5 Cruise @F(EngRunning) Inactive6 Cruise @T(Brake) OR @T(Lever=off) Override7 Override @F(IgnOn) Off8 Override @F(EngRunning) Inactive9 Override [@T(Lever=resume) OR @T(Lever=const)] Cruise

WHEN NOT Brake AND IgnOn AND EngRunning

These parts of the spec would lead to These parts of the spec would lead to unnecessary codeunnecessary codeThese parts of the spec would lead to These parts of the spec would lead to unnecessary codeunnecessary code

GENERATED STATE INVARIANTS

M = Inactive IgnOnM = Override IgnOn EngRunning

TWO APPROACHES TO USING FORMAL METHODS

TWO APPROACHES TO USING FORMAL METHODS

6304/19/23

USE OF FORMAL TECHNIQUESBY PRACTICING ENGINEERS

TWO APPROACHES • Practitioners will depend on experts to apply the techniques

– This currently is the predominant approach• Practitioners themselves will apply the formal techniques

and their supporting tools– Movement in this direction is urgently needed– Better education of practitioners required

But, before practitioners can apply formal techniques and their support tools directly,

major obstacles must be overcome

But, before practitioners can apply formal techniques and their support tools directly,

major obstacles must be overcome

6404/19/23

MATHEMATICS VS.ENGINEERING

MATHEMATICALMATHEMATICALRESOURCESRESOURCES

(E.G., THEORIES)(E.G., THEORIES)

MATHEMATICALLY MATHEMATICALLY WELL-FOUNDEDWELL-FOUNDED

SOFTWARESOFTWAREENGINEERINGENGINEERING

DISCIPLINEDISCIPLINELogics (predicate, 1st order,Logics (predicate, 1st order, higher order, etc.)higher order, etc.)Automata models Automata models Theories underlying decisionTheories underlying decision

proceduresproceduresTheories of composition, Theories of composition, refinement, etc.refinement, etc.......

Humans use this discipline,Humans use this discipline,with support from tools,with support from tools,

to produce high-quality softwareto produce high-quality software

Problem: How to achieve this?Problem: How to achieve this?

6504/19/23

WHAT RESEARCHERS CAN DO TO MAKE FORMAL TECHNIQUES EASIER TO USE

• Notation that is easy to learn and understand (e.g., tabular) with an explicit formal semantics

• Model checking using automatic abstraction

• Integration of decision procedures with the formal techniques

• Pushbutton analysis– e.g., automatic consistency

checking

• Understandable feedback when an error is detected

• Automatically generated invariants

• Theorem provers customized for a particular class of systems– e.g., TAME allows a user to

specify and reason about automata models

• Theorem provers that are more natural and easy to use

– use strategies so that a step in the mechanized proof corresponds closely to a step in a hand proof

– generate natural language explanations

We need more good violins and less reliance on highly talented violinists

We need more good violins and less reliance on highly talented violinists

Moshe VardiMoshe VardiCAV ‘98CAV ‘98

6604/19/23

MAKING FORMAL TECHNIQUES MORE ATTRACTIVE TO SOFTWARE DEVELOPERS

• Integrate the formal techniques with a simulator– simulation helps convince customer that you know about his domain

– simulation can be used • to validate the specification, especially if one adds a fancy graphical interface

• to demonstrate/validate counterexamples produced by a model checker

• Integrate the formal techniques with software testing

• More generally, integrate the formal techniques into the software developer’s process

WEAPONS CONTROL PANEL

CRYPTODEVICE

FLIGHTPROGRA

M

6704/19/23

TRANSFERRING FORMAL TECHNIQUESTRANSFERRING FORMAL TECHNIQUESAND THEIR SUPPORT TOOLS TO AND THEIR SUPPORT TOOLS TO

PRACTICEPRACTICE• To some extent, transferring formal techniques

and supporting technology is a non-technical problem

• Best hope is– education and training– finding champions, i.e., people in industry who are

willing to try something new AND have a problem that the techniques and tools solve

basicresearch

use oftechnology by“risk-tolerant”

ind’l users

technologybecomes anindustry standard

increasing use of technology in ind’l

pilot projects

no. ofusers

time

6804/19/23

WIDER USE OF FORMAL TECHNIQUES BY INDUSTRY: INCENTIVES

• More demands (e.g., by governments) for convincing evidence that a high assurance software product satisfies its requirements

– Examples: In the U.S., a number of products are being evaluated against the Internat. Common Criteria (e.g., firewalls, smartcards, etc.)

– As of July, 2002, the U.S. Navy is requiring all of its “security products” to satisfy the Common Criteria– our group is developing a formal spec and verification of the separation kernel of a crypto system; without

an ICC Level 7 eval., NSA will not certify the device

– in the U.S., federal agencies, such as the Food and Drug Admn. and the Nuclear Regulatory Comm., also want more assurance of the correctness of safety-critical systems (e.g., medical devices, control systems for nuclear plants)

• Because software testing is enormously expensive, there is growing interest in industry in automatic generation of test cases

– e.g., three sites of Lockheed Martin are using the SCR tools in conjunction with a tool for automatic test case generation

– our group also has a contract with NASA to apply automatic test case generation to their Fault Protection Engine

– producing the test cases requires a formal spec!

6904/19/23

CONCLUSIONS

UTILITY OF TOOLS (AND FORMAL TECHNIQUES) IN DEVELOPING/EVALUATING SOFTWARE SYSTEMS

• Find errors people miss

• Help in validating the spec

• Support formal verification

• Reduce the time/effort required to construct test cases and run them

• Provide more confidence in testing by constructing a carefully constructed suite of test cases – Based on selected coverage criteria and a high-quality spec

• Support automatic construction of provably correct, efficient code

Libertates developers to do the hardLibertates developers to do the hardmental work required to developmental work required to develop

high assurance systemshigh assurance systems

Libertates developers to do the hardLibertates developers to do the hardmental work required to developmental work required to develop

high assurance systemshigh assurance systems

7004/19/23

QUESTIONS?QUESTIONS?

THE ENDTHE END

Documents

CONSTANCE HEITMEYER CENTER FOR HIGH ASSURANCE COMPUTER SYSTEMS NAVAL RESEARCH LABORATORY WASHINGTON, DC McMaster University March 17, 2003 TOOLS FOR BUILDING