Encryption in data

RE: Encryption in data

Karl Ylvisaker — Mon, 21 Sep 2020 15:18:14 GMT

[quote user="four_ice"][/quote]

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.

[quote user="four_ice"]if yes, then how this packets would be encrypted as I think it can be decoded by any receiver as well[/quote]

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

RE: Encryption in data

Zero.cool — Mon, 21 Sep 2020 14:31:52 GMT

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

RE: Encryption in data

Karl Ylvisaker — Mon, 21 Sep 2020 13:48:08 GMT

Hello,

[quote user="four_ice"]Thank you for response.[/quote]

No problem at all, I am happy to help!

[quote user="four_ice"][/quote]

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.

[quote user="four_ice"]its good suggestion to use LESC but on the receiver end how to handle decoding,?
Could you point to any example, document or reference.[/quote]

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

RE: Encryption in data

Zero.cool — Mon, 21 Sep 2020 11:55:48 GMT

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,

RE: Encryption in data

Karl Ylvisaker — Mon, 21 Sep 2020 11:34:22 GMT

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

RE: Encryption in data

Zero.cool — Fri, 18 Sep 2020 15:20:51 GMT

could you please elaborate?

RE: Encryption in data

awneil — Fri, 18 Sep 2020 13:28:17 GMT

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