In my spare time, I’ve been working on a Raspberry Pi garage door opener project.
The main goal is the ability to open or close my garage door from my iPhone or CarPlay. Unlike the existing projects I’ve seen, my solution has a rotary encoder on each door in addition to a door closed switch. The rotary encoders allow me to see if the door is moving, and hence close or open the door with a single button press. i.e. instead of a direction-ignorant ‘Activate’ button, I can have separate ‘Open’ and ‘Close’ buttons that will do the right thing, even if the door initially moves in the wrong direction. And I can handle two doors with one Raspberry Pi. I could handle more, but I only need it to handle two doors.
Unlike some of the commercial solutions, my solution does not require cloud services. It will still work when my Internet connection is down. If I’m in WiFi range with my phone, I can open and close my garage doors. If my Internet connection is up, I’ll be able to do the same from anywhere in the world.
It is more secure than the average IoT solution. The authentication protocol uses 2048-bit RSA as the base encryption, over which I send an AES256-encrypted randomly generated challenge. The client must decrypt the challenge using their private RSA key, then decrypt the AES256-encrypted challenge with the shared secret key, then encrypt with my server’s public key and send the challenge response. Post-authentication, the session uses AES256. Sessions will typically be short-lived, and we never exchange any secrets. The server will automatically generate a new 2048-bit RSA key each week, which should eliminate the ability of anyone being able to crack the public key crypto and use it in my lifetime (I don’t see a usable quantum computer on the horizon, and the NSA would just break my door down instead of cracking my garage door opener).
I’m nearly done with the server side that runs on the Raspberry Pi. I’m running FreeBSD 11 on the Raspberry Pi, and my server is multithreaded in order to be able to monitor all of the sensors and be responsive to clients at the same time. It is written in modern C++ since that’s been my server language of choice for… 18 years? All unit tests are done for the code that is completed, and I have tested the server with a simple client. I have also tested the sensor inputs, but I’ve yet to send out my piggyback I/O board design for manufacturing. The industrial rotary encoders will arrive soon, so I’ll probably order my PCBs sometime in the next few weeks.
In order to make the iOS side of things easier, client/server messages are encapsulated in JSON. Since I’m using jsoncpp on the server side, it’s trivial for me to write a Qt app for the desktop and a Wt app for my web server if desired since I’d just use jsoncopp in these cases.
Crypto is still ugly to do with Swift, but I’ll manage. I’m going to try to keep my Objective-C and other non-Swift code to a minimum on the iOS side of things.
I intend to allow configuration from a client. The server code to support this is not complete, but the protocol work is in place.
Probably worth noting that I created a separate libDwmAuth project so I can reuse the authentication and encryption in other IoT projects. No cloud needed, no clear text flying around my wired or wireless networks.