Security
-
@hek This was this one on : battery usage , I don't know if with custom duino they solve this ?
-
Normal Pro Mini boards was discussed. The optimizations is described in the Battery Powering section on the documentation site.
-
@hek Yes I saw it, I just wondered if he applied this to his motuino ? nothing is said on this... I just wondered... off topic, is there a possibility to have three batteries and have a regulation pushing to 3.3V in to have greater sensor life ?
-
One way to off-load the microcontroller would be to use an off-chip security solution. Atmel actually offers something like this.
I have used a similar device when I worked on an Apple accessory. Apple uses a challenge-response mechanism using an authentication chip to identify genuine devices in order to unlock certain aspects of the protocol API to iOS (reading contacts, etc). That device used I2C and I managed to integrate it with a PIC12, so it can be done with minimum HW resources.
I have not looked deeper into how the AES chips actually work (with respect to key management, etc), but I would imagine it could be an adequate tool for the job.If I get the time, I'll look deeper into this.
-
@hek
Speed - according this http://forum.arduino.cc/index.php/topic,88890.0.html atmegas are capable of performing AES 128bit encryption in under 1 ms, seems promising at first glance
Message length - I suspect the simplest way is to make them 16 bytes
Protection against replay attacks - I think using nonces and checking message integrity with some kind of crc could do the trick
Key exchange - wouldn't pre-shared key solve this issue?Also I'm not sure if encryption is really a must for this project. As far as I understand the most important thing is to prevent unauthorised control, and for this kind for things there are lots of MAC algorightms which are much less resource hungry than AES. Any opinions?
-
In another thread it was mentioned that the JeeNode (which uses the RF12b or RF69) already offers XXTEA encryption of on-air packets using an ATMega328p. So it's definitely do-able within our resources, and XX-TEA is probably sufficient - who's going to spend the resources to crack that just to turn on some lights?
There are a lot of protocol questions tho, and the answer depends on your imagined scenario - what are you protecting against, how much incentive is there for an attacker, how serious is your exposure if they get through, etc. There is no one-size-fits-all security design; instead you design it to fit certain scenarios and not others.
So let's start by accumulating a list of "attack scenarios", then deciding which ones we want to thwart, and design from there.
Scenario 1: A major terrorist is using MySensors in their home automation, and the Mission Impossible team asks the NSA to crack the system so they can turn off his/her hot tub pumps at a given time to get the target to enter the fuse box room at exactly 7:02 while an agent slips a note to the luscious companion waiting it the hot tub.
Low priority. Not low hanging fruit.
but more seriously
Accidental interference with bogus packets (from noise or other devices) being received as legitimate, as happens with 433 MHz devices. The use of 127 channels at 3 speeds with 5 byte addresses and 2 byte hardware CRC makes this unlikely.
Accidental jamming - change channels.
Deliberate jamming, Not much we can do on the protocol level to avoid denial of service attacks. Let's skip that.
A neighbor uses MySensors and they accidnetally discover they can monitor your packets. (Not likely to mean much unless they are using MySensors). Change addresses or channels.
A neighbor not using MySensors wants to monitor your packets; they can program nRF chips to do so. They will have to do some reverse engineering to figure out what the contents mean (if unfamiliar with MySensors). Is this a problem?
A technically sophisticated neighbor wants to control your actuators: turn on your lights, open your blinds, etc They scan to find your channel and speed, they use SDR or other tricks to discover your address, and then they can then monitor all your packets. They know or find MySensors on the web and decipher the packets. They then monitor and discover the packet which opens your blinds in the morning, and can resend that packet at a time of their choosing. Is this the key attack we want the design to block?
What are some others? What do we need the design to handle?
-
@Zeph: I think indeed that your "technically sophisticated neighbor" scenario is what first comes to mind.
That matches @xop:
most important thing is to prevent unauthorized control
But adding only a MAC and nonce (authentication only) means adding payload.
To limit the amount of additional data to be send over, I think adding nonce/sequence number and encryption with a shared key is a better idea.
-
@daulagari said:
But adding only a MAC and nonce (authentication only) means adding payload.
To limit the amount of additional data to be send over, I think adding nonce/sequence number and encryption with a shared key is a better idea.I think it's important to evaluate how much payload will add MAC, because in case of encryption (at least AES) you'll have to round your encrypted payload size to 16 bytes minimum, as far as I understand, and you'll need to add the very same nonce and some kind of crc into message to add randomness and integrity check.
Considering XXTEA - it seems even slower than AES, according to this: http://www.ei.ruhr-uni-bochum.de/media/crypto/veroeffentlichungen/2011/01/29/lw_speed2007.pdf
-
@xop said:
Considering XXTEA - it seems even slower than AES, according to this: http://www.ei.ruhr-uni-bochum.de/media/crypto/veroeffentlichungen/2011/01/29/lw_speed2007.pdf
Good find. In his implementation AES was substantially faster (at three times the code size) than the related TEA and XTEA.
Another source suggests that XXTEA may be somewhat more efficient than TEA/XTEA as size increases, but I doubt it overcomes the speed advantage of AES.
So within the bounds of that paper, the advantage of XXTEA would be 8 byte vs 16 byte blocks, and smaller code; but AES is faster.
Another concern is RAM footprint. I think I saw that XXTEA used substantially less RAM than AES on the AVR, but I'll need to look that up again.
-
Using block mode AES with 16 byte blocks means either being limited to a single encrypted block (with room for unencrypted network headers), or using two blocks with the entire payload encrypted.
How large are typical MySensors payloads?
Could we use Cipher Feedback or Output Feedback modes to get more flexibility in the size of encrypted payload?
-
Getting more concrete, it sounds like there are two approaches to authentication currently in the air.
-
Add a MAC + nonce to a plaintext MySensors command sent to a critical actuator.
-
Add a nonce + checksum to an encrypted command sent to a a critical actuator.
In the latter case there's another issue of whether the network headers are encrypted or plaintext (does a repeating node need to decrypt to know where to forward a message?)
For (1) what kind of MAC (message authentication code) would you suggest? A long but secure hash would be too much for our tiny messages.
For (2) let's consider sending a 32 bit sequence + a 32 bit CRC of the payload + sequence. The sequence is your nonce. If after decrypting the CRC matches, then you decrypted right. If the sequence is within N future iterations of the last successful one, accept it (to handle N-1 lost packets). Iterate the sequence (which could be an incrementing integer or a PNG or whatever).
The CRC could be replaced with a fixed value - if it's correct in the decrypted message, all is OK.
That's 8 bytes. A lot. How about shortening one of those values to 2 or 3 bytes?
Or how about considering that successfully decrypting the sequence (to within a range) is sufficient evidence of using the correct decryption key AND of not being a replay.
A very simple approach: Add a 32 bit incrementing number to the end of the payload (including or not including the network header), then use a stream cypher (perhaps AES in one of the modes suggested in my previous msg) to encrypt the payload + sequence. The sender always increments the number, the receiver only accepts a message if it's within 64 counts of the last successful receive.
-
-
@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.
-
@daulagari said:
Only things still need is a spectrum analyzer for the 2.4 GHz in max hold mode and you know the channel.
Can also easily be done using a regular nRF24L01+... I'm thinking of integrating it in the sniffer!
-
@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.
-
@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
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.
-
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...
-
@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.
-
@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.
-
@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
-
@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.
-
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.
-
Ahh.. yes. Now I'm following. Would probably make sense to move the "last" field first in header then to simplify authentication caclulation then.
-
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!
-
@Zeph Damn you!
now I orderd 2 nRF51822 also 
thanks for the heads up
-
I received a nrf8001 BLE development kit from Nordic a week ago. Thought I should play a bit with the BLE part for presence sensing agains my phone (once the new site and 1.4 is launched).
-
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 and:
It adds about 1200 bytes to the code size and uses about 42 bytes of RAM.
-
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.
-
See also the rest of this thread, just a message digest is very likely not the best solution.
Of course not by itself... the idea was to use it to implement some kind of HMAC and combine it with a stream cipher or a vernam cipher.
-
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.
-
@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.
-
I agree on pretty much everything you say, with the additional comment that if we extend the scope of MySensors to beyond the "Garage home-automation enthusiast" some form of commercially acceptable infrastructure, security support is essential. And if we ignore the technical solution to said security support, I believe the first thing to decide is how (not if) to handle multiple packages in a good way.
If the capability of extending the protocol to include several frames in a "message" is in place, the security back-end can be selected more freely, thus also allowing it to be more back-wards compatible, like "optional" signatures and such. It would also allow higher-order encryption, should one prefer that.
I am all for the SHA204-chip so no matter what, I am going to try that out eventually since I think it is such a nice chip, but it might be that I am putting it on hold until the MySensors back-end supports juggling larger datablocks.
The advantage of deciding on signing format (or encryption) early on will enable the protocol to be prepared for this at a relatively early stage, which is nice, because then these features can be enabled "later" without having to roll the entire communications infrastructure, which will be less and less popular, the more mature the system gets. And "large" packet support I think is a cornerstone in this. But that I think is subject for a different topic than "security" per se
-
I have received my authentication HW now and am going to start developing some support for it.
I am going for this approach.I am using Atmels ATSHA204A and I have also ordered a ATAES132 for encryption (but I am not sure I am going to make use of it, I see little benefit of encryption).
-
I found the project very interesting but I am a bit concerned about the responses on the security topic. Responses like, nobody will find out, which is the probability that somebody? who will want to...
I remember the same thing when 802.11 Wifi protocol entered the computing arena and I remember too how the Wardriving fenomenon exploded.
The adventage of mysensors (its easy setup) it is also a drawback from security point of view. In not so many time, I am sure that some "mobile" gateways/controllers will appear, maybe built over raspberry pis that will allow you patrolling cities with your car, searching or scanning for sensors to control.
I started some years ago exploring the Software Defined Radio world and you may be amazed on the quantity o fthings being hacked, you only have to google that. The tink about this is that the effort in resarch you have to do is totatlly null. You only have to google a bit and you find a project on github (like RTL_433) and a usb dongle for 10$ which allows you to sniff the sensors of nearby oregon devices (no knowledge is needed).
There are other works which show how to open cars, or garage doors, and despite there is not a lot of people investigating, there is a lot of work you can download and use. As a matter of fact, Kali linux (a penetration testing linux distribution) is incorporating these tools in its tool arsenal as being more popular amongst hackers/pentesters.
When somebody says that it will be dificult to retro-enginer the protocols, well... Lets look at the following links (and take into account this people is giving to anyone the software they are implementing):
- http://www.windytan.com/2013/11/broadcast-messages-on-darc-side.html
- http://www.windytan.com/2014/02/mystery-signal-from-helicopter.html
- http://hackaday.com/2013/03/14/stealing-cars-and-ringing-doorbells-with-radio/
- http://hackaday.com/2014/12/11/over-engineering-ding-dong-ditch/
- http://www.tomsguide.com/us/wireless-hacking-sdr,news-19308.html
I am agree that the project shall focus on functionality at first, it is good to start having things working first, but for me, is not acceptable having security in the project roadmap and in the top level architecture. Future fields in the messages have to be taken into account, first ideas of arduino variants with a hardware encryption engine have to be taken into account.
I was already making some projects at home with arduino and NRF24L01+ and I found mysensors quite interesting. First thing I thouught was that I would be able to escalate the number of sensors/actuators very fast with the provided infrastrutcure. However, I will not use it at the moment, because escalating the number of sensors and actuators in my house using that stuff, will also increase the severity of the consecuences if somebody palys with it.
-
Could the personalization sketch output the keys in a c-form which can be added directly in MyConfig.h?
So.. If key-code is defined in MyConfig it will be written to ATSHA204A at startup. Hope I'm clear enough?
-
@hek
Not sure I follow. The key is permanently stored in the device. It is not supposed to change ever once written. If zones are locked, it will also not be possible to change. The personalization is a one-shot operation. Why would you like to write the key on every start?
Sure I could update the personalization sketch to emit the auto-generated key in C-syntax form for easy copy+paste, but there is no requirement that the key is generated by the device. You could use "My secret key" as key if you wanted to.
-
Ok. Understand.
-
Perhaps I should post an update on my signing development here.
I have implemented a unique nonce-based signature mechanism using ATSHA204 in the protocol.
I did have to make a sacrifice due to the size limitation of a RF message so the signatures will be truncated. However, analysis show that even truncated HMAC-SHA256 are extreamly difficult to beat, so we should be pretty well covered.Architecturally, the signing driver will be a "plug in". A dummy signing driver is enabled by default, and signing is only done if requested. I will post detailed descriptions and guides once I manage to optimize the SHA204 library and signing implementation down to fit together with an ethernet GW sketch in a Nano (which I think is the most "crowded" usecase).
The design will allow for other signing backends to be used instead of ATSHA204, but as that is the only HW I got that is the backend I am implementing support for.
-
I'm very interested in this topic. Looking forward for the final conclusion.
Thanks.
-
@marcusvdt I believe the conclusion is here
-
working with security on a daily basis I just wanted to point out.... if they want to get it they will....
I sincerely hope the new additions to the security don't slow down the sensor network.
if someone wanted to make sure no one was listening into a radio broadcast.... I would personally go wired...... I see the security issue for this type of network is at best an authentication problem nothing more.
I love the addition of the authentication as a basic security measure and it just adds to the fine work you are doing.
-
@freerpg i also work with security on a daily basis and I share your opinion on the matter totally. Hence my decision to leave encryption out of it and focus on authenticity.
-
@Anticimex How far are you with authenticity verification?
-
@Avamander what do you mean? I consider myself done with security implementation. I don't see a need for more security functionality now when we have both encryption for rf24 and rf69 as well as hmac authentication and white listing.
-
@Anticimex I am not familiar with MySensors so sorry for the questions, who are the "we" you are speaking of having the features? Is this something MySensors now supports?
-
@Avamander "MySensors" has had support for this for quite some time yes. As you can read in the topic post of this thread. Encryption is discussed elsewhere on the forum.
