1 / 24

CONTEXT BINDING: An Emerging Problem in Cryptographic Protocols

CONTEXT BINDING: An Emerging Problem in Cryptographic Protocols. Catherine Meadows Naval Research Laboratory Code 5543 Washington, DC 20375 meadows@itd.nrl.navy.mil. WHAT I DO A LOT OF. Apply formal methods to analysis of cryptographic protocol analysis

vonda
Download Presentation

CONTEXT BINDING: An Emerging Problem in Cryptographic Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CONTEXT BINDING:An Emerging Problem in Cryptographic Protocols Catherine Meadows Naval Research Laboratory Code 5543 Washington, DC 20375 meadows@itd.nrl.navy.mil

  2. WHAT I DO A LOT OF • Apply formal methods to analysis of cryptographic protocol analysis • Over the years, specific type of model of crypto protocols has become accepted • Each principal has a name • Each principal has a master key or set of master keys associated with that name • Master keys used to exchange temporary session keys and other short-term information • Names/master keys unlikely to change, at least during execution of the protocol

  3. SITUATIONS IN WHICH IDENTITIES CAN CHANGE • Mobile computing • Entity migrates from one address to another • Secure group protocols • Entity joins a group, gets new identity as member of group • Composition of protocols • E.g., running a legacy protocol on top of, or inside of, another protocol • Different keys may be associated with different protocols, even when same principal involved

  4. Contexts and Context Binding • Context: a set of attributes that distinguishes a principal • Examples • Address (e.g. IP address) • Long-term keys • Names • Etc. • Context often used to decide what privileges a principal has • In a mobile computing environment, contexts can often change • How can we ensure that they change securely • Context binding: the problem of ensuring the integrity of a context switch

  5. WHAT I’LL TALK ABOUT TODAY • Three examples of flawed context binding • Multihoming “Effects of Mobility and Multihoming on Transport-Protocol Security”, Aura, Nikander, and Camarrillo • Tunneled Authentication Protocols “Man-in-the-Middle in Tunneled Authentication Protocols”, Asokan, Niemi, and Nyberg • Group key distribution Protocols “Deriving, Attacking, and Defending the GDOI Protocol,” Meadows and Pavlovic • Lessons learned in terms of assuring correct context binding

  6. Multihoming • Stream Control Transmission Protocol (SCTP) • Allows endpoints to have multiple IP address for fault tolerance • Currently being extended to allow for multihoming and dynamic address change

  7. Will Concentrate on a Particular Feature: Verification Tags • Verification tags used to identify association • Randomly generated nonces issued by initiator and responder • Random means harder to forge • Provides some protection against spoofing and denial of service attacks • However, anyone who sees them can spoof association • As it turns out, multihoming makes it easier to sniff verification tags

  8. NEW VULNERABILITIES • Multiple addresses means tags can be sent along multiple paths • Easier to sniff and easier to spoof • What happens when an old address is abandoned? • Packets may be still be sent to it and may be received by new owner of address • State cookie used in second message of handshake contains verification tag of any existing association with same endpoints • If attacker gains control of an IP address, can get verification tags by initiating handshake • Etc. …

  9. SOLUTIONS • Can’t use strong cryptography (digital signatures, encryption); too much of an impact on performance • That’s why verification tags introduced in first place • However, can use weaker but more efficient mechanisms such as one-way hashes to limit exposure of verification tags • Some suggestions: • Cryptographically generated address: some address bits encode secure hash of address owner’s public signature key • Public signature key becomes “master context” • Don’t reuse addresses • Send one-way hashes of tags instead of tags themselves in cookies • Verify that peer addresses are active • Use more sophisticated secure acknowledgement schemes • Every packet contains a nonce • Ack is XOR of all nonces in packets received so far

  10. MORAL • Multiplication of addresses not only creates new vulnerabilities but magnifies old ones • Defenses, such as randomly generated verification tags, that were once “good enough” are no longer • However, not feasible to develop full-scale cryptographic defenses • Need to develop a new version of “good enough” • Question: is it possible to quantify “good enough”, or to devise general strategies for arriving at it?

  11. TUNNELED AUTHENTICATION PROTOCOLS • Want to run legacy application (e.g. ftp) inside a server-authenticated tunnel (e.g. tls) • Vulnerability arises when legacy protocol runs in both legacy environment as well as tunneled environment • Example: Extensible Authentication Protocol

  12. Protected EAP • Three parties: client, back-end server, and network access server (NAS) • Client & back-end server set up TLS tunnel over EAP • NAS does not know TLS master secret • Back-end server derives master session keys from TLS master secret • Conveys them to NAS • NAS and client use keys to communicate over link layer Client Conversation Backend Server Over link NAS key

  13. WHAT CAN GO WRONG? • Suppose that: • Legacy client authentication protocol used in other environments • Plain EAP without tunneling • No EAP encapsulation • Client fails to verify server certificate properly • Whether or not using tunnel • Then it’s possible to construct a man-in-the-middle attack

  14. MitM ATTACK • Mitm waits for legitimate device to start untunneled legacy remote authentication protocol (or tricks it into doing so) • MitM sets up tunneled authentication protocol with authentication agent • After tunnel set up, MitM starts forwarding legitimate client’s authentication protocol messages through the tunnel • After remote authentication ended successfully, MitM derives session keys from same keys it is using for tunnel • MitM can now impersonate legitimate device Client Backend Server 1 MitM (as client) Conversation Backend Server 2 NAS key Over link

  15. Recommended fixes • If inner protocol also uses cryptography, perform cryptographic binding between inner and outer protocols • Have inner and outer protocol both create key, and use both as input to session key • Creates some issues with layering • IETF now working out this • For some protocols, this not sufficient • Protocols based on weak passwords • There, stuck with forbidding use outside of secure tunnels

  16. MORAL HERE • When faced with context migration, can achieve security by introducing cryptographic binding between old context and new • This comes at a cost, and may not always be applicable • Layering may be an issue

  17. GDOI PROTOCOL • Stands for “Group Domain of Interpretation” • Two types of principals • Group members • Group Controller/Key server • Includes handshake protocol (groupkey pull protocol) in which member requests to join group and receive current group key

  18. GROUPKEY PULL PROTOCOL Initiator (Member)                   Responder (GCKS)         ------------------                   ----------------         HDR*, HASH(1), Ni, ID    -->                                   <--     HDR*, HASH(2), Nr, SA         HDR*, HASH(3) [, KE_I]    --> [,CERT] [,POP_I]                                   <--     HDR*, HASH(4), [KE_R,] SEQ, KD [,CERT] [,POP_R] Hashes are computed as follows:     HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)     HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)     HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] | POP_I)     HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] | SEQ | KD | POP_R) POP_I = S_I(Ni,Nr) POP_R = S_R(Ni,Nr)

  19. OPTIONAL PROOF OF POSSESSION • Member can introduce certificate in third message • Certificate may give member certain privileges • Member has to prove possession of identity in the certificate • Does this by signing own nonce and GCKS’s nonce • Intended to give cryptographic binding to new identity • Similar optional proof-of-possession for GCKS

  20. ATTACK ON POP Suppose that I is a GCKS that wants to join a group managed by another GCKS, B. Suppose that I doesn’t have the proper credentials to join B’s group. Then I can trick a member A who does into supplying them, as follows. • A --> I : HDR*, HASH(1), Ni, ID A requests to join I's group, sending a nonce Ni 1.' I_member --> B : HDR*, HASH(1)', Ni, ID’ I requests to join B's group, forwarding A's nonce Ni 2.' B --> I_member : HDR*, HASH(2), Nr', SA’ B responds to I with its nonce Nr' 2. I --> A : HDR*, HASH(2)', Nr', SA I responds to member A, but using B's nonce Nr' 3. A --> I: HDR*, HASH(3), CERT(for A's ID in group), POP = S_A(hash(Ni,Nr')) A responds to I with a POP taken over A's and B's nonce 3.' I_member --> B: HDR*, HASH(3), CERT(for A's ID in group), POP = S_A(hash(Ni,Nr)) I as a member responds to B, using A's CERT and POP 4. B --> I_member : HDR*, HASH(4), KD B sends keying information to I under impression the identity in A's certificate belongs to I

  21. WHAT WAS THE PROBLEM? • Cryptographic binding went only one way • PoP appears in message authenticated with member’s key, attests to member’s statement that it is owner of PoP identity • Not much use if member lies • No corresponding statement that PoP identity is also owner of member identity • Solve this problem by having signature taken over member identity as well as the two nonces

  22. MORAL • Not enough to provide cryptographic binding • Need to say what is being bound, and how

  23. HOW TO REASON ABOUT SECURE BINDING? Start with possibility that entities associated with the old context A and new context B could be different • Honest A, dishonest B Could B deceive third party into thinking B was A? • Honest B, dishonest A Could A deceive third party into thinking A was B? • Colluding B and A Possible if A and B share all information If want to avoid this, best can show is that A and B can’t collude without sharing information that they would rather not or could not share

  24. LESSONS LEARNED • Need to deal with/mitigate multiplication of contexts • Especially, need to retire expired contexts • Avoid reusing contexts • Need to reexamine partial solutions • What was “good enough” for single-context environment may not no longer be so when context migration introduced • Cryptographic binding can provide a solution • Need to work out carefully how it’s done and what is being bound

More Related