[security] Migrating from library version 2.1 to 2.2
-
@sineverba I also believe the signal report flag is reversed nowadays, and is an opt-in feature and not an opt-out feature, using MY_SIGNAL_REPORT_ENABLED which defaults to "off". Hence it is not listed in the memory savings section of the documentation, but the documentation of MY_SIGNAL_REPORT_ENABLED does warn that it adds about 1k of flash use.
@anticimex Ah, I did not know, cause I'm in 2.2.0 rc2 (when something works... don't touch it! :D )
-
@alowhum check the development branch. Simple password system has been reworked. Also, documentation is updated.
@anticimex Awesome!
So I had a look at the new code, and is this a fair summary?:
- Simple encryption and simple signing are now two separate functions you can call at the top of your script by adding a line with a password: MY_ENCRYPTION_SIMPLE_PASSWD and MY_SIGNING_SIMPLE_PASSWD.
- You can also just put "MY_SECURITY_SIMPLE_PASSWD" at the top of your script, and that will do both in one go. This used to be called the MY_SIGNING_SIMPLE_PASSWD option, which also did both.
MY_SIGNING_SIMPLE_PASSWD is now called MY_SECURITY_SIMPLE_PASSWD. MY_SIGNING_SIMPLE_PASSWD only affects signing, and a new flag, MY_ENCRYPTION_SIMPLE_PASSWD only affects encryption. MY_SECURITY_SIMPLE_PASSWD enable both these flags.This is simply wonderful.
- More choice and flexibility for the end user.
- Get some simple security on your existing Arduino hardware.
Thank you so much for this.
-
@anticimex Awesome!
So I had a look at the new code, and is this a fair summary?:
- Simple encryption and simple signing are now two separate functions you can call at the top of your script by adding a line with a password: MY_ENCRYPTION_SIMPLE_PASSWD and MY_SIGNING_SIMPLE_PASSWD.
- You can also just put "MY_SECURITY_SIMPLE_PASSWD" at the top of your script, and that will do both in one go. This used to be called the MY_SIGNING_SIMPLE_PASSWD option, which also did both.
MY_SIGNING_SIMPLE_PASSWD is now called MY_SECURITY_SIMPLE_PASSWD. MY_SIGNING_SIMPLE_PASSWD only affects signing, and a new flag, MY_ENCRYPTION_SIMPLE_PASSWD only affects encryption. MY_SECURITY_SIMPLE_PASSWD enable both these flags.This is simply wonderful.
- More choice and flexibility for the end user.
- Get some simple security on your existing Arduino hardware.
Thank you so much for this.
-
@alowhum you are welcome. Just remember that simple in this context also mean weak. Storing the secrets in the sketch is a huge security implication on targets that does not support readout protection. Atmga328p among others.
@anticimex I understand. But if my neighbour has access to the nodes inside my house, then I have a bigger security problem :-)
-
@anticimex I understand. But if my neighbour has access to the nodes inside my house, then I have a bigger security 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 Heh, then I will invite him/her over for tea congratulate them. And then apply some verbal security :-P
Can Arduino nano's be updated OTA?
-
@anticimex Heh, then I will invite him/her over for tea congratulate them. And then apply some verbal security :-P
Can Arduino nano's be updated OTA?
-
@alowhum afaik all MySensors capable nodes can be updated OTA with the appropriate bootloader programmed.
@anticimex Wow, I didn't know that! I've gotta look into that! cool!
-
@anticimex Wow, I didn't know that! I've gotta look into that! cool!
@alowhum in general where are two options, DualOptiboot which require an external spi flash but is radio agnostic, or the mysbooloader which have no requirements on external components but might need to be recompiled to match your radio settings.
-
@alowhum in general where are two options, DualOptiboot which require an external spi flash but is radio agnostic, or the mysbooloader which have no requirements on external components but might need to be recompiled to match your radio settings.
-
@anticimex I haven't found dual optiboot for all mysensors boards, but maybe there is a way to make it work and I'm not expert on this
@gohan hence my comment "in general", and in this sence I believe the board in question is "Can Arduino nano's be updated OTA?" and a nano is atmega328p based, and I believe it supports both bootloader variants. Of course there are some devices that might not support both, or perhaps even any of them, but as most of this discussion relates to resource limited nodes, I think only atmega328p based devices are considered.
-
@anticimex Awesome!
So I had a look at the new code, and is this a fair summary?:
- Simple encryption and simple signing are now two separate functions you can call at the top of your script by adding a line with a password: MY_ENCRYPTION_SIMPLE_PASSWD and MY_SIGNING_SIMPLE_PASSWD.
- You can also just put "MY_SECURITY_SIMPLE_PASSWD" at the top of your script, and that will do both in one go. This used to be called the MY_SIGNING_SIMPLE_PASSWD option, which also did both.
MY_SIGNING_SIMPLE_PASSWD is now called MY_SECURITY_SIMPLE_PASSWD. MY_SIGNING_SIMPLE_PASSWD only affects signing, and a new flag, MY_ENCRYPTION_SIMPLE_PASSWD only affects encryption. MY_SECURITY_SIMPLE_PASSWD enable both these flags.This is simply wonderful.
- More choice and flexibility for the end user.
- Get some simple security on your existing Arduino hardware.
Thank you so much for this.
@alowhum said in [security] Migrating from library version 2.1 to 2.2:
@anticimex Awesome!
So I had a look at the new code, and is this a fair summary?:
- Simple encryption and simple signing are now two separate functions you can call at the top of your script by adding a line with a password: MY_ENCRYPTION_SIMPLE_PASSWD and MY_SIGNING_SIMPLE_PASSWD.
- You can also just put "MY_SECURITY_SIMPLE_PASSWD" at the top of your script, and that will do both in one go. This used to be called the MY_SIGNING_SIMPLE_PASSWD option, which also did both.
MY_SIGNING_SIMPLE_PASSWD is now called MY_SECURITY_SIMPLE_PASSWD. MY_SIGNING_SIMPLE_PASSWD only affects signing, and a new flag, MY_ENCRYPTION_SIMPLE_PASSWD only affects encryption. MY_SECURITY_SIMPLE_PASSWD enable both these flags.I want to follow upon this: I use RFM69 for transport, they have an encryption engine in hardware. Will there be any difference in time to process the message between using:
- MY_SECURITY_SIMPLE_PASSWORD with soft encryption done on the ATmega or
- MY_SIGNING_SIMPLE_PASSWORD and encryption on the RFM or
- just MY_SIGNING_SIMPLE_PASSWORD.
If I'm not mistaken a signed message is the full 32 byes anyway, so the actual "airtime" will not change, but maybe the processing time before that will.
And yes, I am aware of the implications in total system security. But none of my nodes are accessible from the outside of my house. I am not worried about someone reading the contents of my sketch.
-
@alowhum said in [security] Migrating from library version 2.1 to 2.2:
@anticimex Awesome!
So I had a look at the new code, and is this a fair summary?:
- Simple encryption and simple signing are now two separate functions you can call at the top of your script by adding a line with a password: MY_ENCRYPTION_SIMPLE_PASSWD and MY_SIGNING_SIMPLE_PASSWD.
- You can also just put "MY_SECURITY_SIMPLE_PASSWD" at the top of your script, and that will do both in one go. This used to be called the MY_SIGNING_SIMPLE_PASSWD option, which also did both.
MY_SIGNING_SIMPLE_PASSWD is now called MY_SECURITY_SIMPLE_PASSWD. MY_SIGNING_SIMPLE_PASSWD only affects signing, and a new flag, MY_ENCRYPTION_SIMPLE_PASSWD only affects encryption. MY_SECURITY_SIMPLE_PASSWD enable both these flags.I want to follow upon this: I use RFM69 for transport, they have an encryption engine in hardware. Will there be any difference in time to process the message between using:
- MY_SECURITY_SIMPLE_PASSWORD with soft encryption done on the ATmega or
- MY_SIGNING_SIMPLE_PASSWORD and encryption on the RFM or
- just MY_SIGNING_SIMPLE_PASSWORD.
If I'm not mistaken a signed message is the full 32 byes anyway, so the actual "airtime" will not change, but maybe the processing time before that will.
And yes, I am aware of the implications in total system security. But none of my nodes are accessible from the outside of my house. I am not worried about someone reading the contents of my sketch.
-
@davidzh If you enable any form of encryption feature, RFM69 will always use the hardware to implement it. So there is no "soft encryption" on RFM69.
Ok clear. Thank you.
-
I've a lot devices with very hard physical access to them. I'm using OTA to change firmware so please describe how to implement "new 2.2 checksum feature" into existing sketch using OTA.
@bilbolodz Not sure what you mean. Then you have to send personalization sketch OTA and that is really not recommended unless you can do that in a secure way. And the personalizer is not designed to use any radios so you cannot expect to be able to FOTA over a new sketch after personalization. You will have to "bring in" your devices if you want to redo personalization.
-
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 (?) :-)
-
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 (?) :-)
@bilbolodz Correct, checksum is on EEPROM data, so you can make a sketch to read it and calculate the checksum yourself. It is all open source so you can just see in the personalizer how it is calculated and replicate that :)
-
@bilbolodz Correct, checksum is on EEPROM data, so you can make a sketch to read it and calculate the checksum yourself. It is all open source so you can just see in the personalizer how it is calculated and replicate that :)
@anticimex OK maybe I will try but I think it could be a good idea to extend you "migration guide".