This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ECB key transfer during pairing

Hi, I have a central that is trying to pair with a peripheral. I want this connection to be secure and I want to use ECB for encryption of data. My peripheral does not have a display or a keyboard. What pairing mechanism should I use? I was thinking about using "Just Works". I know this question has been asked a lot many times but I am still confused about this one point. Does the ECB encryption key get transferred to the central during the pairing using Just Works? If not how should I let the central know what key to use for decryption? Also is there any documentation which shows how the pairing works exactly?

Thanks.

Parents
  • Hi SUK,

    Not being expert on BT4.x Security Manager and pairing mechanism but I will try to answer. "Just Works" is really the only option for devices which have no input/output interface so you cannot verify that key you receive over radio interface during pairing is genuinely the same as the on on the other device. So generic "zero" string is used to validate that AES key (generated/exchanged during the process) is the one you should use from now on. If you think it through you will find out that this pairing is basically not secure at all, anyone can intercept it and get the actual AES key and then decrypt (or alter/fake) any communication between these two devices later on. In addition even if you are not listening to the pairing itself you can try to convince one of the devices that you have lost the AES key and if it permits such re-pairing it will allow you to do the same again which of course compromises all the future communication. So using this method for anything sensitive is not a good idea.

    Easy solution could be if your device is able to communicate by some other ways (e.g. NFC thanks to nRF52 in-built near-field communication capabilities) or if you are OK with hard-coding some master key into the FW (nRF5x have also something like on-time programmable registers but as they don't have any specific HW protection it almost doesn't matter if you store it there or in the code/data flash). In such case you can use OOB (Out Of Band) mode where AES key is derived/used from this "shared" secret and so you are not exchanging the key over the radio, you don't need to "verify" that it is genuine (by anything like "Just Works" or "Numeric Comparison") and you are set to go.

    Cheers Jan

  • .. and how Transport specific key(s) are generated in 3rd phase from LTK. You either understand it or not, that's very hard to bypass. If you cannot follow all the details then don't worry, that's most of the world. Just study Nordic SDK examples and they will show you how all the steps are implemented. You don't need to understand all the details just major use case (which you seems to get correctly: use LE Secure Connections without MITM protection with Just Works because you have no real option). Just make sure that all the peers you intend to use support this BT 4.2 pairing method, as far as I know many phones don't support it so you might need to support the legacy LE pairing method as well.

Reply
  • .. and how Transport specific key(s) are generated in 3rd phase from LTK. You either understand it or not, that's very hard to bypass. If you cannot follow all the details then don't worry, that's most of the world. Just study Nordic SDK examples and they will show you how all the steps are implemented. You don't need to understand all the details just major use case (which you seems to get correctly: use LE Secure Connections without MITM protection with Just Works because you have no real option). Just make sure that all the peers you intend to use support this BT 4.2 pairing method, as far as I know many phones don't support it so you might need to support the legacy LE pairing method as well.

Children
No Data
Related