Master Keys
schneier.com
schneier.com
"n a recent research paper, we describe weaknesses in most master-keyed lock systems, such as those used by offices, schools, and businesses as well as by some residential facilities (particularly apartment complexes, dormitories, and condominiums). These weaknesses allow anyone with access to the key to a single lock to create easily the "master" key that opens every lock in the entire system. Creating such a key requires little skill, leaves behind no evidence, and does not entail engaging in recognizably suspicious behavior. The only materials required are a metal file and a small number of blank keys, which for many locks are readily available."
If you think about it, designing a lock that takes 2 completely different types of keys would be very difficult. If you don't fit the grooves that a regular key does, you don't fit. So you have to use the same blank. After that it is just the set of grooves that matters.
This is actually fairly common in commercial buildings. The keys have a channel running down the side (the 'grooves' you speak of). The grooves determine what kind of keyway the key can fit into. You can can configure your locks so a certain groove pattern will only fit a subset of your locks, while another kind of groove will fit into all of them. Schlage for instance makes a series of keyways (A, C, D, E, F, G, H, J, K, L, M, XP etc.) that are specified to do exactly this. I always forget which, but I believe it's the L keys that will fit into most of the other keyways.
You can consult Schlage's own books to learn more: http://professional.schlage.com/pdfs/sss/Schlage_Key_Systems... (scroll to the end.)
As long as no-one sold them to the public ...
Not really. A key is like a physical password. Security by obscurity is "I'm betting you don't know what kind of lock/encryption I'm using." Legitimate security is "I won't give you my key/reveal my password."
Just because there's a secret doesn't mean you're Doing it Wrong. "Something you know" is a valid authentication factor.
A key that you give out to thousands of people and cannot be changed afterwards ceases to be a key and becomes an intrinsic part of the system.
With a real key, when a leak like this happens, you invalidate the leaked key and issue a new one. In this particular case, they're basically stuck hoping that nobody does anything nefarious with this key.
The mere existence of a physical key does not make it security through obscurity. It's the fact that the same physical key is distributed to thousands of people with no good way to control them all or compensate for a leak that makes it security through obscurity.
Semantic nitpick, but how does that make this security through obscurity? S.T.O. is not betting your system on something you can't ever change, it's betting your system on hoping the attacker won't guess how the lock works. I think we should be careful not to use inappropriate labels, as this dilutes the language and makes it more difficult to communicate.
A master key is the same as a backdoor known to few. Whether you're using a key that fits the lock, or know that 'Joshua' is the superuser's login, it's still a "secret" which only provides protection while it's actually secret. I think it still counts as STO.
> Whether you're using a key that fits the lock, or know that 'Joshua' is the superuser's login, it's still a "secret" which only provides protection while it's actually secret.
But isn't the same true about passwords? Aren't passwords secrects providing protection only when they remain unknown?
The problem here lies, IMO, not with secrecy but with the password/key distribution and protection. I could imagine a situation similar to described in the article if an administrator gave server's root password to half of the company staff, hoping that no one leaks it.
To quote Kerckhoffs's principle, which Wikipedia leads me to believe is the basis of the whole concept of security through obscurity:
"Its key must be communicable and retainable without the help of written notes, and changeable or modifiable at the will of the correspondents"
Despite the name, this master key is not a "key" in the cryptographic sense. Any system intended to provide security without a key is necessarily relying on security through obscurity.
Half an hour later I have a master key to your house because I Googled "XYZ master key" and filed the appropriate key blank to match. How do you combat that?
That's the security-by-obscurity argument - once the information on "XYZ master key" is available, your house is compromised and you can't fix it by rekeying, only by replacing all XYZ-brand locks with a different brand.
A master key represent reduction of security (by bypassing depth of security and putting more eggs in one locked basket). Both security trade-offs for convenience.
My fancy new luggage comes with combination locks and in addition with one of those TSA locks.
The thing is, how many different lock combinations are they? (My guess: less then a dozen) How widely must the master keys be distributed? Well, in multiple instance to every airport in the US and then some How long until a bunch of dodgy luggage handlers own a set of those locks?
While the consideration not having to break your luggage is nice the implementation seems not very secure to begin with (yeah: I know: neither are luggage locks, but still)
Especially the part about how you can just bust open the zipper on a locked bag anyways.
"Master keys are a convenience, not a security measure."
I imagine that it's easier just to stick with the good old master keys.
I've long believed that most locks are not there to stop professionals, they're just there to stop the opportunist.
If you're at peace with this then there's little advantage spending an extremely large amount of money putting in place a sub-standard digital solution.
The existing system is good enough.
The lock on your front door won't stop someone breaking into your house. Or rather: your lock likely isn't the weakest point when it comes to keeping people out.
However, with the master keys it's not just about getting into places where you shouldn't be able to go, it's also about more or less locking a whole place down by disabling elevators. I can imagine you could put something a bit more complex to disable something which already requires electronics to function.
As I said... it's good enough.
Sounds like physical keys do that.
My house has no master key, after all. If the fire department needs to get inside, they will break the door down. That is the universal master key for any situation, and my understanding is that fire departments are well equipped for this.
Why not simply not have a master key, with the understanding that the door will be destroyed in the event of an emergency?
How often have you heard of someone picking the lock to a knox box or an elevator control panel? (Probably not very)
How often have you heard of someone hitting the alarm or screwing around with the emergency options? (Probably more)
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?
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.
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.
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.)