[security] Introducing signing support to MySensors

[Anticimex]

@Proyectos-Integrasoft I am not sure where to start. I assume you are familiar with c code? The signing solution available in the latest official release (which you find on github, I believe is 2.1.1) require at least fundamental understanding of how to adjust sketch code.
The documentation gives the exact lines to change.
There is, like I said, a step by step guide, and if you follow it you should end up with a properly personalized device. In this case, that is of less importance since you currently do not have a stable enough radio link to use security since you get NACKs for full size payloads (so neither signing nor encryption will work).
So you will have to make that work and get rid of the NACKs, before we should start worrying about personalization.
And like I said before, that is not a signing related issue. You will get the same problem if you try to send full size payloads of any kind. Just try to disable signing and send full size payloads.

[Proyectos Integrasoft]

@Anticimex
Okay, so I'll start by tackling things step by step ... How can I avoid getting NACKs in my log?

[Anticimex]

@Proyectos-Integrasoft as I said; ensuring good decoupling, a stable power supply (measure that to confirm). Also, counterfeit RF24 chips are all over the place that perform under par. There are quite a few threads here on this topic. So please post such questions in those, it is somewhat off topic here :)
Also, setting proper power levels can have a huge impact on the performance.

[ahmedadelhosni]

Hi @Anticimex Actually there is something that I can not understand regarding cryptograhpy. I want to know how other products like Fibaro, Smartthings, etc handles the security ?

Here in our library the SW is not a good idea, why ? I thought beacuse someone can dump the memory .. but is it that easy ? Can't we lock the code and memory ? Also in the hardware ATSHA solution, someone can easily take the chip and intercept our network and sniff it or even send commands as it is explained in the documentation and that's why we don't use security for public nodes as it usualy reports states. But can't we lock the chip ? and by some way only the atmega can communicate with it to get the key by some way ?

I read online that some people are using private and public keys .. if this is the case, then the private key is offcourse saved in the memory. How do they handle this problem ?

Do they use AES , SHA ? which encyption way ?

Also the nRF52, I tried to read a lot and they use private and public keys i guess.

lots of questions and I am confused but I want to know how do they handle protection for public nodes.

Can you please explain this to me ?

Thanks.

[Anticimex]

@ahmedadelhosni some devices, like the atmega, doss not support locking the memory, so the software based signing is inherently insecure in terms of hw theft.
Atsha204a based signing protection specifically against this because the personalizer locks the chip from readout. It is not possible to extract the hmac key from the atsha204a memory and the key is never transmitted OTA (unless you deploy the personalizer OTA).

[Anticimex]

@ahmedadelhosni and regarding reusing a node/atsha204a for attack purpose, we have whitelisting to protect against that. The serials used for whitelisting are also never send OTA (again, unless you send the personalizer OTA).

[ahmedadelhosni]

@Anticimex

1- So if we have a microcontroller that supports locking the memory then the problem is solved ? I know that SAM is being introduced now, Does it support this ?

2- what is then the purpose of locking the ATSHA if we can't extract the HMAC which we depend on it ?

Thanks.

[Anticimex]

@ahmedadelhosni
We lock the atsha to make sure it can't be readable.
It does not matter that samd supports locking or not. The atmega328p does not. For now, we have a security scheme that supports any target, so we have to have a system that works for all.
For MySensors v3, an entirely new security scheme is under consideration. But it will mean dropping support for the atmga328p as it is not powerful enough.
As for what others do, I suggest you ask them :)
Security can be implemented in many ways. Each with drawbacks and benefits. The one currently in use is a scheme that can work on basically any target with reasonable security and performance. It has drawbacks, yes, but at the time of implementation, these were considered acceptable.
For the future, more sophisticated schemes can be used which are easier to use, arguably more secure but more complex in terms of computational power and protocol. The core team is investigating various solutions.

[ahmedadelhosni]

@Anticimex Sorry but I didn't understand the benefit of locking the ATSHA to be unreadable ? :expressionless:
I know we do not lock it so that we can read the HMAC and use it during verification, but what is the usage of a locked ATSHA ?

[Anticimex]

@ahmedadelhosni what do you mean? All cryptography is performed inside the chip. The hmac key never leaves the chip after it has been programmed and locked. Thats the whole point with the atsha204a.

[ahmedadelhosni]

@Anticimex aha okay I understand a bit now. So we put s special hmac that does all cryptography jobs then it gives us something that is used for transmision?

Looks like i have to read the datasheet also :D

[Anticimex]

@ahmedadelhosni I'd suggest you start by reading the documentation on signing linked at the very top of this post. It explains in detail how the signing security is implemented.

[ahmedadelhosni]

@Anticimex yeah I read it several times before but maybe didnt pay attention to tge technical stuff 😂

[Anticimex]

@ahmedadelhosni :) not really needed to be able to use it, but it hopefully helps in understanding it ;)

[ahmedadelhosni]

@Anticimex yeah I know. I have already managed to use Siging in my network and it works.

I just wanted to understand more about how the code works and the technical stuff.

Thanks.

[Anticimex]

@ahmedadelhosni You mean this? :)

[ahmedadelhosni]

@Anticimex Yeah actually I have read this post like 20 times before but I guess I begun to really understand the "technical" stuff today.

So basically what I understood is that we have a HMAC Key, which is generated and is saved in all devices, this is when we do step 1 'generate key' and step 2 'personalize'. Thus when the gateway needs to send to node X, it send to node X asking for a nonce from the ATSHA on Node 2 board. Then node 2 sends the nonce over the air. THe gateway then uses this nonce to produce signed message by first applying SHA then use the HMAC key to produce the signed data. Then the signed data is transmitted over the air to the node X again which does the same operations again and verify that the nonce produces the same signed message in small period of time ( to avoid replay block attacks)

Is my understanding correct :D ?

[Anticimex]

@ahmedadelhosni yes

[ahmedadelhosni]

@Anticimex finally I understood it. Actually I don't like using just the code without fully understanding the implementation. Thanks for support.

I will come with more questions maybe ;)

[Anticimex]

@ahmedadelhosni Feel free to ask, but it is all documented. If what I say does not correspond to what the documentation says, please let me know so it can be improved.