Spending an hour or two around any consumer-level padlock or house deadbolt lock with a simple lockpicking kit will typically instill a good amount of panic and concern about security. While it’s true that any lock can be defeated, it’s almost comically easy to pick basic locks like this. So, if you’re looking for a level of security that can’t be defeated in two minutes with a tiny piece of metal, you might want to try something a little more advanced.
This project stemmed from an idea to use a YubiKey, a USB hardware token typically used for two-factor authentication, for physical locks instead. The prototype was built around an Arduino UNO, and all of the code and build instructions are available on the project’s site. The creator, [rprinz08], does not have one built inside of a secure enclosure so that would remain an exercise for the reader, but the proof-of-concept is interesting and certainly useful.
While digital keys like this can have their own set of problems (as all locks do), this would be a great solution for anyone needing to lock up anything where physical keys are a liability or a nuisance, where logging is important, or where many people need access to the same lock. The open source code and well-known platform make it easy for anyone to build, too.
first of all, using usb as a key for a lock is one of the dumbest ideas i’ve ever heard of. secondly, yubikey has had no shortage of exploits found for it. two terrible decisions all in one project.
“So, if you’re looking for a level of security that can’t be defeated in two minutes with a tiny piece of metal” – i could defeat this joke project in 5 minutes, maybe less.
Even when I worked in Data Centers, the codes to press four digits for access entry was embarrassing. Using every code possible was attainable within a few days of all possible attempts. Even electronic codes were easier if you listened carefully to the combination for access. Companies that make licks, regardless of how a code is entered should make a code minimum of six, eight, or even ten numbers pressed. That way hearing a lengthy code is harder to remember. And buttons pushed, the faster an employee can take notice and alert security.
The question is why the data centers are using different times for different key presses. Are you sure it was a lock and not a telephone? I kid I kid
Different TONES
All comes back to the designer of the system. A poor design results immediately in poor security. First point, instead of discrete tones (likely DTMF) for each button, a single tone for any button press (you need operator feedback). Second, a timeout after each wrong entry, increasing for each wrong entry. Thirdly, a global lockout after so many incorrect tries, with a longer code (more digits) required to reset it back to default mode.
Upshot: Your data center security was awarded to the lowest bidder, and you got the security you paid for.
What exploits? I know there was an issue with the private key generation which was fixed & they offered free replacement to those affected but have there been any exploits of the OTP functions?
If you took the time to read before spewing your bile you’d see that it makes use of HOTP so if you’re really butt hurt about yubikeys you can use any number of standard tokens
Personally I think it’s a cool project and prototype. I think it’d be cool to see something using NFC + PKI so you can use a smartcards/yubikey for physical building access as well as 2FA
Agreed
The Yubikey also supports Slot 9e for PIV based door locks, and they have NFC models. It seems they were actually designed for physical security, the trouble is finding the security equipment (readers) in small lots (less than 1000 units) because everyone wants keypads or HID/prox for small & fast deployments.
“It’s not only a waste of money buying “high security” products which could be unlocked by just a paper clip like shown in this Video but might also be dangerous.”
And the paper clip defeat in the video had absolutely nothing to do with the lock mechanism, the box was not seam protected.
So, proposals are fine and cool, but would be better to provide a complete solution for evaluation.
Key-less locks is not a brand new idea, there are many products with bluetooth/web/app authentications and, oh brother, do they have been annihilated on the bench.
Presenting a USB port to the world exposes a much higher security surface area than the authors appear to realize.
Let’s plug in a USB Killer!
So from reading the article, the StickLock is supposed to send an unlock signal to the actual lock opening mechanism(not currently implemented) upon correct key insertion. plugging in a USB killer will just fry the electronics thus permanently disabling the lock. This is an interesting failure case but whats more interesting is what the author writes about his clear function:
“Note: If you use the clear feature be sure to have some other option to unlock like an additional physical lock etc. THIS FEATURE COULD BE DANGEROUS!”
Which actually negates his opening argument about locks that can be pick-able, who cares about this if you still have the analog key interface to operate the lock.
Also you would have to be very careful to choose your locking mechanism as it would have to be powered by the same source that Stick lock runs off of, having it on the mains runs into the issue of the lock simply not working if the power is out.
the problem is that the author artifically limits his project to what is essentially just the code with out considering the physical implementation but his argument is that this is better than a physically implemented lock that can be “lock picked” for a premise is flawed. First using a video of a defcon talk about picking shitty gun safes does not correlate to securing a location, there are many kinds of locks that you can get for doors, some that are quite difficult to lock pick. Second, securing a premise is much more than a singular locking mechanism as there are a whole raft of other things to consider. So while the code may be perfect and his circuits may be immaculate, what really matters is how this is implemented in the real world.
It cannot be argued that this is any better than a dumb lock until the final implementation is shown.
What would super glue or 2 part epoxy do to a typical key lock?
It may be just a legend but apparently car clamping lasted about a week in France because of people supergluing the locks. Made them impossible to open so they had to be cut and turns out car claps are far more expensive than a tube of superglue.
* Why not use some wireless technology like NFC
– Because sticking a physical key into a lock simply provides less attack
surface compared to wireless technology which could be (theoretically)
sniffed.
* USB is a dumb idea!
– Because of what? An USB token has the same usage vulnerabilities like
a classic key. It can be lost or stolen. Most of the standard physical locks
used in lockers (except high security lock types which costs far more then most
whole lockers) can be easily unlocked (assuming someone has the right
lock picking tools and knowledge). Using USB as a lock could be more secure.
Using a maximum of 64 bytes key IS unbreakable with trying all
possible combinations. Sure someone could use a usbkill (https://usbkill.com/)
on StickLock but all he gets is a dead lock (much the same like pressing
StickLocks) clear switch.
* Used correctly StickLock is almost (as nothing is) unbreakable
– enclosed in a sealed, resin filled steel case with screw terminals for
LEDs, switches and power
– installed inside steel locker not directly attached to locker walls
– signal lines (Valid Device, and Unlock) must both be High to
trigger unlock actuator (not specified, could be anything and is not
part of this project)
– Both unlock signal lines must be routed via different physical paths
inside locker to unlock actuator
– external power supply to StickLock could be another attack surface
– over-power will destroy StickLock rendering it useless
– lowering power supply provoking a BrownOut where SL could behave
undefined must be handled by SLs power stabilizer and processor
reset circuit.
* Using USB provides more attack surface!
– How?
StickLock just understands a very limited set of the USB HID protocol
everything else is ignored. All tests so far have shown that it is not
possible to trick StickLock to set both unlock signal lines to High
by either physically overloading/destroying the USB port or trying to
bring it into an undefined state by introducing invalid USB protocol
responses. Either the Arduino resets or hangs (both do not trigger
an unlock)
* Using USB provides more attack surface!
– How?
because as posted in your comment below, there is still a physical portion of the lock. StickLock’s failure mode is to not operate, meaning that USB killer or a dead battery or just clearing the keys means that the lock wont open. A lock that wont open means that there must be another way to open the lock, a physical means which usually means a key of some sort. Therefore StickLock provides more attack surface based on the fact that it is used in conjunction with a physical means of opening the lock and having more things to attack means a larger attack surface. Also, in the part you copied from the website above even states ways in which the attack surface is larger based on implementation: “external power supply to StickLock could be another attack surface” and depending on how the physical locking mechanism is implemented, battery power may not be economical.
Like i noted above in my comment, this cannot be argued as to be more or less secure than a keyed lock until the final implementation as the physical implementation is just as important as the software and StickLock as it stands is just a software implementation. The author of the post should be very clear about this and really shouldnt invoke comparison to other keyed locks, especially the ones on shitty gun safes.
ps, if you are the author, as implied by just copying part of the article here and your user name, i would like to point out the irony of your website having “The devil is in the details” in the upper right hand corner while glossing over the details of the physical implementation.
Security is about layers, your software layer looks great but the hardware layer is just as important.
Yes I’m the author and I agree with you, SL does not provide the hardware unlock layer (at the moment – working on that also) but must of standard locks fail at the authorization part and not at the actual unlock part. Made some clarifications on the project page.
Quite some standard “smart” locks fail on the unlock part, example:
https://www.youtube.com/watch?v=RxM55DNS9CE
And a piezzo zapper can be simply used to fry the electronics. Do this enough times and the cost if not the bother factor becomes significant. Then you simply rob the place when the owner has put in a cheap lock….
Expensive car alarms were disabled easily using a similar psychology. Keep bumping it and the false triggers become so tiresome that the owner leaves the alarm off and then the car gets stolen….
* StickLock is not a WHOLE lock!
– compared to a physical lock where authorization logic (the bolts and
springs matching the key) and unlock actuator (the cylinder and latch)
are combined into one unit StickLock represents only the authorization
part. The two StickLock signals Device-Valid and Unlock tell the unlock
actuator when to release the lock. That means while SL could be secure
the used actuator could still be vulnerable to “paperclip” hacks.
I really love the idea of this, but one thing that concerns me is that you would need to make sure that the usb port is no longer a wear item.
Is there such a thing as a ruggedized or tamper-proof USB port?
Something like the vandal-resistant keypads and switches I keep seeing.
That would make this pretty awesome for a household locking system if you installed the same latch mechanisms you see on electronic access doors.
That would be amazing. So, are you thinking a key switch, or real security like a Drumm Gemini Shield? That would cover the USB port neatly and protect it, and would only require a single key… Can you see the flaws here?
“We added two keys so it was more secure”
“We added a key turner so that both keys could be turned together”
“We added a lock to the key turner device”
If you are concerned about the USB port being a failure mode use one of the NFC variants of these digital keys instead.
Eh, just buy an actual high security mechanical lock, combine it with a rugged door and frame with properly installed hardware. Nobody is getting into that without significant effort and time, and it has none of the drawbacks of this monstrosity.
All security end with things like this: (brute force)
http://cdns2.freepik.com/foto-gratis/_2854266.jpg
Haven’t seen a word about oneWire iButton tech ?
I’ve got a few waiting in a drawer since a while….
What about this ?