💬 Security & Signing

[pepson]

But still I don't know how use white listening...?

[Anticimex]

@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]

@anticimex
OK but how I can get serial from my Node on Arduino Pro Mini?

And when I want use chip AtSHA204A what I must change on my GW and on Node?
Can I build GW on Rpi with this chip AtSHA204A?

[Anticimex]

@pepson Please. Read. The. Documentation.
And no, atsha204a is not supported on rPi. Nor does it need to be.

[pepson]

@anticimex
But still I don't know how read serial number from Node on Arduino Mini Pro when I want use White Listening...

[Anticimex]

@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!

[joaoabs]

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?

[Anticimex]

@joaoabs yes, it's all in the documentation ;)
Let me know if you can't find it. Links are in the readme.md in git and in github.

[Damian]

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.

1. 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?
2. 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)
3. 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.

[Anticimex]

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

1. 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".

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

3. 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 hope this clarifies the things a bit :)

[Damian]

@anticimex thanks for the answer.

1. 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 ?
2. 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.
3. clear, hope it work. In the meantime I found: https://forum.mysensors.org/topic/2005/software-aes-encryption-for-nrf24 which looks worth testing as well. TL;DR carefully yet.

[Anticimex]

@damian

1. You need to compile with --my-signing-request-signatures AND --my-signing-weak_security. See https://www.mysensors.org/apidocs/group__SigningSettingGrpPub.html#gaf44407e0f498eca7069adf5e59ffe052
2. RF24 encryption is implemented in SW and currently available (with static IV). See https://www.mysensors.org/apidocs/group__EncryptionSettingGrpPub.html

[Damian]

@anticimex Thank you so much for clarification I owe you a beer ;)

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?

[Anticimex]

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

You are welcome! :beers:

[Damian]

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?

[Anticimex]

@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).

[Damian]

@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:

//#define MY_SIGNING_SOFT
//#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
//#define MY_SIGNING_REQUEST_SIGNATURES

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:

#define NUMBER_OF_RELAYS 2
#define R_CHILD_ID 0
#define RELAY_PIN 3

MyMessage msg[NUMBER_OF_RELAYS];
bool relayState[NUMBER_OF_RELAYS] = {false};
bool controllerState [NUMBER_OF_RELAYS] = {false};

void presentation() {

  for (int i=0, r_id=R_CHILD_ID; i<NUMBER_OF_RELAYS; i++, r_id++) {
  present(r_id, S_BINARY);
  msg[i] = MyMessage(r_id, V_STATUS);                                   
  }

}

void receive(const MyMessage &message) {
  if (message.type==V_STATUS) { 
    controllerState[message.sensor] =  message.getBool();                       
    if (controllerState[message.sensor] != relayState[message.sensor]) {                        
      relayState[message.sensor] = controllerState[message.sensor];                             
     }
    Serial.print("Message Sensor id: ");
    Serial.println(message.sensor);
    digitalWrite(RELAY_PIN+message.sensor, relayState[message.sensor] ? RELAY_ON : RELAY_OFF); 
        }
    }

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.

[Anticimex]

@damian It sure looks like message.sensor is cleared/reset for some reason. The verbose logs should show more details and hopefully reveal when in the call path, this happens.

[Damian]

@anticimex
Should I look rather in gw logs or node's? Or both?

[Anticimex]

@damian I'd start with the nodes. I suspect it is at that end something is overwritten after the message is received and verified.