1. Why? I mean, I get that it's a very small fraction, but if you're considering a scenario where you only get a very small fraction of the market, why should that very small fraction be more plausible than, say, 1% of that?
2. OK, so the population of the world is about 7 billion, and 1% of 1% of 1% of that is 7,000. That's not actually so very enormous, especially as you're not going to get a lot of recurring business. (Unless you're envisaging that people pay on a subscription basis for the continued use of the locks on their home, in which case I think 0% of 0% of 0% is a better guess for the likely market penetration.)
I disagree. We are talking about keys to critical infrastructure - fire doors, elevator overrides, utility areas of subway systems.
These are all resources that need to be accessible in a power outage or disaster situation. I do not want our firemen to be locked out of where they need to go because some digital lock lost power.
There is a reason in traditional engineering emergency overrides and shutoffs are mechanically implemented and don't go through a computer.
The whole point of this critical infrastructure is that it be accessible in an emergency and have as few failure modes as possible. A mechanical lock has very few failure modes short of changing the laws of physics.
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.
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.
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.
I'm surprised no one's brought Lockitron [1] into this discussion.
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.
Anyway, it's not a trivial modification, ie. just replacing the lock, because the digital lock needs power to process the key and unlock the door. As long as that's necessary, the initial investment and the increased complexity make the benefits moot to me personally. If you have some sort of door knob action maybe you could harness that to generate a small amount of power sufficient to unlock the door?