Provable Implementations of Security Protocols

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