Verifying Second-Level Security Protocols

1

Verifying Second-Level Security Protocols

G.Bella, C.Longo, L.C.Paulson

UNIVERSITÀ di CATANIADipartimento diMatematica e Informatica

Proc. of TPHOLs 2003, these days in Rome

G.Bella, C.Longo, L.C.Paulson: Verifying Second-Level Security Protocols 2

Certified e-mail delivery

Hmm, must send him an e-mail…

… but in such a way that he can’t claim I

didn’t…

OK, I’ll send it using that certified e-mail protocol…

Then I’ll get a receipt when he

sees the message!

2


Hmm, an e-mail from her… what a

weird protocol though…

At least she couldn’t get that receipt until I opened her email!

Certified e-mail delivery

… damn it! It means she now has a

receipt that I have read her message!


Goals in distributed systems

Complex security goals: certified e-mail, contract-signing, non-repudiation, delegation…

Basic security goals: confidentiality, authentication, integrity.

Basic communication goals: routing, transmission of raw byte streams…

Different goals require different kinds of protocol.

3


A hierarchy of protocols

transport protocols

classical security protocols

complex security protocols

verified!

verified!

verified??

0th -le

vel

first-

level

seco

nd-le

vel

Each protocol relies upon underlying protocols.


A hierarchy of protocols

transport protocols

classical security protocols

complex security protocols

verified!

verified!

verified??

0th -le

vel

first-

level

seco

nd-le

vel

Each protocol relies upon underlying protocols.

(0th-levelprotocols)

(first-level security protocols)

(second-level security protocols)

4


Definition relies upon goals

Essentially carbon-copied from actual protocol designs.

A second-level security protocol is: a protocol that assumes the goals of underlying authentication protocols in order to achieve its own goals.


SSL

CE

SCE

Protocol Hierarchy?It entirely depends on design.

Flat(first level)Verified!

Hierarchical(third level)How to verify?

CE

SSL

SCE

5


Certified e-mail (Abadi et al.)Abbreviations:

Steps:

This is a second-level protocol: it refers to SSL.


How the protocol works

Sender S sends the message, encrypted using a session key, to recipient R.

If R wants to proceed, R asks the Trusted Third Party (TTP) for the key.

The TTP releases the key to R and simultaneously gives a receipt to S.

6


Verifying second-level protocols

Shmatikov and Mitchell have model-checked a contract-signing protocol

Abadi and Blanchet have verified the certified e-mail protocol using Blanchet’s verifier

Creese et al. advance that a DY attacker may be exaggerated in ubiquitous environments (FAST 2003)


Our contribution

Identify the concept of second-level protocols

Enrich our inductive approach to

1. model the goals of first-level protocols

2. adapt Dolev-Yao’s threat model

3. express and verify the protocol goals

7


Primitive events

Fine for first-level protocols. And for second-level?

- A sends message X to B

- B receives message Xfrom network

- A stores message X as an internal state change


Basic operators

8


Specifying a protocol inductivelyProtocol DAP


1. Modelling underlying goalsAuthentication: allow references to sender by event , otherwise forbidden.Reception event naturally hides sender.

Guaranteed delivery: impose introduction of reception event . If also confidential, impose .

Confidentiality: use followed by . Reception is not guaranteed in general.

9


Modelling authentication

Allow receiver’s explicit reference to sender:


Modelling confidentiality

Just replaced events?!

10


YES: look at “knows”


Modelling Guaranteed Delivery

Combination of conf. and g.d. simpler to model than just…

11


2. Adapting the threat model

What’s the threat model for second-level protocols??

The formalisation of the goals just shown yields this threat model naturally.

Simply Dolev-Yao, assuming that the first-level protocol works. The Spy can also use the protocol.


Example: formalising message 2

R sends message to TTP on channel that is SSL protected and delivery guaranteed. The message “magically” reaches TTP.

Query/response mechanism between sender and receiver. Hides a Hash of receiver’s pwd.

Threat model: Spy sees message received by R but not that noted by TTP.

12


3. Modelling the new goalsConsider an e-mail m, its delivery receipt d, a sender S, an intended recipient R.

Goals of certified e-mail delivery (abstract version):

Must be made precise given a specific protocol.


Example: sender’s guarantee 1

Session key available to Spy (receiver might be Spy). Even then, S gets his receipt!

13


Example: sender’s guarantee 2

Receiver gets session key legitimately (receiver might be Spy). Even then, S gets his receipt!


Guarantees proved also for receiver

The receiver will get the key if the sender’s receipt exists

The receiver (who may be the Spy) does not get the key until the sender gets his receipt

Minor: if neither peer is compromised, then the protocol keeps session key secure

14


Differences from earlier proofs

Distrust of peer, who may be dishonest

Spy’s knowledge no longer the main issue: new reasoning methods needed

Issues in the modelling of secure channels


Found anomalyReceiver initiates from step 2, quoting arbitrary sender and building two identical hashes

Session succeds and sender gets receipt about email he never sent

Caused by absent authentication of sender with TTP.Solution: insert sender’s password into certificate S2TTP.

15


Found anomaly 2Receiver claims that email was sent years ago, hence irrelevant

Receiver may be truthful or not: problem either way

Solution: TTP include timestamp in delivery receipt.


ConclusionsSecond-level protocols are not difficult to verify

The use of logic lets us express security properties abstractly and naturally

A general-purpose proof tool (Isabelle) lets us modify the model without resorting to programming

Abadi et al.’s email protocol verified

Proof scripts available

Verifying Second-Level Security Protocols

Documents

Transcript of Verifying Second-Level Security Protocols