Encryption in data

[Zero.cool]

Hi Team,

we are working on nrf52 and we doing encryption of the data.

on the receiver end I can understand if there is connection , the keys will be exchanged and after that the receiver can decode advertisement packets.

But I would like to know that without connection is there possibility to decodethe advertisements on receiver end as we are planning to send some advertisement with information which can be read by receiver without connection

Could there be way by which the receiver can decode this encrypted advertisement.

Thanks,

[awneil]

surely, the method by which the encrypted data is transported is irrelevant to how you decrypt it?

[Zero.cool]

could you please elaborate?

[Karl Ylvisaker]

Hello,

What @awneil is referring to here is the fact that if you intend to encrypt data, send it, and then decrypt it then it does not matter much how you transport that data - i.e the fact that you are doing this through advertisements does not matter for how you may go about encrypting the data, as long as both sender and receiver knows what to expect from these transfers.

If I may ask, have you considered using a connection with LESC in stead of advertising encrypted data here? This way, the encryption will be taken care of for you by the SoftDevice.
Please keep in mind that when you are using advertisements you have no guarantee that the receiver has actually gotten the messages - so if you are transferring important data, then you may loose some of it without knowing, when using advertisements to transport it.

Please do not hesitate to let me know if I should have misunderstood your question, or if anything still should be unclear.

Best regards,
Karl

[Zero.cool]

Hi Karl Ylvisaker
Thank you for response.

Yes, correctly understood,

but here some advertisement (without connection ) if gets dropped or non received by receiver , that is still ok.

its good suggestion to use LESC but on the receiver end how to handle decoding,?
Could you point to any example, document or reference.

Thanks,

[Karl Ylvisaker]

Hello,

Zero.cool said:

Thank you for response.

No problem at all, I am happy to help!

Zero.cool said:

Yes, correctly understood,

but here some advertisement (without connection ) if gets dropped or non received by receiver , that is still ok.

Thank you for confirming this.

Zero.cool said:

its good suggestion to use LESC but on the receiver end how to handle decoding,?
Could you point to any example, document or reference.

Luckily, the SoftDevice ( if it is an nRF device ) or BLE stack in the other end take care of this for you, no need for you to do anything in regards to the encryption.
You may see this being done in the BLE Glucose monitor example application from the SDK.
The example uses LESC with MITM protection. The example contains a lot of other functionality too, but the interesting parts for you to see is mainly the peer_manager_init, with regards to configuring LESC and security.

Best regards,
Karl

[Zero.cool]

Luckily, the SoftDevice ( if it is an nRF device ) or BLE stack in the other end take care of this for you, no need for you to do anything in regards to the encryption.

Thank you for response.
But on other side of receiver its not nRF device, Its plain gateway which will be received the advertisements from nRF 52 transmitter.

Still it would do?
if yes, then how this packets would be encrypted as I think it can be decoded by any receiver as well

[Karl Ylvisaker]

Zero.cool said:

But on other side of receiver its not nRF device, Its plain gateway which will be received the advertisements from nRF 52 transmitter.

Still it would do?

Yes, this is fine. All certified BLE stack implementations will conform to the BLE protocol, and the LESC is part of the protocol, no worries.
I can not speak to how you must go about doing this with the other BLE stack, but I should hope and expect it to be roughly as easy as it is to configure using our SoftDevices.

Zero.cool said:

if yes, then how this packets would be encrypted as I think it can be decoded by any receiver as well

It is true that any receiver could potentially decode it - but that is needed to conform to the BLE specifications. Please have a look at the answers in this ticket, to see a more in-depth explanation of the LESC encryption.

If you are still unsure of how this can be safe I recommend taking a look at the underlying Diffi-Hellman key exchange.

Best regards,
Karl