Security
-
@Zeph said:
How large are typical MySensors payloads?
7 bytes header, + payload.
For 1.3 the payload is ASCII text (normally)
For 1.4 the payload depends on the datatype, e.g. 1 byte for uint8_t, 4 bytes for long.The header you should probably not, or only partially encrypt as it is required for routing the messages.
@Yveaux
So a command to raise the blinds could consist of:7 bytes of unencrypted header
N+1 bytes of encrypted content:- 1 byte of data to control the blinds
- N bytes of sequence/nonce/validity check for
This is assuming that we come up with a stream cipher and that we do not encrypt the header. If we used AES in block mode, we'd pad with zeros to 16 encrypted bytes.
If N=8, there's a lot of overhead to protect one byte :-)
But that's OK
-
Coming back to what @axillent said:
in general (if intruder do not knew that you are using MySensors) a complex radio sniffer hardware/software is needed
in case he/she knews about MySensor he/she still will need a complex radio sniffering if you will change BASE_RADIO_ID and radio channelThings have become more easy using the Wireless nRF24L01+ sniffer for MySensors.
On the blog from @Yveaux you can also find a link to Promiscuity is the nRF24L01+'s Duty post which indicates only two address bytes are needed. Furthermore there is information on using an AMICCOM A7125 chip that does not need address information at all it seems.
Only things still need is a spectrum analyzer for the 2.4 GHz in max hold mode and you know the channel.
-
Coming back to what @axillent said:
in general (if intruder do not knew that you are using MySensors) a complex radio sniffer hardware/software is needed
in case he/she knews about MySensor he/she still will need a complex radio sniffering if you will change BASE_RADIO_ID and radio channelThings have become more easy using the Wireless nRF24L01+ sniffer for MySensors.
On the blog from @Yveaux you can also find a link to Promiscuity is the nRF24L01+'s Duty post which indicates only two address bytes are needed. Furthermore there is information on using an AMICCOM A7125 chip that does not need address information at all it seems.
Only things still need is a spectrum analyzer for the 2.4 GHz in max hold mode and you know the channel.
-
Coming back to what @axillent said:
in general (if intruder do not knew that you are using MySensors) a complex radio sniffer hardware/software is needed
in case he/she knews about MySensor he/she still will need a complex radio sniffering if you will change BASE_RADIO_ID and radio channelThings have become more easy using the Wireless nRF24L01+ sniffer for MySensors.
On the blog from @Yveaux you can also find a link to Promiscuity is the nRF24L01+'s Duty post which indicates only two address bytes are needed. Furthermore there is information on using an AMICCOM A7125 chip that does not need address information at all it seems.
Only things still need is a spectrum analyzer for the 2.4 GHz in max hold mode and you know the channel.
@daulagari said:
Things have become more easy using the Wireless nRF24L01+ sniffer for MySensors.
Slightly. If you know the first 4 bytes of the address, it's easy to find the fifth anyway. That sniffer doesn't help you find those 4 bytes tho.
On the blog from @Yveaux you can also find a link to Promiscuity is the nRF24L01+'s Duty post which indicates only two address bytes are needed.
That does help you find the full address, given enough false hits over time.
Furthermore there is information on using an AMICCOM A7125 chip that does not need address information at all it seems.
Only things still need is a spectrum analyzer for the 2.4 GHz in max hold mode and you know the channel.That could make it easier still. Or as I mentioned one could use SDR (software defined radio) to discover both (spectrum analyzing and raw packet decoding).
It's definitely feasible to break in to MySensors, with enough technical expertise and enough motivation. And a close enough location to do the monitoring and spoofing.
The same could be said for opening my automatic garage door, rolling codes and all.
But then, somebody with enough motivation could just break a window and enter while I'm gone too. It's all a matter of the costs, benefits, and odds.
We could shift the odds more in our favor with a stream encryption, at some cost in complexity and performance.
-
@Zeph : Fully agreed, only point I wanted to make is that things have become cheaper.
Would be good to keep this thread updated with the latest on what are the costs I think.
@daulagari
Yes we are agreed.I am continuing to think about this. I think that what makes the most sense is a stream cipher which can encode 1..32 bytes, and which can include or exclude the network header. (Versus a block mode like plain AES in ECB mode, which can only encode 16 byte chunks). We could use some of the chaining modes to convert a block cipher to a stream cipher, or could just use a pure stream cipher.
We need something which has a small footprint, in code, RAM and time.
I'm currently leaning towards combined authentication, confidentiality, and playback resistance, even tho the middle aspect may not be critical. Having a large message digest isn't going to fit - the system also needs to minimize the data added to a packet.
I'm thinking of using a 32 bit incrementing counter appended to the end of a payload before encryption. The counter could be initialized to a random value at first and would increment with each new packet. When decrypting, the last 4 bytes would need to be in the range N+1 to N+m, where N was the last valid received counter and m is the window. If fewer than m packets are lost, we will resyncronize automatically with the next valid packet. There would be a way to transmit the shared key and initial counter value to a node, given physical access.
I think we could make it a very difficult project for a technically sophisticated neighbor to spoof (or even read) packets, without breaking and entering to physically compromise the system. That's good enough.
Given the playback resistance and given a stream cipher, I'm leaning towards leaving most of the network header in plaintext, so that repeater nodes can quickly repeat them.
And I consider this low priority for myself. The low degree of damage a cracker could cause, combined with the low chances that a nearby neighbor has both the technical expertise and the incentive to crack my system put this type of attack way low among my security concerns. Stealing the bicycle in my back yard would be much easier and more painful than raising my blinds.
I'm very amateur at this, so I'd be glad to hear other approaches and ideas. The creative synergy is one of the payoffs of this for me.
So I see the security question as technically interesting but not pragmatically vital at this time.
-
@daulagari
Yes we are agreed.I am continuing to think about this. I think that what makes the most sense is a stream cipher which can encode 1..32 bytes, and which can include or exclude the network header. (Versus a block mode like plain AES in ECB mode, which can only encode 16 byte chunks). We could use some of the chaining modes to convert a block cipher to a stream cipher, or could just use a pure stream cipher.
We need something which has a small footprint, in code, RAM and time.
I'm currently leaning towards combined authentication, confidentiality, and playback resistance, even tho the middle aspect may not be critical. Having a large message digest isn't going to fit - the system also needs to minimize the data added to a packet.
I'm thinking of using a 32 bit incrementing counter appended to the end of a payload before encryption. The counter could be initialized to a random value at first and would increment with each new packet. When decrypting, the last 4 bytes would need to be in the range N+1 to N+m, where N was the last valid received counter and m is the window. If fewer than m packets are lost, we will resyncronize automatically with the next valid packet. There would be a way to transmit the shared key and initial counter value to a node, given physical access.
I think we could make it a very difficult project for a technically sophisticated neighbor to spoof (or even read) packets, without breaking and entering to physically compromise the system. That's good enough.
Given the playback resistance and given a stream cipher, I'm leaning towards leaving most of the network header in plaintext, so that repeater nodes can quickly repeat them.
And I consider this low priority for myself. The low degree of damage a cracker could cause, combined with the low chances that a nearby neighbor has both the technical expertise and the incentive to crack my system put this type of attack way low among my security concerns. Stealing the bicycle in my back yard would be much easier and more painful than raising my blinds.
I'm very amateur at this, so I'd be glad to hear other approaches and ideas. The creative synergy is one of the payoffs of this for me.
So I see the security question as technically interesting but not pragmatically vital at this time.
@Zeph said:
So I see the security question as technically interesting but not pragmatically vital at this time.
This is vital imho. We have to be pragmatic about this.
I see it like this:
I have camera's around the house. No alarm. Proper locks.
The 'recreational' burglar comes by the house, sees the camera's and moves on.
The 'amateur' burglar will think that it might be worth a shot. Next he sees the locks and he/she will split because it is too difficult and risky.
The 'professional' burglar will go in anyway, whatever I have installed. -
@Zeph said:
So I see the security question as technically interesting but not pragmatically vital at this time.
Yes, also I am more "scared" about other things than people accessing the mysensor network but I do not need remote controlled locks :smile: For me, thinking about it is good fun that can be hopefully helpful in the end.
I think that what makes the most sense is a stream cipher which can encode 1..32 bytes, and which can include or exclude the network header.
Based on streamciphers the ARCFOUR assembler implementation looks like a nice pick. The problem however for stream ciphers is:
- The starting state (seed) needs to be different for every packet sent
- The seed needs to be known by sender and receiver but must be secret for others
- Authenticity is not guaranteed, the message contents can be change without problems and that while authenticity seems to be more important than confidentiality
This makes me think that for a "good-enough" streamcipher too much additional components are needed like a hash to get ourselves a seed and additional code/data to improve authenticity.
I'm thinking of using a 32 bit incrementing counter appended to the end of a payload before encryption.
A counter is largely predictable and a generic problem with sensor data is already that it is highly predicable making a "known plaintext" attach easier. You need some kind of counter to prevent replay attacks but provided the counter is encrypted, the acceptance range (N+1 to N+m) is not too big how much would we really need?
Given the problem I see around a streamcipher implementation and a "known" plaintext I think the drawback/overkill of blockciphers that the block size is too big (64/128) byte might become handy so we can fill up thing with random padding.
Had a look at XTEA and think I like it because of size and performance. But I much better would like that there is some kind of version or cipher field (four bits?) that specifies which cipher is used so things can be mixed and upgraded.
-
@Zeph said:
So I see the security question as technically interesting but not pragmatically vital at this time.
Yes, also I am more "scared" about other things than people accessing the mysensor network but I do not need remote controlled locks :smile: For me, thinking about it is good fun that can be hopefully helpful in the end.
I think that what makes the most sense is a stream cipher which can encode 1..32 bytes, and which can include or exclude the network header.
Based on streamciphers the ARCFOUR assembler implementation looks like a nice pick. The problem however for stream ciphers is:
- The starting state (seed) needs to be different for every packet sent
- The seed needs to be known by sender and receiver but must be secret for others
- Authenticity is not guaranteed, the message contents can be change without problems and that while authenticity seems to be more important than confidentiality
This makes me think that for a "good-enough" streamcipher too much additional components are needed like a hash to get ourselves a seed and additional code/data to improve authenticity.
I'm thinking of using a 32 bit incrementing counter appended to the end of a payload before encryption.
A counter is largely predictable and a generic problem with sensor data is already that it is highly predicable making a "known plaintext" attach easier. You need some kind of counter to prevent replay attacks but provided the counter is encrypted, the acceptance range (N+1 to N+m) is not too big how much would we really need?
Given the problem I see around a streamcipher implementation and a "known" plaintext I think the drawback/overkill of blockciphers that the block size is too big (64/128) byte might become handy so we can fill up thing with random padding.
Had a look at XTEA and think I like it because of size and performance. But I much better would like that there is some kind of version or cipher field (four bits?) that specifies which cipher is used so things can be mixed and upgraded.
@daulagari Agree; I would always keep the option in to send both encrypted and unencrypted messages over the same network, e. g. By using a encryption - type value in the header. For development we would make it very difficult to analyze the (on air) messages when everything is always encrypted.
-
When I was (trying to) develop my own a'la library you've done very well, I was concerned about security of the protocol.
Currently (correct me if I'm wrong) everyone can sniff and send any values to gateway or nodes, which is pretty normal behavior (as it can be done i.e. with RF433MHz protocol devices).But have you ever thought about how it's possible to make whole thing more secure?
Pre-shared key?
I know the limitation is within the RF24 library, which should allow to put bigger messages thru...I do not know how much memory it would take, but why not use frequency hopping? Would make it an ass to intercept.. But I do not know how practical it is, I have zero experience with it.
-
why not use frequency hopping
The algorithm for the hopping will be open-source I hope if it is part of MySensors, so that is easy to crack unless the hopping sequence is scrambled by a key and then again you need some kind of crypto to do the scrambling...
-
@Zeph said:
So I see the security question as technically interesting but not pragmatically vital at this time.
Yes, also I am more "scared" about other things than people accessing the mysensor network but I do not need remote controlled locks :smile: For me, thinking about it is good fun that can be hopefully helpful in the end.
I think that what makes the most sense is a stream cipher which can encode 1..32 bytes, and which can include or exclude the network header.
Based on streamciphers the ARCFOUR assembler implementation looks like a nice pick. The problem however for stream ciphers is:
- The starting state (seed) needs to be different for every packet sent
- The seed needs to be known by sender and receiver but must be secret for others
- Authenticity is not guaranteed, the message contents can be change without problems and that while authenticity seems to be more important than confidentiality
This makes me think that for a "good-enough" streamcipher too much additional components are needed like a hash to get ourselves a seed and additional code/data to improve authenticity.
I'm thinking of using a 32 bit incrementing counter appended to the end of a payload before encryption.
A counter is largely predictable and a generic problem with sensor data is already that it is highly predicable making a "known plaintext" attach easier. You need some kind of counter to prevent replay attacks but provided the counter is encrypted, the acceptance range (N+1 to N+m) is not too big how much would we really need?
Given the problem I see around a streamcipher implementation and a "known" plaintext I think the drawback/overkill of blockciphers that the block size is too big (64/128) byte might become handy so we can fill up thing with random padding.
Had a look at XTEA and think I like it because of size and performance. But I much better would like that there is some kind of version or cipher field (four bits?) that specifies which cipher is used so things can be mixed and upgraded.
@daulagari said:
I'm thinking of using a 32 bit incrementing counter appended to the end of a payload before encryption.
A counter is largely predictable and a generic problem with sensor data is already that it is highly predicable making a "known plaintext" attach easier. You need some kind of counter to prevent replay attacks but provided the counter is encrypted, the acceptance range (N+1 to N+m) is not too big how much would we really need?I'm not sure if you wind up agreeing that an acceptance range of N+1 to N+m (out of 2^32) is sufficiently robust (for our purposes) or not.
I was suggesting that the 32 bit value be appended to the end of the payload, so it would not make for a predictable start. And "predictable" is relative - an attacker doesn't know where in the 32 bit space you started your counter, so it's a weak sort of initialization vector in addition to the cipher key per se. The more predictable contents of a packet is probably a larger weakness, if known (or almost known) plaintext attacks are the concern. However, I think that cracking a decent stream cipher under these circumstances is non-trivial. Somebody with that level of skill and determination would probably not waste it raising my blinds.
I started with the idea of a 4 byte random number and a 4 byte counter, but 8 bytes of overhead per packet seems like a poor tradeoff. So I thought of reducing each to 16 bits. Then I thought about allocating a varied number of bits to each. Then I thought - starting with a random 32 bit number and then incrementing it is a fairly reasonable compromise for a modest security system like this. I also considered using a PRN generator for the sequence instead of a counter, but if the encryption is decent, that would not help the security much, and it makes testing for validity much slower.
The first goal is to authenticate and prefent playback attacks; confidentiality is secondary. And this is not going to be used in banking.
Given the problem I see around a streamcipher implementation and a "known" plaintext I think the drawback/overkill of blockciphers that the block size is too big (64/128) byte might become handy so we can fill up thing with random padding.
We can pad, but the packet is only 32 bytes (1..2 or 1..4 blocks). If we wanted to leave the network headers in plaintext, then it gets worse; with AES, that leaves you with exactly one 16 byte payload - no room for two. I'm not liking that as well as a stream cipher, but it's a judgment call rather than a fact.
Had a look at XTEA and think I like it because of size and performance. But I much better would like that there is some kind of version or cipher field (four bits?) that specifies which cipher is used so things can be mixed and upgraded.
I'm not thrilled with needing to implement multiple ciphers in small machines; even one takes up signficant Flash and RAM.
Of course, you could say that all of a given network would use the same algorithm, in which case the "which cipher" code only confirms they are using the same one. But in that case, you could just silently choose the same algorithm for all your nodes, and that's just one more thing an attacker would need to discover. If they steal one of your nodes and read it - game over anyway.
Currently, I think just getting one encryption protocol and algorithm implemented is challenge enough.
-
@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.
-
The block sizes are not that bad!
XXTEA is 8 bytes (64 bits), which is where I got 1..4 blocks per nRF packet if it's all encrypted.
AES is 16 bytes (128 bits), which is where I got 1..2 blocks per nRF packet, same conditions.
However if the network headers are plaintext, you will only be able to fit one encrypted 16 byte AES block in the rest of the packet (can't shorten it for efficiency, can't fit a second block).
With an 8 byte encryption block and plaintext headers, you could fit 1..3 blocks of encrypted content (assuming the headers stay at or below 8 bytes), which is not as bad. Small packets waste less space, and you can use most of the 32 byte packet.
-
@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.
