Proof-Carrying Authentication∗

Andrew W. Appel and Edward W. FeltenSecure Internet Programming Laboratory

Department of Computer SciencePrinceton University

Princeton, NJ 08544 USA

August 9, 1999

Abstract

We have designed and implemented a generaland powerful distributed authentication frame-work based on higher-order logic. Authenti-cation frameworks — including Taos, SPKI,SDSI, and X.509 — have been explained usinglogic. We show that by starting with the logic,we can implement these frameworks, all in thesame concise and efficient system. Because ourlogic has no decision procedure — althoughproof checking is simple — users of the frame-work must submit proofs with their requests.

1 Introduction

Distributed authentication frameworks allowsharing of access to resources across adminis-trative boundaries in a distributed system. Themain abstractions they support are name-to-key bindings, access control, and delegation.∗To appear in 6th ACM Conference on Computer and

Communications Security, November 1999.Copyright c©1999 by the Association for ComputingMachinery, Inc. Permission to make digital or hardcopies of part of this work for personal or classroomuse is granted without fee provided that copies are notmade or distributed for profit or commercial advantageand that copies bear this notice and the full citationon the first page or intial screen of the document.Copyrights for components of this work owned by othersthan ACM must be honored. Abstracting with credit ispermitted. To copy otherwise, to republish, to post onservers, or to redistribute to lists, requires prior specificpermission and/or a fee. Request permissions fromPublications Dept., ACM Inc., fax +1(212)869-0481, orpermissions@acm.org.

Statements in these frameworks are representedas data structures that are often digitally signedto ensure their integrity.

Several authentication frameworks exist; wemention a few here as examples. The Taosoperating system provided support for secureremote procedure call and data structures torepresent authority and identity [6]. X.509 [15]is a widely-used standard for expressing and us-ing digital certificates. SPKI [4] and SDSI [14](since merged under the joint name SPKI)were reactions to the perceived complexity ofX.509; in both cases the ‘S’ stands for ‘simple.’PolicyMaker [3] is a language for expressing se-curity policies; it can be applied to distributedsecurity policies. Kerberos [12], unlike the otherframeworks, uses symmetric-key encryption toauthenticate users. Each framework has adiffererent semantics and offers a different kindof flexibility.

Formal logic has been used successfully toexplain authentication frameworks and proto-cols, most notably in the design of the Taosdistributed operating system [1, 6]. The design-ers of Taos started by constructing an elegantand expressive logic of authentication as an ex-tension of propositional calculus. They provedthis logic sound — any provable statement istrue in all models — which makes the logican attractive basis for constructing a system.However, since they wanted a server presentedwith a request to be able to decide whetherto grant the request, they chose to implement

1

only a decidable subset of their authenticationlogic. In a decidable logic, there is an algorithmfor determining the truth (or falsehood) of anystatement.

Using a simple and decidable logic wouldhave had advantages: it’s easier to provemetatheorems such as “there’s no way Alicecan access the file bar.” Why, then, do weuse an undecidable logic? Previous approacheshave taken a set of basic inference rules andadded application-specific inference rules tomake application-specific logics; but the newrules must be trusted, i.e. proved sound.By allowing quantification over predicates, wecan use a single set of inference rules, withapplication-specific rules proved as lemmas;therefore, the application-specific rules can beused to prove access requests to servers thatknow only the basic logic. However, logicswith quantification over predicates – higher-order logics – tend to be undecidable: there isno general algorithm for producing proofs of alltrue statements.

Still, a server presented with a request mustbe able to figure out what to do. We solvethis problem by analogy with proof-carryingcode [9]: the client desiring access must con-struct a proof, and the server will simply checkthat proof. Even in an undecidable logic, proofchecking can be simple and efficient. We put theburden of proof on the requester. We will showseveral different strategies by which requesterscan construct proofs, for example by pickingan application-specific decidable subset of ourgeneral logic.

Each of the existing frameworks has chosena particular set of concepts and abstractions:a particular form of delegation, a key-bindingmechanism, certain access control rules, and soon. Although these choices are as reasonable asany, no set of choices is right for everybody. Byusing higher-order logic, our framework allowsthe specification and use of new abstractionsand new variants on the existing abstractions.

Since all the application-specific logics areexpressed using the same general inference

rules, they can safely interoperate: We can takeone theorem proved using the SPKI definitions,and another proved using Taos definitions, andcombine them to prove access even to a serverthat has seen neither set of definitions before.

Although we have expressed SPKI in ourlogic, we don’t really recommend the use ofSPKI 5-tuples for authorization; the operatorswe outline in sections 4 and 5 seem morenatural.

2 An Example

Suppose three principals, a client Alice, afile server Bob, and a certification authorityCharlie, are interacting across a network. (SeeFigure 1.) Bob receives a request to “readfoo.” Bob’s access control list says that aprincipal called Alice can read foo — but isthe request from Alice? Bob trusts Charlieto guarantee key-to-name bindings, and Bobknows that Charlie’s key is Kc. Alice hasobtained a certificate signed by Kc that “Ka

is Alice’s key,” and uses Ka to sign “read foo.”Armed with all of this information, Bob cansafely grant the request to read foo.

Our framework can express this as follows.We can treat “read foo” as an uninterpretedatom, meaning that the logic doesn’t knowwhat it means although the participants do.Digital signing is a primitive of our logic, so(Ka signed read foo) is a statement of the logic.

Each principal is modeled as the set offormulas that she will admit as true. Thus,Alice(∀x.x → x) means that Alice is willing toclaim that (∀x.x → x). That’s not admittingmuch, as the statement is a tautology! Butin fact any principal is required to admit anystatement provable from other statements sheadmits.

We translate the statement “Alice wants toread foo” as Alice(read foo). We translate“read foo if Alice says to” as follows:

Alice(read foo) → read foo.

Charlie’s certification that Ka is Alice’s key

2

AliceBob

Charlie

Request: read foo

Key certificate:

01001110 =sign(Kc, keybind(Ka, Alice))

A1: trustedCA(Charlie)A2: keybind(Kc,Charlie)A3: controls(Alice, read foo)

Proof:[S1: signature 10010111 Ka ReadFoo][S2: signature 01001110 Kc (keybind Ka Alice)]controls_e A3 (keybind_e (controls_e (trustedCA_e A1) (keybind_e A2 S2)) S1).

OK to read foo?Prove it to me!

I want toread foo.

CertificationAuthority

Figure 1: Distributed authentication.

we translate as

Kc signed (∀F. (Ka signed F )→ (Alice(F ))).

Bob’s knowledge of Charlie’s key is stated as

∀F. (Kc signed F )→ Charlie(F ).

Finally, Bob’s trust in Charlie is expressed as amemorandum to himself:

∀k.∀p.Charlie((∀S. (k signed S)→ p(S)))→∀S. (k signed S)→ p(S).

These statements are expressed in a higher-order logic (i.e., one in which we can quantifyover formulas and predicates), with inferencerules given in Figure 3.

Since these statements are rather unwieldy,it is only natural for the participants to haveagreed upon some definitions:

keybind(k, p) stands for∀S. (k signed S) → p(S). That is, k is p’skey, so that if k signs some statement Sthen p should be considered to believe it.

p controls S stands for p(S)→ S. That is, p“controls” the statement S, so if p says Sthen S will be considered true.

trustedCA(c) stands for∀k.∀p. c controls keybind(k, p), meaning

that c is a trusted certification authority:if c says some key binding, we can trustthat key binding.

These particular definitions may be well-suited to our example transaction, but they arehardly likely to be general enough for the realworld. The strength of our approach is thatit does not “build in” a fixed set of definitionsbut allows the participants in each applicationto define and use their own abbreviations.

Some useful lemmas follow immediately fromthese definitions. For example, we can provethe lemma controls e, which states that ifp controls S and p says S, then S is true:

p controls S p(S)S

controls e

Additional lemmas allow one to use state-ments by a trusted certification authority, andto make inferences from key bindings:

trustedCA(c)c controls keybind(k, p)

trustedCA e

keybind(k, p) k signed S

p(S)keybind e

2.1 Constructing a proof.

Bob starts with the following assumptions inhis security database:

A1 = trustedCA(Charlie)

3

A controls read foo

trustedCA(C)C controls keybind(Ka, A)

trustedCA e keybind(Kc, C) Kc signed keybind(Ka, A)C(keybind(Ka, A))

keybind e

keybind(Ka, A)controls e

Ka signed read fooA(read foo)

keybind e

read foocontrols e

Figure 2: Proof that Alice can read foo.

A2 = keybind(Kc,Charlie)A3 = Alice controls read foo

Using these assumptions, and the lemmasshown above, Alice can prove to Bob that heshould allow her to read foo. Before Alice cando this, Bob must publish his assumptions –his security policy – so that she can construct avalid proof. Some parts of the policy – such as“Alice controls read foo” – he may not wish tobroadcast to the whole world, but he should atleast tell each client the assumptions relevantto her.

The proof is illustrated in Figure 2. It hasfive premises: the security policy A1, A2, A3 andtwo digital signatures sent by Alice with theproof. Alice can sign the statement read foowith her own key Ka; she must ask Charlie tosign the statement keybind(Ka, A) with his ownkey Kc.

The proof is checked as follows. Firstwe check the two digital signatures toestablish the facts Ka signed read foo andKc signed keybind(Ka, A). From assumptionA1 we prove C controls keybind(Ka, A)by the lemma trustedCA e. FromA2 and a digital signature we proveC(keybind(Ka, A)) by the keybind e lemma.Now from C controls keybind(Ka, A) andC(keybind(Ka, A)) we prove keybind(Ka, A)by the controls e lemma. From this anda signature we prove A(read foo) by thekeybind e lemma. Finally, from assumptionA3 and A(read foo) we prove read foo bycontrols e.

The definitions, and the proofs of the lem-mas, can be included with the proof for the

benefit of any participant who was not alreadyfamiliar with the definitions and their conse-quences.

3 The Logic

We are using a higher-order logic with the typeform of formulas and a base type, string, whichwill be used to represent keys, signatures, localnames, and for many other purposes. Theinference rules of the logic are given in Figure 3;except for the last four rules, it is standardhigher-order logic. The last four inference rulesallow reasoning about digital signatures andstatements by principals derived from signa-tures and names (strings). For reasoning abouttime, we also need the type integer and rulesfor arithmetic, which we do not show here.

The type form → form – which is a predicateon formulas – represents the worldview of an ac-tor in the system: a principal (an individual ormachine), a group of principals, or some othersuch combination. We will define a principal Pas a worldview that has the properties

∀F.F → P (F ) and∀F∀G.P (F ) ∧ P (F → G)→ P (G)

that is, if F is true then P admits it, and if Gis a consequence of other things P admits, thenP admits G.

A principal may be constructed from a stringby the built-in function N (). For any strings the inference rules name r and name imp eguarantee that the worldview N (s) satisfies theproperties required of principals.

We represent a cryptographic key as a stringin the X.509 SubjectPublicKeyInfo format, thatis, an AlgorithmIdentifer followed by a bit

4

A B

A ∧B and iA ∧BA

and e1A ∧BB

and e2

A

A ∨B or i1B

A ∨B or i2

A ∨B [A]C

[B]C

Cor e

[A]B

A→ Bimp i

A→ B A

Bimp e

A(Y ) Y not occurring in ∀x.A(x)∀x.A(x)

forall i

∀x.A(x)A(T )

forall e

X = Z H(Z)H(X)

congrX = X

refl

F

N (s)(F )name i

N (s)(F ) N (s)(F → G)N (s)(G)

name imp e

digital signature(s, k, F )N (k)(F )

signed

Figure 3: Inference rules of the logic.Quantification and equality (e.g., ∀x.∃y.x = y) arepolymorphic: the quantified variables may be ofbase type (such as string) or formulas, functions,or predicates. The logic also has operators andinference rules for integer arithmetic, existentialquantification, and falsehood, which are not shownhere.

string that is the actual key [15]. The rulesigned says that if s is the digital signaturewith key k of statement F , then N (k)(F ):the principal N (k) must admit any statementsigned by k. The informal k signed F standsfor the formal N (k)(F ).

There is an infinite family of digital signatureaxioms, one for each triple s, k, F where sis the digital signature with key k of therepresentation of the formula F . The proof-checking infrastructure must be able to checkdigital signatures using one or more encryptionalgorithms.

Because definitions such as “keybind” and“controls” are not part of our trusted com-puting base – such definitions are part ofapplication-specific customizable protocols –each server must be able to mechanically checkall proofs of their properties. As we will explainin Section 8, we have implemented a proof-checker for our logic (as will be necessary for theoperation of a server in a distributed authenti-cation system). Every lemma and theorem thatwe state in this paper has been mechanicallyverified.

4 Using the Logic

Since a worldview is just a predicate on for-mulas, worldviews can exhibit a wide varietyof behaviors. This fact can be useful, as wewill see below, but it also has its drawbacks.To simplify things, it is useful to define twospecial classes of worldviews, and to prove somelemmas about the behavior of these kinds ofworldviews.

Principals. The first special class of world-views includes those made by the N () operator,and other worldviews that behave like them;these satisfy

prin(P ) ≡(∀F. (F → P (F )))∧(∀F∀G.(P (F )→ P (F → G)→ P (G))).

Intuitively, prin(P ) means that we can assumethat P admits all tautologies, and that P

5

admits any formula that can be deduced fromother formulas it admits. The following twolemmas are provable:

prin(P ) F

P (F )prin taut

prin(P ) P (F ) P (F → G)P (G)

prin imp e

From the name r and name imp e inferencerules, we can prove the lemma

prin(N (s))n is prin

We can use function composition on world-views:

(A ◦B)(F ) ≡ A(B(F )).

A ◦ B can be thought of as “A quoting B”.Composition of two principals is a principal:

prin(A) prin(B)prin(A ◦B)

prin comp

We can also define a ∧ w operator on world-views, so that A ∧ wB admits a formulawhenever both A and B admit it.

(A ∧ wB)(F ) ≡ A(F ) ∧B(F ).

We can then prove the lemma

prin(A) prin(B)prin(A ∧ wB)

prin ∧

along with lemmas saying that ∧ w is associa-tive and commutative.

Similarly, we can define a ∨ w operator:

(A ∨ wB)(F ) ≡ A(F ) ∨B(F ).

The ∨ w operator can be used to constructgroups of worldviews in which any member canspeak on behalf of the group. ∨ w is associativeand commutative. However, if prin(A) andprin(B), this does not imply prin(A ∨ wB).(For example, we could have A(F ) and B(F →G), but neither A(G) nor B(G).) Groups

evidently satisfy a weaker property than prin();we write this property as

group(A) ≡ ∀F.(F → A(F )).

We can then prove the following lemmas:

prin(A)group(A)

prin is grp

group(A) F

A(F )grp taut

group(A) group(B)group(A ◦B)

grp comp

group(A) group(B)group(A ∧ wB)

grp ∧

group(A) group(B)group(A ∨ wB)

grp ∨

In addition to these classes of worldviews, anyapplication is free to define its own classes.

4.1 Says and Quoting

The system as described so far is adequate, butsome may find the representation of principalsas functions confusing. In order to make thesystem more palatable to these users, we candefine operators to abstract away the represen-tation of worldviews.

We do this by defining a says operator:

A says F ≡ A(F ).

Some simple lemmas about says follow:

group(A) F

A says Fsays taut

prin(A) A says F A says (F → G)A says G

says imp e

We can then define a quoting operator | as

A|B ≡ A ◦B,

and it follows that

(A|B) says F ↔ A says (B says F )quote ident

.

6

The ∧ w and ∨ w operators will lead to theidentities

(A ∧ wB) says F ↔ (A says F ) ∧ w(B says F )

(A ∨ wB) says F ↔ (A says F ) ∨ (B says F )

If we use a logical framework that supportabstract data types, we could choose to hide therepresentation of principals, says, and quoting,and simply expose the set of lemmas theysatisfy.

5 Application-Specific Operators

We expect that the designers of specific appli-cations will often have in mind their own setsof operators and rules for manipulating them.Our system allows users to define new operatorswith manipulation rules, so it can implementapplication-specific operators. In this section,we give as an example a set of operators wehave found useful.

Any application using our system is free todefine whatever operators it likes and provelemmas about them. This kind of extensibilityis the main advantage of our logic-based ap-proach.

Controls. First we define the controls opera-tor1

A controls F ≡ ((A says F )→ F ).

Informally, A controls F means that A canmake F true just by saying it. We can provea simple lemma

A controls F A says FF

controls r.

We can then prove a lemma that says controlcan be handed off from one principal to another:

prin(A) A controls F A says (B controls F )B controls F .

1This definition differs from the one given in Section 2in order to account for the says abstraction.

Speaksfor. The operator

A speaksfor B ≡ ∀x.(A says x→ B says x)

says that everything said by A is also said byB. Generally, if A speaks for B, then A canexercise any rights that B has.

Names. The ability to translate any stringS into a principal N (S) gives us the ability todefine name-spaces. For example, we can definea localname operator as

LN (A,S) ≡ A|N (S).

Now A can give principal B the right to speakfor LN (A,S) by making the statement

A says (B speaksfor N (S)).

Now (assuming prin(A)) it follows thatB speaksfor LN (A,S)2.

We can also use local names to implementroles, with LN (A, role : admin) referring toA’s administrative role; A could then makea statement F on behalf of the role, such as(A says (N (role : admin) says F )).

5.1 Access Control

Suppose a file server machine M stores a filef , and M wants to limit who can read f . (Weassume prin(M).) This can be implemented byrequiring each read request on f to carry a proofof (M says read(f )). M can give another prin-cipal A permission to read the file by makingthe statement (M says (A controls read(f ))).Now if A makes the request (A says read(f )),A can use the request, along with the statementmade by M , to prove M says read(f )3.

2Proof sketch: Suppose B says F . It follows bysays taut that A says (B says F ). Now we havetwo statements that are said by A: B says F andB speaksfor N (S). These two statements togetherimply N (S) says F , so when they are both saidby A, and since prin(A) holds, we can infer thatA says (N (S) says F ). By the definition of localname,this equals LN (A,S) says F .

3To prove this result, we start with A says read(f ),and then (using prin(M)) apply the says taut lemma to

7

5.2 Public-Key Infrastructure

Public-key certificates and their use can be im-plemented in our system as well. A certificationauthority C can issue a certificate binding keyKa to principal A:

(cert C Ka A) ≡ C says (N (Ka) speaksfor A).

This certificate is pointless unless we trust C toissue certificates; this trust can be encoded as

trustedCA(C) ≡ ∀k∀p.C controls (N (k) speaksfor p).

Now we can prove lemmas such as

trustedCA(C) (cert C Ka A) Ka signed F

A says F

indicating that our definitions are consistentwith one model of public-key infrastructure.

Of course, other definitions may make senseto other people. The strength of our systemis that it allows anyone to make their owndefinitions.

5.3 Expiration and Revocation

The primitive now() maps strings to integers;now(m) gives the current time as measured onthe clock of the host whose name is m. Wemake no assumptions about how different clocksare related, though any principal can makestatements and form beliefs about how any twoclocks are related.

When Bob checks the proof of any statement,he will have an assumption in his assumptiondatabase of the form,

now(bob.com) = 83487

if 83487 is the current time.

deduce M says (A says read(f )). Then we start withM says A controls read(f ) and expand the definitionof controls to deduce M says ((A says read(f )) →read(f )). The proof is completed by combiningthe results of the previous two sentences, using thesays imp e lemma (and the assumption prin(M)) todeduce M says read(f ).

Statements can be given limited periods ofvalidity. For example, the statement

A says ((now(Bob) < T )→ F ),

implies A says F until Bob’s clock reaches T ;after that it is vacuous. Of course, a statementthat expires might be renewed with a laterexpiration time, and statements might comewith hints about how to renew them. In orderfor Alice to generate a proof that will be validon Bob’s machine, she should first learn howmuch clock skew there is between her machineand Bob’s. Also, if Charlie trusts Bob to keepthe clock skew between Bob and Charlie under5 seconds, at least until tomorrow, he can issuethe statement,

Kc signed (now(charlie.com) < 100929 →|now(charlie.com)− now(bob.com)| < 5)

Such certificates about clock skew can helpAlice formulate a proof that her key-certificate(signed by Charlie) is still valid with respect toBob’s clock.

An alternative to expiration is revocation.For example, the statement

A says (¬revoked(F )→ F )

says that A says F , unless F has been revoked.A could periodically send out a revocation list;for example

A says ((now(A) < T )→∀x.(revoked(x)→ (x = S1 ∨ x = S2 ∨ x = S3))).

From this we can infer that (until A’s clockreaches T ) statements other than S1, S2, andS3 have not been revoked. By making T onlya short time in the future, we can achievethe effect of on-line revocation list checking.As usual, the cost of frequent revocation listupdates has to be balanced against the timerequired for revocations to propagate throughthe system.

8

6 Alternative Versions of Says

The definition of says given above seems natu-ral, but some applications may want a versionof says that behaves differently. These applica-tions are free to define and use the primitivesthey want. We now give two examples ofalternate definitions of says.

6.1 Says without prin()

Some users may find it more natural to reasonabout a world where rules like says taut andsays imp e hold for all principals. This can beachieved by defining a new operator:

A saysp F ≡ F ∨ (prin(A) ∧A(F )).

Two lemmas follow:

F

A saysp F

A saysp F A saysp (F → G)A saysp G

We can then proceed to define new versionsof the other operators such as controls, and toprove the corresponding lemmas.

6.2 Says without Delegation

Our first definition of says allows any principalto delegate any rights it may have. Someapplications may not like this, so we may wantto define a version of says that does not allowarbitrary delegation. To do this, we define a“says directly” operator:

A saysdir F ≡ ∃K.((A = N (K))∧(K signed F )).

Now if B says ((A saysdir F ) → F ), B hasdelegated to A all of B’s rights to F , butA cannot delegate these rights further, sincethe only way A can exercise these rights is todirectly sign a request to use them.

We can define a “says with optional delega-tion” operator:

A saysoptD F ≡ (A saysdir F )∨(D∧(A says F )).

Now A can delegate its rights to B:

A says ((B saysoptD F )→ F )

and B can delegate these rights to third partiesif and only if D is true.

There are many variants of says, and oursystem allows each application to define and usethe variant that best suits its needs.

7 Encoding Other AuthenticationFrameworks

Our system is general enough to encode otherdistributed authentication frameworks. Weencode a framework by expressing its primitivesin a set of definitions, and then proving theframework’s processing rules as lemmas. Byproviding a single language in which the se-mantics of several frameworks can be expressed,we provide a way for those frameworks tointeroperate with users of our system.

By describing different frameworks in a singlelogic, we provide a way for those frameworks tointeroperate in a principled way. For example,if the semantics of SPKI certificates and Taoscertificates are clearly specified in our logic,then certificates from both frameworks can beused together in the same proof, as long asthe requester can show they satisfy the server’srequirements.

Interoperability has another advantage: itfacilitates the deployment of new frameworks.If frameworks can interoperate, then a newframework does not need near-universal de-ployment in order to attract users. A newframework can be used by a few people atfirst, while those people exploit interoperationto work with the rest of the world.

7.1 SPKI

As an example, we now describe how to encodethe SPKI [4] framework. Certificates are themain data structure in SPKI; a certificate canencode a name-to-key binding or a name-to-privileges binding.

The SPKI specification describes how everycertificate can be translated into a 5-tuple data

9

structure, and it gives rules for combining 5-tuples to deduce new 5-tuples, and for decidingwhether a particular 5-tuple is sufficient evi-dence to allow access to a resource. In the 5-tuple (I, S,D, T, V )

I is the key that issued the certificate;

S is the subject of the certificate, which couldbe a key, a name, or a group;

D is a delegation flag, saying whether therights associated with the certificate maybe delegated;

T is a tag, a data structure that describes arequest or set of requests; and

V says when the certificate is valid, giving anot-valid-before and a not-valid-after time.

Space does not permit a full description of SPKIsemantics; see the SPKI documents [4] for fulldetails.

Encoding SPKI To encode SPKI, we encodethe 5-tuple data structure and the rules formanipulating 5-tuples. Since converting certifi-cates to 5-tuples is a straightforward (thoughtedious) translation process, we could also en-code this conversion in our logic.

In practice, one would want to model theSPKI data structures in great detail, for ex-ample, by expressing the tag-matching rules inlogic. We simplify the model here for brevity.

We give the following definition:

tuple(I, S,D, T, V ) ≡ V →I says (∀x.((S saysoptD ok(x))→

T (x)→ ok(x))).

Here I is the issuing principal; S is the subjectprincipal, which might be a group; D is thedelegation flag; the tag T is represented as apredicate on strings (a predicate which admitsany string iff that string will successfully matchthe tag); and the validity interval is representedas a simple predicate V . ok(x) represents theassertion the the operation specified by x should

be permitted; we encode it as the placeholderok(x) ≡ (N (ok)|N (x)) says false.

Now we can prove SPKI’s rules for manip-ulating 5-tuples as lemmas. To give a simpleexample, we can prove

prin(I) prin(J)tuple(I, J, true, A, V ) tuple(J, S,D,A, V )

tuple(I, S,D,A, V )

We could also go about proving the other rulesfor reasoning about 5-tuples, including a rulefor extracting a useful result from a SPKI chain:

J signed ok(X) prin(I) V T (X)tuple(I,N (J),D, T, V )

ok(X)

Having done this, we could conclude thatany client who could have gotten approval foroperation X on server I in SPKI will be ableto prove I says ok(X). SPKI provides a way todefine local access policies such as

ok(tag (pkpfs /foo read))→ read /foo

Although we have not yet done so, we believethat other distributed authentication frame-works could be encoded in a similar way.

8 Implementation

Proofs must be produced by the client request-ing services and checked by the server, so theremust be a machine-readable and -checkablenotation for theorem and proof. We use ahigher-order logic implemented in Twelf [13],an implementation of the Edinburgh LogicalFramework [5]. Research in proof-carrying code[11] has shown that the Logical Framework(LF) is an excellent notation for explicit proofsthat are to be transmitted and then checkedwith a minimal trusted computing base. Thealgorithm for checking LF proofs is as simpleas programming-language type checking, and infact the Touchstone system for proof-carryingcode [11] includes a simple proof-checker writ-ten in the C programming language.

An earlier version of our system was im-plemented in λProlog instead of Twelf, using

10

controls_e: pf (controls @ A @ F) -> pf (A @ F) -> pf F.keybind_e: pf (keybind @ K @ W) -> pf (digital_signature S K F) -> pf (W @ F).trusted_ca_e: pf (trusted_ca @ Ca) -> pf (controls @ Ca @ (keybind @ K @ A)).

abc: pf (trusted_ca @ Charlie) ->pf (keybind @ Kc @ Charlie) ->pf (controls @ Alice @ ReadFoo) ->pf (digital_signature B10010111 Ka ReadFoo) ->pf (digital_signature B01001110 Kc (keybind @ Ka @ Alice)) ->

pf ReadFoo =

[A1][A2][A3][S1][S2]controls_e A3 (keybind_e (controls_e (trusted_ca_e A1) (keybind_e A2 S2)) S1).

Figure 4: Twelf representation of “read foo” theorem and its proof.

higher-order logic with lemmas and definitionsas described by Appel and Felty [2].

8.1 Proof representation

Figure 4 shows the Twelf code that implementsthe theorem that Alice proves to Bob in theexample of Section 2.1. The first three clausesare the statements of the supporting lemmas;here we have omitted their proofs.

The name of the theorem, abc, is followed bya statement of the theorem: given proofs of thefive premises, we get a proof of ReadFoo.

After the = sign comes the proof of the the-orem. The variables [A1][A2][A3][S1][S2]stand for the five premises; the square bracketsindicate that they are formal parameters ofthe proof, and the body of the proof mayrefer to them by name. We have chosen thename A1,A2,A3 for the first three premises tocorrespond to the names used in Section 2.1.The variables S1,S2 stand for the two digital-signature premises.

The last line shows the proof tree, written outin Twelf notation. It is the same tree shown inFigure 2, but in a form more suited to machineprocessing.

Another illustration is the controls e lemma(Figure 5). The first line declares the typeof the name controls, as a predicate, i.e.a function taking a worldview and a formulaand returning a formula. Next, it defines the

name controls to stand for the (higher-order)formula λaλf. (a f) → f . We have madefunctions (λ) explicit in our logic using thelam operator, and function-application explicitusing the @ operator.

The controls_e lemma states that, given aproof that A controls F , and a proof that A saysF , we can construct a proof of F . The prooffirst uses another lemma, def2_e, to expandthe definition of controls in the premise P1;then the implication-elimination rule imp_e tocomplete the proof.

The Twelf notation will allow the recipientof a proof (and associated lemmas) to checkthe validity of each lemma, and then to usethe lemma in checking the proof of the maintheorem (and of other lemmas).

8.2 Measurements

The implementation of our logic in Twelf isquite concise. Such a checker could be used asthe core of a distributed authentication system.The logical inference rules are specified in 46lines, excluding rules for arithmetic, which canbe specified in another dozen or so.

The Twelf proof-checker itself [13] is im-plemented in Standard ML [8]: the parser is2549 lines of commented code, and the proof-checking algorithm is 1540 lines. The parserneed not be considered part of the trustedcomputing base, since a broken parser cannot

11

controls: tm (worldview arrow form arrow form) = lam[A] lam[F] (A @ F) imp F.

controls_e: pf (controls @ A @ F) -> pf (A @ F) -> pf F = [P1][P2] imp_e (def2_e P1) P2.

Figure 5: Representation of controls and controls e.

cause an invalid proof to be accepted by thechecker. Necula [11] has also implemented anLF proof-checker; its current size is about 2000lines of commented C code [7].

Clients who want to generate proofs willneed application-specific definitions and lem-mas, which might amount to several hundredlines of Twelf, but this will be outside thetrusted computing base – the lemmas can be in-dependently checked by the recipients of proofs.

Proofs are really just s-expressions extendedwith a primitive notion of binding; that is, treeswhose operators are names of inference rulesand lemmas. Each use of a lemma with narguments should add approximately n wordsto the size of the proof, and each statement-and-proof of a lemma should add a number ofwords proportional to the size of the lemma andits proof. A good approximation to the size,in words, of the representation of a proof isthe number of non-punctuation tokens in thefully explicit form of its Twelf syntax. Wecan measure the size of the proof illustrated inFigure 1:

Concept Definition Lemma Proofcontrols 21 29 33keybind 20 39 42trustedCA 32 15 33Main theorem 84 123

Since Bob’s security database contains state-ments of the form trustedCA(Charlie), hepresumably also has copies of the relevent def-initions, lemmas, and proofs. Thus, Alice cansimply send a 84-word theorem and 123-wordproof to justify read foo. But if other lemmasturn out to be helpful in structuring the proof,they can be represented in a very reasonablesize, as the table shows. These numbers aregross overestimates of what can be achievedin practice; Necula [10] has shown methods

of reducing the redundancy in LF proofs andcutting their size by large factors.

Some servers – such as programmable diskcontrollers or active-network routers – are sospecialized that they will not even want to havea full proof checker. In this case, they canrely on certificates. Suppose Doris the diskcontroller trusts Bob to check proofs for her;she can rely on the single inference rule

Kb signed (Doris says F )F

trust bob

Now if Alice wants service format diskfrom Doris, she can submit a proof of(Doris says format disk) to Bob, who will checkit and issue the certificate.

Bob should not sign time-dependent state-ments such as now(bob.com) = 1998 which canbecome false. He can avoid this by not puttingany such assumptions into his database whilechecking proofs of statements that he is beingasked to sign.

9 Conclusion

Higher-order logic allows application-specificmodal logics to be defined and proved in asimple and general framework. The apparentdisadvantage of such a logic — undecidability— can be overcome by submitting a proofwith each authentication request, in the sameway that proof-carrying code submits proofs ofsafety with programs.

We have demonstrated that proofs can besmall, that proof checking is simple to imple-ment, and that existing authentication frame-works can be expressed as application-specificdefinitions and lemmas in our logic. Althoughproof generation is undecidable in general, wehave shown by example that in cases of interest,

12

the requester will have a good idea why sheshould be able to access a resource.

References

[1] Martin Abadi, Michael Burrows, Butler Lamp-son, and Gordon D. Plotkin. A Calculus forAccess Control in Distributed Systems. ACMTransactions on Programming Languages andSystems, 15(4):706–734, September 1993.

[2] Andrew W. Appel and Amy Felty. LightweightLemmas in Lambda Prolog. In 16th Interna-tional Conference on Logic Programming. MITPress, November 1999.

[3] Matt Blaze, Joan Feigenbaum, and Jack Lacy.Distributed Trust Management. In Proc. of17th IEEE Symposium on Security and Pri-vacy, pages 164–173, May 1996.

[4] Carl M. Ellison, Bill Frantz, Butler Lampson,Ron Rivest, Brian M. Thomas, and Tatu Ylo-nen. Simple Public Key Certificate. Inter-net Draft draft-ietf-spki-cert-structure-05.txt,1998.

[5] Robert Harper, Furio Honsell, and GordonPlotkin. A Framework for Defining Logics.Journal of the ACM, January 1993. To appear.A preliminary version appeared in Symposiumon Logic in Computer Science, pages 194–204,June 1987.

[6] Butler Lampson, Martin Abadi, Michael Bur-rows, and Edward Wobber. Authenticationin Distributed Systems: Theory and Prac-tice. ACM Transactions on Computer Systems,10(4):265–310, November 1992.

[7] Peter Lee. personal communication, 1999.

[8] Robin Milner, Mads Tofte, Robert Harper, andDavid MacQueen. The Definition of StandardML (Revised). MIT Press, Cambridge, MA,1997.

[9] George C. Necula. Proof-Carrying Code.In Procedings of the 24th Annual ACMSIGPLAN-SIGACT Symposium on Principlesof Programming Languages (POPL ’97), pages106–119, January 1997.

[10] George C. Necula and Peter Lee. EfficientRepresentation and Validation of Proofs. InIn Proceedings of the 13th Annual Symposiumon Logic in Computer Science, 1998.

[11] George Ciprian Necula. Compiling with Proofs.PhD thesis, School of Computer Science,Carnegie Mellon University, Pittsburgh, PA,September 1998.

[12] B. Clifford Neuman and Theodore Ts’o. Ker-beros: An Authentication Service for Com-puter Networks. IEEE Communications,32(9):33–38, September 1994.

[13] Frank Pfenning and Carsten Schurmann. Sys-tem Description: Twelf — A Meta-LogicalFramework for Deductive Systems. In The16th International Conference on AutomatedDeduction. Springer-Verlag, July 1999.

[14] Ron Rivest and Butler Lampson. SDSI –A Simple Distributed Security Infrastructure.September 1996.

[15] International Telecommunications Union. ITU-T Recommendation X.509: The Directory:Authentication Framework. Technical ReportX.509, ITU, www.itu.int, 1997.

13