💬 Security & Signing

@pepson I have implemented a sw emulator for the atsha which offers compatible security infrastructure but without readout protection. Readout protection is needed if someone steals your node and extracts your hmac key. Your gw won't typically be stolen, so it don't need readout protection and can rely on the soft signing option which is compatible with nodes using atsha204a personalized with the same hmac key. The rPi port support the atsha204a emulator so you can use that to secure nodes that has a real atsha204a device.

@pepson I don't run on raspberry pi so I don't. But the documentation does have specific configuration examples for raspberry pi, so you have all information needed listed there in "how to use this" section.

@sineverba
Hi
Yes i use radio RFM69HW. I also on 2.3.0 have big problem... and back to 2.2.0. What you have problem on 2.3.0 with radio RFM69 ?

I read all your guide and it is ok. But i dont know what i must put in place:
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0Xaa,0Xbb,0Xcc,0XF9,0X82,0XB2,0X50,0XF2,0XAB}}} // got from gateway setup

Put serial from this:
sudo mysgw --gen-soft-serial-key

We will get:

SOFT_SERIAL | 7850987FA6601F6538

The next line is intended to be used in SecurityPersonalizer.ino:
#define MY_SOFT_SERIAL 0X78,0X50,0X98,0X7F,0XA6,0X60,0X1F,0X65,0X38

To use this key, run mysgw with:
--set-soft-serial-key=7850987FA6601F6538

And i must put my keys to mysensors.conf when i use version 2.2.0 ? Or only when use 2.3.0 ?

Software signing settings
Note: The gateway must have been built with signing
support to use the options below.
To generate a HMAC key run mysgw with: --gen-soft-hmac-key
copy the new key in the line below and uncomment it.
#soft_hmac_key=

To generate a serial key run mysgw with: --gen-soft-serial-key
copy the new key in the line below and uncomment it.
#soft_serial_key=

Encryption settings
Note: The gateway must have been built with encryption
support to use the options below.
To generate a AES key run mysgw with: --gen-aes-key
copy the new key in the line below and uncomment it.
#aes_key=

Too many ack lost and slow communication. And other that I don't remember.

That line on the sketches means that you need add on the node that you want whitelist the serial of gateway.

You got serial gateway on the steps for 2.2.0.

You have it.

You don't need to put anything in no file with 2.2.0. In my guide is NOT mentioned. In my guide, at the bottom, there is the final "set keyes" with only a line OR you can set them everytime you get them.

Please, take your time to read 1, 2, 3 times before type anything. I think it is very clear, and every step is write down for you.

Enjoy

PS Don't offend, I want help you, 'cause I used a bit of times before getting security working. And I used so many time write down a guide. But you need to read and follow carefully

no need to remove. Simply, in your sketches, don't use signing at all.

ok but if on gateway it was generate and setup keys and when in skethces i dont use keys will nody connect? and what the purpose of the signature is then ?
I thought that if the gate has a set of keys and will try to connect noda without a key that it will not connect ....

compile gateway with weak security (make your research, also in my github guide, there is )

create the 3 keyes for gateway

set the 3 keyes for gateway.

clean your EEPROM arduinos with the sketch present in my guide and in examples of library

set the keyes in EEPROM arduinos.

Stop. End. Fin. Fine. These steps are MANDATARY. You NEED to do.

You will have in EEPROM the keyes (arduino) and in gateway.

From now, you select:

a) Do I need security? Perfect, in sketch arduino add #define bla bla bla on top with security and other stuff.
b) Do I NOT need security? Perfect, in sketch arduino DON'T ADD #define bla bla related to security.

But what give me this if i can connect nodes also with defines bla bla bla in skethc and also without define bla bla bla in sketch?
But Do I think right ? In each of these accidents in the eeprom I need to have the keys loaded?

@pepson well for starters, don't start out with whitelisting unless you know exactly what you are doing. First you have to verify that your network is stable enough to handle the security protocol. The simplest option is to only enable encryption, or use the simple password flag options. Once you have established that your gw and nodes are capable of communicating securely you can move on to personalization and whitelisting.

@pepson you define whitelisting so I presume you use it. But I don't see your gw flags specifying it so of course it does not work. So get rid of that flag from your config unless you know what it mean so that you set it up properly.

@pepson please just read the documentation. And more importantly, follow it.
Isn't it obvious that it is the flag that mention whitelisting that is supposed to be removed unless you intend to use whitelisting, in which case you ought to know how to set it up properly at both ends?

The next line is intended to be used in SecurityPersonalizer.ino:
#define MY_SOFT_HMAC_KEY 0XD,0X68,0X2E,0XD0,0X51,0X6,0XE5,0XF3,0X61,0XC6,0X42,0X88,0XD6,0X8A,0XAE,0X1B,0X34,0XF5,0XFF,0XB6,0X2B,0X4E,0X39,0X77,0X3C,0X9D,0X92,0XDE,0XD0,0X4B,0X65,0X14

@anticimex
Ok read... but...
when i use MY_SIGNING_NODE_WHITELISTING i must on node in sketch add serial number my gateway and also serial number for node. But from where i can get serial number for my arduino pro mini ? I dont know...becasue i don use ATSHA204 but i use only soft signing....

@pepson your gw is configured to require signing from all nodes.
Your node 33 is set up to use signing. Your node 3 is not. Hence messages from node 3 will be rejected by the GW.
Either set up all nodes to use signing or set up weak security on the GW to only require signing from nodes that require it in turn.
This is documented behaviour. Please read the documentation. That is what it is for.

@pepson I suggest you avoid it. It require good tracking of all serials in your network and is part of the more advanced security mechanisms. And I suspect you will get issues when you add new nodes to your network as you cannot get it to work with just two nodes (you still have not enabled it on your gw). So just avoid whitelisting all together.

@pepson have you read the documentation? Do you understand the concept of personalization? Where have you found information on from where the serial number is obtained?
I will only say this once more: don't use whitelisting unless you know these things. Serial is only used for whitelisting. Don't use something you do not understand.
All your questions so far can be answered by citing the documentation so please read it!

I have my network with NRF24+'s with HW signing. Now, due to performance limitations of the NRF's I'll move to RFM69's which supports encryption.
How can I set encryption in Mysensors? Is it already available? Can I have both signing and Encryption?

Hi,
I've been a while on MySensors forum, most time as a reader. Read the docs about signing and have a couple of questions - possibly stupid as I might not understand well the docs.

I'd like to ask if the flags --my-signing-weak_security and --my-signing-request-signatures (yes I have RPi gw) are complementary or separate: if I define both, do I get a "weak security" feature or the "request security" is on top of that and only signed messages would be accepted? Or maybe I need to define one of them only depending on security level I want to achieve?

Whitelisting - many things were said here, I am not planning to use it for now nor anytime for gateway on nodes as I do not find it necessary as gw is not supposed to be compromised, but did a quick test following the @sineverba tutorial and it failed indeed as pepson said. The serial which I provided in sketch in #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {myserial}}} was the one generated by mysgq --gen-soft-serial-key (and then applied by --set-soft-serial-key ofc) - is that correct? I also tried to replace GATEWAY_ADDRESS with 0 and no success. Maybe there are some other steps that I should take (@Anticimex said something like "But I don't see your gw flags specifying it" which I dont understand in this context)

Is the encryption possible to be enabled only by compiling the gw with --my-rf24-encryption-enabled (for my nrf24) and personalizing gw and node with the same AES key obtained in this docs and by defining the proper flags in sketches on all nodes or is this procedure is more complicated? If this is not the subject for the scope of this thread please tell me I will search more.

Thank you for understanding my possibly dumb questions I try my best but I am a beginner iot, but work in IT so not a total newbe in programming or technologies.

@damian There are no stupid questions on complex matters. Security is a complex matter (unfortunately).

The weak security flag allows a node to inform a GW that it no longer require signing. Thus, an attacker might "take over" a node and replace it with a non-secure one possibly without you noticing.
The request signature flag lets a node (or GW) informe a GW (or node) that it require signatures. That allows the other side to understand that it has to sign messages sent to the destination. It is therefore not to be confused with "weak security". It is more a "enable security".

Writing #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {myserial}}} in a node, tells the node to requrie the GW to salt the signatures with it's serial (that should match the serial you entered in the node).
If the messages fail to verify, it suggests that the GW either has not realized it is expected to salt the signatures, or it uses the wrong serial to do it. Unfortunately I do not have a rPi setup to check this, so any help in troubleshooting that would be appreciated.

Yes, just make sure to also enable encryption on the node. Also, do notice that ALL nodes on the same network needs to use encryption with the same key.

I understand the idea. However, I think I might asked not clear enough. I would like to know how the mysgw daemon would work after the compilation depending on the flags I provide.
I understand that when I compile my gw with only --my-signing-request-signatures it will require all nodes in the network to sign messages. But if I want only some of them to sign messages and some not, do I have to compile the gw with both flags: --my-signing-request-signatures AND --my-signing-weak_security or only: --my-signing-weak_security ?

I think it might be an RPi issue, because the idea and setup seems to be correct. I'll try one day to test it in node-to-node communication or some test serial gw on Arduino. This is not so important to me as the signing itself works fine, just was curious.

So another question for future considerations - is it possible to read eeprom to get the keys? I suppose the answer is yes as the whitelisting feature is introduced, but is it a hard task or keys could be fetched by a simple script reading eeprom?

@damian Reading EEPROM is quite trivial for a determined attacker, hence I discourage SW based security as it does not have the means of storing secrets securely on devices as the atmega328p.
HW based signing is available using the atsha204a in which case signing keys are protected. Encryption keys are not unfortunately as all encryption is currently SW based (or HW accelerated but still SW dependent).
"Security V3" will resolve this, but I unfortunately have no ETA.

I've just applied signing to my own written sketch and hit a wall. Basically the signing works fine - I get time from controller and it works fine - any signed time packets from controller are read. However I've got issues with my receive(const MyMessage &message) function. The function gets the state change for the relay from the controller and to determine which relay should be changed it uses message.sensor method. When the signing is turned off it returns 0 or 1 (for 2 relays). However, when the signing is enabled it returns always 255. Any ideas why?

@damian the only thing I can think of is that you don't read the part of the message you think you read. Could you please provide some logs where you print the message in its entirety? The signing backend also has flags for verbose debugging (see the flags in the docs).

@anticimex I will send logs, for now do not have access to hardware (I'm out of home). I am curious what could be the reason, as I said, I set all keys and the signing itself seems to work well. When I disable:

the sketch works fine. When they are enabled, I can see that the messages are received (I can see the change of the state of relay but I cannot read which relay should be change. Here's a part of my sketch, maybe there is a trivial mistake in it:

when I dump to console controllerState[message.sensor] value I can see it changes, no matter the fact that it points on the table out of the range as I check it later when read message.sensor value. So it leads me to conclusion that message.getBool(); works OK (now I think I should Serial.println(message.getBool()) to get straight the value and make sure it really works fine... I will test it), however:

Serial.print("Message Sensor id: ");
Serial.println(message.sensor);

gives me always the value of 255 instead of 0 or 1 in this case. Of course I gave here only the most important parts of my code which I think causes problems.

@damian interesting. It would appear that verified messages has part of the header overwritten. I will take a closer look tomorrow. If you want, please test with the latest release, although there have not to my knowledge been made any changes relating to this issue.
If you want, please also add some debug printing on the sensor value of the message buffer as it is received and goes though the process of verification and propagates out of the internals in the library. I will look in the code to see if I can find an explanation for the corruption.

@damian Can you please share your sketch including your debug statements? It appears to me that your node between the print "message.getBool: 1" and "message.sensor: 255" is sending something to the GW. That initiates security handshaking so "message" will not be the same between the first and second print.

@damian Hm, I don't find your debug prints you used earlier.
But in general, I would say that the message object might be overwritten by the library, so if you need to use parts of it, make a copy of the parts you use first and then reference the copy to make sure a new incoming message does not overwrite it.
Eg, in receive():

@anticimex Yep, remodelling receive() function by adding variables and assigning values respectively message.sensor and message.getBool at the beginning got the job done. Now it works like a charm. Moreover, the whitelisting feature also works now - I had to do something wrong previously. Thank you once again for your help.

@alowhum as for the link back to mysensors documentation, that documentation is about message signing which is not to be confused with encryption. And on the top of the article is links to the latest documentation which should reflect the latest status on both signing and encryption.