[security] Introducing signing support to MySensors

[Anticimex]

@Pierre-P because if a node is lost, you no longer control that node. So anyone could reprogram it to have it identify itself in any way possible. We have to assume an attacker has full source code access, so they can rewrite the signing algorithm to use a fake serial as salt for the signature to trick the GW to believe it is a new node. A whitelist mean the attacker has to know the ID/serial of one of the nodes you trust. Which they won't know unless they can get access to that node.

[Pierre P]

Thanks for the complet answer !

[Anticimex]

@Pierre-P you are welcome. Security is best when it is totally open and the implementation is aware of this. That makes it quite difficult to circumvent, and it also allows to be challenged. That way, with many eyes examining it, it gets stronger and stronger :) I welcome all attempts to crack it. White or black hat style.

[Soloam]

Hello all! What would require less flash memory? Signing by ATSHA204A Chip or by software?

[Anticimex]

Signing by ATSHA204A require less flash memory, but takes longer to execute (at least on 8MHz AtMega328).

[Soloam]

@Anticimex assumed that, but this post on the forum got me confused: http://forum.mysensors.org/topic/2005/software-aes-encryption-for-nrf24/19

According to that post, he uses software on the SenseBender with Encryption because, according to him "...encryption and ATSHA204A is to big for the SenseBender... ".

I would like to add Signing and encryption to my nodes, but I don't know if it will fit on my Atmega328 flash!

[Anticimex]

Well, how much space you have depend on your sketch and on the features you enable in the library, so it is impossible to predict how your code will fit. I suggest you just try to enable what you want and compile, and you'll know :)

[mfalkvidd]

The easiest way to find out is to look at the output in Arduino IDE when you click "Verify".

There are some factors that affect size:

• Size of bootloader
• MySensors version (different versions of the library have different size requirements)
• MySensors features used (software signing, encryption, debug on or off, etc)
• Size of other libraries you use in your sketch
• Size of your sketch

[mfalkvidd]

ouch, @Anticimex was a bit faster :)
oh, and the problem in the thread you quoted @Soloam is encryption. At least at that time, encryption used too much space so there wasn't space to include either hardware or software signing.

[Soloam]

Yes, encryption and signing! I'll try to order this and test it out! http://www.ebay.com/itm/5PCS-ATSHA204A-STUCZ-T-IC-CRYPTO-4-5KB-SWI-204A-SHA204A-/191782104901?hash=item2ca71aaf45:g:zEQAAOSwwE5WZk9O

[Anticimex]

And on development branch, @tekka has an open PR where he has cut down significantly on the size of the NRF24 driver as well.

[Anticimex]

And you might also have read mine and @mfalkvidd's stand on encryption, so don't be discouraged if you find that you can't fit both. Just skip the encryption in that case. It adds far less in security than signing does.

[Soloam]

Yes, if I have to discard one it would be encryption! Thank you for the help @Anticimex and @mfalkvidd

[carlierd]

Hello,

I currently testing various bootloader to measure impact on CPU speed on the power consumption.
I got a lot of nonce error when using 1 MHz configuration.

Is signing feature possible at 1 MHz ?

Thanks.

David.

[Anticimex]

@carlierd could you specify a bit clearer what you mean by "nonce error"? Signing should work, but the atsha driver is not tested @ 1MHz and might get bad timing. Also, for soft (and hard) signing, if 1MHz is used, performance could degrade to the point that the nonce timeout needs to be increased.

[carlierd]

@Anticimex

Hello.

I am using soft signing.

find parent
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
read: 255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
sensor started, id=255, parent=255, distance=255
find parent
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
read: 0-0-255 s=255,c=3,t=8,pt=1,l=1,sg=0:0
parent=0, d=1
read: 0-0-255 s=255,c=3,t=8,pt=1,l=1,sg=0:0
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
read: 0-0-255 s=255,c=3,t=4,pt=0,l=1,sg=0:9
send: 9-9-0-0 s=255,c=3,t=15,pt=2,l=2,sg=0,st=fail:1
read and drop: 9-9-0 s=255,c=3,t=15,pt=2,l=2,sg=0:1
read: 0-0-9 s=255,c=3,t=15,pt=2,l=2,sg=0:1
send: 9-9-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=fail:
nonce tr err
send: 9-9-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=fail:
nonce tr err
read and drop: 9-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
read: 0-0-9 s=255,c=3,t=17,pt=6,l=25,sg=0:0129D04B64916F5E805EFDF704C34F56B47E547FDDE93805BE
id=9
send: 9-9-0-0 s=0,c=0,t=0,pt=0,l=0,sg=0,st=ok:
send: 9-9-0-0 s=1,c=0,t=30,pt=0,l=0,sg=0,st=fail:
[Setup duration: 9928 ms]
send: 9-9-0-0 s=0,c=3,t=16,pt=0,l=0,sg=0,st=fail:
nonce tr err
send: 9-9-0-0 s=1,c=3,t=16,pt=0,l=0,sg=0,st=fail:
nonce tr err
send: 9-9-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=fail:
nonce tr err
Value is 1   Cycle is 1   3.39 v   [753 ms]

Thanks,

David.

[Anticimex]

@carlierd you have a lot of st=fail, so your problem is radio related, not signing related. I also see non nonce related messages fail so you need to stabilize your rf connection before signing can work. And since signing uses the maximum payload size, it has the least probability to succeed to be sent, so you could find that unsigned messages work while nonces and signed messages fail, but this is normal of the rf link is not fully working. If you get st=fail, it is a radio problem. See this discussion for details: http://forum.mysensors.org/topic/3386/mqttclientgateway-broken-after-upgrade-signature-failure

[carlierd]

@Anticimex Hello. Everything is working at 16 or 8MHz so I am pretty sure it's not an issue with the material.
I will burn the bootloader again and create a new post if it's still not correct. I will also disable signing feature to be sure there is no impact.

David.

[Anticimex]

@carlierd well, st=fail indicate transmission failure so it is pretty clear that you have a issue with rf, at least on that frequency. st=fail is not signing related. But, like previously discussed, enabling signing can trigger more st=fail because the payload gets bigger and is more sensitive to noise.

[tomkxy]

@calierd You can have a look here at the discussion I had with a similar problem which I was able to resolve finally. See the last reply in the aforementioned thread where I summarized how I resolved it, eventually.