Analysis and design of

cryptographic protocols

Main topics
!  The BAN logic
!  Design principles
!  Case studies
•  Needham-Schroeder Kerberos
•  Otway-Rees
•  SSL (an old version)
•  GSM

SNCS Ban logic 2

 The problem

Security protocols are three-line programs

that people still manage to get wrong.
Roger M. Needham

SNCS Ban logic 3

The BAN logic

!  After its inventors: Burrows, Abadi, Needham
!  Belief and action
!  The logic cannot prove that a protocol is wrong
!  However, if you cannot prove a protocol correct,
then consider that protocol with great suspicion

SNCS Ban logic 4

 Formalism
P |≡ X P believes X. P behaves as if X were true

P X P sees X:

P |∼ X P once said X:

P ⇒ X P controls X.

# (X ) X is fresh

K
P ↔ Q K is a shared key between P e Q

SNCS Ban logic 5

Formalism

K
P Q X is a shared secret between P e Q

K
 P K is P’s public key

X Y
X is a combined with Y

{X }K X has been encrypted with K

SNCS Ban logic 6

 Examples
A|≡ #(N a ) A believes that Na is fresh

K
A|≡ A↔ B A believes K to be a shared key with B

K T believes that K is a shared key between A and B

T |≡ A↔ B

K A believes T an authority on generating session keys

A|≡ T ⇒ A↔ B

⎛ K ⎞
A|≡ T ⇒ # ⎜ A↔ B⎟ A believes that T is competent in generating fresh
⎝ ⎠
session keys

SNCS Ban logic 7

Preliminaries
!  BAN logic considers two epochs: the present
and the past
•  The present begins with the start of the protocol

!  Beliefs achieved in the present are stable for all

the protocol duration
!  If P says X then P believes X
!  Beliefs of the past may not hold in the present

SNCS Ban logic 8

 Postulates: message meaning rule
If K is a shared key between P and Q, a P sees
K
P |≡ Q ↔ P, P  { X } K a message encrypted by K containing X (and P
did not send that message), then P believes
P |≡ Q |∼ X
that X was sent by Q

K
If K is Q’s public key, and P sees a message
P |≡  Q, P  { X } K −1 signed by con K-1 containing X, then P believes
P |≡ Q |∼ X
that X was sent by Q

If Y is a shared secrete between P and Q, and

Y
P |≡ Q  P, P  X P sees a message where Y is combined with X
Y
(and P did not send the message), thenP
P |≡ Q |∼ X
believes that X was sent by Q

SNCS Ban logic 9

Postulates: nonce verification rule

P |≡ #( X ), P |≡ Q |∼ X
P |≡ Q |≡ X

!  If P believes Q said X and P believes X is fresh, then P believes Q

believes X (now, in this protocol execution)
!  If P believes X was sent by Q, and P believes X is fresh, then P believes
Q has sent X in this protocol execution instance

SNCS Ban logic 10

 Postulates: jurisdiction rule
P |≡ Q |≡ X , P |≡ Q ⇒ X
P |≡ X

!  If P believes Q believes X and P believes Q is an authority on X, then

P believes X too
!  If P believes Q says X and P trusts Q on X, then P believes X too

SNCS Ban logic 11

Altri postulati
P |≡ X , P |≡ Y P |≡ ( X ,Y ) P |≡ Q |≡ ( X ,Y ) P |≡ Q |∼ ( X ,Y )
P |≡ ( X ,Y ) P |≡ X , P |≡ Y P |≡ Q |≡ X P |≡ Q |∼ X

P |≡ #( X )
P |≡ #( X ,Y )

P  ( X ,Y ) P X Y

P X P X
K K K
P |≡ Q ↔ P, P  { X } K P |≡  P, P  { X } K P |≡  Q, P  { X } K −1

P X P X P X

K K K K
P |≡ R ↔ R′ P |≡ Q |≡ R ↔ R′ P |≡ R  R′ P |≡ Q |≡ R  R′
K K K K
P |≡ R′ ↔ R P |≡ Q |≡ R′ ↔ R P |≡ R′  R P |≡ Q |≡ R′  R

SNCS Ban logic 12

 Protocollo idealizzato
Each protocol step is represented as
A → B : messaggio

For example:
A → B : { A, K ab } K
bs

This notations is ambiguous. Thus the protocol is idealized

⎧ Kab ⎫
A → B : ⎨ A↔ B ⎬
⎩ ⎭ Kbs

The resulting specification is more clear and you can

desume the formula
K ab
B  A↔ B
SNCS Ban logic 13

Protocol analysis
!  Protocol analysis consists in the following steps
1.  Derive the idealized protocol from the real
one
2.  Determine assumptions
3.  Apply postulates to each protocol step and
determine beliefs achieved by principals at
the step
4.  Draw conclusions

SNCS Ban logic 14

 Protocol analysis
[assumption] S1 [assertion 1]
….
[assertion i-1] Si [assertion i]
…
[assertion n-1] Sn [conclusions]
K

Assertion i-1 A |≡ A ↔ B

A → B : { X }K
By applying the message
Step i meaning postulate
K
Assertion i A |≡ A ↔ B, B |≡ A |∼ X

SNCS Ban logic 15

Objectives of a protocol
Objectives depend on the context

! Typical objectives
K K
A |≡ A ↔ B B |≡ A ↔ B (key authentication)
K K
often A |≡ B |≡ A ↔ B B |≡ A |≡ A ↔ B (key confirmation)

A |≡ # ⎛⎜ A ↔ B ⎞⎟ B |≡ # ⎛⎜ A ↔ B ⎞⎟
K K
also (key freshness)
⎝ ⎠ ⎝ ⎠

! Interaction with a certification authority

eb
A |≡ a B

SNCS Ban logic 16

 Needham-Schroeder (1978)

Real protocol
M1 A→T A, B, N a
M 2 T → A EKa ( N a , B, K ab , EKb ( K ab , A ) )
M3 A → B EKb ( K ab , A )
M 4 B → A EKab ( N b )
M5 A → B EKab ( N b − 1)

SNCS Ban logic 17

Needham-Schroeder (1978)
Implicit statement, not explicitly
derived from the real protocol
Idealized protocol •  The idealized protocol may contain implicit
statements

⎧⎪ ⎛ Kab ⎞ ⎛ Kab ⎞ ⎧ Kab ⎫ ⎫⎪

M 2 T → A ⎨Na , ⎜ A ↔ B ⎟ , # ⎜ A ↔ B ⎟ , ⎨ A ↔ B⎬ ⎬
⎩⎪ ⎝ ⎠ ⎝ ⎠ ⎩ ⎭ Kb ⎭⎪ K
a

⎧ Kab ⎫
M3 A → B ⎨ A ↔ B⎬
⎩ ⎭ Kb
⎧ K ab
⎫
M 4 B → A ⎨ N b , A ↔ B ⎬ from B
⎩ ⎭ Kab
⎧ K ab
⎫
M5 A → B ⎨ N b , A ↔ B ⎬ from A
⎩ ⎭ Kab

SNCS Ban logic 18

 Needham-Schroeder
⎧⎪ After receiving Na, T said
⎛ Kab ⎞ ⎛ Kab ⎞ ⎧ Kab ⎫ ⎫⎪
M 2 T → A ⎨ N a , ⎜ A ↔ B ⎟ , # ⎜ A ↔ B ⎟ , ⎨ A ↔ B ⎬ ⎬ Kab is ”good" to talk to
⎪⎩ ⎝ ⎠ ⎝ ⎠ ⎩ ⎭ Kb ⎪⎭ K Bob
a

⎧ Kab ⎫ T said Kab is good to talk to Alice

M 3 A → B ⎨ A ↔ B⎬
⎩ ⎭ Kb

⎧ K ab
⎫ After receiving Kab, B has said Kab is
M 4 B → A ⎨ Nb , A ↔ B ⎬ from B good to talk to A
⎩ ⎭Kab

⎧ K ab
⎫ After receiving Nb, A has said Kab is
M 5 A → B ⎨ Nb , A ↔ B ⎬ from A good to talk to Bob
⎩ ⎭Kab

Principle 1. We have to specify the meaning of each message; specification must

depend on the message contents; it must be possible to write a sentence
describing such a meaning

SNCS Ban logic 19

Needham-Schroeder
Assumptions Objectives
Ka Kb K ab
A |≡ A ↔ T B |≡ B ↔ T A |≡ A ↔ B
Ka Kb K ab
T |≡ A ↔ T T |≡ B ↔ T B |≡ A ↔ B
K ab K ab
T |≡ A ↔ B A |≡ B |≡ A ↔ B
⎛ K ab
⎞ ⎛ K ab
⎞ K ab
A |≡ ⎜ T ⇒ A ↔ B ⎟ B |≡ ⎜ T ⇒ A ↔ B ⎟ B |≡ A |≡ A ↔ B
⎝ ⎠ ⎝ ⎠
⎛ ⎛ Kab ⎞ ⎞ Principle 2. Designer must know
A |≡ ⎜ T ⇒ # ⎜ A ↔ B ⎟ ⎟
⎝ ⎝ ⎠⎠ the trust relationships upon which
A |≡ # ( N a ) B |≡ # ( N b ) the protocol is based. He/she must
know why they are necessary. Such
⎛ K ab ⎞ ⎛ K ab ⎞ reasons must be made explicit.
T |≡ # ⎜ A ↔ B ⎟ B |≡ # ⎜ A ↔ B ⎟
⎝ ⎠ ⎝ ⎠

SNCS Ban logic 20

 Needham-Schroeder
After M2 After M3 After M4
message meaning e
nonce verification message meaning message meaning
K ab K ab
⎛ Kab ⎞
A |≡ T |≡ ⎜ A↔ B⎟ B |≡ T |∼ A ↔ B A |≡ B |∼ A ↔ B
⎝ ⎠
⎛ Kab ⎞ nonce verification nonce verification
A |≡ T |≡ # ⎜ A↔ B⎟ K ab K ab
⎝ ⎠ B |≡ T |≡ A ↔ B A |≡ B |≡ A ↔ B

jurisdiction rule Dopo M5

jurisdiction rule K ab
B |≡ A ↔ B message meaning
⎛ K ab ⎞
A |≡ ⎜ A ↔ B ⎟ ⎛ K ab
⎞
⎝ ⎠ Principle 3. A key may have been B |≡ A |∼ ⎜ N b , A ↔ B ⎟
used recently to encrypt a nonce but it ⎝ ⎠
⎛ K ab ⎞ may be old or compromised. The
A |≡ # ⎜ A ↔ B ⎟ nonce verification
⎝ ⎠ recent use of a key does not make it K ab
more secure B |≡ A |≡ A ↔ B

SNCS Ban logic 21

Otway-Rees protocol
Real protocol
M1. A → B : M , A, B, EK A ( N A , M , A, B )
M2. B → T : M , A, B, EK A ( N A , M , A, B ) , EK B ( N B , M , A, B ) T
M3. T → B : M , EK A ( N A , K ab ) , EK B ( N B , K ab ) M2 M3
M1
M4. B → A : M , EK A ( N A , K ab )

Idealized protocol A B
M1. A → B : { N A , M , A, B}K M4
a

M2. B → T : {N A , M , A, B}K , {N B , M , A, B}K

a b

⎧ K ab
⎫ ⎧ K ab
⎫
M3. T → B : ⎨ N a , A ↔ B, B |~ M ⎬ , ⎨ N b , A ↔ B, A |~ M ⎬
⎩ ⎭Ka ⎩ ⎭ Kb
⎧ K ab
⎫
M4. B → A : ⎨ N b , A ↔ B, A |~ M ⎬
⎩ ⎭Ka

SNCS Ban logic 22

 Otway-Rees

The protocol presents two strange features

!  Na ed Nb are nonces. They are supposed to
prove freshness. Then, why are they encrypted
in messages M1 and M2?
!  Why do we need M in addition to Na and Nb?
•  Actually it disappears after M2

SNCS Ban logic 23

Otway-Rees
M1. A→ B:{N A , M , A, B}K a

M2. B → T : { N A , M , A, B}K , {N B , M , A, B}K

a b

⎧ K ab
⎫ ⎧ K ab
⎫
M3. T → B : ⎨ N a , A ↔ B, B |~ M ⎬ , ⎨ N b , A ↔ B, A |~ M ⎬
⎩ ⎭Ka ⎩ ⎭ Kb
⎧ K ab
⎫
M4. B → A : ⎨ N a , A ↔ B, B |~ M ⎬
⎩ ⎭Ka
M1: Alice says that M is a transaction with Bob and Na is
another name of Alice in M

M2: Bob says that M is a transaction with Bob and Nb is

another name of Bob in M

M3: After receiving Nb, T says that Kab is good and that Alice
believed to be in M
M4: After receiving Na, T says that Kab is good and that Bob believed to
be in M

SNCS Ban logic 24

 Protocollo di Otway-Rees

Ipotesi Risultati
Ka Kb K ab

A |≡ A ↔ T B |≡ A ↔ T A |≡ A ↔ B
Ka Kb K ab

T |≡ A ↔ T T |≡ A ↔ T B |≡ A ↔ B
K ab A |≡ B |≡ M
T |≡ A ↔ B B |≡ A |~ M
A |≡ ⎜ T ⇒ A ↔ B ⎟ B |≡ ⎜ T ⇒ A ↔ B ⎞⎟
⎛ ⎞ ⎛
K K

⎝ ⎠ ⎝ ⎠
A |≡ (T ⇒ B |~ M ) B |≡ (T ⇒ A |~ M )
A |≡ # ( N a ) B |≡ # ( N b )
A |≡ # ( M )

SNCS Ban logic 25

Protocollo di Otway-Rees
After M2
T |≡ A |~ ( N a , M , A, B ) T |≡ B |~ ( Nb , M , A, B )
After M3
⎛ K ab
⎞
B |≡ T |~ ⎜ N b , A ↔ B, A |~ M ⎟ Given Bob’s belief in Nb freshness, then
⎝ ⎠
⎛ K ab
⎞
B |≡ T |≡ ⎜ N b , A ↔ B, A |~ M ⎟ Given Bob’s trust in T about keys and its capability to
⎝ ⎠ relay, then
K ab
B |≡ A ↔ B, B |≡ A |~ M
After M4
⎛ K ab
⎞
A |≡ T |~ ⎜ N a , A ↔ B, B |~ M ⎟ Given Alice’s belief in Na, then
⎝ ⎠
⎛ K ab
⎞
A |≡ T |≡ ⎜ N a , A ↔ B, B |~ M ⎟ Given Alice’s trust in T about keys and its capability to
⎝ ⎠ relay and given Alice’s belief in M freshness
K ab
A |≡ A ↔ B, A |≡ B |≡ M
SNCS Ban logic 26
 Otway-Rees
!  Nonces Na and Nb are for freshness but also to link messages M1 and
M2 to messages M3 and M4, respectively
!  Nonce Na (Nb) is a reference to Alice (Bob) within M, or equivalently,
!  nonce Na (Nb) is another name for Alice (Bob) in M
!  In M1 (M2), encryption is not for secrecy but to indissolubly link Alice
(Bob), Na (Nb) and M together

Principle 4. Properties required to nonces must be clear. What it is fine to

guarantee freshness might not be to guarantee an association between
parts

Principles 5. The reason why encryption is used must be clear

SNCS Ban logic 27

Otway-Rees modified
!  If nonces have to guarantee freshness only, then messages
M1 and M2 could be modified as follows

M1. A → B : M , A, B, N A , EK A ( M , A, B )
M2. B → T : M , A, B, N A , EK A ( M , A, B ) , N B , EK B ( M , A, B )

•  M1 and M3 (M2 and M4) are not linked anymore

•  The resulting protocol is subject to a man-in-the-middle
attack
•  An adversary may impersonate Bob (Alice) with respect to Alice
(Bob)

SNCS Ban logic 28

 Otway-Rees modified
•  The resulting protocol is subject to a man-in-the-
middle attack
•  An adversary may impersonate Bob (Alice) with respect
to Alice (Bob)

•  Let us suppose that Carol (the adversary)

!  has already carried out a protocol instance with
Alice
!  holds an ”old” ciphertext EKa(M´, A, C)

SNCS Ban logic 29

Otway-Rees modified
The Attack

M1. A → B[C ]: M , A, B, N a , EK A ( M , A, B )
M2. C → T : M ′, A, C , N a , EK A ( M ′, A, C ) , N c , EKc ( M ′, A, C )
M3. T → C : M ′, EKa ( N a , K ab ) , EKc ( N c , K ab )
M4. [C ]B → A : EKa ( N a , K ab )

SNCS Ban logic 30

 Protocollo di Otway-Rees "migliorato"
!  If we need to insert references to Alice and Bob in M3 and
M4, then the protocol can ben modified as follows

M1. A → B : A, B, N a
M2. B → T : A, B, N a , N b
M3. T → B : EK A ( N a , A, B, K ab ) , EK B ( N b , A, B, K ab )
M4. B → A : EK A ( N a , A, B, K ab )

Principle 6. If an identifier is necessary to complete the meaning of a

message, it is prudent to explicitly mention such an identifier in the
message

SNCS Ban logic 31

SSL (old version)

Protocol objectives:
•  establish a shared key Kab
•  mutual authentication

M1. {K ab }K
A→ B:
b
M1: Bob sees key Kab

M2. B → A : {N b }K M2: After receiving it, Bob says he saw Kab

ab

M3. A → B : {C ,{N } }
A b K a−1
K ab
M3: After receiving it, Alice says she saw Nb

In the protocol there is no link between A and key Kab

SNCS Ban logic 32

 SSL (old version)

Adversary Mallet plays an MIM attack and impersonates A

with respect to B

M1′ : {K am }K m
M1: {K mb }K b

M2′ : { N b }K M2 : { N b }K
A M B
am

{C ,{N } }
mb

M3′ : A b K a−1
K am
M3 : { C A , {N b }K −1
a
} K mb

After M3, Bob believes he is

talking to Alice

SNCS Ban logic 33

SSL (old versione)

!  The attack may be avoided by modifying M3 as follows

M3 A → B : {C ,{A, B, K
A ab , N b }K −1
a
}
K ab

after receiving Nb, Alice says that Kab is a good key to

communicate with Bob

• Important
•  It’s necessary to introduce identifiers A and B in message M3
because, otherwise, the attack would be still possible by
setting Kam = Kbm

SNCS Ban logic 34

 Sign encrypted data
Principle 7.
•  If an entity signs an encrypted message, it is not possible to infer that
such an entity knows the message contents
•  In contrast, if an entity signs a message Aand
→ the
B {encrypts
X }K ,{h (it,X then
)}Ka−1 it is
possible to infer that the entity knows the message contents
b

Esempio: X.509

{
A → B : A, Ta , N a , B, X a , {Ya }K
b
}
K a−1

The message contains no proof that the sender (Alice)

knows Ya

SNCS Ban logic 35

On hash functions
For efficiency, we sign the hash of a message rather than the message
itself

A→ B: { X }K ,{h ( X )}K
b
−1
a

•  The message does not contain any proof that the signer Alice actually
knows X
•  However, the signer Alice expects that the receiver Bob behaves as if
the sender Bob knew the message
•  Therefore, unless the signer Alice is unwary*, signing the hash is
equivalent to sign the message

* Metaphore: a manager who signs without reading

SNCS Ban logic 36

 Postulates for hash
functions
P |≡ Q |∼ h ( X ) , P  X
P |≡ Q |∼ X

The postulate can be generalized to composite messages

P |≡ Q |∼ h ( X 1 ,, X n ) , P  X 1 ,, P  X n
P |≡ Q |∼ ( X 1 ,, X n )

Notice that P may receive Xi from different channels in different moments

SNCS Ban logic 37

The GSM case

Real protocol
M1. C → S : C •  ρ random challenge generated by
S
M2. C ← S : ρ
•  <σ, K> = h(KC, ρ)
M3. C → S : σ

Assumptions Idealized protocol

Kc Kc K
S |≡ C ↔ S C |≡ S ↔ C M3. C → S : C ↔ S, ρ
Kc
S |≡ #( ρ )
Results
K
S |≡ C |≡ S ↔ C
SNCS Ban logic 38
 Predictable nonces
Principle 8. A predictable quantity can be used as a nonce in a
challenge-response protocol. In such a case, the nonce must be
protected by a replay attack

Example: Alice receives a time stamp from a Time Server

(ex. Alice uses the time stam to synchronize her clock)

M1 A→S A, N a •  Na: predictable nonce

M2 S → A {Ts , N a }K •  (M2): After receiving Na, S said Ts

as

Ipotesi Risultati
K as
A|≡ S ↔ A A|≡ S |∼ Ts
A|≡ S ⇒ Ts A|≡ S |≡ Ts
A|≡ # ( N a ) A|≡ Ts

SNCS Ban logic 39

Predictable nonces
An attack
M predicts the next value of N a
M1 M →S A, N a
M2 S → M {T , N }
s a K as
(S receives M2 at time Ts )

At time TS′ > TS ,Alice initiates a protocol instance

M1 A → S[M ] A, N a
Alice is led to believe that the
M 2 S[M ] → A {T , N }
s a K as
current time is Ts and not Ts´

Since Na is predictable then it must be protected

M1 A→S A, {N a }K
as

M2 S → A {T ,{N } }
s a K as K as

SNCS Ban logic 40

 Nonce: timestamp
Principle 9. If freshness is guaranteed by time stamp, then the difference
between the local clock and that of other machines must be largely smaller
than the message validity. Furthermore, the clock synchronization
mechanisms is part of the Trusted Computing Base (TCB)

Example
•  Kerberos. If the server clock can be set back, then authenticators can
be reused
•  Kerberos. If the server clock can be set ahead, then it is possible to
generate post-dated authenticators

SNCS Ban logic 41

On coding messages
Principle 10. The contents of a messafe must allow us to determine: (i)
the protocol the message belongs to, (ii) the execution instance of the
protocol, (iii) the number of the message within the protocol

Example Needham-Schroeder

M 4 B → A EKab ( N b ) Nb – 1 distinguishes challenge from

M5 A→B EKab ( Nb − 1) response

It would be more clear

M 4 B → A EKab ( N-S Message 4, Nb )

M5 A → B EKab ( N-S Message 5, Nb )

SNCS Ban logic 42