ECB key transfer during pairing

RE: ECB key transfer during pairing

SUK — Thu, 09 Mar 2017 16:29:14 GMT

Hi Endnote, Thank you for your inputs and your patience :). I have implemented a system with LE legacy pairing using Just Works and no MITM.

RE: ECB key transfer during pairing

endnode — Wed, 08 Mar 2017 19:18:52 GMT

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

RE: ECB key transfer during pairing

endnode — Wed, 08 Mar 2017 19:15:21 GMT

That's the part which confuses me: you say that you want to use LE Secure Connection and then you speak about AES ECB. If you want to use LE SC then stop speaking about AES ECB and stop even thinking about it because there is no option, just specification to follow. To the steps: If you see Security Manager description (BT SIG Core v4.2, Vol 3, Part H, Chapter 2) then you see that Pairing is 3-step process where in second step Long Term Key (LTK) is generated and in third step you use specific Transport Key(s) by using LTK. Once you are paired you always do only 3rd step, LTK stays the same on both sides (you need to keep some sort of database, that's what "peer manager" module in Nordic SDK is for, obviously just one example of many ways how to manage these). Then in chapter 2.2 you see full "Cryptographic Toolbox" which tells you all the details about how LTK is generated in 2nd step..

RE: ECB key transfer during pairing

SUK — Wed, 08 Mar 2017 18:57:42 GMT

Hi Endnode, Thank you for your patience :). Can you please elaborate on " Again there are different ways how to solve it and some basic assumptions to be even able to do it." and "The final AES key is generated (pretty complex process) so you don't need to think about it."? I read the SIG core specs but I am still confused about AES key exchange. When does this happen? After pairing or during pairing? I am planning to use Just works with LE secure, no I/O, no MITM. I want to use AES ECB to encrypt data.

RE: ECB key transfer during pairing

endnode — Wed, 08 Mar 2017 07:10:07 GMT

Hi again, so you want to use nRF52 and LE Secure Connections. This is using proper ECC DH key exchange with static and ephemeral key pairs which is not possible to crack by passive listening. That's good. However because there is no link or central certification authority in the ecosystem you need to "authenticate" that correct peers talk together. Again there are different ways how to solve it and some basic assumptions to be even able to do it. If you have no input or output interface on either device you need to settle with unauthenticated key exchange which is vulnerable to Men In The Middle attack (MITM) - but that would be active not passive. That's quite OK. For more read BT SIG Core specification v4.2 (or v5.0) and study Vol. 3 Part H, Chapter 2 "Security Manager" where are all details. The final AES key is generated (pretty complex process) so you don't need to think about it.

RE: ECB key transfer during pairing

SUK — Wed, 08 Mar 2017 00:02:21 GMT

I think I understand now. Please confirm if my understanding is correct: When I use Just Works for pairing (as per this), the p_pk_own key will be generated by the Soft device (which can be 000000). Then when the stage where the DHKey calculation is done (by the peripheral application), I can use any key I want and send that over to the Central. This key can then be used by the Peripheral and central for AES ECB encryption and decryption. Again, I understand that this is not secure and prone to interception. This DHKey (which is generated as a long term key) can be stored by the central after bonding so that at every connection (after disconnection) key exchanges won't have to be done.

RE: ECB key transfer during pairing

SUK — Tue, 07 Mar 2017 22:37:05 GMT

Thank you Endnode for your inputs. Let me summarize what you said: I can only use Just Works for pairing since I don't have Keyboard or display on my peripheral. But I can still use AES CCM encryption and exchange the AES key over radio even if it is not secure. Is my understanding correct? Also I did not understand the part where you said "or if you are OK with hard-coding some master key into the FW". What key are you talking about? The AES CCM key? Where can I find an example which is using AES CCM encryption using Just Works?

RE: ECB key transfer during pairing

endnode — Tue, 07 Mar 2017 18:44:57 GMT

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

RE: ECB key transfer during pairing

SUK — Tue, 07 Mar 2017 18:25:12 GMT

Yes. I meant using AES ECB encryption using stream cipher as per this blog. Can you answer my questions?

RE: ECB key transfer during pairing

endnode — Tue, 07 Mar 2017 18:19:09 GMT

Just a footnote: you definitely DON'T WANT TO USE ECB (Electronic Codebook) ENCRYPTION/DECRYPTION SCHEME FOR ANY COMMUNICATION PROTOCOL in 2017! But you probably mean AES crypto primitive with some more advanced method (like CCM aka Counter with CBC-MAC)...