
Hacker Unlocks ‘High Security’ Electronic Safes Without a Trace - walterbell
https://www.wired.com/2016/08/hacker-unlocks-high-security-electronic-safes-without-trace/
======
kabdib
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.

~~~
awqrre
Which lock that you buy that a locksmith can't unlock?

~~~
xoa
> _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.

~~~
awqrre
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.

------
deutronium
You can get the slides here -
[https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20pre...](https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Plore-
Side-Channel-Attacks-On-High-Security-Electronic-Safe-Locks.pdf)

It really is a clever attack!

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.

~~~
pwg
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.

~~~
jamiesonbecker
Exactly. If you're doing something like:

    
    
        if hashing_function(unknown_pass) == hashed_pass:
    

you're doing it wrong...

Instead, use the compare function built into your crypto library, which should
hopefully be hardened against timing attacks.

In most languages, == and === _are not safe against timing attacks._

~~~
SilasX
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?

~~~
jamiesonbecker
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.

1\. [https://codahale.com/a-lesson-in-timing-
attacks/](https://codahale.com/a-lesson-in-timing-attacks/)

~~~
SilasX
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.

~~~
jamiesonbecker
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!) :)

1\.
[https://security.stackexchange.com/questions/111040/should-i...](https://security.stackexchange.com/questions/111040/should-
i-worry-about-remote-timing-attacks-on-string-comparison#comment198158_111046)

------
zeveb
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?

~~~
krisoft
Not every electronic lock have batteries. Some of them are powered by the user
spinning the dial. (for example the Kaba Mas X-10)

Electronic locksmithing is not in it's infancy. The FF-L-2740B specification
is already a 5 year old.

~~~
nullc
I like the Kaba Mas locks a lot, I wish they weren't so pricey.

------
EvanAnderson
David Jones' EEVBlog had an episode attempting to do powerline analysis of an
electronic safe:
[https://www.youtube.com/watch?v=HxQUKAjq-7w](https://www.youtube.com/watch?v=HxQUKAjq-7w)

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).

~~~
cmdrfred
I'd like to see an opensource deadbolt.

------
peterwwillis
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?

~~~
jdeeny
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.

~~~
teuobk
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.

------
gsmethells
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).

------
sctb
We updated the link from
[https://www.schneier.com/blog/archives/2016/08/hacking_elect...](https://www.schneier.com/blog/archives/2016/08/hacking_electro.html),
which points to this.

