Handbook for the Computer Security Certification of Trusted Systems

Handbook for the Computer

Security Certification of

Trusted Systems

Chapter 1: Overview

Chapter 2: Development Plan

Chapter 3: Formal Model of the Security Policy

Chapter 4: Descriptive Top-Level Specification

Chapter 5: Design

Chapter 6: Assurance Mappings

Chapter 7: Implementation

Chapter 8: Covert Channel Analysis

Chapter 9: Security Features Testing

Chapter 10: Penetration Testing

For additional copies of this report, please send e-mail to

[email protected], or retrieve PostScript via

http://www.itd.nrl.navy.mil/ITD/5540/publications/index.html

A Chapter of the

Handbook for the Computer Security Certication of

Trusted Systems 1

John M c

Hugh, Principal Investigator

TektronixProfessor

Department of Computer Science PortlandState University

POB 751

Portland, Oregon, 97207-0751

Revised Final Rep ort {16 Decemb er 1995

1

PreparedbytheUniversityofNorthCarolinafortheNavalResearchLab oratoryundercontract N00014{91{K{2032

1 Intro duction 4 1.1 What isa CovertChannel? : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 1.2 WhyConsiderCovertChannels? : : : : : : : : : : : : : : : : : : : : : : : : 6 1.2.1 Evaluators: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6 1.2.2 The DesignatedAccreditationAuthority(DAA) : : : : : : : : : : : 7 1.2.3 Developers : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 7 1.2.4 Purchasers : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 7 1.2.5 End users : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 7 1.3 Coding andSignaling: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 1.4 CharacterizingCovertChannels: : : : : : : : : : : : : : : : : : : : : : : : : 8 1.4.1 Storagevs. Timing : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 1.4.2 Sendersand Receivers : : : : : : : : : : : : : : : : : : : : : : : : : : 9 1.4.3 Levelof Abstraction : : : : : : : : : : : : : : : : : : : : : : : : : : : 10 1.4.4 When isa channelharmful? : : : : : : : : : : : : : : : : : : : : : : : 10

2 System Characterizations 11

2.1 Levelsof System Sp ecication : : : : : : : : : : : : : : : : : : : : : : : : : : 11 2.2 System DescriptionIssues : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12 2.2.1 The systemmo del : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12 2.2.2 Completeness : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12 2.2.3 The Notation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 13 2.2.4 Formality : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 13

3 Dep endency Analysis 14

3.1 ResourceIdentication : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 15 3.2 Specication Decomp osition : : : : : : : : : : : : : : : : : : : : : : : : : : : 16 3.2.1 Guarded assignments: : : : : : : : : : : : : : : : : : : : : : : : : : : 16 3.2.2 Sourcesand Targets : : : : : : : : : : : : : : : : : : : : : : : : : : : 17 3.3 Code analysis issues : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 19 3.3.1 Localvariables : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 19 3.3.2 Procedures andFunctions : : : : : : : : : : : : : : : : : : : : : : : : 19 3.3.3 Side Eects : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21 3.4 Expression Decomp osition : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21 3.4.1 If Expressions: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21 3.4.2 Arraysand other structures : : : : : : : : : : : : : : : : : : : : : : : 22

4 Security Policy Issues 26 4.1 Linking p olicytoresources : : : : : : : : : : : : : : : : : : : : : : : : : : : 27

5 Lo oking for Channels 29

5.1 TheShared ResourceMatrix : : : : : : : : : : : : : : : : : : : : : : : : : : 29 5.1.1 The basicSRMformulation : : : : : : : : : : : : : : : : : : : : : : : 30 5.1.2 Adding detailtotheSRM : : : : : : : : : : : : : : : : : : : : : : : : 30 5.1.3 IdentifyingSecurityFlaws : : : : : : : : : : : : : : : : : : : : : : : : 32 5.1.4 Finding CovertChannels : : : : : : : : : : : : : : : : : : : : : : : : 33 5.2 InformationFlowFormulas : : : : : : : : : : : : : : : : : : : : : : : : : : : 36 5.2.1 Deriving SVCsfrom a detailedSRM : : : : : : : : : : : : : : : : : : 36 5.2.2 Reasoning ab outSVCs: : : : : : : : : : : : : : : : : : : : : : : : : : 37 5.2.3 Identifyingsecurity aws : : : : : : : : : : : : : : : : : : : : : : : : 38 5.2.4 Formal owviolations : : : : : : : : : : : : : : : : : : : : : : : : : : 38 5.3 Covert owtrees : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 39 5.3.1 Constructingcovert owtreesfrom dependencydata : : : : : : : : : 39 5.3.2 Identifyingsecurity aws : : : : : : : : : : : : : : : : : : : : : : : : 39 5.4 Non{interferenceformulations : : : : : : : : : : : : : : : : : : : : : : : : : : 40 5.4.1 Non-Interference : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 40

6 Analyzing Covert Channels 43

6.1 Exploiting SecurityFlaws : : : : : : : : : : : : : : : : : : : : : : : : : : : : 43 6.2 CovertChannelScenarios : : : : : : : : : : : : : : : : : : : : : : : : : : : : 44 6.2.1 Half Bit Mechanisms : : : : : : : : : : : : : : : : : : : : : : : : : : : 44 6.2.2 Signaling Proto cols : : : : : : : : : : : : : : : : : : : : : : : : : : : : 44 6.2.3 TalkingtoOutsiders : : : : : : : : : : : : : : : : : : : : : : : : : : : 44 6.3 TrustedApplications- Trustedtodo What?: : : : : : : : : : : : : : : : : : 45 6.4 AnalyzingThreats : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 45 6.5 ChannelCapacity: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 46 6.6 Countermeasures : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 46 6.6.1 Auditing: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 47 6.6.2 ReducingChannel Capacity : : : : : : : : : : : : : : : : : : : : : : : 47 6.6.3 Closingthe Channel : : : : : : : : : : : : : : : : : : : : : : : : : : : 47

7 Evaluating a CovertChannel Analysis 49

7.1 LookingatPlans : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 49 7.1.1 What istob e analyzed? : : : : : : : : : : : : : : : : : : : : : : : : : 49 7.1.2 When will CCAb edone? : : : : : : : : : : : : : : : : : : : : : : : : 50 7.1.3 Who isdoing thework? : : : : : : : : : : : : : : : : : : : : : : : : : 50 7.2 EvaluatingtheResults : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 51 7.2.1 What didthey nd? : : : : : : : : : : : : : : : : : : : : : : : : : : : 51 7.2.2 Howis theinvestigationdescribed? : : : : : : : : : : : : : : : : : : : 51 7.2.3 Lookingatlevelof eortexp ended : : : : : : : : : : : : : : : : : : : 51 7.2.4 Detecting\hand waving" : : : : : : : : : : : : : : : : : : : : : : : : 52

7.3 HowToHedge YourBets : : : : : : : : : : : : : : : : : : : : : : : : : : : : 52

8 Conclusions and Acknowledgments 54

A Mechanical Tools for CCA 59

A.1 TheGypsyInformationFlow Tool(GIFT): : : : : : : : : : : : : : : : : : : 59 A.2 InaFlow : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 60 A.3 TheEHDM MLSTool : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 60 A.4 OtherTo ols : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 60

B A worked Example 62

B.1 Requirements : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 62 B.2 ASkeleton: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 63 B.2.1 Preliminaries : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 63 B.2.2 Files : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 63 B.2.3 The FileSystem and SecurityState : : : : : : : : : : : : : : : : : : 63 B.2.4 Requestsand Responses : : : : : : : : : : : : : : : : : : : : : : : : : 64 B.2.5 The TCBInterface : : : : : : : : : : : : : : : : : : : : : : : : : : : : 64 B.3 TheDTLS: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 64 B.3.1 Data andData Structures : : : : : : : : : : : : : : : : : : : : : : : : 64 B.3.2 Internalroutines : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 65 B.3.3 The TCBroutines : : : : : : : : : : : : : : : : : : : : : : : : : : : : 67 B.4 DTLSAnalysis : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 69 B.4.1 The CanonicalState : : : : : : : : : : : : : : : : : : : : : : : : : : : 69 B.4.2 Dep endencyAnalysis: : : : : : : : : : : : : : : : : : : : : : : : : : : 70 B.5 SecurityAnalysis : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 77 B.6 TheChannel : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 78

Introduction

Covert channel analysis can be viewed either as an arcane asp ect of computer security havinglittle todo with\real" securityissues orasthe keyto protectingnominally secure systems against a wide varietyof b oth internal and external threats. Which view should b e adopted is a function of a number of factors including the nature of the material to b e protected: its sensitivity, size, and timeliness, and the threat environment to which the system will be exp osed. Under the TCSEC [28], covert channel analysis is required starting at the B2 level of assurance with increasingly rigorous analysis required for B3 andA1 systems. Thisis consistentwiththeviewthat highassurance securitysystemsare primarily required to protect highly sensitive information, to counter serious threats, or b oth.

In the introduction, we will provide an overview of covertchannel analysis,b eginning withadenition of covertchannelsand adiscussion ofthenature of theissues concerning them that aect the various users of this handb ook. Since covert channels involve (often complex) coding and signaling mechanisms, these will b e discussed. The introduction concludeswitha characterizationofcovertchannels.

Covertchannelanalysis can,and should, b ep erformed on systemdescriptionsranging fromabstract mo delstomachineco de. Section2 discusses issues ofsystemrepresentation and the suitability of various representation paradigms forcovert channel analysis. Since covert channels are built from information ows within a trusted computing system, one oftherststepsinp erformingananalysisis theabstraction ofp otentialinformation ows fromadescription ofthe system. A formalismforp erforming this task,calleddependency analysis is presented in section 3. Dependency analysis provides a general framework in whichanysuitablesystemrepresentationcanb echaracterized,providingoneof theinputs foracovertchannel analysis.

Covertchannelscanb eeitherinno cuous orharmful. Inno cuouschannelsareconsistent withtheintentofsystem'ssecurityp olicy. Theymayresultinsurprisingsystemb ehaviors, but do not place the system or the information that it protects at risk. Harmful covert channelsareinformation owsthatarecontrarytotheintentofthesystem'ssecuritypolicy. Insection 4 theproblem of extending thesystem security p olicyto coverthe information owsrevealed bydependency analysisis considered.

Given an extended securityp olicy applied tosystemdep endencies, a searchfor covert channelscanb ep erformed. Thissearch, whichisdiscussedinsection5,canb edoneusing

basedoninformation owformulas (alsoknownassecurityvericationconditions),covert owtrees, orother techniques. It can also b e doneusing \non-interference" formulations thatarguably characterizeb oth highlevelsecurityand covertchannels.

If the search for covert channels exp oses a aw in the system, the aw must b e ana-lyzedtodetermineitsp otentialsignicance. Thisincludesthedevelopmentofscenariosfor exploiting the aw,threatanalysis, thedetermination of thechannelcapacity,etc. Coun-termeasuresrangingfrom auditingtheuseof thechanneltorestructuring thesystemmay apply. Section 6coversthis analysis.

By the end of section 6, the evaluator will have a go o d view of the techniques that are useful for performing a covert channel analysis on a system under construction and, we hop e, some insight into techniques for designing the system so as to minimize the intro ductionofcovertchannels. Section 7providesguidance forpurchasersand evaluators in evaluating a covert channel analysis plan. This should b e of interestto developers as well. The handb ook prop er concludes with an annotated bibliography that provides the interested reader with a means to gain further knowledge of the subject. Although the handb o ok is primarily intendedfor the evaluators of B2 orB3 systems where mechanical covert channel analysis to ols are not required, readers should b e aware of the to ols that haveb eendevelopedtosupp ortthevericationsystemsusedforA1systemsaswellassome exp erimentalto ols discussedin the recent literature. These are discussedin App endix A. A small example of a manualcovert channelanalysis using the shared resource matrix is presentedinApp endix B.

1.1 What is a Covert Channel?

MarvSchaefer,formerchiefscientistoftheNationalComputerSecurityCenter,once char-acterized covert channels [35] as system b ehaviors that surprise the system's developers. We oerthe followingasa workingdenition of theterm\CovertChannel."

A covert channelis a mechanism that canbe used to transfer information from oneuserofasystemtoanotherusingmeansnotintendedforthispurp ose bythesystem develop ers.

Thisdenitionisdelib eratelyvague(Whatisinformation? What isintent?) andomits anydiscussionofsecurity. Thedenitionresultsfromthedesiretohaveanintuitivenotion ofasecurecomputer systemthatiseasilyunderstandable toa useraccustomedtomanual pro ceduresand topresentunobvious awsinthesystem asspecialcases. Whether ornot thisisthe b estapproach totheproblem isopen todebate, butit istraditional andwidely accepted.

Inthepen andpap er world,accesstosensitiveinformationiscontrolledbyp eoplewho are trusted to give the information (usually in the form of documents) only to p ersons whoseidentityandwhoseauthorizationtoobtaintheinformationhavebeenestablishedby anappropriateauthority. Ina securecomputer system, theinformationis typicallystored in les or asso ciated with devices such as communication lines. Once the user's identity and authorization are established, theuser's access(actually accessby programsthe user runs) to the information is mediated by the trusted portion of the system. This view

in which the system's security state is characterized by a matrix that shows the nature of the access p ermission that active, information free, entities called \subjects" have to passive,information containing,entitiescalledobjects. Inthismodel, thesystemissecure if all subjects have clearances that are higher than (dominate) the classications of the objectstowhichthey haveread orobserveaccess(the simplesecurityprop erty)and ifthe classication of eachobject to whicha subject haswrite or modify access dominates the classicationof allobjects towhichthesubject hasreadaccess.

While this mo del is intuitive and captures the essence of the pen and paper world,it is not adequate. Let us supp ose that we have given a reader a classied do cument and lo ckedb othina ro om. Now,supp osethatthereadersends thecontentofthedo cumentto anuncleared confederate in thenext room bytappingMorse co de on his ro om'sradiator. Thisis,in eect,a covertchannelsincetheradiator and its pip es wereneverintendedfor communication by the building's designers. While this scenario is somewhat far fetched (Why not just tell the confederate later? The cleared user is violating trust, etc.), its analog in the computer system is not. Although the user is cleared and trusted, there is no assurance that the programs the user uses to access and pro cess classied data are trustworthy. Aswewillsee,mostsystemshavefeaturessuchaslelo cks,devicestatusbits, amemoryp o ol,etc. thataresharedb etweenusersatdierentlevels. Eachsuchfeatureor resourcehasattributesthatcanoftenb emanipulatedtoformthebasisforacovertchannel. Ifwep ositmalicious,untrustedsoftware,usedbytrustedusers,covertchannelsthatsignal information in violation of the intent of the system security p olicy using mechanisms not intendedforexplicit information transferare a distinctp ossibility.

1.2 Why Consider Covert Channels?

For a system to b e evaluated at the B2 level of the TCSEC or ab ove, a covert channel analysisis required. Forsome, this alone may b ea sucientreasontob econcerned. The more curious will probably want toprob e deep er. The following discussions will indicate theconcernsthat applytothe variouscommunitiesofinterestthat usethis handb o ok.

1.2.1 Evaluators

Evaluatorsrequireathoroughunderstandingofcovertchannels. Theyalsoneedtheability to judge the job that the developer has done in dealing with covert channels in both the design and analysis phases of the eort. In addition to evaluating the developer's eorts in analyzing a system for covert channels, the evaluator should also consider the appropriateness of design decisions made by the developer and their impact on system security. Since current practice under the TCSEC divides security into twoareas, access control, which is mediated by the system's MAC and DAC policies and covert channels, which are unmediated, an inappropriate choice of \objects" can result in serious system insecuritiesb einglab eledas\covertchannels." Inasystemforwhichcovertchannelanalysis isrequired,this may b enotbe seriousbutitcanlead toafalse senseofassurance inaB1 system.

Inanaccreditationpro cess,itisnecessarytoconsiderb oththreatsagainstthesystemand thenature of theinformation to b e protected as well as the vulnerabilities of the system b eingexamined. TheDAAmustweightheoperationalrisksassociatedwiththedeployment ofalessthanp erfectsystem. Inparticular,theDAAmustbeable toevaluatethemission risksthat arisedue tothedeployment ofa systemthatcontains exploitableinsecuritiesin theformof covertchannels.

1.2.3 Develop ers

Develop ersof high assurance systems forwhichcovert channelanalysis is required should haveathoroughunderstandingofb oththemechanismsthatmakecovertchannelspossible, particularlythenatureofresourcesharing,andoftheanalysistechniquesthatareavailable toidentifythem. Whileitisdiculttoeliminateallcovertchannelsinacomplexmultilevel securesystem,carefuldesignsupportedbyearlyanalysiscanminimizetheimpactofcovert channels. Developersshould learn tothinkintermsofp otentialcovertchannelsinmaking design decisions. Any design decision that involves the sharing of some system resource among usersat dierent security levels has thepotentialfor intro ducinga covert channel intotheresulting system. The designer should b eawareof this p otential and should take stepstocontrolitinwaysthatcanreduce its impact onoverallsystem security.

1.2.4 Purchasers

Pro curementocers and othersp eciers ofpurchases ofmultilevelsecuresystemsneedto b eawareof the nature of covertchannels and the mechanisms that permit them in order tomatch the system pro cured with its mission. This analysis needs to take into account thenature of thethreats towhichthe systemwill b e exp osed aswell asthenature of the materialthatitwill protectandtherangeof securitylevelsoverwhichitmustop erate. In considering covert channelissues, it is imp ortant to consider the quantityof information that must be compromised to cause a serious breach of security. Systems in which a compromiseof a few hundred bits (say a master encryption key) is serious are much less tolerant ofcovertchannelsthan systemsinwhichmegabytes (sayahighresolution image) mustb ecompromisedfora serious problem toexist.

1.2.5 End users

Endusersneedtohaveanunderstandingofb oththesecuritymechanismsandthepossible vulnerabilitiesof thesystems that they use. This is just as imp ortant for high assurance systems where users should be alert for anomalous behaviors that may indicate security compromisesasitisforlowassurancesystems whereusersshouldb eawareofthesystem's limitations. Usersshouldb eawarethatinthecaseofB1systems,forwhichcovertchannel analysis is not required, develop ers may try to categorize serious security aws as covert channelstoavoiddealingwiththem. Usersoflowassurancesystemssuchascompartmented mo deworkstationsshould b e awareoftheir limitations[6].

\One if by land, two if by sea." Covert channels involve messages transmitted through mechanisms notnormally intended for communication. This typicallyrequires some kind of enco ding. If, as was the case with Paul Revere, the number of messages is limited, a very simple enco ding may b e used. In the general case, the message vo cabulary may b e op enended, and a general enco ding mustb e develop ed. The signaling mechanismthat is usedtotransmit theenco dedmessage willinvolvethemanipulationof someattributeof a resourcethat isshared betweenthesender and receiver.

Typically, the real users of a covert channel are computer programs that have b een subverted for this purp ose. The human user who invokes the program is unaware that sensitive information is b eing compromised by the program. Because the compromise is donebytheprogramratherthanahuman,itcanpro ceedatelectronic,ratherthanhuman sp eeds. Thismeansthat,evenifanelab oratesequence ofactions isrequiredtotransmita singlebitofinformation,itisp ossibletotransmithundredsorthousandsofbitsp ersecond withhighreliability. Inashared,unipro cessorenvironment,contextswitchingtimeisoften themost imp ortant factor limiting covert signaling rates. In multiprocessor systems, this may not b ea factor, and mechanismsthat supp ort covert signaling rates on the order of hundreds of megabitsp ersecond haveb een p osited[38].

1.4 Characterizing Covert Channels

Covertchannels canb e characterizedin a varietyof ways, based on the mechanismsthat theyuse, thelevelofabstraction atwhichthey app ear,oron thenature ofthesenderand receiver.

1.4.1 Storage vs. Timing

Traditionally, covert channelsare characterized as storage or timing channels. As we will see, this characterization is somewhat articial, but it it useful because it describ es the fo cusoftheanalysisusedtoidentifythechannels. Giventhatacovertchannelinvolvesthe manipulationof somesystem resource or resource attribute(such aswhether or nota le isinuse), wecancharacterizea covert channelas a storagechanneliftherecipient ofthe signaledinformationperceivesthesignalasa changeinthevalueoftheshared resource or attribute. Similarly,iftheinformationisperceivedviaachangeinthetimerequiredforthe recipient top erform someaction, thechannel maybecharacterizedasa timingchannel.

Kemmerer[13] givesthefollowingdenitions ofstorage andtiming channels:

\In order to have a storage channel, the following minimum criteria must be satised:

1. Thesendingandreceivingpro cessesmusthaveaccesstothesameattribute of a shared resource.

2. There must be some means by which the sending pro cess can force the shared attributetochange.

attribute change.

4. Theremustb esomemechanismforinitiating communicationb etweenthe sending and receiving processes and for sequencing the events correctly. This could b eanotherchannelwitha smaller bandwidth.

. . .

The minimum criteria necessary in order for a timing channel to exist are as follows:

1. Thesendingandreceivingpro cessesmusthaveaccesstothesameattribute of theshared resource.

2. The sendingand receiving pro cesseshaveaccess toa timereference, such as areal{time clo ck.

3. Thesendermustb ecapableofmo dulatingthereceiver'sresponsetimefor detecting a changeintheshared attribute.

4. Thereissomemechanismforinitiating thepro cessand forsequencingthe events."

Implicitin the timing channelcriteriais the abilityof either thesender orthe receiverto changethevalueof theshared attributeusedtoimplement thetiming channel.

Since high level sp ecications typically do not contain timing information, the covert channelanalysistypicallyp erformedontheDTLSorFTLSofasystemisastoragechannel analysis. Timingchannel analysesare typically much more ad ho c in nature since timing b ehaviorismostoftenmanifestinco deexecutiontimingorindeviceresponsetimes,factors thatareusuallynotconsideredatthespecicationleveland mayb ediculttodetermine even attheco de level.

Notethatthesamemechanismcanmanifestitselfaseitheratimingorstoragechannel. The disk channel discussed by Wray [39] is a go od example. In many cases, the value of some storage resource, such as the disk arm p osition register, is correlated with some temp oralbehavior,suchasseektime. Thusachannelinvolvingdiskarmmanipulationcan manifestitselfas either a timing orasa storage channel. Note also that theterm \clo ck" can be used rather loosely. All that is really necessary to form a clo ck for the purp oses of exercisinga timing channelis forthe receiver tob e able to observe the order in which eventsoccurand forthesenderto b eabletoin uencethat order.

1.4.2 Senders and Receivers

A pedantic denition of covert channels requires that the senderand receiverb e subjects (intheBell andLa Padulasense)underthecontroloftheTCB.Inatraditional multiuser system,thisisareasonablerestriction. Indistributedsystems,especiallywidelydistributed systems,thep ossibilityofsignalingmechanismsinwhichtherecipientisnotasubjectexists. In these cases, the recipient is typically an intruder or wiretapp er on the transmission medium used for the distribution. We prefer not to characterize such channels as covert channels. The reasons for this are discussed in [4], and have todo withthe fact that the receiver and possibly resource attributes used in the exercising the channel may not b e

covertchannels. Nonetheless, wenote thatsomeofthetechniquesthat canidentifycovert signalingmechanismscan identifywiretappingchannels, aswecall them, givena suitable systemrepresentation.

1.4.3 Level of Abstraction

Covertchannel analysis can b ep erformed on anylevel of system representation from ab-stract mo dels tomachine code (and hardware). By analyzing high level abstractions, se-curity aws can b e identied at a stage of development where they are easier to x. A awintroduced early inthedesignpro cess is,ineect, arequirementforthesystemtob e insecuresinceit b ecomespartof thesp ecicationfor renement of thesystemdesign.

By performing covert channel analyses rep eatedly as the system is rened, the intro-ductionofsecurity awscanb eminimizedandappropriatecountermeasuresintroduced to dealwith awsthatmustb epresentforreasons offunctionalityorp erformance.

Atthe hardware level, it is often the case that little exibility is available. Hardware isoftenchosenb eforesystemdesigniscomplete,orthesystemmustb ehostedon existing hardware. Thehardwarebaseislikelytocontainmechanismsthatcanbeusedtoconstruct covert channels. Typical features include memory management units, shared memory or I/O busses, device controllers, etc. If a high capacity signaling mechanism is discovered in the hardware, there seems to be little choice other than to avoid its use altogether or todesign the system sothat the mechanism do es not p enetrate a security b oundary. As shared memory multipro cessors b ecome more common, this is likely toprove increasingly dicult.

1.4.4 When is a channel harmful?

Many covert channels are benign. Benign channels usually p ossess one of the following characteristics:

 Thesenderand receiverarethesamesubject

 Thesender is allowed tocommunicatedirectly with the receiver underthe system's securitypolicy.

 Thereisno eectivewaytoutilizethe signalingmechanism.

Foracovertchanneltob eharmful,thesendermustb eforbiddentocommunicatewith thereceiverunderthesystem'ssecuritypolicyandtheremustbeaneectivepro cedurefor exploitingasecurity awtoformachannelfortransmittingausefulquantityofinformation fromsendertoreceiverinatimelyfashion. Notethatpartofthis denitionisafunctionof thesysteminquestionandpart ofit isa functionoftheenvironmentinwhichthesystem isused. Forthis reason,the decision todeployaless thanp erfect systemmustultimately liewiththeaccreditingauthority,whomustrelyoninformationsuppliedbytheevaluators, withp ossibleinputsfrom theusersand developers.

System Characterizations

Covert channel analysis can be conducted on anylevel of system description from highly abstract sp ecications toimplementationcode. This section will discuss the suitabilityof variouslevels and forms of system representations forp erforming covertchannelanalysis. The primary system description for p erforming a covert channelanalysis for a system to b eevaluatedattheB2orB3levelsofthe TCSECisthedescriptivetoplevelspecication (DTLS).ThischaracterizestheTCBofthesystemintermsofitsinput,outputs,exceptions, and error messages. The preparation of a DTLS is covered in a related p ortion of this handb o ok [29] and will not b e discussed in detail here. However, there are a numb er of issues that must b e addressed if the DTLS is to be suitable for covert channel analysis purp oses. In addition, it is p ossible, and usually desirable to perform a covert channel analysison systemcharacterizationsother thanthe DTLS.The benetsanddiculties of such anapproach will alsob e discussedhere.

2.1 Levels of System Specication

Although the DTLS is, under the TCSEC, the primary description and sp ecication for the system under evaluation, other forms of specication will b e created during system development. These may range from higher level abstract mo dels to lower level co ding sp ecications and the co de itself. Since the entire family of descriptions should be con-sistent, it is likely that a security aw that is introduced in a high level abstraction will p ersist ina low level design and inthe implementation. For this reasonit is desirable to p erformapreliminary covertchannelanalysisonthehighleveldesigns,reningthedesign onlywhenitssecuritycharacteristicsandtheirconsequences areundersto o d. Current tech-niques forcovert channel analysis require examinationof thesystem as a whole, ignoring theinformation hiding and carefulstructuring that should b ethe result of go o d software engineering practices. This means that the eortrequired toanalyze a system for covert channelsisa function of thesizeof the systemb eing analyzed and of its complexity. The idealsituation would b e toanalyze themachine co de using the semantics of its hardware platform as a base. In practice, this is notfeasible. Analysis at the sourcecode level has b eencarried outexp erimentally[37],butwithinconclusiveresults. The DTLSorits more formal counterpart, the FTLS, are the traditional vehicles for covert channel analysis. If theyaresucientlydetailedandcomplete,asrequiredbytheTCSEC,itwouldseemtob e

channels. Unfortunately, this is not true. The TCSECrequires theDTLS tocapture the securityrelatedasp ects of thesystem'sb ehavior. Thisdo es notnecessarily includeawide variety of functionality that may b e used to build covert channels. Any system resource thatis shared b etween usersop erating at dierentlevelsis a p ossible vehiclefor building acovertchannel. Inrecentyears, channelshavebeenreportedthat usepro cess scheduling [12],diskseeks[39],and shared memorybusses inmultiprocessors [38]. Asaresult ofthis, athoroughcovertchannelanalysismustconsider implementationdetails thatintroduce or use resource sharing that is not apparent in the higher level sp ecications and that may not appear to b e security relevant. This may involve an analysis of hardware as well as software.

2.2 System Description Issues

At the implementation level, the security analyst do es not have much control over the way in which the system is describ ed. The programming language to b e used is usually prescrib ed. The hardware description is given(if at all) bythe vendor. At higherlevels, theanalyst mayhave somein uence. The followingissues should b econsidered.

2.2.1 The system model

ADTLScantakeonanumb erofforms. Thestatemachinemo delisthemostcommon. In astatemachinemo del,theTCBisviewedasanabstractstatemachinethatmakeschanges toorreturns information ab out an internal collection of resources inresp onse torequests made by users. The state machine app ears to b e the only sp ecication form that lends itselfeasily tocovertchannelanalysis. This isbecauseit isrelativelyeasy todemonstrate thata statemachinesp ecicationis denitionaland complete.

Thesuitability ofother sp ecicationforms, suchastrace sp ecications[26, 11]is open toquestion. Trace sp ecications allowa system tob e characterizedinterms of sequences of calls on system mo dules. The trace sp ecication denes which sequences are legal and the results of sequences that end in value returning op erations. A trace sp ecication is saidtob ecompleteifitsupportsa mo del. Thisnotion ofcompletenessis weakerthanthe notiondiscussedinthefollowingsectionasitallowsmultiplemodelswithpossiblydiering b ehaviors to satisfy a single trace sp ecication. For a trace sp ecication to completely denetheb ehaviorofa systeminawaythatsupp ortsacovertchannelanalysis,itapp ears that the sp ecication must b e both complete and total. All the mo dels of a total trace sp ecication are equivalent in terms of input and output b ehavior. Given a total and completetrace specicationfora system, it should be p ossible topro duce a mo del of the systemthatissuitableforp erforming acovertchannelanalysis. Thereare noexamples of thispro cess intheliterature,and someresearchisneededb eforethetechniqueisproposed fordevelopingareal system.

2.2.2 Completeness

Foranadequatecovertchannelanalysisitisessentialthattheanalyzedsystemdescription b ecomplete. Thisgenerallyrequiresadenitionalorcauseandeectstyleofsp ecication.

equalvalues. This do es nottelluswhyorhowthey b ecome equal. From acovertchannel standp oint, it may be crucial to know whether they are equal b ecause they are both set tosome constant value or b ecause they are b oth set to the value of some input variable. Similarly, leaving functions p ending or \To be determined" can inhibit a covert channel analysis since the analyst must assume that the function could obtain information from anywhere.

2.2.3 The Notation

Systemsp ecicationscanb epresentedina varietyofformsrangingfromnaturallanguage to mathematical notation. In general, the more precise and unambiguous the notation, theb etter thecovert channelanalysis. There aresubstantial b enets tousing mechanical to ols toaid in covert channelanalysis. The three analysis to ols discussed inAppendix A eachrequirethesp ecicationtob ewritteninaparticularformalspecicationlanguage. If develop erswho understand suchlanguages areavailable,they mayprovideadvantages for B2orB3 systems. Theuseof an approvedformalsp ecicationlanguage isrequiredforan A1system.

2.2.4 Formality

Inthe next section, we introduce dep endencyanalysis. This providesa way of extracting information owsfrom a systemdescription. Informalsystem descriptionstypicallyresult in informal information ow semantics and lead to imprecise dep endency analyses. As thedescriptivelanguagebecomesmore formally dened, itis usuallyp ossibleto deneits information ow semantics more precisely, as well. As a bare minimum, a well dened pseudo code notation should b e used forthe DTLS. More formal notations such as `Z'or VDMarepreferable.

Machine pro cessable specication languages such as those supp orted by the FDM, Gypsy, and EHDM systems are even more preferable since they have well dened infor-mation ow semantics as well as to ols to supp ort covert channel analysis based on these semantics. While the use of a formal sp ecication language is mandated by the TCSEC forA1 systems, such a language can b e b enecial fora lower assurance system and some consideration should b e given to using these languages for B3 systems, even if machine checkedsecurity pro ofswill notb ep erformed.

Dependency Analysis

Dep endencyanalysischaracterizesthesystemunder considerationintermsof its informa-tion ows. Thissectiondiscussesthesemanticsofinformation owanddevelopstechniques foranalyzingthe owsinavarietyofsystemrepresentationsrangingfromEnglishlanguage sp ecicationsand pseudo co detoformalspecicationlanguages andco de. The imp ortance ofa complete,denitional sp ecicationcannotb e overemphasized. Unless wecanassume thatthesp ecicationthatweareanalyzingexplainsallthechangesinthesystemresources andresource attributesthatcanb eobservedwhenthe systemis inop eration,theanalysis will b e incomplete. In the discussion that follows, it is assumed that the sp ecication is completeand denitional. In addition, we will assume that,when we discuss the changes observed asa resultof invokingagivenop eration, thechangesseenare,in fact,aresult of invokingthatoperation andnotanotherone.

Unlike otheranalyses that wemightp erform on a sp ecication(or on someother rep-resentation),dependency analysis is not concerned with what the system do es butrather with how it do es it. Since covert channels typically involve signaling co ded information throughvariationsinthevaluesofstorageitems orthrough thevariationofresp onsetime, we are only interested in how these variations can b e eected ordetected. We introduce thenotion ofa \dep endency"asan abstraction torepresentthese variations. We saythat a dep endencyfrom onesystem resource attribute, say A,to another, say B, underan op-eration,O, existsifitisp ossible toinfer somethingab out thevalueofAbyrstobserving B,theninvokingtheoperationOandthenobservingBagain. Notethatitisnotnecessary todeterminethevalue ofA inthis manner. It is sucienttob e abletoconform orrefute some conjecture ab out the value of A. B may b e a storage resource attribute capable of director indirect(via anotherdep endency) observation. It may also b e atiming resource attribute,suchasthetimerequiredtoexecute O. Inthelatter casetheinitial observation mayb eanotherinvo cationofthe op erationand theconjecturemaybethatthe value ofA haschanged.

The resource attributes involved in a given dependency are characterized as Targets, Sources, and Guards. Targets and Sources are reasonably intuitive, being the resource attributes modied by the op eration in question and the resource attributes from which themo died value(s) werederived. Guards app ear when the modication is conditional, that is, the modication may or may not o ccur dep ending on the values of one or more resource attributes. If an op eration is conditional, the resources and resource attributes

b ecause they guard or control the mo dication decision. Note that it is p ossible to infer somethingab outthevaluesoftheguardresourcesfromobservingachangeorlackofchange inatargetwhen an operationinvolvinga guarded mo dicationofthe targetisinvoked.

Formally,wedene adep endencyasatriple,fT;fSg;GgwhereT isa systemresource orresource attributethat istheTarget ofthedependency,fSgisa setofsystemresources andresource attributes thatare theSourcesof thedep endency. G isa b o olean expression calledtheGuardofthedependency. Information owsfrom eachs2fSg toT ifandonly ifGevaluatestoTrue. Theobjectiveofdependencyanalysisistoidentifysystemresources and resource attributes whose values change when system op erations are invoked and to determineboththesources of themodiedvaluesand the circumstances underwhichthe mo dicationsoccur. This is donein twoparts: the identicationof system resources and resourceattributesandthedecompositionofthesystemsp ecicationtoidentifyindividual targetmo dications.

3.1 Resource Identication

Therst stepinp erforming adep endencyanalysisistoidentifytheresourcesandresource attributes under the control of the Trusted Computing Base (TCB) of the system being analyzed. This isrelatively straightforwardifthe TCB sp ecication is describ edin terms of a formal sp ecication or pseudo co de (assuming that the specication or pseudo co de is relatively closetotheimplementationinlevelof detail),butismore dicultforb othcode and informal natural language specications. Storage resources and attributes are byfar theeasiesttoidentify. Timingresources and attributesaremore dicult.

The generalapproach is toanalyze the systemrepresentationto identifyall p ersistent resources, i.e. those that retain valuesfrom onesystem op eration to thenext. In sp eci-cationstylesthatrequireanexplicit declarationofstorage entities,this isstraightforward. Forotherstyles,itmaybenecessarytoinferaresourceattributefromtheactivelanguageof thesp ecication. Forexample,thespecicationmaycallfortesting todetermine whether a le is \locked." From this, we can infer a \le locked" attribute asso ciated with each le. Elsewhere inthe specication, wewould expect tond mention of an operation that \lo cks" the le and one that \unlo cks" it. These op erations also aect the \le lo cked" attribute.

Staticstructures,suchasarrays,anddynamic structures,suchaslists,haveattributes that are mo died or referenced as side eects of op erations on them or their elements. Thesearediscussedfurtherinsection 3.4.2

Timingresources are more diculttoidentify,especiallyinhigh level descriptions. In theabsence of explicit timing specications,the usual case, the analyst mustb e aware of op erations that seemto permit varyingexecution times and identifya timing resource to asso ciate with each such op eration. In p erforming the dep endency analysis, the factors thatleadtothis variabilitymustb eidentied.

Itis useful toidentifytwo\pseudo resources"toserveas placeholders forinformation intro ducedintothesystembytheuserandinformationreturnedtotheuserbythesystem. Anycovertchannelmuststartwith a\user input" and end witha \user output."

3.2 Specication Decomposition

The objective of p erforming a dep endency analysis is to capture the information ows through the system in such a way as to p ermit the identication of any security aws thatthe systemmayhave. In doingthis, it is useful toexamine thesystem, operation by op erationand reduce its information owsto auniform representationthat issuitablefor subsequentanalysis. This isdoneina series ofsteps.

Manysystem op erations mo dify anumberof dierentsystem resources. Forexample, op eninga leforwriting mayset thele's \lo cked"attribute, setthe usecountof thele to1,andentertheidenticationofthelo ckerintotheuserslistofthele. Bysplittingthis largerop eration into three smaller op erations that areviewedas occurring inparallel, we add precision tothe analysis since the resources thatcontribute toeach of the individual mo dicationsareconsideredseparately.

The objective of thedecomposition pro cess is toseparate the information owsin the systemunderanalysistoanextentthatensuresthatsecurity awscanb eprop erlyidentied and adequately scop ed. This is often a trial and error pro cess. if the decomposition is carried out in excessive detail, the same or similar analyses will be rep eated over and over, showing that each of a group of similar owsis secure (or insecure). On the other hand, if the decomp osition is not carried far enough, ows that are secure may app ear tob e insecure. A reasonablestrategy for a large, complexsystem is to p erform an initial analysisonarelativelycoarsedecomp ositionandtodofurtherdecomp ositiononlyonthose comp onentsoroperationsthatapp eartocontainsecurity aws,stoppingwheneithera aw isidentied orthe decomp osition showsthat a aw isnot actuallypresent. This strategy willsuccessfullyidentifythesecurity awsfromwhichcovertchannelsareconstructed, but furtherdecomp osition may b e required toconstruct scenarios for exercisingthe aw as a partof acovertchannel.

3.2.1 Guarded assignments

Guardedassignmentstatements area usefulform forrepresenting theop erations of a sys-tem. In theintroduction to this section,weintroduced thenotion of a dep endencyasthe fundamental abstractionof information ow. inconvertinga sp ecication into dep enden-cies,it is useful to introduce an intermediate form,the guarded assignment. The guarded assignment was introduced by Dijkstra [2, 3] as an abstraction for program design and sp ecication. Indecomposingaspecicationfordependencyanalysis,guardedassignments areusefulb ecausetheysuccinctlyrepresenttheinformation owsthato ccurinconnection withb othconditional and unconditional op erations.

Guardedassignmentshave theform: If (G) Then T := Swhere

T is the target of the op eration. This is a resource or resource attribute that is aected bytheop eration. It mayb ean isolatedentity,a timingresource, partof astructure suchasan arrayorlist, oran entirestructure.

expression thatiscompatiblewiththetarget. Itisunconditional,thatis,itdo esnot containany\ifexpressions". Thereasonsforthisarediscussedinsection3.4.1b elow.

G is theguardfortheassignment. Itisa b o oleanorlogicalexpression involvingresources, resource attributes, constants, and literal values. If it evaluates to true, the assign-ment takesplace. Ifit isfalse, theassignmentdo es nottakeplace.

If the system sp ecicationis suchthat some target always changes, but thenature of the change dep ends on whether or not a given guard is true, two guarded assignments result,If G Then T := S1,and If not G Then T := S2. Unconditional changes canb e representedbya guardof true.

In some cases, it is useful to nest guarded assignments. This is often the case when a security related test is made to determine whether the functional op eration should b e allowed. For example, if we only allow subjects to op en les for writing at their own securitylevel,wemightrepresentpartof theop erationas

If Level(U) = Level(F) Then If not Locked(F) Then

Locker(F) : = U;

where Levelis a function that returns theclassication or clearance of objects (les For subjects(usersU),Lo ckedisaleattributethatindicateswhetherornottheleisop enfor writing,and Lo ckerisa le attributethat containstheidentityofthe subjectthat lo cked thele.

Thisformulationallowsustoassumetheouterguardinreasoningab outthesecurityof theop eration, something that mayb enecessary todemonstrate the absenceof asecurity aw. Note that op erationally, the nested If A then If B then ... has a distinctly dierent meaning in terms of information ow from the conjunction A & B in that the formerimpliesan order of examinationwithAbeingevaluatedrst and Bb eingevaluated only ifA evaluates to true. On the other hand, A & Bimp oses no such order and results intheevaluationofbothAandB.The eectisthatthere isan information owfromBin thenested structure only if Ais true while there is alwaysa ow assumed from Bin the conjunction.

In decomposing an informal sp ecication, it is usually clear which form is intended. Designersshouldb eawarethatnestingtestswithappropriateerrorresp onsesateachlevel of the nesting may avoid security awsthat would b e present if a conjunctiveform were used.

3.2.2 Sources and Targets

Once a system hasbeendecomp osed intoguarded assignments, it isnecessary toidentify the resources and resource attributes from which information ows as well as those into whichit ows. ThesourcesincludeallresourcesthatarementionedintheSportionofthe guardedassignment. Theyalso includeall thosementionedintheguardG.Thisisb ecause we caninfer somethingab out theresources ofG ifweassume thatweknowthevalueofT

Twhentheop eration inquestionisinvoked,weknowthat Gwastrue.

Inaddition,T maycontributetothe listof sources. IfTisa comp onentofa structure, theresources referenced in its indexing expression will b e sources. To see why this is so, considerthecaseinwhichtheassignmentT(I) := Sis made. If weknowthatnoelement ofThadavalueequaltothatofSb eforetheassignment,wecandetermineIbyexamining Tforchanges.

Atrst glance, targetidentication app ears tobe more straightforward. Wereit not forstructures,thiswouldb ethecase. IfthetargetToftheguardedassignmentisasimple, isolated resource or resource attribute, it alone is the target of the information transfer. As we have seen ab ove, mo difying an element of an array allows determination of the elements index under some circumstances. To account for this, we intro duce the concept of\name resources." The information transfer intothe arrayas awhole that resultsfrom an assignment into one of its elements is said to b e a mo dication of its \static name resource." The securityimplications of this were rst discussedbyGasser [8] in1979 and laterconsidered indetail bySinger [36]. A similar situation existsfor dynamic structures suchaslists,sets,mappings,etc. thatareoftenusedforspecicationpurposes. Inaddition toa staticname resource,thesestructures havedynamic name resources. Forexample, an op eration that app ends a new entry to the end of a queue changes both the contents of the queue and its size. The size is considered to b e a dynamic name resource. It may b e observed directly or indirectly. Indirect observations include full or empty checks for such structures as well as membership tests for sets and the like. Thusa single guarded assignment mayrepresentmultipletargets.

A guarded assignment statement, If G Then T := S givesriseto oneormore dep en-dencytriplesfT;fSg;Ggdepending onthenumberofresourcesorresourceattributes rep-resentedbythetargetToftheguardedassignment. ThesourcesetfSgforeachdep endency consistsof all the resourcesand resource attributes explicitly and implicitly referenced in thesourceand guard expressionsoftheguarded assignmentstatement from whichthe de-p endencyisderived. Ifthetargetoftheguardedassignmentinvolvesaselectionexpression, thismay also contributesources tothedependency.

Thus, the source set fSg for a dep endency fT;fSg;Gg is fSg = fS s g[fS g g[fS t g where fS s

g isthesetof sourcesobtainedfrom thesourceexpression Softheguardedassignment statement,

fS g

g is theset ofsourcesobtained fromtheguardexpression Gof theguardedassignment statement,

fS t

g is the set of sources (if any) obtained from the target expression T of the guarded assignment statement,

The objective of sp ecication decomposition is to reduce the sp ecication, no matter whatits originalform toa list of dep endencies,eachconsisting of a single target, alist of sources derived from the guard and target as well asthe sourceof a guarded assignment statement, and a guard expression. Once thedecomp osition has b een p erformed and the systemsecurityp olicyconsidered(see section 4)thesearchforcovertchannelscanb egin.

Mostspecicationsareeectively functionalinnature. While theymay explicitlydescrib e eects on the global state of the system, they do not usually introduce temporary lo cal resources(variables)and donotusuallyhavehiddenside eectsthat alterthe globalstate in unexp ected ways. Co de also often makes use of pro cedures that can aect multiple resources indep endently. For these reasons, it is necessary to analyze co de in a dierent mannerfromsp ecications.

3.3.1 Lo cal variables

Lo calvariablescanb easourceofconfusioninp erforminga co deanalysis. Forexample,in thefollowingco defragment tmpislocal.

tmp := A + B; D := tmp;

tmp := F + G; H := tmp;

Some analytical techniques would (wrongly) indicate a ow from A to H while it is obviousthatthis isnotthecase. Theb estapproachistotransformtheco de inawaythat eliminateslocalvariables,ineectconvertingimp erativecodeintoitsfunctionalequivalent. Inthecase oftheexample, this transformation wouldyield:

D := A + B; H := F + G;

In the case of lo ops, this may require a transformation to a recursive form and/or a transitiveclosureoftheinformation owsintroducedinthelo op. Techniquesfordoingthis arediscussedindetailin[17].

3.3.2 Pro cedures and Functions

Inmostprogramminglanguages,pro ceduresandfunctionsservetwopurposes. The rstis toprovidean encapsulating abstraction foran op eration ora related group ofoperations. Thesecondistoextendtheop erationalvocabularyofthelanguagebyprovidinganecient waytoapplyorreusetheencapsulatedabstractioninavarietyofcontexts. Apro cedureor functionisusuallydenedintermsof itsuseof anditseects onalistofdummyvariables called its formal parameters. These are placeholders for the variables towhich it will b e applied when it is called in a program that uses it. When the pro cedure or function is called, real variables or expressions from the calling environment are substituted for the dummyvariablesusedinthe denitionof thefunction orpro cedure. These aretheactual parametersof thecallsiteunder analysis.

Procedures, especially those that modify more than one of their formal parameters, p ose an analysis problem. In general, the b est approach is to treat each output formal parameteras thoughit were computed independentlyand thepro cedure callasthough it wereaparallelinvocationofasetofassignments,oneforeachformaloutputparameter. The

the initial (time of call) and nal (time of return) values of each output parameter. (In languagessuchasAdathathaveoutputonlyparameterstheremaynotbeaninputvalue.) Theneteectoftheanalysisandtransformation istocreateasetoffunctional denitions, one for each formal output parameter, for the pro cedure that can be substituted for the pro cedurecall. Functionswithout side eectscanb etreated ina similar fashion,reducing theirimp erativeformtoafunctionalonefortheirresultorreturnvalue. Asimpleexample willillustrate thepro cess:

Procedure OpenW ( F : File, Var L : Lock, Var W : Writer,

R : Reader, U : Users) = If R = Null and not L

then

L := true; W := U; end;

Reduced to functional denitions for the formal output parameters, L and W, this b e-comes:

L(L', R) := If R = Null and not L' then true else L'; W(L', W', R, U) := If R = Null and not L' then U else W';

whereL'and W' denotethe original(orcalling time) valuesofL and Wrespectively. Intracingdep endencies througha pro cedureorfunctioncall, theactualcalling formis replacedbythefunctional form(s). Thisisexpandedtoreplacethefunctional callwith its dening expression. A substitution is then made, using the actual parameters of the call toreplacetheformals of thecalledroutine. Theresult,at thecallingsite isasthoughthe calledroutinehad b een replacedbyinline co dehavingthesameeect.

Continuingthe example,ifa callof thispro cedure weremade,say

OpenW (TheFile,

Locked(TheFile), Writers(TheFile), Readers(TheFile), TheUser);

Theeectwouldb ethesame asiftheco de

Writers(TheFile) := If Readers(TheFile) = Null and not Locked(TheFile) then TheUser

else Writers(TheFile);

then true

else Locked(TheFile);

hadb een inserted inplace ofthe call.

Note that the order of the op erations was reversedto avoid problems with the simul-taneousredenitionand use ofLocked(TheFile). Ingeneral, itmay b enecessary toadd a distinguishingnotationsuchastheprimeusedab oveeachtimeavariableisredenedduring thetransformations. In the end, substitution of actual parameters for formal parameters willremovethe intermediate renamedinstancesleaving only initialand nalversions.

3.3.3 Side Eects

Mostprogramminglanguagesallowglobalvariables,thatis,variablesthatmayb edirectly referenced by a number of dierentfunctions or procedures. Many languages also allow functionstomo difyglobalvariablesandparametersinadditiontoreturningaresult. These actionsarecalledsideeects. Whenaprocedureorfunctionhavingside eectsisanalyzed for dep endencies, additional assignments are added to the eect set of the procedure or function. These are intro duced at each calling site. Interactions b etween the primary eects and the side eects are p ossible (though they represent p o or software engineering practice)andcaremustbetakentoensurethattheproperorderofdep endencyiscaptured througheither orderingof thesubstituted co de orthroughvariableinstance naming.

3.4 Expression Decomposition

In general, the source S of a guarded assignment is the same whether a sp ecication or co deis b einganalyzed. From apractical standp oint,thecomplexityof theexpression and thenumber of unknowns that it contains aects the strength of the dep endencies that it represents. Inthecaseofdep endenciesthatareinvolvedinacovertchannel,thiswillaect thesignaltonoiseratioof thechannel. Thiswill b ediscussed furtherinsection 6.

All variables, constants, and literals that appear in an expression are sources for the expression. Thus if wehave a simpleexpression such as a + b * c the sources are a, b, andc. Thereareseveralcasesthat deservecloser attention.

3.4.1 If Expressions

Ingeneral, it ispreferable tomove all conditionalitytothe guards of guarded assignment statements. Ifthesourceexpression b einganalyzedcontainsaconditional,theconditional canb eaddedtothe guardof theguarded assignmentand the\true" branchof the condi-tionalsubstitutedfortheconditional. Inaddition,anewguardedassignmentiscreatedwith thenegationof thecondition addedto itsguard and the\false" branchof theconditional substitutedfortheconditional. Forexample:

If G Then X := If Z>0 Then Y Else W fI;

If G & Z <= 0 Then X := W;

or,ifa nestedformis indicated

If G Then If Z > 0 Then X := Y; If G Then If Z <= 0 Then X := W;

3.4.2 Arrays and other structures

We have noted earlier that the use of indexable structures intro duces additional resource attributes. Theseattributesmaybereferenced directlyorindirectly. Singer[36]callsthese resource attributes name resources. Indexable structures of constant size have a single name resource that re ects the fact that op erations on the elements of the array can b e detected by observations of prop erties of the array as a whole. In particular, a direct reference toa comp onentof such a structure introduces notonly theelement asa source but also the static name resource of the structure. Dynamic structures have additional name resources. Size is a resource attribute that can be changed by adding or removing an element to a structure. Structures such as mappings are often used as abstractionsin sp ecications. Theyintroduce additionaldynamic nameresourcessuchasthedomainand rangeofthemapping. These,inturn,havenameresourcesoftheirown. Op erationssuchas pushand p oponstacksalso referencethesizeresource ofthestack. Enqueueanddequeue op erationshavesimilareects. Op erationsondynamicstructuresshouldb eexaminedwith careto determine all the dynamic name resources asso ciated with them. Op erations that fail under somecircumstances mayreturn information ab out one ormore of thedynamic nameresourcesasso ciatedwith thestructure. Notethatop erations ondynamic structures are often dened so that exceptions are raised if the operation results in an error such asunder owor over ow. Raising theexception may allow astronger inference aboutthe structurethannotraising it, butsomeinferenceis p ossiblein eithercase.

3.5 Approximations and Conservative Replacement

A complete dep endency analysis, esp ecially of code or of a highly detailed specication requires a large amount of work. If go o d software engineering practices have b een fol-lowed,muchofthisworkwillinvolvetheexpansionand substitutionofdenitionsforuses, esp eciallyatfunctionor pro cedurecallsites.

Is itpossibletoavoidsome ofthe eortaltogetherorat leasttop ostp one it untilit is clearly needed? Sometimes this is p ossible. Inthe absence of side eects or references to globalvariables, the worst that a procedure or functioncan do is introduce dep endencies b etweenall ofits inputsand eachof itoutputs. Sideeects andreferencestoglobals com-plicatethesituationsomewhat,butknowingwhichglobalsare referencedand/or mo died isequivalent toaddingthem totheparameter list,and a similar worst case applies.

Ifthesystemcanb eshownnottohavesecurity awsunderthisworstcaseassumption, further renement of the dep endencies is not needed. On the other hand, if a susp ected awapp earstob edue toaworstcaseassumption,amore detailedanalysis mayeliminate the awormayconrmit andpinpoint theexact mechanism.

thesystemwouldb e secureinthe faceof dep endencies onall structure elements,it isnot necessarytodeterminewhichelementsareactuallyinvolved. Thepracticeofsubstitutinga morecomprehensivesetofdep endenciesforaspeciconeiscalledconservativereplacement. Thisisdiscussedinmoredetailin[19],butthegeneralprinciplescanbeseeninthefollowing examples.

Suppose that we want to suppress the detail in the pro cedure Op enW discussed in section3.3.2ab ove.

Procedure OpenW ( F : File,

Var L : Lock, Var W : Writer,

R : Reader, U : Users) = UNDEFINED;

In this formulation, the b o dy of the pro cedure is not known and we have no choice but to assume the worst case which is an information ow from each of the procedures inputsinto each of its outputs. We assume that we knowthat the implementationof the pro cedurewill notreference anysystemresourcesnotexplicitly orimplicitlymentionedin its parameter list. Reduced to functional denitions forthe formal output parameters, L andW, this b ecomes:

L(F, L', W', R, U) := UNDEFINED; W(F, L', W', R, U) := UNDEFINED;

Substitutingthe actualparameters from thecallshowninsection3.3.2and reduced to dep endency triples, fT;fSg;Gg the information owsfor the undened version of OpenW b ecomes:

{Locked(TheFile);

{TheFile; Locked'(TheFile); Name(Locked);

Writers'(TheFile); Name(Writers); Size(Writers'(TheFile)); Readers(TheFile); Name(Readers); Size(Readers(TheFile)); TheUser};

true}

{Name(Locked);

{TheFile; Locked'(TheFile); Name(Locked);

Writers'(TheFile); Name(Writers); Size(Writers'(TheFile)); Readers(TheFile); Name(Readers); Size(Readers(TheFile)); TheUser};

true}

{Writers(TheFile);

{TheFile; Locked'(TheFile); Name(Locked);

TheUser}; true}

{Name(Writers);

{TheFile; Locked'(TheFile); Name(Locked);

Writers'(TheFile); Name(Writers); Size(Writers'(TheFile)); Readers(TheFile); Name(Readers); Size(Readers(TheFile); TheUser};

true}

{Size(Writers(TheFile));

{TheFile; Locked'(TheFile); Name(Locked);

Writers'(TheFile); Name(Writers); Size(Writers'(TheFile)); Readers(TheFile); Name(Readers); Size(Readers(TheFile)); TheUser};

true}

The name resources app ear because the Locked, Writers, and Readers attributes are assumed to be indexed by TheFile. The size attributes for Readers(TheFile) and Writers(TheFile) app ear b ecause these structures are assumed to b e lists of users. In contrast, thedep endenciesfortheversionof OpenWgiven insection 3.3.2wouldb e:

{Locked(TheFile);

{TheFile; Locked'(TheFile); Name(Locked); Size(Readers(TheFile)};

true}

{Name(Locked);

{TheFile; Locked'(TheFile); Name(Locked); Size(Readers(TheFile)};

true}

{Writers(TheFile);

{TheFile; Locked'(TheFile); Name(Locked); Size(Readers(TheFile); TheUser};

true}

{Name(Writers);

{TheFile; Locked'(TheFile); Name(Locked); Size(Readers(TheFile); TheUser};

true}

{Size(Writers(TheFile));

{TheFile; Locked'(TheFile); Name(Locked); Size(Readers(TheFile); TheUser};

The dierenceinthe numberof attributes that needtob e consideredinthe two cases issubstantial,butifall theattributesinvolvesimilar securityanalyses,there mayb e little dierence in the analysis eort required. In general, pro cedures or functions whose ar-gumentsdo not dier in security level can b e handled more eciently using conservative replacement ofthis kind and makinga generalargumentconcerning thesecurityof allthe p otential ows whether they o ccur or not. If this general argument cannot be made or level dep endent ows are known to b e present in the routine, expansion of the routine's denition isclearly indicated. Forasecond exampleof conservative replacement,supp ose thattheexpression

(String1[i..j] @ String2[k..l])[m]

app ears in the sp ecication b eing analyzed. In this case, the expression pro duces the m'thelementof thesequence pro ducedbyconcatenatingthei'ththrough j'thelementsof String1with the k'ththrough l'th elementsof String2. Possiblesources of information owfromthisexpression includem,i,j,k,l,String1[i] ... String1[j],String2[k] ... String2[l],Name(String1),Size(String1),Name(String2),andSize(String2). Ifadep endencyon allthese sourcesdo esn't lead totheidenticationof aninsecurity,itis easierto usethe conservative formulationthan it isto determine theexact circumstances under which the owsoccur. The less conservative approach would b e to transform the expression into a form conditioned on the index values. Forthis purp ose, wewill assume thattheindexvaluesarewithinrangeastreatmentoftheoutofrangecasesintro ducesyet anotherlevelof complexity. Assumingzero based indexing,the originalexpression canb e rewrittenas:

if m < j-i+1 then String1[m+i]

else String2[m-j+i-1+k] fi

This form would result in two guarded assignments, one for each branch of the if-expression. The information sources foreach branch area subsetof those that app ear for theoriginalformand therelationshipbetweenm, i,and jcanp ossibly b eusedinproving that the owsare secure. This formulation would only b e useful ifthe security levels for elements of String1 dier from those for String2, an unlikely situation. In general, the conservativereplacement approachwill prove adequate andwill reduce theeortrequired todecomp oseaspecication.

Security Policy Issues

A covert channel represents a violation of the real security p olicy of the system under consideration. Therealp olicyisusuallyanextensionofthepolicyembo diedintheFormal Mo deloftheSecurityPolicy(FMSP)ofthesystem. Securityp oliciesarediscussedindetail in a related p ortion of this handb o ok [30]. In performing a covert channelanalysis, it is necessarytoextendthesecurityp olicyofthesystemsothatsecuritycharacteristicscanb e assignedtoall resourcesand resource attributes ofthesystemdescription beinganalyzed. In general, weassume thatthe system has b een characterized asa state machine and thatthesecurityp olicymo deltakestheformofeitheraBellandLaPadula[1] styleaccess control mo delor oneof its information owanalogs [18]. Ineither case,themodelwill be couched interms of passive, information containing,objects,and active, information free, subjects(andp ossiblyhybridsof varioustypes)andwillindicatethenatureoftheaccesses oraccesspermissions that asubject mayobtain to an object asa functionof thesecurity attributes(clearancesforsubjects, classicationsforobjects)possessedbythesubjectand objectsin question.

In applying such a mo del, a limited view of objects is usually taken. This restricts objectstoentitiessuchasles anddevicesthatareintendedtostoresubstantialquantities ofinformation. Forthepurposeofperformingacovertchannelanalysis,anysharedresource or shared resource attribute is an object. In the previous section, the dep endency was intro ducedasan abstraction torepresentarbitrary information ows. Applying a security p olicytoa dep endency,fT;fSg;Gg,we notethat, sincethe target, T,of thedep endency is mo died, the subject invoking the operation that gives rise to the dep endency must have mo dify access to the target and must have read access to each source in fSg since theinformation that mo dies the target comes from these sources. Because the target is mo died only when the guard, G, is true, it must b e the case that the invokingsubject would b e granted the necessary accesses only under circumstances that would result in theguard b eingsatised. If the information ow represented bythe dep endency is tobe considered\secure",this willbe thecase.

The TCSEC requires that the \subjects" and \objects" to which the FMSP applies b e lab eled with machine pro cessable representations of the security attributes on which accesscontrol decisions are made. The pro cess of asso ciatingsecurity characteristicswith system resources and resource attributes is an extension of this labeling requirement. It is not necessary to create physical labels or storage structures in the implementation to

security characteristics for each resource and resource attribute. The mechanisms may involveapp ealing tothecontentsofreal systemlabelsorit mayinvolvethe assignmentof constant securityattributes tosomeresources.

4.1 Linking policy to resources

Dep endencyanalysisidentiesthep otentiallysharedsystemresourcesandattributes. Each resourceand attributemustb e givena classicationifwearetoreasonab outthesecurity of dependencies. The set of values available is dened by the FMSP. DoD style policies typicallydenea latticeofvalueswitheachvalueconsistingof ahierarchicalclassication anda (p ossiblyempty)set of categories. Severaldistinguishedvaluesare ofinterest.

mo del low isthe minimumclassication value denedby theFMSP.It is dominated by all of theclassication valuesdened bytheFMSP.

mo del high isthemaximumclassicationvaluedenedbytheFMSP.Itdominatesallof the classicationvaluesdenedbytheFMSP.

system low is the lowest classication value at which a given system is p ermitted to operate. It dominatesmo del lowand isdominated byall classicationsthat mayb e assigned tothesubjects and objectsof thesystem.

system high is the highest classication value at which a given system is p ermitted to operate. It dominatessystem lowand all classicationsthat may beassigned tothe subjects and objects ofthesystem andis dominated bymo delhigh.

Asubstantialamountofskillisrequiredinassigningsecurityattributes. Ifinappropriate decisions are made, the system may app ear to b e far less secure than it actually is. On the other hand, it is not possible to mask insecurities by inappropriate lab eling unless thelabelingmechanismviolatesthetranquilityprinciple byallowingtheclassicationof a resourcetochangeb etween(orduring)op erations. There areseveraleasycases:

1. TheresourceisanobjectinthetermsoftheFMSP.Inthiscase,itssecurityattributes are exactlythesameasthose ithas intheFMSP.

2. The resource or attribute is logically asso ciated with an object. In most cases, the security attributes should b e the sameas those of the object. This implies that le nameshavethe sameclassicationasles,etc. Exceptionsarep ossible;forexample, a systemmighthave a predened, xed set of leor device namesthat can b eread byall,in whichcase \system low"is anappropriate level.

3. The resourceiscloselyassociatedwithasubject. Inthis case,thesecurityattributes of thesubjectareprobably appropriate, althoughexceptions mayexist.

4. Theresourceisnevermo diedbyanuntrustedsubject. \SystemLow"isappropriate.

theclassesab ovearelikelytob einvolvedinasecurity aw. Itisprobablythecasethatno securitylevel can b e found that will makeall dependencies involving theresource secure. Arbitraryassignmentsof securityattributes cancause the awtoappeartobe asso ciated with variousoperations. If auditing is b eing considered as a countermeasure,asso ciating the awwitha lesscommonoperation willreduce thequantityof auditdatacollected.

Associatingsecurityattributeswithtimingresourcesseemsproblematicatrst. Timing attributes are observed by the system being analyzed. If we associate the level of the subject invoking the op eration with the timing attribute, the appropriate relationship is establishedsince asecure timing dep endencywill only involvesources thatare dominated by the invoking subject. Insecure timings will involve sources that the subject do es not dominate.

Oncethep olicyhasb eenextendedtocoverallsystemresourcesandresourceattributes and a dependency analysis has been performed, a search for security awscan b e made. Thisiscoveredinthenext section.

Looking for Channels

In the previous sections, we have developed a theory of information owthrough dep en-denciesand have discussedtheissues surroundingtheapplication of asecurity p olicytoa system representation. CovertChannel Analysis is a searchfor dep endencies that canb e exploitedinviolationofthesystemsecurityp olicy. Thissectionwill developasequence of analyticalapproachesb eginning with thebasicShared ResourceMatrixand its extensions and pro ceeding to Covert Flow Trees and Information Flow Formulae. Non-interference formulations will also b ediscussed.

5.1 The Shared Resource Matrix

Firstintro ducedbyRichardKemmererintheearly1980s,theSharedResourceMatrix[13] remainsoneofthebestknownanalyticalto olsavailable. WhiletheSRMhasitslimitations, itisstillthemostconcisemethodforcharacterizingtheinformation owsinasystem. We sp end a substantial amount of time developing the extended SRM as a to ol for guiding a search for covert channels. Our development starts with the assumption that we have analyzedasystemrepresentationfordep endenciesand havetheresultsavailabletous. To providea concrete example, wewill consider a fragment ofcode which,while meaningless byitself,serveswell toillustratetheprinciples involved.

Global var a, b, c, d;

Procedure OP1 (Var u : uvar) = begin

a := if b then c else d; u := c;

end;

We assume that the system state is completely characterized by the global variables a, c, b, and d. We also assume that the fragment is a complete characterization of the pro cedureOP1,thatis,therearenohiddenoperationstochangethevaluesofthevariables u, b, c, and d. The analysis and decomp osition of OP1 results in the following guarded assignments: