[security] Introducing signing support to MySensors
-
@ahmedadelhosni some devices, like the atmega, doss not support locking the memory, so the software based signing is inherently insecure in terms of hw theft.
Atsha204a based signing protection specifically against this because the personalizer locks the chip from readout. It is not possible to extract the hmac key from the atsha204a memory and the key is never transmitted OTA (unless you deploy the personalizer OTA).1- So if we have a microcontroller that supports locking the memory then the problem is solved ? I know that SAM is being introduced now, Does it support this ?
2- what is then the purpose of locking the ATSHA if we can't extract the HMAC which we depend on it ?
Thanks.
-
1- So if we have a microcontroller that supports locking the memory then the problem is solved ? I know that SAM is being introduced now, Does it support this ?
2- what is then the purpose of locking the ATSHA if we can't extract the HMAC which we depend on it ?
Thanks.
@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.Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@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 Sorry but I didn't understand the benefit of locking the ATSHA to be unreadable ? :expressionless:
I know we do not lock it so that we can read the HMAC and use it during verification, but what is the usage of a locked ATSHA ? -
@Anticimex Sorry but I didn't understand the benefit of locking the ATSHA to be unreadable ? :expressionless:
I know we do not lock it so that we can read the HMAC and use it during verification, but what is the usage of a locked ATSHA ?@ahmedadelhosni what do you mean? All cryptography is performed inside the chip. The hmac key never leaves the chip after it has been programmed and locked. Thats the whole point with the atsha204a.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ahmedadelhosni what do you mean? All cryptography is performed inside the chip. The hmac key never leaves the chip after it has been programmed and locked. Thats the whole point with the atsha204a.
@Anticimex aha okay I understand a bit now. So we put s special hmac that does all cryptography jobs then it gives us something that is used for transmision?
Looks like i have to read the datasheet also :D
-
@Anticimex aha okay I understand a bit now. So we put s special hmac that does all cryptography jobs then it gives us something that is used for transmision?
Looks like i have to read the datasheet also :D
@ahmedadelhosni I'd suggest you start by reading the documentation on signing linked at the very top of this post. It explains in detail how the signing security is implemented.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ahmedadelhosni I'd suggest you start by reading the documentation on signing linked at the very top of this post. It explains in detail how the signing security is implemented.
@Anticimex yeah I read it several times before but maybe didnt pay attention to tge technical stuff 😂
-
@Anticimex yeah I read it several times before but maybe didnt pay attention to tge technical stuff 😂
@ahmedadelhosni :) not really needed to be able to use it, but it hopefully helps in understanding it ;)
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ahmedadelhosni :) not really needed to be able to use it, but it hopefully helps in understanding it ;)
@Anticimex yeah I know. I have already managed to use Siging in my network and it works.
I just wanted to understand more about how the code works and the technical stuff.
Thanks.
-
@Anticimex yeah I know. I have already managed to use Siging in my network and it works.
I just wanted to understand more about how the code works and the technical stuff.
Thanks.
@ahmedadelhosni You mean this? :)
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ahmedadelhosni You mean this? :)
@Anticimex Yeah actually I have read this post like 20 times before but I guess I begun to really understand the "technical" stuff today.
So basically what I understood is that we have a HMAC Key, which is generated and is saved in all devices, this is when we do step 1 'generate key' and step 2 'personalize'. Thus when the gateway needs to send to node X, it send to node X asking for a nonce from the ATSHA on Node 2 board. Then node 2 sends the nonce over the air. THe gateway then uses this nonce to produce signed message by first applying SHA then use the HMAC key to produce the signed data. Then the signed data is transmitted over the air to the node X again which does the same operations again and verify that the nonce produces the same signed message in small period of time ( to avoid replay block attacks)
Is my understanding correct :D ?
-
@Anticimex Yeah actually I have read this post like 20 times before but I guess I begun to really understand the "technical" stuff today.
So basically what I understood is that we have a HMAC Key, which is generated and is saved in all devices, this is when we do step 1 'generate key' and step 2 'personalize'. Thus when the gateway needs to send to node X, it send to node X asking for a nonce from the ATSHA on Node 2 board. Then node 2 sends the nonce over the air. THe gateway then uses this nonce to produce signed message by first applying SHA then use the HMAC key to produce the signed data. Then the signed data is transmitted over the air to the node X again which does the same operations again and verify that the nonce produces the same signed message in small period of time ( to avoid replay block attacks)
Is my understanding correct :D ?
@ahmedadelhosni yes
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@Anticimex finally I understood it. Actually I don't like using just the code without fully understanding the implementation. Thanks for support.
I will come with more questions maybe ;)
-
@Anticimex finally I understood it. Actually I don't like using just the code without fully understanding the implementation. Thanks for support.
I will come with more questions maybe ;)
@ahmedadelhosni Feel free to ask, but it is all documented. If what I say does not correspond to what the documentation says, please let me know so it can be improved.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ahmedadelhosni Feel free to ask, but it is all documented. If what I say does not correspond to what the documentation says, please let me know so it can be improved.
@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 ? -
@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 The documentation DO cover the technical aspects as well. I just linked directly to that chapter. What is missing from it?
What do you mean with "only use the hardware in private places"? If you only do that, then you don't need to revoke anything since the nodes most likely won't be stolen, right? Revoking is intended for "exposed" nodes.
You typically only need to reprogram your gateway since normally that is the node all other nodes talk to, and hence is the node that would carry the whitelist.
If you put a motion sensor outside, then enable signing and whitelisting on your nodes and then you can inform each and every node exactly what devices are permitted to communicate to it. If your other nodes only typically talk to your gateway, just have the gateway serial in their whitelist and they won't accept other nodes even if they would have the correct HMAC key to base their signatures on.
Even so, if a node is stolen I would highly recommend you change HMAC key because an attacker could dig out the serial of your gateway if it is in a whitelist in the stolen node and use that to spoof a gateway. -
@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 ?
