Comments: Secure DIY Garage Door Opener
Looking for answers to technical questions?
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
If you've found an issue with this tutorial content, please send us your feedback!
What a great project! What would it take to add a second remote to this system? Is it even possible?
Hi #279, Thanks and yes, it is definitely possible to add multiple remotes. What you need is to learn the public key of the second remote and add it into your code on the base.
The base would then need to check each signature against both public keys. If either one of them verifies properly, then open the garage.
I'm planning to add a second remote to my personal system in the next few weeks, so when I do I will definitely post my code as a branch on the main repo.
Thanks again and if you end up setting up a system, please let us know how it goes. Cheers strong security! -Pete
Putting aside the fact that this is an example, it's interesting to analyze the security and the inherent flaws in the implementation.
The most basic attack here is the ability to force the base to persist the token after capturing a successful negotiation.
The other interesting attack is jamming the base and presenting Alice with a null byte token.
Hey #437, It seems you are the cat and I am the mouse, but I intend to scurry away to live another day :)
Ah darn, you got me!! Your first idea is brilliant! I knew I could count on someone finding the weaknesses in my code. My original intent was to invalidate the token after a set amount of time (no matter what), but your idea to keep sending new invalid signatures is good. I will have to have some sort of time-out that is started with the "$$$" ping, and then will time out regardless of any other attempted signatures.... not sure how to implement that just yet, but I'll start working on it!
And your second idea is much like the roll-jam attack I found during my original research. I see how it is modified to trick Alice and impersonate the base. Again, brilliant! It might take me a minute, but I'm hoping there is some sort of solution to protect against this too. I'm still having trouble seeing how a null token would work, because the token is always created by the base, and it would never create a null token... so... ah geese... I get it now. I change the token to all "0x00"s when I timeout.... ya got me!!
And so like the monster at the end of this book, I Grover, say, "I'm so embarrassed".
Thanks again and expect my scurry soon!
This is a cool example and a great use of the ATECC508A.
The two scenarios above can be tackled pretty easily with a state flag.
Spend your time instead working out a remote enrollment mechanism... maybe a programming button on the base :)
Hey #437, Wow, thanks for the solution! I implemented your changes and it seems to be working. I tested invalid signatures and a timeout, and from my new debug messages, it seems to be invalidating the token properly. Take a look if ya like:
https://github.com/sparkfun/Secure-DIY-garage-door-opener/commit/e19509cee69296978c383394dcaeeef328c94f20
Also, I know that it's not necessary (now with the tokenStatus), but I went ahead and changed up how I "destroy" the valid token. Now I am more like "scrambling" the token, by just refreshing it with a new random value (created by the bases co-processor). I preferred this method over the previous null approach, because it's no longer exposed in the source code.
Also, I was thinking it might be another good precaution to have Bob sign every message, and then Alice could verify against his public key. This way, no one could impersonate Bob and get something signed by Alice. Again, I know it's not necessary with the current fix, but, who knows, maybe it would be a weakness that could lead to another creative hack. And it only costs about 100 ms per cycle :)
I do like your enrollment button idea. This is where I will spend some time next. I was thinking that Alice could send her public key along with every message, and Bob would only use it (and store it in EEPROM for future use) if his enroll button is pressed. Does this sound like a valid approach?
Thanks again!!
First, I think this project is a really good exercise in using cryptography, but IMHO, it's vast overkill for most folks. If you're truly worried about the security of your home, remember that the vast majority of people who are going to try to break in (a) don't give a damn about whether it's obvious that they've done so (and so will use physical force to gain entry) and (b) don't have the wherewithall, eiither financially or mentally, to defeat the security of the typical garage door opener. (Here in the Phoenix area, there have been multiple recent reports of garage roberies by someone using a large tool to break off the "emergency entry" key-locked handle, and using that to open the door.)
Second, my understanding of how the "wall button" works is that the ceiling unit provides a (DC) current through the two wires. The LED is across this and lights to give the user "warm fuzzies" that the power is on (and also helps locate the button in darkness). In a single button scenario the switch shorts out the LED and limiting resistor, which the ceiling unit detects, and operates the door. Additional buttons use series resistors to signal their closure. Note that this allows use of the single button remote, or a fancier multibutton remote, with no changes to the ceiling unit.
Third, I'd be inclined to use a higher number of daily operations. Also, I'd be inclined to have an LED on the remote to give "warm fuzzies" that something is happening when the button is pushed, and absence of it lighting up could indicate "low battery". Also, a more "user friendly" idea would be a provision to charge the battery without disassembly of the remote.
Fourth, I think you should think about having provision for two (or more) remotes. Think of a two-car garage with only one door opener -- car 1 leaves for work, uses remote 1 to close door. Driver 2 uses wall button to open door, backs car out, uses remote 2 to close door. (This is why the openers come with the ability to support multiple remotes.)
Fifth, if you are worried about security and install this, be sure to disable the opener's built-in remote. (For at least some, clipping off the antenna wire is probably sufficient.)
Hey 773! Thank you for your comment!! All good things for sure. I definitely agree with all your points.
The author of the articles I linked to in the intro has another great one on security, and I think it's worth a read for everyone:
https://www.garageautomatics.com/secure-your-garage/
I definitely need to look at things like my window and old back door (with old loose fitting door knob).
"warm fuzzies" haha. I can relate to that. The blinking LED is what started it all for me. I love your idea to indicate low battery. I hope I don't see that LED come on for 6 years though :)
And thanks for your explanation of the wall button circuit. That seems to make sense!
I was thinking about doing a smash-up of the boards in a smaller board for my second remote. Might even try to re-use the old remotes enclosure. This seems like a perfect use case of the new Eagle "design block" feature.
https://www.autodesk.com/products/eagle/blog/whats-new-in-autodesk-eagle-modular-design-blocks/
Thanks again and happy new year!
Cool project! Two questions:
First, your Power Considerations page shows that you measured current over ~4.2 seconds (42 readings each covering 100ms). Is that right? Seems like a really long time to send a few messages back and forth.
Secondly, would you need to hold the momentary switch down for pretty much that full ~4 seconds (plus the 1-2 seconds for the arduino to boot)?