Implementing a verification methodology for McCullough security ...
Implementing a Verification Methodology for McCullough Security David Rosenthal Odyssey Research Associates, Inc. 301A Harris B. Dates Drive Ithaca, New York 14850-1313 *t a state machine is any sequence of events derived from that machine which begins with y, has no other inputs, antl leaves that machine ready t o accept the next input.
Abstract W e describe how to build a theorem generation mechanism for the validation of a security property which implies McCullough Security.
The state machine transitions are:
0))
1. I ( ? ) 3 I ( f ( z , y , when they are no outputs for this transaction 2. I ( 5 ) -% O ( 2 ,y, O,()) when an output or nondeterministic decision is t o be made and the transaction is not finished 3. O(z,y,j,s) 5 I ( f ( ? , y , s ) ) when e = 4(!i,y,j.s) and when an output is t o be made and the transaction is finishctl
Introduction I11 previous work [I] we have described a niethodology for proving ~IcCulloughsecurity (also called KADC hook-up security, restriction, aiicl flow srcririty) [']. The purpose of the inctliodology was to automate part of tlrc construction of the scv.ririty 1)roof. 111 tliis previous \vork ivts tlescrilml a class of stiit(\ ni;ic.liiiics i i i i t l a sct of proprrtic's t t i i i ~ tlicy shoultl sati.1'). to IN.srciirc. 111 this l)al)cr \vc' tlt%sc.i.il)csIiow t l i v Iiiacliiiic3s c a i i I)(,tlrscrilxtl a s proccssrs antl lrow to gcneratc the spec.iliQ. I licorenis for these processes.
4 . O(%,y,j,\q) 5 O ( ~ , y , j-t 1,s) when e = 4 ( i . ? y j , s ) and when a n output is to be made and the traiisaction is not fiiiislied 5 . O ( Z ?y , j , .s) 5 Z ( f ( 5 , y,s"(e))) when a nondetmministic decision satisfying p(?, y, j, s , e ) is to he niade and the transaction is finished 6. O(Z,y,j,s) .5 O(Z,y,j l,s"(e)) when a nondeterministic decision satisfying p ( Z , y , j , s, e) is t o be made and the transaction is not finished
Itoiighl!. speaking, the methodology liaiitlletl state machines of the following form: Get an inpiit from the buffer, make n scqurnce of nondeterministic decisions and outputs, antl tlirii
+
return to haiidle the nest inpiit.
Ilcrr is a hrief formal description of the state machines. We that the inputs are buffered. \Ye let I represent s t a t c s \\here the next input is to be taken from the bufrer iiirtl lct 0 represent states wherr out puts or nontlctoministic. t l v t isions are to be made. 'llirse s t a t c s arc parameterized l)y .r \vliich a r e parameters for the tlir sprcific niodel, by j iiitlic.iiting how many outputs antl nondeterministic tlecisioirs lravr bccii inatle since the last iul>ut, by s ii~tlicating t lie iioirtlrtf.riiiinistic decisions, by y indicating wliat tlie previolis iiilnrt was, antl by e indicatiiig cithcr ail output or a iicintlctcrniinistic clioice. T h e function f(?,y, s) will indicate i v l i a t tlie i i t w parameters of thc next illput state are . The ftiiiction 4 ( Z , y , j , s) will indicate what t.he oritput should be antl t he rela.tion p ( $ , y , j , s, e ) will indicate the possible non&,I wninistic choices. A 1runsncfion for an input y on such iissuinc
This condition was called (Def) in the previous paper. For such machines to be secure it is sufficient that they satisfy the following additional constraints with respect to some projection function projl on the parameters:
( I l a l t ) from state I ( ? ) , after any given input y, the state machine may eventually return to an input s t a t r i.e. for any sequelice of outputs and nondeterministic drcisions D
(C''
such that I ( % ) O(it,y,j,s) there is a ~ c q u e n c e 0' and a sequence of parameters :C'such that
of events
I(;'). In particular, there is no rcachable state which will surely have an infinite number of consecutive outputs and delays, or be unable t o make O(Z,y,j,s)
*'lliis work was supportrd by the Air Force Systems ('oiiiiiiiiiid at Rome Air Development Center under ('oill.rnct No. 1:30602-85-C~-0096. The views and conclusioiis cmtained in this paper are those of the author a i i d slioiild not be nrterpret.etl as necessarily representing the official policies, either expressed or implied, of llic Air Force or the U.S. Government. '1 woultl likr to thank Owen Rambow for implementing the algorithm.
133
TH0255-0/89/oooO/0133$01.00 0 IEEE
some transition. In practice, we may make the stronger assumption that there is a bound, b ( 5 , y), on the number of outputs and delays which can transpire before returning t o the next input state. (Remark: this condition does not have t o apply for inputs a t the lowest possible level) The level of any output from O(i?,y,j,s) is 2 the level of y (for those j and s where there is sequence of out-
processes and the functions which are used in building the processes.
puts and delays U such that Z(3) (SI)
% the ordering is don don : : (leve1,level)
-> assertion;
AXIOM transitive is [all a:level,b:level,c:level] dom(a,b) & dom(b,c) => don (a, a=b;
end ;
Introduction to USL
T h e first thing to notice is that collections of specifications are grouped together in a theory. The use of theories is a way t o group related facts together in meaningful components. For details about the theory mechanisms of the Romulus project see (41.
Now rather than dircctly working with state transitions it
inore understandable if we exprrss the machine in a that looks more like a program specification. To do this we einploy the language USL [3] from the Romulus project (foi.mc~rlycalled the Ulysses project) [4].
ih
Theory of partially ordered set of levels
ofteii
\ray
The first two lines are just comments. SL uses the 78 as a mark for the beginning of a comment and everythii-g after the % until the end of the line is not translated.
Tlic 1S1, language is intended as a general language to specify ~n,itli~mat,ical theories in Rornulus. It also contains some fcatiu.rs wliicli specifically help i n t,lie construction of pro-
In the example, the first kind of specification is a way of defining a sort. level is just some sort with no added information given. doni is a function which takes two levels and produces an assertion. The next group of specifications are axioms which tell us more about the definition of don. The quantified variables are included in the brackets itnd the implication is indicated by the => symbol.
Cf’SS(’S.
Tlic. semantic basis for the USL language is the theory of coiist,ructions [5] and not just, first, order logic. Hence the language has quite a bit of expressive power. IIowever the s!,iitax is constructed so that tlie t.ypica1 user only needs to know ahout tlie theory of constructions when they wish t o eiiiploy some of the fancier facilit,ies of USL.
Although we use upper case, the language is not case sensitive. Also note that the ; is used as a specification separator.
‘rlici.c. are t,wo basic kinds of objects. The first are called “ s o l - i s ” wliich are tlie data types a n d thc functions on those data types. Tliese include such things as natural numbers, lmolcans, lists, ordered pairs, processes, ils well as function
Process Construction
spaces formed form these. T h e second kind of object are callcd “assertioiis” which are statements about the sorts. Of part.icular intcrest for the Romulus user are assertions about
Part of the USL language is a facility t o aid in the construction of processes.
I34
o Send(port ,data) - is the output statement
- sends the items from the datalist consecutively Receive(port,data) - is an input statement Avait msg,port from portlist then - receives an input from a buffer connected t o the ports in portlist Plus - is the nondeterministic selection of CSP Select - is for nondeterministic selection which does not check which receives are ready for inputs. Parallel - is parallel composition of processes Skip -- is a “do nothing” statement Parameterized processes - for example AnyProcess(x,y,z)
o Multisend(port ,datalist)
o o
o o o
o o
theory level level : : sort; dom : : {level,level) -> assertion; AXIOM transitive is [all a:level,b:level,c:levell dom( a, b) & dom(b,c) => dom (a,c) ; AXIOM reflexive is [all a:levell dom(a,a) ;
AXIOM antisymmetric is [all a:level ,b:level] (dom(a,b) & dom(b,a)
=> a=b;
end ;
A detailed example appears in the next section.
%% %% %%
0t her features
.................................................. ports portkind := input I output ;
In this section we describe a few more features of the language so that the next example can he understood. For a more complete description of the language see [GI or [3].
port := in1 I in2 I out1 I out2;
1 Is the port multilevel? multilev :: port -> assertion;
Let
It is often convenient to introduce new symbols t o rrtluce tlle complexity of ail expression. For example, we Inay LISC the term Let c=a+b-2 i n 3*c*(c+5)/(~-1) for t I ~ c t r r n i 3*(a+b-2) *((a+b-2)+5)/( (a+b-2)-1).
%level of a port % If the port is single level this will represent that % particular level. For the simplicity of this % example, the level of a multilevel port % carries no meaning. : : port -> level ; levp
Definitions \Ve can introduce an object by giving its sort and then axiomatizing it. The USL language also supports othel \vays of defining objects. One such way is a free algebrn construction. For example, we could define the na.tural numbers as Number : = Zero I Successor(Zero). Here is an example of another form of definition that is used:
kind
: : port
-> portkind
;
define member(?p:port.C1:list port)= ”true, member(?p,[?xl-?l)= (xpp) \ / member(?p,?l);
define isout(?e:eventtype) = if (e=samplel) then true else false
%% The following conditions on the ports must be %% satisfied
111 this form the sort of the function and its axioms are autonratically generated. ( T h e ? serves to iiidicatc that e is a free varial)le, because in the more general forni of this construct it is needed.)
Axiom portaxioml is Call p:portl (multilev(p)); Axiom portaxiom2 is (kind(inl)=input) & (kind(inP)=input) & (kind(outl)=output) & (kind(out2)=output) ;
A Sample Process Specification %
..................................................... %% %% %%
The Process Main
messages a message has a label and other data
datatype : : sort; msgtype := record msg (label:level, Uata:datatype);
Theory anexample
1% .................................................. %% Theory of partially ordered set of levels %%
................................................... %%
I35
1% Events are pairs of ports and msgs
Axiom Call 1:levelI Call m:msgtype] Call pari :paramtype] Call par2:paramtypel ( dom(1, m.labe1) => (proj(1 .pari) =proj(1.par21) => (proj(1,update(parl ,m>)=proj (1.update(par2 ,m)))) ;
Eventtype :=record Event(theport :port,themsg:msgtype);
%% %% %% %%
.................................................. The Level of an event
%% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . %% The process definitions %% %% %% The process Main can receive inputs from either %% port in1 or port in2. Inputs from in2 are just %% passed on through port out2. and then the %% process returns to its original state. Inputs % % from in1 cause the formation of a new %% parameter and an output based on the new x % parameter. The use of the auxiliary process Aux is to demonstrate the theorem generator. %%
1% If the port is multilevel the level of the event %'I, is the label, else it is the level of the port lev : : eventtype -> level; Axiom Axlevl is Call m:msgtypel Call p:portl lev (Event(p,m)) = (if multilev(p) then m.label else levp(p) ) ;
1%. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . %% The functions low and high are useful 1% definitions for user readability Define low(?l :level,?e:eventtype)= dom(l,lev(e)) Define high(?l :level,?e:eventtype)= -low(l ,e) ;
Main : : paramtype -> Process; DefProcess Aux(summary:paramtype,amsg:msgtype) = let newsummary=update(summary,amsg) in begin send(outl,result(newsummary,amsg)); Main(newsummary)
;
1%. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 'I,% Auxiliary information %% %% %%
end
end ;
These functions are used in the definition of the process
DefProcess Main(summary:paramtype) = await amsg,aport from [inl,in2] then begin if aport=inl then Aux(summary,amsg) else begin send(out2,amsg); Main(summary) end end end
paramtype : : sort; update result
:: ::
(paramtype,msgtype) -> paramtype; {paramtype,msgtype) -> msgtype;
,, proj is the projection function on the parameter proj
::
(level,paramtype3 -> paramtype;
%% The following axioms add constraints to the %% update and result functions
end
Axiom Call par:paramtype] Call m:msgtypel dom((result(update(par,m) ,m)) .label,m.label);
Theorem Generation
Axiom [all 1 :levell [all m:msgtypel [all par :paramtype] ( -(dom(l,m.label))) => (proj (1,par)=proj (1,update(par ,m)) ) ;
Rather than trying to support the most general theoren generation paradigm, we have attempted to strike a balance between generality and the simplicity of theorems that i : generates. We plan on having a number of different kinds of methods to generate theorems so that the user of the Romulus system can pick the most appropriate one. In this way he can fit the complexity of the theorems generated to the complexity of the model to be verified. In this paper we
136
illustrate a case which is fairly general. Aux
Main
We begin by describing the simplifying assumptions.
p
await
1. T h e only form of indirect or direct recursion is through a call on the main process (i.e. the one which can get the inputs.) If induction is needed it can usually be encoded as a list of outputs and then the multisend construct ran he used. This will localize the induction to where it is needed.
b
2 . When handling the (Pl) constraint, we assume thaL
k
send Main
Main
Figure 1: Before Transformation
when the same nondeterministic choices are made then the same i f - t h e n - e l s e branches will be taken for both inputs. That is for any level 1, when the lowlevel aspects of the information look the same, then on a low-level input when the same nondeterministic choices are made then the same path will be taken.
Main
P
3. The form of the presentation must be transparent. For example, a term which is semantically equal t o a send command, but not syntactically identical t o that command, may generate a “method does not apply” condit ion.
A
Main
await
If
Main
Figure 2: After Transformation
The system does not generate the projection functions autoiliatically, tliey must he provided 1)y t h e iiser. This ought to ),e lairly siinple (since d a t a is typically labeled in some way).
We now generate the appropriate theorems for the outputs and the new parameter formation. We generate the theorems which claim that:
I-’ and that it auxiliary processes P1, P2, ..PA’. \Ve begin by starting \\.it11 P anti chcck that it starts with an await. We then intliicti\-ely check that each construct used is appropriate (i.e. no other input statements) and expand the definitions of the auxiliary processes when encountrred. Io I)c\ginlet us suppose that the main process is
Same P a t h For a low level input, the i f - t h e - e l s e branch conditions do not depend on high level information. This is used to simplify the proofs of the other constraints.
IIWS
If
UT f i i i t l
a recursion on a
Level The level of any output is 2 the level of the input which started the transaction. This is used t o prove (Lev)
Pi,we announce that the method
does not succeed in this case. (Itelnark: It is also possible to proccetl by using a process tiookiip theorem. but for this
Projhigh On high level inputs the low level part of the parameters is not changed. This is used t o prove ( P h ) .
c,xaniplc we cmploy t,he expansion tcc:linicluc~.)If a path of t Iic cspaiision tcrminates without tlirrctly calling the main 1)r(icc‘ss I-’ we will announre that tlie nicthod failed. This i i i c a n s that there is a path whic:li will caiise the process to I i a l t . ‘This usually nieans that tlierr is a violation of (Halt,) aii(1 i n fact that the process is not secure. However, it may i ~ i t w i i that the method is not applicablr. For example, tlie Iriincli may be impossible ( for instancr it may require that .r > 1 aiid that T < 0 ). This sort of h n c h would never gct takcn a i i t l so the violation of (Halt) is not real.
Projlowparam If two input states look the same to a low level user then when they accept a low level input and make the same nondeterministic decisions, the low level part of the parameters must still be the same after the transaction is completed. This is used for part of the proof of (Pl). Projlowout If two input states look the same t o a low level user then when they accept a low level input and make the same nondeterministic decisions, the outputs from these states will be the same for the transaction. This is used for the other part of (Pl).
Tlic above checks arr sufficient t o guarantce that hoth (Def) aiid (IIalt) are satisfied.
IIwe is a diagram showing the definition expansion for the #11)o\~: czsainple.
I37
Example Generation of Theorems
(proj(l,x)=proj (1.y) 1 => ((aport=inl) &(aport=inl)) => ((LET summary=x,newsummary=update(summary,~nsg) IN proj(1,nevsummary))= (LET summary=y,newsummary=update(summary ,.msg) IN proj(1,nevsummary)))));
The method mentioned above has been coded and tested with a number of examples. Here is the result of applying the generation to the example specification described above. (Note: The name of the theorem includes an indication of why it was generated as well as a unique numeric identifier.)
%" Theorem main-level-14184 is ([all l:level] Call amsg:msgtypel [all aport:pord member(aport, [in1 .in21 => (Call summary:paramtypel (-(aport=inl)) => dom(lev(event(out2, amsg)) ,
%%% Theorem main-same-path-14173 is ([all l:levell[all amsg:msgtype]Call aport :port] member(aport.[inl,in2]) => (Call x:paramtypelCall y:paramtypel low(l,event(aport,amsg)) => (proj(1,x)=proj (1.y)) =:, ((aporttinl) aport=inl)));
lev(event(aport,amsg)))));
%%% Theorem main,projlowout-l4185 is ([all 1:level] [all amsg:msgtype] [all aport :porl:l member(aport,[inl,in2]) => low (1,event(aport ,amsg)) => (Call x:paramtypel Call y:paramtypel (proj(l,x)=proj (1,~))=> ((-(aport=inl)) 6 -(aport=inl)) =>
%%% Theorem main-level-14176 is (Call 1:level1 [all amsg:msgtypel[all aport :port] => member(aport,[inl,in2]) ( [all summary :paramtype] (aport=inl) => (LET newsummary=update(summary,amsg) IN dom(lev(event (out1 ,result(nevsummary,amsg))) ,
(event(out2,amsg)=event(out2,amsg))))
;
%%% Theorem main-projhigh-14188 is ( Call 1:level] Call amsg:msgtypel[all aport :port1 member(aport,[inl,in2]) => high(l,event(aport,amsg)) => (Call summary:paramtypel (-(aport=inl)) => (proj (l,summary)=(LET summary=summary IN proj(1,summary)1) 1) ;
lev(event(aport,amsg))))));
%% % Theorem main-projlovout-14177 is ( C a l l 1:levellCall amsg:msgtypel[all aport :port] member(aport,[inl,in21) => low(l,event(aport,amsg)) => ([all x:paramtypel[all y:paramtypel (proj(l,x)=proj (1,~)) => ((aport=inl) &(aport=inl)) => ((LET summaryrx, nevsummary=update(summary, amsg) IN
%%% Theorem main-projlowparam-14189 is (Call 1 :levellCall amsg:msgtypel[all aport :port1 member(aport,[ini,in2]) => lov(l,event(aport ,asp)) => (Call x:paramtype] Call y:paramtypel (proj(l,x)=proj (1.~1)=> ((-(aport=inl)) & -(aport=inl)) => ((LET summaryox IN proj(l,summary))= (LET summary=y IN proj(1,summary)))));
event(outl,result(newsummary,amsg)))=
(LET summary=y, newsummary=update(summary ,amsg) IN event(outl,result(newsumrnary,amsg))))));
%%% Theorem main-projhigh-14180 is ( C a l l 1:levelI[all amsg:msgtypel[all aport :port] member(aport. Cinl,in2]) => high(l,event(aport,amsg)) => ( [all summary :paramtype] (aport=inl) => (proj (l,summary)= (LET neusummary=update(summary,amsg) IN proj(1,nevsummary)))));
Proof of Theorems The next stage of simplification is to provide help in proving these results. The first step is to use a tactic (i.e. an inference rule) which repeatedly applies the following:
%%% Theorem main-projlovparam-14181 is (Call 1:levellCall amsg:msgtypelCall aport :port] member(aport,[inl,in21) => low(l,event(aport,amsg)) => (Call x :paramtype1[all y :paramtype]
1. It removes the universal quantifiers by picking Teneric constants. 2. It simplifies implications by making the anteccdent a hypothesis and the consequent the fact that na-eds to be proved.
I38
We expect to b e able t o do all of the above steps automatically by the use of one tactic. Further simplification may then b e achieved by using specialized tactics t o help with these kinds of formulas.
3. It simplifies any let statement by making the substitution. This approach usually simplifies the formula t o be proved t o either an equality, an inequality (with dom), on an equivalence.
Here is a possible completion of the proof 1. Substitute in1 for aport and
For example in proving the second theorem main-level-14176 :
prove: dom (lev(event(out1,
result(update(summary ,amsg) ,amsg) ) ) , lev(event (in1 ,amsg) ) )
1. We start with Theorem main-level-l4176 is ([all 1:levell [all amsg:msgtypel[all aport :port1 member(aport,[inl,in2]) => (Call summary:paramtypel (aport=inl) => (LET neusummary=update(summary ,amsg) IN
2. Expand the definition of lev and prove: dom( (if multilev(out1) then result(update(summary,amsg) ,amsg) .label else levp(out1) 1, (if multilev(in1) then amsg .label else levp(in1) 1
dom(lev(event(outl,result(neusummary,amsg))),
lev(event(aport ,amsg))))));
2. Pick values for the quantified variables a.dd type assignments C1:levell,
3. Simplify this by using portaxiom2. We have that multilev(out1) and multilev(in1) we need t o prove:
Camsg:msgtypel, Caport:portl and prove: member(aport , [in1 ,in21 ) => (Call summary:paramtypel (aport=inl) => (LET newsummary=update(summary,amsg) IN dom(lev(event (outl,result(neusummary,amsg))), lev (event(aport,amsg) ) ) ) )
SO
dom( result (update(summary,amsg) ,amsg) .1abel , amsg .label)
4. By using first axiom for result and update
3 . Llake the head of the implication a n Iiypothcsis add to the list of hypotheses: member (aport,[in1 ,in21 ) ancl provr: (Call summary :paramtype] (aport=inl) => (LET neusummary=update(summary,amsg) IN
Call par:paramtype] Call m:msgtypel dom((result(update(par.m),m).label, m.label)
with summary for par and amsg for m we have:
dom(lev(event(outl,result(neusummary,amsg))), lev(event(aport,amsg)))))
dom(result(update(summary,amsg),amsg).l,~bel, amsg .label)
4. Pick Iralues for the quantified variable
5 . We now can directly use this fact t o get the desired result
add type assignments [summary :paramtype] and prove: (aport=inl) => (LET neusummary=update(summary,amsg) IN
Concluding Remarks
dom(lev(event(outl,result(neusummary,amsg))). lev(event(aport,amsg))))
This approach has worked out very well in a number of cases. Work is underway in extending this technique t o ot.lier kinds of examples.
5 . Alake the head of the implication an hypothesis add to the list of hypotheses: (aport=inl) a n d prove:
*
(LET neusummary=update(summary,amsg) IN dom(lev(event(outl,result(nevsummary,amsg))), lev(event(aport,amsg))))
References
6. Reduce the LET clause prove:
[I] David Rosenthal. An approach t o increasing the automation of the verification of security. In Proceedings of the Computer Security Foundations Workshop, pagcs 90-97. Mitre Tech Report M88-37, June 1988.
dom (lev (event(out1, result(update(summary,amsg) ,amsg))),
lev (event(aport,amsg) ) )
I39
[2] Daryl AlcCullough. Ulysses computer security properties modeling environment: T h e theory of security. Technical Report TRS7-222, RADC, 1988. [ 3 ] Daryl AlcCullough. Final design of T.S.L. - SL: A process specification language for Ulysses. Odyssey Research .Associates Tech Report, 19SS. [4] lilysses Staff. Ulysses: A computer-security modeling ciiviroiiiiicnt. In Proceedings of the 1 lth National Comp u f f r .Security Conference, September 19SS. [5] 'T11ic.rl.y Coquand and Gkrard Huet. Constructions: A higher order proof system for meclianizing mathematics. In El'ROCAL85, volume 203 of Lecture Notes in Computcr ,Science, pages 151-184, Berlin, 19S6. SpringerVerlag. [Ci] Davit1 Rosenthal. SL users manual. Odyssey Research Associates Draft Report, 19S9.
Abstract W e describe how to build a theorem generation mechanism for the validation of a security property which implies McCullough Security.
The state machine transitions are:
0))
1. I ( ? ) 3 I ( f ( z , y , when they are no outputs for this transaction 2. I ( 5 ) -% O ( 2 ,y, O,()) when an output or nondeterministic decision is t o be made and the transaction is not finished 3. O(z,y,j,s) 5 I ( f ( ? , y , s ) ) when e = 4(!i,y,j.s) and when an output is t o be made and the transaction is finishctl
Introduction I11 previous work [I] we have described a niethodology for proving ~IcCulloughsecurity (also called KADC hook-up security, restriction, aiicl flow srcririty) [']. The purpose of the inctliodology was to automate part of tlrc construction of the scv.ririty 1)roof. 111 tliis previous \vork ivts tlescrilml a class of stiit(\ ni;ic.liiiics i i i i t l a sct of proprrtic's t t i i i ~ tlicy shoultl sati.1'). to IN.srciirc. 111 this l)al)cr \vc' tlt%sc.i.il)csIiow t l i v Iiiacliiiic3s c a i i I)(,tlrscrilxtl a s proccssrs antl lrow to gcneratc the spec.iliQ. I licorenis for these processes.
4 . O(%,y,j,\q) 5 O ( ~ , y , j-t 1,s) when e = 4 ( i . ? y j , s ) and when a n output is to be made and the traiisaction is not fiiiislied 5 . O ( Z ?y , j , .s) 5 Z ( f ( 5 , y,s"(e))) when a nondetmministic decision satisfying p(?, y, j, s , e ) is to he niade and the transaction is finished 6. O(Z,y,j,s) .5 O(Z,y,j l,s"(e)) when a nondeterministic decision satisfying p ( Z , y , j , s, e) is t o be made and the transaction is not finished
Itoiighl!. speaking, the methodology liaiitlletl state machines of the following form: Get an inpiit from the buffer, make n scqurnce of nondeterministic decisions and outputs, antl tlirii
+
return to haiidle the nest inpiit.
Ilcrr is a hrief formal description of the state machines. We that the inputs are buffered. \Ye let I represent s t a t c s \\here the next input is to be taken from the bufrer iiirtl lct 0 represent states wherr out puts or nontlctoministic. t l v t isions are to be made. 'llirse s t a t c s arc parameterized l)y .r \vliich a r e parameters for the tlir sprcific niodel, by j iiitlic.iiting how many outputs antl nondeterministic tlecisioirs lravr bccii inatle since the last iul>ut, by s ii~tlicating t lie iioirtlrtf.riiiinistic decisions, by y indicating wliat tlie previolis iiilnrt was, antl by e indicatiiig cithcr ail output or a iicintlctcrniinistic clioice. T h e function f(?,y, s) will indicate i v l i a t tlie i i t w parameters of thc next illput state are . The ftiiiction 4 ( Z , y , j , s) will indicate what t.he oritput should be antl t he rela.tion p ( $ , y , j , s, e ) will indicate the possible non&,I wninistic choices. A 1runsncfion for an input y on such iissuinc
This condition was called (Def) in the previous paper. For such machines to be secure it is sufficient that they satisfy the following additional constraints with respect to some projection function projl on the parameters:
( I l a l t ) from state I ( ? ) , after any given input y, the state machine may eventually return to an input s t a t r i.e. for any sequelice of outputs and nondeterministic drcisions D
(C''
such that I ( % ) O(it,y,j,s) there is a ~ c q u e n c e 0' and a sequence of parameters :C'such that
of events
I(;'). In particular, there is no rcachable state which will surely have an infinite number of consecutive outputs and delays, or be unable t o make O(Z,y,j,s)
*'lliis work was supportrd by the Air Force Systems ('oiiiiiiiiiid at Rome Air Development Center under ('oill.rnct No. 1:30602-85-C~-0096. The views and conclusioiis cmtained in this paper are those of the author a i i d slioiild not be nrterpret.etl as necessarily representing the official policies, either expressed or implied, of llic Air Force or the U.S. Government. '1 woultl likr to thank Owen Rambow for implementing the algorithm.
133
TH0255-0/89/oooO/0133$01.00 0 IEEE
some transition. In practice, we may make the stronger assumption that there is a bound, b ( 5 , y), on the number of outputs and delays which can transpire before returning t o the next input state. (Remark: this condition does not have t o apply for inputs a t the lowest possible level) The level of any output from O(i?,y,j,s) is 2 the level of y (for those j and s where there is sequence of out-
processes and the functions which are used in building the processes.
puts and delays U such that Z(3) (SI)
% the ordering is don don : : (leve1,level)
-> assertion;
AXIOM transitive is [all a:level,b:level,c:level] dom(a,b) & dom(b,c) => don (a, a=b;
end ;
Introduction to USL
T h e first thing to notice is that collections of specifications are grouped together in a theory. The use of theories is a way t o group related facts together in meaningful components. For details about the theory mechanisms of the Romulus project see (41.
Now rather than dircctly working with state transitions it
inore understandable if we exprrss the machine in a that looks more like a program specification. To do this we einploy the language USL [3] from the Romulus project (foi.mc~rlycalled the Ulysses project) [4].
ih
Theory of partially ordered set of levels
ofteii
\ray
The first two lines are just comments. SL uses the 78 as a mark for the beginning of a comment and everythii-g after the % until the end of the line is not translated.
Tlic 1S1, language is intended as a general language to specify ~n,itli~mat,ical theories in Rornulus. It also contains some fcatiu.rs wliicli specifically help i n t,lie construction of pro-
In the example, the first kind of specification is a way of defining a sort. level is just some sort with no added information given. doni is a function which takes two levels and produces an assertion. The next group of specifications are axioms which tell us more about the definition of don. The quantified variables are included in the brackets itnd the implication is indicated by the => symbol.
Cf’SS(’S.
Tlic. semantic basis for the USL language is the theory of coiist,ructions [5] and not just, first, order logic. Hence the language has quite a bit of expressive power. IIowever the s!,iitax is constructed so that tlie t.ypica1 user only needs to know ahout tlie theory of constructions when they wish t o eiiiploy some of the fancier facilit,ies of USL.
Although we use upper case, the language is not case sensitive. Also note that the ; is used as a specification separator.
‘rlici.c. are t,wo basic kinds of objects. The first are called “ s o l - i s ” wliich are tlie data types a n d thc functions on those data types. Tliese include such things as natural numbers, lmolcans, lists, ordered pairs, processes, ils well as function
Process Construction
spaces formed form these. T h e second kind of object are callcd “assertioiis” which are statements about the sorts. Of part.icular intcrest for the Romulus user are assertions about
Part of the USL language is a facility t o aid in the construction of processes.
I34
o Send(port ,data) - is the output statement
- sends the items from the datalist consecutively Receive(port,data) - is an input statement Avait msg,port from portlist then - receives an input from a buffer connected t o the ports in portlist Plus - is the nondeterministic selection of CSP Select - is for nondeterministic selection which does not check which receives are ready for inputs. Parallel - is parallel composition of processes Skip -- is a “do nothing” statement Parameterized processes - for example AnyProcess(x,y,z)
o Multisend(port ,datalist)
o o
o o o
o o
theory level level : : sort; dom : : {level,level) -> assertion; AXIOM transitive is [all a:level,b:level,c:levell dom( a, b) & dom(b,c) => dom (a,c) ; AXIOM reflexive is [all a:levell dom(a,a) ;
AXIOM antisymmetric is [all a:level ,b:level] (dom(a,b) & dom(b,a)
=> a=b;
end ;
A detailed example appears in the next section.
%% %% %%
0t her features
.................................................. ports portkind := input I output ;
In this section we describe a few more features of the language so that the next example can he understood. For a more complete description of the language see [GI or [3].
port := in1 I in2 I out1 I out2;
1 Is the port multilevel? multilev :: port -> assertion;
Let
It is often convenient to introduce new symbols t o rrtluce tlle complexity of ail expression. For example, we Inay LISC the term Let c=a+b-2 i n 3*c*(c+5)/(~-1) for t I ~ c t r r n i 3*(a+b-2) *((a+b-2)+5)/( (a+b-2)-1).
%level of a port % If the port is single level this will represent that % particular level. For the simplicity of this % example, the level of a multilevel port % carries no meaning. : : port -> level ; levp
Definitions \Ve can introduce an object by giving its sort and then axiomatizing it. The USL language also supports othel \vays of defining objects. One such way is a free algebrn construction. For example, we could define the na.tural numbers as Number : = Zero I Successor(Zero). Here is an example of another form of definition that is used:
kind
: : port
-> portkind
;
define member(?p:port.C1:list port)= ”true, member(?p,[?xl-?l)= (xpp) \ / member(?p,?l);
define isout(?e:eventtype) = if (e=samplel) then true else false
%% The following conditions on the ports must be %% satisfied
111 this form the sort of the function and its axioms are autonratically generated. ( T h e ? serves to iiidicatc that e is a free varial)le, because in the more general forni of this construct it is needed.)
Axiom portaxioml is Call p:portl (multilev(p)); Axiom portaxiom2 is (kind(inl)=input) & (kind(inP)=input) & (kind(outl)=output) & (kind(out2)=output) ;
A Sample Process Specification %
..................................................... %% %% %%
The Process Main
messages a message has a label and other data
datatype : : sort; msgtype := record msg (label:level, Uata:datatype);
Theory anexample
1% .................................................. %% Theory of partially ordered set of levels %%
................................................... %%
I35
1% Events are pairs of ports and msgs
Axiom Call 1:levelI Call m:msgtype] Call pari :paramtype] Call par2:paramtypel ( dom(1, m.labe1) => (proj(1 .pari) =proj(1.par21) => (proj(1,update(parl ,m>)=proj (1.update(par2 ,m)))) ;
Eventtype :=record Event(theport :port,themsg:msgtype);
%% %% %% %%
.................................................. The Level of an event
%% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . %% The process definitions %% %% %% The process Main can receive inputs from either %% port in1 or port in2. Inputs from in2 are just %% passed on through port out2. and then the %% process returns to its original state. Inputs % % from in1 cause the formation of a new %% parameter and an output based on the new x % parameter. The use of the auxiliary process Aux is to demonstrate the theorem generator. %%
1% If the port is multilevel the level of the event %'I, is the label, else it is the level of the port lev : : eventtype -> level; Axiom Axlevl is Call m:msgtypel Call p:portl lev (Event(p,m)) = (if multilev(p) then m.label else levp(p) ) ;
1%. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . %% The functions low and high are useful 1% definitions for user readability Define low(?l :level,?e:eventtype)= dom(l,lev(e)) Define high(?l :level,?e:eventtype)= -low(l ,e) ;
Main : : paramtype -> Process; DefProcess Aux(summary:paramtype,amsg:msgtype) = let newsummary=update(summary,amsg) in begin send(outl,result(newsummary,amsg)); Main(newsummary)
;
1%. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 'I,% Auxiliary information %% %% %%
end
end ;
These functions are used in the definition of the process
DefProcess Main(summary:paramtype) = await amsg,aport from [inl,in2] then begin if aport=inl then Aux(summary,amsg) else begin send(out2,amsg); Main(summary) end end end
paramtype : : sort; update result
:: ::
(paramtype,msgtype) -> paramtype; {paramtype,msgtype) -> msgtype;
,, proj is the projection function on the parameter proj
::
(level,paramtype3 -> paramtype;
%% The following axioms add constraints to the %% update and result functions
end
Axiom Call par:paramtype] Call m:msgtypel dom((result(update(par,m) ,m)) .label,m.label);
Theorem Generation
Axiom [all 1 :levell [all m:msgtypel [all par :paramtype] ( -(dom(l,m.label))) => (proj (1,par)=proj (1,update(par ,m)) ) ;
Rather than trying to support the most general theoren generation paradigm, we have attempted to strike a balance between generality and the simplicity of theorems that i : generates. We plan on having a number of different kinds of methods to generate theorems so that the user of the Romulus system can pick the most appropriate one. In this way he can fit the complexity of the theorems generated to the complexity of the model to be verified. In this paper we
136
illustrate a case which is fairly general. Aux
Main
We begin by describing the simplifying assumptions.
p
await
1. T h e only form of indirect or direct recursion is through a call on the main process (i.e. the one which can get the inputs.) If induction is needed it can usually be encoded as a list of outputs and then the multisend construct ran he used. This will localize the induction to where it is needed.
b
2 . When handling the (Pl) constraint, we assume thaL
k
send Main
Main
Figure 1: Before Transformation
when the same nondeterministic choices are made then the same i f - t h e n - e l s e branches will be taken for both inputs. That is for any level 1, when the lowlevel aspects of the information look the same, then on a low-level input when the same nondeterministic choices are made then the same path will be taken.
Main
P
3. The form of the presentation must be transparent. For example, a term which is semantically equal t o a send command, but not syntactically identical t o that command, may generate a “method does not apply” condit ion.
A
Main
await
If
Main
Figure 2: After Transformation
The system does not generate the projection functions autoiliatically, tliey must he provided 1)y t h e iiser. This ought to ),e lairly siinple (since d a t a is typically labeled in some way).
We now generate the appropriate theorems for the outputs and the new parameter formation. We generate the theorems which claim that:
I-’ and that it auxiliary processes P1, P2, ..PA’. \Ve begin by starting \\.it11 P anti chcck that it starts with an await. We then intliicti\-ely check that each construct used is appropriate (i.e. no other input statements) and expand the definitions of the auxiliary processes when encountrred. Io I)c\ginlet us suppose that the main process is
Same P a t h For a low level input, the i f - t h e - e l s e branch conditions do not depend on high level information. This is used to simplify the proofs of the other constraints.
IIWS
If
UT f i i i t l
a recursion on a
Level The level of any output is 2 the level of the input which started the transaction. This is used t o prove (Lev)
Pi,we announce that the method
does not succeed in this case. (Itelnark: It is also possible to proccetl by using a process tiookiip theorem. but for this
Projhigh On high level inputs the low level part of the parameters is not changed. This is used t o prove ( P h ) .
c,xaniplc we cmploy t,he expansion tcc:linicluc~.)If a path of t Iic cspaiision tcrminates without tlirrctly calling the main 1)r(icc‘ss I-’ we will announre that tlie nicthod failed. This i i i c a n s that there is a path whic:li will caiise the process to I i a l t . ‘This usually nieans that tlierr is a violation of (Halt,) aii(1 i n fact that the process is not secure. However, it may i ~ i t w i i that the method is not applicablr. For example, tlie Iriincli may be impossible ( for instancr it may require that .r > 1 aiid that T < 0 ). This sort of h n c h would never gct takcn a i i t l so the violation of (Halt) is not real.
Projlowparam If two input states look the same to a low level user then when they accept a low level input and make the same nondeterministic decisions, the low level part of the parameters must still be the same after the transaction is completed. This is used for part of the proof of (Pl). Projlowout If two input states look the same t o a low level user then when they accept a low level input and make the same nondeterministic decisions, the outputs from these states will be the same for the transaction. This is used for the other part of (Pl).
Tlic above checks arr sufficient t o guarantce that hoth (Def) aiid (IIalt) are satisfied.
IIwe is a diagram showing the definition expansion for the #11)o\~: czsainple.
I37
Example Generation of Theorems
(proj(l,x)=proj (1.y) 1 => ((aport=inl) &(aport=inl)) => ((LET summary=x,newsummary=update(summary,~nsg) IN proj(1,nevsummary))= (LET summary=y,newsummary=update(summary ,.msg) IN proj(1,nevsummary)))));
The method mentioned above has been coded and tested with a number of examples. Here is the result of applying the generation to the example specification described above. (Note: The name of the theorem includes an indication of why it was generated as well as a unique numeric identifier.)
%" Theorem main-level-14184 is ([all l:level] Call amsg:msgtypel [all aport:pord member(aport, [in1 .in21 => (Call summary:paramtypel (-(aport=inl)) => dom(lev(event(out2, amsg)) ,
%%% Theorem main-same-path-14173 is ([all l:levell[all amsg:msgtype]Call aport :port] member(aport.[inl,in2]) => (Call x:paramtypelCall y:paramtypel low(l,event(aport,amsg)) => (proj(1,x)=proj (1.y)) =:, ((aporttinl) aport=inl)));
lev(event(aport,amsg)))));
%%% Theorem main,projlowout-l4185 is ([all 1:level] [all amsg:msgtype] [all aport :porl:l member(aport,[inl,in2]) => low (1,event(aport ,amsg)) => (Call x:paramtypel Call y:paramtypel (proj(l,x)=proj (1,~))=> ((-(aport=inl)) 6 -(aport=inl)) =>
%%% Theorem main-level-14176 is (Call 1:level1 [all amsg:msgtypel[all aport :port] => member(aport,[inl,in2]) ( [all summary :paramtype] (aport=inl) => (LET newsummary=update(summary,amsg) IN dom(lev(event (out1 ,result(nevsummary,amsg))) ,
(event(out2,amsg)=event(out2,amsg))))
;
%%% Theorem main-projhigh-14188 is ( Call 1:level] Call amsg:msgtypel[all aport :port1 member(aport,[inl,in2]) => high(l,event(aport,amsg)) => (Call summary:paramtypel (-(aport=inl)) => (proj (l,summary)=(LET summary=summary IN proj(1,summary)1) 1) ;
lev(event(aport,amsg))))));
%% % Theorem main-projlovout-14177 is ( C a l l 1:levellCall amsg:msgtypel[all aport :port] member(aport,[inl,in21) => low(l,event(aport,amsg)) => ([all x:paramtypel[all y:paramtypel (proj(l,x)=proj (1,~)) => ((aport=inl) &(aport=inl)) => ((LET summaryrx, nevsummary=update(summary, amsg) IN
%%% Theorem main-projlowparam-14189 is (Call 1 :levellCall amsg:msgtypel[all aport :port1 member(aport,[ini,in2]) => lov(l,event(aport ,asp)) => (Call x:paramtype] Call y:paramtypel (proj(l,x)=proj (1.~1)=> ((-(aport=inl)) & -(aport=inl)) => ((LET summaryox IN proj(l,summary))= (LET summary=y IN proj(1,summary)))));
event(outl,result(newsummary,amsg)))=
(LET summary=y, newsummary=update(summary ,amsg) IN event(outl,result(newsumrnary,amsg))))));
%%% Theorem main-projhigh-14180 is ( C a l l 1:levelI[all amsg:msgtypel[all aport :port] member(aport. Cinl,in2]) => high(l,event(aport,amsg)) => ( [all summary :paramtype] (aport=inl) => (proj (l,summary)= (LET neusummary=update(summary,amsg) IN proj(1,nevsummary)))));
Proof of Theorems The next stage of simplification is to provide help in proving these results. The first step is to use a tactic (i.e. an inference rule) which repeatedly applies the following:
%%% Theorem main-projlovparam-14181 is (Call 1:levellCall amsg:msgtypelCall aport :port] member(aport,[inl,in21) => low(l,event(aport,amsg)) => (Call x :paramtype1[all y :paramtype]
1. It removes the universal quantifiers by picking Teneric constants. 2. It simplifies implications by making the anteccdent a hypothesis and the consequent the fact that na-eds to be proved.
I38
We expect to b e able t o do all of the above steps automatically by the use of one tactic. Further simplification may then b e achieved by using specialized tactics t o help with these kinds of formulas.
3. It simplifies any let statement by making the substitution. This approach usually simplifies the formula t o be proved t o either an equality, an inequality (with dom), on an equivalence.
Here is a possible completion of the proof 1. Substitute in1 for aport and
For example in proving the second theorem main-level-14176 :
prove: dom (lev(event(out1,
result(update(summary ,amsg) ,amsg) ) ) , lev(event (in1 ,amsg) ) )
1. We start with Theorem main-level-l4176 is ([all 1:levell [all amsg:msgtypel[all aport :port1 member(aport,[inl,in2]) => (Call summary:paramtypel (aport=inl) => (LET neusummary=update(summary ,amsg) IN
2. Expand the definition of lev and prove: dom( (if multilev(out1) then result(update(summary,amsg) ,amsg) .label else levp(out1) 1, (if multilev(in1) then amsg .label else levp(in1) 1
dom(lev(event(outl,result(neusummary,amsg))),
lev(event(aport ,amsg))))));
2. Pick values for the quantified variables a.dd type assignments C1:levell,
3. Simplify this by using portaxiom2. We have that multilev(out1) and multilev(in1) we need t o prove:
Camsg:msgtypel, Caport:portl and prove: member(aport , [in1 ,in21 ) => (Call summary:paramtypel (aport=inl) => (LET newsummary=update(summary,amsg) IN dom(lev(event (outl,result(neusummary,amsg))), lev (event(aport,amsg) ) ) ) )
SO
dom( result (update(summary,amsg) ,amsg) .1abel , amsg .label)
4. By using first axiom for result and update
3 . Llake the head of the implication a n Iiypothcsis add to the list of hypotheses: member (aport,[in1 ,in21 ) ancl provr: (Call summary :paramtype] (aport=inl) => (LET neusummary=update(summary,amsg) IN
Call par:paramtype] Call m:msgtypel dom((result(update(par.m),m).label, m.label)
with summary for par and amsg for m we have:
dom(lev(event(outl,result(neusummary,amsg))), lev(event(aport,amsg)))))
dom(result(update(summary,amsg),amsg).l,~bel, amsg .label)
4. Pick Iralues for the quantified variable
5 . We now can directly use this fact t o get the desired result
add type assignments [summary :paramtype] and prove: (aport=inl) => (LET neusummary=update(summary,amsg) IN
Concluding Remarks
dom(lev(event(outl,result(neusummary,amsg))). lev(event(aport,amsg))))
This approach has worked out very well in a number of cases. Work is underway in extending this technique t o ot.lier kinds of examples.
5 . Alake the head of the implication an hypothesis add to the list of hypotheses: (aport=inl) a n d prove:
*
(LET neusummary=update(summary,amsg) IN dom(lev(event(outl,result(nevsummary,amsg))), lev(event(aport,amsg))))
References
6. Reduce the LET clause prove:
[I] David Rosenthal. An approach t o increasing the automation of the verification of security. In Proceedings of the Computer Security Foundations Workshop, pagcs 90-97. Mitre Tech Report M88-37, June 1988.
dom (lev (event(out1, result(update(summary,amsg) ,amsg))),
lev (event(aport,amsg) ) )
I39
[2] Daryl AlcCullough. Ulysses computer security properties modeling environment: T h e theory of security. Technical Report TRS7-222, RADC, 1988. [ 3 ] Daryl AlcCullough. Final design of T.S.L. - SL: A process specification language for Ulysses. Odyssey Research .Associates Tech Report, 19SS. [4] lilysses Staff. Ulysses: A computer-security modeling ciiviroiiiiicnt. In Proceedings of the 1 lth National Comp u f f r .Security Conference, September 19SS. [5] 'T11ic.rl.y Coquand and Gkrard Huet. Constructions: A higher order proof system for meclianizing mathematics. In El'ROCAL85, volume 203 of Lecture Notes in Computcr ,Science, pages 151-184, Berlin, 19S6. SpringerVerlag. [Ci] Davit1 Rosenthal. SL users manual. Odyssey Research Associates Draft Report, 19S9.
