Moteino RF security?

[designerx]

Hello All,

I've recently stumbled across LowPowerLab and Felix's cool products/projects (specifically GarageMote) while looking for an open source arduino or rPi garage door monitoring/control solution (versus a proprietary and undocumented solution like the Chamberlain MyQ Garage.) 

I understand the security measures in the Raspberry Pi gateway.. but am unfamiliar with RF security issues that may exist in the GarageMote project as currently implemented. So I have a couple of questions for the forum (thank you all in advance and I apologize if these are painfully noob-esque!)

As currently implemented can a "man in the middle" attack intercept the RF transmission and re-broadcast?  From a laymans perspective I would think a timestamp would need to exist to prevent this sort of attack.

Can someone get me started or point me in the right direction to learn/understand enough to create a secure Moteino RFM69 home automation network.

Thanks again!

Stan

[pavlos]

I doubt there is in Moteino any default protection against replay attacks (encryption will not protect against this, a message authentication code plus a unique sequence number per message is what is really required). The replay attack is also one of the easiest attacks to carry out  as it is easy for an attacker to buy one of these reply devices on ebay, record some signal, and replay it later on. Personally I think anything that can block the most basic replay attack devices is good enough as I expect that the next weapon in an attackers arsenal is a crowbar and not cryptanalysis. 

You proposal to include a timestamp in the message (essentially making each message unique) will probably work ok but it assumes that devices  are running an approximately  synced clock. Other approaches will assume some state be kept at least on the receiver to ensure that duplicate messages are discarded. If we wish to avoid maintaining state then  the only way I can think of is for the 2 communicating nodes to exchange some prior info:

1. node1 requests a unique id from node2. This unique id could even be a simple increment counter maintained by node2 .
2. node1 sends the message and includes the counter.

A more secure approach will be to use an HMAC of the message being send and the counter:

1. <as before>
2. node 1 creates an HMAC of the message being send plus the counter. This implies that node1 and node2 share some common secret word.


An HMAC requires a good quality crypto hash and it appears only SipHash is probably  efficient enough to run on moteino like devices. Nevertheless my opinion is even a standard non crypto hash (like crc16) is 'good enough' for this purpose. I have some code in python for both an efficient 16 bit hash and a resulting hmac implementation.  can share it /post it if it would be of any use to you.

Pavlos

[KanyonKris]

Another technique is rolling code, used in garage openers and car remotes. Replaying a previously sent and received message doesn't work because both sender and receiver have moved on to a new code (the receiver will reject old codes).

However rolling code will not protect against a man in the middle who is able to capture a transmitted message and block the receiver from hearing this message, in this case the receiver will accept the replayed message. Is this a practical attack worth worrying about? I'm not sure. The man in the middle could jam the receiver with a strong signal, say a highly directional antenna aimed at the receiver, then have another directional antenna aimed at the transmitter to capture the message. Entirely possible, but more work than just breaking in while you're away? Can HMAC defeat this type of attack?

Here's an Atmel app note on implementing a rolling code system - http://www.atmel.com/Images/Atmel-2600-AVR411-Secure-Rolling-Code-Algorithm-for-Wireless-Link_Application-Note.pdf

[LazyGlen]

I think the first question is: How secure does it need to be? You already have at least 1 level up in security by using a custom system over what came from Sears. I'm guessing that Felix hasn't shipped hundreds of thousands of Moteinos. Though I suppose HopeRF probably has of RFM69's. Just remember, you can go nuts securing a door, but a rock through a window is very effective. Depending on when and how your house is built, it may be simpler for a burgler to go through the wall. For 14 of every 16 inches the only thing between them and your stuff is drywall, fiberglass insulation, 1/2 inch plywood (if you are lucky, I have Cellotex - think soft cardboard!) and siding.

Encryption gets you secure comms, but as you point out, simply playing back the signal makes "IT" happen, whatever "IT" may be, without knowing what the signal contains. So make it a call and response system, with complexity increasing until you feel comfortable.

Logging every request to open would be a good start, limiting range and usage will also help. When you check the logs and find that the door has received multiple requests at an unusual time, THEN you can get paranoid. Here's some thoughts to get you started.

Load each end with a matched set of passwords, 0-? and A-?.
Request To Open - RTO.
CHALenge - CHAL
RESPonse - RESP

CHAL	RESP
0	A
1	B
2	C
3	D
4	E
5	F
6	G

In levels of security, I can see this:

• Remote sends RTO, Door replies with a random CHAL, Remote replies with matched RESP.  ie - RTO, 3, D, open
• Shift correct response based on some variable (Month, day of week, current hour, 24 hour time of day...). So on Monday the correct response to CHAL=0 would be RESP=A, Tuesday that fails because the correct sequence is CHAL=0 RESP=B.
• Shift correct response based on 2 of the above variables.

Load the same passage of text into FLASH on both the Remote and the Door. Remote issues RTO, Door replies with CHAL=random_number, correct RESP uses CHAL as an index into the text passage and returns some number of bytes. (Either fixed or variable. Correct text fails if it is the wrong number of bytes for the current rules.)
OR the correct RESP adds the current (date, month, day of year) to the CHAL and returns THAT piece of text.

Now every 'conversation' between the Remote and Door is unique, and replaying a single transmission will not open the door.
The above all assumes a static RTO command. You can add another level of complexity by changing the RTO based on similar rules, so the Door wont even issue a CHAL unless a valid RTO has been received.

[pavlos]

Indeed, as mentioned earlier I think for home security purposes the crowbar is next in an attackers arsenal and not cryptanalysis. I would consider protection against straightforward replay attacks the minimal level of security required and from there on things can get as secure (complex) as required. A rolling code will work (but will require keeping some state in multiple devices) or a challenge/response approach should suffice for the the most basic replay attacks.

[Felix]

Replay can be an issue, perhaps if you have an RF expert neighbor who will fire his analyzer to sniff the neighborhood and think your RF traffic has interesting patterns.
A simple idea would be to use a real time clock of sorts ... that would render replays useless. This is much the same as a rolling code.
I have thought about this problem but for now I am not that worried
I know this is not a satisfactory answer but really ... if someone wants to open your garage I'm sure they will first buy some kind of garage door remote that does some kind of RF dictionary attack of sorts before they will ride with an RF analyzer to sniff for door opening sequences... that's my 2 cents.

[pavlos]

Unfortunately one does not need these kind of gear these days. We had an incident where I live (a block of 12 flats) where a burglar apparently used some device that just records the rf traffic and plays it back later. So they sit in a car close by and when they note someone trying to open a door or a car they start recording. I presume these 'recording devices' probably target well known frequencies and well known modulation methods but I have no clue to be honest. In any case it is good to know that one can add some basic protection (as a first step any method that results in unique messages will do) without too much effort

[Lukapple]

You can solve this by implementing security using (Time-based)One-time Password Algorithm (TOTP / OTP).