Security
-
I was referring to CFB or OFB chaining modes
In your earlier reply you were referring to this as "stream cipher" so I thought you thought of Cipher feedback (CFB) or Output feedback (OFB) which are not good choices. CFB or OFB chaining is fine.
On indicating the cipher in the presentation, yes, this adds a small cost but I do not see why we should have a presentation at all ;-)
If we want to keep things limited in space and processing time, yes then a pre-shared key (PSK) is the only option. The other options is using certificates, public-key cryptosystems and things like Diffie–Hellman but like said that will not fit.
I see no problem using the same PSK as input for all nodes and the hub but I think the key (or IV) for every node should be different and maybe different for every packet. That is not difficult just use the node Id and the sequence counter.
Actually the whole plaintext header should be input to the key or IV as we want to be sure those contents are no changed.
Remaining discussion points I see:
- XXTEA or XTEA or some other choice for "less secure"
- Do we still need a random number field? I think not, can be combined with the sequence counter
- What size should the sequence counter be
- How does the receiving side after decoding decide the content is valid
@daulagari said:
Actually the whole plaintext header should be input to the key or IV as we want to be sure those contents are no changed.
Good point.
Does the repeating node change anything in the header?
- How does the receiving side after decoding decide the content is valid
Well, what I had suggested is that the 32 bits added at the end of a packet would need to decode to a sequence number in the range N+1 to N+m. If not, it's invalid.
-
@daulagari said:
Actually the whole plaintext header should be input to the key or IV as we want to be sure those contents are no changed.
Good point.
Does the repeating node change anything in the header?
- How does the receiving side after decoding decide the content is valid
Well, what I had suggested is that the 32 bits added at the end of a packet would need to decode to a sequence number in the range N+1 to N+m. If not, it's invalid.
-
@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.
