Security
-
@Zeph said:
The first goal is to authenticate and prevent playback attacks; confidentiality is secondary. And this is not going to be used in banking.
Yes I agree first is authentication and and preventing playback attacks
To do that reasonable secure you need either a keyed-hash (HMAC) with sufficient length and a counter with sufficient length or block cipher with a (shorter) counter.
For the HMAC + counter approach 16 bits each is pretty short I think, remember that apart from passive scanning a "hacker" can also actively scan sending "probe" packets and see what the response is, a well known attach for 802.11 WEP. Need some more time to come up with some numbers.
Re-reading my story above I noted that it was based on wrong a wrong idea.
Yes, with a block size of 64 bytes you need already two+ packets, with 128 (like AES) even four+. That sounds not attractive and likely overkill. On AVR-Crypto-Lib I see no block ciphers with a block size of 32 bytes or smaller...I'm not thrilled with needing to implement multiple ciphers
No that is for sure something that I did not have in mind for nodes but maybe ... for the gateway. If somebody likes to do locks one day, the requirements will be higher than authentication and preventing playback and it would be good to be future proof for that.
@daulagari said:
To do that reasonable secure you need either a keyed-hash (HMAC) with sufficient length and a counter with sufficient length or block cipher with a (shorter) counter.
- If the payload itself is encrypted, why do you need a HMAC?
- Why is a longer counter needed to avoid playback with a stream cipher than with a block cipher? (One of the options for a stream cipher is using the AES in one of the block chaining modes that create a stream cipher).
For the HMAC + counter approach 16 bits each is pretty short I think, remember that apart from passive scanning a "hacker" can also actively scan sending "probe" packets and see what the response is, a well known attach for 802.11 WEP.
That's a good thing to keep in mind. But remember, the entire payload is encrypted with a fairly decent cipher, so the bits get pretty well scrambled. WEP had a weakness to probe. Do you know a weakness of AES with which to form the probes? Can you do it with less than billions of probes?
If it gets down to being close to brute force, then of course the attacker could just send all possible combinations of payload bits and see if anything reacts. But that's gonna take a while!
Which brings up another thing - perhaps we should have some simple level of intrusion detection. If you see a few thousand packets an hour which pass the nRF's CRC but fail the crypto, maybe you should be notified? Or even 10? What if a crytpo enable actuator node were to have a "crypto_fail_count" variable which it would report periodically, like every 1,2,4,8,16 or whatever failures (or it could be polled)? Not a lot of additional code.
You have in mind only the hub handling multiple algorithms (dynamically chosen). Each crypto enabled node would have a single algorothm. The core issue to protect is commands from the hub TO certain critical actuator nodes, like blinds or door locks. If the hub can use multiple algorithms, it has to LOOK UP which algorithm to use when sending TO a given actuator node in that scenario, somewhere in its configuration. So it could also look up which algorithm to use when receiving FROM that node. Embedding an algorithm id in the header bytes then becomes neither sufficient (doesn't tell the hub what to use for sending) nor necessary (the hub has that same way to know which to use when receiving). So all that adding the ID does is waste some precious header space and give an attacker some additional clues.
-
@daulagari said:
To do that reasonable secure you need either a keyed-hash (HMAC) with sufficient length and a counter with sufficient length or block cipher with a (shorter) counter.
- If the payload itself is encrypted, why do you need a HMAC?
- Why is a longer counter needed to avoid playback with a stream cipher than with a block cipher? (One of the options for a stream cipher is using the AES in one of the block chaining modes that create a stream cipher).
For the HMAC + counter approach 16 bits each is pretty short I think, remember that apart from passive scanning a "hacker" can also actively scan sending "probe" packets and see what the response is, a well known attach for 802.11 WEP.
That's a good thing to keep in mind. But remember, the entire payload is encrypted with a fairly decent cipher, so the bits get pretty well scrambled. WEP had a weakness to probe. Do you know a weakness of AES with which to form the probes? Can you do it with less than billions of probes?
If it gets down to being close to brute force, then of course the attacker could just send all possible combinations of payload bits and see if anything reacts. But that's gonna take a while!
Which brings up another thing - perhaps we should have some simple level of intrusion detection. If you see a few thousand packets an hour which pass the nRF's CRC but fail the crypto, maybe you should be notified? Or even 10? What if a crytpo enable actuator node were to have a "crypto_fail_count" variable which it would report periodically, like every 1,2,4,8,16 or whatever failures (or it could be polled)? Not a lot of additional code.
You have in mind only the hub handling multiple algorithms (dynamically chosen). Each crypto enabled node would have a single algorothm. The core issue to protect is commands from the hub TO certain critical actuator nodes, like blinds or door locks. If the hub can use multiple algorithms, it has to LOOK UP which algorithm to use when sending TO a given actuator node in that scenario, somewhere in its configuration. So it could also look up which algorithm to use when receiving FROM that node. Embedding an algorithm id in the header bytes then becomes neither sufficient (doesn't tell the hub what to use for sending) nor necessary (the hub has that same way to know which to use when receiving). So all that adding the ID does is waste some precious header space and give an attacker some additional clues.
The block sizes are not that bad!
Not sure what I was drinking yesterday evening but I mixed up bit with bytes! ;-)
- If the payload itself is encrypted, why do you need a HMAC?
No, if the payload itself is encrypted with a block cipher you do not necessarily need an HMAC. (the bits-bytes confusion made me thing we could not use block ciphers without needing more than one packet)
- Why is a longer counter needed to avoid playback with a stream cipher than with a block cipher? (One of the options for a stream cipher is using the AES in one of the block chaining modes that create a stream cipher).
A stream cipher is a cipher where plaintext bits are combined with a cipher bit stream by a xor. That means that if you want to flip a particular bit of the (encrypted) message you just have to invert that bit, see Bit-flipping attack.
AES in block chaining mode is not a stream cipher as I see it unless you want to use it as random bit stream generator and use that for a stream cipher. Not a good idea.
Yes, to counter act probe attacks, you probably should add some kind of rate limit, but still for a somewhat larger network you can still probe the nodes one by one and have a decent probe rate.
But, let's first calculate what is needed to make a system such that it would say take on three years before "the key is found" and only then think about preventing that even further.
You have in mind only the hub handling multiple algorithms
Indeed.
Embedding an algorithm id in the header bytes then becomes neither sufficient (doesn't tell the hub what to use for sending) nor necessary (the hub has that same way to know which to use when receiving).
Yes, you are right, maybe not needed in the header but I still would like to have a node communicate to the hub what kind (if any) crypto is wants to use. A better place for that might be the presentation.
I think for "less" secure things XXTEA/XTEA is a good idea. Anybody knows which is better?
For more secure things I think AES is the way to go. -
The block sizes are not that bad!
Not sure what I was drinking yesterday evening but I mixed up bit with bytes! ;-)
- If the payload itself is encrypted, why do you need a HMAC?
No, if the payload itself is encrypted with a block cipher you do not necessarily need an HMAC. (the bits-bytes confusion made me thing we could not use block ciphers without needing more than one packet)
- Why is a longer counter needed to avoid playback with a stream cipher than with a block cipher? (One of the options for a stream cipher is using the AES in one of the block chaining modes that create a stream cipher).
A stream cipher is a cipher where plaintext bits are combined with a cipher bit stream by a xor. That means that if you want to flip a particular bit of the (encrypted) message you just have to invert that bit, see Bit-flipping attack.
AES in block chaining mode is not a stream cipher as I see it unless you want to use it as random bit stream generator and use that for a stream cipher. Not a good idea.
Yes, to counter act probe attacks, you probably should add some kind of rate limit, but still for a somewhat larger network you can still probe the nodes one by one and have a decent probe rate.
But, let's first calculate what is needed to make a system such that it would say take on three years before "the key is found" and only then think about preventing that even further.
You have in mind only the hub handling multiple algorithms
Indeed.
Embedding an algorithm id in the header bytes then becomes neither sufficient (doesn't tell the hub what to use for sending) nor necessary (the hub has that same way to know which to use when receiving).
Yes, you are right, maybe not needed in the header but I still would like to have a node communicate to the hub what kind (if any) crypto is wants to use. A better place for that might be the presentation.
I think for "less" secure things XXTEA/XTEA is a good idea. Anybody knows which is better?
For more secure things I think AES is the way to go.@daulagari said:
AES in block chaining mode is not a stream cipher as I see it unless you want to use it as random bit stream generator and use that for a stream cipher. Not a good idea.
I was referrring to CFB or OFB chaining modes (http://en.wikipedia.org/wiki/Cipher_block_chaining)
Yes, you are right, maybe not needed in the header but I still would like to have a node communicate to the hub what kind (if any) crypto is wants to use. A better place for that might be the presentation.
That makes more sense. Still not sure it's needed, but the cost is smaller.
I guess the idea is that they have the appropriate pre-shared keys for the algorithm, but don't have a pre-shared algorithm id? Or are you thinking that the same keys are used for every algorithm?
The hub does indeed need more power for this. Initializing each algorithm for a given key takes some time and space, as well as carrying the code for all of them. But this is making more sense as we explore it.
-
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
-
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.
