BLE LTK regeneration and NVM

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

BLE LTK regeneration and NVM

827 Views
mateuszwielgos
Contributor II

Bluetooth Specification Version 4.2 [Vol 3, Part H] Section 2.4.2.3 states that:

Devices which support encryption in the Link Layer Connection State in the Slave Role shall be capable of generating LTK, EDIV, and Rand.

The EDIV and Rand are used by the slave device to establish a previously shared LTK in order to start an encrypted connection with a previously paired master device.

The generated LTK size must not exceed the negotiated encryption key size and its size may need to be reduced (see Section 2.3.4).

New values of LTK, EDIV, and Rand shall be generated each time they are distributed.

I am using KW41Z with version 2.2.0 of the SDK (framework v. 5.3.3, bluetooth v. 1.2.3). All examples from the MCUXpresso SDK (v2.2) re-use the LTK, EDIV and Rand values - they are hardcoded. It should be relatively trivial to change them each time they are distributed, however, I am using NVM and things are a bit more difficult.

BLE Application Developer's Guide.pdf states that the following functions need to be implemented:

extern void App_NvmErase ( uint8_t mEntryIdx );

extern void App_NvmWrite ( uint8_t mEntryIdx, void* pBondHeader void* pBondDataDynamic, void* pBondDataStatic, void* pBondDataDeviceInfo, void* pBondDataDescriptor, uint8_t mDescriptorIndex };

extern void App_NvmRead ( uint8_t mEntryIdx, void* pBondHeader void* pBondDataDynamic, void* pBondDataStatic, void* pBondDataDeviceInfo, void* pBondDataDescriptor, uint8_t mDescriptorIndex };

They are implemented and things seem to be working okay for me in gNVM_NotMirroredInRamAutoRestore_c mode.

For security reasons (according to BLE Application Developer's Guide.pdf) ediv and randSize need to be compared in the gConnEvtLongTermKeyRequest_c event, so, somehow, they need to be retrieved from NVM along with the LTK. How can this be done?

I debugged how data is written to NVM but nothing seems to match up. In addition, I'm not sure what mEntryIdx should be - is it safe to say that it should equal to peerDeviceId when handling connection events?

Labels (1)
1 Reply

631 Views
mateuszwielgos
Contributor II

I ended up using Gap_SaveCustomPeerInformation / Gap_LoadCustomPeerInformation to get around this issue.