UKS attacks. Dangers & Prevention?

Question

I am trying to understand how to prevent a UKS (unknown key-share) attack, but I am having trouble finding many resources out there to help.

Let's imagine a hypothetical secure messaging application that uses public keys to encrypt messages between any two people trying to communicate. Assume 3 people, $A$, $B$, and $M$, where $M$ is the attacker. My understanding of a UKS attack would be:

1. $M$ announces his public key as $B$'s public key (instead of his own)
2. $A$ sends $M$ a message, but $A$ is unaware that he is really encrypting with $B$'s public key
3. $M$ can't read the message since he doesn't have $B$'s private key, but he forwards it to $B$.
4. $B$ thinks the message came from $A$ (which it did, technically) except $A$ did not intend for $B$ to see the message (he thought it was going to $M$!)

You could disallow two people from having the same public key in the system, but then you could run into some confusing issues for the user if someone "stole" their public key before they joined.

My question is two-fold:

1. Are their any other ways to prevent these types of attacks?
2. What other nefarious things could $M$ do in this scenario? Is it ever practical to alter the ciphertext before sending to $B$ to change the meaning of the message in some way?

Answer 1

As far as I know, unknow key-share (UKS) attacks are mostly related to key exchange protocols.

---

Presentation

An UKS attack on an authenticated key exchange (AKE) protocol is an attack whereby an entity $A$ ends up believing he shares a key with entity $B$,and although this is in fact the case, $B$ mistakenly believes the key is instead shared with an entity $M \not = A$.Since the adversary $M$ doesn't obtain the shared secret key, he can't modify or decrypt the messages between $A$ and $B$. However, $M$ can take advantage of the entities' false assumption about the identity with whom they share the key.

---

Example on authenticated Diffie-Hellman

Let's say $A$ and $B$ want to perform an AKE.

$1. \hspace{2cm} A \longrightarrow M(B):\hspace{0.3cm} Cert_A, g^a, S_A(g^a)$

$2. \hspace{2cm} M \longrightarrow B:\hspace{1cm} Cert_M, g^a, S_M(g^a)$

$3. \hspace{2cm} B \longrightarrow M:\hspace{1cm} Cert_B, g^b, S_B(g^b)$

$4. \hspace{2cm} M(B) \longrightarrow A:\hspace{0.2cm} Cert_B, g^b, S_B(g^b)$

where $M(B)$ denotes $M$ masquerades as $B$ and $S_X$ denotes a signature using the private key given in $Cert_X$.

So at the end of the protocol, $A$ and $B$ share the secret key $g^{ab}$ but $B$ mistakenly believes that this key is shared with $M$ and not with $A$. Note that $M$ does not know the shared secret key $g^{ab}$.

---

---

Answers

I am having trouble finding many resources out there to help.

I posted something some months ago about UKS attacks on KEA protocol, maybe it can help you. Also, an interesting paper about UKS attacks helped me a lot to understand it.

1. Are their any other ways to prevent these types of attacks?

As mentioned in the paper cited above, there are different ways to prevent UKS attacks:

(A) Certificates of both entites should be exchanged prior to the key agreement protocol.

(B) CA should issue certificates whith checking that each entity possesses a private key corresponding to its public key.

(C) Identities of the sender and intended receiver as well as flow numbers should be included in the messages being signed.

In my opinion, (C) is the most important one.

2. What other nefarious things could M do in this scenario? Is it ever practical to alter the ciphertext before sending to B to change the meaning of the message in some way?

A famous hypothetical scenario where an UKS attack can have damaging consequences is the following:

Suppose that $B$ is a bank branch and $A$ is an account holder. Certificates are issued by the bank headquarters, and within each certificate is the account information of the holder. Suppose that the protocol for the electronic deposit of funds is to exchange a key with a bank branch via an authenticated key agreement protocol. At the conclusion of the protocol run, encrypted funds are deposit to the account number in the certificate. Suppose that no further authentication is performed in the encrypted deposit message (which might be the case to save bandwith). If the UKS attack is successfully launched, then the deposit will be made to $M$'s account instead of $A$'s account.

Hope it helps.