[security] Migrating from library version 2.1 to 2.2
-
@bilbolodz That is fine. But as I have currently no means of verifying, I will not make a update to the guide. If you find a way to do it, you are free to post a guide if other need to make a similar thing.
-
So it means that (If I want use signing) I'm stuck with mysensors version 2.1?
I'm not able compile new code (using 2.2) and upload it over OTA because I will loose signing right (without changeing EEPROM content)?
I think there should be a way to migrate sketch (which is using soft signing) from 2.1 to 2.2 with OTA. Secure sending of keys actually is NOT a problem because (as I understood) new in 2.2 is "only checksum" of EEPROM.
So if I have "2.1 mysensors library" personalized devices, it's possible to write a program which gets existing data from EEPROM calculate checksum and write it to EEPROM (maybe also migrating other structures if there were other changes). Such sketch can be in safe way transferred via OTA because it doesn't contain any secret information. Then I can upload new (using 2.2 library) version of my sketch and I will have working "2.2" devices without touching it (only OTA). What do you think about it?Actually now I've realised (luckily) that in these "hard to get devices" I'm using hardware signing so it should be not a problem (?) :-)
-
@alowhum right, but if you update your sketches OTA, he can potentially sniff your key OTA as well and then he does not need to enter your house ;)
@anticimex I have a question - I have two GWs: one with ATSHA204A and one soft signing.
I have noticed that when doing #define PERSONALIZE_ATSHA204A, AES key is saved to ATSHA204A and EEPROM. Is this correct? In what case I need a combination of HMAC + AES keys? I do not do whitelisting -
@anticimex I have a question - I have two GWs: one with ATSHA204A and one soft signing.
I have noticed that when doing #define PERSONALIZE_ATSHA204A, AES key is saved to ATSHA204A and EEPROM. Is this correct? In what case I need a combination of HMAC + AES keys? I do not do whitelisting -
@alexsh1 AES key is never saved to atsha204. It is for encryption and always stored in eeprom.
-
@anticimex Now I got more confused. What keys do I need for atsha204a signing?
-
@anticimex Sorry, I think I need to re-read documentation. HMAC is for atsha204a signing and AES for encryption, right?
I am in the process of re-personalising now :)
-
@anticimex thank you! I set-up singing some time ago and it was working fine, but now I need to revise all that again.
@alexsh1 it is worth mentioning that if you personalize using 2.2.0, you are free to go back to earlier versions without re doing personalization. It is only when going from 2.1 to 2.2 it has to be redone due to the checksum. Of course, be aware that overwriting the checksum will cause signing to fail again.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@alexsh1 it is worth mentioning that if you personalize using 2.2.0, you are free to go back to earlier versions without re doing personalization. It is only when going from 2.1 to 2.2 it has to be redone due to the checksum. Of course, be aware that overwriting the checksum will cause signing to fail again.
@anticimex said in [security] Migrating from library version 2.1 to 2.2:
@alexsh1 Of course, be aware that overwriting the checksum will cause signing to fail again.
And what has to be done in this case? Re-personalising both GW and a node?
-
@anticimex said in [security] Migrating from library version 2.1 to 2.2:
@alexsh1 Of course, be aware that overwriting the checksum will cause signing to fail again.
And what has to be done in this case? Re-personalising both GW and a node?
@alexsh1 re-personalize the node that lost the checksum. Each node (including gw) has a unique personalization and checksum (possibly). Just because one node looses the checksum or gets a mismatch does not mean any other node has the same problem. Everything is stored in eeprom locally.
