1

Security

Andy Gordon, Microsoft Research

SFM-01:PA, Bertinoro, July 2001

2

Goals of the Course

Describe some problems of computer security that are amenable to formal analysis

Part I: Cryptographic security protocols

Part II: Language-based access control

Explain some process algebraic techniques

Structural operational semantics

Equational reasoning

Type-checking

3

Perspective

Formalism much less than half the battle; many, many process issues

Certainty out of reach; need cost effective tools to improve reliability

Still, many interesting language-related security issues within reach of formal analysis

Quest for situations where without too much human effort we can find critical bugs

4

Acknowledgements

I’ve drawn the material in this course from several books and articles

I’ve attempted to credit all the authors whose work is directly reported

Still, the context of all these works is a thriving research community

In these lectures there is sadly no time to cover all the indirect influences or all the related work

5

Part I: Security Protocols

In this part:Spi calculus = -calculus plus crypto

Programming crypto protocols in spi

Two styles of specification and verificationBy equations and bisimulation

By correspondence assertions and typing

6

What’s the problem?

Imagine if cheques had to be signed and dated, but had no serial numbers Could photocopy and cash twice

This is how crypto protocols go wrongMissing serial numbers, identities, etc.

7

Basic Ideas of Spi

Expressing cryptography in a sibling of the -calculus

Joint work with M. Abadi

8

Beginnings

Crypto protocols are communication protocols that use crypto to achieve security goals

The basic crypto algorithms (e.g., DES, RSA) may be vulnerable, e.g., if keys too short

But even assuming perfect building blocks, crypto protocols are notoriously error proneBugs turn up decades after invention

Plausible application of the -calculus:Encode protocols as processesAnalyse processes to find bugs, prove properties

9

Spi = + Cryptography

The names of the -calculus abstractly represent the random numbers of crypto protocols (keys, nonces, …)

Restriction models key or nonce generation

We can express some forms of encryption using processes in the -calculus

We tried various encodings

Instead, spi includes primitives for cryptography

10

Syntax of Spi Terms

Since the -calculus can express pairing, only symmetric-key ciphers are new

We can include other crypto operations such as hashing or public-key ciphers

M, N ::= termsx name, variable(M,N) pair{M}N ciphertext

11

Syntax of Spi Processes

P,Q,R ::= processesout M N output N on

Minp M(x);P input x off Mnew(x);P new nameP | Q compositionrepeat P replicationstop inactivitysplit M is (x,y);P pair splittingdecrypt M is {x}N;P

decryption

check M is N; P name equality

12

Operational Semantics

The process decrypt M is {x}N;P means:

“if M is {x}N for some x, run P”

Decryption evolves according to the rule:

decrypt {M}N is {x}N;P P{xM}

Decryption requires having the key N

Decryption with the wrong key gets stuck

There is no other way to decrypt

13

Equations and Spi

Specifying and verifying crypto protocols using equations

Joint work with M. Abadi

14

Ex: A Simple Exchange

The process sys represents a protocol where: A sends msg to B encrypted under k, over the public channel net Then B outputs the decryption of its input on another channel dThe protocol will get stuck (safely) if anyone captures or replaces

A’s message

sys(msg,d) new(k); (out net({msg}k) |

(inp net(u); decrypt u is {m}k; out d(m);))

A

B

15

Specifying Security Properties

We are only interested in safety properties.

We use equations for simplicity.

For authenticity, we build a necessarily correct, “magical” implementation:

Secrecy. For all msgL, msgR, new(d);sys(msgL,d) new(d);sys(msgR,d)

Authenticity. For all msg, sys(msg,d) sys’(msg,d)

Sys’(msg,d) new(k); (out net({msg}k) |

(inp net(u); decrypt u is {m}k; out d(msg);))

16

Formality in Context…

Like other formalisms, spi abstracts protocols:

e.g., ignoring key and message lengths

So an implementation may not enjoy all the security properties provable at the spi level.

Similarly, for flaws found at the spi level

In security applications, as in others, formal methods need to be joined with engineering rules-of-thumb and commonsense!

17

Defining Equivalence

Two processes are equivalent if no environment (opponent) can distinguish them.

Technically, we use a testing equivalence PQ (R. Morris; R. de Nicola and M. Hennessy).

A test is a process O plus a channel c.

A process passes a test (O,c) iff P|O may eventually communicate on c.

Two processes are equivalent iff they pass the same tests.

18

Testing Equivalence

Allows equational reasoning Is implied by other equivalences

Bisimulation focuses on the process in isolationWe often prove testing equivalence via

bisimulation Reveals curious properties of spi, such as

the “perfect encryption equation”new(k); out c {M}k new(k); out c {M’}k

The outcome of a test cannot depend on data encrypted under an unknown key

19

The Opponent

Our use of testing equivalence implicitly defines the opponent as an arbitrary spi program:

it can try to create confusion through concurrent sessions,

it can initiate sessions, it can replay messages, it can make up random numbers, but it cannot get too lucky, because of

scoping.Most approaches have more limited models.

20

Ex: Multiple Exchanges

Purpose: send multiset of messages from A to B:

The process sys represents a protocol where: There are n senders send, a replicated receiver recv capable of receiving

arbitrarily many messages, and both the senders and receivers share key k.

sys(msg1,…,msgn,d) new(k); (send(msg1,k) | … | send(msgn,k) | repeat recv(k,d))

AB

21

Secrecy Specified in Spi

Secrecy.For all (msgL1, msgR1), …, (msgLn, msgRn), new(d);sys(msgL1,…,msgLn,d) new(d);sys(msgR1,…,msgRn,d) No observer (opponent) should be able to

distinguish runs carrying different messages.

22

Authenticity Specified in Spi

Authenticity.For all p1, …, pn, there is Q such that fn(Q) {p1,…,pn,net} and for all names msg1, …, msgn: sys(msg1,…,msgn,d) new(p1,…,pn); (Q | inp p1(x).out d(msg1) |… | inp pn(x).out d(msgn))By construction, the right-hand process:

Only ever delivers the names msg1, …, msgn on d. Delivers msg no more times than it occurs in the

multiset msg1, …, msgn.

By the equation, the same holds of sys(msg1,…,msgn,d).

23

An Insecure Implementation

send(msg,k) out net({msg}k);recv(k,d) inp net(u); decrypt u is {msg}k; out d(msg)Satisfies neither secrecy nor authenticity.

Can you see why?

24

A Secure Implementation

send(msg,k) inp net(u); new(ca); out net ({ca,u,msg}k);

recv(k,d) new(nb); out net(nb); inp net(u); decrypt u is {ca,nb’,msg}k; check nb’ is nb; out d(msg)

ca is a confounder, nb a nonce: random numbers;

ca is needed for secrecy, nb for authenticity

Message 1 b a: nb

Message 2 a b: {ca,nb,msg}kab

25

Ex: Wide Mouth Frog

The new channel is a fresh session key.

To prevent replays, we use nonce challenges.

A

S

B

Msg 1: new channel

Msg 2: new channel

Msg 3: data on new channel

26

A Crypto Implementation

Goal: authenticate a and kab to b

Message 1

a s: a

Message 2

s a: ns

Message 3

a s: a, {a,a,b,kab,ns}kas

Message 4

s b: *

Message 5

b s: nb

Message 6

s b: {a,s,b,kab,nb}ksb

Message 7

a b: a, {msg}kab

27

WMF Expressed in Spi

We consider n clients plus a server and m instances (sender, receiver, message):

I1=(a1,b1,msg1), …, Im=(am,bm,msgm)

sys(I1,…, In,d) new(k1S); … new(knS); new(kS1); … new(kSn); (send(I1) | … | send(In) | repeat server | repeat recv(1,d) | … | repeat recv(n,d))Allows opponent to interact with and

initiate arbitrarily many concurrent sessions.

28

WMF Specified in Spi

Secrecy.If aLkaRk and bLkbRk for all k1..m then new(d);sys(IL1,…, ILn,d) new(d); sys(IR1,…, IRn,d)Authenticity. sys(I1,…, In,d) sys’(I1,…, In,d)where sys’(I1,…, In,d) is a suitable “magical” specification, as before

Proved via a bisimulation relation defined by a rather complex and ad hoc invariant.

29

Lessons so far…

The spi calculus is rather abstract

Can ignore details, especially details of encryption

The spi calculus is rather accurate

Can describe exact conditions for sending messages

More precise than informal notations and some formal notations, e.g., the BAN logic

Implicit opponent falls out of testing equivalence

Direct proofs of equational specs can be very time consuming, though, can we do better?

30

Break I

31

Types for Spi

Typing authenticity properties

Joint work with A. Jeffrey

32

Origins of Type Theory

Cambridge 1901: Russell uncovers a paradox in Frege’s system of arithmetic

Later, 1908, he proposes his Theory of Types to patch the bug

Your system admits S{x |

xx}.But is SS?

Whoops!

33

A New Protocol Analysis

First, code up the protocol in spi.

Second, specify protocol guarantees via Woo and Lam’s correspondence assertions.

Third, figure out types for the keys, nonces, and data of the protocol.

Fourth, check that the program (including the assertions) is well-typed.

A type soundness theorem implies that the protocol guarantees are satisfied.

34

Step One

Code up the protocol as a spi calculus program

Exactly as before…

35

Ex: Multiple Exchanges

Purpose: send multiset of messages from A to B:

The process sys represents a protocol where: There are n senders send, a replicated receiver recv capable of receiving

arbitrarily many messages, and both the senders and receivers share key k.

sys(msg1,…,msgn,d) new(k); (send(msg1,k) | … | send(msgn,k) | repeat recv(k,d))

AB

36

Step Two

Specify protocol guarantees via Woo and Lam’s correspondence assertions

To do so, we enrich spi with begin L and end L assertions

37

Correspondence Assertions

To specify authenticity properties, Woo and Lam propose correspondence assertions

Let e b mean that the count of e events never exceeds the count of b events

Ex: “cash cheque” “wrote cheque”

Ex: “B accepts message m” “A sent m”

These assertions are simple safety properties

Rule out replays, confused identities, etc.

38

Correspondences in Spi

Programmers may write begin L and end L annotations in our spi calculus

These annotations implicitly define correspondence assertions of the form:end L begin Lthat is, every end L is “paid for” by a distinct,

preceding begin Lno requirement that the begin and end events be

properly bracketed

The programmer may think of these assertions as verified at runtime (like assert in C)

39

Safety and Robust Safety

The point of writing correspondence assertions is to catch programs that are not safe:

A process P is safe iff in every execution trace, there is a distinct begin L for every end L.

Moreover, we want programs to be safe in the presence of any hostile opponent, modelled by an arbitrary spi program:

A process P is robustly safe iff for all begin-and end-free opponents O, P|O is safe.

40

Annotating the Example

We specify authenticity by annotating the multiset example with begin and end events that ought to be in correspondence:

“Sender sent msg” (msg)send(msg,k) begin“Sender sent msg”; out net ({msg}k);recv(k,d) inp net(u); decrypt u is {msg}k; end“Sender sent msg”; out d(msg)

41

A Specification of Authenticity

Because of the possibility of replays, the insecure implementation fails this spec.

We can annotate the secure implementation similarly.

No consensus on formulations of authenticity.

Still, correspondences are simple and precise.

See Focardi, Gorrieri & Martinelli for comparison

Authenticity.The process sys(msg1,…,msgn,d) is robustly safe.

42

Interlude

A type system for crypto primitives

Abadi’s “Secrecy by Typing in Security Protocols” is one inspiration

43

Typing Assertions in Spi?

First, we introduce a typed spi calculus, whose rules can type I/O, data structures, and encryption.

Second, we extend with effects for tracking end-events.

A novel type for nonces transfers effects between senders and receivers.

In the end, the payoff is a guarantee of robust safety by typing.

And nobody knows my code doesn’t type-check, woof

woof!

45

The Untrusted Type Un

Terms of type Un represent untrusted channels and data structures read off the network

Rules include: if M:Un and N:Un then both (M,N):Un and {M}N:Un

For any untyped process O with free names x1, …, xn there is a typed process O’ such that:

x1:Un, …, xn:Un O’ and Oerase(O’)

So (due to Un) typed opponents (such as O’) are as dangerous as untyped opponents.

46

Keys, Pairs

Terms of type Key T are names used as symmetric keys for encrypting type T

If M:T and N:Key T then {M}N:Un.

If M:Un and N:Key T and x:T P well-typed, then so is decrypt M as {x:T}N;P

Terms of type (x:T, U{x}) are dependent records of type T and type U{x}.

47

What Do We Have So Far?

We’ve enough to confer types on all the data in the multiple message protocol.

Typing avoids:arity errors (MyKey only encrypts pairs)key disclosure (cannot transmit MyKey on net)confusing keys with other types, e.g., pairs

Net UnMsg UnMyNonce UnMyKey Key (Msg, MyNonce)

48

But Can We Check Assertions?

Let the judgment

E P : [L1,…,Ln]

mean the multiset [L1,…,Ln] is a bound on the events that P may end but not begin.

If L:T then end L : [L]

If L:T and P:e then begin L;P : e[L]

Metaphor: end’s and begin’s like costs and benefits that must be balanced.

49

Typing a Nonce Handshake

1. Receiver publishes new N:Un

2. Sender receives N:Un, asserts begin L, casts nonce into Nonce[L], returns within encrypted message

3. Receiver decrypts message, checks just once for presence of N:Nonce[L], then asserts end L

Effect in the Nonce[L] type allows transfer:

Each cast is a cost

Each check is a benefit (justified by previous cast)

50

Semantics of cast

The process cast x to (y:Nonce e);P evolves into the process P{yx}

Only way to make name of type Nonce e

The name is a proof events in e have happened

It “costs” the effect e:

If E x : Un and E, y:Nonce e P : e’ then E cast x to (y:Nonce e);P : ee’

Only kind of cast in the system

51

Semantics of check

Process check x is y;P evolves into process P if xy; but otherwise gets stuck.

It “pays for” the effect e in P:

If E x : Nonce e and E y : Un and E P : e’ then E check x is y; P : e’e

For each new(y:Un);P, we require that the name y be used in a check at most once

Enforced by adding a new kind of effect; details omitted

52

Step Three

Figure out types for the keys, nonces, and data of the protocol.

53

Ex: Multiple Messages Again

net : UnMsg UnMyNonce(m) Nonce [“Sender sent m”]MyKey Key (m:Msg, MyNonce(m))

send(msg:Msg,k:MyKey):[] inp net(u:Un); begin “Sender sent msg”; cast u to (no:MyNonce(msg)); out net ({msg,no}k);

54

Ex: Multiple Messages Cont.

(For clarity, we omit confounders.)

recv(k:MyKey,d:Un):[] new(no:Un); out net(no); inp net(u:Un); decrypt u is {msg:Msg,no’:MyNonce(msg)}k; check no’ is no; end “Sender sent msg”; out d(msg);

55

Step Four

Fourth, check that the program (including the assertions) is well-typed.

A type soundness theorem implies the protocol guarantees are satisfied.

56

Robust Safety by Typing

In the multiple messages example, we can check by hand that the following is derivable:

net,msg1,…,msgn,d:Un sys(msg1,…,msgn,d) : []

Hence, authenticity is a corollary of the theorem.

Theorem (Robust Safety)If x1,…,xn:Un P : [] then P is robustly safe.

57

Ex: A slight variant of WMF

Event 1 a begins “a sending b key kab”

Message 1 a s: a

Message 2 s a: ns

Message 3 a s: a, {tag3(b,kab,ns)}kas

Message 4 s b: *

Message 5 b s: nb

Message 6 s b: {tag6(a,kab,nb)}kbs

Event 2 b ends “a sending b key kab”

Message 7 a b: a, {msg}kab

58

Typing the WMF

p1, …, pn,s: Prin Un --n principals, one server

SKey Key T --session keys, for some payload T

kpis: PrincipalKey(pi) --longterm key for each principal

PrincipalKey(p) Key(Cipher3(p) Cipher6(p))

Cipher3(a) (b:Prin, kab:SKey, ns:Nonce[“a sending b key kab”])

Cipher6(b) (a:Prin, kab:SKey, ns:Nonce[“a sending b key kab”])

Slightly simplified compared to original.

Given these types, the system has empty effect (and names known to opponent have type Un). Hence, authenticity follows just by typing.

59

A Rule-of-Thumb

Our type system shows promise as a formalisation of at least some of this principle.

The Explicitness Principle: Robust security is about explicitness. A cryptographic protocol should make any necessary naming, typing and freshness information explicit in its messages; designers must also be explicit about their starting assumptions and goals, as well as any algorithm properties which could be used in an attack.(from Anderson and Needham, Programming Satan’s Computer, in LNCS 1000, 1995.)

60

Implementation

Checked a standard suite of symmetric key protocols

Re-discovered known bugs, found redundancies

See MSR-TR-2001-49, http://cryptyc.cs.depaul.edu

61

Related Protocol Analyses

Little human effort

Auto attack discovery

Intuitive explanation of passes

Precise semantics

Unbounded principal size

BAN Belief logic

FDR Model checker

Isabelle

Interactive thm prover

Athena

Automatic thm prover

Cryptyc

Type checker

Beware: some columns rather subjective Lots of work omitted; see technical report

62

Related Work on Spi

Improved techniques for equational reasoning (Abadi and Gordon; Boreale, De Nicola, and Pugliesi; Abadi and Fournet)

Reachability analysis (Amadio; Abadi and Fiore)

Authentication schema (Focardi, Gorrieri, and Martinelli)

Type systems (Abadi and Blanchet; Gordon and Jeffrey)

Flow analyses (Bodei, Degano, Nielson, and Nielson)

63

Summary of Part I

The spi calculus allows programming and specification of crypto protocols

We borrow many ideas from the -calculusWe specify both secrecy and authenticity Testing equivalence crisply specifies secrecy Woo and Lam’s correspondence assertions

are good for authenticityType-checking spi programs is a cost effective

method for checking some authenticity properties

64

Break II

65

Part IIA theory and critique of stack inspection

Joint work with C. Fournet

66

Part II: Stack Inspection

In this part:Access control in a multi-component

runtime

Some subtleties and risks

An abstract -calculus model

An equational theory of stack inspectionSoundness and completeness theoremsProof technique: applicative bisimilarity

Application to program transformations

67

Highlights of Stack Inspection

A software-based access control mechanism Deployed in Sun’s JVM and Microsoft’s CLR,

type-safe platforms supporting distributed computing with mobile code

Supports multiple components with diverse origins and levels of trust, in same process

Used in browsers, servers, smartcards, cellphones

Allows flexible object-oriented interface to platform, rather than strict sandboxing

68

An Outline of Stack Inspection

In terms of a variant of Pottier, Skalka, and Smith’s sec-calculus

69

Principals and Permissions

We adapt Pottier, Skalka, and Smith’s sec-calculus

Access policy stated using permissions

Based on policy and evidence of origin, each component assigned access rights, a permission set

We abstract from the details, and refer to the access rights as the principal owning the component

System {screenIO,fileIO} --more trustedApplet {screenIO} --less trusted

70

Framing

During compilation and loading, but prior to execution, each method or function is framed with component owner

New syntax R[e] is e framed with principal R; in implementation terms, a tagged stack frame

Function Re frames all ’s in e with R

Rx xRx.e x.R[ Re ] --attach frame only to Re f Re RfR… …

71

Top-Level Configuration

Some mechanism (e.g., types, scopes) prevents Applet-code accessing I/O devices directly…

…but there may be arbitrary interactions (calls and returns) between trusted and untrusted code

Trusted System-code decides access by inspecting the stack to determine its callers

Our model of the initial top-level configuration:

eloader (Systemesystem) (Appleteapplet)

72

Ex: Direct Access

Consider a library function in scope to both trusted and untrusted code

A basic check is on the immediate caller

readFile x. System[ check fileIO for --check caller has fileIO primRF x] --direct access to I/O

Applet[readFile “secrets” ] failSystem[readFile “version” ] “Build 2505”

73

Ex: Indirect Access

In fact, the basic stack inspection algorithm is to check all callers have permission

displayString s. System[ check screenIO for --check callers primDS x] --display string, return *

Applet[displayString “hiya” ] *Applet[displayFile “secrets” ] failSystem[displayFile “version” ] *

displayFile x. System[displayString(readFile x)]

74

Ex: Overriding Policy

The final ingredient of stack inspection is the ability of trusted code to override inspection of its callers

readVersion *. System[ grant {fileIO} in --caller need not have fileIO readFile “version” ]Applet[readVersion *] “Build 2505”

A grant allows authors of trusted code to assert responsibility for overriding policy in certain situations

75

Ex: Untrusted Results

Even without grant, trusted code may unwittingly depend on untrusted data

foolishDisplayFile h. System[ displayString(readFile (h *))]

foolishDisplayFile (*. Applet[“secrets”]) *

Stack inspection prevents h from making privileged calls while running, but doesn’t stop it influencing computation once it returns

76

Syntax of the sec-calculus

e, f :: expressionx variablex.e functione f applicationR[e] framed expressiongrant R in e grant permissionstest R then e else f test permissionsfail failure

p,q Perm permissionR,S,D Perm principal

check p for e test {p} then e else fail

77

Semantics of the sec-calculus

(Eval Outcome)

o SD o

(Eval Appl)

e1 SD x.e3 e2 SD v2 e3 {xv2} SD o

e1 e2 SD o

e SD o security-indexed evaluation

e o e PermPerm o top-level evaluation

u,v :: x.e valueo :: v | fail outcome

S static context, DS

dynamic context

(Eval Frame)

e RDR o

R[e] SD o

(Eval Grant)

e SD(RS) o

grant R in e SD o

(Eval Test)

eRD SD o

test R then etrue else efalse SD o

(Eval Rator Fail)

e1 SD fail

e1 e2 SD fail

(Eval Rand Fail)

e1 SD v e2 SD fail

e1 e2 SD fail

Equivalent to, but more abstract than, P,S&T semantics

79

Equational Impact of Stack Inspection

Its effect on transformations such as inlining and tail-calls

80

Contextual Equivalence

Two programs equivalent if they cannot be distinguished by any larger enclosing program

Generic definition that justifies code optimisations

bubbleSort quickSort

Introduced by J. Morris in the 1960s

A form of testing equivalence

Let e iff there is o such that e o.Let ef iff for every context C(-), C(e) C(f).

81

Ex: Impact of Stack Inspection

Stack inspection changes equivalence, even for pure -expressions

We have ef in the call-by-value -calculus, but not in sec

Hence, usual optimisations may break, motivating our study of equivalence

e xy.let zx y in *.zf xy.let zx y in *.x y

C(-) [(-) (y. test Perm then else y) (x.x)]

82

An Equational Theory

We inductively define a relation ef

Reflexive, symmetric, transitive

Preserved by all contexts

Includes standard call-by-value equations

Plus security specific equations

(x.e)v e{xv}x.v x v if x not free in v

83

Ex: Equations for Frames

In R1[R2[e]] the effect of a grant in e determined by R2 not R1

So R1[R2[e]] (R1R2)[e] not sound in general

Have System[Applet[e]] Applet[e]

But not Applet[System[e]] System[e]

R1[R2[R3[e]]] (R1R2)[R3[e]]R1[R2[e]] R2[e] if R1R2

84

Ex: Equations for Tests

Failure of a test determined by immediate frame

But the converse does not hold:

R1R2 doesn’t imply R1[test R2 then e1 else e2] R1[e1]

Instead, we need a grant to determine success

(R1R2) R1[test R2 then e1 else e2] R1[e2]

R1R2 R3 R1[grant R2 in test R3 then e1 else e2] R1[grant R2 in e1]

85

Soundness and Completeness

Theorem (Soundness)If ef then ef.

Theorem (Completeness wrt Evaluation)Let SCD(-) D[grant D in S[-]].If e SD o then SCD(e)o.

Using bisimulation techniques, we show derivable equations are true contextual equivalences:

The equational theory is as expressive as security-indexed evaluation:

86

App: Shortening Stack Inspection

The following is a recommended idiom for programs making frequent tests

It’s justified by combining the primitives

e test R then (grant R in e) else e

test R then e else e etest R then e1 else e2 test R then (grant R in e1) else e2

87

App: Tail-Calls

A tail-call is the final act of a function, to re-use its stack frame to invoke another function

Important for recursive programming

Formally, amounts to deleting an outer stack frame, so may be a security risk:

Instances like this must be avoided, but many important instances are safe

e.g., tail-calls within the same module

Applet[System[displayString(readFile “secrets”)]] failSystem[displayString(readFile “secrets”)] *

88

An Alternative Equivalence

The motivation is that we can easily show ef implies ef by constructing suitable bisimulations

Applicative bisimilarity introduced by Abramsky

A relation B is an applicative bisimulation iff eBf implies that for all S and D with D S, (1) if e SD fail then f SD fail (2) if e SD x.e’ then f SD x.f’ and for all v , e’{xv} B f’ {xv} and vice versa.

Applicative bisimilarity ef is the union of all applicative bisimulations (the greatest, in fact).

89

The Two are One

We show bisimilarity is preserved by all contexts by Howe’s method

We define a candidate congruence that clearly includes bisimilarity

We prove that it is a bisimulation, and hence equals bisimilarity

Hence, ef implies ef Moreover, ef implies ef

By showing contextual equivalence is a bisimulation

90

Limitations of Stack Inspection

Some factors to beware of

91

Limitations of Stack Inspection

Often marketed as a feature that:

Offers flexible and precise security guarantees to writers of critical code

Can safely be ignored by everyone else

Broadly true, but beware:

Hard to state high-level assurances offered by this enforcement mechanism---not a flow analysis

Program transformations impacted, e.g., JIT may refuse to implement cross-module tail-calls

92

Related Work

Originally designed during the Browser Wars: Netscape, IE, HotJava

Wallach, Appel, and Felten:

Security-passing implementation, logical semantics

Besson, Jensen, Le Métayer, and Thorn:

Model-checking program-dependent properties

Pottier, Skalka, and Smith:

Types and effects to avoid runtime checks

93

Summary of Part II

A theory: A new security-indexed SOS semantics A new equational theory

A critique: Semantics of any program may be affected High-level guarantees a little mysterious

Future: Is there an efficient, better alternative? Better analyses for libraries using stack

inspection?

94

Overall…

Showed specific applications of process algebraic techniques to security issues

This is an exciting time…loads of security problems amenable to formal analyses

In this area, there is a premium on finding attacks, but proving limited guarantees has great value too

Don’t forget practical perspectiveSchneier Secrets and Lies (2000)Anderson Security Engineering (2001)

95

End of course