1
$\begingroup$

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?
$\endgroup$
1
$\begingroup$

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.

  1. 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.

$\endgroup$
  • $\begingroup$ Thanks for the info, I'll take a look at that paper soon. However, I'm having trouble understanding the bank example. I can't follow why a deposit to A will end up in M's account just because M is using A's certificate. Does M make a fake deposit or does A make the deposit and it just ends up in M's account? $\endgroup$ – Anthony Kraft Apr 7 '16 at 15:27
  • $\begingroup$ Specifically, won't there be 2 accounts with the same certificate in the bank's eyes? $\endgroup$ – Anthony Kraft Apr 7 '16 at 15:33
  • $\begingroup$ @AnthonyKraft If $B$ is a bank and $A$ sends him a digital coin, encrypted with the shared secret key, for deposit into his account. Believing that the key is shared with $M$, $B$ assumes the coin is from $M$ and deposits it into $M$'s account instead. I will edit my post to make it more complete. $\endgroup$ – Raoul722 Apr 7 '16 at 15:55
  • 1
    $\begingroup$ I see now. So if the protocol were amended so that A says "here is the encrypted deposit. Oh and by the way I am user A. Please make sure this is deposited into user A's account" then a UKS attack would be thwarted? It seems odd to me that the same session key would be used more than once, even if the same certificate is presented. $\endgroup$ – Anthony Kraft Apr 7 '16 at 16:05
  • $\begingroup$ @AnthonyKraft You got it but I don't get your remark on using the same key. $\endgroup$ – Raoul722 Apr 7 '16 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.