[security] Introducing signing support to MySensors

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

[carlierd]

@Anticimex @tomkxy
Perhaps the arduino and RFM69 can't run at 1MHz. I have capacitors and I tried with two different power sources. Without signing it's better but still a lot of st=fail. No matter, it was just for testing purpose :)

[tomkxy]

@calierd I cannot comment on RFM69 since I have non in operation. Sorry, try to place the nodes further apart and look whether it changes.

[duovis]

@Anticimex Thank you for the effort you have put into signing, this is great!

Would it make sense to explore the I2C version of ATSHA204A ? The reason I'm asking is speed.

[Anticimex]

Thanks @duovis,
Yes, I welcome anyone who has the HW to provide a IO routine for I2C-variants of ATSHA204A. I don't have the hw myself though.

[duovis]

@Anticimex Ok, I'll try to play with it and see if I can come up with something that works on I2C.

[Anticimex]

@duovis Great. I'll happily review any code. You should only need to worry about the low level stuff.

[Soloam]

Hello all!

Two fast question! Can I have nodes working with ATSHA204A chip and others with software?

And, can I have nodes with signing on and others off? Or if I add signing to my network, all nodes must have it?

Thank you all!

[Anticimex]

@Soloam
You can mix nodes with soft signing and ATSHA signing as you like.
You can mix nodes with signing on and off as well. The GW will only sign messages to nodes that require it, and it will also only check signatures from nodes that require signatures. So you can have one node which support/require signing and another which don't. The GW will be able to exchange messages with both nodes.