You might not even need this. The safe I own had two "user" and one "master" slot. Doing a search for documentation of similar models, I found that that some had a second "master" slot with a default factory code. Sure enough, this worked on my own model.
I find it easy to believe there are additional unlock codes for use by locksmiths, law enforcement and so forth.
I'm not buying another electronic lock any time soon.
>Which lock can you buy that a locksmith can't unlock?
"Unlock" is the key verb here, and any good safe should have that property to as great an extent as possible within its economic target. There is a critical distinction to make between the ability to "unlock" something and the mere ability to "gain access" it. While both ultimately yield up whatever is being protected, part of the core concept of "unlocking" is that it's non-destructive and trivially reversible, and thus to some extent provides some of the services of checksumming to the real world. It's not merely about preventing unauthorized access, but knowing about unauthorized access that couldn't be prevented. Any decent locksmith should be able to access any standard safe (that's their whole job) without any keys, but for a good safe that should require physical bypass (such as drilling, mechanical or energetic application, etc) to be involved, which will leave marks. In a legitimate scenario that's fine, because legitimate scenarios (including the government getting a warrant in an investigation) are not covert. As always in security an adversary with access to and willingness to use sufficient resources may be able to figure something out, but to point is to make that a bar sufficient to whatever level that situation needs.
If an electronic lock makes it trivial though to not merely gain access, but for non-owners to "unlock it", ie., to access with a speed and transparency equivalent to that of a legitimate operator, then that is actually a different and more concerning threat profile no matter what the case. As another example, it's certainly hardly an unknown threat that somebody could trivially smash the windows on a typical car to gain access to the interior. But that doesn't mean someone shouldn't be concerned if a newer car with an electronic lock can be trivially made to unlock in a way that's indistinguishable from the owner. There is a risk/reward economic difference that in turn changes the security threat profile.
I didn't choose the term "unlock" randomly... I know that they can unlock most locks without leaving any evidence behind (maybe even all locks)... which is why I asked this question.
Essentially, cheap locks can be bypassed very easily (almost anything by Masterlock). More expensive locks ($60+) will have more pins, making them harder to pick, and often have replaceable cores. Of course, security isn't just about the lock, which is addressed in the first video.
I'm really surprised at the way he mentions the microcontroller tests if the key is correct or not, by simply looping through and breaking on an incorrect number.
Not surprising at all. It is a standard pattern when programming for performance (which is what 99.9% of programmers are going for 99.9% of the time). Once you are sure the answer's wrong, don't bother testing any more of it. And for performance, this is correct, because you don't execute useless unneeded instructions.
The problem, of course, is that in the security realm, coding to break the loop as soon as the answer is known wrong is what provides these types of side channel attacks. But since 99.9% of programmers also do not write code for these environments when tasked to do so they just do what they are used to doing everywhere else (break early, when you know you are done with the checks) without realizing they are leaving an unlocked backdoor as a result.
Why would that leak key material? Knowing that you matched a few characters of the hash (based on earlier exit and quicker response time) doesn't tell you that some of the password characters match -- a partially-matching password shouldn't have an relationship to a fully-matching one, right?
Read the article[1] linked in yock's comment for the gory details, but to sum up: instead of having to calculate the entire set of possibilities for a given hash, you only have to iterate just enough to get the first byte. Then you can do the same thing again for the next byte, and so on. You can't just fix this with some random timing or additional noise.. it's a very difficult problem to solve.
It's telling that even the very smart person who did such a great write-up made a few mistakes again in initial attempts at demonstrating a corrected algorithm that actually blew the whole thing up again.
Because it's so subtle, the odds are very good that most current systems are fallible to this.
I understand that much, but, as I said in my comment, that would only work if the partial match were informative about the full match. A partial password match is informative of what the full password is, but a partial hash collision is not informative about the full collision. By design, learning about one hash preimage tells you nothing about other hash preimages.
By contrast, if you were comparing my submitted password to a stored password, I could use your response time to know that I got the first n characters right. Since n is a prefix of the password, I've learned something about the password, I can lock down those characters, and then guess more, etc. That much I understand.
But the case you're talking about is a comparison of hashes. In that case, timing attacks can tell me that my guess's hash's first n characters match the password's hash's first n characters. So now what? How do I adapt future guesses to learn more characters? What have I learned about (a preimage of the hash of) the password?
If partial hash collisions were, in any way, helpful in guessing the full collision, Bitcoin mining algorithms would adaptively change their guesses as they discovered that their nonces only led to a partial match.
To some extent, unless there is a flaw in the hash (fortunately, those are mythical;)), you're right, except leaking the hash itself can still leak useful data (here's a comment explaining how this can be used for an early-exit byte comparison[1]), and, for some hashes (such as MD5, SHA, etc) leaking the salt can significantly reduce the number of hashes that would need to be brute forced as well. Also, leaking the hash itself can provide a great deal of information about the scheme in use, which can either cause him to accelerate his attacks offline (DES!) or run away crying (bcrypt/scrypt!) :)
Depending on the hash used, it could be subject to a length extension attack. That was one of the big engineering goals for SHA3, to not be susceptible to those.
Nope! If you run the same input enough times, you can get enough data to be able to subtract the random noise out; the larger random number range, the more times you have to run it. The way to properly combat timing attacks is to write constant time code. Daniel Bernstein has made his career talking about and implementing this class of crypto.
Humor me, I think figured it out, run an identical "testPass()" function first and time it ('password' == 'password' if you will), then simply wait at least that length of time before acting on the result. As a bonus add a random delay after that so adversaries might waste time on isolating the randomness as you describe.
If you really want to add some sort of randomness, make it based on the user input. That way your randomness depends on what you send and won't be able to be subtracted out. Or use constant time things (which is hard for the record!) and not have to deal with it.
That's a neat attack, but why does anyone get an electronic safe in the first place?
The batteries may die, which means there must be a physical lock as well. Either the physical lock is less secure than the electronic lock (in which case an attacker will focus on the physical lock) or it is more secure than the electronic lock (in which case why not rely on the physical lock?).
That doesn't even begin to get into the fact that the profession of electronic locksmithing is still in its infancy and as a result electronic locks tend to be laughably insecure in the first place. The whole reason to have a safe is to keep things … safe. Why pay all that money and get nothing in return?
The key bypass is only on the cheapest consumer safes. Many of those can be opened just by rapping with a hammer.
This vuln was found in Sargent & Greenleaf locks. These are UL-listed locks suitable for securing cash in commercial establishments. They have no key bypass.
These locks have the batteries outside the safe, so there is no dead battery issue. However, this enables easy current measurements, as the hacker showed.
FYI, at this level there are no "electronic safes" - just regular safes with electronic locks, which have the same form factor as mechanical safe locks.
Why an electronic lock? Much faster to enter the combo, proof against robo-dialers, can maintain an audit trail of multiple employees, can issue different combinations to different employees and revoke access.
>The batteries may die, which means there must be a physical lock as well
I generally see a battery compartment on the exterior, so if the batteries die you just replace them and then enter the code. Sometimes the key lock does something like immobilize the dial or handle, so it's a second factor, not a bypass.
>Why pay all that money and get nothing in return?
On consumer-level safes, who knows. Beyond that: individually identify users, revoke specific users, have an audit trail of who opened it when, make the ACLs depend on time of day.
People get electronic safes because most people breaking into their house won't be hackers and combination locks are slow and tedious to open. Really tedious if it's something you keep important items in that you need daily or weekly.
From reading the underlying article, it is apparent that the power source is externally available (since they monitored power consumption). Looking at the instruction manual [1] confirms this; you do not need to open the lock to change the battery.
So there is no mechanical lock fallback. The fact that you can remove the batteries (and even the number pad) without unlocking the safe does seem to present some DoS attacks, but I assume that isn't a major concern.
> The batteries may die, which means there must be a physical lock as well.
Why not just have an A/C port somewhere so you can supply your own power if the battery dies? The worst a criminal could do at that point is try to crank a high amperage current through it and try to fry the computer, which would not unlock it.
I see you're downvoted, but I know Yale's residential electronic door locks [1] have a 9V battery terminal on the outside, such that you can open the door in case of an extended power outage. (For short outages the lock has a small internal battery.)
1. Every mechanical lock can be opened using a tool called ITL2000. It is a robotic arm that tests all the combos of the mechanical lock.
2. The maintenance of codes in a bank using mechanical locks is very complicated and costly. When the person in a branch who knows the combo takes holidays a locksmith has to go to the branch to change the combination, for example. In an electronic lock (SG-6121) there are the master code and 9 codes, one of them opens the lock without waiting for the delay.
Like other commenters here I'm wary of using an electronic lock because I'm not able to inspect the code for backdoors. I wonder if there's enough of a hacker market to warrant creating a crowdsourced electronic safe (or retrofit of the electronics of an existing electronic safe).
I didn't read the article, but is the lock RF shielded?
Also, slides show a 1/4" hole, and then the lock and an EEPROM; could it be feasible to melt plastic enough through this hole that one could then expose and flash the EEPROM with UV, resetting it?
An EEPROM (Electrically Erasable Programmable Read Only Memory) is erased electrically rather than with UV light like an EPROM. Even if there isn't a possible attack with light, there might be a way to alter the contents of the EEPROM if you can manage some amount of control over the signals entering the IC.
It turns out that part of the attack does exactly that. It was glossed over in the Wired article, but the slides describe how the lockout-penalty feature in the lock was defeated by manipulating the EEPROM. Basically, if you kill power to the lock at just the right time (i.e., midway through the EEPROM erase cycle as part of the larger/longer EEPROM write cycle), those bytes in EEPROM will be left with a value of 0 instead of whatever had been there.
The 1/4" hole is in the steel of the safe door, and then behind that is the hardened steel body of the lock-proper, so no, I don't think that would be feasible.
An electronic lock will not be on my home anytime soon. Mechanical inventions have nice properties like locality (no remote unlock), history (they've been through the war), and physics (bank vault vs bathroom lock).
I find it easy to believe there are additional unlock codes for use by locksmiths, law enforcement and so forth.
I'm not buying another electronic lock any time soon.