QR Code Opens Doors To You

[Jeremy Blum] wrote in to share his LibeTech QR Code Door Lock project. He developed it during his Senior year at Cornell University along with three of his classmates. It seeks to move away from magnetic card locks in favor of optical locks that authenticate based on a QR code.

The hardware he’s using here is definitely cost prohibitive, but we’re sure the concept could be greatly simplified. In this case a BeagleBone running embedded Linux monitors a feed from a webcam. When it detects a QR code it compares it with a database of approved keys and will unlock the door for you.

There are problems with this technique, one being that an attacker might be able to get a usable photograph of your key without you knowing. But the majority of hotel locks in use right now are even less secure than that. On the upside, the key to your room can be emailed to you for use on just about any device with a screen, or printed out on a piece of paper.

You can find [Jeremy’s] presentation video embedded after the break.

31 thoughts on “QR Code Opens Doors To You

  1. “On the upside, the key to your room can be emailed to you for use on just about any device with a screen, or printed out on a piece of paper.”

    This would be good for a one-use system, where your real key is inside the room waiting for you to pick it up.

    1. To go one step further, at least in regard to assuming a mobile device like a phone is present…

      You could simply make all keys one time use. Every time the person wants to enter the door, they bring up their app/webpage that generates a new QR code that has a new key in it, which is active for X number of uses and expires regardless after a certain amount of time.

      It’d be interesting to also do some “two factor authentication” since there’s a webcam involved. Snap a picture of the user to compare to pictures of known users.

      Interesting indeed.

      1. problem with the single use code app is that without some sort of feedback from the lock telling the phone to move on, you could very easily end up out of sync by accidentally clicking the wrong thing on your phone.

        this might be solvable by giving the lock it’s own lcd screen right below the camera, allowing for 2way communication. that way the phone can confirm that the old code has been accepted, and then receive the new one directly from the lock.

        you could require the lock & phone to flash a series of codes at eachother, so that an attacker couldn’t just use a photo of your phone’s screen. throw in a bit of clever crypto & you could actually have a fairly secure system there.

      2. @J: The door could accept the next n-Keys (say n=10) and synchronize on each successfull authentication. That is pretty common for one time passwords. That way you’ll have to generate 10 keys on the phone to get out of sync, which is very unlikely to do by accident. A display for two-way QR-code communication seems silly to me

  2. Not practical at all, except one time unlocks or dynamic unlocking (server sends you the right code to show onto your mobile). For everything else I would be extremely hesitant, because it almost asks for skimming attacks, where a small conceiled camera grabs a shot of the key and the atacker can then enter. Best locks so far are the transponder locks with encrypted transmission and decent mechanical security.

  3. If you have a phone that can generate & display specific one-time QR codes which have the date+time embedded in the code that would stop someone from taking a photo of the code and trying it at a later date.

    I saw this on bluetooth enabled lock on Shark Tank earlier this year http://www.unikeytech.com/ and you could adapt some of the same techniques for a QR code system – one time entries, codes that only work during certain times (if you have a cleaner etc.)

  4. If the camera’s acquisition of the QR Code is quick enough why not just have the app flash a hundred fake, random, QR Codes with the real one stuck in the middle somewhere, that would make it harder for someone to surreptitiously snap a photo of the right one and someone taking a video of your phone would be pretty obvious.

      1. yes, my instant reaction, just flash ‘every possible’ code at the reader until it opens.
        Given that QR codes are highly error correcting, it should not take long before one is accepted. If this system were to be commercially developed it would need to recognise an attack and alarm/ lockdown etc.

  5. We already do this with barcodes (even on ‘phones – tickets etc).

    Many barcode scanners are infrared, so you put the black tape over them (blocks visible but not IR light) to ward off the ‘take a photo of it’ crowd.

    Been solved, needs less tech, address security concerns mentioned above, etc.

    But yeah, let’s re-invent the wheel and over-complicate stuff ’cause QR codes are cool.

    1. Yeah, I’m normally all for experimenting with crazy ways of doing mundane things, but I’m really not comfortable with over-complicating and generally futzing with things that people depend on for safety and security. Maybe I’m missing something but this QR code approach seems to add cost, while making it drastically easier to get access to something you shouldn’t (if QR codes aren’t one time), AND dramatically more prone to SNAFUs that could leave people stranded outside or something (especially if QR codes *are* one time). That’s on top of requiring students to have a smart phone (which isn’t really fair or reasonable, even if most do).

  6. I second the time sensitive QR code ideas. Similar to banking – who’s seen the PinSentry system for banking auth? A Similar security augmentation would make this work well.
    But simply QR coding a known date and time format (also assuming minute or greater accuracy clock syncing) is vulnerable in its own right, clock skew, QR decode analysis, etc. will eventually break it.
    You’d need to get both sides of the system to perform an identical crypto hash of some kind on the date and time and generate the QR there and then. And passcode locking out your phone as an absolute minimum.
    It seems this could really work!

  7. This would actually work just as well as key pair authentication. If your code is captured by a would-be intruder, the administrator would be able to easily remove only the offending key without rendering the lock useless to other users.

    That said, it would also be easy to implement 2 factor auth with any web enabled device by having the user enter a password/pin and having a unique code generated and displayed that will work only once on the lock, somewhat like rsa key fobs.

  8. It would be cooler if you could use some kind of IR-visible ink so you could have seemingly blank piece of paper that would open your door – kinda like psychic paper from Doctor Who. :) Also, that would make access code difficult to copy.

    1. A previous employer used something similar for building access control. The badges were barcoded, but the barcodes were obfuscated to confuse copiers and scanners that used white light instead of the narrow red of the LED in the readers.

      Fortunately I had a barcode wand around from an old trade show demo. It was able to read the code, and with a barcode generator I was able to print working clones of my own badge.

      Now using an OTP QR code generated with a smartphone app…

  9. Ah well, the QR code in their build is not improving things at all.

    With the computing power, webcam and ethernet, they can use whatever image they want and compare it to known image “signatures” in database. No need to decode stuff from the actual image.

    Moreover, static images (QR code or not..) are vulnerable to replay attack as many of you already stated.

    The only place this could be usefull is somewhere remote (or highly embedded), without network connection and without possibility of regular key db updates. But then it would require QR keys with expiration and at least two factor auth.

  10. This would be great if it was implemented as a Time-based One Time Password i.e. use current unix time (to nearest 100) and hash it with your secret key.
    Then the phone and lock clocks only need to be within 100 seconds of each other and a skimmed key will only work within that 100 seconds (easily fixed by only allowing one entry per 100 seconds)

  11. Implementing it as part of a two factor authentication seems more feasible. An example of that would be thumb print and QR code. But by itself, the ability to view the QR code remains a primary flaw, even with encryption.

    The idea of a dynamic OTP QR code generator is interesting but you will only find yourself securing the generator device with another means of authentication to protect the loss of the device. Which is a little counter productive and not entirely cost efficient.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.