Provable Implementations of
Security Protocols
Andrew D. Gordon
Based on joint work with Karthikeyan
Bhargavan, Cédric Fournet, and Stephen Tse
Microsoft Research
2
The Needham
-
Schroeder Problem
In
Using encryption for authentication in large networks
of computers (CACM 1978)
, Needham and Schroeder didn’t
just initiate a field that led to widely deployed protocols like
Kerberos, SSL, SSH, IPSec, etc.
They threw down a gauntlet.
“Protocols such as those developed here are
prone to extremely subtle errors that are
unlikely to be detected in normal operation.
The need for techniques to verify the
correctness of such protocols is great, and we
encourage those interested in such problems
to consider this area.”
3
Informal Methods
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.
Anderson and Needham
Programming Satan’s Computer
1995
Informal lists of prudent practices enumerate common patterns in
the extensive record of flawed protocols, and formulate positive
advice for avoiding each pattern.
(eg Abadi and Needham 1994, Anderson and Needham 1995)
For instance, Lowe’s famous fix of the Needham
-
Schroeder PK
protocol makes explicit that message 6,
{|NA,
B
,NB|}KA,
is sent by
B, who is not mentioned in the original version of the message.
4
Formal Methods
Dolev&Yao first formalize N&S problem in early 80s
Public key decryption: {| {| M |}
KA
|}
KA
-
1 = M
Their work now widely recognised, but at the time, few
proof techniques, and little applied
In 1987, Burrows, Abadi and Needham (BAN) propose a
systematic rule
-
based logic for reasoning about protocols
If P believes that he shares a key K with Q, and sees the
message M encrypted under K, then he will believe that Q
once said M
If P believes that the message M is fresh, and also believes
that Q once said M, then he will believe that Q believes M
Incomplete, but useful; hugely influential
5
A Potted History: 1978
-
2005
A
B
M
Hi Bob,
love Alice
Hate you,
Bob!
-
Alice
We assume that an intruder can interpose
a computer on all communication paths,
and thus can alter or copy parts of
messages, replay messages, or emit false
material. While this may seem an extreme
view, it is the only safe one when designing
authentication protocols.
Needham and Schroeder CACM (1978)
1978: N&S propose authentication protocols for “large networks of computers”
1981: Denning and Sacco find attack found on N&S symmetric key protocol
1983: Dolev and Yao first formalize secrecy properties wrt N&S threat model, using formal algebra
1987: Burrows, Abadi, Needham invent authentication logic; incomplete, but useful
1994: Hickman invents first version of SSL; holes in v1, v2, but v3 fixes these, very widely deployed
1994: Ylonen invents SSH; holes in v1, but v2 good, very widely deployed
1995: Abadi, Anderson, Needham, et al propose various informal “robustness principles”
1995: Lowe finds insider attack on N&S asymmetric protocol; rejuvenates interest in FMs
circa 2000: Several FMs for “D&Y problem”: tradeoff between accuracy and approximation
circa 2005: Many FMs now developed; several deliver both accuracy and automation
2005: Cervesato et al find same insider attack as Lowe on proposed public
-
key Kerberos
6
2006: Job Done?
After intense effort on symbolic reasoning, there are
now several techniques for automatically proving
properties of protocols represented within a symbolic,
algebraic model
eg Athena, TAPS, ProVerif, FDR, AVISPA, etc
Moreover, many of the unwarranted Dolev Yao
abstractions (eg that message length is unobservable)
are being addressed by relating symbolic techniques to
the probabilistic computational models used by
cryptographers
See the proceedings of the
Formal and Computational
Cryptography
workshops, for example
7
The trouble is
while practitioners are typically happy for researchers to
write formal models of their natural language
specifications, and to apply design principles and formal
tools, they are reluctant to do so themselves.
Specs are always refined by implementation experience,
so absolute correctness (at least of V1) is not a goal
Timely agreement is more important
So specs tend to be partial and ambiguous.
Implementation code is the closest we get to a formal
description of most protocols.
Hence, we need to learn from other areas of verification,
and build tools to analyze code
8
From Model to Code
Many formalisms for crypto protocols (including those
based on process algebra and process calculi) amount to
small programming languages
Several tools have successfully demonstrated the idea:
Strand spaces: Perrig, Song, Phan (2001), Lukell et al (2003)
CAPSL: Muller and Millen (2001)
Spi calculus: Lashari (2002), Pozza, Sista, Durante (2004)
Apparently, the resulting code does not interoperate with
other implementations
But this amounts to growing a formal model into a full
programming language, building a compiler, educating
developers and so on.
9
From Code to Model
Many code analysis tools can detect security issues,
such as buffer overruns, but tools to extract D&Y
models from code are comparatively new
Bhargavan, Fournet, and Gordon (CCS’04) extracted
verifiable pi
-
calculus models from XML policies
configuring some WS
-
Security protocols
First extraction of D&Y models from implementation files
Goubault
-
Larrecq and Parrennes (VMCAI’05) did first
tool to extract D&Y models from the source code (in C)
of a crypto protocol
Based on a pointer analysis they extract a Horn clause
model suitable for analysis by other tools eg SPASS
They analyse one of two roles in the NSL protocol
10
This Talk: Models from ML
We extract verifiable pi calculus models from
protocol implementations in ML
We express the attacker model and the intended
security properties in terms of ML
We justify the tool by proving that, for any attack at
the ML level, there is an attack on the pi model
We consider reference implementations, but not yet
production code
K. Bhargavan, C. Fournet, A.D. Gordon, and S. Tse.
Verified interoperable implementations of security protocols
. In
19th IEEE
Computer Security Foundations Workshop (CSFW 2006)
, pp139
-
152, Venice, July 5
-
7, 2006. IEEE Computer Society.
With K. Bhargavan, C. Fournet, and A.D. Gordon.
Verified reference implementations of WS
-
Security protocols
. In
3rd
International Workshop on Web Services and Formal Methods (WS
-
FM 2006)
, to appear, Vienna, September 8
-
9, 2006.
11
Application
Authz
One Source, Three Tasks
Concrete
Crypto
Symbolic
Crypto
Crypto
Net
Some other
implementation
Extractor
Platform (CLR)
Interoperability (via TCP)
Symbolic
Verification
Symbolic Testing
& debugging
My code
My
protocol
Other
Libraries
Source code with modules
and strong interfaces
Verifiabl
e Model
12
Application
Authz
1. Symbolic testing and debugging
Symbolic
Crypto
Crypto
Net
Platform (CLR)
My code
My
protocol
Other
Libraries
Attacker
(test)
We can code
any given
potential attack
as a program
We use idealized
“black
-
box”
cryptographic
primitives
We model attackers
as arbitrary code
with access to
selected libraries
13
Application
Authz
2. Formal Verification
Symbolic
Crypto
My code
My
protocol
Other
Libraries
Translation to
pi calculus
Pass: Ok for all attackers, or
No + potential attack trace
Formal verification considers
ALL such attackers
Attacker
(unknown)
We model attackers
as arbitrary code
with access to
selected libraries
We only
support
a subset
of ML
Extractor
Verifiabl
e Model
14
Application
Authz
3. Concrete testing & interop
Concrete
Crypto
Crypto
Net
Some Other
Implementation
Platform (CLR)
Interoperability (via TCP)
My code
My
protocol
Other
Libraries
We test that our code
produces and consumes
the same messages as
another implementation
We can also run attacks
to test other
implementations
Attacker
(test)
We only change our
implementation of
cryptography
15
Source Language: F#
F# is a dialect of ML running on the CLR
developed by Don Syme at MSR Cambridge
An F# subset supports protocol programming, and
model extraction
Simple formal semantics
Modular programming based on typed interfaces
Algebraic data types with pattern matching are
useful for symbolic crypto and XML processing
Still, few protocols are written in ML, so next
version of our tools may target C# or CLR IL
16
Pi Calculus Verifier: ProVerif
ProVerif is an automated cryptographic protocol
verifier developed by Bruno Blanchet (ENS)
What it can prove:
Event correspondence properties (e.g., for authentication)
Process equivalences (e.g., for secrecy)
How it works:
Internal representation based on Horn clauses
Resolution
-
based algorithm, with clever selection rules
Attack reconstruction
Automatic, but source programs have to be tuned for
efficient verification
B. Blanchet. An efficient cryptographic protocol verifier based on Prolog rules. In
14th IEEE Computer Security
Foundations Workshop (CSFW 2001).
IEEE Computer Society, 2001.
B. Blanchet, M. Abadi, and C. Fournet. Automated verification of selected equivalences for security protocols. In
20th IEEE Symposium on Logic in Computer Science (LICS 2005).
IEEE Computer Society, 2005.
17
Password
-
Based Authentication
A simple, one
-
message authentication protocol
Two roles
client (A) sends some text, along with a MAC
server (B) checks authenticity of the text
the MAC is keyed using a nonce and a shared password
the password is protected from offline guessing attacks
by encrypting the nonce with the server’s public key
Threat model: multiple instances of each role; attacker knows
server’s public key
18
Making and Checking Messages
19
Coding Client and Server roles
20
One Source, Three Tasks
Using concrete libraries, our client and server can interact on
top of a TCP socket (and could interoperate with other
implementations)
Using symbolic libraries, we can see through cryptography
Using symbolic libraries, fs2pv generates a ProVerif model
for verification, direct from source code
Two Implementations of Crypto
22
A First
-
Order Fragment of ML
23
A Security Goal
24
Safety Against an Attacker
25
Functions as Processes
This is the core of model extraction, but additionally we
perform transformations to speed up verification.
These include inlining, and compilation of certain functions to
ProVerif’s predicates or reduction rules.
Much more could be done; in future, we’d like to adapt Hui and
Lowe’s theory of attack
-
preserving simplifications developed in
the context of CSP (CSFW 1999).
26
Compiling a Function
27
Soundness of our translation
28
Experimental results
We coded and verified a series of protocols
An implementation of Otway
-
Rees
A library for Web Services Security
Multiple message Web Services, with interoperability
We experimented with a range of security properties
Secrecy, Authentication, Session
We coded libraries enabling realistic attacker models
The attacker creates new principals, triggers their role,
controls the generation of cryptographic materials,
and can ask for password
-
and key
-
compromise
29
Some Verification Results
30
Limits of our model
As usual, formal security guarantees hold
only within the boundaries of the model
We keep model and implementation in sync
We automatically deal with very precise models
We can precisely “program” the attacker model
We verify our own implementations, not legacy code
We trust the compiler, runtime, model extractor, and verifier
Our method only finds bugs in the protocol code in F#
Certification is possible, but a separate problem
We trust our symbolic model of cryptography
Partial computational soundness results may apply
Further verification tools may use a concrete model
31
Summary and a Challenge
We verify
reference implementations
of security protocols
Our implementations run with both concrete and
symbolic cryptographic libraries.
Concrete implementation for production and interop testing
Symbolic implementation for debugging and verification
We develop our approach for protocols written in F#,
running on the CLR, verified by ProVerif.
We show its correctness for a range of security properties, against
realistic classes of adversaries
We validate our approach on WS protocols
Both our model extractor, fs2pv, and Csur operate on
code written within the research group
A remaining challenge is to verify independently written
implementations of cryptographic protocols
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο