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.
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?
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.
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.
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
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
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
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)
Top Related