Encryption feature

owar · August 5, 2019, 10:46am

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.

hub.martin · August 6, 2019, 8:31pm

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.

owar · August 7, 2019, 4:41am

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?

hub.martin · August 7, 2019, 6:32am

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.

owar · August 7, 2019, 7:23am

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.

owar · August 7, 2019, 7:45am

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

owar · August 7, 2019, 9:59am

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?

ra216 · August 7, 2019, 1:26pm

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).

hub.martin · August 7, 2019, 4:08pm

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.

hub.martin · August 7, 2019, 4:28pm

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.

github.com

bigclownlabs/bcf-sdk/blob/a368c81b4260083a0dad3de07ba34ff3d8479074/bcl/src/bc_radio_pub.c#L24


__attribute__((weak)) void bc_radio_pub_on_buffer(uint64_t *id, void *buffer, size_t length) { (void) id; (void) buffer; (void) length; }
__attribute__((weak)) void bc_radio_pub_on_state(uint64_t *id, uint8_t state_id, bool *state) { (void) id; (void) state_id; (void) state; }
__attribute__((weak)) void bc_radio_pub_on_bool(uint64_t *id, char *subtopic, bool *value) { (void) id; (void) subtopic; (void) value; }
__attribute__((weak)) void bc_radio_pub_on_int(uint64_t *id, char *subtopic, int *value) { (void) id; (void) subtopic; (void) value; }
__attribute__((weak)) void bc_radio_pub_on_uint32(uint64_t *id, char *subtopic, uint32_t *value) { (void) id; (void) subtopic; (void) value; }
__attribute__((weak)) void bc_radio_pub_on_float(uint64_t *id, char *subtopic, float *value) { (void) id; (void) subtopic; (void) value; }
__attribute__((weak)) void bc_radio_pub_on_string(uint64_t *id, char *subtopic, char *value) { (void) id; (void) subtopic; (void) value; }
__attribute__((weak)) void bc_radio_pub_on_value_int(uint64_t *id, uint8_t value_id, int *value) { (void) id; (void) value_id; (void) value; }




bool bc_radio_pub_event_count(uint8_t event_id, uint16_t *event_count)
{
    uint8_t buffer[1 + sizeof(event_id) + sizeof(*event_count)];


    buffer[0] = BC_RADIO_HEADER_PUB_EVENT_COUNT;
    buffer[1] = event_id;


    bc_radio_uint16_to_buffer(event_count, buffer + 2);


    return bc_radio_pub_queue_put(buffer, sizeof(buffer));
}

owar · August 7, 2019, 5:11pm

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.

hub.martin · August 7, 2019, 7:19pm

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.

owar · August 8, 2019, 7:40am

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);

hub.martin · August 8, 2019, 2:59pm

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.

findmyname · August 21, 2019, 8:23pm

Hi all,
I’m reading through this topic and i feel that i should react …
I totally agree with @owar that storing an important info in a plain text is bad …
I classify important info to all events related to security - doors/windows opening, movement detection, etc.
BUT i think everything (communication) should be encrypted e.g. if attacker steal all temperature events it could be used to detect whether somebody is present in a house/flat. Maybe i’m paranoid but i work in IT

I see some open source AES algorithm for C already implemented - see here. Why don’t port it to BigClown architecture? Furthermore we can do some community project

This doesn’t sound to be “safe” - i guess that event ID is in BigClown code so anybody can read it up?

Thanks

hub.martin · August 22, 2019, 4:25pm

Yes, that “plaintext” IDs are not safe. I’m just trying to explain what is in the radio packet.

We have AES accelerator in the STM32 chip itself. It is not hard to make it work, but it is hard to make it right. And also use the ATSHA chip for signing the message. It was also necessary to have RTC working which is now done in the SDK. We have also some improvements in radio packet format, so in future we would be able to use Murata modules with Semtech radio for BigClown, LoRa or Sigfox.

And all this we would like to make in a single step so users don’t have to reflash all modules because we’re changing radio stack every few months.

I’m sure @michal.muhlpachr who has a lot of encryption knowledge can help me here And maybe @Karel who did a lot of work with different radios.

UPDATE: Of course, we would welcome and support any community effort to improve BigClown open-source project. Start a new thread and we can together discuss all ideas there.