Upgrade to BLE Spec 4.2 with new softdevice

[atummac]

I am currently using softdevice 8.0.0.

I am curious if the nRF51822 will be upgradable to be 4.2 compliant with a new softdevice release in the future? My understanding is that the nRF51822 is only compliant with 4.1 at the moment.

The specific part of 4.2 I am interested in comes from the Bluetooth SIG website:

With the release of the Bluetooth Core Specification version 4.2, security is greatly enhanced by the new LE Secure Connections pairing model. In this new model, the numeric comparison method is added to the other three methods and the Elliptical Curve Hellman-Diffie (ECDH) algorithm is introduced for key exchange in this process.

[Ulrich Myhre]

Hi

It is not mandatory to support all the features in the new specs to claim compliance, so if you are interested in a particular feature you should refer to that one specifically. Our S130 SoftDevice is 4.2 compliant, but do not support LE Secure Connections as of today. S110 8.0.0 is compliant to 4.1 as you mention, but only implement the Privacy 1.1, low duty-cycle directed advertisement and concurrent broadcaster features.

For future advances and timelines, you would have to contact a sales representative. Requests to those teams help developers focus on the right features at the right time. If you do not know your local sales representative, shoot me a message with your location and I will provide you with the contact information.

[atummac]

Thank you for your answer!

[endnode]

Well I guess it's safe to say there will be no ECC on nRF51 because there is no dedicated HW block and doing ECDH in SW on ARM Cortex-M0 in real time is pretty much no go.

[Ulrich Myhre]

It would be quite slow, but it is not outside the realm of possibility. Since key generation happens seldom, it could be done with little impact for applications with longer connections.

[atummac]

I am not sure it would be prohibitively slow. There are open libraries (github.com/.../micro-ecc) to do ECDH even on 8-bit microcontrollers and the performance numbers they are giving are in the 0.5 - 4 second range (this is the key exchange part, which should not be happening often) on an 8-bit 16MHz AVR. As far as I understand, once the key is established (LTK), using it to encrypt/decrypt data would be no different than the LTK established using "JustWorks or 6-digit" methods. I have a feeling the nRF51822 could go quite a bit faster than the AVR if it has single cycle 32-bit multiplies (not all Cortex-M0s do according to ARM's website).