Wifi Door Unlocker

My aunt is a lock smith and during a recent family get together for a graduation, she brought some lock picking sets. She gave me a few pointers and within a few minutes, I had picked my first lock. Mushroom pins are still a struggle sometimes but I'm getting better. When I got back to Seattle, I was excited about trying it out on my door. I was able to get it open in less than 2 minutes. This concerns me to say the least. We have a regular lock as well as a deadbolt which is only lockable from the inside. The downside would if the mechanism were to fail, we would be really locked outside. The new ESP32 looks like it might have the guts to be performant in promicious mode.

So having decided to move away from more of a raspberry pi type solution I think it might be best to move to a router based solution. The router knows who is connected or not, no need to packet sniff. I just need to modify a router to send a packet to another wifi connected device when a phone connects to the wifi. I'm thinking open-wrt. Any thoughts?

So I've been working a little bit more on the problem of the USB wifi chip dropping packets particular when there is a large amount of traffic going through the air (such as when someone is streaming Netflix, which happens more than you'd think). Even when there isn't a whole lot of network traffic, it's easy to miss a packet. Obviously if this is going to replace my need to carry keys then this can't not work. If it drops the authentication packet, then there is no way to send a new one unless I turn off the wifi on my phone off and on. The idea is that I can just walk up to the door and it's open.

I've thought about a few other options such as a FPGA solution that analyzes the packets but it would have to do so at a fairly high level. In order to get a decent sample, the sampling rate would be 4.8 GHZ which I don't think would be possible in an cheap FPGA and would likely require serious cooling in an expensive high end one.

I've given it some thought and decided that the bluetooth low energy spec is actually pretty decent and since all of us have phones that support it, it does make a good choice. The only problems I've thought of is authentication. I think the idea would be that the micro controller would just sense when a phone came in range so it would unlock the door. It would likely do this through MAC address authentication. While I live in a wonderful community that is very crime free, the security of this isn't as robust as I would like. All it would take is someone to sniff out the bluetooth mac address of one of our phones and then spoof it. Of course, if someone was putting this much effort to get in our house, they might as well just break the large and very thin front window of the apartment.

The other problem with this approach is the reduction of novelty. Without wifi, it simply becomes another bluetooth doorknob like everyone else. At what point is it simply more convenient to just buy one for a hundred bucks?

Any thoughts or suggestions?

Sorry for not updating for a while since I got really busy and [standard excuses]. Anyway- I have moved so I need to revise my overall design and instead of actuating the door knob it would make more sense to have it actuate the deadbolt in this particular setup for my new apartment.

I've done some more testing and found that intense network traffic can overwhelm the cheap-o wifi dongle and it will start dropping packets (for example, a roommate watching netflix on the couch will just overwhelm it and it will completely miss most/any authentication packets). 

So here is what I am thinking now- create a aluminum foil overlay that goes over the back so the exposed part of the  antenna facing the door. If I'm correct this should help block out traffic from inside the apartment (since there tends to be a lot of it). That way, in theory, the only the traffic that gets sniffed is directly from the phones outside the door rather than inside the door.

I also picked up a small motion detector from amazon for a few bucks. It's fully digital so just provide it voltage and ground and it's a simple high and low on the output pin- which means it can be attached to an interrupt! I'm going to assume that you know what interrupts are but if you don't know- here's a good resource to learn more.

I did some short experimentation with the sensor and an Arduino and found it worked quite well. The idea is to use the motion sensor to turn on and off the polling of the knock sensor and maybe sleep and wake the raspberry pi for power/heat reason (I've noticed the pi tends to get a tad warm). But I'll see if it's really neccesarry in the end.

Now that things have calmed down and I'm not on vacation or moving I can start working on it again.

So, I figured out what was happening last time. It turns out when you start a monitor interface from the wlan0 it defaults to channel 1. So, you have to start it with

sudo airmon-ng start wlan0 4 

Oh course, replacing the four with whatever channel your access point is on (most wifi points are on auto so it might be wise to set it on a specific channel). 

Anyway, so I found the right command to use which is 

sudo tcpdump -i mon1 -elnq "type mgt subtype auth and wlan host 00:11:22:33:44:55" |sed s/^/\\a/

Oh course once again replacing the mac address with the mac address of the device you want to filter on. The line will output a success at the end which is important to check for as if someone were to use a mac spoofer and try to authenticate then they could get in if we didn't check if the authentication wasn't successful. 

I have some python code to run this in the background- it's in the github repo. I didn't include the settings file that includes the MAC address for my phone. Not a huge security problem, but you can never be too careful. 

I ordered a new part. A little sensor-  HC-SR501 Human Sensor Module Pyroelectric Infrared to detect if someone is at the door. It's got it's own control circuit and can be easily attached to an interrupt.

So using this nice hackaday post I started doing some packet sniffing and I got it working. Sort of.

tcpdump -i mon0 -elnq "type mgt and wlan host 00:11:22:33:44:55" | sed s/^/\\a/

This actually stopped working and I don't entirely know why. I'm just going to have to dive into the 801.11 protocol and see what I can find.

As near as I can tell this puts out the management packets from that particular mac address and then puts them through sed where it appends a beep to the terminal. The key is to figure out how to route this through my python program or how to do it an efficient manner (that pi gets pretty hot when running).

I've looked into pcap and just coding my own solution but then I get away from some of the nice features of python. So that's where I am at.

So I got the wifi card, complete with antenna and have started working on it. It went into monitor mode like a charm.

sudo ifplugd -S -i wlan0
sudo ifconfig wlan0 down
sudo iwconfig wlan0 mode Monitor

Next, I installed the aircrack-ng suite, which wasn't too bad. This website was a big help.

Now to start sniffing some authentication packets!

Threw together some quick models in sketchup. Not really accurate right now but just an illustration of what I'm thinking.

So after doing preliminary testing, I determined that my initial method of nmap the network every second took much too long and was very unreliable. That's because when phones go to sleep sometimes they respond and sometimes they do. It would appear to the PI that phones would be dropping in and out of the network. So back to the drawing board. Then I learned about monitor mode.

A bright ray of hope briefly shone there that day in that humble apartment. It was immediately crushed as the $5 wifi USB card was largely incapable of monitor mode. After a few hours on stack exchange, the solution presented itself in traditional consumerist fashion: buy a new one.

So that's what I'm waiting for. USPS has notified that it has been delievered. So the next step is to set up a github and start taking pictures.