• #security on software development security and web security, security best practices and discussions, break-ins and countermeasures. Everything you ever wanted to know about software security but were afraid to ask, for fear of not understanding the answer!

Hack NFC Door Locks

I can see in the logs that people sometimes come to this site with interesting searches. A recent interesting search was “Hack NFC Door Locks”. Well, since there is interest in the subject, why not? Let’s talk about NFC, contactless smart card and RFID door locks, shall we not?

Universal contactless smart card reader symbol

The actual technology used for the wireless door lock does not really matter all that much. Except, perhaps, when RFID is used because it only can support the simplest read-only schemes. But all in due time. What matters really is how the wireless technology is used. As it is usual in security, the technology could be used to create a fairly secure system or quite the same technology could be used to create a system that looks like a Swiss cheese to an attacker. The devil is in the details.

The simplest way to use any wireless technology to open a lock is to receive some kind of an identifier from the device, compare it to the stored database and take the security decision based on that. All of the RFID, contactless smart cards, and NFC send out a unique identifier when they connect to the reader. That identifier is used in many systems to actually take the security decision and, for example, open the door. The problem with this scheme is, of course, that there is no authentication at all. The identification phase is there but the authentication phase is absent. This is quite similar to asking a user name but not requiring a password.

Sounds silly but there are many systems that actually work like that. They rely on the assumption that copying a smart card is hard. Well, copying a smart card is reasonably hard compared to typing in a password although can be done fairly easily too but that is not the question. An attacker does not need to copy a smart card. The only thing that has to be done is to listen to the wireless communication with a good antenna from around the corner, record it and then play it back.

Another common alternative is to store a unique identifier into the smart card (or NFC device) and then request the card to send back that identifier. This makes for a longer conversation between the reader and the card compared to the case above and depending on the protocol the attacker may need to do more work. However, since the communication is not encrypted, it can be reverse-engineered easily and the attacker can still listen to the conversation, record all the required pieces of data and then communicate with the reader using his computer and an antennae.

Contactless smart cards and NFC devices have an option to use authenticated and encrypted communication. That is what typically used by the transport fare and banking systems. Those are hard to break. I spent countless hours analyzing and hardening those systems and I know that if it is implemented correctly an attacker will be as likely to break it as any other well implemented system using strong encryption – not very.

Of course, there still can be mistakes in the protocol, leaks that allow to guess some properties and secret material, special hardware attacks… but it is easier to attack the banking terminals with skimming devices than smart cards with hardware attacks. And door locks are more likely to implement the simplest of schemes than anything else…

Comments List

Cory C.2013-04-10 19:12 /

How about an NFC/Smart Card style application that makes use of a One-Time-Password in a counter sign sort of scheme? The 'key' device has a table of passwords. When it is used on the 'lock', the identifier is passed to identify the device. Then the 'lock' device sends an id to the key. The 'key' device consults it's table of one time passwords, and transmits the password that matchs the id the lock gave. The lock device then verifies this against an identical copy of the user's table to make the security decision. Even if this is unencrypted, that would be hard to break without first copying the key device's password table. If the algorithm is smart enough, each key can only be used once and thus snooping the return value would be worthless. You could further hash the key against some value related to the identifier such that no two users will ever produce an identical password. Obviously, encryption makes this scheme even more painful, but at that point is this maybe over kill? You could also make this stronger by switching to a single one-time-pass scheme that is set by scanning an interior lock (encryption would be required here, obviously) and cleared upon entry, and/or by encrypting the table of passwords on the 'key' device against a user-entered passphrase, much like how a lot of password services work or passphrases on rsa keys function. Run key app, insert phrase/draw pattern/pic the correct image, tap to pad, done.

tigr[ino]2013-04-10 20:45 /

This scheme is basically equivalent to a password, I think. What matters then is the size of the key space - the bigger the key space, the harder it is to guess the right password (key) and the longer it takes to perform an exhaustive search. All the rest are deterministic functions that do not impact the cryptographic strength of the system. An unrelated problem is that the key table has to be the same on all devices and if it is disclosed, all devices and the whole system becomes suddenly insecure. What's the way to change the keys?

Cory C.2013-04-11 14:47 /

It's not exactly the same as a password. You have a pool of passwords and the lock tells you which one to give it. Snooping the transmission doesn't help because the password give will always be different. You need to compromise the 'key' devices key table to know which password to return, and there are plenty of schemes that reduce the likelihood of bruteforce attacks actually working (introducing a communcation lag between call and response. Half a second is nothing to a human but an eternity to a bruteforce password attack). The key tables don't actually have to be the same between devices. The 'lock' device simply needs to keep a copy of each key table as sent to each 'key' device. Then you invalidate each key in the key table once it's been used (but only on the 'lock' device copy). This is really not that hard or space inefficient and since the lock is a stationary device, it would be trivial to give it adequate storage. Lastly, you could 'lock' the key table on each key device with a user-supplied password that is used as a salt for encryption/decryption. Without this key, the compromised key table is useless. My question is, is this scheme overly complicated when using encryption? (much like how for most webapplications, we just lean really hard on the assumption that SSL won't be broken and send passwords in clear text).

Bert Lee2013-04-15 03:14 /

When you snoop NFC communication, you said a powerful antenna may be required. However it should be considered that NFC RF working distance is normally less than 20cm. it would be hard to get some communication data within the RF working distance. And When NFC is in tag simulation mode, NFC device needs to get some energy from it's host.

tigr[ino]2013-04-15 06:21 /

I said you need a "good" antenna. In this case, you are going to likely need a directional antenna and a sensitive one at that. In the specification, NFC (and other smart card protocols) are supposed to work at distances up to 10 cm from the reader. In practice, this distance is usually smaller, sometimes down to 1-2 cm due to interference, limitations of technologies and so on. Despite this, the lab cases have proven that you can read (snoop on) the communication from as far as 20 meters away. When two NFC devices use active mode, both powering their end of communication, things become easier.

tigr[ino]2013-04-27 17:19 /

I think this scheme is very impractical. There is usually no password to lock the NFC device on the user end (it's usually a smart card like chip). There may be a possibility to use a PIN if it is a mobile phone, for example, but I doubt anyone has bothered to implement it so far. Even if they did, you'd have to come home, get your phone out, hold it at the door reader and... type in the password. Highly inconvenient and this is not going to sell. So the devices are not password protected, even if only for commercial reasons. The devices are also very small, both the reader and the NFC chip in the phone (or a smart card). The place (memory or storage) is very, very expensive. It is not a general purpose computer, there are no gigabytes of memory and hard disk. We are talking about bytes, kilobytes at best. So you may forget about the one-time pads (that's what single-use throw-away keys are, essentially), even on the reader devices, not to mention the card or phone. Thinking about smart card security (and that's what NFC essentially is) is quite different from the web application security. You need a different frame of reference. Think that you give your computer to the attacker. How are you going to protect the data? Now make that computer really small and really slow. And give the attacker a bunch of equipment for, let's say, half a million dollars, just to start playing with that PC you gave him. How long will it last? Now, the interesting (and practical) question from the security point of view for the system you imagined. Suppose I broke in and stole one of your reader devices that has a copy of all keys. And I do have the equipment to retrieve the keys from the reader. Now what do you do?

What are NFC cards and how are they protected? | Holy Hash!2013-06-18 16:38 /

[…] since I posted an initial article “Hack NFC Door Locks” I see a steady stream of people that come with queries like “what’s the […]

Leave a Reply

Your email address will not be published. Required fields are marked *