Challenges in Protocol Design and Analysis

1
Challenges in Protocol Design and Analysis

• Dieter Gollmann
• TU Hamburg-Harburg
• diego_at_tuhh.de

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 Lowes attack revisited
• Robustness?
• Mobile IPv6
• Data integrity without authentication?
• Complex attacks
• Summary Conclusions

4
Protocol analysis the task

• Given security requirements
• desired 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
Lowes attack the protocol

• Needham-Schroeder public key protocol
• Goal derive shared session key from Na, Nb
• 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

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
Lowes 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
Lowes attack
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 DolevYaos 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.
  Crypto91 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 B?A eKa(Nb,Na,B)
• Prudent engineering practice (Abadi Needham)
  include names of principals in all messages
• IKE v2 plausible deniability dont include
  name of correspondent in signed messages
  http//www.ietf.org/proceedings/02nov/I-D/draft-ie
  tf-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
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
3 MACKa(Kb,BU, i, j)
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 doesnt 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
• A ? B m, Z, A, C, p, q, r
• B verifies p h(KZB,m) and q h(KAB,m)
• B ? C m, A, B, D, r, h(KBC,m), h(KBD,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 Cs routing algorithm inserts 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 senders 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
  senders 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 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

28
AA 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 arent 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
32
Key insertion attack
key chosen by attacker
Success!
encrypted key available to attacker, value of U
is unknown
random block interpreted as encrypted key
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