Simplifying MySensors security: the third option.
-
Sorry if I offended, that was not my intention. I love the awesome work that has been done on MySensors!
I can't really analyse what you say, I'm not technical enough, but it sounds great. If it makes the use of the some minimal level of security just a matter of putting in a password at the top of each script, then I'm all for it!
In short this is my suggestion:
- Public sensors, totally open (default)
- Insecure but also not totally open. <- my suggestion.
- Secure (your work here is still so great!)
-
Sorry if I offended, that was not my intention. I love the awesome work that has been done on MySensors!
I can't really analyse what you say, I'm not technical enough, but it sounds great. If it makes the use of the some minimal level of security just a matter of putting in a password at the top of each script, then I'm all for it!
In short this is my suggestion:
- Public sensors, totally open (default)
- Insecure but also not totally open. <- my suggestion.
- Secure (your work here is still so great!)
@alowhum no offense taken. Sorry if I used a sharp tone. I do believe i understand what you are looking for and I believe I can accommodate the request. I will however need your (and/or everybody elses) help in testing though as I still have not gotten unpacked enough in my new apartment (and country) to test stuff myself. But as soon as I have something for you to test I'll post it here. But it will most likely not happen this mother am afraid. Simplification of the regular personalization process is my current task (discussed here).
-
I'd be happy to help. I'm not in a rush, and you don't have to do anything. Your proposal is already above and beyond what I could have expected.
@alowhum well, it will be clear to the user that it isn't enterprise grade security the particular flag will implement. Even so, it will be based on the atsha204a compatible software backend so as long as the node is protected from memory readouts (by fuses, or by simply keeping it locked in) and still making sure the random seed is based on an unconnected analog pin (like it is today) hacking also the simplified security solution though an OTA attack will be as hard as the other solutions (depending on the quality of the password). And it won't support whitelisting of nodes as that would require a unique serial for each node and that complicates things. So my rationale is that if a user wants security including whitelisting, regular personalization procedure will be required (and it will be simpler than today to deploy).
Your proposal is a valid one I have concluded after looking more into what it would mean to implement. And the implementation won't be complicated either. -
Well, that's just fantastic!
-
No, actually it's just evolution :)
-
@alowhum it has and implementation is well under way. But I am not finished with verification and documentation. There is a pull request of you want to test, but be aware that I am force pushing updates to it.
-
@Anticimex said in Simplifying MySensors security: the third option.:
pull request
Wonderful!
Very cool to see this in the code :-)
+ --my-signing=[none|software|password] -
@Anticimex said in Simplifying MySensors security: the third option.:
pull request
Wonderful!
Very cool to see this in the code :-)
+ --my-signing=[none|software|password] -
@alowhum well, verifying on rPi is the one system I cannot test myself so you are very welcome to try that :)
@Anticimex And it's the one system I have, so: perfect! PM me when you want me to do a test.
-
@Anticimex And it's the one system I have, so: perfect! PM me when you want me to do a test.
