Pre-sharing of ECC public keys in Bluetooth Security Mode 4

[Andrew Waterhouse]

Apologies if this is answered in some other thread but we cannot find the precise answers we are looking for and are striving for some quick clarifications. We are planning Bluetooth adoption for the first time using the nRF52833 . Our planned application requires the pre-sharing of ECC public keys to be used in Security Mode 4 to establish a secure link.  We have a couple  questions and perhaps someone can steer us to locate the desired information:

1. Is there a mechanism available in the software for nRF52833 to use a manufacturer-generated ECC public key in place of ta  key generated by the Nordic platform ?

2. We have studied the security descriptions of Bluetooth Core spec v5.2 but cannot  see that the agreed LTK is validated by some mechanisms prior to first use in AES-CCM ?  ECC-DH does not implicitly validate an agreed key - that has to be done by some further mechanism. Am I missing something, or for BLE  must  we wait on the authentication result of the first packet received under AES-CCM to know if pairing  has worked or not ?

Many thanks,

Andrew

[Susheel Nuguru]

Hi Andrew,

1. Is there a mechanism available in the software for nRF52833 to use a manufacturer-generated ECC public key in place of ta  key generated by the Nordic platform ?

If you are looking for a mechanism to generate your own ECC public key, Please take a look at nRF Util. 

2. We have studied the security descriptions of Bluetooth Core spec v5.2 but cannot  see that the agreed LTK is validated by some mechanisms prior to first use in AES-CCM ?  ECC-DH does not implicitly validate an agreed key - that has to be done by some further mechanism. Am I missing something, or for BLE  must  we wait on the authentication result of the first packet received under AES-CCM to know if pairing  has worked or not ?

 I think we need wait until the first packet is received, decrypted, and accepted to know that the pairing has worked.