[security] Introducing signing support to MySensors
-
@Anticimex The documentation is great regarding how to enable the signing and make the nodes work. My questions were related more to technical stuff.
Actually I still have a problem that I shall only use the hardware in private places. I know we have whitelist but I don't like the idea of having to re program node to add or revoke other stolen nodes.
If I need to put a motion sensor outside then I will have to make sure that all other nodes inside my house accept messages from only my gateway for example. Because if this node is stolen I don't want someone to send same commands to my private nodes.
What do you suggest to solve this ?
Do I have to set all private nodes to accept signed data from gateway only ?@ahmedadelhosni in your specific case, I would suggest, in order for you to not risk exposing your gateway serial to a thief, that you don't use whitelisting at the node at risk (the one outside). Then it won't reveal anything about your security if stolen, assuming you use an atsha204a.
Your gateway on the other hand, has a whitelist of every node in your system (if you so choose), so you can, as soon as you notice your node being stolen, remove its entry on the gateway, and it would be rejected. The attacker would then have to try to guess its way into figuring out a serial that match any other node the gateway accept in order to be able to "get in".
That way, your hmac, at least in theory, will still be secure and usable (and you shouldn't need to redo personalization on your network).Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ahmedadelhosni in your specific case, I would suggest, in order for you to not risk exposing your gateway serial to a thief, that you don't use whitelisting at the node at risk (the one outside). Then it won't reveal anything about your security if stolen, assuming you use an atsha204a.
Your gateway on the other hand, has a whitelist of every node in your system (if you so choose), so you can, as soon as you notice your node being stolen, remove its entry on the gateway, and it would be rejected. The attacker would then have to try to guess its way into figuring out a serial that match any other node the gateway accept in order to be able to "get in".
That way, your hmac, at least in theory, will still be secure and usable (and you shouldn't need to redo personalization on your network).@Anticimex This seems a good solution.
I have to points to discuss here please.
First : I know that we have an API to specify that node 4 shall send this message to node 7 for example. In our library, does this communication happens without passing by the gateway ?
If for example in order to reach node 7, a repeater node 6 shall be used in between. Thus node 4, send to the gateway then to node 6 then to node 7 ?In our case when we revoke our stolen node from the Gateway which is now node 4. will the message pass first to the gateway or if the attacker knows node's 7 serial, then node 4 sends it directly to 7 ?
Actually I guess it may pass by the gateway but I am not famailar how is the look up table implemented.
-
@Anticimex This seems a good solution.
I have to points to discuss here please.
First : I know that we have an API to specify that node 4 shall send this message to node 7 for example. In our library, does this communication happens without passing by the gateway ?
If for example in order to reach node 7, a repeater node 6 shall be used in between. Thus node 4, send to the gateway then to node 6 then to node 7 ?In our case when we revoke our stolen node from the Gateway which is now node 4. will the message pass first to the gateway or if the attacker knows node's 7 serial, then node 4 sends it directly to 7 ?
Actually I guess it may pass by the gateway but I am not famailar how is the look up table implemented.
@ahmedadelhosni no, if you directly target another node, I do not believe it will pass through the gateway.
I would say that if something like that is desired, you target your controller and have the controller relay the message to the other node. Everything to/from the controller pass through the gateway. That becomes controller specific behavior though. -
@ahmedadelhosni in your specific case, I would suggest, in order for you to not risk exposing your gateway serial to a thief, that you don't use whitelisting at the node at risk (the one outside). Then it won't reveal anything about your security if stolen, assuming you use an atsha204a.
Your gateway on the other hand, has a whitelist of every node in your system (if you so choose), so you can, as soon as you notice your node being stolen, remove its entry on the gateway, and it would be rejected. The attacker would then have to try to guess its way into figuring out a serial that match any other node the gateway accept in order to be able to "get in".
That way, your hmac, at least in theory, will still be secure and usable (and you shouldn't need to redo personalization on your network).@Anticimex Second : Don't you think that the whitelisting need to be more robust ?
I mean that I don't like the idea of reflashing. Why don't you implement an API that can be used to securely add or revoke serials during run time ?
Also another idea which I would like to discuss. Maybe when a node is started, it sends it's serial number securely to the gateway and it is added to the whitelist for example.
The whole idea is that I don't really know how do other commerial products handle security for private and public nodes. All I know is usually you scan a QR code which is on the box. Do you have any idea ?
-
@ahmedadelhosni no, if you directly target another node, I do not believe it will pass through the gateway.
I would say that if something like that is desired, you target your controller and have the controller relay the message to the other node. Everything to/from the controller pass through the gateway. That becomes controller specific behavior though.@Anticimex Actually something now came to my mind. Can't the attacker flash a gateway sketch easier and control all nodes now ? :D He has a trusted ATSHA with HMAC.
Am I missing something ? -
@Anticimex Second : Don't you think that the whitelisting need to be more robust ?
I mean that I don't like the idea of reflashing. Why don't you implement an API that can be used to securely add or revoke serials during run time ?
Also another idea which I would like to discuss. Maybe when a node is started, it sends it's serial number securely to the gateway and it is added to the whitelist for example.
The whole idea is that I don't really know how do other commerial products handle security for private and public nodes. All I know is usually you scan a QR code which is on the box. Do you have any idea ?
@ahmedadelhosni signing has no (and will not have) a dependency to encryption so serial will never be sent OTA.
For MySensors v3 a complete new security scheme will obsolete the current one, so I won't make significant changes to the existing framework. Of course pull requests are always welcome for review. -
@Anticimex Actually something now came to my mind. Can't the attacker flash a gateway sketch easier and control all nodes now ? :D He has a trusted ATSHA with HMAC.
Am I missing something ?@ahmedadelhosni nodes still need to be included and your existing gateway needs to be blocked out since they will have conflicting addresses.
But as I already said, if you get your devices stolen, the recommendation is to distrust your network and replace the keys.
These are the limitations when implementing security for systems as limited in resources as the atmga328p. -
@Anticimex Actually something now came to my mind. Can't the attacker flash a gateway sketch easier and control all nodes now ? :D He has a trusted ATSHA with HMAC.
Am I missing something ?@ahmedadelhosni also, if your public node is stolen and your gateway had a whitelist (and your other nodes has whitelists) the attacker would not know the serials of your other nodes, and therefore not be able to sign messages to them (assuming your other nodes require signed and whitelist enabled messages).
-
@ahmedadelhosni signing has no (and will not have) a dependency to encryption so serial will never be sent OTA.
For MySensors v3 a complete new security scheme will obsolete the current one, so I won't make significant changes to the existing framework. Of course pull requests are always welcome for review.@Anticimex aha so you mean that since our message frame contains the payload (not encrypted ) + signature so it is not applicable to send it OTA ?
So do you have any documentation for tracking 3.0 progress ?
-
@Anticimex aha so you mean that since our message frame contains the payload (not encrypted ) + signature so it is not applicable to send it OTA ?
So do you have any documentation for tracking 3.0 progress ?
@ahmedadelhosni no, I mean that I don't want features relating to signing to depend on encryption. Things like serials and hmac keys must never be sent OTA even with encryption enabled since the current encryption available (at least in SW) is very weak due to protocol limitations.
Progress on v3 is currently not moving because the core team is busy with other things.
We want to make a security solution that is robust, easy to use and properly secure so we do not want to rush anything. We are well under way with deciding the core principles but I will not publish the working documents because we quite frankly do not have time to handle questions from the public. Especially when we have not finalized the design.Rest assured fully qualified people are investigating and discussing the matter. In due course the results will become public as we are working with an open source project so anything concrete will show on github.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ahmedadelhosni no, I mean that I don't want features relating to signing to depend on encryption. Things like serials and hmac keys must never be sent OTA even with encryption enabled since the current encryption available (at least in SW) is very weak due to protocol limitations.
Progress on v3 is currently not moving because the core team is busy with other things.
We want to make a security solution that is robust, easy to use and properly secure so we do not want to rush anything. We are well under way with deciding the core principles but I will not publish the working documents because we quite frankly do not have time to handle questions from the public. Especially when we have not finalized the design.Rest assured fully qualified people are investigating and discussing the matter. In due course the results will become public as we are working with an open source project so anything concrete will show on github.
-
@Anticimex Great. Thanks for your time.
@ahmedadelhosni don't mention it. I strive to be as transparent as possible when it comes to security. And please, please let me know if there is anything missing from the documentation or things that can be improved in it.
We keep the next level security somewhat under wraps for now since we are not completely sure ourselves on how it is supposed to work just yet. Once we decide on that, we may publish something to get general feedback from anyone who might have input on the design (if so it will be a highly technical document) but most likely this will be a development process where anyone can test and evaluate it on a branch (like the development branch today) long before anything becomes an official release.
We will try to document it continuously as it evolves once we get to start doing actual code. -
@ahmedadelhosni
We lock the atsha to make sure it can't be readable.
It does not matter that samd supports locking or not. The atmega328p does not. For now, we have a security scheme that supports any target, so we have to have a system that works for all.
For MySensors v3, an entirely new security scheme is under consideration. But it will mean dropping support for the atmga328p as it is not powerful enough.
As for what others do, I suggest you ask them :)
Security can be implemented in many ways. Each with drawbacks and benefits. The one currently in use is a scheme that can work on basically any target with reasonable security and performance. It has drawbacks, yes, but at the time of implementation, these were considered acceptable.
For the future, more sophisticated schemes can be used which are easier to use, arguably more secure but more complex in terms of computational power and protocol. The core team is investigating various solutions.@Anticimex said in [security] Introducing signing support to MySensors:
For MySensors v3, an entirely new security scheme is under consideration. But it will mean dropping support for the atmga328p as it is not powerful enough.
Eeekk... Does that mean any nodes based on the pro-mini etc will no longer work with v3.0 signing? Or will there be backwards compatibility to still use these with ATSHA204 as we do today?
-
@Anticimex said in [security] Introducing signing support to MySensors:
For MySensors v3, an entirely new security scheme is under consideration. But it will mean dropping support for the atmga328p as it is not powerful enough.
Eeekk... Does that mean any nodes based on the pro-mini etc will no longer work with v3.0 signing? Or will there be backwards compatibility to still use these with ATSHA204 as we do today?
@skywatch The security solution known as "signing" and "encryption" today will still be available in v3, but will then be referred as "legacy" signing. It will be considered obsolete and only bugfixing will take place, but it will still be supported. Also for the current newer devices, but it might not be ported to upcoming platforms with higher performence.
-
That was a fast reply! :) - Thank you, at least I can carry on building now :)
Where are the latest docs for signing and encryption for ver 2.2.0-rc.1? A few links on the site no longer work and I am having trouble finding what to do (eg HW signing, attach ATSHA204 like this, then do this, then do the other thing and in your sketch do this etc.....) You get the idea! ;)
-
That was a fast reply! :) - Thank you, at least I can carry on building now :)
Where are the latest docs for signing and encryption for ver 2.2.0-rc.1? A few links on the site no longer work and I am having trouble finding what to do (eg HW signing, attach ATSHA204 like this, then do this, then do the other thing and in your sketch do this etc.....) You get the idea! ;)
-
Wouldn't you believe it? - I just found this....
https://www.mysensors.org/apidocs-beta/group__MySigninggrpPub.html
