I know this is uncharitable, but after reading your post, I immediately envisaged a future where locks are web controlled, and the security of people's front doors relies on a shiny Web 2.0 site not having an XSS or CSRF somewhere. Uh oh.
That said, I would be really interested to see a shot at something new in this area.
Most of the current companies follow the OEM -> reseller model. Their customer is actually building and access maintenance companies, not the end user.
I'm not in favor of it, but it's worth noting that the lock on all of our front doors right now is not terribly hard to pick. When the SWAT team wants in, they dispense with the lock altogether by just battering through the door. I suppose if that wasn't fast enough for you, you could blast your way in. The lock-picking technique would not work on correct code--but producing proven correct code is very expensive and unpleasant, so not likely to happen. And you'd still be susceptible to the other two options.
My point is that security is not primarily a technical problem--or at least, there isn't a 100% technical solution, and probably never will be. In practice we benefit a lot from looking innocuous and having neighbors that know us and like us. The main thing keeping people out of your home isn't the lock, it's the inconvenience and unpleasantness of what would most likely happen if they were caught.
I completely agree with you; especially in terms of "security" being a social construct.
However, if it's possible to anonymously unlock a door using the Internet, that that door will most definitely be unlocked once a few people catch on. If such a problem were widespread enough, people would write software to scan the Internet, unlock doors and post the GPS co-ordinates to a twitter feed. This is a direct and unfortunate corollary of the "Greater Internet Fuckwad Theory". A small subset of people would go around "doordriving", or "dooring". Now the idea is stuck in my head.
You're right that correct code can't be "picked" per se - but it's not just about correct code. It's easy to underestimate the number of moving parts required in real world electronic access control systems and how they interact with the computing and physical environments they're installed in. The full system includes the manufacturer, their networks / personnel / procedures, the building, network cabling, management station, the management network, management policies and procedures, peripheral controllers, peripheral bus, peripheral electronics, the physical doodads and mechanisms, the "card to reader" interface and finally the cards themselves.
I personally find the threats against current electronic locking deployments to be pretty interesting. I'm by no means an expert or anything but I had to learn a little bit about it for my job. I'm going to deliberately ignore the SWAT method of e.g. attacking the doorframe if the lock is too hard ;) Or the ceiling and floor tiles, or asking nicely for the key, or dressing up as a fire inspector and asking for the key, or setting off a fire alarm and so on etc. Also, I'm going to focus on the systems I know a bit about, which are corporate office building systems (not e.g. hotels, which are different, or high security systems).
Consider e.g. a standard HID based access control system. You have an awful VB/MS-JET (last time I used it :) card / zone / user / rule GUI on the management station. That thing needs to be secured - and you would be surprised in practice how many organisations put the management station straight on their internal network, as a domain member server even. Multi-tenanted buildings tend to have better security on the management computers -- since they're air-gapped from any of the tenant corporate networks ;) They usually live in a maintenance room (locked by a conventional lock, for obvious reasons) down near the ground floor. In the multi-tenant case the management station will often have a modem plus PC anywhere installed.
If you can log on to the management computer (e.g. by compromising the domain or dialling in to it if it's standalone), the access management system itself asks for a password. You can pull the usernames directly from the underlying access database. You don't normally need to crack passwords. What you do to gain access is choose the name of the installer company as the login, and use that for the password too ;) IAPT (I am a pentester), and so far it's worked every time. Finding building access control management stations is filed in my notes under sections "fun post exploitation activities" and "amusing screenshot fodder".
But going down a level: In practice there is a lot more code running in these systems which I haven't personally looked at in depth. The fittings (e.g. door opener thingy, access card reader widget) are "dumb", and they communicate to peripheral controllers. As I understand it, the management station downloads the various settings and rules and card IDs into the peripheral controller, so that everything still works when if the management computer is down. As I understand it, this communication is plaintext (the name of the bus protocol escapes me right now). If you gain access to any of that wiring (host -> peripheral controller or peripheral controller -> peripheral) it's game over. However there's another possibility I've never seen anyone mention, which is that (I suppose) you might be able to van eck the comms over that bus too.
I think it is a setting you can choose (a hardware option on the fittings?) for whether you want things to fail open or closed in the event that the power goes out.
Going down another level, the "dumb" peripherals really do have code running on them -- they're just "dumb" in the same way that a "dumb terminal" is dumb. If a reader is designed and installed properly we shouldn't be able to glitch it or just plug into an access port, but that still leaves the air interface. The standard HID systems are just doing plaintext RFID and can fairly trivially be cloned by something like a proxmark. It gets a bit worse though with the plaintext systems. The IDs in the standard HID cards are usually formatted as a facility code, followed by a (sequentially allocated) user ID. So if you get the ID of one card -- even if that card has been cancelled -- you can brute force your way to a valid card fairly quickly.
There are encrypted systems (doing things properly) which have been out for a while, but they are still not nearly as common as they should be. Things can still go wrong if that's done poorly (e.g. Mifare classic) but as I understand it the new systems are fairly secure.
Finally, electronic locking mechanisms are still subject to manufacturing tolerances and obvious implementation blunders - meet the new problems, just like the old problems. There are lots of electronic door mechanisms out there which are vulnerable to nothing more complex than a good shove. This is common with both the mag plates and the latches. They also have unique hardware problems. We had a really amusing "bug" in our office where our actuator was wired up in parallel with other actuators by a lazy installer. So even though we were supposed to be in a separately secured section of the building (different access group + pin required for entry), people with access to other areas could still open the door by teaming up -- one person swipes on low security door, wait for the click, and other pushes on the high security door. Sigh.
In a roundabout way, I hope this explains a little bit of my skepticism when I picture an electronic locking company with a groovy kickstarter video (here at lockify, we've reimagined locking things!) and a shiny web 2.0 front end.
Oh wow, there is one! Actually, looks like a great idea.
In my opinion the best technical hack in that product is designing it fit over a deadbolt. That does an end-run over the OEM problem of needing distributors or partners to install and manage it, while providing a failsafe for when power or wifi isn't working. It also accounts for various denial of service conditions. It's not more secure than your existing lock in a physical sense, but it's cool that you can log door entries.
Would be an interesting product to perform a security review on.
That said, I would be really interested to see a shot at something new in this area.
Most of the current companies follow the OEM -> reseller model. Their customer is actually building and access maintenance companies, not the end user.