Simplifying MySensors security: the third option.
-
I've read the discussion here about encryption, and I appreciate that there is an option for some level of encryption now.
But as a usability designer I want to make the case that there needs to be a third option, between "no security" and "good but kinda complex security".
USE CASE
The basic user just wants their neighbour to not be able to trigger their catfood dispenser or listen in on their presence sensor.
That neighbour is probably not a hacker. So just making it a little bit of a hassle to listen in is already great.
USABILITY
Without looking at the technology of it, this is what I'd suggest:
- At the top of a MySensors script you can enter an optional password, and you maybe have to uncomment a line of code. That's all the user has to do.
- The code does the rest. If it notices the password is there, the script will only communicate with other sensors or gateways that have the same password.
.
Again, yes, cracking this is ridiculously easy. But that's not the point. Having your data completely out in the open is way worse. And let's be honest, that's the current default for lots of people who can't be bothered to jump through signing hoops, having to remember that whole process every time you want to add a sensor.
We need a third, simple option.
-
First of all you need signing for that. Encryption comes only second. Both can be done with the securityPersonalizer sketch. Currently @Anticimex is working on an easier to use version. I think thats more or less your solution. Read this thread.
PS Although I agree security should be as easy to use as possible (and perhaps this could be integrated into every sketch, although I am not sure if thats possible with the current structure of the library?!)!
-
Signing is not rocket science. Give it a try. There is a lot of documentation to get you started.
-
You're missing the point.
Signing is not rocket science, but it's a hassle that will always keep a sizable part of the community from any form of security. Not everybody thinks like you do.
-
@alowhum
If you use RFM69, you can enable hardware encryption with one define and store your password (AES Key) by running one sketch.This is enough security for me, as I don't open doors with mysensors.
Changing the default channel id might be a good choice too.
-
@alowhum then please enlighten me with what it is about it that you find so difficult so I get a chance of simplify it instead of bash it.
I have spent man-months in implementing it and documenting it with a ambition that it should be accessible to everyone.
From the feedback I get, I make improvements.
So please give me feedback as you obviously don't think it is good enough, also given the you are informed of the work currently going done in further improving it.
I am not going to add another security mechanism as the once we have are fully adequate and adding more will just add bloat and confusion.
-
There is one thing I can do. I can add a third signing backend. And have it get its key from a define. It won't support whitelisting and the same define will enable signature requests and encryption. As it is much less secure, it will probably be enabled using MY_INSECURE_SECURITY_PASSWORD which also define the keys to use.
That way, the current backends are not loosing integrity, you hopefully get what you want, and everybody stays happy
Unfortunately I cannot give an ETA on when it will be completed but if you agree that this is what you are seeking, I can add an issue for it do we can track it on github. It will be a feature extension so it can get in before releasing version 3 of the library.Is this acceptable?
-
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
-
I'm curious if this has been taken up. Is there anyway I can help?
-
@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]
-
@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.
-
@alowhum whenever you like. Code logic should be done. Whitelisting is also supported. Doxygen docs need more work. Thanks!
