Design of key establishment protocols

(1)

Design of key establishment protocols

- basic concepts, definitions, and classification

- examples (Wide-Mouth-Frog, Needham-Schroeder protocols) - robustness principles

- formal analysis and the BAN logic

“… our task is to program a computer which gives answers which are subtly and maliciously wrong at the most inconvenient possible moment.”

-- Ross Anderson and Roger Needham, Programming Satan’s computer

Goal and motivitaion

goal of key establishment protocols

– to setup a shared secret between two (or more) parties in a dynamic way

– established shared secret is used as a session key to protect communication between the parties

motivation for use of session keys – to limit available ciphertext for cryptanalysis

– to limit exposure caused by the compromise of a session key – to avoid long-term storage of a large number of secret keys (keys

are created on-demand when actually required) – to create independence across communication sessions or

applications

Basic concepts, definitions, and classification

Basic classification

key transport protocols

– one party creates or otherwise obtains a secret value, and securely transfers it to the other party

key agreement protocols

– a shared secret is derived by the parties as a function of information contributed by each, such that no party can predetermine the resulting value

Further protocol characterestics

provided guarantees – entity authentication

• one party is assured about the identity of a second party with which it is communicating

– implicit key authentication

• one party is assured that no other party aside from a specifically identified second party (and possibly some trusted third parties) may gain access to the established session key

– key confirmation

• one party is assured that a second (possibly unidentified) party actually possesses the session key

• possession of a key can be demonstrated by – producing a one- way hash value of the key or – encryption of known data with the key – explicit key authentication

• implicit key authentication + key confirmation – key freshness

• one party is assured that the key is new (never used before)

Further protocol characterestics

reciprocity

– guarantees are provided unilaterally – guarantees are provided mutually efficiency

– number of message exchanges (passes) required – total number of bits transmitted (i.e., bandwidth used) – complexity of computations by each party

– possibility of pre-computations to reduce on-line computational complexity

third party requirements

– on-line, off-line, or no third party at all – degree and type of trust required in the third party system setup

– distribution of initial keying material

Attacker model

it is assumed that the underlying cryptographic primitives (such as encryption, hash functions, etc) used in the protocol are secure

– the attacker is not a cryptanalyst, but someone who tries to subvert the protocol objectives by defeating the manner in which the crypto primitives are combined in the protocol

it is assumed that the network used by the protocol parties is under the full control of the attacker

– essentially, honest parties send and receive messages to and from the attacker who can decide whether to pass them on or carry out some of the following actions (with no noticeable delay):

• eavesdrop messages (passively)

• delete, insert, and modify messages

• replay old messages (recorded in the past)

• initiate one or more executions of the protocol

• participate in multiple concurrent protocol executions and interleave messages from different executions

(2)

Attacker model

objectives of the attacker – deduce a long-term key

• the attacker obtains the long-term key of a honest party A – deduce a session key

• the attacker obtains a session key shared between two honest parties A and B

– masquerade as a honest party B to A

• A believes that he established a session key with B, but in fact he established the key with the attacker

– deceive a honest party A regarding the identity of the other party

• A believes that he established a session key with B, but in fact he established the key with another honest party C

• the attacker does not know the established session key

Attacker model

sometimes it is assumed that the attacker has access to additional information beyond what is generally available

– compromise of past session keys

• obviously, the corresponding session is compromised

• can this be used by the attacker to compromise – future or past sessions?

– long- term secrets?

– compromise of long-term secrets (symmetric keys or private keys)

• obviously, owners of compromised keys can be impersonated in future sessions

• can this be used by the attacker to compromise past sessions?

(break-backward protection or perfect forward secrecy)

The Wide- Mouth- Frog protocol

Alice Server Bob

generate k

A, EKas( B, k, Ta )

E_Kbs( A, k, T_s) summary: a simple key transport protocol that uses a trusted third party

Alice generates the session key and sends it to Bob via the trusted third party

characteristics:unilateral entity authentication of Alice mutual implicit key authentication no key confirmation

key freshness with timestamps (flawed) key control for Alice

on- line third party trusted for secure relaying of keys and verification of freshness

initial long- term keys between the parties and the server are required

Examples / Wide-Mouth-Frog

A flaw in the Wide- Mouth- Frog protocol

summary:after observing one run of the protocol, Trudy can continuously use the Server as an oracle until she wants to bring about re- authentication between Alice and Bob

B, E_Kbs( A, k, T_s) E_Kas( B, k, Ts(1)) A, E_Kas( B, k, Ts(1))

E_Kbs( A, k, T_s⁽²⁾)

... E_Kbs( A, k, Ts(n)) Bob Trudy

Server

Examples / Wide-Mouth-Frog

The Needham- Schroeder protocol

A, B, ra

generate k EKas(ra, B, k, EKbs(k, A))

EKbs(k, A) E_k(r_b) Ek(rb- 1)

summary: Alice requests a session key from the Server; the Server generates the key and sends it to Alice and to Bob via Alice; Alice and Bob performs entity authentication and key confirmation

characteristics:mutual entity authentication, mutual explicit key authentication, key freshness with fresh random numbers (flawed), on- line third party trusted for generation of session keys, initial long- term keys between the parties and the server are required

Examples / Symmetric key Needham-Schroeder

A flaw in the Needham - Schroeder protocol

Trudy Bob

EKbs(k, A) Ek(rb’) Ek(rb’ - 1) Alice

assumption: Trudy recorded a successful run of the protocol and compromised the session key k; thus, she knows k and EKbs(k, A)

summary: Trudy masquerades as Alice to Bob and makes Bob accept the old and compromised session key k

Examples / Symmetric key Needham-Schroeder

(3)

The Needham- Schroeder public- key protocol

Bob P_Kb(r_a, A)

PKa(ra, rb) PKb( rb) Alice

summary:originally a challenge- response type mutual authentication protocol based on public- key encryption only (no signatures); however, since the random numbers exchanged never appear in clear, it was suggested to derive a session key from them

key derivation: both party computes k = f(ra, rb)

characteristics:mutual entity authentication, mutual implicit key authentication (flawed), no key confirmation, key freshness with random numbers, no party can control the key, off- line third party for issuing public key certificates may be required, initial exchange of public keys between the parties may be required

Examples / Asymmetric key Needham-Schroeder

Lowe’s attack

Alice Bob PKm(ra, A)

PKa(ra, rb) P_Km( r_b)

PKb( rb) PKb(ra, A) P_Ka(r_a, r_b) Mallory assumption: Mallory is a malicious user, his public key is K_m

summary: when Alice starts the protocol with Mallory, he can masquerade as Alice to Bob;

Mallory uses Alice as an oracle to decrypt a message received from Bob;

if the protocol is used for key establishment, then Bob falsely believes that he shares a secret key with Alice, but indeed he shares it with Mallory

Examples / Asymmetric key Needham-Schroeder

Robustness principles

- names - encryption - timeliness

- recognizing messages and encodings - trust

Robustness principles

informal guidelines for engineering key establishment protocols can complement formal analysis methods

they are neither necessary nor sufficient for correctness they are simply helpful

Robustness principles

General principles

Principle 1

every message should say what it means; its interpretation should depend only on its content

– if something which is essential to the meaning of a message is left to be inferred from the context, then (re)using the message in a different context may lead to inferring that essential information erroneously

Principle 2

the conditions for a message to be acted upon should be clearly set out so someone reviewing a design may see whether they are acceptable or not

– understanding a message is one thing, but in order to act upon it, a variety of other conditions must hold

– e.g., A may understand that it received a session key from B, but in order to accept this key, A should trust B for generating good quality keys; this trust required in B should be set out explicitly

Robustness principles

Explicit mention of names

Principle 3

if the identity of a principal is essential to the meaning of a message, then it is prudent to mention the name of the principal explicitly in the message

– an early version of SSL:

msg1 A B: PKb(k) msg2 B A: Ek(Nb) msg3 A B: E_k(Cert_A, S_Ka(N_b)) – attack:

msg1 A B: PKb(k) msg1 B C: P_Kc(k) msg2 C B: E_k(N_c) msg2 B A: Ek(Nc) msg3 A B: Ek(CertA, SKa(Nc))

msg3 B C: Ek(CertA, SKa(Nc)) – fix:

msg3 A B: Ek(CertA, SKa(A, B, k, Nb))

Robustness principles / Names

(4)

Use of encryption

Principle 4

be clear on why encryption is being done; encryption is not synonymous with security and its improper use can lead to errors – encryption can be used for various purposes in a protocol – the most common uses are the following:

• to provide confidentiality for the session key

• to provide key confirmation

• to bind parts of a message together

– receiving Ek(X, Y) is not the same as receiving Ek(X) and Ek(Y)

Robustness principles / Encryption

Use of encryption

– Needham-Schroeder with timestamps:

msg1 A S: A, B

msg2 S A: EKas(Ts, k, B, EKbs(Ts, k, A)) msg3 A B: EKbs(Ts, k, A) msg4 B A: E_k(r_b) msg5 A B: E_k(r_b- 1) – use of encryption

msg2, msg3

• to ensure the confidentiality of k

• to bind together T_s, K, and A/B msg4, msg5

• to prove knowledge of k – why nested encryption in msg2 ?

• at first sight, it does not add too much to the protocol

• but a more careful analysis reveals that nested encryption do have a role:

– when B receives msg3 near T_s, he knows that A must have extracted it from msg2 near Ts, and hence A must know k (part of msg2) near Ts

msg5 is not needed

• conclusion:

– either nested encryption in msg2 and no msg5 – or no nested encryption in msg2 and msg5 is needed

Signing encrypted data

Principle 5

– when a principal signs something that has already been encrypted, it should not be inferred that he knows the content of the message

– it is proper to infer that a principal that signs a message and then encrypts it knows the content of the message

– X.509 protocol:

msg1 A B: A, SKa(Ta, Na, B, Xa, PKb(Ya)) – B can be sure that the message comes from A – B cannot be sure that A knows Ya:

msg1 C B: C, SKc(Tc, Nc, B, Xc, PKb(Yc)) msg1 A B: A, SKa(Ta, Na, B, Xa, PKb(Yc))

Use of random nonces

Principle 6

be clear on what properties you are assuming about nonces; what may do for ensuring temporal succession may not do for ensuring association

– Otway-Rees protocol:

msg1 A B: M, A, B, EKas(Na, M, A, B)

msg2 B S: M, A, B, E_Kas(N_a, M, A, B), E_Kbs(N_b, M, A, B) msg3 S B: M, EKas(Na, k), EKbs(Nb, k)

msg4 B A: M, EKas(Na, k)

– N_aand N_bare used to ensure freshness of k in msg3 and msg4 – Naand Nbare also used as references to A and B in msg3 and

msg4

• Nais bound with A and B by encryption in msg1

• Nbis bound with A and B by encryption in msg2

• encryption is used not for secrecy but for binding

Robustness principles / Timeliness

Use of random nonces

– Otway-Rees made simpler:

msg1 A B: A, N_a msg2 B S: A, B, Na, Nb

msg3 S B: EKas(Na, A, B, k), EKbs(Nb, A, B, k) msg4 B A: E_Kas(N_a, A, B, k)

– uses fewer encryptions – role of nonces is clear

– names are mentioned explicitly in messages

Predictable nonces

Principle 7

predictable quantities can be used as nonces in challenge-response protocols, but they should be protected so that an attacker cannot simulate a challenge and later replay a response – a protocol to access a time server:

msg1 A S: A, Na msg2 S A: E_Kas(T_s, N_a) – if Nais predictable:

at T0: X S: A, Na S X: EKas(T0, Na) at T₁: A X%S: A, Na

X%S A: EKas(T0, Na)

(5)

Timestamps

Principle 8

if timestamps are used as freshness guarantees then clocks must be synchronized and the time maintenance mechanism becomes part of the trusted computing base

– a slow clock is dangerous:

• a principal with a slow clock may accept expired certificates – a fast clock may be dangerous too:

• principal with a fast clock may sign a message at T₀using a timestamp T₁> T₀

• an attacker can replay this message at T1

Key freshness

Principle 9

a key may have been used recently, for example to encrypt fresh data, yet be quite old and possibly compromised

– example:

• attack on the Needham-Schroeder symmetric-key protocol

Encoding of messages

Principle 10

it should be possible to deduce from the encoding of a message which run of what protocol it belongs to, and what its number is in the protocol

– Wide-Mouth-Frog protocol:

msg1 A S: A, EKas(Ta, k, B) msg2 S B: E_Kbs(T_s, k, A)

– problem:

• direction is not encoded in the messages – fix:

msg1 A S: A, EKas(“WMF#1”, Ta, k, B) msg2 S B: EKbs(“WMF#2”, Ts, k, A)

Robustness principles / Encoding of messages

Interference between protocols

Please, transfer 1 M $ from the account of Alice to the account of Bob.

hash

hash of message

sign

signature of message

Please, transfer 1 M $ from the account of Alice to the account of Bob.

signature of message

A hash of msg S_Ka( hash of msg )

Alice Bob

- the following should be made impossible by appropriate encoding

Private key of Alice

Robustness principles / Encoding of messages

Trust

Principle 11

be clear on which trust relations your protocol depends on and why the dependence is necessary

– examples:

• in the Wide-Mouth-Frog protocol, one of the parties (A) should be trusted for generating good quality keys; this might be unacceptable in some applications (e.g., where A is a smart card)

• if authenticity of a public key is verified by checking certificate chains, then all issuers in the chain must be trusted

• …

Robustness principles / Trust

BAN logic

- language and inference rules

- methodology of protocol analysis with BAN (like) logic(s) - example: analysis of the Needham-Schroeder protocol - some limitations of BAN logic

(6)

Motivation for formal methods

many protocols have been proposed, but most of them are flawed

– how can these flaws be explained?

flaws are subtle and hard to find – how can flaws be uncovered?

in order to avoid flaws, we need more understanding – what does the protocol really achieve?

– does the protocol need more assumptions than another one?

– does the protocol do anything unnecessary that could be left out without weakening it?

• e.g., does the protocol encrypt something that could be sent in clear?

formal methods may help answering these questions

BAN / Preliminaries

Applications of formal methods

specification construction verification

– logics

• general purpose: HOL/Isabelle

• special: BAN, GNY, SvO, … – process algebrae

• general purpose: CSP/FDR

• special: spi-calculus – strand spaces (Athena) – model checking (Murphi, …)

– specialized expert systems (NRL protocol analyzer, Interrogator)

BAN / Preliminaries

Basic ideas

BAN logic is a formalism that allows us to describe the beliefs of parties in the protocol and to study the evolution of these beliefs as a consequence of communication

examples:

– if you have sent Bob a number that you have never used for this purpose before, and if you subsequently receive from Bob something that depends on knowing that number, then you should believe that Bob’s message originated recently (at least after yours)

– if you believe that only you and Bob know K, then you should believe that anything you receive encrypted with K comes originally from Bob

– if you believe that K is Bob’s public key, then you should believe that any signed message that you can successfully verify with K comes originally from Bob

– …

BAN / Basic ideas

Language

notation:P, Q, R principals (or parties)

K (symmetric) key

PuK, PrK public - private keys X, Y statements { X }_K encryption (signature)

P believes X

principal Pacts as though the statement Xis true P sees X

someone has sent a message containing Xto P, who can read (and possibly repeat) X

P said X

Pat some time sent a message including X; it is not known whether the message was sent long ago or recently, but it is known that P believed Xwhen he sent it

P controls X

Pis an authority on Xand should be trusted on this matter

BAN / Language

Language

X is fresh

Xhas not been sent in a message at any time before the current run of the protocol (this is typically true for nonces)

P K Q

Pand Qmay use the shared key Kto communicate; the key Kis good, in that it will never be discovered by any principal other than Pand Q,or principals trusted by Por Q

PuK = P

Phas PuKas a public key; the corresponding private key PrKwill never be discovered by any principal other than P,or principals trusted by P

X is secret to P, Q

Xis a secret known only to P and Q and possible to principals trusted by them

BAN / Language

Inference rules

P believes PK Q , P sees { X }_K P believes ( Q said X ) message meaning rules:

P believes PuK=Q , P sees { X }_PrK P believes ( Q said X )

nonce verification rule:

P believes ( X is fresh ) , P believes ( Q said X ) P believes ( Q believes X )

control rule:

P believes ( Q controls X ) , P believes ( Q believes X ) P believes X

BAN / Inference rules

(7)

Inference rules

belief rules:

P believes X , P believes Y

P believes ( X and Y ) P believes X , P believes Y P believes ( X and Y )

P believes ( Q believes X ) P believes ( Q believes ( X and Y ) )

saying rules:

P believes ( Q said X ) P believes ( Q said [ X, Y ] )

seeing rules:

P sees X P sees [ X, Y ]

P sees X P believes PK Q , P sees { X }_K

P sees X P believes PuK=P, P sees { X }PuK

P sees X P believes PuK=Q , P sees { X }PrK

Inference rules

freshness rule:

P believes ( [ X, Y] is fresh ) P believes ( X is fresh)

symmetry of shared secrets:

P believes R’K R P believes RK R’

P believes ( K is secret to R’, R ) P believes ( K is secret to R , R’)

P believes ( Q believes R’K R ) P believes ( Q believes RK R’ )

P believes ( Q believes ( K is secret to R’, R ) ) P believes ( Q believes ( K is secret to R , R’) )

Summary of assumptions

cryptography and communication

– cryptographic primitives are secure and perfect (unbreakable) – each encrypted message contains sufficient redundancy to allow a

principal who decrypts it to verify that he has used the right key – principals recognize and ignore their own messages

time

– time is divided into past and present; the present epoch begins at the start of the particular run of the protocol under consideration belief

– all beliefs held in the present are stable for the entirety of the protocol run

– when a principal says something, then he actually believes it – beliefs held in the past are not necessarily carried forward into

the present

BAN / Assumptions

Analysis methodology

protocol

formal protocol description idealization

assumptions

goals

annotation achievements

compare

BAN / Analysis methodology

Idealization

translation into a logical form

– logical form = implementation independent encoding – original: A→B: msg

– logical: B sees ( a formula that represents msg) there’s no general rule for this translation

– idealization requires to understand the protocol conceptually – once it is understood, it is fairly easy to generate a useful logical

form of the protocol guidelines

– leave out everything that do not contribute to the beliefs of the recipient of the message

– in particular, remove cleartext hints

– a real message msgcan be interpreted as a formula Xif whenever the recipient gets msghe may deduce that the sender must have believed Xwhen he sent msg

Assumptions and goals formalized

assumptions

– pre-established channels

• A believes ( A K S ) – nonces

• A believes ( r_ais fresh ) – trust

• A believes ( S controls ( A K B) ) goals

– entity authentication

• A believes ( B said X ) andA believes ( X is fresh ) – implicit key authentication

• A believes ( A K B) – key confirmation

• A believes ( B believes ( A K B ) ) – key freshness

• A believes ( K is fresh )

(8)

Protocol annotation

S₀- assumptions

S1- set of formulae derivable from S0∪{ B sees f( msg1 )}

S2- set of formulae derivable from S1∪{ A sees f( msg2 )}

Sn- set of formulae derivable from Sn-1∪{ B sees f( msgn)} B sees f( msg₁)

A sees f( msg2)

B sees f( msgn)

…

The Needham- Schroeder protocol

BAN / Analysis of the NS protocol

A, B, r_a

generate k EKas(ra, B, k, EKbs(k, A))

EKbs(k, A) Ek(rb) E_k(r_b- 1)

summary: Alice requests a session key from the Server; the Server generates the key and sends it to Alice and to Bob via Alice; Alice and Bob performs entity authentication and key confirmation

characteristics:mutual entity authentication, mutual explicit key authentication, key freshness with fresh random numbers (flawed), on- line third party trusted for generation of session keys, initial long- term keys between the parties and the server are required

Idealization

original:

A S : A, B, r_a

S A : { ra, B, k, { k, A }Kbs}Kas A B : { k, A }Kbs

B A : { r_b}_k A B : { rb- 1 }k

idealized:

A sees { r_a, Ak B, k is fresh, { Ak B, k is fresh }_Kbs}_Kas B sees { Ak B, k is fresh }_Kbs

A sees { r_b, Ak B }_k B sees { r_b- 1, Ak B }_k

Assumptions

pre-established channels:

A believes ( AK_as S ) S believes ( AKas S ) B believes ( BKbs S ) S believes ( BK_bs S ) trust:

A believes ( S controls ( Ak B ) ) B believes ( S controls ( Ak B ) ) A believes ( S controls (k is fresh) ) B believes ( S controls (k is fresh) ) nonces:

A believes ( r_ais fresh ) B believes ( rbis fresh ) session key:

S believes ( Ak B ) S believes ( k is fresh )

Analysis

A sees { ra, Ak B, k is fresh, { Ak B, k is fresh }Kbs}Kas

A sees { r_a, Ak B, k is fresh { Ak B, k is fresh }_Kbs}_Kas A believes ( AKas S )

A believes ( S said [ ra, Ak B, k is fresh, { Ak B, k is fresh }Kbs] ) A believes ( r_ais fresh )

A believes ( [ r_a, Ak B, k is fresh, { Ak B, k is fresh }_Kbs] is fresh )

A believes ( S said [ra, Ak B, k is fresh, { Ak B, k is fresh }Kbs] ) A believes ( [r_a, Ak B, k is fresh, { Ak B, k is fresh }_Kbs] is fresh )

A believes ( S believes ( Ak B ) ) A believes ( S believes ( k is fresh ) )

A believes ( S believes ( Ak B ) ) A believes ( S controls ( Ak B ) )

A believes ( Ak B )

A believes ( S believes ( k is fresh ) ) A believes ( S controls ( k is fresh ) )

A believes ( k is fresh )

Analysis

B sees { Ak B, k is fresh }Kbs

B sees { Ak B, k is fresh }_Kbs B believes ( AKbs S ) B believes ( S said [Ak B, k is fresh] )

???

B believes ( [ Ak B, k is fresh ] is fresh ) B believes ( S said [Ak B, k is fresh ] ) B believes ( [Ak B, k is fresh ] is fresh )

B believes ( S believes ( Ak B ) ) B believes ( S believes ( k is fresh ) ) B believes ( S believes ( Ak B ) )

B believes ( S controls ( Ak B ) ) B believes ( Ak B )

B believes ( S believes ( k is fresh ) ) B believes ( S controls ( k is fresh ) )

B believes ( k is fresh )

(9)

Analysis

A sees { rb, Ak B }k A sees { r_b, Ak B }_k A believes ( Ak B ) A believes ( B said [r_b, Ak B ] )

A believes ( k is fresh ) A believes ( [ r_b, Ak B ] is fresh ) A believes ( B said [ r_b, Ak B ] )

A believes ( [ rb, Ak B ] is fresh ) A believes ( B believes ( Ak B ) )

B sees { r_b- 1, Ak B }_k B sees { r_b- 1, Ak B }_k B believes ( Ak B ) B believes ( A said [ rb- 1, Ak B ] )

B believes ( rb is fresh ) B believes ( [ rb- 1, Ak B ] is fresh ) B believes ( A said [ r_b- 1, Ak B ] )

B believes ( [ rb- 1, Ak B ] is fresh ) B believes ( A believes ( Ak B ) )

Nessett’s critique

Nessett protocol:

A B : { Ta, B, k }PrKa B A : { T_b}_k

idealized Nessett protocol:

B sees { Ta, Ak B }PrKa A sees { Tb, Ak B}k analysis:

B sees { T_a, Ak B }_PrKa B believes ( PuKa= A ) B believes ( A said [ Ta , Ak B ] )

B believes ( Tais fresh ) B believes ( [ Ta , Ak B ] is fresh ) B believes ( A said [ Ta , Ak B ] )

B believes ( [ Ta , Ak B ] is fresh ) B believes ( A believes ( Ak B ) ) B believes ( A believes ( Ak B ) ) B believes ( A controls ( Ak B ) )

B believes ( Ak B )

conclusion: the BAN analysis suggests that the protocol is correct, but it is obviously flawed

BAN / Limitations

BAN’s rejoinder

from Burrows, Abadi, and Needham, Rejoinder to Nessett, Operating Systems Review, Vol. 24. No. 2. April 1990

– “… while we allow for the possibility of hostile intruders, there is no attempt to deal with the authentication of an untrustworthy principal, nor to detect weaknesses of encryption schemes or unauthorized release of secrets ...”

– “… The main difficulty comes with the introduction of the assumption A believes ( Ak B ), which says that Abelieves that kis a good shared key for Aand B. This assumption is clearly inconsistent with the message exchange, where Apublishes k. The inconsistency is not manifested by our formalism, but it is not beyond the wit of man to notice. ...”

BAN / Limitations

Conclusion on BAN logic

formal methods can be very helpful

but no formal method exist that discover every security weaknesses in a protocol

when you use a formal method you should be aware of the limitations of that method

BAN logic is one of the most popular formal methods to analyze cryptographic protocols (it is simple and intuitive)

BAN logic helped researchers

– to discover previously unknown flaws in published protocols, and – to understand the basic principles of authentication and key

establishment

BAN logic has limitations and weaknesses – it failed to discover certain flaws in certain protocols – it seems to have problems in analyzing secrecy properties – it requires “protocol idealization”, which may lead to errors

BAN / Conclusion

Summary

basic concepts

– key establishment, key transport, key agreement

– implicit key authentication, key confirmation, key freshness, … – attacker model

• black box crypto

• attacker controls the network

• simple replays and interleaving attacks robustness principles

– be explicit!

• especially, mention names explicitly formal methods and the BAN logic

– be aware of the limitations of the particular method you use!

Design of key establishment protocols