Challenges in Protocol Design and Analysis

1. Challenges in Protocol Design and Analysis Dieter Gollmann TU Hamburg-Harburg diego@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: Lowe’s 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. Lowe’s 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): AbelievesBbelievesNbis a secret shared byAandB

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. eKe(Na,A) eKb(Na,A) A E B eKa(Nb,Na) eKa(Nb,Na) eKe(Nb) eKb(Nb) Lowe’sattack:

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 beginandendevents 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: 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. 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 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. h(KAC,m) h(KAB,m) Z A B C D h(KZB,m) 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 forwardedmessages; 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. h(kAE,m’) h(kCG,m’) h(kEG,m’) h(kCE,m’) h(kAB,m) h(kBC,m) Z A B C G E h(kBD,m) h(kZB,m) h(kAE,m’) D Tearing the Canvas • To find an “attack” change the assumptions • Adversaries A and C are isolated by B • A and C havea common algorithm for modifying forwarded messages • A knows C’s 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 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 + authorisation • Fora 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

32. EMKKIS SECENC eKm(Y)[kis] eK’(Y) [kis] Y[kis] eKm(K’) [kc] eKm(K’) [kds] EMKKC KEYGEN eX(K’) [kdr] eKm(X) [kc] eKm(X) [kis] EMKKIS EMKKC eU(X) eKm(U)[kc] eU(X) Key insertion attack key chosen by attacker Success! random block interpreted as encrypted key encrypted key available to attacker, value of U is unknown

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