Remote password assign
-
you can use a dual gateway setup: one with old password and one with new, but at this point you could very well use the signing chip and you are good to go
@gohan I am not sure how nice two gateways on the same network will play with each other. If they are on separate networks, the same problem arise, one sketch version will use with one gw, another with the second. Thus not providing any benefit from the first option, to just transmit the new firmware OTA encrypted with the old key.
However, considering that the most probable reason for changing the key is that the old one was compromised, this is a valid option either.
All in all, transmitting keys OTA is never under any circumstances a good idea with the current security scheme. -
Of course sending keys OTA is not advised, but still if you have someone sniffing your wireless mysensors data it must be really motivated to get into your house :D
Actually I said 2 gateways but they would need to be on separate networks: one taking care of the FOTA on old nodes and the other configured to get the nodes reprogrammed.
-
Of course sending keys OTA is not advised, but still if you have someone sniffing your wireless mysensors data it must be really motivated to get into your house :D
Actually I said 2 gateways but they would need to be on separate networks: one taking care of the FOTA on old nodes and the other configured to get the nodes reprogrammed.
-
@gohan maybe, at the cost of the hassle of having to mess a lot with the controller to handle two gateways which most likely will cause the nodes to get new id:s and loose any existing configurations.
But this is an academic discussion, pulling the stunt of changing security keys OTA is not advised, and there will be no official support for a dedicated command to do this in 2.x.x versions due to the security implications.
I have loosened security by supporting the "password" option too much for my comfort already :) -
Sorry for delay. I mean send password not in FOTA but as separate command. In that case gateway should communicate with signed and not signed password nodes. From insecure node only limited commands would be accepted by the gateway, so no hacks would be available like door opening and etc.
The controller would initiate process of changing or assigning password.
So if password gets leaked or node stolen, you would need only initiate password change command in controller without re flashing all nodes with new password.
I know it maybe a security issue, but it would be a lot easier to use same node firmware version for multiple signed passwords. -
Sorry for delay. I mean send password not in FOTA but as separate command. In that case gateway should communicate with signed and not signed password nodes. From insecure node only limited commands would be accepted by the gateway, so no hacks would be available like door opening and etc.
The controller would initiate process of changing or assigning password.
So if password gets leaked or node stolen, you would need only initiate password change command in controller without re flashing all nodes with new password.
I know it maybe a security issue, but it would be a lot easier to use same node firmware version for multiple signed passwords.@kestutis-mockus I don't understand. If you send the password using rf to a node, that password can be sniffed and used by nodes other than your own which would be able to make themself indistinguishable from your own nodes to your gateway/controller.
-
Sorry for delay. I mean send password not in FOTA but as separate command. In that case gateway should communicate with signed and not signed password nodes. From insecure node only limited commands would be accepted by the gateway, so no hacks would be available like door opening and etc.
The controller would initiate process of changing or assigning password.
So if password gets leaked or node stolen, you would need only initiate password change command in controller without re flashing all nodes with new password.
I know it maybe a security issue, but it would be a lot easier to use same node firmware version for multiple signed passwords.@kestutis-mockus I should also clarify that by OTA I mean "Over the Air", as opposed to FOTA witch is "Firmware Over the Air".
Any OTA message can be sniffed by others. To prevent that, encryption can be used, but in this case the usecase is to change encryption password which is a bad idea since some nodes might get the message and change their key. Others might miss it and then won't be able to decrypt future communications as the gateway would have to start using the new password to communicate with the nodes that changed theirs.
All in all, the solution will just be complicated and prone to errors, something the password option was designed to be anything but. -
Well to check if password is changed, verify message could be sent with new encryption, if no replay - send new password change command again. For password sending in OTA - new password could encrypted with predefined encryption key which would be safely saved in atcha and defined uniquely by each developer.
It is just my thoughts, as I understand it cannot be accomplished easily without modifining core files and private modificated files would be overwriten by updates.
Will waot for future updates if something similiar will be developed.
Thanks and sorry for english :) -
Well to check if password is changed, verify message could be sent with new encryption, if no replay - send new password change command again. For password sending in OTA - new password could encrypted with predefined encryption key which would be safely saved in atcha and defined uniquely by each developer.
It is just my thoughts, as I understand it cannot be accomplished easily without modifining core files and private modificated files would be overwriten by updates.
Will waot for future updates if something similiar will be developed.
Thanks and sorry for english :)@kestutis-mockus I still think it is too complicated for what the basic feature actually provide (which is weak security) and it relies on a atsha which on its own implement stronger security based on personalization, something the entire password feature was designed to circumvent. But if you feel the feature is strongly desired, feel free to file a pr (and maintain) the feature and if it is well designed it can be incorporated in the core.
But personally I don't feel it gives enough benefit for being worth the effort of implementation and maintenance.
I'd rather focus on development of the next generation security which is designed to replace the current encryption/signing solution in its entirety (the current solution will remain an option for those who prefer it though). But this will be first in mysensors v3.
