Encryption feature

Hello,

I just want to ask if the data encryption or at least data authentication is now suported or if there is some time estimate of doing so. I would like to use BC in my “smart” house but without encryption I would be scared.

Hello,
we are using ATSHA chip with AES in our close-source Cooper platform. We would like to port this communication to the Bigclown but we would like to also design and change the packet radio format. Right now we use also murata module (the one on LoRa Module) and the radio packet could not be decoded with Spirit1 radio on Core Module. We would like to unite the format so almost any 868 MHz radio module could be tuned to BigClown network.
However this takes lot of time. We also do lot of custom hardware development. So we have no idea when this will be done.

Ghetto style security
On BigClown there is new bc_rtc C functions to work with time, so this is a step closer to create a check for example for replay attack.

One option to solve this quickly could be to add the signature with some hash and timestamp to every message and check the message in the user application instead of low-level radio protocol. I can imagine that node’s custom topic subscribe can be used to receive string which will contain command for eample for relay, timestamp and also some hash/chesksum. The received message will be checked for replay attack by comparing the timestamp and the hash will be checked to validate that the packet was send from the correct Radio Dongle.

I’m really not an expert in security, other colleagues are. I know that hash with some salt cannot be as strong as AES. This is just my opinion what can be quickly done. Any sugggestions are welcome.

Thank you for answer. So you suggest protection from replay attack. But where is protection against anyone else with Bigclown module receiving my data from other modules? Is the data protected somehow or is it in plaintext?

You are right - what I’ve explained is just “signing” the radio packet. Not encrypting. If you are concerned that also temperature and CO2 data needs to be encrypted so no one can read them, you need some cypher and encryption keys on device. But it is not always necessary, for example Sigfox sends not encrypted data, just signed.

Yes, it is OK for me to use just signage for modules like outside climate sensor or alike but I would rather not use plain text for information about movement in rooms inside my house for security reasons. I will try to create some at least low level encryption myself than.

Martin is there any description of how the radio packet looks? With data and topic together?

I made simple XOR encryption for start. And I would like to send the encrypted message with

bc_radio_pub_string

But this function takes only const char which is not suitable for me because my message will change and is not constant. Is there another way to publish string which will change through time?

Unfortunately, they were promising safety first when the campaign was launched. Unfortunately, business is business, and so far only promises, while I liked the concept very much. Now I have to say that they are on the same side as others … security as Emmental cheese (all hole).

The packet format is explained here. But I’m 100% sure it is not correctly documented right now. At least the CRC is just 1 byte in reality. I need to ask @Karel where to find current implementation and update the document.

That const char thing in bc_radio_pub_string does not mean the string cannot be changed AFAIK. It means that the function promises it will not change the content of the string inside.
See https://bytes.com/topic/c/answers/676516-whats-use-const-char-parameter

So what you see is just compiler warning, just cast the parameter type to (const char*)str and you should be fine.

The basic events (PIR, button presses, temperatures) are not transmitted as a plaintext. Over the radio is sent the node ID and event ID. Both is translated to text alias and MQTT topic in the Radio Dongle.

Custom topics and bc_radio_pub_string content is in plaintext.

I have tried the casting without any luck. When I try bc_radio_pub_string("4/3/2/1","ahoj"); It works and I see the message on hub. But when I try bc_radio_pub_string("4/3/2/1",(const char*)output); where output is char output[] = "ahoj"; it does not.

What means “it does not”?
Does the MQTT message arrive but without payload? Or does not arrive at all?

Try to add static in front of your declaration if it is declared in the function.
static char output[] = "ahoj"
But in the code I see that the both topic and payload is immediatelly copied to transmit queue… So this should not be the issue.

Can you create a minimal project where you test just sending the string to see if it will work? If not, share the app folder so I could debug the exact code you have and find where the issue is.

It does not = I do not see any incomming message in Node-RED. But I think I have found the core of this problem. It looks like some chars of string (which is encrypted so it contains weird symbols) are problem to send.

Try this:

 char test1[] = "test1\0";
 char test2[] = "PZ\\^ypl5\0";
 char test3[] = "test2\0";

 bc_radio_pub_string("4/3/2/1",test1);
 bc_radio_pub_string("4/3/2/1",test2);
 bc_radio_pub_string("4/3/2/1",test3);

That makes sense. It may be sent over radio but the Dongle and Python might have issues because it is really expecting a string. You can use bc_base64_encode and decode functions.

Also bc_radio_pub_buffer can be used to send binary data from the Core to the Dongle. In MQTT it appears as an array of numbers/bytes.

The other way from Dongle to Core does not have this binary array. You can send just types defined in bc_radio_sub_pt_t.