Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Using Just Works mode with MITM protection

Hello,

I have a product that uses just works pairing, as the user should walk up to the device to pair (but not bond). As this is using Just Works, the connection should be encrypted but does not protect against MITM(?).

What is common practice when a device needs to work with Just Works pairing, but still have security to stop MITM attacks? If I'm not mistaken encryption should automatically have data data signing to verify the data is authentic.

I want to know that the data is authentic and stop MITM attacks. Would the solution be to add another layer of encryption to the software (e.g. AES)?

Parents
  • Hi,

    To defend against MITM attacks, it is necessary that an encryption secret is exchanged between the device in another transport channel. In this case, that means not through BLE.

    This means that Just Works pairing cannot achieve MITM defense by nature.

    For the additional layer of encryption that you are consider adding to work, a part or the entire secret regarding encryption has to be exchanged by another transport.

    If your system has a transport channel to exchange secret like that, such as via cloud, then you can achieve MITM protection. If not, or if the method you can come up with are not much different from other pairing methods, then perhaps you should consider Bluetooth's existing solution instead.

    Hieu

  • That's interesting to make the cloud exchange the secret key.

    Are you talking about doing a normal just works pairing (no MITM), the keys are already known i.e. the key gets generated during production, hardcoded in the BLE device, and stored in the cloud? Then when a device connects the key that would have been generated via pairing, instead would just be the ones that were used during production.

Reply
  • That's interesting to make the cloud exchange the secret key.

    Are you talking about doing a normal just works pairing (no MITM), the keys are already known i.e. the key gets generated during production, hardcoded in the BLE device, and stored in the cloud? Then when a device connects the key that would have been generated via pairing, instead would just be the ones that were used during production.

Children
Related