💬 Security & Signing

[skywatch]

Is it possible to use the ATSHA204A along with the Rpi directly attached NRF24L01+ gateway? I can see how to attach the ATSHA to the nodes, but how to attach it to the pi?
Thank you.

[Anticimex]

@skywatch no, not to my knowledge. The atsha driver is Arduino specific. I would happily review a pull request that ports the bit banged driver for Linux though :)

[Anticimex]

@skywatch the use case for atsha204a backed signing on rPi is limited though. As it is used as I gw (I presume) it is considered "protected" and is less sensitive for key dumping.

[skywatch]

Thank you for the quick response. Maybe i mis-understand this?
I have got 10 ATSHA chips that I would like to attach to arsuino nodes to use with a raspberry pi based gateway/controller combo. Do I therefore need to attach the ATSHA to the rpi, or could I still use the ATSHA hardware on the arduinos without an ATSHA attached to the rpi?
I had assumed that the atsha chip would be needed at both ends for signing to work. Maybe that's not how it works?

[Anticimex]

@skywatch no, the software port is fully compatible with the atsha204a. So you can use Arduino nodes with atsha204a and they will work just fine with your rPi with software signing. Just as long as they all use the same hmac key.

[sineverba]

I'm hoping that I did done all ok.
I've personalized the Arduino that acts as Gateway (connected via USB to a Raspberry PI) and I've personalized first node (a DHT22).
Both with software signature.

This is the cat from Raspberry / Gateway Arduino:

0;255;3;0;9;TSF:MSG:READ,3-3-0,s=0,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;Skipping security for command 3 type 16
0;255;3;0;9;SHA256: 37FA7FD8F19D55E99C952F467E45D9A7439AAAAAAAAAA                                                                             AAAA
0;255;3;0;9;Skipping security for command 3 type 17
0;255;3;0;9;TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:37FA7F                                                                             D8F19D5CE9A07E95992C45D9A7439
0;255;3;0;9;Transmitted nonce
0;255;3;0;9;TSF:MSG:READ,3-3-0,s=0,c=1,t=1,pt=7,l=5,sg=1:59.3
0;255;3;0;9;Signature in message: 010F55F31D04DBFCA0AFC7E139475
0;255;3;0;9;Message to process: 03033336D4201
0;255;3;0;9;Current nonce: 37FA7FD8F19D55E99C955992C45D9A7439AAA                                                                             AAAAAAAAAAA
0;255;3;0;9;HMAC: B50F55F31D04DBFFC7E139475D91093F0A1EABB174B86E9                                                                             E9
3;0;1;0;1;59.3
0;255;3;0;9;TSF:MSG:READ,3-3-0,s=2,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;Skipping security for command 3 type 16
0;255;3;0;9;SHA256: 803B7127EB3B049768C59D328C89862FF731AAAAAAAAAA                                                                             AAAA
0;255;3;0;9;Skipping security for command 3 type 17
0;255;3;0;9;TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:803B71                                                                             27EB3D0DED839579D328C89862FF731
0;255;3;0;9;Transmitted nonce
0;255;3;0;9;TSF:MSG:READ,3-3-0,s=2,c=1,t=38,pt=7,l=5,sg=1:3.42
0;255;3;0;9;Signature in message: 010E8B790708A39930F73D511F48DAECA
0;255;3;0;9;Message to process: 03002E23BAE5A4002
0;255;3;0;9;Current nonce: 803B7127EB3D0DED83957BB5C59D328C89862FF731AAA                                                                             AAAAAAAAAAA
0;255;3;0;9;HMAC: D10E8B79D511F48DAECAFB4A3D89F553A2DDB26F1614
3;2;1;0;38;3.42

and so on...

This is the Pro MIni serial console:

T: 28.00
1023
Battery Voltage: 3.44 V
Battery percent: 102 %
40413 Skipping security for command 3 type 16
40421 TSF:MSG:SEND,3-3-0-0,s=2,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
40429 Nonce requested from 0. Waiting...
40546 TSF:MSG:READ,0-0-3,s=255,c=3,t=17,pt=6,l=25,sg=1:9CC096EF18295BEFAC43638CA2673A1D759B0CEC6E49C3E060
40558 Skipping security for command 3 type 17
40562 Nonce received from 0.
40564 Proceeding with signing...
Message to process: 03002EF24002
Current nonce: 9CC096EF18295BEFA59B0CEC3E060AAAAAAAAAAAAAA
HMAC: 5D8E8A59EF1420406004E1318A650686E19E3A8
Signature in message: 018E8A5BD166D106004E
40740 Message signed
40749 Message to send has been signed
40755 TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=38,pt=7,l=5,sg=1,ft=0,st=OK:3.44
40763 Skipping security for command 3 type 16
40769 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
40777 Nonce requested from 0. Waiting...
40900 TSF:MSG:READ,0-0-3,s=255,c=3,t=17,pt=6,l=25,sg=1:1C17F1A31D500CB0E840B7214BE961E
40910 Skipping security for command 3 type 17
40916 Nonce received from 0.
40919 Proceeding with signing...
Message to process: 03000E66
Current nonce: 1C17FE25D7B26441A31D961EAAAAAAAAAAAAAA
HMAC: D5992FF4CFB6238CD4062397EEE986F47E0BD65020F39C18662
Signature in message: 01992FF4CFB6238C0FDA62397EEE986F47E0
41095 Message signed
41101 Message to send has been signed
41109 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=0,pt=1,l=1,sg=1,ft=0,st=OK:102
41115 MCO:SLP:MS=5000,SMS=0,I1=255,M1=255,I2=255,M2=255
41121 MCO:SLP:TPD

Are they secure communicating? :)

PS I did delete some chars from the HMAC, nonces, etc etc :D

[Anticimex]

@sineverba the best way to determine that is to see if the messages you send arrive :) if you enable signing and require signatures, unsigned or incorrectly signed messages will be rejected.
I see no errors in the log so it seems it works. The logs however don't match up. The hmac:s in one log does not match the hmac:s in the other.

[sineverba]

@Anticimex
I can assure you that messages, nonces, hmacs and signatures are exactly the same in console gateway and in console of arduino mini.
I did delete some chars before posting for.... security (?) :D
Thank you for your answer!

[Anticimex]

@sineverba why did you delete them? There is nothing secret about them. They are sent over your radio link so they are to be considered very public, or signing wouldn't be useful, would it? ;)

[sineverba]

@Anticimex
I understand :)
The last thing: what's the sense of this message:

Skipping security for command 3 type 17

?

Thank you!

[Anticimex]

@sineverba it means that message is not signed. Because it is of a type not suitable for signing. Typically an ack or a handshake message. You can look the type up in the api specification. In this case it is a handshake message (a nonce reply to be precise).

[sindrome73]

Hello!! I'm also trying to implement SOFT Signature, but because of my poor English I have many problems !!
Someone could post the socket of a node + a working MQTT gateway.

So you can study the code and understand how it works !!!

Thanks 1000 in advance to who can help me

[Anticimex]

@sindrome73 There is no difference for a MQTT gw than from other GW:s. There are code examples in the documentation. See this post and follow the Doxygen links.

[sindrome73]

As I said, my English is not good and therefore it is difficult for me to follow the discussions.

That's why I was asking for a snapshot already done, in order to study the code and understand how to solve ....
  If anyone can help me ????

[Anticimex]

@sindrome73 I am afraid it will be difficult to help if you can't read the code. There is code in the documentation, and you ask for code? There is also a sequence of steps required to do personalization, so you have to be able to understand english to some extent, or find someone who can translate for you.

If it helps, I have pasted the code here in case you for some reason can't find it (I assume you use a official 2.0 release):

How to use this

Before we begin with the details, I just want to emphasize that signing is completely optional and not enabled by default. If you do want the additional security layer signing provides, you pick the backend of your choise in your sketch. Currently, two compatible backends are supported; MY_SIGNING_ATSHA204 (hardware backed) and MY_SIGNING_SOFT (software backed). You can either enable these globally in MyConfig.h or in your sketch for sketch specific/local use.

Firstly, you need to make sure to pick a backend to use as described above.

//#define MY_SIGNING_SOFT
#define MY_SIGNING_ATSHA204
#include <MySensors.h>
...

Make sure to set the define before the inclusion of MySensors.h. It is legal to mix hardware- and software-based backends in a network. They work together.

You also need to decide if the node (or gateway) in question require and verify signatures in addition to calculating them. This has to be set by at least one of the node in a "pair" or nobody will actually start calculating a signature for a message. Just set the flag MY_SIGNING_REQUEST_SIGNATURES and the node will inform the gateway that it expects the gateway to sign all messages sent to the node. If this is set in a gateway, it will NOT force all nodes to sign messages to it. It will only require signatures from nodes that in turn require signatures. If it is desired that the gateway should require signatures from all nodes, MY_SIGNING_GW_REQUEST_SIGNATURES_FROM_ALL can be set in the gateway sketch.
If you want to have two nodes communicate securely directly with each other, the nodes that require signatures must send a presentation message to all nodes it expect signed messages from (only the gateway is informed automatically). See signerPresentation().
A node can have three "states" with respect to signing:

Node does not support signing in any way (neither MY_SIGNING_ATSHA204 nor MY_SIGNING_SOFT is set)
Node does support signing but don't require messages sent to it to be signed (MY_SIGNING_REQUEST_SIGNATURES is not set)
Node does support signing and require messages sent to it to be signed (MY_SIGNING_REQUEST_SIGNATURES is set)

Secondly, you need to verify the configuration for the backend.
For hardware backed signing it is the pin the device is connected to. In MyConfig.h there are defaults which you might need to adjust to match your personal build. The setting is defined using MY_SIGNING_ATSHA204_PIN and the default is to use pin A3.
Similar to picking your backend, this can also be set in your sketch:

#define MY_SIGNING_ATSHA204
#define MY_SIGNING_ATSHA204_PIN 4
#define MY_SIGNING_REQUEST_SIGNATURES
#include <MySensors.h>
...

For the software backed signingbackend, an unconnected analog pin is required to set a random seed for the pseudo-random generator. It is important that the pin is floating, or the output of the pseudo-random generator will be predictable, and thus compromise the signatures. The setting is defined using MY_SIGNING_SOFT_RANDOMSEED_PIN and the default is to use pin A7. The same configuration possibilities exist as with the other configuration options.

Thirdly, if you use the software backend, you need to personalize the node (see personalization).

#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES
#include <MySensors.h>
...

An example of a node that require signatures is available in SecureActuator.ino.

[sineverba]

#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7

I image not, but... the pin need to be to same in every node?

And.. will the library auto manage the PIN (in this case the #7) rendering it floating or need to explicity set it as INPUT on sketch?

Thank you!

[Anticimex]

@sineverba It is assumed that you do any configurations in your sketch, before including MySensors.h so no, it does not need to be the same on every node. It just need to be left unconnected. And yes, the library takes care of the rest.

[mfalkvidd]

The pin does not need to be the same.

The library will set it to the required mode, there is no need to do anything in the sketch.

[pepson]

Hi
I have a gateway mysensors on my RPI3 with radio RFM69HW. Is any chance to build gateway on RPI3 but also with chip ATSHA204A ? And how build it...

[Anticimex]

@pepson the driver has not been designed with rPi in mind. And you'd probably be better off with an I2C variant for rPi. But we currently don't offer a driver for that so you'd have to write it yourself.
But, for a gw, you typically keep those secured physically, so using a atsha device is less important, compared to "roaming" nodes.