The nrf_to_nrf Library: Recent Updates & Changes

 The nrf_to_nrf Library: Recent Updates & Changes

Power Management and Encryption

 I've made some somewhat significant changes to the nrf_to_nrf library recently. This lib allows NRF52x based devices to communicate with each other and NRF24 based devices. 

Power Management:

The NRF52x devices are low power devices, capable of utilizing very little power when all the peripherals are disabled. There was an issue brought to my attention by a user, identifying that the radios were making use of the HF Clock, Random Number Generator, CCM Encryption peripherals and that the hardware was being enabled in the constructor instead of the begin() function. 

I was able to modify the library so that the required peripherals are en/disabled only as required and on calls to powerUp() and powerDown() functions. Users need to keep this in mind, since there may be other needs for these peripherals, which may need to be re-enabled after powering down the radio.

This is fixed in the latest release v1.2.14

Authentication & Encryption:

NRF52x devices may also have a CCM mode encryption capability built in. If so, it was not being configured correctly, and the MAC/MIC verification was actually failing prior to recent updates. Changes were made to correctly copy the MAC/MIC to the receive buffer & the modes are now set prior to encryption/decryption to ensure proper MAC/MIC integrity. A verification is also performed after decryption to ensure the integrity of the MAC/MIC. 

This will be fixed in the next release and is available in the source code on GitHub.

Encrypted Audio Comms with XIAO 52840 Sense

Encrypted Audio Comms with XIAO 52840 Sense

The beginnings of wireless audio comms

I've been playing around with the NRF52840 boards I have, and now that I have basic audio functionality working via PDM microphone and PWM audio output, the next thing to do is test out an encrypted wireless communication scenario, so that's what I've done.

The devices use the AutoAnalogAudio and nrf_to_nrf libraries created by me to communicate wirelessly. I've also enabled encryption at the nrf_to_nrf layer, and the related code is an example of implementation, with the device randomly generating a new key and re-keying every 30 seconds. This will prevent others from decrypting the payloads or performing replay attacks outside the 30-second windows. 

This means that users would need to start the devices at the same time (within a 30-second window), so they start-up using the same key. After 30-seconds, a new key is generated and configured, so both devices will then use the same new key. The receiving device ensures that the old key matches before accepting the new key, so unauthorized users can't simply send a new key or replay an old key. Any power down of either device will result in lost communication unless the other device is restarted within the same 30-second window.

To use the sketches (posted lower down), users would need a XIAO 52840 Sense board and both of the aforementioned libraries installed, then just run the code. No wires to connect, no power supply issues to worry about, no counterfeit nrf24 devices to worry about, just a straightforward device that works.

There are still a few issues with synchronization of the audio vs how the device handles PWM data. Essentially, you can have the PWM pin default to a LOW or HIGH state when the current PWM sequence ends, which happens during radio communication when packets are lost or slow to transmit. Compared to other devices I've worked with, which maintain the current state of the pin when PWM or DAC data ends, this device will revert the pin to either HIGH or LOW which causes a popping or clicking sound. 

I'm not sure how to work around this currently, but will continue to experiment to try and achieve better results. In the mean-time users can try out the prototype code by downloading the sketches here: https://github.com/TMRh20/Sketches/tree/master/XIAO-EncryptedAudio

NRF52840 and Arduino: Encrypted and Authenticated Radio Mesh Networks

 NRF52840 and Arduino: 

Encrypted and Authenticated Radio Mesh Networks

In a recent post, I mentioned using the on-board encryption module of the NRF52840, and I've made some decent headway so far! I've finally gotten my encrypted driver working with RF24Network and RF24Mesh and am pretty happy with the results. 

One of the nicest parts of this is it doesn't add any overhead to RF24Network or RF24Mesh itself, since the encryption is incorporated at OSI layer 2. This means that when we transmit a 32-byte payload with RF24Network or RF24Mesh, all those layers see is the unencrypted data. The radio at layer 2 will add some data onto each payload and encrypt it, then decrypt it and present the unencrypted data to the higher layers.

For example, the current overhead of this implementation for encryption is 12-bytes. A 5-byte Initialization Vector (IV), a 4-byte Message Authentication Code (MAC) and a 3-byte packet counter. The radio driver adds this data on in the background, so if you have a 24-byte payload to send, RF24Network adds on its 8-byte header and the 32-bytes of data is sent to the radio driver. The radio driver will then encrypt the data, send an actual 44 bytes of data over-the-air, then decrypt it and present 32-bytes of data back to the RF24Network layer.

Tip: If using this library with the RF24Network or RF24Mesh layers, open RF24Network.h and set the MAX_FRAME_SIZE to 111. Then, per the included examples, the higher layers will handle the larger packet sizes that the NRF52840 is capable of. Make sure to set it back to 32 for communication with nrf24 devices.

There are still a number of questions I have regarding this implementation, but in any case, the library is functional, but don't quite expect full security just yet. There are a number of things to be investigated and worked out regarding how exactly this CCM module is supposed to be driven.

Another thing that is intriguing here is the break from the OSI model, since encryption is typically defined to be implemented at the presentation layer, way high up on the stack. I don't know why, but it feels like a better opportunity to encrypt as much of the data as possible, publicly transmitting only what absolutely needs to be public information. The design of the RF24 communication stack generally follows the OSI model, so the hope is that this will make up for a lack of presentation layer moving forward. It looks like some tasks can still be left up to the presentation layer, like rekeying and managing timestamps to prevent things like replay attacks.

The library with encryption enabled has now been released, get it via Platform IO, Arduino Library Manager or directly from GitHub for the latest changes. Note that Platform IO will install the proper RF24Network and RF24Mesh dependencies, while Arduino Users would need to install the separate RF24Network and RF24Mesh branches manually for now.