Security
-
@Zeph said:
Does the repeating node change anything in the header?
Yep, it changes the "last" field.
@hek said:
Does the repeating node change anything in the header?
Yep, it changes the "last" field.So if there is an authentication hash of some sort which includes the header, it might omit that byte, so that repeating nodes can pass the encrypted portion "as is" without needing to decrypt and encrypt again just to change that field.
-
@hek said:
Does the repeating node change anything in the header?
Yep, it changes the "last" field.So if there is an authentication hash of some sort which includes the header, it might omit that byte, so that repeating nodes can pass the encrypted portion "as is" without needing to decrypt and encrypt again just to change that field.
Wouldn't it be easier to skip encryption of header al together. It shouldn't contain much sensitive information.
Repeater nodes needs "sender", "destination" and "last" field to be able to route messages to the right direction (and update its routing tables).
I have put "type" and "sensor" field in the end of the header if we would want to encrypt this. -
@hek
Yes, I was suggesting not encrypting the header, it would be plaintext.But a few pasts back @daulagari made a good point:
Actually the whole plaintext header should be input to the key or IV as we want to be sure those contents are no changed.
And that made some sense - the header would be in plaintext but any changes would be detectable to make spoofing harder (ie: the header part would authenticated but not encrypted). If you changed any part of the header, the packet would not authenticate.
I was following up on that with the idea that MOST of the header could be authenticated, but the "last" byte would change in transit so it should not be part of the authentication. The receipient could validate that the rest of the header had not changed tho.
-
@hek
Yes, I was suggesting not encrypting the header, it would be plaintext.But a few pasts back @daulagari made a good point:
Actually the whole plaintext header should be input to the key or IV as we want to be sure those contents are no changed.
And that made some sense - the header would be in plaintext but any changes would be detectable to make spoofing harder (ie: the header part would authenticated but not encrypted). If you changed any part of the header, the packet would not authenticate.
I was following up on that with the idea that MOST of the header could be authenticated, but the "last" byte would change in transit so it should not be part of the authentication. The receipient could validate that the rest of the header had not changed tho.
-
I've orderd these nRF24LE1 and if we are getting encryption I think it would be wise to be compatible with the embedded encryption: http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24LE1
I dont know if its a waste of money but I got 2 for 3€ a piece.
-
I've orderd these nRF24LE1 and if we are getting encryption I think it would be wise to be compatible with the embedded encryption: http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24LE1
I dont know if its a waste of money but I got 2 for 3€ a piece.
@Damme
Keep us informed of your progress!I haven't wanted to set up toolchain and libraries for an 8051 (with which I'm not familiar), so I've not looked into that chip. And I haven't looked into what its AES acceleration feature consists of.
If it's just a speedup for software AES faster and with less 8051 code and RAM space, then it might still be possible to make use of AES in a chaining mode that makes it a stream cipher. If it's more directly tied into encrypting packets directly as a block cipher, it could be harder to use given the discussion above.
On another forum somebody considering that chip was nudged by Nordic's application engineers to use the nRF51822 instead, as their suggested replacement for the nRF24LE1. It has much better resources for not much more cost (at the chip level). And there is an Arduino derived development environment (RFDuino), as well as an mBed system that might (or might not) be adaptable. I'm more interested in facing the learning curve for ARM than for 8051. (Most developers use the nRF51822 in BLE mode, but it is also supposed to be able to emulate ESB for compatibility with the nRF24L01+)
Good luck!
-
@Damme
Keep us informed of your progress!I haven't wanted to set up toolchain and libraries for an 8051 (with which I'm not familiar), so I've not looked into that chip. And I haven't looked into what its AES acceleration feature consists of.
If it's just a speedup for software AES faster and with less 8051 code and RAM space, then it might still be possible to make use of AES in a chaining mode that makes it a stream cipher. If it's more directly tied into encrypting packets directly as a block cipher, it could be harder to use given the discussion above.
On another forum somebody considering that chip was nudged by Nordic's application engineers to use the nRF51822 instead, as their suggested replacement for the nRF24LE1. It has much better resources for not much more cost (at the chip level). And there is an Arduino derived development environment (RFDuino), as well as an mBed system that might (or might not) be adaptable. I'm more interested in facing the learning curve for ARM than for 8051. (Most developers use the nRF51822 in BLE mode, but it is also supposed to be able to emulate ESB for compatibility with the nRF24L01+)
Good luck!
-
I'm going for this approach. I will use this as authentication chip. I see noo benefit of encrypting the payload. Verifying it to originate from a trusted source on the other hand is essential (for locks etc.). The major problem I see at the moment is the limitation of the payload size due to RF24. The messages are going to have to be split up, thus in some respect reducing the efficiency of the authentication mechanism, but an attacker really need to be stubborn to exploit that.
-
I'm rethinking this thread a bit. A key problem that complicated our discussion was the short packet length. My goal was to add no more than 4 bytes to the packet contents, which implies some compromises.
The new approach I'm considering is having an optional second packet with authentication & replay resistance resistance for the first packet.
A given sensactuator node could be programmed to require this second packet or not, depending on what it controls. If it's required, then the node must receive both the command packet and the authentication packet (within some time period) before it would take actions.
In this way, the regular packets could be unchanged and we would not need to reserve extra space.in the command packet. Meanwhile the authentication packet could have room for more information - eg: rolling code, nonce, hash of the payload of the other packet, as well as the plaintext normal routing headers.
-
How abour SipHash? Output is only 8 bytes
Only 8 bytes (64 bits) output is not a plus. MD5 is 128 bits and already considered insecure (partly because of design flaws). Based in this I think 64 bits will be for sure insecure.
See also the rest of this thread, just a message digest is very likely not the best solution.
-
How abour SipHash? Output is only 8 bytes
Only 8 bytes (64 bits) output is not a plus. MD5 is 128 bits and already considered insecure (partly because of design flaws). Based in this I think 64 bits will be for sure insecure.
See also the rest of this thread, just a message digest is very likely not the best solution.
-
the idea was to use it to implement some kind of HMAC and combine it with a stream cipher or a vernam cipher.
See also the earlier discussion, I think a cipher alone can provide authentication without addition MAC.
If you can decode the encrypted message successfully you know that the party you received the message from knows the key and I think that is as good as you can get authentication.
-
That is a possibility but I believe a benefit of skipping encryption and rely on signature allows a client to ignore the security part (if so desired) which potentially allows for the protocol to implement security by default, i. e. signing all messages. Depending on where the ambition level lies this could increase the amount of traffic (passing nonce back and forth and such) but have not gotten the impression that congestion is an issue.
-
Depending on where the ambition level lies this could increase the amount of traffic (passing nonce back and forth and such) but have not gotten the impression that congestion is an issue.
Yes, if you see no problem with the added data needed for the HMAC, I agree this is no problem but if you combine encryption and a hash the hash is overkill.
So I think you plan is to add say 8 bytes to the message content as HMAC?
From the My "hybrid" gateway thread I understand you plan to use the ATSHA204 that has SHA1 (20 bytes). That would be a good option and you do not have to send all 20 bytes, less bytes would mean less secure but 20 bytes is I think currently overkill for sensor data.
-
No, it uses sha256 so it's 32 bytes. Sha1 is crackable so it is useless. The messages unfortunately have to be broken into more transmissions. But for proper security I am afraid it is necessary. On the other hand, the only services that should need security on this level is remotely operated locks or something similar.
-
Sha1 is crackable so it is useless.
Well, your standards are pretty high ;-)
From Wikipedia:
As of 2012, the most efficient attack against SHA-1 is considered to be the one by Marc Stevens[34] with an estimated cost of $2.77M to break a single hash value by renting CPU power from cloud servers.
Do not forget to add apart from the hash a "replay-counter" and the mechanisms to check it otherwise opening the locks next day is just a matter of copying the signed message of the day before.
-
Sha1 is crackable so it is useless.
Well, your standards are pretty high ;-)
From Wikipedia:
As of 2012, the most efficient attack against SHA-1 is considered to be the one by Marc Stevens[34] with an estimated cost of $2.77M to break a single hash value by renting CPU power from cloud servers.
Do not forget to add apart from the hash a "replay-counter" and the mechanisms to check it otherwise opening the locks next day is just a matter of copying the signed message of the day before.
@daulagari Well, wikipedia is not what I consider a reliable source for this kind of info ;) In my work, we have since long forbidden SHA1 usage. That said, using RF24 the security gets somewhat compromised since the messages will be split in parts. But I was thinking of countering that by scrambling the signature and data that are transmitted using a pre-shared algorithm so even if the attacker focused on a part of the message, the attacker will have some trouble figuring out what parts are signature and what part is clear text.
My flow covers replay-attacks by requiring a new nonce for every message. Each message is uniquely signed. They cannot be replay-exploited, nor man-in-the middle compromised unless the attacker knows my secret, and the unique serial of the receiver. Both which are never sent over the RF line. The chip also offers an OTP to protect against physical attack by never exposing the data on a physical pin, but if someone gets access to the Arduino controlling the lock, security on that level becomes rather pointless :)
-
Let's remember the value of the target. How much is it worth to be able to remotely open some blinds? Even for a few who might want to unlock their door via MySensors (vs some other system) I cannot imagine that thieves are likely to spend the amount of time and money it would cost to break in via crytographic means, when there are so many other ways that are cheap and accessible. If anybody here keeps million dollar valued items in their home secured ONLY by MySensors wireless networks, such that a thief would find it worthwhile to mount a major crypto attack to obtain them, then perhaps they should rethink and add other security which is not MySensors based.
So we want reasonable security, within the parameters of our context.
One advantage of the "second packet" approach would be that swapping out a different algorithm would not require any changes to the main protocol.
That said, I want to acknowledge the appeal of signing all messages and leaving it up to the receiver whether it will verify that signing. I'm not sure whether that advantage is worth the effort yet, but I see why it could be good.
