[security] Introducing signing support to MySensors

scalz

@Anticimex: Congratulation for your son! it is not hurry, no problem. and thank you for taking time.
So maybe I am missing something, because I have no key in the sketch??? I am using ATSHA hardware chip.. The key is stored by using SHAPersonalizer, isn't it??

I have not made any changes in Myconfig.h as it is default enabled. So it is like this:

// Disable to completly disable signing functionality in library
#define MY_SIGNING_FEATURE

And the node sketch:

#include <SPI.h>
#include <MyTransportNRF24.h>
#include <MyHwATMega328.h>
#include <MySensor.h> 
#include <DHT.h>  
#include <MySigningAtsha204.h>

#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
#define HUMIDITY_SENSOR_DIGITAL_PIN 5
unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)

MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
MySigningAtsha204 signer; // Select HW ATSHA signing backend
MySensor gw(radio, hw, signer);

DHT dht;
float lastTemp;
float lastHum;
boolean metric = true; 
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);


void setup()  
{ 
  gw.begin(NULL, 10);
  dht.setup(HUMIDITY_SENSOR_DIGITAL_PIN); 

  // Send the Sketch Version Information to the Gateway
  gw.sendSketchInfo("Humidity", "1.0");

  // Register all sensors to gw (they will be created as child devices)
  gw.present(CHILD_ID_HUM, S_HUM);
  gw.present(CHILD_ID_TEMP, S_TEMP);
  
  metric = gw.getConfig().isMetric;
}

void loop()      
{  
  delay(dht.getMinimumSamplingPeriod());

  float temperature = dht.getTemperature();
  if (isnan(temperature)) {
      Serial.println("Failed reading temperature from DHT");
  } else if (temperature != lastTemp) {
    lastTemp = temperature;
    if (!metric) {
      temperature = dht.toFahrenheit(temperature);
    }
    gw.send(msgTemp.set(temperature, 1));
    Serial.print("T: ");
    Serial.println(temperature);
  }
  
  float humidity = dht.getHumidity();
  if (isnan(humidity)) {
      Serial.println("Failed reading humidity from DHT");
  } else if (humidity != lastHum) {
      lastHum = humidity;
      gw.send(msgHum.set(humidity, 1));
      Serial.print("H: ");
      Serial.println(humidity);
  }

  gw.sleep(SLEEP_TIME); //sleep a bit
}

and in Serial Gateway, I have only changed this:

// Message signing driver (signer needed if MY_SIGNING_FEATURE is turned on in MyConfig.h)
//MySigningNone signer;
//MySigningAtsha204Soft signer;
MySigningAtsha204 signer;

// Hardware profile 
MyHwATMega328 hw;

// Construct MySensors library (signer needed if MY_SIGNING_FEATURE is turned on in MyConfig.h)
// To use LEDs blinking, uncomment WITH_LEDS_BLINKING in MyConfig.h
#ifdef WITH_LEDS_BLINKING
MySensor gw(transport, hw , signer, RADIO_RX_LED_PIN, RADIO_TX_LED_PIN, RADIO_ERROR_LED_PIN);
#else
MySensor gw(transport, hw , signer);
#endif

Anticimex

@scalz Thanks :)
Correct. With HW ATSHA204A no key in the sketch is necessary.
And your setup seem ok since there are signed messages being passed successfully so the HW seem ok.

Perhaps you could add a debug print that dumps your messages in the gateway before they are checked for signatures in MySensor::process?
Just put debug(PSTR("read: %d-%d-%d s=%d,c=%d,t=%d,pt=%d,l=%d,sg=%d\n"), msg.sender, msg.last, msg.destination, msg.sensor, mGetCommand(msg), msg.type, mGetPayloadType(msg), mGetLength(msg), mGetSigned(msg)); before #ifdef MY_SIGNING_FEATURE.
You could also do the corresponding thing in your nodes MySensor::sendRoute function so we can see what data you send in order to determine why your node has decided it should not be signed.

It could be you stumbled over a library bug because I see in the code that in sendRoute the if case looks funky.
It says:
if (DO_SIGN(message.destination) && message.sender == nc.nodeId && !mGetAck(message) && mGetLength(msg) &&
but I think it should say
if (DO_SIGN(message.destination) && message.sender == nc.nodeId && !mGetAck(message) && mGetLength(message) &&
Try to change this and see what happens. I have a strong suspicion that your node's msg buffer is empty, and sendRoute therefore don't sign the message because it gets the length from the wrong buffer.

@hek if @scalz tests this successfully, could you patch it? I think it is a bug that it checks mGetLength(msg) and not mGetLength(message) in MySensor::sendRoute.

hek

@Anticimex
I could probably fix it tonight if it turns out wrong.

scalz

@Anticimex @Hek
Thank you very much for debugging!
First, I tried to add the debug watch. And like you said it seems there was no value.
Then, I looked at sendRoute like you advised, and oh!, it makes sense. A tiny small bug is living there !
So I changed mGetLength(msg) with mGetLength(message)
And now... it seems to work well! yeah! I am so happy :smiley:

If you want below is my GW logs (with the debug watch too), but I think it's ok now. there is no unwanted "nosign" anymore.

0;0;3;0;9;gateway started, id=0, parent=0, distance=0
0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 0-0-0 s=0,c=0,t=0,pt=0,l=0,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=15,pt=2,l=2,sg=0:1
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=15,pt=2,l=2,sg=0,st=ok:1
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=15,pt=2,l=2,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01F428B
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=0,t=17,pt=0,l=6,sg=1:1.5 b1
10;255;0;0;17;1.5 b1
0;0;3;0;9;read: 10-10-0 s=255,c=0,t=17,pt=0,l=6,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:013E014
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=6,pt=1,l=1,sg=1:0
10;255;3;0;6;0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=6,pt=1,l=1,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:0174D82
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=11,pt=0,l=8,sg=1:Humidity
10;255;3;0;11;Humidity
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=11,pt=0,l=8,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01827E7
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=12,pt=0,l=3,sg=1:1.0
10;255;3;0;12;1.0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=12,pt=0,l=3,sg=0
0;0;3;0;9;read: 10-10-0 s=0,c=0,t=7,pt=0,l=0,sg=0:
10;0;0;0;7;
0;0;3;0;9;read: 10-10-0 s=0,c=0,t=7,pt=0,l=0,sg=0
0;0;3;0;9;read: 10-10-0 s=1,c=0,t=6,pt=0,l=0,sg=0:
10;1;0;0;6;
0;0;3;0;9;read: 10-10-0 s=1,c=0,t=6,pt=0,l=0,sg=0
0;0;3;0;9;read: 10-10-0 s=1,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01E4D70
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=1,c=1,t=0,pt=7,l=5,sg=1:23.0
10;1;1;0;0;23.0
0;0;3;0;9;read: 10-10-0 s=1,c=1,t=0,pt=7,l=5,sg=0
0;0;3;0;9;read: 10-10-0 s=0,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:0148CE9
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=0,c=1,t=1,pt=7,l=5,sg=1:36.0
10;0;1;0;1;36.0

I have just a last question regarding signature :

in the future, when Mysensors new version will be released, does the controller will have to check the signature and to store the PSK? I think so, as the logs shows it is crypted. For doing this we should inspire ourselves
with your atsha_soft, isn't it? It is just curiosity of mine, as I am looking at your libs, and I am thinking about what changes will be involved on controller side when the moment will come for plugin update...

Now, I have to check the atsha soft version too, then ota with the recently great improvement of tekka..., and understand all new changes in the message format...lots of things.
I like this lib! 1.4 is smart, but dev branch looks very well done and much more optimized.

See you soon!

Anticimex

@scalz Great! Thanks for finding and testing this.
I am not sure I understand your question. You mean to store the PSK of atsha_soft in encrypted form in the sketch? That is difficult since the encryption secret then needs to be stored somewhere as well.
I would recommend (if you do use atsha_soft) to burn the fuses to prevent memory readout to protect the PSK.
Normally, this implementation is stored in the gateway which should be physically protected in any case, so the need to protekt PSK in the gateway is less critical than in a node which may be located "outside".

Secure OTA is currently unsupported. It might be supported in the future.

scalz

Oh, sorry for my bad english!
Is signing just between a Node and a Gateway. or is the controller involved too? Maybe it's a dumb question, I have not checked yet the changes in message.
For OTA, I understand it is not suppported by signature as you explained in your tuto. But, in the other hand, I think that for initiating an ota, it should need a signed message, so I think it is good.

Anticimex

@scalz You decide if your component will require signatures when you create your signer. That is, if you want your gateway to be able to sign messages sent to an actuator (like a lock) but you don't want your gateway to require signed messages from your nodes, you pass a argument to the constructor like this:
MySigningAtsha204 signer(false);
That will

Configure that node/gw to support signed message processing using HW ATSHA
Have that node/gw inform others that it does not require signed messages
Still permit that node/gw to sign messages sent to other nodes/gw who do requre signing

If you stick to default constructor arguments or pass true, the difference is that the node/gw will also inform others that it requires signed messages, and will ignore/discard any message that is not signed which it receive (and is targeted to that particular node/gw). It will not affect messages which are to be relayed, so the node will still work as a relay for unsigned messages.

scalz

@Anticimex:
ok, it is good to know. You have thought about everything!
If signer(true) for gateway, Will the controller (Jeedom, Domoticz..) see a crypted payload in serial transmission or will it work like before (I understand there are some changes in message structure, but what about crypted payload, does the controller need to decrypt?)

Anticimex

@scalz We only sign messages. There is no encryption involved. And the signature is stored without affecting the message contents so it is perfectly compatible with all controllers. The only thing that could affect a controller is the new sign bit in the message header but I don't think that will make any difference as it is not relevant to the controller. It is the gateway that manages this for it.

scalz

ok, it is new for me, so I am mixing vocabulary, but I understand the concept. Thank you, and now I have my answer. no big changes for controller side, great! It makes sense, but I was not sure.

hek

Fix pushed to development.

Anticimex

Thanks for that!

jsondag

I put together a garage door opening using code from korttoma. I used soft signing, and it works great. I was wanting to use a real atsha though.

I bought some atsha204a chips from amazon, and the chips are marked with only "3eas", and a "Y" in one corners. They are soic-8. Is that how this should be marked? I wired one up according to the data sheet. Gnd to Gnd, VCC to 5V, and SDA to A3. I ran the personalizer to generate a key and it said "Failed to wake device." in the serial console. Am I doing something wrong? or did I just get the wrong chip from the seller?

Anticimex

@jsondag I don't have a good explanation on the software signing not working. Maybe inadequate decoupling leads to a too noisy power rail?
About the HW issue, it is important that you use the single wire version of atsha204. NOT the i2c version. The i2c version also has an scl line while the single wire only has sda (and power and ground). That means your soic8 should have 5 unused pads. Atmel ordering code for that variant is ATSHA204A-SSHCZ-T but unfortunately it is not printed on the case. So unless you find that information from Amazon, I am afraid it is very difficult to determine the type of the chips you've got.

jsondag

@Anticimex. Software signing is working fine.

Thanks for the information though. I didn't realize the soic 8 couldn't do one wire. It's a ATSHA204-SH-DA-B according to the listing.

EDIT:
Looking at the datasheet, it says that the SCL pin can be ignored for single wire interface. perhaps I'll wire another one up and give it a go.

Just connect, SDA to A3, correct?

Anticimex

@jsondag ok. From what I could read there are two different order codes for i2c and one-wire so I don't think you can take an i2c variant board and treat it as a one-wire board by just ignoring the scl pin. But if the board really is single-wire, the pinout will be the same as the i2c version, you can just ignore the scl pin as it is NC for the one-wire variant. And from the data sheet, SHDAB is i2c not "single-wire" so I am afraid you cannot use my libs for those. I only have drivers for single-wire chips i am afraid.

TD22057

I just received my chips today from digikey (part num ATSHA204A-STUCZ-TCT-ND) which are the small 3 pin versions. Holy cow these are things are tiny. These are going to be a lot more difficult than I expected to hand solder.

Anticimex

@TD22057 If you don't have a "inverse" tweezer to fixate the chip to the board, just glue it in place. With proper iron temp (at least 300 deg C, I use 330) it's very doable. Much easier than smd resistors/caps if you ask me :) (just don't forget to solder after you glue if you do that)

TD22057

@Anticimex said:

@TD22057 If you don't have a "inverse" tweezer to fixate the chip to the board, just glue it in place. With proper iron temp (at least 300 deg C, I use 330) it's very doable. Much easier than smd resistors/caps if you ask me :) (just don't forget to solder after you glue if you do that)

Thanks - I'll try that as soon as everything arrives. Watching parts trickle in from aliexpress shippers is killing me (I think I've become spoiled on Amazon prime shipping).

tomkxy

First of all I would like to thank Anticimex for this great piece of work!

I am playing around with signing right now. I set up a temp & humid sensor with soft signing support as well as a MQTT gateway with soft signing.

In principle it seems to work. At least sensor values are published to the MQTT broker. However, in the gateway output I see nonce tr errors and sign failures.


Started!
0;0;3;0;9;read: 21-21-0 s=1,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:0107FD8
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5,sg=1:25.1
publish: MyMQTT/21/1/V_TEMP 25.1
0;0;3;0;9;read: 21-21-0 s=2,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:012B06D
0;0;3;0;9;send: 0-0-21-21 s=1,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 21-21-0 s=2,c=1,t=1,pt=7,l=5,sg=1:59.0
publish: MyMQTT/21/2/V_HUM 59.0
0;0;3;0;9;sign fail
0;0;3;0;9;send: 0-0-21-21 s=2,c=3,t=16,pt=0,l=0,sg=0,st=fail:
0;0;3;0;9;nonce tr err
0;0;3;0;9;read: 21-21-0 s=255,c=3,t=17,pt=6,l=25,sg=0:01D5F523C2778AA
0;0;3;0;9;read: 21-21-0 s=1,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:0104881
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5,sg=1:25.1
publish: MyMQTT/21/1/V_TEMP 25.1
0;0;3;0;9;read: 21-21-0 s=2,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:019A79B
0;0;3;0;9;send: 0-0-21-21 s=1,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 21-21-0 s=2,c=1,t=1,pt=7,l=5,sg=1:59.2
publish: MyMQTT/21/2/V_HUM 59.2
0;0;3;0;9;sign fail
0;0;3;0;9;send: 0-0-21-21 s=2,c=3,t=16,pt=0,l=0,sg=0,st=fail:
0;0;3;0;9;nonce tr err
0;0;3;0;9;read: 21-21-0 s=255,c=3,t=17,pt=6,l=25,sg=0:0120D83204D1A06
0;0;3;0;9;read: 21-21-0 s=1,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01AB761
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5,sg=1:25.1
publish: MyMQTT/21/1/V_TEMP 25.1
0;0;3;0;9;read: 21-21-0 s=2,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:013CD41
0;0;3;0;9;read: 21-21-0 s=2,c=1,t=1,pt=7,l=5,sg=1:59.3
publish: MyMQTT/21/2/V_HUM 59.3
0;0;3;0;9;send: 0-0-21-21 s=1,c=3,t=16,pt=0,l=0,sg=0,st=fail:
0;0;3;0;9;nonce tr err
0;0;3;0;9;send: 0-0-21-21 s=2,c=3,t=16,pt=0,l=0,sg=0,st=fail:
0;0;3;0;9;nonce tr err

I am somehow irritated concerning those failures logged after the publish logs. They seem not to be related to receiving and publishing the sensor data. What can be source of that? Why might the gateway trying to transmit?

A second question is related to personalization of the ATSHA204. Am I right that the key is displayed in the SlotConfig00 - SlotConfig0F?

The second personalization step fails with the message "Data lock failed". What could be the reason for that?

[security] Introducing signing support to MySensors

13

11.7k

11.2k

113.1k