Dear Nordic,
I am using nRF52840 chip for BLE Advertising I want to encrypt this Advertising
I Read a CCM-AES encryption in BLE is it right way to this 31 bytes advertising packet encrypting or any other method to encrypt and also i Want to decrypt this advertising packet on Receiver side. I need a help to solve this
Is it CCM-AES encryption is good for my solution (i just read only its theory where i start to implement this on my Application)
Need some help in this
Hi Alan
I assume you are using a BLE SoftDevice to set up the advertising?
There are many ways to encrypt and advertise packet, but using CCM-AES is definitely an option. If you take a look at the nrf_crypto library in the nRF5 SDK, there are functions included for doing AES operations using a multitude of algorithms.
On the nRF52840 these algorithms will utilize the Cryptocell module, to accelerate the operations and reduce overall energy consumption.
The main challenge when using AES is how to safely exchange the encryption key. Ideally you want unique keys in every device, and have some way to configure the receiver with keys for the advertiser it is allowed to read (then you can map the key to the BLE address, in case you want to be able to receive packets from multiple advertisers).
You could also have a look at the Eddystone EID beacon standard, but this might be a bit overkill for your application.
Best regards
Torbjørn
Thank you Torbjorn
Actually I have one reader and several advertiser
I want to this one reader to decrypt packets that coming from several Advertiser
I read some AES methode that describes its work with nonce,counters and result of past encrypt or decrypt etc...
can you suggest a better way to solve this problem (using nRF52840)?
Hi Alan
I can't think of any easier way to do this without compromising the security.
For a general introduction to AES encryption I find this Wiki article to be very helpful, in particular the section called Counter (CTR) which is very similar to how encryption is done in BLE.
Basically you encrypt the nonce and counter with your AES key, and XOR the result with your data.
Then all the receiver has to do is encrypt the same nonce and counter with the same AES key, and XOR the incoming cipher-text to get back the original data (if you XOR something with the same number twice you get back the original result).
The critical aspect is how you distribute the nonce and AES key to the two devices.
In many connected systems the counter will be updated automatically in the transmitter and receiver end, but since you are using advertising you can not guarantee that the receiver will pick up all the packets.
For this reason you would probably have to include the counter in clear text in each advertising packet.
This might sound risky, but as long as the receiver never accepts two packets with the same counter value it is safe (a simple way to do this is to require the counter to increment for each new packet).
The difference between CCM and counter mode encryption (CTR) is that CCM adds an authentication stage to the encryption phase which ensures that the receiver can validate that incoming packets are from the intended target. This allows you to detect if packets have been tampered with, or if someone is simply sending you random data.
The result of the CCM stage is a 4 byte MIC (message integrity check) which needs to be embedded to your payload to verify it's authenticity.
In total then you will need to factor in room in your payload for both the 4 byte MIC and the 4+ byte counter for each transmitted payload.
Best regards
Torbjørn
Hi Alan
I can't think of any easier way to do this without compromising the security.
For a general introduction to AES encryption I find this Wiki article to be very helpful, in particular the section called Counter (CTR) which is very similar to how encryption is done in BLE.
Basically you encrypt the nonce and counter with your AES key, and XOR the result with your data.
Then all the receiver has to do is encrypt the same nonce and counter with the same AES key, and XOR the incoming cipher-text to get back the original data (if you XOR something with the same number twice you get back the original result).
The critical aspect is how you distribute the nonce and AES key to the two devices.
In many connected systems the counter will be updated automatically in the transmitter and receiver end, but since you are using advertising you can not guarantee that the receiver will pick up all the packets.
For this reason you would probably have to include the counter in clear text in each advertising packet.
This might sound risky, but as long as the receiver never accepts two packets with the same counter value it is safe (a simple way to do this is to require the counter to increment for each new packet).
The difference between CCM and counter mode encryption (CTR) is that CCM adds an authentication stage to the encryption phase which ensures that the receiver can validate that incoming packets are from the intended target. This allows you to detect if packets have been tampered with, or if someone is simply sending you random data.
The result of the CCM stage is a 4 byte MIC (message integrity check) which needs to be embedded to your payload to verify it's authenticity.
In total then you will need to factor in room in your payload for both the 4 byte MIC and the 4+ byte counter for each transmitted payload.
Best regards
Torbjørn
