Signing Peer's Identity

Last Updated: 16 December 2018

In the last episode, we've seen that the Basic Authenticated Diffie-Hellman Key Exchange (BADH) was vulnerable to an Unknown Key Share Attack. We'll discuss a fix that takes care of Identity Misbinding Attacks, at least in this case, so we'll finally do have a more robust authenticated Key Exchange protocol.

What happened so far?

Let's recall what we've seen so far. The BADH protocol looks like this:

And the identity-misbinding attack allowed Eve to create two conflicting perceptions:

Alice's perception: I am sharing a key \(g^{ab}\) with Bob

Bob's perception: I am sharing a key \(g^{ab}\) with Eve

Eve managed to confuse Bob to share a key with her that was actually co-created by Alice. How did she manage to accomplish this feat? By simply forwarding Alice's \(g^a\) offer under her identity \(\mathit{I_{Eve}}\) to Bob (that's the part where Bob started to get confused), then forwarding Bob's reply back to Alice, and finally by throwing Alice's signature away, and replacing it with her own signature (which completed Bob's confusion). We can resume it like this:

Be careful here: adding our own's identity to the signature is useless. It's the expected peer's identity (the one we'd like to talk to, not the interloper) that needs to be "sealed" inside the signature.

Of course, Alice expects the signature provided by Bob (Eve) to match her Identity, i.e. to match \(g^a || g^b || \mathit{I_{Alice}}\). But since Eve tried to fool Bob into believing that he's interacting with her, Bob signed \(g^a || g^b || \mathit{I_{Eve}}\) instead. And since Eve doesn't have access to Bob's long-term private key, she can't forge a signature like \(\operatorname{sign_{Bob}}(g^a, g^b, \mathit{I_{Alice}})\).

The Canetti-Krawczyk Security Model

Argumenting like this makes it intuitive to understand what's going on on a very high level. Unfortunately, it's merely hand-waving. Since secure protocol design can be brittle it's way too easy to come up with a construction that may seem secure, yet is fundamentally broken. As UKS has taught us, intuition only goes so far. We should never rely (exclusively) on it. What we need at this point is a real proof that this protocol is secure.

Any security proof worth its salt requires a security model. Key Exchange protocols are nowadays proven with the help of the Canetti-Krawczyk Security Model[CK01]. Explaining this very useful model is way too involved for a small article that needs to be bite-sized and that can be read on the go.