Security Protocols
Luca Viganò
Institut für Informatik
Albert-Ludwigs-Universität Freiburg
www.informatik.uni-freiburg.de/~luca
01.03.02
Luca Viganò
1
Roadmap
• Introduction.
– Definition and purpose of security protocols.
– Security protocols for communication.
• Security protocols in detail.
–
–
–
–
–
–
Terminology.
Types of protocols.
Some basic authentication protocols.
Attack examples.
Design principles.
Formal analysis.
An Introduction to IT-Security
01.03.02
Luca Viganò
2
Networks are insecure
• The only really secure computer is an isolated, turned off, computer.
• Spies/attackers are everywhere!
Non-encrypted communication allows for
–
–
–
–
(passive & active) attacks on messages,
hijacking of connections,
routing spoofing,
...
What I’m talking about comes down to a more basic philosophical principle:
Don’t trust nobody.
(David Mamet, House of Games)
• Solution: use security protocols based on cryptographic algorithms.
An Introduction to IT-Security
01.03.02
Luca Viganò
3
A definition
Protocol: a series of steps, involving two or more agents, designed to accomplish a
task.
• Series of steps: a fixed sequence of actions (computing, sending, receiving, ...),
from start to finish.
• Designed to accomplish a task: the protocol must achieve something specific.
• Involving two or more agents:
– At least two agents are required to complete the protocol.
– One agent alone does not make a protocol, e.g.
∗ he can perform a series of steps to accomplish a task like baking a cake,
∗ but someone else must eat the cake to make it a protocol.
An Introduction to IT-Security
01.03.02
Luca Viganò
4
The purpose of protocols
• In daily life: informal protocols for almost everything.
– Ordering goods on the phone, playing poker, voting in an election, ...
– Everyone knows how to use them, and they work reasonably well.
• In computer networks: formal protocols.
– Not ‘face-to-face’, hence security is in danger.
– Formalization: examine ways in which dishonest agents can subvert
protocols, and develop ‘immune’ protocols.
– Also: abstraction (platform-independence).
An Introduction to IT-Security
01.03.02
Luca Viganò
5
Ground rules
• Everyone involved in the protocol must
– know the protocol and all the steps to follow in advance;
– agree to follow it.
• The protocol must be
– unambiguous (each step must be well-defined);
– complete (there must be a specified action for every possible situation).
• It must be impossible to do more or learn more than what is specified in the
protocol.
An Introduction to IT-Security
01.03.02
Luca Viganò
6
Security protocols for communication
• Goal: secure communication between agents (users, computers, processes, ...).
–
–
–
–
Secrecy (confidentiality): who can receive/read messages?
Authentication: who is talking?
Key-distribution: distribute keys for private or authenticated communication.
Integrity, non-repudiation, accountability, anonymity, unobservability, ...
• Small programs (often less than 10 messages).
• Based on, but ‘independent’ of, cryptographic algorithms, which are
– well-known and well-established,
– negotiated (each side communicates its preferred ones),
– replaced if ‘broken’.
An Introduction to IT-Security
01.03.02
Luca Viganò
7
Security protocols for communication (cont.)
• Agents cooperate by exchanging messages.
Luca → Bank : {Pay DM 100 to Uwe Jendricke}K −1
Luca
• Agents use the messages received, together with modeling assumptions about
the behavior of other agents, to make decisions on how to act.
– Should the Bank carry out the money transfer?
– Should Luca believe that everything is alright after he receives
Bank → Luca : {We payed DM 100 to Uwe Jendricke}K −1 ?
Bank
• Decisions depend on what can be assumed of messages they received, e.g.
– receiver wants to be sure that a received message has been created recently
by the agent claiming to be sender;
– agents must be able to detect when a message has been created or modified
by a malicious agent;
– agents must be able to detect when a message was issued some time ago (or
for a different purpose) and is currently being replayed.
An Introduction to IT-Security
01.03.02
Luca Viganò
8
Threats and attacks
• Perfect encryption is usually assumed (no codebreaking).
• Different types of attackers and attacks.
– Active attacker: assumed to have complete
∗ access to communication between agents,
∗ knowledge of the protocols and of the cryptographic algorithms employed.
– Passive attacker: mainly eavesdropping.
– Cheater: one of the agents involved in the protocol.
– Careless and compromized agents.
A friend’s just an enemy in disguise. You can’t trust nobody.
(Charles Dickens, Oliver Twist)
• Formal analysis and design: model, verify and improve protocols.
An Introduction to IT-Security
01.03.02
Luca Viganò
9
Roadmap
• Introduction.
– Definition and purpose of security protocols.
– Security protocols for communication.
• Security protocols in detail.
–
–
–
–
–
–
Terminology.
Types of protocols.
Some basic authentication protocols.
Attack examples.
Design principles.
Formal analysis.
An Introduction to IT-Security
01.03.02
Luca Viganò
10
The players (Dramatis personae)
• Agents, participants, principals, users, ...
• Honest:
–
–
–
–
Alice and Bob (and Carol and Dave).
Trent: Trusted arbitrator.
Server: Trusted server (a.k.a. Simon).
...
• Dishonest:
– Eve: Eavesdropper.
– Mallory: Malicious active attacker.
– ...
An Introduction to IT-Security
01.03.02
Luca Viganò
11
Types of protocols
• Arbitrated: a disinterested arbitrator is trusted to complete the protocol.
• Adjudicated: additional arbitrated sub-protocol is executed in case of dispute.
• Self-enforcing: protocol constructed so that there cannot be any disputes.
An Introduction to IT-Security
01.03.02
Luca Viganò
12
Arbitrated protocols
• Alice and Bob trust the disinterested arbitrator Trent to complete the protocol.
Trent
Alice
Bob
• Real world: Trent is lawyer (banker, notary public, ...) who will do his part and
is paid in any case.
• Problems: arbitrator
–
–
–
–
–
is faceless,
is expensive,
causes delay,
is a bottleneck,
is a vulnerable point in the network.
An Introduction to IT-Security
01.03.02
Luca Viganò
13
Adjudicated protocols
• An arbitrated protocol can be divided into two subprotocols:
– non-arbitrated protocol executed (every time) to complete protocol,
– arbitrated protocol executed in case of dispute with adjudicator (e.g. judge).
Alice
Bob
Trent
(After the fact)
Evidence
Evidence
• Real world: contract signing.
1.1.
1.2.
1.3.
2.1.
2.2.
2.3.
Alice and Bob negotiate the terms of the contract.
Alice signs the contract.
Bob signs the contract.
Alice and Bob appear before a judge.
Alice and Bob each present their evidence.
The judge rules on the evidence.
An Introduction to IT-Security
01.03.02
Luca Viganò
14
Self-enforcing protocols
• Constructed so that there cannot be any disputes.
• If Bob tries to cheat, Alice immediately detects this and stops the protocol.
Alice
Bob
• Best type of protocol, but there is not a self-enforcing protocol for every
situation.
An Introduction to IT-Security
01.03.02
Luca Viganò
15
Some basic protocols
We have already seen simple protocol sketches:
• Communication using symmetric cryptography:
–
–
–
–
Alice and Bob agree on a cryptosystem and on a key.
Alice encrypts plaintext message using encryption algorithm and key.
Alice send ciphertext to Bob.
Bob decrypts ciphertext using the same algorithm and key.
• Communication using asymmetric cryptography:
–
–
–
–
Alice and Bob agree on a public-key cryptosystem.
Bob makes his public key KB available to Alice.
Alice encrypts message using KB and sends it to Bob.
Bob decrypts message with KB−1.
An Introduction to IT-Security
01.03.02
Luca Viganò
16
Authentication protocols
• A sequence of message exchanges between agents that
– either distributes secrets to some of the agents
– or allows the use of some secret to be recognized.
• At the end of the protocol, the agents involved may deduce certain properties
about the system, e.g.
– only certain agents have access to particular secret information (e.g. keys),
– a particular agent is operational (i.e. currently alive).
• They may then use this information to verify claims about subsequent
communication, e.g.
– a received message encrypted with a newly distributed key must have been
created after distribution of that key and so is timely.
An Introduction to IT-Security
01.03.02
Luca Viganò
17
Some authentication protocols
• SSH: secure remote login & other secure network services.
• SSL: in browsers.
• PGP: email.
• KERBEROS: secure remote login.
• SET: secure electronic transactions.
• And many others, whose name you might not have heard, but which you
perhaps employ every day.
An Introduction to IT-Security
01.03.02
Luca Viganò
18
Building Blocks for Security Protocols
Cryptographic Procedures: Encryption of messages
{{M }KB }K −1 = M
B
(Psuedo-)Random Number Generators: to generate “Nonces”,
e.g. for “Challenge-Response”
Protocols: recipe for exchanging messages
Steps like: A sends B his name together with the message M . The pair
{A, M } is encrypted with B ’s key.
A → B : {A, M }KB
An Introduction to IT-Security
01.03.02
Luca Viganò
19
An Authentication Protocol (Needham-Schroeder)
1. A → B : {A, NA}KB
2. B → A : {NA, NB }KA
3. A → B : {NB }KB
Translation:
“I am Alice and here is a Nonce NA.”
{A, NA} K
B
{NA, NB} K
A
{NB} K
B
“Here is your Nonce NA and I also have one for you.”
“I got it!
It is NB .”
Protocols are typically small and convincing ...and also often wrong!
An Introduction to IT-Security
01.03.02
Luca Viganò
20
Man-in-the-middle Attack
An Introduction to IT-Security
01.03.02
Luca Viganò
21
Attack on Needham-Schroeder (details)
NSPK #1
NSPK #2
{A,NA}KC
{A,NA}KB
{ NA ,NB }K A
{ N B }KC
{ NA ,NB }K A
{ N B }KB
B believes he is speaking with A!
An Introduction to IT-Security
01.03.02
Luca Viganò
22
What went wrong?
• Problem in step 2
B → A : {NA, NB }KA
Agent B should also give his name: {NA, NB , B }KA
• Is the improved version now correct?
?
?
An Introduction to IT-Security
?
?
01.03.02
Luca Viganò
23
The Needham-Schroeder Public-Key Protocol NSPK
M1.
M2.
M3.
M4.
M5.
M6.
M7.
A→S :
S →A:
A→B :
B →S :
S →B :
B →A:
A→B :
A, B
{KB , B }K −1
S
{NA, A}KB
B, A
{KA, A}K −1
S
{NA, NB }KA
{NB }KB
Server
Alice
1
2
4
5
3
6
Bob
7
• Agents: A and B ; certification authority S .
• Pairing: concatenate parts with ‘,’.
• Public keys: KA, KB , KS (initially: A and B hold KS ).
• Private keys: KA−1, KB−1, KS−1.
• Encryption: {X }KA (all can encrypt; only A can decrypt).
• Nonces: NA, NB (random numbers).
An Introduction to IT-Security
01.03.02
Luca Viganò
24
The Needham-Schroeder Public-Key Protocol NSPK (cont.)
M1.
M2.
M3.
M4.
M5.
M6.
M7.
A→S :
S →A:
A→B :
B →S :
S →B :
B →A:
A→B :
A, B
{KB , B }K −1
S
{NA, A}KB
B, A
{KA, A}K −1
S
{NA, NB }KA
{NB }KB
Server
Alice
1
2
4
Bob
5
3
6
7
• (M 1, 2, 4, 5): A and B obtain each other’s public keys.
• (M 3, 6, 7): A and B use keys to communicate secret nonces NA and NB .
• Nonces: challenge—response.
• Only B can recover NA; only A can recover NB .
⇒ A and B are present ‘now’.
⇒ ‘Later’: A and B can use NA and NB for ‘signing’ messages, e.g.
B receives {X , NA}KB ⇒ he deduces A sent X .
An Introduction to IT-Security
01.03.02
Luca Viganò
25
The Needham-Schroeder Public-Key Protocol NSPK (cont.)
• By assuming that A and B already have each other’s keys, we can do without
S and shorten the protocol to:
Alice
M1. A → B : {A, NA}KB
M2. B → A : {NA, NB }KA
M3. A → B : {NB }KB
Bob
1
2
3
• If encryption is not perfect: what happens when private key KB−1 is
compromised?
• But even with the perfect encryption assumption...
• Both versions of the protocol are flawed!
• Two attacks (discovered after many years, using formal methods):
– Replay: record and later re-introduce a (part of a) message.
– Man-in-the-middle: pass messages through to a concurrent session and back.
An Introduction to IT-Security
01.03.02
Luca Viganò
26
A replay attack to NSPK
• Replay (or freshness) attack: record and later re-introduce a (part of a)
message.
• Full NSPK: no guarantee that public keys KB and KA are fresh, i.e. that they
have been created by S as part of the current protocol run.
Server
M2. S → A : {KB , B }K −1
S
M5. S → B : {KA, A}K −1
Alice
1
2
4
5
3
6
Bob
7
S
• If old KB , KA have been compromised and recorded by attacker Mallory, then
Mallory can intercept new messages to S and replay old ones.
⇒ A and B believe that keys are new and use them for subsequent
communication, which can be read by Mallory too.
• Fix: use timestamps, e.g.
M2. S → A : {KB , B , T }K −1
S
This requires a secure and accurate (and possibly global) system clock!
An Introduction to IT-Security
01.03.02
Luca Viganò
27
A man-in-the-middle attack to NSPK
• Man-in-the-middle (or parallel sessions) attack: two or more protocol runs are
executed concurrently and messages from one are used to form messages in
another.
A↔M↔B
• NSPK: Mallory M can start a new protocol run with B pretending to be A.
M1. A → M : {N1, A}KM
M1’. M(A) → B : {N1, A}KB
M2’. B → M(A) : {N1, N2}KA
M2. M → A : {N1, N2}KA
M3. A → M : {N2}KM
M3’. M(A) → B : {N2}KB
• B believes he is talking to A!
• Fix: mention names explicitly in second message, e.g.
M2’. B → M(A) : {N1, N2, B }KA
An Introduction to IT-Security
01.03.02
Luca Viganò
28
Types of attack
• Replay (or freshness) attack: record and later re-introduce a (part of a)
message.
• Man-in-the-middle (or parallel sessions) attack: A ↔ M ↔ B .
• Masquerading attack: pretend to be another agent, e.g.
– forge source address,
– binding attack: M convinces other agents that A’s public key is KM.
• Type flaw attack: substitute a different type of message field,
– e.g. a key vs. a nonce.
• Other types: implementation-dependent, cryptanalysis, ...
An Introduction to IT-Security
01.03.02
Luca Viganò
29
Type flaw attack
• A message consists of a sequence of components each with some value.
– The name of an agent, the value of a nonce, the value of a key, ...
• A message is represented concretely as a sequence of bits.
• Type flaw:
A→B : M
Receiver B accepts M as valid but imposes a different interpretation on the bit
sequence than sender A.
• Example of type flaw attack: Otway-Rees Protocol.
An Introduction to IT-Security
01.03.02
Luca Viganò
30
The Otway-Rees protocol
M1. A → B : I , A, B , {NA, I , A, B }KAS
M2. B → S :
I , A, B , {NA, I , A, B }KAS , {NB , I , A, B }KBS
M3. S → B :
I , {NA, KAB }KAS , {NB , KAB }KBS
M4. B → A : I , {NA, KAB }KAS
• Symmetric keys KAS and KBS already known.
• I is protocol run identifier.
• Goals: A and B are convinced of each other’s identity, and receive from S a
symmetric key KAB for future communication.
An Introduction to IT-Security
01.03.02
Luca Viganò
31
Type flaw attack on the Otway-Rees protocol
M1.
M2.
M3.
M4.
A→B :
B →S :
S →B :
B →A:
I , A, B , {NA, I , A, B }KAS
I , A, B , {NA, I , A, B }KAS , {NB , I , A, B }KBS
I , {NA, KAB }KAS , {NB , KAB }KBS
I , {NA, KAB }KAS
• After initiating the protocol, A expects to receive a message containing her
nonce NA of M1 and the new session key KAB .
• If I is 32 bits, A and B are each 16 bits, and KAB is 64 bits, then Mallory can
– intercept M1 and
– replay the encrypted component of M1 as the encrypted component of M4:
M1. A → M(B ) : I , A, B , {NA, I , A, B }KAS
...
M4. M(B ) → A : I , {NA, I , A, B }KAS
⇒ A checks for the presence of NA and is fooled into accepting I , A, B as the
new session key.
An Introduction to IT-Security
01.03.02
Luca Viganò
32
Type flaw attack on the Otway-Rees protocol (cont.)
M1. A → M(B ) : I , A, B , {NA, I , A, B }KAS
...
M4. M(B ) → A : I , {NA, I , A, B }KAS
A checks for the presence of NA and is fooled into accepting I , A, B as the new
session key.
Graphically:
I
A
B
Intended
interpretation
of sender
1001101100111100 11011011 00010010
Encryption
Ciphertext
Decryption
1001101100111100 11011011 00010010
KAB
An Introduction to IT-Security
Interpretation
of receiver
01.03.02
Luca Viganò
33
Type flaw attack on the Otway-Rees protocol (cont.)
M1.
M2.
M3.
M4.
A→B :
B →S :
S →B :
B →A:
I , A, B , {NA, I , A, B }KAS
I , A, B , {NA, I , A, B }KAS , {NB , I , A, B }KBS
I , {NA, KAB }KAS , {NB , KAB }KBS
I , {NA, KAB }KAS
• Similarly, Mallory can play the role of S in M2 and M3 by replaying the
encrypted components of M2 back to B .
• The attack then is:
M1.
M2.
M3.
M4.
A→B :
B → M(S ) :
M(S ) → B :
B →A:
I , A, B , {NA, I , A, B }KAS
I , A, B , {NA, I , A, B }KAS , {NB , I , A, B }KBS
I , {NA, I , A, B }KAS , {NB , I , A, B }KBS
I , {NA, I , A, B }KAS
⇒ M can now listen to the conversation between A and B using the key I , A, B .
• Fix: types should be clear and ‘unique’.
An Introduction to IT-Security
01.03.02
Luca Viganò
34
Prudent engineering: design principles
• Design principles:
–
–
–
–
–
–
–
Every message should say what it means.
Specify clearly conditions for a message to be acted on.
Mention names explicitly if they are essential to the meaning.
Be clear as to why encryption is being done.
Be clear on what properties you are assuming.
Beware of clock variations (for timestamps).
etc.
• Good advice, but
– Is the protocol guaranteed to be secure then?
– Is it optimal and/or minimal then?
∗ Optimization vs. making everything explicit.
∗ Size of messages vs. number of messages.
– Have you considered all types of attacks?
– etc.
An Introduction to IT-Security
01.03.02
Luca Viganò
35
Formal Models
Goal: formally model protocols and their properties and provide a mathematically
sound means for reasoning about these models.
Basis: suitable abstraction of protocols and information flow
⇒
An Introduction to IT-Security
01.03.02
Luca Viganò
36
Interleaving Trace Models
• Formal model (Paulson): model possible communication events
A → B : M1
C → D : P1
B → A : M2
D → C : P2
..
• A trace is a sequence of events
Interleaving of (partial) runs of the protocol and messages from the attacker
• Trace-based interleaving semantics: a protocol is modeled as a set of traces
Those traces that can arise from parallel, partial runs of the protocol
interleaved with messages from the attacker.
• Attacker model: the attacker controls the network.
He can read, intercept, and create messages. Cryptography, however, is perfect.
An Introduction to IT-Security
01.03.02
Luca Viganò
37
Foundations for a Formal Model
• Inductive definitions are common in mathematics/computer science.
• Example: the set of binary trees T is the smallest set such that:
1. nil ∈ T
2. If t1 ∈ T and t2 ∈ T , then node(t1, t2) ∈ T .
• Inductive definitions can be fully formalized in logic.
– They can be given by a set of Horn Clauses (as above)
or as the least fixedpoint of a monotone function over some universe.
– Formalization possible in set-theory or higher-order logic
– Reasoning principle: induction. E.g., structural induction over trees.
An Introduction to IT-Security
01.03.02
Luca Viganò
38
Modeling: Protocol as an Inductively Defined Set
• Set P formalizes protocol steps
t ∈P
NA 6∈ used t
t, A→B : {A,NA}K ∈ P
hi ∈ P
t ∈P
B
NB 6∈ used t
A0→B : {A,NA}K ∈ t
B
t, B →A: {NA,NB }K ∈ P
A
t ∈P
A→B : {A,NA}K ∈ t
B 0→A: {NA,NB }K ∈ t
B
A
t, A→B : {NB }K ∈ P
B
• as well as attacker model
t ∈P
An Introduction to IT-Security
X ∈ synthesize (analyze (sees t))
t, Spy→B : X ∈ P
01.03.02
Luca Viganò
39
Model Provides a Basis for Interactive Verification
Formalization of inductive definition in HOL ; proof by induction.
Authentication for A: If (1) A received message 2 and (2) used NA to start a
run, then B sent message 2.
For all t ∈ P ,
(1) B 0 → A : {NA, NB }KA ∈ t and
(2) A → B : {A, NA}KB ∈ t
then
B → A : {NA, NB }KA ∈ t
if
Secrecy: Spy cannot discover NB .
(when key’s are not compromised)
For all t ∈ P , if B → A : {NA, NB }KA ∈ t
An Introduction to IT-Security
then NB 6∈ analyze(sees t)
01.03.02
Luca Viganò
40
Interactive Verification — Some Facts/Statistics
• Verification approach due to Larry Paulson, Cambridge.
– Proofs with Isabelle/HOL system
• Dozens of protocols analyzed: Internet protocol TLS, SET, Kerberos IV, ...
• Flaws come out in terms of unprovable goals
• Typical protocol requires a few days to construct a proof script
Scripts machine-checked typically in a few minutes
• However, there are other, complementary, ways to exploit this model!
An Introduction to IT-Security
01.03.02
Luca Viganò
41
An Alternative: Lazy Infinite-State Analysis
• We use Paulson’s model as a basis for automatically detecting attacks.
• Key idea: formalize model using lazy data-structures.
...
Says A->B ...
Says A->Spy ...
...
Says Spy->A ...
Says Spy->B ...
...
...
...
Says A->Spy ...
Says Spy->A ...
...
Says A->Spy ...
Says B->A ...
...
• Compute with model (finite representation of infinite data).
Demand driven transformation and search of inductive definition.
An Introduction to IT-Security
01.03.02
Luca Viganò
42
Technical Details — Lazy Data-Types and Haskell
• Lazy constructors build data without evaluating their arguments
from n = n : from (n+1)
nat = from 0
• This can be used to represent and to compute with infinite sets
[(x,
x*x) | x <- nat, x > 100]
Result: [(101,10201),(102,10404),(103,10609), ...
]
• Haskell is a higher-order strongly typed lazy programming language
– Data-types and set comprehension support high-level modeling
– Good interpreters and compilers available
An Introduction to IT-Security
01.03.02
Luca Viganò
43
Technical Details — Formalizing the Model
• Agents, messages, and events modeled using data-types
data Agent = Alice | Bob | Spy
data Msg = Agent Agent | Nonce Int | Pair Msg Msg | Crypt Agent Msg
data Event = Says Agent Agent Msg
• Cryptographic details abstracted away: public key and name identified
A → B : {A, NA}KB
An Introduction to IT-Security
;
Says A B (Crypt B (Agent A) (Nonce 17))
01.03.02
Luca Viganò
44
Technical Details — Formalizing Rules of ID
• Rule 1
t ∈P
NA 6∈ used t
t, A→B : {A,NA}K ∈ P
;
B
r1 t = [(Says a b (Crypt b (Pair (Agent a) (mkNonce t) )))
| a <- [Alice,Bob,Spy], b <- [Alice,Bob,Spy], a /= b]
• Rule 2
t ∈P
NB 6∈ used t
A0→B : {A,NA}K ∈ t
B
t, B →A: {NA,NB }K ∈ P
;
A
r2 t = [Says b a (Crypt a (Pair (Nonce na) (mkNonce t))) |
Says _ b (Crypt b (Pair (Agent a) (Nonce na) )) <- t]
• Rule 3 similar
An Introduction to IT-Security
01.03.02
Luca Viganò
45
Technical Details — Formalizing the Model (cont.)
Attacker Model
attacker t = [Says Spy a msg | a <- [Alice,Bob],
msg <- synth(analz Spy (sees Spy t))]
analz a hs =
let inj xs = xs
fst xs = [x | Pair x y <- xs]
snd xs = [y | Pair x y <- xs]
decrypt xs = [x | Crypt ag x <- xs, ag == a]
in closure (inj ‘or‘ fst ‘or‘ snd ‘or‘ decrypt) hs
synth hs =
let inj xs = xs
agent _ = [Agent a | a <- [Alice,Bob,Spy]]
crypt xs = [Crypt a x | x <- xs, a <- [Alice,Bob]]
pair xs = [Pair x y | x <- xs, y <- xs]
in (inj ‘or‘ agent ‘or‘ crypt ‘or‘ pair) hs
sees a t = foldr (\x r -> (sees1 x) ‘union‘ r) emptyset tr
where sees1 (Says _ b x) = if a == b || a == Spy then [x] else []
An Introduction to IT-Security
01.03.02
Luca Viganò
46
Technical Details — Formalizing the Model (cont.)
• Inductive definition formalized as infinite tree built from rule applications
data Tree a = Node a [Tree a]
build_tree extension init
= Node init (map (build_tree extension) (extension init))
p =
build_tree ext []
where ext t = map (\x -> ins x t)
((r1 ‘or‘ r2 ‘or‘ r3 ‘or‘ attacker) t)
• Result: lazy executable model (a couple pages of Haskell)
Provides basis for model checking by lazy state-space enumeration
An Introduction to IT-Security
01.03.02
Luca Viganò
47
Technical Details — Model Checking
• State-space exploration: semi-decision procedure to find attack-states
An attack is a predicate formalizing a (safety) property of (finite) traces
• Naive search hopeless!
Tree infinitely deep and very wide
– First ply: all possible starts
A → B : {A, NA}KB
A → Spy : {A, NA}KSpy
...
plus broadcasts from the Spy
Spy → A : A
Spy → A : B
...
– Second ply 214 nodes, third ply 17,529 nodes, ...
An Introduction to IT-Security
01.03.02
Luca Viganò
48
Technical Details — Heuristics
• Use heuristics as tree transducers
Prune branches where spy generates events that honest agents wouldn’t
Spy → A : B or Spy → B : {B , NA}KB
Re-order nodes on each ply, e.g., giving priority to events involving the spy
• Heuristics sound under reasonable protocol implementation assumptions
• Conceptual separation of model, heuristics and search
• Lazy implementation ; data-driven implementation
An Introduction to IT-Security
01.03.02
Luca Viganò
49
Technical Details — Model Checking (cont.)
• Specify attack as predicate on traces (like Paulson):
Authentication for A If (1) A received message 2 and (2) used NA to start a
run, then B sent message 2. Formalized as follows:
AauthenticatesB (t )
≡
SpyattacksA(t )
≡
B 0 → A : {NA, NB }KA ∈ t and
A → B : {A, NA}KB ∈ t
then B → A : {NA, NB }KA ∈ t
¬ AauthenticatesB (t )
if
• Perform iterative deepening search for an attack on the transduced tree
ids pred t = flatten [ idsn n pred t | n <- [0 ..]]
ids attack (prune-and-reorder p)
• Resulting stream is the set of possible attacks.
First element (found at 5th ply) in 13 CPU seconds is man-in-the-middle attack.
An Introduction to IT-Security
01.03.02
Luca Viganò
50
Conclusions and Prospects
• Verification methods typically one of several kinds
Model checking: based on explicit state enumeration, temporal logics, etc.
Specialized logics or theories: e.g., direct theorem proving.
• Lazy modeling exploits complementary aspects of both
Models based on inductive definitions can be used for both inductive theorem
proving and automatic, infinite-state model checking.
• On-the-fly model checking for free!
– data is generated and heuristics applied on demand.
– runtimes are acceptable!
An Introduction to IT-Security
01.03.02
Luca Viganò
51
Current and Future Work
• AVISS Project
Input
Output (<1 Second)
PROTOCOL NSPK;
Identifiers
A, B: user;
Na, Nb: nonce;
Ka, Kb: public_key;
Messages
1. A -> B: {A,Na}Kb
2. B -> A: {Na,Nb}Ka
3. A -> B: {Nb}Kb
Intruder_knowledge Spy, b, ka, kb, kspy;
Goal correspondence_between A B;
A -> Spy: {A,Na}Kspy
Spy -> B: {A,Na}Kb
B -> A: {Na,Nb}Ka
A -> Spy: {Nb}Kspy
Spy -> B {Nb}Kb
• Many interesting research problems. Research positions available.
An Introduction to IT-Security
01.03.02
Luca Viganò
52
Summary
• Networks are insecure!
⇒ avoid non-encrypted communication.
Let every eye negotiate for itself
And trust no agent; for beauty is a witch
Against whose charms faith melteth into blood.
(William Shakespeare, Much ado about nothing )
• Use security (cryptographic) protocols based on cryptographic algorithms for
– authentication, secrecy, integrity, ...
• and
– design protocols following ‘prudent’ principles, and
– use formal methods for protocol analysis.
An Introduction to IT-Security
01.03.02
Luca Viganò
53
Bibliography
• Bruce Schneier. Applied Cryptography. John Wiley & Sons, New York, 1996.
• Dieter Gollmann. Computer Security. Wiley, 2000.
• Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone. Handbook of Applied
Cryptography. CRC Press, 1996.
Available online at http://cacr.math.uwaterloo.ca/hac/
• Arthur E. Hutt, Seymour Bosworth, and Douglas B. Hoyt. Computer Security Handbook. John
Wiley & Sons, 1995.
• John Clark and Jeremy Jacob: A survey of authentication protocol literature, 1997.
http://www.cs.york.ac.uk/~jac/
• Martı́n Abadi and Roger Needham: Prudent Engineering Practice for Cryptographic Protocols.
IEEE Transactions on Software Engineering, 22(1):2-15, January 1996.
See http://www.counterpane.com/biblio/author-A.html
• Martı́n Abadi: Explicit Communication Revisited: Two new attacks on Authentication
Protocols.
Available at http://www.research.digital.com/SRC/staff/ma/bib.html
• About SSH: http://www.ssh.fi/tech/crypto/
• L. C. Paulson. The Inductive Approach to Verifying Cryptographic Protocols. J. Computer
Security 6 (1998).
An Introduction to IT-Security
01.03.02
Luca Viganò
54
• D. Basin. Lazy Infinite-State Analysis of Security Protocols. Secure Networking — CQRE
[Secure] ’99, LNCS 1740. 1999.
• D. Basin and G. Denker, Maude versus Haskell: A Comparison in Security Protocol Analysis,,
International Workshop on Rewriting Logic and Applications, Electronic Lecture Notes on
Theoretical Computer Science, Volume 36, 2001.
• The AVISS project:
www.informatik.uni-freiburg.de/~softech/research/projects/aviss
An Introduction to IT-Security
01.03.02
Luca Viganò
55
Another example: SSH protocol
• Secure remote login & other secure services over an insecure network.
• Protocols with similar goals: AKA (Anarchistic Key Authorisation) and SSL
(Secure Sockets Layer).
• Some (older versions) of these protocols can be attacked, e.g.
– clients/servers can be impersonated by attacker.
An Introduction to IT-Security
01.03.02
Luca Viganò
56
SSH
• A protocol for secure remote login and other secure network services over an
insecure network.
• Intended as replacement for rlogin, rsh, rcp, telnet, ftp,...
• Provides (via slogin, scp, ssh) secure channels for
–
–
–
–
–
strong authentication and secure communications,
logging into another computer over a network,
executing commands onto another machine,
copying files from one machine to another,
etc ...
• Attempts to be ‘easier’ to use than its insecure counterparts.
• Is widely accepted and used (Unix/Linux, Windows, Macintosh).
An Introduction to IT-Security
01.03.02
Luca Viganò
57
/home/luca : man ssh
SSH
SSH(1)
NAME
ssh - secure shell client (remote login program)
SYNOPSIS
ssh [-l login_name] hostname [command]
...
DESCRIPTION
Ssh (Secure Shell) a program for LOGGING INTO A REMOTE
MACHINE AND FOR EXECUTING COMMANDS IN A REMOTE MACHINE. It
is intended to REPLACE RLOGIN AND RSH, and PROVIDE SECURE
ENCRYPTED COMMUNICATIONS BETWEEN TWO UNTRUSTED HOSTS OVER AN
INSECURE NETWORK.
X11 CONNECTIONS and ARBITRARY TCP/IP
forwarded over the secure channel.
ports
can also be
SSH CONNECTS AND LOGS INTO THE SPECIFIED HOSTNAME.
THE USER MUST PROVE HIS/HER IDENTITY TO THE REMOTE MACHINE
using one of several methods.
...
An Introduction to IT-Security
01.03.02
Luca Viganò
58
/home/luca : ssh
Usage: ssh [options] host [command]
Options:
-l user
LOG IN USING THIS USER NAME.
-a
Disable authentication agent forwarding.
-x
DISABLE X11 CONNECTION FORWARDING.
-i file
Identity for RSA authentication (default: ~/.ssh/identity).
-c cipher
SELECT ENCRYPTION ALGORITHM: ‘‘idea’’, ‘‘blowfish’’, ‘‘3des’’
-p port
Connect to this port. Server must be on the same port.
-P
Don’t use privileged source port.
-L listen-port:host:port
Forward local port to remote address
-R listen-port:host:port
Forward remote port to local address
These cause ssh to listen for connections on a port, and
forward them to the other side by connecting to host:port.
-C
Enable compression.
...
An Introduction to IT-Security
01.03.02
Luca Viganò
59
SSH: Protocol Architecture
3 major components (sub-protocols)
• TLP: Transport Layer Protocol.
– Runs (typically) over a TCP/IP connection.
– Provides server authentication, confidentiality and integrity.
– Computes unique session identifier.
• UAP: User Authentication Protocol.
– Runs over TLP.
– Authenticates client to server.
• CP: Connection Protocol.
– Runs over UAP.
– Runs inside encrypted tunnel ⇒ firewalls cannot examine traffic.
– Provides interactive login sessions, remote command execution, forwarded
TCP/IP connections, forwarded X11 connections, ...
An Introduction to IT-Security
01.03.02
Luca Viganò
60
An attack on SSH (I)
• Old, not deployed version of SSH can be attacked.
• Client authentication using public-key cryptography.
– Goal: establish K as session key for subsequent communication A ←→ B .
M1.
M2.
M3.
M4.
M5.
A→B :
B →A:
B →A:
A→B :
A→B :
NA
NB
KBh , KBs
{{hash(previous msgs), K }KBs }KBh
{A, KA, {hash(A, NA, NB )}K −1 }K 0
A
–
–
–
–
KBh long-term host public key (⇒ A checks in database).
KBs short-term (∼ 1 hour) ‘server’ public key.
One-way hash function: variable-length input ; fixed-length output.
K 0 derived from K , NA and NB .
An Introduction to IT-Security
01.03.02
Luca Viganò
61
An attack on SSH (II)
• Basic weakness: A’s signed statement
{hash(A, NA, NB )}K −1
A
does not contain enough information explicitly.
• Intended: K , NA and NB can be used as basis for session between A and B .
• However: no trace of B or K in statement.
⇒ Attack: malicious server B can impersonate client A in session with server C .
• Similar attacks on AKA and SSL (see Abadi’s papers).
An Introduction to IT-Security
01.03.02
Luca Viganò
62
An attack on SSH (III)
M1.
M1’.
M2’.
M2.
M3’.
M3.
M4.
M4’.
M5.
M5’.
A→B :
B →C :
C →B :
B →A:
C →B :
B →A:
A→B :
B →C :
A→B :
B →C :
NA
NA
NC
NC
KCh , KCs
KBh , KBs
{{hash(previous msgs), K }KBs }KBh
{{hash(previous msgs’), K }KCs }KCh
{A, KA, {hash(A, NA, NC )}K −1 }K 0
A
{A, KA, {hash(A, NA, NC )}K −1 }K 0
A
• C believes he has started a session with A using K , while in fact B has K as
well (and A cannot notice any immediate errors).
• Solution (in new versions of SSH): A must sign additional fields:
– identifier for B (name, certificate, public keys),
– identifier for session key (e.g. hash of key).
An Introduction to IT-Security
01.03.02
Luca Viganò
63
Exercises
1. What is the problem with the following key-distribution protocol?
M1.
A → B : {NA, KAB }K −1
A
M2.
B → A : {NA}KAB
2. Describe the following protocol, complete and describe the attack, and find a fix.
M1.1. A → M(S ) : A, B , NA
M1. A → S : A, B , NA
M2.1. M(A) → S : ...
M2. S → A : S , {S , A, NA, KB }K −1
M2.2. S → M(A) : ...
S
M1.2. M(S ) → A : ...
3. Describe the following Needham-Schroeder Shared Key Protocol, find a freshness attack upon
it, and find a fix to the attack.
M1.
M2.
M3.
M4.
M5.
A→S :
S →A:
A→B :
B →A:
A→B :
A, B , N1
{N1, B , KAB , {KAB , A}KBS }KAS
{KAB , A}KBS
{N2}KAB
{N2 − 1}KAB
4. Describe the following one-way authentication protocol, attack it (hint: parallel sessions), and
find a fix.
M1. A → B : {NA}KAB
M2. B → A : {NA + 1}KAB
An Introduction to IT-Security
01.03.02
Luca Viganò
64
Solutions
1. Everyone can decipher M1 by using A’s public key KA!
M1. A → B : {NA, KAB }K −1
A
M2. B → A : {NA}KAB
2. The protocol admits a binding attack:
M1. A → S : A, B , NA
M2. S → A : S , {S , A, NA, KB }K −1
S
M1.1.
M2.1.
M2.2.
M1.2.
A → M(S ) :
M(A) → S :
S → M(A) :
M(S ) → A :
A, B , NA
A, M, NA
S , {S , A, NA, KM}K −1
S
S , {S , A, NA, KM}K −1
S
Fix: include the name of B in M2.
M2. S → A : S , {S , A, NA, B , KB }K −1
S
An Introduction to IT-Security
01.03.02
Luca Viganò
65
Solutions
3. The Needham-Schroeder Shared Key Protocol admits a freshness attack: there
is no guarantee that M3. was created by S as part of the current protocol run!
0
Suppose that a previously distributed key KAB
has been compromised and is
known to attacker M, who monitored the network when the corresponding
protocol run was executed and recorded message
0
M3’. A → B : {KAB
, A}KBS
0
M can now fool B into accepting the key KAB
as new by:
M1.
M2.
M3.
M4.
A→S :
S →A:
A→B :
B →A:
M5.
A → B : {N2 − 1}KAB
A, B , N1
{N1, B , KAB , {KAB , A}KBS }KAS
{KAB , A}KBS
{N2}KAB
M3.
M4.
0
M(A) → B : {KAB
, A}KBS
B → M(A) : {N2}K 0
M5.
M(A) → B : {N2 − 1}K 0
AB
AB
Fix: add timestamps in relevant messages (or, as Needham-Schroeder
themselves suggested, add an extra handshake at the beginning of the
protocol).
An Introduction to IT-Security
01.03.02
Luca Viganò
66
Solutions
4. The protocol admits a parallel sessions attack (with ‘oracle’):
M1. A → B : {NA}KAB
M2. B → A : {NA + 1}KAB
M1.1.
M2.1.
M2.2.
M1.2.
A → M(B ) : {NA}KAB
M(B ) → A : {NA}KAB
A → M(B ) : {NA + 1}KAB
M(B ) → A : {NA + 1}KAB
• A is forced to do work on behalf of the attacker: A acts as an ‘oracle’
against herself, because she provides the correct answer to her own question.
• At the very least, A believes then that B is operational, while B may no
longer exist.
• Simple fix: add A’s name to message M1.
M1. A → B : {NA, A}KAB
An Introduction to IT-Security
01.03.02