[security] Introducing signing support to MySensors
-
@Anticimex So this is no problem if the key is not locked? I was just following the manual
On a separate note, I cannot get soft_serial written into the EEPROM:
#define LOCK_CONFIGURATION //#define LOCK_DATA //#define SKIP_KEY_STORAGE //#define USER_KEY //#define SKIP_UART_CONFIRMATION #define USE_SOFT_SIGNING #define STORE_SOFT_KEY #define USER_SOFT_KEY #define STORE_SOFT_SERIAL #define USER_SOFT_SERIAL #define STORE_AES_KEY #define USER_AES_KEY```I have defined the key under #define MY_SOFT_SERIAL [key]
Personalization sketch for MySensors usage. ------------------------------------------- This value will be stored in EEPROM as soft HMAC key: #define MY_SOFT_HMAC_KEY [deleted] Using this user supplied AES key: #define MY_AES_KEY [deleted] EEPROM configuration: SOFT_HMAC_KEY | [deleted] SOFT_SERIAL | FFFFFFFFFFFFFFFFFF AES_KEY | [deleted] -------------------------------- Personalization is now complete.@alexsh1 Hopefully the manual informs about the risks with locking data (that you cannot change the key afterwards). Atmel is somewhat vague on the security implications; they say that you can not read the key anyway but it is "more secure" to lock data. But personally, I have not found a way to read it, and I prefer to be able to change my HMAC key in my devices if it should be compromised.
Strange that you don't get the soft serial. I see nothing obviously wrong with your config. But I do see that you probably sensored your uart log a bit too hard because there are other lines missing there.
You should have seen thisUsing this user supplied soft HMAC key: #define MY_SOFT_HMAC_KEY [deleted]if you have enabled this:
#define STORE_SOFT_KEY #define USER_SOFT_KEYYou are sure you have no #undef or some accidental comment or similar. As you see in the personalizer code, it is not that complicated. If the flags are enabled, you should at least get some printouts. But since (if your UART dump is correct) you get nothing, I suspect the flags are not really "on".
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@alexsh1 Hopefully the manual informs about the risks with locking data (that you cannot change the key afterwards). Atmel is somewhat vague on the security implications; they say that you can not read the key anyway but it is "more secure" to lock data. But personally, I have not found a way to read it, and I prefer to be able to change my HMAC key in my devices if it should be compromised.
Strange that you don't get the soft serial. I see nothing obviously wrong with your config. But I do see that you probably sensored your uart log a bit too hard because there are other lines missing there.
You should have seen thisUsing this user supplied soft HMAC key: #define MY_SOFT_HMAC_KEY [deleted]if you have enabled this:
#define STORE_SOFT_KEY #define USER_SOFT_KEYYou are sure you have no #undef or some accidental comment or similar. As you see in the personalizer code, it is not that complicated. If the flags are enabled, you should at least get some printouts. But since (if your UART dump is correct) you get nothing, I suspect the flags are not really "on".
@Anticimex said:
Strange that you don't get the soft serial. I see nothing obviously wrong with your config. But I do see that you probably sensored your uart log a bit too hard because there are other lines missing there.
You should have seen thisUsing this user supplied soft HMAC key: #define MY_SOFT_HMAC_KEY [deleted]if you have enabled this:
#define STORE_SOFT_KEY #define USER_SOFT_KEYYou are sure you have no #undef or some accidental comment or similar. As you see in the personalizer code, it is not that complicated. If the flags are enabled, you should at least get some printouts. But since (if your UART dump is correct) you get nothing, I suspect the flags are not really "on".
OK, it was Arduino glitch - any changes in the sketch were not reflected on the compilation. Rebooted my PC and restarted Arduino and all works as expected.
A few questions: Mixing ATSHA204 and soft signing - Does HMAC key (one stored in ATSHA204 of say a node and another one in GW's EEPROM) have to be the same? Also I understand one can store HMAC key on both ATSHA204 and EEPROM of one device (say, Sensebender)? I understand that SOFT_KEY has to be unique for every device?
-
@Anticimex said:
Strange that you don't get the soft serial. I see nothing obviously wrong with your config. But I do see that you probably sensored your uart log a bit too hard because there are other lines missing there.
You should have seen thisUsing this user supplied soft HMAC key: #define MY_SOFT_HMAC_KEY [deleted]if you have enabled this:
#define STORE_SOFT_KEY #define USER_SOFT_KEYYou are sure you have no #undef or some accidental comment or similar. As you see in the personalizer code, it is not that complicated. If the flags are enabled, you should at least get some printouts. But since (if your UART dump is correct) you get nothing, I suspect the flags are not really "on".
OK, it was Arduino glitch - any changes in the sketch were not reflected on the compilation. Rebooted my PC and restarted Arduino and all works as expected.
A few questions: Mixing ATSHA204 and soft signing - Does HMAC key (one stored in ATSHA204 of say a node and another one in GW's EEPROM) have to be the same? Also I understand one can store HMAC key on both ATSHA204 and EEPROM of one device (say, Sensebender)? I understand that SOFT_KEY has to be unique for every device?
@alexsh1 Ok, well Arduino IDE sucks totally.
You can mix ATSHA204A and soft signing as much as you like. But for any two nodes to exchange signed data the HMAC keys have to be identical.
Yes, you can store a HMAC key in both ATSHA204A and EEPROM. These can be different if you like (and I recommend they are as the EEPROM can be dumped if the node falls into the wrong hands).
However, if you want that node to communicate signed data to another node, that node must use a matching HMAC key.
SOFT_KEY is the HMAC key stored in EEPROM, it must not be unique for every device. If it is, no device will be able to sign data to any other node and expect that node to accept that data.
SOFT_SERIAL on the other hand, must be unique to serve any useful purpose for whitelisting. If you use the ATSHA204A, the serial fused in the device will be used and that cannot be changed, and is according to Atmel, unique.Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@alexsh1 Ok, well Arduino IDE sucks totally.
You can mix ATSHA204A and soft signing as much as you like. But for any two nodes to exchange signed data the HMAC keys have to be identical.
Yes, you can store a HMAC key in both ATSHA204A and EEPROM. These can be different if you like (and I recommend they are as the EEPROM can be dumped if the node falls into the wrong hands).
However, if you want that node to communicate signed data to another node, that node must use a matching HMAC key.
SOFT_KEY is the HMAC key stored in EEPROM, it must not be unique for every device. If it is, no device will be able to sign data to any other node and expect that node to accept that data.
SOFT_SERIAL on the other hand, must be unique to serve any useful purpose for whitelisting. If you use the ATSHA204A, the serial fused in the device will be used and that cannot be changed, and is according to Atmel, unique. -
@Anticimex Ok, but is there a reason why one would have HMAC key in both ATSHA204a and EEPROM?
@alexsh1 no, not really. If you have a atsha204a the only reason to not use it would be performance. Software signing executes slightly faster due to the single write protocol of the atsha.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@alexsh1 no, not really. If you have a atsha204a the only reason to not use it would be performance. Software signing executes slightly faster due to the single write protocol of the atsha.
-
@Anticimex Thanks very much for your help - I must admit it was a bit of a challenge to jump straight away from a stable 1.5.4 to 2.0 beta
@alexsh1 yes there have been a lot of changes but hopefully they are perceived as improvements. Feedback on signing usability is always welcome :)
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@alexsh1 yes there have been a lot of changes but hopefully they are perceived as improvements. Feedback on signing usability is always welcome :)
-
@Anticimex BTW, is signing compatible between 1.5.4 and 2.0b?
-
@Anticimex Right, this is why I am not able to sign 1.5.4 nodes with 2.0b GW.
In fact when I inserted #define MY_SIGNING_REQUEST_SIGNATURES into the GW code, some nodes stopped working and I think it has to be with signing as GW is throwing a lot of messages that signing failed.Bottom line is that I need to upgrade pretty much all sensors :-(
-
@Anticimex Right, this is why I am not able to sign 1.5.4 nodes with 2.0b GW.
In fact when I inserted #define MY_SIGNING_REQUEST_SIGNATURES into the GW code, some nodes stopped working and I think it has to be with signing as GW is throwing a lot of messages that signing failed.Bottom line is that I need to upgrade pretty much all sensors :-(
-
Hi. Is there any difference in using RFM69? Signing is supported using that radio? Thanks
-
Hi. Is there any difference in using RFM69? Signing is supported using that radio? Thanks
@cingolanifede signing has nothing to to with which radio you choose so yes. It supports any transport, but to my knowledge it has only been actually tested with nrf24 and rfm69.
-
@Anticimex I must admit that signing is working really-really nicely on my custom made nodes (Soft sign and ATSHA204A)
Apart from a small issue with the sensebender, which I believe is not a signing issue, it is working like a charm. All credit to you! Thank you
Starting sensor (RNNNAS, 2.0.0-beta) Radio init successful. HTU21D Sensor1.1 - Online! isMetric: 1 TempDiff :1098.00 HumDiff :136.75 T: 998.00 H: 36.75 send: 5-5-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:998.0 send: 5-5-0-0 s=1,c=1,t=1,pt=7,l=5,sg=0,st=ok:36.7 send: 5-5-0-0 s=2,c=1,t=38,pt=7,l=5,sg=0,st=ok:3.29 send: 5-5-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:106 Signing required send: 5-5-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=ok: Waiting for GW to send signing preferences... Skipping security for command 3 type 15 read: 0-0-5 s=255,c=3,t=15,pt=0,l=2,sg=0: Mark node 0 as one that do not require signed messages Mark node 0 as one that do not require whitelisting send: 5-5-0-0 s=255,c=0,t=17,pt=0,l=10,sg=0,st=ok:2.0.0-beta send: 5-5-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0 Skipping security for command 3 type 16 read: 0-0-5 s=255,c=3,t=16,pt=0,l=0,sg=0: Signing backend: ATSHA204Soft SHA256: 2C4A871ACCAE26760F41E547DD39B7B816FE22EEBCD8DFA2FE00000000000000 Transmittng nonce send: 5-5-0-0 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:2C4A871ACCAE26760F41E547DD39B7B816FE22EEBCD8DFA2FE Signature in message: 01C31110DAE29D5DCD3771F68B6F29B5CCCF43A3D5397CC8 Message to process: 00050E0306FF4D Current nonce: 2C4A871ACCAE26760F41E547DD39B7B816FE22EEBCD8DFA2FEAAAAAAAAAAAAAA HMAC: 0CC31110DAE29D5DCD3771F68B6F29B5CCCF43A3D5397CC89A82A89D87E931B8 Signature OK read: 0-0-5 s=255,c=3,t=6,pt=0,l=1,sg=0:M send: 5-5-0-0 s=255,c=3,t=11,pt=0,l=24,sg=0,st=ok:Temp/Hum Sensor - HTU21D send: 5-5-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.1 send: 5-5-0-0 s=0,c=0,t=6,pt=0,l=0,sg=0,st=ok: send: 5-5-0-0 s=1,c=0,t=7,pt=0,l=0,sg=0,st=ok: send: 5-5-0-0 s=2,c=0,t=13,pt=0,l=0,sg=0,st=ok: Init complete, id=5, parent=0, distance=1 TempDiff :971.94 HumDiff :0.02 T: 26.06 H: 36.72 send: 5-5-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:26.1 send: 5-5-0-0 s=1,c=1,t=1,pt=7,l=5,sg=0,st=ok:36.7 -
@Anticimex I must admit that signing is working really-really nicely on my custom made nodes (Soft sign and ATSHA204A)
Apart from a small issue with the sensebender, which I believe is not a signing issue, it is working like a charm. All credit to you! Thank you
Starting sensor (RNNNAS, 2.0.0-beta) Radio init successful. HTU21D Sensor1.1 - Online! isMetric: 1 TempDiff :1098.00 HumDiff :136.75 T: 998.00 H: 36.75 send: 5-5-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:998.0 send: 5-5-0-0 s=1,c=1,t=1,pt=7,l=5,sg=0,st=ok:36.7 send: 5-5-0-0 s=2,c=1,t=38,pt=7,l=5,sg=0,st=ok:3.29 send: 5-5-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:106 Signing required send: 5-5-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=ok: Waiting for GW to send signing preferences... Skipping security for command 3 type 15 read: 0-0-5 s=255,c=3,t=15,pt=0,l=2,sg=0: Mark node 0 as one that do not require signed messages Mark node 0 as one that do not require whitelisting send: 5-5-0-0 s=255,c=0,t=17,pt=0,l=10,sg=0,st=ok:2.0.0-beta send: 5-5-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0 Skipping security for command 3 type 16 read: 0-0-5 s=255,c=3,t=16,pt=0,l=0,sg=0: Signing backend: ATSHA204Soft SHA256: 2C4A871ACCAE26760F41E547DD39B7B816FE22EEBCD8DFA2FE00000000000000 Transmittng nonce send: 5-5-0-0 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:2C4A871ACCAE26760F41E547DD39B7B816FE22EEBCD8DFA2FE Signature in message: 01C31110DAE29D5DCD3771F68B6F29B5CCCF43A3D5397CC8 Message to process: 00050E0306FF4D Current nonce: 2C4A871ACCAE26760F41E547DD39B7B816FE22EEBCD8DFA2FEAAAAAAAAAAAAAA HMAC: 0CC31110DAE29D5DCD3771F68B6F29B5CCCF43A3D5397CC89A82A89D87E931B8 Signature OK read: 0-0-5 s=255,c=3,t=6,pt=0,l=1,sg=0:M send: 5-5-0-0 s=255,c=3,t=11,pt=0,l=24,sg=0,st=ok:Temp/Hum Sensor - HTU21D send: 5-5-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.1 send: 5-5-0-0 s=0,c=0,t=6,pt=0,l=0,sg=0,st=ok: send: 5-5-0-0 s=1,c=0,t=7,pt=0,l=0,sg=0,st=ok: send: 5-5-0-0 s=2,c=0,t=13,pt=0,l=0,sg=0,st=ok: Init complete, id=5, parent=0, distance=1 TempDiff :971.94 HumDiff :0.02 T: 26.06 H: 36.72 send: 5-5-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:26.1 send: 5-5-0-0 s=1,c=1,t=1,pt=7,l=5,sg=0,st=ok:36.7@alexsh1 I'm really glad to hear that. Thank you! Glad that signing is being used and is perceived as something not to complicated to bother with. It sets us apart from many other projects dealing with the same thing :)
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@alexsh1 I'm really glad to hear that. Thank you! Glad that signing is being used and is perceived as something not to complicated to bother with. It sets us apart from many other projects dealing with the same thing :)
@Anticimex I did not say it was not complicated :)
Just kidding - speaking just for myself, it did require some time investment to understand the concept and then upgrading my gateway and my nodes (I am still in the process of rolling signing across the rest of my nodes) to MySensors 2.0b. I probably spent more time upgrading MySensors lib and breaking some hardware in the meantime (the SMA connector on the nrf24l01+ PA+LNA) than the actual signing. -
@Anticimex I did not say it was not complicated :)
Just kidding - speaking just for myself, it did require some time investment to understand the concept and then upgrading my gateway and my nodes (I am still in the process of rolling signing across the rest of my nodes) to MySensors 2.0b. I probably spent more time upgrading MySensors lib and breaking some hardware in the meantime (the SMA connector on the nrf24l01+ PA+LNA) than the actual signing.@alexsh1 yeah, well if there is room for improvement in the documentation then feel free to help put with suggestions if there is anything unclear about that :) I use doxygen to document signing features, and a link is available on the GitHub "front-page" (the readme.md)
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@Anticimex I think a noob's section would be good. Having said that, the point is that signing is not something beginners should touch. What do you think?
How about a section on the web-site? Somewhere here - https://www.mysensors.org/build/
-
@Anticimex I think a noob's section would be good. Having said that, the point is that signing is not something beginners should touch. What do you think?
How about a section on the web-site? Somewhere here - https://www.mysensors.org/build/
@alexsh1 hm, yeah, perhaps something for @hek to consider. At least a link to the signing section of the doxygen docs could be placed there. I have tried to make the documentation as step-by-step friendly as I can. That said, as I also did the actual implementation, I may well be blind for certain aspects I take for granted that a "novice" does not.
-
The next release of the main site will be much more flexible and integrated with openhardware-added projects. The idea is to allow community members to maintain their projects and/or "articles" themselves. The how-to for signing is a good example of an article.
