Send secured command to the gateway
-
Thank you for your answer @Anticimex
@anticimex said in Send secured command to the gateway:
Or more to the point: the GW will allow a node to set the bit in gw eeprom to indicate that it require the node to send signed messages, but it will never clear it.
The consequence of doing this is that if you at some point want to disable requirement for signatures for a node, you have to manually reset the eeprom flag in the GW.That exactly what i want to do. But it seams not implemented like this in MySensors V2.3.1
Do you have an idea how to hack MySensors V2.3.1 to do this ?@snyfir Yes, have a look at https://github.com/mysensors/MySensors/blob/master/core/MySigning.cpp#L414
Commenting out that line (and https://github.com/mysensors/MySensors/blob/master/core/MySigning.cpp#L431 if you also use whitelisting) will prevent the GW when configured with MY_SIGNING_WEAK_SECURITY to "downgrade" security settings. Thus, a node that has registered in that it require signatures, will not be able to "undo" that by remote command in the GW.
That should make your lock co-exist securely in your network even when the GW is not requiering signatures from other nodes.
But please note that you still use the weak security flag, so all other GW logic still behaves as before (signed messages will only be required by nodes that require messages themselves and so on).I have intentianlly left out the option of selecting this operation mode because the security configuration is complex enough as it is and users unfamiliar with the inner workings of the signing backend might end up locking themselves out and having problems getting things working again (resetting EEPROM in your GW will make it loose routing tables and ID assignments as well so it is not something to make a habit out of doing :-) ).
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@snyfir Yes, have a look at https://github.com/mysensors/MySensors/blob/master/core/MySigning.cpp#L414
Commenting out that line (and https://github.com/mysensors/MySensors/blob/master/core/MySigning.cpp#L431 if you also use whitelisting) will prevent the GW when configured with MY_SIGNING_WEAK_SECURITY to "downgrade" security settings. Thus, a node that has registered in that it require signatures, will not be able to "undo" that by remote command in the GW.
That should make your lock co-exist securely in your network even when the GW is not requiering signatures from other nodes.
But please note that you still use the weak security flag, so all other GW logic still behaves as before (signed messages will only be required by nodes that require messages themselves and so on).I have intentianlly left out the option of selecting this operation mode because the security configuration is complex enough as it is and users unfamiliar with the inner workings of the signing backend might end up locking themselves out and having problems getting things working again (resetting EEPROM in your GW will make it loose routing tables and ID assignments as well so it is not something to make a habit out of doing :-) ).
Thank you @anticimex i will do that :+1:
Maybe a proper way to avoid resetting EEPROM GW i can change the line https://github.com/mysensors/MySensors/blob/master/core/MySigning.cpp#L277 :
fromif (msg.destination == getNodeId()) {to
if (msg.destination == getNodeId() && msg.sender >= 100) {in that way i don't nead to use MY_SIGNING_WEAK_SECURITY to "downgrade" security and if i nead a node transmission from node to gateway to be secure i just assign it an id > 100
what do you think ?
-
Thank you @anticimex i will do that :+1:
Maybe a proper way to avoid resetting EEPROM GW i can change the line https://github.com/mysensors/MySensors/blob/master/core/MySigning.cpp#L277 :
fromif (msg.destination == getNodeId()) {to
if (msg.destination == getNodeId() && msg.sender >= 100) {in that way i don't nead to use MY_SIGNING_WEAK_SECURITY to "downgrade" security and if i nead a node transmission from node to gateway to be secure i just assign it an id > 100
what do you think ?
@snyfir It might work, but watch out so that you do ensure that nobody can spoof the device ID or somehow trick your GW to reassign the ID to a level where it will not verify the message.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@snyfir It might work, but watch out so that you do ensure that nobody can spoof the device ID or somehow trick your GW to reassign the ID to a level where it will not verify the message.
@anticimex said in Send secured command to the gateway:
@snyfir It might work, but watch out so that you do ensure that nobody can spoof the device ID or somehow trick your GW to reassign the ID to a level where it will not verify the message.
if in the controller i verify the couple message / id of the node, it will be ok no ?
it's possible to trick the GW to reassign the ID ? -
@anticimex said in Send secured command to the gateway:
@snyfir It might work, but watch out so that you do ensure that nobody can spoof the device ID or somehow trick your GW to reassign the ID to a level where it will not verify the message.
if in the controller i verify the couple message / id of the node, it will be ok no ?
it's possible to trick the GW to reassign the ID ? -
@skywatch yes, that is a perfectly viable option. As they are two separate independent networks they can have distinct configurations and requirements. This also applies to the security.
Much like WLANs. -
@anticimex Thank you!
-
@anticimex You may regret that statement when I finally get time to try it! :)
-
@anticimex said in Send secured command to the gateway:
Another hack you could make which is less "hard core" is to adjust the behavior of the weak security flag to never allow "nerfing" security settings for a node.
That is, even with the weak flag set, a gw will never allow a node to stop requiring signed messages.@Anticimex That sounds like a good idea for a new official feature to me? Especially if it's just one line that needs to be commented out?
