[security] Introducing signing support to MySensors

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

[Anticimex]

@tomkxy Thanks.
"nonce tr err" is sent if sendRoute() fails to send a nonce request. So it suggests the radio link is somewhat unreliable and that in turn causes signing to fail. From what I can see you want to sign messages in both directions, so maybe traimsission from the MQTT gateway is not as reliable as reception? message type 16 (command 3) is a nonce request and sometimes it succeeds

0;0;3;0;9;send: 0-0-21-21 s=1,c=3,t=16,pt=0,l=0,sg=0,st=ok:

and sometimes it fail (with that message as consequence):

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

But the failing one is to a different sensor (2) than the first one (1), so perhaps that node is down or at a long range? But last in your log you also fail a transmission to sensor 1. In any case, the nonce tr err is because of failing radio transmissions and as such not a signing issue as such. Sometimes it works (when there are no radio issues:

0;0;3;0;9;read: 21-21-0 s=1,c=3,t=16,pt=0,l=0,sg=0: (request for nonce to GW)
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 (GW sends nonce back)
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5,sg=1:25.1 (signed message with that nonce is received)
publish: MyMQTT/21/1/V_TEMP 25.1 (message/signature is accepted and forwarded)

"sign fail" is typically reported if nonce exchange times out. You can adjust the timeout using MY_VERIFICATION_TIMEOUT_MS if you have many hops or for other reasons cannot process messages fast enough.
I have not tested MQTT gateway myself, and perhaps it uses the MySensors library differently but I have tested both serial and ethernet gateway. But in this case, it probably fails because you never got the request for the nonce out so your sender never got a chance to send a nonce back, and therefore signing cannot succeed.
So the key is to determine why the transmission of the nonce request fail (a radio problem since you get st=fail). Or implement a retransmission at a higher level in your sketch if the radio link is "lossy". The signing backend assumes a working channel and do not handle retransmission for you on failures.

Regarding personalization, key is never displayed. It is stored in slot 0. Slotconfigs are used to set the permissions of the slots. They don't store keys themselves.
You should get the reason for the data lock failure in the code that is sent together with the message. It is the ATSHA circuit itself that provide this value (or the library communicating with it in case of communication problem).

[tomkxy]

Thanks for your fast reply. Regarding the communication failures: I was testing this with both transmitters lying side by side. Do you have any idea why the gateway might want to have a nonce. Is it part of the sensor protocol?
The two sensors displayed in the log are basically the same sensor (DHT22 providing temp and humidity).

With respect to the key topic: The first personalization step provides the following output:

Device revision: 00020009
Device serial:   {0x01,0x23,0x48,0xC9,0x51,0x6A,0x1A,0x06,0xEE}
012348C9516A1A06EE
Chip configuration:
           SN[0:1]           |         SN[2:3]           | 01   23 | 48   C9   
                          Revnum                         | 00   09   04   00   
                          SN[4:7]                        | 51   6A   1A   06   
    SN[8]    |  Reserved13   | I2CEnable | Reserved15    | EE | 13 | 00 | 00   
  I2CAddress |  TempOffset   |  OTPmode  | SelectorMode  | C8 | 00 | 55 | 00   
         SlotConfig00        |       SlotConfig01        | 8F   80 | 80   A1   
         SlotConfig02        |       SlotConfig03        | 82   E0 | A3   60   
         SlotConfig04        |       SlotConfig05        | 94   40 | A0   85   
         SlotConfig06        |       SlotConfig07        | 86   40 | 87   07   
         SlotConfig08        |       SlotConfig09        | 0F   00 | 89   F2   
         SlotConfig0A        |       SlotConfig0B        | 8A   7A | 0B   8B   
         SlotConfig0C        |       SlotConfig0D        | 0C   4C | DD   4D   
         SlotConfig0E        |       SlotConfig0F        | C2   42 | AF   8F   
  UseFlag00  | UpdateCount00 | UseFlag01 | UpdateCount01 | FF | 00 | FF | 00   
  UseFlag02  | UpdateCount02 | UseFlag03 | UpdateCount03 | FF | 00 | FF | 00   
  UseFlag04  | UpdateCount04 | UseFlag05 | UpdateCount05 | FF | 00 | FF | 00   
  UseFlag06  | UpdateCount06 | UseFlag07 | UpdateCount07 | FF | 00 | FF | 00   
                      LastKeyUse[0:3]                    | FF   FF   FF   FF   
                      LastKeyUse[4:7]                    | FF   FF   FF   FF   
                      LastKeyUse[8:B]                    | FF   FF   FF   FF   
                      LastKeyUse[C:F]                    | FF   FF   FF   FF   
  UserExtra  |    Selector   | LockValue |  LockConfig   | 00 | 00 | 55 | 55  

Can I provide any key in the second personalization step or does it have to be same than in the first step being generated?

[Anticimex]

@tomkxy The protocol is described in the first post. Any node that is sending a signed message to another node (that has requested to get signed messages) will ask for a nonce. So you have configured your gateway to require signed messages as well as your node.
Regarding the personalization, I do t understand your question. The output is the chip configuration. It does not list any keys. I am not sure I understand what you mean by second step. You can generate a random key and that key you store and after you store it you have an option to also lock it, but then you have no way of ever changing it. I have documented the personalization flow also in the sketch itself.

[Anticimex]

I should emphasise that if you personalize multiple atsha:s you have to have the same key stored in all of them. But the sketch offer to generate a random key (but you can skip that and use any key or password you like). But the key must be the same for all members of a secure network that want to talk to each other.

[tomkxy]

@Anticimex: The output shown is related to the sketch configuration you described in your description:

Set the following sketch configuration of the personalizer:
Enable LOCK_CONFIGURATION
Disable LOCK_DATA
Enable SKIP_KEY_STORAGE
Disable SKIP_UART_CONFIGURATION
Disable USER_KEY_DATA

Execute the sketch on the “master” device to obtain a randomized key. Save this key to >a secure location and keep it confidential so that you can retrieve it if you need to
personalize more devices later on.

I was wondering that I did not see any explicit reference to a key. So may be I just have to retry.

I should emphasise that if you personalize multiple atsha:s you have to have the same >key stored in all of them. But the sketch offer to generate a random key (but you can >skip that and use any key or password you like). But the key must be the same for all >members of a secure network that want to talk to each other.
Thanks for that clarification. I was aware of that.

[Anticimex]

@tomkxy are you sure you have enabled all those options? According to the dump, your configuration is still not locked and therefore no randomized key can be generated. Are there no more output from the sketch than that? You mentioned failure to lock data zone but I cannot see that message. And you cannot lock datazone without locking configuration.
After the sketch locks configuration it will print a randomized key in the log.

[tomkxy]

@Anticimex: Thanks for your patience and your support.
I rerun it with the output and sketch configuration listed below. May be the reason that it is not working that my poor soldering skills bricked the device.

Extract from sketch (1st run):

#include <sha204_library.h>
#include <sha204_lib_return_codes.h>

// The pin the ATSHA204 is connected on
#define ATSHA204_PIN 17 // A3

// Uncomment this to enable locking the configuration zone.
// *** BE AWARE THAT THIS PREVENTS ANY FUTURE CONFIGURATION CHANGE TO THE CHIP ***
// It is still possible to change the key, and this also enable random key generation
#define LOCK_CONFIGURATION

// Uncomment this to enable locking the data zone.
// *** BE AWARE THAT THIS PREVENTS THE KEY TO BE CHANGED ***
// It is not required to lock data, key cannot be retrieved anyway, but by locking
// data, it can be guaranteed that nobody even with physical access to the chip,
// will be able to change the key.
//#define LOCK_DATA

// Uncomment this to skip key storage (typically once key has been written once)
#define SKIP_KEY_STORAGE

// Uncomment this to skip key data storage (once configuration is locked, key
// will aways randomize)
// Uncomment this to skip key generation and use 'user_key_data' as key instead.
//#define USER_KEY_DATA

// Uncomment this for boards that lack UART
// IMPORTANT: No confirmation will be required for locking any zones with this
// configuration!
// Also, key generation is not permitted in this mode as there is no way of
// presenting the generated key.
//#define SKIP_UART_CONFIRMATION

#if defined(SKIP_UART_CONFIRMATION) && !defined(USER_KEY_DATA)
#error You have to define USER_KEY_DATA for boards that does not have UART
#endif
…

Output:

ATSHA204 personalization sketch for MySensors usage.
----------------------------------------------------
Device revision: 00020009
Device serial:   {0x01,0x23,0x48,0xC9,0x51,0x6A,0x1A,0x06,0xEE}
012348C9516A1A06EE
Skipping configuration write and lock (configuration already locked).
Chip configuration:
           SN[0:1]           |         SN[2:3]           | 01   23 | 48   C9   
                          Revnum                         | 00   09   04   00   
                          SN[4:7]                        | 51   6A   1A   06   
    SN[8]    |  Reserved13   | I2CEnable | Reserved15    | EE | 13 | 00 | 00   
  I2CAddress |  TempOffset   |  OTPmode  | SelectorMode  | C8 | 00 | 55 | 00   
         SlotConfig00        |       SlotConfig01        | 8F   80 | 80   A1   
         SlotConfig02        |       SlotConfig03        | 82   E0 | A3   60   
         SlotConfig04        |       SlotConfig05        | 94   40 | A0   85   
         SlotConfig06        |       SlotConfig07        | 86   40 | 87   07   
         SlotConfig08        |       SlotConfig09        | 0F   00 | 89   F2   
         SlotConfig0A        |       SlotConfig0B        | 8A   7A | 0B   8B   
         SlotConfig0C        |       SlotConfig0D        | 0C   4C | DD   4D   
         SlotConfig0E        |       SlotConfig0F        | C2   42 | AF   8F   
  UseFlag00  | UpdateCount00 | UseFlag01 | UpdateCount01 | FF | 00 | FF | 00   
  UseFlag02  | UpdateCount02 | UseFlag03 | UpdateCount03 | FF | 00 | FF | 00   
  UseFlag04  | UpdateCount04 | UseFlag05 | UpdateCount05 | FF | 00 | FF | 00   
  UseFlag06  | UpdateCount06 | UseFlag07 | UpdateCount07 | FF | 00 | FF | 00   
                      LastKeyUse[0:3]                    | FF   FF   FF   FF   
                      LastKeyUse[4:7]                    | FF   FF   FF   FF   
                      LastKeyUse[8:B]                    | FF   FF   FF   FF   
                      LastKeyUse[C:F]                    | FF   FF   FF   FF   
  UserExtra  |    Selector   | LockValue |  LockConfig   | 00 | 00 | 55 | 00   
Disable SKIP_KEY_STORAGE to store key.
Data not locked. Define LOCK_DATA to lock for real.
--------------------------------
Personalization is now complete.
Configuration is LOCKED
Data is UNLOCKED

Second run with the following sketch settings (key used removed):

#include <sha204_library.h>
#include <sha204_lib_return_codes.h>

// The pin the ATSHA204 is connected on
#define ATSHA204_PIN 17 // A3

// Uncomment this to enable locking the configuration zone.
// *** BE AWARE THAT THIS PREVENTS ANY FUTURE CONFIGURATION CHANGE TO THE CHIP ***
// It is still possible to change the key, and this also enable random key generation
#define LOCK_CONFIGURATION

// Uncomment this to enable locking the data zone.
// *** BE AWARE THAT THIS PREVENTS THE KEY TO BE CHANGED ***
// It is not required to lock data, key cannot be retrieved anyway, but by locking
// data, it can be guaranteed that nobody even with physical access to the chip,
// will be able to change the key.
#define LOCK_DATA

// Uncomment this to skip key storage (typically once key has been written once)
//#define SKIP_KEY_STORAGE

// Uncomment this to skip key data storage (once configuration is locked, key
// will aways randomize)
// Uncomment this to skip key generation and use 'user_key_data' as key instead.
#define USER_KEY_DATA

// Uncomment this for boards that lack UART
// IMPORTANT: No confirmation will be required for locking any zones with this
// configuration!
// Also, key generation is not permitted in this mode as there is no way of
// presenting the generated key.
#define SKIP_UART_CONFIRMATION

#if defined(SKIP_UART_CONFIRMATION) && !defined(USER_KEY_DATA)
#error You have to define USER_KEY_DATA for boards that does not have UART
#endif

#ifdef USER_KEY_DATA
#define MY_HMAC_KEY 0x…

const uint8_t user_key_data[32] = {MY_HMAC_KEY};
#endif
const int sha204Pin = ATSHA204_PIN;
atsha204Class sha204(sha204Pin);

Device revision: 00020009
Device serial:   {0x01,0x23,0x48,0xC9,0x51,0x6A,0x1A,0x06,0xEE}
012348C9516A1A06EE
Skipping configuration write and lock (configuration already locked).
Chip configuration:
           SN[0:1]           |         SN[2:3]           | 01   23 | 48   C9   
                          Revnum                         | 00   09   04   00   
                          SN[4:7]                        | 51   6A   1A   06   
    SN[8]    |  Reserved13   | I2CEnable | Reserved15    | EE | 13 | 00 | 00   
  I2CAddress |  TempOffset   |  OTPmode  | SelectorMode  | C8 | 00 | 55 | 00   
         SlotConfig00        |       SlotConfig01        | 8F   80 | 80   A1   
         SlotConfig02        |       SlotConfig03        | 82   E0 | A3   60   
         SlotConfig04        |       SlotConfig05        | 94   40 | A0   85   
         SlotConfig06        |       SlotConfig07        | 86   40 | 87   07   
         SlotConfig08        |       SlotConfig09        | 0F   00 | 89   F2   
         SlotConfig0A        |       SlotConfig0B        | 8A   7A | 0B   8B   
         SlotConfig0C        |       SlotConfig0D        | 0C   4C | DD   4D   
         SlotConfig0E        |       SlotConfig0F        | C2   42 | AF   8F   
  UseFlag00  | UpdateCount00 | UseFlag01 | UpdateCount01 | FF | 00 | FF | 00   
  UseFlag02  | UpdateCount02 | UseFlag03 | UpdateCount03 | FF | 00 | FF | 00   
  UseFlag04  | UpdateCount04 | UseFlag05 | UpdateCount05 | FF | 00 | FF | 00   
  UseFlag06  | UpdateCount06 | UseFlag07 | UpdateCount07 | FF | 00 | FF | 00   
                      LastKeyUse[0:3]                    | FF   FF   FF   FF   
                      LastKeyUse[4:7]                    | FF   FF   FF   FF   
                      LastKeyUse[8:B]                    | FF   FF   FF   FF   
                      LastKeyUse[C:F]                    | FF   FF   FF   FF   
  UserExtra  |    Selector   | LockValue |  LockConfig   | 00 | 00 | 55 | 00   
Using this user supplied key:
#define MY_HMAC_KEY 0x…..
Writing key to slot 0...
Data lock failed. Response: D3
Halting!

[Anticimex]

@tomkxy I'm on phone so I cannot check the response code right now but you could look it up in the atsha datasheet or in the software. I have not tried to lock data myself and I do not recommend it because it makes it impossible to change the key later on if it is comprised. From what I can see, everything looks good except the locking of the datazone (your key)

[Anticimex]

@tomkxy I should add that from the logs I see that you do have successfully stored your key, so unless you really want to lock down the key, personalization is done and successful.

[tomkxy]

@Anticimex: Thanks a lot. I didn't intend to lock the data zone.

Btw, I did some tests regarding the nonce failure the gateway showed. I think the reason is rather simple. The gateway tried - for reasons I still don't understand - send data to the sensor for which it tried to get a nonce. The sensor however was powered down which is probably the reason why no nonce was sent. At least this error didn't show up when I removed the power down and replaced it by a simple call to delay.

[Anticimex]

@tomkxy Ah, I see. Well then that matter should be sorted.
Regarding your radio issue, yes, if the GW wants to send data to your node, it needs to be up&running. From the log you sent, I cannot determine what data the GW tried to send though, since it (because your node has told the GW it require it) wants to sign the message to send, and fails, the actual message is never showed in the log.
Perhaps you could send a log with your node continuously powered and we could see at least the type of message your GW tries to send. That could help to identify why it tries to send the message in the first place.

[tomkxy]

@Anticimex: I started a new thread http://forum.mysensors.org/topic/1782/gateway-is-sending-command-1-type-1-c-1-t-1-message-to-sensor
because it looks like it is not really related to signing.
In the post I included the log output of the message for which the nonce is being requested. It looks like the gateway node is sending back the humidity with a c=1 command. Somehow this does not make sense to me.

[Anticimex]

@tomkxy I see. Perhaps you request ACK or something like that. But ACKs are not signed. I have seen to that, so probably not. I am not too well into the non-signing aspects of the network though, so hopefully someone else perhaps can give a hint on what's wrong. Could be the sketch itself. I am glad we sorted the signing issues anyway :)

[tomkxy]

@Anticimex: I found the issue with respect to the gateway sending a message back to the sensor. This is due to the gateway subscribing to all topics on the MQTT broker. Once it receives a message it sends it to the sensor as SET message. I have to resolve that one.

I think, I still have an issue with signing which I need to get sorted myself first. I will let you know.

[Anticimex]

@tomkxy Alright. Good to know that you found the root cause for the message issue.
Regarding signing, from what I could see at least some signed messages did come through, so you should at least have the proper shared states (keys) and configs.