6
$\begingroup$

I have a question concerning the pairing of two Bluetooth devices using Simple Secure Pairing with numeric comparison. The NIST document I am looking at states on page 14:

Numeric Comparison was designed for the situation where both Bluetooth devices are capable of displaying a six-digit number and allowing a user to enter a “yes” or “no” response. During pairing, a user is shown a six-digit number on each display and provides a “yes” response on each device if the numbers match. Otherwise, the user responds “no” and pairing fails. A key difference between this operation and the use of PINs in legacy pairing is that the displayed number is not used as input for link key generation. Therefore, an eavesdropper who is able to view (or otherwise capture) the displayed value could not use it to determine the resulting link or encryption key.

And on page 15, there is a graphic that illustrates the “Link Key Establishment for Simple Secure Pairing”:

Graphic showing the “Link Key Establishment for Simple Secure Pairing”

Now…

To check on things, I've used a Bluetooth packet capture to sniff the traffic on my phone to see the pairing details. I expected the Bluetooth packet capture to log the details about the $PK$ that was sent and received by the controller. I do see the User Confirmation Request containing the number for the numeric comparison, but I am not able to detect any infos about a $PK$ exchange – as if such an exchange never happened. Therefore, it would be nice to get a confirmation if Simple Secure Pairing indeed uses a $PK$ – and at what point it actually exchanges it.

TL;DR:

I don't understand how the “Link Key Establishment for Simple Secure Pairing” prevents a MITM attack. It seems as if attackers could send a false $PK_2$ nevertheless… or did I miss something?

Improve this question
$\endgroup$
5
  • 1
    $\begingroup$ my guess: the confirmation number is derived from the shared DH secret and if there's a MitM the DH secret would change and thus both parties would have different codes displayed. $\endgroup$
    – SEJPM
    Commented Jul 20, 2016 at 12:47
  • $\begingroup$ The confirmation number is sent in clear by Bluetooth. I don't think it is linked to the DH secret. If I'm mistaken I'd like some explanations. $\endgroup$
    – Shan-x
    Commented Jul 20, 2016 at 13:09
  • 2
    $\begingroup$ No, numeric comparison is a much more complex operation. See Section 3 of this analysis paper. If the numbers match, we can be pretty sure that there is no MitM. $\endgroup$
    – mikeazo
    Commented Jul 20, 2016 at 14:05
  • $\begingroup$ This is interesting. Can you precise at which step is the comparison by the user? $\endgroup$
    – Shan-x
    Commented Jul 20, 2016 at 14:50
  • $\begingroup$ It is probably after the key is calculated and is some function of the key. But I am not familiar enough with the spec to say for sure. $\endgroup$
    – mikeazo
    Commented Jul 20, 2016 at 16:59

1 Answer 1

Reset to default
5
$\begingroup$

I think that you miss the point of this method. You can think of this SSP as a key-exchange protocol between two devices which have nothing shared between them a priori and also the entire communication is inspectable and even temperable, that is, the adversary can modify/send messages as it wishes. The big advantage of this SSP method over a usual key-exchange protocols (i.e. between computers over the Internet) is that the devices have a human linking between them, or abstractly, authenticated communication channel that cannot be tampered with by the adversary and can be used to send a short message.

Regarding the MITM attack, I'm not very familiar with the spec but looking at this makes it more clear: Assume that as an attacker you execute this key-exchange protocol with both devices A and B. Let $pk_A, pk_B$ be the public keys of A and B resp. and let $pk_A',pk_B'$ be the keys that you (the adversary) choose in the execution between you and A and between you and B resp. Now the number that appears on the screen is a function $H$ (truncated as needed) applied to the keys of the parties (and some more random strings but let's skip it for simplicity), that is, the number on A's device would be $c_A=H(pk_A,pk_A')$ (where the adversary behaves as device B) and the number on B's device would be $c_B=H(pk_B',pk_B)$ (where the adversary behaves as device A). The goal of the adversary is to make $c_A=c_B$ in order for the device to be "paired". The randomness of $pk_A$ dictates that $c_A$ is random as well, which means that in order to make $c_B=c_A$ the adversary has to find a $pk_B'$ such that $c_A=H(pk_B',pk_B)$. This is a hard problem (as finding a preimage for a hash function) and thus the MITM attack could not be held successfully.

Improve this answer
$\endgroup$
1
  • $\begingroup$ In the middle: Why not just sniff $pk_A$ and $pk_B$ and create $H(pk_A,pk_B)$ as an attacker? Where is $pk_A$ bound to A and $pk_B$ bound to B? I know asymmetric key pair, but then you have to use it somewhere? $\endgroup$
    – secf00tprint
    Commented Dec 13 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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