Question about the new nRF5340 and its NFC capability

[Nicholas Lee]

I am currently using the nRF52840.

I was disappointed to discover that the NFC communications module in this chip could not be used to provide out-of-band Bluetooth key-transfer between two nRF52840 devices, as the nRF52840 only acts as a passive NFC tag, and not as an NFC transmitter.

Does the new nRF5340 chip fix this glaring omission in functionality?

If not, it does not seem possible to properly secure the communications between two Nordic Bluetooth chips.

Is there a practical work-around that allows two nRF devices (with no keyboard or display) to have secure communications?

[Andreas]

Hi,

 

nRF5340 also has a NFC tag implementation, meaning it can not read/communicate with other tags. Unfortunately it is hard to please everyone, meaning those who might find this useful and those who do not, who just want to save the extra cost that the NFC reader would add.

Seeing as there is nRF5x on both sides you might not need NFC read functionality though. As you have full control over the device, you can e.g. use the radio to create some 'NFC-like' pairing functionality or OOB.

 

Best regards,

Andreas

[Nicholas Lee]

I would love to know how I am supposed to "use the radio to create some 'NFC-like' pairing functionality or OOB.", when the Bluetooth radio itself is the "Band" and the keys need to be exchanged "Out-of-band" to be secure.

If the keys are sent via Bluetooth before encryption has been established, then they can be intercepted and compromised. However, we can't establish an encrypted link to safely transfer the keys without having already exchanged the keys.
This is catch-22, and without an OOB link (like NFC) to exchange the keys in a way that cannot be intercepted at long range, communication between two nRF chips has no security.

Please provide unambiguous detail of how this paradox is resolved. Thank you

[Andreas]

Hi,

 

You should probably write your own simple protocol or feature to exchange the keys, not use Bluetooth. Using -40dBm TX power the signal should not reach very far, further limiting the range can be done externally if needed. Similar could potentially be implemented using a set of LEDs and photosensors.

If this does not satisfy your requirements that is fair, but unfortunately we can not support this without needing an external IC for the NFC read bit.

 

Best regards,

Andreas

[Nicholas Lee]

The entire industrial IOT market relies on genuinely-secure comms being established between embedded devices (without the use of a commercial mobile phone to facilitate the pairing), so this is a problem that needs solving if Nordic are to avoid limiting their market share. From a business perspective, it is well worth Nordic investing some engineering effort to provide worked-solutions for this that customers can then implement.

The cheapest solution from a product BOM point of view is to use your suggestion of a proprietary short-range radio protocol.

However, you didn't say how this suggestion can actually be implemented on the nRF chip. How can the radio be controlled directly in this manner (with what set of function / library calls exactly???).

As we will be using a CE certified Bluetooth module containing an nRF52840 chip, how can we do this without voiding the expensive-as-heck (in both time and money) radio certification?

The external NFC reader/transponder chips I have found so far are nearly as expensive as the nRF chip itself, goodness only know why they are so expensive. Is there a way with discrete components (FETs) to modulate the NFC coil at 13.56MHz for transmit, and then use the nRF chip's existing internal module for receive?

The old TV-remote trick of using IR LEDs and photodiodes (in both directions), seems like a nice low-tech solution, although it would require a case modification or the use of an IR transmissive plastic.

[Andreas]

Hi,

 

Nicholas Lee said:

The entire industrial IOT market relies on genuinely-secure comms being established between embedded devices (without the use of a commercial mobile phone to facilitate the pairing), so this is a problem that needs solving if Nordic are to avoid limiting their market share. From a business perspective, it is well worth Nordic investing some engineering effort to provide worked-solutions for this that customers can then implement.

I see your point, and I wish we had something to offer on this. In the end this is a business decision, we have to choose what to include and not, and I suppose NFC reader support came in too short. I will forward your thoughts with regards to future products, but as for nRF5340 I am afraid it is a bit too late to add such a complex module.

 

Nicholas Lee said:

However, you didn't say how this suggestion can actually be implemented on the nRF chip. How can the radio be controlled directly in this manner (with what set of function / library calls exactly???).

We have some proprietary protocols with libraries and example code, see Enhanced Shockburst, that you might be able to use. If not, there is nothing preventing you from controlling the radio on register level as long as you do so while the Softdevice is not running. This might be the best way to do it as you can customize it just as you like, but at the same time might take the most work to implement.

 

 

Nicholas Lee said:

The external NFC reader/transponder chips I have found so far are nearly as expensive as the nRF chip itself, goodness only know why they are so expensive. Is there a way with discrete components (FETs) to modulate the NFC coil at 13.56MHz for transmit, and then use the nRF chip's existing internal module for receive?

I have not seen anything similar and I am not sure how easy this will be as I do not see an easy way for the NFCT peripheral to distinguish between when the other side is generating the field and when it is generating the field itself. You would most likely have to try it out by accessing the NFCT directly through the registers. Also there is no 13.56MHz source access in nRF5340, so you would have to add this also externally.

 

Best regards,

Andreas