[security] Introducing signing support to MySensors
-
@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. -
@Anticimex : I totally agree with you. I am still defining my needs too. I have only some nrf nodes but I think Mysensors + RFM + Atsha + ota=Zwave killer! it might eliminate repeater needs.
On my designs I put nrf and rfm footprints but I think I will move to rfm as soon as I can. I will share my designs when it will be tested. Hope there will be lots of boards for mysensors in the future.
Have a good day! -
@Anticimex : I totally agree with you. I am still defining my needs too. I have only some nrf nodes but I think Mysensors + RFM + Atsha + ota=Zwave killer! it might eliminate repeater needs.
On my designs I put nrf and rfm footprints but I think I will move to rfm as soon as I can. I will share my designs when it will be tested. Hope there will be lots of boards for mysensors in the future.
Have a good day!@scalz
I have actually designed a board that supports both radios. I have just received them but have not mounted them with components yet so I have not been able to verify the design. But I will post it on the forum as soon as I have. It will be pin-compatible with Sensbender Micro but also support RF69. It is not intended to be replacing that board nor is it an "official" MySensor board. I have just designed it to fit my personal preferences and to serve as a generic multi-purpose sensor backend (it relies on modules and has a lot of headers to support many sensors in parallel on both 3.3 and 5V rails). -
wow. can't wait to see your creations! Seems interesting. Your board could be very helpful.
I love Sensebender. But 0402, it was difficult to solder for me! So I am trying to use 0805 in my designs, easier for me.
I am finishing to modify a moteino (0805 so a little bigger) to add nrf and atsha. I am waiting for others boards (not received yet) : uCurrent module, one power management optimization board (based on ulpnode idea), esp8266-07 with nrf, rfm and atsha (I will try to make sort of mqtt gateway), and a mysensors relay board. I have others idea too: dimmer for one main, hb100 (for barrier security), mgc3030 (for gesture. lot of stuff on this one I think). But before I must finish what I started. Hihi, mysensors and automation is addictive!I read in previous post that you advised not to use A6,A7 for atsha. But I imagine that I can use others pin (if i take care of datasheet of course)? I think it is doable, just have to modify pin ref in code next, isn't it? Anyway, I always try to keep mysensors reference design (A3), it is just for personal info.
-
wow. can't wait to see your creations! Seems interesting. Your board could be very helpful.
I love Sensebender. But 0402, it was difficult to solder for me! So I am trying to use 0805 in my designs, easier for me.
I am finishing to modify a moteino (0805 so a little bigger) to add nrf and atsha. I am waiting for others boards (not received yet) : uCurrent module, one power management optimization board (based on ulpnode idea), esp8266-07 with nrf, rfm and atsha (I will try to make sort of mqtt gateway), and a mysensors relay board. I have others idea too: dimmer for one main, hb100 (for barrier security), mgc3030 (for gesture. lot of stuff on this one I think). But before I must finish what I started. Hihi, mysensors and automation is addictive!I read in previous post that you advised not to use A6,A7 for atsha. But I imagine that I can use others pin (if i take care of datasheet of course)? I think it is doable, just have to modify pin ref in code next, isn't it? Anyway, I always try to keep mysensors reference design (A3), it is just for personal info.
@scalz
Then you'll be happy to hear that my board uses 0805 and 1206 and also has enlarged pads for hand soldering on all SMD footprints :)
It also features a jumper for current measurement, three power connection options, switchable regulators for super low standby currents and some other features. But I will give the details in a separate post. -
wow. can't wait to see your creations! Seems interesting. Your board could be very helpful.
I love Sensebender. But 0402, it was difficult to solder for me! So I am trying to use 0805 in my designs, easier for me.
I am finishing to modify a moteino (0805 so a little bigger) to add nrf and atsha. I am waiting for others boards (not received yet) : uCurrent module, one power management optimization board (based on ulpnode idea), esp8266-07 with nrf, rfm and atsha (I will try to make sort of mqtt gateway), and a mysensors relay board. I have others idea too: dimmer for one main, hb100 (for barrier security), mgc3030 (for gesture. lot of stuff on this one I think). But before I must finish what I started. Hihi, mysensors and automation is addictive!I read in previous post that you advised not to use A6,A7 for atsha. But I imagine that I can use others pin (if i take care of datasheet of course)? I think it is doable, just have to modify pin ref in code next, isn't it? Anyway, I always try to keep mysensors reference design (A3), it is just for personal info.
-
Very interesting. So your board will be a great addition. I will follow your work for sure!
Thank you very much for your help. -
Hi @all!
First off all: thanks for your great work :-)
I am about to compile the ethernet gw with software signing, but unfortunately I am getting some compile errors.
Does anyone maybe have a sketch handy and would up it here?Thanks in advance and best regards,
Otto
-
Hi @all!
First off all: thanks for your great work :-)
I am about to compile the ethernet gw with software signing, but unfortunately I am getting some compile errors.
Does anyone maybe have a sketch handy and would up it here?Thanks in advance and best regards,
Otto
-
@Anticimex:
Thanks, but I am trying to compile it for an UNO R3?! That should do it. Nevertheless: Using nanos only for nodes should work with sw signing, shouldnt it?
