Send secured command to the gateway
-
@snyfir
Hi!
The gateway will require signatures from the keypad since the keypad also require it also with the weak security setting. However, with that setting, a rogue device could spoof and pretend to be your keypad, and then transmit a message to the gw that it no longer require signatures and therefore make the GW relax its requirement from that device until it again indicate it require signatures.You could add encryption to obfuscate your communication a bit which makes it harder for an attacker to spoof your keypad but that also require you to deploy encryption to the entire network.
You could also hack your gw code so that it makes that particular node irreversibly require signatures from your keypad node but there is currently no "official" way of doing that.
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.
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.
I don't remember exactly but I think this is the behaviour if you do not set the weak flag because the message to configure signing requirement is in itself not signed. Therefore the default is to accept going to a more secure state but not going back.Hope this makes things a bit more clear :)
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 ? -
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?
