Challenges in Protocol
Design and Analysis
Dieter Gollmann
TU Hamburg-Harburg
diego@tuhh.de
1
Background
 “The design and analysis of security
protocols is difficult and error-prone”
 Why is this the case – and is it true?
 Complexity of protocols?
 Complexity of attacks?
 Complexity of analysis?
 Specification of the problem at hand?
2
Agenda
 History: quick look at Dolev-Yao model
 History: Lowe’s attack revisited
 Robustness?
 Mobile IPv6
 Data integrity without authentication?
 Complex attacks
 Summary & Conclusions
3
Protocol analysis – the task
 Given security requirements
 desired security properties
 intended (communications) environment
 Given a security protocol
 Does the protocol meet the
requirements?
4
The environment – Dolev-Yao



For the sake of generality, the adversary is
often put in control of all communications
Known as “analysis in the Dolev-Yao model”
Model makes two independent assumptions:
 The adversary can observe and manipulate all
messages exchanged in a protocol run and can
itself start protocol runs
 Cryptography is “perfect”: adversary only exploits
algebraic properties of cryptographic operators
and interactions between protocol messages
5
A comment

The first assumption was already stated by
Needham and Schroeder [1978]:
We assume that the intruder can interpose a
computer in 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.
6
Default environment



7
Analysis in a general setting need not lead to
higher security; we may reject protocols that
exploit features of their intended environment
Out of scope attacks are useful side
information but do not “break” a protocol
For any approach to protocol analysis, query
how different environments can be modelled
Lowe’s attack – the protocol


Needham-Schroeder public key protocol
Goal: derive shared session key from Na, Nb
1.
2.
3.


8
AB: eKb(Na,A)
BA: eKa(Nb,Na)
AB: eKb(Nb)
Only B can decrypt the first message and
form a reply containing the challenge Na
Only A can decrypt the second message and
form a reply containing the challenge Nb
Fact file
 In the 1970s principals were honest:
 Needham: “If they were people they were
honest people; if they were programs they
were correct programs”
 Formal analysis in the BAN logic (1990):
A believes B believes Nb is a
secret shared by A and B
9
Lowe’s analysis (1995)



Protocol modelled in CSP and analyzed with
the model checker FDR
Environment: adversary can be a regular
protocol participant
Goal phrased as correspondence properties:
 Initiator commits to a run with B when receiving a
reply eKa(Nb,Na) containing the challenge Na
 Responder commits to a run with A only if the
message eKb(Na,A) came from A
10
Lowe’s attack:
A
eKe(Na,A)
eKb(Na,A)
eKa(Nb,Na)
eKa(Nb,Na)
eKe(Nb)
Proof: Initiator A
authenticates
responder E
11
E
eKb(Nb)
B
Attack: Responder B
can be tricked by a
masquerading initiator
Why is there proof and attack?

Changing assumptions about the environment
 Attacks on a closed system by an outsider
 Insider attacks in an open system

Changing assumptions about protocol goals
 Key establishment
 “Entity authentication”
12
Insider attacks



13
Lowe moved from a scenario where honest
principals seek protection from outsiders
interfering with their communications to a
setting where insider attacks are a concern
His attack is due to the change in assumptions
rather than to the use of a model checker
This issue did not arise in Dolev&Yao’s paper
and should be clarified explicitly when referring
to the Dolev-Yao model
Entity authentication


The meaning of “entity authentication” has
changed over time
Two concepts separated around 1990:
 Key establishment: making a shared secret

14
available to two or more parties
 Entity authentication: assuring the identity of a
party and its participation in a protocol run;
captured by correspondence properties: party A
accepts protocol run if B has been involved
Ref.: Menezes, van Oorschot, Vanstone:
Handbook of Applied Cryptography
Correspondence



15
In CSP correspondence conditions are a
natural way of capturing security goals
Correspondence goes back to Bird et al.
[Crypto’91] who state their objective as:
Note that the requirement is that the
exchange be authenticated, and not the
parties themselves.
Challenge: where to insert auxiliary begin and
end events into protocols to formulate a
correspondence property
Remark on robustness



To prevent the attack on NSPK, change the
second message: BA: eKa(Nb,Na,B)
Prudent engineering practice (Abadi &
Needham): include names of principals in all
messages
IKE v2 – plausible deniability: don’t include
name of correspondent in signed messages:
http://www.ietf.org/proceedings/02nov/ID/draft-ietf-ipsec-soi-features-01.txt
16
New environments


When the environment changes, established
assumptions about security goals and
security mechanisms, and even our language
have to be adapted
Case studies
 Mobile IPv6: binding updates
 Ubiquitous computing: CANVAS
 Access control = authentication + authorisation
17
Mobile IPv6



Each mobile node has an address in its home
network; messages sent to this home address are
routed to the mobile node via a secure tunnel
Binding update: a mobile node informs the
correspondent about its current location
Channels with different security characteristics:
 Mobile  home: prearranged IP security association
 Correspondent  home: wired Internet
 Mobile  correspondent: unprotected radio channel
18
Binding update protocol
[Aura, Roe, Arkko, ACSAC 2002]
Challenge sent
to identity
1a: BU
home
CN
2a: Ka, i
Challenge sent
to location
1b: BU
2b: Kb, j
MN
19
3: MACKa(Kb,BU, i, j)
Comment




20
Goals: mobility does not weaken the security
of IP; consider denial-of-service attacks
Attacks on the fixed Internet are not covered
Consequence: attack model doesn’t consider
an adversary who can intercept both
channels from the correspondent
Security is based on return routability, keys
can be sent in the clear
Example: sensor network





21
Setup: nodes are connected to neighbours,
share secret keys with direct neighbours and
nodes reachable via one intermediary
Nodes do not know the identity of all nodes in
the network
Create new messages and forward messages
Goal = message authentication: forwarded
messages cannot be manipulated or injected
No defence against creation of bad messages
Canvas (work by Harald Vogt)


MACs to detect when a message is modified
or has not come via the advertised nodes,
B forwards message m received from A to C:
1. A  B: m, Z, A, C, p, q, r
2. B verifies p = h(KZB,m) and q = h(KAB,m)
3. B  C: m, A, B, D, r, h(KBC,m), h(KBD,m)
h(KAC,m)
Z
22
A
h(KAB,m)
h(KZB,m)
B
C
D
Security guarantees




23
Adversary: node trying to corrupt or inject
forwarded messages; any newly created
message is “legal”
Adversary is isolated if no direct neighbour is
also an adversary
Theorem: “Canvas is robust against isolated
adversaries”
Verified with the AVISS protocol analysis tool
Tearing the Canvas




To find an “attack” change the assumptions
Adversaries A and C are isolated by B
A and C have a common algorithm for
modifying forwarded messages
A knows C’s routing algorithm; inserts m’
h(kAE,m’)
Z
A
h(kAB,m)
h(kZB,m)
24
B
h(kCG,m’)
h(kBC,m)
h(kBD,m)
D
C
h(kCE,m’)
h(kAE,m’)
E
h(kEG,m’)
G
Comment


Established view in communications security:
data integrity  data origin authentication
To check the integrity of a message we have
to verify its origin
 If the sender’s identity is integral part of a

25
message, a spoofed message is not genuine
 In an insecure network, we can only rely on
evidence provided by the sender to verify that a
message has not been altered in transit
For data origin authentication we have to
verify that a message is unchanged
Integrity without authentication



26
When identities of other nodes are unknown
the sender’s identity may not be an integral
part of messages
If we do not assume a completely insecure
network, we may conclude that a message is
received unchanged if a sufficient number of
independent witnesses can vouch for this fact
We can have data integrity without data origin
authentication
Authentication & authorisation
 Lampson et al., 1992: access control =
authentication + authorisation
 For a statement s, authentication answers
the question ‘Who said s?’
 For an object o, authorisation answers the
question ‘Who is trusted to access o?’
 Traditionally, access control employs
user identities and access control lists
27
A&A revisited



28
Today: code-based access control and
access rules encoded in certificates
If security policies no longer refer to user
identities and if authentication checks who
you are, we have access control without
authentication
If authorisation checks that your identity
appears in an access control list and if
security policies are completely encoded in
certificates, we have access control without
authorisation
Complexity





Most academic protocols that have been
formally analyzed aren’t complex at all
Most attacks found are not complex either
(The analysis methods themselves may be
complex but this is the subject of another talk)
“Real” protocols like SSL, IKE, or SET are
sufficiently complex to make formal analysis
awkward
API attacks are examples for exploits that are
too complex to be found by manual analysis
 Example: key management modules
29
Key management modules





30
Devices performing cryptographic operations,
e.g. re-encrypt encrypted data under a new key
Keys tagged & encrypted under master keys
Can a key be tagged and encrypted under a
master key without proper authorisation?
[Longley & Rigby, 92]
Recent work by Mike Bond et al.
Related to work on privilege escalation in code
based access control
Key management functions
function
input
tag
output
tag
SECENC
DATA,
eKm(KD)
kds
eKD(DATA)
-
SECDEC
eKD(DATA),
eKm(KD)
kdr
DATA
-
KEYGEN
eKm(K)
kis
eKm(KG)
eK(KG)
kds
kdr
RTMK
eKm(K1),
eK1(K2)
kir
kdr
eKm(K2)
kdr
EMKKC
eKm(KM),
eKM(K)
kc
-
eKm(K)
kc
EMKKIS
eKm(KM),
eKM(K)
kc
-
eKm(K)
kis
EMKKIR
eKm(KM),
eKM(K)
kc
-
eKm(K)
kir
31
Key insertion attack
eKm(Y) [kis]
EMKKIS
Success!
eKm(K’) [kc]
EMKKC
eK’(Y) [kis]
EMKKC
random block interpreted
as encrypted key
32
SECENC
Y [kis]
eKm(K’) [kds]
eX(K’) [kdr]
eKm(X) [kc]
eU(X)
key chosen
by attacker
KEYGEN
eKm(X) [kis]
eKm(U) [kc]
EMKKIS
encrypted key available to
attacker, value of U is unknown
eU(X)
Summary





33
The design and analysis of security protocols
is difficult and error-prone
Complexity of protocols: rarely an issue
Complexity of attacks: rarely an issue
Complexity of analysis: manual analysis may
miss problems that would be found sooner or
later; tool support saves embarrassment
Specification of the problem at hand: a major
issue when addressing novel applications
Purpose of analysis methods

Two distinct motivations for developing tools
and methods for protocol analysis:
 Analyze protocols meeting established security
requirements and using established primitives
 Analyze protocols meeting novel requirements


34
In the first case, standard security goals,
environments, and cryptographic primitives
can be integral parts of the methodology
Indication: security in the application layer
Agility



35
The second case needs agile methodologies:
easy to define specific adversaries (instead of
the general Dolev-Yao adversary) and to
express new security requirements
New protocols are often designed as novel
requirements emerge, so traditional security
assumptions have to be adjusted
Standard assumptions about the nature of
“security” can get in the way of progress
The challenge ahead
 Clarifying the security properties
required in novel applications
 Understanding implicit assumptions
about the environment underpinning
established properties and established
security mechanisms
 Address complex API attacks
36