[security] Introducing signing support to MySensors

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.

tomkxy

I did a few test with my ATSHA204. I could get it working on an Uno. The I took the chip and placed it on my breadboard with my ProMini. I tried to run the SHA Personaliser Sketch again just to make sure that the chip is somehow working and I received an error message that the device cannot be woken up.

Since it worked on the Uno (including running the SHA Personalizer) it must be related to the ProMini (3.3V / 8 MHz).

To what pin do I have to connect the data line?

Anticimex

@tomkxy That sounds strange. I have run on ProMini 3.3V/8MHz without issues.
Default is to use A3 for the ATSHA204A. It does not really matter which pin you connect it as long as it is usable for digital I/O (and update MY_ATSHA204_PIN accordingly or provide your pin to the MySigningAtsha204 constructor).

tomkxy

How do I change the pin definition if I use A3 on the ProMini?

Anticimex

A3 is default setting. You can find the definition of MY_ATSHA204_PIN in MyConfig.h.

tomkxy

Yep, it is

`#define MY_ATSHA204_PIN 17 // A3 - pin where ATSHA204 is attached
``
I am just irritate by the 17. So this does map to A3 even on ProMini?

Anticimex

@tomkxy yes it does.

tomkxy

@Anticimex Unfortunately, I am now in a total state of mess. It seems that nothing works anymore the moment I turn on any signing. For sure, I have a problem with ATSHA204 and the ProMini which I need to sort out separately. I tried them all with my Uno (reading out the config) which worked. When I try to just read the config with my ProMini I get the error cannot wake up device.

But now, even soft signing did not work any longer (it worked first, than I made changes and afte. I just receive nonce transmission errors from the sensor to the gateway although both radios are side by side and transmission without signing works perfectly.

Btw, what is stored in the EPROM and under what circumstances do I have to clear EPROM first. I changed between the various signing feature (soft signing, HW signing, signing required etc.) back and forth and it seems that this info is stored in EPROM and somehow not cleared?? How does the sensor know that the gateway requires signing? Will it get the info out of EPROM? Will this information be updated during presentation?

I think you did a great job on that implementation, the more frustrating it is that I cannot get it to work reliably. I am out for today. May be I find some time tomorrow getting anot ProMini prepared to checkout the issue with the chips.

Anticimex

@tomkxy The information stored in EEPROM is not specific to any backend. It just informs the node what other nodes require signed messages. At startup, a node broadcasts it's preference to the gateway which then updates it's EEPROM table and replies with its own preference back so the node knows if the gateway wants signed messages as well. If the preferences differ from what is stored in EEPROM already, it is the updated preferences that will replace the stored preferences.
The usecases for this is if you were to deploy a new sensor which require signing, it would inform gateway of this at startup. But if you restart your gateway it would loose this unless it was stored in EEPROM (the same goes the other way around) so the EEPROM is used so that the signing rules in the network gets preserved even if nodes dissappear or restart.
If you suspect the EEPROM to contain corrupt data, you can clear it with the cleareeorom sketch/example.
The typical circumstance you need to clear EEPROM under is when you switch library version, and the reserved region of EEPROM in the library change (and you also use EEPROM in your sketch). Then the library might take some of your sketch data for "it's own" and that can/will lead to unpredictable results.

scalz

Just to say, that I tried some weeks ago ATSHA204A with pro mini and had no problem too. Maybe you should try clear eeprom and retry. Or try with another pro mini. But it should work I think.
And for those who want to test excellent work of @Anticimex and @Tekka, I have posted a simple/basic not expensive, 1.8$ for 3 breakouts here : https://oshpark.com/shared_projects/lvvxsHSW . It can be useful for existing nodes too.

See you soon

[security] Introducing signing support to MySensors

17

11.7k

11.2k

113.0k