1 challenges in protocol design and analysis dieter gollmann tu hamburg-harburg [email protected]
TRANSCRIPT
2
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?
3
Agenda
History: quick look at Dolev-Yao model History: Lowe’s attack revisited Robustness? Mobile IPv6 Data integrity without authentication? Complex attacks Summary & Conclusions
4
Protocol analysis – the task
Given security requirementsdesired security properties intended (communications) environment
Given a security protocol Does the protocol meet the
requirements?
5
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
6
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.
7
Default environment
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
8
Lowe’s attack – the protocol
Needham-Schroeder public key protocol
Goal: derive shared session key from Na, Nb
1. AB: eKb(Na,A)
2. BA: eKa(Nb,Na)
3. AB: 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
9
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
10
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
11
Lowe’s attack:
A E B
eKe(Na,A) eKb(Na,A)
eKa(Nb,Na) eKa(Nb,Na)
eKb(Nb)eKe(Nb)
Proof: Initiator A authenticates responder E
Attack: Responder B can be tricked by a masquerading initiator
12
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”
13
Insider attacks
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
14
Entity authentication
The meaning of “entity authentication” has changed over time
Two concepts separated around 1990: Key establishment: making a shared secret
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
15
Correspondence
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
16
Remark on robustness
To prevent the attack on NSPK, change the second message: BA: 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/I-D/draft-ietf-ipsec-soi-features-01.txt
17
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
18
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
19
MN
CNhome1a: BU
2a: Ka, i
3: MACKa(Kb,BU, i, j)
2b: Kb, j
1b: BU
Binding update protocol
[Aura, Roe, Arkko, ACSAC 2002]Challenge sent to identity
Challenge sent to location
20
Comment
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
21
Example: sensor network
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
22
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(KZB,m)
Z A B C Dh(KAB,m)
h(KAC,m)
23
Security guarantees
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
24
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’
Z A B C
D
G
h(kZB,m)
Eh(kAB,m)
h(kAE,m’)
h(kBD,m)
h(kBC,m)
h(kAE,m’)
h(kCE,m’)
h(kCG,m’)
h(kEG,m’)
25
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
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
26
Integrity without authentication
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
27
Authentication & authorisation
Lampson et al., 1992: access control = authentication + authorisationFor 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
28
A&A revisited
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
29
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
30
Key management modules
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
31
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
32
Key insertion attack
EMKKISeKm(U) [kc] eU(X)
eKm(X) [kis]
EMKKC
KEYGEN
eU(X)
eKm(X) [kc]
EMKKC eX(K’) [kdr]
eKm(K’) [kc]
SECENCEMKKIS
eKm(K’) [kds]
Y [kis]eK’(Y) [kis]eKm(Y) [kis]
encrypted key available to attacker, value of U is unknown
random block interpreted as encrypted key
key chosen by attacker
Success!
33
Summary
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
34
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
In the first case, standard security goals, environments, and cryptographic primitives can be integral parts of the methodology
Indication: security in the application layer
35
Agility
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
36
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