[security] Introducing signing support to MySensors
-
@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 UNLOCKEDSecond 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: 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: 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.
@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. -
@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: 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.@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 :)
-
@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: 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.
@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. -
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?
-
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?
@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). -
A3 is default setting. You can find the definition of MY_ATSHA204_PIN in MyConfig.h.
-
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 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 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.
@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. -
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
-
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
@scalz said:
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.Good idea - I'm finding soldering the ATSHA chips to be a real pain and a small breakout board would help with that. Is the eeprom pads on your board for people who are just using a mega328 chip? Doesn't a pro-mini already have enough eeprom on board?
-
@TDD22057: eeprom on the breakout is for the new ota in Mysensors (over the air upload sketch) . It is not related to authentication.
I made this cheap breakout firstly because I wanted to test the new Mysensors features easily. and I thought it could be useful in some specific case where you don't need to make a pcb for one specific usercase so you use a veroboard and so you can easily add these new features with less pain...
Happy it can help some people :smile: -
Regarding my issue with the ATSHA204A, I did some testing with the following results. I soldered the ATSHA204A on a small breakout board and loaded the SHAPersonalizer sketch.
I tested three configurations:
- Breakout wired to the ProMini without breadboard use
- Breakout wired to a breadboard where the ProMini was plugged
- Breakout and ProMini both plugged to breadboard and connected by wires.
Config 3 does not work!!!
That means the breadboard significantly changes the electrical characteristics. Is anybody on the forum who is able to explain that? -
@tomkxy: it is strange. My first tests have been done in you config 3 (atsha breakout and promini both plugged to breadboard). And it worked well for me. Could it be your wire quality??? I had problems with some Dupont wire once...
