[security] Introducing signing support to MySensors
-
@hek @tbowmo also found this the "hard" way. There are also some other forum discussions on the topic. It is basically how the AVR is designed.
-
I had this concerned from beginning. I will sound like a noon, but I am working on building a custom controller with loads of user configurable interface. For sake of my understanding is there any diagram or video or any resource regarding how to interface the ATSHA204A with arduino @Anticimex .
If there is something like that it will be of a great help. I am going to post a video soon of my work in progress app which controls the devices. I am also working on a scenario where someone can use the normal switches(existing ones) to operate the device and app will update accordingly. Still making way through the ACK part and the hops as I am using Ruby to do all the work -
I had this concerned from beginning. I will sound like a noon, but I am working on building a custom controller with loads of user configurable interface. For sake of my understanding is there any diagram or video or any resource regarding how to interface the ATSHA204A with arduino @Anticimex .
If there is something like that it will be of a great help. I am going to post a video soon of my work in progress app which controls the devices. I am also working on a scenario where someone can use the normal switches(existing ones) to operate the device and app will update accordingly. Still making way through the ACK part and the hops as I am using Ruby to do all the work -
@mainali
Does this help you? Sometimes a few pics say more than a 1000 words :)I made this pic from the Datasheet giving you the pinouts of the ATSHA204A in all known housings.
And the way how to connect is (shamelessly stolen from the GW design of @Anticimex :) )
-
@mainali
Does this help you? Sometimes a few pics say more than a 1000 words :)I made this pic from the Datasheet giving you the pinouts of the ATSHA204A in all known housings.
And the way how to connect is (shamelessly stolen from the GW design of @Anticimex :) )
-
@Anticimex
Thanks for that info, to me it is clear that depending on the used pin in the software one should connect the ATSHA204A corresponding with the software.
Picture does show you being correct how simple it really is to embed the ATSHA204A hardware in the total setup. -
@phil83
I fear you've already ordered the ATSHA204A ? I'm also in Germany so that would be easy.
If not - I'd take 10 pcs. They cost close to nothing -> nice :)@Anticimex
I don't agree with "This is an unlikely usecase because it is really no reason to sign sensor values. If you for some reason want to obfuscate sensor data, encryption is a better alternative."I think of Sensors used for Alarm-Systems. You need to trust the sensor reading because otherwise the attacker might jam the original Sensor and send his own Sensor data to let the alarm-system think the window is still closed (e.g.).
One more question: Are the Serials in the ATSHA in ascending order (i.e. when you have a reel of ICs is each S/N old S/N+1 ?) If this is the case, would it be possible to steal a keyfob to get a valid signing device, read the serial, use that S/N +1, sign the message and get still access to the garage door? I.e. do something one could call "S/N spoofing"? (I know that it is much easier to just break the garage door with a crowbar, but I'm intrested in this - at least hypotheticaly :))
Unfourtunately I don't have much time at the moment to try it out by myself, but I'm still really excited about your work and effort!
-
@phil83
I fear you've already ordered the ATSHA204A ? I'm also in Germany so that would be easy.
If not - I'd take 10 pcs. They cost close to nothing -> nice :)@Anticimex
I don't agree with "This is an unlikely usecase because it is really no reason to sign sensor values. If you for some reason want to obfuscate sensor data, encryption is a better alternative."I think of Sensors used for Alarm-Systems. You need to trust the sensor reading because otherwise the attacker might jam the original Sensor and send his own Sensor data to let the alarm-system think the window is still closed (e.g.).
One more question: Are the Serials in the ATSHA in ascending order (i.e. when you have a reel of ICs is each S/N old S/N+1 ?) If this is the case, would it be possible to steal a keyfob to get a valid signing device, read the serial, use that S/N +1, sign the message and get still access to the garage door? I.e. do something one could call "S/N spoofing"? (I know that it is much easier to just break the garage door with a crowbar, but I'm intrested in this - at least hypotheticaly :))
Unfourtunately I don't have much time at the moment to try it out by myself, but I'm still really excited about your work and effort!
@Dirk_H The signing solution can be applied to both sensors and gateways. If you feel the need to have the gateway require signed messages from nodes, there is nothing to prevent it. I have already thought of that scenario and implemented support for it.
Regarding jamming, no security system can prevent that.
Regarding the generation of serials, you have to contact Atmel about that. And you still need to obtain the preshared key in order to generate properly signed messages. Neither the key nor the serial is ever sent over the air in clear text.
-
@Anticimex
Thank you very much for this solution.I think your solution is the best compromise, if you don't want to transmit more data.
The drawback is, that it isn't really as secure as AES 256 or above. It is a compromise.
What about a solution
- where the original message is untouched without a signature
- a consumer requests an AES 256 signature of this message, if he really needs it
- a second/third signature message is sent to the consumer with full AES 256 signature
In this solution, you could use different keys for different nodes and the risk of stolen keys would be minimized.
-
@Anticimex
Thank you very much for this solution.I think your solution is the best compromise, if you don't want to transmit more data.
The drawback is, that it isn't really as secure as AES 256 or above. It is a compromise.
What about a solution
- where the original message is untouched without a signature
- a consumer requests an AES 256 signature of this message, if he really needs it
- a second/third signature message is sent to the consumer with full AES 256 signature
In this solution, you could use different keys for different nodes and the risk of stolen keys would be minimized.
@FotoFieber
I think sha256 is pretty secure enough :)
Regarding splitting signature and message, I am not too fond of that, because it opens up a lot of attack vectors and it also put requirements on the sender to be able to retain a sent message. Potentially a lot of nodes sends data back and forth, so what happens if, for instance, the gateway sends a message to one node, then sends another message to another node, and then the first node sends a message requesting a signature on a message the gateway no longer has. We have to remember that ram memory is very limited so there are limits in what we can do with message management, unfortunately.
But all feedback is appreciated! Thanks! -
@Anticimex
sha256 is secure enough. But if I understand the implementation correctly, you use the space at the end of the payload for the signature and not the full signature.Another thing to consider is that the strength of the signature is inversely proportional to the payload size.
If I calculate it right, the length of the signature is less or equal (23 bytes) 184 bit.
With a payload of 4 bytes, which would probably be the usual payload I have here, there would be left only 160 bit (20 bytes).
In comparison a HMAC_SHA256 uses 256 bit,
Or did I miss something?
It could be implemented quite simple:
- Node sends data to gateway which in my case is published to MQTT
- some consumer likes to have this signed and sends the node the message back with a sign request
- the node looks at the message and checks, if the value inside the message is still valid. When ok, it sends a HMAC splitted in two messages. If not, it ignores the message or sends NOK.
The problem with this implementation would be, that the node hast to be active to get the singing request.
Maybe it would be better to just send two other messages with the HMAC after the data.
I would suggest to implement the check of the HMAC where it is needed, not in the gateway, In my case, this would be node-red.
-
@Anticimex
sha256 is secure enough. But if I understand the implementation correctly, you use the space at the end of the payload for the signature and not the full signature.Another thing to consider is that the strength of the signature is inversely proportional to the payload size.
If I calculate it right, the length of the signature is less or equal (23 bytes) 184 bit.
With a payload of 4 bytes, which would probably be the usual payload I have here, there would be left only 160 bit (20 bytes).
In comparison a HMAC_SHA256 uses 256 bit,
Or did I miss something?
It could be implemented quite simple:
- Node sends data to gateway which in my case is published to MQTT
- some consumer likes to have this signed and sends the node the message back with a sign request
- the node looks at the message and checks, if the value inside the message is still valid. When ok, it sends a HMAC splitted in two messages. If not, it ignores the message or sends NOK.
The problem with this implementation would be, that the node hast to be active to get the singing request.
Maybe it would be better to just send two other messages with the HMAC after the data.
I would suggest to implement the check of the HMAC where it is needed, not in the gateway, In my case, this would be node-red.
@FotoFieber
Regarding the weakened security based on the message size, you are correct.
But I still disagree on splitting the messages because it will mean that some messages will fail to be signed (depending on network load) and it is no good to have a solution that adds uncertainty in that respect. And I definitely do not want to add restrictions on which types of nodes are capable on signing and which are not. Having the gateway signing messages is a very real application in use cases like locks and such.
The opposite is also equally valid, some nodes might send "important" data. The gateway needs to be able to authenticate such nodes (keyfobs etc).
We have to weigh complexity vs resources, and currently we are pretty much at the limit of our capabilities. An ethernet or mqtt gateway running on an Arduino nano can today barely fit HW support for signing. SW signing does not fit. So we can't really get more complex with the solution without also stepping up the HW platform we execute on. -
I should add that even if signature was separated in its own message, it still would not be full since the rf solution is only capable of sending 32 byte messages and some bytes are needed for routing info. So if "full" signature is required, some framing protocol will also be needed, and then things really get out of hand on a poor Arduino nano or pro mini.
I would suggest using RF69 with AES encryption if the signing scheme in place is inadequate. -
Hi.
I am trying to design some boards. And I would like to have a little precision.
If I understand right, as signing is included in rfm69 radiohead library with mysensors, I don't need atsha? Atsha recommanded with nrf?@scalz
Well, it depends on what you want. In the first post I have outline my stance on the matter. I prefer signing before anything. RF69 offer optional encryption, not signing. If you are happy with just encryption, then you don't need ATSHA but have to use RF69 (or another circuit). -
@Anticimex : you are right. I confused two different things!! So I think the best is combination of both.
Thank you for your precision and for sharing your work. -
@Anticimex : you are right. I confused two different things!! So I think the best is combination of both.
Thank you for your precision and for sharing your work. -
@Anticimex : you are right. I confused two different things!! So I think the best is combination of both.
Thank you for your precision and for sharing your work.@scalz
For the record, I share your opinion on using a combination. I will probably go for that myself when I fully deploy my sensornetwork. RF69 with AES encryption on RF level, and ATSHA authentication on protocol level should be enough to protect against most deliberate non-physical mischief.
